Drupal multilingual SEO and hreflang setup

How hreflang works on a multilingual Drupal site

Hreflang is an annotation that tells search engines which version of a page to show for each language or region, and it matters when the same content exists in several translations that should rank in their own markets. Teams need it when one Drupal site serves two or more languages and search engines would otherwise treat the translations as duplicates or send users to the wrong language. Each annotation pairs a page with its equivalents, and the set only works when every page in the set references all the others, including itself. A missing return link or a page left out of the set can cause search engines to ignore the annotations for the whole group.

Drupal supplies most of the data these tags depend on. The language of each entity, the translation relationships between nodes, and the URL alias for each translation all come from the content model and the language configuration, so the site's content translation settings and language negotiation method determine what gets generated. Language negotiation by path, by domain, or by user or browser preference changes the URL that each translation exposes, which in turn changes the values that hreflang must carry. Translated URL aliases from Pathauto or manual aliases must also resolve to the right node in each language, or the annotations will point at pages that redirect or return the wrong content.

Confirm the exact output of the Hreflang module and of any sitemap options against the module documentation and the site's own rendered markup before relying on them. Check the <head> of several translated pages, look for the reciprocal links and the x-default entry if you use one, and confirm that canonical tags point at the same language version. Ask your partner or internal team to show you the rendered output on a sample of content types, since the module's settings and the sitemap's behavior can differ by version and configuration.

Choosing path, domain or subdomain language negotiation

This table compares the three common ways to give each language its own URL on a Drupal site, along with what each choice does to hreflang, aliases, canonicals and sitemaps. Read each row as a consequence of the URL structure, then check the last rows against your CDN and reverse proxy before you commit.

Decision point	Language prefix in path	Separate domain per country	Subdomain per language
Typical fit	One brand domain serving several languages with shared authority	Distinct national brands or legal entities with local domains	Language sites that need separate hosting or teams but one parent brand
Language detection in Drupal	URL path prefix is detected first in the negotiation order when path-based detection is enabled, with other methods as fallbacks	Domain-based detection maps each host to a language, so the host must be configured explicitly	Host-based detection maps each subdomain to a language, similar to domains but under one registrable domain
Alias patterns	Pathauto patterns include the language prefix, and translated aliases must be unique per language	Aliases can stay short per domain, but each domain needs its own alias set and translation workflow	Aliases follow each subdomain's language, and patterns must be reviewed for each host
hreflang consequences	Every language version lives on one host, so reciprocal hreflang links and x-default are easiest to keep consistent	Each domain's entries point to other domains, which must all be live and reciprocal	Cross-subdomain references are valid but must be listed in every subdomain's sitemap or tags
Canonical URL handling	Each translation carries its own canonical URL, and the language switcher must not canonicalize to the default language	Canonicals stay within each domain, so cross-domain duplication depends on hreflang alone	Canonicals stay within each subdomain, so confirm the Metatag base URL for every host
Sitemap layout	One sitemap can hold all languages with alternate entries	Usually one sitemap per domain, submitted separately in search console tools	Usually one sitemap per subdomain, which adds submission and monitoring work
Operational overhead	Lowest: one hosting footprint, one certificate, one redirect map	Highest: separate certificates, DNS, analytics properties and redirect rules	Moderate: wildcard or per-host certificates and host-level routing rules
CDN and reverse proxy	Confirm the CDN caches by full path and varies on the language prefix, and that purges cover every translation	Confirm each host has its own cache keys, origin routing and certificate, and that Host headers reach Drupal intact	Confirm wildcard certificates, host header forwarding and cache keys that include the host
Ask your partner or vendor to confirm	Negotiation order on your Drupal version, and whether the CDN strips or rewrites language prefixes	How the reverse proxy passes the original host to Drupal, and trusted host pattern settings	Whether your certificate and CDN plan cover new subdomains without manual steps

Hreflang module or XML sitemap: where the tags should come from

Emitting hreflang through the Hreflang module writes link rel="alternate" tags into each translatable page's head, derived from the translations Drupal already knows about. The maintenance burden sits mostly in configuration and template review: the module must be installed, its language list must match the site's configured languages, and any theme or custom route that bypasses the standard page template will miss the tags. Confirm the module's current release compatibility with your Drupal version on its project page before planning the build.

