Technisches SEO für KI-Crawler 2026: llms.txt, Rendering ohne JavaScript und sauberes HTML

Die meisten technischen SEO-Audits enden bei Core Web Vitals, Crawlability und strukturierten Daten. Das war bis 2024 vollständig genug. Seit GPTBot, ClaudeBot und PerplexityBot regelmäßig Websites durchsuchen, fehlt in fast jedem Audit eine eigene Schicht: die Sichtbarkeit gegenüber KI-Crawlern. Diese Schicht hat eigene Regeln, eigene Werkzeuge und eigene Fehlerquellen - und sie überschneidet sich nur teilweise mit dem, was klassische Suchmaschinen-Optimierung abdeckt.

Ich betreue seit über 13 Jahren Websites und Online-Shops, hauptsächlich für den deutschsprachigen Markt. In der letzten Zeit begegnet mir bei Audits immer wieder das gleiche Problem: Der Google PageSpeed Score liegt bei 95, die Sitemap ist sauber, das strukturierte Markup korrekt - und trotzdem erscheint der Anbieter nicht in ChatGPT-Antworten oder Perplexity-Zusammenfassungen. Der Grund sitzt oft tiefer, im technischen Fundament.

Warum KI-Crawler kein JavaScript rendern

Google hat mit dem Wave Rendering Service über viele Jahre eine Infrastruktur aufgebaut, die JavaScript ausführen kann. Das ist aufwendig, langsam und teuer - und für ein Unternehmen mit Google-Ressourcen trotzdem machbar. OpenAI, Anthropic und Perplexity haben diesen Schritt bewusst nicht gemacht.

GPTBot, ClaudeBot und PerplexityBot verhalten sich wie ein Browser aus den frühen 2000ern: Sie senden eine HTTP-Anfrage, empfangen das HTML-Dokument und lesen es aus. JavaScript wird nicht geladen, nicht geparst, nicht ausgeführt. Das bedeutet: Alles, was Ihre Website erst nach einem DOM-Event, einem Fetch-Aufruf oder einem Framework-Rendering-Zyklus anzeigt, existiert für diese Crawler schlicht nicht.

Für WordPress-Installationen mit klassischen PHP-Themes ist das kein Problem - der Server liefert fertig gerendertes HTML. Kritisch wird es bei Single-Page-Applications, headless CMS-Setups oder Themes, die Menüs, Produktbeschreibungen oder Texte erst per React oder Vue nachladen. Ein konkretes Beispiel aus meiner Praxis: Ein WooCommerce-Shop hatte seine Produktkategorietexte in ein React-Widget ausgelagert, das nach dem Laden per API befüllt wurde. Für Google sah die Seite in Ordnung aus - für GPTBot waren die Kategorietexte komplett leer.

Wie Sie prüfen, ob Ihre Seite ohne JavaScript funktioniert

Der schnellste Test kostet keine fünf Minuten. Öffnen Sie Chrome, drücken Sie F12 für die DevTools, klicken Sie auf das Zahnrad-Symbol (Einstellungen) und deaktivieren Sie JavaScript unter dem Punkt "Debugger". Alternativ: Strg+Umschalt+P öffnet die Befehlspalette, dort reicht die Eingabe "Disable JavaScript".

Wenn einzelne dieser Punkte ohne JavaScript fehlen, sehen das die KI-Crawler genauso. Die Lösung ist serverseitiges Rendering (SSR) oder - für kleinere Projekte und klassische WordPress-Setups - schlicht der Umstieg zurück auf native PHP-Templates. Das klingt konservativ, ist aber technisch das Richtigste. Frameworks wie Next.js oder Nuxt bieten SSR von Haus aus; wer ein headless WordPress-Setup betreibt, sollte Static Site Generation (SSG) für inhaltsreiche Seiten in Betracht ziehen.

Was llms.txt ist und wie Sie es für WordPress bauen

llms.txt ist eine schlichte Markdown-Textdatei, die im Root-Verzeichnis Ihrer Domain liegt - also unter ihredomain.de/llms.txt. Das Konzept wurde 2024 von Jeremy Howard (Answer.AI) vorgeschlagen und hat sich seitdem als informeller Standard verbreitet. Die Idee: Statt dass KI-Modelle mühsam Ihre gesamte Sitemap durchforsten, liefern Sie ihnen eine strukturierte Übersicht Ihrer wichtigsten Inhalte direkt im Markdown-Format.

