WordPress自動投稿を5サイトで移行した安全確認の手順

5サイト移行の安全確認の実測手順と確認項目

5サイト移行の安全確認について、当サイトの実運用で行った作業を、成功した工程だけでなく失敗と停止条件まで含めて整理します。一般的なツール紹介ではなく、2026年8月20日に確認した実行記録、測定値、公式資料を分けて記載します。同じ作業を行う場合は、対象サイト、投稿ID、変更前バックアップ、再取得条件を先に固定してください。

先に結論:完了は実行結果ではなく再取得で決める

移行対象を一度に切り替えず、サイト単位の完了条件を固定したことで、4サイトは翌日から7日分の連続予約を確認できました。残る1サイトの予約切れも全体障害ではなく、サイト固有の不足として検出できました。

作業コマンドが終了しても、WordPress側の保存状態や公開HTMLが一致しなければ完了ではありません。変更前の値、送信した値、保存後の値を比較し、違いがあれば次の処理へ進まず安全停止します。これにより、速さよりも復旧可能性と検証可能性を優先できます。

今回確認できた実測値

実施日2026年8月20日
対象5サイト移行の安全確認
測定結果5サイトの移行基盤で151件の自動テストを通し、同期した191ファイルのSHA-256不一致は0件でした。
一次資料WordPress REST API Handbook

測定値は当日のローカル記録とWordPress再取得を照合したものです。検索順位や収益の上昇を直接証明する数字ではないため、技術的な完了条件とSEO成果を混同しません。

作業前に起きていた問題

旧運用を先に消すと、予約投稿や認証の不具合が出たときに比較対象と復旧経路を失います。そこで新旧を並行して、読み取り、シャドー検証、限定書き込み、本番再取得の順に進めました。

自動化では、処理が多いことより、誤った対象へ正しく処理してしまうことの方が危険です。そのためサイトID、ホスト、投稿status、予約日、画像形式を入口で照合し、一つでも不明なら書き込みを行いません。

実際に行った手順

  1. 現行サイトの投稿状態、予約時刻、カテゴリ、画像、認証方式を読み取り専用で記録する
  2. 新基盤をシャドーモードで動かし、WordPressへ書かずに重複と品質検査を通す
  3. 1サイトずつ7日分だけ予約し、投稿IDと保存内容をREST APIで再取得する
  4. 公開URL、canonical、robots、構造化データ、WebPを別経路で確認する
  5. 復旧資料とハッシュがそろうまで旧運用を停止状態で保持する

各工程の間で結果を保存し、後工程が前工程の推測に依存しないようにしました。特にWordPressの変更は、作成や更新のレスポンスだけでなく、別のGETで同じ投稿を取り直して比較します。公開ページの確認が必要な項目は、予約時点のAPI検査と公開後のHTML検査を分けます。

一次資料と実装判断を分ける

WordPress REST APIはJSONを使って投稿などのデータを読み書きでき、公開情報と認証が必要な情報を区別して扱います。 出典はWordPress REST API Handbookです。

公式資料が説明しているのは機能や推奨方法であり、当サイトでの成果まで保証するものではありません。どの設定を採用したか、何件で検証したか、どこで停止したかは実行記録として別に残します。一次資料の記述を、実測した効果のように言い換えないことが重要です。

失敗した点と修正内容

最初は総予約件数だけでも足りるように見えました。しかし途中に空白日があれば毎日公開は止まります。件数ではなく、翌日から各日に1件以上あるかを連続日で判定する設計へ修正しました。

失敗を記録すると、同じ見た目の成功を次回も疑えます。原因、影響範囲、再現条件、採用した修正、修正後の再取得結果を一組にし、単に『対応済み』とは書きません。安全な再試行か、対象の隔離か、認証の再発行かを原因別に選びます。

再現するための確認表

  • 変更対象のサイト名、URL、投稿IDを明記したか
  • 変更前の本文、設定、status、日時を復元可能な形で保存したか
  • 一次資料の確認日とURLを記録したか
  • 測定値に単位と対象件数があるか
  • WordPress再取得で保存結果を比較したか
  • 公開後にcanonical、robots、H1、画像、構造化データを確認する予定があるか

この表の一つでも欠けた場合は、変更を広げず、読み取りとシャドー検証へ戻します。

向いていない環境と注意点

この手順はWordPress REST APIとApplication Passwordを使える環境向けです。プラグイン独自の投稿型や認証制限がある場合は、書き込み前に同じ再取得契約を実装する必要があります。

サイト構成、テーマ、プラグイン、権限、タイムゾーンが違えば、同じコマンドでも結果は変わります。この記事の数字を目標値として流用せず、自分の環境で小さな範囲から測定してください。削除、URL変更、公開状態変更は、対象を明示して承認を得てから行います。

まとめ:次回は効果ではなく再現性から測る

5サイト移行の安全確認は、実行、保存、再取得、公開確認を分けることで安全性を上げられます。関連するWordPress運用記事はブログ運営の実践記録にまとめています。公開後3日、7日、14日、28日にSearch Console、GA4、AdSenseを確認し、表示回数、流入、読了、収益への影響を測定します。変化がない場合も、技術的な安全性とSEO成果を分けて判断します。