---
title: "SEO Site Migration: URLs, Redirects, Canonicals and Hreflang"
description: "Plan an SEO site migration with URL mapping, permanent redirects, canonicals, hreflang, sitemaps, rendering checks, monitoring, and rollback controls."
canonical_url: https://optimi.com/en/guides/seo-site-migration
md_url: https://optimi.com/en/guides/seo-site-migration.md
last_updated: 2026-07-15
---

# SEO Site Migration: URLs, Redirects, Canonicals and Hreflang

Treat a URL move as a controlled search transition. Every valuable old URL needs one verified outcome: equivalent destination, relevant consolidation, or intentional removal.

A migration is not one event. Separate an identity move, such as a domain or path change, from an infrastructure move, such as a CDN, DNS, or hosting change with the same public URLs. Google recommends changing one major variable at a time where possible.

## Outcome

Build a tested URL map and launch process that keeps redirects, canonicals, hreflang, sitemaps, rendering, and operational delivery signals aligned.

## Decide whether public URLs are changing

| Migration | URL changes? | Core controls |
| --- | ---: | --- |
| Domain, subdomain, protocol, or path | Yes | URL map, permanent redirects, canonical and hreflang updates, new sitemap |
| CMS redesign with retained URLs | Ideally no | Rendering, metadata, content, and internal-link parity |
| CDN, hosting, or DNS switch | No | TLS, bot access, headers, cache, logs, and crawler-delivery parity |
| Mixed move | Some | Split into controlled workstreams where possible |

Do not use Search Console Change of Address for a CDN or hosting move that retains public URLs. That is an infrastructure migration, not a redirect project.

## Build the URL map before redirect rules

Source old URLs from sitemaps, CMS data, logs, analytics, internal links, Search Console, feeds, and strategic landing pages. For each old URL, choose an exact equivalent, relevant consolidation, or intentional `404`/`410`. Do not redirect unrelated discontinued products or content to the home page.

**SEO migration control path**

1. Inventory — Collect legacy URLs and business priority.
2. Map — Set one destination or intentional removal per URL.
3. Implement — Deploy server-side redirects and new annotations together.
4. Validate — Check HTTP, rendered HTML, crawler paths, and search signals.

*One approved URL map drives redirect rules, canonical URLs, hreflang clusters, sitemaps, and launch validation.*

Use server-side `301` or `308` for permanent moves. For ordinary crawled `GET` URLs, Google treats both as strong permanent signals; `308` preserves request method and body, while a client may change a `POST` after `301`. Redirect directly to the final destination and avoid chains and loops.

**Representative URL-map validation**

```
old=https://old.example.com/fr/shoes/red
status=301 final=https://www.example.com/fr/chaussures/rouges
final_status=200 canonical=self hreflang_cluster=reciprocal
rendered_title=present sitemap=new-canonical-only result=pass
```

## Keep canonical, hreflang, and sitemap signals consistent

Every new indexable destination should self-canonicalise. Redirects and canonical annotations are strong signals; sitemap inclusion is weaker. They must identify the same preferred URL. Rebuild each hreflang cluster with fully qualified new URLs, self-reference, reciprocal return links, and same-language canonicals. Submit a sitemap of canonical `200` URLs only and update internal links instead of depending on redirects indefinitely.

## Treat rendering and infrastructure as release gates

Validate raw HTTP response, rendered HTML, browser output, canonical, robots directives, sitemap, structured data, and essential JavaScript/CSS access. A `200` response is not proof of indexability or correct rendering. For a no-URL-change CDN move, test DNS, TLS, host headers, cache key and `Vary`, bot WAF rules, redirects, image delivery, and purge behaviour from multiple regions.

## Migration mistakes that create search loss

- Combining a domain move with redesign, taxonomy, CMS, locale, and rendering changes without a phased plan.
  - Using temporary redirects for permanent moves, or redirecting every removed URL to the homepage.
  - Leaving `noindex`, password protection, or development robots rules in production.
  - Sending conflicting redirect, canonical, sitemap, internal-link, and hreflang signals.

## Related guides

- [CDN Migration Guide](/en/guides/cdn-migration)
- [Hreflang and CDN Routing](/en/guides/hreflang-cdn-routing)
- [JavaScript Rendering and SEO](/en/guides/javascript-rendering-seo)

## Authoritative references

- [Google: Move a site with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)
- [Google: Redirects and Google Search](https://developers.google.com/search/docs/crawling-indexing/301-redirects)
- [Google: Canonical URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
- [Google: Localized versions and hreflang](https://developers.google.com/search/docs/specialty/international/localized-versions)
- [Google: Changing hosting or CDN infrastructure](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes)

[Review a site migration](/en/contact): Make the next migration observable and reversible — Optimi can help connect technical SEO, edge delivery, logs, and rollback controls before a URL or infrastructure move goes live.