WordPress制作会社のためのCloudflare入門：高速化・防御・検証環境公開まで

はじめに：CloudflareはWordPressの前段に置く運用レイヤー

WordPress のサイト制作では、テーマやプラグインを作るだけでなく、公開後の速度改善、セキュリティ対策、フォームスパム対策、管理画面の保護、検証環境の共有まで考える必要があります。

小規模なコーポレートサイトであっても、公開した瞬間からログイン画面へのアクセス、存在しないプラグインへの攻撃、問い合わせフォームへのスパム送信、画像や JavaScript の配信負荷などが発生します。

そこで役立つのが Cloudflare です。

Cloudflare というと、まず CDN を思い浮かべる人が多いと思います。しかし、WordPress 制作会社の実務では、Cloudflare を単なる CDN として見るよりも、WordPress サイトの前段に置く運用・防御・高速化のレイヤーとして理解したほうが使いやすくなります。

この記事では、WordPress による Web 制作や保守を行う会社向けに、Cloudflare の使いどころを整理します。

対象読者は次のような人です。

WordPress サイトを制作・保守している人
クライアントサイトの表示速度やセキュリティ相談を受ける人
Cloudflare を導入したいが、どこから触ればよいかわからない人
wp-admin、wp-login.php、問い合わせフォーム、キャッシュ事故が不安な人
制作中の WordPress サイトを安全にクライアントへ共有したい人

この記事では、Cloudflare を入れればすべて解決する、という話はしません。

むしろ重要なのは、WordPress、サーバー、Cloudflare の役割分担を決めることです。キャッシュしてよい場所、してはいけない場所、守るべき管理画面、外部サービスとの連携を整理してから使う必要があります。

このチュートリアルで扱う構成

この記事では、次のような構成を想定します。

ユーザー
  ↓
Cloudflare
  - DNS
  - SSL/TLS
  - CDN
  - Cache Rules
  - WAF
  - Turnstile
  - Access
  - Tunnel
  ↓
WordPress サーバー

WordPress サイトそのものは、一般的なレンタルサーバー、VPS、マネージド WordPress ホスティング、Docker 環境など、どこに置いてもかまいません。

この記事で扱う範囲は次のとおりです。

Cloudflare にドメインを追加する前に確認すること
DNS と SSL/TLS の基本設定
CDN とキャッシュの考え方
WordPress 公式 Cloudflare プラグインと APO の位置づけ
Cache Rules でキャッシュしてよい場所・いけない場所
WAF による WordPress への攻撃対策
wp-login.php と xmlrpc.php の保護
Turnstile によるフォームスパム対策
Cloudflare Access による管理画面・検証環境の保護
Cloudflare Tunnel による確認用 URL の共有
制作会社向けの標準導入パターン
よくあるトラブルと確認ポイント

一方で、この記事では次の内容は深く扱いません。

WordPress テーマ制作そのもの
PHP や MySQL の細かいチューニング
WooCommerce の高度なキャッシュ設計
大規模メディア向けの複雑なエッジキャッシュ戦略
Cloudflare Workers を使った本格的なアプリケーション開発

まずは、制作会社が通常の WordPress 案件で導入しやすい範囲に絞ります。

導入前に確認すること

Cloudflare は便利ですが、既存サイトに導入するときは事前確認が重要です。

特に制作会社の場合、自社サイトではなくクライアントのドメインやサーバーを扱うことが多いため、いきなり設定を変更するとメール停止やログイン不可などの事故につながります。

導入前には、少なくとも次の項目を確認します。

確認項目	確認する理由
ドメイン管理者	ネームサーバー変更が必要になるため
DNS レコード	A、CNAME、MX、TXT などを移行するため
メール設定	MX、SPF、DKIM、DMARC を壊さないため
サーバー側 SSL	Cloudflare の SSL/TLS を安全に使うため
既存キャッシュプラグイン	Cloudflare キャッシュと競合する可能性があるため
会員機能・EC・予約機能	HTML キャッシュ事故を避けるため
外部連携	API、Webhook、Jetpack、スマホアプリなどの通信を確認するため
管理者のログイン方法	Access や WAF で締め出さないため

