WordPress FTPデプロイの完全手順｜ローカルから本番公開まで一気通貫

WordPressのFTPデプロイ — なぜ手順を間違えると公開後にサイトが壊れるのか

WordPressサイトを本番公開した直後に、画面が真っ白になる。リンクをクリックしても404エラーが返ってくる。トップページには表示されていた画像が、内部ページでは軒並み消えている。こうした事態は、FTPデプロイの手順を誤ると実際に起きます。

問題の原因は、大きく3つに集約されます。

よくある失敗パターンと原因の一覧

• 白画面（WSoD）：wp-config.phpのDB接続情報をローカル環境のまま転送してしまい、本番DBに接続できない状態で発生します。
• リンク切れ・URLの不一致：WordPressの管理画面で設定する「サイトURL」と「WordPressアドレス」が本番ドメインに書き換わっていないと、内部リンクがローカルのURLを参照し続けます。
• 画像・メディアの消失：wp-content/uploadsフォルダの転送漏れ、またはパーミッション設定が正しくなく書き込み権限がない場合に起きます。
• プラグイン・テーマの動作不良：ファイル転送順序が乱れた状態でDBをインポートすると、DBが参照するファイルパスと実ファイルの場所が一致しなくなります。

いずれも「なんとなく転送した」「手順を省略した」という判断が引き金になっています。対処に追われると、公開作業の時間が数時間単位で延びるケースも少なくありません。

この記事でカバーする手順の全体像

本記事では、ローカル環境で制作したWordPressサイトをFTPで本番サーバーへ公開するまでの手順を、順を追って解説します。具体的には、サーバー・DB・PHPのバージョン整合性の確認から始まり、転送すべきファイルの選定、DBのエクスポート・インポート、FTP転送時の設定最適化、パーミッション設定、公開後の動作検証まで、一連の工程を網羅しています。

各工程で「なぜその操作が必要か」を明示しながら進めますので、手順を丸暗記するのではなく、判断の根拠を持ちながら作業を進められるようになります。

WordPressのFTPデプロイ — なぜ手順を間違えると公開後にサイトが壊れるのか

WordPressをローカルで制作し、FTPで本番サーバーへ転送した直後に「画面が真っ白になった」「画像がすべて消えた」「管理画面にログインできない」といった事態が発生するケースは少なくありません。こうした問題の多くは、転送操作そのものではなく、デプロイ前後の手順の抜け漏れに起因しています。

本記事では、FTPデプロイで起きやすい失敗パターンとその原因を整理したうえで、環境確認・ファイル構成の把握・DB移行・転送設定・パーミッション設定・公開後の動作確認まで、一連の手順を順番に解説します。

よくある失敗パターンと原因の一覧

公開後のトラブルは、次の3つの原因に集中しています。

• ファイル転送の順序ミス・転送漏れ：テーマファイルやプラグインの一部だけ転送した状態で動作確認を行い、依存ファイルが見つからずエラーが発生するケースです。特に子テーマを使っている場合、親テーマの転送漏れが白画面の直接原因になります。
• wp-config.phpのDB接続情報の書き換え漏れ：ローカル環境のデータベース名・ユーザー名・パスワード・ホスト名をそのま本番に転送すると、DBへの接続に失敗してサイト全体が表示されなくなります。
• パーミッション（ファイル権限）の設定ミス：FTP転送後にディレクトリやファイルの権限が適切でないと、画像のアップロード失敗・プラグインのインストールエラー・キャッシュ書き込み不能といった問題が連鎖します。

この記事でカバーする手順の全体像

上記の原因を踏まえ、本記事は以下の流れでデプロイ手順を解説します。

1. デプロイ前の環境要件の確認（サーバー・DB・PHPバージョンの整合性）
2. WordPressファイルの構成把握と、転送すべきファイル・除外すべきファイルの仕分け
3. データベースのエクスポートから本番へのインポートまで
4. FTPによるファイル転送の具体的な手順と転送設定の最適化
5. 転送後に確認すべきパーミッション設定
6. 公開後のテーマ・プラグイン・フォームの動作確認チェックリスト

各ステップは独立して参照できるよう構成していますが、手順の順序それ自体がトラブル防止の鍵になるため、初回は通しで確認することをお勧めします。

デプロイ前に確認すべき環境要件 — サーバー・DB・PHPバージョンの整合性

WordPressを本番環境へアップロードする前に、ローカル環境と本番サーバーの環境要件が一致しているかを確認しておく必要があります。この確認を省略すると、ファイル転送後にサイトが正常に動作しないケースが少なくありません。

PHPバージョン・MySQLバージョンの確認方法

まずローカル環境のバージョンを把握します。Local（旧Local by Flywheel）やMAMPを使用している場合、ツールの管理画面からPHPバージョンとMySQLバージョンを確認できます。

本番サーバー側は、各レンタルサーバーのコントロールパネルから確認します。代表的な確認箇所は以下のとおりです。

• エックスサーバー：サーバーパネル →「PHP Ver.切替」でPHPバージョンを確認・変更できます。MySQLバージョンはサーバーパネルの「MySQL設定」から確認します。
• ConoHa WING：コントロールパネル →「サイト管理」→「サイト設定」→「PHP設定」でバージョンを切り替えられます。

確認後、ローカルと本番のバージョンが異なる場合は、本番サーバー側を合わせるか、ローカル環境を更新して統一しておくことが推奨されます。

ローカルと本番のバージョン差異が引き起こす不具合例

バージョンの不一致は、WordPressの本番環境アップロード後にさまざまな不具合を引き起こします。

• Fatal error（致命的エラー）の発生：PHP 8.x系で動作を前提としたコードが、PHP 7.x系の本番環境では構文エラーを起こすケースがあります。
• プラグインの動作不全：特定のプラグインがPHPの最低バージョン要件を満たさない環境では、有効化できないか、機能が部分的に動作しないことがあります。
• データベース接続エラー：MySQLのバージョン差異により、ローカルで作成したDBのSQL構文が本番で解釈されないケースがあります。

