What Flexible CMS Should Mean for Editors

A brand-new campaign is about to launch. Traffic will spike. Stakeholders expect zero downtime. Your editorial team needs to QA content in the real environment, but you can't risk surprises in production.

This is where many CMS implementations fall apart. You either get rigid workflows where editors wait days for developer tickets, or you get “flexible” tools that create chaos where every editor invents their own navigation - causing brand drift and cleanup marathons right before a launch.

Wagtail's strength is that it lets you design for autonomy without sacrificing brand control, if you choose the right guardrails.

Building CMS Experiences for Editors

Implementing the right guardrails was the core challenge Eric Sherman (Senior Software Engineer at Truth Initiative, the nation’s largest nonprofit dedicated to ending nicotine addiction) and I tackled when preparing to launch the EX Program, a digital program that helps people quit tobacco using web and SMS.

In our Wagtail Space talk, Building Flexible Wagtail CMS Experiences for Editors, we broke down what we learned: Start simple. Launch fast. Iterate later.

The goal wasn't more CMS features. It was an editor experience that moves fast with guardrails. The approach that worked: automate decisions where possible, give control only where it matters.

3 Wagtail Implementation Strategies

1) Optimize for Rollout Control, Not Layout Control

• For the homepage redesign, flexibility did not mean infinite layouts and endless configurability. It meant editors could draft early, preview safely, and launch predictably. We kept the content model intentionally simple with straightforward fields that matched the design, then used Wagtail's preview mechanism combined with a feature flag so User Acceptance Testing (UAT) could happen in production without exposing the new experience. Launch became a toggle, not a scramble.

2) Let Content Drive Presentation

• For page headers, the obvious Wagtail move is a dropdown: pick a style, pick a theme, pick a variation. That looks empowering until it creates inconsistency and support debt. Instead, we automated header styling based on Wagtail page context (page type, parent page, whether an image exists). Editors make content choices in familiar Wagtail fields, and the system enforces visual consistency. The result is faster editing, fewer mistakes, and a cleaner path to add new themes later.

3) Keep Architecture in Sync with Page Trees

• For topic pages, "maximum flexibility" can become a maintenance trap: manually curated lists, page choosers everywhere, navigation that drifts out of sync. Instead, we used Wagtail's page tree as the source of truth. Editors reorganize once in the Wagtail admin so navigation, related topics, and groupings stay consistent automatically. We still used StreamFields and snippets, but intentionally: StreamFields for controlled variation within a page, snippets for truly reusable content, and Wagtail's page models to keep structure predictable.

These strategies solved the real problem: editors publish with confidence using Wagtail's familiar interface, developers focus on higher-value work instead of CMS tickets, and experiences stay consistent as the site grows.

Watch the Talk

See how these strategies played out in production:

Read more about Six Feet Up’s Django/Wagtail expertise.