最初に「一記事だけ」「投稿・固定ページの全部」「管理画面も含む」「移転やURL変更の直後」のどれかを確認します。 404は「そのURLに表示する資源が見つからない」という結果で、記事本文が消えたとは限りません。パーマリンク保存、.htaccess編集、プラグイン停止を同時に行わず、正常なURLと404のURLを一つずつ記録してください。
トップページと管理画面が開き、一記事だけ404なら、その記事の公開状態・slug・親ページ・URLを先に見ます。トップは開くが投稿すべて404ならrewriteルールを疑います。トップも管理画面も開かない、403・500・データベース接続エラーになる場合は本記事の404手順を重ねず、表示された別エラーを優先します。
ねぇねぇ、佐藤さん！昨日まで読めた記事が404になりました。記事が消えたと思って、新しく作り直すところでした。
作り直す前に止まれてよかったよ。トップ、別記事、管理画面を開いて、一記事だけか全体かを分けよう。
トップと管理画面は開いて、この記事だけ404です。編集画面には記事が残っているので、本文が消えたわけではなさそうです。
そこまで分かれば全体設定はまだ触らなくていいね。編集画面のURLと404のURLを一文字ずつ比べよう。
404が出る範囲と表示元を確認する
同じ「404」でも、サーバーが返す簡素な画面と、WordPressテーマ内の「ページが見つかりません」は確認先が違います。ブラウザのアドレス欄、画面の見た目、発生時刻を残し、ログアウト状態でも同じか確認します。
| 範囲 | 最初に見る場所 | 避けること |
|---|---|---|
| 一記事だけ | 記事の公開状態、slug、親ページ、正しいURL | サイト全体のrewriteを先に編集 |
| 投稿・固定ページが全部 | パーマリンク設定、Webサーバーのrewrite | 記事を作り直す |
| カテゴリだけ | カテゴリslug、ベース、同名ページ | 無関係な記事slugを変更 |
| 移転直後 | 公開先、ドキュメントルート、Apache/Nginx設定 | 旧環境を先に削除 |
| 管理画面も不可 | URL、DNS、サーバー状態、別エラー | パーマリンク保存だけを繰り返す |
HTTPステータスを確認できる人は、問題URLが404、正常URLが200かを記録します。確認できない場合でも、URL全体と画面タイトルを残せば十分です。検索結果だけ404で直接URLは正常なら、Googleの古いURL、canonical、リダイレクトを別に確認します。
一記事だけ404なら公開状態とURLを確認する
- 管理画面の「投稿」または「固定ページ」で対象を検索する
- 公開済みか、下書き・非公開・ゴミ箱ではないかを見る
- 編集画面に表示されるURLと、404のURLを一文字ずつ比較する
- slug、親ページ、カテゴリベースを確認する
- 編集画面の「表示」から正しいURLを開く
大文字小文字、全角記号、末尾の数字、親ページのslugが違えば別URLです。記事を新規作成して同じslugを付けると、末尾に「-2」が付いて原因を増やすことがあります。まず既存記事のIDと公開状態を確認します。
URLを変更した履歴がある場合は、旧URLから新URLへの301を用意します。元URLへ戻せるなら、内部リンクと検索結果への影響を考えて戻す判断もあります。削除した記事を別内容のトップページへ一律転送すると、読者が探した内容と合わずソフト404と判断される場合があるため、同じ目的の代替記事がある時だけ転送します。
全記事が404ならパーマリンクを一度だけ再保存する
トップページと管理画面は開くのに投稿・固定ページが広く404なら、管理画面の「設定」→「パーマリンク」を開きます。現在の構造を画面保存し、値を変えずに「変更を保存」を一度押し、代表記事を確認します。WordPress公式の パーマリンク設定 でも、URL構造とWebサーバー側設定の関係が説明されています。
保存後に直れば、rewriteルールの再生成が効いた可能性があります。直らない場合に何度も構造を切り替えないでください。年月日形式から投稿名などへ変更すると、既存URLと内部リンクまで変わります。成功条件は一記事だけでなく、投稿、固定ページ、カテゴリ、画像、管理画面が正常であることです。
マルチサイト、サブディレクトリ、独自のリバースプロキシがある環境では標準設定と異なります。設定画面の保存だけで直らなければ、現在の構成をサポートへ伝えて確認します。
別のテスト環境では、トップだけ開いて記事が全部404でした。同じ404でも、さっきの一記事だけとは違うんですね。
その場合はrewriteの候補が強くなるよ。今のパーマリンク構造を保存して、値を変えず一度だけ保存しよう。
一度保存したら、代表記事が表示されました。何度も形式を切り替えず、別記事とカテゴリも確認してみます。
一記事だけで合格にしない判断がいいね。固定ページ、画像、存在しないURLの404まで見れば、rewriteが広く正常か判断できるよ。
Apacheの.htaccessとNginxの設定を混同しない
Apache系では、WordPress設置先の
.htaccess
とmod_rewriteがパーマリンクに関係します。WordPress公式の
一般的なエラー
も、Pretty Permalinksの404でパーマリンク再保存とrewrite設定を案内しています。ただし、Web上のサンプルを丸ごと貼る前に現在ファイルを保存し、WordPressの設置場所と他のリダイレクトを確認してください。
Nginxにはディレクトリ単位の
.htaccess
がありません。
WordPress公式のNginx資料
が示すように、サーバー設定側でルーティングします。Nginx環境で.htaccessだけを編集しても直りません。共用サーバーで設定場所が分からない場合は、管理画面の機能またはサポートへ確認します。
権限を777へ広げる、既存ルールを全削除する、ドキュメントルートを推測で変える操作は避けます。変更は一項目にし、変更前ファイルと時刻を残してください。
Nginxのサーバーで.htaccessを探したけど見つかりません。消えたのかと思って、空のファイルを作りそうになりました。
Nginxは.htaccessを使わないんだ。Apache向け手順を重ねず、契約先のNginx設定や管理画面を確認しよう。
ファイルが消えたのではなく、仕組みが違ったんですね。環境名と発生時刻を記録して、サポートへ聞く内容が絞れました。
その情報なら調査が進みやすいよ。分からない設定を推測で作るより、今の構成に合う場所を確かめる方が安全だね。
移転・URL変更直後は公開先と旧URLを分ける
移転後の404は、WordPress設定だけでなく、ファイルを置いた公開先、ドメインが向くサーバー、Webサーバーの設定、旧URLの転送に分けます。旧環境を残せる期間は削除せず、hosts確認や一時URLなど契約先が案内する方法で新旧を比較します。
- トップページは新環境を表示しているか
- 管理画面のサイトURLとホームURLは想定ドメインか
- WordPressファイルがドキュメントルートにあるか
- ApacheかNginxか、必要なrewriteが反映されているか
- 旧URLから同じ内容の新URLへ301されるか
- メール用DNSをサイト移転と混同していないか
画像だけ404なら、投稿パーマリンクではなくアップロード先・年月フォルダ・置換漏れを確認します。CSSやJavaScriptだけなら静的ファイルのパスやキャッシュを別に調べます。
復旧後は代表URLと404にすべきURLを確認する
一つの記事が表示されただけで完了にしません。代表的な投稿、固定ページ、カテゴリ、画像、管理画面を確認します。同時に、存在しないランダムなURLが正しく404を返すことも確認してください。何でもトップへ200で表示すると、壊れたURLを検出できなくなります。
- 問題だったURLが200で正しい記事を表示する
- 別の投稿と固定ページも200になる
- カテゴリと画像が表示される
- 管理画面で保存できる
- 存在しないURLは404のまま
- 旧URLがある場合は同内容の新URLへ301する
ブラウザキャッシュだけで判断せず、ログアウト状態または別ブラウザでも確認します。検索結果の反映には時間差があるため、公開状態とリダイレクトを先に正しくし、Search Consoleでは後日クロール結果を確認します。
よくある失敗を避けて原因を一つに絞る
404を急いで直そうとして、パーマリンク構造の変更、プラグインの一括停止、キャッシュ削除、.htaccessの置換を同時に行うと、どの操作が効いたか分からなくなります。最初に問題URLと正常URLを一つずつ決め、変更前の画面と設定値を保存し、一操作ごとに両方を確認します。改善しなければ元へ戻してから次へ進みます。
キャッシュ系プラグインやCDNを使うサイトでは、WordPress本体が正常でも古い404が配信される場合があります。ただし、最初からすべてのキャッシュを削除すると他ページへの影響が広がります。まずログイン中とログアウト中を比較し、可能なら対象URLだけを無効化します。CDNを一時停止する場合も、作業前後の時刻と復帰手順を残します。
セキュリティ系プラグインやWAFが要求を遮断した時は、404に似た独自画面を出すことがあります。URLに特定の文字列や長いクエリを付けた時だけ発生するなら、通常の記事404と分けて確認します。保護機能を全停止せず、契約先のログや除外設定を確認してください。403や429が記録されているなら、404のrewrite設定を編集する前にその制限を調べます。
また、記事のslugを日本語から英数字へ変えただけでは、すでに共有された旧URLは自動で新URLになりません。旧URLを把握して同じ内容の新URLへ301し、サイト内のメニュー、関連記事、画像リンクも更新します。反対に、存在しないURLをすべてトップページへ転送する設定は、読者が目的の記事へ到達できず、誤りの発見も遅らせます。
直らない時は変更を戻してサポートへ伝える
パーマリンク保存で直らず、rewriteや公開先を自分で確認できない場合は、設定を重ねずサポートへ相談します。問題URL、正常URL、発生時刻、直前の変更、Apache/Nginxの別、実施した一項目、戻した結果を伝えます。パスワードや認証Cookieは送りません。
問い合わせ前には、404画面とURLが同時に分かるスクリーンショット、利用中のWordPressバージョン、直前に更新したテーマやプラグイン名も用意します。サーバーのアクセスログを利用できるなら、問題を再現した時刻と自分のアクセスだけを照合します。ログ全体や他人のIPアドレスを公開掲示板へ貼らず、契約先が指定する安全な窓口で共有してください。
バックアップから戻す場合は、対象と日時を確認します。ファイルだけ戻してもデータベース内のURLや公開状態が一致しないことがあり、逆にデータベースだけを戻すと復旧後の記事更新が失われます。復元前に現状のバックアップをもう一つ確保し、サイト全体を戻すのか、設定ファイルだけを戻すのかを明確にします。
現在環境で設定・ログ・復旧支援を利用でき、原因を直せた人はサーバー変更不要です。移転直後から複数ページが404で、現環境では公開先やrewriteを確認できず、バックアップ復元支援も得られない場合だけ、管理機能と移行支援を比較します。
問題の記事は表示されましたが、これで終わりにしない方がよさそうです。画像やカテゴリまで壊れていないか少し心配です。
その心配を確認表に変えよう。投稿、固定ページ、カテゴリ、画像、管理画面を一つずつ開けばいいよ。
五種類とも正常で、存在しないURLだけは404でした。変更した一項目も記録したので、再発しても戻れそうです。
正しいページは200、存在しないページは404になったね。現在環境で直せたから、404だけを理由に移転する必要はないよ。
まとめ：404の範囲を分け、一項目ずつ戻せる形で直す
一記事だけなら公開状態とURL、全記事ならパーマリンクとrewrite、移転直後なら公開先とWebサーバー設定を確認します。ApacheとNginxでは設定場所が違います。記事を作り直したり権限を広げたりする前に、変更前の値と正常URLを残してください。
復旧後は問題URLだけでなく、別記事、固定ページ、カテゴリ、画像、管理画面、存在しないURLまで確認します。原因を現在環境で解決できたなら契約変更は不要です。
現在環境でrewrite・ログ・復旧支援を確認できない場合
404を現在環境で直せた人には契約変更不要です。移転直後から複数ページが404で、公開先・Webサーバー設定・バックアップ復元を確認できない場合だけ、管理機能と支援範囲を比較します。
エックスサーバー
WordPress移行、バックアップ、サーバーパネル、問い合わせ方法をまとめて確認したい場合の候補です。
向いている人： 発生URLと時刻を記録し、rewriteや復元をサポートへ相談したい人
利点： WordPress向け管理機能と移行・バックアップ関連の公式情報を確認できる
不要な人： パーマリンク再保存やURL修正で現在環境の404を直せた人
注意点： 記事固有のslug間違いや削除済みURLは移転だけでは直りません。
料金： 契約期間・プラン・キャンペーンで変わるため申込画面の総額を確認
エックスサーバーの移行・復旧条件を確認する
ConoHa WING
WordPress移行機能と管理画面、バックアップ条件を同じ候補で確認したい場合に比較できます。
向いている人： 新旧環境を残しながら移転手順とサポート条件を確認したい人
利点： WordPress移行と管理機能の範囲を公式情報で確認できる
不要な人： 一記事の公開状態やslugだけが原因だった人
注意点： 移転前にURL一覧、メールDNS、旧環境の保持期間を記録します。
料金： 契約期間・料金タイプで変動するため初回総額と更新料金を確認
ConoHa WINGの移行・管理条件を確認する広告・PRを含みます。404を現在環境で修正できた場合は契約変更不要です。最新条件と支援範囲を公式ページで確認してください。
よくある質問
パーマリンク設定は別の形式へ変更した方がよいですか？
最初は現在値を記録し、値を変えず一度だけ保存します。形式変更は既存URL全体へ影響するため、404修復だけを目的に安易に変更しません。
.htaccessを削除して作り直してもよいですか？
先に現在ファイルを保存し、Apache環境か、WordPressの設置場所と他のリダイレクトがあるかを確認します。Nginxは.htaccessを使いません。
削除した記事はトップページへ転送すればよいですか？
同じ検索目的の代替記事がある場合だけ、その記事へ301します。無関係なトップへの一律転送は読者の目的と合わず、ソフト404になる可能性があります。
404が直ったと判断する条件は何ですか？
問題URLが200で正しい記事を表示し、別記事、固定ページ、カテゴリ、画像、管理画面も正常で、存在しないURLは404になることを確認します。