「クロールバジェット」という言葉について

何やら「クロールバジェット」という言葉が最近お客様の一般的に使われているのを聞くということで先週くらいに社内でちょいちょい話題になっていました。

クロールバジェット(Crawl Budget)って何ですか

簡単に言うと、「このサイトは1日あたりこれくらいクロールしますよ」という上限値(Budget)をPageRankなどの指標を元にGoogleが割り当てており、このバジェットが低いとサイトが十分にクロールされません、みたいな雰囲気で使われる言葉です。

耳慣れない方には耳慣れないと思います。かくいう自分も業務上使ったことはないですしそんなに話題になることもありません。たまに海外のフォーラムなどで話題になっていることはありますね。

で、そもそもGoogleの公式で出ている言葉でしたっけと思って英語圏の公式サイト巡ってみましたが現時点ではGoogleの公式情報では確認できていません。Googleの技術的な用語というよりも便利な造語という捉え方をした方が良いかもしれません。

諸情報によると以前行われたWeb系のイベントでGoogleの方が「(クロールバジェットという概念は)Googleには存在しない」と発言もされていたようでして。ということで、まあ言葉としてはなかなか曖昧なものとして捉えておいて良いのかなと考えています。

で、言葉の説明についてはそれくらいにしまして、ここから本題。

あろうがなかろうが、考え方としては重要

仮にクロールバジェットなるものが存在するとした場合、単純に考慮すべきポイントは以下です。

・より多くのクロールバジェットを確保するためには多くのリンク(=高いPageRankやAuthority)を得ていることが重要
・クロールリソースは無限ではないので、無駄遣いさせない工夫が必要

そしてこれはクロールバジェットなるものがあろうとなかろうと、とても大きなサイトを運営している方にとっては非常に重要なSEOの要素だと認識しています。

クロール絶対量を増やしてサイトを十分にクロールさせる

ページがクロールされるのはクローラーがリンクを辿る中でURLを発見できるからであり、ほとんどリンクを得られていないページと多くのサイトからリンクをされているページでは後者の方がクロール対象になる確率は高くなります。

全体のクロールリソースが一定だとすれば、クロール対象になる確率が高い(=クロール中にリンクURLが発見される機会が多い)ということはクロールされる絶対量が増えるということです。

つまりクロールの絶対量を増やすのであれば、より多くのリンクを獲得することがそれに直結すると考えて良いでしょう。これはクロールバジェットの考え方と相反することはありませんね。

注意:SEOにおいてリンクを軽視する傾向はダメ

話題がそれるので別途まとめようと思いますが、コンテンツ重視の流れになってきているなか、逆にリンクが軽視されつつあるように思います。これは全くもってダメな流れと思います。

誤解を恐れずに言いますと、今のGoogleはまだまだ“Link is King”を否定できない検索結果です。すなわち今のSEOにおける最重要業務の一つは以前と変わらずリンクを獲得することと断言して良いと思っています。

変わってきているのは、そのプロセスとして人工的な簡易サイトからリンクをもらって順位を上げるような旧来の施策がGoogleには淘汰されつつあり、その分なおさらコンテンツやプロモーションによってリンクを構築していくことが重要になっている、という話です。

リソースを無駄遣いさせないための工夫

仮にクロールリソースが有限だとした場合、全てのURLが確実にクロールされる保証はありません。従って、不要なページにリソースが割かれないよう、重要なページのクロールに集中させる工夫が必要です。

それは例えば無駄な重複コンテンツを発生させない仕組み、理論上URLが無限に生成される仕組みが存在するのであれば運営側でのコントロール、(本当に)クロール不要なコンテンツへのrobots.txtなどの制御、などです。

少なくとも、例えば全くリンクも得られていなくてクロールされる絶対量が十分でないのに、本来クロール不要なコンテンツばかりクローラーがたどっているといった状態は避けるべきでしょう。

注意:不適切なクロール制御は単なる逆効果

クロールを制御することはコンテンツの認識に大きく影響する施策です。テクニカルな意図でrobots.txtを乱用するとかnofollow埋め込みまくるなどは基本的にはほとんどのサイトで考えなくて良いはずです。

あくまでも「クロール不要なURL」とか「制御しきれないほどの大量の重複コンテンツや空ページ量産」などへの制御を場合によっては検討する、レベルで十分と思います。

単純な絶対量(Budget)の割り当て、というよりもクロールされる確率と優先度の問題かなと思いますがどうなんでしょうか

見出しの通りなのですが。絶対量ではなくて「URLが見つけられてクロールされる機会の多さ」「クロールされる優先度」なのかなと。優先度は、「重要な情報どうか」だけではなく「クロールに支障がないか」などによっても決められるんではないかと感じています。

  • 獲得しているリンクが多ければ、その分クロールされやすくなります。
  • どちらにせよサイトが無限にクロールされることはありませんのでリソースは有限です。
  • 有限なリソースなら、より効率よく重要なページがクロールされる工夫をしましょう

ということに加えて、例えばサーバーサイドでエラーが頻発するとか待機時間が鬼のように長い、みたいなことがあればそれは有限なリソースを食いつぶすことにも繋がりますので、そうしたサイトは必然的にクロールの優先度を下げられると考えて良いと思っています(これは体感でめっちゃ感じるところ)。

個人的にはこの(特にサーバサイドの)速度改善もクロール優先度を上げるために必要な施策と思っております。特に新規のサイトでコンテンツ量は多いけどリンクは集まってないし速度も遅い、みたいなサイトだと本当にSEOは全く機能しないなという印象です。

なんだかとりとめないですがここまでまとめますと、

  • 多くのリンクを集める
  • クロール負荷をかけないよう速度改善する
  • クロールを制御する(その必要があれば)

大きなサイトで重要なページのクロール絶対量を増やすために特に重要なポイントはこの3点でしょうか、と思っています。なんだか当たり前な感じになりましたけども。

以上です。ちょっとライトな話題ですが社内用メモとして書いておきました。(この辺り実務レベルでしっかり語れる方で補足頂けるようでしたら是非ご遠慮なくお願いします)

UIやユーザビリティという問題とSEOは「別物」として切り離して考える

SEOの文脈で「検索エンジンではなく、ユーザー視点でサイトを作りましょう」ということがよく言われます。SEOの観点から話をするにあたり、果たして本当にそれで良いのでしょうか。

Googleが特に重視したいこと

もし、「ユーザー重視」がユーザーの検索体験の向上、であったり、ユーザーが検索に求める価値ある情報をコンテンツとして提供する、という意味でユーザーの視点を重視するべきという話であれば、そうした観点での改善は概ねSEOの改善につながりますので正解です。

しかし、同じようにユーザー視点でのサイト改善施策として括られる「ユーザビリティやUIの改善」などの施策が直接SEOに貢献するかといえばそれは決してそうとは言い切れません。少なくとも現時点では、これらはひとまずSEOとは別の改善施策として考えておく必要があります。

Googleが重視するのはあくまでユーザーが発見できる情報の質であり、また到達したサイトの仕様によりユーザーの検索体験を著しく損ねないことです。

言いかえれば、素晴らしいUIではなく、検索者にとって価値ある情報を検索結果で提示したい、その結果として、ユーザーの検索体験をより良いものにしたい、ということです。

UIやユーザビリティの改善≠SEOの改善

例えば、ユーザーテストを繰り返し実施したりアクセス解析をもとに課題を抽出して、よりユーザーがサイト内で迷わず目的を達成しやすいように変更する、ということは多くのWebサイトの改善施策として有効です。

