Google ウェブマスター向け公式ブログ

ウェブマスター向けガイドライン に違反していることが原因で、サイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がったりしていると思われる場合は、 サイトをガイドラインに沿うよう修正し、再審査リクエスト を送信していただくことで、該当のサイトが現在はウェブマスター向けガイドラインに準拠していることを Google に連絡することができます。

再審査リクエストを送信するには、まず、サイトを ウェブマスターツール に登録する必要があります ( 登録する方法の詳細は こちらのヘルプ記事 をご参照ください ) 。また、ウェブマスター向けガイドライン違反が見つかると、Google はメールにてその旨を該当のサイトのウェブマスターの方にご連絡することがあり、同時に、同じメッセージがそのウェブマスターの方のウェブマスターツールのアカウントにも表示されるようになります。ウェブマスターツールにサイトを登録された際には、是非一度 Google からメッセージが届いていないかご確認ください。

また、再審査リクエストを送信される際には、ご注意いただきたい点がいつくかあります。この注意点について、より良く知っていただこうと、動画を用意致しました。あとで参照しやすいように、内容をテキストでも掲載しますので、ぜひ一度ご覧いただければと思います。



＜＜ ビデオの日本語字幕 ＞＞

こんにちは、Google のサーチクオリティチームの Brian White と Rachel です。本日は、再審査リクエストについて、ご紹介します。

ご自身のサイトが Google ウェブマスター向けガイドラインに違反していることがわかった場合、まずはその違反について確認し、その違反箇所を修整するためにどのような措置を行ったのかについて、再審査リクエスト を通じて、Google にご連絡いただくことが重要です。

時折、「サイトがウェブマスター向けガイドラインに準拠するよう修正しました」としか入力されていないリクエストがありますが、これだけだと私たちがどこを確認したらよいのか良く分かりません。再審査リクエストは、コンピュータではなく、私たちが人手でチェックをしています。そのことを念頭において、できる限りの詳細をご連絡いただきますようお願い致します。

なぜサイトにペナルティが課されているのかわからない場合は、再審査リクエストを行う前に再度 Google ウェブマスター向けガイドライン を読み直し、違反行為について確認してみてください。ご自身がそのサイトを直接運用していないのであれば、直接運用している方（例えば、制作会社の方など）に聞いてみると良いでしょう。また Google の ウェブマスターヘルプフォーラム でも質問を受け付けていますので、是非ご利用ください。

時にサイトに技術的な問題があったことがペナルティの原因だとお考えになっている方からの再審査リクエストを受け取ることがあります。例えば、一時的にサーバーがダウンしていたり、一時的に適切なコンテンツを返せていなかった、といった問題がサイトには起こり得ますが、Google はそのような問題には柔軟に対応しています。このような場合は、ペナルティだと思い込んで、すぐに再審査リクエストを送信するのではなく、少し待ってみて、サイトが以前の状態に戻るかどうか確認してみることをおすすめ致します。

重複するコンテンツ をペナルティの原因と思われる方がいらっしゃいますが、大抵の場合、問題は別にあります。例えば、あなたのサイトとパートナーシップを結んでいるサイトがあるとしましょう。このような場合、このパートナーが協力活動をするにあたって、Google の「品質に関するガイドライン」に違反してしまい、結果として両サイトに悪影響が及ぶことがあります。編集権限のあるご自身のサイトは修整できても、編集権限を持たないサイトのコンテンツを修整するのは困難です。我々はこのような状況にできるだけ適切に対応できるよう努めています。このような場合は、再審査リクエストを行う際に、状況をできるだけ詳細にご連絡ください。例えば、不正なリンクが原因でペナルティを課せられた場合、それらを削除するためにした努力をまとめたページの URL を お知らせください。Google には、高性能な社内ツールがあり、また、先ほど申し上げたように、リクエストを個別にチェックするチームもありますので、我々を欺くような行為はお控えく ださい。もし再審査リクエストに、故意に、悪質もしくは我々を誤解させるような情報が含まれていた場合、Google はそのリクエストに対応しかねます。

また、再審査リクエストをスパムメールのように繰り返し何度も送信していただいても、たくさんのリクエストを提出したことにはなりません。簡潔かつ詳細なリクエストを 1 回でまとめて送信するようにしてください。リクエストは我々のチームメンバーが迅速に確認致します。新しい情報を追加したい場合のみ、再審査リクエストを 別途ご送信くださいますよう、お願い致します。

最後になりますが、再審査リクエストが処理された場合は、ペナルティが解除されてからその結果が反映されるまで時間を要する場合がありますのでご了承ください。

我々は常に Google 検索ユーザーの皆様に満足して頂くことを望んでいます。

そこで、再審査リクエストを送信される際には、


この 2 点を守っていただけますよう、お願い致します。

以上が Google の再審査リクエストに関わる者として、皆様にお伝えしたかったことです。

ご清聴ありがとうございました。


Posted by Rachel Searles and Brian White, Search Quality Team
Original Version: Tips on requesting reconsideration

ウェブマスター向けガイドライン に違反していることが原因で、サイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がったりしていると思われる場合は、 サイトをガイドラインに沿うよう修正し、再審査リクエスト を送信していただくことで、該当のサイトが現在はウェブマスター向けガイドラインに準拠していることを Google に連絡することができます。

再審査リクエストを送信するには、まず、サイトを ウェブマスターツール に登録する必要があります ( 登録する方法の詳細は こちらのヘルプ記事 をご参照ください ) 。また、ウェブマスター向けガイドライン違反が見つかると、Google はメールにてその旨を該当のサイトのウェブマスターの方にご連絡することがあり、同時に、同じメッセージがそのウェブマスターの方のウェブマスターツールのアカウントにも表示されるようになります。ウェブマスターツールにサイトを登録された際には、是非一度 Google からメッセージが届いていないかご確認ください。

また、再審査リクエストを送信される際には、ご注意いただきたい点がいつくかあります。この注意点について、より良く知っていただこうと、動画を用意致しました。あとで参照しやすいように、内容をテキストでも掲載しますので、ぜひ一度ご覧いただければと思います。



＜＜ ビデオの日本語字幕 ＞＞

こんにちは、Google のサーチクオリティチームの Brian White と Rachel です。本日は、再審査リクエストについて、ご紹介します。

ご自身のサイトが Google ウェブマスター向けガイドラインに違反していることがわかった場合、まずはその違反について確認し、その違反箇所を修整するためにどのような措置を行ったのかについて、再審査リクエスト を通じて、Google にご連絡いただくことが重要です。

時折、「サイトがウェブマスター向けガイドラインに準拠するよう修正しました」としか入力されていないリクエストがありますが、これだけだと私たちがどこを確認したらよいのか良く分かりません。再審査リクエストは、コンピュータではなく、私たちが人手でチェックをしています。そのことを念頭において、できる限りの詳細をご連絡いただきますようお願い致します。

なぜサイトにペナルティが課されているのかわからない場合は、再審査リクエストを行う前に再度 Google ウェブマスター向けガイドライン を読み直し、違反行為について確認してみてください。ご自身がそのサイトを直接運用していないのであれば、直接運用している方（例えば、制作会社の方など）に聞いてみると良いでしょう。また Google の ウェブマスターヘルプフォーラム でも質問を受け付けていますので、是非ご利用ください。

時にサイトに技術的な問題があったことがペナルティの原因だとお考えになっている方からの再審査リクエストを受け取ることがあります。例えば、一時的にサーバーがダウンしていたり、一時的に適切なコンテンツを返せていなかった、といった問題がサイトには起こり得ますが、Google はそのような問題には柔軟に対応しています。このような場合は、ペナルティだと思い込んで、すぐに再審査リクエストを送信するのではなく、少し待ってみて、サイトが以前の状態に戻るかどうか確認してみることをおすすめ致します。

重複するコンテンツ をペナルティの原因と思われる方がいらっしゃいますが、大抵の場合、問題は別にあります。例えば、あなたのサイトとパートナーシップを結んでいるサイトがあるとしましょう。このような場合、このパートナーが協力活動をするにあたって、Google の「品質に関するガイドライン」に違反してしまい、結果として両サイトに悪影響が及ぶことがあります。編集権限のあるご自身のサイトは修整できても、編集権限を持たないサイトのコンテンツを修整するのは困難です。我々はこのような状況にできるだけ適切に対応できるよう努めています。このような場合は、再審査リクエストを行う際に、状況をできるだけ詳細にご連絡ください。例えば、不正なリンクが原因でペナルティを課せられた場合、それらを削除するためにした努力をまとめたページの URL を お知らせください。Google には、高性能な社内ツールがあり、また、先ほど申し上げたように、リクエストを個別にチェックするチームもありますので、我々を欺くような行為はお控えく ださい。もし再審査リクエストに、故意に、悪質もしくは我々を誤解させるような情報が含まれていた場合、Google はそのリクエストに対応しかねます。

また、再審査リクエストをスパムメールのように繰り返し何度も送信していただいても、たくさんのリクエストを提出したことにはなりません。簡潔かつ詳細なリクエストを 1 回でまとめて送信するようにしてください。リクエストは我々のチームメンバーが迅速に確認致します。新しい情報を追加したい場合のみ、再審査リクエストを 別途ご送信くださいますよう、お願い致します。

最後になりますが、再審査リクエストが処理された場合は、ペナルティが解除されてからその結果が反映されるまで時間を要する場合がありますのでご了承ください。

我々は常に Google 検索ユーザーの皆様に満足して頂くことを望んでいます。

