Einführung in Signed Exchanges in der Google Suche

Mithilfe von Signed Exchanges (SXG) kann die Google Suche deine Inhalte vorab abrufen. Die Privatsphäre der Nutzer bleibt dabei geschützt. Das heißt, dass in der Google Suche angezeigte AMP- und Nicht-AMP-Ergebnisse wichtige Ressourcen vorab abrufen können, wie HTML, JavaScript, CSS, Bilder oder Schriftarten, 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 wiederum die Nutzerfreundlichkeit der Seite erhöht. Durch dieses Verfahren kannst du einen niedrigeren Largest Contentful Paint (LCP) für deine Inhalte erreichen. Für die Google Suche ist die Verwendung von SXG zwar kein unmittelbarer Faktor für das Ranking, dennoch kann sich der niedrigere LCP darauf auswirken, da die Nutzerfreundlichkeit von Seiten für das Ranking eine Rolle spielt.

SXG implementieren

Informationen zur Implementierung von SXG findest du im ausführlichen Leitfaden von web.dev.

Über AMP-Seiten kannst du dich im ausführlichen Leitfaden von amp.dev informieren.

Google ruft deine Inhalte vorab mithilfe eines SXG-Cache ab. 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 diesen beiden Daten liegen muss:

  • Das von deinen Headern zur Steuerung des HTTP-Cache festgelegte Ablaufdatum
  • 1 Tag in der Zukunft, wenn die Inhalte JavaScript- oder Inline-JavaScript sind; ansonsten 7 Tage in der Zukunft

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

  1. Verschiebe personalisierte Inhalte, wie beispielsweise Einkaufswagen, in Lazy-Loading-Elemente außerhalb der SXG. Signiere beispielsweise nur Ressourcen, bei denen der Header cache control auf die Anweisung public gesetzt ist.
  2. Erstelle die Seiten mit responsivem Webdesign. Alternativ kannst du Desktop- und mobile Seiten unter separaten URLs ausliefern oder die Seiten als Hinweis darauf, dass sie nicht responsiv sind, mit dem supported-media-Meta-Tag 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-Einrichtung überprüfen

So sorgst du dafür, dass der Googlebot eine von SXG bereitgestellte Seite crawlen und indexieren kann:

  1. Sieh nach, ob Content-Type auf application/signed-exchange;v=b3 gesetzt ist.
  2. Achte darauf, dass der Befehl dump-signedexchange erfolgreich ausgeführt wird.
  3. Prüfe, ob die signierte URL genau mit der Anfrage-URL übereinstimmt.

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.

Verwende für Nicht-AMP-Seiten den Bericht „Crawling-Statistiken“, um Fehler beim Abruf zu beobachten.

Verwende für AMP-Seiten den AMP-Statusbericht in der Search Console, um SXG-Fehler zu beobachten.

Fehler für den Google SXG Cache beheben

Frage den Google SXG Cache direkt ab, um festzustellen, ob SXG die Cache-Anforderungen erfüllen. Schreibe beispielsweise bei einer SXG-URL https://signed-exchange-testing.dev/sxgs/valid.html die entsprechende Cache-URL:

http://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/-/ ist jedoch anders.

Wenn es sich bei der Antwort um einen SXG handelt, bedeutet dies, dass die Antwort vom Ursprungsserver den Google SXG Cache-Anforderungen entspricht. Andernfalls enthält sie einen HTTP-Header, der den Grund angibt.

  • Wenn es einen Warning-Header gibt, zeigt dieser einen Fehler an, durch den der SXG die Cache-Anforderungen nicht erfüllen konnte.
  • Wenn es einen Location-Header gibt, wurde dieser noch nicht aus dem 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. Mehrere Faktoren bestimmen, ob und wann diese Anfrage erfolgt. Dazu zählt auch die Crawling-Frequenz des Googlebots für deine Website.

Für AMP-Seiten kannst du mithilfe des URL-Prüftools Caching-Fehler beheben.

Auf dem Laufenden bleiben

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

  • Änderungen am Google SXG Cache, die neue Funktionen ermöglichen oder andere Funktionen einstellen.
  • Wichtige Änderungen an den SXG-Tools Web Packager, NGINX SXG Module und libsxg.

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