Get started with signed exchanges on Google Search
When the user ultimately clicks the result, the web page starts rendering much sooner since key resources are already available, leading to a better user experience. This could mean a lower Largest Contentful Paint (LCP) score for your content. While Google Search doesn't consider use of SXG as a direct factor in ranking, the lower LCP may affect ranking because page experience will be a ranking factor.
To implement SXG, follow web.dev's in-depth guide.
For AMP pages, follow amp.dev's in-depth guide.
Additional requirements for Google Search
Google uses a cache of SXG to prefetch your content. Google may serve these cached SXG multiple times.
To make sure that up-to-date content displays in Google Search, set the SXG expiration values appropriately. As a rule of thumb, make sure that the expiration date is less than both of these dates:
- The cache expiration determined by your HTTP headers
To make sure that content displays properly when served on multiple devices, do the following:
- Move personalized content, such as shopping carts, into lazy-loaded elements that are
outside of the SXG. For instance, only sign resources where the
Cache-Controlheader includes the
- Build the pages with responsive
web design. Alternatively, serve desktop and mobile pages on
separate URLs, or annotate the
pages to state that they aren't responsive, using the
supported-mediameta tag. For example, in the page's
<head>element, add the following tag:
<meta name=supported-media content="only screen and (max-width: 640px)">
Monitor and debug SXG
For a list of tools that you can use to debug SXG, check out web.dev's guide to SXG tools.
For non-AMP pages, use the Crawl
Stats report to monitor for fetch errors. In the event that Googlebot can't parse an SXG,
it may recrawl the URL without
application/signed-exchange;v=b3 in the
Accept header, in order to retrieve the
Debug the Google SXG cache
To determine whether SXG meets the cache requirements, query the Google SXG cache directly.
For example, if the SXG URL is
the corresponding cache URL:
The algorithm for computing the subdomain and the URL path suffix is the
as for the AMP cache, while the infix string
/doc/-/ is different.
If the response is a SXG, then this means the response from the origin server meets the Google SXG cache requirements. Otherwise, it will include an HTTP header that indicates the reason.
- If there is a
Warningheader, then it indicates an error that prevented the SXG from meeting the cache requirements.
- If there is a
Locationheader, then it has not yet been fetched by the cache. This is not an error in your SXG.
Regardless of the response, the cache enqueues a request to the original URL for an updated copy. There are several factors for when and if this request happens, including the Googlebot crawl rate for your site.
Google doesn't cache SXGs for longer than the
expires value of the SXG signature
lifetime of the unsigned outer headers of the SXG response.
For AMP pages, you can use the URL Inspection Tool to debug caching errors.
Subscribe to the webpackaging-announce mailing list to stay up-to-date with the following changes:
- Changes to the Google SXG cache that enable new capabilities or deprecate other capabilities.
- Major changes to the SXG tools Web Packager, NGINX SXG module, and libsxg.
If you have questions about SXG on Google Search, visit the Search Central Help Community.