Webサイトの移行は、慎重に計画すればスムーズに完了しますが、“つい慣れ”や“確認漏れ”で思わぬトラブルを招きがちです。特にフリーランスのWeb制作者は、移行失敗によるクライアントとの信頼低下や追加作業へのコスト負担を痛感した経験があるでしょう。本記事では、代表的な5つの失敗事例を取り上げ、原因の究明から具体的なリカバリ手順、再発防止策までを徹底解説します。自分の経験と照らし合わせながら読み進めることで、次回の移行作業を確実に成功させるポイントがつかめます。
バックアップ不十分で移行中にデータ損失
結論——バックアップ体制の不備が最大のリスク
WordPressサイト移行において、バックアップを甘く見ると、移行作業中のトラブル発生時に取り返しのつかないデータ損失を招きます。本件では、移行前のフルバックアップや差分バックアップが適切に取得されておらず、クライアントから提供された旧サーバーのファイル群が一部欠落していたため、移行完了後に「画像や投稿が消えた」状態で公開されるという重大なミスが起きました。
理由——テスト環境と本番環境でのバックアップ運用ミス
- バックアップ対象の漏れ
– データベースのみをエクスポートし、wp-content/uploads配下のメディアファイルをバックアップしていなかった - バックアップの検証不足
– ダウンロードしたバックアップZIPが破損しており、復元テストを一度も実施していない状態 - バックアップスケジュールの未整備
– 移行直前に最新データを取得せず、前日深夜のバックアップを使用したため、当日に投稿された記事が反映されなかった
具体例——実際のリカバリ手順
- 旧サーバーへの再接続とログ確認
– FTPログを洗い出し、欠落ファイルのパスを特定 - データベースの再エクスポート
– phpMyAdminまたはWP-CLIを用い、テーブルごとに圧縮なしSQLで取得 - メディアファイルの差分取得
–rsync --ignore-existingオプションを使い、本番にないファイルのみを転送 - 復元テストの実施
– テスト環境にリストアし、投稿数・画像リンク・リンク切れなどを一括チェックするスクリプトを実行 - 本番環境へ反映
– 一度に上書きせず、保守モードに切り替えた上で段階的に復旧を完了
予防策——次回から必ず実施すべきチェックリスト
- 多重バックアップ：本番サーバー上での手動バックアップに加え、第三者サービス（例：BackWPup, UpdraftPlus）の自動保存先を設定
- バックアップ検証：取得したバックアップファイルをテスト環境でリストアし、完全性を確認
- 差分管理：移行期間中も動的に投稿が入る場合は、移行前後で差分バックアップを取得
- バックアップログの記録：FTPログやCLIログをGitやファイルサーバーに残し、誰がいつ何をバックアップしたかトレーサビリティを担保
- ドキュメント化：移行手順書にバックアップ取得・検証フローを明文化し、手順逸脱を防止
テスト環境URL設定ミスで公開事故
結論——テスト環境のURL残存は公開直後の信頼失墜を招く
テスト環境のURLを本番環境と同じドメインやサブディレクトリに残したまま移行を完了すると、誤ってテストデータや開発中のコンテンツが公開されるリスクが高まり、クライアントやユーザーからの信頼を一瞬で損ないます。また、テストサイトのトップページが本番サイトと並列で稼働し、検索エンジンにインデックスされてしまうと、SEO評価の二重化や重複コンテンツのペナルティにもつながります。
理由——テスト環境と本番環境の分離不足
- URLプレフィックスの未更新
– テスト時に使用していたstaging.example.comからwww.example.comへ変更する際、一部リンクや画像パスがテストドメインのまま放置 - マルチサイト／マルチドメイン設定ミス
– WordPressのSite URL と Home URL が本番データベースで上書きされず、テスト用のサブディレクトリ/staging/が残存 - Search & Replace 処理の漏れ
–wp-cli search-replaceコマンドでの一括置換を行った際、一部テーブルを除外してしまい、常にテストURLを参照する設定が残った
具体例——発生からリカバリまでの手順
- 問題の可視化
– Google Analytics や Search Console のアクセスログから、不審な流入とインデックス状況を確認 - robots.txt・.htaccessによる一時ブロック
– テストURLがクローラーに回らないよう、Disallow: /staging/を追加し、.htaccessで403レスポンスを返却 - URL一括書き換え（Search & Replace）
– WP-CLI を用い、全テーブルに対してwp search-replace 'staging.example.com' 'www.example.com' --skip-columns=guidを実行 - キャッシュクリアと再検証
– CDN（CloudFront 等）とプラグイン側のキャッシュを完全消去し、ブラウザのシークレットモードで正常表示を確認 - インデックス削除申請
– Search Console で誤インデックスされたテストURLをURL検査→削除依頼し、本番URLのみをクローラーに許可
予防策——テスト環境と本番環境の厳格な分離
- 独立ドメイン／サブドメインの徹底
– テスト環境は必ずstaging.example.netのように本番ドメインと見た目でも判別可能な別ドメインに分離 - 自動Search & Replaceのスクリプト化
– 移行スクリプトにURL置換処理を組み込み、例外なく全テーブルを対象に実行 - プラグイン活用
– 「WP Migrate Pro」など、URL一括置換機能の信頼性が高いツールを活用し、ヒューマンエラーを低減 - ドキュメント化とレビュー
– 移行チェックリストにURL確認項目を追加し、作業終了前にチーム内で必ずダブルチェック - アクセス制限
– テスト環境には本番公開前にIP制限やBasic認証を導入し、クローラーアクセスを完全に遮断
DNS切替のタイミング誤りで長時間サイト停止
結論——DNS TTLを考慮しない切替はダウンタイムを招く
DNSレコードのTTL（Time To Live）設定を確認せずにレコードを切り替えると、旧サーバーに向いたキャッシュが残り続け、ユーザーによっては数時間から数日の間、異なるサーバーに到達してサイトが表示されない状態が発生します。これにより、サービス停止による収益損失やブランドイメージ低下を招きます。
理由——TTLとキャッシュ更新のメカニズム
- TTLが高設定
– 既存レコードのTTLが72時間に設定されており、早急な切替でもDNSキャッシュは保持される - DNSプロバイダー反映遅延
– 管理画面でレコードを更新後、数時間から最大24時間かけて各ISPに伝播 - 多層キャッシュの存在
– ユーザー端末、企業ネットワーク、ISPリゾルバ、公共DNS（Google DNS 8.8.8.8など）でのキャッシュ
具体例——停止事故発生から復旧手順
- ダウンフォールトモニタリング
– Pingdom や UptimeRobot でダウン検知アラートを受信 - キャッシュフラッシュ依頼
– TTLを一時的に最小値（60秒以下）に引き下げ、各公共DNSプロバイダーにキャッシュクリア依頼を送信 - 迅速なレコード更新
– Aレコードを旧サーバー→新サーバーIPへ切り替え後、TTL低設定のまま数時間待機 - 再度TTLを標準値に戻す
– キャッシュ反映後、安全のためTTLを3600秒程度に戻し、頻繁な再設定を抑制 - 全拠点からの動作確認
– VPNや各ISPのDNS設定下でブラウジングテスト、国内外の異なるDNSサービスでの到達性をチェック
予防策——DNS切替を円滑化するフロー
- 事前TTL調整
– 移行前72時間以上前にTTLを300秒程度に下げ、切替作業をスムーズに反映 - DNSプロバイダー選定
– 即時反映保証のあるプロバイダー（Cloudflare、Amazon Route 53等）を利用 - 継続的モニタリング
– 切替後24時間は各種モニタリングツールを稼働させ、異常を迅速検知 - 切替手順ドキュメント化
– TTL変更、レコード更新、確認手順を標準化し、誰が実施しても同じフローで対応可能に - 顧客通知
– 切替前にクライアントへメンテナンスウィンドウ予告を行い、ダウンタイムへの理解を得る
文字コード不一致で日本語が文字化け
結論——文字コードの取り扱いミスは一瞬でサイト品質を損なう
移行先サーバーのデフォルト文字コード設定（MySQLやWebサーバー）が旧サーバーと異なる場合、日本語コンテンツが“？”や“�”に化け、ユーザー体験を著しく低下させ、SEO面でもユーザービリティの悪化を招きます。
理由——MySQLとPHPの文字コード設定
- データベース照合順序（Collation）の差
– 旧サーバーはutf8mb4_general_ci、移行先がlatin1_swedish_ciだった - HTTPヘッダとHTML宣言の不一致
–<meta charset="UTF-8">を明示していても、サーバー側のAddDefaultCharset ISO-8859-1が優先 - エクスポート/インポート時のオプション漏れ
–mysqldump --default-character-set=UTF8オプションを付け忘れ、Shift_JISやEUC-JPが混在
具体例——文字化け修正手順
- 文字化け範囲の特定
– 文字化けが発生する投稿IDやメタテーブルをSQLクエリで抽出 - DB照合順序と文字セットの変更
–ALTER DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
各テーブル・カラムにも同様のSQLコマンドを実行 - 再インポート
–mysqldump --default-character-set=utf8mb4で取得し、mysql --default-character-set=utf8mb4でリストア - Webサーバー設定
– Apacheなら.htaccessにAddDefaultCharset UTF-8、Nginxならcharset utf-8;を設定 - 動作検証
– 主要ブラウザの表示をスクリーンショットで比較し、全ページの文字化け解消を確認
予防策——文字コード管理の徹底
- 統一文字セットポリシー
– プロジェクト開始時にUTF-8/utf8mb4を全環境で標準化 - 自動テスト導入
– CI環境でPost-deployスクリプトを動かし、文字化けチェックツール（HTML Tidy等）で検証 - データベース接続設定確認
–wp-config.phpにdefine('DB_CHARSET', 'utf8mb4'); define('DB_COLLATE', 'utf8mb4_general_ci');を明示 - 文字コードドキュメント化
– エクスポート/インポートフロー、サーバー設定をマニュアルに記載し、新人でも再現可能に
HTTPS設定漏れで混在コンテンツ発生
結論——SSL化の不備はユーザーからの信頼喪失に直結
HTTPS移行時に内部リンクや外部リソースをHTTPで残すと、ブラウザの「保護されていない接続」警告が表示され、離脱率増加やSEO評価の低下を招きます。
理由——混在コンテンツの発生メカニズム
- ハードコーディングされたHTTPリンク
– テーマやプラグインのテンプレート内でhttp://が直書き - 外部リソース呼び出し
– Google FontsやAnalyticsタグでhttp://を指定 - Search & Replaceの漏れ
– DB内の投稿URLは置換したが、テーマファイルやウィジェット内の設定を見落とした
具体例——混在コンテンツ解消手順
- 検出ツールで洗い出し
– Chrome DevTools の Securityタブ や「Why No Padlock?」で問題箇所をリスト化 - URL置換処理
– WP-CLIsearch-replace 'http://example.com' 'https://example.com' --all-tablesを実行 - テーマ・プラグイン修正
– テーマフォルダ内の.php/.css/.jsをgrep -R "http://"で検索し、一括修正 - 外部リソースのプロトコル相対URL化
–//fonts.googleapis.comのように記述を変更し、http/https両対応 - SSLテスト
– Qualys SSL Labs でA+評価を取得し、安全性を第三者に証明
予防策——SSL移行チェックリスト
- プラグイン活用
– 「Really Simple SSL」など、自動リダイレクト＆置換機能付きプラグインで一括対応 - コードレビュー
– テーマ・子テーマ開発時に static code analysis を実施し、http://を禁止するルールを設定 - CDN & キャッシュ
– CDNの設定で すべてのHTTPリクエストをHTTPSへ自動リダイレクト - 定期監査
– 移行後も半年ごとに混在コンテンツチェックを行い、運用中の欠落を早期発見
まとめ
本記事で紹介した五つの失敗談は、いずれも事前準備や確認不足が原因です。フリーランス制作者の皆さんは、バックアップの二重化、テスト環境の厳格分離、DNS・文字コード・SSL設定の徹底検証といったポイントを押さえることで、次回の移行作業を安全かつスムーズに進められます。移行失敗は誰にでも起こり得るもの。ただし、体系的な手順書とチェックリストを導入し、専門ツールやチームレビューを活用すれば、リスクは最小限に抑えられます。
