PWA SEO

A PWA is not an app for SEO purposes; it remains a website that must serve its content in a way Googlebot can see. I have seen too many teams optimise for Lighthouse performance only to discover their product pages are blank HTML shells that rely on JavaScript to fetch content. If Google cannot execute that JavaScript — and it often throttles or skips it — those pages will not be indexed. For example, an ecommerce client of mine had 5,000 product pages but only 45 indexed because the PWA used client-side routing with pushState but the initial HTML was empty. Change your default route strategy: use server-side rendering or static pre-rendering for important pages. Service workers can cache HTML, but if you cache it for 30 days, Googlebot will see the same stale page for a month. I now use network-first for HTML with a 5-minute cache. This keeps speed gains without hiding updates. Also, verify that your [robots.txt](/robots-txt/) does not block critical CSS or JavaScript — blocking them disables rendering. A PWA must be crawlable and indexable first; the app-like feel is a bonus, not a replacement for [technical SEO](/technical-seo/).

PWA SEO is critical during migration, scaling, and when you rely on JavaScript for content. I worked with a travel booking site that rebuilt as a PWA. Their organic traffic fell 40% within two months because they had not set up [canonical tags](/canonical-tags/) for the new routes. The old site URLs were still being indexed, and Google treated the new PWA pages as duplicates. Without canonical signals, the wrong version ranked. Another case: a news PWA that served article content entirely via client-side JavaScript. Googlebot fetched the URL and saw only the shell. The site lost 90% of its search visibility. The fix was to pre-render the article HTML on the server for the first request. If you are building a single-page PWA, use history API (pushState) for routing, not hash fragments. Hash fragments are ignored by Google, so each route effectively points to the same URL. You also need a service worker cache strategy that does not serve stale [sitemap](/sitemap/) or HTML content to crawlers. I recommend cache-first for static assets but network-first for HTML. This ensures instant loading for users while keeping content fresh for Google. Finally, check [mobile-seo](/mobile-seo/) — a PWA must be responsive and pass mobile-friendly tests even if it looks app-like.

My biggest mistake with PWA SEO was prioritising speed over crawlability. I assumed that a fast, app-like experience would automatically rank well. It does not. On my first project, I used fragment-based routing (#/products) because it felt clean. Google indexed only the homepage — every product page was treated as the same URL. I had to rebuild the routing with pushState. That cost weeks of development. I also cached HTML in the service worker for 30 days, thinking it would boost performance. It did, but Googlebot kept seeing a version from three weeks ago, missing new products and price changes. Do not cache HTML for longer than a few minutes. I now use stale-while-revalidate with a 5-minute max-age for HTML. Another error: I blocked JavaScript in robots.txt to save crawling budget, not realising the PWA depended on that JS to render content. Pages disappeared from the index. I unblocked it after a [seo audit](/seo-audits/) revealed the problem. If I could start over, I would test each page with Google's URL Inspection tool before launching. PWAs are not a shortcut to rankings. They are a performance enhancement that must sit on top of solid [JavaScript SEO](/javascript-seo/) foundations.