Das Werkzeug unten ruft die öffentliche Fassung einer einzelnen Adresse ab und sagt, was daraus folgt. Es meldet sich nicht an, scannt kein Netz und rät nicht. Es liest dasselbe wie der Browser Ihres Besuchers: Statuscode nach Weiterleitungen, Header, HTML und jene Dateien, die dieses HTML vor dem ersten Bildaufbau anfordert. Diese Dateien lädt es wirklich und wiegt sie, statt zu schätzen.
Website-Check
Sehen Sie, was Ihre Website öffentlich preisgibt
Geben Sie die Adresse einer Website an, die Sie betreiben. Wir rufen sie so ab, wie es ein Browser täte, und zeigen, was daraus folgt, zusammen mit dem, was wir genau gelesen haben.
Was wir prüfen
Response-Header, Zeit bis zum ersten Byte, Titel und Beschreibung, die kanonische Adresse, Überschriften, strukturierte Daten, Bilder, robots.txt und die Sitemap, bei WordPress zusätzlich, was der Quelltext über installierte Plugins verrät. Zusätzlich laden wir die Ressourcen, die das erste Rendern blockieren, und summieren ihr tatsächliches Gewicht.
Was wir nicht geprüft haben
- der Administrationsbereich und alles hinter einem Login
- die Datenbank, ihre Größe und ihr Zustand
- Backups, ob es sie gibt und ob sie sich zurückspielen lassen
- Plugin-Versionen im Abgleich mit einer Schwachstellendatenbank
- wie sich die Seite für eingeloggte Nutzer verhält
- alle Seiten außer der einen angegebenen Adresse
Was hier tatsächlich gemessen wird
Die erste Ebene sind eigene HTTP-Anfragen von einem Cloudflare-Netzrand: Zeit bis zum ersten Byte, Statuscode nach aufgelösten Weiterleitungen, Sicherheitsheader, Cache-Header und Komprimierung. Die zweite Ebene ist das HTML selbst, aus dem sich Titel, Meta-Beschreibung, Canonical, Anzahl der Überschriften erster Ebene, JSON-LD-Blöcke, Sprachattribut und die Art der Bildeinbindung ablesen lassen.
Die dritte Ebene ist das Startgewicht der Seite, und sie verändert das Gespräch am häufigsten. Der Check sammelt aus dem Head alle Stylesheets und alle Skripte ohne defer, also genau das, was ein Browser fertig geladen haben muss, bevor er etwas zeichnen kann. Danach lädt er sie und nennt die echte Kilobyte-Zahl, getrennt nach CSS und JavaScript, mit der Zeit der langsamsten Datei und der Liste der fremden Domains, aus denen sie kommen.
Bei WordPress kommt hinzu, was systembedingt öffentlich ist und Betreiber trotzdem überrascht. Pfade zu Plugin- und Theme-Dateien verraten, was installiert ist und in welcher Version, denn die Versionsnummer steht meist in der Stylesheet-Adresse. Der REST-Endpunkt mit der Benutzerliste antwortet ohne Anmeldung, sofern ihn niemand geschlossen hat. Die Datei xmlrpc.php antwortet oft weiterhin, obwohl die meisten Installationen sie für nichts mehr brauchen.
Warum es hier keine Punktzahl gibt
Das ist eine Entscheidung, keine Lücke. Eine Punktzahl lädt genau eine Anschlussfrage ein, nämlich was nun zu tun sei, und die ehrliche Antwort darauf ist ein weiteres Audit. Gewicht hat dieses Problem nicht. Neunzehn blockierende Anfragen ist eine Zahl, die man sinken sehen kann. Ein Megabyte JavaScript vor dem ersten Bildaufbau zeigt auf ein konkretes Plugin. Elf Anfragen aus zwei fremden Domains zeigen meist auf einen Schriftdienst und einen Tag-Manager, und beides hat jemand entschieden und kann es zurücknehmen.
Diese Ebene hat eine Decke, und die gehört benannt. Gemessen werden Gewicht und Antwortzeit, nicht das Erlebnis Ihrer Nutzer. Das ist keine Core-Web-Vitals-Messung und ersetzt keine. Felddaten sammelt Google achtundzwanzig Tage lang bei echten Besuchern, und sie gehören Ihnen bereits, kostenlos, in der Google Search Console im Bericht zu den Core Web Vitals. Wer wissen will, wie sich der Checkout auf einem Mobilgerät im schwachen Netz anfühlt, findet nur dort eine Antwort. Unsere Zahlen sagen, welcher Teil der Seite dieses Ergebnis verursacht.
Was der Check nicht sehen kann
Die Liste des Unerreichbaren ist kurz und sollte bekannt sein, bevor jemand das Ergebnis für ein Gesamtbild hält. Der Check betritt den Administrationsbereich nicht und weiß daher nichts über Konten, Rollen oder darüber, wer sich zuletzt von einer fremden Adresse angemeldet hat. Er sieht die Datenbank nicht und sagt daher nicht, ob die Tabellen an liegengebliebenen Transients anschwellen. Er prüft keine Backups, denn Backups sind per Definition nicht öffentlich. Er gleicht erkannte Plugin-Versionen nicht mit einer Schwachstellendatenbank ab, eine gelesene Version ist also ein Fakt und keine Risikobewertung. Und er prüft genau die eine angegebene Adresse, nicht die ganze Website.
Die angemeldete Ansicht ist eine eigene Lücke. WordPress liefert angemeldeten Besuchern einen völlig anderen Satz Datenbankabfragen und schaltet für sie den Seiten-Cache meist ab. Ein Shop, der einem Gast in wenigen hundert Millisekunden antwortet, kann einem angemeldeten Kunden mit vollem Warenkorb um ein Vielfaches langsamer antworten. Ein Check von außen zeigt das nicht, und kein Werkzeug ohne Kontozugang zeigt es.
Wie die Befundklassen zu lesen sind
Befunde hoher Schwere kosten sofort Geld oder Sicherheit. Kein HTTPS auf der Zieladresse, ein robots noindex auf einer Seite, die indexiert werden soll, ein offener Endpunkt mit der Benutzerliste, vier oder mehr fehlende der fünf Sicherheitsheader, ein langsames erstes Byte. Hierher gehört auch der schwere Start: fünfzehn oder mehr blockierende Anfragen oder über ein halbes Megabyte vor dem ersten Bildaufbau. Jeder dieser Punkte hat eine konkrete Lösung, meist in der Serverkonfiguration oder in einem Plugin, das ohnehin installiert ist.
Befunde mittlerer Schwere beschreiben einen Zustand, mit dem ein Jahr ohne Ausfall vergeht, der aber langsam Vorsprung kostet. Kein Cache auf dem HTML, blockierende Dateien ohne Komprimierung, Schriften von Googles Servern statt aus der eigenen Domain, fehlende Meta-Beschreibung, kein Block mit strukturierten Daten, Bilder ohne Maße, keine Sitemap. Wer stabilen Verkehr hat, plant das in den nächsten Turnus. Wer einen Shop in der Hochsaison betreibt, zieht Komprimierung, Cache und Bilder vor, weil sie den Warenkorb am schnellsten erreichen.
Befunde niedriger Schwere sind meist Spuren des Technikstapels: WordPress-Version im Meta-Generator, Servername und Version im Header, mehrere Überschriften erster Ebene auf einer Seite, kurze Cache-Lebensdauer statischer Dateien, Bilder ohne verzögertes Laden. Nichts davon legt eine Website lahm. Solche Punkte räumt man bei anderer Arbeit mit auf, nicht statt ihrer.
Die Bestätigungen stehen daneben und für sich. Wenn das Werkzeug meldet, dass die Sicherheitsheader vollständig sind, dass das HTML aus dem Cache kam, dass strukturierte Daten vorhanden sind und der Seitenstart leicht ist, dann ist das kein Füllmaterial. Es beantwortet die Frage, die Betreiber am häufigsten stellen: hat das vorige Team seine Arbeit gemacht.
Wann die ehrliche Antwort lautet, dass nichts zu tun ist
Das kommt häufiger vor, als der Markt für Diagnosewerkzeuge nahelegt. Eine Firmenwebsite auf gutem Hosting, mit aktuellem WordPress, vollständigen Headern, sinnvollem Cache und leichtem Start braucht nichts von uns. Zeigt der Bericht nur Befunde niedriger Schwere und Bestätigungen, ist genau das der Fall. Tab schließen und in einem halben Jahr wiederkommen.
Es gibt auch den Zwischenzustand, in dem Abwarten die richtige Entscheidung ist. Wer vorige Woche Theme oder Hosting gewechselt hat, bekommt von uns bereits Zahlen zur neuen Fassung, während die Search Console noch einen Monat lang die alte beschreibt. Beauftragen Sie nichts auf Basis zweier Quellen, die zwei verschiedene Websites beschreiben. Lassen Sie erst das Zeitfenster weiterwandern.
Und der dritte Fall: ein echter Befund, der nicht Ihrer ist. Fehlender Sicherheitsheader, fehlende Komprimierung oder nicht zwischengespeichertes HTML sind häufig Hosting-Konfiguration und nicht Website-Konfiguration. Eine Nachricht an den technischen Support des Hosters erledigt das günstiger als jedes Projekt.
Was mit der eingegebenen Adresse geschieht
Wir rufen öffentliche Seiten unter der angegebenen Adresse ab, melden uns nirgendwo an und speichern nichts außer einem anonymen Zähler der Aufrufe. Der Bericht landet auf keiner Verteilerliste, denn wir fragen keine E-Mail-Adresse ab. Wer den Kontaktknopf drückt, findet das Formular mit Adresse und den drei schwersten Befunden vorausgefüllt und sieht den ganzen Text vor dem Absenden.
Wohin, wenn der Bericht etwas Echtes gezeigt hat
Wiederkehrende Befunde mittlerer Schwere bedeuten meist fehlende laufende Betreuung und nicht einen einzelnen Fehler, und dafür steht die Wartung von WordPress-Websites. Schwerer Start und langsames erstes Byte führen zur Beschleunigung einer WordPress-Website. Offener Benutzer-Endpunkt, antwortende xmlrpc.php und fehlende Header sind Material für ein WordPress Sicherheitsaudit, denn diese drei lohnen sich nicht einzeln.
