プロのためのSEO講座～Google編～
SEOなんていうのは、むしろ常識になってしまっていますが、素人でも知っているキーワードをプロがどれだけ実践できているか？それが結局は問題なのだと思います。
素人レベルで実践できる話などは、所詮常識レベル。それより一歩進んだ解釈と提案ができて初めてプロだというわけです。
プロのためのSEO講座ということですので、言葉に関する説明などは一切抜きにして、進めていきますので、素人にはお勧めしません。（言葉がわからない人はググってください）
世に出ているホームページの専門書などには、アクセス解析が大切だといわれていますが、それはお客さんがやっておくべき事でプロがやるべきことではありません。
では、プロは何をすべきか？
それは、素人にはできないことをやってあげるのです。そこにこそ対価を払う価値があります。
今回はGoogle編という事で、GoogleのSEOだけにポイントを絞って技術的なことを中心に解説していきます。
まずはじめに何をするかというと、原点に返るところから始めましょう。
…という事で、Googleのガイドラインから主要な部分を抜粋します。
デザインおよびコンテンツに関するガイドライン
- わかりやすい階層とテキスト リンクを持つサイト構造にする。 各ページには、少なくとも 1 つの静的なテキスト リンクからアクセスできるようにします。
- サイトの主要なページへのリンクを記載したサイトマップを用意する。 サイトマップ内にリンクが 100 以上ある場合は、サイトマップを複数のページに分けます。
- 情報量が豊富で便利なサイトを作成し、コンテンツをわかりやすく正確に記述する。
- ユーザーがサイトを探すときに入力する可能性の高いキーワードをサイトに含める。
- 重要な名前、コンテンツ、またはリンクを表示するときは、画像の代わりにテキストを使用する。 Google のクローラでは、画像に含まれたテキストは認識されません。
- TITLE タグと ALT 属性の説明をわかりやすく正確なものにする。
- 無効なリンクがないかどうか確認し、HTML を修正する。
- 動的なページ (URL に “?” が含まれているページなど) を使用する場合、検索エンジンのスパイダーによっては、静的なページと同じようにはクロールされない場合があることを考慮する。パラメータを短くしたり、数を少なくすると、クローラで見つけやすくなります。
- ページのリンクの数を適切な数に抑える (100 未満)。
技術関連のガイドライン
- Lynx などのテキストブラウザを使用してサイトを確認する。ほとんどの検索エンジン スパイダーがサイトを認識する場合、Lynx と同様の形式で認識しています。テキスト ブラウザで、JavaScript、cookie、セッション ID、フレーム、DHTML、Flash などの特殊な機能を使用して作成されたサイトの一部が表示されない場合は、検索エンジンスパイダーがサイトをクロールするときに問題が発生する可能性があります。
- セッション ID やサイト内のパスを追跡する引数がなくても、検索ロボットがサイトをクロールできるようにする。これらの技術は個々のユーザーの行動を追跡する場合には便利ですが、ロボットがアクセスするパターンとはまったく異なります。これらの技術を使用すると、実際は同じページにリンクしている、異なる URL をロボットが排除できず、そのサイトのインデックスが不完全なものになる可能性があります。
- ウェブ サーバーが If-Modified-Since HTTP ヘッダーに対応していることを確認する。この機能を使用すると、Google が前回サイトをクロールした後にコンテンツが変更されたかどうかをサーバーから Google に通知し、帯域幅や負荷を軽減できます。
- ウェブ サーバーの robots.txt ファイルを活用する。このファイルでは、クロールを実行するディレクトリと実行しないディレクトリを指定できます。 誤って Googlebot クローラがブロックされることのないよう、このファイルにサイトの最新の状態が反映されていることを確認してください。サイトへのロボットのアクセスを制御する方法については、次の URL (英語) をご覧ください。 http://www.robotstxt.org Google ウェブマスター ツールの robots.txt 分析ツール を使用して、robots.txt ファイルを正しく使用しているかテストできます。
- コンテンツ管理システムを導入する場合は、検索エンジン スパイダーがサイトをクロールできるように、システムからコンテンツをエクスポートできることを確認する。
- robots.txt を使用して、検索結果ページや、検索エンジンからアクセスしたユーザーにとってあまり価値のない他の自動生成ページをクロールしないよう制御します。
情報の品質が高いことが大前提だということを忘れないでください。無意味な情報を掲載するのは言語道断です。その上で、ポイントだけを解説していきます。
デザインおよびコンテンツに対するガイドラインについては、SEOの対策本や対策サイトなどで語られているので、あえてここでは語りません。それよりも重要なのは、技術関連ガイドラインです。
一つ目のポイントは、Lynxを使った時にちゃんと表示されるかどうかです。しかし、このあたりもある程度の専門書には掲載されています。また、W3Cの勧告やユーザビリティーに関するJIS規格に準拠した場合、問題にはなりません。
問題になってくるのは2つ目と3つ目です。ちなみに、この2つはネットワーク技術をある程度理解していないと言葉の意味すら分からないと思います。（そんなときはググってください）
特に2番目については動的なページ検索に関する重要な記述です。コンテンツ量と検索確率との間には比例関係があるわけですが、効率よくコンテンツを生成するためと、膨大なコンテンツの管理をするためにはCMSの導入が不可欠です。しかし、独自で開発する場合、ただ単にコンテンツが管理・生成できるという部分にだけ着目すべきではないのです。
ちなみに、セッションIDというのは、
https://coreda.jp/category/42/
というように、”?”以降の部分を指します。よくアフィリエイトなどで使われる手法ですが、セッション維持変数のURL埋め込み方式と呼ばれ、Cookieが利用できないブラウザや携帯ブラウザなどに対応するためにあらかじめ変数をURLに埋め込んでおく手法です。APIサービスにはこの方式は不可欠です。
また、ページ上のアンカーリンクタグ内のURLには全てこのセッションIDが自動追加されます。ということは、アンカータグによるサイト内移動できるように作ってしまえば、それらすべては別ページとして認識されるのではないでしょうか。・・・と思ったら大間違い、そもそもGooglebotはそんなものをいちいち相手にしていません。
すると、この手の動的ページはGoogleにインデックスされにくいのです。
「一見異なっているようで実際は同じページにリンクしているURLをロボットが排除できず、そのサイトのインデックスが不完全なものになる可能性があります。」
ユーザの動向を見るということで利用しているサイトもあるようですが、GoogleのSEOにとってはNGです。
また、3つ目についてはサーバの設定についての技術的問題です。実際に対応できているのかまず調べてみることです。その上で、サーバの設定を変更するか、それができない場合別の対策を考えるかという選択肢が生まれますが、実は、Googleのウェブマスターツールを利用するとこれもさほど問題ではありません。たとえば、サーバ側でIf-Modified-Since HTTP ヘッダーに対応していないとしても、クローラーを呼び込むことさえできれば、いいわけです。
4つ目については、実は2つ目の問題とかぶる部分があります。CMSを利用する場合でもセッションIDを利用せずに、静的HTMLを吐き出すことができるか、もしくは、それに準ずる別の形で対応できるかということです。
それに準ずる別の方法で、最もポピュラーなのが、mod_rewriteというモジュールがあります。WebサーバがApacheを使用しているのであれば、このモジュールによって動的ページを静的ページにリアルタイムで変換できます。
Googleで提供しているブログサービスのブロッガ―は、静的HTMLをFTP経由で指定のサーバに保存できるという部分で、ほかの無料ASPサービスよりSEO対策に優れたサイト構築と管理が可能になります。
確かに、静的ページを生成できるCMSを利用するというのが最適ですが、動的・静的の切り替えをできるMODxやファイルの拡張子を変更できるMTなども企業サイト構築には便利です。
最後に、動的ページだとしてもGoolgeに1,990,000 件（本日現在）インデックスされているサイトがあります。
それは、皆さんもよくご存じのAmazon.co.jpです。
ただし、よく検索結果を観察してください。
検索結果1ページ目に出てくるもので、Amazon.co.jpのサイト関連は4つしかありません。（本日現在）
次の検索結果ページもそのような感じで続きます。ということは、自分のサイト以外の人たちが静的ページを多数作ってくれているということになるのです。これは、アマゾン・アソシエイトと呼ばれるアフィリエイトプログラムの影響が大きいでしょう。いち早くアフィリエイトサービスを行ったアマゾンは、動的ページにもかかわらず、Googleでのインデックス数は膨大です。
先にSEOを考えてシステムの設計を行えばよいのですが、すでに膨大なデータ量を保有してしまったサイトでの再構築は、現実問題として不可能でしょう。しかし、そうした問題を別の切り口から解決する方法は、実はいくらでもあるのです。
