Man sieht viele „SEO-Systeme mit einem Dutzend Agenten“. Schaut man genauer hin, was sie tun, lesen die meisten Daten, erzeugen eine Liste mit Empfehlungen und hören dort auf. Sie schreiben nichts auf die Website. Und vor allem messen sie nicht, was danach passiert ist.
Ich habe mir ein eigenes SEO-Autopilot-System gebaut, das ich Cortex nenne. Es läuft jeden Tag auf einem Server, auch wenn mein Rechner ausgeschaltet ist. Am meisten Zeit hat mich nicht der Teil mit den Agenten gekostet, sondern der Kreislauf: feststellen, handeln, prüfen, messen und beurteilen können, ob die Maßnahme überhaupt etwas gebracht hat.
Hier sind die Schritte, um ein solches System aufzubauen, was bei mir kaputtgegangen ist und wie ich es repariert habe. Ich nenne keine Zahlen aus meinem internen Journal: Was ich erzähle, ist Erfahrung, keine Messung. Die einzigen belegten Fakten stammen aus der Google-Dokumentation.
Das Wichtigste
Ein nützlicher SEO-Autopilot schließt den Kreislauf: Er stellt fest, handelt auf der Website, prüft live nach und misst dann vorher und nachher. Ohne Schreibzugriff und ohne Messung ist er ein Dashboard mit Vorschlägen.
Ein vom Texter unabhängiger Prüfer, der oft ablehnt, ist besser als eine nachsichtige Kontrolle. Bei mir hat er vor der Veröffentlichung einen irreführenden Preis gestoppt.
Laut der Google-Dokumentation kann es „einige Tage bis einige Wochen“ dauern, bis eine Änderung am Title berücksichtigt wird: Das Messfenster muss das einplanen.
Eine Seite, die während der Messung geändert wird, muss „ruhen“, sonst vermischen sich die Effekte. Ein Register manueller Änderungen verhindert, dass das System menschliche Arbeit überschreibt.
Die Kosten laufen schnell aus dem Ruder, wenn jeder Aufruf den gesamten Kontext des Tools neu lädt: Legen Sie ein Budget pro Lauf fest, zählen Sie es und protokollieren Sie es.
Was einen Autopilot von einem automatisierten Bericht unterscheidet
Ein automatisierter Bericht beantwortet die Frage „Was läuft schlecht?“. Ein Autopilot beantwortet drei weitere Fragen: Was ändern wir, ist die Änderung sicher, und hat sie funktioniert?
Die letzte Frage wird am häufigsten übersprungen. Ohne sie weiß man aber nicht, ob das System etwas verbessert oder nur herumhantiert. Mein Ausgangspunkt war dieser Gedanke: Eine Maßnahme ohne Messung vorher und nachher ist keine SEO-Maßnahme, sondern eine Wette.
Meine Architektur besteht aus einer Kette. Ein täglicher Job auf einem Server erstellt die Bestandsaufnahme (Search Console, PageSpeed, Indexierung). Ein Untersuchungsschritt geht den Auffälligkeiten nach. Danach durchläuft ein Aktionsagent pro Website: Plan, Texter, automatische Kontrollen, unabhängiger Prüfer, Sicherung, Schreibzugriff, Live-Nachprüfung und automatischer Rollback, falls die Kontrolle fehlschlägt. Jede Aktion wird in ein Register eingetragen. Eine Messung vergleicht die 28 Tage davor mit den 28 Tagen danach. Am Morgen erhalte ich ein Briefing mit genau einer Entscheidung, die ich treffen muss.
Schritt 1: verlässliche Daten und ihre Grenzen
Alles beginnt in der Search Console. Einige Punkte der Dokumentation verändern, wie man die Bestandsaufnahme aufbaut.
Zuerst die Position. Laut der Search-Console-Hilfe zum Leistungsbericht ist die angezeigte Position die höchste, die ein Link Ihrer Website einnimmt, gemittelt über die betreffenden Suchanfragen, und die CTR ist das Verhältnis von Klicks zu Impressionen. Eine durchschnittliche Position ist also kein stabiles Ranking: Man muss sie mit Vorsicht lesen.
Dann Aktualität und Datenmenge. Die Dokumentation der Search-Analytics-API besagt, dass die Daten in der Regel nach zwei bis drei Tagen verfügbar sind, dass die API höchstens 50 000 Zeilen pro Tag und Suchtyp liefert und dass sich die Ergebnisse per Paginierung in Schritten von 25 000 Zeilen abrufen lassen. Sie weist außerdem darauf hin, dass das System Daten auslassen kann, wenn man nach Seite und Suchanfrage gruppiert, und dass man für exakte Summen diese Dimensionen weglassen muss. Praktische Folge: Vergleichen Sie nie eine exakte Summe mit einer Summe von Zeilen, und messen Sie nicht auf den letzten drei Tagen.
Für die Indexierung liefert die URL-Inspection-API den Status der Version, die im Google-Index vorliegt. Sie testet keine Seite live. Mein Agent darf daraus also nicht schließen „die Seite ist indexierbar“: Er stellt fest, was Google gespeichert hat, nicht, was die Website heute ausliefert.
Schritt 2: herausfinden, was bearbeitet werden soll
Meine Suche nach Quick Wins ist bewusst einfach. Ich suche Seiten nahe der ersten Ergebnisseite, deren CTR deutlich unter der der anderen Seiten derselben Website auf gleicher Position liegt, die Marke ausgenommen. Die Idee: eine Website mit sich selbst bei gleicher Position vergleichen, statt mit einer durchschnittlichen CTR-Kurve aus dem Netz.
Die Marke auszunehmen ist ein methodischer Punkt. Markenanfragen haben eine ganz andere CTR und würden das Signal überdecken. Eine Seite, die bei gleicher Position schwächer abschneidet, hat oft einen Title oder eine Description, die nicht neugierig macht oder die Suchintention nicht trifft.
Diese Suche liefert Kandidaten, keine Entscheidungen. Der Untersuchungsschritt prüft, ob die Seite wirklich indexiert ist, ob sie die Suchanfrage beantwortet und ob keine andere Seite der Website dasselbe anvisiert.
Schritt 3: Agenten, die schreiben, und ein Prüfer, der ablehnt
Hier hören die meisten Demonstrationen auf. Einen Agenten schreiben zu lassen ist leicht. Ihn schreiben zu lassen, ohne die Website zu beschädigen, ist die eigentliche Arbeit.
Mein Aufbau trennt die Rollen. Ein Agent plant. Ein Texter macht einen Vorschlag. Automatische Kontrollen prüfen, was sich per Code prüfen lässt (Länge, Format, Vorhandensein der Pflichtelemente). Dann beurteilt ein unabhängiger Prüfer, der den Text nicht geschrieben hat, ob er veröffentlichungsreif ist.
Dieser Prüfer lehnt oft ab, und das ist gewollt. Er hat vor der Veröffentlichung einen irreführenden Preis entdeckt. Er hat auch Texte abgelehnt, die die Seite nur umschrieben, statt etwas beizutragen. Ein Texter, der sich selbst gegenliest, winkt fast alles durch.
Wenn der Prüfer ablehnt, entschärfe ich ihn nicht. Stattdessen bekommt der Texter die letzten Ablehnungsgründe, um daraus zu lernen. Eine laxere Kontrolle erhöht die Veröffentlichungsquote, und genau die sollte man nicht optimieren.
Nach der Freigabe folgen die Sicherung des vorherigen Zustands, das Schreiben und dann die Live-Nachprüfung: Das System lädt die veröffentlichte Seite neu und kontrolliert, dass die Änderung wirklich da ist und sich sonst nichts verändert hat. Schlägt die Kontrolle fehl, erfolgt der Rollback automatisch. Ohne diesen letzten Baustein würde ich nie einen Agenten schreiben lassen.
Schritt 4: messen und die Messung schützen
Die Messung vergleicht ein Fenster vor und ein Fenster nach der Aktion auf der betreffenden Seite. Zwei Vorsichtsmaßnahmen habe ich teuer lernen müssen.
Die Seite ruhen lassen
Wenn man eine Seite während des Messfensters erneut anfasst, weiß man nicht mehr, welche Änderung was bewirkt hat. Das System erzwingt deshalb eine Ruhephase: Eine geänderte Seite wird nicht mehr angefasst, bis ihre Messung abgeschlossen ist.
Um die Dauer festzulegen, muss man auch die Verzögerung auf Seiten von Google kennen. Laut der Dokumentation zu Title Links muss Google die Seite erneut crawlen und verarbeiten, was „einige Tage bis einige Wochen“ dauern kann. Dieselbe Seite weist darauf hin, dass Google einen anderen Titel erzeugen kann als den, den man geschrieben hat, wenn es den Title für nicht repräsentativ für die Seite hält. Ein geänderter Title ist also nicht zwangsläufig ein angezeigter Title: Das System muss das feststellen können.
Der Tag, an dem der Pilot fast meine Arbeit überschrieben hätte
Erste erlebte Schwachstelle: Der Pilot sah nur seine eigenen Aktionen. Er hätte beinahe eine Seite neu geschrieben, die ich ein paar Tage zuvor von Hand geändert hatte. Er wusste nicht, dass sie „in Ruhe“ war, denn ich hatte sie angefasst, nicht er.
Die Lösung ist ein Register manueller Änderungen, das der Pilot vor jeder Entscheidung liest. Sobald ich eine Seite von Hand ändere, trage ich sie dort ein. Elegant ist das nicht, aber es löst das Problem.
Aktionen ohne URL
Zweite Falle: Manche Aktionen betreffen Dateien wie llms.txt, die Sitemap oder robots.txt. Sie haben keine Seiten-URL, also keine Messung pro Seite. Man kann sie nur auf Website-Ebene verfolgen, und der Effekt lässt sich kaum zuordnen. Ich halte sie im Register fest, behaupte aber nicht, ihr Ergebnis zu messen.
Schritt 5: die Kosten, bevor sie Sie überraschen
Meine ersten Tests haben viele Tokens verbrannt. Der Grund: Jeder Aufruf lud den gesamten Kontext des Tools neu, mit Anweisungen, Konfigurationsdateien und Verlauf, obwohl die Aufgabe nur drei Zeilen Kontext verlangte.
Ich bin auf einen minimalen Kontext umgestiegen: Jeder Agent erhält, was er für seine Aufgabe braucht, und sonst nichts. Die allgemeinere Lehre: ein Budget pro Lauf, vorab festgelegt, gezählt und protokolliert. Wird es überschritten, stoppt der Lauf und warnt mich. Kein stillschweigender Ausgleich.
Schritt 6: den Menschen dort behalten, wo es zählt
Das Morgenbriefing enthält für mich nur eine Entscheidung. Alles andere ist entweder erledigt und geprüft oder mit Begründung verworfen.
Bei einer sensiblen Kundenwebsite behalte ich das Go. Manche Websites bleiben im reinen Vorschlagsmodus: Das System stellt fest, untersucht, formuliert, schreibt aber nicht. Autonomie verdient man sich Website für Website, nicht auf einen Schlag.
Ein laufendes Beispiel: mesfrais.pro
Auf meiner eigenen Website mesfrais.pro habe ich die Titles einer Seitenvorlage neu schreiben lassen. Der unabhängige Prüfer hat die erste Version abgelehnt: Der Text versprach auf manchen Seiten zu Unrecht einen steuerlichen Vorteil. Ein Mensch unter Zeitdruck hätte es vielleicht durchgehen lassen.
Anschließend habe ich den Umfang auf den Title allein reduziert, um den Effekt zu isolieren. Keine gleichzeitige Änderung des Inhalts. Der Rollback ist bereit.
Ein Ergebnis habe ich noch nicht. Das Messfenster ist nicht abgeschlossen, und wenn es das ist, wird es nur sagen, was auf diesen Seiten passiert ist, nicht, was anderswo passieren würde. Ich schreibe es lieber so auf, als einen Gewinn zu verkünden, bevor es so weit ist.
Was ich am Montagmorgen tun würde
Mit nur einer Art von Aktion beginnen, etwa den Titles einer Vorlage. Ein enger Umfang macht die Messung lesbar.
Das Register vor dem Agenten schreiben: Aktionen des Systems, manuelle Änderungen, Daten, Zustand vorher. Der Pilot liest es vor jeder Entscheidung.
Texter und Prüfer trennen, mit einer Vorgabe für den Prüfer, die davon ausgeht, dass der Text abzulehnen ist. Ihn nicht entschärfen, wenn er viel ablehnt.
Den Rollback vor dem ersten Schreibzugriff einplanen und die Live-Nachprüfung direkt danach.
Die Ruhephase der Seiten festlegen und die Länge des Messfensters, unter Berücksichtigung der von Google beschriebenen Verzögerungen.
Ein Budget pro Lauf festlegen und den Kontext jedes Aufrufs auf das Nötigste reduzieren.
Den reinen Vorschlagsmodus beibehalten auf Websites, bei denen ein Fehler teuer wird.
Grenzen
Dieser Beitrag erzählt von einem System, das ich für meine Bedürfnisse gebaut habe. Ich nenne keine internen Zahlen, Sie können seine Wirksamkeit also nicht auf mein Wort hin beurteilen, und ich behaupte nicht, dass es den Traffic verbessert. Mein einziger ausführlich beschriebener Fall hat noch kein Ergebnis.
Der Vergleich von 28 Tagen davor und danach bleibt ein einfacher Vergleich. Er neutralisiert weder Saisonalität noch Google-Updates noch die Tatsache, dass Google einen Title umschreiben kann. Ein Anstieg nach einer Aktion ist kein Beweis, dass die Aktion die Ursache ist.
Schließlich geben die zitierten Punkte der Dokumentation den Stand zum Zeitpunkt dieses Artikels wieder und können sich ändern. Auf den von mir geöffneten Seiten nennt diese Dokumentation kein genaues Kontingent für die URL-Inspection-API: Prüfen Sie es, bevor Sie einen Job dimensionieren.