Ladezeit und Core Web Vitals für KI und Suchmaschinen verbessern

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

Die Ladezeit beschreibt, wie schnell eine Seite Inhalt zeigt und auf Eingaben reagiert. Google misst das mit den Core Web Vitals, derzeit drei Kennzahlen:

Die Schwellen stammen aus Googles Übersicht Web Vitals auf web.dev. Bewertet wird das 75. Perzentil der echten Seitenaufrufe, getrennt nach Smartphone und Desktop. Eine Seite besteht, wenn alle drei Kennzahlen im guten Bereich liegen.

Im Google-Ranking sind die Core Web Vitals ein Signal unter vielen, und eine gute Seitenerfahrung ersetzt laut Google keinen guten Inhalt. Für KI-Assistenten sind keine vergleichbaren Schwellen veröffentlicht. Dort kommt es zuerst darauf an, dass ein Crawler Ihre Seite abrufen und lesen kann.

Wie messen Sie Ladezeit und Core Web Vitals, bevor Sie etwas ändern?

Es gibt zwei Datenarten. Felddaten stammen von echten Besuchern und bilden die Grundlage der Google-Bewertung. Labordaten entstehen in einem simulierten Abruf, etwa in Lighthouse, und zeigen reproduzierbar, woran es liegt.

1. Öffnen Sie in der Search Console den Bericht „Core Web Vitals“. Er gruppiert URLs mit ähnlichem Problem und trennt Smartphone und Desktop.
2. Prüfen Sie je Seitentyp eine typische URL in PageSpeed Insights. Oben stehen die Felddaten, darunter die Laborwerte mit Hinweisen.
3. Halten Sie Datum, URL, Gerätetyp und die drei Werte fest. Ohne Ausgangslage lässt sich später keine Verbesserung belegen.
4. Beheben Sie einen Engpass nach dem anderen, zuerst auf einer Testumgebung, und messen Sie im Labor nach.
5. Beobachten Sie nach dem Livegang die Felddaten. Sie bilden sich über ein gleitendes Fenster von 28 Tagen und ziehen deshalb langsam nach.

Seiten mit wenigen Aufrufen haben oft keine Felddaten. Dann bleiben nur Labordaten, die Sie als Näherung lesen.

Was bremst eine Seite am häufigsten, und was hilft dagegen?

LCP: Der größte Inhalt erscheint zu spät

• Langsame Serverantwort: Als Richtwert nennt Google höchstens 0,8 Sekunden bis zum ersten Byte (TTFB). Caching und ein schlanker Seitenaufbau helfen.
• Zu großes Hauptbild: Liefern Sie es in der angezeigten Größe und in einem modernen Format wie WebP oder AVIF.
• Verzögertes Laden des Hauptbilds: Ein Bild im sichtbaren Bereich gehört nicht ins Lazy Loading. Das Attribut fetchpriority mit dem Wert high markiert es als wichtig.

INP: Die Seite reagiert zäh

• Skriptaufgaben, die länger als 50 Millisekunden am Stück laufen, blockieren Eingaben. Zerlegen Sie schweren Code oder laden Sie ihn erst bei Bedarf.
• Drittanbieter-Skripte wie Chat-Widgets oder Tracker prüfen Sie einzeln auf ihren Nutzen. Was nicht gebraucht wird, entfernen oder verzögern Sie.

CLS: Inhalte springen

• Bilder, Videos und Einbettungen brauchen feste Breite und Höhe oder ein Seitenverhältnis.
• Nachladende Schriften verschieben Text. Die Angabe font-display und eine ähnlich große Ersatzschrift mildern das.
• Cookie-Banner und Einblendungen, die Inhalt nach unten drücken, bekommen reservierten Platz oder liegen über der Seite.

Beginnen Sie bei dem Seitentyp mit dem schlechtesten Wert. Eine Korrektur an der Vorlage wirkt auf alle Seiten dieses Typs. Weitere Hinweise stehen im Ratgeber Ladezeit und Core Web Vitals: Best Practices.

