Hreflang Tag Generator

A hreflang generator builds the tags that tell Google which language and country version of a page to show each searcher. Add each version of your page with its language code, optional country code and URL, plus an x-default, and our tool writes valid hreflang tags for your HTML head, your XML sitemap or an HTTP Link header. Every code is checked against the official ISO lists, so mistakes such as en-uk are caught before they go live.

How to use the Hreflang generator

1. 1 Sign in and open the generatorLog in to your free account and open the Hreflang Tag Generator from the tools list.
2. 2 Add each version of the pageEnter a language code, an optional country code and the full URL for every version, or paste a list in one go.
3. 3 Set an x-defaultChoose the page for visitors whose language or country you do not target, often your main international page or a language picker.
4. 4 Pick the output formatChoose HTML tags for the page head, XML sitemap entries, or an HTTP header for PDFs and other files.
5. 5 Publish on every version and verifyAdd the same full set to every version, then run the free hreflang checker on each URL to confirm the return links.

What hreflang tags do

Hreflang is an annotation that links together pages with the same content in different languages, or in the same language for different countries. It tells Google that the British, American and French versions of a page are alternatives, so it can show each searcher the right one. Without it, a searcher in Dublin might land on your US page with dollar prices, or a French speaker might see your English page.

Hreflang does not make a page rank higher, and it does not stop pages being treated as duplicates in every case. It helps Google swap the most suitable version into the result for each searcher. It is most useful when versions are very similar, such as English pages for the UK, Ireland and Australia that differ only in prices, spelling and contact details.

Language and country codes explained

Each hreflang value starts with a language code from ISO 639-1, which is two letters such as en, fr, de or cy for Welsh. You can add an optional country code from ISO 3166-1 alpha-2, such as GB, IE or US, after a hyphen. A country code on its own is not valid; Google needs the language. Letter case does not matter to Google, but writing the language in lower case and the country in upper case, such as en-GB, is the usual convention.

The generator embeds both official lists and checks every row against them. It also catches the codes people most often get wrong because a country code looks like a language code, or the other way round.

• en-GB, not en-UK: the ISO code for the United Kingdom is GB, and Google ignores UK as a region.
• uk on its own is Ukrainian, not the United Kingdom.
• ja is Japanese (JP is the country), ko is Korean (KR is the country), and da is Danish (DK is the country).
• se is Northern Sami; Swedish is sv. ee is Ewe; Estonian is et.
• Numeric regions such as 419 for Latin America are not supported by Google, so use separate country codes or a language-only value such as es.

x-default and language-only fallbacks

The x-default value names the page Google should show when none of your listed languages or countries match the searcher. It is usually a language picker or your main international page. It is optional but recommended, especially for sites that target only a few countries.

You can also mix language-only and language-plus-country values. For example, en-GB and en-US for your two main English markets, plus en pointing at your international English page so English speakers in Canada, Singapore or South Africa still get English rather than falling through to x-default. The generator suggests a language-only entry when you have country-specific versions without one.

Return links: why every page needs the full set

Hreflang only works when it is confirmed from both sides. If your UK page lists the French page as an alternative, the French page must also list the UK page. Google ignores annotations that are not returned, which is the most common reason hreflang appears to do nothing.

The simplest way to get this right is to put exactly the same set of tags on every version, including a tag for the page itself. That is what the generator produces: one block that you paste into the head of every page in the group. In the XML sitemap format it goes further and writes a separate url entry for each version, each carrying the full set, so the return links are consistent by design.

To check a page that is already live, open the Check return links panel and paste its HTML source or its hreflang tags. The generator compares what is there with your set and lists missing codes, extra codes, URLs that differ and repeated codes. For a full check against the live site, including whether each alternate actually links back, use our free hreflang checker.

HTML, sitemap or HTTP header: which method to use

Google supports three ways of declaring hreflang, and they are equivalent. Use one method for a given set of pages, not several, so there is only one place to keep up to date.

Whichever method you choose, use the full, absolute URL of each version, the exact address that loads with HTTP 200 and that is also used in the canonical tag. Hreflang pointing at redirects, at pages with a noindex, or at pages whose canonical points elsewhere is ignored. Each version should have a canonical pointing to itself, not to the version in another language.

• HTML link tags in the head: the most common method and the easiest to inspect. Best for most sites with a manageable number of pages.
• XML sitemap with xhtml:link entries: keeps page templates clean and suits large sites where adding tags to every page is awkward. The urlset element must declare the xhtml namespace, which the generator includes.
• HTTP Link header: the only option for non-HTML files such as PDFs. The generator gives you the header value plus example Apache and Nginx lines.

Common hreflang problems and how to avoid them

Duplicate codes are a frequent fault: two rows for en-GB pointing at different pages leave Google unsure which to use. The generator treats this as an error and asks you to choose one. Using one URL for several codes is allowed, for example a single English page for en-GB and en-IE, and the generator only notes it so you can confirm it is intended.

Other problems happen after publishing. Templates sometimes output relative URLs, mix http and https, or drop the trailing slash, so the hreflang URL no longer exactly matches the page. Content management systems may forget to add a new language version to existing pages, breaking return links. Rerun the hreflang checker after site changes, and keep your list of versions in one place so updates are consistent.

Finally, remember that hreflang is a signal about which version to show, not a way to geo-target content you have not localised. Pages for different countries should genuinely differ where it matters to the visitor, such as currency, delivery, contact details and spelling.

Examples you can copy

<link rel="alternate" hreflang="en-GB" href="https://www.example.co.uk/" />
<link rel="alternate" hreflang="en-IE" href="https://www.example.ie/" />
<link rel="alternate" hreflang="en-US" href="https://www.example.com/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.co.uk/</loc>
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.co.uk/" />
    <xhtml:link rel="alternate" hreflang="fr-FR" href="https://www.example.fr/" />
  </url>
</urlset>

Link: <https://www.example.co.uk/guide.pdf>; rel="alternate"; hreflang="en", <https://www.example.co.uk/guide-cy.pdf>; rel="alternate"; hreflang="cy"

Common mistakes to avoid

Frequently asked questions