Por qué abandoné WordPress después de 20 años (y por qué no lo hice antes)
Hace dos décadas monté mi primera web con WordPress. Corría 2005, y WordPress era una bendición: instalabas, elegías theme, instalabas cuatro plugins y tenías una web funcionando en una tarde. Durante 20 años fue mi herramienta principal. Cientos de proyectos. Miles de horas.
Hoy, asturwebs.es no usa WordPress. Y no volvería atrás ni aunque me pagaran.
Este es el porqué.
El momento “se me cayó la venda”
No fue un día concreto. Fue una acumulación. La gota que colmó el vaso fue un sitio “sencillo” —una web corporativa de 5 páginas— que necesitaba 23 plugins para funcionar como el cliente esperaba. 23. Para 5 páginas.
Hice las cuentas:
5 páginas. 23 plugins.
Cada plugin = una licencia que renovar, un vector de ataque potencial, una actualización pendiente, un conflicto por resolver.
Y luego miré mi propia web. Más de lo mismo. WP Rocket para el caché, Yoast para el SEO, Wordfence para seguridad, Smush para imágenes, un plugin para formularios, otro para cookies, otro para el sitemap… Cada plugin resolvía un problema que WordPress me había creado al no resolverlo de serie.
Entonces hice la pregunta correcta: ¿y si en vez de parchear, cambio de base?
Lo que estaba mal (y WordPress no va a arreglar)
1. El modelo PHP + MySQL es de 2003
WordPress nació cuando PHP era el rey y MySQL la única base de datos que todo hosting ofrecía. Han pasado 23 años. Hoy renderizar HTML una vez y servirlo estático es más rápido, más barato y más seguro.
Pero WordPress no puede ser estático. Su arquitectura es dinámica por definición: cada visita ejecuta PHP, consulta la base de datos, ensambla la página. Para mitigarlo, instalas un plugin de caché. Que genera HTML estático… exactamente lo que podrías haber hecho desde el principio sin WordPress.
2. El editor de bloques no es para escribir
Gutenberg prometía libertad creativa. La realidad: un editor lleno de opciones que distraen, un formato que mezcla contenido con presentación, y una experiencia de escritura que no llega ni de lejos a la de un archivo Markdown en local. Para un blog, escribir debería ser la prioridad. WordPress lo convierte en una batalla contra la interfaz.
3. La seguridad es un trabajo a tiempo parcial
Tener WordPress al día implica:
- Actualizar el core (rezando para que no rompa el theme)
- Actualizar plugins (rezando para que no rompan otros plugins)
- Actualizar el theme (rezando para que… bueno, ya me entienden)
- Revisar usuarios, contraseñas, permisos
- Monitorizar intentos de acceso a
wp-adminyxmlrpc.php
O lo haces tú cada semana, o pagas a alguien para que lo haga. O instalas Wordfence. Que es otro plugin más. Que también hay que actualizar. Y mantener.
4. El coste real está escondido
WordPress es “gratis”. Pero:
| Lo que pagas | Coste real |
|---|---|
| Plugins premium (caché, SEO, formularios, backups) | 200-400€/año |
| Mantenimiento (actualizaciones, seguridad, incidencias) | Tiempo o dinero |
| Reconstruir lo que se rompe tras una actualización | Tiempo o dinero |
Y cuando algo falla —que falla—, el coste no es solo el arreglo. Es lo que pierdes mientras no funciona.
El plan B: Astro 5 + Hono + SQLite
En 2024 empecé a mirar alternativas. Probé Hugo, 11ty, Next.js… Astro 5 me convenció:
- Genera HTML estático por defecto. Sin plugins de caché, sin configuraciones. Estático de verdad.
- Puedes usar React donde lo necesitas. Formulario de contacto, chatbot… hidratas solo lo interactivo. El resto es HTML puro.
- Content Collections con MDX. Escribo en Markdown. Con componentes React si los necesito. Sin editor de bloques.
- Tailwind CSS nativo. Sin temas hijo, sin CSS peleándose con el del plugin de turno.
- Sitemap automático. Sin plugin. Sin Yoast.
Para la parte dinámica (formulario de contacto, guardar leads), monté una API mínima con Hono sobre Node.js y SQLite. 160 líneas de código frente a los miles de WordPress + plugins.
La arquitectura quedó así:
Tres piezas. Nada más.
Por qué ahora y no hace 3 años
Esto mismo lo evalué en 2023. Lo descarté. ¿El motivo? Migrar 55 URLs, 31 posts, formularios, SEO, redirecciones y no perder posicionamiento era un trabajazo que no podía justificar.
Pero en 2026 el tablero ha cambiado. La IA generativa ha bajado la barrera de entrada de una forma que cambia lo que un profesional independiente puede abordar solo:
- Claude Code, Copilot, Cursor… no escriben el código por ti, pero aceleran lo que antes te llevaba días a lo que ahora te lleva horas.
- Repasas un diseño, la IA te genera el componente base y tú lo ajustas.
- Auditas 49 páginas en minutos en vez de tardar una tarde.
- Migras contenido con un script que formatea, limpia y estructura 31 posts de WordPress a MDX.
- Revisas sintaxis, detectas erratas, generas schemas JSON-LD sin escribir JSON a mano.
El punto de inflexión:
Lo que en 2023 habría requerido un equipo de 3 personas durante semanas, en 2026 lo hace un freelance en días. No porque la IA le sustituya, sino porque elimina la fricción: generas, revisas, corriges, iteras. El 80% del tiempo ya no es picar código, es tomar decisiones.
La IA no ha hecho el proyecto por mí. Pero ha hecho viable lo que antes era impensable para alguien que trabaja solo. Y eso lo cambia todo.
Los números: antes y después
| WordPress (v1) | Astro (v2) | |
|---|---|---|
| Páginas | 55 | 49 (migradas con 301s) |
| Plugins | 18 | 0 |
| Tiempo de build | N/A (dinámico + caché) | 2.3 segundos |
| Vulnerabilidades conocidas | Las de 18 plugins | Las mías (código propio, revisable en Git) |
| Peso medio de página | ~800KB | ~120KB |
| Dependencia de terceros | Theme, plugins, updates | Ninguna |
| Escritura de posts | Editor de bloques | Markdown en VS Code |
| Control de versiones | Difícil (DB + archivos) | Todo en Git |
La diferencia más brutal no está en la tabla: ya no mantengo WordPress. Ni el mío ni el de los clientes que he ido migrando. Lo que antes eran horas mensuales de actualizaciones, copias de seguridad, monitorización y sustos… ahora es un build automático y un rsync.
Nota técnica: Si quieres ver el impacto real de esta migración en métricas, audité 32 posts de mi blog con Search Console y los datos hablan solos.
¿Es esto para todo el mundo?
No. Y sería deshonesto decir lo contrario.
Sí migres a Astro (o cualquier generador estático) si:
- Controlas el código y no dependes de un page builder
- Quieres rendimiento extremo sin depender de plugins de caché
- Escribes contenido con frecuencia y valoras una experiencia de escritura limpia
- Te importa la seguridad y no quieres mantener WordPress al día
- Tienes acceso a tu servidor y sabes hacer un
rsync
No migres si:
- Tu negocio depende de plugins específicos de WordPress (WooCommerce complejo, membership sites, LMS con cientos de usuarios)
- Necesitas que el cliente edite contenido desde un panel visual tipo Divi/Elementor
- No tienes conocimientos técnicos para mantener una API en Node.js
- Tu sitio tiene cientos de páginas dinámicas con lógica de servidor
WordPress sigue siendo la herramienta correcta para muchos casos. Pero no para el mío.
Lo que he aprendido
Migrar de WordPress a Astro no es un proyecto técnico. Es un proyecto de criterio.
La pregunta no es “¿qué tecnología uso?”. La pregunta es: “¿qué necesito realmente y qué es ruido?”. En 2026, para una web corporativa con blog, formulario y SEO:
- No necesitas PHP.
- No necesitas MySQL.
- No necesitas un editor de bloques.
- No necesitas 18 plugins.
Necesitas HTML rápido. Un formulario que funcione. Contenido que Google entienda. Y liberarte de la cadena de mantenimiento perpetuo.
Si quieres profundizar en la parte de rendimiento, escribí una guía sobre Core Web Vitals en WordPress con datos reales.
El resto es ruido. Y llevaba 20 años pagando por él.
Si quieres integrar IA en tu proyecto, consulta mi servicio de Inteligencia Artificial.
¿Tienes una web en WordPress y estás pensando en migrar?
Te digo honestamente si te compensa y por dónde empezar. Sin compromiso.
Hablemos →