Unpublished and untranslated nodes: Confirm whether the module omits alternates that point to unpublished translations or to nodes without a translation, so that no tag references a URL returning a 404 or access-denied response.
Large sites: Per-page output scales with the page, so the cost is mainly in rendering and caching. Check that the page cache varies correctly by language and that tags are not stale after a translation is published.
Custom routes: Views, landing pages and custom controllers may not render through the same head logic. List each route type and test it separately.
Language negotiation: Tags must reflect the URL scheme in use, whether path prefix or domain, including the x-default decision.
What to test: Inspect the rendered head on a sample of translated and untranslated nodes, then validate reciprocal pairs across every language version.

The page markup approach is easiest to keep accurate when every language version is a fully managed node, so verify each sample URL before launch.

Running both the Hreflang module and sitemap alternates doubles the number of places where language relationships are declared, which increases the risk of conflicting statements. The approach can make sense during a migration or when a team wants redundancy, but it requires one clear rule for ownership. Without that rule, a page can declare one set of alternates in its head and a different set in the sitemap, and search engines may ignore both signals for that cluster.

Single ownership rule: Choose which source is authoritative for each content type and record it in the build documentation.
Consistency checks: Compare the head tags and sitemap entries for the same URLs on a schedule, and flag any mismatch in language code, region or target URL.
Maintenance cost: Two generators need two sets of updates after each Drupal or module upgrade, and both must be retested.
Language code format: Make sure both sources use the same language and region codes, including x-default, so the sets are identical.
What to test: Run a crawl that extracts both sources for every language cluster and reports any pair that appears in one source but not the other.

For most sites, a single authoritative source with a monitored check is easier to operate than two overlapping ones.

Translated URL aliases and redirects across languages

On a multilingual Drupal site, each translation of a node can carry its own URL alias, so the English, French and German versions of a page each get a distinct address that search engines can index. The decision that matters most is the alias pattern for each language. Pathauto patterns, language-specific path prefixes and any manually entered aliases should be fixed before launch, because every alias that gets indexed becomes a URL other sites and bookmarks depend on. Changing a pattern later does not rewrite old aliases on its own; it only affects content that is re-saved or regenerated, so the team needs a plan for which URLs move and which stay put.

Missing translations and alias changes are the two cases where sites most often leak rankings. When a translation does not exist, Drupal may serve the default language or return a 404 for the language path, and a crawler can then see thin or duplicated pages. Decide in advance whether untranslated nodes should be hidden from the language path, shown in the source language, or redirected to it, and make that choice consistent with the hreflang output. When an alias changes after launch, the Redirect module can record the old path, but the team should confirm that it creates redirects for translated aliases as well as the default one, and that the redirect targets the same language version rather than a different translation.

Plan redirects for old language-specific URLs as a map, not as an afterthought. List every indexed URL by language, including legacy paths from a Drupal 7 site or an older language prefix scheme, and map each to its current translated alias. Test this in a staging copy loaded with your own content, not with sample pages, and check that each language path resolves to its own translation and that no redirect loops between language prefixes. Ask your implementation partner to show the staging results for alias generation, missing-translation behavior and redirect matches before any production cutover.

Setting up hreflang on a Drupal site, step by step

This sequence takes a multilingual Drupal site from an agreed language list to hreflang annotations that search engines can read and check. Each step closes with a verifiable output so the team knows it can move on.

