Kiwop llevaba años con una web en WordPress. Funcionaba, pero no nos representaba. Habíamos evolucionado hacia proyectos de software a medida, arquitecturas headless e inteligencia artificial aplicada, y nuestra propia web seguía siendo un monolito PHP con plugins acumulados durante años. Era como un carpintero con la puerta de casa rota.
En enero de 2026 decidimos pararla y empezar de cero. No un rediseño sobre WordPress, sino una arquitectura completamente nueva. Este artículo cuenta por qué, cómo y qué resultados hemos obtenido.
La web anterior: qué fallaba
No es que la web estuviera rota. Cargaba, se veía bien, tenía contenido. Pero acumulaba problemas que se iban agravando:
Rendimiento mediocre. WordPress con sus plugins de caché, optimización de imágenes y page builders generaba un HTML pesado. Los Core Web Vitals en móvil no pasaban de forma consistente, y Google cada vez penaliza más la experiencia de usuario.
Seguridad expuesta. WordPress es el CMS más atacado del mundo. El panel de administración está en /wp-admin, los endpoints de la API son conocidos, y cada plugin es una superficie de ataque potencial. Mantenerlo actualizado era un trabajo constante.
Rigidez. Cambiar el diseño de una sección implicaba tocar plantillas PHP, hooks, CSS inline del page builder y rezar para que no se rompiera otra cosa. El contenido estaba acoplado a la presentación.
Deuda técnica en contenido. Años de publicaciones habían dejado más de 240 artículos de baja calidad, casi 200 duplicados de WPML sin traducir y decenas de páginas thin content. Google lo veía todo, y la autoridad del dominio se diluía.
La decisión: arquitectura headless
Cuando decimos "headless" no hablamos de una moda tecnológica. Hablamos de separar dos cosas que no tienen por qué ir juntas: dónde se gestiona el contenido y cómo se muestra al usuario.
¿Qué gana el negocio con esto?
Velocidad real, no percibida. El frontend genera HTML puro en servidor. No hay PHP interpretando en cada petición, no hay plugins cargando scripts innecesarios. El navegador recibe exactamente lo que necesita, nada más.
Seguridad por diseño. El CMS donde se edita el contenido no está expuesto a internet. No hay /wp-admin al que atacar. La superficie de ataque se reduce drásticamente.
Flexibilidad total. El equipo de diseño puede cambiar cualquier componente visual sin tocar la base de datos del contenido. Y el equipo editorial puede publicar sin preocuparse de cómo se renderiza.
Escalabilidad. Servir una web en 7 idiomas desde un solo frontend con caché multinivel es viable. Con WordPress y WPML, cada idioma multiplicaba la complejidad.
Astro + Payload CMS: por qué esta combinación
Evaluamos varias opciones. Next.js, Nuxt, Remix para el frontend. Strapi, Directus, Sanity para el CMS. Elegimos Astro y Payload por razones muy concretas.
Astro genera HTML estático o renderizado en servidor sin enviar JavaScript al navegador por defecto. Si una página no necesita interactividad, el usuario recibe HTML y CSS puros. El resultado: 0 milisegundos de Total Blocking Time. Cero. El hilo principal del navegador queda libre.
Payload CMS es un CMS headless sobre PostgreSQL con una API REST limpia y tipado completo en TypeScript. A diferencia de Strapi o Sanity, Payload se autoaloja: nuestros datos están en nuestra base de datos, no en un SaaS externo. Para una agencia que maneja datos de clientes, esto no es negociable.
La combinación resuelve un problema real: contenido gestionado de forma profesional, presentado con un Lighthouse de 97 y 0 ms de bloqueo en el navegador, sin dependencias externas ni vendor lock-in.
El proceso: 35 días, 230 commits
No fue un proyecto de seis meses. Desde el primer commit el 10 de enero de 2026 hasta la versión en producción, pasaron 35 días. 230 commits. Un equipo reducido con objetivos claros.
Fase 1: Estructura y componentes (semanas 1-2)
Definimos la arquitectura modular: 14 componentes de sección reutilizables (hero, grid de servicios, proceso por pasos, FAQs, CTAs) que se combinan como bloques para construir cualquier página de servicio. Cada servicio se define con un archivo de configuración por idioma, sin tocar código.
La decisión más importante fue no usar ningún framework de JavaScript en el cliente. Sin React, sin Vue, sin Svelte. Astro puro con islands architecture para los pocos componentes que necesitan interactividad (como el chatbot). El resultado: un bundle de JS cercano a cero para el 95% de las páginas.
Fase 2: Multi-idioma (semana 3)
Pasamos de 3 idiomas (español, inglés, catalán) a 7 (sumamos alemán, francés, neerlandés y portugués). Esto implicó:
- Un sistema centralizado de traducciones para toda la interfaz, gestionado desde un solo archivo.
- Hreflang correcto con fallback desactivado para evitar que Google indexara contenido sin traducir.
- URLs limpias por idioma sin trailing slash (1.001 URLs indexadas en Google Search Console, todas coherentes).
Un detalle que nos costó horas: la regex de detección de idioma en las URLs. Un patrón incorrecto matcheaba /ca dentro de /casos-de-exito, rompiendo las rutas en catalán. Parece trivial, pero en una web con más de 2.000 páginas, un bug así es catastrófico para SEO.
Fase 3: Migración de contenido y limpieza (semana 4)
Migramos todo el blog de WordPress a Payload CMS. Pero no fue un volcado directo: aprovechamos para hacer una auditoría brutal del contenido.
- 243 artículos tóxicos eliminados (contenido de baja calidad, irrelevante o desactualizado)
- 199 duplicados de WPML despublicados (versiones en inglés y catalán que eran copias sin traducir del español)
- 31 páginas thin content eliminadas con códigos 410 en nginx
- 3 pares de posts duplicados consolidados con redirecciones 301
- 885 títulos recortados a menos de 60 caracteres
- 333 meta descriptions ajustadas a menos de 160 caracteres
Esta limpieza fue deliberada. La Helpful Content Update de Google penaliza a nivel de sitio. Tener 200 páginas basura arrastra hacia abajo a las 700 buenas.
Fase 4: SEO y rendimiento (semana 5)
Auditoría de heading hierarchy en las 2.114 páginas del sitio: 0 errores, 0 warnings. Cada página tiene una estructura semántica correcta, desde H1 hasta H4.
Implementamos un sistema de caché de 4 capas (Payload CMS, Redis SWR, nginx SSR y Cloudflare CDN) con purga ordenada. El orden importa: si purgas Cloudflare pero Payload aún tiene caché viejo, nginx re-cachea datos antiguos inmediatamente. Parece obvio escrito, pero lo aprendimos depurando por qué los cambios no aparecían en producción.
El papel de la IA
Sería deshonesto no mencionarlo: usamos IA como herramienta de desarrollo durante todo el proceso. No para generar código a ciegas, sino como un par de programación que nos ayudó a auditar 2.000+ páginas, detectar inconsistencias de SEO a escala y automatizar tareas repetitivas como la normalización de títulos en 7 idiomas.
La IA no diseñó la arquitectura ni tomó decisiones de negocio. Pero aceleró significativamente la ejecución, especialmente en las fases de auditoría y limpieza de contenido.
Resultados: los números
Rendimiento (Lighthouse)
Las puntuaciones de Lighthouse sobre la web en producción:
- Performance: 97/100 (móvil y escritorio)
- Accesibilidad: 100/100
- Buenas prácticas: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2,2 segundos — aprobado (umbral Google: < 2,5 s)
- TBT (Total Blocking Time): 0 milisegundos — aprobado (umbral: < 200 ms)
- CLS (Cumulative Layout Shift): 0 — aprobado (umbral: < 0,1)
TBT de 0 milisegundos significa que el navegador no se bloquea en ningún momento. CLS de 0 significa que nada se mueve mientras la página carga. Estos números no son teóricos: son mediciones reales sobre la web en producción.
Impacto en buscadores
La limpieza de contenido produjo un efecto esperado: menos impresiones totales (eliminamos cientos de páginas), pero mejor calidad en lo que queda.
- CTR: +27,8% (de 0,17% a 0,22%)
- Posición media: +9,3 posiciones (de 50,6 a 41,3)
- Posición media en móvil: +13,6 posiciones (de 36,9 a 23,3)
Menos volumen, más calidad. Las páginas que quedan rankean mejor y convierten más. Es la estrategia correcta cuando la prioridad es atraer clientes, no acumular visitas vacías.
Escala
- 2.114 páginas auditadas y funcionales
- 7 idiomas desde una sola base de código
- ~1.600 artículos de blog publicados (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Deploys sin downtime con rollback automático
Qué significa esto para nuestros clientes
Esta web no es solo nuestro escaparate. Es la demostración práctica de lo que hacemos.
La misma arquitectura headless que mueve kiwop.com — separación de frontend y CMS, caché multinivel, multi-idioma nativo, rendimiento PageSpeed 97+ — es exactamente lo que implementamos en proyectos de clientes.
Si tu web actual:
- Tarda más de 3 segundos en cargar en móvil
- Depende de WordPress con 20 plugins para funcionar
- Tiene problemas de seguridad recurrentes
- No escala bien a múltiples idiomas o mercados
- Acumula deuda técnica que frena cada cambio
Hay una alternativa probada. No teórica: la estás viendo ahora mismo.
