台風や大雨、地震などの災害時には多くの方が災害情報や交通情報、避難所や防災マップといった緊急情報を確認するため、特定のサイトに突発的にアクセスが集中することがあります。こうした急激なアクセスの集中は、時にサーバーの処理能力を超え、サイトをダウンさせてしまいます。サイトがダウンしてしまうと、災害情報などの緊急情報を提供できなくなり、より多くの混乱を引き起こしてしまうでしょう。

突発的なアクセスの集中は避けることは難しいですが、あらかじめそれに備えることでサイトのダウンを防ぐことが可能です。そこで今回は、災害時などの急なアクセス集中に備えてできる比較的簡単な対策をご紹介したいと思います。

• 軽量化したサイトを別途用意する
  災害時に備え、軽量化したサイトをあらかじめ別途用意しておきましょう。災害時にはその軽量化したサイトに置き換えます。しかし普段は使わないページを用意し、いざという時のために管理し続けるというのは負担が大きいかもしれません。そこで例えば携帯電話向けのサイトを用意し、災害時には携帯電話向けに提供しているページを 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 クライシスレスポンスチーム、サーチ クオリティ チーム

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.

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 が 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

ウェブマスター ツールではサイトへのリンクを、外部のサイトからのリンク と サイト内からのリンク の 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

[本記事は 2008 年に公開された記事の抄訳です。また、ウェブマスター ツール ヘルプページで サイトがハッキングされた、またはマルウェアに感染した場合 の対処方法が掲載されていますが、日本でもハッキングの事例が増えてきているため、改めてご紹介します。]

ウェブサイトのハッキング被害は多くのウェブマスターが経験することで、気をつけて予防策を講じていたとしても発生してしまうことがあるものです。予防のためのアドバイスとしては、最新のソフトウェアやパッチで常にサイトをアップデートしておくこと、Google ウェブマスター ツール に登録して 、インデックスの状態をチェックすること 、ログファイルに目を配り、不審な動きが見られないか確認しておくことなどが挙げられます。（さらに詳しい情報は、2007 年に掲載した「Quick Security Checklist」（英語）の記事にまとめてあります。）

それでは、ハッキングされた時、どうすればいいでしょうか？ サイトをハッキングされたときに最初にすべきことは、ホスティング サービスを利用している場合はそこに連絡をすることです。多くの場合、技術的に困難な作業のほとんどはホスティング サービス業者が対応してくれます。ウェブマスターの多くは共有ホスティング サービスを利用していますが、その場合以下に挙げていることを実行するのが困難な場合があります。アスタリスク（*）のついたアドバイスは、共有ホスティング サービスを利用しているウェブマスターのみなさんが、ホスティング サービス業者の協力を必要とする可能性が高いものです。サーバーに対して完全な管理権を所有している場合は、以下の 4 つの原則に従うことをお勧めします。

サイトをオフラインにする

• サイトを一時的に、少なくとも問題を解決できたと確信できるまでは、オフラインにします（ネットワークから切り離します）。*
• オフラインにできない場合は、クロールされないように 503 ステータス コード を返すよう設定します。
• ウェブマスター ツールの URL 削除ツール を使用して、侵入者によって追加された可能性のあるページや URL を検索結果から削除します。こうすることで、ユーザーがハッキングされたページを閲覧してしまうことを防ぎます。

被害を分析する

• ハッカーの侵入目的が何だったのかを把握することは重要です。
• 狙いは機密情報でしょうか？
• 他の目的のためにサイトを乗っ取ろうとしたのでしょうか？
• ウェブサーバー上で、改変またはアップロードされたファイルを探しましょう。
• サーバー ログから、ログイン認証の失敗、コマンドの履歴（特に root で実行されたコマンド）、不明なユーザーアカウントなどの不審な活動をチェックしましょう。
• 被害の範囲を特定します。他にも影響を受けたかもしれないサイトはありませんか？

復旧する

• 最善策は、信頼できるソースから OS を完全に再インストールすることです。ハッカーによる被害をすべて確実に取り除くには、これ以外に方法はありません。*
• 再インストールが完了したら、最新のバックアップを使用してサイトを復旧します。この際、バックアップがハッキングの影響を受けていないことを必ず確認しましょう。*
• インストールされたソフトウェアにパッチを当てて最新版にします。ブログ プラットフォーム、コンテンツ マネージメント システムや、その他サードパーティによるソフトウェアなどすべてが対象となります。
• パスワードを変更します。

オンラインへの復帰

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

その他の質問と回答:

Q: クロールを防ぐためには、サイトをオフラインにするのと robots.txt を使用するのとでは、どちらが良いですか？
A: オフラインにする方が良いでしょう。マルウェアやバッドウェアがサイトの閲覧者に感染したり、ハッカーがサイトをさらに不正利用したりすることを防ぐことができます。

Q: サイトの問題解決後、どうしたら迅速に再度クロールしてもらえますか？
A: サイトがハッキングされたかどうかに関わらず、こちらの ヘルプ記事 にある手順を踏んでください。

Q: サイトをクリーンアップしましたが、ハッカーによって悪いサイトへリンクされていた場合、検索順位に影響はあるのでしょうか？
A: Google でもそのような事態は望んでいません。ハッカーやスパマーの行為によって、良いサイトの検索順位などに影響が出ないように務めています。念のために、ハッカーが追加した可能性のあるリンクは完全に削除してください。

Q: 自宅のコンピュータがハッキングされた場合はどうしたらいいですか？
A: その場合も、上記の対策が適用できます。復旧には細心の注意を払ってください。注意を怠ると、同様の被害が再発してしまう可能性が高くなります。OS を再インストールするのが最善です。

その他の役に立つ情報:

• サイトが 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?