Una web puede estar «activa» y aun así rota: el servidor responde con HTTP 200, pero la página muestra un error de base de datos, una lista de productos vacía o la página por defecto de la empresa de hosting. Una comprobación que solo mira el código de estado da todo eso por bueno. La monitorización de palabras clave cierra ese hueco comprobando también el contenido: un texto que debe estar en la página, como «Añadir al carrito», o un texto que no debe estar, como «Fatal error». Si la comprobación no se cumple, la página cuenta como caída y recibes una alerta.
Cómo puede una web estar activa pero rota
El código de estado lo pone quien responde a la petición, y no siempre es la parte del stack que ha fallado. Todo esto ocurre con un 200, o con un código que tu monitor acepta:
Una página de error de la aplicación. Algunos frameworks, temas y páginas de error personalizadas muestran los errores con un 200 en lugar de un código 5xx.
Una página vacía. Un error fatal de PHP con la visualización de errores desactivada puede devolver un cuerpo vacío, o una caché puede guardar y servir una página vacía.
Datos que faltan. La tienda carga, pero la API de productos que hay detrás ha fallado, así que todas las categorías dicen «No se han encontrado productos».
La web equivocada. Tras un cambio de hosting o de DNS, el dominio acaba en una página por defecto como «Welcome to nginx!» o en una página de aparcamiento.
Una página de mantenimiento que se quedó activada. Un plugin de modo mantenimiento que responde 200 en lugar de 503 parece una web que funciona para una comprobación de estado.
Una página desfigurada o con contenido inyectado. Un atacante sustituye el contenido o añade enlaces de spam, y el servidor sigue respondiendo con normalidad.
Google llama soft 404 a una página que dice «no encontrado» o no muestra nada mientras responde 200, y esas páginas pueden desaparecer de los resultados de búsqueda. Los usuarios, simplemente, ven una web rota.
Cómo funciona la monitorización de palabras clave
En cada comprobación, el monitor solicita la página, lee el HTML que devuelve el servidor y busca en él tu texto. Hay dos modos:
Debe contener: la comprobación falla cuando falta el texto. Úsalo como prueba de que la página funciona, por ejemplo con el texto de un botón o el nombre de un producto.
No debe contener: la comprobación falla cuando aparece el texto. Úsalo para mensajes de error conocidos.
Hay dos detalles importantes. La comprobación lee el código fuente HTML, no la página que ves en el navegador, así que el texto que JavaScript añade después no está ahí. Y la coincidencia suele ser exacta, mayúsculas y minúsculas incluidas. La entrada del glosario sobre la monitorización de palabras clave tiene la definición breve.
Cómo elegir una buena palabra clave
Una buena palabra clave de «debe contener» solo aparece cuando la página funciona y no cambia de un día para otro. Eso descarta precios, fechas, niveles de stock, contadores y cualquier cosa que esté en un test A/B. Mejor un texto que la aplicación genera a partir de sus datos o plantillas, que desaparece cuando la aplicación falla, que un texto de una cabecera estática que una caché podría seguir sirviendo.
PáginaDebe contenerPor qué funcionaPágina de productoAñadir al carritoSolo aparece cuando el producto y el carrito funcionanPágina de categoríaEl nombre de un producto que siempre está en stockFalta cuando los datos de producto no carganPágina de inicio de sesión¿Has olvidado tu contraseña?Forma parte del formulario de acceso real, no de una página de errorBlog o página de noticiasUna línea del pie de página que genera el CMSDesaparece cuando el CMS no puede conectar con su base de datosEndpoint de salud»status»:»ok»Lo escribe la aplicación después de comprobar sus dependencias
Para una API o un endpoint de health check, una comprobación JSON como que $.status sea igual a ok es más precisa que una palabra clave, porque no depende de los espacios ni del orden de los campos.
Comprobaciones de «no debe contener» para mensajes de error
Una comprobación negativa detecta fallos que puedes nombrar de antemano. Textos útiles, según tu stack:
Error establishing a database connection en WordPress. El núcleo lo envía con un 500, pero una página db-error.php personalizada puede que no.
Fatal error o Parse error en webs PHP que muestran los errores.
Welcome to nginx! o el título de la página por defecto de tu hosting, para detectar un dominio que apunta al servidor equivocado.
Palabras de spam que no pintan nada en tu web, como alarma básica ante contenido inyectado.
Cuidado con las páginas en las que el texto puede aparecer de forma legítima. Una entrada de blog sobre errores de base de datos, o un artículo de ayuda que cita un mensaje de error, harían fallar una comprobación de «no debe contener» cada vez. Si tienes dudas, una comprobación positiva sobre un texto que demuestra que la página funciona es la opción más segura, porque detecta fallos en los que no habías pensado.
Prueba la palabra clave antes de confiar en ella
Comprueba lo que el servidor envía realmente, no lo que muestra el navegador. Desde una terminal:
curl -s –compressed https://example.com/product/blue-mug | grep -c «Add to cart»
Un resultado de 0 significa que el monitor tampoco lo encontrará. Los motivos habituales:
El texto lo genera JavaScript. Mira el código fuente de la página (no el inspector) para ver el HTML que devuelve el servidor, y elige un texto que esté ahí.
Entidades HTML. «Términos & Condiciones» en pantalla suele ser Términos & Condiciones en el código fuente, y las comillas tipográficas también pueden estar codificadas. Elige un texto sin caracteres especiales o cópialo del código fuente.
Mayúsculas y espacios. Un botón que se ve en mayúsculas por CSS sigue siendo «Añadir al carrito» en el HTML. Los saltos de línea dentro del texto también rompen una coincidencia exacta.
El monitor ve otra página. Las webs que eligen idioma o moneda según la ubicación, o que muestran un desafío anti-bots a clientes desconocidos, pueden enviar a un monitor un HTML distinto del que ves tú desde tu mesa.
Cuando una palabra clave no basta
El contenido depende de JavaScript. Las aplicaciones de una sola página envían poco HTML. Compruébalas con un flujo en un navegador real, que ejecuta el JavaScript antes de buscar el texto.
El fallo está unos pasos más allá. La página de producto funciona, pero añadir al carrito no. Una comprobación sintética de varios pasos recorre el proceso y comprueba cada paso.
La página es muy grande. Los monitores suelen leer solo la primera parte de una respuesta. Busca un texto cerca del principio o comprueba un endpoint más pequeño.
La página es lenta, no está rota. Eso es una cuestión de tiempo de respuesta; fija un límite de respuesta lenta en su lugar.
La lista de comprobación de qué monitorizar en tu web sugiere qué páginas merecen una comprobación de contenido, y cómo reducir las falsas alertas cubre el resto del ajuste.
Comprobaciones de palabras clave en Uptimecheck
Cada monitor HTTP(S) de la monitorización de uptime de Uptimecheck puede llevar una comprobación de palabra clave junto a los códigos de estado esperados:
Contiene o no contiene: una palabra clave por monitor, con coincidencia exacta, mayúsculas incluidas, en los primeros 2 MB de la respuesta. ¿Necesitas una comprobación positiva y otra negativa en la misma página? Añade un segundo monitor.
Comprobaciones de JSON y cabeceras: hasta 10 por monitor, como que $.status sea igual a ok o una cabecera Content-Type que contenga json, para APIs y endpoints de salud.
Petición de prueba: ve la respuesta y si las comprobaciones se cumplen antes de guardar el monitor.
Confirmado y explicado: una comprobación fallida se repite antes de abrir una incidencia, y la incidencia indica qué estaba mal, por ejemplo que el texto esperado no estaba en la página o que la página llegó vacía, con el inicio de la respuesta.
JavaScript y recorridos: los flujos comprueban texto en cada paso, y los flujos en un navegador real ven el texto que genera JavaScript, con una captura de pantalla del paso que falló.
Las comprobaciones se ejecutan hasta cada minuto desde Estocolmo, Londres y Nueva York, así que una web que cambia de idioma según la ubicación muestra a Uptimecheck la versión que sirve a Suecia, Reino Unido o Estados Unidos; elige una palabra clave que sea igual en todas las versiones, o envía las cabeceras que eligen el idioma. Para configurar una, consulta cómo añadir tu primer monitor y, si un monitor marca caída mientras la web te funciona, por qué un monitor puede marcar caída cuando la web funciona.
Haz que «activa» signifique que funciona. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.