インデックス可能なプログレッシブ ウェブアプリの構築方法 | Google ウェブマスター向け公式ブログ

プログレッシブ ウェブアプリ (PWA) は、最新技術を活用することで、モバイルサイトとネイティブ アプリの長所を兼ね備える、現在ウェブの世界で最も注目されている新しい概念の１つです。しかし実際に大きな効果を上げるためには、検索エンジンがインデックスすることができ、また他のページからリンクを張れることが重要です。
この記事で紹介する推奨事項は、静的なウェブサイトにおいても通用する、インデックスを登録するためのベストプラクティスです。以下のチェックリストが、より優れたウェブアプリの構築に役立てば幸いです。
コンテンツをクロール可能にするかつてウェブサイトの世界では、HTML をサーバーで生成してレンダリングするのが当たり前とされてきました。コンテンツを直接リンク可能にするには、それが一番簡単な方法です。一方ウェブアプリの世界では、クライアント側でのレンダリングが一般化しているため、ユーザーがページを移動しても再読み込みなしで動的にコンテンツが更新されます。
最新の手法は、これらの良いところを兼ね備えた、ハイブリッドなレンダリングです。ユーザーが直接 URL に移動したときはサーバー側でレンダリングし、最初のページ読み込みの後の移動や非同期リクエストはクライアント側でレンダリングします。
実際に違いを見ていただけるよう 2 つのサンプル PWA を用意しました。1 つはサーバー側でのみレンダリングを行うもの、もう 1 つは両方の手法を組み合わせたハイブリッドな PWA です。
サーバー側とクライアント側のレンダリング技術について詳しく知りたい場合は、こちらやこちらのウェブ記事をご覧ください。

クリーン URL を提供するフラグメント識別子（#user/24601/ や #!user/24601/）は、新しいコンテンツをサーバーから AJAX で受信し、ブラウザでのページ再読み込みを回避したい場合に有用でした。このような設計をクライアント側レンダリングと呼びます。
しかしながら、フラグメント識別子の構文と互換性のないウェブツール、フレームワーク、プロトコルもあります（たとえば Facebook の Open Graph プロトコル）。
History API を使用すると、フラグメント識別子なしで URL を更新でき、その間に非同期でリソースを取得できます。ページの再読み込みも回避できる、両方の良いところを兼ね備えた手法です。AJAX クロール スキーム（#! / エスケープ フラグメント URL で適用）はかつては有用でしたが、現在はおすすめできません。
History API がどのように機能するかについては、ハイブリッド PWA とクライアント側 PWA のサンプルでご覧いただけます。

正規 URL を指定するドメインが同じかどうかに関係なく、複数の URL から同じコンテンツを入手できる場合、インデックス登録の混乱を避ける一番良い方法は、いずれかのページを正規 URL として指定することです。それ以外のすべての重複したページは、正規のページを参照するようにします。

どのデバイスにも最適なデザインにするユーザーがウェブサイトへのアクセスにどのタイプの端末を利用しているかに関係なく、すべてのユーザーに可能な限り最適なエクスペリエンスを提供することが重要です。

サイトをレスポンシブ デザインにすることをおすすめします。つまり、フォント、マージン、パディング、ボタンなどのサイトの基本的なデザインを、画面の解像度や端末のビューポートに合わせて動的に調整する必要があるのです。

パソコンやタブレットのユーザーに対して、小さな画像を拡大して表示するのは最適なエクスペリエンスとは言えません。反対に、モバイル端末に高解像度の画像をダウンロードするのは時間がかかりますし、スクロール時の負荷も大きくなります。
PWA のユーザー エクスペリエンスについて詳しくはこちらをご覧ください。

反復型開発を行うウェブアプリに機能を追加する場合、最も安全な方法の 1 つが反復的な変更です。一度に追加する機能を 1 つだけにすれば、変更による影響を 1 つずつ確認できます。
一方で、多くのデベロッパーはプログレッシブ ウェブアプリの開発を「モバイルサイトを徹底的に見直す機会」として好意的に捉えているようです。新しいウェブアプリを隔離された環境で開発し、完成したら既存のモバイルサイトからそれに移行しようというわけです。
反復型開発を行う場合、変更内容を複数の部分に分解することになります。たとえば、サーバー側レンダリングからハイブリッド レンダリングに移行したい場合は、1 回の反復でその点だけを変更します。他の機能と組み合わせて同時に変更することはしません。
どの手法にも長所と短所があります。反復型開発の場合は移行を継続的に行うため、検索インデックスへの登録の煩雑さを軽減できるというメリットがあります。一方、完成までに時間がかかり、ゼロから開発を始める場合に比べると徹底的な革新にはなりにくい傾向にあります。
いずれにしても、最も注意を払うべきは正規 URL と robots.txt の設定です。

