ChatGPT als Shopping-Kanal: Was wir beim Bau eines OpenAI-Feeds für WooCommerce gelernt haben

Vor ein paar Wochen haben wir uns hingesetzt und einen OpenAI-konformen Produktfeed für einen WooCommerce-Shop gebaut. Eine D2C-Marke im US-Markt, ein paar Dutzend SKUs, sensible Produktkategorie. Das Ergebnis sind drei Wochen Arbeit, sieben Plugin-Iterationen, eine ganze Reihe von Sackgassen und am Ende ein Setup, das so wahrscheinlich noch fast niemand im DACH-Raum live hat.

Dieser Beitrag ist keine theoretische Einführung. Es sind die Dinge, die uns beim Bauen tatsächlich überrascht haben — und die du in keinem der Tutorials findest, die du jetzt schon zu dem Thema googeln kannst.

Warum das Thema gerade wichtig wird

OpenAI baut seit Mitte 2025 einen eigenen Shopping-Index auf. Wenn jemand in ChatGPT fragt „best wireless earbuds under 200 dollars" oder „affordable hiking shoes for wide feet", erscheinen Produktkarten direkt im Chat — mit Preis, Bewertung, Produktbild und Link. Diese Karten kommen nicht aus Google Shopping. Sie kommen aus einem eigenen Feed-System, das OpenAI gerade hochzieht.

Die offizielle Spec dafür liegt unter developers.openai.com/commerce/specs/file-upload/products und beschreibt exakt, welche Felder ein Produkt mitbringen muss, damit ChatGPT es korrekt darstellen kann.

Bisher sind in diesem System hauptsächlich große Player drin: Walmart, Etsy, Target, Sephora. Plus alle Shopify-Merchants, weil Shopify das Onboarding über die eigene Integration anbietet. Wer einen WooCommerce-Shop betreibt, schaut bisher größtenteils zu.

Das ist gerade der spannende Punkt: Es ist noch früh genug, dass man als kleiner oder mittlerer Shop relativ unkompliziert auf der ersten Welle mitschwimmen kann.

Was an dem Thema oft falsch verstanden wird

Bevor wir tiefer einsteigen, drei Dinge gerade rücken, die in fast jedem oberflächlichen Artikel zum Thema falsch dargestellt werden:

OpenAI hat kein Merchant Center. Du kannst dich nicht selbst irgendwo einloggen und deinen Shop registrieren wie bei Google. Der Weg ist Direktkontakt über das Onboarding-Formular unter developers.openai.com/commerce/guides/get-started. OpenAI prüft das manuell.

Ein öffentlich gehosteter JSON-Feed ersetzt das Onboarding nicht. Auch wenn deine Produkte unter domain.com/openai-products.json perfekt strukturiert liegen, indexiert OpenAI sie nicht automatisch. Der offizielle Ingest läuft über SFTP-Push oder die ACP-API nach dem Onboarding-Prozess.

Die Strategie verschiebt sich gerade. OpenAI hat im März 2026 angefangen, weg vom „Instant Checkout direkt in ChatGPT" hin zu dedizierten Retailer-Apps innerhalb von ChatGPT zu pivotieren. Walmart hat den Deal als erstes gemacht. Das heißt: Der Feed bleibt wichtig, aber is_eligible_checkout=true ist gerade weniger der heilige Gral als noch vor sechs Monaten.

Trotzdem lohnt sich das Bauen — aus Gründen, auf die wir gleich kommen.

Der Unterschied zwischen Shopify und WooCommerce

Wenn du Shopify-Merchant bist, ist die Arbeit bereits erledigt. Shopify hat die OpenAI-Integration direkt im Admin-Bereich verfügbar, ein paar Klicks, fertig. Das ist der Grund, warum bei „Wer ist denn schon im ChatGPT-Index?" überproportional viele Shopify-Stores auftauchen.

Bei WooCommerce gibt es nichts Vergleichbares. Es gibt keinen offiziellen Connector, keine OpenAI-WooCommerce-Brücke, keinen Plugin-Marktplatz-Standard. Wer mitmachen will, muss selbst bauen.

Das ist auf den ersten Blick ein Nachteil. In der Praxis hat es aber zwei Vorteile, die wir beim Bauen schätzen gelernt haben:

Du hast volle Kontrolle darüber, was wirklich im Feed landet. Wir haben in unserem Setup zum Beispiel UTM-Parameter aus den Produkt-URLs gestrippt, weil die Quell-Daten aus dem bestehenden Google-Shopping-Feed kamen und sonst Conversions aus ChatGPT als „Google Shopping" in der Analytics auftauchen würden. Bei Shopify hast du diese Kontrolle nicht so feingranular.

Und du baust dir parallel ein Verständnis dafür auf, wie Agentic Commerce wirklich funktioniert. Das wird in den nächsten zwei Jahren ein eigenes Spezialthema werden, vergleichbar mit dem, was Google Shopping um 2014 herum war: ein Kanal, den nur wenige technisch verstehen.

Die Spec: Was OpenAI wirklich will

Die offizielle Product Feed Spec listet rund 60 Felder auf. Die meisten Tutorials zählen die einfach runter. Wir gehen den anderen Weg und sortieren nach Wichtigkeit aus der Praxis.

Was wirklich Pflicht ist

• is_eligible_search (boolean)
• is_eligible_checkout (boolean — bei dir vermutlich auf false bis Onboarding durch ist)
• item_id (stabile SKU)
• title (max 150 Zeichen, kein All-Caps)
• description (max 5000 Zeichen, Plaintext)
• url (muss HTTP 200 zurückgeben)
• brand
• image_url
• price (mit Currency, z.B. 54.90 USD)
• availability (in_stock, out_of_stock, pre_order, backorder, unknown)
• seller_name, seller_url, return_policy
• target_countries, store_country

Was die meisten vergessen, was aber Sichtbarkeit massiv erhöht

• gtin (EAN/UPC) — ohne das gleicht ChatGPT eure Produkte nicht mit anderen Datenquellen ab
• product_category als lesbarer Pfad mit >-Separator — Achtung: Wenn ihr aus einem Google-Shopping-Feed kommt, habt ihr da numerische IDs. Die muss man mappen, sonst ist das Feld nutzlos
• review_count und star_rating — stärkster Ranking-Boost in ChatGPT-Antworten
• warning — bei sensiblen Kategorien (Supplements, Lebensmittel, Alkohol, Kosmetik) sogar Compliance-relevant
• age_group für Produkte mit Altersbezug

Felder, die mit jeder Spec-Iteration relevanter werden

• unit_pricing_measure + base_measure — für Vergleichsfragen wie „cheapest per ounce / per liter"
• material für strukturierte Filter
• accepts_returns, return_deadline_in_days, accepts_exchanges — Vertrauenssignale
• q_and_a und reviews als ausführliche Listen

Code: Ein minimal funktionierender Endpoint

Wer das in WordPress baut, hängt sich am cleansten in den template_redirect-Hook. Hier der gekürzte Kern dessen, was unser Endpoint macht:

add_action('template_redirect', 'render_openai_feed', 0);

function render_openai_feed() {
    $path = parse_url($_SERVER['REQUEST_URI'] ?? '', PHP_URL_PATH);
    if ($path !== '/openai-products.json') return;

    // Cache prüfen
    $cached = get_transient('openai_feed_cache');
    if (is_array($cached)) {
        send_feed($cached);
    }

    // Aus Quelle bauen, z.B. WooCommerce oder existierender XML-Feed
    $items = build_items_from_source();
    set_transient('openai_feed_cache', $items, HOUR_IN_SECONDS);
    send_feed($items);
}

function send_feed($items) {
    status_header(200);
    nocache_headers();
    header('Content-Type: application/json; charset=utf-8');
    header('X-Robots-Tag: noindex, follow');
    header('X-Content-Type-Options: nosniff');
    echo wp_json_encode($items, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT);
    exit;
}

Sieht trivial aus, ist aber an mehreren Stellen tückisch. Die status_header(200)-Zeile zum Beispiel: WordPress markiert URLs, die zu keiner internen Permalink-Regel passen, intern als 404 — und behält den Status bei, auch wenn dein Hook erfolgreich JSON ausliefert. Ohne diese Zeile bekommt jeder Crawler eine HTTP 404 Antwort und verwirft den Feed komplett. Den Bug findest du erst, wenn du die Response-Header im Curl prüfst.

Insight 1: HTTP 404 trotz gültiger JSON-Response

Das ist der Punkt, der uns die meiste Zeit gekostet hat. In Foren oder Tutorials zu „Custom Endpoints in WordPress" findet man das praktisch nirgends. Im Browser sah der Feed perfekt aus — aber Cloudflare-Logs zeigten 404er, und beim Testen mit curl -I kam tatsächlich HTTP/2 404.

Ursache: WordPress' Request-Lifecycle setzt den Status früh, basierend auf Permalink-Matching. Wenn der Pfad zu keiner Regel passt, wird intern 404 markiert. Späteres Output über template_redirect ändert daran nichts, solange du nicht explizit status_header(200) setzt.

Konsequenz: Wer einen JSON-Feed über template_redirect ausliefert, muss zwingend den Status manuell überschreiben.

Insight 2: Reviews aus Drittquellen brauchen Multi-Key-Matching

Unser Setup hatte einen separaten Reviews-Feed im Google Product Reviews Format. Die Reviews waren tief verschachtelt:

<reviews>
  <review>
    <ratings><overall min="1" max="5">5</overall></ratings>
    <products>
      <product>
        <product_ids>
          <skus><sku>PRODUCT-SKU-001</sku></skus>
          <gtins><gtin>1234567890123</gtin></gtins>
          <mpns><mpn/></mpns>
        </product_ids>
      </product>
    </products>
  </review>
</reviews>

Erste Implementation: SKU als Lookup-Key, fertig. Funktionierte nicht zuverlässig, weil im Produkt-Feed mal die SKU als item_id stand, mal die MPN, mal ein eigenes Format. Lösung: Review unter allen verfügbaren IDs gleichzeitig indexieren (SKU, GTIN, MPN), und beim Match im Produkt-Feed über alle drei probieren. Plus eine Dedup-Logik per Signatur, damit eine Review nicht dreimal zählt nur weil sie unter drei IDs liegt.

Das findet man in keiner Standardlösung, weil die meisten Beispiele Reviews und Produkte aus derselben Quelle annehmen.

Insight 3: Google Taxonomy IDs sind in der OpenAI-Welt wertlos

Wer aus einem bestehenden Google-Shopping-Feed importiert, hat in google_product_category numerische IDs wie 1604 oder 888. Das sind Google Merchant Center Taxonomy IDs, ein fest gepflegtes Vokabular.

Die OpenAI Spec verlangt explizit ein anderes Format: Apparel & Accessories > Shoes > Athletic Shoes — mit >-Separator und lesbarem Text.

Wer das einfach durchreicht und die nackte Zahl 1604 in den Feed schreibt, hat ein Feld, das ChatGPT nicht filtern oder verstehen kann. Lösung in unserem Setup: ein internes Mapping mit den relevantesten IDs für die jeweilige Kategorie, alle anderen werden lieber weggelassen als nackt durchgereicht.

$map = [
    '1604' => 'Apparel & Accessories > Shoes > Athletic Shoes',
    '888'  => 'Apparel & Accessories > Clothing > Activewear',
    '2492' => 'Home & Garden > Kitchen & Dining > Kitchen Tools',
    // ...
];

Die offizielle Google-Taxonomy-Liste hat über 6000 Einträge. Wir haben für unseren Use Case etwa 18 davon gebraucht. Lieber selektiv mappen als vollständig.

Insight 4: UTM-Parameter verzerren Attribution

Der Quell-Feed bei uns kam aus einem etablierten WooCommerce-Feed-Plugin und war primär für Google Shopping konfiguriert. Heißt: Jede Produkt-URL hatte UTM-Parameter dran:

?utm_source=Google%20Shopping&utm_campaign=USA%20Feed&utm_medium=cpc

Wenn ChatGPT diese URLs an User ausspielt und ein Klick erfolgt, taucht der Traffic in Analytics als „Google Shopping CPC" auf — obwohl er aus ChatGPT kommt. Das verzerrt eure gesamte Attribution.

OpenAI setzt eigene Referrer (utm_source=chatgpt.com). Wer also UTMs aus dem Quell-Feed übernimmt, verschenkt sauberes Tracking. Die saubere Variante: alle Tracking-Parameter strippen (utm_*, gclid, fbclid, msclkid), ChatGPT setzt dann seinen eigenen.

$strip_prefixes = ['utm_', 'gclid', 'fbclid', 'msclkid', 'mc_eid'];

Insight 5: Cache-Stampede ist real, ETag schon Standard

Wenn ein Feed unter einer öffentlichen URL liegt und mehrere Crawler gleichzeitig vorbeikommen, kann der Cache leer sein und alle Requests parallel den Build triggern. Bei einem 1-MB-XML-Parser auf einem typischen WordPress-Server reicht das, um den Server kurzzeitig in die Knie zu zwingen.

Lösung: Lock-Mechanismus über Transients. Wenn ein Build läuft, warten weitere Requests kurz und nutzen den fertigen Cache:

$lock = get_transient('feed_lock');
if ($lock) {
    for ($i = 0; $i < 16; $i++) {
        usleep(500000);
        $cached = get_transient('feed_cache');
        if (is_array($cached)) return $cached;
    }
}
set_transient('feed_lock', '1', 30);
// ... bauen ...
delete_transient('feed_lock');

Plus: ETag-Header setzen. Crawler senden beim nächsten Request If-None-Match mit dem alten ETag mit, und wenn nichts geändert wurde, antwortet der Server mit 304 Not Modified und null Bytes Payload. Spart bei jedem Recrawl rund 1 MB Bandbreite und Server-Last.

Was nichts bringt: .well-known/ai-commerce/

In mehreren frühen Tutorials und auch in unserem ersten Plugin-Entwurf gab es einen Endpoint unter /.well-known/ai-commerce/products.json plus ein Discovery-Manifest unter /.well-known/ai-commerce/. Die Idee dahinter: analog zu /.well-known/security.txt oder /.well-known/apple-app-site-association eine standardisierte Discovery-URL.

Klingt schlau. Funktioniert aber nicht. Wir haben sowohl die OpenAI-Doku als auch den offiziellen ACP (Agentic Commerce Protocol) im Detail durchsucht: .well-known/ai-commerce/ ist kein Standard. OpenAI nutzt diesen Pfad nirgends, GPTBot crawlt ihn nicht automatisch, und die einzigen .well-known/-Endpunkte im ACP-Ökosystem sind JWKS-Schlüssel für Authentifizierung — also was komplett anderes.

Wer das in seinem Setup hat, hat einen Pseudo-Standard erfunden, der keinen Crawler beeindruckt. Besser weglassen, dafür einen kanonischen Pfad /openai-products.json pflegen.

llms.txt: Was es bringt, was es nicht bringt

Die llms.txt-Spec ist 2024 entstanden als Vorschlag von Jeremy Howard. Idee: eine standardisierte Markdown-Datei im Webroot, die KI-Modellen einen kuratierten Überblick über die wichtigsten Inhalte einer Website gibt.

Yoast SEO hat die Funktion seit Version 23.x eingebaut, RankMath zieht nach. Die Datei wird typischerweise wöchentlich automatisch generiert und enthält Links zu den wichtigsten Seiten — About, Kontakt, Policies, Shop-Seite.

Praktische Konsequenz: llms.txt aktiv lassen und pflegen, aber nicht als „Sichtbarkeits-Booster für Produkte" missverstehen. Der Feed-Pfad gehört entweder in die robots.txt (als Kommentar oder über sauberes Crawling) oder direkt ins OpenAI-Onboarding-Formular.

robots.txt: Der unterschätzte Hebel

OpenAI nutzt vier verschiedene Bots, mit unterschiedlichen Aufgaben:

• OAI-SearchBot — Indexiert Inhalte für ChatGPT-Suchergebnisse. Der wichtigste der vier. Wenn du den blockst, taucht dein Shop in ChatGPT-Suchantworten überhaupt nicht auf.
• GPTBot — Crawlt für das Training der Foundation-Models. Wenn du den blockst, fließen deine Inhalte nicht ins Training, aber Search-Ergebnisse bleiben erreichbar. Seit Dezember 2025 teilt OpenAI die Crawl-Ergebnisse zwischen GPTBot und OAI-SearchBot, um doppeltes Crawling zu vermeiden.
• ChatGPT-User — Wird aktiv, wenn ein User explizit eine URL anfragt („zeig mir Produkt X auf der Website") oder über GPT Actions / Custom GPTs zugreift. Reagiert laut Doku nicht zwingend auf robots.txt, weil user-initiated.
• OAI-AdsBot — Validiert Landing Pages für ChatGPT-Anzeigen. Wenn ihr in ChatGPT werben wollt (auch in Zukunft), muss dieser Bot eure Produktseiten erreichen können, sonst schlägt die Ad-Validation fehl.

Der typische Fehler in robots.txt-Konfigurationen für KI-Bots: Man fügt einen pauschalen User-agent: GPTBot / Allow: / hinzu. Damit überschreibt man aber die spezifischeren Regeln aus dem User-agent: *-Block — inklusive der Disallows für Cart, Checkout und Suchergebnisse.

Robots.txt-Semantik: Der spezifischste User-Agent gewinnt komplett, nicht zeilenweise. Heißt: Du musst die Disallows pro Bot wiederholen, sonst öffnen sich für die OpenAI-Bots plötzlich URLs, die du für alle anderen explizit gesperrt hattest.

User-agent: OAI-SearchBot
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: */cart
Disallow: */checkout
Disallow: */wishlist
Disallow: */my-account
Allow: /

Das ist redundanter Code, aber so funktioniert das Protokoll.

Was bei einem WooCommerce-Shop wirklich passieren muss

Wenn du das bei dir nachbauen willst, sieht der pragmatische Plan so aus:

1. Datenquelle klären. Hast du bereits einen Google-Shopping-Feed über ein etabliertes WooCommerce-Feed-Plugin? Dann kannst du den als Quelle nutzen, statt direkt aus WooCommerce zu lesen. Vorteil: Die Datenqualität ist schon durch den Google-Standard validiert.
2. Eigenes Plugin bauen, nicht versuchen über existierende Plugins zu hacken. Es gibt aktuell keinen sauberen OpenAI-Connector für WooCommerce. Wer versucht, das über existierende Feed-Plugins zu lösen, bekommt entweder zu wenig Kontrolle oder zu viele unbeabsichtigte Seiteneffekte auf Google Shopping. Lieber ein dünnes eigenes Plugin, das ausschließlich lesend arbeitet.
3. Endpoint sauber konfigurieren. /openai-products.json mit HTTP 200, X-Robots-Tag: noindex, follow, ETag, Cache. Keine Sitemap-Verlinkung, kein Footer-Link ohne nofollow — sonst geht Googlebot drauf, was nichts bringt und nur Search-Console-Warnings produziert.
4. robots.txt erweitern. Vier OpenAI-Bots mit Allow-Regeln, aber Disallows pro Bot wiederholt. Plus die normalen Catch-all-Regeln für Googlebot unverändert lassen.
5. OpenAI-Onboarding starten. Über developers.openai.com/commerce/guides/get-started das Formular ausfüllen, mit Feed-URL als Referenz. Das ist der eigentliche Hebel — alles andere ist Vorbereitung.

Was die meisten falsch priorisieren

Aus unserer Erfahrung: Wer das Thema anpackt, verbringt 80% der Zeit mit den falschen Dingen.

Falsch priorisiert wird oft: JSON-LD Product Schema auf Produktseiten, llms.txt-Pflege, das exakte Format jedes optionalen Feldes, eigene Discovery-Endpunkte unter .well-known/.

Richtig wichtig ist: Sauberer Endpoint mit HTTP 200, GTIN bei allen Produkten, lesbare Kategorien, korrekte URLs ohne UTM-Müll, und das Onboarding-Formular bei OpenAI ausfüllen.

Das Onboarding ist der einzige Weg, real in den ChatGPT-Shopping-Index zu kommen. Alles andere ist Voraussetzung dafür, aber kein Ersatz.

Was passiert, wenn man nichts macht

Ehrliche Antwort: Wahrscheinlich nicht viel, kurzfristig. ChatGPT-Search ist noch nicht der Kanal, der ein Geschäft trägt. Selbst große Retailer berichten von einstelligen Prozentsätzen ihres Traffics aus ChatGPT.

Aber: Die Kurve geht steil nach oben. Walmart hat im April 2026 als erster großer Retailer das App-Modell live geschaltet. Etsy und Sephora ziehen nach. In zwölf bis 24 Monaten wird Agentic Commerce ein Kanal sein, in dem die etablierten Player nicht mehr nachträglich aufholbar sind — ähnlich wie bei Google Shopping zwischen 2014 und 2018.

Wer jetzt ein Wochenende investiert, ist vorbereitet. Wer wartet, bewirbt sich später um die Plätze, die andere schon belegt haben.

Was wir konkret bauen würden, wenn wir nochmal anfangen würden

Erstens: Nicht versuchen, alle Spec-Felder auf einmal abzudecken. Mit den 15 echten Pflichtfeldern starten, plus GTIN, plus saubere Kategorien. Den Rest iterieren.

Zweitens: Performance und Caching von Anfang an mitdenken. Auch wenn der Feed nur einmal pro Stunde gebaut wird — wenn er gebaut wird, muss er schnell sein.

Drittens: ETag und HTTP 304 ernst nehmen. Crawler crawlen häufiger als man denkt. Bandbreite und Crawl-Budget sparen lohnt sich.

Viertens: Trennung zwischen „Discovery-Vorbereitung" und „echte Indexierung". Der öffentliche Feed-Endpoint ist Vorbereitung. Real wirksam wird er erst nach OpenAI-Onboarding. Diese Erwartungshaltung muss bei allen Beteiligten klar sein.

Fünftens: Nichts machen, was Google Shopping beeinflussen könnte. Das ist nach wie vor der wichtigste bezahlte Kanal. Der OpenAI-Feed muss komplett orthogonal laufen — eigener Endpoint, eigener Cache, eigene robots.txt-Sektionen, kein Eingriff in bestehende Plugins.

Wo das hingeht

OpenAI Commerce ist gerade in einer Übergangsphase. Die File-Upload-Spec ist stable, die API-Variante wird parallel aufgebaut, der Wechsel zu Retailer-Apps läuft. Wer heute baut, baut für einen Zielzustand, der sich in den nächsten sechs Monaten nochmal verschieben wird.

Das ist okay. Die Grundkonzepte bleiben: Strukturierte Produktdaten in einem JSON-Format, das ChatGPT lesen kann, plus klare Discovery-Pfade über robots.txt und Onboarding. Was sich ändert, sind Felder, optionale Erweiterungen und der genaue Ingest-Mechanismus.

Wer einmal ein Plugin gebaut hat, das diese Aufgabe sauber löst, hat eine Architektur, die jede Spec-Iteration der nächsten zwei Jahre überlebt.

Und nebenbei ein Verständnis davon, wie Agentic Commerce technisch wirklich funktioniert — eine Disziplin, die in zwei Jahren so spezialisiert sein wird wie heute Conversion-Tracking oder Server-Side Tagging.