Markdown ist für Sprachmodelle das, was HTML für Browser ist - ein Format, das sie nativ verstehen und effizient verarbeiten können. Ein gut aufgebautes llms.txt spart dem Modell Crawling-Aufwand und macht klarer, welche Seiten die relevantesten für Ihr Thema sind.

Für WordPress gibt es Stand Mitte 2026 drei Wege:

1. Manuelle Erstellung: Sie schreiben eine Textdatei im Markdown-Format und legen sie per FTP in das Root-Verzeichnis. Das dauert einmalig 30 Minuten und muss bei größeren Änderungen Ihres Angebots aktualisiert werden.
2. Plugin-Integration: Rank Math und AIOSEO bieten erste llms.txt-Module an. Die Datei wird automatisch generiert und bei neuen Veröffentlichungen aktualisiert.
3. Programmatisch per mu-plugin: Wer volle Kontrolle möchte, kann llms.txt dynamisch aus WordPress-Daten erzeugen lassen - das eignet sich besonders für Shops mit vielen Produktkategorien.

Ein minimales llms.txt für eine Dienstleistungsseite sieht ungefähr so aus: Oben ein kurzer Absatz, wer Sie sind und was Sie anbieten, dann eine Liste der wichtigsten Seiten mit je einer Zeile Beschreibung. Das reicht für den Anfang vollständig aus. Mehr zur inhaltlichen Optimierung für KI-Sichtbarkeit finden Sie in meiner GEO-Checkliste: In ChatGPT und Perplexity zitiert werden.

robots.txt: KI-Crawler nicht versehentlich blockieren

Hier liegt der häufigste Fehler, den ich bei Audits finde. Viele Website-Betreiber haben in ihrer robots.txt pauschal alle unbekannten Bots geblockt - was auf den ersten Blick nach guter Sicherheitspraxis aussieht, aber KI-Search-Crawler mit einschließt, die eigentlich erwünscht sind.

Wichtig ist die Unterscheidung zwischen drei Typen von KI-Crawlern:

• Training-Crawler sammeln Daten zum Training von KI-Modellen. Ihr Block beeinflusst, ob Ihre Inhalte in zukünftigen Modellversionen repräsentiert sind.
• Search-Crawler (OAI-SearchBot, Claude-SearchBot) liefern Ergebnisse für KI-Suchsysteme. Blockieren Sie diese, erscheinen Sie nicht in ChatGPT-Websuche oder Claude-Antworten mit Live-Quellenangaben.
• Assistant-Crawler (ChatGPT-User, Claude-User, Perplexity-User) rufen Seiten live ab, wenn ein Nutzer eine URL direkt nennt oder ein KI-Assistent auf eine Quelle verlinkt.

Eine SEOSOON-Studie aus dem Jahr 2026 zeigt: 33,4 % der untersuchten deutschen Domains blockieren mindestens einen KI-Bot - häufig unbeabsichtigt durch zu breite Wildcard-Regeln. Das ist ein erheblicher Anteil, und ich wette, dass viele dieser Website-Betreiber gar nicht wissen, dass sie in ChatGPT-Suchergebnissen unsichtbar sind.

Die robots.txt-Konfiguration braucht also zwei Dinge: Klarheit über Ihre eigene Strategie (Training erlauben oder nicht?) und Kenntnis der aktuellen User-Agent-Namen. Die Liste ändert sich - neue Crawler kommen hinzu, bestehende ändern ihren Agent-String. Ich empfehle, diese Liste alle drei bis sechs Monate zu prüfen. Eine ausführliche Einführung in die technischen Grundlagen finden Sie in meinem SEO-Guide 2026 für KMU in Deutschland.

Sauberes HTML als Fundament

KI-Crawler mögen kein JavaScript, aber sie mögen auch kein chaotisches HTML. Verschachtelte div-Suppen, fehlende semantische Tags und schlechte Heading-Hierarchien führen dazu, dass Sprachmodelle die Struktur einer Seite falsch interpretieren - oder gar nicht erst extrahieren.

