sshを活用したWordPressサーバー移行の完全攻略法！パーミッションエラーやリンク切れを起こさないためのチェックリスト

WordPressサーバーの移行、これほど「ちょっと危険な作業」も珍しいのではないでしょうか。

FTPクライアントでファイルをドラッグ&ドロップする方法もありますが、大量のファイル転送は時間がかかるうえ、パーミッションが崩れたり、シンボリックリンクが正しく扱われなかったりと、トラブルの温床になりがちです。

そこで有効なのが、SSH（Secure Shell）を使った移行です。
コマンド一つでサーバー間を直接つなぎ、rsyncやscpでファイルを高速かつ整合性を保ったまま転送できます。
GUIツールを介さない分、権限情報も正確に引き継げるのが大きな利点です。

とはいえ、SSHでの移行にも落とし穴はあります。
特に注意すべきは以下の3点です。

ファイル・ディレクトリのパーミッション設定ミス
データベースの文字コード不一致
移行後のURL・パス変更に伴うリンク切れ

これらは一つでも見落とすと、サイトが真っ白になったり、画像が表示されなくなったりと、致命的な症状を引き起こします。

本記事では、SSHを用いたWordPressサーバー移行の具体的な手順を、コンピューターサイエンスの知見に基づいて体系的に解説します。
あわせて、移行前後で必ず確認すべきチェックリストも用意しました。
「移行作業で失敗したくない」という方は、ぜひ最後まで目を通してみてください。

なぜWordPressサーバー移行にSSHが最適なのか?
1. FTP移行との違いとSSHのメリット
2. SSH移行に必要な事前準備
SSH接続前に確認すべきサーバー環境チェックリスト
1. PHP・MySQLバージョンの互換性確認
2. SSHアクセス権限とポート番号の確認
SSHでWordPressファイルを移行する具体的な手順
mysqldumpを使ったデータベース移行の実践方法
1. データベースのエクスポートとインポート手順
2. 文字コード(charset)の不一致を防ぐ設定
パーミッションエラーを未然に防ぐ権限設定ガイド
1. ディレクトリとファイルの適切なパーミッション値
2. chown・chmodコマンドの正しい使い方
移行後に起こりがちなリンク切れの原因と対処法
1. 絶対URLと相対URLの違いによる影響
2. wp-config.phpとデータベース内URLの一括置換
移行完了後に必ず実施すべき動作確認とテスト項目
1. 表示崩れ・404エラーのチェック方法
2. SSL証明書とhttps化の確認
SSH移行のトラブルシューティングと注意点
1. 接続タイムアウトへの対処
2. バックアップからのロールバック手順
まとめ:SSHを使った安全なWordPress移行のポイント

なぜWordPressサーバー移行にSSHが最適なのか?

サーバー移行の手段は複数存在しますが、なぜ本記事ではSSHを推奨するのでしょうか。
その理由は、処理の透明性と再現性にあります。
GUIツールでは内部で何が実行されているかがブラックボックス化されがちですが、SSHはコマンド一つひとつが明示的であり、何が起きているかを常に把握できます。
エンジニアリング視点で見れば、これは非常に大きな利点です。

FTP移行との違いとSSHのメリット

従来主流だったFTP移行と、SSHを使った移行には、根本的な違いがあります。

比較項目	FTP移行	SSH移行
転送速度	低速(1ファイルずつ)	高速(並列・圧縮転送可)
パーミッション保持	崩れやすい	保持されやすい
データベース移行	別途ツールが必要	コマンドで一括処理可能

FTPは手軽である一方、大量のファイルを転送する際に処理速度がボトルネックになります。
また、パーミッション情報が正しく引き継がれないケースも珍しくありません。

一方でSSHは、rsyncのような差分転送に対応したコマンドを使うことで、転送量を最小限に抑えつつ、パーミッションやタイムスタンプといったメタデータも維持したまま移行できます。
サーバー間で直接データをやり取りするため、ローカル環境を経由する必要がない点も、時間短縮につながる要素と言えるでしょう。

SSH移行に必要な事前準備

SSHでの移行を始める前に、いくつか確認しておくべき項目があります。
準備を怠ると、移行作業の途中でつまずく原因になりかねません。

移行元・移行先サーバーのSSHアクセス権限
公開鍵認証の設定状況
サーバーのディスク容量(移行先に十分な空き容量があるか)
PHP・MySQLのバージョン情報

