Nein, die meisten Websites rendern für AI-Crawler nicht leer — wir haben es nachgemessen
„AI-Crawler sehen nur ein leeres Skelett" ist das beliebteste Argument im GEO-Marketing. Wir haben es an 300 zufällig gezogenen Websites echter deutscher Kleinbetriebe geprüft — und die These fällt durch. Hier sind die Zahlen, inklusive der Minderheit, bei der es wirklich zutrifft.
des sichtbaren Texts liefert die typische Website eines lokalen Betriebs schon im Roh-HTML — ganz ohne JavaScript (Median über 189 messbare Seiten). Ein nicht-rendernder Crawler sieht fast alles.
Wir haben unsere eigene These widerlegt — zweimal
Die Erwartung war: Kleinbetriebe bauen ihre Seiten mit Baukästen und JavaScript-Themes, also müsste ein Roh-HTML-Crawler bei vielen ins Leere greifen. Ein erster Lauf über bekannte Marken fand davon null Prozent — was wir auf die falsche Stichprobe schoben: Tech-Unternehmen server-rendern eben gut.
Also haben wir den Lauf mit der richtigen Population wiederholt: 300 zufällig gezogene Websites echter Betriebe — Apotheke, Café, Handwerk, Praxis, Hotel. Ergebnis: Median-Coverage 98,8 %. Es lag nicht an der Stichprobe. Die These ist schlicht falsch.
Der Grund ist banal: Die meisten Kleinbetriebe nutzen WordPress, Typo3 oder klassische Baukästen — und die liefern fertiges HTML aus. Die JavaScript-only-Seite ist die Ausnahme, nicht die Regel.
Was wirklich zutrifft — und für wen
Ein reales Problem gibt es, es ist nur viel kleiner als behauptet: 4,2 % der messbaren Seiten (rund 1 von 24) zeigen einem Roh-Crawler weniger als 40 % ihres Inhalts. Nimmt man die weichere Schwelle von 60 %, sind es 12,7 % — rund 1 von 8. Bei n=189 liegen die 95-%-Konfidenzintervalle bei ±2,9 bzw. ±4,7 Prozentpunkten.
Wen es trifft, ist dafür brutal eindeutig. Eine Heidelberger Buchhandlung liefert 204 KB HTML, davon 203 KB JavaScript — der sichtbare Text, den ein Crawler bekommt, lautet vollständig: „Buch-Markt … Fehler beim Laden der App. Erneut Versuchen". Der Crawler bekommt kein leeres Skelett. Er bekommt eine Fehlermeldung, und die ist alles, was er zitieren könnte.
Eine Rostocker Zahnarztpraxis liefert 2 KB mit genau einem Satz: dem Praxisnamen. Ein Jeans-Laden liefert nur seine Navigation. Für diese Betriebe ist das kein Detail — für sie existiert der Inhalt ihrer Website in der KI-Welt nicht.
Der ehrlichere Befund: die Tür ist häufiger zu als der Raum leer
Auffälliger als die Render-Lücke war etwas anderes: 26 der 300 Domains (8,7 %) verweigerten dem GPTBot-User-Agent direkt den Zugriff (403/401). Dazu kam ein Fall, der uns fast in die Irre geführt hätte: ein Server antwortete mit HTTP 200, der Body war aber die Blockseite seiner WAF — praktisch ohne Text.
Genau diese Verwechslung ist der Grund, warum solche Zahlen so oft zu hoch ausfallen: Eine geschlossene Tür sieht in der Messung aus wie ein leerer Raum. Wir zählen beides getrennt — die getarnte Blockseite ist ein Block, kein Render-Problem.
Dieselbe Falle ist uns beim Gegenteil fast passiert: Von den Domains, deren Roh-Fetch scheiterte, antworteten 13 einem echten Browser ganz normal — teils, weil der Server die Verbindung gezielt beim GPTBot-User-Agent kappt, teils wegen Rate-Limits. Sie als „tot" zu zählen wäre exakt derselbe Fehler, nur andersherum. Wirklich unerreichbar (Roh-Fetch UND Browser scheitern) sind 39 Domains (13,0 %).
Der vollständige Trichter — was von 300 übrig bleibt
Alle Prozente oben beziehen sich auf die 189 messbaren Seiten, nicht auf die 300 gezogenen. Sonst mischt sich „rendert leer" mit „Domain existiert nicht". Vollständig aufgeschlüsselt: 189 messbar, 39 wirklich unerreichbar, 26 blocken den GPTBot (403/401), 13 Roh-Fetch gescheitert aber vom Browser erreicht, 17 Render-Timeouts (>60 s), 13 zu dünn für einen sinnvollen Quotienten (<50 gerenderte Wörter), 2 reine Weiterleitungs-/Frameset-Hüllen, 1 getarnte Blockseite.
Das ergibt zusammen genau 300 — die Rechnung geht auf, und jede ausgeschlossene Domain hat einen benannten Grund. Wer nachzählen will: die Rohdaten mit einer Zeile pro Domain liegen offen im Repo.
Stichprobe & Methodik — offen und nachbaubar
Quelle: OpenStreetMap via Overpass-API (frei, ohne Key). Rahmen: 9.232 eindeutige Domains — alle OSM-Betriebe mit hinterlegter Website (Handel, Handwerk, Büro, Gastro, Gesundheit, Hotel) in 8 mittelgroßen deutschen Städten: Bonn, Freiburg, Erfurt, Regensburg, Münster, Heidelberg, Rostock, Kassel. (Kiel und Osnabrück liefen bei Overpass in einen Timeout und sind ehrlich nicht enthalten.)
Ziehung: 300 Domains, Fisher-Yates mit festem Seed 20260716. Zufällig — also kein Cherry-Pick — und reproduzierbar, weil der Seed hier steht. Die Liste steht fest, bevor irgendetwas gemessen wird.
Messung: pro Domain das Roh-HTML mit GPTBot-User-Agent (kein JavaScript) gegen das gerenderte DOM (Playwright, Timeout 60 s). Coverage = sichtbare Roh-Wörter ÷ sichtbare gerenderte Wörter, Textextraktion für beide Seiten identisch. Beide Seiten tolerieren Zertifikatsfehler gleich — sonst fällt jede Seite mit abgelaufenem Zertifikat fälschlich als „tot" aus der Statistik, obwohl der Browser sie anzeigt. Schwellen: <0,4 „quasi leer", <0,6 „stark unvollständig".
Grenzen, offen: Nur Betriebe mit hinterlegter Website (leicht Richtung „etwas etablierter" verzerrt). 8 Städte, kein Bundesland-Proporz. Nur Startseiten. OSM-Filialen tragen die Konzern-Website (lecreuset.de, vodafone.de sind im Rahmen) — das verzerrt eher nach unten, da Konzerne gut server-rendern. Einige der Rate-Limit-Antworten (429) können von unserer eigenen Parallelität stammen. Und: Coverage ist nicht Zitierbarkeit; eine Seite mit 60 % server-gerendertem Text ist für eine KI vermutlich weiterhin brauchbar. Die Zahlen gelten für *diese offengelegte Stichprobe*, nicht als „exakt X % aller deutschen Betriebe".
FAQ
Ist Rendering für AI-Sichtbarkeit also egal?
Für die meisten Seiten: ja, es ist nicht der Engpass — das sagen unsere eigenen Daten, auch wenn es gegen das naheliegende Verkaufsargument spricht. Für rund 1 von 24 Seiten ist es dagegen fatal, weil der Crawler praktisch nichts oder sogar eine Fehlermeldung bekommt. Die einzige Art, das für DEINE Seite zu wissen, ist nachsehen — nicht der Pauschalaussage glauben, in keine Richtung.
Warum weicht das von anderen „X % rendern leer"-Zahlen ab?
Zwei häufige Ursachen, beide hatten wir selbst. Erstens die Population: misst man bekannte Marken oder JS-Framework-Showcases, bekommt man ein anderes Bild als bei echten Betrieben. Zweitens die Zählweise: Wer geblockte Anfragen (auch die als HTTP 200 getarnten Blockseiten) und tote Domains als „rendert leer" mitzählt, kommt auf viel höhere Zahlen. Wir weisen jeden dieser Fälle getrennt aus, und die Summe geht nachprüfbar auf.
Woher stammt die Stichprobe?
Aus OpenStreetMap via Overpass-API: alle Betriebe mit hinterlegter Website in 8 mittelgroßen deutschen Städten (9.232 Domains), daraus 300 zufällig gezogen mit dem offengelegten Seed 20260716. Quelle offen, Werkzeug und Rohdaten im Repo, 1:1 nachbaubar.
Wie prüfe ich, ob meine eigene Seite betroffen ist?
Schneller Selbsttest: `curl -s https://deine-domain.de | wc -w` gegen das, was du im Browser siehst — kommen nur ein paar Dutzend Wörter zurück, während die Seite voll aussieht, lädt dein Inhalt per JavaScript nach. Den sichtbaren Effekt zeigt der kostenlose deeploupe-Checker: ob ChatGPT & Co. dich überhaupt erwähnen. Ohne Anmeldung.
Stand: Juli 2026