PWAのSEO

TL;DR — PWA（プログレッシブウェブアプリ）は、通常のウェブサイトに2つの追加要素を組み合わせたものです。マニフェスト（ホーム画面にインストールできるようにする）と、サービスワーカー（オフラインでも動作できるようにする）です。Googleにとっては依然として単なるウェブサイトであり、PWAにしてもランキングは上がりません。実際に害を及ぼす可能性があるのは、設定が不適切なサービスワーカーが、最新のページではなく古いキャッシュ済みページをGoogleに表示してしまうことです。

PWAの実際の正体

プログレッシブウェブアプリは、ネイティブアプリのように感じられるように拡張されたウェブサイトです。PWAを構成する要素は2つあります。

• ウェブアプリマニフェスト（manifest.json）— アプリの名前、アイコン、色をブラウザに伝える小さなファイルで、訪問者が「ホーム画面に追加」をタップすると、アプリ風のアイコンとスプラッシュ画面が表示されます。
• サービスワーカー — バックグラウンドで動作し、ファイルをキャッシュして、再訪問時の読み込みを高速化し、オフラインでも動作できるようにするJavaScriptの一部です。

以上です。PWAは、その内部ではほとんどの場合、通常のJavaScriptウェブサイト（React、Vue、Angularなど）です。アプリの衣装を着た普通のサイトなのです。

打ち破るべき大きな誤解

最もよくある誤解は、**「サイトをPWAにすれば、ランキングが上がる」というものです。Googleはこれが事実ではないと明確に述べています。Googleのジョン・ミューラーは次のように直接述べています。PWAは「現在、Google検索では何の利点もありません。」 ランキングシステムに「PWAボーナス」は存在しません。

マニフェストファイルもSEOには役立ちません。これはアプリのインストール方法（アイコン、名前、スプラッシュ画面）を制御するものであり、Googleがランキングを決定する際に読み取るものはどれも含まれていません。

実際に害を及ぼす可能性がある唯一のもの

注意が必要なのはサービスワーカーです。ページのキャッシュ（保存）されたコピーを提供できるため、設定が不適切だと、実際の最新ページの代わりに、古い、または空白の「オフラインです」バージョンのページをGoogleに表示してしまう可能性があります。これが、PWAが公開後にトラフィックを失う理由です。「PWAになったから」ではなく、キャッシュの向きが間違っていたからです。

実際にすべきこと

• 検索エンジンに実際のページコンテンツが読み込まれるようにしてください。後からJavaScriptで埋め込まれる空のシェルだけを表示しないようにします。
• サービスワーカーを設定して、HTMLは常にネットワークから取得し、画像やスタイルシートなどの高速化のためだけにキャッシュにフォールバックするようにします。
• 基本を正しく保ちます。実際の一意なURL、すべてのページに適切なタイトルとメタディスクリプション、高速で信頼性の高いエクスペリエンス。

PWAであることはユーザーにとって素晴らしいことです。インストール可能で、高速で、オフラインにも対応しています。ただし、Googleでの順位が上がることを期待してはいけません。また、サービスワーカーがGoogleに間違ったページを提供しないようにしてください。詳細タブには、仕組み、キャッシュ戦略、引用があります。

TL;DR — PWAは、ほぼ常にJS/SPAサイトであるものの上にマニフェストとサービスワーカーを重ねたものです。したがって、JavaScript/SPA SEOのレンダリングルールは変更なしで適用され、さらにPWA固有の2つの懸念事項があります。GoogleはPWAにランキング上の利点を与えていません（ミューラー）。manifest.jsonはインストール可能性を管理するものであり、インデックス作成を管理するものではなく、ランキングシステムがそれを読み取るという証拠はありません。サービスワーカーが本当のリスクです。Googleのレンダラーはインデックス作成時にサービスワーカーを実行しないため、キャッシュファーストのHTML戦略では、古いまたはオフラインのシェルがインデックスされる可能性があります。HTMLにはネットワークファースト、静的アセットにはキャッシュファーストを使用してください。HTTPSはサービスワーカーの必須要件であり*、*また別途、わずかなランキングシグナルでもあります。これらを「PWAの方がランキングが上がる」と結び付けてはいけません。Core Web Vitalsだけが正当な重複であり、それはPWAというラベルではなくエンジニアリングの問題です。

PWAはまずウェブサイトである

最も有用な捉え方は、プログレッシブウェブアプリは、2つのものが追加された通常のウェブサイトであるということです。Google自身の定義によると、PWAは*「最新のAPIで構築および拡張されたウェブアプリであり、拡張された機能を提供しながら、単一のコードベースで任意のデバイスの任意のウェブユーザーにリーチします。」* Googleが挙げる3つの柱は、Capable、Reliable、Installableです。この3つのどれも「ランキング可能」ではないことに注意してください。