特にメール関連の DNS レコードは注意が必要です。

Cloudflare に DNS を移すとき、Web サイト用の A レコードや CNAME だけでなく、メール送受信用の MX レコード、SPF、DKIM、DMARC などの TXT レコードも正しく移行する必要があります。

Web サイトは表示されているのに、メールだけ届かなくなった、という事故は避けたいところです。

また、WordPress 側にすでにキャッシュプラグインが入っている場合も注意が必要です。

たとえば、WordPress 側のページキャッシュ、サーバー側のキャッシュ、Cloudflare のキャッシュ、ブラウザキャッシュが重なると、更新したのに表示が変わらない、管理画面では変わっているのに公開ページでは古い、という状況が起きやすくなります。

制作会社として導入するなら、最初に「どこで何をキャッシュするのか」を決めておくべきです。

DNSとSSL/TLSの基本設定

Cloudflare を導入する最初の作業は、ドメインを Cloudflare に追加し、DNS を Cloudflare 管理に切り替えることです。

大まかな流れは次のとおりです。

Cloudflare にサイトを追加する
既存の DNS レコードを確認する
不足している DNS レコードを追加する
ドメイン管理会社側でネームサーバーを Cloudflare に変更する
DNS 反映を待つ
SSL/TLS 設定を確認する
サイト表示とメール送受信を確認する

WordPress サイトで重要なのは SSL/TLS の設定です。

原則として、SSL/TLS は Full または Full (strict) を目指します。可能であれば Full (strict) が望ましいです。

Flexible は避けたほうがよいです。

Flexible では、ユーザーと Cloudflare の間は HTTPS でも、Cloudflare とオリジンサーバーの間が HTTP になります。これにより、WordPress 側でリダイレクトループや URL 判定の問題が起きることがあります。

安全に運用するには、オリジンサーバー側にも SSL 証明書を設定し、Cloudflare とオリジンサーバーの間も HTTPS にします。

制作会社がクライアントに説明するなら、次のような言い方がわかりやすいです。

Cloudflare を導入すると、サイト訪問者からのアクセスはいったん Cloudflare を通ります。Cloudflare は静的ファイルの配信、攻撃対策、アクセス制御などを前段で処理できます。ただし、サーバー側の SSL 証明書や DNS 設定も正しく整える必要があります。

まずはCDNとして使う

Cloudflare の基本は CDN です。

WordPress サイトでは、次のようなファイルが多く配信されます。

画像
CSS
JavaScript
Web フォント
テーマのアセット
プラグインのアセット
アップロード済みメディア

これらの静的ファイルを Cloudflare のエッジから配信することで、オリジンサーバーへの負荷を減らし、訪問者に近い場所からファイルを返せるようになります。

特に、画像の多い店舗サイト、採用サイト、観光サイト、ポートフォリオ、ブログ、オウンドメディアでは効果が出やすいです。

ただし、CDN を使うときも、何でも長時間キャッシュすればよいわけではありません。

WordPress は、ログイン状態、プレビュー、コメント、検索、会員機能、カート、マイページなど、ユーザーや状態によって表示が変わる場面があります。

静的ファイルは積極的にキャッシュし、ユーザーごとに変わるページはキャッシュしない、という切り分けが必要です。

WordPress公式プラグインとAPOの位置づけ

WordPress で Cloudflare を使う場合、Cloudflare 公式の WordPress プラグインを使う選択肢があります。

公式プラグインを使う主な目的は、WordPress と Cloudflare のキャッシュ削除を連携させることです。

たとえば、記事を更新したとき、WordPress 側では新しい内容になっているのに、Cloudflare 側に古いキャッシュが残っていると、訪問者には古いページが表示されます。

公式プラグインを使うと、WordPress の更新に合わせて Cloudflare のキャッシュを削除する運用がしやすくなります。

さらに、Cloudflare には WordPress 向けの APO、Automatic Platform Optimization があります。

APO は、画像や CSS、JavaScript だけでなく、WordPress の HTML 配信も Cloudflare 側に寄せるための仕組みです。

通常の CDN キャッシュよりも WordPress に踏み込んだ高速化の選択肢と考えるとわかりやすいです。