FTPクライアントのインストールと接続設定（FileZilla / Cyberduckなど）

環境要件の確認が完了したら、FTPクライアントの準備に移ります。WordPressファイルの転送には、FileZillaまたはCyberduckが広く使われています。

FileZillaはWindows・Mac双方に対応し、接続情報（ホスト名・ユーザー名・パスワード・ポート番号）をサイトマネージャーに登録しておくことで、毎回の入力を省略できます。接続方式はセキュリティの観点からFTPSまたはSFTPが推奨されます。本番サーバーのFTP接続情報は、各サーバーのコントロールパネルまたは契約時のメールに記載されています。

デプロイ前に確認すべき環境要件 — サーバー・DB・PHPバージョンの整合性

WordPressを本番環境へアップロードする前に、ローカルと本番サーバーの環境差異を確認しておくことが不可欠です。この確認を省略すると、転送後に画面が真っ白になったり、プラグインが正常に動作しないトラブルが発生するケースが少なくありません。

PHPバージョン・MySQLバージョンの確認方法

まず、ローカル環境のPHPバージョンを確認します。MAMPやLocalなどのツールを使っている場合は、各ツールの管理画面から現在のPHPバージョンを確認できます。次に、本番サーバー側のバージョンを確認します。

代表的なレンタルサーバーでの確認箇所は以下のとおりです。

• エックスサーバー：サーバーパネルにログイン →「PHP Ver.切替」からバージョンを確認・変更できます
• ConoHa WING：コントロールパネルの「サイト管理」→「サイト設定」→「PHPバージョン」から確認・切替が可能です

MySQLのバージョンは、各サーバーの仕様ページまたはphpMyAdminのトップ画面に表示されています。ローカルと本番で使用しているバージョンをメモしてから、次のステップに進むことを推奨します。

ローカルと本番のバージョン差異が引き起こす不具合例

PHPやMySQLのバージョンが一致していない場合、以下のような不具合が発生することがあります。

• 本番サーバーのPHPバージョンが古い場合、WordPress本体やプラグインが要求するバージョンを満たせず、Fatal errorが発生して画面が表示されなくなる
• フォームプラグインや決済系プラグインが、PHPの特定関数に依存している場合、バージョン違いで動作が停止するケースがある
• MySQLのバージョン差異により、データベースのSQL構文が非互換となり、投稿データの読み込みエラーが起きる場合がある

WordPress 本番環境へのアップロード前に、PHPは8.1以上、MySQLは8.0以上（またはMariaDB 10.4以上）を目安にローカルと本番を揃えておくと、環境差異に起因するトラブルを大幅に減らせます。

FTPクライアントのインストールと接続設定（FileZilla / Cyberduckなど）

環境要件の確認が終わったら、FTP接続の準備に入ります。代表的なFTPクライアントとして、FileZilla（Windows・Mac対応）やCyberduck（Mac・Windows対応）が広く使われています。

接続に必要な情報は、サーバー管理画面または契約時のメールに記載されている以下の4項目です。

• FTPホスト名（サーバーアドレス）
• FTPユーザー名
• FTPパスワード
• ポート番号（通常は21、SFTP使用時は22）

セキュリティの観点から、通常のFTPではなくSFTP（SSH File Transfer Protocol）での接続を推奨します。エックスサーバー・ConoHa WINGともにSFTP接続に対応しており、設定方法は各サーバーの公式ドキュメントに記載されています。

WordPressファイルの構成を把握する — 転送すべきファイルと除外すべきファイル

FTPでWordPressファイルを転送する前に、どのファイルを送るべきか・送ってはいけないかを整理しておく必要があります。ファイル構成を理解せずに転送すると、本番環境の設定を上書きしたり、不要なファイルがサーバーに混入したりするリスクがあります。

wp-contentディレクトリ — テーマ・プラグイン・メディアファイルの構成

転送の中心となるのが wp-content ディレクトリです。以下の3つのサブディレクトリが含まれます。

• themes：使用中のWordPressテーマファイル一式。カスタマイズしたCSSやPHPテンプレートが含まれるため、転送漏れが起きやすい場所です。子テーマを使っている場合は、子テーマのディレクトリも必ず含めてください。
• plugins：インストール済みプラグインのファイル群。ローカルで有効化していたプラグインがすべて含まれます。
• uploads：メディアライブラリにアップロードした画像・PDF・動画などの実ファイル。年月別のサブディレクトリ構造になっているため、階層ごと転送します。

特に注意が必要なのが テーマのカスタマイズファイルの転送漏れ です。WordPressテーマには、functions.phpやpage-xxx.phpといったページ固有のテンプレートファイルが含まれます。これらは親テーマのファイルと混在していることが多く、カスタマイズ済みファイルだけを選別して転送しようとすると、漏れが発生しやすくなります。wp-content/themesディレクトリごと丸ごと転送し、本番側で差分が生じないようにするのが確実な方法です。

wp-config.phpの本番用書き換え箇所一覧

wp-config.php はWordPressの動作に関わる最も重要な設定ファイルです。ローカル環境の値をそのまま転送すると、本番DBへの接続が失敗し、サイト全体が表示不能になります。転送前に以下の箇所を本番用の値に書き換えてください。

• DB_NAME：本番サーバーのデータベース名
• DB_USER：本番DBのユーザー名
• DB_PASSWORD：本番DBのパスワード
• DB_HOST：本番DBのホスト名（多くのレンタルサーバーでは「localhost」だが、クラウドDBの場合は別途確認が必要）
• WP_DEBUG：本番環境では必ず false に設定。ローカルでデバッグ用に true にしている場合、エラーログが外部に公開されるリスクがあります。

wp-config.phpは転送前に編集を完了しておくことを強く推奨します。転送後に直接サーバー上で編集する方法もありますが、FTPクライアントを通じた直接編集は文字化けや保存ミスを招くケースがあるため避けるのが賢明です。

