こんにちは。ブログと検索を担当している河野です。
突然ですが、皆さんは404という数字を見て何を思い浮かべるでしょうか。
この数字からWebブラウザで時折見かける「404 Not Found」を思い出す人は多いのではないかと思います。ということで、ちょっと強引ですが、今回はこの404などのHTTPステータスコードについて、ディレクターの視点で知っていた方がいいことを書いてみたいと思います。
【1】HTTPステータスコードの定義と確認方法
まずはHTTPステータスコードについて一通り説明をしたいと思います。
HTTP ステータスコードとは、「HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコード」とWikipediaには定義されています。
冒頭であげた404は、このステータスコードの1つで、リクエストに対応するページやファイルを見つけられなかった時にサーバが返します。
このステータスコードは、全Webアクセスで必ず返ってくるものですが、これをブラウザ上では見ることは404のようなエラー発生時以外はまずありません。
なぜなら、ステータスコードはレスポンスの中のHTTPヘッダに記載されており、このHTTPヘッダの情報は通常Webブラウザ上に出てくることはないからです。(HTTPのレスポンスの中には、ドキュメントのタイプや最終更新日時、レスポンスのサイズなどのメタ情報を持つHTTPヘッダとコンテンツそのもののデータを持つメッセージボディの2つの領域があり、通常我々が目にするのはメッセージボディ部分[コンテンツ部分]です)
では、どのようにすればこのステータスコードを見ることができるでしょうか。以前モバイルサイトをPCで見るためのツールやFirefoxアドオンでも書きましたが、Firefoxの場合、Live HTTP Headersというアドオンを使用することで、やり取りの際のヘッダ情報を出力することができます。また、IEであれば、 Firefoxと同様のことが ieHTTPHeadersというツールでできます。
Live HTTP Headersでの画面イメージは、以下のようなものです。中の赤枠でくくっているStatus-Codeがステータスコードです。またその後ろにあるReason-Phraseは説明句と呼ばれ、スタータスコードの意味を表す短いテキスト記述です。
また、ステータスコードには100番台から500番台まで、大きく5つの区分があります。
それぞれの区分の定義は以下になっています。
この中の400番台、500番台のことを一般にHTTPのエラーコードと呼びます。
ディレクターが知っておく必要のあるステータスコードは主に300,400,500番台ですので、以下にピックアップしました。
詳細は、Studying HTTPのHTTP Status CodeやWikipediaに詳しく説明してありますのでそちらを参照下さい。
【2】エラー発生時の原因調査への利用
先ほども書きましたが、やり取り全体の意味を端的に表した値がステータスコードには入っていますので、Webブラウザを操作中にエラーが発生した際に、ステータスコードはその原因の絞込みに役立ちます。
例えば、404(Not Found)の場合と500(Internal Server Error)の2つは良く目にすると思いますが、ステータスコードを知っていると、その原因が違うことがわかります。
404の場合はリクエストされたリソースが見つからなかったということですので、
などをまず調べると、原因の発見を早くできることが多いです。
一方500の場合は、サーバーエラーを意味しますので、
などを調べる必要があることがわかります。
また、他にも401(Unauthorized)というステータスコードからはそのページでは認証が必要でそれに失敗したこと、403(Forbidden)ではリクエストの実行が拒否されていることがわかりますし、502(Bad Gateway)や504(Gateway Time-out)からは、アクセス先のサーバではなく、その上流のサーバに原因がある可能性が高いのでそれを調べようという判断をすることができます。
このようにステータスコードから問題の原因究明の足がかりを知ることができます。ですので、エラー発生時には担当する開発者には、単にWebが動かない・見えないという報告だけではなく、ステータスコードも含めて伝えるようにするといいでしょう。
【3】SEO対策への利用
google やyahooなどの検索エンジンのクローラはWebサイトを巡回する際に、ステータスコードの値を元に様々な判断をしています。そのため、SEO対策をする上では、自サイトでクローラに対してどのようなステータスコードを返しているのかを意識することは非常に重要です。
例えば、サイトの移転などでURLが変更になり、新しいページへリダイレクトをしたい時には、ステータスコードを301(Moved Permanently)にすると、PageRankや検索順位もリダイレクト先に引き継いでくれると言われています。また、クロール後はリダイレクト先のURLでインデックスを生成してくれます。これらについてgoogleは、ウェブマスター/サイト所有者ヘルプのサイトの移転で、 yahooは、リダイレクトの設定とインデックスに登録されるURLで説明しています。
上記は、ページとページの間に計測用のURLを仕込みたい場合も同様で、計測用のURL自体にはインデックスやPageRankを持たせる必要がありませんので、301(Moved Permanently)によるリダイレクトが有効です。ただ、モバイルの DoCoMo端末の場合には301(Moved Permanently)のステータスを返すと、携帯のブラウザ上で
というポップアップダイアログが表示してしまうため、クローラからのアクセスの際は301(Moved Permanently)を使用するものの、DoCoMo端末からのアクセスからは302(Found)を返すようにするなどの対応をした方がユーザビリティの観点では良いです。
他にも、削除されたアドレスへのインデックスを残し続けないようにするために、きちんとクローラに404(Not Found)のステータスを返そう(ステータス200なのに「その商品はありません」参照)とか、サイトのリニューアルなどでサービスを一時中断する際にはステータスコード503(Service Unavailable)を返すようにしよう(サイトメンテナンス時には、HTTP 503エラーを使う参照)などありますので、SEOを考える上でもディレクターはステータスコードを知っておいた方がいいでしょう。
【4】標準ルールを知り、従うことの重要性
Web が黎明期の頃のように単にサーバにアクセスしてそこのページを見るものから、WebAPIやRSSフィードの授受、検索エンジンのクロールなど、サーバ間での情報のやり取りにも使用されるようになった現在では、自サーバの振る舞いが他のサービスや機能に影響を及ぼす可能性が高くなっています。そのため、互いのやり取りには、RFCやW3Cで規定されているような標準ルールに従うことの重要性が高まっています。
その意味で、Web業界で仕事をする上では、ステータスコードのような規定(ルール)を理解し遵守するのは、開発者でなくても、ディレクターは知っておく必要があると思います。
最後に、418というステータスコードはご存知でしょうか。これは「ティーポットにコーヒーを淹れさせようとして、拒否された場合に返す」ステータスコードです。冗談かと思いきやある意味冗談なのですが、それでもちゃんとRFCの2324で規定されています(参照:WikipediaのHTCPCP)。このようなジョークRFCまであるステータスコード、一度どんなものがあるのか是非眺めてみては如何でしょうか。
以上、本記事執筆のタスクIDが404だったことをきっかけに書いてみました。
これからもライブドアをよろしくおねがいします。
突然ですが、皆さんは404という数字を見て何を思い浮かべるでしょうか。
この数字からWebブラウザで時折見かける「404 Not Found」を思い出す人は多いのではないかと思います。ということで、ちょっと強引ですが、今回はこの404などのHTTPステータスコードについて、ディレクターの視点で知っていた方がいいことを書いてみたいと思います。
【1】HTTPステータスコードの定義と確認方法
まずはHTTPステータスコードについて一通り説明をしたいと思います。
HTTP ステータスコードとは、「HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコード」とWikipediaには定義されています。
冒頭であげた404は、このステータスコードの1つで、リクエストに対応するページやファイルを見つけられなかった時にサーバが返します。
このステータスコードは、全Webアクセスで必ず返ってくるものですが、これをブラウザ上では見ることは404のようなエラー発生時以外はまずありません。
なぜなら、ステータスコードはレスポンスの中のHTTPヘッダに記載されており、このHTTPヘッダの情報は通常Webブラウザ上に出てくることはないからです。(HTTPのレスポンスの中には、ドキュメントのタイプや最終更新日時、レスポンスのサイズなどのメタ情報を持つHTTPヘッダとコンテンツそのもののデータを持つメッセージボディの2つの領域があり、通常我々が目にするのはメッセージボディ部分[コンテンツ部分]です)
では、どのようにすればこのステータスコードを見ることができるでしょうか。以前モバイルサイトをPCで見るためのツールやFirefoxアドオンでも書きましたが、Firefoxの場合、Live HTTP Headersというアドオンを使用することで、やり取りの際のヘッダ情報を出力することができます。また、IEであれば、 Firefoxと同様のことが ieHTTPHeadersというツールでできます。
Live HTTP Headersでの画面イメージは、以下のようなものです。中の赤枠でくくっているStatus-Codeがステータスコードです。またその後ろにあるReason-Phraseは説明句と呼ばれ、スタータスコードの意味を表す短いテキスト記述です。
また、ステータスコードには100番台から500番台まで、大きく5つの区分があります。
それぞれの区分の定義は以下になっています。
区分 | 説明句 | 内容 |
---|---|---|
100番台 | Informational | 情報提供のためのステータスコード |
200番台 | Success | 成功を表すステータスコード |
300番台 | Redirection | 転送に関するステータスコード |
400番台 | Client Error | クライアント側のエラーに関するステータスコード |
500番台 | Server Error | サーバ側のエラーに関するステータスコード |
ディレクターが知っておく必要のあるステータスコードは主に300,400,500番台ですので、以下にピックアップしました。
区分 | 説明句 | 内容 |
---|---|---|
200 | OK | 通信が成功した状態を示します(アクセスの大半がこのステータスになります) |
301 | Moved Permanently | リクエストしたページが別のページへ恒久的に移動したことを示します |
302 | Found | リクエストしたページが一時的に移動されている時に返されます |
304 | Not Modified | リクエストしたページが更新されていない時に返されます |
400 | Bad Request | リクエストの構文がおかしい場合に返されます(定義されていないメソッドなど) |
401 | Unauthorized | リクエストしたページを表示するには認証が必要であることを示します |
403 | Forbidden | リクエストしたページを表示する権限がない時に返されます |
404 | Not Found | リクエストしたページが存在していない時に返されます |
500 | Internal Server Error | リクエストの処理の際にサーバ内部でエラーが発生した際に返されます(スクリプト実行エラーなど) |
502 | Bad Gateway | ゲートウェイやプロキシとして動作しているサーバが上流のサーバへリクエストを送った際に不正なレスポンスを受け取った際に返されます |
503 | Service Unavailable | サーバがアクセス集中やメンテナンスなどの理由で一時的にリクエストを実行できなかった際に返されます |
504 | Gateway Time-out | ゲートウェイやプロキシとして動作しているサーバが上流のサーバへリクエストを送ったけれども、レスポンスを受信できなかった際に返されます |
【2】エラー発生時の原因調査への利用
先ほども書きましたが、やり取り全体の意味を端的に表した値がステータスコードには入っていますので、Webブラウザを操作中にエラーが発生した際に、ステータスコードはその原因の絞込みに役立ちます。
例えば、404(Not Found)の場合と500(Internal Server Error)の2つは良く目にすると思いますが、ステータスコードを知っていると、その原因が違うことがわかります。
404の場合はリクエストされたリソースが見つからなかったということですので、
・URLそのものにタイプミスがないか
・リソースの名前が変わったり削除されていないか
・必要とされるクエリパラメータがちゃんとあるか
などをまず調べると、原因の発見を早くできることが多いです。
一方500の場合は、サーバーエラーを意味しますので、
・サーバ側(プログラムファイルのパーミッション、文字コード、改行コード)に問題がないか
・CGIスクリプトやWebアプリケーション内にバグはないか
などを調べる必要があることがわかります。
また、他にも401(Unauthorized)というステータスコードからはそのページでは認証が必要でそれに失敗したこと、403(Forbidden)ではリクエストの実行が拒否されていることがわかりますし、502(Bad Gateway)や504(Gateway Time-out)からは、アクセス先のサーバではなく、その上流のサーバに原因がある可能性が高いのでそれを調べようという判断をすることができます。
このようにステータスコードから問題の原因究明の足がかりを知ることができます。ですので、エラー発生時には担当する開発者には、単にWebが動かない・見えないという報告だけではなく、ステータスコードも含めて伝えるようにするといいでしょう。
【3】SEO対策への利用
google やyahooなどの検索エンジンのクローラはWebサイトを巡回する際に、ステータスコードの値を元に様々な判断をしています。そのため、SEO対策をする上では、自サイトでクローラに対してどのようなステータスコードを返しているのかを意識することは非常に重要です。
例えば、サイトの移転などでURLが変更になり、新しいページへリダイレクトをしたい時には、ステータスコードを301(Moved Permanently)にすると、PageRankや検索順位もリダイレクト先に引き継いでくれると言われています。また、クロール後はリダイレクト先のURLでインデックスを生成してくれます。これらについてgoogleは、ウェブマスター/サイト所有者ヘルプのサイトの移転で、 yahooは、リダイレクトの設定とインデックスに登録されるURLで説明しています。
上記は、ページとページの間に計測用のURLを仕込みたい場合も同様で、計測用のURL自体にはインデックスやPageRankを持たせる必要がありませんので、301(Moved Permanently)によるリダイレクトが有効です。ただ、モバイルの DoCoMo端末の場合には301(Moved Permanently)のステータスを返すと、携帯のブラウザ上で
サイトが
移動しました
(301)
というポップアップダイアログが表示してしまうため、クローラからのアクセスの際は301(Moved Permanently)を使用するものの、DoCoMo端末からのアクセスからは302(Found)を返すようにするなどの対応をした方がユーザビリティの観点では良いです。
他にも、削除されたアドレスへのインデックスを残し続けないようにするために、きちんとクローラに404(Not Found)のステータスを返そう(ステータス200なのに「その商品はありません」参照)とか、サイトのリニューアルなどでサービスを一時中断する際にはステータスコード503(Service Unavailable)を返すようにしよう(サイトメンテナンス時には、HTTP 503エラーを使う参照)などありますので、SEOを考える上でもディレクターはステータスコードを知っておいた方がいいでしょう。
【4】標準ルールを知り、従うことの重要性
Web が黎明期の頃のように単にサーバにアクセスしてそこのページを見るものから、WebAPIやRSSフィードの授受、検索エンジンのクロールなど、サーバ間での情報のやり取りにも使用されるようになった現在では、自サーバの振る舞いが他のサービスや機能に影響を及ぼす可能性が高くなっています。そのため、互いのやり取りには、RFCやW3Cで規定されているような標準ルールに従うことの重要性が高まっています。
その意味で、Web業界で仕事をする上では、ステータスコードのような規定(ルール)を理解し遵守するのは、開発者でなくても、ディレクターは知っておく必要があると思います。
最後に、418というステータスコードはご存知でしょうか。これは「ティーポットにコーヒーを淹れさせようとして、拒否された場合に返す」ステータスコードです。冗談かと思いきやある意味冗談なのですが、それでもちゃんとRFCの2324で規定されています(参照:WikipediaのHTCPCP)。このようなジョークRFCまであるステータスコード、一度どんなものがあるのか是非眺めてみては如何でしょうか。
以上、本記事執筆のタスクIDが404だったことをきっかけに書いてみました。
これからもライブドアをよろしくおねがいします。
コメント
コメント一覧 (1)
素朴な疑問なのですが、RFC2616ってどこで使用されているのですか?
ブラウザやサーバによって違うのでしょうか。