AI Visibility: Das evidenzbasierte Operating Playbook

1. Sichtbarkeit als Entscheidungsproblem

AI Visibility bezeichnet hier die beobachtbare Präsenz einer Marke oder Quelle in ausgewählten suchgestützten Antwortoberflächen. Es ist weder eine einheitliche Plattformkennzahl noch ein Anspruch auf vollständige Messbarkeit. Beginnt mit einer konkreten Frage eines Buying Committees: etwa welche Voraussetzungen eine revisionsfähige Freigabe von Lieferanten braucht. euer Ziel kann eine richtige Produktbeschreibung, eine hilfreiche Quellenverlinkung oder ein qualifizierter Besuch sein. Diese Ziele verlangen unterschiedliche Nachweise. Der Leitfaden verwendet das eigene Modell Zugang–Aussage–Auswahl–Aktion: Zugang ist überprüfbar, Aussagen sind redaktionell beeinflussbar, die Auswahl durch ein System bleibt fremdbestimmt, die anschließende Handlung muss gesondert gemessen werden.

Einen nutzbaren Entscheidungsauftrag festlegen

Schreibt die geschäftliche Entscheidung vor der Datensammlung auf: Welcher Käufer braucht eine Antwort, welche Handlung wird dadurch möglich und wer darf die Änderung freigeben? Legt Prüftermin und maximalen Zeitaufwand fest. Dokumentiert die bisherige Seite oder Vorgehensweise so, dass ein Kollege den Ausgangspunkt nachvollziehen kann. Trennt eine Aussage aus öffentlicher Dokumentation von eurer Interpretation und einer noch ungeprüften Hypothese. So wird eine vernünftige redaktionelle Praxis nicht zur erfundenen Anforderung einer Suchmaschine.

Die Arbeitseinheit besteht aus einer Käuferfrage, einer relevanten Seite oder Seitengruppe und einem beobachtbaren Ergebnis. Kombiniert im ersten Test keinen Produktstart mit einem Relaunch und einem neuen Messkonzept. Sind die Änderungen untrennbar, kennzeichnet das Ergebnis als Beobachtung. Ein positives Ergebnis kann die nächste Iteration begründen, aber nicht den Anteil jeder Maßnahme erklären.

• Ins Briefing kopieren: Käufer, Entscheidung, Umfang, Ausgangsdatum, Verantwortlicher, Freigabe, Prüftermin.
• Die stärkste alternative Erklärung einer erwarteten Verbesserung notieren.
• Anhalten, wenn niemand die Entscheidung benennen kann, die diese Arbeit verändert.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: AI features and your website.

2. Die fünf Stufen auseinanderhalten

Crawling ist Abruf, Indexierung die mögliche Aufnahme und Verarbeitung, Ranking die Auswahl und Reihenfolge in einem Suchkontext. Retrieval bezeichnet die Beschaffung von Informationen für eine konkrete Aufgabe; Zitierung ist die sichtbare Quellenzuordnung in einer Antwort. Diese Vorgänge können zusammenwirken, sind aber nicht identisch. Ein Serverlog belegt einen Request, keine Indexaufnahme. Ein Suchtreffer belegt kein Zitat. Ein Zitat belegt nicht, dass alle Aussagen der Antwort aus eurer Seite stammen. Verwendet im Register daher fünf getrennte Felder. Wo keine direkte Beobachtung möglich ist, bleibt das Feld unbekannt statt aus der nächsten Stufe rückwärts erschlossen zu werden.

Ein Evidenzregister aufbauen

Sammelt Belege in einem kleinen Register statt ausschließlich in Präsentationsbildern. Jede Zeile braucht Frage, genaue URL, Beobachtungsdatum, Sprache, Umgebung, beobachtetes Verhalten, Interpretation und Sicherheit. Speichert beispielsweise Antwortheader, einen Ausschnitt der gerenderten Seite, einen Export oder eine Antwortkopie, soweit Zugriffsrechte und Aufbewahrung dies erlauben. Der Beleg soll das Geschehen zeigen und nicht nur die Schlussfolgerung des Analysten. Entfernt personenbezogene Informationen und Zugangsdaten vor der Weitergabe.

Verwendet drei Kennzeichnungen: bestätigte Beobachtung, gestützte Interpretation und offene Hypothese. Sie beschreiben die Beleglage, nicht die geschäftliche Bedeutung. Ein bestätigt defekter Link kann wenig relevant sein; ein plausibles Sicherheitsproblem kann sofortige Prüfung verlangen. Benennt jemanden, der Unsicherheit auflöst. Ein leeres Feld bedeutet unbekannt, nicht null oder erfolgreich.

• Mindestens zwei relevante Seitentypen prüfen, bevor Aussagen für die gesamte Website entstehen.
• Ausgeschlossene und fehlgeschlagene Beobachtungen samt Grund sichtbar lassen.
• Die Zusammenfassung stoppen, wenn Sprache, Umgebung oder Berichtsdefinitionen nicht vergleichbar sind.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: AI features and your website.

3. Zugriff und Steuerung auditieren

Erstellt eine Matrix aus Domain, Pfad, Botzweck und gewünschter Freigabe. Suchzugriff und Modelltraining sind unterschiedliche Entscheidungen. Die OpenAI-Dokumentation unterscheidet beispielsweise OAI-SearchBot und GPTBot; prüft die aktuelle Beschreibung vor einer Änderung. Ein User-Agent allein bestätigt keine Botidentität. Vergleicht relevante Zugriffe mit den veröffentlichten Verifikationsinformationen und untersucht Blockierungen in CDN oder WAF. robots.txt ersetzt weder Authentifizierung noch einen Vertraulichkeitsschutz. Zugängliche Marketingseiten und geschützte Kundendaten gehören in unterschiedliche technische Regeln. Lasst Ausnahmen durch Engineering und den zuständigen Sicherheitsverantwortlichen prüfen.

Den tatsächlichen Auslieferungsweg prüfen

Vergleicht Browseransicht, ausgelieferte Antwort und gegebenenfalls die Prüfwerkzeuge einer Suchmaschine. Erfasst angeforderte URL, Weiterleitungsziel, HTTP-Status, relevante Header, gerenderten Hauptinhalt und den Link zur Seite. Eine im eigenen Browser korrekte Seite belegt keinen Zugriff durch Crawler. Umgekehrt beweist eine fehlende Seite in einem manuellen Antworttest kein Crawlingproblem.

Prüft normalen Besuch und neue Sitzung, ohne vorauszusetzen, dass Anmeldung oder erteilte Einwilligung übertragen werden. Untersucht auf Desktop und Mobilgerät besonders Belege und nächste Handlung, nicht nur die Optik. Fordert eine Sicherheitsschicht automatisierte Zugriffe heraus, bezieht den Infrastrukturverantwortlichen ein, statt Schutzmaßnahmen pauschal zu lockern. Eine gezielte dokumentierte Zugriffskorrektur ist einer ungeprüften Ausnahme für die gesamte Anwendung vorzuziehen.

• Einen erfolgreichen und einen fehlerhaften Request zur Reproduktion wechselnder Auslieferung speichern.
• Den frühesten beobachtbaren Fehler bestimmen, bevor Inhalte geändert werden.
• Veröffentlichung stoppen, wenn zentrale Aussagen oder Navigation außerhalb einer privilegierten Sitzung verschwinden.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: OpenAI: Overview of crawlers.

4. Entitäten und Produktwahrheit klären

Definiert ein kleines öffentliches Faktenblatt: offizieller Markenname, Anbieter, Produktkategorie, Zielrolle, Kernfunktion, unterstützte Integrationen und dokumentierte Grenzen. Eine gute Seite beantwortet ausdrücklich, ob eine Funktion im Standardtarif, Zusatzmodul oder erst auf Anfrage verfügbar ist. Fehlende Einschränkungen erzeugen falsche Erwartungen, selbst wenn die Marke oft genannt wird. Prüft ähnliche Namen von Unternehmen und Produktmodulen. Eine klare Kontakt- und Unternehmensseite hilft Besuchern, den Anbieter zu identifizieren. Strukturierte Daten müssen sichtbare Angaben korrekt abbilden; Schema-Markup ist weder ein Ersatz für verständliche Texte noch eine Garantie für AI-Präsenz.

Der öffentliche Produktabgleich