そこで、再審査リクエストを送信される際には、


この 2 点を守っていただけますよう、お願い致します。

以上が Google の再審査リクエストに関わる者として、皆様にお伝えしたかったことです。

ご清聴ありがとうございました。


Posted by Rachel Searles and Brian White, Search Quality Team
Original Version: Tips on requesting reconsideration

約 1 年前に、「 Google の検索は隠しテキストが嫌い 」という記事を Google 公式ブログ 日本版 に掲載しましたが、その記事でもお伝えしましたように、隠しテキストは、Google の ウェブマスター向けガイドライン に違反します。その理由の詳細は、ウェブマスター向けヘルプ センターの記事 にも載せておりますが、本日はその背景と、日本で多く見られる隠しテキストの具体的な一例を改めてご紹介します。

Google の検索は、隠しテキストに限らず、ユーザーが閲覧するウェブページと Googlebot が取得するウェブページの情報が大きく異なる状態を好みません。なぜなら、Google の検索では、Googlebot が取得したウェブページの情報をもとに検索結果をユーザーの方々に返しているため、取得したウェブページの情報と、実際にユーザーが見るページの内容に大きな差があると、適切な検索結果を返すことができなくなってしまうからです。

隠しテキストとなってしまう具体例。皆さまのサイトは大丈夫ですか？

例えば、次のような構造の、季節のギフトを販売するオンラインショップがあるとします。

HOME
┣┳ Products （商品一覧）
┃┣ ...........
┃┣ ...........
┃┣ ...........
┃
┣━ Shipping （送料）
┣━ Payment （お支払方法）
┣━ Inquiry （お問い合わせ）
┗━ About （会社概要）

このサイトでは、膨大な量のウェブページのデザインを一括で管理し、季節ごとにデザインを変えるなどの作業を容易にするため、HTML ファイルと CSS ファイルを分けて構築しています。例えば、このサイトのナビゲーションは、次のような HTML ファイル、CSS ファイルが組み合わさって構築されています。


HTML ファイル:

<div id="navi">
<ul>
<li id="home"><a href="./index.html">ホリデー ギフト 通販 ホーム</a></li>
<li id="products"><a href="./products.html">ホリデー ギフト 通販 商品一覧</a></li>
<li id="shipping"><a href="./shipping.html">ホリデー ギフト 通販 送料</a></li>
<li id="payment"><a href="./payment.html">ホリデー ギフト 通販 お支払い方法</li>
<li id="inquiry"><a href="./inquiry.html">ホリデー ギフト 通販 お問い合わせ</li>
</ul>
</div>

CSS ファイル:

#navi li {
text-indent: -9999px;
}

#navi li#home {
background: url(./img/navi/home.gif) no-repeat;
}
#navi li#products {
background: url(./img/navi/products.gif) no-repeat;
}

CSS ファイル内には、text-indent プロパティを -9999 px と指定している箇所 ( 赤字 ) が見られます。これは、通常のブラウザでの閲覧時に、ナビゲーションに並ぶサイト内へのリンクを、テキストリンクの代わりに画像を使って表示させたい時に用いられることのある方法です。これにより、テキストリンクはページ外に移動する形で隠され、代わりに background プロパティで指定された画像が表示されます。
このナビゲーション部分を通常のウェブブラウザで閲覧すると、次のように見えます。




ナビゲーションが画像で綺麗に表示され、一見、何の問題もありません。

次に、このナビゲーション部分をテキストブラウザで見てみます。
多くのテキストブラウザでは、CSS による装飾が外され、テキストのみの形式でページを閲覧できます。
そして、テキストブラウザでの閲覧情報は、Googlebot がこのページを解釈するときに取得する情報とほぼ同等のものとなっています。




おや？　「ホリデー」「ギフト」「通販」など、先ほど通常のブラウザで閲覧した時には見えなかった単語が表示されていますね。じつは、このサイトでは CSS で隠されるテキストが通常のブラウザでは表示されないことを利用して、 関連するキーワードでの検索にマッチさせるためのキーワードを隠していたのでした。( 上記 HTML ファイルをチェックしてみてください。 )

通常のウェブブラウザで閲覧できる内容はユーザーに提示されている内容、テキストブラウザで閲覧できる内容は Googlebot に対して提示されている内容であるということから、このサイトについて考えてみましょう。
ウェブブラウザとテキストブラウザとでの閲覧時の内容を比較した場合、ナビゲーション部分に注目すると、Googlebot には ユーザーより不自然なほどに多くの文字情報が返されていることがわかります。このようなテキストは、「 隠しテキストと隠しリンク 」 と見なされ、このサイトの情報は、Google が適切な検索結果を提供するうえで信用できないと認識され、サイトが Google の検索結果から一時的に削除されることがあります。

ポイントは、そのテキストがユーザー向けであることです

ただ、画像の内容と CSS や alt 属性による代替テキストが完全に一致していなければならないわけではありません。前回の記事 に も書きましたように、代替テキストが、ユーザーに読ませることを想定し、ユーザーにとって有益なものであると考えられるものであれば ( 例えばテキストブラウザや、テキスト読み上げソフトをご利用のユーザーのために書かれたものである場合 ) 、問題はありません。しかし、ユーザーのためではなく、検索エンジンのためにそのテキストを書いてしまっている場合は、サイトが検索結果から削除されてしまうことがあります。心配な場合は、上記のように、Lynx や w3m な どのテキストブラウザを使ってサイトを閲覧し、通常のブラウザでの閲覧時と比較し、ユーザーのためとは言えない隠しテキストや隠しリンクがないか確認してみてください。判断に迷った際は、「たとえ検索エンジンが存在しなくてもそのテキストを書いたかどうか」と考えてみてください。もし検索エンジンが存在しなくても、そのテキストがユーザーの利便性のために必要なものであると思われる場合、おそらくそれはガイドライン違反ではありません。

ご参考になりましたでしょうか。 ご自身のサイトに隠しテキストがあることが原因で、サイトが Google のインデックスから除外されている場合は、サイトを修正し、再審査リクエスト を送信してください。

ご意見、ご質問は、ウェブマスターヘルプフォーラム までお寄せください。


Posted by サーチクオリティチーム

ウェブマスターツールの キーワード 機能とその UI （ユーザーインターフェース）が新しくなりました。Google がサイト内にキーワードを見つけた頻度や、そのキーワードを検出したページの URL といった詳細情報を確認していただけます。

「重要度」の欄には、あるキーワードの頻出度と、最も検出回数の多いキーワードの頻出度とを比較した相対的な結果が表示されます。


キーワードをクリックしてさらに詳細を表示させると、該当するキーワードを含むページの URL が10 個まで表示されます。


この機能は、ご自身のサイトを新たに再構築する場合や、サイト内のどの URL が乗っ取られたか を特定する場合に役立ちます。例えば、ご自身のサイトにまったく関係のないキーワード ( 例: 「バイアグラ」や「カジノ」 ) の検索結果にご自身のサイトが表示されていることが分かった場合には、この機能を使ってそのようなキーワードを見つけ出し、さらにそのキーワードを含んで いるページを特定することができます。 この機能を使えば、乗っ取られたコンテンツを素早く削除することができるようになるのです。

この情報は毎日更新される予定ですので、定期的に確認し、ご自身のサイトの管理にお役立てください。

ご意見、ご感想は、是非 ウェブマスターヘルプフォーラム までお寄せください。


Posted by Kurt Dresner, Tanya Gupta, and Sagar Kamdar, Webmaster Tools team
Original version: Post-Halloween Treat: New Keywords User Interface!

Google の検索結果では、皆様のウェブページの有益性がユーザーに分かりやすくなるように 「スニペット」と呼ばれるページの説明文をタイトルの下に表示 しています｡スニペットは様々な技術を駆使して生成されており、ユーザーが検索結果からサイトへ飛んだとき、どのような情報が閲覧できるのかを示すものです。本日は、このスニペットを拡張した「Rich snippets ( リッチ スニペット )」という新機能についてご紹介します。今年の 5 月に米国で初めて提供されたもので、他国よりも早く日本は提供 2 ヵ国目となりました。リッチ スニペットは、Google のアルゴリズムを適用して、ウェブページに埋め込んだ構造化データを強調表示する、新しいタイプのスニペットです。

この画像のように、 リッチ スニペットではレビューに関するデータが追加されています。


製品やサービスのレビューや評価情報を表示することで該当ページの有益性が分かりやすくなり、より効果的にユーザーをウェブサイトへ誘導できることが我々の実験結果で出ています。

そこで、今回は、より多くのサイトにこの新機能をご活用いただけるよう、リッチ スニペットの表示に必要な 2 ステップをご紹介します。まず、ページの変更を行ったあとで、次に Google に参加希望のご連絡をいただく必要があります。以下に詳細を説明します。（なお、この機能は、通常のスニペットと同様 Google 独自のアルゴリズムとポリシーに基づいてユーザーにとって有益だと判断された場合のみ表示されます。）


＜ リッチ スニペットの表示 ＞

1. microformats または RDFa を利用して構造化データをページに付加してください。ほとんどの場合、ウェブページ上の既存データをいくつかの追加タグで囲むだけの簡単な作業で完了します。
   
   
   まず、一例として、kakaku.com からマークアップデータ追加前の HTML データを示します。
   
   
   次は、microformats のマークアップを追加した HTML データです。
   
   
   また、2009 年 11 月現在、kakaku.com が実際に使っている手法とは異なりますが、以下のような RDFa のマークアップも使用可能です。いずれの形式にも対応しています。
   
   
   このように microformats もしくは RDFa でアノテーションをすることで、Google の検索結果にリッチ スニペットが表示されるだけでなく、同じフォーマットをサポートする他のサービスやツールでも利用可能になります。さらに、構造化データがウェブ上で普及するにつれ、それに対応する新しいアプリケーションが多数登場することも期待できます。
   

   
   
