Speculation Rules API und SEO

TL;DR — Die Speculation Rules API ermöglicht es Ihrer Website, Chrome oder Edge anzuweisen, die nächste Seite zu laden, die ein Besucher wahrscheinlich anklicken wird – leise, im Hintergrund –, bevor er sie anklickt. Wenn er dann klickt, kann die Seite nahezu sofort erscheinen. Es ist eine Geschwindigkeitsfunktion für echte Nutzer von Chromium-Browsern. Es hilft Google nicht beim Crawlen oder Ranking Ihrer Website, kann aber Seiten schneller erscheinen lassen, was gut für Nutzer ist (und indirekt für Core Web Vitals).

Was es ist

Normalerweise beginnt der Browser beim Klick auf einen Link, die Seite von Grund auf zu laden – und Sie warten. Die Speculation Rules API ermöglicht einer Website einen Vorsprung: Sie teilt dem Browser mit: „Der Besucher wird wahrscheinlich als Nächstes hierhin gehen, also beginnen Sie jetzt, sie vorzubereiten.“ Wenn der Klick schließlich erfolgt, tauscht der Browser die bereits vorbereitete Seite ein, anstatt von vorne zu beginnen.

Es gibt zwei Versionen des „Vorbereitens“, und der Unterschied ist wichtig:

• Prefetch – der Browser lädt das HTML der nächsten Seite leise im Hintergrund herunter. Leichter, geringeres Risiko.
• Prerender – der Browser lädt die nächste Seite vollständig und rendert sie in einem unsichtbaren Tab, einschließlich JavaScript und allem. Schwerer, aber die Seite kann wirklich sofort erscheinen. Riskanter, daher sparsam einsetzen.

Sie richten dies mit einem kleinen JSON-Block auf Ihrer Seite ein. Sie können genaue URLs auflisten oder dem Browser mitteilen: „Bereiten Sie jeden Link vor, über den der Besucher fährt.“

Hilft es bei SEO?

Kurzfassung: nicht so, wie man es sich erhofft. Es führt nicht zu schnellerem Crawlen oder Indexieren. Googlebot braucht das nicht – es ist eine Funktion für menschliche Besucher in Chrome und Edge, nicht für Such-Bots.

Was es kann, ist, Ihre Seiten schneller erscheinen zu lassen, sobald jemand bereits auf Ihrer Website ist und herumklickt. Schnellere reale Erfahrungen fließen in Core Web Vitals ein, was ein (bescheidenes) Ranking-Signal ist – und, was wichtiger ist, schnellere Seiten konvertieren tendenziell besser. Ray-Ban zum Beispiel berichtete von einem großen Sprung bei den Konversionen nach dem Prerendering von Produktseiten.

Das eine, worauf Sie achten sollten

Ihre Analysen können Sie belügen. Wenn der Browser eine Seite vorab rendert, bevor der Besucher sie je sieht, und diese Seite beim Laden einen „Pageview“ auslöst, zählt Ihre Analytik einen Besuch, der nie stattfand. Das eigene Skript von Google Analytics 4 behandelt dies korrekt – aber viele andere Tags und Pixel tun das nicht, und sie protokollieren Phantom-Pageviews, es sei denn, ein Entwickler patcht sie.

Wenn Sie WordPress 6.8 oder höher verwenden, haben Sie bereits eine sichere, konservative Version davon standardmäßig aktiviert (nur Prefetch, für abgemeldete Besucher). Sie mussten nichts tun – es kam mit einem Update.

Möchten Sie das vollständige Bild – Prefetch vs. Prerender im Detail, Eagerness-Stufen, die „niemals prerendern“-Liste und wie Sie das Analytik-Problem beheben? Wechseln Sie zum Erweitert-Tab.

TL;DR — Die Speculation Rules API (Chromium, Chrome/Edge 109+) ermöglicht einer Website, in JSON, inline oder über einen Speculation-Rules-Header, zu deklarieren, welche Same-Site-URLs der Browser prefetchen (Dokument herunterladen; reduziert TTFB) oder prerendern (vollständig abrufen, rendern und JS in einem unsichtbaren Tab ausführen; reduziert TTFB + FCP + LCP) soll. Eagerness (immediate/eager/moderate/conservative) steuert, wann eine Regel ausgelöst wird, getrennt davon, welche URLs sie anvisiert. Es ist kein Crawling-/Indexierungs-/Ranking-Mechanismus – Googlebot verlässt sich nicht auf Ressourcen-Hinweise wie diese (laut Illyes’ Kommentaren vom Februar 2026 zu Hinweisen allgemein) und Google veröffentlicht keine Search-Dokumentation dazu. Aber die Google-Suche selbst verwendet es, um ihre Top-Ergebnisse vorab zu laden, und Ray-Ban berichtete von großen Konversions- und LCP-Gewinnen, also ist der Nutzen für echte Besucher über Core Web Vitals und UX real. Die größten Fallstricke: Analytik-Doppelzählung (behebbar mit document.prerendering/prerenderingchange), zustandsändernde GET-URLs (Logout, In-den-Warenkorb), die Sie niemals spekulieren dürfen, und nur Chromium-Unterstützung. Beginnen Sie breit mit Prefetch; fügen Sie Prerender höchstens ein oder zwei Seiten mit hoher Sicherheit hinzu.

Was die Speculation Rules API tatsächlich ist

Die Speculation Rules API ist eine Browser-API – nur in Chromium –, die es einer Website ermöglicht, dem Browser mitzuteilen, welche Seiten derselben Website vor einem Klick vorbereitet werden sollen. Laut MDN ist die API darauf ausgelegt, die Leistung für zukünftige Navigationen zu verbessern, und da sie auf Dokument-URLs und nicht auf einzelne Ressourcendateien abzielt, ist sie für Multi-Page-Websites sinnvoller als für Single-Page-Apps. Sie ersetzt das alte, veraltete, nur in Chrome verfügbare <link rel="prerender"> und geht über das weit verbreitete <link rel="prefetch"> mit einer ausdrucksstärkeren JSON-Syntax hinaus.

Regeln werden als JSON deklariert, entweder inline in einem <script type="speculationrules">-Block oder über einen Speculation-Rules HTTP-Response-Header. Sie können explizite URLs auflisten oder Links auf der Seite automatisch über where/href_matches-Bedingungen abgleichen (sogenannte Document Rules).

Es gibt zwei spekulative Aktionen, und den Unterschied richtig zu verstehen, ist der Kern der Sache:

