schema.orgがv3.1を公開、ホテルや旅館など宿泊業のサイトで使いたいプロパティを豊富に追加

[レベル: 上級]

schema.orgは、バージョン3.1を公開しました。
特に注目したいのは、ホテルや旅館など宿泊施設に関係するプロパティ(ボキャブラリ)が数多く追加されたことです。

LEGOLANDホテルのネームホルダー

LodgingBusiness と Accommodation に豊富なボキャブラリを追加

LodgingBusinessAccommodation にたくさんのプロパティが新たに追加されました。

LodgingBusinessは、ホテルや旅館、ホステル、B&Bなどの宿泊施設が利用できるschema.orgのタイプです。
Accommodationは、ホテルの部屋や貸し会議室、アパート、キャンプ場の1区画(1グループが利用する範囲)などの収容施設で利用できるタイプです。

たとえば、次のようなプロパティを設定できるようになりました。

  • starRating ―― 五つ星、三つ星などのホテルの格付け(利用者の評価ではない)
  • floorSize ―― フロア面積
  • amenityFeature ―― 提供されているサービス(たとえばホテルにあるサウナとかジム、ビジネスセンターなどの施設)
  • checkinTime / checkoutTime ―― チェックイン/チェックアウトの時間
  • petsAllowed ―― ペット同伴が可能か

宿泊関連ビジネスのサイトで使いたい構造化データ

ホテルや民宿などのサイトではぜひ使いたい構造化データのボキャブラリがschema.orgに登場しました。
また、そういういった宿泊施設を紹介するオンラインホテル予約サイトでも活用できます。

構造化データというコンピュータが理解しやすい形式で情報を提供すれば、検索ユーザーが求めるものにより適したページだと認識してもらえる可能性が高まるでしょう。
たとえば、「4つ星以上で、ペットと泊まれて、サウナがあるホテル」とユーザーが検索したとしたら、構造化データによって条件により合致したホテルを検索エンジンは探しやすくなるかもしれません。

上で紹介したプロパティのほかにも、部屋数 (numberOfRooms) や対応可能言語 (availableLanguage) なども設定できます。
どんなプロパティがあるかを、それぞれのタイプのページで確認してください。
そして可能な限り多くのプロパティで構造化してください。

なお、LodgingBusiness / Accommodation の下にHotel(ホテル)やHostel(ホステル)、Room(部屋)、Apartment(アパート)などのサブタイプがあります。
マークアップする際は、より詳細なタイプを利用することを推奨します。

schema.org 3.1に含まれる更新の詳細はリリースノートを参照してください。

- schema.orgがv3.1を公開、ホテルや旅館など宿泊業のサイトで使いたいプロパティを豊富に追加 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

モバイル検索結果がすべてAMPになる日が来る!? 巨大なAMP専用枠”Live Ticker”をGoogleがこの秋に導入予定

[レベル: 上級]

Googleは、”Live Ticker”(ライブ ティッカー)と呼ぶ、AMP用の新しいセクションをモバイル検索結果にこの秋に導入することを計画しているようです。
“Live Ticker”は、最新ニュースを掲載するためのAMPコンテンツ専用のセクションで、トップニュースのAMPカルーセルの上に表示されます。

パブリッシャー向けの発表会のなかで明らかにしたと、Digidayが報じています。

AMPカルーセルの上に表示される巨大な Live Ticker

Digidayの記事によれば、Live Tickerとは次のような特徴を持つセクションです。

  • トップニュース枠(AMPカルーセル)の上に表示される
  • ウェブのさまざまなソースから集めた、非常に新しいコンテンツが対象
  • AMPコンテンツだけを掲載する

記事には、プレゼンテーションでGoogleが見せたLive Tickerが掲載される検索結果のモックアップが紹介されています。

Live Tickerのモックアップ

モックアップを見ると、3週間ほど前に僕がたまたま遭遇したモバイル検索結果に酷似しています。

