# What happens to hreflang tags after a website migration? > On a multilingual site, hreflang tags almost always break in a migration unless you update them, and there are three usual failures. First, the hreflang tags keep pointing at the old URLs, so after the move they reference addresses that now 404 or redirect, and the language cluster falls apart. Second, the new platform drops hreflang entirely, so search engines lose the signal that links your language and region versions together. Third, the tags lose their reciprocity, meaning the English page points to the German one but the German one no longer points back, which invalidates the relationship. The effect of any of these is that search can show the wrong language version to a user, or treat your translated pages as duplicates. The fix is to update every hreflang URL to the new addresses, keep the set mutual so each version references all the others including itself, and 301 the old URLs as usual. hreflang is a map between versions, and a migration moves the places it points to. WPBuildAI scans your site and returns the URL list across language versions, so you can rebuild the hreflang map against the new addresses. Source: https://wpbuildai.com/what-happens-to-hreflang-tags-after-migration/ By lawrence-arya ยท 2026-06-06 --- On a multilingual site, hreflang tags almost always break in a migration unless you update them, and the breakage is quiet because the pages still look fine in each language. There are three usual failures. First, the hreflang tags keep pointing at the old URLs, so after the move they reference addresses that now 404 or redirect, and the language cluster falls apart. Second, the new platform drops hreflang entirely, so search engines lose the signal that links your language and region versions together. Third, the tags lose their reciprocity, meaning the English page points to the German one but the German one no longer points back, which invalidates the relationship. The effect of any of these is that search can show the wrong language version to a user, or treat your translated pages as duplicates. The fix is to update every hreflang URL to the new addresses, keep the set mutual so each version references all the others including itself, and 301 the old URLs as usual. WPBuildAI scans your site and returns the URL list across language versions, so you can rebuild the hreflang map against the new addresses. The subdomain angle matters more here than almost anywhere else: Google's June 2026 guidance uses [en.example.com among the variants it expects a Change of Address request for](https://searchengineland.com/for-site-moves-specify-all-domain-variants-with-googles-change-of-address-tool-480552), which is exactly the shape a language-segmented site tends to take. ## What hreflang tags do hreflang tags tell search engines that several pages are the same content in different languages or regions, and which one to show to which audience. As the guidance on [telling Google about localized versions](https://developers.google.com/search/docs/specialty/international/localized-versions) describes, they link an English page, a German page, and a French page together as a family, so a German searcher sees the German version rather than the English one. Crucially, hreflang is not a property of a single page; it is a set of references among pages, a small map that says which URL serves which audience. That is what makes it fragile in a migration: a map is only as good as the addresses it points to, and a migration changes the addresses. ## Failure one: tags still point at old URLs The most common breakage is also the most invisible. If the migration carries the hreflang tags across verbatim, they keep referencing the old URLs. After the old URLs are retired or redirected, the hreflang map points at addresses that no longer serve content directly, so the relationships between your language versions break. Search engines following those references find redirects or dead ends instead of the sibling versions, and the cluster stops working as a unit. This is the same class of problem as canonical tags pointing at old URLs, covered in [what happens to canonical tags after a migration](/what-happens-to-canonical-tags-after-migration). The tags exist, they just point at the past. ## Failure two: hreflang dropped entirely The second failure is absence. A new platform or theme may not output hreflang at all, especially if the old site relied on a multilingual plugin that did not move across. Now search engines have no signal connecting your language versions, so they may treat each as standalone, show the wrong language to some users, or, worse, see your translations as near duplicates of one another. The content is all there, but the relationships that organized it are gone. Restoring hreflang means regenerating the full set of references for every page in every language, pointing at the new URLs, so the family is reassembled on the new platform. ## Failure three: broken reciprocity The third failure is subtle and easy to miss even when tags are present. hreflang must be reciprocal: if the English page lists the German version, the German page must list the English one, and every version should reference all the others plus itself. A migration can break this when only some templates are updated, so one language outputs correct tags while another outputs old or missing ones. The result is a one sided relationship that search engines disregard, because the return reference does not match. Reciprocity is what makes the map trustworthy, so after a move you have to confirm not just that tags exist, but that they all point at each other correctly at the new addresses. ## Why migrations are when this surfaces It helps to see the common cause. hreflang is generated by whatever handles multilingual content, a plugin, a framework feature, or hand maintained tags, and a migration replaces that layer. The new system does not inherit the old references; it produces whatever it is configured to produce, which is often nothing or the wrong URLs. Web Almanac 2024 ([HTTP Archive](https://almanac.httparchive.org/en/2024/)) is a reminder of how many URLs and references a site carries, and a multilingual site multiplies that by the number of languages. So the volume of references to rebuild is large, which is exactly why hreflang is so often left broken after a move: it is invisible, plentiful, and tied to the layer you replaced. ## How to rebuild the hreflang map The repair is methodical. Start from a complete list of your URLs across every language version, so you know each old address and its new equivalent, which is what [find and extract all URLs](/find-extract-all-urls-website-301-redirects) gives you. Then regenerate the hreflang set so every page references all of its language siblings at their new URLs, including a self reference, and confirm the references are mutual. Pair this with 301s from the old URLs to the new ones, as in any [site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), and with correct canonicals so hreflang and canonical do not contradict each other, a relationship explained in [consolidating duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls). Map, regenerate, reciprocate, redirect: that sequence rebuilds the family. ## Steps to preserve hreflang through a migration 1. **List every URL across all language versions** before the move. 2. **Map each old language URL** to its new equivalent. 3. **Regenerate hreflang** so every page references all siblings at new URLs. 4. **Include a self reference** in each page's hreflang set. 5. **Confirm reciprocity:** every version references every other, mutually. 6. **301 the old URLs** and keep canonicals consistent with hreflang. ## Worked example: a three language site moves platform Imagine a site in English, German, and French moving to a new platform, with its hreflang previously handled by a multilingual plugin that does not come along. The team lists every URL in all three languages and maps each to its new address. On the new platform, hreflang is not output by default, so they configure it to generate, for each page, references to its three language versions plus itself, at the new URLs. They check a sample across all three languages and confirm the references are mutual, not one sided. They add 301s from the old URLs and align the canonicals. After launch, German searchers again see German pages and the translations are no longer treated as duplicates, because the language map was rebuilt rather than left pointing at the old site, the same care described in [migrate a multilingual WordPress site safely](/how-to-migrate-multilingual-wordpress-site-wpml-safe). ## Limitation: hreflang organizes, it does not rank It is fair to set expectations. hreflang does not boost rankings; it routes the right language version to the right audience and prevents your translations from being read as duplicates. So fixing it after a migration restores correct targeting and removes a duplication risk, but it does not lift a page that ranks poorly on its own merits. hreflang also only works when each referenced page genuinely exists and serves that language, so it cannot paper over missing or untranslated pages. Treat it as the organizing layer for a multilingual site that is otherwise sound, not as a ranking lever, and keep it consistent with your canonicals so the two signals agree. ## Common mistakes - Carrying hreflang tags across verbatim, so they point at old URLs. - Losing hreflang entirely when a multilingual plugin does not migrate. - Updating some language templates but not others, breaking reciprocity. - Omitting the self reference each page's hreflang set should include. - Letting hreflang and canonical tags contradict each other after the move. ## Key points After a migration, hreflang tags usually break unless you rebuild them: they keep pointing at old URLs, get dropped by the new platform, or lose reciprocity, so search shows the wrong language version or treats translations as duplicates. Because hreflang is a map of references among your language versions, a move that changes URLs invalidates it until it is regenerated against the new addresses. Rebuild it from a complete list of URLs across all languages, make every page reference all its siblings and itself at the new URLs, confirm the references are mutual, and pair it with 301s and consistent canonicals. Keep hreflang and [canonical tags](/what-happens-to-canonical-tags-after-migration) in agreement, since both are invisible signals a migration disturbs. WPBuildAI scans your site and returns the URL list across language versions, so you can rebuild the hreflang map against the new addresses. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.