• Prefetch lädt den Response-Body der referenzierten Seite herunter – aber nicht deren Subressourcen. Es reduziert die TTFB der nächsten Seite.
• Prerender ruft die Seite ab, rendert sie und lädt sie in einen unsichtbaren In-Memory-Tab: alle Subressourcen, das gesamte JavaScript, sogar Datenabrufe, die von JavaScript angestoßen werden. Laut MDN sind zukünftige Navigationen zu einer vorgerenderten Seite nahezu sofort. Es reduziert TTFB und FCP und LCP – aber es ist weitaus teurer und riskanter.

Harry Roberts’ Kurzformel in seinem Beitrag zum Schichtenansatz trifft es gut: Prefetch dient der Reduzierung von TTFB, Prerender dient LCP.

Eine wenig behandelte technische Nuance: Spekulierte Ressourcen landen im Memory-Cache des Browsers, der schneller abrufbar ist als der HTTP-Cache, den der ältere <link rel="prefetch">-Hinweis verwendet. Und ein vorabgerufenes oder vorgerendertes Dokument füllt auch den HTTP-Cache, sodass selbst eine Spekulation, die der Besucher nie nutzt, kein reiner Verlust ist – eine spätere Navigation kann trotzdem davon profitieren.

Eagerness: wann spekuliert wird, getrennt von welchen URLs

Eine wirklich clevere Designentscheidung hier ist, dass Eagerness ein separater Hebel von der Zielauswahl ist. Barry Pollards Chrome-Blogbeitrag zu den Verbesserungen der API rahmt es als Trennung von wann spekuliert wird von welchen URLs, auf die spekuliert wird. Es gibt vier Stufen:

• immediate – spekulieren, sobald die Regeln gesehen werden (beim Laden der Seite).
• eager – beim geringsten Signal beginnen.
• moderate – ungefähr bei einem 200ms-Hover (oder Pointerdown bei Touch).
• conservative – bei Pointer- oder Touch-Down, d. h. der Besucher hat fast geklickt.

Behandeln Sie diese vier Trigger-Definitionen als Chromes aktuelle Heuristiken, nicht als feste Spezifikation – Chrome hat die genauen mobilen Trigger mehr als einmal geändert (es hat moderate auf viewportbasierte Heuristiken umgestellt und das Timing von eager noch im Januar 2026 angepasst), also überprüfen Sie die aktuellen Dokumentationen erneut, bevor Sie in Ihren eigenen Implementierungshinweisen einen genauen Millisekunden- oder Prozentwert angeben.

Zwei verwandte Verfeinerungen, die es wert sind, bekannt zu sein: No-Vary-Search erlaubt dem Browser, ein gecachtes Dokument wiederzuverwenden, das sich nur durch ignorierbare Parameter unterscheidet (z. B. UTM-getaggte Varianten derselben Seite), und das neuere prerender-until-script-Muster (behandelt von CoreWebVitals.io) bietet einen Mittelweg zwischen einfachem Prefetch und einem vollständigen Prerender – zum Zeitpunkt dieses Schreibens ist es noch eine experimentelle, nicht allgemein verfügbare Aktion, die in einem Chrome-Origin-Trial läuft, kein ausgelieferter Standard.

Chromes eigene Schutzmechanismen

Sie können das Gerät eines Besuchers nicht versehentlich mit einer zu weit gefassten Regel zerstören. Die Prerender-Dokumentation von Chrome legt unabhängig von Ihrer Konfiguration harte FIFO-Obergrenzen fest: für Regeln mit immediate-Eagerness 50 Prefetches und 10 Prerender; für interaktionsbasierte (moderate/ conservative) Regeln 2 Slots. Chrome behandelt ein Prerender außerdem als Hinweis und progressive Verbesserung, nicht als Garantie – es kann basierend auf den Einstellungen des Benutzers oder Ressourcenbeschränkungen ablehnen – und es rendert keine Cross-Origin-Iframes auf einer prerenderten Seite bis zur Aktivierung. Ein integrierter Datenschutzschutz blockiert auch Cross-Site- Prefetches, wenn der Benutzer bereits Cookies für die Zielseite gesetzt hat.

Cross-Origin-Regeln und was tatsächlich in einer prerenderten Seite passiert

Laut MDN ist Prerendering standardmäßig auf Same-Origin-Dokumente beschränkt. Cross-Origin-, Same-Site-Prerendering ist möglich, aber nur, wenn die Zielseite mit einem Supports-Loading-Mode: credentialed-prerender-Antwortheader optiert – Cross-Site-Prerendering ist zum Zeitpunkt dieses Schreibens überhaupt nicht möglich. Cross-Site- Prefetch ist permissiver (Same-Site- und Cross-Site-Prefetches funktionieren beide), aber dennoch durch die obige Datenschutzregel ohne gesetzte Cookies eingeschränkt; ein breiterer Cross-Site-Prefetch- Opt-in über Supports-Loading-Mode ist als geplant dokumentiert, aber noch nicht ausgeliefert.

In der versteckten Registerkarte ist eine prerenderte Seite kein normaler Seitenaufruf: intrusive APIs (alert()/confirm()/prompt(), requestFullscreen(), Navigator.share()) sind blockiert oder ignoriert, asynchrone APIs wie Geolokalisierung und getUserMedia() werden bis zur Aktivierung aufgeschoben, und Cross-Origin-Iframes und Worker-Skripte laufen bis dahin ebenfalls nicht. Session Storage erhält eine spezielle Behandlung, die Sie kennen sollten, wenn Ihre Seite sie beim Laden liest: Eine prerenderte Seite startet mit einem Klon des Session Storage der Registerkarte, und dieser Klon wird bei der Aktivierung zugunsten des echten Speichers der Registerkarte verworfen – testen Sie also jede von Session Storage abhängige Logik sowohl vor als auch nach dem prerenderingchange-Ereignis, nicht nur bei einem normalen Laden. Für das Timing geben document.prerendering und prerenderingchange den Zustand und den Aktivierungszeitpunkt an; PerformanceNavigationTiming.activationStart liefert die tatsächlich verstrichene Zeit zwischen Prerender-Start und Aktivierung, wenn Sie sie messen möchten.

Beeinflusst die Speculation Rules API SEO, Crawling oder Rankings?

Das ist die Frage, die jeder SEO beantwortet haben möchte, und die meisten Konkurrenzartikel winken sie ab. Die präzise Antwort hat zwei Hälften.

