googlewebmastercentral-ja: 2011

2011 年もありがとうございました！ウェブマスターヘルプフォーラムから感謝をこめて

2011年12月26日月曜日

Google ウェブマスター向け公式ヘルプフォーラムより使いやすく新しい UI へGoogle プロダクトフォーラムトップレベルユーザーの方々とアメリカへ「グローバルトップレベルユーザーサミット 2011」が開催されましたみなさまからたくさんのアイディア・ご意見を頂きましたウェブマスターヘルプフォーラムユーザーアンケートウェブマスターツールにどんな機能があるといいですか？ウェブマスターとして震災に対してできることはないか2011 年のブログ人気記事アフィリエイトを導入されているウェブマスターの皆さまへPosted by サーチクオリティチーム

多言語コンテンツのマークアップのヒント

2011年12月18日日曜日

rel="alternate" hreflang="x"

多地域向けのサイトで、ほぼ同じ内容のコンテンツを使用している場合。例: オーストラリア、カナダ、米国向けの英語版サイトで、価格のみが異なっているもの

多地域向けのサイトで、内容をすべて翻訳したコンテンツを提供しているもの、あるいは、全く異なる各国言語のコンテンツを地域別に提供しているもの。例: 日本語、英語、韓国語で書かれた製品情報ページを持つサイト

言語と地域を指定する翻訳されたコンテンツ、または複数の異なる地域向けに提供されたコンテンツに対応しましたほぼ同一のコンテンツとしてページにアノテーションを付けるrel="canonical" 属性使用例

http://www.example.com/ - ウェブサイトの通常のホームページ (スペイン語)

http://es-es.example.com/ - スペインのユーザー向けバージョン (スペイン語)

http://es-mx.example.com/ - メキシコのユーザー向けバージョン (スペイン語)

http://en.example.com/ - 汎用的な英語バージョン

<link rel="alternate" hreflang="es" href="http://www.example.com/" /> <link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" /> <link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" /> <link rel="alternate" hreflang="en" href="http://en.example.com/" />
URL 単位困ったときはヘルプセンターウェブマスターヘルプフォーラムWritten by Christopher Semturs, Software Engineer, Search Infrastructure, Google Switzerland
Original version: New markup for multilingual content

スマートフォン版 Googlebot-Mobile の導入について

2011年12月15日木曜日

スマートフォンユーザの増加に伴い、最近ではスマートフォン用に最適化されたコンテンツを提供するサイトも増えてきました。そこでGoogleでは、従来の携帯電話（フィーチャーフォン）のユーザーエージェントを使用した Googlebot-Mobile に加えて、スマートフォンのユーザーエージェントを使用した Googlebot-Mobile によるクロールを開始しましたのでお知らせいたします。スマートフォン版 Googlebot-Mobile の導入により、より幅広くスマートフォン用コンテンツを収集して、スマートフォンユーザーのための検索サービスの改善に利用していきます。

現時点で Googlebot-Mobile が使用する主なユーザーエージェントは次の通りです。

従来型携帯電話版 Googlebot-Mobile

SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

スマートフォン版 Googlebot-Mobile

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 2013年10月更新: Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
2015 年 8 月更新: Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

スマートフォン版 Googlebot-Mobile により収集されたコンテンツは、主にはスマートフォン向け検索の品質向上に利用されますが、デスクトップ検索や他の検索モードの品質向上にも利用されることもあります。新しいクローラが収集する情報の例としては、スマートフォン用のコンテンツであるかどうかや、リダイレクトの情報などが挙げられます。

これらの情報を用いる新たな機能として「スマートフォン用ページのリダイレクトスキップ」があります。この機能は、スマートフォンをスマートフォン用コンテンツにリダイレクトするページについて、検索結果から直接スマートフォン用ページへリンクするというものです。この機能により、検索結果ページをロードする際、リダイレクトに起因して発生する平均0.5〜1秒の遅延を短縮することが可能となります。2013/8/13 追記: デスクトップ向けとスマートフォン向けで異なる URL を提供しているサイトにおいて、両者を正しく関係づける rel-alternate-media アノテーション（日本語で表示されない場合はページ右下の表示言語メニューから日本語を選択してください）が発見された場合、スマートフォン向け検索結果においては表示されるリンクを直接スマートフォン用 URL に書き換えることがあります。

Googlebot-Mobile が使用するすべてのユーザーエージェントは特定の機種を指すものとなっていますので、Googlebot-Mobile を特別扱いせず、フィーチャーフォンの Googlebot-Mobile はフィーチャーフォンとして、スマートフォンの Googlebot-Mobile はスマートフォンとして扱ってください。過去のブログポストで述べたガイドラインは、スマートフォンに関する記述を除いては有効です。Googlebot-Mobile が従来型の携帯電話のユーザーエージェントしか使用しないという前提に基づいて、Googlebot-Mobile を特別に扱っているサイトがあるかもしれませんが、この機会に Googlebot-Mobile に対する方針の見直しをおすすめいたします。

この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

