{"id":22919,"date":"2026-08-30T09:38:48","date_gmt":"2026-08-30T07:38:48","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22919"},"modified":"2026-08-30T09:38:49","modified_gmt":"2026-08-30T07:38:49","password":"","slug":"website-monitoring-erreichbarkeit","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/it\/hilfe\/seo-monitoring\/website-monitoring-erreichbarkeit\/","title":{"rendered":"Monitoraggio di siti web: monitorare la disponibilit\u00e0 e le interruzioni"},"content":{"rendered":"

Un sito web pu\u00f2 guastarsi in qualsiasi momento, anche se funzionava perfettamente pochi minuti prima. Problemi al server, aggiornamenti difettosi, interruzioni del DNS, certificati scaduti o problemi con un'applicazione possono far s\u00ec che i visitatori improvvisamente non riescano pi\u00f9 a raggiungere un sito web.<\/p>\n\n\n\n

Chi visita il proprio sito web solo occasionalmente potrebbe accorgersi di tali interruzioni solo ore dopo o tramite una segnalazione da parte dei clienti.<\/p>\n\n\n\n

Il monitoraggio dei siti web automatizza questo controllo. Un servizio di monitoraggio esterno visita regolarmente un sito web e verifica se \u00e8 raggiungibile e come risponde l'endpoint monitorato.<\/p>\n\n\n\n

In questo articolo spieghiamo come funziona il monitoraggio dei siti web, quali metodi di controllo esistono, come distinguere i falsi allarmi dai malfunzionamenti reali e quali limiti possiede un semplice controllo di uptime.<\/p>\n\n\n\n

\n

Breve spiegazione:<\/strong> Il monitoraggio dei siti web controlla automaticamente il tuo sito a intervalli regolari. Se viene rilevato un errore definito, il monitoraggio pu\u00f2 attivare un allarme, permettendoti di accorgerti di un guasto senza dover controllare costantemente il sito web in prima persona.<\/p>\n<\/blockquote>\n\n\n\n

Cos'\u00e8 il monitoraggio di un sito web?<\/h2>\n\n\n\n

Nel monitoraggio dei siti web, un sito web o un determinato servizio viene controllato regolarmente da un sistema esterno.<\/p>\n\n\n\n

Un procedimento semplice appare ad esempio cos\u00ec:<\/p>\n\n\n\n

Sistema di monitoraggio\n        \u2193\nvisita il sito web\n        \u2193\nil server risponde\n        \u2193\nla risposta viene valutata\n        \u2193\ntutto a posto?\n   \u2199              \u2198\n  s\u00ec               no\n  \u2193                \u2193\nprossimo      nuovo controllo \/\ncontrollo        allarme<\/code><\/pre>\n\n\n\n
Questi test vengono eseguiti automaticamente e possono essere effettuati 24 ore su 24.<\/p>\n\n\n\n
Perch\u00e9 \u00e8 utile il monitoraggio esterno?<\/h2>\n\n\n\n
Un sito web non pu\u00f2 stabilire autonomamente in modo affidabile di non essere pi\u00f9 raggiungibile dall'esterno.<\/p>\n\n\n\n
Se, ad esempio, l'intero server, la rete o la risoluzione DNS si guastano, anche un sistema di monitoraggio in esecuzione all'interno della stessa infrastruttura potrebbe esserne influenzato.<\/p>\n\n\n\n
Un monitoraggio esterno, invece, osserva il sito web dalla prospettiva di un'infrastruttura esterna al sistema monitorato.<\/p>\n\n\n\n
\n
Consiglio pratico:<\/strong> Per il monitoraggio della raggiungibilit\u00e0 pubblica, dovrebbe essere eseguito almeno un controllo dall'esterno dell'infrastruttura di hosting effettiva.<\/p>\n<\/blockquote>\n\n\n\n
Cosa pu\u00f2 monitorare il monitoraggio di un sito web?<\/h2>\n\n\n\n
Il termine monitoraggio di siti web comprende diversi tipi di controlli.<\/p>\n\n\n\n
A seconda del sistema di monitoraggio, \u00e8 possibile ad esempio monitorare:<\/p>\n\n\n\n
Accessibilit\u00e0 HTTP e HTTPS\n\nCodice di stato HTTP\n\nTempo di risposta\n\ndeterminato contenuto della pagina\n\nCertificato SSL\/TLS\n\nRisoluzione DNS\n\nPorta TCP\n\nPing\n\nsingoli endpoint API\n\nflussi di utenti pi\u00f9 complessi<\/code><\/pre>\n\n\n\n
Non tutti i monitor devono svolgere tutte queste attivit\u00e0. Quali controlli siano utili dipende da ci\u00f2 che desideri effettivamente monitorare.<\/p>\n\n\n\n
Il classico monitor HTTP o HTTPS<\/h2>\n\n\n\n
Per un sito web normale, un monitor HTTP o HTTPS \u00e8 solitamente il controllo pi\u00f9 importante.<\/p>\n\n\n\n
Il monitoraggio richiama ad esempio la seguente URL:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
e valuta la risposta.<\/p>\n\n\n\n
Una richiesta andata a buon fine pu\u00f2 essere ad esempio risposta con il seguente stato HTTP:<\/p>\n\n\n\n
200 OK<\/code><\/p>\n\n\n\n
Se il sito Web risponde invece con un errore del server, il monitoraggio pu\u00f2 valutare il controllo come fallito.<\/p>\n\n\n\n
Spieghiamo le risposte HTTP pi\u00f9 importanti alla pagina Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500<\/a>.<\/p>\n\n\n\n
Un codice di stato HTTP di successo non significa automaticamente che tutto funzioni<\/h2>\n\n\n\n
Un sito web pu\u00f2 200 OK<\/code> rispondere e ciononostante avere un problema funzionale.<\/p>\n\n\n\n
Ad esempio, la homepage potrebbe essere servita, mentre:<\/p>\n\n\n\n
un modulo di contatto non funziona\n\nil carrello ha un errore\n\nuna funzione del database si interrompe\n\nun login non funziona\n\nmancano immagini o JavaScript\n\nun servizio esterno non risponde<\/code><\/pre>\n\n\n\n
Un semplice monitor HTTP conferma quindi inizialmente solo che l'endpoint HTTP monitorato risponde secondo i criteri definiti.<\/p>\n\n\n\n
Controllo del contenuto anzich\u00e9 solo del codice di stato<\/h2>\n\n\n\n
Un monitoraggio avanzato pu\u00f2 inoltre verificare se una determinata stringa \u00e8 presente nel contenuto restituito.<\/p>\n\n\n\n
Supponendo che su una pagina dovrebbe essere sempre presente il seguente titolo:<\/p>\n\n\n\n
Benvenuti su Example<\/code><\/p>\n\n\n\n
Il monitor non potrebbe solo 200 OK<\/code> ma verificare inoltre se questo testo \u00e8 effettivamente incluso nella risposta.<\/p>\n\n\n\n
Ci\u00f2 consente di rilevare determinati errori in cui il server web risponde tecnicamente con successo, ma non eroga il contenuto atteso.<\/p>\n\n\n\n
Cos'\u00e8 un monitor di parole chiave o di contenuti?<\/h2>\n\n\n\n
Durante un controllo dei contenuti viene cercato un testo o un pattern definito.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
URL raggiungibile?\n      \u2193\n200 OK?\n      \u2193\ntesto atteso presente?\n      \u2193\ns\u00ec \u2192 verifica riuscita\n\nno \u2192 possibile guasto<\/code><\/pre>\n\n\n\n
La stringa selezionata dovrebbe essere il pi\u00f9 possibile stabile.<\/p>\n\n\n\n
Un prezzo in continua evoluzione, una data o un nome utente dinamico, ad esempio, sarebbero spesso inadatti.<\/p>\n\n\n\n
Monitoraggio dei reindirizzamenti<\/h2>\n\n\n\n
Molti siti web reindirizzano automaticamente determinate varianti di URL.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
http:\/\/example.com\/\n\n        \u2193 301\n\nhttps:\/\/example.com\/<\/code><\/pre>\n\n\n\n
Un sistema di monitoraggio pu\u00f2 tracciare automaticamente i reindirizzamenti a seconda della configurazione.<\/p>\n\n\n\n
\u00c8 comunque utile sapere quale URL stai effettivamente monitorando e quale risposta ti aspetti.<\/p>\n\n\n\n
Un ciclo di reindirizzamento accidentale o una destinazione di reindirizzamento errata potrebbero altrimenti causare un'interruzione.<\/p>\n\n\n\n
Maggiori informazioni sulle reindirizzamenti permanenti sono disponibili alla voce Configurazione del reindirizzamento 301: reindirizzare gli URL in modo permanente<\/a>.<\/p>\n\n\n\n
Quale URL dovrebbe essere monitorato?<\/h2>\n\n\n\n
Per un semplice sito aziendale, la home page \u00e8 un punto di partenza ovvio.<\/p>\n\n\n\n
Esempio:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
Tuttavia, per applicazioni pi\u00f9 importanti, la sola pagina iniziale potrebbe non essere sufficiente.<\/p>\n\n\n\n
Inoltre, \u00e8 possibile monitorare gli endpoint centrali, ad esempio:<\/p>\n\n\n\n
Pagina iniziale\n\nimportante pagina di destinazione\n\nNegozio\n\nAccedi\n\nEndpoint API\n\nEndpoint di stato o di controllo dello stato<\/code><\/pre>\n\n\n\n
Tuttavia, non dovresti monitorare ciecamente ogni singola sottopagina. Quelli che contano sono gli endpoint la cui interruzione indica un'interruzione rilevante.<\/p>\n\n\n\n
Sito Web raggiungibile, ma WordPress \u00e8 danneggiato<\/h2>\n\n\n\n
Un web server pu\u00f2 fondamentalmente essere raggiungibile, mentre WordPress stesso causa un errore.<\/p>\n\n\n\n
Ad esempio, una richiesta con:<\/p>\n\n\n\n
Errore interno del server<\/code><\/p>\n\n\n\n
o:<\/p>\n\n\n\n
503 Servizio non disponibile<\/code><\/p>\n\n\n\n
essere risposto.<\/p>\n\n\n\n
Un monitor HTTP pu\u00f2 rilevare un tale errore, sebbene la rete e il server web siano fondamentalmente ancora raggiungibili.<\/p>\n\n\n\n
Perch\u00e9 un solo ping non basta<\/h2>\n\n\n\n
Un test di ping non verifica se il tuo sito web funziona correttamente.<\/p>\n\n\n\n
Usa ICMP e risponde a una domanda diversa rispetto a una chiamata HTTP o HTTPS.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
Ping\n\u2192 un host risponde a ICMP?\n\nHTTP-Monitor\n\u2192 il servizio web risponde\n  a una richiesta HTTP?\n\nContent-Monitor\n\u2192 la pagina fornisce anche\n  il contenuto previsto?<\/code><\/pre>\n\n\n\n
Un server pu\u00f2 rispondere al ping mentre il sito web non funziona.<\/p>\n\n\n\n
Viceversa, un sito web pu\u00f2 essere raggiungibile anche se i pacchetti ICMP vengono bloccati o non ricevono risposta.<\/p>\n\n\n\n
\n
Importante:<\/strong> Non usare il ping come unica prova che un sito web funziona.<\/p>\n<\/blockquote>\n\n\n\n
Cosa significa l'intervallo di controllo?<\/h2>\n\n\n\n
Un sistema di monitoraggio controlla un sito web a intervalli specifici.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
08:00 Esame superato\n\n08:05 Esame superato\n\n08:10 Esame fallito\n\n08:15 Esame fallito\n\n08:20 Esame superato<\/code><\/pre>\n\n\n\n
Con un intervallo di controllo di cinque minuti, in questo esempio non sai con precisione al secondo quando sia iniziata l'interruzione tra le 08:05 e le 08:10 o quando sia terminata tra le 08:15 e le 08:20.<\/p>\n\n\n\n
L'intervallo influenza quindi la risoluzione temporale della tua misurazione.<\/p>\n\n\n\n
Intervalli pi\u00f9 brevi rilevano le anomalie pi\u00f9 rapidamente<\/h2>\n\n\n\n
Se viene controllato ogni minuto, un guasto pu\u00f2 solitamente essere rilevato pi\u00f9 rapidamente rispetto a un controllo ogni 15 minuti.<\/p>\n\n\n\n
Tuttavia, un intervallo pi\u00f9 breve significa anche un maggior numero di richieste di monitoraggio.<\/p>\n\n\n\n
L'intervallo appropriato dipende dall'importanza del servizio monitorato.<\/p>\n\n\n\n
Per un negozio online di importanza critica per il business, un rilevamento pi\u00f9 rapido pu\u00f2 essere pi\u00f9 importante che per un piccolo sito informativo.<\/p>\n\n\n\n
Non allarmare subito per ogni singolo errore<\/h2>\n\n\n\n
Una singola richiesta fallita non significa necessariamente che il sito web sia effettivamente offline.<\/p>\n\n\n\n
Possibili cause a breve termine potrebbero essere, ad esempio:<\/p>\n\n\n\n
breve interruzione della rete\nperdita temporanea di pacchetti\nbreve timeout\nproblema in una sede di monitoraggio\nsovraccarico temporaneo\nbreve fase di manutenzione<\/code><\/pre>\n\n\n\n
I sistemi di monitoraggio professionali possono quindi confermare un controllo fallito prima che venga segnalato un guasto.<\/p>\n\n\n\n
Perch\u00e9 i controlli periodici sono importanti<\/h2>\n\n\n\n
Supponendo che una sede di monitoraggio non riesca a raggiungere il tuo sito web una volta.<\/p>\n\n\n\n
Invece di far scattare subito l'allarme, il sistema pu\u00f2 effettuare un nuovo controllo o utilizzare una seconda posizione.<\/p>\n\n\n\n
Controllo fallito\n        \u2193\nControllo di verifica\n        \u2193\nancora errore?\n   \u2199             \u2198\n no             s\u00ec\n  \u2193                \u2193\nnessun          Guasto\nallarme         probabile<\/code><\/pre>\n\n\n\n
Ci\u00f2 consente di ridurre i falsi allarmi non necessari.<\/p>\n\n\n\n
Monitoraggio da pi\u00f9 posizioni<\/h2>\n\n\n\n
Un servizio di monitoraggio pu\u00f2 effettuare controlli da diverse regioni geografiche.<\/p>\n\n\n\n
Questo aiuta a distinguere tra un blackout globale e un problema di rete regionale.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Zurigo      \u2192 Errore\nFrancoforte \u2192 OK\nAmsterdam   \u2192 OK<\/code><\/pre>\n\n\n\n
Questo depone a favore di una situazione diversa rispetto a:<\/p>\n\n\n\n
Zurigo      \u2192 Errore\nFrancoforte \u2192 Errore\nAmsterdam   \u2192 Errore<\/code><\/pre>\n\n\n\n
Diverse sedi forniscono quindi un contesto aggiuntivo nella diagnostica degli errori.<\/p>\n\n\n\n
Cos'\u00e8 un timeout?<\/h2>\n\n\n\n
Un sistema di monitoraggio non attende indefinitamente una risposta.<\/p>\n\n\n\n
Se non si riceve una risposta sufficiente entro un tempo stabilito, il controllo pu\u00f2 essere considerato scaduto per timeout.<\/p>\n\n\n\n
Tuttavia, un timeout non significa automaticamente:<\/p>\n\n\n\n
Server completamente offline<\/code><\/p>\n\n\n\n
Significa prima di tutto:<\/p>\n\n\n\n
la risposta attesa non \u00e8 stata ricevuta entro il tempo stabilito<\/code><\/p>\n\n\n\n
La causa deve quindi essere diagnosticata.<\/p>\n\n\n\n
Il tempo di risposta non \u00e8 la stessa cosa del tempo di caricamento<\/h2>\n\n\n\n
Molti sistemi di monitoraggio mostrano un tempo di risposta.<\/p>\n\n\n\n
Questo numero non deve essere equiparato automaticamente al tempo di caricamento completo di un sito web.<\/p>\n\n\n\n
Un semplice controllo HTTP potrebbe non caricare le stesse risorse e non eseguire gli stessi processi del browser di un vero visitatore.<\/p>\n\n\n\n
Per l'analisi delle prestazioni effettive del sito web, dovresti quindi utilizzare altri metodi di misurazione.<\/p>\n\n\n\n
Ti spieghiamo come analizzare in modo sensato i tempi di caricamento su Misurare e valutare correttamente il tempo di caricamento del sito web<\/a>.<\/p>\n\n\n\n
Il monitoraggio dei siti web e il PageSpeed misurano cose diverse<\/h2>\n\n\n\n
Entrambi gli strumenti vengono occasionalmente confusi l'uno con l'altro.<\/p>\n\n\n\n
Monitoraggio di siti web<\/th>Analisi delle prestazioni<\/th><\/tr><\/thead>
verifica regolarmente la reperibilit\u00e0 e le condizioni definite<\/td>esamina l'esperienza di ricarica e utilizzo<\/td><\/tr>
funziona continuamente<\/td>viene valutato puntualmente o sulla base di dati degli utenti raccolti<\/td><\/tr>
pu\u00f2 segnalare guasti<\/td>mostra problemi di prestazioni e potenziale di ottimizzazione<\/td><\/tr>
risponde \u201eIl servizio \u00e8 raggiungibile?\u201c<\/td>risponde \u201eQuanto \u00e8 performante il sito?\u201c<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Per un'analisi tecnica con Google PageSpeed Insights, trovi la nostra guida su Usare correttamente Google PageSpeed Insights<\/a>.<\/p>\n\n\n\n
Che cos'\u00e8 l'uptime?<\/h2>\n\n\n\n
L'uptime descrive la percentuale di un determinato periodo di tempo in cui un servizio \u00e8 stato misurato come disponibile.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
99,9 % Disponibilit\u00e0<\/code><\/p>\n\n\n\n
non significa che un sito web non possa mai guastarsi.<\/p>\n\n\n\n
Anche in presenza di percentuali molto elevate, dal punto di vista del calcolo risulta un determinato tempo di inattivit\u00e0 possibile o misurato.<\/p>\n\n\n\n
Trattiamo in modo approfondito come interpretare correttamente questi valori alla pagina Uptime e disponibilit\u00e0: cosa significa davvero 99,9 %<\/a>.<\/p>\n\n\n\n
Il monitoraggio definisce autonomamente cosa significa \u201edisponibile\u201c<\/h2>\n\n\n\n
Un'importante particolarit\u00e0: un valore di uptime dipende dal metodo di misurazione utilizzato.<\/p>\n\n\n\n
Un monitor potrebbe, ad esempio, stabilire:<\/p>\n\n\n\n
HTTP 200\n= disponibile\n\nTimeout\n= non disponibile\n\nHTTP 500\n= non disponibile<\/code><\/pre>\n\n\n\n
Un altro monitor potrebbe accettare reindirizzamenti o eseguire ulteriori controlli dei contenuti.<\/p>\n\n\n\n
Ecco perch\u00e9 i valori di uptime di sistemi diversi non sono necessariamente direttamente comparabili.<\/p>\n\n\n\n
Un risultato di monitoraggio \u00e8 una misurazione, non una verit\u00e0 assoluta<\/h2>\n\n\n\n
Ogni misurazione avviene da una determinata posizione, in un determinato momento e con determinate regole.<\/p>\n\n\n\n
Questo significa:<\/p>\n\n\n\n
Sito di monitoraggio\n\nPercorso di rete\n\nIntervallo di controllo\n\nTimeout\n\nstato previsto\n\nControlli di conferma<\/code><\/pre>\n\n\n\n
influenzano il risultato.<\/p>\n\n\n\n
Per una diagnosi affidabile, in caso di anomalia non dovresti quindi limitarti a osservare l'allarme rosso di monitoraggio, ma verificare successivamente la causa a livello tecnico.<\/p>\n\n\n\n
Cosa pu\u00f2 attivare un allarme di monitoraggio?<\/h2>\n\n\n\n
Un allarme pu\u00f2 avere numerose cause.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Server web non raggiungibile\nL'applicazione risponde con un errore\nErrore PHP\nProblema di database\nProblema DNS\nProblema di rete\nRegola del firewall\nTimeout\nLavori di manutenzione\nReindirizzamento errato\nProblema SSL\/TLS\nServizio esterno non disponibile<\/code><\/pre>\n\n\n\n
L'allarme \u00e8 quindi l'inizio della diagnosi \u2013 non automaticamente la diagnosi stessa.<\/p>\n\n\n\n
Cosa dovresti fare per primo dopo un allarme di guasto?<\/h2>\n\n\n\n
Verifica prima se riesci a riprodurre tu stesso il guasto.<\/p>\n\n\n\n
Apri l'URL monitorato e controlla cosa succede effettivamente.<\/p>\n\n\n\n
Se possibile, verifica inoltre tramite un'altra connessione Internet o un'altra rete.<\/p>\n\n\n\n
Danach solltest du die Art des Fehlers eingrenzen.<\/p>\n\n\n\n
Monitoring meldet Fehler\n        \u2193\nWebsite selbst aufrufen\n        \u2193\nFehler reproduzierbar?\n        \u2193\nHTTP-Status pr\u00fcfen\n        \u2193\nDNS-Aufl\u00f6sung pr\u00fcfen\n        \u2193\nSSL\/HTTPS pr\u00fcfen\n        \u2193\nnur eine Seite oder\nganze Website betroffen?\n        \u2193\nHosting \/ Anwendung \/\nNetzwerk weiter untersuchen<\/code><\/pre>\n\n\n\n
Browser-Fehlermeldung dokumentieren<\/h2>\n\n\n\n
Wenn du eine St\u00f6rung selbst siehst, dokumentiere die genaue Fehlermeldung.<\/p>\n\n\n\n
Ein Screenshot kann dabei hilfreich sein.<\/p>\n\n\n\n
Notiere au\u00dferdem:<\/p>\n\n\n\n
Zeitpunkt\n\nbetroffene URL\n\nHTTP-Status, falls bekannt\n\nDauer der St\u00f6rung\n\nbetroffene Funktionen\n\nverwendetes Netzwerk\n\nwiederholbar oder sporadisch?<\/code><\/pre>\n\n\n\n
Diese Informationen erleichtern eine sp\u00e4tere technische Analyse erheblich.<\/p>\n\n\n\n
HTTP-Status bei einer St\u00f6rung pr\u00fcfen<\/h2>\n\n\n\n
Ein HTTP-Status kann einen wichtigen ersten Hinweis liefern.<\/p>\n\n\n\n
Esempi:<\/p>\n\n\n\n
403 Forbidden\n\u2192 Zugriff wird verweigert\n\n404 Not Found\n\u2192 angeforderte URL nicht gefunden\n\n500 Internal Server Error\n\u2192 serverseitiger Fehler\n\n502 Bad Gateway\n\u2192 Problem zwischen beteiligten Diensten\n\n503 Service Unavailable\n\u2192 Dienst aktuell nicht verf\u00fcgbar\n\n504 Gateway Timeout\n\u2192 vorgelagerte Antwort\n  nicht rechtzeitig erhalten<\/code><\/pre>\n\n\n\n
Ein Statuscode allein nennt jedoch nicht immer die konkrete Ursache.<\/p>\n\n\n\n
DNS-Probleme erkennen<\/h2>\n\n\n\n
Wenn ein Domainname nicht korrekt aufgel\u00f6st werden kann, kann die Website trotz funktionierendem Webserver nicht \u00fcber ihren Domainnamen erreicht werden.<\/p>\n\n\n\n
Ein Monitoring-Alarm kann deshalb auch durch DNS-Probleme entstehen.<\/p>\n\n\n\n
Typische Fragen bei der Diagnose sind:<\/p>\n\n\n\n
Wird die Domain aufgel\u00f6st?\n\nWelche IP-Adresse wird geliefert?\n\nSind die autoritativen Nameserver erreichbar?\n\nWurden DNS-Eintr\u00e4ge k\u00fcrzlich ge\u00e4ndert?\n\nIst nur ein Resolver oder\neine Region betroffen?<\/code><\/pre>\n\n\n\n
DNS sollte jedoch nicht bei jedem Website-Ausfall automatisch als Ursache angenommen werden.<\/p>\n\n\n\n
SSL-\/TLS-Probleme erkennen<\/h2>\n\n\n\n
Bei einer HTTPS-Website kann ein Problem mit dem Zertifikat oder der TLS-Verbindung dazu f\u00fchren, dass ein Monitor die Pr\u00fcfung als fehlgeschlagen bewertet.<\/p>\n\n\n\n
Le possibili cause possono essere:<\/p>\n\n\n\n
Zertifikat abgelaufen\n\nZertifikat noch nicht g\u00fcltig\n\nHostname passt nicht\n\nZertifikatskette fehlerhaft\n\nTLS-Verbindung scheitert<\/code><\/pre>\n\n\n\n
Wie du HTTPS und Zertifikate systematisch kontrollierst, behandeln wir unter Controllo del certificato SSL e HTTPS: individuare gli errori comuni<\/a>.<\/p>\n\n\n\n
Website nur f\u00fcr einzelne Besucher nicht erreichbar<\/h2>\n\n\n\n
Nicht jede gemeldete Nichterreichbarkeit ist ein globaler Website-Ausfall.<\/p>\n\n\n\n
Wenn nur ein einzelner Besucher betroffen ist, k\u00f6nnen beispielsweise lokale Ursachen vorliegen:<\/p>\n\n\n\n
Internetverbindung\n\nlokaler DNS-Resolver\n\nBrowser\n\nVPN\n\nFirewall\n\nUnternehmensnetzwerk\n\nRouting zwischen Netzen<\/code><\/pre>\n\n\n\n
Ein externes Monitoring aus mehreren Standorten hilft dabei festzustellen, ob die Website allgemein oder nur \u00fcber bestimmte Netzwerkwege nicht erreichbar ist.<\/p>\n\n\n\n
Website nur sporadisch langsam oder nicht erreichbar<\/h2>\n\n\n\n
Intermittierende Probleme geh\u00f6ren zu den schwierigsten Fehlern, weil die Website beim manuellen Test h\u00e4ufig bereits wieder funktioniert.<\/p>\n\n\n\n
Le possibili cause possono essere, ad esempio:<\/p>\n\n\n\n
kurzzeitige Lastspitzen\n\nRessourcenengp\u00e4sse\n\nlangsame Datenbankabfragen\n\nexterne API-Aufrufe\n\nCron- oder Hintergrundprozesse\n\nBackup-Prozesse\n\nNetzwerkprobleme\n\nsporadische Anwendungsfehler<\/code><\/pre>\n\n\n\n
Welche Ursache tats\u00e4chlich vorliegt, l\u00e4sst sich aus dem Monitoring-Alarm allein nicht ableiten.<\/p>\n\n\n\n
Eine systematische Performance- und Fehlerdiagnose erkl\u00e4ren wir unter Sito web lento: trovare sistematicamente le cause<\/a>.<\/p>\n\n\n\n
Warum Zeitstempel so wichtig sind<\/h2>\n\n\n\n
Bei sporadischen St\u00f6rungen ist der genaue Zeitpunkt oft entscheidend.<\/p>\n\n\n\n
Wenn ein Monitoring beispielsweise meldet:<\/p>\n\n\n\n
DOWN: 14:37:22\n\nUP:   14:41:08<\/code><\/pre>\n\n\n\n
k\u00f6nnen Server-, Anwendungs- oder andere technische Logs gezielt f\u00fcr diesen Zeitraum untersucht werden.<\/p>\n\n\n\n
Ohne genaue Zeitangabe ist die Suche nach der Ursache deutlich schwieriger.<\/p>\n\n\n\n
\n
Consiglio pratico:<\/strong> Bewahre bei wiederkehrenden St\u00f6rungen immer den exakten Zeitpunkt des Monitoring-Alarms auf. \u201eDie Website war gestern irgendwann langsam\u201c ist f\u00fcr eine technische Diagnose wesentlich weniger hilfreich als ein konkretes Zeitfenster.<\/p>\n<\/blockquote>\n\n\n\n
Was bedeutet DOWN?<\/h2>\n\n\n\n
Ein Monitoring-Dienst bezeichnet eine Pr\u00fcfung h\u00e4ufig als DOWN<\/code>, wenn die definierten Erfolgskriterien nicht erf\u00fcllt werden.<\/p>\n\n\n\n
Das muss nicht zwingend bedeuten, dass der komplette Server ausgeschaltet war.<\/p>\n\n\n\n
Je nach Monitor kann beispielsweise bereits:<\/p>\n\n\n\n
HTTP 500\n\nTimeout\n\nDNS-Fehler\n\nSSL-Fehler\n\nfehlender erwarteter Inhalt<\/code><\/pre>\n\n\n\n
ALS DOWN<\/code> gewertet werden.<\/p>\n\n\n\n
Was bedeutet UP?<\/h2>\n\n\n\n
SU<\/code> bedeutet entsprechend, dass die aktuelle Pr\u00fcfung die definierten Erfolgskriterien erf\u00fcllt.<\/p>\n\n\n\n
Auch hier gilt:<\/p>\n\n\n\n
UP \u2260 jede Funktion der Website funktioniert garantiert<\/code><\/p>\n\n\n\n
Ein einfacher Monitor kann beispielsweise best\u00e4tigen, dass die Startseite 200 OK<\/code> liefert. Ob der komplette Checkout eines Onlineshops funktioniert, wurde damit noch nicht getestet.<\/p>\n\n\n\n
Monitoring eines Onlineshops<\/h2>\n\n\n\n
Bei einem Onlineshop k\u00f6nnen neben der Startseite weitere Funktionen gesch\u00e4ftskritisch sein.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Shop-Seite\n\nProduktseite\n\nWarenkorb\n\nCheckout\n\nZahlungsanbieter\n\nBestellprozess<\/code><\/pre>\n\n\n\n
Ein einfacher Uptime-Monitor kann allerdings nicht automatisch beurteilen, ob der gesamte Kaufprozess funktioniert.<\/p>\n\n\n\n
Daf\u00fcr w\u00e4ren weitergehende synthetische Transaktionspr\u00fcfungen beziehungsweise funktionale Tests notwendig.<\/p>\n\n\n\n
Nicht blind den Checkout mit normalen Requests \u00fcberwachen<\/h2>\n\n\n\n
Dynamische Prozesse wie Warenkorb, Checkout, Login oder Formulare sollten nicht un\u00fcberlegt mit simplen Monitoring-Aufrufen getestet werden.<\/p>\n\n\n\n
Solche Seiten k\u00f6nnen Sitzungen, Cookies, CSRF-Schutz, dynamische Tokens oder weitere Anwendungslogik verwenden.<\/p>\n\n\n\n
F\u00fcr funktionale Transaktionspr\u00fcfungen muss der Test deshalb gezielt f\u00fcr die jeweilige Anwendung konzipiert werden.<\/p>\n\n\n\n
Monitoring von WordPress<\/h2>\n\n\n\n
Bei einer WordPress-Website ist die \u00f6ffentliche Startseite ein sinnvoller Basischeck.<\/p>\n\n\n\n
Je nach Bedeutung der Website k\u00f6nnen zus\u00e4tzliche \u00f6ffentliche Seiten \u00fcberwacht werden.<\/p>\n\n\n\n
Den Administrationsbereich solltest du dagegen nicht einfach mit automatisierten Login-Versuchen belasten.<\/p>\n\n\n\n
Wenn die \u00f6ffentliche Website funktioniert, das WordPress-Backend jedoch langsam oder nicht erreichbar ist, handelt es sich m\u00f6glicherweise um ein anderes Problem als einen vollst\u00e4ndigen Website-Ausfall.<\/p>\n\n\n\n
Frontend und Backend getrennt betrachten<\/h2>\n\n\n\n
Eine WordPress-Website kann beispielsweise folgende Situation zeigen:<\/p>\n\n\n\n
Frontend\n\u2192 funktioniert\n\n\/wp-admin\/\n\u2192 sehr langsam<\/code><\/pre>\n\n\n\n
oder umgekehrt:<\/p>\n\n\n\n
Webserver\n\u2192 erreichbar\n\nWordPress\n\u2192 Fehler 500<\/code><\/pre>\n\n\n\n
Ein Monitoring-Ergebnis sollte deshalb immer im Kontext des tats\u00e4chlich \u00fcberwachten Endpunkts interpretiert werden.<\/p>\n\n\n\n
Cache kann Monitoring-Ergebnisse beeinflussen<\/h2>\n\n\n\n
Eine gecachte Startseite kann weiterhin sehr schnell ausgeliefert werden, obwohl ein Problem in einem dynamischen Bereich der Website besteht.<\/p>\n\n\n\n
Umgekehrt kann ein ungecachter Endpunkt andere Antwortzeiten zeigen als die \u00f6ffentliche Startseite.<\/p>\n\n\n\n
Das bedeutet nicht, dass Caching das Monitoring \u201efalsch\u201c macht. Der Monitor misst schlicht den Endpunkt, den du ihm vorgegeben hast.<\/p>\n\n\n\n
Deshalb ist die Auswahl repr\u00e4sentativer Pr\u00fcfungen entscheidend.<\/p>\n\n\n\n
CDN und Monitoring<\/h2>\n\n\n\n
Wenn eine Website \u00fcber ein Content Delivery Network oder einen Reverse Proxy ausgeliefert wird, sieht ein externer Monitor m\u00f6glicherweise zun\u00e4chst diese vorgelagerte Infrastruktur.<\/p>\n\n\n\n
Das kann zu Situationen f\u00fchren, in denen:<\/p>\n\n\n\n
CDN erreichbar\n        \u2193\nOrigin-Server hat Problem\n        \u2193\ngecachter Inhalt teilweise\nweiterhin erreichbar<\/code><\/pre>\n\n\n\n
o:<\/p>\n\n\n\n
Origin funktioniert\n        \u2193\nCDN \/ Proxy hat St\u00f6rung\n        \u2193\nBesucher erreicht Website\ntrotzdem nicht normal<\/code><\/pre>\n\n\n\n
Bei der Diagnose solltest du deshalb ber\u00fccksichtigen, welche Infrastruktur zwischen Besucher und eigentlichem Webserver liegt.<\/p>\n\n\n\n
Monitoring und Wartungsarbeiten<\/h2>\n\n\n\n
Geplante Wartungsarbeiten k\u00f6nnen absichtlich zu einer vor\u00fcbergehenden Nichterreichbarkeit f\u00fchren.<\/p>\n\n\n\n
Gute Monitoring-Systeme erlauben deshalb Wartungsfenster beziehungsweise das zeitweise Pausieren von Alarmen.<\/p>\n\n\n\n
Dadurch vermeidest du unn\u00f6tige Benachrichtigungen w\u00e4hrend einer bekannten geplanten Wartung.<\/p>\n\n\n\n
Die Messdaten solltest du dennoch korrekt interpretieren: Ein geplanter Ausfall bleibt technisch eine Phase eingeschr\u00e4nkter oder fehlender Verf\u00fcgbarkeit, auch wenn daf\u00fcr kein Alarm notwendig ist.<\/p>\n\n\n\n
Welche Benachrichtigungen sind sinnvoll?<\/h2>\n\n\n\n
Ein Monitoring-System kann je nach Anbieter unterschiedliche Alarmwege unterst\u00fctzen.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
E-Mail\n\nPush-Nachricht\n\nSMS\n\nMessenger\n\nWebhook\n\nIncident-System<\/code><\/pre>\n\n\n\n
Entscheidend ist weniger die Anzahl der Kan\u00e4le als die Frage, ob eine relevante Meldung tats\u00e4chlich von einer zust\u00e4ndigen Person wahrgenommen wird.<\/p>\n\n\n\n
Zu viele Alarme sind kontraproduktiv<\/h2>\n\n\n\n
Wenn ein Monitoring-System st\u00e4ndig irrelevante Warnungen versendet, entsteht Alarmm\u00fcdigkeit.<\/p>\n\n\n\n
Wichtige Meldungen werden dann m\u00f6glicherweise \u00fcbersehen.<\/p>\n\n\n\n
Konfiguriere deshalb:<\/p>\n\n\n\n
sinnvolle Pr\u00fcfintervalle\n\nrealistische Timeouts\n\nBest\u00e4tigungspr\u00fcfungen\n\nrelevante Endpunkte\n\npassende Alarmempf\u00e4nger\n\nWartungsfenster<\/code><\/pre>\n\n\n\n
mit Blick auf den tats\u00e4chlichen Einsatzzweck.<\/p>\n\n\n\n
Was ist ein False Positive?<\/h2>\n\n\n\n
Ein False Positive ist vereinfacht ein Alarm, obwohl der \u00fcberwachte Dienst aus Sicht der relevanten Nutzer nicht tats\u00e4chlich ausgefallen war.<\/p>\n\n\n\n
Beispielsweise k\u00f6nnte nur der Netzwerkweg eines einzelnen Monitoring-Standorts gest\u00f6rt gewesen sein.<\/p>\n\n\n\n
Deshalb sind Wiederholungspr\u00fcfungen und mehrere Standorte bei wichtigeren Systemen hilfreich.<\/p>\n\n\n\n
Was ist ein False Negative?<\/h2>\n\n\n\n
Umgekehrt kann ein Monitor einen Dienst als verf\u00fcgbar bewerten, obwohl f\u00fcr Besucher ein relevantes Problem besteht.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Startseite liefert 200 OK\n\naber:\n\nCheckout funktioniert nicht<\/code><\/pre>\n\n\n\n
Der einfache Startseitenmonitor meldet weiterhin SU<\/code>, obwohl eine gesch\u00e4ftskritische Funktion gest\u00f6rt ist.<\/p>\n\n\n\n
Das zeigt eine zentrale Grenze jedes Monitorings: Es kann nur pr\u00fcfen, wof\u00fcr es konfiguriert wurde.<\/p>\n\n\n\n
Monitoring ersetzt keine Backups<\/h2>\n\n\n\n
Website-Monitoring und Backups l\u00f6sen v\u00f6llig unterschiedliche Probleme.<\/p>\n\n\n\n
Monitoring\n\u2192 erkennt eine St\u00f6rung\n\nBackup\n\u2192 erm\u00f6glicht Wiederherstellung\n  von Daten oder Systemzust\u00e4nden<\/code><\/pre>\n\n\n\n
Ein Monitor kann dich beispielsweise dar\u00fcber informieren, dass eine Website nicht erreichbar ist. Er besitzt dadurch aber nicht automatisch eine verwendbare Kopie deiner Website.<\/p>\n\n\n\n
Monitoring ersetzt keine Sicherheits\u00fcberwachung<\/h2>\n\n\n\n
Eine Website kann technisch erreichbar sein und trotzdem kompromittiert worden sein.<\/p>\n\n\n\n
Ein normaler HTTP-Monitor erkennt nicht automatisch:<\/p>\n\n\n\n
Schadcode\n\nmanipulierte Dateien\n\ngestohlene Zugangsdaten\n\nunerlaubte Administratoren\n\nversteckte Weiterleitungen\n\nDatenabfluss<\/code><\/pre>\n\n\n\n
Uptime-Monitoring ist deshalb nur ein Bestandteil einer umfassenderen technischen \u00dcberwachung.<\/p>\n\n\n\n
Monitoring ersetzt keine Performance-Analyse<\/h2>\n\n\n\n
Eine Website kann 100 Prozent der gemessenen Zeit erreichbar und trotzdem unertr\u00e4glich langsam sein.<\/p>\n\n\n\n
Umgekehrt kann eine sehr schnelle Website gelegentliche Ausf\u00e4lle besitzen.<\/p>\n\n\n\n
Deshalb sollten Verf\u00fcgbarkeit und Performance getrennt gemessen werden.<\/p>\n\n\n\n
Wenn deine Website zwar erreichbar, aber langsam ist, findest du unter Sito web lento: trovare sistematicamente le cause<\/a> einen Diagnoseablauf.<\/p>\n\n\n\n
Monitoring-Daten \u00fcber l\u00e4ngere Zeit auswerten<\/h2>\n\n\n\n
Der eigentliche Wert eines Monitorings entsteht nicht nur durch einzelne Alarme.<\/p>\n\n\n\n
\u00dcber l\u00e4ngere Zeit k\u00f6nnen Muster sichtbar werden.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Ausf\u00e4lle immer nachts?\n\nProbleme immer w\u00e4hrend Backups?\n\nTimeouts nur bei bestimmter Seite?\n\nFehler nur aus bestimmter Region?\n\nAntwortzeiten zu bestimmten\nZeiten auff\u00e4llig?\n\nwiederkehrende 5xx-Fehler?<\/code><\/pre>\n\n\n\n
Solche Muster k\u00f6nnen bei der Ursachenanalyse wesentlich hilfreicher sein als ein einzelner isolierter Alarm.<\/p>\n\n\n\n
Statusseiten<\/h2>\n\n\n\n
Bei gr\u00f6\u00dferen Diensten kann zus\u00e4tzlich eine \u00f6ffentliche oder interne Statusseite sinnvoll sein.<\/p>\n\n\n\n
Sie kann beispielsweise anzeigen:<\/p>\n\n\n\n
Website\n\nAPI\n\nKundencenter\n\nE-Mail-Dienste\n\nweitere Systeme<\/code><\/pre>\n\n\n\n
Eine Statusseite sollte jedoch m\u00f6glichst nicht vollst\u00e4ndig von genau derselben Infrastruktur abh\u00e4ngen, deren Ausfall sie kommunizieren soll.<\/p>\n\n\n\n
Was sollte ein gutes Basis-Monitoring leisten?<\/h2>\n\n\n\n
F\u00fcr eine normale gesch\u00e4ftliche Website sollte ein Basis-Monitoring mindestens klar beantworten k\u00f6nnen:<\/p>\n\n\n\n
Welche URL wird gepr\u00fcft?\n\nWie h\u00e4ufig wird gepr\u00fcft?\n\nWelcher Zustand gilt als Erfolg?\n\nWie lange wird auf Antwort gewartet?\n\nWird ein Fehler best\u00e4tigt?\n\nWann wird alarmiert?\n\nWann gilt die Website wieder als UP?\n\nWer erh\u00e4lt den Alarm?<\/code><\/pre>\n\n\n\n
Nur wenn diese Parameter bekannt sind, lassen sich die gemessenen Werte sinnvoll interpretieren.<\/p>\n\n\n\n
Monitoring richtig dokumentieren<\/h2>\n\n\n\n
Bei wichtigen Websites lohnt sich eine kurze Dokumentation der \u00dcberwachung.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Monitor:\nWebsite Startseite\n\nURL:\nhttps://example.com\/\n\nTyp:\nHTTPS\n\nIntervall:\n5 Minuten\n\nErwartung:\nHTTP 200\n\nAlarm:\nnach best\u00e4tigtem Fehler\n\nEmpf\u00e4nger:\nzust\u00e4ndige Person<\/code><\/pre>\n\n\n\n
Dadurch ist auch sp\u00e4ter nachvollziehbar, was der Monitor tats\u00e4chlich gepr\u00fcft hat.<\/p>\n\n\n\n
Ein typischer Monitoring-Ablauf<\/h2>\n\n\n\n
Website definieren\n        \u2193\nwichtigen Endpunkt w\u00e4hlen\n        \u2193\nPr\u00fcfmethode bestimmen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nErfolgskriterien definieren\n        \u2193\nAlarmierung konfigurieren\n        \u2193\nMonitoring starten\n        \u2193\nFehler erkannt?\n        \u2193\nKontrollpr\u00fcfung\n        \u2193\nAlarm\n        \u2193\nSt\u00f6rung reproduzieren\n        \u2193\nFehler eingrenzen\n        \u2193\nUrsache beheben\n        \u2193\nWiederherstellung pr\u00fcfen\n        \u2193\nMonitoring best\u00e4tigt UP\n        \u2193\nVorfall dokumentieren<\/code><\/pre>\n\n\n\n
H\u00e4ufige Fehler beim Website-Monitoring<\/h2>\n\n\n\n
nur Ping verwenden\n\n200 OK mit vollst\u00e4ndig\nfunktionierender Website gleichsetzen\n\nAntwortzeit mit kompletter\nLadezeit verwechseln\n\nnur einen irrelevanten\nEndpunkt \u00fcberwachen\n\nbei jedem einzelnen Timeout\nsofort Alarm ausl\u00f6sen\n\nzu viele unwichtige\nMonitore konfigurieren\n\nkeine Zeitstempel dokumentieren\n\ngeplante Wartungen\nnicht ber\u00fccksichtigen\n\nMonitoring als Backup betrachten\n\nMonitoring als Sicherheitsl\u00f6sung betrachten\n\nUP mit \"alles funktioniert\"\ngleichsetzen\n\nDOWN mit \"Server ausgeschaltet\"\ngleichsetzen<\/code><\/pre>\n\n\n\n
Checkliste: Website-Monitoring sinnvoll einrichten<\/h2>\n\n\n\n
Was soll \u00fcberwacht werden?\n        \u2193\n\u00f6ffentliche URL bestimmen\n        \u2193\nHTTP oder HTTPS verwenden\n        \u2193\nerwarteten Status definieren\n        \u2193\nfalls sinnvoll Inhalt pr\u00fcfen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nTimeout sinnvoll w\u00e4hlen\n        \u2193\nKontrollpr\u00fcfung aktivieren\n        \u2193\nggf. mehrere Standorte nutzen\n        \u2193\nAlarmempf\u00e4nger festlegen\n        \u2193\nTestalarm durchf\u00fchren\n        \u2193\nWartungsfenster ber\u00fccksichtigen\n        \u2193\nMonitoring-Daten regelm\u00e4\u00dfig pr\u00fcfen\n        \u2193\nwiederkehrende Fehler analysieren<\/code><\/pre>\n\n\n\n
Riepilogo<\/h2>\n\n\n\n
Website-Monitoring \u00fcberpr\u00fcft automatisch, ob eine Website oder ein bestimmter Dienst erreichbar ist und die definierten Erfolgskriterien erf\u00fcllt.<\/p>\n\n\n\n
F\u00fcr normale Websites ist ein externer HTTPS-Monitor ein sinnvoller Ausgangspunkt. Je nach Anwendungsfall k\u00f6nnen zus\u00e4tzliche Inhaltspr\u00fcfungen, weitere Endpunkte oder Pr\u00fcfungen aus mehreren Regionen sinnvoll sein.<\/p>\n\n\n\n
Ein Monitoring-Alarm bedeutet jedoch nicht automatisch, dass der komplette Server ausgefallen ist. Ein Timeout, DNS-Problem, HTTP-Fehler, Zertifikatsproblem oder eine gest\u00f6rte Anwendung kann ebenfalls einen Alarm verursachen.<\/p>\n\n\n\n
Umgekehrt beweist ein gr\u00fcner SU<\/code>-Status nicht, dass jede Funktion einer Website einwandfrei arbeitet. Ein einfacher Startseitenmonitor kann beispielsweise keinen vollst\u00e4ndigen Bestellprozess beurteilen.<\/p>\n\n\n\n
Monitoring ersetzt au\u00dferdem weder Backups noch Sicherheits\u00fcberwachung oder Performance-Analyse. Diese Systeme beantworten unterschiedliche technische Fragen.<\/p>\n\n\n\n
Besonders wertvoll wird Monitoring durch kontinuierliche Messungen, genaue Zeitstempel und eine sinnvolle Alarmierung. Bei sporadischen Problemen k\u00f6nnen diese Daten helfen, wiederkehrende Muster zu erkennen und Server- oder Anwendungslogs gezielt f\u00fcr den betroffenen Zeitraum auszuwerten.<\/p>\n\n\n\n
Gutes Website-Monitoring bedeutet deshalb nicht, m\u00f6glichst viele Checks einzurichten. Entscheidend ist, die richtigen Endpunkte mit klar definierten Kriterien zu \u00fcberwachen und bei einer Abweichung schnell die Informationen zu erhalten, die f\u00fcr eine echte Diagnose ben\u00f6tigt werden.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
Eine Website kann jederzeit ausfallen \u2013 auch wenn sie wenige Minuten zuvor noch problemlos funktioniert hat. Serverprobleme, fehlerhafte Updates, DNS-St\u00f6rungen, abgelaufene Zertifikate oder Probleme mit einer Anwendung k\u00f6nnen dazu f\u00fchren, dass Besucher eine Website pl\u00f6tzlich nicht mehr erreichen. Wer die eigene Website nur gelegentlich selbst aufruft, bemerkt solche St\u00f6rungen m\u00f6glicherweise erst Stunden sp\u00e4ter oder durch […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[85],"doc_tag":[],"class_list":["post-22919","docs","type-docs","status-publish","hentry","doc_category-seo-monitoring"],"year_month":"2026-09","word_count":3699,"total_views":"4","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/it\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"SEO & Monitoring","term_url":"https:\/\/www.curiaweb.ch\/it\/hilfe-kategorie\/seo-monitoring\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/comments?post=22919"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22919\/revisions"}],"predecessor-version":[{"id":22921,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22919\/revisions\/22921"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/media?parent=22919"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/doc_category?post=22919"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/doc_tag?post=22919"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}