Qué incluir en un informe de mantenimiento web mensual (con plantilla)

Respuesta corta: un buen informe de mantenimiento web, enviado cada mes, cabe en una o dos páginas y responde a cuatro preguntas del cliente: ¿ha estado la web disponible?, ¿está segura y al día?, ¿qué habéis hecho este mes? y ¿hay algo que tenga que decidir yo? Incluye disponibilidad, actualizaciones, seguridad, copias, rendimiento, SEO técnico, correo y cookies, y termina con pendientes y recomendaciones. Abajo tienes la plantilla.

Esta guía es parte de Checklist de entrega de una web al cliente. La checklist deja la web bien el día de la entrega; el informe mensual demuestra que sigue bien.

Para qué sirve el informe (y por qué muchos no se leen)

El mantenimiento bien hecho es invisible. Si todo va bien, el cliente no nota nada, y lo que no se nota acaba pareciendo que no se hace. El informe mensual existe para hacer visible ese trabajo y para que las decisiones que dependen del cliente no se queden sin tomar.

Muchos informes no se leen por tres motivos: son exportaciones automáticas de 15 páginas con gráficos que nadie entiende, solo dicen «todo OK» sin explicar qué se ha comprobado, o mezclan datos técnicos con cosas que el cliente sí tiene que decidir y las decisiones se pierden.

Cómo saber si tu informe funciona

• El cliente responde o pregunta algo al menos de vez en cuando.
• Las recomendaciones que haces se aprueban o se rechazan, pero no se quedan en el aire meses.
• Cuando hay un problema, el cliente recuerda que se lo avisaste en el informe.
• Lo puedes preparar en menos de 30 minutos por web, porque los datos salen de herramientas, no de entrar a mirar.

Si ninguna de estas se cumple, el informe necesita una vuelta.

Qué incluir en el informe de mantenimiento web: las secciones

1. Resumen en tres líneas

Lo primero, y lo único que leerán muchos clientes. Estado general (verde, ámbar, rojo), lo más importante que ha pasado y si hay algo que decidir. Ejemplo: «La web ha estado disponible todo el mes. Hemos aplicado 14 actualizaciones y corregido un fallo del formulario de contacto. Necesitamos tu visto bueno para renovar el certificado del dominio secundario.»

2. Disponibilidad

• Porcentaje de disponibilidad del mes.
• Caídas: cuántas, cuándo, cuánto duraron y por qué.
• Qué se hizo para que no se repitan.

Un 99,9 % de disponibilidad son unos 43 minutos de caída al mes. Dale contexto al número: no es lo mismo una caída de 40 minutos a las 4 de la madrugada que en hora punta de una tienda.

3. Actualizaciones

• Versión de WordPress, y si se ha actualizado.
• Plugins y tema actualizados (número, y los importantes por nombre).
• Actualizaciones que se han dejado pendientes a propósito y por qué (por ejemplo, una versión mayor de WooCommerce que se prueba antes en staging).
• Cualquier incidencia tras una actualización y cómo se resolvió.

4. Seguridad

• Vulnerabilidades conocidas detectadas en plugins o tema, y si están corregidas.
• Usuarios administradores: cuántos hay y si ha cambiado algo.
• Incidencias: spam, enlaces sospechosos, intentos de acceso anómalos.
• Estado del certificado SSL y fecha de caducidad.

5. Copias de seguridad

• Frecuencia y fecha de la última copia correcta.
• Dónde se guardan y cuántos días se conservan.
• Última prueba de restauración y resultado. Esto es lo que da tranquilidad de verdad: una copia que nunca se ha restaurado no garantiza nada.

6. Rendimiento

• Métricas de Core Web Vitals de las páginas principales, en móvil: LCP (bueno por debajo de 2,5 s), INP (bueno por debajo de 200 ms) y CLS (bueno por debajo de 0,1). Google explica los umbrales en su documentación de Core Web Vitals.
• Comparación con el mes anterior.
• Lo que se ha optimizado y lo que se propone.

