The Two Faces of AMP


The day after AMP was launched, I published a post with a bunch of concerns I had—most notably, that of the incentives being put around building AMP content.

This promise of improved distribution for pages using AMP HTML shifts the incentive. AMP isn’t encouraging better performance on the web; AMP is encouraging the use of their specific tool to build a version of a web page. It doesn’t feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web.

It’s a concern that has been stated over and over again in the two-plus years of AMP’s existence, by numerous developers. It finally boiled over recently, resulting in the publication of the AMP letter which at the time I’m writing this has been signed by 640 people and seven organizations (and also, to my knowledge, has not been formally addressed by the AMP team).

The letter calls on the AMP team to make two primary changes:

  1. Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice.

  2. Do not display third-party content within a Google page unless it is clear to the user that they are looking at a Google product. It is perfectly acceptable for Google to launch a “news reader”, but it is not acceptable to display a page that carries only third-party branding on what is actually a Google URL, nor to require that third-party to use Google’s hosting in order to appear in search results.

AMP has indeed made a few changes to help with problem number two a little bit. There’s still some work to be done there, but it’s a good sign.

But there has been no indication of any attempt to address the first issue, that of incentivization and premium placement. In fact, not only has there been no attempt to fix it, it appears the AMP team is doubling-down on those incentives instead.

Yesterday they announced a new extension to the AMP format: AMP stories. AMP stories will be familiar to anyone who has looked at more openly proprietary formats like Apple News. They provide a mechanism for publishers to build visually compelling and engaging stories for mobile (though as AMP itself eventually expanded beyond mobile, I fully expect the same thing to happen with stories).

The kicker to the announcement is the promise from yesterday’s keynote that this content will “ surfaced in Google search.” The exact method sounds like it isn’t guaranteed, just as the exact method wasn’t guaranteed when AMP itself was first announced. The launch post did, however, provide an image that shows how those results could appear in search.

So, to recap, the web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.

This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.” There are a lot of good folks working on AMP. I’ve met and talked with many of them numerous times and they’re doing amazing technical work. But the way the project is being positioned right now is disingenuous.

If AMP is truly for the open web, de-couple it from Google search entirely. It has no business there.

I have no problem with Google using their search engine to drive certain behaviors. HTTPS impacts your SEO score, performance impacts your SEO score (a little)—and that’s fine! These are features of a site that are not beholden to a single framework or tool. Everyone benefits whether they’re using Google technology or not.

But that’s not what happens with the AMP carrot. The only people who benefit are the ones who buy into this one, single tool.

If AMP makes performance better, that’s fantastic! Let’s incentivize good performance in the rankings. Let’s incentivize the goal, not the tool. There’s no need to single it out—if it does what it promises, it will reap the same rewards as any other highly performant page.

And I get it—it’s a non-trivial issue to give the same sort of treatment to all performance, well-built sites that you currently give to AMP content. Here’s the solution: don’t incentive it then until you can do it for the broader web. Yes, it will hurt AMP adoption and slow it down, but that’s not the goal here, right? AMP is for the open web, remember? The goal is a better web experience, a more performant web—not more AMP content. Right now that’s not what these artificial incentives accomplish.

Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.