Latest / Marketing-Automatisierung 2026 / Core Web Vitals und Latenz: Erhalten schnellere Seiten mehr KI-Zitate?

Transcript

Core Web Vitals und Latenz: Erhalten schnellere Seiten mehr KI-Zitate? · Marketing-Automatisierung 2026

• 0:00
  SPEAKER_00: Core Web Vitals und Latenz.
• 0:02
  SPEAKER_00: Erhalten schnellere Seiten mehr künstliche Intelligenzzitate.
• 0:06
  SPEAKER_00: Einleitung.
• 0:07
  SPEAKER_00: Eine schnelle Website ist für Menschen einfacher zu bedienen.
• 0:11
  SPEAKER_00: Sie könnte auch für Suchmaschinen und KI-Systeme einfacher abzurufen, zu rendern und zu verstehen sein.
• 0:17
  SPEAKER_00: Doch eine wichtige Unterscheidung wird oft übersehen.
• 0:20
  SPEAKER_00: Eine schnellere Seite kann das Crawling und die Verfügbarkeit von Inhalten verbessern.
• 0:25
  SPEAKER_00: Das bedeutet jedoch nicht, dass Geschwindigkeit allein dazu führt, dass ein KI-System die Seite zitiert.
• 0:32
  SPEAKER_00: Stand 2.
• 0:33
  SPEAKER_00: August 2026 gibt Google an, dass stabile Server-Antwortzeiten und geringere Latenz die Crawl-Kapazität einer Website erhöhen können.
• 0:43
  SPEAKER_00: 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.
• 0:58
  SPEAKER_00: Dieser Artikel präsentiert einen evidenzbasierten Testplan, anstatt zu behaupten, dass ein abgeschlossenes Experiment bereits durchgeführt wurde.
• 1:06
  SPEAKER_00: Es wurden keine Website-, Seitenmenge, Serverprotokolle oder Zitationsdatensätze bereitgestellt.
• 1:13
  SPEAKER_00: Ziel ist es, eine kontrollierte Studie zu definieren, die messen kann, ob ein geringeres Time-to-First-Byte, Zeit bis zum ersten Byte die Crawling-Frequenz erhöht.
• 1:24
  SPEAKER_00: Ob ein geringeres Largest Contentful Paint, größtes inhaltliches Element, die Entdeckung oder Indexierung verbessert.
• 1:31
  SPEAKER_00: Ob ein geringeres Cumulative Layout-Shift, kumulative Layout-Verschiebung, das Crawling oder den Abruf durch KI beeinflusst.
• 1:39
  SPEAKER_00: Ob Leistungsverbesserungen die Rate erhöhen, mit der Seiten von KI-Suchsystemen sichtbar zitiert werden.
• 1:45
  SPEAKER_00: Die kurze Antwort, ein geringeres Time-to-First-Byte, kann das Crawling unter den richtigen Bedingungen verbessern.
• 1:52
  SPEAKER_00: 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.
• 2:05
  SPEAKER_00: Wenn die Antwortzeiten steigen oder eine Website zu viele Serverfehler oder Rate-Limit-Antworten zurückgibt, kann Google das Crawling reduzieren.
• 2:14
  SPEAKER_00: Eine schnellere Antwortzeit garantiert jedoch nicht mehr Crawling.
• 2:18
  SPEAKER_00: Die Crawl-Nachfrage hängt auch von Faktoren ab wie, wie oft sich die Website ändert.
• 2:23
  SPEAKER_00: Wie beliebt die Website und ihre Seiten sind.
• 2:26
  SPEAKER_00: Ob der Inhalt nützlich und einzigartig ist.
• 2:29
  SPEAKER_00: Wie viele doppelte oder minderwertige URLs existieren.
• 2:33
  SPEAKER_00: Ob aktualisierte URLs in Sitemaps enthalten sind.
• 2:37
  SPEAKER_00: 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.
• 2:50
  SPEAKER_00: Ein geringeres Largest Content for Paint kann indirekt helfen.
• 2:55
  SPEAKER_00: Largest Content for Paint misst, wann der Hauptinhalt für einen Benutzer sichtbar wird.
• 3:00
  SPEAKER_00: 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.
• 3:12
  SPEAKER_00: Die wahrscheinliche Beziehung ist indirekt.
• 3:15
  SPEAKER_00: Geringere Latenz, schnellere Ressourcenlieferung, effizienteres Rendering oder Abrufen, weniger Crawl-Timeouts oder unvollständige Abrufe.
• 3:25
  SPEAKER_00: Der Effekt sollte am stärksten sein, wenn wichtige Inhalte abhängen von langsamem JavaScript, großen Bildern, render blockierenden Style-Sheets, kleinseitigem Rendering, stark eingebetteten Ressourcen.
• 3:39
  SPEAKER_00: Ein schneller Largest Content-Full-Paint-Score allein ist wahrscheinlich kein direktes KI-Zitationssignal.
• 3:46
  SPEAKER_00: Ein geringeres Cumulative Layout Shift hat wahrscheinlich wenig direkten Crawling-Effekt.
• 3:52
  SPEAKER_00: Cumulative Layout Shift misst unerwartete Bewegungen des sichtbaren Inhalts.
• 3:58
  SPEAKER_00: Es ist hauptsächlich eine Benutzererfahrungsmetrik.
• 4:01
  SPEAKER_00: Häufige Ursachen sind Bilder ohne Abmessungen, dynamisch eingefügte Werbung, eingebettete Inhalte und Webfonts.
• 4:09
  SPEAKER_00: Ein Crawler erfährt eine Layout-Verschiebung nicht auf die gleiche Weise wie ein menschlicher Besucher.
