Eine brauchbare Website-Audit-Checkliste ist fest definiert und nachprüfbar: dieselben Checks, dieselben Schwellenwerte, bei jeder Website. webvise hat die eigene als kostenloses Tool veröffentlicht. Der WP Health Report prüft jede öffentliche URL in rund 60 Sekunden mit 13 benannten Performance-Checks, 5 Core Web Vitals und 3 regelbasierten Sicherheits-Flags, ganz ohne Zugang, Plugin oder Installation.
Jeder Check in diesem Artikel stammt direkt aus dem Quellcode des Tools, bis hin zum Schwellenwert, der entscheidet, ob ein Befund in den Report kommt. Die meisten Audit-Checklisten enden in Ermessensfragen, etwa der Bewertung des eigenen Nutzenversprechens. Ein Check, der bei zwei Durchläufen unterschiedlich ausfallen kann, ist eine Meinung.
Wer nach einer Website Audit Checkliste sucht, will etwas, das sich heute ohne Agentur durchführen lässt. Dieser Artikel liefert die 60-Sekunden-Pipeline, die 13 Checks mit ihrer 0,9-Regel, die 5 Vitals mit grünen Schwellenwerten, die WordPress-Erkennung und ein manuelles 30-Minuten-Runbook.
- Der [WP Health Report](/wp-health-report) ist die automatisierte Version dieser Checkliste. Er läuft komplett auf öffentlichen Daten und braucht rund 60 Sekunden pro Website.
- Nur Lighthouse-Audits mit einem Score unter 0,9 zählen als Befund. Der Report sortiert sie nach dem schlechtesten Wert zuerst und zeigt die Top 5 mit geschätztem Einsparpotenzial.
- 5 Core Web Vitals kommen aus dem Mobile-Lauf: FCP, LCP, TBT, CLS und Speed Index.
- WordPress wird über 5 Merkmale erkannt, PHP über 3. Ein Treffer genügt, um das passende Sicherheits-Flag auszulösen.
- Jeder Schritt lässt sich in rund 30 Minuten von Hand reproduzieren. Das Runbook steht in der zweiten Hälfte dieses Artikels.
So funktioniert die 60-Sekunden-Pipeline
Das Tool validiert die URL und ruft dann Googles PageSpeed Insights API v5 zweimal parallel auf: ein Mobile-Lauf, ein Desktop-Lauf, nur die Kategorie Performance, jeweils mit 20 Sekunden Timeout. Danach folgen Fingerprinting, Befund-Extraktion, Vitals und die Sicherheitsregeln. Die PageSpeed-Aufrufe machen den Großteil der Laufzeit aus, deshalb steht der komplette Report nach rund 60 Sekunden.
Befunde und Vitals stammen beide aus dem Mobile-Lauf, und das ist Absicht. Mobiles Lighthouse drosselt CPU und Netzwerk, liefert also den strengeren der beiden Scores, und Google indexiert zuerst die mobile Version. Der Desktop-Score steht als Kontext daneben.
Die 13 Performance-Checks und die 0,9-Regel
Das Tool fragt exakt 13 Lighthouse-Audits ab, alle stehen in der Tabelle unten. Ein Audit wird erst dann zum Befund, wenn sein Score unter 0,9 fällt. Alles darüber passiert den Check ohne Meldung. Die Befunde werden nach dem schlechtesten Wert zuerst sortiert, und der Report zeigt die Top 5 mit geschätztem Einsparpotenzial in Millisekunden, wo Lighthouse es liefert.
Ich habe die Ausgabe bewusst bei 5 Befunden gedeckelt. Eine Liste mit 30 Punkten liest sich wie Rauschen und wird ignoriert, während 5 Befunde mit dem schlimmsten zuoberst als Arbeitsauftrag funktionieren, den ein Entwickler heute anfangen kann.
| Check (Lighthouse-Audit-ID) | Was er meldet |
|---|---|
| render-blocking-resources | CSS und Skripte, die den ersten Seitenaufbau verzögern |
| unused-javascript | Ausgeliefertes JavaScript, das die Seite nie ausführt |
| unused-css-rules | Geladene Stylesheets ohne angewendete Regeln |
| unminified-javascript | Skripte ohne Minifizierung |
| unminified-css | Stylesheets ohne Minifizierung |
| total-byte-weight | Gesamtgewicht der Seite über alle Requests |
| server-response-time | Langsame Serverantwort (Time to First Byte) |
| dom-size | Aufgeblähter DOM-Baum, oft durch Page Builder |
| redirects | Weiterleitungsketten vor der finalen URL |
| uses-text-compression | Fehlende gzip- oder Brotli-Kompression |
| uses-optimized-images | Bilder in Übergröße oder in veralteten Formaten |
| offscreen-images | Bilder unterhalb des Sichtbereichs, die sofort laden |
| uses-responsive-images | Ein großes Bild für alle Bildschirmgrößen |
WordPress-Websites scheitern typischerweise an denselben drei Checks: render-blocking-resources durch Theme-Stylesheets, unused-javascript durch Page Builder und server-response-time durch PHP-Hosting ohne Caching. Die Mechanik dahinter steht in Warum WordPress auf dem Smartphone langsam ist.
Die 5 Core Web Vitals im Report
Der Report liest 5 Metriken aus dem Mobile-Lauf: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift und Speed Index. Jede kommt mit ihrem Rohwert und einem Score von 0 bis 100.
| Metrik | Was sie misst | Grüner Schwellenwert (mobil) |
|---|---|---|
| FCP | Erster sichtbarer Inhalt auf dem Bildschirm | 1,8 s oder weniger |
| LCP | Größtes gerendertes Element | 2,5 s oder weniger |
| TBT | Blockierter Main Thread beim Laden | 200 ms oder weniger |
| CLS | Visuelle Layout-Verschiebungen | 0,1 oder weniger |
| Speed Index | Wie schnell sich der sichtbare Inhalt aufbaut | 3,4 s oder weniger |
Googles Ranking-Set besteht aus LCP, CLS und INP. Labor-Läufe können INP nicht messen, weil dafür echte Nutzereingaben nötig sind, also springt TBT als Labor-Näherung ein. Steht das mobile LCP auf Rot, gehört es zuerst repariert: Es ist Ranking-Faktor und zugleich die Verzögerung, die Besucher tatsächlich spüren.
WordPress-Erkennung und die 3 Sicherheits-Flags
Für das Fingerprinting lädt das Tool die Seite einmal und prüft 5 WordPress-Merkmale: wp-content-Pfade, wp-includes-Pfade, ein Generator-Meta-Tag mit WordPress, einen x-powered-by-Header mit WordPress und einen wp-json-Verweis im Link-Header. Ein Treffer genügt.
Die PHP-Erkennung nutzt 3 Merkmale: einen WordPress-Treffer, denn WordPress läuft auf PHP, einen x-powered-by-Header mit PHP oder .php-Dateiverweise im Markup. Schlägt die Fingerprint-Anfrage fehl, meldet das Tool nichts, statt zu raten.
Die 3 Sicherheits-Flags sind Regeln mit exakten Auslösern. "Keine HTTPS-Verschlüsselung" greift, wenn die URL nicht mit https beginnt. "Angriffsfläche WordPress-Plugin-Ökosystem" greift bei jedem WordPress-Treffer. "Serverseitige PHP-Angriffsfläche" greift bei jedem PHP-Treffer.
Ein Flag ist ein Anlass, genauer hinzusehen, und der Report sagt das auch, statt Regeln als Schwachstellen-Scan zu verkaufen. Was Plugin-Exposition in der Praxis kostet, steht in WordPress-Sicherheitsrisiken.
Die manuelle Version: 30 Minuten, 6 Schritte
Das komplette Audit lässt sich mit Browser und Terminal reproduzieren. Gleiche Checks, gleiche Schwellenwerte, gleiche Reihenfolge.
- PageSpeed zweimal laufen lassen. pagespeed.web.dev öffnen, die wichtigste Seite testen und zuerst den Mobile-Tab lesen. Performance-Score und die 5 Vitals notieren.
- Die 0,9-Regel anwenden. Die 13 Checks aus der Tabelle oben durchgehen und jeden als Befund markieren, den PageSpeed unter Diagnostics auflistet.
- Nach dem schlechtesten Wert sortieren, 5 behalten. Befunde nach geschätztem Einsparpotenzial ordnen und alles ab Platz 6 ignorieren. Das ist der Arbeitsauftrag.
- Den eigenen Stack fingerprinten. Den Seitenquelltext öffnen und nach wp-content, wp-includes und generator suchen.
- Die Header prüfen. `curl -sI https://ihredomain.de` ausführen und die Header x-powered-by und link lesen.
- Die Sicherheits-Flags auszählen. Fehlendes https in der Adresszeile, ein WordPress-Treffer oder ein PHP-Treffer setzen je ein Flag.
Das ist die gesamte Checkliste. Der WP Health Report automatisiert alle 6 Schritte in rund 60 Sekunden und schickt die Befunde auf Wunsch per E-Mail.
Wo die Checkliste endet
Das Audit bewertet, was sich aus öffentlichen Daten bewerten lässt: Performance, Vitals und Stack-Exposition. Texte, Conversion-Pfade und Designqualität brauchen einen Menschen, und eine Checkliste, die dort Scores vortäuscht, wird zur Meinung mit Zahlen dran.
Ein Report mit WordPress-Merkmalen neben einem Mobile-Score unter 50 deutet meist auf eine strukturelle Obergrenze. Die versteckten Kosten von WordPress rechnet vor, was der Betrieb dieses Setups kostet. Steht ein Neuaufbau im Raum, übernimmt die WordPress-Migration von webvise das komplett, mit im Schnitt 3 Wochen bis zum Launch über die webvise-Projekte hinweg.
webvise hat den WP Health Report als Einstiegsschritt der eigenen Audit-Arbeit gebaut, und das Tool läuft innerhalb von webvise.io, einer Website, die selbst zu 100 % mit Claude Code KI-entwickelt ist. Testen Sie Ihre Website unter wp-health-report, oder melden Sie sich, dann gehe ich die Befunde mit Ihnen durch.