Öffnet Produktseite, Preisseite und technische Dokumentation nebeneinander. Markiert für jede wichtige Fähigkeit dieselben vier Angaben: verfügbare Aktion, berechtigte Rolle, Tarif und Voraussetzung. Schon eine abweichende Einschränkung kann aus einer richtigen Kurzbeschreibung ein falsches Versprechen machen. Gebt jedem Widerspruch einen Faktenowner. Entscheidet, welche aktuelle Angabe gilt, und korrigiert anschließend alle betroffenen öffentlichen Kopien einschließlich Downloads. Prüft danach die Seite mit einer einfachen Gegenfrage: Unter welcher Bedingung wäre dieser Satz falsch? Wenn die Bedingung für Käufer relevant ist, gehört sie neben die Aussage. Erst nach diesem Abgleich lohnt sich eine breitere Beobachtung fremder Antworten.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: Structured data policies.

5. Käuferfragen nach Evidenzwert wählen

Sammelt Fragen aus freigegebenen Vertriebsgesprächen, Supportmustern, Produktdokumentation und Interviews. Kennzeichnet die Herkunft, ohne vertrauliche Gesprächsinhalte zu veröffentlichen. Gewichtet Entscheidungsrelevanz, Produktpassung, verfügbare Belege und Pflegefähigkeit. Die interne Priorität darf keine erfundene Nachfragezahl enthalten. Eine häufig gestellte Grundsatzfrage kann eine geringe Produktpassung haben; eine seltenere Integrationsfrage kann eine kritische Kaufhürde lösen. Reserviert beide Arten, aber beurteilt sie nicht anhand desselben Erfolgsmaßes. Schließt Fragen aus, für die euer Team nur unbelegte Behauptungen liefern könnte.

Das Fragenportfolio begrenzen

Wählt für den ersten Zyklus einen kleinen Mix aus vier Entscheidungstypen. Verknüpft jede Frage mit einem realen Produktbezug und einer belastbaren Zielseite. Fügt eine Ausschlussliste hinzu: Rechtsauskünfte ohne Fachprüfung, unbelegte Wettbewerbervergleiche und Zukunftsfunktionen bleiben außerhalb des öffentlichen Antwortprogramms. Ein Fragenowner dokumentiert, warum ein Thema aufgenommen wird und welches andere Thema dafür warten muss. Bei neuen Vertriebsfragen prüft ihr zuerst, ob eine vorhandene Seite erweitert werden kann. So entsteht kein endloser Promptkatalog, sondern ein begrenztes Portfolio nützlicher Antworten. Die Priorität ist intern begründet und wird nicht als Nachfragevolumen des Marktes ausgegeben.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: Helpful, reliable content.

6. Quellenfähige Seiten produzieren

Eine belastbare Antwortseite enthält eine direkte Einordnung, Bedingungen, nachvollziehbare Schritte, ein begrenztes Beispiel und verlinkte Belege. Bei technischen Abläufen nennt Versionsstand, Voraussetzungen und Fehlermeldungen, soweit öffentlich zulässig. Zeigt das Ergebnis einer Handlung und erklärt, wie ein Leser es prüfen kann. Veröffentlicht keine künstlichen Studien oder erfundenen Kundenresultate als originäre Forschung. Ein sauber erklärter eigener Test mit Methode und Grenze ist wertvoller als eine scheinbar repräsentative Prozentzahl. Erhaltet den fachlichen Zusammenhang, auch wenn einzelne Abschnitte gut allein verständlich sein sollen.

Einen zitierbaren Beleg sauber begrenzen

Beschreibt bei einem eigenen Produkttest Testumgebung, Datenart, durchgeführte Schritte und tatsächlich beobachtetes Ergebnis. Ein erfolgreicher Test mit Beispieldaten zeigt den getesteten Ablauf, nicht die Leistung bei jedem Kunden. Verlinkt auf die aktuelle Dokumentation und nennt Abweichungen zu älteren Versionen. Ersetzt werbliche Superlative durch überprüfbare Aussagen, etwa welche Exportfelder vorhanden sind. Eine Datentabelle braucht Einheiten und Zeitraum; ein Screenshot braucht Kontext und darf keine vertraulichen Kundendaten zeigen. Prüft abschließend, ob die Aussage auch außerhalb ihres Absatzes missverstanden werden könnte. Ergänzt nötige Bedingungen direkt am Beleg, statt auf entfernte Haftungstexte zu vertrauen.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: Helpful, reliable content.

7. Beobachtungen statt Prompt-Theater

