11 years 1ヶ月 ago
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 が対応できないリダイレクトなど）を特定することもできます。
最後に、ご不明な点やご質問がありましたら、
ウェブマスター ヘルプ フォーラムまでお寄せください。
Original version: Updating our technical Webmaster Guidelines
11 years 2ヶ月 ago
閲覧しようとしたページが自分の端末に対応していないという状況は、ウェブ ユーザーによくある悩ましい問題です。時には、まったく何もないページや大部分が欠けたページが表示されます。
Google は、本日より日本でも、端末が対応していない技術が使われていると思われるページを検出した際には、モバイルの検索結果上に
その旨を表示（英語）するようになりました。たとえば、Adobe Flash は、iOS や Android 4.1 以降を搭載したスマートフォンでは表示できません。このような端末では、大部分が Flash であるようなページは、モバイルの検索結果上で以下のように表示されます。
現在使われている様々な端末に対応したウェブサイトの開発方法
ところで、現在使われているすべての端末に対応したウェブサイトを開発することは難しくありません。HTML5 を使いましょう。HTML5 は、どのような端末でも表示されますし、HTML5 しか使えない端末さえあるからです。そこで、好きな種類のファイルをどのような端末でも表示できるようなサイトを作る一助になればとの思いから、最近、Google は次の 2 つのページを
公開いたしました。
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
11 years 3ヶ月 ago
夏の間、ウェブマスター ツール チームは
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
11 years 3ヶ月 ago
検索エンジンのランキングを操作するために PageRank を渡すリンクを売買することは、Google のウェブマスター向けガイドラインに違反しています。このことは、以前にもこのブログ上で
お伝えしてきました。
この記事では、最近 Google が対策を行った、大規模な
リンク プログラムの一例をご紹介いたします。
（例 1） 自動生成された文章に、特定のサイトへのリンクを、過度に最適化されたアンカーテキストを用いて挿入しているケースです。
（例 2） 本来対象としているサイト以外への発リンクも設置することで自然なリンクに見せかけているケースです。
最近 Google が対応を行ったケースでは、委託先 SEO 会社がリンク操作のネットワークを保有して依頼主に提供している例だけでなく、企業自身が主体となってリンク操作のためのネットワークを運用している例が見受けられました。そのような例に対して Google は、ウェブマスター向けガイドライン違反として適宜自動または手動による対策を実施しています。
ウェブマスターのみなさまには、こういった PageRank を渡すリンクの操作や売買を避けることをこれまでどおり強くおすすめします。サーチ クオリティ チームは、今後とも、ユーザーのために、検索結果からのスパムの排除に全力で取り組んでまいります。
Google サーチ クオリティ チーム
11 years 3ヶ月 ago
11 years 3ヶ月 ago
このたび、サイトリンクの検索ボックスが新しくなりましたのでお知らせいたします。この検索ボックスを使用すると、ユーザーはサイト独自の検索ページを通じて直接サイト内の特定のコンテンツに簡単にアクセスできるようになります。
この検索ボックスの仕組みと検索結果に表示されるタイミング
たとえば [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
11 years 3ヶ月 ago
本記事でご紹介するデベロッパー サイトは、現時点ではまだ日本語に翻訳されていませんが、日本のみなさまにもご利用いただける内容であり、有益であると思いますのでご紹介させていただきます。誰もが帯域幅の使用量を削減したいと考えています。ホスティング プロバイダーは料金を節約したいと考えていますし、モバイル ユーザーは使用制限の範囲内に収めたいと思っています。そして、不必要なバイト数の読み込みを待ちたいと思っている人は誰もいません。ウェブには帯域幅を節約できるチャンスがたくさんあります。たとえば、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 （英語）などへの移植が進行中です。
11 years 3ヶ月 ago
先日、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:
ユーザーから寄せられたベスト投稿を発表！（各言語でベスト投稿を発表しました）
世界中から寄せられた投稿のご紹介
今回、世界同時でキャンペーンを行ったこと、そして、世界中のユーザーからサイトの不正なハッキング対策が多く寄せられたことからもわかるように、サイトの不正なハッキングの問題は全世界的に広がりを見せています。どうぞ今回ご紹介した Tips と共に以下のサイトも参考にし、ご自身のサイトの設定をもう一度確認してみてください。
ハッキングされたサイトに関するウェブマスター ヘルプ
http://www.google.co.jp/webmasters/hacked/これからも全世界で Tips を共有し、サイトのハッキングと闘いましょう！ #NoHacked のハッシュタグはこれからもご利用ください。また質問がある際は
ウェブマスター ヘルプ フォーラムをご利用ください（ハッキングに関するカテゴリも用意しています）。
Google では今後もユーザー、ウェブマスターのみなさまのお役に立てる情報をどんどん発信していきたいと思っておりますので、ぜひ
Google Webmasters ページ、
Google Japan ウェブマスター コミュニティをフォローしてみてください。
Posted by your friendly #NoHacked helpers
11 years 4ヶ月 ago
セキュリティは Google の最優先事項です。Google は、
デフォルトで強力な HTTPS 暗号化を導入するなど、業界でも最先端のセキュリティを Google サービスに導入することに力を注いでいます。これにより、たとえば Google 検索、Gmail、Google ドライブを使用しているユーザーは自動的に、Google に安全に接続することができます。
Google は、Google のサービスだけにとどまらず、より広い範囲でインターネットを安全に利用できるように取り組んでいます。そこで大きな割合を占めているのは、ユーザーが Google から安全なサイトにアクセスできるようにすることです。たとえば、Google ではウェブマスター向けに
ハッキングの対策や修正方法について詳しい情報を提供するサイトを作成しました。
また、ますます多くのウェブマスターが
HTTPS（HTTP over
TLS / Transport Layer Security）を彼らのサイトに導入するようになってきています。これはとても心強いことです。
こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。
Google は、みなさんがより簡単に TLS を導入し、よくある失敗を避けられるように、今後数週間のうちに詳細なベスト プラクティスを公開する予定です（Update: こちらの
ヘルプ記事内で公開しました）。開始にあたって、以下の基本的なヒントもご確認ください。
- 必要な証明書タイプを決定します: シングル、マルチ ドメイン、ワイルド カード
- 2048 bit の証明書を使用します
- 同じ安全なドメイン上にあるリソースには相対 URL を使用します
- 他のすべてのドメインにはプロトコル相対 URL を使用します
- サイトのアドレスの変更方法について詳しくは、サイト移転に関するヘルプ記事をご覧ください
- robots.txt を使用して HTTPS サイトへのクロールをブロックしないでください
- 可能な限り検索エンジンがページをインデックス登録できるようにします。Noindex メタタグの使用は避けます。
このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは
良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。
今後、より多くのウェブサイトで HTTPS が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。
11 years 4ヶ月 ago
クロールするべきか、しないべきか、それが 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 の指定の作成についてアドバイスが欲しい場合などは、ぜひ
ウェブマスター ヘルプ フォーラムをご利用ください。
Original version: Official Google Webmaster Central Blog: Testing robots.txt files made easier
11 years 4ヶ月 ago
複数の国のユーザーをターゲットとしているウェブマスターの方は、
rel-alternate-hreflang について耳にされたことがあるかと思います。まだこの機能をご存知でない方のために簡単にご説明しますと、このアノテーションにより Google などの検索エンジンが適切な言語や地域のバージョンのページを検索ユーザーに表示できるようになり、結果としてユーザーの満足度の向上につながります。
実装したこのアノテーションが検索エンジンで使用できる状態であるかどうかを確認することは、特にページが多くあるサイトでは容易ではなく、この点については世界中のサイト運営者の方から声が上がっています。そこで Google では本日、rel-alternate-hreflang アノテーションのデバッグを簡単に行うことができる機能を公開します。
不適切な 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
11 years 5ヶ月 ago
もしあなたがウェブサイトと Android アプリを両方持っているのなら、それらを連携させることで、スマートフォンやタブレットから Google で検索しているユーザーにとって、検索結果からアプリへの起動を非常に簡単にすることができるようになりました。
検索結果に表示されるアプリのディープリンクは、あなたのアプリが既にインストールされている端末の検索結果において、アプリ内のコンテンツへのアクセスをより容易にします。ウェブサイトのページを対応するアプリ側の部分へと接続することで、サイトオーナーとして、適切なコンテンツを、適切なタイミングでユーザーに見せることができるようになります。
いくつものアプリが
既に App Indexing を実装しています。今週の Google I/O で、ディープリンクの設定、サイトのアプリへの接続、パフォーマンスやエラーのトラッキングといった一連のプロセスをより容易にするための機能を発表いたしました。
簡単に始められます
このたび、アプリのディープリンクをインデックスさせるために必要なプロセスを大きく簡易化しました。アプリが既に HTTP によるリンクをサポートしているのであれば、
あなたの URL 群がインデックスされると共に、Google はアプリとサイトの繋がりを発見し、検索結果でディープリンクを使用したアプリへの直接的な遷移を可能にします。
アプリのディープリンクの発見とインデックス作業を Google に任せることもできますが、あなた自身がこれらのディープリンクを埋め込み、公開することをおすすめします。もしあなたのアプリがカスタム ディープリンクスキームをサポートしている場合は特にそうです。そのためには、2 つの方法があります:
各ウェブページに対して、rel="alternate" 属性を持った link 要素を <head> 部分に埋め込むか、サイトマップを利用して android-app URI を指定する。
デベロッパー サイト上で実装方法を確認できます。
また、このたび、アプリページをインデックスする際に発生した問題について報告を行う
新しい機能をウェブマスター ツールに追加しました。ここでは、各アプリページとウェブページのペアについて検知されたエラーと、デバッグのためのサンプル アプリ URI確認することができます。
また、それぞれの問題について、その詳細なデバッグ方法も確認することができます。アプリのディープリンクの QR コードも含まれていますので、携帯電話やタブレットで簡単にリンクを開けます。エラーが検知された場合、ウェブマスター ツール上でメッセージもお送りいたします。
App Indexingは既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。
Posted by Mariya Moeva, Webmaster Trends Analyst
Original version: Android app indexing is now open for everyone!
11 years 6ヶ月 ago
ウェブマスターの皆様にとって、サイトの移転ほど厄介で悩ましい問題はないかもしれません。このたび 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 を別に設定している場合や動的配信を行っている場合にウェブサイトでレスポンシブ ウェブ デザインを使用するよう変更するにはどうすればよいか、といった質問も増えつつあります。この設定の変更について詳しくは、スマートフォン向けサイトの推奨事項についてまとめたサイトに新たに追加された
こちらのページをご覧ください。
Original version: Official Google Webmaster Central Blog: Making site moves easier
11 years 6ヶ月 ago
Google は 5 月 15 日、ホスティング サービスの運営者のみなさまを対象にしたイベント「
Hosting Meetup @ Google」を開催しました。今回は、そのイベントの様子をご紹介します。
ブログなどのホスティング サービスは、低コストで簡単に利用できることから広く利用されています。一方で、その利便性を悪用し、Google のウェブマスター向けガイドラインに違反するようなスパム目的に利用されるケースがあることもわかっています。
今回のイベントは、こうした背景から、Google 検索と相性のよいホスティング サービスの運営について考えることを目的として実施しました。
当日は、ウェブマスター ツールや構造化データ、複数デバイス対応などに関して、Google 検索と相性の良いホスティング サービス運営のためのヒントのご紹介と、ホスティング サービス上でよく見られるウェブマスター向けガイドライン違反（ウェブ スパム）について、その傾向や対処方法などをお話しました。
ホスティング サービスからウェブ スパムがなくなり、かつ、Google 検索と相性の良いサイト構築を心がけていただくことで、Google がホスティング上のサイトを見つけやすくなり、より多くの検索ユーザーがそうしたサイトを訪問する可能性が高まります。
そのための具体的なアクションとしては、
- スパム ポリシーの制定・見直し
- スパムへの対処（サイトの自動生成の禁止。Captcha の導入、違反箇所の修正方法、スパム サイトへの対処方法など）
- ユーザーへの啓蒙
- ウェブマスター ツールをユーザーが利用できるようにする
Google と相性の良いサイトの構築のヒント
- ウェブマスター ツールの活用
- 構造化データの導入
- 適切な複数デバイス対応
こういった内容をぜひサービスの運営に取り入れていただき、Google 検索と相性のよいサービスの運営を行っていただければと思います。
ホスティング サービスの運営者の方々からも Google のウェブマスター向けガイドラインについてのご質問や、スパムへの対処方法のベスト プラクティスについてのご質問など、数多くのご質問をいただき、非常に有意義な意見交換をすることができました。
ご参加いただきましたみなさま、ありがとうございました！
また、今回イベントに参加できなかったホスティング サービスのみなさまのために、同一の内容をテーマとしたウェブマスター ハングアウト「
ホスティング サービスのみなさまへ：Google 検索と相性の良いサービスの運営とは？」を実施いたしましたので、ぜひご覧ください。
あわせてホスティング サービスの運営者のみなさまを対象とした情報をまとめた
サイトを設けました。今回のイベントでお話した内容や、関連する情報についてまとめて掲載しておりますのでぜひご覧ください。
Google サーチ クオリティ チーム
2014/6/23追記：ウェブマスター ハングアウトを実施しましたので表現を告知から変更いたしました。
11 years 6ヶ月 ago
ウェブマスター ツールの 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 がそれらのコンテンツを見つけてインデックスに登録することが可能になります。サイトに表示されるコンテンツやそのレイアウトにあまり影響しない一部のコンテンツ タイプ（ソーシャル メディア ボタン、フォント、ウェブサイト分析スクリプトなど）は、クロールできない状態のままでも構いません。詳しくは、以前ブログに投稿した「
ウェブページをより深く理解するようになりました」という記事をご覧ください。
今回のアップデートによって問題の診断が容易になり、誤ってクロールがブロックされていたコンテンツが発見され、クロールされるようになることを願っております。ご不明な点やご意見などありましたら、
ウェブマスター ヘルプ フォーラムまでお寄せください。
Original version: Official Google Webmaster Central Blog: Rendering pages with Fetch as Google
11 years 6ヶ月 ago
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 をまだ実行できない検索エンジンでも大丈夫です。
場合によっては、JavaScript が複雑すぎたり特殊すぎたりして、Google で実行できないこともあります。このような場合は、ページを完全に正しくレンダリングすることはできません。
JavaScript によっては、コンテンツを追加するのではなく削除するものもあります。こういった場合、コンテンツのインデックス登録はできなくなってしまいます。
現在 Google ではデバッグがより簡単にできるように、ウェブマスターの皆様が Google によるサイトのレンダリング状況を詳しく把握できるようなツールの開発に取り組んでおります。近いうちに
ウェブマスター ツールで皆様にご提供する予定です。
ご不明な点がありましたら、お気軽に
ウェブマスター ヘルプ フォーラムをご利用ください。
Original version: Official Google Webmaster Central Blog: Understanding web pages better
11 years 6ヶ月 ago
モバイル対応のページを作成するデベロッパーやウェブマスターの皆さんのお役に立てるよう、Google ではこのたび、PageSpeed Insights の見直しを行い、モバイルでの操作性に関する推奨事項を新たに追加しました。
ページの読み込みが速くても、操作性が低ければその効果が損なわれかねません。Google の調査では、平均的なモバイル ページの
読み込みには少なくとも 7 秒はかかる（英語記事）ことがわかっています。
PageSpeed Insights ツールを使用し、そこで提示される速度についての提案を活用することで、
ページ読み込みの速度を改善することは可能です。では、モバイル サイトの読み込みに 7 秒もかからず 2 秒で済む場合を考えてみましょう。ページの読み込み後、モバイル ユーザーがテキストを読んだりページを操作したりするために、画面をピンチズームしたりスクロールしたりして 5 秒かかってしまったら、ユーザーの体験としてはそのサイトは速いとは言えません。PageSpeed Insights が新しく提案するユーザー エクスペリエンスに関するルールを参考にすれば、こうした操作性についての問題点を見つけ出し、修正することができます。
この新たな推奨事項では、現在のところ次のような対策を紹介しています。
viewport を設定する: viewport メタ タグが指定されていないページは、最新のモバイル ブラウザではモバイル非対応ページとみなされてデスクトップ向けのビューポートとして処理され、さらにはフォント拡大が適用される可能性もあるため、意図したとおりのページ レイアウトで表示されないことがあります。モバイルに適したサイトにするためには、まず
viewport の設定で width=device-width を使用しましょう。
コンテンツのサイズを viewport に合わせる: ユーザーは、モバイル サイトは横ではなく縦にスクロールするものと思っています。viewport を設定したら、ページのコンテンツが
その viewport の幅に収まっていることを確認してください。その際、携帯端末の幅は機種によって異なることに注意が必要です。
読みやすいフォント サイズを使用する: ユーザーがスマートフォンで記事を読むときに拡大しないと文字が読めないとしたら、それはモバイルに適したサイトとは言えません。PageSpeed Insights では、大部分のユーザーにとって
読みやすい大きさの文字かどうかをチェックします。
タップ ターゲットのサイズを適切に調整する: 携帯電話やタブレットのタッチスクリーンでボタンやリンクをタップしようとして、間違えて誤ったターゲットをタップしてしまうことがあります。これは、パソコンのマウス カーソルと比べて指の腹の方が大きいためですが、とても煩わしいものです。モバイル サイトのタッチスクリーンの
タップ ターゲットは押しやすいように十分大きくするようにしてください。
プラグインを使用しない: ほとんどのスマートフォンでは、Flash などのブラウザ プラグインをサポートしていません。そのため、モバイル サイトでも
プラグインを使用しないようにします。
この記事に関するコメントやご質問は、
ウェブマスター ヘルプ フォーラムまでお寄せください。
Original version: Official Google Webmaster Central Blog: Making your site more mobile-friendly with PageSpeed Insights
11 years 6ヶ月 ago
複数の国で事業を行っている場合や複数の言語をターゲットとしている場合は、それぞれの国または言語をターゲットとする URL に応じたコンテンツを含むサイトまたはセクションを別個に提供することをおすすめします。たとえば、ターゲット地域を米国に、ターゲット言語を英語に設定したページと、ターゲット地域をフランスに、ターゲット言語をフランス語に設定したページを用意します。
多地域、多言語のサイトの処理について別の記事でご説明していますが、ホームページはやや特別です。この記事では、言語や地域に応じてユーザーにふさわしいコンテンツを提供できるよう、ウェブサイトに適切なホームページを作成する方法について解説します。
ユーザーがアクセスしたときのホームページ/リンク先ページの動作を設定する場合、次の 3 つのパターンがあります:
それぞれの設定について詳しく見ていきましょう。
世界中のユーザーに同じコンテンツを表示する
このシナリオでは、ある 1 つの国/言語に固有のコンテンツをホームページ/汎用 URL（http://www.example.com）で配信します。このコンテンツは、ブラウザでその URL に直接アクセスしたユーザー全員と、その URL を指定して検索したユーザー全員に表示されます。上で述べたように、それぞれの国と言語のバージョンもそれぞれ固有の URL でアクセスできるようにする必要があります。
注: 別の地域のユーザーや別の言語を設定しているユーザーに対し、より適切なバージョンのコンテンツが用意されていることを知らせるバナーをページに表示することができます。
ユーザーがローカル バージョンと言語を自由に選択できるようにする
この設定では、ホームページ/汎用 URL で国選択ページを提供し、ユーザーが国と言語に応じて表示したいコンテンツを選択できるようにします。その URL を入力したすべてのユーザーは同じページにアクセスすることになります。
ユーザーの地域や言語設定に応じて、ユーザーを自動的にリダイレクトする、または適切な HTML コンテンツを動的に配信する
この 3 番目のシナリオでは、ユーザーの地域や言語設定に応じて、適切な HTML コンテンツを自動的に配信します。このシナリオの実装は、サーバー サイドで 302 リダイレクトを使用するか、適切な HTML コンテンツを動的に配信することで実現できます。
ホームページ/汎用ページでは必ず x-default rel-alternate-hreflang アノテーションを使用してください（汎用ページが、ユーザーが直接アクセスできないリダイレクト ページである場合も同様です）。
注: 特定のバージョンを用意していないユーザー層のリダイレクトについても考慮する必要があります。たとえば、英語、スペイン語、中国語のバージョンが用意されているウェブサイトにフランス語を使用するユーザーがアクセスしたとします。この場合は、最も適切であると思われるコンテンツを表示することになります。
いずれの設定を選択した場合でも、国や言語の選択ページを含むすべてのページが次の条件を満たしている必要があります:
注: 冒頭で述べたように、国や言語のバージョンごとに別個の URL を用意する必要があります。
rel-alternate-hreflang アノテーションについて
どの方法を選択したかにかかわらず、必ずすべてのページにアノテーションを追加してください。アノテーションにより、検索エンジンで適切な結果がユーザーに表示される可能性が大幅に高くなります。
国選択ページ、リダイレクトまたは動的に配信されるホームページでは必ず
x-default hreflang を使用する必要があります。これは、自動的にリダイレクトされるホームページや国選択専用のアノテーションです。
最後に、rel-alternate-hreflang アノテーションに関して役立つ一般的な注意事項をいくつかご紹介します:
アノテーションは自分に対しても向いていなければなりません。ページ A で、そのページ自身をリンク先とした rel-alternate-hreflang アノテーションを使用する必要があります。
rel-alternate-hreflang アノテーションは、HTTP ヘッダー、HTML の head セクション、またはサイトマップ ファイルで指定できます。シグナルの不整合やエラーを回避するために、アノテーションを実装する際は 1 つの方法で行うことを強くおすすめします。
これらの推奨事項に従うことで、ローカライズされたコンテンツが 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
11 years 7ヶ月 ago
リダイレクトは、あるページから別のページに訪問者を誘導する方法のひとつとしてウェブで広く利用されています。しかし、検索エンジンを操作したりだましたりするためのリダイレクトや、検索エンジンと人間のユーザーにそれぞれ異なるコンテンツを表示するためにリダイレクトが利用される場合もあります。Google のウェブマスター向けガイドラインの
品質に関するガイドラインでは、このようなタイプのリダイレクトを厳しく禁じています。
こうしたリダイレクトの中には、たとえば PC ユーザーには通常のページが表示されるのに、モバイル ユーザーはハッカーによって、まったく別のスパム サイトにリダイレクトされるように改ざんされるといったケースもあります。問題のあるリダイレクトをウェブマスターの皆様により詳しく理解していただくために、Google の品質に関するガイドラインの
不正なリダイレクトのページにその違反例を新たに掲載しました。
さらに、
ハッキングされたコンテンツに関するガイドラインも更新し、攻撃を受けたウェブサイトで不正なリダイレクトが挿入された例を追加しました。サイトが攻撃を受けたと思われる場合は、こちらのガイドの手順に沿って
サイトの問題を特定し、修正してください。
Google ではユーザーを危険から守り、検索結果の品質を維持するため、Google の品質に関するガイドラインのあらゆる違反と同様、これらのガイドライン違反に対しても手動による対策（Google のインデックスからの削除など）を行う場合があります。Google のガイドラインについてご不明な点がありましたら、お気軽に
ウェブマスター ヘルプ フォーラムでご質問ください。
Original version: Webmaster Guidelines for sneaky redirects updated
11 years 7ヶ月 ago
先日 Google では、世界中のウェブマスターの方に向けたグローバルの
公式 Google+ ページを公開しました。もうご覧いただけましたでしょうか？この Google+ ページでは、
といった幅広い情報をお届けします！
ページ上では、英語による投稿が多いですが（英語がわからなくても楽しめる写真の投稿もたくさんあります）、ページ以下には
イタリア語や
日本語、
ロシア語、または
スペイン語を話すウェブマスターの方々が情報交換を行えるコミュニティも設けています。
ぜひ
ウェブマスター向け公式 Google+ ページをフォローして日々更新される情報をチェックしてみてください！
Hello from around the world!
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報Unknownnoreply@blogger.comBlogger443125
Google ウェブマスター向け公式ブログ フィード を購読
