Static HTML and the JavaScript problem
A page has two versions: the HTML your server sends, and the page a browser assembles after running your JavaScript. Humans see the second. Many machines only reliably see the first. Content can disappear in the gap between the two.
Who renders, who doesn't
Googlebot renders JavaScript, eventually, at a cost, with failure modes. The newer AI search crawlers are weaker: assume some fetch your raw HTML and stop. Google's own long-standing recommendation covers both worlds: put important content in textual, retrievable form rather than behind interaction or scripts. Official recommendation
The test that settles it
Fetch your page with JavaScript off (curl, or view-source) and ask: is the actual information present in what came back? The services, the prices, the opening hours, the article text? If the answer is a spinner and an empty div, you are publishing to browsers and hiding from crawlers. Common offenders: content loaded from an API after the page arrives, text inside interactive widgets, tabs and accordions that inject content on click, and site builders that ship pages as scripts.
What good looks like
Server-rendered or statically generated pages, where the HTML is the content, scripts enhance rather than construct, and nothing essential waits for interaction. This also loads faster for humans. It is the rare case where the machine's preference and the visitor's coincide.
What bernard does about this
This is the core of what a bernard move is: sites are rebuilt as static, fully rendered HTML. The content is in the bytes the server sends, verified page by page during import. verified