--- title: What status code does my page return? How to check with the HTTP Status Checker description: Search Console says a page is "Not found (404)", yet it opens fine in your browser. The page you see and the status code the server sends are two separate things. Here's how to check the HTTP status code of any URL from outside your network with the free HTTP Status Checker, how to read the result, and how to fix a page that looks right but answers wrong. canonical: https://watchfor.io/blog/how-to-check-http-status-codes --- # What status code does my page return? How to check with the HTTP Status Checker 2026-10-04 · WatchFor Team · Guides · guides, http, seo Search Console says a page is "Not found (404)", yet it opens fine in your browser. The page you see and the status code the server sends are two separate things. Here's how to check the HTTP status code of any URL from outside your network with the free HTTP Status Checker, how to read the result, and how to fix a page that looks right but answers wrong. To check the HTTP status code of a page, request the URL with a client that shows the response line instead of rendering the page: `200` means found, `301`/`302` a redirect, `404` not found, `5xx` a server error. A browser hides that number, so a page can look perfectly normal and still answer `404`, or show "page not found" while answering `200`. The free [HTTP Status Checker](/http-status-checker) fetches the URL from a WatchFor probe and puts the status code first, with the timing and every response header under it. No signup. ## What this tool answers *What status code does this URL return right now, to someone who isn't me?* Reach for it when Search Console or a crawler reports 404s or "soft 404s" you can't reproduce, after deleting or moving pages, when a monitoring alert says `503` and the site looks fine, or when an API returns errors for some clients. The request comes from a probe with no cookies, no login and no browser cache, which is how Googlebot and new visitors meet your site. ## A real example ### Checking the HTTP status code of a page that looks fine The report usually reads: "Google says this URL is 404, but it opens fine." To show how far the page and the status can drift apart, we used a page that renders as a complete, styled article page: Wikipedia's page for an article that doesn't exist. In the [HTTP Status Checker](/http-status-checker) we entered `https://en.wikipedia.org/wiki/This_page_does_not_exist_xyz`, kept method **GET** and **Follow redirects** on, and pressed **Fetch headers**. The run came from the Vilnius probe: ![The HTTP Status Checker result for https://en.wikipedia.org/wiki/This_page_does_not_exist_xyz: status 404 in red, TTFB 440 ms, transport tcp, DNS 0 ms, connect 30 ms, TLS 37 ms, TTFB 440 ms, security headers 3 of 7, and the first response headers including Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform](/blog/how-to-check-http-status-codes-404.webp) In a browser this URL shows the full Wikipedia layout, search box and "Wikipedia does not have an article with this exact name". To a client that reads the status line it's a **404**, sent with a 51,120-byte page. No redirects; time to first byte **440 ms** (connect 30 ms, TLS 37 ms, the rest waiting for the server). The headers explain the wait: `x-cache: cp3066 miss, cp3066 miss`, `Cache-Control: private, s-maxage=0` and a `Server` name in Wikimedia's Ashburn data centre. The 404 page isn't cached at the edge, so every request is built fresh. **The answer:** what Google sees is the status code, not the page. If a URL like this is one you want indexed, the server is the thing to fix, not the content. The usual culprits: - **Single-page apps** that serve the app shell for known routes but return `404` from the server, then render the page in JavaScript. Make the server (or the hosting rewrite rules) answer `200` for every real route. - **Framework not-found paths** reached by mistake: a data fetch fails during rendering and the framework sends its 404 response (in Next.js, a call to `notFound()`), even though the page template rendered. - **CDN or proxy error pages** replacing an origin error with a styled page that keeps the error status. The opposite case is the **soft 404**: a "page not found" message sent with `200`. Google flags those too. A removed page should answer `404` or `410`. ## How to read the results | What you see | What it means | | --- | --- | | **Status** | The status code of the final response. Green for 2xx, amber for 3xx, red for 4xx and 5xx. With **Follow redirects** on, this is the page the redirects lead to. | | **TTFB chip** | Time from sending the request to the first byte of the response. Green under 50 ms, amber under 200 ms, red above. | | **Redirects chip** | Shown when redirects were followed, with how many. | | **tcp / http3** | The transport used for the request: TCP, or HTTP/3 over QUIC. | | **DNS / connect / TLS / TTFB** | Where the time went. DNS shows 0 ms when the probe's resolver already had the name cached. A slow TTFB with fast connect and TLS means the server or backend is slow, not the network. | | **Security headers (n/7)** | Which of seven common security headers came back; struck through means missing. The [security headers guide](/blog/how-to-check-security-headers) covers them. | | **Header list** | Every response header as sent. Long values (cookies, report URLs) are cut short. | ## More ways to use it - **Is it down for everyone or just me?** If the checker gets `200` from outside and you can't load the page, look at your own network, VPN or DNS cache first. - **After deleting pages.** Confirm removed URLs answer `404` or `410` and not a `200` "not found" page. - **Testing the redirect itself.** Untick **Follow redirects** to see the first response alone: a `301` with its `Location` header, instead of the page it points to. For every hop, use the [Redirect Checker](/redirect-checker). - **Checking a 503 from monitoring.** Many maintenance pages and rate limiters send `503` with a friendly page; the status tells you which one your users got. - **HEAD versus GET.** Switch the method to **HEAD** to see whether a server treats it differently; some answer `405` or a different code to HEAD. ## Tips and gotchas - **One location, no cookies.** Geo-blocking, bot protection or a login wall can return `403`, `429` or a redirect to some clients only. If the result differs from your browser, that's often the reason. - **Bot protection.** CDNs with bot challenges sometimes answer automated clients with `403` or `503` while browsers pass. That's a real answer: it's what crawlers get too. - **A 304 isn't an error.** `304 Not Modified` is a cache confirmation; you only see it when the client sends `If-None-Match` or `If-Modified-Since`. - **The body is not the status.** Never decide from the page text whether a page works. Status codes and what each one means are in [HTTP status codes explained](/blog/http-status-codes-explained). ## Check it from the command line too `curl -w` prints the status code and nothing else: ```bash curl -s -o /dev/null -w '%{http_code} %{size_download} bytes\n' \ https://en.wikipedia.org/wiki/This_page_does_not_exist_xyz ``` ```text 404 51120 bytes ``` Same answer and size as the checker. `-I` shows the status line and headers of a HEAD request: ```bash curl -sI https://en.wikipedia.org/wiki/This_page_does_not_exist_xyz | head -1 ``` ```text HTTP/2 404 ``` For a batch of URLs, loop over a file: `while read u; do printf '%s ' "$u"; curl -s -o /dev/null -w '%{http_code}\n' "$u"; done < urls.txt`. ## Keep watching it A status check is a snapshot. An [HTTP monitor](/http-monitoring) requests the URL on a schedule from several locations, and its **HTTP Status Evaluation** rule opens an incident when the code falls outside the classes you accept (by default `2xx` and `3xx`). Failures are confirmed from other locations before anyone is alerted, so one bad network path doesn't wake you up. Add a **Response Body Match** rule to catch the soft-404 case: a `200` that no longer contains the text the page should have. ## FAQ **How do I check the HTTP status code of a URL?** Use a tool that shows the response instead of the page: the HTTP Status Checker, `curl -I https://example.com`, or the Network tab in your browser's developer tools, which lists the status of every request. **Why does Google say my page is 404 when it loads fine?** Because the server sends `404` while the page still renders, often a single-page app route or a framework not-found response. Check the status from outside your browser; if it's 404, fix the server or rewrite rules so the route answers `200`. **What is a soft 404?** A page that tells visitors it doesn't exist but answers `200 OK`. Search engines treat it as an error page that's pretending to be content. Send a real `404` or `410` for removed pages, or redirect with a `301` when there's a true replacement. --- Canonical page: https://watchfor.io/blog/how-to-check-http-status-codes · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt