Du hast deine Inhalte optimiert. Deine Website zeigt Fachwissen, Autorität und Signale für Vertrauen. Aber wenn ein KI-Crawler deine Seite erreicht und in ein Timeout läuft, weil dein Server 6 Sekunden zur Antwort braucht oder LCP nach 5 Sekunden noch nicht fertig gerendert ist, zieht der Crawler weiter. Deine Inhalte werden nie indexiert. Deine Zitate bleiben aus.
Geschwindigkeit entscheidet über Sichtbarkeit. Nicht schleichend. Sofort und hart.
KI-Crawler arbeiten unter Einschränkungen, die klassische Suchmaschinen nicht haben. Sie haben strenge Zeitfenster für Timeouts, begrenzte Rechenbudgets und wenig Geduld. Eine Seite, die bei Google perfekt rankt, kann für ChatGPT, Perplexity oder Claude komplett unsichtbar sein, weil sie nicht innerhalb der Frist des Crawlers lädt. Dieses Kapitel behandelt, wie Core Web Vitals für KI funktionieren, welche Kennzahlen am wichtigsten sind und was du ändern musst.
Was Core Web Vitals messen und warum es sie gibt
Core Web Vitals sind drei Kennzahlen, die Google geschaffen hat, um die echte Nutzererfahrung zu messen. Sie erfassen den Moment, in dem der Browser beginnt, Inhalte zu zeigen, den Moment, in dem Nutzer mit der Seite interagieren können, und wie stabil das Layout beim Laden bleibt. Google behandelt sie als Rankingfaktoren. Für KI-Crawler sind sie aber Überlebensfaktoren.
Die drei Kennzahlen sind:
Largest Contentful Paint (LCP): Wie lange es dauert, bis das grösste visuelle Element geladen ist. Das Ziel liegt unter 2,5 Sekunden. Das ist das, was Nutzer zuerst sehen. Wenn dein Hero-Bild, deine Überschrift oder dein Hauptbereich 4 Sekunden braucht, um zu erscheinen, müssen Menschen und Crawler gleichermassen warten.
Interaction to Next Paint (INP): Wie lange der Browser braucht, um zu reagieren, nachdem ein Nutzer auf etwas geklickt hat. Das Ziel liegt unter 200 Millisekunden. Diese Kennzahl prüft, ob dein JavaScript aufgebläht ist oder deine Seite einfriert, wenn Crawler Interaktion simulieren.
Cumulative Layout Shift (CLS): Wie sehr die Seite beim Laden herumspringt. Das Ziel liegt unter 0,1. Wenn sich Elemente unerwartet verschieben, ziehen Crawler durcheinandergeratene oder unvollständige Inhalte heraus. Deine sorgfältig geschriebenen Absätze werden beim Auslesen durch den Crawler unlesbar.
Für die klassische Suche sind das Hinweise. Für KI-Crawler sind es harte Grenzen.
Warum KI-Crawler andere Anforderungen an die Geschwindigkeit haben als Google
Der Crawler von Google verteilt die Arbeit. Er crawlt Millionen von URLs auf Tausenden Servern. Er kann es sich leisten, 10 Sekunden auf das Laden einer Seite zu warten, weil sich das Warten über eine riesige Infrastruktur verteilt.
KI-Crawler arbeiten mit Inferenz pro Anfrage. Wenn ein Nutzer ChatGPT eine Frage stellt, hat Perplexity 3 bis 5 Sekunden, um deine Inhalte zu finden, abzurufen und auszulesen, bevor die Antwort beginnen muss. Jede Sekunde zählt. Jede Millisekunde wird vom Crawl-Budget abgezogen.
Studien zum Verhalten von KI-Crawlern zeigen, dass Websites mit einem First Contentful Paint unter 0,4 Sekunden im Schnitt 6,7 Zitate bekommen, während Websites, die über 1,13 Sekunden laden, im Schnitt 2,1 Zitate bekommen. Das ist keine Korrelation. Das ist Kausalität. Langsame Seiten werden übersprungen.
Der Crawler von ChatGPT für den Abruf hat einen dokumentierten Schwellenwert für Timeouts. Seiten, die nicht innerhalb dieses Fensters antworten, werden als nicht erreichbar markiert und bei künftigen Crawl-Versuchen zurückgestuft. Der Bot von Perplexity macht dasselbe. Eine Website, die 6 Sekunden zur Antwort braucht, bekommt keine zweite Chance.
Time to First Byte (TTFB): die Kennzahl, die KI-Crawler am meisten interessiert
TTFB misst den Moment zwischen dem Senden einer Anfrage und dem Eintreffen des ersten Bytes vom Server. Es ist das reinste Mass für die Reaktionsfähigkeit des Servers.
Für KI-Crawler entscheidet TTFB, ob sie überhaupt versuchen zu rendern. Wenn dein Server 700 Millisekunden zur Antwort braucht, hat der Crawler 700 Millisekunden seines Zeitfensters von 3 bis 5 Sekunden verschwendet. Der Crawler bricht das Rendern ganz ab und liest nur noch HTML. Das heisst, deine mit JavaScript gerenderten Inhalte werden unsichtbar.
Die Richtwerte sind klar. Ein TTFB unter 200 Millisekunden gilt als hervorragend. 200 bis 500 Millisekunden sind akzeptabel, aber nicht ideal. Über 600 Millisekunden hast du ein Problem mit der Infrastruktur des Servers.
Die meisten Artikel zur Leistung behandeln TTFB als zweitrangig gegenüber visuellen Kennzahlen. Für KI-Crawler ist er der Türsteher. Wenn TTFB scheitert, zählt nichts anderes.
Häufige Ursachen für langsames TTFB sind langsame Datenbankabfragen bei jedem Laden einer Seite, überlastetes Hosting mit zu vielen Websites pro Server, schlechte geografische Weiterleitung von Anfragen und fehlendes Caching über ein Content Delivery Network (CDN). Das sind keine Probleme des Designs. Das sind Probleme der Infrastruktur.
Largest Contentful Paint (LCP): Warten auf das grosse Element
LCP misst die Zeit, bis das grösste visuelle Element vollständig geladen ist. Das ist meist ein Hero-Bild, ein Hintergrundbild oder ein grosser Textblock. Bei Seiten mit viel Inhalt ist es der Hauptbereich.
Ein LCP unter 2,5 Sekunden ist die Schwelle für "gut". KI-Crawler zitieren Seiten in diesem Bereich 2,8-mal häufiger als Seiten mit langsamerem LCP. Der Unterschied ist nicht subtil.
Der Crawler wartet nicht, bis jedes Element fertig geladen ist. Aber er wartet, bis der Hauptinhalt erscheint. Wenn dein Hero-Bild 4 Megabyte gross ist und du es nicht für das Web optimiert hast, sitzt der Crawler untätig da, während das Bild lädt. Wenn das Bild fertig geladen ist, bist du schon über dem Timeout des Crawlers.
Häufige Ursachen für langsames LCP sind zu grosse Bilder ohne Komprimierung, nicht optimierte eingebettete Videos, die das Rendern blockieren, Webschriften, die nicht auf die nötigen Zeichen reduziert sind und nicht schnell laden, und Skripte von Drittanbietern, die oberhalb des sichtbaren Bereichs rendern. Jedes davon fügt dem LCP Sekunden hinzu.
Die Lösung ist nicht, länger zu warten. Die Lösung ist, dass LCP schneller passiert. Das heisst: Bilder optimieren, Inhalte unterhalb des sichtbaren Bereichs verzögert laden (Lazy Loading), Skripte asynchron laden und gegebenenfalls schwere eingebettete Elemente von Drittanbietern durch statische HTML-Alternativen ersetzen.
Interaction to Next Paint (INP): Leistung bei der Ausführung von JavaScript
INP misst die Reaktionsfähigkeit. Wenn ein Nutzer (oder ein Crawler, der einen Nutzer simuliert) mit der Seite interagiert, wie lange dauert es, bis sich auf dem Bildschirm etwas ändert? Das Ziel liegt unter 200 Millisekunden.
Bei KI-Crawlern zeigt INP, ob dein JavaScript optimiert oder aufgebläht ist. Ein schlechter INP-Wert zeigt, dass auf deiner Seite zu viel Code im Hauptthread läuft oder dass Code nicht richtig in Teile zerlegt und verzögert geladen wird.
Crawler, die Interaktion simulieren, tun das, um dynamische Inhalte herauszuziehen. Wenn deine Seite statisches HTML lädt, aber auf JavaScript angewiesen ist, um Formulare, bedingte Inhalte oder interaktive Elemente zu rendern, muss der Crawler dieses JavaScript ausführen. Wenn das JavaScript langsam ist, bekommt der Crawler einen schlechten INP-Wert und stuft deine Seite als ineffizient ein.
Das versteckte Problem beim Rendern im Client ist, dass die meisten KI-Crawler JavaScript gar nicht rendern. Untersuchungen zeigen, dass statisches HTML mit Schema-Markup eine Erfolgsquote von 94 % beim Auslesen erreicht, während mit JavaScript gerenderte Inhalte bei 23 % liegen. Das heisst: Wenn deine Inhalte hinter JavaScript versteckt sind, sehen KI-Crawler sie womöglich nie.
Wenn deine Website das Rendern im Client nutzt, wird das Problem mit INP zu einem Problem der Sichtbarkeit. Der Crawler kann nicht warten, bis JavaScript ausgeführt ist, also überspringt er Inhalte, die von JavaScript abhängen.
Cumulative Layout Shift (CLS): Stabilität beim Herausziehen
CLS misst visuelle Instabilität. Wenn sich Elemente der Seite beim Laden bewegen, steigt der Cumulative Layout Shift. Das Ziel liegt unter 0,1.
Für Crawler geht es bei CLS nicht um die Nutzererfahrung. Es geht um die Genauigkeit beim Auslesen. Wenn sich das DOM verschiebt, während der Crawler Inhalte herauszieht, greift er womöglich die falschen Elemente. Eine Überschrift kann in den Platz einer anderen rutschen. Eine Seitenleiste kann den Hauptinhalt aus der Position drücken. Der Crawler zieht den Text heraus, der an einer Position steht, nicht den Text, der logisch dorthin gehört.
Häufige Ursachen für hohen CLS sind Werbeflächen, die spät laden und Inhalte nach unten drücken, Bilder ohne festgelegte Masse, die laden und das Layout verschieben, Webschriften, die getauscht werden und den Abstand verändern, und Karussells, die automatisch laufen und Inhalte verschieben. Jedes davon lässt das Layout wandern.
Die Lösung ist, Platz für alles zu reservieren, was noch lädt. Lege Masse für Bilder im HTML fest. Setze font-display auf swap, damit Schriften das Rendern nicht blockieren. Lade Werbung und dynamische Inhalte in reservierten Containern, die keine Verschiebungen im Layout auslösen.
So optimierst du für die Geschwindigkeit von KI-Crawlern
Die Optimierung der Geschwindigkeit für KI-Crawler unterscheidet sich von der für Menschen. Nutzer achten darauf, wann sie die Seite sehen und wann sie damit interagieren können. Crawler achten darauf, wann der Server antwortet und ob alle Inhalte fertig gerendert werden.
Beginne mit TTFB. Wenn dein Server mehr als 500 Millisekunden zur Antwort braucht, zählt nichts anderes. Prüfe deine Datenbankabfragen, wechsle zu einem schnelleren Hosting-Anbieter, setze Caching auf Ebene der Anwendung ein oder nutze ein CDN. Die Investition in TTFB zahlt sich sofort bei der Abdeckung durch Crawler aus.
Optimiere Bilder. Jedes Bild auf deiner Seite sollte komprimiert, auf die angezeigte Grösse verkleinert und in modernen Formaten wie WebP mit PNG als Ersatz ausgeliefert werden. Nutze dafür ein Tool zur Bildkomprimierung. Nutze für Hero-Bilder ein CDN mit automatischer Optimierung.
Verzögere nicht kritisches JavaScript. Lade nur JavaScript, das unbedingt nötig ist, damit der Crawler Inhalte sieht. Skripte, die Analysen erfassen, Werbung laden oder interaktive Funktionen antreiben, sollten verzögert oder asynchron geladen werden. So bleibt der Hauptthread frei und die Ausführung schnell.
Rendere kritische Inhalte auf dem Server. Wenn deine Website ein Framework für den Client nutzt, rendere den kritischen Pfad auf dem Server und aktiviere ihn im Client. So sehen Crawler Inhalte sofort. Noch besser ist statische Generierung der Website (SSG): Baue deine Seiten beim Deployment zu HTML.
Vermeide grosse eingebettete Elemente von Drittanbietern. Wenn du YouTube-Player, Audio-Player oder grosse externe Widgets einbettest, blockieren sie das Rendern. Ersetze sie durch Platzhalter, die erst beim Klick geladen werden, oder ziehe die wesentlichen Informationen in statisches HTML.
Reserviere Platz für dynamische Inhalte. Lege feste Masse für Bilder, Werbung und dynamische Bereiche fest. Das verhindert Verschiebungen im Layout und stellt sicher, dass der Crawler die richtigen Inhalte herauszieht.
Nutze ein CDN. Ein Content Delivery Network leitet Anfragen an den geografisch nächsten Server weiter und senkt Latenz und TTFB. Die meisten CDNs bieten auch automatische Optimierung und Komprimierung von Bildern.
Was WEMASY für Geschwindigkeit und die Optimierung für Crawler bietet
Der Website-Builder von WEMASY enthält Hosting mit automatischem CDN-Caching, Optimierung von Bildern beim Hochladen und serverseitiges Rendern aller Inhalte der Website. Mit WEMASY gebaute Seiten erfüllen die Standards der Core Web Vitals standardmässig.
Wenn du eine Website mit WEMASY veröffentlichst, ist dein TTFB über unser CDN optimiert, deine Bilder werden automatisch verkleinert und komprimiert, und dein HTML wird als statische Seiten ausgeliefert, nicht auf Abruf erzeugt. Das heisst, KI-Crawler sehen deine Inhalte sofort, ohne auf Rendern oder Verarbeitung zu warten.
Das ist in den WEMASY-Tarifen enthalten.
Häufig gestellte Fragen
Beeinflusst die Geschwindigkeit der Seite KI-Zitate stärker als klassisches SEO?
KI-Crawler reagieren empfindlicher auf Geschwindigkeit, weil sie unter engeren Zeitgrenzen arbeiten. Klassische Crawler von Google können 10 Sekunden auf das Laden einer Seite warten. KI-Crawler laufen meist nach 3 bis 5 Sekunden in ein Timeout. Beim klassischen SEO ist Geschwindigkeit ein Rankingsignal. Bei GEO ist sie eine Schwelle. Wenn du sie nicht schaffst, gibt es gar keine Zitate. Mit dem Website-Builder von WEMASY richtest du das direkt auf deiner Website ein.
Woher weiss ich, ob mein TTFB für KI-Crawler schnell genug ist?
Nutze Google PageSpeed Insights (führe es so aus, als wäre es ein Crawler, indem du die Desktop-Version prüfst). Achte auf TTFB unter 500 ms. Ist er höher, musst du dein Hosting, deine Datenbank oder deinen Code der Anwendung untersuchen. Auch andere kostenlose Tools zum Testen der Geschwindigkeit zeigen TTFB. Wenn dein TTFB dauerhaft über 600 ms liegt, wende dich an deinen Hosting-Anbieter oder erwäge einen Wechsel zu einem schnelleren Anbieter.
Sollte ich Core Web Vitals optimieren, wenn ich klassische Rankings bei Google nicht verfolge?
Ja. Core Web Vitals beeinflussen die Sichtbarkeit in der KI direkt. Studien zeigen, dass 85 % der Websites, die KI-Plattformen zitieren, alle drei Schwellenwerte der Core Web Vitals erfüllen. Selbst wenn Rankings bei Google für dein Geschäft keine Rolle spielen, tut es die Sichtbarkeit in der KI. Die Optimierung ist dieselbe.
Lohnt sich der Wechsel zu einem schnelleren Hosting-Anbieter nur wegen der Core Web Vitals?
Wenn dein aktueller TTFB über 600 ms liegt, ja. Der Preisunterschied zwischen einfachem und schnellem Hosting liegt meist bei 5 bis 15 $ pro Monat. Der ROI aus besseren KI-Zitaten und Abdeckung durch Crawler ist deutlich höher. Schnelles Hosting verbessert auch Nutzererfahrung und Conversion-Raten, nicht nur die Crawlbarkeit.
Verbessert Caching die Core Web Vitals?
Caching ist unverzichtbar. Caching im Browser sagt den Browsern der Besucher, Bilder und statische Dateien lokal zu speichern, damit sie nicht erneut geladen werden müssen. Caching auf dem Server speichert fertig gerenderte Seiten im Speicher, damit sie nicht von Grund auf neu gebaut werden müssen. Beides senkt TTFB und LCP deutlich. Setze Header für das Caching konsequent ein und nutze ein CDN mit automatischem Caching.
Schadet die Optimierung der Geschwindigkeit für KI-Crawler der Nutzererfahrung?
Nein. Optimierungen für Crawler, also schnellere Server, Komprimierung von Bildern und verzögertes Laden von JavaScript, verbessern die Nutzererfahrung auf ganzer Linie. Seiten, die für Crawler schneller laden, laden auch für Menschen schneller. Die einzige Ausnahme: Du optimierst rein für Crawler und entfernst Bilder oder kürzt Inhalte, was Nutzern schaden würde. Tu das nicht. Optimiere für Geschwindigkeit, ohne Wert zu entfernen.