Drupal SEO has an unearned reputation. Ask around and somebody will tell you Drupal is good for search out of the box, usually while comparing it to a fifteen year old memory of another platform. A stock Drupal 11 install ships with no meta description field, no XML sitemap, no automatic redirect when a URL changes, and content that answers at /node/123 until an editor types an alias by hand.

That is not a criticism of the project. Core deliberately keeps its surface small and pushes anything opinionated out to contributed modules, which is exactly why a large Drupal site can be tuned more precisely than most platforms allow. But it does mean the phrase “out of the box” is carrying a great deal of weight, and it means a Drupal site’s search performance is decided almost entirely by which modules were installed on day one and how somebody configured them.

What follows is an account of that stack as it stands in September 2026: what core does, which contributed modules replace what other systems hand you for free, the failure modes that only exist on Drupal, and what it costs to repair a site where none of this was done at the start.

Is Drupal good for SEO out of the box? No. Core gives you path aliasing, canonical link tags and a strong multilingual routing layer, but it provides no meta descriptions, no XML sitemap, no redirect handling and no structured data. Those come from four contributed modules: Pathauto, Metatag, Simple XML Sitemap and Redirect. A Drupal site without them is not badly optimised, it is unoptimised.


What Drupal Core Actually Does

Core gives you three things that matter, and all three are genuinely good.

The core Path module lets you attach a human readable alias to any route, so a node can answer at /services/tax-advice instead of its internal path. Core stores the alias and resolves the request against it. What core will not do is invent the alias, so on a site with two thousand nodes somebody has to type two thousand aliases, and in practice nobody ever does.

Core also emits link relations on entity pages. Viewing a node produces a rel="canonical" pointing at the aliased URL and a rel="shortlink" pointing at the unaliased one, which is more than several commercial platforms manage without a plugin. That single behaviour is why the duplicate path problem described below is usually survivable rather than fatal.

The third is language. Core’s multilingual stack handles path prefixes, per language aliases and alternate language links on translated entities, and it is the strongest part of Drupal’s search story.

Everything else is contributed. There is no meta description field on a content type until you add one, no sitemap, no redirect table, and deleting a node leaves a 404 and nothing else.

The Four Modules That Are Effectively Mandatory

Dozens of modules carry an SEO label on drupal.org. Four of them are not optional, and a Drupal build that skips any one has a hole its competitors do not.

Pathauto

Pathauto generates aliases from token patterns, so a pattern such as blog/[node:title] produces the alias automatically when the node is saved. It is the closest thing Drupal has to a universally installed module, with 464,471 sites reporting it, and the current stable release, 8.x-1.15 from 4 May 2026, supports Drupal 10.2 and 11. It depends on the Token module.

The setting that decides whether Pathauto helps or hurts is the update action, which controls what happens when a title changes and the pattern produces a different alias. Pathauto can do nothing, replace the alias outright, or create the new alias and a redirect from the old one. The third option is the one you want, and it exists only when the Redirect module is installed. Sites left on a weaker default quietly accumulate several live aliases per node.

Metatag

Metatag is how a Drupal page acquires a meta description at all, along with Open Graph and Twitter Card output. Damien McKenna has maintained it since 2012, 332,868 sites report using it, and release 2.2.0 from September 2025 requires Drupal 10.3 or 11.

It works through defaults set per entity type and bundle, written as token patterns, with per node overrides layered on top. The common failure is a pattern that resolves identically across an entire content type, producing several hundred pages that share one description. That is worse than having no description, because it tells a crawler the pages are interchangeable.

Simple XML Sitemap

Core ships no sitemap of any kind. Simple XML Sitemap is the standard answer, used by 137,418 sites, with release 4.2.3 from 26 November 2025 requiring Drupal 10.3 or 11. It indexes entities, views and custom links, and it emits hreflang and image entries, which matters a great deal on multilingual builds.

Configure it per bundle rather than globally. The default temptation is to include everything, which pushes taxonomy term pages, user profiles and unfiltered views listings into the sitemap and tells search engines that your thinnest pages are a priority.

Redirect

Redirect provides manual redirects and, more importantly, canonical URL enforcement: it can redirect every non-canonical request for a piece of content to the canonical path. 265,749 sites use it, and 8.x-1.13 from 24 April 2026 supports Drupal 10 and 11.

One caveat worth stating plainly. The project page currently carries a “seeking co-maintainers” notice, which for a module this load bearing is a maintenance risk to watch rather than a reason to avoid it. It is still covered by the Drupal security advisory policy.

Drupal SEO Traps That Other Platforms Do Not Have

Every node has at least two live URLs

This is the one that surprises people arriving from other systems. Adding an alias in Drupal does not retire the internal path. /node/123 keeps answering with a 200 and the complete page, and so does every alias that node has ever been given if the update action allowed them to persist.

Core’s canonical tag mitigates the damage, and Google treats a canonical annotation as a strong signal rather than an instruction, ranking it alongside redirects and above sitemap inclusion. A strong signal is not a guarantee. The robust fix is the Redirect module’s canonical enforcement, which converts the duplicates into permanent redirects so there is nothing left to consolidate.

