A blog post is for arguments. Facts belong somewhere else.

A question that needs a current fact is not a blog subject. It is a page, and usually a page you already have. The blog is for the things that need arguing, and the quickest way to fill an archive with pages nobody needed is to stop noticing the difference.

A post carries a date, and the date is a promise

Every post here prints the moment it was generated. That dateline does real work: it tells you how old the thinking is, and for an argument, age is context. A piece from 2024 on how buyers evaluate content is still worth reading now.

Facts do not survive the same treatment. A post stating your price, your integration list or your rate limits is correct on the morning it publishes and silently wrong some time later. Nobody schedules a review of a two-year-old post. It sits there, dated and confident, answering with something you stopped standing behind a year ago.

The right home for a fact is a page somebody updates when it changes, because sales links to it and a customer complains the same day it breaks. A blog post has no such alarm attached. It has a date, which looks like currency and is not.

Your own product page is one of the "other pages in search results"

Google's guidance on creating helpful content asks something more awkward than it first appears: does the content provide substantial value when compared to other pages in search results? Most people read that as a question about competitors. Your own pricing page and docs are in those results too.

When a post covers ground a product page already owns, you have not added coverage. You have added a second, weaker answer to a question you were answering well, and asked a ranking system to choose. Sometimes it chooses the post. That is worse than losing the query outright, because the reader arrives at commentary when they came for the specification, and leaves.

The same guidance asks whether content is made primarily to attract visits from search engines. A backlog assembled from keyword volume answers yes whoever writes the words, which is the argument we have made about machine authorship: the failure is the page nobody needed, not the author.

The test is whether a competent person could disagree

One question does most of the triage. Could someone who knows your business read this and disagree?

If they could, if the subject turns on a judgment call or a position that costs you something to hold, it is a post. It will still be readable in three years, because arguments age into context rather than into error.

If the only available responses are "correct" and "incorrect", it is a fact. There is no argument inside a list of supported file formats, and wrapping eight hundred words around it does not create one; it buries the list. The cases in between resolve the same way. The fact goes on the page, and the reason for the fact becomes the post.

Routing a subject is not rejecting it

Few of these subjects deserve dropping. They deserve splitting at the seam between the answer and the argument, and the blog takes the half that stays true.

What does it cost goes on the pricing page. Why we price by publishing cadence rather than per seat is a post, because a reasonable operator would price it differently and we have to defend the choice. Which languages are supported is a line of product copy. Whether to publish in a language before you sell in it is a real disagreement with money attached. How to approve a draft belongs in the documentation. What good approval looks like does not, because most teams get it wrong in a way no interface corrects.

The product page gets the thing that changes. The post gets the thinking behind it, which changes far more slowly and is the part a competitor cannot copy off your website in an afternoon.

The filter has to be written down, because the engine will not supply it

A human writer applies this filter without being asked, largely by accident. Writing is slow and unpleasant enough that a subject with nothing to argue tends to die on the way to the page. The writer stalls, cannot find an angle, moves on. Scarcity was doing the triage, and nobody needed a policy about it.

An engine has no such friction. Hand it "our supported integrations" and it returns nine hundred competent, on-brand words on schedule, then does it again next week. Nothing errors. The archive fills with pages that are accurate, fluent and unnecessary, and the first symptom arrives two years later as a maintenance problem, by which point deletion is a bad first move and you are left rewriting.

So the triage that happened by attrition has to move into the brief and be said out loud. Ours is one line: the blog takes subjects that survive disagreement. Everything else gets an address where the facts are maintained.

What changes if you accept this

Your backlog gets shorter and better. Subjects you saved because they were easy to write turn out to be product-page copy, and the ones you avoided because they demanded a position turn out to be the whole blog.

The test costs a minute per subject, and it is worth running on what you have published rather than only on what is queued. If a post could be replaced by a paragraph on a page you maintain, it is not earning its place in the archive. It was never the writing that put it there.