Eine kaputte Seite erkennen, die trotzdem lädt
Uptime-Monitoring stellt meist nur eine Frage: Hat die Seite geantwortet? Bei vielen Problemen, die eine Website Besucher und Bestellungen kosten, lautet die Antwort trotzdem Ja. Das Produktraster im Shop bleibt leer. Das CMS zeigt seine Fehlermeldung mitten im normalen Layout. Ein Wartungsbanner bleibt nach der Wartung stehen. Ein Release bringt die Staging-Konfiguration mit und damit <meta name="robots" content="noindex"> – und die Website verschwindet in den folgenden Wochen aus den Suchergebnissen.
Pingsured liest das HTML und prüft die Elemente, die Sie angeben – mit den CSS-Selektoren, die Sie ohnehin aus den Entwicklertools Ihres Browsers kennen.
Was Sie prüfen sollten
| CSS-Selektor | Operator | Wert |
|---|---|---|
h1 | enthält | Frühjahrskollektion |
.product-card | Anzahl mindestens | 12 |
.price | passt auf | [0-9] |
.maintenance-banner | nicht vorhanden | |
meta[name=robots][content*=noindex] | nicht vorhanden |
Eine Prüfung kann statt des Texts auch ein Attribut lesen: link[rel=canonical] mit dem Attribut href gleich der eigenen Adresse der Seite erkennt ein Canonical-Tag, das woandershin zeigt. Wo eine Seite ausgibt, wann sie zuletzt aktualisiert wurde – etwa time[datetime] oder ein article:modified_time-Meta-Tag –, melden die Alter-Operatoren, wenn das länger her ist, als es sein sollte.
Leerraum im Text wird vor dem Vergleich vereinheitlicht. Ein Zeilenumbruch oder eine geänderte Einrückung im Template löst also keinen Alarm aus. Statt CSS können Sie in jeder Prüfung auch XPath verwenden.
Warum Sie Ihre Seiten mit Pingsured prüfen sollten
- Sie sehen, was Besucher sehen würden. Nicht nur „der Server hat geantwortet“, sondern „die Seite hat ihre Produkte, ihre Preise und keine Fehlermeldung“.
- Suchprobleme bei der nächsten Prüfung, nicht beim nächsten Crawl. Ein
noindexoder ein falsches Canonical-Tag fällt innerhalb des Prüfintervalls auf – nach Minuten statt nach den Wochen, bis es sich als verlorener Traffic zeigt. - Selektoren, die Sie schon kennen, frei kombinierbar mit dem Statuscode, einer Textsuche und Header-Prüfungen; der Ping besteht nur, wenn alle bestehen.
- Jeder Standort für sich. Eine Seite, die ein CDN-Knoten veraltet ausliefert oder die eine Firewall-Regel in einer Region blockiert, scheitert von diesem Standort aus, ohne von den anderen verdeckt zu werden.
- Leicht aus Ihrer Webanalyse herauszuhalten. Jede Anfrage trägt den User-Agent
Pingsured/1.0, und unsere Prüfungen kommen von veröffentlichten Adressen.
Grenzen, die Sie kennen sollten
- Geprüft wird das HTML, das Ihr Server ausliefert; JavaScript wird nicht ausgeführt. Inhalte, die eine Single-Page-Anwendung erst im Browser rendert, sind dort nicht zu finden – prüfen Sie stattdessen die API, aus der sie ihre Daten lädt.
- Gelesen wird nur das erste MB der Seite. Längeres HTML wird bis zu dieser Grenze geprüft; ein Element weit am Ende einer sehr großen Seite wird also unter Umständen nicht gefunden.
- Geprüft wird mit
GEToderHEAD, mit eigenen Request-Headern und HTTP-Basic-Authentifizierung. Seiten hinter einem Login-Formular lassen sich nicht prüfen.