KI-Website-Audit: Website mit KI-Agenten prüfen, vom Nachweis bis zur verifizierten Korrektur

1. Was ein KI-Website-Audit ist

Ein Website-Audit prüft, wie eine Website aufgebaut, ausgeliefert und angebunden ist: ob sie geschützt ist, ob Suchmaschinen und KI-Systeme sie lesen können, ob Menschen sie nutzen können, wie schnell sie ist und welche Drittanbieter-Dienste sie lädt. Ein KI-Website-Audit bringt einen KI-Agenten in diese Arbeit. Der Agent startet die Prüfungen, liest die Ergebnisse, erklärt sie in verständlicher Sprache, entscheidet mit Ihnen, was zuerst behoben wird, und schreibt die Änderungsanfrage für die Person oder den Coding-Agenten, der die Korrektur umsetzt.

Mit denselben Worten werden drei recht unterschiedliche Dinge beschrieben:

Dieser Leitfaden behandelt den dritten Ansatz, weil KI hier echte Zeit spart und jeder Befund an einen Nachweis gebunden bleibt, den Sie prüfen können. Die Prüfungen bleiben wiederholbar; der Agent ergänzt Urteilsvermögen, Kontext und die Übergabe an die Menschen und Tools, die Änderungen ausliefern. Wenn MCP neu für Sie ist, erklärt der MCP-Leitfaden Hosts, Clients, Server und Tools in einfachen Worten.

2. Was ein KI-Agent allein kann und was nicht

Ein Sprachmodell ist sehr gut im Lesen, Zusammenfassen und Schreiben. Ein Netzwerkwerkzeug ist es nicht. Solange die Anwendung ihm kein Tool für die Aufgabe gibt, sieht es unterhalb der sichtbaren Seite nicht, was ein Browser oder Crawler sieht. Die Tabelle vergleicht einen Agenten, der allein arbeitet (höchstens mit einem Browsing-Tool), mit demselben Agenten auf Basis strukturierter Prüfungen.

Coding-Agenten mit Terminal wie Claude Code, Codex oder Cursor können auch selbst curl, dig oder openssl ausführen. Das hilft, einen einzelnen Befund zu bestätigen, doch der Agent wählt die Befehle unterwegs: Die Abdeckung hängt davon ab, woran er denkt, die Ergebnisse schwanken zwischen Durchläufen, und nichts beschränkt seine Abfragen auf Domains, die Sie verifiziert haben.

Das Risiko in der mittleren Spalte hat einen Namen. Die OWASP-Liste der Risiken für LLM-Anwendungen beschreibt Fehlinformation (Misinformation) als falsche oder irreführende, aber glaubwürdig wirkende Ausgabe, wobei Halluzination eine der Hauptursachen ist und das Problem sich verschärft, wenn Menschen ihr ohne Überprüfung vertrauen. Im Audit sieht das so aus: „Ihre DMARC-Richtlinie steht auf none“ für eine Domain, deren Eintrag das Modell nie gelesen hat, oder ein fehlender Header, den der Server tatsächlich sendet.

Ein zweites Risiko kommt von den Seiten selbst. Ein Agent, der eine Website liest, liest nicht vertrauenswürdigen Text, und eine Seite kann Anweisungen an das Modell enthalten, mitunter vor menschlichen Besuchern verborgen. OWASP nennt das indirekte Prompt Injection. Ein sorgfältiger Audit-Aufbau behandelt Seiteninhalte als Daten, über die berichtet wird, nie als Anweisungen, und lässt jede Aktion des Agenten von einer Person freigeben.

Gut kann der Agent alles rund um den Nachweis: erklären, was ein Befund für genau diese Website bedeutet, verwandte Befunde bündeln, nach Kontext fragen, den die Prüfungen nicht kennen können (wird die alte Staging-Subdomain noch genutzt?), und eine Korrekturanfrage schreiben, die für einen Coding-Agenten präzise genug ist. Diese Arbeitsteilung ist der Kern eines guten KI-Website-Audits.

3. Die sechs Bereiche mit je einer Checkliste

Ein gründliches Website-Audit betrachtet sechs Ebenen. Jede beantwortet eine andere Frage und liefert eine andere Art von Nachweis. Der Leitfaden zum Website-Audit folgt einer Kundenreise durch alle sechs; hier die Arbeitscheckliste.

