PWA SEO

TL;DR — A PWA (Progressive Web App) is a normal website with two extras bolted on: a manifest that lets people install it to their home screen, and a service worker that can make it work offline. To Google it’s still just a website — going PWA does not boost your rankings. The one thing that can actually hurt you is a badly set-up service worker that shows Google an old, cached page instead of your live one.

What a PWA actually is

A Progressive Web App is a website that’s been enhanced to feel more like a native app. Two pieces make it a PWA:

• A web app manifest (manifest.json) — a small file that tells the browser your app’s name, icons, and colors, so a visitor can tap “Add to Home Screen” and get an app-style icon and splash screen.
• A service worker — a bit of JavaScript that runs in the background and can cache files so the site loads fast on repeat visits and even works offline.

That’s it. Underneath, a PWA is almost always a regular JavaScript website (React, Vue, Angular, and so on). It’s a normal site wearing an app costume.

The big myth to bust

The most common thing people believe is: “If we turn our site into a PWA, we’ll rank better.” Google has said plainly that this isn’t true. Google’s John Mueller put it directly: PWAs “currently don’t have any advantage in Google Search.” There is no “PWA bonus” in the ranking systems.

The manifest file doesn’t help SEO either. It controls how the app installs — the icon, the name, the splash screen — none of which Google reads when deciding how to rank you.

The one thing that can actually hurt

The service worker is the part to be careful with. Because it can serve a cached (saved) copy of your pages, a bad setup can end up showing Google a stale or even blank “you’re offline” version of a page instead of the real, up-to-date one. That’s how a PWA loses traffic after launch — not because it “became a PWA,” but because the caching was pointed the wrong way.

What to actually do

• Make sure your real page content loads for search engines, not just an empty shell that fills in with JavaScript afterward.
• Set your service worker so it fetches fresh HTML from the network first, and only falls back to the cache for speed on things like images and stylesheets.
• Keep the basics right: real, unique URLs; a good title and meta description on every page; a fast, reliable experience.

Being a PWA is great for your users — installable, fast, offline-friendly. Just don’t expect it to move you up in Google, and don’t let the service worker feed Google the wrong page. The Advanced tab has the mechanics, the caching strategies, and the quotes.

TL;DR — A PWA is a manifest + a service worker layered on top of what is almost always a JS/SPA site — so the rendering rules from JavaScript/SPA SEO apply unchanged, plus two PWA-specific concerns. Google gives PWAs no ranking advantage (Mueller). The manifest.json governs installability, not indexing, and there’s no evidence the ranking systems read it. The service worker is the real risk: Google’s renderer does not run service workers when indexing, so a cache-first HTML strategy can index a stale or offline shell — use network-first for HTML, cache-first for static assets. HTTPS is a hard requirement for service workers and separately a tiny ranking signal; don’t chain those into “PWAs rank better.” Core Web Vitals is the only legitimate overlap, and it’s the engineering, not the PWA label.

A PWA is a website first

The single most useful frame: a Progressive Web App is a normal website with two things added on top. Per Google’s own definition, PWAs “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.” The three pillars Google names are Capable, Reliable, and Installable — note that none of the three is “rankable.”

Architecturally, that codebase is almost always a JavaScript framework running a single-page-application pattern. Which means: everything that governs JS/SPA indexability governs PWA indexability, with no modification. Real <a href> links and History-API routing (not hash fragments) for addressability; server-side rendering or prerendering for content availability; per-route canonical, title, and meta in the rendered DOM. If you’ve read the JavaScript SEO and SPA SEO material, you already know 90% of PWA SEO — the app-shell failure mode, in particular, is one Google explicitly documents: “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.” A PWA that ships an empty shell with no SSR/prerender inherits that problem directly.

So the honest scope of a PWA-specific SEO article is small: the manifest, and the service worker. Everything else is JS/SPA SEO wearing a manifest.

The core myth: “going PWA” does not improve rankings

This is the headline. Google has been unusually direct about it. John Mueller, in a Search Central office-hours session, said PWAs “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” and — asked whether converting to a PWA would help — “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.”

He also pre-empted the usual counter-argument, that “our competitor went PWA and their rankings jumped.” His answer: “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.” And on why: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.”

