Should your startup have a blog?

A blog is a format: dated entries, newest first, usually written to be read once. That format suits some things and suits most product content badly.

Most of what a product needs to publish is in the right column: pages that answer a question and get refreshed rather than replaced. Google's freshness systems favour recent content on queries where recency matters, which is news and prices, not "how to import a csv".

These are not writing problems. They are shape problems, and no amount of effort fixes them from inside the blog.

1. News nobody searches for. "We raised a round", "we are at the conference", "meet our new hire". Real to you, searched by nobody, and it is most of what startup blogs contain.
2. Thin posts written to a schedule. Somebody committed to weekly, and by week six the posts are four hundred words of general advice. That is exactly what Google's scaled content guidance describes.
3. Abandonment. The last post is from fourteen months ago and every visitor can see it. A blog that stops advertises that the company stopped.

Three questions for each piece you are considering. If it fails the first, do not write it; if it passes the first and fails the others, write it as a page rather than a post.

1. 1

   Does somebody search for this?

   Not "is it interesting". Type the question into Google as a buyer would phrase it. If nothing comes back, nobody is looking.

2. 2

   Will it still be true in a year?

   If yes, it is a page: no date in the URL, refreshed rather than replaced. If no, it is a post, and that is fine as long as you know it will fade.

3. 3

   Does a page of yours already answer it?

   If it does, improve that page instead. A second page on the same search splits the impressions and neither wins.

Almost everything a product wants to publish passes the first two as a page. That is the argument: not "do not write", but "do not write it in a format built for news".

A library: undated pages grouped by subject, each answering one search, linked from a hub, refreshed on a schedule. Structurally it can live at /guides/ and look nothing like a blog.

Keep a blog alongside it if you have genuine news or a genuine voice people follow. Release notes, studies and opinions belong there, and they can link to the library where a reader wants the method rather than the story.

There are products where the blog is the channel, and they have something specific in common: a voice people follow, or news people wait for.

• A founder who writes well and has an audience that reads them. The blog is distribution for the voice, and the links it earns are real.
• A product where the release notes matter to users, so the changelog is read like a feed.
• A company publishing original data regularly, where each study is an event with a date.
• A category that moves monthly, where a post about this month is genuinely what people search.

Notice what is not on that list: "we heard content marketing works". If the reason to start is that everyone has one, the blog will hit failure two by week six.

Do not delete it in a weekend. Audit it, decide per post, and act on the data rather than the feeling.

1. 1

   Export twelve months of Performance data by page

   Clicks and impressions per URL. Add the internal links and the last update date from a crawl.

2. 2

   Sort into four piles

   Ranking and accurate: leave alone. Ranking and stale: refresh. Not ranking but on a real search: rewrite as a page. Not ranking, no search, no links: remove.

3. 3

   Merge the near-duplicates

   Three posts on the same subject become one page at the strongest URL, with 301s from the others.

4. 4

   Move the keepers out of the date structure

   If the URLs carry dates, decide once whether the migration is worth the redirects. It usually is when the posts still earn clicks.

5. 5

   Leave the news where it is

   Release notes and announcements can stay dated. They are doing their job by being dated.