The hoops you'll have to jump through to use your domain with AMP

This is part of a series of articles on the repercussions of AMP adoption. AMP is being given special attention due to its potential to centralize control of the way the web is built. Read more: Google AMP lowered our page speed, and there’s no choice but to use it

An infuriatingly hacky situation exists on the web today, and people who publish content on the web have been powerless to remedy it: if your site is visited via Google Search and you’ve implemented Google’s AMP framework (which, if you’re a publisher, you essentially have to), your site appears to be coming from google.com - that’s what the URL bar says, and the server your site is sent from belongs to Google. The reader won’t even come into contact with your own server.

This might seem like a minor issue, but a domain name is a crucial facet of a business’ brand. Millions are spent on domain names. Users, including billions of non-technical users, rely on them to identify where information is coming from.

With AMP, URLs don’t mean what they used to, and sharing a link to a page is more confusing than it ever needed to be. AMP breaks conventions that users have adapted to since the dawn of the web itself.

On top of this hack, another is piled on in an attempt to partially remedy it: the ugly grey bar showing the content owner’s domain name. It’s a tacky, inelegant blemish that looks like it’s part of the page, not part of the browser UI. It makes all AMP pages look the same, like they’re a white-label content provider for google.com.

Google’s solution

Publishers have had to live with this situation for three years, since AMPs introduction, but this year, Google has come up with a solution, called Signed Exchanges. Let’s take a look at what’s required.

First you’ll need a new TLS certificate, called a SXG certificate, a special one which supports an extension called CanSignHttpExchanges. There’s only one company in the world that offers them so far, and it’ll cost you $198 a year. From what we can tell, you’ll still need your regular certificate in addition to this new SXG one, so you’ve now got a new expense every year.

Next you’ll need to run a new web server called AMP Packager, or amppkg. It works by creating “Signed HTTP Exchanges (SXGs)”, which are AMP documents that have been transformed and cryptographically signed. AMP Packager is a HTTP server that “sits behind a frontend server”, so you’ll need to run it in addition to your existing server.

To deploy amppkg in production, both it and your server have to be configured manually. You’ll need to:

• Manually configure your server to conditionally proxy requests to amppkg by URL and header
• Change the headers your server returns for all URLs pointing to an AMP page
• Automate the renewal of the SXG certificate and restart amppkg every 90 days or sooner
• Keep amppkg updated to a version specified by Googlebot in the headers it sends. Your AMP-on-your-own-domain will stop working (somehow) if you don’t
• On top of that, the system introduces new security concerns that publishers will need to handle to protect users and their privacy

So that’s a new HTTP server, new HTTP headers, new TLS certificate, and new daemons.

All of this so you can serve your users from your own domain like it’s 1999.

By the way, signed exchanges are only supported on Google Search (but not yet on the all-important carousel at the top of the page), and only supported on Chrome. Other browsers may follow suit, but both Mozilla and Apple are skeptical. Mozilla even considers the Signed HTTP Exchanges standard “harmful”.

It’s likely that tooling will improve in the future. But all these new moving parts will still need to be part of the mix of technologies serving your content.

That said, if you happen to be a Cloudflare customer, there is a simpler option.

Cloudflare’s “AMP Real URL”

Cloudflare announced recently that if you’re a customer, they can do a lot of this work for you - taking your AMP pages, signing them, and passing them on to Google’s AMP cache.

Slightly unnerving is the fact that in the same blog post, Cloudflare strongly implies that this service is something they could easily charge for, saying it’s free “not because our customers haven’t been excited or willing to pay for it” - that their motivation is, yes, to build an open internet, but also “we are hoping that this will motivate potential customers who value AMP to choose Cloudflare.”

So by requiring publishers to invest in a complex new technology just to avoid punishment on Google’s search results, Cloudflare get’s a captive audience of potential new customers.

Cloudflare’s solution is complicated and required significant development effort, so it’s not inconceivable that they’ll charge for the service in the future. Other CDNs may follow suit in providing a similar service, so hopefully publishers won’t be locked into using Cloudflare. But even if there will be choice, it means that putting your content on the web - without being penalized on Google - requires a new middle man, unless you’re willing to roll your own solution.

Publishers are being pressured by Google to do all this - on their own dime - just to access the most lucrative position on Google’s results page. Were it not for Google’s monopoly, getting publishers to play ball would have been much more difficult.