Where PWA relaunches do correlate with ranking lifts, it’s the confounds that come with any big rebuild: modernized internal linking, refreshed and expanded content, genuine speed improvements, and usually a marketing push tied to the relaunch. None of that requires the PWA label. If you rebuild a 10-to-15-year-old organically-grown site, you change a dozen things at once — attributing the result to “PWA” is a correlation error.

Manifest.json: installability ≠ indexability

The manifest.json file exists to make your app installable. Its fields — name, short_name, icons, start_url, display, theme_color — drive the install prompt, the home-screen icon, the splash screen, and whether the app opens standalone or in a browser tab. That’s the entire job.

There’s no evidence Google’s ranking or indexing systems read the manifest as a signal. The cleanest external confirmation is Google’s own PWA checklist, which lists “Is installable” and “Discoverable in search” as two separate, independent checklist categories — where discoverability is defined as ordinary SEO fundamentals: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” Installability (manifest-driven) and discoverability (classic SEO) are treated as parallel concerns, not one feeding the other. So: keep a valid manifest because it’s what makes the app installable — just don’t file it under SEO.

Service workers: the one real PWA-specific SEO risk

Here’s the fact that matters most, and it’s PWA-specific: Google’s rendering service does not run your service worker when it renders a page for indexing. The reasoning, from Martin Splitt: “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.” A service worker’s whole point is speeding up repeat visits from a cache — and Googlebot is, by design, always treated as a first-time visitor, so there’s nothing for it to speed up. Splitt again: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” Mueller has confirmed this is stable policy, not a temporary state: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.”

So why is that a risk? Because your service worker does run in real users’ browsers, and if you told it to serve HTML cache-first — return the saved copy, skip the network — then a real repeat visitor sees a fast cached page, but that’s a strategy Googlebot never executes. The danger is the reverse case: a caching pattern that, under any error or fallback condition, hands back a stale document or the offline-fallback page. Because rendering is stateless and the WRS treats every fetch as fresh, a misconfigured caching strategy is how a PWA ends up with Googlebot indexing an outdated or empty offline shell instead of live content.

The caching-strategy rule of thumb:

• HTML documents → network-first (or stale-while-revalidate with a short TTL). Get the live page; use the cache only as an offline fallback, and make sure that fallback is never what a fresh crawl would index.
• Static assets (JS, CSS, images, fonts) → cache-first is fine and desirable — they don’t change per request and aren’t the indexable document.

How to audit it: compare what Googlebot sees against what a repeat visitor’s browser serves from cache. Use URL Inspection in Search Console (live test) to see the rendered HTML Google actually gets, and check it against the live page. If they diverge, your service worker or SSR setup is the first suspect. And watch rendering timeouts on hybrid setups — as Hamlet Batista noted from the dynamic-rendering era, “Rendering services won’t wait forever for a page to finish loading.” (That specific article is about dynamic rendering, which Google now discourages in favor of SSR — cite the timeout principle, not the pattern.)

HTTPS: a service-worker requirement, and separately a tiny ranking signal

You’ll see PWA SEO posts imply “PWAs need HTTPS, and HTTPS boosts rankings, therefore PWAs are more SEO-friendly.” Two true facts, wrongly chained.

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.

Fact two: HTTPS is a real Google ranking signal, but a minuscule one. Google’s own 2014 announcement: “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.”

The point: any HTTPS site gets that same tiny signal — PWA or not. A PWA doesn’t get extra SEO credit for HTTPS; it just can’t function without it. Don’t sell HTTPS as a PWA SEO benefit.

Core Web Vitals: the one legitimate overlap

If there’s a real place where “good PWA” and “good SEO” meet, it’s performance. Google’s PWA guidance leads with reliability — “A reliable Progressive Web App feels fast and dependable regardless of the network” — and Core Web Vitals are a confirmed (if modest) ranking factor. A well-engineered PWA that loads fast and stays responsive will tend to score well on Vitals.

But read the causation carefully: it’s the engineering, not the PWA-ness. A bloated PWA — huge JS bundle, render-blocking hydration, an over-eager service worker — can easily post worse Core Web Vitals than a plain server-rendered page. The Vitals win comes from doing the performance work well, which you could do with or without a manifest. Being a PWA neither guarantees good Vitals nor grants a shortcut to them.