転送除外すべきファイル・ディレクトリのチェックリスト

以下のファイル・ディレクトリは、転送しても本番環境では不要、あるいは有害になるケースがあります。FTPクライアントの除外設定や転送前の確認リストに組み込んでおくことをお勧めします。

• node_modules：npmで管理するJavaScriptライブラリ群。容量が膨大な上、本番での実行は不要です。
• .git：Gitのバージョン管理情報。公開サーバーに上がるとソースコード履歴が外部からアクセスできる状態になり、セキュリティリスクになります。
• .DS_Store：macOSが自動生成するフォルダ情報ファイル。本番環境での意味はなく、不要なファイルとして残ります。
• wp-config.php（ローカル版）：前述の通り、本番用に書き換えた版のみを転送します。ローカル用の設定ファイルを誤って上書きしないよう注意してください。
• wp-content/debug.log：WP_DEBUGが有効な環境で生成されるログファイル。本番に転送する意味はなく、残留するとサイト情報が漏洩するリスクがあります。

WordPressファイルの構成を把握する — 転送すべきファイルと除外すべきファイル

FTPでWordPressをデプロイする際に起こりがちなミスの多くは、「何を転送すべきか」の理解が曖昧なことに起因しています。転送すべきファイルと除外すべきファイルを事前に整理しておくことが、安全なデプロイの前提条件です。

wp-contentディレクトリ — テーマ・プラグイン・メディアファイルの構成

WordPressのファイル構成の中で、制作物として最も重要なのがwp-contentディレクトリです。このディレクトリには以下の3つが格納されています。

• themes：使用中のWordPressテーマ一式。カスタマイズしたCSSやPHPテンプレートファイルを含む
• plugins：導入済みプラグインのファイル群
• uploads：メディアライブラリに登録された画像・PDF等のファイル

特に注意が必要なのはthemesディレクトリ内のカスタマイズファイルの転送漏れです。親テーマに対して子テーマでスタイルを上書きしている場合、子テーマのディレクトリごと転送しなければ、本番環境ではデザインが崩れます。テンプレートファイルを個別に編集しているケースでも、変更したファイルだけを抜き出して転送する運用では漏れが起きやすいため、wp-content/themesディレクトリは丸ごと転送することを推奨します。

また、wp-coreのコアファイル群（wp-admin、wp-includes）も転送対象です。ローカルと本番のWordPressバージョンを揃えている場合でも、テーマやプラグインとの整合性を保つために上書き転送します。

wp-config.phpの本番用書き換え箇所一覧

wp-config.phpは転送前に必ず本番環境用の設定に書き換えてください。ローカル環境の設定値のまま本番サーバーへ転送すると、データベース接続エラーでサイトが表示されません。書き換えが必要な主な箇所は以下のとおりです。

• DB_NAME：本番サーバーで作成したデータベース名
• DB_USER：本番DBのユーザー名
• DB_PASSWORD：本番DBのパスワード
• DB_HOST：本番サーバーのDBホスト名（多くの場合「localhost」だが、サーバー会社により異なる）
• WP_DEBUG：本番環境ではfalseに設定し、エラー情報を非表示にする

また、.htaccessもWordPressのパーマリンク設定を機能させるために必要なファイルです。ローカル環境で生成されたものをそのまま転送し、本番環境のパーマリンク設定画面で「変更を保存」を実行して再生成するのが安全です。

転送除外すべきファイル・ディレクトリのチェックリスト

以下のファイル・ディレクトリは転送しないようにしてください。本番環境に混入すると、セキュリティリスクや動作不具合の原因になります。

• node_modules：npm等で生成される依存パッケージ群。容量が膨大なうえ、本番環境では不要
• .git：Gitのバージョン管理情報。外部から参照されると、ソースコードが流出するリスクがある
• .DS_Store：macOSが自動生成するメタデータファイル。不要なうえ、ディレクトリ構造の情報を含む
• wp-config-local.php：ローカル環境専用の設定ファイルを別途管理している場合は除外する
• .env：環境変数ファイル。APIキー等の機密情報が含まれるため、本番サーバーへの転送は厳禁

FTPクライアントによっては、隠しファイル（ドットから始まるファイル）が初期設定で非表示になっているケースがあります。転送前に隠しファイルの表示設定を有効にし、除外すべきファイルが含まれていないかを必ず確認してください。

データベース（DB）の移行手順 — エクスポートから本番インポートまで

ファイル転送と並んで、DBの移行はWordPress本番公開において最も失敗しやすい工程です。手順を一つでも省略すると、サイト内のリンクが機能しなくなったり、画像が表示されなくなったりと、公開後のトラブルに直結します。

phpMyAdminでのDBエクスポート手順

ローカル環境のDBは、phpMyAdminを使ってエクスポートします。手順は以下の通りです。

1. ローカル環境のphpMyAdmin（例：http://localhost/phpmyadmin）にアクセスする
2. 対象のデータベースを左側のツリーから選択する
3. 上部メニューの「エクスポート」をクリックする
4. エクスポート方式は「詳細」を選択し、形式はSQLのままにする
5. 「生成オプション」内の「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER コマンドを追加する」にチェックを入れる
6. 「実行」をクリックして .sql ファイルをダウンロードする

WP-CLIが使える環境であれば、wp db export backup.sql のコマンド一行でも同等のエクスポートが可能です。GUIを介さない分、自動化や再現性の面で優れています。

本番DBへのインポートとユーザー権限の確認

本番サーバーのコントロールパネル（cPanelやさくらのコントロールパネルなど）からphpMyAdminを開き、あらかじめ作成しておいた本番用DBを選択します。「インポート」タブからエクスポートした .sql ファイルをアップロードして実行してください。

