Why the Mega Analyzer wants 800 words on expertise page...

The E-E-A-T signals card in the Mega Analyzer ends with a row that reads 412 words (≥800 for expertise pages), with your page's own number in place of the 412. It goes green at 800 and red below it, and it says nothing else. What it is really measuring is not length. It is the odds that a page claiming to know something has room for the parts that make a claim checkable: a definition, evidence, a caveat, and a source. Below 800 words those parts are usually missing, and that is the only reason the number exists.

What the check actually tests

Pass and fail use the same wording. The row title is the count followed by "words (≥800 for expertise pages)", the icon is a check mark or an X, and no detail text renders on either outcome. The test is one comparison: d.wordCount >= 800.

The count comes from a single line in the analyzer:

m.wordCount = m.bodyText ? m.bodyText.split(/\s+/).length : 0;

bodyText is the fetched HTML parsed with DOMParser, cloned, and stripped of the page chrome before its text is read. The strip list is script, style, nav, header, footer, aside, noscript and form, plus anything carrying role="navigation", role="banner" or role="contentinfo", plus the common class names sites use when they skip the semantic tags: .site-footer, .footer, .notification-bar, .bottom-bar, .mobile-nav, .legal, .disclaimer, .terms, .cookie-consent and a few more. Whatever survives is collapsed to single spaces, trimmed, and split on whitespace. Every token is a word, so "1,200" is one word and a stray pipe character between two table cells is also one word.

Four details decide whether a page you think is long enough actually passes:

Tables and lists count. The Voice bucket strips table and dl before it measures sentence length, but the word count keeps them. A spec table with 300 cells is 300 or more words here.
Hidden text counts. DOMParser does not apply CSS, so an accordion panel with display:none or a collapsed details element contributes its full text. The count is what a crawler receives, not what a visitor sees.
Client-rendered text does not count. The analyzer reads the HTML the proxy fetched and never executes JavaScript. A page that ships a 40-word shell and hydrates 1,500 words on the client fails this row, and the Overview's "SSR vs SPA shell" cell will say SHELL or THIN at the same time.
Alt text and attributes do not count. textContent reads text nodes only. Image descriptions, title attributes and aria-label values are invisible to it.

The same number appears in three other places: the Overview stats line ("N words · N schema types · N H2s"), the Words row of the Mobile parity table, and its Word gap stat. If desktop and mobile disagree by more than 200 words, the Mobile parity score loses 25 points on its own and this row is the wrong one to fix first.

In the score, the row is worth 10 points of the E-E-A-T sub-score, whose maximum runs from 124 to 131 depending on whether the page hosts a Person, Organization or vertical business entity. So a fail costs about 8 percent of that bucket, not the bucket. The Voice sub-score separately credits 10 of its 100 points when the prose alone, tables removed, reaches 800.

Why it matters

Start with the awkward part. Google's helpful content guidance includes this self-assessment question under "Avoid creating search engine-first content": "Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't.)" That is as plain as Google gets. There is no 800-word ranking rule, and an audit tool that implied one would be lying to you.

So why does the analyzer hold the line at 800? Because 800 is a proxy for structure. Google's Search Quality Evaluator Guidelines, section 3.2, tell raters to judge main content on effort, originality, talent or skill, and, for informational and YMYL pages, accuracy against "well-established expert consensus." The guidelines never name a length, but what they describe takes words: a definition of the thing, at least one piece of evidence with numbers in it, an honest boundary on when the advice does not apply, and a pointer to where the facts came from. A page under 800 words tends to have one or two of those four. A page over 800 written by someone who knows the subject usually has all four without trying.

The same pattern shows up on the retrieval side. The AI Citation Readiness audit on this site runs word count as its first signal, with 800 as the pass line, because shorter pages rarely contain a self-contained passage an answer engine can lift with its evidence attached. The Mega Analyzer's own passage check counts paragraphs of 134 to 167 words, ideally sitting directly under an H2 or H3, and goes green at three of them. Three such paragraphs alone are 400 to 500 words before you have written an introduction.

The demotion evidence points the same way from the other end. The HCU classifier post on this site found pages under 300 body words heavily over-represented in the corpora demoted by the helpful content system, with pages under 600 usually lacking the depth the classifier rewards on competitive queries. Thin was the common thread, not short. But the two travel together often enough that the count is a cheap first screen.

