Quick answer
fetch-failed means NOTABIS could not complete a request for a queued URL after its request attempts ended in an exception. It is different from a received HTTP 4xx or 5xx response, which can produce http-error, and from an edge challenge, which produces edge-blocked. Check network, TLS, DNS, timeouts, and application availability for the exact URL.
What the issue means
A fetch failure occurs before the crawler has a usable response to analyse. Common causes include DNS failure, a refused connection, an invalid certificate, a timeout, an unsafe redirect destination, a response that exceeds configured limits, or repeated transport errors. A server can be healthy for a browser in one location and still fail from another network path.
Why it matters for SEO
Search engines cannot understand or refresh a page they cannot retrieve. Repeated failures on important URLs can reduce crawl coverage and delay updates, while an isolated transient failure may have little lasting effect. The finding is evidence about this audit run and does not prove that every crawler or visitor saw the same failure.
How NOTABIS detects it
For each queued URL, NOTABIS attempts a safe GET request and retries transport or 5xx/429 conditions according to its crawler settings. If the request throws after those attempts, it records fetch-failed at audit scope for that URL and continues with other queue items. A response with status 400 or higher is analysed as a page and can receive http-error; a recognised edge challenge is handled as edge-blocked.
The result depends on the audit’s DNS resolution, timeout, redirect, body-size, safety, and network conditions. It does not identify the root cause by itself.
How to check it yourself
Request the exact URL from more than one network and retain headers:
curl -v -L https://example.com/page -o /dev/null
Check DNS records, certificate chain, redirect destinations, firewall logs, application logs, response time, and rate limits. Compare a successful browser request with a plain GET and inspect whether a CDN or proxy changes the result.
How to fix it
Repair the underlying DNS, TLS, routing, server, proxy, or application failure. Remove redirect loops and invalid destinations, increase resource capacity where a timeout is genuine, and tune rate limits for legitimate crawlers. Do not convert an error into 200 OK with a generic page. Re-request the URL, verify the final HTML or intended status, and rerun the audit.
When this is intentional or does not need fixing
An expired page, private endpoint, deliberately disabled environment, or temporary maintenance window may be unreachable. A protected route should remain protected and be assessed with its intended client. Document intentional exclusions so a transient or private URL is not mistaken for a broken public page.
Related issues
Read edge and bot blocking, no pages crawled, HTTP error responses, and redirect chains.
Run a NOTABIS audit
NOTABIS lists queued URLs that could not be fetched after its request attempts, helping you compare transport evidence with page-level HTTP errors.