Fix · Readable content

The content only appears after JavaScript runs

In your browser the page is full. The first thing a crawler receives is a near-empty shell that fills itself in later, by running scripts. Some crawlers wait for that. Most fetchers do not.

What we found

Little readable content in the initial HTML — the homepage as served, before any script runs, carries only a few visible words. The finding names the word count it saw. Evidence EV-002

Why it matters

Google documents that it does render JavaScript: pages that answer 200 go into a render queue, a headless browser runs the scripts, and "Google also uses the rendered HTML to index the page". The queue is not instant, and rendering can lag crawling by anything from seconds to much longer.

The fetchers behind AI answers are a different case. OpenAI, Anthropic and Perplexity publish what their crawlers are for and how to allow them; none documents that its fetcher executes JavaScript. Until one does, the safe assumption is that an assistant sees exactly what arrives in the first response. If that is a shell, there is nothing to quote.

First, see what actually arrives

  1. Open the page, disable JavaScript, reload. In Chrome: DevTools, the three-dot menu, More tools, Rendering, tick "Disable JavaScript". Or view the source with Ctrl+U (Cmd+U on a Mac). What you now see is what a non-rendering fetcher sees.
  2. Or fetch it from the command line:
    curl -sL https://yourbusiness.co.uk/ | sed 's/<[^>]*>//g' | wc -w
    A homepage that reads as a few dozen words here, and hundreds in the browser, has this problem.

The repair: three routes, pick the one your platform allows

  1. Server-side rendering or static generation. The framework renders the HTML on the server (or at build time) and sends the finished page. Next.js, Nuxt, SvelteKit, Astro and most modern frameworks support this as a setting, not a rewrite. This is the complete fix.
  2. Prerendering. A build step renders each page once into static HTML that is served to everyone, with the scripts still attached for interaction. Good for brochure sites on a JavaScript framework.
  3. Put the facts in the HTML anyway. If neither route is available this month, make sure the business name, what you do, where you are, opening hours and prices are in plain HTML in the served page, even if the rest still loads by script. Templates on Wix, Squarespace and Shopify already do this for their own content; the problem is usually a widget or a headless build.

Before and after

Now

<body>
  <div id="root"></div>
  <script src="/assets/app.f30ab93c62.js"></script>
</body>
<!-- 0 visible words -->

After

<body>
  <h1>Jersey ice cream, made on the
  farm near Penrith</h1>
  <p>Open daily 11am to 5pm, four
  miles south of Penrith…</p>
  <div id="root">…rendered…</div>
  <script src="/assets/app.f30ab93c62.js" defer></script>
</body>

Client-side rendering is not wrong for an app behind a login. It is wrong for the page that has to tell a stranger, or a machine, who you are.

Prove it worked. Fetch the page with JavaScript disabled, or with curl, and read it. The business name, what you do and the first answer a customer needs must all be there. Then run the free check again: the foundation "Content is readable without running JavaScript" should pass and quote a word count in the hundreds.

What it will not do

Google was probably already rendering your page, so this change may not move Google results at all. What it changes is what every other fetcher sees, and how quickly a change to your page is picked up. Rendering is a queue; served HTML is immediate.

Sources: Google Search Central, "Understand JavaScript SEO basics" (render queue; rendered HTML used for indexing). OpenAI, Anthropic and Perplexity crawler documentation, read 22 September 2026: no statement on JavaScript execution.