公開済みの記事が404になる原因は、URLの誤り、非公開・削除、書き換えルール、移行先の設定などです。
WordPressの書き換えルールを再生成することで直る場合がありますが、サーバー側の適用条件に問題があれば、保存だけでは復旧しません。
まず記事とURLを確認する
管理画面で記事が公開済みか、スラッグが一致するかを確認します。
下書きや削除済みの記事は、パーマリンクの保存では公開されません。
一部の旧URLだけが404になる場合は、移行前後のURL対応とリダイレクトを確認してください。
構造を変えずパーマリンク設定を保存する
複数の個別記事で404が起き、記事自体は存在する場合の手順です。
現在のパーマリンク設定を記録し、.htaccessを使う環境では既存ファイル全体をバックアップします。
独自の転送やアクセス制限が含まれる場合もあるため、ファイル全体を汎用の設定例で置き換えないでください。
「設定 → パーマリンク」で構造を変えず、「変更を保存」を一度押します。
URL構造を変更すると、既存リンクに影響します。
上の画像は旧版の管理画面です。
表示される項目はWordPressや環境によって異なります。
ApacheとNginxで対応が異なる
Apacheで.htaccessを利用する構成では、WordPressがファイルへ書き込めることと、Apacheがそのルールを適用することを分けて確認します。
書き込みできない場合は管理画面の案内とサーバーの権限を確認します。
書き込めても、ApacheのAllowOverrideやAllowOverrideListなどで必要な指令が許可されていなければ、期待どおりには適用されません。
判断できない場合は、対象URL・発生時刻・保存後の結果を添えてホスティング事業者へ確認してください。
適用条件はApache公式の.htaccess解説を参照できます。
Nginxは.htaccessを使わないため、サーバー側の設定確認が必要です。
毎アクセス時にflush_rewrite_rules()を実行するコードは追加しないでください。
直ったか確認し、悪化したら戻す
記事URLを再表示し、正しい本文が表示されHTTPステータスが200か確認します。
直らない場合は設置ディレクトリ、サーバーの書き換え設定、キャッシュを順に確認します。
500エラーなど悪化した場合は、変更前に保存した設定へ戻します。
本番で原因を特定できない場合は複製環境で切り分けてください。
関連：移転時のリダイレクト設定。
仕様の参照：WordPress公式パーマリンク解説。
書き換えルールが原因の場合を隔離環境で確認する
2026年10月3日、隔離したApache 2.4.69・PHP CGI 8.2.29・WordPress 7.1.2で、試験用の公開記事とWordPress内部の書き換えルールを使いました。
Apacheの入口ルールがある状態では、記事のURLで200と本文を取得できました。
入口ルールだけを外すと同じURLが404になり、保存したルールへ戻すと200と本文が復旧しました。
ルールを外した状態で投稿IDのクエリ形式を開くと、WordPressから通常のパーマリンクへ301転送されました。
その入口が404のままなら、転送先でも表示できません。
PHPへ到達できたことと、最終的に本文を表示できたことを分けて確認してください。
存在しない記事のURLは、ルールを戻しても404でした。
今回の結果は入口の書き換えが原因の場合の切り分けです。
管理画面の「変更を保存」の操作、.htaccessへ書けないサーバーの権限変更、Nginx、CDNでの復旧は試験に含みません。
よくある質問：WordPressで「ページが見つかりませんでした。」と表示されるとき
公開済みの記事が404になるのは、どんな原因ですか？
記事では、URLの誤り、非公開・削除、書き換えルール、移行先の設定などです。WordPressの書き換えルールを再生成することで直る場合がありますが、サーバー側の適用条件に問題があれば、保存だけでは復旧しません。
まず何を確認しますか？
記事では、管理画面で記事が公開済みか、スラッグが一致するかを確認します。下書きや削除済みの記事は、パーマリンクの保存では公開されません。一部の旧URLだけが404になる場合は、移行前後のURL対応とリダイレクトを確認します。
パーマリンク設定の保存は、どんなときに試しますか？
記事では、複数の個別記事で404が起き、記事自体は存在する場合の手順です。現在のパーマリンク設定を記録し、.htaccessを使う環境では既存ファイル全体をバックアップしたうえで、「設定 → パーマリンク」で構造を変えず「変更を保存」を一度押します。URL構造を変更すると既存リンクに影響します。
.htaccessは、汎用の設定例で置き換えてよいですか？
置き換えないでください。記事では、独自の転送やアクセス制限が含まれる場合もあるため、ファイル全体を汎用の設定例で置き換えないとしています。
ApacheとNginxで、対応は違いますか？
違います。記事では、Apacheで.htaccessを利用する構成では、WordPressがファイルへ書き込めることと、Apacheがそのルールを適用することを分けて確認します。書き込めても、AllowOverrideなどで必要な指令が許可されていなければ期待どおりには適用されません。Nginxは.htaccessを使わないため、サーバー側の設定確認が必要です。
判断できないときは、どうしますか？
記事では、対象URL・発生時刻・保存後の結果を添えてホスティング事業者へ確認します。
直ったかどうかは、どう確認しますか？
記事では、記事URLを再表示し、正しい本文が表示されHTTPステータスが200か確認します。直らない場合は設置ディレクトリ、サーバーの書き換え設定、キャッシュを順に確認します。500エラーなど悪化した場合は、変更前に保存した設定へ戻します。
アクセスのたびに、書き換えルールを再生成するコードを入れてもよいですか？
入れないでください。記事では、毎アクセス時にflush_rewrite_rules()を実行するコードは追加しないとしています。なお、記事の隔離環境での確認は入口の書き換えが原因の場合の切り分けで、管理画面の「変更を保存」の操作、.htaccessへ書けないサーバーの権限変更、Nginx、CDNでの復旧は試験に含みません。
