Not Found (404)

TL;DR — “Not found (404)” in Search Console means Google asked your server for a page and got a “not found” answer, so it didn’t index it. Google found the URL on its own — usually from a link somewhere, or because the page used to exist — which describes how it was discovered, not proof it’s missing from your current sitemap. This is normal and usually fine, but only for URLs that are actually supposed to be gone. You only need to fix it if the URL should work, in which case you bring the page back or redirect it to the right replacement.

What “Not found (404)” means

This label means Google received an HTTP 404 when requesting the URL. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google treats persistent 4xx responses other than 429 as if the content does not exist. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Open the Page Indexing report in Google Search Console and you’ll see a list of reasons pages aren’t indexed. “Not found (404)” is one of them. It means Googlebot requested the URL, and your server replied with an HTTP 404 (Not Found) — the standard “this page doesn’t exist” response. Because the page returned a 404, Google didn’t index it.

The part that surprises people: Google says it found this URL without an explicit request from you. That describes how Google discovered it — usually one of two places below — not a guarantee it’s missing from your current sitemap. If the same URL is still sitting in a sitemap you submit, that’s a separate, fixable problem (a stale sitemap entry), not a contradiction of what the report is telling you:

• A link. Something on the web links to that URL — one of your own pages, or a page on another site — and Google followed the link.
• A page that used to exist. The URL was live and indexed before, then you deleted it or changed the URL. Google still remembers it and re-checks it.

Do 404s hurt my SEO?

This is the question everyone really wants answered, so here it is up front: no, not automatically. 404s are a normal part of how the web works. Pages get removed, URLs change, and other sites occasionally link to addresses that never existed. A page returning 404 when it’s genuinely gone is the correct behavior — Google’s own documentation says 4xx responses other than 429 don’t affect your site’s crawl rate, and a correct 404 isn’t a penalty on the rest of your site.

That “correct” label only applies to URLs that are actually supposed to be gone, though. A 404 on a page you still link to, that’s sitting in your sitemap, or that other sites still link to isn’t harmless just because it’s technically valid — it’s a broken link, lost link equity, or a visitor hitting a dead end. So for genuinely dead pages with nothing pointing at them, “Not found (404)” in your report is nothing to panic about. For the rest, it’s worth a look — see the next section.

When a 404 is actually worth fixing

The 404s worth your attention are the ones for URLs that should work:

• A page you still link to from your own navigation or content (a broken internal link).
• A URL that’s in your sitemap (it shouldn’t be — sitemaps are for live, indexable pages).
• A page that other sites link to (you’d be wasting those links).
• A URL that still gets traffic or that people clearly meant to reach.

For those, you have two good options:

1. Bring the page back if it was deleted by mistake.
2. Redirect it to the most relevant live page (a 301 redirect). This sends visitors somewhere useful and, importantly, passes along the value of any links pointing at the old URL.

One thing not to do: don’t redirect every dead URL to your homepage. Google treats an irrelevant redirect like that as a “soft 404” — which is its own problem. Redirect to a genuinely related page, or just let it 404.

Want the full version — 404 vs 410 vs 301 vs noindex, how to find what’s linking to a 404, and how long these linger in the report? Switch to the Advanced tab.

TL;DR — “Not found (404)” means Googlebot requested a URL Google describes as discovered on its own — a link, or a previously-indexed page — not through an explicit request from you, and got a 404, so it’s not indexed. That description explains the original discovery, not proof the URL is absent from your current sitemap. 404s are a normal part of the web, and Google’s own documentation says 4xx responses other than 429 don’t affect crawl rate; a 404 for a removed page with no replacement is correct and isn’t a sitewide penalty — but a 404 on a URL that should exist (linked internally, in a sitemap, with backlinks, or with traffic) still costs you broken links, lost equity, or lost users. For those: restore the page, or 301 it to a genuinely relevant live page — prioritizing the ones with inbound links to recover equity. Leave the rest as 404. In my own experience 410 tends to drop a touch faster, though Google treats 4xx codes other than 429 the same. Don’t mass-redirect to the homepage (soft-404 risk). Googlebot keeps re-checking old 404s with decreasing frequency, which is why they linger in the report — that’s normal, not a penalty.

