Respuesta breve
La pregunta del CMS no se resuelve comparando sistemas, sino con dos respuestas: quién editará el sitio y con qué frecuencia. Repasamos tres formas de edición, qué significa «CMS básico o conexión de datos» y qué sigue siendo tarea tuya.
La respuesta: el panel es para quien vaya a editar el sitio
Si hace falta un CMS lo decide un hecho y no una tabla comparativa de funciones: ¿hay alguien en la empresa que se vaya a sentar a cambiar el texto de una página? Si esa persona existe y las ediciones son regulares, el panel hace falta. Si no hay nadie, será otro sistema que mantener.
El fracaso tiene una forma reconocible. Se encarga el panel, se reparten los accesos y seis meses después nadie recuerda la contraseña, así que el texto lo sigue cambiando el desarrollador por correo. El dinero se fue en una capacidad que nadie usa y que igualmente hay que mantener al día.
Por eso la conversación empieza con dos preguntas: quién editará exactamente y con qué frecuencia. Esas dos respuestas definen la forma del panel, su tamaño y cuánto tiempo habrá que dedicar a formar a esa persona después del lanzamiento, mucho más que cualquier lista de funciones.
El resto del artículo explica qué significa «CMS básico o conexión de datos» en la práctica, qué formas de edición existen, qué sigue siendo responsabilidad tuya y cómo dejar la decisión por escrito antes de empezar, para no tener que rehacer el sitio después.
Nombra a una persona, no a un departamento
«De las actualizaciones se encarga marketing» no es una respuesta. Los departamentos no entran en el panel; entra un empleado concreto, con su usuario, su paciencia particular para las interfaces y su lista de tareas de la semana. Sin un nombre no se pueden escribir los requisitos.
Pregúntale a esa persona qué ha hecho antes con una web. Haber trabajado con cualquier panel cambia las expectativas: ya sabe qué son un borrador, una vista previa y un botón de publicar, y nadie tiene que explicarle la diferencia entre una página y un bloque dentro de ella.
La segunda pregunta es qué va a cambiar en realidad. Uno edita solo precios y teléfonos, otro escribe artículos, otro sube fotos al catálogo. Son tres conjuntos de campos distintos, y montarlos todos juntos por si acaso significa pagar por lo que nadie va a tocar.
Si no hay editor y no está previsto que lo haya, la respuesta honesta es que el panel no hace falta. En ese caso conviene pedir los cambios como una tarea puntual y dejar el contenido en las fuentes del proyecto, que recibes en la entrega junto con los accesos.
Con qué frecuencia cambia el contenido: tres patrones, tres conclusiones
El primer patrón es editar casi todos los días: noticias, promociones, novedades, ofertas de empleo. Aquí el panel se amortiza enseguida, porque cada petición a un proveedor cuesta tiempo y una cola de espera por un cambio de dos minutos frena a todo un equipo que tenía otro trabajo previsto.
El segundo patrón son unos pocos cambios al mes: actualizar una tarifa, reescribir la descripción de un servicio, añadir una reseña. Para eso basta un conjunto reducido de campos editables: los cambios son previsibles y un sistema de publicación completo quedaría casi sin uso entre uno y otro.
El tercer patrón es un sitio que cambia dos o tres veces al año. El panel se queda parado y sus actualizaciones hay que instalarlas igual. Encaja mejor Soporte técnico continuo: $290 al mes por actualizaciones prioritarias, un ritmo semanal de entregas y mantenimiento técnico, en ciclo mensual, con el volumen acordado al inicio de cada ciclo y 30 días de aviso para terminar.
Los patrones se mezclan. Los precios y los datos de contacto pueden cambiar cada semana mientras la estructura de páginas sigue intacta durante años. Entonces solo se abre a edición la parte que se mueve, y lo demás se queda en el código, donde un movimiento de ratón no lo alcanza.
Qué significa «CMS básico o conexión de datos» dentro del paquete Sitio para lanzamiento
El paquete Sitio para lanzamiento cuesta $380 e incluye una construcción responsive, CMS básico o conexión de datos y la configuración del despliegue. El plazo es de 3-5 días laborables, hay 2 rondas de revisiones antes del lanzamiento y el contenido y las traducciones los aporta el cliente.
«CMS básico» significa esto en la práctica: las partes del sitio que has señalado como cambiantes se exponen como campos editables y el resto queda montado. No es un constructor universal de páginas, sino un panel hecho a la medida de la lista concreta que dijiste que ibas a cambiar.
«Conexión de datos» es el otro camino: el contenido vive en una fuente externa, por ejemplo una hoja de cálculo o un catálogo, y el sitio lo lee desde allí. Encaja cuando alguien ya mantiene esos datos y duplicarlos en un panel aparte crearía una segunda versión de la verdad.
La elección entre ambos depende de la misma pregunta: ¿dónde trabaja cómodo el empleado? Quien ya vive dentro de una hoja de cálculo de compras no va a abrir un panel nuevo, y conectar los datos elimina a la vez la formación y una interfaz de más.
Tres formas de edición entre las que eliges
La primera forma son campos editables: un titular, un texto, un precio, una fotografía. Cada campo está definido de antemano y con un propósito claro, y desde dentro no se puede romper la maquetación. Cambia lo que se expuso, y nada por encima de eso.
La segunda forma es un sistema de publicación completo: borradores, fechas, autores, categorías, biblioteca de medios. Se justifica cuando aparecen materiales nuevos con regularidad y hace falta orden en el archivo, no solo cuando hay que corregir un párrafo ya publicado.
La tercera forma es el contenido en las fuentes del proyecto. El texto vive junto al código y cada cambio pasa por una compilación y un despliegue. Para un equipo con desarrollador funciona; para un propietario sin perfil técnico en plantilla, no funciona.
Las formas se combinan. Las fichas de servicio pueden vivir en campos, los artículos en un sistema de publicación y los textos legales en las fuentes, porque los abogados los reescriben una vez al año y siempre a través de una tarea, nunca un viernes por la tarde.
Editar contenido no es lo mismo que mover la maquetación
Conviene aclarar una expectativa antes de empezar: un panel suele permitir cambiar el contenido, no arrastrar bloques por la pantalla con el ratón. Ese límite es deliberado y protege el diseño y la maquetación de los cambios hechos con prisa y publicados sin revisar.
Un editor libre de bloques da más libertad y, con ella, más maneras de estropear una página: márgenes descuadrados, cinco tamaños de titular distintos, una imagen estirada a todo el ancho. A los seis meses el sitio parece montado con piezas de kits que no encajan entre sí.
Por eso el briefing no debería decir «quiero cambiarlo todo». Debería enumerar elementos: el titular del servicio, el precio, el plazo, tres viñetas de ventajas, la fotografía. Una lista así se convierte en campos directamente, sin un paso de interpretación por el medio.
Si más adelante hace falta un tipo de página nuevo o un bloque nuevo, eso es trabajo aparte. El paquete Desarrollo de producto, de $880, lo cubre: 2-3 semanas, con 2 rondas de revisiones por cada funcionalidad entregada; las aplicaciones móviles nativas y las licencias de pagos no se incluyen.
Catálogo, precios y datos: cuando el panel deja de tratar de texto
Un catálogo cambia cómo se plantea la pregunta. Ya no se trata de un párrafo en una página sino de estructura: un producto tiene nombre, precio, disponibilidad, fotografías y categoría, y todo eso debe seguir coherente entre el listado y la ficha del producto.
Lo que hay que decidir es dónde está la fuente de verdad. Si los productos se mantienen en un sistema de gestión, el sitio debería leerlos de allí. Si no, aparecen dos versiones del precio y alguien acabará enviándole al cliente la antigua dentro de un presupuesto.
Cargar el catálogo a mano en el panel tiene sentido cuando hay pocas referencias y se mueven poco. En cuanto son cientos, la carga manual se convierte en un trabajo permanente que nadie puso en el presupuesto y que nadie quiere heredar.
Los filtros, los estados y las rutas son desarrollo y no redacción. El paquete Desarrollo de producto lo dice de forma directa: entrega de funcionalidades, lógica de estados y rutas, pruebas y endurecimiento, que es otro orden de trabajo distinto a rellenar un campo en un panel.
Los textos y las traducciones quedan de tu lado
Un límite que conviene decir claro: VITON13 no escribe el contenido del cliente ni hace traducciones. Las condiciones de Sitio para lanzamiento lo indican sin rodeos: el contenido y las traducciones los aporta el cliente. El panel no cambia eso, solo ofrece el lugar donde colocar el texto.
La consecuencia práctica es que el texto debe existir cuando llega la construcción. Un panel vacío el día del lanzamiento significa un sitio vacío y no flexibilidad: el visitante ve marcadores de posición y los buscadores indexan páginas en las que no hay nada que leer.
Con los idiomas ocurre lo mismo. Tres versiones lingüísticas son tres juegos de textos que alguien tiene que escribir y mantener al día. Sin ese recurso resulta más honesto lanzar en un idioma y añadir los demás cuando haya algo que valga la pena añadir.
También ayuda acordar quién responde de cada idioma: una persona escribe y publica, otra solo revisa. De lo contrario, tras el lanzamiento las ediciones se atascan entre varios validadores, y ningún panel ha resuelto nunca una cola formada por personas.
Imágenes, peso de la página y velocidad de carga
El panel pone la subida de imágenes en manos de alguien sin formación técnica. Una foto hecha con el móvil y subida tal cual puede pesar varios megabytes, y el navegador tiene que descargarla antes de que la página termine de asentarse en la pantalla.
Por eso el tratamiento de imágenes se resuelve del lado del sitio: límites de tamaño, compresión, formatos modernos y carga diferida de todo lo que queda bajo la primera pantalla. La documentación de rendimiento de MDN recorre estas técnicas una por una y explica qué cambia cada una.
Conviene limitar también la entrada: una indicación de las proporciones esperadas junto al campo, un aviso cuando el archivo es demasiado grande, un recorte a una relación de aspecto fija. Sale más simple que limpiar cada mes las consecuencias de la subida de otra persona.
La velocidad también hay que revisarla después del lanzamiento y no solo en la aceptación. El contenido se acumula, y una página que era ligera el primer día puede arrastrar decenas de fotos subidas un año más tarde, sin que nadie note la deriva mientras ocurre.
Accesibilidad: lo que un editor puede romper sin darse cuenta
Por el panel pasan cosas de las que depende que la página se pueda usar. WCAG 2.2 exige alternativas textuales para el contenido no textual, que es el criterio 1.1.1, y quien las rellena suele ser la misma persona que ha subido la imagen.
Los encabezados son el segundo ejemplo. El criterio 1.3.1 pide que la estructura de la página esté disponible de forma programática y no solo visual. Cuando un editor crea un subtítulo poniendo una línea en negrita, la estructura desaparece aunque en pantalla se vea casi igual.
De ahí sale un requisito práctico para el panel: un campo alt junto a cada subida, niveles de encabezado elegidos de una lista y no fijados por el tamaño de letra, y enlaces con texto con sentido en lugar de «ver más» repetido cinco veces en una misma página.
La referencia rápida de W3C para WCAG 2.2 funciona aquí como lista de comprobación: reúne los criterios en un solo lugar que se puede recorrer. Algunos puntos corresponden al desarrollo y otros dependen de lo que el editor escriba en el panel.
Accesos, roles y qué recibes en la entrega
Los roles no son una cuestión de confianza sino de consecuencias. Una persona publica, otra prepara borradores, otra solo consulta las estadísticas. Ese reparto reduce la posibilidad de que una edición accidental salga al sitio en vivo un viernes por la tarde y siga ahí el lunes.
Las cuentas deben estar a nombre de la empresa y no del correo personal de un empleado. Cambiar de proveedor o perder a un responsable no puede significar perder el acceso al panel, al dominio y al alojamiento junto con esa persona y su buzón.
En la entrega conviene pedir algo más que los usuarios: una nota corta sobre cómo añadir una página, cómo sustituir una fotografía y cómo deshacer un error. Una página de texto ahorra decenas de correos durante el primer mes desde que el sitio está en vivo.
Si las ediciones llegan más rápido de lo que el equipo puede asumirlas, Soporte técnico continuo cuesta $290 al mes e incluye actualizaciones prioritarias, un ritmo semanal de entregas y mantenimiento técnico. Una construcción nueva o un rediseño no entran y se presupuestan aparte.
Cómo dejar la decisión por escrito y con qué paquete empezar
Escribe la decisión en un párrafo: quién edita, qué edita, con qué frecuencia y qué se queda en el código. Ese párrafo responde a si necesitas un CMS y de qué tipo en tus propios términos, y no en los de la tabla de funciones de otra persona.
Para un sitio nuevo encaja Sitio para lanzamiento por $380: construcción responsive, CMS básico o conexión de datos, configuración del despliegue, 3-5 días laborables y 2 rondas de revisiones antes del lanzamiento. El contenido y las traducciones los preparas tú antes de que empiece la construcción.
Cuando la fecha ya está fijada existe Launch Site Express por $520, el mismo alcance en cola prioritaria: 2 días laborables, compilaciones diarias, una lista de comprobación de lanzamiento y una llamada de entrega, con 1 ronda de revisiones tras la primera construcción completa. Contenido, fotografía y soporte continuo no se incluyen.
Si el sitio ya funciona y solo necesita correcciones puntuales, empieza con Site Fix Pack por $70: hasta 5 arreglos acordados, una revisión en móvil y escritorio y una lista de antes y después en la entrega, en 1-2 días laborables con 1 ronda de revisiones. Páginas nuevas, rediseño y migraciones no entran; los detalles están en /es/services/development.
Lista práctica
- Nombra al empleado que abrirá el panel y escribe ese nombre en el briefing.
- Enumera los elementos concretos que hay que editar: titular, precio, plazo, fotografía, viñetas.
- Calcula con qué frecuencia cambia el contenido: a diario, unas veces al mes o dos al año.
- Decide dónde está la fuente de verdad de precios y catálogo para no mantener los datos dos veces.
- Prepara los textos y las traducciones antes de empezar la construcción, porque ningún panel los aporta.
- Revisa en la aceptación los campos alt, los niveles de encabezado y el peso de las imágenes subidas.
Preguntas frecuentes
¿Cómo sé si necesito un CMS?
Nombra a la persona que cambiará el contenido y con qué frecuencia lo hará. Si ese editor existe y las ediciones son regulares, el panel hace falta. Si el sitio cambia dos o tres veces al año quedará parado, y encaja mejor un soporte con los cambios pedidos como tareas.
¿Qué significa CMS básico dentro del paquete Sitio para lanzamiento?
El paquete cuesta $380 e incluye construcción responsive, CMS básico o conexión de datos y configuración del despliegue. El plazo es de 3-5 días laborables con 2 rondas de revisiones antes del lanzamiento, y el contenido y las traducciones los aporta el cliente.
¿Podré mover bloques y cambiar el diseño de las páginas desde el panel?
Normalmente no: el panel cambia el contenido dentro de campos definidos de antemano, no la disposición de los bloques. Los tipos de página nuevos y los bloques nuevos son trabajo aparte, más cerca del paquete Desarrollo de producto.
¿Cuánto cuesta el soporte si no podemos llevar el panel por nuestra cuenta?
Soporte técnico continuo cuesta $290 al mes e incluye actualizaciones prioritarias, un ritmo semanal de entregas y mantenimiento técnico. Funciona en ciclo mensual, el volumen se acuerda al inicio de cada ciclo y se termina avisando con 30 días.
¿Escribís vosotros los textos y las traducciones del sitio?
No. El contenido y las traducciones los aporta el cliente, y así consta en las condiciones de Sitio para lanzamiento. De nuestro lado queda dónde se coloca ese texto, cómo se comporta en cada pantalla y cómo se cambia después.