Web & development / CLEARBYTE

HTTP status codes for website checks and integrations

The status code describes the result of an HTTP request. A friendly error page that returns 200 is different from a real 404. Read the code, method and response headers together when testing a website or API.

HTTP status codes for website checks and integrations

The status code describes the result of an HTTP request. A friendly error page that returns 200 is different from a real 404. Read the code, method and response headers together when testing a website or API.
CodeMeaningPractical interpretation
200OKRequest succeeded; interpret the body according to the request method.
201CreatedRequest created one or more resources.
204No ContentSuccessful request with no response content.
301Moved PermanentlyResource has a permanent new URI; some clients may change POST to GET.
302FoundTemporary redirect; some clients may change POST to GET.
307Temporary RedirectTemporary redirect that preserves the request method.
308Permanent RedirectPermanent redirect that preserves the request method.
304Not ModifiedConditional GET or HEAD can reuse its stored representation.
400Bad RequestServer cannot or will not process the request because of a perceived client error.
401UnauthorizedValid authentication credentials are required.
403ForbiddenServer understands the request but refuses it.
404Not FoundNo current representation was found, or the server will not disclose one.
405Method Not AllowedThe method is known but is not supported for this target resource.
410GoneAccess is no longer available and the condition is likely permanent.
429Too Many RequestsRequest rate is limited; Retry-After may be supplied.
500Internal Server ErrorUnexpected server condition prevented fulfillment.
502Bad GatewayA gateway received an invalid upstream response.
503Service UnavailableServer is temporarily unable to handle the request.
504Gateway TimeoutA gateway did not receive an upstream response in time.
Download this reference as CSV ↓

Formula & method

Inspect the status before parsing a response as the expected document or JSON payload. Follow a redirect intentionally and record its chain when verifying canonical URLs. For a deleted page, check both the visible message and the actual HTTP status.

Authentication, rate limits and temporary failures require different handling. A 429 or 503 may provide Retry-After; respect it rather than retrying rapidly. Applications can still report a business-level failure inside a 200 response, so the status alone does not validate the entire operation.

Worked example

If an unknown URL shows “Page not found” but responds with 200, the visible copy and protocol result disagree. A custom error design can still return the correct 404 status.

What can change the answer

This table summarizes selected standard meanings, not every status code or application contract. Do not infer that a 403 or 404 proves a resource never existed.

Sources & definitions

Method checked:

Continue with a related task