Googleは、Accelerated Mobile Pages (AMP) を通常の検索でサポートするモバイル検索を正式に公開した。ゆっくりと展開している。まず米Googleのモバイル検索から導入が始まったと思われ、日本のGoogleではまだ変化はない。
- Google、AMPをサポートするモバイル検索を正式公開。ゆっくりと展開し、まずは米国から導入開始か？ -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
「Google SEO」タグアーカイブ
Xmasイベントのように毎年開催するイベントには同じURLを使い続けるのがSEOに強い
クリスマスイベントのように毎年毎年、繰り返し行われるイベント用に設置しているページを検索に強くするにはどうしたらいいのだろうか？簡潔に言うと、最新の回のイベントに関するコンテンツに対しては常に同じURLを使い続け、終了した回のイベントのコンテンツは別のURLのページに移動するのがベスト。
- Xmasイベントのように毎年開催するイベントには同じURLを使い続けるのがSEOに強い -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Google、ローカルナレッジパネルに「ウェブ上のレビュー」を追加。レストランやテーマパークなどに対するさまざまなレビューサイトでの評価が検索結果でわかる
[レベル: 中級]
Googleは、ローカルナレッジパネルに「ウェブ上のレビュー」を追加しました。
「ウェブ上のレビュー」には、さまざまなレビュー系サイトから集められた平均評価が掲載されます。
レビューサイト運営者は、Review snippetsを設定することで「ウェブ上のレビュー」に含めてもらいやすくなります。
ローカルナレッジパネルに掲載された「ウェブ上のレビュー」
レストランやショップ、テーマパーク、公園など場所や建物に関係するナレッジパネルにウェブ上のレビューは掲載されます。
こちらは昭和記念公園のナレッジパネルに掲載されたウェブ上のレビューです。
Facebookとジョルダンのウェブページに投稿されているレビューの情報が採用されています。
こちらはテーマパークのウェブ上のレビューです。
こちらはレストランのウェブ上のレビューです。
レビューの採用元がそれぞれ異なっているのがわかります。
どこから引っ張ってくるかはアルゴリズムによって判断されます（提供元として選ばれやすくする方法は後述）。
最大で3つのサイトからのレビュー情報が掲載されます。
PC検索でもウェブ上のレビューを見ることはできます。
詳しく書かれたレビュー記事を引用する「Critics reviews」という機能が先月から米国では試験的に始まっています。
Critics reviewsとウェブ上のレビュー（英語では「Reviews from the web」）は両方とも掲載されます。
ナレッジパネルでのレビュー情報をGoogleは充実させるように取り組んでいるようです。
なおCritics reviewsは米Googleだけですが、「ウェブ上のレビュー」は世界中のGoogleで利用可能です。
Review snippetsの設定方法
さて、ここまでは一般ユーザーに向けての「ウェブ上のレビュー」という新機能の紹介です。
あなたがレビューを集めるサイトを運営しているなら、ローカルナレッジパネルのウェブ上のレビューに掲載されやすくすることができます。
ウェブ上のレビューは、技術的な用語では「Review snippets（レビュー スニペット）」と呼ばれます。
ローカルビジネスの場合のレビュー スニペットにはschema.orgを用いた次の2つの構造化データのマークアップが必要です。
- Review（レビュー）
- Local Business（ローカルビジネス）
構造化データを使うことにより、レビューのデータをGoogleは集めることができます。
そして、あなたのサイトでのレビューの対象とナレッジグラフに登録されているローカル”エンティティ“とを結び付けることができます。
レストランやお店、テーマパークなどのレビューを集めているサイトならレビュー スニペットに必要な構造化データを設定しておくといいでしょう。
ナレッジパネル経由でのアクセスが増えることが期待できます。
- Google、ローカルナレッジパネルに「ウェブ上のレビュー」を追加。レストランやテーマパークなどに対するさまざまなレビューサイトでの評価が検索結果でわかる -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
直帰率や滞在時間をランキングシグナルとしてGoogleは使っているのか？ アルゴリズム評価には使っているが個々の検索結果を変更する目的では使わない
[レベル: 初〜中級]
Googleは、検索結果でのクリック率や直帰率、サイトでの滞在時間をランキングに反映させているのでしょうか？
たびたび出てくるこの質問にGoogleのJohn Mueller（ジョン・ミューラー）氏が直近のウェブマスターオフィスアワーで答えました。
検証には使っているが、個々のレベルでは使っていない
次の質問が尋ねられました。
Googleは、ランキングシグナルとして直帰率を使っていますか？
ミューラー氏はこう答えます。
直帰率みたいなものは、Googleアナリティクスのようなツールで昔から計測されている指標だ。でも、私たちはGoogleアナリティクスを検索順位を決めることにはまったく使っていない。検索に対しては通常は使っておらず、結びつけてはいない。
（クリックや直帰など）そういったデータを実際に使っている1つの場面は、アルゴリズムを評価するときだ。
概して、どちらのアルゴリズムがいいかを検証するときに使う。数百万の検索結果、数百万のさまざなサイトにわたって検証することができる。そして、「概して言えば、集計データに基づくとこちらのアルゴリズムのほうがうまくいってるな」と言うことができる。
だが、もっと狭い範囲では、そういうことは本当には簡単にはできない。私が知る限りでは、直帰のようなものはランキングには使っていない。
質問が続きます。
たとえば、1,000人のユーザーが訪問したとします。
300人のユーザーは探していたものを見つけた。400人のユーザーはそこそこ時間をサイトで費やしたけれど、また検索を続けた。400人はすぐに検索結果に戻った。
こういったユーザー行動の状態をGoogleは見ていますか？ 検索順位を変化させますか？
ミューラー氏の回答は次のようでした。
基本的には先ほども言ったとおりだ。
非常に幅広く集約されたデータにおいては、そういったもののなかには見ているものも確かにある。何百万ものサイト、何百万もの検索結果を見たときには、そこから妥当な有用性を得ることができると思う。
しかしページ単位では、そういったことは普通は簡単にできるものではないだろう。
Googleアナリティクスのデータを検索には使っていない、これは信じていいでしょう。
すべてのサイトがGAを導入しているわけではありません。
ウェブ全体を考えれば、むしろ導入していないサイトのほうが多いのではないでしょうか。
そういった限られたデータを利用することは信頼性に欠けます。
一方で、検索結果でのクリックなどユーザー行動を実際に利用している場面があります。
それは新しいアルゴリズムを導入したり、アルゴリズムに改良を加えるときです。
検索品質評価者や、あるいは一般ユーザーを対象にしたテストで、新しい検索結果が良いものかどうかを判断するときの材料にしています。
たとえば、以前よりもユーザーがクリックしなくなったり再検索が増えたりしたとしたら、新しい検索結果は品質が返って落ちたと判断されるかもしれません。
テストで良い結果が得られれば実際に導入されるだろうし、良い結果が得られなければ導入は見送られるかもしれません。
アルゴリズムの改良や品質のチェックにクリックなどのユーザーデータが使われることは、GaryがGoogle Dance Tokyoで日本に来たときも説明していました。
さて問題は、個々のサイト/ページにおける検索結果でのユーザー行動がランキングに直接反映されるのかどうかです？
特にここ2、3年盛り上がっている（？）トピックです。
ミューラー氏によれば、ものすごく限られたデータだから簡単には利用できないとのことでした。
何百万もの検索結果とサイトを基にした集計データはアルゴリズムの評価に役立つけれど、1つのページや1つの検索結果だけのデータをそのまま検索結果には反映させることには問題があるからです。
あなたはどう思いますか？
僕はジョンを信じることにします。:）
- 直帰率や滞在時間をランキングシグナルとしてGoogleは使っているのか？ アルゴリズム評価には使っているが個々の検索結果を変更する目的では使わない -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Google、ローカルビジネス向けレビューの構造化データのガイドラインを更新。悪いレビューも許可すること、サードパーティサイトのレビューはマークアップ不可など
[レベル: 中級]
Googleは、レビューの構造化データの仕様・ガイドラインを更新しました。
特にローカルビジネス向けのレビューに対して、重要な変更が含まれます。
ローカルビジネス向けレビューの新しいガイドライン
レストランやホテル、ショップなど実店舗型のビジネスが顧客のレビューをサイトに掲載し、構造化データでマークアップする際のガイドラインが更新されました。
下が、2016年8月4日に更新された、この記事を書いている時点でのローカルビジネスのレビューのガイドラインです。
- Snippets must not be written or provided by the business or content provider unless they are genuine, independent, and unpaid editorial reviews.
- Reviews must allow for customers to express both positive and negative sentiments. They may not be vetted by the business or restricted by the content provider based on the positive/negative sentiment of the review before submission to Google.
- Reviews cannot be template sentences built from data or automated metrics. For example, the following is not acceptable: “Based on X number of responses, on average people experienced X with this business.”
- Reviews for multiple-location businesses such as retail chains or franchises can only be submitted for the specific business location for which they were written. In other words, reviews for multiple-location businesses cannot be syndicated or applied to all business locations of the same company.
- Aggregators or content providers must have no commercial agreements paid or otherwise with businesses to provide reviews.
- Do not include reviews that are duplicate or similar reviews across many businesses or from different sources.
- Only include reviews that have been directly produced by your site, not reviews from third-party sites or syndicated reviews.
日本語訳
日本語ページが存在しないので、日本語にしました。
- 本物で、関係性がなく、対価を支払わず自発的に書いてもらったものでない限りは、レビューは、ほかのビジネスやコンテンツ提供者によって書かれたり提供されたりしたものであってはいけません。
- レビューは、好意的な意見と批判的な意見のどちらも顧客が表せるようでなければなりません。Googleに投稿する前に、そのレビューが好意的か否定的かという感情にもとづいて、ビジネス運用者によって審査されたりコンテンツプロバイダーによって制限されたりしてはいけません。
- レビューは、データや自動解析から作られた定型文であってはいけません。たとえば次のようなレビューは許可されません ―― 「◯件の返信にもとづくと、たいていの人はこのサービスに対して◯◯を体験しています」
- チェーン店やフランチャイズのように複数の場所で営業しているビジネスに対するレビューは、そのレビューが書かれた店舗の場所においてのみ投稿できます。言い換えると、複数の場所で営業しているビジネスのレビューを、同じ経営元のほかの場所の店舗に複製したり掲載したりすることはできません。
- レビューを配信するサービス提供者やコンテンツプロバイダーは、対価を支払っても支払わなくても、レビューを提供するために営利目的の契約を結んではいけません。
- たくさんのビジネスに渡る、あるいは異なるソース元からの、重複したり類似したりするレビューを含めてはいけません。
- あなたのサイトに直接投稿されたレビューだけを含めてください。サードパーティのサイトからのレビューや同報配信されたレビューを含めてはいけません。
わかりやすい日本語版
僕の日本語訳では意味がわかりにくいところがあったのではないでしょうか。
オリジナル自体が（僕にとっては？）わかりづらい英語で書かれていて、日本語に訳しづらい表現が多いのです。
要点を絞って、わかりやすく書き換えたのがこちらです。
- 純粋な顧客ではない評論家や業者によってレビューが書かれたとしたら、そういった人・業者にはお金を払っていてはいけないし、関係性があってはいけない。宣伝目的ではなく、中立な立場でのレビューでなければならない。
- 良いレビュー、悪いレビューのどちらも顧客は投稿できるようにする。悪いレビューだからといって検閲してはいけない。
- 自動生成したレビューを掲載してはいけない。
- 複数の店舗があるビジネスでは、レビューを掲載できるのはその場所の店舗（のサイト/ページ）だけ。たとえば、新宿・渋谷・池袋の3か所にお店があったとして、新宿店に対して書かれたレビューを渋谷店や池袋店（のサイト/ページ）に掲載することはできない。
- レビューサイトは、営利目的でレビューを提供してはいけない。
- 同一または類似したレビューを掲載してはいけない。
- 構造化データでマークアップできるのは自分のサイトに投稿されたレビューだけ。たとえば、Googleや食べログに書き込まれたレビューを自分のサイトに掲載してそれをマークアップしてはいけない。
お金を払って書いてもらったレビューをマークアップしてはいけないのは当然として、レビューが批判的だから掲載しないとか、別の店舗のレビューを使いまわしするとか、レビューサイトに書かれたレビューをコピーしてそれをマークアップするとか、気を付けなければならない点がいくつもあります。
ガイドラインに違反していると、構造化データでマークアップしていてもリッチスニペットが検索結果に出なくなることがあります。
悪質な場合は手動対策の対象になるかもしれません。
あなたがローカルビジネスを営んでいてレビューの構造化データを設置しているなら、ガイドラインに沿っているか点検してください。
- Google、ローカルビジネス向けレビューの構造化データのガイドラインを更新。悪いレビューも許可すること、サードパーティサイトのレビューはマークアップ不可など -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
JavaScriptのクロール用に特別なユーザーエージェントをGoogleは持っていない、JSの処理はクロールとは別
[レベル: 中級]
Googleは、JavaScriptをクロールするために特別なUser Agent（ユーザーエージェント）を持ってはいません。
通常のGooglebotがJavaScriptもクロールします。
JavaScriptのクロール用に特別なUAは存在しない
GoogleのJohn Mueller（ジョン・ミューラー）氏に、フォロワーがTwitterで次のように質問しました。
JavaScriptやAjaxを多用したサイトに対しては、普通のGooglebotとは異なるGooglebotがいるんですか？
ミューラー氏はこのように返信します。
特別なUAはない。だが、クロールの直後にいつもレンダリングするとは限らない。それでたぶん、そういうふうに考えたのではないだろうか？
@ramirez_robert @methode No special UAs, but rendering isn't always immediate on crawl, maybe that's what you're seeing?
— John Mueller (@JohnMu) 2016年8月4日
JavaScript/Ajaxをたくさん使ったサイトを質問したユーザーは運用しているらしく、インデックスへの反映が遅いため、JavaScript専用のクローラがいるのではないかと疑ったようです。
しかし、JavaScriptであろうが通常のGooglebotがクロールします。
JSコンテンツのインデックスへの反映が遅い（遅く見える）理由
その後のやり取りを見ていると、JavaScript/Ajaxコンテンツのインデックスへの反映が遅いと質問者が感じた理由は、主に次の2つの要因によると思われます。
- JavaScriptの実行は別プロセス
- キャッシュはインデックスとは異なる
JavaScriptの実行は別プロセス
ミューラー氏が触れているように、JavaScriptはクロールと同時に実行されるわけではありません。
そのページのHTMLのクロールと、そのページにあるJavaScriptの実行は別々に処理されます。
JavaScriptも含めてレンダリングした、そのページの最終的なコンテンツのインデックスができあがるまでには時間がかかることもあります。
以前に詳しく解説しました。
キャッシュはインデックスとは異なる
質問者は、Googleのキャッシュを見てインデックス状態を判断していた可能性があります。
キャッシュを見た場合、そのページのJavaScriptを処理するのはGooglebotではなくあなたが今使っているブラウザです。
レンダリングが完了してGooglebotが実際に見ているページをキャッシュでは確認することはできません。
Googlebotがそのページをどのように見ているかを正確に知るには、Fetch as Googleのレンダリングを使います。
こちらも以前に詳しく解説しました。
ということで、この記事で伝えたかったことをまとめると、
- JavaScriptのクロールのために特別なGooglebotは存在しない
- JavaScriptのクロールとその処理は同時とは限らないため、インデックスへの反映にタイムラグが生じることがある
となります。
- JavaScriptのクロール用に特別なユーザーエージェントをGoogleは持っていない、JSの処理はクロールとは別 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleの検索結果に直接投稿する機能のテスト参加が拡大、ブラジルとインドにも展開予定
[レベル: 上級]
メッセージや画像、動画をあたかもソーシャルメディアであるかのように検索結果に直接投稿する機能をGoogleは試験的に公開しています。
この機能を、より多くのスモールビジネスに提供する予定とのことです。
また利用できるのは米国だけだったのが、ブラジルとインドにも展開していきます。
検索結果に投稿するとは？
TwitterやFacebookに投稿するように、メッセージや画像、動画を投稿してGoogleの検索結果にそのまま表示させることができます。
もともとは今年の3月に、米国の大統領選挙の候補者のために提供された機能です。
こちらは、ヒラリー・クリントン (Hillary Clinton) 氏の投稿が差し込まれている検索結果です。
TwitterやFacebook、Google+での投稿ではありません。
ヒラリーさんの名前の下には”on Google”というラベルが記載されています。
どこかのソーシャルメディアではなく、「Googleに」投稿したということを示したいのでしょう。
検索結果に直接投稿する機能はその後、限られた数の中小規模のローカルビジネスに対しても試験的に提供が始まりました。
もう少し詳しいことはWeb担当者Forumの連載コラムで説明したので、そちらを参照してください。
より多くのローカルビジネスに開放、ブラジルとインドにも展開
ローカルSEOのエキスパートである、Mike Blumenthal（マイク・ブルーメンソール）氏によると、検索結果に投稿する機能（「Google Posts」などと呼ばれることがあるが、正式な名称をGoogleは公表していない）をさらに数十のローカルビジネスが利用できるようにGoogleは予定しているとのことです。
こちらは新たに試験運用に参加したと思われる、My Special Dayというウェディングドレスのブティックの投稿です。
ショップ名の下には、ヒラリーさんと同じように”on Google”のラベルが付いていますね。
投稿をタップ/クリックすると、その投稿が拡大表示されます。
また米国だけで提供していた機能ですが、ブラジルとインドにも展開するとのことです。
Googleが新しい機能を試験的に公開する場合は、たいてい大手企業のサイトが相手になります。
しかしこの機能に関しては、スモールビジネスが選ばれています。
珍しいことです。
大規模なビジネスであればFacebookやTwitterなどのソーシャルメディアを効果的にすでに利用できているはずです。
いっぽうで小さなお店では、ソーシャル運用まで手が回らないことも多いでしょう。
そういった小規模ビジネスに露出チャンスを与えたいというのがGoogleの狙いなのかもしれませんね。
そして、米国の次がなぜブラジルとインドなんでしょうね。
ソーシャルメディアがさほど普及していないから？
この機能は回線速度が遅くても利用しやすかったりするから？
実験のまま終了するか、このまま日本にも展開してくるかはまったくわかりません。
それでも「おもしろそう」と興味を持ったなら、ウェイティングリストに登録しておくといいでしょう。
- Googleの検索結果に直接投稿する機能のテスト参加が拡大、ブラジルとインドにも展開予定 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Google、レストランのナレッジカードに批評レビュー記事を掲載。Critic reviews用のschema.orgが掲載には必要。
[レベル: 上級]
Googleは、批評家が書いたレストランやカフェのレビュー記事をナレッジカードに掲載するようにしました。
批評レビュー記事を提供しているサイトは、構造化データでマークアップすることでナレッジカードに掲載される機会を得ることができます。
ナレッジパネルに掲載される批評レビュー
こちらは「restaurants seattle」（レストラン シアトル）の検索結果に出てきたローカルパックです。
3つ出てきたレストランの下に「E」のロゴとともに、短いスニペットが見えます。
これらは、”食”をテーマにしたEaterというサイトに掲載された、そのレストランが言及された記事のタイトルです。
タップするとそのレストランのナレッジカードに移動し、そのレストランを紹介している、もっと多くのレビュー記事を見ることができます。
ここでは、レストランレビューサイトのZagat（現在はGoogleが所有）のレビューが「Critic reviews」（批評レビュー）というラベルとともにトップに大きく掲載され、そのほかのレビューがその下にリストアップされています。
レビューをタップすれば、そのサイトに移動してレビュー記事の全文を読めます。
必ずしも、レストランのレビューサイトだけからとは限りません。
The GuardianやCBS Localのようなニュースサイトも混じっています（レビューが掲載されるサイトは後述）。
PC検索のナレッジパネルにも「Critic reviews」は出てきます。
ちょうど1年前に、映画やTV番組に対する批評家のレビュー記事を、同じように「Critic review」としてGoogleはナレッジパネルに掲載し始めました。
レストランやカフェなどのローカルビジネスにも批評家によるレビュー記事の掲載をGoogleは拡大したのです。
構造化データで批評レビューをマークアップ
あなたのサイトがレストランの批評記事を提供しているなら、Critic review向けの構造化データでマークアップすることによりナレッジカードに掲載される機会を得ることができます。
Critic reviewsに必要なschema.orgは、デベロッパーサイトに先日公開されました。
ただし、Critic reviewはまだ試験運用中です。
ZagatやEaterなど限られたパートナーサイトが参加しているにすぎません。
興味を持った場合は、専用フォームから参加をリクエストする必要があります。
ローカルビジネスの批評レビューは、今のところ米Google (google.com) の英語のレビューが対象です。
しかしほかの国と言語にもすぐに展開するとのことです。
ユーザーによって投稿されたレビューではなく、精通しているライターによって書かれたレストランのレビュー記事を掲載しているサイトは今のうちから準備に取り掛かると面白いかもしれませんね。
ナレッジカードを通じて、あなたの批評レビュー記事をさらに多くのユーザーに読んでもらえるチャンスを手にできそうです
批評レビューのナレッジカード掲載に興味を持ったならこちらのGoogle公式情報をお読みください。
- Inside Search: Never miss a “must-try” with Google Search
- Official Google Webmaster Central Blog: Promote your local businesses reviews with schema.org markup
- Reviews | Search | Google Developers
- Google、レストランのナレッジカードに批評レビュー記事を掲載。Critic reviews用のschema.orgが掲載には必要。 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように
[レベル: 上級]
Googleが検索を完全にHTTPS化して以来まもなく5年がたちます。
さらにセキュリティを高めるために、www.google.comドメインで HTTP Strict Transport Security (HSTS) の実装を始めたことをGoogleはアナウンスしました。
HSTSを適用したことにより、米Google検索を含む www.google.com ドメインを利用するときの2回目以降は、たとえ http で始まるURLでアクセスしようとしたとしても、ブラウザ側で https に置き換えてアクセスするようになります。
※HSTSに詳しくなければ、Web担当者Forum連載コラムでの解説をご覧ください。このブログのHTTPS移行の際にもHSTS（とPreload HSTS）を実装しています。
www.google.com のHSTSを検証
www.google.com が本当にHSTSになっているかどうかを確かめてみました。
HTTPヘッダー
HTTPヘッダーでは、Strict Transport Security がきちんと返されています。
ちなみに、max-age が「86400」に設定されています。
単位は秒で、86,400秒は1日です。
非常に短い期間ですが、www.google.com は極めて巨大なサイトなので、移行にともなって発生するかもしれない問題を回避するためにあえてこのように短く設定しているとのことです。
今後数か月かけて、最低でも1年間の有効期間になるまで徐々に増やしていく予定です。
GoogleニュースのHTTPS移行でも、max-age を徐々に増やしていくことをGoogleはアドバイスしていましたね。
僕は最初から1年（31536000秒）でした。w
Google Chrome
Chromeのアドレスバーに「chrome://net-internals/#hsts」を打ち込むことで、ブラウザ（Chrome）が認識しているHSTSのステータスを調査することができます。
www.google.comで検索します。
「dynamic_upgrade_mode」の「STRICT」が、HSTSが適用されていることを示しています。
www.google.co.jpには（まだ？）HSTSは実装されていません。
「dynamic_upgrade_mode」は「UNKNOWN」になっています。
307リダイレクト
ブラウザがHSTSを認識している状態で、HTTPの http://www.google.com にアクセスしてみました。
307リダイレクトが返っています。
307はブラウザ内部でのリダイレクトです。
HSTSが正常に動作している証拠ですね。
GmailやYouTubeはすでにHSTSを実装しています。
Google検索のHSTS適用はむしろ遅めだったのかもしれません。
今のところは、www.google.com だけですが、いずれは www.google.co.jp はもちろんのこと世界中のGoogleに広めていくのでしょう。
常時HTTPSのサイトをあなたも運営しているなら、セキュリティをさらに高めるためにもHSTS（とPreload HSTS）の実装をお忘れなく。
- Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答
HTTPからHTTPSへの移行に際して、Googleニュースに登録しているパブリッシャーからよく尋ねられる質問とその回答を、Google+のGoogleウェブマスター公式アカウントが共有しました。
We collected a few questions from news publishers related to HTTP to HTTPS site moves, but some of the answers are relevant to all webmasters who are considering going secure.
長山さんがそのうち日本語に訳してくれるように思いますが、それまでのつなぎとして代わりに僕が翻訳したものをこのブログに掲載します。
基本的には、Googleニュースに登録しているサイト向けですが、一般サイトのHTTPS移行のときにも役立つ情報も含まれています。
ではお読みください。
Googleニュース登録サイトのHTTPS移行でよくある質問
Q. HTTPSに一度に移行すべきですか？ それとも少しずつ移行すべきですか？
A. トラフィックとインデックスに影響がないかどうかをテストするために、サイトの一部分だけを初めは移行することを推奨します。その後は、サイトの残りを一度に移行してもいいし、部分部分に分けて移行しても構いません。サイトの最初にテストするセクションを決める際には、変更する頻度が少なく、頻繁だったり予測できなかったりする出来事によって大きな影響を受けないセクションを選ぶようにします。
1つのセクションだけを移行するのは移行を試すのにとてもいい方法ですが、検索に関して言えば、必ずしもサイト全体の移行の見本になるとは限らないことを覚えておいてください。多くのページを移行すれば移行するほど、解決が必要になってくる別の問題に直面しやすくなります。問題を最小限に抑えるために、綿密に計画します。
Q. どのくらいの期間テストを実行すべきですか？
A. クロールとインデックスが変更を認識できるようにするため、それに加えてトラフィックを監視するために数週間を予定してください。
Q. 1セクションだけから始めたとしても、サイト全体をHTTPSで利用できるように計画しています。HTTPSのコンテンツが先にインデックスされないように、リダイレクトやrel=”canonical”を使うべきですか？
A. 技術的な仕組みから、リダイレクトを設置したらそういったページ（HTTPでインデックスさせたままのHTTPSページ）をテストできないでしょう。したがって、rel=”canonical”を推奨します。
Q. HTTPのサイトマップをrobots.txtで参照しています。HTTPSの新しいサイトマップを含むように更新すべきでしょうか？
A. HTTPのサイトマップとHTTPSのサイトマップをそれぞれ指すように、HTTP用とHTTP用にrobots.txtファイルを別々に分けることを推奨します。また、1つのURLは片方のサイトマップだけに記述するようにすることも推奨します。
Q. HTTPS化のテスト中は、HTTPSのセクションをどちらのサイトマップに記述すべきでしょうか？
A. 移行するセクションだけのサイトマップを別個に作ることができます。こうすれば、テスト対象のセクションのインデックスをより正確に追跡できます。ただし、テスト対象のURLがほかのサイトマップに重複しないようにくれぐれも注意してください。
Q. HTTPSバージョン用のrobots.txtに、特別に何か追加するものはありますか？
A. いいえ、ありません。
Q. 私たちのHTTPSサイトは、まだ移行していないページをHTTPにリダイレクトして戻しています。サイトマップには何を記述したらいいでしょうか？ HTTPとHTTPSの両方のURLをサイトマップに記述するのでしょうか？ テストしているセクションで、HTTPのURLがHTTPSのURLにリダイレクトしている場合はどうなるでしょうか？
A. ユーザーが訪問したときにリダイレクトするかどうかにかかわらず、HTTPのURLはすべてHTTP用のサイトマップに、HTTPSのURLはすべてHTTPS用のサイトマップに記述します。リダイレクトとは関係なしにサイトマップにページを記述すれば、新しいURLを検索エンジンがより早く発見する手助けになります。
Q. includeSubDomains をHSTSヘッダーに設定した場合、どのドメインに影響しますか？
A. サイト全体をHTTPSに移行したあとは、セキュリティをさらに高めるためにHSTSプリロードに対応させることができます。HSTSを有効にするためには、
includeSubDomainsディレクティブをHSTSヘッダーに設定しなければなりません。
includeSubDomainsが設定されたHSTSヘッダーを www.example.com のサイトが返したとしたら、次のようなドメイン名のサイトに適用されます。
- www.example.com
- foo.www.example.com
しかし、次のようなドメイン名のサイトには適用されません。
- notexample.com
- foo.example.com
ただし、HTTPに戻す際の手順をHSTSは複雑にします。次のステップを推奨します。
- まず、HSTSなしでHTTPSを展開する。
- 短い期間を指定した
max-ageでHSTSヘッダーの送信から始める。ユーザーとほかのクライアントの両方からのトラフィック、また広告などの付属要素のパフォーマンスを監視する。- HSTSの
max-ageの期間を徐々に増やしていく。HSTSがユーザーと検索エンジンに悪い影響を与えなかったら、望むのであれば、ChromeのHSTSプリロードリストにサイトを追加するように依頼できます。
[鈴木補足: HSTSとプリロードHSTSがわからない人は、Web担当者Forumのコラムでの解説記事をお読みください。]
Q. サイト全体に対して単体のGoogleニュースサイトマップを使っています。部分的に少しずつ移行するとしたらどうしたらいいですか？
A. HTTPSの新しいセクションに対してニュースサイトマップを使いたいのであれば、プロトコルが変わったことを知らせるためにニュースチームにコンタクトを取らなければなりません。その後、Search ConsoleのHTTPSのプロパティで、HTTPSに移行したセクションごとに新しいGoogleニュースサイトマップを送信できます。
Q. HTTPSの移行に伴って、Google ニュース パブリッシャー センターでやることが推奨されるようなことは何かありますか？
A. パブリッシャーセンターはHTTPからHTTPSへの移行を透過的に処理します。ニュースサイトマップを利用しないのであれば、一般的には、Googleニュースの観点からは何もする必要はありません。その場合は、ニュースチームにコンタクトして変更について知らせてください。変更したセクションについても知らせることができます。たとえば、HTTPSへ移行している場合は、http://example.com/section を https://example.com/section へ移行していることを指定できます。
以上です。
常時HTTPSへの移行を計画している人は、僕のブログのHTTPS移行時のステップ・バイ・ステップも参考にしてください。
- Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki