ハッキングされたサイトの復旧事例をご紹介します

今日では、ハッキングされるウェブサイトの数は、1 日あたり数千に及ぶと言われています。ハッキングされたサイトは、ユーザーに悪意のあるソフトウェアを配布する、ユーザーの個人情報を収集する、ユーザーをまったく別のサイトにリダイレクトするなどの方法で、ユーザーに危害を加えるおそれがあります。もしサイトがハッキングされたら速やかに復旧したいものですが、その方法は単純ではありません。

Google では、サイトがハッキングされた場合にできるだけ簡単に復旧できるよう、セキュリティの問題ハッキングされたサイトに関するヘルプハッキングされたサイト専用のフォーラムなどを提供しています。最近、ハッキングされた 2 つのサイトのウェブマスターの方に、どうやってサイトを復旧したかについてお話を伺う機会がありました。こうした事例をご紹介することで、ハッキングの被害にあったウェブマスターの皆様がサイトの復旧を行う際のヒントになれば幸いです。

事例 1: レストランのウェブサイトがハッキングされ、複数のスクリプトが挿入された

このレストランでは Wordpress でウェブサイトを作成していましたが、ある日サイトがハッカーによって改ざんされたことを警告する Google からのメッセージがウェブマスター ツール アカウントに届きました。Google では検索ユーザーを保護するため、このウェブサイトがハッキングされたことを示すラベルを Google 検索結果に表示しました。このサイトのウェブマスターであるサムさんがソース コードを確認したところ、「viagra(バイアグラ)」、「cialis(シアリス)」などの薬剤用語を使った不審なリンクが数多く見つかりました。また、「buy valtrex in florida(バルトレックス 購入 フロリダ)」のような meta description タグが HTML 上に追加されているページも数多く見つかりました。さらには、多くのページに(HTML 内にも)非表示の div タグが挿入され、さまざまなページにリンクしていました。もちろん、これらはサムさんが追加したものではありません。

サムさんは、ハッキングされたコンテンツを可能な限り削除して再審査リクエストを送信しました。リクエストは承認されませんでしたが、Google からメッセージがあり、PHP ファイル(もしくは、その他のサーバー ファイル)内に不審なスクリプトが追加されていないか、.htaccess に変更が加えられていないか確認するようアドバイスされました。これらは、ハッカーがサイトを改ざんする際、スクリプトを追加するのによく狙うファイルだからです。通常、ハッカーはこのようなスクリプトを使って、ハッキングしたコンテンツを検索エンジンに対してのみ表示し、一般のユーザーにはそのコンテンツが表示されないようにしてしまいます。サムさんはすべての .php ファイルを確認し、ハッキング前にバックアップしておいたファイルと比較しました。その結果、footer.php、index.php、functions.php に新しいコンテンツが追加されていることが判明しました。これらのファイルをバックアップ ファイルで置き換えた後にハッキングされたコンテンツがそれ以上見つからないことを確認し、もう一度再審査リクエストを送信したところ、サイト内のハッキングされたコンテンツがすべて削除されていることを知らせる Google からの通知が届きました。

ハッキングされたコンテンツはすべて削除しましたが、サムさんとしては今後のハッカーの攻撃からサイトを保護しなければなりません。そこで以下の方法によりサイトを保護することにしました。
  • コンテンツ管理システム(WordPress、Joomla、Drupal など)を常に最新のバージョンに更新する(プラグインも忘れずに更新する)。
  • コンテンツ管理システムの管理機能を使用できるアカウントに、強度の高いパスワードを使用する。
  • コンテンツ管理システムでサポートされている場合は、ログインの 2 段階認証(英語)を有効にする(2 要素認証と呼ばれることもあります)。この方法は、パスワードの再設定に使用するアカウントにもおすすめします。GoogleMicrosoftYahoo(英語)など、ほとんどのメール プロバイダでサポートされています。
  • インストールされているプラグインやテーマが信頼できる提供元からのものであることを確認する。既にサポートが終了しているようなプラグインやテーマを使用し続けることは大変危険です。また、海賊版のプラグインやテーマには、ハッカーの侵入を容易にするようなコードが挿入されていることが多いようです。

事例 2: 事業用ウェブサイトに検出が難しいハッキングされたページが大量に見つかった

