Wenn eine WordPress-Website an einem Freitagnachmittag ausfällt, läuft die Uhr für zwei verschiedene Probleme an: die Behebung des Problems und die Klärung, wer dafür verantwortlich ist.
Das zweite Problem dauert fast immer länger. Ein Entwickler zeigt auf die Kampagne, die gerade online gegangen ist. Der Marketingmitarbeiter zeigt auf den Server. Die Agentur nimmt Anrufe von beiden Seiten entgegen und hat keine eigenen Daten, auf die sie zurückgreifen kann. Bis sich alle darauf geeinigt haben, wo man nachsehen muss, hat der Ausfall bereits echtes Geld gekostet – und der Streit auch.
Die eigentliche Ursache ist nicht, dass sich die Teams nicht einig sind. Es liegt daran, dass jedes Team mit einem anderen Ausschnitt der Daten arbeitet. Der Entwickler sieht den Code. Der Marketingmitarbeiter sieht den Traffic. Die Agentur sieht die Warteschlange der Support-Tickets. Niemand sieht zur gleichen Zeit dasselbe, daher kann niemand etwas ausschließen.
Kinstas Ansatz besteht darin, alle Teams auf die gleiche diagnostische Basis zu stellen. Die Daten, die die Support-Techniker von Kinsta zur Untersuchung eines Problems nutzen – wie Antwortcodes, PHP-Leistung, Cache-Anteile und Anfrageprotokolle –, sind dieselben Daten, die jedem MyKinsta-Nutzer mit Zugriff auf die Analysen zur Verfügung stehen. Wenn alle dieselben Signale lesen, wird eine defekte Website zu etwas, das das Team gemeinsam diagnostiziert, anstatt darüber zu streiten.
Das verändert auch die Art und Weise, wie Teams mit dem Support interagieren. Dieser Leitfaden führt dich durch die in MyKinsta verfügbaren Diagnosetools, erklärt, was jedes einzelne anzeigt, wann man sie einsetzt und wie man sie als Teil eines gemeinsamen Workflows nutzt – statt als Einzelaktion zur Fehlerbehebung.
Warum Leistungsprobleme zu Schuldzuweisungen werden
Bei einer modernen WordPress-Website trägt selten eine einzige Person die Verantwortung für alles. Entwickler verwalten den Code. Marketingfachleute führen Kampagnen durch. Agenturen oder Freiberufler kümmern sich um das Hosting. Jedes Team macht seine Arbeit; das Problem ist, dass sich ihre Einblicke nicht überschneiden.
Wenn eine Website ausfällt, verwandelt diese Lücke in der Sichtbarkeit ein technisches Problem still und leise in ein persönliches:
- Entwickler überprüfen den Code, aber nicht den Server. Ihr Blickfeld endet an der Anwendungsebene, sodass eine serverseitige Ursache für sie unsichtbar bleibt.
- Marketingleute sehen den Traffic, aber nicht die Datenbank. Ein Kampagnen-Spike erscheint ihnen als offensichtlicher Auslöser, weil es die einzige Variable ist, die sie messen können.
- Agenturen nehmen die Beschwerde entgegen, verfügen aber über keinerlei Daten. Sie werden eher zu einer Vermittlungsinstanz zwischen den Parteien als zu einer Quelle für Antworten.
Ohne gemeinsamen Bezugspunkt geht jede Partei davon aus, dass die Ursache bei jemand anderem liegt. Viele Hosting-Plattformen verstärken dieses Muster stillschweigend, indem sie Diagnosedaten innerhalb des Support-Teams zurückhalten. Du eröffnest ein Ticket und wartest, während jemand anderes die Logs auswertet, auf die du keinen Zugriff hast.
Kinsta verfolgt den gegenteiligen Ansatz. Schauen wir uns nun an, welche Tools du zuerst nutzen solltest und wie du sie als gemeinsamen Workflow einsetzt – statt als Einzelmaßnahme.
Was das MyKinsta-Analyse-Dashboard anzeigt, wenn etwas schiefgeht
Wenn eine Website nicht richtig funktioniert, besteht die erste Aufgabe darin, festzustellen, um welche Art von Problem es sich handelt. Langsame, fehlerhafte und überlastete Websites erfordern jeweils unterschiedliche Maßnahmen. Eine falsche Diagnose – etwa ein Caching-Problem als Serverproblem oder einen Fehleranstieg als Traffic-Problem zu behandeln – verschwendet die Zeit aller Beteiligten.
Im Bereich „Analytics“ von MyKinsta beginnt diese Diagnose.
Im Bereich Analytics von MyKinsta findest du Daten auf Unternehmensebene. Für eine einzelne Website gehst du zu Websites > „Websitename“ > Analytics. Unabhängig davon stehen jedem Nutzer mit Zugriff auf die Analytics dieselben Berichte zur Verfügung.
Überprüfe, ob die Website tatsächlich Fehler zurückgibt
Stell vor allem erst einmal fest, ob die Website wirklich ausfällt oder nur langsam ist. Das hat unterschiedliche Ursachen und erfordert unterschiedliche Lösungen – und wenn man beides verwechselt, fangen die Schuldzuweisungen an.
Die Registerkarte Response beantwortet diese Frage. Das zentrale Diagramm, die Aufschlüsselung der Antwortcodes, zeigt die Verteilung der HTTP-Statuscodes, die deine Website im ausgewählten Zeitraum zurückgegeben hat.
So deutet eine Häufung von 5xx-Codes auf Probleme mit dem Server oder der Anwendung hin, während 4xx-Codes auf Probleme beim Zugriff auf Ressourcen hindeuten. Zwei weitere Diagramme ermöglichen dir eine genauere Analyse:
- Die Aufschlüsselung der 500-Fehler unterscheidet einen generischen 500-Fehler von einem 502 „Bad Gateway“ oder einem 503 „Service Unavailable“, die auf unterschiedliche Ursachen hinweisen.
- Die Aufschlüsselung der 400er-Fehler unterteilt die clientseitigen Codes und unterscheidet eine Flut von 404er-Fehlern von den anderen Antworten, die auf Probleme bei der Authentifizierung, den Berechtigungen oder der Ratenbegrenzung hinweisen.
Da jeder Nutzer mit Zugriff auf die Analysedaten dieselbe Aufschlüsselung sieht, kannst du direkt an der konkreten Fehlerursache arbeiten, anstatt lange zu rätseln.
Unterscheide eine langsame Website von einer fehlerhaften
Eine Website, die in sechs Sekunden lädt, und eine, die 500-Fehler zurückgibt, fühlen sich für einen frustrierten Besucher ähnlich an, haben aber völlig unterschiedliche Ursachen. Auf der Registerkarte Performance kannst du sie voneinander unterscheiden.
Einige Berichte hier lohnen sich bei jeder Untersuchung einer langsamen Website:
- Die durchschnittliche PHP- und MySQL-Antwortzeit zeigt, wie lange die Anwendung braucht, um jede nicht zwischengespeicherte Anfrage aufzubauen und abzufragen. Ein plötzlicher Anstieg ist in der Regel eher das erste Anzeichen für eine Leistungsminderung als für ein Infrastrukturproblem.
- Der PHP-Durchsatz zeigt an, wie viele Anfragen in diesem Zeitraum ausgeführt wurden. Wenn eine Verlangsamung eher mit einem Durchsatzanstieg als mit einer Codeänderung zusammenfällt, ist die wahrscheinliche Ursache die Auslastung und kein Fehler.
- Die AJAX-Nutzung deckt Spitzen bei der „admin-ajax.php“-Aktivität auf – eine häufige und leicht zu übersehende Belastung der Backend-Ressourcen, die durch Plugins und angemeldete Nutzer verursacht wird, die Hintergrundaufgaben ausführen.
- Unter Top maximum upstream time werden die langsamsten einzelnen Pfade aufgelistet, sodass du direkt auf die Seite oder den Endpunkt hinweisen kannst, die den Durchschnittswert der Website in die Höhe treiben, anstatt zu raten.
Zusammen geben dir diese Informationen Aufschluss darüber, ob der nächste Schritt darin besteht, die Anwendung zu optimieren oder einen Ausfall zu eskalieren.
Überprüfe, wie viel von der Website zwischengespeichert wird
Eine Website kann sich aus Gründen langsam anfühlen, die nichts mit dem Code oder der Infrastruktur zu tun haben: Zu wenig davon wird aus dem Cache bereitgestellt. Wenn die Cache-Quote sinkt, verarbeitet der Server Anfragen, die er eigentlich nicht bearbeiten müsste, was die Antwortzeiten erhöht. Das ist einer der häufigsten Gründe für die Frage „Liegt es am Host?“, und fast nie ist der Host schuld.
Der Abschnitt Cache zeigt, wie Anfragen über die verschiedenen Caching-Ebenen von Kinsta abgewickelt werden.
Jede Anfrage wird in einen von drei Zuständen eingeteilt:
HITbedeutet, dass Kinsta die Anfrage aus dem Cache bedient – genau das, was du für den Großteil des Datentraffics willst.BYPASSbedeutet, dass eine Regel oder ein Konflikt die Anfrage aus dem Cache fernhält.MISSbedeutet, dass der Inhalt noch nicht zwischengespeichert ist, dies aber nach der ersten Anfrage geschehen wird.
Das Cache-Diagramm einer gut funktionierenden Website besteht überwiegend aus HITs. Wenn die BYPASS-Rate steigt, listet der Bericht Top Server-Cache-Bypässe die spezifischen Pfade auf, die den Cache umgehen.
Manche Umgehungen sind kein Problem (wie zum Beispiel die WordPress-Anmeldeseite, die nie zwischengespeichert wird). Taucht jedoch eine zwischenspeicherbare Seite in dieser Liste auf, deutet das auf einen Plugin-Konflikt oder ein Problem mit den Caching-Regeln hin. Wenn du diese Berichte liest, während du eine langsame Seite beobachtest, kannst du sehen, ob die Seite zwischengespeichert ist, anstatt einfach anzunehmen, dass der Host das Problem ist.
Finde heraus, was Ressourcen verbraucht
Wenn eine Website keine Fehler zurückgibt, aber mehr Bandbreite oder Kapazität beansprucht, als sie sollte, findest du die Ursache im Bericht Top-Anfragen. Ressourcenprobleme sind am schwersten einzugrenzen: Eine Bandbreitenüberschreitung oder eine Verlangsamung unter Last geht in der Regel nicht mit einem Fehlercode einher.
Drei Berichte machen aus diesem Rätselraten eine konkrete Erkenntnis:
- Serverbandbreite zeigt, welche URLs die meisten Daten direkt von deinem Ursprungsserver abrufen.
- Gesamtbandbreite addiert die vom CDN und vom Edge-Cache bereitgestellten Daten, sodass du das gesamte Volumen jeder Anfrage siehst.
- Aufrufe zeigt die am häufigsten angeforderten Ressourcen unabhängig von ihrer Größe an, wodurch eher ein Endpunkt mit konstanter Auslastung als eine einzelne große Datei sichtbar wird.
Zusammen zeigen sie, ob ein Ressourcen-Spike auf eine übergroße Mediendatei, einen außer Kontrolle geratenen Endpunkt oder einen Crawler zurückzuführen ist, der denselben Pfad tausende Male aufruft. Von da an besteht die Lösung in der Regel darin, das Asset zu optimieren, es über ein CDN zu leiten oder das Problem am Endpunkt zu beheben.
Wenn Crawler- oder Bot-Traffic hinter dem Anstieg steckt, kannst du mit Kinstas Bot-Schutz nicht-menschlichen Traffic direkt über MyKinsta identifizieren, klassifizieren und blockieren – ganz ohne Plugin oder Support-Ticket.
Wie APM ein Leistungsproblem bis zu seiner Ursache zurückverfolgt
Die Analytics-Berichte zeigen dir, was auf einer Website passiert. Das APM-Tool von Kinsta verrät dir, warum. Während Analytics dir anzeigt, dass die PHP-Antwortzeit um 14 Uhr sprunghaft angestiegen ist, zeigt dir APM, welche Plugin-Funktion, Datenbankabfrage oder welcher externe API-Aufruf dafür verantwortlich war.
APM ist in jedem Kinsta-Tarif enthalten und läuft direkt in MyKinsta.
Führe APM als Sitzung aus, nicht als Dauerbetrieb
Im Gegensatz zum Analytics-Dashboard, das kontinuierlich im Hintergrund Daten aufzeichnet, belastet der APM-Agent die CPU und den Arbeitsspeicher deines Servers, während er Daten sammelt. Kinsta empfiehlt, ihn nur zu nutzen, wenn du gerade aktiv ein Problem diagnostizierst.
Um eine Sitzung zu starten, geh zu Websites > „Websitename“ > APM, klick auf APM aktivieren und wähle dann ein Überwachungsfenster aus – 2, 4, 12 oder 24 Stunden. APM deaktiviert sich am Ende des Zeitraums automatisch.
Das bedeutet, du hast einen einfachen Arbeitsablauf:
- Starte APM, wenn du ein Problem vermutest oder eines reproduzieren kannst, damit deine Website im Normalbetrieb nicht zusätzlich belastet wird.
- Wähle ein Zeitfenster, das das Problem abdeckt, reproduziere dann das Problem oder warte, bis es erneut auftritt, damit das Tool es mit Live-Daten erfasst.
- Lies die Ergebnisse aus, sobald sich Daten angesammelt haben, und schalte APM dann aus, wenn du fertig bist.
APM-Ergebnisse auswerten
APM organisiert die gesammelten Daten auf vier Registerkarten: Transaktionen, WordPress, Datenbank und Extern.
Beginne mit Transaktionen, um die langsamsten Anfragen zu finden. Wenn du auf eine beliebige Transaktion klickst, öffnet sich eine Zeitleiste mit allen an dieser Anfrage beteiligten Prozessen, und die ressourcenintensivsten Abschnitte werden markiert. So erfährst du, ob du deine Optimierungsbemühungen auf eine langsame Datenbankabfrage, eine bestimmte Plugin-Funktion oder eine API eines Drittanbieters konzentrieren solltest.
Die Registerkarte Extern ist besonders nützlich, um den Host als Ursache auszuschließen. Wenn die Verlangsamung einer Transaktion auf einen externen API-Aufruf zurückzuführen ist, zeigen die APM-Daten dies eindeutig an. Das ist der Unterschied zwischen einem Support-Ticket mit dem Hinweis „Die Seite ist langsam“ und einem, in dem steht: „Die Verlangsamung liegt in der API unseres E-Mail-Dienstanbieters, nicht beim Server.“
Wie der Log-Viewer und das Aktivitätsprotokoll eine Zeitleiste rekonstruieren
Um einen Vorfall zu beheben, muss man in der Regel wissen, was passiert ist und in welcher Reihenfolge. Zwei Einträge in MyKinsta helfen dir dabei, den zeitlichen Ablauf zu rekonstruieren: Der Log-Viewer erfasst, was die Website tut, und das Aktivitätsprotokoll erfasst, was die Nutzer tun.
Der Log-Viewer zeigt dir, was die Website meldet, nicht wie sie läuft. Auf dem Log-Bildschirm stehen für jede Website in MyKinsta drei Dateien zur Verfügung:
error.logzeichnet PHP-Fehler und -Warnungen auf – das ist die erste Anlaufstelle, um nach der Ursache für eine fehlerhafte Seite zu suchen.kinsta-cache-perf.logerfasst die Cache-Leistung und zeigt an, ob Seiten aus dem Cache bereitgestellt werden oder diesen umgehen.access.logProtokolliert jede HTTP-Anfrage, die die Website erreicht – hier kannst du Traffic-Muster und wiederkehrende 404-Fehler nachverfolgen.
Der integrierte Viewer lädt bis zu 20.000 Zeilen und verfügt über ein Suchfeld, mit dem du nach beliebigen Textzeichenfolgen filtern kannst. Die Protokolle können auch über den Dateimanager in MyKinsta heruntergeladen werden, falls du sie in einem externen Tool bearbeiten möchtest.
Das Aktivitätsprotokoll: Was die Nutzer getan haben
Das Aktivitätsprotokoll erfasst jede Aktion, die in MyKinsta für eine Website von einem beliebigen Nutzer durchgeführt wurde, in chronologischer Reihenfolge.
Du findest die Aktivitätsprotokolle unter Websites > „Webseitenname“ > Benutzeraktivität. Jeder Eintrag zeigt dir die Aktion in einfacher Sprache, den Benutzer, einen Zeitstempel und ein Statussymbol an. Hier kennzeichnet ein grünes Häkchen den Erfolg und ein rotes Ausrufezeichen einen Fehler.
In Kombination mit anderen Protokollen hilft es dir bei der Fehlerdiagnose. Mit einer gefüllten error.log-Datei kannst du beispielsweise das Aktivitätsprotokoll öffnen, es auf dasselbe Fenster eingrenzen und alle zugehörigen Aktionen finden.
Wie die Verfügbarkeitsüberwachung für gemeinsames Bewusstsein sorgt
Die oben genannten Tools sind reaktiv. Die Verfügbarkeitsüberwachung macht die Erkennung proaktiv: Anstatt erst durch eine Kundenbeschwerde von einem Problem zu erfahren, werden du und Kinsta gleichzeitig darauf aufmerksam.
Kinsta überwacht jede Website auf der Plattform etwa 480 Mal am Tag. Wenn du die Überwachungsbenachrichtigungen unter Benutzereinstellungen > Benachrichtigungen aktiviert hast, erhältst du eine E-Mail zu Bereichen, die besondere Aufmerksamkeit erfordern:
- Website-Fehler weisen auf ein Problem hin, das auf der Website selbst erkannt wurde.
- SSL-Fehler weisen auf ein Zertifikats- oder Konfigurationsproblem hin, bevor es Besucher abschreckt.
- Domain-Ablauf weist auf eine ablaufende Domain hin, bevor sie verfällt.
E-Mails werden erst nach drei aufeinanderfolgenden fehlgeschlagenen Überprüfungen ausgelöst und nicht schon nach der ersten – so werden vorübergehende Störungen herausgefiltert, die dich sonst mit Fehlalarmen überschwemmen würden.
SIX15 Solutions betreibt mehr als 30 Kunden-Websites mit dieser Überwachung, wobei der Wert weniger in der Überprüfung selbst liegt als darin, wie oft Probleme behoben werden, bevor ein Kunde sie bemerkt.
Ich betreibe derzeit über 30 Kunden-Websites in meinem Agency-Tarif, von kleinen Marketing-Websites bis hin zu vollwertigen Mitgliederportalen mit Tausenden von Nutzern – und das ohne Probleme oder Ausfallzeiten.
Allerdings ist nicht jede Warnung ein Ausfall. Planlimit-Warnungen benachrichtigen dich, wenn du die Nutzungsgrenzen deines Tarifs erreichst – das ist eine effektive Frühwarnstufe. So kannst du anhand deiner Analysen erkennen, warum du an ein Limit stößt, z. B. durch eine Kampagne, die mehr Traffic generiert als prognostiziert, oder durch Crawler- oder Bot-Aktivitäten.
Gemeinsame Daten beenden die Schuldzuweisungen
Eine ausgefallene Website kostet am meisten Zeit damit, die Verantwortung und Zuständigkeit zu klären, statt das Problem zu beheben. Die Analytics von MyKinsta zeigen an, ob eine Website langsam, ausgefallen oder überlastet ist. Mit dem APM-Tool, dem Log-Viewer, dem Aktivitätsprotokoll, der Verfügbarkeitsüberwachung und vielem mehr kannst du sicherstellen, dass alle von einem Problem erfahren und sich sofort an die Arbeit machen können, ohne in einer Ticket-Warteschlange zu hängen.
Das Ziel ist es, diese Ansichten als gemeinsamen Arbeitsablauf zu betrachten. Wenn jedes Teammitglied den richtigen Zugriff auf die Analysen hat, könnt ihr euch auf die Berichte einigen, anhand derer ihr arbeitet, bevor jemand ein Ticket eröffnet. So bleibt das Gespräch eine Diagnose und wird nicht zum Streit.
Wenn du Websites verwaltest, für die mehrere Teams gemeinsam verantwortlich sind, gibt das Managed-WordPress-Hosting von Kinsta jedem dieser Teams einen Platz am Diagnosetisch. Wenn du Kunden-Websites in großem Umfang verwaltest, lohnt es sich, das Agency-Partner-Programm wegen der darin enthaltenen Tools für gemeinsamen Zugriff und gemeinsame Verwaltung in Betracht zu ziehen.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
