Der SEO-Audit wird schneller. Die Prüfung nicht.

Automatisieren Sie noch – oder prüfen Sie nur schneller?

Diese Frage entscheidet darüber, ob ein KI-Agent Arbeit abnimmt oder lediglich mehr Output produziert. Ein technischer SEO-Audit eignet sich grundsätzlich für Automatisierung, weil viele Prüfungen festen Kriterien folgen, die benötigten Daten reproduzierbar abrufbar sind und jeder belastbare Befund auf eine konkrete Quelle zeigen kann; schwierig wird es erst bei seiner Bedeutung für dieses Unternehmen, zu diesem Zeitpunkt, unter diesen technischen und wirtschaftlichen Bedingungen.

Genau dort endet die Routine.

Ich nutze ein Team aus spezialisierten KI-Agenten, um technische Audits vorzubereiten. Das System sammelt Daten, verteilt Aufgaben und formuliert Befunde. Es darf den fertigen Report jedoch nicht ungeprüft ausliefern. Zwischen Analyse und Kunde liegen ein Gegencheck gegen Live-Quellen und meine persönliche Freigabe.

Dieser Artikel basiert auf einem neunminütigen Video, das ich für den SEO-Club von Marie Haynes aufgenommen habe. Darin ist der Ablauf an einem technischen Audit von mariehaynes.com zu sehen: Auftrag, Delegation, Prüfung, Korrekturschleife und Freigabe.

▶ Auf YouTube ansehen

1. Automatisieren Sie nur Prüfungen mit einem klaren Soll-Zustand

Ich automatisiere eine Prüfung nur, wenn die Aufgabe eine prüfbare Antwort besitzt. Ist die Seite ohne JavaScript lesbar? Liefert die robots.txt einen HTTP-Status 200? Enthält das HTML ein bestimmtes Schema-Markup? Erreicht ein definierter Bot die Seite? Für solche Fragen lassen sich Datenquelle, Prüfschritt und erwartetes Ergebnis vorab festlegen.

„Analysiere die Website und finde SEO-Probleme“ ist dagegen keine brauchbare Arbeitsanweisung. Der Satz lässt offen, welche Bereiche zählen, welche Werkzeuge der Agent verwenden soll und wann ein Befund als belegt gilt. In meinem Prozess gilt der daraus entstehende Befund deshalb als unbelegt.

Schlecht: „Prüfe die technische SEO-Qualität der Website.“

Besser: „Rufe robots.txt und die XML-Sitemap live ab. Dokumentiere pro URL den HTTP-Status, den Abrufzeitpunkt und die relevante Antwortzeile. Trenne bestätigte Fehler von Hinweisen, die eine manuelle Prüfung brauchen.“

Warum ist die zweite Fassung besser? Sie definiert Quelle, Handlung und Beleg. Der Agent muss weniger erraten.

Meine wichtigste Vorarbeit steckt deshalb nicht im Prompt, sondern in den Skills und Instruktionen des Systems. Dort stehen die einzelnen Prüfschritte, erlaubte Werkzeuge, Ausgabeformate und Abbruchkriterien. Diese Denkarbeit nimmt mir kein Modell ab. Ohne ein sauberes Verfahren automatisiert der Agent nur Unklarheit.

2. Trennen Sie Delegation, Fachanalyse und Qualitätsprüfung

In meinem Setup arbeitet kein einzelner Universal-Agent den gesamten Audit ab. Ein Lead verteilt die Aufgaben an Agenten mit festen Rollen und eigenen Werkzeugrechten. Ich habe sie nach Figuren aus „The Office“ benannt – eine trockene Organisationshilfe, aber eine erstaunlich merkfähige.

Michael koordiniert den Auftrag, Dwight prüft Crawling, Schema-Daten, Bot-Zugriffe und robots.txt, Pam bearbeitet Content und E-E-A-T, Oscar zieht Daten aus Analytics, der Google Search Console und per Model Context Protocol angebundenen Werkzeugen, während Angela ausschließlich die Qualitätssicherung übernimmt.

Entscheidend ist die Rollentrennung.

Im Video erhält Michael den Auftrag für den technischen Audit, erstellt zuerst einen Delegationsplan und wartet auf meine Freigabe; erst danach schickt er die Fachaufgabe an Dwight, dessen Analyse anschließend bei Angela landet und bei einem gescheiterten Gegencheck in die Korrekturschleife zurückgeht. Das finale Dokument entsteht erst nach bestandener Prüfung.

