手間なしUX改善！ HTMLちょい修正で実現できる、かんたん画像lazy-load【SEO記事12本まとめ】

今週のピックアップ

手間なしUX改善！ HTMLちょい修正で実現できる、かんたん画像lazy-load
Chrome以外のブラウザもサポートしてほしい （Hara Kazunari on Twitter） 国内情報

ページ表示を高速化してUXを改善するのに、ページをスクロールに従って画像を読み込むようにする「遅延読み込み（lazy-load）」が効果的だ。

これまで画像の遅延読み込みはJavaScriptライブラリなどを使って実現するものだったのだが、ついにGoogle Chromeウェブブラウザが、ネイティブ lazy-load を正式にサポートした（Chrome 76から）。

つまり、JavaScript のライブラリを使用しなくても、HTMLタグを少しいじるだけで画像が遅延読み込みされるようになったのだ（さらにiframeも同様に遅延読み込みできる）。

画像であれば、img タグに loading 属性を追加し、値に "lazy" を指定するだけでいい（loading 属性の値についてはこちらの記事を参照）。

<img src="cuty-cat.jpg" loading="lazy" alt="かわいい猫" height="700" width="1200" />

現時点でサポートしているのはChromeだけとはいえ、JavaScriptの知識がまったくなくてもlazy-loadを実装できるのは注目に値する。ほかのブラウザが追随してサポートすることを期待したい。

サイバーエージェントのエンジニアである原氏は、こえのブログにさっそく実装したとのことである。

あなたのサイトで実装してみたい場合、技術がわかる人に「グーグルの技術情報」とともに「polyfill（ポリフィル）もあるらしい」と伝えるといいだろう。Chrome以外のブラウザも考慮した仕組みにうまくしてくれるかもしれない。

グーグル検索SEO情報

モバイルアプリのインストール促進バナーをなくしてDAUが17%増加
CTRは上がるがビジネス指標は向上 （Luke Wroblewski on Twitter） 海外情報

アプリのインストールを勧めるバナーをサイト訪問時に表示させる構成についての注意点を、グーグルのルーク・ロブルースキー氏がツイッターに投稿した。

端的に言えば、アプリインストールバナーはユーザー体験を損ねるため使用しないほうがいいのことだ。

ロブルースキー氏による指摘は6件の連続ツイートによるものだが、ポイントを抜粋して日本語で紹介する。

訪問した瞬間にページいっぱいに表示されるアプリバナーは、一見すると成果を出すように思える。

あるサイト（今はなきGoogle+）では、クリック率は9%だった！

しかし、70%のユーザーはクリックもインストールも、さらにそれ以上サイトを見ることもなく完全に離脱していた。

一方、アプリバナーを削除したらインストールは2%減少したものの、モバイル版Webサイトの日別アクティブユーザー数は17%増加した。多くの事業で、アクティブユーザー数の増加は喜ばしいことだろう。

アプリインストールバナーは、サイトの重要なコンテンツを不明瞭にしてしまう。

ある調査によれば、世界でも最大規模のいくつかのECサイトでは、アプリバナーがある種の離脱を引き起こしており、その離脱につながる直接の原因はアプリバナー以外には見つからなかったという。

アプリインストールのバナーはビジネスの最も重要な指標にマイナスの影響を与える。ECサイトであれば、コンバージョンである購入を妨げてしまう。

2つの事例であるから、アプリインストールバナーがどんなビジネスにおいても悪いというわけではない。したがって、UX向上のためには、検証とユーザーテストが大切だともロブルースキー氏は補足している。

MFIに移行してほしいとグーグルに申請できるのか？
オプトインもオプトアウトもできない （#AskGoogleWebmasters on YouTube） 海外情報

モバイル ファースト インデックス（MFI）への移行を、サイト側から申し込むことはできないのか？

この質問に、グーグルのジョン・ミューラー氏が、YouTubeで行っている「#AskGoogleWebmasters（グーグルのウェブマスターに質問しよう）のシリーズで次のように回答した。

