"Not found (404)" keeps growing. Did something break — or is this your cleanup?

You opened Search Console’s Page indexing report, and in the table headed Why pages aren’t indexed one row reads Not found (404). Beside it, a number. The number is what brought you here — because it is bigger than it was last time you looked, and the chart of it climbs. A warning that sits still can be filed away. A warning that grows feels like a hole getting wider.

So here is the sentence this article exists to earn: a climbing 404 count is often what a cleanup looks like from Google’s side. Delete a stretch of old pages — retired posts, categories you stopped using, an add-on you uninstalled — and the report will not show it the next morning. The rows tend to arrive one at a time, over weeks, as Google gets around to re-reading each address you emptied and finds it empty. The number going up is not your site coming apart. Often it is the record of your own work, delivered at Google’s pace instead of yours. And if you deleted nothing you can remember — addresses in the list you have never seen, with question marks or strange endings — that is the other common shape, and the same one test sorts it.

Your list almost certainly holds two kinds of address, and separating them is the whole job. Most of them are addresses you emptied on purpose — those are correct, and you can stop at them. A few might be addresses that answer “not found” while something of yours still points at them. One test tells them apart, it comes from Google’s own documentation, and you can run it yourself in minutes. The test is two checks and it lives below in Run the test on your own site — if four minutes is what you have, go there now. What follows first is the one paragraph that explains why the report cannot do this sorting for you.

A 404 is about an address, not a page

404 is the answer an address gives when there is nothing at it. Not hidden, not locked, not forwarded somewhere else — the three-digit code your site sends back says the address was asked for and nothing lives there. (The locked-door answer is 403, and the 403 row has its own article.)

Notice what a 404 is about: an address, not a page. A page you deleted last month is not “showing an error” — the page is gone, which is what you decided, and the address it used to live at now gives the only truthful answer it has left. That answer is not a malfunction. It is the deletion, working.

Google can’t tell your cleanup from a breakage

The report, though, lists that truthful answer in a table of problems, and this is the moment to see why. An owner brought the exact situation to Google’s help forum in 2022: “I deleted some pages from site. But now those pages are showing ‘Not found (404)’ error in Search Console.” A Product Expert — one of the volunteer regulars Google badges in that forum, not Google staff — answered in one breath, capitals theirs:

A Product Expert in Google’s help forum, as reported

Nothing to fix, deleted pages SHOULD provide a 404 But Google doesn’t know if it is intentional or accidental so just lets you know when it finds them.

That middle clause is the entire report, explained. From the outside, a page you removed on purpose and a page your site broke by accident give the identical answer — not found — and Google has no way to know which one it met. So it writes them all down and shows you the list. The row is not an accusation. It is a question the report has no way to ask out loud: did you mean this?

The owner in that thread didn’t believe it — “Why nothing to fix. That a big problem for my site SEO.” — and if some part of you is asking the same thing, Google’s own page on 404 errors answers it in writing:

Google’s help page on 404 errors

In general, 404 errors won’t impact your site’s search performance, and you can safely ignore them if you’re certain that the URLs should not exist on your site.

In plain words: the addresses in this list are not weighing on the pages you kept. A page that no longer exists is not competing with anything, and it is not taking anything from the pages that do. What Google is asking is narrower than “is your site in trouble” — it is only asking whether you meant it.

“If you’re certain” is the working part of that sentence. Certainty is exactly what the next test buys you.

The one test, and it is Google’s own

Google does not say fix nothing. Its help page for the Page indexing report names which 404s deserve a person’s time, in one sentence:

Google’s help page, on the only 404s worth fixing

In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap. If a page has been moved, you should return a 3XX redirect to the new page.

Read the condition slowly, because it is the sorting machine. The question is never does this address answer “not found” — of course it does; that is why it is in the list. The question is: does anything of yours still point there? A link in your own menu, a mention on your own pages, a line in your sitemap — the file that tells Google which addresses you want visited. If yes, you are promising visitors a page that is gone, and that promise is the fault. If no, the 404 is the correct answer to a question nobody you care about is asking.

Here is what usually lands in this row, sorted by that test:

• Leave them Pages and posts you deleted — the 404 is your decision, reported back to you.
• Leave them Category, tag and author archives — listing pages your platform built by itself, one per category, one per author. Delete the category and the archive goes with it. You removed the thing; the listing had nothing left to list.
• Leave them Pagination that no longer exists — the /page/2/, /page/3/ addresses of a list that got shorter, or that you switched off.
• Leave them Leftovers from an uninstalled plugin — a plugin is an add-on that bolts extra features onto your site, and it makes addresses and files of its own. Uninstall it, and they stop existing, which is the point of uninstalling.
• Leave them Addresses you never made — spellings with ? and a string of numbers, paths from a theme or an old site, addresses another site typed wrong. Nobody built them, and they fail the test the same way a deleted page does.
• Fix this An address you still link to, or still list in a sitemap — a page in your own menu answering “not found”, or a sitemap advertising a page that is gone. This is the one Google’s sentence names, and the one worth your evening.

Run the test on your own site

You don’t need tools for this, only a browser and a few minutes.

