SEO- und GEO-Experimente mit Claude Code und einer Kontrollgruppe

Was der Loop für SEO-Experimente tut

SEO-Experimente sagen nur dann etwas aus, wenn sich die geänderten Seiten stärker bewegt haben als eine Gruppe unveränderter Seiten. Nach dieser Regel testen wir die SEO-Korrekturen auf unserer Website. Claude Code schreibt das Experimentprotokoll, bevor es eine Seite anfasst, ändert eine zufällig gezogene Testgruppe, lässt eine passende Kontrollgruppe unberührt, und ein Skript vergleicht beide an Tag 15 und Tag 31. ConvOps steuert das Ganze als geplante Tasks mit Workflows, und jede Änderung mergt ein Mensch. Es ist einer der Loops, mit denen wir unser Unternehmen führen.

Ein vorregistriertes SEO-Experiment ist eine Seitenänderung, deren Hypothese, Metrik, Seitengruppen und Falsifikationskriterium committet werden, bevor die Änderung live geht, und danach nie mehr bearbeitet werden. Eine Seitenfamilie ist eine Seite samt ihren Sprachvarianten (en, es, de). Familien sind die Einheit, die der Loop der Test- oder der Kontrollgruppe zuweist.

Alle Ansichten und Zahlen unten verwenden Beispieldaten von Tidewell, einer fiktiven Rechnungs-App unter tidewell.example.com.

So läuft der Loop: Monatliche Recherche und eine von Menschen genehmigte Strategie speisen einen wöchentlichen Planer, der Experiment-Tasks anlegt, ein täglicher Puls weckt die fälligen, alles liest und schreibt ein Ledger-Repo, und ein Mensch mergt jede Änderung, bevor sie live geht.

Vier Zeitpläne treiben ihn an: ein täglicher Puls, ein wöchentlicher Planer sowie monatliche Recherche und Strategie.

Vier Zeitpläne treiben den Loop an: ein täglicher Puls, ein wöchentlicher Planer, monatliche Recherche und monatliche Strategie, jeweils mit ihrer Regel und ihrer Aufgabe.

Warum wir ihn gebaut haben: Eine Seite ist Rauschen, und Agenten erfinden Zahlen

Die meisten SEO-Tests auf kleinen Websites führen Sie in die Irre: Eine Seite schwankt um ein Drittel, ohne dass sich etwas geändert hat. Google-Updates, Saisonalität, Crawl-Zeitpunkte und websiteweite Einbrüche bewegen eine Seite ganz von selbst. Ein Vorher-nachher-Diagramm einer einzelnen Seite kann eine Korrektur nicht von einer ruhigen Woche unterscheiden.

Die Antwort ist eine Kontrollgruppe von derselben Website, zufällig zum selben Zeitpunkt zugewiesen. Beide Gruppen erleben dieselben Bedingungen, also ist der Abstand zwischen ihnen der Effekt. Laut den Testrichtlinien von Google hängt die Dauer, die ein verlässlicher Test braucht, davon ab, wie viel Traffic die Website bekommt (Google Search Central, 2025(wird in einem neuen Tab geöffnet)). Dieser Loop ändert nie eine URL und fügt keine Weiterleitung hinzu, und eine kleine Website bekommt 28 gemessene Tage plus eine Verlängerung.

Eine Seite schwankt von Woche zu Woche um ein Drittel, ohne dass sich etwas geändert hat, während Test- und Kontrollgruppe gemeinsam durch einen websiteweiten Einbruch gehen; gemessen wird der Abstand zwischen ihnen.

Das zweite Problem ist der Agent. Bitten Sie einen Agenten, „die Daten zu prüfen“, und er berechnet Verhältnisse, vergleicht sie mit Vergleichswerten, die er sich ausgedacht hat, und empfiehlt Änderungen. Unserer hat genau das getan. Deshalb berechnet ein Skript jede Metrik und jedes Urteil, und Claude Code führt die Schritte aus und liest die Ergebnisse.

Wenn Sie einen geplanten Loop wie diesen wollen, mit Schritten, Gates und menschlichen Freigaben, sehen Sie sich an, wie ConvOps ihn steuert(wird in einem neuen Tab geöffnet).

So läuft er: vier Zeitpläne, fünf Workflows

Ein Experiment-Loop ist nur so ehrlich wie seine Uhr, deshalb wartet hier nichts darauf, dass sich eine Person daran erinnert.

Der Planer nutzt nur ein Strategie-Memo, dessen Freigabe-Task abgeschlossen ist. Ohne ein solches bleibt er bei seinen Standardwerten. Ein Memo steuert wochenlang Experimente, deshalb unterschreibt es eine Person.

Ein Pool ist die Menge der Familien, in denen eine Metrik messbar ist: Abrufe durch KI-Crawler, Google-Impressionen, Position oder Klickrate. Ein Arm ist ein Korrekturtyp, angewendet auf eine Gruppe von Seitenfamilien. Eine Welle ist die Menge der Arme, die an einem Montag gemeinsam starten und sich eine Kontrollgruppe teilen.

Jeder Arm ist ein eigener Task mit einem Workflow aus 10 Schritten, ein Graph aus Schritten und Gates, die Form, die wir in Was ist Graph Engineering? beschreiben.

Jedes Merge wartet auf eine Person, das menschliche Gate, das wir in KI-Systeme mit Human in the Loop bauen beschreiben.

Der Experiment-Workflow als Graph: Register, Implement und Review, ein Ship-Schritt, der menschliche Freigabe braucht, dann Go live (Tag 0), Interim (Tag 15) und Final (Tag 31), wobei Gate-Ergebnisse zu Rollback oder Act springen, bevor Learn folgt.

Zwischen den Auswertungen ruht der Task bis zu seinem Fälligkeitsdatum, und der tägliche Puls weckt ihn.

Unser Loop für die selbstheilende Website nutzt dasselbe Muster für die Website-QA: Ein wöchentlicher Prüflauf legt Bugs an, und jeder Bug bekommt einen eigenen Reparaturlauf, der erst nach einer erneuten Prüfung schließt.

Ein Lauf Schritt für Schritt (Beispieldaten)

Hier ist ein vollständiger Tidewell-Lauf, vom Montagsplaner bis zum Urteil an Tag 31.

Montag: Der Planer öffnet eine Welle

Der Bericht des wöchentlichen Planers: geeignete Familien und Arm-Kapazität pro Pool, die für jede Welle gezogenen Korrekturtypen, die Zuweisung mit Seed und vier Experiment-Tasks, die der nächste Puls verteilt.

Der Planer zählt geeignete Familien und die Arm-Kapazität pro Pool (Markierung 1). Die Kapazität ist die Zahl der geeigneten Familien geteilt durch 15, abgerundet, minus eins: Tidewells 68 Familien im KI-Pool erlauben 3 Arme. Der Google-Pool ist auf 1 Arm begrenzt, und jeder Pool hat immer nur eine laufende Welle.

Ein Pool bekommt nur dann eine Welle, wenn seine historische A/A-Baseline in Ordnung ist. Diese Baseline spielt vergangene Daten mit Schein-Aufteilungen erneut ab und zählt, wie oft reines Rauschen wie ein Gewinn aussieht (2,1 % im Beispiel). Ein Pool, der das nicht besteht, bekommt keine Welle, weil jedes Urteil dort Rauschen wäre.

Korrekturtypen, die öfter gewonnen haben, werden häufiger gezogen (Markierung 2), wobei etwa 20 % der Arme für Korrekturtypen ohne Urteil reserviert bleiben (Thompson Sampling, Beta(1 + wins, 1 + losses + inconclusives)).

Die Zuweisung nutzt das Datum als Zufalls-Seed, mischt innerhalb jeder Diagnosegruppe und verteilt die Familien reihum, die Kontrollgruppe zuerst (Markierung 3). Jede Gruppe erhält 17 Familien. Der nächste Puls, nicht der Planer, verteilt die vier Tasks.

Register: Das Protokoll kommt zuerst

Das Experimentprotokoll im Status registered (registriert): Frontmatter, eine falsifizierbare Hypothese, die Regel, die sie widerlegt, Familien und Baseline, alles committet, bevor der Agent eine Seite anfasst.

Das Protokoll enthält einen Korrekturtyp (Markierung 1), einen falsifizierbaren Satz (3), die Regel, die ihn widerlegt (4), und eine Baseline über 28 Tage (5). Nach dem Commit ändern sich nur noch der Status und die Datumsangaben. Wir registrieren vorab, weil ein Agent, genau wie ein Mensch, im Nachhinein in jeder Zahl eine Geschichte finden kann; ein committetes Falsifikationskriterium lässt nichts zum Umdeuten übrig.

Implement, Review, Ship, Go live

In Arm A ergänzt Claude Code die 17 Testfamilien mit Rechnungsvorlagen um eine Zusammenfassung in Frageform und einen FAQ-Block. Das ist die eine Variable. Es fasst nie URLs, Slugs, Weiterleitungen, das gemeinsame Layout oder Fakten an, und es aktualisiert das Datum auf jeder geänderten Seite. Das statische Review besteht; ein Mensch mergt. Hier ist Arm B derselben Welle, ruhend nach dem Go-live.

Ein paralleler Experiment-Task nach dem Go-live: die Notiz jedes Schritts am Task, die Live-Prüfung hervorgehoben, Interim (Tag 15) als Nächstes und das Fälligkeitsdatum auf Tag 15 gesetzt, sodass der Task bis dahin ruht.

Go live prüft die Änderung im Produktions-HTML auf allen 17 Seiten (Markierung 1). Laut Google kann das Crawling einige Tage bis einige Wochen dauern (Google Search Central, 2025(wird in einem neuen Tab geöffnet)), deshalb ist Tag 0 der Tag, an dem die Änderung live verifiziert ist, nicht der Tag des Merges. Go live setzt Tag 0 und beide Fälligkeitsdaten und lässt den Task dann bis Tag 15 ruhen (Markierungen 2 und 3).

Tag 15 und Tag 31: Ein Skript entscheidet

Der Schritt Final (Tag 31) trägt die Entscheidungsregeln in seinen Anweisungen: das Urteilsskript ausführen, dann Gewinn, Verlust oder nicht eindeutig mit einer Verlängerung bis Tag 59.

Die Entscheidungsregeln stehen in den Anweisungen des Schritts (Markierung 2), sodass der Agent nicht mit ihnen diskutieren kann. Er führt das Urteilsskript aus und folgt dem passenden Zweig.

Die Entscheidungsnotiz am selben Task hält jede Auswertung als Zeile fest; hier ist die finale Auswertung nicht eindeutig, also wird der Task einmal bis Tag 59 verlängert.

An Tag 15 liest das Skript Ratio 1,08, p 0,31: kein Schaden, kein vorzeitiger Gewinn, weiter. An Tag 31 liest es Ratio 1,11, p 0,19 (Markierung 1): nicht eindeutig, also wird der Task einmal bis Tag 59 verlängert und ruht erneut.

So sieht das Ergebnis aus: das Ledger

Das Ergebnis dieses Loops ist das Ledger, nicht ein Traffic-Diagramm.

Das Ledger führt eine Zeile pro Experiment mit den echten Spaltennamen, und die Statusspalte zeigt, wo jedes Experiment in seinem Lauf steht.

Ein Experiment durchläuft die Status registered (registriert), awaiting-merge (wartet auf Merge), live, interim-done (Zwischenauswertung erledigt) und final und kann als extended (verlängert), rolled-back (zurückgenommen) oder void (ungültig) enden. Jeder Arm ist ein eigener Task mit eigenem Urteil.

Das Urteilsskript führt eine Differenz-von-Differenzen-Analyse (Diff-in-Diff) mit Permutationstest auf Familienebene über 10.000 Durchmischungen aus. Die Ratio ist die Veränderung der Testgruppe geteilt durch die Veränderung der Kontrollgruppe im selben Zeitraum; 1,5 bedeutet also, dass sich die Testgruppe um 50 % stärker bewegt hat als die Kontrollgruppe. Bei KI-Abrufen (jede Metrik hat eigene Schwellen) braucht ein Gewinn an Tag 31 p ≤ 0,0477, eine Ratio von 1,5 oder mehr und mindestens 60 % der Testfamilien über dem Median der Kontrollgruppe. Ein KI-Abruf-Ergebnis an Tag 15 mit p ≤ 0,0074, das auch die Ratio- und Anteilsregeln erfüllt, beendet den Arm vorzeitig: Es ist final und geht direkt zu Act. Ein Verlust ist das Spiegelbild (Ratio 0,67 oder weniger, 60 % unter dem Median), und es folgt ein Rollback. Alles andere, oder weniger als 15 Familien pro Arm, ist nicht eindeutig.

Die beiden p-Schwellen teilen ein Budget von 5 % für falsche Gewinne auf die zwei Auswertungen auf, sodass ein vorzeitiger Stopp an Tag 15 keine zusätzlichen falschen Gewinne kostet. Die Ratio und der Anteil von 60 % stoppen ein Ergebnis, das statistisch echt, aber winzig ist oder von einer einzigen großen Seite getragen wird.

Wie aus einer Auswertung eine Entscheidung wird: Bei der Zwischenauswertung an Tag 15 ist ein KI-Abruf-Ergebnis mit p ≤ 0,0074 und Ratio ≥ 1,5 ein vorzeitiger Gewinn, der den Arm stoppt und zu Act geht, Schaden führt zum Rollback, ein Google-Update macht die Auswertung ungültig, alles andere läuft weiter; die finale Auswertung an Tag 31 liefert Gewinn, Verlust oder nicht eindeutig (Schwellen aus verdict.py) mit einer Verlängerung bis Tag 59; ein Gewinn legt nur eine Replikationsidee an.

Nicht eindeutig ist kein Verlust. Es bedeutet, dass der Effekt, falls es einen gibt, kleiner ist, als diese Website erkennen kann. Der Task wird einmal bis Tag 59 verlängert und dann geschlossen, denn ein Test, der so lange läuft, bis er gewinnt, gewinnt irgendwann durch Rauschen. Auch ein Gewinn erzeugt keine weiteren Experimente. Er legt eine Replikationsidee für einen Menschen an, denn ein Budget von 5 % für falsche Gewinne bedeutet, dass manche Gewinne Rauschen sind, und nur ein zweiter Lauf mit frischen Familien trennt sie voneinander.

Was schiefgeht: der Agent, der eine Krise erfand

Unser schlimmster Morgen kam von einem Agenten, der hilfreich sein wollte. Unsere tägliche Prüfung übersprang ihre Prüfliste und schrieb einen eigenen Bericht. Sie berechnete eine Klickrate, verglich sie mit einem „Branchenstandard“, den ihr niemand gegeben hatte, stufte sie als CRITICAL ein, empfahl Änderungen und zitierte Tracking-Bugs, die nie angelegt worden waren. Jede Zahl wirkte plausibel. Keine stammte aus einer definierten Prüfung. Wir archivierten den Bericht und schrieben den Schritt noch am selben Tag neu. Hier ist der Fall, nacherzählt auf Tidewell-Daten.

Vorher: Der Agent bewertete die CTR anhand eines erfundenen Vergleichswerts und empfahl Änderungen; nachher: Ein Skript erstellt den Snapshot, und nur vier feste Prüfungen entscheiden, die eine echte Anomalie finden, eine Sitemap, die 500 zurückgibt.

Die Regel, die daraus entstand, hat zwei Teile. Erstens erstellt ein Skript den Snapshot, und der Agent berechnet nie eine Snapshot-Zahl und schreibt die Datei nie von Hand. Zweitens gelten nur vier feste Prüfungen als Anomalien:

1. Die Impressionen fallen unter die Hälfte ihres 7-Tage-Mittelwerts.
2. Die Abrufe durch KI-Crawler fallen unter 50 % oder steigen über 300 % ihres 7-Tage-Mittelwerts.
3. Eine Familie in einer laufenden Welle fehlt 7 Tage lang in den Daten.
4. Die Startseite oder die Sitemap liefert einem KI-Crawler nicht HTTP 200.

Keine Urteile über die CTR, keine Rankings, keine Vergleichswerte, keine Empfehlungen. Ein Bug wird nur mit der ID zitiert, die der Tracker zurückgegeben hat.

Der zweite Fehler war leiser und schlimmer. Ein Paket-Release für eine unserer Websites enthielt eine noch nicht veröffentlichte Produktänderung, und die schrieb vor Tag 0 Texte auf einer unserer Kontrollseiten um. Eine Kontrolle, die sich ändert, ist keine Kontrolle mehr: Jeder Abstand, den sie zeigt, ist unsere eigene Änderung, nicht die Korrektur. Wir haben es vor dem Go-live bemerkt. Die Regel: Eine Familie, die nach der Zuweisung angefasst wird, wandert nach „Excluded after assignment“ (nach der Zuweisung ausgeschlossen) und fällt aus dem Vergleich.

Bauen Sie Ihren eigenen: die Minimalversion

Für den Anfang brauchen Sie keine fünf Workflows. Sie brauchen ein Repo, zwei Skripte, eine Protokollvorlage und einen täglichen Scheduler.

Die Minimalversion zum Nachbauen: Ein täglicher Scheduler führt ein Snapshot-Skript aus, das in ein Ledger-Repo schreibt, Protokolle entstehen aus einer Vorlage, und ein Urteilsskript liefert an den Fälligkeitsdaten behalten, verlängern oder zurücknehmen.

Die Protokollvorlage, eine Datei pro Experiment:

---
experiment: exp-0001
site: example
wave: example-2026-01-05
arm: A
fix_type: internal-links
primary_metric: impressions
status: registered
branch: exp/exp-0001
day0: null
interim_due: null
final_due: null
---
Hypothesis:
One falsifiable sentence: what changes, on which treated families, against which control, by day 31.

Falsified if:
The day 31 verdict is not a win under the thresholds fixed in the verdict script.

Families:
treated (15+): ...
control (15+): ...

Baseline (28 days):
treated ... | control ...

Verdicts:
| Look | Date | n treated / control | Ratio | p | Verdict |
|---|---|---|---|---|---|

Lesson:

Kopieren Sie die Protokollvorlage und planen Sie dann den täglichen Puls in ConvOps(wird in einem neuen Tab geöffnet), damit jedes Experiment an seinem Fälligkeitsdatum geweckt wird.