Website-Audit 2026: Die vollständige Checkliste für SEO, Core Web Vitals, Barrierefreiheit und Sicherheit

Im Jahr 2026 muss ein Audit schichtweise durchgeführt werden. Google stützt die Sichtbarkeit weiterhin auf technische Grundlagen und Inhalte, die in erster Linie für Menschen erstellt wurden, auch wenn Ergebnisse zusätzlich in KI-gestützten Funktionen erscheinen können. Core Web Vitals sollten mit echten Nutzerdaten bewertet werden, Barrierefreiheit lässt sich nicht allein mit einem Scanner bestätigen, und Sicherheit umfasst weit mehr als ein vorhandenes SSL-Zertifikat.

Dieser Leitfaden führt durch den gesamten Prozess: von Indexierung und SEO über LCP, INP und CLS bis zu WCAG 2.2, Sicherheitsheadern, Formularen, Analytics und der richtigen Reihenfolge der Korrekturen.

TL;DR: Beginnen Sie mit kritischen Problemen: Ausfall der Website, blockierter Indexierung, fehlerhaften Weiterleitungen, HTTPS-Problemen und Schwachstellen. Verbessern Sie anschließend Core Web Vitals, die Barrierefreiheit der wichtigsten Nutzerwege, Inhalte und interne Verlinkung. Eine Punktzahl von 100/100 in einem Tool ersetzt weder Search-Console-Daten noch Tests auf echten Geräten oder eine manuelle Prüfung.

Standards, Schwellenwerte und Quellen wurden zuletzt am 23. Juli 2026 geprüft.

Die wichtigsten Audit-Bereiche

Bereich	Was geprüft werden sollte	Wie ein gutes Ergebnis aussieht	Priorität
Indexierung	robots.txt, noindex, Sitemap, Canonical, HTTP-Statuscodes	wichtige Seiten sind erreichbar und indexierbar, Duplikate sind konsolidiert	kritisch
SEO und Inhalte	Suchintention, Titel, Überschriften, interne Links, strukturierte Daten	jede wichtige Seite hat einen klaren Zweck und einen eigenen Mehrwert	hoch
Performance	LCP, INP, CLS, TTFB, JavaScript, Bilder, Fonts	CWV liegen beim 75. Perzentil im Bereich „gut“	hoch
Barrierefreiheit	Tastatur, Fokus, Semantik, Kontrast, Formulare, Screenreader	zentrale Nutzerwege erfüllen WCAG 2.2 AA	hoch
Sicherheit	HTTPS, Header, Cookies, Abhängigkeiten, Autorisierung, Backups	keine kritischen Schwachstellen und keine unnötige Exponierung	kritisch
UX und Conversion	Mobile, Formulare, Navigation, Fehler, Vertrauen	Nutzer können die Hauptaufgabe ohne unnötige Reibung abschließen	hoch
Messung	Search Console, Analytics, Logs, Monitoring	Daten sind vollständig, datenschutzkonform und handlungsrelevant	mittel

Was umfasst ein Website-Audit tatsächlich?

Ein vollständiges Audit verbindet mindestens sechs Perspektiven:

1. Technisches SEO - ob ein Crawler die Website aufrufen, rendern, Links verfolgen und die richtige kanonische URL erkennen kann.
2. Inhaltsqualität - ob eine Seite eine echte Nutzerfrage beantwortet, logisch aufgebaut ist und keine andere Seite unnötig dupliziert.
3. Performance - wie schnell der Hauptinhalt erscheint, wie zügig die Seite reagiert und ob sich das Layout während des Ladens verschiebt.
4. Barrierefreiheit - ob der Dienst mit Tastatur, Screenreader und Vergrößerung nutzbar ist und nicht ausschließlich auf Farbe angewiesen ist.
5. Sicherheit und Datenschutz - ob Kommunikation, Sitzungen, Formulare, Abhängigkeiten und Nutzerdaten angemessen geschützt sind.
6. UX und Geschäftsziele - ob Besucher das Angebot verstehen und die wichtigste Aktion ohne unnötige Schritte ausführen können.

