Un sitio WordPress es un programa, una base de datos y un montón de plugins, a menudo en un alojamiento compartido. Cuando falla una de esas piezas, el sitio falla a su manera. La página puede quedarse en blanco, mostrar un mensaje corto o cargar tan despacio que los visitantes se marchan.
La monitorización externa no puede ver nada de eso por dentro. Lo que sí puede hacer es pedir, con un calendario, las mismas direcciones que pediría un visitante y avisarte cuando la respuesta es incorrecta. Esta guía muestra qué direcciones pedir y qué señales configurar.
Los fallos que conviene detectar
La documentación de WordPress describe los fallos que los propietarios de sitios encuentran con más frecuencia. Cada uno se ve distinto desde fuera:
| Qué ocurrió | Qué ve un visitante | Qué puede leer una comprobación externa |
|---|---|---|
| Un plugin o un tema falla con un error de PHP | Una página en blanco (la «pantalla en blanco») o un mensaje que dice que el sitio tiene un error crítico | Normalmente un error del servidor, 500. A veces una página en blanco que aun así responde 200 |
| WordPress no puede llegar a su base de datos | «Error establishing a database connection» | Un error del servidor, o una página que contiene esa frase |
| Se interrumpe una actualización | Un aviso breve de mantenimiento que no desaparece | Una respuesta 503 |
| El alojamiento está sobrecargado | Una página que carga despacio y luego un error o un tiempo de espera agotado | Tiempos de respuesta lentos y luego un tiempo de espera agotado o una respuesta 5xx |
| El certificado o el dominio vencen | Una advertencia de seguridad del navegador, o ningún sitio | Un aviso de SSL, de dominio o de DNS |
Ninguno de estos casos es raro. La mayoría empieza justo después de un cambio, así que tienden a aparecer cuando nadie está mirando.
Qué direcciones monitorizar
Cada dirección exacta cuenta como un sitio web, así que elige con cuidado.
- La página de inicio. La primera dirección, la más evidente. Un plugin de caché puede servirla desde una copia guardada, de modo que puede parecer sana durante un tiempo después de que el resto del sitio haya fallado.
- La página de acceso, wp-login.php. Es pública, responde sin contraseña y normalmente queda fuera de la caché. PHP y la base de datos tienen que generarla en cada solicitud, por lo que tiende a fallar cuando ellos fallan.
- Una página que importa al negocio. Una página de contacto, una de reservas, una lista de precios.
- Cualquier otro nombre de host. Una tienda o un área de socios en un subdominio, o una copia de pruebas, es una dirección aparte con sus propios fallos.
No monitorices el área de administración. Una comprobación no inicia sesión, así que solo vería una redirección a la página de acceso.
Detectar una página de error que responde 200
Un error del servidor es fácil: cualquier respuesta final fuera del rango de 200 a 399 cuenta como fallo, y se registra el motivo.
El caso difícil es una página que responde 200 pero está mal. Una caché puede servir una página en blanco o rota, o un tema puede imprimir un mensaje de error dentro de una respuesta por lo demás normal. Dos alertas de texto cubren esto:
- Fallar cuando la página contiene una frase. Usa una frase del propio fallo, como «Error establishing a database connection».
- Fallar cuando a la página le falta una frase. Usa una frase que siempre está en una página sana, como parte del texto del pie de página o el nombre de un botón.
Elige una frase corta, exacta y que no cambien los editores ni los plugins de traducción. El texto tiene que coincidir exactamente.
Atascado en modo mantenimiento
Cuando WordPress se actualiza, muestra un aviso breve de mantenimiento y responde con un 503 durante un momento. Si la actualización se interrumpe, el aviso puede quedarse durante horas, y los visitantes no ven nada más.
Para una comprobación externa, un 503 es un fallo, así que este caso no necesita ningún ajuste especial. Lo que importa es que se avise a alguien. Como una comprobación fallida se repite antes de abrir un incidente, una actualización normal y corta no dispara ninguna alarma, y una que se atasca, sí.
Primero lento, después caído
Un alojamiento saturado rara vez pasa de sano a muerto de golpe. Las páginas tardan más y luego algunas agotan el tiempo de espera. Una comprobación espera hasta 15 segundos antes de considerar una respuesta un fallo y registra el tiempo de respuesta cada vez, así que un gráfico de historial muestra un sitio que se vuelve más lento antes de dejar de responder.
Lo que la monitorización externa no puede hacer
- No sabe qué plugins o temas están instalados, ni cuáles están desactualizados.
- No encuentra brechas de seguridad, malware ni una página hackeada que aun así responde con normalidad.
- No mira detrás de un inicio de sesión, un formulario o un pago.
- No repara nada. Te dice que hay un problema, y cuándo empezó y terminó.
Lista de comprobación
- ¿Está monitorizada la página de inicio, y también la de acceso?
- ¿Hay una alerta de texto sobre una frase de una página sana?
- ¿Llegan las alertas a alguien que pueda actuar, por correo o Telegram?
- ¿Se vigilan las fechas de vencimiento del certificado SSL y del dominio?
- Si te ocupas de sitios de otras personas, ¿está cada uno etiquetado con su cliente?