APO が向いているサイトは、たとえば次のようなものです。

個人ブログ
技術ブログ
コーポレートサイト
お知らせ中心のサイト
オウンドメディア
静的なページが多いサイト

一方で、次のようなサイトでは慎重に検証する必要があります。

WooCommerce などの EC サイト
会員サイト
予約サイト
ユーザーごとに表示が変わるサイト
ログインユーザー向けコンテンツが多いサイト
外部 API 連携が多いサイト

制作会社の実務では、APO をいきなり全案件に入れるのではなく、サイト種別に応じて判断するのがよいです。

静的なコーポレートサイトやブログでは有力な選択肢です。一方で、EC、予約、会員機能が絡む場合は、ステージング環境で十分に確認してから導入します。

Cache Rules：キャッシュしてよい場所・いけない場所

WordPress と Cloudflare を組み合わせるうえで、もっとも重要なのがキャッシュ設計です。

キャッシュは表示速度を改善しますが、間違えると不具合の原因になります。

基本方針は次のとおりです。

静的ファイルは積極的にキャッシュする
管理画面はキャッシュしない
ログイン処理はキャッシュしない
ユーザーごとに変わるページはキャッシュしない
HTML キャッシュはサイト種別に応じて慎重に判断する

代表的なパスごとの方針は次のようになります。

パス	方針	理由
`/wp-content/uploads/*`	積極的にキャッシュ	画像などの静的ファイルが多い
`/wp-content/themes/*`	キャッシュ候補	テーマの CSS、JS、画像が多い
`/wp-content/plugins/*`	キャッシュ候補	プラグインの CSS、JS が多い
`/wp-admin/*`	キャッシュしない	管理画面の誤動作を防ぐ
`/wp-login.php`	キャッシュしない	ログイン処理のため
プレビュー URL	キャッシュしない	編集中の内容確認に使うため
`/cart/*`	キャッシュしない	ユーザーごとに表示が変わるため
`/checkout/*`	キャッシュしない	決済・個人情報を扱うため
`/my-account/*`	キャッシュしない	会員ごとの情報を扱うため
`/wp-json/*`	原則慎重	REST API の用途により異なる
`/wp-admin/admin-ajax.php`	原則慎重	テーマやプラグインが利用するため

特に注意したいのは、admin-ajax.php と REST API です。

WordPress のテーマやプラグインは、表側の画面でも admin-ajax.php や /wp-json/ を使うことがあります。これらを雑にブロックしたり、強くキャッシュしたりすると、問い合わせフォーム、検索、絞り込み、予約、カート、いいね機能などが壊れる可能性があります。

制作会社の実務では、最初から細かく攻めすぎず、まずは次のような安全な範囲から始めるのがよいです。

画像、CSS、JavaScript などの静的ファイルをキャッシュする
管理画面とログイン画面はキャッシュ対象から外す
フォームや API 周りは実際の動作を確認する
問題がなければ HTML キャッシュや APO を検討する

WAF：WordPressへの攻撃を前段で減らす

WordPress は広く使われているため、攻撃者にとっても狙いやすい対象です。

公開したばかりの小規模サイトでも、存在しないプラグインの脆弱性を狙うリクエストや、wp-login.php へのログイン試行、xmlrpc.php へのアクセスが来ることがあります。

Cloudflare WAF を使うと、こうした攻撃の一部を WordPress に届く前に減らせます。

WAF は、リクエストの URL、HTTP メソッド、ヘッダー、IP アドレス、国、ボディなどをもとに、通信を許可したり、ブロックしたり、チャレンジを出したりする仕組みです。

WordPress 制作会社としては、まず Managed Rules を有効にし、ログを見ながら調整するのが現実的です。

WAF を導入するときの考え方は次のとおりです。

まずは一般的な攻撃対策を有効にする
WordPress 関連のルールを確認する
誤検知が起きていないかログを見る
管理画面、フォーム、REST API の動作を確認する
必要に応じて例外ルールを作る

WAF は強ければ強いほどよい、というものではありません。

たとえば、問い合わせフォームの POST が止まる、管理画面の保存が失敗する、ページビルダーの通信がブロックされる、といったこともあり得ます。

そのため、制作会社の保守運用では、WAF を入れたあとに「フォーム送信」「ログイン」「記事更新」「メディアアップロード」「プラグイン設定保存」などを確認することが大切です。

wp-login.phpとxmlrpc.phpを守る

WordPress で特に狙われやすいのが、wp-login.php と xmlrpc.php です。

wp-login.php は WordPress のログイン画面です。総当たり攻撃や、漏えいしたパスワードを試す攻撃の対象になりやすい場所です。

xmlrpc.php は、外部クライアントや一部サービスとの連携に使われてきたエンドポイントです。現在でも Jetpack、スマホアプリ、外部投稿ツールなどで使われる場合があります。

使っていないなら xmlrpc.php は制限候補になります。ただし、利用中のサービスがある場合は、いきなりブロックすると連携が壊れます。

制作会社としては、次の順番で確認すると安全です。

クライアントがスマホアプリや Jetpack を使っているか確認する
外部投稿ツールや連携サービスがあるか確認する
xmlrpc.php へのアクセスログを確認する
使っていなければブロックまたはチャレンジ対象にする
使っている場合は必要な通信だけ許可する方法を考える

wp-login.php については、次のような対策が考えられます。

Rate Limiting で短時間の大量アクセスを制限する
WAF で怪しいアクセスにチャレンジを出す
特定の国や ASN からのアクセスを制限する
Cloudflare Access でログイン画面の前に認証を置く
WordPress 側でも二要素認証を導入する

ただし、クライアントが複数拠点からログインする場合や、外部ライターがいる場合は、IP 制限だけに頼ると運用しづらくなります。

制作会社の案件では、「強い制限」と「クライアントが日常的に使えること」のバランスを取る必要があります。

Turnstileでフォームスパムを減らす

WordPress サイトでよく問題になるのが、問い合わせフォームやコメントフォームへのスパムです。

Cloudflare Turnstile は、CAPTCHA の代替として使えるボット対策です。

従来の CAPTCHA は、ユーザーに画像選択や文字入力を求めることがあり、ユーザー体験を悪化させる場合がありました。Turnstile は、できるだけユーザーに負担をかけずにボット判定を行うための仕組みです。

WordPress では、Turnstile 対応プラグインを使うことで、次のような場所に導入できます。

問い合わせフォーム
コメントフォーム
ログインフォーム
会員登録フォーム
パスワードリセットフォーム

制作会社の案件では、特に問い合わせフォームへの導入価値が高いです。

クライアントへの説明は、次のようにするとわかりやすいです。

問い合わせフォームのスパムが増えている場合、WordPress 側のフォームプラグインだけで対処するのではなく、Cloudflare Turnstile を組み合わせると、ユーザー体験を大きく損なわずにボット対策を追加できます。

導入後は、必ず実際にフォーム送信をテストします。

確認する項目は次のとおりです。

フォームが表示されるか
送信できるか
管理者に通知メールが届くか
自動返信メールが届くか
スパム判定が強すぎないか
スマホでも問題なく送信できるか

フォームはクライアントの売上や問い合わせに直結するため、見た目だけでなく、送信完了まで確認することが重要です。

Accessで管理画面や検証環境を守る

Cloudflare Access は、Web アプリケーションの前段に認証を置くための機能です。

WordPress の場合、管理画面や検証環境の保護に役立ちます。

通常、WordPress の管理画面は /wp-admin/ や /wp-login.php にアクセスすると表示されます。もちろん WordPress 側のログインはありますが、そのログイン画面自体はインターネットに公開されています。

Cloudflare Access を使うと、WordPress のログイン画面に到達する前に、Cloudflare 側で認証を要求できます。

たとえば、次のような使い方ができます。