Was sie NICHT tut

Sie ist kein Crawling-, Indexierungs- oder Ranking-Mechanismus. Es gibt keine Google Search Central-Dokumentation, die die Speculation Rules API mit dem Crawlen oder Indexieren durch Googlebot verbindet – weil sie diese Ebene überhaupt nicht berührt. Es ist eine Browser-Funktion für menschliche Besucher in Chromium.

Die nächste offizielle Google-Aussage ist Gary Illyes in Search Off the Record (Anfang 2026), der über Resource Hints im Allgemeinen spricht – nicht namentlich über die Speculation Rules API. Wie Search Engine Journal berichtete, war Illyes’ Punkt, dass die eigene Infrastruktur von Googlebot nahezu unbegrenzte Bandbreite und sehr schnelle DNS-Auflösung hat, sodass Hinweise wie DNS-Prefetch und Preload praktisch keinen Wert für seinen Crawling-Prozess haben – es kann bereits schnell mit Servern kommunizieren und muss nicht angewiesen werden, Dinge früher abzurufen. Behandeln Sie das als Unterstützung für „Dies ist eine Browser-/Besucherfunktion, keine Crawler-Funktion“, beachten Sie jedoch den Umfang: Illyes sprach über die breitere Familie der Resource Hints, nicht speziell über Speculation Rules. Dies ist dieselbe Disziplin, die der verwandte Artikel zu Resource Hints anwendet.

Auch der Vollständigkeit halber, weil oft gefragt wird: Bing hat nichts zur Speculation Rules API für SEO veröffentlicht. Edge (Chromium 109+) unterstützt sie als Browserfunktion, aber es gibt keinen bingbot- oder Indexierungs-Aspekt – was genau das ist, was man für eine Rendering-Browser-Funktion erwarten würde, nicht für eine Suchmaschinen-Crawler-Funktion.

Was es KANN

Es kann Core Web Vitals verbessern – insbesondere LCP und indirekt INP, indem JavaScript-Ausführung vor der Interaktion vorgezogen wird – für echte Nutzer. Core Web Vitals ist ein dokumentiertes (wenn auch bescheidenes) Ranking-Signal über das Page-Experience-System, also gibt es einen indirekten Ranking-Pfad. Aber das stärkere Argument ist schlicht UX und Conversion: Die nächste Seite sofort erscheinen zu lassen, ist ein echter Geschäftshebel, unabhängig von Rankings.

Die nicht übertreibende Art, es zu formulieren: Speculation Rules sorgen nicht dafür, dass Sie anders gecrawlt oder indexiert werden – sie lassen eine Seite sofort erscheinen, sobald ein echter Besucher bereits auf Ihrer Website navigiert, was ein UX- und Core-Web-Vitals-Hebel ist, kein Crawler-Hebel.

Ergebnisse aus der Praxis

Zwei Belege tragen hier die Hauptlast, und beide stammen aus Googles eigenen Veröffentlichungen.

Google Search nutzt es selbst. Laut der Ankündigung des Chrome-Teams von 2025 war eine der ersten Anwendungen von Speculation Rules das Vorabladen der ersten beiden Suchergebnisse. Die gemessenen Verbesserungen: Auf Android Chrome wurde die LCP für Klicks von Google Search um 67 Millisekunden reduziert; auf dem Desktop eine ähnliche LCP-Verbesserung von 58,6 Millisekunden. Hover-basiertes Vorabladen der übrigen Ergebnisse reduzierte die Desktop-FCP um 7,6 Millisekunden und die LCP um 9,5 Millisekunden. Für Cross-Origin-Ergebnis-Vorabladevorgänge leitet Google Search sie über Chromes privaten Prefetch-Proxy, um die Anfrage zu anonymisieren. Nur wenige konkurrierende Artikel erwähnen, dass Google dem so sehr vertraut, dass es dies auf google.com/search in großem Maßstab einsetzt – und die genauen Millisekunden-Deltas veröffentlicht hat.

Ray-Bans Fallstudie ist der Beleg für die geschäftliche Wirkung. Googles web.dev-Fallstudie berichtet, dass nach dem Vorab-Rendern von Produktseiten die mobilen Konversionsraten auf PDPs um 101,47 % und auf dem Desktop um 156,16 % stiegen, mit einer 43 %-Verbesserung der LCP sowohl auf dem Desktop als auch auf Mobilgeräten. Die Absprungraten sanken auf beiden um etwa 13 %, und die pro Sitzung angesehenen Seiten stiegen auf Mobilgeräten um 51,95 % und auf dem Desktop um 65,30 %. Die Implementierungsaufteilung ist aufschlussreich: Desktop verwendete moderate Eagerness, ausgelöst durch Hover über Produktkacheln; Mobilgeräte (kein Hover-Zustand) verwendeten immediate Eagerness nur auf den ersten vier Kacheln, die am häufigsten angeklickt wurden.

Und der Umfang ist bereits groß: WordPress 6.8 (März 2025) liefert dies standardmäßig aus, basierend auf einem Feature-Plugin, das vor der Kernübernahme auf Zehntausenden von Websites lief – was bedeutet, dass ein bedeutender Teil des Webs bereits Speculation Rules ausführt, ohne dass jemand sie konfiguriert.

So implementieren Sie es sicher

Die konsensuale Einführungsreihenfolge, sowohl aus Googles Dokumentation als auch von unabhängigen Experten:

1. Beginnen Sie breit mit Prefetch. Laut Implementierungsleitfaden von Chrome ist Prefetch für die meisten Websites relativ sicher und der erste Ansatz, den viele wählen.
2. Fügen Sie Prerender später und eng begrenzt hinzu. Die Chrome-Dokumentation warnt vor übermäßigem Prerendering auf Kosten von Benutzerressourcen und empfiehlt, das Prerendering auf höchstens ein oder zwei Seiten zu beschränken. Harry Roberts kommt unabhängig zum gleichen Ergebnis – ein Wildcard-ähnlicher Abgleich ist zu gierig, und alles vorzurendern ist meist zu teuer und zu riskant; ein Opt-in-Ansatz ist besser.
3. Nutzen Sie Dokumentregeln zur Skalierung ohne Seitenkonfiguration. Statt URLs auf jeder Seite manuell aufzulisten, bezieht eine where/href_matches-Bedingung URLs aus dem Dokument selbst, sodass ein Regelsatz websiteweit angewendet werden kann.
4. Beachten Sie Ihre CSP. Inline-<script type="speculationrules">-Blöcke benötigen eine explizite Freigabe in script-src – über 'inline-speculation-rules', eine Hash-Quelle oder eine Nonce-Quelle – andernfalls schlagen sie still fehl, wenn eine Content Security Policy aktiv ist.

