ホームページの移管は、ファイルを別サーバーへコピーして終わる作業ではありません。Web表示が戻っても、メールが届かない、フォーム通知が来ない、旧URLが404になる、Search Consoleの所有権を失う、といった事故は起こります。最初に「何が変わり、何を維持するか」を分けることが安全な移管の出発点です。
この記事では、保守先変更やサイト移転を進める中小企業の担当者が、サーバー、ドメイン、DNS、メール、WordPress、URL、検索、フォームを一つの移管表で管理し、切替と復旧を判断する手順を整理します。
最初に移管方式を4つへ分ける
「ホームページを引っ越す」という言葉だけでは、必要な作業を決められません。URLが変わらないホスティング変更、ドメインやパスが変わる移転、CMS変更、DNS・メール管理先変更は別の作業です。複数が重なる場合も、各変更を分けて担当・切替時刻・合格条件を決めます。
| 方式 | 変わるもの | 中心となる確認 | Search Console対応 |
|---|---|---|---|
| URL維持 | サーバー、CDN、IP | 新環境、DNS、証明書、旧新トラフィック | 既存所有権とURL検査を維持 |
| URL変更 | ドメイン、プロトコル、パス | 旧新URL表、301/308、canonical、内部リンク | 旧新プロパティ、サイトマップ、条件によりChange of Address |
| CMS変更 | 管理画面、テーマ、機能、データ構造 | 本文、画像、機能、計測、権限の受入 | 公開URLが変わるかで分岐 |
| DNS・メール変更 | ネームサーバー、各DNSレコード、配送経路 | Web、MX、TXT、サブドメイン、送受信 | DNS所有権トークンを維持 |
GoogleのURLを変えないホスティング変更ガイドは、新環境を用意してテストし、DNSを切り替え、旧新サーバーのトラフィックを監視してから旧環境を止める流れを示しています。一方、ドメイン・プロトコル・パスが変わる場合はURL変更を伴うサイト移転として扱います。
着手条件は資産・権限・契約・復旧先がそろうこと
移管作業の前に、ドメイン登録者、DNS管理、サーバー、WordPress管理者、データベース、ファイル、ソースコード、計測、Search Console、メール管理の権限を確認します。「現在の制作会社に頼めば取れるはず」では着手条件を満たしません。組織側が実際にログインでき、二要素認証や請求先も引き継げる状態にします。
制作データ、契約、認証情報を受け取れない場合は先にホームページのデータと権限を回収する手順で所有・利用・再構築の選択肢を整理します。WordPress管理画面へ入れない場合は、設定を推測で書き換えず、WordPressログイン不能の切り分けへ分けます。リニューアルを伴うなら既存サイト資産の整理表も先に作ります。
Search Consoleは移管後も組織側所有者が残るようにします。Googleの所有権確認の案内では複数の確認方法を持てます。所有者・ユーザー・権限管理を確認し、HTML、DNS、Google Analytics、Google Tag Managerなど別サービスと共用する確認トークンを不用意に消しません。
現行環境は接続先と確認方法を1行ずつ記録する
資産台帳は「サーバー一式」の一行にまとめません。Webとメールが同じドメインを使っていても、契約先・設定場所・切替方法は別の場合があります。値だけでなく、管理画面、契約名義、更新期限、変更者、確認方法を残します。秘密情報そのものは台帳へ貼らず、保管場所への参照だけを記録します。
| 対象 | 記録する内容 | 切替前の確認 |
|---|---|---|
| ドメイン | 登録者、レジストラ、期限、移管ロック | 組織側で更新とDNS変更ができる |
| DNS | ネームサーバー、A/AAAA/CNAME/MX/TXT等 | 現行値と用途をエクスポート・照合 |
| サーバー/CDN | 契約、IP、証明書、ログ、制限 | 新環境のHTTP・TLS・容量を確認 |
| WordPress | 管理者、home/siteurl、DB、テーマ、プラグイン | 復元後に管理・公開両面へ入れる |
| メール | 受信、送信、転送、外部配信、認証 | 社内外の送受信と迷惑判定を確認 |
| 外部サービス | フォーム、決済、予約、API、計測、Search Console | 許可ドメイン、通知先、所有権を維持 |
WordPressはファイルとデータベースを同じ時点で扱う
WordPressの公開状態は、コア、テーマ、プラグイン、アップロード、設定ファイル、データベースが組み合わさって作られます。公式のMigrating WordPressは、サーバー移動、URL変更、設定ファイル、home/siteurl、リライト、マルチサイトなどで手順が異なる点を説明しています。エクスポート済み本文だけで完全移管と判断しません。
WordPressの一般設定では、WordPress AddressとSite Addressは意味が異なり、管理者メールも個人ユーザーのメールとは別です。新環境では公開URL、管理画面、パーマリンク、画像、管理者メールの確認を分けます。ドメインを一括置換するときは、直列化データやGUID、マルチサイトを単純な文字置換で壊さない方法を選びます。
候補制作中に記事ごとのフルバックアップやサイト全体保存を繰り返す必要はありません。この作業では対象記事の読み取り専用スナップショット1点だけを使います。全記事完成後に最終承認が得られた移管本番では、公式のWordPressバックアップ手順を踏まえ、同時点のファイルとデータベースを一つの検証済みバックアップセットとして用意し、復元手順まで確認します。
URLが変わる場合は旧新対応表を公開前に完成させる
ドメイン、http/https、www有無、ディレクトリ、個別ページのパスが変わる場合は、旧URLごとに新URLと処理を決めます。似ていないページをトップページへ一括転送せず、内容を引き継ぐURLがなければ404または410を検討します。画像、PDF、CSS、JavaScriptなど検索や外部リンクから使われるURLも対象です。
| 列 | 内容 | 公開後の合格条件 |
|---|---|---|
| 旧URL | canonical、サイトマップ、解析、ログから抽出 | 直接アクセス時の応答を記録 |
| 新URL | 同じ意図と内容を引き継ぐ最終URL | HTTP 200・自己canonical |
| 処理 | 維持、301/308、統合、404/410 | 転送連鎖とループなし |
| 内部参照 | 本文、メニュー、canonical、hreflang、schema | 旧URLを経由せず新URLへ直結 |
| 外部参照 | 広告、SNS、プロフィール、重要被リンク | 優先リンクを新URLへ更新 |
| 確認証拠 | HTTP、画面、日時、担当、例外 | 未確認と不合格を分ける |
Googleのリダイレクトガイドは、恒久移転で可能ならサーバー側の恒久リダイレクトを推奨しています。転送は最終URLへ直接つなぎ、canonical、内部リンク、新サイトマップも新URLにそろえます。Change of Addressはドメインまたはサブドメイン移転時に使うもので、ホスティング変更、同一ドメイン内パス変更、www有無だけの変更には使いません。
DNS切替ではWebだけでなくメールと所有権を守る
ネームサーバーを変えると、Web向けA/AAAA/CNAMEだけでなく、MX、SPF、DKIM、DMARC、Search Consoleや外部サービスの検証TXT、サブドメインも新しいDNSへ再現する必要があります。現行ゾーンを用途付きで照合し、値が分からないレコードを「不要」と推測して削除しません。TTLを事前に下げる場合は、変更が行き渡る時間と元へ戻す時刻も決めます。
Google Workspaceを使う場合、公式のMX設定で受信先を確認し、SPF設定ではWebサーバー、フォーム送信、メール配信サービスなど実際の送信元を洗い出します。他社メールを使う場合は、その事業者の現行公式値を使います。移管中は社内同士だけでなく、社外アドレスからの受信、社外への送信、返信、転送、フォーム通知を試します。
新環境はDNS切替前に利用者の操作まで検証する
新環境の確認はトップページが見えるだけでは足りません。代表ページ、画像、PDF、サイト内検索、メニュー、スマートフォン表示、ログイン、更新、フォーム送信、通知、自動返信、予約・決済、計測、404、Feed、サイトマップを確認します。テスト環境のnoindexやアクセス制限は、本番切替時に外す項目として台帳に残します。
| 対象 | テスト | 停止条件 |
|---|---|---|
| 表示 | 1440/1024/768/390px、画像、PDF、主要導線 | 欠落、混在コンテンツ、横切れ |
| 管理 | ログイン、編集、保存、予約公開、権限 | 組織管理者が復旧できない |
| フォーム | 入力、確認、送信、DB、通知、自動返信 | 不達、二重送信、個人情報露出 |
| 検索 | HTTP、canonical、robots、noindex、schema、サイトマップ | 公開ページのブロックや旧URL混在 |
| 外部連携 | 計測、広告、API、Webhook、予約、決済 | 重要処理または記録が欠落 |
| 復旧 | バックアップ整合、戻し方、所要時間、責任者 | 戻せる根拠がない |
公開は7ゲートで進め、合格しなければ止める
移管は日付だけを決めず、各段階の合格条件と中止判断を決めます。発注後の担当、変更、受入、公開判断は制作会社選定後の進行手順と共用できます。更新が長期間止まっているサイトは更新再開の現状確認、内製・外注・保守の選択は更新方法の選び方で先に整理します。
| ゲート | 完了条件 | 未達時の判断 |
|---|---|---|
| 1. 資産・権限 | 契約、認証、ファイル、DB、DNS、メールを操作可能 | 作業へ進まない |
| 2. 方式確定 | URL維持・変更、CMS、DNSの範囲が明確 | 見積と日程を再作成 |
| 3. 新環境受入 | 表示・機能・管理・検索・メールが合格 | DNSを切り替えない |
| 4. 公開承認 | 差分、時間、担当、連絡、復旧条件を承認 | 延期 |
| 5. 切替 | DNS・公開・転送を実行し時刻を記録 | 停止条件で復旧 |
| 6. 公開判定 | 外部回線・実端末・送受信・検索面で合格 | 修正または復旧 |
| 7. 旧環境停止 | 旧側トラフィック、ログ、契約終了条件を確認 | 旧環境を維持 |
公開後は検索・エラー・メール・問い合わせを別々に監視する
切替直後、翌営業日、数日後、数週間後の確認日を決めます。HTTP 5xx・404、応答速度、旧新サーバーログ、フォーム件数、メール不達、計測、検索のクリック・表示を別の指標として見ます。URL変更を伴う移転では一時的な検索変動があり得るため、順位だけで復旧判断をしません。
新URLの一覧はサイトマップの公式手順に沿って絶対URLで用意し、代表URLはSearch ConsoleのURL検査でインデックス状態とライブ取得を分けて確認します。検索流入が落ちた場合は検索トラフィック低下の切り分けを使い、技術障害、移転処理、需要変化を混同しません。
見積はコピー作業ではなく確認範囲で比較する
移管費用は、ページ数だけでなく、権限回収、DNSとメール、CMSとデータ量、独自機能、URL変更数、フォーム・決済、公開時間、監視期間、復旧試験で変わります。「移行一式」に何が含まれるかを、台帳、受入テスト、公開立会い、旧環境停止、引渡しの成果物で比較します。見積条件はホームページ更新費用と作業範囲でそろえられます。
公開後の保守、監視、権限台帳まで継続して任せる場合は、復旧目標、緊急連絡、月次確認、契約終了時の返却物を決めます。移管だけでなく日常運用も含む支援範囲はホームページ保守・更新サービスで確認できます。
まとめ
安全なホームページ移管は、URL維持、URL変更、CMS変更、DNS・メール変更を分け、資産・権限、接続先、旧新URL、受入テスト、公開ゲート、復旧条件を一つの台帳でつなぐ作業です。画面が見えることだけで完了にせず、メール、フォーム、検索、計測、管理画面、旧環境停止まで確認します。
みやあじよでは、現行資産と権限の確認、移管方式の分岐、WordPress・DNS・メールの切替、旧新URL表、公開判定、復旧手順まで整理します。移管予定日、変えたいもの、維持したいURL、現在分かる契約先を添えてお問い合わせフォームからご相談いただけます。
