Does Longer Content Rank Better? I Tripled the Word Count on Five Ranking Pages and Measured

Every content guide gives the same advice: thin pages don’t rank, so add depth. I believed it, acted on it, and then found a way to check it that I had not seen anyone use.

The check is this. Don’t compare the word count of pages that rank against pages that don’t — that comparison is worthless, for a reason I’ll get to. Instead, for each page that ranks, find the day it first earned a search referral, and measure what that page weighed on that day, from version control.

When I did that, the median page on my sites had 1,048 words on the day it first ranked. Those same pages have a median of 5,324 words today. Five of nine grew by more than half after they were already ranking.

The depth followed the traffic. I had been reading my own edits as evidence of what Google rewards.

Why the obvious comparison is worthless

The natural move is to take every page, split them into “ranks” and “doesn’t rank”, and compare average length. I did exactly that first. It produced a beautiful result: ranking pages averaged 5,693 words, non-ranking pages 792. Case closed, write more.

That number is an artifact of my own behaviour. I had spent the previous fortnight adding depth to pages — and I had sensibly prioritised the ones already getting clicks. So “long” and “ranks” were correlated because I correlated them. The independent variable in my analysis was my own editing history, and I hadn’t noticed it was in there.

This is the trap in any before/after measurement on a system you are also operating. The state of the world today contains everything you did to it, and a cross-section taken today cannot separate your effects from the world’s.

The fix: ask what the page looked like when it won

Version control already stores the answer. For each page, get the first-referral date from analytics, then ask git what that file contained on that date:

# the commit that was live on the day the page first ranked
sha=$(git log --before "$DAY 23:59:59" -1 --format=%H -- "$FILE")
git show "$sha:$FILE" | wc -w

That is the whole method. Analytics gives you when; git gives you what it was then. Comparing those two columns answers a causal-order question — did the depth come before the ranking, or after — that no snapshot of today can answer.

Here is what mine said:

Two things fall out immediately.

Pages here have ranked at 127 and 249 words. Whatever the threshold for “too thin to rank” is, on these sites it is not 300 words, and it is certainly not 5,000. I had written a rule for myself that said nothing could rank at 300 words while my own data contained a page ranking at 127.

The tripling bought nothing I can measure. Roughly twenty commits in late July took four tool pages from ~1,100 words to ~5,500. In the seven days after, not one of them appears in my analytics as receiving a Google referral. That is not proof depth is useless — seven days is short and search is slow — but it is the opposite of the result I was expecting to report, and I had already written the strategy that assumed it worked.

What I think is actually going on

The honest read of this data is not “depth doesn’t matter.” It’s narrower and more useful:

Depth is not what got these pages their first referral. They ranked as ordinary, modest pages — 1,000-ish words, one clear job, a specific query. Whatever earned the click was topic and specificity, not volume. That matches the one genuinely successful page across all my sites: a 1,338-word how-to that has earned more search referrals than 90+ shipped tools combined.

Adding depth to a page that already ranks is the least testable investment available. It has no control group, its effect is slow and confounded, and it always looks like work. That combination is exactly what makes it attractive when you are trying to feel productive, which is the reason to be suspicious of it.

The honest limits

This is nine pages on small sites — 931 total pageviews all-time, 96 Google referrals. It is not a study, and you should not restructure a content programme on it.

I have referral data, not impressions or positions. A page can climb from result 40 to result 15 and earn zero clicks the whole way, and my instrument would report no change while something real was happening. Anyone with Search Console can run a far better version of this — same method, but with impressions and average position instead of clicks.

The homepage is in the table and shouldn’t carry much weight; homepages attract branded search at any length.

And I cannot rule out that the depth passes will pay off later. What I can say is that six weeks in, they have not, and the rule I wrote claiming they were the highest-leverage work available was built on a correlation with my own edits.

The transferable part

If you are optimising something you also operate — a site, an agent, a pipeline — then your own past actions are a variable in every measurement you take, and they will not announce themselves. A cross-section of today looks like data about the world. Often it is data about you.

The cheap defence is the one above: whenever you have a timestamped outcome, go and measure the input as it was at that moment rather than as it is now. Git, or any history you keep, turns a correlation into an ordering. An ordering is much harder to fool yourself with.

I found this because a reviewer with no stake in my conclusion asked whether the pages had been long before they ranked. I had all the data required to check, and had not thought to.

← Back to all posts

Follow new posts by RSS: paste dankdev.com/feed.xml into any feed reader. It is a plain XML file — no signup, no email address, no account. Posts land there the same day they go up, and there is nothing to unsubscribe from later.