GEO-Audit

GEO (Generative Engine Optimization) ist die Disziplin, eine Website so zu bauen, dass KI-Engines — ChatGPT, Claude, Perplexity, Gemini und Googles AI Overviews — sie leicht crawlen, verstehen und zitieren können. Das GEO-Audit findest du unter KI-Sichtbarkeit → GEO-Audit. Es ruft die Website eines Kunden genau so ab, wie diese Engines es tun (ein einfacher HTTP-Request ohne JavaScript-Ausführung — exakt die Art, wie die großen KI-Crawler abrufen), und bewertet konkrete, überprüfbare Signale zu einem einzelnen Bereitschafts-Score von 0–100. Wichtig: Gemessen wird die Bereitschaft — ob eine Website so aufgestellt ist, dass sie zitiert werden kann — und nicht der tatsächliche Zitationsanteil. Wie oft eine Marke in KI-Antworten wirklich genannt wird, wird getrennt davon im Tab Sichtbarkeit verfolgt. Diese Unterscheidung halten wir bewusst explizit, damit der Score nie mehr verspricht, als er misst.

Der Gesamtscore gewichtet fünf Kategorien. Zugang für KI-Crawler (30): ob deine robots.txt die Crawler, die Live-KI-Antworten speisen — OpenAIs OAI-SearchBot und ChatGPT-User, Anthropics Claude-User und Claude-SearchBot, PerplexityBot, Googlebot und Google-Extended — überhaupt auf die Website lässt. Zugänglichkeit der Inhalte / SSR (30): ob der Hauptinhalt der Seite im rohen HTML steht statt per JavaScript nachgeladen zu werden, denn KI-Crawler führen kein JS aus. Diese Kategorie trägt zusätzlich eine informative Content-Delta-Prüfung: Die geprüften Seiten werden einmal als KI-Agent und einmal als normaler Browser abgerufen, und ein wesentlicher Unterschied wird markiert — bekommt der Bot weniger, unterschätzen die Audit-Befunde womöglich, was Menschen sehen; bekommt er mehr oder anderes, ist das ein Cloaking-Risiko. Auf den Score wirkt sie nie. Strukturierte Daten (20): gültiges schema.org-JSON-LD, das deine Marke als bekannte Entität verankert — vor allem ein Organization-Block mit sameAs-Links, dazu Unterstützung für antwortfreundlichere Typen wie FAQPage, Article, Product, HowTo und QAPage. Das Audit erkennt diese Typen nicht nur, sondern prüft auch, ob ein vorhandener Typ die erforderlichen Eigenschaften wirklich mitbringt (eine FAQPage braucht Fragen mit akzeptierten Antworten, ein Article braucht headline/author/datePublished, ein Product braucht offers, ein HowTo braucht steps); ein vorhandener, aber unvollständiger Typ wird als teilweise erfüllt markiert — mit den exakt fehlenden Eigenschaften — statt voll zu bestehen. Technische SEO-Hygiene (15): Sitemap, selbstreferenzierendes Canonical, genau ein H1, ein sinnvoller Title und eine Meta-Description sowie HTTPS. llms.txt (5): Vorhandensein und grundlegende Gültigkeit einer /llms.txt — eine vorausschauende Konvention, bewusst am niedrigsten gewichtet: Googles offizielle Anleitung zur generativen KI besagt, dass Google llms.txt ignoriert, und keine Antwort-Engine hat bestätigt, sie für Zitate zu nutzen. Sie zählt daher als günstige, maschinenlesbare Hygiene und nie als Google-/Such-Ranking- oder Zitationsfaktor. Jede Prüfung wird als bestanden, teilweise erfüllt oder nicht bestanden bewertet, mit einer verständlichen Erklärung, was gefunden wurde und warum es zählt. Das Ergebnis ist damit eine Aufgabenliste und nicht bloß eine Zahl.