What Google is actually telling you

The report states the observed 404; it does not by itself explain which link, historic URL, or application route produced it. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google’s general 4xx documentation describes the indexing behavior. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Google’s definition of this status is short: “This page returned a 404 error when requested.” The surrounding context is the part that matters — Google discovered the URL without any explicit request or sitemap from you. That’s what separates “Not found (404)” from the indexing errors you submitted yourself.

That sentence describes how Google originally found the URL — it’s not a claim that the URL has never appeared in, or isn’t currently sitting in, one of your sitemaps. If you check a live sitemap and the same URL is still listed there, that’s a real (and separate) problem worth fixing — a stale sitemap entry — not a contradiction of what the report is telling you about discovery.

So the URL came from one of these:

• An internal or external link. Google extracts links as it crawls. A typo’d internal link, an old link on someone else’s site, or a link in a comment can all point Googlebot at a URL that 404s.
• A previously-indexed page you deleted or whose URL you changed. Google remembers URLs it has seen and re-requests them for a long time.
• Scraped, malformed, or fabricated URLs. Other sites sometimes mangle your URLs, append junk, or invent paths. Google may try them. None of that is your fault, and none of it requires action.

That last point is worth internalizing: finding a 404 in this report does not mean you did something wrong. Google discovers URLs from all over the web.

Does “Not found (404)” hurt SEO? (the verdict first)

No — not automatically, and this is the single biggest misconception about the report. 404s are how the web is supposed to work when content is gone, and Google’s own crawl documentation says 4xx status codes other than 429 have no effect on a site’s crawl rate. A correctly-returned 404 on a genuinely gone page is not a sitewide penalty.

That’s a narrower claim than “404s never matter,” though. A 404 doesn’t drag down the rest of your site by itself, but a 404 on a URL that should work — one with internal links, external backlinks, or real traffic — still costs you something concrete: a broken link, lost link equity, or a visitor hitting a dead end. The report itself isn’t the problem; leaving the 404s that shouldn’t exist unfixed is.

This matches my own read of HTTP status codes generally: 4xx responses cause the specific page to drop out of the index, but that’s the page going away cleanly — not a penalty applied to your domain. The page that 404s simply isn’t in the index anymore; everything else is unaffected.

Google’s own help docs make the same point about indexing in general: it’s fine for a URL not to be indexed for the right reasons, and “a 404 for a page that you’ve removed and have no replacement for” is explicitly one of those right reasons. A 404 on a genuinely-dead page is the correct end state, not a to-do.

What Google does with a 404 internally

From Google’s HTTP-status documentation, the mechanics are clean: for a previously-indexed URL, the indexing pipeline removes it from the index. Newly encountered 404s simply aren’t processed — there’s nothing to index. And Googlebot doesn’t forget the URL immediately: it keeps re-requesting it, with the crawling frequency gradually decreasing over time.

That re-checking behavior is why old 404s keep appearing in your report long after you’ve dealt with them. Google is periodically confirming the page is still gone, in case it comes back. It’s not a sign of a problem, and it’s not wasting a meaningful amount of crawl budget on a normal-sized site.

When a 404 is worth fixing — and when it isn’t

The decision rule is simple: fix the 404 only if the URL should exist. The signals that a URL “should exist”:

• You link to it internally (a broken link in your nav, content, or footer).
• It’s in your sitemap (it shouldn’t be — sitemaps should list only live, indexable URLs).
• It has external backlinks pointing at it.
• It still gets traffic, or clearly matches something people are looking for.

If none of those are true — the page is genuinely gone and nothing of value points at it — leave it as a 404. That’s the correct response and there’s nothing to do.

How to fix the ones that matter

For URLs that should resolve, you have a short menu:

• Restore the page if it was removed by mistake or you have equivalent content to put back.
• 301 redirect it to the most relevant live page. This is the usual move for a removed page that has a sensible replacement. As I’ve put it before about pages showing up as 4xx: more than likely you just need to 301 redirect each of these to a relevant page. The redirect sends users somewhere useful and passes the ranking value of any links along to the new URL.
• Leave it as a 404 (or use 410) when the page is genuinely gone and has no good replacement. This is not a failure — it’s the right answer.

