Was sieht Googlebot von Service Workern?

Unser Test in der Search Console

Für eine Progressive Web App wollten wir wissen, was Googlebot mit dem Service Worker macht. Dafür haben wir eine Testseite gebaut, die beim Laden eine Datei sw.js mit dem Scope „/“ registriert und das Ergebnis auf der Seite ausgibt. Diese Seite haben wir mit der URL-Prüfung der Search Console live getestet.

Eine Begründung liefert die Meldung nicht. Trotzdem liegt hier kein Fehler vor, denn Googlebot verhält sich so, wie Google den Renderer gebaut hat.

Warum führt Googlebot keine Service Worker aus?

Seit Mai 2019 rendert Googlebot mit einer aktuellen Chromium-Version. Google sprach damals von über 1.000 neuen Funktionen gegenüber dem alten Chrome 41, darunter ES6, IntersectionObserver und Web Components. Service Worker standen nicht auf der Liste.

Der Grund liegt im Aufbau des Web Rendering Service (WRS). Laut Google-Dokumentation behält er zwischen zwei Seitenaufrufen keinen Zustand. Cookies, Local Storage und Session Storage werden gelöscht, Berechtigungsanfragen lehnt Googlebot ab. Ein Service Worker nützt erst beim zweiten Besuch, weil er Dateien für später speichert. Für Googlebot ist jeder Aufruf ein erster Besuch, und Nutzer, die aus der Suche kommen, waren oft noch nie auf der Seite.

Die Falle bei der Feature-Erkennung

Die Abfrage 'serviceWorker' in navigator liefert im Renderer trotzdem true, weil Chromium die Schnittstelle kennt. Erst der Aufruf von register() scheitert. Fragst du nur die Unterstützung ab und machst danach Inhalte vom Service Worker abhängig, zeigst du Googlebot eine leere oder halbe Seite. In Server-Logs kann sw.js trotzdem als Abruf durch Googlebot auftauchen. Ausgeführt wird die Datei nicht.

Typische Fehlerbilder

In Foren und eigenen Analysen tauchen immer wieder dieselben Muster auf.

• Unterseiten nur über den Service Worker. Die App erwartet, dass der Nutzer zuerst die Startseite lädt und der Service Worker danach alle weiteren Seiten liefert. Googlebot ruft Unterseiten direkt auf und bekommt eine leere Hülle oder einen Fehler. Im Index landet im Extremfall nur die Startseite.
• SEO-Elemente ändern sich beim zweiten Besuch. Der Service Worker tauscht Title, Description oder strukturierte Daten aus, etwa für A/B-Tests. Googlebot sieht eine andere Fassung als Stammbesucher. Das kann als Cloaking gewertet werden.
• Cache-first bei wechselnden Inhalten. Stammbesucher sehen wochenlang alte Preise oder Texte, Googlebot den aktuellen Stand. Das Suchergebnis passt dann für viele Nutzer nicht zur Seite.
• Service Worker aus dem Framework-Standard. Starter-Vorlagen und PWA-Plugins bringen oft einen Service Worker mit aggressivem Caching mit, ohne dass das Team davon weiß.

So setzt du Service Worker SEO-sicher ein

1. Progressive Enhancement. Jede Seite funktioniert ohne Service Worker vollständig. Er beschleunigt nur wiederholte Besuche.
2. Fehler abfangen. Scheitert die Registrierung, läuft die Seite ohne Meldung weiter.
3. Inhalte serverseitig ausliefern. Server-Side Rendering oder statische Generierung für den ersten Aufruf, danach Hydration im Browser. Next.js, Nuxt, SvelteKit, Angular SSR und Gatsby bringen das mit.
4. Network-first für wechselnde Inhalte. Der Service Worker fragt zuerst den Server und greift nur bei Ausfall auf den Cache zurück.
5. Scope bewusst setzen. Eine sw.js unter /blog/ steuert nur URLs unter /blog/. Für die ganze Website gehört sie ins Root-Verzeichnis.
6. SEO-Elemente nie im Service Worker ändern. Title, Description, Canonical, Meta Robots, hreflang, strukturierte Daten und Open-Graph-Tags sind für alle Besucher gleich.

So sieht eine Registrierung aus, die Googlebot nicht stört.

So sieht eine einfache Network-first-Strategie im Service Worker aus.

Edge Worker als Alternative

