Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

404

HTTP 404 Not Found status: target resource representation absent

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 404 (Not Found) means the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. Check the exact URI spelling, path case, and base domain, test a hard refresh to rule out a cached 404, and record the failing URL.

Safety first

Stop and check this first

  • Never run automated path-enumeration scripts against 404 responses or disable authorization checks on the server; RFC 9110 Section 15.5.4 permits servers to return 404 to conceal forbidden resources, and repeating identical unauthenticated requests will not reveal them.

Safe checks you can perform

  • Verify the exact URI path, character case, and origin root page
  • Bypass local and intermediary caches or inspect response headers with curl
  • Check origin access logs and route definitions for the requested URI and auth context

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Restore the target representation, configure a redirect, or return 410 Gone for permanent removal
  • Do not attempt this professional task: Purge cached 404 entries and set explicit Cache-Control headers on the origin

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Restore the target representation, configure a redirect, or return 410 Gone for permanent removal

    What they doHave the web developer or site administrator restore the missing file or route if it was removed by mistake, configure a 301/308 redirect if the resource moved to a new URI, or configure the origin server to return 410 (Gone) when the resource has been permanently retired.

    They must show youa curl -i response from the old URI showing the restored 200 OK representation, the redirect Location header, or the 410 Gone status.

    In writingthe updated route mapping or redirect rule deployed and the HTTP status code now returned for the URI.

  2. Purge cached 404 entries and set explicit Cache-Control headers on the origin

    What they doIf a newly deployed page or API endpoint continues returning 404 through a CDN or proxy cache, have the hosting or platform administrator purge the cached URI key and configure explicit Cache-Control or Expires headers on the origin server.

    They must show youthe CDN or proxy cache purge confirmation alongside a fresh HTTP 200 OK response carrying explicit Cache-Control headers.

    In writingthe purged URI paths, the Cache-Control policy configured for 404 responses, and the verification timestamp.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Verify the exact URI path, character case, and origin root page

    No special tools

    Who:
    You in your web browser or API client.
    How:
    Inspect the full URI for typos, trailing slashes, file extensions, or uppercase/lowercase differences, and open the root homepage of the same domain to confirm the origin server responds.
    Result that matters:
    Comparing the failing target URI against the site root separates a path-level 404 from a whole-domain outage.
    If the domain homepage loads and correcting a typo or path segment returns 200 OK, that confirms the 404 was caused by a mistyped URI or broken link.
    If the exact documented URI still returns 404 while the site root works, that points to a moved, removed, or access-restricted resource on the server.
    Evidence to keep:
    Record the exact failing URI, the referring page or link source, and the timestamp of the request.

    Evidence: RFC 9110 section 15.5.5 - 404 Not Found · RFC 9110 section 15.5 - Client Error 4xx

  2. Bypass local and intermediary caches or inspect response headers with curl

    Tools required

    Who:
    You or your web developer using a browser private window or curl.
    How:
    Perform a hard reload in the browser or run curl -i on the URI to inspect the HTTP status line and caching headers such as Date, Cache-Control, Expires, and Age.
    Result that matters:
    Because RFC 9110 Section 15.5.5 makes 404 responses heuristically cacheable, an intermediary or browser cache can keep serving an older 404 after a resource is published.
    If the resource loads with 200 OK in a private window or when bypassing the cache, that confirms a heuristically cached 404 response caused the error.
    If the origin server still generates a fresh Date header with HTTP 404, that rules out a stale cache and confirms the origin currently rejects or lacks the target resource.
    Evidence to keep:
    Save the raw HTTP response header lines (with any session cookies or tokens redacted) and the timestamp.

    Never brute-force or enumerate neighboring URL paths or private object IDs when testing a 404, and redact any Authorization or Cookie headers before sharing curl output.

    Evidence: RFC 9110 section 15.5.5 - 404 Not Found · RFC 9111 section 4.2.2 - Calculating Heuristic Freshness

  3. Check origin access logs and route definitions for the requested URI and auth context

    Tools required

    Who:
    The site administrator, backend developer, or API owner.
    How:
    Search the origin server and reverse-proxy access logs for the request timestamp and path, verify whether the route exists in the current deployment, and check whether an authorization filter intentionally returns 404 instead of 403.
    Result that matters:
    Access logs and route tables show whether the 404 came from an unmatched route, a missing database record, or an intentional RFC 9110 Section 15.5.4 concealment rule.
    If the route or record is absent from the origin deployment, that confirms the representation is missing and needs restoration, a redirect, or 410 Gone.
    If the resource exists but an authorization rule returned 404 to an unauthenticated or unauthorized caller, that confirms intentional concealment of a protected resource.
    Evidence to keep:
    Keep the matching server access log line showing the request method, URI path, status 404, and timestamp.

    Do not disable authentication middleware or expose private routes publicly just to test whether a 404 disappears.

    Evidence: RFC 9110 section 15.5.4 - 403 Forbidden · RFC 9110 section 15.5.5 - 404 Not Found · RFC 9110 section 15.5.11 - 410 Gone

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 404 Nicht gefunden
  • 404 No encontrado
  • 404 Non trouvé
  • 404 Non trovato
  • 404 Not Found
  • código HTTP 404
  • error HTTP 404
  • événement SMA 404
  • evento SMA 404
  • HTTP 404
  • HTTP error 404
  • HTTP status 404
  • inversor SMA 404
  • inverter SMA 404
  • onduleur SMA 404
  • SMA Ereignis 404
  • SMA event 404
  • SMA inverter 404
  • SMA Wechselrichter 404
  • status code 404
  • Sunny Tripower X 404