• 4:15
  SPEAKER_00: Daher ist eine direkte Beziehung zwischen einem geringeren Cumulative Layout Shift und mehr Crawling unwahrscheinlich.
• 4:22
  SPEAKER_00: Es kann eine indirekte Beziehung bestehen, wenn eine hohe Layout-Verschiebung verursacht wird durch Inhalte, die spät durch JavaScript eingefügt werden.
• 4:31
  SPEAKER_00: Wichtiger Text, der erst nach Ausführung von Skripten sichtbar wird.
• 4:36
  SPEAKER_00: Bilder oder eingebettete Inhalte, die den Seitenaufbau verzögern.
• 4:40
  SPEAKER_00: Instabile Vorlagen, die bei verschiedenen Abrufen unterschiedliche Inhalte erzeugen.
• 4:46
  SPEAKER_00: In diesen Fällen ist das eigentliche Problem nicht der Layout verschiebungswert.
• 4:50
  SPEAKER_00: Das eigentliche Problem ist, dass die Seite möglicherweise schwer zu verarbeiten ist oder wichtige Inhalte zu spät sichtbar macht.
• 4:58
  SPEAKER_00: Schnellere Seiten werden nicht automatisch häufiger zitiert.
• 5:02
  SPEAKER_00: Google sagt, dass Seiten, die in KI-Funktionen erscheinen, zuerst indexiert und berechtigt sein müssen, in normalen Suchergebnissen mit einem Snippet zu erscheinen.
• 5:13
  SPEAKER_00: Google sagt auch, dass es keine zusätzlichen technischen Anforderungen oder spezielle KI-Optimierungen für seine KI-Übersichten und den KI-Modus gibt.
• 5:23
  SPEAKER_00: OpenAI erklärt ebenfalls, dass die Chat-GPT-Suchrankings von mehreren Faktoren abhängen und dass die Zulassung ihres Suchcrawlers OAI SearchBot für die Aufnahme wichtig ist.
• 5:35
  SPEAKER_00: Es wird nicht angegeben, dass niedrigere Core-Webweiters die Zitationswahrscheinlichkeit direkt erhöhen.
• 5:42
  SPEAKER_00: Co.
• 5:42
  SPEAKER_00: Dies deutet auf ein vierstufiges Modell hin.
• 5:45
  SPEAKER_00: Entdeckung erfährt das System, dass die URL existiert.
• 5:50
  SPEAKER_00: Abruf und Verarbeitung.
• 5:51
  SPEAKER_00: Kann das System die Seite abrufen und verstehen?
• 5:55
  SPEAKER_00: Indexierung und Abruf.
• 5:56
  SPEAKER_00: Wird die Seite für eine bestimmte Abfrage ausgewählt?
• 6:00
  SPEAKER_00: Zitationsauswahl.
• 6:01
  SPEAKER_00: Wird die Seite als sichtbare Quelle in der Antwort angezeigt?
• 6:05
  SPEAKER_00: Die Seitengeschwindigkeit kann die ersten beiden Stufen beeinflussen.
• 6:09
  SPEAKER_00: Sie ist nicht als direkte Ursache der vierten Stufe etabliert.
• 6:13
  SPEAKER_00: Jüngste Forschungsergebnisse zeigen auch, dass KI-Systeme viele relevante Seiten lesen, aber nur einige davon zitieren.
• 6:21
  SPEAKER_00: Mit anderen Worten, Abruf und Zitation sind separate Ereignisse.
• 6:26
  SPEAKER_00: Was sollte getestet werden?
• 6:28
  SPEAKER_00: Die Studie sollte zwei verschiedene Fragen testen, anstatt KI-Sichtbarkeit als eine einzige Metrik zu behandeln.
• 6:35
  SPEAKER_00: Frage 1 Beeinflusst die Leistung das Crawling.
• 6:38
  SPEAKER_00: Primäre Ergebnisse.
• 6:40
  SPEAKER_00: Zeit von der Veröffentlichung bis zur ersten Crawler-Anfrage.
• 6:44
  SPEAKER_00: Anzahl der Crawler-Anfragen pro Seite pro Tag.
• 6:47
  SPEAKER_00: Zeit zwischen erfolgreichen erneuten Crawl.
• 6:50
  SPEAKER_00: Anzahl der gecrawlten Seiten pro 1000 veröffentlichten Seiten.
• 6:55
  SPEAKER_00: Prozentsatz erfolgreicher Abrufe.
• 6:57
  SPEAKER_00: Rate der Serverfehler und Ratelimit Antworten.
• 7:01
  SPEAKER_00: Zeit von der Veröffentlichung bis zur Indexierung.
• 7:04
  SPEAKER_00: Frage 2.
• 7:05
  SPEAKER_00: Beeinflusst die Leistung die Zitationsauswahl.
• 7:08
  SPEAKER_00: Primäre Ergebnisse.
• 7:10
  SPEAKER_00: Prozentsatz der getesteten Abfragen, die eine sichtbare Zitation erzeugen.
• 7:15
  SPEAKER_00: Zitationsrate pro berechtigter Seite.
• 7:18
  SPEAKER_00: Zitationsanteil innerhalb einer Abfrage.
• 7:21
  SPEAKER_00: Prozentsatz der abgerufenen Seiten, die zu sichtbaren Zitaten werden.
• 7:25
  SPEAKER_00: Zitationspersistenz über die Zeit.
• 7:27
  SPEAKER_00: Zitationsrate nach KI-System.
• 7:30
  SPEAKER_00: Diese Ergebnisse müssen nach Anbieter getrennt werden.
