Discover Optimization Is Not SEO Optimization — Two Image Signals Most Sites Miss

Google published a Search Central case study in which a site called Kirbie's Cravings added one line to its robots meta tag and recorded a 79% lift in Google Discover traffic. A second site in the same case study, Istoé, recorded a 30% lift on the equivalent surface. The change was not a content edit, a schema rollout, or a Core Update side effect — it was a robots directive that turned on full-size image previews. Google's own data, Google's own publishing surface, Google's own framing.

If you do not have that directive set, and if your hero images are below 1200 pixels wide, you are not optimized for Discover. You are not even eligible. The February 2026 Discover Core Update — which moved Parade's audience up 1,300% and Forbes' audience down 67% in the same three-week window — did not punish any of those sites for their image setup. It could not. They all had it right. The image signals are the doorway, not the leaderboard.

This post is for everyone who has ever asked "we did all the SEO and we still get no Discover traffic — what is missing?" The answer, for a meaningful share of sites we audit, is two HTML tags.

Key Takeaways

• Google Discover has a documented eligibility floor: images at least 1200 pixels wide, 16x9 aspect, more than 300,000 total pixels, and max-image-preview:large enabled. Miss any one and you are out of the Discover candidate pool.
• The robots directive is not Discover-only — it is Search-wide. Google introduced it in September 2019 specifically to give publishers control over rich-image previews across Search. Discover later adopted it as a hard requirement.
• The February 2026 Discover Core Update did not punish or reward sites for image setup. Winners and losers both had compliant images. Image signals are the gate; predicted-engagement and content signals do the ranking. See our writeup of the February rollout for the redistribution data.
• Most CMS defaults still ship without the robots directive set. Most editorial workflows still serve hero images at 800 px or 1024 px because that is what the layout uses. The fix is small. The cost of skipping it is "Discover is not a channel for you, period".
• This is the cleanest case in the audit catalogue where "your SEO is fine, but you are invisible to a Google surface" is true and fixable in one sprint.

What Google's Discover Docs Actually Say

The Get on Google Discover documentation is short. The image section is shorter. Here are the four bullet points verbatim:

• High-quality images that are at least 1200 px wide
• A 16x9 aspect ratio
• More than 300,000 total pixels (e.g. 1200 x 250 = 300,000)
• Avoid placing the site's logo as the image

And immediately after:

Make sure to enable large image previews by adding max-image-preview:large to your robots meta tag.

That is the full specification of the Discover image gate. There is no soft language. Nothing about "we recommend" or "for best results". The verbs are "are at least", "make sure to enable". Google ships docs in the imperative when the requirement is hard.

The page does not say what happens when you fail these checks. The Kirbie's Cravings case study fills in the blank: before adding the directive, Discover was a marginal traffic source. After: 79% lift. The mechanism, plainly stated in the case study, is that Discover renders article cards at the full-size image format when the directive is set, and at a smaller thumbnail (or sometimes nothing) when it is not. Users on the Discover feed tap on the larger cards at roughly twice the rate. Compounded across millions of impressions, that becomes a 79% audience number.

Why the Robots Directive Is Search + Discover, Not Discover-Only

The temptation when reading the Discover docs is to file the max-image-preview:large directive under "Discover stuff" and forget about it for any site that does not run a publisher business. That framing misses the original purpose of the tag.

When Google introduced max-image-preview in September 2019, the announcement framed it as a Search feature. The post is titled "More controls on Search". The motivation, in Google's wording: give publishers explicit control over how their images appear in Search rich results, including featured snippets, the image carousel, and the visual search surfaces. The same directive that ungates the Discover surface controls the preview rendering across Search.

Without the directive, Google defaults to small thumbnails in Search rich results. Recipe cards render compressed. Product cards render compressed. Featured snippets that include images render compressed. The full-size visual is locked off across the board. A site that loses Discover for missing the directive also loses the visual richness of half its Search appearances — the loss compounds.

This is why our audit reports the directive as a "Search + Discover" signal, not "Discover-only". The eligibility floor is one decision; the rendering quality of every visual Search result is a parallel decision; the same single line of HTML controls both.

Why 1200 Pixels Wide Is the Threshold (And Why "Big Enough" Is Not)

We see a lot of sites that serve hero images at 800 px or 1024 px and assume they are "modern-resolution enough" for Google. They are not. The 1200 px number is not a Google opinion about quality. It is the threshold Google's docs name, and it is the threshold below which Discover stops rendering the full-size card.

