Prüfen, ob KI-Crawler Ihre Website tatsächlich erreichen und lesen können

Prüfe, ob meine Website [site URL] Inhalte für KI-Suche wie ChatGPT, Claude, Perplexity, Gemini und Copilot ausliefern kann. Meine Search-Console-Property ist [Search Console property, or "none"]. Meine wichtigsten Seiten sind: [5 to 10 page URLs]. Das ist ein reiner Lese-Audit, ändere nichts. 1. robots.txt. Lies [site URL]/robots.txt mit site_read_url und notiere den Statuscode. Wenn die Datei 5xx zurückgibt oder in einer Weiterleitungsschleife landet, sag gleich zu Beginn, dass Crawler die Website möglicherweise gar nicht crawlen. Ermittle dann, welche Regelgruppe für jeden dieser Crawler gilt und ob meine wichtigen Seiten erlaubt sind: OAI-SearchBot, ChatGPT-User, GPTBot, Claude-SearchBot, Claude-User, ClaudeBot, PerplexityBot, Perplexity-User, Googlebot, Google-Extended, Bingbot, Applebot, Applebot-Extended, CCBot, meta-externalagent. Wenn ein Crawler eine Gruppe unter seinem eigenen Namen hat, gilt nur diese Gruppe und die `User-agent: *`-Regeln gelten nicht, berücksichtige das. 2. Sortiere die Crawler nach Rolle. Für Suche und Zitate crawlen OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot und Googlebot. Eine Seite live abrufen, wenn ein Nutzer eine Frage stellt, tun ChatGPT-User, Claude-User und Perplexity-User. Trainingsdaten sammeln GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot und meta-externalagent. Markiere jeden blockierten Such-Crawler mit dem höchsten Schweregrad, denn dann kann die Website in den Antworten dieses Assistenten nicht zitiert werden. Behandle einen blockierten Trainings-Crawler nicht als Fehler, beschreibe ihn als Entscheidung. Beachte: Google-Extended hat keinen Einfluss auf die Google-Suche oder AI Overviews und steuert nur, ob die Inhalte für Gemini-Modelle verwendet werden. 3. Statuscodes und Header. Lies jede wichtige Seite mit site_read_url und max_bytes=0. Melde nur den Statuscode, die Weiterleitungskette (redirects), die Header `x-robots-tag` und `content-type` sowie den `server`-Wert, nicht den vollständigen Header-Dump. Markiere Weiterleitungsketten mit mehr als zwei Hops, eine End-URL, die vom Canonical abweicht, und jeden noindex- oder nosnippet-Header. Wenn eine Seite 403, 429 oder 503 zurückgibt und der server-Wert eine Schutzschicht wie Cloudflare, Sucuri oder Akamai zeigt, weise darauf hin, dass es sich um eine Bot-Sperre handeln kann. 4. Inhalt ohne JavaScript. Lies die wichtigen Seiten mit site_read_url und text=true. Diese Ansicht wird aus dem HTML extrahiert, das der Server sendet, also genau das, was ein KI-Crawler sieht, der kein JavaScript ausführt. Wenn die Antwort truncated is true meldet, lies die Seite erneut mit max_bytes=1000000, sonst glaubst du, Inhalte weiter unten fehlten. Sag für jede Seite, ob H1, der erste Absatz des Hauptinhalts, Preis- oder Leistungsangaben und Kontaktdaten in diesem Text vorkommen und ob internal_links Links zu den Seiten des Hauptmenüs enthält. 5. Inhalt mit JavaScript. Miss die drei wichtigsten Seiten mit seo_technical_audit, das die Seite mit JavaScript rendert. Markiere gesondert jede Seite, bei der Title, H1 oder Sprache zwischen den beiden Ansichten abweichen. Ein Sprachunterschied entsteht meist durch eine automatische Weiterleitung nach Land oder Browsersprache des Besuchers, und weil die meisten KI-Crawler von Servern in den USA kommen, kann das dazu führen, dass sie die falsche Sprachversion sehen. 6. Was Google sieht. Wenn ich eine Search-Console-Property habe, prüfe die wichtigen Seiten in einem einzigen gsc_inspect_urls-Aufruf: Abdeckungsstatus, Datum des letzten Crawls und von Google gewähltes Canonical. Liste jede wichtige Seite auf, die per robots.txt blockiert ist oder als "Gecrawlt, zurzeit nicht indexiert" angezeigt wird. Liste die eingereichten Sitemaps mit ihren Warnungen und Fehlern über gsc_sitemaps auf. 7. Discovery-Dateien. Lies sitemap.xml und llms.txt mit site_read_url. Prüfe, ob meine wichtigen Seiten in der Sitemap stehen und ob die lastmod-Werte echt aussehen, und sag es, wenn alle URLs dasselbe Datum tragen. Wenn llms.txt fehlt, vermerke es als Lücke, aber nicht als kritische, denn keine der großen KI-Suchmaschinen hat offiziell erklärt, diese Datei als Ranking- oder Zitiersignal zu verwenden. Benenne die Grenzen der Tools klar. site_read_url sendet seine Anfrage wie ein Browser und kann sich nicht als GPTBot oder ClaudeBot ausgeben, daher taucht eine Firewall-Regel, die nur nach Crawler-Namen blockiert, in diesem Audit nicht auf. Wenn ich ein CDN oder eine Firewall nutze, erinnere mich daran, im zugehörigen Panel nach einer Einstellung zu suchen, die KI-Crawler blockiert (bei Cloudflare "AI Crawl Control" oder "Block AI bots"). Wenn die Website bei Opus Growth gehostet wird, schick mich nicht zu einem CDN-Panel, und wenn du eine Sperre siehst, schlage vor, sie mit report_issue zu melden. Formatiere die Ausgabe so. Zuerst eine Zusammenfassung in drei Sätzen: Ist meine Website offen für KI-Suche, und wenn nicht, was ist das größte Hindernis. Dann eine Crawler-Tabelle: Crawler, Rolle, robots.txt-Entscheidung, die entscheidende Regelzeile, Schweregrad. Dann eine Seitentabelle: URL, Statuscode, Weiterleitungen, x-robots-tag, H1 und erster Absatz im Text ohne JavaScript (ja oder nein), Unterschied zur JavaScript-Ansicht, Google-Abdeckungsstatus. Zum Schluss eine nach Schweregrad geordnete Fix-Liste, jeweils mit Beleg und Zuständigem (ich, ein Entwickler, der Hosting-Anbieter). Wo die Daten für eine Schlussfolgerung nicht ausreichen, rate nicht, sondern sag, was fehlt.