Confirm the language list and default language
The site owner, content lead and SEO lead agree the full list of languages, the default language and which language versions are live at launch. Record each language with its intended URL form, such as a language prefix or country domain, and note any language that will share content with another. The step is done when this list is signed off in writing and every language has a named owner for its content. Hreflang annotations are only as accurate as this list, so any later change should start here.
Choose the language negotiation method
The Drupal team decides how the site detects and switches languages: by URL path prefix, by domain, or by a combination configured under the language negotiation settings. The choice depends on hosting, brand structure and whether each language needs its own domain for search. The lead developer documents the decision and the URL pattern for each language. The step closes when a test request to each language URL resolves to the expected language without redirect loops.
Configure content and interface translation
The Drupal developer enables the Language and Content Translation modules, adds each language, and marks which content types, taxonomy terms and menus are translatable. Editors confirm that translated nodes are created as separate translations with their own fields rather than copies left in the source language. Interface strings are translated through the translation UI or an approved translation workflow. The step is done when a sample page exists in every language and the admin pages show each translation's status.
Set translated URL aliases
The team configures URL aliases so each translation has its own path in its own language, typically with Pathauto patterns that include the language token or with manual aliases where editors need control. Slugs for the same content should be consistent enough that a reviewer can match them, but translated words belong in the translated path. The check is to list aliases per language and confirm that no translation falls back to a system path like /node/123, and that no two languages share an identical alias for different content.
Enable and configure hreflang output or sitemap entries
The SEO lead chooses how alternate links are published: the Hreflang module that outputs link elements in the page head, or sitemap entries generated by an XML sitemap module with language alternates. Only one source should emit annotations for the same URL to avoid conflicting signals. The developer maps each translation to its language code and confirms that every page lists all of its alternates, including itself. The check is a view of the rendered page source where each language version contains alternate links to every other version, and the links reciprocate.
Set canonical and x-default handling
The team sets each translated page to be self-canonical, so every language version points to its own URL, and decides whether a language selector page or a default-language URL should receive the x-default annotation. Canonicals should never point a translation at the default language, because that tells search engines to drop the translation. The check is to inspect the canonical tag and x-default link on a sample of each content type and confirm they match the agreed rules.
Verify status codes, reciprocity and sitemap output
The SEO lead and developer crawl a representative sample of pages in every language and confirm that each URL returns its own status code, normally 200 for live content and a planned redirect for retired content. They validate that every alternate in the markup or sitemap points to a URL that returns 200 and links back. Sitemap entries are checked against the rendered pages. The step closes when the crawl report shows no missing reciprocal links, no alternates pointing to redirects or errors, and no translation that is missing from the sitemap.
Monitor and retest after each content release
The operations team adds the hreflang checks to the release checklist so that new languages, new content types and alias pattern changes are tested before they go live. Search Console or an equivalent tool is watched for hreflang errors after publication. The team keeps the language list and mapping documented so a new editor or developer can follow the rules. The step is done when the checks run as part of each release and the documentation names an owner for each language.

Hreflang errors that break language pairs

Hreflang annotations fail quietly. A page can look correct to an editor while the set of language pairs is incomplete, contradictory or pointing at the wrong URL. The cards below cover the errors we see most often on Drupal sites, each with the symptom to look for and the check to run before you trust the output.

Non-reciprocal annotations

Every language version must list every other version, and each of those versions must list it back. If the English page points to the German page but the German page does not point to English, the pair is unreliable. On Drupal this often happens when a translation is added to some content types but the hreflang source (the Hreflang module, a sitemap generator or a custom alter hook) only reads annotations from the default language. Check: crawl each language version and confirm that the full set of alternates appears on every page. Confirm current search engine guidance on how reciprocity is evaluated.

Wrong language or region codes

Hreflang values must be valid language codes, optionally followed by a region code, such as en-US or pt-BR. Drupal language codes are not always the same as the values you need, for example when a site uses a custom language code for a regional variant or a Drupal language is named zh-hant with a region expected elsewhere. A typo or a generic code such as en used where a region was intended can silently point search engines at the wrong audience. Check: compare the rendered hreflang values with the language list at /admin/config/regional/language and with the intended market list.

Missing self-references

Each page should include an hreflang entry that points to itself, in addition to its alternates. Sets built by hand in templates or by partial modules often omit the current language because the code assumes the page is already known. On a multilingual node, a missing self-reference can appear only on the untranslated fallback view or only on the default language. Check: view the source of one page per language and confirm the self-reference matches the canonical URL for that language.

Canonical and hreflang disagreement

Hreflang targets should be the URLs you want indexed for each language. If the canonical tag on a French page points to the English version, or a faceted or paginated URL is canonicalized to a different host, the hreflang entry and the canonical tag contradict each other. Metatag defaults and Pathauto patterns applied per language can produce this without anyone choosing it. Check: for each language version, confirm that the canonical URL is identical to the URL listed as its own hreflang entry.

Redirects inside the set

An hreflang target that redirects is a weak target. This often follows a language-prefix change, a translated alias added after launch or a domain move that left old alternates in place. The redirect chain may also differ by language, so one pair works and another does not. Translated URL aliases make this more likely when editors rename a path and the old alias stays behind. Check: request every URL in the set and confirm each returns a direct 200 response with no redirect, and that the final URL matches the one listed in the annotation.

Cached pages serving another language

