WordPress REST APIエラーの原因と直し方|403・404・500・サイトヘルスの対処手順

WordPress REST APIエラーの原因と403・404・500エラーの対処法を示すアイキャッチ

WordPressで「REST APIでエラーが発生しました」と表示されたり、記事の保存時に「更新に失敗しました」と出たりする場合、WordPressとサーバーの通信が正常に行われていない可能性があります。

原因はパーマリンク設定、セキュリティ機能、プラグインの競合、サーバーの接続障害などさまざまです。まずエラーの発生場所とHTTPステータスコードを確認し、影響の少ない対処から順番に試すことが解決への近道です。

この記事では、WordPress REST APIエラーの確認方法から、403・404・500エラーなどの症状別の対処手順まで解説します。

 

目次

WordPress REST APIエラーが出たら最初に確認すること

REST APIエラーが発生しても、すぐにWordPressを再インストールしたり、プラグインをすべて削除したりする必要はありません。

最初にエラーの詳細を確認し、問題が発生している通信を特定してください。

  1. WordPress管理画面の「ツール」→「サイトヘルス」を開きます。
  2. 「ステータス」にREST API関連の警告があるか確認します。
  3. 警告の詳細を開き、REST APIエンドポイント(通信先URL)とレスポンス(サーバーからの応答)を控えます。
  4. 別のタブで、サイトURLの末尾に「/wp-json/」を付けてアクセスします。
  5. 表示結果とエラーコードを確認し、以下の対処手順へ進みます。

例として、サイトURLが「https://example.com/」の場合、確認先は次のとおりです。

https://example.com/wp-json/

正常にアクセスできる環境では、利用可能なREST APIのルート情報などがJSON形式(データを構造化して表す形式)で表示されます。

ただし、このURLが正常に表示されても、ログインが必要なAPIや記事保存機能まで正常とは限りません。公開APIの確認と管理画面内の認証付き通信は区別してください。

なお、WordPressをサブディレクトリへ設置している場合やURL構成を変更している場合は、実際のREST API URLが異なることがあります。

サイトヘルス全般の確認方法は、WordPressサイトヘルスの改善方法も参考になります。

 

REST APIのエラーコード別・原因と対処法一覧

REST APIエラーは、表示されたHTTPステータスコード(通信結果を示す3桁の番号)によって確認すべき箇所が異なります。

まずは次の表で、ご自身の症状に近い項目を確認してください。

エラー・症状 主な確認対象 最初の対処
401 Unauthorized ログイン状態・認証情報 再ログインして再試行
403 Forbidden アクセス権限・WAF・セキュリティ設定 通信先とブロック履歴を確認
404 Not Found URL・パーマリンク・リライトルール パーマリンク設定を再保存
500 Internal Server Error PHP・プラグイン・サーバー内部処理 エラーログを確認
502・503・504 サーバー・プロキシ・応答遅延 障害情報とサーバーログを確認
cURL error 6 DNS・ホスト名解決 ドメインの名前解決を確認
cURL error 7 接続先・ポート・ネットワーク 接続経路とサーバー設定を確認
cURL error 28 通信タイムアウト 接続遅延や遮断を調査
Too many redirects HTTPS・転送設定 リダイレクト設定を確認
rest_cookie_invalid_nonce 認証用nonce・キャッシュ 再ログインとキャッシュ確認

これらは原因を特定するための目安です。同じ403エラーでも、WordPress側の権限不足とサーバー側のアクセス遮断では対処方法が異なります。

HTTPステータスコードの意味を詳しく確認したい場合は、HTTPステータスコード一覧と意味も参考になります。

REST APIの401・403・404・500とcURLエラーの確認対象を分類した図

 

WordPress REST APIとは?エラーで影響する機能

REST API(HTTP通信を利用してアプリケーション間でデータをやり取りする仕組み)は、WordPressの投稿や設定などを外部アプリケーションや管理画面の機能から操作するために利用されています。

WordPressのブロックエディターもREST APIを使用する機能の一つです。

そのため、REST APIの通信に問題があると、次のような症状が発生する場合があります。

  • 投稿や固定ページの保存・更新に失敗する
  • ブロックエディターが正常に読み込まれない
  • サイトヘルスにREST API関連の警告が表示される
  • REST APIを利用するプラグインや外部連携が動作しない
  • 一部の管理画面機能でデータの取得に失敗する

ただし、REST APIの一部のルートだけでエラーが発生している場合、サイト全体が停止するとは限りません。

「REST API全体が使えない」のか、「特定の機能やエンドポイントだけ失敗している」のかを区別することが重要です。

 

REST APIへアクセスすると404 Not Foundが返される場合、URLの誤りやリライトルール(アクセスURLをWordPress内部の処理先へ振り分ける規則)に問題がないか確認します。

 

パーマリンク設定を保存し直す

  1. WordPress管理画面で「設定」→「パーマリンク」を開きます。
  2. 現在の設定を確認します。
  3. 設定値を変更せずに「変更を保存」をクリックします。
  4. 再度REST API URLへアクセスし、エラーが改善したか確認します。

この操作によって、WordPressのリライトルールが更新され、URLの振り分けに関する問題が解消する場合があります。

ただし、すべての404エラーがこの操作で解決するわけではありません。

 

通常のREST API URLと代替URLを比較する

標準的なURL構成のサイトでは、次の2つを比較することで、URL書き換え設定の問題を切り分けられる場合があります。

https://example.com/wp-json/
https://example.com/?rest_route=/

後者だけが正常に表示される場合は、WebサーバーのURL書き換え設定に問題がある可能性があります。

Apacheでは.htaccess、Nginxではサーバー設定などが確認対象になります。ただし、利用しているサーバー構成によって異なります。

.htaccessやWebサーバー設定を直接変更する前に、必ず元の内容を保存してください。 設定を誤ると、REST APIだけでなくサイト全体のURLが正常に動作しなくなる可能性があります。

なお、REST APIの一部のURLが404になる場合は、そのルートを提供するプラグインが停止している、または対象ルートが登録されていない可能性もあります。

 

403・401エラーは認証とセキュリティ設定を確認する

403エラーや401エラーが発生する場合は、アクセス権限と認証状態を優先して確認します。

 

ログイン状態と操作権限を確認する

投稿の編集・更新などには、適切なユーザー権限が必要です。

  1. 管理画面から一度ログアウトします。
  2. 再ログインして同じ操作を試します。
  3. 問題が発生する操作に必要な権限を持つユーザーか確認します。
  4. ブラウザーの開発者ツールで、失敗したAPIのレスポンスを確認します。

レスポンスに「rest_forbidden」などのエラーコードが含まれる場合は、対象操作に必要な権限が不足している可能性があります。

一方、「rest_cookie_invalid_nonce」などが表示される場合は、nonce(リクエストの正当性を確認するための値)が無効になっている可能性があります。

この場合、再ログインやページの再読み込みで改善することがあります。キャッシュが古い認証関連情報を返していないかも確認してください。

 

WAFによるアクセス遮断を確認する

WAF(Webアプリケーションへの不正な通信を検知・遮断する仕組み)がREST APIへのリクエストを遮断している場合があります。

レンタルサーバーやCDN(コンテンツ配信・通信中継の仕組み)の管理画面にあるセキュリティログを確認してください。

失敗したリクエストの時刻、アクセス先URL、遮断ルールを照合すると、WAFが関係しているか判断しやすくなります。

遮断が確認できた場合は、問題の通信に限定した例外設定を検討してください。

原因を確認せずWAFを恒久的に無効化したり、/wp-json/配下を一律に許可したりすることは避けてください。

セキュリティ上のリスクがあるため、必要に応じてサーバー事業者へ相談することをおすすめします。

 

プラグインやテーマの競合を切り分ける

REST APIエラーがプラグインの更新やテーマ変更後に発生した場合は、変更した機能との関連を調べます。

セキュリティ系、キャッシュ系、認証系、URL変更系のプラグインは確認対象になり得ますが、プラグインの種類だけで原因を断定することはできません。

 

安全にプラグインを確認する手順

  1. サイト全体とデータベースのバックアップを取得します。
  2. 直前に更新・追加・設定変更したプラグインを確認します。
  3. 可能であればステージング環境(公開サイトとは別の検証用環境)で再現します。
  4. 疑わしいプラグインを一時停止してREST APIの動作を確認します。
  5. 改善した場合は、該当プラグインの設定や更新履歴を調査します。
  6. 検証後は必要な機能を戻し、サイト全体の動作を確認します。

複数のプラグインを同時に停止すると、どの変更が改善につながったか分かりにくくなります。可能な限り変更を一つずつ行ってください。

ECサイト、会員サイト、予約サイトなどでは、一時停止によって購入・ログイン・予約機能に影響する場合があります。公開環境での停止操作は慎重に行ってください。

 

テーマが原因か確認する

テーマ内のfunctions.phpなどに追加した独自コードが、REST APIの認証・権限・レスポンスを変更している場合もあります。

最近コードを追加した場合は、その変更内容を確認してください。

テーマの切り替えが必要な場合も、先にステージング環境で検証することをおすすめします。

独自コードの編集後にサイトが動かなくなった場合は、functions.phpの編集エラーから復旧する方法も参考になります。

また、プラグインの影響で管理画面へ入れない場合は、レンタルサーバーからWordPressプラグインを削除・停止する方法を確認してください。

 

500エラー・cURLエラーはサーバー側を調べる

REST APIの通信で500エラーやcURLエラーが発生する場合、WordPressの設定だけでは解決できないことがあります。

 

500 Internal Server Errorの確認方法

500エラーは、サーバー内部でリクエストの処理に失敗したことを示します。

原因を特定するために、次の情報を確認してください。

  • エラー発生時刻
  • 失敗したREST APIのURL
  • サーバーのPHPエラーログ
  • 直前のプラグイン・テーマ・PHP設定の変更
  • サーバーのリソース制限や障害情報

PHP(WordPressの主要な処理を実行するプログラミング言語)のエラーが発生している場合、ログから原因となるファイルや処理を特定できることがあります。

WordPressのデバッグログを利用する場合は、公開画面へエラーを表示しない設定とし、ログへの第三者アクセスを防いでください。

エラーログにはサーバーの内部パスや機密情報が含まれる場合があるため、そのまま公開しないでください。

 

cURL error 6・7・28の違い

cURL(サーバーからHTTP通信などを行うための仕組み)に関連するエラーでは、番号ごとに確認対象が異なります。

  • cURL error 6:接続先ホスト名を解決できない状態です。DNS(ドメイン名を接続先の情報へ変換する仕組み)やサーバーの名前解決を確認します。
  • cURL error 7:接続先へ接続できない状態です。接続先アドレス、ポート、ファイアウォールなどを確認します。
  • cURL error 28:通信が制限時間内に完了しなかった状態です。ネットワークの遅延、遮断、サーバー負荷などを調査します。

サイトヘルスのREST APIテストでは、WordPressサーバー自身がサイトのURLへHTTPリクエストを送るため、外部のブラウザーからサイトを開けても、サーバー内部からの通信だけが失敗する場合があります。

このようなケースでは、サーバー事業者へ次の情報を伝えると調査を依頼しやすくなります。

  • 発生日時とタイムゾーン
  • サイトヘルスに表示されたエラー全文
  • REST APIエンドポイントのURL
  • HTTPステータスコードまたはcURLエラー番号
  • 直前に行った設定変更
  • ブラウザーからのアクセス結果

サーバー側の通信制御が原因の場合、WordPressの再インストールでは改善しない可能性があります。

 

リダイレクトエラーとHTTPS設定を確認する

REST APIの通信で「Too many redirects」などが表示される場合、リダイレクト(別のURLへ自動転送する処理)が繰り返されている可能性があります。

主に次の設定を確認します。

  • WordPressアドレスとサイトアドレス
  • HTTPからHTTPSへの転送設定
  • wwwあり・なしの統一設定
  • CDNやリバースプロキシのHTTPS設定
  • URL変更系プラグインの転送ルール

WordPress管理画面の「設定」→「一般」で確認できるURLと、実際にアクセスするURLが意図した構成になっているか調べてください。

ただし、WordPressの設定ファイルでURLが固定されている場合など、管理画面から変更できない環境もあります。

原因を特定する前にサイトURLを書き換えると、管理画面へアクセスできなくなる可能性があります。

特にCDNやプロキシを利用している場合は、HTTPSの終端位置や転送ルールを含めて確認してください。

 

記事の保存・更新に失敗するときの確認方法

ブロックエディターで「更新に失敗しました」「返答が正しいJSONレスポンスではありません」などと表示される場合、REST API通信の失敗が関係していることがあります。

ただし、JSONエラーの表示だけでREST APIの特定の原因を確定することはできません。

 

ブラウザーの開発者ツールで失敗した通信を確認する

  1. 保存前に編集中の文章を別の場所へコピーして保護します。
  2. ブラウザーの開発者ツールを開きます。
  3. 「Network(ネットワーク)」を選びます。
  4. 必要に応じて「Fetch/XHR」で通信を絞り込みます。
  5. 記事の保存・更新を再試行します。
  6. 失敗したリクエストのURL、ステータスコード、レスポンスを確認します。

ChromeやEdgeでは、通常F12キーなどで開発者ツールを開けます。画面や項目名はブラウザーのバージョンによって異なります。

失敗した通信が「/wp-json/wp/v2/」配下などであれば、REST APIの応答内容を調べてください。

レスポンスがHTMLのエラーページになっている場合は、WordPress本体のJSON応答に到達する前に、サーバーやセキュリティ機能がエラーを返している可能性もあります。

ブラウザーのNetworkパネルでREST APIの通信URL、ステータスコード、レスポンスを確認する図

 

保存できない場合の安全な対処

まずは本文を保護したうえで、再ログイン、ページの再読み込み、ブラウザー拡張機能の影響確認など、元に戻しやすい操作から試してください。

