Technical SEOFor content and SEO teams, learn to map equivalent blog editions, choose hreflang codes and formats, and test reciprocal links and redirects after URL changes.
13 min read
A translated article can be live and easy to find, yet still appear for the wrong market if its alternate URLs point to the wrong editions. Hreflang tags for multilingual blog content help Google Search connect equivalent articles with their intended language or region. They do not translate a post or guarantee which result a searcher sees.
Start with the articles, not the markup. Once you know which published URLs belong together, you can assign codes, choose one annotation format, and keep those relationships intact when URLs move. The same record gives your team a practical way to check each release.
Article summary
Give each article family its own URL record. A family contains actual versions of the same article, not every post aimed at a particular country or every page under a language folder.
Start with a stable article ID that stays the same when titles or URL slugs change. Put each published language or regional edition under that ID. Compare the main subject and intended reader before treating two posts as equivalents. Similar slugs are weak evidence: editors may adapt a title, change examples, or publish a separate article for a local audience.
Keep these fields together for each family so a move does not separate its editions:
For an illustration, imagine one article published at an English URL and a French URL. Record both under one ID, but leave a proposed German edition unpublished until its page exists. A different French article on the same topic belongs in another family if it answers a different question.
This distinction matters when a regional editorial plan contains both translations and original stories. A regional article planning workflow can help assign ownership, while the hreflang record should contain only equivalent pages.
Google describes hreflang uses that include fully translated pages and small regional variations in the same language. It also includes pages whose template is translated while the main article is not. That last case deserves an editorial decision: a translated menu does not make an English article a French translation.
Check what a reader would receive after following each alternate. If the main body remains in the original language, describe that edition accurately in your publishing record. Google says pages in different languages are duplicates only when the main content remains untranslated. Do not add a language URL merely because a template or navigation label exists for it.
Regional editions need a separate judgment. An English article for the UK and an English article for another market may differ in examples while addressing the same question. They can belong together, but a locally commissioned article with a different purpose should not be forced into the group. Think in terms of what each reader is trying to learn, rather than which directory contains the page.
Duplicate-content decisions remain separate. The duplicate URL decision guide explains when a canonical or redirect has a role; neither should be assigned simply because two editions share a topic.
Publish each language version at its own stable URL. Google recommends distinct URLs rather than relying on cookies or browser settings to change a page's language. Dynamic changes and automatic rerouting can keep Google from finding every edition. They can also make an alternate link difficult for a reader to follow directly.
Record the canonical destination alongside each published URL. A canonical identifies Google's representative URL among duplicate pages; hreflang connects valid localized editions. For same-language regional variants, Google recommends using canonicalization with hreflang. Make the canonical decision deliberately rather than assuming an alternate annotation settles which URL represents duplicated content.
Before producing markup, open each destination in the article family. The URL should lead to the intended article, not a language home page or a replacement post with a different focus. If a translation has not been published, keep its status in the record without creating an alternate reference to it.
Also check the route readers take through the site. If a moved article leaves an old menu or related-post link behind, the broken internal link workflow helps find that problem. Hreflang should describe the live editions; internal links should lead readers to them.
For hreflang tags on multilingual blog content, a correct URL group still needs accurate audience labels. Choose the language first, add a region only when it distinguishes a real edition, and publish the same complete group for every version.
Google specifies an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha 2 region code. In practice, en labels English without narrowing it to one country; en-GB labels English intended for the UK. Likewise, fr-CA identifies a French edition intended for Canada. A region code cannot stand alone.
Use the broader language label when one article genuinely serves that language's readers across markets. Add a region when you have an edition intended for that region. The code describes the audience for the URL, not the country where your business operates or the folder name your CMS happens to use.
Google accepts uppercase and lowercase letters, although uppercase region codes follow ISO convention. Consistent casing makes a shared publishing record easier to read. Google's localized-versions documentation dated September 21, 2026, says es-419 is not supported as an hreflang value because its region component is not an ISO 3166-1 Alpha 2 code.
A common trap is treating the annotation as a language detector. Google says it determines page language through its own algorithms, not hreflang or the HTML lang attribute. Label an edition for its intended audience, but make the article itself match what that audience expects to read.
The x-default value names a fallback URL for visitors whose language or region is not covered by the listed editions. Google says it works best on a language selector. It is not a translation code, and it does not create an article where no localized article has been published.
Suppose a publisher has English and French editions plus a page where readers choose a language. The selector may be the x-default destination. If that selector does not exist, do not invent one to fill a field. Keep the published article group accurate and decide separately whether a selector would help readers navigate the site.
Each published edition should list itself as well as its alternates. The alternate relationships must run both ways: if the English page names the French page, the French page must name the English page. Give every reference a fully qualified URL, including https://, rather than a relative path that depends on where the annotation appears.
This is easier to maintain when the alternate set comes from one article record. A newly published translation then changes the set for every existing edition, not only its own page. An unpublished edition remains outside the set until it has a live destination.
Google supports HTML alternate links, HTTP Link headers, and XML sitemaps for hreflang. It treats the methods as equivalent and says there is no Search benefit to maintaining all three. Choose the format your team can update whenever an edition is published, removed, or moved.
These formats place the alternate set in different parts of your publishing system:
| HTML links | XML sitemap | HTTP headers | |
|---|---|---|---|
| Useful for | HTML article pages | Central URL records | PDFs, other files |
| Location | Page head | Each URL entry | Link response header |
| Variant coverage | Full set per page | Full set per entry | Full set per response |
For ordinary blog pages, HTML links fit when your templates can read the article record. Sitemap annotations may be simpler when a central process owns all URL relationships. HTTP headers are useful for non-HTML material, including PDFs, because those files have no HTML head.
In a sitemap, each article URL entry lists every alternate, including itself; the child alternate links do not count toward the sitemap's URL limit. Whichever method you use, produce the same self-inclusive set for each edition. Mixing manually maintained sources adds another place for an old URL to survive after a move.
Treat a move as a change to article relationships, not only to addresses. Each old localized URL needs a destination for that same edition, and every live annotation should name the final URL.
Start with one published article family. On each edition, inspect the format your site actually uses: the HTML head, the HTTP response headers, or the sitemap entry. Compare its alternate set with the article record. Each URL should be fully qualified and lead to the edition named by its language or regional code.
Next, read the references in reverse. Does every destination list itself and return a reference to the page you started from? A correct-looking English page is not enough if its French counterpart still points at an older English address. Check the entire family after adding an edition, because an existing page must also acquire the new alternate.
Open the destinations rather than judging them by URL shape. A valid path may now contain a different article, a language landing page, or a redirect to an unintended market. Inspect the canonical destination separately, especially where regional editions share a language. Hreflang and canonicalization answer different questions, so one correct annotation does not excuse a mistaken canonical.
For hreflang tags on multilingual blog content, the useful unit of testing is the article family. Testing only the newly created URL can miss stale references on older editions. Keep the record beside the results so an editor can resolve whether the error is in the markup or in the proposed pairing.
Build the cutover from the existing URL record. A language-specific article should move to its corresponding language-specific destination, not to one default page for every old path. Google recommends permanent server-side redirects such as 301 or 308 and advises against redirect chains. A direct old-to-new pair makes the intended destination clear.
Use this sequence for each moved article family:
Google's site-move guidance generally recommends keeping permanent redirects for at least one year. Meanwhile, live hreflang references should point straight to new final URLs, not to old URLs that redirect. That distinction lets old links reach the moved article without leaving outdated addresses in its current alternate set.
A crawl can check more article families than a series of manual page visits. Compare its results with your record to find missing self-references, absent return links, malformed codes, and alternate URLs that no longer lead to the intended article. Test redirects as a separate part of the crawl so a sound annotation does not hide a broken old path.
Google's migration guidance recommends using Search Console to submit the new sitemap and monitor indexing. Watch the affected language URLs after launch alongside your site's traffic for those markets. A reported indexing change gives you a reason to inspect the relevant article family, its canonical destination, and the route from its old URL.
Search Console's International Targeting report is deprecated, although Google continues to support and use hreflang, according to Search Console Help. Do not base your release check on finding that old report. Use your published annotations and crawl results to test relationships, then use Search Console's sitemap and indexing information to follow the move.
When the crawl finds a mismatch, fix the underlying article record before republishing annotations. Otherwise, a manual repair on one page may disappear at the next release. Repeat the check when a translation launches, a regional edition changes purpose, or another URL in the family moves.
The durable choice is where your team maintains article identity and URL relationships. Publishing software can manage articles, while a separate crawl tests what the site actually released. Neither task replaces the other.
Put the article family ID, intended locale, current URL, and canonical decision where the people publishing editions can maintain them. That may be a CMS field or a shared publishing record. The point is to give a new translation one existing family to join, rather than making an editor reconstruct relationships from similar-looking slugs.
Assign ownership of changes. When an editor publishes an edition, someone must update the group's active URL set. When a developer moves a path, someone must change the old-to-new destination and republish the references on every affected edition. A record with no owner is liable to preserve a URL long after its article has moved.
Keep an unpublished translation visible as a status, not as an alternate URL. This lets a content team plan work without implying that searchers can reach the page. If two regional articles cease to answer the same question, revisit their family assignment before carrying old annotations into a redesign.
Prefer a process that generates the alternate set from the maintained record. If that is beyond your publishing setup, a small manually maintained group can still work, provided a release check covers every edition. The trade-off is staff time: each added or moved URL calls for changes across the whole family.
Aranx supports keyword and competitor research, content planning, article generation with images, publishing to connected WordPress, Shopify, and custom CMS sites, and management of multiple websites. Those are content operations. The supplied product information does not establish that it creates or validates hreflang, so it should not stand in for an annotation or audit process.
Screaming Frog is a technical crawler that Google names as an option for testing redirects during a site move. Sitebulb is another technical audit option; SEO Sherpa names both tools for finding hreflang problems such as missing return links, invalid codes, or broken target URLs. These tools inspect released pages rather than decide which articles are editorial equivalents.
The roles are different, so choose for the task rather than treating these names as direct substitutes:
| Aranx | Screaming Frog | Sitebulb | |
|---|---|---|---|
| Role | Blog content operations | Technical site crawling | Technical SEO auditing |
| Relevant work | Plan and publish articles | Test moved URL redirects | Find hreflang issues |
If your team already has a reliable publishing process, the more useful addition may be a crawl and a maintained URL record. If publication across sites is the bottleneck, content software may help with that work. In either case, an editor still has to decide which articles belong together.
Choose an existing article with at least two live language editions. Put its active URLs, intended audiences, and canonical destinations into one record. Have the person responsible for publication produce the alternate set through the process your team expects to use for future articles.
After publishing, inspect each edition's actual annotation location. Follow every alternate destination and check that each page returns the relationship. If the article is moving, test its old URLs against the recorded new destinations. This small release reveals whether your publishing process and your QA process use the same article record.
Resolve any mismatch at its source. A wrong pairing calls for an editorial record change; a missing reference calls for a publishing change; an old path that reaches the wrong market calls for a redirect change. Assign the correction to the owner of that part of the workflow before extending it to more posts.
Once that article passes, apply the same process to the remaining families. Keep the record active as articles are added or moved. Your next decision is concrete: select the first article family and name who will maintain its URLs and test its published references.
Hreflang tags connect equivalent URLs for language or regional page versions and help Google Search identify the version intended for a searcher’s language or region. Hreflang tags do not translate the article, and Google does not use hreflang or the HTML lang attribute to detect page language.
Yes. Each hreflang language version should list itself and its alternate versions, and the relationship must be reciprocal for Google to process it. Alternate URLs must be fully qualified, including https://.
Hreflang tags use an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha 2 region code. A region code cannot stand alone; examples include en, en-GB, and fr-CA.
For hreflang annotations, Google treats HTML links, HTTP Link headers, and XML sitemaps as equivalent methods. Choose the format the team can keep accurate; Google says there is no Search benefit to maintaining all three.
