---
title: "Server rendering is not a status code — gCurv Technologies"
description: "A server-rendered page can still return 200 for a URL that does not exist. These are separate layers, and conflating them is common."
lang: en
json-ld: |
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Server rendering is not a status code",
    "description": "A server-rendered page can still return 200 for a URL that does not exist. These are separate layers, and conflating them is common.",
    "datePublished": "2026-08-24",
    "dateModified": "2026-08-24",
    "url": "https://gcurv.com/notes/server-rendering-is-not-a-status-code",
    "author": {
      "@type": "Organization",
      "name": "gCurv Technologies",
      "url": "https://gcurv.com"
    },
    "publisher": {
      "@type": "Organization",
      "name": "gCurv Technologies",
      "url": "https://gcurv.com"
    }
  }
---

[![gCurv logo](/assets/gcurv-logo-CJpRRXOD.png)gCurv ](/)

[Work](/work)[Capabilities](/capabilities)[Products](/products)[Notes](/notes)[About](/about)

[Contact us](/contact)

Engineering note 

# Server rendering is not a status code

2026-08-24

A site can be fully server-rendered and still be broken in a way that server rendering does not fix.

We found this on a site where every unknown URL returned a complete, valid page with a 200 status. Requesting a path that had never existed returned a byte-identical copy of the homepage: full HTML, correct canonical tag, robots: index, follow, and fifty-seven working relative links in the body.

The instinct is to reach for rendering. It is the wrong layer. Rendering governs what is inside a response. The status code governs what the response is. A hosting fallback that serves index.html for anything unmatched will happily serve beautifully server-rendered HTML with a 200 attached, and no amount of prerendering changes that.

The consequence is not cosmetic. A crawler that receives 200 treats the URL as a real page and follows every link in it. Ours had already manufactured deeper paths from links found on URLs that did not exist, each one also returning 200. The error surface grows on its own.

## What it looks like

Request a path you are certain has never existed. Check three things: the status code, the byte size against your homepage, and whether the canonical tag points at the requested URL or at /. If the size matches your homepage and the canonical points home, you have a soft 404 regardless of how good the rendering is.

## The fix

A real not-found signal from the router rather than a fallback at the host. In TanStack Start that is throw notFound() from the route loader when the record does not resolve, which produces an actual 404. Worth checking every dynamic segment separately: we found a site where top-level 404s worked correctly and only the blog slug route still returned 200, because the not-found case there rendered an "Article Not Found" component instead of throwing.

That last variant is the one that survives review, because the page says not found. Only the status code disagrees.

[← All notes](/notes)

![gCurv logo](/assets/gcurv-logo-CJpRRXOD.png)gCurv 

A full live website with homepage, platform narrative, product modules, services, pricing, and an editorial blog.

[Email our team](/contact)

### Platform

-   [Overview](/platform)
-   [Products](/products)
-   [Pricing](/pricing)

### Solutions

-   [Services](/services)
-   [Industries](/platform)
-   [Blog](/blog)

### Company

-   [About us](/about)
-   [Contact us](/contact)

© 2026 gCurv. All rights reserved. [Back to top ↑](#top)