Live Tickerによく似たセクションが掲載される検索結果

スマホのスクリーンの下半分には、今やおなじみになったトップニュースのAMPカルーセルが表示されています。
そしてそのカルーセルの上には、ひときわ目立つ大きな1枚の”AMPカード”が表示されています。
これがLive Tickerに違いありません。

位置と大きさのため、カルーセルよりも目を引きます。(ハ◯頭の写真なのも視線を引く要因かもしれませんがw)。

発表会に参加していたパブリッシャーによると、この新しい Live Ticker は秋ごろの公開が予定されているそうです。

モバイル検索結果は、上から順にAMP、AMP、AMP?

クエリに最も関連した非常に新しいコンテンツ(プレゼンでは、”the best super-fresh content”と表現)に対して、Live Tickerが適用されるとのことです。

通常の検索結果にもAMPページを含める開発プレビューのモバイル検索をGoogleは先日公開しました。

Live TickerとAMP混在の検索が正式導入されたとすると、クエリによっては、モバイル検索結果に掲載されるコンテンツは上から順に次のようになるかもしれません。

  1. AMPのLive Ticker
  2. トップニュースのAMPカルーセル
  3. 通常の検索結果に混ざったAMPページ

ライブ配信や写真ギャラリー、実況中継など記事以外にもサポートを予定しているAMPコンテンツも発表会では紹介されたようです。
モバイル検索結果でAMPを掲載するセクションがさらに増えることになります。

ともすると、「検索結果に表示されるすべての結果がAMP」なんてことが近い将来に実際に起こりそうです。

たとえ今の段階ではAMP対応を見送っているとしてもまったく問題ないと僕は思います。
それでも、AMPの動向にはこれからも注視していきましょう。

- モバイル検索結果がすべてAMPになる日が来る!? 巨大なAMP専用枠”Live Ticker”をGoogleがこの秋に導入予定 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google、検索アナリティクスの表示回数・掲載順位・クリック数のデータについて詳細に説明するヘルプ記事を公開

[レベル: 中級]

Search Consoleで提供されている検索アナリティクス レポートの表示回数と掲載順位、クリック数のデータの取得方法や見方を詳細に説明するヘルプ記事をGoogleは新規に公開しました。

what-is-search-result-position.png

ウェブマスター必読のヘルプ記事

日常的に検索アナリティクスを利用するサイト管理者はもちろんのこと、たとえときどきであっても検索アナリティクスを利用するのであれば、必ず目を通しておくべきヘルプ記事です。

従来のように単に10個の青色リンクが並ぶだけの検索結果だったなら、読まなくても検索アナリティクスレポートの見方にさほど支障はないでしょう。
しかしながら、ユニバーサル結果やナレッジパネル、強調スニペット、AMPカルーセルなど現在の検索結果は多種多様です。
要素によって、表示回数とクリック数の数え方、掲載順位の割り当て方が変わってきます。

たとえば、ナレッジパネルは検索結果ページの(右側の)最上部に表示されますが、掲載順位としては11位が割り当てられることがあります。
1つのナレッジパネルには複数のリンクが含まれています。
サイト別に見るかページ別に見るかによって、リンクの表示回数の数え方が変化します。

AMPカルーセルは、カルーセル内のAMPページにはすべて同じ掲載順位が割り当てられます。
ただし、そのページの要約(サムネイル画像と記事タイトル)がカルーセルの中で表示されないと表示回数には含まれません。
ところが検索結果のカルーセルの中では表示されなかったとしても、AMPビューアの中で閲覧されれば表示されたことになり、かつクリック数も1カウントされます。

理解できるまで繰り返し読みたい

日本語ページができているので安心して読めます。
僕のブログでの一般的な解説は不要でしょう。

でも1回読んだだけでは意味を理解しづらい複雑なところあるかもしれません。
きちんと理解できたと自信が持てるまで、何度か読むことをおすすめします。