Was haben Ladezeit und KI-Crawler miteinander zu tun?

Beim Zugriff gilt: Eine Seite, die ein Crawler nicht abrufen oder lesen kann, kommt nicht als abgerufene Quelle vor.

• Antwortzeit und Statuscodes: Google senkt bei Serverproblemen die Abrufrate seines Crawlers. Ob andere Anbieter ähnlich reagieren, lässt sich nicht pauschal sagen. Dauerhafte 5xx-Fehler und Zeitüberschreitungen sollten Sie in jedem Fall beheben.
• JavaScript: Nicht jeder Crawler führt JavaScript aus. Texte, Tabellen und Preise, die erst im Browser nachgeladen werden, fehlen dann im abgerufenen HTML. Über „Seitenquelltext anzeigen“ sehen Sie, was ein Crawler ohne Skriptausführung erhält.
• Bot-Schutz: Firewalls und CDN-Regeln weisen unbekannte Bots mitunter ab. Das Server-Log zeigt, welche Crawler welche Statuscodes bekommen.
• robots.txt: Die Regeln gelten je Crawler. Prüfen Sie, ob ein Eintrag versehentlich einen Anbieter aussperrt, etwa OAI-SearchBot (Suche in ChatGPT) oder Claude-SearchBot (Claude).

Bei Google AI Overviews muss die Seite laut Googles Dokumentation zu KI-Funktionen im Google-Index stehen und mit Textauszug anzeigbar sein. Zusätzliche technische Anforderungen nennt Google nicht.

Zum Aufbau einer llms.txt gibt es eine eigene Anleitung zur llms.txt. Eine Nennung in KI-Antworten folgt daraus nicht.

Wie funktioniert der Kreislauf aus Messung, Arbeitspaket und Freigabe bei Smart2Index?

Wir messen jede Woche 12 Käuferfragen auf ChatGPT, Perplexity, Gemini, Claude und Google AI Overviews sowie bei Google. Microsoft Copilot messen wir nicht, wir optimieren zusätzlich dafür. Die Messwerte sind Stichproben, weil KI-Antworten je nach Zeitpunkt, Modellversion, Standort und Kontext schwanken.

Für die Umsetzung brauchen wir Zugang zu Ihrer Seite, zur Search Console und zu Analytics, nach einer kurzen Checkliste. Danach legen wir Ihnen jeden Tag ein Arbeitspaket vor, höchstens 30 im Monat: Seite, Text, Rechner oder Korrektur. Dazu gehören On-Page- und Speed-Fixes für Titel, Beschreibungen, strukturierte Daten und Ladezeit. Der Indexierungs-Wächter prüft täglich Statuscodes, noindex, Canonical, Sitemap und KI-Crawler.

Sicherheitsthemen wie Security-Header oder TLS gehören zu Smart2Security aus der Smart2-Familie. Wer zuerst wissen möchte, wo die eigene Firma steht, trägt im kostenlosen KI-Check eine Käuferfrage und die Domain ein. Das Ergebnis kommt innerhalb eines Werktags per E-Mail.

Wann braucht eine Ladezeit-Korrektur einen Fakten-Check?

Zu unseren On-Page- und Speed-Fixes zählen neben der Ladezeit auch Titel, Beschreibungen und strukturierte Daten, und dort stehen Firmenname, Zahlen und mitunter Fristen. Strukturierte Daten sollen laut Google den sichtbaren Inhalt der Seite abbilden. Eine falsche Angabe steht dann im sichtbaren Text und in den strukturierten Daten. Was in Titel und Beschreibung gehört, erklärt der Ratgeber zu Meta Title und Meta Description. Den Aufbau von Article- und FAQPage-Markup zeigt der Ratgeber zu Schema.org JSON-LD.

Bei Smart2Index stehen Ihre Firmenfakten in einem Fakten-Register. Ein Prüfprogramm vergleicht jeden Text vor der Auslieferung mit diesem Register und hält Abweichungen bei Preisen, Zahlen, Fristen und Firmennamen auf. Danach sieht ein Mensch jede Änderung durch. Mit Ihrer Freigabe übernehmen Sie die Verantwortung für die Richtigkeit des veröffentlichten Inhalts (AGB D5.3).

