What a Content Workspace Should Do the Day After Launch

The site launches on a Thursday. The migration held, the redirects resolve, everyone is pleased, and somebody books a retrospective. The following Monday a colleague asks where the pricing copy is edited, and whether the launch announcement belongs under news or under insights. Nobody has an answer, because nobody was asked that question at any point during the project.

That gap is the subject here. A launch is a milestone; publishing is a job, and the day after launch is when the real workload starts. Content operations is the unglamorous name for that workload, and it is almost never specified, budgeted or handed to anybody in particular.

Our position, stated so you can argue with it: most regret about a CMS is an operations gap wearing the costume of a feature gap. Teams ask for a different tool when what they need is a queue, an owner, and a decision about what happens to a page that has stopped being true.

Launch is where the workload starts

Think about what a site actually needs during its first ordinary year. A handful of new pages. A legal update. A service description that changed because the service changed. Three pages that quietly stopped being true. A set of images somebody wants replaced. One page nobody visits and two people defend.

None of that is a project. All of it is work, and all of it arrives without a budget line. A build has a start and an end, which makes it easy to fund and easy to celebrate. Publishing has neither, which makes it institutionally awkward: it belongs to nobody in particular, gets paid for once, and reappears every single week regardless.

By then the build team has usually moved to the next thing. This is where website maintenance earns its keep, and it is worth naming plainly rather than leaving implied, because the alternative is that every small change becomes an escalation and every escalation makes the next person reluctant to ask.

The four jobs a workspace has to carry

Reduce content operations to its irreducible parts and you get four jobs. Publishing, refreshing, retiring, reporting. Everything else that appears on a content plan is a variation on one of them.

Notice that three of the four concern pages that already exist. Most content plans are entirely about the first row, which is why sites get bigger without getting better, and why the second year always feels heavier than the first.

Publishing and refreshing

Publishing is a queue, not a calendar

A calendar says what goes out on which date. A queue says what is next, who is holding it, and what it is waiting on. Calendars look better in a deck and break the first time something slips, because one missed date makes the whole grid wrong and people stop reading a grid that is wrong.

So the workspace has to show state. Which drafts exist, who has each one, what is waiting on a review, what is waiting on an image, what is approved but unscheduled. If answering "what is stuck" requires a meeting, the system is not carrying the job and somebody is compensating for it in their head.

Publishing also needs a floor rather than a target. One page a fortnight that somebody genuinely wanted beats a stated commitment to four a month that nobody has time to write and everybody feels guilty about. Content and organic growth work is mostly the discipline of holding a modest floor for a long time, which is far less exciting and far more effective than a quarter of enthusiasm.

Refreshing is the job nobody plans for

Every page has a decay rate, and the subject sets it, not the writing. Pricing and product pages go stale when the offer changes. Guides go stale when the tool they describe ships a new interface. Policy pages go stale on a date somebody else decides. A piece of opinion barely decays at all.

So attach a review interval to the page type at the moment you define the type, rather than to individual pages as an afterthought. Then the workspace can answer, without anybody building a spreadsheet, which pages are overdue and who owns each one. That single view replaces most of what a content audit is usually hired to produce.

A refresh is not a rewrite. Read the page against the question it exists to answer, correct what is now false, cut what has become filler, add what the last year taught you, and leave the URL alone. Writing a page that answers a query is the standard to refresh against, because most stale pages have not become wrong so much as they have drifted into circling the question.

The temptation to resist is refreshing whatever is easiest to refresh. Prioritise by consequence instead: pages that would embarrass you if a customer read them this morning, then pages people use to make a decision, then everything else. The easy ones will still be there.

Retiring and reporting

Retiring is a decision, not a delete

Every site accumulates pages with no remaining job: an event that already happened, a service you stopped offering, three near-identical posts written by three people in three different quarters, a campaign landing page that outlived the campaign by years.

There are four honest options for such a page, and choosing between them is the actual work. Keep it and update it. Merge it into a stronger page and redirect. Redirect it without merging, because it holds links but nothing worth carrying. Or remove it properly and let the URL answer as not found. Deleting quietly and leaving nothing behind is the only option that reliably costs you something.

Whichever you pick, the redirect log is the artefact that has to survive. It is the record of where things went, and it outlives everybody who made the decisions. Keep it in the repository or inside the workspace itself, never in one person’s spreadsheet and never only in a server configuration nobody reads.

Retirement has a mechanical tail as well. A removed page has to stop being linked internally, stop appearing in the sitemap, and stop being requested by anything you control. Crawl, render and index is where those consequences surface, usually a few weeks after somebody assumed the job was finished.

Reporting closes the loop

Reporting here does not mean a dashboard. It means a short, regular reading of what the content did, ending in decisions: this page gets refreshed, this pair gets merged, this subject deserves another page, this idea gets dropped and nobody has to feel bad about it.

The failure mode is reporting that describes instead of deciding. A monthly deck of charts nobody acts on is an expensive way to feel informed. If the report does not change the queue, it is not part of the operating rhythm; it is a ritual with a slide template.

