Zum Inhalt springen
Answer-First

Ladezeit und Core Web Vitals für KI und Suchmaschinen: Best Practices

8 Min. LesezeitStand: Von David, Senior AI Research Scientist
Management-Kurzantwort

Wie wichtig sind Ladezeit und Core Web Vitals für KI und Suchmaschinen?

Google wertet die Core Web Vitals als Teil der Seitenerfahrung, relevante Inhalte wiegen jedoch schwerer. Viele KI-Crawler lesen nur das HTML, das Ihr Server ausliefert; ein direkter Einfluss der Messwerte auf KI-Nennungen ist nicht belegt. In der Regel lohnt sich zuerst eine kurze Serverantwort, dann ein Hauptinhalt, der in höchstens 2,5 Sekunden erscheint (LCP), stabile Layouts (CLS) und schnelle Reaktion auf Eingaben (INP).

  • Gut laut Google: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1.
  • Bewertet wird das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop.
  • Der Googlebot rendert JavaScript, viele KI-Crawler lesen nur das ausgelieferte HTML.
1 weiterer Punkt
  • Felddaten zeigen echte Besuche, Labordaten einen simulierten Test.
Smart2Index Übersichtskarte „Schema.org & llms.txt Setup“ mit den Feldern JSON-LD validiert, AI-Crawler freigegeben und Sitemap aktuell

Die Core Web Vitals LCP, INP und CLS haben feste Grenzwerte, und KI-Crawler stellen eigene Ansprüche an Server und HTML. Wer die Maßnahmen in der richtigen Reihenfolge angeht und vorher wie nachher misst, kann Verbesserungen belegen. Das betrifft B2B-Websites, auf denen Käufer Anbieter prüfen, bevor sie anfragen.

Auf dieser Seite
  1. Management-Kurzantwort
  2. Wie wirken LCP, INP und CLS auf Ranking und KI-Abruf?
  3. Was brauchen KI-Crawler, um Ihre Seiten zu lesen?
  4. Welche Grenzwerte gelten für LCP, INP und CLS?
  5. In welcher Reihenfolge verbessern Sie die Ladezeit?
  6. Welche typischen Fehler verschlechtern die Werte bei B2B-Websites?
  7. Wie messen Sie Ladezeit und Core Web Vitals vorher und nachher?
  8. Wie läuft die Umsetzung bei Smart2Index mit Prüfung und Freigabe ab?
  9. Häufige Fragen von Entscheidern

Wie wirken LCP, INP und CLS auf Ranking und KI-Abruf?

Die Core Web Vitals sind drei Messwerte, mit denen Google die Seitenerfahrung beschreibt. LCP (Largest Contentful Paint) gibt an, wann das größte sichtbare Element geladen ist. INP (Interaction to Next Paint) misst, wie schnell die Seite auf Klicks, Taps und Tastendrücke reagiert. CLS (Cumulative Layout Shift) misst, wie stark Inhalte beim Laden verrutschen. INP hat im März 2024 den früheren Wert FID abgelöst.

Für Google gehören die Werte zu den Signalen der Seitenerfahrung. Relevante Inhalte wiegen nach Googles eigener Darstellung in der Search-Central-Doku zur Seitenerfahrung schwerer. Eine schnelle Seite ohne passende Antwort führt deshalb für sich genommen zu keinem guten Ranking.

Bei ChatGPT, Perplexity, Gemini, Claude und Google AI Overviews ist ein direkter Zusammenhang zwischen Core-Web-Vitals-Werten und Nennungen öffentlich nicht belegt. Die Ladezeit wirkt über eine Vorstufe: Ein Crawler muss Ihre Seite abrufen können, bevor ein Assistent daraus zitieren kann. Antwortet der Server träge oder mit Fehlercodes, kann dieser Abruf lückenhaft bleiben.

Was brauchen KI-Crawler, um Ihre Seiten zu lesen?