Automatische Tools sind ein guter Ausgangspunkt, können aber nicht alles bewerten. Lighthouse erkennt einen Teil der Performance- und Barrierefreiheitsprobleme, kann jedoch nicht feststellen, ob ein Angebot verständlich ist, ein Formular den Kundenbedürfnissen entspricht oder eine Fehlermeldung wirklich bei der Problemlösung hilft.

Vor dem Start: Umfang und URL-Stichprobe festlegen

Der häufigste Fehler besteht darin, nur die Startseite zu scannen. In der Praxis sollten repräsentative Seitentypen geprüft werden:

• die Startseite,
• die wichtigste Leistungs- oder Produktseite,
• ein Artikel oder Ratgeber,
• eine Kategorie- oder Listingseite,
• ein Kontaktformular, eine Registrierung oder der Checkout,
• eine Suchergebnisseite,
• eine Sprachversion,
• die 404-Seite und andere Fehlerzustände,
• eine geschützte Seite, falls vorhanden.

Bei einer kleinen Website reicht eine Stichprobe aus mehreren oder einem Dutzend URLs. Bei einem Shop, Portal oder einer Anwendung sollten Vorlagen statt zufälliger URLs untersucht werden. Hat eine Produktvorlage einen falschen Canonical oder lädt ein zu schweres Skript, kann das Tausende Seiten betreffen.

Sammeln Sie vor dem Audit:

• Zugriff auf Google Search Console und Analytics,
• eine Liste der wichtigsten Geschäftsziele,
• Sitemap und zentrale Vorlagen,
• Informationen zu Änderungen, Migrationen und Traffic-Einbrüchen,
• Daten aus dem Fehlermonitoring und Server-Logs,
• die von Kunden am häufigsten genutzten Geräte und Browser.

1. Audit von technischem SEO und Indexierung

HTTP-Statuscodes und Domainvarianten prüfen

Jede wichtige URL sollte den richtigen Status zurückgeben:

• 200 für eine funktionierende Seite,
• 301 oder 308 für eine dauerhafte Weiterleitung,
• 404 oder 410 für entfernte Inhalte,
• 5xx nur bei einem echten Serverfehler, nicht als Dauerzustand.

Prüfen Sie http/https, www/non-www, abschließende Schrägstriche und Groß-/Kleinschreibung. Alle Varianten sollten zu einer konsistenten Version führen. Vermeiden Sie Weiterleitungsketten und Situationen, in denen viele alte URLs ohne inhaltlichen Bezug auf die Startseite umgeleitet werden.

robots.txt, noindex und Ressourcenzugriff prüfen

Die Datei robots.txt steuert den Zugriff von Crawlern auf Abrufebene, ist aber kein Mechanismus zum Entfernen einer Seite aus den Suchergebnissen. Eine blockierte URL kann weiterhin im Index erscheinen, wenn Google sie aus anderen Quellen kennt. Zum Ausschluss einer Seite dienen beispielsweise noindex, Passwortschutz oder das Entfernen der Ressource.

Prüfen Sie, ob:

• wichtige Bereiche nicht versehentlich blockiert sind,
• die Staging-Umgebung geschützt und nicht nur in robots.txt versteckt ist,
• Google CSS, JavaScript und Bilder für das Rendering abrufen kann,
• die Sitemap unter der richtigen Adresse liegt und nur kanonische Seiten enthält,
• ein noindex-Tag nach dem Produktions-Deployment nicht versehentlich erhalten blieb.

Canonicals und Duplikate bewerten

Eine kanonische URL bezeichnet die bevorzugte Version identischer oder sehr ähnlicher Inhalte. Google wertet Canonical-Signale stark, kann jedoch eine andere URL auswählen, wenn die übrigen Signale widersprüchlich sind.

Prüfen Sie die Konsistenz von:

• rel="canonical",
• Weiterleitungen,
• internen Links,
• XML-Sitemaps,
• Sprachversionen,
• Protokoll und Host.

Ein Canonical sollte normalerweise auf eine funktionierende 200-URL zeigen, nicht auf eine Fehlerseite, Weiterleitung oder eine mit noindex markierte URL.

JavaScript-Rendering überprüfen

