# WordPress静的サイトをCloudflareで公開する手順
Simply Staticなどで書き出した静的ファイルは、Cloudflareを使って公開できます。Cloudflareには静的ファイルを配信する方法がいくつかあり、この記事では実際にこのサイトを公開しているCloudflare Workers Static Assetsという方法を中心に、公開までの手順を解説します。
Cloudflare PagesとWorkers Static Assets、どちらを使うか
Cloudflare PagesとWorkers Static Assets、どちらを使うかで確認すべきポイントを整理します。
Cloudflareで静的ファイルを公開する方法として、Cloudflare PagesとCloudflare Workers Static Assetsの2つがよく使われます。どちらも、あらかじめ用意した静的ファイル一式をエッジのネットワークから配信するという点では共通しています。
どちらを選んでも大きな失敗にはなりません。この記事は、実際にこのサイトの運用で使っているWorkers Static Assetsを基準に手順を書いています。Cloudflare Pages側の手順は概要だけに留め、深くは扱いません。
もともとCloudflare Pagesのほうが静的サイトのホスティング先として広く知られていますが、Workers Static Assetsも同じCloudflareの基盤上で静的ファイルを配信できる選択肢です。細かな機能差はありますが、WordPressを静的化したサイトを公開するという目的においては、どちらを選んでも大きく困ることはありません。
事前準備
事前準備で確認すべきポイントを整理します。
公開作業を始める前に、次の2つを済ませておきます。
- Cloudflareのアカウントを作成する
- Simply Staticなどで書き出した静的ファイル一式を用意する（書き出し方法はSimply Staticの使い方で解説しています）
ドメインをCloudflareで管理するかどうかも、この段階で考えておくとよい点です。本番ドメインへ切り替える前に、Cloudflareが用意しているプレビュー用のドメイン（`*.workers.dev`）で動作を確認できるため、いきなり本番ドメインを向ける必要はありません。
Wranglerでのデプロイ設定
Wranglerでのデプロイ設定で確認すべきポイントを整理します。
Workers Static Assetsでの公開には、Wranglerというコマンドラインツールを使います。設定ファイルには、主に次の項目を指定します。
- 配信対象にするディレクトリ（Simply Staticの元Zipファイルや、未処理の展開先ではなく、後処理・検証を済ませたディレクトリを指定します）
- URLの末尾スラッシュの扱い
- 存在しないURLへアクセスされたときの応答
末尾スラッシュの正規化
WordPressから書き出したファイルは、`ページ名/index.html`という構成になっていることが一般的です。`auto-trailing-slash`という設定を使うと、`/ページ名/`をそのページの正規のURLとして配信し、末尾のスラッシュがないアクセスやindex.htmlへの直接アクセスも、正規のURLへそろえて返してくれます。
404ページの扱い
存在しないURLにアクセスされた場合の応答も設定できます。`404-page`という設定にすると、用意した404ページの内容を、HTTPステータスもきちんと404として返してくれます。見た目だけ404ページが表示されて、実際のステータスは200のまま、という状態を避けられます。
デプロイの実行と公開後の確認
デプロイの実行と公開後の確認で確認すべきポイントを整理します。
設定が終わったら、まずはローカルで動作を確認するコマンドを実行し、問題がなければ公開用のコマンドを実行します。
公開が終わったら、そのまま終わりにせず、次の項目を確認しておくことをおすすめします。
- サイトマップに掲載されている全URLがHTTP 200で表示されるか
- 末尾スラッシュのないURLが正規のURLへ正しくそろえられるか
- 存在しないURLでHTTP 404の404ページが表示されるか
- リンク切れ、混在コンテンツ、WordPress側の動的な参照が残っていないか
フォームなど動的な機能がある場合の追加確認
お問い合わせフォームなど、外部の送信サービスと連携している機能がある場合は、フォーム側の設定も忘れずに確認します。フォーム送信サービスが送信元ドメインを制限している場合、プレビュー用のドメインからの送信が拒否されることがあります。具体的な設置方法は静的化したWordPressサイトでお問い合わせフォームを使う方法で紹介しています。
本番ドメインへの切り替え
本番ドメインへの切り替えで確認すべきポイントを整理します。
プレビュー用のドメインで一通りの確認が終わってから、本番ドメインを割り当てます。順番を逆にして先に本番ドメインを向けてしまうと、確認中の不具合がそのまま公開されることになるため、確認を終えてから切り替えるという順序を守ることが大切です。
切り替えた直後は、これまで使っていたWordPress側のサーバーをすぐに解約せず、しばらく並行して残しておくことをおすすめします。DNSの反映には時間差があり、切り替え直後は利用者によって古い環境へ接続することもあるためです。SSL証明書の状態、フォームの動作、アクセス解析のタグ、検索エンジン向けの設定なども含めて一定期間安定していることを確認し、それから旧環境の解約手続きに進みます。
よくある質問
よくある質問で確認すべきポイントを整理します。
Q. Cloudflare PagesとWorkers Static Assets、どちらを選べばいいですか？
A. どちらでも静的ファイルの配信は可能です。この記事では、実際にこのサイトで運用しているWorkers Static Assetsの手順を扱っています。どちらを選んでも大きな失敗にはなりません。
Q. 公開前にどのドメインで動作確認できますか？
A. Cloudflareが用意しているプレビュー用のドメイン（`*.workers.dev`）で確認できます。本番ドメインを向ける前に、このドメインで一通りの動作を確かめておくと安心です。
Q. 公開後、存在しないURLにアクセスするとどうなりますか？
A. 設定次第ですが、用意した404ページの内容が、HTTPステータスも404として返るように設定できます。見た目だけ404で実際は200のまま、という状態は避けられます。
Q. 本番ドメインへの切り替えはどのタイミングで行うべきですか？
A. プレビュー用のドメインでの動作確認が一通り終わってからです。確認より先に本番ドメインを向けてしまうと、不具合がそのまま公開されてしまいます。切り替え直後もWordPress側のサーバーはすぐに解約せず、しばらく並行して残しておくと安全です。
Q. 静的サイトでもお問い合わせフォームは使えますか？
A. 静的なHTMLだけではフォームの送信処理は動きませんが、外部の送信サービスと組み合わせることで使えるようになります。送信元ドメインの許可設定が必要になる場合もあるため、具体的な設置方法は別の記事で紹介しています。
まとめ
まとめで確認すべきポイントを整理します。
公開までの流れは、事前準備、デプロイの設定、デプロイの実行、公開後の確認、本番ドメインへの切り替えという5つの段階に整理できます。特にプレビュー用のドメインで確認してから本番へ切り替えるという順序を守ることが、公開後のトラブルを防ぐ一番のポイントです。
| 設定項目 | 確認する内容 |
|---|---|
| 配信ディレクトリ | 後処理・検証済みの出力先を指定する |
| html_handling | 末尾スラッシュを正規URLへそろえる |
| not_found_handling | 存在しないURLをHTTP 404で返す |
