海外SEO情報ブログ

[レベル: 上級]

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

[レベル: 上級]

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

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

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

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

[レベル: 上級]

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

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

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

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

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

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

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

スマホのスクリーンの下半分には、今やおなじみになったトップニュースの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

[レベル: 中級]

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

• 表示回数、掲載順位、クリック数とは – Search Console ヘルプ

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

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

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

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

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

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

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

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

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

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

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

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

[レベル: 上級]

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対応したページを表示する開発プレビュー版のモバイル検索をGoogleは先週公開しました。

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

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

@suzukik @methode For AMP in the "normal" search results you don't need any special structured data markup.

— John Mueller (@JohnMu) 2016年8月2日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今週のピックアップ

• AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK？
  

日本語で読める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記事まとめ10+2本

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

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

海外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

[レベル: 中級]

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

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

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

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

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

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

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

リッチスニペットの結果でも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が検索を完全に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

HTTPからHTTPSへの移行に際して、Googleニュースに登録しているパブリッシャーからよく尋ねられる質問とその回答を、Google+のGoogleウェブマスター公式アカウントが共有しました。

長山さんがそのうち日本語に訳してくれるように思いますが、それまでのつなぎとして代わりに僕が翻訳したものをこのブログに掲載します。

基本的には、Googleニュースに登録しているサイト向けですが、一般サイトのHTTPS移行のときにも役立つ情報も含まれています。

ではお読みください。

Googleニュース登録サイトのHTTPS移行でよくある質問

Q. HTTPSに一度に移行すべきですか？ それとも少しずつ移行すべきですか？

Q. どのくらいの期間テストを実行すべきですか？

Q. 1セクションだけから始めたとしても、サイト全体をHTTPSで利用できるように計画しています。HTTPSのコンテンツが先にインデックスされないように、リダイレクトやrel=”canonical”を使うべきですか？

Q. HTTPのサイトマップをrobots.txtで参照しています。HTTPSの新しいサイトマップを含むように更新すべきでしょうか？

Q. HTTPS化のテスト中は、HTTPSのセクションをどちらのサイトマップに記述すべきでしょうか？

Q. HTTPSバージョン用のrobots.txtに、特別に何か追加するものはありますか？

Q. 私たちのHTTPSサイトは、まだ移行していないページをHTTPにリダイレクトして戻しています。サイトマップには何を記述したらいいでしょうか？ HTTPとHTTPSの両方のURLをサイトマップに記述するのでしょうか？ テストしているセクションで、HTTPの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ニュースサイトマップを使っています。部分的に少しずつ移行するとしたらどうしたらいいですか？

Q. HTTPSの移行に伴って、Google ニュース パブリッシャー センターでやることが推奨されるようなことは何かありますか？

以上です。

常時HTTPSへの移行を計画している人は、僕のブログのHTTPS移行時のステップ・バイ・ステップも参考にしてください。

- Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答 -

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

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

今週のピックアップ

• 「検索の意図はなし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化
  

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

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

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

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

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

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

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

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

こちらからどうぞ。

• 「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化 などSEO記事まとめ10+2本

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

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

高品質なページに比べて低品質なページがサイト内にたくさんあるからといって、必ずしも、サイト全体の評価が下がるわけではありません。
とはいえ、質が悪いコンテンツばかりのサイトをユーザーが気に入るはずがありません。
したがって、ユーザー体験を高めるためにも低品質なページは削除するか改善することが望まれます。

Googleはページ数だけで評価しない

英語版のオフィスアワーで参加者がこんな質問を投稿しました。

もしサイト内のページの70%が低品質で、30%が高品質だったとしたら、Googleが直接割り当てるドメインスコアが低くなって、最終的に、サイト全体のランキングに影響しますか？

GoogleのJohn Mueller（ジョン・ミューラー）氏は次のように回答します。

なんとも言えない。場合によってはそういうことがあるかもしれない。

検索検索のどの順位にそうしたURLを配置したらいいかを私たちが判断する際には、単にページの数だけではなくもっと多くのことを見ている。

たとえば、カレンダーのスクリプトをサイトに1つ設置し、それが100,000ページを自動生成していて、同時に、質が本当に高いページも5つ持っている状況を考えてみてほしい。

