相当遅ればせながら…Googleウェブマスター向け公式ブログでも紹介されておりましたので、私のブログでもサササッとご紹介したいと思います。Googleウェブマスター向け公式ブログに合わせてポイントだけ掻い摘んで触れておきます。

Google I/O 2018で触れた検索関連情報

もともと、Google I/O 2018はあらゆるGoogleのサービスと未来について開発者から発表される場ですので、検索サービス関連のセッションはあまり多くありません。その検索サービス関連のセッションの中で、私が気になったのは以下の点です。

JavaScript生成コンテンツのレンダリング方法

あれ…1つになっちゃいました(笑)。要は、レンダリング(≒Googleがページ構成を視覚的に理解すること)において、JavaScriptはその動的な特性から、なかなかGoogleに理解されにくいプログラミング言語でした。しかし、モバイルサイトにおいては多用されるケースも多く、Googleはそれもようやく理解できるようになったのですが、そのやり方はまだ充分とは言えません。各レンダリング(サーバー、ブラウザ、Googlebot)の組み合わせ次第で様々なレンダリング方法があります。その上で、今回新しくダイナミックレンダリングというやり方をGoogleが紹介してくれました。

これに関しましては、海外SEO情報ブログ「JSサイトのための第4のレンダリング構成としてダイナミックレンダリングをGoogleが発表」が非常に分かりやすいので、ご覧ください。

ちなみに、いずれGoogle側からも追って詳細説明してくれるそうです。

これらのセッションでは、モバイルフレンドリーテストツールのJavaScriptエラーレポートを発表し、ダイナミックレンダリングについて紹介し(これについては今後の投稿で詳しく取り上げる予定です)、CMSでIndexing APIやSearch Console APIを利用してユーザーに情報を提供する仕組みについて説明しました。

引用）Googleウェブマスター向け公式ブログ

その他

他には、ブログでも「インデックス登録時にレンダリングが行われるわけではないこと。レンダリングは遅れて行われる」ということや、「表示させたいコンテンツページは正しいステータスコードとmeta情報、canonicalが行われていること」、「リンクされるURLにはhref属性をつけること」が紹介されています。

1点難しそうな話だけ…

シングルページアプリルーティング向けのJavaScript History APIを採用するため、ハッシュベースのルーティング(「#」を含むURL)はサポートを終了する必要があります。

引用）Googleウェブマスター向け公式ブログ

こちらですが、シングルページアプリケーション(Single Page Application：SPA)と言いまして、単一のURLで構成されるWebページやアプリで、JavaScriptによってURLは変わらずに動的に画面遷移するものです。1つのページでコンテンツの切り替えを行うパターンのやつですね。つまり、SPA内でAからBというコンテンツ遷移をした場合でも、URLは変わらないままです。ですので、その上でBからブラウザバックする(ブラウザの「戻る」ボタンを押す)と、ユーザーの感覚的にはAの内容に戻るはずですが、実際はAでもBでも同一のURLなので、Aではなく、それよりも前に見ていたURLページまで戻ってしまいます。

そうならないようにブラウザバックしてもBからAに戻れるようにするのが「ルーティング」でして、Aのページ内容の場合はURL末尾に#aaa、Bの場合は末尾に#bbb等と付くようにし、実質的に別URLとして管理する方法が「ハッシュベースのルーティング」です。

一方「JavaScript History API」は、URLの見た目上は変わらないものの、裏側でURLが切り替わるようなイメージです。Googleは今後この「JavaScript History API」を採用するため、SPAにおけるハッシュベースのルーティングは機能しなくなるということです。
ですので、SPAの担当者でルーティングに「#」を活用している運用者はHistory APIに切り替えていく必要があります。

以上

私が気になったところは以上です。
個人的には検索よりも気になったものが多かったので、そっちでお腹いっぱいになっちゃってました(笑)。

そういえば、一部日本でもGoogleアシスタントで飲食店の予約が出来るようになりましたし、これからが楽しみですね。

Google I/O 2018の追記

Search for articles

Archives