Your old website is still in Google, and it is sending people nowhere.

We received this email on 20 September 2026 about our own site, so the worked example below is ours rather than a hypothetical.

The wording is what causes the alarm. "New reasons prevent pages from being indexed" reads like a fault. What it describes is Google reporting that it found instructions you gave it and followed them.

The test that settles it in ten minutes

There is exactly one question that matters: does any URL you want indexed redirect?

Your sitemap is the list of URLs you are asking Google to index. Your redirect rules are the instructions about which URLs go elsewhere. If those two sets overlap, you have a real problem — you are simultaneously asking for a page to be indexed and sending crawlers away from it. If they do not overlap, the report is describing retired URLs and is working as intended.

What we found when we ran it on ourselves

We checked all 64 URLs in our sitemap against all 23 redirect rules then in place. Zero matched. The report was describing the old WordPress estate we retired on purpose — the category pages, the tag pages, the old blog paths, and root-level post slugs.

So the email needed no action. But running the check properly did surface something we had got wrong, which is the useful half of this note.

The mistake we had made

Every retired post was redirecting to our article index. One rule, one destination, everything.

That is the easy thing to build and it is weaker than it looks. A redirect to the closest equivalent passes more signal than a redirect to a general page, and a large number of unrelated URLs all landing on one destination can eventually be treated as a soft 404 — which means the redirect achieves nothing and you have spent the link equity anyway.

The proper fix is a one-to-one map from each old URL to its nearest surviving page. We could not build one: the list of old URLs is not in our repository, and the export lives in the Search Console account rather than anywhere we could read.

So we routed by keyword instead. An old path containing "mortgage" now lands on the mortgage article rather than the index; one containing "letting" lands on the lettings page; nineteen topics, twenty-two rules, derived from the request rather than from a list we did not have. When it misses, it falls through to the index, which is the behaviour it replaced — so the worst case is unchanged.

Three things to check on your own site

1. Cross-check your sitemap against your redirects. This is the whole test. On most sites it is a five-line script and the answer should be zero.
2. Check every redirect destination still exists. A redirect pointing at a page that was later deleted is a 301 to a 404, which is worse than no redirect. Ours is now a build check.
3. Look at what your old URLs go to. If everything lands on the homepage or one index, there is signal being wasted and a better mapping available.

What this does not tell you

Search Console reports several exclusion reasons and they are not equivalent. "Page with redirect" is usually fine. "Soft 404", "Crawled – currently not indexed" and "Discovered – currently not indexed" say different things and some of them are worth acting on.

It also does not tell you whether the destination is any good. A redirect delivers a reader to a page; whether that page answers the question they arrived with is a separate problem, and the traffic patterns in the note on falling search referrals suggest it matters more than it used to.

Whether a crawler can reach you at all changed in September — that is the crawler default note — and the visibility checker asks the narrower question about one page. Our own register of what we check is at what we checked.