Website Migration SEO Checklist: Redirects, Tests and Rollback

Redirects, a Change of Address request and DNS steps differ by type, so a mixed project needs one plan per type.

Check: Name one type for each part of the project. A mixed project gets one line per type, with its own steps.

Google says a site move combined with a redesign will probably lose some traffic while Google relearns the pages.

Check: Write the launch order in the plan: domain first, then layout or CMS, each in its own release.

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.

Check: Test the certificate, mixed-content dependencies, canonicals, and sitemap and hreflang URLs for any http:// value.

You need this baseline for the comparison at each checkpoint after the move. The Performance report's default view covers only the past three months.

Check: Export queries and pages for a full period before launch. Save the files outside Search Console, with the launch date in the file name.

Benchmark these measures before the move. You need the same measures at each checkpoint to tell a dip from a loss.

Check: Record each measure by template and for the top landing pages, with the date. Take the indexed page count from the Page indexing report.

The crawl is the reference for status codes, titles, canonicals, internal links and hreflang on the old site.

Check: Crawl the whole site with Screaming Frog or a similar crawler, and save the export before any change.

Google names sitemaps, server logs or analytics, and the CMS as sources for old URLs. A full crawl is a fourth source.

Check: Merge the lists, remove duplicates, and add image, PDF, JavaScript and CSS URLs.

A missed redirect costs the most on URLs with many links. Google also advises a list of sites linking to the old URLs.

Check: Export referring domains for each old URL, then mark the URLs with the most referring domains as must-not-break.

Google says people often redirect to wrong or non-existent URLs on the new site, so every target needs a test.

Check: 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 treats 404 and 410 the same and drops already indexed URLs that return them. Merged content can redirect to one new page.

Check: 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 advises covering every variant of both sites, including www, non-www, HTTP and HTTPS.

Check: Add each variant as a property, or add a Domain property, which covers all protocols and subdomains and uses a DNS record.

A disavow file uploaded to the old site must be uploaded again in the new site's account.

Check: Upload the disavow file in the new account.

Google crawls both the old and new URLs after a move, so the server needs room for the extra requests.

Check: Confirm the new server and CDN can handle the higher crawl load after launch. Send the host the planned move date.

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.

Check: 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.

The backup is part of the rollback plan. An untested backup is a guess.

Check: Restore the backup into a scratch environment, and confirm the site loads and the database holds the latest content.

A used domain can carry URL removals left by the previous owner, especially a site-wide removal.

Check: Before the move, look for manual actions and URL removals in Search Console for the domain, and clear any you find.

Google suggests a test environment, perhaps IP-restricted, with noindex on any public test host. It also says robots.txt does not hide pages. Authentication is the primary block.

Check: Request the staging URL from an outside network. Confirm you get an access challenge, not the page.

Google advises a written list of URLs whose noindex rules come off when the move starts, so nobody guesses on launch day.

Check: Store the final robots.txt and the removal list in the launch runbook, with one owner for each item.

A noindex tag usually sits in a shared template, so a homepage check misses article and product pages.

Check: Search the built HTML of one page from each template for noindex and Disallow, before and after the deploy.

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.

Check: Request robots.txt on both hosts and confirm a 200 or 404 status. A 4xx other than 429 counts as no file.

Google says firewall or DoS protection must not block Googlebot from reaching DNS or the hosting servers. A bot challenge looks like an outage.

Check: After launch, check the bot-protection logs for blocked Googlebot requests, and run a live test in URL Inspection on important pages.

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.

Check: Read the response for each old URL. Confirm a 301 or 308 status and a server-side redirect.

Google advises redirecting to the final destination directly. Chains add latency, and some browsers do not support long chains.

Check: Flatten chains in the map. In the crawl, each old URL should show one redirect and a final 200 status.

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.

Check: Count the old URLs that point to each target. Review every target with many unrelated sources.

A 301 for a dropped URL with links keeps most of that link value. Google treats 404 and 410 the same.

Check: 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'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.

Check: 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 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.

Check: Request the old host's robots.txt and count the hops in the response. Remove any redirect on that path.

Bing's Site Move tool is no longer available, so server-side 301s are how you tell Bing about a move.

Check: Submit the new sitemap in Bing Webmaster Tools, and send added, updated or deleted URLs through IndexNow, a protocol for sharing changed URLs.

