2015年、確実に成果を出すためのSEOの方程式
土居です。この記事では僕がSEOに携わるときにほぼ例外なく考えているイメージを可視化してお伝えします（脳内整理も兼ねて）。初心者の方は全体観を把握するために、実務者の方は思考の整理に、それぞれ一助になれば幸いです。
タグ: ステータスコード
スマートフォン版サイトがないのにスマホとPCで検索順位が全然違う、という事例を調べてみた
6月に、「スマートフォンユーザーにとって著しくユーザーエクスペリエンスを損ねるような実装をしている場合、スマートフォン検索においてのみランキングを下げることがある」というような話題がありました。
※参考：Google ウェブマスター向け公式ブログ: スマートフォン向け検索でのランキングの変更について
先日、うちのメンバーに頼まれてあるクライアント様のサイトを調査してみたところ、それに近い話題で、ただちょっと特殊っぽい事例にあたりましたので紹介しておきます。
結論：スマホでは普通に見れるけどGooglebot-Mobileには不適切な転送設定されていた
ざっくり言いますと、「通常のスマホブラウザでは問題なくレスポンスが返されてサイトが閲覧できるのに、スマートフォンのUAを持ったGooglebot-Mobileに不適切なリダイレクト、具体的には『全てTOPページへ転送』のような設定がされていた」という状態でした。
と言われても何のこっちゃピンと来ないという方も多いと思いますので簡単に解説していきます。
解説
まず状況としては、
- 少し前からスマホ検索でのみ検索結果に表示されなくなった
- でもスマホサイトもないし、スマホでの閲覧も問題なく出来る
- 変なリダイレクトがかかってたりする様子もない
- PCサイトでは問題なく検索トラフィック伸びてるのにスマホだけ激減してる
という感じで、最初は検索結果のバグかテストか何かかな？とも思ったのですが、それなりの期間そういう状態だったのでそういうわけでもなく、何かしら致命的な問題があるはずと思って改めて調べてみたわけですがしばらくの間は良く分からんという感じでした。
ようやく思い立ってFetch as Googleで投げてみた
ちなみにFetch as Googleって何、という人のために言うと、「Googlebotがどういう風に情報を取得しているのかを確認できる、ウェブマスターツールの機能」です。こんな感じです。
こんな風にURLとクローラーを指定すると、
こんな風にクローラーが受け取る情報を表示してくれます。（↑はテストなので気にしないで下さい）
さて話を戻しますが、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のクローラーなのですからそちらでチェックしないといけないですね。
あまり汎用的ではない話題だと思いますが、ここ最近だけでも数回、スマートフォン検索での検索結果が下がった、などの相談を頂きましたが、どれも不適切なリダイレクトなどの初歩的な設計ミスが何かしら発生しているという状態でした。
そもそも冒頭にあるような話題をキャッチアップしていなかった人は必ず知っておくべき事項ですし、こういう細かな設定ミスでもトラフィックに重大な影響を与える可能性もあるということで、きちんと予備知識として再確認をしておけると良いですね。
ヴォラーレ株式会社 土居
おすすめの記事
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の観点では、サイトが検索エンジンに正常にクロールされ、正しく検索インデックスに登録してもらえるための基本的な作法として、サイトを制作・管理する方には皆さまに理解していただけると嬉しいです。
文責：ヴォラーレ株式会社 西村