それでも説明していることがわからなかったり疑問が出てきたりしたときは、コメントかTwitterGoogle+で質問してください。
わかる範囲内ですが、アドバイスできると思います。

あるいはヘルプフォーラムで質問すれば僕以外のフォーラムメンバーからも回答してもらえます。

- Google、検索アナリティクスの表示回数・掲載順位・クリック数のデータについて詳細に説明するヘルプ記事を公開 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

AMPに構造化データはもはや不要、Search Consoleのエラーレポートからも外れる

[レベル: 上級]

Googleのモバイル検索結果にAMPページが表示されるには、有効なAMP HTMLでのマークアップに加えて、schema.orgを用いた構造化データが必須でした。
しかし、今後は必須でなくなります。

通常の検索結果にもAMPページを将来的に表示することを視野に入れた変更です。

またこの変更にあわせて、Search ConsoleのAMPレポートでは構造化データ関連の問題はエラーの対象から外れました。

AMPに構造化データはもはや不要

これまでは、AMPコンテンツを検索結果に表示させるには次のいずれかのschema.orgによる構造化データが必要でした。

  • schema.org/Article
  • schema.org/NewsArticle
  • schema.org/BlogPosting
  • schema.org/VideoObject

要件指定された構造化データでマークアップすることが、トップニュース枠のAMPカルーセルに表示される条件に含まれます。

オリンピック関連ニュースのトップニュースAMPカルーセル

しかし、通常の検索結果にもAMP対応したページを表示する開発プレビュー版のモバイル検索をGoogleは先週公開しました。

トップニュースのAMPカルーセルはニュース系のコンテンツが掲載対象だったのに対して、通常の検索結果ではコンテンツのタイプは問われません。
結果として、構造化データは必須ではなくなりました。

開発プレビュー版が公開された直後に、GoogleのJohn Mueller(ジョン・ミューラー)氏に確認をとりました。

通常の検索結果に対しては、(AMP用に)特別な構造化データのマークアップは必要ない。

AMPカルーセル掲載にはこれまでどおり必要

ただし、トップニュース枠のAMPカルーセルに掲載されるには、これまでどおり構造化データが必要です。
Article や NewsArticle など、先に挙げた4つのいずれかのタイプの schema.org を実装してください。

構造化データがAMPレポートのエラー対象から外れる

ここまで説明したように、通常の検索結果に表示されるAMPページには構造化データが必須ではなくなりました。

開発プレビュー版の検索結果は試験公開が始まったばかりですが、この変更を先取りしてSearch ConsoleのAccelerated Mobile Pagesレポートでは構造化データはエラーの対象から外れました。
次の2つは「問題」として依然としてレポートされるものの、エラー数を示すグラフには含まれなくなります。

  • 構造化データがありません
  • 無効な構造化データ

AMPエラーレポートの8月2日(正確には8月1日)の「更新」がこの変更を示しています。
この日を境にAMPエラーが急激に減っているサイトがあるかもしれません。

AMPエラーレポート

このキャプチャには出ていませんが、構造化データに問題がある場合はグラフの下のリストには「情報」というラベルとともにレポートされます(「エラーではないけれど可能なら修正してね」ということですね)。
ただし先ほども書いたように、グラフには含まれません。

なお、構造化データがAMPに必須ではなくなったこととSearch ConsoleのAMPレポートでの扱いに変更があったことは、Google+ヘルプページで公式にアナウンスが出ています。

もともと構造化データは、AMPの仕様に必要だったわけではなくAMPカルーセルに掲載するためにGoogleが独自で設定した要件でした。
AMP対応するプロセスのなかに構造化データが不要になったので、実装の敷居がいくらか下がりました。

通常の検索結果にAMPページを表示させることが果たして本当にいいことなのかどうかの議論はこれから本格的に始まるとして、AMP対応が自分のサイトのメリットになるかどうかを検証するために、少しの手間をかけられるなら、これを機に思い切ってAMP化してしまうのもいいかもしれません。