Most CMS regret is a content operations gap

When a team tells us the CMS is the problem, the complaints they list are usually not about the CMS. Here are the five we hear most, with what is normally underneath them.

• "Nothing gets published." Almost always there is no queue and no owner, so publishing only happens when somebody escalates. A new tool inherits the same silence within a month.
• "We do not know what is out of date." No page type carries a review interval, so nothing is ever overdue by definition. This is a modelling decision, not a software limitation.
• "Every change needs a developer." Sometimes a genuine modelling problem. Just as often a permissions setting nobody has revisited since the week of launch.
• "The site looks inconsistent." The content model allows freeform markup, so every editor invents their own layout. Changing tools without changing the model reproduces the problem precisely.
• "We cannot get anything out of it." This one is real, and it is the exception. Export is a genuine property of the product and the single thing most worth testing before you sign.

Four of those five follow you to the next platform. So here is the test we apply before agreeing that a replatform is the answer: write down every complaint, then mark the ones a new tool actually changes. If the marked list is short, you are buying a licence when you needed an operating rhythm, and the rhythm is considerably cheaper.

Teams often want to build their way out instead, with internal tooling nobody asked for. Before commissioning anything, it is worth being honest about whether the thing you need is a product, a service or a feature, an argument our parent company has made in a wider setting and one that applies neatly to content tooling.

The honest exception, because this claim is not universal: some platforms really do obstruct the rhythm. A system where every editorial change requires a deployment nobody present can trigger, or where two people cannot work in the same week without overwriting each other, is a real constraint and no amount of process fixes it. Judge that on the specific mechanism that blocks you, not on the general level of frustration in the room.

What the workspace has to make easy

Once you accept that operations is the problem, the tool requirements change shape. You stop asking what the system can do and start asking what it makes easy on a Tuesday, for the person who is actually going to do it.

• Structured fields rather than a wall of markup. Storing content as a block of HTML is the decision that turns every future redesign into manual re-typing, page by page.
• Visible state. Draft, in review, approved, scheduled, published, overdue. State that lives in somebody’s head is not state; it is a dependency on that person being available.
• A review step that can refuse. Somebody with the authority to hold a publish, and a record showing that they did. Approval nobody can decline is decoration.
• Redirects editable by whoever retires pages. If retiring a page requires a developer and a release, pages simply do not get retired. They get orphaned instead.
• An export you have run yourself. Not one described in a sales call. What happens to your content when you leave the CMS is the question to settle while you still have negotiating room.

Where the content physically sits shapes several of those, and Git-backed or API-backed works through that choice on its own terms. A workspace like Acrosite takes the structured route: editors work in typed fields, and the workspace generates the required files, commits them to GitHub and triggers the configured deployment, so the audit trail is the commit history instead of a reporting feature somebody has to build later.

Notice what is absent from that list: page builders, template variety, the number of available blocks. Those decide how a page looks on launch day. None of them decide whether it is still true a year later. Website design and development that ends at launch without handing over a documented content model leaves the operations gap by construction, however good the site looks the week it ships.

The rhythm, and who owns it

Operations becomes real when it has a name attached and a repeating slot in a calendar. The minimum that works is smaller than most teams expect, and it survives holidays, which matters more than elegance.

1. One owner for the queue. Not a committee and not a channel. One person who knows what is next, can reorder it, and is allowed to say no to a late request.
2. A weekly pass over the queue. What shipped, what is stuck, what is next. Fifteen minutes, written where everyone can read it afterwards rather than delivered in a meeting.
3. A monthly slot for refreshes. A protected amount of time spent on pages that already exist, which is the first thing sacrificed whenever something new is urgent.
4. A quarterly retirement review. Read the list of pages nothing links to and nobody visits, then choose one of the four options for each. Choosing nothing is how the pile grows.
5. A standing report that ends in decisions. Short, regular, and closing with what changes in the queue because of what it says. If nothing changes, shorten the report.

The intervals are not sacred and yours may differ. The pattern is what transfers: something weekly for flow, something monthly for decay, something quarterly for the pile.

A content system can make the right action easy. It cannot decide that anybody takes it. That part has a name attached, or it does not happen.

Where we would start

If the site is already live and none of this exists, do not start with a tool. Start by listing every page type you have and giving each one a review interval and an owner. That document is the operating model, it fits on a single page, and it makes the next argument about tooling much shorter.

Then run one retirement review before writing anything new. It is the fastest way to see what the site actually is rather than what the sitemap says it is, and the list of pages nobody can defend is always longer than the room expects. Most teams get more out of that afternoon than out of a quarter of new publishing.

The reversal, because this advice does not apply everywhere: if your site is genuinely new and small, you do not have an operations problem yet. Publish. Imposing a rhythm on twelve pages is procedure for its own sake. Introduce it at the point where one person has to ask another person where a page is edited, which is the moment the knowledge stopped fitting in one head.

And if the current answer to "who owns this page" is a shrug in a channel nobody reads, that is the finding, not a detail. Tell us what your page types are and we would start with the review intervals, because they cost the least and they surface everything else within a month.