WordPressのダウンロード方法｜公式版の入手と安全な導入手順

WordPressをダウンロードするときは、検索結果に出てきたZIPファイルを適当に取得するのではなく、公式の配布元と導入先の環境を確認します。WordPress本体、テーマ、プラグインは別のファイルなので、同じ「WordPressのダウンロード」という言葉でも手順が異なります。この記事では、WordPress本体を安全に入手し、ダウンロード後に何を確認してサーバーへ設置するかを整理します。

公式パッケージを取得できても、その時点でサイトが完成したわけではありません。PHPとデータベースの要件、HTTPS、ファイルの設置場所、データベース情報、バックアップ、管理者アカウントを準備する必要があります。特に既存サイトへ上書きすると、記事や設定が失われる可能性があるため、先に新規インストールか更新かを判定します。

ダウンロード：始める前に必要なもの

WordPress本体のダウンロードは、公式サイトから現行の安定版を取得する作業です。新しいバージョンを使う目的で古いZIPを探すのではなく、現在の保守状況、サーバー要件、テーマ・プラグインの互換性を確認します。過去版が必要なテストでは、取得理由と保管場所を記録し、本番へ古い版を新規導入しないようにします。

推奨PHP・データベース・HTTPSを確認する

WordPress公式のRequirementsでは、2026年8月9日時点の推奨環境としてPHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上、HTTPS対応が案内されています。ダウンロード前にサーバーのPHP版とデータベース版を確認し、要件を満たせない場合は、先にサーバーのプランやバージョンを見直します。

要件を満たさないZIPを選び直すのではなく、環境側を確認します。古いPHPで動く可能性があっても、最新のセキュリティ修正やテーマ・プラグインの対応を受けられない場合があります。サーバー会社の管理画面でPHPを切り替えるときは、既存サイトの互換性、バックアップ、切り戻し方法を確認してから変更します。

HTTPSは、ダウンロードしたZIPを置く場所だけの話ではありません。インストール後のサイトURL、管理画面URL、画像、CSS、フォームの送信先がHTTPSへそろっている必要があります。SSL証明書の発行状況と更新方法を確認し、HTTPのまま管理者パスワードや記事を送信しない環境を用意します。

ドメイン・サーバー・管理権限をそろえる

WordPress本体をダウンロードする人と、サーバーへ設置する人が別の場合、引き継ぐ情報を分けます。共有するのはZIPの入手元、対象バージョン、保存場所、設置先URL、実施日時、確認項目です。サーバーのログインパスワード、データベースパスワード、アプリケーションパスワードを、記事制作のCSVや本文へ書き込みません。

設置先が新規ドメインなのか、既存サイトのサブディレクトリなのか、テスト用サブドメインなのかで操作が変わります。サーバー上に public_html や htdocs などの公開フォルダーがある場合も、契約先の指定を確認します。ZIPを展開する場所を間違えると、管理画面は開けても公開URLから見つからないことがあります。

管理権限は最小限に分けます。ファイルを配置するためのFTPやSSH権限と、WordPress管理者権限は同じとは限りません。作業者へ必要な権限だけを渡し、作業後に一時的なアカウントや鍵を停止します。外部連携が必要な場合も、通常の管理者パスワードを共有せず、利用先ごとに失効できる認証情報を使います。

導入方法を選ぶ

WordPressの公式ダウンロードには、ZIPを取得して手動で設置する方法と、サーバー会社の簡単インストールを使う方法があります。ZIPを取得すること自体は同じでも、データベース作成、設定ファイル、権限、更新、バックアップを誰が管理するかが違います。自分の環境と担当者の経験に合う方法を選びます。

サーバーの簡単インストールが向く場合

サーバーの簡単インストールは、公式パッケージの取得、ファイル配置、データベースの設定を管理画面からまとめて実行できる方式です。初めての導入で、サーバー会社のサポートを受けたい場合に向いています。ただし、画面に表示される「インストール」ボタンが、既存サイトを初期化する操作ではないかを確認します。

入力前に、ドメイン、設置先ディレクトリ、サイト名、管理者メール、ユーザー名、パスワード、データベースの扱いを確認します。既存の同名ファイルやデータベースがある場合は、上書きや重複の警告を読みます。新規サイトのつもりでも、以前のテスト環境が残っていることがあります。

簡単インストール後は、管理画面の「設定→一般」でサイトURLを確認し、固定ページと投稿を一つずつ作成します。テーマとプラグインを大量に追加する前に、ログイン、表示、画像、パーマリンク、メール、HTTPSを確認してください。標準テーマのまま動作確認を済ませると、後でテーマを入れたときの差分を追いやすくなります。

手動インストールが必要な場合

手動設置では、WordPress公式ダウンロードページからZIPを取得し、展開したファイルを公開フォルダーへ配置します。公式ページのURLをブックマークし、検索広告や第三者の再配布ページから取得しないことが安全の基本です。ZIPを取得した日時とページURLを記録すると、後で同じ版を再現できます。

ZIPを展開すると、WordPressのファイル群が入ったフォルダーが作成されます。公開フォルダー直下へ配置するのか、 blog などのサブディレクトリへ置くのかを決めます。余分なフォルダーが一段入ると、URLが想定と変わります。設置後にブラウザーで公開URLと管理画面URLを開き、インストール画面が表示される場所へ配置できたかを確認します。