Was NICHT vorabgerufen oder vorgerendert werden sollte

Sowohl MDN als auch der Implementierungsleitfaden von Chrome sind eindeutig: Einige URLs dürfen niemals spekuliert werden, da ein spekulativer Abruf immer noch eine echte Anfrage ist, die echte Nebenwirkungen auslösen kann. Die Gefahrenliste:

• Abmelde-/Logout-URLs.
• “In den Warenkorb”-URLs.
• Sprach- oder Währungswechsler-URLs.
• Anmeldeabläufe, die eine SMS/OTP auslösen.
• URLs, die ein Nutzungskontingent erhöhen oder Ad-Conversion-Tracking auslösen.

Die grundlegende Lösung ist eine Designfrage: Zustandsänderungen – wie eine /logout-Aktion – sollten nicht als einfache GET-Links umgesetzt werden, die eine Spekulationsregel überhaupt abrufen könnte.

Prerender ist noch strenger. Zusätzlich unsicher zum Vorrendern: Seiten, die beim Laden clientseitigen Speicher verändern, beim Laden Analytik- oder Werbe-Impressionen senden oder anderweitig Nebenwirkungen verursachen, als hätte der Benutzer interagiert. MDN formuliert es so, dass Prerendering riskanter ist als Prefetching und sparsam eingesetzt werden sollte, nur dort, wo es sich lohnt.

Das Analytik-Problem beheben

Das ist die Falle, die echte Websites erwischt. Eine vorgerenderte Seite wird vollständig geladen, bevor der Benutzer sie überhaupt sieht. Wenn ein page_view (oder eine Werbe-Impression oder ein Meta-Pixel-Ereignis) beim Laden ausgelöst wird, haben Sie einen Besuch protokolliert, der nicht stattgefunden hat – das bläht GA4-Sitzungen auf und verfälscht die Attribution.

Der Mechanismus zur Behebung ist in MDN und den Chrome-Leitfäden dokumentiert:

• document.prerendering ist true, während eine Seite vorgerendert wird.
• Das prerenderingchange-Ereignis wird bei der Aktivierung ausgelöst (wenn der Benutzer tatsächlich hineinnavigiert).
• Server können spekulative Anfragen auch über den Sec-Purpose-Anfrageheader erkennen (prefetch oder prefetch;prerender).

Die praktische Realität: Laut Implementierungsleitfaden von Chrome unterstützen einige Analytik-Anbieter (Google Analytics) und Werbeanbieter (Google Publisher Tag) bereits Spekulationsregeln und protokollieren einen Aufruf erst, wenn die Seite aktiviert wird. GA4s eigenes gtag.js übernimmt das für Sie. Was normalerweise nicht standardmäßig damit umgeht: benutzerdefinierte GTM-Tags, Meta Pixel und eigene Skripte. Bei Tag-Manager-Setups ist ein sauberer Ansatz, das Tag-Manager-Skript selbst zu verzögern oder bestimmten Code zu sperren, bis die Seite aktiviert oder sichtbar gemacht wird. Es gibt eine dokumentierte reale Variante, wie man das falsch macht – WordPress-6.8-Websites, die angeblich GA4- und Meta-Pixel-Geisterbesuche auslösen, nachdem die Funktion automatisch aktiviert wurde; Erwin Hofman behandelt die Lösung ausführlich.

Realitätscheck zur Browserunterstützung

Dies dämpft die ROI-Erwartungen, und die meisten Artikel verschweigen es: Die Speculation Rules API ist nur für Chromium (Chrome und Edge 109+). Sie ist nicht Baseline. Firefox hat eine positive Standards-Position nur zum Prefetch-Teil und hat ihn nicht ausgeliefert; Safari hat eine Implementierung hinter einem Flag, standardmäßig deaktiviert. Ein erheblicher Anteil des Datenverkehrs jeder Website – alle auf Firefox und Safari – profitiert überhaupt nicht, also passen Sie Ihre Erwartungen entsprechend an.

Speculation Rules in WordPress 6.8+

Da ein großer Teil des Suchpublikums WordPress nutzt und dies standardmäßig erhalten hat: WordPress 6.8 (März 2025) enthält integriertes Speculative Loading, standardmäßig aktiviert für abgemeldete Besucher, mit einer konservativen, nur-Prefetch-Konfiguration ab Werk. Website-Betreiber können das Verhalten anpassen – einschließlich der Entscheidung für Prerender bei wichtigen URLs – über den wp_speculation_rules_configuration-Filter (Weston Ruter, ein Google-Ingenieur und WordPress-Core-Mitwirkender, hat eine Anleitung). Der Standard ist bewusst sicher, weshalb die meisten WordPress-Websites ihn aktiviert lassen können – aber genau deshalb hat die oben genannte Analytics-Falle viele Website-Betreiber überrascht, die nie etwas aktiviert haben.

Mythen, entlarvt

• „Speculation Rules werden Googlebot helfen, meine Website schneller zu crawlen.“ Nein – es ist ein Browser-Rendering-Feature für menschliche Besucher in Chromium; die eigene Infrastruktur von Googlebot benötigt solche Hinweise nicht, und kein Google-Dokument verknüpft die API mit dem Crawling.
• „Es ist dasselbe wie <link rel="prefetch">/<link rel="prerender">.“ Nicht ganz – es ersetzt das veraltete, nur für Chrome verfügbare rel="prerender", fügt eine reichhaltigere JSON-Syntax hinzu (Dokumentregeln, Eagerness) und speichert spekulierte Ressourcen im Speichercache statt im HTTP-Cache.
• „Alles vorzubereiten macht meine gesamte Website sofort schnell, ohne Nachteile.“ Nein – Chrome warnt vor übermäßigem Prerendering, erzwingt harte Obergrenzen, und sowohl Google als auch Harry Roberts empfehlen höchstens ein oder zwei vorbereitete Seiten.
• „Wenn ich Speculation Rules hinzufüge, funktioniert meine Analytik einfach.“ Nur wenn jedes Analytik- und Werbeskript über document.prerendering/prerenderingchange aufschiebt. GA4 handhabt das; viele GTM-Tags und Drittanbieter-Pixel nicht.
• „Es wird universell unterstützt, also ist es eine sichere Standardeinstellung für den gesamten Datenverkehr.“ Nein – nur Chromium, nicht Baseline; Firefox und Safari liefern es nicht standardmäßig aus.
• „Prefetch ist risikofrei, also kann ich es wildcarden.“ Übertrieben – ein Wildcard-ähnlicher Abgleich ist zu gierig, besonders für zustandsändernde GET-URLs, die von vornherein keine abrufbaren Links sein sollten.
• „Das wird direkt meine Rankings verbessern.“ Von keiner offiziellen Quelle als direkter Ranking-Faktor belegt. Die glaubwürdige Kette ist: Speculation Rules → bessere echte Nutzer-Core-Web-Vitals / Konversion → das bestehende, moderate Page-Experience-Signal, plus geschäftliche Erfolge, die unabhängig von Rankings zählen.