インポート後に必ず確認すべきポイントが、DBユーザーへの権限付与です。wp-config.php に記載したDBユーザーが、対象のDBに対して「すべての権限」を持っていない場合、WordPressは正常に起動しません。コントロールパネルの「データベースユーザーの追加」メニューから権限を明示的に付与してください。

siteurl・homeのURL書き換え — Search Replace DBの使い方

DBのインポートが完了した時点では、テーブル内のURLはすべてローカル環境のもの（例：http://localhost/mysite）になっています。この状態で公開しても、内部リンクや画像のパスがローカルを参照し続けるため、本番環境では正しく機能しません。

この問題を解消するために使うのが、Search Replace DB（interconnect/it製）です。手順は以下の通りです。

1. Search Replace DBのPHPファイルをダウンロードし、本番サーバーの任意のディレクトリへFTPでアップロードする
2. ブラウザからそのファイルにアクセスし、DB接続情報を入力する
3. 「Replace」欄にローカルURL（例：http://localhost/mysite）、「With」欄に本番URL（例：https://example.com）を入力する
4. 「Live Run」を実行し、wp_options テーブルの siteurl・home を含む全テーブルのURLが一括置換されたことを確認する
5. 作業完了後、セキュリティ上の理由からアップロードしたPHPファイルを必ず削除する

WP-CLIが使える場合は、wp search-replace ‘http://localhost/mysite’ ‘https://example.com’ でも同じ処理が行えます。いずれの方法でも、この置換工程を省略することは公開後のサイト破損に直結するため、必須の手順として位置づけてください。

データベース（DB）の移行手順 — エクスポートから本番インポートまで

ファイル転送と並んで、DBの移行はWordPress本番公開における最重要工程のひとつです。この手順を誤ると、サイトURL・画像・内部リンクがすべて壊れる可能性があります。順を追って確認していきましょう。

phpMyAdminでのDBエクスポート手順

ローカル環境のphpMyAdminにアクセスし、対象のデータベースを選択します。画面上部の「エクスポート」タブをクリックし、以下の設定で出力してください。

• エクスポート方式：詳細を選択
• 形式：SQL
• 「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER コマンドを追加する」にチェック
• 文字セット：utf8mb4を確認

設定が完了したら「実行」をクリックし、.sqlファイルをローカルに保存します。WP-CLIを使う場合は wp db export backup.sql コマンド一行で同等のエクスポートが可能です。

本番DBへのインポートとユーザー権限の確認

本番サーバーのコントロールパネル（cPanelなど）からphpMyAdminを開き、あらかじめ作成しておいた本番用データベースを選択します。「インポート」タブから先ほどの.sqlファイルを指定し、実行します。

インポート後は必ずDBユーザーに対してすべての権限が付与されているかを確認してください。権限が不足していると、WordPressがDBに接続できず「データベース接続確立エラー」が表示されます。wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTが本番環境の値と一致していることも合わせて確認します。

siteurl・homeのURL書き換え — Search Replace DBの使い方

DBのインポートが完了しても、そのままではsiteurl・homeがローカルのURLのまま記録されています。この状態で公開すると、内部リンク・画像パス・テーマのリソースURLがすべてローカルを参照してしまい、フロントエンドが正常に表示されません。

URL一括置換にはSearch Replace DB（interconnect/it製）の利用が一般的です。手順は以下のとおりです。

1. Search Replace DBのファイルを本番サーバーの任意のディレクトリにアップロードする
2. ブラウザでそのURLにアクセスし、ツールの管理画面を開く
3. 「replace」欄にローカルURL（例：http://localhost/mysite）、「with」欄に本番URL（例：https://example.com）を入力する
4. 対象DBの接続情報を入力し、「Dry Run」で置換対象件数を確認してから「Do Search Replace」を実行する
5. 完了後、必ずSearch Replace DBのファイルをサーバーから削除する（セキュリティリスクになるため）

この工程を省略すると、管理画面へのログインURL・メディアライブラリの画像・パーマリンクがすべてローカル環境を指したままになります。見た目上は公開できていても、実態は壊れたサイトが本番に存在している状態です。DB移行においてURL書き換えは省略できない必須工程として位置づけてください。

FTPでWordPressファイルを本番サーバーへ転送する — 手順と転送設定の最適化

ファイル転送のステップは、接続設定の確認・転送先ディレクトリの特定・ファイルのアップロードという3段階に整理できます。各ステップで設定を誤ると、転送完了後にサイトが正常に表示されないケースが少なくありません。以下では、FileZillaを例に、実務で押さえておくべきポイントを順に解説します。

FTPクライアントの接続設定と疎通確認

FileZillaを起動し、メニューの「ファイル」→「サイトマネージャー」から新規サイトを登録します。入力が必要な項目は次のとおりです。

• ホスト：サーバーのIPアドレスまたはFTPホスト名（例：ftp.example.com）
• ポート：通常FTPは21番、SFTP（SSH File Transfer Protocol）を使う場合は22番
• プロトコル：セキュリティ面から、可能であればSFTPを選択する
• ユーザー名・パスワード：サーバーのコントロールパネルで発行されたFTPアカウント情報を入力する

設定後、「接続」ボタンを押してサーバー側のディレクトリ一覧が表示されれば疎通確認は完了です。接続できない場合は、ファイアウォールの設定やポート番号の誤りを最初に疑ってください。

転送先ディレクトリの確認 — ドキュメントルートを間違えないために

接続後に最初に確認すべきは、ドキュメントルートの場所です。多くのレンタルサーバーでは public_html または htdocs がWebの公開ディレクトリになっています。サーバーによっては www というディレクトリ名を使う場合もあるため、ホスティング事業者のドキュメントで必ず確認してください。

WordPressをドメインのルートに公開する場合は、public_html/ の直下にファイルを配置します。サブディレクトリ（例：public_html/blog/）への配置を予定している場合は、あらかじめそのディレクトリを作成しておくと転送時のミスを防げます。

ファイル転送の順序と上書き設定の選択基準