Viele KI-Crawler lesen nur das HTML, das der Server ausliefert, und führen kein JavaScript aus. Der Googlebot rendert Seiten dagegen in einem zweiten Schritt. Das kann je nach Anbieter und Zeitpunkt abweichen. Haupttext, Überschriften und Kontaktangaben gehören deshalb ins ausgelieferte HTML.

Ein einfacher Test: Öffnen Sie den Seitenquelltext im Browser und suchen Sie einen Satz aus dem Haupttext. Fehlt er dort, sehen ihn Crawler ohne JavaScript ebenfalls nicht. Danach lassen sich vier Punkte am Server prüfen:

  • Wichtige Seiten liefern den Statuscode 200, ohne 5xx-Fehler und ohne lange Weiterleitungsketten.
  • Die Zeit bis zum ersten Byte (TTFB) liegt laut web.dev zur Time to First Byte als Richtwert unter 0,8 Sekunden.
  • Die robots.txt schließt keine Crawler aus, die Ihre Seiten lesen sollen.
  • Strukturierte Daten stehen als JSON-LD im ausgelieferten HTML, wie es der Ratgeber zu Schema.org-Markup für Article und FAQPage beschreibt.

Eine llms.txt-Datei kann KI-Systemen eine Übersicht Ihrer Inhalte geben. Ob ein System sie auswertet, entscheidet der Anbieter, und eine Nennung folgt daraus nicht.

Welche Grenzwerte gelten für LCP, INP und CLS?

Google teilt jeden Wert in drei Stufen ein; die Grenzwerte stammen aus der Dokumentation zu den Web Vitals auf web.dev. Bewertet wird das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Mindestens drei von vier Besuchen müssen den Grenzwert also einhalten, damit die Seite als gut gilt.

WertGutVerbesserungswürdigSchlechtHäufige Ursache
LCPbis 2,5 Sekunden2,5–4 Sekundenüber 4 Sekundenlangsame Serverantwort, großes Hauptbild, blockierende Skripte
INPbis 200 Millisekunden200–500 Millisekundenüber 500 Millisekundenlange JavaScript-Aufgaben, schwere Drittanbieter-Skripte
CLSbis 0,10,1–0,25über 0,25Bilder ohne Größenangabe, spät eingeblendete Banner

Beim LCP ist das gemessene Element meist ein Bild oder ein großer Textblock am Seitenanfang. CLS hat keine Einheit: Der Wert ergibt sich aus Größe und Verschiebungsstrecke der Elemente, die springen.

In welcher Reihenfolge verbessern Sie die Ladezeit?

Was früh im Ladevorgang passiert, wirkt auf alles Spätere. Die Arbeit beginnt deshalb beim Server und endet bei den Skripten. Eine ergänzende Schrittfolge steht in der Anleitung zu Ladezeit und Core Web Vitals.

  1. Ausgangswerte festhalten: LCP, INP und CLS für die wichtigsten Seitentypen mit Datum notieren, etwa Startseite und Leistungsseite.
  2. Eigene Sicherung der Website anlegen und einen Weg zurück festlegen, bevor Sie an Theme, Plugins oder Server arbeiten.
  3. Serverantwort verkürzen: Seiten-Caching einschalten, statische Dateien über ein Content Delivery Network (CDN) ausliefern und mit Brotli oder gzip komprimieren.
  4. Das LCP-Element beschleunigen: Hauptbild in passender Größe und im Format WebP oder AVIF ausliefern, mit dem Attribut fetchpriority (Wert high) früh laden und nicht mit dem Attribut loading (Wert lazy) verzögern.
  5. Blockierendes entfernen: CSS für den ersten Bildschirm zuerst laden, übrige Skripte mit defer nachladen, Schriften selbst hosten und die CSS-Eigenschaft font-display auf swap setzen.
  6. Layout stabilisieren: Bildern und Videos Breite und Höhe mitgeben, für Banner und Einbettungen feste Platzhalter reservieren.
  7. JavaScript entlasten, um den INP-Wert zu verbessern: Drittanbieter-Skripte prüfen, Aufgaben über 50 Millisekunden aufteilen, Eingabe-Handler kurz halten.
  8. Nach den Schritten 3 bis 7 jeweils erneut messen, bevor Sie den nächsten beginnen, und am Ende die Werte mit den Ausgangswerten aus Schritt 1 vergleichen.