Prioritize by inbound links. The highest-value 404s are the ones with external backlinks, because a dead URL with links is leaking equity that you could recover with a single redirect to a relevant page. Pull the 404 URLs that have backlinks (a backlink tool or your link report will show these), and 301 those first. A 404 with no links and no traffic can simply stay a 404 — redirecting it accomplishes nothing.

Don’t redirect everything to the homepage. A redirect to an unrelated page — classically, dumping every dead URL onto / — gets treated as a soft 404 by Google, because the destination isn’t a real replacement for what was requested. Redirect to a relevant page or don’t redirect at all.

404 vs 410 vs 301 vs noindex

These get muddled constantly. The full decision table is in the Cheat Sheets tab; the short version:

• 404 (Not Found) / 410 (Gone) — the page doesn’t exist. Both drop the URL from the index, and Google’s own documentation says it treats 4xx status codes (other than 429) the same. In my own practitioner experience, 410 tends to drop a touch faster, but the difference is minimal either way. Use 410 if you want to signal “this is never coming back”; 404 is otherwise completely fine.
• 301 (Moved Permanently) — the content moved; consolidate signals onto the new URL. This is the tool for a removed page that has a relevant replacement.
• noindex — the page exists and should stay live, but you don’t want it in search. Different tool for a different goal — don’t reach for it on a page that’s genuinely gone.

On 404 vs 410 specifically, my own framing has been that 404s and 410s get a similar treatment — both drop pages from the index, and in my own experience 410s go a little faster, even though Google’s documentation treats 4xx codes (other than 429) identically. So don’t agonize over the choice; pick 410 for “gone forever,” 404 for everything else, and move on.

How to find what’s linking to a 404

To fix a 404 (or decide whether to bother), find what points at it:

• In GSC: open the “Not found (404)” status, click an example URL, and check Referring page under Discovery. Treat it as one possible clue, not a complete link inventory — Google describes it as a page it possibly used to discover the URL, which can be a direct link, a higher-level page the link was found through, or simply absent if the information isn’t available. Pair it with the methods below rather than stopping there.
• With a crawler / site audit: Ahrefs Site Audit or Screaming Frog will list your broken internal links — the in-house 404s you can fix directly by editing the link.
• With a backlinks tool: check broken backlinks to find dead URLs on your site that external sites link to. These are your 301 priorities.
• In server logs: the ground truth for which URLs are being requested and what status codes they return at scale.

Validate the fix and what to expect

Once you’ve restored or redirected the URLs that should exist, you can hit Validate Fix in the Page Indexing report. It’s optional, not required — Google says it can pick up a correction on its own the next time it crawls the page, whether or not you validate. Hitting Validate Fix just lets you track that review as it happens; it doesn’t come with a guaranteed timeline or a promise of faster reprocessing. Don’t expect the count to drop to zero right away either way: Google re-crawls 404s on a tapering schedule, so even correctly-handled URLs can linger in the report for a while. That lingering is the re-check behavior, not a sign the fix didn’t take, and there’s no fixed point at which Google guarantees it’s done. (And there’s no reason to validate a 404 that’s genuinely correct just to try to make it disappear from the report — validation is for confirming a fix, not for dismissing a working 404.)

For very large sites generating mass bogus 404s (millions of junk URLs from a broken template or a spider trap), crawl efficiency becomes a real concern and you’ll want pattern-based fixes rather than one-by-one work — but for typical sites, the crawl-budget cost of 404s is negligible.

Where this sits among its siblings

“Not found (404)” is the clean case: the server correctly said “not found.” Its neighbors in the Page Indexing report are different situations — don’t conflate them. A soft 404 is a not-found message served with a 200 (or an irrelevant redirect), which Google flags separately. Blocked due to other 4xx issue covers 401/403 and the rest of the 4xx family. Redirect error is a broken redirect, distinct from the normal “Page with redirect.” And server error (5xx) means the server failed, not that the page is gone. The fixes diverge, so identify which status you’re actually looking at first.

