Site Migration Indexing Checklist

A migration keeps its Google index when three things hold: every old URL with value 301 redirects to its closest equivalent in one hop, the new pages are crawlable and indexable from the first minute, and you tell Google about the move with sitemaps and, for domain changes, the Change of Address tool. Most migration disasters come from a missing redirect map or from a staging noindex that went live with the site.

Use this checklist in order. It applies to domain changes, http to https, URL restructures, CMS or platform changes and merging sites.

What kind of migration is it?

Type	URLs change?	Change of Address tool?	Relative risk
Hosting or CDN change only	No	No	Low
HTTP to HTTPS	Protocol only	No	Low
Redesign or new templates, same URLs	No	No	Medium (content and internal links change)
CMS or platform change	Usually	No	High
URL restructure on the same domain	Yes	No	High
New domain	Yes	Yes	High
Merging or splitting sites	Yes	Sometimes	Highest

Google's advice is to change one thing at a time where possible. Moving domain, platform, design and content in one weekend makes it impossible to tell what caused a drop. If you have to combine, plan for extra monitoring.

Phase 1: before the migration

Benchmark

You cannot measure a loss without a baseline. Save these now:

• Search Console Performance exports (pages and queries) for the last 16 months
• Page indexing report: indexed count, plus the count for each not indexed reason
• Analytics: organic landing pages with sessions and conversions
• A rank tracking snapshot, if you use one
• Crawl stats: average requests per day and response time
• A full crawl of the old site: URL, status, title, H1, canonical, meta robots, word count, inlinks

Build the complete list of old URLs

One source is never complete. Combine:

1. The crawl of the old site
2. XML sitemaps. Extract them with the Sitemap URL Extractor
3. Search Console: Performance > Pages, and Links > Top linked pages (external)
4. Analytics landing pages for the last 12 months or more
5. Server logs: every URL Googlebot requested
6. Backlink tool exports, if you have them
7. Existing redirect rules. Old redirects have to be carried forward and re-pointed at the new final URLs

Deduplicate and normalise with the URL List Cleaner. Include PDFs, and images that receive search traffic.

Map old to new

Make a spreadsheet: old_url | new_url | type | priority.

• One to one wherever an equivalent page exists.
• Closest relevant page when several pages are merged into one.
• 404 or 410 for content that is dropped on purpose and has no equivalent. Google's guidance is clear: do not redirect many old URLs to one irrelevant destination such as the homepage. Such redirects may be treated as soft 404s.
• Prioritise by traffic, links and revenue. Check the top few hundred rows by hand.
• Prefer pattern rules (regex) for systematic changes, and explicit rules for exceptions.

Generate server rules from the map with the Redirect Rule Generator, which covers Apache, Nginx, Cloudflare and Netlify.

Prepare the new site

• Staging is protected by HTTP authentication, not by a robots.txt or noindex setup that could leak into production
• Titles, descriptions, H1s and body content carried over. Do not rewrite everything in the same release
• Self-referencing canonicals that use the new URLs
• Internal links updated to point straight at new URLs, not through redirects
• Hreflang annotations updated to new URLs, on sites that use them
• Structured data carried over, with URLs inside it updated
• A new XML sitemap containing only new, canonical, indexable URLs
• A robots.txt for the new site, reviewed line by line
• A custom 404 page that returns a real 404 status
• Analytics and tag manager installed
• Mobile pages have the same content and links as desktop
• Server capacity: Google recrawls heavily after a move. Google also advises against limiting Googlebot's crawl rate during one

Crawl the staging site and compare it with the old crawl: page count, titles, word counts, inlinks per page. Pages that lose most of their internal links in the new design are a common hidden cause of drops. See internal linking for indexing.

Test redirects before launch

Load the redirect rules on staging, feed in the full old URL list and check for each URL:

• The status is 301 (or 308), not 302
• It takes one hop, not a chain through http, then www, then the new path
• The destination returns 200
• The destination is the page you intended

The Redirect Checker traces the hops for a single URL. For the full list, use your crawler's list mode.

Search Console preparation

• Verify the new domain or prefix in Search Console before launch. For domain moves, verify both old and new
• Use DNS verification where you can, so that the verification survives the platform change
• Confirm that the old property will stay verified afterwards. If it used an HTML file or meta tag on the old platform, add a DNS record now

Timing

Choose a quiet period for the business, avoid Fridays, and make sure developers are available for the week after launch.

Phase 2: launch day

Work through this in order.

