Google Discover: The Traffic Channel You Can Measure but Barely Steer

Google Discover occupies a strange position in most reporting. It is often a site’s second-largest Google surface, it arrives without a query attached, and it is missing from most SEO dashboards entirely — usually because the person building the dashboard has never been asked about it. Then a spike happens, nobody can explain it, and the channel gets written off as noise.

Google’s own documentation is unusually direct about why it behaves that way, and about how little of it is under your control. That candour is what makes Discover worth understanding properly rather than optimising for: a short list of real technical requirements, and an explicit instruction about how to treat the traffic in your forecasts.

Google Discover is a feed inside Google Search that surfaces content matched to a person’s interests rather than to a query. Any page indexed by Google and compliant with Discover’s content policies is automatically eligible — no special markup is required — so optimisation is limited to image specifications, preview signals, page experience, and content that suits an interest-based feed.

Key takeaways

• There is no Discover markup, and no way to opt in. Google states that content is automatically eligible to appear in Discover if it is indexed by Google and meets Discover’s content policies: “No special tags or structured data are required.”
• Eligibility is not appearance. Google adds the qualifier in the same paragraph: being eligible to appear in Discover is not a guarantee of appearing.
• One technical setting does gate the good placements. Google’s image specification requires max-image-preview:large (or AMP) alongside images at least 1200 px wide — without it you are ineligible for the large-image treatment that drives the visits.
• Google tells you to treat the traffic as supplemental. Its wording: Discover traffic is less predictable or dependable when compared to keyword-driven search visits, and you should consider it supplemental to keyword-driven search traffic.
• It is not only for new content. Google notes that older content may appear if it’s helpful and relevant to individuals based on their interests — which makes evergreen work eligible, not just news.

What Discover is, and what it is not

Discover is part of Google Search that shows people content related to their interests, based on their Web and App Activity. There is no query. Google is matching content to a person rather than a person’s words to content, which inverts every assumption underneath keyword-driven SEO.

Two consequences follow, and both are stated in Google’s documentation.

You cannot target it. There is no keyword to rank for, no schema type to implement, no property to submit. Eligibility is automatic for indexed, policy-compliant content. Everything below is about making eligible content more likely to be selected, which is a materially weaker form of control than ranking.

It is still Search underneath. Google says Discover makes use of many of the same signals and systems used by Search to determine what is helpful, people-first content, and points site owners at the same helpful-content guidance. So Discover is not a separate discipline requiring a separate content strategy. It is the same content, selected differently.

The most persistent myth is that Discover is a news-publisher channel. Google’s own text contradicts the narrower reading twice: content that may appear “includes a wide range of topics that aligns with a person’s interests”, and older content may appear if it remains helpful and relevant. Recency helps because interests are often current; it is not a requirement.

There is a genuine restriction, though, and it is about format rather than topic. To keep the feed suitable for interest-based browsing, Google says Discover might not recommend job applications, petitions, forms, code repositories, or satirical content without any context, and that beyond SafeSearch it filters content that might be seen as shocking or unexpected. If your library is mostly documentation, reference tables and tools, Discover is unlikely to be a channel for you no matter what you change.

The one setting that actually gates it

If you take a single technical action from this article, this is it — and it is the one most commonly missing on B2B sites.

Google’s image guidance for Discover asks for compelling, high-quality images, “especially large images that are more likely to generate visits from Discover”, and gives specifications:

• At least 1200 px wide
• More than 300,000 total pixels — Google’s own worked example is that a 16:9 image at 1280×720 gives 921,600 pixels and clears the bar
• 16:9 aspect ratio
• Enabled by the max-image-preview:large setting, or by using AMP

That last line is the gate. max-image-preview:large is a robots meta directive, and without it Google will not use the large image preview regardless of how good your image is:

<meta name="robots" content="max-image-preview:large">

Or as an HTTP header, which is easier to apply site-wide:

X-Robots-Tag: max-image-preview:large

Plenty of sites are missing it for an understandable reason: it is not in most CMS defaults, most SEO plugins do not surface it prominently, and nothing in Search Console complains about its absence. Check yours in one command:

curl -sI https://example.com/some-article | grep -i "x-robots-tag"
curl -s https://example.com/some-article | grep -i "max-image-preview"

If neither returns anything, you are ineligible for the placement that produces most Discover clicks. The rest of the robots directive family — and the traps in it — are covered in robots.txt for developers.

Choosing the image Google shows

Having enabled large previews, the next question is which image gets used. Google’s guidance is to specify one explicitly, using schema.org markup or the og:image meta tag, since this “can influence which image is chosen as the thumbnail in Discover”.

