WordPress vs. Headless CMS: A Case Study on Our Own Agency Relaunch
WordPress vs. Headless CMS: we’ve used both for years. And because of that, we have a clear recommendation. This case study is about how, after an SEO crash with headless, we deliberately took a step back to WordPress: in summer 2023 we migrated our agency website from WordPress to a headless setup with Strapi and Nuxt. The goal was a modern architecture, clean content models, and a clean technical cut. The result was sobering: our organic visibility and clicks dropped by more than 90 percent. On December 8, 2025, we went live again – this time with a visually almost identical appearance, but back on a WordPress foundation. Since then, our visibility has been rebuilding measurably and steadily. Within three weeks, the Seobility visibility score for our tracked keywords rose from 30 to 69.
This case study on WordPress vs. Headless CMS shows why that happened and what conclusions we’ve drawn from it.
Starting Point: WordPress Was Fine, But the Trend Pointed Toward Headless CMS
Before our first relaunch, our website was running on classic WordPress. Technically the system was solid, the content had grown organically, and SEO-wise we were stable. Rankings, internal links, and historical content had been built up over years.
This is what our old website looked like before the 2023 relaunch – it first went live with this user interface back in 2016:
WordPress wasn’t an innovation project, it was a working foundation. I liked the old website. It ran reliably for years. Its design was still modern and would probably still be better today than most of our agency competitors’ websites. A relaunch is rarely necessary. We chose to do one anyway. And with that I directly violated the first recommendation in my own relaunch checklist: avoid a relaunch as long as possible. Improve incrementally rather than attempting the big swing. My backend developer even warned us not to do it. My Head of Development was excited about the project, and I also wanted our agency to be at the cutting edge of the most modern web solutions – which is why we adopted the AVIF image format in our web projects early and also like to use HTTP3 … though here too with unexpected side effects.
In the following video, I explain without any marketing fluff what matters when choosing between WordPress and Headless CMS, and how to make the best decision for your situation.
Relaunch 1: WordPress → Strapi + Nuxt (Summer 2023)
The switch to headless was a deliberate (wrong) decision. A relaunch without real necessity. We wanted:
- a modern architecture
- a clear separation of content and frontend
- better maintainability at the code level
- a solution that would scale long term
Strapi is a headless CMS (API-first) where the backend (content) and frontend (website/app) are completely separated. Content is delivered via REST or GraphQL. We implemented the whole thing with Nuxt.
WordPress, by contrast, is a monolithic CMS (backend + frontend in one system) where content and presentation are directly coupled. (Though it can also be used headlessly if needed.) While WordPress has a huge ecosystem of themes and plugins and the largest developer community, getting started with a headless CMS is more demanding. That became clear in our team as well. While all five of my developers know WordPress inside out, only my Head of Development was specialized in Nuxt. And the onboarding time is significantly higher.
We spent months conceiving a new user interface, preparing images, creating content, and above all coding. In parallel, we also cleaned up content, removed outdated blog articles, and consolidated topics. What we underestimated: the SEO impact of this overall package.
Headless CMS vs. WordPress: The Comparison
To understand the different criteria where Headless CMS and WordPress each have their characteristics and advantages, take a look at this table.
| Criterion | Headless CMS | WordPress |
| Architecture | API-first, backend and frontend separated | Monolithic (backend + frontend integrated) |
| Initial HTML delivery | Depends on SSR/pre-rendering | Content server-side in HTML by default |
| SEO robustness | Highly dependent on rendering setup | Very robust with a clean setup |
| Multilingual support | Custom-built (API logic) | Standardized via WPML/Polylang |
| MultiSite capability | Technically possible, but custom | Natively integrated WordPress MultiSite |
| Shop integration | API-based, flexible, but complex | WooCommerce integrates seamlessly |
| Accessibility (WCAG/BFSG) | Fully controllable, but fully your responsibility | Easy to implement with a clean theme |
| Content workflow | Editorial UI often technical, can also be editor-friendly | Very editor-friendly |
| Team dependency | Often requires framework specialists | Broad ecosystem and plenty of available developers |
| Maintenance effort | Higher (build process, dependencies) | Predictable and standardized |
| Update safety | Framework updates can bring breaking changes | Core is stable, plugin strategy is key |
| Time-to-market | Longer | Significantly faster |
| Cost (initial) | Usually higher | Usually lower |
| Cost (operating) | Higher with custom architecture | Easy to plan |
| Suitability for a classic corporate website | Only worthwhile with a platform/multichannel strategy | Very well suited |
What Went Wrong with the Headless Relaunch: Visibility Down 90 Percent
We went live in summer 2023 full of confidence that we were starting a new chapter in web development on our side. As the following chart shows, our visibility had already been declining. The relaunch would fix it. Sure …
What happened on relaunch day? The visibility trend shows a clear cliff edge. Within a very short time, almost all rankings were gone. In the months that followed, almost nothing moved. It looked almost as if we had gone live with noindex, but that wasn’t the case.
Looking back, it only became clear over time that the drastic drop in visibility wasn’t triggered by a single measure, but by the interplay of several factors. The switch to a headless setup with Strapi and Nuxt meant not only a technology change, but also a fundamental shift in how our content was being delivered to search engines.
In parallel with the technical relaunch, we had deliberately reduced our content. Outdated blog articles were deleted, topics were merged, and the overall offering was slimmed down. This decision made sense content-wise, but in combination with the headless setup it had serious side effects.
Some of the deleted content had built up rankings, internal links, and external signals over the years. Those historical relevance signals were completely lost. While classic CMS setups often absorb such cuts better, in the headless context this loss of trust hit an already compromised crawlability. For Google, the impression was of a significantly changed, unstable domain that was hard to classify.
The result was not a short-term correction but a months-long phase in which Google still knew the website but barely actively evaluated it anymore. This „SEO limbo“ lasted almost six months, and in hindsight it’s a sign of a fundamental re-evaluation of our domain. We also made it hard for Google at the start with self-inflicted problems on the website.
Although Google can render JavaScript in principle, in practice this process is two-step and error-prone. A significant portion of content, meta information, and internal links were not fully visible to the crawler in the initial HTML, but only became available after client-side hydration. As a result, Google was missing key signals for page classification in the first crawl phase. The consequence wasn’t a selective downgrade of individual URLs, but an almost complete loss of organic visibility at the domain level.
On top of that, structured data, canonicals, and meta information were not always delivered server-side and consistently. For humans, the website was fully usable; for search engines, however, it wasn’t clearly interpretable. The crawlers had real trouble accessing the content, as a look at Search Console at the time revealed. This kind of discrepancy is typical of many headless setups when SEO isn’t treated as an equal discipline in the architecture from the start. And that’s on us.
Another effect became visible in Search Console: for several weeks we received no crawling requests at all. My developer addressed it, and only from the beginning of September did crawl requests start picking up again. During that phase, our pages were effectively no longer being crawled and evaluated – functionally equivalent to being temporarily de-listed.
In hindsight, one design flourish in particular was problematic: a pre-loading animation that briefly delivered an empty page before the actual content loaded. In the following screenshot, on the right, you can see the dark background with our logo, which was shown briefly and then faded away on its own. For users it felt modern; for Google, it looked like two separate pages. In practice, often only the empty page was crawled. That single decision had a massive impact on crawling, rendering, and ultimately the domain’s overall visibility.
In 2024 we then ran a proper PageSpeed sprint, getting our mobile and desktop scores up to 90+.
In a direct comparison, you can see we weren’t the only ones struggling with performance initially. WordPress is considered sluggish by many, and I often read WordPress-bashing. From my point of view, that tends to come from people without a real tech background clicking sites together with Elementor. Across technology comparisons, looking at Core Web Vitals classified as good, WordPress actually comes out ahead of Nuxt.js, Next.js, and of course Elementor (source):
The Underestimated Dependency on Specialist Know-How
Another aspect that became increasingly evident in day-to-day operations was the strong dependency on specialized developer knowledge. The Strapi setup was customized, update-sensitive, and in large parts fully understood by only one person on our team. Smaller changes, bugfixes, or updates consistently required deep re-familiarization and led to delays.
In contrast, WordPress is broadly anchored across our team. All five developers are extremely strong in WordPress, updates and feature requests are standard processes, and problems can be solved quickly and independently of each other. This team compatibility of a technology is often underestimated in system decisions, including by us. It has a direct impact on the stability, speed, and long-term maintainability of a website.
In 2024 and 2025 our focus was mainly on our own project TutKit.com, which meant the agency website was always second priority in the project pipeline. Agency work came mostly from our network, so the drop in rankings didn’t really affect our day-to-day business. We barely noticed, because we weren’t really checking. Things were going well overall in the company and on our projects. So we never found the time to fix all the issues to the end, and somehow never got around to upgrading our entire dev team to headless development. Our client projects continued to be built with WordPress.
Looking back, several factors came together and reinforced each other, leading to our (self-inflicted) problems:
- a headless setup with error-prone initial delivery
- a simultaneous content reduction without full relevance inheritance
- JavaScript-dependent navigation and internal linking
- technical gimmicks that blocked crawlers
- a lack of resources to address all issues in time
The Second Relaunch: Same Website, Different Foundation
When we decided in late summer to switch back to WordPress, one point was fundamental: this wasn’t a classic relaunch. The interface, content, and URL structure remained completely unchanged. Only the technical foundation was replaced. On December 8, 2025, we went live with the rebuilt user interface on the WordPress codebase we know so well. We also took the opportunity to optimize our in-house developed WordPress theme. As an agency, we’re not fans of clicky-colorful page builders like Elementor or other website kits. We want lean code for our sites and full control over everything. So we built our own theme with a curated set of pre-installed plugins and a structure based largely on Advanced Custom Fields. Unlike the 2023 relaunch, we locked in all the important quality benchmarks already in the development environment and were able to go live with top scores in on-page quality, security, and PageSpeed right from the start.
WordPress sites don’t inherently perform badly. We’ve optimized performance to 96 on mobile, even though we also run such heavyweight plugins as WPML for multilingual support:
Right out of the gate with high on-page quality at a 96 percent score: with the help of Seobility, we lock in technical, structural, and content quality for a relaunch in our projects:
Within a few weeks it became clear that Google could crawl the pages much faster and more consistently. Content was immediately present in the HTML, metadata and structured information were available right away, and internal links were fully visible without JavaScript. The search engine received clear, stable signals again.
The result was a rapid rebuild of visibility for the keywords we track. The Seobility visibility score rose from 30 to 69 within three weeks, the number of ranking keywords grew steadily, and the trend pointed clearly upward. An effect this fast wouldn’t be explainable without a fundamental technical improvement. And I suspect this is just the beginning. Next year I’ll publish an update to this chart here.
Why WordPress Was the Better Choice in This Case
This case study is not a blanket verdict against headless CMS. Systems like Strapi have their strengths in complex platforms, app integrations, and multichannel scenarios. For an SEO-driven agency website with a strong content focus, however, WordPress turned out to be the more robust and economical solution.
WordPress delivers content, metadata, and semantic structures immediately and consistently. Errors are more easily forgiven by search engines, changes are re-evaluated faster, and relaunches overall carry less risk. Combined with broad know-how available in the team, this creates a stability that is crucial in a marketing and SEO context.
For us, this failure was an expensive investment – one that led us to consistently deploy data-based validation tools to secure client projects before going live. We’ve moved away from the mindset that certain issues can be fixed later, on the fly. Later is a point in time that rarely comes, or comes too late, because other topics and tasks always end up on the agenda.
Switching back to WordPress was not a nostalgic decision but a pragmatic one. Modern architecture is not an end in itself. What matters is how reliably a system transports content, how well it’s mastered by the team, and how stable it performs under real SEO conditions. If even we as a tech agency struggled with this, every company should think hard about whether such technical experiments are worth the risk. This experience has lastingly changed our decision-making processes. And we’re glad to see visibility clearly trending upward now.
Update February 2026: Visibility Continues to Grow
In early February we also noticed that the number of top 10 and top 100 URLs has made a nice jump. We’re catching up again to where we were back in the old WordPress days before the botched relaunch to Headless CMS Strapi.
The agency relaunch back to WordPress also demonstrates strategically how important a stable, SEO-friendly system is for sustainable visibility and content-driven growth.
FAQ on Headless CMS vs. WordPress
A headless CMS like Strapi fully separates the backend (content management) and the frontend (presentation). Content is delivered via API (REST/GraphQL) to a framework like Nuxt.js.
WordPress is monolithic by default: content, templates, metadata, and internal links are delivered directly server-side as ready-made HTML.
It depends on your goal. For content- and SEO-driven websites, WordPress is often the more robust choice, because content, meta data, and internal links are typically present immediately in the HTML. Headless is worth it when you need multichannel (apps, multiple frontends, real-time interactivity) or very custom platform logic.
In many projects, WordPress is cheaper both in implementation and in operation, because setup, hosting, updates, and standard features are faster to provision (ecosystem, plugins, proven patterns). About 43% of all websites run on WordPress. That means you also have the largest developer community in the world available for WordPress work. Headless is often more expensive because you develop backend and frontend separately and need more custom engineering – and far fewer developers actually know their way around it.
Long term, headless can get more expensive when:
updates/dependencies (frameworks, build pipeline) require regular work
knowledge is concentrated in a few specialists
SEO fine-tuning (rendering, metas, structured data) has to be constantly kept in sync
WordPress is often – if not always – cheaper when you work without page-builder bloat and properly secure performance and quality.
For search engines and LLMs, clearly structured, immediately available content (including semantic signals) is easier to interpret and evaluate.
Headless architectures aren’t inherently bad for SEO. Problems arise when:
content is only hydrated client-side via JavaScript
meta data, canonicals, or structured data are not delivered consistently server-side
navigation and internal links depend on JavaScript
crawling is disrupted by animations or technical in-between pages
Search engines like Google can render JavaScript, but in a two-step process. If central content isn’t present in the initial HTML, important relevance signals are missing.
For citations in AI answer systems, another factor comes in: an LLM lookup during real-time search works under strict latency constraints. Slow response times prevent pages from being added to the candidate pool, because they miss the retrieval window.
No. Architecture alone doesn’t decide. What matters is:
server-side delivery of central content
clean information architecture
consistent structured data
stable crawlability
in-house team know-how
There will be companies that demonstrate they achieve great SEO and GEO success with their headless CMS. But they are the exception. If even we as a real tech agency had our challenges, for most companies an SEO focus with WordPress will be economically more robust and lower risk.
Technology is only as stable as the team that maintains it. When a system:
is update-sensitive
is only fully mastered by one person
requires long onboarding time
the operational risk rises. Google also indirectly evaluates stability, maintainability, and consistency through technical signals.
Headless is especially worthwhile with:
multiple output channels (website + app + screens + API partners)
large product or content platforms with custom logic
teams that strongly master frontend frameworks and can demonstrably solve SEO and GEO cleanly
WordPress is strong for:
marketing websites, SEO landing pages, blogs, case studies
teams that want to iterate quickly
projects where maintainability and editorial flow are central
MultiSite/multilingual setups (depending on the configuration)
shop integrations via WooCommerce
There’s hardly an area where WordPress currently doesn’t deliver. WordPress is also less maintenance-heavy, because updates, security patches, and content workflows are standardized. Headless is maintainable, but usually only with more engineering (dependencies, build processes, monitoring).