2. そして、リッチ スニペットへの参加をご希望される際は、専用フォーム に必要事項を記入しご連絡ください。Google では、このフォームに記入していただいたすべてのユーザーに個別に返信することはできません。特定のサイトのデータをどのように使用するかについての保証はできませんが、データについて詳しくお伺いする目的でご連絡させていただくことがあります。また、ページに変更を加えても必ずしもリッチ スニペットが表示されるとは限りません。通常のスニペットと同様 Google 独自のアルゴリズムとポリシーに基づいてユーザーにとって有益だと判断された場合のみ表示されます。

リッチ スニペットの活用や構造化データのアノテーションに関する詳細は ヘルプ記事 にてご確認ください。


＜ FAQ ＞

Q) 作成したページをマークアップすれば、必ずリッチスニペットが表示されるのですか？
A) いいえ。ページに microformats や RDFa でアノテーションしてもリッチ スニペットが表示されるとは限りません。まず、既に定義されている全ての microformats や RDFa に対してリッチスニペットが対応しているわけではありません。例えば、現在はレビューについてのみリッチ スニペットが表示されます。リッチ スニペットが ユーザーにとって有益と判断された場合には、他のカテゴリの microformats や RDFa に順次対応していきたいと考えています。また、リッチ スニペットが対応しているカテゴリの microformats や RDFa でアノテーションしたとしても、通常のスニペットと同様 Google 独自のアルゴリズムとポリシーに基づいてユーザーにとって有益だと判断された場合のみ表示されます。

なお、microformats もしくは RDFa でアノテーションした場合、他のウェブサイトやツール ( ブラウザや携帯電話など ) にそのデータを利用される可能性があることをご承知ください。リッチスニペットにご興味がある場合には、こちらの フォーム をご利用ください。

Q) レビュー以外のカテゴリに対応する予定はありますか？
A) ユーザーにとって有益だと思われるカテゴリの microformats や RDFa を選定しながら対応していく予定です。

Q) 今後の予定は？
A) レビュー以外の新しいカテゴリについて検証した上で、順次展開していく予定です。

Q) ページ内のデータ量が多すぎて、すべてをマークアップしきれません。
A) ページ内の全ての構造化データをアノテーションする必要はありません。リッチ スニペットで表示できる情報には限りがあります。例えば、ある製品のページに 497 件のレビューがある場合、497 件すべてをアノテーションしても、そのページのリッチ スニペットには全ての情報を表示することはできません。このような場合には review-aggregate という全レビューのまとめ（レビュー数、平均／最低／最高評価など）のみアノテーションするだけでかまいません。

Q) なぜ複数のエンコーディング方式に対応させたのですか？
A) 構造化データに関しては、多くのエンコーディングの議論がされてきました。例えば、Google 社内でも、microformats エンコーディングを支持する者、各種 RDFa エンコーディングを支持する者、そして Google 独自のエンコーディングを支持する者がいます。しかしこのリッチ スニペット・プロジェクトを進めるうちに、ウェブ上の構造化データは、複数のエンコーディ ング方式に対応可能であり、対応するべきでもあるいう考えに至りました。microformats と RDFa の両方をサポートしている点がその現われです。

ただし、用語を共通化することは重要だと考えています。たとえば、オブジェクトの型、オブジェクトのプロパティ、プロパティの型が共通であれば、様々なア プリケーションでも構造化データを識別できるようになります。 Google では、この用語の問題をどう処理するか議論を重ねた上、ある種の「投資」が必要との結論に至りました。そこで、Google は他の団体等と協力して、Google の様々なサービスや他のウェブサイトが共通して使用できる用語を定義していく予定です。まずは短いリストから始め、順次数を増やしていきたいと考えていま す。

可能な限り、すでに普及した用語を流用していきます。すでに定義されていた vCard や hReview のほか、様々なコミュニティで定義された多種多様なフォーマットに対応していきます。Google カスタム検索を使用しているサイトでは、独自の型を定義できるようになり、それを Google 側がインデックス処理し、カスタム検索の結果ページにリッチ スニペットを使用して（英語）ユーザーに提示できるようになります。最後に、Google では、構造化データを検討するコミュニティからの新しいアイデアに基づき、この分野が発展することを奨励、期待しています。


Written by 鈴木宏輔 / プロダクトマネージャー, 渡邉 悠 / ソフトウェアエンジニア

最後に、サイトの構造上の問題について、取り上げます。

サイトのデザイン・構造上の問題

これまでの説明で、第三者からの悪意ある攻撃によってサイトやアクセス数に悪影響が出る場合があることがお分かりいただけたと思います。次はサイトのデザイ ン・構造上の問題についてご説明します。具体的には、皆さんのサイトが Google の検索結果に表示されるためには、サイトが適切に Google にクロールされ、インデックスに登録されなければなりません。そのためには、以下の事柄をお試しください。

• まずはサイトの robots.txt のステータスコードが正しいかどうか、Google に エラーを返していないかどうか を確認します。
• サイトを移転する場合のベストプラクティス（英語）を参考に、ウェブマスターツールに新たに加わった「アドレス変更ツール」を活用します。
• robots.txt ファイルの設定を見直し、誤ってブロックされているページがないかどうかを確認します。特に書き換えたページや動的ページは注意が必要です。
• 最後に、rel="canonical" 属性をうまく活用 し、ドメイン上にある重複コンテンツがインデックスされるのを防ぎます。下の資料の例にもあるとおり、この属性を利用することで、複数の重複した内容のページの中から優先的に表示させたい特定のページを、Google に伝えることができます。

まとめ

結論としては、Google の検索結果は変動するものだという事実を踏まえたうえで、ご自身のサイトが検索結果に表示されなかったり、表示が不自然に変動したりする場合は、悪意ある攻撃やデザイン・構造上の問題が原因になっている場合があり、さらにそうした問題は防げるのだということを覚えておいていただければと思います。まず手始めに行っていただきたいのは次の 3 つです。

• 第三者によるサイトの改ざんに注意すること。
• ウェブマスター ツール内の HTML のヒント のページをよく読み、ご自身のサイトが正しくクロールされ、インデックスに登録されているかどうかを確認すること。
• そして robots.txt ファイルのテスト を行い、誤って Googlebot をブロックしていないかどうかを確認することです。また、その際に Google が robots.txt ファイルにアクセスできないエラー についても、再度ご確認いただければと思います。

詳しくは、こちらの スライド もご参照ください。


ご意見、ご質問は、ウェブマスターヘルプフォーラム までお寄せください。


Written by Luisella Mazza, Search Quality Senior Analyst
Original Version: Traffic drops and site architecture issues

次に、プレゼンテーション資料 を使って、アクセスが減少した際に注意すべき点をご説明します。

まず、第三者によって 隠しテキストや隠しリンク がサイトに埋めこまれたことにより、サイトが Google のウェブマスターガイドラインに違反してしまい、サイトが Google の検索結果から除外されている場合があります。ご自身のサイトにこうした問題が起こっているかどうかは、Google のキャッシュやウェブマスターツー ルを使って確認することができますので、ご安心ください。



また、サイトが第三者によって改ざんされたことで、ユーザーが別のサイトにリダイレクトされる場合も、アクセス数が減少する可能性があります。原因としては、例えば、改ざんされたサーバーを経由した場合、検索エンジンからの参照が引き金となって、別のページへリダイレクトされるような仕掛けになっている場合などがあります。



このような不正行為を Google が検出した場合、通常は問題が検出されたことを伝えるメッセージがウェブマスターツールのメッセージセンターに表示されます。



改ざんによって Google のクローラだけがリダイレクトされるケースもあります。この場合はユーザーには影響がないため、サイトのアクセス数が急激に減少することはありませんが、 この状態が長期にわたると Google にインデックスされるページが減る可能性があります。

（後段に続く）


Written by Luisella Mazza, Search Quality Senior Analyst
Original Version: Traffic drops and site architecture issues

「アクセス数の減少」と「サイトの構造上の問題」に関する質問を数多くいただくため、先日（2009年 5 月 18, 19 日）ロンドンで開催された SMX London（サーチ・マーケティング・エキスポ・ロンドン）（英語）にて、これらの問題を詳しく解説したプレゼンテーションを行いました。今日は、その際に説明した内容から、重要な点を抜き出して紹介します。まずはアクセス数が減少する原因についてお話しし、続いて、サイトのデザイン・構造上の問題についてご説明しましょう。

アクセス数が減少する原因を理解する

ご存じの通り、Google の検索結果は常に変動しています。ウェブは絶えず進化し続け、それに合わせて Google のインデックスも更新されるからです。 また、ユーザーの関心や検索キーワードを把握する Google の機能が改善した場合も、Google のアルゴリズムによるページの選択や掲載順位は、たいてい変化します。しかし、こうした理由による検索結果の変動が混乱を招き、時に誤解を引き起こしているのかもしれません。そこで、アクセス数減少の原因に関する俗説をいくつか取り上げ、その間違いを指摘していきたいと思います。


ウェブマスターの皆様に多く見られる誤解については、以上となります。

