Los sitios estáticos han vuelto. He trasladado a mis clientes fuera de WordPress y no van a volver.

Creé un sitio web de peluquería canina como HTML estático. Sin WordPress. Sin React. Sin pasos de compilación. Solo archivos HTML, una hoja de estilos CSS y cero marcos de JavaScript. Se carga en menos de un segundo en un VPS barato, nunca ha sido pirateado y el cliente no me ha llamado ni una sola vez para arreglar un complemento roto.

Ese sitio, Fancy Pet Salon en Lynchburg, Virginia, es uno de los varios proyectos en los que elegí HTML estático en lugar de un CMS. Un negocio de alquiler de cines en el patio trasero. Un portafolio de desarrolladores (el que estás leyendo ahora mismo). Varios sitios de marketing para presentaciones a clientes. Todos estáticos. Todos rápidos. Todos sin problemas.

No soy un purista que odia los sitios dinámicos. También utilizo Kirby CMS para el sitio web de una empresa y aplicaciones Laravel para herramientas de cotización. La herramienta adecuada depende del trabajo. Pero para un número sorprendente de sitios web, la herramienta adecuada es el HTML simple, y la industria ha estado sobredimensionando la solución equivocada durante años.

Por qué WordPress se convirtió en el estándar (y por qué eso es un problema)

WordPress impulsa alrededor del 40 % de la web. Se convirtió en la recomendación predeterminada para todo tipo de sitios web porque tiene un complemento para todo, los temas son baratos y los clientes sin conocimientos técnicos pueden iniciar sesión y editar el contenido.

El problema es lo que conlleva todo eso. Un sitio web típico de WordPress carga entre 30 y 50 solicitudes HTTP cada vez que se carga una página nueva. Ejecuta PHP en cada solicitud. Consulta una base de datos MySQL para crear una página que tiene el mismo aspecto cada vez. Necesita actualizaciones periódicas del núcleo, los temas y los complementos, y si se omiten esas actualizaciones, se está ejecutando un software vulnerable conocido en la Internet pública.

He limpiado sitios de WordPress pirateados. Es un trabajo miserable. La superficie de ataque es enorme. Cada plugin es un punto de entrada potencial. Cada dependencia obsoleta es una vulnerabilidad conocida. La seguridad de WordPress es un trabajo a tiempo completo, y la mayoría de las pequeñas empresas no tienen a nadie que lo haga.

El coste de mantenimiento también es real. Conflictos entre plugins, actualizaciones de la versión de PHP que causan problemas, sobrecarga de la base de datos, degradación del rendimiento con el tiempo. He visto sitios de WordPress que tardan 8 segundos en cargarse porque tienen 40 plugins activos y un creador de páginas que genera un lío de divs anidados. El cliente no sabe por qué su sitio es lento. Solo sabe que lo es.

¿Qué significa realmente «estático» en 2026?

Cuando digo «sitio estático», no me refiero a una página de Geocities de 1998. Me refiero a archivos HTML preconstruidos que se sirven directamente al navegador sin procesamiento del lado del servidor. La página ya está construida antes de que alguien la solicite.

El resultado: la página se carga en milisegundos en lugar de segundos. Cero consultas a la base de datos. Cero ejecución de PHP. El servidor web simplemente entrega un archivo. Eso es todo.

Los sitios estáticos modernos utilizan Tailwind CSS para el estilo, pueden incluir JavaScript para funciones interactivas y son indistinguibles de cualquier sitio dinámico. El sitio Fancy Pet Salon es bilingüe (inglés y español), tiene un menú completo de servicios, galerías de imágenes y formularios de contacto, todo en HTML estático. Nadie que visite el sitio puede decir que no es WordPress.

En cuanto al alojamiento, los archivos estáticos son absurdamente baratos de servir. Un VPS básico maneja miles de visitantes simultáneos sin ningún problema. O bien, se puede implementar en Netlify de forma gratuita y dejar que ellos se encarguen de la CDN. Yo implemento varios sitios de vista previa de clientes en Netlify: se envía a git, se compila y se publica. Coste total de alojamiento: cero.

La objeción «Pero necesito un CMS»

Esta es la objeción que siempre recibo. «Mi cliente necesita editar el contenido. No sabe escribir HTML».

Es una observación válida. No todos los sitios pueden ser archivos puramente estáticos que solo un desarrollador puede tocar. Pero aquí está la cuestión: hay más opciones que solo «WordPress o HTML codificado a mano». El espacio entre esos dos extremos es donde se encuentran las soluciones interesantes.

Opción 1: CMS de archivos planos

Yo utilizo Kirby CMS para el sitio web de la empresa J.M. Field Group. Kirby es un CMS de archivo plano: almacena el contenido en archivos de texto en lugar de en una base de datos. Hay un panel de administración donde los usuarios sin conocimientos técnicos pueden editar páginas, añadir imágenes y gestionar el contenido. Pero la arquitectura subyacente es mucho más sencilla que la de WordPress.

Sin base de datos no hay ataques de inyección SQL. Sin ecosistema de plugins no hay vulnerabilidades de plugins. Las actualizaciones son poco frecuentes y no causan interrupciones. El sitio se carga rápidamente porque el procesamiento es mínimo: Kirby lee un archivo de texto y renderiza una plantilla. Es la simplicidad del CMS que yo quería sin las complicaciones de WordPress.

Otras opciones de archivos planos: Grav, Statamic (basado en Laravel) y Cockpit. Todos comparten la misma filosofía: ofrecer a los editores una interfaz de usuario sin la sobrecarga de la base de datos.

Opción 2: CMS sin interfaz + generador estático

Si necesitas una gestión de contenidos más estructurada (múltiples autores, tipos de contenido, flujos de trabajo editoriales), lo mejor es un CMS sin interfaz. El CMS se encarga de la edición de contenidos (Contentful, Sanity, Strapi o una docena más). Un generador de sitios estáticos (Eleventy, Hugo, Astro) extrae el contenido en el momento de la compilación y genera archivos HTML.

El resultado es el mismo: HTML estático servido a los visitantes. Pero los editores disponen de una interfaz CMS adecuada para gestionar el contenido. El paso de la compilación añade complejidad, pero está automatizado: los cambios en el contenido desencadenan una recompilación y una implementación.

Este enfoque requiere más configuración que WordPress. También es más escalable, más seguro y ofrece un mejor rendimiento en todas las etapas. Para sitios con mucho contenido y múltiples colaboradores, es la arquitectura adecuada.

Opción 3: Utilizar solo HTML estático

Para muchos sitios, la respuesta honesta es que, de todos modos, nadie edita el contenido. He visto instalaciones de WordPress en las que el cliente inició sesión una vez después del lanzamiento y nunca más. El blog tiene tres entradas de 2019. La página de inicio no ha cambiado en dos años. El cliente está pagando por el alojamiento de WordPress, las actualizaciones de los plugins y la supervisión de la seguridad de un sitio que, en realidad, ya es estático.

Para estos sitios, y hay muchos, basta con crearlos como HTML estático. El sitio web de la peluquería canina no necesita un CMS. El sitio web de la empresa de alquiler no necesita un CMS. El sitio web de presentación de marketing definitivamente no necesita un CMS. Créalo, impleméntalo y funcionará sin necesidad de mantenimiento hasta que el contenido realmente necesite cambiar. Cuando eso ocurra, un desarrollador realizará la edición en cinco minutos.

Las cifras de rendimiento

No voy a fingir que se trata de un estudio controlado. Estas son cifras reales de sitios web reales que gestiono.

No estoy seleccionando un mal ejemplo de WordPress. Es un sitio de WordPress normal. Los rápidos son la excepción, no la regla.

La seguridad es una ventaja subestimada

Un archivo HTML estático no tiene superficie de ataque. No hay código que se ejecute en el servidor. No hay panel de administración al que aplicar fuerza bruta. No hay base de datos que inyectar. No hay plugins con vulnerabilidades sin parchear. El servidor web entrega un archivo. Eso es todo.

Para cualquier sitio que maneje información confidencial o represente a una empresa que no puede permitirse el tiempo de inactividad, solo por el argumento de la seguridad ya vale la pena considerar la estática.

Cuándo WordPress (o un CMS) sigue siendo la opción adecuada

No estoy diciendo que WordPress nunca deba utilizarse. Hay casos legítimos:

• Comercio electrónico con WooCommerce: si necesitas una tienda online completa con gestión de inventario, WordPress + WooCommerce sigue siendo una opción razonable. Shopify es mejor para la mayoría de la gente, pero WooCommerce tiene su lugar.
• Sitios de membresía o plataformas LMS: si los usuarios inician sesión, tienen cuentas e interactúan con contenido dinámico, necesitas un backend dinámico. WordPress maneja esto muy bien.
• Publicación de contenido de alta frecuencia: si publicas más de 5 artículos a la semana con varios autores, el flujo de trabajo editorial de un CMS vale la pena. Aunque con ese volumen, probablemente sea mejor un CMS sin interfaz + SSG.
• El cliente insiste en ello: a veces el cliente ya conoce WordPress, su equipo conoce WordPress y el coste del cambio no compensa las ventajas técnicas. El pragmatismo vence al purismo.

Cómo decidir

Haz dos preguntas:

1. ¿Alguien más que un desarrollador necesita editar este sitio con regularidad?

Si la respuesta es no: HTML estático. Envíalo y sigue adelante.

Si es ocasionalmente: CMS de archivo plano como Kirby. Es sencillo, seguro y los editores pueden actualizar el contenido sin llamarte.

Si es con frecuencia y con varias personas: CMS sin interfaz + generador de sitios estáticos. Requiere más configuración, pero es la arquitectura adecuada para sitios con mucho contenido.

2. ¿El sitio necesita cuentas de usuario, comercio electrónico o funcionalidad dinámica?

Si no: CMS estático o de archivo plano.

Si sí: necesitas un backend dinámico. Laravel, Rails, Django o, sí, WordPress. Adapta el marco a la complejidad.