• 7:34
  SPEAKER_00: Eine Google-KI-Übersicht.
• 7:36
  SPEAKER_00: Ein ChatGPT-Suchergebnis.
• 7:38
  SPEAKER_00: Eine Microsoft-Copilot-Antwort, eine Perplexity-Antwort und eine Claude-Suchantwort können unterschiedliche Indizes, Crawler, Ranking-Systeme und Aktualisierungspläne verwenden.
• 7:50
  SPEAKER_00: Experimentelles Design.
• 7:52
  SPEAKER_00: Erstellen Sie einen kontrollierten Seitensatz.
• 7:54
  SPEAKER_00: Verwenden Sie einen ausreichend großen Seitensatz, um aussagekräftige Crawler und Zitationsdaten zu erzeugen.
• 8:01
  SPEAKER_00: Ein praktisches Ausgangsdesign würde umfassen 240 bis 800 Seiten, mindestens 20 Seiten pro Seitenvorlage, 3 bis 5 Inhaltskategorien, eine Mischung aus Evergreen und regelmäßig aktualisierten Seiten, gleiche Anzahl von Seiten in jeder Behandlungsgruppe.
• 8:21
  SPEAKER_00: 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.
• 8:42
  SPEAKER_00: Erstellen Sie nicht hunderte von dünnen oder nahezu doppelten Seiten nur für das Experiment.
• 8:47
  SPEAKER_00: Googles Richtlinien warnen davor, dass doppelte und minderwertige URLs Crawl-Ressourcen verschwendeten und die Effizienz einer Website verringern können.
• 8:58
  SPEAKER_00: Ein Matched-Pair-Design ist nützlich.
• 9:01
  SPEAKER_00: Paaren Sie beispielsweise Seiten mit ähnlichen, Inhaltslänge, Themennachfrage, Aktualisierungsfrequenz, Anzahl der internen Links, Anzahl der externen Links, historischer Traffic, Suchranking-Position.
• 9:16
  SPEAKER_00: Platzieren Sie dann eine Seite jedes Paares in der Kontrollgruppe und die andere in einer Behandlungsgruppe.
• 9:23
  SPEAKER_00: Verwenden Sie ein faktorielles Behandlungsdesign.
• 9:26
  SPEAKER_00: Die Hauptleistungsbehandlungen sollten unabhängig voneinander und zusammen getestet werden.
• 9:32
  SPEAKER_00: For the full table, please open this article on autopod.co.
• 9:37
  SPEAKER_00: Dies schafft ein kontrolliertes Experiment für die drei angefragten Optimierungen HTTP3, Content Delivery Network Edge Caching, Bildkomprimierung.
• 9:48
  SPEAKER_00: Die Behandlung der Layout-Stabilität ist notwendig, da die ersten drei Optimierungen Cumulative Layout Shift nicht zuverlässig isolieren.
• 9:57
  SPEAKER_00: Bildkomprimierung kann Largest Contentful Paint senken, ohne die Layout-Stabilität zu verändern.
• 10:03
  SPEAKER_00: Warum HTTP3 eine eigene Messung benötigt.
• 10:07
  SPEAKER_00: HTTP3 verwendet das Quick-Transport-Protokoll und bietet unabhängige Streams, wodurch Transport-Level Head-Offline-Blocking vermieden werden kann, das in HTTP2 über TCP gefunden wird.
• 10:20
  SPEAKER_00: Seine Vorteile hängen davon ab, ob der Client oder Crawler tatsächlich HTTP 3 aushandelt.
• 10:27
  SPEAKER_00: Daher sollte das ausgehandelte Protokoll für jede Anfrage aufgezeichnet werden.
• 10:32
  SPEAKER_00: HTTP 1.1, HTTP2, HTTP3.
• 10:37
  SPEAKER_00: Gehen Sie nicht davon aus, dass die Aktivierung von HTTP 3 bedeutet, dass jeder Crawler es verwendet.
• 10:44
  SPEAKER_00: Wenn Googlebot, OAI Searchbot oder ein anderer Crawler weiterhin HTTP2 verwendet, kann HTTP3 die Anfragen dieses Crawlers nicht beeinflussen.
• 10:56
  SPEAKER_00: Warum Edge Caching sorgfältig getestet werden sollte.
• 10:59
  SPEAKER_00: Ein Content Delivery Network kann das Time-to-First-Byte reduzieren, indem es Inhalte näher am Anfragenden bereitstellt.
• 11:07
  SPEAKER_00: Es kann auch die Anzahl der Anfragen an den Origin-Server reduzieren.
• 11:12
  SPEAKER_00: Testen Sie mindestens drei Cache-Zustände.
• 11:14
  SPEAKER_00: Kalter Cache, der Edge muss den Origin kontaktieren.
• 11:18
  SPEAKER_00: Warmer Cache, der Edge liefert die Seite ohne Kontakt zum Origin.
• 11:22
  SPEAKER_00: Revalidierter Cache, der Edge oder Crawler, verwendet einen E-Tag oder Last-Modified-Wert und erhält eine 304-Not-Modified-Antwort.
• 11:32
  SPEAKER_00: Google empfiehlt explizit effizientes HTTP-Caching und unterstützt die Versendung von 304-Not-Modified-Antworten, um unnötige Verarbeitung und Bandbreite zu reduzieren.
• 11:44
  SPEAKER_00: Lassen Sie nicht zu, dass Caching veraltete oder falsche Inhalte an Crawler liefert.
• 11:49
  SPEAKER_00: Erfassen Sie Cache-Hit oder Miss, Cache-Alter, Edge-Standort, Origin-Antwortzeit, Inhaltsversion, Statuscode, Validierungsheader.
