Premiers pas avec les échanges signés dans la recherche Google

Les échanges signés (SXG) permettent à la recherche Google de précharger votre contenu tout en préservant la confidentialité de l'utilisateur. Dans la pratique, cela signifie que les résultats AMP et les résultats standards qui apparaissent dans la recherche Google peuvent précharger quelques ressources clés (telles que du code HTML, JavaScript, CSS, des images ou des polices) en respectant la confidentialité, si le site Web associé est compatible avec les échanges signés.

Lorsque l'utilisateur clique sur le résultat final, la page Web commence à s'afficher bien plus tôt, car les ressources clés sont déjà disponibles, ce qui optimise l'expérience utilisateur. Cela peut contribuer à améliorer le score LCP (Largest Contentful Paint) pour votre contenu. Même si la recherche Google ne considère pas l'utilisation des échanges signés comme un facteur de classement direct, un LCP plus faible peut influer sur le classement, car l'expérience sur la page fait partie des facteurs de classement.

Mettre en œuvre un échange signé

Pour implémenter un échange signé, suivez le guide détaillé de web.dev.

Pour les pages AMP, reportez-vous au guide détaillé disponible sur amp.dev.

Google utilise un cache d'échanges signés pour précharger votre contenu. Ceux-ci peuvent être diffusés plusieurs fois.

Pour vous assurer que le contenu à jour s'affiche dans la recherche Google, définissez les valeurs d'expiration des échanges signés correctement. En règle générale, assurez-vous que la date d'expiration est inférieure à ces deux dates :

  • Délai d'expiration défini par vos en-têtes de contrôle du cache HTTP
  • Un jour après si le contenu est au format JavaScript ou intègre JavaScript (sinon, sept jours après)

Pour vous assurer que le contenu s'affiche correctement sur différents appareils, procédez comme suit :

  1. Migrez le contenu personnalisé, tel que les paniers d'achat, dans des éléments à chargement différé qui se trouvent en dehors de l'échange signé. Par exemple, ne signez que les ressources dans lesquelles l'en-tête Cache-Control inclut l'instruction public.
  2. Créez les pages à l'aide du Responsive Web Design. Vous pouvez également diffuser des pages pour ordinateur et pour mobile sur des URL distinctes ou annoter les pages pour indiquer qu'elles ne sont pas responsives à l'aide de la balise Meta supported-media. Par exemple, dans l'élément <head> de la page, ajoutez la balise suivante :
    <meta name=supported-media content="only screen and (max-width: 640px)">

Vérifier la configuration de l'échange signé

Pour vous assurer que Googlebot peut explorer et indexer une page diffusée par échange signé, procédez comme suit :

  1. Vérifiez que l'élément Content-Type est défini sur application/signed-exchange;v=b3.
  2. Assurez-vous que la commande dump-signedexchange aboutit.
  3. Vérifiez que l'URL signée correspond exactement à l'URL de la requête.

Surveiller et déboguer un échange signé

Pour obtenir une liste des outils que vous pouvez utiliser pour déboguer un échange signé, consultez le guide concernant les outils SXG sur web.dev.

Pour les pages standards, utilisez le rapport de statistiques sur l'exploration pour surveiller les erreurs d'exploration.

Pour les pages AMP, utilisez le rapport d'état AMP dans la Search Console pour identifier les erreurs SXG.

Déboguer le cache d'échanges signés Google

Pour déterminer si l'échange signé respecte les conditions requises en matière de cache, interrogez directement le cache d'échanges signés Google. Par exemple, si l'URL de l'échange signé est https://signed-exchange-testing.dev/sxgs/valid.html, formulez l'URL du cache correspondante :

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

L'algorithme permettant de calculer le sous-domaine et le suffixe du chemin de l'URL est identique à celui du cache AMP, alors que la chaîne infix /doc/-/ est différente.

Si la réponse correspond à un échange signé, cela signifie que la réponse du serveur d'origine respecte les conditions requises pour le cache d'échanges signés Google. Dans le cas contraire, elle inclut un en-tête HTTP indiquant la raison.

  • S'il existe un en-tête Warning, elle indique une erreur qui empêche l'échange signé de respecter les conditions requises en matière de cache.
  • S'il existe un en-tête Location, elle n'a pas encore été récupérée par le cache. Il ne s'agit pas d'une erreur au niveau de l'échange signé.

Quelle que soit la réponse, le cache met en file d'attente toute requête envoyée à l'URL d'origine pour obtenir une version mise à jour. Plusieurs facteurs déterminent l'échec ou le succès de cette requête et, le cas échéant, le moment où elle a lieu, y compris la vitesse d'exploration de Googlebot pour votre site.

Google ne met pas en cache les fichiers SXG pendant une durée plus longue que la valeur expires de la signature SXG ou que la durée de vie de l'en-tête externe non signé de la réponse SXG.

Pour les pages AMP, vous pouvez utiliser l'outil d'inspection d'URL pour déboguer les erreurs de mise en cache.

Rester informé

Abonnez-vous à la webpackaging-announceliste de diffusion pour recevoir une notification lors des modifications suivantes :

  • Modifications apportées au cache d'échanges signés Google (ajout ou suppression de fonctionnalités)
  • Modifications majeures apportées au package Web des outils SXG, au module SXG NGINX et à libsxg

Pour toute question concernant les échanges signés dans la recherche Google, consultez le site de la communauté d'aide Search Central.