Müssen Antworten für alle Besucher angepasst werden, etwa für Weiterleitungen oder Tests mit Metadaten, ist ein Edge Worker der passende Ort. Cloudflare Workers, Lambda@Edge, Fastly Compute oder Netlify Edge Functions laufen auf dem Server, bevor die Antwort den Browser erreicht. Googlebot bekommt dieselbe Antwort wie jeder andere Besucher. Braucht die Website weder Offline-Modus noch Background Sync, ist der Verzicht auf den Service Worker oft die einfachste Lösung.

So prüfst du deine Seiten

Den ersten Blick übernimmt unser Service Worker Test. Er zeigt, ob eine Seite einen Service Worker registriert, wofür sie ihn nutzt und was ein Crawler beim ersten Aufruf ohne ihn bekommt. Danach prüfst du von Hand weiter.

1. Chrome DevTools öffnen, Tab „Application“, Bereich „Service Workers“.
2. „Bypass for network“ aktivieren. Damit verhält sich der Browser beim Laden wie ohne Service Worker.
3. Unter „Storage“ mit „Clear site data“ alle gespeicherten Daten löschen.
4. Eine Unterseite direkt aufrufen und neu laden. Texte, Bilder, Navigation, crawlbare Links sowie Title und Meta-Tags im Quelltext müssen da sein.
5. In der Search Console die URL-Prüfung starten und „Live-URL testen“ wählen. Screenshot, gerendertes HTML und Konsolenmeldungen mit dem Quelltext vergleichen.

Die Meldung „Registration failed: Rejected“ in der Konsole ist dabei erwartbar. Entscheidend ist nur, ob ohne Service Worker alles da ist. Fehlt dann Inhalt, liegt ein Problem in der Architektur vor, das sich mit einer Einstellung nicht beheben lässt.

Service Worker Test von searchVIU

Der Test ruft eine URL auf wie ein neuer Besucher und rendert sie ohne aktiven Service Worker. So bekommt auch Googlebot jede Seite. Danach sucht der Test die Registrierung im Quelltext, im gerenderten HTML und in bis zu 15 Skripten der Seite. Das Service-Worker-Skript liest er aus, ohne es auszuführen.

• Registrierung mit Skript-Adresse, Scope und dem Header Service-Worker-Allowed. Liegt der Scope über dem Ordner des Skripts oder kommt das Skript mit falschem Content-Type, meldet der Test einen Fehler.
• Verwendung: Offline-Seite, Precache, Caching-Strategie je Ressourcentyp, Push-Nachrichten, Background Sync, Navigation Preload und die erkannte Bibliothek, etwa Workbox mit Version.
• Cache: die Offline-Seite und bis zu 10 Dateien aus dem Precache mit Statuscode. Fehlt eine Datei, bricht die Installation des Service Workers ab.
• Signale beim ersten Aufruf: Statuscode, Title, Canonical, Meta Robots, H1, Wörter und Links, dazu der Vergleich der gewählten Kennung mit Chrome.

Einen zweiten Aufruf, bei dem der Service Worker die Seite schon steuert, führt der Test noch nicht aus. Was Stammbesucher anders sehen, leitet er aus dem Skript ab.

Das frühere Tool auf searchviu.com war ein Selbsttest. Es registrierte einen Service Worker in dem Browser, der die Seite aufrief, und prüfte dort Cache, Messaging und Background Sync. Mit der URL-Prüfung der Search Console ließ sich so beobachten, wie Googlebot reagiert. Der neue Test prüft beliebige URLs von außen. Für Googlebots eigene Sicht bleibt die URL-Prüfung der Search Console der direkte Weg.

Was hat sich seitdem geändert?

Den Mobile-Friendly-Test, der 2020 einen zweiten Blick auf Googles Rendering bot, hat Google Ende 2023 eingestellt. Für den Test bleibt die URL-Prüfung der Search Console. Googles Dokumentation beschreibt den Renderer weiter als zustandslos und auf einer aktuellen Chromium-Version (Stand März 2026). Die Testseite zeigt beim Live-Test weiterhin dasselbe Ergebnis.

Häufige Fehler

• Die Feature-Erkennung gilt als Beweis, dass der Service Worker läuft.
• Inhalte oder interne Links kommen erst über den Service Worker auf die Seite.
• Bei fehlgeschlagener Registrierung zeigt die Seite eine Fehlermeldung oder bleibt leer.
• Cache-first für Seiten mit Preisen, Verfügbarkeiten oder News.
• Der Standard-Service-Worker des Frameworks bleibt ungeprüft aktiv.

Häufige Fragen