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 cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. 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 descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. rules from JavaScript/SPA SEOSPA SEO is the practice of making a client-side-routed single-page application — one that loads a single HTML document and then swaps views with JavaScript (React Router, Vue Router, Angular Router) — crawlable and indexable, so every route resolves to real, unique HTML with its own URL, canonical, and metadata. apply unchanged, plus two PWA-specific concerns. Google gives PWAs no ranking advantage (Mueller). The manifest.json governs installability, not indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., so a cache-first HTML strategy can index a stale or offline shell — use network-first for HTML, cache-first for static assets. HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. or prerendering for content availability; per-route canonical, title, and meta in the rendered DOM. If you’ve read the JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. and SPA SEO material, you already know 90% of PWA SEOPWA 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. — 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/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. 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 linkingAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..” 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. never executes. The danger is the reverse case: a cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. (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 HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers., an over-eager service worker — can easily post worse Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. 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 navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals. 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 crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index., sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere., IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it.), 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/cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency.) layered on what’s almost always a JS/SPA site. All the JavaScript/SPA SEOSPA SEO is the practice of making a client-side-routed single-page application — one that loads a single HTML document and then swaps views with JavaScript (React Router, Vue Router, Angular Router) — crawlable and indexable, so every route resolves to real, unique HTML with its own URL, canonical, and metadata. 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (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.
• HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' ≠ a PWA SEOPWA 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. perk. It’s a hard requirement for service workers (secure context) and separately a “very lightweight” ranking signal every HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' site gets. Don’t chain the two.
• Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index..

Official documentation

Primary-source material on PWAs, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., 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) — cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. 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 (HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.') 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 crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index.; 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 descriptionsThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through., and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..” — web.dev PWA checklist, “Discoverable in search.” Jump to quote

Google — service workers and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..” — John Mueller, Google (reported July 2023). Read the coverage

HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.': platform requirement vs. ranking signal

• “Service workers are only available in secure contexts: this means that their document is served over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. timeouts (dated context)

• “RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal.), 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 InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (live test) in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — is Google seeing the real page or a stale/offline/empty one?
2. If stale or empty → suspect the service-worker cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. 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 linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., content, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. 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 InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (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 HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' (required for service workers anyway).
• Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are healthy — verify the JS bundle and hydrationTurning HTML, CSS, and JavaScript into the final visual page and DOM. aren’t dragging LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..
• 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 SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. 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 recrawlCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. 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 contentThin content is web content that provides little or no value to users. Google's spam policies name it 'thin content with little or no added value' — and it's about value per page, not word count.. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. and crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., 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 SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. and renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. explainers cover the exact pipeline (crawl → render → indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.) 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 frameworksJavaScript frameworks — React, Vue, Angular, Next.js, Nuxt, Svelte, Astro — are libraries or meta-frameworks for building web UIs. Their SEO impact depends on rendering mode: SSR and SSG deliver pre-rendered HTML; CSR-only apps require Googlebot to execute JavaScript before it can index content. and single-page-application patterns, so the same renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. service doesn’t execute service workers when indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (it treats every crawl as a first-time visit), a cache-first cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. strategy on HTML can serve GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. a stale or offline-fallback page instead of live content. Everything else that overlaps SEO — Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' — is true of any well-built site, PWA or not.

Related: SPA SEO, JavaScript SEO

Changelog