HTTP error checker for 4xx and 5xx website responses.

Q: Will the audit start immediately after I enter a URL?

No. The form opens the crawler with the URL prefilled so settings can be reviewed before starting.

Q: Can this be monitored over time?

Yes. Registered users can keep private crawl history and create recurring audits for monitored sites.

Review crawled URLs that return client or server errors and separate expected terminal responses from problems that need attention.

✓Free during beta✓URL-level evidence✓Private history after signup✓Scheduled monitoring

What this check finds

This page focuses on HTTP errors in crawl context. The crawler records the fetched URL, response status, discovery source when available, metadata, redirect outcome, and history signals that explain why a finding appears.

Use the check to review URLs returning 4xx or 5xx status codes. The goal is not just to report a problem, but to show the URL-level evidence needed to decide whether the issue is intentional, accidental, fixed, or still unresolved.

HTTP Error CheckerCompleted

Visited704

Indexable619

Errors20

Warnings8

FindingSeverityEvidence

Client errorsErrorURL, status, and source page

Server errorsErrorStatus code and affected URL

HTTP terminal statusesWarningFinal response after redirects

Why this check matters

Group errors by status

Separate 404, 403, 500, and other terminal responses instead of reviewing a raw URL list.

Use source-page context

Find the page that introduced the URL when the crawler can identify it.

Validate after deployment

Rerun the crawl after route, server, or content changes.

How to fix and verify it

Run a focused crawl. Start with the affected website or section and keep settings consistent for follow-up comparisons.
Inspect the evidence. Review affected URLs, source pages, HTTP statuses, metadata values, and crawl lineage before making changes.
Apply the smallest safe fix. Update the page, template, route, redirect rule, canonical tag, or internal link that caused the finding.
Rerun the audit. Confirm that the finding is resolved and did not create a new issue elsewhere.

When to monitor it

Small technical issues become expensive when they remain invisible. For HTTP errors, a repeatable crawl helps distinguish a one-time anomaly from a persistent problem caused by templates, redirects, routes, metadata, or content changes.

Start with the concrete evidence: affected URL, source page, HTTP status, metadata value, redirect target, or comparison row. After the fix is made, run another crawl with comparable settings to confirm the finding is resolved.

Frequently asked questions

What does this page check?

It checks URLs returning 4xx or 5xx status codes and presents the result as summary counts plus URL-level evidence. That makes the audit useful for deciding what to fix and for verifying the result in a later crawl.

Will the audit start immediately after I enter a URL?

No. The URL is transferred to the crawler seed field so you can review scope, limits, redirects, and sitemap policy before starting.

Can this be monitored over time?

Yes. Registered users can create scheduled audits and review whether findings are new, resolved, or still unresolved across completed crawls.

Is this only for SEO?

No. The same findings are useful for site maintenance, release validation, migration checks, and general quality assurance.

Related audit pages

Run a free audit and review HTTP errors by URL.

Enter a website URL and inspect HTTP errors with URL-level evidence in the live crawler.