A hreflang SEO audit helps confirm that search engines can connect the right language or regional version of each page without conflicting signals. This reusable checklist covers hreflang tags, localized URLs, canonicals, redirects, XML sitemaps, validation errors, and a practical remediation workflow for international websites.
Overview
Hreflang tells search engines which alternate versions of a page target particular languages or regions. It does not translate content, redirect visitors, or replace a canonical tag. A reliable international SEO implementation usually requires several signals to agree:
- Each localized URL returns a successful, indexable response.
- Each page identifies its valid language and, where relevant, regional alternates.
- Alternate pages reference one another with reciprocal hreflang annotations.
- Canonicals point to the preferred URL for that page version rather than collapsing every locale into one URL.
- Internal links, XML sitemaps, redirects, and metadata use the same URL and locale structure.
Begin with a representative URL set rather than checking pages at random. Include the homepage, important commercial pages, templates with different URL patterns, recently launched translations, and pages with known indexing problems. Export the URLs and their expected language-region targets into a spreadsheet so the audit tests implementation against an agreed source of truth.
For larger sites, combine a crawler with server-log analysis and search performance data. A crawl can expose markup and response issues, while logs show whether search-engine crawlers are repeatedly visiting redirects, blocked URLs, or obsolete locale paths. See the SEO log file analysis workflow and the crawl budget optimization checklist for related technical checks.
Checklist by scenario
1. Validate the hreflang relationship
- Confirm every target URL is the intended equivalent page, not merely a page in the same category.
- Check that the language code and optional region code match the page's actual audience.
- Use the correct format, such as
en,fr, or a language-region combination such asen-GB. Do not create arbitrary codes for marketing regions. - Check that each alternate includes a link back to the source page. Hreflang relationships should be reciprocal.
- Include the page itself in its own alternate set when the implementation method and platform support that pattern.
- Use
x-defaultonly for a genuine fallback experience, such as a language selector or general international page.
2. Check canonicals and localized URLs
- Verify that each locale page has a canonical URL that represents that page version.
- Flag cases where every language page canonicals to the default-language URL without a clear reason.
- Ensure canonical URLs use the preferred protocol, host, casing, and trailing-slash convention.
- Compare canonical targets with hreflang targets. A hreflang URL that canonicalizes elsewhere can create conflicting signals.
- Confirm that localized URLs are not blocked by robots.txt, a noindex directive, authentication, or an accidental staging rule.
3. Test redirects and status codes
- Request every hreflang URL as a crawler would and record status code, final URL, and redirect chain.
- Replace links to redirected locale URLs with the final destination.
- Remove hreflang references to deleted pages, soft error pages, and URLs that require a session or location-based redirect.
- Check that the final destination preserves the intended language and region rather than redirecting all visitors to one default page.
- Investigate server errors and inconsistent responses between desktop, mobile, and different request headers where relevant.
4. Audit XML sitemaps
- Include only preferred, indexable URLs in the main URL set.
- If hreflang annotations are implemented in XML sitemaps, confirm every alternate is valid and reciprocal in the sitemap data.
- Keep sitemap URLs consistent with canonical tags and internal links.
- Separate locale sitemaps when that makes ownership, deployment, or troubleshooting clearer.
- Review sitemap processing and indexing coverage in the site's search-console reporting.
Validation table
| Check | Pass condition | Typical failure | Action |
|---|---|---|---|
| Language-region code | Code follows the platform's supported language and region conventions | Typo or invented regional code | Normalize the code and update every reference |
| Return tag | Target page links back to the source page | Missing reciprocal reference | Regenerate the complete alternate set |
| Canonical | Canonical supports the intended locale URL | All locales canonicalize to one language | Review locale-level canonical rules |
| Status and redirects | Target returns a successful, final response | Redirect, 404, 5xx, or redirect loop | Repair the URL or remove it from the set |
| Indexability | Target is crawlable and eligible for indexing | Robots block or noindex directive | Resolve the restriction or exclude the target |
| XML sitemap | Sitemap contains the preferred URL set | Old, duplicate, or redirected locale URLs | Regenerate and resubmit the sitemap |
What to double-check
Inspect the rendered HTML, not only the CMS fields. JavaScript, edge rules, plugins, or template logic can alter the final links after publication. Confirm whether hreflang appears in the HTML head, HTTP headers, or XML sitemaps, then use one consistent ownership model where possible.
Check locale coverage at the template level. A product page may have translations while its category, navigation, or checkout links still point to the default market. Review language selectors, internal links, structured data URLs, Open Graph URLs, and pagination for the same host and locale conventions.
Record errors in a remediation worksheet:
| Source URL | Expected alternate | Observed issue | Owner | Priority | Retest date |
|---|---|---|---|---|---|
| Example locale page | Expected language-region URL | Missing return tag, redirect, or canonical conflict | Team or system owner | High, medium, or low | Planned validation date |
Prioritize issues affecting many URLs, recently launched markets, key revenue pages, or complete locale clusters. After a fix, recrawl both sides of the relationship and retain the before-and-after results.
Common mistakes
- Using hreflang as a translation substitute: The annotation helps identify an audience; it does not create localized content.
- Tagging unrelated pages: Alternate URLs should satisfy the same underlying intent, even if their copy and offers differ by market.
- Forgetting return tags: A one-way declaration is incomplete and often produces validation warnings.
- Mixing URL conventions: Switching between HTTP and HTTPS, alternate hosts, or inconsistent trailing slashes makes relationships harder to process.
- Canonicalizing every market to the default: This can undermine the purpose of maintaining distinct locale pages.
- Leaving old locale URLs in templates: A migration can fix the sitemap while navigation and hreflang still reference retired paths.
- Testing only one page: Validate representative templates, edge cases, and the complete cluster for every important market.
When to revisit
Run this hreflang SEO audit before launching a new translation or regional site, during a domain or CMS migration, after changing URL rules, and after releasing a localization template. A quarterly review is a practical baseline for established international sites; increase the frequency when locale pages change frequently or several teams publish independently.
Recheck supported language-region code guidance and search-engine documentation whenever platform behavior or implementation methods change. Also review the audit after significant crawl or indexing anomalies appear in search-console reporting. For measurement context, connect the findings to the site's GA4 and Google Search Console SEO reporting workflow.
For the next audit, export a fresh URL sample, run the validation table, assign each failure an owner and priority, fix the highest-impact patterns first, and recrawl the affected clusters. Keep the worksheet with the release notes so the next localization launch starts from verified URL rules rather than assumptions.