That is why the row should be read next to three neighbors rather than alone: Hedge word density (target ≤ 3 per 1K words) and Vague-claim density (target ≤ 1 per 1K words) in the Voice card, and Page makes ≥2 quantified claims in the Trust card. A 1,400-word page with twelve hedges per thousand words and zero numbers passes this row and fails the point of it. A 400-word page that fully answers "what is the deposit on a 10x10 unit" with the actual dollar figure and the refund terms is fine. A 500-word "complete guide to" anything in finance, health or law usually is not, because the guide format promises the four parts and 500 words cannot deliver them.

How to fix it

1. Classify the page before you touch it. Expertise pages make a claim to knowledge: articles, service explainers, about and bio pages, FAQ hubs, anything on a YMYL topic. Utility pages do a job: contact, thank-you, category indexes, login, legal boilerplate. The analyzer does not classify for you; it applies the threshold to every URL and leaves the judgment to the person reading the report. If a utility page fails, you are done.

2. For an expertise page under 800, add structure, not sentences. Work through the missing pieces in this order, because each one is something a rater or a retriever will look for by name:

A one-sentence definition inside the first 100 words. The analyzer has a "First 100 words contain a definitional sentence" check that looks for "is", "are", "means" or "refers to" in that window, but it only runs on article-shaped pages that already have 800 words, so you will not see it until this row is green.
A "who this is for" paragraph that names the reader and the situation, and, just as usefully, the reader it is not for.
The mechanism or the steps. How the thing actually works, in the order it happens.
One worked example with real numbers: a rate, a count, a date, a dollar figure, with the unit attached.
A "when not to" or caveats section. This is the part most sites skip, and it is the part that reads as expertise.
A sources list with outbound links to the primary documents.

Written honestly, those six pieces land between 900 and 1,400 words without any effort to hit a number. If you finish them and the page is still at 600, it is probably a narrow question that deserves to stay short (see the next section).

3. Merge thin siblings. If one topic is split across three or four URLs of 250 words each, none of them is an expertise page and all of them compete with each other. Pick the URL with the most inbound links or the cleanest slug, fold the others into it as sections, and 301 the losers to the survivor. The Programmatic SEO Thinness Audit post covers how to spot the shingle pattern where this is happening at scale.

4. Move boilerplate out of the body region and mark the content region. Repeated calls to action, legal text, newsletter blocks and location footers inflate the count without adding content, and they also drag the hedge and CTA density numbers in the wrong direction. Put them in header, footer, aside or nav, or give them one of the class names the strip list recognizes, and wrap the real content in main and article so any extractor reads the right region:

<body>
  <header>... site chrome, stripped before counting ...</header>
  <nav aria-label="Primary">...</nav>

  <main>
    <article>
      <h1>How a self-storage deposit actually works</h1>
      <p>A storage deposit is a refundable amount held against damage or unpaid rent,
         collected once at move-in and returned within the window the lease names.</p>

      <h2>Who this is for</h2>
      <p>...</p>

      <h2>How the deposit is calculated</h2>
      <p>...</p>

      <h2>A worked example</h2>
      <table>...</table>

      <h2>When a deposit is not refunded</h2>
      <p>...</p>

      <h2>Sources</h2>
      <ul><li><a href="https://example.gov/...">...</a></li></ul>
    </article>
  </main>

  <aside class="newsletter">... not counted ...</aside>
  <footer>... legal text, mailing address, copyright: not counted ...</footer>
</body>

If the page carries Article JSON-LD, stick to the properties Google's Article documentation recommends (none are required): headline, image, datePublished, dateModified and author. schema.org defines a wordCount property on Article, but Google's documentation does not list it and the analyzer does not read it. The count on this row always comes from the rendered text.

5. Re-run, then check that the new paragraphs carry weight. Run the Mega Analyzer again and confirm the row and the Overview count moved by roughly the number of words you added. Then run Paragraph Semantic Density on the same URL. It scores every paragraph on noun density and entities per 100 words and flags the filler ones, which is the fastest way to catch a paragraph that added 90 words and no information. Finish with AI Citation Readiness for the rest of its signals, because a page that just crossed 800 often also lacks a named author, a visible date, or an outbound citation.

