ウェブマスター向け公式ブログ
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報
災害時、急激なアクセス集中に備えてウェブマスターができること
2011年9月29日木曜日
台風や大雨、地震などの災害時には多くの方が災害情報や交通情報、避難所や防災マップといった緊急情報を確認するため、特定のサイトに突発的にアクセスが集中することがあります。こうした急激なアクセスの集中は、時にサーバーの処理能力を超え、サイトをダウンさせてしまいます。サイトがダウンしてしまうと、災害情報などの緊急情報を提供できなくなり、より多くの混乱を引き起こしてしまうでしょう。
突発的なアクセスの集中は避けることは難しいですが、あらかじめそれに備えることでサイトのダウンを防ぐことが可能です。そこで今回は、災害時などの急なアクセス集中に備えてできる比較的簡単な対策をご紹介したいと思います。
軽量化したサイトを別途用意する
災害時に備え、軽量化したサイトをあらかじめ別途用意しておきましょう。災害時にはその軽量化したサイトに置き換えます。しかし普段は使わないページを用意し、いざという時のために管理し続けるというのは負担が大きいかもしれません。そこで例えば携帯電話向けのサイトを用意し、災害時には携帯電話向けに提供しているページを PC 向けに提供するのもひとつのアイディアです。また、特にアクセスが集中するのは主にトップページであるケースが多いのではないでしょうか。そこで全ての代替ページを用意するのではなく、トップページのみ軽量化したページを用意しておき、リンク先は携帯電話向けのページにリンクするようにすることで、災害時にはトップページのみ差し替えるだけで大幅にサーバーの負荷を軽減することができます。
軽量化のポイントは、
画像やフラッシュなどの装飾的な要素は極力外し、メニューやナビゲーションなどの画像ファイルはテキストに置き換え、HTML を中心に作成する。
動的なページはサーバーの負荷が高いため静的な HTML ページを用意する（情報は手動で更新します）。
なるべく軽いファイル形式で提供する
データのサイズはなるべく小さくなるように心がけましょう。例えば提供する情報が文字情報の場合、ファイルサイズが大きくなる PDF ファイルなどでの情報の提供は避け、テキストデータなどの軽いデータで提供するようにしましょう。例えばこちらの
PDF ファイル
と
リッチテキストファイル
をダウンロードして比較してみてください。中身はほぼ同じ内容ですが、ファイルサイズは PDF が 180KB、テキストファイルは 37KB と、テキストファイルの方が圧倒的に軽いことがわかります。
また、同じ PDF ファイルでも、画像データから作成した PDF よりも、テキストエディタ等からテキストデータを保持したまま作成した PDF の方がデータが軽くなります。また、
テキストデータを保持したまま作成された PDF は検索結果に表示されやすくなります
ので PDF を作成する際は画像データから作成するのではなく、テキストデータを保持した形で作成することをお勧めします。
表や数値データは CSV や XML などの形式でも用意する
表や数値データは CSV や XML 形式のファイルでも用意しましょう。これらの形式のファイルは、比較的サイズが小さくなり、また、そのデータを利用して外部の開発者が別の災害情報サービスを提供することが可能になり、より多くの人に情報を届けることができるようになるためです。
サードパーティのサービスを活用する
サードパーティのサービス等を利用し、災害時に参照される情報を中心にミラーサイトを作成することも一つの方法です。Google では
Google サイト
や
Blogger
といったサービスを無料でご利用いただくことが可能です。
また、万が一サイトがダウンした場合でも Google では公的なサービスを提供するサイトについてはキャッシュデータを検索結果に表示し、ユーザーが閲覧できるようにしています。このサービスへのご登録は、
こちらから
お申し込みください。なお、こちらのご登録に関しましては、 go.jp ドメインのサイトや地方公共団体、各種公共サービスなど、公共性の高い非営利サイトに限らせていただきます。また、お申し込みからご登録まで少々お時間がかかりますのでご了承ください。
今回ご紹介しました対策についてのご質問は、
ウェブマスター ヘルプ フォーラム
へお寄せください。※災害時の問い合わせ窓口ではありませんのでご注意ください。
Posted by Google クライシスレスポンスチーム、サーチ クオリティ チーム
ページ スピード サービス - ウェブ パフォーマンスを高速化
2011年9月25日日曜日
2 年前、Google は
ページ スピード ブラウザ拡張機能（英語）
をリリースし、今年に入ってからは
Page Speed Online API（英語）
をリリースしました。これらを通して、デベロッパーの皆さまにウェブページ高速化のための具体的な提案を行っています。昨年には、
mod_pagespeed（英語）
という Apache モジュールをリリースしました。これは、自動的にウェブページを書き換えるものです。ウェブマスターの皆さまのさらなる負担の軽減と、面倒なインストール作業を不要にするために、ページ スピード関連の最新のテクノロジーである
ページ スピード サービス（英語）
をリリースしました。
ページ スピード サービスとは、ウェブページの読み込みを自動的に高速化するオンライン サービスです。このサービスを使用するには、お申し込みのうえ、サイトの DNS エントリが Google を指すように設定していただく必要があります。ページ スピード サービスによって、ウェブ サーバーからコンテンツが読み取られ、ウェブ パフォーマンス向上のためのベスト プラクティスが適用されたページに書き換えられます。この書き換えられたページが、世界中の Google のサーバーを経由してエンド ユーザーに提供されます。ウェブサイトのユーザーから見ると、サイトへのアクセス方法はそれまでと同じですが、ページの読み込みが高速になります。これで、ウェブマスターの皆さまは CSS の短縮化や、画像圧縮、キャッシング、gzip によるリソース圧縮などのウェブ パフォーマンス向上のためのベスト プラクティスに悩む必要はなくなります。
Google が実施した高速化のテストでは、
概ねのサイトで 25% から 60%（英語）
の改善が実証されています。ただし、効果はサイトごとに異なるので、皆さまのサイトが実際にページ スピード サービスによってどれだけ高速化されるかを
測定（英語）
してみてください。この結果を見て、十分な効果が期待できるようであれば、こちらから
ページ スピード サービスにお申し込み（英語）
ください。そうでない場合は、しばらくしてからもう一度測定してみてください。Google では今後も、このサービスに改善を加えていく予定です。
現時点では、ページ スピード サービスは少数のウェブマスター様のみにご提供しています（無料）。手頃な料金でご利用いただけるようにする予定であり、詳細は後日発表いたします。このサービスへのアクセスをご希望の場合は、
こちらのウェブ フォーム（英語）
からお申し込みください。
Posted by Ram Ramani, Engineering Manager
Original version:
Official Google Webmaster Central Blog: Page Speed Service - Web Performance, Delivered.
検索結果における PDF ファイルの取り扱いについてのヒント
2011年9月19日月曜日
Google の使命は、世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることです。この使命を遂行するなかで、時として HTML 形式以外のファイル、たとえば PDF、表計算、プレゼンテーション用スライドといった形式のファイルに遭遇することがあります。ファイル形式が違うからといって、Google のアルゴリズムに支障が生じることはありません。Google では、関連性の高いコンテンツを抽出し、適切なインデックス登録を行って検索結果に反映させるよう取り組んでいます。このようなファイル形式は、標準的な HTML 形式とは大きく異なるものですが、実際にはどのようにインデックス登録されているのか、どういったガイドラインが設けられているのか、そしてファイルをインデックスに登録して欲しくない場合には、ウェブマスターの皆様はどうしたらよいか、ご存知でしょうか？
Google は
2001 年に PDF ファイルのインデックス登録を開始
（英語）し、現在では
数億件もの PDF ファイルがインデックスに登録されています
。今回は、PDF のインデックス登録に関して、よく寄せられる質問とその回答をまとめてみました。
質問: Google では、どんな形式の PDF ファイルでもインデックス登録できるのですか？
答え:一般的に、各種文字コードを使用した PDF ファイルに含まれているテキスト コンテンツは、どのような言語で書かれていようと、そのファイルがパスワード保護または暗号化されている場合を除き、インデックスに登録できます。テキストが画像として埋め込まれている場合は、Google ではその画像を
OCR
（英語）アルゴリズムで処理し、テキストを抽出することができます。簡単に言うと、PDF 文書内のテキストをコピーして、標準的なテキスト文書にペーストできるのであれば、そのテキストはインデックス登録が可能です。
質問: PDF ファイル内の画像はどうなるのですか？
答え: 現時点では、PDF ファイル内の画像はインデックスには登録されません。画像をインデックス登録するには、その画像用の HTML ページを作成する必要があります。ご自分のサイトの画像が検索結果に含まれる可能性を高めたい場合は、
ヘルプ センター
に記述されているアドバイスを参考にしてください。
質問: PDF 文書内のリンクはどのように取り扱われるのですか？
答え: 一般に、PDF ファイル内のリンクは HTML 内のリンクと同じように扱われます。つまり、リンクから PageRank をはじめとするインデックス登録のシグナルが渡されるので、Google は、その PDF ファイルをクロールしたのち、リンクをフォローできるようになります。現在のところ、PDF ファイル内のリンクに対しては
nofollow
属性は設定できません。
質問: PDF ファイルを検索結果に表示させないようにするにはどうしたらいいですか？既に検索結果に表示されている場合は、どのようにしたら削除できますか？
答え: PDF 文書を検索結果に表示させないようにする一番簡単な方法は、そのファイル用の HTTP ヘッダーに X-Robots-Tag: noindex を追加するという方法です。既にインデックスに登録されている場合は、X-Robot-Tag で noindex を指定すれば、しばらく時間が経つとインデックスから除外されていきます。早急に削除したい場合は、Google ウェブマスター ツールの
URL 削除ツール
を使用してください。
質問: PDF ファイルでも検索結果の上位にランクされますか？
答え: もちろんです。通常、他のウェブサイトと同じようにランキングされます。たとえば、[
mortgage market review
]、[
irs form 2011
]、[
paracetamol expert report
] で検索してみると、いずれも検索結果の上位に P
DF 文書が表示されます（注: この記事の作成時点）。 これは、文書の内容と、サイトへの埋め込み方法、そして他のウェブページからのリンク状況に基づいた結果です。
質問: ページを HTML と PDF の両方の形式で提供していると、重複コンテンツと見なされるのでしょうか？
答え: できれば、コンテンツは 1 つだけにすることをお勧めします。それが難しい場合は、どちらのバージョンを優先するのかを必ず示すようにしてください。その方法としては、サイトマップに優先 URL を含める方法や、HTML 内または PDF 文書の
HTTP ヘッダー
内で canonical （優先）バージョンを設定する方法などがあります。詳しくは
正規化
に関するヘルプ センターの記事を参照してください。
質問: 検索結果に表示される PDF 文書のタイトルはカスタマイズできますか？
答え: 表示するタイトルの生成には、ファイル内のタイトル メタデータとその PDF ファイルを指すリンクのアンカー テキストという 2 つの主要要素を使用しています。Google のアルゴリズムに対して、適切なタイトルを示したい場合は、上記要素を両方ともアップデートすることをお勧めします。
詳しくは、Matt Cutt による動画
PDF ファイルを検索用に最適化する
（英語）をご覧ください。また、インデックスに登録できるコンテンツ形式については、
ヘルプ センター
でご確認いただけます。ご質問やご意見がありましたら、
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by Gary Illyes, Webmaster Trends Analyst
Original version:
PDFs in Google search results
Google Chrome でサイトをうまく表示する方法
2011年9月11日日曜日
Google Chrome が 2008 年 9 月にリリースされて以降、すでに多くの皆様に利用していただけるようになっておりますが、残念ながらいくつかのサイトが正しく表示されないという声がまだ聞かれます。サイトが正しく表示されないのは、もちろん Google Chrome 側の不具合が原因であることもありますが、一方でサイトがある特定のブラウザだけを対象にしている場合や Web 標準に沿わない形でサイトがデザインされていることもあります。
今までに、どうしたら Google Chrome でサイトを正しく表示させられるのか、ということに関してたくさんの質問がウェブマスターやデベロッパーのみなさんから寄せられました。今回は、このためのヒントをいくつかご紹介します。
Google Chrome を検出するためには
多くの場合、Safari と Google Chrome でサイトは同じように見えます。なぜならこれらは両方とも
WebKit
（英語）ベースのブラウザだからです。もしあなたのサイトが Safari で正しく表示されているのなら、Google Chrome でも同様に正しく表示 されるはずです。
サイトによっては Chrome が他のブラウザと混同されてしまうことも少なくありません。Safari では正しく表示されているサイトが Chrome で正しく表示されないのならば、そのサイトが Chrome のユーザー エージェント文字列を認識していない可能性があります。
Google Chrome のユーザー エージェント文字列は次のようになります。
Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/W.X.Y.Z Safari/534.24
Chrome 11 におけるユーザー エージェント文字列の変更 - Google Japan Developer Relations Blog
で紹介したように、Chrome 11 より変更になっていますので、ご注意ください。
ユーザー エージェントのタイプを検出したいのであれば、次の JavaScript が WebKit での検出に使えるでしょう。
var isWebkit =
navigator.userAgent.indexOf("AppleWebKit") > -1;
そうではなく、もし WebKit が特定のバージョン以上であることを確認したいのならば、以下の新しい機能が使えるでしょう。
var webkitVersion =
parseFloat(navigator.userAgent.split
("AppleWebKit/")[1]) ||
undefined;
if (webkitVersion && webkitVersion > 500 ) {
// WebKitの素晴らしい機能を使う
}
Google Chrome が利用している WebKit のバージョンは Ominibox に “about:version” と入力することで得ることができます。
一般的に、WebKit や Google Chrome を検出するために "Google" や "Apple" といった文字列を navigator.vendor に加えることはお勧めしません。なぜならそうしてしまうと、他の Webkit や Chromium をベースとしたブラウザを検出できなくなってしまうからです！
WebKit の検出の詳細については、
webkit.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日木曜日
ウェブマスター ツールではサイトへのリンクを、
外部のサイトからのリンク
と
サイト内からのリンク
の 2 種類に分類していますが、この度
ウェブマスター ツール
内のリンク データのカテゴリ分けを変更しました。今回の変更によって、リンクの合計数が変わることはありませんが、どれがサイト内からのリンクで、どれが外部のサイトからのリンクか、より実情に近いものになるのではないかと思います。
ウェブマスター ツールでは、ドメイン名のみ（example.com）、サブドメイン（www.example.com や cats.example.com）、サブディレクトリを含むドメイン（www.example.com/cats/ や www.example.com/users/catlover/）といった様々な種類のサイトを管理できます。従来は、ウェブマスター ツールに登録したサイトの URL から始まる URL のリンクのみが内部リンクに分類されていました。たとえば、www.example.com/users/catlover/ をサイトとして追加していた場合、URL が www.example.com/users/catlover/ から始まる www.example.com/users/catlover/profile.html からのリンクは内部リンクのカテゴリに入っていましたが、www.example.com/users/ や www.example.com からのリンクは外部リンクに分類されていました。また、登録したサイトが www.example.com だった場合、example.com からのリンクは外部からのリンクと見なされていました。リンクの URL がサイトと同じ URL から始まっていないためです（www が欠けています）。
しかし、最近では example.com と www.example.com は同じサイトとして扱われることが多くなってきました。そこで、example.com または www.example.com のどちらかをサイトに追加していれば、リンクのドメインに www が付いていてもいなくても内部リンクのカテゴリに分類されるように変更しました。また、他のサブドメインからのリンクも内部リンクに含めるようにしました。ドメインを管理している方は多くの場合、サブドメインも管理しているからです。したがって、cats.example.com や pets.example.com からのリンクも www.example.com の内部リンクとなります。
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.com
）やサブディレクトリ（例:
www.google.com/support/webmasters/
）内にあり、ルート ドメインにはない場合、内部リンク内にはそのサブドメインやサブディレクトリからのリンクのみが表示され、それ以外はすべて外部リンクとみなされます。これらの数がより正確になるように、いくつかの変更を加えています。
注意していただきたいのは、example.com や www.example.com などのルート ドメインでは今回の変更に伴って外部からのリンクの数が少なく表示される可能性があることです。これは前述のように、従来は外部リンクに分類されていた一部の URL が内部リンクに分類されたためです。リンクの合計数（内部リンク + 外部リンク）は、今回のアップデートの影響を受けません。
この記事に関するコメントやご質問は、
ウェブマスター ヘルプフォーラム
までお寄せください。
Posted by Susan Moskwa, Webmaster Trends Analyst
Original version:
Reorganizing internal vs. external backlinks
ラベル
+1 ボタン
AMP
API
App Indexing
Google プレイス
Merchant Center
Search Console
イベント
ウェブマスターガイドライン
ウェブマスタークイズ
ウェブマスターツール
ウェブマスターフォーラム
オートコンプリート
お知らせ
クロールとインデックス
サイトクリニック
サイトマップ
スマートフォン
セーフブラウジング
セキュリティ
データー ハイライター
ハッキング
ハングアウト
ビデオチュートリアル
マルウェア
モバイルサイト
リッチスニペット
検索エンジン最適化
検索結果
構造化データ
国際化
再審査リクエスト
初級者向け
上級者向け
中級者向け
アーカイブ
2016
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月
災害時、急激なアクセス集中に備えてウェブマスターができること
ページ スピード サービス - ウェブ パフォーマンスを高速化
検索結果における PDF ファイルの取り扱いについてのヒント
Google Chrome でサイトをうまく表示する方法
ウェブマスター ツールの内部リンクと外部からのリンクの取り扱いを変更しました
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
Follow @googlewmc
モバイルの検索結果が
4 月 21 日
から変わります。
モバイル フレンドリーかどうかをぜひ試してみてください！
