Nobody reads your blog. They read your documentation

A page that answers a question people type is worth roughly forty times a page about your company. Not as a slogan. You can calculate it, and the calculation is why I stopped writing a blog.

The arithmetic of a page that ranks

Traffic from search is three numbers multiplied together. How many people search the phrase, what share of them click your result at the position you hold, and what share of those sign up.

Click through rates by position are well documented and roughly like this, give or take by industry.

One page, one phrase searched 400 times a month.

Note the shape. Dropping from first to third costs you 61 percent of the traffic. Position ten is worth about seven percent of position one, which is why ranking eighth for a big phrase is worth less than ranking first for a small one.

Twenty four pages, each averaging 400 searches a month at around position three, gives about 1050 visitors a month. That's roughly what mine does.

Now do the same sum for a blog post

Our blog had nine posts. Our roadmap for the year. A post about why we built the product. Two release notes. One about our stack.

Search volume for those phrases is zero. Not low. Zero, because nobody searches for the roadmap of a company they've never heard of.

So the first term in the multiplication is zero and it doesn't matter what the other two are. That's the whole analysis. A blog post about your company can only reach people who already follow you, which means it isn't a channel, it's a newsletter with worse delivery.

Left describes us. Right describes a problem somebody has open in another tab.

Why the docs pages take an hour and the blog took a day

A docs page takes an hour because I already know the answer. I'm writing down something I've explained three times in support.

A blog post took half a day because I had to invent a reason for it to exist. That difference isn't discipline, it's that one of them has source material and the other doesn't.

Finding your pages

Open your support inbox and read the subject lines, not the bodies. The recurring ones are your list, already in priority order, already in your customers' words.

That's the whole method. Every page I have came from a ticket I'd answered at least twice, and the ones that took off are the ones where I resisted improving on the customer's phrasing.

That resistance matters more than it sounds. Somebody with a merged header cell problem does not search for spreadsheet import best practices. They type the words in front of them. Every editing pass makes your title more respectable and less findable.

Second source is your own swearing. When something in your domain costs you an hour and a failed search, that's a page, because if it was hard for you to find it's hard for everyone.

The discipline it takes

The page has to be genuinely complete. Somebody must be able to solve their problem by hand, without your product, and leave satisfied.

Every instinct pushes the other way. There's always a moment where you think you could stop just short, describe the problem thoroughly, and make the solution the thing they sign up for. Don't. That page reads as an advert inside two sentences and the people who'd have trusted you can tell.

The mechanism only works because the reader gets what they came for. Some of them then decide they'd rather not do this by hand every month, and those are the ones worth having.

My best performing page explains how to reconcile two bank feeds manually. Eleven steps. No pitch, one line at the bottom saying what I build. It brings more signups than the other 23 combined, and the tedium is doing the selling. Anybody who reads eleven steps has already worked out that they don't want to do this every month.

What I wouldn't do

I wouldn't write pages for problems my product doesn't solve just to catch traffic. I tried three on adjacent accounting topics. They brought visitors who bounced. Traffic that can't convert costs you writing time and gives you a number that looks better.

I wouldn't chase volume either. Twenty four pages isn't many. Each covers something I've personally been asked about more than twice, which is a small set, and when I run out I stop rather than padding.

The cost nobody mentions

A stale docs page is worse than no page. Somebody follows it, it doesn't match what they see, and now they distrust the product as well as being stuck.

When we changed the import screen last spring I had to revise eleven pages. Two days. I found two more that had been quietly wrong for months.

So forty pages isn't forty finished things, it's a maintenance commitment that comes back every time the product moves. It's still the best hour I spend. Just go in knowing it's an hour that recurs.