まず確認すべきは、両サーバーへのSSH接続が可能かどうかです。
パスワード認証だけでなく、公開鍵認証を設定しておくと、セキュリティ面でも安心です。

ssh-keygen -t ed25519 -C "migration-key"

このコマンドで鍵ペアを生成し、公開鍵を移行先サーバーの~/.ssh/authorized_keysに登録しておきましょう。

また、移行先のディスク容量が不足していると、転送途中でエラーが発生する可能性があります。
df -hコマンドで空き容量を事前に確認しておくことも、地味ながら重要な準備の一つです。
こうした基礎的な確認を怠らないことが、結果的にトラブルのないスムーズな移行につながります。

SSH接続前に確認すべきサーバー環境チェックリスト

実際にSSH接続を開始する前に、サーバー環境そのものを点検しておくことが重要です。
移行作業は「動いてから考える」のではなく、「動く前提を確認してから実行する」姿勢が求められます。
ここでは特に見落とされがちな2つの観点について整理します。

PHP・MySQLバージョンの互換性確認

WordPressは、PHPおよびMySQL(またはMariaDB)のバージョンに強く依存するアプリケーションです。
移行元と移行先でバージョンに差異があると、プラグインが正常に動作しなかったり、最悪の場合はサイト全体が真っ白になる、いわゆる「White Screen of Death」を引き起こすこともあります。

まずは移行元サーバーで、以下のように現在の環境情報を取得しておきましょう。

php -v
mysql --version

取得した情報は、移行先サーバーの環境と照らし合わせて確認します。
特に注意すべきポイントは以下の通りです。

PHPのメジャーバージョンが異なっていないか(例:PHP7系からPHP8系への移行)
非推奨(deprecated)になった関数を使用しているプラグインがないか
MySQLの文字コード設定(utf8からutf8mb4への移行など)がプラグインの想定と一致しているか

特にPHP8系では、型に関するチェックが厳格化されているため、古いプラグインやテーマがエラーを吐くケースが少なくありません。
事前にテスト環境で動作確認しておくと安心です。

SSHアクセス権限とポート番号の確認

次に確認すべきは、SSH接続そのものの設定です。
セキュリティ強化のため、多くのレンタルサーバーやVPSでは、デフォルトの22番ポートから変更されていることがあります。
接続情報は事前に控えておきましょう。

確認項目	内容	確認コマンド例
ポート番号	22番か、変更されたポートか	サーバー管理画面で確認
ユーザー権限	rootか一般ユーザーか	`whoami`
sudo権限	必要な操作にsudoが使えるか	`sudo -l`

ポート番号が変更されている場合、接続時には-pオプションで明示的に指定する必要があります。

ssh -p 2222 user@example.com

また、一般ユーザーでログインする場合は、ファイルの所有者やパーミッション変更にsudo権限が必要になる場面もあります。
事前にsudo -lで自分の権限範囲を確認しておくと、作業中に権限不足でつまずくことを防げます。
こうした地味な確認作業こそが、後々の大きなトラブルを未然に防ぐ鍵となるのです。

SSHでWordPressファイルを移行する具体的な手順

事前準備が整ったら、いよいよ実際のファイル移行に入ります。
WordPressのファイル群は、コアファイル・テーマ・プラグイン・アップロード画像など多岐にわたるため、転送方法を誤ると想定以上に時間がかかったり、一部のファイルが欠落したりする恐れがあります。
ここでは代表的な2つのコマンドと、転送を効率化するテクニックを紹介します。

rsyncコマンドによるファイル転送

WordPressのファイル移行において、最も推奨されるのがrsyncコマンドです。
差分転送に対応しているため、途中で通信が途切れても再実行時には転送済みの部分をスキップでき、パーミッションやシンボリックリンクの情報も保持されます。

rsync -avz -e ssh /var/www/html/wordpress/ user@example.com:/var/www/html/wordpress/

各オプションの意味は以下の通りです。

-a:アーカイブモード。パーミッションや所有者情報を維持したまま転送
-v:詳細ログを表示(verbose)
-z:転送時にデータを圧縮
-e ssh:SSH経由での通信を明示的に指定

特に-aオプションは、パーミッションエラーを防ぐうえで欠かせません。
単純なcpやFTPでは失われがちな情報も、rsyncならそのまま引き継げます。

scpコマンドを使ったピンポイント転送

一方、特定の設定ファイルだけを素早く転送したい場合には、scpコマンドが便利です。
rsyncほど多機能ではありませんが、シンプルな分、単一ファイルのやり取りには扱いやすいという特徴があります。