アーキテクチャ的には、そのコードベースはほぼ常にシングルページアプリケーションパターンを実行するJavaScriptフレームワークです。つまり、JS/SPAのインデックス可能性を左右するすべてが、変更なしでPWAのインデックス可能性を左右するということです。アドレス可能性には実際の<a href>リンクとHistory-APIルーティング（ハッシュフラグメントではなく）が必要です。コンテンツの可用性にはサーバーサイドレンダリングまたはプリレンダリングが必要です。レンダリングされたDOMには、ルートごとの正規化、タイトル、メタが必要です。JavaScript SEOとSPA SEOの資料を読んだことがあれば、PWA SEOの90%はすでにご存知でしょう。特にアプリシェルの失敗モードは、Googleが明示的に文書化しているものです：“Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” (翻訳) 「一部のJavaScriptサイトでは、初期HTMLに実際のコンテンツが含まれておらず、GoogleがJavaScriptを実行して初めて実際のページコンテンツを確認できるアプリシェルモデルを使用する場合があります。」 SSRやプリレンダリングなしで空のシェルを配信するPWAは、その問題を直接引き継ぎます。

したがって、PWA固有の SEO記事の正直な範囲は小さいものです：マニフェストとサービスワーカーです。それ以外はすべて、マニフェストをまとったJS/SPA SEOです。

中核となる神話：「PWA化」はランキングを向上させない

これが見出しです。Googleはこれについて異常なほど率直です。John Mueller氏は、Search Centralのオフィスアワーセッションで、PWAは*“currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,”* (翻訳) 「現在、Google検索において何らかの利点はなく、私の知る限り、これを変更する計画はありません。」と述べ、PWAへの変換が役立つかと尋ねられた際には、“By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (翻訳) 「デフォルトでは、PWAにするとランキングが良くなると言うのは、そうではないと思います。」と述べました。

また、彼は「競合他社がPWAに移行してランキングが急上昇した」というよくある反論も先取りしました。彼の答えは次のとおりです：“So just the fact that one of your competitors has moved from one framework to another, and has seen an improvement in search, that framework change from my point of view wouldn’t be responsible for that.” (翻訳) 「つまり、競合他社の1つが別のフレームワークに移行して検索で改善が見られたという事実だけでは、そのフレームワークの変更がその原因ではないと私の見解では考えられます。」そしてその理由について：“These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (翻訳) 「これらは本質的にウェブサイトを作るさまざまな方法であり…ほとんどの場合、これらを通常のHTMLページとして見ています。」

PWAの再起動がランキングの向上と相関する場合、それは大規模な再構築に伴う交絡因子によるものです：近代化された内部リンク、リフレッシュされ拡張されたコンテンツ、真の速度改善、そして通常は再起動に伴うマーケティング活動です。そのどれもPWAというラベルを必要としません。10〜15年かけて有機的に成長したサイトを再構築する場合、一度に多くのことを変更します。その結果を「PWA」に帰属させるのは相関エラーです。

Manifest.json：インストール可能性 ≠ インデックス可能性

manifest.jsonファイルは、アプリをインストール可能にするために存在します。そのフィールド（name、short_name、icons、start_url、display、theme_color）は、インストールプロンプト、ホーム画面のアイコン、スプラッシュ画面、およびアプリがスタンドアロンで開くかブラウザタブで開くかを制御します。それがすべての役割です。

Googleのランキングまたはインデックスシステムがマニフェストをシグナルとして読み取るという証拠はありません。最も明確な外部確認は、Google自身のPWAチェックリストです。そこでは*“Is installable”* (翻訳) 「インストール可能である」と*“Discoverable in search”* (翻訳) 「検索で発見可能である」が2つの別々の独立したチェックリストカテゴリとしてリストされており、発見可能性は通常のSEOの基本として定義されています：“Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (翻訳) 「一意のURL、説明的なタイトル、メタディスクリプション、構造化データを通じて検索エンジンの発見を有効にします。」 インストール可能性（マニフェスト駆動）と発見可能性（クラシックSEO）は、一方が他方を支えるのではなく、並行する関心事として扱われます。つまり、有効なマニフェストを維持することは、アプリをインストール可能にするために重要ですが、SEOとして分類しないでください。

サービスワーカー：PWA固有の唯一の実質的なSEOリスク

ここに最も重要な事実があり、これはPWA固有のものです。Googleのレンダリングサービスは、インデックス作成のためにページをレンダリングする際に、あなたのサービスワーカーを実行しません。 その理由は、Martin Splitt氏の言葉を借りれば、「SERPからあなたのページをクリックする人は初めての訪問者であると想定しなければならないため、サービスワーカーを実行してもあまり効果がないのが通常です。」 サービスワーカーの要点は、キャッシュからの再訪アクセスを高速化することです。そしてGooglebotは、設計上、常に初めての訪問者として扱われるため、高速化する対象がありません。Splitt氏は再びこう述べています：「検索結果からあなたのページにアクセスするユーザーは、以前にそこに訪れたことがない可能性があるため、私たちはそれをサポートしていません。」 Mueller氏は、これが一時的な状態ではなく安定した方針であることを確認しています：「これが変わるとは思っていません。インデックス作成のためにこのようにバックグラウンドでサービスワーカーを実行するのは計算コストが高いからです。」