• 11:59
  SPEAKER_00: Warum Bildkomprimierung mit Largest Contentful Paint verknüpft sein sollte.
• 12:04
  SPEAKER_00: WebP und AWIF bieten im Allgemeinen eine bessere Komprimierung als ältere Bildformate.
• 12:11
  SPEAKER_00: Kleinere Bilder können die Übertragungszeit reduzieren und Largest Contentful Paint verbessern, wenn das Bild das Largest Contentful Paint Element ist.
• 12:20
  SPEAKER_00: Der Test sollte verwenden.
• 12:22
  SPEAKER_00: Dieselben Bildabmessungen.
• 12:24
  SPEAKER_00: Dasselbe visuelle Qualitätsziel.
• 12:27
  SPEAKER_00: Responsive SRC-Set-Bilder.
• 12:29
  SPEAKER_00: Ein modernes Format mit einem geeigneten Fallback.
• 12:33
  SPEAKER_00: Explizite Width- und Heitwerte.
• 12:35
  SPEAKER_00: Kein Lazy Loading für das Largest Contentful Paint-Bild.
• 12:38
  SPEAKER_00: Eine Bild-URL, die im anfänglichen HTML sichtbar ist.
• 12:43
  SPEAKER_00: Bildkomprimierung allein verbessert Largest Contentful Paint möglicherweise nicht, wenn die eigentliche Verzögerung von JavaScript oder einer späten Ressourcenentdeckung herrührt.
• 12:53
  SPEAKER_00: 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.
• 13:06
  SPEAKER_00: Führen Sie den Test lange genug durch.
• 13:09
  SPEAKER_00: Ein kurzer Test kann die Auswirkungen der Crawl-Planung und des Index-Refresh übersehen.
• 13:15
  SPEAKER_00: Ein praktisches Design ist 2 Wochen Basismessung, 6 bis 12 Wochen Behandlungszeitraum, eine abschließende Umkehr- oder Crossover-Periode, falls möglich.
• 13:26
  SPEAKER_00: Für einen Crossover-Test tauschen Sie die Behandlungen zwischen passenden Seitengruppen.
• 13:31
  SPEAKER_00: Wenn der Leistungseffekt verschwindet, wenn die Behandlung entfernt wird, ist das Ergebnis stärker als ein einfacher Vor-Nachher-Vergleich.
• 13:39
  SPEAKER_00: Core Web-Vitals-Felddaten sollten über einen geeigneten Zeitraum ausgewertet werden.
• 13:45
  SPEAKER_00: Der Chrome User Experience Report verwendet eine rolierende 28-Tage-Agggregation.
• 13:50
  SPEAKER_00: Daher ist er nicht darauf ausgelegt, sofortige Genderungen nach einer Bereitstellung anzuzeigen.
• 13:56
  SPEAKER_00: Messen Sie die gesamte Crawler-Population.
• 13:59
  SPEAKER_00: Behandeln Sie nicht den gesamten automatisierten Traffic als eine Gruppe.
• 14:03
  SPEAKER_00: Mindestens trennen Sie Suchcrawler, Googlebot, Bingbot, KI-Suchcrawler, OAI Searchbot, Perplexitybot, Cloud Searchbot, vom Benutzer angeforderte Abrufer, Perplexity-User, Claud-User, Chat-GPT-Benutzer-Abrufer, wo identifizierbar.
• 14:20
  SPEAKER_00: Training Scroller, GPT-Bot, Cloudbot, Google Extended Steuerungen.
• 14:25
  SPEAKER_00: Training Scroller sollten nicht als Proxy für KI-Suchzitate verwendet werden.
• 14:30
  SPEAKER_00: Enthropic, OpenAI und Google unterscheiden zwischen Crawlern, die für Training, Suche oder Benutzerdefinierte Abrufe verwendet werden.
• 14:39
  SPEAKER_00: Google gibt auch an, dass Google Extended die Aufnahme oder das Ranking in der Google-Suche nicht beeinflusst.
• 14:45
  SPEAKER_00: Perplexity unterscheidet ähnlich zwischen PerplexityBot, der die Suchindexierung unterstützt, und Perplexity User, der eine Seite als Reaktion auf eine Benutzeranfrage abrufen kann.
• 14:56
  SPEAKER_00: Oh! Verifizieren Sie die Crawler-Identität anhand veröffentlichter IP-Bereiche oder Reverse-DNS, wo der Anbieter dies unterstützt.
• 15:05
  SPEAKER_00: User-Agent Strings können von nicht verwandten Crawlern kopiert werden.
• 15:10
  SPEAKER_00: Google warnt ausdrücklich, dass Googlebot User-Agen Strings gefälscht werden können.
• 15:16
  SPEAKER_00: Zu erfassende Metriken, Performance-Metriken, sammeln Sie sowohl Labor- als auch Real-User-Daten.
• 15:22
  SPEAKER_00: 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.
• 15:46
  SPEAKER_00: HTTP-Protokoll.
• 15:48
  SPEAKER_00: Cache-Status.
• 15:49
  SPEAKER_00: Google empfiehlt ein ungefähres Time-to-First-Byte-Ziel von 800 Millisekunden oder weniger.
• 15:55
  SPEAKER_00: Aber Time-to-First-Byte ist selbst kein Core-Web-Weite.
• 16:00
  SPEAKER_00: Die aktuellen guten Core-Web-Viteils-Schwellenwerte am 75.
• 16:04
  SPEAKER_00: Perzentil sind.
• 16:05
  SPEAKER_00: Largest Contentful Paint 2,5 Sekunden oder weniger.
• 16:10
  SPEAKER_00: Cumulative Layout Shift 0,1 oder weniger.
