Under the Hood
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.
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 when a rebuild stops being an upsell and starts being the cheaper option.