Kiwop had been running on a WordPress website for years. It worked, but it no longer represented us. We had evolved toward custom software projects, headless architectures and applied artificial intelligence, yet our own website was still a PHP monolith with plugins piled up over the years. It was like a carpenter with a broken front door.
In January 2026, we decided to stop and start from scratch. Not a redesign on top of WordPress, but an entirely new architecture. This article explains why, how, and what results we have achieved.
The Previous Website: What Was Failing
It is not that the website was broken. It loaded, it looked fine, it had content. But it had accumulated problems that kept getting worse:
Mediocre performance. WordPress with its caching plugins, image optimization tools and page builders generated bloated HTML. Mobile Core Web Vitals were not passing consistently, and Google increasingly penalizes poor user experience.
Exposed security. WordPress is the most attacked CMS in the world. The admin panel sits at /wp-admin, API endpoints are well known, and every plugin is a potential attack surface. Keeping it updated was a constant effort.
Rigidity. Changing the design of a section meant touching PHP templates, hooks, the page builder's inline CSS, and hoping nothing else would break. Content was tightly coupled to presentation.
Content technical debt. Years of publishing had left over 240 low-quality articles, nearly 200 untranslated WPML duplicates, and dozens of thin content pages. Google could see all of it, and the domain's authority was being diluted.
The Decision: Headless Architecture
When we say "headless," we are not talking about a tech trend. We are talking about separating two things that do not need to be tied together: where content is managed and how it is displayed to the user.
What does the business gain from this?
Real speed, not perceived speed. The frontend generates pure HTML on the server. There is no PHP interpreting on every request, no plugins loading unnecessary scripts. The browser receives exactly what it needs, nothing more.
Security by design. The CMS where content is edited is not exposed to the internet. There is no /wp-admin to attack. The attack surface is drastically reduced.
Total flexibility. The design team can change any visual component without touching the content database. And the editorial team can publish without worrying about how things are rendered.
Scalability. Serving a website in 7 languages from a single frontend with multi-layer caching is feasible. With WordPress and WPML, every language multiplied the complexity.
Astro + Payload CMS: Why This Combination
We evaluated several options. Next.js, Nuxt, Remix for the frontend. Strapi, Directus, Sanity for the CMS. We chose Astro and Payload for very specific reasons.
Astro generates static or server-rendered HTML without sending JavaScript to the browser by default. If a page does not need interactivity, the user receives pure HTML and CSS. The result: 0 milliseconds of Total Blocking Time. Zero. The browser's main thread stays completely free.
Payload CMS is a headless CMS built on PostgreSQL with a clean REST API and full TypeScript typing. Unlike Strapi or Sanity, Payload is self-hosted: our data lives in our own database, not on an external SaaS. For an agency that handles client data, this is non-negotiable.
The combination solves a real problem: professionally managed content, delivered with a Lighthouse score of 97 and 0 ms of browser blocking, with no external dependencies or vendor lock-in.
The Process: 35 Days, 230 Commits
This was not a six-month project. From the first commit on January 10, 2026, to the production release, it took 35 days. 230 commits. A small team with clear objectives.
Phase 1: Structure and Components (Weeks 1-2)
We defined the modular architecture: 14 reusable section components (hero, service grid, step-by-step process, FAQs, CTAs) that combine like building blocks to create any service page. Each service is defined with a configuration file per language, without touching code.
The most important decision was not using any client-side JavaScript framework. No React, no Vue, no Svelte. Pure Astro with islands architecture for the few components that need interactivity (like the chatbot). The result: a JS bundle close to zero for 95% of pages.
Phase 2: Multi-Language (Week 3)
We went from 3 languages (Spanish, English, Catalan) to 7 (adding German, French, Dutch and Portuguese). This involved:
- A centralized translation system for the entire interface, managed from a single file.
- Correct hreflang with fallback disabled to prevent Google from indexing untranslated content.
- Clean URLs per language without trailing slash (1,001 URLs indexed in Google Search Console, all consistent).
One detail that cost us hours: the regex for language detection in URLs. An incorrect pattern was matching /ca inside /casos-de-exito, breaking Catalan routes. It seems trivial, but on a website with over 2,000 pages, a bug like that is catastrophic for SEO.
Phase 3: Content Migration and Cleanup (Week 4)
We migrated the entire blog from WordPress to Payload CMS. But it was not a straight dump: we took the opportunity to run a thorough content audit.
- 243 toxic articles removed (low-quality, irrelevant or outdated content)
- 199 WPML duplicates unpublished (English and Catalan versions that were untranslated copies of the Spanish originals)
- 31 thin content pages removed with 410 status codes in nginx
- 3 pairs of duplicate posts consolidated with 301 redirects
- 885 titles trimmed to under 60 characters
- 333 meta descriptions adjusted to under 160 characters
This cleanup was deliberate. Google's Helpful Content Update penalizes at the site level. Having 200 junk pages drags down the 700 good ones.
Phase 4: SEO and Performance (Week 5)
Heading hierarchy audit across all 2,114 pages on the site: 0 errors, 0 warnings. Every page has a correct semantic structure, from H1 through H4.
We implemented a 4-layer caching system (Payload CMS, Redis SWR, nginx SSR and Cloudflare CDN) with ordered purging. The order matters: if you purge Cloudflare but Payload still has stale cache, nginx re-caches old data immediately. It seems obvious in writing, but we learned it the hard way debugging why changes were not showing up in production.
The Role of AI
It would be dishonest not to mention it: we used AI as a development tool throughout the entire process. Not to generate code blindly, but as a pair programmer that helped us audit 2,000+ pages, detect SEO inconsistencies at scale, and automate repetitive tasks like normalizing titles across 7 languages.
AI did not design the architecture or make business decisions. But it significantly accelerated execution, especially during the content audit and cleanup phases.
Results: The Numbers
Performance (Lighthouse)
Lighthouse scores on the production website:
- Performance: 97/100 (mobile and desktop)
- Accessibility: 100/100
- Best Practices: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2.2 seconds -- passed (Google threshold: < 2.5 s)
- TBT (Total Blocking Time): 0 milliseconds -- passed (threshold: < 200 ms)
- CLS (Cumulative Layout Shift): 0 -- passed (threshold: < 0.1)
A TBT of 0 milliseconds means the browser never blocks at any point. A CLS of 0 means nothing shifts while the page loads. These numbers are not theoretical: they are real measurements taken on the production website.
Search Engine Impact
The content cleanup produced an expected effect: fewer total impressions (we removed hundreds of pages), but better quality in what remains.
- CTR: +27.8% (from 0.17% to 0.22%)
- Average position: +9.3 positions (from 50.6 to 41.3)
- Mobile average position: +13.6 positions (from 36.9 to 23.3)
Less volume, more quality. The pages that remain rank better and convert more. This is the right strategy when the priority is attracting clients, not accumulating empty visits.
Scale
- 2,114 pages audited and functional
- 7 languages from a single codebase
- ~1,600 blog articles published (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Zero-downtime deploys with automatic rollback
What This Means for Our Clients
This website is not just our showcase. It is the practical demonstration of what we do.
The same headless architecture that powers kiwop.com -- separation of frontend and CMS, multi-layer caching, native multi-language support, PageSpeed 97+ performance -- is exactly what we implement in client projects.
If your current website:
- Takes more than 3 seconds to load on mobile
- Depends on WordPress with 20 plugins to function
- Has recurring security issues
- Does not scale well to multiple languages or markets
- Accumulates technical debt that slows down every change
There is a proven alternative. Not theoretical: you are looking at it right now.