• 16:13
  SPEAKER_00: Interaction to Next Paint - 200 Millisekunden oder weniger.
• 16:17
  SPEAKER_00: Crawl-Metriken.
• 16:19
  SPEAKER_00: Für jede verifizierte Crawler-Anfrage erfassen Sie Text, Timestamp, URL, User Agent, Verified Bot, Source IP, HTTP Protokoll, Status Code, Response Time, Time to First Byte, Byte Send, Cache Status, Edge Location, E-Tag, Last Modified, Referral.
• 16:37
  SPEAKER_00: Berechnen Sie Text-Crawl Requests per URD, Successful Fetch Rate, 5xX Rate, 429 Rate, Median Recrawl Intervall, P75 Recrawl Intervall, Publication to First Fetch, Publication to First Index, KI Zitationsmetriken.
• 16:54
  SPEAKER_00: Verwenden Sie einen festen Satz von Abfragen für jede Plattform.
• 16:58
  SPEAKER_00: Der Abfragesatz sollte folgendes enthalten.
• 17:01
  SPEAKER_00: Direkte Sachfragen, Vergleichsfragen, Beste oder Empfehlungsfragen.
• 17:05
  SPEAKER_00: Fragen, die auf Aktualität reagieren.
• 17:08
  SPEAKER_00: Fragen, bei denen die getestete Seite die stärkste Antwort ist.
• 17:12
  SPEAKER_00: Fragen, bei denen die getestete Seite relevant, aber nicht dominant ist.
• 17:16
  SPEAKER_00: 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.
• 17:33
  SPEAKER_00: Wiederholen Sie Abfragen, da KI-Antworten variieren können.
• 17:37
  SPEAKER_00: Verwenden Sie einen festen Zeitplan, ZB dreimal pro Woche, und erfassen Sie Änderungen in der Engine oder dem Modell.
• 17:44
  SPEAKER_00: 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.
• 17:57
  SPEAKER_00: Microsoft warnt, dass die Daten aggregiert, stichprobenbasiert und beobachtend sind.
• 18:02
  SPEAKER_00: Sie können nicht beweisen, dass eine bestimmte Seitenänderung eine Zitationsänderung verursacht hat.
• 18:08
  SPEAKER_00: Google begann im Juni 2026 ebenfalls mit der Einführung spezieller generativer KI-Leistungsberichte in der Search Console.
• 18:16
  SPEAKER_00: Die Berichte waren zunächst nur für eine Untergruppe von Websites verfügbar.
• 18:20
  SPEAKER_00: Daher kann der Zugang variieren.
• 18:23
  SPEAKER_00: Statistische Analyse Crawling-Frequenz.
• 18:26
  SPEAKER_00: Verwenden Sie ein gemischtes Zählmodell, wie ein negatives Binomialmodell.
• 18:31
  SPEAKER_00: Text-Crawl-Count, Treatment Time to First Byte, Page-Age, Update Frequency, Sitemap Status, Internal Links, Server Errors, 1 Page, 1 Crawler.
• 18:42
  SPEAKER_00: 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.
• 18:53
  SPEAKER_00: Entdeckung und Indexierung.
• 18:55
  SPEAKER_00: Verwenden Sie Überlebensanalyse für Zeit von der Veröffentlichung bis zum ersten Abruf.
• 19:01
  SPEAKER_00: Zeit von der Veröffentlichung bis zur ersten Indexierung.
• 19:04
  SPEAKER_00: Zeit von der Aktualisierung bis zum erneuten Crawl.
• 19:08
  SPEAKER_00: Das Hauptergebnis ist nicht einfach, ob eine Seite irgendwann gecrawlt wurde.
• 19:12
  SPEAKER_00: Es ist, ob die Behandlung die Zeit reduzierte, die benötigt wurde, um die Seite zu finden und zu verarbeiten.
• 19:19
  SPEAKER_00: KI-Zitationsauswahl.
• 19:21
  SPEAKER_00: Verwenden Sie ein hierarchisches logistisches Modell.
• 19:24
  SPEAKER_00: Text Citation Present.
• 19:26
  SPEAKER_00: Treatment Time to First Byte, Largest Contentful Paint, Kumulativ Layout Shift, Indexed Status, Search Visibility, Content Freshness, Page Authority.
• 19:37
  SPEAKER_00: 1 Query, 1 Engine, 1 Page.
• 19:40
  SPEAKER_00: Führen Sie zwei separate Modelle aus.
• 19:43
  SPEAKER_00: Abrufmodell Wurde die Seite abgerufen oder als Kandidat angezeigt.
• 19:48
  SPEAKER_00: Zitationsmodell.
• 19:50
  SPEAKER_00: Wurde die Seite, wenn sie abgerufen wurde, sichtbar zitiert.
• 19:53
  SPEAKER_00: Diese Unterscheidung ist essentiell.
• 19:56
  SPEAKER_00: Eine Leistungsverbesserung, die das Crawling aber nicht den Abruf erhöht, ist kein KI-Zitationseffekt.
• 20:03
  SPEAKER_00: 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.
• 20:12
  SPEAKER_00: Erwartete Ergebnisse.
• 20:14
  SPEAKER_00: Dies sind Arbeitshypothesen, keine behaupteten experimentellen Ergebnisse.
• 20:19
  SPEAKER_00: Hypothese 1.
• 20:21
  SPEAKER_00: Time-to-First-Byte wird dem deutlichsten Crawl-Effekt haben.
• 20:25
  SPEAKER_00: Erwarten Sie eine positive Beziehung zwischen einem geringeren Time-to-First-Byte und der Crawl-Kapazität.
• 20:31
  SPEAKER_00: Wenn die Website viele Seiten hat.
• 20:33
  SPEAKER_00: Seiten sich oft ändern.
• 20:35
  SPEAKER_00: Der Origin-Server langsam oder überlastet ist.
• 20:38
  SPEAKER_00: Die Website 5xx oder 492 Antworten zurückgibt.
• 20:43
  SPEAKER_00: Der Crawler signifikante Zeit mit Warten auf Antworten verbringt.
• 20:47
  SPEAKER_00: Erwarten Sie wenig messbaren Effekt auf einer kleinen Website mit geringer Crawl-Nachfrage.
• 20:53
  SPEAKER_00: Hypothese 2.
• 20:55
  SPEAKER_00: Largest Contentful Paint wird durch Rendering und Ressourcenbereitstellung wichtig sein.
• 21:00
  SPEAKER_00: Erwarten Sie, dass ein geringeres Largest Contentful Paint hilft, wenn die Seite auf Browser Rendering angewiesen ist.
• 21:07
  SPEAKER_00: Wichtige Inhalte hinter JavaScript liegen.
• 21:10
  SPEAKER_00: Große Bilder oder Style-Sheets für die Indexierung erforderlich sind.
• 21:14
  SPEAKER_00: Der Crawler viele Seitenressourcen abruft, die langsamere Behandlung Timeouts oder unvollständiges Rendering verursacht.
• 21:22
  SPEAKER_00: Erwarten Sie eine schwache Beziehung, wenn der wichtige Text der Seite bereits im initialen HTML vorhanden ist.
• 21:29
  SPEAKER_00: Hypothese 3.
• 21:31
  SPEAKER_00: Cumulative Layout Shift wird wenig direkten Effekt haben.
• 21:35
  SPEAKER_00: Erwarten Sie keine bedeutsame direkte Beziehung zwischen Cumulative Layout Shift und Crawlfrequenz oder Zitationsrate nach Kontrolle von Seitenstruktur und JavaScript verhalten.
• 21:47
  SPEAKER_00: Wenn Cumulative Layout Shift Zitationen vorherzusagen scheint, untersuchen Sie, ob es als Proxy fungiert für clientseitiges Rendering, späte Inhalseinfügung, instabile Werbung, Verständnis.
• 22:00
  SPEAKER_00: Oder verzögerten Text.
• 22:02
  SPEAKER_00: Schlecht strukturiertes HTML.
• 22:04
  SPEAKER_00: Hypothese 4.
• 22:06
  SPEAKER_00: Geschwindigkeit allein wird nicht zu mehr KI-Zitaten führen.
• 22:09
  SPEAKER_00: Die stärksten Prädiktoren für die Zitationsauswahl sind wahrscheinlich weiterhin Relevanz zur Abfrage.
• 22:16
  SPEAKER_00: Inhaltsqualität, klare Antworten, Aktualität, Autorität und Vertrauen, Eignung für den Suchindex, Abrufrang.
• 22:25
  SPEAKER_00: Ob die Seite die gemachte Behauptung direkt unterstützt.
• 22:28
  SPEAKER_00: Googles Richtlinien betonen nützliche, zuverlässige, menschenzentrierte Inhalte und besagen, dass KI-Suchfunktionen auf den bestehenden Such- und Indexierungssystemen basieren.
• 22:40
  SPEAKER_00: Ein Leistungsbudget, abgestimmt auf KI-Abruf.
• 22:43
  SPEAKER_00: Das folgende ist ein vorgeschlagenes Betriebsbudget.
• 22:46
  SPEAKER_00: Es ist keine veröffentlichte KI-Ranking-Formel.
• 22:50
  SPEAKER_00: For the full table, please open this article on autopod.co.
• 22:54
  SPEAKER_00: Googles aktuelle Dokumentation besagt, dass Googlebot die ersten 2 MB einer unterstützten Datei abruft und externe Skripte und Style-Sheets separat abruft.
• 23:05
  SPEAKER_00: Es wird aufempfohlen, wichtige Metadaten und strukturierte Daten früh im HTML zu platzieren.
• 23:11
  SPEAKER_00: Implementierungsempfehlungen HTTP3.
• 23:14
  SPEAKER_00: Verwenden Sie HTTP3, wenn es vom Hosting-Anbieter und Content Delivery Network unterstützt wird.
• 23:21
  SPEAKER_00: Messen Sie HTTP3 Aushandlungsrate, HTTP2-Fallback-Rate, Verbindungsaufbauzeit, Time-to-First-Byte, Leistung nach geografischer Region, Leistung nach Crawler.
• 23:34
  SPEAKER_00: Betrachten Sie HTTP3 nicht als garantierte Such- oder KI-Optimierung.
• 23:39
  SPEAKER_00: Es ist eine Transportverbesserung, die nur Clients helfen kann, die Sie verwenden.
• 23:44
  SPEAKER_00: Content Delivery Network Edge Caching für öffentliche, nicht personalisierte Seiten.
• 23:50
  SPEAKER_00: Legen Sie klare Cache-Control-Regeln fest.
• 23:52
  SPEAKER_00: Verwenden Sie langlebiges Caching für versionierte statische Assets.
• 23:57
  SPEAKER_00: Verwenden Sie kurzes, aber nützliches Caching für häufig aktualisiertes HTML.
• 24:02
  SPEAKER_00: Vermeiden Sie Cache-Fragmentierung durch unnötige Abfrageparameter.
• 24:07
  SPEAKER_00: Bewahren Sie kanonische URLs.
• 24:09
  SPEAKER_00: Unterstützen Sie E-Tag und Last Modified.