スクリプトで作られた実質的に中身がない100,000ページと良い5ページという理由だけで、悪いウェブサイトということにはならない。

その5ページはとても良いページだということだってありえるから、検索結果で表示したいと私たちは考えるかもしれない。特定のクエリに対して検索結果で表示するのにふさわしいかもしれないからだ。役に立つ情報を提供するかもしれないし、ユーザーの疑問を解決するかもしれない。抱えている問題を解く助けになるかもしれない。

したがってページ数だけを見るというものではない。

だが一般的に言って、サイトを見て、「粗雑なページがたくさんある、このページのコンテンツは古くて質が低い」と感じたのなら、Google側のアルゴリズムによる対処がどうであれ削除した方がいい。

ユーザーがそういうのに出くわしたなら、「この1ページだけはすばらしいけど、このサイトにある他のページは本当にひどい」と言うかもしれない。そんなことになったら、忠実なユーザーにはそのユーザーはならないだろう。もう戻ってこないだろうし、ほかの人にあなたのサイトを勧めることもないだろう。

アルゴリズムの評価が下がるとは限らないがユーザーの評価は下がる

たとえ低品質なページが大部分を占めていたとしても、高品質なページに対するアルゴリズム的な評価までもが下がるとは限らないようです。
クエリによっては、（数少ない）高品質ページが検索結果で上位表示することがありえます。

しかし、低品質なコンテンツばかりのサイトをユーザーが好きになるはずがありません。
1回訪問して、それっきりでしょう。
ブックマークしたりRSSに登録したりすることはないでしょう。

リピーターになってもらう、評判を高めるという観点からは質が低いコンテンツは存在させるべきではありません。

もっとも、質が低いコンテンツばかりのサイトは検索結果でも全体的に不利になる傾向にあるように僕は経験から感じます。
むやみにページ数を増やすのではなく、本当に質が高いコンテンツだけでサイトを作り上げたほうが全体的な評価が上がるはずです。

また可能であれば、低品質だからといって単純に削除するのではなく高品質になるように改善するほうが好ましいことを最後に付け加えておきます。

- 低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき -

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

[レベル: 上級]

AMPプロジェクトは、コンテンツのライブ更新を可能にする仕組みとして <amp-live-list> のベータ版を試験公開しました。
amp-live-listを実装すると、追加のナビゲーションやページのリロードなしでコンテンツを最新の状態に動的に更新できます。

AMPページをリロードなしで即座に更新

こちらはAMPプロジェクト公式ブログのアナウンスで紹介されている amp-live-list を実装したAMPページのデモです。

“YOU HAVE UPDATES”（更新があります）という青いメッセージが画面上部に出現したあと、上にスクロールして戻ると新しいコンテンツが追加されています。

読み込んだという感覚は皆無で、AMPページの高速表示はまったく損なわれていません。

amp-live-list は刻々と状況が変化するコンテンツ向き

刻々と状況が変化するコンテンツに amp-live-list は向いています。

たとえば、イベントの内容をリアルタイムで配信するライブブログです。
執筆者が新たに書き込んだ記事を次から次へとAMPページで読むことができます。

amp-live-list は、ページのコンテンツの一部分だけに利用することが可能です。
スポーツの試合のスコアや選挙の開票状況を掲載しているページでは、ページ全体を更新する必要はありません。
スコアや開票状況の部分だけリアルタイムで更新すれば十分です。
こうしたケースでは、限定した部分のみに amp-live-list を適用することができます。

AMPは、変化しない静的なコンテンツに向いている技術なのに、ライブ更新が可能になるというのは面白い機能ですね。

バックグラウンドで、コンテンツを配信しているサーバーとクライアント（ブラウザ）が直接”ポーリング”して、コンテンツに更新があるかどうかをチェックするのだそうです。
更新があれば、更新を動的にクライアントのページに差し込みます。

しかしAMPで高速化を実現しているキャッシュシステムをスルーするわけではありません。
データ量やスマホ側の帯域幅、CPUの負担を削減するためにAMPキャッシュの機能は依然として活躍しています。

