Reading & structure
Readable text before and after JavaScript
Readable text is wording BLURSOR extracts from a page response. Its browser-text presence measurement checks which distinct visible word passages were already in the raw response; character counts remain supporting context.
What it means
A website can send useful text in its initial response and add more after JavaScript runs. Some readers process that initial response; a browser can also run the page's scripts. Google documents its own rendering process, but that does not establish how every search or AI service handles a page.
For an owner, the useful question is whether product details, prices, explanations, and contact information arrive in the version a reader receives. A large character total is not an achievement by itself. Menus, repeated cards, consent panels, and other interface text can increase the number without adding useful business information.
An example
Illustrative example
Hypothetical example: more text after a consent panel loads
Imagine a service page with 8,000 extracted characters in the initial response and 10,000 in the browser snapshot. If the extra 2,000 characters belong to a consent panel, the counts alone do not show that the service description was missing. Passage matching checks the wording instead.
In a different hypothetical page, the initial response contains only a loading message while the browser contains the complete service description. Its distinct browser-view passages will be mostly absent from the raw response even if other raw text makes the totals similar.
| Measurement | Hypothetical value | Meaning |
|---|---|---|
| Initial response | 8,000 characters | Extracted text before JavaScript |
| Browser snapshot | 10,000 characters | Extracted text after browser rendering |
| Browser wording in raw response | Measured from passages | Words in matching three-word passages, divided by distinct visible browser words |
How BLURSOR measures it
In the report: Text before JavaScript · Text after JavaScript · Browser-view text in raw response · Readable page content
BLURSOR counts text characters in the retained raw HTML and browser HTML as separate context. For the leading percentage it also collects laid-out text nodes in one browser state, excludes CSS-hidden elements, normalizes case and punctuation, and removes duplicate browser blocks. It counts distinct visible words in three-word passages found in the raw extraction; a heading shorter than three words needs an exact block match. Sections can move without losing a match.
The denominator is the distinct visible browser words captured, not the character count. Capture and extraction limits, absent browser evidence, or different destinations make the percentage unavailable. The raw and browser text panels retain HTML text and may include hidden wording; the leading percentage uses the separate visibility snapshot. This is not a pixel-level reading test.
What to do next
- Search both extracted versions for your main offer, price conditions, and other information customers need before deciding.
- If important text appears only after JavaScript, ask your developer whether the initial response can include it.
- Investigate the cause of a large difference before changing the page or adding more text.
What it cannot tell you
- Matching passages do not prove that wording is accurate or useful. Text in canvas, CSS-generated content, frames, and states after clicks may not be captured; very short common phrases can match by coincidence.
- This measurement does not verify a real crawler's visit, indexing, ranking, or citation.
Sources and further reading
The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.
Want to know how your business looks online? Get a free website audit