• 24:12
  SPEAKER_00: Testen Sie kalte, warme und revalidierte Cache-Zustände.
• 24:16
  SPEAKER_00: Bestätigen Sie, dass Scrawler-Anfragen dieselben wichtigen Inhalte erhalten wie menschliche Anfragen.
• 24:22
  SPEAKER_00: Ein Content-Delivery Network sollte die Latenz reduzieren, ohne veraltete, inkonsistente oder bot-spezifische Seitenversionen zu erzeugen.
• 24:32
  SPEAKER_00: Bildkomprimierung.
• 24:34
  SPEAKER_00: Für Bilder verwenden Sie AVF oder WebP, wenn die visuelle Qualität akzeptabel ist.
• 24:40
  SPEAKER_00: Bieten Sie Responsive-Bildgrößen an.
• 24:42
  SPEAKER_00: Servieren Sie kein Desktop-Bild auf einen kleinen mobilen Bildschirm.
• 24:46
  SPEAKER_00: Laden Sie das Largest Contentful Paint-Bild, nicht LazyLoad.
• 24:50
  SPEAKER_00: Fügen Sie Bildabmessungen ein.
• 24:52
  SPEAKER_00: Platzieren Sie das Largest Contentful Paint-Bild im initialen HTML.
• 24:57
  SPEAKER_00: Verwenden Sie Fetch Priority Equals High, nur wenn angemessen.
• 25:02
  SPEAKER_00: Halten Sie wichtige Erklärungen im Text, anstatt sie nur in Bilder einzubetten.
• 25:07
  SPEAKER_00: Bildkomprimierung ist am wertvollsten, wenn das Bild das Largest Contentful Paint-Element ist.
• 25:12
  SPEAKER_00: Sie behebt keine Seite, deren Hauptverzögerung durch Server-Rendering oder JavaScript-Ausführung verursacht wird.
• 25:20
  SPEAKER_00: Layout-Stabilität.
• 25:22
  SPEAKER_00: Um Cumulative Layout-Shift zu reduzieren, legen Sie Breiten- und Höhenattribute für Bilder fest.
• 25:28
  SPEAKER_00: Reservieren Sie Platz für Werbung.
• 25:30
  SPEAKER_00: Reservieren Sie Platz für eingebettete Video und soziale Inhalte.
• 25:34
  SPEAKER_00: Vermeiden Sie das Einfügen von Bannern über bestehendem Text.
• 25:38
  SPEAKER_00: Verwenden Sie stabile Strategien zum Laden von Schriftarten.
• 25:42
  SPEAKER_00: Vermeiden Sie das Ersetzen großer Blöcke von serverseitig gerenderten Inhalten nach dem Seitenladen.
• 25:48
  SPEAKER_00: Diese Änderungen verbessern die Benutzererfahrung, auch wenn sie keinen messbaren Effekt auf das Crawling oder die Zitationen haben.
• 25:56
  SPEAKER_00: Tools und Überwachung.
• 25:58
  SPEAKER_00: Performance Tools.
• 25:59
  SPEAKER_00: Verwenden Sie Chrome User Experience Report für Core Web Vitals von echten Benutzern.
• 26:05
  SPEAKER_00: Chrome User Experience Report Application Programming Interface für die automatisierte Erfassung von Felddaten.
• 26:12
  SPEAKER_00: PageSpeed Insights für Laboraudits und Felddaten.
• 26:16
  SPEAKER_00: Lighthouse für wiederholbare Labortests.
• 26:18
  SPEAKER_00: Lighthouse Continuous Integration für Pull Request Performance Budgets.
• 26:23
  SPEAKER_00: Web Page Test für Multi-Location Tests, Cache-Zustände und Protokollvergleiche.
• 26:28
  SPEAKER_00: Chrome DevTools zum Debuggen von Largest Content for Paint und Layout-Verschiebung.
• 26:33
  SPEAKER_00: Die Web Vitals JavaScript-Bibliothek für Real-User Monitoring.
• 26:38
  SPEAKER_00: Die Chrome User Experience Report API bietet aggregierte Felddaten auf Seiten- und Origin-Ebene, einschließlich Largest Content for Paint, Cumulative Layout Shift, Interaction to Next Paint und experimentellem Time to First Byte.
• 26:52
  SPEAKER_00: Lighthouse Continuous Integration kann Performance Checks bei jeder Code-Änderung durchführen und Builds fehlschlagen lassen, wenn Budgets überschritten werden.
• 27:02
  SPEAKER_00: Frawler Überwachung.
• 27:03
  SPEAKER_00: Verwenden Sie Serverprotokolle, Edge-Protokolle und einen kleinen Satz synthetischer Sonden.
• 27:09
  SPEAKER_00: Beispielsonde: Bash Curl HTTP 3 SS-O dev0 D TA Wänke Status minus HTTP-Code, n HTTP-Version, NNAMLOOKUP, TimENAMELOOKUP, N Connect Time Connect, N Start Transfer, Time Start Transfer, NTotal, TimeTotal, NSize, Time Size Download, N Mozilla 5.0, Compatible OAI Searchbot 1.0.
• 27:37
  SPEAKER_00: Führen Sie denselben Test durch mit Googlebot, Bingbot, OAI Searchbot, PerplexityBot, Cloud Searchbot, einem normalen Browser User Agent.
• 27:47
  SPEAKER_00: Der Test sollte folgendes überprüfen: Statuscode, Robotsberechtigung, Antwortheader, HTML-Inhalt, HTTP-Version, Cache-Status, Antwortzeit, ob wichtiger Text ohne JavaScript vorhanden ist.
