Qué tecnología necesita tu web (y por qué no hay una respuesta única)

Cada vez que alguien nos pregunta “¿qué es mejor, WordPress o una web hecha a medida?”, la respuesta empieza por una pregunta de vuelta: ¿cómo vas a usar tu web de verdad? No en teoría, no en la intención de hace tres años — de verdad.

Porque la tecnología correcta para una web no depende de cuál sea “la mejor” en abstracto. Depende de quién va a tocar el contenido, cada cuánto, con qué conocimientos y con qué presupuesto de mantenimiento. Y hay algo que se pasa por alto: esa respuesta cambia con el tiempo. La tecnología que era la acertada cuando montaste tu web puede no ser la que necesitas hoy, sin que nadie haya hecho nada mal.

Para que esto no se quede en teoría, te contamos tres casos reales que hemos vivido. Dos de ellos acabaron en el mismo sitio por motivos completamente opuestos. Y el tercero es el nuestro.

Antes de nada: el problema nunca es la herramienta

Aclaremos esto de entrada, porque es donde más se confunde la gente. WordPress no es malo. Joomla no es malo. Los constructores visuales no son malos. Cada uno de ellos sostiene millones de webs que funcionan perfectamente.

Lo que sí existe es el desajuste entre la herramienta y el uso real. Un gestor de contenidos es una máquina pensada para que publiques y edites con frecuencia, con todo lo que eso implica: base de datos, plugins, actualizaciones, mantenimiento. Si publicas cada semana, esa maquinaria vale cada euro que cuesta. Si no has tocado el contenido en tres años, esa misma maquinaria es peso muerto que hay que mantener igualmente — y que si se desatiende, acaba dando problemas.

Y ojo, porque aquí es fácil caer en la condescendencia: si tienes una web que no tocas, no es culpa tuya. Casi nadie contrata una web sabiendo con exactitud cuánto la va a usar. Mucha gente ni siquiera sabe todo lo que podría hacer con la suya, y otros lo saben pero no tienen tiempo — están ocupados sacando adelante su negocio, que es lo suyo. El desajuste se detecta después, cuando ya hay recorrido. Eso es normal.

El abanico hoy es más amplio que hace unos años

Antes la decisión era casi binaria: o un gestor de contenidos, o una web hecha a mano. Hoy hay más opciones, y merece explicarlas en lenguaje llano:

CMS clásico (WordPress, Joomla, PrestaShop…). Un gestor donde entras, editas y publicas. La web se genera al momento para cada visitante consultando una base de datos. Máxima flexibilidad y una cantidad enorme de plugins disponibles. A cambio: hay que mantenerlo (actualizaciones, seguridad, copias) y es más lento por naturaleza, porque cada visita implica trabajo del servidor.

Web estática (HTML a medida). Páginas ya construidas que se sirven tal cual, sin base de datos ni procesamiento. Es lo más rápido y lo más seguro que existe, porque casi no hay nada que atacar ni que actualizar. A cambio: para cambiar contenido hay que tocar el código o pedírselo a alguien.

Generador de sitios estáticos (Astro, Hugo, Eleventy…). El punto intermedio que mucha gente no conoce. Tú escribes el contenido, y el generador construye automáticamente todas las páginas —índices, listados, categorías— y las deja como HTML estático. El visitante recibe una web estática y rápida, pero tú no has tenido que montar cada página a mano.

CMS desacoplado (headless). La combinación que rompe la falsa dicotomía “CMS o estático”: editas el contenido en un gestor cómodo, con su panel y sus formularios, igual que en un CMS de toda la vida — pero lo que recibe el visitante es una web estática generada a partir de ese contenido. Tienes la comodidad de editar sin tocar código y la velocidad y seguridad de lo estático.

Esa última opción es la que más ha cambiado el panorama, y la que hace que la pregunta “¿CMS o estático?” ya no tenga tanto sentido como antes.

Puesto en forma de tabla, para orientarse rápido:

Ninguna fila es una regla: son puntos de partida para la conversación, no veredictos.

