Ehrlicher Maßstab
Methodik
Jede Zahl auf dieser Seite wird beim Erstellen der Seite aus dem Quellcode von Sonar oder aus einer datierten Nachweisdatei gelesen. Keine davon ist von Hand eingetippt, und jeder Abschnitt nennt die Dateien, aus denen seine Zahlen stammen.
Jede Zahl auf dieser Seite wird beim Laden berechnet, aus dem Code, der Sonar ausführt, und aus seinen aufgezeichneten Testläufen – sie kann also nicht vom Produkt abweichen.
Was wir messen, je Engine
SEO stammt aus Ihren eigenen Google-Search-Console-Daten und ist deterministisch: Dieselben Daten ergeben denselben Score. Die letzten 28 Tage werden mit den 28 Tagen davor verglichen. Das Intervall (80 %) zeigt die Schwankung von Woche zu Woche in Blöcken von 7 Tagen, denn Search-Console-Daten sind eine Vollerhebung, keine Stichprobe.
Die AEO-Bereitschaft stammt aus deterministischen Checks des HTML und der HTTP-Antworten Ihrer Seiten, ohne Sprachmodell und ohne Bewertungsschema. Jeder fehlgeschlagene Check enthält einen Nachweis, den Sie anfechten können.
Der GEO-Zitieranteil gibt an, wie oft eine KI-Engine Ihre Domain für eine feste Menge von Prompts unter ihren Quellen aufführt. Jede der 6 Engines und jede Sprache wird für sich ausgewiesen und nie mit den anderen gemittelt.
Die drei Scores werden nie zu einer Zahl verschmolzen. Der Datentyp, der sie enthält, hat kein Feld für einen Gesamtscore, und ein Test schlägt fehl, sobald jemand eines hinzufügt.
Panelgröße und Rhythmus
- Prompts
- 30 (20 Kategorie, 10 Marke)
- KI-Engines
- 6
- Sprachen
- 2, immer unterschiedliche Sprachen
- Durchläufe je Prompt
- 2
- Antworten je Engine und Sprache
- 60
- Rhythmus
- Wöchentlich
Die Sprache einer Frage und die Auswahl der Prompts bewegen KI-Zitate weit stärker als dieselbe Frage erneut zu stellen. 2 Durchläufe je Prompt sind das Minimum, mit dem sich das Rauschen zwischen Durchläufen noch schätzen lässt; tägliche Läufe würden die Kosten vervielfachen, ohne das Intervall zu verengen. Der Preis dafür ist ausdrücklich: Eine Änderung bei Zitaten wird nie in weniger als einer Woche erkannt.
60 Antworten je Engine und Sprache ergeben breite Intervalle, oft zu breit, um zwei nahe beieinanderliegende Anteile zu unterscheiden. Sonar zeigt diese Breite, statt sie zu verstecken.
Wie Intervalle berechnet werden
Intervalle stammen aus einem Cluster-Bootstrap. Neu gezogen wird ein Prompt-Cluster, mit Zurücklegen und mitsamt all seinen Durchläufen. Prompts zum selben Thema steigen und fallen gemeinsam; jede Antwort als unabhängig zu behandeln, ließe Intervalle schmaler erscheinen, als sie sind.
Jedes Intervall verwendet 2.000 Bootstrap-Replikate auf einem Niveau von 95 %, mit der Perzentilmethode „expanded“. Sie wurde gewählt, weil ihre Überdeckung in der Simulation unter den getesteten Methoden am nächsten am Nominalwert lag.
Eine GEO-Zahl gilt nur dann als gemessen, wenn jeder Prompt mindestens 2-mal lief und es mehr als ein Prompt-Cluster zum Neuziehen gibt. Andernfalls wird sie als indikativ gekennzeichnet, mit ihrer Stichprobengröße, und ein einzelnes Cluster erhält das breitestmögliche Intervall.
Zufalls-Seeds werden aus Engine und Sprache abgeleitet, sodass dieselben Daten immer dasselbe Intervall ergeben.
Holdout-Design: warum Vorher/Nachher kein Beweis ist
Traffic bewegt sich aus Gründen, die nichts mit einer Änderung zu tun haben: Saison, Feiertage, Suchmaschinen-Updates, der Launch eines Wettbewerbers. Ein Vorher/Nachher-Vergleich mischt all das ins Ergebnis. Deshalb vergleicht jede Wirkungsaussage von Sonar die geänderten Seiten mit einem Holdout ähnlicher Seiten, die nie angefasst wurden, an denselben Tagen.
Mindestens 10 % der URLs und mindestens 10 % der Prompt-Cluster werden zurückgehalten. Die Zugehörigkeit entscheidet ein schlüsselbasierter Hash, kein Ranking, sodass neue Seiten bestehende Mitglieder nie neu mischen. Holdout-Mitglieder werden nie entfernt oder ausgemustert.
Seiten werden nach Suchanfragen-Clustern randomisiert, nicht einzeln: Seiten mit gemeinsamen Top-Anfragen werden gemeinsam zugeteilt, sodass eine Änderung auf einer Seite einer Kontrollseite keine Klicks wegnehmen kann. Ein Experiment startet nur, wenn das größte Cluster höchstens 30 % der Klicks hält und mindestens 10 Cluster Klicks haben.
Der Schätzer ist Difference-in-Differences mit wöchentlichem Saisonmodell und Moving-Block-Bootstrap (Blöcke von 7 Tagen, 2.000 Replikate). Eine Poisson-Untergrenze verhindert, dass Websites mit wenig Traffic fälschlich schmale Intervalle erhalten. Er braucht 70 Tage Verlauf vor der Änderung und eine Auswertung über 28 Tage danach.
GOOD verlangt eine Gewinnwahrscheinlichkeit von mindestens 95 % und eine überschrittene sequenzielle Grenze; BAD verlangt eine Schadenswahrscheinlichkeit von mindestens 90 %; NEUTRAL verlangt, dass mindestens 80 % der Wahrscheinlichkeit innerhalb von ±3 % liegen, dem kleinsten Zuwachs, der sich zu pflegen lohnt. Die sequenzielle Grenze verbraucht ein Fehlerbudget von 5 % je Richtung, sodass tägliches Prüfen keine zusätzlichen Fehlalarme erzeugt. Alles andere bleibt RUNNING oder endet als UNDERPOWERED, grau dargestellt und nie grün.
Ohne Holdout verweigert der Wirkungsbericht die Anzeige. Er wird nicht durch eine Vorher/Nachher-Zahl ersetzt.
Ergebnisse der A/A-Tests
Ein A/A-Test ändert nichts, daher ist jedes GOOD- oder BAD-Urteil daraus ein Fehlalarm. Die komplette Urteils-Pipeline, derselbe Code, der echte Experimente bewertet, lief auf simulierten Websites, deren Aufteilung und Rauschen an einer echten Website kalibriert wurden.
0 falsche Urteile in 100 A/A-Läufen über 5 Traffic-Stufen.
| Klicks pro Tag | A/A: falsches GOOD oder BAD | Echter Zuwachs von 20 % als GOOD erkannt | Echter Rückgang von 10 % als BAD erkannt | Gemessener MDE |
|---|---|---|---|---|
| 1,2 | 0 von 20 | 0 von 20 | 0 von 20 | 117 % |
| 8,4 | 0 von 20 | 0 von 20 | 0 von 20 | 49 % |
| 22 | 0 von 20 | 3 von 20 | 1 von 20 | 30 % |
| 50 | 0 von 20 | 4 von 20 | 3 von 20 | 21 % |
| 150 | 0 von 20 | 14 von 20 | 2 von 20 | 13 % |
Die Tabelle zeigt auch den unbequemen Teil: Bei wenig Traffic wird selbst ein echter Zuwachs selten erkannt, weil ein GOOD-Urteil mehr Sicherheit verlangt, als die Lehrbuchformel für den MDE annimmt. Deshalb zeigt Sonar Ihren MDE, bevor ein Experiment beginnt, und deshalb hängt, was es verkauft, an der gemessenen Teststärke.
Das sind Simulationen, aufgezeichnet am 24. September 2026. Ein A/A-Test auf einer echten Traffic-Reihe braucht 98 Tage endgültige Daten, und die Labor-Website hatte damals 69. Seit dem 20. Oktober 2026 gibt es genug endgültige Daten, aber das Ergebnis auf der echten Reihe ist noch nicht veröffentlicht – die Tabelle oben bleibt simuliert.
Minimal nachweisbarer Effekt nach Traffic-Stufe
Der minimal nachweisbare Effekt (MDE) ist der kleinste Zuwachs, den ein Experiment vom Rauschen unterscheiden kann, bei einem zweiseitigen Signifikanzniveau von 5 % und einer Teststärke von 80 %. Sonar berechnet ihn für Ihre Website, bevor ein Experiment beginnt.
Eine Wirkungsaussage wird nur verkauft, wenn der gemessene MDE höchstens 12 % beträgt. Zwischen 12 % und 25 % werden Ergebnisse als indikativ gezeigt. Über 25 % wird gar keine Wirkungsaussage getroffen.
| Klicks pro Tag | Planungs-MDE | Was Sonar behaupten darf |
|---|---|---|
| 1,2 | 322 % | Keine Wirkungsaussage |
| 8,4 | 122 % | Keine Wirkungsaussage |
| 22 | 75 % | Keine Wirkungsaussage |
| 50 | 50 % | Keine Wirkungsaussage |
| 150 | 29 % | Keine Wirkungsaussage |
| 200 | 25 % | Nur indikativ |
| 866 | 12 % | Wirkungsaussage |
Planungswerte nehmen unabhängige Tage, eine vorsichtige Überdispersion und den minimalen Holdout an. Maßgeblich ist der Wert, der auf Ihren eigenen Daten mit dem Block-Bootstrap gemessen wird. In den A/A-Läufen oben fiel er kleiner aus als der Planungswert, auf einer anderen Website kann er aber größer ausfallen.
MDE-Rechner
Dieselbe Funktion wie in der Tabelle oben, mit Überdispersion 4. Ändern Sie die Eingaben, um zu sehen, wie viel Traffic ein auswertbares Experiment braucht.
Was wir nicht behaupten
Manche Zahlen würden sich besser verkaufen. Sonar zeigt sie nicht.
- Einen einzigen kombinierten Sichtbarkeitsscore. SEO, AEO und GEO bleiben drei getrennte Zahlen.
- Wirkung aus einem Vorher/Nachher-Vergleich. Vorher/Nachher-Diagramme tragen den Hinweis „kein Wirkungsnachweis“.
- Eine GEO-Zahl ohne ihr Intervall oder die Kennzeichnung gemessen für Daten, die nur indikativ sind.
- Eine Wirkungsaussage für eine Website, deren MDE über 25 % liegt.
- Einen Trend über einen Versionswechsel des KI-Modells hinweg. Eine neue Modellversion beginnt eine neue Reihe.
- Zusammengefasste Ergebnisse anderer Kunden, bevor mindestens 3 verschiedene Kunden und 3 unabhängige Cluster beitragen.
- Bewertungen, Rezensionen, Preise oder Referenzen, die es nicht gibt.
Sicherheitskreislauf
Sonar schreibt auf Live-Websites, daher ist jeder Schreibvorgang begrenzt, geprüft und umkehrbar.
- Live-Prüfung
- 2 Minuten nach dem Veröffentlichen ruft Sonar die Live-Seite ab und prüft, ob jede Änderung tatsächlich ausgeliefert wird. Falls nicht, prüft Sonar nach 28 Minuten noch einmal. Eine fehlgeschlagene Prüfung wird protokolliert und gemeldet, nie verborgen.
- Rücknahme
- Jede Änderung wird mit ihrem vorherigen Zustand gespeichert und kann in der App zurückgenommen werden. Experimente werden in Ringen von 10 %, 30 % und 100 % der geeigneten Seiten ausgeweitet, und ein BAD-Urteil nimmt die Änderung zurück.
- Notschalter
- Ein Schalter stoppt jeden Schreibvorgang für einen ganzen Workspace oder eine einzelne Website und pausiert live geschaltete Edge-Änderungen, sodass die Website auf ihre Originalseiten zurückfällt. Er wird vor jedem Schreibvorgang geprüft.
- Tempolimits
- Limits zählen gleitende Zeitfenster, keine Kalendertage, sodass sich Arbeit nicht um Mitternacht bündeln lässt.
- Neue Artikel auf einer Kunden-Website: höchstens 3 je gleitende 24 Stunden
- Technische Korrekturen je Website und Tag, standardmäßig: höchstens 3
- Inhaltsentwürfe je Website und Tag, standardmäßig: höchstens 1
- Holdout-Seiten
- Werden nie bearbeitet. Der Executor stoppt, wenn eine Änderung eine davon berühren würde.
Verbindungen und was jede ändern kann
Wie Sonar Korrekturen anwendet, hängt davon ab, wie Ihre Website verbunden ist. Die Tabelle wird aus dem erzeugt, was jede Verbindung heute tatsächlich unterstützt.
| Hebel | Edge (Cloudflare) | WordPress | GitHub | Shopify | Webflow | Contentful | Sanity | Strapi | Wix | Squarespace | HubSpot |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Seitentitel und Meta-Beschreibungen | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja |
| Antwortblöcke, FAQ und VergleichstabellenB-01 · B-18 · B-14 | Ja | Teilweise | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Strukturierte FAQ-DatenA-21 | Ja | Ja | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Neue SeitenB-15 | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Abschnitte bestehender Artikel auffrischenB-10 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| robots.txt, llms.txt und IndexNow-SchlüsselA-01 | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Technische Korrekturen (Bild-Alt, Social-Tags, hreflang, Weiterleitungen)A-06 · A-08 · A-16 · B-19 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Canonical-TagsA-07 | Ja | Nein | Nein | Nein | Nein | Teilweise | Teilweise | Teilweise | Ja | Nein | Ja |
| Korrekturen für ganze TemplatesB-31 · B-30 · A-07 · A-16 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| SammlungsseitenB-15 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Lokalisierte Titel und Beschreibungen im StapelB-22 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Verwandte Links zwischen SeitenB-21 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Bild- und Video-Sitemaps, EntitätslinksH-10 · A-16 · H-15 · D-01 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Konsolidierung (noindex für dünne Seiten)B-11 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Geschwindigkeit (HTML-Cache, Preload)A-26 · A-13 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Agent-Bereitschaft (Markdown, Feeds, Richtlinien)F-11 · F-16 · F-17 | Ja | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein | Nein |
| Vollständig verfügbar | 16 von 16 | 4 von 16 | 3 von 16 | 3 von 16 | 1 von 16 | 1 von 16 | 1 von 16 | 1 von 16 | 2 von 16 | 1 von 16 | 2 von 16 |
- Edge (Cloudflare): die größte Auswahl an Korrekturen, angewendet vor Ihrer Website. Funktioniert für jede Domain: Leiten Sie einen Hostnamen per CNAME bei Ihrem DNS-Anbieter auf Sonar um.
- WordPress: das Sonar-Plugin plus ein Anwendungspasswort. Titel, Beschreibungen, FAQ-Abschnitte und neue Seiten.
- GitHub: Sonar öffnet Pull Requests in Ihrem Repository, für Websites, die aus Dateien erzeugt werden.
- Shopify: eine benutzerdefinierte App in Ihrem Shop. Meta-Tags und Blöcke auf der Seite.
- Webflow: ein API-Token. Nur Seitentitel und Beschreibungen.
- Contentful, Sanity, Strapi (Feldzuordnung pro Inhaltstyp), Wix, Squarespace und HubSpot: ein API-Token. Titel und Beschreibungen, dazu Canonical, wo die API das Feld hat; alles andere geht in den Exportmodus.
Was Sie brauchen
- Google Search Console: Fügen Sie das im Einrichtungsassistenten angezeigte Dienstkonto von Sonar als eingeschränkten Nutzer Ihrer Property hinzu.
- Bing Webmaster Tools: Bitten Sie den Sonar-Inhaber, Ihre Website zum Bing-Konto des Teams hinzuzufügen.
- Edge-Verbindung: Zugriff auf Ihre DNS-Einstellungen, um einen CNAME-Eintrag hinzuzufügen (beliebiger DNS-Anbieter). Können Sie den DNS nicht ändern, verwenden Sie stattdessen WordPress, Shopify, Webflow oder GitHub.
- Eine Authenticator-App für den zweiten Faktor, erforderlich zum Verbinden einer Website.
- Mindestens zwei Inhaltssprachen für das Unternehmen, wenn Sie das GEO-Zitier-Panel nutzen möchten.