2012/2/3 追記
* この記事に関するご質問をウェブマスターヘルプフォーラムで受け付け、スマートフォン版 Googlebot-Mobile に関する質問専用のスレッドでその回答を公開しております。ぜひこちらも合わせてご覧下さい。

Posted by 加藤義清 / ソフトウェア・エンジニア

Google カスタム検索エンジンがウェブマスターツール内で作成・管理できるようになりました

2011年12月9日金曜日

Google カスタム検索エンジン検索向け AdSenseウェブマスターツールウェブマスターヘルプフォーラムPosted by Sharon Xiao, Software Engineering Intern, and Ying Huang, Software Engineer
Original version: Create and manage Custom Search Engines from within Webmaster Tools

複数ページにまたがる記事やコンテンツをお持ちの方へ。rel=”next” と rel=”prev” を使用したページネーションのご紹介

2011年12月2日金曜日

rel=”canonical”rel=”next” と rel=”prev”

個々のページ / URL にあるリンクの効果などのインデックス対象の属性を、一連のページ全体のものとしてまとめること（つまり、page-1.html、page-2.html といった個々のページにあるリンクをばらばらの状態ではなく、一連のグループとして取り扱うこと）

最も関連性が高いページ / URL （通常は一連のコンテンツの最初のページ）にユーザーを誘導すること

rel=”next” と rel=”prev” を使うことによって、続きものになっているコンテンツの個々の URL 間の関係性を Google に示すことができます検索結果に『すべて表示』ページを優先的に表示する方法

「すべて表示」ページが含まれるページ構成については、ブログ記事の検索結果に「すべて表示」ページを優先的に表示する方法をご参照くださいウェブマスターの選択肢

特に何も対策はしない。複数ページに分割されたコンテンツがウェブ上に存在し、ページ内の HTML マークアップ rel=”next”、rel=”prev” の有無に関係なく、Google は最も関連性の高い検索結果を表示するよう努めます。

サイトに「すべて表示」ページがある場合、または「すべて表示」ページを設けようとしている場合は、検索結果に「すべて表示」ページを優先的に表示する方法を参照してください。

ひと続きになっているコンテンツを構成する個々の URL に rel=”next” と rel=”prev” を指定し、URL 間の関係性を Google に示す（このブログ記事で紹介している例です）。これによって Google はコンテンツのインデックス登録がより正確にできるようになり、最も関連性の高いページ（通常は最初のページ）をユーザーに表示するようになります。実装に関しては以下で詳しく説明します。

rel=”next” と rel=”prev” の実装方法<head><link rel="next" href="http://www.example.com/article?story=abc&page=2" /><link rel="prev" href="http://www.example.com/article?story=abc&page=1" /><link rel="next" href="http://www.example.com/article?story=abc&page=3" /><link rel="prev" href="http://www.example.com/article?story=abc&page=2" /><link rel="next" href="http://www.example.com/article?story=abc&page=4" />そして最後のページ http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

いくつか注意すべき点があります:

最初のページには rel=”next” マークアップのみ記述し、rel=”prev” マークアップは記述しない。
2 ページから、最後から 1 つ前のページまでは、rel=”next” と rel=”prev” のマークアップを両方とも記述する。
最後のページには rel=”prev” のみ記述し、rel=”next” は記述しない。
rel=”next” と rel=”prev” の値は、相対 URL または絶対 URL のどちらでもよい（ <link> タグに準じる）。また、ドキュメントにリンクを指定している場合は、そのベース URL に基づいて相対パスを指定する。
rel=”next” と rel=”prev” は、 <head> セクション内で宣言するだけでよく、ドキュメントの <body> 内で記述する必要はない。
rel=”previous” は、rel=”prev” リンクの構文上のバリエーションとして許容される。
rel="next" と rel="prev" を指定することと、rel="canonical" を指定することは、別々の概念である。よって、同一ページ内に両方の宣言を記述することが可能。たとえば、http://www.example.com/article?story=abc&page=2&sessionid=123 の中で、次のように記述してよい。

<link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/>
<link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />
rel=”prev” と rel=”next” は Google に対するヒントであり、絶対的な指示ではない。
rel="prev" や rel="next" を指定すべき箇所で指定していないなど、正しく実装されていない場合は、Google はこれまでと同様にページのインデックス登録を行い、コンテンツを把握する。

わからないことがある場合は？
詳しい情報は、ヘルプセンターを参照してください。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team
Original version: Pagination with rel=“next” and rel=“prev”

検索結果に「すべて表示」ページを優先的に表示する方法

2011年12月2日金曜日

ユーザーは、ページをめくることでロードの待ち時間が長くなる複数ページ構成より、1ページにすべてが表示されているコンテンツの方を好むことが多いただし、ロード時間が長いと「すべて表示」ページが敬遠される場合も検索結果表示の遅さにも不満続きもののコンテンツに関する最善策

サイトに「すべて表示」ページがある場合