Open the addresses. Click the row in the report; its Examples table lists the affected addresses. Open a few. Read them as addresses, not as errors: is this a page you deleted, an archive of a category you removed, page 3 of something? After a cleanup, the list usually reads like a receipt of what you threw away. An address you have never seen before is not a worse sign — it is usually the never-made kind from the list above, and the two checks below judge it the same way.

Look for your own links. Click through your site the way a visitor would — the menu, the footer, the sidebar. Links from other people’s sites don’t count here — Google’s condition is about links of yours, and you cannot fix somebody else’s page anyway. If any listed address is reachable from your own pages, you have found the real case: a signpost pointing at a demolished building. The fix is whichever you meant — remove the link, or bring the page back. And when the fix is made, take your proof from Search Console’s own tool: URL Inspection at the top of the screen, then TEST LIVE URL, which fetches the address right now rather than repeating what Google saw last time. A page you brought back should now answer normally; a link you removed you can confirm by clicking through the menu again. That proof is today’s, and it is yours — the waiting described in the last section is the other reader’s problem, not yours.

Open your sitemap. A sitemap is you handing Google a reading list, so a deleted page still on it is you asking Google to keep visiting a page you removed. Type your domain and then /sitemap.xml — for mine, that is kovalweb.com/sitemap.xml. If nothing opens, try /sitemap_index.xml, the other common spelling. What appears may look like a tidy table or like a page of tags and angle brackets; both are normal, and both are just a list of addresses. If it is split into several smaller lists, open them one at a time. On each, press Ctrl+F (Cmd+F on a Mac) and paste in the part of the missing address after your domain name — /uk/author/hladunn/ rather than the whole thing. Nothing highlighted means it is not listed, which is the answer you want. And if neither address opens anything at all, you may simply not publish a sitemap — that is not a fault, and it means there is nothing here to check. A dead page that does turn up in a sitemap is worth fixing — though usually your platform or SEO plugin rebuilds the sitemap by itself once the page is properly gone.

If neither search finds anything — no link of yours, no sitemap entry — then Google’s own condition for “worth fixing” is not met, and there is nothing here for you to do. (If the page moved rather than died, that is the one case where a redirect belongs — the section Don’t send them to your home page covers it.)

My own report: twenty-four pages, and climbing

My own list is the first kind from top to bottom — every address in it is one I emptied — so let me show the whole thing. I cleaned up kovalweb.com: switched pagination off entirely, deleted old category archives — including their Ukrainian and Russian language versions — removed some author pages, and uninstalled a plugin (Super PWA) the site no longer needed. These rows were predictable — they were part of the plan, not a departure from it.

Search Console’s version of my cleanup: Not found (404), 24 affected pages as of 20 August 2026 — and a chart that does not climb so much as step. It sits at one through late May, at a handful all through June and early July, then jumps to twelve in the last week of July, and steps again through August: fifteen, twenty-one, twenty-four on the day I wrote this. By the day it was published, four days later, twenty-seven — and the list was still nothing but addresses I had removed on purpose. Those steps are worth reading. Google was not finding new damage each week; it was working through a list of addresses it already knew, in batches, at its own pace. In all that time nothing on the site broke, because nothing on the site changed. What grew was the number of deleted addresses Google had got round to re-reading. The addresses Search Console lists for me have exactly the shapes from the list above:

• https://kovalweb.com/ru/category/dizajn/ — a deleted category archive, in one of the language versions,
• https://kovalweb.com/uk/category/site-development/page/2/ — pagination of another,
• https://kovalweb.com/uk/author/hladunn/ — a removed author page, the same kind of machine-made listing that also fills my Page with redirect row, one author to a page,
• https://kovalweb.com/superpwa-sw.js?1781877248 — a file the uninstalled plugin used to produce.

“I meant to delete those” is a claim, so on 20 August I ran the test on sixteen of the listed addresses — the sixteen the next section is about. Every one answers a real 404 — an actual “nothing here”, not a page that answers “here it is” while showing a not-found message (that disguised kind has a name — soft 404 — and it turns up later, under Don’t send them to your home page). And both halves of the test come back empty: nothing on my home pages links to any of these addresses, and none of them appears in any of my four sitemap lists. By Google’s own sentence, there is nothing here to fix.

One column repays a glance while you are in the table: Last crawled, the day Google last read the address. On some rows in this report those dates are a year old, and the row is only Google’s memory. Not here — mine run from 1 August to 18 August, every one inside three weeks. Recent dates against long-deleted pages look alarming, but the same help page says this is the design:

Google’s help page, on why it keeps re-reading removed addresses

Google continues to crawl all known URLs even after they return 4XX errors for a while, in case it’s a temporary error.

Google is not stuck; it is double-checking. Each recent date is Google asking an address again and hearing “nothing here” again — which is exactly the answer I want it to hear.

Why “Validate fix” came back Failed

Above my examples sits a strip, and it reads Validation failed, with Started: 7/31/26 and Failed: 8/5/26. I pressed VALIDATE FIX at the end of July, the way the interface invites you to, and the details view now counts PENDING 8 · FAILED 16. Sixteen failures — every one a page I deleted on purpose.

That result was on schedule. Validation asks Google to confirm the 404s are gone; mine are not gone, they are correct — so Google re-read the addresses, heard “not found” again, and stamped the batch Failed. Why one page fails a whole batch has its own article; what that article can’t tell you is this case, where every instance remains by design because every deletion was deliberate.

So, for your own row: if the 404s in your list are correct, don’t press VALIDATE FIX — it asks Google to confirm a fix that was never needed. And if you already pressed it, nothing is damaged. Failed validation is not a penalty and there is nothing to undo; the red strip is Google reporting that the deletions are still deleted, and you can leave it sitting there.

A Product Expert said as much in a thread from 2024, to an owner whose report was filling with 404s she had not created: “Validation is only for when the 404 status was wrong.” When the 404 is right for the address, the same reply goes on, validation is the wrong tool and will fail if you use it. Her follow-up will sound familiar: “I’ve already tried the Validation process in Google Search Console, but the issue not only persists, it seems to increase over time.” And John Mueller of Google put the same rule in one line, quoted in Search Engine Journal:

John Mueller, as quoted by Search Engine Journal

It’s more if you accidentally 404’d something and fixed it. You obviously don’t have to fix 404s that you want to be 404s.

So a red Failed on this row, after a cleanup, is not a verdict on your site. It is the report confirming — in the least reassuring wording available — that your deletions are still deleted.

Don’t send them to your home page

Search for this warning and you will meet one piece of advice again and again. Here it is as a replier gave it in a plugin’s support forum on wordpress.org, to an owner staring at hundreds of these rows after uninstalling a plugin:

A replier in a plugin’s support forum on wordpress.org, as reported

Every time you delete/remove a page/post URL from your site, the best move is creating a 301 redirect from the old URL to any other one that can represent that content, and if no other content is similar you can just redirect to your site home page.

Only part of that is safe. A 301 — a permanent forward from one address to another — to the page that genuinely replaced the old one is right. But “any other one that can represent that content” is already the slippery half — a page that is merely on a similar topic is not a replacement, and Google files a redirect to a near-enough page under the same name as a redirect to the home page. Google’s page on 404 errors gives that name:

Google’s help page, on redirecting deleted pages to the home page

Returning a code other than 404 or 410 for a non-existent page (or redirecting users to another page, such as the homepage, instead of returning a 404) can be problematic. Such pages are called soft 404s, and can be confusing to both users and search engines.

(410 is the neighbouring code for “gone, deliberately” — you do not need to go and set it; Google treats it much the same, and a plain 404 is already the right answer.)

Keep the two cases apart, because both hide inside the word “redirect”. The page moved, and a real replacement exists: redirect the old address to the new one. Google recommends exactly this in the reason’s own definition — “If your page has moved, use a 301 redirect to the new location” — and the visitor holding the old link gets the page’s successor. The page is gone, and nothing replaces it: let it answer 404. A redirect to a real replacement is a promise kept. A redirect to the home page — or to a page that is merely nearby — is a promise broken politely: the visitor asked for a page and got a lobby, and Google files it under the soft 404 name above, which trades a row that means “deletion, working” for one that means “answer I don’t believe”. A Product Expert drew the same line for an owner with more than four hundred of these rows: “…the fix is to redirect the old urls to the new if there is a valid counterpart. If the url isn’t valid, it should remain a 404”.

When the number stops climbing

Start with what is certain, because here the certain part is the comforting part. There is no lever for this row — no button empties the list early, and, the part I wish the interface said out loud, no button ever needed pressing. Google’s help page for the report says so:

Google’s help page, on skipping the button entirely

You can also fix issues without validating; Google updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation.

The count corrects itself as Google’s visits come and go — and the visits themselves thin out. From the same page:

Google’s help page, on how long the visits continue

Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often.

And the list is built to stop growing on its own — the same page again:

Google’s help page, on what the report shows

To avoid showing you an eternally growing list of 404 errors, the Page indexing report shows only URLs that have shown 404 errors in the past month.

How long until yours empties? Google’s 404 page offers something close to a timescale:

Google’s help page, on a deleted page with no replacement

If it is a deleted page that has no replacement or equivalent, returning a 404 is the right thing to do. The report should stop showing the 404 after about a month.

About a month, in Google’s telling. Owners measure longer. One asked in January 2024: “Some people say Google will eventually remove this pages after a month or so, but it has been more than 6 months now and google still crawls this pages.” The honest position holds both: “should stop showing after about a month” is Google’s own sentence, and the longer waits are real reports, so I will not promise you a date — my own row is still climbing as I write this. But the date was never your part of the job. Your part of this story was over the day the cleanup was done; the report’s part runs on Google’s calendar, and waiting is not a task.

This row teaches something the others don’t: the real thing behind the warning can be work you already did. I emptied out categories, pagination, author pages and a plugin; Google noticed, at its own pace, and wrote each address down; the climbing number is my cleanup as it shows up in the paperwork. Run Google’s one test — nothing of yours links to them, nothing of yours lists them — and then read the growing count for what it is. Not damage spreading. A decision, landing.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.