Wo dies einzuordnen ist

Dies ist ein Web-Performance-Thema, kein Crawling-Thema – und diese Grenze sauber zu halten, ist der Punkt. Es ist ein enger Verwandter der Resource Hints (preload/preconnect/dns-prefetch/prefetch), die die gleiche Idee „Der Browser erledigt Netzwerkarbeit früher“ und denselben Vorbehalt „hilft Googlebot nicht“ teilen; es speist Core Web Vitals (insbesondere LCP); und es interagiert mit Caching und einem CDN, da spekulierte Dokumente Caches füllen. Für das Crawler-seitige Analogon zu „Vor dem erneuten Abrufen fragen“ behandelt das Thema bedingte Anfragen, wie Googlebot vermeidet, unveränderte Seiten erneut herunterzuladen – eine andere Ebene (Crawler, nicht Browser), dieselbe Disziplin, Mechanik von Ranking-Auswirkungen zu trennen.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Was es ist: eine nur in Chromium verfügbare (Chrome/Edge 109+) Browser-API zum Prefetch (Herunterladen des HTML-Dokuments; reduziert TTFB) oder Prerender (vollständiges Laden + Ausführen von JS in einem unsichtbaren Tab; reduziert TTFB + FCP + LCP) von Seiten derselben Website vor einem Klick. Deklariert als Inline-JSON oder über einen Speculation-Rules-Header.
• Eagerness (immediate/eager/moderate/conservative) steuert, wann eine Regel ausgelöst wird, getrennt davon, welche URLs sie anspricht. Chrome erzwingt harte Obergrenzen (50 Prefetches / 10 Prerenders für immediate-Regeln); die genauen Auslöser sind von der Chrome-Version abhängige Heuristiken, keine festen Konstanten.
• Cross-Origin: Prerender ist standardmäßig Same-Origin; Cross-Origin-Same-Site- Prerender erfordert das Opt-in des Ziels (Supports-Loading-Mode: credentialed-prerender); Cross-Site-Prerender ist überhaupt nicht möglich. Prefetch ist permissiver, aber dennoch durch eine No-Destination-Cookies-Datenschutzregel eingeschränkt.
• SEO-Realität: kein Crawling-/Indexierungs-/Ranking-Mechanismus — Googlebot benötigt keine Resource Hints (laut Illyes, Feb. 2026, zu Hints allgemein) und Google hat kein Search-Dokument dazu. Bing hat nichts veröffentlicht. Es kann Core Web Vitals (LCP/INP) und Conversions für echte Nutzer verbessern — ein indirekter Ranking- und UX-Hebel.
• Beweis, dass es funktioniert: Google Search prefetcht seine Top-zwei-Ergebnisse (LCP um ~58–67 ms reduziert); Ray-Ban berichtete von ~100–156 % Conversion-Steigerungen und einer 43 % LCP-Verbesserung durch Prerendering von PDPs.
• Größtes Risiko — Analytics: Eine spekulierte Seite, die beim Laden einen Pageview auslöst, bläht GA4 auf. Beheben mit document.prerendering / prerenderingchange. GA4 behandelt das nativ; GTM-Custom-Tags und Meta Pixel oft nicht.
• Niemals zustandsändernde GET-URLs spekulieren: Logout, Add-to-Cart, Währungs-/Sprach- Umschalter, OTP-Anmeldung. Diese von GET-Links umgestalten.
• Einführungsreihenfolge: Prefetch breit einsetzen, Prerender nur auf ein oder zwei Seiten maximal hinzufügen, CSP beachten ('inline-speculation-rules').
• WordPress 6.8+ liefert konservatives, nur-Prefetch-spekulatives Laden standardmäßig für abgemeldete Nutzer aus (wp_speculation_rules_configuration-Filter zum Anpassen).

Offizielle Dokumentation

Primärquellen-Dokumentation. Hinweis: Die Suchmaschinen veröffentlichen nichts dazu als SEO-Thema — die maßgeblichen Dokumente sind Browser-/Standard-Referenzen.

MDN / Standards

• Speculation Rules API — die technische Referenz: Syntax, Prefetch vs. Prerender, Datenschutz, CSP und Browser-Kompatibilitätsstatus.
• Speculation-Rules HTTP-Header — Deklaration von Regeln über einen Antwort-Header statt eines Inline-Skripts.

Chrome for Developers (Google)

• Prerender pages in Chrome for instant page navigations — wie Prerender funktioniert, die Hint-nicht-Garantie-Einordnung und Chromes FIFO-Obergrenzen.
• Guide to implementing speculation rules for more complex sites — die Analytics-Warnung, die Behandlung von Drittanbieter-Skripten und Vorsichtshinweise zu Zustandsänderungen.
• Improvements to the Speculation Rules API (Barry Pollard, 2024) — Dokumentregeln, Eagerness, No-Vary-Search, HTTP-Cache-Wiederverwendung.
• Google Search now uses the Speculation Rules API (Pollard & Busaryev, 2025) — Googles eigene Nutzung und die gemessenen LCP/FCP-Deltas.

web.dev (Google)

• How Ray-Ban doubled conversion rate… through prerendering — die Fallstudie zu den geschäftlichen Auswirkungen.
• Prefetching, prerendering, and precaching — Memory-Cache vs. HTTP-Cache und wann Vorsicht geboten ist.

WordPress (offizielle Funktionsdokumentation)

• Speculative Loading in 6.8 (Make WordPress Core) — das Standardverhalten und der Konfigurationsfilter.
• Speculative Loading Feature-Plugin — das Plugin, auf dem die Core-Übernahme basierte.

Zitate aus der Quelle

