APO should serve from origin page with AMP querystring

The AMP querystring (www.example.com/page-with-amp?amp) is very popular in Wordpress installation to serve AMP formatted pages. AMP formatted pages are quite different from regular pages, so the ?amp querystring change a lot the content of the page.

APO not recognize this critical aspect, strip the AMP querystring and serve the page from the regularm, cached version.

Now i Have 15k pages with AMP errors in the Google search console.

Please, fix this problem and get the pages with amp querystring from origin.

according to @yevgen latest APO version should be caching ?amp query strings APO release 2020.10.7 and 2020.10.8 as long as the request is a GET with text/html Accept headers and no cookies

I’m trying to understand. The primary goal of AMP is speed, right? If APO serves from cache it will be faster than going to origin for optimized AMP page. Why not to serve all pages in AMP format or disable AMP altogether if you are happy with APO?

Hi @eva2000, thanks for your reply.

Seems the new feature is not deployed yet. I received yesterday several notification from the Google Search Console and right now the amp page are server as regular pages (ie now https://www.webnews.it/2020/10/20/vivo-sbarca-in-europa-ecco-tutti-i-nuovi-smartphone/?amp=)

Hi @yevgen: APO should serve different cache for regular page (ie. https://www.webnews.it/2020/10/20/vivo-sbarca-in-europa-ecco-tutti-i-nuovi-smartphone/) and AMP page (https://www.webnews.it/2020/10/20/vivo-sbarca-in-europa-ecco-tutti-i-nuovi-smartphone/?amp).

amp is an active querystring and can change a lot the page content for users.

@dadamax we added amp to the query strings list we allow to serve from cache recently. In the particular case origin took 8s to serve amp page. Obviously not all origin servers will be that slow, but the idea is that serving the page from cache will be always faster than going to origin otherwise APO could be disabled.
I understand that serving page in non AMP format when AMP format is requested could be problematic. That’s why I’m suggesting 2 available options when running APO:

  • serve all pages in AMP format with and without ?amp= query string (I believe it’s not restricted to mobile only)
  • disable AMP on the server

One final argument that I’m hesitant to revert amp change and request it from origin is that Google is pushing Web Vitals instead of AMP: https://www.searchenginewatch.com/2020/09/16/google-ranking-factors-2021-core-web-vitals-e-a-t-or-amp/. So that means serving pages as fast as possible is more important than serving page in correct format, Google agrees.

1 Like

@yevgen, thanks for your reply.

I don’t kwnon were the 8seconds metrics came from, but usually the AMP pages are lighter than standard pages, so they are served very fast (at least, we serve them very fast).

But the problem is not that: the problem is that Cloudflare included the amp querystring in the ‘marketing attribution querystring’ list when is one of the most used querystring for serving a completely different page to clients. So pages with this querystring should be always refreshed from origin.

After I received thousands of error notification form Google I was forced to disable APO. But AMP is still critical to site success and in some sites, if Cloudflare continue to consider amp querystring ‘marketing’, I will change my AMP url from querystring based to url based (from www.site.com/page?amp to www.site.com/amp/page). Just lot of work.


I think the point yevgen is making here is that “very fast” AMP is still not as fast as serving a normal page from cache. If you use responsive pages that properly adapt to mobile, and you’re caching and optimizing in other ways (reducing file size, etc.), what benefit is there from using AMP?

It looks like you would need to redesign, but it’s probably going to be worth it because AMP could be abandoned at any time.

+1 on that, tried Wordpress AMP plugin on my blog and it actually slowed my pages down and increased my pages HTML size almost 3x from 58-65KB to >223KB

Yeah that would be problematic, APO cache needs to really add a cache key for to be able to serve separate caches for ?amp and non-amp pages


I definitely agree on this.

It’s like if APO is serving an AMP page from cache located at /article/amp/, it will be a different page than /article/ because the slug is different and the content on both pages is different.

/article/ and /article/?amp should definitely be trated as two different cache entries since both pages contain different content as well.

Of course, the Cloudflare plugin would also need to purge the cached ?amp pages the same way it purges the regular version of the articles.

1 Like

@eva2000 Web Vitals are very important. But AMP pages often acquire more performance on the Google SERP page and we need them for SEO purposes. So we can have both: well optimized regular pages AND AMP pages.

That would be changing in future when they roll out Page Experience group as a ranking factor which includes Core Web Vital Metrics https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html

We’re combining the signals derived from Core Web Vitals with our existing Search signals for page experience, including mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines, to provide a holistic picture of page experience. Because we continue to work on identifying and measuring aspects of page experience, we plan to incorporate more page experience signals on a yearly basis to both further align with evolving user expectations and increase the aspects of user experience that we can measure.

When we roll out the page experience ranking update, we will also update the eligibility criteria for the Top Stories experience. AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page. Alongside this change, page experience will become a ranking factor in Top Stories, in addition to the many factors assessed.

So if 2 web sites on same topic have same SEO juice and if one’s page experience i.e. page speed is faster than the other, then the faster site will rank higher regardless of if it’s using AMP. I’ve already seen site and even forums in Google News that do not use AMP so it is starting to change.

Though I still agree, separate caches for AMP ?amp and non-AMP pages is necessary.

Though whether you want to use AMP will eventually depend on overall page speed as in future Google page experience rank will probably not care if you use AMP or not. I’ve seen AMP pages with 32+ seconds page load time where all 32+ seconds had 100% cpu utilisation on the web browser with 1,200 requests on the single page load. Google isn’t going to rank that site with AMP and 32+ seconds page load time higher than a similar site on same topic that loads with non-AMP page in <2 seconds on mobile.

Basically, AMP only makes sense when AMP pages are faster than your non-AMP pages.

1 Like

Be aware it requires manual purge of www.site.com/amp/page when www.site.com/page changes.

1 Like

Hi there,

I’m not sure I follow the current status of ?amp URL caching.
When I go to URLs with the ?amp query URL, I see the desktop version.
However if I do a hard refresh, it effectively returns the AMP version and queries after that properly return the AMP version.

Why is the proper AMP version not stored at first? Is there some kind of cold start issue going on or did I miss something?

Probably an initial request was returned from KV which was cached as desktop version, next fetch returned cached mobile version from Cloudflare Cache. It can be checked with cf-apo-via response header.

We will remove ?amp pages caching, as it’s created a lot of confusion, we will rollout the change on Monday.


Sounds good. Could you let us know here when it’s rolled out?

Thanks a lot.



Facing the same issue with APO - AMP is necessary for many websites - especially blogs and news from Google SEO perspective - Please notify once it is fixed.

The release is postponed till Tuesday. We are bundling the fix with other changes which require more delicate rollout.