Should you choose AMP or PWA to maximize your SEO performance?

Why does Google oppose these two technologies despite their frequent coexistence?

The statement by John Mueller draws a clear line between two technical approaches that address different issues. AMP (Accelerated Mobile Pages) focuses exclusively on the content display speed — an ultra-constrained framework that eliminates anything that slows down the initial rendering.

Progressive Web Apps, on the other hand, emphasize functional richness: offline capabilities via Service Workers, home screen installation, push notifications, background synchronization. Two opposing philosophies that reflect two models of web usage.

What is the concrete difference in terms of technical architecture?

AMP enforces a restricted HTML, with CSS limited to 50KB inline, and JavaScript only through validated components. This rigidity ensures predictable performance — Google can pre-load AMP pages from its cache with nearly zero latency.

A PWA relies on a Service Worker that intercepts network requests to serve cached content. The architecture remains flexible: React, Vue, vanilla JS, it doesn't matter. Complexity increases proportionally with features — a multi-step form with client-side validation will be trivial in PWA but nightmarish in AMP.

How does this distinction impact Google's behavior towards these contents?

Historically, AMP received preferential treatment in mobile Top Stories carousels. Google officially removed this boost in 2021, but AMP pages still retain a mechanical advantage: pre-loading from Google's cache drastically reduces Time to First Byte.

For PWAs, there is no special ranking treatment. Google crawls and indexes just like any other page, with particular attention to Core Web Vitals — where a well-optimized PWA can outperform due to application caching and progressive loading.

• AMP favors editorial content: articles, news, recipes, simple product sheets
• PWA excels in complex journeys: configurators, dashboards, business applications
• Technical SEO diverges radically: strict canonicalization in AMP, Service Worker cache management in PWA
• Performance metrics oppose: ultra-low FCP/LCP in AMP, critical TTI/TBT in PWA
• Maintenance effort differs: double publication in AMP (canonical + AMP version), single codebase in PWA

Does this binary opposition reflect the reality on the ground?

The dichotomy presented by Mueller simplifies the issue drastically. In practice, we observe AMP+PWA hybrids on major media sites — AMP article pages for cold traffic, and subsequent navigation in PWA for retention. This isn't an exclusive choice, it's a layered optimization strategy.

Another point Google avoids: AMP has lost some of its luster since 2021. The removal of the AMP badge from SERPs and the end of the Top Stories privilege broke the network effect. Many media outlets abandoned AMP — the technical ROI (maintaining two versions) no longer justified traffic gains.

What are the unspoken limitations of each approach?

AMP blocks dozens of use cases: advanced analytics tracking, sophisticated A/B testing, dynamic paywalls, social logins, third-party widgets. Each workaround requires an amp-custom component that burdens the stack. [To be verified]: Google claims that AMP covers "content publishing," but never quantifies the proportion of content actually compatible without compromise.

On the PWA side, the deadlock lies elsewhere: the Service Worker introduces cache complexity that can generate nasty bugs (outdated content served indefinitely, desynchronization between cache and server). And contrary to the myth, a poorly optimized PWA will be slower than a well-built traditional site — the overhead of JavaScript is real.

In what contexts does this recommendation become counterproductive?

If your e-commerce site generates 80% of its revenue from 5+ page journeys with filters, comparators, and checkout tunnels, AMP is out of the question from the start. Conversely, a niche blog with zero interaction (no comments, no dynamic newsletter) objectively has no need for a PWA — a statically generated site (Hugo, Jekyll) with aggressive CDN caching will perform better.

The real issue that Mueller doesn't address: what is your primary traffic source? If it's Google Discover or Top Stories, AMP retains tactical interest. If it's direct or social traffic with strong recurrence, PWA becomes strategic to encourage installation and notifications. The choice is economic before it's technical.

How should you technically arbitrate between AMP and PWA for a real project?

Start by auditing your dominant user journeys. If 70%+ of your sessions are single-page (reading an article then bouncing), AMP might still make sense — especially if you aim for Google features like Top Stories or Discover. Analyze your GA4 data: session duration, pages per session, return rate at 7 days.

Next, measure the actual performance gap. Run Lighthouse on your strategic pages: if your LCP is already under 2.5s and your CLS under 0.1, AMP's contribution will be marginal. If you're at 4s+ LCP, AMP could divide that figure by two — but optimizing your current site (lazy loading, compression, CDN) could yield the same result without the technical debt.

What implementation mistakes should absolutely be avoided?

A classic error in AMP: publishing a stripped-down AMP version that breaks the experience (missing images, absent CTAs, truncated content). Google crawls both versions — if the AMP version is objectively degraded, you risk cannibalizing your mobile conversion rate. Functional parity is non-negotiable.

On the PWA side, the recurring trap: a poorly configured Service Worker that aggressively caches dynamic content. Result: your users see outdated prices, incorrect stock, unpublished items. Implement a granular cache strategy (network-first for APIs, cache-first for assets) and rigorously test update scenarios.

What roadmap should be adopted if you want to cover both approaches?

If your resources allow it, the strategy of AMP for acquisition + PWA for retention remains the most robust. Serve an AMP version on the first hit (URLs in /amp/ with canonical to the standard version), then progressively load PWA capabilities (Service Worker, manifest) after the second page view.

Concretely: a media outlet can serve its articles in AMP to capture Google traffic, then silently install the Service Worker and offer the home screen addition after 2-3 pages viewed. This is what The Washington Post does — AMP on articles, PWA on navigation. But beware: this hybrid stack requires a solid tech team and close monitoring.

• Map your content typologies (static editorial vs. interactive interfaces)
• Benchmark your current Core Web Vitals on strategic pages
• If LCP > 3s or CLS > 0.15, AMP could be a quick win on editorial content
• If your model relies on engagement/recurrence, prioritize PWA with a notification strategy
• Test in A/B on a subset of URLs before deploying massively
• Monitor business metrics (conversion rate, ad RPM) — technical performance is just a proxy