2014/07/22

クロールバジェットはないのか?

マット・カッツ氏 インタビュー by エリック・アンギ―

マット・カッツ氏は2000年1月にソフトウェアエンジニアとしてGoogleに参加。ノースカロライナ大学チャペルヒル校でコンピュータグラフィックスの博士号を取得後、ノースカロライナ大学からサイエンス修士を、数学とコンピュータサイエンスの学士号をケンタッキー大学から受領している。
Googleでの経験以外に、国防総省で最高機密クリアランスも取得し、ゲームエンジン会社でも働いた経験がある。Googleでは、Googleのフィルターであるセーフサーチを作成。今のところ、Googleは一番おもしろい仕事だとマット氏は話す。現在、Googleでウェブスパムチームのリーダーを務め、彼のブログ内ではウェブマスターに関する事柄について述べている。

<インタビュー>

エリック:「クロール・バジェット」について少しインタビューさせてください。私の理解では、Googlebotは、ウェブサイトが何ページあるか知った上で来て、それらのページが終われば去る、ということなのですが。。。


マット:覚えておいてください。まず、いくつか違った巷の認識をご紹介したいと思います。第一に、インデックスのリミットというものは存在しないということです。たくさんのひとはドメインがある一定の数のページしかインデックスされないと思っているようですが、そういうことはありません。


それから、我々のクロールにはハードリミットというものも存在しません。最も良い捉え方として、我々がクロールするページ数というものは、あなたのPageRankの割合で決まります。もしあなたのルートページにたくさんのリンクがあれば、我々は確実にそれをクロールします。そしてあなたのルートページが他のページヘリンクされ、それらがPageRankを得れば、それらもクロールします。しかし、あなたのサイト構造が深くなればなるほど、PageRankは減少します。


(”我々がクロールするページ数というものは大体で言えばあなたのPageRankの割合で決まります”)


他の考え方として、あなたのサイトのPageRankの低いページは、同等かそれ以上のPageRankを持つページのより大きな範囲と競っています。ウェブ上にはたくさんのとても低いもしくはゼロにちかいPageRankを持つページがあります。たくさんリンクされるページは発見されやすく、クロールもかなり早くされがちです。PageRankが低いページはそれほど頻繁にクロールされないでしょう。


クロール・バジェットの概念に関して興味深いことのひとつは、ハードリミットというものはクロール自身にはないものの、ホストロードという概念があることです。ホストロードとは、ウェブサーバーが扱うことが可能な同時に起きるコネクションの最大数のことです。一度に一つのbotしか持てないウェブサーバーを持っていると想像してみてください。このせいで一度に1ページしかフェッチできないので、ホストロードはとても低いものとなりますが、例えばFacebookやTwitterなんかは、同時にたくさんのコネクションを扱えるのでとても高いホストロードを持ちうるはずです。


あなたのサイトは同じIPアドレスで違ったサイトを持つバーチャルホスト上にあるかもしれません。理論上では、我々がどれだけあなたのサイトをクロールするか、リミットに達することがありえます。例えば、ある時に我々があるサイトから2ページしか扱えず、決まった時間内でのみクロールしていたとして、そのホストから我々がフェッチできるページ数の上限をつけるでしょう。


エリック:では基本的に2つの要因があるのですね。第一にPageRankで、それはサイトでどれだけのクロールがなされるか仮に決定する。しかしホストロードも同様に影響する。


マット:その通りです。現時点で非常に多くのサイトは、第一の範疇、つまりPageRankとその他の要因が、サイト上でどれほど深く我々が行くか決定する状態にいます。しかしながら、ホストロードがサイトに影響をおよぼすことも考えられます。


これが重複コンテンツのトピックへとつながります。我々が1サイトから3ページをクロールしたとして、そのうち2ページが3つ目の複製だと発見したと考えてみてください。我々が3ページのうち2ページを落とし1ページのみキープします。つまり、より少なく良いコンテンツを持っていることになります。なので我々はそういったサイトからはそれほどクロールしない傾向にあります。


もしホストロードのリミットがあるなら、あなたのサーバーのせいで我々がフェッチできるページ数に限度があるということで、重複コンテンツをあなたが持ち我々がそれらのページを切り捨てたということは、他の良くユニークなクオリティコンテンツを持つページを、インデックス内に載せる機会をあなたが失った、ということを意味します。


エリック:それは常々我々もみなさんに与えてるアドバイスです。重複コンテンツの対価はクロール・バジェットをムダにする、という。


マット:そうですね。一つの概念として、もしあなたがある程度のPageRankしかなければ、そのサイトからクロールする程度も限られます。つまり、その中のいくつかのページは切り捨てられ、それはある意味ムダになります。そして同様にホストロードの範疇も考えられます。つまり我々がそれほどたくさんフェッチできないところです。