転送するファイルは、大きく「コアファイル」「テーマ」「プラグイン」「wp-config.php」に分類できます。新規デプロイの場合は一括転送で問題ありませんが、既存サイトへの上書き更新時は順序と上書き設定に注意が必要です。

1. wp-content/themes/：カスタムテーマのみを転送し、不要なテーマは上書きしない
2. wp-content/plugins/：追加・更新対象のプラグインだけを転送する
3. wp-config.php：本番環境の設定（DB接続情報など）を上書きしないよう、転送対象から除外する

FileZillaの上書き設定は「転送」→「ファイルが既に存在する場合の動作」から変更できます。既存サイトへの部分更新では「サイズや更新日時が異なる場合のみ上書き」を選択すると、意図しないファイルの置き換えを防げます。

大量ファイル転送時のタイムアウト・エラー対策

WordPressのコアファイルとプラグインを含めると、転送対象が数千ファイルに達するケースは珍しくありません。この規模になると、タイムアウトや転送エラーが発生しやすくなります。実務上、有効な対策は次のとおりです。

• 同時接続数の制限：FileZillaの「編集」→「設定」→「転送」で、同時転送数を3〜5程度に下げる。デフォルトの最大値のままにすると、サーバー側でDoS判定されて接続が切られることがあります。
• タイムアウト時間の延長：「接続」→「タイムアウト」の設定値を120秒以上に変更する。大容量ファイルのアップロード中に接続が切れるトラブルを減らせます。
• 転送の分割：コアファイル・テーマ・プラグインをフォルダ単位で分けて順番に転送する。エラーが発生した際に、再転送の範囲を最小限に絞れます。
• 失敗キューの再転送：FileZillaは転送失敗したファイルを「失敗したファイル」タブに一覧表示します。転送完了後にこのタブを確認し、該当ファイルを右クリック→「再転送」で補完してください。

転送が完了したら、FileZillaのリモートディレクトリで主要ファイル（wp-login.php、wp-config.php、wp-content/ フォルダ）の存在をビジュアルで確認しておくと、パーミッション設定の前段階として抜け漏れを防ぎやすくなります。

FTPでWordPressファイルを本番サーバーへ転送する — 手順と転送設定の最適化

ファイルの転送操作そのものは難しくありませんが、設定の抜けや転送順序の誤りが原因でサイトが正常に表示されないケースは少なくありません。ここではFileZillaを例に、接続設定から実際のアップロードまでをステップ形式で整理します。

FTPクライアントの接続設定と疎通確認

FileZillaを起動したら、まずサイトマネージャー（編集→サイトマネージャー）で新規サイトを登録します。入力が必要な項目は以下のとおりです。

• ホスト：サーバー管理画面に記載されているFTPホスト名（例：ftp.example.com）
• ポート：通常のFTPは21番、SFTP（SSH File Transfer Protocol）を使う場合は22番
• プロトコル：セキュリティ要件がある場合はSFTPを選択する。共用サーバーでは明示的なFTP over TLS（FTPES）が使えるケースもあります
• ログオンタイプ：「通常」を選び、FTPアカウントのユーザー名とパスワードを入力

入力後は「接続」をクリックし、リモートサイトペインにサーバーのディレクトリ一覧が表示されれば疎通確認完了です。接続エラーが出る場合は、ファイアウォールによるポートブロックを疑い、サーバー側のFTP許可IPアドレス設定も確認してください。

転送先ディレクトリの確認 — ドキュメントルートを間違えないために

最も多いミスの一つが、転送先ディレクトリの選択誤りです。多くの共用サーバーではドキュメントルートが public_html または www ディレクトリになっていますが、マルチドメイン環境ではドメインごとにサブディレクトリが切られているケースがあります。

サーバー管理画面（cPanelやXserverのサーバーパネルなど）でドキュメントルートのパスを事前に確認し、FileZillaのリモートサイトペインで同じパスに移動してからアップロードを開始してください。WordPressのルートファイル（wp-login.phpやwp-config.phpなど）が public_html直下 に配置されているかどうかを目視で確認するひと手間が、後のトラブルを防ぎます。

ファイル転送の順序と上書き設定の選択基準

新規デプロイか既存サイトの更新かによって、推奨する転送順序が異なります。

1. 新規デプロイの場合：wp-config.phpは本番用の設定に書き換えたものをアップロードする。wp-content（テーマ・プラグイン・アップロードファイル）→ WordPressコアファイルの順で転送すると、コア起動前に必要なリソースが揃います
2. 既存サイトの更新の場合：wp-config.phpと.htaccessは原則として上書きしない。FileZillaの転送ダイアログで「より新しいファイルのみ上書き」を選択し、設定ファイルを誤って置き換えるリスクを最小化してください

大量ファイル転送時のタイムアウト・エラー対策

WordPressは標準的な構成でも数千ファイルに及ぶため、転送中にタイムアウトやCONNECTION_CLOSEDエラーが発生することがあります。以下の設定を事前に調整しておくと安定します。

• 同時接続数の制限：FileZillaの「編集→設定→転送」で同時転送数を3〜5に設定する。サーバー側の接続制限を超えると強制切断されるため、上限を抑えることで安定性が増します
• タイムアウト値の延長：「編集→設定→接続」でタイムアウトを120秒以上に設定する
• 転送の再開機能を活用する：失敗したファイルはキュー画面に残るため、右クリック→「キューに追加して再転送」で中断した箇所から再開できます
• wp-content/uploadsを分割転送する：メディアファイルが多い場合は年月フォルダ単位で分けてアップロードすると、一度のセッションが軽くなりエラーが減少します

なお、サーバーによっては1セッションあたりの最大ファイル転送数に制限を設けているケースがあります。共用サーバーを利用している場合はホスティング会社のドキュメントで同時接続数の上限を事前に確認しておくと安心です。

パーミッション（権限）設定 — 転送後に必ず確認すべき項目

