Free hreflang generator and checker
- No signup
- Free
- 10 checks a day
Hreflang tells search engines which language or country version of a page to show. This tool builds valid tags and checks a live cluster for the mistakes that make Google ignore the whole set. It does not promise rankings. It stops you shipping broken return links.
How to use the hreflang generator
Add one row per language or country URL. Pick a language, add a region only when the page is meant for that country, and keep every URL absolute. Paste an x-default URL when you have a catch-all page for everyone else. Generate HTML, a sitemap block, or HTTP Link headers once the rows pass validation.
Bulk paste works as URL, language, region on each line. The generator refuses codes it does not know. It will stop you writing en-UK. Use en-GB. Read the warnings about mixed hosts or mixed http and https before you copy the output into production.
When the output looks right, put the same set on every page in the cluster. A UK page that lists the US alternate must also appear on the US page. That return link is the rule most setups break.
How to use the hreflang checker
Paste one URL from a language cluster. The checker fetches that page, reads hreflang from the HTML head and from the Link header, then follows the alternates it finds (up to thirty). It builds a matrix of return links and lists exact fixes, including a sample tag when a return is missing.
Read the verdict first. Errors mean Google may ignore the tags until you fix them. Warnings, such as a missing x-default, are optional improvements. A page we could not fetch is marked as unreachable. That is not the same as a broken return link.
Ten checks a day is enough for real troubleshooting. Fix the missing return, redeploy, then check again. Loading a checked cluster into the generator helps you rebuild a clean set when the live markup is a mess.
What hreflang does (and does not do)
Hreflang is a hint about which URL is the right language or region variant. It is not a ranking boost. It will not make a weak page rank in a new country. It helps search engines avoid showing the wrong market the wrong page when the same content exists in several places.
Canonical and hreflang must agree. Hreflang should point at canonical URLs. If a page redirects, point at the final URL. If a page is noindex, do not expect the tags on it to carry the cluster. Those conflicts are errors in this checker on purpose.
Hreflang code cheat sheet
Language uses ISO 639-1 two-letter codes. Region uses ISO 3166-1 alpha-2. Combine them as language-REGION, for example en-GB and en-US. Do not invent en-UK. Spanish for Mexico is es-MX. Portuguese for Brazil is pt-BR.
x-default is optional. Use it for the page you want when none of the other codes match, often an international chooser or a global English page. It does not replace a proper language tag for a real market page.
| Code | Meaning | Common mistake |
|---|---|---|
| en-GB | English for the United Kingdom | Writing en-UK |
| en-US | English for the United States | Using en alone when US and UK pages both exist |
| es-MX | Spanish for Mexico | Using es for every Spanish market |
| pt-BR | Portuguese for Brazil | Using pt when Brazil and Portugal differ |
| x-default | Fallback for unmatched users | Treating a missing x-default as a hard error |
HTML tags vs sitemap vs HTTP headers
HTML link tags in the head are the most common and the easiest to inspect. A hreflang sitemap is useful when you have many URLs and want one place to maintain the map. HTTP Link headers work when you cannot edit the HTML, but they are harder to debug in the browser.
Pick one primary method for a cluster and keep it consistent. If HTML and headers disagree, the checker will surface both and you still have to decide which source is authoritative. Do not maintain three different maps by hand.
The most common hreflang errors
Missing return links are first. Page A lists page B, but page B never lists page A. Invalid region codes are second. Canonical conflicts are third. Redirecting hreflang targets are fourth. Self-reference missing on a page is fifth. Duplicate language codes pointing at different URLs round out the list I see most often.
When you fix a cluster, fix the whole set in one deploy. Patching one page and leaving the others stale often makes the matrix worse for a week. Use this checker after the deploy, not only before.
- Missing return link between two alternates
- en-UK or other invented region codes
- Hreflang URL that is not the canonical URL
- Alternate that 301s to another host or path
- noindex on a page that still declares hreflang
- Self-reference missing on one member of the cluster
Shopify Markets, WordPress, and Next.js
Shopify Markets and apps often inject hreflang for you. Still check a money page with this tool. Plugin output can miss a market, point at a non-canonical URL, or leave a redirect in the chain after a theme change.
On WordPress, WPML and Polylang are common sources. Confirm the plugin is writing tags on the templates you care about, not only the homepage. On Next.js, generate the tags in one place in the layout or metadata API so every locale page shares the same cluster builder.
After a migration, re-check hreflang on the new host. Old domains left in the tags are a classic post-launch failure. Pair this page with the redirect mapper when the move also changes paths.
A practical fix order I use on client sites
I start with unreachable and redirecting targets. There is no point debating return links while half the cluster 301s. Point every hreflang href at the final canonical URL, then redeploy.
Next I fix invalid codes. en-UK, bare region codes, and duplicate language labels pointing at different URLs all get cleaned before I ask Google to recrawl. The generator’s validation list is the same list I use in reviews.
Then I repair return links in one pass. I paste the missing tag the checker suggests, or I rebuild the whole cluster in the generator and replace the old set. Partial patches leave the matrix half green and still broken.
Self-reference comes after that. Every page should list itself. Plugins sometimes omit the current URL on one template. Spot-check a service page, a blog post, and a homepage in each language.
Canonical conflicts last only because they often need a CMS change, not just a tag paste. If the canonical points at another market’s URL, fix the canonical logic in the template. Do not paper over it with more hreflang.
I re-run the checker after deploy on the same seed URL. If the verdict is clean, I leave it alone and watch Search Console international targeting reports when they still apply to the property. I do not refresh the SERP every hour waiting for a flag to appear.
For Shopify Markets, I treat the app output as a draft. Themes update. Markets get added. A new country can ship without a return link until someone checks. Ten daily checks are enough to catch that after a markets change.
For WordPress, I ask which plugin owns the tags. Two plugins writing hreflang is worse than none. Disable the duplicate source, then validate. For Next.js, I want one function that builds the cluster for a path so product and marketing pages cannot drift.
When a migration moves hosts, I check hreflang the same week as redirects. Old domains left in alternates are common. Pair this tool with the redirect mapper and the migration checklist so the international set is not an afterthought on week three.
If the business only has one language, you do not need hreflang theatre. Add it when you truly serve more than one language or country URL. A single en page does not need a decorative x-default pointing at itself for show.
Use the Sitemap URL check when your plugin writes hreflang only in XML. Use the Page URL check when tags live in the head. If both exist and disagree, fix that conflict before you chase return links.