For the report as a whole, see the GSC Page Indexing hub; for the underlying mechanics of how bots request URLs in the first place, see crawling.

AI summary

A condensed take on the Advanced version:

• What it means: Googlebot requested a URL Google describes as discovered on its own — a link, or a previously-indexed page — not through an explicit request from you, and got an HTTP 404, so the page isn’t indexed. Google’s definition: “This page returned a 404 error when requested.” That’s a description of discovery, not proof the URL is missing from your current sitemap — a URL that’s still listed there is a separate problem worth fixing.
• Where the URL came from: internal/external links, pages you deleted or renamed, or scraped/malformed/fabricated URLs from elsewhere. Finding a 404 here doesn’t mean you did something wrong.
• SEO impact: not automatic. Google’s own documentation says 4xx statuses other than 429 don’t affect crawl rate, and a correctly-returned 404 for a removed page with no replacement is not a sitewide penalty. But a 404 on a URL that should work — linked, in a sitemap, with backlinks, or with traffic — still costs broken links, lost equity, or lost users.
• What Google does: removes a previously-indexed URL from the index; doesn’t process newly-found 404s; keeps re-checking the URL with decreasing frequency — which is why old 404s linger in the report (normal, not a penalty).
• When to fix: only URLs that should exist — linked internally, in a sitemap, with backlinks, or with traffic.
• How to fix: restore the page, or 301 it to a genuinely relevant live page. Prioritize 404s with inbound links to recover equity. Leave genuinely-gone pages as 404 (or 410, which Google treats the same as 404 in its own documentation, though in practitioner experience it tends to drop a touch faster).
• Don’t: mass-redirect everything to the homepage — irrelevant redirects get treated as soft 404s.
• 404 vs 410 vs 301 vs noindex: 404/410 = gone (both drop from index); 301 = moved (consolidate onto a replacement); noindex = keep the page live but out of search.
• Find the links via GSC “Referring page” (one possible clue, not a complete link list), a crawler (broken internal links), a backlinks tool (broken backlinks), or server logs. Validate Fix is optional — Google can detect a correction without it, and neither path has a guaranteed timeline.

Official documentation

Primary-source documentation from the search engines.

Google

• Page indexing report — the report this status lives in, including the “Not found (404)” definition and the “it’s fine for a URL not to be indexed for the right reasons” guidance.
• HTTP status codes, network errors, and DNS errors — how Google handles 4xx: removing previously-indexed URLs, not processing newly-found 404s, and the gradually-decreasing crawl frequency.
• Redirects and Google Search — how to set up the 301 redirects you’ll use to send the 404s that should exist to relevant live pages.
• How to remove a page from search (block indexing) — when you want a live page out of search (noindex), which is a different goal from a 404.

Bing / Microsoft

• Bing Webmaster Tools — Site Explorer & URL inspection — Bing’s crawl information surfaces 404s the same way; the handling guidance aligns with Google’s (fix the ones that matter, let genuine dead pages 404).

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the “Not found (404)” definition

• “This page returned a 404 error when requested.” — Google Search Console Help, Page indexing report. Jump to quote

Google — it’s fine for a URL not to be indexed

• “It’s fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” — Google Search Console Help, Page indexing report. Jump to quote

Google — how 4xx is handled in indexing

• “In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.” — Google Search Central, HTTP status codes documentation. Jump to quote
• “The crawling frequency gradually decreases.” — Google Search Central, HTTP status codes documentation. Jump to quote

The mental models

1. Discovered ≠ submitted. “Not found (404)” specifically means Google found the URL on its own — a link, an old indexed page, a mangled URL from another site — not from your sitemap. So the first question isn’t “how do I fix it” but “should this URL even exist?”

2. 404 is the correct answer for a dead page. A 404 isn’t an error to eliminate; it’s the right HTTP response when content is gone. It’s not a quality signal and not a ranking signal. The goal is accuracy — have URLs return what’s actually true — not a zero count in the report.