プログレッシブ エンハンスメントを利用するブラウザの機能は、可能な限り使用前に検出しておくことが重要です。ブラウザが特定の機能に対応しているかどうかを都度テストするのではなく、事前に機能検出を実施することをおすすめします。
過去に一般的だった手法でおすすめできないものの 1 つが、ユーザーがどのブラウザを使用しているかテストしてから機能を有効または無効にする方法です。ブラウザの機能は日々進化していますので、このような方法を採らないよう強くおすすめします。
Service Worker は比較的新しい技術です。こうした新しい技術には段階的に対応することが重要です。これは、プログレッシブ エンハンスメントを利用する場合に適した事例です。

Search Console でテストするGoogle 検索のクローラが、サイトをどのように見ているかを理解することが重要です。Search Console の [クロール] > [Fetch as Google] 機能を使用すると、サイト内の個別の URL を取得して、Google 検索のクローラがサイトをどのように見ているかを把握できます。JavaScript を処理してページをレンダリングするか、未加工の HTML レスポンスのみを表示するかを選択できます。
Google Search Console では、さまざまな方法でページ上のコンテンツを分析できます。たとえば、構造化データ、リッチカード、サイトリンク、Accelerated Mobile Pages が存在するかどうかを検出することもできます。

Schema.org 構造化データでアノテーションを追加するSchema.org 構造化データは、サイト内のページの最も重要な部分を、機械で処理可能なデータとして要約できる、柔軟なメタデータです。たとえば、「NewsArticle」のように単純にページ全体の内容を示すこともできますし、バンドのツアーに関する具体的な情報として、場所、バンド名、会場、チケット販売元などを指定することもできます。また、料理の材料や手順を要約することも可能です。
このメタデータをウェブアプリのすべてのページで使用する必要はないかもしれませんが、必要だと思われる場合は積極的に使用することをおすすめします。Google は、ページがレンダリングされた後にそれを抽出します。
「NewsArticle」、「Recipe」、「Product」など、さまざまなデータタイプが用意されています。どのようなデータタイプがあるかはこちらで確認できます。

Open Graph や Twitter カードでアノテーションを追加するSchema.org メタデータに加え、Facebook の Open Graph プロトコルや Twitter のリッチカードに対応することも検討してください。
これらのメタデータ形式を使用すると、ページのコンテンツをユーザーが簡単にソーシャル ネットワークで共有できるようになります。
既存のサイトやウェブアプリでこれらのメタデータ形式を使用している場合は、プログレッシブ ウェブアプリにも追加して、ユーザーが簡単に口コミを広げられるようにしておくことが重要です。

複数のブラウザでテストするユーザーの立場から考えると、ウェブサイトがどのブラウザでも同じように動作することが重要です。iPhone でも Android でも、画面サイズがほぼ同じであれば、モバイルサイトには同じように動作することが求められます。
世界中で多様なブラウザが利用されており、まるでウェブが分断されているようにも感じられますが、ウェブがこれほど革新的なプラットフォームになった理由の 1 つがこのような多様性と競争でもあるのです。ありがたいことにウェブ標準がかつてないほど成熟し、最新のツールを利用することで、ブラウザ間で互換性のある多機能なウェブサイトを効率的に開発できるようになっています。

ページ読み込みのパフォーマンスを測定するウェブサイトは、読み込み速度が速いほどユーザー エクスペリエンスが高くなります。ウェブ開発において、ページの読み込み速度の最適化を重視することはすでに常識となっていますが、サイトを新しいバージョンに更新したときの最適化についてはあまり重視されていない傾向にあります。
プログレッシブ ウェブアプリの開発においては、サイトを公開する前にページ読み込み速度を測定して最適化して、常に最良のパフォーマンスを得られるようにすることをおすすめします。

このチェックリストが、インデックス可能性を念頭にプログレッシブ ウェブアプリを開発するためのガイドとしてお役に立つことを願っています。
プログレッシブ ウェブアプリの実際の開発にあたっては、インデックス登録方法を示すサンプルで、サーバー側、クライアント側、ハイブリッドの 3 種類のレンダリングについて理解してください。ご不明な点などありましたら、いつものようにウェブマスター フォーラムで質問してください。

Original version: Official Google Webmaster Central Blog: Building Indexable Progressive Web Apps