では、なぜそれがリスクなのでしょうか？ それは、あなたのサービスワーカーが実際のユーザーのブラウザでは実行されるからです。そして、もしHTMLをキャッシュファーストで配信するように指示した場合（保存されたコピーを返し、ネットワークをスキップする）、実際の再訪ユーザーは高速なキャッシュページを見ることになりますが、それはGooglebotが決して実行しない戦略です。危険なのは逆のケースです。つまり、何らかのエラーやフォールバック条件の下で、古いドキュメントやオフラインのフォールバックページを返すキャッシュパターンです。レンダリングはステートレスであり、WRSはすべてのフェッチを新しいものとして扱うため、キャッシュ戦略の設定ミスは、PWAがライブコンテンツの代わりに古いまたは空のオフラインシェルをGooglebotにインデックスさせる原因となります。

キャッシュ戦略の経験則：

• HTMLドキュメント → ネットワークファースト（または短いTTLでのstale-while-revalidate）。ライブページを取得します。キャッシュはオフラインのフォールバックとしてのみ使用し、そのフォールバックが新しいクロールでインデックスされることが決してないようにしてください。
• 静的アセット（JS、CSS、画像、フォント）→ キャッシュファーストで問題なく、望ましいです。これらはリクエストごとに変化せず、インデックス可能なドキュメントではありません。

監査方法： Googlebotが見るものと、再訪ユーザーのブラウザがキャッシュから配信するものを比較します。Search ConsoleのURL Inspection（ライブテスト）を使用して、Googleが実際に取得するレンダリングされたHTMLを確認し、ライブページと照合します。それらが異なる場合、サービスワーカーまたはSSRの設定が最初の容疑者です。また、ハイブリッド設定でのレンダリングタイムアウトに注意してください。Hamlet Batista氏がダイナミックレンダリングの時代に指摘したように、「レンダリングサービスは、ページの読み込みが完了するのを永遠に待つことはありません。」 （その特定の記事はダイナミックレンダリングに関するもので、Googleは現在SSRを推奨してこれを推奨していません。タイムアウトの原則を引用し、パターン自体は引用しないでください。）

HTTPS：サービスワーカーの要件であり、別途小さなランキングシグナル

PWAのSEOに関する投稿では、「PWAにはHTTPSが必要で、HTTPSはランキングを向上させる。したがって、PWAはSEOにより適している」と示唆するものがあります。これは、2つの真実の事実が誤って結び付けられたものです。

Fact one: service workers only run in a secure context. Per MDN: “Service workers are only available in secure contexts: this means that their document is served over HTTPS, although browsers also treat http://localhost as a secure context, to facilitate local development.” That’s a browser platform rule, not an SEO tactic — no HTTPS, no service worker, full stop.

事実2: HTTPSはGoogleの実際のランキングシグナルですが、ごくわずかなものです。Google自身の2014年の発表: “we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (翻訳) 「HTTPSをランキングシグナルとして使い始めています。今のところ、これは非常に軽量なシグナルに過ぎません。全世界のクエリの1%未満に影響し、高品質なコンテンツなどの他のシグナルよりも重みが小さいものです。」

要点: どのHTTPSサイトも同じ小さなシグナルを得ます。PWAかどうかは関係ありません。PWAがHTTPSに対して追加のSEOクレジットを得るわけではありません。ただ、HTTPSなしでは機能できないだけです。HTTPSをPWAのSEOメリットとして売り込まないでください。

Core Web Vitals: 唯一の正当な重複部分

「優れたPWA」と「優れたSEO」が本当に交わる場所があるとすれば、それはパフォーマンスです。GoogleのPWAガイダンスは信頼性を最優先にしています — “A reliable Progressive Web App feels fast and dependable regardless of the network” (翻訳) 「信頼性の高いプログレッシブウェブアプリは、ネットワークに関係なく高速で信頼できると感じられます」— そしてCore Web Vitalsは確認された（控えめではありますが）ランキング要素です。適切に設計されたPWAが高速に読み込まれ、応答性を維持するなら、Vitalsで良いスコアを出す傾向があります。

しかし、因果関係を注意深く読んでください: それはエンジニアリングであって、PWAらしさではありません。 肥大化したPWA — 巨大なJSバンドル、レンダリングをブロックするハイドレーション、過剰に熱心なサービスワーカー — は、プレーンなサーバーサイドレンダリングのページよりも簡単に悪いCore Web Vitalsを記録します。Vitalsの勝利は、パフォーマンスの作業を適切に行うことから生まれます。これはマニフェストの有無にかかわらず実行できます。PWAであることは、優れたVitalsを保証するものでも、その近道を与えるものでもありません。

アプリのような機能はUXであり、ランキング要素ではない

ホーム画面への追加、オフラインモード、プッシュ通知、アプリのようなナビゲーション — これらはすべて本物で価値のあるPWAの利点であり、すべてエンゲージメント/リテンション機能であり、インデックス作成やランキングへの入力ではありません。GoogleのPWAチェックリストは、「インストール可能」と「検索で発見可能」を別々のバケットに置くことで、その区別を明確にしています。

「インストール可能」を単一の普遍的な機能として扱わないでください。ブラウザやOSによって異なります。これは、それがSEOシグナルになり得ないもう一つの理由です（Googleには報酬を与える一貫したクロスブラウザの動作がありません）。PWAが独自のカスタムインストールUIを表示できるようにするbeforeinstallpromptイベントは、Chromiumのみのメカニズムです。MDNのPWAインストール可能性ガイドによると、“not supported on iOS.” (翻訳) 「iOSではサポートされていません。」iOS Safariでは、インストールは手動の共有 → ホーム画面に追加フロー（iOS 16.4+のChrome、Edge、Firefox、Orionに拡張されており、これらはすべてiOSでAppleの必須WebKitエンジンを使用しているため、同じ制限を共有します）でのみ行われ、自動プロンプトではありません。そのどれもSEOの状況を変えるものではありません。つまり、「私のPWAがインストール可能かどうか」は、訪問者がどのブラウザとOSを使用しているかに依存しないイエス/ノーの事実ではないということです。

