GEO-Fehler #9: Langsame Seiten, die KI-Crawler abbrechen
Ein Crawler wartet nicht. Antwortet dein Server zu langsam oder blockiert schweres JavaScript das Rendering, bricht der Crawler ab und liest die Seite unvollständig. Was er nicht liest, kann keine KI zitieren. Performance ist damit keine reine Komfortfrage, sondern eine Bedingung für KI-Sichtbarkeit.
Warum brechen KI-Crawler bei langsamen Seiten ab?
KI-Crawler wie GPTBot, ClaudeBot und PerplexityBot arbeiten mit einem festen Zeitbudget pro Seite. Antwortet dein Server nicht in wenigen Sekunden oder blockiert schweres JavaScript das Rendering, bricht der Crawler ab. Er liest die Seite dann unvollständig oder gar nicht. Was nicht gelesen wird, kann keine KI zitieren.
Eine langsame Seite entsteht selten aus einem einzelnen Grund. Meist kommen mehrere Faktoren zusammen: ein überladenes Design mit vielen unkomprimierten Bildern, große JavaScript-Bundles, ein langsamer oder überlasteter Server und fehlendes Caching. Jeder Faktor addiert Millisekunden, und in Summe wird aus einer eleganten Seite ein schweres Paket, das Sekunden zum Laden braucht.
Für einen menschlichen Besucher ist das ärgerlich, aber er wartet vielleicht. Ein Crawler wartet nicht. Perplexity crawlt Seiten in Echtzeit, während ein Nutzer eine Frage stellt. Das Zeitfenster ist dort besonders knapp. Braucht deine Seite zu lange, ist die Antwort längst formuliert, bevor dein Inhalt überhaupt gelesen wurde. Eine andere, schnellere Quelle wird zitiert.
Auch der Googlebot, dessen Index viele KI-Systeme mitnutzen, hat ein begrenztes Crawl-Budget. Langsame Seiten werden seltener und unvollständiger gecrawlt. Wenn schweres JavaScript den Hauptinhalt erst spät rendert, kann es passieren, dass der Crawler die Seite als fast leer wahrnimmt. Der Effekt ist derselbe wie bei einem harten Timeout: Der Inhalt existiert für die KI nicht.
Wie schnell der größte sichtbare Inhalt geladen ist. Große unkomprimierte Bilder und langsame Server sind die häufigsten Bremsen.
Wie schnell die Seite auf Klicks und Eingaben reagiert. Schweres JavaScript blockiert den Hauptthread und lässt die Seite hängen.
Wie stabil das Layout bleibt. Bilder ohne feste Maße und spät geladene Elemente lassen Inhalte springen.
Richtwerte nach den Core Web Vitals von Google web.dev.
Warum zählt Performance für Crawlbarkeit und Ranking?
Performance wirkt doppelt. Schnelle Seiten werden vollständiger gecrawlt und damit überhaupt erst KI-zitierbar. Gleichzeitig sind Core Web Vitals ein bestätigter Google-Ranking-Faktor. Wer schneller lädt, gewinnt bei der KI-Sichtbarkeit und beim klassischen Ranking zugleich.
Die Crawlbarkeit ist die erste Hürde. Ein Crawler, der abbricht, sieht keinen Content. Ohne Content gibt es nichts zu zitieren und nichts zu ranken. Ladezeit entscheidet also nicht darüber, ob deine Seite ein bisschen schlechter abschneidet, sondern ob sie überhaupt vollständig in den Index kommt. Das ist ein Alles-oder-nichts-Effekt.
Die zweite Ebene ist das Ranking. Google zählt Core Web Vitals als Teil des Page-Experience-Signals. Langsame Seiten ranken schlechter. Da viele KI-Systeme ihre Antworten auf gut positionierten Google-Ergebnissen aufbauen, wirkt sich ein schlechtes Ranking direkt auf die KI-Sichtbarkeit aus. Der Nachteil pflanzt sich fort.
Und schließlich zählt die Nutzererfahrung. Wer über eine KI-Antwort auf deine Seite kommt und dann Sekunden auf das Laden wartet, springt oft wieder ab. Die gewonnene Sichtbarkeit verpufft an der langsamen Landing. Performance ist damit der stille Multiplikator, der über alle Stufen hinweg wirkt: vom Crawl über das Ranking bis zur tatsächlichen Anfrage.
Woran erkennst du, dass deine Seite zu langsam ist?
Der schnellste Test ist Google PageSpeed Insights: URL eingeben, Score und Core-Web-Vitals-Werte ablesen. Ein Performance-Score unter 50 auf Mobile ist ein klares Warnsignal. Achte auf LCP, INP und CLS sowie auf die Gesamtgröße der Seite.
Öffne Google PageSpeed Insights und gib deine wichtigste Seite ein. Das Tool zeigt zwei Bereiche: Felddaten von echten Nutzern und Labordaten aus einem simulierten Test. Für den ersten Eindruck reicht der Performance-Score und die farbliche Einstufung von LCP, INP und CLS. Grün heißt gut, orange heißt Verbesserungsbedarf, rot heißt Problem.
Ergänzend hilft ein Blick auf die reine Seitengröße. Öffne deine Seite und schau in den Netzwerk-Tab der Browser-Entwicklertools. Seiten über 3 bis 4 MB mit Dutzenden großen Bildern und mehreren MB JavaScript sind fast immer zu schwer. Diese Zahlen sagen mehr als jedes Bauchgefühl.
Und dann gibt es das Symptom, das man am eigenen Server sieht: Timeouts und langsame Antwortzeiten in den Server-Logs. Wenn Anfragen regelmäßig über eine Sekunde bis zum ersten Byte brauchen, ist das ein Zeichen, dass der Crawler schon vor dem eigentlichen Inhalt ausgebremst wird.
Wie machst du deine Seite schnell genug für KI-Crawler?
Der wirksamste Fix beginnt bei den Bildern, gefolgt von Caching und einem CDN, weniger und aufgeschobenem JavaScript, serverseitigem Rendering des Hauptinhalts und einem schnellen Hosting. In dieser Reihenfolge holst du den größten Teil der verlorenen Ladezeit zurück.
Warum Feld- und Labordaten unterschiedliche Geschichten erzählen
Wer Performance ernsthaft angeht, stößt schnell auf zwei Datenarten. Labordaten entstehen aus einem einzelnen simulierten Test unter kontrollierten Bedingungen. Sie sind gut, um konkrete Probleme zu finden und Fixes zu prüfen. Felddaten stammen von echten Nutzern über Wochen hinweg und zeigen, wie schnell die Seite unter realen Bedingungen wirklich ist.
Der Unterschied ist wichtig, weil Google für das Ranking die Felddaten heranzieht. Eine Seite kann im Labortest gut aussehen, aber bei Nutzern mit älteren Geräten und langsamem Mobilfunk schlecht abschneiden. Deshalb lohnt es sich, die mobile Ansicht zuerst zu optimieren. Sie ist fast immer der schwächere Wert und zugleich der, den Google und die meisten Crawler zuerst sehen.
Ein häufig unterschätzter Faktor ist das erste Byte, die Server-Antwortzeit. Sie liegt vor allen Rendering-Metriken und begrenzt sie nach oben. Ist der TTFB schon hoch, kann kein noch so schlankes Frontend die Seite retten. Deshalb gehört die Server- und Hosting-Seite zur Performance-Arbeit dazu, nicht nur die Optimierung im Browser.
Und schließlich ist Performance kein einmaliges Projekt. Jedes neue Bild, jedes zusätzliche Skript und jede neue Funktion kann die Seite wieder verlangsamen. Ohne kontinuierliche Messung fällt der Wert unbemerkt zurück. Genau deshalb ist eine laufende Überwachung sinnvoller als ein einmaliger Optimierungssprint.
Core Web Vitals im Audit, jeden Tag automatisch
Pantra misst LCP, INP, CLS und die Server-Antwortzeit über die Google PageSpeed API und verfolgt sie über die Zeit. Wird deine Seite langsamer, siehst du es im Audit, bevor KI-Crawler und Google es dir mit weniger Sichtbarkeit quittieren. Zu jedem Finding gibt es einen konkreten Fix.