エリック:他の背景コンセプトとして、ムダなリンクジュースの概念を話したいと思います。PageRankという言葉を使いますが、より一般的にはリンクジュースのことを言っています。それはもとのPageRankのコンセプトを超えた、信用や権威といったコンセプトに関連しているかもしれません。1つのページから重複ページヘリンクをした時、それはPageRankを浪費していることになる、ですよね?


マット:そういうこともあります。一般的に、重複コンテンツは何ページがクロールされるかについての最大の要因ではありませんが、1要因ではあります。私の全体的なアドバイスとしては、もしサイト構造を前もって修正しておけば、それは非常に役立つでしょう。なぜならあなたは重複コンテンツやそれに付随する事柄について心配する必要がなくなるからです。同様に重複URLに対して301 Redirectsを使ってひとつのURLへマージすることもできます。301 Redirectsが使えないのなら、rel=canonicalへ戻っても良いです。


301を作るのにウェブサーバーへアクセス出来ない人もいるかもしれません。たとえば学校のアカウントであったりフリーホストであったり。しかし、もしサイト構造を直すことができるのなら、それは301やrel=canonicalで取り繕うよりも好ましいです。


エリック:なるほど!それは確実に最上のスタンダードですね。たとえば、10個の他のページヘリンクをもつ1ページがあったとします。それらの3つのページは複製であり切り捨てられたとしたら、3つの得票数を失った、ということでしょうか?


マット:確実にそうとも言えません。こういった場合が、人々が実験が必要な場面です。我々がしていることはページを完全に切り捨てることというより、マージすることです。もしあなたが複製である3ページにリンクさせていたら、サーチエンジンはこれらが複製であることに気づき、これらの入ってくるリンクジュースをマージされたページヘトランスファー(移行)させられるかもしれません。


(”(重複コンテンツで)我々がしていることはページを完全に切り捨てることというより、マージすることです”)


PageRankが完全にムダになっているということが常ではありません。そのサーチエンジンと、その実行によります。それぞれのサーチエンジンはことの実行を違ってするでしょうから、もしあなたのリンクが全て一つのページヘ行くというのなら、それは確実に好ましいです。


エリック:セッションIDについて少しお話し願えますか?


マット:使わないでください。今の時代、殆どの人はセッションIDを必要としないサイトを作るとても良い方法を知っているはずです。現時点で、ほとんどのソフトウェア作成者はそれを考えているべきです。サーチエンジンの観点からというだけでなく、ユーザビリティの観点からもです。ユーザーはよく見えるリンクをクリックしがちですし、よく見えるURLを覚えている傾向にあります。


それでももし避けられないのであれば、GoogleはセッションIDを扱うためのツールを提供しています。人々がURLパラメータが無視し、もしくは使ってなく、価値を持たない場合、より良いURLに書き換えてください。Yahoo!では書き換えるサービスを行っています。Googleもその方法を提供していますし、他のいくつかのサーチエンジンも提供しています。セッションIDを回避することができるなら、それが普通ですし最善です。


エリック:究極的には、そこには重複コンテンツとみなされる危険性があります。


マット:あります。サーチエンジンは大抵の場合対処できます。一般的には大きな問題ではありませんが、ページの複数バージョンが違ったセッションIDでインデックス化されたケースをいくつか見たことはあります。最善なのはいつも自分で自分のサイトをケアすることで、そうすればサーチエンジンがどう扱うかを心配することはないはずです。


エリック:アフィリエイト・プログラムについて触れましょう。他の人から自分へトラフィックを送ってもらい、彼らはURLへパラメータを乗せる。あなたは自サイトへの全ての訪問のパラメータを整備する。とても一般的ですね。これはサーチエンジンがプロセスを得意とするものなのでしょうか?それとも重複コンテンツとみられるリスクがあるのでしょうか?


マット:重複コンテンツが発生し得ます。もしあなたが共同ブランドなんていうものを扱っていたとして、ページ上の唯一の違いがロゴだけなんてことがあれば、ユーザーはこういったものは基本的に同じページとみなします。サーチエンジンは基本的にこういったものをマージするのに長けていますが、他のシナリオでは確実に重複コンテンツの問題を引き起こし得ます。


エリック:古典的なSEOのアドバイスとして聞くのは、パラメータをURLへのせさせておいて、ユーザーがあなたのサイトへのそのリンクをクリックしたとき、パラメータなしで301リダイレクトをし、そのパラメータをクッキーでなくすことをしろ、というものです。


