Core Web Vitals und Latenz: Erhalten schnellere Seiten mehr KI-Zitate?

Core Web Vitals und Latenz: Erhalten schnellere Seiten mehr Künstliche Intelligenz Zitate?

Einleitung

Eine schnelle Website ist für Menschen einfacher zu bedienen. Sie könnte auch für Suchmaschinen und KI-Systeme einfacher abzurufen, zu rendern und zu verstehen sein.

Doch eine wichtige Unterscheidung wird oft übersehen:

Eine schnellere Seite kann das Crawling und die Verfügbarkeit von Inhalten verbessern. Das bedeutet jedoch nicht, dass Geschwindigkeit allein dazu führt, dass ein KI-System die Seite zitiert.

Stand 2. August 2026 gibt Google an, dass stabile Server-Antwortzeiten und geringere Latenz die Crawl-Kapazität einer Website erhöhen können. Google erklärt auch, dass seine KI-Suchfunktionen dieselben grundlegenden Such- und Indexierungssysteme wie die traditionelle Suche verwenden und keine spezielle KI-Auszeichnung oder Geschwindigkeitsoptimierungen erfordern. (developers.google.com)

Dieser Artikel präsentiert einen evidenzbasierten Testplan, anstatt zu behaupten, dass ein abgeschlossenes Experiment bereits durchgeführt wurde. Es wurden keine Website, Seitenmenge, Serverprotokolle oder Zitationsdatensätze bereitgestellt. Ziel ist es, eine kontrollierte Studie zu definieren, die messen kann:

1. Ob ein geringeres Time to First Byte (Zeit bis zum ersten Byte) die Crawling-Frequenz erhöht.
2. Ob ein geringeres Largest Contentful Paint (Größtes Inhaltliches Element) die Entdeckung oder Indexierung verbessert.
3. Ob ein geringeres Cumulative Layout Shift (Kumulative Layout-Verschiebung) das Crawling oder den Abruf durch KI beeinflusst.
4. Ob Leistungsverbesserungen die Rate erhöhen, mit der Seiten von KI-Suchsystemen sichtbar zitiert werden.

Die kurze Antwort

Ein geringeres Time to First Byte kann das Crawling unter den richtigen Bedingungen verbessern

Googles aktuelle Crawl-Dokumentation besagt, dass die Crawl-Kapazitätsgrenze erhöht werden kann, wenn eine Website stabile oder verbesserte Antwortzeiten, einschließlich Time to First Byte, aufweist. Wenn die Antwortzeiten steigen oder eine Website zu viele Serverfehler oder Rate-Limit-Antworten zurückgibt, kann Google das Crawling reduzieren. (developers.google.com)

Eine schnellere Antwortzeit garantiert jedoch nicht mehr Crawling. Die Crawl-Nachfrage hängt auch von Faktoren ab wie:

• Wie oft sich die Website ändert.
• Wie beliebt die Website und ihre Seiten sind.
• Ob der Inhalt nützlich und einzigartig ist.
• Wie viele doppelte oder minderwertige URLs existieren.
• Ob aktualisierte URLs in Sitemaps enthalten sind.

Dies bedeutet, dass eine geringere Latenz den stärksten Effekt auf große, häufig aktualisierte oder serverbeschränkte Websites haben sollte, nicht unbedingt auf eine kleine Website mit begrenzten neuen Inhalten.

Ein geringeres Largest Contentful Paint kann indirekt helfen

Largest Contentful Paint misst, wann der Hauptinhalt für einen Benutzer sichtbar wird. Google gibt auch an, dass sowohl die Server-Antwortzeit als auch die Zeit, die zum Rendern von Seiten und eingebetteten Ressourcen erforderlich ist, die Crawling-Effizienz beeinflussen können. (developers.google.com)

Die wahrscheinliche Beziehung ist indirekt:

Geringere Latenz → schnellere Ressourcenlieferung → effizienteres Rendering oder Abrufen → weniger Crawl-Timeouts oder unvollständige Abrufe.

Der Effekt sollte am stärksten sein, wenn wichtige Inhalte abhängen von:

• Langsamem JavaScript.
• Großen Bildern.
• Render-blockierenden Stylesheets.
• Client-seitigem Rendering.
• Stark eingebetteten Ressourcen.