Welche typischen Fehler verschlechtern die Werte bei B2B-Websites?

Bei der Fehlersuche lohnt zuerst der Blick auf diese Stellen:

  • Das Hauptbild wird per Lazy Loading verzögert, obwohl es das LCP-Element ist.
  • Fotos liegen in Originalgröße auf dem Server und werden per CSS verkleinert angezeigt, sodass Besucher mehr Daten laden als nötig.
  • Ein Tag Manager lädt Chat-Widget und Analyse-Skripte, die jeweils eigene Anfragen und Rechenzeit beanspruchen.
  • Ein Cookie-Banner erscheint nach dem Laden, schiebt den Text nach unten (CLS) oder wird selbst zum größten Element (LCP).
  • Der Inhalt entsteht erst im Browser per JavaScript: Besucher sehen die Seite, KI-Crawler ohne JavaScript finden nur ein leeres Grundgerüst.
  • Optimiert wird nur der Lighthouse-Score, während die Felddaten echter Besucher auf schwächeren Geräten und Netzen unbeachtet bleiben.
  • Nach einem Plugin- oder Theme-Update fehlt die Nachmessung, und eine Verschlechterung fällt erst Wochen später auf.

Wie messen Sie Ladezeit und Core Web Vitals vorher und nachher?

Zwei Datenarten ergänzen sich. Felddaten stammen aus echten Besuchen und kommen aus dem Chrome User Experience Report (CrUX). Die Search Console zeigt sie im Bericht zu den Core Web Vitals, PageSpeed Insights neben der Laborauswertung. Labordaten entstehen in einem simulierten Test, etwa mit Lighthouse. Sie liegen sofort vor und lassen sich wiederholen, bilden aber die Geräte und Netze Ihrer Besucher nur grob ab.

Für die Bewertung durch Google zählen die Felddaten. Mit Labordaten prüfen Sie, ob eine einzelne Änderung wirkt, noch bevor genug Besuche vorliegen. Notieren Sie zu jeder Messung Datum, Seite und Gerätetyp, denn Tageszeit, Serverlast und Skripte von Drittanbietern lassen die Werte schwanken. Vergleichen Sie darum mehrere Messungen.

Überarbeiten Sie Seiten auch inhaltlich, gehört ein ehrliches Änderungsdatum dazu, wie es der Ratgeber zu dateModified im Schema Markup beschreibt. Bei rein technischen Speed-Fixes bleibt das Datum stehen, solange sich der Inhalt nicht geändert hat.

Wie läuft die Umsetzung bei Smart2Index mit Prüfung und Freigabe ab?

Die Maßnahmen oben setzt ein internes Team um oder ein externer Anbieter. Wir richten uns an B2B-Unternehmen im Mittelstand, die Messung und Umsetzung von einem Anbieter wollen. Wir messen jede Woche 12 Käuferfragen in ChatGPT, Perplexity, Gemini, Claude und Google AI Overviews sowie bei Google und legen Ihnen jeden Tag ein Arbeitspaket zur Freigabe vor. Ein Arbeitspaket ist eine Seite, ein Text, ein Rechner oder eine Korrektur; es gibt höchstens 30 im Monat. Dazu zählen On-Page- und Speed-Fixes zu Titeln und Beschreibungen, strukturierten Daten und Ladezeit.

Ein Prüfprogramm vergleicht jeden Text vor der Auslieferung mit Ihrem Fakten-Register und hält Abweichungen bei Preisen, Zahlen, Fristen und Firmennamen auf. Danach sieht ein Mensch jede Änderung durch. Erst nach Ihrer Freigabe geht eine Änderung live, und Sie entscheiden mit einem Klick.