A reverse proxy, CDN or page cache that ignores the language context can serve a German page to an English visitor or emit the hreflang block for the wrong node. The symptom is intermittent: the annotations are correct on a cold request and wrong on a warm one. Drupal cache contexts for language and URL, and the cache tag purging used by your proxy, decide whether this happens. Check: request the same URL several times through the production cache path, with the language prefix or domain varied, and compare the head section against a direct origin request.

What buyers ask before setting up multilingual SEO

How much effort does multilingual SEO on Drupal take?

Effort depends on how many languages you publish, how much content each language carries, and how much of that content is translated rather than machine-generated or left in the default language. The alias strategy matters as much as the count. Translated URL aliases for every content type, taxonomy term and menu item multiply the rules a team must design, test and maintain. Sitemap size also grows with each language and each translated node, which affects how hreflang entries are generated and checked. Ask any partner to list each language, each content type that needs its own alias pattern, and the expected sitemap scope, then tie the estimate to those items in the quote.

How long does a multilingual hreflang project take?

The timeline is set by decisions and content, not by configuration alone. Language and domain decisions must be made first, then the language negotiation method, the alias patterns, and the hreflang source (the Hreflang module or sitemap entries). Translation workflow and content readiness often set the pace, because hreflang pairs only work when every language version exists and points to its counterpart. Ask for a written schedule with a named dependency for each phase, including who signs off on language decisions and when translated content is due.

What does our internal team need to provide?

Three inputs are usually the critical path. First, language decisions: which locales you serve, whether each uses a path prefix or its own domain, and which language is the default. Second, a translation workflow: who translates, who approves, and how translated aliases are reviewed before publication. Third, access to Google Search Console and any other search engine webmaster tools for each property, so that indexing and hreflang errors can be checked after launch. Confirm in the quote which of these your team owns and which the partner expects to request.

Can our in-house team set this up without outside help?

Yes, if the team has Drupal site-building experience, has worked with the language and content translation modules, and can test hreflang output in a staging environment. The hard parts are usually consistency and upkeep: keeping alias patterns, sitemap settings and language switchers aligned as content types grow, and checking each language version for correct canonical and alternate tags after every release. Compare the internal skill set against that ongoing workload. A partner is most useful for the initial design, a documented configuration, and a test plan your team can repeat.

What costs are one-time and what recurs after launch?

One-time work includes the language and alias design, module configuration, custom code if any, the redirect map for moved URLs, and the initial verification. Recurring costs come from translation of new content, alias and sitemap checks after structural changes, Drupal core and contributed module updates, and search console monitoring. Core and module updates follow the Drupal release cadence, so the upkeep budget should cover at least one planned update cycle per year. Ask the quote to separate build work from support, and to state what happens when you add a language later.

How does a quote follow from a written scope?

DeployOpen works from a written scope, and most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that document. To compare proposals, ask each vendor for the list of languages, the content types and taxonomies covered, the language negotiation method, the sitemap approach, the redirect and alias rules, the test cases used for hreflang validation, and the handover documentation. Quotes that cannot name these items are hard to compare, whatever the total.

Does an outside team also check that hreflang works after launch?

Launch checks should confirm that each page declares alternate language versions, that each alternate points back to its counterpart, and that the default language is marked correctly. Ask how the partner will verify these on a sample of pages and on the full sitemap, and how indexing errors will be reported to you. Ongoing checks are usually needed after new languages, new content types or alias changes. Note that a partner prepares the site and reports on its signals, but search engines decide how pages rank.

Security and operations for multilingual sites

Multilingual Drupal sites add operational surfaces that a single-language site does not have: translator accounts, language-specific caches, aliases and sitemaps. The cards below name the decision each surface requires and the check to schedule so that hreflang signals stay accurate after launch.

Translator and editor access by language

Decide which roles can create, edit and publish translations for each language, and whether a translator can see unpublished content in other languages. Drupal's content translation and permission settings control this, so review role grants per language after every new language is added. Schedule a quarterly review of translator accounts, and remove access for contractors when a translation project closes. Ask your team whether translation vendors need named accounts or access through a managed workflow.

Unpublished translations in sitemaps and markup

A translation that is unpublished, in draft or missing should not appear in the XML sitemap or as an hreflang alternate on other language versions. Confirm how your sitemap module and hreflang setup treat unpublished and untranslated nodes before launch. Add a check that crawls each language version and compares the hreflang output with the sitemap entries. Pages that point to missing alternates can cause search engines to ignore the signals.