amp-live-list によるライブ更新を必要とするサイトはそう多くはなさそうな気がしますが、興味があるなら試してみるといいでしょう。

実験段階なので利用するにはオプトインする必要があります。
JavaScriptコンソールで次のコードを実行するか、もしくは専用ページからオプトインします。

AMP.toggleExperiment('amp-live-list')

そのほか、amp-live-list の詳しい仕組みと実装方法に関しては、公式アナウンスとGitHubを参照してください。

- AMPページでライブ更新を可能にする amp-live-list が試験公開される -

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

[レベル: 中級]

Googleにおいては、301リダイレクトを設定した場合、いくらかのPageRankが喪失します。
しかしこれはもう過去の話です。
現在では、301リダイレクトや302リダイレクトを含む30x系のリダイレクトでPageRankが失われることはありません。

Googleのゲイリー・イリェーシュとジョン・ミューラーがともに認める

PageRank喪失の仕様が現在は適用されないことを最初に明らかにしたのは、GoogleのGary Illyes（ゲイリー・イリェーシュ）氏です。

30x redirects don't lose PageRank anymore.

— Gary Illyes (@methode) 2016年7月26日

30xのリダイレクトがPageRankを失うことはもうない

ゲイリーのツイートが正しいことを、John Mueller（ジョン・ミューラー）氏も、昨日のオフィスアワーで認めています。

これからは安心して301/302リダイレクトを使える

301リダイレクトによるPageRankの喪失をGoogleが発生させていた大きな理由は、スパム対策です。

301を不正に利用する人たちがいます。
たとえば、301リダイレクトを繰り返して大元のサイトを隠蔽したりします。
マネーロンダリングみたいなものですね。
そうした不正利用に対処するためでした。

不正利用への別の対策が可能になったのかどうかはわかりませんが、いずれにしても現在は301リダイレクトでPageRankが失われることはありません。
喪失処理の撤廃は301リダイレクトだけではなく、302リダイレクトも307リダイレクトも含めて、300系リダイレクトすべてに当てはまります。

リダイレクトの影響で失われるPageRankはもともと微々たるものでした。
気にかける必要はまったくなかったのです。

それでもSEOを意識している人にとってはインパクトがある情報だったため、ドメイン名移転やHTTPS移行に際して301リダイレクトを使うことに強い抵抗を示す人がたくさんいます。
それしか手段がないにもかかわらずです。

ですが、もはやそういった（本当に些細な）心配をする必要はなくなりました。
これからは安心してリダイレクトを使えます。

ちなみにPageRank喪失の仕様が廃止されたのは、最近の話ではなくしばらく前からとのことです。

なお、301リダイレクトと302リダイレクトはどちらもPageRankを渡します。
「302リダイレクトはPageRankを渡さない」は必ずしも正しくありません。
301よりも302が適切だと考えるなら、302を使ってもなんら問題ありません。

301と302、307をはじめ各種リダイレクトの違いはこちらの記事を参照してください。

- 「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める -

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

[レベル: 初級]

「ありがとうございます！」「参考になりました！」こういった非常に短い、ただの感想コメントはそのままにしていおいても問題ないのでしょうか？
それとも削除すべきなのでしょうか？

GoogleのJohn Mueller（ジョン・ミューラー）氏がTwitterでフォロワーからの質問に回答しました。

スパムコメントを私は削除しています。「この記事に本当にひらめきを得ました！」のような感謝系のコメントはそのままにしおくべきでしょうか？ それとも削除すべきでしょうか？

まったくあなた次第だ。私にとっては、問題ないものもあるだろうし、単にリンクを張ろうとしているものもあるだろう。

コメント管理はしっかりと

コメントはそのページのコンテンツの一部になります。
有益なコメントはほかのユーザーの役に立つことがあります。
コメントに書き込まれたことが検索にひっかかって、検索トラフィックが生じることすらあるでしょう。

とはいえ、「ありがとうございます！」「参考になりました！」のようなコメントがたくさん集まってもページの価値を上げることはなさそうです。
そうは言っても、本当に感謝の気持ちを伝えるために（人間）が書き込んでくれたのであれば、もちろん嬉しいことなのでそのままにしておいてもまったく問題ありません。

