EN 
ESHreflang Implementation Checklist for Multilingual Websites
Hreflang works when every indexable language or regional page points to itself and to every genuine alternative, using the same complete set of absolute URLs. It does not translate a page, force a ranking, or replace canonicalisation. Its job is narrower: help Google understand which URLs are equivalent versions for different languages or regions and show the most appropriate one in search.
The safest implementation starts with a page-to-page locale map, not with a plugin setting. Decide which pages are true alternatives, confirm that each one can be crawled and indexed, then publish one consistent annotation method and test the reciprocal relationships. The checklist below follows Google Search Central’s documentation for localized page versions, multilingual and multiregional sites, and canonicalisation.
1. Decide whether you need language or language-region targeting
Use a language code when the same page serves speakers of a language broadly, such as en or de. Add a region only when the page is genuinely adapted for that market, for example en-GB and en-US. Currency, delivery rules, legal terms, product availability and local terminology can justify regional versions; a duplicated page with only a different folder name usually cannot.
Language values use ISO 639-1 codes and optional regions use ISO 3166-1 alpha-2 codes. Do not invent combinations such as uk-en: the language comes first, so British English is en-GB. Script subtags can be useful where a language is written in more than one script.
Before implementation, create a simple matrix with one row per page concept and one column per locale. A row might contain the English, German and Spanish versions of the same service page. Leave a cell empty when no equivalent page exists. Hreflang should describe real alternatives, not create an impression of localisation that the content does not support.
2. Give every locale its own stable URL
Google recommends separate URLs for language versions. Subfolders, subdomains and country-code domains can all work; the right choice depends on markets, authority, infrastructure and the team’s ability to maintain the setup. URL parameters are harder to manage and are not recommended as the main locale structure.
Avoid serving different languages at one URL based only on cookies, IP location or the browser’s Accept-Language header. Googlebot may not discover every variation, and users can lose control of the page they want. Keep a visible language or region selector with normal crawlable links. If you suggest another version, let the user choose instead of forcing an automatic redirect.
3. Choose one annotation method you can maintain
Google supports three equivalent methods:
- HTML links in the document
<head>for ordinary web pages; - HTTP Link headers for non-HTML files such as PDFs;
- XML sitemap annotations when a central page matrix is easier to maintain than template output.
Using all three does not add a search advantage and creates more places for the sets to disagree. Choose the method that can be generated from one reliable source of truth. For many CMS sites, HTML is easiest to inspect. For large catalogues, sitemap-based annotations may be easier to validate at scale.
4. Publish a complete, reciprocal cluster
Each member of a locale cluster must list itself and every other member. The set should be identical on all versions. For an English, German and Spanish group, the English page points to all three, the German page points to all three, and the Spanish page points to all three.
<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/service/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/service/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/service-selector/" />Use fully qualified HTTPS URLs. Keep protocol, host, path and trailing-slash rules consistent with the final canonical destination. A missing return link can cause Google to ignore the relationship because the claimed alternative does not confirm it.
5. Use x-default for a genuine fallback
x-default is appropriate for a locale selector, a global page, or another fallback intended for users whose language or region is not explicitly listed. It is not a substitute for a missing English version and it does not need to be the homepage. Point it to the page that genuinely handles unmatched visitors.
6. Align hreflang with canonical, robots and redirects
Every localised URL normally needs a self-referencing canonical. Do not canonicalise translated pages to the English page simply because the topic is the same. Different-language pages are not duplicates when their main content is translated.
For same-language regional pages with substantially similar content, choose the preferred canonical carefully and retain the relevant hreflang relationships. Google treats canonical signals as hints, so internal links, sitemaps, redirects and annotations should tell the same story.
Every URL in the set should return a final HTTP 200 response, be allowed by robots.txt and be indexable. Remove URLs that redirect, return errors, carry noindex, or have been retired. Do not point annotations through redirect chains.
7. Localise the page, not only the navigation
Google determines a page’s language primarily from visible content. Translating only the header, footer and buttons while leaving the main article or product description unchanged is not a complete language version. It can also create several low-value URLs that compete with one another.
Review the title, headings, body copy, navigation, forms, validation messages, image alternatives and relevant legal or commercial details. A useful localised page should answer the same core intent while using language and examples that make sense in its market. This is why international SEO is not just a tagging exercise: architecture, indexation and content quality have to agree.
8. Validate before and after release
Start with a sample from each template: homepage, service page, category, product, article and any paginated or filtered type. For every sampled cluster, verify:
- one indexable final URL per intended locale;
- valid language and optional region codes;
- self-reference and complete return links;
- the same URL set on every member;
- absolute canonical URLs that do not conflict;
- no redirects, errors or blocked destinations;
- substantially localised visible content;
- crawlable language-switcher links.
After deployment, crawl the site and compare clusters programmatically rather than checking tags one page at a time. Review Google Search Console for indexing changes, unexpected canonical choices and locale pages receiving impressions in the wrong market. Monitoring is essential after migrations, CMS releases and catalogue changes because a template or routing change can break thousands of annotations at once.
Common hreflang mistakes to avoid
The most frequent failures are incomplete return links, unsupported codes, annotations pointing to redirects, and blanket generation that maps every page to a homepage in another language. Another common error is adding a locale URL before its main content has been translated. Treat the locale matrix as managed content: when a page is published, moved or removed, update its whole cluster.
Hreflang also cannot repair weak architecture. If locale pages are hidden behind scripts, orphaned from internal navigation or excluded from sitemaps, correct annotations alone will not make the implementation robust. A broader migration SEO checklist is useful when URLs or platforms are changing, while ongoing checks belong in a website maintenance routine.
How VOWE approaches multilingual SEO
Can VOWE review hreflang on an existing multilingual website?
Yes. VOWE’s international SEO service includes technical and indexation review, including canonicals, redirects, sitemaps and hreflang. The review connects those signals with the site’s real languages, markets and commercial pages.
Does VOWE recommend domains, subdomains or subfolders?
VOWE compares search demand, current authority, content capacity and technical constraints before recommending an international architecture. The right structure depends on the markets and on what the team can maintain consistently.
Is hreflang enough for international SEO?
No. VOWE treats hreflang as one part of multilingual and multiregional optimisation. Research, page intent, localised content, internal linking, indexation and measurement in Google Search Console and analytics also shape the roadmap.
If your locale structure has grown without a controlled page map, tell VOWE which languages and markets you support. A focused review can identify conflicting signals and turn them into an implementation plan.