Google では、コンテンツの「すべて表示」ページがある場合、そのページを検出しようとします。（それを構成する個々のページがある場合はそれらのページも同時に検出しようとします）ウェブマスターの皆さまには特に何もしていただく必要はありません。ただし、Google に対してより明確なシグナルを送りたい場合は、個々の構成ページにて rel=”canonical” に「すべて表示」ページを指定することで、一連のページを適切に検出する可能性を高めることができます。

rel=”canonical” にて、一連の URL に含まれるコンテンツをまとめた「すべて表示」ページ（例: page-all.html）を指定することができます

なぜこれでうまくいくのでしょうか？

図に示されているように、一連のコンテンツの 1 つである page-2.html は、canonical のターゲットに page-all.html を指定することができます。ユーザーがあるキーワードで検索をおこない、検索結果から page-all.html が選択された場合、仮にキーワードに最も関連しているのが page-2.html であったとしても、ユーザーは page-all.html の中で、page-2.html に含まれる目的の情報を得ることができます。

一方、page-2.html にて page-1.html を canonical に指定することは避けてください。page-1.htm には page-2.html のコンテンツが含まれていないためです。ユーザーの検索キーワードは page-2.html 上のコンテンツに関連性が高いことはあり得ますが、page-2.html の canonical に page-1.html が設定されていると、ユーザーは検索結果の中から page-1.html を選択することも考えられます。この場合、目的の情報に到達するために別のページに移動しなければならないという操作が発生します。それはユーザーにとって不便であると同時に、Google にとっても最適といえる結果ではなく、また、ターゲットのはっきりしないトラフィックをサイトに呼ぶことになりかねません。

ただし、「すべて表示」ページを検索結果に表示しないことを強く希望する場合は、1）一連のコンテンツの個々のページに「すべて表示」ページへの rel=”canonical” が設定されていないことを確認した上で、2）「すべて表示」ページに “noindex” を設定してください。（設定方法は一般的なもので問題ありません）

個々の構成ページを優先表示したい場合（または「すべて表示」ページがない場合）

サイトが下記の状況のいずれか（または両方）に当てはまるケースとなるでしょう。

「すべて表示」ページが検索結果に適さない（たとえばロード時間が長すぎる、ユーザーにとって操作が難しくなるためなど）
サイトのユーザーが複数ページ構成の方を好み、また検索結果に「すべて表示」ページではなく、個々のページの表示を望んでいる

このような場合は、標準的な HTML の rel=”next” と rel=”prev” 要素を指定して、一連のコンテンツの個々の構成ページ間の関係性を指定することができます。正しく指定されていれば、Google は通常、下記のような挙動をとります。

個々のページ/URL にあるリンクなどのインデックス属性を統合します。
個々のページのうち、最も関連性が高いページ/URL をユーザーに提供します。通常、コンテンツの最初のページですが、アルゴリズムによって、一連のコンテンツのいずれかのページを検索結果に表示する場合もあります。

個々のページにて、コンテンツの最初のページに対して rel=”canonical” を使用しているケース（たとえば page-2.html にて、rel=”canonical” に page-1.html を指定するなど）が見られますが、これらの個々のページには実際に重複コンテンツがあるわけではないため、このような指定はお勧めできません。rel=”next” と rel=”prev” を使用するのがより適切です。

まとめ

「すべて表示」ページを最適化する場合は、個々の構成ページにて rel=”canonical” を使用し、ターゲットに「すべて表示」ページを指定します。
あるいは、

サイトの「すべて表示」ページを使わない場合は、 rel=”next” と rel=”prev” 属性を使用し、Google が一連のページを識別した際に構成ページの方を検索結果に表示するよう明示します。

わからないことがある場合ウェブマスターヘルプフォーラムWritten by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team
Original version: View-all in search results

著作者情報のマークアップに対応しました

2011年11月24日木曜日

ヘルプ記事「著者情報」schema.org のマイクロデータPosted by Othar Hansson, Software Engineer
Original version: Authorship markup and web search

クロスドメイン URL の選択 - 複数のドメイン間の重複コンテンツの正規化について

2011年11月15日火曜日

重複コンテンツrel="canonical" 属性 301 リダイレクトクロスドメイン URL の選択不適切なクロスドメイン URL の選択がされる主な原因ガイドラインベストプラクティス

複数リージョン向けウェブサイトを含む重複コンテンツ：多くのウェブマスターの方が、ときには不注意で、そしてときにはユーザーの所在地によってコンテンツを提供するために、同じ言語でほぼ同一のコンテンツを複数ドメイン上で公開しています。たとえば、ウェブマスターが example.com と example.net の両方で英語の同一コンテンツを用意したり、example.de、example.at、example.ch で 1 つのドイツ語のウェブサイトをホストしたりすることは珍しくありません。

ウェブサイトの性質やユーザーに応じて、現在サポートされている正規化の方法のうちいずれかを用いて、代表 URL をアルゴリズムに通知することができます。詳細については以下の記事を参照してください。

設定ミス：一部の設定ミスによって、アルゴリズムが誤った選択を行うことがあります。例として以下のようなものがあります：