データベースを作成したら、データベース名、ユーザー、パスワード、ホストを安全に管理します。インストール画面や wp-config.php の入力を、共有チャットや記事メモへ貼りません。設定ファイルをバックアップするときは、公開URLからダウンロードできない場所へ保管し、不要な一時ファイルを削除します。

設定を順番に進める

ダウンロードしたファイルを設置したら、管理画面へ入れる状態を作り、初期設定を順番に行います。最初からデザインを作り込まず、URL、データベース、メール、権限、バックアップを確認してからテーマやプラグインへ進みます。

データベースとwp-config.phpの役割

WordPressは、投稿、固定ページ、ユーザー、設定をデータベースへ保存し、テーマやプラグイン、画像をファイルへ保存します。ZIPを再ダウンロードしても、既存の記事や設定が戻るわけではありません。移行や更新の前には、データベースと wp-content を含むファイルを同じ時点でバックアップします。

wp-config.php にはデータベース接続情報や秘密鍵が入るため、ダウンロードしたファイルの中で最も慎重に扱います。ログへ内容を出さず、作業画面を共有するときも値を隠します。デバッグ設定を使う場合は、エラーを訪問者へ表示しない設定を選び、作業後に不要なデバッグを無効化します。

データベース接頭辞を指定する画面がある場合も、入力の目的を理解してから決めます。推測されにくい接頭辞は補助的な対策に過ぎず、更新、強い認証、最小権限、バックアップ、HTTPSを省略する理由にはなりません。設定値を変更したら、管理画面へログインできるか、記事が保存できるか確認します。

設置先URLと管理者情報を決める

インストール時に入力するサイトアドレスは、訪問者が開くURLです。 https://example.com と https://example.com/blog は別の設置先なので、ドメイン、サブディレクトリ、wwwの有無を決めてから入力します。後から変更すると画像やリンク、リダイレクトに影響するため、テスト環境と本番環境を混同しません。

管理者メールは、パスワード再設定や更新通知を受け取れるアドレスにします。入力後、実際に受信できるかを確認します。ユーザー名は推測されやすいものを避け、記事の著者名として公開する名前と、ログイン用の識別子を分けます。担当者ごとにユーザーを作り、管理者権限を必要な人だけへ付与します。

インストール後は「設定→一般」「設定→パーマリンク」「設定→表示」などを確認し、サイト名、タイムゾーン、日付形式、トップページ、URL構造を決めます。テスト中に検索エンジンへ表示されない設定を使った場合は、本番公開時に戻すことをチェック項目へ入れます。

公開前の動作確認

ダウンロードと設置が成功しただけでは、サイトの公開準備は終わりません。訪問者が見る公開画面、記事編集者が使う管理画面、メールやフォームなどの外部連携を分けて確認します。問題を見つけたら、テーマやプラグインを増やす前に標準状態へ戻って原因を切り分けます。

ログイン・表示・メール・更新を試す

管理者でログインし、投稿の下書き保存、画像のアップロード、固定ページの作成、メニューの確認を行います。次にログアウトして、トップページ、記事詳細、固定ページ、カテゴリー、検索結果、404ページを開きます。管理バーが表示されるログイン中だけでなく、訪問者と同じ状態で表示を確認します。

問い合わせフォームや通知メールを使うなら、テスト用のアドレスで送信し、受信、返信先、迷惑メール判定を確認します。サーバーによってはPHPのメール送信制限があり、フォーム画面に成功と出ても届かないことがあります。DNSや送信元ドメインの設定を契約先の案内で確認し、実在顧客の個人情報をテストに使いません。

WordPress本体を更新する前に、テーマとプラグインが対象版へ対応しているかを確認します。アップデート後は、ダウンロードした版、更新日時、確認した画面を記録します。表示崩れ、500エラー、フォーム停止が起きた場合は、更新前のバックアップから戻す判断をし、闇雲に別のプラグインを追加しません。

バックアップと復旧経路を残す

公式ZIPはWordPress本体を再取得するためのものですが、サイトのコンテンツをバックアップするファイルではありません。データベース、テーマ、プラグイン、アップロード画像、設定ファイルを含む復旧セットを作ります。サーバー会社の自動バックアップを使う場合も、対象、保存期間、復元手順、復元中のサイト停止を確認します。

検証環境へバックアップを復元し、管理画面へログインできるか、投稿と画像が表示されるか、フォームが動くかを試します。復元テストをしていないバックアップは、存在していることしか確認できません。復元できない場合は、別のバックアップ方式や保管場所を検討します。

ダウンロードしたZIPの取得元URL、取得日、対象バージョンは作業記録へ残します。ただしZIPそのものを公開フォルダーや不特定多数が見られる共有リンクへ置かず、必要な担当者だけが扱える場所で保管します。展開途中の一時ファイルや設定メモに、データベース情報や認証情報が残っていないことも作業後に確認します。

取得したファイルを別の環境へ渡す場合も、公式の配布元と版が一致することを受け手側で確認します。ファイル名だけを根拠にせず、作業記録のURLと日付を照合してください。

WordPressのダウンロードは、公式ページから現行版を取得して終わりではありません。サーバー要件を確認し、設置先と権限を決め、データベースと設定ファイルを安全に扱い、標準状態で表示・メール・更新・復旧を試すまでが導入です。公式配布元と契約先の現行情報を照合し、取得した版と作業記録を残しておくと、後の移行や更新でも安全に同じ環境を再現できます。