Content that needs JavaScript: who can read it and who cannot

For years the honest advice about client-rendered content was: Google handles it, ship it. Google does handle it, with a second rendering pass, and pages built entirely in the browser rank perfectly well.

What has changed is who else is fetching. A retrieval fetcher answering a user's question right now is optimised for latency, not completeness: it makes a request, takes the bytes, and moves on. Running a headless browser per fetch is expensive and slow, and for most of these agents there is no second pass. Whatever is in the response body is what exists.

So the same page can be entirely visible to search and nearly empty to an assistant.

You do not need a tool for the first pass. curl makes exactly the request a non-rendering fetcher makes, so piping it through a word count answers the question.

# What arrives before any script runs. Send a real
# user agent: some hosts serve a different shell to
# clients they do not recognise.
curl -s -A "Mozilla/5.0 (compatible; check)" \
  https://example.com/page \
  | tr -d '\n' \
  | sed -E 's/<script[^>]*>.*?<\/script>//g; s/<[^>]+>/ /g' \
  | tr -s ' ' \
  | wc -w

# Then look at what is actually there, not just how
# much of it: does your h1 and first paragraph appear?
curl -s https://example.com/page | grep -o '<h1[^>]*>[^<]*'

A page whose article body is two thousand words and whose raw response yields forty is client-rendered content. In the browser, the equivalent check is to disable JavaScript in devtools and reload: what remains is roughly what a non-rendering fetcher gets.

The framing that helps: you do not need to abandon client-side rendering, you need the first response to contain the content. Every fix below is a way of doing that.

Server rendering or static generation. The real answer if it is available to you. In the App Router this is the default and the problem usually comes from opting out of it: a page marked 'use client' at the top of the tree, or content fetched in an effect rather than on the server.

// The version that ships an empty shell: the fetch
// happens in the browser, after the bundle loads.
//
//   'use client'
//   export default function Page({ params }) {
//     const [doc, setDoc] = useState(null)
//     useEffect(() => {
//       fetch(`/api/docs/${params.slug}`)
//         .then(r => r.json()).then(setDoc)
//     }, [params.slug])
//     if (!doc) return <Spinner />
//     return <article>{doc.body}</article>
//   }

// The same page, resolved before the response is sent.
// The HTML that leaves the server contains the text.
export default async function Page({ params }) {
  const doc = await getDoc(params.slug)
  return (
    <article>
      <h1>{doc.title}</h1>
      {doc.body}
    </article>
  )
}

Prerendering at the edge for bots. A middle path when a rewrite is not on the table: serve a rendered snapshot to non-browser clients. It works, and it has a real cost, which is that you now maintain two paths and only one of them is exercised by your team.

A meaningful noscript body. Not a fix, and worth mentioning because people reach for it. A <noscript> block containing the article text does put the content in the response, but maintaining a parallel copy of your content is a guarantee that the two will diverge.

Because it is the one defect in the AI group that removes the content rather than degrading it. A missing llms.txt costs you a signpost. A weak heading outline costs you clean passage boundaries. This costs you the text, and everything else on the list is downstream of there being text.

It is also template-scoped, which is the multiplier the severity scale weighs most heavily: one rendering decision in one layout applies to every page beneath it, and the pages most likely to be affected are the deep content pages that were supposed to earn the citations.

Re-run the same curl, on the same URL, and compare word counts before and after. It is a blunt measure and it is the right one: the number going from forty to two thousand is the fix landing. Then grep the response for a distinctive sentence from the middle of the page rather than trusting the count alone.

Check it again after any change to your data-fetching approach, because this is a defect that gets reintroduced by a refactor rather than by an edit. Moving one fetch into an effect to fix a loading state is enough to empty a template again, and nothing in your test suite will notice.