Verwendet ein festes Set aus Grundlagen-, Vergleichs-, Implementierungs- und Risikofragen. Trennt Markenfragen von unmarkierten Fragen, weil beide andere Voraussetzungen haben. Protokolliert die gesamte sichtbare Quellenmenge und nicht nur eure Domain. Prüft, ob ein Link tatsächlich zur angegebenen Seite führt und ob diese die referenzierte Aussage unterstützt. Bewertet Markennennung, verlinkte Quelle und sachliche Richtigkeit gesondert. Ein gutes Ergebnis kann eine richtige Antwort ohne eigene Nennung sein; ein schlechtes Ergebnis kann eine prominent zitierte, aber überholte Produktangabe sein.

Quellenqualität zusätzlich zur Präsenz kodieren

Ein Analyst prüft für jede eigene Quellenreferenz drei Dinge: Ist der Link erreichbar, trägt die Zielseite die zugeordnete Behauptung und ist die Information aktuell? Eine verlinkte Startseite kann für die Anbieteridentität passen und für eine Integrationsgrenze ungeeignet sein. Markiert diese Fälle unterschiedlich. Haltet fremde falsche Aussagen getrennt von eigenen veralteten Angaben fest, weil ihr nur Letztere unmittelbar ändern könnt. Wenn eine Antwort ohne sichtbare Quellen entsteht, bleibt die Belegzuordnung unbekannt. Unterstellt keinen bestimmten Retrievalweg. Der Monatsvergleich zeigt deshalb Präsenz und Quellenqualität nebeneinander und beschreibt Korrekturbedarf konkret auf Claim-Ebene.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Microsoft: Introducing AI Performance.

8. Besuche und Pipeline vorsichtig verbinden

Eine Sucherscheinung ist keine Sitzung. Eine Sitzung mit erkennbarer AI-Referrer-Domain ist keine vollständige Messung aller AI-Einflüsse. Prüft verweisende Quellen, Einstiegsseiten, qualifizierte Ereignisse und CRM-Fortschritt jeweils mit passender Definition. Fragt im Formular optional, wie ein Interessent auf das Unternehmen aufmerksam wurde; bewahrt Freitext nur entsprechend euren Regeln auf. Vergleicht diese Angabe mit messbaren Quellen, ohne eine Übereinstimmung zu erzwingen. Berichtet unterstützte Pipeline als Modellperspektive und qualifizierte Besuche als Beobachtung, nicht als bewiesenen zusätzlichen Umsatz durch eine Zitierung.

Einen Referral-Abgleich durchführen

Baut einen Bericht mit Einstiegsseite, Sitzungsquelle und einem vorher definierten qualifizierten Ereignis. Prüft zunächst einen kontrollierten Testbesuch, damit Filter und Ereignisse nachvollziehbar sind. Verbindet danach nur die zulässigen und tatsächlich verfügbaren Kontodaten mit dem CRM. Eine fehlende Referrer-Angabe wird als unbekannt behandelt; sie wird nicht nachträglich einer AI-Oberfläche zugeschrieben, nur weil eine Nennung beobachtet wurde. Ergänzt im Bericht die Zahl der eindeutig zuordenbaren Anfragen und den Zeitraum der Prüfung. Bei sehr kleinen Zahlen beschreibt ihr einzelne aggregierte Befunde, statt volatile Konversionsraten als belastbare Kanalleistung zu verkaufen. Haltet Selbstberichte in einer separaten Spalte.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google Analytics: Traffic acquisition.

9. Fehlbilder richtig interpretieren

Wenn Botzugriffe vorhanden sind, aber keine Stichprobenzitierung erscheint, bleiben mehrere Erklärungen offen: schwache Fragenpassung, andere ausgewählte Quellen, kleine Stichprobe oder fehlende Indexaufnahme. Keine davon folgt zwingend aus dem Log. Bei falscher Produktbeschreibung prüft zunächst die eigene Website auf widersprüchliche aktuelle und alte Angaben. Bei steigenden Nennungen ohne Besuche untersucht Antwortnutzen und Handlungspfad, statt automatisch die Texte zu verkürzen. Bei sinkenden Besuchen und stabilen qualifizierten Anfragen kann sich die Besuchszusammensetzung geändert haben. Entscheidend ist die früheste durch Belege unterstützte Diagnose.

Drei typische Befunde unterscheiden

