WordPress運用基盤の整え方｜メール・DNS・Cloudflare・バックアップを一枚で管理する方法

WordPressサイトが1つのうちは、サーバーのログイン先、DNS、メール、バックアップを頭の中で覚えられます。サイトが増えると、ドメイン会社、DNS、メール、WordPress、Search Console、広告、API、自動化が別々になり、「どこを直せばいいか」を探す時間が増えます。

僕自身、複数のWordPress/Webサイト、DNS、Zoho Mail、Cloudflare、自動化基盤を扱う中で、個別設定よりも依存関係が分かる台帳が重要だと感じています。障害時に「WordPressが壊れた」と思っても、実際はDNSやメールだけの問題ということもあるからです。

WordPress運用を7つの層に分ける

これらを1つのサービスへまとめると簡単に見えますが、障害時の影響範囲は広くなります。逆に全部を分けると管理先が増えます。重要なのは「分けること」ではなく、どこに依存しているかを見える化することです。

サイト台帳に最低限入れる項目

パスワードそのものは台帳へ書きません。資格情報はパスワードマネージャー等へ分離し、台帳には「どこで管理しているか」「誰がアクセスできるか」「最後にローテーションした日」だけ残します。APIキー、SMTPパスワード、Cloudflare API Token、Application Password、秘密鍵も同じ扱いです。

台帳には「責任者・確認日・更新期限」を必ず持たせる

サービス名だけを並べた台帳は、障害時に誰が判断するか分かりません。各行にOwner、Backup owner、最終確認日、次回確認日を追加します。1人運営でもOwnerを自分と明記しておけば、将来外注・法人化・共同運営へ移した時に責任境界を作りやすくなります。

RPOとRTOをサイトごとに決める

「バックアップあり」だけでは復旧設計になりません。RPOはどの時点までのデータ損失を許容するか、RTOは何時間以内に復旧したいかの目標です。毎日更新するメディアと、問い合わせが売上に直結する事業サイトでは許容値が違います。

高可用性を目的に仕組みを増やしすぎず、「4時間以内」「翌日まで」のように目標を明示すると、必要なバックアップ頻度と費用を決めやすくなります。

障害Runbookは「症状→確認→復旧→連絡」で作る

障害時に検索しながら対応すると、焦ってDNSやキャッシュを何度も変更しやすくなります。1ページのRunbookを作り、症状別に最初の3手を固定します。

• サイトが開かない：ドメイン期限→NS/DNS→Cloudflare→オリジンサーバー→WordPressの順
• メールだけ止まった：MX→メール用DNS-onlyホスト→SMTP→SPF/DKIM/DMARC→受信側エラー
• 更新が反映されない：WordPress→プラグインキャッシュ→サーバーキャッシュ→Cloudflareの順
• フォームだけ届かない：フォーム送信→wp_mail/SMTPログ→From/Reply-To→実メールヘッダー

各Runbookには「変更してよい項目」「変更禁止項目」「rollback手順」「障害連絡先」を付けます。DNSや認証情報を触る工程ほど、直前状態のスクリーンショットやexportを残します。

秘密情報は運用台帳から分離し、参照先だけ記録する

運用台帳は共有しやすいほど便利ですが、そこへAPIキーやパスワードを直接書くと、台帳漏えいが全サービス漏えいになります。資格情報は専用保管先に集約し、台帳には「Password Manager / Vault名」「credential名」「Owner」「最終ローテーション日」を残します。

• Cloudflare API Tokenは必要なzone/permissionだけに絞る
• WordPress Application Passwordは連携ごとに分ける
• SMTPのアプリ固有パスワードはサイト/用途別に分ける
• 退職・委託終了・端末紛失時に個別失効できるようにする
• GitHub、記事本文、共有チャット、スクリーンショットへ秘密情報を載せない

変更管理は「Before・Change・After」の3点セットにする

DNS、Cloudflare、SMTP、キャッシュ、WordPress一括更新のような変更は、作業内容より「何を変えたかを後から説明できること」が重要です。Beforeに現行値と正常状態を保存し、Changeで変更理由・担当・日時を記録し、AfterでWeb・メール・フォーム・主要URLを確認します。

複数サイトでは全サイトを同時変更せず、1サイトまたはcanaryで確認してから広げると影響範囲を小さくできます。

障害時は「Webが見えるか」から順番に切り分ける

1. ドメインの期限とDNS解決を確認する
2. HTTPSでサイトが表示できるか確認する
3. WordPress管理画面へ入れるか確認する
4. 特定ページ/全ページどちらの障害か分ける
5. フォーム送信とメール受信を別々に確認する
6. Cloudflare/cacheを一時的に切り分ける
7. 直前の更新・DNS変更・プラグイン変更を確認する
8. 必要ならバックアップから復旧する