Google verarbeitet JavaScript-Anwendungen in mehreren Schritten: Crawling, Rendering und Indexierung. Clientseitig erzeugte Inhalte können später verarbeitet werden als sofort verfügbares HTML. Kritische Informationen und Links sollten daher nicht von einem fragilen Skript abhängen.

Prüfen Sie bei SPAs und hybriden Anwendungen:

• HTML, das bereits vor der JavaScript-Ausführung verfügbar ist,
• Links als echte <a href>-Elemente,
• korrekte Statuscodes,
• individuell erzeugte Metadaten für jede URL,
• Verhalten beim direkten Aufruf einer Unterseite,
• Hydration-Fehler und fehlgeschlagene API-Anfragen,
• Indexierbarkeit von Paginierung und Infinite-Scroll-Listen.

Sprachversionen prüfen

Bei einer mehrsprachigen Website sollte jede Version eine eigene stabile URL besitzen. Prüfen Sie:

• gültige hreflang-Attribute,
• wechselseitige Verweise zwischen den Versionen,
• optionales x-default,
• Canonical auf dieselbe Sprachversion,
• keine automatischen Weiterleitungen, die Crawler blockieren,
• übersetzte Titel, Beschreibungen, Inhalte und Navigation.

Checkliste für technisches SEO

• Wichtige URLs liefern 200.
• Weiterleitungen sind einstufig und logisch.
• Es gibt keine unbeabsichtigten robots.txt-Sperren.
• Die Produktionsversion enthält kein unbeabsichtigtes noindex.
• Die XML-Sitemap enthält nur kanonische URLs.
• Canonicals, Links und Sitemap stimmen überein.
• JavaScript versteckt keine kritischen Inhalte vor Crawlern.
• 404-Seiten liefern tatsächlich den Status 404.
• Sprachversionen verwenden korrektes hreflang.
• Parameter und Filter erzeugen keine massenhaften Duplikate.

2. Inhalts- und Onpage-SEO-Audit

Jede Unterseite sollte ein Hauptziel haben

Titel, H1, Einstieg, Hauptinhalt und Call-to-Action sollten dieselbe Suchintention bedienen. Wenn eine Seite gleichzeitig eine Leistung verkaufen, Grundlagen erklären und für ein Dutzend unverbundener Suchanfragen ranken soll, erfüllt sie meist keine dieser Aufgaben besonders gut.

Prüfen Sie:

• ob der title eindeutig und beschreibend ist,
• ob die H1 den Inhalt korrekt widerspiegelt,
• ob die Suchvorschau zum Klick motiviert, ohne übertriebene Versprechen,
• ob H2- und H3-Überschriften eine logische Struktur bilden,
• ob die Antwort früh erscheint und nicht erst nach einer langen Einleitung,
• ob der Artikel Erfahrung, Beispiele und Quellen zeigt,
• ob das Aktualisierungsdatum einer echten Inhaltsänderung entspricht.

Google empfiehlt hilfreiche, verlässliche Inhalte, die in erster Linie für Menschen erstellt wurden, statt Seiten, die nur Rankings manipulieren sollen.

Interne Verlinkung sollte Struktur schaffen

Gute interne Links helfen Nutzern beim nächsten Schritt und zeigen Suchmaschinen die Beziehungen zwischen Themen. Verwenden Sie aussagekräftige Ankertexte statt vieler generischer „hier klicken“-Links.

Sinnvolle nächste Schritte aus diesem Artikel sind:

• Website-Zustandsprüfung von POLPROG,
• Core Web Vitals in der Praxis,
• Web-Strategie,
• Performance,
• Sicherheit,
• So planen Sie eine Unternehmenswebsite, die Leads generiert.

Prüfen Sie außerdem verwaiste Seiten, zu denen kein interner Link führt.

Bilder, strukturierte Daten und Open Graph

Bilder sollten sinnvolle Dateinamen, passende Abmessungen und Alternativtexte besitzen, wenn sie Informationen vermitteln. Ein rein dekoratives Bild sollte meist ein leeres alt="" verwenden. Google unterstützt verbreitete Formate wie JPEG, PNG, WebP, SVG und AVIF.

Prüfen Sie:

• width und height, um Layoutverschiebungen zu reduzieren,
• srcset und sizes,
• Kompression und Format,
• Lazy Loading unterhalb des sichtbaren Bereichs,
• Alternativtexte,
• strukturierte Daten passend zum sichtbaren Inhalt,
• og:title, og:description, og:image und og:url.

