Een website kan “up” zijn en toch kapot: de server antwoordt met HTTP 200, maar de pagina toont een databasefout, een lege productlijst of de standaardpagina van een hostingbedrijf. Een check die alleen naar de statuscode kijkt, keurt dat allemaal goed. Keyword monitoring dicht dat gat door ook de inhoud te controleren: tekst die op de pagina moet staan, zoals “Add to cart”, of tekst die er juist niet mag staan, zoals “Fatal error”. Klopt de check niet, dan telt de pagina als down en krijg je een melding.
Hoe een site up kan zijn en toch kapot
De statuscode wordt bepaald door wat het verzoek beantwoordt, en dat is niet altijd het deel van de stack dat faalde. Dit gebeurt allemaal met een 200, of met een code die je monitor accepteert:
Een foutpagina van de applicatie. Sommige frameworks, thema’s en eigen foutpagina’s tonen fouten met een 200 in plaats van een 5xx-code.
Een lege pagina. Een fatale PHP-fout met uitgeschakelde foutweergave kan een lege body opleveren, of een cache kan een lege pagina opslaan en serveren.
Ontbrekende data. De webshop laadt, maar de product-API erachter faalde, dus in elke categorie staat “Geen producten gevonden”.
De verkeerde site. Na een wijziging bij de hosting of in de DNS komt het domein uit op een standaardpagina zoals “Welcome to nginx!” of een parkeerpagina.
Een vergeten onderhoudspagina. Een plugin voor onderhoudsmodus die 200 teruggeeft in plaats van 503, ziet er voor een statuscheck uit als een werkende site.
Een bekladde of geïnjecteerde pagina. Een aanvaller vervangt inhoud of voegt spamlinks toe, en de server antwoordt gewoon normaal.
Google noemt een pagina die “niet gevonden” meldt of niets toont terwijl ze 200 teruggeeft een soft 404, en zulke pagina’s kunnen uit de zoekresultaten verdwijnen. Gebruikers zien gewoon een kapotte site.
Hoe keyword monitoring werkt
Bij elke check vraagt de monitor de pagina op, leest de HTML die de server teruggeeft en zoekt daarin naar je tekst. Er zijn twee modi:
Moet bevatten: de check faalt als de tekst ontbreekt. Gebruik dit als bewijs dat de pagina werkt, zoals het label van een knop of een productnaam.
Mag niet bevatten: de check faalt als de tekst verschijnt. Gebruik dit voor bekende foutmeldingen.
Twee details zijn belangrijk. De check leest de HTML-bron, niet de pagina die je in een browser ziet, dus tekst die later door JavaScript wordt toegevoegd staat er niet in. En de match is meestal exact, inclusief hoofdletters en kleine letters. In de woordenlijst over keyword monitoring vind je de korte definitie.
Zo kies je een goed keyword
Een goed “moet bevatten”-keyword verschijnt alleen als de pagina werkt en blijft van dag tot dag hetzelfde. Prijzen, datums, voorraadniveaus, tellers en alles wat in een A/B-test zit vallen dus af. Kies liever tekst die de applicatie uit haar data of templates opbouwt, zodat die verdwijnt als de applicatie faalt, dan tekst in een statische header die een cache nog zou kunnen serveren.
PaginaMoet bevattenWaarom het werktProductpaginaAdd to cartWordt alleen getoond als het product en de winkelwagen werkenCategoriepaginaEen productnaam die altijd op voorraad isOntbreekt als de productdata niet laadtInlogpaginaWachtwoord vergeten?Hoort bij het echte inlogformulier, niet bij een foutpaginaBlog- of nieuwspaginaEen regel uit de footer die het CMS opbouwtVerdwijnt als het CMS zijn database niet kan bereikenHealth-endpoint”status”:”ok”Geschreven door de applicatie nadat ze haar afhankelijkheden heeft gecontroleerd
Voor een API of een health check endpoint is een JSON-check zoals $.status is gelijk aan ok preciezer dan een keyword, omdat die niet afhangt van spaties of de volgorde van velden.
“Mag niet bevatten”-checks voor foutmeldingen
Een negatieve check vangt storingen op die je vooraf kunt benoemen. Bruikbare tekenreeksen, afhankelijk van je stack:
Error establishing a database connection bij WordPress. De core stuurt deze melding met een 500, maar een eigen db-error.php-pagina misschien niet.
Fatal error of Parse error bij PHP-sites die fouten tonen.
Welcome to nginx! of de titel van de standaardpagina van je host, om een domein te betrappen dat naar de verkeerde server wijst.
Spamwoorden die niets op je site te zoeken hebben, als eenvoudig alarmdraadje voor geïnjecteerde inhoud.
Let op pagina’s waar de tekenreeks legitiem kan voorkomen. Een blogpost over databasefouten, of een helpartikel dat een foutmelding citeert, zou elke keer een “mag niet bevatten”-check laten falen. Twijfel je, dan is een positieve check op tekst die bewijst dat de pagina werkt de veiligere keuze, omdat die ook storingen opvangt waar je niet aan had gedacht.
Test het keyword voordat je erop vertrouwt
Controleer wat de server echt stuurt, niet wat de browser toont. Vanuit een terminal:
curl -s –compressed https://example.com/product/blue-mug | grep -c “Add to cart”
Een telling van 0 betekent dat de monitor de tekst ook niet vindt. De gebruikelijke oorzaken:
JavaScript bouwt de tekst op. Bekijk de paginabron (niet de inspector) om de HTML te zien die de server teruggeeft, en kies tekst die daarin staat.
HTML-entiteiten. “Terms & Conditions” op het scherm is in de bron vaak Terms & Conditions, en gekrulde aanhalingstekens kunnen ook gecodeerd zijn. Kies tekst zonder speciale tekens, of kopieer hem uit de bron.
Hoofdletters en spaties. Een knop die met CSS in hoofdletters wordt getoond, is in de HTML nog steeds “Add to cart”. Regeleinden binnen de tekst breken ook een exacte match.
De monitor ziet een andere pagina. Sites die taal of valuta kiezen op basis van locatie, of onbekende clients een botcontrole tonen, kunnen een monitor andere HTML sturen dan jij achter je bureau krijgt.
Wanneer een keyword niet genoeg is
De inhoud hangt af van JavaScript. Single-page apps sturen weinig HTML. Controleer ze met een flow in een echte browser, die het JavaScript uitvoert voordat hij naar de tekst zoekt.
De fout zit een paar stappen verder. De productpagina werkt, maar toevoegen aan de winkelwagen niet. Een synthetische check in meerdere stappen doorloopt het hele traject en controleert elke stap.
De pagina is erg groot. Monitors lezen meestal alleen het eerste deel van een response. Controleer op tekst bovenaan, of controleer een kleiner endpoint.
De pagina is traag, niet kapot. Dat is een kwestie van responstijd; stel in plaats daarvan een limiet voor trage responses in.
De checklist van wat je op je website moet monitoren laat zien welke pagina’s een inhoudscheck verdienen, en zo verminder je valse meldingen behandelt de rest van het fijnafstemmen.
Keywordchecks in Uptimecheck
Elke HTTP(S)-monitor in de uptime monitoring van Uptimecheck kan naast de verwachte statuscodes een keywordcheck hebben:
Bevat of bevat niet: één keyword per monitor, exact gematcht, inclusief hoofdletters, in de eerste 2 MB van de response. Wil je op dezelfde pagina zowel een positieve als een negatieve check? Voeg dan een tweede monitor toe.
JSON- en headerchecks: tot 10 per monitor, zoals $.status is gelijk aan ok of een Content-Type-header die json bevat, voor API’s en health-endpoints.
Testverzoek: bekijk de response en of de checks slagen voordat je de monitor opslaat.
Bevestigd en uitgelegd: een mislukte check wordt herhaald voordat er een incident wordt geopend, en het incident vertelt wat er mis was, bijvoorbeeld dat de verwachte tekst niet op de pagina stond of dat de pagina leeg terugkwam, met het begin van de response.
JavaScript en trajecten: flows controleren tekst bij elke stap, en flows in een echte browser zien tekst die JavaScript opbouwt, met een screenshot van de stap die faalde.
Checks draaien tot elke minuut vanuit Stockholm, Londen en New York, dus een site die van taal wisselt op basis van locatie toont Uptimecheck de versie die hij aan Zweden, het Verenigd Koninkrijk of de VS serveert; kies een keyword dat in elke versie hetzelfde is, of stuur de headers mee die een taal kiezen. Lees hoe je je eerste monitor toevoegt om er een in te stellen, en als een monitor down meldt terwijl de site bij jou werkt: waarom een monitor down kan zijn terwijl de site werkt.
Laat “up” betekenen dat het werkt. Probeer Uptimecheck 14 dagen gratis, zonder creditcard.