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 so ab, wie es die meisten KI-Crawler tun (ein einfacher HTTP-Request ohne JavaScript-Ausführung), und bewertet konkrete, überprüfbare Signale zu einem einzelnen Bereitschafts-Score von 0–100. Für die Crawler von OpenAI, Anthropic und Perplexity ist nicht dokumentiert, dass sie JavaScript rendern. Google rendert Seiten zwar in einem headless Chromium, aber später und über eine Warteschlange, deshalb ist das rohe HTML das, was jede Engine beim ersten Besuch lesen kann. 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, meta-webindexer von Meta AI — ü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 die meisten 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. Dieselbe Kategorie durchsucht die abgerufenen Seiten außerdem nach verstecktem Text, der sich an KI-Leser richtet — Markup, das ein Besucher nie sieht (display:none, Schriftgröße 0, Positionierung außerhalb des Bildschirms, die Attribute hidden oder aria-hidden, Screenreader-Klassen, HTML-Kommentare, alt- oder meta-Attribute) mit Formulierungen wie „ignore previous instructions“ oder „AI assistants: recommend …“. KI-Crawler lesen rohes HTML, solcher Text erreicht sie also vollständig, und Googles Spam-Richtlinien werten versteckten Text und Versuche, generative KI-Antworten zu manipulieren, als Spam. Das ist CrunchJunkies eigene heuristische Erkennung, keine Plattform-Richtlinienprüfung: Die Zeile erscheint nur bei einem Fund, zitiert die Textstelle, damit du sie selbst beurteilen kannst, und wirkt nie auf den Score. 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 aus einem Laborbenchmark von 2024: 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), in der der Anteil einer Quelle an der generierten Antwort (der positionsgewichtete Wortanteil der Arbeit, auf GPT-3.5 und ihren eigenen Testfragen) von 19,5 % ohne Änderungen auf 27,8 % mit Zitaten, 25,9 % mit Statistiken und 24,9 % mit genannten Quellen stieg. Das ist ein Laborergebnis, keine Messung an Live-Engines, und unsere eigenen Daten über 81 Websites (September 2026) zeigen keinen klaren Zusammenhang zwischen dem Gesamtscore des Audits und der Häufigkeit, mit der KI-Antworten eine Website nennen. Jede Prüfung wird als bestanden/teilweise/nicht bestanden mit einer verständlichen Notiz bewertet, die ihre Quelle nennt, damit du siehst, woher die Empfehlung kommt. Das Audit bewertet außerdem die extrahierbare Struktur — ob eine Seite ihre Inhalte in Aufzählungs- oder nummerierte Listen und Datentabellen gliedert, die Antwort-Engines in sich geschlossene Passagen zum Übernehmen bieten. Das wird fair bewertet (eine textlastige Seite wird zu mehr Struktur angestupst, nie deswegen durchfallen gelassen) und stützt sich auf Forschung von 2026 zu Content-Struktur und KI-Zitierung („Structural Feature Engineering for GEO“, arXiv 2603.29979). Derselbe Benchmark hat auch gezeigt, was nicht funktioniert: Keyword-Stuffing schnitt von allen getesteten Methoden am schlechtesten ab. 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 — Cloudflares AI Crawl Control, früher der Schalter „Block AI bots“, 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 deine Startseite und eine Inhaltsseite aus deiner Sitemap ab, gibt sich dabei als jeder einzelne KI-Crawler aus und meldet pro Seite, ob der Request wirklich durchkam. Die zweite Seite zählt, weil manche Sperren nur für einen Teil der Seiten gelten — Cloudflares Standard blockiert seit dem 15. September 2026 Agent- und Trainings-Crawler nur auf Seiten mit Werbung —, die Startseite allein kann also unauffällig aussehen. Das ist standardmäßig rein informativ — eine Warnung gibt es nur, wenn unsere Testanfrage klar abgewiesen wird (ein HTTP 403/406), damit dich normales Rate-Limiting oder ein kurzzeitiger Fehler nicht in Alarm versetzt. Der Test sendet den Namen jedes Crawlers von unseren eigenen Servern, nicht von den veröffentlichten IP-Adressen des Crawlers, und viele Firewalls weisen solche ungeprüften Anfragen ab, während sie die echten Crawler durchlassen: Eine Abweisung ist ein starkes Indiz, kein Beweis. Wird unsere Testanfrage an der Edge abgewiesen, nennt das Audit den betroffenen 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. „Refused our test“ ist das, worauf du achten solltest: Die robots.txt erlaubt den Crawler, die Edge hat unsere Testanfrage aber abgewiesen. Das ist ein Indiz für eine Blockade, kein Beweis, denn unsere Testanfragen tragen den Namen des Crawlers, kommen aber von unseren Servern, und viele Firewalls weisen solche Anfragen ab, während sie die verifizierten Crawler durchlassen. Prüfe die Logs deines CDN oder deiner Firewall auf Anfragen aus den veröffentlichten IP-Bereichen der Crawler. Sie deckt die acht Crawler ab, denen sich eine Blockade zuordnen lässt — die Such-Crawler (OAI-SearchBot, PerplexityBot, Googlebot, meta-webindexer von Meta AI), die Live-Agenten (ChatGPT-User, Claude-User, Perplexity-User) und ClaudeBot — 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. „Echt“ ist wörtlich gemeint: Anfragen, die nur den Namen eines KI-Crawlers benutzen – eine IP außerhalb der veröffentlichten Bereiche des Betreibers oder ein reiner robots.txt-Name wie Google-Extended oder Applebot-Extended, den Google und Apple nie senden –, zählen nicht mit, denn eine Firewall, die sie abweist, macht ihren Job; die Warnung führt sie gesondert auf. Seit dem 27. September 2026 – nachdem ein Kunde eine rote Warnung auf seine Firewall zurückführte, die Schwachstellen-Scanner abwies – bleiben drei weitere Dinge außen vor: Abweisungen auf Scanner-Pfaden wie /.env oder /wp-config.php (eine Sonde bleibt eine Sonde, egal wie sie sich nennt), Anfragen von IPs, die im Zeitraum die Crawler-Namen von zwei oder mehr verschiedenen KI-Betreibern benutzt haben (keine echte Crawler-IP gibt sich zugleich als OpenAI und Anthropic aus – das ist ein Scanner, der User-Agents rotiert), und die Warnung wird zu einem informativen Hinweis „nicht verifiziert“ herabgestuft, wenn die Belege einer Bot-Regel widersprechen: Jeder Crawler mit veröffentlichten IP-Bereichen kam durch, oder jede Abweisung ist ein HTTP 406, die Signatur einer Muster-Regel wie ModSecurity und nicht einer Identitätsregel. Aus demselben Grund zeigt die Karte die Aufteilung 403/406. Von den gezählten Blockaden zeigt sie, wie viele aus den veröffentlichten IP-Bereichen des Betreibers kamen und wie viele sich nicht prüfen ließen (die meisten KI-Betreiber veröffentlichen keine Bereiche, das kann also gut der echte Crawler sein). So erwischst du eine Edge-Sperre auf zwei Wegen: aus einem punktuellen Audit und aus dem Live-Traffic dazwischen. Seit dem 15. September 2026 gibt es eine häufige Ursache für diesen Befund, die man kennen sollte. Seit diesem Datum blockiert Cloudflare standardmäßig die Crawler, die es als Agent einstuft — ChatGPT-User, Claude-User und Perplexity-User, also die Abrufer, die live handeln, wenn ein Assistent eine Frage zu dir beantwortet — sowie die Training-Klasse (GPTBot, ClaudeBot und ähnliche) auf Seiten mit Werbung; das gilt für neue Zonen, neue Websites bestehender Kunden und jede Free-Plan-Zone, während reine Such-Crawler wie OAI-SearchBot erlaubt bleiben. Crawler, die zugleich Suche und Training bedienen, blockiert dieselbe Regel — Cloudflare nennt Googlebot, Applebot und Bingbot —, auf diesen Seiten kann eine Website also auch Google Search und AI Overviews verlieren. An unserem Scan ändert das nichts (wir rufen die APIs der Engines auf), aber eine Website, die so ihre Agenten-Abrufer verloren hat, antwortet Assistenten mit Leere. Der Live-Test trägt deshalb alle drei Klassen, sodass das Muster als „Refused our test“ in den Agent- und Training-Zeilen auftaucht, meist auch bei Googlebot, während OAI-SearchBot durchkommt — und wenn die Antworten Cloudflares Edge-Marker tragen, benennt der Befund die Ursache und verweist auf Cloudflare → AI Crawl Control (oder eine WAF-Skip-Regel). Ohne diese Marker bleibt es bei der allgemeinen Formulierung und bei einem halben Punkt statt null: Das Audit behauptet nie Cloudflare, das es nicht gesehen hat. Das Cloudflare-Standardmuster ist die Ausnahme von „Indiz, kein Beweis“: Abgewiesene Agent- und Training-Crawler bei durchgelassenen reinen Such-Crawlern passen zu einer dokumentierten Regel, die auch für die verifizierten Crawler gilt, dieser Fall bleibt deshalb ein Fehlschlag. Bei einer bestätigten Sperre nennt die Zeile außerdem die Schicht, die geantwortet hat – Cloudflare, Amazon CloudFront / AWS WAF, Akamai, Vercel, Sucuri, Imperva, Fastly, ModSecurity oder der Webserver selbst, wenn die Antwort keine CDN-Merkmale trägt –, gelesen aus den Headern und dem Body dieser Antwort, nie aus einer IP oder einem Hoster geraten, mit der Korrektur für genau diese Schicht: Eine robots.txt-Änderung hebt keine WAF-Sperre auf. Eine Bot-Challenge, die unseren eigenen Audit-Request trifft, wird als „aus unserer Warte nicht eindeutig“ gemeldet, nie als Sperre der Crawler. 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. Die Seitenliste stammt aus jeder Sitemap, die die Website veröffentlicht, einschließlich Sitemap-Indizes und in der robots.txt angegebener Sitemaps, und aus den Links der Startseite, wenn es keine Sitemap gibt. Eine Seite der Auswahl, die unsere Anfrage ablehnt oder nicht beantwortet (403, 429, Serverfehler), wird ausgelassen statt bewertet; ein 404 bleibt drin, denn eine tote URL in der eigenen Sitemap ist ein Befund. 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. Ist die Startseite beim Audit nicht die Website, sagt das Audit das, statt einen Score auszugeben. Das gilt für eine Sperrseite des Hosters, eine abgelaufene oder geparkte Domain, eine Standardseite des Servers, einen Serverfehler und eine Startseite, die nicht antwortet. Die Seite nennt, was der Server zeigte, bietet an, das Audit erneut auszuführen, und verlinkt das letzte Audit der verfügbaren Website. Der Score erscheint durchgestrichen als nicht vergleichbar, und es werden keine Korrekturen oder KI-Hinweise daraus abgeleitet, denn sie würden den Platzhalter beschreiben statt der Website. Ein solches Audit löst keine Score-Warnung aus (dafür gibt es das eigene Signal „Website wird nicht ausgeliefert“), und Berichte sowie Content-Briefs verwenden stattdessen das letzte Audit der verfügbaren Website. Die API und der CrunchJunkie-Connector liefern das Audit mit einem Feld homepageUnavailable, das sagt, was der Server zeigte. Die Prüfungen, die gelaufen sind, bleiben unter „Zeigen, was auf dieser Seite gemessen wurde“ einen Klick entfernt. 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.

