Wer die Website-Qualität prüfen möchte, braucht mehr als ein persönliches Designurteil. Eine Website kann modern aussehen und trotzdem das Angebot schlecht erklären, auf Mobilgeräten scheitern, Suchmaschinen blockieren oder Anfragen verlieren.
Die kurze Antwort: Eine gute Website erfüllt ihren Geschäftszweck, macht relevante Inhalte verständlich, funktioniert zugänglich auf unterschiedlichen Geräten, ist technisch auffindbar und besitzt einen geregelten Betrieb. Mit den folgenden 25 Fragen kannst du diese Qualität strukturiert prüfen. Jede erfüllte Frage zählt einen Punkt.
Website-Qualität in fünf Bereichen prüfen
Die 25 Punkte verteilen sich auf fünf gleich gewichtete Prüffelder:
| Prüffeld | Fragen | Kernfrage | | -------------------------- | -----: | --------------------------------------------------------- | | Geschäftsziel und Struktur | 1–5 | Unterstützt die Website eine konkrete Entscheidung? | | Inhalt und Vertrauen | 6–10 | Verstehen und glauben Besucher das Angebot? | | UX und Barrierefreiheit | 11–15 | Können unterschiedliche Menschen die Seite bedienen? | | SEO und Performance | 16–20 | Ist die Website auffindbar, schnell und migrationssicher? | | Technik und Betrieb | 21–25 | Funktioniert sie zuverlässig über den Launch hinaus? |
Bewerte nicht nach Absicht, sondern nach dem sichtbaren Zustand. „Das wollen wir noch ergänzen“ zählt vorerst als nicht erfüllt.
Auswertung: Was bedeutet die Punktzahl?
| Ergebnis | Einordnung | Sinnvoller nächster Schritt | | ------------ | ----------------------------- | --------------------------------------------------------- | | 22–25 Punkte | starke Basis | einzelne Lücken priorisieren und Wirkung messen | | 17–21 Punkte | grundsätzlich tragfähig | schwächstes Prüffeld gezielt verbessern | | 11–16 Punkte | mehrere strukturelle Risiken | Maßnahmenplan statt einzelner Designkorrekturen erstellen | | 0–10 Punkte | grundlegender Handlungsbedarf | Ziel, Struktur und technische Basis neu bewerten |
Die Summe ist nur die erste Orientierung. Ein nicht funktionierendes Anfrageformular kann geschäftlich schwerer wiegen als drei kleinere Inhaltslücken. Markiere deshalb zusätzlich alle Punkte, die Umsatz, Bewerbungen, Sicherheit oder bestehende Suchsichtbarkeit direkt gefährden.
Prüffeld 1: Geschäftsziel und Struktur
1. Hat die Website ein klar benanntes Geschäftsziel?
Bestanden, wenn: Eine verantwortliche Person kann in einem Satz sagen, welche geschäftliche Veränderung die Website erzeugen soll – etwa qualifizierte Anfragen, Bewerbungen, Terminbuchungen oder Produktregistrierungen.
„Online präsent sein“ ist kein ausreichendes Ziel. Ohne Priorität konkurrieren zu viele Botschaften und Handlungsaufforderungen miteinander.
2. Sind die wichtigsten Zielgruppen und Situationen definiert?
Bestanden, wenn: Für jede Hauptzielgruppe ist dokumentiert, mit welcher Frage oder welchem Problem sie auf die Website kommt.
Eine Persona-Datei ist dafür nicht zwingend nötig. Entscheidend ist, dass Seitenstruktur und Inhalt reale Entscheidungssituationen abbilden – nicht nur interne Abteilungen.
3. Gibt es pro zentraler Seite einen primären nächsten Schritt?
Bestanden, wenn: Besucher erkennen, was nach dem Lesen sinnvoll ist: Projekt anfragen, Referenz öffnen, Termin buchen, Unterlage herunterladen oder eine passende Unterseite wählen.
Fünf gleichwertige Buttons sind keine Auswahlhilfe. Eine klare Hierarchie darf sekundäre Wege anbieten, muss aber einen Hauptweg erkennbar machen.
4. Entspricht die Navigation den Fragen der Nutzer?
Bestanden, wenn: Bezeichnungen sind ohne internes Vorwissen verständlich und wichtige Inhalte lassen sich auf direktem Weg erreichen.
Teste die Navigation mit einer Person außerhalb des Unternehmens. Gib ihr eine konkrete Aufgabe und beobachte, welchen Menüpunkt sie wählt. Erklärungen während des Tests verfälschen das Ergebnis.
5. Gibt es eine verantwortliche Person für die Website?
Bestanden, wenn: Inhalt, Technik, Anfragen und Freigaben haben benannte Verantwortliche – intern oder extern.
Websites ohne Eigentümer veralten schleichend. Kontaktdaten, Leistungen, Teamseiten und rechtliche Informationen bleiben dann so lange liegen, bis ein Fehler sichtbar wird.
Prüffeld 2: Inhalt und Vertrauen
6. Erklärt der erste Bildschirm Angebot, Zielgruppe und Nutzen?
Bestanden, wenn: Ein neuer Besucher kann nach wenigen Sekunden sagen, was das Unternehmen anbietet, für wen und mit welchem relevanten Nutzen.
Eine kreative Headline darf Neugier erzeugen. Sie sollte aber nicht verlangen, dass Besucher zuerst mehrere Absätze entschlüsseln.
7. Haben wichtige Leistungen eigene, vollständige Seiten?
Bestanden, wenn: Zentrale Leistungen erklären Problem, Vorgehen, Umfang, Belege, typische Fragen und den nächsten Schritt.
Kurze Kacheln auf der Startseite reichen bei erklärungsbedürftigen B2B-Angeboten selten. Gleichzeitig braucht nicht jede interne Teilleistung eine dünne SEO-Seite. Eine URL sollte eine eigenständige Nutzerfrage vollständig beantworten.
8. Werden Qualitätsversprechen konkret belegt?
Bestanden, wenn: Aussagen wie „erfahren“, „individuell“ oder „zuverlässig“ werden durch reale Projekte, Zahlen, Arbeitsweisen, Zertifikate, Personen oder freigegebene Kundenstimmen gestützt.
Unser Artikel Fünf B2B-Webdesign-Beispiele aus Fürth und Nürnberg zeigt, wie Ausgangslage und Entscheidung mehr Aussagekraft schaffen als eine reine Screenshot-Galerie.
9. Sind Inhalte aktuell, eindeutig und fachlich verantwortlich?
Bestanden, wenn: Leistungen, Team, Kontaktdaten, Termine und Fachinformationen stimmen; veraltete Inhalte sind aktualisiert, zusammengeführt oder entfernt.
Bei Fachartikeln sollten Autor und Veröffentlichungs- oder Änderungsdatum sichtbar sein. Das hilft Lesern, Aussagen zeitlich und fachlich einzuordnen.
10. Ist der Kontaktweg verständlich und verhältnismäßig?
Bestanden, wenn: Besucher wissen, welche Angaben benötigt werden, was nach dem Absenden passiert und wann sie mit einer Antwort rechnen können.
Ein Erstkontakt muss nicht das vollständige Vertriebsformular abbilden. Frage nur Daten ab, die für den nächsten sinnvollen Schritt tatsächlich gebraucht werden.
Prüffeld 3: UX und Barrierefreiheit
11. Funktionieren alle wichtigen Aufgaben auf einem Mobilgerät?
Bestanden, wenn: Navigation, Inhalte, Tabellen, Formulare und Buttons lassen sich auf kleinen Bildschirmen ohne Zoomen oder horizontales Seiten-Scrolling nutzen.
Teste nicht nur eine verkleinerte Browseransicht. Reale Geräte zeigen Probleme mit Bildschirmtastatur, Touch-Zielen, langsamer Verbindung und Browserleisten deutlicher.
12. Ist die Website vollständig per Tastatur bedienbar?
Bestanden, wenn: Alle interaktiven Elemente sind mit Tabulator, Umschalttaste und Eingabetaste erreichbar; Fokusreihenfolge und sichtbarer Fokus sind nachvollziehbar.
Dieser Test dauert für eine kleine Website nur wenige Minuten und findet Probleme, die ein reiner Screenshot niemals zeigen kann.
13. Sind Kontraste, Beschriftungen und Alternativtexte sinnvoll?
Bestanden, wenn: Text und Bedienelemente sind ausreichend kontrastreich, Formularfelder besitzen eindeutige Labels und inhaltliche Bilder haben passende Alternativtexte.
Die Web Content Accessibility Guidelines 2.2 formulieren testbare, technologieunabhängige Kriterien für zugängliche Webinhalte. Automatische Prüfungen helfen, ersetzen aber keine manuelle Nutzung mit Tastatur und assistiven Technologien.
14. Bleibt das Layout während des Ladens und Bedienens stabil?
Bestanden, wenn: Bilder, Schriften, Banner oder nachgeladene Inhalte verschieben keine bereits sichtbaren Bedienelemente unerwartet.
Layout-Sprünge sind nicht nur ein Performanceproblem. Sie führen zu Fehlklicks und erschweren besonders Menschen mit motorischen oder kognitiven Einschränkungen die Nutzung.
15. Erklären Formulare Fehler und Erfolg eindeutig?
Bestanden, wenn: Fehlende oder falsche Eingaben werden verständlich am betroffenen Feld benannt; nach dem Absenden erscheint eine eindeutige Bestätigung.
Farbe allein darf nicht das einzige Fehlersignal sein. Außerdem sollte der Fokus bei einer Fehlermeldung sinnvoll geführt werden.
Prüffeld 4: SEO und Performance
16. Können Suchmaschinen die gewünschten Seiten crawlen und indexieren?
Bestanden, wenn: robots.txt, Meta-Robots, Canonicals und HTTP-Statuscodes unterstützen den beabsichtigten Indexierungszustand.
Ein versehentliches noindex aus der Entwicklungsumgebung kann eine ansonsten perfekte Website unsichtbar machen. Prüfe zentrale URLs nach dem Launch zusätzlich in der Google Search Console.
17. Besitzt jede wichtige Seite ein eindeutiges Suchthema?
Bestanden, wenn: Seitentitel, Hauptüberschrift, Einleitung und Inhalt beantworten dieselbe Nutzerfrage, ohne mehrere Seiten gegeneinander antreten zu lassen.
Lokale Seiten für Webdesign in Fürth und Webdesign in Nürnberg brauchen jeweils eigenständigen Nutzen. Nur den Ortsnamen auszutauschen ist keine belastbare lokale Relevanz.
18. Sind interne Links und strukturierte Daten konsistent?
Bestanden, wenn: Wichtige Seiten sind aus passenden Inhalten verlinkt, es gibt keine unnötigen Linkketten und strukturierte Daten stimmen mit dem sichtbaren Inhalt überein.
Google nennt für AI Overviews und AI Mode keine besondere Geheimoptimierung. In den offiziellen Hinweisen zu KI-Funktionen in der Suche bleiben interne Auffindbarkeit, gute Seitenerfahrung, Textinhalte und passende strukturierte Daten zentrale Grundlagen.
19. Erreichen reale Nutzer gute Core Web Vitals?
Bestanden, wenn: Felddaten liegen im guten Bereich: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden und CLS höchstens 0,1 – jeweils am 75. Perzentil.
Diese Schwellen stammen aus der Core-Web-Vitals-Dokumentation von web.dev. Ein einzelner Lighthouse-Test ist nützlich für die Diagnose, aber nicht mit realen Felddaten gleichzusetzen.
20. Ist bei einem Relaunch jede alte URL bewusst behandelt?
Bestanden, wenn: Relevante alte URLs sind einer passenden neuen URL, einem echten 404/410-Status oder einer dokumentierten Ausnahme zugeordnet.
Google empfiehlt bei Migrationen ein URL-Mapping, serverseitige permanente Weiterleitungen und direkte Ziele ohne unnötige Ketten. Die offizielle Anleitung für Website-Migrationen beschreibt den Ablauf. Unsere Relaunch-Checkliste ordnet ihn in das Gesamtprojekt ein.
Prüffeld 5: Technik und Betrieb
21. Werden HTTPS und sinnvolle Sicherheits-Header eingesetzt?
Bestanden, wenn: Die Website erzwingt HTTPS und setzt zur Anwendung passende Sicherheits-Header ohne widersprüchliche oder veraltete Konfigurationen ein.
Das OWASP Secure Headers Project bietet herstellerneutrale technische Orientierung. Sicherheits-Header sind eine Schutzschicht, ersetzen aber keine sichere Anwendung, Updates oder eine individuelle Prüfung.
22. Sind alle Formulare vollständig getestet?
Bestanden, wenn: Erfolgsfall, Pflichtfelder, ungültige Eingaben, Spam-Schutz, Einwilligung, Zustellung und gegebenenfalls CRM-Übergabe wurden mit realen Testdaten geprüft.
Kontrolliere nicht nur die sichtbare Bestätigungsseite. Eine Anfrage kann im Browser erfolgreich aussehen und trotzdem wegen einer fehlerhaften E-Mail- oder API-Konfiguration verloren gehen.
23. Messen Tracking und Consent nur das Beabsichtigte?
Bestanden, wenn: Einwilligungen werden technisch respektiert, Ereignisse sind dokumentiert und wichtige Conversions lassen sich ohne doppelte oder widersprüchliche Messung nachvollziehen.
Die konkrete rechtliche Bewertung gehört zu qualifizierten Datenschutz-Fachleuten. Der technische Qualitätscheck prüft, ob das abgestimmte Consent- und Messkonzept tatsächlich umgesetzt ist.
24. Sind Eigentum, Zugänge, Backups und Wiederherstellung geklärt?
Bestanden, wenn: Domain, Hosting, Quellcode, Design, Analytics und weitere Konten sind eindeutig zugeordnet; Backups existieren und die Wiederherstellung wurde zumindest stichprobenartig geprüft.
Eine Sicherung, die niemand zurückspielen kann, ist nur eine Hoffnung. Dokumentiere außerdem, wer bei Ausfall oder Anbieterwechsel Zugriff erhält.
25. Gibt es einen geregelten Betrieb nach dem Launch?
Bestanden, wenn: Verantwortliche, Update-Rhythmus, Monitoring, Reaktionsweg und Budget für Verbesserungen sind benannt.
Der Launch ist der Beginn der realen Nutzung. Ohne Betrieb bleiben technische Fehler, veraltete Inhalte und schlechter werdende Performance oft so lange unbemerkt, bis Kunden sie melden.
Welche Punkte lassen sich automatisieren?
Automatisierte Tests sind besonders hilfreich für wiederkehrende technische Prüfungen:
- nicht erreichbare Links und fehlerhafte Statuscodes;
- fehlende Seitentitel oder Canonicals;
- bestimmte Barrierefreiheitsfehler;
- Performance-Labordaten;
- JavaScript-Fehler;
- Formular-Smoke-Tests;
- fehlende oder widersprüchliche Sicherheits-Header.
Manuell geprüft werden müssen unter anderem Verständlichkeit, visuelle Hierarchie, Qualität der Belege, sinnvolle Alternativtexte, Tastaturabläufe und die Frage, ob eine Seite das Geschäftsproblem wirklich löst.
Ein gutes Qualitätssystem verbindet deshalb drei Ebenen: automatisierte Tests, fachliche Prüfung und reale Nutzungsdaten.
So priorisierst du die gefundenen Probleme
Nicht jede Abweichung gehört sofort in einen Relaunch. Ordne jeden Fund nach Wirkung und Aufwand:
- Geschäftskritisch: Anfragen gehen verloren, wichtige Seiten sind nicht indexierbar oder sensible Funktionen sind unsicher.
- Nutzungsrelevant: Navigation, mobile Bedienung, Lesbarkeit oder Formulare erschweren zentrale Aufgaben.
- Wachstumsrelevant: Leistungsseiten, Belege, interne Links oder Messung begrenzen Sichtbarkeit und Conversion.
- Kosmetisch: Eine Abweichung betrifft hauptsächlich Geschmack, ohne Aufgabe oder Vertrauen wesentlich zu beeinflussen.
Bearbeite zuerst Punkte mit hoher Wirkung und überschaubarem Aufwand. Mehrere strukturelle Probleme in Ziel, Inhalt und Technik sprechen eher für einen geplanten Relaunch als für eine Folge isolierter Korrekturen.
Wer Budget und Umfang einordnen möchte, findet im Artikel Was kostet eine professionelle Website in Fürth und Nürnberg? typische Kostenblöcke. Für einen schnellen interaktiven Einstieg stehen außerdem unsere kostenlosen Website-Checks bereit.
Häufige Fragen zur Website-Qualität
Wie oft sollte eine Website geprüft werden?
Geschäftskritische Formulare und Verfügbarkeit sollten laufend überwacht werden. Ein umfassender fachlicher Check ist mindestens vor und nach größeren Änderungen sinnvoll. Inhalte, Zugänge und technische Abhängigkeiten sollten zusätzlich in einem festen Rhythmus überprüft werden.
Reicht ein Lighthouse-Score für die Qualitätsbewertung?
Nein. Lighthouse liefert wertvolle Labordaten zu Performance, Barrierefreiheit, Best Practices und SEO. Es bewertet aber weder Positionierung noch Beweiskraft, fachliche Richtigkeit oder den vollständigen Geschäftsprozess hinter einem Formular.
Ist eine Website mit 25 Punkten automatisch rechtssicher?
Nein. Die Checkliste ist keine rechtliche Prüfung. Impressum, Datenschutz, Einwilligungen, Barrierefreiheits-Pflichten und branchenspezifische Anforderungen sollten bei Bedarf juristisch oder fachlich bewertet werden.
Muss jede Website perfekte Core Web Vitals erreichen?
Die guten Schwellenwerte sind ein sinnvolles Qualitätsziel, aber kein Ersatz für die Gesamtbetrachtung. Eine schnelle Seite mit unverständlichem Angebot ist ebenso problematisch wie eine überzeugende Seite, die auf Mobilgeräten kaum lädt.
Wann genügt Optimierung und wann ist ein Relaunch sinnvoll?
Einzelne technische oder inhaltliche Lücken lassen sich häufig gezielt beheben. Wenn Ziel, Seitenstruktur, CMS, Designsystem und Inhalte gleichzeitig nicht mehr tragen, ist ein geplanter Relaunch meist wirtschaftlicher als dauerhaftes Flicken.
Fazit: Qualität ist überprüfbar
Eine hochwertige Website ist kein Geschmacksurteil und kein einzelner Performancewert. Sie verbindet Geschäftsziel, verständlichen Inhalt, belastbare Belege, zugängliche Bedienung, Auffindbarkeit und geregelten Betrieb.
Die 25 Punkte machen diese Qualität besprechbar. Genau darin liegt ihr Wert: Teams können Probleme priorisieren, Angebote klarer abgrenzen und einen Launch anhand gemeinsamer Kriterien freigeben.
Wenn du die Prüfung nicht allein durchführen möchtest, kannst du uns deine Website über die Projektanfrage schicken. Als Webdesign-Agentur für Fürth und Nürnberg verbinden wir die fachliche Einordnung mit konkreten nächsten Schritten – vom begrenzten Audit bis zum vollständigen B2B-Relaunch.