（中段に続く）


Written by Luisella Mazza, Search Quality Senior Analyst
Original Version: Traffic drops and site architecture issues

Google Japan ブログ にて、情報に素早く辿り着くための新しい機能 を発表しましたので、併せて、先月英語版ウェブマスターセントラルブログで紹介した記事 を抄訳し、ご紹介します。

新しい機能は、いずれも検索結果に新しいリンクを表示して、膨大な情報が詰まったページ内の該当箇所にひとっ飛びできるようにします。ユーザーの探している 情報がページ内の特定の場所にまとめて記載されている場合、ユーザーがその場所に直接ジャンプすることができるので、ページ全体をスクロールしながら探す 手間が省けます。

また、新しいリンク機能は、ページの構成に基づいてアルゴリズムで自動生成されるため、どんなサイトでも表示される可能性があります。もちろん、料金を支払うことで特定のサイトへこのリンク機能が表示されるように設定することはできません。

では、この便利な新機能をご自分のサイトへ反映させたい場合はどうしたらいいでしょうか？　ここで、いくつかのヒントをご紹介します。

1. まず、ページが複数のトピックから構成される場合には、各トピックを明確に異なるセクションに分けてください
2. 次に、各セクションにわかりやすい名称（例えば「第 2 章」などではない名称）のアンカーを埋め込んでください
3. そして、そのページ内に、各アンカーにリンクされている目次を作成してください

この新しいリンク機能が表示されるかどうかは、キーワードに応じて変わってきますので、必ずしも毎回リンク機能が表示されるわけではありません。ある検索キーワードに対してリンクを表示することが明らかに役立つ場合にのみ表れます。

ちょっとした工夫をすることで、進化を続ける Google のお役立ち機能との相性もぐんとよくなります。より利便性の高いウェブサイトの運営に、Google のこの新しいリンク機能が役立てば幸いです。

ご意見、ご質問は、ウェブマスターヘルプフォーラム までお寄せください。


Localized and posted by 鈴木宏輔, プロダクトマネージャー
Originally Posted by Raj Krishnan, Snippets Team
Original Version: Using named anchors to identify sections on your pages

先日、モバイルサイトを正しく Google に認識させる方法についてご紹介しました が、本日は同じサービスをデスクトップ向けと携帯電話向けの両方に提供されているウェブマスターの方向けの情報をお届けします。

モバイル版とデスクトップ版の両方のサイトを運営されているウェブマスターの方から多く寄せられるご意見の中に、デスクトップからの検索に対してモバイル版のページが出現してしまう、あるいは逆に、モバイル検索でデスクトップ版のページが出てきてしまうという問題があります。このような場合は、リダイレクトなどを利用することで携帯ユーザーを携帯サイトに誘導するのが有効です。

リダイレクトを利用する

デスクトップ版 URL に携帯ユーザーからのアクセスがあった場合、対応するモバイル版 URL にリダイレクトするという手法です。これによって Google は両者の関係に気づき、デスクトップからの検索に対してはデスクトップ版の URL を、モバイル検索にはモバイル版の URL を出すことが可能となります。

この場合、対応する URL でアクセスできるコンテンツはできるだけ一致するようにしてください。たとえばショッピングサイトを運営していて、個別商品のデスクトップ版 URL に携帯端末からアクセスがあったとき、モバイル版の同じ商品のページではなく、モバイル版サイトのトップページにリダイレクトする、といったことにはならないように気をつけてください。まれに、モバイル版サイトの検索ランキングを上げるためにこのようなリダイレクトを行っているサイトも見られるようですが、そのようなことはしないでください。ユーザーにとっての利便性も下がります。逆に、モバイル版の URL に通常のデスクトップブラウザや Googlebot からアクセスがあった場合は、デスクトップ版 URL にリダイレクトする必要は特にありません。例えば Google と YouTube はリダイレクトさせずに、モバイル版ページの下部に PC 版 URL へのリンクを張っています。モバイル版サイトの機能がデスクトップ版に比べて少ない場合、ユーザーがデスクトップ版へ簡単に移動できるので便利です。

同じ URL で内容をユーザーエージェントによって切り替える

様々な事情や歴史的な経緯によって、同じ URL でフォーマットやコンテンツをユーザーエージェントによって切り替える方式を実施しているサイトがあります。つまり、実際にアクセスする URL は同じですが、ユーザーエージェントの情報にもとづいてデスクトップから閲覧した場合と携帯電話から閲覧した場合で表示するフォーマットを変えるという手法です。この場合、どちらの検索結果でも同じ URL が表示され、デスクトップからアクセスすればデスクトップ版のコンテンツが閲覧でき、携帯電話からはモバイル版のコンテンツが閲覧できます。

ただし、クローラーに返すコンテンツの設定を誤ると、場合によってはサイトの偽装、いわゆる「クローキング」と見なされることがあるのでご注意ください。

クローキングとは、Googlebot に対して通常のユーザーと異なるコンテンツを見せることで、検索結果のランク付けを高めようとする行為のことです。実際にはユーザーが閲覧するコンテンツにはないキーワードで検索結果に表示されるなどの不便を生じるため、クローキングに対しては、厳しい対処が取られます。

では、同じ URL でモバイル版とデスクトップ版を提供する場合、「ユーザーが閲覧するコンテンツ」とはどちらのことなのでしょうか。前回の記事でも説明したように Google ではウェブ検索用の Googlebot とモバイル検索用の Googlebot-Mobile というクローラーを使っています。ですから Googlebot にはデスクトップのウェブブラウザと同じコンテンツを、Googlebot-Mobile には携帯電話のウェブブラウザと同じコンテンツを返してください。もちろんこの場合、Googlebot と Googlebot-Mobile で受け取るコンテンツが違っていても問題ありません。たとえば、サイト管理者の意図と反してクローキングと認識される可能性のあるパターンとして、デスクトップからのアクセスは「携帯電話からアクセスしてください」といった説明をするページを返しているのに、Googlebot と Googlebot-Mobile を区別せず扱っているために Googlebot からはモバイル版のコンテンツが見えてしまっている、というケースがあります。この場合、実際にデスクトップユーザーが閲覧するコンテンツと Googlebot が受け取るコンテンツが異なるため、クローキングと判断されてしまう可能性があります。



まとめ

Google も検索結果の改善に日々取り組み、問題の解決に尽力していますが、デスクトップ版とモバイル版の対応関係などについては、ウェブマスターの皆様にもご協力いただければ幸いです。できるだけたくさんのモバイルコンテンツが Google のインデックスに登録され、ひいては、検索ユーザーの皆様により良い検索結果を提供することにつながればと思っています。モバイル検索のユーザーエクスペリエンス向上のため、ぜひご協力をお願いします。


Posted by 向井 淳, ソフトウェアエンジニア, モバイル検索チーム

皆様もご存知のように日本は携帯電話普及率が非常に高く、たくさんの人が携帯電話を日常的に利用しています。その用途は通話やメールに留まらず、ウェブサイトの閲覧も携帯から行う人が増えており、Google モバイル検索 における検索件数は、日本国内からの全検索件数の少なくない割合を占めています。ただ、モバイルサイトの運営は、それほど容易なことではありません。モバイルサイトには通常のウェブサイト（デスクトップ版のサイト）とは異なるフォーマットが使われ、運営方法やノウハウもデスクトップ版サイトとは大きく異なるため、その管理は、ウェブマスターの皆様にとって新たなチャレンジとなっているのではないでしょうか。モバイル検索のエンジニアとして様々なサイトを調査していると、携帯電話からの閲覧を想定して設計されているものの、それ以外のソフトウェアがアクセスすることは念頭に置かれていなかったため、Google のインデックスに正しく登録されていないモバイルサイトが多数あるのを見かけます。Google の検索を通じてユーザーがあなたのサイトと出会うには、まず、あなたのサイトが Google に適切にインデックスされている必要があります。

そこで今回は、あなたのモバイルサイトを正しく Google のインデックスに登録するためのヒントをご紹介したいと思います。

そもそもモバイル検索結果にウェブページが出てこない場合

モバイル検索 で "site:" 演算子 を使って検索しても、あなたのサイトのウェブページが検索結果に出てこない場合は、サイトに以下の 2 つのいずれか、もしくは両方の問題があることが考えられます。

Googlebot がサイトを発見できていない

Google は Googlebot と呼ばれるプログラムを使ってウェブページ情報を取得し、これをもとに検索インデックスを作っています。サイトが作られて間もないと、Googlebot がまだそのサイトの存在に気付いておらず、ウェブページ情報が取得されていない可能性があります。そのような場合は、モバイルサイトマップ を作成し、Google に送信することで、その存在を教えてください。モバイルサイトマップは通常のサイトマップ同様、ウェブマスターツールを使って送信 することができます。

Googlebot がサイトにアクセスできない

モバイルサイトのなかには携帯電話以外のアクセスを禁止しているため、Googlebot もアクセスすることができず、検索できなくなっていることがあります。モバイルサイトの収集に使われる Googlebot は、ユーザーエージェント情報に "Googlebot-Mobile" という文字列を含んでいますので、"Googlebot-Mobile" を含むユーザーエージェントからのアクセスも許可するようにしてください。なお、Google はユーザーエージェント情報を予告なく変更することがありますので 、現在の Googlebot-Mobile が使っているユーザーエージェントと完全に一致するかどうかで比較することは推奨されません。ユーザーエージェントが "Googlebot-Mobile" という部分文字列にマッチするかどうかのみで判断してください。