では、そこで挙げられた改善項目はSEOにとってプラスになる改善なのか?といえば、必ずしもそうではありません。UIとかユーザビリティを重視してサイトを改善すれば自ずとSEOがよくなるほど今のGoogleは都合良くなってくれてはいません

従って、逆にSEOを少し妥協してでも全体の転換率を高めるかどうか、などの判断を求められる場合も多いでしょう。

例えば下図のように、自然検索流入が20%減少しても全体のコンバージョンが10%向上して総合的なROIが改善するのであればそちらを選択すべきですね、とかそういう世界です。

検索トラフィックが減ったとしても、広告やソーシャルメディア経由の流入をはじめ全体の目標達成率が改善し、結果として目標達成数が改善することはあり得る。

※さすがにここまで都合良く数字が動くわけではないにせよ、言いたいことのイメージとして。

ユーザビリティの改善がSEOの改善に繋がるケースも多くある

もちろんユーザビリティやUIの最適化を行うことで、それがSEOの改善に直結することは少なくありません。例えば、

  • ユーザーに不適切な転送設定がある
  • 実質的なコンテンツを持たず広告への橋渡ししかしていない
  • 広告表示量がページの情報量に対して異常に多い
  • ファーストビューの表示が著しく遅い
  • そのページのメインとなる情報の起点がファーストビューに存在しない

などの問題は、ユーザーの検索体験を大きく損ねる要因になるでしょう。ユーザビリティ上の問題だけではなく、検索順位に直接的に悪影響を与える可能性が高いため、SEOの観点でも改善すべきポイントと言えます。

また、これとは別に、検索者や彼らの検索行動を考慮した情報設計のもとでナビゲーションを変更するなどの施策でしたら、それは多くの場合にSEOに直結する改善施策になります。

SEOを考慮する上では、検索エンジンの制約が前提にある

しかし、今の検索結果で露出を高めるための最適化を行うということは、今の検索エンジンの性能などといった制限を考慮する必要があります。今のGoogleは昔に比べ進化したとは言え、人間と同様の情報処理が行えるわけではありません。

ですので、SEOという制約の中でサイトを考えるときには、やはりクローラビリティやインデクサビリティ、アクセシビリティなどへの考慮がまだまだ必要です。

具体的には、例えば大半のユーザーにとってはサイト利用上で不要かもしれない文章を用意したり、同様に不要なリンクナビゲーションを用意することがSEO上の改善に繋がる場合もあるのです。

モバイルファーストで作られたサービスのSEOの課題

こうした課題は、特にモバイルファーストで発進したWebサービスにおいては顕著に現れます。スマートフォン向けサービスにおけるサービス設計やUI設計においてSEO要件が優先的に考慮されるケースはまずありません。

文字情報やナビゲーションも、スマホUIを重視するのであれば操作性やコンテンツの視認性を考慮して「不要な情報をできるだけ削る」というステップを踏むのが一般的でしょう。

その要件を基準にサイトを作れば、必然的に検索エンジンがインデックスできる情報量や、クロールできるURLについても制限されることになります。

最近ではよく「スマホ版のコンテンツをとりあえずそのままデスクトップ版に拡張しました」というサイトを見ることがありますが、上記のような理由でSEOには不利になります。

スマートフォン端末を優先した情報設計を行うサイトが増えても、Googleのインデックスは依然としてデスクトップを前提として形成されているという実情が、このギャップを更に広げている気がしなくもありません。そしてそれは検索者の都合を考慮すれば自然なスタンスだと思います。

これはインターネットにおける情報探索行動が年々スマートフォンに移行していく中で、モバイルファーストで作られたWebサービスの普及が進むにつれよりいっそう顕著な課題となるでしょう。

どこまでSEOを重視するか

サービスの内容によっては、上手にUIやユーザビリティとの妥協点を見つけ、デスクトップ版とスマホ版、アプリ版などでUIとSEO要件のバランスのとれた設計をすることが可能と思いますが、そうではないケースも多々あります。

では、そういうケースではSEOに取り組む必要がないのか?といえば決してそうではありません。

そのあたりの線引きは、「この情報は(ユーザー視点で見た時に)検索結果に載るべきか?載る必要はないか?」で考えるべきです。テキスト情報があるか、ないか、とかそういう事実だけで判断するべきではありません。

検索結果に載るべき情報(=他にない付加価値を持っている情報)なのであれば、コストの許容する限り&サービスを損ねない要件においてSEOを考慮するべきと思います。

「テキスト情報が少なすぎてこれでは何とも、、」などのことも勿論あるでしょうが、それでも保持しているデータと情報そのものの性質を元に、持っている情報をページの情報やリンクナビゲーションにどのように反映させるかを考えるだけでも、改善させることはできると思います。

まとめ

いろいろなSEO系の記事のコメント欄を見て、「SEOじゃなくてユーザー視点でサイトを作ることだけ考えれば良いのに」的なコメントもちょくちょく見かけますが、検索エンジンという特殊なプラットフォームの制限を無視することは今の段階ではオススメできません。

SEO要件を考慮せずあえて無視する、が功を奏することもあるでしょうが、ある程度の知識と判断材料なしにその判断をするのであれば、それは単に検索流入を放棄することになりかねませんので、注意してください。

お知らせ

しきりにSEOの話をしてきましたが、最近、サイト改善ソリューションとしてユーザビリティ改善に特化したサイト改善サービスの強化にも力を入れています(実はユーザーテストルームなんていう専用部屋とかアイトラッキングシステムなんてものもオフィスに存在していたりします)。

その流れで、そちら系のテーマでの話題での勉強会なども行いますので、SEOだけではなくこういうところでも皆さまの支援を出来ればと思います。SEOの会社としては珍しい方向性かもしれませんが、この人たち珍しいなと思って是非お越しください。

詳細:【初心者向け】サイトパフォーマンス向上の為のユーザビリティ改善セミナー
※残席少ししかないみたいなのでお早めにお願いします。

【初心者向け】クローラビリティを改善し、サイトのコンテンツを検索エンジンに正しく発見・認識させる

SEOの文脈で「クローラビリティ」という言葉を聞いたことがある方は多いと思います。クローラーがどのように情報を発見し、受け取るかを理解することで、サイトの改善に役立ててみて下さい。初心者向け記事として大学生の佐々木くんにまとめてもらいました。

検索エンジンの仕組み

検索エンジンは大きく分けてクロール、インデックス、ランキングの3つで成り立っています。検索エンジンはまず数兆ものWebページを「クローラー」と呼ばれるソフトウェアがリンクを辿って巡回しながら各Webページの情報を取得し、その情報をサーバーにインデックスします。

インデックスされた情報は検索エンジン独自のアルゴリズムによってランキング付けされ、そのランキングが検索結果に反映されます。

今回のテーマは「クローラビリティ」ですが、クローラビリティを改善することは、必要なコンテンツを正しく検索エンジンが発見できるようになることに直結します。数十ページのサイトが気にする必要はほとんどありませんが、比較的規模の大きなコンテンツを有しているWebサイトであれば、クローラビリティを考慮したサイトの設計は極めて重要なポイントとなります。

検索エンジンの仕組みに関しては検索エンジンの仕組みを説明しているGoogleの公式ページが説明しているので、まずはそちらをご覧頂ければと思います。

具体的なページを例に比較

検索エンジンは進化し、ユーザーと同じような目線でコンテンツを評価できるようになってきている、という話をよく聞きます。もちろん、人間が良いと思うものを検索エンジンが同じように良いと評価できるように仕組みの改良が行われていますが、現実を見ればまだまだそこには乖離があります。

ということで、当社が運営しているアプリに関する記事を例に、人間が見た場合と検索エンジンが見た場合の両方で比較してみたいと思います。

人間が見た場合

日刊Applivのキャプチャ画像、記事タイトルやキャッチとなるサムネイル画像、記事ランキングなどが画面に表示されている

人間が見た場合はみなさんそれぞれの見方があるとは思いすが、タイトルや本文の内容を見つつ新着記事や月間PVランキングにさらっと目を通す感じかと思います。

検索エンジンが見た場合

ここではGoogleの検索エンジンを例に、Googlebotがどの様にサイトを理解しているのかをSearch Engine Spider Simulatorというツールを使って見てみます。

同じ日刊Applivのページですが、レイアウトも画像もなく、ただひたすら文字情報だけが列挙されている

分かりづらいかもしれませんが、この画像の様に検索エンジンはページ内のテキスト情報のみを取得していると考えて下さい。厳密にはHTML全体を取得し、読み取れたテキスト情報をHTMLタグから分離して解析している、という方が正しいかもしれません。

※実際にGoogleのクローラーがサーバーから受け取っている情報は、ステータスコードやメタ情報などの付加情報と、HTMLファイルそのものです。このあたりの仕組みについては次の記事を参考にしてみてください。

参考:よく見るHTTPステータスコード一覧とその意味を理解する

また、次のように検索エンジンはテキストの他にリンク(link)や、キーワード(keyword)、スニペットに採用される可能性のあるディスクリプション(description)に関する情報をクローリングしてサーバーに情報をインデックスします。ここで発見され取得できたリンクURLは、クローラーの巡回リストに登録され、クロール対象URLとなります。

日刊Applivの記事内で発見されたリンクのURLが羅列されている

メタキーワードやメタディスクリプションといったメタ情報。この記事では特に記述がありませんのでnot foundと表示されている

この様に、人間と検索エンジンではWebページの見方が全く異なる事が分かります。

例を挙げますと、alt属性という、画像の代替となるテキスト情報を入れましょうという話はよく有りますが、このようにテキスト情報としてコンテンツを見た時に、文脈として意味が通るような代替テキストを含めることが正しい、ということは理解できると思います。

例えば、意味を持たない画像情報にはalt属性はalt=”"(空っぽ=意味情報なし)として記述しないといけませんし、逆に、豊富な意味情報を持つ画像であればその意味情報をそのままalt属性に付与しないと文脈として意味が通らなくなってしまいますね。キーワードを含める含めないとかいう話ではなく、こういう使い方を心がけると良いと思います。

検索エンジンの性能とクローラビリティ

Googlebotを例に検索エンジンがサイトをどう理解するのかについて説明しましたが、検索エンジンはGoogle以外にもYahoo!、BinggooBaiduInfoseekAskLycosCUIL!などなど数多く存在し、これらの検索エンジンは決してGoogleと同等の性能がある訳ではありません。

ユーザー体験の検索に特化したり検索ワードの関連性に特化したりと、特定の分野に強みを持つ検索エンジンも存在しますが、総合的に現時点ではやはり、Googleが最もユーザーが見つけたい情報を表示してくれている検索エンジンと言えるような気がしますね。
出典:4大検索エンジン+Cuilの性能を比較してみた

Googleはもちろん、様々な性能の検索エンジンがある中でどの検索エンジンに対しても正確にサイトの情報を理解してもらうには、「クローラビリティ」を考慮する必要があります。

クローラビリティとは
サイトにに対するクローラーの回遊性の事
引用:クローラビリティを100点に仕上げてURLを検索エンジンに正しく伝える

つまり、クローラーがどれだけWebサイトの中を巡回しやすいかの度合いを表す言葉です。クローラビリティが強固なWebサイトは、常に重要なコンテンツが検索エンジンに発見される状態を維持できますので、検索エンジンにとっても優しいサイトだと言えます。

リンクのURLが発見されて巡回リストに登録されなければそのコンテンツが検索結果に表示されることはありませんし、クローラーが読み取れるテキスト情報が不足または不適切な状態では、正しい内容を検索結果に反映できないかもしれません。

特に多くのコンテンツを有するサイト、動的にコンテンツを吐き出すような仕組みを持つWebサイトにおいては、このようにクローラーが正しく情報を発見できて内容を理解できることを前提に作らないと、せっかく公開しているコンテンツが検索結果に反映されないということになりかねません。

参考:SEOで本当によく見る”もったいない”内部リンク設計

さて、クローラビリティを考慮する上でWebサイトを設計するには、

  • クローラーがクローリングしてきた際に正しいHTTPステータスコードを検索エンジンに返す事
  • URLを整理してWebサイトのもつコンテンツをクローラーに過不足なく発見させる事
  • リンクには<a>タグと適切なアンカーテキストを記載する