長期的な目標は、すべてのサイトをモバイル ファースト インデックスに移行することだ。だが、オプトインあるいはオプトアウトの仕組みを提供する計画はない。

現状では、モバイル ファースト インデックスへの準備ができているかどうかをアルゴリズムで判断し、一気に移行する。準備ができているかどうかを決定するには、モバイルサイトとPCサイトを比較する。そして構造化データと画像を含むすべてのコンテンツがモバイルサイトにあるかどうかを確認する。

またモバイル ファースト インデックスとモバイルフレンドリーは別ものだ。モバイル向けサイトを持たなくても、モバイル版Googlebotがきちんとインデックスできれば問題ない。

つまり、残念ながら、

モバイル ファースト インデックスの準備が確実にできているはずなのに、なぜかうちのサイトは移行されない

といった場合でも、移行してもらうようグーグルにリクエストすることはできない。グーグルが認識するサイトは膨大なので、すべて一度には移行できないのだそうだ。よって、MFIに移行されるのを待つしかない。

逆に、モバイル向けサイトを持たないからといって、モバイル ファースト インデックスへの切り替えを拒否することもできない（そもそも、ミューラー氏が言うようにモバイル ファースト インデックスとモバイルフレンドリーは無関係だ）。

モバイル ファースト インデックスの準備ができていないとしても、最終的には強制的にすべてのサイトをMFIに移行するとグーグル社員から筆者は聞いている。なお、2019年7月1日からはグーグルが新たに発見したサイトは最初からモバイル ファースト インデックスになっている。たとえ、準備が整っていなかったとしてもだ。

サイトマップは、URL発見で2番目に重要な情報源
昔から変わらず （Search Engine Roundtable） 海外情報

サイトマップは、GooglebotがURLを発見するのに、2番目に重要な情報源だ

グーグルのゲイリー・イリェーシュ氏は、スペインで6月に開催されたSEOカンファレンスでこのように発言したそうだ。

5年前のロンドンでのカンファレンスでも同じことを言っていたそうで、依然として状況は変わっていないとのことである。

非常に大規模なサイトでは、サイトマップに記載するURLを精査しないと本当にクロールしてほしいURLにクローラーが回ってこないことがあると聞く。しかし、一般的なサイトであれば、サイトマップは絶対に送信しておくべきだろう。新規コンテンツの公開と既存コンテンツの更新をグーグルに知らせる手段になる。

検索エンジン向けサイトマップのベストプラクティスをグーグルは2015年に解説している。もし読んだことがなければ読んでおくといい。

ところで、URLの発見においてサイトマップが2番目に重要な情報源ならば、最も重要な情報源は何だろうか？

おそらく、グーグルが新しいURLをみつけるのに最も重要な情報源は、昔から変わらず「リンク」のはずだ。

SEO業界のトップ2が語ったSEOの「現在」と「未来」
実に学びの多いトークイベント （DemandSphere） 海外情報

アイレップの渡辺隆広氏とJADEの辻正浩氏をゲストにしたトークイベントのレポートを紹介する。テーマはもちろんSEOだ。「現在のSEO」と「これからのSEO」について、両氏の洞察力に富んだ考えを聞くことができる。

元記事から、Q&Aをいくつか紹介しよう。

質問
最近の検索アルゴリズムにはどのような傾向があると感じられていますか？

辻氏：

お客さまからもよく「Googleは何を見ているの？直帰率や滞在時間？」と質問されるんですが、直帰率も滞在時間も見ていません。数多くのデータや実験からそう断言できます。直帰率70％・滞在時間30秒でもユーザーを満足させるサイトであれば順位は落ちないんですよ。もちろんユーザー満足度を測る一つの指標として直帰率を見るのは間違っていませんが、そういう考えなしにただ数字を見るだけでは全く意味がありません。

渡辺氏：

