Zum Inhalt springen
Bernhard Götzendorfer
KI Deep Dives

Wie Agenten meine eigene Website auditiert haben

Ein /discovery-Lauf, mehrere parallele Agenten, ein Live-Browser-Test: Wie ich meine eigene Website prüfen ließ, und warum am Ende ein Mensch entscheidet.

Kontaktbogen aus sechs echten Audit-Screenshots der Website in Desktop- und Mobilansicht

TL;DR

Am 3. Juli 2026 ließ ich mit einem einzigen /discovery all-Befehl mehrere schreibgeschützte Prüfungen über meine Website laufen. Der Lauf untersuchte Code, Infrastruktur, Oberfläche, die veröffentlichte Seite und SEO. Aus Dutzenden Rohbefunden wurden nach manueller Triage zwölf GitLab-Issues. Vier Beispiele zeigen, warum beide Schritte wichtig sind: Die Agenten deckten mehr Flächen ab als ein einzelner Browserlauf, und ich verwarf Dubletten und falsche Befunde, bevor etwas geändert wurde.

Warum ich den Lauf gestartet habe

Der Auslöser waren ein Satz Handy-Screenshots und vier Dinge, die mich seit einigen Wochen störten. Die Seite hatte sich durch viele kleine Änderungen an Text, Bildern und Layout weiterentwickelt. Ich wollte einen gemeinsamen Durchlauf über Repository und veröffentlichte Seiten, statt jede Fläche einzeln zu prüfen.

Dafür nutzte ich den /discovery-Skill aus session-orchestrator, meinem MIT-lizenzierten Orchestrierungswerkzeug. Den größeren Ablauf beschreibe ich in Wie session-orchestrator in 9 Tagen reifte. Hier geht es um einen einzelnen Lauf gegen diese Website.

Ein Befehl, mehrere schreibgeschützte Prüfungen

Der Befehl lautete:

/discovery all

Er startete parallele Prüfungen für Code, Infrastruktur, Oberfläche, Architektur, Live-Seite und SEO. Die Probes durften nichts verändern. Sie lieferten Befunde mit Fundstelle oder Browserbeobachtung zurück.

Die Live-Browser-Prüfung renderte die veröffentlichten Seiten und untersuchte die berechneten Stile. Damit findet sie andere Fehler als ein reiner Quellcode-Scan. Am Ende standen Dutzende Befunde. Einige beschrieben denselben Fehler aus verschiedenen Richtungen, andere hielten einer Kontrolle nicht stand. Nach der Triage legte ich zwölf Issues als GitLab #257 bis #268 an.

Vier Befunde aus dem Lauf

  • Unsichtbare Buttons auf dunklen CTA-Flächen (#258). Der sekundäre Button verwendete die Outline-Variante von shadcn. Seine Farbe verschmolz mit dem dunklen Hintergrund. Er war vorhanden und klickbar; erst die Prüfung der berechneten Stile zeigte, dass Text- und Hintergrundfarbe übereinstimmten.
  • CSP blockierte Badges auf der Manifest-Seite (#259). Die Seite lud Status-Badges von shields.io, doch die Content Security Policy erlaubte diese Quelle nicht. Statt einer sichtbaren Fehlermeldung blieb eine leere Fläche.
  • YouTube-Embeds zeigten „Video nicht verfügbar“ (#257). Die Uploads liefen auf YouTube, das Einbetten war aber deaktiviert.
  • hreflang- und Sitemap-Verweise führten zu 404 (#260). Ein ungenutzter translationSlug erzeugte Links auf Seiten, die nicht existierten.

Die Beispiele stammen aus verschiedenen Schichten: CSS, Browserrichtlinie, externe Medienkonfiguration und Content-Metadaten. Genau diese Streuung machte mehrere fokussierte Prüfungen in einem Lauf nützlich.

Manuelle Triage

Ich prüfte die Rohbefunde, bevor ich daraus ein Issue oder einen Fix machte. Dubletten wurden zusammengeführt. Bei den vier Beispielen kontrollierte ich die berechneten Stile, den blockierten Request, das Verhalten des Players und die 404-Antworten. Befunde ohne ausreichenden Beleg verwarf ich.

Diese Trennung bleibt im Ablauf ausdrücklich bestehen: Agenten sammeln und prüfen; ich entscheide, welcher Befund Arbeit wird. Auch ein plausibel formulierter Bericht kann ein Nicht-Problem beschreiben. Deshalb führt ein Audit-Ergebnis nicht direkt zu einem automatischen Fix.

Den Lauf wiederholen

Der /discovery-Skill liegt im öffentlichen Repository von session-orchestrator. Er kann auch gegen andere Websites laufen, wobei die sinnvollen Prüfungen von Stack und Deployment abhängen. Mein nächster Lauf wird eine andere Liste liefern, weil sich diese Seite weiter verändert.

Der wiederholbare Ablauf ist einfach: fokussierte Probes ausführen, Fundstellen behalten, die gemeinsame Liste triagieren und danach die bestätigten Punkte beheben. KI-Output verlässlich prüfen behandelt dasselbe Review-Prinzip außerhalb von Website-Audits.

Die Agenten vergrößerten die Fläche, die ich in einem Lauf prüfen konnte. Die manuelle Triage reduzierte das Ergebnis auf zwölf Issues, für die ich Verantwortung übernehmen konnte. Beides war für dieses Audit nötig.