mrsaynothing.devwhy is google not indexing my site — the 199-page walk-back
Google quietly stopped indexing this site — dead slugs behind 301s. The audit, the 199-row alias map, the 410 graveyard, and the numbers ten days on.
Google stops indexing pages it keeps finding dead. Read your referrer split first — Google sessions collapsing while Bingbot still crawls is the signature. Then inspect one dead URL in Search Console and read the verdict. Fix by redirect: one hop from every old slug to its living twin,
410 Gonefor the truly dead, IndexNow ping everything, and expect the walk-back to take weeks — ours is still unfinished on day 10.
Every number below is this site's own record — the referrer split, the redirect map, the crawler census — pulled live. Last tested 2026-11-06.
Two sibling pieces from this desk covered the crawler side of the house: how to stop AI crawlers — the census of who obeys, and AI crawlers vs search crawlers — the seven-night census. Both watched who knocks. This one is about the door falling off its hinges.
How do you know Google quietly stopped indexing you?
You won't get a note. No warning, no penalty message, nothing in Search Console. The first witness is your own referrer split: weekly organic pageviews on this site ran 269 → 238 → 224 → 92 over four weeks — and the crash week was the week of a URL migration. Google referrers fell from 43 a day to 3. Organic sessions now sit at 44 for the week, −41% against the week before.
The second witness is the crawler census. While Google's referrers flatlined, Bingbot hit this site 2,325 times in seven days — named, indexed, obeying the signs. Googlebot managed 640. One engine kept walking the building; the other had lost its map. Search Console's URL Inspection on a dead page says Crawled – currently not indexed, which is Google-speak for I saw it, I thought about it, I moved on.
What breaks indexing after a site move?
The migration re-published the whole corpus under new slugs and left a redirect lane behind: every legacy blog URL guessed its new address by bolting a date onto the old name. When the guess landed right, the 301 worked. When it landed wrong — and it landed wrong 199 times — the redirect pointed at a page that did not exist.
A 301 to a missing page is a 404 wearing a borrowed coat. The crawler follows the redirect, finds nothing, and starts deleting your pages from the index — politely, a few per day, with no email.
The route layer never checked that the target existed. That is the entire bug: a redirect lane with no map underneath it. Google deindexed the dead landings one crawl at a time, and because the failures were redirects, nothing in the logs screamed — every request returned a tidy 301, then a tidy 404 behind it.
What does the fix look like?
Three moves, in order. First, the alias map: 199 rows pairing each legacy slug with the real page it should have reached, generated by matching the old corpus against what actually lives — and every match chain counted, because trust needs receipts:
| How the old slug was matched | Rows | What it means |
|---|---|---|
| name stem prefix | 131 | the old name survived inside the new slug |
| locale twin inheritance | 54 | a translated page already pointed home |
| unique date stamp | 9 | only one post carried that day |
| word-overlap score | 4 | fuzzy match, verified by hand |
| manual candidate | 1 | the one the robots argued over |
Second, the graveyard: 204 slugs with no living target got 410 Gone plus a noindex header — a 410 says gone on purpose, which search engines process faster than a naked 404. Third, the nudge: every fixed URL went out over IndexNow — 271 corpus URLs plus 235 graveyard and extras, 506 accepted in one batch. IndexNow is Bing's protocol for announcing changes the moment they land; feeding it the 410s forces a recrawl that retires the dead addresses from Bing's index inside days. You are allowed — advised, even — to tell the crawler where the bodies are buried.
Should a dead URL 301, 404, or 410?
One question decides: does the content live somewhere else?
The one thing not to do is the thing this site did for ten days: leave a redirect pointing at nothing and call it migrated.
How long does reindexing take?
Honest answer: longer than the fix took. The alias map, the graveyard and the batch ping all landed inside two days. The index is coming back slower — ten days on, Search Console's impression window is still repopulating, and organic sessions sit 41% under the week before. Bing-family traffic returned first, which matches the IndexNow lane doing its job while Google re-walks the building at its own pace.
The walk-back is not a switch, it is a tide. You can rebuild every door in a weekend; the crawler decides when to turn the handle. This site is on day 10 of that tide, and the water is still coming in.