Joomla SEO Setup Guide : URLs, Metadata and Sitemaps [2026]
Joomla's SEO configuration done properly, including the duplicate-URL behaviour that catches almost every new site.
Your Joomla site is live, the content is good, and the URLs look like index.php?option=com_content&view=article&id=42. Worse, you have discovered the same article is reachable at three different addresses depending on which menu the visitor came through, and you do not know which one search engines are indexing.
Joomla’s out-of-box SEO is adequate — genuinely so, and better than its reputation suggests. But it has one structural quirk that no amount of plugin installation fixes, and which you have to handle deliberately: the router will happily serve the same content at multiple URLs. This guide covers the whole configuration for Joomla 5.x, and is honest about where the core stops.
Turn on SEF URLs properly
Three settings in Global Configuration → Site control URL formatting, and they interact.
| Setting | Set to | Resulting URL |
|---|---|---|
| All three off | — | /index.php?option=com_content&view=article&id=42 |
| Search Engine Friendly URLs | Yes | /index.php/services/consulting |
| + Use URL Rewriting | Yes | /services/consulting |
| + Adds Suffix to URL | No (recommended) | /services/consulting rather than .html |
| Unicode Aliases | No (usually) | Transliterated ASCII aliases rather than raw Unicode |
Enable SEF, rewriting and rename the htaccess file
Set Search Engine Friendly URLs to Yes and Use URL Rewriting to Yes. Then rename htaccess.txt to .htaccess in your web root — Joomla ships the rules but not the active file.
Order matters here. Enabling rewriting without the .htaccess in place gives you a site where the homepage works and every other page returns 404, which is an alarming five minutes if you were not expecting it. If that happens, set Use URL Rewriting back to No, rename the file, then re-enable.
On nginx there is no .htaccess. The equivalent goes in the server block, and your host may have to apply it:
location / {
try_files $uri $uri/ /index.php?$args;
}
Switching “Adds Suffix to URL” off, or turning rewriting on, changes every URL on the site. Search engines have the old ones indexed and visitors have them bookmarked. Either make the change before launch, or make it and immediately add 301 redirects from old to new — Joomla’s core Redirect component, with its System – Redirect plugin enabled, captures incoming 404s so you can map them. Doing neither loses whatever ranking those URLs held.
Should you remove the .html suffix?
Yes, on a new site. It carries no ranking benefit, it makes URLs longer, and it implies a static file that does not exist. Set Adds Suffix to URL to No.
On an established site the calculation is different. The suffix is harmless, and removing it means redirecting every indexed URL. Unless you are already restructuring, leave it. This is a tidiness preference dressed up as an SEO decision, and it is not worth a migration on its own.
Menu structure is URL structure
This is the part that catches people coming from other systems. In Joomla, the URL of a page is derived from the menu item that points to it, not from the article’s category. An article in the “Consulting” category, reached through a menu item under “Services”, produces /services/consulting-article. Change nothing about the article and move the menu item, and the URL changes.
Two consequences follow.
First, plan your menu tree as you would plan your URL tree, because they are the same thing. A flat menu produces flat URLs; a three-level menu produces three-level URLs. Aim for a structure where any page is two or three segments deep — deeper adds length without adding clarity.
Second, articles with no menu item pointing at them get a URL derived from wherever Joomla can route them, which is where the duplicate problem starts.
The duplicate URL problem, and how to actually handle it
Here is the behaviour that no other major CMS shares, and the single most important thing in this article.
Joomla’s router resolves a content item through whichever menu path it can find. If an article sits in a category reachable through two menu items, the article is reachable at two URLs. Both return HTTP 200 and identical content. Neither is marked as the real one.
/services/consulting/strategy-workshops
/resources/articles/strategy-workshops
/component/content/article?id=42
That third form deserves attention. Any article is reachable via the non-SEF route whether or not you have a menu item for it, and crawlers do find them.
Fix it in this order
- Give every important page exactly one menu item. This is the real fix. A page with one route has one URL. It costs nothing and removes the problem at source rather than papering over it.
- Set the canonical. Joomla 5 emits a canonical link for most core views, but not reliably in every multi-route situation. Verify by viewing source on a page reached by two paths — both should carry the same
<link rel="canonical">. - Block the non-SEF component route in
robots.txt, which stops crawlers finding/component/content/URLs in the first place.
# robots.txt additions
Disallow: /component/
Disallow: /index.php?
Disallow: /*?limitstart=
Disallow: /*?start=
A robots.txt disallow stops crawling, not indexing — a blocked URL can still appear in results if something links to it, listed without a description. If a duplicate URL is already indexed and you need it gone, you must let the crawler reach it and serve either a noindex or a 301. Blocking it in robots.txt first actively prevents removal, because the crawler can no longer see the instruction.
The pagination parameters matter more than people expect. A category blog with 200 articles and 10 per page generates 20 near-identical listing URLs, each with the same title and meta description. Blocking limitstart is the quick handling; setting a sensible items-per-page and using a proper archive structure is the better one.
Metadata: three levels, and which wins
Joomla sets metadata at three levels and the precedence is not obvious.
| Level | Where | Applies to | Precedence |
|---|---|---|---|
| Global | Global Configuration → Site → Metadata | Site-wide fallback | Lowest |
| Menu item | Menu item → Page Display and Metadata tabs | The page that menu item produces | Beats global |
| Article | Article → Publishing tab | The article when viewed on its own page | Highest, on single-article views |
The practical upshot: for a page produced by a menu item — the homepage, a category blog, a contact page — set the metadata on the menu item. For an article reached through a category listing, set it on the article. Setting it on the article and wondering why the category page still shows the global description is a common and entirely understandable confusion.
Set the fields that matter
On a menu item, Page Display holds the Browser Page Title — this becomes the <title> tag, and it is separate from the menu link text. Set it explicitly; leaving it empty means the title is the menu item title, which is optimised for navigation rather than search.
The Metadata tab holds the Meta Description. Write 140–160 characters that describe the page and give someone a reason to click. Leave Meta Keywords empty — no major search engine has used it for well over a decade.
Global Configuration metadata defaults
Under Global Configuration → Site → Metadata Settings, four settings deserve a decision rather than a default.
Site Meta Description is the fallback for pages with nothing more specific. Write one. A generic fallback is better than an empty tag, and worse than a specific one — treat it as a safety net, not a strategy.
Robots is the site-wide directive and the most dangerous setting on the page. It should read index, follow on production. If it says noindex, nofollow, nothing on the site can be indexed regardless of what else you do. This is the first thing to check when a site is invisible in search, and it is set wrongly surprisingly often — usually because it was set during development and never changed back.
Content Rights and Author Meta Tag are optional. Turning the author tag off is reasonable on a site where staff names are not something you want published in the markup.
Global Configuration → Site → Robots overrides everything below it. A staging site copied to production keeps whatever it had, and a site that has been live for six months with noindex will have no organic traffic and no obvious reason why. Check it now, then check the per-menu-item robots settings on your key pages, then check robots.txt. Three places, two minutes.
robots.txt in Joomla
Joomla ships robots.txt.dist. Copy it to robots.txt — the .dist file is not served and exists so that core updates do not overwrite your customised version.
The shipped rules block the administrative and system directories, which is right. What people frequently get wrong is blocking /media/ or /templates/ — do not. Search engines need to fetch your CSS and JavaScript to render the page as a visitor sees it, and blocking those directories causes rendering problems that are hard to diagnose from the outside.
User-agent: *
Disallow: /administrator/
Disallow: /api/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/
Disallow: /component/
Sitemap: https://example.com/sitemap.xml
XML sitemaps: what the core does and does not do
Be clear about this, because a lot of published advice is wrong: Joomla 5 does not generate an XML sitemap out of the box. There is no core sitemap component. If you want one — and you do — you install an extension.
What core Joomla does provide is a set of RSS/Atom feeds, at /index.php?format=feed&type=rss and per-category equivalents. A feed is not a sitemap. It contains recent items only, in a different format, and while search engines will consume one, it is a poor substitute.
| Need | Core Joomla 5 | Requires an extension |
|---|---|---|
| SEF URLs and rewriting | Yes | — |
| Per-page title and meta description | Yes | — |
| Canonical tags on core views | Mostly | Edge cases |
| 301 redirect management | Yes (Redirect component) | — |
| XML sitemap | No | Yes |
| Open Graph / Twitter Card tags | No | Yes |
| JSON-LD structured data | No | Yes, or template override |
| Bulk metadata editing | No | Yes |
| Image alt text enforcement | No | Editorial discipline |
Free and commercial sitemap extensions both exist; commercial Joomla SEO extensions typically sit around €30–60 per year. Whichever you choose, verify it lists Joomla 5.x compatibility explicitly — the Joomla 4 transition removed a number of long-standing SEO extensions from the ecosystem, and some listings have not been updated.
After installing a sitemap extension
- Confirm the sitemap includes only canonical URLs — if it lists both
/services/xand/resources/x, you are actively advertising your duplicates. - Exclude unpublished, archived and access-restricted content.
- Add the sitemap URL to
robots.txt. - Submit it in Google Search Console and Bing Webmaster Tools.
- Check back after a week: a large gap between submitted and indexed counts usually means duplicates or thin pages, not a sitemap fault.
Structured data
Joomla emits some microdata in core layouts — the article view carries basic schema markup — but it does not produce the JSON-LD that most guidance now recommends, and it produces nothing for organisations, breadcrumbs, products or FAQs.
Two routes. An SEO extension will generate JSON-LD from your content with configuration rather than code. Or, if you want control and have one or two schema types to emit, a template override on the article layout is straightforward and adds no extension to maintain:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "<?php echo htmlspecialchars($this->item->title, ENT_QUOTES, 'UTF-8'); ?>",
"datePublished": "<?php echo HTMLHelper::_('date', $this->item->publish_up, 'c'); ?>",
"author": {"@type": "Organization", "name": "Example Ltd"}
}
</script>
Escape everything you output. Unescaped quotes in an article title break the JSON and the markup is then silently ignored, which is the most common way hand-rolled structured data fails.
Image alt text
Joomla’s Media Manager and editor both offer an alt text field, and neither enforces it. On most sites a meaningful share of images ship with none.
Alt text is an accessibility requirement first and an SEO input second, and the same rule serves both: describe the image in the context of the page. “Team photo” is nearly useless; “The Example Ltd delivery team outside the Bristol depot” is useful to a screen reader user and to an image crawler.
Purely decorative images should carry an empty alt attribute — alt="", present but empty. That tells assistive technology to skip it. Omitting the attribute entirely is different and worse: the screen reader may read the filename aloud.
When you insert an image, TinyMCE presents the alt field but does not require it, and the Media Manager will not warn you. If you have contributors, this becomes a policy problem rather than a technical one. An accessibility checker extension run monthly is a reasonable safety net; asking people to fill in the box is more reliable.
Aliases: the field that becomes your URL
Every article, category and menu item has an alias, and it is the URL segment. Joomla generates one from the title if you leave it blank.
Three rules. Keep it short and readable — generated aliases from long titles produce URLs nobody wants to share. Use hyphens, lower case, ASCII. And do not change an alias after the page is indexed without adding a redirect, because changing it changes the URL and the old one starts 404ing immediately.
The Unicode Aliases setting in Global Configuration decides whether a Turkish or Greek title produces a raw-Unicode alias or a transliterated ASCII one. Transliteration is the safer default: Unicode URLs are legal and work, but they become percent-encoded when copied, which makes them ugly in shared links and awkward in analytics.
Redirects with the core Redirect component
Joomla ships a Redirect component that most people never enable. It is genuinely useful.
Enable it before you restructure anything
Enable System – Redirect in the plugin manager, then open Components → Redirects. From that point every 404 the site serves is logged with its referrer.
After a restructure, work through the list: for each logged 404 that corresponds to a real old URL, enter the new destination and publish the redirect. Joomla then serves a 301 to that URL.
Two limits worth knowing. It only records URLs that were actually requested, so it is reactive — it will not tell you in advance what you are about to break. And on a busy site the list fills with scanner noise probing for wp-login.php and similar; filter aggressively and do not treat volume as signal.
A launch checklist
- SEF URLs on, URL Rewriting on,
.htaccessrenamed. - Suffix off (new sites only).
- Global Robots set to
index, follow. robots.txtcreated fromrobots.txt.dist, with/component/blocked and the sitemap URL added.- Every key page has exactly one menu item.
- Browser Page Title and Meta Description set on every menu item.
- Canonical tags verified by viewing source on a multi-route page.
- Sitemap extension installed, generating canonical URLs only.
- Sitemap submitted to Search Console and Bing Webmaster Tools.
- System – Redirect plugin enabled.
- HTTPS forced site-wide, with HTTP 301ing to HTTPS.
- One canonical hostname — pick
wwwor non-wwwand redirect the other.
That last item is easy to forget and produces a whole-site duplicate. Both hostnames resolving with HTTP 200 means every page on the site exists twice as far as a crawler is concerned. Fix it in .htaccess or at your CDN, and set $live_site in configuration.php only if you have a specific reason to — leaving it empty lets Joomla work it out, which is usually what you want.
Frequently asked questions
Does Joomla 5 generate an XML sitemap?
No. There is no core sitemap component, and the RSS feeds Joomla does provide are not a substitute. You need an extension. Check its listing states Joomla 5.x compatibility explicitly, since several long-standing SEO extensions did not survive the Joomla 4 transition.
Why is the same article showing at two different URLs?
Because Joomla’s router resolves content through whichever menu path can reach it, and an article in a category reachable from two menu items has two valid URLs. The durable fix is giving each important page exactly one menu item; the mitigations are canonical tags and blocking /component/ in robots.txt.
Should I remove the .html suffix from my URLs?
On a new site, yes — set Adds Suffix to URL to No before launch. On an established indexed site, no, unless you are restructuring anyway: the suffix does no harm, and removing it means redirecting every indexed URL for a purely cosmetic gain.
Do I need a paid SEO extension for Joomla?
Not for the basics. Core handles SEF URLs, per-page metadata, canonicals and redirects. You need something extra for an XML sitemap, Open Graph tags, JSON-LD and bulk metadata editing — a free sitemap extension plus a template override covers a lot of that, and paid suites mainly buy you convenience and bulk editing.
My site is not appearing in search at all. What do I check first?
Three settings, in this order: Global Configuration → Site → Robots (must be index, follow), the per-menu-item robots setting on the pages concerned, and robots.txt. A staging site promoted to production with noindex left in place is the commonest cause by a wide margin.
Where do I set the page title — the menu item or the article?
For a page produced by a menu item, use the menu item’s Page Display → Browser Page Title. For an article reached through a listing, use the article’s Publishing tab. Article-level metadata wins on the single-article view; menu item metadata governs the listing page itself.
Are meta keywords worth filling in?
No. No major search engine has used the keywords meta tag for well over a decade. Leave the field empty and spend the time on the meta description, which is shown to searchers and does influence whether they click.