ページが一時的に移動すると、HTTP 303ステータスコードが返されます。そして、サーバーは要求されたリソースに接続することができず、別のページにリダイレクトされることに。これは面倒なだけでなく、リダイレクトループやキャッシュの問題など、他のエラーにつながりかねません。

「HTTP 303 See Other」ステータスコードの解決は、原因が特定できればその解決方法はシンプル。サーバーの設定を確認したり、WordPressのデバッグモードでエラーログを確認したりすることで解決可能です。

今回は、HTTP 303ステータスコードについて詳しく見ていきます。主な原因を押さえて、素早く解決しましょう！

HTTP 303ステータスコードとは

HTTP 303ステータスコードは、リダイレクトが最近転送されたリソースに接続されないことを意味し、転送ページのような別ページに接続されます。

このエラーメッセージは、サーバーがブラウザに、ページが一時的に移動したことを伝えるもの。サーバーはHTTPリクエストのデータを正常に受信し、別のURLに対して新たにGETリクエストを送信しなければなりません。

「HTTP 303 See Other」のメッセージは、PUTまたはPOSTリクエストの結果として見られるのが一般的ですが、時にDELETEによっても発生することがあります。ブラウザは新たなページを表示することでコードを処理するため、WordPressでは自動的にリダイレクトされます。

しかし、このステータスコードが別の問題を引き起こす可能性も。

  • リダイレクトループ（無限ループ）の発生─各ページがユーザーを元のリソースに戻すリダイレクトを行う場合に発生することがあります。
  • キャッシュプロキシがリソースをキャッシュするのが困難─プロキシは、200のステータスコードで返されたリソースのみをキャッシュするのが一般的です。
  • 帯域幅の消費量の増加やパフォーマンスの低下─303のリソースがキャッシュされていない場合に発生することがあります。

また、303ステータスコードは、他のHTTPステータスコードと異なる動作を見せることを念頭に置いてください。例えば、HTTP 301ステータスコードもリダイレクトメッセージを表示しますが、ページが恒久的に移動された場合のみに見られます。

303に近いステータスコードであるHTTP 302ステータスコードは、一時的な移動を意味します。

HTTP 304ステータスコードは、対象のリソースが変更されていないことを意味し、このメッセージが表示されたら、複製を保持するのがベストプラクティスです。

HTTP 303ステータスコードの原因

HTTP 303ステータスコードは、単にクライアントのリクエストの結果を示すもの。多くのユーザーはこれを「エラー」と認識しがちですが、実際には、単にサーバーが別の場所にリダイレクトしていることを示すメッセージです。

HTTP 303ステータスコードに遭遇する主な原因は、以下の通り。

  • リソースが別の場所に移動した：別のURLに移動したなど。
  • リソースへのアクセス方法が変更された：容易にアクセスできなくなった、または一般公開されなくなった可能性があります。
  • サーバーの設定に誤りがある：よく見られる原因。
  • アプリケーションに問題ある：クライアントアプリケーションにメッセージをトリガーするカスタムコードが含まれている場合は、これが原因になっている可能性があります。

基本的には、原因さえわかれば、HTTP 303ステータスコードの解決は簡単です。

HTTP 303ステータスコードの解決方法

HTTP 303ステータスコードの概要がわかったところで、早速解決方法を見ていきましょう。

作業を始める前に、必ずサイトのバックアップを作成しておきましょう。これからご紹介する手順の中には、サイトファイルを編集するものもあり、慎重な操作が必要になります。

また、まずはステージング環境で操作を行うことをおすすめします。問題が発生しないことを確認した上で、本番サイトに変更を反映すれば安全です。

1. サーバーの設定を確認する

303リダイレクトの原因を突き止めるには、サーバーソフトウェアの設定ファイルを開き、意図しないリダイレクトの指示がないかどうかを確認します。まず手始めに、どのウェブサーバーソフトウェアを使っているかを調べましょう。

NginxとApacheは、最も一般的なウェブサーバーで、このどちらかである可能性が高いです。今回は、Apacheの設定ファイルを確認する方法を見ていきます。

まず、サイトファイルにアクセスします。お使いのホスティングサービスでcPanelを使用している場合は、ファイルマネージャーにアクセスしてください。

あるいは、SFTPを使用してサイトファイルに接続することも可能です。これには、FileZillaなどのFTPクライアントをダウンロードしましょう。また、FTPの認証情報も必要になります。

Kinstaをご利用の場合、MyKinstaで簡単にFTP認証情報を参照することができます。該当のサイトを選択し、「情報」画面の「SFTP/SSH」セクションまでスクロールします。

MyKinstaの情報画面
MyKinstaの情報画面

FTPクライアントとの接続を確立したら、ルートディレクトリ（通常はpublic_html）を開いて、.htaccessファイルを探しましょう。

.htaccessファイル
.htaccessファイル

次に、このファイルをテキストエディターで開き、RewriteXXXディレクティブを使用している行を探します。RewriteCondディレクティブは、入力されたURLに対して一致するテキストベースのパターンを定義します。

一致するURLが訪問者によって要求された場合、RewriteCondディレクティブに続くRewriteRuleディレクティブは、別のURLへのリダイレクトを実行します。RewriteRuleの最後にある、[R=303]を探しましょう。

RewriteRuleの最後にこの値が入力されているのを見つけたら、「#」を使って一時的にコメントアウトしてみてください。その後、ウェブサーバーを再起動し、303ステータスコードが消えているかどうかをチェックしましょう。

2. サーバーログを確認する

アプリケーションは、すべてのアクティビティを追跡できるよう、通常何らかのサーバーログを保持しています。例えば、サーバーアプリケーションログでは、どのページがリクエストされ、どのデータベースの結果が提供されたかを確認できます。

一方、ウェブサーバーのログは、サイトを実行するハードウェアに関連し、接続されたサービス（およびサーバー自体）の健全性と状態に関する情報が記録されています。したがって、サーバーログを見つけ、その内容を分析することで、303ステータスコードの解決を試みることができます。

Kinstaでサイトを運営している場合は、MyKinstaで以下3種類のログファイルを閲覧可能です。

  • error.log：PHPエラーを含む特定のエラーを記録
  • kinsta-cache-perf.log：リクエストに対するキャッシュヘッダの状態（HIT、MISS、BYPASS）を記録
  • access.log：その日のすべてのNginxリクエストを記録

ログを表示するには、MyKinstaにログイン後、左側のメニューで「WordPressサイト」を選択し、サイトをクリックして、「ログ」画面に移動します。

MyKinstaのサーバーログ
MyKinstaのサーバーログ

最初にerror.logのログファイルが表示されますが、ドロップダウンメニューで確認したいログを選択可能です。

ドロップダウンメニューで確認したいサーバーログを選択
ドロップダウンメニューで確認したいサーバーログを選択

表示したいログを選択すると、サイト上で発生したすべてのエラーまたはリクエストが一覧表示されます。

MyKinstaのログビューア
MyKinstaのログビューア

また、検索バーを使って、ファイル内の特定の文字列を検索することも。SFTPを使ってログをパソコンにダウンロードすることもできます。

サーバーログの確認でこのステータスコードを解決できるわけではありませんが、ログを分析し、原因となっているエラーを突き止めることができます。

3. アプリケーションをデバッグする

最後に、クライアントアプリケーションをデバッグしてみるのも手です。この解決策は、アプリケーションにカスタムコードがあり、それが原因になっている可能性がある場合にぴったりです。

まずは、ローカル環境にサイトのコピーを作成します。これによって、303ステータスコードが発生した状況を正確に再現することができます。また、何らかの問題が発生した瞬間にアプリケーションコードを表示することもできます。

WordPressのデバッグモードを有効化するには、WP Debuggingのようなプラグインを使うのが1番手っ取り早い方法です。

WP Debugging
WP Debugging

また、wp-config.phpファイルを編集することもできます。この場合は、先ほどのようにcPanelまたはFTPクライアントを使用して、サイトのファイルにアクセスし、サイトのルートフォルダにあるファイルを探します。

wp-config.phpファイルを開いたら、ファイルの一番下にある「That’s all, stop editing!」と書かれた部分に移動して、次のコードを貼り付けます。

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

これで、wp-contentフォルダを見つけて、サイトのエラーを確認することができます。デバッグができている場合は、WordPressがデバッグモードが有効になったときにのみ表示されるdebug.logファイルが出現します。

このファイルをダウンロードしてローカル環境で開き、HTTP 303ステータスコードの原因となっているエラーを特定しましょう。完了したら、値を「false」に変更するか、コードの行を削除することで、デバッグモードを無効にしてください。

HTTP 303ステータスコードがSEOに与える影響とは

サイトの視認性を重視していれば、HTTP 303ステータスコードが検索エンジン最適化（SEO）にどのような影響を与えるかが気になるはず。

幸い、「HTTP 303 See Other」がサイトのSEOに与える影響はほとんどありません。このステータスコードの目的は、あくまで要求されたリソースが移動したことをクライアントに伝えることにあります。

そのため、クライアントはリソースにアクセスするために、別の場所にリクエストを送信しなければなりません。303ステータスコードは、GETリクエストにのみ使用されるように設計されているため、今後リソースにリクエストする際には、別のURLを使用します。

303ステータスコードがSEOに影響を与える可能性は低い一方で、同じ300番台のHTTP 301および302ステータスコードは影響します。と言うのも、それぞれ恒久的、一時的なリダイレクトに使用され、サイトのリンクジュースを転送することができるためです。

まとめ

HTTP 303ステータスコードは、遭遇すると厄介な存在。しかも、「エラー」と認識されることが多く、解決しづらいのも面倒です。今回の記事では、このステータスコードを解消し、サーバーが要求されたリソースに接続できるようにする方法をご紹介しました。

まずはサーバーの設定ファイルを確認し、意図しないリダイレクトが行われていないかどうかを調べること。また、サーバーのログを見たり、アプリケーションをデバッグしたりして、303ステータスコードの原因となっている問題を突き止めましょう。

また、Kinstaのような一流ホスティングサービスを利用すれば、サイトでエラーが発生する可能性が低くなることをご存知ですか？万が一問題が発生しても、プランを問わず、トラブルシューティングをサポートする業界トップクラスのサポートをご提供しています。Kinstaのホスティングプランの詳細はこちらをご覧ください。