A Tiny Static Build for Policy Pages, Not a Plugin

Policy pages are the least glamorous part of a store, and the most likely to be wrong. Ours drifted for months: the returns window in the footer said one thing, the returns page said another, and the privacy page still described a checkout flow we had replaced. We fixed it by rebuilding the policy set as a static output rather than CMS content.

The problem with editing policies in a page builder

A page builder stores markup, not meaning. Every edit is invisible in review, every change is a diff nobody keeps, and there is no way to answer a simple question: what did this page say on the day an order was placed?

That last question matters. When a customer disputes a return window, the answer is not what the page says today. It is what it said when the order was placed.

What we built

Four HTML files, one shared stylesheet, one build step:

policies/
  privacy.html
  returns.html
  delivery.html
  contact.html
  _layout.html   # shared shell, injected at build time
  build.js       # inlines layout, writes dist/

The build step inlines a shared header and footer, stamps a version string, and writes the result into the deploy directory. Nothing clever. It runs in under a second, and the output is a set of plain pages that any static host will serve.

Why this beats a plugin, for us

1. Diffs. Every change is a commit. We can say what changed, when, and why.
2. Version stamps. Each page renders its own version and date, so support can quote the exact version a customer agreed to.
3. No runtime surface. A policy page has no forms, no sessions, no database calls. Static output removes a category of failure that would otherwise show up at the worst moment.
4. Portability. The same files deploy anywhere. We are not locked into a plugin's template system.

What we lost, and how we handled it

Non-technical edits now need a person who can open a pull request. That is a real cost, and it is why we keep a plain-text copy of each policy in the repository with a short "what changed" note above every edit. Anyone can propose wording; the merge is the only technical step.

We also lost the rich editor's ability to paste formatted text. That turned out to be a feature: our policies got shorter and more direct once they had to survive Markdown review.

The schema part

Each page carries the organisation's contact details and the same policy language that appears on the site, so search engines and assistants read the same text a customer reads. We do not publish separate "SEO copy" for policies. One text, one source.

The measurement

Support tickets that mentioned a policy contradiction: eleven in the month before the rebuild, two in the month after. Not a controlled experiment, and we changed other things too, but the direction matched what we expected.

If you try this

Start with the returns page. It is the one customers quote at you, and the one most likely to disagree with the footer. Then the privacy page. Then delivery. Leave the about page for last; it is the only one nobody disputes.

Our own set is public: privacy policy, returns, and the guides index. If you have built something similar and hit a wall we have not, the contact page is open.

LoveyDovey runs a small Indian online store; the policy set described here is public at lovedovey.com.