App-like features are UX, not ranking factors

Add-to-home-screen, offline mode, push notifications, app-like navigation — all genuine, valuable PWA benefits, and all engagement/retention features, not indexing or ranking inputs. Google’s PWA checklist makes the split explicit by putting “installable” and “discoverable in search” in separate buckets.

Don’t treat “installable” as a single, universal capability either — it varies by browser and OS, which is one more reason it can’t be an SEO signal (Google would have no consistent, cross-browser behavior to reward). The beforeinstallprompt event that lets a PWA show its own custom install UI is a Chromium-only mechanism; per MDN’s PWA installability guide, it’s “not supported on iOS.” On iOS Safari, installation happens only through the manual Share → Add to Home Screen flow (extended to Chrome, Edge, Firefox, and Orion on iOS 16.4+, all of which use Apple’s required WebKit engine on iOS and so share that limitation), not an automatic prompt. None of that changes the SEO picture — it just means “is my PWA installable” isn’t a yes/no fact independent of which browser and OS a visitor is on.

Twitter Lite is the case study everyone reaches for as “proof PWAs help SEO” — and its documented results are real (a 65% increase in pages per session, 75% increase in Tweets sent, 20% decrease in bounce rate) — but every one of those is an engagement metric. Google’s own case study of it never mentions SEO, organic search, or rankings at all. Great result; wrong column.

Ecommerce PWA storefronts: a short callout

PWA storefronts add a few wrinkles worth naming, because they compound the SPA risks. Client-side routing plus faceted navigation can generate crawlable-looking URLs that all resolve to the same shell, or an explosion of parameter URLs. Cart and checkout state lives client-side and should never gate the indexable product content. And each product page must independently return real, unique HTML — the app-shell trap is most expensive exactly where you have the most pages. The fixes are the same ones from ecommerce and faceted-navigation SEO; the PWA layer doesn’t change them, it just makes the SSR/prerender discipline more important.

Bing and PWAs

Worth a line: Bing has published no PWA-specific ranking or indexing guidance. Its webmaster guidelines are PWA-agnostic (general crawlability, sitemaps, robots.txt, IndexNow), and Microsoft’s extensive PWA docs are entirely about Edge install prompts, PWABuilder, and Microsoft Store packaging — distribution and installation, a separate track from web-search indexing. So for Bing, default to ordinary JS-rendering crawlability guidance; there’s no PWA exception to learn.

The bottom line

PWA SEO is JavaScript/SPA SEO plus exactly two additions: ignore the manifest as an SEO input (it’s for installability), and configure the service worker so it never traps Googlebot in a stale or offline cache. Get those right and a PWA indexes exactly like any other well-built site — no bonus, no penalty, just the same rules.

AI summary

A condensed take on the Advanced version:

• A PWA is a website first. It’s a manifest.json (installability) + a service worker (offline/caching) layered on what’s almost always a JS/SPA site. All the JavaScript/SPA SEO rules apply unchanged.
• No ranking advantage. Google’s John Mueller: PWAs “currently don’t have any advantage in Google Search.” “Going PWA” does not improve rankings.
• Manifest.json is SEO-irrelevant. It controls install prompts, icons, start_url, display — there’s no evidence the ranking systems read it. Google’s PWA checklist lists “installable” and “discoverable in search” as separate categories.
• The one real risk is the service worker. Google’s renderer doesn’t run service workers when indexing (it treats every crawl as a first-time visit), so a cache-first HTML strategy can index a stale or offline shell. Use network-first for HTML, cache-first for static assets.
• HTTPS ≠ a PWA SEO perk. It’s a hard requirement for service workers (secure context) and separately a “very lightweight” ranking signal every HTTPS site gets. Don’t chain the two.
• Core Web Vitals is the only legit overlap — and it’s the performance engineering, not the PWA label. A bloated PWA can score worse.
• App-like features (install, offline, push) are engagement, not ranking. Twitter Lite’s famous gains are engagement metrics; that case study never mentions SEO. Installability itself varies by browser/OS (iOS Safari has no beforeinstallprompt, only manual Add to Home Screen) — one more reason it can’t be a ranking signal.
• Bing has no PWA-specific guidance; default to ordinary JS crawlability.