Taxonomy term pages multiply

Core generates a listing page for every taxonomy term. On a site with a free tagging vocabulary that means one page per tag, most holding one or two nodes, each with a templated title and no description. Several hundred of these is a thin content problem nobody deliberately created.

Decide per vocabulary rather than site wide. Categories with genuine editorial value get indexed and get hand written descriptions. Free tagging vocabularies get excluded from the sitemap and, in most cases, a noindex.

Views pagination and the ?page= trail

Every core Views listing paginates with a ?page= parameter, and each of those is a separate URL. Google’s guidance is that each page in a sequence should have its own URL and its own canonical rather than being canonicalised back to page one, and that rel next and prev are no longer used.

The Drupal specific part is that exposed filters and sorts on the same view multiply against the pager. A listing with three exposed filters and forty pages of results generates far more addressable URLs than it has content, and every one of them renders.

Facets and parameter explosion

Faceted search, usually the Facets module on top of Search API, is where this stops being untidy and becomes a crawl budget problem. Facets 3.0.6, released 1 September 2026, supports Drupal 10.1 and 11 and is used by 56,746 sites. It also carries a seeking co-maintainers notice.

Google warns that crawlers work through enormous numbers of faceted navigation URLs before they can establish that the URLs lead nowhere useful, and that this consumes both your crawl budget and their compute. Decide early which facet combinations are indexable, block the rest, and keep parameter order stable so an identical filter set always produces an identical URL.

Publication state churn

A node created unpublished, given a working title, then published a week later under a different one generates an alias at creation and another at publication. With the wrong update action both stay live and both stay crawlable. Multiply that by an editorial team and a year of output and the alias table ends up larger than the node table, which is exactly the pattern an SEO audit is looking for when it counts live URLs against published nodes.

Structured Data in Drupal

There are two routes, and the choice matters more than it appears to.

Schema.org Metatag extends Metatag to emit JSON-LD in the page head, covering more than twenty five schema types. Version 3.0.4 from 19 February 2026 supports Drupal 9, 10 and 11, and 66,363 sites use it. Like Redirect and Facets, it is seeking co-maintainers.

Its advantage is that it inherits Metatag’s whole inheritance model: defaults per bundle, tokens pulling field values, per node overrides, and editors who never see raw JSON. Its limit is that you can only express what the module models, and deeply nested schema, the kind a product needs once offers, reviews and a return policy are involved, is awkward to build out of token fields.

Hand written JSON-LD in a Twig template gives you complete control and costs you the editorial interface. On a site with a handful of templates and a developer on hand, that is often the better trade. On a site with sixty content types and a content team, it is not, because every schema change becomes a deployment.

Pick one route. The failure we see most often is both running in parallel, emitting two Article blocks that disagree with each other about the publication date.

Multilingual Drupal and hreflang

This is where Drupal genuinely earns its reputation, and it is worth stating clearly because the rest of this article is about gaps.

Core ships the language modules, and once content translation is enabled Drupal emits alternate language links on translated entities without any contributed help. Path prefixes, per language aliases and per language menus all work as delivered.

Google’s requirements for localized versions are that every version lists itself as well as all the others, that the annotations are bidirectional, and that an x-default exists as a fallback. Drupal’s translation model satisfies the first two automatically, because the alternates are generated from the translation set rather than typed by an editor. That is a real advantage over platforms where hreflang is a plugin field somebody can forget.

Two things still go wrong. The x-default value is not set for you and needs adding through Metatag or a template. And partial translation sets produce alternates that point at pages which fall back to the source language, which is a worse signal than omitting the annotation entirely.

Performance and Core Web Vitals

Drupal’s caching layers are core, they are good, and they are frequently switched off during a debugging session that nobody remembered to end.

Render caching stores fragments with cacheability metadata: cache tags describing the data a fragment depends on, cache contexts describing what it varies by, and a max age. Tags invalidate automatically when the underlying entity changes. Get the metadata wrong and you either serve stale pages or cache nothing at all.

Internal Page Cache serves complete pages to anonymous visitors. Dynamic Page Cache serves pages to any user by caching everything except the personalised parts. BigPipe, in core since Drupal 8.1 and part of the standard install profile since 8.5, then streams those personalised placeholders after the initial response has already been flushed.

For Core Web Vitals the relevant points are narrow. BigPipe improves perceived load and can worsen Cumulative Layout Shift when the placeholders it fills are not given reserved space. Largest Contentful Paint on a Drupal site is usually decided by hero images and the aggregated CSS bundle rather than by the render cache. Drupal 11.4 added Brotli compressed CSS and JavaScript asset generation when the PHP extension is available, which is a straightforward win on any site serving its own assets.

What a Major Version Upgrade Breaks

A Drupal major upgrade is not a re-platform, but it breaks search visibility in specific and repeatable ways.