Two things it tells you not to do, both of which are near-universal defaults on B2B sites:

• Avoid generic images, and Google names the specific case: your site logo.
• Avoid text-heavy images. A rendered headline on a card reads well in a social preview and badly at feed size.

This is worth checking against what your site actually ships rather than what your template intends. A single fallback OG image applied across every article satisfies the tag and defeats the purpose — every card looks identical and none of them represents its page. If your OG images are auto-generated from the article title, you have text-heavy images by construction, which is exactly the case Google advises against for this surface.

The trade-off is real and worth naming: a title-card OG image usually performs well on LinkedIn and X, where context is thin and the headline does the work. Discover wants the opposite. If both matter, they need different images, not a compromise between them.

What Google says about preview content

The remaining recommendations are about the preview a person sees in the feed — title, snippet, image — and they are framed as prohibitions more than techniques:

• Avoid clickbait — specifically, using misleading or exaggerated details in preview content to artificially inflate engagement, or withholding crucial information required to understand what the content is about.
• Use page titles and headlines that capture the essence of the content.
• Avoid sensationalism tactics that manipulate appeal by catering to morbid curiosity, titillation, or outrage.
• Provide content that’s timely for current interests, tells a story well, or provides unique insights.
• Provide an overall great page experience.

The withholding clause is the one worth dwelling on, because it describes a technique that works everywhere else. “The one metric that changed everything” is a curiosity-gap headline; on this surface Google names it as a thing to avoid. Headlines that state the finding tend to be the ones that survive here — which happens to be the same discipline that makes a page extractable by answer engines, covered in answer engine optimization.

Page experience is the least glamorous item and the one with a measurement path attached: the loading, interactivity and layout-stability metrics in Core Web Vitals for developers.

Measuring it honestly

Discover has its own Search Console report — Performance → Discover — and it behaves differently enough from the Search report that comparing them naively produces wrong conclusions.

What Google documents about it:

• It shows impressions, clicks and CTR for content that has appeared on Discover in the last 16 months, as long as your data reaches a minimum impressions threshold.
• The report is visible only if your property has reached a minimum number of impressions in Discover. Its absence is a finding, not a bug.
• It includes traffic from Chrome and tracks Discover traffic across all surfaces where users interact with Discover.

Four definitional details decide whether your numbers mean what you think they mean, and none of them is obvious from the interface.

Metrics are attributed to the canonical URL. Google is explicit that all page metrics are assigned to the canonical URL, not to the page where the user lands when they click a Discover result. Two consequences follow: the URL credited in the table is the canonical one, and data appears only in the property containing that canonical. If you have duplicates, “the canonical URL will contain all data for clicks, impressions, and CTR, and the duplicate URLs will show zero for those values.” A property that reports zero Discover traffic may simply not own the canonical — which makes this a canonicalisation question before it is a reporting one. The decision framework is in canonical vs noindex.

An impression means scrolled into view. Google counts an impression when the Discover item is scrolled into view, and only one impression per result per session — scrolling past and back does not double it. This is a stricter definition than the Search report’s, so Discover CTR is not comparable to Search CTR and should never be charted against it.

A click excludes sharing. Google notes a click is not counted if the user shares the item or performs another action. Engagement that does not produce a visit is invisible here.

The table is capped at 1,000 rows, and Google says the data is truncated before it reaches the report — so reversing the sort order will not reveal row 1,001. On a large site the page-level table is a sample, and the totals above the chart are the accurate figure. Dates are in Pacific Time in every view except the 24-hour one, which is another reason Discover and analytics numbers rarely reconcile exactly.

And note the missing dimension: there is no query data, because there are no queries. Any dashboard that joins Search and Discover on a query column will silently drop Discover entirely. If you are building the reporting layer, this is a schema decision rather than a formatting one — the two surfaces need separate tables. The dashboard patterns are in how to build an SEO reporting dashboard in Looker Studio.

The harder measurement question is what to promise. Google’s guidance is explicit that Discover traffic is less predictable or dependable than keyword-driven search visits and should be treated as supplemental, and it lists three reasons the number moves without you doing anything:

Cause	What Google says	What it means for reporting
Changing interests	Someone less interested in a topic sees other content instead	Declines can be entirely audience-side
Content types	Discover adjusts which content types appear on the feed	Category-level shifts are not site-level failures
Updates to Search	Discover is an extension of Search, so core updates can produce traffic changes	Correlate with the Search status dashboard before diagnosing