Official documentation

Primary-source material on PWAs, rendering, and the facts this article rests on.

Google / web.dev

• What are Progressive Web Apps? — Google’s definition and the three pillars (Capable, Reliable, Installable).
• What makes a good Progressive Web App? (PWA checklist) — separates “Is installable” from “Discoverable in search” as distinct categories.
• Service workers (Learn PWA) — caching strategies and the service-worker lifecycle.
• Understand JavaScript SEO Basics — the app-shell failure mode Google documents.
• Building Indexable Progressive Web Apps (2016) — Google’s original PWA-indexability post.
• Twitter Lite case study — the engagement metrics (note: no SEO/organic claims anywhere in it).
• HTTPS as a ranking signal (2014) — the “very lightweight signal” statement.

MDN / platform

• Service Worker API — the secure-context (HTTPS) requirement.
• Making PWAs installable — browser/OS installability differences, including why beforeinstallprompt isn’t supported on iOS.

Bing / Microsoft (no PWA-specific ranking guidance exists — these are install/distribution docs)

• Bing Webmaster Guidelines — general crawlability; PWA-agnostic.
• Overview of Progressive Web Apps (PWAs) — Edge install and distribution focus.

Quotes from the source

On-the-record statements. Where a quote is relayed by a third party rather than a Google-owned URL, the caveat says so.

Google — no PWA ranking advantage

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” — John Mueller, Google, Search Central office-hours (Nov 2021). Read the coverage
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” — John Mueller, same session. Read the coverage
• “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, same session. Read the coverage

Google — what a PWA is, and the app-shell risk

• “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.” — web.dev. Jump to quote
• “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.” — Google Search Central. Jump to quote
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” — web.dev PWA checklist, “Discoverable in search.” Jump to quote

Google — service workers and indexing (relayed)

• “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.” — Martin Splitt, Google. Read the coverage
• “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). Read the coverage
• “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 (reported July 2023). Read the coverage

HTTPS: platform requirement vs. ranking signal

• “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.” — MDN, Service Worker API. Jump to quote
• “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.” — Google, “HTTPS as a ranking signal” (2014). Jump to quote

Installability varies by browser/OS

• “This is not supported on iOS.” — MDN, on the beforeinstallprompt custom-install-prompt event. Jump to quote

On rendering timeouts (dated context)

• “Rendering services won’t wait forever for a page to finish loading.” — Hamlet Batista, Search Engine Land. Read the article

Should I go PWA — and what will it do for SEO?

A quick walk through the questions people actually bring to this topic.

“We’re considering a PWA. Will it help our SEO?”

• No inherent ranking benefit — Google says PWAs get no advantage in Search. → Build a PWA for the user benefits (installable, offline, fast repeat loads), not for rankings. → It won’t hurt SEO either, as long as your rendering and service worker are set up correctly (continue below).

“We’re building/have a PWA. Is my content actually indexable?”

• Does the initial HTML contain the real content (SSR/prerender), or is it an empty app shell filled by JS?
  • Empty shell, no SSR → this is the app-shell trap. Add SSR or prerendering before worrying about anything PWA-specific. (Same fix as any SPA.)
  • SSR/prerender in place → good; move to the service worker.

“How should my service worker cache pages?”

• HTML documents → network-first (or stale-while-revalidate, short TTL). Never cache-first for HTML.
• Static assets (JS/CSS/images/fonts) → cache-first is fine and good.
• Offline fallback page → make sure it can never be the version a fresh crawl indexes.

“My PWA lost rankings/traffic after launch. Where do I look?”

1. Run URL Inspection (live test) in Search Console — is Google seeing the real page or a stale/offline/empty one?
2. If stale or empty → suspect the service-worker caching strategy (cache-first HTML) or a missing SSR step.
3. If the content’s there but rankings still dropped → look at what else the rebuild changed: internal links, content, redirects, speed. The PWA label is rarely the cause.

“Do I need to do anything special with the manifest for SEO?”

• No. Keep it valid for installability; it has no SEO role. Spend the effort on URLs, titles, meta, structured data, and Core Web Vitals instead.

PWA SEO checklist

