Website Migration SEO Checklist: Redirects, Tests and Rollback
Which website migration tasks decide whether rankings hold, and in what order do you do them?
Updated
Google advises changing one thing at a time in a website migration, such as the domain first and the CMS or layout later, so you can trace any traffic drop to its cause.
The redirect map is the highest-stakes artifact in any move. Work each table in order, and give every task one named owner before the move starts.
Related guides: technical and on-page SEO checklist, SEO quick wins checklist for fixes before a move, SEO audit tool for crawling the old and new site, image SEO for moved image URLs, Bing and other search engines.
Pick Your Website Migration Type First, Because It Sets the Steps
Name the migration type before you plan any other task. The type decides whether you need redirects, a Change of Address request, or only a DNS switch.
A hosting or CDN change that keeps the visible URLs has its own guide, with a DNS switch and no redirects.
Change one thing at a time. Google advises a domain move first, then a CMS or layout change, rather than one release for both.
Use the SEO guide for the wider program around a move.
Migration types at a glance
| Type | What changes | Do URLs change? | Change of Address? | Main risk |
|---|---|---|---|---|
| Domain | The domain name, such as example.com to example.net, or merged hostnames. | Yes | Yes, for a domain or subdomain move. | Old URLs with no 301 to an equivalent page. |
| Platform or CMS | Templates, rendering and often the URL pattern. | Depends on the URL map. | No, unless the domain also changes. | Links that are not anchor elements with an href, which Google cannot follow. |
| HTTPS | The protocol, from http to https. | Yes | No. | HTTPS pages that redirect through HTTP, use a bad certificate, or point to HTTP canonicals. |
| URL structure | Paths, such as pages moved under a new folder. | Yes | No. Add redirects and update sitemaps. | A redesign combined with the move, which Google says will probably lose some traffic. |
| Hosting or CDN | The server, host or CDN, with the visible URLs unchanged. | No | No. | Crawl or DNS failures, and firewalls that block Googlebot. |
Migration type tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Classify the migration type and write it in the plan | The type decides whether you need redirects, a Change of Address request, or only a DNS switch. | Name one type for each part of the project. A mixed project gets one line per type, with its own steps. | Google site move guide, Google hosting move guide |
| Split combined projects into separate launches | Google says a site move combined with a redesign will probably lose some traffic while Google relearns the pages. | Write the launch order in the plan: domain first, then layout or CMS, each in its own release. | Google site move guide, Change of Address help |
| For an HTTPS move, remove every HTTPS-to-HTTP path | Google keeps the HTTP page as canonical when the HTTPS page has a bad certificate, insecure dependencies other than images, a redirect through HTTP, or an HTTP canonical. HSTS does not override that preference. | Test the certificate, mixed-content dependencies, canonicals, and sitemap and hreflang URLs for any http:// value. | Google canonicalization guide |
Before You Touch Anything: Benchmark, Crawl and Map the Old Site
Record the old site before any change. The baseline and the crawl are the reference you compare against after launch.
Google names sitemaps, server logs or analytics, and the CMS as sources for the old URL list.
Google also asks for two lists at the final move: a sitemap of the new URLs, and the sites that link to your old URLs.
A wildcard redirect can replace a URL list in a pure domain change. A complex move needs a generated mapping of old to new URLs, kept in a database or in rewrite rules.
Include videos, images, JavaScript and CSS URLs in the plan. Google says they need the same move as pages.
Verify every variant of the old and new sites in Search Console before launch, including the HTTP and HTTPS variants.
Expect heavier crawling after the move. Google says it crawls the new site more heavily than usual for a time.
Move during a recurring traffic dip if your traffic has one. Small and medium sites move all URLs at once. Large sites can test with a section that changes less often.
The Performance report opens on the past three months by default, so export the baseline now.
Run the SEO audit tool on the old site before the move and on the new site after it. For a free crawler and a log analyzer, see free SEO tools and resources.
Preparation tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Export baseline organic clicks, impressions, queries and pages from Search Console | You need this baseline for the comparison at each checkpoint after the move, and the live reports only show recent periods. | Export queries and pages for a full period before launch. Save the files outside Search Console, with the launch date in the file name. | Search Console Performance report help |
| Snapshot rankings, indexed page count, organic sessions, conversions and revenue | Seer Interactive advises benchmarking these measures before a move. You need the same measures at each checkpoint to tell a dip from a loss. | Record each measure by template and for the top landing pages, with the date. Take the indexed page count from the Page indexing report. | Seer Interactive checklist |
| Crawl the old site fully and save the crawl | The crawl is the reference for status codes, titles, canonicals, internal links and hreflang on the old site. | Crawl the whole site with Screaming Frog or a similar crawler, and save the export before any change. | Seer Interactive checklist |
| Build one URL inventory from a crawl, Search Console, analytics, sitemaps and the CMS | Sitemaps alone miss old orphaned pages that still hold links. Google also names server logs and the CMS as sources for old URLs. | Merge the lists, remove duplicates, and add image, PDF, JavaScript and CSS URLs. | Google site move guide, Seomator checklist |
| Snapshot the backlink profile and mark the most-linked URLs | A missed redirect costs the most on URLs with many links. Google also advises a list of sites linking to the old URLs. | Export referring domains for each old URL, then mark the URLs with the most referring domains as must-not-break. | Google site move guide, Seomator checklist |
| Build the 1:1 redirect map (old URL, new URL, type, status) | It is the highest-stakes artifact in the move. Google says people often redirect to wrong or non-existent URLs on the new site. | Keep one target for each old URL, use a 301 or 308 for each move, and test that every target returns a 200 status. | Google site move guide |
| Decide the fate of every old URL: redirect, merge, or 404 or 410 | Google treats 404 and 410 the same and removes those URLs from the index. Merged content can redirect to one new page. | Add a decision column to the map. Give each 404 or 410 a reason, and consider a 301 for any URL that still has links. | Google HTTP status guide, Google site move guide |
| Verify all old and new property variants in Search Console | Google advises covering every variant of both sites, including www, non-www, HTTP and HTTPS, so Search Console collects data for each one. | Add each variant as a property, or add a Domain property, which covers all protocols and subdomains and uses a DNS record. | Google site move guide, Search Console property types help |
| Copy settings to the new property: disavow file and crawl rate | A disavow file uploaded to the old site must be uploaded again in the new site's account. Google also asks for the crawl rate setting on both sites. | Upload the disavow file in the new account. Set the crawl rate to Let Googlebot determine on both sites. | Google site move guide |
| Check server capacity and warn the host | Google crawls both the old and new URLs after a move, so the server needs room for the extra requests. | Confirm the new server and CDN can handle the higher crawl load for weeks. Send the host the planned move date. | Google site move guide |
| Pick the launch window and the approach: all at once, or by section | Google advises moving in a recurring traffic dip. Small and medium sites move all URLs at once, and large sites can start with a stable section. | Compare weekly and seasonal traffic in analytics to choose the window. For a large site, pick a section that changes less often for the first move. | Google site move guide |
| Back up files, database and DNS, and test the restore | The backup is part of the rollback plan. Seomator's checklist calls an untested backup a guess. | Restore the backup into a scratch environment, and confirm the site loads and the database holds the latest content. | Seomator checklist |
| Check a purchased destination domain for manual actions and URL removals | A used domain can carry URL removals left by the previous owner, especially a site-wide removal. | Before the move, look for manual actions and URL removals in Search Console for the domain, and clear any you find. | Google site move guide |
Staging, Noindex and Blocks: What to Remove at Launch and Why
Keep staging out of the index with authentication first, then noindex. Do not rely on robots.txt for this.
Google says robots.txt is not a way to hide pages, and a blocked URL can still be indexed from links.
A robots.txt rule can also stop Google from reading a noindex tag on the same page.
Google sees a noindex only after a recrawl, and low-importance pages can wait months for one.
Use URL Inspection to see the HTML Googlebot received for a page with noindex.
Remove the migration-only blocks from the new copy when the move starts.
For general on-page and technical checks after launch, use the technical and on-page SEO checklist.
Staging and launch-day block tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Put staging behind HTTP auth or an IP allowlist | Google suggests a test environment, perhaps IP-restricted, and says robots.txt does not hide pages. Seomator calls authentication the primary block, with noindex as a second layer. | Request the staging URL from an outside network. Confirm you get an access challenge, not the page. | Google hosting move guide, Seomator checklist |
| Prepare the production robots.txt and the noindex removal list before launch | Google advises a written list of URLs whose noindex rules come off when the move starts, so nobody guesses on launch day. | Store the final robots.txt and the removal list in the launch runbook, with one owner for each item. | Google site move guide |
| Remove staging blocks at launch, then grep the built output for noindex and Disallow | Seomator says a noindex tag usually sits in a shared template, so a homepage check misses article and product pages. | Search the built HTML of one page from each template for noindex and Disallow, before and after the deploy. | Google site move guide, Seomator checklist |
| Confirm robots.txt returns 200 or 404 (never 5xx) on the old and new hosts | A 5xx response stops Google's crawling for 12 hours. Google caches robots.txt for up to 24 hours, so an old block can last a day after you fix it. | Request robots.txt on both hosts and confirm a 200 or 404 status. A 4xx other than 429 counts as no file. | Google robots.txt guide |
| Confirm the firewall, CDN or WAF lets Googlebot reach the new stack | Google says firewall or DoS protection must not block Googlebot from reaching DNS or the hosting servers. A bot challenge looks like an outage. | After launch, check the bot-protection logs for blocked Googlebot requests, and run a live test in URL Inspection on key pages. | Google hosting move guide |
Redirect Rules: Status Codes, Chains and How Long to Keep Them
Use a 301 or 308 for every permanent move, set on the server.
Permanent redirects tell indexing that the target should be the canonical page. Temporary redirects do not, and the old URL can stay in results.
Redirect types and how Google reads them
| Redirect | How Google reads it | Use it for | Source |
|---|---|---|---|
| 301 | Permanent. Google reads it as a strong signal that the target should be canonical. | Every permanent move. | Google HTTP status guide |
| 308 | Permanent. Google treats it the same as a 301, but the two codes differ in meaning for other clients. | A permanent move where the meaning matters to other clients. | Google HTTP status guide |
| 302 | Temporary. A weak signal, and the original URL can stay in results. | A short outage, when you want the original URL to stay in results. | Google HTTP status guide |
| 307 | Temporary. Google treats it the same as a 302. | A temporary change that should read as temporary to other clients. | Google HTTP status guide |
| Instant meta refresh | Read as permanent. | Avoid it when a server-side redirect is possible. | Google redirect guide |
| Delayed meta refresh | Read as temporary. | Avoid it for moves. | Google redirect guide |
| JavaScript redirect | Google may never see it if rendering of the content fails. | Last resort, when no server-side or meta refresh option exists. | Google redirect guide |
Redirect each old URL to its final page in one hop. Google can follow up to 10 hops, but it advises one hop, and when one hop is impossible, ideally no more than 3 hops and fewer than 5.
Send consolidated pages to one new page. Do not send many unrelated old URLs to the home page.
Google says 301 and other permanent redirects do not cause a loss in PageRank. Google also says people often redirect to URLs that do not exist on the new site, so test every target.
Google's guides set two floors for keeping redirects. The site move guide says generally at least one year. The Change of Address help says at least 180 days, and longer if Google traffic still reaches the old URLs. Keep redirects for at least one year, the longer floor.
Google's guides disagree on URL Inspection and redirects. The site move guide names URL Inspection for testing single URLs. The HTTP status guide says Google's inspection tools do not follow redirects. Test old URLs with a crawler or script that follows the chain, and test each new URL in URL Inspection.
Redirect URLs are not indexed, only the target is. Expect Page with redirect rows for the old URLs in the Page indexing report.
Redirect map tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Use 301 or 308 for every permanent move, server-side | Google says a server-side redirect has the best chance of being read correctly. Avoid JavaScript redirects, which Google may never see if rendering fails. | Read the response for each old URL. Confirm a 301 or 308 status and a server-side redirect. | Google redirect guide |
| Make every redirect one hop to a 200 page | Google advises redirecting to the final destination directly. Chains add latency, and some browsers do not support long chains. | Flatten chains in the map. In the crawl, each old URL should show one redirect and a final 200 status. | Google site move guide |
| Never redirect many unrelated URLs to the home page | Google says this can be treated as a soft 404. Consolidated content is the exception: many old pages can redirect to one new page that replaces them. | Count the old URLs that point to each target. Review every target with many unrelated sources. | Google site move guide |
| Return 404 or 410 for deleted URLs with no equivalent, and 301 those that still have links | Seer Interactive advises a 301 for a dropped URL with links, so most of that link value is kept. Google treats 404 and 410 the same. | Mark each deleted URL in the map as 404 or 410, or as 301 when it has links. Confirm each one returns that status. | Google HTTP status guide, Seer Interactive checklist |
| Test the whole map with a crawler or script, not by hand | Google's HTTP status guide says its inspection tools do not follow redirects, so a crawler that follows the chain fills that gap. The Page indexing report lists chains that are too long, loops and bad URLs. | Test each old URL for its hop count, final URL, final 200 status and loops. Test http, https, www and non-www on the old host. | Google site move guide, Google HTTP status guide, Page indexing report help |
| Keep robots.txt on the old host free of long redirect chains | Google follows at least five redirect hops for robots.txt, then treats the file as a 404. It does not follow JavaScript or meta refresh redirects for robots.txt. | Request the old host's robots.txt and count the hops in the response. Remove any redirect on that path. | Google robots.txt guide |
| Handle Bing with 301s, a new sitemap and IndexNow, since Bing has no move tool | A Microsoft reply in the Bing Webmaster community, from August 2024, says the Site Move tool is no longer available and recommends server 301s. | Submit the new sitemap in Bing Webmaster Tools, and send added, updated or deleted URLs through IndexNow. Confirm the current Bing menu before you plan around it. | Bing community reply, IndexNow documentation |
| Keep redirects live for at least one year | Google's site move guide says generally at least one year. Its Change of Address help sets a floor of 180 days, so plan around the longer figure. | Put a removal date at least one year out in the plan. Extend it while links or Google traffic still reach the old URLs. | Google site move guide, Change of Address help |
Launch Day: Point Canonicals, Hreflang, Sitemaps and Links at the New URLs
Point every launch-day signal at the new URLs: canonicals, hreflang, sitemaps and internal links.
Google advises absolute paths, not relative paths, in rel=canonical.
Hreflang needs the same care. Every alternate must link back to the page it points to, and every alternate must use a full http or https URL.
A sitemap file holds 50MB uncompressed or 50,000 URLs, so split a larger site into an index file.Google uses lastmod only when it is consistently accurate, and it ignores priority and changefreq.
Ask sites that link to your old URLs to update, starting with the links that bring the most visits.
Move images and downloads such as PDFs with the same care, because they can hold traffic and links.After the move, read the image SEO guide for image formats and layout.
Submit added, updated or deleted URLs to IndexNow for the engines that participate.
Launch-day tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Use a self-referencing absolute canonical on every new URL | Each new URL should carry a self-referencing canonical. Once redirects are live, canonicals on the new site must use the new URLs. | Fetch one URL per template and confirm the canonical is the absolute new URL, not the old one. | Google site move guide, Google canonicalization guide |
| Update hreflang to the new URLs, with return links and x-default | Hreflang annotations must use the new URLs. Google may ignore them when a page does not link back to the page it points to. | Confirm each alternate links back, uses full http or https URLs, and that x-default covers unmatched languages. Skip this task for single-language sites. | Google localized versions guide |
| Publish a new sitemap with only final 200 URLs, and submit it | Google says to submit the new sitemap. A sitemap file holds 50MB uncompressed or 50,000 URLs, and Google uses lastmod only when it is accurate. | Include absolute URLs that answer 200, with no redirects or noindex pages. Split into an index file at the limit, and set lastmod only to dates that match the page. | Google sitemaps guide, Google site move guide |
| Keep the old-URL sitemap submitted for monitoring | Google says the old-URL sitemap shows redirect warnings that you can ignore, and its indexed count falls as the new sitemap's count rises. | Submit both sitemaps. Ignore redirect warnings on the old-URL sitemap only, and track both counts each week. | Google site move guide |
| Rewrite internal links to the final URLs in the same release | Google says to replace internal URLs based on the mapping. An internal link that goes through a redirect adds a hop for users. | Crawl the new site and list each internal link that answers with a 3xx status. Fix every one. | Google site move guide |
| Update external, social and ad links, top inbound first | Google suggests prioritizing outreach by the number of inbound visits for each link. | Sort the inbound links to old URLs by visits, using analytics. Update the top ones first, then social profiles and ad campaigns. | Google site move guide |
| Lower the DNS TTL a week ahead for hosting moves, and monitor propagation | Google suggests lowering the TTL at least a week before a hosting move, to a few hours, so DNS caches refresh faster. | Note the current TTL on each record, and lower it a week before the move. Watch propagation from more than one location, and keep the old host live. | Google hosting move guide |
| Verify analytics and conversion tracking on the new templates, and annotate the launch | Seomator notes that broken tracking looks exactly like a traffic collapse, so rule out a measurement fault before you diagnose an SEO loss. | Confirm each template fires the analytics and conversion tags in the real-time reports. Add a launch annotation with the date. | Seomator checklist, Seer Interactive checklist |
| Move images and PDFs with the same redirect rules, and keep image URLs stable | Images and downloads such as PDFs can hold traffic and links. Google says to reference an image with the same URL so it can be cached and reused. | Add image and PDF URLs to the map. Return a 301 where a URL changes, and leave image URLs unchanged where you can. | Google site move guide, Google Images guide |
Change of Address: When to Submit It and What It Requires
Use Change of Address only for a domain or subdomain move, and only after the redirects are live.
You need owner access to both properties under one Google account. The tool works only on domain-level properties, so a path cannot be moved with it.
The tool does not move subdomains, including www. It does move every protocol of the source property and every path under the domain.
After you submit, Google shows an in-progress notice for 180 days. During that time Google emphasizes crawling the new site, forwards signals, and prefers the new site for canonical pages.
Google does not erase the old site from the index. Old URLs can keep showing when they have no equivalent page on the new site.
Seer Interactive advises submitting the change only for the site that moves, not for the destination site.
Bing has no move tool. A Microsoft reply in the Bing Webmaster community, posted in August 2024, says the Site Move tool is gone and recommends server 301s. For Bing and other engines, see the search ecosystem page.
Change of Address tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Check the Change of Address prerequisites | You must own both properties under one Google account, and the tool works only on domain-level properties, not on paths. | Confirm owner access to both properties under the same account, and confirm the old property is at domain level. | Change of Address help |
| Redirect the old homepage and canonical pages with 301 before you submit | Google asks for a 301 from the old homepage to the new one, and recommends 301s for the canonical pages. The tool runs a quick check for 301s on a few pages. | Test the old homepage and the top canonical pages before you open the tool. Fix every critical pre-move failure the tool reports before you continue. | Change of Address help |
| Submit Change of Address for every old host variant, then check each one | The tool does not move subdomains, including www. It does move every protocol and every path under the domain. Google says to use it for unused www and non-www variants too. | List every host variant in Search Console. Submit a request for each domain or subdomain change, and skip HTTP to HTTPS, www to non-www and path moves. | Change of Address help, Google site move guide |
| Do not chain or stack moves: one move at a time into a shared destination | Google says you cannot submit a second move from the new site right after the first. Merging several sites at once can cause confusion and traffic loss. | Finish one move, wait until traffic stabilizes, then start the next. Record the date each move finished. | Change of Address help |
Post-Launch Monitoring: What to Watch Week by Week
Watch the old and new sites side by side for the first weeks. Google expects traffic on the old site to fall while the new site's traffic rises.
A small to medium site can take a few weeks for most pages to move, and larger sites take longer. The move is complete only when Googlebot has visited every old and new URL at least once.
Rankings can fluctuate during the move, and then settle. Google calls this normal.
Expect a temporary drop in crawl rate right after launch, followed by a steady increase over the next few days.
Crawl Stats marks the host status red when robots.txt, DNS or server connectivity has a significant error in the last week.
Google removes URLs that persistently return a server error from the index. Short outages keep indexed URLs for a while.
Core Web Vitals on a new template take weeks to show, because the Chrome UX Report data is a 28-day rolling average.
The Page indexing report limits its example list to 1,000 URLs, so use it to find patterns. Live URL Inspection does not test duplicate or canonical conditions.
Monitoring calendar
| When | What to check | Source |
|---|---|---|
| Day 1 to day 7, daily | 404s, failed redirects and index drops. | Seomator checklist |
| Day 8 to day 30, two to three times a week | Ranking trends and Crawl Stats. | Seomator checklist |
| Day 31 to day 90, weekly | Organic traffic against the baseline. | Seomator checklist |
| Week one, week two and week four | Clicks and impressions for the old and new URLs. | Webflow checklist |
| Day 28 onward | Field data for each new template. | Chrome UX Report methodology |
| Day 90, once | Full re-audit against the baseline. | Seomator checklist |
| Day 180 | The Change of Address notice and move signals end. | Change of Address help |
| One year or longer | Redirects stay live, and the old domain stays paid. | Google site move guide |
Monitoring tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Re-crawl the live site on launch day and diff it against the old crawl | Seer Interactive advises a second full crawl to confirm the changes are the ones you expect. Seomator adds that an old URL with no link on the new site is an orphan. | Compare status codes, canonicals, titles, internal links, hreflang and noindex between the two crawls. List every old URL that no new page links to. | Seer Interactive checklist, Seomator checklist |
| Check server logs daily in week one for Googlebot hits, 4xx and 5xx | Logs show Googlebot's crawling, the URLs that return errors, and normal user traffic in one place. | Filter the logs for Googlebot, and count 4xx and 5xx responses by URL each day. Log any new error pattern for the team. | Google site move guide, Google HTTP status guide |
| Watch the Crawl Stats host status for robots.txt, DNS and server connectivity | A red status means a significant robots.txt, DNS or connectivity error in the last week. | Check the host status in Crawl Stats each day in the first weeks. Treat red as an issue to fix the same day. | Crawl Stats help |
| Track the old-URL and new-URL sitemaps in the Sitemaps report | Google expects the indexed count for the old sitemap to fall over time while the count for the new sitemap rises. | Record both indexed counts each week. A new-sitemap count that stays low is a prompt to check the redirects. | Google site move guide |
| Review the Page indexing report weekly for redirect errors, noindex, soft 404 and not found | The report's example list is limited to 1,000 URLs. Live URL Inspection does not test duplicate or canonical conditions, so use the report to find patterns. | Use the report to find patterns each week. Check key URLs one by one in URL Inspection, and compare canonicals with the crawl. | Page indexing report help |
| Compare Performance clicks and impressions for old and new URLs at weeks one, two and four | Google says new URLs start to show impressions and clicks as they index, and rankings may fluctuate before they settle. | Filter by the old and new URL paths separately. Read trends across weeks, not single days. | Google site move guide, Webflow checklist |
| Check Core Web Vitals per new template once 28 days of field data exist | The Chrome UX Report uses a 28-day rolling average, so new templates take weeks to show their field data. | Review field data for each template after that window. Do not judge a new template on its first week. | Chrome UX Report methodology |
| Fix the 404s that you link to or list in a sitemap, and leave the rest | Google advises fixing only the 404s you link to or list in a sitemap. A page that has moved should return a 3xx redirect. | Filter the 404 list by internal links and sitemap membership. Fix those, then leave the rest. | Page indexing report help |
| Run a full audit at day 90 and compare it with the baseline | Seomator's monitoring plan ends with one full re-audit at day 90. It catches must-not-break URLs that stopped redirecting. | Re-run the full crawl, compare it with the baseline crawl, and confirm every must-not-break URL still redirects. | Seomator checklist |
| Keep checking until Change of Address ends at day 180, and keep redirects for one year | The in-progress notice and the move signals run for 180 days. The site move guide says generally at least one year for redirects, so the calendar needs both dates. | Put both end dates in the plan. Do not remove redirects, or let the old domain lapse, before those dates. | Change of Address help, Google site move guide |
Website Migration Rollback: When to Revert and Who Decides
Write the rollback rules before launch, not during it. Google publishes no rollback thresholds, so the triggers below are recommended judgement, not Google rules.
Google's published failure signals are robots.txt errors, host connectivity errors and persistent server errors.
Recommended triggers, each one a judgement call:
- robots.txt returns a 5xx, or production carries a blanket Disallow or noindex. Roll back while the old host is still up.
- Crawl Stats host status turns red for DNS or connectivity. Roll back while the old host is still up.
- Persistent 5xx errors appear on the new host. Roll back while the old host is still up.
- A must-not-break URL fails its redirect test and cannot be fixed on launch day. Fix forward instead of rolling back.
- Conversion tracking is lost. Fix forward instead of rolling back.
A rollback for a hosting move is a DNS change, and it works only while the old host still runs.
For a domain move, Google documents the cancel steps. Remove the old 301s from the server, add 301s from the new site back to the old one, then open the Change of Address tool on the old property and click Cancel Move.The cancel works for 180 days after the request.
Expect a long recovery for a domain move. A Search Engine Journal study of 892 domain migrations found an average of 523 days for the new domain to match the old estimated traffic.
The same study found that 17% of migrations had not recovered after 1,000 days. Its 2023 study of 171 migrations averaged 229 days and found that 42% did not return at all, and the 2026 sample is about five times larger.
The study estimated traffic with SEO tools, with a high share of its data from Ahrefs and volunteer submissions. It did not use each site's own analytics. Treat these figures as a range for planning, not as a forecast for your site.
For help running a move, see SEO services.
Rollback and recovery tasks
| Task | Why it matters | How to check | Source |
|---|---|---|---|
| Write go/no-go and rollback criteria before launch, and name the rollback owner | Seomator recommends three to five binary conditions, with a named rollback owner. Google sets no rollback thresholds, so the criteria are your own judgement. | Write three to five yes or no conditions, for example: redirect map complete, staging crawl clean, backup tested, rollback owner named. | Seomator checklist |
| Keep the old host and a restorable backup live until old-host traffic is zero | Google says the old hosting can shut down once its traffic reaches zero. A hosting rollback is a DNS change. | Track old-host traffic in the logs until it reaches zero. Keep the backup restorable until then. | Google hosting move guide, Seomator checklist |
| Write the Change of Address cancel procedure into the runbook | Google's cancel works for 180 days after the request. The old 301s must come off the server first, or Google may keep following them. | Write three steps in the runbook: remove the old 301s, add 301s from the new site back to the old, and click Cancel Move on the old property. | Change of Address help |
| Set stakeholder expectations with the recovery data | One Search Engine Journal study of 892 domain migrations found an average of 523 days for the new domain to match the old estimated traffic. Its figures are estimates from SEO tools, not each site's own analytics. | Put these figures in the plan with the method limit beside them, so nobody reads an estimate as a forecast. | Search Engine Journal study |
Common Questions
How many redirect hops can a migration afford, and what does each extra hop cost?
Google says it can follow up to 10 hops, but its site move guide advises redirecting straight to the final URL. If that is not possible, keep the chain ideally to no more than 3 hops and fewer than 5. Each extra hop adds latency for users, and not every browser supports long chains. Search Console's Crawl Stats report also counts each hop as a separate request, so long chains add to the load on your server.
Do 301 redirects lose link equity, and is a 302 safer while I test?
Google says 301 and other permanent redirects do not cause a loss in PageRank, so a 301 is the right choice for a move. A 302 is a temporary redirect and a weak signal, and it can keep the old URL in search results. Use a 302 only when a page is down for a short time and you want the original URL to stay in results. For a move, use a 301 or a 308.
Which moves need Change of Address, and which need only redirects?
Change of Address applies only when a whole domain or subdomain moves to another domain or subdomain. An HTTP to HTTPS switch, a move from www to non-www and a change of paths inside one site do not use it. Those moves need redirects, canonicals and updated sitemaps. For a domain move, submit the change for every variant of the old domain you have added to Search Console, including unused www and non-www hosts, from an account that owns both properties.
How long should I keep redirects and the old domain?
Keep redirects for at least one year. Google's site move guide says generally at least one year, while its Change of Address help says at least 180 days, and longer if Google traffic still reaches the old URLs. Use the longer figure. Keep paying for the old domain for at least a year as well, because Google sees no relationship between the two sites after 180 days, and an abandoned domain can be used for abuse.
How do I tell a traffic dip from a failed migration?
Judge the move in weeks, not days. Google says a small or medium site can take a few weeks for most pages to move, and rankings can fluctuate before they settle. Watch the indexed page counts for the old and new sitemaps first, because a low count on the new side can point at the redirects. Compare every measure with your pre-launch baseline. Estimates from SEO tools put recovery much longer: one study of 892 domain migrations found an average of 523 days to match the old estimated traffic.
Can I roll back after I submit Change of Address?
Yes, for 180 days after the request. Google's steps are to remove the 301 redirects on your server that send traffic from the old site to the new one, add 301 redirects from the new site back to the old one, then click Cancel Move in the Change of Address tool on the old property. Skip the first step and Google may keep following the old redirects after the cancel, so remove them before you cancel.