PWA

A PWA is a website that you can install on your phone like a native app, but underneath it is still HTML, CSS and JavaScript. The SEO trap is that because PWAs rely on JavaScript to function, you can accidentally build a site that looks great in a browser but shows Googlebot a blank page. I would not call a site a PWA until I have verified that Google can render the content without the JavaScript execution – that means server-side rendering, pre-rendering, or at least a solid fallback. The progressive part means it should work as a normal website first, then enhance. If your site works without JavaScript for the initial load, you are half way there. Think of a hotel booking site where the search results page is generated client-side. The HTML Googlebot sees is just <div id="root"></div>. No hotel names, no prices. That page will not rank for anything. My rule: if you cannot make your site function without JavaScript for the first meaningful paint, you are not building a PWA – you are building an app that happens to live on the web.

A PWA makes sense when you have a high percentage of returning visitors on mobile who would benefit from offline access or push notifications. I worked on a travel booking site where installing the PWA increased return visits by 3.2 times. The offline caching of itinerary pages let users check booking details without a signal. But if your site is a blog with mostly one-time readers from social media, the PWA overhead – the manifest, the service worker, the JavaScript bundle – adds load time and dev cost with little return. There is also a geographic nuance: in markets with expensive or unreliable data, an offline-cached PWA can be a differentiator. The counter-argument is that a well-optimised responsive site can achieve similar load times without the complexity. I would only prioritise a PWA if you have at least 40% returning visitors and a use case for offline or native-like engagement. One edge case: Apple’s Safari still does not support push notifications from PWAs on iOS, so if your audience is iPhone-heavy, do not rely on that feature.

For the user, a PWA appears as an install prompt in the browser after certain criteria are met (a service worker, a manifest, HTTPS, and regular visits). Once installed, it opens in its own window without browser chrome. The manifest.json defines icons, the start URL, and the display mode. The service worker intercepts network requests and caches assets for offline use. For Google, it is still a web page. Googlebot uses a renderer that executes JavaScript, but it has limits: it will not wait indefinitely, and it often skips background tasks. If your service worker caches a loading screen as the first response, Googlebot will see that loading screen for every page. I test three URLs per page type using the URL Inspection Tool. If the rendered text is under 100 characters of actual content, I flag it as an indexing risk. Internal links must be real <a> tags with href attributes; click handlers on <div> elements break crawlability. For more detail on this, read my notes on [JavaScript SEO](/javascript-seo/).

The biggest tradeoff is between app-like experience and crawlability. Server-side rendering (SSR) solves indexing but adds server cost and complexity – every request requires Node.js processing. Pre-rendering is simpler: you generate static HTML at build time. But that breaks if your content changes frequently. I pre-rendered a news site once, but the cache was set to 24 hours; any breaking news was outdated after an hour. Dynamic rendering (serving pre-rendered content to Googlebot and client-side pages to users) seems like a middle ground, but it doubles your server cost and debugging effort. The service worker adds another layer of complexity: cache aggressively for offline users, but that same cache can serve stale content if you forget to version it. My decision rule: if content changes less than once a day, use pre-rendering. If it changes hourly, you need SSR or incremental static regeneration. If you cannot commit to any of these, stick with a regular responsive site and focus on [Core Web Vitals](/core-web-vitals/) instead. A PWA is not automatically better for SEO than a fast, mobile-friendly website.

My first PWA project was a recruitment site. I thought adding a manifest and a service worker made it a PWA. I used create-react-app with no pre-rendering. Googlebot got a shell with a loading spinner. It took me three weeks to realise that my beautiful offline-enabled app had zero organic traffic – every page returned the same empty <div>. I switched to pre-rendering with a static site generator, but then the offline caching broke because the pre-rendered files did not match the client-side routes. I ended up migrating to server-side rendering with Next.js. Another mistake: I set VERSION = '1.0' in the service worker cache key and forgot to increment it for weeks. Users and Googlebot saw stale job listings. I also assumed all browsers support all PWA features equally – Safari on iOS still does not support push notifications or background sync. Now I always run a quick [SEO audit](/seo-audit/) on the rendered output before celebrating any PWA launch.

If this is your problem today, [Technical SEO Audit Service](/technical-seo-audit-service/) and [Performance Optimisation](/performance-optimization/) are the notes I'd open next.