There is one piece of context worth surfacing here that the docs themselves do not state. The 1200 px floor was a deliberate Google choice in 2019 to align with the Open Graph 1200x630 social-sharing convention. Sites that had a proper og:image set up for Facebook and Twitter sharing already had a 1200-wide image asset; Google simply piggybacked. The implication is that if your og:image:width is below 1200, you are also serving a sub-optimal social share card to every other platform that consumes Open Graph. Discover is the most punishing consumer because it has an explicit threshold, but the same fix improves LinkedIn previews, Slack unfurls, iMessage cards, and AI citation panels that consume og:image.

The other three numeric requirements (16x9 aspect, >300,000 total pixels, no-logo) are downstream. If you nail 1200 wide and use a typical 1200x675 hero image (Google's own example), you are at 16x9 and 810,000 pixels in one shot. The width number is the one to anchor on. The aspect and pixel-count constraints follow for free.

What February 2026 Taught Us About Image Signals

Our writeup of the February 2026 Discover Core Update covers the publisher redistribution in detail — Forbes lost 67% of its Discover audience, Parade gained 1,300%, the publisher list contracted from 172 unique domains to 158, the rollout took 22 days. The piece worth pulling out here is the part that did not happen.

Forbes did not lose because Forbes had bad images. Forbes had proper og:image markup, proper 1200-wide hero photos, the robots directive enabled. So did Yahoo, The Sun, The Independent — all the major losers. The winners (Parade, Fortune, WSJ, Axios) also all had compliant image setup. ALM Corp's analysis of the top US Discover domains and Newzdash's parallel coverage both confirm: image signals were not the differentiator.

What did differentiate winners from losers was the content layer — predicted engagement signals, content originality, editorial freshness, regional relevance. The February update reweighted those. Image signals stayed where they were, doing what they had always been doing: deciding who was eligible for the redistribution and who was not.

The takeaway for everyone outside the top-tier publisher set is "this is the more important update for you, not the less important one". You are unlikely to be moved by a content-signal reweighting if you are not in the candidate pool at all. The image signals are what put you in the pool. The Discover Core Update was the headline story, but for sites that do not already have image setup right, the silent story is that they were not part of either the winning or losing half — they were sitting outside the gate the whole time.

Why This Is Not "SEO Optimization"

A lot of audit reports lump every Google surface together under "SEO" and treat Discover signals as a footnote. The framing is misleading.

Search optimization is about matching a query — keyword targeting, intent matching, ranking against competing pages for an explicit user input. There is a query string; there is a SERP; there is a measurable position. The optimization loop is well-understood and has been the same loop for two decades, even with the AI Overviews layer on top.

Discover has no query. There is no keyword to target, no intent to match against, no SERP to position on. The algorithm guesses what each individual user is likely to engage with, given their interests and recent behavior. The signals it uses are different from Search ranking signals: image quality, headline-content alignment, freshness windows, predicted engagement, geography. ClickMediaLab's 2026 Discover ranking factors writeup is the most consolidated public list; the overlap with Search ranking factors is small.

This means a site can be perfectly SEO-optimized and still get zero Discover traffic, because the surfaces use different signals and the eligibility floor for Discover is gated by signals that "good SEO" does not necessarily address. Most CMSes have an SEO plugin that handles meta titles, descriptions, canonical tags, and schema — and silently leaves the max-image-preview directive and og:image:width assertions on the table because those are not Search-ranking signals.

For sites in news, publishing, food, travel, lifestyle, ecommerce — anywhere Discover drives meaningful audience — closing this gap is the highest-leverage 30-minute fix available in 2026. Two HTML lines, one image upload pipeline check, and Discover becomes a real channel instead of a missed channel. Search rankings do not improve. That is not the point. Discover eligibility is the point.

What Most Sites Get Wrong in Practice

We have audited enough sites in 2026 to call the patterns. Three failure modes account for almost all the Discover ineligibility we see.

Failure mode 1 — Robots directive missing entirely. Most CMSes ship without max-image-preview set in the default robots meta tag. WordPress with Yoast does not set it. WordPress with Rank Math does not set it. Custom Jamstack stacks usually do not set it. Sites that set robots directives explicitly almost always set them for indexing intent (index/noindex, follow/nofollow) and leave the preview directives blank, defaulting to small. The fix is one line in the head template. The cost of skipping it, for a publisher-style site, is every Discover impression and a meaningful share of Search rich-result CTR.

Failure mode 2 — og:image declared but width below 1200. Editorial workflows often pick whatever image asset the layout uses (800 px wide, 1024 px wide) and pipe it into the og:image meta tag. The image is good quality. It looks fine in the layout. It is below the Discover floor. Discover excludes the page from the large-image candidate pool. The fix is to commission or render the hero image at 1200 wide minimum and reference that version specifically in og:image — even if the in-page layout uses a smaller version.

Failure mode 3 — og:image:width meta tag missing entirely. The og:image URL is set, the actual image file is 1600 wide on the CDN, but no og:image:width meta tag exists in the head. Google can in principle fetch the image and measure it, but the explicit declaration is what consumers (Facebook, LinkedIn, Discover render pipelines) rely on for fast decisions. Without the declaration, half the consumers fall back to thumbnail rendering even when the source image is plenty large. The fix is to add <meta property="og:image:width" content="1200"> (and the matching height) alongside the og:image URL.

All three failures are visible from outside the site, in the static HTML, with no JavaScript execution needed. Any audit that parses the head can detect them. The fact that audits routinely miss them is a framing problem, not a detection problem — they get filed under "OG tags" or "social sharing" and treated as nice-to-have, when in reality they are the eligibility gate for an entire Google surface.

How to Verify Your Site

Open the page in a browser, view source, and search the head for:

1. max-image-preview:large — should appear inside a <meta name="robots" content="..."> tag, alongside any existing directives (e.g. index, follow, max-image-preview:large). If your robots meta tag exists but does not contain that token, you are exposed. If the robots meta tag is entirely absent, Google defaults to small image previews — same effect.

2. og:image:width meta tag — should appear with a content value of 1200 or larger on article-like and homepage URLs. If it is absent or under 1200, you are excluded from Discover's large-image rendering.

3. The actual image file — open the og:image URL directly in a browser. Check the displayed image dimensions (right-click → inspect, or use any image tool). The file itself needs to be 1200 wide or larger; declaring 1200 in the meta tag while serving an 800-pixel JPEG does not help.

If you are running an audit pipeline, both signals can be checked statically without rendering JavaScript. Our audit tool surfaces them as separate findings — one for the width threshold, one for the robots directive — because they fail independently in production and they need separate fixes from different teams (image pipeline vs. head template). When both fail, the fix is two commits, usually in two repos.

What Changes Next

The image signals we cover here are the eligibility floor as of 2026-05. The floor will move. Google has been hardening Discover's visual quality requirements since 2019 and there is no reason to expect that trajectory to reverse. Likely future shifts to watch:

• Higher resolution threshold — 1200 px wide was a 2019 number aligned to a 2014-vintage Open Graph convention. With phone screens at 1080-1290 logical pixels and 3x rendering density, the visual quality requirement is shifting toward 1800-2400 px wide source images. Google has not formalized this yet, but the writing is on the wall.
• WebP / AVIF format preference — Discover's render pipeline already handles WebP and AVIF. Sites still serving JPEG-only hero images leave file-size and load-time wins on the table that compound across thousands of Discover candidates competing for the same feed slot.
• Aspect ratio tightening — 16x9 is the current minimum aspect requirement, but 4x3 and 3x2 render meaningfully smaller cards in the current Discover surface. Sites that standardize on 16x9 hero crops across the entire editorial pipeline (not just the og:image meta tag) win the visual real estate war.

None of these matter if you do not pass the 2026 floor first. Get the directive set, get the width above 1200, then revisit the higher-end optimizations once the basics are in place.

Try It On Your Site

Two signals, three failure modes, one set of fixes. The cost of skipping is "you are not a Discover candidate". The cost of fixing is two HTML tags and a hero-image-pipeline adjustment. We run both checks as part of every audit on hybridranking.com — the result tells you in seconds whether your site is in the candidate pool or sitting outside the gate, and which of the three failure modes (if any) applies to you. The audit is free and runs on any public URL.

Pair this writeup with our coverage of the February 2026 Discover Core Update for the redistribution data that frames why being in the candidate pool matters: the publishers who moved up 200 positions did not crack a new ranking factor — they had image setup right and benefited from a content-signal reweighting. The publishers who moved down by similar amounts also had image setup right; they lost on a different axis. Whether you win or lose the next reweighting depends on the content layer. Whether you are in the conversation at all depends on the two image signals here.