/wp-admin/* を制作会社とクライアントだけに制限する
/wp-login.php を認証済みユーザーだけに見せる
公開前のステージング環境全体を保護する
Basic 認証の代わりに Google アカウントやメール認証を使う
外部パートナーやライターに一時的なアクセスを許可する

制作会社にとって特に便利なのは、公開前サイトや検証環境の保護です。

従来は Basic 認証を設定したり、サーバー側で制限したりすることが多かったと思います。Cloudflare Access を使うと、Cloudflare の管理画面からアクセス制御を設定できます。

ただし、WordPress 管理画面に Access をかける場合は注意が必要です。

REST API を巻き込まないか
外部連携を止めないか
クライアントがログイン手順を理解できるか
複数人で運用するときに権限管理できるか
ログインできないときの解除手順を用意しているか

Access は強力ですが、設定を間違えるとクライアントや制作側がログインできなくなることがあります。

本番サイトに適用する前に、ステージング環境で試すのが安全です。

Tunnelで確認用URLを安全に共有する

Cloudflare Tunnel は、ローカル環境や社内環境のサービスを、Cloudflare 経由で外部に公開できる仕組みです。

WordPress 制作会社では、次のような場面で役立ちます。

ローカルの WordPress 開発環境を一時的に共有する
ステージング環境を固定 URL で共有する
サーバーのポートを直接開けずに確認用 URL を作る
Cloudflare Access と組み合わせて認証付きの確認環境にする
クライアント、社内メンバー、外部パートナーに限定公開する

構成イメージは次のようになります。

制作中のWordPress
  ↓
Cloudflare Tunnel
  ↓
Cloudflare Access
  ↓
クライアント確認用URL

制作中のサイトを確認してもらうために、レンタルサーバーへ毎回アップロードするのは手間がかかります。ローカル環境や一時的な検証環境を安全に共有できると、確認作業が楽になります。

ただし、Tunnel で公開する場合も、認証なしで開けっぱなしにするのは避けたほうがよいです。

制作中のサイトには、未公開情報、仮の原稿、クライアント名、画像素材、テストデータなどが含まれることがあります。

そのため、Cloudflare Tunnel と Cloudflare Access を組み合わせて、確認用 URL にアクセスできる人を制限するのが実務的です。

画像の多いサイトでのCloudflare活用

WordPress サイトの表示速度で大きな割合を占めるのが画像です。

特に、次のようなサイトでは画像最適化が重要です。

飲食店サイト
美容室サイト
観光サイト
不動産サイト
採用サイト
ポートフォリオ
オウンドメディア
AI 生成画像を多く使うサイト

Cloudflare では、通常の CDN キャッシュに加えて、画像最適化系の機能を検討できます。

ただし、最初から高度な画像基盤を組む必要はありません。

まずは WordPress 側で次の基本を整えます。

適切な画像サイズでアップロードする
不要に大きい画像を使わない
WordPress のサムネイルサイズを整理する
遅延読み込みを確認する
画像圧縮を行う
WebP などの形式を検討する

そのうえで、Cloudflare 側では次のような活用を考えます。

画像ファイルを CDN でキャッシュする
画像変換機能を使う
Cloudflare Images のような専用サービスを検討する
大量画像を扱う場合は R2 などのストレージも検討する

制作会社の通常案件では、まず CDN キャッシュと WordPress 側の画像最適化を整えるだけでも十分なことが多いです。

画像基盤を大きく変える場合は、メディアライブラリ、バックアップ、既存 URL、SEO、プラグイン互換性に注意します。

制作会社向けの標準導入パターン

ここからは、サイト種別ごとの導入パターンを整理します。

小規模コーポレートサイト

会社案内、サービス紹介、お知らせ、問い合わせフォーム程度の小規模サイトでは、Cloudflare を導入しやすいです。

おすすめ構成は次のとおりです。

DNS
SSL/TLS Full strict
CDN
静的ファイルキャッシュ
WAF Managed Rules
Turnstile
必要に応じて APO

小規模コーポレートサイトでは、ユーザーごとに表示が変わるページが少ないため、Cloudflare の恩恵を受けやすいです。

問い合わせフォームには Turnstile を導入し、管理画面には WAF や Access を検討します。

ブログ・オウンドメディア

記事中心のサイトでは、表示速度とキャッシュが重要です。

おすすめ構成は次のとおりです。

DNS
SSL/TLS Full strict
CDN
WordPress公式プラグイン
APO
画像キャッシュ
WAF
Rate Limiting

ブログやメディアでは、APO が有力な選択肢になります。

ただし、ログインユーザー向け機能、限定公開コンテンツ、広告タグ、計測タグ、コメント機能などがある場合は、キャッシュ後の表示を確認します。

会員サイト・予約サイト

会員サイトや予約サイトでは、キャッシュに注意が必要です。

おすすめ構成は次のとおりです。

DNS
SSL/TLS Full strict
CDN
WAF
Turnstile
管理画面保護
HTMLキャッシュは慎重に検証
会員ページ・予約ページはキャッシュ除外

ユーザーごとに表示が変わるサイトでは、HTML キャッシュを安易に有効化しないほうが安全です。

ログイン後のページ、予約フォーム、マイページ、決済ページなどは、必ずキャッシュ対象から外します。

WooCommerceサイト

WooCommerce では、カート、チェックアウト、マイページがユーザーごとに変わります。

おすすめ構成は次のとおりです。

DNS
SSL/TLS Full strict
CDN
静的ファイルキャッシュ
WAF
Turnstile
ログイン・カート・チェックアウトはキャッシュ除外
決済Webhookを止めない

WooCommerce では、カートや決済に関わる通信を壊さないことが最優先です。

Cloudflare の導入自体は有効ですが、HTML キャッシュや強い WAF ルールは慎重に検証します。

ステージング環境

制作中や公開前の確認環境では、Tunnel と Access が便利です。

おすすめ構成は次のとおりです。

Cloudflare Tunnel
Cloudflare Access
限定公開URL
クライアント確認
社内レビュー

公開前のサイトを誰でも見られる状態にするのではなく、確認できる人を制限します。

制作会社としては、検証環境の共有方法を標準化しておくと、案件ごとの運用が安定します。

クライアントに説明するときの言い方

Cloudflare は機能が多いため、クライアントにそのまま説明すると伝わりにくいことがあります。

制作会社としては、技術名ではなく、効果と注意点をセットで説明するとよいです。

たとえば、次のように説明できます。

Cloudflare を導入すると、サイト訪問者とサーバーの間に Cloudflare が入り、画像や CSS などの配信、攻撃対策、アクセス制御などを前段で処理できます。これにより、表示速度の改善、サーバー負荷の軽減、管理画面への攻撃対策が期待できます。

注意点もあわせて伝えます。

ただし、Cloudflare は入れれば自動的にすべてが安全になる道具ではありません。WordPress のログイン、管理画面、会員ページ、カート、決済ページなどは、キャッシュやアクセス制御の設定を誤ると不具合につながります。そのため、サイトの機能に合わせて設定し、導入後に動作確認を行います。

保守メニューとして提案するなら、次のような表現も使えます。

Cloudflare の設定と監視を保守メニューに含めることで、表示速度、セキュリティ、フォームスパム、管理画面保護について、公開後も継続的に調整できます。

クライアントにとって重要なのは、Cloudflare の機能名ではなく、何が改善され、どこに注意が必要なのかです。

よくあるトラブルと確認ポイント

最後に、Cloudflare と WordPress を組み合わせたときによくあるトラブルを整理します。

管理画面が崩れる

管理画面の CSS や JavaScript が正しく読み込まれない場合、次の原因が考えられます。

管理画面をキャッシュしている
セキュリティルールが管理画面の通信をブロックしている
最適化機能が JavaScript を壊している
プラグインの通信が Cloudflare に止められている

確認することは次のとおりです。

/wp-admin/* をキャッシュしていないか
WAF のログにブロック履歴がないか
JavaScript 最適化を一時的に無効化すると直るか
特定のプラグイン画面だけで起きるか

ログインできない

WordPress にログインできない場合、次の原因が考えられます。

Access の認証設定が厳しすぎる
WAF がログイン POST を止めている
Rate Limiting に引っかかっている
wp-login.php をブロックしている
SSL/TLS やリダイレクト設定に問題がある

確認することは次のとおりです。

Cloudflare のセキュリティイベントを確認する
一時的に該当ルールを無効化して切り分ける
サーバー側のログも確認する
ブラウザの Cookie を削除して再試行する
SSL/TLS モードが適切か確認する

更新したのに表示が変わらない

記事や固定ページを更新したのに公開画面が変わらない場合、キャッシュが原因のことが多いです。

考えられるキャッシュは次のとおりです。

Cloudflare のキャッシュ
APO のキャッシュ
WordPress キャッシュプラグインのキャッシュ
サーバー側キャッシュ
ブラウザキャッシュ

確認することは次のとおりです。

Cloudflare のキャッシュをパージする
WordPress 側のキャッシュを削除する
シークレットウィンドウで確認する
別のネットワークや端末で確認する
公式プラグインのキャッシュ連携を確認する

問い合わせフォームが送信できない

フォーム送信ができない場合、次の原因が考えられます。

Turnstile の設定ミス
WAF が POST リクエストをブロックしている
admin-ajax.php が制限されている
REST API が制限されている
メール送信設定に問題がある

確認することは次のとおりです。

Turnstile を一時的に無効化して確認する
WAF のログを確認する
フォームプラグインの送信方式を確認する
管理者通知メールと自動返信メールを確認する
SMTP プラグインやメールサーバーのログを確認する

WooCommerceでカートがおかしい

WooCommerce でカート内容が他人と混ざる、カートが更新されない、チェックアウトできないといった問題が起きた場合、キャッシュ設定を最優先で疑います。

確認することは次のとおりです。

カートページをキャッシュしていないか
チェックアウトページをキャッシュしていないか
マイページをキャッシュしていないか
Cookie を無視して HTML キャッシュしていないか
決済 Webhook が WAF に止められていないか

WooCommerce では、静的ファイルの CDN キャッシュは有効ですが、ユーザーごとに変わるページの HTML キャッシュは慎重に扱います。

制作会社の保守メニューに組み込む

Cloudflare は、単発の導入作業だけでなく、保守メニューにも組み込みやすいサービスです。

たとえば、次のような項目を保守内容に含めることができます。

DNS 設定の管理
SSL/TLS 設定の確認
キャッシュ設定の調整
WAF ログの確認
フォームスパム対策
管理画面保護
画像配信の最適化
ステージング環境の保護
トラブル発生時の切り分け

WordPress の保守というと、本体・テーマ・プラグインの更新、バックアップ、障害対応が中心になりがちです。

しかし、実際のサイト運営では、表示速度、セキュリティ、スパム、ログイン攻撃、外部公開前の確認環境など、WordPress の外側にも課題があります。

Cloudflare を使うと、その外側の課題に対して、制作会社が提案できる範囲が広がります。

まとめ：CloudflareはWordPress保守メニューにしやすい

WordPress 制作会社にとって、Cloudflare は単なる CDN ではありません。

WordPress の前段に置くことで、表示速度の改善、静的ファイルの配信、WAF による攻撃対策、Turnstile によるフォームスパム対策、Access による管理画面保護、Tunnel による検証環境共有など、制作と保守の両方に役立ちます。

最初に導入するなら、次の順番が現実的です。

DNS と SSL/TLS を正しく設定する
静的ファイルを CDN で配信する
管理画面とログイン画面をキャッシュ対象から外す
WAF の基本設定を有効にする
問い合わせフォームに Turnstile を導入する
wp-login.php と xmlrpc.php へのアクセスを確認する
必要に応じて APO を検討する
管理画面や検証環境に Access を使う
開発・確認用に Tunnel を活用する

重要なのは、Cloudflare にすべてを任せることではありません。

WordPress、サーバー、Cloudflare の役割を分け、サイトの種類に応じて設定することです。

小規模なコーポレートサイトやブログでは、Cloudflare の導入効果を得やすいです。一方で、会員サイト、予約サイト、WooCommerce などでは、キャッシュやアクセス制御を慎重に設計する必要があります。

制作会社としては、Cloudflare を「速くするための道具」としてだけでなく、納品後の運用を安定させるための前段レイヤーとして扱うと、提案や保守の幅が広がります。

WordPress サイトを作って終わりにしないために、Cloudflare を運用設計の選択肢に入れておく価値は大きいと思います。