Warum nicht ein Agent für alles? Produktion und Kontrolle fänden sonst im selben Kontext statt. Ein separater Prüfer erhält einen engeren Auftrag: Behauptung lesen, Originalquelle öffnen, Ergebnis bestätigen oder zurückweisen.

Die Trennung erzwingt einen separaten Gegencheck. Sie beweist weder Unabhängigkeit noch eine niedrigere Fehlerquote. Zwei Agenten können denselben Fehler machen.

3. Prüfen Sie jede Zeile gegen die Live-Quelle

Das eigentliche Nadelöhr eines Audits ist nicht die Datensammlung. Es ist die Interpretation.

Ein Sprachmodell schreibt überzeugend über einen Crawl, den es nie gesehen hat. Es kann eine Korrelation als Ursache ausgeben oder eine fehlende Information mit einer fachlich klingenden Erklärung ergänzen. Die Prosa bleibt sauber. Der Befund bleibt falsch.

Angela darf sich deshalb nicht auf Modellwissen verlassen, sondern muss die Quelle erneut abrufen – als aktuellen HTTP-Request, reales HTML, jüngsten Snapshot oder Originalwert aus dem angebundenen Werkzeug – und jeden Befund gegen genau den Nachweis prüfen, den ein anderer Fachmann später selbst öffnen und nachvollziehen könnte. Danach gibt es für jede Aussage nur drei mögliche Ergebnisse:

1. Der Beleg bestätigt die Aussage. Sie bleibt stehen.
2. Der Beleg zeigt einen konkreten Fehler. Die Aussage geht mit Korrektur zurück.
3. Der Beleg reicht nicht aus. Die Aussage fliegt aus dem Report oder wird ausdrücklich als offene Hypothese markiert.

Im Video besteht Dwights erster Bericht diese Prüfung nicht. Angela bestätigt einzelne Punkte mit Belegen, weist andere zurück und gibt den Audit an Michael zurück. Dwight arbeitet die Hinweise ein. Danach beginnt ein neuer Gegencheck. Der erste, gut formulierte Report war also nicht „fast fertig“. Er war ungeprüft.

Ein Prompt für die erste Selbstkontrolle

Auch ohne Agenten-Team können Sie einen zweiten Prüfpass einbauen. Dieser Prompt dient der Suche nach Widersprüchen, Lücken und unklaren Formulierungen:

Lies deine Antwort erneut. Prüfe sie nach drei Kriterien:

1. Richtigkeit: Welche Tatsachenbehauptung ist nicht direkt durch die
   bereitgestellte Quelle belegt?
2. Vollständigkeit: Welche Information fehlt, damit ein Fachmann den
   Befund reproduzieren kann?
3. Klarheit: Welche Formulierung könnte ein Leser ohne den bisherigen
   Gesprächskontext missverstehen?

Liste zuerst die Fundstellen. Schlage danach konkrete Änderungen vor.
Erfinde keine fehlenden Belege.

Der Prompt ersetzt keinen Faktencheck. Das Modell kann damit die eigene Antwort auf innere Widersprüche prüfen, aber keine nicht geladene Quelle verifizieren. Für Tatsachenbehauptungen braucht es weiterhin den Live-Abruf.

4. Schicken Sie Kundendaten nicht ungefiltert an ein Cloud-Modell

Für komplexe Aufgaben nutze ich Cloud-Modelle. Namen, Domains und andere sensible Angaben sollen dort trotzdem nicht als Klartext landen. In meinem Ablauf sitzt deshalb ein lokal betriebenes Modell über Ollama vor dem externen Modell. Es ersetzt die sensiblen Werte durch Platzhalter wie {{KANZLEI}} oder {{HAUPTDOMAIN}}.

Das Cloud-Modell bearbeitet anschließend die abstrahierte Struktur. Die Zuordnung zwischen Platzhalter und echtem Wert bleibt lokal. Erst bei der Zusammenführung auf meiner Maschine setzt das System die Werte zurück.

Die Grenze gehört offen dazu: Eine Pseudonymisierung macht aus einem externen Modell keine lokale Verarbeitung. Projektart, Branchenkontext oder technische Struktur können trotz Platzhaltern erkennbar bleiben. Der Prozess braucht deshalb eine Datenklassifizierung vorab. Hochsensible Inhalte gehören nicht in den Cloud-Pfad, nur weil ein Name ersetzt wurde.