scp wp-config.php user@example.com:/var/www/html/wordpress/wp-config.php

wp-config.phpのような機密情報を含むファイルは、まとめて転送するのではなく、内容を確認しながら個別に転送したほうが安全です。
移行先の環境変数やデータベース接続情報が異なる場合、そのままコピーすると接続エラーの原因にもなりますので、転送後は必ず内容を見直しましょう。

転送時間を短縮する圧縮テクニック

ファイル数が数万点を超えるようなWordPressサイトの場合、個々のファイルを転送するオーバーヘッドが無視できなくなります。
そこで有効なのが、事前にアーカイブ化してから転送する方法です。

tar czf wordpress_backup.tar.gz /var/www/html/wordpress/
scp wordpress_backup.tar.gz user@example.com:/var/www/html/

移行先サーバーで解凍する際は、以下のように実行します。

ssh user@example.com "cd /var/www/html/ && tar xzf wordpress_backup.tar.gz"

小さなファイルを大量にやり取りするより、一つの圧縮ファイルとして転送するほうが、通信のオーバーヘッドを大幅に削減できます。
特に画像ファイルが多いメディアライブラリを含む移行では、この手法の効果を実感しやすいはずです。
転送量や環境に応じて、rsyncと圧縮転送を使い分けることをおすすめします。

mysqldumpを使ったデータベース移行の実践方法

ファイルの移行と並んで重要なのが、データベースの移行です。
WordPressは投稿内容や設定情報の大半をMySQL(またはMariaDB)に保存しているため、この工程を誤ると、サイトの表示崩れやログイン不能といった深刻な問題に直結します。
ここではmysqldumpを用いた具体的な手順と、注意すべき文字コードの問題について解説します。

データベースのエクスポートとインポート手順

データベース移行の基本は、「エクスポート→転送→インポート」という3段階のプロセスです。
まずは移行元サーバーで、SSH経由でmysqldumpコマンドを実行し、データベースの内容をSQLファイルとして書き出します。

mysqldump -u root -p wordpress_db > wordpress_db.sql

このコマンドを実行すると、データベース内のテーブル構造とデータがすべて1つのSQLファイルにまとめられます。
次に、生成したファイルを移行先サーバーへ転送します。

scp wordpress_db.sql user@example.com:/home/user/

最後に、移行先サーバーで空のデータベースを作成したうえで、SQLファイルをインポートします。

mysql -u root -p wordpress_db_new < wordpress_db.sql

一連の流れをまとめると、以下のようになります。

移行元でmysqldumpによりSQLファイルを生成
scpまたはrsyncでファイルを転送
移行先で空のデータベースを作成
mysqlコマンドでインポートを実行

なお、大規模なデータベースの場合、エクスポート・インポートどちらの処理にも時間がかかります。
作業前にサイトをメンテナンスモードにしておくと、データの不整合を防げるため安心です。

文字コード(charset)の不一致を防ぐ設定

データベース移行で最も見落とされやすいのが、文字コードの不一致です。
移行元と移行先で文字コード設定が異なると、日本語の記事タイトルや本文が文字化けする、いわゆる「豆腐文字」が発生することがあります。

特に注意すべきは、utf8とutf8mb4の違いです。
絵文字や一部の特殊文字を扱う場合、4バイト対応のutf8mb4でなければ正しく保存できません。
移行元のデータベースがどちらの設定かを、事前に確認しておきましょう。

確認項目	確認方法	注意点
データベースの文字コード	`SHOW VARIABLES LIKE 'character_set_database';`	utf8mb4推奨
テーブルの照合順序	`SHOW TABLE STATUS;`	Collationの統一が必要
接続時の文字コード	`mysqldump`実行時のオプション	明示的に指定するのが安全

文字コードのずれを防ぐには、mysqldump実行時に明示的にcharsetを指定する方法が有効です。

mysqldump -u root -p --default-character-set=utf8mb4 wordpress_db > wordpress_db.sql

このように、エクスポートの段階で文字コードを固定しておくことで、インポート後の文字化けリスクを大幅に減らせます。
データベース移行は目に見えない部分だからこそ、こうした細かな設定への注意が、移行の成否を分けると言っても過言ではありません。

パーミッションエラーを未然に防ぐ権限設定ガイド

サーバー移行の作業でもっとも頻繁に発生するトラブルの一つが、パーミッションエラーです。
「画像がアップロードできない」「管理画面から更新できない」といった症状の多くは、この権限設定に起因しています。
ここでは、WordPressにおける適切なパーミッション値と、その設定方法について解説します。

