Page Deindexed: Why It Happens and How to Recover
A page deindexed after months of sitting quietly in Google’s results is a different problem from a page that never got in. Something changed: the page itself, the server, a directive somewhere in the stack, or Google’s judgement of whether the page still belongs. Almost all of it is discoverable, and most of it is repairable. The order is what people get wrong. Confirm the page actually left the index, find what changed, fix that one thing, then ask Google to look again and verify the answer against live results instead of assuming the fix took.
First, confirm the page is actually gone
Two very different symptoms get described with the same sentence. “My page disappeared from Google” can mean the page no longer ranks for the query you were watching, or it can mean the URL is not in the index at all. The repairs have nothing in common.
Search for the exact URL, and then for a distinctive full sentence from the page in quotes. If the page comes back for either, it is still indexed and you have a ranking problem, not a deindexing one. A site: query is a rough instrument rather than a definitive answer, so treat a blank result as a prompt to look further, not as proof.
If you have Search Console access, the Page indexing report will usually name the reason Google recorded, and URL Inspection will show the last crawl. That reason string is the single most useful piece of evidence in the whole investigation. Not everyone has verified access to the property, which is why the exact-phrase check is worth running first.
Why a page gets deindexed
A noindex directive arrived. A theme update, a plugin default, a staging configuration promoted to production, a CDN rule adding an X-Robots-Tag header to a whole directory. Google treats noindex as an instruction and follows it, so the page leaves cleanly and quietly, usually with nobody having decided to remove it.
The URL stopped serving the page. A 404 or 410 after a slug change. A soft 404, where the page returns 200 but the content is empty or has become a generic placeholder. A long run of 5xx errors during a migration. Sustained, and Google drops the URL.
Crawling got blocked. A Disallow rule does not deindex a page by itself, and Google’s robots.txt documentation is explicit that a blocked URL can still appear in results. What a block does is freeze the situation. Google can no longer fetch the page, so it cannot see the state of the page or any repair you make to it.
The canonical now points elsewhere. After a migration or a duplicate cleanup, a URL can be consolidated into another URL. The page looks deindexed, but it has really been merged, and the fix is a canonical correction rather than a resubmission.
A redirect swallowed it. Blanket rules written for a site move tend to catch more URLs than intended, and the casualties are rarely noticed for weeks.
Google reconsidered. Sometimes nothing on your side changed at all. Indexing is a judgement, and judgements are revisited. Thin pages, near-duplicates, pages whose subject has gone stale, and large batches of similar pages published quickly are the usual candidates. There is no error to find here, which is why this cause takes the longest to accept.
The overlap is worth naming: the causes that keep a new page out are largely the same ones that push an old page back out, which we covered in six reasons Google declines to index a page that looks fine. Deindexing is that list arriving late.
It is usually the template, not the page
One deindexed page is rarely one page. Directives, status codes and canonicals come from templates, plugins and server rules, and those apply to sets. Before you repair the URL you noticed, check three or four of its siblings: other posts on the same template, other products in the same category, other pages under the same path.
If the siblings are fine, you have a page-level cause and a small job. If they are not, you have a site-level cause and the URL you noticed was simply the one you happened to be watching. Fixing one page while a template quietly removes forty is the most expensive version of this mistake.
What recovery actually involves
Remove the cause first. A recrawl request on a page that still carries noindex achieves nothing, because Google will fetch the page, read the directive and honour it again.
Then make sure the page can be fetched: a 200 status, no block in robots.txt, real content, a self-referencing canonical if it should stand alone. Then ask Google to recrawl the URL, which asks Google to look sooner than it otherwise would.
After that it is Google’s timetable. Reindexing is not a restore from backup: the page is judged again on what it is now, and it can return quickly, return slowly, or sit in the crawled-but-not-indexed state for a while, which is a different signal worth reading on its own terms. We wrote about that state in crawled, currently not indexed. Change one thing at a time and note the date you changed it, or the next investigation starts with no timeline. The broader mechanics of how pages enter and leave the index are set out in the guide to Google indexing.
Verify the recovery, do not assume it
The temptation after a fix is to check once, see the page back, and close the tab. A single check tells you about one moment, and a page that came back after a template repair can leave again when the next deploy reinstates the rule that removed it.
What you want is the same question asked repeatedly over a period: is this URL in Google’s results today? That is the problem AIndexify was built for. Each submitted URL is checked against live Google results on a fixed schedule rather than marked done at delivery, and it reports “Indexed” with the date it was found, or “Not indexed as of” that date. The preflight helps here too: a URL still carrying noindex, a 404 or a robots block comes back as “Couldn’t check” with the credit refunded, which tells you your repair never went live.
Recovery is two events, the fix and Google’s answer, and only the second one counts. See where your pages actually stand: submit your URLs and have the answer checked against live results, with dates.