Ein einzelner Wert ohne Erklärung hilft niemandem weiter – und ein Werkzeug, das für jede Website eine scheinbar exakte Note ausgibt, verschweigt meist, was es gar nicht gemessen hat. Deshalb beschreibt diese Seite, wie wir prüfen, wie wir Befunde einordnen und wo die Grenzen einer externen Analyse liegen.
Auf einen Blick
- 48 Prüfkriterien in sechs Bereichen bilden das Prüfmodell (Version 1.0.0). Welche davon für eine Website passen und geprüft werden können, entscheiden wir je Website; der Bericht nennt, was tatsächlich geprüft wurde.
- Pixelkiez wählt bis zu sechs öffentliche Seiten aus und prüft sie persönlich. Zugangsdaten oder Installationen sind dafür nicht nötig.
- Eingeordnet wird nur, was belegt ist – mit URL, Zeitpunkt und Methode.
- Fehlende Daten führen wir als „nicht geprüft“. Sie werden nie als Mangel Ihrer Website dargestellt.
Das Prüfmodell
Die 48 Kriterien verteilen sich auf sechs Bereiche. Jeder Bereich hat ein Gewicht, mit dem er in den Pixelkiez Score eingeht:
| Bereich | Prüfkriterien | Gewicht |
|---|---|---|
| Auffindbarkeit & SEO | 10 | 25 % |
| Performance & Technik | 9 | 20 % |
| Nutzerführung & Conversion | 8 | 20 % |
| Vertrauen, Datenschutz & Inhalt | 8 | 15 % |
| Barrierefreiheit | 6 | 10 % |
| KI-Verständlichkeit | 7 | 10 % |
| Gesamt | 48 | 100 % |
Die Gewichtung spiegelt wider, wie grundlegend ein Bereich für die Funktion einer Website ist: Wer nicht gefunden wird oder deren Seiten auf dem Smartphone kaum nutzbar sind, verliert Besucher, bevor alle anderen Qualitäten wirken können. Sie ist keine Aussage darüber, dass Barrierefreiheit oder Datenschutz weniger wichtig wären – sie beschreibt nur ihren Anteil am Pixelkiez Score. Der Pixelkiez Score ist eine Orientierungshilfe von 360°Pixelkiez, kein allgemeiner Qualitätsstandard, kein Zertifikat und keine Ranking- oder Umsatzprognose.
Die Startseite und die Analyse erklären dieselben sechs Bereiche mit denselben Gewichten.
Manche Kriterien brauchen Voraussetzungen, die nicht immer gegeben sind: echte Nutzungsdaten, zum Beispiel für die Core Web Vitals, kontrollierte Laborläufe oder automatisierte Accessibility-Tests. Ob sie geprüft werden können, hängt vom Einzelfall ab.
Wie eine Prüfung abläuft
Umfang festlegen
Zu Beginn wird dokumentiert, welche Adresse geprüft wird, welche Varianten es gibt (etwa mit und ohne „www“), zu welchem Zeitpunkt die Prüfung erfolgt, welche Sprache und welcher Markt relevant sind und welche der bis zu sechs öffentlichen Seiten in die Stichprobe einfließen – zum Beispiel die Startseite, eine Leistungsseite und die Kontaktseite.
Belege erheben
Für jedes Kriterium wird die festgelegte Prüfmethode angewendet: Abruf der Seite und Auswertung der Serverantwort, Inspektion des HTML, Darstellung im Browser, Auswertung strukturierter Daten, Messung von Ressourcen, datierte Suchanfragen oder – wo öffentlich vorhanden – Feld- und Labordaten. Jeder Befund wird mit Fundstelle, Zeitpunkt und Methode festgehalten.
Einordnen
Ein Kriterium wird nur dann eingeordnet, wenn mindestens ein belastbarer Beleg vorliegt. Dafür nutzen wir eine fünfstufige Skala:
| Stufe | Bedeutung |
|---|---|
| Stark | Anforderung erfüllt, keine nennenswerten Lücken |
| Kleine Lücken | grundsätzlich gut, einzelne Verbesserungen sinnvoll |
| Gemischt | teils erfüllt, teils deutlicher Handlungsbedarf |
| Schwach | überwiegend nicht erfüllt |
| Blockierend | verhindert eine Grundfunktion, etwa Erreichbarkeit oder Indexierung |
Wo es einen anerkannten externen Grenzwert gibt – etwa bei den Core Web Vitals –, wird der gemessene Wert zuerst gegen die aktuelle Quelle dieses Grenzwerts eingeordnet und erst danach einer Stufe zugeordnet.
Priorisieren
Befunde werden nach ihrer Wirkung auf Besucher und Geschäft sowie nach dem Aufwand der Behebung geordnet. Zuerst stehen Hindernisse, die Kerninhalte, Kontaktwege oder die Auffindbarkeit blockieren; danach folgen Optimierungen.
Was Ihr Bericht zeigt
Ihr Bericht ist ein PDF mit sieben Seiten, das Pixelkiez persönlich erstellt, prüft und per E-Mail schickt. Er stellt die wichtigsten belegten Befunde in den Vordergrund, erklärt sie verständlich und ordnet die nächsten Schritte nach Wirkung und Aufwand.
Der Bericht nennt die geprüften Seiten und die Grenzen der Prüfung. Punkte, die nicht geprüft werden konnten, und Lücken in den Daten benennt er offen, ohne sie als Mangel zu werten. Wo eine Messbedingung für das Verständnis eines Befunds nötig ist – etwa Suchanfrage, Ort, Gerät und Datum einer Sichtbarkeitsprobe –, wird sie knapp genannt.
Der Status „nicht geprüft“
Nicht jedes Kriterium lässt sich bei jeder Website prüfen. Echte Nutzungsdaten liegen zum Beispiel nur vor, wenn eine Website genügend Besuche hat; manche Fehlermeldungen erscheinen erst, wenn ein Formular abgesendet wird – was eine externe Analyse bewusst unterlässt. In solchen Fällen führen wir das Kriterium als „nicht geprüft“.
So bleibt das Ergebnis fair: Eine Website wird nicht dafür abgewertet, dass Daten fehlen oder eine Prüfung von außen nicht möglich war.
Was die Analyse nicht leistet
- Keine Ranking- oder Sichtbarkeitsgarantie. Suchergebnisse und KI-Antworten hängen von Suchanfrage, Wettbewerb, Ort, Gerät, Zeitpunkt und den Systemen der Anbieter ab.
- Keine Rechtsprüfung. Ob Impressum, Datenschutzerklärung oder Barrierefreiheit rechtlichen Anforderungen genügen, kann nur eine qualifizierte rechtliche Prüfung beurteilen.
- Keine Zertifizierung der Barrierefreiheit. Die Prüfung ist eine Stichprobe und ersetzt keine vollständige Konformitätsprüfung.
- Kein Penetrationstest. Sichtbare Sicherheitsmerkmale wie HTTPS und Header sagen nichts über Schwachstellen in der Anwendung.
- Keine Garantie für Vollständigkeit. Eine Stichprobe zeigt Muster, nicht jeden Einzelfall auf jeder Unterseite.
Belege und Quellen
Die Erläuterungen in diesem Bereich stützen sich auf überprüfbare Quellen: offizielle Dokumentationen der Suchmaschinen- und KI-Anbieter, Standards des W3C, der IETF und europäischer Normungsorganisationen, Gesetzestexte und Gerichtsentscheidungen sowie Forschung anerkannter Institute. Ältere Studien sind mit Jahr gekennzeichnet. Jede Unterseite nennt ihren inhaltlichen Stand.
Externe Grenzwerte übernehmen wir aus der jeweils aktuellen Primärquelle. Für die Core Web Vitals gelten zum Beispiel die Schwellenwerte, die Google veröffentlicht: ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1, jeweils am 75. Perzentil (web.dev: Web Vitals). Für Barrierefreiheit sind die Web Content Accessibility Guidelines 2.2 auf den Stufen A und AA der Maßstab (W3C: Web Content Accessibility Guidelines 2.2).
Quellen
Die Aussagen auf dieser Seite stützen sich auf die folgenden Quellen, geordnet nach Herausgeber. Angaben von Anbietern beschreiben, was ein Unternehmen über sein eigenes System sagt; sie sind dafür die maßgebliche Quelle und können sich jederzeit ändern. Bei Gesetzen, Standards und technischen Referenzen nennen wir die geltende Fassung.
- Google definiert die Core Web Vitals und ihre Schwellenwerte, auf die sich die Performance-Bewertung stützt.
- W3C
- Die WCAG 2.2 sind der Maßstab für die Prüfung der Barrierefreiheit.