ディレクトリとファイルの適切なパーミッション値

パーミッションとは、ファイルやディレクトリに対する読み取り・書き込み・実行の権限を数値で表したものです。
WordPressの場合、セキュリティと機能性のバランスを考慮した推奨値がある程度確立されています。

対象	推奨パーミッション	意味
ディレクトリ全般	755	所有者は読み書き実行可、他は読み取り実行のみ
ファイル全般	644	所有者は読み書き可、他は読み取りのみ
wp-config.php	600または640	所有者以外のアクセスを制限

なぜディレクトリは755で、ファイルは644なのでしょうか。
これは、ディレクトリには「実行権限」がないと中に入れないという、Unix系OSの仕様に起因します。
一方、通常のファイルには実行権限は不要なため、644という値が標準となっています。

ただし、wp-config.phpのようにデータベースの接続情報を含む機密ファイルは、より厳格な権限を設定すべきです。
所有者以外が読み取れないよう、600や640に制限しておくと安心でしょう。

移行作業の中でパーミッションが崩れる主な原因は、以下のようなケースです。

FTPクライアントの設定で、転送時に権限情報がリセットされる
アーカイブの展開時に、デフォルトの権限が適用される
異なるユーザー・グループでファイルが作成される

chown・chmodコマンドの正しい使い方

権限が崩れてしまった場合、修正にはchmodコマンドを使用します。
ディレクトリとファイルで異なる値を一括適用したい場合は、findコマンドと組み合わせるのが定石です。

find /var/www/html/wordpress/ -type d -exec chmod 755 {} \;
find /var/www/html/wordpress/ -type f -exec chmod 644 {} \;

-type dはディレクトリのみ、-type fはファイルのみを対象とするオプションです。
これにより、ディレクトリとファイルそれぞれに正しい権限値を一括で適用できます。

また、パーミッションだけでなく、ファイルの所有者(オーナー)とグループが正しく設定されているかも確認が必要です。
所有者情報がずれていると、Webサーバーのプロセス(多くの場合www-dataなど)がファイルにアクセスできず、エラーの原因になります。

chown -R www-data:www-data /var/www/html/wordpress/

-Rオプションを付けることで、指定したディレクトリ以下すべてのファイル・サブディレクトリに再帰的に所有者情報を適用できます。
ただし、この操作はシステム全体に影響を及ぼす可能性があるため、対象パスを必ず確認したうえで実行してください。

権限設定は地味な作業に見えますが、WordPressが正常に動作するための土台とも言える部分です。
焦らず一つひとつ確認しながら進めることをおすすめします。

移行後に起こりがちなリンク切れの原因と対処法

ファイルとデータベースの移行が完了しても、それだけでサイトが正常に表示されるとは限りません。
多くの場合、移行後に「画像が表示されない」「内部リンクをクリックすると404になる」といった症状に直面します。
この原因の大半は、URL情報の不整合にあります。

絶対URLと相対URLの違いによる影響

WordPressは、投稿本文やウィジェットの設定内で、画像やリンクのURLを絶対URLとして保存する仕様になっています。
絶対URLとは、https://old-domain.com/wp-content/uploads/image.jpgのように、ドメイン名を含んだ完全なURLのことです。

これに対して、/wp-content/uploads/image.jpgのようにドメイン名を含まない記述を相対URLと呼びます。
相対URLであれば、ドメインが変わってもリンク切れは発生しませんが、WordPressの標準仕様では絶対URLが多用されるため、ドメインやディレクトリ構成が変わる移行では注意が必要です。

絶対URLがそのまま残ってしまうと、次のような問題が起こります。

移行先の新しいドメインではなく、旧ドメインへのリンクが残る
アップロード画像が旧サーバー上の画像を参照し続ける
内部リンクのクリックで404エラーが発生する

サブディレクトリからサブドメインへ移行するケースや、ステージング環境から本番環境へ移行するケースでは、特にこの問題が顕著に現れます。

wp-config.phpとデータベース内URLの一括置換

URLの不整合を解消するには、大きく分けて2つの作業が必要です。
1つ目はwp-config.php内のサイトURL設定、2つ目はデータベース内に保存された投稿データのURLです。

まず、wp-config.phpや管理画面の設定から、siteurlとhomeが新しいドメインに正しく設定されているかを確認しましょう。
設定ファイルの修正自体は単純ですが、データベース内に散らばった数百、数千件のURLを手作業で置換するのは現実的ではありません。