悪意のあるウェブサイトへの攻撃：ウェブサイトに対する攻撃の中には、勝手に正規化を行うコードを生成するものがあります。たとえば、サイトに HTTP 301 リダイレクトを返させるものや、HTML や HTTP ヘッダーにドメインをまたがった rel="canonical" リンク属性を挿入するものがあります。この場合は悪意のあるコンテンツをホスティングしている外部 URL を指すことが一般的です。このような例では、攻撃を受けたウェブサイトの URL ではなく、悪意のある URL やスパム URL がアルゴリズムに選択されてしまうことがあります。

このような場合、サイトがハッキングされた、またはマルウェアに感染した場合のガイドラインに従い、再審査リクエストを送信します。ウェブマスターツールの Fetch as Googlebot 機能を使用すると、Googlebot に見えているようにコンテンツを表示し、クローキングされた攻撃を検出できます。

DMCA (デジタルミレニアム著作権法) に基づく要求を提出するクロスドメイン URL の選択ウェブマスターヘルプフォーラムPosted by Pierre Far, Webmaster Trends Analyst
Original version: Raising awareness of cross-domain URL selections

多言語ウェブサイトの作成について

2011年11月9日水曜日

通常、多言語のウェブサイトを作成する意味があるのは、ターゲットユーザーの使用する言語が複数にわたっている場合です。Google の言語認識言語を認識しやすくするために、ページごとに使用する言語を統一すること、そして原文と訳文を一緒に表示しないことをおすすめします。サイトの多言語化を図る際には、検索結果に表示されるスニペットや URL などにも気を配る事が重要となります。多言語のサイトの分析: URL 構造enenfrfrオンラインの URL エンコーダmountain-bikesvélo-de-montagne%C3%A9多言語のウェブサイトのクロールとインデックス文字コードの使用ウェブマスターヘルプフォーラムWritten by Xavier deMorales, Google Search Quality
Original version: Working with multilingual websites

SSL 検索における検索クエリデータの取得方法について

2011年10月31日月曜日

急速に広まってhttps://www.google.comSSL 検索がデフォルトgoogle.co.jpHTTP リファラーフィールドウェブマスターツール豊富な検索クエリデータウェブマスターツールに追加した確認済みのサイト

過去 30 日間のデイリー検索クエリトップ 1,000 と、デイリーランディングページトップ 1,000 の表示。

表示回数、クリック数、クリックスルー率（CTR）の表示。また、各クエリの検索結果における平均掲載順位を直近 30 日間で比較。

CSV 形式でのデータのダウンロード。

Google アナリティクスウェブマスターツールと同様の検索クエリデータウェブマスターヘルプフォーラムPosted by Anthony Chavez, Product Manager
Original version: Accessing search query data for your sites

ウェブマスターツールの検索クエリのデータが Google アナリティクスから利用可能になりました

2011年10月31日月曜日

検索クエリパイロットベータの募集

検索クエリ: 1 日あたり上位 1,000 件のクエリに対するインプレッション数、クリック数、掲載順位、クリックスルー率（CTR）の情報

ランディングページ: 1 日あたり上位 1,000 件のランディングページに対するインプレッション数、クリック数、掲載順位、CTR の情報

地域別サマリー: 国ごとのインプレッション数、クリック数、CTR

ウェブマスターヘルプフォーラムPosted by Christina Chen, Product Manager
Original version: Webmaster Tools Search Queries data is now available in Google Analytics

パラメータ付き URL 処理の新機能

2011年10月28日金曜日

機能の概要

新機能の詳細

Googlebot が決定

すべての URL

値が指定されている URL のみ

クロールしない

事例

パラメータ名

コンテンツへの影響

Googlebot がクロールする対象

trackingId

なし

代表的な URL 1 つ

sortOrder

並べ替え

値が「lowToHigh」に指定されている URL のみ

sortBy

並べ替え

値が「price」に指定されている URL のみ

filterByColor

絞り込み

クロールしない

itemId

コンテンツ指定

すべての URL

page

ページ指定

すべての URL

助手ウェブの魔法使い

fairyclothes.example.com/skirts/?trackingId=aaa123

fairyclothes.example.com/skirts/?trackingId=aaa124

fairyclothes.example.com/trousers/?trackingId=aaa125

助手ウェブの魔法使い

fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’

fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’highToLow’

fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’lowToHigh’

fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’

fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

助手ウェブの魔法使い助手ウェブの魔法使い

fairyclothes.example.com/skirts/?page=1

fairyclothes.example.com/skirts/?page=2

fairyclothes.example.com/skirts/?page=3

fairyclothes.example.com/skirts/?page=1&flterByColor=blue

fairyclothes.example.com/skirts/?page=2&flterByColor=blue

URL パラメータウェブマスターヘルプフォーラムWritten by Kamila Primke, Software Engineer, Webmaster Tools Team
Original version: Improved handling of URLs with parameters

再審査リクエストへの回答が、より具体的になりました

2011年10月20日木曜日