Befund eins: Die öffentliche Seite liefert eine Sicherheitsabfrage. Hier prüft Engineering die konkrete Auslieferung und Botverifikation. Befund zwei: Die Seite ist erreichbar, nennt aber unterschiedliche Produktgrenzen. Hier verantwortet Product Marketing einen Faktenabgleich. Befund drei: Die Seite ist erreichbar und korrekt, erscheint im kleinen Fragenkern aber nicht. Hier ist die Ursache offen; eine automatische technische Fehlermeldung wäre unberechtigt. Für jeden Befund gibt es daher einen anderen nächsten Schritt. Dokumentiert bei offenen Auswahlfragen die Alternative, dass andere Quellen den konkreten Bedarf besser erfüllen. Entscheidet erst nach weiteren passenden Beobachtungen über zusätzliche Produktion oder technischen Umbau.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: OpenAI: Overview of crawlers.

10. FIKTIVES SaaS-Beispiel: FreigabeCloud

FIKTIV: FreigabeCloud verkauft Lieferantenfreigaben an mittelständische Einkaufsabteilungen. Annahmen sind zwölf öffentliche Kernseiten, zwei Sprachen und ein kleiner gemeinsamer Marketing- und Produktzyklus. Das Team entdeckt eine veraltete Seite, die einen inzwischen entfernten CSV-Import verspricht. In angenommenen zwanzig gültigen Antwortbeobachtungen nennen sechs die Domain; zwei davon enthalten diese falsche Aussage. Die erste Entscheidung lautet Korrektur und Abgleich der Produktwahrheit, nicht Steigerung der Nennungsrate. Nach Veröffentlichung prüft das Team Erreichbarkeit und richtige Angaben, wiederholt dieselben Fragen und meldet Ergebnisse als Stichprobenbefund. Es gibt keine reale Kundenwirkung und keinen abgeleiteten Umsatz.

Die Fallentscheidung nachrechnen

Im fiktiven Beispiel beträgt die Nennungsrate sechs von zwanzig. Die relevante Qualitätsfrage ist jedoch zunächst, warum zwei genannte Antworten eine veraltete Funktion enthalten. Das Team erstellt eine Liste aller eigenen Seiten mit dieser Behauptung und korrigiert die nachweislich falschen Angaben. Es kann danach berichten, dass diese eigenen Kopien korrigiert wurden. Es darf noch nicht behaupten, dass fremde Antworten vollständig aktualisiert sind. Dafür werden neue Läufe mit denselben Fragen benötigt. Bleibt der Fehler bestehen, wird der Befund samt Datum weitergeführt. Diese Trennung verhindert, dass ein abgeschlossener redaktioneller Task mit einer kontrollierbaren externen Wirkung verwechselt wird.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: Helpful, reliable content.

11. Ein 90-Tage-Betriebsrhythmus

In den ersten zwei Wochen definieren Marketing und Produkt Fragen, Faktenblatt und Kontrollen. Engineering prüft Auslieferung an einer kleinen wichtigen Seitengruppe. Bis Tag dreißig entsteht ein erstes vollständiges Antwortpaket mit Ausgangsbeobachtungen. Im zweiten Monat folgen Prüfung, Korrekturen und vorsichtige Erweiterung auf die zweite Sprache. Im dritten Monat werden Pflegebedarf und geschäftliche Signale gemeinsam bewertet. Die Zeitfenster sind Planungsannahmen, keine Frist bis zu einer Suchwirkung. Wenn Grundlagen fehlen, bleibt der Umfang klein. Ein sauber gepflegtes Paket hat Vorrang vor einer großen Zahl unbelegter AI-optimierter Seiten.

Den ersten Zyklus wirklich abschließen

Ein Zyklus endet mit vier prüfbaren Ergebnissen: ein freigegebener Fragenkern, korrigierte Produktfakten, ein technisch kontrolliertes Seitenpaket und ein nachvollziehbarer Beobachtungsexport. Jedes Ergebnis hat einen Namen und einen Abnahmetermin. Marketing koordiniert, aber Engineering muss nicht für eine ungeklärte Produktbehauptung haften und Produkt muss keinen Trafficgewinn versprechen. Im Abschlussgespräch entscheidet das Team, welche Unsicherheit die nächste Runde auflösen soll. Wenn nur mehr Fragen gesammelt wurden, aber keine Seite verbessert oder geprüft wurde, ist der Zyklus noch nicht abgeschlossen. Verkleinert dann den Umfang und beendet zuerst die offenen Kernaufgaben.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: AI features and your website.

12. Weiterführen, korrigieren oder stoppen

