Choosing a Web Stack for SEO, GEO, and AI Max
22 May 2026
Two stacks. Same kind of website. Different fitness for the job your site now has to do.
The web stack that powered a decade of SEO isn't built for the three things a modern marketing site has to do at once: rank organically (SEO), get cited by AI engines (GEO), and feed Google's AI Max for paid leads.
The most popular stack is still WordPress + PHP/MySQL + plugins + a page builder, fronted by Cloudflare. That's ~42% of all websites. It's not wrong — it's just optimised for the publishing model of 2015, not the publishing model AI Max and AI Search now require.
This article challenges the popular stack, lays out the three patterns that meet the new demands, and gives you an honest comparison including security trade-offs and what Kaliber actually runs.
The winning brands won't be the ones with the prettiest websites. They'll be the ones whose websites can be quickly read, classified, cited, and bid against by every AI surface that matters.
The popular stack hasn't changed. The job it has to do has.
Most marketing websites in 2026 still run on the same stack as in 2018. WordPress sits at 41.9% of all websites globally and 59.5% of sites with a known CMS — a near-monopoly that's barely shifted in years. On the server side, the picture is similar: Nginx, Apache, Cloudflare Server, and LiteSpeed cover the vast majority of traffic.
None of that is a problem on its own. The problem is what stacked on top: page builders (Elementor, Divi, Bricks), plugin sprawl (Yoast plus RankMath plus 30 more), and theme architectures that treat every page as a unique handcrafted document. That pattern works fine if your website's only job is to convert visitors who arrived from elsewhere.
It's not your website's only job anymore.
Three demand profiles your website now has to satisfy
The way to think about the modern marketing website isn't through one objective. It's through three, often pulling in slightly different directions:
Traditional organic search
Goal: organic traffic from Google's classic ranking systems.
- Crawlable HTML, server-rendered
- Page speed and Core Web Vitals
- Schema markup at the page level
- Internal linking and site architecture
- Depth, freshness, and editorial signal
- Canonicalisation and clean URLs
AI Search visibility
Goal: get cited in ChatGPT, Claude, Perplexity, Google AI Mode, AI Overviews.
- Entity recognition — clearly identifiable business
- Structured content as discrete, citable units
- Proof-rich claims with named sources
- Authorial credibility and bylines
- Fast deploy velocity (AI surfaces re-index often)
- Consistent definitions across every page
Paid lead generation
Goal: feed Google's AI Max with clean source material for ads, matching, landing pages, and agent answers.
- Consistent ad-copy source pages (text customisation reads them)
- Cleanly classified URL pool (Final URL expansion routes through it)
- Knowledge base for Business Agent for Leads — the agent inside the ad draws answers from your site
- Specific pages per Situation × Customer Type
- Brand voice and claim governance in copy
- High-quality conversion events feeding back
Where the popular stack falls short
Not philosophically — concretely. Six failure modes that show up in real audits:
- Content trapped in page-builder DOM. Elementor and Divi serialise content into divs nested ten deep. Crawlable, technically — but the semantic structure is invisible. AI engines extract entities from text; they don't reverse-engineer page-builder JSON.
- Schema added as plugin output, not derived from content. Yoast lets you tick "this is a Service page." It doesn't know which service, which customer types it serves, what proof supports it. Schema becomes a checkbox, not a model.
- Page-by-page authoring. Every new landing page is a manual rebuild. AI Max wants precise pages per Situation × Customer Type. Page-builder workflows can't keep up.
- No structured content model. Service descriptions live as inline copy on three different pages. When positioning changes, three editors update three pages, one forgets. AI Max reads contradictions.
- Plugin sprawl as the surface area for change. Every "we need to do X" answer is "install this plugin." The stack gets fatter, slower, more brittle, and more attack-prone every quarter.
- Slow deploys. Edit-in-admin feels fast, but staging-to-production cycles often take days because every change risks breaking something. AI Search surfaces re-index in hours. The mismatch compounds.
WordPress itself isn't the problem. Modern WordPress with block patterns, ACF custom fields, a lean theme, schema templates baked into theme code (not plugin-of-the-month), and a disciplined publishing workflow CAN serve all three demand profiles. The problem is that 95% of WordPress installs use the page-builder-plus-plugin workflow, which can't. Pick your fight: the workflow, not the platform.
Four stack patterns that meet the demands
There's no universal right answer. There are four real-world patterns that work, each with trade-offs. Pick based on team capability and editorial velocity, not vendor fashion.
Pattern A — WordPress
The default for ~42% of the web. Can serve all three demand profiles if run with discipline — block-pattern theme over page-builder DOM, custom fields via ACF or native blocks, schema generated from theme functions tied to the content model, plugin count under ten, editorial workflow that authors blocks rather than typing into page boxes. Without that discipline, WordPress is the version most teams quietly resent: plugin sprawl, page-builder spaghetti, slow deploys, accidental schema.
Best for: teams already on WordPress with developer capacity, content teams that need WYSIWYG editing, and businesses where the cost of migration outweighs the benefits of a different stack.
Pattern B — Webflow / Squarespace
Visual no-code builders with structured content built in. Webflow Collections and Squarespace's content blocks both support the kind of reusable, referenceable objects that AI Search and AI Max benefit from. Faster to launch than WordPress, no plugin sprawl, vendor-managed infrastructure with automatic security updates. Trade-offs: high vendor lock-in (your content lives in their format), limited custom schema beyond what the platform exposes, harder to extend with custom logic at scale.
Best for: marketing teams without dedicated developer capacity, design-led brands, sites with predictable content patterns, and businesses that prefer OPEX over engineering investment.
Pattern C — Headless CMS + modern front-end
Structured content in Sanity, Contentful, Storyblok, Strapi, or Payload. Front-end in Astro, Next.js, or SvelteKit. Edge hosting on Netlify, Vercel, or Cloudflare Pages. Schema auto-generated from content models. Editors get a clean admin in the vendor cloud; developers ship the templates.
Best for: serious growth brands, content-heavy marketing sites, teams with a developer + editor split, businesses that publish weekly or faster.
Pattern D — AI-Authored Stack (Claude Code + Git + Edge)
No CMS in the traditional sense. Pages authored as HTML files in a repo, deployed continuously through Git to edge hosting. An AI agent (Claude Code, Cursor, similar) is the publishing layer — it reads briefs, writes structured HTML, generates schema, opens pull requests. Editors review changes in Git or a Git-aware UI; deploys take seconds.
Best for: technical founders, small ops teams, agencies, and any team where the bottleneck is publishing velocity rather than editorial autonomy. Strong fit for sites that need to ship pages in hours, not days.
Side-by-side stack comparison
Same job, four ways to do it. Pick the column that matches how your team actually wants to operate.
| WordPress | Webflow / Squarespace | Headless CMS (Sanity + Astro) |
AI-Authored Stack (Claude Code + Git) |
|
|---|---|---|---|---|
| Editor experience | Block editor or page builder | Visual no-code, drag-drop | Headless admin (structured forms) | Git / IDE with AI agent |
| Structured content | Possible with ACF; often trapped in page-builder DOM | Built-in (Collections / content blocks) | First-class | Enforced by AI authoring |
| Schema quality | Plugin checkbox | Built-in basics; custom needs code | Auto from content model | Hand-written or AI-generated |
| Publishing velocity | Hours to days per page | Hours per page | Minutes per page | Seconds to deploy, minutes to author |
| Page load speed | Variable (heavy default, lean with care) | Fast (built-in CDN, optimised output) | Fast (SSG / SSR) | Fastest (static HTML) |
| AI Search fitness | Accidental (depends on theme + plugins) | OK (structured content, limited schema control) | By design | By design |
| Non-technical editing | Yes | Yes | Yes | Limited (Git or AI prompting required) |
| Cost — 10K visits/mo | $30-100/mo (managed WP + plugins) | $20-50/mo (platform plans) | $0-30/mo (Sanity + Netlify free tiers) | $20-100/mo (Netlify + AI usage) |
| Cost — 100K visits/mo | $200-500/mo (WP Engine / Kinsta growth tiers + security tools) | $50-300/mo (Webflow Business / Squarespace Commerce) | $120-300/mo (Sanity team + Netlify Pro + bandwidth) | $70-220/mo (Netlify Pro + bandwidth + AI usage) |
| Time to launch (10-page marketing site) | 4-12 weeks | 2-6 weeks | 6-10 weeks | 1-3 weeks (or hours per page with AI; content becomes the bottleneck) |
| Vendor lock-in | Low (self-hosted, exportable DB) | High (proprietary format, no easy export) | Medium (content exportable via API; front-end ties) | Low (flat HTML, Git-owned) |
Cost ranges are typical, not contractual — bandwidth, asset weight, and traffic shape change them. Time-to-launch numbers assume an experienced team for each pattern; from a cold start, add 50-100%. The build-process side of the time gap — what it actually takes to ship a website for the AI era — is its own piece, coming next in the series.
Security: not the headline, but a real trade-off
Every stack shifts security risk somewhere. The right question isn't "which stack is most secure?" — it's "which trade-off can your team actually manage?"
| Stack | Top vulnerabilities to watch | Pros | Cons |
|---|---|---|---|
| WordPress | Plugin CVEs (new ones weekly), brute-force admin login, SQL injection via outdated plugins, file-upload exploits, supply-chain attacks via compromised plugin updates, XSS via theme or plugin output, outdated PHP / dependencies, privilege escalation if user roles are loose. | Mature stack, well-documented vulnerabilities, large security tooling market (Wordfence, Sucuri). A lean modern setup with fewer than ten plugins meaningfully shrinks the footprint. | Largest attack surface on the web. Plugin supply-chain risk. Public admin login. Ongoing patching is a permanent operational cost. Routinely the most-compromised CMS. |
| Webflow / Squarespace | Account-takeover via credential reuse, third-party integration risks, form spam, exposed embed code, supply-chain risk via partner apps and integrations. | Vendor-managed infrastructure with automatic security updates. No server to patch. No public admin login on your domain. Audit-grade vendor security baseline as a floor. | Vendor security IS your security floor — you can't patch their infrastructure if a vulnerability surfaces. Less audit visibility into the underlying stack. Loss of vendor account = loss of site control. |
| Headless CMS (Sanity + Astro) | API token leakage (in client-side code, repos, build logs), webhook spoofing, misconfigured CORS / API permissions, vendor account compromise, dependency CVEs in front-end framework. | Admin lives in vendor cloud — not your server. No PHP / SQL runtime exposed publicly. CDN-fronted by default. | API key management becomes critical. Webhook abuse possible. Vendor security IS your security floor. Loss of vendor account = loss of CMS. |
| AI-Authored Stack (Claude Code + Git) | Form spam / serverless function abuse, Git repo access compromise (push access = site control), CI/CD secret leakage, edge function env-var exposure, dependency CVEs in any client-side scripts. | Smallest possible surface. No database. No public admin. Nothing dynamic to inject into on read. Every change reviewed in Git. | Forms and dynamic features need third-party services (Netlify Forms, serverless functions) — each adds a small surface. Non-technical editing requires a Git-aware UI or a thin admin layer. |
The honest position: a properly hardened WordPress is fine for most businesses with the discipline to keep it lean. Webflow and Squarespace shift the patching burden to the vendor — convenient, but their security floor becomes yours. A headless setup shifts risk to vendor and key management. An AI-authored / flat-HTML setup is the smallest surface but trades editor experience for it. Choose what your team can defend, not what scores best on a single dimension.
Two stacks for two jobs at Kaliber
We don't pretend there's one right stack. We run two — picked deliberately for what each site has to do.
kaliber.asia — this site
No CMS, no build step, no plugins. Pages are authored by Claude Code as the publishing layer — reads a brief, writes structured HTML, generates schema, opens a pull request. Deploys take 30-60 seconds. Every change is reviewed in Git. Attack surface: minimal.
kaliber.group — case studies
Structured content for case study production at scale. Editors author content objects (clients, results, KPIs, narrative blocks) in Sanity's headless admin without touching code. Astro composes the pages. Same edge hosting, different editorial workflow.
Both share the same output discipline: clean structured HTML that AI engines can crawl, classify, retrieve, and cite without ambiguity. The stack adapts to the editorial workload — the output discipline is constant.
Choosing the right stack — without rebuilding by reflex
The most expensive mistake is reflexive migration. Most teams should NOT start by rebuilding. Start by answering:
- Who edits? Five non-technical editors needing autonomous publishing → headless or modern WordPress. One technical operator → flat HTML or modern WP.
- How often do you publish? Monthly → any stack works. Weekly → modern WP minimum. Daily → headless or flat. Hourly during campaigns → headless or flat with AI authoring.
- How structured is the content? Mostly free-form blog posts and pages → traditional CMS is fine. Many product/service variants, location pages, comparison pages → structured content model required.
- What's the security posture? Regulated industry or high-value target → minimise surface (headless or flat). Otherwise → modern WP with proper hardening is acceptable.
- What's the budget profile? CAPEX-allergic, OPEX-friendly → existing WP. Comfortable with vendor-tier costs that scale with content → headless. Optimising for lowest ongoing cost → flat HTML.
- What's the team's tolerance for vendor lock-in? Low → WordPress or flat HTML. Comfortable trading lock-in for editor experience → headless.
The right stack is the one your team can run with discipline. A modest stack run well beats an ideal stack run badly.
Common mistakes when changing stacks
- Migrating before fixing the content model. A bad knowledge layer doesn't get better on a new platform. Model the objects first, then choose the publishing system that fits.
- Picking the trendy stack over the team's actual workflow. Headless is great if your team can run it. A team without dev capacity drowns in it.
- Treating it as a tech project, not a content operations change. The platform change matters less than what changes about how content gets authored, reviewed, and shipped.
- Underestimating editorial governance. Five editors publishing without review on any modern stack will produce the same inconsistency the old stack had.
- Forgetting forms, search, comments, and integrations. The marketing-site features that aren't pages — these are where most flat-HTML and headless migrations underestimate effort.
- Skipping the security trade-off conversation. Every stack shifts risk. Decide explicitly where it goes.
Frequently asked questions
Is WordPress still a viable stack for AI-era marketing?
Yes, but only the modern flavour. WordPress with block patterns, ACF custom fields, a lean theme, schema templates baked into the theme code (not plugin-of-the-month), and a clean publishing workflow can serve all three demand profiles — SEO, GEO, and AI Max — competently. WordPress + Elementor + 30 plugins + page-builder layouts is the version that's failing. The problem isn't WordPress. It's the page-builder-plus-plugin workflow most installs default to.
Do I need to migrate off WordPress to do GEO and AI Max well?
Not necessarily. If your team has the developer capacity to run modern WordPress with structured fields and clean theme code, you can satisfy GEO and AI Max without migrating. Migration becomes the right call when (a) editorial velocity is bottlenecked by page-builder rebuild cycles, (b) you need a structured content model that ACF can't comfortably express, or (c) your team is moving toward developer-led publishing and a headless workflow fits the org better.
What's the most underrated factor when choosing a stack?
Editorial governance, not technology. A great stack with no content team produces nothing. A modest stack with a disciplined editorial team produces compounding results. Before picking a stack, answer: who edits, how often, with what review process, and what gets measured? The answer narrows the stack choice more than any benchmark.
How does the stack affect security exposure?
Significantly. Self-hosted WordPress has the largest attack surface in the industry — public admin login, PHP + SQL runtime, plugin supply chain, ongoing patching cost. Headless CMSes shrink the surface by moving admin into vendor cloud and removing PHP/SQL from your server. Static and flat HTML sites have the smallest surface — nothing to inject into, no admin to brute-force, no database to exfiltrate. Each pattern shifts risk somewhere; pick the trade-off you can manage.
Is Webflow or Squarespace a credible AI-era stack?
Yes, for many marketing teams. Both support structured content via Collections (Webflow) or content blocks (Squarespace), produce server-rendered HTML, and ship with vendor-managed security updates so you're not patching plugins every week. The trade-offs are vendor lock-in (your content lives in their proprietary format), limited custom schema beyond what the platform exposes, and harder extension at enterprise scale. Webflow gives more design and structural control. Squarespace is faster to set up. Both beat plugin-heavy WordPress on velocity and security for most marketing-site use cases.
What does Kaliber actually run?
Two stacks for two jobs. kaliber.asia (this site) runs flat HTML, hosted on Netlify edge, with Claude Code as the publishing layer — no CMS, no build step, every page authored by an AI that knows the schema. kaliber.group (case studies and product showcase) runs Astro + Sanity + Netlify for structured content production at scale, with editors who don't touch code. Both share the same output discipline: clean structured HTML that AI engines can crawl, classify, retrieve, and cite without ambiguity.
Is flat HTML + an AI agent like Claude Code a realistic pattern for other teams?
It's realistic for teams that already work with version control, have at least one technical operator, and prioritise output speed over non-technical editorial autonomy. The trade-off: editors can't edit pages in a WYSIWYG admin. The gain: deploys take 30-60 seconds, every change is reviewed in git, schema is always consistent, and there's almost nothing to attack. Strongest fit for technical founders, small ops teams, and agencies. Wrong fit for teams where 5+ non-technical editors need autonomous publishing.
Where does Shopify fit for ecommerce?
Shopify remains the practical default for commerce — its product schema, structured product feeds, and third-party integration market are mature. The gap is on the content side: most Shopify stores are weak on educational, comparison, and situational content. The fix is either Shopify's content tools used disciplined (Metaobjects, structured collections) or a headless approach with Shopify storefront API + a content-grade front-end like Next.js or Hydrogen, fed by a structured CMS. The commerce stays on Shopify. The content gets a serious upgrade.