Wie Agenten meine eigene Website auditiert haben

TL;DR

Vier Bugs auf einem Handy-Screenshot und ein Befehl: /discovery all. Am 3. Juli 2026 habe ich meine eigene Website von mehreren Agenten-Läufen auditieren lassen, inklusive Live-Browser-Test, während ich Kaffee geholt habe. Aus Dutzenden Roh-Befunden wurden nach meiner Triage zwölf echte Issues, GitLab #257 bis #268. Die Agenten haben gefunden und belegt. Entschieden habe ich. Genau diese Arbeitsteilung ist der Punkt: Ein Werkzeug findet und beweist, der Mensch triagiert und gibt frei. Dieser Artikel zeigt, wie so ein Audit abläuft, was es fand, und warum die Triage-Bremse nicht wegzuoptimieren ist.

Das Problem: Eine Website altert im Blindflug

Eine Website ist nie fertig. Ich ändere Texte, tausche Bilder, ziehe eine Sektion um, deploye eine neue Variante. Jede einzelne Änderung ist harmlos. Die Summe über Monate ist es nicht. Irgendwann zeigt ein Video "nicht verfügbar", ein Button verschwindet auf dunklem Grund, eine Sitemap verweist ins Leere, und niemand merkt es, weil niemand systematisch hinschaut.

Der naive Weg ist: Ich klicke selbst durch, sehe drei Dinge, prompte einen Agenten, fixe, gehe weiter. Das skaliert nicht. Ich sehe, was mir auffällt, nicht, was kaputt ist. Und meine Aufmerksamkeit ist die knappste Ressource, die ich habe. Über die Verschiebung dieses Engpasses von der Produktion zur Prüfung habe ich in Der knappe Skill ist nicht Tippen, sondern Verifikation geschrieben.

Was fehlt, ist ein Verfahren, das breit und stur prüft, ohne dass ich jeden Klick selbst mache. Genau das leistet die /discovery-Skill in session-orchestrator, meinem eigenen Open-Source-Tool. Wie der Loop drumherum funktioniert, habe ich in Wie session-orchestrator als OSS-Tool in 9 Tagen reift beschrieben. Hier geht es um einen einzigen Lauf gegen ein einziges Ziel: meine eigene Website.

Ein Befehl, mehrere Probes

Der Auslöser war unspektakulär: ein Screenshot-Dump aus dem Handy, vier Dinge, die mir über Wochen aufgefallen waren, und der Verdacht, dass da mehr liegt. Ein Befehl:

/discovery all

Was dann läuft, sind mehrere parallele Probes, jede auf eine andere Fehlerklasse angesetzt: Code, Infrastruktur, UI, Architektur, die Live-Site im echten Browser, und SEO. Sie arbeiten nur lesend. Keine dieser Probes darf etwas ändern. Sie sammeln, belegen, verlinken die Fundstelle. Der Live-Browser-Teil ist der, der mich am meisten überrascht hat: Ein Agent öffnet die deployte Seite, rendert sie wirklich, und prüft berechnete Stile statt nur den Quellcode zu lesen. Genau dieser Lauf lief, während ich in der Küche stand und Kaffee holte.

Am Ende steht kein sauberes Ergebnis, sondern ein Haufen. Dutzende Roh-Befunde, viele davon Dubletten, manche Rauschen, manche echte Treffer. Das Tool dedupliziert und legt mir eine Liste vor. Meine Aufgabe beginnt genau hier: Aus dem Haufen wird durch Triage eine kurze, harte Liste. In diesem Fall zwölf Issues, die ich als GitLab #257 bis #268 angelegt habe.

Was die Läufe wirklich fanden

Vier der zwölf Befunde erzählen die Geschichte am besten, weil sie zeigen, welche Fehlerklassen ein Mensch beim Durchklicken zuverlässig übersieht:

