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. 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 noch junge Konvention, deshalb niedrig gewichtet, weil bislang keine große Engine bestätigt hat, dass sie sie nutzt. 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. 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.

Ö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, Startseite, llms.txt und Sitemap in einem Durchgang. 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. 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. 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 drei 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.

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.