What is a 404 error?

What does a 404 response actually tell a visitor or crawler?

A 404 response tells a requesting client that the server has no current representation to provide for that address, or declines to disclose one. It does not establish why the resource is missing. Diagnose the intended resource before deciding whether to restore content, redirect a genuine move, or retain the missing response.

• The HTTP standard’s 404 definition, accessed October 8, 2026, does not require the condition to be permanent.

  That matters when interpreting a report. A typo, incomplete release, deliberate removal, or access policy can produce the same status while requiring different action.

• The visible page is a separate part of the response.

  It can contain a clear explanation, current navigation, and a way to recover. A branded design does not require a successful status. Customers can receive useful assistance while the response accurately says that the requested resource is unavailable.

• Search engines also interpret the response.

  Google’s HTTP status guidance explains how missing responses affect its crawlers. A correct response is useful infrastructure, but it is not evidence that the business made the right removal decision. An active service may still need restoration.

• Avoid describing every 404 as a website fault.

  Unknown addresses inevitably exist, including mistyped and invented paths. The important question is whether someone is directed to missing information that should be available. That ties the investigation to publishing intent and customer access instead of a raw error total.

How does a real 404 differ from a soft 404?

A real 404 delivers the missing-resource status in the HTTP response. A soft 404 is a search-engine interpretation of content that appears missing or empty despite a different delivery response. Inspect both the status and the page content, because either can be wrong independently and require a different repair.

What should be checked before changing a missing URL?

Before changing a missing URL, establish whether its resource should still exist, moved to an equivalent destination, or was removed without a replacement. Use the current service inventory and publishing history. The response alone cannot determine business intent, and redirecting before that decision can conceal a content loss or send visitors somewhere irrelevant.

• Start with the actual address, including host, path, and query.

  Identify the source of the request: current navigation, a past campaign, a customer bookmark, a search result, or a fabricated path. Those sources do not change the protocol meaning, but they reveal who is affected and how the failure is introduced.

• If the service remains active, compare the route with its published record.

  A renamed slug may have lost its mapping. A record may be unpublished accidentally. A template may use an outdated field. Repair the specific fault and confirm the substantive explanation returns publicly, rather than replacing it with generic text.

• If the resource moved, identify its equivalent destination.

  A 301 redirect can represent a permanent move once that relationship is established. If no comparable information exists, retaining the missing response can be accurate. Neither choice should be made solely to reduce the number displayed by an auditing tool.

• Record uncertain intent as uncertain.

  A developer can verify routing but may not know whether a retired service will return. Ask the person responsible for that offering before encoding a permanent destination. The useful outcome is an accurate resource decision, not a response change whose rationale nobody can explain.

How can the actual response be tested with a full GET?

Test the actual response with a full GET request that retrieves the document a visitor receives. Keep the initial response separate from any later redirect destination. A header-only request may follow a different server branch, so it cannot always establish what the ordinary document request delivers or whether the body matches its status.

The HTTP method definitions distinguish GET from HEAD. Use browser network tools or an appropriate command-line request to capture status, headers, and the returned body. Keep authentication and request conditions visible in the test notes when they affect the result.

curl --request GET --dump-header response-headers.txt \
  --output response-body.html https://example.com/retired-service/

This illustrative command saves the initial document and headers without automatically following redirects. The hostname is a syntax example, not a live business finding. Inspect the saved response before deciding whether another request is needed. When a redirect exists, follow and inspect its destination as a separate step.

• In browser tools, preserve the document request and identify which response belongs to it.

  A missing image or analytics call may show 404 while the main page succeeds. Conversely, a successful asset request does not prove the document succeeded. Match the address and resource type rather than reading an isolated red entry.

• Retest the same public URL after repair.

  A screenshot can show the interface but cannot demonstrate the transport status. A status capture can show delivery but cannot prove that the intended content arrived. Keep both observations when the failure involves the page itself, and distinguish the current result from older recorded evidence.

How can broken internal links be traced to their source?

Broken internal links should be traced from the missing destination back to the page or component that sends visitors there. Repairing the referring link prevents repeated customer failure at its source. The missing destination may also need restoration or a redirect, but that does not justify leaving current navigation pointed at obsolete addresses.

• Search the rendered link inventory and the underlying content or template.

  A site-wide header can repeat one bad destination across many pages. An editorial article may contain a single outdated reference. Treat the component or content record as the repair unit rather than making many disconnected page edits.

