WordPress and Webflow are still the right call when the client has no developer on retainer, expects in-browser editing without a separate frontend repo, or depends on plugins and integrations that only exist in those ecosystems. Forcing Jamstack on those clients creates friction that shows up in support tickets six months later.
When the agency can standardize on frontend templates and a content API, the static-first plus headless CMS pattern scales better across clients.
Four paths in 2026
The market in 2026 is fragmented by role, not by one dominant platform. Each path has a legitimate place in agency work.
Path 1: AI-augmented no-code
Examples: Framer, Wix, Hostinger AI builder, Durable
Best for agencies when: speed matters more than ownership, the client has no development budget, and the site is a simple presence or campaign landing page.
Trade-off: limited portability, vendor lock-in, and weak reuse of the same codebase across multiple clients. The AI step accelerates the first draft; ongoing edits still happen inside that vendor's editor.
Path 2: Visual pro builder
Examples: Webflow
Best for agencies when: the deliverable is a design-led marketing site, marketers need self-serve editing after handover, and hosting, SSL, and CDN are acceptable as platform fees.
Trade-off: cost scales with traffic and seats; complex integrations and deeply custom application logic hit a ceiling sooner than a code-first stack. Code export exists on some plans but dynamic CMS features do not always survive a move.
Path 3: Classic CMS
Examples: WordPress (block themes, Elementor, or custom themes)
Best for agencies when: the client expects WordPress, needs a broad plugin library, or runs a content operation that already lives in WP admin.
Trade-off: security patches, plugin conflicts, and performance tuning become ongoing responsibilities. A well-cached WordPress site can perform well; a neglected one becomes a maintenance liability.
Path 4: Modern dev stack
Examples: Astro, Next.js, or Nuxt frontend + headless CMS (NomaCMS, ElmapiCMS, Contentful, Sanity, Strapi, Payload, Directus, Storyblok, and others)
Best for agencies when: reusable templates, strong performance, and a clean separation between content and presentation matter, especially across several client sites on similar architecture.
Trade-off: requires developer capacity for the frontend and integration work. The CMS choice affects editor experience, hosting cost, and whether one installation can serve many clients.
Paths 1–3 are valid for specific briefs. Path 4 is the focus of the rest of this guide because it is the pattern agencies can productize: one template repo per framework, one CMS operations model, many client frontends.
Recommended pattern: static-first + headless CMS
The architecture agencies reuse most often in 2026 looks like this:
- Editors update structured content in a headless CMS admin.
- The CMS exposes a content API (REST or GraphQL).
- The frontend fetches content at build time (SSG), on a schedule (ISR), or per request (SSR) for the pages that need it.
- Public pages ship as HTML from an edge CDN; only interactive regions load JavaScript where necessary.
This is the practical meaning of "Jamstack" or "composable" in agency delivery: not a brand name, but pre-rendered HTML plus APIs plus selective hydration.
Why static-first
Static and hybrid sites deliver predictable performance: no database round-trip on every page view for marketing content. Security surface area shrinks when the public site is files on a CDN. Hosting costs stay low for brochure and blog traffic patterns.
The islands architecture trend — render most of the page as HTML, hydrate only widgets that need client state — keeps JavaScript budgets under control. That matters for Core Web Vitals and for clients who care about mobile performance on average connections.
When to add SSR or ISR
Pure static generation fits content that changes infrequently or can wait for the next deploy. Add incremental static regeneration, on-demand revalidation, or server-side rendering when:
- editors publish several times per week and cannot wait for a full rebuild pipeline;
- preview URLs must show draft content;
- localized routes or large entry counts make full rebuilds slow.
SEO and release discipline for headless frontends — canonicals, sitemaps, metadata — should be treated as a gate before client handover, not an afterthought.
Framework picker for agencies
The frontend choice should follow team skills and the client's interaction requirements — not hype cycles.
Astro
Fits: content-heavy marketing sites, blogs, documentation-style hubs, portfolios.
Strengths: minimal client JavaScript by default, fast builds, strong content-focused developer experience.
Agency note: pair with a headless CMS when marketers edit copy; use Markdown in Git only when the client accepts developer-mediated updates.
Next.js
Fits: marketing sites that share a codebase with app-like features, teams already on React, projects needing App Router and hybrid rendering.
Strengths: large ecosystem, mature deployment on Vercel and other hosts, ISR and server components for mixed static and dynamic routes.
Agency note: avoid shipping a full client-side SPA when most routes are static marketing pages.
Nuxt
Fits: Vue teams, i18n-heavy sites, agencies standardized on the Vue ecosystem.
Strengths: file-based routing, solid SSR and SSG story, good fit for multilingual client sites.
Vue (without Nuxt)
Fits: smaller Vue SPAs or embedded apps where a full Nuxt stack is more than the brief requires.
SvelteKit
Fits: teams invested in Svelte, niche projects where bundle size and simplicity matter.
Strengths: growing framework; smaller hiring pool and package ecosystem than React or Vue.
Headless CMS picker for agencies
CMS selection for agency work should be evaluated on axes that show up in monthly operations — not on feature checklists copied from vendor homepages.
| Criterion | What to ask |
|---|---|
| Hosting model | Cloud SaaS vs self-hosted on agency infrastructure |
| Multi-project fit | One install for many clients, or one install per client |
| Editor UX | Can the client's marketer publish without filing a ticket |
| API and SDKs | REST or GraphQL, TypeScript clients, webhook support |
| Cost at scale | Total cost across five to ten client sites over two years |
| Operational burden | Updates, memory use, plugin ecosystems, backup routines |
NomaCMS
NomaCMS is a managed, AI-native headless CMS. Structured content, a REST API, and a JavaScript SDK ship without running a CMS server on agency infrastructure. Built-in AI assists with writing, translation, and inline field editing; an MCP server connects Cursor, Claude Code, and other AI editors. Separate projects per client keep schema, entries, assets, and API keys isolated in the cloud. Paid plans add project auth, webhooks, locales, team workspaces, and versioning. Global CDN handles asset delivery. Plans start at $15 per month after a 7-day free trial.
Agency fit: teams that want hosted delivery, predictable SaaS pricing, and AI-first editorial workflows without VPS maintenance. Strong when the agency prefers cloud ops over self-hosting.
ElmapiCMS
Self-hosted headless CMS on Laravel with multi-project support from one installation — separate content, API keys, and users per client. One-time licensing ($70) rather than per-seat SaaS fees suits agencies running several similar client sites on their own server. PHP-based hosting tends toward lower idle memory than many Node CMS stacks. Editor UI is React-based; delivery is API-first for Astro, Next.js, Nuxt, and other frontends.
Agency fit: teams comfortable running infrastructure who want unlimited projects from a single install and predictable long-term cost at scale.
Contentful
Enterprise-grade cloud CMS with strong API tooling and personalization options. Editorial workflows and roles are mature. Cost scales with usage and seats — reasonable for larger clients, expensive when multiplied across many small sites.
Sanity
Content Lake model, real-time collaboration, and deep customization for developer-heavy teams. Strong when editors and developers share one studio daily. Pricing and schema design complexity deserve upfront planning.
Storyblok
Visual editor and marketer-friendly page building on top of headless delivery. Good fit when clients want component-based editing without touching code. Enterprise features and AI-assisted workflows are increasingly part of the pitch.
Strapi
Popular self-hosted Node.js CMS with a large plugin ecosystem. Flexible content types; each client traditionally meant another installation unless architecture is carefully designed. Memory consumption on small VPS instances is a known planning factor.
Payload
TypeScript-first, developer-oriented, often self-hosted. Strong when the agency wants code-adjacent schema and full data ownership. Requires Node operations competence.
Directus
Database-first headless layer over SQL databases. Flexible for teams that want direct data access and self-hosting. Editor experience differs from purpose-built marketing CMS products.
For managed cloud delivery with AI workflows, see NomaCMS and its CMS for agencies guide.
Worked example: agency stack with ElmapiCMS
Scenario: an agency delivers a marketing site and blog for Client A. Clients B and C are queued on similar architecture. The agency wants one CMS operations model, reusable Astro templates, and clear handoff boundaries.
Stack: Astro frontend, ElmapiCMS, deploy to any edge-friendly host (Vercel, Netlify, or Cloudflare Pages).
Step 1: One CMS, isolated projects
Provision one ElmapiCMS installation on agency infrastructure. Create a separate project for Client A with its own collections, API keys, and user accounts. Client B and C receive their own projects on the same instance when their builds start.
This mirrors a multi-client CMS workflow: one update cycle, one backup target, no cross-client data leakage.
Step 2: Minimum content model for launch
Resist over-modeling before go-live. A practical launch schema includes:
- Site settings — logo, default SEO, navigation, footer links
- Pages — structured marketing URLs (home, about, pricing)
- Blog posts — if the brief includes a blog
Defer team directories, complex relational catalogs, and localization until phase two.
Step 3: Reuse the agency template
Clone the agency's Astro + headless CMS starter for Client A. Replace API keys, environment variables, and branding tokens. The frontend repo structure stays identical across clients; only the content API endpoint and keys change.
Step 4: Publish flow
On publish, either trigger a build webhook from the CMS to the hosting provider or use on-demand revalidation if the frontend supports it.
Step 5: Client handoff
Document what the client may edit in the CMS (copy, images, blog posts, navigation labels) versus what remains in code (layout components, new page types, design system changes). Clear boundaries prevent "small tweak" requests from becoming undeployed frontend changes.
This pattern works when the agency has frontend developers, clients need a marketer-friendly admin, and running ten separate CMS servers is not sustainable.
Paths at a glance
| Path | Time to first launch | Client edit experience | Reuse across clients | Performance ceiling | Typical ops cost | Best agency use case |
|---|---|---|---|---|---|---|
| AI no-code | Fastest | Guided in vendor UI | Low | Medium | Low-medium | One-off microsites, speed over ownership |
| Webflow | Fast | Strong visual editor | Medium (clone projects) | High for marketing sites | Medium-high | Design-led marketing, marketer self-serve |
| WordPress | Medium | Familiar block editor | Medium (themes, multisite) | Medium-high with tuning | Medium | Plugin-heavy sites, WP-native clients |
| Static + headless CMS | Medium (first template slower) | CMS admin | High (templates + API) | Highest | Low-medium (self-hosted) | Retainer clients, multi-site agencies |
"Ops cost" is qualitative: SaaS platforms trade cash for reduced server work; self-hosted stacks trade server time for license savings at scale.
Client scenarios
SaaS landing page and changelog
A B2B startup updates hero copy and ships product changelog entries weekly. Astro + headless CMS keeps the marketing site fast while marketers edit structured sections and posts without touching Git. ISR or webhook-triggered rebuilds keep publish latency acceptable.
Developer portfolio and case studies
A consultancy refreshes case studies quarterly. Astro or Nuxt with infrequent builds fits well. If the client later wants self-serve case study publishing, add CMS collections without rewriting the frontend architecture.
Multi-client agency retainer
An agency runs eight client marketing sites on similar layouts. NomaCMS (managed cloud, one project per client) or ElmapiCMS (self-hosted, one install) plus per-client Astro repos keeps CMS ops lean. New clients clone the frontend template; billing stays predictable.
Client insists on in-browser editing, no dev budget
A local business wants to change text and images themselves and will not pay for ongoing development. Webflow or WordPress is the honest recommendation. Jamstack adds cost and friction when no one maintains the frontend repository.
Neutrality on this fourth scenario builds trust: the agency is advising on fit, not on standardizing every client into one stack.
Baselines every stack needs in 2026
Path choice does not exempt a site from fundamentals. Every delivery — including static and headless — should meet these baselines before launch:
- Core Web Vitals: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, CLS below 0.1 (75th percentile field data where available).
- Semantic HTML: meaningful heading hierarchy, landmarks, and crawlable links — not div-only layouts for primary content.
-
Structured data: JSON-LD that matches visible content (
Article,FAQPage,BreadcrumbListwhere appropriate). Mismatched schema hurts trust and rich-result eligibility. - Accessibility: WCAG 2.2 AA as a release gate — keyboard navigation, focus states, sufficient contrast.
- AI and search visibility: clear question-and-answer content, accurate metadata, and stable URLs so both search engines and answer engines can cite the site reliably.
These baselines are path-agnostic. A fast Jamstack site with broken canonicals still loses visibility; a Webflow site that hits Vitals targets still wins.
Top comments (0)