What it means

Defined in RFC 9110 Section 15.5.5 and registered in the IANA HTTP Status Code Registry under 4xx Client Error, status code 404 (Not Found) indicates that the origin server did not find a current representation for the target resource or chooses not to reveal its existence. Section 15.5.5 notes that 404 does not state whether the condition is temporary or permanent (status 410 Gone is preferred when known to be permanent) and that a 404 response is heuristically cacheable under RFC 9111 Section 4.2.2. Receiving 404 alone never proves the server process is down.

Warnings and stop conditions

  • Mediumsource verified

    Never run automated path-enumeration scripts against 404 responses or disable authorization checks on the server; RFC 9110 Section 15.5.4 permits servers to return 404 to conceal forbidden resources, and repeating identical unauthenticated requests will not reveal them.

    Evidence: RFC 9110 section 15.5.4 - 403 Forbidden · RFC 9110 section 15.5.5 - 404 Not Found

Symptoms and causes

Probable causes · in order

  • Mistyped URI path, wrong case, or broken link to a non-existent resourceConfirmed

    Under RFC 9110 Section 15.5 and Section 15.5.5, the origin server returns 404 (Not Found) when the target URI requested by the client does not map to any current representation on the server.

    Evidence: RFC 9110 section 15.5.5 - 404 Not Found · IANA HTTP Status Code Registry · RFC 9110 section 15.5 - Client Error 4xx

  • Resource removed or relocated without a redirect or 410 Gone statusCommon

    When a page or API endpoint is removed or moved and the server owner has not configured a redirect or a 410 (Gone) status code, requests to the old URI receive 404 (Not Found).

    Evidence: RFC 9110 section 15.5.5 - 404 Not Found · RFC 9110 section 15.5.11 - 410 Gone

  • Origin server intentionally concealing a forbidden resource with 404 instead of 403Possible

    RFC 9110 Section 15.5.4 and Section 15.5.5 explicitly allow an origin server that wishes to hide the current existence of a forbidden target resource to respond with 404 (Not Found) instead of 403 (Forbidden).

    Evidence: RFC 9110 section 15.5.4 - 403 Forbidden · RFC 9110 section 15.5.5 - 404 Not Found

  • Stale 404 response served from a browser, proxy, or CDN heuristic cachePossible

    RFC 9110 Section 15.5.5 defines a 404 response as heuristically cacheable unless restricted by explicit cache controls, and RFC 9111 Section 4.2.2 allows a cache to assign a heuristic expiration time when none is specified.

    Evidence: RFC 9110 section 15.5.5 - 404 Not Found · RFC 9111 section 4.2.2 - Calculating Heuristic Freshness

Virtual technician

Does 404 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Sources and technical references

  1. 1

    RFC 9110 section 15.5.5 - 404 Not Found

    Internet Engineering Task Force · 2022 · official_doc

  2. 2

    IANA Hypertext Transfer Protocol Status Code Registry

    Internet Assigned Numbers Authority · 2025 · official_doc

Sources: RFC 9110 section 15.5.5 - 404 Not Found · IANA Hypertext Transfer Protocol Status Code Registryreviewed 2026-10-19 · verified

Was this entry useful?