Most of them do not matter. Google’s own advice is to fix only the 404s you link to yourself or list in your sitemap. The rest of that list is usually old addresses nobody points at any more, and leaving those broken is the right call.
The one line that sorts the whole list
Google’s Search Console Help page for the Page indexing report says it plainly. “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.” That page carries no update date.
So take each address in your 404 list and ask two questions.
- Does a link on your new site point at this address?
- Is this address in the sitemap you handed Google?
If either answer is yes, fix it. Change the link to point at the page that exists now, or send the old address to its replacement with a permanent redirect.
If both answers are no, ask one more thing. Did that address hold a real page that now lives somewhere else? If it did, redirect it. If it held nothing worth keeping, leave it alone. The same help page says it is fine for a URL not to be indexed for the right reasons, and it names a 404 for a page you removed with no replacement as one of those reasons.
A redirect only does its job while it is still switched on. How long you have to keep the old ones running is a separate question with a real number attached.
What a broken address does to the rest of your site
Google Search Central has a page called How HTTP status codes affect Google’s crawlers, last updated February 4, 2026. It says Google does not index addresses that return a 4xx code, and that addresses already in the index get removed once they start returning one.
Read that carefully. It describes what happens to the broken address itself. It does not say the pages that still work get pulled down with it.
The same page says something that saves you money. “All 4xx errors, except 429, are treated the same.” Its own list calls 410 gone, and plenty of people will tell you to switch your 404s to 410s to clear them out faster. That page does not support the swap. It also says the 4xx codes, apart from 429, have no effect on how fast Google crawls your site.
Soft 404s are the ones worth opening
There is a second row in that report, and it is the one to look at first. A soft 404, in Google’s words, is a page that “returns a user-friendly ‘not found’ message but not a 404 HTTP response code.”
This shows up a lot right after a rebuild. Your new site has a nice not found screen with your phone number on it, and the server quietly hands back a 200 success code instead of a 404. Google sees a page whose code says fine and whose words say not found.
Google’s fix has two halves. Return a 404 response code for pages that truly are not found, and put enough on the page for Google to tell that it is not a soft 404.
The report entry says what to do next. Run a live URL inspection test against the page, then click View tested page for a screenshot of how Google renders it. A live test fetches the address in real time, so you see the page as it stands today rather than the version Google last indexed.
Some of the 404s are supposed to be there
Google Search Central’s guide How to move a site, last updated August 20, 2026, tells you to make deleted content return an error on purpose. If you did not carry every old page across, those addresses “correctly return an HTTP 404 or 410 error response code on the new site.”
That is a design choice, not a fault. Ten thin pages you were glad to drop should show up as 404s. If they do not, something is still serving them.
The same guide covers the warnings on your old sitemap. Search Console may flag the old addresses for redirecting, and Google says this is normal and you can ignore those warnings. You are moving to new addresses, which is exactly what the warning is describing.
If your domain name changed as well as your addresses, there is a separate Search Console tool for that, and it is narrower than most people assume.
What the report will not tell you
The example list is capped. Google’s help page states that “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.”
That is a number you can go and check yourself. Open the report, click into Not found (404), and count the rows. If your 404 count is 4,000, you are looking at a sample of it, and there is no way inside the report to see the rest.
There is a second limit worth knowing. The help page says there is no way to tell Googlebot to permanently forget an address, though it will crawl it less and less often. Your 404 list is never going to reach zero, so do not treat the count as a score you are trying to beat.
For the full picture, Google’s site move guide points you at your own server logs. Your host’s error log shows every address anyone requested, including the ones Google has not got around to yet, and those same logs show whether ChatGPT has read your site.
What to do next
Work in this order. It takes an hour, not a project.
- Open the Page indexing report and sort the not indexed reasons. Handle Soft 404 before Not found (404).
- Run a live URL inspection on two or three soft 404 examples. Fix the code the server returns.
- Export the Not found (404) list. Match it against your sitemap and your own site’s links.
- Redirect the matches to real pages. Leave the rest.
- Check back in two weeks. Google says validation typically takes up to about two weeks and sometimes much longer, so rows leave the report on its schedule, not yours.
Here is the honest part. If nothing on your 404 list is in your sitemap, and nothing on your new site links to it, there is nothing here to buy. Reading the report and closing it is a complete answer some weeks.
Where money is worth spending is the watching itself, over the first month or two after a launch, alongside the rest of the search checks. One bad afternoon in a report is noise. The same address failing for three weeks running is not.