ウェブマスター向けガイドライン再審査をリクエスト再審査リクエストの受付通知スパムウェブマスターヘルプフォーラム『不自然なリンクに関する Google ウェブマスターツールからのお知らせ』を受け取った際に確認をおすすめするポイントサイトの掲載順位が上がらない理由Posted by Tiffany Oberoi and Michael Wyszomierski, Search Quality Team
Original version: Reconsideration requests get more transparent

サイトの状態が一目で確認できるようになりました。

2011年10月13日木曜日

サイトでマルウェアが検出されていないか

URL 削除ツールによって重要なページが削除されていないか

robots.txt にて、クロールがブロックされている重要なページがないか

ウェブマスターヘルプフォーラムPosted by Susan Moskwa, Webmaster Trends Analyst
Original version: Work smarter, not harder, with site health

ウェブマスターヘルプフォーラムからも参加！グローバルトップレベルユーザーサミット 2011 のご報告

2011年10月2日日曜日

グローバルトップレベルユーザーサミット 2011ヘルプフォーラムウェブマスターヘルプフォーラム

サミットに参加された日本のトップレベルユーザーの皆様（左から 4 名）と Google 社員グローバルトップレベルユーザーサミット 2011 のご報告トップレベルユーザーサミットのご報告 & そもそもトップレベルユーザーとは？ウェブマスターヘルプフォーラムPosted by サーチクオリティチーム

災害時、急激なアクセス集中に備えてウェブマスターができること

2011年9月29日木曜日

軽量化したサイトを別途用意する
災害時に備え、軽量化したサイトをあらかじめ別途用意しておきましょう。災害時にはその軽量化したサイトに置き換えます。しかし普段は使わないページを用意し、いざという時のために管理し続けるというのは負担が大きいかもしれません。そこで例えば携帯電話向けのサイトを用意し、災害時には携帯電話向けに提供しているページを PC 向けに提供するのもひとつのアイディアです。また、特にアクセスが集中するのは主にトップページであるケースが多いのではないでしょうか。そこで全ての代替ページを用意するのではなく、トップページのみ軽量化したページを用意しておき、リンク先は携帯電話向けのページにリンクするようにすることで、災害時にはトップページのみ差し替えるだけで大幅にサーバーの負荷を軽減することができます。

軽量化のポイントは、

画像やフラッシュなどの装飾的な要素は極力外し、メニューやナビゲーションなどの画像ファイルはテキストに置き換え、HTML を中心に作成する。
動的なページはサーバーの負荷が高いため静的な HTML ページを用意する（情報は手動で更新します）。

なるべく軽いファイル形式で提供する
データのサイズはなるべく小さくなるように心がけましょう。例えば提供する情報が文字情報の場合、ファイルサイズが大きくなる PDF ファイルなどでの情報の提供は避け、テキストデータなどの軽いデータで提供するようにしましょう。例えばこちらの PDF ファイルとリッチテキストファイルをダウンロードして比較してみてください。中身はほぼ同じ内容ですが、ファイルサイズは PDF が 180KB、テキストファイルは 37KB と、テキストファイルの方が圧倒的に軽いことがわかります。

また、同じ PDF ファイルでも、画像データから作成した PDF よりも、テキストエディタ等からテキストデータを保持したまま作成した PDF の方がデータが軽くなります。また、テキストデータを保持したまま作成された PDF は検索結果に表示されやすくなりますので PDF を作成する際は画像データから作成するのではなく、テキストデータを保持した形で作成することをお勧めします。

表や数値データは CSV や XML などの形式でも用意する
表や数値データは CSV や XML 形式のファイルでも用意しましょう。これらの形式のファイルは、比較的サイズが小さくなり、また、そのデータを利用して外部の開発者が別の災害情報サービスを提供することが可能になり、より多くの人に情報を届けることができるようになるためです。

サードパーティのサービスを活用する
サードパーティのサービス等を利用し、災害時に参照される情報を中心にミラーサイトを作成することも一つの方法です。Google では Google サイトや Blogger といったサービスを無料でご利用いただくことが可能です。

こちらからウェブマスターヘルプフォーラムPosted by Google クライシスレスポンスチーム、サーチクオリティチーム

ページスピードサービス - ウェブパフォーマンスを高速化

2011年9月25日日曜日

ページスピードブラウザ拡張機能（英語） Page Speed Online API（英語）mod_pagespeed（英語）ページスピードサービス（英語）概ねのサイトで 25% から 60%（英語）測定（英語）ページスピードサービスにお申し込み（英語）こちらのウェブフォーム（英語）Posted by Ram Ramani, Engineering Manager
Original version: Official Google Webmaster Central Blog: Page Speed Service - Web Performance, Delivered.

検索結果における PDF ファイルの取り扱いについてのヒント

2011年9月19日月曜日

