When a client asks for “a new website”, the underlying architecture you choose affects editing, performance, security, compliance and ongoing support. This short guide helps you pick between three common approaches: static sites (SSG + CDN), headless CMS paired with static delivery, and managed WordPress. Each section explains what the option is, when it fits, and the operational trade‑offs you should include in a commissioning brief.
Quick decision flow (one page)
- Is the site mostly informational (brochure pages, contact, opening times) with infrequent content changes? Consider static SSG + CDN.
- Will the same content feed multiple channels (web, app, kiosk) or need structured content and editorial workflows? Consider headless CMS + SSG.
- Does the client need frequent on‑page edits, many off‑the‑shelf plugins (booking, membership), or prefers a familiar editor? Consider managed WordPress.
- Do you require integrated e‑commerce and payments? Managed WordPress or a dedicated ecommerce platform are more straightforward; headless/ecommerce is possible but requires more technical setup.
- Is localisation needed (many languages)? Headless CMS often handles structured localisation better; static sites can, but expect more build complexity.
Option 1 — Static site (SSG + CDN)
What it is: Pages are prebuilt as HTML at deploy time and served from a CDN. Typical tooling includes static site generators (SSGs) and CI/CD pipelines that publish to a CDN.
Best fit: Mostly informational sites, small business brochure sites, landing pages and campaign microsites that change rarely.
Pros: Fast page loads because content is served from the edge; smaller server‑side attack surface since there’s no running CMS; typically lower hosting complexity and strong cacheability. Many platform guides highlight performance and simplified hosting as primary benefits of SSG + CDN architectures (Netlify).
Cons: Less convenient for non‑technical editors if you don’t provide a friendly editing interface; content updates require a rebuild/deploy step (this can be automated but affects build cadence); previewing draft content needs extra tooling.
Option 2 — Headless CMS + SSG
What it is: A headless CMS separates content from presentation and delivers structured content via APIs to whatever frontend you build. The frontend can be statically generated and deployed to a CDN, combining editorial workflows with static delivery (Vercel).
Best fit: Organisations that want editorial ease (non‑technical content editors), structured content reused across channels, or sites with moderate complexity and a desire for static performance.
Pros: Editors get richer workflows and content modelling while the site benefits from CDN delivery; easier multi‑channel publishing; control of presentation is uncoupled from content storage.
Cons: Build times increase with more content and pages—this affects how quickly changes go live; previewing and real‑time editing are more complex and must be engineered (preview endpoints or server functions); the architecture adds more moving parts to support.
Option 3 — Managed WordPress
What it is: A server‑hosted CMS where the editing interface and the public site are managed together. Managed hosts provide backups, updates and one‑click staging in many cases.
Best fit: Clients who need frequent on‑site content updates, a wide range of plugins (forms, bookings, SEO tools), or who expect to rely on content editors familiar with WordPress.
Pros: Editor familiarity reduces training time; many ready plugins exist for common needs; staging and GUI‑based editing are straightforward.
Cons: Larger server‑side attack surface requiring regular updates, security hardening and backups; performance depends on host and caching configuration; plugins can introduce maintenance burden and compatibility issues.
GDPR, ICO and cookies — what to brief
UK cookie and data rules apply regardless of architecture: non‑essential cookies (tracking/advertising) require user consent, and your implementation determines where cookies and analytics run (client vs server). Include an ICO check in your brief to map analytics and cookies (ICO guidance).
Practical notes: server‑side measurement (proxying analytics through server functions) can reduce client‑side cookies; static sites minimise server storage of personal data, but integrating third‑party widgets (chat, booking) can still set cookies and must be documented and consented.
Studio commissioning checklist
- Service levels: Define SLA for fixes, security patches and response times.
- Preview & staging: Require a preview environment for editors and a staging URL that mirrors production.
- Editing UX test: Run a live content‑editing session with the client during acceptance testing.
- Build/deploy cadence: Specify expected deploy times and rollback procedure for SSG/headless builds.
- Backups & security: For managed CMS, require automated backups and plugin update policy; for headless/static, document API keys and secret storage.
- Accessibility & SEO: Include accessibility checks and baseline SEO performance metrics (core web vitals where appropriate).
- Exit & ownership: Confirm who owns content, DNS, and build/deploy credentials; include an exit procedure for handing over source content and keys.
Short decision worksheet — 6 questions
- Will non‑technical staff edit the site frequently? If yes → WordPress or headless with editor UI.
- Will content be reused on other channels (apps, kiosks)? If yes → headless CMS.
- Is the site mostly static information that rarely changes? If yes → static SSG + CDN.
- Do you need many plugins or ready integrations (payments, bookings)? If yes → WordPress or specialist ecommerce.
- Is minimising maintenance and server exposure a priority? If yes → static or headless with static delivery.
- Do you require a fast, small‑team operational model with clear handover? If yes → include the commissioning checklist above and test the editor UX before sign‑off.
If you want a studio‑ready one‑page decision flow and a fillable commissioning checklist tailored to the client, we can convert this brief into a printable sheet and a short acceptance test for editors — try our website launch checklist tool to get started: Website launch check.
Sources: Vercel (headless CMS overview), Netlify (guide to headless + SSG patterns) and the ICO guidance on cookies and PECR.