Scannable pass for keeping a Progressive Web App crawlable and indexable:

• Real content is server-rendered or prerendered — not an empty app shell filled by JavaScript after load.
• Every route has a real, unique URL via the History API (no hash/#! routing).
• Each route returns its own canonical, title, and meta description in the rendered DOM.
• Service worker serves HTML network-first (or stale-while-revalidate, short TTL) — never cache-first for HTML documents.
• Static assets (JS/CSS/images/fonts) can be cache-first; that’s fine.
• The offline-fallback page can never be what a fresh crawl indexes.
• URL Inspection (live test) shows Google the real, current page — compared against the live page.
• The manifest is valid for installability, but you’re not treating it as an SEO lever.
• Installability is tested per browser/OS, not assumed universal (iOS Safari has no beforeinstallprompt; it’s manual Add to Home Screen) — and none of that variance is treated as an SEO issue.
• Served over HTTPS (required for service workers anyway).
• Core Web Vitals are healthy — verify the JS bundle and hydration aren’t dragging LCP/INP down.
• Ecommerce: product pages each return real unique HTML; faceted-nav/client routing isn’t spawning shell-only or infinite parameter URLs.

PWA SEO — cheat sheet

Does it affect SEO?

Service-worker caching by resource type

Fast facts

• Google gives PWAs no ranking advantage (Mueller).
• Google’s renderer does not run service workers when indexing.
• HTTPS ranking signal: “fewer than 1% of global queries” (Google, 2014).
• Bing: no PWA-specific guidance — treat as any JS site.

Incident playbook: search traffic dropped after a PWA release

1. Freeze the release path. Stop further service-worker and routing deployments while you preserve the failing production state and release identifiers.
2. Confirm scope. Segment the drop by template, directory, device, and deployment time. A PWA-wide failure should not be assumed from one broken route.
3. Compare three responses. Save the raw HTTP response, a fresh rendered page with storage cleared, and a returning-user page controlled by the service worker. Check the title, canonical, robots directives, primary copy, links, and status behavior.
4. Inspect registration and cache policy. In DevTools Application, identify the active worker, its scope, waiting versions, cache names, and navigation handler. Confirm HTML navigations are not trapped behind an old cache-first response.
5. Bypass the worker. Unregister it or use DevTools’ bypass option, reload, and repeat the affected route. If the defect disappears, the worker or its cache is the likely boundary; if it remains, continue as an ordinary JavaScript SEO incident.
6. Restore a safe navigation path. Roll back the worker or switch document requests to network-first with an explicit offline fallback. Do not delete all caches blindly if users depend on offline data.
7. Validate and monitor. Test a clean browser, an updating browser, and an offline browser. Then inspect representative URLs and watch search performance through the normal recrawl window.

Treating the manifest as an SEO file

Stuffing keywords into name, short_name, or icon metadata does not make pages more indexable. Use the manifest for installation behavior and put search-relevant content in crawlable HTML with ordinary titles, links, and canonicals.

Caching HTML forever

A cache-first rule that treats navigations like immutable assets can keep old copy, canonicals, or robots directives alive after a release. Cache versioned JS, CSS, and images aggressively; give HTML a network-aware update strategy.

Returning the offline shell as a successful page

Serving the same offline app shell for every unavailable URL can look like many different URLs returning identical thin content. Keep the offline experience clearly separate from normal navigation and do not pretend a missing document is the requested page.

Hiding navigation behind non-link controls

A button that changes client state may work in the app while providing no crawlable <a href> path to the destination. Use real links for routes search engines and users need to follow, then enhance the transition with JavaScript.

Testing only as a warm returning user

A developer browser with an installed worker and populated cache can mask a broken first visit. Test clean storage, an upgrade from the previous worker, and a returning visit. Those are distinct PWA states.

Example: asset caching and document caching need different rules

The following simplified service-worker logic shows the boundary. Hashed assets can be cache-first; document navigations should try the network before falling back.

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))
    );
  }
});

The exact production policy depends on update and offline requirements, but the SEO lesson is stable: HTML is not the same kind of immutable asset as a fingerprinted bundle.

Example: crawlable route versus app-only state

<!-- 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>

A PWA can intercept the link for an app-like transition without removing its crawlable URL.