2014～16年頃はクリック率を上げたり滞在時間を伸ばしたりすれば順位を上げることができました。しかし2011～12年頃にGoogleが本格的に機械学習を投入してからは、そんな単純な話ではなくなったんですよね。例えば、彼氏彼女の誕生日プレゼントを探しているユーザーって、延々と検索し続けます。なぜなら欲しいものは答えではなくアイディアだから。一方で、料理のレシピを探しているユーザーだったら、いいレシピを見つけたらそのサイトをしばらく開きっぱなしにしますよね。このように検索クエリが違えばユーザー行動も変わるので、Googleも滞在時間やクリック率では単純に判断しなくなりました。

質問
「検索上位を追いかける意味がなくなってきているのではないか？」という質問がきていますが、お二人はどのようにお考えでしょうか？

渡辺氏：

私は「SEOの成果を順位で評価するのはやめません？」とお客さまに言っています。そもそもSEOのゴールは1位をとることではなく、オーガニックトラフィックから売上を上げることですよね。

Googleが検索ユーザーにリンクではなく直接答えを返すようになり、スマホだと顕著に検索1位が昔でいう6～7位の位置まで下がってしまっていますが、1位をとる以外にもビジネスゴールを達成する方法はたくさんあると思います。

辻氏：

私は約20万キーワードの順位を定期的に追っていますが、昔ほどチェックしなくなりましたね。数十サイトのSEOコンサルティングをおこなっていますが、ランキングデータを提出しているお客さまは1社だけ。順位だけ追いかけるのってある意味こちらとしては楽なんですが、それはお客さまのためにならないんですよね。

質問
インハウスSEO担当者になりたての20代の方にむけて、今何を学ぶべきかぜひアドバイスいただけないでしょうか。

渡辺氏：

10年後はさておきもっと短いスパンで考えると、今Googleのためにやっていること、例えば正規化なんかは今後Googleが勝手にやってくれると思うんですよ。だからもっとユーザー側を向いて考える比重を増やすべきだと思いますね。

辻氏：

「作業にしてはダメ」「検索エンジンを理解しながら業務に取り組むべき」ですね。検索エンジンはどういうシステムで、どういう意図をもって動いているのか、私はまさに渡辺さんから学びました。世界一複雑なシステムを理解してやろうとする姿勢が大事だと思います。

黎明期からSEOに携わってきた、SEO業界を代表する2人の話は、実に学びが多いものだ。元記事では、ここで紹介した以外にも2人のアドバイスがたくさん掲載されているので、ぜひとも読んでほしい。

Web担当者に役立つ最新情報

JavaScriptのせいでSEOに大失敗したサイトの事例
元グーグル社員がシェア （Pedro Dias on Twitter） 海外情報

サイトでJavaScriptを積極的に使うようにリニューアルしたことが原因で検索エンジンに正しくインデックスされなくなってしまったサイトの失敗事例を、元グーグル社員のペドロ・ディアス氏がツイッターに投稿した。

JavaScriptフレームワークを使ってブラウザ側でコンテンツをレンダリングするようにサイトを変更したところ、検索トラフィックが激減してしまったのだそうだ。

原因は、GooglebotがJavaScriptを正常にレンダリングできず、コンテンツを取得できなかったためと思われる（たとえば、サイト全体が、メインコンテンツのない真っ白のページばかりになるようなケース）。

教訓として得られるのは、JavaScript に依存してメインコンテンツを生成するサイトでは、事前の検証が必須だということだ。Googlebotがきちんとレンダリングできるかどうかは、URL検査ツールで確認できる（モバイルフレンドリーテストやリッチリザルトテストでも可能）。

Googlebotのレンダリングに支障が出ているようであれば、「サーバーサイド レンダリング（SSR）」「ダイナミック レンダリング」などの技術を検討するといいだろう。

ドメインやサブディレクトリを第三者に貸し出すSEO手法にグーグルが対策
忠告だけにとどまらず （Search Engine Roundtable） 海外情報

サブドメインやサブディレクトリを第三者に提供するサービスに関して、グーグルが注意を喚起したことを、前回このコーナーでお伝えした。