Innerhalb der Content-Bewertung prüft das GEO-Audit drei Schreibsignale, für die peer-reviewte Forschung gezeigt hat, dass sie die Wahrscheinlichkeit erhöhen, von generativen Engines zitiert zu werden: direkte Zitate, belegte Statistiken und Verweise auf autoritative externe Quellen. Sie stammen aus der KDD'24-Arbeit „GEO: Generative Engine Optimization“ (Aggarwal et al., Princeton / IIT Delhi), die gemessen hat, dass Zitate, Statistiken, genannte Quellen und flüssige Sprache die Sichtbarkeit einer Seite in KI-Antworten jeweils um rund ein Viertel steigern. Jede Prüfung wird als bestanden/teilweise/nicht bestanden mit einer verständlichen Notiz bewertet, und das Audit kennzeichnet sie als forschungsbelegt — damit du weißt, dass die Empfehlung kein Bauchgefühl ist. Das Audit bewertet außerdem die extrahierbare Struktur — ob eine Seite ihre Inhalte in Aufzählungs- oder nummerierte Listen und Datentabellen gliedert, die KI-Antwort-Engines nahezu wortgleich übernehmen; strukturierter Inhalt ist dadurch deutlich zitierfähiger als ein Textblock. Das wird fair bewertet (eine textlastige Seite wird zu mehr Struktur angestupst, nie deswegen durchfallen gelassen) und stützt sich auf Forschung von 2026 dazu, wie Content-Struktur die KI-Zitierung prägt („Structural Feature Engineering for GEO“, arXiv 2603.29979). Dieselbe Forschung hat auch gezeigt, was nicht funktioniert: Keyword-Stuffing war die mit Abstand schlechteste Taktik und hat die KI-Sichtbarkeit aktiv gesenkt. Deshalb behandelt das Audit Keyword-Stuffing als negatives Signal — es bringt nie Punkte, und eine Seite mit zu hoher Keyword-Dichte (grob über 6 %, mit einem erhöhten Bereich zwischen 4 und 6 %) wird als zu behebendes Problem markiert, nicht als Häkchen zum Abhaken. Nichts in der Content-Bewertung belohnt jemals Keyword-Dichte; sie bestraft ausschließlich Stuffing.

Eine robots.txt-Regel, die „erlaubt“ sagt, hilft nur, wenn der Crawler die Seite auch tatsächlich erreicht. Viele Websites geben KI-Bots in der robots.txt frei, sitzen dann aber hinter einer WAF oder einem CDN — der Schalter „Block AI bots“ bei Cloudflare ist der Klassiker — die genau diese Crawler an der Edge stillschweigend abweist. Für dich und den Website-Betreiber sieht alles gut aus; für die KI-Engine ist die Website unsichtbar. Das GEO-Audit führt deshalb neben der robots.txt-Prüfung auch einen echten Erreichbarkeitstest durch: Es ruft die Seite ab und gibt sich dabei als jeder einzelne KI-Crawler aus, und meldet, ob der Request wirklich durchkam. Das ist standardmäßig rein informativ — eine Warnung gibt es nur, wenn eine Sperre zweifelsfrei bestätigt ist, damit dich normales Rate-Limiting oder ein kurzzeitiger Fehler nicht in Alarm versetzt. Wird eine echte Edge-Sperre erkannt, nennt das Audit den abgewiesenen Crawler beim Namen, sodass du damit direkt zum Hosting- oder Security-Team des Kunden gehen kannst. Die Lehre daraus: „In der robots.txt erlaubt“ und „in der Praxis erreichbar“ sind zwei verschiedene Dinge, und KI-Sichtbarkeit braucht beides. Du siehst das an zwei konkreten Stellen. Im GEO-Audit legt eine Karte „Firewall & access policy“ es Crawler für Crawler offen — was die robots.txt sagt, neben dem, was der Live-Test gefunden hat, mit einem klaren Urteil pro Zeile. „Firewall blocks“ ist das, worauf du reagieren solltest: Die robots.txt erlaubt den Crawler, die Edge blockiert ihn trotzdem. Sie deckt die fünf Crawler ab, denen sich eine Blockade zuordnen lässt (OAI-SearchBot und ChatGPT-User von ChatGPT, PerplexityBot, ClaudeBot, Googlebot), und wandert mit in den Bericht, in geteilte Links und ins PDF. Und wenn du die Aufnahme der Crawl-Logs eingerichtet hast, meldet die Crawl-Insights-Seite eine WAF-Blockade-Warnung — gespiegelt von einem Signal in deinem Posteingang —, sobald echter KI-Crawler-Traffic mit HTTP 403/406 zurückkommt. So erwischst du eine Edge-Sperre auf zwei Wegen: aus einem punktuellen Audit und aus dem Live-Traffic dazwischen. Ein weiteres robots.txt-Signal lohnt einen Blick: Eine Karte „Content-Nutzungsrichtlinie“ erscheint, wenn deine Website Cloudflares Content-Signal-Direktive veröffentlicht (search / ai-input / ai-train = yes/no). Das ist ein Präferenzsignal, keine erzwungene Kontrolle — keine Antwort-Engine berücksichtigt es bestätigt und Google ignoriert es nach eigener Aussage, es beeinflusst deinen GEO-Score also nie und ändert für sich genommen nicht, ob du zitiert wirst. Wir zeigen es aus einem Grund: Cloudflare hat Standardwerte automatisch in Millionen verwalteter robots.txt-Dateien eingetragen, deine Website sendet also womöglich ai-input=no — die Bitte an KI-Engines, deine Inhalte nicht als Live-Input für Antworten zu nutzen —, ohne dass das jemand gewählt hat. Wenn du KI-Sichtbarkeit anstrebst, ist das das Gegenteil von dem, was du willst; die Karte weist darauf hin (und erkennt, wenn es wie Cloudflares Standard aussieht), damit du ai-input=yes setzen oder die Zeile entfernen kannst. Sie ist außerdem als Bericht-Dimension „Content usage policy“ verfügbar. (ai-train=no ist ein legitimer Trainings-Opt-out ohne Wirkung auf Live-Antwort-Zitationen — die Karte sagt das und markiert es nie.)

