Indexing after a site migration

What Google has to do after a move

A migration changes the address of content Google already knows. For the move to register, Googlebot must fetch each old URL, receive a permanent redirect, follow it, and process the new URL. Until that happens for a given page, Google keeps showing the old address or nothing. The slowest part is usually the old URLs: pages Google crawls rarely may not be revisited for weeks.

Google's site move guide sets out the native process. Its main points:

• Map every old URL to its new equivalent and use permanent redirects. The guide states that 301 and other permanent redirects don't cause a loss in PageRank.
• Remove any leftover noindex rules on the new site that were used to keep staging out of search.
• Test redirects with the URL Inspection tool for individual URLs, or scripts for large numbers.
• If the domain or subdomain changes, submit a Change of Address in Search Console.
• Submit sitemaps. The guide notes this can make discovery quicker and that moving in sections is fine.

The native checklist in order

1. Before launch: crawl the old site and export every indexable URL. This list is your baseline.
2. At launch: deploy redirects, publish the new sitemap, keep the old sitemap available listing the old URLs so Google revisits them.
3. Same day: verify both properties in Search Console, submit the new sitemap and file Change of Address where relevant.
4. First weeks: watch the Page Indexing report for the new property and spot-check redirects with URL Inspection.
5. Update what you control: internal links, canonical tags and hreflang should all point at new URLs, not at redirects. Google's canonical documentation treats redirects and rel="canonical" as signals, so consistency between them speeds consolidation.

Where an indexer adds value

The native route works on URLs you control. Two groups fall outside it.

Rarely crawled old URLs. Deep pages, old blog archives and long-tail product URLs may sit in Google's index under their old address for a long time. Submitting the old URLs to an indexer prompts Googlebot to fetch them, see the redirect and move on to the destination.

Pages hosting your backlinks. External links still point at old URLs. Google consolidates them through the redirect, but only when it recrawls the linking page and the old target. Where you can, ask site owners to update links; for the rest, resubmitting the linking pages helps Google refresh its view. This is the same process described in indexing guest post backlinks, applied to existing placements.

IndexChex fits this through standard submission of the old URL list (up to 10,000 per job) or a drip feed over 1 to 30 days for large sites where a sudden burst of requests to the old host is unwanted.

Verifying the move

Search Console shows what Google reports for your properties, but not for the pages linking to you. An index check over two lists gives a clearer picture:

IndexChex checks each URL with four query forms (bare URL, quoted URL, site: and inurl:); its weekly measurements on recurring URL sets put the checker at about 96% accurate on average as of October 2026. Run the check a few days after launch, then again once crawl activity settles. Old URLs still indexed after several weeks often have a redirect problem rather than a crawl problem.

Agencies running migrations for clients usually report on these three lists separately; link indexing for agencies covers the reporting side. For catalogues with thousands of moved SKUs, see indexing ecommerce product pages; for templated sections, indexing programmatic pages.

Common mistakes

• Redirecting everything to the homepage, which Google may treat as a soft 404.
• Chains of redirects from earlier migrations left in place.
• Blocking the old site in robots.txt, which stops Google from seeing the redirects at all.
• Submitting new URLs to an indexer before redirects and canonicals are consistent, so Google indexes a mixed signal.