CMS Architecture

CMS architecture: model the content, then build the site around it.

We design the content model for your website, build the CMS around it in Webflow, and move your existing content across. This is for B2B teams whose site is a pile of one-off pages and whose every edit needs a developer.

Most CMS problems are modelling problems. If the structure underneath is wrong, no amount of editor training fixes it.

What we do

  • Model the content first. We list what your site actually publishes, find what repeats, and turn the repeating things into collections instead of hand-built pages.
  • Design the collections. Fields, types, defaults and validation, named so a marketer knows what goes in each one without asking.
  • Set the relationships. References and multi-references between collections, so an author, a product, a category or a location connects once and appears everywhere it should.
  • Build the templates. One template per collection, designed for real content, including the long titles and the missing images.
  • Handle the edge cases. Empty states, items with no image, very long strings, items with no related content, and the pages nobody thinks about until launch week.
  • Connect the tools you already pay for. CRM, marketing automation, calendars, analytics, search and forms, wired so data goes where your team already looks for it.
  • Move the content across. We export from your current platform, clean and map the fields, and import into the new collections with URLs preserved or redirected.
  • Build the redirect map. Every URL that moves is accounted for, and we verify it against the live site after launch.
  • Set the publishing rules. Who can edit what, what is structural and locked, and how a new page gets made without breaking the system.

How we run it

Step 1 · Content inventory. We pull every page and every content type off your current site and put them in one list. This usually finds duplicates, orphans and three versions of the same page.

Step 2 · The model. We draft the collections, the fields and the relationships, and walk you through it. This is the document everything else is built from, and it is agreed before anything is built.

Step 3 · Build. Collections, fields, references and templates go into Webflow. Real sample content goes in early, because sample content is where a model shows its cracks.

Step 4 · Migration. We map old fields to new fields, run a test import, review it with you, then run the full import. URLs are preserved where possible and redirected where they are not.

Step 5 · Integrations. We connect the tools, test each connection with real submissions, and document what goes where.

Step 6 · Handover. A written guide to the model, a recorded walkthrough for your editors, and a support window agreed at kickoff.

What you get every week. The content model document, kept current, a staging link with the collections you can click through, a written note on what moved, and one call. Migration mapping decisions are logged in the same place, so nothing gets decided in a chat message and forgotten.

Deliverables

  • Full content inventory of the existing site
  • A written content model: collections, fields, types, relationships
  • Built CMS collections and templates in Webflow
  • Migrated content from your current platform, with field mapping documented
  • A verified redirect map for every moved URL
  • Connected integrations, tested and documented
  • Editor permissions and publishing rules
  • A written guide to the model and a recorded editor walkthrough
  • A support window after launch, agreed at kickoff

Who it is for

  • B2B teams whose blog, case studies, jobs, locations or product pages are hand-built one at a time.
  • Companies moving off a platform where publishing requires a developer.
  • Marketing leaders who want to add a page type without a project.
  • Teams with content spread across systems that has to end up in one place.
  • Sites with large, frequently changing content: property listings, catalogs, directories, resource libraries.

Who it is not for

  • Small sites with a handful of static pages and no content that repeats. A CMS would be overhead you do not need.
  • Teams who want the content moved across exactly as it is, without deciding what to keep. Migration without a model just moves the problem.
  • Products needing a custom application database. This is website content, not application data.
  • Anyone unwilling to name one person who owns content decisions during the build.

Related services

Questions we get asked

Let us look at your content.

Bring the current site and a rough idea of what your team publishes. We will walk you through what the model would look like.

Start a project

Tell us what you are building.

Tell us where you want to go and we'll build the site that gets you there: fast, findable, and built to convert.