Quick Answer
A Hypertext Transfer Protocol (HTTP) 404 response means the origin found no current representation or declined to disclose one. Visitors can check the address, use the site's navigation, or report a broken link. Site owners should restore the resource, repair the route or link, or redirect only to a relevant replacement.
Key Takeaways
- Meaning: A 404 means no current representation was found or disclosed; it is not a connection failure.
- Visitor action: Check the complete address, use the site's current navigation, and report confirmed broken links.
- Owner action: Restore missing content, repair broken links or routes, or redirect to a relevant replacement.
- Status choice: Use 404 when permanence is unknown, 410 for likely permanent removal, and 301 for permanently moved content.
- Soft 404: An error-like page that returns success is not a correct 404 response.
- Failure source: Proxy error codes can describe responses from a target, proxy, gateway, or another responding component.
How Does HTTP 404 Differ from Similar Errors?
HTTP 404 covers a missing current representation or concealed resource, while nearby status codes describe other specific failure types. The visible error page may look similar for several statuses. Inspect the numeric status before choosing a repair.
| Status | What it means | First check |
|---|---|---|
| `403 Forbidden` | The server understood the request but refuses it | Authentication, authorization, and access policy |
| `404 Not Found` | The origin found no current representation or will not disclose one | Address, resource, route, and deployment |
| `405 Method Not Allowed` | The method is known but unsupported by the target resource | Request method, route, and `Allow` header |
| `406 Not Acceptable` | The target lacks an acceptable representation under proactive negotiation | `Accept` fields and available formats |
| `410 Gone` | The resource is unavailable, and the condition is likely permanent | Removal decision and replacement availability |
A 404 differs from a connection failure because a server or intermediary returned an HTTP response. The response does not prove that the intended application handled the request. A content delivery network, gateway, web server, framework, or application can generate it.
A 404 can also conceal a forbidden resource, so it does not always prove nonexistence. Use 410 when the origin knows that removal is likely permanent. Use 301 only when the content has moved to a relevant replacement.
These distinctions prevent wasteful fixes. Changing credentials will not restore a deleted file, while changing a method will not correct a misspelled path.
What Does a 404 Error Mean?
HTTP 404 means the origin found no current representation or is unwilling to disclose one for the requested target resource. Request for Comments (RFC) 9110, published in 2022, defines both possibilities.
RFC 9110 does not classify the missing state as temporary or permanent. Requests using GET, HEAD, POST, and other methods can receive a 404 response because the status concerns the selected target.
An application programming interface can return a 404 response for an unknown object identifier or absent route. Some services also conceal protected resources with a 404 response.
A minimal response can look like this:
The status belongs to the 4xx client-error class, but that label does not assign blame to a person. A broken deployment or server route can cause a valid address to return 404. Diagnose the request and responding component before deciding who must act.
RFC 9110 also describes 404 as heuristically cacheable unless explicit controls or the method definition say otherwise. A cached 404 response can therefore remain visible after a repair. Owners should inspect cache headers and invalidate affected cache entries after confirming the underlying fix.
The response body and status serve different purposes. A custom page can offer navigation, search, and contact options while retaining the correct 404 status. Writing “not found” in a page that returns 200 does not create a real 404.
What Causes a 404 Error?
HTTP 404 errors usually come from incorrect addresses, removed content, broken routes, deployment gaps, or deliberate resource concealment. The immediate cause concerns the requested target. The component returning the status may differ across requests.
| Cause | Typical evidence | Likely owner |
|---|---|---|
| Address typo | Another spelling or path opens correctly | Visitor, editor, or linking site |
| Moved or deleted content | The old address disappeared after a content change | Content or search team |
| Broken internal link | A current page points to an invalid target | Site owner |
| Route mismatch | The application lacks a handler for the exact path | Developer |
| Missing deployed asset | Page markup references a file absent from the release | Development or operations team |
| Rewrite failure | Friendly paths fail, while a direct entry point works | Server or site administrator |
| Deliberate concealment | Protected targets return 404 instead of revealing existence | Application owner |
Addresses can differ by hostname, port, path case, trailing slash, extension, identifier, query handling, or locale prefix. Path case sensitivity depends on the server, file system, framework, and route configuration. Compare the complete requested address instead of checking only the visible page name.
Single-page applications can show a 404 when server routing misses a valid client-side path. Catch-all routing can instead return the application shell for an invalid client-side path.
The server may return the application shell with status 200 even when the application presents the route as missing. Content management system changes can leave old links, media paths, category addresses, or rewrite rules behind.
Deployment systems can omit generated files or publish page markup before its assets. Logs and release manifests can distinguish these causes from an ordinary mistyped address.
How Can Visitors Fix a 404 Error?
Visitors can directly fix address-related 404s, locate moved content through current navigation, or report a confirmed broken link. A visitor cannot repair deleted content or a missing server route. Start with checks that preserve the intended destination.
Use this sequence:
- Check the address: Confirm the domain, path, spelling, punctuation, and identifier without changing the intended destination.
- Use current navigation: Search from the site's homepage or follow its menus to find a page with the same purpose.
- Reload once: Repeat the request in case a deployment or cache changed during the original attempt.
- Verify access: Sign in through the site's normal interface when the missing resource belongs to an authorized account area.
- Report the link: Send the broken address, referring page, visible message, and time to the website owner.
A bookmark or search result can preserve an address after content moves. Replace the bookmark only after confirming the new page serves the same purpose.
Avoid guessing unrelated paths on private or restricted services. Report persistent failures when the site's current navigation points directly to the missing address.
Clearing all cookies, changing Domain Name System settings, or restarting a router does not fix an ordinary missing resource. Those actions can remove useful session state or create unrelated problems. Clear a browser cache only when a repaired response appears to remain cached locally.
A private window can test whether local extensions, a service worker, or stored session data changes the result. Compare one controlled attempt rather than repeating requests.
How Do Website Owners Diagnose 404 Errors?
Website owners should reproduce the exact address, capture the first response, and identify the component that generated the reported 404. Preserve the original request before changing routes, redirects, or caches. One altered variable can hide the actual failure.
Follow this diagnostic sequence:
- Record the request: Save the scheme, hostname, port, path, query, method, time, referrer, and affected user context.
- Capture the first response: Disable automatic redirects, then retain the status, response fields, and a sanitized body sample.
- Identify the responder: Correlate edge, gateway, web server, application, and content management system logs by time or request identifier.
- Compare deployment state: Check the live route map, published content, asset manifest, rewrite rules, and release version.
- Test one change: Keep every other request property constant while changing one suspected cause.
- Validate the repair: Repeat the original request, then confirm the expected status, content, links, and cache behavior.
This Bash command performs a normal GET and stores the response fields separately:
`--disable` must appear first, and it prevents cURL from loading its default configuration file. `--dump-header` writes received fields, while `--output` discards the body.
The official cURL manual documents each option and the `--write-out` variables. Do not add `--location` during the baseline because it would follow redirects.
The effective address should therefore match the requested address. Use cURL response headers to inspect the status, `Location`, caching fields, and intermediary clues.
Avoid `-I` unless the failing request actually uses HEAD. That option changes the method instead of merely hiding the body.
Review sending request headers with cURL before reproducing authenticated requests. Redact all secrets from retained diagnostics before storing or sharing them.
How Do You Fix 404 Errors on a Website?
Website owners fix 404 errors by choosing restoration, link repair, redirection, or intentional removal for each missing address. The correct action depends on whether the requested content should exist. Do not redirect every unknown address to the homepage.
| Situation | Correct action | Validation |
|---|---|---|
| Content should still exist | Restore it at the intended address | The original request returns the intended representation |
| Internal link contains a mistake | Correct the source link | The source now points directly to a working address |
| Content moved permanently | Return 301 to the closest relevant replacement | The old address redirects once to matching content |
| Application route is missing | Register or repair the exact route | The intended method and path return the expected result |
| Deployment omitted a file | Publish the missing asset or correct its reference | The release manifest and live response agree |
| Content was intentionally removed | Keep 404, or use 410 for likely permanent removal | The custom page retains the intended status |
Redirects should preserve user intent. A category page can replace a retired item only when it genuinely satisfies the same need.
Irrelevant redirects obscure broken links and can be classified as soft 404s. Update internal links, navigation, sitemaps, canonical references, and application routes after choosing the destination.
Ask referring publishers to correct important external links when they allow such changes. Keep a useful custom 404 page for addresses without a relevant replacement.
What Should WordPress Owners Check?
WordPress owners should confirm the post exists and compare its published permalink with the requested address. If only friendly permalinks fail on Apache, inspect rewrite handling with the hosting provider.
Avoid changing server configuration without a backup, appropriate permissions, and a tested rollback plan. The official WordPress troubleshooting documentation identifies inactive Apache `mod_rewrite` as one possible Pretty Permalink cause.
The `mod_rewrite` explanation does not apply to every host or web server. Compare WordPress settings, server rules, and the live environment before changing anything.
After any repair, test an intended page and a deliberately invalid address. The intended page should return its expected status and content. The invalid address should return a genuine 404 response.
What Is a Soft 404, and How Do You Fix It?
A soft 404 shows missing, empty, or error-like content while returning success or an irrelevant redirect instead of 404. “Soft 404” is a search-engine classification, not an HTTP status.
The server may return 200, 301, or another misleading status. Google Search Central's crawl-error documentation describes a common case as an error page returning 200.
Empty pages, broken database connections, missing server-side includes, or unloaded JavaScript files can create similar signals. Google may exclude detected soft 404 pages from search results.
Google Search Console reports detected soft 404s within its Page indexing report. Use the inspection tool in Google Search Console to compare the rendered page and returned status after each repair.
Fix the response according to the content's intended state. Return 404 when no replacement exists, or use 410 when removal is likely permanent. Return 301 when the requested content has moved permanently to a page satisfying the same need.
Restore substantive content when the page should exist. Then confirm that required scripts, data calls, server-side includes, and database results load for ordinary users and search crawlers. A successful status cannot compensate for an empty rendered page.
Test the raw status and the rendered result because either layer can mislead. A custom error page may look polished while correctly returning 404. Conversely, visible “not found” text can sit inside an incorrect 200 response.
Test missing, moved, and restored addresses after changing routing, rendering, or redirect behavior. Each case should return its intended status, destination, and content.
Do 404 Errors Hurt Search Engine Optimization (SEO)?
Valid 404 responses do not create a site-wide Google penalty, but broken internal paths can waste visits and obstruct discovery. Missing pages cannot provide useful destinations in search results. The practical effect on SEO depends on which address failed and why.
Google's guidance about 404 errors and rankings says some missing addresses do not affect rankings for other working pages. Proper 404 and 410 responses are normal for content without replacements. Owners should still repair valuable missing pages, broken links, and accidental failures.
A deleted page can lose its search visibility because its content no longer exists at that address. That outcome differs from a site-wide ranking penalty.
Restore the page when it should exist. Redirect it only when another address meets the same search need. Broken internal links create dead ends for visitors and crawlers.
Broken links can also hide content that remains available elsewhere. Update each link at its source whenever the correct address is known.
Keep custom 404 pages helpful but technically accurate. Include clear missing-page language, normal navigation, relevant links, and a reporting method. Do not return 200 merely because the error page includes helpful navigation or branded content.
Prioritize 404 repairs by business value, internal-link frequency, traffic, backlinks, and whether the requested content should exist. Give isolated malformed paths lower priority when they correctly return 404 and serve no user need. Continue monitoring for patterns that reveal a template, deployment, or routing defect.
How Should You Handle 404 Errors at Scale?
Large websites should group 404s by normalized path, source, responder, release, and intended content state before assigning repairs. Raw counts alone mix harmless probes with costly failures. Classification turns repeated addresses into a repair queue.
| Control | Recommended behavior | Reason |
|---|---|---|
| Collection | Combine server logs, crawler results, analytics, and search reports | Combining sources covers more failure types |
| Normalization | Remove sensitive values and group equivalent path patterns | One defect can produce many unique addresses |
| Prioritization | Rank by traffic, internal links, backlinks, conversions, and content intent | High-impact failures receive attention first |
| Ownership | Route content, application, deployment, and redirect defects separately | Each failure reaches the team that can repair it |
| Validation | Retest the original address and a known invalid control | Repairs should not break genuine 404 behavior |
| Alerting | Compare rates with releases and historical baselines | Sudden changes can reveal deployment regressions |
Bound concurrency by host, and avoid retrying stable 404 responses automatically. Waiting longer does not restore a missing route.
Recheck after a relevant content, configuration, cache, or deployment change, or after a defined review interval. Record the responder, referring page, route template, and release version without retaining private query values.
Deduplicate failures before queueing repairs. Keep separate classes for missing pages, missing assets, soft 404s, and deliberate removals.
Reliable web scraping with proxies still requires response validation, target-specific pacing, and bounded retries. Treat 404 as data, not merely a failed transfer. A successful connection can deliver a valid 404, a soft 404, or the intended representation.
Test a small sample after repairs, then expand validation across affected templates and locations. Compare status, effective address, selected content markers, and redirect count. Alert only when a metric crosses a meaningful threshold or an important route fails.
How Can Proxidize Help Test 404 Responses?
Proxidize can compare 404 behavior across network routes, but it cannot restore content or correct a server configuration. First confirm that the address and method match the intended request. Then vary only the route when geography or network context could change the response.
A website may serve location-specific catalogs or pages. Its edge configuration may also vary by region. A controlled proxy matrix can reveal whether the same request returns 404 through one region but succeeds through another.
Using cURL with a proxy explains how to keep the target address unchanged while changing the network route. Sticky sessions help repeated checks retain one eligible exit during a comparison.
Rotating sessions let separate requests use eligible exits from the pool. Targeting and session mode are separate controls, so record both with each response.
Proxidize Residential Proxies provide country, city, and Internet service provider targeting with rotating or sticky sessions. Residential Proxies fit global checks where content availability or routing may differ by market. Proxidize Mobile Proxies provide city-level targeting across mobile-network routes, with rotating or sticky sessions.
Best For: Residential Proxies suit global, location-specific checks across residential routes.
Best For: Mobile Proxies suit tests that specifically require a mobile-network route.
Keep the address, method, headers, cookies, timing, and validation rule constant during each comparison. A changed result shows correlation with the tested route, not proof of the underlying cause. Confirm the responding layer through logs before changing production behavior.
Proxies do not override access rules, repair links, or make unauthorized testing acceptable. Follow applicable laws, website terms, and target-specific limits. Stop when the target does not permit the requested access.
What Should You Remember About 404 Errors?
HTTP 404 describes a target without a current representation or one whose existence the origin server is unwilling to disclose. The intended content state determines the correct repair. That decision separates restoration, redirection, and intentional removal.
- Verify the status: A visible error message does not prove that the server returned 404.
- Preserve the request: Capture the exact address, method, first response, and responding layer before changing anything.
- Repair the cause: Restore content, correct the link or route, or publish an omitted asset when it should exist.
- Redirect selectively: Use 301 only when another page genuinely meets the same user need.
- Represent removal accurately: Keep 404 when permanence is unknown, or use 410 when removal is likely permanent.
- Validate every change: Test both repaired addresses and deliberately invalid controls across the relevant environments.
Frequently asked questions
A 404 error means the origin found no current representation for the requested resource. The origin may also conceal an existing resource with a 404 response. The response alone does not establish whether the resource exists or whether its absence is temporary or permanent.
HTTP classifies 404 within the 4xx client-error family, but a human visitor may not have caused it. A broken server route, deleted file, or deployment error can produce the same status. Diagnose the requested address and responding layer before assigning responsibility.
A 404 error has no fixed duration because the status does not label the condition as temporary or permanent. It remains until the address, resource, routing, or response behavior changes. Website owners should use 410 when they know the condition is likely permanent.
Use 404 when no current representation exists and permanence is unknown. Use 410 when the resource is unavailable and that condition is likely permanent. The 410 status gives clients and automated crawlers a clearer signal about the expected duration of the removal.
Do not automatically redirect every 404 to the homepage. Redirect only when another page genuinely satisfies the same user need. Otherwise, keep an accurate 404 or 410; irrelevant redirects hide broken links, confuse visitors, and can create soft 404 signals.
Fix a soft 404 by aligning the returned status with the content. Return 404 when permanence is unknown, or use 410 for likely permanent removal. Restore meaningful content when the page should exist, or use 301 when that content has moved to a relevant replacement.
A proxy cannot recreate a missing resource, repair a broken route, or change the origin's intended status. A controlled proxy test can compare responses across locations or network types. Keep the address, method, headers, cookies, validation rule, and timing consistent while changing only the proxy route.