Für praktische Tests eignen sich der Bildkonverter und -optimierer und die Open-Graph-Vorschau.

SEO in KI-gestützten Suchergebnissen

Google betont, dass für KI-Funktionen in der Suche weiterhin die grundlegenden SEO-Praktiken gelten. Es sind keine speziellen Dateien oder neuen Markups ausschließlich für AI Overviews oder AI Mode erforderlich. Eine Seite muss weiterhin indexierbar sein und die normalen Anforderungen der Suche erfüllen.

Eine vernünftige Strategie besteht darin:

• klare und vollständige Antworten zu veröffentlichen,
• Quellen und praktische Beispiele zu verwenden,
• schnell veränderliche Informationen zu aktualisieren,
• massenhaft erzeugte, repetitive Inhalte zu vermeiden,
• semantische Struktur und interne Links zu pflegen,
• Traffic und Suchanfragen in der Search Console zu beobachten.

3. Core Web Vitals und Performance

Aktuelle Schwellenwerte

Core Web Vitals bestehen aus drei Kennzahlen. Die Bewertung sollte anhand des 75. Perzentils realer Besuche erfolgen, getrennt für Mobilgeräte und Desktop.

Kennzahl	Was sie misst	Gut	Verbesserungsbedarf	Schlecht
LCP	Zeitpunkt des größten sichtbaren Inhaltselements	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	Reaktionsverzögerung bei Interaktionen	≤ 200 ms	200-500 ms	> 500 ms
CLS	visuelle Stabilität des Layouts	≤ 0,1	0,1-0,25	> 0,25

Felddaten zeigen die Erfahrung echter Nutzer, Labordaten helfen beim Reproduzieren eines Problems. Beides darf nicht verwechselt werden. Eine Website kann lokal in Lighthouse gut abschneiden, aber auf älteren Smartphones einen schlechten INP oder in einem bestimmten Land einen langsamen LCP besitzen.

LCP verbessern

Häufige Ursachen eines schlechten LCP:

• langsamer Server oder fehlender Cache,
• zu großes Hero-Bild,
• LCP-Ressource wird erst durch JavaScript entdeckt,
• renderblockierendes CSS und Fonts,
• lange Anfrageketten,
• schwere Logik vor dem Rendering.

Maßnahmen:

• TTFB und Caching verbessern,
• Bilder in den richtigen Abmessungen ausliefern,
• moderne Formate und Kompression verwenden,
• die wichtigste Ressource priorisieren,
• das LCP-Bild nicht per Lazy Loading laden,
• kritisches CSS und Skripte reduzieren,
• ein CDN einsetzen, wenn es den Weg zum Nutzer tatsächlich verkürzt.

INP verbessern

INP verschlechtert sich durch lange Aufgaben im Hauptthread, zu viel JavaScript, teures Rendering von Komponenten und Event-Handler, die zu viel Arbeit erledigen.

Prüfen Sie:

• Aufgabendauer im Performance-Panel,
• Drittanbieter-Skripte,
• Komponenten, die bei jeder Änderung neu rendern,
• große Listen ohne Virtualisierung,
• synchrone Speicher- und DOM-Operationen,
• Formularvalidierung und Animationen während der Interaktion.

Teilen Sie lange Aufgaben auf, verschieben Sie nicht kritische Arbeit und senden Sie möglichst wenig JavaScript an den Browser.

CLS verbessern

Häufige Quellen für Layoutverschiebungen:

• Bilder und iFrames ohne Abmessungen,
• Anzeigen ohne reservierten Platz,
• Cookie-Banner, die oberhalb des Inhalts eingefügt werden,
• spät geladene Fonts,
• Komponenten, die vor bestehendem Inhalt ergänzt werden,
• Animationen von layoutwirksamen Eigenschaften.

Reservieren Sie Platz, verwenden Sie stabile Platzhalter und testen Sie den gesamten Ladevorgang statt nur den fertigen Screenshot.

Nicht nur auf Lighthouse optimieren

Lighthouse ist ein Labortest unter kontrollierten Bedingungen. Ein belastbarer Prozess kombiniert:

• Search Console und den Bericht zu Core Web Vitals,
• CrUX- oder RUM-Daten,
• Lighthouse und Performance-Panel,
• Tests auf einem langsameren Gerät,
• Monitoring von Regressionen nach dem Deployment.

4. Barrierefreiheits-Audit nach WCAG 2.2

WCAG 2.2 beschreibt Kriterien, die sowohl automatisiert als auch manuell geprüft werden. Ein Scanner allein kann keine vollständige Konformität bestätigen, weil manche Kriterien Kontextbewertung und Interaktionstests erfordern.

Tastatur und Fokus

Durchlaufen Sie den wichtigsten Nutzerweg ohne Maus:

• ist jedes interaktive Element erreichbar,
• ist die Fokusreihenfolge logisch,
• ist der Fokusindikator klar sichtbar,
• hält ein Modal den Fokus und gibt ihn nach dem Schließen zurück,
• gibt es eine Tastaturfalle,
• lässt sich wiederkehrende Navigation überspringen.

Semantik und Screenreader

Prüfen Sie:

• eine logische H1 und eine korrekte Überschriftenhierarchie,
• Landmarken wie header, nav, main und footer,
• echte Buttons und Links statt klickbarer div-Elemente,
• zugängliche Namen für Icons,
• Ankündigungen dynamischer Änderungen,
• korrekte Lesereihenfolge,
• Dokumentsprache im Attribut lang.

ARIA sollte semantisches HTML ergänzen und nicht ohne Not ersetzen.

Formulare und Fehler

Jedes Feld sollte eine sichtbare Beschriftung und eine programmatische Verknüpfung mit seiner Beschreibung besitzen. Ein Fehler muss erklären, was korrigiert werden soll, und darf nicht ausschließlich über Farbe signalisiert werden.

Testen Sie:

• Labels und Anweisungen,
• Pflichtfelder,
• Autocomplete-Attribute,
• Tab-Reihenfolge,
• Fehlermeldungen,
• Fehlerzusammenfassung nach dem Absenden,
• Verhalten bei Zoom und schmalem Bildschirm,
• Zeitlimits und deren Verlängerbarkeit.

Kontrast, Vergrößerung und Bewegung

Prüfen Sie den Kontrast von Texten, Icons und Fokuszuständen. Testen Sie bei 200 % und 400 % Zoom, mit größerer Schrift und in einem schmalen Viewport. Inhalte sollten nicht horizontal gescrollt werden müssen, außer wenn dies sachlich notwendig ist.

Animationen sollten prefers-reduced-motion respektieren. Automatisch bewegte Inhalte brauchen eine Möglichkeit zum Pausieren, wenn sie das Verständnis beeinflussen.

Checkliste Barrierefreiheit

• Der gesamte Nutzerweg funktioniert per Tastatur.
• Fokus ist sichtbar und logisch.
• Überschriften und Landmarken beschreiben die Struktur.
• Buttons und Links haben verständliche Namen.
• Formulare besitzen Labels und hilfreiche Fehler.
• Der Kontrast erfüllt WCAG 2.2 AA.
• Inhalte funktionieren bei Zoom und Reflow.
• Informationsbilder haben passende Alternativtexte.
• Bewegung lässt sich reduzieren.
• Zentrale Aufgaben wurden mit einem Screenreader geprüft.

5. Sicherheits- und Datenschutz-Audit

HTTPS ist der Anfang, nicht das Ende

Die gesamte Website sollte per HTTPS ohne aktive Mixed Content funktionieren. Prüfen Sie Gültigkeit des Zertifikats, Vertrauenskette, unterstützte Protokolle, automatische Erneuerung und HTTP-zu-HTTPS-Weiterleitung. Lighthouse markiert Seiten ohne HTTPS als Sicherheitsproblem, führt aber keinen vollständigen Penetrationstest durch.

Domain und Zertifikat lassen sich mit dem DNS- und SSL-Inspektor prüfen.

Sicherheitsheader

Header beheben keine fehlerhafte Autorisierung, begrenzen aber bestimmte Angriffsklassen und unsicheres Browserverhalten. Das OWASP Secure Headers Project pflegt aktuelle Empfehlungen und Beispiele.

