Mi web carga, pero algunas páginas fallan: qué revisar

La portada abre, el monitor dice que todo está bien y, aun así, un cliente escribe porque no puede pagar, iniciar sesión o enviar el formulario. Que la web cargue pero no funcione es uno de los problemas más frustrantes, porque las comprobaciones más simples no lo ven: miran la portada, la portada responde y nadie se entera.

Aquí va por qué pasa, cómo encontrar la parte rota y qué vigilar para enterarte antes que tus clientes.

Por qué una web puede fallar a medias

Una web no es una sola página. Detrás de cada sección hay piezas distintas, y cualquiera puede fallar sola:

• Una plantilla o un plugin roto en un tipo de página concreto: la ficha de producto, el blog o el buscador.
• La base de datos fallando a medias: las páginas en caché se ven bien y las que necesitan consultar datos dan error.
• Un servicio externo caído: la pasarela de pago, el mapa, el sistema de reservas o la API de la que depende una sección.
• Una caché que esconde la caída: la CDN sigue entregando la portada guardada mientras el servidor de detrás no responde.
• Redirecciones mal puestas después de una migración: direcciones viejas que llevan a un 404 o a un bucle.
• JavaScript que falla en el navegador: el HTML llega bien, pero el botón o el formulario no hacen nada.
• Formularios que se envían pero no llegan, porque el servidor no puede mandar correo.

Cómo diagnosticarlo paso a paso

1. Reproduce el fallo con la dirección exacta. Pide al cliente el enlace y pruébalo en una ventana privada, sin sesión ni caché del navegador.
2. Mira el código de respuesta de esa página. Un 500 o un 503 apuntan al servidor; un 404, a una dirección o una redirección; un 200 con la página rota, a la plantilla o al JavaScript.
3. Sigue las redirecciones con la herramienta de redirecciones para ver a dónde lleva de verdad cada salto.
4. Revisa si viene de la caché. Las cabeceras de la CDN suelen decir si la respuesta salió de su caché. Si la portada sale de la caché y lo demás falla, el problema está en el servidor de origen.
5. Abre la consola del navegador (F12) y busca errores en rojo. Si hay errores de JavaScript, el HTML puede estar bien y el fallo estar en el navegador.
6. Lee el registro de errores del servidor a la hora en que el cliente lo vio.
7. Repasa lo último que cambió: una actualización, un plugin nuevo, una migración o un cambio en un servicio externo.

Qué conviene vigilar

Vigilar solo la portada es la razón por la que estos fallos pasan desapercibidos. Algunas ideas:

• Varias direcciones, no una. Las páginas que dan dinero o que más se usan: una ficha de producto, la página de contacto, el área de reservas.
• Un texto que solo aparezca cuando la página está bien. Un monitor de palabra clave nota que falta el botón o el nombre del producto aunque la página responda 200.
• El código de respuesta esperado. Si una página debe devolver 200, cualquier otra cosa cuenta como fallo.
• Las API de las que dependes, con un monitor de API que compruebe el método, las cabeceras y el código esperado.
• Al menos una dirección que no salga de la caché, para que una caída del servidor no quede escondida detrás de la CDN.

Lo que un monitor externo no ve

Un monitor como MonitoraWeb mira cada dirección desde fuera, desde un solo punto, sin navegador:

• No ejecuta JavaScript, así que no ve lo que dibuja un script después de cargar.
• No inicia sesión, no rellena formularios y no hace compras.
• No sabe si un correo del formulario llegó.

Para eso hace falta probar los formularios y los pagos de vez en cuando, o pedirle a alguien del equipo que recorra la web después de cada cambio importante. Lo que sí hace, y cómo, lo explicamos en monitoreo de disponibilidad web.

Preguntas frecuentes

¿Por qué el monitor dice que mi web está bien si una página falla?

Porque probablemente solo vigila la portada. Añade monitores para las páginas importantes y un texto clave en cada una.

¿Cómo sé si el problema es de la caché?

Mira las cabeceras de la respuesta: las CDN suelen indicar si salió de su caché. Si la portada sale de la caché y lo demás falla, el origen está caído.

¿Un monitor externo detecta errores de JavaScript?

No. Ve el HTML que entrega el servidor, no lo que el navegador hace después. Para eso hay que revisar la consola del navegador.

¿Qué páginas debería vigilar además de la portada?

Las que generan ingresos o contactos: una ficha de producto, el contacto, las reservas, y las API de las que dependen.

¿Puede vigilar que un formulario funcione?

Puede vigilar que la página del formulario cargue y muestre el formulario, pero no lo envía ni comprueba que el correo llegue.