Your site loads fine. View Source shows an empty page.

For a while, the page you are reading this on had a real defect, and it was ours. The homepage, terms and privacy pages shipped as Design Components bundles. What actually arrived in the browser was a loading shell plus a large base64 payload inside a script tag. JavaScript decoded the payload and wrote the page into the DOM.

In a browser it looked perfect. Headlines, sections, meta tags, all present after a few hundred milliseconds. But the HTML we served contained no headline, no body copy, and no readable og: tags. Every word of the site lived inside a string that only a JavaScript engine could open.

How to check your own site in two minutes

The trap is that Inspect Element lies to you for this purpose. Inspect shows the DOM after JavaScript has run, which is exactly the thing you are trying to test around. You need the bytes the server sent, before any script executed. Four checks, none of them requiring a developer:

• Use View Source, not Inspect. In Chrome and Firefox, view-source: followed by your URL. Then search for your own headline text. If it is not there, it does not exist as far as a plain HTTP client is concerned.
• Turn JavaScript off in your browser settings and reload. A content site should still be readable. A dashboard app does not have to be, but your marketing pages do.
• Paste your URL into a WhatsApp chat with yourself, and into a Slack or LinkedIn message box. If the preview card is blank or shows only the domain, your og: tags are not in the served HTML.
• Run curl against the URL from a terminal and pipe it to a word count. A homepage that returns two kilobytes of shell is a homepage with no content in it.

Why this fails quietly instead of loudly

No error appears anywhere. Your team sees the site, your client sees the site, uptime monitoring returns 200. Search engines do render JavaScript in many cases, so traffic may not collapse in a way that makes anyone investigate. The damage is uneven and hard to attribute, which is the worst kind.

The part that fails immediately is link previews. The scrapers behind chat apps and social networks fetch your HTML once and read the meta tags out of it. Most do not run your JavaScript and will not wait around for it. If your title and description are inside a base64 payload, every link anyone shares of your work arrives as a bare grey rectangle. For a studio that gets found through referrals and shared links, that is not a cosmetic issue.

What correct looks like

WITHOUT

• Loading shell + base64 payload
• Text written by JavaScript
• og: tags inside a string
• Source of truth in the build artifact

WITH

• Static HTML served whole
• Headlines in the source
• og: tags in the served HTML
• Editable templates in src

The three bundled pages are now fully static HTML. Every headline, paragraph and meta tag is in the source. JavaScript still runs, but only to enhance: animation, small interactions, nothing that content depends on. The editable source lives in src as template files, and tools/prerender.py writes out the finished HTML. Editing is one command, and the deployed artifact has no build step and no dependencies.

We kept the old bundle tool, tools/dc-bundle.py, out of the build but in the repository. It can still extract a template out of an old bundle pulled from git history, which is how the src folder was recovered in the first place. That is worth saying plainly: our source of truth had been encoded inside a build artifact, and getting it back required writing a decoder. If your content only exists inside a compiled blob, you do not have content, you have a hostage.

If you are hiring someone to build a site, this is a question you can ask without knowing how to code. Ask whether the page text is in the HTML the server sends, or assembled by JavaScript in the browser. Both approaches are legitimate for interactive systems where a user is already logged in. For anything you want found, quoted or shared, only one of them works.