小規模事業主であるマリアさんは、管理しているウェブサイトがハッキングされていることを知らせるメッセージをウェブマスター ツールで受け取りました。メッセージには、ハッカーが追加したページの例として http://example.com/where-to-buy-cialis-over-the-counter/ が挙げられていました。ホスティング プロバイダに相談したところ、ホームページのソース コードを確認してくれましたが薬剤に関するキーワードは見つからず、http://example.com/where-to-buy-cialis-over-the-counter/ にアクセスするとエラー ページが返されるという状況でした。有料のマルウェア スキャン サービスも利用しましたが、サイト内に悪意のあるソフトウェアを見つけることはできませんでした。
その後、ウェブマスター ツールの Fetch as Google 機能を使用して、Google が例示した URL(http://example.com/where-to-buy-cialis-over-the-counter/)にアクセスしてみましたが何も返されませんでした。どうしようもないため再審査リクエストを送信したところ、不承認メッセージが届き、以下の 2 点を試すようアドバイスがありました。
  1. www のないサイト URL をウェブマスター ツールに追加する。これは、ウェブマスターが見落としがちなフォルダにハッカーのコンテンツが隠されている場合があるためです。

    http://example.com と http://www.example.com は同じサイトのように見えますが、Google ではこれらを別々のサイトとして処理しています。http://example.com は「ルート ドメイン」で、http://www.example.com は「サブ ドメイン」です。マリアさんは http://www.example.com は確認していましたが、http://example.com は確認していませんでした。しかし、ハッカーが追加していたページは http://example.com/where-to-buy-cialis-over-the-counter/ のような www のないページで、こちらを確認することが重要だったのです。マリアさんが http://example.com を確認したところ、ウェブマスター ツールの Fetch as Google 機能を使用してハッキングされたコンテンツを表示することができました。
  2. .htaccess ファイルに新たなルールが追加されていないか確認する。

    マリアさんが、ホスティング プロバイダにやり方を教わって .htaccess ファイルを確認したところ、次のような追加した覚えのない不審なコンテンツが追加されていました。

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
    RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
    RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
    </IfModule>


    この mod_rewrite(英語)ルールはハッカーが挿入したもので、特定の検索エンジンから訪れたすべてのユーザーと検索エンジン クローラを、ハッキングされたコンテンツの生成元である main.php にリダイレクトしているものでした。このようなルールで、携帯端末でサイトにアクセスしてきたユーザーをリダイレクトすることも可能です。同じ日、最近のマルウェア スキャンによって、main.php ファイルに不審なコンテンツが見つかっていたことも判明しました。さらには、ウェブサイト開発ソフトウェアの FTP ユーザー領域に、不明なユーザーが登録されていることにも気付きました。
マリアさんは main.php ファイルと .htaccess ファイルを削除し、FTP ユーザー領域から不明なユーザーを削除しました。これにより、サイトのハッキングを止めることができたのです。

今後ハッキングされないための対策

  • サーバーへのファイル転送に FTP の使用を避ける。FTP では、パスワードをはじめすべてのトラフィックが暗号化されません。代わりに SFTP を使用することで、パスワードを含むすべてのトラフィックが暗号化され、盗聴者からデータを保護できます。
  • .htaccess のような重要なファイルへのアクセス権限を確認する。この点については、必要に応じてホスティング プロバイダに相談してください。.htaccess はサイトの改善や保護に使用する重要なファイルですが、このファイルへのアクセスを許してしまうとハッカーに悪用されるおそれがあります。
  • サイトを変更する権限のあるユーザーを確認できる場所(管理パネルなど)をこまめにチェックして、不明なユーザーが追加されていないかどうか確認する。
Google では、ウェブマスターの皆様のサイトがハッキングされないことを願っておりますが、万が一ハッキングされた場合はハッキングされたサイトに関するヘルプをご覧ください。ハッキングされたサイトを復旧するためのさまざまな資料が用意されています。それでもご不明な点がある場合や、他のウェブマスターと情報交換していただける場合は、ウェブマスター ヘルプ フォーラムをご利用ください(フォーラムに投稿する際やサイトの再審査リクエストを送信する際は、#NoHacked を含めるようにしてください)。

最後に、ハッキングによる被害はなかなか気づかないことも多いようです。サイトの不正なハッキングをいち早く見つけ、普段からサイトのセキュリティ強化を意識しましょう!

Web Components と JSON-LD でウェブサイト開発がより簡単に

JSON-LD は、Google などの検索エンジンに対してサイト上のコンテンツを記述する構造化データの実装に使用できる JSON ベースのデータ形式です。たとえば、イベント、店舗、人物などのリストがある場合に、schema.org ボキャブラリを JSON-LD スニペットとしてウェブページに埋め込むことで、構造化された方法でリストのデータをページに含めることができます。構造化データにすることで、Google がページの内容を把握しやすくなり、ナレッジグラフ イベントリッチ スニペットなどの検索機能でコンテンツがハイライトで表示されやすくなります。

Web Components は、カスタマイズした再利用可能なユーザー インターフェース ウィジェットとその動作を定義するための技術です。複数の技術で成り立ち、その仕様は現在も策定中です。ウェブ デベロッパーであれば誰でも Web Components をビルドできます。まず、ユーザー インターフェースの個々のパーツについてテンプレートを定義し、Web Components を使用したいページにテンプレートをインポートします。Web Components の動作を定義するには、Custom Elements を使用します。ユーザー インターフェースのパーツの表示とロジックが Web Components にバンドルされるため、このバンドルを他のページや他のデベロッパーと共有したり、再利用したりでき、ウェブ開発が簡単になります。

JSON-LD と Web Components は、併せて利用するととてもうまく機能します。Custom Elements がプレゼンテーション層として機能し、JSON-LD は Custom Elements や検索エンジンが読み込むデータ層として機能します。つまり、schema.org/Eventschema.org/LocalBusiness など、どのような種類の schema.org についても、Custom Elements をビルドできることになります。

アーキテクチャは次のようになります。構造化データはデータ ベースに格納されます(例: チェーンの店舗の所在地)。このデータは JSON-LD スニペットとしてウェブページに埋め込まれます。つまり、Custom Elements によって読み込まれ、人間の訪問者に対して表示されたり、Googlebot によって Google のインデックス登録のために取得されたりできるようになります。

Custom Elements の詳細や独自の Custom Elements の使用方法については、以下をご覧ください。

オンライン フォームを入力しやすくするために

多くのウェブサイトでは、重要な目標を達成するための手段としてフォームを使用しています。たとえば、ショッピング サイトでは代金の決済、ニュース サイトでは会員の登録などです。ユーザーの多くは、ウェブ上の各サイトでオンライン フォームを入力するたびに、氏名、メール アドレス、電話番号、住所などの情報を繰り返し入力することになります。同じ情報を何度も入力するのは面倒なだけではありません。入力エラーが発生しやすく、ユーザーがフォームの途中で入力をやめる原因にもなってしまいます。パソコンよりも携帯端末で閲覧するユーザーが多くなり、フォームをすばやく簡単に入力できるようにすることが不可欠となっています。Google では 3 年前、フォームへの入力をすばやく、簡単に、スマートに行えるようにするため、Chrome で新たに「autocomplete」属性をサポートすることを発表しました。現在では、最新の WHATWG の HTML 標準(英語)に準拠する形で「autocomplete」属性が完全にサポートされています。これにより、ユーザー インターフェースやバックエンドに変更を加えることなく、入力要素項目に一般的なデータ タイプ(「name」、「street-address」など)をラベル付けできるようになっています。既にたくさんのウェブマスターがフォームをマークアップしてオートコンプリートを実装し、フォーム入力の完了率を上昇させています。

たとえば、フォームのメール アドレス項目をオートコンプリートできるようにするには、次のようにマークアップします(サンプル フォームもご覧ください)。

<input type="email" name="customerEmail" autocomplete="email"/>
携帯端末ユーザーが増加した今、操作やブラウジングが簡単なウェブサイトにすることが非常に重要です。「autocomplete」属性でマークアップされたフォームが、今後ますます増えていくことを願っております。詳細については、「Web Fundamentals」の Label and name inputs properly (英語)で仕様を確認してください。ご質問などありましたら、いつもどおりウェブマスター ヘルプ フォーラムに投稿してください。

誘導ページについて、品質に関するガイドラインを更新しました

Google のサーチ クオリティ チームは、ユーザーに対するウェブスパムの影響を最小限に抑える方法について継続的に取り組んでいます。誘導ページもその対象の 1 つです。

Google では従来より、検索エンジンのためだけに作成された誘導ページについて、ユーザーの検索体験の品質に悪影響を及ぼす可能性があるとの見解を持っています。

たとえば、検索結果に表示されるすべてのページが、検索ユーザーを同じサイトに誘導するものであった場合を考えてみてください。ユーザーがある検索結果をクリックして閲覧し、その内容が目的に沿うものではなかったため検索結果ページに戻って次の結果をクリックしても、結局は最初に閲覧した目的に沿わなかったページと同じページに誘導されてしまい、ユーザーの利便性が大きく妨げられてしまいます。

Google では長い間、明確な独自の価値を提供していないにもかかわらず検索結果の上位に表示されることのみを目的とするサイトを目にしてきました。このような誘導は、サイト内の複数のページを利用したり、多数のドメインを利用したり、またはそれらを組み合わせた形で行われています。Google ではユーザーに表示される検索結果の品質向上を目的として、より適切にこのような種類のページに対応するためのランキングの調整を近日中に開始します。大規模かつ入念な誘導キャンペーンを実施しているサイトは今回の変更によって大きな影響を受ける可能性があります。

ウェブマスターの皆様に Google のガイドラインを十分にご理解いただけるよう、品質に関するガイドラインに誘導ページの明確な例を追加するとともに、その定義を更新しました。
誘導ページかどうかは、たとえば、以下のような項目に基づいて判断されます。
  • 検索エンジン用に最適化することでサイト内の有用なコンテンツや関連性の高いコンテンツにユーザーを案内することを目的としているか。そうである場合、そのページがサイトのユーザー エクスペリエンスに不可欠か。
  • ページのコンテンツが極めて具体的であるにもかかわらず、一般的なキーワードで検索結果の上位に表示されることを目的としていないか。
  • 検索トラフィックを増やすことを目的に、そのページにサイト上の既存の項目(場所や商品など)をまとめたコンテンツを繰り返して掲載していないか。
  • コンテンツや機能において独自の価値はなく、単にお金儲けのためにユーザーを別のページに誘導することのみを目的に作成されたページではないか。
  • ページが「孤立」して存在していないか。サイト内の他の場所からそのページへの移動が困難または不可能ではないか。検索エンジンのためだけに、サイト内の他のページやサイトのネットワークからそのページへのリンクを作成していないか。

誘導ページにつきましては、こちらのブログ記事「誘導ページ(Doorway Page)はガイドライン違反です」もご覧ください。誘導ページについてのご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

古い Webmaster Tools API 廃止のお知らせ

昨年の秋、多くの重要な自動処理の実装に役立つ新しい Webmaster Tools API 提供の開始をアナウンスしました。そしてこのたび、保留となっていた ClientLogin の終了(英語)とともに、2015 年 4 月 20 日に古い Webmaster Tools API (英語)を廃止します。

古い API を利用している場合でも、新しい API への移行は簡単です。新しい API は、メッセージとキーワードの機能を除いて古い API の機能をすべてカバーしています。Python (英語)、Java (英語)、および(コマンドラインに慣れた方のため、およびテストを容易にするために)OACurl (英語)のサンプルを用意しています。加えて、サイトを自動的に追加するためのSite Verification API (英語)も提供しています。 Python を使った検索クエリのダウンロード機能(英語)は当分の間提供を続けますが、今後数か月の間に新しい API に置き換わる予定です。

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

ウェブマスター ツールを利用してリソースのブロックを解除しましょう

ウェブページではデザイン性や機能性を高めるため、画像、CSS ファイル、JavaScript ファイルがよく使われます。このようなリソースがクロールからブロックされると、Googlebot では検索用にページをレンダリングする際にそのリソースを使用できません。そこで Google ウェブマスター ツールでは、ウェブマスターの皆様がこのような問題を特定して解決できるよう、ブロックされたリソースのレポートを導入しました。
このレポートには、サイト上のブロックされたリソース(JavaScript、CSS、画像など)の提供元ホスト名が表示されます。行をクリックすると、ブロックされたリソースの一覧と、そのリソースが埋め込まれているページが表示されます。そこから、ページ コンテンツのクロールとインデックス登録を可能にするために何が必要かを診断、解決する手順に進むことができます。

取得してレンダリングすると、これらのブロックされたリソースがどの程度問題であるかが表示されます。URL の取得とレンダリングをリクエストすると、Googlebot としてレンダリングされたスクリーンショットと一般ユーザーとしてレンダリングされたスクリーンショットの両方が表示されます。これにより、ページが Googlebot から異なって認識されることに大きく影響する問題を、より簡単に特定できるようになります。

ウェブマスター ツールでは、ウェブマスターが関与しうると思われるホストのみを表示するため、現時点では、さまざまなサイトで使用されているホスト(一般的な解析サービスなど)は表示されません。すべての robots.txt ファイルを更新するのは時間がかかるため、ブロックされたときに表示が大きく異なってしまうリソースから開始することをおすすめします。関連する手順について詳しくは、ウェブマスター ツールのヘルプセンター記事をご覧ください。

この新機能が、ウェブサイト上のブロックされたリソースを特定してブロック解除する際に、皆様のお役に立てば幸いです。ご不明な点がありましたら、お気軽にウェブマスター プロダクト フォーラムまでお寄せください。

検索結果をもっとモバイル フレンドリーに

ユーザーが携帯端末で検索した場合、探している情報がモバイル フレンドリー サイトで公開されていてもアプリで公開されていても、関連性の高いタイムリーな検索結果がユーザーに表示される必要があります。インターネットへのアクセスに携帯端末が使用されるケースが増えてきたため、Google のアルゴリズムもこうした使用状況への対応が必要となっています。これまでにも、サイトを適切に設定するための変更、最新端末で表示可能にするための変更を行ってきました。また、検索ユーザーがより簡単にモバイル フレンドリーなウェブページを探せるよう対応し、アプリの有益なコンテンツを検索結果に表示するようになる App Indexing を導入しました。

本日、Google はモバイル フレンドリーなコンテンツをユーザーがより発見しやすくするためにおこなった 2 つの重要な変更についてお知らせします。

1. 検索結果にもっとモバイル フレンドリーなウェブサイトを

Google では、4 月 21 日より、ウェブサイトがモバイル フレンドリーかどうかをランキング要素として使用し始めます。この変更は世界中の全言語のモバイル検索に影響を与え、Google の検索結果に大きな変化をもたらします。この変更によって、検索ユーザーは、クエリへの関連性が高く使用端末にも適した高品質な検索結果を見つけやすくなります。

モバイル フレンドリー サイトの作成について詳しくは、モバイル フレンドリー サイトのガイドをご覧ください。ウェブマスターの皆様は、以下のツールを使うことで、ご自身のページが Googlebot からどのように認識されているかを変更の前に確認することができます。

2. 検索結果にもっと関連性の高いアプリ コンテンツを

本日より Google は、インデックスされたアプリからの情報を、そのアプリをインストールしている ログイン ユーザーに対して、ランキング要素の一つとして使用し始めます。これにより、インデックスされたアプリのコンテンツをより簡単に見つけることができるようになります。アプリのコンテンツが検索結果に表示されるようにする方法については App Indexing サイトで解説していますので、ぜひご覧ください。

モバイル フレンドリー サイトまたは App Indexing についてご不明な点がありましたら、ウェブマスター プロダクト フォーラムでお気軽にご質問ください。

ウェブマスター ツールでモバイル ユーザビリティが確認できるようになりました

スマートフォンが普及するにつれ、モバイルでの閲覧に対応したサイトを作ることは、ますます重要になってきています。今回は、先日ウェブマスター ツールに追加されました、モバイル ユーザビリティを確認できる機能をご紹介いたします。

この新機能によって、あなたのサイトがモバイルで閲覧される際に問題となりうる点が表示されるようになりました。進捗を確認するために、時系列でのグラフもついています。

ここでは、スマートフォンでの閲覧の際、上下のスクロールのみによって簡単に読むことのできるサイトをモバイル フレンドリーと定義しています。左右へのスワイプやズームイン、ズームアウトが必要となる場合、スマートフォンで気軽に閲覧することは難しくなってしまいます。ここで指摘される問題は以下のようなものです。
これらの問題がウェブマスター ツール内で表示されている場合、ぜひ解決法を探ってみてください。テンプレートを変えるだけで直ってしまうこともままあります。詳しい情報は、モバイルガイドを御覧ください。

ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

XML サイトマップと RSS/Atom フィードのベストプラクティス

サイトマップを送信することは、サイトを最適化する上で重要な要素の一つです。サイトマップを送信することで、あるサイトに存在するすべての URL を検索エンジンが発見できるようになり、ページの内容が変更された時に素早くダウンロードすることが可能になります。そこで今回は、サイトマップにおける重要なフィールドについて、XML サイトマップや RSS/Atom フィードはいつ使えばよいのか、また Google 検索に最適化するためにはどうすればよいか、について解説します。

サイトマップとフィード

サイトマップは、XML サイトマップ(英語)、RSS 、もしくは Atom のいずれかの形式を使用します。主な違いは次のとおりです。XML サイトマップは、あるサイトに存在するすべての URL が含まれますが、RSS/Atom フィードは、最新の更新が含まれます。つまり:
  • XML サイトマップは一般的にファイルサイズが大きくなります。一方、RSS/Atom フィードのファイルサイズは小さく、サイトの最新の更新情報のみが含まれます。
  • XML サイトマップは RSS/Atom フィードほど頻繁にダウンロードされません。
Google では、最適なクロールを行うために、XML サイトマップと RSS/Atom フィードの両方を使用することをおすすめしています。XML サイトマップによって、Google はサイト内の全ページに関する情報を取得することができ、RSS/Atom フィードによって、サイト内のすべての更新情報を取得することができるからです。両者のおかげで、Google はインデックス中のコンテンツをいつも最新の状態に保つことが可能になります。ただし、サイトマップやフィードを送信したからといって、URL のインデックスが保証されるわけではありません。

XML サイトマップの例:
<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>http://example.com/mypage</loc>
   <lastmod>2011-06-27T19:34:00+01:00</lastmod>
   <!-- optional additional tags -->
 </url>
 <url>
   ...
 </url>
</urlset>


RSS フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<rss>
 <channel>
   <!-- other tags -->
   <item>
     <!-- other tags -->
     <link>http://example.com/mypage</link>
     <pubDate>Mon, 27 Jun 2011 19:34:00 +0100</pubDate>
   </item>
   <item>
     ...
   </item>
 </channel>
</rss>


Atom フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
 <!-- other tags -->
 <entry>
   <link href="http://example.com/mypage" />
   <updated>2011-06-27T19:34:00+01:00</updated>
   <!-- other tags -->
 </entry>
 <entry>
   ...
 </entry>
</feed>


"other tags" は必須タグと省略可能なタグの両方を表しており、両者はそれぞれの形式の標準によって定義されています。Google では、Atom/RSS フィードに必須タグを指定することをおすすめしています。この指定により、フィードは Google 検索だけでなく、フィードを扱う可能性のある他のプロパティでも表示することが可能になるからです。


ベストプラクティス

重要なフィールド

XML サイトマップと RSS/Atom フィードは、実際のところ、メタ データが付加された URL の一覧です。その中で、Google にとって最も重要な情報は、URL そのものとその最終更新日時です。

URL

XML サイトマップや RSS/Atom フィード内の URL は、以下のガイドラインに従ってください。
  • Googlebot が取得可能な URL であること。robots.txt によって Googlebot のアクセスを禁止している URL や、ページが存在しない URL が指定されているケースがよく見られますが、それらは間違った指定方法です。
  • 正規 URL であること。内容の重複した複数のページの URL が指定されていることがありますが、これは間違った指定方法です。そのままでは、インデックスが改善されない一方で、あなたのサーバーの負荷が増大してしまいます。

最終更新日時

それぞれの URL に対して、その URL の最終更新日時を XML サイトマップと RSS/Atom フィードに指定してください。最終更新日時とは、そのページのコンテンツが実質的に更新された最新の日時です。ある更新が検索結果に影響を与える可能性がある場合、その更新日時が最終更新日時となります。
  • XML サイトマップでは <lastmod> を使用します
  • RSS では <pubDate> を使用します
  • Atom では <updated> を使用します
最終更新日時を正しく設定、更新するには:
  • 日時を正しい形式で指定します。XML では W3C Datetime 形式 (英語)、Atom では RFC3339 形式 (英語)、RSS では RFC0822 形式 (英語)を使用します。
  • コンテンツが実質的に変更されたときのみ、日時を更新します。
  • サイトマップやフィードが取得されるたびに、現在日時を最終更新日時として指定しません。

XML サイトマップ

XML サイトマップには、サイト内のすべての URL が記載されている必要があります。一般的に、XML サイトマップはファイルサイズが大きく、頻繁には更新されません。使用の際は、以下のガイドラインに従ってください。
  • 単独の XML サイトマップの場合:(定期的に更新されるサイトの場合は、)更新は少なくとも一日一回行い、Google に ping(英語)を送信します。
  • 複数の XML サイトマップの場合:それぞれの XML サイトマップにはできるだけ多くの URL を記載します。一つの XML サイトマップは、最大 5 万 URL もしくは(圧縮されていない状態で)10 MB までとし、ファイルがどちらかの制限に達するまで URL を記載します。XML サイトマップをひとつでも更新した場合は、その都度 Google に ping(英語)を送信してください(サイトマップ インデックス ファイルを使用している場合は、一度だけ送信してください)。それぞれの XML サイトマップにごく少数の URL のみを記載しているケースがしばしば見られますが、それは間違った指定方法です。その場合、Google にとって、想定された時間内で XML サイトマップすべてをダウンロードすることが難しくなります。

RSS/Atom

RSS/Atom フィードは、サイト内の最近の更新情報を伝えている必要があります。通常、RSS/Atom フィードはファイルサイズが小さく、頻繁に更新されます。Google では、RSS/Atom フィードを以下のように設定することをおすすめしています。
  • 新たなページが追加されるか、既存のページが実質的に更新された場合、フィードにその URL と更新日時を追加します。
  • Google による更新情報の見逃しを防ぐため、RSS/Atom フィードには、少なくとも、前回の Google のクロール以降のすべての更新情報が記載されるようにしてください。Google では、そのための最適な方法として、PubSubHubbub(英語)の使用をおすすめしています。ハブが、可能な限り高速かつ効率的な方法で、関係するすべての購読者(RSS リーダーや検索エンジンなど)へフィードの内容を伝達してくれます。

XML サイトマップと RSS/Atom フィードの両方を使用することで、Google や他の検索エンジンによるクロールをうまく最適化することができます。その際に重要な情報は、正規 URL と最終更新日時です。これらを適切に設定し、サイトマップの ping や PubSubHubbub を通して Google などの検索エンジンに伝えることで、クロールを最適な状態で行うことが可能になり、意図した通りに、ウェブサイトが検索結果に反映されるようになります。

ご不明な点がありましたら、この記事にコメントいただくか、ウェブマスター ヘルプ フォーラムのサイトマップ カテゴリまでいつでもお寄せください。

地域対応ページのクロールとインデックス登録

地域対応ページでは、ユーザーの言語や検出された地域に応じてコンテンツが変更されます。Googlebot は通常 Accept-Language HTTP リクエスト ヘッダーを設定せずにページをリクエストし、米国からと判定される IP アドレスを使用するため、地域対応ページのすべてのコンテンツが正しくインデックス登録されるとは限りません。

このたび Google では、リクエストの言語や地域に基づいて配信コンテンツを変更していると判断されたページに対応するため、新しい地域認識クロール設定を Googlebot に追加しました。
  • 地域分散クロール: Googlebot は、米国からと判定される現在の IP アドレスに加え、米国外からと判定される IP アドレスも使用します。
  • 言語依存クロール: Googlebot は、リクエスト内で Accept-Language HTTP ヘッダーを使用してクロールします。
これらの新しいクロール設定は、地域対応ページが検出されると自動的に有効になるため、CMS やサーバー設定を変更しなくても、サイトのクロール方法や Google の検索結果での表示の変化にお気付きいただけることでしょう。

この新しい設定が追加された後も、地域ごとに rel=alternate hreflang アノテーションで別々の URL を使用することを引き続きおすすめします。ユーザーの操作やコンテンツの共有を円滑に行うために、そして地域別のコンテンツを可能な限りインデックス登録してランキングの精度を向上させるために、Google では今後も別々の URL の使用を推奨いたします。

ご不明な点やご意見・ご感想などありましたら、ウェブマスター ヘルプ フォーラムにてお聞かせください。

2014 年もウェブマスター向け公式ブログをご覧頂き、ありがとうございました。

2014 年もウェブマスター向け公式ブログをはじめ、ウェブマスター ヘルプ フォーラムWebmaster Japan コミュニティ、そして Webmaster Hangout/Office Hour など、ご愛読、ご参加いただきありがとうございました。

ウェブマスターのみなさまにとって今年はどんな一年でしたでしょうか?今年公開した人気記事のランキングとともに今年一年を振り返ってみたいと思います。上位 5 つの記事を見てみましょう。

第 1 位:HTTPS をランキング シグナルに使用します
第 2 位:リンク プログラムによるガイドライン違反について
第 3 位:ウェブページをより深く理解するようになりました
第 4 位:検索ユーザーがモバイル フレンドリー ページを見つけやすくするために
第 5 位:検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

今年一番注目された記事は「HTTPS をランキング シグナルに使用します」でした。HTTPS のサイトへの導入については、多くのウェブマスターの方々からご質問を頂きましたが、ランキングのシグナルとして使用しているからというだけでなく、ユーザーにサイトをもっと安全に閲覧していただくためにもぜひ導入を検討していただければと思います。また、今年もう一つ注目を集めたのはモバイルではないでしょうか。今年は他にも「Google の検索結果に、誰もが表示できるウェブサイトを」など、モバイル ユーザーの利便性を意識した改善をたくさん行っています。日本でもモバイルの検索結果に [スマホ対応] と表示されるようになりましたので、ぜひ一度モバイル フレンドリー テストであなたのサイトがモバイル フレンドリーかどうかチェックしてみてください。モバイル フレンドリー サイトの作り方についてはGoogle のウェブマスター向けモバイル ガイドや、2 年前の記事となりますが、「Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法」をぜひご覧ください。

いかがでしたでしょうか?見落としていた記事はありませんか?見落としていた記事がある方は、ぜひ冬休み中、お時間があるときに目を通してみていただけたら幸いです。また、最近日本でもハッキングの被害が引き続き増えています。年末のお休みに入る前に、こちらの記事なども参考にしながら、ぜひ担当されているサイトがハッキングの被害に遭わないように設定を再度ご確認されることをお勧めします。また、年末年始の時期を狙い、詐欺サイトでオンライン ショッピングのユーザーを騙したり、低品質なアフィリエイト サイトで営利を稼ごうといった悪質な行為を行うケースも残念ながら増える傾向にありますのでご注意ください。また、そのようなサイトを見かけた際はスパム レポートでお知らせください(関連 Google+ 記事)。

今年もありがとうございました。それではみなさん、よいお年を!

Takeaki Kanaya, Kiyotaka Tanaka and Kazushi Nagayama, Search Quality Team

App Indexing の実装に不可欠な 4 つのステップ

ディープ リンクは、オーガニック検索内で最近見かけるようになった「新入り」ですが、目を見張るような速さで普及しています。ユーザーがログインしている場合、Android での Google 検索結果のうち、15% が App Indexing によるアプリ ディープ リンクを表示しています。前四半期だけで、アプリ ディープ リンクのクリック数が 10 倍に急増しました。

App Indexing を今年 6 月に公開して以来、デベロッパーの皆様からさまざまなフィードバックが寄せられました。ほとんどの実装はうまく行きましたが、うまく行かなかった実装からも多くを学ぶことができました。この記事ではそうした経験を踏まえ、App Indexing の実装を成功させるうえで欠かせない 4 つのステップについて解説します。また、アプリのパフォーマンスを把握したり、アプリの利用を促進したりするための便利な新機能も紹介します。

1. デベロッパーにウェブマスター ツールへのアクセス権限を付与する

App indexing は、ウェブマスターとアプリ デベロッパーが協力して取り組む必要があります。ウェブマスター ツールには、デベロッパーが必要とする情報も表示されます。現時点で表示されるのは以下の情報です。
  • アプリ内のインデックス登録済みページのエラー
  • Google 検索でのアプリ ディープ リンクのクリック数とインプレッション数(週単位)
  • サイトマップに関する統計情報(アプリ ディープ リンクをサイトマップで実装した場合)
今後これらの他にもさまざまな情報を追加する予定です。

しかしながら、ウェブマスター ツールへのアクセスが許可されているデベロッパーは非常に少ないようです。アプリ関連の問題の修正に必要な情報を確実に伝達するには、デベロッパーにウェブマスター ツールへのアクセス権限を付与することが不可欠です。

確認済みのサイト所有者であれば、新しいユーザーを追加できます。付与したい権限レベルに応じて [制限付き] または [フル] を選択してください。

2. 検索結果からのアプリへのアクセス状況を把握する

ユーザーは、検索結果からアプリにアクセスしてくれているでしょうか。アプリ ディープ リンクのパフォーマンスをトラッキングする方法として次の 2 つを追加しました。
  • ウェブマスター ツール アカウントのメッセージ センターに、週ごとのクリック数とインプレッション数が送信されるようになりました。
  • アプリ ディープ リンクによってどれくらいのトラフィックがアプリにアクセスしたかを、リファラー情報(具体的には ACTION_VIEW インテントのリファラー extra)を使用してトラッキングできるようになりました。将来的には、この情報を Google アナリティクスに統合して簡単にアクセスできるようにする予定です。デベロッパー サイトでは、リファラー情報をトラッキングする方法(英語)について解説しています。

3. アプリの重要なリソースがクロール可能であることを確認する

ウェブマスター ツールのクロール エラー レポートで、「コンテンツの不一致」エラーが発生する大きな原因の 1 つがリソースのブロックです。クロールでは、アプリ ページをレンダリングするために必要なすべてのリソースにアクセスする必要があります。これにより、アプリ ページのコンテンツが、関連付けられているウェブページと同じかどうかを確認できます。

アプリ ページのレンダリングに不可欠なリソースにアクセスできない場合に、どのリソースがブロックされているかを簡単に特定できるようになりました。アプリで「コンテンツの不一致」エラーが発生した場合は、詳細ダイアログの手順 5 に沿ってブロックされているリソースの一覧を確認してください。

4. Android アプリのエラーに注意する

アプリのインデックス登録時のエラーを簡単に特定できるようにするため、検出されたすべてのアプリ エラーをメッセージとして送信することになりました。また、そのほとんどがクロール エラー レポートの [Android アプリ] タブにも表示されます。

従来の「コンテンツの不一致」エラーと「インテント URI が無効」エラーに加え、以下の 3 つのエラー タイプを追加しました。
  • APK が見つからない: アプリに対応するパッケージが見つからない
  • First Click Free(英語) がない: アプリへのリンクがコンテンツに直接つながっておらず、ログインしないとアクセスできない
  • 戻るボタンの違反: アプリへのリンクをたどって移動した後、戻るボタンで検索結果に戻ることができない
これまでの経験から、エラーの大部分はアプリの一般的な設定が原因であることがわかっています(リソースがブロックされている、ユーザーが検索結果からアプリを開こうとすると地域選択のポップアップが表示されるなど)。これらの点に注意することで、関連する URI の問題をすべて解決できるはずです。

App Indexing 実装がうまく行くことを願っています。ご不明な点がありましたら、いつでもウェブマスター ヘルプ フォーラムまでお寄せください。

検索ユーザーがモバイル フレンドリー ページを見つけやすくするために

スマートフォンなどの携帯端末で Google の検索結果をタップした時、表示されたページのテキストが細かすぎたり、リンクの表示が小さかったり、またはすべてのコンテンツを見るには横にスクロールしなければならなかったりといった経験はありませんか?これは主に、ウェブサイトが携帯端末での表示に最適化されていないことが原因です。

この問題はモバイル検索ユーザーの利便性を妨げることになります。そこで本日 Google では、ユーザーが目的の情報をより簡単に見つけることができるようにするために、モバイル版の検索結果に [スマホ対応] というラベルを追加します。
この変更は、今後数週間で順次日本を含む世界中で公開する予定です。Googlebot によってクロールされ、以下の条件を満たしたページは、[スマホ対応] ラベルが適用される可能性があります。
  • 携帯端末では一般的でないソフトウェア(Flash など)を使用していないこと
  • ズームしなくても判読できるテキストを使用していること
  • ユーザーが横にスクロールしたりズームしたりする必要がないよう、コンテンツのサイズが画面のサイズと一致していること
  • 目的のリンクを簡単にタップできるよう、それぞれのリンクが十分に離れた状態で配置されていること
ページがモバイル フレンドリーの条件を満たしているかどうかを確認するには:
ここでご紹介したツールやガイドは現在のところ英語のみとなりますが、今後数週間で多くの言語でご利用いただけるようになります。

Google ではこのラベルを、モバイル ユーザーにさらに優れたモバイル ウェブ エクスペリエンスを提供するための第一歩と考えています。また、このモバイル フレンドリーの条件をランキング要素として使用することも実験中です。

ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。Google の願いは、モバイル フレンドリー サイトが今後ますます増えていくことです。すべてのユーザーが快適に利用できるウェブを作り上げていきましょう!

技術に関するウェブマスター向けガイドラインを更新しました

Google のインデックス登録システムは、CSS と JavaScript を有効にすることで一般的な最新のブラウザと同じようにウェブページをレンダリングしていると先日お伝えしました。本日、Google ではこの内容を踏まえ、技術に関するウェブマスター向けガイドラインを一部更新いたします。

新しいガイドラインでは、最適なレンダリングおよびインデックス登録のため、ページ内で使用している JavaScript、CSS、画像ファイルに Googlebot がアクセスできるようにする必要がある、としています。サイトの robots.txt を使って Javascript や CSS ファイルのクロールを拒否するように設定すると、Google のアルゴリズムによるコンテンツのレンダリングとインデックス登録を妨げ、最適な結果が得られなくなる可能性があります。

インデックス登録の最適化に関するおすすめの方法を更新

Google のウェブマスター向けガイドラインに記載されていたように、これまで Google のインデックス登録システムは、テキスト ベースの古いブラウザ(Lynx など)にたとえられてきました。しかし、ページのレンダリングに基づいてインデックス登録を行うようになったいま、もはや Google のインデックス登録システムをテキスト ベースのブラウザと同じように考えるのは正しくありません。より正確には、現在使われているウェブ ブラウザに例えるほうが適切です。このような新しい観点からの注意事項は以下のとおりです。
  • 現在使われているブラウザと同じように、Google のレンダリング エンジンも、あるページ内で使用される技術のすべてに対応しているとは限りません。プログレッシブ エンハンスメントという考えに基づいてページをデザインすることにより、ページ内で使われている技術がサポートされていないブラウザやシステムに対しても、基本的なコンテンツと機能が提供できるようになります。
  • すばやくページがレンダリングできれば、ユーザーがあなたのコンテンツをスムーズに閲覧できるだけではなく、ページのインデックス登録をより効率的に行うことができます。特に、ページのパフォーマンスを最適化(英語)するためのおすすめの方法をご紹介いたします。
  • 必ず、JavaScript や CSS ファイルを Googlebot に配信する際に生じる追加の負荷をサーバーが処理できるようにします。
  • テストとトラブルシューティング

    レンダリングベースのインデックス登録を始めるに伴い、Google ではウェブマスター ツールの Fetch as Google 機能も更新しました。この機能により、ウェブマスターの皆様は Google のシステムが、あるページをどのようにレンダリングしているかを把握できるようになります。また、インデックス登録に関する多くの問題(robots.txt による不適切な制限や Googlebot が対応できないリダイレクトなど)を特定することもできます。

    最後に、ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

    Google の検索結果に、誰もが表示できるウェブサイトを

    閲覧しようとしたページが自分の端末に対応していないという状況は、ウェブ ユーザーによくある悩ましい問題です。時には、まったく何もないページや大部分が欠けたページが表示されます。

    Google は、本日より日本でも、端末が対応していない技術が使われていると思われるページを検出した際には、モバイルの検索結果上にその旨を表示(英語)するようになりました。たとえば、Adobe Flash は、iOS や Android 4.1 以降を搭載したスマートフォンでは表示できません。このような端末では、大部分が Flash であるようなページは、モバイルの検索結果上で以下のように表示されます。


    現在使われている様々な端末に対応したウェブサイトの開発方法


    ところで、現在使われているすべての端末に対応したウェブサイトを開発することは難しくありません。HTML5  を使いましょう。HTML5 は、どのような端末でも表示されますし、HTML5 しか使えない端末さえあるからです。そこで、好きな種類のファイルをどのような端末でも表示できるようなサイトを作る一助になればとの思いから、最近、Google は次の 2 つのページを公開いたしました。
    • Web Fundamentals (英語): ウェブサイト作成のベスト プラクティスを集めた用例集。
    • Web Starter Kit (英語):  Web Fundamentals の用例を応用して、ウェブサイトを一から作るためのフレームワーク。
    Web Fundamentals に書かれた適切な作り方に従うことで、Google が推奨している、検索に適したレスポンシブ デザイン(英語)であるサイトを作ることができます。この際、Googlebot がサイトのすべてのサブ リソース(CSS、Javascript、画像ファイル等)にアクセスできるよう robots.txt などの設定をしてください。すべてのサブ リソースにアクセスできることで、Google のアルゴリズムは、ページがレスポンシブ デザインであることを検出しやすくなり、ひいては適切に評価することができます。また、ウェブマスター ツールには、インデックスに登録するアルゴリズムがどのようにウェブサイトを認識しているかを調べるための Fetch as Google という機能があります。

    ご不明な点がございましたら、ウェブマスター ヘルプ フォーラムをご利用ください。

    Webmaster Tools API を更新しました

    夏の間、ウェブマスター ツール チームは Webmaster Tools API (英語)の更新に取り組んできました。この新しい API は、他の Google API と統一されており、アプリやウェブ サービスの認証がより簡単に行えるようになりました。また、API からウェブマスター ツールのいくつかの主な機能にアクセスすることもできます。

    他の Google API を使用したことがあるなら、この新しい Webmaster Tools API も簡単に使い始めることができるでしょう。Python (英語)、Java (英語)、および(コマンドラインに慣れた方のために)OACurl (英語)のサンプルを用意しています。
    この API では次のことができます。
    • サイトの表示、追加、削除(現時点では、アカウントに最大 500 件のサイトを追加できます)
    • サイトマップの表示、追加、削除
    • 個々のサイトマップについて、警告、エラー、インデックス登録数の取得
    • サイトについて、すべての種類のクロール エラーを時系列で取得
    • 特定の種類のクロール エラーについて、サンプルを表示
    • クロール エラーを個別に「修正済み」にする(処理には影響を与えませんが、画面表示をシンプルにできます)
    この API をどうぞご活用ください。API の使用に関して不明な点がありましたら、お気軽にヘルプ フォーラムでご質問ください。

    リンク プログラムによるガイドライン違反について

    検索エンジンのランキングを操作するために PageRank を渡すリンクを売買することは、Google のウェブマスター向けガイドラインに違反しています。このことは、以前にもこのブログ上でお伝えしてきました。

    この記事では、最近 Google が対策を行った、大規模なリンク プログラムの一例をご紹介いたします。

    (例 1) 自動生成された文章に、特定のサイトへのリンクを、過度に最適化されたアンカーテキストを用いて挿入しているケースです。


    (例 2) 本来対象としているサイト以外への発リンクも設置することで自然なリンクに見せかけているケースです。


    最近 Google が対応を行ったケースでは、委託先 SEO 会社がリンク操作のネットワークを保有して依頼主に提供している例だけでなく、企業自身が主体となってリンク操作のためのネットワークを運用している例が見受けられました。そのような例に対して Google は、ウェブマスター向けガイドライン違反として適宜自動または手動による対策を実施しています。

    ウェブマスターのみなさまには、こういった PageRank を渡すリンクの操作や売買を避けることをこれまでどおり強くおすすめします。サーチ クオリティ チームは、今後とも、ユーザーのために、検索結果からのスパムの排除に全力で取り組んでまいります。

    新しいウェブマスター アカデミーが22言語でご利用いただけるようになりました


    このたび、新しいウェブマスター アカデミーが 22 言語でご利用いただけるようになりました。ウェブマスター初心者の皆様には、優れたサイトを作成する方法素晴らしいユーザー体験を提供する方法検索結果に適切に表示されるようにする方法などの基本事項を、さまざまな言語で学習していただくことができます。既によく理解している項目については、各モジュールの最後にあるクイズで理解度をテストしてみましょう。

    お好みの言語でウェブマスター アカデミーをご覧頂いたら、ぜひウェブマスター ヘルプ フォーラムでご感想をお寄せください。今年の 3 月に英語版を公開(英語)した後も、皆様からのフィードバックをいただき、参考にさせていただきました。このガイドはわかりやすく、楽しみながら読めるようになっていますので、ぜひ一通りご覧ください。きっとみなさまのお役に立てることと思います。

    優れたサイトや Google 検索との相性の良いコンテンツを作成し、世界中のユーザーにアクセスしてもらいましょう。

    検索結果内の検索ボックスが新しくなりました

    このたび、サイトリンクの検索ボックスが新しくなりましたのでお知らせいたします。この検索ボックスを使用すると、ユーザーはサイト独自の検索ページを通じて直接サイト内の特定のコンテンツに簡単にアクセスできるようになります。

    この検索ボックスの仕組みと検索結果に表示されるタイミング


    たとえば [ABC 出版] や [株式会社 XYZ] のように名前で会社を検索する場合、ユーザーは実際にはそのウェブサイト内の特定の情報を探しているかもしれません。今までは、Google のアルゴリズムでこのような検索キーワードが認識されると、多数のサイトリンクが表示され、その検索結果の下に追加の検索ボックスが表示されていました。ユーザーはこの検索ボックスを使用して検索結果から直接、このサイトにsite: 検索を行うことができます(例: [site:example.com 登山ガイド])。

    今回は、この検索ボックスが改良され、オートコンプリートにも対応しました。正しいマークアップが使用されていれば、ユーザーはウェブサイトの独自の検索ページに直接リダイレクトされます。


    サイトをマークアップする方法


    サイトでは、サイト固有の検索エンジンを使用している必要があります。既に使用している場合は、schema.org/SearchAction (英語)マークアップの potentialAction プロパティ(英語)を使用して、ホームページを schema.org/WebSite (英語)エンティティとしてマークアップすることで Google に知らせることができます。マークアップには、JSON LD、microdata、RDFa を使用できます。実装について詳しくは、デベロッパー サイト(英語)をご確認ください。

    サイトにマークアップを実装すると、ユーザーはサイトリンク検索ボックスから直接、サイトの検索結果ページにジャンプできるようになります。マークアップがない場合は、今までと同様に「site: 検索キーワード」に一致する Google 検索結果ページが表示されます。

    ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムでご質問ください。

    Apache や Nginx での帯域幅の最適化について

    本記事でご紹介するデベロッパー サイトは、現時点ではまだ日本語に翻訳されていませんが、日本のみなさまにもご利用いただける内容であり、有益であると思いますのでご紹介させていただきます。

    誰もが帯域幅の使用量を削減したいと考えています。ホスティング プロバイダーは料金を節約したいと考えていますし、モバイル ユーザーは使用制限の範囲内に収めたいと思っています。そして、不必要なバイト数の読み込みを待ちたいと思っている人は誰もいません。ウェブには帯域幅を節約できるチャンスがたくさんあります。たとえば、gzip せずに提供されているページ、縮小化されていないスタイルシートや JavaScript、最適化されていない画像などです。

    では、なぜウェブは帯域幅用に最適化されていないのでしょうか。このような節約が誰にとっても有益なら、なぜ誰も実行しないのでしょうか。ほとんどの場合、こういった変更は大変面倒な作業だからです。ウェブ デザイナーはアートワークをエクスポートする際に「ウェブ用に保存」することが奨励されていますが、いつも忘れてしまいます。JavaScript プログラマーは、デバッグが困難になるからという理由でコードの縮小化を好みません。開発や展開のプロセスの一環として、これらの最適化がそれぞれサイトに毎回適用されるようにするカスタム パイプラインを設定することもできますが、大変手間がかかります。

    ウェブ ユーザーにとっての簡単な解決策は、Chrome のようにデータを自動的に最適化し、圧縮してくれるプロキシを使用することです。ユーザーがこのサービスを使用すると、HTTP トラフィックが Google のプロキシ経由となり、ページの読み込みが最適化され、帯域幅の使用も 50% 削減されます。これは有益な方法ではありますが、この機能をオンにしている Chrome ユーザーのみに限定されます。また HTTPS トラフィックを最適化することはできません。

    PageSpeed チームは、帯域幅の最適化機能によってウェブマスターの皆様に同様のテクノロジを提供いたします。これにより、他のブラウザのユーザー、安全なサイト、デスクトップ ユーザーに加え、アウトバウンド トラフィックの料金を低く抑えたいサイト所有者も、最適化を実現できるようになりました。PageSpeed モジュールを Apache または Nginx サーバーにインストールし [1]、設定で帯域幅の最適化機能を有効にすれば、後は PageSpeed がすべて解決してくれます。

    キャッシュの拡張インライン化から、より積極的な機能である画像の遅延読み込みJavaScript の遅延実行まで、PageSpeed の高度な最適化機能は、後からでも PageSpeed 設定で有効にするだけで使用できます。

    詳しくは、PageSpeed のインストール方法帯域幅の最適化を有効にする方法のページをご覧ください。



    [1] 別のウェブサーバーをお使いの場合は、Apache または Nginx プロキシでの PageSpeed の実行をご検討ください。このモジュールは完全なオープンソースであり、現在は IIS (英語)、ATS (英語)などへの移植が進行中です。