Prüfen Sie mindestens:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• Schutz vor Einbettung mit frame-ancestors,
• sichere Cookie-Attribute: Secure, HttpOnly und passendes SameSite.

CSP sollte schrittweise eingeführt werden. Beginnen Sie mit Content-Security-Policy-Report-Only, analysieren Sie Berichte und aktivieren Sie die Durchsetzung erst danach. Eine kopierte Konfiguration muss an die tatsächlich verwendeten Ressourcen angepasst werden.

Für eine schnelle Kontrolle nutzen Sie den Inspektor für Sicherheitsheader.

OWASP Top 10:2025 als Risikokarte

Die aktuelle OWASP Top 10:2025 umfasst fehlerhafte Zugriffskontrolle, Sicherheitsfehlkonfigurationen, Probleme in der Software-Lieferkette, kryptografische Fehler, Injection, unsicheres Design, Authentifizierungsfehler, Integritätsprobleme, Mängel bei Logging und Alarmierung sowie den falschen Umgang mit Ausnahmezuständen.

Prüfen Sie praktisch:

• ob ein Nutzer Daten eines anderen Nutzers lesen oder ändern kann,
• ob das Administrationspanel zusätzlich geschützt ist,
• ob APIs Berechtigungen serverseitig prüfen,
• ob Abhängigkeiten und Container-Images gepflegt werden,
• ob Geheimnisse aus Repository und Client-Code ferngehalten werden,
• ob Eingaben validiert und Ausgaben kodiert werden,
• ob Sitzungen ablaufen und widerrufen werden können,
• ob Logs Passwörter, Tokens und sensible Daten vermeiden,
• ob Fehler Stack Traces und Infrastrukturdetails verbergen,
• ob Backups existieren und eine Wiederherstellung getestet wurde.

Bei Anwendungen mit Login, Zahlungen oder Kundendaten sollte der Testumfang auf OWASP ASVS basieren und nicht nur auf einer kurzen Header-Liste.

Datenschutz und Analytics

Prüfen Sie:

• welche Skripte vor einer Einwilligung ausgeführt werden,
• ob Formulare nur notwendige Daten erheben,
• Aufbewahrungsfristen,
• Zugriff von Mitarbeitern und Dienstleistern,
• Möglichkeit zum Widerruf der Einwilligung,
• Consent-Mode-Konfiguration, falls verwendet,
• Protokollierung von IP-Adressen und Identifikatoren,
• ob die Datenschutzerklärung dem tatsächlichen Verhalten entspricht.

Ein Cookie-Banner allein garantiert keine Konformität. Entscheidend ist, was die Website tatsächlich lädt und überträgt.

6. UX, Mobile und Conversion

Ein technisches Audit kann erfolgreich sein, obwohl die Website ihr Ziel weiterhin verfehlt. Durchlaufen Sie den wichtigsten Prozess als neuer Nutzer:

• ist im ersten Bildschirm klar, was das Unternehmen anbietet,
• beschreibt jeder CTA eine konkrete Aktion,
• ist die Navigation ohne Rätsel verständlich,
• fragt das Formular nur notwendige Informationen ab,
• lassen sich Fehler leicht korrigieren,
• sind Telefonnummer und E-Mail auf Mobilgeräten antippbar,
• überlagern sich keine Elemente,
• lassen Pop-ups den Inhalt nutzbar,
• sind Erfolgsmeldungen eindeutig,
• funktioniert die Seite bei langsamer Verbindung und fehlgeschlagenen Anfragen.

Testen Sie auch die 404-Seite, leere Suchergebnisse, nicht verfügbare Produkte oder Leistungen, abgelaufene Sitzungen und fehlgeschlagene Zahlungen. Ausnahmezustände entscheiden oft darüber, ob jemand wiederkommt.

Für Lead-Generierung lesen Sie So planen Sie eine Unternehmenswebsite, die Leads generiert.

7. Messung, Monitoring und Datenqualität

Search Console zeigt, wie die Website in Google Search abschneidet, Analytics zeigt das Verhalten nach dem Besuch. Die Verbindung beider Perspektiven hilft, ein Sichtbarkeitsproblem von einem Conversion-Problem zu unterscheiden.

