A promise is harder to check than a number

There are two ways a sentence on a product page can stop being true, and they are not variations of one problem. The first is a number that moved: you said three working days, the shipping profile now says five. That one is unpleasant but tractable, because a number has a counterpart. Somewhere there is a field holding the real value, and a person or a script can hold the two up against each other and see the gap.

The second kind has no counterpart. "Free returns." "Gift wrapping available." "We can engrave it." "Next-day delivery to most of the country." Each of those is a yes, and a yes has no value to compare with. It is not wrong in the way 5 is wrong when the answer is 3. It is either still backed by something or it is not, and nothing on the page can tell you which.

What is actually behind a yes

Every promise like that rests on something you did once and have probably stopped thinking about. Free returns rests on a courier contract with a returns rate built into it. Gift wrapping rests on a box you still have in stock and someone with ten spare minutes at packing time. Engraving rests on a machine that works and a person who operates it. Next-day delivery rests on a carrier service that is still enabled in your shipping settings and still collects from your postcode.

None of those things announces itself when it changes. A courier contract lapses on a date in an email from last year. The gift boxes run out on an ordinary Tuesday and get reordered or do not. A carrier quietly drops a service level in your region. In every case the thing that changed was operational and the thing that broke was editorial, and the two have no connection at all.

Why the usual checks cannot see it

This is the part worth being precise about, because it is the reason diligent sellers still get caught. If you have ever reconciled your copy against your data — and it is a good habit, which is the whole argument of an earlier post on this blog — what you built was a comparison. Copy says X, system says Y, flag the difference. That machinery is genuinely useful and it is structurally incapable of seeing a promise, because there is no Y. The field it would read does not exist. So the check runs, finds nothing, and reports that everything agrees.

We ran into exactly this on 21 October 2026, in our own code. A check that reads this site's public pages had been widened the day before to cover every operational setting the product has — all forty-seven of them, derived automatically so a new one cannot be forgotten. It was a real improvement and it was still blind to nine of the things it now covered, because those nine are switches rather than dials. The question the check asks is whether a published sentence states a setting's value, and a switch has no value a sentence could state. One of those nine turned out to be holding up a promise on ten of our own pages.

The question that does work

Stop asking what a promise says and start asking what would have to be true for you to keep it. For each claim, name the thing behind it — the contract, the stock item, the person, the carrier option, the machine — and write that down next to the sentence. You now have a list of dependencies rather than a list of sentences, and dependencies can be checked, because each one has an owner and most have a renewal date.

• Returns and exchanges — a courier contract or a returns portal subscription, usually with an annual date on it.
• Gift wrapping, personalisation, engraving, hand-written notes — a physical consumable plus labour at packing time. The first runs out; the second disappears when you get busy.
• Delivery speeds and coverage — a specific carrier service, enabled per region. Carriers change what they offer without telling the people writing listings.
• Anything described as available on request — this one is almost always a person, and it stops being true when that person is on holiday rather than when anything is reconfigured.
• Warranties, guarantees and any 'we will make it right' language — the most expensive to break, and the least likely to have anything systematic behind it.

Then do the one thing a number never needs: check that nothing else on your site quietly contradicts it. A promise lives in prose, and prose spreads — the same offer gets restated on a policy page, in an FAQ, in a banner, each time slightly differently. A number restated twice is simply two copies of the same figure. A promise restated twice can end up being two different promises, and a reader finding both will believe the smaller one. We hold our own copy to that rule for the same reason we are careful about what counts as a report of a wrong render: two incompatible readings of one promise are worse than either reading alone.

The smallest version of this

If the full exercise is too much, do the cheap one. Read your own product page as a customer who intends to take you up on every single offer in it — all of them, today. Where you feel a flicker of doubt about whether you could actually deliver, that is the list. It is usually three or four sentences, and they are rarely the ones you would have guessed, because the promises you worry about are the ones you are already managing. The dangerous ones are the ones you stopped noticing years ago.