Beispielbericht: anonymisierte, echte Website
Dieser Beispielbericht zeigt, wie ein Website-Check aussieht. Wir haben zwei echte Websites gemessen und alle identifizierenden Angaben entfernt. Zu jeder sehen Sie das Tempo am Smartphone, die Grundlagen für Suche und KI sowie die Kontaktwege, gefolgt von dem, was wir tun würden. Die beiden Beispiele heißen Website A und Website B.
So lesen Sie diese Beispiele
Beide sind echte Websites. Wir haben Domain, Marke, Logos und alles entfernt, was sie identifizieren könnte. Die Werte wurden am 5. Oktober 2026 mit Lighthouse unter Laborbedingungen gemessen: „Mobil“ bedeutet ein emuliertes Smartphone mit simulierter, langsamer 4G-Verbindung.
Beide Websites sind in gutem Zustand. Ein guter Check sagt auch, was man in Ruhe lassen sollte. Laborwerte sind keine Felddaten echter Besucher.
Schnell, klar und einen Schritt vom Kontaktformular entfernt
am Smartphone
Beschreibung
Zugang
wege
- Hauptinhalt erscheint am Smartphone nach 1,23 s
- Such- und KI-Crawler sind erlaubt
- Zuerst beheben: kein Anfrageformular auf der Startseite
Das würden wir für Website A tun
Das Tempo in Ruhe lassen.
Ein mobiler Wert von 100 und 1,23 s bis zum größten Inhalt sind gut. Änderungen hier würden mehr riskieren, als sie einbringen.
Ein kurzes Anfrageformular auf der Startseite ergänzen.
Besucher können bisher nur Links nutzen. Ein kurzes Formular erspart einen Schritt, wenn jemand über einen QR-Code an einem Messestand kommt.
Die Content Security Policy verschärfen.
Sie erlaubt derzeit unsicheres Inline-Skripting und eval. Wir würden zuerst eine strengere Richtlinie testen und sie dann durchsetzen.
Messen, bevor das HTML zwischengespeichert wird.
Die Serverantwort von 190 ms könnte mit einem Seiten-Cache sinken, doch bei einem Wert von 100 ist der Gewinn klein. Wir würden zuerst messen.
Gemessene Werte
| Prüfung | Was wir gemessen haben |
|---|---|
| Tempo, mobil | Performance-Wert 100, größter Inhalt nach 1,23 s, Layout-Verschiebung 0,000, Blockierzeit 0 ms, erster Inhalt nach 1,04 s |
| Tempo, Desktop | Performance-Wert 100, größter Inhalt nach 0,37 s |
| Serverantwort | 190 ms; die Seite wird mit No-Store-Caching gesendet, sodass jeder Aufruf den Server erreicht |
| Seitengewicht | Etwa 14 KB HTML komprimiert, 3 Bilder (alle SVG, alle mit Beschreibung und Größenangabe) |
| Titel und Beschreibung | Titel 57 Zeichen, Beschreibung 158 Zeichen, beide innerhalb der üblichen Anzeigegrenzen |
| Überschriften | Eine H1, 14 H2, 23 H3 |
| Strukturierte Daten | Organization, WebSite, WebPage und FAQPage mit 6 Fragen |
| Robots und KI-Zugang | Such- und KI-Crawler sind erlaubt, Sitemap angegeben, llms.txt vorhanden, eine fehlende URL liefert ein echtes 404; die von uns getesteten KI-Crawler erhalten die Seite (HTTP 200) |
| Kontaktwege | Kontaktseite, E-Mail-, Telefon- und WhatsApp-Links; kein Formular auf der Startseite |
| Sicherheits-Header | HSTS, nosniff, Referrer-Policy und Frame-Optionen gesetzt; die Content Security Policy erlaubt unsicheres Inline-Skripting und eval |
| Skripte von Drittanbietern | Keine im HTML der Seite |
Schnell und leicht erreichbar, mit langen Suchausschnitten
am Smartphone
Beschreibung
Zugang
wege
- Hauptinhalt erscheint am Smartphone nach 1,73 s
- Such- und KI-Crawler sind erlaubt
- Zuerst beheben: Titel und Beschreibung überschreiten die üblichen Grenzen
Das würden wir für Website B tun
Den Titel auf 60 Zeichen und die Beschreibung auf 160 kürzen.
Beide überschreiten die üblichen Grenzen, sodass Suchergebnisse sie abschneiden können.
Auf das erste Rendern schauen, nicht auf Bilder.
Größter Inhalt (1,73 s) und erster Inhalt (1,72 s) erscheinen fast gleichzeitig, die Wartezeit liegt also vor dem ersten Rendern. Die 41 KB Inline-CSS würden wir als Erstes untersuchen.
Die Content Security Policy vom Report-only-Modus in den erzwungenen Modus überführen
nachdem wir ihre Berichte gelesen haben.
Das Analytics-Beacon erst nach Einwilligung laden
sofern die Region des Besuchers es verlangt. Wir würden dies anhand der Einwilligungseinrichtung der Website prüfen.
Gemessene Werte
| Prüfung | Was wir gemessen haben |
|---|---|
| Tempo, mobil | Performance-Wert 99, größter Inhalt nach 1,73 s, Layout-Verschiebung 0,000, Blockierzeit 0 ms, erster Inhalt nach 1,72 s |
| Tempo, Desktop | Performance-Wert 100, größter Inhalt nach 0,55 s |
| Serverantwort | 176 ms; das HTML ist als privat gekennzeichnet, sodass gemeinsame Caches es nicht speichern |
| Seitengewicht | Etwa 20 KB HTML komprimiert (99 KB unkomprimiert), davon etwa 41 KB unkomprimiert Inline-CSS; keine Bilder auf der Startseite |
| Titel und Beschreibung | Titel 66 Zeichen, Beschreibung 168 Zeichen, beide über den üblichen Anzeigegrenzen |
| Überschriften | Eine H1, 8 H2, 6 H3 |
| Strukturierte Daten | Organization, Person, WebSite, ProfessionalService und FAQPage mit 6 Fragen |
| Robots und KI-Zugang | Such- und KI-Crawler sind erlaubt, Sitemap angegeben, llms.txt vorhanden, eine fehlende URL liefert ein echtes 404; die von uns getesteten KI-Crawler erhalten die Seite (HTTP 200) |
| Kontaktwege | Kontaktseite, E-Mail, 4 Telefon-Links, 3 WhatsApp-Links und 2 Formulare auf der Startseite |
| Sicherheits-Header | HSTS (180 Tage, ohne Subdomains), nosniff, Referrer-Policy und Frame-Optionen gesetzt; die Content Security Policy läuft im Report-only-Modus und wird nicht erzwungen |
| Skripte von Drittanbietern | 1 externer Host, ein CDN-Analytics-Beacon, im HTML der Seite geladen |
Was das für Ihren Check bedeutet
Ihr eigenes Ergebnis folgt derselben Logik: was wir gemessen haben, was es bedeutet und was wir zuerst beheben würden. Wir schreiben es in einfacher Sprache und senden es innerhalb von zwei Werktagen per E-Mail.