Prüfen Sie:

• ob die Search-Console-Property die richtige Domainvariante umfasst,
• Indexierungsfehler und manuelle Maßnahmen,
• Suchanfragen, Seiten, Länder und Geräte,
• Veränderungen bei Klicks und Impressionen nach Deployments,
• Vollständigkeit der Analytics-Ereignisse,
• Ausschluss internen Traffics und von Bots,
• Richtigkeit des Conversion-Funnels,
• Alerts für JavaScript- und Serverfehler,
• Uptime- und Zertifikatsmonitoring.

Beheben Sie nicht alles gleichzeitig ohne Ausgangswert. Dokumentieren Sie den Status quo und führen Sie Änderungen gruppenweise ein, damit ihre Wirkung messbar bleibt.

Wie lange dauert ein Audit?

Die folgenden Werte sind praktische Schätzungen, kein offizieller Standard. Der Umfang hängt von Vorlagenanzahl, Datenzugang, Technologie und Risikoniveau ab.

Umfang	Richtwert	Enthalten
Schnelle Prüfung einer URL	15-30 Min.	Status, Meta, grundlegende CWV, HTTPS und Hauptfehler
Kleine Unternehmenswebsite	2-6 Std.	Stichprobe, SEO, CWV, Barrierefreiheit, Sicherheit und UX
Inhalts- oder mehrsprachige Website	1-3 Tage	Vorlagen, Indexierung, hreflang, Links, Daten und Prioritäten
Onlineshop	3-7 Tage	Kategorien, Produkte, Filter, Checkout, strukturierte Daten, Performance
Webanwendung	5-10+ Tage	Rollen, Autorisierung, Abläufe, API, Fehlerzustände, manuelle Tests
Sicherheits-Audit mit hohem Risiko	eigener Umfang	Threat Modeling, ASVS, Anwendungs- und Infrastrukturtests

Die Kosten steigen weniger mit der reinen Zahl der URLs als mit der Zahl unterschiedlicher Verhaltensweisen. Tausend Produkte auf einer Vorlage können einfacher zu prüfen sein als eine Anwendung mit zehn Rollen und vielen Zuständen.

Wie sollten Korrekturen priorisiert werden?

Nutzen Sie ein einfaches Modell: Auswirkung × Reichweite × Risiko ÷ Implementierungskosten.

P0 - sofort beheben

• Website oder kritische Funktion ist nicht verfügbar,
• wichtige Bereiche sind von der Indexierung ausgeschlossen,
• Datenleck oder Umgehung der Autorisierung,
• abgelaufenes Zertifikat oder aktiver Mixed Content,
• Migration erzeugt massenhaft Fehler und verlorene URLs,
• Formular übermittelt keine Anfragen.

P1 - hohe Priorität

• schlechte CWV auf wichtigsten Vorlagen,
• ernsthafte Barrieren bei Tastatur und Formularen,
• falsche Canonicals oder hreflang,
• unklare Leistung und erschwerte Conversion,
• kritische, nicht aktualisierte Abhängigkeiten,
• kein Monitoring wichtiger Fehler.

P2 - im nächsten Zyklus einplanen

• doppelte Titel und schwache interne Links,
• fehlende Alternativtexte,
• schwere Bilder unterhalb des sichtbaren Bereichs,
• inkonsistente strukturierte Daten,
• schwache 404- und Leerzustände,
• Probleme weniger häufig genutzter Vorlagen.

P3 - Optimierung und Ausbau

• zusätzliche strukturierte Daten,
• weitere Gewichtsreduzierung,
• Tests von Texten und CTAs,
• Ausbau von Inhalten,
• Bereinigung von Komponenten und Dokumentation.

Reparaturplan für 30, 60 und 90 Tage

Erste 30 Tage

Beheben Sie P0-Probleme, Indexierung, Weiterleitungen, HTTPS, Formulare und Datenverluste. Legen Sie einen Ausgangswert für die Messung fest.

Bis Tag 60

Arbeiten Sie an den wichtigsten Vorlagen: Core Web Vitals, Tastaturbedienung, Formulare, Inhalte, interne Links und Anwendungssicherheit. Führen Sie Regressionsmonitoring ein.

