UON Logo
Contáctenos
Soporte y MantenimientoSeguridad

¿Quién cuida de su proyecto después de la entrega?

11 min de lectura

El mantenimiento web va más allá de corregir errores: seguridad, copias de seguridad, dominio y velocidad. Conozca 7 cuidados y un plan en 5 pasos.

Mesa de taller con herramientas ordenadas alrededor de un portátil abierto, que sugiere el mantenimiento continuo de un sitio web

Mantenimiento de un sitio web después de la entrega: qué ocurre cuando nadie está mirando y cómo elegir quién mirará por usted.

El nuevo sitio web sale a producción, el equipo lo celebra y el contrato con quien lo desarrolló llega a su fin. Tres meses después, un formulario deja de enviar mensajes. Seis meses después, el navegador muestra un aviso de “sitio no seguro”. Un año después, el dominio vence y la página simplemente desaparece.

Ninguno de estos problemas es raro, y ninguno es culpa del sitio en sí. Un sitio web o un sistema no es un producto que se compra terminado y se guarda en un cajón. Se parece más a un coche: funciona muy bien cuando sale del concesionario, pero necesita revisiones, cambio de piezas y alguien que note el ruido extraño antes de que se convierta en un problema serio.

La pregunta que casi nadie hace al contratar es justamente la más importante: ¿quién cuida de su proyecto después de la entrega? En este artículo entenderá qué cambia cuando su proyecto sale a producción, qué cuidados no pueden faltar y cómo organizarlo todo sin necesidad de saber programar.

Quién participa después de que el sitio sale a producción

Incluso un sitio sencillo depende de varias piezas que no se quedan quietas. Conviene conocer cada una antes de decidir quién se ocupa de ellas:

  • Su empresa: dueña del sitio, de la marca y de los datos de los clientes que pasan por él.
  • Quien lo desarrolló: conoce el código por dentro, pero suele salir de escena cuando termina el contrato del proyecto.
  • El alojamiento (hosting): el “terreno” donde vive el sitio. Mantiene el servidor encendido, pero en general no toca su sitio.
  • El dominio: la dirección (susitio.com), que debe renovarse periódicamente.
  • Plugins, bibliotecas y servicios de terceros: formularios, pagos, mapas, herramientas de analítica. Cada uno lo actualiza otra empresa, a su propio ritmo.
  • Navegadores y buscadores: Chrome, Safari y Google cambian sus reglas con frecuencia, y el sitio tiene que adaptarse.

El problema aparece en el espacio entre estas piezas. El proveedor de alojamiento cree que el sitio es responsabilidad de quien lo desarrolló. Quien lo desarrolló cree que el contrato terminó. Y la empresa cree que, si nada está roto, todo va bien. Cuando todos creen que alguien se está ocupando, en la práctica nadie lo hace.

1. Actualizaciones de seguridad y de dependencias

Qué es: todo proyecto utiliza piezas prefabricadas (sistemas, plugins, bibliotecas). Cuando alguien descubre un fallo en una de ellas, el fabricante publica una corrección. Actualizar es instalar esa corrección.

Por qué importa: un fallo conocido es como una cerradura cuya combinación se ha publicado en internet. Patchstack, empresa especializada en seguridad de WordPress, registró 7966 nuevas vulnerabilidades en 2024 en el ecosistema WordPress, unas 22 al día, y el 96% estaba en plugins. En el informe de 2023 de Sucuri, el 39,1% de los sistemas de gestión de contenidos hackeados estaban desactualizados en el momento de la limpieza.

No es solo WordPress. Todo sitio, incluso uno hecho a medida, se construye sobre dependencias: el lenguaje en el que se ejecuta (como PHP o Node.js), el framework y decenas de bibliotecas de código abierto que se encargan de tareas como formularios, imágenes o pagos. Cada una recibe parches de seguridad, pequeñas correcciones publicadas cuando se descubre un fallo. Piense en ellas como las llamadas a revisión de un coche: el fabricante encontró el defecto y la corrección existe, pero solo sirve a quien lleva el coche al taller.

