HTTP 200 status code

What this check does

Sends a GET request to the audited URL and reads the final HTTP status code. The check passes only on 200 OK. It flags:

• 3xx redirects (the URL isn’t the canonical one)
• 4xx errors (404 page not found, 410 gone, 403 forbidden)
• 5xx errors (server crash, gateway timeout)

The crawler follows up to a small number of redirects so it can also tell you the final status at the end of the chain.

Why it matters

Search engines and AI crawlers treat non-200 responses as “don’t index this URL.”

• 301/302 — the URL won’t rank; the redirect target will. If you’ve shared example.com/old-post and it 301s to example.com/new-post, every backlink, every social share, every featured-snippet selection points at a URL Google will drop from its index within weeks.
• 404 / 410 — the URL is removed from the index. If this happened by accident (typo in a redirect rule, missing trailing slash, deleted page that still has backlinks), you’re losing traffic silently.
• 500 / 502 / 503 / 504 — Google retries, then deindexes after a few days of failures. Worse, Googlebot will reduce crawl budget for the whole domain.

A page that returns anything other than 200 is invisible.

How to fix it

First, see exactly what the server returns. curl -I shows the full chain:

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Add -L and -w "%{http_code} -> %{redirect_url}\n" to map every hop. If you see multiple 30x rows before the final 200, you have a redirect chain — also worth fixing.

If the URL should return 200 but returns 301/302:

Some common culprits:

• WWW or trailing-slash mismatch — example.com/page 301s to example.com/page/. Pick one canonical form (with or without slash) and link to it consistently. Don’t link to the redirecting form internally.
• HTTPS upgrade — http://example.com/page 301s to https://example.com/page. Expected, but make sure all internal links and the sitemap use HTTPS so crawlers never hit the redirect. See Redirect HTTP to HTTPS.
• Locale redirect on the root path — / 302s to /en/ based on Accept-Language. Googlebot crawls from the US with en-US, so / becomes a redirect to /en/. Either make / serve the English content directly (with hreflang for other locales) or use a 302 plus x-default hreflang.

If the URL returns 404 by accident:

• Check the routing config (nginx try_files, Next.js [...slug].tsx, Astro getStaticPaths).
• Check case sensitivity — /About and /about are different URLs on Linux servers.
• Check the database — a CMS page set to “draft” returns 404 in most templates.

If the page is genuinely gone, return 410 Gone instead of 404 — Google deindexes 410s about twice as fast. Set up a custom 404 page so the response is still helpful for humans.

If the URL returns 5xx:

This is a server problem, not a configuration problem. Check the application logs at the timestamp MetricSpot ran the audit. Common causes: database connection pool exhausted, out-of-memory on a serverless function, third-party API the page depends on returned a timeout.

Recipes:

# nginx — explicit 200 for a route, no redirect
location = /pricing {
  try_files /pricing.html =404;
}

// Express — return 410 for permanently removed URLs
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — return 410 from a route segment
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // returns 404 by default
  // ...
}

For Astro static sites, a 410 needs to be served by your host (nginx return 410; or Cloudflare Worker), since Astro’s static output only emits 404s for missing routes.

Frequently asked questions

Is 301 always bad?

No. A 301 is correct when the URL has genuinely moved — old slug to new slug, HTTP to HTTPS, www to non-www. It’s only bad when MetricSpot audits the URL you intend to be canonical and it 301s away — that means you’ve given us (and Google, and every backlink) the wrong URL.

Should I return 200 for missing pages with a “not found” message?

No. Returning 200 with “page not found” body content is called a soft 404. Google detects it (by content pattern) and treats it as 404 anyway, but it confuses analytics and bloats your crawl budget. Always return the correct HTTP status.

What about 304 Not Modified?

304 is a successful conditional response — the browser already has the page cached. It’s not a problem; MetricSpot doesn’t send If-Modified-Since headers so you won’t normally see it in our crawl. If you do, your CDN is being too aggressive about caching responses to unauthenticated GETs.