Führt weiter, wenn Inhalte eine belegte Käuferfrage lösen, Aussagen gepflegt werden und Prüfung bezahlbar ist. Korrigiert, wenn ein bestimmter Fehler mit klarem Test vorliegt. Stoppt Ausweitung, wenn nur kosmetische Promptgewinne ohne stabile Methode entstehen, wenn Produktbelege fehlen oder wichtige Pflegearbeit liegen bleibt. Eine negative kleine Stichprobe allein rechtfertigt keine Abschaffung nützlicher Dokumentation. Eine positive Stichprobe allein rechtfertigt kein großes Budget. Legt die Budgetentscheidung neben die Qualitätsentscheidung, damit Suchunsicherheit nicht mit redaktioneller Nutzlosigkeit verwechselt wird.

Erweiterung an konkrete Bedingungen knüpfen

Vor einer zweiten Produktlinie oder Sprache prüft ihr drei Voraussetzungen: Die erste Gruppe ist korrekt gepflegt, die Methode kann von einem Kollegen wiederholt werden und der zusätzliche Aufwand hat einen Owner. Ein positiver Einzelprompt erfüllt keine dieser Bedingungen. Ein begrenzter negativer Befund verhindert Erweiterung ebenfalls nicht automatisch, wenn die Seiten eine dokumentierte Käuferhürde lösen. Setzt für die Erweiterung einen Kostenrahmen und eine nächste Entscheidung fest. Bleibt die neue Gruppe ohne belastbare Produktbelege, wird sie zurückgestellt. So bleibt das Programm auch dann sinnvoll steuerbar, wenn externe Zitierungen stark schwanken und keine schnelle kommerzielle Zuordnung möglich ist.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google Analytics: Attribution.

13. Arbeitsblätter für den Betrieb

Nutzt vier verknüpfte Arbeitsblätter: Fragenregister, Produktfakten, technische Freigaben und Beobachtungsprotokoll. Die gemeinsame Kennung verbindet eine Frage mit Zielseite, belegter Aussage, Verantwortlichem und Prüftermin. Markiert im Faktenblatt veraltete Angaben, die auch in Downloads oder Übersetzungen korrigiert werden müssen. Das Beobachtungsprotokoll enthält zusätzlich gültige negative Ergebnisse und nicht verfügbare Tests. Ein Monatsbericht soll Entscheidungen zeigen: welche Käuferhürde gelöst wurde, welcher Fehler offen bleibt und welcher nächste Beleg eine Erweiterung erlauben würde. Screenshots sind Anhänge und nicht der Ersatz für diese Entscheidungskette.

Eine vollständige Beispielzeile führen

Q-01 fragt nach Rollenrechten für den Export. Die Zielseite heißt im Arbeitsblatt P-04; der Produktbeleg E-09 nennt Administratorrechte und abgeschlossene Vorgänge. Product Marketing bestätigt den Claim, Engineering prüft Erreichbarkeit und Marketing dokumentiert den Fragenlauf. Ein offener Fehler bleibt mit derselben Kennung erhalten, auch wenn die Formulierung später verbessert wird. Ergänzt einen Status für nicht mehr relevante Fragen, statt sie aus historischen Berichten zu löschen. So kann ein neuer Kollege nachvollziehen, warum eine Seite existiert und welcher Beleg ihre zentrale Aussage trägt. Die Kennungen sind frei wählbar; entscheidend ist die erhaltene Beziehung zwischen Frage, Claim und Prüfung.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Microsoft: Introducing AI Performance.

14. Quellen und Grenzen des Playbooks

Google beschreibt eigene AI-Suchfunktionen; daraus lässt sich keine identische Funktionsweise anderer Systeme ableiten. Microsoft berichtet über ausgewählte eigene und Partnererfahrungen, nicht über den gesamten Markt. OpenAI beschreibt Zwecke und Steuerung seiner Crawler, nicht eine vollständige Rezeptur für Zitierungen. Diese Grenzen sind Teil des Betriebsmodells. Die Empfehlungen zu klaren Aussagen, kleinen Paketen und Evidenzregistern sind eigene Arbeitsmethoden dieses Leitfadens. Sie sollen Entscheidungen prüfbar machen. Weder ihre konsequente Anwendung noch korrektes Schema-Markup garantiert Indexierung, Ranking, Abruf, Zitierung, Besuche oder Pipeline.

Dokumentation beim Plattformwechsel neu bewerten

