Hreflang Audit: Language and Region Tags Guide

When a site has Turkish, English, or country-specific versions of a page, search engines need a clear signal about which URLs are localized alternatives. `hreflang` annotations describe that relationship and can help Google Search serve a version that better matches a user’s language or region. They are not a ranking boost, redirect instruction, or indexing guarantee by themselves. A URL’s content, accessibility, and canonical choice still matter. This guide provides a repeatable way to audit hreflang and repair broken relationships.

Start by defining groups of pages that are genuinely alternatives; do not connect every URL to every language. Then verify language and region codes, self-referencing and reciprocal links, absolute URLs, canonicals, and the implementation method. Finally, test the pages in production. For the editorial side of translation and localization, see our content localization guide; for URL discovery and sitemap inventory, see our XML sitemap audit.

What hreflang signals, and what it does not

Hreflang tells Google that specific page URLs are alternatives by language or region. For example, a Turkish product page and English pages for the UK and US may describe the same product for different audiences. Google can use this signal to try to show a more suitable version. The annotation does not automatically redirect visitors to another URL; that would require a separate user-facing navigation or redirect decision. A visible language selector remains useful so visitors can choose a version themselves.

Hreflang is not Google’s primary method for detecting a page’s language. Google analyzes the content, and neither an HTML `lang` attribute nor a hreflang value alone proves what language a page contains. Fully translated pages can be alternatives, as can forum pages with the same main content and a translated template, or pages with small regional differences in the same language. The signal does not make thin or duplicate content valuable. Each localized version should still provide useful information for its intended audience.

Start by defining the alternate URL group

The most important editorial decision in a hreflang audit is which pages truly are alternatives. Turkish and English descriptions of the same product are usually appropriate. A blog post is not automatically an alternative to another post on a similar topic if it has not been translated. Pages with country-specific pricing, shipping, or availability may be regional versions of the same product; they can also remain separate if their topic or user need differs. Assign each page group a content identity, then list its real language and region variants under that identity.

Add a page ID, language/region, complete URL, response status, canonical target, hreflang alternatives, and sitemap membership to a mapping sheet. Use a CMS language group or translation ID if it reliably represents the relationship; do not infer it only because URL slugs look alike. Do not label a page with no translation as an alternate to a nearby general category. Include only existing, accessible variants, and update the whole group in a controlled way when a new language version is published.

Use valid language and region codes

The language value should be a supported standard language code; an appropriate country or region code can be added when needed. For example, `tr` targets Turkish, `en` general English, `en-US` US English, and `en-GB` English for the United Kingdom. Use the correct two-letter region format; a common mistake is `en-UK`, where `en-GB` is the correct form. If you only target a language, do not add an unnecessary region. Normalize codes as data and run automated checks for case differences and misspellings.

`x-default` can identify a default page for users whose language or region is not covered by another value. This is often a language selector or general market page, but it is not mandatory for every site. The x-default destination must also be accessible and consistent with the group. Match the code to the actual page language: marking English content as Turkish still sends a misleading signal even if the page itself is valid. Avoid forcing a permanent IP-based redirect; provide clear links to alternatives instead.

Check self-referencing and reciprocal links

Every page in a hreflang group should list itself and all the other variants. If the Turkish page points to the English page but the English page does not link back, the relationship is incomplete. Inspect the full alternate set in the `<head>` of every URL, not just the homepage. Each member of a group should report the same URL set. When you remove a variant or add a language, update the annotations for every member together.

A group of two pages has two links on each page: one to itself and one to the alternate. A group of three languages has three links on every page. Do not omit the self-reference; listing only the other languages leaves the mapping incomplete. If a page has intentionally not been translated, do not make it look like a member of the group. Generate the annotation from publication state and translation relationships so that drafts or removed URLs cannot leak into the set.

Choose one implementation method

Google supports localized versions through alternate links in the HTML `<head>`, HTTP `Link` headers, or XHTML links in an XML sitemap. From Google’s perspective, the methods provide equivalent signals; implementing all three usually adds maintenance without search benefit. HTML head links can be practical for most HTML pages. HTTP headers may suit non-HTML files such as PDFs. XML can work well for a large URL inventory managed centrally through sitemap generation.

Document the source of truth after choosing a method. If a CMS plugin generates head links while a deployment system manages sitemap annotations, two different lists can conflict. Identify which translation data produces the group. After a theme or plugin update, crawl for duplicate or inconsistent sets on the same page. Review Google’s official localized versions documentation (Opens in a new tab) for the implementation options and the rule that every variant should list the complete group.

Audit HTML head annotations

With the HTML method, each `<link rel="alternate" hreflang="..." href="...">` element belongs in the valid `<head>` and should use a complete absolute URL. An early closing head tag, annotations inserted into the body, or a script that moves them into an unexpected DOM can keep the signal from being seen as intended. Compare the original HTML source with the rendered DOM. Keep each hreflang alternate in its own link element instead of combining it with an unrelated attribute such as `media`.

Normalize target URLs: HTTPS, the correct host, the preferred slash, and the canonical URL variant. Do not list a URL that redirects, returns 404, requires authentication, is noindex, or canonicalizes to another language page. Make sure every address is a real localized page available to visitors. Use canonical URLs rather than tracking parameters or session IDs in hreflang. If a page unexpectedly has two language groups, find the theme and plugin producing them and use one authoritative source.

Inspect hreflang in XML sitemaps

With the sitemap method, each `<url>` entry lists all language or region alternatives for that URL, including itself, through `<xhtml:link rel="alternate" hreflang="...">` elements. The sitemap must declare the required XHTML namespace. Each variant’s own `<url>` entry should contain the same complete alternate set, and all href values should be absolute URLs. Parse the sitemap as XML to find malformed markup, but do not assume that syntactic validity proves the relationships are correct.