- AMPに構造化データはもはや不要、Search Consoleのエラーレポートからも外れる -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK?【海外&国内SEO情報ウォッチ】

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

  • AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK?
    Web担当者フォーラム 海外&国内SEO情報ウォッチ

日本語で読めるSEO/SEM情報

  • こうすればPageSpeed Insightsで100点満点を獲得できる!
  • 最も厄介なスパムは、それが正しいとサイト管理者が信じてやるもの
  • 「SEOに効果がある」が信じられない3つの理由
  • ガイドライン違反のアフィリエイトへの対応、アダルトサイトの年齢認証とクローキングなど7月2回目のオフィスアワー

海外のSEO/SEM情報を日本語でピックアップ

    >
  • 販売終了ページをカテゴリページやトップページにリダイレクトするとソフト404になる!?
  • いったん削除して404にしたページを復活したら評価は回復するか?
  • 良いリンクを否認しても、否認ファイルから削除すれば再評価される
  • HTTPS移行とCMS移行は同時に実行すべきか?
  • アプリではドロップダウンを使うべきでない!? 使わないほうが操作時間40%短縮

海外SEO情報ブログの掲載記事からピックアップ

  • 「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める
  • 低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき

SEO Japanの掲載記事からピックアップ

更新がなかったのでお休み。

こちらからどうぞ。

- AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK?【海外&国内SEO情報ウォッチ】 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

【ブログ読者へご連絡】8/4〜8/5のブログ更新をお休みします

TC Meetup

海外SEO情報ブログの読者のみなさまへ

いつもご訪問ありがとうございます。

8月4〜5日の2日間、Google主催のTop Contributor Meetup Tokyoに参加します。
Top Contributor Meetupは、Googleの公式ヘルプフォーラムで活動しているメンバーが招待される特別イベントです。
海外ではなく日本での開催ですが期間中めいっぱい楽しんできたいので、明日とあさってのブログ更新をお休みします。

金曜日のWeb担当者Forumの連載コラムはいつもどおりお届けします。

また来週お会いしましょう!

- 【ブログ読者へご連絡】8/4〜8/5のブログ更新をお休みします -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始

[レベル: 中級]

モバイル検索の通常の検索結果で、スマホ向けページに置き換えてAMPページを表示する実験をGoogleは開始しました。
これまでは、AMPに対応したページは「トップニュース」として、通常の検索結果とは別枠のカルーセル(またはリスト)の中に掲載されていました。

AMPページとスマホ対応ページが混在

通常の検索結果にAMPページが表示される実験用の検索ページには、g.co/ampdemo からアクセスできます(スマホでアクセスしてください)。
うまくいかない場合は、こちらからアクセスしてください。

トップニュース用のAMPカルーセルではなく通常の検索結果の中にAMPページが表示されます。
(僕たちにとっては)おなじみのAMPマークが付いているのですぐにわかります。

AMPページが通常の検索結果に差し込まれている

検索結果の上には、AMPを説明するためのメッセージが表示されていますね。

こちらは、AMPページとスマホ対応ページが混在する状況がもっとわかりやすい検索結果です。

AMPページとスマホ対応ページが混在

1つだけ(2つ目)が、スマホ対応で残りの3つはAMP対応です。

リッチスニペットの結果でもAMPとスマホ対応 (Mobile-friendly) が混在しています。

AMPとMobile-friendlyが混在するリッチスニペット

AMP対応ページがあるときはスマホ対応ページに置き換わる

検索結果に表示されたページにAMP対応したバージョンがあるときに、通常のスマホ対応バージョンのページに置き換わってAMP対応ページが表示されます。
つまりこの検索結果においては、AMP対応しているサイトでは通常のモバイル向けページは表示されなくなるということになります。

AMP対応していなければ、今までどおりにモバイル向けページが表示されます(モバイル対応していなければ、もちろん「スマホ対応」ラベルなしのPC向けページが表示される)。

ランキングアルゴリズムの変更ではない