FTPでのファイル転送が完了しても、パーミッション（ファイル・ディレクトリへのアクセス権限）の設定が誤っていると、サイトが正常に動作しないケースがあります。特に画像アップロードの失敗や500エラーは、パーミッション起因であることが少なくありません。転送直後に必ず確認しておくべき項目を整理します。

ディレクトリ・ファイル別の推奨パーミッション値一覧

WordPressにおけるパーミッションは、数値3桁（例：755）で表します。左から「所有者」「グループ」「その他」への権限を示し、読み取り(4)・書き込み(2)・実行(1)の合計値で表記します。以下が主要なパスごとの推奨値と、設定ミス時に発生する症状です。

• ディレクトリ全般（wp-content/ など）：755 — 所有者のみ書き込み可。777に設定するとセキュリティリスクが高まります。
• wp-content/uploads/：755 — WordPressが画像などを書き込めるよう、Webサーバーの実行ユーザーが所有者である必要があります。権限不足の場合、メディアアップロードが失敗します。
• wp-config.php：600または640 — DB接続情報を含む最重要ファイルです。644以上に開放すると第三者から閲覧されるリスクがあります。
• .htaccess：644 — パーミッションが厳しすぎるとWordPressがパーマリンク設定を書き込めず、404エラーが多発します。
• PHPファイル全般（wp-login.php など）：644 — 実行権限（755）を与える必要はなく、644で十分です。

FTPクライアントからのパーミッション変更手順

FileZillaを例に、パーミッションを変更する手順を示します。

1. FileZillaでサーバーに接続し、変更対象のファイルまたはディレクトリを右クリックします。
2. コンテキストメニューから「ファイルパーミッション」を選択します。
3. 「数値で入力」欄に推奨値（例：755 または 644）を直接入力します。
4. ディレクトリの場合は「サブディレクトリに再帰的に適用する」にチェックを入れ、「ディレクトリのみ」または「ファイルのみ」を選択して適用範囲を分けます。
5. 「OK」をクリックして完了です。変更後はブラウザで動作確認を行ってください。

wp-content/uploads/ のパーミッションは、所有者がWebサーバーの実行ユーザー（多くの場合 www-data や apache）でなければ、755に設定しても書き込みが拒否されることがあります。その場合はサーバー管理者への確認が必要です。

パーミッション（権限）設定 — 転送後に必ず確認すべき項目

FTPでファイルを転送し終えた後、多くの方がパーミッション（ファイル・ディレクトリへのアクセス権限）の確認を後回しにしがちです。しかし、設定値が適切でないと、画像のアップロードが失敗したり、サイト全体が500エラーを返したりと、公開直後に致命的な問題が起きる可能性があります。

ディレクトリ・ファイル別の推奨パーミッション値一覧

WordPressの本番環境では、ディレクトリとファイルで異なる推奨値が設定されています。下記の表で、対象パス・推奨値・設定ミス時に起きやすい症状を整理します。

• WordPressルートディレクトリ（755）：所有者のみ書き込み可。誤って777にするとセキュリティリスクが高まります。
• wp-content/uploads（755）：メディアファイルの書き込みに必要です。644のままにすると、管理画面から画像をアップロードした際に「アップロードに失敗しました」のエラーが出ます。
• wp-config.php（600または640）：DBのホスト名・ユーザー名・パスワードを含む最重要ファイルです。644以上に緩めると、他ユーザーから読み取られるリスクが生じます。
• .htaccess（644）：Apacheのリライトルールを記述します。600にするとWordPressがパーマリンク設定を書き込めず、投稿URLが404エラーになるケースがあります。
• その他のPHPファイル・テンプレートファイル（644）：読み取り専用で問題ありません。755にする必要はなく、書き込み権限を与えると改ざんリスクが上がります。

FTPクライアントからのパーミッション変更手順

FileZillaを例にした変更手順は以下のとおりです。他のFTPクライアントでも、基本的な操作の流れは同じです。

1. FileZillaでサーバーに接続し、変更したいファイルまたはディレクトリをリモートサイトのペインで選択します。
2. 対象を右クリックし、メニューから「ファイルパーミッション（File permissions）」を選択します。
3. 表示されるダイアログで数値欄に推奨値（例：755や644）を直接入力します。チェックボックスも連動して切り替わります。
4. ディレクトリに対してはダイアログ内の「サブディレクトリに再帰的に適用する」にチェックを入れると、配下のファイルにも一括適用できます。ただし、ディレクトリとファイルで推奨値が異なるため、「ディレクトリのみ」「ファイルのみ」のオプションを使い分けてください。
5. 「OK」をクリックして適用後、管理画面からメディアのアップロードを1件試し、正常に保存されることを確認します。

パーミッション設定は、転送完了後のチェックリストの先頭に位置づけておくことをお勧めします。特にwp-content/uploadsとwp-config.phpは、設定ミスの影響範囲が大きいため、本番公開前に必ず目視で確認してください。

本番公開後の動作確認 — テーマ・プラグイン・フォームの検証チェックリスト

ファイル転送とDB移行が完了しても、動作確認を省略すると見落としが後日のトラブルに直結します。本番環境はローカルとサーバー設定が異なるため、同じファイル構成でも挙動が変わるケースがあります。以下のチェックリストを順番に消化することで、公開直後の不具合を最小化できます。

表示・リンク・メディアの確認項目

まずサイト全体の表示とリンクの疎通を確認します。

• トップページ：HTTPではなくHTTPS（SSL）でアクセスし、証明書エラーが出ないことを確認します。
• 固定ページ・投稿ページ：複数のページを実際に開き、レイアウト崩れや404エラーが発生していないかを確認します。
• 内部リンク・メニュー：ローカルURLが残っている場合はリンク切れになります。Search Replaceなどで置換済みであっても、目視で数箇所クリックして動作を確かめます。
• メディアファイル：画像・PDF・動画がすべて表示・再生されるかを確認します。wp-contentディレクトリの転送漏れが原因で画像だけ表示されないケースがよく見られます。
• リダイレクト：旧URLから新URLへのリダイレクト設定（.htaccessまたはプラグイン）が意図どおりに機能しているかを確認します。