問題なのは、自動生成されたコメントやまったく関連性がないページヘのリンクを落としていくスパムコメントです。
放置しておくとそのページやサイト自体の評価が下がることがあり得ます。
その記事を読んだユーザーに不快感を与えるようなコメントは根本的に削除すべきです。

たいていのCMSは、コメント内のリンクにnofollowが自動で付く設定になっています。
しかしそれでも、リンク獲得を目的としたコメントなら削除対象にしたほうがいいでしょう。

コメントを開放しているサイトの管理者は、コメント管理も重要な仕事であることを認識しておかなければなりません。
自動承認せずに手動で承認したり、スパムコメントを弾くプラグインなどを活用できます。

コメントではありませんが、サイト管理者ではなくユーザーが生成したコンテンツが理由でGoogleから手動の対策を受けたケースが過去にあったので紹介しておきます。

• Mozilla、UGCスパムが原因でGoogleから手動ペナルティを喰らう
• 米スプリント・ネクステルがUGCスパムを理由にGoogleから警告を受ける

最後におまけを。

WordPressのコメントスパム対策プラグインといえば、Akismetが有名です。
僕はこれに加えてSiteGuard WP Pluginのコメント認証も併用しています。

SiteGuard WP Pluginの良いところは、「日本語」のキャプチャをコメント投稿時に要求することです。

自動化されたボットのコメントスパムは海外（特にロシアや中国）から来るものが大半です。
キャプチャ認証を使っていても、英数字だとくぐり抜けてしまうコメントスパムもあります。

しかし海外製なので日本語入力ができません。
つまりSiteGuard WP Pluginの日本語キャプチャをパスできないのです。

Akismetは、ほとんどのスパムコメントを検出してスパムボックスに入れてくれますが、それでもコメント自体は投稿されてしまいます。
SiteGuard WP Pluginなら投稿すら拒絶します。

SiteGuard WP Pluginを入れて以来、スパムコメントが本当に激減しました。
ほかにもセキュリティを高める機能があり、SiteGuard WP Pluginは僕のお気に入りのプラグインの1つです。

- 「ありがとうございます！」のような感謝系の1行コメントを削除すべきか？ -

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

5月にオーストラリアのアデレードでBig Digital Adelaideというカンファレンスが開催されました。
このときに、GoogleのGary Illyes（ゲイリー・イリェーシュ）氏に Woj Kwasi氏が1対1でインタビューし、それをブログに公開しています。

Wojさんから許可を得たので、一部ではありますが、そのインタビュー記事を僕のブログで紹介します。
RankBrainや検索結果クリックデータ、AMP、アプリなど興味深い部分に絞って翻訳したのできっと参考になるはずです。

RankBrain

Q. RankBrainが、どうやってGoogleがクエリをより適切に理解できるようにしているのかを説明してもらえますか？ コア アルゴリズムとどんなふうに調和しているのでしょうか？

検索結果のクリックデータ利用

Q. 検索結果をランキング付けするときに、クリック率と同様に検索結果への直帰もGoogleは考慮しているというのは本当ですか？

ボットの割合

Q. インターネットのどのくらいの割り合いが、ボットに対して本当の人間ですか？

透明性

Q. 昨年2月に透明性をより高めるとGoogleは公表しました。これはGoogleにとって優先事項ですか？ 透明性をもっと高めるべきだと考えていますか？

ウェブ vs. アプリ

Q. モバイルウェブよりもモバイルアプリの開発に投資したほうがいいビジネスはありますか？

AMP

A. どんな状況でAMPを考慮すべきですか？

音声検索

Q. 音声検索で使われている語句や用語はテキスト入力とどんなふうに違っていますか？

以上です。
特にインパクトがあったのはどれだったでしょうか？

この記事では一部分だけの紹介ですが、全文はKwasiさんの元記事をお読みください。

Gary Illyes Interview – Let Me Google That For You

Thank you, Kwasi! :)

- Googleのゲイリーに、RankBrain・クリックデータ・AMP・アプリetc.について質問してみた【オーストラリア編】 -

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

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

今週のピックアップ

• 「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説
  

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

• AMPの耳寄り情報ツイート×14
• 常時HTTPSは○○だから良くない――それは古い知識からの思い込みかも!?
• 検索結果のタイトル書き換え、強調スニペット、PubSubHubbub、HTTPSなど7月のオフィスアワー
• プログレッシブ ウェブ アプリの実装でコンバージョン率が200%以上に！
• Search Consoleの「HTMLの改善」に対処しなくても検索順位が下がることはない

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

• ポップアップで隠されたメインコンテンツをグーグルは重要視しないかも
• サイトの統合・分割とドメイン名の移転を同時にしたら、グーグルの処理に長い時間がかかることも
• 「ペンギンはもう更新しないなんて、誰が言った？」グーグル社員が噂を否定
• JSON-LDのschema.org構造化データを簡単に作れるツールが登場

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

• HTML文法的に正しくないheadセクションの中のrel=hreflangやrel=canonicalをGoogleは認識しない
• 【確定】誰が記事を書いたかをGoogleはランキング要因にしていない、もう一度ジョン・ミューラーに質問してみた。

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

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

こちらからどうぞ。

• 「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説 などSEO記事まとめ10+2本

- 「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説【海外＆国内SEO情報ウォッチ】 -

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

[レベル: 上級]

Googleモバイル検索のトップニュースのAMPカルーセルに掲載されるにはその記事に画像が必須で、構造化データで指定します。
画像のサイズには要件があり、幅 (width) は 696px 以上です。
しかし高さ (height) には、最小サイズの要件はありません。

公式ドキュメントには高さの要件記載なし

トップニュースのカルーセルに必要な構造化データを説明した、Google公式のドキュメントには画像のサイズ要件が示されています。

Images should be at least 696 pixels wide.

画像の幅は最小で696ピクセルです。

ところが、幅の要件の記載はあるのですが、高さの要件の記載がありません。
高さ対しては要件は指定されていないのでしょうか？

高さの最小要件は定められていない

「高さは何でもいいのか？」という疑問に対して、GoogleのTomo T氏はヘルプフォーラムで次のように回答しています。

There is no minimum height requirement for images. As a general rule of thumb, the bigger the image provided, the better they would look in the carousel. In the spirit of AMP, it’s also important to be considerate with the img file size and format; as such, bitmaps aren’t recommended :)

画像に対しては、高さの最小要件はない。一般的な経験則から言えば、大きい画像を提供すればするほどカルーセルできれいに見える。

AMPの精神として、適切なファイルサイズとフォーマットを検討することも大切だ。たとえばビットマップは推奨されない。

ということで、AMP記事の構造化データで指定する画像のサイズは、横 (width) は 696px 以上である必要がありますが、縦 (height) には最小サイズの要件はありません。

大きけれが大きいほどいいようですが、だからといって 10,000px の画像は度を超えてますね。

画像のファイルフォーマットにも注意しましょう。
サポートされるのは、.jpgと .png、.gif になります。

[注意] 画像サイズの要件は、構造化データで指定する画像、言い換えればカルーセルに表示させたい画像に対して要求されます。
カルーセルに掲載するつもりがない画像には最小サイズは要求されません。任意のサイズの画像を掲載できます（構造化データに含める必要もない）。

- AMPカルーセルの画像サイズは幅が696px以上、縦は最小要件なし -

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

[レベル: 初級]

Googleは、その場所を訪れた人がだいたいどのくらい時間滞在しているのかをローカルナレッジパネルに表示する機能を公開しました。

著名なランドマークやテーマパーク、博物館・美術館などの施設の平均滞在時間を知ることができます。
モバイル検索で利用可能です。

平均滞在時間

こちらは、東京スカイツリーのローカルナレッジパネルです。
1年前に導入された「訪問数の多い時間帯」の下に平均滞在時間が表示されています。

こちらは、先日世界文化遺産に登録された国立西洋美術館の平均滞在時間です。

こちらは、キッザニア東京の平均滞在時間です。
ここには「観光プラン」のラベルが付いています（ほかには見つけられなかった）。

旅行の計画に役立つかも

旅行の計画をたてるときに、どのくらいの時間をその場所で見込んでおけばいいかを見積もるのに「平均滞在時間」の機能は役立ちそうです。