などといった施策があります。(より詳しい内容はWeb担当者フォーラムの”クローラビリティを100点に仕上げてURLを検索エンジンに正しく伝える“や”titleタグ、metaタグおよびURLの構造 – 『検索エンジン最適化の初心者ガイド』改訂版#4-2“の記事に記載されています)

結び

今後、良質なコンテンツをより多くの人に見てもらう機会を作るには、検索エンジンの性能を過信し過ぎないのが無難ですが、もちろん検索エンジンの性能は歴史を辿ってみてもその性能は確実に高まっているので必要以上に最適化する必要は無くなってきています。

しかし、クローラビリティが軟弱だと検索エンジンによってはサイトの情報を正しく理解してもらえず評価に悪影響をもたらしたり、そもそも情報をクロールされないなど負の結果を招く原因になり得るので、性能の低いクローラーでも情報を理解出来る様に、という考えの元で最適化をする事で、より強固なクローラビリティを実現出来ると言えます。

参考:GoogleのJavaScript理解に100%頼るべきではない、JSなしでも入手できる最小限のコンテンツが必要

重要なコンテンツのクローラビリティを確保することは、検索エンジン最適化における基本的な施策であり、にも関わらずここを疎かにしていることで大きな機械損失を生んでいるサイトは決して少なくないのではないでしょうか。

ユーザーだけでなく、検索エンジンにも優しいWebサイトの構築を目指していきましょう。

外部サイトへのリンクには漏れなく”nofollow”とか、いい加減やめませんか

「外部サイトへのリンクには、PageRankが外に流出するのを防ぐために”nofollow”を入れるように、とSEOの人からアドバイスをもらったことがあり、実践している」という方が今でも多いように思います。というか多いです。

無意味です

ほとんどの場合、大切なPageRankの流れを意味もなく断ち切っているにすぎず、プラスになることはなくマイナスでしかありません。この記事で紹介するような事情が無い限りは外すことをおすすめします。

まず前提として、ユーザー投稿型のサイトなどではない一般的な企業サイトを運営していて、nofollowをテクニカルに駆使する必要のあるシーンというのはごく限られたケースだという認識です。正直ほとんど使いドコロはないと思っています。

普通はほとんど使わなくて良いものですし、個人的にもここ数年でnofollow付与を提案したケースは自社で運営するメディアも含めて数えるほどしかありません。(某氏のように大規模なサイトのSEOばかりをガッツリ見ている人はそうではないと思いますがそんな人、何人もいないと思います。)

ということで記事タイトルについての話はもう完了したので、ここからはrel=”nofollow”について解説します。

rel=”nofollow”の意味

nofollowって何よ、という方に簡単に解説しておくと、「nofollow指定されたリンク先にPageRankを渡さない」「nofollow指定されたリンクをクロールの対象リストから除外する」というものです。簡単にいえばSEO上そのリンクの価値がなくなるということですね。

nofollowの意味を図示しています

nofollowが作られた目的は、検索エンジンのランキング評価対象としたくないページへのリンクにPageRankをを受け渡さないようにする、といったことを簡便に実現するためです。

もしnofollowがなければ、例えばリンクをクロールさせたくない場合、robots.txtでブロックされた中間ページにリンクし、中間ページから本来リンクしたいページのURLにリダイレクトをする、など何かしらの面倒な作業が必要となります。

なぜnofollowが必要になったか

その当時に検索業界にいたわけではありませんでしたので、その時代を生きていた方から何か補足がありましたら是非お願いしたいのですが、考えられる点としては主に以下のものかなと。

SEOを目的とした有料リンク掲載への対策

ユーザーが(何かの対価としてではなく)自発的に掲載したリンクに限定して評価対象としないと本来のPageRankの概念それ自体が意図した通りに機能しなくなります。

そこで、Googleとしては「金銭などを対価として掲載するリンクにはnofollowを付与する」というルールを設けることで、有料リンク等による順位操作を規制しようとしたことが背景としてあげられると思います。

ユーザー生成型コンテンツ(UGC)の普及に伴う、”リンク先ページの信頼度をサイト運営者が保証できないリンク”のクロール制御

1つ前の項目とほとんど同じじゃないかと思うフシもありますが。

Wikipediaを代表として、Yahoo!知恵袋や無料ブログサービスなどでは外部サイトへのリンクに自動的にnofollowが付与されるようになっています。身近なところではtwitterの投稿のリンクも同様です。nofollowが付与されているので、これらのサイトにリンクが掲載されたとしても直接的なSEOの価値はありません。

もともと、大半のリンクはサイト運営者の意思の元で掲載されていたはずです。しかしUGCが普及し、サイト内にユーザーが自由にコンテンツを投稿したりリンクを掲載できたりするようになると、サイトへの誘導目的や、SEO目的のリンクの掲載も一定割合発生します。

それがまともなサイトならまだしも、アダルトサイトやウィルスを拡散させるためのサイトでないとも言い切れません。そうしたサイトへのリンクを検索エンジンが評価対象&クロール対象としない、とすることで、少なくともSEO目的のリンクの投稿の価値をなくすことが出来ます。

まとめてしまえば、SEOを目的としたリンクへの対処法として、と言えそうですが。

PageRankスカルプティング

僕がこの業界に関わりだした2009年には、ギリギリそういうテクニックがありました。最近SEOの勉強を始めた人だとあまり聞き慣れないかもしれません。

イメージだけ説明すると、”100″のPageRankを持ったページがあったとして、そのページから10本のリンクが均等に掲載されていた場合、各ページに10ずつのPageRankが流れます(あくまでもイメージです)。

pagerankが均等に10ずつ配布されるとします

そのうち2本のリンクにnofollowを付与することで、PageRankを受け渡す対象が8本になりますね。すると、各ページには12.5ずつのPageRankが受け渡されることになります。つまり8本に渡るPageRankが増えるのです。

nofollowで指定したリンクの分だけ、他のページへのPRの受け渡し分が増える

このように、nofollowを活用して重要なページにPageRankを集中させようとするテクニックを、PageRankスカルプティングと呼びました。

でもこれは既に2009年時点で機能していません。あるリンクにnofollowを掲載した場合、PageRankを破棄することになり、そのほかのリンクに充当されるわけではない、という仕様変更が行われたためです。

仮にnofollowで指定したとしても、それは破棄することに同義。他が増えるとかそういうわけではない

変更の意図としては、もともとサイトのPageRankを調整するためのテクニックとしてnofollowが作られたわけではなく、ユーザーにとっては無関係な施策でしたので、そういう使われ方をされることは本来の目的と異なる、という判断のもとの変更という話だったのかもしれません。

どちらにせよ現時点では、nofollowを付与すればPageRankが重要なページに集中します、ではなくなっているのです。

nofollowはいつどんな時に使うか?

一部曖昧なところもありますがこのようなイメージで問題ありません。

ユーザーがリンクを自由に掲載できる場合の不正リンクへの対策

先述の通り、ユーザーが投稿できるタイプのコンテンツで、誰でもリンクを掲載することが許可されている場合、信頼できないサイトへリンクが向けられる可能性があるため(出会い系やアダルトサイトなどのスパムコメントなどが良い例)、それをGoogleに辿らせない&評価の対象としないために使います。

昔はUGCがここまで普及していたのでほぼ全てのリンクはサイト管理者の制御のもとで掲載されていましたが、UGCが普及したことで誰でも簡単にリンクを貼ることが出来るようになり、その中で自作自演やスパムなどが増えてくると、外部サイトへのリンクには一律でnofollowなどの対応を取らざるを得ません。

※事実、近年では不正リンク対策として、有料ディレクトリ登録サービスや無料ブログサービスの外部サイトへのリンクの多くもnofollowを付与するように変更されてきています。

検索エンジンがデータ収集する価値のないページへのクロールの制御

よく言われているのはログインページなど、Googlebotがそのコンテンツの中身を収集出来ない場合です。砕けて言えば「そこクロールしても何も見れないから他のとこ見に行ってちょうだい」という意味ですね。

それであれば使う意味は確かにあるような気がしますが、いちいちそんな細かいこと考える必要もないんじゃないでしょうかとも思っています。大きな効果があるとは思えませんし。

あとこの意図で使うとすると、ほとんどのサイトは意識する必要はないと思うのですが、大規模なサイトを運営していて、本来クロール不要なURLへのリンクが不可避に大量に生成されるがrobots.txtでブロックする必要がない、或いはrobots.txtでリアルタイムに弾いていくのが運用上現実的ではない、などの場合でしょうか。

※ただし不要なはずのURLが大量に生成されるというのは、それはnoindexとかnofollowでどうこうじゃなくてその仕様を適切な形に変更すれば良い、というケースも割合多そうですが。。

よほどのことが無ければ、ほとんどの場合はウェブマスターツールのパラメータ制御機能で上手く調整すれば良いレベルだと感じています。(すみません、ここは正直言いきる自信がないです。)

Google的には”真っ黒”な完全アウトサイダーなサイトへリンクをせざるを得ない場合

これは正直ちょっと自分でも確信はなくて、賛否両論あると思うのですが。

仮に自社の関連サイトだったとしても、リンク先のページが大規模な不正リンクプログラムなどの中心にいる場合、或いは重度のペナルティを受けている場合など、リンクを掲載することでそのサイトとの(リンクの繋がりとしての)距離が近くなってしまいます。

こいつはくせぇーーッ!スパムのにおいがプンプンするぜーーーッ!!

でも関連サイトですし、Google的に真っ黒であることとユーザーに見せたくないことは全く違いますので、リンクを外す理由にはなりません。放置でも良いのかもしれませんが、個人的にはこういうリンクの繋がりの全体像を想像するとこれはちょっと気持ち悪いし嫌なのですね。

それを避けるためにnofollowを掲載するよう提案したことはあります。

nofollowを付与することでリンクグラフから相互リンクを無効化する

どのケースも多少の効果はあったように見えましたが、正直言えば因果関係は曖昧ですのでここは参考程度にして下さい。冒頭でも書きましたが、ほとんどの場合は有効なPageRankを破棄することでもありますのでこんなことしない方が良いのは間違いありません。

とまあ、いくつか挙げてみましたが、少なくとも一般的な中小規模の商用サイトでnofollowを当然のように使う、どこでnofollowを付与するかをじっくり考える、などということはほとんど無いなあとは思っています。

なぜ、テクニカルなことをしたがるのか

ドラクエで新しい呪文を覚えると、誰もが”絶対に必要ないけど使わざるを得ない”みたいな精神状態に追い込まれます。

例えば敵グループが複数に分かれていて、どう考えても賢者としてはヒャダインかイオラあたりで対応するようなシーンなのに、1ターン目でなぜか敵単体に向かって新しく覚えたベギラゴンを唱えてしまうなどの事例が挙げられます。

特に画面演出のないドラクエ4以前であっても、同様の現象が必ずと言っていいほど起きますね。

それと全く同じです。少し勉強して知識がつくと、絶対に必要ないのにcanonicalとかnoindexとかnofollowとかrobots.txtを駆使してクローラーの色々制御してみようなどと思ってしまったり。しかしほとんどの場合が「しかしなにもおこらなかった」です(逆に大ダメージを受けることはありえます)。

例えば、昨年にrobots.txtについて詳細に記事にまとめられていたブログがありましたが、(おそらく記事執筆時に調べながら追記したであろう)robots.txtの記述が誤っていて、全てのページがクロール拒否になっていたということは記憶にあたらしいです。ちなみにその後きちんと修正されていました。

まとめ

普通にサイトを運営していれば「ほとんどのページはクロールされ、インデックスさせるべきコンテンツ」なはずです。外部サイトであっても、nofollowを付与する必要のあるようなサイトにリンクすることは滅多にないはずです。

少なくとも、敵グループが多数に分散していたら、多くの場合は素直にイオ系呪文で対応しておくのが良いかと思います。

ヴォラーレ株式会社 土居

スマートフォン版サイトがないのにスマホとPCで検索順位が全然違う、という事例を調べてみた

6月に、「スマートフォンユーザーにとって著しくユーザーエクスペリエンスを損ねるような実装をしている場合、スマートフォン検索においてのみランキングを下げることがある」というような話題がありました。

※参考:Google ウェブマスター向け公式ブログ: スマートフォン向け検索でのランキングの変更について

先日、うちのメンバーに頼まれてあるクライアント様のサイトを調査してみたところ、それに近い話題で、ただちょっと特殊っぽい事例にあたりましたので紹介しておきます。

結論:スマホでは普通に見れるけどGooglebot-Mobileには不適切な転送設定されていた

ざっくり言いますと、「通常のスマホブラウザでは問題なくレスポンスが返されてサイトが閲覧できるのに、スマートフォンのUAを持ったGooglebot-Mobileに不適切なリダイレクト、具体的には『全てTOPページへ転送』のような設定がされていた」という状態でした。

と言われても何のこっちゃピンと来ないという方も多いと思いますので簡単に解説していきます。

解説

まず状況としては、

  • 少し前からスマホ検索でのみ検索結果に表示されなくなった
  • でもスマホサイトもないし、スマホでの閲覧も問題なく出来る
  • 変なリダイレクトがかかってたりする様子もない
  • PCサイトでは問題なく検索トラフィック伸びてるのにスマホだけ激減してる

という感じで、最初は検索結果のバグかテストか何かかな?とも思ったのですが、それなりの期間そういう状態だったのでそういうわけでもなく、何かしら致命的な問題があるはずと思って改めて調べてみたわけですがしばらくの間は良く分からんという感じでした。

ようやく思い立ってFetch as Googleで投げてみた

ちなみにFetch as Googleって何、という人のために言うと、「Googlebotがどういう風に情報を取得しているのかを確認できる、ウェブマスターツールの機能」です。こんな感じです。

ウェブマスターツール左メニュー「クロール」から「Fetch as Google」の機能を選び、URLを指定してクローラの種類を指定する
こんな風にURLとクローラーを指定すると、

Googlebotが受け取る情報がそのまま表示される
こんな風にクローラーが受け取る情報を表示してくれます。(↑はテストなので気にしないで下さい)

さて話を戻しますが、ChromeでUAとかいじくりながら色んなUAでアクセスしてみても全部通常に見れて、冒頭の記事にあるように「スマホ閲覧に苦しいくらい表示が遅い」なんてこともないし、何だろうなあと思いながら色々見てたのですが、「あ、Googlebotで見てない」とようやく気付いてウェブマスターツールでFetch as Googleで投げたんですね。

そうしたら案の定、スマホUAを持ったGooglebot-Mobileでアクセスすると「リダイレクトループになる」とか「全てのURLがTOPページにリダイレクトされる」的な感じになっていました。Fetch as Googleで取得した情報は以下のようなものでした。

HTTP/1.1 302 Found
Date: Wed, 13 Nov 2013 11:36:07 GMT
Server: Apache
Location: http://www.**********.jp/
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF=”http://www.***********.jp/”>here</A>.<P>
</BODY></HTML>

※この辺りの見方についてはHTTPステータスコードについての記事を参考にしていただければと。

まとめ

「スマホ版のサイトを持ってないなら、変な仕様になってスマホ検索結果で変な結果になることはないはずなんだけどなあ」というところでちょっと先入観ありましたがあくまで情報を取得してるのはGoogleのクローラーなのですからそちらでチェックしないといけないですね。

あまり汎用的ではない話題だと思いますが、ここ最近だけでも数回、スマートフォン検索での検索結果が下がった、などの相談を頂きましたが、どれも不適切なリダイレクトなどの初歩的な設計ミスが何かしら発生しているという状態でした。

そもそも冒頭にあるような話題をキャッチアップしていなかった人は必ず知っておくべき事項ですし、こういう細かな設定ミスでもトラフィックに重大な影響を与える可能性もあるということで、きちんと予備知識として再確認をしておけると良いですね。

ヴォラーレ株式会社 土居

おすすめの記事

Webサイト高速化・表示速度改善のために知っておきたい基礎知識

Webサイトを高速化をする事によって得られるメリットは様々あると思いますが、ユーザーエクスペリエンスの改善といった話とは別に、個人的にはサーバの台数が減らせるというのも大きなメリットだと思っています。サーバサイド側のエンジニアとしてはやはりサーバの台数が減ればコストも下がるし、運用も楽になりますので、SEOに関わらず努力したいところではありますね。

しかしながら、「高速化しよう」「表示速度を改善しよう」といっても、実際にどういうところに高速化を阻害するような要因があるのか、ということを知っていなければそもそもどう取り組んで良いか分かるはずもありません。

ということで今回は、技術者の方でなくともサイト高速化のポイントがある程度理解できる(多分)ように、最低限「こんなことがあるのね」というポイントを大まかにまとめてみました。

高速化のための基礎知識

高速化という言葉の中には、大きく分けて2種類の概念が存在します。

  1. フロントエンド側での高速化
  2. サーバサイド(バックエンド)側での高速化

フロントエンドとは

ここで定義したいフロントエンドとは「HTML・CSS・JavaScriptなどの技術」と解釈してください。噛み砕いて言えば、「ページがブラウザに表示される」という部分に関する部分がフロントエンドということです。フロントエンドの領域では、ある程度HTMLが書ける方ならポイントさえつかめれば誰でも高速化する事が可能です。

サーバサイド(バックエンド)とは

サーバサイド(バックエンド)側、というのは文字通りサーバー側での最適化なのですが、状況によって見るべきポイントが異なりますし、ある程度は専門的な知識が求められるので、誰でも簡単に高速化、というのは難しいことも場合と思いますので、今回はいくつかの要素について掻い摘んでお話しようと思います。

フロントエンドの高速化

これに関しては様々な方法があると思いますが、シンプルに考えて以下の3つを注意した上で高速化を行っていけばいいと思います。

  1. サーバーへの通信の回数を減らす
  2. サーバーへの通信量を減らす
  3. レンダリングの速度を低下させない

1.サーバーとの通信の回数を減らす

まず、普段ウェブサイトを表示する時のブラウザの動作を考えてみましょう。ウェブページにアクセスする際には、ブラウザに「http://xxxx.○○.html」などといったURLを入力したり、リンクをクリックしたりすると思いますが、このサイトを開く場合にサーバへのアクセスは何回になるか?

と聞くと、意外に「1回しか通信しない」と思っている人も多いのではないでしょうか。

実は「http://xxxx.○○.html」を開いて中のHTMLを確認するまで、実際に何回サーバーとの通信が発生するかはわかりません。

なぜ開くまでわからないのか?といえば、それはHTML書かれている内容によって通信回数が異なるからです。通信回数はHTMLの中に記述されている、画像、外部CSSファイル、外部Javascriptファイルの数によって変わってきます。

外部ファイル化されたスタイルシート(CSS)やJava Scriptは、都度そのファイルの情報をサーバーから受け取ります。同じく画像ファイルも、都度サーバーから情報を受け取っているため、画像ファイルが多ければ多いほど通信も多く発生しています。ブラウザにキャッシュが残っている場合には、サーバーとの通信は発生せずキャッシュの情報を読み込みます。

単純に考えて画像の数だけ、CSSの数だけ、Javascriptの数だけ通信が発生していまします。
※304を返す場合は通信は発生しません。ステータスコードに関しては「よく見るHTTPステータスコード一覧とその意味を理解する」を参照してもらえればいいのかなと思います。

通信回数が多いということは、その分だけ表示が遅れることにつながりますので、なるべく少ない通信回数で表示が完了できるようにするという事がまず大切です。もちろん、決して「通信を1回に押さえろ」というわけではなく、あくまで無駄な通信をしないということです。

2. サーバーへの通信量を減らす

通信の回数、ではなく「通信量」を減らすということをイメージすると、例えば画像ファイルの容量を減らすことが思い浮かぶ方が多いと思いますが、そういうことです。画像や動画ファイルはファイルサイズがとても大きいので、通信量が増えます。

この点では、本当に基本的な事かもしれませんが、読み込むファイルのサイズを減らすということが重要になります。一番多くのサイトに関係があるのはやはり画像ファイルだと思います。

「これ以上は画質を荒くしたくない」という事情は多々あると思いますので、そんなときは、画質を落とさずにファイルサイズを減らす「画像の最適化」を行います。

通常の画像データにはウェブページとしては不必要なデータが含まれている事があります。それらを排除することで、ファイルサイズを軽くする事が出来ます。画像によっても変わってきますが、相当ファイルサイズが減るのでおすすめです。

最適化する際は専用のソフトウェアがあるので、そちらを使いましょう。

ちなみに、余力があれば、CSSとJavascriptのファイルサイズも少なくした方が良いと思います。もともと、画像に比べたらファイルサイズは小さいのですが、それでも軽量化をするべきだと私はを思います。

ある程度ウェブサイトを長年運用していると、CSSやJavascriptが徐々に追加され、気づいたら容量が増えていたなんてことがあります。また、簡単に軽量化できるので、導入しやすさもあります。

ただし、不必要なJavascriptやCSSは削除してしまえばいいんじゃないの?って思う方もいるかもしれませんが不必要だと思ってたら、必要だったCSSの記述だとか、使っていないと思っていたJavascriptの関数を削除してしまったり…と、もちろん不必要な記述は削除するべきですが、現実的にはなかなか難しいと思います。

そんなときは「ファイルの圧縮」を行います。不必要な空白や改行を削ってCSSファイルや、Javascriptファイルを軽量化する手法です。

もちろんエディタ等の置換機能を駆使して、消していく事もできますが、何千行なんてCSSやJavascriptファイルだった場合はとても大変なので自動で変換してくれる便利なツールがたくさんあるのでそちらを使いましょう。

3.レンダリング(≒HTML解析~ブラウザ表示)の速度を低下させない

ブラウザの表示速度を遅くしてしまう要因は通信だけではありません。HTMLの記述のしかた一つでブラウザの表示速度も下がってしまう場合もあります。

例えば一昔前はよくJavascriptをheadタグのなかに記述している事が多かったと思いますが、最近ではbodyの閉じタグの直前に記述するのが主流です。(ただし、Google アナリティクスの計測用コードなどはhead内に記述したほうがより正確な計測が出来るといった事情もあるように、必ず・全てということではありません。)

headタグ内への記述を推奨されない理由は、ブラウザの表示速度が低下してしまうからです。たとえばheadの中に外部Javascriptの読み込みがあると、その時点でJavascriptの読み込み、実行がされてしまいます。その間ブラウザは表示に関する処理は止まってしまうので、ユーザーに取ってはその分表示されるのが遅く感じてしまいます。

headタグ内にJSのタグが存在すると、これらのスクリプトが先に処理、実行される。bodyタグ内のコンテンツの表示はJSの処理が完了してから行われるため、<br />
				体感として表示が遅くなってしまう。

そこで、先にブラウザに表示できるものを表示させて、あとからJavascriptの処理をさせるという順序にすれば、体感的にユーザーに遅さを感じさせないようにすることができます。

body閉じタグ直前にコードが入っていれば、コンテンツの表示が完了してからその処理が実行されるため、その分ユーザーの体感速度は改善する。

もちろん1つ2つの処理であればそこまで影響が出ることは無いと思いますが、大量にJavascriptファイルがある場合などは大きな影響が出る可能性があります。

サーバサイド(バックエンド)側での高速化

さて、ここからは簡単にサーバサイド側の高速化の話を軽く触れていきたいと思います。どうしても技術よりの話題になりますので普段全く技術に関わらない方はナナメ読みで良いと思います。

サーバサイドは本当に様々な条件によって変わってきますので、状況によって高速化の手法はバラバラです。Ruby、Python、NodeJS、Perl、Java、PHPなどプログラミング言語によってももちろん違いますし、BtoCなウェブアプリケーション、BtoBなアプリケーションなど、ターゲットによっても変わります。また、サーバのスペックなどによっても変わってしまいます。非常に複雑で、ある程度以上の専門的な知識が必須になります。

とは言っても、高速化に関してサーバサイドで重要な事は、突き詰めていけばたった一つだけ。「ブラウザに返すレスポンスの速度を上げる」ということです。

特に速度が遅くなりやすい部分、アプリケーションによるデータベースの扱い方について私が意識的に注意している部分に関して簡単に掻い摘んで説明します。

使わなくてよい物はDBを使わない

Webアプリケーションではほとんどの場合、何かしらのデータベースが使われています。データベースは非常に強力なソフトウェア(ミドルウェア)ですが、アプリケーションから使い方を間違えると速度の低下につながります。

ついつい、データベースで何でも管理したくなってしまいがちですが、データベースに入れなくていいデータを入れるのはやめましょう。特にセッションデータをデータベースに入れているケースをたまに見かけますが、なるべく控えたほうがいいです。

このセッションデータと呼ばれる物は、ユーザーがアクセスする度にデータを取得して、更新して書き込むということが発生します。リクエストが発生する度に、データベースへの書き込み処理、読み込み処理が発生してしまうので、データベースに不要な負荷を与えてしまいます。

キャッシュを活用する

当たり前の事かもしれませんが、データベースは呼ばれれば呼ばれるほど、速度が低下します。小さい事かもしれませんが、比較的変更の少ない固定されているデータ「商品マスタ」「ユーザー情報」などはキャッシュしておくべきです。ユーザー数やアクセス数が多いサービスにはかなり有効な方法です。

※ただし、キャッシュを多様しすぎると、正しくないデータがブラウザに表示されてしまうなんて事もあるので使用する際は注意してください。

実行しているSQLの最適化

データベースを使う場合に、本当に最適なデータベースの使い方をしているのか見直しましょう。データを取得する際にSQLを使用しますが、その際に実行されているSQLが意図としたSQLになっているのか?見直してみると無駄がある事も多いので、ここは慎重に確認するべきです。

データベースのインデックスの見直し

データベースの高速化の技術の一つにインデックスという物が存在します。本で言うところの「索引」と同じような物ですが、このインデックスの設定の仕方で速度が何倍も変わってきます。

良いインデックスというのはデータベースの設計やアプリケーションによって変わってきますが、インデックスがしっかり使われているかを確認しましょう。

非同期処理でデータを保存する

データベースにデータを保存する際に、「保存しました」というレスポンスをデータベースから帰って来るのを待っていると速度が遅くなってしまいます。書き込む量が多くなれば多くなるほど速度は遅くなってしまいます。

大切なデータに関しては同期的に対応するべきですが、そこまで重要じゃないデータに関しては非同期で保存するという方法は有効です。

不必要なデータは保存しない

データベースはデータ量が多くなれば多くなるほど、速度が低下してしまいます。不必要なデータを保存するのは避けた方がいいです。

分割を意識した設計

データ量が多くなってしまうデータベースでは、データベースやテーブルが分割されても大丈夫なような設計をするべきです。

、、など、見るべきポイント、高速化を阻害する要因というのは様々あります。

まとめ

ウェブサイトの高速化というと例えば「CSSスプライトを使いましょう!」などのフロントエンド寄りの話が話題になりやすいですが、こういったサーバサイドでもしっかりと対応するために、どの程度のユーザーが使うのか、どの程度の規模のサービスなのか?といったあたりも意識しながらウェブサイトを設計・構築することが重要です。

サイトの高速化について大まかに掻い摘んで書きましたが、まだまだやらなければ行けない事はたくさんあります。今回紹介したポイントを意識して最適化することにより、確実に高速化できるのではないでしょうか。

ヴォラーレ株式会社 望月

おすすめの記事

よく見るHTTPステータスコード一覧とその意味を理解する

404や503、301・302など「ステータスコード」とか言われるものをよく見るけど実はその意味はよく分かっていません、という方は意外に多いんじゃないかなと思ったので、よく見るものを一覧でまとめて解説してみました。このあたりの話題にそこまで詳しくない方でなくとも理解できるように解説しているつもりです。

Webブラウザやクローラーが情報を受け取る仕組み

私たちは普段、FireFoxやChrome、SafariなどのWebブラウザを通じてURLにアクセスしてWebコンテンツを閲覧しています。この「URLにアクセスする」ときに、Webブラウザは「リクエスト」を送り、Webサーバーが「レスポンス」を返す、というやり取り(通信)が行われています。

ブラウザからリクエスト(URL)を送り、サーバーからレスポンスが返される図

リクエストを送る側は、「サーバー(提供者)」に対して「クライアント(依頼者)」と呼ばれます。Googleのような検索エンジンのクローラーもブラウザと同じくクライアントという扱いになります。

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

WebブラウザやクローラーがURLにアクセスしようとするとWebサーバーからどのようなレスポンスを受け取っているのか?というのは例えばGoogleのウェブマスターツールの基本機能「Fetch as Google」などを使って知ることができます。
※図の中の赤枠以下の情報を受け取っています。

ウェブマスターツール Fetch as Google を使用してGoogleBotが受け取ったデータが表示。ステータスライン、メタ情報、ボディメッセージを受け取っている。

少し見づらいですが、通常通りアクセスできてコンテンツの情報が得られる場合にはブラウザやクローラーはこのようなデータをWebサーバーから受け取っています。

ここで少しだけ專門用語を使うと、上の図にあるようなレスポンスは「ステータスライン」「レスポンスヘッダ」「メッセージボディ」の3つから成っています。
上からステータスライン、メタ情報(データに付随する情報)、ボディメッセージ(この場合はHTMLテキスト)という具合でデータを受け取っている

レスポンスヘッダとメッセージボディについては今回本題から外れますが、折角ですので合わせて簡単に解説します。

ステータスライン

ステータスラインは一番上に記述されている「HTTP/1.1 200 OK」や「HTTP/1.1 301 Moved Permanently」等のようなもので、「レスポンスの状態」を表します。この中の「200」や「301」といった3桁の数字が今回の話題となる「ステータスコード」です。「OK」「Moved Permanently」は「説明句」というもので、その名の通りステータスコードの内容説明をするものです。

HTTP/1.1 は「通信規約とそのバージョン」 200 はステータスコード OK は説明句

クライアント(WebブラウザやGoogleBot)はWebサーバからどのステータスコードが返ってきたかによって、その中身を見なくとも次にどんな処理を行えばよいかを判断することができます。

レスポンスヘッダ

レスポンスに付与するメタ情報が記載されている部分です。ここでいうメタ情報とは、「(受け取った)データに関する補足情報」のようなものと思って下さい。例えば、URLが転送(リダイレクト)されている場合に転送先のURLの情報を「Location」として付与する、などの情報です。

メッセージボディ

いわゆる”本文”にあたるもので、Webページに問題なくアクセスできた場合にはHTML情報がここに記載されます。私達が普段見ているWebページはこのHTMLテキストをブラウザが解釈して表示したものです。

さて、本題のHTTPステータスコードについて話を戻します。

HTTPステータスコード

ステータスコードは本来ブラウザやクローラーが処理するために付与されているものなので、普段私達がブラウザ上でWebページを見ている際に見ることはありませんが、時々エラーでこんなのをお目にかかることはありますね。

404 Not Found

503 Service Unavailable

また、Google Chromeに標準搭載されているDeveloper Toolsや、Firefoxのアドオン(Live HTTP headersやFirebug等)を使えばレスポンスに含まれているHTTPステータスコードを確認することができます。今回はその使い方は割愛させていただきますが興味の有る方はお試しください。

それでは次節からは本題であるステータスコードについてお話をさせていただきます。

ステータスコードの大まかな分類と意味

さて、ステータスコードは大まかに分けて5つに分けられます。

  • 100番台 : 処理中
  • 200番台 : 成功
  • 300番台 : リダイレクト
  • 400番台 : クライアントエラー
  • 500番台 : サーバエラー

このようにそれぞれの番台によって異なる意味を持っています。個別のステータスコードの前に、まずここでは各番台について簡単にその意味を説明しておきます。

100番台

100番台はクライアントからのリクエストを処理中であることを示すステータスです。

Webサーバ側からクライアント側に対して「もうちょっと詳しくやってほしいことを教えてくれ」とか「今、頼まれたことをやってるんだけども時間かかるわ」という内容のレスポンスを返します。これらのステータスコードが使われている場面はあまり見かけません。

200番台

200番台はクライアントからのリクエストが受付に成功したというステータスです。私達がWebページを見ているとき、多くが200番のステータスです。

300番台

300番台は「リダイレクト」と書きましたが、厳密には「リクエストを達成するためには、ブラウザ側で追加の処理を実行する必要がある」というステータスです。

その追加の処理が301では例えば「別URLへの移動」になります。301番、302番のコードについては「301リダイレクト」「302リダイレクト」などサイトURL変更の際の転送処理として聞いたことのある方が多いのではないでしょうか。

400番台・500番台

400番台、500番台のコードはエラーコードであり、正常にリクエストされたものが返せない状態のときに使用されます。そのうち400番台はクライアント側に原因があるエラー、500番台はWebサーバ側が原因のエラーです。

それぞれのステータスコードについて

ここまででざっくりとした分類をお話ししたので、本節ではそれぞれのステータスコードについてお話します。今回は普段の業務を行う中で比較的頻繁に目にすることの多いメジャーなものに絞りたいと思います。

200 OK

リクエストは問題なく受理され、要求に従ったレスポンスが返されます。私達がWebページを正常に閲覧している際、大抵このステータスとともに返ってきたレスポンスの内容を見ています。

200はそのまま「OK、問題ありません」の意味

301 Moved Permanently

リクエストで要求された情報の中身が別の場所に移動したことを示します。

この移動は一時的なものではなく、恒久的なものです。サイトの引越しを行ったりしてアクセスするURLが変更され、ずっとそのURLを使用していく場合にこのステータスコードを返すようにしておく必要があります。

301は恒久的な転送、つまり「引っ越したよ」の意味。

googleからの評価を新しいURLに引き継がせるためにも301を設定しておきましょう。また、あるページへのアクセス経路を一本にまとめる、いわゆるサイトの正規化を行う場合にもこの301リダイレクトを使用します。

302 Found (※Moved Temporarily)

こちらもリクエストで要求された情報の中身が別の場所に移動したことを示します。301と異なるのは、その移動が一時的なものであるという点です。

302は「今ここにいないよ、そのうち戻ってくるよ」の意味

たとえばメンテナンス等で一時的にサイトを別の場所に移さなければならないが、また元の場所に戻す場合はこの302番のステータスを返すように設定しておきましょう。GoogleBotもそれが一時的な移動であることを読み取ってサイトの評価を移動先のURLに移すことはしません。

※302は昔の規格(HTTP/1.0)では説明句が「Moved Temporarily」でしたが現行の規格(HTTP/1.1)になって「Found」に変更されました。一時的な転送、という以外でも利用されることが多かったためのようで、現在別の307という比較的マイナーなステータスコードで「Temporary Redirect」が割り振られていますが、実際の使用例は見たことはありません。

304 Not Modified

これはリダイレクトではありませんが、補足的に説明をしておきます。

304は「未更新」を表します。私達が正常にWebページを見れているとき、多くは200ステータスが返ってきているのですが、実際には304ステータスのコンテンツが混じっていることもあります。このときWebサーバからはメッセージボディ、つまりコンテンツが返ってきません。ブラウザ側では304を受け取ると、ブラウザ内のキャッシュに残っているコンテンツを使ってWebページを表示しています。

ステータスコード304は「前に渡したのと同じだよ」という意味

403 Forbidden

サーバ側で外から見えないように設定してある領域へのアクセスをリクエストしたときに返ってくるステータスコードです。簡単に言えば立ち入り禁止です。

403は立入禁止の意味。

見せたいページでこのエラーが出ているときはアクセス制御の設定が間違っている可能性がありますので設定ができる方は確認してみましょう。

404 Not Found

リクエストしたページが見つからない場合に返されるステータスコードです。

404はそのまま「探したけど見つかりませんでした」の意味

ウェブマスターツールではGoogleBotが検出した404エラーをレポートしてくれていますが、特に404エラーが多いからといってgoogleからのサイトの評価が下がることはないと言われています。サイト内からリンクされているページが404エラーになっている(=リンク切れ)のは問題ですが、そうでない限りは放置しても良いかと思います。

他サイトから多くのリンクを受けているようなページを404エラーとしてしまうと、折角サイトが得られた被リンクの恩恵を逃してしまうことになります。何かしら代替のコンテンツを用意してそのページを残しておくか、近い内容を持つページに301リダイレクトするなどでリンク資産をサイト内に残せる処理をするのが一般的です。

410 Gone

404と同じくリクエストしたページが見つからない場合に返されるステータスコードです。404と違う点は、そのリクエスト先のページが「消滅した」という意味合いがあることです。

410は「前あったけどもう無いんだよね」の意味。

こちらの記事によると最近はGoogleBotは404と410を微妙に区別しているとのことですが、記事でも書いてあるようにそこまで神経質になる必要はほとんどないと思います。

補足:ソフト404エラー

ブラウザ上ではそのページが存在しない旨のメッセージが表示されているにも関わらず、ステータスコードとしては404や410を返していない(つまり正常なレスポンスとして「200 OK」が返されている)パターンが存在します。これを「ソフト404エラー」などと呼びます。

ソフト404はサーバーは「OK」と返しているのにユーザーには「無い」に見えている状態

どういうときに発生するかというと、例えばサイト運営側で独自にエラーメッセージ表示用のコンテンツを作成して、想定していないURLに対してリダイレクトをかけてそのコンテンツに飛ばすというケースが考えられるでしょうか。

Webページを見ているユーザに対してページがないことが伝わっても、機械的にHTTPステータスコードを読み取るbotに対しては伝わりません。このようなソフト404ページが存在するとGoogleBotがクロールのリソースを無駄に消費することになりますので、存在しないページにアクセスしたときはステータスコードとして404もしくは410が返されるように正しく設定するべきです。

500 Internal Server Error

サーバ側の何らかのミスによってリクエストに応えられない場合です。例えばシステム開発中にバグを混入させてしまうとこのエラーを起こすことがあります。

500は「サーバー内部の調子が悪い」のエラーの意味

503 Service Unavailable

Webサーバの過負荷状態で一時的にWebページが表示できないときなどに発生します。例えばTwitterがクジラを表示させている状態、とでも言えばイメージが沸きやすいでしょうか。

twitterが混雑してるとくじらが出ます。

メンテナンスでサービスをストップさせている際に意図的に503を返すように設定することもありますが、基本的にはサーバー負荷の問題ですので頻発するようであれば、サーバーの変更を検討するか、サイト側での負荷軽減などの手を打つ必要があります。

503は「今忙しいから後にして」の意味。

まとめ

ここまでHTTPステータスコードについてのお話をさせていただきましたがいかがでしたでしょうか。表には出てこない部分ではありますが、こうした部分まで意識してみることができれば、今よりもクローラにとって優しいサイトが作れるかもしれません。

特に一般の方(技術に関わりのない方)にとってはこうした話というのはあまり重要視されにくい話題と思いますが、SEOの観点では、サイトが検索エンジンに正常にクロールされ、正しく検索インデックスに登録してもらえるための基本的な作法として、サイトを制作・管理する方には皆さまに理解していただけると嬉しいです。

文責:ヴォラーレ株式会社 西村

おすすめの記事