Geben Sie ein Arbeitspaket frei, setzen wir die Änderung auf Ihrer Website um und sichern vorher den alten Stand, damit wir sie jederzeit zurückbauen können. Eine eigene Sicherung Ihrer Website bleibt trotzdem sinnvoll. Jeden Montag zeigt ein Report als PDF, was live ging, wie sich Rankings und KI-Nennungen verändert haben und was als Nächstes kommt.

Häufige Fragen von Entscheidern

Wie lange dauert es, bis Verbesserungen in der Search Console sichtbar werden?

Rechnen Sie mit bis zu vier Wochen, bei wenigen Besuchen auch länger. Die Felddaten stammen aus dem Chrome User Experience Report und decken einen gleitenden Zeitraum von 28 Tagen ab; auch die Validierung einer Korrektur im Core-Web-Vitals-Bericht kann bis zu 28 Tage dauern. Labordaten reagieren sofort. Suchmaschinen und KI-Assistenten lesen geänderte Seiten zudem erst nach und nach ein; deshalb beträgt die Mindestlaufzeit bei Smart2Index drei Monate.

Warum zeigt mein Bericht keine Felddaten für einzelne Seiten?

Der Chrome User Experience Report veröffentlicht Werte erst, wenn genug Besuche von Chrome-Nutzern vorliegen, die der Datenweitergabe zugestimmt haben. Bei Seiten mit wenig Verkehr fehlen sie deshalb oft. Dann helfen die Werte der gesamten Domain, Gruppen ähnlicher Seiten in der Search Console und Lighthouse-Messungen im Labor.

Sagen Sie zu, dass schnellere Seiten zu Nennungen in KI-Antworten führen?

Nein. Wir schulden die fachgerechte Durchführung der vereinbarten Analysen, Messungen, Texte und technischen Maßnahmen, jedoch keine bestimmte Nennung, Empfehlungsquote, Platzierung, Indexierung, Besucherzahl oder Anzahl von Anfragen. Die Messwerte sind qualifizierte Stichproben, weil KI-Antworten je nach Zeitpunkt, Modellversion, Standort und Kontext schwanken.

Verlangsamen Schema.org-Markup und eine llms.txt meine Website?

In der Regel kaum: JSON-LD ist ein Textblock im HTML und meist klein im Vergleich zu Bildern und Skripten. Die Datei llms.txt liegt separat auf dem Server und wird nur geladen, wenn ein Crawler sie abruft; Besucher laden sie nicht. Eine Nennung in KI-Antworten folgt aus keinem von beiden automatisch.

Welche Werte zählen mehr, Mobilgeräte oder Desktop?

Arbeiten Sie zuerst an den mobilen Werten. Google bewertet die Core Web Vitals für Mobilgeräte und Desktop getrennt, verwendet aber für Indexierung und Ranking die mobile Version einer Seite, gecrawlt mit dem Smartphone-Agent (Mobile-First-Indexierung). Mobile Besuche laufen zudem oft auf schwächeren Geräten und Netzen, deshalb sind LCP und INP dort meist schlechter.

Sollte ich KI-Crawler sperren, um meinen Server zu entlasten?

Sperren Sie keine Crawler, die Ihre Seiten für Antworten lesen sollen. Wer OAI-SearchBot sperrt, erscheint laut OpenAI nicht in den Suchantworten von ChatGPT; GPTBot für das Training lässt sich getrennt steuern. Auch bei Anthropic kann das Sperren von Claude-SearchBot oder Claude-User Sichtbarkeit kosten. Bei Last helfen eher Caching und ein CDN.

Nach den Speed-Fixes prüfen, ob KI-Assistenten Ihre Firma nennen

Eine schnelle, gut lesbare Seite ist die Voraussetzung. Ob sie genannt wird, zeigt erst die Messung: Der kostenlose KI-Check zeigt innerhalb eines Werktags per E-Mail, wer bei Ihrer Käuferfrage genannt wird und wo Ihre Firma steht. Dafür tragen Sie eine Käuferfrage und Ihre Domain ein.