Understand HTTP errors, redirects, and soft 404 checks
Learn how availability gates and HTML soft-error detection work.
Last checked 20 August 2026
TechDash checks the exact monitored URL before it runs browser and content checks. The HTTP error and redirect gates always run and cannot be disabled for an individual page. They use the first response rather than silently following a redirect, so a changed URL does not hide behind a successful destination.
HTTP errors
HTTP errors on monitored pages is Critical when a fetch fails or the first hop is not successful. TechDash treats HTTP 200-299 and 304 as successful. A 3xx is handled by the redirect check instead.
The evidence includes the expected successful range and the actual status, including status 0 for a fetch failure. Because there is no trustworthy page to render after a hard failure, TechDash skips later browser and content rules for that run. This prevents secondary incidents such as missing titles or schema from being created from an error page.
This is an absolute-state check. It can matter on the first observation, unlike checks that need a before-and-after baseline. Investigate hosting and CDN health, recent deployments, DNS, TLS, authentication, and firewall rules. Confirm the same URL from another network if the failure might be local. Restore a successful response, then use Check & Verify.
Redirects
Monitored URL returns a redirect is Warning when the exact URL returns 3xx. Evidence shows the requested URL, status, and resolved Location destination. Remaining checks are skipped because TechDash monitors the entered URL rather than deciding that its destination is equivalent.
If the redirect is an intentional same-host move, the incident may offer Update Monitored URL. That action rechecks the destination before replacing the stored monitored path and closing the issue. Use it only when the destination is the permanent page you now want to monitor. If the source URL should still serve content, fix the redirect instead.
The first website setup has a special normalization rule. A small number of same-site redirects, such as example.com to www.example.com, can update the stored origin and monitored homepage before a redirect baseline exists. Later redirects are reported normally. External destinations, redirect loops, missing Location headers, and unsuitable paths are not adopted automatically.
Soft 404s
Soft 404 suspected is Warning for an HTML page that returns success but looks like a missing or empty page. The current check fails when either:
- The title contains a 404 or not-found phrase, including "page does not exist"
- The rendered page contains more than zero but fewer than 40 words of page copy
The evidence shows the HTTP status, title, and rendered word count. This is intentionally a broad heuristic. A legitimate short landing page can trigger it, while a verbose custom error template can evade it. Treat the result as a prompt to inspect the page, not proof of Google's classification.
Non-HTML responses are excluded. XML sitemaps, robots.txt, feeds, PDFs, and other resources do not receive this HTML soft 404 test. A completely empty extraction does not satisfy the thin-content condition by itself, although other checks may identify the underlying rendering or availability problem.
For removed content with no useful replacement, return a real 404 or 410. For an active page, restore meaningful visible content and a specific title. If the URL was intentionally redirected, monitor the preferred destination instead.
Troubleshooting unexpected results
Open the incident and verify the response status, content type, title, word count, and destination. If a browser appears healthy but TechDash reports an error, check whether a WAF, CDN, consent layer, or Basic Authentication rule treats the configured user agent differently. A separate Crawler newly blocked or challenged incident can explain why browser-derived checks were suppressed.
If the soft 404 is a valid short page, consider whether monitoring that URL provides useful SEO evidence. You can disable the optional soft 404 check for that page, but the HTTP error and redirect gates remain enabled. Do not suppress a repeated finding until you have confirmed that the live response and search intent are deliberate.