と思ったのですが、ディズニーランドで3時間は短すぎませんかね？

3時間では、下手すれば、2時間並んで1つのアトラクションに乗って終わりですよね。

ロケーション履歴を有効にしているユーザーから収集したデータをもとにしていると思われますが、実際の状況と合っていない場合もありそうです。
あくまでも参考程度にとらえておいたほうが安心かもしれません。

また、レストランやカフェなどは対象になっていないようです。
個人的には、飲食店の滞在時間がわかるともっと便利なように思いました。

- Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示 -

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

[レベル: 上級]

Google (AMP Project) は、AMPページでも高速で表示される広告として、AMP for ads、略称 “A4A” を公開しました。
メインコンテンツの表示を遅らせることなく、広告のすばやい表示を A4A は実現しています。

広告表示も爆速

A4A 広告 と A4A ではない広告の表示速度にどのくらいの違いがあるかをデモンストレーションしたアニメーションを、AMP Projectが公式ブログの記事で紹介しています。

左が A4A ではない普通の広告で、右が A4A 広告です。
ページの上部にデモ用の青いバナー広告が表示されます。

検索結果をタップしてページに飛んだあと、A4A ではない普通の広告が完全に表示されるまでには3.12秒かかっています。
それに対して、A4A 広告は0.5秒で表示が完了しています。

訪問者に広告をしっかりと見てほしい広告出稿者と広告掲載者にとっては、広告がすばやく表示されることはとても重要です。
かといって、広告表示を優先するあまりページ本体の表示を遅くしてしまったのでは、「限りなく速く」というAMPの基本精神を無視してしまうことになります。

ページの表示速度を犠牲にすることなく広告の高速表示も可能にしたのが、A4A、つまり AMP for ads になります。

A4A を速くしている要素

AMP for ads の高速表示を可能にするために、いくつもの技術が用いられています。
簡単に説明します。

リクエストとレンダリングを分離

広告のリクエストとレンダリングを完全に分けています。

サーバー側では、広告のリクエストが発生するとオークションなどの処理が発生し時間がかかることがあります。
一方クライアント（ブラウザ）側では、受け取った広告のレンダリングのためにCPUやメモリなどのリソースを消費するので、ページのメインコンテンツのレンダリングを遅らせる原因になります。

A4A では、両者を分離することでページのレンダリングが遅くなることを防いでいます。

AMPの制限されたサブセット

A4A はAMPの仕様に従って構成されます。
しかし、すべての仕様が広告にとって必要というわけではありません。

A4A の場合は、必要な一部分だけに制限して、AMPの仕様に従っているかどうかの有効性を検証するので、バリデーションチェックの時間が短縮されます。

また一般的な広告は、その広告（のコード）がさまざまなことを自由に実行できますが、A4A においては何ができるかはAMPが完全にコントロールします。
スピードを落とすような余計なことはできないということですね。

AMP用解析の再利用

広告には、その広告専用の解析機能を実装することが珍しくありません。
3個の広告を1つのページに掲載したら、3つの解析ツール（つまりJavaScript）が稼働するかもしれません。
表示を遅くさせる原因になります。

A4A では、amp-analytics を利用して計測します。
amp-analytics を利用すれば1つのコードで複数の計測が可能です。

見えるときだけ開始

A4A 広告は、それがスクリーンの見える範囲にあるときだけに表示されます。

たとえば、ページのいちばん下にある広告は、ページを下までスクロールして表示領域に入ったたときに初めて掲載のための処理が始まります。

また状況に応じてアニメーションのフレームレートを抑えるなど、スクロールなどのユーザー体験を阻害しないような仕組みも実装しています。

AMP for adsは2週間前に公開されたばかりで、まだ正式に仕様が固まったわけではありません。
それでも、広告が重要なビジネスモデルになっているパブリッシャーにとっては、AMPで実現できる高速性を犠牲にせずに掲載できる A4A はとても魅力的に映るのではないでしょうか。

AMPはオープンソースなので、どの広告ベンダーでも A4A に対応した広告を配信できます。
これも優れた点といえます。

A4A の技術的な詳細は、Githubで確認してください。

- Google、AMPに完全対応した爆速表示の広告 A4A を公開 -

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