Official statement
Other statements from this video 14 ▾
- 34:02 Le contenu de qualité suffit-il vraiment pour ranker localement ?
- 90:21 Google My Business est-il vraiment indispensable pour le référencement local ?
- 98:11 Pourquoi les nouveaux sites locaux ne peuvent-ils pas viser les requêtes nationales d'emblée ?
- 125:05 Faut-il abandonner le link building au profit des « actions remarquables » ?
- 154:17 Google ajuste-t-il vraiment ses algorithmes contre les SEO ?
- 182:56 Le PageRank fonctionne-t-il vraiment encore comme en 1998 ?
- 189:58 Faut-il vraiment abandonner le dynamic rendering pour le SSR ?
- 236:46 Le server-side rendering est-il vraiment indispensable pour votre SEO ?
- 251:06 JavaScript est-il vraiment le pire ennemi des Core Web Vitals ?
- 305:31 Pénalité manuelle vs déclassement algorithmique : quelle différence pour votre site ?
- 333:40 Le contenu dupliqué tue-t-il vraiment votre référencement ou suffit-il d'ajouter quelques paragraphes uniques ?
- 401:29 Faut-il vraiment optimiser la longueur des balises title pour Google ?
- 419:13 Les PWA ont-elles vraiment un impact SEO ou est-ce juste un mythe technique ?
- 492:07 Faut-il vraiment limiter les scripts tiers pour améliorer son SEO ?
Martin Splitt states that an invalid AMP page causes more issues than it provides benefits — it's better to fix it or delete it. For SEO, this means that a shaky AMP implementation can negatively affect crawling, indexing, and user experience. Specifically: audit your AMP errors in Search Console and act quickly, as Google no longer tolerates rough implementations.
What you need to understand
Why is Google so strict about broken AMP pages?<\/h3>
Google has long promoted AMP (Accelerated Mobile Pages)<\/strong> as a mobile performance lever, especially with the Top Stories carousel and priority eligibility in some search results. However, a poorly implemented AMP page — invalid HTML code, missing tags, blocked resources — generates validation errors in Search Console.<\/p> These errors are significant. They fragment your crawl budget<\/strong>, create canonicalization conflicts between the AMP version and the standard version, and can even lead to partial de-indexing if Google fails to interpret the content. Splitt's message is clear: if you can't maintain a valid AMP page, you're losing more than you're gaining.<\/strong><\/p> An invalid AMP page can lead to several adverse effects. First, it wastes crawl budget — Googlebot tries to validate it, fails, comes back later, and so on. Then, it pollutes your structured data<\/strong>: if you use Schema.org on the AMP side and the page is malformed, Google may ignore these signals.<\/p> Finally, and this is the most insidious point: a broken AMP page may remain indexed in cache but no longer receive AMP's priority processing. The result? You think you have a functioning AMP version, but Google treats it like a standard mobile page — without the benefits of speed or display. It's a technical facade that dilutes your SEO efforts<\/strong> without you realizing it immediately.<\/p> Search Console remains your best ally: go to the “Experience” > “AMP”<\/strong> section to identify validation errors. Google classifies these errors by type: prohibited tags, missing attributes, non-HTTPS resources, blocked scripts, etc. Each error comes with the affected URL and an excerpt of the problematic code.<\/p> But be careful: not all errors are equal. An <img><\/strong> tag that is not AMP (instead of <amp-img><\/strong>) blocks complete validation, while a missing tracking attribute might go unnoticed in production. The official AMP testing tool (validator.ampproject.org) allows you to check in real-time whether a page complies with AMP HTML specs — it's essential before each deployment.<\/p>What are the real risks of a broken AMP page?<\/h3>
How can you tell if your AMP pages are actually broken?<\/h3>
SEO Expert opinion
Is this statement consistent with practices observed in the field?<\/h3>
Yes, and it is indeed a firmer stance than what Google claimed a few years back. At the time of AMP's launch, Google was tolerant of rough implementations — as long as the page loaded quickly, minor validation errors were overlooked. Since Core Web Vitals<\/strong> became a ranking factor and AMP is no longer mandatory for Top Stories, Google has tightened its approach.<\/p> Recent audits show that invalid AMP pages remain indexed but no longer enjoy any boost. Worse: they can generate soft 404s<\/strong> in some cases, as the broken AMP content may return empty or partial content. Splitt's recommendation reflects this reality: If you can't ensure AMP compliance, cleanly abandon it.<\/strong><\/p> First, not all AMP errors warrant immediate removal. A tracking error or a malformed Schema.org tag on the AMP side does not prevent strict HTML validation — and can be corrected without major impact. Conversely, a structural error (prohibited tag, missing attribute on <amp-img><\/strong>) blocks validation and requires swift action.<\/p> Furthermore, removing AMP should be accompanied by a 301 redirect<\/strong> to the standard version and an update of the canonical tagging. If you remove AMP without redirecting, you create massive 404s on the indexed AMP URLs, which fragments your crawl and may temporarily lower your visibility. [To check]<\/strong>: Google has never released numerical data on the exact SEO impact of migrating from AMP to non-AMP — real-world feedback varies depending on the quality of the standard version and the site's crawl history.<\/p> If you're in a sector where the Top Stories carousel or Google Discover generates a significant share of your traffic and your AMP version is technically valid but has tracking or Schema.org errors, it may be wise to fix rather than delete<\/strong>. AMP remains a visibility lever in certain editorial contexts, notably news and highly viral visual content.<\/p> However, if your standard version shows green Core Web Vitals and your AMP is not bringing measurable traffic, removal is the most rational decision. Keep in mind that maintaining AMP requires ongoing technical monitoring — each update of the CMS, theme, or scripts can break validation. If you don’t have the resources to keep up, it’s best not to play with AMP.<\/strong><\/p>What nuances should be applied to this directive?<\/h3>
In what cases does this rule not completely apply?<\/h3>
Practical impact and recommendations
What should you concretely do if you have broken AMP pages?<\/h3>
Start with a complete audit in Search Console<\/strong>: section “Experience” > “AMP”. Identify errors by type and by volume of affected URLs. Prioritize blocking errors (prohibited tags, missing attributes) that prevent strict HTML validation — they're the ones that harm crawling and indexing the most.<\/p> Then, decide whether you want to fix or delete<\/strong>. If your AMP pages generate measurable traffic from Discover or Top Stories, and the errors are correctable (malformed tags, non-HTTPS resources), invest in fixing them. If AMP brings you nothing and your standard version is performing well, delete the AMP pages and redirect them in 301 to the standard URLs.<\/p> Never delete AMP URLs without a 301 redirect — this is the classic mistake that causes massive 404s<\/strong> on indexed URLs and drops organic traffic. Update the <link rel="amphtml"><\/strong> tagging on the standard version so that it no longer points to a non-existent AMP page, and ensure that the AMP canonical tag correctly points to the standard version.<\/p> Another pitfall: forgetting to submit a new XML sitemap after removing AMP. Google continues to crawl the old AMP URLs if they remain listed in the sitemap, which wastes crawl budget. Finally, if you decide to fix AMP, test each page with the official validator<\/strong> before putting it back into production — an undetected validation error during dev can propagate to thousands of pages.<\/p> Monitor Search Console for 2-3 weeks after migration: AMP errors should gradually disappear, and the 404s on the old AMP URLs should be accompanied by valid 301 redirects. Also check that your organic traffic from mobile<\/strong> remains stable or increases — a sharp drop may indicate a redirection or canonical tagging issue.<\/p> Use Google Analytics to compare traffic before/after on the affected URLs. If you notice a drop in traffic from Discover or Top Stories, it means your standard version isn’t compensating for the benefits of AMP in those placements — and it might have been better to fix than remove.<\/p>What errors should you absolutely avoid during an AMP migration or deletion?<\/h3>
How can you verify that the transition went smoothly?<\/h3>
<link rel="amphtml"><\/code> tagging.<\/li>
❓ Frequently Asked Questions
Dois-je absolument supprimer mes pages AMP si elles présentent des erreurs mineures ?
Que se passe-t-il si je supprime AMP sans redirection 301 ?
AMP reste-t-il un facteur de classement en SEO mobile ?
Comment savoir si mes pages AMP génèrent vraiment du trafic ?
Peut-on corriger les erreurs AMP directement dans la Search Console ?
🎥 From the same video 14
Other SEO insights extracted from this same Google Search Central video · duration 559h09 · published on 25/03/2021
🎥 Watch the full video on YouTube →Related statements
Get real-time analysis of the latest Google SEO declarations
Be the first to know every time a new official Google statement drops — with full expert analysis.
💬 Comments (0)
Be the first to comment.