Unsichtbare Buttons auf dunklen CTA-Flächen (#258). Auf den dunklen Call-to-Action-Slabs hatte die sekundäre Schaltfläche die Outline-Variante von shadcn. Auf dunklem Grund fiel die Buttonfarbe mit dem Hintergrund zusammen. Der Button war da, klickbar, und praktisch unsichtbar. Gefunden wurde das nicht im Code, sondern im Live-Browser: eine Prüfung der berechneten Stile, bei der die Textfarbe der Hintergrundfarbe entsprach. Ein statischer Code-Scan hätte den Button für vorhanden erklärt. Er war ja vorhanden. Nur eben nicht sichtbar.
CSP blockte die Badges auf der Manifest-Seite (#259). Die damalige Manifest-Seite lud Status-Badges von shields.io. Meine Content-Security-Policy erlaubte die Quelle nicht, also wurden die Badges still geblockt. Kein Fehler, kein Crash, nur ein leerer Fleck, den man beim schnellen Überfliegen nicht registriert.
YouTube-Embeds zeigten "Video nicht verfügbar" (#257). Auf den Uploads war das Einbetten deaktiviert. Das Video existierte und lief auf YouTube, nur eingebettet nicht. Ein toter Player mitten auf der Seite.
hreflang- und Sitemap-404s durch einen ungenutzten translationSlug (#260). Ein verwaister Übersetzungs-Slug in den Metadaten erzeugte hreflang-Verweise und Sitemap-Einträge auf Seiten, die es nicht gab. Für einen Besucher unsichtbar, für Suchmaschinen ein 404-Signal.

Keiner dieser vier Bugs wäre mir beim gemütlichen Durchklicken aufgefallen. Der unsichtbare Button ist per Definition unsichtbar. Die geblockte CSP-Quelle ist ein Nicht-Ereignis. Der tote hreflang-Verweis lebt in einer Datei, die kein Mensch freiwillig liest. Agenten sind hier nicht klüger als ich. Sie sind nur unermüdlich und schauen an Stellen, die ich überspringe.

Die Triage-Bremse: der Mensch entscheidet

Und hier kommt der Teil, der mir wichtiger ist als die Bug-Liste. Aus Dutzenden Roh-Befunden wurden zwölf Issues. Der Rest fiel raus, und zwar durch mich, nicht durch das Tool.

Ein Teil der Roh-Befunde waren Dubletten, also drei Probes, die denselben Fehler aus drei Winkeln melden. Ein Teil war schlicht falsch: plausibel formuliert, mit Fundstelle, und trotzdem kein echtes Problem. Genau das ist der gefährlichste Output, den ein Agent liefern kann, der nach Fund aussieht und keiner ist. Hätte ich jeden Befund blind in ein Issue gegossen, hätte ich mir zwei Dutzend Geistertickets gebaut und Zeit an Nicht-Problemen verbrannt.

Meine Regel ist deshalb hart und einfach: Ein Agent darf finden und belegen. Anlegen und fixen entscheide ich. Bei den vier Bugs oben habe ich vor dem Fix jeweils den Beleg geprüft, den berechneten Stil, den geblockten Request, den 404. Wo der Beleg trug, wurde es ein Issue. Wo nicht, wurde es verworfen.

Agenten finden und belegen. Entscheiden tue ich.

Das ist keine Zier. Es ist die Trennlinie zwischen einem Werkzeug und einem Vorgesetzten. Ein Audit-Lauf, der direkt in Fixes mündet, ohne dass ein Mensch triagiert, ist kein Fortschritt, sondern ein schnellerer Weg, Unsinn zu deployen. Die Läufe geben mir Reichweite. Die Triage gibt mir die Verantwortung zurück, die ich nicht abgeben kann und will.

Der Prozess ist das Produkt

Es gibt eine Pointe an dieser Geschichte, die mir mehr bedeutet als jeder einzelne Fix. Das Werkzeug, das meine Website auditiert hat, ist mein eigenes. session-orchestrator ist MIT-lizenziert, öffentlich unter github.com/Kanevry/session-orchestrator, und /discovery ist eine seiner Skills. Wenn du wissen willst, ob ich wirklich so arbeite, musst du mir nicht glauben. Du kannst das Tool lesen, installieren und denselben Lauf gegen deine eigene Seite fahren.

Das ist der Grund, warum ich diese Läufe überhaupt öffentlich beschreibe. Nicht weil vier gefixte Bugs eine Meldung wert wären, sondern weil der Prozess der Beleg ist. Ich zeige nicht ein poliertes Ergebnis, sondern die Werkbank: einen Befehl, mehrere Probes, einen Haufen Rohdaten, eine menschliche Triage, zwölf Issues, saubere Fixes. Kein Demo-Theater. Der echte Arbeitsstand.

Und es ist wiederholbar. Der nächste Lauf gegen meine Website wird andere Dinge finden, weil sich die Seite weiter verändert. Das Verfahren bleibt gleich. Genau das meine ich, wenn ich sage, der Prozess ist das Produkt: Nicht die eine Bug-Liste zählt, sondern die Fähigkeit, sie jederzeit wieder zu erzeugen, und die Disziplin, jeden Befund vor der Freigabe durch die menschliche Bremse zu schicken.

Fazit

Ein Website-Audit durch mehrere Agenten-Läufe ist breit und stur. Aber sein Wert entsteht erst an der Stelle, an der ein Mensch entscheidet:

Agenten finden, was der Mensch übersieht. Unsichtbare Buttons, geblockte Requests, tote hreflang-Verweise, verwaiste Sitemap-Einträge: Fehlerklassen, die kein Durchklicken zuverlässig fängt. Breite und Ausdauer sind die Stärke der Läufe.
Die Triage ist nicht wegzuoptimieren. Aus Dutzenden Roh-Befunden wurden zwölf echte Issues. Der Filter war ich, nicht das Tool. Der plausibel-falsche Befund ist der teuerste, wenn ihn niemand aussortiert.
Der Prozess ist der Beleg. Das Audit-Werkzeug ist Open Source und öffentlich. Wer zweifelt, fährt den Lauf selbst, und das ist ehrlicher als jede Folie.

KI ist auch hier ein Werkzeug: mächtig, aber kein Wunder. Sie verschafft mir Reichweite über die ganze Seite. Die Entscheidung, was davon zählt, bleibt bei mir.