マット:それも可能です。同様のことが例として広告のランディンページなんかにも使えます。あなたは自分のアフィリエイトランディングページの広告を別のURLディレクトリへ作り、例えばrobots.txtでブロックすることを考えるかもしれません。広告のように、アフィリエイトリンクもふつう、サーチエンジンでなく実際のユーザーのためのものです。なのでそれは追うことができやすく、もしそれらのページがクロールされることがまずなければ、アフィリエイトコードが漏れたり重複コンテンツ問題を産んだりすることを心配しなくてよいのです。


エリック:もしGooglebotがアフィリエイト・リンクを見つけたとしたら、そのリンクをおすすめと広告、どちらにみなしますか?


マット:ふつう我々はそういった種のリンクを正しく扱いたいと思っています。多くの場合、そのリンクが本質的にお金のために人々を誘導していたら、我々はそれをおすすめとはみなさないでしょう。


(”(アフィリエイトリンクについて)我々はそれをおすすめとはみなさないでしょう”)
エリック:ファセットナビゲーションについて話しましょう。例として、Zapposでは人々が靴をサイズ、色、ブランドによって購入し、同じ商品が20の違った方法でリストされています。とても難しいです。こういったシナリオについてどう考えますか?


マット:ファセットナビゲーションは大抵の場合トリッキーです。一般的なユーザーではうまく扱えない人もいて、かれらはどこにいるのかわからなくなります。コンテンツの部分部分をナビゲートするのにたくさんの道があるかもしれませんが、可能ならコンテンツのそれぞれのページにひとつのURLを持つべきです。データを細分化するたくさんの方法があります。もし自分でコンテンツの特定の部分へ到達する自分が考える最も重要な方法がなにか決められるのであれば、URLパラメータのなかでのヒエラルキーを持とうとすることができるでしょう。


たとえば、カテゴリーが最初のパラメータであり、値段が2番目かもしれません。たとえもし誰かが値段によってナビゲートし、次にカテゴリーをクリックしたとしても、あなたがものがどうカテゴライズされるべきかというヒエラルキーは、ポジションに関していえばURLパラメータのなかで強要されるのです。


このように、一番重要なカテゴリーは第一に、そして次は2番目に。こういったことがサーチエンジンにとってコンテンツをより良く知るための助けとなります。なぜならもし最後のパラメータを取り除いたとしても、それは有益または似たコンテンツを得ることができると気づけるからです。一般的に、ファセットナビゲーションは難しい問題です。なぜなら人が1つのページを見つけるのにたくさんの違った道を作り出しているからです。ペイロードへ達するまえにたくさんの中間経路があるのです。


もし中間ページに関してことを比較的浅く保てるのなら、それは良いやり方です。もしひとつの商品を見つけるのに、ファセットナビゲーションの7層をクリックしていかないといけなかったら、その人はきっと我慢しきれないでしょう。サーチエンジンサイドからしても、商品へ到達するのに我々が7~8層のファセットナビゲーションをクリックしていかないといけなかったら、それは同様におかしなことです。ある意味、それはとても多くのクリックで、人々が購入するための特定の商品がないそれら中間ページのために使われるたくさんのPageRankです。こういったクリックのそれぞれは、PageRankを浪費する小さなパーセンテージの機会なのです。


ファセットナビゲーションがあるユーザーにとって良いものである一方で、もしあなたがページをどうカテゴライズするかのヒエラルキーを自分で決められるのなら、そのファセットナビゲーションが比較的浅いものになるようにしてください。これらは同様にサーチエンジンにとっても、実際の商品を見つけやすくするのに役立ちます。


エリック:もし違うページで基本的に同じ商品、もしくはかなり似ている商品が違うソート順で載っていたら、カノニカルタグの適用は好ましいですか?


マット:なり得ます。もしくは自身でパラメータのポジションを再整理するのも考えられるでしょう。一般的に、カノニカルタグというものはあなたがサーチエンジンに2つのページのコンテンツは基本的に同じである、と伝えるために作られています。あなたは必ずしも、11種の違った色を持つ商品があったら、それの黒バージョンと赤バージョンの違いを明確にしたいとは思わないかもしれません。単にデフォルトの商品ページを持ち、それが賢いことにドロップダウンメニューのようなものを持っているようにしたいかもしれません。商品の少数のバリエーションを見せ、rel=canonicalを持つのは、rel=canonicalタグを使うのに良い方法でしょう。


エリック: PageRankへの影響、クロールと基本ツールのインデックスについて話しましょう。我々のお気に入り301 Redirectsから始めましょう。


マット:基本的に、301 RedirectはPageRankを渡します。サイト上でページ間を移動するのに、そしてサイト間でさえも移動するのにそれは便利になり得ます。たくさんの人が使い、比較的上手く動いているように見え、その働きはとても早いです。私もmattcuts.comからdullest.comへ行くのに使ったことがありますし、そのトランジションはとても上手く行きました。私のテストによれば全く成功でした。実際、今dullest.comへ行っても何のページも得られません。全てのページはmattcutts.comへ移動しました。もしページごとの移動をしているなら、全てのページは新しいサイトへうつるので、これはあなたにとってとても強力な武器となります。




