Fixing the AMP Signed Exchange issues in Google Search Console
Starting last year, Google began using the Signed Exchange or SXG service to link to signed AMP pages served by its cache, allowing content to be preloaded without loss of privacy and to assign the content to the right origin,because the user displays the original URL. With the spread of the system, it has become important for users to verify the correctness of the process and, for this, the Mountain View team has added a new feature to the Google Search Console.
Un nuovo tool per gli errori con SXG
The announcement comes from the blog of Webmaster Central, which explains first of all what is the Signed Exchanges (SXG) protocol, meaning a subset of the emerging family of specifications called Web Packaging that allows publishers to make their content safely portable, maintaining integrity and attribution to the publisher.
Now “sites that implement SXG for their AMP pages will be able to understand if there are problems that prevent Google from providing the SXG version of their page using Google AMP Cache“, write Amir Rachum, Search Console Software Engineer, and Jeffrey Jose, Google Search Product Manager.
How to solve problems with Signed Exchanges
To use the tool you have to open the report on the status of the AMP pages of the GSC, where you can check if the site has problems related to SXG by simply looking for warnings that report “signed exchange” in the name (as you see in the image); Google will also report new problems by e-mail.
To help with debugging and to verify that a specific page is served using SXG, we can inspect a URL using the URL Inspection Tool and find out if any problems related to SXG are displayed in the AMP section of the analysis. We can both diagnose problems affecting the indexed version of the page and use the “live” option, which will verify the validity of the live version currently served by our site.
Main problems with Signed Exchange
As the Search Console guide explains, there are 12 main problems that can occur with SXG, each of different entities and consequences and, of course, different path for the correction (described in detail in the linked page). In detail:
- The standard Signed Exchange is not valid.
This situation occurs if the HTTP response is a Signed Exchange standard that does not meet the requirements of the Google AMP Cache: the page is shown to users without signature information. For a site, this means that the page is presented in an AMP viewer with a Google URL instead of the original URL.
- The standard Signed Exchange payload presents an analysis error.
This happens if the “payload” of the Signed Exchange gives an HTTP answer that does not meet the requirements of the Google AMP Cache: also in this case, the page is shown without signature information and with a Google URL instead of with the original one.
- The “header_name” heading for the standard Signed Exchange payload presents an invalid value.
The HTTP response is a Signed Exchange that contains a signed reply header that does not meet one of the requirements of Google AMP Cache: the consequences are always the absence of signature information and the use of the Google URL.
- The mandatory “header_name” heading of the standard Signed Exchange payload is missing.
Similar effects of this error, which depends on an HTTP response that generates a Signed Exchange where the specified header is missing, required by the Signed Exchange specifications or the Google AMP Cache requirements.
- The signature header for the standard Signed Exchange cannot be analyzed.
The same situation (no information about signing and displaying the Google URL) also occurs when the HTTP response is a Signed Exchange that contains an incorrect signature header according to the Signed Exchange specifications.
- The “parameter_name” in the standard Signed Exchange signature header is not valid.
The impact on the site is always similar when the HTTP response is a Signed Exchange whose signature header has an incorrect value for the specified parameter, as required by the Signed Exchange specifications.
- Dates for the standard Signed Exchange are invalid.
Another problem that causes the inability to show signature information and the original URL of the AMP page occurs when the HTTP response is a Signed Exchange which signature header has an incorrect value for the date or expires parameter , as required by Signed Exchange specifications or Google AMP Cache requirements. In particular, remember the guide, the signature must be valid at the time of recovery and at least for the following four days.
- The certificates chain referenced by the “cert-url” of the standard Signed Exchange cannot be analyzed.
In this error – that has identical effects to those already described – the HTTP answer is a Signed Exchange which cert-url is not correct according to the Signed Exchange specifications.
- The certificates chain referenced by the “cert-url” is invalid for the standard Signed Exchange.
It happens if the HTTP response is a Signed Exchange whose cert-url is not valid according to the Signed Exchange specifications: the impact on the pages remains that of the other problems analyzed.
Beside these setbacks – which resolution is optional, also because they do not have particularly penalizing effects for the pages, that they come however indexed and shown in the Search, although with the limitations described – there are then three more problematic errors, that are:
- The standard Signed Exchange cannot be analyzed.
It happens when the HTTP response has a type of application/signed-exchange content; v=b3, but Google could not extract the body of the response, because this failed to meet the high-level requirements of that type or because its payload is improperly Merkle-encoded. This error prevents the indexing of the AMP page: if the site offers a corresponding page not AMP, the Google search will show the one among the results; Otherwise, the page may not be fully displayed in the Search.
- The URL for the internal payload does not match the URL of the request for the standard Signed Exchange.
This issue has a similar impact on the site than the last one, and happens when the HTTP response is a Signed Exchange which reserve Urls do not match the URL of the request (they must be equal byte by byte). As a result, “Google Search does not trust that the response is representative of the request’s URL” and may prevent its indexing.
- The “header_name” for the HTTP answer of the standard Signed Exchange has an invalid value.
The latter error also causes negative effects on the appearance of the AMP page in Search: the problem occurs when the HTTP response has a type of application/signed-exchange content, but the response headers are not valid for other reasons. “For example, the content type may lack a v=b3 parameter”, and as a result “the format is not known to Google and therefore the body of the response cannot be extracted”.