Twitter Liteは、誰もが「PWAがSEOに役立つ」ことの証明として挙げるケーススタディです。そして、その文書化された結果は本物です（ページあたりのセッション数が65%増加、送信ツイート数が75%増加、直帰率が20%減少）— しかし、そのすべてはエンゲージメント指標です。Google自身のケーススタディでは、SEO、オーガニック検索、ランキングについてはまったく言及されていません。素晴らしい結果ですが、間違った列です。

EコマースPWAストアフロント: 簡単な注意点

PWAストアフロントには、言及する価値のあるいくつかの難点があります。SPAのリスクを悪化させるからです。クライアントサイドルーティングとファセットナビゲーションを組み合わせると、すべて同じシェルに解決されるクロール可能に見えるURL、またはパラメータURLの爆発を生成する可能性があります。カートとチェックアウトの状態はクライアントサイドに存在し、インデックス可能な製品コンテンツをゲートしてはなりません。また、各製品ページは独立して実際の一意のHTMLを返す必要があります。アプリシェルの罠は、ページが最も多い場所で最もコストがかかります。修正はEコマースとファセットナビゲーションSEOと同じです。PWAレイヤーはそれらを変更せず、SSR/プリレンダリングの規律をより重要にするだけです。

BingとPWA

一言で言えば、BingはPWA固有のランキングやインデックスに関するガイダンスを一切公開していません。Bingのウェブマスター向けガイドラインはPWAに依存しないもの（一般的なクロール可能性、サイトマップ、robots.txt、IndexNow）であり、Microsoftの広範なPWAドキュメントはすべてEdgeのインストールプロンプト、PWABuilder、Microsoft Storeのパッケージングに関するものです。つまり、配布とインストールという、ウェブ検索インデックスとは別のトラックです。したがって、Bingについては、通常のJSレンダリングのクロール可能性ガイダンスをデフォルトにしてください。PWAに特有の例外はありません。

結論

PWA SEOは、JavaScript/SPA SEOに、正確に2つの追加事項を加えたものです。マニフェストをSEO入力として無視すること（インストール可能性のため）、そしてサービスワーカーがGooglebotを古いキャッシュやオフラインキャッシュに閉じ込めないように設定することです。これらを正しく行えば、PWAは他のよく構築されたサイトとまったく同じようにインデックスされます。ボーナスもペナルティもなく、同じルールが適用されるだけです。

AIまとめ

Advancedバージョンの簡潔な見解:

• PWAはまずウェブサイトです。 これは、ほぼ常にJS/SPAサイトであるものに重ねられたmanifest.json（インストール可能性）+ サービスワーカー（オフライン/キャッシュ）です。JavaScript/SPA SEOのルールはすべて変更なしで適用されます。
• ランキング上の利点はありません。 GoogleのJohn Mueller氏：PWAは*“currently don’t have any advantage in Google Search.”* (翻訳) 「現在、Google検索では何の利点もありません。」 「PWA化」してもランキングは向上しません。
• Manifest.jsonはSEOに関係ありません。 インストールプロンプト、アイコン、start_url、displayを制御しますが、ランキングシステムがこれを読み取るという証拠はありません。GoogleのPWAチェックリストでは、「インストール可能」と「検索で発見可能」を別々のカテゴリとして挙げています。
• 唯一の実際のリスクはサービスワーカーです。 Googleのレンダラーはインデックス時にサービスワーカーを実行しないため（すべてのクロールを初回訪問として扱います）、キャッシュファーストのHTML戦略では、古いまたはオフラインのシェルがインデックスされる可能性があります。HTMLにはネットワークファースト、静的アセットにはキャッシュファーストを使用してください。
• HTTPS ≠ PWA SEOの特典。 これはサービスワーカーにとっての必須要件（セキュアコンテキスト）であり、また別途、すべてのHTTPSサイトが得る「非常に軽量な」ランキングシグナルです。この2つを関連付けないでください。
• Core Web Vitalsは唯一の正当な重複です — そしてそれはPWAというラベルではなく、パフォーマンスエンジニアリングです。肥大化したPWAはより悪いスコアになる可能性があります。
• アプリのような機能（インストール、オフライン、プッシュ）はエンゲージメントであり、ランキングではありません。 Twitter Liteの有名な成果はエンゲージメント指標です。そのケーススタディではSEOについては一切言及されていません。インストール可能性自体もブラウザ/OSによって異なります（iOS Safariにはbeforeinstallpromptがなく、手動での「ホーム画面に追加」のみ）— これがランキングシグナルになり得ないもう一つの理由です。
• BingにはPWA固有のガイダンスはありません。通常のJSクロール可能性をデフォルトにしてください。

公式ドキュメント

PWA、レンダリング、およびこの記事が基づく事実に関する一次資料。

