How Webnovel Used Google AMP WebPackage and Signed HTTP Exchanges to Preserve Its Brand URL

Webnovel (the overseas brand of Qidian) adopted Google AMP for its homepage and reading pages early last year, which improved speed but caused the search result landing page URL to show Google’s domain, confusing users and affecting brand visibility.

Google responded by releasing the AMP WebPackage technology, which allows the original domain to be displayed while still serving cached content.

WebPackage Background

Unlike traditional bundlers such as Webpack, WebPackage lets you package files for third‑party delivery while browsers still recognize your real domain, avoiding the need to expose private TLS certificates to CDN providers.

This capability directly solves the URL‑masking issue caused by AMP caching.

Implementing Signed‑HTTP‑Exchanges (SXG)

To enable WebPackage, the content returned to Google’s crawler must be encrypted with a certificate that supports the SXG extension. The implementation consists of three main steps.

1. Obtain an SXG‑compatible certificate

You need a certificate from a CA that supports the SXG extension (currently Digicert) and uses an EC key with the prime256v1 curve. This certificate is only used to encrypt the AMP document served to Google’s crawler.

2. Deploy amppkg on your server

Follow the official amppkg instructions; the only notable configuration is to set QueryRE = ".*" to capture query strings.

<code>amppkg.toml
----------
Port = 'port listening'
CertFile = 'path/to/fullchain.pem'   # SXG cert from your CA
KeyFile = 'path/to/privkey.pem'      # SXG cert key
OCSPCache = '/tmp/amppkg-ocsp'
[[URLSet]]
[URLSet.Sign]
Domain = "amppackageexample.com"
QueryRE = ".*"   # to capture query string
</code>

3. Configure AMP SXG back‑origin

The following diagram shows the back‑origin architecture (image omitted for brevity). You then set up Nginx (or similar) to route requests based on the AMP-Cache-Transform header:

<code>upstream amppkg { proxy_pass http://IP:PORT; }
upstream webnovelBackend { proxy_pass http://IP:PORT; }
location ^~ /amp/ {
    if ($http_amp_cache_transform = "google") {
        rewrite ^/(.*)$ /ampSXG/$1 last;
        break;
    }
    add_header Vary "AMP-Cache-Transform, Accept";
    proxy_pass http://webnovelBackend;
}
location ^~ /ampSXG/ {
    proxy_pass http://amppkg/priv/doc/https://m.webnovel.com/;
}
location ^~ /amppkg/ {
    proxy_pass http://amppkg/amppkg/;
}
</code>

When Google’s crawler fetches an SXG‑encrypted AMP document, it first makes a normal request. If the response includes the header Vary: AMP-Cache-Transform,Accept , the crawler makes a second request with AMP-Cache-Transform: google , which your reverse proxy detects and forwards to the amppkg server to serve the signed exchange.

The SXG certificate is only used for encrypting the content; the connection between the reverse proxy and amppkg remains HTTP.

Results

After enabling AMP WebPackage with SXG, Webnovel observed lower bounce rates and higher pages‑per‑session compared to the previous AMP implementation. As Chrome 73+ adoption grows, the performance benefits are expected to become more pronounced.

Tip: By mapping AMP URLs to their corresponding Google Cache addresses, users can stay within the cached environment for as many interactions as possible, falling back to the origin site only when necessary.