そこで有効なのが、WP-CLIのsearch-replaceコマンドです。
SSH経由でWP-CLIが使える環境であれば、以下のように一括置換が可能です。

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

--all-tablesオプションを付けることで、投稿本文だけでなく、ウィジェットやプラグイン設定など、データベース内のすべてのテーブルを対象に置換処理が行われます。
実行前に--dry-runオプションを付けて、置換される件数を事前に確認しておくと安全です。

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --dry-run

WP-CLIが利用できない環境の場合は、mysqlコマンドから直接UPDATE文を実行する方法もありますが、シリアライズされたデータ(配列やオブジェクトが文字列化された形式)を含むレコードは、単純な文字列置換では破損してしまう危険があります。
そのため、シリアライズ構造を正しく処理できるWP-CLIやプラグインを利用するほうが、確実性の高い方法と言えるでしょう。
URLの置換は地味な作業に見えて、サイトの表示品質を左右する重要な工程です。

移行完了後に必ず実施すべき動作確認とテスト項目

ファイル・データベース・URLの移行がすべて完了したら、最後に欠かせないのが動作確認です。
「移行作業が終わった」と「サイトが正常に動いている」は、必ずしもイコールではありません。
ここでは、公開前に必ずチェックしておくべき2つの観点を紹介します。

表示崩れ・404エラーのチェック方法

まず確認すべきは、サイトの見た目と内部リンクの整合性です。
トップページだけでなく、投稿一覧、個別記事、固定ページ、カテゴリーページなど、代表的なページタイプを一通り巡回して確認しましょう。

目視での確認に加えて、コマンドラインからHTTPステータスコードを確認する方法も有効です。

curl -I https://new-domain.com/

このコマンドを実行すると、レスポンスヘッダーが表示され、ステータスコードが200 OKであるかを確認できます。
もし404や500が返ってくる場合は、パーミッションやURL設定に問題が残っている可能性が高いでしょう。

サイト全体のリンク切れを網羅的にチェックしたい場合は、以下のような観点を押さえておくと漏れが少なくなります。

画像・CSS・JavaScriptなど静的ファイルが正しく読み込まれているか
メニューやウィジェット内のリンク先が新ドメインを指しているか
お問い合わせフォームなど、動的な機能が正常に動作するか
検索機能やページネーションが正しく動作するか

特に画像の読み込みエラーは、ブラウザの開発者ツール(コンソールタブやネットワークタブ)を開くことで、どのリソースが読み込めていないかを具体的に特定できます。

SSL証明書とhttps化の確認

移行先サーバーでSSL証明書が正しく設定されているかどうかも、忘れずに確認すべき項目です。
証明書が正しく機能していないと、ブラウザに警告が表示され、訪問者の離脱につながりかねません。

証明書の有効期限や発行元は、以下のコマンドで確認できます。

openssl s_client -connect new-domain.com:443 -servername new-domain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

このコマンドを実行すると、証明書の有効期間(notBeforeとnotAfter)が表示され、期限切れや設定ミスがないかを確認できます。

あわせて確認しておきたいポイントを、以下にまとめます。

確認項目	内容	想定されるトラブル
証明書の有効期限	期限切れになっていないか	警告画面の表示
httpからhttpsへのリダイレクト	常時SSL化されているか	混合コンテンツエラー
混合コンテンツ	http経由のリソース読み込みがないか	鍵アイコンが表示されない

特に見落とされやすいのが、混合コンテンツ(Mixed Content)の問題です。
ページ自体はhttpsで配信されていても、画像やスクリプトの一部がhttpで読み込まれていると、ブラウザによっては警告が表示されます。
前章で紹介したURL一括置換の際に、http表記が残っていないかも合わせて確認しておくと安心です。
動作確認は地道な作業ですが、公開後のトラブルを未然に防ぐ、最後の砦と言える工程です。

SSH移行のトラブルシューティングと注意点

ここまで解説してきた手順を踏んでいても、実際の移行作業では予期しないトラブルに遭遇することがあります。
ここでは、SSH移行で特に発生しやすい2つの問題と、その対処法について解説します。
事前に対応策を頭に入れておくことで、いざというときに冷静に対処できるはずです。

接続タイムアウトへの対処

大容量のファイルを転送している最中に、SSH接続がタイムアウトしてしまうケースは珍しくありません。
原因の多くは、通信の無通信状態が一定時間続くことで、サーバー側またはクライアント側の設定によって接続が自動的に切断されることにあります。