フォーム・プラグイン動作の確認

プラグインはローカルで有効だったものが、本番サーバーのPHP設定やメール送信設定の違いで正常に動作しないことがあります。

• 問い合わせフォーム：Contact Form 7などのフォームで実際に送信テストを行い、管理者メールアドレスへの到達を確認します。SMTPプラグインを使っている場合は認証情報の再設定が必要なケースがあります。
• 外部API連携：Googleマップ埋め込みやSNSフィードなど、APIキーを使う機能はドメイン制限の再設定が必要な場合があります。
• キャッシュ・SEOプラグイン：本番環境のパスに合わせてキャッシュをクリアし、サイトマップが正しいURLで生成されているかを確認します。

テーマ・テンプレートのカスタマイズ反映確認

WordPressテーマのカスタマイズが本番に正しく引き継がれているかを確認します。Cocoonのような多機能テーマは、テーマ独自の設定値がDBに保存されているため、DBの移行が不完全だと外観設定がリセットされることがあります。

• テーマ設定画面：外観 → カスタマイズ、またはテーマ独自の設定パネルを開き、フォントや配色・ヘッダー設定がローカルと一致しているかを目視で確認します。
• 子テーマのスタイル：子テーマを使用している場合、style.cssの転送漏れがないかをFTPクライアントで改めて確認します。
• テンプレートの表示切り替え：固定ページに個別テンプレートを割り当てている場合、ページ編集画面でテンプレートが正しく選択されているかを確認します。

本番公開後の動作確認 — テーマ・プラグイン・フォームの検証チェックリスト

ファイル転送とDB移行が完了した後も、動作確認を省略することはできません。ローカルでは問題がなかった設定が、本番環境では意図通りに機能しないケースは珍しくないためです。以下のチェックリストを順に確認することで、公開直後のトラブルを最小化できます。

表示・リンク・メディアの確認項目

まず、基本的なページ表示とリンク構造を確認します。

• トップページ：HTTPSで正常に表示されるか。混在コンテンツ（Mixed Content）の警告が出ていないかをブラウザの開発者ツールで確認します。
• 固定ページ・投稿：サンプルページや実際の投稿URLが404にならずに表示されるかを確認します。パーマリンク設定を保存し直すことで解消するケースがあります。
• メディアファイル：画像・PDFなどがローカルのパスのまま残っていないかを確認します。wp-content/uploads内のファイルが正しく転送されているかどうかも併せてチェックします。
• 内部リンク・リダイレクト：旧URLから新URLへのリダイレクトが301で機能しているかを確認します。
• SSL：サイトアドレスがhttpsに変更されており、証明書エラーが出ないことを確認します。

フォーム・プラグイン動作の確認

プラグインはローカルと本番でPHPバージョンや環境設定が異なると、挙動が変わる場合があります。

• 問い合わせフォーム：Contact Form 7などで実際にテスト送信を行い、管理者メールへの到達を確認します。送信後のサンクスページへの遷移も確認が必要です。
• 外部API連携：Google マップやreCAPTCHAなどは、APIキーのドメイン制限を本番ドメインへ更新しているかを確認します。
• キャッシュ系プラグイン：W3 Total CacheやWP Super Cacheは、本番用の設定に切り替え、キャッシュをクリアした状態で動作を確認します。

テーマ・テンプレートのカスタマイズ反映確認

WordPressテーマやテンプレートに手を加えている場合は、カスタマイズが正しく反映されているかを個別に確認します。

• 子テーマの適用：親テーマを直接編集していた場合、本番でも意図通りに反映されているかを確認します。子テーマ経由での変更が推奨されている理由はここにあります。
• Cocoonなどの人気テーマ固有の設定：Cocoonではスキン・フォント・カラーパレットの設定がデータベースに保存されます。DBを正しくインポートしていれば引き継がれますが、テーマ設定画面を開いて目視確認することを推奨します。
• ウィジェット・カスタマイザー設定：サイドバーやフッターのウィジェット設定がローカルと一致しているかを確認します。
• functions.phpのカスタムコード：追加したコードが本番でエラーを出していないかを、WordPressのデバッグログ（wp-config.phpでWP_DEBUGを有効化）で確認します。

上記の確認が完了した段階で、Google Search Console（GSC）へのサイトマップ送信と、インデックスリクエストを行うことが一般的な次のステップです。

デプロイ作業を効率化する — ツール選択とワークフロー設計の考え方

ツール分散による作業ミスのリスクと対策

WordPressのFTPデプロイ手順を正確に把握していても、使用するツールが分散していると作業ミスは起きやすくなります。FTPクライアント・コードエディタ・DBツール・ブラウザをそれぞれ個別に立ち上げ、都度ウィンドウを切り替えながら進める従来のフローには、次のようなリスクが伴います。

• ファイル転送先のディレクトリをツール間の切り替え時に取り違える
• DBのエクスポート・インポート操作と、FTP転送の順番が前後する
• ブラウザでの動作確認中に、どのファイルを最後に転送したか記憶が曖昧になる

これらのミスは、ツールの習熟度ではなくワークフロー設計の問題です。作業環境をできる限り一元化することが、ミス低減への現実的な対策になります。

統合ワークスペースによるデプロイフロー効率化の考え方

デプロイ効率を上げるうえで有効なのは、作業文脈をまたがずに完結できる環境を整えることです。CLANEが提供するWeb制作統合ワークスペース「CLANE ONE」は、コードエディタ・FTP操作・WordPress管理・SEO分析を一つの環境にまとめており、ツール間の往復を減らす設計になっています。

ツールの切り替えコストは小さく見えて、デプロイ全体の流れを途切れさせる要因になりやすいです。統合された環境でフローを設計することは、本番公開の確実性を高めるための実践的なアプローチといえます。

