ウェブマスター向け公式ブログ
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報
ウェブマスター ツール: 「検索クエリ」 など、新機能のお知らせ。データの増減がよりわかりやすくなりました
2010年11月24日水曜日
ウェブマスター ツールの一部の機能が更新されましたのでお知らせします。検索結果にてあなたのサイトがどのように表示されるのかをより詳細に把握し、管理することができるようになりました。
検索クエリ:
常に変化するサイトの動向をいち早くキャッチしたいという点から、表示回数、クリック数、CTR（クリック率）、平均掲載順位の各列の横に新たに 「変更」列を追加しました。それぞれの値が増加している場合は緑色で、減少している場合は赤色で矢印と共に表示されるため、これらの数値のそれぞれの傾向を容易に把握することができます。また、「変更」列は指定した期間に対応しているため、なんらかの変化があった時期の特定も簡単です。
「検索クエリ」に一覧表示される各「検索キーワード」は、そのキーワードの表示回数やクリック数のグラフが確認できる、詳細ページにリンクされています。これによりキーワードごとに時間の経過に伴う検索結果における数値の推移を視覚的に把握することができます。グラフの下には、そのキーワードで検索された際に表示されるページの一覧、表示回数、クリック数、CTR が記されたテーブルが表示されます。テーブルの各列はソートが可能で、最も興味のある項目を基準にソートすることができます。ご自身の使い慣れたツールを使ってデータを分析したい場合は、「このテーブルをダウンロード」のリンクをクリックしてメインの「検索クエリ」ページ全体か、各キーワードの詳細ページの情報をエクスポートすることができます。
パラメータ処理の更新:
昨年ウェブマスター ツールでは、
パラメータ処理（英語）
を導入し、URL パラメータを指定しそれを無視して良いかを設定できるようにしました。今回、この機能をウェブマスター ツール内の「サイト設定」－「設定」にあるタブ内に移動し、パラメータ管理機能を強化しました。これまで同様パラメータ処理では、あるパラメータを無視するように指定した場合、このパラメータは表示される内容に影響を与えないということを Google に知らせることになります。
例えば、以下の URL にある "sid" のようなセッション ID パラメータの場合を見てみましょう。
http://example.com/product.php?item=swedish-fish
http://example.com/product.php?item=swedish-fish&sid=1234
http://example.com/product.php?item=swedish-fish&sid=5678
上記の 3 つの URL が、まったく同じ「Swedish Fish（魚型のグミキャンディ）」の商品ページを表示すると仮定した場合、Google がクロールし、インデックスする必要があるのはこれらのページのうち 1 つの URL だけでいいのです。
この場合、ウェブマスター ツールにてパラメータ "sid" を「無視する」と指定するだけで、1 つの URL のみをインデックスに登録し、コンテンツ内の重複を避けることができます。
上記のこれまでの機能に加え、今回、特定の URL パラメータにおける有効な値の中から、特定の値を選択できる機能を追加しました。この機能は、あるパラメータの値がコンテンツと連動し、パラメータの値が変わるとよく似た異なるページを表示するような場合に重要になります。
例えば、URL にある "sort-by" のような並べ替え用のパラメータが含まれている場合を見てみましょう。
http://example.com/shop.php?category=candy&sort-by=asc-price&page=1
http://example.com/shop.php?category=candy&sort-by=desc-price&page=1
http://example.com/shop.php?category=candy&sort-by=asc-price&page=2
http://example.com/shop.php?category=candy&sort-by=desc-price&page=2
上記の 4 つの URL が「キャンディ」のカテゴリの商品を表示するとします。このカテゴリは 2 ページに渡って表示され、表示される商品は値段によって、昇順もしくは降順に並べ替えが可能です。この場合、 "sort-by" のパラメータを無視に設定することは適切ではなく、Google によるサイトのインデックス登録がうまくいかない可能性があります。例えば、 "sort-by" を無視した場合、Google が本来は異なる上 2 つの URL を同じものと認識し、昇順で並べ替えられた URL をインデックス登録する可能性があります。また、同様に下 2 つの URL を同じものと認識し、降順で並べ替えられた URL をインデックス登録する可能性があります。これによって、「キャンディ」カテゴリのインデックス登録に一貫性がなくなり、結果として、あるキャンディはインデックスに指定された両方のページに表示されるが、あるキャンディはどちらのページにも表示されないということが起こり得ます。
そこで今回この現象を回避するため、ウェブマスター ツールにて新機能の「特定の値を使用」を選択できるようにしました。具体的には、 "sort-by" のパラメータに対して、「特定の値を使用」をプルダウンから選択し、有効な値（例えば "asc-price" ）を選択するだけで、Google は値段によって昇順に並んだ商品のページのみをインデックスの対象とします。これによりインデックス内で重複するコンテンツを減らし、さらに Google のインデックス登録に一貫性を持たせることができます。
メッセージ:
サイトによってはウェブマスター ツールのメッセージ センターで、多くのメッセージを受け取る場合があります。今回の更新で、あなたが重要だと思う特定のメッセージにスターをつけることができるようになりました。新しい「スター付き」表示を選択すると、あなたがスターをつけたメッセージをすべて見ることができ、あなたのサイトにとって重要なメッセージの確認やトラッキングが容易になります。
今回の更新で、ウェブマスター ツールがさらに便利に利用できるようになれば幸いです。今回の更新に関するご意見やご質問は、ぜひ
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by Jonathan Simon, Webmaster Trends Analyst
Original version:
Webmaster Tools: Updates to Search queries, Parameter handling and Messages
ウェブマスター ツール「サイトへのリンク」機能が新しくなりました
2010年11月18日木曜日
ウェブマスター ツール
の「
サイトへのリンク
」 機能が新しくなりました。あなたのサイトがどのドメインから 1 番多くリンクされているかを確認できるようになったことを始めとして、いくつかの改善がなされました。たとえば、サマリーページには 3 つのセクションがあり、リンク数の最も多いリンク元、あなたのサイト内で最も多くリンクされているコンテンツ、あなたへのサイトのリンク用に外部ページが使用しているアンカーテキストのサンプルを確認できるようになっています。それでは主な特徴をみていきましょう。
リンク数の最も多いリンク元
「リンク数の最も多いリンク元」のセクションの下にある「詳細 »」をクリックすると、あなたのサイトにリンクしているドメインの一覧が表示されます。一覧からドメイン名をクリックすると、そのドメインからリンクされているあなたのサイト内のページが、サンプルとして表示されます。
さらに各ドメインの下にある「詳細 »」をクリックすると、そのドメインからリンクされているページの一覧が表示されます。ページの上部には、そのドメインからのリンク数の合計と、リンクされているあなたのサイトのページ数の合計が表示されます。
最も多くリンクされているコンテンツ
「最も多くリンクされているコンテンツ」のセクションの下にある「詳細 »」をクリックすると、あなたのサイトの中でリンクされているページの一覧が表示され、合わせてそのページの被リンクの数と、そのページにリンクしているドメイン数の合計も表示されます。一覧表示されているページをクリックすると、そのページにリンクしている主なドメインと、そのドメインから貼られているリンク数が表示されます。リンク数の算出および「サイトへのリンク」機能全体で用いられるデータはより包括的になり、301 または 302 リダイレクトされたリンクを含むようになりました。
「リンクされているすべてのページ」にて一覧表示されているページには「詳細 »」という関連リンクがあり、そのページにリンクしている全てのドメインの一覧を表示させることができます。
表示されているドメインをクリックすると、そのページにリンクしているドメイン内のページの一覧が表示されます。
今回のウェブマスター ツール「サイトへのリンク」機能の改善 によって、あなたのサイトがどのようにリンクされているか、より詳細に把握しやすくなり、サイトのリンク構成の変化を効率的に追跡することができるようになれば幸いです。みなさまのフィードバックはウェブマスター ツールの機能性の更なる向上につながります。今回の更新に関するコメントやご質問は、
ウェブマスター ヘルプフォーラム
までお寄せください。
Posted by Jonathan Simon, Webmaster Trends Analyst
Original version:
Webmaster Tools - Links to your site updated
参照元の記事を明らかにする新しいメタタグをご紹介します
2010年11月17日水曜日
ニュース記事を書いたジャーナリストが明らかになることは、読み手にとってもニュースの発行元にとっても良いことです。しかし、ニュースの広まる速度が速くなり、記事を他のウェブサイトに配給するサイトも増加しているため、これを実現するのが難しくなっているのも事実です。そこで、Google ニュース用の新たなメタタグ、syndication-source と original-source への対応を試験的に進めています。それぞれ使用する場面は異なりますが、記事を公開したニュースの発行元と、記事を書いた他のジャーナリストを正しく伝えることが目的です。メタタグの使用例は次の通りです。
syndication-source
は配給された記事の、優先的に表示させたい URL を指定するために使います。2 つの記事が全く同じ、あるいはほぼ同一である場合、発行元には syndication-source を使って Google ニュースで使用すべき URL を指定していただいています。例えば、発行元 X が発行元 Y に記事を配給している場合、両社とも該当の記事に以下のメタタグを追加する必要があります。
<meta name="syndication-source" content="http://www.publisherX.com/wire_story_1.html">
original-source
は、あるニュースを最初に報じた記事の URL を指定するために使います。Google ではニュース発行元に、このメタタグを使用し最初にニュースを取り上げた記事を明らかにすることを勧めています。どの記事が最初の記事か判断しにくい場合もあるとは思いますが、このメタタグの目的は記事を書いた人の努力や労力がきちんと評価されることにあります。あるトピックについて初めて書かれた記事につけるメタタグは、次のようになります。
<meta name="original-source" content="http://www.example.com/burglary_at_watergate.html">
両方のケースとも、メタタグが現在のページの URL を指定していても、何も問題ありません。また、1 つのページに複数の original-source メタタグを追加し、現在の記事につながる複数の情報源が指定されていても問題ありません。いずれのケースも、正確な URL がわからない場合は、元記事のあるサイトのドメインを指定してください。
これらのメタタグはすでに Google で使用されていますが、結果が皆様の目に見えるようになるのはもう少し先かもしれません。しばらくは実際の使用状況を観察し、活用する方法を検討していく必要があります。しかし、このメタタグを用いることで、記事の出所がはっきりわかるようになりますので、今から是非とも活用いただければと思います。
今回ご紹介したメタタグの仕様や、サイトに取り入れる方法の詳細については、
ヘルプ センターの記事
（英語）をご参照ください。
Posted by Eric Weigle, Software Engineer, and Abe Epton, Publisher Technical Specialist
Original version:
Credit where credit is due
Merchant Center をご利用の皆様へ
2010年11月12日金曜日
10 月末にサービスの提供を開始した
Google ショッピング
は、おかげさまでたくさんの方に使っていただいており、チーム一同、とてもうれしく思っています。また、現在、私たちの予想をはるかに超える数のフィードを
Google Merchant Center
からご送信いただいており、審査完了まで通常以上の時間を頂戴しております。心配をお掛けして大変申し訳ありません。まだお時間を頂戴しますが、すべての店舗のフィードを審査していますので、いましばらくご辛抱いただけますようお願い致します。
また本日は、フィードに関してよくあるご質問とその解決方法をご紹介いたします。
1) 必須の属性とは具体的にどんなもの？ 推奨される属性は入れなければならないの？
必須の属性とその値は、すべてのデータフィードに含んでいただく必要があります。次の属性が含まれていないと、データフィードは処理されませんので、ご注意ください。
商品 ID [ id ] : 商品を一意に識別する英数字の ID。
商品名 [ title ] : 商品の名前。「送料無料」「セール」「50% オフ」などの宣伝の文言は含まないでください。
商品リンク [link] : 商品の URL へのリンク。この URL には個別のオンライン購入オプション ( 「カートに入れる」ボタンなど ) が必要です。
価格 [price] : 商品の価格。この値は、ウェブページに掲載されている価格と常に一致するようにしてください。価格の変動が頻繁に行われるサイトは、その変動に対応する頻度でフィードを更新してください。また、会員価格や通常価格がある場合は、通常価格を含むようにしてください。
商品説明 [ description ] : 商品の説明テキスト。商品名同様に、宣伝の文言は含まないでください。
状態 [ condition ] : 「新品 (new)」「中古品 (used)」「再生品 (refurbished)」のいずれかを指定します。
推奨される属性と値は、必ずしも必要なものではありませんが、次の 2 つは特にフィードに含まれることをお勧め致します。
商品画像リンク [ image_link ] : 画像が提供されないと Google ショッピングの検索結果に画像が表示されないため、ユーザーにとっても皆様にとっても不利益となりますので、商品画像がある場合はこの情報を送信されることを強く推奨します。商品画像がない場合は、この属性を空白にします。ロゴや「イメージがありません」のような汎用画像は含まないでください。
GTIN [ gtin ] : GTIN ( 国際取引商品番号 ) には JAN コードや ISBN コードが含まれます。商品に GTIN が存在する場合には極力送信されることを強く推奨します。
詳細は、
ヘルプ記事: フィード仕様
をご参照ください
2) 日本語の属性を使っているせいか、フィードがエラーになります。どうしたらいいですか？
使用するフィードの形式に応じて言語設定を行う必要があります。
テキスト ( スプレッドシート ) またはタブ区切り形式のファイルを使用する場合は、英語または対象国の言語の属性が使用できます。ただし、属性名と値の言語は一致するようにしてください。たとえば、日本語の属性名を使用される際は、日本語の値を使用してください。また、このとき、フィードの設定において、属性の言語の設定を使用している属性と値の言語、もしくは自動検出に設定することをお忘れなく。
データフィードの登録
の詳細はこちらをご覧ください。
XML 形式のファイルもしくは API を使用する場合は、英語の属性のみ使用可能です。
詳しくは、ヘルプ記事:
データフィードの概要
をご参照ください。
3) フィードの承認ステータスについて詳しく教えてください
ご提供いただいたフィードがプログラムポリシーに沿っているかどうかの審査が完了し、承認が反映されると、商品が Google ショッピング上で検索可能となります。なお、ステータスは、
Merchant Center
内、[ 商品 ] タブにて確認ができます。送信されたフィードにすべての必要な属性が確認されると、まず、"審査待ち" ステータス (
オレンジ色の砂時計
) となり、承認が反映されると、"検索可能" (
緑色のチェック
) になります。承認がされない場合、承認されない理由をご説明するメールが送信されると同時に、ステータスが "承認されませんでした" (
赤いストップマーク
) となります。一度このステータスが反映されると、その後何度フィードを送信しても、同じステータスが Merchant Center には表示され続けますが、実際には「審査待ち」の状態にあるとご理解ください。再審査は定期的に行われていますが、こちらも現在通常以上に時間がかかっております。2 週間程度経っても変化がない場合は、
不承認のデータフィードまたは商品
のフォームからお問い合わせください。
商品のステータスのより詳細な定義は、
ヘルプ記事: 公開された商品の表示
にありますので、ご参照ください。
この他のご質問については、
Merchant Center のヘルプ記事
をご参照ください。
Google ショッピング
は、多くのオンラインショッピングサイトのウェブマスターの方々の参加があって初めて実現されるプロダクトですので、今後もできる限り多くの方に Merchant Center をご利用いただければと思っています。ご意見やご質問はぜひ
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by 鈴木宏輔 / プロダクトマネージャー
インスタント プレビューについて
2010年11月10日水曜日
本日、昨年 11 月から提供していた
検索ツールのプレビュー表示機能
がインスタント プレビューとして生まれ変わりました。この機能は、各検索結果のプレビューを表示することでユーザーが目的の情報を探しやすくする機能です。従来は、タイトル、URL、スニペット（要約文）などのテキスト情報に基づいて、どの検索結果が自分の探している結果であるかを判断していました。インスタント プレビューの目的も同じですが、テキスト情報ではなく、各ページおよびページ内の関連個所を視覚的に表示します。ウェブマスターの皆さまにとっては、サイトのデザインの秀逸性をアピールする機会です。そこで、この機会をどのように生かせるか、いくつかポイントを挙げたいと思います。
まず、インスタント プレビューがどのような機能か理解することが重要です。ユーザーが任意の検索結果の虫めがねアイコンをクリックすると、そのページのスクリーンショットが検索結果の右に表示されます。オレンジ色でハイライトされた箇所がページ内で検索ワードと関連性が非常に高い個所になります。また、吹き出しには関連する箇所が抜き出されて表示されます。
これらの要素によって、ユーザーは検索結果をクリックした際にどのような情報が取得できるか、またなぜ検索ワードと関連性が高いかを知ることができます。そのため、あなたのページに実際に来るユーザーは探している情報を見つけ、サイトに滞在する可能性が高くなります。インスタント プレビューはクリックした検索結果の満足度を 5% 以上高められるという結果が我々の実験でも出ています。
多くのサイトが、サイトの構成、ページのレイアウト、情報の表示方法に対して多くの努力を注いできました。インスタントプレビューは Google の検索結果ページ上で非常に多くのスペースを使ってあなたのサイトをアピール出来る絶好の機会です。それでは、この機能を有効活用するコツをご紹介しましょう。
余分な情報を極力載せず、ページの構成とレイアウトをシンプルにすること。シンプルさと明快さがインスタント プレビューを通じてユーザーに明らかになり、あなたのサイトのビジターはより良い体験ができるでしょう。
すきま広告やポップアップなどコンテンツを見えにくくする要素を避けましょう。これらの要素はプレビューに表示される可能性があり、その場合スクリーンショットが分かりにくくなってしまいます。
多くのサイトのプレビューは通常のクローリングにより自動的に生成されます。時折、スクリーンショットをユーザーのリクエストに応じて生成することがあります。その際、新しい "Google Web Preview" ユーザーエージェントを使ってページをクロールします。
インスタント プレビューは Google の検索結果順位を一切変えません。同じ検索結果、同じ検索順位です。また、クリックのトラッキング方法も変わりません。その結果のプレビューが表示されたかどうかに関わらず、検索ユーザーが検索結果のタイトルをクリックし、あなたのサイトを訪問すると、それは通常通り 1 クリックとしてカウントされます。インスタント プレビューの表示自体はクリックとしてはカウントされません。
nosnippet メタ タグ
を設定したページは、Google の検索結果にスニペットが表示されません。インスタントプレビューも同様に nosnippet メタ タグが付与されているページについてはプレビューを表示しません。しかし、インスタント プレビューからオプトアウトするかどうかは慎重にご検討ください。通常のスニペットと同様、プレビューはユーザーにとっては有益な情報です。我々の実験結果ではプレビューが表示された結果が実際にクリックされる確率は 4 倍以上に高まります。また、robots.txt でブロックされたページはインスタント プレビューを表示しません。
現在、インスタント プレビューは一部の動画やフラッシュコンテンツを"パズル"アイコンあるいは黒い四角に置き換えて表示します。これらのリッチコンテンツを正しく表示できるよう現在改善中です。
今後もインスタント プレビューをさらに改善していきますので、ご期待ください。
Posted by 鈴木宏輔 / プロダクトマネージャー
URL 末尾のスラッシュは必要？
2010年11月5日金曜日
URL 末尾のスラッシュ（「/」）は必要なのでしょうか？今回は、よく聞かれるこの質問について、取り上げたいと思います。
一般的には、下記のように、URL の末尾にスラッシュが付いている場合はディレクトリを示し、スラッシュが付いていない場合はファイルを示す、という使い分けがされてきました。
http://example.com/foo/ （末尾にスラッシュがあるので、通常はディレクトリを示す）
http://example.com/foo （末尾にスラッシュがないので、通常はファイルを示す）
ただし、これはあくまで慣例に過ぎません。Google では、ファイルかディレクトリか、または URL 末尾にスラッシュがあるかどうかに関わらず、上記の URL はそれぞれ別物として（そして、同等に）扱われます。
スラッシュの有無でコンテンツが異なる場合について（ユーザーには不便？）
検索エンジンにとっては、この 2 種類の URL がそれぞれ異なるコンテンツを保有していたとしても、技術的には問題ありません。しかし、ユーザーにとっては、非常に分かりにくいと言えます。たとえば、www.google.co.jp/webmasters と www.google.co.jp/webmasters/ でまったく違うコンテンツが表示される場合を想像してみてください。
このような理由から、末尾にスラッシュがある URL とない URL で、同じコンテンツを表示することが多いのです。典型的には、次のようなディレクトリ構成になっているサイトによく見られます。
http://example.com/parent-directory/child-directory/
スラッシュの有無に関わらずコンテンツが同じ場合について
では、下記のような 2 種類の URL で同じコンテンツが表示される場合について考えてみましょう。
http://<ドメイン>/<ディレクトリ>/
（末尾にスラッシュあり）
http://<ドメイン>/<ディレクトリ>
（末尾にスラッシュなし）
この場合は、両方ともが
ステータス コード 200
を返すのではなく、片方がもう一方に
リダイレクト
するという設定にするのが望ましいと言えます。というのも、このように設定することで、
重複するコンテンツの問題
を避けることができるからです。ブラウザのアドレス バーに URL を直接入力することで、この設定の簡単なチェックが可能です。
もし、両方の URL を入力しても、どちらか一方の URL しか返ってこない場合は、もう一方の URL がこの URL にリダイレクトされているので、その設定のままで問題ありません。ちなみに、末尾にスラッシュが付いている URL にリダイレクトされる場合、Google の検索結果には通常、そのリダイレクトが 301 か 302 かに関係なく、200 を返す方の URL （一般的には末尾にスラッシュがある方の URL ）が表示されます。
一方で、スラッシュの有無に関わらず、どちらの URL もレスポンス コードとして 200 を返す場合には、どうすればよいでしょうか？
重複するコンテンツを減らし、
クロールの効率性
（英語）を上げるために設定を変更する（詳細は下記を参照）。
特に設定を変更しない。
最適な選択とは言えませんが、特に問題はありません。というのも、多くのサイトが重複するコンテンツを保有しているため、Google ではサイトをインデックスする際、ウェブマスターとユーザーに配慮してこのようなケースにもおおむね対応しているからです。
※ ちなみに、ルート URL については、http://example.com のように末尾にスラッシュがなくても、http://example.com/ とまったく同一に扱われ、決してリダイレクトされることがないようになっています。
URL の形式を統一する手順
下記の 2 種類の URL がどちらもレスポンス コードとして 200 を返し、そのコンテンツが重複している場合は、以下の手順に従って URL の形式を 1 つに統一することができます。
http://<ドメイン>/<ディレクトリ>/
http://<ドメイン>/<ディレクトリ>
優先 URL としてどちらか一方の URL を選択する。
サイトがディレクトリ構造の場合は、URL の末尾にスラッシュを付けるのが慣例となっていますが（例: example.com/directory ではなく example.com/directory/）、どちらを選択するかは自由です。
優先 URL として選択した形式を一貫して使用する。
リンクや
サイトマップ
には、重複 URL ではなく、優先 URL を使用します。
301 リダイレクトを利用して、重複 URL から優先 URL にリダイレクトする。
リダイレクトの設定ができない場合は、
rel="canonical" 属性
の利用を強くおすすめします。この属性を指定することで、Google やその他の検索エンジンに対して、2 つの URL に分散していたリンクの効果をまとめるなど、301 リダイレクトと同様の効力を発揮することができます。この点についての詳細は、
SEO レポートカード
の「調査分野Ⅱ URL とリダイレクト」をご覧ください。
ウェブマスター ツール
の
Fetch as Googlebot
機能を利用して、301 リダイレクトの設定を確認する。
たとえば、下記のような URL のペアが期待通りのステータス コードを返すか確かめてみましょう。
http://example.com/foo/
http://example.com/foo
具体的には、優先 URL が 200 を返すのに対して、重複 URL が 301 を返して優先 URL にリダイレクトするかどうか確認します。また、モバイル サイトの場合は、
Fetch as Googlebot-Mobile
機能を利用すると同様に確認することができます。
クロール エラー
がないかウェブマスター ツールでチェックする。
可能であれば、ウェブ サーバーのログも念のためチェックして、301 リダイレクトをしているか確認しましょう。
以上の手順を踏むことで、サイトがより最適化され、サーバー運用が効率的になります。
Written by Maile Ohye, Developer Programs Tech Lead
Original version:
To slash or not to slash
ラベル
+1 ボタン
2
AMP
11
API
3
App Indexing
8
CAPTCHA
1
Chrome
2
First Click Free
1
Google アシスタント
1
Google プレイス
2
Lighthouse
3
Merchant Center
8
NoHacked
4
PageSpeed Insights
1
reCAPTCHA v3
1
Search Console
96
speed
1
イベント
17
ウェブマスターガイドライン
54
ウェブマスタークイズ
2
ウェブマスターツール
83
ウェブマスターフォーラム
8
オートコンプリート
1
お知らせ
59
クロールとインデックス
71
サイトクリニック
4
サイトマップ
14
スマートフォン
11
セーフブラウジング
5
セキュリティ
18
データー ハイライター
2
ハッキング
19
ハングアウト
2
ビデオチュートリアル
7
マルウェア
9
モバイルサイト
54
リッチカード
1
リッチスニペット
12
リッチリザルト
3
画像
1
画像検索
1
検索エンジン最適化
13
検索結果
79
構造化データ
19
国際化
4
再審査リクエスト
9
初級者向け
160
上級者向け
203
中級者向け
206
動画
1
アーカイブ
2018
12
11
10
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
4
3
2
1
2016
12
11
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
5
4
3
2
1
2014
12
11
10
9
8
7
6
5
4
3
2
1
2013
12
11
10
9
8
7
6
5
4
3
2
1
2012
12
11
10
9
8
7
6
5
4
3
2
1
2011
12
11
10
9
8
7
6
5
4
3
2
1
2010
12
11
10
9
8
7
6
5
4
3
2
1
2009
12
11
10
8
7
6
4
3
2
1
2008
12
Feed
Google
on
Follow @googlewmc