Caso 1: la web que no se tocaba (y a la que el CMS le sobraba)

Thagaste tenía una web en WordPress desde 2018. Funcionaba, no estaba infectada, no se veía rota. Pero en todos esos años prácticamente no se había cambiado ni una línea de contenido: la web era un escaparate, no una herramienta de trabajo. Y eso está bien — hay negocios cuya web tiene exactamente esa función.

El problema apareció el día que quisieron cambiar una fotografía. Y no se pudo.

No era un capricho técnico: entre los plugins desatendidos durante años y, sobre todo, una plantilla que había quedado atrás, actualizar cualquier cosa se había vuelto una operación de riesgo. La web seguía en pie, pero se había convertido en algo que no se podía tocar sin miedo a romperlo.

Les pusimos las cuatro opciones encima de la mesa, con sus pros, sus contras y sus costes: arreglar el WordPress actual, rehacerlo en WordPress limpio, hacerlo con un generador estático, o hacerlo en HTML a medida.

Y ahí apareció el dato que más sorprende a la gente: arreglar el WordPress existente salía más caro que rehacer la web entera. Suena contraintuitivo hasta que lo piensas — desenredar años de plugins acumulados y una plantilla obsoleta lleva más horas que partir de cero con criterio.

La decisión la tomó la clienta, no nosotros. Y eligió HTML a medida, con un razonamiento impecable sobre su propio uso real: “si hay que actualizar algo, os avisamos”. Ese es el uso real de su web, y con ese uso, un CMS es maquinaria que no necesita. Menos piezas, menos mantenimiento, menos coste, y una web que carga instantánea.

La lección: el CMS le sobraba. Estaba pagando —en mantenimiento y en riesgo— por una flexibilidad que no usaba y que, sin mantenimiento, acabó siendo un estorbo.

Caso 2: el cliente que sabe (y que aun así tenía problemas invisibles)

El segundo caso es el perfil opuesto. Una asociación con varias webs, gente autosuficiente que se monta sus propias páginas y no lo hace mal. Se manejan con su gestor, saben lo que quieren, e incluso son capaces de meterse a editar HTML.

Pero hay una diferencia entre un aficionado competente y alguien que se dedica a esto profesionalmente, y no está en lo que se ve — está en lo que no se ve. Sus webs funcionaban visualmente bien, y sin embargo arrastraban problemas de fondo: URLs con el index.php colgando, idiomas configurados en el gestor que en realidad no existían como contenido, intentos de ataque en instalaciones desatendidas, plantillas usadas prácticamente tal cual —en algún caso con las imágenes de demostración todavía puestas—, poco personalizadas.

Nada de eso rompe una web. Todo eso la mina: en SEO, en seguridad y en la imagen que proyecta.

Lo interesante de este caso es el desenlace: algunas de sus webs pasaron a HTML, y otras se quedaron en su gestor porque para lo que son, les va bien. No se migró todo por coherencia ni por dogma. Cada web se decidió por su uso.

La lección: el CMS les estorbaba en unas webs y les sirve en otras. Y algo que se olvida mucho — la autonomía del cliente no depende del CMS: depende del cliente. Ellos son autónomos con y sin gestor.

Caso 3: el nuestro, y por qué elegimos un generador estático

Nuestra propia web estaba en WordPress. Hoy está hecha con Astro, un generador de sitios estáticos, y alojada en Cloudflare Pages. El razonamiento es distinto a los dos casos anteriores, y esa es justo la gracia.

Nosotros sí publicamos. Este blog tiene ya decenas de artículos, con sus categorías, sus etiquetas y sus listados, y publicamos con frecuencia. Ese detalle descarta el HTML a mano: cada artículo nuevo obligaría a tocar manualmente el índice del blog, las páginas de categoría, las de etiqueta y la paginación. Un generador estático hace todo eso solo — escribimos el artículo y el resto de páginas se construyen automáticamente.

Pero seguimos queriendo lo estático. Y aquí está la clave: no hubo que elegir. Editamos el contenido en un gestor (el modelo desacoplado que explicábamos antes), y lo que recibe el visitante es HTML estático puro. Comodidad para editar, velocidad y seguridad de lo estático.