No pongas solo la puntuación de PageSpeed: varía de una medición a otra y el cliente se preocupa cuando baja dos puntos sin motivo. Las métricas de campo (datos de usuarios reales) son más estables.

7. SEO técnico

• Páginas indexadas y errores de indexación (Search Console → Indexación → Páginas).
• Clics e impresiones del mes frente al anterior y frente al mismo mes del año pasado.
• Problemas técnicos encontrados y corregidos: enlaces rotos, redirecciones, títulos duplicados, errores del sitemap.
• Cambios relevantes: un título de la portada modificado, un sitemap que ha perdido URLs.

Si alguno de estos puntos te suena, tenemos guías de cada uno en Mi web no aparece en Google: las causas técnicas.

8. Correo y dominio

• Estado de SPF, DKIM y DMARC.
• Si el dominio o la IP del correo han aparecido en alguna lista negra.
• Fecha de renovación del dominio.

9. Privacidad y cookies

• Si la web carga cookies o rastreadores antes del consentimiento.
• Cambios en las herramientas de analítica o publicidad instaladas.

10. Trabajo realizado

Lista breve de tareas del mes: lo planificado y lo que surgió. Con fecha y, si el contrato es por horas, tiempo dedicado.

11. Pendientes y recomendaciones

Separadas en dos bloques:

• Necesitamos tu decisión: cosas que requieren aprobación, presupuesto o acceso del cliente.
• Recomendamos para los próximos meses: mejoras sin urgencia.

Cada recomendación con una frase de por qué importa, en lenguaje de negocio: «Si el DMARC sigue en modo vigilancia, cualquiera puede enviar correos haciéndose pasar por vuestro dominio», no «DMARC p=none».

Plantilla de informe de mantenimiento web

Copia y adapta:

Y un ejemplo de cómo se redacta una sección, para que se entienda sin conocimientos técnicos:

SEGURIDAD — Estado: correcto
- El 12 se publicó una vulnerabilidad en el plugin de formularios.
  La corregimos el mismo día actualizándolo a la versión nueva.
- Hay 2 administradores (tú y nosotros). Sin cambios este mes.
- Certificado SSL válido hasta el 18 de enero. Se renueva solo.

Errores habituales

• Mandar el informe en bruto de una herramienta. Úsalas para sacar los datos, pero escribe tú el resumen y las recomendaciones.
• Ocultar los problemas. Si hubo una caída, cuéntala con su causa y su solución. Un cliente se fía más de una agencia que le cuenta lo que pasó que de una que siempre dice «todo OK».
• Llenarlo de jerga. Si el cliente tiene que buscar qué es un TTFB, has perdido su atención.
• Recomendaciones sin dueño ni fecha. Cada pendiente debe decir quién lo tiene que hacer.
• No guardar el histórico. El informe de este mes debe poder compararse con el anterior. Usa siempre la misma estructura.

Para agencias: los datos del informe, ya recogidos

La parte lenta del informe no es redactarlo, es recoger los datos de cada web. Jeffrey ya los tiene porque vigila las webs todo el mes: las caídas con su hora de inicio y de fin, las incidencias de seguridad, SSL, correo y cookies con su historial, los cambios de SEO detectados en la portada y los hallazgos del rastreo, las mediciones de rendimiento (LCP, CLS, FCP, TTFB y puntuación, en móvil y escritorio) y qué herramientas de analítica tiene instaladas cada web.

Con el plugin de Jeffrey instalado, además, el inventario de versiones de core, plugins y tema, las vulnerabilidades conocidas, los administradores y el estado de las copias gestionadas, incluida la última prueba de restauración. Los avisos de todo esto llegan durante el mes a la agencia y a NexaTech a la vez, con una primera respuesta en menos de 4 horas, así que el informe cuenta problemas que ya se han resuelto y no problemas que se acaban de descubrir. Y puede ir con la marca de la agencia.

Si quieres montar la vigilancia de toda la cartera, lo contamos en Cómo vigilar 40 webs de clientes sin revisarlas a mano.

Preguntas frecuentes