Google / web.dev

• プログレッシブウェブアプリとは？ — Googleの定義と3つの柱（Capable、Reliable、Installable）。
• 優れたプログレッシブウェブアプリの条件（PWAチェックリスト） — 「インストール可能」と「検索で発見可能」を別々のカテゴリとして区別しています。
• サービスワーカー（Learn PWA） — キャッシュ戦略とサービスワーカーのライフサイクル。
• JavaScript SEOの基礎を理解する — Googleが文書化しているアプリシェルの失敗モード。
• インデックス可能なプログレッシブウェブアプリの構築（2016年） — Googleの最初のPWAインデックス可能性に関する投稿。
• Twitter Liteケーススタディ — エンゲージメント指標（注：SEOやオーガニックに関する主張はどこにもありません）。
• ランキングシグナルとしてのHTTPS（2014年） — 「非常に軽量なシグナル」という記述。

MDN / プラットフォーム

• Service Worker API — セキュアコンテキスト（HTTPS）の要件。
• Making PWAs installable — ブラウザ/OSごとのインストール可否の違い。iOSでbeforeinstallpromptがサポートされない理由を含む。

Bing / Microsoft (PWA固有のランキングガイダンスは存在しない — これらはインストール/配布に関するドキュメント)

• Bing Webmaster Guidelines — 一般的なクロール可能性。PWAに依存しない。
• Overview of Progressive Web Apps (PWAs) — Edgeのインストールと配布に焦点。

ソースからの引用

公式発言。引用がGoogle所有のURLではなく第三者によって伝えられている場合、その旨が注記される。

Google — PWAのランキング優位性なし

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” (翻訳) 「PWAは現在Google検索において何ら優位性を持たず、私の知る限りこれを変更する計画はありません。」 — John Mueller（Google）、Search Centralオフィスアワー（2021年11月）。 報道を読む
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (翻訳) 「デフォルトで、PWAにすることでランキングが向上するというのは、そうではないと思います。」 — John Mueller、同じセッション。 報道を読む
• “So just the fact that one of your competitors has moved from one framework to another, and has seen an improvement in search, that framework change from my point of view wouldn’t be responsible for that.” (翻訳) 「つまり、競合他社がフレームワークを別のものに移行し、検索で改善が見られたとしても、私の見解ではそのフレームワーク変更が原因ではないでしょう。」 — John Mueller、同じセッション。 報道を読む

Google — PWAとは何か、アプリシェルのリスク

• “Progressive Web Apps (PWA) are web apps built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase.” (翻訳) 「プログレッシブウェブアプリ（PWA）は、最新のAPIで構築・拡張されたウェブアプリであり、単一のコードベースでどのデバイスのどのウェブユーザーにも届きながら、拡張された機能を提供します。」 — web.dev。 引用へ移動
• “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” (翻訳) 「一部のJavaScriptサイトでは、初期HTMLに実際のコンテンツが含まれず、GoogleがJavaScriptが生成する実際のページコンテンツを確認する前にJavaScriptを実行する必要があるアプリシェルモデルを使用する場合があります。」 — Google Search Central。 引用へ移動
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (翻訳) 「一意のURL、説明的なタイトル、メタディスクリプション、構造化データを通じて検索エンジンによる発見を有効にします。」 — web.dev PWAチェックリスト、「検索で発見可能」。 引用へ移動

Google — サービスワーカーとインデックス (報道による)

• “As we have to assume that someone clicking on your page from a SERP is a first-time visitor, running a service worker is usually not going to do much good.” (翻訳) 「SERPからあなたのページをクリックする人は初めての訪問者であると想定しなければならないため、サービスワーカーを実行しても通常あまり効果はないでしょう。」 — Martin Splitt（Google）。 報道を読む
• “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (翻訳) 「検索結果からあなたのページをクリックするユーザーは、以前にそこを訪れたことがないかもしれないため、私たちはそれをサポートしていません。」 — Martin Splitt（Google）（Google I/O 2019）。 報道を読む
• “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (翻訳) 「それが変わるとは思っていません — インデックスのためにこのようにバックグラウンドでサービスワーカーを実行するのは計算コストが高いからです。」 — John Mueller（Google）（2023年7月報道）。 報道を読む

HTTPS：プラットフォーム要件とランキングシグナル

• “Service workers are only available in secure contexts: this means that their document is served over HTTPS, although browsers also treat http://localhost as a secure context, to facilitate local development.” (翻訳) 「Service Worker はセキュアコンテキストでのみ利用可能です。つまり、そのドキュメントは HTTPS で配信される必要がありますが、ブラウザはローカル開発を容易にするために http://localhost もセキュアコンテキストとして扱います。」 — MDN、Service Worker API。 引用元へ移動
• “we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (翻訳) 「HTTPS をランキングシグナルとして使い始めています。現時点では非常に軽量なシグナルに過ぎません — 全世界のクエリの 1 % 未満に影響し、高品質なコンテンツなどの他のシグナルよりも重みが小さいものです。」 — Google、「HTTPS as a ranking signal」(2014)。 引用元へ移動

インストール可能性はブラウザ/OSによって異なる

• “This is not supported on iOS.” (翻訳) 「これはiOSではサポートされていません。」 — MDN、beforeinstallpromptカスタムインストールプロンプトイベントについて。 引用へジャンプ