3. Fix only what should exist. Run every 404 through one test: is it linked internally, in a sitemap, backed by external links, or still getting traffic? Yes → restore or 301 to a relevant page. No → leave it as a 404. This one rule resolves most of the report.

4. Recover equity before you recover URLs. Among the 404s worth fixing, the ones with inbound external links come first — a 301 to a relevant page reclaims that link value. A 404 with no links and no traffic is fine to leave alone; redirecting it gains you nothing.

5. Relevant redirect or no redirect. A 301 only helps when it lands on a genuinely related page. An irrelevant redirect (everything → homepage) gets treated as a soft 404. When there’s no good destination, the right move is to keep the 404, not to invent one.

Triaging your “Not found (404)” list

Work the report top to bottom:

• Open the “Not found (404)” status in the Page Indexing report and review the example URLs.
• For each URL, click in and check Referring page under Discovery — a possible clue to where Google found the link, not a guaranteed complete inventory.
• Flag any URL that is linked internally — fix the broken internal link at the source (this is the cleanest win).
• Flag any URL that is in your sitemap — it shouldn’t be; remove it or restore the page.
• Pull the 404 URLs that have external backlinks (broken-backlinks report) — these are your 301 priorities to recover equity.
• Check which 404s still receive traffic or clearly match user intent.
• For each “should exist” URL: restore the page, or 301 it to a genuinely relevant live page (not the homepage).
• Leave genuinely-gone URLs with no links/traffic as 404 (or 410 if you want a slightly faster drop).
• Confirm no live redirects dump unrelated URLs onto / (soft-404 risk).
• Optionally hit Validate Fix (Google can also pick up a real fix on its own) — then expect a slow taper, not an instant zero, with no fixed timeline.
• Confirm you’re triaging the right status (not soft 404, other 4xx, redirect error, or 5xx — the fixes differ).

Playbook: respond to a sudden 404 spike

1. Confirm the spike is real. Compare Search Console examples with a live crawl or server responses; reports can lag behind current behavior.
2. Group by cause and template. Look for a deployment, URL-pattern change, internal-link bug, deleted section, or malformed generated URL rather than fixing rows individually.
3. Prioritize URLs with value. Restore or redirect URLs that should exist, have meaningful backlinks or traffic, or remain in internal links and sitemaps.
4. Leave legitimate removals alone. A truly gone URL with no replacement should keep returning 404 or 410; do not redirect it to an irrelevant page.
5. Repair the source. Update templates, internal links, and sitemap generation so they stop producing or promoting the broken pattern.
6. Validate and watch recurrence. Test representative URLs and monitor the pattern. Exit when valuable URLs resolve correctly and newly discovered 404s return to the expected baseline.

404 cheat sheets

Which response for which situation

Should I fix this 404? — decision flow

Fast facts

• “Not found (404)” = Google describes finding the URL without an explicit request from you — that’s how it was discovered, not proof it’s absent from your current sitemap.
• A correctly-returned 404 is not automatically a sitewide quality or ranking penalty — but a 404 on a URL that should work still costs links, traffic, or users.
• Google removes a previously-indexed URL on 404; doesn’t process new 404s.
• Googlebot keeps re-checking old 404s with decreasing frequency → they linger.
• 404 vs 410: Google’s docs treat 4xx codes (except 429) the same; in practitioner experience 410 drops a touch faster.
• Don’t redirect everything to the homepage → soft 404.
• Crawl-budget cost of 404s is negligible except on very large sites with mass bogus URLs.

Common issues

The 404 count suddenly spikes in the Page Indexing report

Likely cause: a broken template is generating junk URLs (bad pagination parameters, a faceted-nav bug, session IDs leaking into links), a spider trap, or another site is scraping and mangling your URLs. Fix: pull a sample of the new 404 URLs and look for a shared pattern (a query parameter, a path prefix). If it’s your own template, fix the code generating the bad links. Check via server logs or /tools/log-file-analyzer to confirm the pattern and see whether it’s real crawl volume or just a handful of examples.

You fixed a URL but it still shows “Not found (404)” weeks later

