Moz - SEOとインバウンドマーケティングの実践情報

Google Localの問題点と、賢く有効活用するためのヒント（後編）

グーグルローカルに関するさまざまな問題点と、グーグルローカルを活用する上でのアドバイス。

Moz 2009/7/3 9:00 SEO | 解説／ノウハウ

SEOmozは英国Distilled社と提携し、検索エンジン市場のニュースと情報を提供している。この記事はDistilled.co.ukに勤務する協力者から提供されたもので、内容はすべて筆者自身の見解であり、SEOmozの見解を反映しているとは限らない。

この記事は前後編の2回に分けてお届けしている。グーグルローカルに注意を払うべき理由を説明した前回に続いて、今回はグーグルローカルに関するさまざまな問題点と、グーグルローカルを活用する上でのアドバイスをお伝えしよう。

グーグルローカルに関する問題点

以下に、グーグルローカルに関して僕が遭遇した一般的な問題をいくつか挙げる。

スパム。しかもその割合は高い。

僕は最近、ホテルを検索されることの多い米国の10都市について分析してみた。10都市は検索窓に「hotels in」まで入力したときに、グーグルサジェストで検索クエリの候補として出てくるところだ（まったく非科学的なやり方だってことはわかってるけど、恣意的でないスナップショットがほしかったんだ）。

それから、各検索結果について、10個セット10件分の結果を分析した。つまり全部で100件のローカル検索結果を分析したわけだ。その結果、そのうちの15件が、以下のいずれかの方法によるスパムだった。

メインのインデックスに紛れ込むスパム

以下に示した「hotels in boston」（ボストンのホテル）の検索結果を見てほしい。おかしなものが紛れ込んでるんだが、どれだかわかるかな？

そう、もちろん最後のやつだ。これは鍵の業者（locksmith）であってホテルではない。簡単だね。でも実は、これ以外にもおかしな点があって、それがすぐにはわからないのが問題なんだ。D（上から4つ目）の検索結果をよく見て。なんの問題もなさそうに見えるよね。これはClub Quarters Hotelのリスティングで、このホテルはたしかにボストンにある。ところが、ここに表示されているURLは「www.elephantcastle.com」で、実際のアクセス先はそちらになる（ちなみにこれは、ロンドンにある地下鉄駅「Elephant & Castle」のWebサイトではなく、ボストンに店を出しているバー・チェーンのサイトだった）。

こんなことが起こったのは、バーElephant & CastleとClub Quarters Hotelの住所が同じだったからだ。そしてグーグルは、リスティングを統合しようとしてかなりまずい仕事をしている。

グーグルローカルの詳細ページに紛れ込むスパム

C（上から3つ目）の検索結果に注目しよう。ホテル名の表示はなんの問題もないように見える。でもURLは「www.cheap-hotels.usa.net」だ。「www.cheap-hotels-usa.net」というURLはこのホテルのサイトを示していないから、前項のようなリスティング統合の問題じゃないことは確かだ。では、どうしてこのようなことが起きるのか？事情はもっとひどくて、クリックして詳細を見る（レビューのリンクをクリックする）と、このようなページが表示される。

これはなんとも奇妙なリスティングだ。ホテルの公式サイトが載っていないだけでなく、cheap-hotels-usaのサイトも出てこない。その代わりに今度は、Blogspot上にあるスパムブログにリンクしている。どうしてこんなことが？たぶんそれは、リスティングの中に「Edit（編集）」ボタンがあるせいだ。これをクリックすると、URLまで含めて、グーグルローカルに登録したテキスト情報が自由に編集できてしまう。

グーグルがどうしてこんな自由な編集を許しているのか、僕にはよくわからない。この件について、以前グーグルは、大半の編集は正しく行われたものだと言っていたし、規模の小さいニッチな店の場合はそれも真実だろう。でも、競争の激しいキーワードの場合はスパムをはびこらせるだけだ。ここで編集されたデータがグーグルローカルのメインインデックスに反映されて例の10個セットが表示されるには数週間ほどかかるから、「cheap-hotels-usa」のURLが今でも10個セットの中にあるんだ。

