Official statement
Other statements from this video 39 ▾
- □ La suppression de liens peut-elle déclencher une pénalité Google ?
- □ Faut-il vraiment nettoyer vos liens artificiels si Google les ignore déjà ?
- □ Les liens sont-ils vraiment en train de perdre leur pouvoir de classement sur Google ?
- □ Les backlinks perdent-ils leur importance une fois un site établi ?
- □ Faut-il vraiment bannir tout échange de valeur contre un lien ?
- □ Les collaborations éditoriales avec backlinks sont-elles vraiment sans risque selon Google ?
- □ Faut-il vraiment arrêter toute tactique de liens répétée à grande échelle ?
- □ Les actions manuelles Google sont-elles toujours visibles dans Search Console ?
- □ Un domaine spam inactif depuis longtemps retrouve-t-il automatiquement sa réputation ?
- □ Les pages AMP doivent-elles vraiment respecter les mêmes seuils Core Web Vitals que les pages HTML classiques ?
- □ Faut-il mettre à jour la date de publication après chaque petite modification d'une page ?
- □ Les sitemaps News accélérent-ils vraiment l'indexation de vos actualités ?
- □ Les balises canonical auto-référencées suffisent-elles vraiment à protéger votre site des duplications d'URL ?
- □ Faut-il vraiment abandonner les balises rel=next et rel=prev pour la pagination ?
- □ Le nombre de mots est-il vraiment un critère de classement Google ?
- □ Les sites générés par base de données peuvent-ils encore ranker en croisant automatiquement des données ?
- □ Les redirections 302 de longue durée sont-elles vraiment équivalentes aux 301 pour le SEO ?
- □ Combien de temps un 503 peut-il rester actif sans risquer la désindexation ?
- □ Pourquoi faut-il vraiment 3 à 4 mois pour qu'un site refonte soit reconnu par Google ?
- □ Les URLs mobiles séparées (m.example.com) sont-elles toujours une option viable en SEO ?
- □ Faut-il vraiment craindre de supprimer massivement des backlinks après une pénalité manuelle ?
- □ Les backlinks sont-ils devenus un facteur de ranking secondaire ?
- □ Faut-il vraiment attendre que les liens arrivent « naturellement » ou prendre les devants ?
- □ Qu'est-ce qu'un lien naturel selon Google et comment éviter les pratiques à risque ?
- □ Faut-il nofollowtiser tous les liens éditoriaux issus de collaborations avec des experts ?
- □ Les pénalités manuelles Google : êtes-vous vraiment sûr de ne pas en avoir ?
- □ Un passé spam efface-t-il vraiment son empreinte SEO après une décennie ?
- □ Les pages AMP gardent-elles un avantage concurrentiel face aux Core Web Vitals ?
- □ Faut-il vraiment mettre à jour la date de publication d'une page pour améliorer son classement ?
- □ Les sitemaps News accélèrent-ils vraiment l'indexation de votre contenu ?
- □ Pourquoi votre site oscille-t-il entre la page 1 et la page 5 des résultats Google ?
- □ Le balisage fact-check améliore-t-il vraiment le classement de vos pages ?
- □ Faut-il vraiment ajouter une balise canonical auto-référentielle sur chaque page ?
- □ Faut-il encore utiliser les balises rel=next et rel=previous pour la pagination ?
- □ Le nombre de mots est-il vraiment sans importance pour le classement Google ?
- □ Les sites générés par bases de données peuvent-ils vraiment ranker sur Google ?
- □ Faut-il vraiment abandonner les URLs mobiles séparées (m.example.com) ?
- □ Faut-il vraiment se préoccuper de la différence entre redirections 301 et 302 ?
- □ Combien de temps peut-on garder un code 503 sans risquer la désindexation ?
Google confirms that AMP is not mandatory for appearing in Discover. Regular HTML pages can also access it without any issues. The only difference lies in the default size of the thumbnails, but standard pages can achieve the same dimensions using the meta robots max-image-preview tag. A simple adjustment that levels the playing field between AMP and traditional HTML.
What you need to understand
Was AMP really a requirement for Discover? <\/h3>\n\n
For a long time, confusion reigned on this point. Many SEO professionals believed — or feared — that AMP was a prerequisite for appearing in the Discover feed. This belief was based on empirical observations: AMP sites seemed overrepresented in this channel.
\n\nMueller puts an end to this misconception. Discover accepts regular web pages, period. The myth of an algorithmic preference for AMP in this specific context was never officially founded. What actually mattered was the quality of the content, user engagement, and relevance to interests.
\n\nWhy the confusion with thumbnails? <\/h3>\n\n
The misunderstanding stems from the thumbnail size. AMP pages benefited by default from larger thumbnails in Discover, which mechanically generated more clicks and visibility. This visual advantage was mistakenly interpreted as algorithmic favoritism.
\n\nHowever, Google has long offered the meta robots max-image-preview:large tag. It allows standard HTML pages to display exactly the same thumbnail sizes as AMP. In practical terms? A single line of code is enough to equalize display conditions. No need to overhaul an entire technical architecture.
\n\nWhat is the true hierarchy of criteria for Discover? <\/h3>\n\n
Discover operates on a model of interest-based personalization. The algorithm analyzes browsing history, past interactions, and contextual relevance signals. Loading speed matters, but it's just one factor among many — and AMP is merely one way to optimize this speed.
\n\nWhat truly matters: the quality of visual content, the freshness of information, measured engagement (click rates, time spent), and thematic coherence with user preferences. AMP can facilitate some of these criteria, but does not replace them. A fast, well-structured HTML page with quality images has every chance.
\n\n- \n
- AMP is not a prerequisite to appear in Discover — standard HTML pages access it without restriction \n
- The max-image-preview:large tag equalizes thumbnail sizes between AMP and non-AMP, neutralizing the historical visual advantage of AMP \n
- The real selection criteria remain content relevance, user engagement, and quality of experience, not the technical format \n
- Sites that invested in AMP solely for Discover may reconsider this strategy if maintenance becomes burdensome \n
- Optimizing images, speed, and structured data remains more critical than the choice between AMP and standard HTML \n
SEO Expert opinion
Is this statement consistent with real-world observations? <\/h3>\n\n
Yes and no. On paper, Mueller is right: technically, Google does not require AMP for Discover. But in practice, for years, AMP sites have dominated this channel overwhelmingly. Coincidence? Not really. AMP brought a set of optimizations — speed, optimized images, structured data — that maximized the chances of being picked.
\n\nLet's be honest: Google never stated that AMP was mandatory, but the ecosystem operated as if it were. The arrival of the max-image-preview tag changed the game, but many sites are still unaware of its existence. The result: AMP continues to benefit from a default advantage, even if it is no longer technically justified.
\n\nWhat nuances should be added to this assertion? <\/h3>\n\n
First point: saying that AMP is not required does not mean it is useless. If your tech stack is slow, your HTML is heavy, and your images are weighing in megabytes, AMP remains a shortcut to performance. It’s a constraining framework, but effective in enforcing good practices.
\n\nSecond nuance: the max-image-preview tag only addresses a part of the problem — the thumbnail size. It does not compensate for a slow page, an overloaded DOM, or poor structured data. If your standard HTML is shaky, adding this meta tag won’t suffice to compete with a well-structured AMP. [To be checked]: Mueller does not specify whether other technical criteria still implicitly favor AMP in Discover's selection algorithm.
\n\nIn what cases does this rule not apply? <\/h3>\n\n
If you are a media publisher with a massive content volume and a dominant mobile audience, AMP may still make sense — not specifically for Discover, but for your entire ecosystem (Google cache, guaranteed speed, integration with certain ad platforms).
\n\nOn the other hand, for an e-commerce site, a corporate blog, or a niche site with low volume, maintaining two versions (AMP + HTML) quickly becomes a burden. Mueller's statement opens the door for simplification: focus on a single ultra-optimized HTML version, and you'll have the same chances in Discover. But beware — this assumes your HTML is truly top-notch. No compromises on speed or mobile-first.
\n\nPractical impact and recommendations
What should I do concretely if my site uses AMP? <\/h3>\n\n
First step: evaluate the maintenance cost of AMP against the real benefit. If you find that Discover generates little traffic, or that your standard HTML is already fast (Core Web Vitals in the green), AMP becomes unnecessary. You can then consider a gradual migration to optimized standard HTML.
\n\nIf you decide to abandon AMP, make sure your standard HTML incorporates all the technical signals that AMP brought automatically: structured data tags (JSON-LD), optimized images (WebP, lazy loading), loading speed under 2.5 seconds on mobile, and of course the famous meta max-image-preview:large. Without these foundations, your site risks losing visibility in Discover.
\n\nHow can I check that my thumbnails display correctly in Discover? <\/h3>\n\n
Add the following tag in the head of your pages: <meta name="robots" content="max-image-preview:large"><\/code>. That's it. No need to modify the rest of your code. Google Search Console does not provide a preview for Discover, so the only way to validate is to monitor your actual impressions in the GSC Discover report.
Also, check that your cover images comply with the recommended dimensions: at least 1200 pixels wide, 16:9 or 4:3 ratio, JPEG or WebP format. An image that is too small or poorly framed will be automatically dismissed, even with the tag in place. And remember to fill in the alt attributes and Open Graph tags — Google uses them to contextualize the image.
\n\nWhat mistakes should I avoid in this transition? <\/h3>\n\n
Classic mistake: suddenly removing AMP without preparing the replacement HTML. Result: traffic drop, disappearing thumbnails, degraded technical signals. Proceed in phases: first optimize your HTML, ensure performance is up to standard, then gradually remove AMP pages.
\n\nAnother pitfall: believing that the max-image-preview tag is enough to compensate for a slow site. It only changes the thumbnail size, nothing more. If your Time to Interactive exceeds 5 seconds, your LCP is at 4 seconds, and your CLS is at 0.25, you will never pass Discover's selection filters, wide thumbnail or not.
\n\n- \n
- Add meta robots max-image-preview:large in the head of all pages eligible for Discover \n
- Ensure that the cover images are at least 1200px wide and maintain a consistent ratio (16:9 or 4:3) \n
- Optimize Core Web Vitals (LCP < 2.5s, CLS < 0.1, FID < 100ms) to maximize selection chances \n
- Integrate structured JSON-LD (Article, ImageObject) to help Google contextualize the content \n
- Monitor the Discover report in Google Search Console to measure the real impact of changes \n
- If migrating from AMP, maintain both versions in parallel for at least 3 months to compare performance before cutting definitively \n
❓ Frequently Asked Questions
La balise max-image-preview fonctionne-t-elle aussi pour les résultats de recherche classiques ?
Si j'ai déjà AMP, dois-je absolument le supprimer maintenant ?
Est-ce que tous les types de contenu peuvent apparaître dans Discover ?
Combien de temps après l'ajout de la balise max-image-preview voit-on un effet ?
Peut-on forcer l'apparition dans Discover avec cette balise ?
🎥 From the same video 39
Other SEO insights extracted from this same Google Search Central video · published on 01/04/2021
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.