モバイルサイトの中には特定の IP アドレス帯域からのアクセスのみを許可することで確実に携帯電話以外のアクセスを禁止する手法が用いられることがあります。このように IP アドレス帯域を限定すると、Google も含めた各種の検索エンジンからのアクセスも禁止されてしまいますし、検索エンジンや携帯電話以外の携帯機器からのアクセスができないと最終的にユーザーの数が増えにくくなると考えられます。しかしもしどうしても IP アドレス帯域を使った制限を外せないというサイトを運営されている方のために、Googlebot-Mobile で使用する IP アドレス帯域を公開 していますので、この IP アドレス帯域からのアクセスも許可していただきますよう、お願い致します。

モバイルサイトが、モバイルサイトとして認識されていない場合

Googlebot-Mobile はウェブページ情報を取得してインデックスすると同時に、取得したページが実際に携帯電話で閲覧可能かどうかをチェックしています。Googlebot が携帯電話で閲覧できないと判断したページはモバイルページであるとみなされず、モバイルサイトのインデックスに登録されません（ PC サイトのインデックスに登録される可能性はあります）。この判定は様々な情報に基づき行われますが、DTD（Doc Type Definition, 文書型定義）宣言もそのひとつです。適切に XHTML Mobile や Compact HTML など携帯端末向けのフォーマットの DTD を宣言していれば問題なくモバイルページとして登録されるでしょう。詳細は、携帯サイトウェブマスター向けのガイドライン をご参照ください。

また、先日 ウェブマスターヘルプフォーラム に、モバイルサイト というカテゴリが追加されました。モバイルサイトの検索結果に関するご意見、ご質問は、是非こちらにご投稿ください。


Posted by 向井 淳, ソフトウェアエンジニア, モバイル検索チーム

ウェブサイトを立ち上げると、自分のサイトが検索エンジンにどのようにインデックスされ、ランク付けされているのかが気になる方も多いでしょう。ランク付けをあげるために、たとえば、ウェブページやメタタグに、検索に利用されるであろうキーワードを詰め込むとか、無数の検索エンジンやディレクトリ型検索エンジンへの登録を試みるなど、試されたことありませんか？

本日は、去年の秋に開催された Live chat のイベント（英語） で、サーチクオリティチームの John Mueller が紹介した、「Google のインデックスやランク付けに関する、10 の誤解 」というプレゼンテーションを元に、これらの誤解について、解説したいと思います。

誤解 1: サイト内に 重複するコンテンツ があるとペナルティを受ける

あなた自身のサイト内の重複するコンテンツについて、過度に気にする必要はありません。Google は重複するコンテンツを無視することに長けています。重複するコンテンツのうち、検索結果に優先的に表示させたいページがある場合は、canonical 指定を使う など、Google がそのページに気付きやすいようにしてください。



誤解 2: HTML と XHTML を混ぜて使用するとウェブマスターツールの認証に失敗する

ウェブマスターツールの確認用のメタタグ は、ウェブページのエンコーディングやドキュメントタイプに関係なく、ご利用いただけます（※確認用のメタタグは、ウェブマスターツールのアカウントと、サイトに固有のものであることにご注意ください）。サイトの確認は、ネットワークの不具合などで失敗することもあります。うまくいかない場合は、Googlebot がサイトの URL にアクセスできるような設定になっていることを確かめ、もう一度サイトの確認を試みてください。

誤解 3: 検索結果におけるサイトの評価を高めるためには、何千もの検索エンジンや登録サイトに登録されることが重要だ

そんなことはありません。そんなに多くの検索エンジンや登録サイトを日常的に利用している方は少ないと思います。あなたが多くの検索エンジンや登録サイトを探している間に、多くの検索エンジンが、自動的にあなたのサイトを見つけ出し、インデックスに登録してしまうことでしょう。こうしたサイトに登録するだけでは、あなたのサイトに大きな変化をもたらすことは期待出来ませんのでご注意ください。

誤解 4: AdWords や AdSense, Analytics を利用すると、サイトの評価が上がる、もしくは下がる

そんなことはありません。これらはすべて、ウェブマスターの皆様に是非ご活用いただきたい Google のサービスですが、このいずれか、もしくはすべてを利用されているからという理由で、検索結果上のサイトの評価が上がることもなければ、下がることもありません。



Google Analytics はサイトのパフォーマンスを高めるのに役立つツールですので、是非ご利用ください。

誤解 5: 重要なキーワードは、重要なページの重要な場所に出来る限りたくさん詰め込んで、そのページが他のページよりも価値があることに、検索エンジンが気付くようにしたほうがいい

キーワードの乱用 は Google のウェブマスター向けガイドライン違反です。いわゆる「理想的なキーワード密度」は存在しませんので、ユーザーのことを第一に考え、自然なコンテンツを作ることを心掛けましょう。キーワードを頻出させて、ユーザーが文章を読む際の邪魔にならぬよう、気をつけましょう。

誤解 6: XML サイトマップ を使うと、サイトのランク付けが下がる

そんなことはありません。XML サイトマップがあると、検索エンジンは、あなたのサイトについて、よりよく知ることができます。また、XML サイトマップを作ることで、ウェブマスターの皆様も、ご自身のサイトについて、より理解が深まることもあるでしょう。多くの CMS が XML サイトマップを自動的に生成していますし、XML サイトマップの自動生成ツールも、多数オンラインで提供されています。もし、サイトマップを未送信でしたら、是非一度作成し、Google に送信してみてください。また、XML サイトマップを作られたあとは、更新も怠らないようにしましょう。

XML サイトマップについての詳細は、sitemaps.org をご参照ください。

誤解 7: PageRank は、もはや意味を持たない / PageRank　がすべてだ！

PageRank は、そのウェブページが持っているリンクの質と量を測る指標です。Google がランク付けに PageRank を用いているのは事実ですが、PageRank は、Google がウェブページのランク付けを行ううえで用いる 200 以上の技術のひとつに過ぎません。Google ツールバーに表示される PageRank の更新頻度は年に数回程度です。

誤解 8: サイトの URL は定期的に Google に登録 しなおす必要がある

そんなことはありません。サイトを何度送信しても、クロールやインデックス、ランク付けに変化は起こりません。サイトの URL について一度でも Google が把握することができれば、インデックスへの登録などについては順次対応します。



誤解 9: 一度ランク付けがあがったら、もうサイトに手をつけないほうがいい

放っておくことで価値が増すものもあると思いますが、ウェブサイトはそうではありません。あなたのサイトが気に入ったユーザーは、きっとまた戻ってきますので、繰り返しサイトを訪れてくれるユーザーに、新しいコンテンツを提供できるようにしましょう。あなたが現在のランク付けに満足してサイトの更新を止めた場合、更新が止まっている間に別のサイトが進化し、より良いコンテンツを提供し始め、ユーザーの興味がそちらに移ってしまうことがあるかもしれません。ランク付けは常に変化していることをお忘れなく。

誤解 10: 正しい (X)HTML の記述は、サイトのランク付けを上げる

実は、インターネット上のほとんどのサイトの記述に誤りがあると言われています。完全に正しい記述は全体の約 5% 以下とさえ言われています（英語）。ブラウザはこの状況に対応しており、検索エンジンも同様です。致命的に壊れた記述は非常に稀です。ただ、正しく記述されたサイトは、より多くのブラウザで適切に表示されますので、できるだけ正しく書くことをおすすめします。また、正しく記述すると、問題が見付かりやすくなり、修正も容易になります。


これらの誤った情報に惑わされないようにするためには、まずは、インターネットにある情報を検索して、調べてみることです。多くの誤解はすでに誤解であることが証明されています。これらの情報を広めているサイトや、そのサイトのオーナーについてもよく調べてみると良いでしょう。また、多くの場合、常識を働かせてみると、見えてくることがあります。あまりに出来すぎた話であれば、信じないほうが良いでしょう。



併せて、次の資料も是非ご参照ください。

ウェブマスター向け 公式ブログ: 重要な情報はここに掲載しますので、RSS やメール配信機能を利用し、最新の情報を常に得られるようにしておくことをおすすめします。

ウェブマスターヘルプフォーラム: 調べてもわからなかったことは、フォーラムにてご質問ください。経験豊富なウェブマスターの方々と共に Google 社員が質問にお答えします。ただ、同じような質問がすでにされている場合がありますので、質問を投稿する前に、フォーラムの上部にある検索ボックスから検索してみてください。また、質問や回答を行う際には、周囲への配慮をお忘れなく。お互いの知識をここで共有しましょう。

ウェブマスターツール やウェブマスター向けヘルプセンター も是非お役立てください。


Written by John Mueller, Webmaster Trends Analyst, Google Zürich
Original Version: Myths and Misconceptions --"I read this online so it must be true!" (Google Document)

本日は、「一行表示のサイトリンク」についてご紹介します。

すでによくご存知の方がいらっしゃるかもしれませんが、改めてご説明しますと、サイトリンク とは、Google の検索結果の一番目のサイトの下部に表示される、サイト内の特定のページへのリンクのことです。ユーザーはサイトリンクからサイト内の重要なコンテンツに 直接飛ぶことができますので、複雑なつくりのサイトを閲覧する際などに便利です。また、サイトリンクはサイト内の人気のあるコンテンツなどを目立たせるの で、サイトの概要を把握するのにも役立ちます。ウェブマスターにとっては、サイトリンクを通じて、ユーザーにサイトの内容を詳しく知ってもらえるという利点もあります。たとえば [ JAXA ] で検索すると、人工衛星・探索機 や施設見学・ツアー、宇宙ステーション・きぼう広報 ... などのサイトリンクが表示されます。


