This site is a library of around seven hundred pages: what we fix, the services, the industries and niches we work in, answers to specific questions, guides, definitions and pieces like this one.
That scale is where most content operations start telling small lies. Not deliberately. It happens because writing a hundred pages that are genuinely different is hard, and writing a hundred pages that look different is easy. A template gets filled in. A statistic gets borrowed from an article that borrowed it from another article. A case study gets composited from things that could have happened. Each shortcut is small, and together they produce a site where nothing is quite false and nothing can be relied on.
So the rules here are written to be mechanical, because good intentions do not survive page four hundred. Some are editorial and some are enforced by a script that refuses to publish a page which breaks them. This is what they are, and where they could still fail.
No number we cannot stand behind
The rule that does the most work: no statistics, no benchmarks, no percentages presented as findings, no client results, no awards, no review counts, no prices.
This is stricter than it sounds. It rules out the entire genre of sentence that begins with a figure and a claim about what most stores do. Those sentences are persuasive, they are easy to write, and almost none of them can be traced to anything solid. When they can be traced, the underlying study is usually narrow, old, or about a different market than the reader's.
What is allowed is your own numbers, and worked examples with figures that are clearly labelled as invented. When you see a paragraph here that begins with a supposition, that is the convention: the numbers are there to show the shape of a calculation you should run on your own data, not to describe reality.
Also allowed are platform facts we are confident about: what a product feed requires, what a checkout can be configured to do, how a bidding system uses the values you send it. Those are checkable, and when they change we change the page.
Volume is where accuracy breaks, so the rules have to be mechanical.
Every page must carry specifics a neighbouring page could not
The second rule targets the failure mode particular to large sites: pages that are technically about different things and functionally identical.
So a page about one niche has to carry at least a few specifics that a neighbouring niche page could not truthfully carry. That niche's vocabulary, its buying process, its seasonality, the way its products are searched for, its advertising restrictions, its reorder cycle, the attributes that matter in its feed.
That rule is why writing this library is slow. If you cannot say something specific about a category, you should not have a page about it, and the honest response is to write fewer pages rather than to pad the ones you have.
It also applies within a page. Headings, opening lines and questions are not reused across the site. If two pages would naturally want the same heading, one of them has not found its own argument yet.
The reader-facing version of this rule is simple: if a page here could have been written about any store in any category, it should not exist.
We write about our own work, not about other companies
The third rule is that comparisons are between two options a store has, not between named companies.
We do not write about other agencies, we do not rank software brands against each other, and we do not publish the sort of comparison page that exists to catch searches for a competitor's name. Those pages are cheap traffic and they are almost always written by someone with an interest in the outcome, which makes them worthless as advice.
Where a comparison genuinely helps a store, it is between things the store is actually choosing between: one campaign structure or another, a threshold or a bundle, a subscription or a reminder, a redesign or a set of targeted fixes. Those have real trade-offs and no marketing interest attached.
The same rule governs what we say about ourselves. We do not claim to be better than anyone, because that is not checkable. We describe how we work, what we will not do, and how we charge, and those are all things you can hold us to.
It costs us a category of easy pages. It also means nothing here needs a disclaimer.
The build refuses pages that break the rules
Editorial rules that live in a document get forgotten. So the ones that can be automated are.
Every page in this library is a structured file, checked against a schema before it can publish. The schema enforces the shape: a description within a set length, a minimum amount of real body text in each section, the required fields present, a review date in the right format.
On top of that, a checker scans for the things we have decided not to say. Marketing filler words we do not use. Em dashes, which we avoid for consistency. Percentage claims in the pattern that usually signals a borrowed statistic. Links to pages that do not exist, so a related link never points at nothing.
A page failing any of these does not get a warning. It fails the check, and the build stops.
None of this makes a page good. A page can pass every automated check and still be dull or wrong, and that is what editing is for. What the machinery does is remove a class of failure that gets more likely the more pages you have and the more tired the person writing them is.
Review dates, corrections and removals
Ecommerce advice ages badly. Platform features change, advertising policies change, feed requirements change, and a page that was accurate two years ago can be quietly wrong today.
So every page carries the date it was last reviewed, visible to you rather than buried in metadata. It is not a publication date. It is a claim that someone checked the page against reality on that day, which is the more useful fact.
When something is wrong, we correct the page rather than deleting it and hoping. When a piece of advice is no longer right because a platform changed, the page says what changed. When a page is genuinely obsolete, it goes, and anything pointing at it is updated so you do not land on nothing.
We would rather hear about errors than discover them. If a page here contradicts what a platform actually does, or contradicts another page on this site, that is worth telling us about, and the fix goes in.
Consistency across several hundred pages is a maintenance job, not an achievement. It has to be done repeatedly or it decays.
Where this could still fail
It would be against the spirit of the exercise to present all this as a solved problem. Here is where it is weakest.
Opinion ages. Pieces like this one argue for an approach, and an argument that is right today can be wrong after a platform change. The review date helps, and it does not fully solve it.
Worked examples drift. Numbers chosen to illustrate a calculation reflect the prices and costs of the moment they were written. They are labelled as invented, but a reader skimming can still take them as typical.
Judgement is not checkable by a script. Whether a fix should come first for a particular kind of store is our opinion, formed from the work we do. We try to show the reasoning so you can disagree with it, but reasoning presented well is persuasive whether or not it is correct.
And we can simply be wrong about a platform detail, particularly in a fast-moving area.
What we can promise is the process: rules applied to every page, checks that fail the build, dates you can see, and corrections rather than defensiveness. The rest is work.