El alojamiento es parte de la decisión. Al ser estático, la web se sirve desde una red de distribución global —el contenido viaja desde el nodo más cercano a cada visitante—, con seguridad de serie y margen para programar comportamientos a medida. Es infraestructura difícil de replicar con un CMS clásico.

Y control total. Siendo una agencia de SEO, nuestra web tiene que ser un ejemplo, no una excepción. Cuando necesitamos algo —un campo nuevo en el gestor, un dato estructurado concreto, un ajuste de rendimiento— lo hacemos y punto, sin depender de que un plugin lo contemple.

Lo que no vamos a contarte es que salió gratis. Toda migración tiene un coste, y la nuestra lo tuvo: cambiar las direcciones de las páginas nos costó posiciones en Google y meses de trabajo para recuperarlas. Lo sabíamos y aun así compensaba, pero forma parte del cálculo real: migrar nunca es solo la factura del desarrollo.

La lección: cuando el contenido crece de verdad, necesitas algo que genere las páginas por ti. Y cuando la velocidad y el control son parte de tu propuesta de valor, la infraestructura deja de ser un detalle técnico.

El remate: tres casos, tres respuestas distintas

Fíjate en lo que ha pasado aquí:

• Un cliente acabó en HTML porque no toca nunca su web.
• Otro acabó en HTML en algunas webs porque toca mucho y sabe hacerlo — y mantuvo su gestor en otras.
• Nosotros acabamos en un generador estático porque publicamos constantemente.

Dos de ellos llegaron al mismo sitio por motivos opuestos. Y una misma organización tiene hoy webs en tecnologías diferentes, cada una con la que le encaja.

Si ni siquiera dentro de una organización la respuesta es única, está bastante claro que no existe “la mejor tecnología” en abstracto. Existe la que encaja con cómo usas tu web.

Señales de que tu web tiene problemas que no ves

Esta es la parte práctica. Son comprobaciones que puedes hacer en unos minutos, sin saber programar, y que delatan problemas de fondo:

Mira tu URL con atención. Si ves cosas como index.php en medio de la dirección, parámetros raros, o la misma página accesible desde varias direcciones distintas, tienes un problema de configuración que afecta al SEO.

Comprueba que llegan los formularios. Rellena tú mismo el formulario de contacto de tu web y comprueba que el correo llega. Es más común de lo que parece que lleve meses sin funcionar y nadie se haya dado cuenta — con lo que eso significa en clientes perdidos.

Fíjate en el candado del navegador. Si tu web da avisos de “no segura”, o si escribiendo la dirección sin https no te redirige sola a la versión segura, hay algo mal montado.

Busca restos de la plantilla. Textos tipo “Lorem ipsum”, imágenes de demostración que no son tuyas, secciones que vinieron con el diseño y nadie quitó. Proyectan descuido y a veces son contenido duplicado con otras webs que usan la misma plantilla.

Cuenta cuánto tarda en cargar en el móvil, con datos y no con wifi. Si tú te impacientas, imagina alguien que no tiene ningún motivo para esperarte.

Revisa cuándo se actualizó por última vez. Si tu web tiene gestor y hace más de un año que nadie entra a actualizar nada, hay actualizaciones de seguridad pendientes. Es la vía de entrada más habitual a una web comprometida.

Búscate en Google desde una ventana de incógnito, con el móvil. Esta comprobación es menos conocida y de las más reveladoras: algunas webs comprometidas inyectan código que solo actúa con visitantes nuevos desde el móvil —redirigiendo a páginas de spam o mostrando contenido que no es tuyo— mientras que a ti, que entras siempre desde el mismo dispositivo y con la sesión iniciada, te enseña todo normal. Si lo que ves en incógnito no es lo que esperas, tienes un problema serio.

Si al pasar esta lista te han salido varias, no significa que haya que rehacer la web entera — significa que merece la pena mirar qué está pasando antes de decidir nada. Es justo lo que hacemos en una auditoría: encontrar qué está frenando la web y qué tiene más impacto arreglar primero.