Ein schneller Largest Contentful Paint Score allein ist wahrscheinlich kein direktes KI-Zitationssignal.

Ein geringeres Cumulative Layout Shift hat wahrscheinlich wenig direkten Crawling-Effekt

Cumulative Layout Shift misst unerwartete Bewegungen des sichtbaren Inhalts. Es ist hauptsächlich eine Benutzererfahrungsmetrik. Häufige Ursachen sind Bilder ohne Abmessungen, dynamisch eingefügte Werbung, eingebettete Inhalte und Web-Fonts. (web.dev)

Ein Crawler erfährt eine Layout-Verschiebung nicht auf die gleiche Weise wie ein menschlicher Besucher. Daher ist eine direkte Beziehung zwischen einem geringeren Cumulative Layout Shift und mehr Crawling unwahrscheinlich.

Es kann eine indirekte Beziehung bestehen, wenn eine hohe Layout-Verschiebung verursacht wird durch:

• Inhalte, die spät durch JavaScript eingefügt werden.
• Wichtiger Text, der erst nach Ausführung von Skripten sichtbar wird.
• Bilder oder eingebettete Inhalte, die den Seitenaufbau verzögern.
• Instabile Vorlagen, die bei verschiedenen Abrufen unterschiedliche Inhalte erzeugen.

In diesen Fällen ist das eigentliche Problem nicht der Layout-Verschiebungswert. Das eigentliche Problem ist, dass die Seite möglicherweise schwer zu verarbeiten ist oder wichtige Inhalte zu spät sichtbar macht.

Schnellere Seiten werden nicht automatisch häufiger zitiert

Google sagt, dass Seiten, die in KI-Funktionen erscheinen, zuerst indexiert und berechtigt sein müssen, in normalen Suchergebnissen mit einem Snippet zu erscheinen. Google sagt auch, dass es keine zusätzlichen technischen Anforderungen oder spezielle KI-Optimierungen für seine KI-Übersichten und den KI-Modus gibt. (developers.google.com)

OpenAI erklärt ebenfalls, dass die ChatGPT-Suchrankings von mehreren Faktoren abhängen und dass die Zulassung ihres Such-Crawlers, OAI-SearchBot, für die Aufnahme wichtig ist. Es wird nicht angegeben, dass niedrigere Core Web Vitals die Zitationswahrscheinlichkeit direkt erhöhen. (help.openai.com)

Dies deutet auf ein vierstufiges Modell hin:

1. Entdeckung — Erfährt das System, dass die URL existiert?
2. Abruf und Verarbeitung — Kann das System die Seite abrufen und verstehen?
3. Indexierung und Abruf — Wird die Seite für eine bestimmte Abfrage ausgewählt?
4. Zitationsauswahl — Wird die Seite als sichtbare Quelle in der Antwort angezeigt?

Die Seitengeschwindigkeit kann die ersten beiden Stufen beeinflussen. Sie ist nicht als direkte Ursache der vierten Stufe etabliert.

Jüngste Forschungsergebnisse zeigen auch, dass KI-Systeme viele relevante Seiten lesen, aber nur einige davon zitieren. Mit anderen Worten: Abruf und Zitation sind separate Ereignisse. (cambridge.org)

Was sollte getestet werden?

Die Studie sollte zwei verschiedene Fragen testen, anstatt „KI-Sichtbarkeit“ als eine einzige Metrik zu behandeln.

Frage 1: Beeinflusst die Leistung das Crawling?

Primäre Ergebnisse:

• Zeit von der Veröffentlichung bis zur ersten Crawler-Anfrage.
• Anzahl der Crawler-Anfragen pro Seite pro Tag.
• Zeit zwischen erfolgreichen erneuten Crawls.
• Anzahl der gecrawlten Seiten pro 1.000 veröffentlichten Seiten.
• Prozentsatz erfolgreicher Abrufe.
• Rate der Serverfehler und Rate-Limit-Antworten.
• Zeit von der Veröffentlichung bis zur Indexierung.

Frage 2: Beeinflusst die Leistung die Zitationsauswahl?

Primäre Ergebnisse:

• Prozentsatz der getesteten Abfragen, die eine sichtbare Zitation erzeugen.
• Zitationsrate pro berechtigter Seite.
• Zitationsanteil innerhalb einer Abfrage.
• Prozentsatz der abgerufenen Seiten, die zu sichtbaren Zitaten werden.
• Zitationspersistenz über die Zeit.
• Zitationsrate nach KI-System.

