Un sito può essere “online” e non funzionare lo stesso: il server risponde con HTTP 200, ma la pagina mostra un errore del database, un elenco prodotti vuoto o la pagina predefinita del provider di hosting. Un controllo che guarda solo il codice di stato li considera tutti superati. Il monitoraggio delle parole chiave chiude questa falla controllando anche il contenuto: un testo che deve esserci nella pagina, come “Aggiungi al carrello”, o un testo che non deve esserci, come “Fatal error”. Se la verifica non regge, la pagina risulta down e ricevi un avviso.
Come un sito può essere online ma non funzionare
Il codice di stato lo imposta chi risponde alla richiesta, e non sempre è la parte dello stack che si è guastata. Tutti questi casi si verificano con un 200, o con un codice che il tuo monitor accetta:
Una pagina di errore dell’applicazione. Alcuni framework, temi e pagine di errore personalizzate mostrano gli errori con un 200 invece che con un codice 5xx.
Una pagina vuota. Un fatal error PHP con la visualizzazione degli errori disattivata può produrre un body vuoto, oppure una cache può salvare e servire una pagina vuota.
Dati mancanti. Lo shop si carica, ma l’API dei prodotti alle sue spalle non ha risposto, così ogni categoria dice “Nessun prodotto trovato”.
Il sito sbagliato. Dopo un cambio di hosting o di DNS, il dominio finisce su una pagina predefinita come “Welcome to nginx!” o su una pagina di parcheggio.
Una pagina di manutenzione rimasta attiva. Un plugin per la modalità manutenzione che risponde 200 invece di 503 sembra un sito funzionante a un controllo del codice di stato.
Una pagina defacciata o con contenuti iniettati. Un attaccante sostituisce i contenuti o aggiunge link di spam, e il server continua a rispondere normalmente.
Google chiama soft 404 una pagina che dice “non trovato” o non mostra nulla pur rispondendo 200, e queste pagine possono sparire dai risultati di ricerca. Gli utenti vedono semplicemente un sito rotto.
Come funziona il monitoraggio delle parole chiave
A ogni controllo, il monitor richiede la pagina, legge l’HTML restituito dal server e ci cerca il tuo testo. Le modalità sono due:
Deve contenere: il controllo fallisce quando il testo manca. Usala come prova che la pagina funziona, per esempio con l’etichetta di un pulsante o il nome di un prodotto.
Non deve contenere: il controllo fallisce quando il testo compare. Usala per i messaggi di errore noti.
Due dettagli contano. Il controllo legge il sorgente HTML, non la pagina che vedi nel browser, quindi il testo aggiunto in seguito da JavaScript non c’è. E la corrispondenza di solito è esatta, maiuscole e minuscole comprese. La voce del glossario sul monitoraggio delle parole chiave riporta la definizione breve.
Come scegliere una buona parola chiave
Una buona parola chiave “deve contenere” compare solo quando la pagina funziona e resta uguale da un giorno all’altro. Questo esclude prezzi, date, disponibilità di magazzino, contatori e tutto ciò che è in un A/B test. Preferisci un testo che l’applicazione genera dai suoi dati o template, così sparisce quando l’applicazione si guasta, piuttosto che un testo in un header statico che una cache potrebbe continuare a servire.
PaginaDeve contenerePerché funzionaPagina prodottoAggiungi al carrelloViene mostrato solo quando il prodotto e il carrello funzionanoPagina di categoriaIl nome di un prodotto sempre disponibileManca quando i dati dei prodotti non si caricanoPagina di loginPassword dimenticata?Fa parte del vero modulo di login, non di una pagina di erroreBlog o pagina di notizieUna riga del footer generata dal CMSSparisce quando il CMS non riesce a raggiungere il suo databaseEndpoint di health check”status”:”ok”Lo scrive l’applicazione dopo aver controllato le sue dipendenze
Per un’API o un endpoint di health check, un controllo JSON come $.status uguale a ok è più preciso di una parola chiave, perché non dipende dagli spazi né dall’ordine dei campi.
Controlli “non deve contenere” per i messaggi di errore
Un controllo negativo intercetta i guasti che sai indicare in anticipo. Stringhe utili, a seconda del tuo stack:
Error establishing a database connection su WordPress. Il core lo invia con un 500, ma una pagina db-error.php personalizzata potrebbe non farlo.
Fatal error o Parse error sui siti PHP che mostrano gli errori.
Welcome to nginx! o il titolo della pagina predefinita del tuo hosting, per accorgerti di un dominio che punta al server sbagliato.
Parole di spam che sul tuo sito non hanno nulla a che fare, come semplice campanello d’allarme per i contenuti iniettati.
Fai attenzione alle pagine in cui la stringa può comparire legittimamente. Un articolo del blog sugli errori del database, o un articolo di supporto che cita un messaggio di errore, farebbe fallire ogni volta un controllo “non deve contenere”. Nel dubbio, un controllo positivo su un testo che dimostra che la pagina funziona è la scelta più sicura, perché intercetta anche i guasti a cui non avevi pensato.
Testa la parola chiave prima di affidarti a lei
Verifica ciò che il server invia davvero, non ciò che mostra il browser. Da un terminale:
curl -s –compressed https://example.com/product/blue-mug | grep -c “Add to cart”
Un conteggio di 0 significa che nemmeno il monitor la troverà. I motivi più comuni:
Il testo lo genera JavaScript. Visualizza il sorgente della pagina (non l’inspector) per vedere l’HTML restituito dal server, e scegli un testo che sia lì.
Entità HTML. “Terms & Conditions” sullo schermo è spesso Terms & Conditions nel sorgente, e anche le virgolette tipografiche possono essere codificate. Scegli un testo senza caratteri speciali, oppure copialo dal sorgente.
Maiuscole e spazi. Un pulsante reso in maiuscolo con il CSS resta “Aggiungi al carrello” nell’HTML. Anche gli a capo all’interno del testo impediscono una corrispondenza esatta.
Il monitor vede una pagina diversa. I siti che scelgono lingua o valuta in base alla posizione, o che mostrano una verifica anti-bot ai client sconosciuti, possono inviare a un monitor un HTML diverso da quello che ricevi tu alla scrivania.
Quando una parola chiave non basta
Il contenuto dipende da JavaScript. Le single-page app inviano poco HTML. Controllale con un flusso in un browser reale, che esegue il JavaScript prima di cercare il testo.
Il guasto è qualche passaggio più avanti. La pagina prodotto funziona, ma l’aggiunta al carrello no. Un controllo sintetico in più passaggi percorre l’intero percorso e verifica ogni passaggio.
La pagina è molto grande. I monitor di solito leggono solo la prima parte di una risposta. Cerca un testo vicino all’inizio, oppure controlla un endpoint più piccolo.
La pagina è lenta, non rotta. È una questione di tempo di risposta: imposta invece una soglia per le risposte lente.
La checklist di cosa monitorare sul tuo sito suggerisce quali pagine meritano un controllo del contenuto, e come ridurre i falsi allarmi copre il resto della messa a punto.
I controlli delle parole chiave in Uptimecheck
Ogni monitor HTTP(S) del monitoraggio uptime di Uptimecheck può includere un controllo della parola chiave accanto ai codici di stato attesi:
Contiene o non contiene: una parola chiave per monitor, con corrispondenza esatta, maiuscole comprese, nei primi 2 MB della risposta. Ti servono sia un controllo positivo sia uno negativo sulla stessa pagina? Aggiungi un secondo monitor.
Controlli JSON e degli header: fino a 10 per monitor, come $.status uguale a ok o un header Content-Type che contiene json, per API ed endpoint di health check.
Richiesta di prova: vedi la risposta e se i controlli passano prima di salvare il monitor.
Confermato e spiegato: un controllo fallito viene ripetuto prima che si apra un incidente, e l’incidente dice cosa non andava, per esempio che il testo atteso non era nella pagina o che la pagina è tornata vuota, con l’inizio della risposta.
JavaScript e percorsi: i flussi controllano il testo a ogni passaggio, e i flussi in un browser reale vedono il testo generato da JavaScript, con uno screenshot del passaggio fallito.
I controlli girano anche ogni minuto da Stoccolma, Londra e New York, quindi un sito che cambia lingua in base alla posizione mostra a Uptimecheck la versione che serve in Svezia, nel Regno Unito o negli Stati Uniti: scegli una parola chiave uguale in tutte le versioni, oppure invia gli header che scelgono la lingua. Per configurarne uno, leggi come aggiungere il tuo primo monitor, e se un monitor segnala down mentre per te il sito funziona, perché un monitor può risultare down quando il sito funziona.
Fai in modo che “online” significhi funzionante. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.