Service Manual 01 ... Structural Diagnosis
Under the Hood
Tune it, or replace it. The evidence decides.
Six findings in the registry can come back as structural. Each one means the cause sits above the page, in how the site is built, rendered, or hosted. You can rewrite every word and the finding stays exactly where it was.
Two ways a build goes wrong
Structural findings come in two shapes, and telling them apart matters more than counting them. Both mean the cause sits above the page. Only one of them is worth rebuilding over.
Diagnosis A
The hotrod
Built well. Tuned wrong.
Somebody who knew what they were doing made real decisions here, and then one of them got set badly and nobody went back to it. The engine is fine. The timing is off. The findings cluster in one place, the repair is a configuration change rather than a rewrite, and once it lands the rest of the result usually improves on its own.
The tell: one or two structural findings, concentrated in one group, on a page that otherwise scores well.
Diagnosis B
The Edsel
Built well. Built for the wrong reader.
The Edsel was not a cheap car. Ford spent a fortune on it, it carried real engineering, and it failed anyway because the assumption underneath it about who was going to want it turned out to be wrong. That is the harder version of this problem and the one people argue against hardest, because nothing about it looks like a mistake. Nobody was lazy. The build is competent. It was aimed at a reader who shows up with a browser, runs your scripts, and waits, at a moment when a growing share of the readers that matter do none of those three things.
The tell: three or more structural findings that all trace back to the same decision. Usually rendering.
Most sites are neither. Most sites are a daily driver with a loose belt, which is the quick-fix list and not this page at all.
And the inspection cannot tell you which of the two you are looking at. It counts findings and reports what it observed. Working out whether six findings are six problems or one decision wearing six hats takes somebody looking at the build, and anything that claims to do that from outside a single URL is guessing.
Content is in the HTML, not assembled by script
What it means: the server sent a mostly empty document and a script bundle. The content appears when the browser runs the script. A person sees a full page. A retriever reading the raw response sees a frame.
Why it is structural: the rendering model is a decision made in the codebase. Nothing you do in the content editor changes what the server sends first.
What actually fixes it: server-side rendering, pre-rendering at build time, or a static export. Every major framework supports at least one of these. All three are engineering work.
Body text survives boilerplate stripping
What it means: readable text is a tiny fraction of the response by size. The document is overwhelmingly markup, inline script, and embedded state.
Why it is structural: it is a build output. Frameworks that ship their entire application state in the document produce this, and no amount of writing more copy shifts the ratio meaningfully.
What actually fixes it: moving state out of the document, splitting bundles, and trimming duplicated markup. Build configuration, not content.
Page has enough readable text to be useful
What it means: when this comes back structural rather than as a quick fix, the page returned under eighty words. Almost nothing.
Why it is structural at that level: a page with a real title and description and essentially no body text is usually a template that is not rendering its content server-side, not a page somebody forgot to write.
What actually fixes it: find out why the content is not in the response before writing more of it.
Page links onward into the site
What it means: when this comes back structural, the raw HTML contained zero internal links. Not few. Zero.
Why it is structural: a page with no links at all almost always means the navigation is built client-side. The menu exists in the browser and nowhere else, which means the entire site is being discovered through the sitemap alone.
What actually fixes it: render the navigation server-side. This one repair often clears several other findings at the same time.
Served over HTTPS
What it means: the page answered over plain HTTP.
Why it is structural: it is a certificate and server configuration issue. Nothing in the markup compensates for it.
What actually fixes it: install a certificate and force HTTPS at the server. Free certificates have been standard for years, so the usual blocker is that nobody has had access to the server recently.
Server responded promptly
What it means: the server took more than two and a half seconds to answer.
Why it is structural: that is time spent before a single byte of your content was sent. It is hosting, database, or application code.
What actually fixes it: find out what the server is doing before it responds. Caching, an unindexed query, or an underpowered host cover most cases, and all three are decided above the page.
How many of these is too many
One structural finding is a thing to know about. Two is worth a conversation with whoever maintains the build. Three or more almost always trace back to a single decision, and at that point the useful discussion is about that decision rather than about the findings it produced.
That is the line between the two diagnoses above. A hotrod gets retuned. An Edsel gets replaced, and the hard part is never the engineering. It is that the assumption underneath the build moved, and admitting that is more expensive than any of the work.
That is when a rebuild stops being an upsell and starts being the cheaper option.