記事を公開したのに個別ページが404になるとき｜一覧には出るのにURLで開けない場合の確認順

WordPressで記事を公開した直後に、こういう状態になることがあります。

• 管理画面では「公開済み」になっている
• トップページやブログ一覧には新着として表示されている
• なのに記事のURLをクリックすると「ページが見つかりません」（404）

記事が消えたわけでも、公開に失敗したわけでもありません。先に結論を書きます。

この症状の大半は、管理画面の「設定」→「パーマリンク」を開いて、何も変えずに「変更を保存」を押すだけで直ります。

かかる時間は30秒です。理由と仕組み、これで直らなかった場合に次に見る場所を、実際の運用で確認してきた順番でまとめます。ホームページを外注している経営者の方なら、制作会社に「パーマリンクの再保存は試しましたか」と一言聞けるようになるだけでも、解決までの往復が1回減ります。

なぜ「一覧には出るのに個別ページだけ404」になるのか

WordPressは、「このURLならこの記事を表示する」というURLと記事の対応表（リライトルール）を内部に保存しています。個別ページのURLが開けるかどうかは、この対応表で決まります。

一方、トップページやブログ一覧は、この対応表とは別の仕組みで記事を取り出して表示しています。だから対応表が古いままだと、一覧には出るのに、個別URLだけ解決できないという一見不思議な状態になります。「一覧に出ている＝記事は存在している」なので、消えたのではなくURLの解決だけが失敗している、と切り分けられるわけです。

この対応表は、管理画面で普通に操作しているぶんには、必要なタイミングでWordPressが自動的に作り直してくれます。ところが、次のような公開のしかたでは作り直されないことがあります。

• REST API経由で記事を公開した（自動投稿ツール・外部システム連携・AIによる記事投稿など）
• サイトを立ち上げた直後で、最初の記事をAPIから入れた
• サーバー移転や復元のあとで、対応表だけが古い状態で残った

特に注意したいのが1つ目と2つ目の組み合わせです。REST APIで記事を公開すると、APIのレスポンスは「成功」で返ってきます。投稿としては本当に成功しているのに、URLの対応表は更新されない。この仕様を知らないと、「成功と返ってきたのに404」という状況で原因探しが迷走します。

実例：立ち上げ直後のブログに5本入れたら、全件404だった

弊社で腸活サプリを扱うECクライアントのブログを立ち上げたときの実例です。デザインを整えたブログにREST APIで記事5本を一括公開したところ、APIのレスポンスは5本とも成功、一覧ページもカテゴリページも正常に表示されているのに、個別記事のURLは5本すべて404でした。

原因はまさに前述のリライトルール未更新です。立ち上げ直後のWordPressに、管理画面を経由せずAPIだけで記事を入れたため、URLの対応表が一度も作り直されていませんでした。対応表の再生成（フラッシュ）を1回実行しただけで、5本とも即座に200（正常表示)になりました。

この経験から、弊社ではAPI経由の公開処理には「公開後に全記事のURLへ実際にアクセスし、200が返ることを確認して完了とする」工程を必ず入れています。公開処理の成功と、読者がURLを開けることは別物だからです。この確認を挟んでおけば、「公開したつもりでSNSに流したリンクが全部404だった」という事態を未然に防げます。

確認手順：上から順に潰す

手順1：パーマリンク設定を再保存する

管理画面の「設定」→「パーマリンク」を開き、設定は何も変えずに「変更を保存」を押します。このボタンを押すと、WordPressはURLの対応表を作り直します。設定を変える必要はありません。保存という操作自体に再生成の効果があります。

なお、プログラム側から同じことをする関数（flush_rewrite_rules）もありますが、こちらは毎回のアクセスで実行するとサイト全体が重くなるため、実行するなら一回限りで止まる作りにするのが定石です。管理画面に入れる状況なら、ボタンを押すほうが安全で確実です。

手順2：「?p=記事ID」でアクセスして切り分ける

再保存で直らなかった場合は、記事そのものの問題か、URL解決の問題かを切り分けます。

https://あなたのドメイン/?p=123 のように、記事IDを直接指定するURLで開いてみてください（IDは記事編集画面のURLにある post=123 の数字です)。この形式のURLは対応表を使わないため、切り分けに使えます。

• ?p=IDなら開ける → 記事は正常。URL解決側（パーマリンク・.htaccess）の問題。手順3へ
• ?p=IDでも404 → 記事側の問題。公開ステータスが「公開」になっているか、公開日時が未来になっていないか（予約投稿状態）を確認

手順3：.htaccessを確認する

サーバー上の .htaccess というファイルに、# BEGIN WordPress から # END WordPress までのブロックがあるか確認します（外注している場合は制作会社への確認事項です）。このブロックが、URLをWordPressへ渡すための入口です。

ここで起きやすい事故が2つあります。どちらも実際の運用で遭遇したパターンです。

• 別システム時代の記述が残っている。静的サイトからWordPressに作り替えた案件で、旧サイト用の「全ページを特定ファイルへ転送する」記述が残っていて、下層URLが全部404になっていたことがあります。サイトをリニューアルした直後に404が出る場合は、まず前のサイトの.htaccessが残っていないかを疑ってください
• デプロイ（ファイル一括アップロード）で.htaccessが先祖返りする。ファイル一式をサーバーへ丸ごと上書きする運用にしていると、サーバー側で直した.htaccessが、次のアップロードで古いものに戻ります。この事故は起きた瞬間に気づけないのが厄介で、.htaccessはアップロード対象から除外しておくのが予防策です