この問題を防ぐには、SSHのクライアント設定ファイルに、接続を維持するためのオプションを追加しておくのが効果的です。

Host example
    HostName example.com
    User user
    ServerAliveInterval 60
    ServerAliveCountNum 3

~/.ssh/configに上記のような設定を追記しておくと、60秒ごとにサーバーへ生存確認のパケットが送信され、無通信による切断を防止できます。

また、rsyncを使った転送であれば、接続が切れても差分転送の仕組みにより、再実行時には転送済みの部分をスキップできます。
長時間かかる転送作業では、以下のようにnohupやターミナルの多重化ツールと組み合わせて、接続断の影響を受けにくくする工夫も有効です。

screenやtmuxを使い、セッションを維持したままバックグラウンドで実行する
nohupコマンドで、ターミナルが閉じてもプロセスを継続させる
転送するファイルを分割し、一度あたりの処理時間を短縮する

特に低速な回線や不安定なネットワーク環境で作業する場合は、これらの対策を組み合わせておくと、作業効率が大きく向上します。

バックアップからのロールバック手順

どれだけ慎重に作業を進めても、移行後に致命的な不具合が発覚する可能性はゼロではありません。
そうした事態に備え、移行作業を始める前に、必ず移行元サーバーの状態を丸ごとバックアップしておくことが鉄則です。

ファイルとデータベース、それぞれのバックアップを取得しておきましょう。

tar czf backup_before_migration.tar.gz /var/www/html/wordpress/
mysqldump -u root -p wordpress_db > backup_before_migration.sql

万が一、移行先で復旧困難な問題が発生した場合、これらのバックアップを使って迅速に元の状態へ戻せます。
ロールバックの手順は、基本的にはこれまで解説してきた移行手順の逆を行う形になります。

状況	対応内容	優先度
移行先サイトに致命的なエラーが出ている	DNS設定を旧サーバーに戻す	最優先
データベースに不整合がある	バックアップしたSQLファイルで復元	高
ファイルの一部が破損している	バックアップアーカイブから復元	高

DNSの向き先を変更している場合、切り戻し作業と並行して、DNSの伝播にも時間がかかる点を考慮しておく必要があります。
移行作業は、うまくいくことを前提にするのではなく、失敗したときにどう戻すかまで設計しておくことが、プロフェッショナルな進め方と言えるでしょう。

まとめ:SSHを使った安全なWordPress移行のポイント

ここまで、SSHを活用したWordPressサーバー移行の具体的な手順について、事前準備からトラブルシューティングまで一通り解説してきました。
最後に、記事全体の要点を整理しておきましょう。

SSHによる移行が優れている最大の理由は、処理の透明性と再現性にあります。
GUIツールに頼らず、コマンド一つひとつを明示的に実行することで、何が起きているかを常に把握しながら作業を進められます。
これは、FTPのような従来の移行手段にはない大きなメリットです。

移行作業全体を振り返ると、押さえるべきポイントは以下のように整理できます。

移行前に、PHP・MySQLのバージョンやSSH接続情報など、サーバー環境を入念に確認する
rsyncやscpを使い分け、ファイル構成やデータ量に応じた効率的な転送方法を選択する
mysqldumpによるデータベース移行時は、文字コードの不一致に注意する
パーミッションは755(ディレクトリ)と644(ファイル)を基準に、chmod・chownで正しく設定する
WP-CLIのsearch-replaceコマンドで、データベース内のURLを漏れなく一括置換する
移行後は表示崩れ・404エラー・SSL証明書の状態を必ず確認する
万が一に備え、作業前には必ずファイルとデータベースのバックアップを取得しておく

これらの工程を一つずつ丁寧に実行できれば、パーミッションエラーやリンク切れといった、移行作業でよくあるトラブルの大半は未然に防げるはずです。
逆に言えば、こうしたトラブルの多くは「準備不足」と「確認不足」から生じているとも言えます。

最後に、移行作業全体を通してのチェックリストを、簡潔にまとめておきます。

フェーズ	主な確認・作業内容
事前準備	SSH接続情報、環境バージョン、バックアップ取得
ファイル移行	rsync・scpによる転送、パーミッション維持
データベース移行	mysqldumpによるエクスポート・インポート、文字コード確認
URL・リンク修正	search-replaceによる一括置換
移行後の確認	表示崩れ・404エラー・SSL証明書のチェック