Are AMP and PWA really useless for organic search?

Why does Google claim that AMP and PWA are not ranking factors?

The distinction is crucial: a ranking factor refers to a variable that Google’s algorithm directly uses to calculate a page's positioning. Signals like backlinks, content relevance, or loading speed fall into this category. AMP and PWA don’t function that way.

Google does not favor an AMP page over a classic HTML page if both deliver identical performance. The framework is just a technical means among others to achieve user experience goals. What truly matters are the Core Web Vitals, loading time, interactivity, and visual stability. AMP can help, but you are not obligated to use it if your site already meets these criteria.

What role does user experience play in this equation?

UX impacts rankings indirectly but tangibly. A site that loads quickly, doesn’t jolt users with moving elements, and allows for smooth navigation on mobile generates better behavioral signals. Users stay longer, click more, and return.

Google captures these signals and integrates them into its overall assessment. If AMP or PWA help you achieve these performances, that’s great. But if you achieve the same results with a well-optimized classic tech stack, you have no penalties to worry about. The choice of framework becomes a matter of engineering, not pure SEO.

In what cases do these technologies provide a concrete advantage?

AMP was designed for news and content sites where loading speed is critical. AMP pages load almost instantly thanks to preloading and strict framework limitations. On mobile, in challenging network conditions, this advantage remains real.

PWAs excel in a different context: that of web applications that need to function offline or provide a native-like experience. If your model relies on recurring visits, advanced features, or intensive mobile use, PWA makes perfect sense. But for a standard WordPress blog, the investment often isn't justified.

• AMP and PWA are not direct ranking factors in Google’s algorithm
• Their impact on SEO comes from improving user experience and Core Web Vitals
• A well-optimized classic HTML page can outperform a poorly designed AMP page
• The choice of these technologies should be based on a real needs analysis of the project, not on an SEO reflex
• UX gains must be measurable: loading time, bounce rate, engagement

Does this statement match what we observe in the field?

Yes, and the data confirms it. A/B tests conducted on news sites show that optimized HTML pages with a good CDN, smart lazy loading, and effective compression achieve equivalent positions to their AMP counterparts. Google has gradually removed the AMP badge from mobile SERPs, indicating that the shown preference is fading.

The confusion stems from the fact that AMP was long required to appear in the Top Stories carousel. This requirement has disappeared with the introduction of Core Web Vitals as eligibility criteria. Now, any fast page can claim that position. AMP is no longer a shortcut, just a method among others to reach performance thresholds.

What nuances should be added to this official position?

Google is technically correct, but the full story is more complex. While AMP and PWA are not direct factors, they can facilitate achieving criteria that are. For instance, a well-designed PWA improves Largest Contentful Paint and First Input Delay, both components of Core Web Vitals that genuinely influence rankings.

The trap is believing that adopting AMP or PWA is enough. I've seen sites switch to AMP without optimizing their images, third-party scripts, or HTML structure. The result: no visible improvement in SERPs, or even degradation if the AMP version is less rich in content or internal linking. Technology is just a tool, not a miracle solution.

Should you abandon AMP or PWA if you’ve already implemented them?

Not necessarily. If your AMP version is functioning well, generating traffic, and posing no maintenance issues, there’s no reason to remove it. However, if you find that the AMP version creates content duplicates, canonicalization issues, or conversion tracking difficulties, migrating to a well-optimized HTML version might be wise.

For PWAs, the question is different. If the application provides real added value to users (offline mode, relevant push notifications, smooth navigation), it justifies the investment. But if the PWA is just a showcase without recurring use, you can focus on the classic optimization of the site. [To be checked]: The actual impact of Service Workers on crawl budget remains debated; some SEOs report slowdowns in indexing new pages.

What should you concretely do with this information?

First, stop viewing AMP or PWA as boxes to check on an SEO checklist. Ask yourself the real question: does your site have measurable performance issues? Use PageSpeed Insights, Lighthouse, WebPageTest to gather real data. If your Core Web Vitals are already green, investing in AMP makes no sense.

If you have gaps, identify their origin. Is it slow servers, unoptimized images, blocking third-party scripts, poorly loaded CSS? In 90% of cases, these issues can be resolved with classic optimizations: compression, minification, CDN, lazy loading, preconnect. AMP or PWA only become relevant if you’re struggling with specific technical constraints or if your usage model justifies it.

What mistakes should be avoided when deploying these technologies?

The most common mistake: creating a diluted AMP version that does not include all contents, internal links, and structural elements from the main version. Google indexes both versions, and if the AMP version is less complete, you dilute your thematic authority. Worse, you create confusion for the algorithm, which no longer knows which version to prioritize.

Another common pitfall: implementing a PWA without a coherent caching strategy. Poorly configured Service Workers can serve outdated content, block the indexing of new pages, or create duplicate versions. Always test in a staging environment with Google Search Console tools and ensure that Googlebot accesses the canonical versions of your pages.

How can you measure the actual impact of these implementations on organic traffic?

Set up rigorous before/after tracking with Google Analytics and Search Console. Segment your data by device type (mobile/desktop), traffic source, and page. Monitor particularly the bounce rate, time spent on site, and number of pages per session. These behavioral metrics reveal if technical improvements translate into real UX gains.

Also compare your average positions on strategic queries before and after deployment. If you observe stagnation despite improved Core Web Vitals, it indicates that other factors (content, authority, search intent) are limiting your progress. AMP or PWA have never compensated for poor content or a nonexistent backlink strategy. These technical optimizations can prove complex to implement correctly, especially if they involve deep changes to the site’s architecture. Consulting a specialized SEO agency can help avoid costly mistakes and provide personalized support to evaluate the relevance of these technologies in your specific context.

• Audit Core Web Vitals with PageSpeed Insights and identify the real bottlenecks
• Compare the performance of AMP and classic HTML pages on similar content
• Ensure that the AMP version includes all structural elements (linking, structured data, complete content)
• Test Service Workers in staging to avoid indexing issues with PWAs
• Implement precise tracking to measure the impact on behavioral metrics
• Do not sacrifice content richness or the quality of internal linking for raw speed