この順番を決めておくと、焦ってプラグインを削除したりネームサーバーを往復させたりする操作を減らせます。

運用台帳で分けて管理する領域

メールはWebサイトと別の監視項目にする

サイトが表示できるのに問い合わせだけ届かない事故は、ユーザーから見ると気づきにくい問題です。フォーム画面に「送信完了」と出ても受信箱へ届いていないことがあります。

月1回またはサイト変更後に、実際のフォーム送信→Zoho等の受信箱→返信まで確認します。SPF・DKIM・DMARCやSMTP設定を変えた日は必ず再テストします。

DNS変更は「差分」と「戻し方」を残す

DNSはサイト・メール・外部認証に同時に影響します。変更前の全レコード、変更したレコード、変更時刻、理由を保存します。Cloudflareへ移す場合も、A/CNAMEだけでなくMX/TXT/認証レコードを確認します。

「誰かが昔追加した用途不明TXT」を勝手に削除しないことも大切です。サービス名が分からなければ調べ、不要と判断できてから消します。

Cloudflareは機能ごとに導入状態を記録する

Cloudflareを「使っている/使っていない」の二択で記録すると、障害時にどの機能が効いているか分かりません。DNSだけ、CDNだけ、Accessありなど、機能単位で残します。

バックアップは存在より復元可能性

WordPress公式もバックアップをファイルとデータベースに分けて説明しています。運用台帳には、何日分あるかだけでなく、どこから復元できるか、最後に復元テストした日も記録します。

更新前バックアップ、日次バックアップ、外部保存の役割を分けると、最新状態だけでなく「問題が入る前の時点」へ戻しやすくなります。バックアップの詳細は既存の専用記事へ集約し、このHubでは復旧経路が見えることを重視します。

日常運用を標準化する

公開・更新の標準手順を固定する

1. 変更対象と目的を記録
2. バックアップ/rollback可能性を確認
3. 下書きまたはステージングで変更
4. PC/スマホ表示QA
5. フォーム・主要リンク・画像確認
6. 公開
7. Cloudflare/サーバーキャッシュ反映確認
8. Search Console等で必要な確認
9. 変更日と結果を台帳へ記録

サイトごとに毎回違う手順を考えるのではなく、共通チェックリストを作り、テーマや収益導線などサイト固有部分だけ変える方がミスを減らせます。

月1回の運用チェック

• ドメイン更新期限と支払い
• サーバー容量・バックアップ状態
• WordPress/PHP/主要プラグイン更新
• フォーム送受信
• SPF/DKIM/DMARC
• Cloudflareの異常・キャッシュルール
• 404・主要内部リンク
• Search Consoleのインデックス異常
• ASPリンク・終了案件
• 管理者/MFA/不要アカウント

30分で作る最小運用台帳

1. サイト名、URL、ドメイン登録先、Webサーバーを10分で記入
2. DNS、メール、Cloudflare、バックアップの管理先を10分で記入
3. Owner、最終確認日、更新期限、RPO/RTOを5分で記入
4. 障害時Runbookのリンクと資格情報の保管先だけを5分で記入

最初から大規模な管理台帳は不要です。「どこを見るか」「誰が判断するか」「どう戻すか」が1枚で分かれば十分です。秘密情報そのものは書かず参照先だけにします。

131〜139を役割別に使い分ける

台帳を作る目的は「自分しか分からない」をなくすこと

複数サイトを一人で運営していても、半年後の自分は細かい設定を覚えていません。サービスを追加した理由、どのDNSレコードが必要か、どこにバックアップがあるかを文章で残しておけば、未来の自分やAIツールが安全に判断できます。

自動化を進める場合も同じです。AIへ操作権限を与える前に、サイトごとの許可範囲とrollback経路を台帳化しておくと、121〜130で作ったWordPress AI自動化クラスターともつながります。

公式情報・参考資料

仕様確認日：2026年10月1日。設定画面・料金・提供機能は変更されるため、実作業前にリンク先の最新版も確認してください。

• WordPress：Backups
• Cloudflare DNS：Get started
• Cloudflare：Troubleshooting email issues
• Gmail：メール送信者のガイドライン

あわせて読みたい

• WordPress×AI連携の全体像
• 複数WordPressサイトの管理を効率化
• WordPressバックアップ方法
• WordPressセキュリティ対策

まとめ

WordPress運用は、記事を書くことだけでなく、DNS・メール・サーバー・Cloudflare・バックアップがつながって成り立ちます。サイト数が増えるほど個別設定を覚えるのではなく、依存関係と変更履歴を台帳へ集約してください。障害時の判断が速くなり、自動化や外注へ渡せる範囲も広がります。

関連記事：WP-Cronとsystem cronの違い

関連記事：ステージング環境で安全に更新する

関連記事：WordPress高速化・安定運用の全体像