2015年、確実に成果を出すためのSEOの方程式
土居です。この記事では僕がSEOに携わるときにほぼ例外なく考えているイメージを可視化してお伝えします（脳内整理も兼ねて）。初心者の方は全体観を把握するために、実務者の方は思考の整理に、それぞれ一助になれば幸いです。
タグ: クローラー
「クロールバジェット」という言葉について
何やら「クロールバジェット」という言葉が最近お客様の一般的に使われているのを聞くということで先週くらいに社内でちょいちょい話題になっていました。
クロールバジェット（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の公式ページが説明しているので、まずはそちらをご覧頂ければと思います。
具体的なページを例に比較
検索エンジンは進化し、ユーザーと同じような目線でコンテンツを評価できるようになってきている、という話をよく聞きます。もちろん、人間が良いと思うものを検索エンジンが同じように良いと評価できるように仕組みの改良が行われていますが、現実を見ればまだまだそこには乖離があります。
ということで、当社が運営しているアプリに関する記事を例に、人間が見た場合と検索エンジンが見た場合の両方で比較してみたいと思います。
人間が見た場合
人間が見た場合はみなさんそれぞれの見方があるとは思いすが、タイトルや本文の内容を見つつ新着記事や月間PVランキングにさらっと目を通す感じかと思います。
検索エンジンが見た場合
ここではGoogleの検索エンジンを例に、Googlebotがどの様にサイトを理解しているのかをSearch Engine Spider Simulatorというツールを使って見てみます。
分かりづらいかもしれませんが、この画像の様に検索エンジンはページ内のテキスト情報のみを取得していると考えて下さい。厳密にはHTML全体を取得し、読み取れたテキスト情報をHTMLタグから分離して解析している、という方が正しいかもしれません。
※実際にGoogleのクローラーがサーバーから受け取っている情報は、ステータスコードやメタ情報などの付加情報と、HTMLファイルそのものです。このあたりの仕組みについては次の記事を参考にしてみてください。
参考：よく見るHTTPステータスコード一覧とその意味を理解する
また、次のように検索エンジンはテキストの他にリンク(link)や、キーワード(keyword)、スニペットに採用される可能性のあるディスクリプション(description)に関する情報をクローリングしてサーバーに情報をインデックスします。ここで発見され取得できたリンクURLは、クローラーの巡回リストに登録され、クロール対象URLとなります。
この様に、人間と検索エンジンではWebページの見方が全く異なる事が分かります。
例を挙げますと、alt属性という、画像の代替となるテキスト情報を入れましょうという話はよく有りますが、このようにテキスト情報としてコンテンツを見た時に、文脈として意味が通るような代替テキストを含めることが正しい、ということは理解できると思います。
例えば、意味を持たない画像情報にはalt属性はalt=”"（空っぽ＝意味情報なし）として記述しないといけませんし、逆に、豊富な意味情報を持つ画像であればその意味情報をそのままalt属性に付与しないと文脈として意味が通らなくなってしまいますね。キーワードを含める含めないとかいう話ではなく、こういう使い方を心がけると良いと思います。
検索エンジンの性能とクローラビリティ
Googlebotを例に検索エンジンがサイトをどう理解するのかについて説明しましたが、検索エンジンはGoogle以外にもYahoo!、Bing、goo、Baidu、Infoseek、Ask、Lycos、CUIL!などなど数多く存在し、これらの検索エンジンは決してGoogleと同等の性能がある訳ではありません。
ユーザー体験の検索に特化したり検索ワードの関連性に特化したりと、特定の分野に強みを持つ検索エンジンも存在しますが、総合的に現時点ではやはり、Googleが最もユーザーが見つけたい情報を表示してくれている検索エンジンと言えるような気がしますね。
出典：4大検索エンジン＋Cuilの性能を比較してみた
Googleはもちろん、様々な性能の検索エンジンがある中でどの検索エンジンに対しても正確にサイトの情報を理解してもらうには、「クローラビリティ」を考慮する必要があります。
クローラビリティとは
サイトにに対するクローラーの回遊性の事
引用：クローラビリティを100点に仕上げてURLを検索エンジンに正しく伝える
つまり、クローラーがどれだけWebサイトの中を巡回しやすいかの度合いを表す言葉です。クローラビリティが強固なWebサイトは、常に重要なコンテンツが検索エンジンに発見される状態を維持できますので、検索エンジンにとっても優しいサイトだと言えます。
リンクのURLが発見されて巡回リストに登録されなければそのコンテンツが検索結果に表示されることはありませんし、クローラーが読み取れるテキスト情報が不足または不適切な状態では、正しい内容を検索結果に反映できないかもしれません。
特に多くのコンテンツを有するサイト、動的にコンテンツを吐き出すような仕組みを持つWebサイトにおいては、このようにクローラーが正しく情報を発見できて内容を理解できることを前提に作らないと、せっかく公開しているコンテンツが検索結果に反映されないということになりかねません。
さて、クローラビリティを考慮する上で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が作られた目的は、検索エンジンのランキング評価対象としたくないページへのリンクに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が流れます（あくまでもイメージです）。
そのうち2本のリンクにnofollowを付与することで、PageRankを受け渡す対象が8本になりますね。すると、各ページには12.5ずつのPageRankが受け渡されることになります。つまり8本に渡るPageRankが増えるのです。
このように、nofollowを活用して重要なページにPageRankを集中させようとするテクニックを、PageRankスカルプティングと呼びました。
でもこれは既に2009年時点で機能していません。あるリンクにnofollowを掲載した場合、PageRankを破棄することになり、そのほかのリンクに充当されるわけではない、という仕様変更が行われたためです。
変更の意図としては、もともとサイトのPageRankを調整するためのテクニックとしてnofollowが作られたわけではなく、ユーザーにとっては無関係な施策でしたので、そういう使われ方をされることは本来の目的と異なる、という判断のもとの変更という話だったのかもしれません。
どちらにせよ現時点では、nofollowを付与すればPageRankが重要なページに集中します、ではなくなっているのです。
nofollowはいつどんな時に使うか？
一部曖昧なところもありますがこのようなイメージで問題ありません。
ユーザーがリンクを自由に掲載できる場合の不正リンクへの対策
先述の通り、ユーザーが投稿できるタイプのコンテンツで、誰でもリンクを掲載することが許可されている場合、信頼できないサイトへリンクが向けられる可能性があるため（出会い系やアダルトサイトなどのスパムコメントなどが良い例）、それをGoogleに辿らせない＆評価の対象としないために使います。
昔はUGCがここまで普及していたのでほぼ全てのリンクはサイト管理者の制御のもとで掲載されていましたが、UGCが普及したことで誰でも簡単にリンクを貼ることが出来るようになり、その中で自作自演やスパムなどが増えてくると、外部サイトへのリンクには一律でnofollowなどの対応を取らざるを得ません。
※事実、近年では不正リンク対策として、有料ディレクトリ登録サービスや無料ブログサービスの外部サイトへのリンクの多くもnofollowを付与するように変更されてきています。
検索エンジンがデータ収集する価値のないページへのクロールの制御
よく言われているのはログインページなど、Googlebotがそのコンテンツの中身を収集出来ない場合です。砕けて言えば「そこクロールしても何も見れないから他のとこ見に行ってちょうだい」という意味ですね。
それであれば使う意味は確かにあるような気がしますが、いちいちそんな細かいこと考える必要もないんじゃないでしょうかとも思っています。大きな効果があるとは思えませんし。
あとこの意図で使うとすると、ほとんどのサイトは意識する必要はないと思うのですが、大規模なサイトを運営していて、本来クロール不要なURLへのリンクが不可避に大量に生成されるがrobots.txtでブロックする必要がない、或いはrobots.txtでリアルタイムに弾いていくのが運用上現実的ではない、などの場合でしょうか。
※ただし不要なはずのURLが大量に生成されるというのは、それはnoindexとかnofollowでどうこうじゃなくてその仕様を適切な形に変更すれば良い、というケースも割合多そうですが。。
よほどのことが無ければ、ほとんどの場合はウェブマスターツールのパラメータ制御機能で上手く調整すれば良いレベルだと感じています。（すみません、ここは正直言いきる自信がないです。）
Google的には”真っ黒”な完全アウトサイダーなサイトへリンクをせざるを得ない場合
これは正直ちょっと自分でも確信はなくて、賛否両論あると思うのですが。
仮に自社の関連サイトだったとしても、リンク先のページが大規模な不正リンクプログラムなどの中心にいる場合、或いは重度のペナルティを受けている場合など、リンクを掲載することでそのサイトとの（リンクの繋がりとしての）距離が近くなってしまいます。
でも関連サイトですし、Google的に真っ黒であることとユーザーに見せたくないことは全く違いますので、リンクを外す理由にはなりません。放置でも良いのかもしれませんが、個人的にはこういうリンクの繋がりの全体像を想像するとこれはちょっと気持ち悪いし嫌なのですね。
それを避けるためにnofollowを掲載するよう提案したことはあります。
どのケースも多少の効果はあったように見えましたが、正直言えば因果関係は曖昧ですのでここは参考程度にして下さい。冒頭でも書きましたが、ほとんどの場合は有効なPageRankを破棄することでもありますのでこんなことしない方が良いのは間違いありません。
とまあ、いくつか挙げてみましたが、少なくとも一般的な中小規模の商用サイトでnofollowを当然のように使う、どこでnofollowを付与するかをじっくり考える、などということはほとんど無いなあとは思っています。
なぜ、テクニカルなことをしたがるのか
ドラクエで新しい呪文を覚えると、誰もが”絶対に必要ないけど使わざるを得ない”みたいな精神状態に追い込まれます。
例えば敵グループが複数に分かれていて、どう考えても賢者としてはヒャダインかイオラあたりで対応するようなシーンなのに、1ターン目でなぜか敵単体に向かって新しく覚えたベギラゴンを唱えてしまうなどの事例が挙げられます。
特に画面演出のないドラクエ4以前であっても、同様の現象が必ずと言っていいほど起きますね。
それと全く同じです。少し勉強して知識がつくと、絶対に必要ないのにcanonicalとかnoindexとかnofollowとかrobots.txtを駆使してクローラーの色々制御してみようなどと思ってしまったり。しかしほとんどの場合が「しかしなにもおこらなかった」です（逆に大ダメージを受けることはありえます）。
例えば、昨年にrobots.txtについて詳細に記事にまとめられていたブログがありましたが、（おそらく記事執筆時に調べながら追記したであろう）robots.txtの記述が誤っていて、全てのページがクロール拒否になっていたということは記憶にあたらしいです。ちなみにその後きちんと修正されていました。
まとめ
普通にサイトを運営していれば「ほとんどのページはクロールされ、インデックスさせるべきコンテンツ」なはずです。外部サイトであっても、nofollowを付与する必要のあるようなサイトにリンクすることは滅多にないはずです。
少なくとも、敵グループが多数に分散していたら、多くの場合は素直にイオ系呪文で対応しておくのが良いかと思います。
ヴォラーレ株式会社 土居
Googleがアルゴリズムを変更する目的とSEOの役割
ご存じの通り、Googleというシステムには日々様々な変更が加えられています。それに伴い、SEOを行う際に気をつけた方が良いこと、逆に気にしなくて良くなったこと、なども継続的に発生し、日々の情報収集と定期的な知識のアップデートが求められることは間違いありません。
しかし、そのようにGoogleに変更が加えられること、それに伴いSEOにも変更が必要になる場合があることなどから、「SEOはGoogleとのイタチごっこ」のような偏った理解をされている方や、逆に「SEOの時代は終わった、これから必要なのはSEOではない」などの極端な解釈をされている方が多いです。
出尽くした感の否めない話題ですが、改めてそのあたりについて整理しました。
改めて、検索エンジンについて理解する
Googleという検索サービスのビジネスについて、最近東証一部に上場されたファンコミュニケーションズの柳澤社長（@ankeiy）がこれ以上ないくらい端的に表現されていたので引用させて頂きます。
Googleは天使でも悪魔でもありません。情報整理して、利用してもらい、広告で商売しているだけです。それだけです。
— 柳澤安慶(二丁目ではヤナティ） (@ankeiy) 2013, 11月 22
Googleは世界中の情報をクローラーというプログラムで収集し、検索して取り出しやすいようにインデックス（索引）化し、検索キーワードが送信された際にその言葉の意味や検索の意図を理解し、ランキングアルゴリズム（≒ランキング算出ロジック）に基づき検索結果に表示する順序を決めて、それを検索結果に表示します。
ここで表示された検索結果が検索ユーザーにとって都合の良いものであればあるほどツールとしての利用価値は高いと言えますし、利用ユーザー数の獲得や利用頻度の向上につながります。
一方で、GoogleはAdWordsという広告プラットフォームを広告主に公開し、検索キーワードと関連性の高い広告を検索結果に表示できる仕組みを持っています。この広告がクリックされた時点で、Googleには広告収益が発生します。
従って、シンプルに考えてしまえば、検索ツールの利用者数や利用頻度が増えれば、総合的に検索結果に広告が表示される回数や広告クリック数が増え、結果としてGoogleの収益も増える、と言えますね。
つまりGoogleが検索ツールとしての収益を高めるためには、まず基本的な取り組みとして検索ツールの利用価値を高める、つまり「検索した人が見たい情報にすぐに辿りつける検索ツール」にするような取り組みが継続的に必要になるのです。
今のGoogleは完璧なシステムではない
前の記事の中でも触れた内容なのですが、文脈的にこちらでも引用しておきます。
不完全というのはどういう根拠のもとで言っているかと言えば、
・検索する人が検索する言葉をある程度考えて打ちこまないとうまく欲しい情報に辿りつけないことが多い
・サイトが検索エンジンが理解できるように作られていないときちんとヒットしないことが多い
・ユーザーが本来求めていないような情報が上位に表示されることが多いなどの点からです。
ということですね。
つまり、適切な検索キーワードが上手く思いつかなかったり、見たいサイトが検索エンジンにとって読み取りにくい仕様で作られていたりすればユーザーは見たい情報に辿りつけませんし、また、未だに内容として間違いだらけの情報が上位に表示されていたりもするわけです。
Googleは何のために日々の変更を行っているのか？
Googleが今の時点で理想とは言えないのであれば、当然そのギャップを埋めていくために様々な改善を加えていく必要があります。いわゆる「アルゴリズム更新」なんていうのもこの一環です。変わるのはアルゴリズムだけではなく、先ほどの
世界中の情報をクローラーというプログラムで収集し、検索して取り出しやすいようにインデックス（索引）化し、検索キーワードが送信された際にその言葉の意味や検索の意図を理解し、ランキングアルゴリズム（≒ランキング算出ロジック）に基づき検索結果に表示する順序を決めて、それを検索結果に表示する
という、一連のプロセスを実行するための仕組み全般において様々な変更が日々加えられています。実際には、これに加えて、不正な手法でランキングを操作しているサイトを人為的なオペレーションのもとでランクを下げるなどのスパム対策（手動対応）も取られたりしています。
Googleはとにかく、検索ユーザーに対してより理想に近い検索結果を返すために出来ることは何でもやろうとする、ということです。イメージとしてはこんな感じでしょうか（今やってるセミナーの資料から抜粋）。
例えばですが、昨年に実施された「ハミングバード・アップデート」について、あまりこうした話題に不慣れな方々が「ハミングバードによってリンクやSEO会社の出る幕は終わった、よりコンテンツが重要視される時代に」と言うような主旨のエントリーが書かれているのをいくらか見かけました。
しかし実際にはハミングバードとは、リンク評価やコンテンツの評価などではなく、上図で言う「検索された言葉の意味や意図をより的確に把握するため」のアップデートです。
具体的には、フレーズや言葉ではなくて、（音声検索の普及などを見越して）「会話型の検索キーワード」を今までより適切に解釈して上手く処理できるようになりました、と言った趣旨の変更でした。
では、SEOの役割とは？
Googleが検索結果の改善のために様々な取り組みを行っている一方で、ではSEOという考え方はどのような役割を果たすべきなのか？と考えてみましょう。先ほどの図の延長で見ればこういうことでしょうか。やや無理やり感がありますが。
Googleが、自社システムの不完全な部分を埋めるための取り組みを行っているのに対して、SEOは、現状のシステムの性能、将来的な検索エンジンの向かう先を理解をした上で、多くの検索ユーザーが検索結果を通じてサイトに辿りつける、という状態を安定して作っておくために行われるものなのです。
その中で、直接的なビジネスへの貢献度が高い（≒売上に直結しやすい）一部の商用キーワードにおいては、そのポジション争いが熾烈となり、過剰な手法を用いてランキングを上げようとする対策が蔓延しており、それがいわゆるブラックハットSEOと括られるものです。日本で「SEO」と称されているものの多くは、ここの部分を指して言われているものなのです。なので話が時折おかしな方向に行くんですね。
しかし、これは検索結果全体からみればごく一部の検索結果で苛烈に発生していることであり、大半の検索結果においてはそうしたものとはほぼ無関係です（なぜなら皆さんは普段買い物をするためだけに検索をするわけではありませんよね？）。
とにかく、SEOはGoogleの不完全さを、技術的またはマーケティング的なアプローチを以て補完し、サイトを検索から辿りつける状態にするための取り組み、と言えるものなのです。
「SEOはGoogleとのイタチごっこ」というのは本当なの？
もちろん本当ではありません。ただし、これは全くの間違いですかと言えばそうではなく、何かものすごく偏った、というかごく一部の側面だけを切り出した視点からの表現と言えます。具体的には、
- SEOとは、Googleの意図と関係なくランキングを操作する手法である
- Googleは、そうした手法を駆逐するために日々アルゴリズム変更を実施している
- SEOとGoolgeは、そうした意味で対立関係にあるものである
こうした偏った観点でのSEOとGoogleの考え方である、と言って良いと思います。
実際には、そもそもSEOの意図はそういうところではありませんし、Googleの変更は不正な手法の排除だけでは決してありませんし（スパム対策は検索結果の品質改善の取り組みのうちの一部でしかない）、SEOとGoogleは本来は先ほどお伝えしたように補完関係にあるはずのものです。
もともと、ちょっとしたサイトのチューニングと、人為的にリンクを増やして上位表示する、ということがSEOとして普及してきていたので、そういう視点で見るのであれば、逆にこういう表現がシックリ来るのは間違いないと思いますが。
SEOというアプローチそれ自体を見限るということは、場合によっては本来得られるべき自然検索トラフィックの多くを放棄することにもつながります。検索トラフィックはまだまだWeb全般で見たときには非常に大きなインパクトのあるものです。SEOを正しく理解し、またその重要度について正しく評価できることが重要です。
Googleは完璧な検索システムになり得るか？
まず、完璧なシステムって何よ？というとどういうことかと言えば、例えば
- ユーザーが今欲しい情報を完璧に理解できるようになったとき
- ユーザーと全く同じようにコンテンツを閲覧できるようになったとき
- ユーザーが欲しい情報を有機的に判別できるようになったとき
のようなことが実現出来れば、今の発展形としてはかなり理想に近い検索ツールと言えると思います。そしてこうなれば、今のSEOノウハウなどとされているものの大半は無用の長物になっているでしょう。
しかし、完璧になる時代って訪れるんでしょうか？と言うと、少なくとも当分は訪れないと思います。少なくとも、今の「検索」という形式を取っている以上はなかなか難しいのではないでしょうか。
万人共通のベストアンサーがあるわけでもなければ、同じような情報を求めていたとしてもシチュエーションに応じて本来ベストなアンサーは異なるでしょうし、そこまで含めて全ての検索に対して常に最適解を提示できるというのはちょっと想像が出来ませんね。
Googleが多くの人に使われている中で、それが検索システムとして完璧でないのであれば、それを補完する技術としてSEOはまだまだ必要、と言えると思います。
まとめ
Googleは不完全なシステムですし、検索技術が進歩しても完璧なシステムがすぐに出来上がるわけではない以上、それを補完する（＝検索サービスと、Webサイトと、検索ユーザーをつなぐ）ための技術は必要で、それがSEOです。
人々の情報探索行動の中で「検索すること」が重要なファクターである以上は、SEOは終わりませんし、変わらず重要な取り組みと言えます。それだけで物事が全て解決するわけではないというのは間違いありませんが、面倒で難しいからという理由でSEOを放棄するのはただ勿体ないとしか言いようがありません。
初心者向けの内容とは言え、ここに書かれている内容は、SEOに関わる人は全員が共通認識としてもっておいたほうが良い内容と思っています。少しでもためになったとか役に立ちそうと思った方は是非シェアなりブックマークなりして頂けると幸いです。
ヴォラーレ株式会社 土居
これからSEOを始める方に、最初に知っておいて欲しいこと
新入社員として、あるいは部署移動などをきっかけに、4月からSEOの仕事をされるという方は多いと思います。しかしSEOの仕事とひとくちに言いましても、コツさえつかめば誰もが簡単に上手くできるようになります、というほど難易度の低い仕事ではないと思っています。
まがりなりにもこの業界でSEOに関わるような仕事を始めてから5年程度たちますので、決してベテランとは言えませんがそれでもこれから同じような仕事をする人に対して色々アドバイス出来ることはあるかと思いますので書きました。
この3つを前提としておきましょう
最初は10個くらい挙げていたのですが、だいたい同じようなこと言っているなと感じたので3つにまとめました。
- SEOでは全ての問題を解決できません
- 今のGoogleは完全なものではありません
- アルゴリズムが公開されなくても基本的なやるべきことは分かります
１つずつざーっと説明していきます。
SEOでは全ての問題を解決できません
SEOに過剰な期待を持ってしまったり、ある種の全能感みたいなものを持ってしまわないようにしましょう、ということです。まずは、この前提をきちんと理解することから始めます。
SEOを成功させることが、必ずしもサイトの改善にとって最短でも最善でもない場合はいくらでもあります。そういう場合には、SEOの効果を盲信してしまうことはその他の色々な可能性を狭めてしまうことに直結します。
SEOはあくまでも検索者とサイト運営者が検索結果を通じて接点を得られる機会を増やすための取り組みです。簡単に言えば検索結果での露出を高めるための取り組みです。
その視点で極端な話で言えば、サイトに掲載されている情報を誰も検索して探そうとはしていない、のであればSEOにコストをかける意味はありません。
つまりは、どの程度の問題を解決できるのかと言えばサイトによって様々で、自然検索トラフィックがどの程度ビジネスにとって重要なものなのかということに依存します、ということです。
また、SEOの仕事をする人がこういう視点でしかサイトを見れないようになってしまうと、「良いサイト＝SEOに優れたサイト」のような狭い価値観になります。少なくとも、依頼者の視点に立てば、そういう人に自分のWebサイトの相談をするだろうか？ということを考えてみると良いと思います。
今のGoogleは完全なものではありません
不完全というのはどういう根拠のもとで言っているかと言えば、
- 検索する人が検索する言葉をある程度考えて打ちこまないとうまく欲しい情報に辿りつけないことが多い
- サイトが検索エンジンが理解できるように作られていないときちんとヒットしないことが多い
- ユーザーが本来求めていないような情報が上位に表示されることが多い
などの点からです。
日本語でくくってしまえば、Web上の情報を収集したり整理したりする仕組みの性能、検索された言葉の意図の解釈の精度、ランキング決定のためのルールの精度、などまだまだ改善されていく余地は全然ありますよね、ということです。
ユーザーが欲しいと思っているベストな情報に検索を通じて瞬時にアクセスできる、という点をひとまず検索エンジンが目指している1つの目標とするのであれば、まだまだ遠い場所にいるのかなという所感です。
しかし、ある程度色んな勉強をしたうえで、色んなキーワードでの上位表示サイトとかの分析みたいなことをやったり自分である程度思った通りの成果が出せるようになると、突然「なんかGoogleのアルゴリズム掴んじゃったかも」という感覚に襲われたりすることもあります。
これは断言できますけどその感覚は100％単なる勘違いです。全部なんて見えるわけありません。傾向とか○○の点で改善してきているとかそういうことはもちろん日々の検索結果のリサーチで把握可能なものだと思いますが。
まだシステムとして不完全なもので不具合的な要素だって検索結果には多分に含まれていて日常的に変更が加えられているアルゴリズムに、手動対応などの人的要素がそこに加わっていて、更に人的な対応のルールすら固まっていない（頻繁にルールややり方に調整が入っている）ような印象を受けています。
つまるところ、バグとか曖昧なルールとか目下改善中とか目下テスト中の項目だってたくさんあるわけで、そういう検索結果を僕らは見ているわけですね。
ちなみに、「掴んだわ」的なことを言う人、あるいは掴めるものと信じて止まない人の特徴として、Googleというシステムの未熟さには気付きつつも、一方でものすごく不変的かつある意味で完璧な何かを期待していることが多いと思います。
ただ、実際にはそういう人が思っている以上にものすごく流動的かつ曖昧な要素が多い、という前提で考えなければいけないのです。
もちろん僕も昔は「なんか掴んだ気がする。分かってきた」とか言ってた時期がありました。本当ごめんなさい。
アルゴリズムが公開されなくても基本的なやるべきことは分かります
先ほどとは逆の議論として、「Googleのアルゴリズムはブラックボックスなので」というのは非常に違和感あって僕は使わないようにしています。まあ確かに全部が見えないという意味ではブラックボックスではあるのですが、大きな影響のある変更や、一般的に常識となっているような評価項目などについてはある程度までは情報も公開されていますし。
実際には、「検索結果にどのように反映されるか（何番目にランクされるか）は最終的には分からない」だけであって、「何をすればもっと改善するのか」は分かります。それをとにかくやってみてどこまでそれを評価してもらえるかを検索エンジンの今の不完全な評価システムに委ねるわけですね。
例えば、の話ですが。
「このサイトが3位、このサイトが6位となかなか上位にいるのですが弊社のサイトは9位にいます。この差はなんですか？」というような質問はたまにありますが残念ながら僕は答えられません。次の日になって検索結果上位のサイトがガラっと入れ替わっていることも多分にありますし、そうなった場合はその時に話したことは根拠を失うためです。
ここについては「考えても分からんものは分からん」という明確な割り切りが必要です。
ただ「こういう目標に対して、今どういうところに課題や不足があって、これから何をすればもっと良くなるでしょうか」であればいくらでも妥当な提案は出せると思います。その前に目標の見直しが必要な場合も多分にあるでしょうし。
どのような状況、どのようなサイトであれ、大枠としてやるべきことは割と明確なのです。
- 検索されることを考慮したサイトの設計、出現語句の最適化
- クローラー等の性能に合わせた技術面での最適化
- 長期的にビジネスに貢献し得るコンテンツの作成＋リンクやシェアの獲得
まとめて括ってしまえば、かなり乱暴ですがこれくらいの3つくらいにまとめることは出来るとは思っています。そしてこのうちの1つでも著しく欠如しているとそれだけでSEOは減速します。
ですのでSEOをしっかりやるのであれば、上記のような項目それぞれについて改善の余地があれば、伸び白の大きいもの（出来ればコストのかからないもの）から順々にやっていくようなイメージです。
もちろん、コンテンツ→リンクの取り組みは、最終的には地道に継続することでしか成功し得ないものでもありますのでここのあたりは工夫と根気が必要です。
ただ、これはあくまでもしっかりSEOをやりきる上で、の話であって、実際にはサイトを作るときにはビジネスサイドの要求、UIやビジュアルデザイン面の要求、SEO上の要求などがところどころで衝突する場面が出てきますし、全てにおいてSEO側の事情を優先させるということはほとんどありません。
ですので前提として、SEOの仕事をする人は、そのサイトにおけるSEOの重要度を正しく評価できる必要があります。この辺は結構ひとくくりに言えない部分なので難しいことですね。
※ちなみに今月は自分でも制作とか開発の人のためのSEOセミナーやりますけど、こういう話題にも少し触れますので興味ありましたら是非。
最後に、SEOの仕事に必要な能力は半端なく広く深いものです
冒頭で5年くらいSEOの仕事に関わってきました、というお話をしましたが、やるべきことがある程度分かったとしても企画～制作～運用改善まであらゆるフェーズで求められるSEOのスキルを全てカバーしてくのはかなり大変だと思います。
自分で言うのも気持ち悪いですが、個人的には自分は決して学習能力の低い方ではないとは思っていますが、今はもちろん、正直今後も全部なんて到底カバーしきれる気がしません。自分がここまでやってこの程度なのだから、という逆の意味での自信は最近になってようやく少しずつついてきたところです。
言いたいことは、そうそう簡単な仕事だと思って甘くみて欲しくはないですけれども、しっかり勉強すれば、その分しっかり成果の出せる仕事ではあります。一定水準をクリアしているSEOのプレイヤーの母数に対して、潜在的なSEOの需要が過剰にある環境だと思いますので、そういう意味でもチャレンジし甲斐のあるテーマではないかなと思います。
以上、これからSEOを専門で仕事とされる方に参考にして頂ければと思います。
ヴォラーレ株式会社 土居
SEOに有利？不利？エンジニアが見るHTML5とSEO
弊社はSEOのサービスを提供している関係上、直接コンサルティングには直接携わらないエンジニアでも、時折SEOに関する質問をされる機会は少なくありません。なかでもしばしば尋ねられるのが、SEOとHTML5の話題です。いまさらという感は否めませんが、本記事ではHTML5とSEOの関係についてざっくりと述べてみたいと思います。
HTML5とは
「HTML5」と言う場合、単純なマークアップ言語としてのHTML5をさす場合と、その関連技術を含む広義のHTML5をさす場合があります。
狭義のHTML5は、HTML4.0、XHTML1.1などと同列の、テキストを構造化するマークアップ言語です。要素の追加や変更、新たに導入された概念などの違いがあります。ただし既存の(X)HTMLとの互換性もある程度維持されており、本質的にはこれまでの(X)HTMLと大きな違いはありません。
一般的にHTML5といった場合、単純なマークアップ言語としての側面だけでなく、WebStorage、WebSocketなどのAPIも含めてHTML5と言われることが多いと思います。文脈によってはCSS3やSVG、WebGLといった技術も含めてHTML5と呼ばれることもあるようです。
本記事では、初めにマークアップ言語としてのHTML5について述べ、後半ではAPIの話題にも軽く触れておきたいと思います。
マークアップ言語としてのHTML5とSEO
マークアップ言語としてのHTML5を見たとき、HTML5にはどのような特徴があるのでしょうか？主な特徴として以下のようなものがあると考えています。
- コンテンツ・モデルとカテゴリーの導入
- 要素の追加、廃止と意味付けの変更
以上の点を、以下で少しだけ解説します。
コンテンツ・モデルとカテゴリーの導入
HTML4.0で定義されていた要素には、ブロック要素とインライン要素があり、インライン要素の中にブロック要素を入れてはいけないなどのルールが存在しました。例えば、インライン要素であるa要素を、ブロック要素であるdiv要素の中には入れることができないといったルールです。
このルールに従った場合、例えば以下のようなマークアップは認められません。
<a href=“http://www.seohacks.net/”><div>SEO HACKS</div></a>
例. HTML4.0における間違った要素の配置
HTML5では、このブロック要素とインライン要素に代わり、カテゴリーとコンテンツ・モデルという概念が定義されました。
カテゴリーとは、その要素が定義された目的を示すものです。例えば、body要素の中に設置できる要素はフロー・コンテンツというカテゴリーに属しますし、文章の章や段落を定義する要素は、セクショニング・コンテンツというカテゴリーに属します。
それぞれの要素で、中にどのカテゴリーの要素を含めてもよいか？というルールを表したのがコンテンツ・モデルになります。例えば、section要素のコンテンツ・モデルはフロー・コンテンツとセクショニング・コンテンツなので、このいずれかのカテゴリーに該当する要素を中に含めてよいことになります。
要素の追加、廃止と意味付けの変更
HTML5では、新たに追加された要素、廃止された要素、そして引き続き存続し続けるものの、意味付けの変更されているものが存在します。
追加された要素としては、article、section、header、asideなど文章構造を表現する要素や、embed、video、audioなどのインタラクティブな要素を表すものなどが追加されています。こうした要素の追加により、より文章の構造的意味を明確に示すことができるようになったり、インタラクティブなページの構成ができるようになりました。
一方で廃止された要素もあります。廃止された要素は、big、center、fontなどの見た目を定義していた要素や、frame、framesetのようなフレームに関する要素などです。これらの要素はCSSを使用したり、他の代替候補となるタグをすれば問題ないでしょう。
b、iなど、廃止ではないものの、以前のバージョンのHTMLから、意味付けが変更された要素もあります。例えばb要素はこれまで太字を現す要素で、かつ太字で現すという意味での仕様は非推奨とされていますが、HTML5では他と区別して表記すべきフレーズを示す要素となりました。
具体例 – hx要素のマークアップ
さて、HTML5によって変わる具体的な例として、SEO上も重要といわれる見出し要素のマークアップを考えてみましょう。見出しを表すh1〜h6要素はHTML4.01の場合、1〜6という数字でそのランクを示します。
<h1>見出しレベル１</h1>
<div>
<h2>見出しレベル２</h2>
<div>
</div>
<h2>見出しレベル２</h2>
<div>
</div>
</div>
例. HTMLの見出しレベル分け（HTML5でも有効）
最上位の見出しであるh1要素はSEO上、1つの文書内で1度しか利用できないというルールがありました。HTML5の場合も、このルールに従っていれば何ら問題はありません。
一方でHTML5の場合、新たに追加されたsection要素のようなセクショニング・コンテンツの深さを使ってセクションを表現することもできます。以下のようなケースでは、h1要素を複数使用されていても、それぞれのセクションにおける見出しのレベルを区別できるようになっています。
<section>
<h1>見出しレベル1</h1>
<section>
<h1>見出しレベル２</h1>
</section>
<section>
<h1>見出しレベル２</h1>
</section>
</section>
例. HTML5ではこのような見出しの使い方も認められる
とはいえ、HTML5では既存の方法によるマークアップも可能です。当然の疑問として、どちらの方法を使うのが良いか？ということになりますが、上述の２つの例に優劣はありません。単に選択肢が増えただけなので、使いやすい方を選べばよいでしょう。
HTML5はSEOに有利なのか？
ここまで、HTML5におけるマークアップ言語として変わった点をごく簡単に記載しました。HTML5はSEOに対してどういった影響を与えるのでしょうか？結論だけ先に述べますと、HTML5の使用は、SEOに有利とも不利ともいえないと考えています。
確かにHTML5を使用することで、以前のバージョンのHTMLに比べ、より文章構造を明確することができ、サーチエンジンにとってもより文章の示す意味を解釈しやすくなったのは事実です。また、HTML5に追加されたインタラクティブ・コンテンツや、後述するAPIを利用すれば、よりリッチなコンテンツを記述することができます。
しかしながら単なるフォーマットの違いです。XHTMLで記述していた文書が、HTML5になることによって、ページそのものの価値が高くなったりすることはあるでしょうか？利用するサイトがHTML4.01なのかHTML5なのか、を気にする一般ユーザーはほとんどいないはずです。
新規でサイトを作る場合や、サイトのフルリニューアル時にHTML5を選択するのはありだと思います。しかし、SEO目的で既にHTML4.0やXHTMLで構成されているサイトをそのままHTML5に書き直すといったことは全く必要ないでしょう。
Web周辺技術としてのHTML5
HTML5のカバーする領域は非常に幅広く、マークアップ言語の側面のみならず、JavaScriptを介して扱うAPIや、WebSocketなどの関連技術もその範囲に含まれます。例えばWebStorage、WebSocket、Paging APIといったものが該当します。非常に幅広い領域のAPIが定義されており、全てを紹介しきることは到底できませんので、少しでもSEOに関係のありそうなAPIを簡単に紹介させていただこうと思います。
表示速度を計測する「Navigation Timing API」
Webサイトを見るときには、リンクをクリックしたり、アドレスバーにURLやキーワードを打ち込んだりすると思います。大抵のサイトでは、１秒〜せいぜい数秒の内にページが表示されるはずです。利用するユーザにとっては一瞬のできごとですが、ブラウザ上で見たいページをリクエストしてから実際にWebサイトが表示されるまでには、いくつかの段階を経ています。Navigation Timing APIとは、一言で言えばこの”いくつかの段階”として示しているものを共通化して、表示速度の記録・参照が可能なAPIです。
W3Cから拝借したNavigation Timing APIについてのドキュメント図では、以下のようなフェーズに分けられています。
Navigation Timing API
このAPIは、通常のWebサイト上で利用するものではありませんが、Chromeのデベロッパーツールなどではこのフェーズを閲覧することができます。またGoogle Analyticsの「サイトの速度」で表示出来る時間も、このNavigation Timing APIにより測定されているものだと思います。
SEO上は小さなファクターであるものの、ユーザーエクスペリエンス的な側面も考えると、サイトの表示速度は決して無視できるものではありません。
以前、別の記事でWebサイトの高速化に関するトピックを紹介しました。このAPIを利用すると、こうした高速化による改善状況などを定量的に計測することができます。具体的な利用例としては、弊社開発室のブログでNavigation Timing APIを利用したツールでパフォーマンス測定を自動化するというトピックを紹介しておりますので、よければそちらも参照ください。
より詳しい解説は外部のサイトに譲りますので、このようなAPIも利用できることだけ知っていただければ十分です。
画面遷移せずに履歴を操作する「History API」
いわゆる“Ajax”を多用したサイトでは、画面の遷移なくコンテンツを書き換えたりすることが行われます。一方で、クローラーは１つのURLを１ページとして認識するため、このようなサイトのコンテンツを意図通りにインデックスさせることが困難でした。
上述のようなAjaxを使用したページをインデックスさせる方法として、Googleは#!(hashbang)を使ってAjaxアプリケーションをクロールさせる方法を提示していましたが、複雑な仕様で誰しもが利用できる仕様とはいえませんでした。
これを代替する手段として、近年はpushStateの利用を推奨しているようです。
pushStateは、HTML5で定義されているHistory APIの機能の１つで、画面遷移せずにブラウザの履歴にURLを追加することができる機能です。画面遷移をせずにAjaxを使ってコンテンツの書き換えを実現したい場合、pushStateを使えばコンテンツの書き換えと同時にURLも変更することができます。
もちろんAjaxを使わずとも閲覧できるサイトのほうが検索エンジンライクなのは間違いないと思いますが、必ずしもSEOが最重要のファクターである、というケースばかりではないと思います。検索エンジンには独立したページとしてインデックスさせたいといったニーズがある場合、利用を検討してみるのも良いのではないでしょうか？
まとめ
本記事では、HTML5の概要や、HTML5とSEOとの関係、HTML5に含まれるAPIの一部を紹介しました。すでに述べた通り、HTML5を使うことそれ自体がSEO上特別有利になるとか、不利になることはないと考えています。
とはいうものの、HTML5について正しく理解しておくことや、HTML5で何ができるか？を知っておくことは、誤った使い方によるリスクを避けたり、取りうる選択肢を増やすという意味で重要と言えるのではないでしょうか。
ヴォラーレ株式会社 若松
URL正規化の方法、、の前に考えるべきこと
主に制作とか開発の仕事をされている方と話していて、URL正規化についての考え方、についてちょっと違うんじゃないのと思うことがあるので書きます。すごく基本的なことなのですが、あまり話題として触れられていないように思ったので。
URLの正規化とは何ぞ、という方にまず解説
検索すればそういう記事はとてもたくさん出てきますが、サッパリでピンと来ませんという人のために、かなり粗いんですけど例えを入れておきますね。まずはイメージから。
例えばSalesforceみたいな基幹システムを色んな人が好き勝手触ってると、いつの間にかどんどんデータが乱れてくることってありますよね。その中でも結構やっかいなのがこういうデータの重複登録問題。
例えばですが、こういう感じですね。こうなってしまうと企業データを検索して新しいデータ入力しようとしたりするときに無駄な確認とか処理が発生しますよね。もちろんトラブルの原因にもなるのでこれはよろしくないです。
で、こういう風に「複数存在してしまっているけど実質同じものはひとつにまとめた方が良いよね」というのがいわゆるSEOの正規化のイメージです。
(補足)
もともと正規化って「”名寄せ”みたいな感じ」って言ったほうが近いものがあるかもしれませんが、SEOの話題としては必ずしも名寄せとは感覚が同じでない場合とかもあるのでそういうことにしておきます。
どっちにしても「1つであるべきデータがバラバラになっていたら管理とか処理にあたって色々不都合ありますよね」ということだと思っていて下さい。
SEOでいうところの正規化について
SEOでいうところの正規化のイメージは、「複数の異なるURLに同じコンテンツが存在する場合、どのURLを検索エンジンが評価すれば良いのかを1つ定めてそこに評価をまとめる」ということです。
検索エンジンも、同じコンテンツなのに別々のURLでそれが返されてしまうと、「どれを見ればいいんだろ？」ということになって正しい処理が行われなかったり、少なくとも無駄な処理をさせることにはなってしまうわけですね。
規模や内容によりますが、あまりにこうした問題がサイト全体で好き勝手に発生しまくっているという状況はSEO上かなりネガティブになり得ることですので、きちんと整備しておくことに越したことはありません。
さてようやく本題です。
まず最初に考えるべきは「重複させないための仕組み」
冒頭の例に戻りますが、ああいう形での重複データがあると、検索して最新状況確認する際に色んなとこに情報が散らばってたりしていて、「誰だよこっち書いた奴、こっちにまとめろよ」みたいなことになるわけですね。
この状態は間違いなく色々不便かつ正しくない状態なので、避けるべきことです。
1つ2つあるだけならまだしも、これが数百とかに渡って大量の重複データがシステム内に存在する、あちこちに情報が散乱してまとまってない、みたいな状態になっていたらもうカオスですよね。
で、この時にその部署の管理者が真っ先に考えるべきことって、「重複が原因で顧客データに不備があってで何かトラブルが発生したときの対応策」とか「重複データをどのデータにまとめるかのルール」ではなくて「重複データが発生しないための仕組み」ですよね。
予めシステム側で上手く照合されるように良い塩梅の条件決めておくとか、オペレーター側での指導や管理の徹底だったりとか、そういうことで問題が起こらないように仕組みを作っておくわけです。
最近LINEマンガでROOKIESを久々に読んだのですが、
「あらかじめ打球を予測していとも簡単に捕る。それが本当のファインプレーだ」
と池辺教頭もおっしゃっていまして、それと同じ理屈です。
コンテンツに対してURLが一意であることが理想
SEOに話を戻します。前の話をURL正規化の話に無理やり帰着させて、「URLがばらけるから正規化しよう」ではなくて「URLがばらけないように作ろう」が先にあるべきだ、という話ですね。
テクニカルに「こうすればいいんです！」みたいな応急処置を積み重ねていくと、後々どこでどんな処理をしていたかとか分からなくなったりリニューアルの際に抜け漏れが発生したり、あまり良いことはありません。
もちろん、www.とか拡張子とか「/」有無とかutm系のパラメータとかそういう当たり前に発生するものはいつも通りの転送やcanonicalなどで正規化処理をする必要がありますので（今回は解説割愛）、そういうもの以外での不要な正規化処理を避けようとすることが大事ということです。
分かりやすい例で言えばクロスカテゴリ（財布(アイテム)×シャネル(ブランド)みたいにあるカテゴリと別のカテゴリとの掛け合わせ）が発生するようなサイトでこういう形を稀に見ます。
こういう仕様でガッチリとシステムを固めてしまうとあまり簡単にはいじれなくなりますので無理やりcanonicalで対応するような処理をする必要が出てきます。
この場合は、複数の可能性が考えられる経路やカテゴリに、クロスカテゴリのURLや商品ページのURLが依存してしまってるのが問題ですね。
これは一例ですが、このように商品のURLはカテゴリや経路に依存しない仕様にしておかないと、というような配慮があれば正規化処理などここではもともと考える必要もなかったわけです。
よほど大規模だったり複雑なサイトでなければ、最初にURLについて考えておけば大抵の問題は回避できるんじゃないかなと思います。それなのに「URLもちゃんと考えておかないと」って考えて設計しようとしている方って意外に少ない気がします。
あるコンテンツに対してURLは一意、が基本
「ひとつのコンテンツに対してURLがひとつ」であるべきで、余計な正規化処理をしなくてよいURLの設計を心がけてみてください。
SEOってサイトとかページとかではなく本質的にはURL単位でクロールされ、URL単位でインデックスに格納され、URL単位で評価が付きます。そういう意味ではURL設計を考慮することは基本的なSEOのひとつです。
仕事柄、色んなエンジニアの方と話す機会ありますが、「URLをどう吐きだすかとか深く考えたことなかったッスねー」という感じの人は （受託開発してるとかメディア運営してるとか関わらず）多かったりします。
特に幅広いコンテンツを扱うとか大量のコンテンツを扱う、とかの場合、このあたりのURLの考慮の有無によって後々余分な処理をするための工期が削減できる、改修や拡張が入った時にも変更が少なくて済む、変更が少なくて済むということは実装ミスによる検索トラフィック損失などのリスクが減らせる、というわけです。
補足：検索エンジンが進化しても機械への配慮はしておく
「Googleも上手く対処できるようになってるから細かいことはあんまり気にしなくていいよ」とはGoogleがよく言っていることで、確かにそうなってきています。しかしここは受け手としては「検索エンジンの技術に合わせることに躍起になってコストかけなくていいよ（Googleが頑張るからさ）」と捉えたいところ。
サイトを作る方は、「それでもサイトを制作する時には(検索エンジンに限らず)機械への配慮を怠らない」と考えるべきと思います。SEOに限って言えば、そうすることで防げる損失がかなり大きい場合も珍しくありません。
ということで、この記事を読んで「へぇそういうこともあるのか」と感じた方は、是非参考にしてみてください。
ヴォラーレ株式会社 土居
SEOで本当によく見る”もったいない”内部リンク設計
SEOといえばコンテンツや外部リンクの話はしょっちゅう出てくるものの、内部リンクをどう作るかみたいな話はあまり出てこないな、という気がしています。今回は実はとても大切な内部リンクの、よくありがちなミスとその対策について見ていきたいと思います。
内部リンクの作り方は大事なのにあまり話題にならない
最近良く、SEOでリンク買うのはダメ→良いコンテンツを作ればいいんだ！という論調の記事を見かけることがありますが、ただコンテンツを充実させればいいというわけではありません。
もし良いコンテンツがあって多くのリンクを集めていたとしても、それを検索エンジンが正しく評価できる設計でサイトが作られていなければ、十分にSEOの効果が発揮されない場合も多くあります。
逆にいえば、ある程度の地盤となるコンテンツやリンクといったSEOの資産があれば、テクニカルな改善によってパフォーマンスは大きく向上します。
その重要な技術のひとつが内部リンクの構築方法です。ユーザーにとって内部リンクはページからページヘ快適に移動するための手段でありナビゲーションですが、SEOの観点からすると
- クローラーがサイト内を巡回するための経路
- サイトの構造やページ毎の意味情報を伝える手段
などの役割を果たします。
検索エンジンはページ内にあるリンクのURLを読み取ってクロール対象を決定します。また、内部リンクも外部リンクと同様、より多くのリンクが集まっているページが評価される仕組みになっています。
サイト内で適切にリンクの受け渡しを行い、重要なページに評価を集めるという施策を行うのは基本なのですが、意外とこのあたりのことをしっかり考えて作られているサイトはそこまで多くないように思います。
この記事では、内部リンクに関して良くみられる、適切とは言えない実装について解説します。
SEOでよく見る”もったいない”内部リンクの事例
現場でよくあるケースとしてはこういうのでしょうか。
- 重要なコンテンツがクロールされにくくなっている
- 検索結果に表示させる必要のないページが大量にインデックス対象になっている
- 重要なページにリンクが集められていない
- アンカーテキストにキーワードが含まれない
- 正規のURLにリンクされていない
以下、順番に見て行きます。
重要なコンテンツがクロールされにくくなっている
例えば、求人検索や物件検索、ホテルの予約などを行うサイトでよくありがちなのがこのパターンです。
検索エンジンは、HTML上にURLが記載され、aタグでリンクされているものはクロールの対象としてページランクを受け渡しますが、Javascriptで構築されたリンクやフォーム形式で取得するコンテンツを必ずしも正しく処理できるとは限りません。
トップページにフォームがポンとおいてあり、ユーザーはそこから目的のページを探せるけれど、静的なリンク（aタグで記述されたリンク）が設置されていないがために検索エンジンはその先のページを上手く把握できないようになっているサイトが多くあります。
※静的なリンクはないけどユーザーはコンテンツを見つけられる形式の例
Javascriptやフォーム形式が悪いということではなく、それだけでは検索エンジン最適化としては不十分ということです。検索流入口としたい(orなり得る)ページを正しくクロール・インデックスしてもらうには、タグでのリンクをきちんと設置する必要があります。
※検索エンジンもユーザーもコンテンツを見つけられる形式の例
※Javascriptやフォームのような形式であってもクローラーがユーザーに近しい動きをし、情報を取得するようにはなっていますが、それは「可能である」ということであって「何も問題がない」ということでは決してありません。この辺りは勘違いされている方が多いポイントですのでご注意ください。
検索結果に表示させる必要のないページが大量にインデックス対象になっている
サイト内のリンクを重要度の低いページにばかり流してしまっている、そもそも必要の無いページをクロールさせたりインデックスさせる要因になってしまっているという課題です。
様々パターンはあるのですが、制作担当者が良かれと思ってやっているのが裏目に出てしまっている例としてよく見るのが、インデックス数を増やすために細かくカテゴリを分けすぎている、などです。
例えば、検索できる求人ページが500あったとして、それを見つけるのに5000個のカテゴリはいらないわけですよね。一概には言えませんが、かなり細かく分けても数百もあれば検索条件としては十分なはずです（それで賄えないものはフリーワードなり他の探し方で補うなどが出来るはず）。
かつては、「インデックスされているページが多いほどSEOには良い」という理屈が実際に成り立ってしまっていた側面があり、その名残でとにかくページを増やすためだけに不要な（中身もなく、検索されることもないし、ユーザーも使用しないような）カテゴリを機械的に作りまくっている、というサイトを見かけます。
“コンテンツの品質”が評価として重要度を増して以降、こうしたほぼ存在意義を持たないページが量産されているようなサイトは検索結果で露出されにくくなっており、インデックスを整理するという意味でも内部リンクのコントロールは重要になっています。
重要なページにリンクを集められていない
先のパターンと表裏一体ではありますが、今度は上位表示されるべきページに対してリンクが集められていないというパターンです。
例えば、パンくずリストひとつを取り上げてみても、末端の詳細ページからいきなりトップページに戻ってしまっていて、SEOにとって重要な中間のカテゴリページにリンクが渡っていないというサイトはよくありますね。
パンくずリストはサイトの構造を検索エンジンが理解するためにシグナルとして使われる要素でもありますので、単に上位ページに戻れるという仕組みだけではなく、サイトの構造やコンテンツの従属関係を正しく伝えられなければなりません。
パンくずリストに限らず、図の良くない例のように重要なページに下位ページからリンクが返されていない場合、複合キーワードとしてヒットしてほしいい重要なキーワードでの評価を高められないため、露出の可能性が大きく下がってしまいます。
ここでも、サイト設計の段階でSEOを考慮しなければ修正がなかなか大変な場合も多いです。
アンカーテキストにキーワードが含まれない
アンカーテキストのキーワードマッチという点で言えばSEO上の重要度は以前よりも下がっているとは言え、特に理由がなければアンカーテキストは極力リンク先のページが何のページかが分かるように記述するべきです。
画像でリンクする場合にはalt属性に代替テキストを記述しなければなりませんが、その場合「画像を外してページを見た場合にどういうテキストでリンクされているか」を考えて代替テキストを作ります。
正規のURLにリンクされていない
www.の有無や拡張子（index.html）やスラッシュ有無など基本的な正規化処理は行われているのに、そのページに対するリンクは正規URLに向けられていないというケースもよく遭遇します。
余計なリダイレクトを挟むことはユーザーにも負担をかけSEO上もプラスにはなりませんので、面倒でもリンク先URLは書き換えておくべきです。
まとめ
以上、SEO実務上よく出会う不適切な内部リンクのパターンをピックアップしてみました。どれも基礎的なお話でしかありませんが、こんなの全て完璧にできているよ、というサイトのほうが少ないのではないでしょうか。
こういったものは、必ずしも技術的に難易度が高いというものではなく、「知っていればそうしていたけど、特に気にしてなかったからそうしなかった」という理由で不適切な実装をされているケースが大半だと認識していますので、それは単純にもったいないですよね。MOTTAINAI。
とはいえ、規模が大きくなりサイトが複雑になればなるほど面倒なことが多いですし、どのページをインデックス対象にするか、どの部分を重要なページとみなしリンクを配分するかなどはサイトによって大きく変わってきますし、一概に「正解」を定義することはできません。
こういったところの微妙なニュアンスなどもセミナー等でコミュニケーションする中で知ってもらおうというような活動もやってます。こういうノウハウ系の記事もちょこちょこと更新していけるよう頑張っていきますので、引き続きよろしくお願いします。
ヴォラーレ株式会社 實川 節朗
「SEOノウハウ」って何だろうね、という話
“SEOノウハウ”という表現、よく使われますけど、これまたエラく曖昧な、そしてその言葉を単独で使えば、何とも胡散臭い言葉だと自覚しています。この業界では特に、でしょうか。「僕らSEOのノウハウたくさん持ってるよ」とかドヤ顔で言われても何言ってるのか正直よく分からないですよね。
（※って言って”SEOノウハウ“って調べたら僕が以前に取材頂いた記事が1位に、、すみませんでした）
話を戻して、何をもってSEOのノウハウというんだろう、ということについて。言葉を明確に定義する必要もないとは思うんですけど、「言葉にするなら多分こういうものかな」って言えば自分はしっくりくるなと思ってる内容をまとめてみようと思います。
「SEOノウハウ」がそれ単独で出来ることは少ない
ちょっと話は逸れますが、例えば、大学生3人で始めたばかりのスタートアップ企業が、いきなりリクルートさんの主力Webサービスと同じサービスをWebで展開しても同じことはできないですよね（例に出してしまってすみません）。資金力、人的資源、組織力、ノウハウ、運用歴、ブランド、何もかもが圧倒的に違うわけですね。
そしてそれはSEOにしても同じことが言えます。
表面的なサイトの形や機能は同じように構築すれば同じようにできることは多いと思いますが、じゃあ既にそのジャンルのトップ（キーワードの順位だけじゃなくて事実上のトップ）に長らく君臨するようなサイトはそういう要素だけで出来上がってるの？と言えば全然違うわけです。
世間一般にSEOが強いとされるサイトを見てその表面だけ真似ても、長期的に蓄積されてきたWeb上の資産は一朝一夕ではまねられません。そういうサイトのSEOの”強さ”の土台となっているのは「SEOのノウハウ」なんていうものではなく、サイトへの投資、ビジネスへの投資そのものだったりします。
だから単にSEOに詳しい人がいるだけでは、ビジネスを加速させることには限界があるわけですね。
SEOに長けている人がWebに関わると何が変わるのか
じゃあ、SEO強い人がいると何が良いのよ？というお話で。SEOに関する知見の多寡によって差が出るのは、次のような項目なんじゃないかと思っています。
- そのビジネスにおけるSEOの重要度の評価を適切にできるかどうか
- そのサイトでの理想的なSEOのイメージ（将来像）を持てているかどうか
- 現状の課題を正しく認識し、現実的かつ妥当な施策のプランニングができるかどうか
- サイト運用や企業活動の実績をどれだけ有効なSEO資産に転換できるか
- 蓄積されたSEO資産をどれだけ有効な検索トラフィックに転換できるか
- 検索トラフィックをどれだけ資産や収益に転換できるか
せっかく良質なサイトを運用していてもこのノウハウが欠如すれば100の投資をした結果のリターンが20しかないかもしれない(実際そういうサイトは多いですよ、勿体ない)。
でも、ある程度の知見があればこれを150にできるかもしれない。
本当にSEOに強い人がやればこれを300まで持っていけるかもしれない。
ちょっと雑ですけど、個人的には、SEOのノウハウというのはそういう類のものだと思っています。
ちなみに”SEO資産”というと何とも怪しい表現ですが、砕けて言えば「検索エンジンに認識・評価され検索結果により多くサイトが露出されるための材料となるもの」みたいな感じでしょうか。
コンテンツやリンクといった直接的な資産は分かりやすいですが、「継続的にサイトに訪れ、リンクや共有をしてくれる可能性の高いユーザー」みたいなものとかそういうのも本質的にはサイトの資産と考えるべきかなとも思います。
何にしてもサイトに色んなものを蓄積していくことは必要
基本的には先ほどこういうものになります。ただし、人工リンクみたいにサイト自体の改善をせずに評価を底上げするようなやり方を除き、100の投資自体はきちんとする必要があるんですよね。
つまりサイトに対する100の投資を300のリターンに出来るような”SEOに強い人”がいたとしても、投資が10のサイトであればそれを30にすることしかできないんですね、超単純計算では。
その場合、別のサイトでそれなりのスキルを持った人たちが100の投資で150のリターンを返してきているなら、そのサイトには勝てないわけです。
多分これがSEOノウハウというもののある意味での限界かなと思っています。
何もない状態で出来ることがほとんどなくて、何かする場合には基本的に何をするにもSEOが関わってくるのでそこにいちいちSEOを考慮した要件や仕組みを組み込んでいく、そんなイメージです。
しかし、言うは易し、するは難し
簡単に言っていますが、先ほど挙げたようなこと（資産を蓄積し大きなリターンに転換する）を本当に上手に実現しようと思うと、SEOと一言で言っても本当にいろんなことを知っていないといけないし、最低でも、相応に広い視野を持たないといけないのです。
また、必要な素養が幅広いので大変です、ということ以上に、明確なリターンが見えるわけではなく、かつ確かな正解のないものに、そうした動きを積極的にしていきましょうよ、としてそれを実行に移すまでのハードルが、企業によっては非常に高いと思うんですよね。
そういうところを少しでもカバーできればと思って（勿論、あわよくば案件のご相談など頂ければと思って）セミナーとか勉強会とかもやっているわけですね。今は需要の濃い話題とか、検索エンジン周りに寄せていますが、今後少しずつ領域広げてバリエーション増やしていきたいなとも思っています。
そんな感じで引き続きよろしくお願いいたします。
ヴォラーレ株式会社 土居
Webサイト高速化・表示速度改善のために知っておきたい基礎知識
Webサイトを高速化をする事によって得られるメリットは様々あると思いますが、ユーザーエクスペリエンスの改善といった話とは別に、個人的にはサーバの台数が減らせるというのも大きなメリットだと思っています。サーバサイド側のエンジニアとしてはやはりサーバの台数が減ればコストも下がるし、運用も楽になりますので、SEOに関わらず努力したいところではありますね。
しかしながら、「高速化しよう」「表示速度を改善しよう」といっても、実際にどういうところに高速化を阻害するような要因があるのか、ということを知っていなければそもそもどう取り組んで良いか分かるはずもありません。
ということで今回は、技術者の方でなくともサイト高速化のポイントがある程度理解できる（多分）ように、最低限「こんなことがあるのね」というポイントを大まかにまとめてみました。
高速化のための基礎知識
高速化という言葉の中には、大きく分けて２種類の概念が存在します。
- フロントエンド側での高速化
- サーバサイド（バックエンド）側での高速化
フロントエンドとは
ここで定義したいフロントエンドとは「HTML・CSS・JavaScriptなどの技術」と解釈してください。噛み砕いて言えば、「ページがブラウザに表示される」という部分に関する部分がフロントエンドということです。フロントエンドの領域では、ある程度HTMLが書ける方ならポイントさえつかめれば誰でも高速化する事が可能です。
サーバサイド（バックエンド）とは
サーバサイド（バックエンド）側、というのは文字通りサーバー側での最適化なのですが、状況によって見るべきポイントが異なりますし、ある程度は専門的な知識が求められるので、誰でも簡単に高速化、というのは難しいことも場合と思いますので、今回はいくつかの要素について掻い摘んでお話しようと思います。
フロントエンドの高速化
これに関しては様々な方法があると思いますが、シンプルに考えて以下の3つを注意した上で高速化を行っていけばいいと思います。
- サーバーへの通信の回数を減らす
- サーバーへの通信量を減らす
- レンダリングの速度を低下させない
1.サーバーとの通信の回数を減らす
まず、普段ウェブサイトを表示する時のブラウザの動作を考えてみましょう。ウェブページにアクセスする際には、ブラウザに「http://xxxx.○○.html」などといったURLを入力したり、リンクをクリックしたりすると思いますが、このサイトを開く場合にサーバへのアクセスは何回になるか？
と聞くと、意外に「１回しか通信しない」と思っている人も多いのではないでしょうか。
実は「http://xxxx.○○.html」を開いて中のHTMLを確認するまで、実際に何回サーバーとの通信が発生するかはわかりません。
なぜ開くまでわからないのか？といえば、それはHTML書かれている内容によって通信回数が異なるからです。通信回数はHTMLの中に記述されている、画像、外部CSSファイル、外部Javascriptファイルの数によって変わってきます。
単純に考えて画像の数だけ、CSSの数だけ、Javascriptの数だけ通信が発生していまします。
※304を返す場合は通信は発生しません。ステータスコードに関しては「よく見るHTTPステータスコード一覧とその意味を理解する」を参照してもらえればいいのかなと思います。
通信回数が多いということは、その分だけ表示が遅れることにつながりますので、なるべく少ない通信回数で表示が完了できるようにするという事がまず大切です。もちろん、決して「通信を１回に押さえろ」というわけではなく、あくまで無駄な通信をしないということです。
2. サーバーへの通信量を減らす
通信の回数、ではなく「通信量」を減らすということをイメージすると、例えば画像ファイルの容量を減らすことが思い浮かぶ方が多いと思いますが、そういうことです。画像や動画ファイルはファイルサイズがとても大きいので、通信量が増えます。
この点では、本当に基本的な事かもしれませんが、読み込むファイルのサイズを減らすということが重要になります。一番多くのサイトに関係があるのはやはり画像ファイルだと思います。
「これ以上は画質を荒くしたくない」という事情は多々あると思いますので、そんなときは、画質を落とさずにファイルサイズを減らす「画像の最適化」を行います。
通常の画像データにはウェブページとしては不必要なデータが含まれている事があります。それらを排除することで、ファイルサイズを軽くする事が出来ます。画像によっても変わってきますが、相当ファイルサイズが減るのでおすすめです。
最適化する際は専用のソフトウェアがあるので、そちらを使いましょう。
ちなみに、余力があれば、CSSとJavascriptのファイルサイズも少なくした方が良いと思います。もともと、画像に比べたらファイルサイズは小さいのですが、それでも軽量化をするべきだと私はを思います。
ある程度ウェブサイトを長年運用していると、CSSやJavascriptが徐々に追加され、気づいたら容量が増えていたなんてことがあります。また、簡単に軽量化できるので、導入しやすさもあります。
ただし、不必要なJavascriptやCSSは削除してしまえばいいんじゃないの？って思う方もいるかもしれませんが不必要だと思ってたら、必要だったCSSの記述だとか、使っていないと思っていたJavascriptの関数を削除してしまったり…と、もちろん不必要な記述は削除するべきですが、現実的にはなかなか難しいと思います。
そんなときは「ファイルの圧縮」を行います。不必要な空白や改行を削ってCSSファイルや、Javascriptファイルを軽量化する手法です。
もちろんエディタ等の置換機能を駆使して、消していく事もできますが、何千行なんてCSSやJavascriptファイルだった場合はとても大変なので自動で変換してくれる便利なツールがたくさんあるのでそちらを使いましょう。
- YUI Compressor
- Compressor
- Closure Compiler(javascriptのみ)
- ProCSSor - Advanced CSS Prettifier(CSSのみ)
3.レンダリング（≒HTML解析～ブラウザ表示）の速度を低下させない
ブラウザの表示速度を遅くしてしまう要因は通信だけではありません。HTMLの記述のしかた一つでブラウザの表示速度も下がってしまう場合もあります。
例えば一昔前はよくJavascriptをheadタグのなかに記述している事が多かったと思いますが、最近ではbodyの閉じタグの直前に記述するのが主流です。（ただし、Google アナリティクスの計測用コードなどはhead内に記述したほうがより正確な計測が出来るといった事情もあるように、必ず・全てということではありません。）
headタグ内への記述を推奨されない理由は、ブラウザの表示速度が低下してしまうからです。たとえばheadの中に外部Javascriptの読み込みがあると、その時点でJavascriptの読み込み、実行がされてしまいます。その間ブラウザは表示に関する処理は止まってしまうので、ユーザーに取ってはその分表示されるのが遅く感じてしまいます。
そこで、先にブラウザに表示できるものを表示させて、あとからJavascriptの処理をさせるという順序にすれば、体感的にユーザーに遅さを感じさせないようにすることができます。
もちろん1つ2つの処理であればそこまで影響が出ることは無いと思いますが、大量にJavascriptファイルがある場合などは大きな影響が出る可能性があります。
サーバサイド（バックエンド）側での高速化
さて、ここからは簡単にサーバサイド側の高速化の話を軽く触れていきたいと思います。どうしても技術よりの話題になりますので普段全く技術に関わらない方はナナメ読みで良いと思います。
サーバサイドは本当に様々な条件によって変わってきますので、状況によって高速化の手法はバラバラです。Ruby、Python、NodeJS、Perl、Java、PHPなどプログラミング言語によってももちろん違いますし、BtoCなウェブアプリケーション、BtoBなアプリケーションなど、ターゲットによっても変わります。また、サーバのスペックなどによっても変わってしまいます。非常に複雑で、ある程度以上の専門的な知識が必須になります。
とは言っても、高速化に関してサーバサイドで重要な事は、突き詰めていけばたった一つだけ。「ブラウザに返すレスポンスの速度を上げる」ということです。
特に速度が遅くなりやすい部分、アプリケーションによるデータベースの扱い方について私が意識的に注意している部分に関して簡単に掻い摘んで説明します。
使わなくてよい物はDBを使わない
Webアプリケーションではほとんどの場合、何かしらのデータベースが使われています。データベースは非常に強力なソフトウェア（ミドルウェア）ですが、アプリケーションから使い方を間違えると速度の低下につながります。
ついつい、データベースで何でも管理したくなってしまいがちですが、データベースに入れなくていいデータを入れるのはやめましょう。特にセッションデータをデータベースに入れているケースをたまに見かけますが、なるべく控えたほうがいいです。
このセッションデータと呼ばれる物は、ユーザーがアクセスする度にデータを取得して、更新して書き込むということが発生します。リクエストが発生する度に、データベースへの書き込み処理、読み込み処理が発生してしまうので、データベースに不要な負荷を与えてしまいます。
キャッシュを活用する
当たり前の事かもしれませんが、データベースは呼ばれれば呼ばれるほど、速度が低下します。小さい事かもしれませんが、比較的変更の少ない固定されているデータ「商品マスタ」「ユーザー情報」などはキャッシュしておくべきです。ユーザー数やアクセス数が多いサービスにはかなり有効な方法です。
※ただし、キャッシュを多様しすぎると、正しくないデータがブラウザに表示されてしまうなんて事もあるので使用する際は注意してください。
実行しているSQLの最適化
データベースを使う場合に、本当に最適なデータベースの使い方をしているのか見直しましょう。データを取得する際にSQLを使用しますが、その際に実行されているSQLが意図としたSQLになっているのか？見直してみると無駄がある事も多いので、ここは慎重に確認するべきです。
データベースのインデックスの見直し
データベースの高速化の技術の一つにインデックスという物が存在します。本で言うところの「索引」と同じような物ですが、このインデックスの設定の仕方で速度が何倍も変わってきます。
良いインデックスというのはデータベースの設計やアプリケーションによって変わってきますが、インデックスがしっかり使われているかを確認しましょう。
非同期処理でデータを保存する
データベースにデータを保存する際に、「保存しました」というレスポンスをデータベースから帰って来るのを待っていると速度が遅くなってしまいます。書き込む量が多くなれば多くなるほど速度は遅くなってしまいます。
大切なデータに関しては同期的に対応するべきですが、そこまで重要じゃないデータに関しては非同期で保存するという方法は有効です。
不必要なデータは保存しない
データベースはデータ量が多くなれば多くなるほど、速度が低下してしまいます。不必要なデータを保存するのは避けた方がいいです。
分割を意識した設計
データ量が多くなってしまうデータベースでは、データベースやテーブルが分割されても大丈夫なような設計をするべきです。
、、など、見るべきポイント、高速化を阻害する要因というのは様々あります。
まとめ
ウェブサイトの高速化というと例えば「CSSスプライトを使いましょう！」などのフロントエンド寄りの話が話題になりやすいですが、こういったサーバサイドでもしっかりと対応するために、どの程度のユーザーが使うのか、どの程度の規模のサービスなのか？といったあたりも意識しながらウェブサイトを設計・構築することが重要です。
サイトの高速化について大まかに掻い摘んで書きましたが、まだまだやらなければ行けない事はたくさんあります。今回紹介したポイントを意識して最適化することにより、確実に高速化できるのではないでしょうか。
ヴォラーレ株式会社 望月
おすすめの記事
2013.4.26 SEOセミナー開催レポート：「理解していれば回避できるはずの問題は予め回避しておくが吉」
さて、最近セミナー報告ばかりになりつつある当ブログですが、今回は4月26日（金）に開催しました制作や開発に関わる方向けのSEOセミナーのレポートです。前回と同じくtwitterで内容お伝えしていたのでそれもまとめてあります。
twitterまとめ：Webサイト設計に関わる無料SEOセミナー セルフまとめもいいとこ
今回はマーケティングとかリンクとかコンテンツとか検索エンジンアルゴリズムといった話題にはあまり触れず、Webサイトの設計・制作にあたりどういったことを予め考慮しておかなければならないのか、という内容で予定では120分のところ150分くらいに渡りお伝えしました。
諸注意として予めお伝えしたこと
本題の前に皆さんに事前にお伝えしたこととして、
- 検索エンジンが評価したいのはコンテンツ＆リンク
- 検索エンジンは「正しく作られたWebサイト」を評価したいのではない
- 正しく作られたWebサイト≠高く評価されるWebサイト
というのがまず原則としてあります。ですので、ここではあくまでSEOの観点から、という話にしますが、例えば実際にHTMLのマークアップを行う方がいくらそれらを美しく記述したところで、それ自体はSEOの完成ではなく、むしろSEOを行う土台を整える作業のうちのごく僅かな要素の一つ、というところでしかありません。
しかし、それでも尚、「（ある程度）検索エンジンを考慮してサイトを作る」ということはとても重要なものであるという認識でおり、サイト規模が大きくなる、とか長きに渡ってコンテンツを配信していく、というサイトであればあるほど、運用に入る前、設計の段階でどこまでSEOが考慮されたか、によって運用後の検索トラフィックには大きな差が出ます。
「クローラーの仕組みやランク付けアルゴリズムを研究して完璧なSEO設計をする」とかそういうことではなく、ある種の「普通に回避できるはずだった問題」を予め回避することが出来るのであれば、それは事前に対処して回避しておくのが吉じゃないですか（実際には、普通に回避できるはずだった問題点を回避できてなくて色々損してるケースがあまりに多く勿体ない）、ということが今回の本旨です。
セミナーコンテンツ
詳細はボリュームが多いので（スライド150枚以上）概要をラインナップとして並べます。
※実際のプレゼンで使用したスライド一覧
1.検索エンジンの基礎知識
今回はかなりサラッと流しましたが、これはどの回でも必ず行います。最低限、裏でどんなものがどのように、何のために動いているのかは理解しておかないとその先の話が通じなくなってしまいます。
- 検索エンジンの仕組み
- 検索エンジンの収益モデル
- 検索結果が返されるプロセス
2.企業がSEOに取り組む意義と得られるもの
今回はメインの話題がサイトの作り方の部分だったりもするのでここも流してしまいましたが、目的と手段を混同しないように、ということと、最終的にどのようにSEOを通じて検索トラフィックが獲得されるのか、ということに簡単に解説しました。
- 企業がSEOを行うメリット
- SEOのWebプロモーション上の特性
- SEOの運用と目標達成までのプロセス
3.SEOの取り組み内容とその分類
例えば内部対策と外部対策とか、コンテンツとリンクとか、ユーザビリティとクローラビリティとか、まあ色んな確度からそれぞれの要素が様々分類されて対比されます。まずはどういう要素がSEOには存在していて、それぞれがどういう分類をされるのか、みたいなことをかなりザックリまとめてお話しました。
- 機械（検索エンジン）を考慮したサイト設計
- キーワード/コンテンツ/リンク
- 制作・開発担当者が直接SEOに貢献できる事
- 内部と外部 / 機械と人間
4.制作者が行えるSEO
メインはこの部分です。事例を交えて、サイトのデザインや機能の実装にあたり最低限、少なくとも知っておかれたい、或いは気にされたい部分を約100枚くらいのスライドで駆け足で解説しました。
限られた時間の中で、なのでこういうお話を新情報として聞かれる方もいらっしゃったと思いますが、もちろんボリューム的には一つ一つについて網羅できるはずもないので、まずは「なるほど、こういうことも気にしておかないといけないのね」ということだけでも理解して頂ければ良いかなとは思っています。
- 検索キーワードと流入口ページの確保
- テキスト情報の独自性の担保
- 重複コンテンツ問題
- クロール・インデックス
- ページレイアウト
- サイトの速度
まとめ
今回お話した内容は、一つ一つの項目としては取り立てて珍しい話ではないというかごく基本的なことの確認、おさらいのような感じでしたが、しかし基本的であることと皆さんがそれを満遍なく理解しているということはイコールではありません。
実際に、少なくとも全体から見れば一部を除いた多くのWebサイトは、SEOに適しているとはとてもではないが言い難い、というような作り方をされていると思います。
少なくとも、HTML構文チェックで100点を目指すこと自体のSEO的な価値というのはほぼ皆無だと思っておりますが、そういう類の「最適化」を求めるのではなく、最低限、作成するコンテンツの内容や得られたリンクが漏れ無く無駄なく評価される、ということがSEOの前提ですので、こうした認識は、Webの制作や運用に関わる皆さんにやはり最低限以上は知っておいて頂きたいなと感じる所存です。
次回開催のお知らせ
アンケートやTwitter上での反響は割と良かった方だったので、僕個人の省エネも兼ねて5月にもう一度同じ内容のセミナーをすることになりました。
詳細：Web制作・開発に関わる方向けのSEO設計基礎セミナー(第二回)
Web制作会社の方や社内のWeb担当者の方をメインターゲットとしていますが、マーケティング担当者の方とかまあ色々要は基本的にはご興味がありましたらご参加頂ければと思います。
当日は事前に簡単なレジュメ（?）をお配りして、プレゼン資料とかは終了後にお持ち帰り頂けるようにしていますが、今回は資料印刷ミスりました。細かな誤字チェックとかは複数人でやったのにも関わらず表題だけが作成当初のまんまになってました。
※内容は本番でした。
ということで5月のセミナーも告知前からちらほらと参加お申込み頂いている企業様もいらっしゃり大変有難い状況ではありますが、今後のセミナーも機会とご興味とお時間ありましたら是非ご参加下さい。
ヴォラーレ株式会社 土居
おすすめの記事
よく見るHTTPステータスコード一覧とその意味を理解する
404や503、301・302など「ステータスコード」とか言われるものをよく見るけど実はその意味はよく分かっていません、という方は意外に多いんじゃないかなと思ったので、よく見るものを一覧でまとめて解説してみました。このあたりの話題にそこまで詳しくない方でなくとも理解できるように解説しているつもりです。
Webブラウザやクローラーが情報を受け取る仕組み
私たちは普段、FireFoxやChrome、SafariなどのWebブラウザを通じてURLにアクセスしてWebコンテンツを閲覧しています。この「URLにアクセスする」ときに、Webブラウザは「リクエスト」を送り、Webサーバーが「レスポンス」を返す、というやり取り（通信）が行われています。
リクエストを送る側は、「サーバー（提供者）」に対して「クライアント（依頼者）」と呼ばれます。Googleのような検索エンジンのクローラーもブラウザと同じくクライアントという扱いになります。
HTTPステータスコードとは？
WebブラウザやクローラーがURLにアクセスしようとするとWebサーバーからどのようなレスポンスを受け取っているのか？というのは例えばGoogleのウェブマスターツールの基本機能「Fetch as Google」などを使って知ることができます。
※図の中の赤枠以下の情報を受け取っています。
少し見づらいですが、通常通りアクセスできてコンテンツの情報が得られる場合にはブラウザやクローラーはこのようなデータをWebサーバーから受け取っています。
ここで少しだけ專門用語を使うと、上の図にあるようなレスポンスは「ステータスライン」「レスポンスヘッダ」「メッセージボディ」の３つから成っています。
レスポンスヘッダとメッセージボディについては今回本題から外れますが、折角ですので合わせて簡単に解説します。
ステータスライン
ステータスラインは一番上に記述されている「HTTP/1.1 200 OK」や「HTTP/1.1 301 Moved Permanently」等のようなもので、「レスポンスの状態」を表します。この中の「200」や「301」といった３桁の数字が今回の話題となる「ステータスコード」です。「OK」「Moved Permanently」は「説明句」というもので、その名の通りステータスコードの内容説明をするものです。
クライアント（WebブラウザやGoogleBot）はWebサーバからどのステータスコードが返ってきたかによって、その中身を見なくとも次にどんな処理を行えばよいかを判断することができます。
レスポンスヘッダ
レスポンスに付与するメタ情報が記載されている部分です。ここでいうメタ情報とは、「（受け取った）データに関する補足情報」のようなものと思って下さい。例えば、URLが転送（リダイレクト）されている場合に転送先のURLの情報を「Location」として付与する、などの情報です。
メッセージボディ
いわゆる”本文”にあたるもので、Webページに問題なくアクセスできた場合にはHTML情報がここに記載されます。私達が普段見ているWebページはこのHTMLテキストをブラウザが解釈して表示したものです。
さて、本題のHTTPステータスコードについて話を戻します。
HTTPステータスコード
ステータスコードは本来ブラウザやクローラーが処理するために付与されているものなので、普段私達がブラウザ上でWebページを見ている際に見ることはありませんが、時々エラーでこんなのをお目にかかることはありますね。
また、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ページを正常に閲覧している際、大抵このステータスとともに返ってきたレスポンスの内容を見ています。
301 Moved Permanently
リクエストで要求された情報の中身が別の場所に移動したことを示します。
この移動は一時的なものではなく、恒久的なものです。サイトの引越しを行ったりしてアクセスするURLが変更され、ずっとそのURLを使用していく場合にこのステータスコードを返すようにしておく必要があります。
googleからの評価を新しいURLに引き継がせるためにも301を設定しておきましょう。また、あるページへのアクセス経路を一本にまとめる、いわゆるサイトの正規化を行う場合にもこの301リダイレクトを使用します。
302 Found (※Moved Temporarily)
こちらもリクエストで要求された情報の中身が別の場所に移動したことを示します。301と異なるのは、その移動が一時的なものであるという点です。
たとえばメンテナンス等で一時的にサイトを別の場所に移さなければならないが、また元の場所に戻す場合はこの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ページを表示しています。
403 Forbidden
サーバ側で外から見えないように設定してある領域へのアクセスをリクエストしたときに返ってくるステータスコードです。簡単に言えば立ち入り禁止です。
見せたいページでこのエラーが出ているときはアクセス制御の設定が間違っている可能性がありますので設定ができる方は確認してみましょう。
404 Not Found
リクエストしたページが見つからない場合に返されるステータスコードです。
ウェブマスターツールではGoogleBotが検出した404エラーをレポートしてくれていますが、特に404エラーが多いからといってgoogleからのサイトの評価が下がることはないと言われています。サイト内からリンクされているページが404エラーになっている（＝リンク切れ）のは問題ですが、そうでない限りは放置しても良いかと思います。
他サイトから多くのリンクを受けているようなページを404エラーとしてしまうと、折角サイトが得られた被リンクの恩恵を逃してしまうことになります。何かしら代替のコンテンツを用意してそのページを残しておくか、近い内容を持つページに301リダイレクトするなどでリンク資産をサイト内に残せる処理をするのが一般的です。
410 Gone
404と同じくリクエストしたページが見つからない場合に返されるステータスコードです。404と違う点は、そのリクエスト先のページが「消滅した」という意味合いがあることです。
こちらの記事によると最近はGoogleBotは404と410を微妙に区別しているとのことですが、記事でも書いてあるようにそこまで神経質になる必要はほとんどないと思います。
補足：ソフト404エラー
ブラウザ上ではそのページが存在しない旨のメッセージが表示されているにも関わらず、ステータスコードとしては404や410を返していない（つまり正常なレスポンスとして「200 OK」が返されている）パターンが存在します。これを「ソフト404エラー」などと呼びます。
どういうときに発生するかというと、例えばサイト運営側で独自にエラーメッセージ表示用のコンテンツを作成して、想定していないURLに対してリダイレクトをかけてそのコンテンツに飛ばすというケースが考えられるでしょうか。
Webページを見ているユーザに対してページがないことが伝わっても、機械的にHTTPステータスコードを読み取るbotに対しては伝わりません。このようなソフト404ページが存在するとGoogleBotがクロールのリソースを無駄に消費することになりますので、存在しないページにアクセスしたときはステータスコードとして404もしくは410が返されるように正しく設定するべきです。
500 Internal Server Error
サーバ側の何らかのミスによってリクエストに応えられない場合です。例えばシステム開発中にバグを混入させてしまうとこのエラーを起こすことがあります。
503 Service Unavailable
Webサーバの過負荷状態で一時的にWebページが表示できないときなどに発生します。例えばTwitterがクジラを表示させている状態、とでも言えばイメージが沸きやすいでしょうか。
メンテナンスでサービスをストップさせている際に意図的に503を返すように設定することもありますが、基本的にはサーバー負荷の問題ですので頻発するようであれば、サーバーの変更を検討するか、サイト側での負荷軽減などの手を打つ必要があります。
まとめ
ここまでHTTPステータスコードについてのお話をさせていただきましたがいかがでしたでしょうか。表には出てこない部分ではありますが、こうした部分まで意識してみることができれば、今よりもクローラにとって優しいサイトが作れるかもしれません。
特に一般の方（技術に関わりのない方）にとってはこうした話というのはあまり重要視されにくい話題と思いますが、SEOの観点では、サイトが検索エンジンに正常にクロールされ、正しく検索インデックスに登録してもらえるための基本的な作法として、サイトを制作・管理する方には皆さまに理解していただけると嬉しいです。
文責：ヴォラーレ株式会社 西村