Öffne das KI-Sichtbarkeits-Projekt eines Kunden, geh auf GEO-Audit — die Domain ist bereits aus der gespeicherten Website des Kunden vorbelegt. Klick auf „Audit starten“, und CrunchJunkie prüft robots.txt, llms.txt, die Sitemap und eine repräsentative Auswahl an Seiten — die Startseite plus eine Seite pro Website-Bereich, bevorzugt tiefere Seiten, sodass Blogartikel und Produktseiten mitbewertet werden, nicht nur die oberste Ebene. On-Page-Ergebnisse werden ehrlich über die Auswahl aggregiert („3/6 geprüfte Seiten bestehen“), und der Bereich „Ergebnisse pro Seite“ schlüsselt dieselben Checks Seite für Seite auf — ein gemischtes Ergebnis ist damit immer auf die konkrete Seite zurückführbar. Jeder Durchlauf wird gespeichert, du kannst also nach Änderungen erneut auditieren und zusehen, wie sich der Score bewegt — der Verlauf zeigt jeden Snapshot mit Datum. Das Audit läuft außerdem automatisch — standardmäßig wöchentlich, denn On-Site-Signale ändern sich langsam und jedes Audit liest Seiten der Kunden-Website. In den Projekt-Einstellungen kannst du auf tägliche Audits umstellen; ein manuelles „Audit starten“ ist immer möglich. Automatische Läufe sind reine Seitenabrufe ohne KI-Checks und kosten daher nie etwas. Weil das Audit nur On-Site-Signale betrachtet, sieht es Off-Site-Faktoren nicht, die ebenfalls auf die KI-Sichtbarkeit einzahlen (Markenerwähnungen im Netz, Präsenz auf Reddit oder Wikipedia) — und auch nicht, ob ein Modell auf deinen Inhalten trainiert wurde. Lies einen hohen Score als „diese Website ist gut aufgestellt, um zitiert zu werden“, und schau parallel in den Tab Sichtbarkeit, ob sich diese Aufstellung in echte KI-Erwähnungen übersetzt.

KI-Crawler holen eine Seite mit einem einfachen HTTP-Request und führen kein JavaScript aus — alles, was eine Website erst im Browser nach dem Laden zeichnet, ist für sie unsichtbar. Genau das prüft das Audit. Der SSR-Check misst, wie viel echter Inhalt im initialen HTML steckt — die Wörter, die im rohen <body> stehen, bevor irgendein JavaScript läuft — und besteht bei einer nennenswerten Menge, meldet teilweise erfüllt bei wenig Inhalt und fällt bei einer leeren Hülle durch. Der Client-Side-Only-Check sucht nach den Fingerabdrücken eines Single-Page-App-Frameworks (React, Next.js, Vue, Nuxt, Angular, Svelte und andere) über einem nahezu leeren initialen Body — das klassische Muster einer Website, die für Menschen einwandfrei rendert und einem Crawler fast nichts zurückgibt. Serverseitig gerendert zu sein ist allerdings nur die halbe Maschinenlesbarkeit — die Seite muss dem Crawler auch erlauben, den Hauptinhalt von Navigation, Header und Footer zu unterscheiden. Das Audit prüft auf ein semantisches Hauptinhalts-Landmark (ein <main>- oder <article>-Element oder role="main"): Mit einem kann ein Crawler den zitierwürdigen Inhalt in einem Schritt isolieren; ohne eines zwingt eine Seite aus lauter generischen <div>s die Engine zu raten, welcher Block die Antwort ist. Es ist ein sanfter Hinweis, nie ein hartes Durchfallen, mit dem Fix, den Hauptinhalt in <main> zu fassen. Außerdem prüft das Audit auf ein robots-Meta-Tag mit noindex: Trägt eine Seite <meta name="robots" content="noindex">, sagt sie Such- und KI-Antwortmaschinen, dass sie ganz draußen bleiben sollen — das wird mit dem exakten Fix benannt. Zusammen fangen diese Prüfungen die technischen Gründe ab, aus denen eine im Browser perfekt aussehende Seite für KI trotzdem praktisch unsichtbar sein kann.

