Pages Not Indexed After a Migration
After a migration you expect the new addresses to replace the old ones in search results. An indexation gap is when that does not happen: the old pages drop out but the new ones are not indexed in their place, or only part of the site makes it in.
It shows up as falling impressions, a shrinking indexed count in Search Console, and pages that cannot be found even when you search for their exact title. This guide explains how to read each status in the Page indexing report after a move, what each one means in a migration, and how to clear it.
What an indexation gap looks like
During a normal move, old and new addresses overlap for a while. Old URLs move into the "Page with redirect" group as Google recrawls them, and the matching new URLs appear in the indexed count. An indexation gap is when the second half does not follow the first. The common signs are:
- The number of indexed pages for the new setup stays well below the number that were indexed before.
- Whole sections, such as the blog or a product category, are missing while others are fine.
- URL Inspection on an important new page says "URL is not on Google".
- Impressions fall in the Performance report and do not come back as the old pages drop out.
The Site Migration Audit checks indexing as part of comparing the old site with the live one, alongside lost URLs and redirect coverage. Use its findings to spot which sections are affected, then use Search Console to see why Google has not indexed them.
site: search operator to measure indexation. Its
result count is an estimate and changes from one search to the next. The Page indexing report and URL
Inspection are the reliable sources.The statuses that matter after a move
The Page indexing report in Search Console groups every known URL by a reason. After a migration, some groups are expected and some point to a fault.
| Status | For old URLs | For new URLs |
|---|---|---|
| Page with redirect | Expected. Google has seen the redirect. | A fault. A new URL should not redirect; your internal links or sitemap point at a non-final address. |
| Excluded by 'noindex' tag | Rare, unless old pages were deliberately noindexed. | Usually a staging setting carried into production. |
| Blocked by robots.txt | Can stop Google from seeing the redirect at all. | A staging robots.txt or a new rule blocking a folder. |
| Not found (404) | An old URL with no redirect. See the lost URLs guide. | A link or sitemap entry for a new page that does not exist. |
| Server error (5xx) | Redirect layer failing under load. | New platform struggling with crawl volume. |
| Redirect error | A chain that is too long, a loop, or a redirect to an invalid URL. | Same. |
| Duplicate, Google chose different canonical than user | Not usually relevant. | Canonicals, redirects or links disagree about the main address. |
| Crawled, currently not indexed | Not relevant. | Google fetched the page but chose not to index it yet. |
| Discovered, currently not indexed | Not relevant. | Google knows the address but has not fetched it yet. |
| Soft 404 | Old URLs redirected to an unrelated page. | Thin or empty new pages, such as categories with no products. |
Filter the report by sitemap to focus on new URLs only. When you submit a sitemap that lists just the new addresses, you can pick it in the report's filter and ignore the noise from old ones.
Staging settings that travel to production
The most damaging and most common cause is a block set up to keep the development site private that was never removed. Check these first, on the live site, before anything else:
- robots.txt containing
Disallow: /for all user agents. - A robots meta tag such as
<meta name="robots" content="noindex, nofollow">in the head of every page. - An
X-Robots-Tag: noindexheader set in server configuration, a CDN rule or a hosting control panel, which does not show in the page source at all. - Password protection or IP allow lists left on part of the site, which return 401 or 403 to crawlers.
- Platform switches, such as the WordPress Reading setting that discourages search engines, or a Shopify store password left enabled.
curl -s https://example.co.uk/robots.txt
curl -sI https://example.co.uk/services/ | grep -i x-robots-tag
curl -s https://example.co.uk/services/ | grep -i 'name="robots"'A combination to watch for: a page blocked in robots.txt and also marked noindex. Google cannot crawl the page, so it never sees the noindex, and the URL can sit in the index with no description. Remove the robots.txt block when you want a noindex to be read. The noindex and disallow guide covers that conflict in detail.
When Google crawls but does not index
"Crawled, currently not indexed" and "Discovered, currently not indexed" are not errors in the technical sense. They mean Google has not yet decided the page is worth indexing, or has not got round to fetching it. After a migration these groups can grow for reasons you can influence:
- Content lost in the new templates. A category page that had a useful introduction on the old site may now be a grid of products with no text, or a product page may have lost its description. Compare old and new versions of affected pages side by side.
- Weak internal linking. New pages that are only reachable through a search box, filters or a JavaScript menu are found slowly and look unimportant.
- Many near-identical pages. New platforms sometimes generate addresses for every filter, sort order or tag, which spreads crawling across low-value URLs.
- Server strain. If the new host responds slowly or with errors, Google reduces how fast it crawls. The Crawl stats report under Settings in Search Console shows response times and errors.
Google has said there is no minimum word count, so do not pad pages. Restore the information that made the old page useful, link to it from relevant pages, and let it be recrawled.
The fix, step by step
Step 1
Compare indexed counts for the old and new setup
Open the Page indexing report for the property that covers the new site and note the indexed count. If the domain changed, open the old property too and note how many pages it had indexed before launch. Use the Site Migration Audit results to see which sections of the new site are affected. A gap confined to one section usually has one cause, while a site-wide gap usually means a block.
Step 2
Remove anything blocking crawling or indexing
Fetch the live robots.txt, check the head of several templates for a robots meta tag,
and check response headers for X-Robots-Tag. Look for platform switches that discourage
search engines, store passwords and IP restrictions. Remove every block intended for staging. Then use
URL Inspection with the live test on one page from each template to confirm Google can crawl it and that
indexing is allowed.
Step 3
Export the not-indexed groups for the new URLs
In the Page indexing report, filter by the sitemap that lists only new addresses so old URLs do not cloud the picture. Open each reason in the Why pages are not indexed table and export the example URLs. Put them in one spreadsheet with the status as a column, then sort by section or template so you can see whether one group of pages shares one cause.
Step 4
Fix each status group at its cause
For Page with redirect on new URLs, update links and sitemap entries to the final address. For noindex and robots.txt groups, remove the rule. For 404s, restore the page or correct the link. For canonical disagreements, align the tag with the redirect destination. For crawled but not indexed, compare the page with its old version and restore missing content and internal links before asking for a recrawl.
Step 5
Submit a clean sitemap of the new addresses
Generate an XML sitemap that lists only new, indexable, final URLs that return 200, with no redirects, errors or noindexed pages. Submit it in the Sitemaps report of the new property and in Bing Webmaster Tools. Check that robots.txt references it. A clean list helps crawlers discover new pages sooner and gives you a precise filter for measuring indexation of exactly the pages you care about.
Step 6
Tell Google about a domain change
If the migration changed the domain, verify the new domain in Search Console, confirm that the old home page and a sample of other old URLs redirect permanently to their new equivalents, then open the Change of Address tool in the old property and submit the move. The tool is only for domain changes. Moves within the same domain, including a new URL structure or HTTPS, rely on redirects alone.
Step 7
Recheck the groups and a sample of key pages
After fixing a group, press Validate fix for that reason in the Page indexing report so Google rechecks the affected URLs. Request indexing in URL Inspection for a handful of the most important pages only, since there is a daily limit. Re-run the Site Migration Audit each week and track the indexed count for the new sitemap until the gap closes or stops shrinking.
Bing and other search engines
Everything above applies to other search engines too, with a few differences in tooling:
- Bing Webmaster Tools has its own Site Move tool for domain changes and its own URL Inspection. Submit the new sitemap there as well.
- IndexNow is a protocol supported by Bing, Yandex and some others that lets you notify them when URLs change. Google does not use it. It can help Bing pick up a large batch of new addresses sooner, and several CMS plugins and CDNs support it.
- AI answer engines that use Bing's index, or their own crawlers, will also see stale or missing pages until the move is processed. Check that your robots.txt does not accidentally block their crawlers on the new site if you want to be cited.
Avoiding indexation gaps next time
- Block staging with a login, not robots rules. A password keeps the staging site private without leaving a noindex or disallow that can be copied into production.
- Put the blocks on a launch checklist. Check robots.txt, robots meta,
X-Robots-Tagand platform privacy settings within minutes of launch. - Keep content parity. Move the text, headings and internal links that made old pages useful, not just the product data.
- Prepare the sitemap in advance. Have the new sitemap generated on staging and ready to submit on launch day.
- Warm the server. Make sure the new host can handle a burst of crawling, because Google recrawls heavily after a move.
1. Why are my new pages not indexed after the migration when the old ones were?
Start with blocks carried over from staging: a robots.txt disallow, a noindex tag or header, a platform privacy switch, or password protection. After that, look at the Page indexing report status for affected new URLs, because each status has a different cause and a different fix. New pages that redirect, carry canonicals to other addresses, or lost their content in the new templates are the most common reasons once blocks are ruled out.
2. Should I request indexing for every new URL?
No. The request indexing button in URL Inspection has a daily limit and is meant for a small number of important pages. For a whole site, submit an XML sitemap of the new addresses, make sure every old URL redirects to its equivalent, and keep internal links pointing at the new URLs. Those signals scale to thousands of pages, whereas manual requests do not, and repeated requests for the same page do not speed things up.
3. Is it normal to see lots of Page with redirect entries after a migration?
Yes, for old URLs. When Google recrawls an old address and finds a redirect, it moves that URL into the Page with redirect group, which shows the redirect is being processed. It becomes a problem only when new URLs appear there, because that means your internal links, canonicals or sitemap point at an address that redirects again. Filter the report by the sitemap that lists only new addresses to tell the two apart quickly.
4. What does Crawled, currently not indexed mean after a site move?
Google has fetched the page but decided not to add it to the index for now. It is not a technical error, and some pages on every site sit there. After a migration, a jump in this group often means the new templates are thinner than the old pages, or that pages are poorly linked. Compare affected pages with their old versions, restore missing content and links, and allow time for recrawling.
5. Do I need the Change of Address tool if I only moved to HTTPS?
No. The Change of Address tool is for moving from one domain or subdomain to another, such as example.co.uk to example.com. Switching from HTTP to HTTPS, changing the URL structure or moving platform on the same domain does not use it. Those moves rely on permanent redirects from each old URL to its new equivalent, correct canonicals and an updated sitemap, all within the same Search Console domain property, which already covers both protocols.
6. Can a slow new server stop pages being indexed?
It can slow things down. Google adjusts how fast it crawls based on how quickly and reliably your server responds. If the new host returns errors or responds slowly during the burst of crawling that follows a migration, Google reduces its crawl rate, so new pages are fetched and indexed more slowly. The Crawl stats report in Search Console settings shows response times, status codes and host problems over time.
7. How do I know which pages dropped out of the index during the migration?
Compare lists. Take the pages that had impressions in the old property before launch, map each to its new address using your redirect map, and check the new addresses against the Page indexing report or the URL Inspection tool. The Site Migration Audit checks indexing as part of its before-and-after comparison, which helps highlight sections with gaps. Pages with a missing new equivalent belong in the lost URLs process instead.
The Site Migration Audit compares your pre-migration crawl with the live site, finds lost URLs, validates redirects, tracks ranking shifts, checks indexing and structured data, and audits internal links.
Open Migration Audit Fixes →