• Check the actual anchor destination, not only its visible label.

  Relative paths can resolve differently when a page moves. A root-relative service link and a path-relative sibling link may lead to different locations. Confirm the browser’s resolved URL before concluding that the named service itself is missing.

• Review punctuation and case conventions where the hosting environment distinguishes them.

  A trailing slash policy can also introduce inconsistent routes. Normalization rules should reflect the application’s intended URL design. Do not add ad hoc redirects before checking whether a broader routing inconsistency is responsible.

• After changing the source, recrawl or inspect representative affected pages.

  Verify that navigation now leads directly to the intended resource. A redirect may remain useful for external references, but current internal navigation should not depend on an avoidable detour when the correct address is known and available.

When is restoring the original resource better than redirecting it?

Restoring the original resource is appropriate when that address should still provide an active, distinct piece of information and its absence is accidental. A redirect can hide a failed publication without replacing what visitors need. Check content intent and route stability before changing an established address that customers or current navigation still expect to work.

• Look for a failed release, deleted content record, altered routing key, or unavailable build output.

  Compare the intended page with a known working resource from the same implementation. That comparison can expose a template-wide defect, but it should not be treated as proof that every missing path deserves restoration.

• Restore accurate information rather than cloning another service page.

  A lost explanation may need a verified service scope, location, contact route, or eligibility detail. The editor should confirm these facts with the business. Technical recovery cannot establish whether old commercial information is still correct enough to publish.

• Review associated resources as well.

  A restored page can still link to missing downloads or display broken essential images. A successful document response is only part of the customer task. Check the resources required to understand or complete that task while keeping decorative failures separate from missing core information.

When should a missing page redirect to a replacement?

An equivalent new address justifies a redirect when the original resource has genuinely moved and the destination serves the same purpose. Match the old task with the new information. A permanent redirect communicates a move, while a blanket homepage destination can leave customers without the specific explanation that the old address promised to provide.

• Google’s redirect guidance, accessed October 8, 2026, explains permanent and temporary moves.

  Its site-move guidance recommends URL mapping. Neither establishes that any available page is an acceptable destination for every retired resource.

• Illustrative mapping decision: an old boiler-repair URL is replaced by a new boiler-repair URL after a naming change.

  The new page covers the same service and customer task. Redirecting that old address is understandable. Sending a retired commercial-refrigeration article to a general residential homepage requires a different relevance assessment.

• Inspect the destination’s own response and content before enabling the mapping.

  An apparently valid redirect can terminate at another missing page. A redirect chain may also route through obsolete mappings before reaching its final destination. Test the complete path rather than counting the first redirect as a successful repair.

• Update current links to the intended final destination and retain useful old mappings for established references.

  Avoid loops, self-redirects, or mappings that depend on ambiguous prefix matches. A relevant destination and predictable route are both necessary for the change to serve the visitor who followed the original address.

When is keeping a 404 response the correct decision?

Keeping a 404 response is correct when the requested resource is unavailable and there is no justified restoration or relevant move to represent. Unknown addresses and retired resources do not need invented pages. Preserve helpful error navigation, and remove obsolete references that the site controls when those references no longer serve a legitimate purpose.

• Google’s Page indexing documentation explains that removed pages without replacements can appropriately remain unavailable.

  A report category identifies an observation; it does not instruct the business to create content for every address that a crawler discovers or a visitor mistypes.

• Distinguish genuine old resources from arbitrary paths.

  A typo in an external link may warrant a narrowly justified correction if its intended resource is obvious. An invented path does not automatically deserve a permanent redirect. Broad fallback rules can create confusing behavior and make actual route defects harder to recognize.

• Remove retired addresses from the current XML sitemap if they are no longer intended resources.

  Update owned navigation and content references where appropriate. These changes align the current inventory with the resource state; they do not require suppressing every possible future request to the old address.

• Do not use a robots block as a substitute for accurate delivery.

  A robots.txt rule controls permitted crawling, not the existence of a replacement resource. Preventing a crawler from requesting the page can also prevent it from observing the response that correctly represents the removal.

How does 410 Gone change the interpretation?

A 410 response expresses that the resource is no longer available and the condition is likely permanent. A 404 does not assert that permanence. Choose according to what the server operator actually knows. For Google indexing, the distinction should not become a promise of a specific removal speed or a reason to redesign every retired route.

Why can a cached 404 remain after the resource returns?

