International SEO Checklist: Hreflang & Canonicals
Check language URLs, hreflang return links, canonicals and localized content. Use an international SEO checklist with a worked example and release checks.

Your German product page is live, but visitors keep landing on the English version. Before adding more tags, check the path a visitor and a crawler actually follow. A correct alternate link cannot repair a failed page, an unrelated translation or a language selector that drops people on the homepage.
This international SEO checklist helps you review an existing multilingual or regional website before a release. Work through one group of equivalent pages at a time. Keep the requested URL, final URL, language, intended audience and observed result together. A single-language website serving a worldwide audience does not need invented language versions just to complete this checklist.
1. Map the pages that belong together
Make one row for each real version of the same visitor task: the same product, help article or service. Record its language and any meaningful regional differences, such as availability, currency or delivery terms. Assign a reviewer who can read that language. A URL folder is a label, not proof that the page is translated or suitable for its intended market.
Keep unrelated pages out of the group. An English product page and a German category page may both mention the product, but they do not give the visitor the same experience. If a translation is missing, record it as missing; do not manufacture an equivalent URL in the audit.
2. Run the international SEO checklist
| Check | Evidence to retain | Decision before release |
|---|---|---|
| Page availability | Requested URL, every redirect hop, final HTTP status and document type. | Resolve failed destinations before reviewing their content or alternate links. |
| Language and regional purpose | The actual page text, product details and intended audience. | Have a fluent reviewer confirm that the page serves the same task and uses appropriate local wording. |
| Indexing intention | Robots directives and the team’s decision about whether this page belongs in search. | Investigate unexpected exclusions. Preserve deliberate private or unavailable versions. |
| Canonical destination | The declared canonical, its final response and its relationship to this version. | Review a translated page pointing at the original language before assuming that consolidation is intended. |
| Alternate-page group | Every hreflang value and destination in the chosen implementation. | Check valid language codes, optional region codes, self-reference and reciprocal links. |
| Language selector | The links visible to a visitor on each version. | Switch to the equivalent page when one exists. Make the fallback clear when it does not. |
| Internal discovery and sitemap | The links and sitemap entries that introduce each approved version. | Replace obsolete destinations and investigate important versions with no measured discovery path. |
| Local reading and task completion | A mobile walkthrough of headings, text, forms, downloads or checkout where applicable. | Fix untranslated instructions and broken actions. Do not require commerce checks on a site without commerce. |
3. Check hreflang without confusing it with translation
Google supports alternate-page annotations in HTML, HTTP headers or XML sitemaps. Pick a maintainable method. Each version should identify itself and its equivalents using fully qualified URLs. Check return links in both directions. Use a language code such as de, or a language plus region such as en-GB; a country code alone is insufficient. An x-default page can provide a fallback for unmatched languages. Hreflang helps identify alternatives; it does not translate the content or determine the page’s language for Google.
For an HTML implementation, retain the link elements from the head of the fetched document. If JavaScript changes them, keep the rendered evidence separately. A screenshot of translated text does not prove that the source contains the intended alternate links. See Google’s localized-page guidance for implementation rules and examples.
4. Work through a small example
Illustrative example: a software company has English and German versions of a setup guide. The English page lists both versions, but the German page lists only itself. The German language selector also sends visitors to the English homepage.
These are two separate tasks. The developer repairs the alternate-page group and verifies the return links. The content owner changes the selector to the equivalent English setup guide and checks that the link works. A German-speaking reviewer checks that the instructions still match the product. The team retains the original tags, links and observations so another person can compare the release.
If the English guide has been removed, adding a return link to that failed URL is not a repair. First choose a real equivalent destination or remove the obsolete relationship after review. If a request times out, label its evidence unavailable and retry a bounded check before drawing a conclusion.
Two repairs, two acceptance checks
Alternate-page relationship
English guide → German guide
German guide → English guide
Check: both pages identify the same equivalent pair.
Visitor’s language switch
German guide → English guide
Check: the visitor keeps the setup task instead of restarting on the homepage.
Illustrative route diagram. Matching alternate tags and a useful visitor link are separate checks; neither guarantees search traffic.
5. Verify the release with the same page group
- Save the exact before-state, intended change, owner and affected URLs.
- After deployment, fetch each changed page and its linked equivalents freshly.
- Compare final responses, canonicals, alternate links and visitor actions with the intended result.
- Retain failed and unavailable checks beside successful checks.
- Record the deployment date and affected pages before reviewing later search results.
In LLMIC, begin with a scoped website audit and inspect the affected page records. Keep the original crawl and a fresh post-release check. For canonical conflicts, use the canonicalization diagnosis guide. Use independent checks for anything the available crawl did not measure. A completed task and a verified technical change remain separate facts.
6. Measure the right result
Review each changed page and its relevant queries in Search Console over comparable mature periods. Segment by country when it helps answer the market question; a country is not the same as a visitor’s language. Record clicks, impressions, CTR and average position separately. Small samples may leave the result inconclusive.
Use GA4 to review a defined visitor task, such as a configured download or enquiry event, only after verifying its meaning and collection. Keep the property, hostname, traffic population, dates and timezone consistent. A technically correct release may show no measurable traffic movement, and later movement alone does not establish that the release caused it.
Questions before you sign off
Does every worldwide website need hreflang?
No. Start with the actual language or regional versions you maintain. Do not invent alternates for a single-language site.
Is a valid alternate tag enough to approve the page?
No. Check its destination, equivalent content, canonical intention and the visitor’s ability to complete the task.
What if a language version cannot be checked?
Keep that version unverified. Record the access or response failure and the next check instead of including it in a pass rate.
Sources and review scope
Sources and measurement notes
Google’s localized-version documentation was reviewed on 13 October 2026. The checklist and example are an editorial review method, not a customer result or a promise of indexing, rankings or traffic. Continue with the international SEO diagnosis guide when a check fails, and retain the evidence needed for a specific repair.
Check the website behind the idea.
Use LLMIC to crawl pages, review the evidence and organise the next actions in one native Mac workspace.