これまでサイトリンクは、検索結果の一番目のサイトにのみ、つまり一回の検索に対して最大ひとつのサイトにしか表示されませんでしたが、このたび、サイトリ ンクの機能が拡張され、これまでサイトリンクが表示されなかったサイトや、2 番目以降のサイトに対してもサイトリンクの表示が可能となりました。つまり、一回の検索において、複数のサイトにサイトリンクが表示されるようになったの です。表示方法も、検索結果の一番目のサイトの URL の下に縦 2 段で表示されていた従来の形に加え、最大 4 つのサイトリンクが URL のすぐ上に横並びで表示されるようになりました。下記画像の表示例をご覧ください。3 つのサイトにそれぞれのサイトリンクが一行で表示されています。


一行表示のサイトリンクは、縦 2 段表示のサイトリンクと比べて、ひとつのサイトに対して表示されるリンクの数は少ないものの、同様の利点があります。まず、ユーザーはサイトリンクとして表示されたいくつかのサブページを見ることで、サイトの概要を把握することができます。また、いくつかのサイトにサイトリンクが表示されている場合は、サ イトリンクを比較することで、それぞれのサイトの内容の違いも知ることができます。一行表示のサイトリンクも、従来の縦 2 段表示のサイトリンク同様、どのリンクがどのような条件下で表示されるかは、Google のアルゴリズムでユーザーの役に立つと判断された場合にのみ、自動生成されています。

ウェブマスターの皆様にとって今回の新機能の重要なポ イントは、皆様のサイトでも、これまで表示されていなかった検索キーワードに対してサイトリンクが表示され得るということです。このようにサイトリンクの 表示が増えることで、ユーザーの利便性が上がると同時に、皆様のサイトの認知度の向上やユーザーの増加が期待できるのです。しかし、もしどうしても、表示して欲しくないサイトリンクが表示されている場合は、サイトリンクをブロックして非表示にすることもできますので、ご安心ください。サイトリンクのブロックは、ウェブマスターツール を使って行うことができ、一度ブロックされると、そのサイトリンクは 90 日間検索結果に表示されなくなります。サイトリンクをブロックする方法の詳細については、ヘルプ記事 をご確認ください。2009 年 7 月現在のところ、サイトのトップページに対して表示されるサイトリンクのみブロック可能ですが、将来的にはどのページに対して表示されるサイトリンクでもブロックできるように、機能の更なる拡張を進めています。

このたび改善されたサイトリンクとウェブマスターツールの機能が、ウェブマスターとユーザーの皆様のお役に立てば幸いです。

ご意見、ご質問は、ウェブマスターヘルプフォーラム までお寄せください。


Posted by Doantam Phan, Software Engineer, and Raj Krishnan, Product Manager, Sitelinks Team
Original Version: One-line sitelinks

複数の URL で同一、もしくは同一に近いコンテンツを管理されていて、重複するコンテンツ 関連の問題を抱えるウェブマスターの方々に朗報です。検索結果に優先的に表示させたいバージョンの URL を、検索エンジンに通知する書式がサポートされるようになりました。この書式をご利用いただくことで、検索結果に表示される、ご自身のサイトの URL に関して、これまでよりもコントロールできるようになります。また、この書式は、優先したいバージョンの URL に、外部からのリンクなどの情報を統合する助けにもなります。

架空のサイトを例に、この書式についてご説明します。

Swedish Fish （魚の形をしたスウェーデンのお菓子）を販売するサイトだとしましょう。優先したいバージョンの URL と、そのコンテンツは、次のようなものであるとします。

http://www.example.com/product.php?item=swedish-fish


しかし、ユーザー（や Googlebot ）は複数の URL により Swedish Fish にアクセスできるとします。これらの URL に表示されるコンテンツは、次の図のように、優先したい URL に表示されるコンテンツとほとんど同じです。異なるのは、分類用のパラメータやカテゴリー遷移に対応する部分だけです。

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy


また、次の図のように、まったく同一のコンテンツが、訪問者識別用パラメータやセッション ID を付加されたがゆえに、異なる URL で提供されている場合もあるとしましょう。

http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678


ここで、次のような優先したいバージョンの URL を指定する <link> タグを、

<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish">

重複するコンテンツを持つ URL 群:

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678

の <head> 部分に入れることにより、これらの URL 群よりも、http://www.example.com/product.php?item=swedish-fish　という正規の URL を優先的に検索結果に表示してほしいと Google に伝えることができます。PageRank などの URL に付随する情報も統合されます。

Google 以外の検索エンジンも、あなたのサイトをクロール、インデックスする際にこの情報を使うことができます。 2009 年 7 月現在、この書式は、Ask.com, Microsoft Live Search, Yahoo! においてもサポートされています。

以上が簡単な canonical 指定についての説明になりますが、読者の皆様は、きっと、もっと詳しく知りたいとおっしゃるのではないかと思い、インデックスチームの Joachim Kupke にいくつか質問に答えてもらったので、紹介します。

rel="canonical" は Google に対する命令 （directive） として機能しますか、それとも参考情報 （hint）として機能しますか？
参考情報ですが、重要な参考情報として受け止められます。検索結果に表示する最適なページの判定を行ううえで、他の情報と共に、この canonical 指定の指定も考慮に入れます。

Canonical 指定を指定する上で、<link rel="canonical" href="product.php?item=swedish-fish">のような相対リンクは使えますか？
<link> タグ内に、通常通り相対パスを使うことは可能です。また、<base> リンクを記述していただくことで、その基準 URL に基づいて、相対リンクを処理するように指定できます。

Canonical 指定で指定した URL にあるコンテンツが完全に重複するコンテンツではなくても大丈夫でしょうか？
商品の並びが違うなど、若干の違いは許容範囲です。また、優先ページと、そのページと重複するコンテンツを持つ複数のページが、異なるタイミングでクロールされることが想定されるので、複数の異なるバージョ ンの重複するコンテンツが Googlebot に検出されることがあるかもしれません。いずれにしても、問題はありません。

rel="canonical" で指定したページが 404 を返している場合はどうしたらいいのでしょうか？
これまでどおりコンテンツをインデックスし、優先するページの特定に努めますが、実在する URL を正規の URL として利用することをおすすめします。

rel="canonical" で指定した URL がインデックスされない場合はどうしたらいいのでしょうか？
インターネットにある全ての公開コンテンツに対してそうであるように、Google は canonical 指定で指定された URL もできるだけ早く発見し、クロールするよう努力しています。インデックスされると Google はすぐに、 rel="canonical" の指定について再確認します。

rel="canonical" の指定にはリダイレクト URL も使えるのでしょうか？
はい、リダイレクト設定をしている URL も、正規の URL として使うことができます。通常と同じようにリダイレクトを処理し、インデックスへの登録を試みます。

もし rel="canonical" に、複数の矛盾する URL を指定してしまった場合は、どうなるのでしょうか？
Google のアルゴリズムは寛容にできており、canonical 指定の連鎖をたどることもできますが、最適な正規化のためには、常に特定の正規の URL が指定されるよう、リンクの更新を行うようおすすめします。

異なるドメイン上の URL を canonical 指定のリンクタグ内で指定することはできますか？
できません。異なるドメインへのサイトの引越には、301 リダイレクトの利用をおすすめします。現在 Google は、サブドメイン間 （あるいは同ドメイン内）での正規化には対応していますが、異なるドメイン間の正規化には対応していません。例えば、www.example.com と example.com と help.example.com 間での canonical 指定の指定はできますが、 example.com と example-widgets.com 間での指定はできません。

実際に使われているサイトの例はありますか？
はい。wikia.com がテストサイトとして、協力してくれました。例えば、http://starwars.wikia.com/wiki/Nelvana_Limited という URL にあるページのソースコードに、http://starwars.wikia.com/wiki/Nelvana が優先ページとして指定されているのを見ていただくことができます。

この 2 つのページはほとんど同じですが、Nelvana_Limited となっている上の URL にあるコンテンツには、上部に短いメッセージが掲載されています。これは canonical 指定を有効に活用している、良い例です。この書式を利用することで、両方の URL のインデックス上の情報は統合され、検索結果には wikia.com が指定したバージョンの URL が掲載されるようになります。

ご質問やご意見は、ぜひ、ウェブマスターヘルプフォーラム までお寄せください。また、もし、この正規化の書式をすぐに導入できなくても、ご心配なさらないでください。この書式以外にも、これまで試みてきましたように （英語）、外部からのリンクなど、サイトの情報を統合し、最適なバージョンの URL を特定することに関しては、引き続き、私たちも更なる改善に努めてまいります。


Written by Joachim Kupke, Senior Software Engineer, and Maile Ohye, Developer Programs Tech Lead
Original Version: Specify your canonical

ウェブマスターヘルプフォーラム に、Googlebot や robots.txt に関する質問が多く寄せられたので、少々古い記事にはなりますが、2006 年に英語版ウェブマスターセントラルブログに掲載された記事 が、皆様の参考になればと、抄訳して掲載します。

サイトをメンテナンスのために落としています。Googebot に「メンテナンス中」のページをインデックスさせるのではなく、後でクロールに戻って来るよう伝えたいのですが、どうしたらいいですか？

