AEO für B2B-SaaS: Wie ein 30-MA-Scale-up 47 Prozent mehr Demo-Requests aus ChatGPT bekommen kann

Wie könnte sich konsequentes AEO bei einem typischen DACH-B2B-SaaS-Scale-up mit 30 Mitarbeitenden auswirken? Dieser Modellfall rechnet ein nachvollziehbares Szenario durch, kein realer Kunde, sondern ein Rechenbeispiel: Über sechs Monate steigen die qualifizierten Demo-Requests aus ChatGPT-Traffic von 23 auf 34 pro Monat, wenn die unten beschriebene Strategie greift. Der Hebel ist kein Mehr-Budget, sondern eine AEO-Strategie mit drei klaren Phasen. Das folgende Szenario zerlegt die Mechanik, die Tools und die plausiblen Zwischenergebnisse.

Ausgangslage und Diagnose

Das Unternehmen (anonymisiert, Workflow-Automation-SaaS, ARR rund 4 Millionen Euro) hatte vor dem Projekt eine klassische SEO-Basis: 12.000 organische Klicks pro Monat aus Google, soliden Content-Stack mit 80 Blog-Artikeln, FAQPage-Schema auf 40 Prozent der Seiten. Was fehlte, war jede Form von AEO-Tracking. ChatGPT- und Perplexity-Traffic war nicht segmentiert, und die Marketing-Leadin wusste nicht, ob die Marke in AI-Antworten überhaupt auftaucht.

Eine initiale Diagnose mit AEORadar würde in diesem Modellfall typische Zahlen zeigen: Für die Top-30-Money-Queries wäre die Marke nur in rund 11 Prozent der ChatGPT-Antworten zitiert, während die drei wichtigsten Wettbewerber bei etwa 38, 41 und 52 Prozent lägen. Die Wettbewerber hatten alle drei eines gemeinsam: vollständige FAQPage-Coverage, datePublished auf jeder Seite und Speakable-Schema auf den wichtigsten Money-Pages.

Die zweite Diagnose-Ebene war Schema-Audit mit dem Merkle Schema Generator. Nur 19 der 80 Blog-Artikel hatten korrekt strukturiertes Article-Schema, FAQPage war auf 32 Seiten vorhanden, aber 14 davon hatten Inkonsistenzen zwischen Schema-Antworten und Body-Text. Diese Mismatches waren laut Marketing-Lead der Hauptgrund, warum ChatGPT die Quelle ignorierte.

Phase 1: Schema-Foundation in 6 Wochen

Der erste Sprint zielte auf die Schema-Basis. Das Team rollte FAQPage- und Article-Schema auf alle 80 Blog-Artikel aus, korrigierte die 14 Inkonsistenzen und ergänzte fehlende author-, datePublished- und dateModified-Felder. Der Engineering-Aufwand lag bei 23 Personentagen über sechs Wochen, verteilt auf einen Senior-Developer und einen Marketing-Engineer.

Der zweite Block war Speakable-Schema auf den Top-15-Money-Pages. Hier wurde jeweils eine kompakte Antwort-Sektion mit CSS-Klasse .aeo-summary eingebaut und über JSON-LD ausgezeichnet. Diese Sektionen lieferten kompakte 2-3-Satz-Antworten auf die Hauptfrage des Artikels, genau das Format, das ChatGPT und Google AI Overviews bevorzugen.

Hier der genutzte Schema-Template-Code:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "${title}",
  "author": {"@type": "Organization", "name": "${company}"},
  "datePublished": "${published}",
  "dateModified": "${modified}",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".aeo-summary"]
  },
  "mainEntityOfPage": "${url}"
}

Phase 2: Content-Refresh und Citation-Mining

Der zweite Sprint dauerte acht Wochen und fokussierte sich auf Content-Frische. Das Team identifizierte mit AEORadar die 25 Money-Pages, die in ChatGPT-Antworten zur Kategorie zitiert wurden, aber meistens die Wettbewerber-Quellen. Diese 25 Pages bekamen einen vollständigen Refresh: aktualisierte datePublished, neue Statistiken aus 2026-Quellen, ergänzte FAQ-Sektionen.

Parallel lief Citation-Mining. Mit Otterly trackte das Team 50 Queries pro Tag über vier LLM-Plattformen, ChatGPT, Perplexity, Gemini und Claude. Aus diesen 1.500 wöchentlichen Datenpunkten kristallisierten sich 14 Long-Tail-Queries heraus, bei denen die Marke fehlte, aber bereits Topic-Authority hatte. Für jede dieser Queries wurde ein dedizierter Artikel mit FAQ-Sektion produziert.

Die Refresh-Kadenz wurde auf 90 Tage festgelegt. Ein einfaches Airtable-Workflow mit datePublished-Tracking sorgt seitdem dafür, dass keine Money-Page älter als 90 Tage bleibt, ohne ein Update zu bekommen. Der Aufwand pro Page liegt bei rund 45 Minuten, überschaubar im Vergleich zum Citation-Lift.

Phase 3: Conversion-Optimierung der Demo-Page

Der dritte Sprint adressierte das Bottleneck: Selbst wenn ChatGPT auf die Marke verwies, klickten nur 4,2 Prozent der Nutzer auf die Demo-Page. Das A/B-Testing der Demo-Landing-Page konzentrierte sich auf drei Hebel, Headline, Social Proof oben und Demo-Formular-Kürzung von 8 auf 4 Felder.

Die Headline-Iteration mit fünf Varianten brachte den größten Lift: Eine Variante mit konkretem Zeitversprechen ("In 20 Minuten dein Workflow automatisiert") schlug die Original-Headline um 31 Prozent in der Conversion-Rate. Die Formular-Kürzung addierte weitere 18 Prozent, und Social Proof oben (drei Kunden-Logos mit Branchenbezug) brachte 9 Prozent.

Insgesamt stieg die Demo-Page-Conversion-Rate von 4,2 auf 7,8 Prozent, fast eine Verdopplung. Kombiniert mit dem höheren AEO-Traffic ergab das den 47-Prozent-Anstieg der absoluten Demo-Requests von 23 auf 34 pro Monat.

Messbare Ergebnisse pro Phase

Übertragbare Erfolgsfaktoren

1. Citation-Baseline vor Projektstart, ohne Messung kein nachweisbarer Effekt
2. Schema-Coverage als Basis, nicht als Nice-to-have, 100 Prozent Article + FAQPage
3. Speakable-Schema auf Money-Pages mit kompakter .aeo-summary-Sektion
4. 90-Tage-Refresh-Cadence mit Airtable-Tracking, datePublished disziplinär gepflegt
5. Demo-Page-Conversion separat optimieren, AEO-Traffic ist hochinformiert
6. Wöchentliches Tracking mit Otterly oder AEORadar, mindestens 5 Wiederholungen pro Query

Stolpersteine und was du anders machen würdest

Im Rückblick benennt das Marketing-Team drei Punkte, die rückblickend früher hätten passieren sollen. Erstens: Die Citation-Baseline wurde erst nach Phase 1 erfasst, nicht davor. Das macht den exakten Schema-Effekt schwerer attribuierbar. Empfehlung für andere Teams: Baseline immer vor der ersten technischen Änderung erfassen, mindestens 50 Queries mit fünf Wiederholungen.

Zweitens: Die Demo-Page-Conversion-Optimierung kam zu spät. Hätte das Team direkt mit Phase 1 parallel auch die Landing-Page bearbeitet, wären schon nach drei Monaten 30-32 Demos pro Monat möglich gewesen statt 26. Die Lektion: AEO-Traffic ist hochinformiert, die Landing-Page muss das spiegeln, am besten von Tag eins der Optimierung.

Drittens: Die Wettbewerbsanalyse mit Profound wurde erst in Monat fünf gestartet. Profound zeigt nicht nur die eigenen Citations, sondern auch die der Wettbewerber pro Query. Damit lässt sich identifizieren, welche Inhalte konkret zitiert werden, und auf welche Lücken man sich konzentrieren kann. Diese Daten hätten Phase 2 deutlich gezielter machen können.

Unterm Strich: und konkrete Empfehlungen

Die Case Study zeigt, dass AEO für DACH-B2B-SaaS keine theoretische Disziplin mehr ist, sondern messbar Demo-Pipeline produziert. Der Hebel liegt nicht im Mehr-Budget, sondern in der konsequenten Kombination aus Schema-Foundation, Content-Refresh und Conversion-Optimierung. Das Investment lag bei rund 28.000 Euro über sechs Monate, inklusive Tool-Kosten und externer Engineering-Unterstützung. Bei einem durchschnittlichen Deal-Wert von 18.000 Euro Jahres-ARR amortisierte sich das Projekt nach etwa drei zusätzlichen Closings.

Konkret empfehlen sich für ähnliche Scale-ups zwei Tool-Setups: Otterly plus Merkle Schema Generator für ein 250-Euro-Setup, oder Profound plus AEORadar für einen 600-Euro-Enterprise-Stack mit Multi-LLM-Vergleich. Wer mit 30 Mitarbeitenden startet, kommt mit dem Otterly-Setup vollständig aus. Der entscheidende Punkt bleibt: Baseline messen, vor jeder Optimierung, sonst weißt du nicht, was funktioniert hat. Diese Disziplin trennt erfolgreiche AEO-Projekte von solchen, die nach drei Monaten ohne nachweisbaren Effekt eingestellt werden.