900 URLs Return 404. Which Ones Should You Fix, Redirect, or Leave Alone?

When 900 URLs return 404 in a crawl report or in Google Search Console, the first reaction is usually to treat the list as an emergency. It rarely is. Most of those URLs need no action, a smaller group needs a redirect, and a few point to a real problem such as a broken internal link or a deleted page that still has backlinks.

You probably have an export open right now and are wondering where to start. This guide shows how to sort that list by cause, so you spend your time only on the URLs that matter.

Do You Need to Fix Every 404 Error?

No. A 404 is the correct response when a page does not exist, and most 404 errors need no action. Google’s help page on 404 errors says that many of them are not worth fixing because they do not harm a site’s indexing or ranking. John Mueller made a similar point when he said 404s would not affect the rest of a site’s rankings, as reported by Search Engine Journal.

That does not mean the list can be ignored. The count is not the signal. The cause is. A URL that returns 404 because an outdated page was deleted is normal. A URL that returns 404 because your own navigation links to it is a defect. A URL that returns 404 while holding valuable backlinks is lost opportunity. One status code covers all three, which is why a flat list of 900 rows feels more alarming than it is.

In my experience, the number of distinct causes behind a large list is small. Hundreds of URLs often trace back to one template, one migration rule, or one deleted section. Once you sort by cause, a 900-row problem becomes a handful of decisions.

The Three Decisions for a 404 URL: Fix, Redirect, or Leave Alone

Every 404 URL ends up with one of three outcomes: you fix the link that points to it, you redirect it with a 301 to a close replacement, or you leave it as a 404. Four questions decide which one applies. Is there a genuine replacement page? Does any page on your site still link to it? Does it have backlinks or past search traffic? Was it ever a page you wanted to exist?

The first row is the only one where something important is actually broken. Open two or three of those URLs in a browser before assuming anything was deleted on purpose. A mass 404 on pages you expected to be live points to a configuration fault, and that fault should be fixed before any redirect work begins.

How to Group 900 URLs That Return 404 Before You Touch Anything

Group the list by pattern and by source, not one URL at a time. A list of 900 URLs that return 404 usually collapses into somewhere between five and fifteen patterns, and each pattern gets a single rule instead of hundreds of manual edits.

Start by combining two views of the problem. Google Search Console lists URLs Google has discovered, including ones found through external links and old sitemaps. A crawl of your own site lists URLs your internal links point to. Neither view is complete alone, and the overlap tells you a lot.

Put everything in one spreadsheet and add these columns:

• URL pattern: the folder or prefix, such as /tag/, /product/, /wp-content/uploads/, or URLs with query strings
• Internal links: how many pages on your site still link to it, from a crawl
• Backlinks: whether other sites link to it, from any backlink report you have access to
• Past performance: clicks or sessions over the last 12 months, from Search Console or analytics
• Replacement: the closest live page, if one exists
• Decision: fix, redirect, or leave

Sort by URL pattern first. You will usually see obvious clusters: a removed tag archive, a product category that was renamed, a folder of old PDFs, a run of garbage URLs with extra text appended. Decide each cluster once, then apply the decision to every row inside it.

Which 404 URLs to Fix at the Source

Any 404 URL that one of your own pages links to should be fixed by editing the link, not by adding a redirect. A redirect hides the symptom while the broken link stays on the page, sending visitors and crawlers through an extra hop for no reason. Search Engine Journal makes the same distinction: redirecting a misspelled internal URL does not fix the underlying problem, which is the link itself.

To find these, you need to know which page contains each broken link and what the anchor text says. A broken link checker that reports the target URL, the source page, and the anchor text for every dead link makes this a short job instead of a long hunt. Without the source page, you only know a URL is dead. With it, you know where to click.

Start with links that live in templates: main navigation, footers, sidebars, related post widgets, and breadcrumb trails. One bad link in a template can appear on thousands of pages, so a single edit can remove a large share of your list. Next, handle links inside body content, and then remove dead URLs from your XML sitemap, since a sitemap should only list pages that return 200.

Dead outbound links belong in this group as well. If a page you linked to has disappeared from another site, link to a working replacement or remove the link. Pointing readers to pages that no longer exist makes your content look neglected.

Which 404 URLs to Redirect With a 301

Redirect a 404 URL when the page moved or has a genuine replacement, and the old URL still carries value in the form of backlinks, search traffic, or regular visits from bookmarks. A 301 sends users to the new page and tells Google the move is permanent. Google’s documentation says it treats a 301 as a strong signal that the target should be the canonical URL, while a 302 is only a weak one.