2001 年に PDF ファイルのインデックス登録を開始数億件もの PDF ファイルがインデックスに登録されています質問: Google では、どんな形式の PDF ファイルでもインデックス登録できるのですか？ OCR質問: PDF ファイル内の画像はどうなるのですか？ヘルプセンター質問: PDF 文書内のリンクはどのように取り扱われるのですか？ nofollow質問: PDF ファイルを検索結果に表示させないようにするにはどうしたらいいですか？既に検索結果に表示されている場合は、どのようにしたら削除できますか？ URL 削除ツール質問: PDF ファイルでも検索結果の上位にランクされますか？mortgage market reviewirs form 2011paracetamol expert report質問: ページを HTML と PDF の両方の形式で提供していると、重複コンテンツと見なされるのでしょうか？ HTTP ヘッダー正規化質問: 検索結果に表示される PDF 文書のタイトルはカスタマイズできますか？ PDF ファイルを検索用に最適化するヘルプセンターウェブマスターヘルプフォーラムPosted by Gary Illyes, Webmaster Trends Analyst
Original version: PDFs in Google search results

Google Chrome でサイトをうまく表示する方法

2011年9月11日日曜日

Google Chrome を検出するためにはWebKitChrome 11 におけるユーザーエージェント文字列の変更 - Google Japan Developer Relations Blogwebkit.orgその他のヒント

Google Chrome は Active X プラグインをサポートしていませんが、NPAPI プラグインはサポートしています。つまり、Google Chrome では Firefox や Safari と同じように Flash や Java といったプラグインのコンテンツを見せることができます。

もしあなたのサイト上のテキストがうまく表示されていない場合は、適切なコンテンツタイプと文字コードの情報を HTTP レスポンスヘッダーもしくはページの始めやセクションのなるべくトップに近いところで記載していることを確認してください。

ブロックレベル要素をインライン要素の中に書かないようにしましょう。

誤った例: <a><div>こちらは正しく表示されません。</div></a>
正しい例: <div><a>こちらは正しく表示されます。</a></div>

もし JavaScript が Google Chrome でうまく動かないようでしたら、Chrome に組み込まれている JavaScript ツールやデベロッパーツールを使ってデバッグを行うことができます。

あなたのページで使っている文字セットは Official IANA LIst に準拠している必要があります。表の preferred MIME name の名前をご使用ください。
例: ISO-8859-1, Shift_JIS

HTTP Header と Meta tag で異なる文字エンコーディングを指定している場合、Google Chrome は、HTTP Header の指定を優先的に使用します。HTTP Header と Meta tag で異なる文字エンコーディングを指定することはトラブルの原因になります。詳しい情報は、The WHATWG Blog — The Road to HTML 5: character encoding（英語）を御覧ください。

基本的に文字エンコーディングは UTF-8 を使用されることをお勧めしています。何らかの理由により、旧来の文字エンコーディングを使用する必要がある場合は、これまでご紹介した内容を踏まえているかをご確認の上使用してください。

ウェブマスターヘルプフォーラムWritten by Glenn Wilson, Product Manager, Google Chrome
Original version: Helping your site look great with Google Chrome

ウェブマスターツールの内部リンクと外部からのリンクの取り扱いを変更しました

2011年9月8日木曜日

外部のサイトからのリンクサイト内からのリンクウェブマスターツール

www.google.com へのリンク

外部リンク

内部リンク

従来のカテゴリ分けでは...

www.example.com/
www.example.org/stuff.html
scholar.google.com/
sketchup.google.com/
google.com/

www.google.com/
www.google.com/stuff.html
www.google.com/support/webmasters/

新しいカテゴリ分けでは...

www.example.com/
www.example.org/stuff.html

scholar.google.com/
sketchup.google.com/
google.com/
www.google.com/
www.google.com/stuff.html
www.google.com/support/webmasters/

googlejapan.blogspot.comwww.google.com/support/webmasters/ウェブマスターヘルプフォーラムPosted by Susan Moskwa, Webmaster Trends Analyst
Original version: Reorganizing internal vs. external backlinks

ウェブサイトがハッキングされた、さあどうする？ - サイトがハッキングされた場合の対応方法

2011年8月31日水曜日

サイトがハッキングされた、またはマルウェアに感染した場合Google ウェブマスターツールQuick Security Checklistサイトをオフラインにする

サイトを一時的に、少なくとも問題を解決できたと確信できるまでは、オフラインにします（ネットワークから切り離します）。*

オフラインにできない場合は、クロールされないように 503 ステータスコードを返すよう設定します。

ウェブマスターツールの URL 削除ツールを使用して、侵入者によって追加された可能性のあるページや URL を検索結果から削除します。こうすることで、ユーザーがハッキングされたページを閲覧してしまうことを防ぎます。

被害を分析する

ハッカーの侵入目的が何だったのかを把握することは重要です。

狙いは機密情報でしょうか？
他の目的のためにサイトを乗っ取ろうとしたのでしょうか？

ウェブサーバー上で、改変またはアップロードされたファイルを探しましょう。

サーバーログから、ログイン認証の失敗、コマンドの履歴（特に root で実行されたコマンド）、不明なユーザーアカウントなどの不審な活動をチェックしましょう。

被害の範囲を特定します。他にも影響を受けたかもしれないサイトはありませんか？