エリック:一つのドメインから別なドメインへ移動するとして、サーチエンジンと全てのユーザーエージェントにドメインの道標の指示を出すある少しの宣言を書いたとします。このような時、サイトへのリンクをもともと実行したユーザーが、新しいドメインへリンクされなかったことでPageRankへの影響はあるのですか?


マット:それは良い質問で、私も100%確信を持ってはいないです。それがPageRankの損失になり得る、ということは確実に言えます。クロールとインデックスチームが、そういった自然なPageRankの損失を実施しているのかどうかは100%確信は持てません、なのでこの特殊な件については調べないと行けないです。(補足:後のemailにより、マットはこのようなケースが有ることを認めました。301によるPageRankの損失は存在します)


エリック:302 Redirectsについて少し話しましょう。


マット:302は一時的なものとして意図されてます。もし何かをその場に少しの時間だけ置こうとしているなら、302は完全にそれに適しています。一般的に、それはPageRankを流しませんが、とても便利になり得ます。もしサイトが一時的になにかをしているなら、302はそういった状況に全く適しているでしょう。


エリック:それではHTTPステータスコードがなかったり200を返すサーバーサイドリダイレクトの場合は?


マット:200のみだったら、我々は返されたコンテンツは我々が求めたそのURLにあると仮定するでしょう。もしあなたのウェブサーバーがサーバーサイドにおかしな書き換えをしていても、我々はそのことを知り得ません。我々がわかることは我々が古いURLをリクエストたことで、なんらかのコンテンツを得、それをインデックスすることです。それをオリジナルのURLロケーションのもとにインデックスするでしょう。


エリック:では本質的に302 みたいに?


マット:いえ、そうでもありません。我々が求めたページと違ったページコンテンツを返すために、本質的にウェブサーバー上でごまかしをしているのです。我々が懸念する限りでは、我々はリンクをみつけ、そのページヘのそのリンクを追って、そのページを求めます。あなたはコンテンツを返し、我々はそのコンテンツをそのURLでインデックスします。


人はいつも動的なことをサーバーサイドでやれます。ウェブサーバーに実装されたCMSが301や302をしないでしょうが、それは複雑で非常にエラーを引き起こしやすいことは想像しやすいと思います。


エリック:カノニカルタグの概要を話していただけますか?


マット:いくつか覚えておく事柄があります。もし重複コンテンツをサイト構造を使うことで減らせるなら、それは好ましいことです。合体させるページは必ずしも完璧な複製じゃなくても、同様の商品でコンセプト的に重複していたり、物事で非常に関連しているべきです。2009(昨)年12月に発表しましたが、現在はクロスドメイン rel=canonicalが可能です。


例えば、私の昔のスクールアカウントに、rel=canonicalをつけてmattcutts.comへ指し示すこともできます。もしウェブサーバーにリダイレクトを足すためにアクセスできなかったら、rel=canonicalを使うのは良い方法です。しかし、大抵の人はそれを、インデックされたくないページの他のバージョンよりも、カノニカルバージョンが確実にインデックスされるように、重複コンテンツのために使います。
エリック:では、カノニカルタグを持つページへリンクすると、それは本質的にページのカノニカルバージョンへの301のように扱うのですか?


マット:そうですね。301の劣化版ととらえるのは悪くない方法でしょう。もしあなたのウェブサーバーが301ができるなら、それを実装すればいいでしょうし、もしウェブサーバーへのアクセスがなかったり、301をセットアップするのがとても大変であるようなら、rel=canonicalをすればよいです。
ページをrel=canonicalを使って自身へリンクさせるのは全く問題ないですし、少なくともGoogleにとっては、rel=canonicalをあなたのサイトの全ページにつけるのも全く問題ないです。なるべく最低限で使われるようにしたほうがいいと考えられていますが、そうではありません。我々はサイトの全ページがrel=canonicalを持つシチュエーションを自問自答してみました。あなたがそれらが正しいページを指し示すよう管理している限り、問題はなにもないはずです。


エリック:たしか昔にあなたがカノニカルタグのことを「指令」と呼ぶには少し強すぎる、と言ったのを聞いた覚えがあります。あなたは「ヒント」と呼びますね。


マット:そうですね。一般的に、クロールチームはこういったヒントを考慮し、大抵の場合それを広告から得て行動に移します。もしそれを指令と呼ぶならそれを守る義務があるように感じますが、クロールとインデックスチームは、サイトオーナーが間違えて墓穴を掘り、rel=canonicalタグのいうことを聞いていないのかどうか、最終判断する権利を持っていたいのです。大抵の場合、人々はrel=canonicalタグの効果が見れます。もし我々が彼らがそれを意図していなかったと判断できれば、我々はそれを無視します。


