つまり検索エンジンも?や=を嫌う − 動的ページと静的ページ(3)

（前回からの続き。2回目も同じ感じだっただったけど）
いやしかし、動的ページ使いまくりのアマゾンなのに日本のアマゾンだけで見ても140万ほどインデクスされていることはどう説明するんだ？しかもアマゾンだってアクセスしてよく見るとURLの最後にセッションIDっぽい数字が自動追加されてるのに？？

Googleに140万ページがインデックスされている www.amazon.co.jp と 1700件の www.shopping.hp.com の違いはなんだろうか？それは両者を何ページがサーフィンしてみるだけですぐにわかる。 amazon.co.jpのURLには記号はほとんど/(スラッシュ)だけで、たまに=(イコール)がある程度。 www.shopping.hp.comのURLは?(クエスチョン)や=や&が盛りだくさん。

そう。Googlebotは?や=や&があるURLを動的ページとみなしてクロールにブレーキをかける。 実は動的ページと静的ページの見分け方についてはGooglebotはそんなに頭が良いわけではない。 GooglebotはURLに?や=や&が多用されているとか、さらにその文字列に「session」といった単語があるとか、そういったことだけでそれが動的ページであるかどうか判断している。これはGooglebotだけじゃない。Yahoo!Slurpなどにおいても似たようなものだろう。

?や=や&はCGI(Common Gateway Interface)仕様のひとつであるQUERY STRINGと呼ばれる指定方法だ。プログラムはこの記号に沿って指定された文字列をもとに、動的ページを生成して出力する。文字列というのは例えばECサイトであれば商品番号だったりする。

ただし、このCGI仕様はあくまでもひとつの方法に過ぎない。本来はファイルシステム上のディレクトリ(フォルダ)構造を示すために使われる/(スラッシュ)という記号だが、 ?や=や&といったCGI標準仕様の変わりに使ってはいけないわけではない。 1回目の記事で、YahooJapanのトップページが「index.html」なのにもかかわらず動的ページであり、拡張子などは参考に過ぎないと書いた。 Googlebotだってその点ではそれほど優秀なわけではない。「?や=や&を含むURLは動的ページである可能性が高いから注意せよ」というプログラミングに基づいているだけだ。

かくして、URLに?や=や&が盛りだくさんのwww.shopping.hp.comのページはちっとも検索エンジン内に蓄積されてゆかない。

実はプログラムに引数を渡す手段は?や=や&だけではない。技術的な手段は何通りでもある。そこでアマゾンでは、一般に使用される?や=や& の代わりに極力 /(スラッシュ) のみを使って動的ページのURLを表現することで URLだけで見ると「ちょっとディレクトリ構造が深くて独特だね」くらいにしか見えないようにしている。もちろんこのスラッシュはWebサーバ内のディレクトリ構造を示しているわけではまったくないだろう。ただしこれは筆者の推測なのだが、アマゾンのこうした工夫は検索エンジン対策というよりは以前の記事でも書いた対人間用の心理学的な配慮であり、検索エンジン対策としても機能しているのは結果オーライなのかもしれないと考えている。

実はアマゾンはもうひと工夫している。例えば
http://www.amazon.co.jp/exec/obidos/ASIN/4093860726/
に普通のブラウザでアクセスしようとすると
http://www.amazon.co.jp/exec/obidos/ASIN/4093860726/xxx-xxxxx-xxxxx
というふうにURLの最後に個別のセッションIDが付加されたURLにリダイレクト (HTTPステータスコード302)されるが、 User-AgentヘッダがGooglebotの場合にはリダイレクト処理はされずにそのままコンテンツを返すようになっている。また、そのコンテンツの中身自体も、普通のブラウザアクセスに対しては「123-45678-000999」のようなアマゾン独特のセッションIDがコンテンツ内全てのアンカーリンク内のURLに自動追加されるが、 Googlebotが相手の場合にはそれがなされないようになっている。こうしたシステム的な工夫により、前回説明した、

一見異なっているようで実際は同じページにリンクしているURLをロボットが排除できず...

という現象を避けるようになっている。

いずれにせよ、セッション維持にURL埋め込み方式を取っているWebサイトなど少ない。動的ページだらけのWebサイトであっても、URLに?や=を使わない方式にするだけで Googlebotはいくらでもクロールしてくれるようになることはアマゾンによって証明されているのだ。

しかし、言うは簡単というのが世の中のつらいところである。一般に販売される「ECサイト構築ソフト」のようなものや、システム開発会社が手でまともに設計するシステム、あるいはシステム開発会社などで使われるWebサイト（というよりWebアプリケーション）を作るための各種のAPサーバ製品やフレームワークなどは、ほとんどがCGIの標準仕様のみにもとづいており、URLには当然ながら?や=や&が多用され、それにあわせ request.getParameter(hogehoge) とか $_GET[hogehoge] といった記述がプログラム内のいたるところで使用されている。それらを使ったところで 「高い金出して作ったWebサイトなのにGoogleやYahooではトップページくらいしかひっかからない！」 という事態が待っているのだ。

アマゾンのようにできるだけ/(スラッシュ)だけの形式で引数を渡すには設計自体、ソフト自体、フレームワークそれ自体の大幅な改造が必要であり、現実的ではない。仮にそのように改造したとしても、もしも近い将来、検索エンジンのクローラーの方が進化してしまって?や=があるURLに対するクローリングにも問題がなくなってしまったら、苦労と金は水の泡と消えるだろう。

データの管理画面はCGIやらの動的ページで行って、実際にお客が見るページは静的なページを自動生成するようにすればいいんですよ、と甘い言葉をささやく業者もいる。それは間違ってはいないが「足して５になる数字は２と３ですよ」と言っているに過ぎない。 要は動的ページであってもURLだけは静的ページであるかのように見えるように作れば、 Googlebotはクロールしてくれる。 しかし残念ながら上で述べたようにそこまで考えている製品やプログラミングフレームワークは少ないし、そこまで考えが至るエンジニア自体もまた少ない。

Apacheのmod_rewriteや、それに類するフィルタリング装置を使うとか、 QUERY_STRINGのかわりにPATH_INFO環境変数を使えばなんとかなるかもしれないが、それなりのノウハウが必要だしアプリも無改造というわけはまずいかないだろう。楽天市場の店舗の商品URLや2ch.netのURLのシンプルさには実は理由があるということに改めて気づき横目に見つつ、 ?や=や&を使いまくりの長い長いURLを持て余しているECサイトの運営者のみなさんの苦悩は続く。