投稿者: Google Webmaster Central

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

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 が対応できないリダイレクトなど）を特定することもできます。

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

    Posted by Pierre Far, Webmaster Trends Analyst
    Original version: Updating our technical Webmaster Guidelines

    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 という機能があります。

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

    Posted by Keita Oda, Software Engineer, and Pierre Far, Webmaster Trends Analyst
    Original version: Promoting modern websites for modern devices in Google search results

    Webmaster Tools API を更新しました

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

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

    Posted by John Mueller, fan of long command lines, Google Zuerich

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

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

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

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


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


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

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

    Google サーチ クオリティ チーム

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


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

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

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

    Posted by Mary Chen, Webmaster Outreach
    Original version: Official Google Webmaster Central Blog: Webmaster Academy now available in 22 languages

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

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

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


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

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


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


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

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

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

    Posted by Mariya Moeva, Webmaster Trends Analyst, and Kaylin Spitz, Software Engineer
    Original version: Official Google Webmaster Central Blog: An improved search box within the search results

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

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

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

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

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

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

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

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

    Posted by Jeff Kaufman, Make the Web Fast
    Original version: Official Google Webmaster Central Blog: Optimizing for Bandwidth on Apache and Nginx

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

    不正なハッキングに対する #NoHacked キャンペーンを世界中で実施しました

    先日、Google サーチ クオリティ チームでは、#NoHacked キャンペーンと題して、サイトの不正なハッキングの問題を改めて知り、サイトを守るための Tips （ヒント）を 1 週間毎日発信するキャンペーンを全世界で行いました。

    このキャンペーンは、11 言語圏でGoogle+や Twitter、Weiboなど様々なチャンネルを舞台に実施しました。延べ 100 万人近い方が閲覧し、何百もの投稿の共有や、 #NoHacked のハッシュタグを使ったユーザー オリジナルの Tips 投稿が行われました。

    ここで、Google が投稿した 5 つの Tips を改めてご紹介するとともに、世界中から寄せられた素晴らしい投稿の一部をご紹介します。

    Tips その 1:
    今週はハッキングの予防について考えよう！

    Tips その 2:
    ウェブマスター ツールはハッキングからサイトを守る上でも役立ちます。使っていない方はぜひ登録を。お友達にもお知らせください。

    Tips その 3 :
    Google アラートを設定してハッキングの兆候をいち早くつかもう。

    Tips その 4:
    ソフトウェアは常に最新のものにアップデートしておこう。

    Tips その 5:
    ユーザーから寄せられたベスト投稿を発表！（各言語でベスト投稿を発表しました）

    世界中から寄せられた投稿のご紹介

    • ブラジルの Pablo Silvio Esquivel さんは海賊版ソフトウェアを使うことがハッキング被害の危険性につながることを紹介してくれました。
      https://plus.google.com/+PabloSilvioEsquivel/posts/9ahpESFwuac
    • オランダの Rens Blom さんは、パスワードを複数のアカウントで使いまわさず定期的に変更すること、そして 二段階認証 などのセキュリティ機能も使うことをおすすめしてくれました。
      https://plus.google.com/+GoogleNederland/posts/48e3VAsxddS
    • ロシアの Дмитрий Комягин さんは、日頃からサイトへのトラフィックや、検索クエリ、ランディング ページなどをモニターし、数値の想定外の急上昇などがないか把握しておくという方法を投稿してくれました。
      https://plus.google.com/+googleru/posts/CYwe6xf3Xvm
    • 日本の工務店コンサルタントさんは、実際に被害に遭われた際のレポートとそこから得た教訓として、ハッキング対策を適切に行っているホスティングを選ぶこと、ウェブマスター ツールのメール転送機能を設定しておくことなどを詳しくご紹介してくださいました。
      https://plus.google.com/+Asanoyukinobu/posts/hsKmoc2v2cZ
    • ポーランドの Kamil Guzdek さんは、WordPress をインストールした際に、table prefix をデフォルトのものからユニークなものへ変更することで、データベースがハッキングされるのを防ぐという tips を紹介してくれました。
      https://plus.google.com/+KamilGuzdek/posts/Gu63giLNTiZ
    今回、世界同時でキャンペーンを行ったこと、そして、世界中のユーザーからサイトの不正なハッキング対策が多く寄せられたことからもわかるように、サイトの不正なハッキングの問題は全世界的に広がりを見せています。どうぞ今回ご紹介した Tips と共に以下のサイトも参考にし、ご自身のサイトの設定をもう一度確認してみてください。
    ハッキングされたサイトに関するウェブマスター ヘルプ
    http://www.google.co.jp/webmasters/hacked/

    これからも全世界で Tips を共有し、サイトのハッキングと闘いましょう！ #NoHacked のハッシュタグはこれからもご利用ください。また質問がある際はウェブマスター ヘルプ フォーラムをご利用ください（ハッキングに関するカテゴリも用意しています）。

    Google では今後もユーザー、ウェブマスターのみなさまのお役に立てる情報をどんどん発信していきたいと思っておりますので、ぜひ Google Webmasters ページ、Google Japan ウェブマスター コミュニティをフォローしてみてください。

    Posted by your friendly #NoHacked helpers

    HTTPS をランキング シグナルに使用します

    セキュリティは Google の最優先事項です。Google は、デフォルトで強力な HTTPS 暗号化を導入するなど、業界でも最先端のセキュリティを Google サービスに導入することに力を注いでいます。これにより、たとえば Google 検索、Gmail、Google ドライブを使用しているユーザーは自動的に、Google に安全に接続することができます。

    Google は、Google のサービスだけにとどまらず、より広い範囲でインターネットを安全に利用できるように取り組んでいます。そこで大きな割合を占めているのは、ユーザーが Google から安全なサイトにアクセスできるようにすることです。たとえば、Google ではウェブマスター向けにハッキングの対策や修正方法について詳しい情報を提供するサイトを作成しました。

    Google ではさらにもう一歩踏み込んで、数か月前の Google I/O では、「HTTPS everywhere」をウェブで提唱しました。

    また、ますます多くのウェブマスターが HTTPS（HTTP over TLS / Transport Layer Security）を彼らのサイトに導入するようになってきています。これはとても心強いことです。

    こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。


    Google は、みなさんがより簡単に TLS を導入し、よくある失敗を避けられるように、今後数週間のうちに詳細なベスト プラクティスを公開する予定です。開始にあたって、以下の基本的なヒントもご確認ください。
    • 必要な証明書タイプを決定します: シングル、マルチ ドメイン、ワイルド カード
    • < 2048 bit の証明書を使用します
    • 同じ安全なドメイン上にあるリソースには相対 URL を使用します
    • 他のすべてのドメインにはプロトコル相対 URL を使用します
    • サイトのアドレスの変更方法について詳しくは、サイト移転に関するヘルプ記事をご覧ください
    • robots.txt を使用して HTTPS サイトへのクロールをブロックしないでください
    • 可能な限り検索エンジンがページをインデックス登録できるようにします。Noindex メタタグの使用は避けます。
    サイトが既に HTTPS で配信されている場合は、Qualys Lab ツールを使用してウェブサイトのセキュリティ レベルと設定をテストできます。TLS とサイト パフォーマンスについて不安がある場合は、「Is TLS fast yet?」（英語）をご覧ください。また、ご質問やご不明な点がある場合は、ウェブマスター ヘルプ フォーラムでお尋ねください。

    このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。

    今後、より多くのウェブサイトで HTTPS が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。

    Posted by Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts
    Original version: HTTPS as a ranking signal

    robots.txt ファイルのテストが簡単になりました

    クロールするべきか、しないべきか、それが robots.txt の問題です。

    正しい robots.txt ファイルを作成して維持することは、ときに難しい場合もあります。ほとんどの場合はそうではありませんが（そもそも robots.txt ファイルを必要としないサイトも多くあります）、大きな robots.txt ファイル内で個々の URL をブロックしている（またはブロックしていた）指定を見つけることは、難しい作業となる場合もあるでしょう。そこで、robots.txt ファイルの編集を容易にするために、このたび、新しい robots.txt テスターを発表いたします。

    新しいテスターは、ウェブマスター ツールの [クロール] セクションにあります:


    ここでは、現在の robots.txt ファイルの確認、および URL のクロールがブロックされているかどうかのテストを行うことができます。複雑な指定をわかりやすくするため、最終的に決定に使われた箇所がハイライト表示されます。ファイルに変更を加えてテストを行うこともできます。変更を有効にするには、変更したファイルをサーバーにアップロードしてください。Google のデベロッパー サイトでは、robots.txt の指定とファイルの処理方法について詳しく説明しています (英語)。

    また、古いバージョンの robots.txt を確認したり、サーバー側の問題によってクロールがブロックされている状況を確認したりすることもできます。たとえば、robots.txt ファイルが Googlebot に対して 500 サーバー エラーを返している場合、通常そのサイトのクロールは一時停止されます。

    既存のサイトでエラーや警告が表示される可能性もあるため、robots.txt ファイルをよく確認することをおすすめします。また、robots.txt テスターをウェブマスター ツールの他の機能と組み合わせることも可能です。たとえば、新しい Fetch as Google を使用してウェブサイトの重要なページをレンダリングした際、ブロックされた URL が見つかったら、robots.txt テスターを使って、その URL をブロックしている指定を見つけて修正することができます。CSS、JavaScript、モバイル コンテンツをブロックする古い robots.txt ファイルが原因で問題が発生することはしばしばありますので、そのような問題は、修正すべき箇所がわかれば簡単に修正できます。

    今回更新したツールを使うことで robots.txt のテストとメンテナンスが容易になれば幸いです。何かご不明な点がある場合や、robots.txt の指定の作成についてアドバイスが欲しい場合などは、ぜひウェブマスター ヘルプ フォーラムをご利用ください。

    Posted by Asaph Arnon, Webmaster Tools team
    Original version: Official Google Webmaster Central Blog: Testing robots.txt files made easier

    ウェブマスター ツールで hreflang のアノテーションに関するトラブルシューティングができるようになりました

    複数の国のユーザーをターゲットとしているウェブマスターの方は、rel-alternate-hreflang について耳にされたことがあるかと思います。まだこの機能をご存知でない方のために簡単にご説明しますと、このアノテーションにより Google などの検索エンジンが適切な言語や地域のバージョンのページを検索ユーザーに表示できるようになり、結果としてユーザーの満足度の向上につながります。

    実装したこのアノテーションが検索エンジンで使用できる状態であるかどうかを確認することは、特にページが多くあるサイトでは容易ではなく、この点については世界中のサイト運営者の方から声が上がっています。そこで Google では本日、rel-alternate-hreflang アノテーションのデバッグを簡単に行うことができる機能を公開します。

    [インターナショナル ターゲティング] 機能の [ターゲット言語] セクションで、hreflang アノテーションによく見られる 2 つの問題を特定できます:
    • リターン リンクの欠落: アノテーションは、そのアノテーションが参照しているページから確認する必要があります。ページ A がページ B にリンクしている場合、ページ B からもページ A にリンクしていなければなりません。そうでない場合、アノテーションが正しく解釈されない恐れがあります。
      この種のすべてのエラーについて、検出した場所と日時、リターン リンクが配置されるべき場所が表示されます。
    • 不適切な hreflang 値: hreflang 属性の値は、ISO 639-1 形式で指定した言語コード（「es」など）か、国コード（ISO 3166-1 Alpha 2 形式で指定）と言語コードの組み合わせ（「es-AR」など）のいずれかである必要があります。
      Google のインデックス登録システムがこれらの形式以外で指定された言語コードや国コードを検出した場合は、URL の修正例が表示されます。

    さらに、地域ターゲットの設定をウェブマスター ツールのこの機能に移行し、インターナショナルおよび多言語ターゲティングに関連するすべての情報を 1 か所で確認できるようにしました。

    この新機能が、サイトでの rel-hreflang 実装に関する問題を解決する際の一助となりましたら幸いです。この機能についてご不明な点やご意見、ご感想などがありましたら、ウェブマスター ヘルプ フォーラムにご投稿ください。

    Posted by Gary Illyes, Webmaster Trends
    Original version: Official Google Webmaster Central Blog: Troubleshooting hreflang annotations in Webmaster Tools

    Android の App Indexing が誰でもご利用いただけるようになりました！

    もしあなたがウェブサイトと Android アプリを両方持っているのなら、それらを連携させることで、スマートフォンやタブレットから Google で検索しているユーザーにとって、検索結果からアプリへの起動を非常に簡単にすることができるようになりました。

    検索結果に表示されるアプリのディープリンクは、あなたのアプリが既にインストールされている端末の検索結果において、アプリ内のコンテンツへのアクセスをより容易にします。ウェブサイトのページを対応するアプリ側の部分へと接続することで、サイトオーナーとして、適切なコンテンツを、適切なタイミングでユーザーに見せることができるようになります。


    いくつものアプリが既に App Indexing を実装しています。今週の Google I/O で、ディープリンクの設定、サイトのアプリへの接続、パフォーマンスやエラーのトラッキングといった一連のプロセスをより容易にするための機能を発表いたしました。

    簡単に始められます

    このたび、アプリのディープリンクをインデックスさせるために必要なプロセスを大きく簡易化しました。アプリが既に HTTP によるリンクをサポートしているのであれば、
    あなたの URL 群がインデックスされると共に、Google はアプリとサイトの繋がりを発見し、検索結果でディープリンクを使用したアプリへの直接的な遷移を可能にします。

    アプリのディープリンクの発見とインデックス作業を Google に任せることもできますが、あなた自身がこれらのディープリンクを埋め込み、公開することをおすすめします。もしあなたのアプリがカスタム ディープリンクスキームをサポートしている場合は特にそうです。そのためには、2 つの方法があります:
    • 各ウェブページに対して、rel="alternate" 属性を持った link 要素を <head> 部分に埋め込むか、サイトマップを利用して android-app URI を指定する。デベロッパー サイト上で実装方法を確認できます。
    • App Indexing API （英語）を利用する。
    また、このたび、アプリページをインデックスする際に発生した問題について報告を行う新しい機能をウェブマスター ツールに追加しました。ここでは、各アプリページとウェブページのペアについて検知されたエラーと、デバッグのためのサンプル アプリ URI確認することができます。


    また、それぞれの問題について、その詳細なデバッグ方法も確認することができます。アプリのディープリンクの QR コードも含まれていますので、携帯電話やタブレットで簡単にリンクを開けます。エラーが検知された場合、ウェブマスター ツール上でメッセージもお送りいたします。


    App Indexingは既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。


    ぜひ App indexing をお試しください。何かご質問があれば、ウェブマスター ヘルプ フォーラムへ！

    Posted by Mariya Moeva, Webmaster Trends Analyst
    Original version: Android app indexing is now open for everyone!

    サイトの移転をより容易に

    ウェブマスターの皆様にとって、サイトの移転ほど厄介で悩ましい問題はないかもしれません。このたび Google では、スムーズなサイト移転をサポートすることを目的に、Googlebot と相性の良い移転の方法についての詳細なガイドを作成しました。では、サイト移転とは正確には何であり、それを適切に行うにはどうすればよいのでしょうか。


    サイト移転の基本


    一般的に、サイト移転とは、以下のいずれかの方法でコンテンツを移動させることです。
    • URL を変更せずにサイトを移転する: URL 構造には変更を加えずに、ウェブサイトをホストしている基底のインフラストラクチャのみを変更します。たとえば、www.example.com を、同じ URL とサイト構造を維持したまま別のホスティング プロバイダに移行する場合などがこれにあたります。
    • URL を変更してサイトを移転する: この場合、ウェブサイトの URL の変更にはさまざまなパターンがあります。
    • プロトコル: http://www.example.com を https://www.example.com に変更する
    • ドメイン名: example.com を example.net に変更する
    • URL のパス: http://example.com/page.php?id=1 を http://example.com/widget に変更する
    サイトの移転が適切に行われていないケースや、サイトの移転を問題なく完了するうえで非常に重要となる手順が踏まれていないケースも多く見られます。そこで Google では、ウェブマスターの皆様が適切にサイトの移転を計画、実施できるよう、ヘルプセンターのサイト移転ガイドラインを更新しました。また同時に、このガイドラインに沿ってサイトの移転が行われた場合にサイトの移転を検出して処理できるよう、クロールとインデックス登録のシステムの改良も続けています。

    レスポンシブ ウェブ デザインへの変更


    モバイル用の URL を別に設定している場合や動的配信を行っている場合にウェブサイトでレスポンシブ ウェブ デザインを使用するよう変更するにはどうすればよいか、といった質問も増えつつあります。この設定の変更について詳しくは、スマートフォン向けサイトの推奨事項についてまとめたサイトに新たに追加されたこちらのページをご覧ください。

    ご不明な点がある場合はウェブマスター ヘルプ フォーラムで質問してみてください。

    Posted by Pierre Far and Zineb Ait Bahajji, Webmaster Trends Analysts
    Original version: Official Google Webmaster Central Blog: Making site moves easier

    「Hosting Meetup @ Google」を開催しました！

    Google は 5 月 15 日、ホスティング サービスの運営者のみなさまを対象にしたイベント「Hosting Meetup @ Google」を開催しました。今回は、そのイベントの様子をご紹介します。


    ブログなどのホスティング サービスは、低コストで簡単に利用できることから広く利用されています。一方で、その利便性を悪用し、Google のウェブマスター向けガイドラインに違反するようなスパム目的に利用されるケースがあることもわかっています。

    今回のイベントは、こうした背景から、Google 検索と相性のよいホスティング サービスの運営について考えることを目的として実施しました。

    当日は、ウェブマスター ツールや構造化データ、複数デバイス対応などに関して、Google 検索と相性の良いホスティング サービス運営のためのヒントのご紹介と、ホスティング サービス上でよく見られるウェブマスター向けガイドライン違反（ウェブ スパム）について、その傾向や対処方法などをお話しました。



    ホスティング サービスからウェブ スパムがなくなり、かつ、Google 検索と相性の良いサイト構築を心がけていただくことで、Google がホスティング上のサイトを見つけやすくなり、より多くの検索ユーザーがそうしたサイトを訪問する可能性が高まります。

    そのための具体的なアクションとしては、

    ウェブ スパムの削減について（関連ヘルプ記事）
    • スパム ポリシーの制定・見直し
    • スパムへの対処（サイトの自動生成の禁止。Captcha の導入、違反箇所の修正方法、スパム サイトへの対処方法など）
    • ユーザーへの啓蒙
    • ウェブマスター ツールをユーザーが利用できるようにする
    Google と相性の良いサイトの構築のヒント
    • ウェブマスター ツールの活用
    • 構造化データの導入
    • 適切な複数デバイス対応
    こういった内容をぜひサービスの運営に取り入れていただき、Google 検索と相性のよいサービスの運営を行っていただければと思います。

    ホスティング サービスの運営者の方々からも Google のウェブマスター向けガイドラインについてのご質問や、スパムへの対処方法のベスト プラクティスについてのご質問など、数多くのご質問をいただき、非常に有意義な意見交換をすることができました。

    ご参加いただきましたみなさま、ありがとうございました！


    また、今回イベントに参加できなかったホスティング サービスのみなさまのために、同一の内容をテーマとしたウェブマスター ハングアウトを実施いたしますので、ぜひご参加ください。

    イベント詳細
    2014 年 6 月 10 日 12 時 ~ 12 時 30 分

    あわせてホスティング サービスの運営者のみなさまを対象とした情報をまとめたサイトを設けました。今回のイベントでお話した内容や、関連する情報についてまとめて掲載しておりますのでぜひご覧ください。

    今後も、ウェブマスター ハングアウトやGoogle+ Webmaster Japan コミュニティなどを通してウェブマスターのみなさまの疑問にお答えしたり、交流を図っていきたいと思いますので、ぜひご参加ください！

    Google サーチ クオリティ チーム

    Fetch as Google でページをレンダリングできるようになりました

    ウェブマスター ツールの Fetch as Google 機能を使用すると、Googlebot がどのようにページを取得しているかを確認できます。ここで表示されるサーバー ヘッダーや HTMLは、技術的問題やハッキングの影響を診断するのに役立ちますが、その理解が難しい場合もあるでしょう。「このコードの意味は何？」、「本当に自分のブラウザで見ているのと同じページなんだろうか？」「今日の昼ごはんはどこで食べよう？」...。昼ごはんをどこで食べるかについてはお助けできませんが、他の問題を解決するために、このたび Google はウェブマスター ツールを拡張し、Google がページをどのようにレンダリングしているかを確認できるようにしました。

    レンダリングされたページを表示する

    Googlebot は、ページをレンダリングする際、そのページに関係するすべての外部ファイルをできるだけ見つけて取得しようとします。その際、画像、CSS、JavaScript ファイルだけでなく、CSS や JavaScript によって間接的に埋め込まれるファイルも取得した上で、Googlebot のページ認識のプレビュー画像を描画することになります。

    Fetch as Google 機能は、ウェブマスター ツールの [クロール] セクションにあります。[取得してレンダリング] をクリックして URL を送信して処理が完了するのを待ちます（ページによっては少し時間がかかる場合があります）。処理が完了したら、表示された行をクリックして結果を確認します。


    robots.txt によってブロックされたリソースの取り扱い

    Googlebot は、すべてのファイルを robots.txt の指示に従って取得します。クロールを許可していないファイルがある場合（または、Googlebot のクロールが許可されていないサードパーティ サーバーからファイルを埋め込んでいる場合）、そのファイルはレンダリング時に利用できません。同じように、サーバーが応答しない場合やエラーが返された場合も、それらのファイルを利用することはできません（こうした問題の詳細は、ウェブマスター ツールの [クロール エラー] セクションで確認できます）。こうした問題が発生した場合は、プレビュー画像の下に詳細が表示されます。

    サイトに表示されるコンテンツやそのレイアウトに大きく影響する埋め込みリソースについては、Googlebot がアクセスできるかどうかを確認しておくことをおすすめします。Fetch as Google が使いやすくなるだけでなく、Googlebot がそれらのコンテンツを見つけてインデックスに登録することが可能になります。サイトに表示されるコンテンツやそのレイアウトにあまり影響しない一部のコンテンツ タイプ（ソーシャル メディア ボタン、フォント、ウェブサイト分析スクリプトなど）は、クロールできない状態のままでも構いません。詳しくは、以前ブログに投稿した「ウェブページをより深く理解するようになりました」という記事をご覧ください。

    今回のアップデートによって問題の診断が容易になり、誤ってクロールがブロックされていたコンテンツが発見され、クロールされるようになることを願っております。ご不明な点やご意見などありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

    Posted by Shimi Salant, Webmaster Tools team
    Original version: Official Google Webmaster Central Blog: Rendering pages with Fetch as Google

    ウェブページをより深く理解するようになりました

    Google のサーバーが Susan Wojcicki のガレージで動いていた 1998 当時は、JavaScript や CSS はあまり気にかける必要もありませんでした。それらはあまり使用されておらず、JavaScript はページ要素にちょっとした動きなどを加えるために使用されてるだけでした。そのときと今では状況が大きく変わりました。今やウェブの世界は、JavaScript を最大限に活用したリッチでダイナミックで魅力的なウェブサイトであふれています。今回は、よりリッチなウェブサイトをレンダリングする Google の能力についてご紹介します。Google は現在、最新のウェブ ブラウザに近いコンテンツの表示、外部リソースの追加、JavaScript の実行、CSS の適用を実現しています。

    以前は、HTTP レスポンスのボディから取得されるテキスト形式のコンテンツだけが認識されており、JavaScript が動作する一般的なブラウザにどのようなコンテンツが実際に表示されているかを解釈することは行っていませんでした。JavaScript を使用した時にのみ表示される価値のあるコンテンツを表示するページ群が登場しても、検索ユーザーにそのコンテンツの情報を伝えることはできませんでした。これは検索ユーザーとウェブマスターの両方にとって悲しい結末です。

    この問題を解決するために、Google では JavaScript を実行してページを把握する方法を試すことにしました。現在のウェブの規模でそれを行うことは困難ですが、やるだけの価値はあると判断したのです。これを実現するため、Google のシステムは、時間をかけて徐々に改良されてきました。ここ数か月間、Google のインデックス登録システムは、かなりの数のウェブページを JavaScript が有効な一般ユーザーのブラウザのようにレンダリングしています。

    場合によっては、レンダリング時の処理が完全にはうまくいかないこともあり、皆様のサイトの検索結果に影響を及ぼす可能性があります。その場合の考えられる原因と、その問題の回避方法（可能な場合）の例を以下にご紹介いたします。
    • 別々のファイルにある JavaScript や CSS などのリソースが（robots.txt などにより）Googlebot をブロックしている場合、Google のインデクシング システムは、そのサイトを一般ユーザーと同様には認識できません。皆様のコンテンツをインデックス登録できるように JavaScript や CSS の取得を Googlebot に許可することをおすすめします。これは、モバイル向けのウェブサイトでは特に重要です。あるページがモバイル向けに最適化されているかを Google のアルゴリズムが識別するうえで、CSS や JavaScript などの外部リソースが必要になるためです。
    • ウェブ サーバーが一定数のクロール リクエストを処理できない場合、ページをレンダリングする Google の機能に影響を及ぼす可能性があります。Google がページをレンダリングできるかどうかを確認したい場合は、ご利用のサーバーでリソースのクロール リクエストを処理できるかどうかをご確認ください。
    • 常に有効なのは、サイトで最新の機能を使わないようにすることです。この方法を使えば、ユーザーのブラウザが互換性のある JavaScript を実装していなくてもコンテンツを表示できます。JavaScript が無効またはオフになっていても、JavaScript をまだ実行できない検索エンジンでも大丈夫です。
    • 場合によっては、JavaScript が複雑すぎたり特殊すぎたりして、Google で実行できないこともあります。このような場合は、ページを完全に正しくレンダリングすることはできません。
    • JavaScript によっては、コンテンツを追加するのではなく削除するものもあります。こういった場合、コンテンツのインデックス登録はできなくなってしまいます。
    現在 Google ではデバッグがより簡単にできるように、ウェブマスターの皆様が Google によるサイトのレンダリング状況を詳しく把握できるようなツールの開発に取り組んでおります。近いうちにウェブマスター ツールで皆様にご提供する予定です。

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

    Posted by Erik Hendriks and Michael Xu, Software Engineers, and Kazushi Nagayama, Webmaster Trends Analyst
    Original version: Official Google Webmaster Central Blog: Understanding web pages better

    PageSpeed Insights を使ってサイトのモバイル操作性を向上させましょう

    モバイル対応のページを作成するデベロッパーやウェブマスターの皆さんのお役に立てるよう、Google ではこのたび、PageSpeed Insights の見直しを行い、モバイルでの操作性に関する推奨事項を新たに追加しました。


    ページの読み込みが速くても、操作性が低ければその効果が損なわれかねません。Google の調査では、平均的なモバイル ページの読み込みには少なくとも 7 秒はかかる（英語記事）ことがわかっています。PageSpeed Insights ツールを使用し、そこで提示される速度についての提案を活用することで、ページ読み込みの速度を改善することは可能です。では、モバイル サイトの読み込みに 7 秒もかからず 2 秒で済む場合を考えてみましょう。ページの読み込み後、モバイル ユーザーがテキストを読んだりページを操作したりするために、画面をピンチズームしたりスクロールしたりして 5 秒かかってしまったら、ユーザーの体験としてはそのサイトは速いとは言えません。PageSpeed Insights が新しく提案するユーザー エクスペリエンスに関するルールを参考にすれば、こうした操作性についての問題点を見つけ出し、修正することができます。

    この新たな推奨事項では、現在のところ次のような対策を紹介しています。
    • viewport を設定する: viewport メタ タグが指定されていないページは、最新のモバイル ブラウザではモバイル非対応ページとみなされてデスクトップ向けのビューポートとして処理され、さらにはフォント拡大が適用される可能性もあるため、意図したとおりのページ レイアウトで表示されないことがあります。モバイルに適したサイトにするためには、まず viewport の設定で width=device-width を使用しましょう。
    • コンテンツのサイズを viewport に合わせる: ユーザーは、モバイル サイトは横ではなく縦にスクロールするものと思っています。viewport を設定したら、ページのコンテンツがその viewport の幅に収まっていることを確認してください。その際、携帯端末の幅は機種によって異なることに注意が必要です。
    • 読みやすいフォント サイズを使用する: ユーザーがスマートフォンで記事を読むときに拡大しないと文字が読めないとしたら、それはモバイルに適したサイトとは言えません。PageSpeed Insights では、大部分のユーザーにとって読みやすい大きさの文字かどうかをチェックします。
    • タップ ターゲットのサイズを適切に調整する: 携帯電話やタブレットのタッチスクリーンでボタンやリンクをタップしようとして、間違えて誤ったターゲットをタップしてしまうことがあります。これは、パソコンのマウス カーソルと比べて指の腹の方が大きいためですが、とても煩わしいものです。モバイル サイトのタッチスクリーンのタップ ターゲットは押しやすいように十分大きくするようにしてください。
    • プラグインを使用しない: ほとんどのスマートフォンでは、Flash などのブラウザ プラグインをサポートしていません。そのため、モバイル サイトでもプラグインを使用しないようにします。
    これらのルールについては、PageSpeed Insights のヘルプ ページに詳しい説明があります。準備ができたら、PageSpeed Insights ツールを使ってページをテストし、改善点を確認してみてください。なお、今回の PageSpeed Insights の更新により、モバイル対応のデザインを使用できるようにもなりました。また、ヘルプ ドキュメントの翻訳版が公開され、さまざまな言語でご利用いただけるようになっています。

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

    Posted by Matthew Steele and Doantam Phan, PageSpeed Insights team
    Original version: Official Google Webmaster Central Blog: Making your site more mobile-friendly with PageSpeed Insights

    海外のユーザーに適したホームページの作成

    複数の国で事業を行っている場合や複数の言語をターゲットとしている場合は、それぞれの国または言語をターゲットとする URL に応じたコンテンツを含むサイトまたはセクションを別個に提供することをおすすめします。たとえば、ターゲット地域を米国に、ターゲット言語を英語に設定したページと、ターゲット地域をフランスに、ターゲット言語をフランス語に設定したページを用意します。多地域、多言語のサイトの処理について別の記事でご説明していますが、ホームページはやや特別です。この記事では、言語や地域に応じてユーザーにふさわしいコンテンツを提供できるよう、ウェブサイトに適切なホームページを作成する方法について解説します。

    ユーザーがアクセスしたときのホームページ/リンク先ページの動作を設定する場合、次の 3 つのパターンがあります:
    • すべてのユーザーに同じコンテンツを表示する。
    • ユーザーが選択できるようにする。
    • ユーザーの地域と言語に応じたコンテンツを配信する。
    それぞれの設定について詳しく見ていきましょう。

    世界中のユーザーに同じコンテンツを表示する


    このシナリオでは、ある 1 つの国/言語に固有のコンテンツをホームページ/汎用 URL（http://www.example.com）で配信します。このコンテンツは、ブラウザでその URL に直接アクセスしたユーザー全員と、その URL を指定して検索したユーザー全員に表示されます。上で述べたように、それぞれの国と言語のバージョンもそれぞれ固有の URL でアクセスできるようにする必要があります。


    注: 別の地域のユーザーや別の言語を設定しているユーザーに対し、より適切なバージョンのコンテンツが用意されていることを知らせるバナーをページに表示することができます。

    ユーザーがローカル バージョンと言語を自由に選択できるようにする


    この設定では、ホームページ/汎用 URL で国選択ページを提供し、ユーザーが国と言語に応じて表示したいコンテンツを選択できるようにします。その URL を入力したすべてのユーザーは同じページにアクセスすることになります。

    国際化したサイトでこのシナリオを実装する場合は、国選択ページに x-default rel-alternate-hreflang アノテーションを必ず使用するようにしてください。このアノテーションは、特にこのようなページで使用する目的で作成されています。x-default 値は、1 つの言語または地域に固有ではないページを Google が認識しやすくするためのものです。


    ユーザーの地域や言語設定に応じて、ユーザーを自動的にリダイレクトする、または適切な HTML コンテンツを動的に配信する


    この 3 番目のシナリオでは、ユーザーの地域や言語設定に応じて、適切な HTML コンテンツを自動的に配信します。このシナリオの実装は、サーバー サイドで 302 リダイレクトを使用するか、適切な HTML コンテンツを動的に配信することで実現できます。

    ホームページ/汎用ページでは必ず x-default rel-alternate-hreflang アノテーションを使用してください（汎用ページが、ユーザーが直接アクセスできないリダイレクト ページである場合も同様です）。

    注: 特定のバージョンを用意していないユーザー層のリダイレクトについても考慮する必要があります。たとえば、英語、スペイン語、中国語のバージョンが用意されているウェブサイトにフランス語を使用するユーザーがアクセスしたとします。この場合は、最も適切であると思われるコンテンツを表示することになります。

    いずれの設定を選択した場合でも、国や言語の選択ページを含むすべてのページが次の条件を満たしている必要があります:
    • Googlebot がアクセスしてクロールおよびインデックス登録できる: ローカライズされたページのクロールおよびインデックス登録がブロックされないようにしてください。
    • ユーザーが必ずローカル バージョンまたは言語を切り替えることができる: たとえばプルダウン メニューを使用して、これを実現できます。
    注: 冒頭で述べたように、国や言語のバージョンごとに別個の URL を用意する必要があります。

    rel-alternate-hreflang アノテーションについて


    どの方法を選択したかにかかわらず、必ずすべてのページにアノテーションを追加してください。アノテーションにより、検索エンジンで適切な結果がユーザーに表示される可能性が大幅に高くなります。

    国選択ページ、リダイレクトまたは動的に配信されるホームページでは必ず x-default hreflang を使用する必要があります。これは、自動的にリダイレクトされるホームページや国選択専用のアノテーションです。

    最後に、rel-alternate-hreflang アノテーションに関して役立つ一般的な注意事項をいくつかご紹介します:
    • アノテーションは、他のページにおいても確認する必要があります。ページ A がページ B にリンクしている場合、ページ B からもページ A にリンクしていなければなりません。そうでない場合、アノテーションが正しく解釈されない恐れがあります。
    • アノテーションは自分に対しても向いていなければなりません。ページ A で、そのページ自身をリンク先とした rel-alternate-hreflang アノテーションを使用する必要があります。
    • rel-alternate-hreflang アノテーションは、HTTP ヘッダー、HTML の head セクション、またはサイトマップ ファイルで指定できます。シグナルの不整合やエラーを回避するために、アノテーションを実装する際は 1 つの方法で行うことを強くおすすめします。
    • hreflang 属性の値は、言語については ISO 639-1 形式で、地域については ISO 3166-1 Alpha 2 形式で指定する必要があります。地域のみの指定はサポートされていません。サイトに国のみを設定したい場合は、ウェブマスター ツールの地域ターゲティング機能を使用してください。
    これらの推奨事項に従うことで、ローカライズされたコンテンツが Google で認識されやすくなり、Google 検索結果でより関連性の高い結果をユーザーに提供できるようになります。ご不明な点やご意見・ご感想などありましたら、ウェブマスター  ヘルプ フォーラムにてお聞かせください。


    Posted by Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts.
    Original version: Official Google Webmaster Central Blog: Creating the Right Homepage for your International Users

    ウェブマスター向けガイドラインを更新しました – 不正なリダイレクトとハッキングされたコンテンツについて

    リダイレクトは、あるページから別のページに訪問者を誘導する方法のひとつとしてウェブで広く利用されています。しかし、検索エンジンを操作したりだましたりするためのリダイレクトや、検索エンジンと人間のユーザーにそれぞれ異なるコンテンツを表示するためにリダイレクトが利用される場合もあります。Google のウェブマスター向けガイドラインの品質に関するガイドラインでは、このようなタイプのリダイレクトを厳しく禁じています。

    こうしたリダイレクトの中には、たとえば PC ユーザーには通常のページが表示されるのに、モバイル ユーザーはハッカーによって、まったく別のスパム サイトにリダイレクトされるように改ざんされるといったケースもあります。問題のあるリダイレクトをウェブマスターの皆様により詳しく理解していただくために、Google の品質に関するガイドラインの不正なリダイレクトのページにその違反例を新たに掲載しました。

    さらに、ハッキングされたコンテンツに関するガイドラインも更新し、攻撃を受けたウェブサイトで不正なリダイレクトが挿入された例を追加しました。サイトが攻撃を受けたと思われる場合は、こちらのガイドの手順に沿ってサイトの問題を特定し、修正してください。

    Google ではユーザーを危険から守り、検索結果の品質を維持するため、Google の品質に関するガイドラインのあらゆる違反と同様、これらのガイドライン違反に対しても手動による対策（Google のインデックスからの削除など）を行う場合があります。Google のガイドラインについてご不明な点がありましたら、お気軽にウェブマスター ヘルプ フォーラムでご質問ください。


    Posted by Aaseesh Marina, Search Quality Team
    Original version: Webmaster Guidelines for sneaky redirects updated

    グローバルのウェブマスター向け公式 Google+ ページを公開しました！

    先日 Google では、世界中のウェブマスターの方に向けたグローバルの公式 Google+ ページを公開しました。もうご覧いただけましたでしょうか？この Google+ ページでは、
    といった幅広い情報をお届けします！

    ページ上では、英語による投稿が多いですが（英語がわからなくても楽しめる写真の投稿もたくさんあります）、ページ以下にはイタリア語や日本語、ロシア語、またはスペイン語を話すウェブマスターの方々が情報交換を行えるコミュニティも設けています。

    ぜひウェブマスター向け公式 Google+ ページをフォローして日々更新される情報をチェックしてみてください！


    Hello from around the world!

    Posted by Mary Chen and Andrey Lipattsev, Webmaster Outreach Team
    Original version: Introducing our global Google+ page for webmasters