「WordPress簡単移行、完了しました！」
管理画面に表示されたその文字を見て、思わず大きく息を吐き出したんじゃないでしょうか。
慣れないサーバーパネルとの格闘、エラーが出ないかヒヤヒヤしながら見守ったプログレスバー。本当にお疲れ様でした。
でも、ぶっちゃけて言ってしまいますね。
ここからが本当の「サーバー移行」の始まり。
「えっ、まだやることあるの？ もう疲れたんだけど……」
そんな声が聞こえてきそうです。痛いほど分かります。私も昔、往復3時間の通勤電車の中でスマホを握りしめながら、同じように絶望した経験があるので。
当時の私は、「完了」の文字を見た瞬間、嬉しさのあまり即座にネームサーバーを切り替え、勢い余って旧サーバーの解約ボタンまでポチッと押してしまいました。
結果どうなったか。
翌朝、自分のサイトにアクセスしたら、トップページが真っ白。「404 Not Found」という無慈悲な文字だけが表示されていました。
数年間、泥臭く書き溜めてきた数百記事のデータ。毎月稼いでくれていたアフィリエイト報酬。それらが一瞬で吹き飛んだかのような恐怖で、文字通り血の気が引いたのを今でも鮮明に覚えています。
結論から言うと、シンレンタルサーバーの「WordPress簡単移行」が終わった段階では、まだ旧サーバーは絶対に解約してはいけません。
サイトのデータが新サーバーにコピーされただけで、ネット上の住所（DNS）や、検索エンジンからの評価の引き継ぎなど、やるべき重要な設定が山積みだからです。
この記事では、「もう失敗したくない」「今までの検索順位やアクセスを絶対に落としたくない」という方に向けて、実際に私が何度も冷や汗をかきながら確立した「絶対に事故らないための移行後チェックリスト」をステップバイステップで共有します。
ネットによくある「URLが変わらないなら301リダイレクトは不要です」といった教科書通りの正論だけではなく、「じゃあサブドメインから移した時はどうするの？」「SSLの警告が出たらどう対処するの？」といった、リアルな現場でつまずきがちなポイントも包み隠さずお伝えしていきますね。
大丈夫。ここまで来られたあなたなら、絶対に乗り越えられます。
旧サーバーを安全に解約して、ぐっすり眠れる状態になるまで、一緒に確認していきましょう。
結論｜WordPress移行は「移行完了」と表示されて終わりではない
改めてお伝えします。
シンレンタルサーバーの管理画面で「移行完了」と表示されても、それは単に「旧サーバーから新サーバーへ、WordPressのデータのお引越しが終わった」というだけに過ぎません。
例えるなら、新しい家（新サーバー）に家具（ブログのデータ）を運び込み終わった状態。
でも、郵便局に転居届（DNSの切り替え）を出していないので、お客さん（読者やGoogleのクローラー）はまだ古い家（旧サーバー）に向かってしまっているというわけです。
だからこそ、このタイミングで絶対にやってはいけないのが以下の2つ。
- いきなり旧サーバーを解約する
- 動作確認をせずにネームサーバー（DNS）を切り替える
これらを焦ってやってしまうと、「サイトが表示されない」「今までのアクセスがゼロになる」といった致命的な事故に繋がります。
私たちがこれからやるべきことは、
「新居（新サーバー）の家具の配置に問題がないか確認する」
↓
「転居届（DNS）を出す」
↓
「安全を確認してから、古い家（旧サーバー）を引き払う」
という、極めて現実的で石橋を叩いて渡るような作業です。
地味で面倒くさく感じるかもしれませんが、あなたがこれまで通勤電車の中や休日の時間を削って育ててきた大切なブログを守るための、最後の砦。
一つずつ、確実に潰していきましょう。
まず新サーバー側のWordPressを確認する
ネームサーバー（DNS）を切り替える前に、まずは「新サーバーにコピーされたWordPressが、本当に正常に動いているか」を確認します。
読者に公開する前に、裏口からこっそり入って内装をチェックするイメージですね。
シンレンタルサーバーには、ネームサーバーを切り替える前でもサイトの動作を確認できる「動作確認URL」という便利な機能があります。（あるいはPCのhostsファイルを少し書き換えて確認する方法もありますが、今回は一番安全で簡単な方法で確認したという前提で進めます）
新サーバーの環境にアクセスできたら、以下の項目を順番にテストしてみてください。
管理画面へログインできるか
まずは基本中の基本。新サーバー側のWordPress管理画面（wp-admin）に正常にログインできるかを確認します。
IDとパスワードは、旧サーバーで使っていたものと全く同じです。
ここで「パスワードが違います」と弾かれたり、画面が真っ白になったりする場合は、移行時にデータベースのコピーが上手くいっていない可能性があります。
トップページが表示されるか
ログインできたら、次はサイトの表側です。トップページが崩れることなく表示されているかチェックします。
ここで私が実際に経験した冷や汗ものの失敗談を一つ。
管理画面には入れるのに、トップページを見に行くと「404」エラー。原因は、移行先のサーバーディレクトリに元々空の「index.html」が置かれていて、WordPressの「index.php」より優先して読み込まれていたからでした。
もし同じような現象が起きたら、FTPソフトやファイルマネージャーから不要なindex.htmlをリネーム（または削除）してみてください。あっさり解決することが多いです。
代表的な記事ページを確認する
トップページが無事でも油断は禁物。「トップは表示されるけど、個別記事を開いたら全部エラーになった」というのも、移行あるあるです。
直近で書いた記事、アクセスを集めている主力記事など、いくつかのページを実際にクリックして、文章やレイアウトが崩れていないか確認してください。
画像が表示されるか
記事の中にある画像が、ちゃんと表示されているかも重要です。
文字データは移行できたのに、メディアライブラリの画像ファイルだけが上手くコピーされておらず、サイト中が「画像が見つかりません」のマークだらけになってしまうことがあります。
特にアイキャッチ画像や、記事内の図解など、重要な画像が抜け落ちていないか目視で確認しましょう。
問い合わせフォームをテストする
意外と見落としがちなのがこれ。Contact Form 7などのプラグインで作った問い合わせフォームが、新サーバーでも正常に動作するかテスト送信を行います。
読者からの連絡や、ASPからの特別単価のオファーなど、重要な機会を逃さないためにも「テスト送信です」と自分で入力して、ちゃんと自分のメールアドレスに届くか確認しておいてください。
テーマ・プラグインを確認する
最後に、使用しているテーマ（SWELLやCocoonなど）の設定や、有効化していたプラグインが旧サーバーと同じ状態になっているかを確認します。
キャッシュ系のプラグインや、セキュリティ系のプラグインが新サーバーの環境とバッティングしてエラーを吐いていることもあるので、ダッシュボードの上部に変な警告メッセージが出ていないかチェックしておくと安心です。
WordPressアドレスとサイトアドレスを確認する
よし、サイトの表示とログインは無事クリアですね。
ここからは少しずつ、WordPressの裏側の設定を確認していきます。
意外と見落としがちなのが、WordPressのシステム自体に登録されている「自分のサイトの住所」が、正しく新しいものになっているかという点。
「簡単移行ツールを使ったんだから、そんなの勝手にやってくれてるでしょ？」と油断するのは禁物です。
設定 → 一般を確認
管理画面の左メニューから「設定」→「一般」と進んでみてください。
上から3番目と4番目に、「WordPress アドレス (URL)」と「サイトアドレス (URL)」という項目があります。
移行先URLになっているか
ここのURLが、あなたがこれから運営していく正しいURLになっているか、一言一句見逃さずにチェックします。
もしドメインを変えずに（同じURLのまま）サーバーだけを移行したのなら、ここは旧サーバー時代と全く同じURLになっているのが正解。
でも、もし今回「サブドメインからサブディレクトリへ（例：sub.example.com から example.com/sub/ へ）」のようにURLの構成そのものを変える移行をしたのであれば、ちゃんと新しいURLに書き換わっているか確認必須です。
ツールも決して完璧ではありません。
もしここで古いURLや間違ったURLが残っていると、後々画像が読み込まれなかったり、ログイン画面から締め出される謎のリダイレクトループに巻き込まれたりします。
（恥ずかしながら、過去の私はこれをすっ飛ばしてネームサーバーを切り替え、貴重な休日の半日を復旧作業に溶かしました……）
正しいURLが入っていることを自分の目で確認できたら、次へ進みましょう。
パーマリンクを再保存する
続いて、WordPress移行時の「あるあるトラブル大賞」とも言えるパーマリンクの設定。
「トップページは綺麗に表示されたのに、渾身の収益記事をクリックしたら『404 Not Found』になった！終わった……！」
通勤電車の中でスマホ画面を見つめながら、リアルに顔面蒼白になった過去の私に教えてあげたい、魔法のボタンがあります。
設定 → パーマリンク → 変更を保存
やり方は拍子抜けするほど簡単。
管理画面の「設定」→「パーマリンク」を開きます。
そして、設定内容は一切いじらずに、画面の一番下にある「変更を保存」ボタンをポチッと押すだけ。
たったこれだけ。ホントにこれだけです。
URLの構造を変えたり、文字を入力し直す必要はありません。ただ「開いて、そのまま保存」する。いわゆる「空保存」です。
これをすることで、WordPressの裏側で動いている「.htaccess」という重要なシステムファイルが最新の状態にパチッと更新され、URLと記事の紐付けがリセットされるんです。
人間で言うところの、脳内リフレッシュですね。
記事URLが404にならないか確認する
ボタンを押したら、もう一度サイトの表側に回って、適当な個別記事をクリックしてみてください。
さっきまで無慈悲な404エラーを吐いていたページが、嘘のようにスッと表示されたんじゃないでしょうか。
もし最初から正常に表示されていたとしても、サーバー移行の直後は念のためこの「空保存」をやっておくのが、私たちのような個人ブロガーが生き残るための鉄則です。
これ、公式のマニュアルにはサラッとしか書かれていないことが多いですが、サイトの表示崩れを防ぐための泥臭くも強力なおまじない。絶対に忘れないでくださいね。
DNSを切り替える
よし、ここまでの確認で「新居の家具の配置」はバッチリですね。エラーもなく、管理画面にも入れる。
いよいよ本番、「転居届」を提出して、世の中の人たちに新しい住所を知らせる作業に入ります。
それが、ネームサーバー（DNS）の切り替え。
ここからが、本当の意味での引っ越し作業のスタートです。
新サーバー側の動作確認後に切り替える
改めて釘を刺しておきますが、DNSの切り替えは「必ず」これまでの動作確認がすべて完了してから行ってください。
「早く終わらせたいし、とりあえず切り替えちゃえ」は絶対にNG。
切り替えた後にサイトの表側を見て「あれ？ 画面が真っ白だぞ？」「レイアウトが崩壊してる！」となっても、すぐには元に戻せないのがこの作業の怖いところ。
ネットの世界に「ごめん、やっぱり前の住所でお願いします！」と伝わるまでには、とてつもない時間がかかってしまうんです。
取り返しのつかない事故を防ぐためにも、動作確認はしつこいくらいやって損はありません。
ネームサーバー変更かDNSレコード変更か確認する
実際の作業自体は、ドメインを管理しているサービス（お名前.comやXserverドメインなど）の管理画面で行います。
基本的には、ネームサーバーの指定をシンレンタルのもの（ns1.shin-server.jpなど）に丸ごと書き換えるだけ。数分で終わります。
ただし。
もしあなたが「ブログのURLとは別に、メールだけはGoogle Workspaceや他のサーバーを使っている」という場合は超・要注意。
安易にネームサーバーを丸ごと書き換えると、サイトは表示されるけれど「自分宛ての仕事のメールが一切届かなくなる」という大惨事に繋がります。
その場合はネームサーバー全体ではなく、「DNSレコード（Aレコード）」だけを新サーバーのIPアドレスに向ける、という少しマニアックな作業が必要になります。
もし心当たりがあるなら、切り替えボタンを押す前に必ず深呼吸。自分の環境がどちらに当てはまるのか、もう一度確認してくださいね。
DNS反映には時間差がある
無事に設定を保存。お疲れ様でした。
でも、ここで自分のスマホからサイトを見て「よし、ちゃんと表示されてる！ 切り替わった！」と安心するのは、実は少し早計。
DNSの切り替えというのは、世界中にある無数のサーバーに「このサイトの住所が変わったよー！」と伝言ゲームをしていくようなもの。
あなたの家（環境）ではすぐに切り替わって見えても、地球の裏側や別のプロバイダを使っている読者には、まだ旧サーバーが表示されている。
この「浸透期間（プロパゲーション）」は、短くて数時間、長ければ48時間ほど続きます。
DNS反映中は旧サーバーも残しておく
「DNSも切り替えたし、もう旧サーバーの解約ボタン押しちゃっていいよね？ 早く解約しないと月額もったいないし」
……ストップ。そのマウスに乗せた指、今すぐ離してください。
ここで旧サーバーのデータを消し去ることは、引っ越しの最中に前の家を爆破するのと同じくらい危険な行為です。
アクセス先が旧・新サーバーに分かれる可能性
先ほどお伝えした「伝言ゲームのタイムラグ」。
これが何を意味するかというと、最大48時間ほどの間、ネット上にはあなたのサイトが「2つ存在している」状態になるんです。
Aさんがアクセスすると新居（新サーバー）のサイトが表示され、Bさんがアクセスすると古い家（旧サーバー）のサイトが表示される。
完全に世界線が分岐しているパラレルワールド状態。これがDNS反映中のリアルな現実です。
旧サーバーをすぐ解約しない
もしこの不安定な時期に「もう終わった」と勘違いして、旧サーバーを解約しデータごと消し去ったらどうなるか。
未だに旧サーバー側の住所を信じている読者（あるいはGoogleの巡回ロボット）がアクセスした瞬間、「このサイトは存在しません」という無慈悲なエラー画面に叩き落とされます。
せっかく見に来てくれた読者も、検索エンジンからの評価も、その瞬間に台無し。
だからこそ、完全に伝言ゲームが終わるまで、絶対に旧サーバーを解約してはいけないんです。
コメント・問い合わせ・EC等の更新系サイトは特に注意
さらに恐ろしいのは、読者がアクションを起こせる「動きのあるサイト」の場合。
もし旧サーバーのサイトを見ている読者が、渾身の長文コメントを残してくれたり、重要な仕事の問い合わせフォームを送信してくれたら……？
そのデータは、いずれ解約して消えゆく運命にある「旧サーバー」の中にだけ保存されます。新居には一切引き継がれません。
「消えた問い合わせ」の出来上がりです。
私が過去に運営していた小規模な物販サイトでこれをやらかし、「注文したのに確認メールが来ないぞ！」というクレームが数日後に発覚して顔面蒼白になったのは、今となっては苦い（そして胃が痛くなる）思い出。
読者からのアクションが多いサイトの場合は、移行直前〜DNS反映完了までの数日間、フォームやコメント欄を一時的に閉じる「メンテナンスモード」にするのも立派な防衛策。
見えない事故を防ぐためにも、この「移行の狭間の数日間」は本当に慎重に扱ってくださいね。
SSLを確認する
DNSの浸透が徐々に進み、スマホやPCから新サーバー側のサイトへアクセスできるようになった。
ここでホッと一息つきたいところですが、実はもう一つ、読者を不安のどん底に突き落とすトラップが潜んでいます。
それが「SSL（HTTPS化）」の設定漏れ。
あの、ブラウザのアドレスバーに赤字でデカデカと表示される「保護されていない通信」という警告画面。自分のサイトでアレが出た瞬間の、血の気が引く感覚といったらありません。
読者からすれば「このサイト、ウイルス感染してるんじゃないの？」と疑って即離脱するレベルの致命傷になります。
httpsで正常表示されるか
まずはシンプルに、URLの先頭を「https://〜」にしてサイトへアクセスしてみてください。
シンレンタルサーバーの簡単移行では無料独自SSLも設定してくれることが多いですが、環境によっては上手く引き継がれていないケースもあります。
もしここで表示されない場合は、シンレンタルのサーバーパネルから「SSL設定」を開き、自分のドメインにSSL証明書がきちんとインストールされているか確認しましょう。
証明書エラーがないか
無事に「https://〜」で表示されたとしても、ブラウザのアドレスバーにある「鍵マーク」をクリックして詳細を見てください。
「この接続は安全です」と表示されていれば合格。
もしここで「証明書が無効です」といったエラーが出る場合、旧サーバーの古い証明書のキャッシュが残っていたり、新サーバー側での発行処理がまだ完了していない（DNS浸透待ち）状態だったりします。焦らず、少し時間を置いてから再確認するのが吉です。
httpからhttpsへ転送されるか
ここ、意外と見落とす人が多いポイント。
「http://〜（sなし）」の古いURLでアクセスしたときに、自動で「https://〜」へリダイレクト（転送）されるかテストしてみてください。
これまでの旧サーバーでは.htaccessというファイルで転送設定をしていたはずですが、移行のタイミングでその記述が消えたり、無効になったりすることがあります。
もし転送されずに「sなし」のままサイトが表示されてしまうと、Googleから「同じ内容のサイトが2つある」とみなされて重複コンテンツ扱いのペナルティを受ける危険性が。
転送されない場合は、シンレンタルの管理画面やプラグインを使って、早急に常時SSL化の転送設定を追加してください。
混在コンテンツがないか
「鍵マークは出た！ 転送も完璧！」
よし、完璧だ。……と言いたいところですが、まだ油断できません。
記事を開いたとき、アドレスバーの鍵マークが外れていたり、「一部のコンテンツが安全ではありません」と警告が出たりしませんか？
これが俗に言う「混在コンテンツ（Mixed Content）」。
テキスト自体はhttps化されているのに、記事内に貼り付けた画像のURLや、アフィリエイトのバナーリンクなどが「http://〜」のまま残っていると発生します。
特に昔から運営しているブログだと、古い記事の画像URLがそのままになっているケースが多発。私もこれで過去記事を一つずつ修正する羽目になり、通勤電車の中で絶望した記憶があります。
「Search Regex」などの一括置換プラグインを使って、データベース内の「http://自分のドメイン」を「https://自分のドメイン」に書き換える作業を忘れずに行いましょう。
サブドメインからサブディレクトリへ移した場合は301を設定する
さて、ここからは少し特殊ですが「絶対に知っておくべき」お話をします。
今回の移行のタイミングで、「URLの構成そのものを変えた」という方はいますか？
例えば、私自身が過去にやったのがこれ。
・旧URL：https://sub.example.com/article-a/ （サブドメイン）
・新URL：https://example.com/sub/article-a/ （サブディレクトリ）
このように、ドメインの文字列や階層が少しでも変わる場合。
これは単なる「サーバーのお引越し」ではなく、「ネット上の住所変更（ドメイン変更）」という扱いになります。
ここで絶対に必要になるのが「301リダイレクト」。
「古いURLにアクセスしてきた人を、自動的に新しいURLへ強制転送する」仕組みです。これをサボると、今までの検索順位やSEOの評価がすべてリセットされ、アクセスが文字通りゼロになります。冗談抜きで、数年間の努力が水の泡です。
旧URLと新URLを1対1で対応させる
301リダイレクトを設定する上で一番大切な鉄則。それは「旧記事A」は必ず「新記事A」へ飛ばすこと。
これを「1対1の対応」と呼びます。
読者が「この記事読みたい！」と思って検索結果から旧URLをクリックしたのに、全然違うページに飛ばされたらどう思いますか？ そっとブラウザの戻るボタンを押しますよね。Googleもこれを非常に嫌います。
全記事をトップページへまとめて転送しない
私が過去にやってしまった最悪の失敗。
「一つずつ設定するの面倒くさいし、とりあえず古いURLにアクセスが来たら、全部新しいサイトのトップページに転送しちゃえ！」
これ、SEO界隈では「ソフト404」と呼ばれる御法度です。
Googleの巡回ロボットからすれば「記事の評価を引き継いでほしいって言うけど、全部トップページじゃん。これ別のページだよね。じゃあ評価リセットで」と判断されてしまいます。
面倒でも、絶対に一括でトップページへ丸投げするような横着はしないでください。
できるだけ同じ記事同士を301する
基本的には、旧サーバー側の.htaccessファイルに転送用のコードを記述するか、WordPressの「Redirection」といったプラグインを使って設定します。
サブドメインからサブディレクトリへの変更なら、正規表現という少し専門的な記述を使えば「ドメイン部分だけを書き換えて、その後ろの記事URLはそのまま引き継ぐ」という一括設定も可能です。
いずれにせよ、
旧URL .../article-a/ → 新URL .../article-a/
旧URL .../review-b/ → 新URL .../review-b/
というように、中身が同じ記事同士をピタッと紐付けること。
これが、あなたが血と汗の結晶で育ててきたドメインパワー（ブログの資産）を、新しいURLへ一滴残らず注ぎ込むための唯一の手段です。
ドメイン・URLが同じなら301は基本的に不要
「サーバー 移行 301」
このキーワードで検索して、パニックに陥っていませんか？
ネット上の解説記事には「サーバーを移行したら301リダイレクトが必須！」とドヤ顔で書かれているものが本当に多い。
過去の私も、これにまんまと踊らされました。
「えっ？ URLは変わってないのに、どこからどこへ転送しろって言うの！？」と、夜中の3時にPCの前で一人フリーズしたあの絶望感。
結論からハッキリ言いますね。
もしあなたが「ドメイン（URL）は1ミリも変えずに、単にシンレンタルサーバーへ引っ越しただけ」なら、301リダイレクトは基本的に設定不要です。
なぜネット上でこれほど情報が錯綜しているのか。
それは、「サーバーの移行（家主が変わるだけ）」と「ドメインの移行（住所そのものが変わる）」を混同して説明している記事があまりにも多いからです。
先ほど説明した「サブドメインからサブディレクトリへ」のようにURLの文字列が変わったのなら、古い住所から新しい住所への転送（301）は絶対に必要。
でも、旧サーバーでも新サーバーでもURLが「https://example.com/」のまま変わらないのであれば、転送のしようがありませんよね。
あなたがやるべきことは、前述した「DNSの切り替え」だけ。
表札（DNS）を正しく掛け替えれば、読者もGoogleのクローラーも、迷うことなく新しいサーバーへやって来てくれます。
無用な混乱を招く複雑な転送設定は、そっと忘れてしまって大丈夫です。
Search Consoleを確認する
「サーバーを移行したら、SEOの評価がリセットされるんじゃないか……」
「数年かけて積み上げた検索順位が一気に圏外へ吹き飛んだらどうしよう……」
ブロガーにとって、これほど胃が痛くなる恐怖はありませんよね。私も移行のたびに、この不安と戦っています。
この見えない恐怖を払拭し、「Googleがちゃんと新居を認識してくれているか」を確認する唯一の手段が、Google Search Console（サチコ）です。
とはいえ、やることはシンプルなので安心してください。
同じドメインなら既存プロパティを確認
もしドメインを変更せずにサーバーだけを引っ越したのなら、サチコ側で新しい設定をやり直す必要はありません。
今まで毎日眺めていた（あるいは現実逃避で見て見ぬふりをしてきた）、あのプロパティ画面をそのまま開いてください。
DNSの切り替えが終わり、新しいサーバーでサイトが動き始めていても、URLが同じである限りGoogleはこれまで通り巡回を続けてくれます。
急にデータが途切れたり、再登録を求められたりすることはないのでご安心を。
新URLのインデックス状況を確認
逆に、もし今回の移行でURL構成を変更した場合（サブドメインからサブディレクトリ等）。
この場合は、サチコ上で「新しいURLのプロパティ」を新規作成する必要があります。
新しいプロパティの画面を開き、先ほど設定した「301リダイレクト」が正しくGoogleに認識されているか、新しいURLで検索結果にインデックス（登録）され始めているかを確認していきます。
ただ待つだけでなく、「URL検査ツール」を使って、アクセスを稼いでいる主力記事だけでも手動で「クロールリクエスト（早く見に来て！という要請）」を送っておくと、移行後の順位下落リスクをグッと減らせます。
サイトマップを確認
意外と盲点になるのが、XMLサイトマップの送信状態。
移行のゴタゴタの中で、XMLサイトマップを生成するプラグイン（XML Sitemapsなど）の設定が初期化されてしまったり、キャッシュの影響で古いサイトマップのまま更新が止まってしまうことがあります。
サチコの左メニューから「サイトマップ」を開いてみてください。
ステータスが緑色で「成功しました」となっているか。そして何より「最終読み込み日時」が、サーバー移行後の直近の日付になっているかを必ずチェックしましょう。
ここが止まっていると、せっかく新サーバーで書いた新着記事が、いつまで経ってもGoogleにインデックスされないという悲劇が起きます。
404やクロールエラーを確認
そして、移行が終わってから最低でも1週間。毎日必ずチェックしてほしいのが、サチコの「ページ（インデックス作成）」のエラーレポートです。
もし、移行時に一部の画像が欠落していたり、パーマリンクの設定がおかしくなっていたりすると、数日後にここで「見つかりませんでした（404）」というエラーが急増します。
過去の私が移行に失敗したとき、ここのグラフが突然真っ赤に跳ね上がり、文字通り心臓が止まりかけました。
「移行完了」と思っても、Googleの目線では見えないエラーが隠れているかもしれない。
早めにエラーに気づけば、リダイレクトの設定やリンクの修正で傷口を最小限に抑えられます。移行後の数週間は、サチコのレポートを「毎朝の健康診断」だと思って必ず目を通してくださいね。
Google Analyticsはどうする？
サチコの確認が無事に終わったら、次はアクセス解析の要、Google Analytics（GA4）です。
「移行してから数日経つけど、アナリティクスのアクセス数がずっとゼロのままなんだけど……」
「やばい、サーバー移行で何か致命的なミスをして、検索圏外に飛ばされた！？」
満員電車の中でスマホを見て、冷や汗がドッと吹き出す瞬間。
でも、ちょっと待ってください。深呼吸しましょう。
実はこれ、サイトへのアクセスがゼロになったわけではなく、単に「移行のゴタゴタで、アクセスを計測するタグが外れてしまっているだけ」というオチが非常に多いんです。
計測タグが残っているか確認
シンレンタルサーバーの簡単移行は非常に優秀なので、基本的には旧サーバーのデータがそのまま丸ごとコピーされます。
しかし、お使いのWordPressテーマ（SWELLやCocoonなど）の設定や、ヘッダーに直接コードを書き込む系のプラグインを使っている場合、キャッシュの不具合やデータベースの書き換え時に「GA4の計測タグ」がフッと消えてしまうことが稀にあります。
まずはWordPressの管理画面に入り、ご自身がタグを設置していた場所（テーマのカスタマイザー画面や、SEOプラグインの設定欄など）を開いてみてください。
「G-」から始まる測定IDや、トラッキングコードが旧サーバー時代と同じようにしっかり入力されているか、目視で確認しましょう。
リアルタイム計測を確認
タグが無事に残っていることを確認したら、一番確実なのは「自分でアクセスして計測されるか」を見ることです。
PCでアナリティクスの画面を開き、「リアルタイム」のレポートを表示させておきます。
その状態で、自分のスマホ（Wi-Fiを切って4G/5G回線にするなど、自分のIP除外設定をすり抜ける環境で）からサイトにアクセスしてみてください。
数秒〜十数秒後に、スマホからのアクセスがピコッとグラフに反映されればミッションクリア。
「ちゃんとアクセス、来てるじゃん……」と、胸をなでおろす瞬間ですね。
Google Tag Managerを利用している場合も動作確認
もしあなたが少し上級者で、「アナリティクスのタグはGoogle Tag Manager（GTM）経由で入れているよ」という場合もやることは同じです。
GTMのコンテナスニペット（あの長いコードです）が、新サーバーのサイトの<head>と<body>直下にしっかり残っているかソースコードを確認してください。
こちらもプレビューモードを使って、タグが正常に発火（動作）しているかテストしておけば完璧です。
データさえ繋がっていれば、どれだけ時間がかかってもこれまでのアクセス記録は途切れません。
広告・アフィリエイト・外部サービスを確認する
さて、ここからは私のような「ブログからの収益でお小遣い（あるいは生存資金）を稼いでいる」という方にとって、死活問題になるパートです。
サイトは表示された。アクセスも計測できている。
でも、「肝心の広告バナーが表示されていない」「アフィリエイトのリンクが壊れている」としたら？
それはただのボランティア活動になってしまいます。私たちが必死に確保した作業時間が、1円にもならないなんて悲しすぎますよね。
ASP登録URL
ここでも、URLの構成が変わったかどうかが運命の分かれ道になります。
サブドメインからサブディレクトリへ変更するなど、「URLが変わった」方。
今すぐ、A8.net、もしもアフィリエイト、バリューコマースなど、あなたが登録しているすべてのASP（アフィリエイト・サービス・プロバイダ）の管理画面にログインしてください。
そして、登録サイトのURL情報を「新しいURL」に変更申請する必要があります。これを忘れると、「登録外のサイトからの成果」とみなされて、せっかく発生した報酬が全キャンセル（非承認）になるという地獄を見ることになります。
逆に、ドメイン（URL）が全く変わっていない方は、ASP側の登録情報をいじる必要はありません。
広告タグ
Google AdSenseなどのクリック型広告を貼っている方も要注意です。
サーバーを引っ越した直後、「あれ？ アドセンスの広告が全部真っ白になってる？」という現象が起きることがあります。
原因の多くは、旧サーバーのルートディレクトリ（一番上の階層）に置いていた「ads.txt（アズテキスト）」というファイルが、新サーバーにコピーしきれていないこと。
シンレンタルのサーバーパネルからファイルマネージャーを開き、一番上の階層にちゃんと「ads.txt」が存在しているか確認してください。もし無ければ、アドセンスの管理画面から再度ダウンロードしてアップロードすれば、数日で広告は復活します。
reCAPTCHA
スパムコメントや迷惑メールを防ぐための「Google reCAPTCHA」。
これも、もしドメインを変更した場合は、reCAPTCHAの管理画面で「新しいドメイン」を追加登録し直す必要があります。
古いドメインのままだと、読者が問い合わせフォームを使おうとしたときにエラーが出て送信できなくなってしまいます。
外部API等
最後に、AmazonアソシエイトのAPI（Rinkerやポチップなどのプラグインで商品リンクを作っている場合）や、その他SNSの連携ツールなど。
これらも「URLが変わった場合」は軒並み設定の修正が必要です。
また、稀にですが「サーバーのIPアドレス」を制限にかけている外部サービスを使っている場合、新居（シンレンタルサーバー）のIPアドレスに変更申請を出さないと通信が弾かれることがあります。
面倒かもしれませんが、主力で稼いでくれている記事のAmazonリンクや広告バナーを実際にいくつかクリックしてみて、「ちゃんと成果が発生するリンクとして飛べるか」を自分の指でテストしてみてください。
数万、数十万の収益ロスを防ぐための、たった5分の確認作業です。
移行後に確認したいSEO項目
さて、広告やアフィリエイト周りの「収益直結」の確認もクリアしましたね。
ここから先は、今まであなたが泥臭く積み上げてきた検索エンジンからの評価（SEO）を、一滴もこぼさずに新サーバーへ引き継ぐための総仕上げです。
「簡単移行ツールを使ったんだから、SEOの設定も全部そのままでしょ？」
そう信じたいところですが、環境が変わった衝撃でWordPressの裏側の設定が初期化されたり、プラグインがエラーを起こしたりすることは珍しくありません。
過去の私のように、「なんか最近、じわじわ検索順位が落ちてる……」と数ヶ月後に手遅れになってから絶望しないよう。
以下のSEO関連項目が、旧サーバー時代と同じ状態になっているかサクッと確認しておいてください。
- canonical（カノニカル）タグ
ページのソースを開き、<link rel="canonical" href="正しいURL">が設定されているか。URL変更をした方は、ここが旧URLのままになっていないか要チェック。 - robots.txt
検索エンジンの巡回ロボットへの指示書。移行時にデフォルト状態に戻ったり、誤って「全ページの巡回を拒否」する設定になっていないか確認を。 - noindex設定
意図的に検索結果に出さないようにしていたページ（タグ一覧や低品質な過去記事など）のnoindexが外れていないか。または逆に、トップページに誤ってnoindexが入っていないか（これ、本当に顔面蒼白になります）。 - XMLサイトマップ
プラグイン（XML Sitemaps等）が正常に動き、最新のサイトマップを生成しているか。Search Consoleでエラーが出ていないか。 - 301リダイレクト
（URL変更をした場合のみ）旧URLから新URLへ、漏れなく転送が機能しているか。 - 404エラーページ
存在しないURLにアクセスしたとき、サーバーデフォルトの味気ない英語のエラー画面ではなく、あなたのサイトの「404ページ（見つかりませんでした等の案内）」が正しく表示されるか。 - 内部リンク
記事から別の記事へ飛ばすリンクが、きちんと新サーバーのURLに向いているか（プラグインで一括置換済みなら問題なし）。 - Search Console
先ほども触れましたが、移行後1週間は「カバレッジ（ページ）エラー」が急増していないか毎日監視する。
全部完璧だ！と胸を張れる状態になれば、SEO面の引き継ぎは完了です。
旧サーバーはいつ解約していい？
ここまで本当にお疲れ様でした。
いよいよ、あなたが一番気になっていた最大の疑問。「で、旧サーバーはいつ解約していいの？」というお話に入ります。
ぶっちゃけ、使わなくなったサーバーの月額料金なんて1円でも払いたくない。今すぐ解約ボタンをポチッと押して、固定費を削りたい。
その気持ち、痛いほど分かります。私も毎月のお小遣いを死守したい人間なので。
でも、ここまで慎重に積み上げてきた安全という名の石橋を、最後の最後で自ら叩き割るような真似はしないでください。
旧サーバーを安全に解約するには、以下の手順と「冷却期間」が絶対に必要です。
DNS変更直後は解約しない
何度もお伝えしている通り、ネームサーバー（DNS）を変更した直後は、ネット上に新旧2つのサイトが同時に存在している「伝言ゲームの最中」です。
この浸透期間（最大48時間ほど）に旧サーバーを消し去ることは、まだ古い住所に訪ねてきてくれている読者の目の前で、家を爆破するのと同じ。
「数日分のサーバー代」をケチった代償として、貴重なアクセスとGoogleからの信頼を失うことになります。
新サーバーの動作を一定期間確認
では、どれくらい待てばいいのか。
私自身の経験則から言うと、「DNS切り替え後、最低でも1〜2週間」は旧サーバーをそのまま契約状態にしておくことを強く推奨します。
数日経てばアクセス自体は新サーバーに100％向くようになりますが、それだけで安心はできません。
「週末になって初めてアクセスのピークを迎えたら、新サーバーのメモリ容量が足りずにサイトが落ちた」
「月に1回しか動かないバックアッププラグインが、新環境でエラーを吐いた」
こういった「しばらく動かしてみないと分からない隠れトラブル」が潜んでいる可能性があるからです。
もしこの期間中に新サーバーで致命的なエラーが起きたとしても、旧サーバーが生きてさえいれば、ネームサーバーを元に戻すだけでひとまず「元の家」に避難できます。
旧サーバーは、移行初期における最強の「命綱」なんです。
フォーム・メール等も確認
この冷却期間中に、もう一度だけ確認してほしいのが「読者からの連絡経路」。
特に、DNSが完全に切り替わるまでの数日間に、古い方のサーバーへひっそりと送られていた「迷子の問い合わせ」や「迷子のメール」がないか。
旧サーバーのウェブメール機能や管理画面にログインして、未読の重要なメッセージが放置されていないか、最後に見回りをしてください。
バックアップを取得
「よし、2週間経った。動作も完璧だ。いよいよ解約するぞ！」
その前に。本当にこれが最後の作業です。
旧サーバーに残っている「サイトの全データ（public_html内のファイル一式）」と「データベース（MySQL）」を、手動でパソコンにダウンロードして保存してください。
「新サーバーにちゃんとデータがあるんだから、わざわざ古いものを保存する必要なくない？」
そう思うかもしれません。
でも、人間は必ずミスをします。数ヶ月後に「あ！ あの時消しちゃった古い画像、やっぱり必要だった！」と気づいたとき、旧サーバーの解約後では完全に手遅れ。
お守り代わりの「完全なバックアップ」を手元に残しておく。これが、何が起きても生き残るための防衛策です。
問題なければ旧サーバーを解約
- 新サーバーで1〜2週間の安定稼働を確認した。
- 迷子の問い合わせやメールの取りこぼしもチェックした。
- 旧サーバーの全データをローカルに保存した。
この3つの条件がすべて揃ったとき。
初めて、あなたは心からの安心とともに、旧サーバーの「解約（退会）」ボタンを押すことができます。
本当の意味でのサーバー移行が完了する瞬間ですね。
旧サーバー解約前の最終チェックリスト
いよいよ大詰め。
旧サーバーの解約ボタンを押す前に、指差し確認レベルで最終チェックをしましょう。
「え、ここまで確認したのに、まだやるの？」と思うかもしれません。
でも、これが本当に最後。あなたが通勤電車の揺れに耐えながら、睡眠時間を削って書き上げてきた大切な記事たちを守るための、最後の砦です。
以下の項目にすべてチェックが入るか、今一度、自分の目で確認してください。
- トップページ：レイアウトが崩れず、正常に表示されているか
- 記事ページ：代表的な記事や稼ぎ頭の収益記事が404エラーになっていないか
- 画像：アイキャッチや記事内の解説画像がリンク切れしていないか
- wp-admin：新サーバー側のWordPress管理画面に問題なくログインできるか
- SSL：URLが「https」になり、ブラウザに鍵マークが出ているか。リダイレクトは効いているか
- 301リダイレクト：（URL構成を変更した場合のみ）旧URLから新URLへ自動で転送されるか
- 問い合わせフォーム：テスト送信をして、自分の手元のメールボックスに届いたか
- メール：独自ドメインのメールアドレス（MXレコード等）の送受信は正常か
- Search Console：エラーが急増していないか、サイトマップは無事に読み込まれているか
- Google Analytics：自分のスマホからのアクセスが「リアルタイム」で計測されているか
- バックアップ：万が一に備え、旧サーバーのデータをまるごとPCにダウンロードしたか
- DNS：切り替えから十分な冷却期間（最低1〜2週間）が経過し、旧サーバー側に迷子のアクセスが残っていないか
すべてクリアできましたか？
本当にお疲れ様でした。これで心置きなく、旧サーバーの解約手続き（退会）に進むことができます。
実際に移行後に遭遇したトラブル
ここでは少し箸休め（と言っても当時は全く笑えませんでしたが）として、私が過去にシンレンタルへ移行した直後に遭遇し、リアルに寿命が縮んだトラブルを2つシェアさせてください。
「あ、こんなバカなミスする奴もいるんだな」と笑い飛ばしつつ、反面教師にしていただければ幸いです。
管理画面には入れるのにトップページが404
これ、本当に血の気が引きました。
簡単移行ツールで「完了」の文字を見て、ガッツポーズ。ログイン画面にもすんなり入れて「なんだ、サーバー移行って余裕じゃん」と調子に乗っていた数分後。
サイトの表側にアクセスした瞬間、真っ白な画面に「404 Not Found」という文字だけがポツンと表示されたんです。
「えっ、記事全部消えた！？」とパニックになりながら、震える手でFTPソフトを開いてサーバーの中を覗き込みました。
結果から言うと、原因は拍子抜けするほど単純。
移行先のシンレンタル側に、初期設定として置かれていた空の「index.html」というファイル。これが、WordPressの命である「index.php」よりも優先して読み込まれてしまっていたんです。
その「index.html」の名前をパッと変えた（無効化した）だけで、一瞬でサイトが元通りに復活。あの時の全身の力が抜けるような安堵感は忘れられません。
もし、今まさに同じ症状で絶望している方がいたら、焦らずこちらの記事（※「管理画面には入れるのに404になる原因と解決策」への内部リンク）をチェックしてみてください。すぐ直りますよ。
サブドメインからサブディレクトリへ変更
これは単なるサーバー移転ではなく、「ドメイン構成の変更」を同時にやってしまった無謀なケース。
当時の私は「サブドメイン（sub.example.com）で別運営していたブログを、メインブログのサブディレクトリ（example.com/sub/）に統合したい！」と思い立ち、勢いで移行ツールを回しました。
結果、何が起きたか。
旧URLへのアクセスがすべて無効になり、せっかく育っていた検索順位が一時的に圏外へ吹き飛びました。
大急ぎで「.htaccess」ファイルに正規表現を使った301リダイレクトを設定し、なんとかGoogleからの評価を取り戻しましたが……。「サーバー移行」と「URL変更」を一緒にやると、トラブルの難易度が跳ね上がるんだなと痛感した強烈な体験です。
この時の泥臭い復旧作業と、具体的な301転送コードの書き方については、長くなるので別記事（※「サブドメインからサブディレクトリへの移行と301設定」への内部リンク）にまとめました。
私と同じように変則的な移行（URL変更）を考えている方は、必ず事前に読んで、強固な防衛線を張っておいてくださいね。
WordPress移行後の作業順をまとめる
ここまで、本当にたくさんの確認作業を乗り越えてきましたね。お疲れ様でした。
文字にすると長くてウンザリするかもしれませんが、一つひとつは「開いて確認するだけ」「ボタンを押すだけ」のシンプルな作業ばかり。
最後に、あなたが作業の途中で迷子にならないよう、全体のロードマップを1枚のチェックリストとして整理しておきます。
ブックマークやスクリーンショットに保存して、通勤電車の中や夜のスキマ時間の作業中に、一つずつ消し込んでみてください。
【WordPress移行・完全攻略チェックリスト】
- 新サーバーのWordPress確認（ログイン、表示崩れ、フォームのテスト）
- WordPress URL確認（設定画面の2つのURLが正しいか）
- パーマリンク確認（設定画面を開いて、何も変えずに「空保存」）
- DNS切り替え（ネームサーバー変更。ここで初めて表札が切り替わる）
- SSL確認（httpsでの表示、自動リダイレクト、混在コンテンツの修正）
- 必要なら301設定（※サブドメインからの移行など、URLが変わった人だけ必須）
- Search Console確認（エラーの監視、新しいサイトマップの送信）
- Analytics確認（自分のスマホからのリアルタイム計測テスト）
- 広告・外部サービス確認（ASPの登録URL変更、アドセンスのads.txtなど）
- 一定期間の動作確認（DNS浸透のタイムラグに備え、1〜2週間は様子見）
- 最終バックアップ（旧サーバーの全データをPCへまるごと保存）
- 旧サーバー解約（すべてクリアして、初めて解約ボタンを押す）
この順番通りに進めれば、取り返しのつかない致命傷を負うことは絶対にありません。
まとめ｜旧サーバーを安全に消せるまでがWordPress移行
シンレンタルサーバーの「WordPress簡単移行」機能。
確かにツール自体は魔法のように優秀で、数年前の手作業によるデータベース移行に比べたら、涙が出るほど快適になりました。
でも、「完了」という画面が出たからといって、ネット上の引っ越しがすべて終わったわけではないという現実。
新しい家（サーバー）に荷物を運び込んだ後、電気や水道を開通させ、転居届を出し、古い家を安全に引き払う。そこまでやって初めて、本当の意味での「サーバー移行」は完了します。
「DNS？ 301リダイレクト？ もう専門用語ばかりで頭が痛い……」
最初は誰だってそうです。私も、知識ゼロの状態で何度もサイトを吹き飛ばしかけ、冷や汗を流しながら夜中に復旧作業をした痛い経験があります。
だからこそ、あなたには同じ失敗をしてほしくなくて、少し口うるさいくらいに「確認」「待機」「バックアップ」の重要性をお伝えしてきました。
ここまで読んでくれたあなたなら、絶対に安全に、そして大切な検索順位や読者を失うことなく、新しい環境への移行を完了できるはず。
焦らなくて大丈夫。
月額数百円をケチって急ぐ必要なんてありません。旧サーバーの解約ボタンを押すその瞬間まで、一つずつ着実に不安要素を潰していきましょう。
あなたのサイトが無事に新居で動き出し、これまで以上の成果を上げてくれることを、心から応援しています。
大仕事、本当にお疲れ様でした。今日はひとまず、ぐっすり眠ってくださいね。