Prompt: review a service-worker caching strategy

Paste the worker source and a route inventory. Do not include secrets or private API responses.

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]

Prompt: build a PWA release QA matrix

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]

The SHELL framework for PWA SEO reviews

• S: Server response. A usable first response, or a deliberate rendering strategy, must expose the page rather than only an empty app shell.
• H: Hrefs. Important routes use crawlable links with stable URLs, not controls that exist only as client-side state.
• E: Expected metadata. Titles, canonicals, robots directives, and structured data remain correct in raw and rendered states.
• L: Live documents. Navigation requests have a freshness policy appropriate for HTML; stale cached documents do not silently outlive releases.
• L: Lifecycle tests. QA covers install, activate, update, waiting-worker, offline, and bypass states instead of one warm developer session.

The framework keeps PWA-specific review narrow. If all five pass, most remaining work is ordinary JavaScript, performance, and indexability QA.

DevTools Console: inspect the active worker and caches

Run this in the browser DevTools Console on the PWA. It reports registrations and cache names without changing either one.

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 Console: compare a network fetch with a cached response

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 ?? '' }
});

The result proves that a response exists in a cache; it does not prove which fetch handler will win for every navigation. Confirm routing in the worker source and the Network panel.

Regex: find risky cache-first navigation handlers

Use this as a review aid, not a parser. It looks for a navigation condition followed nearby by a cache lookup.

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

Validate a PWA SEO release

Test yourself: PWA SEO

Five quick questions on how Progressive Web Apps interact with search. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO Issues & Best Practices — the rendering foundation every PWA sits on; app-shell, SSR, and what Google’s renderer does and doesn’t do.
• The Beginner’s Guide to Technical SEO — where rendering and crawlability fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, the pipeline a PWA has to pass through. (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Google: Progressive Web Apps Don’t Rank Better Than Regular Sites (Search Engine Journal) — the Mueller office-hours coverage that anchors the myth-bust.
• Google Says Progressive Web Apps (PWAs) Have No Advantage In Search (Search Engine Roundtable) — independent write-up of the same session.
• Service Worker – What SEOs Need to Know (SearchViu) — the Splitt/Mueller statements on why the renderer skips service workers.
• Understand JavaScript SEO Basics (Google) — the app-shell failure mode, documented at the source.
• What makes a good Progressive Web App? (PWA checklist) (web.dev) — installability and discoverability as separate categories.
• Twitter Lite case study (web.dev) — the real engagement numbers, and proof they were never about SEO.

Videos

• Google Search Central (YouTube) — Martin Splitt’s JavaScript SEO and rendering explainers cover the exact pipeline (crawl → render → index) a PWA depends on, including how the stateless renderer handles JS. Channel

PWA SEO

PWA SEO is making sure a Progressive Web App's content is server-rendered or prerendered, its service worker never traps Googlebot in a stale cache, and its URLs are real, unique, and crawlable — since the manifest and offline features that make it a 'PWA' carry no ranking weight of their own.

Related: SPA SEO, JavaScript SEO

PWA SEO

A Progressive Web App (PWA) is a website enhanced with a web app manifest and a service worker so it can behave more like a native app — installable to the home screen, offline-capable, with an app-like UI. PWA SEO is the practice of keeping that app crawlable, renderable, and indexable by search engines.

The key thing to understand is that a PWA is still a website first. Google does not treat it as a special content type and gives it no ranking boost for being a PWA — John Mueller has said PWAs “currently don’t have any advantage in Google Search.” Architecturally, PWAs are almost always built on JavaScript frameworks and single-page-application patterns, so the same rendering and indexability rules that govern any JS/SPA site apply here without modification.

There are only two genuinely PWA-specific SEO concerns. The manifest.json file governs installability (app name, icons, start_url, display mode) — there’s no evidence Google’s ranking systems read it. The service worker is the one real risk: because Google’s rendering service doesn’t execute service workers when indexing (it treats every crawl as a first-time visit), a cache-first caching strategy on HTML can serve Googlebot a stale or offline-fallback page instead of live content. Everything else that overlaps SEO — Core Web Vitals, HTTPS — is true of any well-built site, PWA or not.

Related: SPA SEO, JavaScript SEO

Changelog