Progressive Web Appsは検索から開く個別ページに直接URLを持たせる

Progressive Web Appsの個別ページは、画面内のリンクをたどったときだけでなく、そのURLを直接開いたときにも内容を返します。検索結果、ブックマーク、メールのリンクから来る人は、最初にアプリのトップページを開くとは限りません。個別ページを開けなければ、見たい商品や記事へ着く前に戻されます。

Googleは、検索に載せるウェブアプリでは、サーバー側でHTMLを返す方法、または最初のURLでサーバー側の内容を返して以後の遷移をJavaScriptで扱う方法を案内しています。どちらも、最初のリクエストに内容を含め、個別URLを独立して開けることが要点です。JavaScriptで画面を切り替えられることと、検索や外部リンクから個別ページを開けることは別です。

URLは画面の状態を表すためだけに使うものではありません。誰かへ送るlink、ブラウザの履歴、検索結果、広告のlink先は、すべてURLから始まります。商品詳細を開いているのにURLが一覧のままなら、利用者は戻る操作や共有したlinkで同じ内容へ戻れません。画面を素早く切り替える設計と、どの内容をどのURLで開くかを決める設計を分けます。

個別URLを増やす前に、公開する単位を決めます。商品、記事、店舗案内のように、検索から直接読まれる理由がある内容には固有のURLを持たせます。絞り込みの途中状態や一時的な画面まで無数のURLにする必要はありません。どのURLで何を伝え、どのURLを検索から開いてほしいかを決めれば、canonical URLや内部linkの確認も行いやすくなります。

画面遷移とURLの役割を混同しない

たとえば、商品一覧から商品詳細へ進むとき、画面だけを書き換える実装を考えます。一覧から操作する人には商品詳細が見えても、/product/25/を直接開いた人へトップページだけを返せば、その人は目的の商品へ着けません。検索も、そのURLに商品詳細があるとは確認できません。

#product/25/のようにフラグメント識別子だけで個別ページを表す設計は、URLとして扱いにくくなります。個別の内容には、/product/25/のようなフラグメントを含まないURLを割り当てます。クライアント側の描画やハイブリッド描画を使う場合は、History APIでブラウザの戻る操作と進む操作にも対応します。

History APIを使う場合も、URLだけを替えて中身が追いつかなければ意味がありません。商品Aから商品Bへ進んだとき、title、本文、画像、link先が商品Bへ替わり、戻る操作で商品Aへ戻ることを確認します。画面では商品Bに見えるのに、URLを直接開くと商品Aやtop pageが出るなら、外部から来た人は同じ画面へ着けません。操作中の画面と直接開いた画面を並べて確認します。

site内のlinkも、JavaScriptのclickだけに頼りません。利用者が新しいtabで開く、URLをコピーする、JavaScriptの読み込みに時間がかかるといった場面でも、個別ページへ進めるlinkが必要です。見た目がbuttonでも、どの内容へ進むのかが分からなければ、検索と利用者のどちらにとっても確認しにくくなります。画面の操作を作ることと、到達先のURLを用意することを別に扱います。

最初の取得で何が読めるかを確かめる

説明用の仮例として、商品情報をJavaScriptで読み込んでから画面へ出すサイトを考えます。通信が遅い、JavaScriptが実行されない、必要なファイルが取得できないという条件では、最初の応答に商品名も説明もないかもしれません。利用者も検索も、画面遷移のあとだけに出る内容を必ず読めるとは限りません。

サーバー側の描画は、URLを開いたときにサーバーがHTMLを作って返す方法です。ハイブリッド描画は、最初のURLではサーバー側で内容を返し、その後の画面遷移をJavaScriptで扱う方法です。どちらを選ぶかは制作の条件で決めても、個別URLを開いたときに何が返るかは確認します。

最初の応答にtitleだけがあり、本文や商品の条件がJavaScriptの後にしか出ない場合、表示が終わるまでの条件によって内容が読めないことがあります。画面上で最終的に見えることだけでなく、最初に返るHTMLと、JavaScriptを実行した後の表示を比べます。サーバー側の描画を選ぶ理由は技術の流行ではなく、個別URLを開いた人へ必要な内容を早く渡すためです。

ハイブリッド描画では、最初の個別URLを開く経路と、site内を移動する経路の両方を試します。最初のURLでは内容が出るのに、一覧から個別pageへ移動するとtitleやcanonical URLが前のpageのまま残ることがあります。反対に、site内の遷移ができても、再読み込みでtop pageへ戻ることがあります。二つの経路は同じように見えても、確認すべき動きが違います。

クライアント側の描画だけで作る場合も、Search ConsoleのFetch as Googleで個別URLを取得し、Googleの検索用クローラが本文を描画できるかを確認します。確認する対象はトップページではなく、検索から直接来てほしい商品、記事、案内ページです。

公開前はURLを単独で開いて確認する

公開前に、次の順で確認します。

1. 個別ページのURLを新しいブラウザのウィンドウへ貼り付け、目的の内容が出るか確認する。
2. ブラウザの戻る操作と進む操作を使い、URLと表示内容がずれないか確認する。
3. サーバーが返すHTMLと、JavaScriptを実行したあとの表示で、主要な本文が消えていないか比べる。
4. Fetch as Googleで個別URLを取得し、必要な本文と資源が見えているか確認する。

公開直前に、開発用のrobots.txtをそのまま残すと、個別URLが正しくてもGooglebotは取得できません。canonical URLも、公開する実URLを指すように確認します。機能を増やす作業と、URL、描画方法、robots.txtを直す作業を同時に進めるほど、原因は追いにくくなります。

Fetch as Googleで確認するときは、取得結果の見た目だけでなく、対象URLと必要な資源を見ます。商品pageを確認するなら、商品名、説明、選ぶための条件、画像やstyleが読み込めているかを確認します。top pageが正しく取れていても、個別pageのJavaScriptや画像が取得できなければ、個別内容を確認したことにはなりません。エラーが出た場合は、URL、取得時刻、読めなかった資源を残し、routing、robots.txt、fileの置き場所を分けて調べます。

制作を外部へ依頼する場合は、「PWAを検索対応にする」とだけ伝えません。直接開けるべきURL、最初に返す本文、canonical URL、確認する代表page、Fetch as Googleを確認する人を決めます。アプリの画面遷移を作る人と、商品や記事の内容を確認する人が別なら、内容の正しさは事業側が確認します。技術を任せても、どのpageを公開の入口にするかまで任せるとは限りません。

最初に一つの個別pageで確認した方法を、同じ種類のpageへ広げます。商品pageのroutingを直したなら、別の商品でも直接開けるかを確認します。記事pageの本文が最初の応答にないなら、同じtemplateの記事を確認します。個別入力の問題か共通のroutingやtemplateの問題かを分ければ、必要な範囲を直しながら検査を進められます。

最初の一手は、検索で読まれたいページを一つ選び、そのURLをサイト外から直接開くことです。そこに目的の本文がなければ、画面遷移の見た目より先にURLと応答を直します。