• 28:00
  SPEAKER_00: 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.
• 28:18
  SPEAKER_00: Bing Webmaster Tools Crawl-Anfragen und indexierte Seiten.
• 28:22
  SPEAKER_00: Bing Webmaster Tools KI-Leistung, tägliche Sitemap und Last Mob-Prüfungen.
• 28:27
  SPEAKER_00: Die Search Console API kann Leistungsdaten nach Seite, Abfrage, Datum, Gerät und Sucherscheinung abrufen.
• 28:34
  SPEAKER_00: Vorbehaltlich Ihre Datenbeschränkungen.
• 28:37
  SPEAKER_00: Zitationsüberwachung Erstellen Sie ein Zitationspanel, das 50 bis 200 stabile Abfragen pro Thema enthält.
• 28:45
  SPEAKER_00: 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.
• 28:55
  SPEAKER_00: Zitationsreihenfolge, Datum und Uhrzeit der Antwort, ob sich die Seite geändert hat, ob sich das Modell oder die Sucherfahrung geändert hat.
• 29:04
  SPEAKER_00: Vergleichen Sie Zitationszählungen verschiedener Systeme nicht so, als wären sie äquivalent.
• 29:10
  SPEAKER_00: Microsoft gibt an, dass die Zitationsaktivität kein Rankingscore, Autoritätsscore, Traffic Maß oder Qualitätsscore ist.
• 29:19
  SPEAKER_00: Alarmregeln.
• 29:20
  SPEAKER_00: Erstellen Sie Warnungen für Time to First Byte steigt um mehr als 25%.
• 29:26
  SPEAKER_00: Largest Contentful Paint steigt am 75.
• 29:29
  SPEAKER_00: Perzentil über 2,5 Sekunden.
• 29:31
  SPEAKER_00: Kumulative Layout-Shift steigt über 0,1.
• 29:35
  SPEAKER_00: Einen anhaltenden Anstieg von 5xx oder 429 Antworten.
• 29:40
  SPEAKER_00: Ein Rückgang der Crawler-Erfolgsrate.
• 29:43
  SPEAKER_00: Eine Robots.txt-Änderung.
• 29:45
  SPEAKER_00: Ein Sitemap-Fehler.
• 29:46
  SPEAKER_00: Einen plötzlichen Rückgang der indexierten Seiten.
• 29:49
  SPEAKER_00: Einen plötzlichen Rückgang der KI-Zitationen über mehrere Plattformen hinweg.
• 29:54
  SPEAKER_00: Eine Änderung des Zitationsvolumens, die nur eine Plattform betrifft.
• 29:58
  SPEAKER_00: Ein Zitationsrückgang, der nur eine Plattform betrifft, kann durch eine Modell-, Index-, Abfrage oder Produktänderung verursacht werden und nicht durch ein Seitenleistungsproblem.
• 30:09
  SPEAKER_00: Microsoft warnt ausdrücklich, dass Zitationstrends beobachtend sind und sich aufgrund von Inhaltsaktualisierungen, Benutzernachfrage und System- oder Modelländerungen ändern können.
• 30:21
  SPEAKER_00: Fazit.
• 30:22
  SPEAKER_00: Die haltbarste Schlussfolgerung ist Schnellere Seiten können die Crawl-Effizienz verbessern, insbesondere wenn Serverlatenz, Ressourcengröße, Fehler oder Rendering-Verzögerungen limitierende Faktoren sind.
• 30:36
  SPEAKER_00: Es gibt jedoch derzeit keine starken Beweise dafür, dass niedrigere Core-Web-Wites KI-Systeme die Hack dazu veranlassen, eine Seite als Zitat auszuwählen.
• 30:47
  SPEAKER_00: Die erwartete Kausalkette ist Text, geringere Latenz, bessere Serverkapazität, weniger fehlgeschlagene oder verzögerte Abrufe.
• 30:56
  SPEAKER_00: Schnellere Entdeckung und Verarbeitung.
• 30:59
  SPEAKER_00: Verbesserte Chance, indexiert und abgerufen zu werden.
• 31:02
  SPEAKER_00: Möglicher Anstieg der Zitationen.
• 31:05
  SPEAKER_00: 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.
• 31:18
  SPEAKER_00: Für die meisten Websites ist die richtige Performance-Strategie daher nicht, für KI-Zitationen isoliert optimieren.
• 31:25
  SPEAKER_00: Sie lautet Wichtige Inhalte im initialen HTML verfügbar halten.
• 31:30
  SPEAKER_00: Time-to-First-Byte stabil halten.
• 31:32
  SPEAKER_00: Edge-Caching für öffentliche Inhalte verwenden.
• 31:35
  SPEAKER_00: Wichtige Bilder komprimieren und priorisieren.
• 31:38
  SPEAKER_00: Layout-Verschiebungen verhindern.
• 31:40
  SPEAKER_00: Zuverlässige Statuscodes zurückgeben.
• 31:44
  SPEAKER_00: Sitemaps und interne Links aktuell halten.
• 31:47
  SPEAKER_00: Die richtigen Suchcrawler zulassen.
• 31:49
  SPEAKER_00: Crawling, Indexierung, Abruf und Zitation als separate Stufen messen.
• 31:54
  SPEAKER_00: Dieser Ansatz führt zu einer schnelleren Website für Menschen, einer gesünderen Website für Suchcrawler und einer testbaren Grundlage für das Verständnis der KI-Sichtbarkeit.
• 32:04
  SPEAKER_00: Alle Quellenlinks finden Sie in der Textversion dieses Artikels.
• 32:08
  SPEAKER_00: Den vollständigen Artikel finden Sie auf autopod.co.