復旧する

最善策は、信頼できるソースから OS を完全に再インストールすることです。ハッカーによる被害をすべて確実に取り除くには、これ以外に方法はありません。*

再インストールが完了したら、最新のバックアップを使用してサイトを復旧します。この際、バックアップがハッキングの影響を受けていないことを必ず確認しましょう。*

インストールされたソフトウェアにパッチを当てて最新版にします。ブログプラットフォーム、コンテンツマネージメントシステムや、その他サードパーティによるソフトウェアなどすべてが対象となります。

パスワードを変更します。

オンラインへの復帰

ウェブサイトを再びオンラインにします。

ウェブマスターツールを使用している場合は、

サイトにマルウェアが存在すると検知された場合は、これらが排除されたかどうかを判断するために調査を申請してください。詳しい情報はヘルプ記事「サイトがハッキングされた、またはマルウェアに感染した場合」の「4: Google にサイトの再審査を依頼する」をご覧ください。
インデックスに入れたい URL に対して URL 削除ツールを使用した場合は、ウェブマスターツールで削除を取り消してください。

ハッカーが再びサイトを攻撃する可能性がありますので、不審な動きに注意してください。

ヘルプ記事

サイトが Google によってマルウェアに感染していると検知された場合、ウェブマスターツールのページに警告メッセージを表示しますので、あらかじめウェブマスターツールに登録しておくことを強くお勧めします。

Matt Cutts がブログに投稿した「Three tips to protect your WordPress installation」（英語）という記事にも実用的なコメントが多く寄せられています。

ウェブマスターヘルプフォーラムWritten by Nathan Johns, Search Quality Team
Original version: My site's been hacked - now what?

リニューアルされたサイトリンクのご紹介

2011年8月24日水曜日

サイトリンクをアップデート

見やすく：リンクのテキストはフルサイズになり、通常の検索結果と同様に、緑色のURLおよび 1 行のスニペットが追加で表示されます。これによって、個々のサイトリンクおよびメインのサイトがより目立つことになり、検索ユーザーの目に止まりやすくなります。

柔軟に：これまで、各サイトのサイトリンクのセットは固定されており、それら全てが表示される、もしくは全く表示されないの二者択一で、特定の検索ワードによってこの一覧の表示順が変動することはありませんでした。今回のアップデートで、表示されるサイトリンクおよびその表示順は検索ワード次第で変動するようになり、より最適な検索結果を提供できるようになりました。更に、サイトリンクの最大表示数が 8 から 12 に引き上げられ、表示される数も検索ワード次第で変化するようになりました。

わかりやすく：これまでは、サイトリンクが表示されているサイト内のページがサイトリンクだけでなく、サイトリンクが表示されていない残りの検索結果にも表示されるといった事がありました。今回のアップデートで、サイトリンクが表示されたドメインとその他のドメインの区別が、より明確にされるようになり、サイトリンクが検索結果トップに表示された場合、その下に表示される残りの検索結果はその他のドメインからのものとなります。例外は、ある検索ワードの検索結果トップが、あるドメインのサブページである場合です。例えば［the met exhibitions］と検索した場合、www.metmuseum.org/special/ が検索結果トップとして表示されます。ここで表示されるサイトリンクは、 www.metmuseum.org/special 以下等から抽出されます。その一方で、残りの検索結果は他のドメインのページが表示されますが、store.metmuseum.org や blog.metmuseum.org/alexandermcqueen/about のような、metmuseum.org ドメイン内のその他のページが残りの検索結果に表示される場合があります。

品質の改善：これらユーザーの目に見える変更と同時に、目に見えない改善も図りました。具体的には、サイトリンクを生成したり順位付けしたりするためのデータ（ウェブサイトのリンク構成など）を従来のランキングシステムと統合して、より優れたアルゴリズムにしました。それによって、順位付けの観点から見て、「通常の」検索結果とサイトリンクの間に区別はなくなりました。

今回のアップデート実施後のサイトリンクGoogle ウェブマスターツールウェブマスターツールヘルプウェブマスターヘルプフォーラムWritten by Harvey Jones, Software Engineer, & Raj Krishnan, Product Manager, Sitelinks team

Original version: Introducing new and improved sitelinks

Fetch as Googlebot ツールを使って Google へ URL の送信が可能になりました。

2011年8月17日水曜日

URL の送信方法

サイトマップオーナーの確認をせずに URL を Google へ送信する方法URL のクロールフォーム

URL のクロールフォームウェブマスターツールウェブマスターヘルプフォーラムWritten by Jonathan Simon & Susan Moskwa, Webmaster Trends Analysts
Original version: Official Google Webmaster Central Blog: Submit URLs to Google with Fetch as Googlebot

Google プレイスに登録できるお店やサービスとは

2011年8月10日水曜日

Google アカウントGoogle プレイス連載Google プレイスに登録できるお店やサービス品質ガイドライン

Google マップに表示されるビジネスリスティングの例Google プレイスに登録できないお店やサービス

インターネットのみで営業しており、顧客が直接訪問できる店舗が存在しないネットショップ

実際の住所が存在しないお店やサービス（自宅のリビング、パラグライダーの講習を実施する飛行場、急流くだりツアーを行う河川などは、お店やサービスの住所としての要件を満たしません。）

特定の住所を持たないお店やサービス（農作物の路面販売、移動式のホットドッグ屋台、またはカフェやレストランにおける 1 回きりのコンサートなど）

物件として実際の住所は存在するが、顧客が直接訪問してもその場で契約できないサービス（不動産会社による紹介物件のリスティング登録など）

Google AdWordsGoogle プレイスに登録する方法（ビジネスリスティングの作成）こちら

こちらサービス提供地域を指定する方法

ヘルプセンター作成されたリスティングの認証方法Google プレイスヘルプフォーラムPosted by Lina Paczensky, Local Search Quality

Original version: Google LatLong: Tips for creating a free business listing in Google Places: business types

PageRank をこえて ― より実用的な指標へ

2011年8月9日火曜日

Google アラート自分の投稿したフォーラムでの発言ブログ記事Twitter でのつぶやきウェブマスターツールから PageRank データの表示を削除なぜ PageRank ばかりが注目されているのか？Google 公式ブログテクノロジーの概要本来の目的は何か？ツールバー上に表示されている PageRank が下げられることがあるPageRank に替わる指標は何か？Google アナリティクスウェブマスターツール

コンバージョン率

直帰率

クリック率 (Click-through rate: CTR)

コンバージョン率直帰率直帰率クリック率 (CTR)検索エンジン最適化 ( SEO ) スターターガイドHTML のヒントAvinash Kaushik 氏のサイト意図的に PageRank を操作する目的でリンクを売買することは Google のウェブマスター向けガイドラインの違反Google が有料リンクを信頼しない理由有料リンクでガイドライン違反にならないためにウェブマスターヘルプフォーラムPosted by Susan Moskwa, Webmaster Trends Analyst
Original version: Beyond PageRank: Graduating to actionable metrics

schema.org のご紹介: より便利なインターネットのための検索エンジンの取り組み

2011年8月4日木曜日

※schema.org人物レビューリッチスニペットを導入しましたショッピングと商品イベントレシピ

サイトマッププロトコル1) schema.org では新しいマークアップを数多くご紹介しています

作品: CreativeWork、Book、Movie、MusicRecording、Recipe、TVSeries

テキスト以外の組み込みオブジェクト:AudioObject、ImageObject、VideoObject

Event

Organization

Person

Place、LocalBusiness、Restaurant

Product、Offer、AggregateOffer

Review、AggregateRating

schema.org の全マークアップの一覧2) schema.org は microdata を使用していますガイド3) 引き続き、既存のリッチスニペットマークアップのフォーマットにも対応します4) リッチスニペットのテストツールでマークアップをテストしましょうリッチスニペットテストツールschema.orgschema.org FAQBy Kavi Goel and Pravir Gupta, Search Quality team
Original version: Introducing schema.org: Search engines come together for a richer web

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

2011 年もありがとうございました！ウェブマスターヘルプフォーラムから感謝をこめて

多言語コンテンツのマークアップのヒント

スマートフォン版 Googlebot-Mobile の導入について

Google カスタム検索エンジンがウェブマスターツール内で作成・管理できるようになりました

複数ページにまたがる記事やコンテンツをお持ちの方へ。rel=”next” と rel=”prev” を使用したページネーションのご紹介

検索結果に「すべて表示」ページを優先的に表示する方法

著作者情報のマークアップに対応しました

クロスドメイン URL の選択 - 複数のドメイン間の重複コンテンツの正規化について

多言語ウェブサイトの作成について

SSL 検索における検索クエリデータの取得方法について

ウェブマスターツールの検索クエリのデータが Google アナリティクスから利用可能になりました

パラメータ付き URL 処理の新機能

再審査リクエストへの回答が、より具体的になりました

サイトの状態が一目で確認できるようになりました。

ウェブマスターヘルプフォーラムからも参加！グローバルトップレベルユーザーサミット 2011 のご報告

災害時、急激なアクセス集中に備えてウェブマスターができること

ページスピードサービス - ウェブパフォーマンスを高速化

検索結果における PDF ファイルの取り扱いについてのヒント

Google Chrome でサイトをうまく表示する方法

ウェブマスターツールの内部リンクと外部からのリンクの取り扱いを変更しました

ウェブサイトがハッキングされた、さあどうする？ - サイトがハッキングされた場合の対応方法

リニューアルされたサイトリンクのご紹介

Fetch as Googlebot ツールを使って Google へ URL の送信が可能になりました。

Google プレイスに登録できるお店やサービスとは

PageRank をこえて ― より実用的な指標へ

schema.org のご紹介: より便利なインターネットのための検索エンジンの取り組み

ラベル

アーカイブ

Feed

Blogs officiels Google

Blogs Webmaster en :

日本版 Google Blog 関連