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
- Diffs. Every change is a commit. We can say what changed, when, and why.
- Version stamps. Each page renders its own version and date, so support can quote the exact version a customer agreed to.
- 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.
- 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.
Top comments (0)