Content management systems
A CMS your team will use without calling us
The complaint is almost never that a CMS lacks features. It’s that publishing a simple page takes four steps, two of which are guesswork, so people stop doing it and email the developer instead. Most of that is content modelling rather than software.
What this covers
Built around the people who publish
The person who signs off the project is rarely the person who uses the CMS every week. We design for the second one.
CMS builds
WordPress, Payload, Sanity, Strapi, Contentful and Shopify. Chosen for how your team works and what your developers can maintain, not for whichever platform is currently fashionable.
Content modelling
Deciding what a "page" actually is in your business, so editors fill in clearly named fields instead of fighting a page builder into shape every time.
Migrations
Moving content between platforms with URLs, metadata, images and internal links preserved. The redirect map is written before the migration runs, not afterwards.
Editor experience
Live previews, sensible field labels, validation that catches mistakes before publish, and required fields where something genuinely is required.
Locked components
The parts of the design that shouldn't move are fixed in place. Editors get freedom where it's safe and guardrails where a wrong choice would break a layout.
Roles and permissions
Who can publish, who can only draft, who can change templates, and who can add users. Worth setting up before the team grows rather than after an accident.
Multi-site and multi-language
Shared components across several sites or regions, with translation workflows that don't rely on someone maintaining a spreadsheet of strings.
Maintenance
Core and plugin updates, security patching and backups, handled monthly if you'd rather not track it. Particularly relevant for older WordPress installs.
Where we come in
The three calls we get most
"Our editors are scared of the CMS."
Usually a modelling problem wearing a training problem's clothes. When fields map to things people recognise, the training takes about twenty minutes.
"We're on an old WordPress with forty plugins."
Slow, fragile and a security liability, with nobody sure which plugins are load-bearing. We audit what’s actually used before removing anything.
"We need to replatform without losing our rankings."
Entirely achievable, and entirely dependent on redirects and URL structure. This is the part that gets skipped when a migration runs late.
How it works
We talk to the people who publish first
The first sessions are with editors, not stakeholders. What gets published weekly, what gets published once and never touched, what has to stay consistent across pages, and where the current system makes them stop and ask someone. The build follows from that.
Then we model the content: types, fields, relationships and what is genuinely optional. Doing this properly is what makes a CMS feel obvious two years later, when nobody involved in the original project is still around to explain it.
For migrations, URLs and redirects are part of the plan from day one. Losing search rankings in a replatform is avoidable and almost always self-inflicted. We check the map against live traffic before the switch, then again after.
On staying where you are
WordPress has a poor reputation among developers and a very good one among the people who have to use it. If your install is healthy and your team is comfortable, we'll usually recommend cleaning it up rather than moving you somewhere new and more expensive.
Tools
What we work with
Both traditional and headless, depending on whether the content feeds one site or several places at once.
- WordPress
- ACF
- Payload
- Sanity
- Strapi
- Contentful
- Shopify
- Next.js
- Astro
- Redirect mapping
- Content migration scripts
Answers
Questions about CMS work
Will a migration lose our Google rankings?
Not if the redirects are done properly. Every old URL needs a permanent redirect to its new equivalent, and page structure and metadata need to carry across. We treat that as part of the migration, not an extra.
Should we stay on WordPress?
Often, yes. It gets criticised by developers and quietly liked by editors. If the install is healthy and your team knows it, a cleanup is usually better value than a move.
Can our team edit without breaking the design?
That's the point of the way we build. Editors get fields and defined components rather than free rein over layout, so a page can be wrong in content but not broken in structure.
What's the difference between headless and traditional?
Traditional keeps the content and the site together, which is simpler. Headless separates them, which helps when the same content feeds a site, an app and a third place. Most businesses need the first one.
Do you maintain it after launch?
If you want. Updates, patching and backups can run as a monthly arrangement, or we can document it and hand the whole thing to your team.
Can you rescue a site we can't log into?
Usually, if you own the domain and the hosting. Recovering access from a previous agency is more common than you'd think and it's a reasonable first job.
Related
Often needed alongside this
Get in touch
Tell us what your editors keep getting stuck on.
Whether it's a migration, a rebuild or an install nobody has updated in two years, a short description is enough to start.