Not Found (404) in Google Search Console: What It Means and What to Fix First

A "not found 404" error in Google Search Console doesn't always mean something broke. Sometimes it means Google tried to crawl a URL that no longer exists, and your server correctly told it so. The problem starts when you can't tell which 404s are intentional and which ones are quietly draining crawl budget and killing internal link equity.

Google re-crawls URLs it already knows about, URLs other sites link to, and URLs sitting in your sitemap. When any of those return a 404 or 410 status, GSC logs them under Page indexing as "Not found (404)." A handful won't hurt you. Hundreds, especially if they once ranked or still receive internal links, will. Below is a fix-first checklist that starts with confirming the problem and ends with measuring recovery.

What not found 404 actually means in GSC

Google's Page indexing report groups URLs by their indexing status. When you see "Not found (404)," it means Googlebot requested the URL and received a true HTTP 404 or 410 response. The page is gone, and your server said so.

Google treats 404 and 410 similarly over time, but a 410 tells crawlers the removal is permanent, which can speed up de-indexing. If you deleted a page on purpose, 410 is the cleaner signal.

Googlebot doesn't immediately trust a 404. It will retry the URL periodically, especially if internal links or sitemap entries still point to it.

A true 404 returns the correct HTTP status code. A soft 404 returns a 200 OK status but serves thin or empty content that Google interprets as a 404. The fix for each is different. With a true 404, ask yourself whether this page should exist. With a soft 404, ask why your server is saying "everything's fine" when the page is empty. If you're seeing soft 404 errors instead, we covered that in detail in our guide to soft 404s in Google Search Console.

Confirm the 404 before you fix anything

Don't start fixing URLs based on the GSC report alone. Confirm the status yourself, because GSC data can lag by days.

Paste the flagged URL into the URL Inspection tool in GSC. Check the coverage section for the HTTP response code. Then click "Test Live URL" to see what Google gets right now.

If the live test returns a 200 status, the page was restored and you're waiting for Google to re-crawl. If it still returns a 404 or 410 status, keep going.

Run curl -I https://yoursite.com/the-url in your terminal. Look for the raw HTTP status header without any client-side rendering tricks.

If you prefer a browser, open DevTools, go to the Network tab, reload the page, and check the status code of the document request.

Is the 404 URL still in your XML sitemap? Search for it. A sitemap that includes dead URLs tells Google to keep wasting crawl budget on pages that don't exist.

Next, run a site-wide crawl or use your CMS search to find internal links pointing to the dead URL. These are the "directory listings" that keep sending Googlebot back.

Fix intentional vs. accidental 404s

Not every 404 needs the same response. Your first move is sorting them into two buckets: pages you meant to remove and pages that disappeared by accident.

You retired a product, killed a landing page, or consolidated content. The page should be gone. Here's the cleanup.

1. Confirm the server returns 404 or 410, with a 410 being slightly better for intentional, permanent removals.
2. Remove the URL from your XML sitemap, then regenerate and resubmit.
3. Find and remove all internal links pointing to the dead URL, as every remaining internal link is a wasted signal and a bad user experience.
4. Don't request indexing because you want Google to stop indexing this page.

That's it. Google will eventually drop the URL from the report after it confirms the removal on subsequent crawls.

Somebody changed a slug, a migration dropped pages, or a CMS update broke a template. These need more aggressive action because you're losing traffic every day.

1. Restore the original page if the content still exists. This is always the fastest fix.
2. If you can't restore, set up a 301 redirect to the closest equivalent page. Don't redirect everything to the homepage. Google treats broad, lazy redirects as soft 404s.
3. Update internal links to point to the restored page or the redirect target. Don't rely on the 301 to fix your internal linking permanently.
4. Resubmit your sitemap in GSC after making changes. This nudges Google to re-crawl faster.

When you should not hit "request indexing"

The "Request Indexing" button in URL Inspection is tempting. But using it at the wrong time wastes your daily quota and can signal confusion to Google.

Skip it in two situations.

First, intentional removals. If you want the page gone, requesting indexing is contradictory. Second, very recently published pages. Google may not have discovered them yet, and the not found 404 entry in your report might be from a premature crawl of a URL that appeared briefly in a sitemap or internal link before the page was ready.

