Cinco formas de poner un CMS detrás de una web HTML que ya existe, y lo que te cuesta de verdad cada una en tiempo de puesta en marcha, cambios de código y mudanzas de alojamiento. Una de ellas la hacemos nosotros, y decimos sin rodeos dónde es la respuesta equivocada.
La forma más rápida de añadir un CMS a una web HTML que ya existe es engancharle una capa de edición alojada con una sola etiqueta de script. El marcado, los estilos y el alojamiento se quedan tal cual, y el contenido pasa a ser editable en su sitio, normalmente en menos de cinco minutos.
Todas las alternativas implican tocar el build. Rehacer la web en WordPress cambia la forma en que se generan las páginas. Un CMS sobre git necesita un repositorio y un pipeline de despliegue. Un CMS headless necesita a alguien que modele el contenido y lo conecte con las plantillas. Un CMS PHP de ficheros planos necesita PHP en el servidor y permisos de escritura en la raíz web.
Elige con dos preguntas: ¿hay que tocar el código? y ¿el cliente necesita una cuenta en algún sitio? Todo lo demás son detalles.
| Capa con etiqueta de script | Rehacer en WordPress | CMS sobre git | CMS headless | PHP de ficheros planos | |
|---|---|---|---|---|---|
| Ejemplos | Qixoo | WordPress + una plantillaElementor, Bricks | TinaCMS, DecapCloudCannon, Sveltia | Contentful, SanityStoryblok, Prismic | Sitecake, CouchCMSGetSimple |
| Puesta en marcha realista | ~5 minutos | 1–3 días | 2–6 horas | 1–2 días de desarrollo | 1–2 horas |
| ¿Hay que tocar el código? | Una línea | Se rehace desde cero | Hay que anotar las plantillas | Plantillas reescritas | Etiquetas de comentario por zona |
| ¿Se muda la web? | No: se queda donde está | Normalmente sí | Necesita git y un build | Necesita un build o un servidor | Necesita alojamiento con PHP |
| El cliente necesita cuenta | No: enlace de invitación | Sí, un usuario de WordPress | Sí, normalmente un acceso a git | Sí, un asiento del CMS | Sí, una contraseña del CMS |
| De quién es la marca del editor | Neutra, o la tuyaTu logo con el módulo de marca blanca, 29 $ una vez | WordPress | Varía, a menudo la del proveedor | La del proveedor | La de la herramienta |
| Mantenimiento continuo | Ninguno por tu parte | Actualizaciones de core, plantilla y plugins | Mantener el pipeline de build | Mantener la integración | Actualizaciones de PHP y permisos de ficheros |
| Coste típico | $0–$99/moEl plan gratis cubre 1 web | Alojamiento más tu tiempoEl software es gratis | Free–$100/moDecap y Tina son de código abierto | $100–$500+/mo | Licencia de pago únicoA menudo menos de 100 $ |
| El contenido vive en el HTML de origen | Se reaplica en el navegador | Sí | Sí, en el build | Sí, si se renderiza en el servidor | Sí, escrito en el fichero |
Los tiempos son para una web escaparate de cinco páginas entregada a un cliente no técnico, por alguien que ya ha usado la herramienta antes. La primera vez con cualquiera de ellas serás más lento.
Todas las opciones de esta página son la mejor opción para alguien. Aquí está quién debería pasar de largo ante cada una.
Un blog con una entrada al día, una tienda con mil referencias, un portal de empleo: cualquier cosa donde el contenido se produce en volumen y tiene que estar en el HTML de origen en cuanto cambia pertenece a un CMS de verdad, con plantillas y base de datos.
Pasa de ella también si necesitas flujo editorial: borradores, revisión, publicación programada, tres personas aprobando un párrafo.
Encaja en: webs escaparate, landings y webs de negocio local, las que cambian unas pocas veces al mes.
Rehacer en WordPress una web ya terminada cuesta días, y el día que acabas has adoptado un trabajo de mantenimiento: actualizaciones del core, actualizaciones de plugins, seguridad, copias. Alguien paga eso para siempre, y normalmente eres tú.
Además tira a la basura todo lo que hacía que tu web original fuera rápida y limpia.
Encaja en: webs que de verdad necesitan plugins: membresías, reservas, una tienda de verdad.
Decap, Tina y CloudCannon son buenas herramientas, baratas o gratis, y guardan el contenido en tu repositorio. También dan por hecho que hay un repositorio, un build y un despliegue que se lanza cuando cambia el contenido. Alguien tiene que hacerse cargo de ese pipeline.
Cuando el build se rompe, el cambio del cliente no aparece, y quien recibe la llamada eres tú.
Encaja en: webs llevadas por desarrolladores, documentación y equipos que ya viven en git.
Contentful, Sanity y Storyblok están hechos para contenido a escala repartido por muchos canales. Para un restaurante con una carta y un bloque de horarios te vas a pasar un día modelando tipos de contenido y reescribiendo plantillas para resolver un problema que cabía en una frase.
El precio mensual también está en otro orden de magnitud.
Encaja en: contenido multicanal, apps y varias webs compartiendo un mismo fondo de contenido.
Sitecake y CouchCMS escriben directamente en tus ficheros HTML, lo cual es elegante, y necesita PHP, permisos de escritura en la raíz web y un alojamiento que tolere ambas cosas. Netlify, Vercel y Cloudflare Pages no lo hacen.
Varias herramientas de esta categoría llevan además años sin una actualización de verdad.
Encaja en: alojamiento compartido clásico con cPanel y FTP.
Si quien edita la web es desarrollador, mete el contenido en git. Si la edita a diario un equipo de marketing, compra un CMS de verdad. Si es el dueño de un restaurante que quiere cambiar un precio un domingo y no ha iniciado sesión en nada en su vida, deja la edición en la propia página.
La respuesta equivocada siempre es: «mándame los cambios y ya los hago yo».
Pégalo una vez antes de </head> en cada página, o en el campo de código personalizado del head de la plataforma que aloje la web. En el marcado no cambia nada más.
Abre la web publicada con la sesión iniciada y haz clic en un titular, un párrafo, una imagen o un enlace para cambiarlo. El contenido guardado se reaplica en cada carga de página.
Abre su propia web y la edita en un editor reducido y sin marca de Qixoo. Sin cuenta, sin panel y sin código. Pon ahí tu propio logo con el módulo de marca blanca.
Textos y titulares, imágenes, enlaces, botones, elementos de lista, menús, galerías y sliders: lo que los clientes piden cambiar de verdad. También puedes soltar bloques prefabricados (unas FAQ, una lista de precios, una fila de testimonios) sin escribir marcado.
No reestructura tu maquetación, y no es una caja de permisos: el editor de cliente es una interfaz reducida que oculta la edición estructural, no un candado sobre la página que hay debajo. Tampoco aloja tu web: el HTML lo sigue sirviendo tu alojamiento.
Tu alojamiento sigue sirviendo el HTML que escribiste, así que un rastreador recibe siempre una página completa. El contenido editado a través de la capa se reaplica en el navegador, lo que significa que un cambio puede tardar más en recogerse que si tocaras el fichero de origen. Para un titular o un párrafo de entrada que cambia un par de veces al año, eso no es problema. Si el contenido entero de una página tiene que indexarse el mismo día que cambia, edita también el HTML.
No. Una capa de edición con etiqueta de script se engancha al HTML que ya publicaste: marcado, estilos y alojamiento se quedan como están. Rehacer la web solo hace falta por la vía de WordPress o la headless, que cambian la forma en que se generan las páginas.
El HTML original lo sigue sirviendo tu alojamiento, así que la página que recibe un rastreador es la que escribiste. El contenido editado se reaplica en el navegador, de modo que un texto cambiado puede verse más tarde que un cambio estático. Perfecto para textos que cambian de vez en cuando; edita también el origen si una página tiene que indexarse el día que cambia.
Con Qixoo, no: le mandas un enlace de invitación y edita su propia web publicada. Con los Client Seats de Webflow, con WordPress o con un CMS headless, cada persona que edita necesita una cuenta en esa plataforma.
Funciona en cualquier web que sirva HTML, sea cual sea el alojamiento: HTML escrito a mano, generadores estáticos, webs exportadas de Webflow o Framer, plantillas de WordPress y cualquier cosa en Netlify, Vercel, Render, cPanel o un VPS. En webs alojadas en Webflow la etiqueta va en Site Settings → Custom Code, que requiere un plan de sitio de pago de Webflow.
Sigue online con todos los cambios guardados intactos: las visitas ven el contenido actual. Solo se pausa la edición hasta que vuelva a haber un plan activo. No se borra nada y no hay que migrar nada de vuelta.
En la medida de lo posible. Las apps que vuelven a renderizar el DOM después de cargar pueden sobrescribir el contenido inyectado, así que prueba una página antes de prometérselo a un cliente. El HTML renderizado en servidor y las exportaciones estáticas son el caso fiable.
Varias. Decap CMS y TinaCMS son gratis y de código abierto si la web vive en un repositorio git y te apañas con un pipeline de build. El plan gratuito de Qixoo cubre una web sin límite de tiempo. El software de WordPress es gratis; el alojamiento, el tiempo de migración y el mantenimiento no.
Empieza por la página escrita exactamente para eso: el reemplazo del Editor antiguo y la marca blanca de Webflow. Cubre los Client Seats, qué cambió el 4 de agosto de 2026 y cómo devolver la edición con un clic bajo tu propia marca.
Una línea de código. La primera web es gratis, sin límite de tiempo y sin tarjeta.
Empezar gratis →