エリック:ウェブマスターツールの"ignore parameters(パラメータを無視する)"は、カノニカルタグを同様なことをするのに有効な違った手です。


マット:そうです、本質的にそうです。これは良いことで、なぜならrobot.txtは少し鈍くなりがちで、もしあなたがページがクロールされるのをブロックして我々がフェッチしないと、我々は他のページの複製バージョンだというようにみなせないからです。しかしもしあなたがURL上のパラメータが必要でないウェブマスターコンソールで伝えてくれれば、我々は利を得られます。


エリック:KMLファイルについて少し話しましょう。クロールバジェットをセーブするためにこれらのページをrobots.txtに入れることは適切ですか?


マット:基本的に私はそれを推奨しません。クローラとインデックスチームからの現時点での最も適切なアドバイスは、あなたが重要と思うサイトのページをGoogleにクロールさせることで、そうすれば我々は余分な重複を取り除くようにします。あなたはそれを事前に良いサイト構造や301で修正することができますが、もしrobots.txtからなにかをブロックしようとしたりすると、多くの場合我々はまだそのURLを見つけインデックスに残します。なので必ずしもクロールバジェットをセーブするとは限りません。これはなかなか興味深くて、GoogleはたとえそれはHTML拡張子ではなかったとしてもたくさんの違ったページをクロールしようとし、実際にGoogleはKMLファイルも同様にクロールするのです。


(”もしrobots.txtからなにかをブロックしようとしたりすると、多くの場合我々はまだそのURLを見つけインデックスに残します。なので必ずしもクロールバジェットをセーブするとは限りません”)


我々が基本的におすすめするのは、Googlebotにそれらのページをクロールさせそこで重複をなくさせることです。もしくは、可能であるなら、サイト構造を使って重複問題を事前に修正することです。もしあなたのサイトの50%がKMLファイルで、不釣り合いに大きな数のフォントがありこれらをクロールされたくないのであれば、robots.txtを使えます。robots.txtは個別指令の万能札を持っているので、ブロックできます。ほぼ全てがHTMLで、ほかに少しページや違うファイル・タイプがある大抵のサイトでは、Googlebotにクロールさせることをおすすめします。


エリック:もしそれが実際のページに対して少しの割合であるなら、ヘンな策略はやめるべきですね。


マット:その通りです。


エリック:Googleはコンテンツタイプを決定するのにHEADリクエスト(HTTP リクエスト)をしますか?


マット:知らない人のために、コンテンツをフェッチしたりチェックするのに違った方法があります。もしGETをするなら、ウェブサーバーにそのコンテントが変わったかどうかを尋ねています。ウェブサーバーはyesかnoで多少なりとも返答できますし、コンテンツを返さなくても実際は良いわけです。一件するとHEADリクエストはサーチエンジンにとってWebをクロールし最後にクロールした時からなにか変化があったページのみフェッチするために、素晴らしい方法と思うかもしれません。


しかし実際には、HEADリクエストをすると、殆どのウェブサーバーではページが変わったかどうか判別するためにほぼ同じだけの量の仕事をするはめになっています。我々のテストでは、特定のページにHEADをするよりも、GETをするほうが、大抵の場合より効率的であると判明しました。いくつかの事柄にはHEADを使うこともあります。例えば、画像クロールではHEADリクエストを使うかもしれません。なぜなら画像はコンテントの中でウェブページよりも非常に(容量)大きなものだからです。


ウェブ、テキストコンテンツ、そしてHTMLに関していえば、一般的に我々はHEADクエリよりもGETを単に使います。今も、ウェブサーバーがそのページが変わったかどうかを判別できるIf-Modified-Sinceのようなものを使います。ウェブをクロールするのに賢い方法が幾つかありますが、HEADリクエストは、画像コンテンツに関して使うとはいえ、HTMLコンテンツをクロールすることに関してはそれほど帯域幅を節約しないです。


エリック:予想するにビデオコンテンツにも同様に使えるだろう、ということであってますか?


マット:ですね。しかし念のため確認する必要があります。


エリック:ファセットナビゲーションの話題をひろげるにあたって、我々はとても複雑なファセットナビゲーション構造を持ったサイトに取り組んだことがあります。それは実際はとても良いユーザーエクスペリエンスです。実装したあと、コンバージョンに素晴らしい上昇が見られました。ビジターごとにより良い収益を生み出し、とても良いサインでした
マット:本当ですね。


