Sitearc

Headless CMS sites: where crawlable structure goes missing

The three places a headless build loses structure, and a filled rendered-output check. The slug change that proves the fourth.

Answers
Find the crawlable structure a headless build drops.
Included check
A filled rendered-output check with the finding and the fix
Written for
Developers building on a headless CMS

Where structure is lost

A headless CMS stores structured content. The site then renders it. The loss happens in the render, not in the content.

The three places to look

  1. Metadata. The title comes from a component, not from the entry.
  2. Routing. A slug change in the CMS leaves the old URL returning 404.
  3. Markup. Structured data is written in a template, so every page claims the same thing.

A filled check

Cedar and Slate Interiors, a custom headless build, October 2026.

step 1  fetch the url and read the returned html
        /services/kitchens fetched, 200, 9.4KB before rendering

step 2  title, description and h1 present without javascript
        title present, description present, h1 present

step 3  the canonical is the url requested
        canonical points at the apex host, correct

step 4  rendered section order matches the entry
        two sections swapped: an editor drag did not reach the template

step 5  internal links resolve, not only render
        one link points at a draft slug that returns 200 with an empty page

step 6  one structured data block per entity
        three organisation blocks, one per section component

step 7  change one slug, and confirm the old url redirects
        no redirect existed. The old url returned 404 for 11 days

findings, with the fix
- section order      render from the entry order, not a fixed list
- draft slug linked  unpublish it, or redirect it
- three blocks       emit once, in the layout
- no redirect        add a redirect on slug change, in the webhook that saves

Fetch, do not view

Viewing a page renders it. Fetching it shows what a crawler gets first. Where the two differ, the difference is the finding.

Acceptance: the check is complete when

  • every step has a result from the fetched HTML
  • each finding has a fix and an owner
  • the slug change test was actually performed
  • the fixes are re-checked on the rendered page

Troubleshooting

Symptom Likely cause What to do
Content missing from the fetched HTML Client-side rendering Render on the server, or prerender
Two pages share one title One metadata component for the section Bind the title to the entry
A deleted page still returns 200 A draft was published by route Unpublish the route, then redirect
Every page claims the same entity A template block Emit from the entry
A slug change loses traffic No redirect on save Add it to the save webhook

Limits

A client-rendered site can still be indexed. It is slower and less reliable, and the fix is rendering rather than a tag.

Nothing here replaces the content work. A page that renders perfectly and answers nothing is still a page nobody needs.

Where this came from