Diese Ergebnisse müssen nach Anbieter getrennt werden. Eine Google KI-Übersicht, ein ChatGPT-Suchergebnis, eine Microsoft Copilot-Antwort, eine Perplexity-Antwort und eine Claude-Suchantwort können unterschiedliche Indizes, Crawler, Ranking-Systeme und Aktualisierungspläne verwenden.

Experimentelles Design

1. Erstellen Sie einen kontrollierten Seitensatz

Verwenden Sie einen ausreichend großen Seitensatz, um aussagekräftige Crawler- und Zitationsdaten zu erzeugen.

Ein praktisches Ausgangsdesign würde umfassen:

• 240 bis 800 Seiten.
• Mindestens 20 Seiten pro Seitenvorlage.
• Drei bis fünf Inhaltskategorien.
• Eine Mischung aus Evergreen- und regelmäßig aktualisierten Seiten.
• Gleiche Anzahl von Seiten in jeder Behandlungsgruppe.

Jede Seite sollte haben:

• Ähnliche HTML-Struktur.
• Ähnliche Inhaltslänge.
• Dasselbe Veröffentlichungssystem.
• Dasselbe interne Verlinkungsmuster.
• Dieselben kanonischen Regeln.
• Dieselbe Sitemap-Behandlung.
• Dieselben robots.txt-Berechtigungen.
• Ein einzigartiges, nützliches Thema.

Erstellen Sie nicht Hunderte von dünnen oder nahezu doppelten Seiten nur für das Experiment. Googles Richtlinien warnen davor, dass doppelte und minderwertige URLs Crawl-Ressourcen verschwenden und die Effizienz einer Website verringern können. (developers.google.com)

Ein Matched-Pair-Design ist nützlich. Paaren Sie beispielsweise Seiten mit ähnlichen:

• Inhaltslänge.
• Themennachfrage.
• Aktualisierungsfrequenz.
• Anzahl der internen Links.
• Anzahl der externen Links.
• Historischer Traffic.
• Suchranking-Position.

Platzieren Sie dann eine Seite jedes Paares in der Kontrollgruppe und die andere in einer Behandlungsgruppe.

2. Verwenden Sie ein faktorielles Behandlungsdesign

Die Hauptleistungsbehandlungen sollten unabhängig voneinander und zusammen getestet werden.

Dies schafft ein kontrolliertes Experiment für die drei angefragten Optimierungen:

• HTTP/3.
• Content Delivery Network Edge-Caching.
• Bildkomprimierung.

Die Behandlung der Layoutstabilität ist notwendig, da die ersten drei Optimierungen Cumulative Layout Shift nicht zuverlässig isolieren. Bildkomprimierung kann Largest Contentful Paint senken, ohne die Layoutstabilität zu verändern.

Warum HTTP/3 eine eigene Messung benötigt

HTTP/3 verwendet das QUIC-Transportprotokoll und bietet unabhängige Streams, wodurch transport-level Head-of-Line-Blocking vermieden werden kann, das in HTTP/2 über TCP gefunden wird. Seine Vorteile hängen davon ab, ob der Client oder Crawler tatsächlich HTTP/3 aushandelt. (rfc-editor.org)

Daher sollte das ausgehandelte Protokoll für jede Anfrage aufgezeichnet werden:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Gehen Sie nicht davon aus, dass die Aktivierung von HTTP/3 bedeutet, dass jeder Crawler es verwendet. Wenn Googlebot, OAI-SearchBot oder ein anderer Crawler weiterhin HTTP/2 verwendet, kann HTTP/3 die Anfragen dieses Crawlers nicht beeinflussen.

Warum Edge-Caching sorgfältig getestet werden sollte

Ein Content Delivery Network kann das Time to First Byte reduzieren, indem es Inhalte näher am Anfragenden bereitstellt. Es kann auch die Anzahl der Anfragen an den Origin-Server reduzieren. (web.dev)

Testen Sie mindestens drei Cache-Zustände:

1. Kalter Cache — Der Edge muss den Origin kontaktieren.
2. Warmer Cache — Der Edge liefert die Seite ohne Kontakt zum Origin.
3. Revalidierter Cache — Der Edge oder Crawler verwendet einen ETag- oder Last-Modified-Wert und erhält eine 304 Not Modified-Antwort.

Google empfiehlt explizit effizientes HTTP-Caching und unterstützt die Verwendung von 304 Not Modified-Antworten, um unnötige Verarbeitung und Bandbreite zu reduzieren. (developers.google.com)

Lassen Sie nicht zu, dass Caching veraltete oder falsche Inhalte an Crawler liefert. Erfassen Sie:

• Cache-Hit oder Miss.
• Cache-Alter.
• Edge-Standort.
• Origin-Antwortzeit.
• Inhaltsversion.
• Statuscode.
• Validierungsheader.

Warum Bildkomprimierung mit Largest Contentful Paint verknüpft sein sollte

WebP und AVIF bieten im Allgemeinen eine bessere Komprimierung als ältere Bildformate. Kleinere Bilder können die Übertragungszeit reduzieren und Largest Contentful Paint verbessern, wenn das Bild das Largest Contentful Paint-Element ist. (web.dev)

Der Test sollte verwenden:

• Dieselben Bildabmessungen.
• Dasselbe visuelle Qualitätsziel.
• Responsive srcset-Bilder.
• Ein modernes Format mit einem geeigneten Fallback.
• Explizite width- und height-Werte.
• Kein Lazy Loading für das Largest Contentful Paint-Bild.
• Eine Bild-URL, die im anfänglichen HTML sichtbar ist.

Bildkomprimierung allein verbessert Largest Contentful Paint möglicherweise nicht, wenn die eigentliche Verzögerung von JavaScript oder einer späten Ressourcenentdeckung herrührt. Googles Leistungsrichtlinien weisen darauf hin, dass die Reduzierung der Bild-Downloadzeit die Verzögerung einfach auf einen anderen Teil der Seite verschieben kann, wenn das Largest Contentful Paint-Element spät enthüllt wird. (web.dev)

3. Führen Sie den Test lange genug durch

Ein kurzer Test kann die Auswirkungen der Crawl-Planung und des Index-Refreshs übersehen.

Ein praktisches Design ist:

• Zwei Wochen Basismessung.
• Sechs bis zwölf Wochen Behandlungszeitraum.
• Eine abschließende Umkehr- oder Crossover-Periode, falls möglich.

Für einen Crossover-Test tauschen Sie die Behandlungen zwischen passenden Seitengruppen. Wenn der Leistungseffekt verschwindet, wenn die Behandlung entfernt wird, ist das Ergebnis stärker als ein einfacher Vorher-Nachher-Vergleich.

Core Web Vitals Felddaten sollten über einen geeigneten Zeitraum ausgewertet werden. Der Chrome User Experience Report verwendet eine rollierende 28-Tage-Aggregation, daher ist er nicht darauf ausgelegt, sofortige Änderungen nach einer Bereitstellung anzuzeigen. (developer.chrome.com)

4. Messen Sie die gesamte Crawler-Population

Behandeln Sie nicht den gesamten automatisierten Traffic als eine Gruppe.

Mindestens trennen Sie:

Such-Crawler

• Googlebot.
• Bingbot.

KI-Such-Crawler

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Vom Benutzer angeforderte Abrufer

• Perplexity-User.
• Claude-User.
• ChatGPT-Benutzer-Abrufer, wo identifizierbar.

Trainings-Crawler

• GPTBot.
• ClaudeBot.
• Google-Extended-Steuerungen.

Trainings-Crawler sollten nicht als Proxy für KI-Suchzitate verwendet werden. Anthropic, OpenAI und Google unterscheiden zwischen Crawlern, die für Training, Suche oder benutzerdefinierte Abrufe verwendet werden. Google gibt auch an, dass Google-Extended die Aufnahme oder das Ranking in der Google-Suche nicht beeinflusst. (help.openai.com)

Perplexity unterscheidet ähnlich zwischen PerplexityBot, der die Suchindexierung unterstützt, und Perplexity-User, der eine Seite als Reaktion auf eine Benutzeranfrage abrufen kann. (docs.perplexity.ai)