Likely cause: Googlebot re-checks 404s on a tapering schedule, so the report count lags behind the actual fix — this is expected, not a sign the fix failed. Fix: confirm the live URL is actually returning the right status now (200 if restored, 301 if redirected) using curl -I or /tools/http-status-checker. You can optionally hit Validate Fix in GSC — it’s not required, since Google can also pick up a correction on its own — and expect the count to taper down gradually rather than drop instantly, with no fixed timeline for when it clears.

A removed URL shows up as “soft 404” instead of “Not found (404)”

Likely cause: the page is returning HTTP 200 with a “not found”-looking message instead of an actual 404/410 status, or it’s redirecting to an irrelevant page. Fix: check the response code with curl -I or /tools/http-status-checker — if it’s a 200, configure the server (or CMS) to return a real 404/410 for that path instead of a soft error page.

A 301 you set up shows as “soft 404” for the destination

Likely cause: the destination page isn’t a genuine replacement for what was requested — Google reads a mismatched redirect target the same way it reads an irrelevant one. Fix: re-check the target with /tools/redirect-checker and point the 301 at a page that actually matches the original URL’s topic, not the nearest category page or the homepage.

The report lists a URL you never created or linked to

Likely cause: a scraped, malformed, or fabricated URL from another site, or a page from years ago that Google still remembers and periodically re-checks. Fix: click the URL in the report and check Referring page under Discovery — a possible clue, not a guaranteed source, since Google may not have that data available. If it’s external and clearly mangled, no action is needed — it isn’t something you broke.

Scripts and snippets

Check a URL’s live status (macOS/Linux)

Confirm what status code a URL is actually returning before you decide whether it needs fixing:

curl -I https://example.com/old-page

Look at the first line of the response (e.g. HTTP/2 404 or HTTP/2 301). If it’s a redirect, curl shows the location: header with the destination.

Check a URL’s live status (PowerShell)

$response = Invoke-WebRequest -Uri "https://example.com/old-page" -Method Head -UseBasicParsing
$response.StatusCode

Add -MaximumRedirection 0 if you want to see the raw 301/302 without PowerShell following it automatically.

Grep server logs for 404 hits (regex)

Run this against an Apache/Nginx “combined” format access log to pull every request that returned a 404:

grep -oP '"\S+ \K\S+(?=.*" 404 )' access.log

Capture-group breakdown: "\S+ \K skips past the HTTP method (GET/POST) and discards it from the match; \S+ captures the requested path; the lookahead (?=.*" 404 ) requires that the rest of the log line contains a 404 status before matching. The output is a plain list of the URLs that 404’d — pipe it through sort | uniq -c | sort -rn to rank them by frequency.

DevTools Console — check status without leaving the page

Paste into the Console panel to check a specific URL’s status from the browser you’re already in:

fetch("https://example.com/old-page", {method: "HEAD"}).then(r => console.log(r.status, r.url));

Bookmarklet — check the current page’s status

Drag this into your bookmarks bar (it’s a bookmarklet — click it while on any page to check that page’s own response status):

javascript:(function(){fetch(location.href,{method:"HEAD"}).then(function(r){alert(r.status+" "+r.url);});})();

Tools for finding and fixing 404s

This site’s tools

• /tools/http-status-checker — check the live HTTP status of any URL before deciding whether it needs a redirect, a restore, or nothing at all.
• /tools/redirect-checker — confirm a 301 you set up actually resolves in a single hop to the intended destination, with no chains or loops.
• /tools/log-file-analyzer — parse server logs to see the actual URLs Googlebot is hitting that return 404s, and at what frequency.
• /tools/site-audit-lite — crawl your own site to surface broken internal links (the 404s you can fix directly by editing the link at the source).

Third-party tools

• Google Search Console — the Page Indexing report itself; open a “Not found (404)” example and use the Referring pages view to see what linked to it, and Validate Fix once you’ve made a change.
• Bing Webmaster Tools — the equivalent crawl-error surface for Bing.
• Ahrefs or Screaming Frog — full-site crawls that list broken internal links, and backlink reports that surface broken backlinks (external sites linking to a dead URL on your site) — your priority list for 301s.

Validating a 404 fix

Run these after restoring or redirecting a URL that should exist, to confirm the fix actually took effect rather than just assuming it did.