Contributed modules are the usual cause. If Metatag is not ready for the target version and the site goes live without it, every meta description on the site disappears at once and nobody notices until impressions fall a fortnight later. The same applies to the sitemap module and, worse, to Redirect, because losing Redirect stops the canonical enforcement and brings every old alias back to life.

The second cause is configuration that does not survive the move. Metatag defaults, Pathauto patterns and sitemap bundle settings all live in configuration, and a rebuilt site that imports content but not configuration comes back with default patterns and different URLs for identical content.

Take a full crawl before you start, recording URL, status code, title, description and canonical for every page, then diff it against the same crawl afterwards. Our Drupal migration guide covers the version paths and the deadlines attached to them.

Where the Drupal Versions Sit Right Now

Timing changes what you should sensibly do first. Drupal 11.4.0 arrived on 1 July 2026, and the 11.4.x branch has security support until June 2027. Drupal 10, released on 15 December 2022, reaches end of life on 9 December 2026, and Drupal 12 is scheduled for the week of 7 December 2026, with a beta due in mid September 2026.

The practical consequence is that a Drupal 10 site has roughly three months of security coverage left as this is written. Any SEO work commissioned on a Drupal 10 site should be sequenced after the upgrade rather than before it, because doing it the other way round means paying twice: once to fix the metadata, and again when a module version bump changes the output.

Drupal 11.1 to 11.4 run on PHP 8.3 and 8.4, while Drupal 10 requires at least PHP 8.1. The PHP floor is very often the real blocker on shared hosting, not the Drupal work itself.

What a Drupal SEO Engagement Costs

Scope it properly first. A Drupal SEO engagement is not a report, it is configuration and template work inside a specific codebase, and the deliverable is a changed site rather than a document.

The baseline audit covers the four module stack and how it is configured, the alias and redirect tables, taxonomy and views exposure, sitemap contents, structured data output and the caching layers. On a site of a few hundred nodes that is three to five days of work. UK technical SEO day rates commonly sit between £600 and £1,200, so a technical SEO audit of that shape lands between £2,000 and £5,000 depending on seniority and site size.

Implementation is separate and usually larger. Installing and configuring Pathauto, Metatag, Simple XML Sitemap and Redirect on a live site with existing content means bulk generating aliases, building a redirect map for every alias that changes, and writing description patterns that do not collapse into duplicates. Budget one to two times the audit fee for that stage.

A multilingual Drupal site with faceted search sits above this band. UK agencies bill roughly £600 to £900 a day for Drupal work, as covered in our guide to Drupal developer rates, and an engagement with several translation sets and facet governance is realistically ten to twenty days.

Ask for the before and after crawl diff as a named deliverable. Without it there is no evidence anything actually changed.

Getting the Order Right

The sequence that works is unglamorous. Install and configure the four modules before anything else, because content decisions taken without them create rework later. Close the duplicate URL surface next, since it touches every page on the site. Then taxonomy and views exposure, then structured data, then performance. Content and links come after the technical layer is stable, never before it.

Mecanik works through this order as a technical SEO audit run against the Drupal codebase and its configuration rather than against a crawl alone, with the SEO audit service covering the implementation that follows. If you are still deciding whether Drupal is the right platform at all, our Drupal development guide and the comparison of headless and traditional CMS architectures are better places to start than this one.



Frequently Asked Questions

Is Drupal good for SEO out of the box? No. Drupal core provides path aliasing, canonical link tags and multilingual routing, but no meta descriptions, no XML sitemap, no redirect handling and no structured data. Those require the Pathauto, Metatag, Simple XML Sitemap and Redirect modules, all contributed rather than core. A stock install is unoptimised rather than badly optimised.

Which SEO modules does a Drupal site actually need? Four are effectively mandatory: Pathauto for automatic URL aliases, Metatag for meta descriptions and social tags, Simple XML Sitemap for the sitemap itself, and Redirect for redirects and canonical URL enforcement. Schema.org Metatag is the usual fifth if you want structured data without hand writing JSON-LD in Twig templates.

Why does /node/123 still work after I add a URL alias? Because a Drupal alias does not retire the internal path. Both addresses return the full page with a 200 status. Core emits a canonical tag pointing at the alias, which Google treats as a strong signal rather than an instruction, so the reliable fix is the Redirect module’s canonical URL enforcement, which converts the duplicates into permanent redirects.

Are Pathauto, Metatag and Simple XML Sitemap compatible with Drupal 11? Yes, and all four of the core stack are actively maintained. Pathauto 8.x-1.15 supports Drupal 10.2 and 11, Metatag 2.2.0 requires Drupal 10.3 or 11, Simple XML Sitemap 4.2.3 requires Drupal 10.3 or 11, and Redirect 8.x-1.13 supports Drupal 10 and 11. All four are covered by the Drupal security advisory policy.

What does a Drupal SEO engagement cost in the UK? A configuration audit covering the module stack, alias and redirect tables, taxonomy exposure, sitemap and structured data takes three to five days on a mid sized site, which at UK technical SEO day rates of £600 to £1,200 works out at roughly £2,000 to £5,000. Implementation typically costs one to two times the audit fee again.