Website Word Counter

The word count of a website page is two numbers, not one.

Every word counter answers a slightly different question, which is why three tools give three figures for one page. Here is what gets counted, what should, and what a count can and cannot tell you about a page's chances in Google and in AI answers.

What a website word counter actually counts

A paste-in word counter has it easy: you hand it the text, it counts the text. A URL word counter has to decide first what the text is. The served HTML of a typical page holds the article, but also the navigation menu, a header with a phone number and a call to action, a sidebar of related posts, a newsletter form, a cookie banner, and a footer that repeats the address, the social links and, on a regulated firm's site, several paragraphs of legal notices. All of it is visible text. Only part of it is the page.

So there are two honest answers. The whole-page count is every word of text in the document, which is what a reader scrolling to the bottom technically passes. The main-content count is the words in the part of the page that is unique to it, the part a search engine or an AI assistant is trying to understand when it decides what this URL is about. Some tools report only the first, some report only a cleaned version without saying how they cleaned it, and a few split total from corrected count as this one does. This counter shows both, and names the rule that separates them.

The rule is the one Verand's own site audit uses on every page it crawls. Scripts, styles, SVG, forms and iframes are removed. Then the first <article> element that holds at least 250 characters of text is taken as the main content. If there is none, the <main> element is used. If there is neither, the body is used with every <header>, <nav>, <footer> and <aside> cut out. A site built with those semantic elements gets an exact boundary; a site built from generic <div> wrappers gets the best cut the markup allows.

Why two tools never agree

Disagreement between word counters is normal, and it has three sources. The first is the boundary above: one tool includes the menu and footer, another strips them, a third strips some of them by its own heuristic. On a long article the gap is a few hundred words; on a short service page it can be more than the article itself.

The second is how a "word" is cut. This counter treats any run of characters between spaces as one word, after the markup is removed. That makes 1031-exchange one word, $250,000 one word and a URL written out in the text one word. Other tools split on hyphens or punctuation, drop numbers, or count an ampersand as a word. Word processors apply their own rules again, so a draft that read 1,500 words in your editor can come back a few percent off here without anything being wrong.

The third is what the tool was served. A counter that renders the page in a browser sees text that JavaScript adds after load; one that reads the raw HTML does not. A counter that is blocked by a bot wall may be counting the wall. When two figures disagree, check the boundary first, the word rule second, and what was fetched third.

Required disclosures inflate the count

For a financial adviser, an insurance agency, a law firm or a medical practice, a large share of the visible words on every page can be text the firm is required or advised to carry: the risk statement, the "not an offer" language, the attorney advertising notice, the licensing lines, the privacy and accessibility links. That text belongs on the page. It does not make the page longer in any sense that matters to the reader, because it is the same on every page.

This is where a single whole-page number misleads. Picture a service page that reads 1,200 words in a whole-page counter, of which the firm's own explanation of the service is 700 and the rest is menu, footer and disclosures. The owner believes the page is substantial. The part that is unique to it is a little over half that. A page padded by footer disclosures is still thin; the counter's job is to show the padding, not to add it to the total.

On a well-built article the gap is modest. Willowdale Equity's break-even ratio article counts 2,064 words of main content and 2,516 on the whole page, so 452 words, about 18%, sit in the menu, the footer and the rest of the page furniture. That is the shape to expect. When the gap is larger than the main content, the page is mostly frame.

Server HTML versus JavaScript-rendered text

This counter reads the HTML the server sends and does not run the page's scripts. On a traditional site, and on any site that renders on the server, that HTML is the page. On a site that builds its content in the browser, the served HTML can be a nearly empty shell, and the counter will report a handful of words for a page that looks full in your browser.

That low number is a finding, not a malfunction. Google renders JavaScript, in a later pass than the first crawl. Most AI crawlers do not: Vercel's December 2024 analysis of crawler traffic found that the crawlers behind ChatGPT, Claude, Perplexity and Meta's AI fetched JavaScript files but did not execute them. A page whose words exist only after the scripts run is a page those crawlers read as the shell. If the main-content count here is far below what you see on screen, the text is arriving by JavaScript, and moving it into the served HTML is the fix.

How many words should a page have?

There is no correct length, and Google says so directly. Its guidance on helpful content lists, among the signs of writing for search engines rather than people: "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.)" A definition can be complete in 400 words; a comparison of two tax treatments may need 3,000. Advice on an ideal blog post length is content planning, not a ranking rule.

What a count is good for is spotting the extremes. A service page with 150 words of its own cannot answer the questions a prospective client has, however well written it is. That is what the thin-content check on this card flags: main content under 300 words. The figure is Verand's rule of thumb for pages on YMYL topics, where readers and reviewers expect depth, not a threshold any search engine publishes. Contact, about, privacy, terms and similar utility pages are exempt, because short is right for them.

Comparing against the pages that rank

The counter works on any public URL, so the most useful run is often not your own page. Count the main content of the pages that rank for your query and you learn what depth the topic has been given, which is a better guide than any general rule. Compare main content with main content: a competitor's whole-page figure inflated by a mega-menu tells you about their navigation, not their answer.

Then read the pages rather than matching the number. A 2,500-word page that ranks has usually earned it by covering the questions, the edge cases and the evidence, and a 2,500-word page that restates one point does not rank for long. Length follows coverage; it does not cause it. For the same reason this tool does not report keyword density. Older word counters list the most frequent terms and their percentages, and the claim that a target density helps rankings has never been shown.

Common mistakes

• Reading the whole-page figure as the article's length. On a short page the menu and footer can be most of it. Judge depth by the main-content count.
• Padding to a target. Adding sentences to reach a number produces the pages Google's guidance describes. Add the answer that is missing instead.
• Putting the content in a form. Some page builders wrap the whole page in a <form>. This counter removes forms before counting the main content, as Verand's audit does, so a page built that way reads as nearly empty here.
• Loading the article by JavaScript. Invisible to crawlers that do not render. If the counts here are near zero for a page that looks full, that is the cause.
• Counting hidden tabs and accordions as missing. They are not: text in the HTML counts even when collapsed, because no CSS is applied. Text fetched only when a tab is clicked does not.
• Treating every short page as thin. A contact page with 60 words is doing its job. The check skips utility pages for that reason.
• Comparing counts across tools. Each draws the boundary and cuts words differently. Compare pages with one tool.

SEO word count, in one line

Count the main content, not the page. Use the gap between the two figures to see how much of the page is frame, fix a main content that is thin by adding what the reader needs, and let the length fall where the topic puts it.