Pages not indexed after a WordPress migration is a problem with an enormous amount written about it and almost none of it useful, because nearly every article you will find is a pre-launch checklist. Back up the database. Set up redirects. Update internal links. All correct, all published for someone who has not moved yet.
You have moved. It went wrong. Traffic is down, the Pages report has changed shape, and nobody is telling you how to find out which URLs you actually lost. That is what this is.
Why did my pages disappear from Google after a WordPress migration?
Before diagnosing, know what normal looks like, because a lot of post-move panic is normal.
Google’s site move documentation says it plainly:
“As a general rule: for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer).”
And on the wobble itself:
“With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site.”
For a host change with no URL change, Google’s separate page describes the crawl dip as expected:
“it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days, potentially to rates that may be higher than before the move.”
So a dip in week one is not a diagnosis. A specific list of URLs that used to be indexed and now are not, three weeks later, is.
How do I find every URL that got lost in the migration?
Every article on this topic tells you to compare your indexed page count to your sitemap count. A count is not a list. You cannot fix a number.
Build the list instead, in three joins:
- What you used to claim. Pull the old sitemap XML. If the old site is gone, the Wayback Machine usually has a copy of
/sitemap.xmlor/wp-sitemap.xml. - What you claim now. Pull the new sitemap. Diff the two. URLs present in the old and absent from the new are either intentionally retired or accidentally dropped, and only you know which.
- What Google says about each one. Export the Pages report per status. Then run the diff list through bulk URL inspection, which is the only step that returns per-URL truth rather than a population summary.
That third step is the one people skip, and Google’s own Page indexing report documentation explains why you cannot skip it:
“the list of example URLs in the report is limited to 1,000 items, and isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items”
The report tells you how big the problem is. It will not name every URL in it. I built the bulk URL inspection tool for exactly this shape of job, because inspecting a few hundred migrated URLs one at a time in the interface is how a two hour audit turns into a two day one.
One more thing, and it is counterintuitive. Keep the old sitemap submitted through the move. Google expects the warnings:
“Search Console may show warnings for the sitemap that contains the old URLs about the URLs redirecting; this is normal and you can ignore these warnings.”
That old sitemap is your progress meter. Its indexed count should fall while the new one rises. Two lines crossing is a migration completing.
What does “Crawled, currently not indexed” mean after a site move?
Read the reason, not the count. Four statuses show up after a migration and they mean four different jobs.
Excluded by noindex tag. Check this one first, and check it on WordPress specifically. The Settings, Reading, “Discourage search engines from indexing this site” box does not write a robots.txt block any more. It has not since WordPress 5.3. The core change says:
“In previous versions of WordPress, Disallow: / was added to the robots.txt file… This has been removed.”
“Sites with the ‘discourage search engines from indexing this site’ option enabled will display an updated robots meta tag: <meta name='robots' content='noindex,nofollow' />”
This is the single most common migration killer I see, and it is nasty because it hides. Staging sites have that box ticked. The box comes across with the database. Your robots.txt looks perfectly clean and every page carries a noindex. Anyone checking robots.txt versus noindex as if they were the same control will walk straight past it.
Alternate page with proper canonical tag. Usually the canonical still points at the staging hostname or the old domain. The page is fine, the pointer is wrong.
Page with redirect. Correct and expected on old URLs. Leave it.
Crawled, currently not indexed. Googlebot fetched the new URL and shelved it, generally because the old URL is still in the index and the two look like the same page. This one resolves as consolidation catches up, and it is the status most likely to make you do damage by panicking.
Figures from Google's site move documentation and the Change of Address tool help page.
How long should I keep 301 redirects after moving WordPress?
Longer than you think, and Google gives a number:
“Keep the redirects for as long as possible, generally at least 1 year.”
Redirect plugins get tidied up during spring cleaning and that is how a recovered migration un-recovers itself six months later. If the redirect map lives in a plugin, export it and keep the export somewhere that is not the plugin.
Two related warnings from the same document. Every old URL needs a redirect to its own new equivalent, and Google explicitly says not to take the lazy route:
“Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site… might be treated as a soft 404 error.”
That is worth knowing before you write a catch-all rule. A blanket redirect to the homepage does not preserve anything, and it manufactures soft 404s at scale.
And the finish line is defined:
“To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once.”
Both sides. Which is another reason to leave that old sitemap submitted.
Does the Change of Address tool fix a drop in traffic?
No, and its limits are documented. From the Change of Address help page:
“These actions continue for 180 days after you start migration in Search Console.”
“Google does not erase the old site from the index.”
“can be used only on properties at the domain level… You cannot move properties at the path level.”
“The tool does not move any subdomains below the specified domain (including www).”
So it does not apply to a host change, an http to https move, a www change, or a move into a subfolder. It forwards signals for six months while your redirects do the actual work for a year. If your pages are missing because of a staging noindex or a broken canonical, the tool changes nothing at all, and running it will make you feel like you have acted when you have not.
How long until rankings recover?
Google will not give you a number for recovery, only for the move: a few weeks or more, longer for large sites. Anything more precise you read is someone’s case study wearing a rule’s clothing.
What I watch instead of the calendar, in order: old sitemap indexed count falling, new sitemap indexed count rising, the noindex count going to zero, and the “Crawled, currently not indexed” bucket draining rather than growing. When those four move the right way, the move is working, whatever the traffic graph is doing that week. When week four looks like week one, something in the audit above is still broken, and it is usually the noindex.
Sources
- Move a site with URL changes, Google Search Central. Redirect retention, move duration, the soft 404 warning and the completion definition.
- Change your hosting, Google Search Central, for the expected crawl rate dip.
- Change of Address tool, Search Console Help. The 180 day window and the eligibility limits.
- Page indexing report, Search Console Help, for the 1,000 example URL cap.
- Changes to prevent search engines indexing sites, WordPress core, September 2019, for the switch from robots.txt to a noindex meta tag in WordPress 5.3.