Live status check on the fixed URL

Test to run: curl -I on the URL, or /tools/http-status-checker. Expected result: 200 if you restored the page, or a 301 to the correct destination if you redirected it. Failure interpretation: still 404, a 5xx, or a redirect pointing at the wrong page means the fix didn’t actually deploy. Monitoring window: immediate. Rollback trigger: wrong status or wrong destination — fix the server rule and re-check before moving on.

Redirect path check

Test to run: /tools/redirect-checker on the old URL. Expected result: a single-hop 301 landing directly on the relevant live page — no chain, no loop. Failure interpretation: multiple hops, a loop, or landing on an unrelated page (soft-404 risk). Monitoring window: immediate. Rollback trigger: any chain, loop, or irrelevant destination — correct the redirect rule.

GSC Validate Fix

Test to run: in the Page Indexing report, open “Not found (404)” and hit Validate Fix (optional — Google can also detect a real correction on its own without it). Expected result: status moves through “Validation started” to “Passed,” and the affected URL count tapers down. Failure interpretation: validation fails, or the count doesn’t move over an extended period — re-check that the live URL is actually fixed and that nothing still links to the old one. Monitoring window: ongoing, with no fixed completion date (Google re-checks 404s on a tapering schedule, not instantly, and gives no guaranteed timeline). Rollback trigger: repeated validation failure — re-verify the fix at the server level.

Crawl behavior in server logs

Test to run: /tools/log-file-analyzer on requests to the old URL. Expected result: Googlebot’s hits on the old URL taper off over time while requests shift to the new URL. Failure interpretation: Googlebot keeps hitting the old URL at an unchanged rate well after the change, suggesting it hasn’t picked up the redirect (or something still links to the old URL directly). Monitoring window: ongoing, over an extended period (crawl frequency decreases gradually, per Google’s own documentation, with no fixed schedule). Rollback trigger: no tapering after an extended period — confirm the redirect is server-side (not a JS or meta-refresh redirect) and audit for lingering internal links to the old URL.

Quiz

Five questions to check what actually sticks about “Not found (404).”

Not found (404)

A Google Search Console Page Indexing status meaning Googlebot requested a URL it says it discovered on its own — not proof it's absent from your current sitemap — and got a 404 Not Found, so the page isn't indexed. Usually fine unless the URL should still exist.

Parent concept: Page Indexing report · Related: Blocked due to other 4xx issue, Redirect error, Crawling

Not found (404)

Not found (404) is a status in Google Search Console’s Page Indexing report, under “Why pages aren’t indexed.” It means Googlebot requested the URL and the server returned an HTTP 404 (Not Found), so the page wasn’t indexed. The defining detail: Google says it discovered this URL without any explicit request or sitemap from you. That describes how Google found the URL — not proof it has never appeared in, or isn’t currently sitting in, one of your sitemaps; a URL still listed in a live sitemap is a separate, fixable problem. Google usually found it as a link from another page (yours or someone else’s), or it’s a page that existed before and was deleted.

A “Not found (404)” status is not necessarily a problem. 404s are a normal part of the web, and Google’s own crawl documentation says 4xx statuses other than 429 don’t affect a site’s crawl rate — a correctly-returned 404 isn’t a sitewide penalty. A 404 for a page you removed and won’t replace is the correct outcome, not an error to chase. But a 404 on a URL that should still work — one that’s linked, in a sitemap, or has backlinks — still costs you something (a broken link, lost equity, a lost visitor), so it’s worth diagnosing rather than dismissing on sight.

It only needs fixing when the URL is one that should exist — ones you link to internally, list in a sitemap, that have external backlinks, or that still get traffic. For those, restore the page or 301 redirect it to the most relevant live page. Genuinely-gone pages should keep returning 404 (or 410). This is distinct from its siblings: “Blocked due to other 4xx issue” (401/403/other 4xx), “Redirect error” (a broken redirect), and “Soft 404” (a not-found message served with a 200).

Parent concept: Page Indexing report · Related: Blocked due to other 4xx issue, Redirect error, Crawling

Changelog