WordPressのREST APIが突然404になるとき｜管理画面をサブドメインへ移した後に残る古い接続先と、認証を疑う前に確かめる順番
WordPressのREST APIが突然404になるとき｜管理画面をサブドメインへ移した後に残る古い接続先と、認証を疑う前に確かめる順番
昨日まで動いていた自動投稿や外部連携が、ある日 404 を返すようになった。管理画面には今までどおりログインできるし、記事も書ける。それなのに /wp-json/ だけが見つからないと言われる。WordPressの置き場所をサブドメインへ移した、表側を静的サイトやヘッドレス構成に切り替えた、という作業の後によく出る症状です。
結論から書きます。REST APIが404のとき、最初に見るのはパスワードでも権限でもなく「その404を返しているのは誰か」です。 確かめる順番は次の3つです。
- 404の本文がJSONか、HTMLかを見る（WordPressまで届いているかどうかが1回で分かる）
- 現在の正しい接続先を、WordPress自身に答えさせる
- 旧URLを転送で救おうとせず、接続元の設定を全部洗い出して書き換える
404は「宛先にその資源がない」という応答で、認証より手前の話です。アプリケーションパスワードを作り直しても、ユーザー権限を上げても、宛先が違う限り結果は変わりません。認証の問題は 401 や 403 として現れます（401の切り分けはアプリケーションパスワードで401になる原因にまとめています）。
まず切り分ける：その404はWordPressが返しているか
REST APIの404には2種類あります。HTTPステータスの数字は同じでも、直す場所がまったく違います。ステータスコードだけで判断せず、レスポンスの本文と Content-Type を必ず出力します。
| 本文の形 | 何が起きているか | 直す場所 |
|---|---|---|
JSONで "code":"rest_no_route" |
リクエストはWordPressに届いている。そのルート（パス）が存在しない | エンドポイントのつづり、プラグインの有効化、バージョン（wp/v2）の指定 |
| HTML（サイトの「ページが見つかりません」） | リクエストがWordPressに届いていない。Webサーバーか、表側のサイトが404を返している | 接続先のホスト名とパス、パーマリンク設定、.htaccess |
確認は1行で済みます。
curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/wp/wp-json/404 application/json ならWordPressの中の話、404 text/html ならWordPressの外の話です。移設の後に出る404は、ほぼ後者です。 この時点で、認証情報を触る理由はなくなります。
実例：管理画面は開くのに、RESTだけが404だった
自社サイトでの実測です。このサイトは、もともと本体ドメインの /wp/ というディレクトリにWordPressを置いていました。表側を静的サイト生成（Astro）に切り替えた際、WordPressは記事の入力専用として cms. のサブドメインへ移しています。
切替から1か月半ほど経って、記事タイトルを調べるために手元の作業メモにあった接続先へリクエストを送ったところ、404が返りました。そのとき実測した結果が次の表です（2026年9月時点）。
| 送った先 | 応答 | 本文 |
|---|---|---|
旧 /wp/wp-admin/ |
301 → 新サブドメインの管理画面 | — |
旧 /wp/wp-login.php |
301 → 新サブドメインのログイン画面 | — |
旧 /wp/wp-json/ |
404 | text/html（表側サイトの404ページ） |
新 cms. の /wp-json/ |
200 | application/json |
新 cms. の /wp-json/wp/v2/users/me（同じアプリケーションパスワード） |
200 | 認証成立 |
ここに、この症状が分かりにくい理由が全部入っています。
管理画面は旧URLでも開けてしまう。 切替時の .htaccess では、ブックマークから来る人のために管理画面とログイン画面を新サブドメインへ転送していました。ブラウザで旧URLを開けば何事もなく新しい管理画面に着くので、人間は「URLが変わった」ことを意識しません。一方、RESTのパスは転送の対象に入れていませんでした（理由は後述します）。結果として、人が使う入口は生きていて、プログラムが使う入口だけが消えている状態になります。
404の本文は、表側サイトの404ページだった。 返ってきたのはJSONではなく、静的サイトの「ページが見つかりません」のHTMLです。先の表のとおり、これは「WordPressに届いていない」という意味で、宛先違いだとここで確定できます。
認証情報は何も変える必要がなかった。 アプリケーションパスワードはデータベースのユーザー情報に保存されます。データベースごとコピーして移したWordPressでは、旧環境で発行したものが新しい接続先でそのまま通ります。直すのは接続先の1行だけでした。
なお、このサイトでは過去に、旧接続先に対する 401 の調査記録が「未解決」のまま残っていました。移設後は、その記録のとおりに調べても何も解決しません。旧パスへ送っている限り、サーバー設定をどう直しても応答は変わらないからです。症状が出たら、原因を調べ始める前に「いま調べている宛先は現役か」を確かめる。これが切り分けの最初に来る理由です。
現在の正しい接続先は、WordPress自身に聞く
「新しい接続先はどこか」を、人の記憶や古い資料から探す必要はありません。WordPressは自分のREST APIの場所を公開しています。
方法1：レスポンスヘッダを見る。 現在の管理画面と同じホストのトップページに対してヘッダだけを取得します。
curl -sI https://cms.example.com/ | grep -i "^link"Link: <https://cms.example.com/wp-json/>; rel="https://api.w.org/" という行が返れば、それがREST APIの入口です。HTMLの <head> にも同じ内容の <link rel="https://api.w.org/"> が出力されます。
方法2：?rest_route=/ で試す。 パーマリンク設定や .htaccess の書き換えルールが効いていない環境では、/wp-json/ という「きれいなURL」が解決されず、WordPress本体が正しい場所にあっても404になります。
curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://cms.example.com/?rest_route=/"これが 200 application/json で、/wp-json/ が404なら、場所は合っていて書き換えルールだけが効いていません。管理画面の「設定→パーマリンク」で何も変えずに保存し直すと、.htaccess が再生成されて直ることが多い形です。移設でファイルだけをコピーし、.htaccess を持っていかなかったときに起きます。
方法3：疎通は認証つきの軽いエンドポイントで確認する。 接続先が分かったら、記事の投稿ではなく GET /wp-json/wp/v2/users/me?context=edit で確かめます。これが200なら、接続先も認証も揃っています。
旧URLからの転送で済ませず、接続元を書き換える
「管理画面と同じように、旧 /wp-json/ も新しい場所へ301で転送すればよいのでは」と考えたくなりますが、REST APIではこれを恒久対応にしないほうが安全です。理由は2つあります。
- 転送をまたぐと認証ヘッダが落ちる。 curlやPythonの主要なHTTPライブラリは、別ホストへの転送を追うときに
Authorizationヘッダを付け直しません。認証情報を意図しない相手へ送らないための仕様です。つまり転送した先で、今度は401になります - POSTがGETに変わることがある。 301・302の転送では、多くのクライアントが転送後のリクエストをGETに変えます。記事の投稿（POST）のつもりが記事一覧の取得（GET）になり、エラーにならずに「何も投稿されない」という、さらに見つけにくい症状に変わります
読み取り専用の取得だけなら転送でも動きますが、書き込みがある連携は接続元の設定を直すのが正しい対処です。自社の切替で、記事URLや管理画面は転送の対象にし、RESTのパスは対象から外したのもこのためです。転送で動いているように見せるより、404で止まって気づけるほうが、壊れ方として安全だと判断しました。
古い接続先が残りやすい7か所
移設のときに直すべき接続先は、1か所ではありません。次の7か所を、旧ホスト名と旧パス（例：/wp/wp-json）で検索して洗い出します。
| 場所 | 残りやすい理由 |
|---|---|
①自動投稿・連携スクリプトの設定ファイル（.env・設定JSON） |
動いているものは最初に直すので、ここは直っていることが多い。逆に「ここを直したから終わり」と思い込みやすい |
| ②サイト生成のビルド設定（CIの環境変数・シークレット） | リポジトリの外に保存されていて、検索に掛からない |
| ③定期実行（cron・スケジューラ・GASのスクリプトプロパティ） | 月1回・週1回しか動かないものは、壊れても次の実行日まで分からない |
| ④フォームの送信先 | 問い合わせフォームがWordPressのプラグインのRESTエンドポイントへ直接送信している場合、URLがページのHTMLやJavaScriptに直書きされている |
| ⑤外部の自動化サービス・予約投稿ツール | 管理画面が自社の外にあり、担当者しか場所を知らない |
| ⑥表側のJavaScript | 「最新記事3件」の取得などでRESTのURLを直接持っている |
| ⑦手順書・引き継ぎ資料・作業メモ | プログラムではないので誰も直さない。次に手作業をする人が、資料のとおりに古い宛先へ送る |
自社の例で実際に残っていたのは⑦でした。自動投稿の設定ファイルは切替当日に新しい接続先へ書き換え、変更の理由と日付も書き添えてあったので、毎日の投稿は止まっていません。一方で、移設の経緯を書いた資料とは別の、ブログ運用の資料に旧接続先が残っていました。移設のような土台の変更は、その作業の記録1か所に書いて終わりにせず、関係する資料をすべて検索して同じ日に直す。直すときは古い記述を消さずに「訂正」として上に書き足すと、後から経緯を追えます。
④も同じ切替で確認した項目です。このサイトのサービス紹介ページのフォームは、旧 /wp/ 側のフォームプラグインのエンドポイントへ直接送信する作りになっていました。フォームは送信エラーが訪問者の画面にしか出ないため、運営側は問い合わせが来ないことでしか気づけません。移設の検証項目に「フォームの実送信と受信確認」を必ず入れるのは、この見えにくさのためです。リンク先や構造化データに残る旧URLの洗い出しはリンク先を変えたのに旧URLが残る場所で扱っています。
起こりうる失敗と、その予防
| 起こりうること | 予防 |
|---|---|
| 404を見て、アプリケーションパスワードを再発行する | 本文がJSONかHTMLかを先に見る。HTMLなら認証は無関係。再発行すると、正しく動いていた別の連携まで止まる |
旧 /wp-json/ を301で転送して解決したことにする |
転送先で認証ヘッダが落ちる・POSTがGETに変わる。書き込みのある連携は接続元を直す |
| 旧環境のWordPressを残したままにして、古い接続先が「動いてしまう」 | 旧側に投稿され続け、新側には何も入らない。移設後は旧側のRESTが応答しないことまで確認する。使わないWordPressを残す危険は別の面でも大きい |
| 月次の定期実行だけが古い接続先のまま | 移設の翌日ではなく、全部の定期実行が1巡する日に結果を確認する予定を入れる |
| 接続確認を記事の投稿で行う | 失敗の理由が混ざる。users/me のような軽い取得で確かめる |
移設の日に済ませるチェックリスト
- 旧ホスト名・旧パスで、リポジトリ、サーバー上のファイル、資料フォルダを全文検索する
- リポジトリの外にある設定（CIのシークレット、スケジューラ、外部サービス、GASのプロパティ）を一覧にして1件ずつ開く
- 新しい接続先に対して
/wp-json/（200・JSON）とusers/me（200）を確認する - 旧接続先に対して、期待どおりの応答（404、または意図した転送）になっているかを確認する
- フォームを実際に送信し、メールの受信まで確認する
- 手順書・引き継ぎ資料の接続先を書き換え、変更日と理由を書き添える
- 定期実行が1巡する日に、実行結果を確認する予定を入れる
よくある質問
Q. 管理画面にはログインできます。それでも接続先が違うことはありますか
あります。管理画面やログイン画面は旧URLから転送されていることが多く、ブラウザのアドレスバーを見ると別のホスト名に変わっています。ログイン後のアドレスバーのホスト名が、REST APIの接続先のホスト名です。
Q. 移設していないのに、ある日から404になりました
本文がHTMLなら、.htaccess の上書きやパーマリンク設定の初期化を疑います。?rest_route=/ が200なら書き換えルールの問題です。本文がJSONの rest_no_route なら、そのルートを提供していたプラグインの停止や更新を確認します。セキュリティ系のプラグインやサーバーの機能がREST APIを制限している場合は、404ではなく 401 や 403 で返る設定が多いため、ステータスと本文の組み合わせで見分けます。
Q. アプリケーションパスワードは移設後に作り直すべきですか
データベースごと移したなら、そのまま使えます。作り直す必要があるのは、漏えいの疑いがあるときや、担当者が変わったときです。404の対処としては意味がありません。
まとめ
- REST APIの404は、本文がJSONかHTMLかを最初に見る。HTMLならWordPressに届いておらず、認証は無関係
- 現在の接続先は、
Linkヘッダのrel="https://api.w.org/"と?rest_route=/でWordPress自身に確認する - 旧URLからの転送は、認証ヘッダの脱落とPOSTのGET化があるため、書き込みのある連携では恒久対応にしない
- 古い接続先は、設定ファイルよりもリポジトリの外の設定・フォームの送信先・手順書に残る
- 移設の確認は当日だけで終えず、定期実行が1巡する日にもう一度行う
WordPressの置き場所を変える作業は、表に見えるページの転送だけを確認して終わりになりがちです。サイトの切替や、切替後に動かなくなった連携の調査でお困りでしたら、お問い合わせからご相談ください。