エリック:一方で、我々が気づいたのは、サイト上でインデックスされたページ数が著しく落ちたことです。思うに、それはこれら違ったページの種類が、大抵の場合に単に商品を違った順序でリストしていただけだからです。
これらのページはテキストリッチではありません。クローラが噛み砕ける部分は多くなく、質が貧弱なページや複製のように見えます。このような場合どうやって対処するのが最善でしょうか?これらのページをクロールされるのを防ぐべきでしょうか?


マット:ある意味では、ファセットナビゲーションはサーチエンジンにとってなんとなく迷路のように見えることがあります。なぜならデータを細分化するのにとても多くの違った方法を持ちえるからです。もしサーチエンジンがその迷路を抜けられず、あちら側にある実際の商品へたどり付けなかったら、時にそれは各ページの価値を決定するアルゴリズムの観点からいうとトリッキーになり得ます。


先ほど私が述べたアドバイスに戻りますが、考えるに値することのひとつに、もしあなたがデータを覗き見るためのレンズやファセット(=面)の数を制限することができるなら、それは手助けになるでしょうし混乱を時に減らせるでしょう。これは確実にあなたが考えてみるべきことです。もしデフォルトカテゴリー、ヒエラルキー、またはあなたが最も効率的と思うもしくは最もユーザーフレンドリーだと思うナビゲートの方法があるのなら、それは試す価値があります。


これらのファセットナビゲーションページにrel=canonicalを試して、ファセットナビゲーションを通して降りていく標準の方法へ戻ることを想像してみてください。こんなことが、どれくらいそれがうまくいくか見るための実験としてあなたが恐らく試してみるべきことでしょう。これがたくさんのそういったファセットページを、違ったたくさんの別な商品へ伝わる一つの道へまとめるのに有益だと私は想像しますが、ユーザーがそれに対してどうリアクションするかも知る必要があるでしょう。


エリック:ではGooglebotがあるサイトへ来て、ページの70%が他ページヘリダイレクトされるかrel=canonicalを持っているのを見たとしたら、どうなりますか?もしこういったシチュエーションの場合、このタグをここで前に見たことがあるからと、これらのページをクロールする時間を減らしますか?


マット:rel=canonicalが影響を与えるかということよりも、我々のアルゴリズムはそれらのページの価値と有益性を確かめるためにサイトをクロールしている、ということです。もし我々が価値が低いとみなすページがたくさんあれば、そのサイトからはそれほど多くのページをクロールしないかもしれません。そしてそれはrel=canonicalからは独立しています。これはもしそこにあるのが単にたくさんのリンクばかりであるなら、ただの普通のファセットナビゲーションにも起こるでしょう。


これは本当に個々のサイトが違ったアプローチ方で実験したほうがよい事柄でしょう。rel-canonicalを使ってサーチエンジンを違ったファセットや違ったカテゴリーを通してナビゲートするデフォルトの道へ向かわせることを、私は必ずしも間違いとは思いません。あなたは単にファセットの実験をして複数になった道の量を減らし、より論理的な道の構造へ戻ろうとしているだけでしょう。




エリック:クローラがたくさんの時間をこういったインデックスされたくないページに使うことが、良くない傾向であるように聞こえます。


マット:それは正しいです。考えてみるなら、データを細分化する個々のレベルまたは違った各方法というのは、また違う次元なのです。クローラが商品カタログ全体をクロールすること x そのページ数ーそしてそれらのページは実際には商品を持たないかもしれないーという次元の。市、州、職業、色、価格etcに添ってナビゲートするかもしれません。あなたは大抵のページにたくさんのテキストと実際の商品を持たせたいはずです。ナビゲーションが複雑すぎると、サーチエンジンが見つけてインデックスし、ユーザークエリに応答して返すものがより少なくなります。


多くの場合、ファセットナビゲーションはユーザーもしくはサーチエンジンと、実際の商品との間にあるレイヤーのようになり得ます。それは単にたくさんの違った倍増するページの何重もの層であり、コンテンツへ直接導いてくれるものではありません。サーチエンジンやユーザー視点からすると時にそれは難しく感じられます。


エリック:PageRankスカルプティングはどうでしょうか?作成者はエンコードされたJavaScriptを使ったリンクのリダイレクトを考えるべきですか?それともiframe内に実装されたリンクですか?


マット:PageRankスカルプティングについて以前お話したアドバイスと同じです。PageRankスカルプティングがGooglebotをサイト内でガイドするのに最も適した方法ではない、と話しましたし、その前からもPageRankスカルプティングはあなたの時間を使うのにベストなものではない、と言っていました。なぜならその時間はもっとより多くのサイトへのリンクを得るのと、より良いコンテンツを作るのに費やすほうが良いからです。


