Die Plattformregel, die lautlos verschwand
Der Satz hatte drei Review-Runden überlebt. Er stand in der Projektspezifikation, er war das Akzeptanzkriterium eines Tickets, er war eine der Freigabe-Voraussetzungen, die ich für den ersten Werbe-Euro formuliert hatte, und er stand im Entwurf einer Nachricht an den Entwickler eines Kunden, als Arbeitsauftrag.
Er sagte, wir bräuchten einen DNS-Eintrag für die Landingpage-Domain, weil Meta eine Domain-Verifizierung verlangt, bevor man Web-Conversion-Events konfigurieren kann.
Meta verlangt das nicht. Für Web-Events ist die Anforderung irgendwann entfallen, bevor ich einen dieser vier Sätze geschrieben habe.
Was auf der Hilfeseite wirklich steht
Aufgefallen ist es mir nur, weil ich mich auf ein Gespräch mit Metas Pro Team vorbereitet habe und meine Fragen präzise haben wollte. Die Recherche hatte mir längst eine selbstbewusste Antwort geliefert, zusammengesetzt aus einer Suchzusammenfassung: acht priorisierte Conversion-Events pro Domain, Wertegruppen für die Wertoptimierung, Domain-Verifizierung als Vorbedingung. Klassische Aggregated Event Measurement, also das Konstrukt, das Meta nach Apples App Tracking Transparency gebaut hat.
Dann habe ich die Hilfeseite selbst im Browser geöffnet. Im zugeklappten Abschnitt zu Website-Events schreibt Meta (Meta-Hilfebereich für Unternehmen, gelesen am 4. Oktober 2026):
Für die Optimierung der Web-Conversions musst du keine acht Conversion-Events mehr pro Domain priorisieren.
Und:
Der Tab „Messung aggregierter Events" im Meta Events Manager wurde entfernt, da du keine Web-Events mehr konfigurieren musst.
Und der Punkt, der die Arbeitslast meines Kunden betraf:
Du bist nicht verpflichtet, deine Website-Domains im Zusammenhang mit der Event-Konfiguration zu verifizieren.
Vier Aufzählungspunkte, von denen jeder etwas wegnimmt, das meine Spezifikation als harte Anforderung führte. Beim dritten lohnt sich der genaue Blick darauf, was dort steht und was nicht: Eine Domain-Verifizierung kann weiter nötig sein, aus Gründen, welche die Seite selbst nicht aufzählt, sondern auf einen eigenen Artikel verlinkt. Das ist ein anderes Argument als das, mit dem ich gearbeitet hatte, und es ist das, mit dem ich von Anfang an hätte arbeiten sollen.
Der Teil, der das Versagen erklärt
Interessanter als mein eigener Fehler ist das Folgende: Diese Änderung hat kein Datum.
Die Seite sagt, Meta führe die Änderungen „nach und nach" ein und das neue Verhalten gelte, „wenn du Zugriff darauf hast". Kein Stichtag, kein Deprecation-Hinweis, keine Migrationsfrist. Der alte Konfigurations-Tab wurde nicht als veraltet markiert, er wurde entfernt. Ein gestaffelter Rollout ohne angekündigtes Datum ist von außen praktisch unsichtbar.
Das ist deshalb entscheidend, weil Suchranking nach Verlinkung funktioniert. Verlinkt wird zu Plattformanforderungen vor allem Agentur-Content, Implementierungs-Leitfäden und Konferenzvorträge, und die sind alle in den Jahren entstanden, in denen die Anforderung echt war. Es gab nie eine datierte Ankündigung, auf die irgendeiner dieser Texte hätte reagieren können. Also beschreibt der Korpus weiterhin eine Welt mit acht priorisierten Events, und die Zusammenfassung, die ich bekommen habe, war eine korrekte Aggregation dieses Korpus. Sie war nicht halluziniert. Sie war gut belegt, und sie war zutreffend für die Jahre, in denen die Anforderung galt.
Die lebende Seite widerspricht dem allen, und zwar in einem zugeklappten Akkordeon, das eine reine Textextraktion nicht zurückgibt. Ich musste die Überschrift erst aufklicken, damit der Text überhaupt existierte.
Was es gekostet hat und was es fast gekostet hätte
Gekostet hat es nichts, weil ich es vor dem Versenden gefangen habe. Lehrreicher ist, was es fast gekostet hätte. Ich hätte den technischen Verantwortlichen eines Kunden gebeten, einen DNS-Eintrag für eine Anforderung zu setzen, die es nicht mehr gibt. Der Eintrag wäre gesetzt worden, weil ich derjenige bin, der das wissen soll. Der Aufwand wäre klein gewesen und vollständig vergeudet, und zwar in der einen Richtung, aus der man nicht zurückkommt: der eigenen Glaubwürdigkeit in genau der Sache, für die man geholt wurde.
Die Korrektur lief stattdessen in die andere Richtung: Eine Anforderung fiel von der Liste des Kunden weg. Das ist ein deutlich besseres Gespräch als das, in dem man etwas hinzufügt.
Die Regel, die ich jetzt anwende
Was als Fakt in ein Kundendokument, eine Spezifikation oder ein Ticket einzieht, wird vorher an der Originalquelle gelesen, einschließlich der Abschnitte, die man aufklappen muss. Was nur aus einer Zusammenfassung stammt, wird als Frage formuliert, nicht als Befund.
Das kostet beim Schreiben einen halben Satz. Aus „Meta verlangt eine Domain-Verifizierung" wird „verlangt Meta noch eine Domain-Verifizierung, an der Quelle zu prüfen". Die zweite Fassung ist ehrlich über den eigenen Wissensstand, und sie erzeugt für niemanden Arbeit, solange sie nicht bestätigt ist.
Suchen ist weiterhin der richtige Weg, um die maßgebliche Seite zu finden. Es ist kein Weg, sie zu lesen.
Eine Fußnote zum selben Fehler, vier Wochen später
Ich habe diese Regel damals als Lehre notiert. Vier Wochen später, beim Abschluss desselben Projekts, habe ich für eine Werkzeug-Änderung argumentiert und als Hauptbeleg eine Datei angeführt, von der ich mich erinnerte, sie geschrieben zu haben. Die Datei existierte nicht. Ich hatte sie aus der Erinnerung rekonstruiert, detailliert genug, um ein Datum mitzuliefern.
Gleiches Versagen, andere Oberfläche: eine selbstbewusste Behauptung, keine Primärquelle, und eine, die zufällig genau das stützte, was ich ohnehin tun wollte. Die Disziplin heißt nicht „Suchzusammenfassungen misstrauen". Sie ist enger und unangenehmer: Prüfe die Sache selbst, bevor du sie tragen lässt, auch dann, wenn die Sache die eigene Erinnerung ist, und besonders dann, wenn sie dir zustimmt.