After you click generate in the Hreflang Generator, the result is one single escaped HTML block — one <link rel="alternate"> element per locale row, with self-references included, ampersands encoded, and the hreflang attribute written in canonical casing such as en-US or zh-Hant. Checking that result means three distinct jobs that people too often collapse into one: visually scanning the block for shape and escaping errors, installing the identical block on every alternate page head, and crawling the live pages to confirm each locale really returns the full set and that the alternates actually point back to one another. The generator itself only produces the head-ready text; it cannot see your site, so every signal it described in the markup has to be re-confirmed against the published HTML. A block that looks tidy in a code editor but is missing on one URL of the cluster will be ignored by search engines, because a one-way declaration from another page cannot speak for the page it omits. Treat the post-generation phase as a deployment ritual, not a casual paste.
What "checking the result" actually means after generation
"Checking the result" splits into three jobs that are easy to merge by accident. The first job is inspecting the block the tool just produced against the input you typed — does every row produce one element, is each hreflang value canonicalized, is every URL fully qualified, and is every ampersand rendered as &? The second job is installation: the exact same block, character for character, must reach the head of every page in the language cluster. The third job is live verification, where a crawler, a browser inspector, or curl is used to confirm each published page actually returns the full set and each target URL resolves to a real, indexable page. None of these can be skipped because each catches a different failure class. The generator has no way to reach your CMS, see your redirects, or observe drift introduced by caching layers, minifiers, or template inheritance, so the post-generation phase is where realistic implementation problems surface for the first time.
Inspecting the generated block before you install it
The first pass is a quiet read of the HTML the tool just produced. The block should contain one <link rel="alternate" hreflang="..." href="..."> element per row of input, with every attribute value enclosed in double quotes and ampersands rendered as &. The hreflang attribute needs canonical casing — en-US not en-us, and zh-Hant not zh-hant. URLs must be fully qualified with http or https, including the host; relative references, scheme-relative references, fragments, and embedded credentials should not appear. If any row violates one of those shape rules, the generator rejects the entire set rather than silently dropping one locale, so a partial block on your clipboard usually points at a wrong separator count or a malformed row in the input.
| Symptom in the generated HTML | Likely input cause | Fix in the source row |
|---|---|---|
| hreflang value like en-us or zh-hant | Locale typed in lowercase region or script | Use canonical form en-US, zh-Hant |
| href contains /en/page or //example.com/en | Relative or scheme-relative URL | Provide the full https://example.com/en/page |
| Raw & between query parameters | Ampersand not escaped before copy | Verify the block uses & everywhere |
| Block missing a hreflang row you typed | Duplicate locale or duplicate target URL after normalization | Remove or merge the duplicate row |
| No block generated | Fewer than two rows were entered | Add the current page plus at least one alternate |
| href includes #section or user:pass@ | Fragment or credentials left in URL | Strip fragments and any @-credentials |
The locale casing column is worth a closer look because it is the easiest miss to skip visually. The generator runs each locale through Intl.getCanonicalLocales, so en-us becomes en-US, zh-hant becomes zh-Hant, and a region attached to a language appears as fr-CA. Case normalization is not a cosmetic detail — search engines treat tags as opaque strings, and a cluster with mixed casing is treated as a cluster with missing entries. Confirm the casing matches what you would type if you were writing each tag by hand, then move on to deployment.
Running the three post-build checks
Once the block reads cleanly, the deployment checks begin. Each step exists because the previous one only catches a different class of mistake.
- Inventory the cluster. Write down every localized URL that is a true alternate, including the page being edited right now. Do not leave off the current page — Google documents self references as an essential signal, and a block without self references invites another site to claim the page.
- Install the identical block on every page head. The Hreflang Generator produces one escaped set; that exact set, character for character, must be pasted into every alternate. Drift between copies is the single most common implementation failure, so prefer a content template sourced from the same rows used during generation.
- Crawl the live cluster, sampling at least one URL per language, and inspect the returned HTML. Confirm each sample returns 200, that the full expected set is present in the head, and that each hreflang target resolves to a real page with a 200 status. A page pointing at a redirect, a 404, or a non-canonical URL silently weakens the cluster.
A useful auxiliary check is to compare the rendered HTML of three or four locales with a diff tool. If the head sections differ in anything other than whitespace or attribute order, those differences are real implementation drift, not harmless formatting. Several publishing systems template hreflang from a sidecar file or a database column, and that source has to be the single source of truth the generator also uses, otherwise updates will not propagate to every page.
Confirming self and reciprocal links on the live pages
Reciprocal links are the part the generator cannot verify on its own — it cannot make HTTP requests from the browser. Self links and return links are two related expectations: each page must list itself in the set, and each alternate must also appear in the set published by every other alternate. Google has documented that a one-way declaration can be ignored because another site must not be able to claim your page as its alternate unilaterally. A practical check is to fetch three or four sample URLs from the cluster with a browser inspector or a command-line tool, list the hreflang values found on each, and confirm the lists match in size and in URL content.
For deeper audit guidance, Google's documentation on localized versions explains the cluster concept and how search engines treat alternate declarations. A common drift to look for is an x-default row that appears on some pages but not on every locale — only one x-default may exist in the set, but it still has to be present on every page. The generator rejects duplicate locale values case-insensitively after normalization, so a stray en-us in addition to en-US causes the generator to reject the entire set, and the duplicate row must be corrected at the source.
What breaks the block between generation and indexing
Even a perfectly generated block can be undone by what the publishing system does with it after the paste. Common ways the result stops matching the original include: a CMS rewriting absolute URLs to relative paths on save; template inheritance stripping one alternate from the head of one language; HTML minifiers dropping what they think is a duplicate link element; CDN edge logic injecting redirects on one country path but not on others; and sitemap or HTTP header implementations publishing a second inconsistent hreflang set in a different channel. Search engines treat HTML head, HTTP headers, and XML sitemaps as equivalent, so a duplicate set in any other channel must match exactly, or it should not exist.
Pick the method your CMS can keep complete and synchronized, and use the Hreflang Generator for that single channel. For a deeper conceptual overview of how the tool shapes its output from each row, the walkthrough of what the generator builds pairs well with the verification angle covered here. For background on the rel="alternate" attribute as defined in the WHATWG HTML living standard, the link type specification describes the attribute shape the generator targets.
Keeping the post-build check honest as the cluster changes
Verification is not a one-time event. When a locale is added, removed, redirected, or moved to a new canonical URL, the hreflang set on every existing page has to be regenerated and reinstalled, and the cluster crawl has to be repeated. Treat the generated block as a snapshot of the cluster's declared shape at one moment; any change to that shape invalidates the snapshot. A lightweight ongoing ritual is to re-run the generator against the canonical URL list whenever the international or CMS team schedules a release, paste the new block into a staging environment, crawl a sample of locales there first, and only then promote the changes to production.
One last boundary worth remembering is what the tool cannot do for you. It does not translate content, detect language, or guarantee a search result. It also cannot prove reciprocal links because it cannot access remote pages. Ongoing quality depends on treating hreflang as a relationship description among substantially equivalent localized pages — accurate, current, and identical across the cluster — rather than as a substitute for translated primary content or coherent international architecture.
For a deeper look, see Meta Tag Generator for Website: Build and Verify Tags.