Text-to-HTML ratio, in short
Text-to-HTML ratio (or text-to-code ratio) is the percentage of a page's HTML that is visible text. It is not a Google ranking factor: asked directly in 2018, Google's John Mueller said Google does not use anything like it and simply picks up the visible content on the page. A low ratio is still worth a look, because it can point to thin content, HTML so large it nears Googlebot's 2MB limit, or content that only appears after JavaScript runs.
- Google does not use the ratio. No Google documentation mentions it.
- The warning lines (such as 10%) are set by each audit tool, not by Google.
- Fix the cause, if there is one. Never pad a page with words to move the number.
Here is the full exchange, from a Google Webmaster Central office-hours hangout in March 2018. A viewer asked whether there is any term like text to code ratio in SEO. Mueller's answer, as transcribed: "No. We don't use anything like text to code when it comes to Google search. We essentially pick up the visible content on the page, and we use that. Some pages have a lot more HTML, some pages have a lot less HTML. That's more a matter of your design preferences, how you set things up on your site." You can watch the answer at 18:43.
So why do audit tools still flag it? Because the ratio is cheap to calculate on every page of a crawl, and an unusually low one is a reasonable hint that something else is off. The useful skill is telling the hint apart from the problem.
How the Ratio Is Calculated
Tools differ in the details, but Screaming Frog publishes a clear definition: the number of non-HTML characters found in the body of the page (the text), divided by the total number of characters the HTML page is made up of, shown as a percentage.
ratio = visible text characters / total HTML characters x 100
Worked example. A blog post has 1,500 words, about 9,000 characters of visible text. Its HTML, including the theme, navigation, inlined SVG icons and a block of CSS in the head, is 120,000 characters. The ratio is 7.5%, and a tool with a 10% threshold flags it. Watch what happens with two different changes:
| Version | Text chars | HTML chars | Ratio | What changed |
|---|---|---|---|---|
| Original page | 9,000 | 120,000 | 7.5% | Flagged by a tool with a 10% threshold |
| Inlined SVG icons and CSS moved to files | 9,000 | 60,000 | 15% | Same words, ratio doubled |
| 800 more words of genuinely useful content | 13,800 | 65,000 | 21% | Better for readers; the ratio is a side effect |
The first change doubled the ratio without touching a word a reader sees. The second improved the page and raised the ratio as a side effect. Only the second could plausibly help in search, and it would help just as much if the ratio had not moved. That is the whole lesson: the ratio describes the template more than the content.
To check one page yourself, a rough measurement in a terminal:
# Total HTML characters, as the server sends them
curl -s https://example.com/post > page.html && wc -c page.html
# Visible text characters (rough: strips tags, scripts and styles)
python3 -c "import re,sys;t=open('page.html').read();t=re.sub(r'(?s)<(script|style).*?</\1>','',t);print(len(re.sub(r'\s+',' ',re.sub(r'<[^>]+>',' ',t)).strip()))"What Tools Flag, and What Google Says
Each audit tool picks its own line, which is the first clue that there is no official one:
| Tool | How it treats the ratio |
|---|---|
| Semrush Site Audit | Flags "low text-HTML ratio" when it is 10% or less |
| Screaming Frog SEO Spider | Reports a Text Ratio column for every page; no pass or fail line |
| Oncrawl | Reports the ratio and states in its help docs that Google does not use it as a ranking factor |
Some tool documentation goes further and says a higher ratio gives a page a better chance of ranking. Google has never said so, and its one direct answer says the opposite. Here is how the common claims hold up:
| Myth | What the sources say |
|---|---|
| Google rewards pages with a higher text-to-HTML ratio. | Google's John Mueller: "We don't use anything like text to code when it comes to Google search." (2018) |
| You need a ratio above a certain percentage to rank. | No Google documentation mentions the ratio. Thresholds are each tool's own choice, and they disagree. |
| Adding more words fixes the problem. | Google's helpful content guidance asks whether you are writing to a word count because you heard Google prefers one, and answers: "No, we don't." |
| Markup is dead weight. | Structured data, accessible navigation and semantic tags all add HTML and lower the ratio. They are often worth it. |
| HTML size never matters. | It does at the extreme: Googlebot indexes only the first 2MB of an HTML file, uncompressed. |
What a Low Ratio Might Be Pointing To
Four problems are real, and each one can drag the ratio down. Check for them directly; the ratio only tells you where to start looking.
| Issue | What it looks like | How to check | Fix |
|---|---|---|---|
| Thin content | A normal-sized template with a few lines of text | Read the page against the queries it gets impressions for in Search Console | Answer the query properly, or merge the page into a stronger one |
| HTML near the 2MB limit | Very large HTML even though the visible page is short | Download the HTML and check its uncompressed size | Move inlined images (base64), SVG sprites, large style blocks and big serialised data out of the HTML |
| Content only after JavaScript | A ratio close to zero; the raw HTML is an empty shell | Compare view-source with the rendered page, or use View crawled page in Search Console's URL Inspection | Server-side rendering, static generation or pre-rendering for content pages |
| Very large DOM | Deeply nested wrappers, long lists rendered in full | Run Lighthouse and read the Optimize DOM size insight | Flatten wrappers, paginate or virtualise long lists, render hidden panels on demand |
The 2MB limit
This is the one hard number in the topic. Google's documentation says that when crawling for Google Search, Googlebot crawls the first 2MB of a supported file type (64MB for PDFs). The limit is applied to the uncompressed data, each referenced resource such as CSS or JavaScript is fetched separately under the same limit, and once the cut-off is reached only the part already downloaded is sent for indexing. Google updated this page in February 2026; older articles and Google's general crawler overview still quote 15MB, which remains the default for Google's crawlers as a whole. An ordinary article is nowhere near 2MB. A page that inlines base64 images or ships a very large serialised data blob can be.
JavaScript-only content
A client-rendered app can send HTML that is little more than a script tag, so its raw ratio is close to zero. Google renders JavaScript before indexing, so this is not automatically a problem in Google, but Google's own JavaScript guidance says server-side or pre-rendering is still a great idea because it is faster for users and crawlers and not all bots can run JavaScript. Our guide to removing unused JavaScript covers the performance side.
DOM size
The older Lighthouse audit warned when the body had more than about 800 nodes and errored above about 1,400. Since Lighthouse 13 it has been replaced by the Optimize DOM size insight, which only fails when a large layout or style recalculation takes longer than 40ms. That is a better test: it measures the cost of the markup, not its amount. See measuring page speed and optimising INP for what to do about it.
Triage Low-Ratio Warnings in Five Steps
- 1
Export the flagged pages
From your audit tool, export every page with a low ratio warning, with its URL and word count.
- 2
Sort them by what they earn
Add Search Console clicks and impressions for each URL. A flagged page with no impressions and no purpose may be a candidate for removal, not repair.
- 3
Check the raw HTML size of the top few
Anything in the hundreds of kilobytes for an ordinary article deserves a look at what is inlined. Anything approaching 2MB is urgent.
- 4
Compare raw and rendered text
If the main content is missing from view-source but present in the browser, the page depends on JavaScript to show its content. Check how Google sees it with URL Inspection.
- 5
Read the page as a visitor would
If the HTML is fine and the content is still thin for the query, the fix is editorial. If the page is good and the HTML is fine, close the warning and move on.
For the wider checklist this fits into, see the DIY technical SEO audit.
Ask Google how it sees the page
Murkuz does not crawl or score your HTML. It reads what Google reports. In Claude or ChatGPT, ask Inspect_URL whether a flagged page is indexed and which URL Google picked as canonical, and Search_Analytics for its clicks and impressions, which is steps one and two of the triage without an export. See the Search Console connector.
Further reading
Google's documentation first, then the record of what Google said and how tools define the number. Each one was read in full before it was added here.
Official docsGoogle Search Central
What is GooglebotStates the limit that actually matters for HTML size: Googlebot crawls the first 2MB of a supported file, measured uncompressed, and only what it downloaded goes forward for indexing.
Official docsGoogle Search Central
Understand JavaScript SEO basicsHow Google crawls, renders and indexes JavaScript pages, and why it still calls server-side or pre-rendering a great idea. The real issue behind most near-zero ratios.
NewsSearch Engine Roundtable, Barry Schwartz
Google has no code to text ratio algorithmThe write-up of John Mueller's 2018 answer, with the office-hours video embedded at the right moment. The clearest on-record statement from Google on the subject.
Official docsChrome for Developers
Optimize DOM sizeWhat Lighthouse and the Performance panel now check about page structure, and when a large DOM becomes an actual performance problem rather than a number on a report.
Tool docsScreaming Frog
SEO Spider tabs: ContentThe plainest published definition of how a crawler calculates the text ratio, along with the other content columns it reports. Useful for knowing exactly what a tool's number means.
Frequently Asked Questions
What is text-to-HTML ratio in SEO?
Text-to-HTML ratio, also called text-to-code ratio, is the share of a page's HTML that is visible text, shown as a percentage. Screaming Frog, for example, divides the number of non-HTML characters in the body by the total number of characters in the HTML. SEO audit tools report it as a rough sign of how much of a page is content and how much is markup, styles and scripts.
Is text to code ratio a ranking factor?
No. Asked in a 2018 office-hours session, Google's John Mueller said that Google does not use anything like text to code ratio in search. Google picks up the visible content on the page and uses that, and how much HTML surrounds it is a design choice. No Google documentation mentions the ratio as a signal.
What is a good text-to-HTML ratio?
There is no good ratio in Google's eyes, because Google does not use it. Tools set their own warning lines: Semrush's Site Audit flags pages at 10% or less. Treat a flagged page as a prompt to check for thin content, oversized HTML or content that only appears after JavaScript runs, and ignore the number itself once those are ruled out.
How do I calculate text-to-HTML ratio?
Divide the length of the page's visible text by the length of its full HTML and multiply by 100. A page with 9,000 characters of text in 120,000 characters of HTML has a ratio of 7.5%. Crawlers such as Screaming Frog calculate it for every page; for one page you can download the HTML and count both with a short script.
How do I fix a low text-to-HTML ratio warning?
Find out what the warning is pointing at. If the page has little to say, improve the content for the reader. If the HTML is large, look for inlined images, SVGs, styles and serialised data that could be external files. If the text only appears after JavaScript runs, render it on the server. If none of those apply, the warning can be ignored.
Is HTML size a problem for Google?
Only at the extreme. Google's documentation says Googlebot crawls the first 2MB of a supported file type, measured on uncompressed data, and sends only the part it downloaded for indexing. Content after that cut-off is not considered. Very few pages come near it, but pages with large inlined data can.
Does JavaScript affect text-to-HTML ratio?
Yes. A page that builds its content with JavaScript in the browser can ship almost no text in its HTML, so tools that read the raw HTML report a ratio near zero. Google can render JavaScript, but its own guidance says server-side or pre-rendering is still a great idea because it is faster for users and crawlers, and not all bots can run JavaScript.