HTTP 410 Gone: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, crawler, monitoring tool or uptime checker reports 410 Gone.
• The response may affect one URL, path pattern, HTTP method or API version rather than the entire website.
• DNS can still resolve and TLS can still succeed because the request reached an HTTP endpoint.
• Response headers may reveal caching behavior, a redirect target, authentication context, proxy or CDN information, or the server that handled the request.
• Repeating the request usually returns the same result when the resource has intentionally been removed.

Root causes, ordered by likelihood

Most likely causes

1. Intentional resource removal or deprecation — The owner permanently removed a page, file, API endpoint or version and configured the old address to return 410.
2. Application or routing rule — The application maps a retired route, deleted record or unsupported API version to 410.
3. Web-server rewrite or virtual-host configuration — A route rule, deployment change or incorrect site configuration returns 410 for a URL that should still work.
4. Reverse proxy or CDN behavior — An intermediary may have cached or generated the response based on its routing, cache or edge configuration.
5. Request mismatch — The URL may be valid for one method or path form but removed or unsupported for the method being used.
6. Custom security or request-handling logic — A WAF, gateway or application policy may deliberately use 410, although authentication, authorization and rate-limit problems often use other status codes instead.

The status code alone cannot identify which component produced the response. Response headers, timestamps and logs are needed to distinguish an intended removal from an accidental rule or stale intermediary response.

How to fix it

If you are visiting the site

1. Check the address carefully, including the hostname, path, spelling, capitalization and any version segment.
2. Retry the exact URL once without repeatedly refreshing it. If the page requires an account, sign in through the site’s normal process and retry.
3. If you reached the URL from an old bookmark, search result or external link, look for the site’s current navigation or an announced replacement. Do not assume that a 410 has an equivalent destination.
4. If the response remains and the resource should still exist, send the site owner the URL, request time, HTTP method and the displayed 410 result. Do not send passwords, cookies or access tokens.

If you own or develop the site

1. Reproduce the exact request. Record the URL, HTTP method, host, query parameters, status, response headers and whether the request was authenticated. Compare the failing request with a known-good related route or method.
2. Decide whether the 410 is intentional. Confirm whether the page, file, record or API version was deliberately removed. If it was, document the removal and keep the response unless a suitable replacement is required.
3. Identify the response-producing layer. Check whether the headers and request path indicate the application, web server, reverse proxy, CDN or WAF generated the response. Review each layer in the request path rather than changing all of them at once.
4. Inspect matching logs. Search the relevant access, application, proxy, CDN or security logs using the timestamp, route and request identifier. Look for a removal rule, deleted record, rewrite, deployment change or cached response.
5. Check recent changes and cache state. Compare routing, API versioning, authentication, rewrite and edge-cache configuration with the last known-good deployment. If an intermediary cached an incorrect response, follow its documented, authorized cache-invalidation process rather than broadly disabling caching.
6. Apply the narrowest authorized correction. Restore the route or remove the erroneous rule only when the resource is supposed to be available. If an equivalent replacement exists, configure and test a deliberate redirect; do not redirect unrelated or missing URLs merely to hide the 410.
7. Retest the same request. Verify the status, headers and response body from the relevant client and, where applicable, from the affected network or edge location. Confirm that intentionally removed routes still behave as documented and that related routes retain their intended statuses.
8. Review monitoring and documentation. Update route inventories, API deprecation notices, redirects and tests so a future release does not accidentally remove an active resource.

Prevention & how to verify the fix

• Maintain an inventory of important web routes, files and API versions, including their intended removal behavior.
• Treat intentional removals as release changes: document them, test them and identify any approved replacement URL.
• Keep application, web-server, proxy, CDN and WAF configuration version controlled and review route changes before deployment.
• Test important URLs and API methods after releases, migrations and deprecations.
• Monitor HTTP status rates by route, method and deployment so unexpected 410 responses are distinguishable from planned removals.
• Retain access and application logs long enough to correlate a response with the responsible layer.
• Define cache invalidation and rollback procedures for accidental edge or proxy responses.

Frequently asked questions