The practical consequence for anyone reporting to a client or a board: do not put Discover in a forecast, and do not put it in the same chart as organic search without a label. A month where Discover doubles and search is flat is not a win you can repeat; a month where Discover collapses and search is flat is usually not a failure you caused. Reporting them as one line manufactures both stories. Which metrics belong in front of a stakeholder at all is the subject of SEO KPIs.

Is Discover worth any effort?

For most B2B and SaaS sites, honestly: a small amount, once.

The work that qualifies is bounded and does not compete with anything else on the roadmap. Set max-image-preview:large site-wide. Make sure each article specifies a real, representative image at 1200 px or wider in 16:9, rather than a logo or a title card. Do not write curiosity-gap headlines. Every one of those is defensible on its own merits for social sharing, image search and Search itself — Discover eligibility is a side effect rather than the justification.

What does not qualify is a content strategy aimed at the feed. There is no query to target, no ranking to track, and Google explicitly tells you the traffic is not dependable. Building an editorial plan around a surface with those properties is speculation with an SEO label on it.

The exception is a site whose Discover report is already showing meaningful impressions. That is evidence the surface likes your content, and it changes the calculation — at that point the image and preview work has a measured return rather than a hypothetical one. Check the report before deciding; for most sites the tab will not be there at all, which is the answer.

Where this fits

Discover is a Google surface you measure rather than target, which puts it alongside the other places traffic arrives without a ranking attached: tracking AI referral traffic for the assistant surfaces, and how to track AI Overviews for the one inside the results page. The reporting layer that has to hold all of them is in Looker Studio, and the question of which of them belong in a stakeholder report is in SEO KPIs.

If you want the measurement layer built so these surfaces are separated properly rather than averaged into one misleading line, that is part of GEO and technical SEO consulting.

FAQ

How do I get my content into Google Discover?

There is no submission and no markup. Google states that content is automatically eligible to appear in Discover if it is indexed by Google and meets Discover’s content policies, and that “no special tags or structured data are required.” What you can influence is selection rather than eligibility: enable max-image-preview:large, supply a large, representative, non-generic image at 1200 px or wider, write headlines that capture the essence of the content rather than withhold it, and provide a good page experience. Google is also clear that eligibility “is not a guarantee of appearing.”

Do I need structured data for Google Discover?

No. Google says no special tags or structured data are required for eligibility. Schema.org markup still has a role, but a narrower one than people assume: Google suggests using schema.org markup or the og:image tag to specify a large, representative image, because that can influence which thumbnail Discover chooses. That is image selection, not eligibility.

Why did my Google Discover traffic suddenly drop?

Google lists three causes that are not about your site’s quality: changing interests, where someone’s declining interest in a topic changes what their feed shows; content types, since Discover adjusts which kinds of content appear; and updates to Search, because Discover is an extension of Search and core updates can produce traffic changes. Before investigating your own pages, check the dates against Google’s Search status dashboard. Google also frames the whole channel as less predictable or dependable than keyword-driven search visits, so some variance has no diagnosis at all.

Is Google Discover only for news sites?

No. Google says content that may appear “includes a wide range of topics that aligns with a person’s interests”, and that older content may appear if it’s helpful and relevant. Timeliness helps because interests are often current, but it is not a requirement. The real constraint is format rather than recency: Google notes Discover might not recommend job applications, petitions, forms, code repositories, or satirical content without context — so reference-heavy and tool-heavy sites are poor candidates whatever they publish.

What is max-image-preview:large and do I need it for Discover?

It is a robots meta directive that permits Google to use a large image preview of your page. Google’s Discover image specification lists it explicitly: images should be at least 1200 px wide, more than 300,000 total pixels, 16:9, and “enabled by the max-image-preview:large setting, or by using AMP.” Without it you are not eligible for the large-image treatment that generates most Discover visits. Set it in a robots meta tag or, more reliably, as an X-Robots-Tag HTTP header applied across the site.

Why can’t I see the Discover report in Search Console?

Because the property has not reached the threshold. Google states the report is visible only if your property has reached a minimum number of impressions in Discover. Its absence is informative rather than broken — it means the surface has not selected your content, which for many B2B and documentation-heavy sites is the expected outcome. One thing to rule out first: metrics are attributed to the canonical URL, so if the canonical for your content sits in a different property, the data is there rather than here.

Should Discover traffic go in my SEO forecast?

No. Google’s own guidance is to consider Discover traffic supplemental to keyword-driven search traffic, precisely because it is less predictable. Report it, separately and labelled, so a spike or a collapse does not get attributed to work on organic search. Forecasting against a surface with no query, no ranking and documented audience-side volatility produces numbers that cannot be defended when they miss.