Automatic Platform Optimization（APO）では、サイト全体をエッジネットワークから配信し、訪問者のパフォーマンスを改善します。Cloudflare は通常、静的コンテンツだけをキャッシュします。APO では HTML などの動的コンテンツもキャッシュし、サイト全体をキャッシュから配信できます。オリジンへの往復を減らし、Time to First Byte（TTFB）とその他のサイトパフォーマンス指標を大幅に改善します。動的コンテンツに加え、APO はサードパーティスクリプトもキャッシュし、Cloudflare のエッジネットワークを離れるリクエスト数をさらに減らします。
APO を使っても、WordPress サイトは通常どおり管理できます。Cloudflare の WordPress プラグインを使うと、WordPress でコンテンツを更新するたびにエッジ上のコンテンツも更新され、古いコンテンツの配信を防ぎます。加えて、ログイン中または管理者のユーザーではキャッシュをバイパスし、非公開コンテンツが他の訪問者にキャッシュ配信されないようにします。APO でできることの詳細は、紹介動画 ↗ を参照してください。
APO は、リクエストとオリジン応答が次の条件をすべて満たす場合にだけ、応答を HTML としてキャッシュします。いずれかが満たされない場合、リクエストはキャッシュをバイパスしてオリジンから配信され（cf-cache-status: DYNAMIC）、cf-apo-via 応答ヘッダーに理由が示されます。
- リクエストメソッド が
GETまたはHEADです。 - HTML 適格性 が、リクエストの
Acceptヘッダーと URL パスに基づいて満たされます。Accept: text/html（品質値が 0 より大きい）は HTML リクエストとして扱われます。Accept: text/html; q=0は HTML を明示的に拒否し、HTML としてキャッシュされません。Acceptヘッダーにtext/htmlが含まれない場合（Accept: */*やAcceptヘッダーなしを含む）は、代わりに URL パスを使います。ページや投稿などの非静的パスは適格のまま、静的ファイル拡張子は適格ではありません。
- オリジン応答 が HTTP
200で、Content-Typeがtext/htmlです。 - WordPress プラグインからの
cf-edge-cache応答ヘッダー がキャッシュを許可します（たとえばcache,platform=wordpress。no-cacheではありません）。 - バイパス Cookie がありません（ログイン、セッション、WooCommerce の Cookie など）。
- キャッシュをバイパスするリクエストヘッダー（
Cache-Control: no-cacheなど）やリスクのあるヘッダー（x-host、x-forwarded-host、x-original-url、x-rewrite-url）がありません。 - URL パス が除外パス（checkout、
wp-cron.php、フィードなど）ではありません。 - クエリ文字列 がないか、対応しているマーケティングパラメーターに限られます。詳細は クエリパラメーターとキャッシュ応答 を参照してください。
Cache Level: Bypassの Page Rule がリクエストに一致しません。詳細は APO と Page Rule の連携 を参照してください。
Automatic Platform Optimization は、Enterprise の サブドメインセットアップ で、たとえば www が apex ドメインと別のゾーンにある場合には使えません。