Einführung in Signed Exchanges in der Google Suche

Mithilfe von Signed Exchanges (SXG) können deine Inhalte in der Google Suche vorab abgerufen werden und dabei den Datenschutz für Nutzer einzuhalten. Das heißt, dass in der Google Suche angezeigte AMP- und Nicht-AMP-Ergebnisse wichtige Ressourcen, wie HTML, JavaScript, CSS, Bilder oder Schriftarten, unter Einhaltung des Datenschutzes vorab abrufen können, wenn die entsprechende Website SXG unterstützt.

Wenn der Nutzer dann auf das Ergebnis klickt, wird die Webseite wesentlich schneller gerendert, da wichtige Ressourcen bereits verfügbar sind, was die Nutzerfreundlichkeit der Seite erhöht. So kannst du einen niedrigeren LCP-Wert (Largest Contentful Paint) für deine Inhalte erreichen. Auch wenn sich die Verwendung von SXG nicht unmittelbar auf das Ranking der Suchergebnisse bei Google auswirkt, kann ein niedriger LCP-Wert von Vorteil sein, weil beim Ranking auch die Nutzerfreundlichkeit von Seiten eine Rolle spielt.

SXG implementieren

Informationen zur Implementierung von SXG findest du in diesem ausführlichen Leitfaden von web.dev. Halte dich nach der Implementierung an diese Anleitung zum Messen und Optimieren der Leistungsverbesserung mit SXG.

AMP-Seiten werden in diesem ausführlichen Leitfaden von amp.dev behandelt.

Zusätzliche Anforderungen für die Google Suche

Um deine Inhalte vorab abrufen zu können, nutzt Google einen SXG-Cache. Diese im Cache gespeicherten SXG-Inhalte stellt Google möglicherweise mehrmals bereit.

Achte darauf, das Ablaufdatum der SXG-Inhalte richtig einzustellen, damit die in der Google Suche angezeigten Inhalte aktuell bleiben. Generell gilt, dass das Ablaufdatum vor den folgenden beiden Datumsangaben liegen muss:

dem Cache-Ablaufdatum, das von deinen HTTP-Headern festgelegt wird
dem Datum, das einen Tag in der Zukunft liegt, wenn es sich bei den Inhalten um JavaScript oder Inline-JavaScript handelt; ansonsten dem Datum 7 Tage in der Zukunft

So sorgst du dafür, dass Inhalte auf mehreren Geräten richtig angezeigt werden:

Verschiebe personalisierte Inhalte, wie beispielsweise Einkaufswagen, in Lazy-Loading-Elemente außerhalb von SXG. Alternativ kannst du den signierten Header Vary: Cookie hinzufügen. SXGs mit diesem Header werden nur Besuchern ohne Cookie für deine Website angezeigt.
Erstelle die Seiten mit responsivem Webdesign. Alternativ kannst du Desktopseiten und mobile Webseiten unter separaten URLs ausliefern oder die Seiten als Hinweis darauf, dass sie nicht responsiv sind, mit dem meta-Tag supported-media kennzeichnen. Füge beispielsweise im <head>-Element der Seite das folgende Tag hinzu:
```
<meta name=supported-media content="only screen and (max-width: 640px)">
```

SXG beobachten und Fehler beheben

Eine Liste der Tools, mit denen du SXG debuggen kannst, findest du im Leitfaden zu SXG-Tools von web.dev.

Falls der Googlebot einen SXG nicht parsen kann, wird die URL ohne application/signed-exchange;v=b3 im Accept-Header möglicherweise noch einmal gecrawlt, um die Variante text/html abzurufen. Sollten SXG-Indexierungsfehler auftreten, verlinkt die Google Suche auf die ursprüngliche URL ohne SXG.

Bei AMP-Seiten steht für die Überwachung von SXG-Fehlern der AMP-Statusbericht zur Verfügung.

Fehler im Zusammenhang mit dem Google-SXG-Cache beheben

Wenn du wissen möchtest, ob SXG die Cache-Anforderungen erfüllt, kannst du die Chrome-Erweiterung zur SXG-Validierung verwenden.

Alternativ kannst du auch den SXG-Cache von Google direkt abfragen. Lautet die SXG-URL beispielsweise https://signed-exchange-testing.dev/sxgs/valid.html, sollte die zugehörige Cache-URL so formuliert werden:

https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html

Der Algorithmus zum Berechnen der Subdomain und des URL-Pfad-Suffixes ist derselbe wie der für den AMP-Cache, der Infix-String /doc/-/ lautet jedoch anders.

Wenn als Antwort ein SXG zurückgegeben wird, bedeutet dies, dass die Antwort vom Ursprungsserver den Anforderungen des Google-SXG-Caches entspricht. Andernfalls enthält sie einen HTTP-Header, der den Grund angibt.

Wenn es einen Warning-Header gibt, verweist das auf einen Fehler, aufgrund dessen der SXG die Cache-Anforderungen nicht erfüllen konnte.
Wenn es einen Location-Header gibt, wurde dieser noch nicht durch den Cache abgerufen. Dies ist kein Fehler in deinem SXG.

Unabhängig von der Antwort reiht der Cache eine Anfrage nach einer aktualisierten Kopie an die ursprüngliche URL ein. Ob und wann diese Anfrage erfolgt, hängt von mehreren Faktoren ab. Dazu zählt auch die Crawling-Frequenz des Googlebots für deine Website.

Google speichert SXGs nicht länger im Cache, als der expires-Wert der SXG-Signatur oder die Aktualität der unsignierten Header der SXG-Antwort angibt.

Bei AMP-Seiten kannst du Caching-Fehler mithilfe des URL-Prüftools suchen und beheben.

Auf dem Laufenden bleiben

Abonniere die webpackaging-announce-Mailingliste, um aktuelle Informationen zu folgenden Änderungen zu erhalten:

Änderungen am Google-SXG-Cache, mit denen neue Funktionen eingeführt und bestehende Funktionen eingestellt werden.
Wichtige Änderungen am SXG-Tool Web Packager, am Modul NGINX SXG und an libsxg.

Wenn du Fragen zu SXG in der Google Suche hast, findest du im Hilfeforum von Google Search Central weitere Informationen.