Für die KI-Crawler-Schicht gelten einige klare Regeln: Der Hauptinhalt einer Seite sollte in einem <main>-Element sitzen. Überschriften folgen einer sauberen Hierarchie (H1, dann H2, dann H3) ohne Sprünge. Navigations-HTML ist sauber in <nav> oder <header> vom Content getrennt, damit Crawler nicht Menülinks als inhaltliche Aussagen werten. Boilerplate-Texte wie Cookie-Banner oder Disclaimer sollten semantisch abgegrenzt sein.

Für meine eigene Website dawidweb.com und für Kundenprojekte nutze ich die Kombination aus Blocksy-Theme und native WordPress-Blöcke - das erzeugt sauberes, semantisches HTML ohne überflüssige Wrapper. Die Onpage-Optimierung auf Entitäten-Ebene, die ich in meinem Artikel zu Onpage SEO und Entitäten 2026 beschreibe, baut direkt auf dieser technischen Basis auf.

Server-Logs als KI-Bot-Audit

Google Analytics sieht keinen einzigen KI-Bot-Besuch. Der Grund ist simpel: Diese Bots führen kein JavaScript aus, laden also auch keinen GA4-Tag. Wer wissen will, ob GPTBot seine Website überhaupt besucht - und welche Seiten er sich ansieht - kommt an den Server-Logs nicht vorbei.

Bei LH.pl-Hosting und ähnlichen deutschen Hostern finden Sie die Access-Logs meist im Hosting-Panel unter "Statistiken" oder "Logs". Alternativ: Ihr Hoster stellt rohe Log-Dateien per FTP bereit. Eine einfache Analyse mit grep nach GPTBot, ClaudeBot und PerplexityBot zeigt Ihnen innerhalb von Minuten:

• Wie oft jeder Bot in den letzten 30 Tagen Ihre Site besucht hat
• Welche URLs er gecrawlt hat
• Ob er auf Fehler (404, 403, 500) gestoßen ist
• Wie schnell der Server geantwortet hat (Response Time)

Eine 30-Tage-Log-Analyse von Digital Applied aus 2026 zeigt, dass GPTBot im Schnitt 4.200 Anfragen pro Site und Tag sendet - ClaudeBot kommt auf etwa 1.800, PerplexityBot auf knapp 980. Wenn diese Zahlen bei Ihnen weit darunter liegen, lohnt sich ein Blick auf robots.txt, Server-Sicherheitsregeln und die Gesamtstruktur Ihrer Inhalte.

Die technische Schicht in der Praxis

Ich fasse zusammen, was in einem vollständigen technischen Audit für KI-Sichtbarkeit geprüft werden sollte - separat vom klassischen Core-Web-Vitals-Audit, der weiterhin seine Berechtigung hat:

• Rendert die Seite alle wesentlichen Inhalte ohne JavaScript? (Test: JS in DevTools deaktivieren)
• Ist llms.txt vorhanden, gepflegt und im Markdown-Format korrekt strukturiert?
• Differenziert die robots.txt zwischen Training-Crawlern und Search-Crawlern?
• Enthält der HTML-Quellcode saubere Semantik (main, nav, header, h1-h3-Hierarchie)?
• Sind Server-Logs aktiv und zugänglich für regelmäßige Bot-Traffic-Analysen?
• Gibt es WAF- oder CDN-Regeln, die KI-Bots auf Server-Ebene blockieren, obwohl die robots.txt sie erlaubt?

Die meisten dieser Punkte kosten bei einem WordPress-Setup wenige Stunden Arbeit. Die Wirkung ist langfristig: Je strukturierter und lesbarer Ihre Seite für Sprachmodelle ist, desto wahrscheinlicher erscheinen Sie in KI-Suchergebnissen und Zusammenfassungen. Wer jetzt optimiert, hat gegenüber Wettbewerbern, die diesen Schritt noch nicht gemacht haben, einen klaren Vorsprung.

Haben Sie Fragen zu Ihrer konkreten Situation - ob WordPress-Theme, WooCommerce-Shop oder Unternehmensseite? Ich schaue mir das gerne im Rahmen einer SEO-Beratung an.