Kiwop portava anys amb una web en WordPress. Funcionava, però no ens representava. Havíem evolucionat cap a projectes de programari a mida, arquitectures headless i intel·ligència artificial aplicada, i la nostra pròpia web continuava sent un monòlit PHP amb plugins acumulats durant anys. Era com un fuster amb la porta de casa trencada.
Al gener de 2026 vam decidir aturar-nos i començar de zero. No un redisseny sobre WordPress, sinó una arquitectura completament nova. Aquest article explica per què, com i quins resultats hem obtingut.
La web anterior: què fallava
No és que la web estigués trencada. Carregava, es veia bé, tenia contingut. Però acumulava problemes que s'anaven agreujant:
Rendiment mediocre. WordPress amb els seus plugins de memòria cau, optimització d'imatges i page builders generava un HTML pesat. Els Core Web Vitals en mòbil no passaven de manera consistent, i Google cada cop penalitza més l'experiència d'usuari.
Seguretat exposada. WordPress és el CMS més atacat del món. El panell d'administració està a /wp-admin, els endpoints de l'API són coneguts, i cada plugin és una superfície d'atac potencial. Mantenir-lo actualitzat era una feina constant.
Rigidesa. Canviar el disseny d'una secció implicava tocar plantilles PHP, hooks, CSS inline del page builder i resar perquè no es trenqués una altra cosa. El contingut estava acoblat a la presentació.
Deute tècnic en contingut. Anys de publicacions havien deixat més de 240 articles de baixa qualitat, gairebé 200 duplicats de WPML sense traduir i desenes de pàgines thin content. Google ho veia tot, i l'autoritat del domini es diluïa.
La decisió: arquitectura headless
Quan diem "headless" no parlem d'una moda tecnològica. Parlem de separar dues coses que no tenen per què anar juntes: on es gestiona el contingut i com es mostra a l'usuari.
Què hi guanya el negoci amb això?
Velocitat real, no percebuda. El frontend genera HTML pur al servidor. No hi ha PHP interpretant a cada petició, no hi ha plugins carregant scripts innecessaris. El navegador rep exactament el que necessita, res més.
Seguretat per disseny. El CMS on s'edita el contingut no està exposat a internet. No hi ha /wp-admin per atacar. La superfície d'atac es redueix dràsticament.
Flexibilitat total. L'equip de disseny pot canviar qualsevol component visual sense tocar la base de dades del contingut. I l'equip editorial pot publicar sense preocupar-se de com es renderitza.
Escalabilitat. Servir una web en 7 idiomes des d'un sol frontend amb memòria cau multinivell és viable. Amb WordPress i WPML, cada idioma multiplicava la complexitat.
Astro + Payload CMS: per què aquesta combinació
Vam avaluar diverses opcions. Next.js, Nuxt, Remix per al frontend. Strapi, Directus, Sanity per al CMS. Vam triar Astro i Payload per raons molt concretes.
Astro genera HTML estàtic o renderitzat al servidor sense enviar JavaScript al navegador per defecte. Si una pàgina no necessita interactivitat, l'usuari rep HTML i CSS purs. El resultat: 0 mil·lisegons de Total Blocking Time. Zero. El fil principal del navegador queda lliure.
Payload CMS és un CMS headless sobre PostgreSQL amb una API REST neta i tipat complet en TypeScript. A diferència de Strapi o Sanity, Payload s'autoallotja: les nostres dades estan a la nostra base de dades, no en un SaaS extern. Per a una agència que gestiona dades de clients, això no és negociable.
La combinació resol un problema real: contingut gestionat de manera professional, presentat amb un Lighthouse de 97 i 0 ms de bloqueig al navegador, sense dependències externes ni vendor lock-in.
El procés: 35 dies, 230 commits
No va ser un projecte de sis mesos. Des del primer commit el 10 de gener de 2026 fins a la versió en producció, van passar 35 dies. 230 commits. Un equip reduït amb objectius clars.
Fase 1: estructura i components (setmanes 1-2)
Vam definir l'arquitectura modular: 14 components de secció reutilitzables (hero, grid de serveis, procés per passos, FAQs, CTAs) que es combinen com a blocs per construir qualsevol pàgina de servei. Cada servei es defineix amb un fitxer de configuració per idioma, sense tocar codi.
La decisió més important va ser no fer servir cap framework de JavaScript al client. Sense React, sense Vue, sense Svelte. Astro pur amb islands architecture per als pocs components que necessiten interactivitat (com el chatbot). El resultat: un bundle de JS proper a zero per al 95% de les pàgines.
Fase 2: multiidioma (setmana 3)
Vam passar de 3 idiomes (espanyol, anglès, català) a 7 (hi vam afegir alemany, francès, neerlandès i portuguès). Això va implicar:
- Un sistema centralitzat de traduccions per a tota la interfície, gestionat des d'un sol fitxer.
- Hreflang correcte amb fallback desactivat per evitar que Google indexés contingut sense traduir.
- URLs netes per idioma sense trailing slash (1.001 URLs indexades a Google Search Console, totes coherents).
Un detall que ens va costar hores: la regex de detecció d'idioma a les URLs. Un patró incorrecte feia match de /ca dins de /casos-de-exito, trencant les rutes en català. Sembla trivial, però en una web amb més de 2.000 pàgines, un bug així és catastròfic per al SEO.
Fase 3: migració de contingut i neteja (setmana 4)
Vam migrar tot el blog de WordPress a Payload CMS. Però no va ser un bolcat directe: vam aprofitar per fer una auditoria brutal del contingut.
- 243 articles tòxics eliminats (contingut de baixa qualitat, irrellevant o desactualitzat)
- 199 duplicats de WPML despublicats (versions en anglès i català que eren còpies sense traduir de l'espanyol)
- 31 pàgines thin content eliminades amb codis 410 a nginx
- 3 parells de posts duplicats consolidats amb redireccions 301
- 885 títols retallats a menys de 60 caràcters
- 333 meta descriptions ajustades a menys de 160 caràcters
Aquesta neteja va ser deliberada. La Helpful Content Update de Google penalitza a nivell de lloc web. Tenir 200 pàgines escombraries arrossega cap avall les 700 bones.
Fase 4: SEO i rendiment (setmana 5)
Auditoria de heading hierarchy a les 2.114 pàgines del lloc: 0 errors, 0 warnings. Cada pàgina té una estructura semàntica correcta, des de H1 fins a H4.
Vam implementar un sistema de memòria cau de 4 capes (Payload CMS, Redis SWR, nginx SSR i Cloudflare CDN) amb purga ordenada. L'ordre importa: si purgues Cloudflare però Payload encara té memòria cau antiga, nginx torna a guardar dades antigues immediatament. Sembla obvi per escrit, però ho vam aprendre depurant per què els canvis no apareixien en producció.
El paper de la IA
Seria deshonest no esmentar-ho: vam fer servir IA com a eina de desenvolupament durant tot el procés. No per generar codi a cegues, sinó com un company de programació que ens va ajudar a auditar 2.000+ pàgines, detectar inconsistències de SEO a escala i automatitzar tasques repetitives com la normalització de títols en 7 idiomes.
La IA no va dissenyar l'arquitectura ni va prendre decisions de negoci. Però va accelerar significativament l'execució, especialment en les fases d'auditoria i neteja de contingut.
Resultats: els números
Rendiment (Lighthouse)
Les puntuacions de Lighthouse sobre la web en producció:
- Performance: 97/100 (mòbil i escriptori)
- Accessibilitat: 100/100
- Bones pràctiques: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2,2 segons — aprovat (llindar de Google: < 2,5 s)
- TBT (Total Blocking Time): 0 mil·lisegons — aprovat (llindar: < 200 ms)
- CLS (Cumulative Layout Shift): 0 — aprovat (llindar: < 0,1)
TBT de 0 mil·lisegons significa que el navegador no es bloqueja en cap moment. CLS de 0 significa que res no es mou mentre la pàgina carrega. Aquests números no són teòrics: són mesuraments reals sobre la web en producció.
Impacte en cercadors
La neteja de contingut va produir un efecte esperat: menys impressions totals (vam eliminar centenars de pàgines), però millor qualitat en el que queda.
- CTR: +27,8% (de 0,17% a 0,22%)
- Posició mitjana: +9,3 posicions (de 50,6 a 41,3)
- Posició mitjana en mòbil: +13,6 posicions (de 36,9 a 23,3)
Menys volum, més qualitat. Les pàgines que queden posicionen millor i converteixen més. És l'estratègia correcta quan la prioritat és atraure clients, no acumular visites buides.
Escala
- 2.114 pàgines auditades i funcionals
- 7 idiomes des d'una sola base de codi
- ~1.600 articles de blog publicats (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Desplegaments sense downtime amb rollback automàtic
Què significa això per als nostres clients
Aquesta web no és només el nostre aparador. És la demostració pràctica del que fem.
La mateixa arquitectura headless que mou kiwop.com — separació de frontend i CMS, memòria cau multinivell, multiidioma natiu, rendiment PageSpeed 97+ — és exactament el que implementem en projectes de clients.
Si la teva web actual:
- Tarda més de 3 segons a carregar en mòbil
- Depèn de WordPress amb 20 plugins per funcionar
- Té problemes de seguretat recurrents
- No escala bé a múltiples idiomes o mercats
- Acumula deute tècnic que frena cada canvi
Hi ha una alternativa provada. No teòrica: l'estàs veient ara mateix.