レンダリングタイムアウトについて (時代に応じた文脈)

• “Rendering services won’t wait forever for a page to finish loading.” (翻訳) 「レンダリングサービスは、ページの読み込みが完了するまで永遠に待つわけではありません。」 — Hamlet Batista、Search Engine Land。 記事を読む

PWAにすべきか、そしてSEOに何をもたらすか？

このトピックについて人々が実際に持ち込む質問を簡単に見ていきましょう。

「PWAを検討しています。SEOに役立ちますか？」

• 固有のランキング上の利点はありません — GoogleはPWAが検索で優位性を得ることはないと述べています。→ ランキングのためではなく、ユーザーの利点（インストール可能、オフライン、高速な再読み込み）のためにPWAを構築してください。→ レンダリングとサービスワーカーが正しく設定されている限り（以下を続行）、SEOを損なうこともありません。

「PWAを構築中/構築済みです。私のコンテンツは実際にインデックス可能ですか？」

• 初期HTMLに実際のコンテンツ（SSR/プリレンダリング）が含まれていますか、それともJSで埋められる空のアプリシェルですか？
  • 空のシェル、SSRなし → これがアプリシェルの罠です。PWA固有のこと心配する前に、SSRまたはプリレンダリングを追加してください。（任意のSPAと同じ修正です。）
  • SSR/プリレンダリングが導入済み → 良いです。サービスワーカーに進みましょう。

「サービスワーカーはページをどのようにキャッシュすべきですか？」

• HTMLドキュメント → ネットワークファースト（またはstale-while-revalidate、短いTTL）。HTMLにはキャッシュファーストを使用しないでください。
• 静的アセット（JS/CSS/画像/フォント） → キャッシュファーストで問題なく、むしろ良いです。
• オフラインフォールバックページ → 新しいクロールがインデックスするバージョンになることは決してないようにしてください。

「PWAのローンチ後にランキング/トラフィックが低下しました。どこを見ればよいですか？」

1. Search ConsoleでURL Inspection（ライブテスト）を実行 — Googleは実際のページを見ていますか、それとも古い/オフライン/空のページを見ていますか？
2. 古いまたは空の場合 → サービスワーカーのキャッシュ戦略（キャッシュファーストHTML）またはSSRステップの欠落を疑ってください。
3. コンテンツが存在するのにランキングがまだ低下している場合 → リビルドが他に何を変更したかを見てください：内部リンク、コンテンツ、リダイレクト、速度。PWAというラベルが原因であることはほとんどありません。

「SEOのためにマニフェストで特別なことをする必要はありますか？」

• いいえ。インストール可能性のために有効に保ってください。SEO上の役割はありません。URL、タイトル、メタ、構造化データ、Core Web Vitalsに労力を費やしてください。

PWA SEOチェックリスト

プログレッシブWebアプリをクロール可能かつインデックス可能に保つためのスキャン可能なパス：

• 実際のコンテンツはサーバーサイドレンダリングまたはプリレンダリングされている — ロード後にJavaScriptで埋められる空のアプリシェルではない。
• すべてのルートがHistory APIを介して実際の一意のURLを持つ（ハッシュ/#!ルーティングなし）。
• 各ルートがレンダリングされたDOM内で独自のcanonical、タイトル、メタディスクリプションを返す。
• サービスワーカーがHTMLをネットワークファースト（またはstale-while-revalidate、短いTTL）で配信する — HTMLドキュメントに対してキャッシュファーストにしない。
• 静的アセット（JS/CSS/画像/フォント）はキャッシュファーストで問題ない。
• オフラインフォールバックページが新しいクロールでインデックスされることは決してない。
• URL Inspection（ライブテスト）がGoogleに実際の現在のページを表示する — ライブページと比較して。
• マニフェストはインストール可能性のために有効であるが、SEOのレバーとして扱っていない。
• インストール可能性はブラウザ/OSごとにテストされ、普遍的と想定されていない（iOS Safariにはbeforeinstallpromptがない。手動でホーム画面に追加する）— そしてその変動のいずれもSEOの問題として扱われない。
• HTTPSで配信される（サービスワーカーにはそもそも必須）。
• Core Web Vitalsが健全である — JSバンドルとハイドレーションがLCP/INPを低下させていないことを確認する。
• Eコマース：各製品ページが実際の一意のHTMLを返す。ファセットナビゲーション/クライアントルーティングがシェルのみまたは無限のパラメータURLを生成していない。

PWA SEO — チートシート

SEOに影響しますか？

リソースタイプ別のサービスワーカーキャッシュ戦略

豆知識

• GoogleはPWAにランキング上の利点を与えない（Mueller）。
• Googleのレンダラーはインデックス時にサービスワーカーを実行しない。
• HTTPSランキングシグナル：「グローバルなクエリの1%未満」（Google、2014年）。
• Bing：PWA固有のガイダンスなし — 他のJSサイトと同様に扱う。

インシデントプレイブック：PWAリリース後に検索トラフィックが低下した場合

