Query Fan-Outs, Mistral, Regenwasser-Projekt, Vercel Services

Begrüßung

Folge 9 — und damit ist die zehnte in Sichtweite. Für die gibt es Überlegungen: vielleicht ein Gast, auf jeden Fall etwas Besonderes. Seit dem Start kommt jeden zweiten Mittwoch um 12 Uhr eine Folge, pünktlich, und darauf sind beide ein bisschen stolz. Wo es noch hakt, ist Social Media: Reels sind vorbereitet, aber das Veröffentlichen bleibt trotzdem liegen. Man stellt sich das eben doch leichter vor, wenn man selbst nur einmal im Quartal etwas postet.

Query Fan-Outs: was ChatGPT im Hintergrund wirklich sucht

Wenn ein Prompt bei ChatGPT eine Websuche auslöst, wird die Anfrage im Hintergrund in mehrere Search Queries aufgefächert — der Query Fan-Out. Aus den Ergebnissen dieser Queries entsteht dann die Antwort; das ist der Grounding-Teil des Prozesses. Christophs konstruiertes Beispiel: Aus „welches CRM für ein kleines Team" werden Queries wie „CRM für kleine Unternehmen Vergleich 2026", „HubSpot vs. Pipedrive Preise", „CRM Software Testbericht DACH", „CRM kostenlose Version Einschränkungen" und „CRM DSGVO Hosting EU". Die Treffer werden danach in weiteren Schritten gefiltert und bewertet.

Der manuelle Weg an diese Daten geht über die DevTools. Chat-ID aus der URL kopieren (chatgpt.com/c/<ID>), DevTools öffnen, Network-Tab, Filter auf Fetch/XHR, die ID ins Filterfeld — dann tauchen zwei Einträge auf, und der mit genau diesem Namen liefert unter „Response" den kompletten JSON-Baum des Chats. Christoph hat den in einen JSON-Online-Editor geworfen: rund 3.600 Zeilen, darin Erstellungsdatum, Titel, die Save-URLs und vor allem der Key „mapping" mit den einzelnen Turns. Geht man die durch, steckt in einem der Einträge im Textfeld wieder ein JSON-String — und darin stehen die Queries. Wichtig: Dieser Key ändert sich regelmäßig, OpenAI ist kein großer Fan davon, dass man da rankommt.

Sein echtes Beispiel kam frisch aus dem Urlaub auf Bornholm: „Ich suche auf der Insel Bornholm ein hochwertiges, nachhaltiges Hotel" (Spoiler: Es war dann doch der Campingplatz). Heraus kamen Queries wie „Bornholm sustainable hotel", „luxury eco hotel Bornholm", „Bornholm Green Key" und „Bornholm boutique hotel". Damit man das nicht jedes Mal von Hand macht, gibt es GPT-Spy von Alin Radulescu — ein Bookmarklet, das den JSON-String automatisch auswertet und Search Queries, Search Results, Citations und Save-URLs auflistet. Jens' Anmerkung dazu: Das Snippet lässt sich genauso gut direkt in die Browser-Konsole einfügen, das Bookmark macht nichts anderes.

Interessant sind die Beobachtungen daran. Erstens: „Bornholm Green Key" liest sich wie eine Brand. Christophs These ist deshalb, dass die Queries aus dem Trainingswissen des Modells generiert werden und nicht über einen separaten Recherche-Turn davor — jedenfalls bei einfachen Anfragen. Wer im Knowledge nicht vorkommt, tut sich entsprechend schwer, sich dort zu platzieren. Zweitens: Die Queries sind extrem lang und detailliert („Bornholm hotel sustainability local organic food design") — Formulierungen, die kein Mensch so eingeben würde. Genau das ist eine Chance: Wenn man weiß, dass so etwas abgefragt wird, kann man eine Landing Page exakt darauf bauen.

Drittens Title und Meta Description. Bei 20 Search Results kann niemand ernsthaft behaupten, dass ChatGPT alle 20 Seiten scrapt und auswertet — das wäre viel zu teuer. Also muss die Vorfilterung über Title und Description laufen. Jens' Anschlussfrage: Welcher Suchindex steckt eigentlich dahinter, und was steht dort über eine Seite drin — nur die klassischen Meta-Tags oder eine eigene generierte Zusammenfassung? Sicher ist das niemand; Christoph verweist aber darauf, dass OpenAI mit einem eigenen Search-Bot ordentlich crawlt, also sehr wahrscheinlich auch einen eigenen Index hat. Letzter Punkt aus seinen Tests: Free-Account gegen Paid-Account macht einen krassen Unterschied — mit dem kostenlosen Konto hat er deutlich weniger Queries gesehen.

Mistral: was aus Europa geht

Der Anlass war eine Open-Source-Contribution. In Jens' Payload-Plugin, das per KI Alt-Texte für Bilder generiert, kam ein Pull Request an, der einen zweiten Resolver ergänzt: neben OpenAI jetzt auch Mistral. Das Plugin ist bewusst so gebaut, dass der Provider austauschbar ist. Kurzer Exkurs an der Stelle, weil es immer noch sehr häufig falsch gemacht wird: Alt-Texte wie „Bild von Jens Becker" bringen weder Mensch noch Maschine etwas. Mit einem fertigen CMS-Plugin und einem guten Prompt — oder einem passenden Skill, wenn die Seite aus einer Codebase kommt — ist das heute wirklich kein Aufwand mehr.

Der PR hat dann neugierig gemacht. Im Mistral Studio hat sich Jens vor allem die Konnektoren angeschaut — technisch nichts anderes als MCP-Server. Angebunden hat er den MCP-Server des zwischen-zwei-stacks-CMS, und das ist ihm gut gelöst vorgekommen, ehrlich gesagt besser als bei Claude und deutlich besser als bei ChatGPT. Es gibt einen Connector Debugger, in dem man die URL einträgt und dann jeden einzelnen Step durchgehen kann, inklusive der Tools, Prompts und Resources des Servers. Bei ChatGPT sieht man bei einem Custom Connector gar nicht, was hin- und hergeschickt wurde — als Entwickler ist das schlicht schlecht. Im Test („Wann wurde die letzte Folge veröffentlicht, worum ging es?") war der Tool-Call auf das find-Tool samt Argumenten und JSON-Antwort komplett sichtbar.

Ansonsten nimmt sich das alles wenig: Chats, ein Work-Modus, Mistral Code, dazu die erwartbaren Kleinigkeiten wie Vorlesen oder das nachträgliche Bearbeiten eines Prompts. Beim Thema Agentic Coding testet Jens gerade OpenCode als Harness, das im Gegensatz zu Claude Code oder Codex beliebige Modelle und Provider zulässt, also auch Mistral. Nüchtern muss man sagen: Die Mistral-Modelle sind beim Agentic Coding nicht auf dem Niveau der Top-Modelle von Claude. Für Aufgaben wie die Alt-Text-Generierung reichen sie aber allemal. Und fast brandaktuell: In einem Blogpost vom 11. August kündigt Mistral an, zusätzlich zu den eigenen Modellen weitere fremde Open-Weight-Modelle auf die Plattform zu holen — was vermuten lässt, dass rein eigene Modelle gegen die US-Konkurrenz schwerer sind als gedacht, aber als Weg zur Plattform durchaus spannend ist.

Dazwischen eine Info von Christoph: OpenRouter, so etwas wie eine Börse für Modelle und Tokens, bei der man sich nicht überall einzeln anmelden muss, wird gerade von Stripe übernommen. Auf den ersten Blick seltsam — die Vermutung dahinter ist aber, dass AI-Agents bald selbst Geld ausgeben und dafür Zahlungsmethoden brauchen. Jens ergänzt den HTTP-Statuscode 402 Payment Required, der jahrzehntelang praktisch ungenutzt war und jetzt wieder spannend wird, Stichwort x402-Protokoll.

Einig sind sich beide bei der Abhängigkeit von US-Anbietern — die Fable-5-Episode, in der plötzlich über Zugang nach Staatsbürgerschaft geredet wurde, ist noch frisch. Christoph will einen Wochen-Langzeittest mit Mistral machen, Jens beschreibt sich selbst als „stuck in Claude Code". Beides läuft auf dasselbe hinaus: sich ab und zu bewusst Zeit nehmen, das eigene KI-Setup zu hinterfragen und Alternativen anzuschauen.

Regenwasser-Projekt: von der Testseite zur Partnersuche

Christoph hat ein paar Testseiten für SEO- und GEO-Experimente, und die größte davon ist regenwasser-haushalt.de — ein Ratgeber für Hausbesitzer, die Regenwasser sammeln und nutzen wollen, für den Garten oder die Toilettenspülung. Gestartet im November letzten Jahres, also gut neun Monate, mit einer Optimierungsschleife alle zwei bis drei Wochen: Search-Console-Daten anschauen, Kannibalisierung suchen, Keywords auf Seite 2 nach vorne schieben. In SEO Gets sieht man die Kurve: Am Anfang passiert lange wenig, dann steigt die Average Position Stück für Stück, alle Google-Updates ohne Einbruch überstanden, und zuletzt sind auffällig viele Keywords in die Top 3 und Top 10 gerutscht. Ein Tag lag schon bei 200 Unique Visitors.

In Plausible kommen rund 62 Prozent des Traffics von Google, ChatGPT liegt bei 4,2 Prozent. Das täuscht aber: Im Bot-Traffic ist enorm viel los, weil die Seite Info-Charakter hat und ihre Inhalte von Agents konsumiert werden, ohne dass jemand klickt. Noch deutlicher wird es im neuen Generative-AI-Tab der Google Search Console, den Christoph für die Seite schon hat: rund 45.000 bis 46.000 Impressionen in AI Overviews in drei Monaten — bei fast keinen Klicks. Rechnet man den Bot-Traffic dazu, landet man bei einer Reichweite von vielleicht 100.000 in drei Monaten, die praktisch komplett bei AI-Agents stattfindet. Zero-Click-Marketing ist damit kein Zukunftsthema mehr, sondern die Arbeitsgrundlage: Es geht darum, die Marke zu platzieren, nicht mehr nur Besucher zu zählen. Jens' Reminder dazu aus Folge 5: Wer wirklich wissen will, wie viel AI-Bot-Traffic anfällt, muss in die Server-Logs schauen, Plausible ist da naturgemäß limitiert.

Was die Seite von einer reinen Ratgeberseite unterscheidet, sind zwei Dinge. Erstens die Survey, die seit Monaten läuft und fragt, wo der Besucher gerade steht: nur informieren, konkret planen oder schon in der Umsetzung. Über das ganze Jahr gerechnet liegt die Antwortrate bei 7,2 Prozent, real eher bei 20 Prozent — damit weiß Christoph, in welchem Kaufstadium seine Leute sind. Zweitens die Produktseiten für Pumpen, Zisternen und Regentonnen, die nicht von Anfang an drin waren. Die Vergleichsmethodik ist transparent aufklappbar dokumentiert, gefiltert werden kann auch, und der Anspruch ist schlicht, das besser zu machen als Amazon — was für eine Nische wie Regenwasserpumpen machbar ist. Getrackt wird, welches Produkt wie oft geklickt wird und zu welchem Merchant es geht.

Und daraus wird jetzt Partnersuche. Christoph hat sich dafür ein kleines HTML-Dashboard fürs Telefonieren gebaut — inspiriert von Jens' kleinen HTML-Seiten aus der letzten Folge und von seinem Coach Simon: Wunschpartner mit recherchiertem Hintergrund, Telefonnummer, Argumente für genau diesen Kunden, ein Feld für das Ergebnis des Gesprächs, oben die KPIs (8,2 Prozent Produktklickrate, rund 60 Prozent Wachstum Monat für Monat) und je ein Tab für Einwandbehandlung und Deal-Anker. Das gibt am Telefon spürbar Sicherheit. Das wertvollste Gespräch war ausgerechnet das unangenehmste — sinngemäß „wollen Sie sich hier eine goldene Nase verdienen?". Statt beleidigt zu sein, hat Christoph zugehört, und der Anbieter hat sein eigentliches Problem erzählt: Er plant die Anlagen, und gekauft wird dann woanders. Damit war klar, dass qualifizierte Leads mit Dachgrundfläche, Dachtyp und geplanter Nutzung um ein Vielfaches mehr wert sind als reiner Traffic.

Die Konsequenz war schnell gebaut: ein Zisternenrechner, der über eine kleine JSON-Datei den Niederschlag pro Postleitzahl kennt, nach Nutzung (Garten, Haus) und Haushaltsgröße die passende Zisternengröße ausrechnet und am Ende fragt, ob man ein Angebot von einem Fachbetrieb möchte. Wer nicht will, bekommt eine Planungsgrundlage als PDF und kann damit selbst zum Anbieter gehen. Parallel läuft ein Mitmachbereich: Wer schon eine Anlage hat, kann Formular und Fotos schicken und bekommt einen 100-Euro-Gutschein — die Zielgruppe dafür ist über die Survey ohnehin schon bekannt und bekommt direkt das passende Pop-up. Aus Theoriewissen sollen so echte Anlagen und echte Erfahrungsberichte werden.

Vercel Services: ein Deployment statt zwei

Jens' Standard-Setup für Websites ist Payload als Headless CMS und Astro als Frontend, dazu ein Open-Source-Template. Alle Seiten werden statisch generiert und beim Aufruf nur noch über das CDN ausgeliefert. Der Preis dafür: zwei Vercel-Projekte, die in der richtigen Reihenfolge deployen müssen — erst das CMS, dann das Frontend. Bisher löst er das entweder mit einer GitHub Action, die die Deployments nacheinander anstößt, oder mit Disziplin bei den Pull Requests: Wenn eine CMS-Erweiterung die Website betrifft, geht erst der CMS-PR live, dann der Web-PR.

Vercel Services, aktuell in der Beta und langsam im Rollout, räumt das auf. Damit lassen sich mehrere Apps in einem Vercel-Projekt deployen: die Payload-App und die Astro-App in einem Projekt, ein Deployment, beides nacheinander gebaut. Das Reihenfolgeproblem verschwindet damit komplett. Der zweite Vorteil ist Latenz: Die HTTP-Calls zwischen CMS und Website laufen dann intern und verlassen die Vercel-Infrastruktur nicht mehr, gehen also nicht über das öffentliche Internet.

Ein Haken bleibt, und er hängt genau am statischen Ansatz: Wenn beide Deployments zusammengefasst sind, wird bei jeder noch so kleinen CMS-Änderung die komplette Website neu gebaut — je nach Größe und Content 30 Sekunden bis ein, zwei Minuten. Deshalb experimentiert Jens gerade mit Incremental Static Regeneration. Die Idee: Seiten serverseitig beim ersten Aufruf rendern und cachen, alle weiteren Aufrufe kommen aus dem Cache, und bei einer Änderung im CMS wird der Cache revalidiert. Christophs Rückfrage — der erste User nach einer Änderung bekommt also die serverseitig gerenderte Version, alle danach wieder die gecachte — trifft es genau. Damit auch dieser erste Besucher nicht warten muss, lässt sich der Cache nach dem Invalidieren direkt wieder aufwärmen.

Umgesetzt wird das in seinem Payload-Plugin, das Pfad- und URL-Generierung, Breadcrumbs und Alternativpfade übernimmt: ein, zwei Beta-Versionen mit experimentellen Features, die serverseitiges Rendern und Caching unterstützen. Für das Template ist ein eigener Branch für das Services-Setup geplant — bewusst als Ergänzung, denn das Template soll nicht Vercel-only werden, sondern weiter auch auf Cloudflare oder Netlify laufen. Nebenbei erwähnt und einen Glückwunsch wert: Jens Payload Plugins Repository hat vor ein paar Wochen die 100 GitHub-Stars geknackt.