Should you really enable max-image-preview:large to get featured in Discover?

Why does Google require explicit activation of large previews?

Discover operates on a model of progressive consent. Google does not unilaterally decide to display your images: it is up to you to signal that you permit the use of high-resolution visuals.

The max-image-preview:large directive belongs to the family of robots tags and explicitly communicates this permission. Without it, Google defaults to a restriction (equivalent to "standard") that limits the size of previews, even if your images are 2000×1500 pixels.

This logic protects publishers who do not want their visuals — sometimes protected or sensitive — displayed full screen in an algorithmic feed. For sites seeking maximum visibility in Discover, it is a signal to send without hesitation.

What image size actually triggers the large display?

Mueller refers to a "suitable size" — a deliberately vague formulation. Field observations converge towards a minimum of 1200 pixels in width, with a preferred ratio around 16:9 or 4:3.

But size alone isn’t enough. An image of 1600×900 px without the max-image-preview:large tag will remain displayed in a reduced format. Conversely, a 1200×675 px image with the tag enabled will benefit from premium processing.

Google also favors images above the fold, with optimized weight (WebP recommended) and a relevant editorial context. A beautiful orphan image amidst poor content will never be promoted, regardless of its resolution.

Is AMP still a credible alternative for gains?

Mueller mentions AMP as an alternative option. Let’s be honest: AMP is in advanced decline. Google itself has removed the AMP badge from mobile results and decoupled Core Web Vitals from this technology.

If you already have a functional AMP infrastructure, it continues to automatically enable large previews. But deploying AMP solely for Discover no longer makes strategic sense: the meta tag is infinitely simpler, faster to implement, and compatible with any CMS.

The AMP alternative is mentioned only for historical reasons — it was the only way to access large previews before the introduction of max-image-preview. Today, it offers no differentiating advantage on this specific point.

• Two cumulative conditions: meta tag + images ≥1200px in width
• Preferred WebP format to balance quality and loading weight
• Determining editorial context: relevant image in quality content
• AMP is no longer a priority to achieve this goal
• Measurable CTR impact: tests show +40% to +120% depending on the verticals

Does this directive really reflect field observations on Discover?

Data confirms Mueller's statement, but with important nuances depending on sectors. In lifestyle, food, and travel verticals, enabling max-image-preview:large shows spectacular gains: some sites have seen their Discover traffic multiply by 2.5 in three weeks.

Conversely, in B2B, finance, or pure tech themes, the impact remains marginal or even nonexistent. Discover heavily favors mainstream visual content — if your site deals with corporate taxation, this optimization will change nothing about your absence from the feed.

The real issue is not technical but editorial. Google will never publicly state that Discover functions like an algorithmic celebrity magazine, but the facts are stubborn: emotional, visually appealing, and "snackable" content crushes everything else. [To be verified]: the exact impact of the aspect ratio (16:9 vs 4:3 vs 1:1) remains unclear — Google does not provide any quantitative data.

What contradictions exist between this guidance and observed practices?

First paradox: some sites appear in large format on Discover without having implemented the tag. Upon analysis, these are typically high-authority domains (CNN, BBC, Le Monde) for which Google seems to apply a different implicit rule.

Second inconsistency: sites that have correctly activated max-image-preview:large see no change in display for months, then suddenly switch to large format following an algorithm update. This suggests that the tag is a necessary but not sufficient condition.

Third troubling observation: display can vary from user to user for the same content. Google personalizes Discover heavily based on history, location, and device — hence the tag does not guarantee universal display. It allows large format, it does not impose it.

In what cases does this optimization do absolutely nothing?

If your site currently generates no Discover traffic, adding the tag will not miraculously trigger inclusion. The eligibility criteria for Discover are well upstream: content freshness, user engagement, domain authority, thematic relevance.

In practical terms, a technical blog with 200 visitors/month will never appear in Discover, even with 4K images and the tag perfectly configured. Conversely, an established media outlet with several million monthly sessions will see an immediate and measurable impact.

How do you correctly implement the max-image-preview tag?

The implementation is technically trivial: add <meta name="robots" content="max-image-preview:large"> in the <head> of all your pages. Not just on the homepage, not just on recent articles — everywhere.

If you’re already using a robots meta tag with other directives (index, follow, etc.), combine them: content="index, follow, max-image-preview:large". In WordPress, major SEO plugins (Yoast, Rank Math, SEOPress) now offer this option with a click.

Next, check the rendering with the URL Test tool in Search Console — but be cautious, this tool does not specifically simulate Discover. The real test is to monitor your Discover performance for 2-3 weeks after deployment. If you already have traffic, the impact appears within 7-10 days.

What technical errors completely negate the effect of this tag?

First fatal error: placing the tag after the initial load via JavaScript. Google does not always execute JS to read the meta robots — the directive must be present in the raw HTML source, server-side.

Second trap: using aggressively lazy-loaded images that only load during scroll. Google may never "see" these images during crawl. Use loading="eager" on your main image or ensure it’s in the initial viewport.

Third frequent blunder: images that are technically wide (1500px) but severely compressed (20 KB in JPEG quality 30). Google favors high-quality visuals — a blurry or pixelated image will never be promoted, regardless of its declared resolution.

How do you measure the real impact on Discover traffic?

Search Console provides a dedicated "Discover" report with impressions, clicks, and CTR. Export metrics before/after implementation over comparable periods (same day of the week, same seasonality). A positive impact translates to +30% to +150% impressions in the next 3 weeks.

But watch out for false signals: if you publish a viral article simultaneously, it's impossible to isolate the tag's effect. Ideally, first test on a coherent section of the site (e.g. travel category) before generalizing. Strict A/B testing is impossible on Discover — proceed in successive phases.

Also track engagement metrics: time on page, bounce rate, pages per session. A Discover influx with a 95% immediate bounce signals that your visuals promise what your content does not deliver. The algorithm will quickly adjust downward.

• Add max-image-preview:large in the <head> of all pages
• Ensure your main images are at least 1200px in width
• Favor the WebP format with quality compression (80-85)
• Test rendering with Search Console and monitor performance for 3 weeks
• Audit lazy loading: the main image must be visible during the initial crawl
• Export Discover metrics before/after to quantify the impact