Learn more about Signed HTTP Exchanges (SXGs)
Automatic Signed Exchanges (SXGs) are an open, standard delivery mechanism that makes it possible to authenticate the origin of a resource, independent of how it was delivered. This enables faster delivery of a website from a third party — such as Google itself from its search results page — or from a news aggregator that is linking out to other sites. This decoupling enables a variety of use cases, such as prefetching, offline Internet experiences, and serving from third-party caches. It does so in a secure and privacy-preserving manner, and Cloudflare automatically handles all packaging and certificate handling.
For more details regarding how SXGs work, please check out the announcement blog post.
What are the requirements for enabling SXGs?
Signed Exchanges have a few requirements:
- SXGs are available for zones with a Pro or higher plan. SXGs are also available for zones on a Free plan with an APO subscription.
- SXGs only works with zones that have their nameservers managed by Cloudflare. Learn here how to change your domain nameservers to Cloudflare. After enabling your nameservers to be managed by Cloudflare, log in to the Cloudflare dashboard, select your domain and go to DNS. In Proxy status, enable the Cloudflare proxy in any relevant DNS records by clicking the grey clouds. When proxied through Cloudflare, the cloud will be orange.
- Zone certificates need to be managed by Cloudflare.
- Note: To obtain an SXG certificate, you need to add a CAA Record for issuance of the certificate from the Certificate Authority. Cloudflare adds the corresponding CAA records in DNS on behalf of users after they enable SXGs, to make sure issuance is not blocked. If you would like to obtain SSL certificates that are issued by other CAs, please ensure that you add the CAA records for the CAs after enabling the SXG.
- Content needs to be cached in intervals of 120 seconds or longer, as Google checks this setting to generate an SXG. To ensure that content is cached every two minutes or more, go to the Cloudflare dashboard > Caching > Configuration > Browser Cache TTL and check the length of time Cloudflare instructs a browser to cache files.
- AMP Real URL needs to be disabled if SXGs is enabled. To do that, go to the Cloudflare dashboard > Speed > Optimization > AMP Real URL and click the toggle to disable this setting.
How to enable SXGs
If your account satisfies the requirements to enable SGXs:
- Log in to the Cloudflare dashboard and select your account and domain.
- Go to Speed > Optimization.
- Scroll down to Automatic Signed Exchanges (SXGs) and toggle the button to enable it.
- Currently, signed exchanges are only used by Google for Android search. Google is working on implementing support for SXGs on desktop browsers.
- Google only loads Signed Exchanges for the top results.
- Signed exchanges can strip out certain cookies and headers, and create problems with dynamic content. The following hop-by-hop and other uncached headers will be stripped during the signed exchange generation:
- Hop-by-hop header fields listed in the Connection header field (section 6.1 of RFC7230).
- Header fields listed in the no-cache response directive in the Cache-Control header field (section 126.96.36.199 of RFC7234).
- Header fields defined as hop-by-hop:
- Since Cloudflare cannot be sure whether a signed exchange includes private information or not, a signed exchange will not be generated in the presence of the following headers:
There are a couple of ways to ensure that SXGs are working properly for your zone:
1. Run the following command in your terminal:
curl -svo /dev/null https://example.com -H "Accept: application/signed-exchange;v=b3"
2. Verify that the
Content-Type is set to
- On a desktop computer, open Chrome.
- Go to View > Developer > Developer Tools.
- Click the Toggle device toolbar button, and select an Android device.
- Click the Network tab in Chrome’s developer tools.
- With the Network tab open, search Google for your zone plus your website. For example, yourdomain.com + website.
- Refer to the Network tab in Chrome’s dev tools. In the Type column you should see the result with
signed-exchange / Redirect.
- For a list of tools that you can use to debug SXG, please refer to web.dev's guide to SXG tools.
- If it’s an AMP page, you can refer to the AMP status report — Search Console Help, which explains the impact using SXGs has on AMP pages.
- For non-AMP cases, or non-AMP SXGs customers, there isn’t yet a help page which would describe the error type breakdown. However, if there are any critical errors that would warrant disabling the SXGs:
- To ensure that Googlebot is able to crawl and index a page served by SXG, take these steps:
- Verify that the
Content-Typeis set to
- Run the command dump-signedexchange and make sure it finishes without errors.
- Check that the signed URL matches the request URL.
- Verify that the
No. Google can still parse the signed exchange and treat it like normal HTML. In the case of an AMP page, Google should fall back to treat it like it would treat a regular AMP page.
We use Digicert for SXGs certificate issuance. Once SXGs is enabled, we add the CAA records on behalf of the zones:
% dig example.com caa ;; ANSWER SECTION: example.com. XXXX IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes" example.com. XXXX IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
No. This is for an unreleased/in-development feature. It’s safe to block those requests, and users can ignore them.