Redirects keep passing signals and visitors while old links and Google traffic remain. Plan around the longer of the two Google figures.

Check: Put a removal date at least one year out in the plan. Extend it while links or Google traffic still reach the old URLs.

Each new URL should carry a self-referencing canonical. Once redirects are live, canonicals on the new site must use the new URLs.

Check: Fetch one URL per template and confirm the canonical is the absolute new URL, not the old one.

Hreflang annotations must use the new URLs. Google may ignore them when a page does not link back to the page it points to.

Check: Confirm each language version links back, uses full http or https URLs, and that x-default covers unmatched languages. Skip this task for single-language sites.

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.

Check: Include only absolute, canonical URLs. Split the list into several sitemaps at the limit, optionally with an index file, and set lastmod only to dates that match the page.

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.

Check: Submit both sitemaps. Ignore redirect warnings on the old-URL sitemap only, and track both counts each week.

Google says to replace internal URLs based on the mapping. An internal link that goes through a redirect adds a hop for users.

Check: Crawl the new site and list each internal link that answers with a 3xx status. Fix every one.

Google suggests prioritizing outreach by the number of inbound visits for each link.

Check: Sort the inbound links to old URLs by visits, using analytics. Update the top ones first, then social profiles and ad campaigns.

Google suggests lowering the TTL at least a week before a hosting move, to a few hours, so DNS caches refresh faster.

Check: 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.

Broken tracking looks exactly like a traffic collapse, so rule out a measurement fault before you diagnose an SEO loss.

Check: Confirm each template fires the analytics and conversion tags in the real-time reports. Add a launch annotation with the date.

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.

Check: Add image and PDF URLs to the map. Return a 301 where a URL changes, and leave image URLs unchanged where you can.

You must own both properties under one Google account, and the tool works only on domain-level properties, not on paths.

Check: Confirm owner access to both properties under the same account, and confirm the old property is at domain level.

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.

Check: 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.

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.

Check: 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.

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.

Check: Finish one move, wait until traffic stabilizes, then start the next. Record the date each move finished.

A second full crawl confirms the changes are the ones you expect. An old URL with no link on the new site is an orphan.

Check: Compare status codes, canonicals, titles, internal links, hreflang and noindex between the two crawls. List every old URL that no new page links to.

Logs show Googlebot's crawling, the URLs that return errors, and normal user traffic in one place.

Check: Filter the logs for Googlebot, and count 4xx and 5xx responses by URL each day. Log any new error pattern for the team.

A red status means a significant robots.txt, DNS or connectivity error in the last week.

Check: Check the host status in Crawl Stats each day in the first weeks. Treat red as an issue to fix the same day.

Google expects the indexed count for the old sitemap to fall over time while the count for the new sitemap rises.

Check: Record both indexed counts each week. A new-sitemap count that stays low is a prompt to check the redirects.

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.

Check: Use the report to find patterns each week. Check important URLs one by one in URL Inspection, and compare canonicals with the crawl.

Google says new URLs start to show impressions and clicks as they index, and rankings may fluctuate before they settle.

Check: Filter by the old and new URL paths separately. Read trends across weeks, not single days.

The Chrome UX Report uses a 28-day rolling average, so new templates take weeks to show their field data.

Check: Review field data for each template after that window. Don't judge a new template on its first week.

Google advises fixing only the 404s you link to or list in a sitemap. A page that has moved should return a 3xx redirect.

Check: Filter the 404 list by internal links and sitemap membership. Fix those, then leave the rest.

The monitoring plan ends with one full re-audit at day 90, the point to compare with the baseline.

Check: Re-run the full crawl, compare it with the baseline crawl, and confirm every must-not-break URL still redirects.

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.

Check: Put both end dates in the plan. Don't remove redirects, or let the old domain lapse, before those dates.

Set three to five binary conditions, with a named rollback owner. The criteria are your own judgement.

Check: Write three to five yes or no conditions, for example: redirect map complete, staging crawl clean, backup tested, rollback owner named.

Google says the old hosting can shut down once its traffic reaches zero, so keep it running until then.

Check: Track old-host traffic in the logs until it reaches zero. Keep the backup restorable until then.

Google's cancel works for 180 days after the request. Remove the old 301s from the server first, or Google may keep following them.

Check: 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.

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.

Check: Put these figures in the plan with the method limit beside them, so nobody reads an estimate as a forecast.