No code change is required beyond the semantic landmarks in step 4. This row is fixed in the editor, not the template.

When to leave it alone

Utility pages. A contact page with an address, a phone number, hours and a map is doing its job at 90 words, and so are a thank-you page, a category index, a login screen and a 404. The row will be red on every one of them. Read it as not applicable and move on.

Narrow questions with complete answers. A glossary entry, a single FAQ answer at its own URL, or a "what does this fee cover" page that gives the fee, the amount, the reason and the exception has answered the question. Adding 400 words makes it worse. Make sure it lives under a hub that is itself an expertise page and links to it, so the depth exists one click away.

Pages whose content is not text. A gallery page for a photographer, a video page, a downloadable spec sheet with a two-paragraph description, or an interactive tool are judged by what they do. The rater guidelines say the amount of effort expected for a short social video is less than for a documentary, "but both need sufficient effort to create satisfying content for their purpose." Purpose sets the bar, not the medium's word count.

Client-rendered pages, until the rendering is fixed. If the Overview's "SSR vs SPA shell" cell says SHELL or THIN, this row is reporting a rendering problem, not a content problem. Fix the pre-rendering first, then read the row again.

And never pad. The rater guidelines have a section for this, 5.2.2, "Filler as a Poor User Experience": filler "can artificially inflate content, creating a page that appears rich but lacks content website visitors find valuable," and a Low rating is appropriate when a page "contains a large amount of low quality and unhelpful filler." Crossing 800 with filler turns a red row into a green one and a fine page into a Low one. If the six structural pieces in step 2 are all present and the count still reads 650, the count is wrong about this page, and you should trust the page.

If you run a portfolio of sites built from one template, the way The $100 Network lays out, a red row on one site is usually a red row on all of them. The fix belongs in the shared content model, once, rather than in sixteen separate editors.

Fact-check notes and sources

Source: https://developers.google.com/search/docs/fundamentals/creating-helpful-content establishes Google's position on length. Under "Avoid creating search engine-first content" the self-assessment asks, "Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't.)" The same page asks whether content demonstrates "first-hand expertise and a depth of knowledge" and presents information "in a way that makes you want to trust it, such as clear sourcing."
Source: https://static.googleusercontent.com/media/guidelines.raterhub.com/en//searchqualityevaluatorguidelines.pdf (Search Quality Evaluator Guidelines, September 11, 2025 edition). Section 3.2, Quality of the Main Content, names effort, originality, talent or skill, and accuracy as the criteria, and its example is that "a short video shared on social media" needs less effort than "a full-length, professionally produced documentary," but both need sufficient effort for their purpose. Section 5.2.2, Filler as a Poor User Experience, defines filler and assigns a Low rating to pages with a large amount of it. Section 2.3 defines YMYL topics as those that "could significantly impact the health, financial stability, or safety of people, or the welfare or well-being of society."
Source: https://developers.google.com/search/docs/appearance/structured-data/article lists author, dateModified, datePublished, headline and image as the recommended Article properties and does not mention word count anywhere.
Source: https://schema.org/wordCount defines the property as "The number of words in the text of the CreativeWork such as an Article, Book, etc." and lists Article and CreativeWork as the types it is used on. It exists in the vocabulary; Google does not document reading it.
Analyzer internals, verified in the tool source on 2026-09-21: the count is bodyText.split(/\s+/).length after chrome removal; the row is renderChk(d.wordCount >= 800, ...) with an empty detail string; the E-E-A-T sub-score adds 10 points for wordCount >= 800 against a maximum of 124 to 131; the Voice sub-score adds 10 of 100 for 800 prose words; the passage check counts paragraphs of 134 to 167 words and goes green at three; the definitional-sentence check is gated behind wordCount >= 800 and an article-shaped URL or schema; the Mobile parity sub-score drops 25 points when desktop and mobile word counts differ by more than 200. The AI Citation Readiness tool's code runs word count as check 1 with 800 as the pass line.

Why the Mega Analyzer wants 800 words on expertise pages, and when 800 is wrong