A fast website your team can edit

A headless CMS website splits the website in two. The content (text, images, products, locations, articles) lives in a content management system your team logs into. The website itself is a separate front end that takes that content and turns it into fast pages.

In a traditional setup such as WordPress with a theme, the editor and the website are one piece of software, so every plugin, theme update and page-builder layer slows the public pages and adds something to patch. Headless keeps the editing where your team needs it and lets the website be built for speed.

For your team, the day-to-day feels familiar: they log in, change a headline, swap an image, build a page from blocks, preview it and press publish. The difference is what visitors get: pages that load quickly on a mid-range phone and a site that doesn’t break when someone updates a plugin.

Headless pays off when your website changes often and matters to sales. Marketing teams that run campaigns, companies with product catalogues, brands with online stores and businesses with content in several languages get the most from it.

It is less useful for a small brochure site that changes twice a year. If no one on your side will edit the website, a simpler build can be the better spend, and we will say so.

It also pays off when the same content appears in several places. Products, locations or team profiles kept as structured content can feed the website, an app, a store and an AI search from one source, instead of being copied into each.

Running costs are usually modest. Pages served as files from a content delivery network cost little to host, even with plenty of traffic. The CMS has its own plan, often free for a small team and paid as more editors and content are added, and an open-source CMS can run on your own hosting instead.

Before any design, we decide what your content actually is. A content model describes each kind of content and its fields: a product has a name, a series, specifications, images and documents; a location has an address, hours and a map; an article has an author, a date and a topic.

Getting this right is what makes a site easy to run later. When products are structured data rather than paragraphs typed into pages, visitors can filter them, compare them and find them by specification, and your team changes a detail once instead of hunting through pages. We build the model with the people who will edit the site, because they know which fields they reach for every week.

Your team builds pages from a library of ready-made blocks: page headers, feature rows, product grids, comparison tables, questions and answers, quote and contact forms, image galleries and calls to action. Each block is designed in your brand and works on every screen size.

Blocks give freedom without breaking the design. An editor can build a campaign page in an afternoon, but can’t accidentally pick the wrong font or a colour that fails contrast. Blocks are built to WCAG 2.1 AA, so pages work with screen readers and keyboards whoever puts them together. When your team needs something new, we add a block, and it is ready for every page.

Every change can be previewed on the real design before it goes live, and earlier versions of any page can be restored. Where content needs a second pair of eyes, such as prices, product claims or legal text, it passes through an approval step first. Launch pages can be scheduled to go live at a set time, so a campaign starts when the ads do. Roles decide who may edit, who may approve and who may change the site’s settings.

Fast pages come from how the site is built, not from tuning later. Pages are generated ahead of time as complete HTML and served from a content delivery network close to each visitor. Images are resized and compressed for every screen, fonts are loaded from your own domain, and scripts are kept to what each page needs.

We measure Core Web Vitals, Google’s measures of loading, responsiveness and visual stability, on real mid-range phones over mobile data before launch, and fix whatever holds a page back. After launch, the same measures are checked as your team adds pages and blocks.

Speed matters most where you pay for visitors. Every click from an ad that leaves before the page appears is money spent for nothing, and landing pages built from the same fast blocks as the rest of the site load just as quickly on the first visit.

A rebuilt site should help search, not hurt it. Titles, descriptions and the addresses of pages are fields your team manages in the CMS. Structured data for your organisation, products, articles, locations and questions is produced from the content model, so it stays correct as content changes.

The sitemap updates itself on every publish, and changing a page’s address creates a redirect from the old one. Clear pages with direct answers near the top also help AI assistants and answer engines quote you accurately, which matters more as people ask them instead of searching.

Most headless projects replace an existing website, and that website has earned its place in search. Before we design, we audit every page, the search terms each ranks for and the links pointing in from other sites.

Every old address is mapped to its new page with a permanent redirect, content is carried across and checked, and titles, descriptions and structured data move with it. On launch day the new sitemap is submitted, and afterwards we watch Search Console, test the redirects and fix any page that drops out. If the move is a large part of your project, our website migration page covers it in depth.

A website is part of your sales, so its forms go where your team works. Contact and quote forms send to your CRM, such as HubSpot or Zoho, with the page, product and campaign attached. Site search can run on Algolia, and a store’s products and checkout can come from Shopify behind your own design.

Analytics and advertising tags wait for each visitor’s consent where the law requires it, and events are set up so you can see which pages lead to enquiries, not just visits.

We need access to what you have and time from the people who will run the site. That means your current website and its analytics and Search Console accounts, your brand files, and any product data, documents or spreadsheets the new site should draw on.

Most of all we need the people who will edit the site: an hour or two with them while we build the content model, and their feedback on the editing screens before launch. One person on your side should own the website, approve the blocks and decide what goes live first. Copy can be written by your team, or we can work with your writer to fit it to the new pages.

We train your team on launch day and stay with you afterwards. New blocks and page types are added when your team asks for them, the CMS and the code are kept up to date, and speed and search are checked regularly.

Over time, the content model grows with the business: new product lines, new languages, new locations. Because the content is structured, each addition is a field or a block, not a rebuild. And because the website and the CMS are separate, either can be changed later without starting the other again.