SEO
Do You Still Need a Third-Party SEF Extension?
For years the first thing installed on a new Joomla site was an SEF extension, because the core router genuinely needed help. That has not been true for a while, and installing one out of habit now buys you a dependency in exchange for…
What core covers
Out of the box, with three settings in Global Configuration → Site → SEO:
- Readable URLs built from menu structure and aliases.
- Remove IDs from URLs, which drops the numeric prefix that used to be the main complaint.
- URL rewriting, so
index.phpdisappears from the path. - An optional suffix, if you want
.htmlon the end.
Beyond configuration, the modern router can be strict about what it accepts — returning a 404 for a path that does not match, rather than rendering the article anyway under whatever URL was requested. That single behaviour removes a whole class of duplicates that SEF extensions were bought to clean up afterwards.
Add to that a Redirects component that records 404s and maps old URLs to new ones, plus per-article metadata and robots settings. That is most of the historical feature list.
One genuine gap: canonical tags. Core emits none by default — the SEF plugin adds one only when an alternative domain is configured. If you need canonicals, that is a dozen lines in a template or a small plugin, not a reason to install a routing component.
What an extension can still add
Honest answers, and they are narrower than the marketing:
- Fully custom URL patterns — if the business requires a structure the core router will not produce, an extension is the way to get it.
- Bulk metadata rules — title and description templates applied across hundreds of pages by pattern, which core does per item.
- Routing for third-party components whose own routers are poor. Though the better fix is usually the component.
If none of those describe your site, you are installing a dependency for nothing.
What it costs
An SEF extension sits in front of every request on the site and rewrites the routing. That has consequences worth stating plainly.
It becomes load-bearing. Once URLs are generated by the extension, removing it changes every address on the site. The exit cost only grows.
It follows your upgrade schedule. A component this deep in the request cycle has to be compatible before you can move to a new Joomla version. Sites stuck on old Joomla are very often stuck behind one extension, and a router is a common one.
It duplicates decisions. When both core and the extension have opinions about canonical URLs, redirects and 404s, the interaction is where the confusing bugs live.
How to decide
Configure core first, then look at the actual URLs your site produces. Crawl it and list the distinct addresses. If they are readable, if each page has one address, and if the extra addresses that exist are handled by canonicals or redirects, the job is done.
If something specific is wrong, name it before shopping. "URLs are ugly" is not a requirement; "product pages should live at /brand/model rather than under their category path" is, and it tells you whether any extension actually solves it.
Before changing anything on a live site
Whatever you decide, changing URL structure on an indexed site is a migration, not a settings change. Export the current URLs first, plan the redirects, and apply both together. We covered the mechanics of that in a separate piece on redirect mapping.