Índice5
La conversación tuvo lugar esta semana, entre nosotros y un socio que preparaba un presupuesto. Su cliente, una empresa industrial, tiene un sitio en Drupal. El sitio es antiguo, ni siquiera funciona el HTTPS, y la pregunta era: ¿le hacemos un lavado de cara en Drupal o pasamos a otra cosa? Entonces fue a ver la página de noticias. Última publicación: 2016.
Diez años de CMS, diez años de actualizaciones, alojamiento y vulnerabilidades que vigilar, para una página congelada. No es un caso aislado, es casi la regla. Los clientes quieren un CMS «para poder modificarlo ellos mismos». Publican dos o tres artículos la primera semana y después todo cae en el olvido. Las páginas de servicios, por su parte, no cambian nunca.
En resumen
- Un CMS ofrece una flexibilidad que la mayoría de las empresas casi nunca utiliza.
- Esa flexibilidad se paga todos los días: base de datos, extensiones que parchear, servidor que vigilar, páginas más lentas.
- Un sitio estático sirve páginas ya fabricadas: nada que piratear, nada que parchear y una velocidad mediblemente mejor.
- Modificar un sitio estático ya no está reservado a los desarrolladores: usted describe el cambio en su idioma, la IA lo prepara y una persona lo valida.
- La pregunta ya no es «¿necesito poder modificar mi sitio?», sino «¿necesito para eso un servidor funcionando permanentemente?».
El CMS, un seguro que nunca se reclama
El reflejo es comprensible. Nadie quiere depender de un proveedor para corregir un número de teléfono. El CMS tranquiliza: hay un botón «Editar», así que uno es libre.
En la práctica, observamos siempre la misma curva en las empresas que acompañamos: un pico de actividad en el lanzamiento, algunas noticias y luego el silencio. Las páginas de servicios se escriben una vez y se quedan así durante años. No es pereza: un sitio de empresa cambia poco, y es normal. Lo que no es normal es pagar cada día por una capacidad que se usa dos veces al año.
Lo que cuesta la flexibilidad sin usar
Un sitio WordPress o Drupal ejecuta código en cada visita. Consulta una base de datos, monta la página y la envía. Ese mecanismo tiene un precio, que se paga incluso cuando nadie publica nada.
La seguridad. WordPress equipa el 39,6 % de los sitios según W3Techs, lo que lo convierte en un objetivo rentable. Según Patchstack, proveedor de soluciones de seguridad para WordPress, el ecosistema registró 11 334 nuevas vulnerabilidades en 2025, el 91 % de ellas en extensiones (informe Patchstack 2026). Patchstack vende protección, por lo que sus cifras deben leerse como un orden de magnitud, pero la tendencia no admite debate. Y la base tampoco está a salvo: en octubre de 2026, PHP tuvo que corregir dos vulnerabilidades críticas que permitían tomar el control de un servidor, como explicamos en el artículo sobre la vulnerabilidad de PHP de octubre.
El fin de vida. Drupal 7, que todavía mueve muchos sitios de empresa, no tiene parches de seguridad oficiales desde el 5 de enero de 2025 (anuncio de Drupal). A un sitio como el de nuestro ejemplo no le queda otra opción que una migración, sea cual sea el camino.
La velocidad. En las mediciones de campo de HTTP Archive, tomadas con visitantes reales, el 48 % de los sitios WordPress superan los tres umbrales de Google en móvil, frente al 71 % de los sitios Astro, en septiembre de 2026. Son dos poblaciones distintas, no un experimento controlado, y un WordPress cuidado puede ser rápido. Pero la diferencia dice algo: cuanto menos trabajo tiene el servidor en cada visita, antes llega la página. El detalle está en nuestra comparativa Astro o WordPress.
El tiempo. Actualizaciones del núcleo, de las extensiones, del tema, de PHP, copias de seguridad de la base, supervisión: es un presupuesto de mantenimiento mensual, publique el sitio o no.
El sitio estático: modificable, sin la maquinaria
Un sitio estático se fabrica en el momento de publicar y luego se sirve tal cual a través de una red de distribución. Sin base de datos, sin panel de administración expuesto, sin extensiones que parchear. Lo que un atacante no encuentra, no lo puede explotar.
La objeción siempre llega: «Pero entonces, ¿cómo modifico mi sitio?». Ahí es donde ha cambiado el paradigma. Hoy existen tres maneras, todas tan sencillas como un CMS:
- En lenguaje natural. Usted escribe «sustituye el número de teléfono del pie de página» o «añade una noticia sobre nuestra nueva feria», la IA prepara la modificación, aparece una vista previa y un clic la publica. Detallamos este funcionamiento en el artículo sobre la modificación de un sitio en lenguaje natural.
- Con un editor headless. Para un equipo que publica a menudo, un editor como Sanity ofrece los mismos campos que un CMS clásico, pero no sirve las páginas: alimenta el sitio en el momento de la publicación.
- En archivos de texto. Para un blog, un simple archivo Markdown por artículo, revisado y luego publicado. La elección entre ambos depende del ritmo de publicación, como explica nuestro artículo sobre el blog en Markdown o en CMS.
Cada modificación conserva su historial, y cada error se deshace con un clic. Es más control que un CMS, no menos.
Por qué es el momento adecuado
La IA ha cambiado la pregunta. Ayer, un sitio estático requería un desarrollador para cada coma, y el CMS era el precio de la autonomía. Hoy, la autonomía pasa por la conversación: quien sabe describir lo que quiere puede modificar su sitio sin conocer la herramienta. El servidor que funciona permanentemente «por si acaso» ya no tiene razón de ser para la mayoría de los sitios de empresa.
Cuidado, sin embargo, con el atajo inverso: la IA no fabrica un sitio sólido en una hora. Hace que la modificación sea fácil una vez que el sitio está bien construido, lo que sigue siendo un trabajo de oficio, como contamos en «Puedo hacerlo en 1 h con Astra en ultra code».
El CMS sigue siendo la buena elección en algunos casos: una redacción que publica a diario, varios roles que validan, una tienda con existencias que cambian. Para un sitio corporativo que cambia tres veces al año, es pagar un motor de carreras para ir a comprar el pan.
Por dónde empezar
Mire la fecha de su última noticia y el número de veces que sus páginas de servicios han cambiado en los dos últimos años. Si la respuesta cabe en los dedos de una mano, su sitio necesita ser modificable, no un CMS.
Nuestra guía de migración con Astro detalla el método. Nuestra migración a un sitio estático conserva todas sus direcciones y su posicionamiento, pone en marcha la modificación en lenguaje natural y forma a su equipo para usarla. Su sitio se vuelve más rápido, más seguro, y por fin puede olvidarse de las actualizaciones de extensiones.
Fuentes
- W3Techs, cuota de mercado de WordPress, octubre de 2026 (nueva pestaña)w3techs.com
- Informe Patchstack 2026 (nueva pestaña)patchstack.com
- Drupal 7 End of Life (nueva pestaña)drupal.org
Jim · fundador de Brain Plus AI
Más artículos sobre sitios, migración y astro
Entender4 min
Fallo crítico de PHP: actualizar y luego pensar en estático
El 21 de octubre de 2026, PHP corrigió dos fallos que permiten tomar el control de un servidor sin contraseña. Qué hacer hoy, por qué la IA acorta el plazo antes de los ataques y por qué es el momento de preguntarse si su sitio aún necesita PHP.
Entender9 min La guía del tema
Migrar a un sitio estático con Astro sin perder el SEO
Un sitio estático generado con Astro sustituye a un WordPress o un Drupal envejecido sin cambiar de direcciones: páginas en HTML puro servidas por una CDN, ningún plugin que parchear y una cadena de publicación con vuelta atrás. Lo que cambia, cómo se migra y cuándo no hay que hacerlo.
Entender7 min
Accesibilidad web: lo que cambia la obligación de 2025
Desde el 28 de junio de 2025, la Ley Europea de Accesibilidad se aplica a los servicios vendidos en línea a particulares. Quién está realmente afectado, quién no, qué exige el texto a un sitio web y por qué el trabajo beneficia también a quienes no están obligados.