WordPressサイトでページを開いたときに「404 Not Found」や「ページが見つかりません」と表示されると、記事や画像が消えたのではないかと不安になります。しかし、404は「そのURLに対応するページを見つけられなかった」という応答であり、必ずしも投稿データそのものが失われた意味ではありません。URLの入力間違い、リンク先の変更、パーマリンクの書き換え設定、サーバー移行後の設定不足など、原因は複数あります。
大切なのは、404をすべて消そうとすることではありません。存在しないURLが正しく404を返すのは正常な動作です。一方で、公開中の投稿や固定ページまで404になる場合は、読者が必要な情報へ到達できず、問い合わせや申込みの機会も失われます。正常な404と、直すべき404を分けて考える必要があります。
この記事では、初心者が本番サイトを壊さずに原因を切り分ける順番、管理画面でできる確認、パーマリンクやサーバー設定を扱うときの注意、移転・URL変更時の判断、専門家へ依頼する目安を解説します。思いついた設定を一度に変えるのではなく、影響の小さい確認から一つずつ進めましょう。
WordPressの404エラーとは
404はHTTPステータスコードの一つで、サーバーには到達したものの、要求されたURLに該当するファイルやページを見つけられなかったときに返されます。サイト全体が停止している状態とは異なり、トップページや管理画面は開けるのに特定の投稿だけ404になることもあります。
WordPressでは、ブラウザから届いたURLをそのまま実ファイル名として探すだけではありません。パーマリンクのルールに従ってURLを解釈し、データベース内の投稿、固定ページ、カテゴリー、タグ、カスタム投稿などに結び付けます。この書き換えルールと現在のサイト構成が一致しないと、投稿が存在していても404が表示されます。
正常な404と直すべき404を分ける
存在したことのないURL、削除済みで代替ページもないURL、入力を間違えたURLが404を返すのは正常です。Google Search Centralも、ページとコンテンツがなく、適切な代替先がない場合は404または410を返す考え方を案内しています。すべての404をトップページへ転送する必要はありません。
一方、公開中の投稿を投稿一覧から「表示」しても404になる、サイト内メニューや記事内リンクから開けない、パーマリンク設定の変更直後から多数のページが404になった、といった場合は修正対象です。また、ページがないと表示しながらHTTP応答が200になる「ソフト404」も、読者と検索エンジンの双方を混乱させるため確認が必要です。
404とほかのエラーを混同しない
403はアクセスを拒否された状態、500はサーバー内部で処理に失敗した状態、DNSエラーや接続タイムアウトはサーバーへ到達できていない状態です。見た目が似た独自エラーページでも、原因と対処は異なります。ブラウザーの開発者ツール、サーバーのアクセスログ、URL検査などを使える場合は、実際のHTTPステータスを確認してください。
管理画面へ入れるか、トップページは開けるか、特定のURLだけか、すべての投稿かを記録すると、404の範囲を早く判断できます。サポートへ相談するときも「サイトが見られない」だけでなく、対象URLとHTTPステータスを伝えると調査が進みやすくなります。
最初に被害を広げないための確認
404を見つけた直後は、早く直したくても設定やファイルをまとめて変更しないでください。複数の変更を同時に行うと、どれが原因だったか分からなくなり、元に戻せなくなることがあります。まず現状を保存し、再現条件を記録します。
対象URLと発生条件を記録する
404になったURLを省略せずにコピーし、発生日時、直前に行った作業、ログイン中とログアウト中の違い、パソコンとスマートフォンの違いを記録します。URL末尾のスラッシュ、英字の大文字・小文字、全角文字、余分な空白、リンクに含まれる記号も確認します。
同じ投稿を管理画面の投稿一覧から開いた場合と、検索結果や外部リンクから開いた場合でURLが違うことがあります。古いURLだけが404で、新しいURLは正常なら、WordPressの故障ではなくURL変更後のリンクや転送の問題と考えられます。
影響範囲を小さな表にする
- トップページは開けるか
- 管理画面へログインできるか
- 一つの投稿だけか、すべての投稿か
- 固定ページ、カテゴリー、画像にも影響するか
- 新規投稿と過去投稿で違いがあるか
- ログアウト状態や別端末でも再現するか
「投稿だけすべて404」なら書き換えルール、「一つだけ404」なら公開状態やスラッグ、親子関係、「画像だけ404」ならファイルの保存先や移行漏れというように、範囲から候補を絞れます。ただし、この段階で断定せず、次の確認で事実を積み上げます。
変更前のバックアップを確保する
パーマリンクを保存するだけで直る場合もありますが、.htaccessやサーバー設定、プラグイン、リダイレクトまで触る可能性があるなら、作業前のバックアップが必要です。WordPressのファイルとデータベースの両方を確保し、保存日時、保存先、復元方法も確認します。
バックアップがあるという表示だけで安心せず、現在の投稿と設定を含む世代か、復元権限があるかを見ます。本番サイトで注文、予約、会員情報、問い合わせなどが動いている場合は、復元によるデータ巻き戻しの影響も考え、安易にサイト全体を戻さないでください。
原因を切り分ける安全な順番
404の原因調査は、URLの確認から始め、WordPress上のページ状態、パーマリンク、プラグインやテーマ、サーバー設定の順に進めると安全です。影響の大きい操作ほど後に回し、各段階で一つだけ変更して結果を記録します。
URLの入力とリンク先を確認する
最初に、アドレスバーへ手入力したURLの誤りがないか確認します。記事タイトルを変更しても、設定によってはスラッグが自動で変わらない場合があります。逆にスラッグを変更したのに、メニュー、ボタン、記事内リンク、メール、SNS、広告などが古いURLのまま残っていることもあります。
WordPress管理画面の投稿または固定ページ一覧から対象を開き、現在表示されているURLと404のURLを比較します。ページが正常に公開されているなら、古いリンクを更新するか、明確な移転先がある場合だけ恒久転送を検討します。似ているだけのページへ無理に転送すると、読者の期待と内容がずれます。
公開状態と削除状態を確認する
対象ページが下書き、非公開、予約投稿、ゴミ箱に入っていないかを確認します。公開済みに見えても、公開日時、表示対象、親ページ、投稿タイプ、言語や会員制プラグインの条件によって一般の訪問者には表示されないことがあります。
ゴミ箱から復元する場合は、同じスラッグを持つ別ページが作られていないかも確認してください。WordPressが重複回避のためスラッグ末尾に数字を付けると、以前のURLと一致しません。ページを復元した後は、ログアウト状態で現在のURLを開きます。
パーマリンク画面を確認する
WordPress公式の「Settings Permalinks screen」では、管理画面の「設定」から「パーマリンク」を開くとURL構造を管理でき、画面を開くことで書き換えルールの再生成が行われると説明されています。公開ページが存在するのに多数の投稿が404になる場合は、現在の構造を記録してからこの画面を確認します。
構造を別のものへ変えて保存し、元へ戻す操作は、既存URLを一時的に変える可能性があります。まず現在の選択内容とカスタム構造を記録し、意図せず変更しないことが重要です。保存後は、トップページ、投稿、固定ページ、カテゴリー、問い合わせなど主要URLを確認します。
公式資料では、.htaccessが書き込み可能ならWordPressがルールを更新し、書き込みできない場合は必要なルールが画面に示されると説明されています。権限やファイル編集に慣れていない場合は、表示された内容を推測で追加せず、レンタルサーバーのサポートへ相談してください。
直前の変更を一つずつ戻して確認する
404がプラグインの導入・更新、テーマ変更、子テーマ編集、リダイレクト設定、セキュリティ設定の直後に始まったなら、変更との関連を疑います。すべてを一括停止する前に、直前に変更した項目から一つずつ確認します。
リダイレクト、キャッシュ、多言語、会員制、カスタム投稿、SEO、セキュリティ系のプラグインはURL処理へ関わることがあります。ただし、プラグイン名だけで原因とは断定できません。停止前後のURLとステータスを記録し、原因でなければ元の状態へ戻します。フォーム、決済、ログイン、アクセス制御など他機能への影響も確認します。
キャッシュの残りを確認する
設定を直しても404が続く場合、ブラウザー、WordPressのキャッシュプラグイン、サーバーキャッシュ、CDNに古い応答が残っていることがあります。まずシークレットウィンドウや別端末で確認し、必要な層だけを消去します。
全キャッシュを無計画に削除すると一時的にサーバー負荷が上がることがあります。アクセスが多いサイトでは対象URL、実行時刻、CDNのパージ範囲を決めてください。キャッシュを消したことで直っても、元の404を生んだ設定が残っていないか再確認します。
パーマリンクとサーバー設定が原因のケース
トップページは表示されるのに投稿や固定ページだけが404になる場合、WordPressがURLを解釈するための書き換えルールが動いていない可能性があります。特にサーバー移行、ドメイン変更、サブディレクトリ移動、常時SSL化、サーバー構成変更の後は確認が必要です。
Apache環境の.htaccessを扱うとき
Apache環境では、WordPressのパーマリンクが.htaccess内のmod_rewriteルールを利用する構成があります。WordPress公式の「Common WordPress errors」でも、きれいなパーマリンクで404になる場合は、パーマリンクの再設定や.htaccessの確認、mod_rewriteの有効化が案内されています。
.htaccessはサイト全体のアクセス制御や転送に関わる重要なファイルです。既存内容にはWordPress以外のセキュリティ設定、常時SSL化、WAF、キャッシュ、管理画面保護などが含まれる場合があります。「標準の内容」に丸ごと置き換えると、別の機能を壊すおそれがあります。編集前に必ずコピーを保存し、変更箇所を限定してください。
ファイルが見えない場合は、ドットで始まる隠しファイルの表示設定を確認します。書き込み権限を広くしすぎるのも危険です。適切な権限が分からない場合は、サーバー会社へ「パーマリンクの書き換えルールが反映されるか」「mod_rewriteが利用できるか」を確認するのが安全です。
Nginx環境では.htaccessを探さない
WordPress公式のNginx資料では、NginxにはApacheの.htaccessに相当するディレクトリ単位の設定ファイルがなく、設定はサーバー管理者がサーバーレベルで行うと説明されています。Nginx環境で.htaccessを作成しても、通常は期待した書き換え設定にはなりません。
Nginxを主サーバーとして使う場合は、locationやtry_filesなどの設定がWordPressのURL処理に合っているか確認します。ただし、レンタルサーバーやマネージド環境では利用者が直接編集できないことがあります。また、レスポンスヘッダーにNginxと出ても、実際には前段のリバースプロキシで、背後にApacheがある構成もあります。表示だけで断定せず、契約先の仕様を確認してください。
サブディレクトリやサイトURLの不一致
WordPress本体をサブディレクトリへ置き、公開URLはドメイン直下にする構成では、「WordPressアドレス」と「サイトアドレス」の役割が異なります。移行時に一方だけを変更したり、設定ファイルやデータベースのURLが旧環境のままだったりすると、一部のページや管理機能で不整合が起こります。
管理画面へ入れる場合は「設定」「一般」とサイトヘルスの情報を確認します。管理画面へ入れない状態でデータベースを直接書き換えるのは、URLを誤ると復旧を難しくします。旧URLと新URL、WordPressの設置場所、公開ディレクトリ、SSLの有無を整理してから作業してください。
一つのページだけ404になる場合
サイト全体ではなく一つの投稿や固定ページだけが404なら、サーバー全体の書き換えより、そのページ固有の状態を先に確認します。公開状態、スラッグ、親ページ、同名ページ、カスタム投稿の設定、古いリンクを順に見ます。
スラッグの重複と変更履歴を確認する
投稿と固定ページ、カテゴリー、タグ、カスタム投稿で似たスラッグを使うと、プラグインや独自ルールを含む構成では競合が起きることがあります。管理画面で対象ページの現在のスラッグを確認し、ゴミ箱や別の投稿タイプに同名がないかを調べます。
スラッグを変える前に、外部リンク、検索結果、メール、QRコード、広告、印刷物などで旧URLが使われていないか確認します。公開後のURL変更は、単に新しいスラッグへ書き換えるだけでなく、旧URLから新URLへの転送と内部リンク更新をセットで考えます。
親ページと階層を確認する
固定ページに親子関係がある場合、親ページのスラッグ変更で子ページのURLも変わる構成があります。メニューに登録されたURLが古いままなら、子ページだけ404に見えます。現在のパーマリンクを管理画面で確認し、メニューや本文リンクと比較してください。
親ページをゴミ箱へ移動した、非公開にした、階層を変更した場合も影響します。ページ階層を元へ戻すか、新しい構成へ合わせてリンクを更新するかを決めます。旧URLに十分な利用実績がある場合は、適切な転送も検討します。
カスタム投稿タイプのルールを確認する
制作実績、商品、イベントなどのカスタム投稿では、登録時のrewrite設定、投稿タイプ名、固定ページのスラッグが競合することがあります。WordPress公式資料も、カスタム投稿タイプと単一ページが同じ名前の場合に404が起きる可能性を示しています。
この領域はテーマやプラグイン、独自コードに依存します。運用中の本番サイトで登録コードを直接変更すると、既存URL全体へ影響する可能性があります。ステージング環境で再現し、パーマリンクの再生成、スラッグ設計、転送計画をまとめて検証してください。
移転やURL変更後に404が増えた場合
サーバー移行、ドメイン変更、httpからhttpsへの移行、ディレクトリ変更、サイト統合の後に404が増えた場合は、個別ページを一件ずつ直す前に移行全体を確認します。旧URLと新URLの対応表がないまま転送を追加すると、ループや誤転送が起きやすくなります。
旧URLと新URLの対応表を作る
主要な投稿、固定ページ、カテゴリー、画像、問い合わせ導線について、旧URL、新URL、現在のステータス、転送の要否を一覧にします。URL構造を維持した移行なら、ドメイン部分だけの変更で済むことがあります。構造も変更したなら、個別の対応が必要です。
すべてをトップページへ転送する方法は簡単に見えますが、探していた内容と転送先が一致しません。代替ページが明確なら301転送、コンテンツがなく代替もないなら404または410というように、利用者にとって自然な結果を選びます。
データベース置換とファイル移行を別々に確認する
投稿本文のURL置換が完了していても、画像ファイルが移行されていなければ画像だけ404になります。逆にファイルがあっても、添付URLやアップロードパスが旧環境を向いていれば表示されません。データベース、uploadsフォルダー、テーマ・プラグイン、サーバー設定を分けて確認します。
WordPressのデータにはシリアライズされた値が含まれることがあるため、単純な文字列置換で壊れる場合があります。大量置換はバックアップと検証環境を用意し、WordPress対応の方法または移行ツールを使います。置換後は投稿本文だけでなく、ウィジェット、メニュー、カスタムフィールド、テーマ設定も確認してください。
転送ループと多段転送を避ける
httpからhttps、wwwありからなし、旧ドメインから新ドメイン、旧スラッグから新スラッグを別々の場所で設定すると、複数回の転送やループが起きることがあります。WordPressプラグイン、.htaccess、サーバー管理画面、CDNのどこで転送を管理するかを明確にします。
変更後は代表URLだけでなく、末尾スラッシュの有無、クエリ文字列、カテゴリー、画像、存在しないURLも確認します。正常なページは最終URLで200、移転したページは適切な転送を経て200、存在しないページは404または410になることが目安です。
SEOで誤解しやすい404の扱い
Search Consoleに404が表示されたからといって、すべてが重大なSEO障害とは限りません。削除したページや誤った外部リンクなど、存在しないURLが正しく404を返している場合もあります。重要なのは、そのURLに本来あるべきコンテンツがあるか、代替ページがあるかです。
削除済みページは無理に復活させない
内容が古く、代替ページもないなら、404または410のままでも不自然ではありません。読者が別の情報を探せるよう、404ページにサイト内検索、主要カテゴリー、ホームへのリンクを用意する方法があります。ただし、見た目を整えてもHTTPステータスは404を返す必要があります。
削除ページへの内部リンクが残っているなら修正します。外部サイトから重要なリンクがあり、同じ目的を満たす新ページが存在する場合は、その新ページへの301転送を検討します。関連性の弱いページへ機械的に転送しないことが大切です。
ソフト404を見逃さない
ソフト404は、ページがない旨を表示しているのに200を返す状態です。Google Search Centralでは、こうしたページは利用者にとって分かりにくく、検索結果から除外されることがあると説明しています。存在しないURLをトップページへ転送する設定や、空に近いページが200を返す構成を確認します。
Search ConsoleのURL検査だけでなく、ブラウザーの開発者ツールやHTTPヘッダー確認手段で応答を見ます。CDNやキャッシュが異なる応答を返す場合もあるため、ログイン状態、地域、端末を変えて確認すると切り分けやすくなります。
サイトマップと内部リンクを更新する
XMLサイトマップに404のURLが残っている場合は、サイトマップ生成元の公開状態やURL設定を確認します。手動でXMLだけを書き換えても、次回生成時に戻る可能性があります。投稿の状態、パーマリンク、SEOプラグインのサイトマップ設定など、元のデータを直します。
記事本文、メニュー、パンくず、関連記事、フッター、画像リンクなどの内部リンクも確認します。404ページを直すだけでなく、読者が古いURLへ進む入口を減らすことが再発防止になります。
やってはいけない対処
404は設定を変えると一時的に直ることがありますが、原因を確認せずに広い変更をすると別の障害を生みます。とくに本番サイトでは、次の操作を急いで行わないでください。
- バックアップなしで.htaccessやNginx設定を上書きする
- 現在のパーマリンク構造を記録せずに変更する
- すべての404をトップページへ転送する
- 複数のプラグインやテーマを同時に停止・削除する
- 本番データベースで一括置換を試す
- 原因を確認せずサイト全体を古いバックアップへ戻す
- ファイル権限を必要以上に緩くする
変更は一つずつ行い、変更前の値、変更内容、確認URL、結果、戻し方を記録します。効果がなければ元へ戻してから次へ進みます。この記録があれば、途中から専門家へ引き継ぐ場合にも調査の重複を減らせます。
自分で対応するか依頼するかの判断基準
URLの入力間違い、投稿の公開状態、古い内部リンク、パーマリンク画面の確認などは、管理画面へ入れてバックアップがあれば自分で対応しやすい範囲です。一方、サーバー設定や大規模移行、売上に関わる機能が影響している場合は、早めの依頼が安全です。
自分で進めやすいケース
- 影響が一つのページに限定されている
- 管理画面へ入り、公開状態と現在URLを確認できる
- 直前の変更が明確で、元へ戻せる
- ファイルやデータベースを直接編集しなくてよい
- 検証用のバックアップと確認時間を確保できる
この範囲でも、変更後は対象ページだけでなく主要導線を確認します。直ったように見えても、フォーム、会員ログイン、決済、検索、画像など別機能へ影響していないかを見て完了とします。
サーバー会社へ相談したいケース
- パーマリンク保存時に.htaccessの更新を求められる
- mod_rewriteやNginxの設定が必要か分からない
- サーバー移行やドメイン変更の直後から発生した
- WAF、CDN、キャッシュ、アクセス制限が関係しそう
- 同じサーバー上の複数サイトで同時に異常がある
サーバー会社へは、契約IDなど必要な情報を安全な窓口から伝え、対象ドメイン、発生日時、404になるURL、正常なURL、直前の変更、確認済み事項をまとめます。WordPressの独自コードやプラグイン内部はサポート範囲外の場合があるため、どこまで調査できるかも確認します。
WordPress制作者や保守担当へ依頼したいケース
- 多数の公開ページが404で事業への影響が大きい
- カスタム投稿タイプや独自テーマが関係している
- リダイレクトが複数箇所に設定され、全体像が分からない
- データベース置換やサーバー設定変更が必要
- バックアップの復元可否を自分で判断できない
- 短時間で再発する、または原因が複数ありそう
依頼時には「404を直してください」だけでなく、正常に戻したいURL、残すべきURL構造、変更してよい時間帯、公開停止の可否、バックアップ場所、サーバーとCDNの構成、直前の作業履歴を共有します。パスワードや秘密鍵はメールやチャットへ貼らず、権限を限定した安全な共有方法を使ってください。
復旧後に確認する項目
対象URLが表示された時点で作業を終えると、別ページの404や誤ったステータスを見逃します。復旧後は、利用者の導線とWordPressの管理状態をまとめて確認します。
- トップページ、主要投稿、固定ページ、カテゴリーが200で表示される
- 旧URLから新URLへの転送が意図どおりである
- 存在しないURLが正しい404を返す
- メニュー、記事内リンク、パンくず、関連記事に古いURLがない
- 画像、CSS、JavaScriptなどのファイルが404になっていない
- ログイン、フォーム、検索、会員、決済など主要機能が動く
- キャッシュを再生成した後も結果が変わらない
- サイトマップに削除済みURLが残っていない
変更内容、作業日時、担当者、確認URL、バックアップ、戻し方を保守記録に残します。パーマリンクやリダイレクトは数か月後に別の担当者が触ることもあるため、設定場所を明記しておくと再発防止になります。
WordPressの404エラーに関するよくある質問
404が一件あるだけでSEO評価は大きく下がりますか
存在しないURLが正しく404を返すこと自体は、直ちにサイト全体の問題を意味しません。公開中の重要ページが404になっていないか、内部リンクやサイトマップから大量に404へ誘導していないかを確認します。代替ページがある場合だけ適切に転送し、ない場合は正常な404として扱います。
パーマリンク設定を保存すれば必ず直りますか
書き換えルールの不整合が原因なら直る可能性がありますが、公開状態、スラッグ、移行漏れ、プラグイン、サーバー設定が原因なら保存だけでは直りません。現在の構造を記録し、保存後の確認結果を見て次の候補へ進みます。
.htaccessを削除して作り直してもよいですか
既存の.htaccessにはWordPress以外の重要設定が含まれることがあります。内容を確認せず削除・上書きするのは避けてください。バックアップを取り、サーバー構成と必要なルールを確認し、分からない場合はサーバー会社や保守担当へ依頼します。
404をすべてトップページへ転送してもよいですか
おすすめできません。利用者が探していた内容とトップページが一致せず、ソフト404と判断される可能性もあります。明確な代替ページがあるURLはそのページへ転送し、代替がないURLは404または410を返すのが基本です。
直った後にSearch Consoleで何を確認しますか
対象URLをURL検査し、実際のHTTP応答と取得結果を確認します。ページインデックス登録レポートの404やソフト404、サイトマップに含まれるURLも見ます。反映には時間がかかることがあるため、設定を短時間に何度も変えず、修正内容と確認日を記録します。
まとめ
WordPressの404エラーは、ページが本当に存在しない正常な404と、公開中のページを見つけられない異常を分けることが出発点です。対象URL、影響範囲、直前の変更を記録し、バックアップを確保してから、URL、公開状態、パーマリンク、プラグインやテーマ、キャッシュ、サーバー設定の順に確認します。
Apacheの.htaccessとNginxのサーバー設定は扱いが異なり、移行や独自投稿タイプではURL全体の設計も関わります。分からないまま設定を上書きせず、変更を一つずつ試して結果を残してください。多数のページ、売上や会員機能、データベース、サーバー設定へ影響する場合は、早めにサーバー会社やWordPressの保守担当へ相談する方が、停止時間と二次被害を抑えやすくなります。
