Page Weight vs Extractable Text: A 25-Site Audit Protocol

Protocol published August 13, 2026; testing pending. This research will compare transfer size, raw HTML size, server-extractable text, rendered-DOM text, and main-content density across 25 public pages. No result, correlation, crawling effect, ranking effect, or AI-citation effect has been established.

The question came from a practitioner discussion about a heavy homepage that yielded relatively little raw text. That observation is useful for forming a test, but it is not a representative dataset. SearchEngineAnswer will not reuse the thread’s ratio as its own evidence.

Research question

Within a declared sample of comparable page jobs, how do compressed transfer bytes, uncompressed document bytes, server-extractable text, rendered text, script and style bytes, and main-content density vary? The primary outcome is descriptive. The study will not infer crawler success or ranking from page weight.

Predeclared sample

• 25 public, permissioned-to-fetch URLs.
• Five page-job groups with five pages each: homepage, article, product or service, documentation, and directory/listing.
• One canonical desktop URL per page, no authentication, no deliberate stress testing.
• Pages selected before extraction; failed fetches remain in the dataset.
• One fixed user agent, location, network profile, and collection window recorded in UTC.

The sample is intentionally small and purposive. Results will describe these pages only; they will not represent the web.

Variables to save

Raw evidence required for every row

Layer	Field	Method note
Response	Final status, URL, redirects, headers, compressed bytes	Save raw request and response metadata
Document	Uncompressed HTML bytes	Save the exact response body and hash
Server extraction	Text from parsed HTML without browser execution	Remove script/style and normalize whitespace
Rendered extraction	Visible and accessibility-tree text after a fixed wait	Save rendered DOM and timeout state
Composition	Script, style, hydration, media-reference bytes	Report definitions and parser version
Content density	Main-content characters divided by document bytes	A study metric, not a ranking score

Collection procedure

1. Freeze the URL list, page-job labels, date, region, and software versions.
2. Fetch once for the saved network response; do not retry away failures.
3. Hash and store raw HTML.
4. Run the declared server parser and save extracted text.
5. Render in a clean browser profile with a fixed timeout and save the DOM, accessibility text, screenshot, errors, and network log.
6. Identify main content using the predeclared rule; log manual overrides.
7. Run one verification repeat for rows that fail or differ materially.

Planned analysis

The release will publish a row-level table, distributions by page job, scatter plots, and named outliers. It will distinguish compressed transfer size from raw document size and DOM size. Correlation will be reported with the sample and method boundary, not translated into “Google cannot crawl heavy pages.”

Any relationship may be explained by templates, JavaScript architecture, duplicate navigation, embedded data, content type, consent interfaces, or extraction error. Manual review will inspect outliers before interpretation.

Stop and correction rules

• Stop if the collector repeatedly changes page state or violates a site’s controls.
• Replace no sampled URL after results are visible; document exclusions.
• Publish fetch and parser failures as results.
• Correct extraction bugs and rerun the entire affected metric, with the change logged.
• Do not publish site-quality scores or rank individual sites.

What this study cannot establish

It cannot determine Google’s crawl budget, indexing choice, ranking, rendering queue, AI citation, or user satisfaction. It cannot establish a universal ideal page size or text ratio. A light page can be unhelpful; a heavy page can be useful and crawlable. The study measures retrievable artifacts under one declared method.

Readers can use the protocol now to audit their own releases, but the SEA results section will remain marked pending until all 25 raw rows and verification artifacts are saved. The related HTTP 200 investigation explains another reason to preserve the full response rather than trusting a status code.

Community question

The test was prompted by a discussion in r/TechSEO. It is cited as the origin of the question, not as evidence for the answer.