Language-aware cache rules

CDNs and reverse proxies must vary cached responses by language, or a visitor may receive a page with the wrong hreflang tags or interface language. Decide whether language is set by path, domain or cookie, and make the cache key match that choice. Confirm that the cache varies on the request headers Drupal uses for language negotiation and that cache tags purge all language versions of an entity together. Test with requests from each language path after every cache configuration change.

Change control for alias patterns

Changing an alias pattern for one language can move URLs that search engines already index, and translated aliases may diverge from the English structure in ways that break the reciprocal hreflang pairs. Treat alias patterns as controlled configuration: record each change, the affected content types and languages, and the redirect plan. Review the alias list for duplicates after each change, since two entities sharing a path in one language is a common fault on multilingual sites.

Per-language 404 and redirect loop monitoring

Errors on one language version often go unnoticed because the default language receives most of the traffic. Set up 404 and redirect reporting that groups results by language prefix or domain, and alert when a language's 404 count rises after a release. Redirect loops between language negotiation and alias redirects are a frequent fault after a configuration change, so include a loop test in the release checklist. Ask your team who receives these alerts and how quickly they are triaged.

Search Console and sitemap credentials

Access to Search Console properties and sitemap submission endpoints should be granted to named people or service accounts, not shared logins. Decide who can submit sitemaps, who can change property ownership and where verification tokens are stored. Keep these credentials in your secrets manager rather than in site configuration exported to version control. Review access when staff or agency contacts change, and confirm that each language domain or subdirectory is covered by a property you control.

What to confirm in your environment before committing

Confirm the Drupal core version first, because it decides which Hreflang and sitemap module releases you can use. Ask the Drupal developer to check each contributed module's project page for its supported core range before the plan is written, and to record the exact versions that will be installed. If sitemap output is generated by the sitemap module rather than the Hreflang module, confirm which one owns the hreflang entries so that two modules are not both emitting alternates. DeployOpen scopes these version checks and the compatibility review in the written plan, so the decision is recorded before build starts.

Confirm how the translation workflow and content moderation interact with publishing. Ask the content lead whether translations are created in place or as separate content, whether each language moves through its own review state, and whether an unpublished translation can still appear in the sitemap or the language switcher. Ask the Drupal developer to confirm how translated URL aliases are generated for each language, since an alias that changes after publication can leave an alternate pointing at a dead URL.

Confirm with the hosting provider and the CDN team that the language variant survives every request. Ask whether the reverse proxy or CDN caches pages without varying on the language path, domain or Accept-Language header, and whether the number of languages and regional variants in scope matches what the infrastructure serves. Finally, ask the SEO lead which search engine webmaster tools will receive the sitemap, how they report hreflang errors, and who reviews those reports after launch. Agree on that owner and on the frequency of checks in the written plan.

How DeployOpen scopes and verifies multilingual SEO on Drupal

DeployOpen plans and implements self-hosted Drupal sites inside your own infrastructure, including the hreflang, language negotiation and translated URL alias work that multilingual search depends on. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory every language, country variant and content type that needs its own indexable URL before choosing a tool.
Decide between the Hreflang module and sitemap-based hreflang entries, and record why in the written scope.
Document language negotiation by path or domain, with the URL structure each language will use at launch.
Agree which translated URL aliases, redirects and fallback rules are in scope, and which content stays untranslated.

How we build

Configure language negotiation and translated Pathauto patterns so each language generates its own stable, readable URLs.
Generate reciprocal hreflang annotations, including x-default, and confirm every alternate points to a live, canonical URL.
Test hreflang output on sample nodes, taxonomy terms and listing pages across every language and content type.
Review how translation fallbacks, untranslated entities and language switchers affect canonical tags and indexing signals.

How we hand over

Deliver a written configuration record covering language settings, URL patterns, hreflang source and sitemap rules.
Provide a verification checklist that editors and site owners can rerun after adding a language or translation.
Document the steps for adding a new language, including alias generation, redirects and hreflang checks.
Walk your team through the test results and open issues so ownership of each remaining item is clear before handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover re-testing hreflang output after Drupal core or contributed module updates.
Confirm with DeployOpen during quoting which environments, languages and release windows the retainer will cover.

Drupal multilingual SEO with hreflang