GuíaPlataformas y herramientas
Una rutina de mantenimiento web que una publicación independiente puede sostener
Una rutina útil protege las tareas esenciales del lector, el proceso de publicación y la capacidad de recuperarse cuando un cambio sale mal.

En esta página
Una rutina de mantenimiento viable empieza por las partes del sitio que no deben fallar en silencio: que los lectores lleguen al contenido, que los editores puedan publicarlo, que los formularios importantes entreguen sus mensajes y que el propietario pueda recuperar el sitio. Asigna a cada comprobación un responsable y una respuesta clara si falla.
El calendario siguiente es un punto de partida, no un motivo para aplazar una corrección urgente. Una alerta de seguridad, una copia fallida o un acceso que no funciona deben atenderse cuando aparecen. Un sitio que publica durante todo el día también puede necesitar revisiones más frecuentes que un archivo pequeño que apenas cambia.
Mantén un registro operativo breve
Anota los servicios de los que depende la publicación y quién puede acceder a ellos. Incluye el registro del dominio, el DNS, el alojamiento, el CMS o sistema de compilación, el almacenamiento de medios, los formularios, el envío de correo y las suscripciones de pago que mantienen el sitio operativo.
Para cada uno, registra cuándo se renueva, quién se encarga de recuperarlo y qué función cumple. Guarda los secretos en un sistema seguro apropiado, no en el repositorio público ni en una lista compartida de mantenimiento. La lista debe indicar a la persona autorizada dónde obtener acceso.
Define unas pocas páginas y tareas representativas. Por ejemplo: abrir un artículo reciente en un teléfono, seguir un enlace de navegación, buscar un contenido antiguo, guardar un borrador y enviar un mensaje de prueba autorizado. Elige las tareas que importan en tu sitio; no añadas una prueba para una función que no ofreces.
Mantén un único registro de cambios con fechas, componentes afectados y persona responsable. Cuando aparezca un problema, será más útil que intentar reconstruir de memoria qué plugin o plantilla cambió.
Cada semana: comprueba que los recorridos esenciales funcionen
Visita las páginas representativas sin una sesión de administrador. Busca imágenes ausentes, texto ilegible, menús rotos o una interfaz que tape el artículo en una pantalla pequeña. Prueba la navegación por teclado en los controles principales. Una página puede cargarse correctamente y seguir siendo difícil de utilizar.
Prueba los formularios de principio a fin cuando tengas autorización: envío, confirmación y llegada al destino previsto. Utiliza un mensaje claramente identificado como prueba y elimina después los datos de prueba innecesarios. Un aviso de éxito en el navegador no demuestra que el mensaje haya llegado.
Revisa tareas fallidas, errores recientes y resultados de las copias de seguridad. Comprueba que la copia más reciente corresponda a la actividad del sitio. La frecuencia de las copias debe reflejar cuánto trabajo nuevo puede permitirse perder la publicación, no una preferencia arbitraria por una tarea semanal.
Revisa las actualizaciones disponibles y los avisos oficiales de los componentes que realmente utilizas. Para WordPress, la documentación de actualización recomienda mantener el software al día y realizar una copia antes de actualizar. Decide cómo se aplicarán las actualizaciones habituales y cómo se gestionarán las correcciones urgentes de seguridad; no dejes que todas esperen a un rediseño indefinido.
Revisa los enlaces nuevos importantes y sus destinos, especialmente los comerciales. Un enlace que sigue devolviendo una página puede llevar ahora a un evento pasado, un producto no disponible o una oferta sin relación. La disponibilidad técnica y la exactitud editorial son comprobaciones distintas.
Cada mes: revisa recuperación, acceso y deterioros graduales
Restaura una copia reciente en un entorno aislado y examina el resultado. Alterna con el tiempo las páginas y funciones revisadas para no dejar olvidados permanentemente un archivo antiguo, una colección de imágenes o un idioma secundario. El manual de copias de seguridad de WordPress ofrece un ejemplo útil de por qué importan tanto los archivos como el contenido de la base de datos.
Revisa quién tiene acceso. Elimina las cuentas que ya no lo necesitan, comprueba los permisos de los colaboradores activos y verifica los medios de recuperación. Confirma quién recibe los avisos de seguridad y facturación. Una bandeja de entrada que nadie lee no debe ser el único lugar al que llegue una advertencia importante.
Examina el rendimiento con pruebas repetibles y datos de usuarios reales cuando estén disponibles. La documentación de Web Vitals de Google distingue la medición de campo de las herramientas de desarrollo y diagnóstico. Mantén constantes las condiciones de prueba e investiga los retrocesos significativos, en lugar de perseguir una puntuación perfecta después de cada cambio menor.
Revisa la indexación y la visibilidad en buscadores de las secciones importantes. Examina ejemplos de páginas recién publicadas, investiga exclusiones inesperadas y busca avisos de indexación o seguridad. Un cambio de tráfico necesita un proceso de diagnóstico propio, no una instrucción automática para reescribir el sitio.
Revisa también las renovaciones próximas y el crecimiento del almacenamiento u otros recursos limitados. Así, una decisión de alojamiento será una comparación planificada en lugar de una reacción apresurada a una cuenta vencida o un disco lleno.
Antes y después de cada versión: prepara la recuperación
Antes del despliegue, identifica el cambio y el efecto esperado. Guarda la versión actual, confirma la copia de seguridad pertinente y decide qué obligaría a volver atrás. Prueba las plantillas afectadas y los recorridos esenciales en una vista previa privada.
Separa las correcciones de contenido de los cambios técnicos más amplios cuando sea posible. Si una versión modifica a la vez la navegación, la gestión de imágenes y la analítica, un fallo posterior tendrá más causas posibles. Eso no impide una versión conjunta; hace más valiosa la documentación y las comprobaciones específicas.
Después del despliegue, verifica el resultado público real. Abre las páginas modificadas, revisa los enlaces importantes, comprueba los formularios si se han visto afectados y verifica que no se haya mostrado material privado o en borrador. Comprueba la URL publicada en lugar de suponer que una carga correcta significa que la página adecuada está en línea.
Si la versión falla, utiliza el procedimiento de recuperación acordado y conserva pruebas suficientes para diagnosticarla. Registra qué ocurrió, qué se restauró y si hay contenido o envíos más recientes que deban conciliarse. No consideres que volver a la versión anterior ha funcionado solo porque se carga el inicio.
Adapta la rutina a sitios estáticos y sitios con CMS
Un sitio estático sigue dependiendo de su código fuente, proceso de compilación, credenciales de despliegue, recursos y servicios externos. Conserva una versión reproducible de la compilación e identifica qué funciones de formularios, búsqueda o pago se ejecutan en otros servicios. Regenerar archivos de artículos no puede restaurar datos almacenados por un servicio separado.
Un CMS añade un entorno de ejecución, una base de datos, temas o extensiones y acceso administrativo. La rutina debe cubrir esos componentes además de las páginas públicas. En cualquiera de las arquitecturas, asegúrate de que alguien pueda explicar qué debe restaurarse y en qué orden.
Termina cada sesión de mantenimiento con un breve registro de excepciones y acciones asignadas. El propósito no es producir una larga lista de marcas verdes. Es descubrir fallos cuando todavía son pequeños y dejar a la siguiente persona una idea clara del estado del sitio.
Traducido de la edición fuente en inglés.
Fuentes primarias
- documentación de actualizaciónwordpress.org
- manual de copias de seguridad de WordPressdeveloper.wordpress.org
- documentación de Web Vitals de Googleweb.dev


