WordPress移行(サーバー引っ越し)は、ファイル一式とデータベースを新サーバーへ複製し、動作確認のうえでDNSを切り替えるという流れで進めます。本記事では、サーバー付帯の簡単移行ツール・プラグイン・手動の3方式の選び方から、ダウンタイムやリンク切れを防ぐ切替の実務、移行後の確認項目までを7ステップにまとめました。WordPressはCMS(コンテンツ管理システム)の一種です。CMSの仕組みや種類・選び方から知りたい場合はCMSとはもご覧ください。あわせて、自力で対応してよいサイトの条件と移行代行へ依頼すべき条件、代行費用の目安も整理します。判断の根拠になる仕様やツールの制約は、各社の公式マニュアルや公式ドキュメントへ本文からたどれるようにし、手を動かす場面ではコピーして実行できるコマンド例を添えました。企業サイトの担当者が、自社の状況に合う移行方法を選べる状態にすることが本記事の狙いです。
まとめ:WordPress移行は方式選定とDNS切替の設計で決まる
WordPress移行の成否は、作業そのものよりも「方式の選定」と「切替タイミングの設計」で決まります。標準構成に近いサイトなら、エックスサーバーの「WordPress簡単移行」などサーバー付帯ツールで完結する場面が多く、追加費用もかかりません。カスタマイズが入ったサイトはAll-in-One WP Migrationによる丸ごと移行、数GBを超える大規模サイトや特殊構成はFTPとphpMyAdmin、あるいはWP-CLIによる手動のデータ移行が候補になります。
ドメインをそのまま使うサーバー移行であれば、URLは変わらないため検索順位への影響は限定的です。GoogleもURLを変えないサイト移転を「新環境の準備→DNS変更→新旧のトラフィック監視→旧環境の停止」という4段階の作業として説明しており、順位そのものより切替の段取りに注意を向けています。障害はDNS切替とSSL設定の局面に集中するので、TTLの短縮と新旧サーバーの並行稼働期間を確保してから切り替えます。
会員機能や決済を持つサイト、停止が売上や信用に直結するサイトは、自力での夜間作業ではなく移行代行への依頼が確実です。線引きの基準は本文で条件付きで言い切ります。なお移行そのものを外注する前に、そもそもWordPressで運用を続けるかを見直す手もあります。判断材料はWordPressはオワコンかで、シェアと保守コストの両面から整理しました。移行を機にサイトごと作り替える選択肢を検討するなら、一創のWordPressサイト制作・CMS構築で構築から運用までまとめて引き受けています。
WordPressサーバー移行の基本構造と引っ越しを検討する場面
最初に、何を動かすのか・なぜ動かすのかを整理します。移行の対象と理由がはっきりすれば、後の方式選定で迷いません。なお、WixやJimdo、アメブロ、HTMLサイトなどWordPress以外からの乗り換えは前提条件が異なるため、他サービスからWordPressへの移行手順を別記事にまとめています。
表示速度・費用・サポート終了などサーバー移行を検討する典型的な場面
サーバー移行を検討するきっかけは、おおむね次のどれかに当てはまります。
- 表示速度が遅く、サーバースペック(CPU・メモリ・ストレージ)の上限に達している
- 月額費用が同等スペックの他社プランより高く、更新のたびに割高感がある
- サーバーのPHPが古く、WordPress本体やプラグインの要件を満たせない
- 利用中のプランやサービス自体が提供終了・サポート終了を迎える
- 制作会社の変更やサイト刷新にあわせて管理環境を引き上げたい
このうちPHPバージョンの問題は放置する時間だけ危険が増えます。WordPressの公式な動作環境は2026年9月時点でPHP 8.3以上、データベースはMariaDB 10.11以上またはMySQL 8.0以上とされ、HTTPSは「すべてのインストールに必須」と明記されています。古いPHPのまま動かし続けるとセキュリティ更新も受けられません。サイト刷新と同時に移す場合は、サイトリニューアルの進め方で解説しているSEO評価の引き継ぎ手順とあわせて計画すると、作業の重複を省けます。刷新するかどうかをまだ決めていない段階なら、判断の材料をサイトリニューアルとはで先に押さえておくと、移行と刷新のどちらを先に走らせるかが見えてきます。
移行で動かす2つの要素:WordPressのファイル一式とデータベース
WordPressのサイト実体は、大きく2つに分かれます。1つはサーバー上のファイル一式で、テーマ・プラグイン・アップロード画像が入るwp-contentディレクトリと、接続設定を書いたwp-config.phpが中心です。もう1つはデータベース(MySQLまたはMariaDB)で、記事本文・固定ページ・各種設定・ユーザー情報はすべてこちらに保存されています。
つまりサーバー引っ越しとは「ファイルの複製」と「データベースの複製」を新サーバーで再結合する作業です。片方だけ移すと、画面は表示されるのに記事がない、あるいは記事はあるのに画像が全滅する、という中途半端な状態になります。移行方式の違いは、この2要素をツールが自動で運ぶか、人が手で運ぶかの違いにすぎません。手順の原型はWordPress公式のMoving WordPressにまとまっており、サーバーだけを変える場合とURLごと変える場合で作業が分かれる点も公式が整理しています。
本体バージョンの扱いにも一言添えます。WordPress本体は公式のリリース一覧で7.1系(2026年8月19日リリース、2026年9月時点)まで進んでいます。移行時に新旧サーバーで本体バージョンを揃えておくと、復元後のテーブル構造の差異に起因するエラーを減らすことが可能です。逆に、移行と本体の大型更新を同じ日に重ねると、不具合が出たときの切り分けが難しくなります。更新は移行の前か後のどちらかに寄せてください。
ドメインそのままのサーバー移行とドメイン移管が必要になる場合の違い
「ドメインそのまま」でサーバーだけ引っ越す場合、URLは1文字も変わりません。DNSの向き先を新サーバーに変えるだけなので、検索エンジンから見てもページの場所は同じで、リダイレクト設定も不要です。相談の多くはこのパターンで、束ねて検索される「wordpress移行 ドメインそのまま」の答えは「可能で、むしろ標準的な形」になります。
一方、ドメインの管理会社ごと変えるのは「ドメイン移管」という別の手続きです。認証コード(AuthCode)の取得やレジストラ間の承認が必要になります。gTLDの場合、ICANNの移管ポリシーが3.7.5と3.7.6で「登録日から60日以内の移管申請」「直前の移管から60日以内の再移管」をレジストラが拒否できると定めており、登録者情報を変更した直後にも60日のロックがかかる仕組みです。サーバー移行と同時に動かすと切り分けが難しくなるため、先にサーバーを移し、安定稼働を確認してからドメイン移管に着手する順序を推奨します。WixやJimdoなど他サービスからWordPressへ乗り換える場合は、データ構造が異なるため本記事の手順がそのまま使えません。記事のエクスポートと再構築を含む別の計画が必要になります。
サーバー付帯ツール・プラグイン・手動移行の3方式と選び方の基準
移行方式は実質3択です。サイトの規模とカスタマイズの深さで選びます。迷ったら、まず付帯ツールを試し、失敗したら次の方式へ降りる順番で問題ありません。
エックスサーバー等の簡単移行ツールで丸ごと移行できる条件と制約
主要レンタルサーバーは、移行元のWordPress情報を入力するだけでファイルとデータベースを自動で複製する機能を備えています。制約は各社の公式マニュアルに明記されているので、着手前に自社サイトが条件を外していないかを確かめてください。
| 移行先サーバー | 付帯ツール名 | 公式が挙げる主な制約 |
|---|---|---|
| エックスサーバー | WordPress簡単移行 | マルチサイト不可・DB2GB超は不可 |
| ConoHa WING | WordPressかんたん移行 | 二段階認証の有効時は不可 |
| ロリポップ | WordPress簡単引っ越し | 対応プランを事前に確認 |
費用がかからず、FTPもデータベースも触らずに済むため、標準構成のサイトなら第一候補になります。エックスサーバーの公式マニュアルは、対応バージョンをWordPress 4.2〜7.1・PHP 7.2以上とし、移行対象をwp-contentフォルダ内のデータとデータベース内のデータに限ると説明しています。裏返せば、移行元の.htaccessやwp-content以外に置いたファイルは運ばれません。マルチサイト構成、データベース容量が2GBを超える場合、WordPress.comからの移行は対象外とも明記されています。
ConoHa WINGの公式マニュアルも同様に、WordPress 3.8.5より古い、PHP 5.3より古い、マルチサイト、管理画面の二段階認証が有効、プラグイン導入にFTP情報を要する設定といった条件を「使用できないサイト」として挙げています。逆に本番移行の前にテスト移行を試せる機能が用意されており、切替前の動作確認をツール側で完結させられる利点があります。ロリポップの公式マニュアルも移行元の管理者ログイン情報を入力して実行する形式です。セキュリティ系プラグインやログインURL変更プラグインが動いていると、いずれのツールも接続に失敗しやすくなります。移行元でこの種のプラグインを一時停止してから実行するのが定石です。
All-in-One WP Migrationの移行手順とアップロード上限の正体
All-in-One WP Migrationは、サイト全体を1つのアーカイブファイルに書き出し、新サーバー側で読み込むだけで丸ごと移行できるプラグインです。テーマのカスタマイズやプラグイン設定、データベースの中身まで一括で運べるため、付帯ツールが対応しない「異なるサーバー会社間」や「カスタマイズ済みサイト」で使われます。公式のプラグインページは2026年8月20日更新で、現在も保守が続いています。
誤解されやすいのが「無料版のインポート上限」です。開発元のServMaskは自社の解説記事で「この上限を設定しているのはプラグインではなくホスティング事業者だ」と明言しています。管理画面に出る数値は、PHPのupload_max_filesizeとpost_max_size、さらにWebサーバー側の受信サイズ制限(nginxのclient_max_body_size等)をプラグインが読んで表示しているだけ、という説明です。したがって最初に見るべきはプラグインの仕様ではなく、契約中のサーバーのPHP設定になります。
上限に当たったときの手は3つあります。1つ目はサーバー側でPHPの上限を引き上げる方法で、php.iniや.user.ini、.htaccessで指定できる環境なら費用はかかりません。2つ目はエクスポート時の詳細オプションでメディアライブラリを除外し、画像はFTPやrsyncで別送する方法です。3つ目はUnlimited Extension(年69ドル・50サイトまで)で上限を外す方法になります。それでも収まらない規模なら、次の手動移行へ切り替える判断が現実的でしょう。書き出しファイルはバックアップとしても機能するので、移行と同時に退避データを確保できる点も利点です。
FTPとphpMyAdminによる手動データ移行が向く大規模・特殊構成
手動移行は、FTP(またはSSH)でwp-contentなどのファイル一式を転送し、phpMyAdminでデータベースをエクスポート・インポートし、wp-config.phpの接続情報を新サーバーに合わせて書き換える方法です。ツールの容量制限を受けず、数GBを超えるメディアを持つサイト、マルチサイト、独自テーブルを持つ会員システム連携サイトでも対応できます。
その代わり、失敗要因も人の手に集中します。データベースの文字コード指定の不一致、URL置換の漏れ、ファイルパーミッションの崩れは典型例です。SSHが使える環境なら、次のようにコマンドで運ぶほうが取りこぼしが減ります。文字コードを明示し、ファイル転送は差分同期で回す形です。
# 旧サーバー: データベースを文字コード指定つきで書き出す
mysqldump --single-transaction --default-character-set=utf8mb4 -u olduser -p old_db --result-file=old_db.sql
# 旧サーバー: wp-content を新サーバーへ差分転送する
rsync -avz -e ssh ./wp-content/ [email protected]:~/public_html/wp-content/
# 新サーバー: 空のデータベースへ読み込む
mysql --default-character-set=utf8mb4 -u newuser -p new_db -e "source old_db.sql"
AWSなどクラウド環境へ移す場合は、サーバー構築自体の設計が加わるため、クラウド移行の進め方で移行方式と切替手順の全体像を確認したうえで計画してください。
WP-CLIでデータベースを書き出しURLを置換するコマンド手順
URLが変わる移行では、データベース内の旧URLを新URLへ置き換える作業が必要です。ここで単純な文字列置換をかけると、WordPressがオプション値などに使うPHPシリアライズ形式が壊れ、テーマ設定やウィジェットが消えます。公式のコマンドラインツールであるWP-CLIのwp search-replaceは「PHPのシリアライズデータを適切に処理し、主キーの値は変更しない」と明記されており、この事故を避けられます。
実行前のバックアップも同じツールで取れます。wp db exportでSQLファイルを書き出し、–dry-runで置換件数を確認してから本実行する流れが安全です。–skip-columns=guidは公式の例にも出てくる指定で、フィード用の識別子であるguid列を書き換えないためのものになります。
# 1. 先にデータベースを書き出して退避する
wp db export backup-before-replace.sql --add-drop-table
# 2. 置換対象と件数を確認する(この時点では保存されない)
wp search-replace 'http://old.example.com' 'https://example.com' --skip-columns=guid --dry-run
# 3. 問題なければ本実行し、キャッシュを破棄する
wp search-replace 'http://old.example.com' 'https://example.com' --skip-columns=guid
wp cache flush
# 4. サイトURLが書き換わったかを確認する
wp option get siteurl
wp option get home
WP-CLIが使えないレンタルサーバーでは、同じ働きをするプラグイン形式の置換ツールで代替します。どちらを使うにせよ、置換前のSQLファイルを手元に残しておけば、失敗しても元に戻せます。ドメインそのままの移行では置換自体が不要なので、この工程は「URLが変わるときだけ通る道」と覚えておくと段取りを間違えません。
ダウンタイムを防ぐWordPressサーバー引っ越しの手順7ステップ
方式が決まったら、実行の順序を固定します。手順の骨格はどの方式でも共通で、違うのはステップ3の運び方だけです。
新サーバー契約からDNS切替までの移行手順7ステップの全体工程
標準的な工程は次の7ステップです。
- 新サーバーを契約し、PHP・データベースのバージョンが要件を満たすか確認する
- 移行元でファイルとデータベースの完全バックアップを取得する
- 選んだ方式(付帯ツール/プラグイン/手動)でファイルとデータベースを複製する
- hostsファイルの書き換えで、DNS切替前に新サーバー上の表示と動作を確認する
- 新サーバー側でSSL証明書を設定し、https表示の準備を整える
- DNSレコードを新サーバーへ切り替え、浸透後の表示・フォーム・ログインを確認する
- 数日〜1週間の並行稼働を経てから、旧サーバーを解約する
要となるのがステップ4のhosts確認です。手元のPCのhostsファイルにドメインと新サーバーのIPアドレスを書き加えると、世間にはまだ旧サーバーが公開されたまま、自分だけ新サーバーの表示を検証できます。ここで管理画面ログイン・問い合わせフォーム送信・主要ページの表示を潰しておけば、切替当日の作業はDNS変更だけで済む状態です。Googleも前掲のサイト移転ガイドで、新環境の準備段階でのテストを最初の工程に置いています。
hostsファイルとdigコマンドで切替前の表示とDNSを確認する
hostsファイルはWindowsならC:\Windows\System32\drivers\etc\hosts、macOSやLinuxなら/etc/hostsにあります。管理者権限で開き、新サーバーのIPアドレスとドメインを1行ずつ書き足してください。wwwありとなしの両方を書いておくと、リダイレクトの挙動まで確認できます。
# hosts に追記する(新サーバーのIPを左、ドメインを右に書く)
203.0.113.25 example.com
203.0.113.25 www.example.com
# 現在のDNS応答とTTLを確認する
dig example.com A +noall +answer
# 外部の公開DNSから見た応答も確かめる
dig +short example.com @8.8.8.8
# 新サーバーが応答しているかをヘッダだけで確認する
curl -sI https://example.com | head -n 1
digの出力にはAレコードの値と残りTTLが秒で並びます。ここでTTLが3600のままなら、切替後に最大1時間は旧サーバーを見続ける端末が残ると読めます。確認が終わったらhostsに書いた行は必ず削除してください。消し忘れると、DNSを戻したときに自分だけ古い環境を見続け、原因の切り分けを誤ります。Googleは移転の確認手段として複数の公開DNSチェックツールを併用すること、サーチコンソールのURL検査ツールでGooglebotが新環境へ到達できるかを確かめることを挙げています。その具体的な使い方はサーチコンソールとはにまとめました。
DNSのTTL短縮と並行稼働でダウンタイムとメール停止を防ぐ方法
DNSの切替は世界中のキャッシュが順次入れ替わる仕組みのため、TTL(キャッシュ有効期間)が長いままだと新旧どちらに接続されるか分からない時間が長引きます。Googleは移転の少なくとも1週間前にTTLを数時間程度の控えめな値へ下げるよう案内しており、実務ではさらに踏み込んで切替の1〜2日前に300秒程度まで縮める段取りが取られます。混在時間を数分から1時間規模に抑えるのが狙いです。切替後、安定したらTTLは元の値に戻して構いません。
見落としやすいのがメールです。同じドメインでメールも運用している場合、DNSにはWebの向き先(Aレコード)とメールの向き先(MXレコード)が別々に定義されています。Webだけ移すつもりでネームサーバーごと変更すると、メールが新サーバーの空のメールボックスへ届き始め、実質的なメール消失が起きます。移行前にDNSレコードの一覧を控え、メールを旧環境に残すのか同時に移すのかを決めてから切り替えてください。混在時間帯に旧サーバーへ届いたメールや問い合わせを拾うためにも、旧サーバーの即時解約は避け、並行稼働期間を確保します。Googleのガイドも、全ユーザーが新環境からコンテンツを受け取っていることを確認してから旧環境を止める順序を示しています。
URL・SSL・301リダイレクトの確認でリンク切れとSEO低下を防ぐ
ドメインそのままの移行なら、URLが変わらないため301リダイレクトは原則不要です。逆にURLが変わる移行(ドメイン変更・httpからhttpsへの変更を伴う場合)では、旧URLから新URLへの301リダイレクトを1対1で設定しないと、被リンクと検索評価の引き継ぎが切れます。手順はGoogleのURLが変わるサイト移転に別立てでまとまっているので、該当する場合はそちらを先に読んでください。
SSLは切替直後の典型的な落とし穴です。理由は証明書の発行方式にあります。Let’s Encryptのチャレンジタイプのうち、広く使われるHTTP-01はドメイン直下の.well-known/acme-challenge/に置いたトークンファイルを取りに来る方式なので、DNSが新サーバーへ向いていないと検証が通りません。切替直後に証明書エラーが出る空白時間は、ここから生まれます。回避策は、DNSのTXTレコードで検証するDNS-01チャレンジを使うか、レンタルサーバー側の無料SSLを切替直後にすぐ発行できるよう手順を確認しておくことです。ワイルドカード証明書が必要な場合はDNS-01が前提になる点も、Let’s Encryptの公式文書に明記されています。
切替が済んだら、データベース内に旧サーバーのテスト用URLが残っていないかを置換ツールで確認し、サーチコンソールでクロールエラーが増えていないかを1〜2週間監視します。Googleは移転直後にクロール率が一時的に下がり、その後数日かけて戻るのは正常な挙動だと説明しているので、初日の数値だけで慌てる必要はありません。あわせて、サーチコンソールの所有権確認をHTMLファイルやmetaタグ、解析タグで行っている場合、その確認用ファイルを新環境にも残す必要があります。ここまでやれば、サーバー移行が原因で順位を失う可能性はかなり小さくなります。
WordPress移行の失敗パターンと自力・代行依頼を分ける判断基準
最後に、つまずきの実例と、自力でやるか移行代行へ出すかの線引きを示します。この章が本記事の結論です。
文字化け・SSLエラー・更新失敗など移行後に多い不具合と原因
移行後に問い合わせの多い不具合は、原因がほぼ決まっています。全ページの文字化けはデータベースの文字コード指定(utf8mb4等)の不一致、鍵マークの警告はSSL証明書の未発行・混在コンテンツ(http画像の読み残し)、下層ページだけ404になるのはパーマリンク設定の未反映で、管理画面から設定を保存し直すだけで直る例が目立ちます。テーマ設定やウィジェットだけが消えている場合は、URL置換でシリアライズデータを壊した疑いが濃厚です。
プラグインの動作不良は、新旧サーバーのPHPバージョン差が原因になりがちです。古いPHP向けのプラグインが新環境で致命的エラーを起こすと、画面全体が真っ白になることもあります。hosts確認の段階でプラグインを1つずつ有効化し、どれが原因かを切り分けられるようにしておけば、切替後に慌てません。バックアップさえ残っていれば、どの不具合も旧環境へ戻してやり直せます。復旧できない事故のほとんどは「バックアップを取らずに始めた」ケースです。
自力移行でよいサイトの条件と移行代行へ切り替えるべき条件の線引き
自力での移行は、次の3条件がそろうサイトに限って推奨します。標準構成に近くカスタマイズが浅いこと、数時間の表示不安定を許容できること、hostsファイルの書き換え程度の作業に抵抗がないことです。個人ブログや小規模なお知らせサイトの大半はここに入り、付帯ツールかAll-in-One WP Migrationで完結します。付帯ツールの制約表に1つも引っかからないなら、自力で進めてよい側だと判断できます。
逆に、会員機能・決済・予約など止められない機能を持つサイト、フォーム経由の商談が売上に直結する企業サイト、複数人が日常的に更新している編集体制のサイトは、自力の夜間作業では割に合いません。失敗時の損失が代行費用を上回るためです。マルチサイト構成、データベースが2GBを超える規模、独自テーブルを持つ連携システムがある場合も、付帯ツールが使えないので同じ側に入ります。この場合は移行代行へ依頼し、社内はコンテンツ確認に専念する分担が現実的です。一創ではWordPress保守・メンテナンスとして、サーバー移行を含む保守対応を請け負っています。移行を終えた後の更新・バックアップ・監視まで含めて任せる先を決めておくと、切替後の障害対応が速くなります。
移行代行の費用の目安と依頼前に整理して伝える情報・業者選定の観点
移行代行の費用は、標準的なレンタルサーバー間の引っ越しで数万円〜15万円前後が目安です。マルチサイトやカスタマイズの深いサイト、クラウド環境への移設を伴う案件では20万円を超えることもあります。金額を分けるのは「環境差異の大きさ」と「止められない度合い」の2点で、夜間・休日の切替指定は追加費用の対象になりがちです。移行ではなくサイトそのものを作り替える段階なら、制作の外注先選びから見直す判断になります。依頼先タイプ別の費用と選び方はWordPress制作代行の費用相場と制作会社の選び方で扱っています。
見積もり精度を上げるには、依頼前に次の情報を整理して渡します。現行サーバーのプラン名とPHPバージョン、サイトの容量(ファイルとデータベース)、使用プラグインの一覧、メール運用の有無、停止を許容できる時間帯の5点です。業者選定では、移行前後のバックアップ取得と切り戻し手順を提示できるか、SSL・DNS切替まで含めて請けるかを確認します。作業範囲が「データを移すだけ」の業者と「動作確認と障害対応まで」の業者では、同じ金額でも中身が別物です。見積もりの内訳を確認し、作業範囲の認識差をなくしてから発注します。移行が完了した後の更新・バックアップ・セキュリティ対応をどこまで委託するかは、WordPress保守運用の作業範囲と内製か外注かの判断基準で整理しています。
よくある質問
WordPress移行(サーバー引っ越し)について、検索の多い質問に答えます。
WordPressの移行はドメインそのままでできますか?
できます。ドメインを変えずにサーバーだけ引っ越す形が標準的で、URLは一切変わりません。DNSの向き先を新サーバーへ切り替えるだけなので、リダイレクト設定も不要で、検索順位への影響も限定的です。ドメインの管理会社を変えたい場合のみ「ドメイン移管」という別手続きが加わり、gTLDでは登録や直前の移管から60日間はレジストラが移管を拒否できる規定があります。サーバー移行の安定稼働を確認してから順番に進めることを推奨します。
WordPressのサーバー移行は自分でできますか?
標準構成のサイトなら自力で完了できます。目安は、マルチサイトではない、データベースが2GB以下、管理画面の二段階認証やログインURL変更プラグインを止められる、の3点です。この条件に収まっていれば、移行先の付帯ツールに移行元のURLと管理者ログイン情報を入れるだけで済みます。条件を外れるサイトはツールが途中で止まるため、手動移行かWP-CLIでの作業になり、コマンド操作と切り戻し手順の準備が作業の前提です。自信が持てない場合は、テスト移行機能のあるサーバーを選ぶと失敗のコストを下げられます。
All-in-One WP Migrationで移行できないときはどうすればよいですか?
まずインポート側の上限を疑ってください。開発元のServMaskは、この上限を決めているのはプラグインではなくホスティング事業者のPHP設定だと説明しています。対処は3段階で、サーバー側のupload_max_filesizeとpost_max_sizeを引き上げる、エクスポート時にメディアライブラリを除外して画像をFTPで別送する、それでも不足なら有料拡張か手動移行(FTP+phpMyAdmin)へ切り替える、と順に降りるのが定石です。移行先サーバーの付帯ツールが使える組み合わせなら、そちらを先に試す価値もあります。
サーバー移行中にサイトが見られない時間はどのくらい発生しますか?
正しく段取りすれば、閲覧者から見えるダウンタイムはほぼゼロにできます。旧サーバーを公開したまま新サーバーへ複製し、hostsファイルで動作確認を済ませてからDNSを切り替えるため、どの時点でもどちらかのサーバーが表示に応えるからです。DNS切替後の混在時間はTTLを事前に短くしておけば数分から1時間規模に収まります。逆に、旧サーバーを先に解約してから移行を始めると長時間の停止が確定するため、この順番だけは守ってください。
サーバー移行でSEOの順位は下がりますか?
ドメインそのままの移行なら、URLが変わらないため順位が下がる直接の理由はありません。実際に影響が出るのは、移行ミスでリンク切れや表示エラーを放置した場合、SSL証明書の空白時間が長引いた場合、URLが変わるのに301リダイレクトを設定しなかった場合です。Googleは移転直後にクロール率が一時的に下がり数日で戻ると説明しているので、初日の変動だけで判断しないでください。移行後1〜2週間はサーチコンソールでクロールエラーとインデックス状況を監視し、異常があれば早期に直せば、評価の引き継ぎで問題が起きる場面はほとんどありません。
WordPress移行の代行費用はどのくらいかかりますか?
標準的なレンタルサーバー間の移行で数万円〜15万円前後が目安です。サイト容量が大きい、マルチサイトである、クラウドへの移設を伴う、夜間切替を指定するといった条件で20万円超になる場合もあります。見積もり時は、サーバー仕様・サイト容量・プラグイン一覧・メール運用の有無・停止許容時間帯の5点を伝えると精度が上がります。金額よりも、バックアップと切り戻し手順を提示できる業者かどうかを先に確認してください。
関連記事
- WordPressはオワコンか?シェアと保守コストで採用可否を判断する:移行前にWordPressで運用を続けるべきかを判断する材料をまとめています。
- サーチコンソールとは?できること・設定手順とSEO改善への使い方:移行後のクロールエラー監視とURL検査の手順を解説しています。
- サイトリニューアルの進め方|SEO評価を落とさない6ステップと注意点:サイト刷新とサーバー移行を同時に進める際の計画手順を解説しています。
- クラウド移行の進め方|計画から移行方式・費用・切り替えまでの手順を発注者視点で解説:AWS等クラウド環境へ移す場合の方式選定と切替手順をまとめています。
- システム移行とは?移行方式の種類と進め方・失敗を防ぐ判断基準を解説:Webサイトに限らないシステム全般の移行方式と判断基準を整理しています。
- コーポレートサイトとは?目的・役割と「成果が出る」基本構成をWeb制作目線で解説:移行を機に見直したい企業サイトの構成と運用の基本をまとめています。