Sicherheit

• HTTPS und TLS: eine vertrauenswürdige Zertifikatskette, kein Ablauf in den nächsten Wochen, TLS 1.2 oder 1.3 und Weiterleitung von HTTP auf HTTPS.
• Security-Header: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Schutz vor Einbettung in Frames und eine Referrer-Policy bei HTML-Antworten.
• CORS: kein Access-Control-Allow-Origin: * bei Antworten mit privaten Daten und keine gespiegelten Origins in Kombination mit Credentials.
• DNS und E-Mail-DNS: gültige SPF- und DMARC-Einträge für jede Domain, die Mails versendet, und restriktive (v=spf1 -all, p=reject) für Domains, die nie Mails versenden.
• Öffentlich erreichbare Dateien und Secrets: nichts erreichbar unter Pfaden wie /.env, /.git/ oder alten Backups und keine API-Schlüssel im Frontend-JavaScript.
• Subdomains: keine DNS-Einträge, die auf gelöschte Cloud-Ressourcen zeigen und von anderen übernommen werden könnten (Subdomain-Takeover).
• Angriffsfläche: nur die vorgesehenen offenen Ports und HTTP-Methoden, bekannte Anmelde- und Admin-Seiten sowie ein aktuelles CMS samt Plugins, wenn Sie WordPress betreiben.
• Lieferkette: Skripte von Drittanbietern nur aus Quellen, die Sie gewählt haben.

Einige dieser Prüfungen lesen nur öffentliche Informationen. Andere, etwa die Abfrage sensibler Pfade oder Port-Scans, senden Anfragen, denen der Eigentümer zustimmen sollte; deshalb sollte ein Audit-Tool sie nur bei Zielen ausführen, deren Eigentum Sie verifiziert haben. Der Leitfaden zum Website-Sicherheitsaudit behandelt die Anwendungsseite: Konten, Berechtigungen und Anmeldung.

Technisches SEO

• Crawlbarkeit: robots.txt blockiert keine Seiten oder Ressourcen, die indexiert werden sollen.
• Indexierung: kein versehentliches noindex auf wichtigen Seiten und eine Sitemap mit den kanonischen URLs.
• Titel und Meta-Descriptions: vorhanden, eindeutig und passend zur Seite.
• Überschriften: eine klare Hauptüberschrift und eine logische Gliederung.
• Canonicals: jede Seite verweist auf ihre bevorzugte URL, nie auf eine Weiterleitung oder Fehlerseite.
• Strukturierte Daten: gültiges JSON-LD, das zum sichtbaren Inhalt passt.
• Interne Links und Weiterleitungen: wichtige Seiten über Navigation oder Inhalt erreichbar und keine Ketten aus mehreren Weiterleitungen.
• Search-Console-Daten: Seiten mit vielen Impressionen, aber niedriger Klickrate, und Suchanfragen, bei denen Sie knapp unter den Spitzenplätzen ranken. Das sind oft die schnellsten Gewinne.

Eine Einschränkung zählt hier. Google rendert JavaScript, bevor es eine Seite indexiert, empfiehlt in den Grundlagen von JavaScript-SEO aber weiterhin serverseitiges Rendering oder Pre-Rendering, unter anderem weil manche Bots kein JavaScript ausführen können. Ein Audit, das statisches HTML liest, sieht die Seite so wie diese Bots; bei einer Website, die ihre Inhalte im Browser aufbaut, vergleichen Sie die Befunde mit der gerenderten Seite. Der Leitfaden zum technischen SEO-Audit geht tiefer.

Bereitschaft für KI-Sichtbarkeit

• Richtlinie für KI-Crawler: Die robots.txt-Regeln für jeden KI-Crawler entsprechen Ihrer Entscheidung und nicht einer Plugin-Voreinstellung, die niemand gewählt hat. Mehrere Anbieter dokumentieren getrennte Tokens für Such- und Trainings-Crawler; Google beschreibt etwa Google-Extended neben seinen Such-Crawlern.
• llms.txt: optional. Ein kurzer Markdown-Index Ihrer nützlichsten Seiten, vor allem bei dokumentationslastigen Websites sinnvoll; der llms.txt-Leitfaden erklärt, was die Datei leistet und was nicht.
• Entitätsklarheit: überall derselbe Firmenname, dieselbe Beschreibung, derselbe Standort und dieselben Kontaktdaten, gestützt durch strukturierte Organization-Daten.
• Beantwortbarkeit: Seiten, die echte Kundenfragen direkt beantworten, weit oben, als Text statt in Bildern.
• Prompt-Abdeckung: eine Liste der Fragen, die Käufer einem Assistenten stellen, und zu jeder die Seite Ihrer Website, die sie beantwortet.
• Quellensignale: ein genannter Autor oder eine genannte Organisation, Datumsangaben und Quellenverweise, die eine Seite leicht zitierbar und zuordenbar machen.

Das sind Bereitschaftsprüfungen Ihrer eigenen Inhalte. Sie zeigen nicht, ob ein Assistent Sie heute zitiert; dafür braucht es ein separates Protokoll aus Fragen und Antworten. Google erklärt, dass seine KI-Funktionen über die normale Eignung für die Suche hinaus keine zusätzlichen Anforderungen stellen; Crawl-Zugang und klare Inhalte kommen also zuerst. Der Leitfaden zum KI-Sichtbarkeits-Audit zeigt, wie Sie das Fragenset aufbauen.

Barrierefreiheit

• Textalternativen: Jedes informative Bild hat einen aussagekräftigen Alt-Text, dekorative Bilder einen leeren.
• Formulare: Jedes Feld hat ein programmatisch verknüpftes Label, nicht nur Platzhaltertext.
• Struktur: Überschriften in korrekter Reihenfolge, Landmarks wie main und nav und ein Skip-Link.
• Namen: Jede Schaltfläche und jeder Link hat einen zugänglichen Namen, und es gibt keine leeren Links.
• Sprache: Die Seite deklariert ihre Sprache mit dem Attribut lang.
• Manuelle Prüfungen: Bedienung nur mit der Tastatur, sichtbarer Fokus, Farbkontrast, Zoom und Reflow sowie ein Durchgang mit Screenreader.

Das W3C stellt klar, dass Tools nicht alle Aspekte der Barrierefreiheit automatisch prüfen können und menschliches Urteil nötig ist. Eine automatische Prüfung findet das fehlende Label; nur ein Mensch beurteilt, ob das Label sinnvoll ist. Der Leitfaden zum Barrierefreiheits-Audit beschreibt den manuellen Durchgang nach WCAG 2.2.

Performance

• Core Web Vitals: Largest Contentful Paint innerhalb von 2,5 Sekunden, Interaction to Next Paint innerhalb von 200 Millisekunden und Cumulative Layout Shift von höchstens 0,1, jeweils am 75. Perzentil der Seitenaufrufe (web.dev).
• Zuerst Felddaten: Daten des Chrome UX Report zeigen, was echte Chrome-Nutzer in den vergangenen 28 Tagen erlebt haben, sofern die Seite oder Website genug Traffic hat, um aufgenommen zu werden; Lighthouse-Laborwerte helfen bei der Ursachensuche.
• Mobil zuerst: Testen Sie die mobile Version der wichtigen Seiten, etwa Startseite, Produkt- oder Leistungsseite und Checkout oder Kontaktformular.
• Übliche Ursachen: ein zu großes Hero-Bild, renderblockierende Skripte und Schriften, Layoutverschiebungen durch Bilder ohne Abmessungen oder spät eingeblendete Banner und schwere Drittanbieter-Tags.

Die Dokumentation von PageSpeed Insights weist darauf hin, dass Labor- und Felddaten voneinander abweichen können; ein guter Laborwert heißt nicht, dass echte Besucher ein gutes Erlebnis hatten. Der Leitfaden zum Website-Performance-Audit zeigt, wie Sie eine langsame Metrik mit dem verursachenden Element verbinden.

Integrationen

• Inventar: jedes Analytics-Tool, jeder Tag Manager, jedes Werbepixel, jedes Consent-Tool und jedes Tag zur Website-Verifizierung auf der Seite und wer jeweils dafür zuständig ist.
• Dopplungen und Altlasten: zwei Kopien desselben Analytics-Tags oder ein Pixel einer Kampagne, die im Vorjahr endete.
• Einwilligung: ein Consent-Tool, wo Sie eines brauchen, und Tags, die darauf warten.
• Personenbezogene Daten: keine E-Mail-Adressen, Telefonnummern oder Namen im Data Layer, in URLs oder Seitentiteln, die Tags auslesen. Die Analytics-Hilfe von Google bittet Website-Betreiber zum Beispiel, personenbezogene Daten aus URLs, Titeln und Ereignissen herauszuhalten.

Statische Prüfungen zeigen, was das Markup deklariert. Ob ein Tag tatsächlich auf die Einwilligung wartet oder welche Ereignisse nach einem Klick ausgelöst werden, erfordert eine Browsersitzung mit geöffneten Entwicklertools. Der Leitfaden zum Integrations-Audit führt durch diese Analyse.

4. Website mit KI prüfen: Schritt für Schritt

Das Model Context Protocol (MCP) ist ein verbreiteter Weg, wie eine KI-Anwendung Tools anderer Dienste aufruft. Mit einem angebundenen Audit-Dienst kann der Agent in Ihrem Chat- oder Coding-Tool Prüfungen ausführen und direkt mit den Ergebnissen arbeiten. Der Ablauf hat neun Schritte; die ersten beiden erfolgen einmal pro Website, der Rest wiederholt sich bei jedem Audit.

1. Verbinden. Fügen Sie den Audit-Dienst als MCP-Verbindung in Ihrem KI-Client hinzu und melden Sie sich im Browser an. Remote-MCP-Server mit Konto nutzen üblicherweise OAuth, wie in der MCP-Autorisierungsspezifikation beschrieben; Sie geben den Zugriff in einem Anmeldefenster frei und fügen nie ein Passwort oder einen API-Schlüssel in den Chat ein. Sitelemetry verbindet sich so in ChatGPT, Claude, Claude Code, Codex und Cursor; der MCP-Verbindungsleitfaden enthält die Schritte für jeden Client.
2. Umfang und Autorisierung festlegen. Entscheiden Sie, welche Websites und Seiten im Umfang liegen, und prüfen Sie nur Websites, die Ihnen gehören oder für die Sie eine schriftliche Testerlaubnis haben. Passive Prüfungen lesen, was jeder Besucher sehen kann; aktive Sicherheitsprüfungen senden Testanfragen und sollten erst laufen, nachdem Sie die Kontrolle über die Domain verifiziert haben. Nennen Sie dem Agenten den Umfang in klaren Worten: nur Produktion, diese drei URLs, keine Formularübermittlungen.
3. Audit ausführen. Fragen Sie nach einem vollständigen Audit oder einem Bereich: „Führe ein vollständiges Audit von https://www.example.com aus und liste die Befunde nach Schweregrad.“ Lange Audits laufen womöglich als Hintergrundjob; lassen Sie den Agenten auf das Ergebnis warten, statt einen zweiten Scan zu starten.
4. Nachweise lesen. Jeder Befund sollte Schweregrad, beobachteten Nachweis, Auswirkung und Maßnahme enthalten. Bitten Sie den Agenten, bei allem mit hoher Einstufung den Nachweis zu zitieren, und reproduzieren Sie ein bis zwei Befunde selbst mit curl -sI oder dig. Einen reproduzierbaren Befund können Sie mit gutem Gewissen beheben.
5. Priorisieren. Sortieren Sie nach Schweregrad, dann nach Exposition (ist die Seite öffentlich, geht es um Anmeldung oder Zahlung?), dann nach Aufwand. Bündeln Sie Befunde mit gemeinsamer Korrektur, etwa mehrere Header in derselben Serverkonfiguration, und fragen Sie den Agenten, welche Befunde für diese Website wichtig sind und welche hier wenig Risiko tragen.
6. Einen agentenfertigen Fix-Prompt an den Coding-Agenten übergeben. Machen Sie aus den gewählten Befunden eine präzise Änderungsanfrage mit Nachweis, Randbedingungen, Akzeptanzkriterien und Retest-Schritten (Beispiel unten). Geben Sie sie dem Coding-Agenten, der in Ihrem Repository arbeitet, oder lassen Sie denselben Client beides erledigen, wenn er Repository-Zugriff hat.
7. Über den normalen Prozess ausliefern. Prüfen Sie den Diff, testen Sie auf Staging und deployen Sie wie bei jeder Änderung. Das Audit ersetzt kein Code-Review, und ein Coding-Agent sollte nicht ohne Freigabe einer Person deployen.
8. Erneut auditieren, um zu verifizieren. Führen Sie nach dem Deployment dieselbe Prüfung am selben Ziel aus. Ein Befund ist geschlossen, wenn ein frisches Ergebnis ihn nicht mehr zeigt, nicht wenn der Agent meldet, er habe eine Datei geändert.
9. Überwachen. Planen Sie das Audit als Wiederholung, damit ein Plugin-Update, ein neues Tag oder ein ablaufendes Zertifikat auffällt, bevor Besucher es bemerken. Wöchentlich passt für die meisten kleinen Websites; Websites mit täglichen Deployments profitieren von täglichen Läufen.

Die MCP-Spezifikation empfiehlt einen Menschen im Prozess (Human in the Loop), der Tool-Aufrufe ablehnen kann, und OWASP führt übermäßige Handlungsfreiheit (Excessive Agency) als eigenes Risiko auf: schädliche Aktionen, wenn ein Agent mehr Funktionen, Berechtigungen oder Autonomie hat, als seine Aufgabe braucht. In der Praxis: Lassen Sie die Audit-Tools lesen und Codeänderungen sowie Deployments von einer Person freigeben.

Ein Fix-Prompt, mit dem ein Coding-Agent ohne Raten arbeiten kann, sieht so aus (illustratives Beispiel):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Jeder Teil hat eine Aufgabe. Der Nachweis sagt dem Coding-Agenten, was beobachtet wurde, damit er das Problem nicht neu entdecken muss. Die Randbedingungen halten die Änderung klein; HSTS mit kurzem max-age zu starten und ihn stufenweise zu erhöhen, ist der vorsichtige Weg, den der HSTS-Leitfaden beschreibt. Die Akzeptanzkriterien sind Befehle, die jeder ausführen kann, und der Retest-Schritt schließt den Kreis mit derselben Prüfung, die das Problem gefunden hat.

5. Ein KI-Website-Audit-Tool bewerten

Wer nach dem besten KI-Tool für ein Website-Audit sucht, findet lange Listen. Die richtige Wahl hängt von Ihrer Website ab, doch die Fragen, die ein nützliches KI-Audit-Tool von einem Chatbot mit angehängtem Scanner unterscheiden, sind für jedes Produkt dieselben.

Testen Sie dann jeden Kandidaten an Ihrer eigenen Website, bevor Sie sich darauf verlassen:

• Führen Sie ihn zweimal aus auf derselben Seite ohne Änderungen. Befunde und Schweregrade sollten übereinstimmen.
• Prüfen Sie drei Befunde von Hand, je einen aus Sicherheit, SEO und Barrierefreiheit, mit curl, dig oder dem Seitenquelltext.
• Bauen Sie auf Staging ein bekanntes Problem ein, etwa ein Bild ohne Alt-Text oder einen doppelten Titel, und sehen Sie, ob es gemeldet wird.
• Beheben Sie einen Befund und auditieren Sie erneut. Er sollte verschwinden, und nichts Unbeteiligtes sollte sich ändern.
• Lesen Sie die Grenzen. Einem Tool, das sagt, was es nicht prüft, ist leichter zu vertrauen als einem, das behauptet, alles zu prüfen.

Abschnitt 8 listet auf, was Sitelemetry abdeckt, wie es Korrekturen übergibt und wo seine Grenzen liegen.

6. Häufige Fallstricke und wie Sie sie vermeiden

Der rote Faden ist immer derselbe. Behandeln Sie den Agenten wie einen schnellen, eloquenten Kollegen, der den Server nie gesehen hat: Geben Sie ihm Nachweise, halten Sie seine Berechtigungen eng und prüfen Sie das Ergebnis auf der Live-Website.

7. Ein durchgespieltes Beispiel: die Website einer kleinen Praxis

Eine Zahnarztpraxis betreibt unter www.example-clinic.com eine WordPress-Website mit Online-Terminbuchung. Die Praxismanagerin verbindet einen Audit-Dienst mit ihrem KI-Assistenten, verifiziert die Domain und bittet um ein vollständiges Audit der Startseite und der Buchungsseite. Unter den Ergebnissen (illustrativ, keine echten Daten):

Der Agent erklärt, warum die ersten beiden zuerst kommen: Das Backup legt Daten für jeden offen, der den Pfad errät, und die Adresse im Tracking-Code wird an jedes Drittanbieter-Tag weitergegeben, das den Data Layer liest. Er fragt, ob die Sperre der KI-Crawler beabsichtigt war. Niemand hatte das entschieden, also wird daraus eine Entscheidung des Eigentümers statt einer Korrektur.

Beim Backup ist die Korrektur kein Code: Datei löschen, nach weiteren Kopien auf dem Server suchen und herausfinden, welcher Prozess sie erzeugt hat. Danach prüfen Sie die Zugriffsprotokolle auf frühere Downloads, ändern Passwörter oder Schlüssel, die im Backup enthalten waren, und folgen, falls Patientendaten offengelegt worden sein könnten, dem Verfahren der Praxis bei Datenschutzverletzungen. Für die Formular-Labels schreibt der Agent einen Fix-Prompt, der die fünf Felder und die Buchungsseite nennt, mit der Randbedingung, dass das visuelle Design unverändert bleibt, und dem Akzeptanzkriterium, dass ein Screenreader für jedes Feld ein Label ansagt. Der Coding-Agent des Entwicklers setzt die Änderung um, der Entwickler prüft und deployt sie, und ein erneutes Audit zeigt den Befund als behoben. Der DMARC-Eintrag geht an die Person, die das DNS verwaltet, beginnend mit p=none und Berichten, wie der DMARC-Rollout-Leitfaden erklärt. Jeder Punkt endet gleich: geändert, deployt und mit dem Audit, das ihn gefunden hat, erneut geprüft.

8. Diesen Ablauf mit Sitelemetry umsetzen

Sitelemetry ist ein KI-Website-Audit-Tool, gebaut für den Ablauf in diesem Leitfaden:

• Sechs Bereiche. Sicherheit mit bis zu 27 Modulen im Enterprise-Plan: DNS, SPF und DMARC, TLS, HTTPS-Status, Security-Header, CORS, öffentlich erreichbare Dateien, Offenlegung von APIs und Secrets, Subdomain-Takeover, Lieferkette, Anmeldefläche, offene Ports, HTTP-Methoden, WordPress und mehr. Technisches SEO, einschließlich Google-Search-Console-Klicks, CTR, Position und Quick Wins. Bereitschaft für KI-Sichtbarkeit, Barrierefreiheit, Performance über PageSpeed Insights, Lighthouse und CrUX-Felddaten sowie Integrationen.
• Nachweise und Korrekturen. Befunde enthalten Schweregrad, Nachweis, Auswirkung und Maßnahme, und jedes Audit kann einen agentenfertigen Fix-Prompt mit Randbedingungen, Akzeptanzkriterien und Retest-Schritten erzeugen.
• In Ihren KI-Tools. Es funktioniert über MCP mit OAuth-Anmeldung in ChatGPT, Claude, Claude Code, Codex und Cursor; der MCP-Verbindungsleitfaden zeigt, wie Sie sich verbinden. Die OAuth-Anmeldung bedeutet, dass Sie den Zugriff in einem Browserfenster freigeben und nie ein Passwort oder einen API-Schlüssel in den Chat einfügen.
• Verifizieren und überwachen. Auditieren Sie nach einer Korrektur erneut, um sie auf der Live-Website zu bestätigen. Je nach Plan läuft die Überwachung wöchentlich, täglich oder stündlich. Berichte lassen sich als JSON oder PDF exportieren, im Enterprise-Plan auch als White-Label-Berichte.
• Pläne. Starter für $49/Monat, Professional für $149/Monat und Enterprise für $249/Monat; die Preisseite listet, was jeweils enthalten ist.

Die Grenzen sind die, nach denen dieser Leitfaden Sie suchen lässt. Gehostete Audits beobachten das Ziel, ohne es zu verändern, und aktive Sicherheitsprüfungen laufen nur an verifizierten Zielen. Die Prüfungen zu SEO, KI-Sichtbarkeit, Barrierefreiheit und Integrationen lesen statisches HTML ohne JavaScript. Die KI-Sichtbarkeit prüft die Bereitschaft der Inhalte und befragt keine KI-Assistenten. Die Barrierefreiheitsprüfungen sind statisch und an WCAG 2.2 orientiert, keine vollständige manuelle Bewertung, und das Sicherheitsaudit ist kein Penetrationstest. Behalten Sie die manuellen Prüfungen aus Abschnitt 3 für das bei, was statische Analyse nicht sehen kann.