Aussagen aus der primären Browser-/Standarddokumentation und Googles eigenen Veröffentlichungen. Da dies kein Suchmaschinen-SEO-Thema ist, gibt es keine Google Search-Zitate — die Quellen sind Chrome/MDN/web.dev.

MDN — was es ist und was es tut

• “The Speculation Rules API is designed to improve performance for future navigations. It targets document URLs rather than specific resource files, and so makes sense for multi-page applications (MPAs) rather than single-page applications (SPAs).” (Übersetzung) „Die Speculation Rules API soll die Leistung für zukünftige Navigationen verbessern. Sie zielt auf Dokument-URLs und nicht auf bestimmte Ressourcendateien ab und ist daher für Multi-Page-Anwendungen (MPAs) sinnvoller als für Single-Page-Anwendungen (SPAs).“ Zum Zitat springen

Chrome — Googles eigene Nutzung (das stärkste Beweisargument)

• “One of the first uses of speculation rules was to prefetch the first two search results.” — Chrome for Developers Blog. (Übersetzung) „Eine der ersten Verwendungen von Spekulationsregeln war das Vorabrufen der ersten beiden Suchergebnisse.“ Zum Zitat springen
• Auf Android Chrome wurde der LCP für Klicks von Google Search “reduced by 67 milliseconds.” (Übersetzung) „um 67 Millisekunden reduziert.“ Zum Zitat springen
• Auf dem Desktop eine “similar improvement in LCP of 58.6 milliseconds.” (Übersetzung) „ähnliche Verbesserung des LCP um 58,6 Millisekunden.“ Zum Zitat springen

Speculation Rules Spickzettel

Prefetch vs. Prerender

Eagerness — wann eine Regel ausgelöst wird (unabhängig von welchen URLs)

Chromes harte Obergrenzen (unabhängig von Ihrer Konfiguration)

• immediate-Regeln: 50 Prefetches / 10 Prerenders.
• Interaktionsbasierte (moderate/conservative) Regeln: 2 FIFO-Slots.

Cross-Origin-Kurzreferenz

• Prerender: standardmäßig Same-Origin; Cross-Origin Same-Site erfordert, dass das Ziel Supports-Loading-Mode: credentialed-prerender sendet; Cross-Site-Prerender ist nicht möglich.
• Prefetch: Same-Site und Cross-Site funktionieren beide, eingeschränkt durch die Datenschutzregel für No-Destination-Cookies.

Schnelle Fakten

• Unterstützung: nur Chromium (Chrome/Edge 109+). Nicht Baseline. Firefox = Prefetch Standards-Position nur (nicht ausgeliefert); Safari = hinter einem Flag, standardmäßig aus.
• Als JSON deklariert: inline <script type="speculationrules"> oder ein Speculation-Rules-HTTP-Header.
• CSP: Inline-Blöcke benötigen 'inline-speculation-rules' (oder Hash/Nonce) in script-src.
• Erkennen eines spekulativen Ladens: document.prerendering, das prerenderingchange-Ereignis oder der Sec-Purpose-Anforderungsheader.
• Kein Google-Ranking-/Crawl-Signal. Google Search nutzt es (Top-2-Ergebnisse, ~58–67 ms LCP). WordPress 6.8+ = konservativ, nur Prefetch, abgemeldet, standardmäßig aktiviert.

Was Sie nicht tun sollten

Spekulieren von zustandsändernden GET-URLs. Ein spekulativer Fetch ist eine echte Anfrage. Prefetchen oder Prerendern Sie niemals Logout, Add-to-Cart, Währungs-/Sprachumschalter, OTP-auslösende Anmeldeabläufe oder URLs, die ein Guthaben erhöhen. Die eigentliche Lösung ist Design: Diese Aktionen sollten keine einfachen GET-Links sein, die eine Regel abrufen könnte. Dies ist sowohl in MDN als auch in Chromes Implementierungsleitfaden dokumentiert.

Prerendern im großen Stil oder mit einem Platzhalter. Chrome begrenzt es und warnt vor übermäßigem Prerendern auf Kosten von Benutzerressourcen; Harry Roberts nennt ein Platzhalter-ähnliches Matching zu gierig. Beschränken Sie Prerender auf eine oder zwei hochvertrauenswürdige Seiten.

Annehmen, dass Ihre Analytik in Ordnung ist. Wenn eine vorgerenderte Seite beim Laden einen Seitenaufruf auslöst, blähen Sie GA4 mit Besuchen auf, die nie stattgefunden haben. GA4s gtag.js behandelt dies – aber GTM-Custom-Tags, Meta Pixel und hausgemachte Skripte oft nicht. WordPress-6.8-Sites meldeten Berichten zufolge GA4/Meta-Geisterbesuche, nachdem die Funktion automatisch aktiviert wurde. Sperren Sie Tracking auf document.prerendering / prerenderingchange.

Ihre CSP vergessen. Ein Inline-<script type="speculationrules"> schlägt unter einer Content Security Policy still fehl, es sei denn, script-src erlaubt 'inline-speculation-rules' (oder einen Hash/Nonce).

Erwarten, dass es Crawling oder Rankings hilft. Es berührt Googlebot nicht. Dies intern als “SEO-Fix für Crawl-Budget oder Rankings” zu verkaufen, setzt die falsche Erwartung – präsentieren Sie es als Core Web Vitals / Conversion-Gewinn für echte Chromium-Besucher.

Reichweite überschätzen. Es ist nur Chromium. Firefox- und Safari-Nutzer erhalten standardmäßig nichts, also modellieren Sie ROI nicht so, als gelte es für den gesamten Traffic.

Arbeitsbeispiele

Minimale, illustrative Regelblöcke. Passen Sie das Targeting an Ihre eigene Website an und schließen Sie immer zustandsändernde URLs aus.

1. Zwei explizite URLs prefetchen (sicherster Ausgangspunkt)

<script type="speculationrules">
{
  "prefetch": [
    { "urls": ["/pricing/", "/features/"] }
  ]
}
</script>

2. Dokumentregeln – Prefetch von Same-Site-Links bei Hover (moderate)

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

