Technical GEO · CMS comparison
Which CMS to pick if you want AI to read your site
WordPress still runs almost 60% of the web that uses a content management system, but it's among the worst performers on Core Web Vitals. Next.js sits at the opposite end. We cover what a CMS is, how the main families compare, and what the evidence says about which performs best now that whoever "reads" you isn't just a person, but an AI crawler that doesn't execute JavaScript.
By the ArribaIA team · Updated
Citable summary
No single CMS brand is, on its own, "the best for GEO". What determines whether ChatGPT, Gemini, or Perplexity can read your site is whether the content already arrives built into the initial HTML, with consistent structured data and clear dates, because GPTBot and ClaudeBot download JavaScript but almost never execute it. A traditional CMS like WordPress renders server-side by default, but carries the worst Core Web Vitals pass rate (45% on mobile, versus 68% for Next.js sites). A headless CMS solves nothing on its own: it only helps if the frontend consuming it uses server-side or static rendering, like what we build with Next.js.
This summary condenses the guide into under 130 words on purpose: it's the kind of fragment an AI can cite without needing to read the rest of the page.
What is a CMS?
A CMS is where the content lives, not how it looks
A CMS (Content Management System) is the software that lets you create, edit, organize, and publish a website's content without writing every page by hand. It stores text, images, metadata, and structure, and decides (or delegates) how all of that turns into the HTML that reaches a browser or a crawler.
That last part is what has changed weight in recent years. For a long time, choosing a CMS was mostly a matter of editorial convenience. Today it's also a visibility decision: whoever builds the final HTML determines what a crawler can read, and unlike a person, a crawler doesn't always execute JavaScript or wait for the page to finish loading.
That's why it's worth separating two questions that tend to get mixed up: where content is managed and how it's delivered. The four families below answer that question differently, and that difference explains much of what follows in this guide, including its connection to local business authority and to AEO.
Manages and displays content in the same system
WordPress, Joomla, or Drupal in their classic mode. The CMS itself generates the HTML server-side (usually with PHP) from a database and templates. By far the family with the largest market share.
All-in-one, built to avoid touching code
Wix, Squarespace, GoDaddy Website Builder, or Webflow in their most common use. Visual editor, hosting, and content management bundled into a single closed package, with little room to adjust how the HTML is generated.
Manages the content, doesn't display it
Contentful, Sanity, Strapi, Storyblok, or Contentstack. They store and organize content and deliver it via API (REST or GraphQL), with no visual template of their own. The frontend is built separately, in whatever technology is chosen.
The frontend decides how and when it renders
Next.js, Astro, Nuxt, or Remix connected to a headless CMS (or to a WordPress instance used purely as a data source via its API). The development team controls whether each page is generated at request time (SSR), ahead of time (SSG), or incrementally (ISR).
The market, in numbers
Who uses what, today
Before comparing architectures, it's worth seeing the real starting point: where most of the web's content lives today and how it performs.
| Metric | Figure | Context |
|---|---|---|
| Sites that use some CMS | 69.6% | Out of all sites monitored by W3Techs as of August 2026. The rest use custom development or don't declare an identifiable CMS. |
| WordPress's share of the entire web | 41.2% | Equivalent to 59.1% of the known CMS market: more than half of all websites running a CMS use WordPress. |
| WordPress sites passing Core Web Vitals on mobile | 45% | Versus 85% for Duda or 74% for Wix, per the CMS chapter of HTTP Archive's 2025 Web Almanac. |
| Next.js sites passing Core Web Vitals on mobile | 68% | Versus 44% for a React SPA without server-side rendering, per the webvitals.tools benchmarks dashboard (April 2026). |
Comparison
Four families, four ways to deliver your content
No family is objectively superior across every dimension. Here's what actually changes between them, and what you genuinely need to weigh before choosing.
| Aspect | Traditional CMS | Website builder | Headless CMS | Framework + headless |
|---|---|---|---|---|
| Examples | WordPress, Joomla, Drupal | Wix, Squarespace, Webflow | Contentful, Sanity, Strapi, Storyblok | Next.js, Astro, Nuxt + headless CMS |
| Does the initial HTML already carry the content? | Yes, generated server-side with PHP on every visit | Depends: older builders relied on the browser, current ones already use server-side rendering | Not on its own: it's an API, entirely dependent on the frontend consuming it | Yes, if the team chooses server-side or static rendering instead of client-only |
| Who controls performance | The hosting, the chosen theme, and the installed plugins | The platform itself, with little room for manual tuning | Doesn't directly apply: performance is decided by the frontend, not the CMS | The team building the frontend, with near-total control |
| Learning curve | Low for basic use, medium to high with many plugins | Very low: built so you never touch code | Medium to high: needs a developer to build the frontend | High: requires a development team experienced with the framework |
| Typical cost | Low or no license fee, variable cost in hosting and plugins | Fixed monthly fee, all-inclusive | CMS fee plus frontend development and maintenance | Development cost plus hosting or headless CMS fee |
| Best for | Blogs, media outlets, and businesses with a large content team | Small businesses that need a website now, with no technical team | Brands publishing the same content across several channels (web, app, store) | Businesses prioritizing speed, technical control, and AI visibility |
Performance
Why server-side rendering matters so much now
Server-side rendering (SSR) and static rendering (SSG) generate the HTML before the browser or the crawler asks for it. Client-side rendering (CSR), typical of a plain JavaScript-built SPA, requires code to execute before the content can be seen.
Until recently, this was mostly a question of speed as perceived by people. That's no longer the case. A traffic analysis of AI crawlers by Vercel and MERJ found that none of the major AI crawlers execute JavaScript as a matter of course: GPTBot downloads JavaScript files on 11.5% of its requests and ClaudeBot on 23.84%, but neither one ever executes them. If a page's main content only appears after JavaScript runs in the browser, that crawler simply doesn't see it.
Google is the partial exception: Google-Extended inherits Googlebot's full rendering, so it can execute JavaScript, though at more cost and delay than reading already-built HTML. No other relevant AI crawler offers that same guarantee today.
Core Web Vitals data points the same way, even though it measures something different (real loading experience, not crawler legibility). Architectures that generate static or server-rendered HTML pass more often than those that rely on the browser to build the entire page.
| Technology | CWV pass rate | Source |
|---|---|---|
| Astro (static) | 84% on mobile | webvitals.tools, April 2026 |
| Eleventy (static) | 81% on mobile | webvitals.tools, April 2026 |
| SvelteKit (server) | 75% on mobile | webvitals.tools, April 2026 |
| Next.js (server or static) | 68% on mobile | webvitals.tools, April 2026 |
| Nuxt (server or static) | 60% on mobile | webvitals.tools, April 2026 |
| React without server-side rendering | 44% on mobile | webvitals.tools, April 2026 |
| WordPress | 45% mobile / 50% desktop | Web Almanac 2025 (mobile) and webvitals.tools, November 2025 (desktop) |
| Wix | 74% mobile / 82% desktop | Web Almanac 2025 (mobile) and webvitals.tools, November 2025 (desktop) |
This doesn't prove that switching CMS guarantees better numbers on its own: hosting, theme, installed plugins, and team discipline matter as much as the base technology. A well-maintained WordPress site can outperform a poorly built Next.js project. What is a consistent pattern in the data is that architectures designed to generate HTML ahead of time start with an advantage.
The million-dollar question
What's the best CMS for GEO?
There's no universal winner. What does exist are four traits that, based on technical documentation and several industry analyses, determine whether a CMS helps or gets in the way: whether the initial HTML already carries the content, whether it allows consistent structured data, whether it exposes dates and authorship clearly, and whether it makes it easy to organize content into chunks that answer a specific question.
Traditional CMS (well-configured WordPress)
Since it renders server-side by default, content is usually in the initial HTML without relying on JavaScript. The risk isn't that the crawler won't see the text, it's the buildup of plugins, heavy themes, and structured data poorly implemented by add-ons that don't always match what a person sees.
Website builder (Wix, Squarespace, Webflow)
Modern builders already use server-side rendering for the initial load (Wix has since 2020), so the historical problem of content invisible to crawlers is largely solved. What remains limited is control over markup, the types of structured data available, and the depth of technical customization.
Headless CMS alone
A headless CMS doesn't generate HTML: it only delivers data via API. Its fitness for GEO depends entirely on the frontend consuming it. A headless setup feeding a client-only rendered app can end up less legible to an AI crawler than a standard WordPress site.
Framework + headless with SSR or SSG (Next.js + Sanity, Contentful, or similar)
Combines structured content modeling, API delivery, and full control over when and how each page renders. Based on the performance data above, it's the combination most likely to serve complete, fast HTML with consistent structured data. It's also the one that demands the most technical investment to get right.
Having the highest technical ceiling doesn't automatically mean more visibility: a poorly implemented headless site can perform worse than a well-maintained WordPress. Architecture sets the limit of what's possible; content, authority, and consistency decide whether a brand actually reaches that limit, as we explain in more detail in what GEO is.
Pros and cons
The good and the bad of each family, no varnish
Traditional CMS
- Huge ecosystem of themes, plugins, and integrations
- Low entry curve for publishing content every day
- Renders server-side by default
- Very broad community and documentation
- Performance depends heavily on hosting, theme, and plugins
- The most frequent target for attacks, given its market share
- Easy to accumulate redundant or poorly maintained plugins
- Structured data generated by plugins doesn't always match visible content
Website builder
- A website can be live in hours, with no technical team
- All-inclusive: hosting, certificate, visual editor
- Major builders already use server-side rendering
- Minimal maintenance for the business owner
- Little control over HTML markup and structured data
- Migrating to another platform later tends to be costly
- Performance limited by the platform's own decisions
- Limited technical customization compared to custom development
Headless CMS
- The same content feeds web, app, and other channels at once
- Structured content modeling, treated as data rather than pages
- Full freedom to choose the frontend technology
- Usually eases advanced editorial workflows (roles, reviews, versions)
- Useless without a well-built frontend behind it
- Double cost: the headless platform plus frontend development
- Requires a permanent technical team, not just at launch
- More maintenance complexity than an all-in-one CMS
Framework + headless (Next.js and similar)
- Better average performance per available Core Web Vitals data
- Full control over what arrives in the initial HTML
- Fits naturally with structured data and chunked content
- Scales well from a simple landing page to a complex platform
- Higher upfront development cost than a traditional CMS
- Publishing new content may need technical support depending on setup
- Misusing client-side rendering cancels out much of the advantage
- Fewer prebuilt plugins: almost everything is custom-built
Before deciding
How to choose a CMS with AI in mind too
- 01Check whether the main content appears in the initial HTML without running JavaScript (visible by disabling it in the browser).
- 02Review whether the current theme or frontend generates structured data consistent with what a person sees.
- 03Measure real Core Web Vitals, not just a one-off PageSpeed snapshot.
- 04Confirm that publication and update dates are visible and correctly marked up.
- 05Count how many plugins or third-party dependencies each page loads, and what each one is for.
- 06Consider who's going to publish content day to day, not just who builds it once.
- 07If considering a migration, weigh the development and maintenance cost against the expected performance gain.
- 08Don't migrate CMS purely for GEO if the technical SEO foundation still has more urgent issues.
- 09Lean on an AI visibility audit before deciding, to know whether the problem is the platform or the content.
- 10If building from scratch, consider Next.js with server-side rendering as a starting point.
Frequently asked questions
What people ask most
Do I have to migrate from WordPress to Next.js for ChatGPT to read me?
Not necessarily. WordPress renders server-side by default, so content is usually in the initial HTML. The usual problem isn't the platform itself, it's the buildup of plugins, heavy themes, and poorly implemented structured data that many years-old installations carry.
Before planning a full migration, it makes more sense to audit what's actually failing: crawling, speed, structured data, or simply content that isn't very useful. That's exactly the starting point of an AI visibility audit.
Does a headless CMS automatically improve SEO or GEO?
No. A headless CMS doesn't generate HTML on its own, it only delivers content via API. Its effect on SEO or GEO depends entirely on how the frontend consuming it is built: if that frontend just renders client-side, it can end up less legible to an AI crawler than a standard WordPress site.
The real benefit of a headless CMS shows up when it's paired with a frontend using server-side or static rendering, not from being headless by itself.
Are Wix or Squarespace bad for AI visibility?
They no longer carry the historical problem of relying entirely on the browser: since 2020, Wix has used server-side rendering for the initial load, and Squarespace has followed a similar path. Main content is usually accessible to a crawler that doesn't execute JavaScript.
The real limitation is control: these platforms leave little room to adjust advanced structured data, information architecture, or performance beyond what the editor itself allows.
What about online stores on Shopify?
Shopify behaves similarly to a commerce-focused website builder: decent average performance (78% Core Web Vitals pass rate on desktop, per webvitals.tools) and server-side rendering by default in its standard themes, but with limited room once heavily customized with third-party apps, which tend to add extra JavaScript.
Is it worth migrating CMS purely for GEO reasons?
Rarely, if that's the only reason. Migrating platforms has a real cost (development, content, redirects, the team's learning curve) that's only justified if the current CMS is genuinely the bottleneck. In most cases, the room for improvement is earlier: in technical SEO, in structured data, or in how the content is written.
It makes more sense to migrate when building a new site from scratch, or when the current platform imposes technical limits that can't be solved with adjustments.
How do I check if my current website is legible to AI crawlers?
A simple, free way: disable JavaScript in the browser and reload the page. If the main content disappears or the page goes blank, it's very likely GPTBot, ClaudeBot, or PerplexityBot don't see it either, since none of the three execute JavaScript as a matter of course.
For a more complete review (structured data, crawling, architecture), we do that as part of our AI visibility audit.
Does structured data depend on which CMS I use?
Partly. A headless CMS or a framework like Next.js lets you define exactly which JSON-LD gets generated for each content type. In a traditional CMS or a website builder, structured data usually depends on a plugin or a built-in feature, with less room to adapt it to specific cases.
Either way, the rule doesn't change by platform: structured data must always match the content visible on the page. That's the work we do in LLM content optimization.
Sources
What we rely on
We always distinguish between official documentation, large-scale data reports, and industry analysis. A benchmark dashboard built by a company isn't the same as a platform's official documentation, and we flag it in every case.
- Professional analysis
Usage statistics of content management systems
W3Techs
A continuously updated dashboard of web technology usage statistics, with each CMS's market share out of all monitored sites and out of the set of sites with a known CMS.
w3techs.com/technologies/overview/content_management - Professional analysis
CMS | Web Almanac 2025
HTTP Archive
The content management chapter of HTTP Archive's annual report, with real Core Web Vitals data, page weight, and JavaScript usage by platform, aggregated from millions of sites.
almanac.httparchive.org/en/2025/cms - Professional analysis
Performance Benchmarks Dashboard
webvitals.tools
A dashboard that cross-references Chrome UX Report (CrUX) data with technology detection (Wappalyzer) to show the Core Web Vitals pass rate by framework and by CMS, updated monthly.
webvitals.tools/benchmarks/ - Professional analysis
The rise of the AI crawler
Vercel & MERJ
An analysis of real AI crawler traffic (GPTBot, ClaudeBot, PerplexityBot, and others) across Vercel's network, including the share of requests that download JavaScript without ever executing it.
vercel.com/blog/the-rise-of-the-ai-crawler - Official documentation
AI features and your website
Google Search Central
Google's official documentation on how AI Overviews and AI Mode work, and the real technical requirements for a page to be usable as a source.
developers.google.com/search/docs/appearance/ai-features - Official documentation
Integrating Next.js and Contentful for your Headless CMS
Vercel
Vercel's (Next.js's creator) official guide on connecting Next.js to a headless CMS, and why Next.js doesn't replace a CMS but pairs with one.
vercel.com/kb/guide/integrating-next-js-and-contentful-for-your-headless-cms - Official documentation
Headless CMS explained in one minute
Contentful
A reference explanation of what a headless CMS is and how it differs from a traditional or decoupled CMS.
www.contentful.com/headless-cms/ - Professional analysis
Tested: Is Wix Good For SEO?
Seobility
An independent analysis of Wix's technical evolution, including its move to server-side rendering for the initial load since 2020.
www.seobility.net/en/blog/wix-seo/ - Professional analysis
How to choose the best CMS for LLM SEO
Brightspot
A six-criteria technical framework (structured modeling, Schema.org support, API delivery, modularity, freshness signals, and editorial governance) for evaluating a CMS for AI system visibility. This is content published by a CMS vendor, so its product rankings have been treated with corresponding caution.
www.brightspot.com/cms-resources/cms-selection-guide/best-cms-for-llm-seo
Is your current CMS holding back your AI visibility?
We check whether your website's content already arrives built into the HTML, whether your structured data is consistent, and what would or wouldn't be worth migrating in your specific case, without recommending a platform change just because.