Bis Tag 90

Verbessern Sie weniger kritische Vorlagen, standardisieren Sie den Veröffentlichungsprozess, integrieren Sie automatische Prüfungen in CI und planen Sie wiederkehrende Audits nach größeren Releases.

Vollständige Checkliste vor Abschluss des Audits

SEO und Indexierung

• Crawler können wichtige Seiten und Ressourcen abrufen.
• Die XML-Sitemap ist aktuell.
• Canonicals, Weiterleitungen und Links sind konsistent.
• Es gibt kein unbeabsichtigtes noindex.
• Wichtige Seiten besitzen eindeutige Titel, H1 und Inhalte.
• Interne Links führen zu geschäftlich relevanten Seiten.
• Sprachversionen verwenden korrektes hreflang.
• Strukturierte Daten entsprechen sichtbaren Inhalten.
• Open-Graph-Metadaten sind vollständig.

Performance

• LCP, INP und CLS erfüllen die Grenzwerte in Felddaten.
• Das LCP-Bild hat richtige Abmessungen und Priorität.
• JavaScript blockiert keine Interaktionen.
• Bilder haben Abmessungen und ein geeignetes Format.
• Fonts und kritische Ressourcen erzeugen keine vermeidbaren Verzögerungen.
• Ergebnisse werden nach Deployments überwacht.

Barrierefreiheit

• Die Website funktioniert ohne Maus.
• Fokus ist sichtbar.
• Semantik und Überschriftenreihenfolge sind logisch.
• Formulare besitzen Labels und hilfreiche Fehler.
• Kontrast und Reflow erfüllen WCAG 2.2 AA.
• Die Oberfläche wurde mit einem Screenreader geprüft.

Sicherheit und Datenschutz

• HTTPS funktioniert überall und das Zertifikat wird überwacht.
• Session-Cookies besitzen sichere Attribute.
• Header sind an die Anwendung angepasst.
• Berechtigungen werden serverseitig geprüft.
• Abhängigkeiten und Geheimnisse werden kontrolliert.
• Logs und Alerts ermöglichen eine Reaktion.
• Backups wurden getestet.
• Tracking-Skripte respektieren Einwilligungen.

UX und Geschäft

• Das Angebot ist verständlich, ohne die gesamte Seite zu lesen.
• CTAs führen zur vorgesehenen Aktion.
• Formulare und Checkout funktionieren mobil.
• Fehlerzustände helfen bei der Wiederherstellung.
• Ereignisse und Conversions werden korrekt gemessen.
• Jede Korrektur hat Verantwortlichen, Priorität und Termin.

Website-Zustandsprüfung von POLPROG nutzen

Mit der Website-Zustandsprüfung lässt sich ein Audit anhand einer URL starten und SEO, Performance, Barrierefreiheit, Sicherheit sowie Best Practices prüfen. Die Tests laufen serverseitig und erfordern keine Registrierung.

Ein sinnvoller Ablauf:

1. Startseite und jede wichtige Vorlage scannen.
2. Kritische Fehler und wiederkehrende Muster dokumentieren.
3. CWV mit echten Nutzerdaten bestätigen.
4. Tastatur, Formulare und zentrale Nutzerwege manuell testen.
5. Zusätzlich Sicherheitsheader, DNS und SSL sowie Open Graph prüfen.
6. Backlog nach Auswirkung und Risiko priorisieren.
7. Nach der Umsetzung erneut testen und Regressionen überwachen.

Fazit

Das beste Website-Audit im Jahr 2026 endet nicht mit einem Dokument voller hundert Warnungen. Es endet mit einer kurzen, geordneten Maßnahmenliste, die kritische Probleme von kosmetischen trennt, Verantwortlichkeiten festlegt und eine Erfolgskontrolle nach der Umsetzung ermöglicht.

Stellen Sie zuerst sicher, dass die Website verfügbar, indexierbar und sicher ist. Verbessern Sie danach die wichtigsten Nutzerwege, Core Web Vitals und Barrierefreiheit. Optimieren Sie erst anschließend kleinere Details. Diese Reihenfolge erzeugt meist mehr Wert als die Jagd nach einer perfekten Punktzahl in einem einzelnen Scanner.