What Are HTTP Error Responses? Types, SEO Impact, and How to Fix Them

Quick answer

An HTTP error response is a server response that tells a browser or crawler a request could not be completed normally. The most relevant SEO errors are usually 4xx responses, such as 404 Not Found, and 5xx responses, such as 500 Internal Server Error. A single intentional 404 is not automatically an SEO problem, but broken internal links, unexpected errors, and repeated server failures can prevent search engines from retrieving or understanding content.

What the issue means

Every web request returns an HTTP status code. Successful pages normally return a 2xx response, such as 200 OK. Redirects use 3xx responses, while 4xx responses indicate a problem with the request or requested resource and 5xx responses indicate that the server failed to fulfil an otherwise valid request.

Common codes include:

• 301 or 308: permanent redirect to another URL.
• 302 or 307: temporary redirect.
• 400: the request was malformed.
• 401: authentication is required.
• 403: the server understood the request but refuses access.
• 404: the requested resource was not found.
• 410: the resource was intentionally removed and is gone.
• 429: too many requests were sent in a period of time.
• 500: an unspecified server-side application error.
• 502: a gateway received an invalid upstream response.
• 503: the service is temporarily unavailable.
• 504: a gateway timed out waiting for an upstream service.

When NOTABIS reports an HTTP error response, it has measured an error status for the final response to a crawled URL. The report may also show the requested URL, final URL, redirect chain, response status, response time, and page-level evidence. A broken internal link is related but distinct: it describes a link from one crawled page whose target returned an error.

Why it matters for SEO

Search engines need to retrieve a URL before they can evaluate its content. An unexpected 4xx means the requested document was not available, and an unexpected 5xx means the server failed while handling the request. If an important indexable page repeatedly returns an error, crawlers cannot reliably access its content and users may encounter a broken experience.

The context matters:

• A link to a missing page creates a poor user path and is usually worth repairing or removing.
• A removed page may correctly return 404 or 410; that is not automatically a defect.
• A private account route may correctly return 401 or 403.
• A temporary maintenance response such as 503 may be appropriate when the service is genuinely unavailable and is removed when the work is complete.
• A 429 can indicate rate limiting rather than a broken page, but it can prevent a crawler from completing its work.

Fixing an error does not guarantee higher rankings. The right outcome may be restoring the page, redirecting it to a genuinely relevant replacement, removing stale internal links, or leaving an intentional error response in place.

How NOTABIS detects it

NOTABIS requests URLs discovered from the submitted site, its crawlable links, and applicable sitemap sources. It records the HTTP status and follows permitted redirects according to the crawler’s behaviour. A final response in the HTTP error range can produce the http-error finding. If an internal link points to that URL, the audit can also record a broken-internal-link finding.

The rule is page-scoped and is based on the response observed during the crawl. It does not prove that every request from every location, user agent, session, or time will receive the same response. Authentication, rate limiting, edge controls, transient outages, and request-specific application behaviour can change the result. Check the requested status and final status separately when redirects are involved.

How to check it yourself

1. Open the URL in a browser and inspect the Network panel in Developer Tools.
2. Look at the document request’s status code and whether it redirected.
3. Check the final URL, response headers, and response body.
4. Repeat the request without following redirects:

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

5. Follow redirects while retaining the final URL and response details:

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

6. If the URL is linked internally, search the source HTML, templates, CMS content, navigation, and sitemap for references to it.
7. Compare a failing request with server logs, application logs, deployment history, and any CDN or reverse-proxy logs.

Do not rely only on the page text. A custom “Not found” message can still be served with HTTP 200, which is a different problem from a real 404 and may need separate soft-404 investigation.

How to fix it

Start by deciding what the URL should do:

• The page should exist: restore the route, content, controller, file, or upstream service and confirm it returns 200.
• The page moved permanently: return one direct 301 or 308 redirect to the closest relevant replacement, update internal links, and avoid redirect chains.
• The content is gone with no replacement: remove stale internal links and let the URL return 404 or 410 as appropriate.
• The page is private: preserve the intended authentication or authorization response and do not expose private content merely to satisfy a crawler.
• The outage is temporary: repair the underlying service and use 503 only while the service is genuinely unavailable.

After changing the site, request the URL again, inspect the status and headers, test the important internal links, and rerun the audit. Search engines may need time to recrawl the URL and update their index.

Common mistakes include redirecting every error to the homepage, returning 200 for missing content, redirecting to an unrelated page, fixing the target but leaving broken internal links, and hiding an application error behind a generic success response.

Examples

A genuine missing page:

GET /old-guide HTTP/1.1
Host: example.com

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8

This is appropriate when /old-guide has no replacement. Remove links that still send users there.

A moved page:

GET /old-guide HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-guide

The destination should be closely related and should return a successful response. Link directly to /new-guide wherever possible.

An application failure:

GET /pricing HTTP/1.1

HTTP/1.1 500 Internal Server Error

This usually requires investigation in the application and server logs. Do not replace the response with 200 OK merely to make a crawler report success.

When this is intentional or does not need fixing

An HTTP error does not always represent a defect. A 404 is correct for a URL that was never created or has been removed without a suitable replacement. A 410 can communicate deliberate permanent removal. 401 and 403 are often required for account pages, private files, administrative tools, and protected APIs.

A temporary 503 can be correct during planned maintenance if the service recovers promptly. A 429 can be an intentional protection against abusive or excessive requests, although the limit should not unintentionally prevent legitimate crawling.

The question is not “How do I remove every error?” It is “Does this URL have a public purpose, and is the response consistent with that purpose?”

Related issues

Related NOTABIS Learn guides will be linked here as they are published. The closest planned topics are broken internal links, redirected URLs, redirect chains, and 404 versus 410 responses.

Run a NOTABIS audit

Not sure whether your site contains broken URLs or unexpected HTTP errors? Run a NOTABIS SEO audit to crawl your site and identify affected pages, response statuses, redirects, and related link evidence.