The word that matters is genuine. Mueller’s example was a discontinued cup replaced by a new cup that does the same job, which is a fair redirect. A similar page is not enough. If someone wants a knife and lands on a page about spoons, the redirect has helped nobody. When the closest page is only loosely related, leave the URL as a 404.

A few rules keep redirects clean:

• Map one to one. Send each old URL to the most specific equivalent page, not to a category or the homepage.
• Use pattern rules for migrations. If /blog/2021/post-name/ became /blog/post-name/, one rewrite rule covers the whole group.
• Point straight to the final URL. Googlebot follows up to 10 hops, but every extra hop adds delay and another place for a mistake. If A redirects to B and B redirects to C, send A directly to C.
• Prioritize by value. Redirect URLs with backlinks and traffic history first. A URL with neither can wait or be skipped.

The backlink check deserves the most attention. If another website links to a URL that returns 404, that link currently leads nowhere. A 301 to the right page recovers the visitors and the link equity that would otherwise be wasted.

Which 404 URLs to Leave Alone, and Whether to Use 404 or 410

Leave a URL as a 404 when the page was removed on purpose, no equivalent exists, nothing links to it, and it earned no traffic. This covers most of the long tail in any large list: old tag pages, expired campaign pages, thin posts that were pruned, and URLs that never existed in the first place.

Google’s help page notes that a 404 usually drops out of the report after a period of time. Crawlers may check a removed URL a few more times and then slow down. That behavior is normal, and it does not require anything from you.

The choice between 404 and 410 comes up often. A 410 states that the page is gone for good, while a 404 only says it was not found. Google’s documentation says it treats a 410 the same way as a 404 for search purposes. Use 410 if it is easy to set up and you want to be explicit, but do not expect a ranking or indexing benefit from the switch.

What does deserve effort is the 404 page itself. It should return a real 404 status code, tell visitors plainly that the page is missing, and offer a search box and links to your main sections. Google’s guidance on custom 404 pages stresses that they are made for users, and that a page which says “not found” while returning a 200 status creates a different problem, covered next.

Why Redirecting 404 Pages to the Homepage Creates Soft 404 Errors

Redirecting every 404 URL to the homepage is a shortcut that usually backfires. Google treats a redirect to an unrelated page as a soft 404, which means the redirect does not pass the value you hoped it would and the URL still looks like an error to the search engine.

A soft 404 is a URL that shows an error or an empty page while returning a 200 status code. Google’s status code documentation explains that when its systems detect an error page from the content, Search Console reports it as a soft 404. Its recommendation is simple: if the page is gone and has no replacement, return a 404 or 410. If the page moved or has a clear replacement, use a 301.

There is a user problem too. Someone who clicked a link for a specific guide and arrives on a homepage has to work out what happened. A clear 404 page that offers navigation serves them better than a silent redirect.

The same applies to custom “not found” templates and empty search result pages that return 200. Check the status code, not only what the page looks like. If you suspect a pattern like this, inspect a few URLs and confirm the header says 404.

A Worked Example: Sorting 900 URLs That Return 404

The numbers below are illustrative, but they reflect the kind of split I see in real exports. Imagine a site that changed its URL structure and pruned old content, and now shows 900 URLs that return 404.

Add the groups up and the total is 900. Yet the actual work is six decisions, one template edit, and about 15 individual redirects on top of the pattern rule. Roughly 480 of the URLs, over half, needed nothing at all.

That is the point of grouping first. The pile looked like 900 tasks. In practice it was a short list of changes plus a large set of URLs that were correctly returning 404.

How to Confirm Your Fixes and Stop 404 Errors From Piling Up Again

After making changes, crawl the site again and check the status codes directly. Fixed links should no longer appear in the report. Redirected URLs should return a 301 and land on a 200 page in one hop. Left-alone URLs should still return a clean 404, not a 200 and not a redirect to the homepage.

Then watch Search Console over the following weeks. The count of not found URLs should trend down, and any soft 404 entries should shrink as you correct status codes. New 404s will keep appearing as the site changes, so the aim is not zero. The aim is that every remaining one is a deliberate choice.

A few habits prevent the next pile from building up:

• Keep a redirect map during migrations. List old and new URLs before launch, not after the 404s appear.
• Check for dead links after content changes. Deleting a page without checking what links to it is the most common way internal 404s begin.
• Run a recurring crawl. A free broken link checker used monthly, and after any redesign or CMS change, catches new dead links while the list is still short.
• Keep sitemaps clean. Only live, indexable URLs belong in them.

The next time 900 URLs return 404, the number should not decide anything. Ask what links to each URL, whether a real replacement exists, and whether the URL ever had value. Fix what is broken, redirect what moved, and let the rest stay missing.