PageRankスカルプティングはあなたが既に持つPageRankを取り、それをあなたがより効果的だと思う別のページヘガイドしようとしますが、それより良い方法があります。もしあなたが素晴らしいコンバージョンや素晴らしい利益マージンを与えてくれる商品を持っているなら、それをサイトのルートの前面と真ん中に置きましょう。たくさんのPageRankがその特定の商品ページへのリンクを通して流れるでしょう。


サイト構造、たくさんの人々をあなたが見て欲しい商品へ飛ばすためにどのようにリンクと構造がページ上に表すか、リンク上の個々のPageRankスカルプティングをしようとするよりアプローチとして良い方法です。もしサイト構造を一番重要なページか最も大きな利益マージンを生み出すページのPageRankにフォーカスできなら、iframeやエンコードされたJavaScriptを使おうとするより、直接PageRankをスカルプティングするより、良い方法です。


サイト構造をまずきちんとできたら、残りは少ないです、そうすればPageRankスカルプティングのことを考える必要もないのでは、と感じます。それ以上を考え、完璧に明確になるために、人は自分のサイトでなにをしてもよいでしょう。私の経験から言えばPageRankスカルプティングは時間を使う最善のものではないです。


エリック:ファセットナビゲーションの問題をもつサイトを例として出しましたが、述べたとおり、インデックスページ数の下降が見られます。彼らは、Googlebotが彼らがインデックスされたくないページ上で時間をつぶさないような方法を欲しがっています。これに関するあなたの考えはどうですか?


マット:良い例としては、あなたの一番売れ筋の10個の商品を、フロントページにおき、そしてそれらの商品ページ上に、次の売れ筋10個もしくは100個の商品へのリンクを置くことです。各商品が10個のリンクを持ち、そしてその10個のリンクがまた他の比較的売れている10この商品を指し示すのです。Youtubeやアマゾンのようなサイトを考えてください。かれらはユーザーを関連ページや彼らが買いそうな関連商品へ飛ばすのにとても素晴らしい仕事をしています。


もしそういったページについて何か良さそうなものが目についたら、ユーザーはそれをクリックしてそこからまた5つの良さそうで関連した商品を見るでしょう。ユーザーとサーチエンジン両方を、深いファセットナビゲーションへ飛び込ませるのではなく、直接ユーザーの重要な商品へ導いているのです。こういったことがサイトを作成し実験することで最善の方法が何か突き止められるのです。


(繰り返しになりますが)PageRankスカルプティングをするのではなく、一番売れるもしくは一番重要だと思う商品を前と真ん中に置くサイト構造をつくる方法があります。それらが層の上にあれば、人々はそれをクリックする傾向にあります。そのPageRankをとても慎重にそれら関連商品のなかに分散させ、それら関連リンクをナビゲーションではなく商品ページへ直接使うことができます。必ずしもPageRankスカルプティングをすることなくそれを実現する方法があるのではないかと私は思います


エリック:もしJavaScriptエンコードやiframeを使うことを選択したとして、それはスパム行為や時間の無駄使いの可能性があるとみなされるのでしょうか?


マット:それがスパム行為とみなされるかどうかは確信は持てませんが、PageRankスカルプティングを効果的じゃなくするためのnofollowのもともとの変更は、少なくとも部分的に動機付けされています。なぜなら人が関わるサーチの特徴は、サーチエンジンにとってのそれと同じもしくは近いつながりを、ユーザーに対しても見たいからです。あなたのユーザーにはサーチエンジンが行くところへ行ってほしいでしょうし、ユーザーが行くところへサーチエンジンにも行って欲しいでしょう。


(”PageRankスカルプティングを効果的じゃなくするためのnofollowのもともとの変更は、少なくとも部分的に動機付けされています。なぜなら人が関わるサーチの特徴は、サーチエンジンにとってのそれと同じもしくは近いつながりを、ユーザーに対しても見たいからです”)


ある意味では、PageRankスカルプティングはそこから分岐しようとしていると思います。もしあなたがそちらの方向へ足を踏みだそうとしているなら、なぜそこから分岐してbotをユーザーとは違った場所へと送ろうとしているのか自問自答するべきです。私の経験では、我々はbotがサーチエンジンユーザーと同じページ上にいるかもしくは基本的に同じ方向へ動いているのを見たいのです。その道筋で、iframeやおかしなJavaScriptがしみわたりサーチの質に影響し我々がPageRankがどうそれらのリンクを通して流れるかについて変更したりするかもしれないことは想像できます。


それは必ずしも我々がそれをスパムだと考えるわけではなくて、我々はサーチエンジンが見つけたそのリンクやページが、サイトを訪れたユーザーが見つけるリンクやページと同じ近所にいて同じ質を持って欲しいからということです。


エリック:ではPDFファイルは?