Además, estas piezas tienen fecha de caducidad. PHP, por ejemplo, ofrece a cada versión dos años de soporte completo y dos años más solo para correcciones críticas de seguridad. Después de eso, los nuevos fallos ya no se corrigen. Un sitio que nunca cambia de versión acaba, poco a poco, funcionando sobre piezas que nadie repara.

En la práctica, cuidar las dependencias implica tres rutinas:

  • Aplicar los parches de seguridad en cuanto se publican, priorizando los fallos graves.
  • Usar herramientas que avisan cuando una biblioteca del proyecto tiene un fallo conocido (muchos servicios de alojamiento de código lo hacen automáticamente).
  • Planificar las actualizaciones mayores, como cambiar la versión del lenguaje o del framework antes del fin del soporte, con pruebas antes de salir a producción.

Ejemplo práctico: la Empresa XPTO instaló un plugin de formularios en 2023 y nunca más lo actualizó. En 2025 se divulgó un fallo en ese plugin. Sin nadie vigilando, el sitio empezó a redirigir a los visitantes a páginas de apuestas.

Sea realista: las cifras anteriores son del ecosistema WordPress, el más usado del mundo. Los sitios hechos con otras tecnologías tienen los mismos riesgos de dependencias desactualizadas, pero estas cifras concretas no se les aplican directamente. Y actualizar también tiene riesgos: una actualización puede romper otra parte del sitio. Por eso debe hacerse con copia de seguridad y pruebas, no por impulso.

2. Copias de seguridad que funcionan de verdad

Qué es: una copia del sitio y de los datos guardada en otro lugar, lista para restaurarse.

Por qué importa: la copia de seguridad es lo que convierte un desastre en un contratiempo. La agencia de ciberseguridad de Estados Unidos (CISA) recomienda la regla 3-2-1: tres copias de los archivos importantes, en dos tipos de almacenamiento, con una de ellas fuera de la ubicación principal. La misma orientación pide algo que casi nadie hace: probar la restauración periódicamente.

Ejemplo práctico: el proveedor de alojamiento de XPTO hacía copias automáticas, pero las guardaba en el mismo servidor. Cuando el servidor falló, el sitio y las copias se perdieron juntos.

Pregunte a quien cuida de su sitio: “¿Cuándo fue la última vez que restauró una copia de seguridad para probarla?” Si la respuesta es “nunca”, usted tiene una esperanza, no una copia de seguridad.

3. Dominio, alojamiento y certificado al día

Qué es: el dominio es la dirección del sitio; el alojamiento, donde vive; el certificado de seguridad (SSL/TLS), el candado que aparece en el navegador.

Por qué importa: los tres vencen. Un dominio vencido y no renovado queda suspendido y, si sigue sin pagarse, puede liberarse para que otra persona lo registre. En Brasil, por ejemplo, un dominio .br primero queda congelado por Registro.br. El certificado, por su parte, vencerá cada vez más rápido: el CA/Browser Forum, grupo que define las reglas de estos certificados, aprobó reducir la validez máxima de 398 días a 200 días a partir del 15 de marzo de 2026, 100 días en 2027 y 47 días en 2029. Es decir, renovar a mano deja de ser viable; tiene que ser automático y estar monitorizado.

Ejemplo práctico: el dominio de XPTO estaba a nombre de un exempleado, con su correo registrado. Los avisos de vencimiento llegaron a un buzón que ya nadie leía.

4. Monitorización: saberlo antes que el cliente

Qué es: herramientas que revisan el sitio todo el tiempo y avisan cuando se cae, se vuelve lento o un formulario deja de funcionar.

Por qué importa: sin monitorización, quien descubre el problema es su cliente, normalmente en el peor momento. Un formulario de contacto roto no muestra ningún error en pantalla; simplemente deja de entregar mensajes, y usted solo se da cuenta cuando desaparecen las solicitudes de presupuesto.

Ejemplo práctico: un monitor sencillo comprueba la página de inicio cada pocos minutos y envía una alerta por WhatsApp o correo electrónico al responsable. Una prueba mensual de envío del formulario cubre el hueco que el monitor no ve.

5. Rendimiento y experiencia en Google