デプロイ作業を効率化する — ツール選択とワークフロー設計の考え方

ツール分散による作業ミスのリスクと対策

WordPressのFTPデプロイ手順は、一つひとつのステップ自体はそれほど複雑ではありません。しかし、作業に使うツールが分散していることで、ミスが起きやすい構造になっています。

典型的なフローを整理すると、次のようになります。

• コードエディタでファイルを編集・確認する
• FTPクライアント（FileZillaなど）を起動してサーバーへ転送する
• phpMyAdminやDBクライアントツールでデータベースをインポートする
• ブラウザでWordPress管理画面を開き、URLやパーマリンクを設定する
• 再びブラウザで表示確認・動作検証を行う

この間、アプリケーションを何度も切り替えながら作業を進めることになります。ツール間の行き来が増えるほど、「転送するファイルを一部取り違えた」「DBのインポート前にURLを書き換えてしまった」といった順序ミスや操作ミスが発生しやすくなります。

統合ワークスペースによるデプロイフロー効率化の考え方

こうした課題に対するアプローチの一つが、作業環境の統合です。ツールをまたぐ回数を減らし、一つの画面の中でデプロイに関わる操作を完結させることで、ミスの発生しやすいコンテキストスイッチ（作業の切り替え）を減らすことができます。

CLANEが提供するWeb制作統合ワークスペース「CLANE ONE」は、コードエディタ・FTP転送・WordPress管理画面へのアクセス・SEO分析といった機能を一つの環境にまとめた設計になっています。個別ツールを並列で立ち上げる従来のフローと比べて、デプロイ作業全体の手順を見通しやすい状態に整理できる点が特徴です。

ツール選択の観点では、「それぞれのツールが優秀かどうか」だけでなく、「作業フロー全体を通じてツール間の連携がどれだけスムーズか」を基準に評価することが重要です。デプロイのミスの多くは、ツール単体の問題ではなく、ツール間の情報の受け渡しや操作の順序管理に起因するためです。

まとめ — WordPressのFTPデプロイを確実に完走するために

WordPressのFTPデプロイは、手順そのものが複雑というより、各フェーズの「抜け」が積み重なって本番環境のトラブルを引き起こすケースがほとんどです。ここでは、記事全体で解説した手順を改めて整理し、実作業時のリファレンスとして活用できるようにまとめます。

デプロイ手順の全体フロー振り返り

1. 環境確認：ローカルと本番のPHP・MySQLバージョン、必要なPHP拡張モジュールの整合性を照合する
2. ファイル整理：転送対象（wp-content、wp-config.php等）と除外対象（.DS_Store、node_modulesなど）を明確に分ける
3. DB移行：ローカルDBをエクスポートし、URL置換（Search Replace DB等）を実施したうえで本番DBへインポートする
4. FTP転送：FTPクライアントの同期設定を確認し、wp-config.phpは本番用の接続情報に書き換えてから転送する
5. パーミッション設定：ディレクトリは755、ファイルは644、wp-config.phpは600を適用する
6. 動作確認：管理画面ログイン、パーマリンク再保存、プラグイン・フォーム・表示崩れを一通り検証する

フェーズ別・見落としやすいポイント早見表

• 環境確認：PHPバージョンの差異によるプラグイン非対応を見落としやすい
• ファイル整理：ローカル専用のwp-config.phpをそのまま転送してDB接続エラーを招くケースが多い
• DB移行：URL置換の漏れにより、画像パスや内部リンクが本番で壊れたままになりやすい
• FTP転送：大量ファイルの転送中断に気づかず、テーマファイルが不完全な状態で公開されるリスクがある
• パーミッション：wp-contentへの書き込み権限不足で、メディアアップロードやキャッシュ系プラグインが機能しなくなる
• 動作確認：パーマリンクの再保存を忘れると、固定ページやカテゴリページが404になる

各フェーズを順番どおりに実施し、特にDB移行とwp-config.phpの差し替えは後戻りしにくい工程として慎重に扱うことが、WordPress公開手順を制作者として確実に完走するための基本姿勢です。

まとめ — WordPressのFTPデプロイを確実に完走するために

WordPressのFTPデプロイは、手順そのものは体系化されています。ただし、各フェーズに「見落とすと本番環境が壊れる」判断ポイントが点在しているため、作業全体を俯瞰した上で進めることが重要です。

デプロイ手順の全体フロー振り返り

1. 環境確認 — PHPバージョン・MySQLバージョン・サーバー要件をローカルと本番で照合する
2. ファイル整理 — 転送対象と除外対象を明確に分類し、不要ファイルを本番に持ち込まない
3. DB移行 — ローカルDBをエクスポートし、本番用の接続情報に書き換えた上でインポートする
4. FTP転送 — 転送モード・文字コード・上書き設定を確認してからファイルを送信する
5. パーミッション設定 — ディレクトリは755、ファイルは644を基準に、wp-config.phpは600に絞る
6. 動作確認 — テーマ・プラグイン・フォーム・リダイレクトをチェックリストに沿って検証する

フェーズ別・見落としやすいポイント早見表

• 環境確認 — PHPのマイナーバージョン差異によるプラグイン非対応を見落としやすい
• ファイル整理 — .htaccessやwp-config.phpのローカル設定を上書き転送してしまうケースが多い
• DB移行 — サイトURLのシリアライズデータを単純な文字列置換で処理すると、データが破損する恐れがある
• FTP転送 — バイナリモードとASCIIモードの混在が原因でテーマファイルが文字化けする場合がある
• パーミッション設定 — 転送後に権限が777のままになり、セキュリティリスクが残るケースが少なくない
• 動作確認 — パーマリンク設定の再保存を忘れると、投稿URLが404になる

WordPress FTPデプロイの公開手順は、一つひとつのフェーズを確実にクリアすることで初めて安定稼働につながります。制作者・Web担当者を問わず、本記事を実作業時のリファレンスとして活用してください。