Verifizieren Sie die Crawler-Identität anhand veröffentlichter IP-Bereiche oder Reverse DNS, wo der Anbieter dies unterstützt. User-Agent-Strings können von nicht verwandten Crawlern kopiert werden. Google warnt ausdrücklich, dass Googlebot-User-Agent-Strings gefälscht werden können. (developers.google.com)

Zu erfassende Metriken

Performance-Metriken

Sammeln Sie sowohl Labor- als auch Real-User-Daten:

• Time to First Byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Gesamtes Seitengewicht.
• Größe des initialen HTML.
• Bildübertragungsgröße.
• Anzahl der Anfragen.
• Zeit, die für die Serververarbeitung aufgewendet wird.
• Zeit, die auf die Largest Contentful Paint-Ressource gewartet wird.
• HTTP-Protokoll.
• Cache-Status.

Google empfiehlt ein ungefähres Time to First Byte-Ziel von 800 Millisekunden oder weniger, aber Time to First Byte ist selbst kein Core Web Vital. (web.dev)

Die aktuellen „guten“ Core Web Vitals-Schwellenwerte am 75. Perzentil sind:

• Largest Contentful Paint: 2,5 Sekunden oder weniger.
• Cumulative Layout Shift: 0,1 oder weniger.
• Interaction to Next Paint: 200 Millisekunden oder weniger. (web.dev)

Crawl-Metriken

Für jede verifizierte Crawler-Anfrage erfassen Sie:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Berechnen Sie:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

KI-Zitationsmetriken

Verwenden Sie einen festen Satz von Abfragen für jede Plattform. Der Abfragesatz sollte Folgendes enthalten:

• Direkte Sachfragen.
• Vergleichsfragen.
• „Beste“ oder Empfehlungsfragen.
• Fragen, die auf Aktualität reagieren.
• Fragen, bei denen die getestete Seite die stärkste Antwort ist.
• Fragen, bei denen die getestete Seite relevant, aber nicht dominant ist.

Für jede Abfrage erfassen Sie:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Wiederholen Sie Abfragen, da KI-Antworten variieren können. Verwenden Sie einen festen Zeitplan, z. B. dreimal pro Woche, und erfassen Sie Änderungen in der Engine oder dem Modell.

Microsoft Bing Webmaster Tools bietet jetzt einen Bericht zur KI-Leistung, der zitierte Seiten, Grounding-Abfragen und Zitationstrends über unterstützte Microsoft KI-Erfahrungen hinweg anzeigt. Microsoft warnt, dass die Daten aggregiert, Stichproben-basiert und beobachtend sind; sie können nicht beweisen, dass eine bestimmte Seitenänderung eine Zitationsänderung verursacht hat. (bing.com)

Google begann im Juni 2026 ebenfalls mit der Einführung spezieller generativer KI-Leistungsberichte in der Search Console. Die Berichte waren zunächst nur für eine Untergruppe von Websites verfügbar, daher kann der Zugang variieren. (developers.google.com)

Statistische Analyse

Crawling-Frequenz

Verwenden Sie ein gemischtes Zählmodell, wie ein negatives Binomialmodell:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Die Seiten- und Crawler-Effekte sind wichtig, da einige Seiten von Natur aus mehr Aufmerksamkeit erhalten als andere und verschiedene Crawler unterschiedliche Zeitpläne haben.

Entdeckung und Indexierung

Verwenden Sie Überlebensanalyse für:

• Zeit von der Veröffentlichung bis zum ersten Abruf.
• Zeit von der Veröffentlichung bis zur ersten Indexierung.
• Zeit von der Aktualisierung bis zum erneuten Crawl.

Das Hauptergebnis ist nicht einfach, ob eine Seite irgendwann gecrawlt wurde. Es ist, ob die Behandlung die Zeit reduzierte, die benötigt wurde, um die Seite zu finden und zu verarbeiten.

KI-Zitationsauswahl

Verwenden Sie ein hierarchisches logistisches Modell:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Führen Sie zwei separate Modelle aus:

1. Abrufmodell — Wurde die Seite abgerufen oder als Kandidat angezeigt?
2. Zitationsmodell — Wurde die Seite, wenn sie abgerufen wurde, sichtbar zitiert?

Diese Unterscheidung ist essenziell. Eine Leistungsverbesserung, die das Crawling, aber nicht den Abruf erhöht, ist kein KI-Zitationseffekt. Eine Leistungsverbesserung, die den Abruf, aber nicht die Zitationen erhöht, deutet darauf hin, dass die Seite berücksichtigt wird, aber bei der Quellenauswahl verliert.