Ein reiner Speed-Fix ändert den sichtbaren Inhalt nicht und ist deshalb in der Regel kein Anlass für ein neues Änderungsdatum. Wann ein solches Datum gerechtfertigt ist, steht im Ratgeber zu Update-Signalen und dateModified.

Wie laufen Freigabe, Rückbau und Montags-Report ab?

Jedes Arbeitspaket kommt fertig zu Ihnen, mit Beleg und Prüfsiegel, und Sie sehen Vorher und Nachher nebeneinander. Sie entscheiden mit einem Klick. Erst nach Ihrer Freigabe geht eine Änderung live.

Speed-Fixes laufen jeweils mit Rückbauplan: Wir setzen die Änderung auf Ihrer Website um und sichern vorher den alten Stand, damit wir sie jederzeit zurückbauen können. Das Backup Ihrer Website stellen Sie selbst (AGB D6.2), den Rückbau übernimmt unser Team.

Jeden Montag zeigt der Report als PDF, was live ging, wie sich Rankings und KI-Nennungen verändert haben und was als Nächstes kommt. Die Felddaten der Core Web Vitals bilden sich über 28 Tage. Suchmaschinen und KI-Assistenten lesen geänderte Seiten außerdem erst nach und nach ein, deshalb beträgt die Mindestlaufzeit drei Monate. Die Laufzeiten stehen unter Angebot. Eine bestimmte Nennung, Platzierung oder Besucherzahl sagen wir nicht zu (AGB D2.2).

Häufige Fragen von Entscheidern

Wie lange dauert es, bis sich eine Korrektur im Core-Web-Vitals-Bericht zeigt?

Rechnen Sie mit etwa vier Wochen oder etwas mehr: Die Felddaten bilden sich über ein gleitendes Fenster von 28 Tagen, deshalb verschwinden alte schlechte Werte nur allmählich. In der Search Console können Sie nach einer Korrektur die Validierung starten. Google prüft dann bis zu 28 Tage lang, ob die Werte im guten Bereich bleiben.

Muss eine Seite alle drei Kennzahlen bestehen?

Ja, für die Bewertung „bestanden“ müssen LCP, INP und CLS jeweils im guten Bereich liegen. In der Search Console richtet sich der Status einer URL-Gruppe nach der schwächsten Kennzahl. Ein guter LCP gleicht einen schlechten INP deshalb nicht aus. Prüfen Sie alle drei Werte und beginnen Sie bei der schwächsten.

Brauche ich für KI-Crawler eine eigene, schnelle Version meiner Seite?

Nein. Crawlern anderen Inhalt zu zeigen als Besuchern gilt bei Google als Cloaking und verstößt gegen die Spam-Richtlinien. Sinnvoll ist eine einzige Seite, deren wesentlicher Inhalt schon im ausgelieferten HTML steht und die schnell antwortet.

Reicht ein Plug-in für Caching und Bildkomprimierung?

Für den LCP oft teilweise, für INP und CLS meist nicht: Ein Plug-in kann Serverzeit und Bildgrößen verbessern und damit den LCP. INP und CLS hängen oft an Skripten, Schriften und Layout, die ein Plug-in nicht automatisch löst. Messen Sie deshalb vor und nach der Aktivierung mit denselben URLs und prüfen Sie, ob sich der Wert tatsächlich verändert hat.

Soll ich zuerst die Werte für Smartphone oder für Desktop verbessern?

In der Regel zuerst Smartphone. Google verwendet für Indexierung und Ranking die mobile Version einer Seite (Mobile-First-Indexierung), und mobil sind die Werte meist schwächer. Die Search Console zeigt beide Gerätetypen getrennt. Beginnen Sie mit dem Bericht, in dem mehr URLs als „Schlecht“ oder „Optimierung erforderlich“ stehen, und prüfen Sie danach den anderen.