ウェブマスター向け公式ブログ
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報
HTTP ヘッダーでの rel="canonical" 属性に対応しました
2011年7月29日金曜日
みなさまからのご要望にお応えし、このたび、Google 検索は
IETF RFC 5988 のセクション 5
（英語）に記載のシンタックスに従って HTTP ヘッダーで指定された
link rel="canonical" 属性
に対応いたしました。rel="canonical" を有する HTTP ヘッダーを使用することで、HTML 文書だけでなく、それ以外の形式のコンテンツ（PDF ファイルなど）についても canonical URL（優先する URL）を設定することが可能になります。
では実際に、rel="canonical" を指定した HTTP ヘッダーがどのような働きをするか、HTML ページ版と PDF ダウンロード版の両方で文書を提供しているウェブサイトを例に見ていきましょう。HTML 版と PDF 版の URL はそれぞれ下記のとおりとします。
http://www.example.com/white-paper.html
http://www.example.com/white-paper.pdf
このケースでは、PDF ファイルが要求された時に rel="canonical" HTTP ヘッダーを使用することによって、優先する URL が上記 HTML 文書であることを Google に通知することができます。
記述例：
GET /white-paper.pdf HTTP/1.1
Host: www.example.com
(...以下、他の HTTP リクエスト ヘッダー...)
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <http://www.example.com/white-paper.html>; rel="canonical"
Content-Length: 785710
(...以下、他の HTTP レスポンス ヘッダー...)
他にも、rel="canonical" を設定した HTTP ヘッダを活用できる代表的なケースとして、ウェブサイトが同一ファイルを複数の URL から提供している場合（コンテンツ配信ネットワークを使用している場合など）に、Google に対して優先する URL を通知したいといったケースが挙げられます。
これらのリンク ヘッダー要素は、現時点では Google においては検索でしか対応していませんが、ウェブマスターのみなさまの利用状況を考慮しながら、Google の他のサービスにおいても対応できるようにしたいと考えております。
詳しくは、
正規化
および
rel="canonical" 属性
に関するヘルプセンターの記事をご参照ください。ご質問やご意見がありましたら、
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by Pierre Far, Webmaster Trends Analyst
Original version:
Supporting rel="canonical" HTTP Headers
404 はサイトに悪影響を与えますか？
2011年7月22日金曜日
ある日、何気なくウェブマスター ツールを使って自分のサイトの調子を確認したところ、
クロール エラーページ
が、
404（Not found）
（英語）でいっぱいになっていました。こんな時、いったいどうしたらいいのでしょうか？
心配する必要はありません。今回の記事は、404 についてと、これらがサイトに対して影響をおよぼす点（あるいは影響をおよぼさない点）について取り上げます。
質問: ウェブマスター ツールのクロール エラー ページに表示される 404 （Not found）は、Google 検索での掲載順位に影響しますか？
答え: サイトの一部の URL が既に存在しない、または 404 を返していた場合も、サイトの他の URL （
200（Successful）
を返すもの）の検索結果内での掲載順位には影響しません。404 レスポンス コードは、インターネットにとっては正常な動作です。インターネットは常に変化しており、新しいコンテンツが作られ、古いコンテンツはなくなっていきます。コンテンツがなくなったとき、404 HTTP レスポンス コードを返すことが通常の動作です。検索エンジンはこのことを理解しています。上図にあるように、Google のサイトにも 404 エラーはありますし、404 エラーはインターネットのあちこちで見られます。サイトからページが削除された場合は、いわゆる「ソフト 404」よりも、正しい 404 または 410 レスポンス コードが返されるほうが検索エンジンにとっては望ましいのです。Google のクローラが URL の HTTP レスポンス コードを確認するためには、その URL をクロールする必要があることを覚えておいてください。該当の URL が robots.txt ファイルでブロックされていると、クロールができず、レスポンス コードを確認することができません。
質問: では、ウェブサイトにとって 404 はまったく影響のないものなのですか？
答え: サイトの一部の URL が 404 を返しているということ自体が、サイト運営者の評価や Google 検索の結果に影響することはありません。ただし、一部の 404 に対しては対処が必要かもしれません。たとえば、404 を返しているページがサイトにとって重要なページである場合は、なぜクロール時に 404 が出ているのか調査するほうがよいでしょう。URL のスペルミス（www.example.com/awesome を誤って www.example.com/awsome としている場合など）がある場合は、誰かがサイトにリンクしようとしてタイプミスをしていることが考えられます。その場合、404 を返す代わりに、301 リダイレクトを使用し正しい URL にリダイレクトすれば、そのリンクからのトラフィックを得ることができます。また、ユーザーがサイトの 404 ページにアクセスした場合、「404 Not found」とだけ表示するのではなく、
ユーザーにとって有用なページを用意
することもできます。
質問: 「ソフト 404」について詳しく教えてください。
答え:
ソフト 404
とは、ウェブサーバーが、存在しない URL に対して 404（または 410）以外の応答コードを返す場合です。一般的な例としては、サイト運営者が
ユーザーにとって便利な 404 ページ
（英語）を提供したいと考え、そのようなコンテンツを提供するには必ずレスポンス コード 200 を返さなければならないと思っている場合です。しかし、404 を返しても、そのようなコンテンツを提供することはできます。他の例としては、未知の URL に対して 404 を返す代わりにホームページにリダイレクトしている場合です。どちらの場合も、Google があなたのサイトを分析しインデックスを作成するのに支障が出る可能性があるため、存在しないコンテンツに関しては適切なレスポンス コードを返すようにしてください。
ページに「404 Not Found」と書かれているからといって、本当に応答コード 404 を返しているとは限りません。
ウェブマスター ツールの
Fetch as Googlebot
機能を使用して、そのページをチェックしてみてください。サーバーが正しい応答コードを返すように設定する方法がわからない場合は、ホスティングサービスのヘルプページなどを参照してみましょう。
質問: URL が 404、301、410 のうちどれを返すべきか判断するにはどうすればよいのですか？
答え: サイトからページを削除するときに、そのコンテンツを別の場所に移動するのか、完全にサイトからなくすつもりなのかを考慮してください。コンテンツを新しい URL に移動する場合、古い URL から新しい URL へ 301 リダイレクトしましょう。こうすれば、ユーザーが古い URL を訪れた場合も、探している情報と関連があるページに自動的に誘導されます。コンテンツを完全に削除して、今後サイトに設置しない場合は、古い URL が 404 または 410 を返すよう設定しましょう。現在、Google は 410（Gone） を 404（Not Found）と同じように処理します。そのため、どちらを返してもかまいません。
質問: 404 のほとんどが、サイトに存在しない URL に対するものです。これは何ですか？どこから来たトラフィックですか？
答え: 通常 Google は、ウェブ上のどこかであなたのサイト内へ張られたリンクを検出すると、コンテンツの有無を問わずそのリンクをクロールします。もしその URL が存在しない場合には場合はサーバーは 404 を返す必要があります。こういった無効なリンクが発生する理由は、いろいろ考えられます。例を挙げると、サイトにリンクしようとした誰かがスペルミスをした場合、設定ミスの場合（CMS によってリンクが自動生成されている等）、Google のクローラが JavaScript や他の組み込みコンテンツ内のリンクを認識してクロールしようとした場合、サーバーが未知の URL をどのように処理するかを Google が確認しようとした場合などです。サイトに存在しない URL に対してウェブマスター ツールが 404 を報告した場合は、無視しても問題ありません。Google では、あなたのサイトにとって必要な URL と、404 を返すべき URL を判別できません。このため、サイトで検出されたすべての 404 を報告し、対応が必要かどうかはみなさんの判断に任せています。
質問: サイトをスクレイピングされたため、大量の 404 が発生しました。例えば「http://www.example.com/images/kittens.jpg" width="100" height="300" alt="kittens"/></a...」のような、実在する URL に他のコードが付け加えられたものです。これはサイトに悪影響を与えますか？
答え: 一般的に、このような「壊れた」リンクがサイトに悪影響を与えることはありません。Google は、サイトの運営者側ではスクレイピングを行う者や、普通でない方法でリンクしようとする者を制御できないことを理解しています。
正規表現
を使いこなせる場合は、これらの URL を
このように
（英語）リダイレクトすることもできますが、普通は心配しなくても大丈夫です。また、サイトからコンテンツが盗用された確信がある場合は、
こちらから著作権侵害の申し立て
を行うことができます。
質問: 先週、ウェブマスター ツールで報告された 404 をすべて修正したのですが、まだ一覧に記載されています。正しく修正できなかったということですか？エラーが表示されなくなるまで、どのくらいかかるのですか？
答え: 「クロール エラー」ページの「最終検出」列をご覧ください。これは各エラーが検出された最新の日付を示しています。列の日付がエラーを修正する前であれば、そのエラーはその日付から発生していないことを意味します。日付が修正後である場合は、クロール時に再び 404 に遭遇していることになります。
Fetch as Googlebot
機能を使用すると、クローラが新しいレスポンス コードを確認できているかどうかをチェックできます。いくつかの URL でテストして問題がなければ、それらはクロール エラーの一覧から消えていくはずです。
質問: アカウントから 404 エラーを早く消去するために、Google の URL の削除ツールを使ってもよいですか？
答え: いいえ、URL の削除ツールは Google の検索結果から URL を削除するためのものであり、ウェブマスター ツールのアカウントから削除するためのものではありません。404 を返すページはいずれ検索結果には表示されなくなるため、緊急の削除要請用のツールを使う必要はありません。URL の削除ツールを使用するべきである場合とそうでない場合については、
この記事
（英語）の後半を参照してください。
ご質問やご意見がありましたら、
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by Susan Moskwa, Webmaster Trends Analyst
Original version:
Do 404s hurt my site?
Google ウェブマスター ツールと Google アナリティクスで「+1」の効果を確認できます
2011年7月14日木曜日
[この記事は、
Inside AdSense ブログ
とのクロスポストです。]
先日世界中でリリースした +1 ボタン
は、
自分の信頼している人たちとインターネット上でつながりやすく
（英語。日本語字幕付き）することを目指しています。あるユーザーが +1 ボタンを押すと、その情報はそのユーザーにつながっている友人達の間で共有され、検索結果に表示されます。そうした友人間のおすすめ情報は、きっと検索結果からどのサイトを閲覧しようかを決める際の貴重な参考となるでしょう。つまり、+1 ボタンによって、友人達があなたのサイトについてあなたに代わりおすすめしてくれることになります。
しかし、サイトを運営するウェブマスターのみなさまにとってこのような新しい機能の効果は、測定してはじめて分かることもあるでしょう。そこでこの度、+1 ボタンをサイトに導入した効果を測定するための機能をリリースしました。
トラフィックへの影響を測る 3 つの指標（ウェブマスター ツール）
まず、
Google ウェブマスター ツール
の +1 統計情報では、+1 ボタンがサイトへのトラフィックにどう影響しているかを確認できます。
検索への影響
では、検索結果からの集客に「+1」がどう影響しているかを確認できます。+1 による友人からのおすすめ情報が検索結果にある場合とない場合とで、クリック数や表示回数を比較できますので +1 ボタンを押された場合にクリック率が変化しているかどうかがわかります。クリック率の変化の統計は、比較が行えるだけの表示回数がある場合のみ表示されます。
アクティビティ
は、サイト内、あるいは他のページ（Google 検索など）で、あなたのページに対し何回 +1 ボタンが押されたかが表示されます。
最後に、
対象
にはページの +1 ボタンを押した Google ユーザーの地域情報やユーザー情報が表示されます。プライバシー保護のため、一定以上の人数のユーザーが +1 ボタンを押した場合にのみ、この情報は表示されます。
レポートを表示するには、ページの左側にある [+1 統計情報] メニューからご利用ください。Google ウェブマスター ツールで認証手続（サイトの確認）をしていない場合は、
こちらの手順
を参照して Google ウェブマスター ツールへサイトの登録をしてください。
共有の効果を測る 3 つのソーシャル指標（Google アナリティクス）
Social Plug-in Analytics in Google Analytics
（英語）を利用すると、+1 ボタン以外の方法でコンテンツが共有されている場合についてもその効果を確認することができます。Google アナリティクスの JavaScript を設定すれば、ソーシャル セクションのエンゲージ レポートから、ページで行われている様々なソーシャル上での共有（+1 ボタンのクリック、Twitter のつぶやきなど）を比較することができます。
エンゲージ レポート
では、+1 ボタンのクリックやその他のソーシャル上での共有を行った訪問者について、サイトでのパフォーマンスがどのようなものだったかを確認できます。この機能を使用すれば、たとえば、ページを訪問して +1 ボタンをクリックしたユーザーが、クリックしなかったユーザーよりも長時間サイトに留まっているかなどを判断することができます。
アクション レポート
では、サイトに対して行われたソーシャル上での共有の数（+1 ボタンのクリック、Twitter のつぶやきなど） をソーシャル サービスごとに確認できます。
ページ レポート
では、ページごとにソーシャル上で共有された回数を比較し、どのページが最も共有されているかを確認できます。
Google アナリティクスの最新トラッキング コードをデフォルトの状態で使用している場合、
サイトに +1 ボタンを追加
すると、あなたのアカウントで 自動的に「+1」の Social Plug-in Analytics が有効になります。また、簡単な手順で、
他のサービスの Social Interaction Analytics を有効にする
（英語）こともできます。
ソーシャル 関連のレポートはまだ始まったばかりです。ますますインターネット上でソーシャルなサービス、共有が盛んになっていく中で、この新しいレポートが皆様のビジネスのお役に立つことを期待しています。ぜひ「+1」をご活用ください！
Written by Dan Rodney, Software Engineer
Original version:
+1 reporting in Google Webmaster Tools and Google Analytics
Google ショッピングのフィード仕様とポリシーの重要な変更
2011年7月12日火曜日
2011 年も残すところ約半年となりましたが、
Google ショッピング
は、引き続き、より快適なショッピング環境を提供すべく努めてまいります。
Google ショッピングの目標は、ユーザーが商品情報をすばやく簡単に検索できるようにし、各ショップを訪れる買い物客を増やすことです。このたび、そうした取り組みの一環として、Google ショッピングのフィード仕様とポリシーを一部変更することになりました。
2011 年 9 月 22 日時点で新しい仕様とポリシーの要件を満たしていないアカウントは停止となる可能性がありますのでご注意ください
( この変更は、日本、米国、フランス、英国、ドイツにおいて適用されます )。
変更点の要約
今回の変更によって、ユーザー エクスペリエンスが大幅に向上すると確信しています。以下に、日本でのフィード仕様の変更点をいくつか例示します。
追加の商品画像リンク:
商品の画像を複数登録したい場合、これまでは商品画像リンク [image link] 属性に複数登録していましたが、これからは [image link] 属性に登録する画像はひとつだけとし、追加分は [additional image link] 属性を使って登録してください。
在庫状況:
在庫がない商品も検索できるようにします。そのために、すべての商品アイテムの在庫状況 [availability] ステータスを必須の属性とします。
Google 商品カテゴリ:
新しい必須属性として Google 商品カテゴリ [google product category] を追加しました。この属性には、Google の分類に従って商品アイテムのカテゴリを指定します ( 現時点では一部の商品カテゴリに対してのみ必須です )。今後は、新しい属性と既存の商品カテゴリ [product type] 属性を併用することになります。
価格:
セールの期間と価格を [sale price effective date] と [sale price] 属性を使って指定できるようになりました。また、[price]、[sale price] 共に対象国の通貨単位も送信する必要がありますのでご注意ください ( 例: 150 JPY )。
ショップ向けの情報ドキュメント
新しいフィード仕様とポリシー、変更にあたって必要な準備など、詳しい情報へのリンクは以下のとおりです。
Google ショッピングの変更について - 2011 年夏
Google ショッピングの新しいフィード仕様
属性要件の一覧表
ファッション関連商品の登録に関するヒント
Google ショッピングの新しいポリシー
近日中に、変更点について詳しく説明した動画を公開する予定です。今後も詳しい情報を随時提供していきます。
Google ショッピングの新しいフィード仕様とポリシーの適用について
2011 年 9 月 22 日時点で新しい仕様とポリシーの要件を満たしていないアカウントは停止となる可能性があります ( 詳しくは上記のポリシーに関するドキュメントをご覧ください) 。なお、これらの変更は Google ショッピングにのみ適用されます。
Google 商品広告
と
Commerce Search
には適用されません。
Posted by 鈴木宏輔 / プロダクトマネージャー
インスタント プレビューのトラブル シューティングはウェブマスター ツールで
2011年7月8日金曜日
昨年の 11 月、Google は
インスタント プレビューを公開しました
。この機能は、検索結果の中のどのサイトが検索したキーワードに関連があるかどうか、ユーザーがそのサイトをクリックすることなく確認できる機能です。公開以来、Google インスタント プレビュー チームは、ページのインスタント プレビューのレンダリング結果に関する皆様からのフィードバックや問題点に着目してきました。
プレビュー画像に問題がある場合の主な原因は次のとおりです:
robots.txt によりサイト上の画像などへのアクセスがブロックされていたため、画像が表示されなかった。
ユーザーに実際に表示されるコンテンツと、Googlebot に見せるコンテンツが異なる、
クローキング
状態になっていた。
Flash が使用できない場合の代替コンテンツがきちんと作られていなかった。
皆様がこうした問題を診断するときに役立つよう、
ウェブマスター ツール
の [Labs] セクションにインスタント プレビュー ツールをご用意しました。
まず、インスタント プレビューを確認したいページの URL を入力します。すると Google はサイトからページを取得し、実際に Chrome ブラウザとインスタント プレビューで表示されるのと同様にそれぞれレンダリング （描画）します。なお、最新の WebKit ビルドを使用してレンダリングを行いますが、この WebKit ビルドには Flash や Silverlight などのプラグインは含まれていないことに注意してください。そのため、Flash などの表示箇所を空白にしないためには、代替コンテンツを用意する必要があります。代替コンテンツは、検索エンジンだけではなく、プラグインを持っていないサイト訪問者にも役立ちます。
レンダリング結果の下には、「リソースがない」、「リソースが robots.txt でブロックされている」など、レンダリング中に検出された問題が表示されます。今後も皆さまのインスタント プレビューの改善に役立つような情報をさらにお伝えしていけるよう改善を重ねたいと思います。
ご質問やご意見がありましたら、
ウェブマスター ヘルプ フォーラム
へお寄せください。
Posted by Michael Darweesh, Software Engineer
Original version:
Troubleshooting Instant Previews in Webmaster Tools
ラベル
+1 ボタン
2
AMP
11
API
3
App Indexing
8
CAPTCHA
1
Chrome
2
First Click Free
1
Google アシスタント
1
Google ニュース
1
Google プレイス
2
Javascript
1
Lighthouse
4
Merchant Center
8
NoHacked
4
PageSpeed Insights
1
reCAPTCHA v3
1
Search Console
101
speed
1
イベント
25
ウェブマスターガイドライン
57
ウェブマスタークイズ
2
ウェブマスターツール
83
ウェブマスターフォーラム
10
オートコンプリート
1
お知らせ
69
クロールとインデックス
75
サイトクリニック
4
サイトマップ
15
しごと検索
1
スマートフォン
11
セーフブラウジング
5
セキュリティ
18
ダイナミック レンダリング
1
データー ハイライター
2
ハッキング
19
ハングアウト
2
ビデオチュートリアル
7
フィードバックとコミュニケーション
1
プロダクトエキスパート
1
マルウェア
9
モバイル
2
モバイルサイト
54
リッチカード
2
リッチスニペット
12
リッチリザルト
4
画像
3
画像検索
2
検索エンジン最適化
13
検索結果
85
構造化データ
25
国際化
4
再審査リクエスト
9
初級者向け
160
上級者向け
203
中級者向け
206
動画
1
アーカイブ
2020
11月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
11月
10月
9月
8月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
4月
3月
2月
1月
2016
12月
11月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2013
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2012
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2010
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2009
12月
11月
10月
8月
7月
6月
4月
3月
2月
1月
2008
12月
Feed
Follow @googlewmc