注意したいのは、ランキングを決定するアルゴリズムの変更ではないという点です。

検索順位には影響しません。
そのページにAMP対応パージョンがあれば、代わりに、AMPページを優先して検索ユーザーに提示するというだけです。

AMPページを優先する理由は、単により速く表示されるページをユーザーに提供することで、ユーザー体験を向上させることが目的です。
AMPページの評価や順位を上げることが目的ではありません。

AMP対応で十分、スマホ対応は不要になる?

“early preview”(初期プレビュー)ということで、AMPを通常の検索結果に差し込むモバイル検索は実験が始まったに過ぎません。
実際に導入されるかどうかはユーザーの反応次第です。

とはいえ、いずれ導入されるだろうと個人的には思います。

ただし、解決しなければならない問題が出てくるだろうし、そのままではなくさまざまな改良がきっと加えられるでしょう。

通常の検索結果からだとしたら、AMPページにアクセスされることを望まないサイトがあるだろうことは容易に想像できます。

AMPは徹底的な高速性を追求するために、できることに制限がかかっています。
高速性を失わないようにさまざまな機能がAMPでも利用できるようにAMPプロジェクトは取り組んではいます。
しかし、今すぐに何でもできるようになるわけではありません。

AMP専用枠じゃないなら、通常のスマホ対応ページに来てもらったほうがメリットが多いと考えるサイトも必ず出てくるはずです。

またAMPページを優先表示するなら、モバイル向けページを作る必要がなくなりそうです。
Google検索のようにAMPをサポートするプラットフォームではなかったとしても、AMPページをユーザーに見せても問題はありません。
いっそのこと、これまでのモバイル向けページを完全にAMP対応ページに置き換えてしまったほうがコストも下がります。

もっとも、それはそれで良いことなのかもしれませんけどね。

いずれにしても、Googleが検索でAMPをどのように扱っていくのか、目が離せない状況は続きます。

- スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始 -

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 がきちんと返されています。

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が適用されていることを示しています。

dynamic_upgrade_mode: STRICT

www.google.co.jpには(まだ?)HSTSは実装されていません。
「dynamic_upgrade_mode」は「UNKNOWN」になっています。

dynamic_upgrade_mode: UNKNOWN

307リダイレクト

ブラウザがHSTSを認識している状態で、HTTPの http://www.google.com にアクセスしてみました。

307リダイレクトが返っています。

307 Internal Redirect

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は複雑にします。次のステップを推奨します。

  1. まず、HSTSなしでHTTPSを展開する。
  2. 短い期間を指定した max-age でHSTSヘッダーの送信から始める。ユーザーとほかのクライアントの両方からのトラフィック、また広告などの付属要素のパフォーマンスを監視する。
  3. 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

「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化【海外&国内SEO情報ウォッチ】

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

  • 「検索の意図はなし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト

日本語で読めるSEO/SEM情報

  • 目立ってる? 今度の検索結果の絵文字はパンくずリスト
  • お待たせしました、AMPの公式ドキュメント日本語版も順次公開!
  • App Indexingって何? おいしいの? という人におすすめの記事
  • ヤフーが48億ドルで身売り!?

海外のSEO/SEM情報を日本語でピックアップ

  • 音声検索は文字入力検索に比べてアクション系クエリが30倍多い
  • 大量のURLを再クロールさせるにはlastmod付きのサイトマップが役立つ
  • AMPの成功事例は今後もっと増えていきそう
  • 偽のスパムレポートを競合に繰り返し送られたらどうなる?
  • 外部サイトへの発リンクはランキングに悪い影響を与えるのか?

海外SEO情報ブログの掲載記事からピックアップ

  • Google、AMPに完全対応した爆速表示の広告 A4A を公開
  • Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示

SEO Japanの掲載記事からピックアップ

更新がなかったのでピックアップなし。

こちらからどうぞ。

- 「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化【海外&国内SEO情報ウォッチ】 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki