¿Sitio estático o WordPress? Una ruta de decisión por tipo de proyecto

La pregunta «¿estático o WordPress?» suele plantearse como si fuera de gustos, pero se responde mirando tres cosas: quién va a editar el contenido, con qué frecuencia cambia y si el sitio necesita hacer algo en el servidor cuando llega una visita (cobrar, guardar un comentario, mostrar un carrito). Este artículo convierte esas tres preguntas en una ruta de decisión, la aplica a cuatro proyectos típicos y termina con un cálculo de coste anual en el que cada número es un supuesto declarado.

Qué cambia de verdad entre uno y otro

Un sitio estático es un conjunto de archivos HTML, CSS, imágenes y, si acaso, algo de JavaScript, generados de antemano. Cuando alguien pide una página, el servidor entrega un archivo que ya existe. No hay base de datos ni código ejecutándose en el servidor por cada visita. El contenido suele escribirse en archivos de texto (Markdown o HTML) y un generador los convierte en páginas.

WordPress es una aplicación PHP con base de datos. Cada página se compone en el servidor a partir de plantillas, plugins y registros de la base de datos (con caché, si la configuras). A cambio, ofrece un panel de administración donde cualquiera puede escribir, subir imágenes y programar publicaciones sin tocar archivos. Según su página oficial de requisitos, WordPress recomienda PHP 8.3 o superior, MySQL 8.0 o MariaDB 10.11 o superior, y HTTPS. Es decir: necesitas un servidor que ejecute PHP y una base de datos, y alguien que los mantenga al día.

Esa diferencia de arquitectura explica casi todo lo demás: la superficie de ataque, el tipo de alojamiento, el trabajo de mantenimiento y quién puede publicar sin ayuda.

Tabla comparativa

La tabla resume las diferencias en los cinco criterios que más pesan en la práctica. Las valoraciones son criterio editorial basado en la arquitectura de cada opción, no resultados de pruebas.

Fíjate en que la fila de rendimiento no dice «estático es rápido y WordPress lento». Un sitio estático con imágenes de 3 MB y cinco scripts de terceros puede ser lento, y un WordPress con caché de página completa y un tema sobrio puede ir muy bien. La arquitectura fija el punto de partida, no el resultado. Para medir el resultado, consulta qué miden LCP, INP y CLS y con qué umbrales.

La ruta de decisión

Responde a las preguntas en este orden. La primera que te dé una respuesta clara suele decidir.

1. ¿El sitio cobra, gestiona cuentas de usuario o guarda datos enviados por los visitantes? Si la respuesta es sí y es el núcleo del proyecto, necesitas lógica de servidor. Eso descarta un sitio estático puro, aunque no obliga a WordPress: también existen plataformas de tienda alojadas.
2. ¿Van a publicar personas que no quieren tocar archivos ni Git? Si son varias y publican a menudo, WordPress (u otro CMS con panel) ahorra fricción diaria. Un sitio estático con un CMS «sin cabeza» (headless) es posible, pero añade otra pieza que configurar.
3. ¿Quién va a mantener el servidor dentro de dos años? Si no hay nadie con tiempo para revisar actualizaciones, el sitio estático reduce el riesgo de quedarse con un WordPress abandonado y vulnerable.
4. ¿El contenido cambia pocas veces al mes y lo escribe gente técnica? Entonces el sitio estático es la opción con menos piezas.

Cuatro proyectos, cuatro respuestas

Blog personal

Una sola persona escribe, publica unas pocas entradas al mes y no cobra nada en la web. Si esa persona se maneja con Markdown, un generador estático es la opción con menos mantenimiento: no hay panel que proteger ni plugins que actualizar. Si quiere escribir desde el móvil o le resulta ajeno trabajar con archivos, WordPress es razonable, pero con pocos plugins y las actualizaciones automáticas activadas (desde WordPress 5.6, las instalaciones nuevas traen activadas por defecto las actualizaciones automáticas del núcleo, menores y mayores).

Un detalle sobre alojamiento gratuito: GitHub Pages, por ejemplo, publica sitios estáticos con límites documentados (sitio publicado de hasta 1 GB y un límite «blando» de 100 GB de transferencia al mes) y no permite usarlo como alojamiento de tiendas o negocios cuyo fin principal sean transacciones comerciales. Para un blog personal esos límites sobran; para otros proyectos, lee las condiciones antes de decidir.

Revista con varios autores

Aquí pesa el flujo editorial. WordPress trae de serie roles pensados para eso: el colaborador (Contributor) escribe pero no publica ni sube archivos, el autor publica lo suyo y el editor gestiona las entradas de todos. Reproducir eso en un sitio estático exige un CMS externo o revisiones por pull request, que funcionan bien con redactores técnicos y mal con los demás.

Opinión editorial: para una revista con más de dos o tres personas no técnicas, WordPress suele compensar su mantenimiento. Eso sí, asigna a alguien la tarea de las actualizaciones: en la tabla oficial de capacidades, actualizar núcleo, plugins y temas corresponde al administrador, no a editores ni autores.

Tienda

Una tienda necesita carrito, pagos, stock, impuestos y correos transaccionales. Un sitio estático no hace nada de eso por sí mismo. Las salidas habituales son WordPress con un plugin de comercio, una plataforma de tienda alojada o un sitio estático que enlaza a un servicio de pago externo. Esta última sirve para vender tres productos digitales; para un catálogo con variantes y envíos se queda corta enseguida.

Si eliges WordPress para una tienda, el listón de mantenimiento sube: hay datos de clientes y pedidos. La guía oficial de seguridad de WordPress recomienda instalar plugins y temas sólo de fuentes de confianza, eliminar los que no se usan y desactivar la edición de archivos desde el panel (constante DISALLOW_FILE_EDIT).

Documentación técnica

La documentación es el terreno natural del sitio estático. La escriben personas técnicas, conviene versionarla junto al código, se revisa como el código y cada cambio queda registrado en Git. Además, suele tener muchas páginas que cambian poco, lo que encaja con generarlo todo de antemano.

Cuánto cuesta al año: un ejemplo con supuestos

Los precios de dominios y alojamiento varían por proveedor, país y promociones, así que no tiene sentido dar cifras «oficiales». Lo útil es el método: sumar lo que pagas y el tiempo que dedicas, porque el tiempo es el coste que más se olvida.

Las cifras dependen de tus supuestos; lo que se mantiene es la estructura. En proyectos pequeños, la partida grande casi nunca es el alojamiento: son las horas.

Lo que no decide esta elección

Ni el estático ni WordPress te dan posicionamiento por sí mismos. Google no premia una tecnología concreta; lo que cuenta es lo que entregas: si las páginas responden con el código correcto, si hay una sola versión de cada URL, si cargan rápido y si el contenido es útil. Ambos caminos pueden hacerlo bien o mal. Si migras de uno a otro, lo que más daño hace es cambiar URLs sin redirecciones; revisa cómo dejar una sola versión de cada página y qué código debe responder cada URL antes de mover nada.

Tampoco decide la monetización. AdSense pide, entre otras cosas, poder colocar su código entre las etiquetas <head> de tus páginas, y eso es posible en ambos casos.

Antes de decidir, comprueba esto

• Has escrito quién publicará contenido y si sabe trabajar con archivos y Git.
• Sabes si el sitio necesitará pagos, cuentas o formularios que guarden datos.
• Hay una persona con nombre asignada a las actualizaciones (si eliges WordPress).
• Has hecho tu propio cálculo de coste anual con tus precios y el valor de tu tiempo.
• Has leído las condiciones de uso del alojamiento elegido (límites de transferencia, uso comercial).
• Tienes un plan de copias de seguridad: el repositorio Git en el estático; archivos y base de datos en WordPress.

Cuándo no aplicar esta ruta: si tu organización ya tiene un CMS corporativo con un equipo que lo mantiene, o si el proyecto es una aplicación web (paneles, cuentas, datos en tiempo real), la pregunta no es «estático o WordPress», sino qué framework de aplicación usar.