サーバーが、200 （成功）ではなく、503 （ネットワーク利用不可） の HTTP ステータスコード を返すように設定してください。こうすることで、Googlebot はまた別の機会にクロールを試みるようになります。

Googlebot がサイトをクロールする負荷が高すぎる場合はどうしたらいいのですか？

ウェブマスターツール内 [サイト設定] の [クロール速度] セクションで、希望のオプションを選択していただくことができます。


Robots メタタグと robots.txt ファイルはどちらを使うのが望ましいのですか？

Googlebot はどちらの指示にも従いますが、robots メタタグはページ毎に記述する必要があります。もしクロールされたくないページが多数ある場合は、robots.txt ファイルを使って一度にそれら複数のページへのアクセスをブロックできるようサイトを構成すると、設定が簡単になります（例えば、それらのページをひとつのディレクトリにまとめるなど）。

Robots.txt に、全ての検索エンジンのボット（クローラ）を対象にした記述と、Googlebot のみを対象にした記述が混在している場合、全ての検索エンジンを対象にした記述を Googlebot はどのように解釈するのですか？

あるサイトの robots.txt に、全てのボット向けの指示と、Googlebot に限定した指示の両方が含まれている場合、Googlebot は後者を優先します。

例えば、次のような記述の robots.txt ファイルがある場合、

User-agent: *
Disallow: /

User-agent: Googlebot
Disallow: /cgi-bin/

Googlebot は、サイトの cgi-bin ディレクトリ以外のページを全てクロールします。

次のような記述の robots.txt ファイルがある場合は、

User-agent: *
Disallow: /

Googlebot は、サイトのページを一切クロールしません。

あなたのサイトの robots.txt ファイルを Googlebot がどのように解釈しているかは、ウェブマスターツールの robots.txt のテスト を使って確認することができます。また、robots.txt ファイルに変更を加えた場合、Googlebot がどのように解釈するようになるかについても、このツールで試すことができます。


Googlebot （や Google のその他のクローラ群）がどのように robots.txt を解釈するかについて、より詳しく知りたい方は ヘルプセンター をご参照下さい。


Posted by サーチクオリティチーム
Original Version: All About Googlebot

ウェブマスターの皆様は、サイトの管理者として、サイトのどのコンテンツが検索エンジンのインデックスに登録されているかについて、気を配られていることと思います。検索エンジンのインデックスに登録されたくないコンテンツについては、robots.txt ファイルか、robots メタタグを利用 して、インデックスされたくない旨を検索エンジンに伝えることができます ( 注: robots.txt でブロックされた URL のメタタグに noindex や noarchive を指定しても無効です。Google のクローラーはまず最初に robots.txt をチェックします。そこでアクセスが禁止されたページをクローラーは読み込みに行きませんので、そのページにあるメタタグの指定がクローラーに伝わりません ) が、では、すでにインデックスに登録されているコンテンツを削除したい場合は、どうしたらよいかご存知でしょうか？　今回は、Google のインデックスに登録されたコンテンツを削除する方法について、ご紹介します。

まず、その方法は、削除したいコンテンツの種類によって異なります。削除したいコンテンツの種類別の方法 が、 ウェブマスター向けヘルプセンターに詳しく記載されていますので、是非一度ご参照ください。該当する方法がとられたページは、次回クロール後に、インデックスから自動的に削除されます。ただ、もし希望されるのであれば、次のクロールまでじっと待つのではなく、削除までの時間を短縮する方法もあります。

ウェブマスターツールで 所有権の確認が済んでいるサイトについては、ウェブマスターツールにある「URL の削除」という運用ツールを利用して、インデックスからコンテンツを削除するためのリクエストを送信できます。「URL の削除」ツールのメイン画面から「新しい削除リクエスト」ボタンをクリックし、削除したいコンテンツの種類を選択してください。


個々の URL
個々の URL もしくは画像を削除したい場合は、この項目を選択してください。個々の URL の削除が正しく処理されるためには、その URL が下記のいずれかに該当する必要があります。

• 404 か 410 の HTTP ステータスコードを返す URL である
• robots.txt ファイル でブロックされている URL である
• noindex メタタグ でブロックされている URL である

次に、削除の準備が整ったら、削除したい URL を入力し、その URL が、ウェブ検索に表示されているのか、それともイメージ検索に表示されているのかを選択してください。そして「追加」ボタンをクリックします。一回のリクエストで最大 100 URL まで追加することができます。削除したい URL をすべて入力したら「リクエストの送信」をクリックします。

サイト上のディレクトリとすべてのサブディレクトリ
特定のディレクトリ内にあるすべてのファイルやフォルダを削除したい場合は、この項目を選択してください。例えば、次の URL についての削除リクエストを送信するとします。

http://www.example.com/myfolder

このリクエストによって、このパスを先頭に持つすべての URL がインデックスから削除されます。

削除される URL 例:
http://www.example.com/myfolder
http://www.example.com/myfolder/page1.html
http://www.example.com/myfolder/images/image.jpg

ディレクトリの削除が正しく処理されるためには、robots.txt ファイルを利用し、そのディレクトリをブロックする必要があります。上で挙げた例に関しては、http://www.example.com/robots.txt に、例えば次のような次の記述が必要です。

User-agent: Googlebot
Disallow: /myfolder


サイト全体
Google のインデックスからサイト全体を削除したい場合は、この項目を選択してください。この項目が選択されると、サイトのすべてのディレクトリとファイルがインデックスから削除されます。使用するドメイン以外のドメインを持つ URL をインデックスから削除するのに、このツールは利用されないようお願い致します。具体例を挙げると、サイトの URL をすべて www 有りのバージョンでインデックスさせたい場合に、www 無しのバージョンを削除するために、このツールを利用しないでただきたいのです。そのような場合は、ウェブマスターツールの「使用するドメイン」で設定を行い、可能であれば、使用するドメインへの 301 リダイレクト 設定を行ってください。また、個々の URL やディレクトリの削除同様、「サイト全体」の削除をされる際には、robots.txt を使って、サイト全体をブロックする必要があります。

Google の検索結果のキャッシュ コピー
キャッシュを削除したい場合は、この項目を選択してください。また、キャッシュの削除が正しく処理されるためには、キャッシュの削除を希望するページに、次の 2 つのいずれかを行う必要があります。

• Noarchive メタタグを適用する

• ページの内容を更新する

削除リクエストのステータス確認
削除リクエストの処理はまず「保留中」と表示され、しばらくすると「完了」もしくは「拒否」のいずれかの結果が表示されます。「拒否」という結果が表示された場合は、削除リクエストが正しく処理されるための必要条件を満たしていたかを再度確認してください。


コンテンツの再登録
削除が正しく処理されると「削除されたコンテンツ」タブに URL がリストされます。コンテンツをブロックしていた robots.txt の記載を消すか、robots メタタグを削除したうえで、このツールにある再登録ボタンをクリックすれば、いつでもそのコンテンツの再登録は可能です。この作業が行われない場合は、少なくとも 90 日間、そのコンテンツは Google のインデックスに登録されません。90 日経過した後に、再度クロールを試みた際に、そのコンテンツがまだブロックされている、もしくは 404 か 410 を返している場合は、そのコンテンツは Google のインデックスに登録されません。逆に、90 日経過した後にクロールが可能な状態であった場合は、そのコンテンツは再び Google のインデックスに登録されます。


自分の管理下にないコンテンツの削除依頼
ご自身が管理しているサイト外のコンテンツの削除についても、ウェブページ削除リクエストツールをご利用いただきますと、同様のリクエストが送信できます。


ただ、Google はウェブをインデックスしていますが、各ページのコンテンツを管理しているわけではなく、各ページのコンテンツを管理しているのは、その各ページのウェブマスターなので、基本的には、そのウェブマスターがコンテンツをブロックもしくは変更するか、ページを削除しない限り、検索結果からそのコンテンツを削除することはできません。削除を希望するコンテンツがある場合、まず、そのコンテンツの管理者に対応してもらったうえで、このツールを使って検索結果から取り除くまでの時間を短縮することができます。

特定の種類の個人情報やクレジットカード番号などを含む検索結果を見つけた場合は、そのコンテンツの管理者の協力が得られなくても、このツールを使ってリクエストを送信することが可能です。その場合には、Google が直接皆さんと協力できるよう、メールアドレスの入力をお願いします。



また、このツールは、セーフサーチにおいて不適切な結果が返された際のご報告にも利用することができます。


ウェブマスターツール内の URL 削除ツール同様、「保留中」「完了」「拒否」など、リクエストのステータス確認もできます。基本的には、正しく削除の処理が行われるための必要条件を満たしていないと、リクエストは拒否されます。個人情報に関する削除リクエストのステータスは、ここには表示されません。代わりに、削除リクエストを行うに当たって必要な次のステップをご説明するメールが届けられます。

Posted by サーチクオリティチーム
Original Version: Requesting removal of content from our index

本日、Google 検索エンジン最適化スターター ガイドの日本語版 (pdf) を公開致しました。内容は、昨年公開した Search Engine Optimization Starter Guide (英語) と同様です。英語版が出た際に、英語版ウェブマスターセントラルブログに掲載したアナウンスメントの抄訳とともに、紹介します。

フォーラムやカンファレンスなどで、ウェブマスターの方々からよくいただくのは、「どうしたら簡単に Google の検索結果におけるサイトのパフォーマンスは上げられるの？」というご質問です。その質問に対する答えにはとても色々な可能性があり、実際、インターネットには、検索エンジン最適化 (SEO) に関する情報が氾濫しているので、ウェブマスターになりたての方や、この話題にまだ馴染みのない方は、最初はびっくりしてしまうかもしれません。