1. Deploy the site and the redirects together. Old URLs should never return 404, even for a short time.
2. Check robots.txt on the live host. No Disallow: /. Test key URLs in the Robots.txt Tester.
3. Check for noindex. View source on the homepage and one page per template. Check response headers for X-Robots-Tag. The Indexability Checker covers status, robots.txt, noindex and canonical in one pass.
4. Spot check 20 to 50 redirects from the priority list, including http and non-www variants.
5. Run the full redirect test against production.
6. Submit the new sitemap in Search Console for the new property.
7. Keep the old URL sitemap available and submitted for now. Google's site move documentation suggests this, to help it find the redirects.
8. Domain change only: use Change of Address. In the old property: Settings > Change of address, select the new property, and run the validation. The tool checks for a 301 from the old homepage and for verification of both properties. The signal is active for 180 days.
9. Inspect key URLs on the new site with URL Inspection > Test live URL, then Request indexing for the homepage and main hubs.
10. Crawl the live site and compare with the staging crawl.
11. Annotate the launch date in your analytics and reporting.

Then update what you control externally: Google Business Profile, social profiles, ad campaign URLs, email templates, and the most valuable backlinks. Ask those sites to update the link. Redirects pass signals, but a direct link is cleaner and saves a hop.

Phase 3: the first four weeks

Daily in week one, then weekly

Check	Where	What is healthy	Warning sign
Crawl errors	New property: Page indexing > Not found (404), Server error (5xx)	Few, and explainable	Hundreds of 404s: the redirect map has gaps
Old URLs processing	Old property: Page indexing > "Page with redirect" rising, indexed count falling	Steady shift	The old indexed count is not moving: redirects are not being seen
New URLs indexed	New property: indexed count rising, per sitemap	Rises over weeks	Flat, with many "Discovered" or "Crawled - currently not indexed"
Crawl rate	Settings > Crawl stats	A spike, then settling	A spike in 5xx or response time: the server is struggling
Traffic	Performance report, old and new properties added together	A dip, then recovery	A continuing decline after three to four weeks
Canonicals	URL Inspection on samples	Google-selected canonical is the new URL	Google still selects the old URL: conflicting signals

For http to https or path changes inside a Domain property, old and new URLs live in the same property. Use page filters to separate them.

Fix 404s from real data

Export "Not found (404)" from the new property, and the 404s with traffic or Googlebot hits from your server logs. Add redirects for every URL that had value, and ignore obvious junk. Repeat weekly for the first month. Background in HTTP status codes for SEO.

Tracking at scale

On large sites, checking samples by hand is not enough. The URL Inspection API allows 2,000 checks per day per property, enough to follow your priority URLs every day and the full set on rotation. TurboIndex can do this from your new sitemap: it records index status per URL, so you can see which sections are being picked up and which are stuck, and it notifies Bing through IndexNow at the same time.

Phase 4: months one to twelve

• Keep the redirects. Google recommends at least a year. In practice, keep them for as long as you own the domain
• Keep the old domain registered. If it lapses, someone else can register it and take over your old links
• Remove the old URL sitemap once most old URLs show as "Page with redirect"
• Do not reuse old URLs for different content
• Compare with the baseline at 30, 60 and 90 days: indexed pages, clicks by section, top queries
• Chase important backlinks that still point to old URLs

The mistakes that cause most migration losses

Mistake	What happens	Prevention
Staging noindex or Disallow: / goes live	The new site drops out of the index	Launch day steps 2 and 3, repeated after every deploy in week one
No redirect map, or redirecting everything to the homepage	Old URLs become 404s or soft 404s, and signals are lost	A full URL inventory and one to one mapping
302 where 301 was intended	Google is slower to treat the move as permanent	Test status codes. See 301 vs 302 redirects
Redirect chains	Slower processing and wasted crawling, and Googlebot follows only a limited number of hops	One hop to the final URL. Update the older rules
Canonicals still pointing to the old domain	Conflicting signals, and the old URLs stay indexed	Crawl the new site and filter on canonical
Internal links still pointing to old URLs	Every internal click is a redirect, which weakens the signals	Search and replace in the database, then re-crawl
Content removed or shortened "while we are at it"	Rankings drop for reasons that have nothing to do with the move	Migrate first, change content later
New templates drop internal links	Deep pages become orphans	Compare inlinks per URL before and after
Blocking the old site in robots.txt	Google cannot crawl the old URLs to see the redirects	Leave the old URLs crawlable
Losing Search Console verification	No data at the moment you most need it	DNS verification set up beforehand
JavaScript or meta refresh redirects	Weaker and slower than server-side redirects	Use server-side 301s

For how Google processes moved URLs in its pipeline, see how Google Search works.