Wie sieht man OpenAI- und Gemini-Suchanfragen?

Nutze eine dokumentierte API mit Websuche

OpenAI dokumentiert Web-Suchaktionen im Output der Responses API. Je nach Modell und Aktion kann der Response eine Query oder mehrere Queries enthalten.

ai-fanout.com sendet einen begrenzten Server-Request mit aktivierter Websuche und deaktivierter Speicherung. Der API-Key erreicht den Browser nicht.

Gib ein kurzes Thema ein, wähle OpenAI, setze Sprache und Land nur bei Bedarf und starte nach dem CAPTCHA. Das Ergebnis nennt Modell, Locale, Zeitpunkt, Suchaktionen und sichtbare Query-Strings.

Eine URL im Response belegt Sichtbarkeit in diesem Lauf, aber weder Google-Ranking noch Empfehlung oder dauerhafte Zuordnung.

Eine Chat-Oberfläche ist kein verlässlicher Datenvertrag. Interne Requests können sich ändern, fremde Identifikatoren enthalten oder gar keinen nutzbaren Query-String liefern.

Auch wenn Entwicklerwerkzeuge einmal einen Suchbegriff zeigen, folgt daraus kein dauerhafter Zugriff auf ChatGPT-Interna. Ein API-Response ist enger, aber reproduzierbar.

Dann hat die API in diesem Lauf keinen Query-String offengelegt. Vielleicht wurde keine Suche ausgeführt, das Feld fehlte oder der Response endete zu früh.

Ein zweites Modell darf nicht erfinden, was OpenAI vermutlich gesucht hat. Dafür gibt es den getrennten Modus Suchideen.

Belegt ist, dass ein benannter API-Response diese Felder zu diesem Zeitpunkt gezeigt hat. Nicht belegt sind identische Suchen auf chatgpt.com, menschliche Nachfrage oder Wiederholbarkeit.

• Kurze Eingabe
• Modell, Locale und Zeit festhalten
• Null Queries akzeptieren
• Nur sichtbare Felder exportieren

Der Lauf hat vier sichtbare Stationen

Die Anwendung sendet Thema und optionalen Locale-Kontext. OpenAI entscheidet innerhalb des Limits, ob und wie gesucht wird. Der Suchdienst liefert Webkontext; das Modell verarbeitet ihn für die Antwort.

Der Response kann Suchaktionen, Query-Argumente, URL-Anmerkungen und Verbrauchsdaten enthalten. ai-fanout.com extrahiert diese Felder und verwirft die nicht benötigte Antwortprosa.

Ein Provider-Tool-Aufruf kann mehrere Query-Strings bündeln. Eine Suchaktion mit vier Queries ist kein Widerspruch.

Mehrere gemeinsam gelieferte Quellen dürfen nicht erfunden auf einzelne Queries verteilt werden.

Bei Websuche kann der gelieferte Suchkontext zu den Input-Tokens zählen. Ein Keyword mit drei Wörtern kann dadurch tausende Input-Tokens auslösen.

Die Seite nutzt bereits die niedrige Suchkontextstufe und begrenzt den Output. Noch weniger Kontext würde eine andere Architektur oder weniger gelesene Ergebnisse bedeuten.

Suchaktionen, Ausgabe, Laufzeit, tägliche Nutzung und Monatskosten sind begrenzt. Das hält den kostenlosen Dienst kontrollierbar, macht das Ergebnis aber zu einer Stichprobe.

Die Query zeigt, wonach gesucht wurde. Die Quelle zeigt eine sichtbare URL. Verbrauchsdaten zeigen gemeldete Tokens und Aktionen. Die Kostenanzeige ist eine Schätzung; maßgeblich bleibt der Provider.

• Eingabe und Locale
• Web-Suchaktion
• Webkontext und Quellen
• Verbrauchsdaten

Queries und Zitate beantworten verschiedene Fragen

Eine Query zeigt, wonach gesucht wurde. Ein Zitat zeigt eine Seite aus dem gelieferten Belegkontext. Beides im selben Response bedeutet nicht automatisch eine Eins-zu-eins-Zuordnung.

Das Tool verbindet eine Quelle nur dann mit einer einzelnen Query, wenn der Provider beides in derselben Ein-Query-Aktion liefert.

URL, Anbieter, Modell, Locale und Zeitpunkt stützen die enge Aussage, dass diese Seite in diesem Lauf sichtbar war. Auswahlgrund, gelesener Umfang, Richtigkeit und erneute Sichtbarkeit bleiben offen.

Öffne die Quelle und prüfe Aussage, Herausgeber, Datum, Geltungsbereich und wirtschaftliche Interessen. Für Produktverhalten und Richtlinien sind aktuelle Primärquellen der beste Start.

Der API-Response enthält kein klassisches Ranking, Suchvolumen oder Klickpotenzial. Nutze Zitate für Quellenanalyse und Search Console oder Analytics für Nachfrage und Leistung.

Geprüfte OpenAI-Beobachtungen können normalisiert veröffentlicht werden. Google schränkt Grounded Results und Search Suggestions zusätzlich ein; diese Gemini-Daten werden vor lokaler Speicherung entfernt.

• Stützt sie die Aussage?
• Ist sie aktuell?
• Ist sie die nächstmögliche Quelle?
• Was beweist sie nicht?

Gemini nutzt Google Search als Grounding-Tool

Die Gemini API kann Google Search aufrufen. Der Response kann Suchargumente mit Query-Strings sowie Grounding- und Quelleninformationen enthalten. Eine identische Suche auf gemini.google.com wird nicht behauptet.

Angezeigt werden Thema, Modell, Locale, Zeitpunkt, Suchaktionen und offengelegte Query-Strings. Quellen erscheinen nur im gelieferten Umfang. Fehlt eine Query, bleibt das Ergebnis null.

Der Server fordert eine nicht gespeicherte Interaktion an. Google dokumentiert bei Search Grounding dennoch Provider-Aufbewahrung. ai-fanout.com erstellt kein eigenes Rohdatenarchiv; lokale Historie beginnt nur nach Speichern.

Googles Zusatzbedingungen begrenzen Caching, Analyse und Weiterverbreitung. Die Seite entfernt diese Felder vor einem Historieneintrag und baut keinen öffentlichen Gemini-Datensatz.

Halte Thema, Sprache und Land beim Wechsel zu OpenAI konstant. Vergleiche Wörter und Nutzeraufgaben und beschreibe das Ergebnis als datierte API-Beobachtungen, nicht als Modellrangliste.