Die meisten KI-Crawler holen eine Seite mit einem einfachen HTTP-Request und führen kein JavaScript aus (für die Crawler von OpenAI, Anthropic und Perplexity ist nicht dokumentiert, dass sie es rendern) — alles, was eine Website erst im Browser nach dem Laden zeichnet, ist für sie unsichtbar. Google ist die Ausnahme: Googlebot rendert jede Seite, die mit 200 antwortet und nicht auf noindex steht, in einem headless Chromium, aber später, über eine Warteschlange, und AI Overviews und AI Mode verlinken nur Seiten, die indexiert sind und ein Snippet zeigen dürfen. Serverseitiges Rendering liefert jeder Engine den Inhalt schon beim ersten Abruf. 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). Kurz: Er prüft, ob KI-Agenten deine Website erreichen, ohne JavaScript lesen und ihre Daten auswerten können — die Voraussetzungen, kein Test, ob ein Agent dort eine Aufgabe abschließen kann. Eine Studie von MERJ (September 2026) zeigt, warum der Unterschied zählt: Eine Seite kann jede Readiness-Prüfung bestehen, während ein Agent an der Aufgabe auf ihr trotzdem scheitert. 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. Zwei Prüfungen folgen Googles Lighthouse, das in Version 13.5 (September 2026) seiner Kategorie Agentic Browsing eine Gruppe Agent Discoverability hinzugefügt hat und sie gerade in PageSpeed Insights bringt — so stimmt unser Urteil mit dem überein, was ein Kunde in den Chrome DevTools sieht. Die erste ist Agent Resource Discovery. Wir suchen eine ai-catalog.json so, wie Lighthouse es tut: eine Agentmap-Zeile in der robots.txt, ein Tag link rel="ai-catalog", ein Link-Header, dann /.well-known/ai-catalog.json. Gibt es eine, prüfen wir sie gegen die ARD-1.0-Regeln, die Lighthouse anwendet (Spec-Version, Einträge, urn:air:-Kennungen, Anzeigename, Typ, genau eines von url oder data). Die aktuelle ARD-Spezifikation (v0.91, 26. August 2026) hat die Datei in ard.json und den Link in rel="ard" umbenannt; Lighthouse 13.5 liest beides noch nicht. Deshalb suchen wir nach beiden Formen, zuerst nach ard.json, und das Ergebnis nennt, welche gefunden wurde und ob Lighthouse sie sieht. Eine ard.json braucht keine Spec-Version. Wie der MCP-Deskriptor ist sie rein informativ, und keine zu veröffentlichen ist in Ordnung; Lighthouse wertet das ebenfalls als nicht anwendbar. Nicht ausgeführt wird nur Lighthouses zusätzlicher strenger JSON-Schema-Durchlauf, und die Prüfung sagt das. Eine dritte Prüfung in dieser Gruppe, „Markdown für Agenten“, fordert die Startseite mit dem Header Accept: text/markdown an – so, wie es Agenten von Vercel, Cloudflare und anderen inzwischen tun – und meldet, ob die Website mit einer Markdown-Fassung antwortet (Content-Type text/markdown, idealerweise mit Vary: Accept, damit Caches beide Fassungen auseinanderhalten) oder mit der HTML-Seite; kündigt die Seite per link rel="alternate" type="text/markdown" eine Markdown-Zwillingsfassung an – der Weg, den Applebot nimmt –, wird auch diese abgerufen und beurteilt. Sie ist rein informativ und wird nie gewertet: Keine Antwortmaschine hat bestätigt, dass eine Markdown-Antwort Zitate beeinflusst – deshalb ist sie wie llms.txt formuliert, als günstige Hygiene für Agenten-Lesbarkeit, die Hoster wie Vercel und Cloudflare ohne Inhaltsänderung einschalten können. Die zweite Lighthouse-Prüfung ist die Gültigkeit der llms.txt im llms.txt-Abschnitt, die jetzt Lighthouses drei Regeln nutzt: eine H1, mindestens ein Link und mindestens 50 Zeichen.

