Preview, Draft, Publish: The Three States Every CMS Gets Wrong

A reviewer asks for a preview link, so you send one. Six weeks later somebody searches a phrase from that page and finds it sitting in the results, at a URL nobody meant to publish, carrying the headline the client rejected and a paragraph that ends mid-sentence. Nothing broke. Every component did exactly what it was configured to do.

Almost every argument about CMS preview and drafts is really an argument about three states that share one workflow and get implemented as one field with three values. They are not points on a slider. They are three different kinds of claim: a draft is a statement about permission, a preview is a promise about rendering, and publishing is a commitment to a URL.

Get those definitions apart and most of the familiar problems dissolve. Leave them blurred and you get the failure above, plus its quieter siblings: the preview that lies about what the page will look like, the review link nobody can open, the unpublish that destroys the only copy. This piece defines each state, shows where systems fold them together, and ends on the one that does lasting damage.

Three states, three different claims

A draft says: nobody outside this list is meant to read this yet. It is a permission claim, and permission claims are enforced by access control rather than by a flag on a record. If a draft can be reached by anyone who guesses a URL, it was never a draft. It was an unlinked page.

A preview says: this is what publishing would produce. That is a rendering claim, and it is only as good as the distance between the preview path and the production path. Every difference between the two is a place the promise can fail.

And publishing says: this is our position, at an address we will stand behind. It is a commitment about a URL, which is why publishing should always leave a record of who committed it and when. That record is not paperwork. It is what you need on the day a legal page says something nobody remembers approving.

Where systems fold two states into one

Nobody sets out to blur them. It happens because one implementation is cheaper than three, and because the blur stays invisible until the day it becomes expensive.

The draft that is only a flag

The cheapest implementation puts a status column on the same row as the live content. Editing the draft edits the record the site reads from, and the only thing standing between an unfinished sentence and the public is a query filter. Any cache warmer, search index, feed, or slightly different query written by a developer in a hurry can step around that filter. It also makes unpublishing destructive, because there is no second copy to fall back to. Teams in this position learn to be afraid of their own editor, which is one reason every small change ends up on a developer’s desk.

The preview that is really production

The other common fold puts preview on the live site behind a query string. It renders the draft through the production template, which is the right instinct, and then inherits every property of a public URL: it can be cached, shared, logged in analytics, and crawled. A parameter is not a permission boundary. It is a suggestion. Frameworks that treat preview as an explicit mode rather than a URL trick handle this properly, and the Next.js documentation is worth reading on how that mode is entered and left.

There is a third shape, and it is the one we reach for most often, because it gives the states physical meanings rather than semantic ones. In a repository-backed workflow a draft is a change that has not been committed, preview builds from that change, and publishing is the commit. Acrosite works this way: it gives editors a structured workspace, generates the required files, commits them to GitHub and triggers the configured deployment. The boundaries stop being conventions somebody has to defend and start being facts about where the bytes are. Our parent company has written about the same problem from the editor’s side in where drafts live and what stops them.

Preview fidelity, and the ways a preview lies

A preview is a prediction. Its only value is accuracy, and accuracy is not what most preview panes are built to optimise. Here is where the prediction usually goes wrong.

• Different data. The preview renders one entry, while production renders that entry inside a page assembled from navigation, related items, promotional slots and whatever the last campaign left behind.
• A different rendering path. An editor pane that approximates the template with its own stylesheet is not a preview. It is an illustration, and it will disagree with production on exactly the things nobody checks.
• A different viewport. Preview panes are narrow columns on wide screens. Most readers are on a phone. A heading that fits the pane can run to four lines on the device the traffic actually arrives on.
• A different session. The editor is signed in, so personalised blocks, gated sections and logged-in navigation all resolve differently than they will for a first-time visitor.
• Missing third-party weight. Consent banners, embeds, tag managers and chat widgets are often stripped from preview. They are also the things most likely to move layout and slow the page down.

The rule that fixes most of this: preview should be production’s renderer running against the draft’s data, and nothing else different. Same templates, same layout, same viewport controls, same scripts. Anything stripped out for convenience is a category of bug you have agreed to discover after publishing. Fidelity also depends on how content is stored: when a page is one large field of pasted markup, preview is the only way to know what it will do, whereas a content model with real fields makes most of the output predictable before anyone looks at it.

Shareable drafts, and what a review link must carry

Reviewers rarely live inside the CMS. Legal, a subject expert, the client, the person who actually knows the product: none of them want a login for a tool they will open twice a year. So the review link becomes the real interface for the most consequential step in publishing, and it is usually the least designed part of the system.

A review link should tell its recipient four things without anyone having to explain: that this is a draft rather than the live page, which version they are looking at, where to send a change, and when the link stops working. Carry none of those and comments arrive as screenshots in a chat thread, while the trail of who approved what disappears. That trail is what version control gives an editor, and it is also why a reviewer needs a defined pass rather than an open invitation to react, a point made well in the reviewer’s pass.