Wenn ihr eine weitere Antwortoberfläche aufnehmt, übertragt nicht ungeprüft die Kontrollen der bisherigen Plattform. Erstellt eine kurze Quellenkarte mit Zugriffssteuerung, dokumentiertem Produktumfang und verfügbaren Berichtsdaten. Prüft besonders, ob eine Kennzahl tatsächlich dieselbe Ereignisdefinition verwendet. Ein Microsoft-Bericht und ein manueller ChatGPT-Lauf dürfen parallel im Bericht stehen, sind aber keine addierbaren Teile eines Marktgesamtwerts. Quellen ändern sich; speichert deshalb nicht nur einen Link, sondern auch das Datum der fachlichen Prüfung und die daraus abgeleitete Entscheidung. Eine frühere Aussage bleibt historisch nachvollziehbar, selbst wenn die Plattformbeschreibung später erweitert wird.

Arbeitsblatt

Primärquelle zur fachlichen Einordnung: Google: AI features and your website.

15. Ein vollständiger Wochenauftrag für AI Visibility

Montag: Produktwahrheit vor Auswahl prüfen

Nehmt eine konkrete Frage aus dem bestehenden Kern: Welche Rollen dürfen einen Freigabeexport auslösen? Der Marketingowner öffnet die bisherige Zielseite, der Produktowner bestätigt die aktuelle Berechtigungsregel. Notiert bekannte Tarifunterschiede ausdrücklich. Engineering prüft einen direkten Aufruf ohne Anmeldung. Das erwartete Ergebnis ist eine öffentliche Erklärung der Voraussetzungen, während der eigentliche Kundenvorgang geschützt bleibt. Wenn der Text nur nach dem Login existiert, entscheidet bewusst über eine zusätzliche öffentliche Erklärung. Kopiert keine Kundendaten in die Marketingseite. Schließt den Montag mit einer belegten Aussage und einem klar benannten offenen Punkt ab.

Mittwoch: Eine kleine Änderung veröffentlichen

Die Redaktion ergänzt eine direkte Antwort, die erforderliche Rolle und den Hinweis auf ausgeschlossene Vorgänge. Die Produktprüfung bestätigt diese Sätze einzeln. Der Releasezettel nennt die geänderte URL und beide Sprachen. Prüft anschließend Quelle, Sprachwechsel und sichtbare Bedingungen live. Alte Downloads mit derselben Behauptung bekommen einen eigenen Aktualisierungstask. Die Veröffentlichung wird als eigene Inhaltskorrektur dokumentiert. Weder ein Botbesuch am selben Tag noch eine neue Nennung wird als Beweis ihrer Wirkung behandelt. Wenn eine Rücknahme nötig ist, nennt der Releasezettel die verantwortliche Person und die korrekte Ersatzinformation. Ein Rückfall auf einen nachweislich falschen Claim ist keine geeignete Rücknahme.

Freitag: Beobachten und den nächsten Schritt festlegen

Wiederholt die vorgesehenen Fragen unter den dokumentierten Bedingungen. Für jeden gültigen Lauf erfasst ihr Nennung, Linkziel und richtige Wiedergabe der Rollenbedingung. Zeigt auch Läufe ohne eigene Quelle. Der Wochenabschluss besteht aus drei getrennten Sätzen: Was an eigenen Seiten korrigiert wurde, was in fremden Antworten beobachtet wurde und welche geschäftlichen Daten tatsächlich vorliegen. Bleibt die Stichprobe klein, bleibt auch die Aussage klein. Die nächste Woche kann eine weitere Käuferhürde bearbeiten oder zunächst bestehende Fehler nachprüfen. Eine Erweiterung braucht einen Grund jenseits einer attraktiven Bildschirmaufnahme. Damit entsteht ein wiederholbarer Arbeitsauftrag, der auch bei wechselnder externer Auswahl fachlich nützlich bleibt.

Verifizierte Quellen

Die folgenden offiziellen URLs wurden am 24. Oktober 2026 redaktionell geprüft. Prüft die aktuelle Fassung vor Implementierungsänderungen.

• Google: AI features and your website
• OpenAI: Overview of crawlers
• Microsoft: Introducing AI Performance
• Google: robots.txt
• Google: Block indexing with noindex
• Google: Structured data policies
• Google: Helpful, reliable content
• Google Analytics: Traffic acquisition
• Google Analytics: Attribution