Erwartete Ergebnisse

Dies sind Arbeitshypothesen, keine behaupteten experimentellen Ergebnisse.

Hypothese 1: Time to First Byte wird den deutlichsten Crawl-Effekt haben

Erwarten Sie eine positive Beziehung zwischen einem geringeren Time to First Byte und der Crawl-Kapazität, wenn:

• Die Website viele Seiten hat.
• Seiten sich oft ändern.
• Der Origin-Server langsam oder überlastet ist.
• Die Website 5xx- oder 429-Antworten zurückgibt.
• Der Crawler signifikante Zeit mit Warten auf Antworten verbringt.

Erwarten Sie wenig messbaren Effekt auf einer kleinen Website mit geringer Crawl-Nachfrage.

Hypothese 2: Largest Contentful Paint wird durch Rendering und Ressourcenbereitstellung wichtig sein

Erwarten Sie, dass ein geringeres Largest Contentful Paint hilft, wenn:

• Die Seite auf Browser-Rendering angewiesen ist.
• Wichtige Inhalte hinter JavaScript liegen.
• Große Bilder oder Stylesheets für die Indexierung erforderlich sind.
• Der Crawler viele Seitenressourcen abruft.
• Die langsamere Behandlung Timeouts oder unvollständiges Rendering verursacht.

Erwarten Sie eine schwache Beziehung, wenn der wichtige Text der Seite bereits im initialen HTML vorhanden ist.

Hypothese 3: Cumulative Layout Shift wird wenig direkten Effekt haben

Erwarten Sie keine bedeutsame direkte Beziehung zwischen Cumulative Layout Shift und Crawl-Frequenz oder Zitationsrate nach Kontrolle von Seitenstruktur und JavaScript-Verhalten.

Wenn Cumulative Layout Shift Zitationen vorherzusagen scheint, untersuchen Sie, ob es als Proxy fungiert für:

• Client-seitiges Rendering.
• Späte Inhaltseinfügung.
• Instabile Werbung.
• Versteckten oder verzögerten Text.
• Schlecht strukturiertes HTML.

Hypothese 4: Geschwindigkeit allein wird nicht zu mehr KI-Zitaten führen

Die stärksten Prädiktoren für die Zitationsauswahl sind wahrscheinlich weiterhin:

• Relevanz zur Abfrage.
• Inhaltsqualität.
• Klare Antworten.
• Aktualität.
• Autorität und Vertrauen.
• Eignung für den Suchindex.
• Abrufrang.
• Ob die Seite die gemachte Behauptung direkt unterstützt.

Googles Richtlinien betonen nützliche, zuverlässige, menschenzentrierte Inhalte und besagen, dass KI-Suchfunktionen auf den bestehenden Such- und Indexierungssystemen basieren. (developers.google.com)

Ein Leistungsbudget, abgestimmt auf KI-Abruf

Das Folgende ist ein vorgeschlagenes Betriebsbudget. Es ist keine veröffentlichte KI-Ranking-Formel.

Googles aktuelle Dokumentation besagt, dass Googlebot die ersten 2 Megabyte einer unterstützten Datei abruft und externe Skripte und Stylesheets separat abruft. Es wird auch empfohlen, wichtige Metadaten und strukturierte Daten früh im HTML zu platzieren. (developers.google.com)

Implementierungsempfehlungen

HTTP/3

Verwenden Sie HTTP/3, wenn es vom Hosting-Anbieter und Content Delivery Network unterstützt wird.

Messen Sie:

• HTTP/3-Aushandlungsrate.
• HTTP/2-Fallback-Rate.
• Verbindungsaufbauzeit.
• Time to First Byte.
• Leistung nach geografischer Region.
• Leistung nach Crawler.

Betrachten Sie HTTP/3 nicht als garantierte Such- oder KI-Optimierung. Es ist eine Transportverbesserung, die nur Clients helfen kann, die sie verwenden.

Content Delivery Network Edge Caching

Für öffentliche, nicht personalisierte Seiten:

• Legen Sie klare Cache-Control-Regeln fest.
• Verwenden Sie langlebiges Caching für versionierte statische Assets.
• Verwenden Sie kurzes, aber nützliches Caching für häufig aktualisiertes HTML.
• Vermeiden Sie Cache-Fragmentierung durch unnötige Abfrageparameter.
• Bewahren Sie kanonische URLs.
• Unterstützen Sie ETag und Last-Modified.
• Testen Sie kalte, warme und revalidierte Cache-Zustände.
• Bestätigen Sie, dass Crawler-Anfragen dieselben wichtigen Inhalte erhalten wie menschliche Anfragen.

Ein Content Delivery Network sollte die Latenz reduzieren, ohne veraltete, inkonsistente oder bot-spezifische Seitenversionen zu erzeugen.

Bildkomprimierung

Für Bilder:

• Verwenden Sie AVIF oder WebP, wenn die visuelle Qualität akzeptabel ist.
• Bieten Sie responsive Bildgrößen an.
• Servieren Sie kein Desktop-Bild auf einem kleinen mobilen Bildschirm.
• Laden Sie das Largest Contentful Paint-Bild nicht lazy-load.
• Fügen Sie Bildabmessungen ein.
• Platzieren Sie das Largest Contentful Paint-Bild im initialen HTML.
• Verwenden Sie fetchpriority="high" nur, wenn angemessen.
• Halten Sie wichtige Erklärungen im Text, anstatt sie nur in Bilder einzubetten.

Bildkomprimierung ist am wertvollsten, wenn das Bild das Largest Contentful Paint-Element ist. Sie behebt keine Seite, deren Hauptverzögerung durch Server-Rendering oder JavaScript-Ausführung verursacht wird. (web.dev)

Layoutstabilität

Um Cumulative Layout Shift zu reduzieren:

• Legen Sie Breiten- und Höhenattribute für Bilder fest.
• Reservieren Sie Platz für Werbung.
• Reservieren Sie Platz für eingebettete Video- und soziale Inhalte.
• Vermeiden Sie das Einfügen von Bannern über bestehendem Text.
• Verwenden Sie stabile Strategien zum Laden von Schriftarten.
• Vermeiden Sie das Ersetzen großer Blöcke von serverseitig gerenderten Inhalten nach dem Seitenladen.

Diese Änderungen verbessern die Benutzererfahrung, auch wenn sie keinen messbaren Effekt auf das Crawling oder die Zitationen haben. (web.dev)

Tools und Überwachung

Performance-Tools

Verwenden Sie:

• Chrome User Experience Report für Core Web Vitals von echten Benutzern.
• Chrome User Experience Report application programming interface für die automatisierte Erfassung von Felddaten.
• PageSpeed Insights für Laboraudits und Felddaten.
• Lighthouse für wiederholbare Labortests.
• Lighthouse Continuous Integration für Pull-Request-Performance-Budgets.
• WebPageTest für Multi-Location-Tests, Cache-Zustände und Protokollvergleiche.
• Chrome DevTools zum Debuggen von Largest Contentful Paint und Layout-Verschiebung.
• Die web-vitals JavaScript-Bibliothek für Real-User-Monitoring.

Die Chrome User Experience Report API bietet aggregierte Felddaten auf Seiten- und Origin-Ebene, einschließlich Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint und experimentellem Time to First Byte. (developer.chrome.com)

Lighthouse Continuous Integration kann Performance-Checks bei jeder Code-Änderung durchführen und Builds fehlschlagen lassen, wenn Budgets überschritten werden. (github.com)

Crawler-Überwachung

Verwenden Sie Serverprotokolle, Edge-Protokolle und einen kleinen Satz synthetischer Sonden.

Beispielsonde:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Führen Sie denselben Test durch mit:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Einem normalen Browser-User-Agent.

Der Test sollte Folgendes überprüfen:

• Statuscode.
• Robots-Berechtigung.
• Antwort-Header.
• HTML-Inhalt.
• HTTP-Version.
• Cache-Status.
• Antwortzeit.
• Ob wichtiger Text ohne JavaScript vorhanden ist.

Such- und Indexierungsüberwachung

Verwenden Sie:

• Google Search Console Crawl-Statistiken.
• Google Search Console Seitenindexierungsberichte.
• Google Search Console URL-Inspektion.
• Google Search Console Sitemap-Daten.
• Google Search Console generative KI-Berichte, wenn verfügbar.
• Bing Webmaster Tools Crawl-Anfragen und indexierte Seiten.
• Bing Webmaster Tools KI-Leistung.
• Tägliche Sitemap- und lastmod-Prüfungen.