1. リリースパスを凍結する。 障害が発生している本番状態とリリース識別子を保持したまま、それ以上のサービスワーカーとルーティングのデプロイを停止します。
2. 影響範囲を確認する。 テンプレート、ディレクトリ、デバイス、デプロイ時間ごとに低下をセグメント化します。PWA全体の障害を、1つの壊れたルートから推測すべきではありません。
3. 3つのレスポンスを比較する。 生のHTTPレスポンス、ストレージをクリアした新しいレンダリングページ、サービスワーカーによって制御される再訪ユーザーページを保存します。タイトル、canonical、robotsディレクティブ、主要なコピー、リンク、ステータスの動作を確認します。
4. 登録とキャッシュポリシーを検査する。 DevToolsのApplicationで、アクティブなワーカー、そのスコープ、待機中のバージョン、キャッシュ名、ナビゲーションハンドラーを特定します。HTMLナビゲーションが古いキャッシュファーストのレスポンスの背後に閉じ込められていないことを確認します。
5. ワーカーをバイパスする。 ワーカーを登録解除するか、DevToolsのバイパスオプションを使用して、再読み込みし、影響を受けるルートを繰り返します。欠陥が消えた場合、ワーカーまたはそのキャッシュが境界の可能性が高いです。残っている場合は、通常のJavaScript SEOインシデントとして続行します。
6. 安全なナビゲーションパスを復元する。 ワーカーをロールバックするか、ドキュメントリクエストを明示的なオフラインフォールバック付きのネットワークファーストに切り替えます。ユーザーがオフラインデータに依存している場合、すべてのキャッシュを盲目的に削除しないでください。
7. 検証と監視。 クリーンなブラウザ、更新中のブラウザ、オフラインブラウザをテストします。次に、代表的なURLを検査し、通常の再クロールウィンドウを通じて検索パフォーマンスを監視します。

マニフェストをSEOファイルとして扱う

name、short_name、またはアイコンメタデータにキーワードを詰め込んでも、ページのインデックス可能性は向上しません。マニフェストはインストール動作に使用し、検索関連のコンテンツは、通常のタイトル、リンク、canonicalを持つクロール可能なHTMLに配置します。

HTMLを永久にキャッシュする

ナビゲーションを不変のアセットとして扱うキャッシュファーストのルールは、リリース後に古いコピー、canonical、またはrobotsディレクティブを存続させる可能性があります。バージョン付きのJS、CSS、画像は積極的にキャッシュします。HTMLにはネットワークを認識する更新戦略を与えます。

オフラインシェルを成功ページとして返す

利用できないすべてのURLに対して同じオフラインアプリシェルを提供すると、多くの異なるURLが同一の薄いコンテンツを返しているように見える可能性があります。オフラインエクスペリエンスを通常のナビゲーションから明確に分離し、欠落しているドキュメントが要求されたページであるふりをしないでください。

ナビゲーションを非リンクコントロールの背後に隠す

クライアントの状態を変更するボタンは、アプリ内では機能するかもしれませんが、宛先へのクロール可能な<a href>パスを提供しません。検索エンジンとユーザーがたどる必要があるルートには実際のリンクを使用し、その後JavaScriptで遷移を強化します。

ウォームな再訪ユーザーとしてのみテストする

インストールされたワーカーとキャッシュが設定された開発者ブラウザは、壊れた初回訪問を隠す可能性があります。クリーンなストレージ、以前のワーカーからのアップグレード、再訪をテストします。これらは異なるPWA状態です。

例：アセットキャッシュとドキュメントキャッシュには異なるルールが必要

次の簡略化されたサービスワーカーロジックは、境界を示しています。ハッシュ付きアセットはキャッシュファーストにできます。ドキュメントナビゲーションは、フォールバックする前にネットワークを試す必要があります。

self.addEventListener('fetch', event => {
  const request = event.request;

  if (request.mode === 'navigate') {
    event.respondWith(
      fetch(request).catch(() => caches.match('/offline/'))
    );
    return;
  }

  if (['script', 'style', 'image', 'font'].includes(request.destination)) {
    event.respondWith(
      caches.match(request).then(cached => cached || fetch(request))
    );
  }
});

正確な本番ポリシーは、更新とオフラインの要件に依存しますが、SEOの教訓は安定しています。HTMLは、フィンガープリント付きバンドルと同じ種類の不変アセットではありません。

例：クロール可能なルートとアプリのみの状態

<!-- Search engines and users get a real destination. -->
<a href="/products/running-shoes/">Running shoes</a>

<!-- This changes app state but exposes no destination URL. -->
<button onclick="showCategory('running-shoes')">Running shoes</button>

PWAは、クロール可能なURLを削除せずに、アプリのような遷移のためにリンクをインターセプトできます。

プロンプト：サービスワーカーのキャッシュ戦略をレビューする

ワーカーソースとルートインベントリを貼り付けます。シークレットやプライベートなAPIレスポンスを含めないでください。

Audit this service worker for search and freshness risks. Classify each fetch route as
document navigation, versioned static asset, API response, media, or offline fallback.
For each route, state the current strategy, the stale-content failure mode, and a safer
strategy. Pay special attention to HTML served cache-first, redirect handling, offline
shells returned for real URLs, cache-version cleanup, and worker scope. Quote the exact
code that creates each finding. Do not claim that PWA features provide a ranking boost.

Route inventory:
[PASTE ROUTES AND CONTENT TYPES]