なお、手順1の再保存（フラッシュ）が書き換えるのは BEGIN〜END ブロックの内側だけで、ブロックの外に書いた独自設定は保持されます。とはいえ.htaccessはサイト全体の入口なので、触る前にコピーを取っておくことは徹底してください。

手順4：日本語スラッグを疑う

スラッグ（URLの末尾部分）に日本語を使っている場合、404の原因になりやすいポイントが増えます。日本語スラッグはURL上では %e3%81%82… のようなコード（パーセントエンコード）に変換されて扱われ、この変換の扱いがサーバー設定・転送ルール・外部システムの間で食い違うと404になるからです。

実際に確認してきたパターンを2つ挙げます。

• 転送（リダイレクト）ルールに日本語スラッグを含めると、変換の食い違いで転送先が404になることがある。サーバーがURLを再変換するときの表記の差（大文字・小文字など）をWordPress側が解決できないケースです
• 記事データを外部システムへ渡すと、変換されたままのコードがファイル名やフォルダ名として使われて404になる。REST APIはスラッグを変換済みの形で返すため、受け取る側で元に戻す処理を挟まないと、%e3 で始まる名前のフォルダができてしまいます

日本語スラッグ自体が悪いわけではありませんが、転送設定や外部連携が絡むサイトでは、新規記事のスラッグは英数字（ローマ字）に統一しておくと、この種の404を最初から避けられます。

手順5：静的生成・ヘッドレス構成なら「ビルド待ち」を疑う

WordPressを記事の入稿システムとして使い、表側のサイトは別の仕組みで生成する構成（ヘッドレスCMS・静的生成）の場合、WordPress側の公開成功と、公開URLが開けることの間に時間差があります。

弊社のブログがまさにこの構成で、記事はWordPressに入稿し、表側のページは30分おきの自動ビルドで生成されます。つまり公開ボタンを押した直後は、表側のURLは404で正常です。ビルドが走った時点で200になります。

この構成で運用するなら、次の2点を仕組みに入れておくことをおすすめします。

• 「公開直後の404は異常ではない」と関係者に共有しておく（知らないと障害だと騒ぎになります）
• 公開URLを使う後続処理（SNS投稿・Googleビジネスプロフィールへの投稿・メール配信など）には、URLが200を返すことを確認してから実行するガードを入れる。弊社の自動投稿もこのガードを入れており、ビルド前の記事は次回に自動で持ち越されます

手順6：キャッシュを疑う

ここまでの対処をしたのに404のままに見える場合、直っているのに古い結果を見ている可能性があります。レンタルサーバーのキャッシュ機能が、修正前の404応答をしばらく返し続けることがあるからです。

確認するときは、URLの末尾に ?test=20260815 のような適当なパラメータを付けてアクセスしてください。キャッシュを素通りして現在の状態が見られます。ブラウザのシークレットウィンドウでの確認も有効です。「直したのに変わらない」ときは、直せていないのではなくキャッシュ越しに見ているだけ、というのは404に限らずWeb運用全般でよくある落とし穴です。

よくある質問

Q. パーマリンクの再保存で、公開中の記事やSEOに悪影響はありませんか？

設定を何も変えずに「変更を保存」を押す限り、URLは1文字も変わらないため、公開中の記事にも検索順位にも影響はありません。URLの対応表が作り直されるだけです。注意が必要なのは、このとき設定（「投稿名」「日付と投稿名」など）自体を変えてしまった場合で、全記事のURLが変わり、旧URLからの転送（301リダイレクト）を用意しないと今度は既存記事が404になります。再保存と設定変更は別物、と覚えてください。

Q. 公開済み記事の日本語スラッグを、後から英数字に変えてもいいですか？

スラッグを変えるとURLが変わるため、旧URLで張られたリンクや検索結果からのアクセスが404になります。変えるなら旧URLから新URLへの転送設定とセットで行ってください。すでに検索流入がある記事は無理に変えず、新規記事から英数字に統一していくのが、手間とリスクの少ない現実的な進め方です。

Q. 自動投稿のたびに毎回404になります。毎回フラッシュすればいいですか？

毎回フラッシュが必要になるのは別の異常のサインです。フラッシュは本来、立ち上げ直後やURL構造の変更時に1回やれば済むもので、恒常的に仕込むと処理が重く、サイト全体の速度に響きます。毎回発生する場合は、プラグインやテーマがURL構造に関わる設定を繰り返し書き換えていないかなど、フラッシュを打ち消している側の原因を特定してください。対症療法の自動フラッシュで蓋をするのは、負荷と引き換えに原因を見えなくする悪手です。

まとめ：確認順の一覧表

順番	確認すること	直るケース
1	パーマリンク設定を再保存	REST API・自動投稿経由の公開、立ち上げ直後のサイト（最多）
2	?p=記事IDで開くか	記事側（ステータス・予約投稿）とURL側の切り分け
3	.htaccessの中身	リニューアル直後・デプロイでの先祖返り
4	日本語スラッグ	転送ルール・外部連携が絡むサイト
5	ビルド待ちか	静的生成・ヘッドレス構成
6	キャッシュ	「直したのに変わらない」とき

最後にもう一度だけ。「一覧には出るのにURLで開けない」は、記事が消えたのではなくURLの対応表が古いだけというケースが大半です。まずパーマリンクの再保存。それで直らなければ、この表の順番で上から潰していけば、原因は必ずこのどれかに行き着きます。

また、REST APIで記事公開を自動化する場合は、「公開後に本番URLの200を確認する」工程まで含めて自動化してください。公開処理の成功は、読者がその記事を読めることを保証しません。最後の一歩を確認する仕組みが、公開したつもりの404を防ぎます。