Checking only the primary URL and a single language row is not enough. Confirm that every group member exists and lists itself and the other pages consistently. Include only canonical, indexable URLs; alternate links should not point to old slugs, staging hosts, or redirect targets. XHTML alternate elements describe relationships and do not increase the number of sitemap URLs. If the file is large, use a sitemap index and ensure that splitting the files does not drop reciprocal links between group members.

Align canonical, hreflang, and internal links

Each language page should normally declare itself as its own preferred canonical URL. If the Turkish page declares the English URL as canonical while hreflang says the two are alternates, those signals can conflict. Internal links, the sitemap, hreflang, and redirects should also point to consistent URL variants. Record the user-declared canonical, Google-selected canonical, and hreflang target for each page together. Consult Google’s canonicalization troubleshooting guide (Opens in a new tab) when Google selects an unexpected version.

Hreflang does not replace canonical and does not consolidate pages with different content. If you do not want a language page indexed, first confirm that this is the intended policy and assess how noindex or canonical settings affect the alternate group. Each language version should provide a title, main content, meta description, and navigation for its audience. Adapt prices, currency, stock, and legal terms to the market where appropriate. Adding the tag cannot compensate for weak localization.

Use a crawl to find broken relationships

Manually opening every URL is impractical on a large site. Crawl the pages and extract each HTML alternate set, then compare it with the CMS translation ID. At minimum, automated checks should flag invalid codes, empty or relative hrefs, repeated language values, missing self-references, non-reciprocal links, targets returning 3xx/4xx/5xx, and canonical conflicts. Include staging and production hosts in the review; wrong-host annotations often come from deployment configuration.

Generate the issue report around URL pairs and translation groups. If a group has six language versions, one missing alternate can make all six pages inconsistent. Do not stop at a metric that says “hreflang exists”; measure reciprocal completeness and the HTTP/canonical state of each target. Run the same crawl after deployment and compare before-and-after counts. Use URL Inspection on representative important pages; a crawler seeing valid HTML does not guarantee that Google will index every URL.

Common hreflang mistakes

• Missing return links: every page should list itself and the other variants.
• Invalid language or region code: use a valid code rather than a value such as `en-UK`.
• Unrelated URLs in one group: topical similarity alone is not a translation relationship.
• Redirecting or broken target: point directly to the accessible final URL.
• Conflicting canonical: a language page may canonicalize to an unintended variant.
• Only linking to itself: the group is incomplete if other localized pages are missing.
• Maintaining different source lists: HTML and sitemap generation from different data creates inconsistency.
• Forced IP redirects: visitors and crawlers may not be able to reach alternate URLs.
• Treating annotations as ranking guarantees: hreflang can help select a locale, but it does not guarantee visibility.

A step-by-step audit example

Suppose a Turkish service page and its English version appear in the wrong language in search results. First confirm that both URLs return 200, provide content in their own language, and declare their own canonical URL. Then extract alternate links from each HTML head. Does the Turkish page list both `tr` and `en`? Does the English page list those same two absolute URLs with the right codes, including itself? Is one target an old slug or a different www/HTTPS variant? Does the CMS translation ID group the two addresses together?

Next review the sitemap entry and internal links. If a target redirects or is noindex, update the annotation to the accessible preferred URL. Test the change in staging, then deploy it. In production, check source HTML and HTTP responses for both pages, and use URL Inspection to confirm that important examples are crawlable and canonical signals are consistent. Do not expect a search result to change immediately; Google may need to recrawl and process the signals before choosing a more appropriate language version. If the result remains wrong, recheck the live annotations, canonical, and actual content language.

Hreflang publication checklist

1. Define translation relationships in the CMS or editorial records.
2. Assign each page the correct language/region code and absolute URL.
3. Choose and document one method: HTML, HTTP header, or sitemap.
4. Confirm that every variant lists itself and all other variants.
5. Check that targets are accessible, canonical, and indexable.
6. Crawl production HTML or sitemap data for reciprocity errors.
7. Repeat the checks on live sample URLs after deployment.

Frequently asked questions

Should every language page link to itself in hreflang?

Yes. Each variant should list itself and the other localized pages in the same content group so that the relationship is complete and reciprocal.

Should I use both HTML and XML sitemap hreflang?

Usually not. Google supports these methods, but using all of them may add maintenance and inconsistency risk without an extra search benefit. Choose one method your team can maintain correctly.

Is `x-default` required?

No. It can identify a general page or language selector for users whose language preference does not match another value, but it is not mandatory for every site.

Does hreflang tell Google what language the page is in?

It describes relationships between language or region alternatives. Google primarily determines a page’s language by analyzing its content; do not use the tag to compensate for incorrect language text.

Will hreflang get a page indexed?

No. It does not guarantee discovery or indexing. Crawl access, canonical choice, content, and other technical signals still matter.

Should I add hreflang if a blog post has no English translation?

Only add it when a real localized alternative exists. Do not connect an untranslated article to a different post merely because the topic is similar.

Conclusion

A sound hreflang implementation connects genuinely equivalent language or regional URLs with valid codes and reciprocal annotations. Check the self-reference, absolute and accessible URLs, self-canonical consistency, and a single implementation source. Keep sitemap and internal link inventories aligned, then verify production with automated crawls and sample URL checks. Hreflang helps Google understand the appropriate locale; it does not replace useful content or guarantee indexing.

Primary reference: Google Search Central’s official guide to localized versions (Opens in a new tab). Confirm the language/region alternatives, HTML, HTTP header, sitemap, and reciprocal-link requirements against your live URLs.