Die Search Console API kann Leistungsdaten nach Seite, Abfrage, Datum, Gerät und Sucherscheinung abrufen, vorbehaltlich ihrer Datenbeschränkungen. (developers.google.com)

Zitationsüberwachung

Erstellen Sie ein Zitationspanel, das 50 bis 200 stabile Abfragen pro Thema enthält. Führen Sie das Panel nach einem festen Zeitplan aus und erfassen Sie:

• Ob die Plattform gesucht hat.
• Welche Quellen erschienen sind.
• Ob die getestete URL zitiert wurde.
• Zitationsreihenfolge.
• Datum und Uhrzeit der Antwort.
• Ob sich die Seite geändert hat.
• Ob sich das Modell oder die Sucherfahrung geändert hat.

Vergleichen Sie Zitationszählungen verschiedener Systeme nicht so, als wären sie äquivalent. Microsoft gibt an, dass die Zitationsaktivität kein Ranking-Score, Autoritäts-Score, Traffic-Maß oder Qualitäts-Score ist. (bing.com)

Alarmregeln

Erstellen Sie Warnungen für:

• Time to First Byte steigt um mehr als 25 Prozent.
• Largest Contentful Paint steigt am 75. Perzentil über 2,5 Sekunden.
• Cumulative Layout Shift steigt über 0,1.
• Einen anhaltenden Anstieg von 5xx- oder 429-Antworten.
• Einen Rückgang der Crawler-Erfolgsrate.
• Eine robots.txt-Änderung.
• Einen Sitemap-Fehler.
• Einen plötzlichen Rückgang der indexierten Seiten.
• Einen plötzlichen Rückgang der KI-Zitationen über mehrere Plattformen hinweg.
• Eine Änderung des Zitationsvolumens, die nur eine Plattform betrifft.

Ein Zitationsrückgang, der nur eine Plattform betrifft, kann durch eine Modell-, Index-, Abfrage- oder Produktänderung verursacht werden und nicht durch ein Seitenleistungsproblem. Microsoft warnt ausdrücklich, dass Zitationstrends beobachtend sind und sich aufgrund von Inhaltsaktualisierungen, Benutzernachfrage und System- oder Modelländerungen ändern können. (bing.com)

Fazit

Die haltbarste Schlussfolgerung ist:

Schnellere Seiten können die Crawl-Effizienz verbessern, insbesondere wenn Server-Latenz, Ressourcengröße, Fehler oder Rendering-Verzögerungen limitierende Faktoren sind. Es gibt jedoch derzeit keine starken Beweise dafür, dass niedrigere Core Web Vitals KI-Systeme direkt dazu veranlassen, eine Seite als Zitat auszuwählen.

Die erwartete Kausalkette ist:

text Geringere Latenz → bessere Serverkapazität → weniger fehlgeschlagene oder verzögerte Abrufe → schnellere Entdeckung und Verarbeitung → verbesserte Chance, indexiert und abgerufen zu werden → möglicher Anstieg der Zitationen

Der letzte Schritt bleibt unsicher, da die Zitationsauswahl von Relevanz, Qualität, Aktualität, Autorität, Abfrageabsicht, Abrufrang und dem Verhalten jedes KI-Systems abhängt.

Für die meisten Websites ist die richtige Performance-Strategie daher nicht „für KI-Zitationen isoliert optimieren“. Sie lautet:

1. Wichtige Inhalte im initialen HTML verfügbar halten.
2. Time to First Byte stabil halten.
3. Edge-Caching für öffentliche Inhalte verwenden.
4. Wichtige Bilder komprimieren und priorisieren.
5. Layout-Verschiebungen verhindern.
6. Zuverlässige Statuscodes zurückgeben.
7. Sitemaps und interne Links aktuell halten.
8. Die richtigen Such-Crawler zulassen.
9. Crawling, Indexierung, Abruf und Zitation als separate Stufen messen.

Dieser Ansatz führt zu einer schnelleren Website für Menschen, einer gesünderen Website für Such-Crawler und einer testbaren Grundlage für das Verständnis der KI-Sichtbarkeit.