What a CMS needs so editors can publish without breaking SEO
Roles, a review step, scheduled publishing, an audit log and generated sitemap and structured data. What we built into a publication's CMS, and what we still lack.
- Roles and a review step stop one mistake from reaching every page.
- Generate the sitemap, llms.txt and structured data from the content, not by hand.
- An audit log lets you see who changed a page and fix it with confidence.
- Show the last-verified date and reviewer to readers. We track them but don't show them yet.
Quick answer
A CMS that lets editors publish safely needs roles where only some people can publish, a review step, revision history, an audit log, scheduled publishing, per-page SEO fields with safe defaults, and a sitemap, llms.txt and structured data generated from the content. The technical basics should be something the system does, not something an editor remembers.
The short answer
Editors need speed. Search engines need consistency. A CMS reconciles the two by making the technical basics automatic and by limiting how far one mistake can spread.
Our rule: if a rule matters for search, it goes in code, not in a style guide. Style guides get forgotten on a Friday afternoon. Code doesn’t.
Why buyers ask this
Marketing teams want to publish without waiting for a developer. Developers worry that a free-for-all publishes broken pages. Both worries are fair, and a good CMS answers both. The question to ask isn’t “is it easy to use?” but “what does it stop a tired editor from doing?”
What we built into one
We co-founded CrawlTheory, an SEO publication, and built its admin CMS. The parts that matter here:
- A workflow with five states: draft, in review, scheduled, published, archived. Editors move posts between draft and in review. Only a super admin can publish or schedule. The check runs in the server action that saves the post, not just in the interface, so it can’t be bypassed by a crafted request from the browser.
- Roles: super admin, editor and viewer. A viewer can look but not change.
- Revision history. Every draft save writes a snapshot, so an editor can browse recent versions and restore one.
- An audit log of admin actions, with the actor’s email stored on the row so entries outlive the user.
- Scheduled publishing. A secured route publishes due posts, refreshes the pages and notifies search engines through IndexNow.
- Per-page SEO overrides with a rule that an empty field falls through to the page’s own default, so a half-filled form can never break a page.
- A generated sitemap, llms.txt and structured data built from the same rows the pages use.
- A slot-conflict check. If an editor pins an article to a featured slot that is taken, the system asks before replacing it.
The feature list to ask of any CMS
| Need | Why it matters | A good answer |
|---|---|---|
| Roles with a publish gate | One mistake shouldn’t reach every page | Editors submit, an approver publishes |
| A review step | A second pair of eyes | A visible “in review” state |
| Revision history | Editors need to undo their own errors | Restore any recent version |
| Audit log | You can see who changed what, and fix it | Actor, action and time on every change |
| Scheduling | Publishing on a plan, not by hand at midnight | A scheduler you can see running, at a stated cadence |
| Per-page SEO fields | Title, description and social card per page | Safe defaults when a field is empty |
| Generated sitemap | New pages can’t be forgotten | Built from published content on request |
| Structured data | Matches the page by construction | Generated from the same fields |
| Redirect handling | A changed address shouldn’t lose its history | A redirect created when a slug changes |
| Input clean-up | Pasted text carries odd characters | Normalised when content enters, not when it’s shown |
Three lessons from auditing our own CMS
In June 2026 we ran a root-cause analysis on CrawlTheory. Three findings are worth borrowing.
1. Fix content where it enters, not where it’s shown. Our typographic clean-up for quotation marks ran on article bodies only. Titles, excerpts and card headings showed whatever characters were pasted in, often curly quotes from a word processor. A rule applied in one place isn’t applied. Normalise on import and on save.
2. An override that silently wins is a trap. The admin let someone upload a sitemap file. An uploaded file took priority over the generated one, so when someone had uploaded one, new posts never appeared. If you offer an override, show a visible warning while it is active, and make the generated version the default. We now send a no-store header from the sitemap route so it can’t be served stale.
3. “In the HTML” is not “visible”. Our public pages were server-rendered, so the text was in the HTML. But each block started invisible and a script faded it in when it scrolled into view. Without the script, the page looks blank in some audit tools. As of 26 October 2026 that rule is still in our stylesheet. We know about it, and we are telling you so you can avoid it. See server-rendered pages and AI search.
A note on scheduling
Our scheduled-publish route is written to be called every fifteen minutes. The cron entry in our deployment config runs once a day. Both are fine for a publication that schedules a day ahead, and wrong for one that promises a post at 9:15. Ask any CMS vendor how often the scheduler runs, not only whether one exists.
Build, buy or use WordPress?
Our opinion, since you asked. If one person publishes a few articles a month, use a hosted platform and stop reading. If several people publish, you need review and an audit trail, and search and AI crawlers matter enough to engineer for, a custom CMS or a heavily configured one earns its cost. A middle path is a standard CMS plus a short, written list of rules enforced by plugins or checks. What you shouldn’t do is rely on training.
What we still lack
We track a last-verified date and a reviewer, but readers can’t see them yet. For a publication that wants to be cited, visible freshness is a trust signal, and it is on our list.
We have recorded no traffic, ranking or AI-citation result for this CMS. It is our own product, so it is not independent proof. And a one-person site doesn’t need roles, review or an audit log. They pay off once two or more people publish.
Next: can marketing publish without a developer and will the site get found. Case study: the CMS behind a publication.
Features and rules come from the CrawlTheory repository (migrations, server actions, routes and configuration) on 26 October 2026, and the three lessons from our own root-cause analysis dated 17 June 2026, re-checked in the code on 26 October. All are tracked in our claim ledger. We co-founded CrawlTheory. Proof grade 4: our own build.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