さて、ここで衝撃的な事実をお知らせしなくてはならない。もし君がホテルチェーンを所有していて、グーグルローカルに一括アップロードでリスティングを登録していたとしたら、グーグルはこの一括アップロードをそれほど信用していないらしく、ホテルのリスティングには編集機能ボタンが表示されないんだ。

言語

そういうわけでグーグルローカルは、ローカル検索のクエリを扱うために設計されたものだと思われているかもしれないが、実際には各国の言語による検索で、非常にお粗末な結果を返してくれる。

僕が見るかぎり、問題は、「google.co.uk」や「google.fr」「google.com」などにはそれぞれの地域に対応したインデックスがあるのに、グーグルローカルのインデックスは世界に1つしかないということだ。この問題点はさまざまな形で表れているけれど、なかでも最も重要なのは、グーグルローカルではあるページに関して1つの言語でしか登録できない点だ。したがって、「google.co.uk」で「madrid hotel」（マドリードのホテル）を検索すると、次のようになる。

そして、「google.es」で検索するとこうなる。

「google.es」で検索した結果の中に、「.com」ドメイン名（英語）と「.es」ドメイン名（スペイン語）が交じっている。「.es」ドメイン名のサイトは「google.es」で検索したときに出てきているから、かなりきちんと処理されている。お利口さんだね！

けれども問題となるのは、同じコンテンツで使用言語の異なる2つのバージョンがある場合なんだ。それが、サブドメイン上にあろうと、サブフォルダにあろうと、あるいはその国の国別コードTLDを使っていようと、グーグルローカルにとっては関係ない。1つの施設につき1つしかリスティングを登録できないんだ。だから、上記の例に出てくるHotel Regenteは（サイトに複数の言語バージョンを用意しているのに）、英国内から英語で検索しても、スペイン語版のトップページしか表示されない。

これはまずいよね？ぜひとも解決してもらいたいものだ。通常の検索結果ページなら、グーグルは言語や地域を実にうまく検出しているんだから、その言語／地域絞り込み検出機能をグーグルローカルのインデックスにも適用したら、すばらしいことになるだろう。

確認作業

これは3つ目の問題点だが、先に述べた2つのの問題にも関係している。あちこちに営業拠点（実際の店舗やホテルなど）がある場合、それを一つひとつ登録するのは大変な作業になるだろう。何百という営業拠点について、データの整合性を取って、情報の正確さを確認し、調整していくことを想像してみよう。

でも、そんなことをする必要はない、そうだろ？一括アップロードができるじゃないか？まあ、確かにできることはできるけど、さっき言ったように、一括アップロードはグーグルからそれほど信用されていない。だから結局のところ、1つ1つ個別に確認していくしか方法はなくて、すごくたくさんの営業拠点があった場合はほぼ不可能だ。

アドバイス

それで、今日の記事の要点は何か？そうだな、それは2つある。まず1つは、みんなが自サイト（あるいは自分の顧客のサイト）の最適化の方法について、より深い知識が得られるよう、グーグルローカルが現時点で抱えている問題点を明らかにすること。これはもうできたと思う。

2つ目は、みんながじっくり考えて、できればそれを実際に採用してもらえるようなヒントを提供することだ。ということで、グーグルローカル利用のヒントを。

1. どうしても必要な場合を除いて、一括アップロードは避けること

ローカル検索の情報を編集するウェブマスターの能力と、グーグルから信用されていないという事実を考えると、一括アップロードはできるだけ避けて、グーグルローカルで表示してもらいたい施設や店舗を一つひとつがんばって登録することをお薦めする。

2. 各拠点について登録は1つ

たとえ君が、複数の言語のページ、あるいは同じ住所に複数の施設を持っていたとしても、グーグルローカルに登録するのは、絶対にそのうちの1つにすること。現時点では、グーグルは同じ住所に複数の企業があると、あまり上手に処理できない。

3. たくさんの営業拠点を持っている場合、KML形式による地理情報サイトマップの利用を考える

実際問題として、施設を一つひとつ登録するのが不可能なら（あるいは現在その処理を行っている最中であっても）、地理情報サイトマップであれば、一括アップロードより信用されているはずなので、そちらを使うことを検討してみよう。サイトマップの認証プロセスは、ドメイン名と関連付けられているため、そもそもアップロードプロセスよりも信用度が高いのだが、地理情報サイトマップもそれと同じ認証プロセスを採用しているからだ。