マット:もちろんPDFファイルもプロセスします。PDFファイル内のリンクがPageRankを渡すかどうかについてはお話しません。しかし、PDFについて考えるのに良い方法として、これらはFlashのようなもので、ウェブにとって継承されたり本来のフォーマットではないということであり、しかしとても便利になりうる、ということです。Flashファイル内で使えるコンテンツを見つけようとするのと同じように、PDFファイルでも使えるコンテンツを見つけようとします。同様に、ユーザーは必ずしもPDFふを送られるのが好きではないです。もしあなたがコンテンツをウェブ本来のフォーマット、つまりピュアHTMLのようなものにできるなら、それはしばしばピュアPDFファイルよりもユーザーにとって便利です。


エリック:人が他の人に編集されたくないドキュメントがあり、しかしそれを配布して使うのを許したいときの典型的な例があります。例えばeBook。


マット:パスワードで守られたPDFファイルをインデックスできるとは思えません。同様に、PDFファイルで画像ベースのものもあります。しかしながら、ある状態ではPDFにOCRを走らせることもできます。


エリック:もし画像ベースでなくテキストベースのPDFファイルがあったら?


マット:もちろん使いたければ使うことができますが、基本的に私はPDFファイルがファイルというものは人々が最後に出会うものだと考えていて、ユーザーはそれを開くのは少し余計に手間がかかると考えていると思います。それがユーザーエクスペリエンスに影響することがあると、こころにとめる必要があります。


エリック:新しいJavaScriptのプロセスで実際になにをしているのですか?実際にJavaScriptを実行しているのですか?


マット:しばらくの間、我々はJavaScriptをスキャンしていて、リンクを探していました。GoogleはJavaScriptに関してより賢くなり、JavaScriptを実行できます。我々が全てのJavaScriptを実行する、とは言いませんので、JavaScriptを実行できない条件があるときもあります。確実に一般的でよく知られたJavaScript、例えばGoogle Analyticsみたいなものがあり、あなたは実行すらしたくないでしょうが。なぜならGooglebotからGoogle Analyticsへファントムが訪れるようなことを生み出したくないでしょうから。


必要性があるとき、JavaScriptの大きな断片を実行する能力も我々は持っています。ひとつ覚えていてほしいのは、もしJavaScriptを使って宣伝しているなら、nofollowをJavaScriptのリンク上に使うことができます。


エリック:もし広告をサイト上に持っていたら、Googleにとっては人がそれらリンクをnofollowするのが願いですよね?


マット:もちろんです。我々の理念は変わってませんし、変わるとも考えていません。もし広告を買っているのならユーザーにとっては素晴らしいでしょうが、我々はサーチエンジンのランキングに広告に影響を及ぼしてもらいたくはありません。例えば、もしあなたのリンクがリダイレクトにいき、そのリダイレクトがrobots.txtーそれは我々がそのリンクを追わないよう見張っててくれてーからブロックされているとします。もしJavaScriptを使っているなら、nofollowをJavaScript内で使えます。たくさんの広告が、それらは一時的なので302を使っています。これら広告は永久的でないと意図され、我々もそれらを適切にプロセスしようとしています。


我々のそれに関するスタンスは変わっていません、実際に、我々は人々にもっと多くのリンクスパムについて報告をするよう来月から求めていきます。スパムを撃退するための方法と新しいいくつかのツールとテクノロジーもできてきます。違ったタイプのリンクスパムについても、いつかフィードバックを求めるかもしれません。


エリック:では誰かが302を広告内のリンクで使っていたとしたら?


マット:問題ないでしょう。我々は基本的にそれをプロセスしそれが広告だと気づくことができます。我々はたくさんのことをしてそれが広告だと判別できるようにし、プロセスするのにそれが過度にサーチエンジンに影響しないようにこころがけています。


良いことに、非常に多くの広告ネットワークがたくさんの違ったタイプのプロテクションを持っているらしいということです。一番ふつうなのは、302リダイレクトをrobots.txtによってブロックされたなにかを通り抜けさせることです。なぜならbotは貧弱なクレジット率をもつか、もしくはクレジットカードを承認すらされていないため、広告は確実にコンバートされないので一般的に人はbotに広告を追いかけてほしくないからです。それがあなたのAnalyticsをめちゃめちゃにするのも好ましくないです。


エリック:そのような状況で、リンクはリンクジュースを消費しますか?


マット:確認しないといけないです。それに関してクロールとインデックスチームに問いかけたことはありません。そのような状況は基本的にコンテンツのほぼ大半がHTMLであり、とても少ない広告部分を持つでしょうから、たいして大きな要因とはならないでしょう。


エリック:ありがとう、マット!


マット:ありがとう、エリック!


March 14, 2010



6821 words

0 件のコメント:

コメントを投稿