APO bypassing /amp/: page type "Unknown"

Hi there,

I reported this possible bug a few times since APO’s launch. Cloudflare doesn’t recognize /amp/ pages as “text/html” in this specific situation, and serves it from origin, bypassing APO.

This is happening since day 1:

Some considerations:

  • All of those pages do have a “text/html” header (official amp plugin)
  • All returning status 200.
  • All cookies removed via nginx;
  • In my browser, everything is delivered from cache as expected.
  • I’ve also ran several tests using curl, forcing “Pragma: no-cache” and “Cache-control: no-cache” headers. It always returns a cache “HIT”.
  • The traffic is all mobile and from the US, even though it’s a brazillian site (portuguese)
  • That’s not just regular traffic. I suspect it could be Googlebot (or some other bots). But that doens’t explain missing the cache more than 5k times for the same urls.
  • These posts are not our most visited content. It’s just random URLs, some don’t even get real traffic.
  • After enabling APO in october, the average response time in our Google Search Console report increased from 80ms to +230ms. It could be an indicator that APO is missing the cache for googlebot.

Still, that doens’t explain missing the cache 5 thousand times per URL. It should be cached after the first request, and revalidated in the subsequent requests (after expired).

11.8 million requests went straight to my server over the last week – 1.6 million over the last 24 hours. That’s a lot more traffic than these pages actually have.

Here are some URLs from the list, if anyone wants to check:

Any ideas on why this is happening?

Hi guys,

Any ideas here?

I tried the support, but they always respond with basic instructions about APO, which are already covered in my tests…


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.


I think we can improve cache hit ratio for cases when both APO and Cache Everything settings are present ( as in your use case). At the moment we rely on “accept” header to have “text/html” value. I assume it’s not always the case for search engine crawlers. I will release a change this week.


The change is live.