Neben dem GEO-Gesamtscore erzeugt jedes Audit inzwischen einen separaten Sub-Score „Agent-Bereitschaft“ von 0 bis 100. Wo es beim GEO-Score ums Gecrawlt- und Zitiertwerden geht, geht es bei der Agent-Bereitschaft um die neuere Klasse von KI-Agenten — die Echtzeit-Assistenten, die Inhalte abrufen und Tools aufrufen, um im Auftrag eines Nutzers live zu handeln. Bewertet werden drei konkrete, beeinflussbare Signale: ob die robots.txt die User-Agents dieser Echtzeit-Agenten durchlässt (ChatGPT-User, Claude-User, Perplexity-User, Gemini Deep Research und ähnliche), ob deine Inhalte ohne JavaScript lesbar sind (Agenten holen rohes HTML und führen meist kein JS aus) und wie breit deine strukturierten Daten aufgestellt sind (wie viele verschiedene schema.org-Typen ein Agent bei dir auswerten kann). Zu jedem dieser Punkte gibt es den Button „Fix mit Crunch entwerfen“, genau wie im Haupt-Audit. Der Sub-Score wird aus zwei Gründen bewusst getrennt ausgewiesen und nicht in deinen GEO-Score eingerechnet: Das Feld ist noch jung, und eines seiner Signale — ein Agent-Interface-Deskriptor unter /.well-known/mcp.json — folgt einer Konvention (MCP), die gerade erst standardisiert wird. Diese Prüfung ist deshalb rein informativ: Finden wir einen solchen Deskriptor, weisen wir ihn als vorausschauende Positionierung aus und zeigen das Badge „MCP-Endpunkt erkannt“ — sein Fehlen senkt deinen Sub-Score aber nie. Nichts hier bestraft eine Website dafür, einen Vorstandard noch nicht übernommen zu haben. Die Trennung sorgt außerdem dafür, dass deine historischen GEO-Scores über die Zeit direkt vergleichbar bleiben.

Jedes Audit erzeugt außerdem einen separaten Sub-Score „Entitäts-Autorität“ von 0 bis 100 — ein Maß dafür, wie stark dein schema.org-Entitäts-Graph ist. Wo die Kategorie „Strukturierte Daten“ im Gesamtscore fragt „gibt es überhaupt Schema“, stellt die Entitäts-Autorität die schärfere Frage, die KI-Antwortmaschinen tatsächlich nutzen, um zu entscheiden, wer du bist und ob sie dir vertrauen und dich zitieren (E-E-A-T): eine vollständige Organization (name, url, logo und ein sameAs-Array), Verweise auf autoritative externe Profile (LinkedIn, Crunchbase, Wikidata, offizielle Social-Profile — drei oder mehr sind ein starkes Signal), die benannten Personen hinter der Marke (ein Gründer oder Artikel-Autoren, als Person-Entitäten deklariert) und echte Autorenangaben bei deinen Artikeln. Der Score ist deterministisch — er liest nur die strukturierten Daten, die du wirklich veröffentlichst, und rät nie einen Schema-Typ aus deinem Seitentext — und ehrlich: Enthalten die Stichprobenseiten keine Artikel-Knoten, wird die Autorenangabe als „nicht bewertet“ markiert statt gegen dich gezählt (und BlogPosting zählt als Article, ein Blog wird also nie fälschlich als „fehlender Article“ markiert). Wie Agent-Bereitschaft und Lokale GEO bleibt er aus dem GEO-Hauptscore heraus, damit deine Historie vergleichbar bleibt, und zu jeder Lücke gibt es den Button „Fix mit Crunch entwerfen“. Du siehst ihn auch als Bericht-Dimension „Entity authority“, die in geteilte Links und ins PDF mitwandert.