The preview URL nobody locked

This is the failure worth planning against, because it persists after the mistake is fixed. An indexed preview can outrank the page it was previewing, expose pricing that was never agreed, or leave an unapproved claim in a search result long after the words themselves changed. Removing it is slow, and the cache is not yours.

1. Put it behind something real. Authentication, or a signed token tied to one document and one expiry. A long random path is obscurity, and obscurity leaks the first time somebody pastes it into a ticket.
2. Send a noindex header, not only a tag. An X-Robots-Tag of noindex on every preview response covers assets and non-HTML files that a tag in the document head cannot reach.
3. Do not rely on a disallow rule. Blocking a path in robots.txt tells crawlers not to fetch it, which is not the same as telling them not to list it. A blocked URL linked from somewhere else can still appear in results, without a description.
4. Keep preview off the production hostname. Separate the origins so that no cache, no sitemap generator and no internal link can promote a preview into the live site by accident.
5. Expire the link and mean it. A token with no end date is a permanent public URL with extra steps. Short lifetimes are annoying exactly once, which is cheaper than the alternative.
6. Check that it worked. Search for the preview hostname, read the crawl logs, and look at what search console reports. This takes minutes, and it is the only step on the list that produces evidence.

Google’s own introduction to robots.txt is explicit that the file manages crawling rather than indexing, and the distinction is worth internalising, because so many staging leaks come from believing otherwise. If a preview environment is already indexed, the fix is a proper removal plus a noindex response, not another disallow line. That work sits with technical SEO, and it is far cheaper to prevent than to unwind.

A preview link is a publication with a smaller audience and no record. Treat it as one and most of these problems stop happening.

The multiplier nobody budgets for

Three states are manageable. Three states across seven locales and two brands is a matrix, and that is where most editorial workflows stop fitting on a whiteboard. A page can be published in English, in draft in German and scheduled in French at the same moment, so "is this page live?" no longer has a single answer. Any system running multiple languages without a second website has to decide whether a locale may publish ahead of its source, and decide it deliberately rather than discovering the answer from whatever the software happens to allow.

The same multiplier applies to component-level content. If a shared block appears on forty pages, editing it puts forty published pages into an unstated condition where part of what a visitor sees has been approved and part has not. Most platforms have no word for that condition, which is precisely why it causes trouble.

Scheduling is a fourth state pretending to be a date field

Scheduled content is neither draft nor published. It is a promise that something will change with no human present, and it is the state most likely to fail silently, because failure looks identical to nothing happening. On a database-driven site the page appears when a query starts including it. On a statically built site nothing appears at all unless a job runs, and a job that stopped running produces no error anyone reads.

So treat a scheduled publish as an operation with a monitor rather than a checkbox with a date. Somebody should be told when it fires and, more usefully, when it does not. The morning of a launch is a poor time to learn that the scheduler quietly stopped three weeks ago.

Five questions to put to a platform before you buy it

Ask these during the trial, with a real page and a real reviewer, instead of reading the feature list. Every one of them has produced an eliminating answer at least once.

1. Is a draft a separate record, or a flag on the live one? If it is a flag, ask what happens to the published version while somebody is editing, and what unpublish actually deletes.
2. Does preview run the production renderer? Not a similar one. The same one. Ask what is excluded from preview and why, then test the excluded thing first.
3. How is a preview link secured and expired? Look for signed tokens with an expiry and a noindex response header. A random path with no expiry is a permanent public URL.
4. What does the audit trail record on publish? A name, a timestamp, a diff and a way back. Anything less leaves "who approved this wording" unanswerable on the day it matters.
5. What happens when a scheduled job fails? Silence is the wrong answer and the most common one. Ask who gets told, and through which channel.

Where we would start

Write the three claims down for your own site, one sentence each, and make sure everybody who publishes agrees with them. That exercise takes twenty minutes and settles arguments that otherwise recur every quarter, because most disagreements about workflow are really disagreements about what a word means.

Then test the boundary rather than the feature. Open a preview link in a browser with no session, from a network nobody has signed in from, and see what comes back. Search for your staging hostname. Ask the platform to show you the audit record for a page somebody changed last month. Those three checks find more than a week of evaluation does, and they fit comfortably inside the discovery phase of an ordinary website design and development engagement.

One concession before anybody rebuilds anything: a two-person team publishing a page a week does not need this machinery, and imposing it slows them down against a risk they do not carry. The three states earn their cost when more than one person can publish, when someone outside the team has to approve, or when a page can create a legal or commercial obligation. Below that line, a draft, a build and a careful pair of eyes is a respectable system. Above it, guessing is how preview links end up in search results. If you are unsure which side you are on, describe your publishing workflow to us and we will tell you where it leaks.