Cómo decidir en tu caso

Cuatro preguntas, y contestándolas sin engañarte a ti mismo, casi se decide sola:

¿Cada cuánto vas a cambiar el contenido de verdad? No en la intención — en la práctica. Si la respuesta sincera es “una o dos veces al año”, no necesitas un gestor. Si es “cada semana”, lo necesitas sí o sí.

¿Quién lo va a hacer? ¿Tú, alguien de tu equipo, o nos vas a avisar a nosotros? Si nadie de tu lado va a tocar la web, un panel de edición es una función que pagas y no usas.

¿Necesitas funcionalidad o es informativa? Una tienda, un sistema de reservas, un área privada de clientes o una zona de descargas cambian la ecuación por completo: ahí la funcionalidad manda sobre todo lo demás. Si vendes online, la conversación es otra — y empieza por cómo montar la tienda, no por la tecnología.

¿Qué presupuesto de mantenimiento vas a asumir? Esta es la pregunta incómoda y la que más se salta. Un gestor sin mantenimiento no es “gratis”: es una factura aplazada. Si no vas a destinar nada al mantenimiento, elige algo que no lo necesite.

Preguntas frecuentes

¿Es mejor WordPress o una web estática?

Ninguna de las dos es mejor en abstracto. WordPress encaja cuando vas a editar contenido con frecuencia, necesitas funcionalidades complejas o quieres una oferta amplia de extensiones — asumiendo su mantenimiento. Una web estática encaja cuando el contenido cambia poco, o cuando la velocidad y la seguridad son prioritarias. La pregunta útil no es cuál es mejor, sino cuál encaja con tu uso real.

¿Podré actualizar mi web yo mismo si no es un CMS?

Depende de la opción. Con HTML a medida, los cambios los hace quien lleve la web. Pero existen opciones intermedias: con un CMS desacoplado editas el contenido en un panel cómodo, sin tocar código, y la web sigue siendo estática. Si la autonomía para editar es importante para ti, dilo desde el principio: condiciona la elección.

¿Cuándo compensa rehacer la web en vez de arreglarla?

Cuando el coste de desenredar lo que hay se acerca o supera al de empezar de nuevo — algo mucho más frecuente de lo que parece en webs con años de plugins acumulados y plantillas obsoletas. También cuando la tecnología actual ya no encaja con cómo usas la web, o cuando arreglarla te dejaría en el mismo sitio dentro de dos años. La forma de saberlo es pedir las dos valoraciones y compararlas.

¿Una web estática posiciona peor en Google?

Al contrario. A Google le da igual con qué tecnología esté hecha una web: lo que valora es el contenido, la experiencia y el rendimiento. Y en rendimiento, una web estática juega con ventaja porque carga más rápido. Lo que sí importa es que esté bien construida: buena estructura, contenido útil, datos estructurados y direcciones limpias. Eso se puede hacer bien o mal con cualquier tecnología.

¿Y si mi web actual funciona pero es antigua?

“Funciona” y “está bien” no son lo mismo. Muchas webs antiguas siguen en pie pero arrastran problemas invisibles de seguridad, rendimiento o SEO. La checklist de este post te da pistas en cinco minutos. Si sale limpia, tu web probablemente está bien y no hay que tocar nada — que también es una conclusión válida.

Si te llevas una sola idea de este post, que sea esta: la mejor tecnología para tu web es la que encaja con cómo la usas de verdad, no la que está de moda ni la que usa tu competencia. Y como el uso cambia con los años, revisar esa decisión de vez en cuando es sano.

Cuando hacemos una web, la primera conversación no va de tecnología: va de cómo trabajas y qué esperas de tu web. La tecnología viene después.

Si no tienes claro si tu web necesita un cambio de fondo o solo algunos ajustes, lo revisamos contigo y te decimos qué merece la pena hacer y qué no — incluido “esto está bien como está”, que es una conclusión que damos más veces de las que la gente espera. Escríbenos y lo vemos.