小さな会社のWebサイトをCloudflareで運用して分かったこと

ホームページの検索結果への登録がなかなか進まず、調べていくと、トップページにリダイレクト（転送）を置いていたことが原因の一つだった、ということがありました。小さな会社のWebサイトを自分で運用していると、こうした細かい設定の落とし穴に何度か当たります。

私はWebサイトやWebアプリを、主にCloudflareで動かしています。どのサイトか、どの顧客かは書きません。ここでは、無料枠の数字と、はまった点、バックアップの考え方だけを書きます。また、他社のホスティングと比べた経験はないので、他社との優劣は書けません。

無料枠で足りるかの目安

2026年9月30日にCloudflareの公式ページで確認した無料プランの数字は、次のとおりです。

ページ数が少ない会社案内のような静的サイトなら、この範囲に収まるはずです。逆に、写真をたくさん置くアプリや、毎日たくさんの人が使うシステムは、R2の保存量やD1の書き込み回数が先に限度に近づくと予想しています。私の手元では、限度を超えたという記録はありません。無料枠の内容は変わる可能性があるので、使う前に必ず公式ページを見てください。

有料に切り替える基準は、まだ決めていません。ダッシュボードで使用量を数えてから決めるつもりです。

はまった点

一つ目は、トップページへの転送です。ルートのURLにリダイレクトを置いたところ、検索エンジンの登録の側で「重複している」と判断される原因になりました。検索の管理画面で見えた理由は四つあり、そのうち実害があったのは「別の正規URLが選ばれている」の一つでした。転送をやめて、トップページを直接配信するようにしました。

二つ目は、独自ドメインの反映の遅れです。Cloudflare Pagesでは、標準のアドレスはすぐに更新されるのに、独自ドメインだけ数分遅れることがありました。デプロイの直後に確認して、反映されていないと早合点しないようにしています。

三つ目は、ログインの安全性です。私の記録では、CloudflareのGoogleアカウントによるログインでは、Cloudflare側の二段階認証を設定できないという既知の制約があります。その場合、実質的な二要素認証はGoogleアカウントの側で行うことになります。パスワードでログインするなら、認証アプリまで設定しておくのがよいと考えています。

バックアップ

Webアプリのデータは、変更を本番へ反映する前にデータベースを書き出して保存します。手作業だと忘れるので、デプロイの手順に自動で組み込みました。稼働中のシステムでは、修正が即座に本番に反映されるからです。ただ、書き出したデータから実際に元へ戻す訓練までは、定期的にはできていません。バックアップは、戻せるところまで確認して初めて意味があります。内部の設定や顧客のデータは、ここには書きません。

独自ドメインのメールについて

会社のメールを独自ドメインで用意する方法は、この記事の対象にしません。比較して選んだ記録が私の手元にないため、確かなことを書けないからです。無料枠の話とは別に、契約の条件や料金を調べるときは、それぞれの事業者の公式ページを見る必要があります。

今の運用

静的なサイトと、小さなWebアプリを、Cloudflareで動かしています。使用量や契約の内訳は書きません。写真を扱うアプリとの関係は現場写真と工程表をスマホで扱うときの保存の考え方にも書きました。次は、バックアップから復元する練習を1回やって、かかった時間を記録に残すつもりです。