Wenn ein Kunde ein lokales Unternehmen ist — ein Geschäft, Restaurant, eine Praxis, ein Handwerksbetrieb, alles mit physischem Standort oder Einzugsgebiet — aktiviere im Tab KI-Sichtbarkeit → Einstellungen die Option „Dieser Kunde ist ein lokales Unternehmen“. Das GEO-Audit erzeugt dann einen separaten Sub-Score „Lokale GEO“ von 0 bis 100, neben dem GEO-Gesamtscore und der Agent-Bereitschaft. Wie die Agent-Bereitschaft wird er bewusst nicht in deinen GEO-Hauptscore eingerechnet — eine SaaS ohne LocalBusiness-Schema soll dafür nicht abgewertet werden —, damit deine Historie vergleichbar bleibt. Lokale GEO bewertet die On-Site-Signale, die ein Unternehmen in lokalen KI-Antworten auftauchen lassen („bester Florist in meiner Nähe“, „Klempner in Berlin“): LocalBusiness-Schema und dessen Vollständigkeit, Name/Adresse/Telefon als echter Text, der zum Schema passt, ein Link zu deinem Google-Unternehmensprofil, eigene Standortseiten, deine Stadt und Region in Titeln und Überschriften, Bewertungs-Markup, eine eingebettete Karte und Links zu seriösen Verzeichnissen. Es ist ehrlich — ohne gesetzte Zielstadt heißt es „nicht bewertet“ statt eines Fehlschlags, und dupliziert wirkende „Stadt-Tausch“-Standortseiten werden nie belohnt. Zwei Felder schärfen die Prüfung. Trage die Stadt und Region des Kunden ein, damit das Audit bestätigen kann, dass du nennst, wo du tätig bist, und füge die URL des Google-Unternehmensprofils ein — der Entitäts-Link, der deine Website mit deinem Maps-Eintrag verbindet, eines der stärksten lokalen Signale. So findest du diese URL: Google Maps öffnen, das Unternehmen suchen, den Eintrag öffnen, auf „Teilen“ tippen und den Link kopieren (er sieht aus wie https://maps.app.goo.gl/… oder https://www.google.com/maps/place/…). Dann das Audit ausführen, um die Karte „Lokale GEO“ zu sehen — mit dem Button „Fix mit Crunch entwerfen“ an jedem Problem, genau wie im Haupt-Audit.

Zu jedem Problem, das das Audit findet, gehört eine verständliche Erklärung, was gefunden wurde und wie du es änderst. Und für die Fälle, in denen du den Fix nicht selbst von Hand schreiben willst, hat jedes Problem den Button „Fix mit Crunch entwerfen“. Ein Klick, und Crunch entwirft eine konkrete, kopierfertige Lösung für genau dieses Problem — verankert im tatsächlichen Befund und in der auditierten Seite, kein Ratschlag von der Stange — samt Kopier-Button, um ihn direkt in ein Ticket zu heben oder an die Entwickler des Kunden zu geben. Der entworfene Fix wird bei Bedarf für das Problem vor dir erzeugt und nicht im Audit gespeichert; du kannst ihn jederzeit neu erzeugen. Wie der Rest von Crunch braucht er ein verfügbares KI-Modell (Managed AI oder deinen eigenen Key). Damit wird aus dem Audit statt einer Problemliste eine Liste von Änderungen, die du sofort umsetzen kannst. Ein Problem hat einen eigenen Button. Wenn die /llms.txt-Prüfung nicht besteht, zeigt die llms.txt-Kategorie „llms.txt mit Crunch erzeugen“: Crunch entwirft eine vollständige Start-/llms.txt aus der EIGENEN Struktur der Website — den echten URLs ihrer sitemap.xml plus Titel und Beschreibung der Startseite — gruppiert in Abschnitte mit je einer kurzen Beschreibung. Jeder Link ist eine echte Seite der Website, nie eine erfundene; speichere das Ergebnis nach kurzer Prüfung als /llms.txt im Root deiner Domain.

Dieselbe Audit-Engine treibt auch eine kostenlose, öffentliche Version unter crunchjunkie.io/products/geo-audit an — ohne Login, ohne Konto. Jede Person kann eine Domain eingeben und in Sekunden den 0–100-Score, die Kategorie-Aufschlüsselung und eine priorisierte Fix-Liste bekommen. Für Agenturen ist das praktisch: ein schneller GEO-Check auf der Website eines Interessenten vor dem Pitch, oder den Link teilen, damit ein Kunde das Problem selbst sieht. Das öffentliche Tool ist ratenbegrenzt und liest nur öffentliche Seiten und die robots.txt. Alles andere in dieser Anleitung — das wöchentliche Re-Audit, die Ergebnisse pro Seite, der Wettbewerbs-Crawler-Benchmark, die Agent-Bereitschaft, die Lokale GEO und „Fix mit Crunch entwerfen“ — ist die In-App-Version, die den Score zusätzlich über die Zeit im Projekt des Kunden verfolgt. Zwei ausführliche Guides gehen tiefer, wenn du einem Kunden die Begründung an die Hand geben willst: „GEO-Audit durchführen: die komplette Checkliste 2026“ und „GEO-Audit vs. SEO-Audit“, beide im CrunchJunkie-Blog.