Google also recommends mapping old URLs to their new destinations, testing the new site thoroughly, implementing the appropriate redirects and monitoring both the old and new versions after the move.[1]
What is a website migration from an SEO perspective?
Not every migration is the same.
Google broadly distinguishes between site moves where URLs change and infrastructure changes where the public URLs remain unchanged.[1][2]
Examples of migrations involving URL changes include:
- changing domain;
- moving from HTTP to HTTPS;
- changing URL structure;
- changing directories or slugs;
- moving content between domains;
- consolidating several websites into one.
In these situations, users and search engines need a clear signal showing where the previous resource has moved. Permanent redirects are usually the main mechanism used for this.
A hosting or infrastructure migration where all public URLs remain unchanged is different. Google provides separate guidance for this scenario and focuses primarily on server preparation, DNS changes and monitoring traffic and Googlebot activity.[2]
Likewise, changing CMS does not automatically require changing URLs. A site can be moved from one platform to another while preserving its existing URL structure.
Avoid changing everything at once if you do not need to
Where the project allows it, Google recommends changing major elements in stages rather than moving domain, CMS and the entire site layout at the same time.[1]
The reason is practical.
If visibility drops after launch, it is much easier to diagnose the cause when you know exactly what changed.
Why can organic visibility fall after a website migration?
A migration does not automatically mean a website has to lose its existing rankings.
Risk increases when the migration removes or changes elements that previously helped Google discover, interpret and evaluate individual pages.
Common problems include:
- an important old URL returning 404 even though a new equivalent exists;
- redirecting many unrelated pages to the homepage;
- canonical tags still pointing to the old domain or staging environment;
- an accidental noindex directive on production;
- important resources being blocked in robots.txt;
- internal links still pointing through old URLs;
- valuable content being removed or substantially changed;
- broken hreflang relationships;
- rendering problems on the new site;
- redirect chains or redirect loops.
Google specifically warns about unrelated redirects, indexing blocks left behind after launch and inconsistent canonical signals during site moves.[1]
A technology change can also introduce problems.
Google can process JavaScript, but content intended for indexing ultimately needs to be available in the rendered HTML.
For that reason, after moving to a more JavaScript-dependent architecture, it is worth checking not only how the page appears in a normal browser, but also the rendered version available through Google’s tools.[9]
Stage 1. Build a pre-migration inventory
One of the most expensive migration mistakes is starting the URL mapping process only after the old website has already been taken offline.
Before launch, build the most complete possible inventory of URLs associated with the existing website.
A normal crawl alone may not be sufficient.
It will not necessarily discover an orphan URL that has no current internal links but still receives organic traffic or has valuable backlinks.
For that reason, the inventory should combine several sources.
Website crawl
A crawl provides URLs available through the current internal linking structure and allows you to review status codes, canonicals, headings, indexability and crawl depth.
Google Search Console
Search Console helps identify pages generating organic clicks and impressions and provides a baseline for comparing visibility before and after the migration.
Google Analytics 4
GA4 helps identify landing pages that genuinely receive traffic and generate conversions.
The Traffic acquisition report can be used to analyse visits coming from organic sources.[8]
XML sitemap
The sitemap provides another source of URLs that the site currently declares to search engines.
Backlink data
Ahrefs, Semrush or another backlink analysis platform can help identify historical URLs that still receive external links.
Server logs
For larger websites, server logs can provide an additional source of old URLs that are still being crawled by Googlebot.
Screaming Frog also recommends combining crawl data with sources such as Analytics, Search Console, sitemaps, backlink data and log files when building a migration URL inventory.[10]
What should you preserve as a baseline?
Before deployment, save data that can be used for later comparison:
- Google clicks and impressions;
- important search queries;
- organic landing pages;
- conversions and organic revenue;
- indexed pages;
- a full crawl of the old website;
- existing redirects;
- backlink data for important URLs.
The objective is not to expect identical performance immediately after launch.
The objective is to understand what changed compared with the pre-migration state.
Which tools are useful during an SEO migration?
There is no single tool that can audit an entire migration.
Each tool shows a different part of the picture.
| Tool | Main migration use |
|---|---|
| Screaming Frog | crawling, staging comparison, canonicals, status codes, internal links, redirect testing |
| Google Search Console | organic visibility, indexing, sitemaps, URL Inspection, Change of Address |
| Google Analytics 4 | organic traffic, landing pages, conversions |
| Ahrefs / Semrush | backlink targets and additional historical URL data |
| Chrome DevTools / Lighthouse | rendering, JavaScript, requests and technical regressions |
| Server logs | Googlebot activity, legacy URLs, 4xx and 5xx responses |
Screaming Frog before and after the migration
Screaming Frog is particularly useful because you can crawl the existing website, crawl the staging environment and then compare the two datasets.
Its Crawl Comparison functionality can be used to review changes in areas such as structure, crawl depth, page titles, meta descriptions, internal linking and page content between two crawls.[10]
Screaming Frog documents List Mode as a practical way to test a predefined set of URLs during migration work and to follow redirects through to their final destination.[10]
Stage 2. Staging: what should be checked before launch?
The staging environment should allow the new website to be checked before users and search engines see the production version.
Before launch, compare the new site with the existing version for:
- important URL structure;
- HTTP status codes;
- titles and H1 headings;
- canonical tags;
- meta robots directives;
- internal linking;
- breadcrumbs;
- hreflang;
- structured data;
- content on important landing pages;
- rendering behaviour.
If the staging environment is publicly accessible, it also needs protection against accidental indexing.
However, robots.txt and noindex should not be treated as interchangeable mechanisms.
robots.txt: controls crawling.
noindex: tells search engines that a page should not be indexed.
For Google to see a noindex directive, Googlebot must be able to crawl the URL.
If the URL is blocked in robots.txt, Google may not be able to read the noindex directive.[4]
For a private staging environment, access restrictions such as server-level authentication are therefore preferable to relying solely on crawler directives.
Stage 3. URL mapping: the key migration document
When URLs change, every important old URL should have a defined outcome.
The objective is not to create one rule:
everything → new homepage
but to define the relationship between individual resources.
| Old URL | Situation | Action |
|---|---|---|
| /old-service/ | the service exists under a new URL | 301/308 to equivalent |
| /guide-2022/ | content was consolidated into a new guide | merge + 301/308 |
| /spring-offer-2019/ | content no longer exists and has no replacement | 404 or 410 |
| /contact/ | URL remains unchanged | keep 200 |
Google recommends mapping current URLs to their new equivalents and using permanent server-side redirects where content has genuinely moved.[1][3]
301 or 308?
For permanent URL moves, Google recommends using a permanent server-side redirect where possible.
Both 301 and 308 indicate that the resource has permanently moved.[3]
For a typical website migration, 301 is the more commonly encountered option.
308 serves a similar permanent-redirection purpose but differs at the HTTP level, including how request methods are handled.
There is no SEO reason to replace correctly functioning 301 redirects with 308 redirects.
Google also states that permanent redirects such as 301 do not cause a loss of PageRank.[1]
A redirect may be correct while the new page simultaneously loses content, internal links or changes its search intent.
What about 302 and 307?
302 and 307 are temporary redirects.
They are appropriate when the move itself is genuinely temporary.
Google recommends using a permanent redirect when the URL has permanently changed.[3]
A 302 should therefore not be used as the default choice for a permanent migration simply because it also redirects the browser.
404 or 410?
If a page has been permanently removed and there is no similar replacement, both 404 and 410 are valid responses.
Google lists both as appropriate responses when a resource no longer exists and there is no replacement page.[5]
Not every historical URL needs to be redirected somewhere.
When there is no logical replacement, a correct 404 or 410 response is better than sending the user to an unrelated category or homepage.
Why you should not redirect everything to the homepage
This is one of the most common shortcuts in poorly planned migrations.
Imagine the old website contained 500 articles.
The new site retains 100, while the remaining 400 use: old article → /
Technically, the redirect works.
From a content perspective, the homepage is not the equivalent of 400 different articles.
Google warns that redirecting many old URLs to a single unrelated destination, such as the homepage, may be treated as a soft 404.[1]
If several old articles have genuinely been consolidated into one comprehensive new resource, however, redirecting those URLs to the consolidated page may be completely appropriate.
Redirect chains: the shorter, the better
Long-running websites can easily accumulate structures such as:
URL A → URL B → URL C → URL D
especially when every migration adds another layer of redirects.
Googlebot can follow chains of up to 10 redirects, but Google recommends redirecting directly to the final destination.
Where a chain cannot be avoided, Google advises keeping it as short as possible — ideally no more than three redirects and fewer than five.[1]
In practice, a new migration is a good opportunity to simplify:
old URL → previous URL → current URL
into: old URL → current URL.
This can be tested efficiently with Screaming Frog List Mode and redirect reports.
Stage 4. Canonicals, internal links and sitemaps should tell the same story
A migration is easier for search engines to interpret when the main technical signals are consistent.
For a new destination URL, the intended structure might look like:
old URL
↓ 301
new URL
and on the new page:
- the canonical points to the new URL;
- internal links point directly to it;
- the new URL appears in the sitemap.
Google describes redirects and rel=”canonical” as strong canonicalisation signals, while sitemap inclusion is a weaker signal.
Google also notes that combining consistent canonicalisation methods can strengthen the preferred signal.[6]
Canonical tags after a migration
When URLs change during a migration, Google recommends updating canonical tags on the new pages so that they use the new URLs.[1]
A typical mistake looks like this:
new page: newdomain.com/service/
but the HTML still contains: canonical → staging.example.com/service/
or: canonical → olddomain.com/service/
It is also important to remember that a canonical is not an absolute command.
Google considers the declared canonical, but may ultimately select a different representative URL.[6]
Update internal links
After migration, internal links should point directly to the new URLs instead of linking to old addresses and relying on redirects.
Google includes updating internal links as part of its site migration guidance.[1]
Instead of: article → old URL → 301 → new URL
use: article → new URL.
The redirect then remains useful for old search engine references, bookmarks, external backlinks and historical URLs.
Before launch, a focused SEO audit helps verify URL mapping, canonicals and internal linking behaviour.
What should happen to the XML sitemap?
After migration, prepare a sitemap containing the new preferred URLs.
Google recommends including URLs in a sitemap that you want to appear in Search — in practice, your preferred canonical URLs.[7]
If <lastmod> is used, the date should reflect a genuinely meaningful page change.
Google gives examples such as updates to the main content, structured data or links, rather than an automatically refreshed CMS timestamp.[7]
Google’s current migration documentation describes both submitting the new sitemap and using sitemap data to monitor the transition between old and new URLs.[1]
What about hreflang on multilingual websites?
If language-version URLs change, their hreflang relationships also need to be updated.
Google explicitly mentions updating hreflang annotations to the new URLs as part of a migration.[1]
In practice, review the complete cluster:
- PL → EN;
- EN → PL;
- self-reference;
- x-default, if used;
- canonical for each version.
Changing only one language version while the other continues to reference historical URLs creates inconsistent signals.
Stage 5. Launch-day checklist
Do not treat “the website opens” as proof that the migration is complete.
- Homepage returns 200.
- Important landing pages return 200.
- Old URLs with valid replacements return the intended 301/308.
- No redirect loops exist.
- No unnecessary redirect chains exist.
- Removed URLs without replacements return 404/410.
- Canonicals do not reference staging or the old domain.
- Production robots.txt does not block important sections.
- No accidental noindex directive remains.
- Internal links use current URLs.
- The new sitemap is available.
- Hreflang references current language URLs.
- Structured data contains current URLs.
- GA4 and GTM are collecting data.
- Forms and checkout work.
- Important templates render correctly.
- Run a full crawl of the production website.
- Inspect several important URLs in Search Console.
For migrations involving more JavaScript, it is also worth reviewing rendered output using URL Inspection and Google’s other testing tools.[9][12]
When should you use Change of Address in Google Search Console?
The Change of Address tool has a specific purpose and should not be used for every website migration.
Google recommends it when moving a site from one domain or subdomain to another.
It should be used after the migration has been implemented and the redirects are already working.[11]
Do not use it for:
- HTTP → HTTPS migration;
- normal path changes within the same domain;
- hosting-only migrations.[11]
Stage 6. How should a migration be monitored?
A migration does not end when the new website goes live.
Google explains that site moves are processed on a URL-by-URL basis.
Rankings may fluctuate temporarily after a significant change, and for small and medium-sized websites it can take several weeks for most URLs to move through the index.
Larger sites can take longer.[1]
Monitoring should therefore be divided into stages.
The first 24 hours
Start with critical failures.
These are not problems to “watch for two weeks”.
They should be investigated and fixed as quickly as possible.
The first week
Monitor:
- Google Search Console;
- important new URLs;
- 404 and soft 404 responses;
- Google-selected canonical;
- redirect behaviour;
- organic sessions in GA4;
- conversions;
- another crawl of the old URL list.
URL Inspection allows you to review the indexed version of a page, run a live URL test and see Google’s selected canonical.[12]
The first month
Over a longer period, compare:
- organic clicks and impressions;
- landing pages;
- important queries;
- indexing;
- conversions;
- sales or leads;
- visibility of important landing-page groups.
Do not evaluate the success of a migration using only “average position”.
The objective is to successfully transfer valuable organic traffic and business results to the new version of the website.
Is a drop in visibility normal after migration?
Fluctuation can be normal.
An unlimited drop is not.
Google states that temporary ranking fluctuations can occur after significant site changes while the new URLs are crawled and indexed.[1]
That does not mean every decline should simply be blamed on the migration.
If after launch:
- important URLs return 404;
- the site contains noindex;
- robots.txt blocks the whole site;
- new pages have incorrect canonicals;
- old URLs were not redirected;
- Googlebot receives widespread 5xx responses;
there is a concrete technical issue to investigate.
How long should redirects remain in place?
Google’s main site migration documentation recommends keeping redirects for as long as possible — generally for at least one year.
Google also notes that from a user perspective, keeping them permanently may make sense.[1]
The Change of Address documentation additionally refers to a minimum period of 180 days for that specific process and recommends keeping redirects longer if they continue to receive traffic.[11]
Important internal links and valuable external backlinks should still be updated to the new URL where practical, rather than relying forever on redirects.
Google also recommends updating your own links and, where possible, important external backlinks after a move.[1]
This work should sit inside the broader process of SEO services, not as a one-off technical task.
A migration without URL changes can still affect SEO
Keeping the same URLs makes a migration considerably easier, but it does not guarantee that organic performance will remain unchanged.
A redesign can change:
- content;
- navigation;
- internal linking;
- breadcrumbs;
- headings;
- structured data;
- rendering;
- HTML delivered to Googlebot;
- performance;
- meta robots directives;
- canonical tags.
If the new version removes important information or makes key content harder for search engines to access, keeping the same URL alone will not protect its previous search performance.
Technology migrations deserve particular attention.
Google can render JavaScript, but it also documents differences and limitations in the crawling and rendering process.
If important content is not present in the final rendered HTML, Google cannot index it.[9]
Common SEO migration myths
Myth 1: A 301 redirect loses PageRank
Google states that 301 and other permanent redirects do not cause a loss of PageRank.[1]
That does not mean a poorly executed migration automatically preserves existing visibility.
A redirect is only one part of the migration.
Myth 2: Every old page must be redirected somewhere
No.
If the resource no longer exists and there is no similar replacement, a correct 404 or 410 response is appropriate.[5]
Myth 3: All old URLs can be redirected to the homepage
Unrelated redirects may be treated as soft 404s.[1]
Myth 4: If the URLs stay the same, SEO is safe
The URL can remain unchanged while the content, indexability, architecture or rendering changes substantially.
Myth 5: Submitting the new sitemap is enough
A sitemap helps Google discover preferred URLs, but it does not replace URL mapping, redirects, correct canonicals and internal linking.[1][6][7]
Myth 6: Change of Address should be used for every migration
No.
The tool is designed for specific domain/subdomain moves and is not used for ordinary path changes within the same domain.[11]
SEO migration checklist
Before launch
- crawl the existing website;
- export GSC and GA4 data;
- collect current sitemaps;
- identify URLs with backlinks;
- save existing redirects;
- prepare an old URL → new URL map;
- define URLs that remain 200;
- define URLs requiring 301/308;
- identify removed URLs that should return 404/410;
- compare staging with the current site;
- review canonicals;
- review robots and meta robots;
- check hreflang and structured data;
- confirm conversion tracking works.
Launch day
- deploy the new environment;
- activate redirects;
- test important status codes;
- check redirect loops and chains;
- review robots.txt;
- confirm no accidental noindex remains;
- review canonicals;
- test internal linking;
- check sitemap;
- verify GA4/GTM;
- test forms and checkout;
- run a full production crawl.
After migration
- monitor GSC;
- inspect important URLs using URL Inspection;
- monitor 404 and soft 404 responses;
- compare organic landing pages;
- monitor conversions;
- retest old URLs;
- review Google-selected canonicals;
- update important external links;
- do not remove redirects prematurely.
Summary
A safe website migration is not simply a matter of preparing a redirect file.
The full process matters:
INVENTORY
→
MAPPING
→
STAGING
→
DEPLOYMENT
→
VALIDATION
→
MONITORING
Every important old URL should have a defined outcome.
If it has a direct replacement, redirect it to the new location.
If the content has been consolidated, redirect it to the relevant consolidated resource.
If the page has genuinely disappeared and has no replacement, a correct 404 or 410 response may be entirely appropriate.
At the same time, the new URLs should form a consistent system with canonical tags, internal linking and the sitemap.
The more useful data you preserve before the migration, the easier it becomes to distinguish normal indexing changes from a genuine technical problem after launch.