Keeping a website editable without breaking it

Every company wants a website its marketing team can update without filing a ticket. Many companies also have a story about the time someone did exactly that and broke the homepage, published a draft by mistake, or deleted a page that was still linked from an ad campaign. Editability and stability aren't opposites. With the right structure, your team can edit freely and the site still holds together.

Why editable sites break

Sites usually break under editing for one of three reasons. The editor gives too much freedom, such as raw HTML fields or unrestricted page builders, so layout and styling drift with every change. There is no review step, so mistakes go straight to the public site. Or there is no history, so when something goes wrong nobody can see what changed or put it back.

Each of these has a structural fix, and none of them requires slowing your team down.

Structure content, not pages

The most important decision is how content is modeled in your content management system. Instead of giving editors a blank canvas, define content types with specific fields. A case study has a client name, a summary, a hero image, a body and a list of services. A job posting has a title, a location, a description and an application link. A landing page is assembled from a fixed set of approved sections.

Structured content keeps the design consistent because layout is controlled by code while words and images are controlled by editors. It also lets the same content appear in several places, such as a services page and the homepage, without copying and pasting.

• Give every field a clear label and help text that explains where the content appears on the site.
• Add validation: required fields, character limits for headlines, minimum image dimensions and required alt text.
• Offer a library of section types for landing pages instead of free-form layout.
• Avoid raw HTML and embed fields, or limit them to a small number of trusted roles.

Use roles deliberately

Not everyone who edits the site needs the same permissions. Most content management systems support roles, and a simple structure covers most teams.

• Contributors create and edit drafts but cannot publish.
• Editors review and publish content in their area.
• Administrators manage content types, users, redirects and integrations.
• Developers change templates and components through code, with review, rather than through the CMS.

Keep the number of administrators small. Remove accounts promptly when people leave, and require multi-factor authentication for anyone who can publish, since a compromised publishing account is a direct route to your public site.

Add a review step that doesn't get in the way

A simple draft, review and publish workflow catches most mistakes. The author submits a change, a second person looks at a preview and approves it, and only then does it go live. For routine edits, such as fixing a typo in a blog post, a lightweight approval is enough. For high-traffic pages, legal content and pricing, require approval from a named owner.

Scheduled publishing is worth setting up too. Announcements, pricing changes and campaign pages can be prepared and approved ahead of time and go live at a set moment, without someone pressing a button at midnight.

Keep a history of every change

Version history turns mistakes from emergencies into minor inconveniences. Every published change should record who made it, when and what changed, with a straightforward way to restore a previous version. Most modern content management systems offer this; make sure it is enabled and that your team knows how to use it before they need it.

History also supports accountability without blame. When a page is wrong, you can see when it changed and ask the right person, rather than guessing.

Protect the things editors shouldn't break

Some parts of a site carry more risk than ordinary content. Protect them with guardrails that work automatically, so nobody has to remember them.

• Redirects: when a page's address changes or a page is removed, create a redirect from the old address. Some systems do this automatically when a slug changes.
• Links: run a broken-link check on a schedule and after major content changes.
• Images: resize and compress uploads automatically, so a large photo straight from a phone doesn't slow the page down.
• Accessibility: require alt text and enforce a sensible heading order in templates, as part of meeting WCAG.
• Search metadata: page titles and descriptions with sensible defaults and length guidance in the editor.
• Forms: route submissions to a monitored inbox or CRM, and test them after any change to the form or its destination.

Separate content changes from code changes

Editors change content; developers change how content is displayed. Keep those paths separate. Template and component changes should go through code review and a staging environment, the same as any other software. Content changes go through the CMS workflow. When the two are mixed, such as editors pasting scripts into pages or developers editing live content directly, both sides lose the protections designed for them.

Choosing tools

There are good options at every size, from a headless content management system paired with a custom front end to an established platform such as WordPress configured with structured fields and restricted roles. The right choice depends on how many people edit, how often, and how much custom functionality the site needs. Whatever you choose, evaluate it against the practices above: structured content, roles, review, history and guardrails.

Papel Sites, our early-access product, is built around these ideas: structured pages, a review step before publishing, version history, and Claude to help draft copy, with your team approving every change. For sites with more specific needs, we build on the CMS that fits the project as part of our business websites service.