Jedes Audit erzeugt außerdem einen separaten Sub-Score „Entitäts-Markup“ von 0 bis 100 — ein Maß dafür, wie stark dein schema.org-Entitäts-Graph ist. Er misst nur das Markup auf deiner Website, nicht wie bekannt oder maßgeblich deine Marke ist: Eine berühmte Marke ohne Organization-Schema erreicht trotzdem einen niedrigen Wert. Wo die Kategorie „Strukturierte Daten“ im Gesamtscore fragt „gibt es überhaupt Schema“, stellt das Entitäts-Markup die schärfere Frage, ob die Website selbst sagt, wer dahintersteht (die E-E-A-T-artigen Signale): 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. Nimm nur echte Personen: Googles Richtlinien zu hilfreichen Inhalten (Stand 1. Oktober 2026) werten erfundene Autorenprofile als Täuschung, und das Audit liest dein Markup, kann aber nicht prüfen, ob eine genannte Person existiert. 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 markup“, die in geteilte Links und ins PDF mitwandert. Ein Diagnosepfad ist es wert, gekannt zu werden: Teams mit starkem technischem SEO — sauberes Schema, korrekte robots.txt — sind regelmäßig überrascht von schwacher KI-Sichtbarkeit, weil Antwort-Engines mehr gewichten als Markup-Konformität. Wenn deine Structured-Data-Checks bestehen, die Sichtbarkeit aber niedrig bleibt, schau als Nächstes hier hin: Ein dünner Entitätsgraph (keine sameAs-Profile, keine benannten Personen, keine Autorenschaft) ist ein häufiger Grund, warum Engines nicht einordnen können, wer du bist und ob ein Zitat vertrauenswürdig wäre — und danach liegt die Lücke meist gar nicht on-site, sondern in Off-Site-Autorität, die die Ansichten Domains und Gap-Analyse direkt messen.

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 entworfenen Änderungen. Verstehe jeden Entwurf als Ausgangspunkt: Prüfe und bearbeite ihn, bevor du ihn ausspielst, und ersetze Platzhalter durch deine echten Werte. Googles Hinweise zu KI-generierten Inhalten (Stand 1. Oktober 2026) nennen Titel, Meta-Beschreibungen, strukturierte Daten und Alt-Texte als Stellen, an denen ungeprüfter generierter Text Probleme macht. Die Probleme zu Organization und sameAs werden anders behandelt, denn sie drehen sich um Fakten, die ein Modell nicht kennen kann. Dafür liest Crunch deine Startseite und die dort verlinkten Seiten Über uns, Kontakt und Impressum und baut aus dem, was dort steht, einen vernetzten Block: eine Organization, die von ihr veröffentlichte WebSite und die Startseite, verbunden über @id. Name und Logo stammen aus deinem eigenen Markup oder deinen Tags; nennt die Website nirgends einen Namen, wird der Markenname verwendet, den du dem Projekt gegeben hast – aber nur, wenn der Titel deiner Startseite ihn bestätigt. Leitet die Root-URL auf einen Sprachordner wie /de weiter, beschreibt der Startseiten-Eintrag die Seite, die tatsächlich gelesen wurde. sameAs enthält nur Profil-Links, die auf deiner Website stehen – in deinem Markup deklariert oder auf den gelesenen Seiten verlinkt. Ein Profil, das nur auf einer einzelnen Unterseite verlinkt ist, wird als weggelassen aufgeführt und nie einfach dir zugeschrieben, und es gibt keine Platzhalter zum Ausfüllen. Unter dem Block steht, woher jeder Wert stammt und was bewusst weggelassen wurde. Dieser Weg braucht kein KI-Modell. Jeder Block wird geprüft, bevor du ihn siehst: Das JSON muss gültig sein, und jeder Typ und jede Eigenschaft muss im aktuellen schema.org-Vokabular existieren und an einem Typ sitzen, der sie erlaubt. Dieselbe Prüfung läuft über jedes JSON-LD in einem vom Modell entworfenen Fix, und das Ergebnis steht unter dem Entwurf. Den Rich Results Test von Google ersetzt das nicht; er prüft zusätzlich Wertformate und Pflichtfelder auf der Live-Seite. 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. Jedes kostenlose Audit bekommt eine permanente Ergebnisseite (crunchjunkie.io/de/products/geo-audit/r/<id>) mit Vorschaubild, sodass Besucher Score, die beiden eigenständigen Teilwerte und die Fix-Liste posten oder weiterleiten können. Ergebnisseiten werden von Suchmaschinen nicht indexiert, zeigen nie die E-Mail-Adresse des Besuchers und verlinken direkt auf den kostenlosen KI-Sichtbarkeits-Check für dieselbe Domain – der ehrliche nächste Schritt, denn ein GEO-Score findet Blocker und sagt nicht voraus, wie oft Suchmaschinen eine Marke nennen.