3. Eine hochvertrauenswürdige Seite vorrendern, gefährliche Pfade ausschließen

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout*" } },
          { "not": { "href_matches": "/cart*" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

4. Regeln über HTTP-Header statt Inline-Skript ausliefern

Speculation-Rules: "/speculation-rules.json"

…wobei /speculation-rules.json dasselbe JSON mit einem application/speculationrules+json-Inhaltstyp zurückgibt. Nützlich, wenn eine strenge CSP Inline-Skripte unangenehm macht.

5. Analytik davor schützen, während des Prerenderns auszulösen

if (document.prerendering) {
  document.addEventListener('prerenderingchange', sendPageview, { once: true });
} else {
  sendPageview();
}

Dies verzögert den Seitenaufruf, bis die Seite tatsächlich aktiviert wird – dasselbe Muster, das GA4s eigenes Skript verwendet.

Analytik sprang nach dem Prerender-Release

1. Pausieren Sie die Prerender-Regel, nicht das gesamte Performance-Programm. Behalten Sie eine Kopie der bereitgestellten Regel und stellen Sie den betroffenen Pfad zurück auf Prefetch oder keine Spekulation. Wenn der unerklärte Traffic aufhört, fahren Sie mit der Prerender-Untersuchung fort.
2. Trennen Sie Aktivierung vom Hintergrundladen. Reproduzieren Sie in Chromium und prüfen Sie document.prerendering vor der Navigation. Wenn Analytics auslöst, während es true ist, zeichnet das Tag eine Seite auf, die der Besucher nicht aktiviert hat.
3. Identifizieren Sie den auslösenden Eigentümer. Prüfen Sie GA4, benutzerdefinierte GTM-Tags, Ad-Pixel und hauseigene Events unabhängig. Wenn nur eine Quelle aufbläht, beheben Sie diese Integration, anstatt jede Regel zu schwächen.
4. Gaten Sie das Event. Verzögern Sie den Pageview oder die Impression bis prerenderingchange/Aktivierung. Wenn der Anbieter Prerendering bereits unterstützt, entfernen Sie doppelte benutzerdefinierte Auslöselogik.
5. Spielen Sie den Fall der abgebrochenen Navigation erneut ab. Lösen Sie ein Prerender aus, klicken Sie jedoch nicht. Das Event muss ausbleiben. Aktivieren Sie dann die Seite einmal und bestätigen Sie, dass genau ein Event aufgezeichnet wird.
6. Stellen Sie eng begrenzt wieder her. Aktivieren Sie ein hochvertrauenswürdiges Prerender-Ziel erneut, vergleichen Sie aktivierte Navigationen mit Analytics-Events und erweitern Sie nur, wenn die Zählungen ausgerichtet bleiben.

Überprüfen Sie eine Regelsammlung auf Nebenwirkungen

Review this Speculation Rules JSON and a list of site routes. Classify every matched
route as safe to prefetch, safe to prerender, or exclude. Explicitly flag logout,
add-to-cart, language/currency switching, OTP, allowance-changing, analytics, storage,
and ad-impression side effects. Check eagerness, scope, and likely resource waste.
Return the smallest safe rule set plus validation and rollback tests. Do not claim a
crawling, indexing, or direct ranking benefit.

Entwerfen Sie eine schrittweise Einführung

Create a staged Speculation Rules rollout for this click-path data and browser mix.
Start with prefetch, choose at most one or two high-confidence prerender targets, and
explain why each route is likely enough to justify its cost. Include Chromium-only
segmentation, analytics activation handling, CSP checks, success metrics, an abandoned
navigation test, and rollback triggers. Do not invent conversion or performance gains.

Fehlersuche bei fehlender Spekulation

Given this page markup, response headers, CSP, browser version, and DevTools evidence,
diagnose why a speculation rule was not used. Check invalid JSON, CSP blocking,
unsupported browser, rule mismatch, resource limits, cross-origin restrictions, and
browser discretion. Return symptom, evidence, likely cause, smallest fix, and the
exact evidence that would confirm it.

Checkliste für die sichere Spekulationsfreigabe

• Browser-Support-Daten rechtfertigen eine Chromium-only progressive Enhancement.
• Die erste Einführung verwendet Prefetch; Prerender ist auf ein oder zwei hochvertrauenswürdige Ziele beschränkt.
• Logout, Warenkorbänderungen, Login/OTP, Sprache/Währung, Berechtigungsänderungen und andere zustandsändernde GET-Routen sind ausgeschlossen.
• Vorgerenderte Seiten mutieren keinen Speicher und lösen keine Impressions vor der Aktivierung aus.
• Session-Storage-abhängige Logik wird sowohl vor als auch nach prerenderingchange getestet (eine vorgerenderte Seite beginnt mit einem Speicherklon, der bei der Aktivierung verworfen wird).
• Jedes Cross-Origin-Prerender-Ziel sendet Supports-Loading-Mode: credentialed-prerender; Cross-Site-Prerender wird gar nicht versucht.
• Benutzerdefinierte Analytics und Pixel prüfen document.prerendering und warten bei Bedarf auf prerenderingchange.
• CSP erlaubt die Inline- oder externe Spekulationsregel-Zustellungsmethode.
• Targeting und Eagerness basieren auf beobachtetem Navigationsverhalten, nicht auf einer Wildcard-Vermutung.
• DevTools bestätigt, dass die Regel gültig, berechtigt und nur für beabsichtigte URLs verwendet wird.
• Eine abgebrochene spekulative Last zeichnet keinen Pageview, keine Conversion und keine Zustandsänderung auf.
• Safari und Firefox erhalten weiterhin eine voll funktionsfähige normale Navigation.
• Leistungs- und Geschäftsergebnisse werden auf aktivierten Navigationen gemessen, wobei verschwendete Spekulation separat verfolgt wird.

Aktivierungs- und Analytics-Integrität

Durchzuführender Test: Lösen Sie ein Prerender ohne Klick aus, wiederholen Sie dann und aktivieren Sie die Seite einmal, während Sie Analytics und benutzerdefinierte Pixelanfragen beobachten.

Erwartetes Ergebnis: Das abgebrochene Prerender zeichnet keinen Pageview oder keine Impression auf; die aktivierte Navigation zeichnet genau eine auf.

Fehlerinterpretation: Ein Tag löst beim Hintergrundladen aus oder doppelte Aktivierungslogik zeichnet denselben Besuch zweimal auf.

Überwachungsfenster: Testen Sie vor der Freigabe, unmittelbar nach der Freigabe und nach Änderungen am Tag-Manager oder an der Analytics-Bibliothek.

Rollback-Auslöser: Deaktivieren Sie Prerender für die betroffene Route, wenn spekulative Lasten Sitzungen, Impressions, Conversions oder Attribution aufblähen.

Navigationsleistung und Verschwendung

Durchzuführender Test: Vergleichen Sie passende aktivierte Navigationen mit und ohne die Regel und zählen Sie Spekulationen, die nie aktiviert werden.

Erwartetes Ergebnis: Gezielte Chromium-Navigationen zeigen früheres Dokument-/Paint-Timing ohne ein inakzeptables Volumen ungenutzter Arbeit oder Regressionen auf der aktuellen Seite.

Fehlerinterpretation: Die Vorhersage ist schwach, die Eagerness zu aggressiv oder Hintergrundarbeit konkurriert mit der aktuellen Seite.

Überwachungszeitraum: Überprüfung während eines begrenzten Rollouts auf repräsentativen Geräten und Verbindungsklassen, bevor der Umfang erweitert wird.

Rollback-Auslöser: Zurückstufen von Prerender auf Prefetch oder Entfernen der Regel, wenn ungenutzte Anfragen oder Regressionen den gemessenen Nutzen der aktivierten Navigation überwiegen.

Ausschluss von Nebeneffekten

Durchzuführender Test: Jede übereinstimmende Route ohne Aktivierung ausführen und Serverstatus, Authentifizierung, Warenkorbinhalte, Nachrichten und Nutzungszähler prüfen.

Erwartetes Ergebnis: Keine spekulative Anfrage ändert den Benutzer- oder Serverstatus.

Fehlerinterpretation: Eine statusändernde GET-Route wurde übereinstimmend gefunden oder eine Seite führt während des Hintergrundladens Nebeneffekte aus.

Überwachungszeitraum: Erneut ausführen, wenn sich Routen, Dokumentregel-Selektoren oder Anwendungsnebenwirkungen ändern.

Rollback-Auslöser: Übereinstimmung sofort entfernen, wenn eine spekulative Anfrage einen Benutzer abmeldet, einen Warenkorb ändert, eine Nachricht sendet, ein Kontingent verbraucht oder eine Conversion aufzeichnet.

Bewertungstabelle für spekulative Navigation

Metrik: Leistung der aktivierten Navigation für berechtigte Chromium-Benutzer, gepaart mit Spekulationsaktivierungsrate und Genauigkeit der Analyseereignisse.

Was es Ihnen sagt: Ob die Vorhersage tatsächliche Navigationen zur nächsten Seite beschleunigt, wie oft vorab abgerufene/vorab gerenderte Arbeit tatsächlich genutzt wird und ob die Messung vertrauenswürdig bleibt.

So ziehen Sie es: Segmentieren Sie reale Benutzernavigation und Paint-Zeiten nach Browser und Regel-Exposition; protokollieren Sie Spekulationskandidaten und Aktivierungen; vergleichen Sie aktivierte Seitenaufrufe mit Analyseereignissen. Halten Sie Prefetch- und Prerender-Kohorten getrennt.

Benchmark oder realistischer Bereich: Verwenden Sie die eigene Vorab-Verteilung der Website und eine kontrollierte Holdout-Gruppe. Es gibt kein ehrliches universelles Aktivierungsraten- oder Conversion-Ziel; Browsermix, Pfadvorhersagbarkeit, Seitengewicht und Absicht unterscheiden sich je nach Website.

Rhythmus: Beobachten Sie Ressourcennutzung und Analyseintegrität während des Rollouts, überprüfen Sie Leistung und Aktivierung wöchentlich beim Optimieren der Regeln und führen Sie nach Änderungen an Navigation, Tagging, CSP oder Browserunterstützung eine erneute Prüfung durch.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• The Beginner’s Guide to Technical SEO — wo Page-Experience- und Performance-Themen wie dieses in das größere Bild passen.
• Core Web Vitals: What They Are and How to Improve Them — die LCP/INP-Metriken, die Speculation Rules tatsächlich für echte Benutzer verbessern. (Hinweis: Ich habe noch keinen speziellen Ahrefs-Leitfaden speziell zur Speculation Rules API — dieses Stück ist der Deep Dive; die Links hier sind meine nächste verwandte Abdeckung.)

Meine Vorträge

• What’s Next for Page Experience — SMX Next 2021 (SlideShare) — mein Page-Experience-Vortrag, der frühe Ladetechniken hervorhob (eine “Get Things Earlier”-Folie, die auf das damals experimentelle spekulative Prerendering verlinkte), was der modernen Speculation Rules API vorausgeht, aber auf dieselbe Idee verweist.
• How Search Works (SlideShare) — Crawling, Rendering, Indexierung und Ranking, nützlich, um die Browserebene von der Crawler-Ebene zu trennen. (Mein üblicher Haftungsausschluss gilt: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Aus der Branche

• Google Search nutzt jetzt die Speculation Rules API (Chrome for Developers) — Googles eigene Nutzung, mit den LCP/FCP-Millisekunden-Deltas.
• Wie Ray-Ban die Conversion-Rate durch Prerendering verdoppelt hat (web.dev) — die beste Fallstudie zu geschäftlichen Auswirkungen von Prerendering.
• Ein geschichteter Ansatz für Speculation Rules (Harry Roberts, CSS Wizardry) — die stärkste Umsetzungsbeschreibung eines unabhängigen Experten, einschließlich des Modells „Prefetch für TTFB, Prerender für LCP“.
• Google erklärt, warum sein Crawler Ihre Resource Hints ignoriert (Search Engine Journal) — Illyes‘ Kommentare vom Februar 2026 dazu, warum Googlebot nicht von Resource Hints profitiert (allgemein, nicht spezifisch für Speculation Rules).
• Google Search nutzt jetzt die Speculation Rules API, um die Suche zu beschleunigen (Search Engine Land) — Bestätigung der Chrome-Ankündigung durch die Fachpresse.
• Verhindern Sie verzerrte Analysen bei Verwendung von Speculation Rules (Erwin Hofman) — eine ausführliche Lösung für das GA4-Kontaminationsproblem.
• Schlüssel-URLs mit spekulativem Laden in WordPress eifrig vorab rendern (Weston Ruter, Google/WordPress core) — wie Sie den Standard von WordPress 6.8 über den Filter wp_speculation_rules_configuration anpassen.
• Blitzschnelle Websites mit Speculation Rules (DebugBear) — eine praktische Anleitung eines Performance-Tool-Anbieters.

Testen Sie sich: Speculation Rules

Fünf kurze Fragen dazu, was die Speculation Rules API kann – und was nicht. Wählen Sie für jede Frage eine Antwort und prüfen Sie dann.

Änderungsprotokoll