クローラーの最近のブログ記事

モバイルSEOをする上で様々な制限をかけている場合、
その制限の所為で検索エンジンのクローラーが正常にサイトをクロールできない現象が起こります。
その中で必ず確認しなければならないものが以下の3つ。

1. クローラのIPを制限していないか

もしIPで携帯以外のアクセスを制限していた場合、クローラーも同時に弾かれることになります。 携帯は各キャリアがIP帯域を公開していて携帯のIPのみを許可することが容易なため、結構落とし穴です。 この場合は検索エンジンのクローラーIPを開放することでクロールしてくれるようになります。 クローラーIPは公式で公開されていないので、追いかけるのが超めんどいです...。

2. クローラーのUserAgentを制限していないか

UserAgentでアクセスを制限している場合、クローラーのUserAgentも開放してあげないとクロールする前に弾かれてしまいます。 UserAgentはIPよりは把握が楽です。（Yahoo!モバイルは公式で公開してるし）

3. クローラーが使用している機種情報が制限されていないか

機種別に見せるページを変えている、アクセス制限をしている場合、これもクローラーが弾かれる原因になります。 なぜなら各モバイル検索エンジンクローラーは機種情報を付与しつつクロールに来るからです。 つまり、携帯に成りすましてクロールに来ていると言うこと。 なのでクローラーが成りすましている機種にアクセス制限がかかっていると、内部が見られないためインデックスされても「対応していない機種なのでアクセスできません...うんたら」のページしかインデックスされない状況に。 この偽装している機種も公式で公開していないので全ての把握が難しい＆めんどいです。

Yahoo!

• Y!J-SRD

IP
124.83.159.
203.216.197.xxx
機種情報
J-PHONE/4.3/V603T
J-PHONE/2.0/J-SH03
J-PHONE/3.0/V403SH
DoCoMo/2.0/SO502i
DoCoMo/1.0/SO506iC
KDDI-CA23 UP.Browser/6.2.0.5

• Y!J-MBS


• Y!J/1.0

IP
211.14.8.2xx

• lwp-trivial/1.41（cr0x.wap.search.mud.yahoo.comでやってくる）

IP
209.191.126.xxx

• Yahoo　Seeker

IP
66.94.229.146
66.94.233.75
66.196.93.xxx
68.142.195.xxx
216.109.126.143
機種情報
KDDI-TS24
J-PHONE/2.0/J-SH03
DoCoMo/1.0/SO502i

• Googlebot-mobile

IP
66.249.64.0/20
222.238.81.xxx
207.44.196.xxx
125.177.35.xxx
216.239.39.xxx
機種情報
KDDI-CA33
DoCoMo/1.0/N505i/c20/TB/W20H10
Nokia7110/1.0
Nokia6820/2.0

つまるところ、「Googlebot」とついているクローラー全てがブロックされると言うことです。

http://www.google.co.jp/support/webmasters/bin/answer.py?answer=40364

まさかとは思ってたけど、公式にあるなんて知らなかった...とんだ盲点ozn
対処法として

Googlebot をブロックして、Googlebot-Mobile など他の Google ロボットを許可する場合、Allow ルールを使用して特定のロボットにアクセスを許可することができます。 たとえば、次のように指定します。
User-Agent: Googlebot
Disallow: /
User-Agent: Googlebot-Mobile:
Allow:

ってのがあるんですが、ちょい怪しいんじゃないかな...。
携帯サイトめんどくさー！

今日も今日とてサイトのログを見ていたら（少々変な日課ですが）、
Googlebotがこんな挙動をしていました。

2007/07/18,10:10:32
66.249.85.131
/google***********.html（GoogleSitemapの確認ファイル）
200（ステータスコード）
Google-Sitemaps/1.0

2007/07/18,10:10:32
66.249.85.131
/noexist_**************.html（noexist_確認ファイルと同じファイル名）
404
Google-Sitemaps/1.0

上記はSEOの効果測定に有効と言われているGoogleウェブマスターツールのクローラーです。
Webマスターツールでは、エラー情報やリンク情報などを知るためにはGoogleが指定する確認ファイルのアップロードを行う必要があります。
そんな訳でこのサイトにもWebマスターツールの確認ファイルを入れてあるんですが、
noexist_うんたらとかいうファイルはWebウェブマスターツールにアップロードを指定されていないので当然アップしていません。
しかし実際クロールに来るGooglebotは必ず確認ファイルと一緒にnoexist_うんたらを拾いに来ます。
404を吐いているのにも関わらず毎回必ずセットでやってきます。
かなり前からこんな感じなので気にはなっていたんですが...。
ということで、ちょっと調べてみたところGoogleGroupsに回答がありました。

英語苦手なので曖昧ですが、どうやら「存在しないファイルに確実に404エラーを出すところかどうか」を見ているらしいとのこと。
存在しないファイルに対してGooglebotに存在していると思わせ・騙す行為を防ぐためのもの？とかどうとか...。
つまり、「ページが存在しない場合301リダイレクト等を使用してステータスコード200を返すページに自動的に移動する」行為がGooglebotのチェックにひっかかる様なサイトという事なのかなあ？

そう思うと、現在はやり（？）の「エラーページを独自で作る」のステータスコードはどうなっているんだろう？と疑問に思いました。
エラーページ自体は存在しているから200？だったらだめじゃん独自エラーページ！
というわけで更に調べたところ、.htaccessに以下の記述をすればいいらしい。

ErrorDocument 404 /404.html

...というか、普通に独自エラーページ作る時の記述なんですが...。
単に404エラーメッセージを404.htmlに置き換えているだけだからステータスコードに影響はないっぽい。
.htaccessにだけ書く場合はこれでも大丈夫みたいです。安心安心。

現在モバイルSEOのテスト用にDocomoのDOCTYPE宣言を入れたxhtmlのページを泳がせているんですが、
ログを見ていたらクローラーの中でこんなやつがいました。

IP：　209.191.126.182
HOST:　cr06.wap.search.mud.yahoo.com
UA:　lwp-trivial/1.41

HOSTからしてどうやらYahooのモバイルクローラー？（wapってあるし。でも情報が少ないからなんとも）
しかしUAが違うしなあ...と思って調べていたら、
このUAはperlがページを取得した時に残されるもの(LWP::Simple)とのこと。
mixiのRSS fetcherも以前はこれだったとか、そうでないとか。

とにかくこのクローラー、ひたすらrobots.txtとサイトマップをセットで拾っていきます。
Whois見ても本物のYahooの様なので、ちょい様子見で。