キャッシュの削除が必要な場合も、管理画面の認証付き通信を誤ってキャッシュしていないか確認することが重要です。

保存失敗の原因を確認する前に、未保存の本文を失う操作をしないでください。

 

サイトヘルスだけにREST APIの警告が出る場合

記事の編集やサイト表示は正常なのに、サイトヘルスだけでREST APIの警告が表示されるケースもあります。

この場合、サイトヘルスが実施する認証付きREST APIテストの結果を確認してください。

WordPressのサイトヘルスでは、投稿タイプ情報を取得するREST APIエンドポイントに対して、編集コンテキストを指定した通信を行う処理があります。

代表的な形式は次のとおりです。

/wp-json/wp/v2/types/post?context=edit

この通信は認証状態や権限の影響を受けるため、公開REST APIのトップページが正常に表示されても、サイトヘルスのテストだけ失敗することがあります。

サイトヘルスの警告詳細に表示されたURLとレスポンスを確認し、原因を切り分けてください。

また、PHPセッションが適切に閉じられていない場合、REST APIやループバックリクエスト(サーバーが自分自身へ送る通信)へ影響することがあります。

「アクティブなPHPセッションが検出されました」と併せて表示される場合は、プラグインや独自コードによるセッション処理も調査対象です。

警告が表示されているだけで、サイト全体が故障していると判断する必要はありません。 一方、現在動作している機能が正常だからといって、警告を無条件に放置することも避けてください。

 

REST APIエラーの対処で避けたい操作

REST APIエラーは設定変更によって改善することがありますが、誤った対処によって別の問題が発生する可能性もあります。

特に次の操作には注意してください。

  • REST APIを全面的に無効化する:ブロックエディターや外部連携などの機能に影響する場合があります。
  • WAFを無期限に停止する:本来遮断すべき不正な通信まで許可する危険があります。
  • 認証や権限チェックを解除する:非公開情報の取得や不正な操作を許す可能性があります。
  • SSL証明書の検証を無効化する:通信相手の正当性を確認できなくなるため、恒久的な解決策として採用しないでください。
  • バックアップなしで設定ファイルを編集する:管理画面や公開サイトへアクセスできなくなる可能性があります。
  • 原因不明のままWordPressを再インストールする:問題を解決できないうえに、既存データや設定へ影響するおそれがあります。

設定を変更する場合は、変更前の値、変更した日時、確認結果を記録しておくと、問題が悪化した際に元へ戻しやすくなります。

 

WordPress REST APIエラーのよくある質問

REST APIの警告が出ても記事は公開できますか?

問題が発生しているエンドポイントや機能によって異なります。REST APIの一部だけが失敗している場合、記事公開機能が正常に動作することもあります。

ただし、保存・更新処理に影響している場合は、公開操作に失敗する可能性があります。警告の内容と実際の動作を確認してください。

 

REST APIの/wp-json/を無効にすればエラーは消えますか?

REST APIを無効にすることは、通信障害の根本原因を修正する方法ではありません。

WordPress本体やプラグインの機能へ影響する可能性があるため、エラーを隠す目的での全面無効化はおすすめできません。

 

パーマリンクを保存しても直らない場合は?

通常URLとrest_route形式のURLを比較し、リライトルールの問題か、それ以外の通信障害かを切り分けてください。

403であれば権限やWAF、500であればサーバーログなど、実際のエラーに応じた確認へ進みます。

 

レンタルサーバーへ問い合わせるべきタイミングは?

cURLによる接続失敗、サーバー側の403・500エラー、原因不明のタイムアウトなどが継続する場合は、サーバー事業者への相談を検討してください。

エラー全文、発生日時、通信先URL、実施済みの対処をまとめると状況を伝えやすくなります。

 

まとめ|REST APIエラーは通信結果から原因を絞り込む

WordPress REST APIエラーを解決する際は、サイトヘルスや開発者ツールでエラーの内容を確認し、原因に合った対処を選ぶことが重要です。

404ならパーマリンクやURL書き換え設定、401・403なら認証やアクセス制御、500ならサーバー内部の処理を優先して調べます。

また、cURLエラーやリダイレクトエラーでは、WordPress以外のネットワーク・サーバー設定が関係している場合もあります。

設定を一度に大きく変更せず、バックアップを取得してから一つずつ検証してください。改善しない場合は、確認したエラー情報をもとにサーバー事業者やプラグイン開発元へ相談することをおすすめします。

PR記事一覧

Ads Blocker Image Powered by Code Help Pro

広告ブロックを検出しました!

ブラウザの拡張機能を使用して広告をブロックしていることが検出されました。

ブラウザの広告ブロッカーなどの機能を無効にして「更新」をクリックして下さい。

You cannot copy content of this page