サイトのクローラビリティやインデックスの状態を改善するうえで、参考になるベストプラクティスを紹介するガイドがあれば、ウェブマスターの方々や、 Google 社内の別のチームの仲間にも参考になるかもしれないと思い、このたび、Google 検索エンジン最適化スターター ガイドを作成しました。

この Google 検索エンジン最適化スターター ガイドは、 ウェブマスターがサイトの検索エンジン最適化を検討する際にチェックするであろう、13 の分野について取り上げています。例えば、title タグや description タグ、URL の構造、ナビゲーション、コンテンツ、アンカーテキストなどの改善についてです。経験値や、サイトの規模・種類に関わらず、全てのウェブマスターの方の参考になるように作りました。内容がより詳しく伝わるよう、図や、陥りがちな落とし穴、各種詳細資料へのリンクもたくさん盛り込んでいます。今後は、定期的にこのガイドを更新し、新たな最適化の提案や、最新の技術的なアドバイスを提供できるよう努めていきたいと考えています。

今度、「SEO 初心者なのですが、サイトをどう改善したらいいか教えてください」と聞かれたら、Google 社内でも活用している、この Google 検索エンジン最適化スターターガイドを紹介したいと思います。

ご不便をお掛けしましたことをお詫び申し上げます。

Written by Brandon Falls, Search Quality Team
Original Version: Google's SEO Starter Guide

Google のクロールに関して、ヘルプフォーラム に何件かご質問をいただきましたので、去年の秋に英語版 Webmaster Central ブログに掲載された記事 （英語）が参考になればと、抄訳して掲載いたします。

2006 年に、ウェブマスターツール に「ウェブクロール エラー」の表示機能が追加されて以来、どの URL においてエラーが生じているのかがわかると更に便利だというご意見を、多数のウェブマスターの方々からいただきました。例えば「ページが見つかりません ( 404 Not Found ) 」のようなエラーの修正と予防は、リンク元の URL が特定できないことには難しいものです。このような声にお応えするかたちで、このたび、クロールエラーの原因となったリンク元の数と URL がウェブマスターツールに表示されるようになりました。

ウェブマスターツールの「診断」から「ウェブクロール」を選んでいただくとレポートが表示されます。その中の「見つかりませんでした」や「サイトマップの URL に関するエラー」の項目に「リンク元」という列が追加されています。この列には、例えば「ページが見つかりません ( 404 Not Found ) 」というエラーが生じている URL にリンクしているページの数が表示されます。


この「リンク元」の列に表示されているページ数をクリックすると、問題の URL にリンクしているページのリストが表示されます。これらのページが検出された日付も表示されます。リンク元は、ご自身のサイト内であることもあれば、サイト外のこともあります。


これらのリンク元を一括してダウンロードする機能もついています。「このサイトの全てのエラー ソースをダウンロード」というリンクをクリックしていただければ、エラーの原因となっているリンク元のリストをダウンロードしていただけます。


このように、サイトにクロールのエラーが生じている場合は、ウェブマスターツールを使って、クロールエラーの原因が、ご自身のサイトにあるのか、外部のサイ トにあるのかを、調べることができます。クロールエラーの原因となっているページを特定することにより、そのページの管理者に修正を依頼することもできますし、必要であれば、正しい URL へのリダイレクト設定 を行うこともできます。是非一度 ウェブマスターツール にログインし、この機能を試してみてください。ネットのどこかからあなたのサイトを訪れようとしているユーザーや、すでにあなたのサイト内にいるユーザーが、求めていた情報にちゃんとたどり着けるように手助けすることができます。

サイトのユーザーエクスペリエンスの向上にお役立ていただければ幸いです。


Written by Jonathan Simon, Webmaster Trends Analyst and Michael Williamson, Webmaster Tools Intern
Original Version: Webmaster Tools shows Crawl error sources

今回は、ウェブマスターの方々のブログや掲示板でしばしば話題にあがる疑問にお答えします。[site:example.com] のように、"site: 演算子" を使ってご自身のサイトを検索すると Google のインデックスに登録されたサイト内のページが表示 されますが、その数と、"ウェブマスターツールの「サイトマップの詳細」に表示される「インデックスに登録された URL の数" が異なるという疑問についてです。 この違いは一見バグのようですが、実は設計によるものです。 ウェブマスターツールの「サイトマップの詳細」のデータには、サイトマップを使って送信した URL しか反映されません。一方、site: 演算子による検索結果には、サイトに新たに追加された URL や、リンクをたどることで発見された URL など、サイトマップには記載されていないが、Google がクロールするに至ったあらゆる URL が含まれています。

Site: 演算子は、あなたのサイトが Google のインデックス上でどのような状態にあるかを手軽に診断するための方法とお考えください。Site: 演算子を使って確認できることは、次のようなことです。

• インデックスに登録されたページのおおよその数
• サイトが第三者の手によって不正に書き換えられてしまっていないかどうか

• 重複するタイトルやスニペットがないか

次の図は site: 演算子を使って検索した一例です。


ウェブマスターツール内のサイトマップに関するレポートでは、より詳細な内容がご確認いただけます。例えば、サイトマップで送信された URL のうち、インデックスされた URL はいくつであったか、また、もし Google がそのサイトマップにアクセスしようとしたときに、問題がが生じていたら、そのエラー情報や警告も表示されます。


Site: 演算子 やサイトマップ については、ヘルプセンターに詳細記事がありますので、是非一度ご覧ください。ヘルプセンターでは解決しない疑問がありましたら、ウェブマスターヘルプフォーラム へ投稿されることをおすすめします。経験豊富なウェブマスターの方々や、Google 社員が、あなたの質問をお待ちしています。


Written by Charlene Perez, Search Quality Team
Original Version: Using stats from site: and Sitemap details

Google に検索エンジン向け サイトマップ を送信する方法が簡単になりました。以前はサイトマップのファイル形式を特定していただく必要がありましたが、もうその必要はありません。送信されたデータの形式は、自動的に判別されます。今日は、Google がサポートしているサイトマップの形式と、サイトマップを Google に送信する方法をご紹介します。

※一部、リンク先が英語のページも含まれています。ご了承ください。


Google がサポートしているサイトマップの形式

インターネットを面白いものにしている理由のひとつは、本当にさまざまな種類のコンテンツがそこにあることでしょう。あなたのサイトにも動画がありませんか？ もしあるのでしたら、是非 Google に、動画サイトマップを送信してください。そうしていただくことで、Google はその動画に、ユーザーを連れていくことができるようになります。または、ソースコードのサンプルを掲載していませんか？　もし掲載していたら、ソース コード検索サイトマップの送信をお願いします！　以下は、現時点で Google がサポートしているサイトマップの形式です。このように、多様な形式に対応しています。

• ウェブページ用の XML サイトマップ - サイトにある全てのページを送信するときは、このサイトマップを使ってください（ウェブページにはこの形式が推奨されています）。これ以外のサイトマップ形式は、全ての検索エンジンでサポートされているわけではありませんが、ウェブページを対象とした XML サイトマップは、sitemaps.org に賛同する全ての検索エンジンによってサポートされています。
  
• ウェブページ用の RSS 2.0　と Atom 1.0 フィード - ブログの多くはこれを自動的に作成します。
• ウェブページの URL 一覧を記載したテキストファイル - 上記形式のサイトマップを自動的に作ることができない場合は、サイトの URL リストを入力したテキストファイルを使うこともできます。
• 動画検索用の動画 XML サイトマップ - あなたのサイトの動画をインデックスし、Google 動画検索 で検索されるようにします。
• 動画検索用の Media-RSS フィード - mRSS フィードは様々なシステムで利用されていますが、Google 動画検索 にも使われています。
• Google ソースコード検索用 XML Sitemap - ユーザー向けにプログラムのサンプルやソースコードを提供している場合は、Google ソースコード検索 用にこのサイトマップを送信します。
• モバイル検索用 XML サイトマップ - この形式を利用すると、そのコンテンツはモバイル用に最適化されているものだということを Google に知らせることができます（最近、形式に若干の変更がありましたので、ご注意ください）。
• 地理情報用の XML サイトマップ - KML か GeoRSS ファイル形式の地理情報データがサイトにある場合は、Google にこれらに関して教えてください。
• ニュース用 XML サイトマップ - ニュースのサイトはニュース記事を送信するのに、特別な形式のサイトマップが利用できます（このサイトマップを送信する前に、Google ニュースへのご登録 をお忘れなく）。

Google に送信予定の複数のサイトマップをお持ちの場合は、1,000 ファイル以内であれば、サイトマップインデックスファイル にまとめることができます。1,000 より多くのサイトマップをお持ちの場合は、分割して、複数のサイトマップインデックスファイルを送信することも可能です。もちろん Google は全て喜んでお受けします！

Google にサイトマップを送信する方法

サイトマップファイルを作成し、サーバーにあげて、準備が整ったら、あとは、検索エンジンがそのサイトマップを見つけるようにするだけです。Google は、サイトマップを送信する 3 つの簡単な方法をサポートしています。

• Google ウェブマスターツール を使う

• robots.txt ファイルにサイトマップについて記載する

• HTTP "ping" を使う

これらの簡略化が、サイトマップを送信していただくうえで、皆様のお役に立てば幸いです。


Written by John Mueller, Webmaster Trends Analyst, Google Zürich
Original Version: Sitemap Submission Made Simple