Are Progressive Web Apps really indexable by Google?

Why does Google still mention 'steps to follow' if JavaScript rendering is resolved?

Because Googlebot's JavaScript rendering works, but with technical limits that Google doesn't shout about. The bot uses a version of Chrome to execute JS, which implies a processing delay between raw HTML crawling and final rendering.

This delay can extend to several days on certain sites, especially those with low crawl budgets. For a PWA generating its content dynamically on the client side, this means Google first sees an empty shell and then comes back later for the full rendering. In the meantime, no indexing of actual content.

What can block a PWA's indexing despite JavaScript rendering?

Service workers pose specific issues. They intercept network requests to cache, but if misconfigured, they can serve Googlebot outdated content or offline pages when the bot expects fresh content.

Modern frameworks (React, Vue, Angular) often use client-side routing that does not generate real crawlable URLs. Google can theoretically handle client-side routing, but in practice, ranking signals are weaker than with classic server-side URLs.

Aggressive lazy loading remains a classic pitfall: if content only loads on scroll or user interaction, Googlebot likely won't see it, even with JavaScript rendering enabled.

How can you check if Google is truly indexing your PWA's content?

The Search Console is not enough. The URL Inspection tool shows the final rendering, but not always what is actually indexed. It is necessary to cross-check with targeted site: queries and verify that dynamic content appears in the snippets.

A simple test: disable server-side JavaScript and see what a curl or wget returns. If the page is empty or nearly empty, you have a problem. Google can compensate, but why take the risk?

• JavaScript rendering works, but introduces a delay between crawling and indexing that can kill content freshness.
• Misconfigured service workers can serve outdated or offline content to Googlebot.
• Client-side routing weakens ranking signals compared to classic server URLs.
• Lazy loading on scroll or interaction remains invisible to Googlebot even with JS enabled.
• The Search Console inspection tool shows rendering, not necessarily what is actually indexed.

Is this statement consistent with on-the-ground observations?

Yes and no. Google has indeed made progress on JavaScript rendering, but Mueller remains vague about specific limitations. In practice, sites that have migrated to full client-side PWA architectures often report organic traffic drops of 20-40% within the first six months.

Why? Because the rendering delay disrupts indexing responsiveness. An article published at 8 AM may not be crawled-rendered-indexed for 48-72 hours. In news or trending topics, you're already out of the game. Google never clearly states that JS introduces this lag, but it's observable across all large JS-heavy sites.

What nuances should we add to this official position?

Mueller says, 'there are still steps to follow' without specifying which ones. This is typical of Google's discourse: acknowledging a problem without giving the keys. [To verify]: Google publishes no metrics on the failure rate of JavaScript rendering. How many pages fail? What JS patterns break the bot? No data.

PWAs with pre-rendering or SSR (server-side rendering) fare much better. Next.js, Nuxt.js, and other frameworks that generate HTML on the server side and then hydrate on the client avoid all these pitfalls. If you go full client-side, you're taking an unquantified risk.

Another point that is never mentioned: the Core Web Vitals of PWAs. Heavy JS often degrades LCP and CLS. Google says it indexes PWAs, but if your metrics are poor, you won't rank anyway.

In what cases does this rule not apply?

If your PWA is a private application (intranet, client space), Google indexing is not the issue. However, for a public site that wants organic traffic, ignoring SSR or pre-rendering is akin to shooting yourself in the foot.

Sites with very high crawl budgets (Amazon, Wikipedia) can afford heavy JS: Google will crawl and render often enough to compensate for the lag. For a typical site with 1000-5000 pages and a limited crawl budget, it's suicidal.

What should be done concretely for an indexable PWA?

First, implement server-side rendering (SSR) or pre-rendering using solutions like Rendertron, Prerender.io, or native frameworks (Next.js, Nuxt). This generates complete HTML on the server side, immediately visible to Googlebot without waiting for JS rendering.

Next, configure the service workers so that they do not hide actively crawled pages. Use selective caching strategies: network-first for fresh content, cache-first only for static assets. Check in server logs that Googlebot is receiving fresh content, not outdated cache.

What mistakes should be avoided when deploying a PWA?

Never launch a PWA with pure client-side rendering without testing indexing on a subset of pages in staging. Too many developers think that 'Google says it handles JS' = complete green light. No. Test, measure, check in the Search Console.

Avoid lazy loading on everything. Load at least above-the-fold content and critical elements (titles, first paragraphs, main images) synchronously. The rest can be lazy-loaded, but with fallbacks visible to bots.

Don't forget about dynamic sitemaps. A PWA often generates URLs on the fly; ensure your XML sitemap reflects all accessible routes and is updated in real-time or near real-time.

How to check if your PWA is correctly indexed?

Use the URL inspection tool in the Search Console on a representative sample of pages. Compare the raw HTML (under 'More Info' > 'View Crawled Page') with the final rendering. If critical content only appears in the rendering, you depend on JS, thus on Google's goodwill.

Run JavaScript crawls with Screaming Frog or OnCrawl with rendering enabled. Compare with a classic crawl without JS: the gap will reveal how much content is invisible without rendering. If the gap exceeds 30%, you have a significant risk of partial indexing.

• Implement SSR or pre-rendering using Next.js, Nuxt.js, or Rendertron to serve complete HTML on the server side.
• Configure service workers in network-first mode for dynamic content, cache-first only for static assets.
• Load above-the-fold and critical content synchronously, without waiting for user interactions.
• Generate dynamic XML sitemaps reflecting all accessible routes of the PWA, updated in real-time.
• Test extensively in staging with the Search Console inspection tool and JS crawls (Screaming Frog, OnCrawl).
• Monitor Core Web Vitals (LCP, CLS, INP) since heavy JS can harm your ranking even if indexing works.