La pregunta «qué CMS elijo» se plantea al revés nueve de cada diez veces. Va sobre tecnología cuando debería ir sobre personas: quién va a escribir, con qué frecuencia y con qué soltura técnica.
Un CMS potente en manos de quien nunca lo tocará es un coste recurrente sin contrapartida. Una web congelada en manos de quien publica tres veces por semana es un cuello de botella.
La pregunta que hay que hacerse antes que ninguna
¿Cuántas veces al mes va a cambiar el contenido y quién lo va a cambiar? La respuesta determina casi todo lo demás.
Una web de diez páginas modificada dos veces al año no necesita ningún CMS: el coste de mantenimiento y seguridad de un panel supera con creces la comodidad que aporta. Un blog alimentado tres veces por semana por una persona no técnica lo necesita sin discusión.
| Frecuencia de actualización | Quién edita | Solución adecuada |
|---|---|---|
| Un par de veces al año | El proveedor | Páginas estáticas, sin panel |
| Una o dos veces al mes | La dirección | CMS ligero o zonas editables concretas |
| Varias veces por semana | Un equipo | CMS completo con roles y borradores |
| En continuo, multicanal | Un equipo editorial | Headless con API |
WordPress: en qué es bueno y qué cuesta
WordPress mueve una parte considerable de la web por buenas razones: interfaz familiar, ecosistema enorme, coste de entrada bajo y una reserva amplia de gente capaz de intervenir.
El coste real no está en la instalación, está en el tiempo. Cada extensión añade una dependencia que mantener y una superficie de ataque. Una web WordPress sin actualizar durante un año es una web comprometida en espera.
- Elígelo si: publican varias personas, quieres poder cambiar de proveedor, el presupuesto inicial es ajustado.
- Evítalo si: nadie se va a ocupar de las actualizaciones, o el rendimiento es crítico sin presupuesto de optimización.
- En cualquier caso: presupuesta el mantenimiento desde el principio, no tras el primer incidente.
Headless: cuándo se justifica de verdad
El principio es separar la gestión del contenido de su presentación: el contenido vive en una API y uno o varios front-ends lo consumen.
Es excelente cuando el mismo contenido alimenta realmente varios canales — web, aplicación móvil, pantallas en tienda, socios. Es complejidad gratuita cuando a la salida solo hay una web.
La trampa del headless
Dos sistemas que mantener en lugar de uno, una vista previa a menudo mediocre y dependencia de un servicio externo cuya tarifa puede cambiar. No lo elijas porque sea moderno; elígelo porque tienes varios canales.
A medida: menos exótico de lo que parece
Una web desarrollada a medida, sin framework pesado, suele ser la solución más rápida y duradera para una web corporativa o de contenido con estructura estable. Sin capa de abstracción, sin extensiones que actualizar, sin superficie de ataque heredada.
Su debilidad es real y conviene nombrarla: sin panel, cualquier cambio pasa por alguien técnico. La respuesta no es añadir un CMS completo, sino hacer editables solo las zonas que cambian de verdad.
Una vía que se ignora a menudo
El contenido en archivos estructurados y versionados, con una interfaz de edición limitada a los bloques que se mueven. Conservas la velocidad de lo estático y la capacidad de cambiar lo que importa, sin panel que asegurar.
El coste total a cinco años, no el precio del presupuesto
El precio que se anuncia de una web es el precio del primer año. A cinco años la estructura de costes se desplaza hacia el alojamiento, el mantenimiento, las licencias de extensiones y los arreglos que siguen a cada salto de versión mayor. Esa suma es la que hay que comparar, no el presupuesto inicial.
Un WordPress bien atendido cuesta entre 600 y 1.800 € al año de mantenimiento externalizado, más 150 a 600 € anuales de licencias si la web depende de extensiones de pago: formularios avanzados, campos personalizados, buscador interno, copias de seguridad. Esas licencias no son opcionales: una extensión cuya suscripción caduca deja de recibir parches de seguridad.
| Opción | Creación | Recurrente anual | Total a 5 años |
|---|---|---|---|
| Constructor online | 0 a 1.500 € | 200 a 600 € | 1.000 a 4.500 € |
| WordPress a medida | 4.000 a 12.000 € | 800 a 2.400 € | 8.000 a 24.000 € |
| Headless (CMS en la nube + front) | 12.000 a 30.000 € | 1.200 a 4.000 € | 18.000 a 50.000 € |
| A medida sin panel | 3.000 a 10.000 € | 150 a 600 € | 3.750 a 13.000 € |
Los rangos se solapan, y ese es el dato relevante: ninguna opción es estructuralmente más barata. El constructor online es el más económico mientras te quedes dentro de su perímetro, y el más caro el día que sales, porque la rehechura empieza de cero. El desarrollo a medida sin panel tiene un recurrente bajo pero factura cada evolución por jornadas: cuenta 400 a 700 €, y comprueba que tu ritmo de cambios no pase de tres o cuatro jornadas al año.
Hay una partida que casi siempre se olvida: los saltos de versión mayor. Pasar de una versión mayor del CMS a la siguiente supone entre media jornada y cinco jornadas según el número de extensiones y si hay un tema hijo personalizado. Provisionar ese gasto una vez cada tres años evita el desenlace de siempre: una web bloqueada en una versión obsoleta porque la actualización nunca se presupuestó.
La seguridad: quién responde, exactamente
La seguridad se resuelve por contrato tanto como por tecnología. En una web WordPress intervienen cuatro actores: el proveedor de alojamiento por el servidor, el editor del CMS por el núcleo, los autores de extensiones por su código, y el proveedor por la aplicación de los parches. Si nadie ha firmado ese último papel, no está cubierto.
La inmensa mayoría de los ataques con éxito no explota un fallo del núcleo de WordPress, sino una extensión sin actualizar o una cuenta de administración mal protegida. El plazo importa: un fallo publicado se explota de forma automatizada en los días siguientes a la salida del parche. Un contrato que promete actualizaciones «mensuales» deja abierta una ventana de tres o cuatro semanas.
- El plazo de aplicación de los parches críticos: 72 horas es un compromiso sostenible; «lo antes posible» no lo es.
- La frecuencia y la retención de las copias, y sobre todo dónde se guardan: una copia en el mismo servidor que la web no protege de nada.
- El plazo de restauración tras un incidente, y quién puede activarla.
- Lo que queda fuera: la limpieza de una web comprometida se factura aparte, entre 500 y 2.000 € según el alcance de la infección.
El desarrollo a medida sin base de datos ni panel reduce la superficie de ataque, no la elimina: quedan el servidor, el formulario de contacto y las dependencias del sistema. La diferencia está en el volumen de código ajeno del que dependes sin conocerlo. Menos dependencias no es invulnerabilidad, es una carga de vigilancia dividida entre cinco o diez.
Migrar de un CMS a otro: lo que cuesta de verdad
Cambiar de CMS no consiste en mover texto. El coste se concentra en tres partidas que rara vez se cifran de antemano: la correspondencia de URL, la reconstrucción de las plantillas y la recuperación de contenidos que nunca existieron en forma estructurada.
| Punto de partida | Recuperación del contenido | Carga estimada |
|---|---|---|
| WordPress con contenido estructurado | Exportación XML y API REST | 3 a 6 días |
| CMS propietario con exportación | CSV o JSON parcial | 6 a 12 días |
| Constructor de páginas visual | Sin estructura aprovechable | Reescritura completa |
| Sitio estático versionado | Archivos ya estructurados | 1 a 3 días |
La partida más subestimada es el plan de redirecciones. Una web de 80 páginas que cambia de arquitectura necesita 80 redirecciones 301 comprobadas una a una. Sin ellas, la pérdida de tráfico orgánico es inmediata y tarda entre seis y doce meses en recuperarse. Cuenta entre media jornada y una jornada para una web de ese tamaño, más si las direcciones antiguas llevan identificadores numéricos sin lógica legible.
Segunda partida: los contenidos maquetados a mano. Un artículo cuya estructura vive en HTML pegado sobre la marcha no se convierte solo. En cincuenta artículos, la recuperación manual son dos a cuatro jornadas. Por eso una web hecha con un constructor visual casi nunca se migra: se rehace.
Un orden de magnitud para decidir: migrar una web corporativa de 30 a 60 páginas se sitúa entre 2.500 y 6.000 €, redirecciones y pruebas incluidas. Por debajo, parte del trabajo no se ha cifrado, y suele ser justo el que protege el posicionamiento ya conseguido.
Constructores de páginas: el bloqueo es el modelo de negocio
Un constructor de páginas visual — extensión de WordPress o plataforma completa — guarda la maquetación en su propio formato. El texto sigue siendo legible, la estructura no. Desactiva la extensión y la página queda reducida a un bloque de etiquetas inservible tal cual.
No es un defecto de diseño, es el modelo. Una herramienta de la que se sale con facilidad se sustituye con facilidad. El coste de salida forma parte del producto y rara vez se menciona en el momento de la compra.
El bloqueo tiene un segundo efecto, más cotidiano y menos visible: el marcado te viene impuesto. No eliges ni la jerarquía de títulos, ni el peso del CSS que se carga en cada página, ni el número de contenedores anidados. En una web de contenido eso pesa sobre los Core Web Vitals y sobre la accesibilidad, dos asuntos que solo se corrigen saliendo de la herramienta.
La prueba que hay que hacer antes de firmar
Pide una página exportada tal como saldría de la herramienta y mira si su contenido se recupera sin la herramienta. Si la respuesta es «para eso haría falta una extensión», acabas de conocer el precio de la salida.
Nada de esto descalifica a estas herramientas. Para una asociación que monta una página de evento en dos horas, el bloqueo es un coste asumible. Se convierte en problema cuando la web sostiene tráfico orgánico construido durante años: la rehechura deja de ser un proyecto de web y pasa a ser un proyecto de web más una recuperación de posicionamiento, y lo segundo suele superar a lo primero.
Accesibilidad: lo que el CMS no resuelve
La accesibilidad digital ha dejado de ser una buena práctica opcional para todo el mundo. En Francia el referencial aplicable es el RGAA, derivado de las WCAG, y es la base de las auditorías. Obliga desde hace tiempo a los organismos públicos y a las empresas por encima de un umbral alto de facturación.
El perímetro se amplió con el marco europeo de accesibilidad, aplicable desde junio de 2025 a servicios como el comercio electrónico, la banca o el transporte de viajeros, con exención para las microempresas. Si vendes en línea y tienes más de diez empleados, el asunto te afecta directamente; si no, sigue siendo un argumento de calidad, no una obligación.
El CMS no hace accesible una web, y ninguno la hace inaccesible por sí solo. Lo que decide es la plantilla y cómo se introduce el contenido. Los incumplimientos más frecuentes son independientes de la tecnología: contrastes insuficientes, imágenes decorativas sin atributo alt vacío, campos de formulario sin etiqueta asociada, títulos elegidos por su tamaño y no por su nivel, componentes interactivos inutilizables con teclado.
El cálculo económico es claro: integrar la accesibilidad desde el diseño añade en torno a un 10 a 15 % al presupuesto inicial. Volver sobre ella después, en una web corporativa ya publicada, es un trabajo de 3.000 a 8.000 €, revisión de la plantilla incluida, porque casi siempre hay que tocar la estructura y no solo los colores.
Las capas que prometen conformidad automática mediante JavaScript no producen conformidad. Parchean algunos atributos en tiempo de ejecución sin tocar la estructura ni la calidad de los contenidos, que son exactamente los dos puntos que examina una auditoría.
El criterio que nadie mira: la salida
Antes de elegir, pregunta cómo recuperas tu contenido si cambias de idea. ¿Existe una exportación limpia y documentada? ¿En qué formato? ¿Incluye las imágenes?
Una solución de la que no se sale con facilidad acaba dictando sus condiciones. Es un criterio de elección al menos tan importante como la lista de funciones.
Para recordar
- Deciden la frecuencia de publicación y el perfil de quien edita, no la tecnología.
- Compara totales a cinco años, no presupuestos del primer año: los rangos se solapan.
- WordPress es buena elección si el mantenimiento está presupuestado y contratado desde el principio.
- La seguridad se juega en un plazo de parcheo escrito, no en una tecnología.
- El headless se justifica por el número de canales, no por la modernidad.
- Un constructor de páginas visual se rehace, no se migra: mete ese coste en la cuenta.
- La accesibilidad cuesta un 10 a 15 % en diseño y dos o tres veces más después.
- Comprueba siempre cómo se sale antes de entrar.
FAQ — Elección de CMS
¿WordPress es malo para el SEO?
No. Un WordPress bien configurado se posiciona muy bien. Lo que perjudica al posicionamiento son las plantillas sobrecargadas y la acumulación de extensiones, no el CMS en sí.
¿Se puede migrar de un CMS a otro más adelante?
Sí, pero el coste depende por completo de cómo esté almacenado el contenido. Migrar desde un sistema con exportación limpia lleva unos días; desde un constructor de páginas propietario suele equivaler a reescribirlo todo.
¿Qué presupuesto para cada opción?
WordPress a medida: 4.000 a 12.000 €, más 50 a 150 €/mes de mantenimiento. Headless: 12.000 a 30.000 €, más la suscripción del servicio. A medida sin CMS: 3.000 a 10.000 €, mantenimiento marginal.
¿Puede bastar un constructor de webs online?
Para una presencia sencilla y temporal, sí. Los límites aparecen en el rendimiento, el control del marcado y sobre todo la portabilidad: normalmente no puedes llevarte la web a otro sitio.
¿Podrá otro proveedor retomar la web?
Depende de tres cosas que conviene comprobar antes de firmar: quién tiene los accesos al alojamiento y al dominio, si el código está versionado y entregado, y si las decisiones técnicas están documentadas. Un WordPress estándar se retoma en unas horas; una web a medida sin repositorio ni documentación cuesta de dos a cinco jornadas de ingeniería inversa antes del primer cambio.
¿Hace falta un CMS concreto para cumplir con la accesibilidad?
No, el CMS apenas influye. La conformidad se decide en la plantilla, la jerarquía de títulos, los contrastes, las etiquetas de formulario y la forma de introducir el contenido. Un WordPress con una plantilla sobria puede cumplir; el mismo WordPress con un constructor de páginas visual rara vez lo hace.
Fuentes
- Google — Guía de iniciación al SEO — qué espera el buscador
- web.dev — Core Web Vitals — umbrales LCP, INP, CLS
- RGAA — referencial francés de accesibilidad — criterios y método de auditoría
- Google — Redirecciones y cambio de dirección — qué exige una migración de URL
¿Qué CMS encaja en tu caso?
Dime quién publica, con qué frecuencia y con qué nivel técnico. Te digo qué solución aguanta cinco años — y cuál te va a salir cara.
Plantear mi caso