Official statement
Other statements from this video 49 ▾
- 1:38 Google suit-il vraiment les liens HTML masqués par du JavaScript ?
- 1:46 JavaScript peut-il masquer vos liens aux yeux de Google sans les détruire ?
- 3:43 Faut-il vraiment optimiser le premier lien d'une page pour le SEO ?
- 3:43 Google combine-t-il vraiment les signaux de plusieurs liens pointant vers la même page ?
- 5:20 Les liens site-wide dans le menu et le footer diluent-ils vraiment le PageRank de vos pages stratégiques ?
- 6:22 Faut-il vraiment nofollow les liens site-wide vers vos pages légales pour optimiser le PageRank ?
- 7:24 Faut-il vraiment garder le nofollow sur vos liens footer et pages de service ?
- 10:10 Search Console Insights sans Analytics : pourquoi Google rend-il impossible l'utilisation solo ?
- 11:08 Le nofollow influence-t-il encore le crawl sans transmettre de PageRank ?
- 11:08 Le nofollow bloque-t-il vraiment l'indexation ou Google crawle-t-il quand même ces URLs ?
- 13:50 Pourquoi Google refuse-t-il de communiquer sur tous ses incidents d'indexation ?
- 15:58 Faut-il vraiment indexer toutes les pages paginées pour optimiser son SEO ?
- 15:59 Faut-il vraiment indexer toutes les pages de pagination pour optimiser son SEO ?
- 19:53 Les paramètres d'URL sont-ils encore un problème pour le référencement naturel ?
- 19:53 Les paramètres d'URL sont-ils vraiment devenus un non-sujet SEO ?
- 21:50 Google bloque-t-il vraiment l'indexation des nouveaux sites ?
- 23:56 Les liens dans les tweets embarqués influencent-ils vraiment votre SEO ?
- 25:33 Les sitemaps sont-ils vraiment indispensables pour l'indexation Google ?
- 26:03 Comment Google découvre-t-il vraiment vos nouvelles URLs ?
- 27:28 Pourquoi Google impose-t-il un canonical sur TOUTES les pages AMP, même standalone ?
- 27:40 Le rel=canonical est-il vraiment obligatoire sur toutes les pages AMP, même standalone ?
- 28:09 Faut-il vraiment déployer hreflang sur l'intégralité d'un site multilingue ?
- 28:41 Faut-il vraiment implémenter hreflang sur toutes les pages d'un site multilingue ?
- 29:08 AMP est-il vraiment un facteur de vitesse pour Google ?
- 29:50 Pourquoi Google mesure-t-il les Core Web Vitals sur la version de page que vos visiteurs consultent réellement ?
- 30:20 Les Core Web Vitals mesurent-ils vraiment ce que vos utilisateurs voient ?
- 31:23 Faut-il manuellement désindexer les anciennes URLs de pagination après un changement d'architecture ?
- 31:23 Faut-il vraiment désindexer manuellement vos anciennes URLs de pagination ?
- 32:08 La pub sur votre site tue-t-elle votre SEO ?
- 32:48 La publicité sur un site nuit-elle vraiment au classement Google ?
- 34:47 Le rel=canonical en syndication est-il vraiment fiable pour contrôler l'indexation ?
- 34:47 Le rel=canonical protège-t-il vraiment votre contenu syndiqué du vol de ranking ?
- 38:14 Les alertes de sécurité dans Search Console bloquent-elles vraiment le crawl de Google ?
- 38:14 Un site hacké perd-il son crawl budget suite aux alertes de sécurité Google ?
- 39:20 Les liens dans les guest posts ont-ils vraiment perdu toute valeur SEO ?
- 39:20 Les liens issus de guest posts ont-ils vraiment une valeur SEO nulle ?
- 40:55 Pourquoi Google ignore-t-il les dates de modification identiques dans vos sitemaps ?
- 40:55 Pourquoi Google ignore-t-il les dates lastmod de votre sitemap XML ?
- 42:00 Faut-il vraiment mettre à jour la date lastmod du sitemap à chaque modification mineure ?
- 42:21 Un sitemap mal configuré réduit-il vraiment votre crawl budget ?
- 43:00 Un sitemap mal configuré peut-il vraiment réduire votre crawl budget ?
- 44:34 Faut-il vraiment choisir entre réduction du duplicate content et balises canonical ?
- 44:34 Faut-il vraiment éliminer tout le duplicate content ou miser sur le rel=canonical ?
- 45:10 Faut-il vraiment configurer la limite de crawl dans Search Console ?
- 45:40 Faut-il vraiment laisser Google décider de votre limite de crawl ?
- 47:08 Les redirections 301 en interne diluent-elles vraiment le PageRank ?
- 47:48 Les redirections 301 internes en cascade font-elles vraiment perdre du jus SEO ?
- 49:53 L'History API JavaScript peut-elle vraiment forcer Google à changer votre URL canonique ?
- 49:53 JavaScript et History API : Google peut-il vraiment traiter ces changements d'URL comme des redirections ?
Google confirms that AMP is not a prerequisite for ranking: only actual performance matters. An optimized non-AMP page can outperform a poorly designed AMP page. For SEOs, this means prioritizing Core Web Vitals and measurable performance metrics instead of getting locked into a specific technical format.
What you need to understand
Why does Google emphasize this distinction between format and performance?
For years, AMP was seen as a competitive advantage — notably for news sites that benefited from a dedicated carousel in mobile search results. Many practitioners invested in this technology thinking it offered an automatic ranking boost.
Let’s be honest: this belief was based on a misleading correlation. AMP pages were often faster, so they performed better. But it wasn’t the format that gave them an advantage — it was their loading time. Google makes it clear: an ultra-fast non-AMP page beats a slow AMP page.
What truly matters to the search engine?
Measured performance. Specifically, Google assesses metrics like Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). These indicators make up the Core Web Vitals, which are now integrated into ranking signals.
The issue with AMP is that it imposes a strict technical framework that limits functionality. Some sites found that their AMP pages were indeed fast, but too constrained to convert effectively. Others noticed that poorly optimized scripts in their AMP implementation could slow down rendering.
Does this render AMP obsolete?
Not necessarily. AMP remains a viable solution for news sites or high-traffic blogs that want to standardize performance without heavily investing in front-end optimization. But it’s no longer a mandatory passage.
What changes is the technical freedom. A skilled developer can achieve equivalent — or even superior — performance by optimizing a traditional stack: minifying JS, implementing smart lazy loading, configuring CDN properly, server caching, etc. And that's where many sites struggle: optimizing without AMP requires more skills.
- Speed is a confirmed ranking factor, not the AMP format itself.
- The Core Web Vitals are the determining metrics to evaluate performance.
- AMP can help, but it’s just one method among others to achieve a fast site.
- A well-optimized non-AMP page surpasses a poorly implemented AMP page.
- The choice between AMP and non-AMP should be based on available technical resources and business objectives.
SEO Expert opinion
Is this statement consistent with field observations?
Yes, and it closes a debate that has lingered for years. In practice, some e-commerce sites that abandoned AMP for an optimized stack (Next.js, Varnish caching, WebP images, etc.) maintained — or even improved — their positions. The opposite was rarer: a site switching to AMP without mastering the implementation often lost conversions.
The real problem is that many SEOs marketed AMP as a magical solution when it was a stopgap for poorly coded sites. Google sets the record straight: what matters is the performance measured by tools (PageSpeed Insights, Lighthouse, Search Console).
What nuances should be added to this position?
First, it is crucial to distinguish ranking from visibility in carousels. For a long time, the Top Stories carousel was reserved for AMP pages — this is no longer the case since the June 2021 update. Now, any page that meets the criteria for news content and Core Web Vitals can feature there. But be cautious: [To verify] some observers still report advantages for AMP in very competitive niches, though Google does not officially document this.
Next, there is the issue of the Google AMP cache. AMP pages hosted on Google’s cache benefit from pre-loading that drastically reduces perceived loading time for users. This is not a ranking factor, but it is a user experience advantage that can indirectly improve behavioral signals (bounce rate, time on site).
In what cases does this rule not apply completely?
If your site is a technical powerhouse with a dedicated team, you can forget AMP and directly optimize your pages. But if you manage a legacy CMS with spaghetti code built up over 10 years, AMP can be a pragmatic shortcut to avoid a complete overhaul.
There are also cases where AMP imposes constraints incompatible with your business model — typically, sites that monetize through heavy advertising scripts or complex third-party integrations. In these situations, favoring native performance is often more cost-effective, even if it requires a larger initial investment.
Practical impact and recommendations
What should you do if you are still using AMP?
Start by auditing the actual performance of your AMP pages versus your regular pages. Use PageSpeed Insights on a representative sample: if your non-AMP pages pass the Core Web Vitals, consider migrating. Otherwise, you risk a ranking regression.
If you decide to exit AMP, prepare a well-planned migration: properly configured 301 redirects, monitoring of Core Web Vitals post-migration, tracking positions in Search Console. And that's where many struggle: migrating without breaking SEO requires expertise.
What mistakes should you avoid in speed optimization?
First mistake: believing that a good Lighthouse score is enough. Google measures performance in real-world conditions (field data), not just in labs. A site can have a score of 95/100 on Lighthouse while having catastrophic Core Web Vitals on mobile 3G. Always check field data in Search Console.
Second mistake: optimizing speed at the cost of conversion. Removing all scripts to gain 0.3 seconds on LCP, then losing 20% of conversions because support chat or behavioral tracking no longer functions, is counterproductive. Finding the balance is tricky.
How can you ensure your site remains performant without AMP?
Implement continuous monitoring of Core Web Vitals. Tools like Crux API, Real User Monitoring (RUM), or solutions like SpeedCurve allow you to detect regressions before they impact ranking. Don't rely solely on one-off tests.
Then, apply classic front-end optimizations: lazy loading of images, JS/CSS minification, Brotli compression, HTTP/2 or HTTP/3, well-configured CDN, aggressive browser caching. It's basic, but poorly executed, it can ruin performance. For many sites, these optimizations require precise technical support — and that’s where a specialized SEO agency can make a difference by combining SEO expertise and development skills to deliver measurable gains without compromising business objectives.
- Audit the actual performance (field data) of your AMP and non-AMP pages
- Ensure your non-AMP pages pass the Core Web Vitals before any migration
- Set up clean 301 redirects if you abandon AMP
- Continuously monitor Core Web Vitals metrics post-migration
- Optimize the front-end: lazy loading, minification, CDN, caching
- Balance speed and business functionalities (conversion, tracking)
❓ Frequently Asked Questions
Est-ce que je perds du ranking si je désactive AMP sur mon site ?
AMP donne-t-il encore un avantage pour apparaître dans le carrousel Top Stories ?
Quels sites devraient encore utiliser AMP ?
Comment savoir si mes pages non-AMP sont assez rapides ?
Peut-on avoir une page AMP plus lente qu'une page classique ?
🎥 From the same video 49
Other SEO insights extracted from this same Google Search Central video · duration 55 min · published on 21/08/2020
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.