Category: technical SEO · ~15 min read · Library article · Author: Anna Hartung
If you run a site built on Next.js, React, or any other component-based framework and you've opened a Semrush Site Audit, you've probably met the warning: "Low text-to-HTML ratio." It sounds like a verdict — as if Google has quietly downgraded your pages for being too code-heavy. In practice, it's one of the most misread signals in technical SEO, and on a modern stack it fires constantly on pages that are completely healthy.
This guide goes past the one-line "ignore it" advice you'll find elsewhere. We'll cover what the ratio actually measures, why frameworks like Next.js trip it by design, whether Google treats it as a ranking factor at all, and — the part that actually matters — how to tell the difference between a harmless warning and a genuine rendering problem hiding behind it.
Key takeaways
| Point | Detail |
|---|---|
| It is not a Google target | Google documents how it crawls, renders and indexes pages, but defines no text-to-HTML threshold for ranking. |
| Next.js trips it by design | Component frameworks emit deep structural markup, hydration data, and scripts, so the ratio reads low even on perfectly healthy pages. |
| The real question is rendering | Ask whether your content is present in the server HTML crawlers receive — not whether a percentage clears some threshold. |
| Do not assume every crawler runs JavaScript | Google explicitly notes that not all bots can run JavaScript, so useful initial HTML remains the robust baseline. |
| Fix the cause, not the number | Padding text to raise the ratio never moves rankings; address thin content or a rendering gap instead and the ratio follows. |
Is text-to-HTML ratio a Google ranking factor?
Google defines no text-to-HTML target in its Search documentation. Its current JavaScript SEO documentation describes crawling, rendering and indexing, while its performance guidance uses measured loading and interaction metrics—not a ratio of copy bytes to markup bytes. Google representatives have also said publicly that the ratio is not a Search ranking factor.
So where does the "ideal ratio of 25–70%" figure that some tools quote come from? Not from Google. That range is folklore that circulates among auditing tools and SEO blogs; it describes a correlation that used to hold on simple static sites — text-heavy pages tended to be cleaner and lighter — not a rule Google enforces. Treating it as a target is exactly the mistake Mueller was warning against.
That doesn't make the warning meaningless, though. It makes it indirect. A genuinely bloated page — megabytes of markup, scripts, and styles wrapped around a sentence of content — can be slow, hard to crawl efficiently, and thin on substance. None of those is "the ratio"; they're separate, real problems that a low ratio sometimes points at. The ratio is the check-engine light, not the engine.
What does Semrush actually measure — and why does Next.js trigger it?
Semrush's current Site Audit issue list says it raises the warning when a page's text-to-HTML ratio is 10% or less. Semrush classifies it as a Warning rather than an Error. That is a tool-specific diagnostic threshold, not a threshold published by Google, so it should be interpreted alongside rendering, performance, content and indexation evidence.
Now consider how a Next.js or React page is built. The framework ships a tree of components, each wrapped in its own structural markup. Layout primitives, design-system wrappers, navigation, card grids, filters, and repeated UI elements all emit <div> after <div> — the "divitis" that visual builders and component systems produce as a side effect. On top of that sits the framework's own runtime: hydration payloads, inlined JSON state, preload tags, and script references in the <head>. The result is a page where the markup is large by construction, while the visible text on a given page — say, a service overview or a portfolio grid — is comparatively short. Divide one by the other and you land under 10% without anything being wrong.
This is why the warning clusters on exactly the page types where it's least informative: listing and index pages (blog indexes, tag archives, case-study overviews), legal and utility pages (privacy policy, terms, brand disclaimer), and design-led landing pages that lead with imagery and components rather than long copy. E-commerce and Shopify stores hit it for the same reason — product grids plus third-party scripts inflate the denominator. The metric was designed for a web made of hand-written HTML documents. Component-rendered applications simply don't fit its assumptions.
The question that actually matters: can Google see your content?
Here's the reframe that turns this from a vanity metric into a useful diagnostic. The right question was never "is my ratio above some number?" It's "is my real content present in the HTML that crawlers receive — and can search engines render it reliably?" On a JavaScript framework, that question has real teeth, and it's worth understanding the mechanics.
Google describes three phases for JavaScript pages: crawling, rendering and indexing. It parses the HTTP response for crawlable links, and pages eligible for indexing are then sent to a render queue where the Web Rendering Service executes JavaScript. Google notes that a page can remain in that queue longer than a few seconds; it does not publish a guaranteed rendering time. Its documentation also says all eligible 200 pages may be rendered, so server-rendered HTML should not be described as literally "skipping" the renderer. The practical advantage is simpler: meaningful content and links are already available in the response even before client code succeeds.
This is where rendering strategy decides everything, and Next.js gives you the full spread:
In client-side rendering (CSR), the server may return only an application shell plus scripts. Google can render JavaScript, but the page then depends on those scripts, resources and data requests completing successfully before the final content can be processed. Important links that exist only after rendering are also discovered later than links present in the response. A CSR page can therefore show both a low text-to-HTML ratio and a real rendering problem; the ratio is only the prompt to investigate.
In server-side rendering (SSR) and static generation (SSG), meaningful content, links and metadata can arrive in the HTTP response. Next.js also supports cached and per-route rendering strategies, so public marketing and editorial pages do not need to behave like logged-in application screens. The point is not "never use client rendering"; it is to avoid making important public content depend unnecessarily on a fragile client-only path.
So when the Semrush warning appears, the productive move is not to chase the percentage. It's to confirm that the page's meaningful content exists in the server response. The fastest checks: view the page's raw source (not the rendered DevTools DOM) and search for a core sentence; and run the URL through Google Search Console's URL Inspection to see the actual rendered HTML Google captured. If your headings and key paragraphs are there, a 7% ratio is a non-issue. If they're missing from the raw HTML and only appear after JavaScript runs, you've found something worth fixing — and it has nothing to do with the ratio.
Why initial HTML still matters beyond Google
Crawler capabilities differ. Google itself advises that server-side or pre-rendering remains useful because not all bots can run JavaScript. Bot documentation commonly explains user agents and access controls, but that alone does not prove the exact rendering behavior of every downstream retrieval system. The safe engineering assumption is therefore modest: put the substantive public content in the initial HTML instead of requiring every crawler to reproduce a full browser session.
This does not guarantee inclusion in an answer engine, and client-side rendering does not automatically exclude a page. It simply removes an avoidable dependency: systems that fetch usable HTML can extract the page without needing the same JavaScript support, timing and network access as a user's browser.
When the warning is genuinely safe to ignore
Put together, a low text-to-HTML ratio is almost always harmless when the page is doing its job and its content is server-rendered. A blog index that lists posts, a tag page, a privacy policy, a visually rich landing page where the framework emits deep component markup — these will trip the 10% threshold routinely, and that's expected. Google doesn't score the ratio; it asks whether the page satisfies its intent, whether it can render and index the content, and whether the page is internally linked and reachable. If a human can tell what the page offers within a few seconds and the core text is present in the raw HTML, the warning is noise. Inflating such a page with filler text to "fix" the number does nothing for rankings and often hurts the design and conversion rate it was built for.
When a low ratio is a symptom worth chasing
The warning earns your attention when it travels with other signals — that's the discipline. Treat it as a prompt to investigate, then look for the things that actually matter:
A page with genuinely little content behind the markup (the classic example: a service page that's two sentences and a grid of cards) targeting a commercial or informational query it has no depth to win. Semrush flagging Low Word Count or Thin Content on the same URL — those are the more meaningful warnings, and a low ratio next to them corroborates a real gap. Google Search Console showing weak impressions, or the page sitting in "Crawled – currently not indexed" or "Discovered – currently not indexed." And the rendering red flag above: important content present only after client-side execution, absent from the initial HTML. In every one of these cases the ratio isn't the disease — low word count, thin content, weak intent coverage, or a rendering dependency is. Fix those, and the ratio takes care of itself as a byproduct.
One specific footgun worth naming is a robots.txt rule that blocks JavaScript or CSS needed to render the page. Google states that it cannot render JavaScript from blocked files or blocked pages. Whether that changes indexation depends on which content relies on those resources, but it is a real rendering issue that the ratio itself cannot diagnose.
How we audit this at H-Studio
When this warning shows up in a client audit, we don't open a text editor — we run a short sequence of checks, in priority order.
First, rendering parity: does the raw server HTML contain the page's headings, primary paragraphs, internal links, and structured data? We compare view-source against the rendered DOM and confirm with Search Console's URL Inspection what Google actually captured. Second, intent and depth: does the page have enough substance to satisfy the query it targets, judged as a reader would judge it — not by word count alone, but by whether it answers the question. Third, the corroborating signals: low word count, thin content, indexation status in GSC, and whether the page is even internally linked from somewhere relevant. Fourth, the bigger issues that almost always outrank this one: Core Web Vitals and performance, indexability and canonicalisation, and keyword cannibalization between pages competing for the same intent. Only if content quality is genuinely lacking do we recommend expanding or restructuring — and then for the reader, not for the metric.
In years of doing this, I can't recall a single case where raising a text-to-HTML ratio, on its own, moved a ranking. Every time the warning mattered, it was standing in front of a real problem — usually thin content or a client-side rendering gap — and fixing that is what changed the outcome.
Fixing it the right way (only when justified)
If an audit does turn up a genuine weakness, the work is about quality and rendering, never padding. The levers that actually help:
Make sure essential content—headings, main copy and primary links—is present in the server response. Validate structured data in the rendered output too. Where a page is genuinely thin for its intent, add only the explanation a reader needs; there is no universal word count. Keep critical information available without a user interaction that a crawler may not perform. On the code side, trim unused JavaScript and oversized third-party scripts because that helps users and measured performance, even though any ratio change is only a byproduct.
What never helps is manufacturing text to hit a number. Stuffing a clean landing page with paragraphs nobody will read inflates the ratio, dilutes the message, and tends to lower conversion — trading a phantom SEO gain for a real business loss.
What actually moves rankings here
Strip the warning back and the priorities are clear: confirm that the page is indexable, its meaningful content survives rendering, it satisfies its intended reader, and real performance measurements are acceptable. Core Web Vitals—LCP, CLS and INP—belong to Google's page-experience signals, but relevance is not reducible to any single metric. Text-to-HTML ratio sits downstream of these decisions; improving a ratio alone demonstrates none of them.
For modern Next.js sites, the verdict is simple: treat "low text-to-HTML ratio" as a diagnostic hint, not an action item. Let it prompt the two questions worth asking — is my content in the server HTML, and does this page deserve to rank for its intent? — and act only on the answers.
If you want a second pair of eyes on how your Next.js site renders for crawlers, our SEO migration & relaunch work starts exactly here — rendering parity, indexability, and intent — before anyone touches a word count. A 30-minute intro call is the easiest way to start.
— Anna
Frequently asked questions
Is a low text-to-HTML ratio bad for SEO?
Not on its own. Google's John Mueller has said plainly that the ratio is not and never has been a ranking factor. It only matters indirectly, as a possible hint of page bloat, thin content, or a rendering problem — each of which you'd address directly, not by changing the ratio.
What is a good text-to-HTML ratio?
There's no Google-defined target. The "25–70%" figure quoted by some tools is industry folklore, not a Google rule. Semrush simply flags pages at 10% or below. A page can rank perfectly well below that threshold.
Why does my Next.js or React site have a low text-to-HTML ratio?
Because component frameworks emit large amounts of structural markup — nested layout elements, design-system wrappers, hydration data, and scripts — relative to visible text. The denominator is large by design, so the ratio reads low even on healthy pages.
How do I know if Google can actually see my content?
Look at the raw server HTML (view-source, not the rendered DevTools DOM) and search for a core sentence; then use URL Inspection in Google Search Console to see the rendered HTML Google captured. If your headings and main paragraphs are present, you're fine.
Does client-side rendering hurt SEO?
It can create avoidable rendering dependencies. Google can run JavaScript, but client-only content depends on scripts and data requests completing during rendering, and not every crawler supports JavaScript. Server-side or static rendering puts meaningful content in the initial HTML and is a robust baseline for public pages.
Should I add text to fix the warning?
Only if the page is genuinely thin for the query it targets. Add content that helps the reader — a clear intro, an explanation of the offering, a real FAQ. Never pad a page just to raise the ratio; it doesn't help rankings and usually hurts clarity and conversion.
Edited and fact-checked by Anna Hartung.