それから間もなくして、そうしたサービスにグーグルは対策を実行したようだ。いくつものサイトが検索トラフィックを大幅に減らしているらしい（ただし、メインサイトではなく貸し出されたサブドメインやサブディレクトリのサイトの方が影響を受けているとのこと）。

グーグルはこうした手法について、

ガイドラインには違反していない

と言っていたものの、同時に次のようにも言っていた。

規模が拡大すればそれ相応に扱う

今回の変動が、手動対策なのか、それともアルゴリズムによる評価下げなのかは不明だ。ただ1つわかるのは、この件に限らず、グーグル検索のすきを突くようなトリックは最後には必ず封じ込まれるということだ。

複数の構造化データを1つのページに盛り込んでもいいの？
大丈夫だけれど注意点あり （Google Devs Japan on Twitter） 国内情報

グーグルの開発者向けのツイッターアカウントが検索関連のTIPSを投稿したので紹介する。

たとえば、同じ1つのページに、次の構造化データを両方マークアップしたら、どうなるのだろうか？

• レシピの構造化データ
• 商品の構造化データ

検索結果ページでは、両方のリッチリザルトが同時に表示されることはない（どちらが表示されるかはクエリに依存するのだろうか？）。

なお、schema.orgにはそのページの主となる“エンティティ”を指定するmainEntityとmainEntityOfPageというタイプがある。グーグルはサポートしているので、複数の構造化データを1ページにマークアップする際には利用してもいいだろう（ただし、どのように利用されるかはグーグル次第）。

求人検索、リニューアル後の順位、外部陸データの差異など、8月のオフィスアワー
フォーラムのエキスパートも参加してシドニーからお届け （ウェブマスター オフィスアワー） 海外情報

8月のオフィスアワーが開催された。取り上げられた質問は次のとおりだ。

• 求人情報の構造化における雇用形態
• サイトリニューアル後の掲載順位
• 外部リンクデータの差異
• 検索エンジンに早く単語を学習させる方法
• 重複として扱われインデックスされないURL
• Googlebotのレンダリング
• 米国からのアクセスを遮断する方法
• コピーサイトによって順位が下がった
• 古いオフィスアワーの情報は信用できる？
• タイトルに意図しない文字列が追加されている
• 2019年上半期の思い出

今回は、金谷氏とあんな氏に加えてヘルプフォーラムのプロダクトエキスパートも参加している。豪シドニーでの特別イベントにあわせて開催されたためだ。グーグル社員だけではなくエキスパートたちからのアドバイスも参考になるだろう。

Search Console APIをグーグルが整理整頓
いくつかのタイプのサポート終了 （Official Google Webmaster Central Blog） 海外情報

Search Console APIで提供していたタイプのいくつかをサポート終了することをグーグルはアナウンスした。

• Search Analytics APIでは、searchAppearanceタイプとして次のものをサポートしなくなる。

  • Is Install
  • Is App Universal
  • Is Opened

• Sitemaps APIでは、送信されたサイトマップのインデックス状況のデータをIndexedフィールドで提供しなくなる。

Search Analytics APIの変更に関しては、App IndexingはすでにSearch Consoleで管理できなくなっているので問題ないだろう。サイトマップのデータが入手できなくなるのは、不便に感じるウェブ担当者がひょっとしたら出てくるかもしれない。

（元記事ではいつから変更が入るのか、すでに変更されているのかは明示されていない）

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

リッチリザルトとAMPに関する記事をピックアップ。

• CTRアップに期待、How-toリッチリザルトが日本のGoogle検索でも導入される

  ハウツーのコンテンツがあれば取り組んでみよう

  ★★★★★

  • SEOがんばってる人用（ふつうの人は気にしなくていい）
• 任意のJavaScriptをAMPで動かせる！amp-scriptが一般公開される

  パフォーマンスとセキュリティを妨げずに独自のJSを使用可

  ★★★☆☆

  • AMPがんばってる人用（ふつうの人は気にしなくていい）