グーグル検索結果に同一サイトから表示されるページ数の上限は？

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

グーグル検索結果に同一サイトから表示されるページ数の上限は？
関連性が高ければいくつでも （John Mueller on Twitter）

1つのサイトから検索結果に同時に表示されるページ数に、決まった上限数はない

グーグルのジョン・ミューラー氏が、このようにコメントした。

昔のグーグル検索では、同じドメイン名のサイトからのページが1つの検索結果に出る数を2件に制限していた時期があった。しかし、今はその制限は存在しない。

たとえば、次の図のような状態だ（筆者のブログの例で申し訳ないが）。

同じサイトのページが3つ表示されている検索結果（パーソナライズ機能が影響しないように、シークレットモードで検索している）

クエリに対して関連性が高いとアルゴリズムが判断したページが同じサイトから何ページも表示されることは、今は決して珍しくない。

あるいは、関連性が認められるコンテンツがそのサイト以外に見つからない場合にも、同一サイトから複数の結果が同時に表示されることも多い（こういったクエリを見つけたら、関連性が高いコンテンツを作成するのも狙い目かもしれない）。

“過剰な”最適化というものはSEOに存在するのか？
言葉としては矛盾しているが起こりうる （Gary Illyes on Twitter）

「SEOの都市伝説を暴く」というトピックで良いネタがないかツイッターに訪ねていたグーグルのゲイリー・イリェーシュ氏に、あるフォロワーが少し変わった質問をした。

「過剰な最適化（over-optimization）」はどうでしょう？ アリなら、もっと適切な、矛盾していない名前を付けられませんかね？

「過剰な最適化」という言葉には、確かに矛盾がある。「最適化」は文字どおり「最も」適した状態を表す。それが「過剰」だというのは、言葉としては変だ。

イリェーシュ氏は次のように返信した。

いいね。だけど、良い呼び方を思いつかない。「最適化」のための行為をやり過ぎてしまうと結果として悪影響が出始めるという、文字どおりのことだからね。

名前や都市伝説かどうかはともかくとして、たしかに“過剰な最適化”は起こりうる。たとえば、こんなパターンだ。

• titleタグのキーワードが大切と聞く ⇒ titleタグにキーワードをたくさん詰め込む
• 外部リンクが重要なランキング要因と聞く ⇒ 自作ブログを開設しでっちあげのリンクを集める
• ページ数が多いと評価が上がると聞く ⇒ （中身が薄い）ページを量産する

どれも、アルゴリズムで評価を下げられたり手動対策の対象になったりする行為だ。

結局のところ、「過剰な最適化」とは、検索エンジンだけに目が向いていて、ユーザーにまったく目を向けていない人がやることだ。ともすれば結末は悲惨なことになる。

検索エンジン最適化の根底にはユーザー最適化があることを忘れてはいけない。

ダウンロード不要でアプリを動かせるInstant Appsが一般公開
オーガニック検索でも実行可能 （Android Developers Blog）

Android Instant Apps（アンドロイド インスタント アプリ。以下、Instant Apps）がすべての開発者に公開された。

Instant Apps は、ダウンロード・インストールすることなくアプリをスマホ端末で動かせる仕組みで、オーガニック検索からでも機能する。昨年5月のGoogle I/O 2016で発表され、今年1月に一部の開発者を対象に試験公開されていた。

先日開催されたGoogle I/O 2017 で紹介があったInstant Appsのデモを、以下で紹介する。

「nytimes crossword」で検索した検索結果からニューヨーク・タイムズ紙が提供するクロスワードのアプリがInstant Appsで起動するようになっており、これによってリピートユーザーが増加しているとのことだ。

アプリ開発者にとってInstant Appsは、アプリの利用を増やすチャンスとして試してみたくなる仕組みではないだろうか。アプリとウェブの両方を提供しているとしたら、「ウェブサイトか？ それともネイティブアプリか？」の悩ましい選択肢に、また1つの要素が加わったようにも思う。

1つ注意したいことがあるとしたら、Instant Appsは、アプリを動かすのに必要なデータを都度ダウンロードする点だ。通信環境が良くない状況ではうまく機能しないことも予測される。もっとも高速で安定した通信環境が整っている日本では、さほど気にすることではないのかもしれないが。

Instant Appsを実装するための詳細は元記事（英語）とドキュメント（一部日本語）を参照してほしい。

HTTPからHTTPSへの移転にアドレス変更ツールを使えるのか？
サポート予定もなし （John Mueller on Twitter）

ジョン・ミューラー氏がツイッターでフォロワーから次のように質問された。

Search Consoleのアドレス変更ツールで、HTTPS移転をサポートする予定はありますか？

ミューラー氏は次のように答えた。

いや、その予定はない。その場合、リダイレクト設定するのがいちばん良い方法だ。

HTTPからHTTPSへの移行に際してのアドレス変更ツールの利用は、たびたび出てくる質問あるいは要望だ。ミューラー氏によれば、サポート予定はないし、301リダイレクトによる転送だけで十分だとのことである。

なおアドレス変更ツールは、サブディレクトリ単位の移転にも対応していないことも知っておこう。対応しているのはドメイン名の移転だけだ。

フェイスブックのインスタント記事がグーグルのAMPに対応!?
Facebook Media （え？ そっちなの！？）

記事コンテンツを高速に表示する技術と言えば、真っ先に思い浮かぶのはAMPだろう。AMPはグーグルが中心になって開発している。

同じような技術として、フェイスブックも「インスタント記事（Instant Articles）」という仕組みを用意している。

しかしこの2つには、いくつかの違いがある。

• AMPはオープンソースなので、どんなプラットフォームでもAMPをサポートできる。すでに、ツイッターやはてなブックマークなど多くのプラットフォームがAMPをサポートしている。

  インスタント記事は独自仕様なので、フェイスブックへのコンテンツ配信にしか使えない。

• AMPはコミュニティが形成されており、世界中の開発者が改良を続けている。

  インスタント記事はフェイスブックが独自に開発しているので、その仕様に一般の開発者が入り込む余地はない。

こうした事情（と大人の事情）により、インスタント記事の発行を中止するパブリッシャーも出現している。

このような状況のなかフェイスブックは、なんとAMPをサポートする拡張機能をインスタント記事の仕組みに導入した。インスタント記事用のコンテンツを作っておけば、それをAMP対応に変換できるようになったのだ。

インスタント記事を成功させるために、ライバル関係にあるグーグル主導のAMPにフェイスブックが対応するというのは、見方によっては皮肉的な話だ。

AMPがオープンソースだったことも影響しているに違いない。グーグルと特別な提携を結ぶことなく、フェイスブックはAMPの技術を利用できるからだ。

とはいえ、進む方向が微妙である気もする。インスタント記事の表示にAMPをそのまま使えるようにすればいいと思うのだが、なぜそうしないのだろうか。

やはり、自社が扱う広告を派手に挿入したいし、コンテンツを囲い込みたいのだろうか……少しもやもやするニュースだ。