Lexington
LexConnect, an app built on the extranet we had already delivered, so information reached staff wherever they were working.
Read the case study: Lexington →
Content modelling
The schema decisions you make now are the ones your editors live with for years. Slow queries, frustrated editors, content that can't be reused and duplicates across spaces usually trace back to a content model built quickly under deadline. We design Contentful and headless content models with editors, product and engineering in the room, and we bring seventeen years of modelling content in Drupal to it.
Where you're starting from
- Contentful
- Strapi
- WordPress
- Drupal
Where you go next is decided in the Blueprint. Sometimes the answer is to upgrade.
Which situation are you in?
New build
Starting from scratch
You are moving to Contentful or another headless CMS and want the model right before anything is built on top of it.
A documented model, agreed before build.
Refactor
A model that has stopped working
One page type with sixty optional fields, free-text tags, everything localised. We redesign the model and write the scripts that move your content into it.
A cleaner model, with no content lost on the way.
Expansion
Something big is coming
A new channel, new locales or a new product. We plan where it fits before the model bends out of shape to accommodate it.
Room to grow without a rebuild.
What usually goes wrong, and how we stop it
The same modelling mistakes turn up again and again. Each one is fixable, but the longer it sits, the more content is built on top of it.
1
The "page" type
One type with dozens of optional fields and no structure. We split it into types editors can understand.
2
Free-text taxonomy
"News", "news" and "Blog post" all meaning the same thing. Taxonomy becomes references, with one source of truth.
3
Everything localised
Slugs, IDs and references marked as translatable. We decide locale behaviour field by field.
4
Deep reference chains
Page, section, block, item, variant: slow to query and slow to edit. We keep nesting shallow.
5
Mixed concerns
Content, SEO, analytics and layout on one type. We separate them so each can be reused.
6
No history
Types changed by hand in the interface for years. We put the model in version-controlled migration scripts.
How a modelling engagement runs
Typically two to six weeks
- DiscoveryWorkshops with editorial, product and engineering on every content type and channel.
- ModelContent types, fields, validations and references proposed and reviewed with your team.
- BuildThe model set up in your space through version-controlled migration scripts.
- EditorsField help text, validations and training, so bad content can't ship.
- HandoverArchitecture document, scripts and a sign-off checklist your team owns.
Projects we've built
Cyber Essentials
Infrastructure used by Cyber Essentials providers, built so assessors can review everything as quickly as possible.
Read the case study: Cyber Essentials →Questions
If yours isn't here, it's usually quicker to ask on the phone.
Is this only for Contentful?
Most of our modelling work is on Contentful, but the same approach applies to Strapi and to headless WordPress and Drupal.
Can you change our model without losing content?
Yes. Changes are written as migration scripts that move existing entries into the new structure, rehearsed on a copy of your space first.
What do we get at the end?
A content architecture document, the migration scripts in your repository, configured validations and editor guidance, and a trained team.
After launch
Contentful support and maintenance →Already live? WebsiteSupport.io looks after it
Once a Contentful site is live, our sister company WebsiteSupport.io keeps it patched, monitored, hosted and improving.
Start with a Blueprint!
Three weeks, from £5,500 + VAT. Credited against the build, and yours to take to any supplier.