Service worker:
[PASTE SOURCE]

プロンプト：PWAリリースQAマトリックスを構築する

Create a release QA matrix for this PWA. Cover a clean first visit, a returning visit
with the current worker, an upgrade from the previous worker, offline navigation, and a
worker-bypassed visit. For each state, list how to reproduce it and what to compare in
the raw response and rendered page: status behavior, title, canonical, robots, primary
content, internal links, and freshness. Use only the routes and requirements I provide;
flag missing evidence instead of inventing expected results.

Routes and requirements:
[PASTE ROUTE | EXPECTED CONTENT | OFFLINE REQUIREMENT | RELEASE CHANGE]

PWA SEOレビューのためのSHELLフレームワーク

• S: サーバーレスポンス。 利用可能な最初のレスポンス、または意図的なレンダリング戦略が、空のアプリシェルだけでなくページを公開する必要があります。
• H: リンク。 重要なルートは、クライアント側の状態としてのみ存在するコントロールではなく、安定したURLを持つクロール可能なリンクを使用します。
• E: 期待されるメタデータ。 タイトル、正規化、robotsディレクティブ、構造化データは、生の状態とレンダリングされた状態の両方で正しいままです。
• L: ライブドキュメント。 ナビゲーションリクエストには、HTMLに適した鮮度ポリシーがあります。古いキャッシュされたドキュメントがリリースを静かに超えて存続することはありません。
• L: ライフサイクルテスト。 QAは、インストール、アクティベート、更新、待機ワーカー、オフライン、バイパス状態を、1回のウォームな開発者セッションではなくカバーします。

フレームワークは、PWA固有のレビューを狭く保ちます。5つすべてが合格した場合、残りの作業のほとんどは、通常のJavaScript、パフォーマンス、インデックス可能性のQAです。

DevToolsコンソール: アクティブなワーカーとキャッシュを検査する

PWAでブラウザのDevToolsコンソールでこれを実行します。登録とキャッシュ名を変更せずに報告します。

const registrations = await navigator.serviceWorker.getRegistrations();
console.table(registrations.map(r => ({
  scope: r.scope,
  active: r.active?.scriptURL || '',
  waiting: r.waiting?.scriptURL || '',
  installing: r.installing?.scriptURL || ''
})));
console.log('Caches:', await caches.keys());

DevToolsコンソール: ネットワークフェッチとキャッシュされたレスポンスを比較する

const path = location.pathname;
const network = await fetch(path, { cache: 'no-store' });
const cached = await caches.match(path);
console.table({
  network: { status: network.status, type: network.type },
  cache: { found: Boolean(cached), status: cached?.status ?? '' }
});

この結果は、レスポンスがキャッシュに存在することを証明しますが、すべてのナビゲーションでどのフェッチハンドラーが勝つかを証明するものではありません。ワーカーソースとネットワークパネルでルーティングを確認してください。

正規表現: リスクの高いキャッシュファーストのナビゲーションハンドラーを見つける

これをパーサーではなくレビュー支援として使用します。ナビゲーション条件とその近くのキャッシュルックアップを探します。

request\.mode\s*===?\s*['"]navigate['"][\s\S]{0,500}caches\.(?:match|open)\s*\(

PWA SEOリリースを検証する

自分をテスト: PWA SEO

プログレッシブウェブアプリが検索とどのように相互作用するかについての5つの簡単な質問。それぞれに回答を選んで、確認してください。

時間をかける価値のあるリソース

私の関連記事

• JavaScript SEOの問題とベストプラクティス — すべてのPWAが基づくレンダリングの基盤。アプリシェル、SSR、そしてGoogleのレンダラーが何をし、何をしないか。
• 技術SEOの初心者向けガイド — レンダリングとクロール可能性が全体像のどこに当てはまるか。

私の講演

• 検索の仕組み (SlideShare) — クロール、レンダリング、インデックス、ランキングのパイプラインをPWAが通過しなければならない私のウォークスルー。(常時免責事項: 「これは私のシステムの理解です…100%完全または正確ではありません。」)

業界からの情報

• Google: Progressive Web Apps Don’t Rank Better Than Regular Sites (Search Engine Journal) — Muellerのオフィスアワーでの発言を報じた記事で、この誤解を覆す根拠となる。
• Google Says Progressive Web Apps (PWAs) Have No Advantage In Search (Search Engine Roundtable) — 同じセッションを独立に報じた記事。
• Service Worker – What SEOs Need to Know (SearchViu) — レンダラーがサービスワーカーをスキップする理由に関するSplitt/Muellerの発言。
• Understand JavaScript SEO Basics (Google) — アプリシェルの失敗モードについて、元資料で解説。
• What makes a good Progressive Web App? (PWA checklist) (web.dev) — インストール可能性と発見可能性を別々のカテゴリとして扱う。
• Twitter Lite case study (web.dev) — 実際のエンゲージメント数値と、それがSEOとは無関係だったことの証明。

動画

• Google Search Central (YouTube) — Martin SplittのJavaScript SEOとレンダリングの解説動画は、PWAが依存する正確なパイプライン（クロール → レンダリング → インデックス）をカバーしており、ステートレスなレンダラーがJavaScriptをどう処理するかも含む。 チャンネル

変更履歴