Auch die Rückersetzung ist ein Fehlerpunkt. Stimmen Platzhalter nicht exakt überein oder taucht ein echter Wert bereits in einem Log auf, bricht die Schutzannahme. Ich prüfe deshalb nicht nur den Modelloutput, sondern auch den Weg dorthin.

5. Behalten Sie Priorisierung und Endabnahme beim Menschen

Agenten eignen sich für wiederholbare Standard-Checks. Strategische Beratung ist eine andere Arbeit.

Ein Modell kann melden, dass eine wichtige Seite nur nach JavaScript-Ausführung lesbar ist. Es kennt damit noch nicht die internen Release-Zyklen, den Umsatzbeitrag der Seite oder den Aufwand einer Änderung im bestehenden Stack. Aus dem technischen Befund folgt nicht automatisch die richtige Priorität.

Drei Entscheidungen bleiben bei mir. Erstens bewerte ich Kausalität: Verursacht der gefundene Fehler tatsächlich das beobachtete Problem, oder tritt beides nur gleichzeitig auf? Zweitens priorisiere ich nach geschäftlicher Wirkung und Umsetzbarkeit. Drittens hinterfrage ich die Datenbasis selbst. Ein Crawl hinter einer Firewall kann technisch korrekt ausgeführt und trotzdem nicht repräsentativ sein.

Bevor ein Report den Kunden erreicht, lese ich Strategie, Befunde und Wortlaut, prüfe jede Zahl auf eine durchgehend gleiche Definition, vergleiche Schlussfolgerung und Beleg und entscheide schließlich, ob die vorgeschlagene Priorität zum Unternehmen, zu seinen Release-Zyklen und zum erwartbaren Geschäftsnutzen passt. Erst dann gebe ich das Dokument frei.

Wann lohnt sich der Aufbau? Wenn ein Prozess regelmäßig wiederkehrt, feste Eingaben besitzt und sich jedes Ergebnis gegen eine Originalquelle prüfen lässt. Für einmalige Analysen mit unklarer Datenlage kostet die Agenten-Architektur oft mehr Zeit, als sie spart. Dann ist ein sauber geführter Einzelagent oder Handarbeit die bessere Wahl.

Die Automatisierung verändert damit mein Skillset. Weniger Zeit fließt in das mechanische Sammeln und Formatieren. Mehr Zeit fließt in Prüfkriterien, Quellenkontrolle und Priorisierung. Der Audit wird schneller. Die Verantwortung nicht.

Häufige Fragen

Kann ein KI-Agent einen technischen SEO-Audit vollständig übernehmen?

Ein KI-Agent kann standardisierte Prüfungen ausführen, Daten sammeln und einen ersten Report formulieren. Er ersetzt weder die unabhängige Kontrolle gegen Live-Quellen noch die geschäftliche Priorisierung. In meinem Prozess erreicht kein Report den Kunden ohne persönliche Endabnahme.

Reicht ein zweiter Prompt als Faktencheck?

Nein. Ein zweiter Prompt kann Widersprüche oder fehlende Angaben in einer Antwort sichtbar machen. Tatsachen lassen sich damit nur prüfen, wenn der Agent die Originalquelle tatsächlich neu abruft und den Befund dagegen vergleicht. Modellwissen ist keine Live-Quelle.

Welche SEO-Aufgaben eignen sich für Agenten?

Geeignet sind wiederkehrende Checks mit klaren Kriterien: HTTP-Status, robots.txt, XML-Sitemaps, Bot-Zugriffe, JavaScript-Abhängigkeiten oder Schema-Markup. Weniger geeignet sind strategische Entscheidungen, bei denen Umsatzwirkung, interne Abläufe und unvollständige Daten gegeneinander abgewogen werden müssen.

Schützt lokale Anonymisierung alle Kundendaten?

Nein. Platzhalter halten direkte Identifikatoren aus dem Cloud-Prompt heraus, doch Struktur und Kontext des Projekts können erkennbar bleiben. Sensible Daten brauchen deshalb eine vorgelagerte Klassifizierung. Nicht jeder Inhalt darf den lokalen Verarbeitungspfad verlassen.

Sie möchten einen technischen SEO- oder GEO-Prozess auf Automatisierung prüfen, ohne die Kontrolle an das Modell abzugeben? Schreiben Sie mir. Ich trenne mit Ihnen zuerst die standardisierbaren Prüfungen von den Entscheidungen, die menschliche Verantwortung brauchen.