The page says “not found.”

The page says “not found.” The server says “200 OK.”

A screenshot won’t show you that difference.

I found this while reviewing a Next.js website connected to WordPress. Nonexistent routes displayed the expected error screen but returned a success status. I traced the route behaviour, specified the correction, and verified the responses after the site’s developer changed the implementation.

That’s why I check more than the visible layout on a JavaScript website:

• What happens when someone opens a URL directly? • What changes after navigating through the app? • Do the page content, canonical URL and indexing directives match the intended page? • What does an invalid URL actually return?

There is a wrinkle: Next.js can return 200 for streamed not-found responses. The status, content and indexing directives need to be assessed together. A blanket “every 200 error page is broken” rule would be wrong.

Today’s SSRWire update tightened another part of these checks: it generates body fingerprints only for complete responses. A truncated or failed response should not stand in for a finished page when comparing releases.

SSRWire inspects the HTTP response; browser checks cover rendering and navigation.

This is where my React/Next.js/Nuxt development work connects with technical SEO: making sure a URL delivers the right page and the right search signals, including when something goes wrong.