Qué es: la velocidad con la que el sitio carga y responde, sobre todo en el móvil.

Por qué importa: Google mide la experiencia de uso con las Core Web Vitals. Para considerarse buena, una página tiene que mostrar el contenido principal en un máximo de 2,5 segundos (LCP), responder a un toque en un máximo de 200 milisegundos (INP) y no “saltar” en la pantalla (CLS de hasta 0,1), considerando el 75% de las visitas. Un sitio rápido en el lanzamiento se vuelve lento con el tiempo: imágenes pesadas añadidas en el día a día, nuevos scripts de marketing, plugins acumulados.

Ejemplo práctico: el equipo de XPTO publicó en el blog fotos de 8 MB directamente desde el móvil. El sitio, que era rápido, empezó a tardar con datos móviles.

Sea realista: la velocidad es una de las señales que Google tiene en cuenta, pero por sí sola no garantiza una mejor posición en la búsqueda. El contenido relevante sigue pesando más.

6. Accesos y propiedad: el sitio tiene que ser suyo

Qué es: saber quién tiene las contraseñas y a nombre de quién están el dominio, el alojamiento, el código y las cuentas de servicios (Google Analytics, Search Console, correo electrónico).

Por qué importa: es habitual descubrir, al cambiar de proveedor, que todo está a nombre de otra persona. Sin los accesos, cualquier mantenimiento se convierte en una negociación.

Ejemplo práctico: un documento sencillo, guardado en el gestor de contraseñas de la empresa, con cada servicio, su titular, el correo registrado y la fecha de vencimiento. Quien cuida del sitio recibe acceso de colaborador, no de propietario.

7. Evolución: el sitio acompaña al negocio

Qué es: ajustes y mejoras continuas: nuevas páginas, un servicio recién lanzado, una campaña, una integración con el CRM.

Por qué importa: el negocio cambia y el sitio tiene que reflejarlo. Un sitio que no evoluciona envejece y, tarde o temprano, se convierte en un proyecto de rehacerlo todo, mucho más caro que pequeñas mejoras a lo largo del tiempo.

Ejemplo práctico: en lugar de rehacer el sitio cada tres años, XPTO reserva algunas horas al mes para mejoras priorizadas a partir de los datos de acceso y de las peticiones del equipo comercial.

Plan de acción: 5 pasos para no dejar su sitio huérfano

  1. Haga un inventario de accesos. Enumere dominio, alojamiento, código, correo y cuentas de Google, con titular, correo registrado y fecha de vencimiento. Todo lo que no esté a nombre de la empresa pasa a la lista de pendientes.
  2. Nombre a un responsable. Puede ser alguien del equipo, quien desarrolló el sitio o una empresa que ofrezca servicios especializados de mantenimiento y soporte continuo. Lo importante es que haya un nombre, y no un “alguien”.
  3. Defina por escrito qué incluye el mantenimiento. Actualizaciones, copias de seguridad con prueba de restauración, monitorización, renovaciones, plazo de respuesta ante problemas y cuántas horas de mejoras al mes.
  4. Active la monitorización y las alertas. Disponibilidad del sitio, vencimiento del dominio y del certificado, y una prueba periódica de los formularios.
  5. Programe una revisión trimestral. Media hora para revisar el informe de actualizaciones, la velocidad del sitio, los contactos recibidos y las mejoras de la siguiente ronda.

Conclusión

La entrega de un sitio no es la línea de meta; es la salida. Las empresas que tratan su sitio como un activo vivo, con alguien responsable de él, evitan sustos, gastan menos en rehacerlo y lo convierten en un canal que mejora con el tiempo.

La buena noticia es que no necesita saber programar para ello. Solo necesita hacer la pregunta correcta antes de que el problema la haga por usted: ¿quién cuida de su proyecto después de la entrega?

Si la respuesta todavía no está clara, UON puede ayudarle. Hable con nosotros y entenderemos juntos lo que su sitio necesita para seguir siendo seguro, rápido y trabajando para su negocio.

Referencias

¿Listo para convertir su idea en una solución digital eficiente?

Contáctenos y solicite un presupuesto personalizado para su proyecto.

Contáctenos