An intermediary or browser can continue serving an earlier missing response even after the origin has restored the requested document. Repairing the origin does not necessarily replace every cached representation immediately. Compare the public response with the intended origin behavior and inspect cache controls before attributing a continuing failure to the restored content itself.

• The HTTP standard identifies 404 as heuristically cacheable unless other conditions or controls apply.

  This is a protocol possibility, not proof that a particular CDN cached the error. Confirm available cache evidence and the platform’s configured behavior for the affected route.

• Capture the public response from a fresh request and note available delivery headers.

  An authenticated administrator may bypass caching or use a different path. A working dashboard preview therefore does not prove that an anonymous visitor receives the restored resource. Test the address customers actually follow.

• If the origin works but the public edge still serves the previous missing response, inspect the relevant cache state and invalidation method.

  If both are missing, revisit the application repair. Purging cannot fix an active rule that keeps generating 404, and an origin-only change cannot establish that public delivery has recovered.

How should temporary failures be separated from missing resources?

Preserve the application’s knowledge of the underlying cause instead of converting every unsuccessful lookup into a not-found response. An unavailable database is different from a completed lookup that finds no resource. Returning 404 for both can misrepresent active content as absent and lead to removal decisions that should instead address delivery reliability.

• Google’s HTTP guidance distinguishes server failures from client-error responses.

  The HTTP standard describes temporary service unavailability separately. Choose the response that matches the condition instead of treating the normal page template as proof of successful delivery.

• Check where exceptions become empty results.

  A content adapter may catch an upstream timeout and return an empty object. The route handler then mistakes that object for a deleted record. Preserve explicit failure states through that boundary so the response handler can tell unavailable data from confirmed absence.

• Do not apply missing-resource instructions to optional dependencies automatically.

  An unavailable analytics endpoint does not remove the main service explanation. An unavailable primary record may prevent the application from delivering that explanation at all. These are different dependency relationships, even when both appear as errors in browser tools.

• Test recovery after the dependency returns.

  Confirm the intended document response and substantive content, plus any metadata changed during the error state. An error-only noindex instruction should not remain on the recovered active page. A working data call alone does not demonstrate that every output state reset correctly.

How should Search Console and request logs be reconciled?

Match the address, observation time, and delivery conditions when comparing an indexing report with recorded server activity. A historical indexing observation can differ from today’s public response. Logs can confirm recorded requests but may omit edge-served traffic. Neither source alone explains the intended resource state or proves that every visitor received the same result.

• Google’s URL Inspection documentation distinguishes indexed information from a live test.

  Use that distinction when a repaired page still appears under a missing category. Establish whether the available evidence predates the release before deciding that the current route needs another change.

• Use log-file analysis to examine available document requests, response statuses, and referring context.

  Verify crawler identity when making crawler-specific claims. A user-agent string alone can be copied. Partial origin exports should not be presented as complete accounts of activity at every delivery layer.

• Check whether missing requests concern documents or resources such as images and scripts.

  A broken required script can affect the rendered page without making its document request return 404. Conversely, a successful script response does not restore a missing main document. Match each observation to the resource it describes.

• Keep counts comparable.

  A report can count example URLs while a log export counts repeated requests. Those totals answer different questions. Use the observations to identify actual affected routes and visitors rather than presenting a larger request total as evidence that more distinct pages disappeared from the website.

What should a useful 404 page and repair test include?

A useful 404 page explains that the requested resource is unavailable and gives relevant ways to continue. Its repair test should confirm both accurate status and practical navigation. Test a known working route, a genuinely unknown route, and the specific repaired address so a catch-all change cannot silently reverse the intended behavior.

• Use clear language that avoids blaming the visitor for an error the site may have introduced.

  Offer stable navigation, search where it works, and appropriate contact options. Do not promise that a general service page contains the missing information unless it does. Recovery links should help the visitor make a sensible next choice.

• Check that the error interface itself has functioning links and accessible controls.

  A broken search form or navigation destination compounds the original failure. Confirm the layout does not rely on a missing essential asset. These are interface checks alongside the transport check, not substitutes for the correct response.

• After restoring or redirecting an address, revisit the original referring context.

  The customer should reach the intended resource from that link. After retaining a correct missing response, remove misleading owned references. This tests whether the repair solves the actual customer path rather than only changing a response in isolation.

Continue the public-page review

Our website SEO checker provides preliminary public-page signals. Verify the response and resource decision through the checks above. Our technical SEO services help connect a confirmed routing or delivery failure with the appropriate repair.