Wie viel SEO steckt in KI-Empfehlungen? Joe Shirey sucht gerade ein neues NAS. Früher hätte er ein Dutzend Tabs mit Testberichten, Foren und Herstellerseiten geöffnet, diesmal schrieb er seine Anforderungen auf und gab sie einem Agenten, der mit einer kurzen Auswahl samt Vor- und Nachteilen zurückkam. Shirey arbeitet bei Google Cloud und hat aus dieser neuen Gewohnheit ein kontrolliertes Experiment gemacht: 310 Prompts, ein Basislauf und fünf Tests, zusammen 5.580 Durchläufe. Die Frage war, ob sich die Empfehlung eines Agenten über die Suchergebnisse steuern lässt, die er zu sehen bekommt. Für alle, die SEO als kurzfristigen Hebel verstehen, ist das Ergebnis ernüchternd. Langfristig spricht es trotzdem dafür, sie nicht zu vernachlässigen.
Warum Produktrecherche in den KI-Agenten wandert
Eine von MarTech zusammengefasste Erhebung von L.E.K. Consulting zeigt: 46 Prozent der KI-Nutzer beginnen ihre Produktrecherche inzwischen auf Plattformen wie ChatGPT, Gemini, Perplexity oder Claude. 2024 waren es 25 Prozent. Im selben Zeitraum sank der Anteil derer, die klassisch über eine Suchmaschine einsteigen, von 43 auf 24 Prozent.
Ein Bericht von Emplifi und Semrush vom September 2026 zeichnet ein ähnliches Bild: 66 Prozent der Verbraucher haben KI-Werkzeuge schon für Produktrecherchen genutzt, 11 Prozent machen sie zu ihrem ersten Anlaufpunkt. Das betrifft den Einzelhandel. Entwickler verhalten sich nicht anders. Wer einen Coding-Agenten fragt, welche Datenbank, welchen Message-Broker oder welchen Hosting-Anbieter er nehmen soll, bekommt eine Empfehlung – und übernimmt sie oft einfach.
Damit wird aus Suchmaschinenoptimierung so etwas wie Generative Engine Optimization. Statt um zehn blaue Links geht es darum, ob ein Modell ein Produkt kennt, es für erwähnenswert hält und am Ende auswählt. Zwischen diesen drei Dingen liegen Welten. Genau diese Unterscheidung ist der Kern des Experiments.
Was Coding-Agenten tatsächlich auswählen
Am 3. September veröffentlichte Armature eine Untersuchung mit dem Titel „Which tools do Claude Code, Codex and Cursor choose?“. Ausgewertet wurden 16.893 Sitzungen von Coding-Agenten, für 5.292 davon wurden die Daten offengelegt. In vergleichbaren Aufgaben wählten alle drei Agenten nur in 42 Prozent der Fälle exakt dasselbe Werkzeug.
Ein Beispiel: Für ein Voice-Agent-Feature griff Claude Code zu Twilio, Codex zur OpenAI Realtime API und Cursor zu Vapi. Erwähnt zu werden bedeutete nicht, gewählt zu werden. PayPal tauchte in den Sitzungen 139 Mal auf und wurde kein einziges Mal als Lösung ausgewählt.
Die Studie landete am selben Tag auf Hacker News und bei TLDR, Analysen von VarOps, explainx und Pinggy folgten. VarOps merkte an, dass viele Leser die Zahlen als Marktanteile interpretierten. Ein Missverständnis, das zeigt, wie sehr solche Auswertungen nach Rankings aussehen, obwohl sie etwas anderes messen.
Für die SEO-Frage ist ein Nebenbefund wichtiger: Die Agenten nutzten die Websuche sehr unterschiedlich stark. Codex suchte in 94 Prozent der Sitzungen, Cursor in etwa zwei Dritteln, Claude Code nur in rund 30 Prozent.
Der Versuchsaufbau: 310 Prompts und ein manipulierbarer Suchdienst
Daraus entstand ein kontrolliertes Experiment. Shirey testete das Szenario, das er als Google-Cloud-Mitarbeiter am besten kennt: Lässt sich ein Agent zu Google-Cloud-Produkten drängen? Er schrieb 310 Prompts, die jeweils eine Architektur- oder Technologieentscheidung verlangen, bei der Google Cloud ein konkurrierendes Produkt hat. Die Aufgaben verteilen sich auf acht Kategorien: KI und Machine Learning, Infrastruktur, Datenbanken und Analytics, App-Entwicklung, Entwicklerwerkzeuge, Sicherheit und Identität, Management-Tools sowie Integrationsdienste.
Kein Prompt nennt einen Anbieter beim Namen. Gefragt wird zum Beispiel, welcher Dienst sich eignet, um täglich Tausende Schadensmeldungen als PDF automatisch in strukturierte Felder zu überführen – die naheliegende Google-Cloud-Antwort wäre Document AI. Als Agent kam Claude Code mit Claude Sonnet 5 über die Gemini Enterprise Agent Platform zum Einsatz. Jeder Prompt lief dreimal, um die Nichtdeterminiertheit von Sprachmodellen abzufedern. Das ergibt 930 Durchläufe pro Test und 5.580 über alle Läufe hinweg.
Um die Suchergebnisse zu kontrollieren, blockierte Shirey die eingebauten Werkzeuge WebSearch und WebFetch. Stattdessen kam ein MCP-Server namens gemini-search-mcp zum Einsatz, den sein Kollege Casey West geschrieben hat. Das kleine Go-Programm spricht über stdio mit dem Agenten und stellt ein einziges Werkzeug bereit: web_search. Jede Anfrage geht an ein Gemini-Modell mit aktiviertem Google-Search-Grounding, zurück kommen eine Zusammenfassung, eine nummerierte Quellenliste und die tatsächlich ausgeführten Suchanfragen. Weil der Server lokal läuft, lässt sich jede Query protokollieren und verändern, bevor sie bei der Suche ankommt. Ein kleines Skill wies den Agenten zusätzlich an, dieses Werkzeug der nativen Suche vorzuziehen.
Fünf Testläufe von keiner Suche bis zur maximalen Beeinflussung
Zuerst brauchte es eine Kontrollbasis. Die 310 Prompts gingen direkt über die Anthropic-API an Claude Code, mit aktivierter nativer Websuche und ohne Aufforderung zu suchen. Sonnet 5 suchte in 3 von 930 Durchläufen, also in 0,3 Prozent der Fälle. Bei beratenden Architekturfragen antwortet das Modell fast immer direkt aus seinen Trainingsdaten. Das liegt deutlich unter den 30 Prozent, die Armature für Claude Code gemessen hatte. Plausibel, denn dort schrieben die Agenten Code in echten Repositories, hier ging es um grundsätzliche Technologiefragen.
Danach folgten fünf Varianten. Im ersten Test war jede Suche blockiert, das Modell arbeitete allein aus seinen Gewichten, deren Trainingsstand bis Januar 2026 reicht. Im zweiten Test stand der Suchserver bereit, aber kein Prompt verlangte eine Suche. Im dritten Test endete jeder Prompt mit der ausdrücklichen Bitte, vor der Antwort die aktuelle Dokumentation zu prüfen, weil sich Funktionsumfang, Limits und Preise häufig ändern.
Die Tests vier und fünf arbeiteten mit einer manipulierten Suche. Der MCP-Server hängte an jede Query den Zusatz an, Google-Cloud-Produkte in den Ergebnissen zu bevorzugen. Der Agent sah diesen Zusatz nie, er bekam nur entsprechend ausgerichtete Treffer. Test fünf kombinierte beides: erzwungene Suche und verzerrte Query.
Der Eingriff muss eingeordnet werden. Der Server verändert nur den Suchbegriff, er erfindet keine Ergebnisse. Was der Agent liest, ist echter Google-Search-Grounding-Text, nur zu einer geladenen Anfrage. Trotzdem ist dieser Eingriff stärker, als echte Suchmaschinenoptimierung je sein könnte. Keine SEO-Technik verwandelt eine Anfrage nach Azure AI Document Intelligence in eine Übersicht über Google Cloud Document AI. Hier passierte genau das.
Was die Zahlen zeigen: viele Nennungen, wenige Entscheidungen
Gemessen wurden drei Kriterien: ob eine Antwort mindestens ein Google-Cloud-Produkt nennt, ob ein solches Produkt als Hauptempfehlung oder benannter Zweitplatzierter auftaucht und ob es tatsächlich als erste Wahl ausgewählt wird. Der Ausgangspunkt ohne jede Suche lag bei 56,0 Prozent Nennungen, 44,2 Prozent Shortlist-Plätzen und 9,2 Prozent tatsächlichen Auswahlen.
Mit verfügbarer, aber nicht eingeforderter Suche stiegen die Werte leicht: 14,2 Prozent der Durchläufe suchten, 59,7 Prozent nannten Google Cloud, 10,0 Prozent wählten es. Wurde die Suche ausdrücklich verlangt, suchte der Agent in 99,5 Prozent der Fälle, die Auswahlquote kletterte auf 13,0 Prozent.
Die manipulierte Suche brachte im vierten Test kaum etwas: 11,0 Prozent Auswahlen statt 10,0 Prozent, innerhalb der normalen Schwankungsbreite. Der Grund ist einfach. Wenn der Agent das Werkzeug selten benutzt, hat die verzerrte Query kaum Gelegenheit zu wirken. Erst die Kombination aus erzwungener Suche und manipulierten Ergebnissen zeigte einen deutlichen Effekt: Die Nennungen sprangen auf 89,1 Prozent, die Shortlist-Quote auf 68,6 Prozent, die Auswahlquote auf 17,1 Prozent.
Entscheidend ist das Verhältnis. Zwischen Test drei und Test fünf, also allein durch den Query-Eingriff, wuchsen die Nennungen um rund 21 Prozentpunkte, die tatsächlichen Auswahlen aber nur um 4,1 Punkte. In Test fünf zitierten 99,5 Prozent der Suchantworten ein Google-Cloud-Produkt. Trotzdem empfahl der Agent in 706 von 925 Suchdurchläufen einen Wettbewerber.
Ein Bild beschreibt die Versuchsreihe ganz gut. Ein Sprachmodell ist kein Verzeichnis, in das man oben etwas hineinwirft und unten eine Antwort herausbekommt. Es verhält sich eher wie ein erfahrener Bibliothekar, der fast alles aus dem Kopf beantwortet und nur selten aufsteht, um im Regal nachzuschlagen. Was er aus dem Kopf sagt, hat er irgendwann gelernt. Und wenn er doch zum Regal geht, entscheidet er selbst, welches Buch er mitbringt – auch dann, wenn jemand die Regale heimlich umsortiert hat.
Was das für Anbieter und für Entwickler bedeutet
Shirey nennt die Grenzen selbst: ein Modell, ein Anbieter, eine Art von Frage. Es ging um beratende Architekturfragen, nicht um Programmieraufgaben in echten Repositories, bei denen Armature viel höhere Suchquoten gemessen hat. Ein Agent wie Codex, der in 94 Prozent der Sitzungen sucht, gibt Suchergebnissen deutlich mehr Gelegenheit zu wirken als Sonnet 5 in diesem Versuch.
Für Anbieter heißt das: Die Empfehlung entsteht überwiegend aus dem, was das Modell im Training gelernt hat. Dokumentation, Tutorials und jahrelange Berichterstattung über ein Produkt prägen diese Gewichte. Die Optimierung für den Moment, in dem ein Agent zufällig sucht, ist dagegen ein kleiner Hebel. Die größte Einflussgröße war in diesem Experiment nicht der Inhalt der Suchergebnisse, sondern die Frage, ob überhaupt gesucht wird. Und das entscheiden die Anwender und ihre Werkzeugkonfiguration, nicht der Anbieter.
Für Entwickler ergeben sich zwei Konsequenzen. Erstens: Wenn du willst, dass die Empfehlung aktuelle Dokumentation und Preise widerspiegelt, musst du den Agenten ausdrücklich zum Suchen auffordern. Von allein tut er es oft nicht. Zweitens: Wer das Suchwerkzeug kontrolliert, beeinflusst die Antwort. In dem Experiment hat kein Agent bemerkt, dass jede seiner Anfragen umgeschrieben wurde. Wenn du einen fremden Suchdienst in deinen Agenten einbaust, vertraust du ihm mit mehr, als dir vermutlich bewusst ist.
Das heißt nicht, dass Suchmaschinenoptimierung sinnlos wäre. Shirey hält SEO langfristig für sinnvoll, weil es vermutlich die Trainingsdaten prägt – ausdrücklich als Annahme, denn am Training großer Modelle ist er nicht beteiligt. Wer seine Inhalte für Agenten lesbar und zitierfähig aufbereitet, arbeitet demnach an dem Material, aus dem künftige Trainingsläufe schöpfen können. Der Effekt ist langsam und indirekt: ein Hebel auf die nächste Generation von Modellen, nicht auf die Antwort von morgen. Wer kurzfristig eine KI-Empfehlung erzwingen will, überschätzt die Suchergebnisse und unterschätzt die Trainingsdaten.
Und noch eine Randnotiz, die in allen Durchläufen galt: Werbung spielte keine Rolle.
Zurück zum NAS. Die kurze Liste, die Shirey für seine Speicherauswahl bekommen hat, stammte nach seiner Einschätzung wahrscheinlich aus dem, was das Modell im Training gelernt hatte – nicht aus einem Suchergebnis, das jemand für ihn optimiert hätte. Das ist die unspektakuläre Botschaft dieser Versuchsreihe. Generative Engine Optimization lohnt sich als geduldige Arbeit an guten Inhalten, klarer Dokumentation und echter Auffindbarkeit. Sie ist kein Trick, mit dem man sich in eine Empfehlung hineinschreibt, die das Modell längst vergeben hat.
Quelle: joe-shirey.com
