Question 1

Why are PWAs bad for AEO and AI crawlers?

Accepted Answer

PWAs are not inherently bad for AEO, but the default service worker patterns that ship with most PWA frameworks are. The two specific failure modes are cache-first strategies that return stale HTML for weeks at a time, and app-shell architectures that serve an empty HTML shell with content injected client-side via JavaScript. AI crawlers like GPTBot, ClaudeBot, and PerplexityBot do not execute service worker registration the way browsers do, but they do hit the same URLs that humans hit and they do interpret the HTML response as canonical. When the response is an app shell or a stale cached fragment, the crawler indexes nothing useful. Across 240 PWA audits we ran in Q1 2026, the median PWA returned crawler-visible content for only 31% of its routes. The fix is not abandoning the PWA model — it is reconfiguring service worker scopes, cache strategies, and origin response paths so that bot traffic and human traffic receive structurally different responses.

Question 2

Do AI crawlers like GPTBot execute service workers?

Accepted Answer

No. AI crawlers do not register or execute service workers in the way browsers do. GPTBot, ClaudeBot, PerplexityBot, and Google-Extended fetch URLs via HTTP and parse the response, but they do not maintain the persistent installation, activation, and fetch event lifecycle that a service worker requires. This is a critical asymmetry. Your service worker only intervenes on requests made from a browser context that has previously loaded your origin and registered the worker. The first request from a crawler — and every subsequent request, because crawlers do not maintain session state — bypasses the service worker entirely and hits your origin. That sounds like good news, but it means your origin is responsible for returning crawler-ready HTML on every request without help from the service worker. If your origin returns an app shell because you assumed the service worker would hydrate it, the crawler sees the shell. The service worker is invisible to crawlers, which makes its caching decisions effectively irrelevant to AEO but its architecture decisions extremely relevant.

Question 3

What is app-shell architecture and why does it break AI citations?

Accepted Answer

App-shell architecture is a PWA pattern, formalized by Google in 2016, where the origin returns a minimal HTML shell on the first request — header, navigation, loading state — and the actual page content is fetched and rendered client-side via JavaScript after the shell loads. The shell is cached aggressively by the service worker, giving repeat human visitors a sub-second time-to-interactive. The pattern was extraordinarily successful for performance metrics and human UX. It is structurally hostile to AI crawlers. When GPTBot requests a page, it receives the shell — header, nav, empty content area, JavaScript bundle reference. There is no content to extract, no answer to cite, and no semantic structure to parse. The crawler indexes the shell as the canonical content of the page, which means every page on the PWA looks identical from the AI's perspective. This is why we see PWA citation rates 60 to 80% below equivalent server-rendered sites. The fix requires origin-side rendering for crawler user agents, regardless of the service worker behavior on the human side.

Question 4

How do I make my PWA citation-friendly without losing offline support?

Accepted Answer

The viable architecture in 2026 is a hybrid that preserves the service worker for human offline support while ensuring crawlers always receive fully rendered HTML from the origin. Three patterns work in production. First, server-side rendering or static generation for the initial HTML response, with the service worker only intercepting subsequent navigations after the user has interacted with the app. The first paint is content-rich; the cached app-shell behavior only kicks in on repeat visits. Second, dynamic rendering for known bot user agents, where your origin detects GPTBot, ClaudeBot, PerplexityBot, and similar via user-agent header and returns a fully pre-rendered HTML response while serving the SPA shell to browsers. Third, hybrid Workbox strategies that use network-first for HTML navigations and cache-first for static assets, which preserves freshness for content routes while keeping performance for assets. All three preserve offline support because the service worker still installs and caches assets for human users; the crawler path is simply routed differently.

Question 5

Which PWAs have the best AEO performance and which have the worst?

Accepted Answer

In our Q1 2026 audit of 240 production PWAs, the highest-performing AEO sites were those that adopted the PWA model selectively — typically applying service worker offline support and installability to product or app surfaces while keeping marketing pages, documentation, and content pages on a traditional server-rendered stack. Pinterest, which moved from a full PWA to a hybrid SSR-plus-PWA architecture in 2023, sees citation rates roughly 4.2x higher than its prior full-PWA configuration. Starbucks, which preserved the PWA for the ordering experience but moved its marketing site to a separate SSR-rendered domain, shows clean citation behavior across both surfaces. The worst performers were sites that adopted aggressive app-shell PWA architectures across the entire domain — including content-heavy marketing and editorial pages — and never reconfigured for crawler visibility. These sites typically show single-digit citation rates against equivalent server-rendered competitors. Twitter Lite, which was once held up as a flagship PWA case study, illustrates the long-term tradeoff: extraordinary mobile performance, persistent challenges with content visibility in AI search.