Use "Request Indexing" only after you've confirmed the restored or redirected URL returns a 200 status via the live URL test. Otherwise you're asking Google to re-crawl a broken page.

How to measure recovery in Google Search Console

Fixing the URLs is half the job. You need to verify that Google has actually processed your changes.

Go to Page indexing and watch the "Not found (404)" issue count. After your fixes, use "Validate Fix" on the issue group. GSC will re-crawl a sample of affected URLs and report back within a few days.

A successful validation moves the issue to "Passed." If it fails, GSC tells you which URLs still return errors, so you can diagnose the stragglers.

Search Engine Land's SEO debugging methodology recommends exporting 404 URLs from Search Console and cross-checking with robots.txt and noindex directives. That approach helps catch template-level issues you might miss when fixing URLs one at a time.

For 301 redirects, check the Performance report for the destination URL. Are impressions and clicks starting to appear? This confirms Google has transferred ranking signals.

If you redirected a page that had strong rankings, expect a temporary dip. Rankings usually stabilize within two to four weeks if the redirect target is topically relevant.

Keep 404s from piling up again

Fixing a batch of 404s feels great until the next CMS update breaks a different set of URLs. Build a few habits into your content operations.

Automate sitemap generation so deleted pages drop out immediately. Most modern CMS platforms handle this, but custom builds often don't.

Run a monthly crawl of your site. Flag any internal links returning non-200 status codes. This is the single most effective preventive measure because it catches problems before Google does.

For teams using JavaScript frameworks, Google's developer documentation outlines how to serve correct HTTP headers for empty JS routes rather than returning 200 OK for pages that don't exist. Getting this wrong is one of the most common sources of both 404 and soft 404 issues on JS-heavy sites.

If you track your content performance through tools like AEO Analytics, you'll catch indexing drops early. Pairing coverage monitoring with AI Visibility Tracking gives you a fuller picture of how Google treats your pages over time.

Frequently asked questions

How long should I keep a 301 redirect in place after fixing an accidental 404?

Keep redirects live for at least several months so users and crawlers can transition naturally, and longer if the old URL still gets backlinks or direct traffic. As a rule, avoid removing a redirect until you confirm the old URL no longer receives significant visits or crawl activity.

What is the safest way to handle trailing slashes, uppercase letters, or parameter variations that create duplicate 404s?

Standardize URL formatting at the server level. Enforce lowercase and a single trailing-slash policy, then redirect variants to the canonical format. For parameter noise, limit which parameters generate indexable URLs and ensure your internal links always use the preferred version.

How do I prioritize which 404s to fix first when there are thousands?

Start with URLs that have external backlinks or strong historical traffic. Next, tackle 404s linked from high-authority internal pages and templates, since those tend to multiply across the site.

Should I serve a custom 404 page, and what should it include to reduce user drop-off?

Yes, a helpful custom 404 can retain users even when a URL is gone. Include a clear message, site search, and a prominent path back to key pages. Make sure the page still returns an actual 404 status code.

Can CDN, caching, or security tools cause false 404 reports in Google Search Console?

They can, especially if a WAF blocks Googlebot or a CDN serves an edge error. Check server logs and CDN or WAF event logs for Googlebot requests to confirm whether the origin returned a real 404 or an intermediary did.

What is the best approach for handling 404s during a site migration or platform change?

Create a pre-migration URL mapping from old to new pages, and validate it with a crawl in a staging environment before launch. After launch, monitor log files and analytics for unexpected 404 patterns, then patch redirect gaps quickly to prevent prolonged loss of discovery.

How can I prevent content teams from accidentally creating broken internal links that lead to 404s?

Add CMS guardrails such as link validation on publish and alerts when a linked page is deleted or unpublished. Editorial checklists and a simple monthly link integrity report help catch issues before they scale.

Start monitoring coverage automatically

Manually checking GSC every week works until your site grows past a few hundred pages. ClickFlow connects to your Search Console data and surfaces coverage issues alongside content performance, so you can catch 404 spikes and act on them before they compound. Worth a look if you're tired of spreadsheet-based audits.