Technical SEOLearn how publishers can prepare images, set max-image-preview permission, align page image signals, and audit Discover exposure without assuming placement.
15 min read
A strong article image can arrive in Google Discover as a small thumbnail, or the article may not appear in the feed at all. Neither outcome tells you, by itself, whether the image file is suitable. Publishers need to check the image, the page's preview permissions, and the signals that identify the preferred photo.
Google Discover large image previews for publishers are card images in a personalized feed, not full-size Google Images results. We will separate the settings you can control from Google's choices about the thumbnail and whether to show an article.
Article summary
Start with the article's image file, then judge how it reads as a landscape thumbnail. Width alone cannot tell you whether the subject will survive a crop.
Google Search Central recommends images at least 1,200 pixels wide, with more than 300,000 total pixels and a 16:9 aspect ratio. These are recommendations for strong Discover imagery, not conditions that promise a large card or feed placement. Width measures one side of the file; total pixels multiply its width by its height. Treat them as separate checks when you select an export from your CMS.
Google's example measures 1,280 × 720 pixels, giving it 921,600 total pixels. The dimensions also form a 16:9 rectangle. That makes it a useful reference when an editor must choose between several versions of the same photograph. A file with ample width but too little height may have less room for the intended crop. A tall original may have plenty of pixels yet still need a deliberate landscape version.
Use the actual file assigned to the article rather than the dimensions of a large original stored elsewhere. A CMS may hold several derivatives, and your editorial choice concerns the version presented on the page. Record its width, height, and intended crop together. That small record makes it easier to spot a template that consistently selects an unsuitable derivative instead of asking editors to replace each image individually.
For teams choosing images at publication time, a repeatable image review belongs alongside the publisher editorial workflow. It gives the person approving the article a chance to catch a poor export before the page goes live.
Pixels are the canvas; the crop is the window. Google may crop a Discover image automatically, so a large file can still produce a thumbnail that hides the relevant subject. Examine the image at a landscape ratio before approving it. If the article concerns a particular person or object, keep that subject within the portion likely to remain visible. Empty space at the edges is less costly than losing the subject.
Consider an article about a newly opened pedestrian bridge. A photograph taken from far away may technically meet the image recommendations, yet the bridge could occupy only a narrow strip. A closer frame can communicate the subject at card size without changing the article's meaning. This is an editorial choice, not a directive that tells Google where to crop. You are preparing a useful candidate image while Google retains control of the displayed treatment.
When the original is tall, choose a landscape crop deliberately rather than relying on the middle of the frame to contain everything. Look at where faces, signs, or the main object sit after trimming the top and bottom. If a tight crop removes necessary context, choose another photograph. Preserving the story is more useful than forcing a weak image into the recommended shape.
This review also helps with repeat publishing. Note which article types tend to use portrait photography and give their editors a practical landscape option. Otherwise, a technically sound template can repeatedly receive images whose subject disappears in the card.
Google recommends compelling, high-quality images that are relevant to the content. It also says large images are more likely to generate visits from Discover. Neither statement means that making an image larger will cause an article to appear. Choose the photograph that helps a reader identify the story, then make sure its file and crop support that choice.
A sharp but generic photograph can satisfy the dimensions while saying little about the article. For an account of a specific event, an image of that event is a stronger candidate than a broad illustration of its topic. Editorial relevance matters because the card pairs a picture with a headline. If those elements point to different stories, the preview can mislead even when each element looks polished on its own.
We recommend treating the image decision as part of your content planning and reporting, rather than as a late technical repair. When you review article performance, you can then distinguish a recurring image-choice problem from a preview setting shared by the whole template.
For each representative article, keep the selected file and its crop associated with the page you are auditing. This lets you compare what the editor meant to publish with what the article identifies as its preferred image. That distinction matters once you move from image preparation to page settings.
After choosing the image, check the rule delivered with the article page. The preview directive grants permission for a larger display; it neither enlarges the source file nor chooses the thumbnail.
For an HTML article, the robots meta tag can carry the permission. The HTML example is <meta name="robots" content="max-image-preview:large">. Google also accepts the directive in an HTTP response header, written as X-Robots-Tag: max-image-preview:large. Either route lets the page communicate its preview permission without changing the photograph.
Choose the route your publishing setup can apply consistently. A CMS template may place a meta tag on article pages, while a server configuration may send a header. What matters during an audit is the page response your visitor receives, not a field labeled "large image" in an editing screen. Compare a published article with its template setting so a local exception does not hide a broader configuration problem.
Google's Discover guidance also mentions AMP as another route for enabling large image previews. AMP is not required when you use the documented preview directive. If your site publishes more than one version of an article, inspect the version delivered for each route you actually use. A setting on one template does not, by itself, describe every article response.
We would start with a representative published article and identify whether the permission appears in its HTML or response headers. Then inspect another article that uses the same template. A consistent result points to a template-level setting; a difference suggests an article-level override or a separate publishing path worth examining.
The `max-image-preview` rule has three values. Google describes `none` as allowing no image preview, `standard` as permitting a default-size preview, and `large` as permitting a larger one. With `large`, the preview may reach the width of the viewport. That is a display limit, not a required pixel width for the image file and not an instruction to render every card at that size.
If you omit the rule, Google may show a default-size image preview. An article can therefore have an excellent lead photograph but lack explicit permission for a larger preview. The reverse also happens: a page can grant permission while supplying an image that is too small or poorly cropped for the intended card. Audit both pieces rather than assuming one repairs the other.
Think of the directive as permission to open a wider display window. It does not make the photograph sharper, select the subject, or require Google to open that window. For publishers, this distinction prevents an unhelpful fix. Adding `large` cannot recover detail missing from the uploaded file. Replacing the file cannot override a restrictive page rule.
The value should also match your editorial intent. A publisher that does not want image previews can choose `none`; one that permits only the default-size treatment can choose `standard`. Use `large` when your policy allows a bigger preview and your image workflow supplies appropriate candidates. Google still decides the final presentation.
Inspect all robots instructions delivered for the article, not only the setting you intended to add. Google applies the more restrictive rule when directives conflict. A page that declares `max-image-preview:large` in one place and a tighter preview value elsewhere has not given a clear, effective large-preview permission. Check the HTML meta tag and any `X-Robots-Tag` header together.
Google must be able to crawl the page to read those instructions. A `robots.txt` crawl block can prevent it from discovering the meta tag or header. Do not treat a rule visible in your browser as proof that Google can read it. The practical audit starts with the delivered page, then accounts for whether crawling is allowed for that page.
Other robots directives have different jobs. `noimageindex` blocks image indexing, while `noindex` blocks a page from search results. Neither means "show my image larger." If either appears unexpectedly on editorial pages, examine why it was set before changing preview permission. Removing a restriction can affect more than the size of a Discover thumbnail.
A useful handoff to a developer names the exact article and the conflicting instructions in its response. That is more actionable than reporting that Discover images look small. Once the delivered rule is consistent, you can move to the separate question of which image the page suggests Google use.
You do not upload a picture directly to Discover as a separate publishing step. Publish it with an article that Google can index, then treat image-selection markup as guidance rather than an admission ticket.
Google says indexed content that meets its Discover content policies is automatically eligible. It does not require special tags or structured data for that eligibility. Appearance is a separate decision, so even an eligible article with a suitable image and generous preview permission may never appear in a reader's feed. This is the boundary to keep in view throughout a Google Discover large image preview audit.
For a publisher asking how to publish a picture on Google Discover, the useful action is to publish the article with its relevant image. You are preparing a page that can be considered, not submitting an isolated photograph for a card. The article and image need to make sense together because Discover presents editorial content to people according to their interests.
Keep the eligibility check distinct from the image check in your audit notes. One question asks whether the article can be indexed and complies with Discover policies. Another asks whether its image and preview settings support a larger card. A problem in either area calls for a different fix. Increasing image dimensions does not make a non-indexed article eligible, while indexing alone does not choose a compelling thumbnail.
This separation matters when a colleague reports that an article is absent from the feed. Absence does not identify a faulty image setting. First establish what the page actually publishes and permits. Then describe the remaining uncertainty plainly: Google chooses whether the eligible article is shown to a given audience.
Google says `og:image` or schema.org image markup can identify a large, representative page image and influence its thumbnail choice. Neither signal locks in the displayed image. Use them to make your editorial preference legible, particularly when an article contains several photographs that could plausibly represent the story.
Open a published article and compare its visible lead image with the image identified in those page signals. If the lead photograph shows the event but `og:image` identifies a generic graphic, the page sends an avoidable mixed message. Align the signals with the image that best explains the article, then check that this file also has a useful landscape crop.
Structured image markup is optional for Discover eligibility. That makes it useful as a preference signal, not a substitute for indexing, policy compliance, or preview permission. A publisher can reasonably maintain it for consistency across article templates without presenting it as a requirement to appear in the feed. The same distinction applies to `og:image`: it suggests an image, but Google makes the final selection.
If your CMS assigns the preferred image automatically, test an article with more than one photograph. A template that always chooses the first file may not reflect an editor's choice of lead image. Fixing that mapping at the template level can be more reliable than asking editors to correct individual pages after publication.
Google advises publishers to use titles that capture the article's essence and to avoid clickbait or misleading preview text and images. It also advises against using a site logo or a text-heavy image as the preferred image. Those choices may be easy for a template to supply, but they tell a reader less about a particular story than a relevant photograph does.
Review the title and selected image as a pair. An image can be accurate on its own yet suggest a claim the article does not make when placed beside a forceful headline. Conversely, a precise title cannot rescue a generic image that makes several unrelated articles look identical. The preview should let a reader understand what they are about to open.
Google also recommends a good page experience. The card is only the invitation; the article must deliver what its preview promises. When you choose between a dramatic crop and one that preserves context, favor the honest frame. A visually striking thumbnail that changes the meaning of the scene is a poor editorial choice even if it fits the preferred dimensions.
We would make this a publication check for articles likely to have multiple candidate images. Ask whether the lead image, page signals, headline, and article tell the same story. If they do, the page gives Google a coherent candidate without pretending to control the final card.
Use Discover reporting to understand exposure, not to infer that a particular image setting caused it. Then inspect a representative article template before changing the wider archive.
The Search Console Discover Performance report appears after a property reaches a minimum number of Discover impressions. Google says the report covers content that appeared in Discover during the previous 16 months. It measures actual exposure, rather than the pool of articles that could have appeared. That distinction matters when you review an image-setting change: a page can meet the documented conditions without producing a report entry.
The report lets you group data by page, country, Discover appearance, and date. Choose the view that matches the question you are asking. Page data can show which articles received exposure, while dates can help you see whether a change affected several days rather than one. Neither view turns an impression count into an audit of the image file or the robots directive.
A missing report is not a reason to leave page settings unexamined. You can still inspect a published article, its selected image, and its delivered preview permission. Those checks answer whether your publishing setup provides suitable inputs. The report answers a different question: what happened when content was shown in Discover.
Keep a record of when a template change reaches published pages. That gives your team a clear point to review later, without treating the next movement in the report as proof of cause. Discover exposure depends on more than the settings under your control.
Search Console Help defines the report's measures by what people did in Discover. Read them in this order before comparing article pages:
Google assigns these metrics to the canonical URL, the page address it treats as the main version. Individual page rows below the report's impression threshold may be omitted, while their data remains in site totals. If a total exceeds the visible rows, do not turn that difference into a diagnosis of missing image permission.
An impression starts when the item comes into view, not when an eligible page is published. Clicks then tell you how often people opened that item. CTR relates those two measures. Read them together when comparing exposed articles, but return to the actual page when you need to know which image and preview directive it supplies.
Do not treat a rise in clicks as evidence that Google displayed a larger thumbnail. It tells you that more clicks occurred. The actionable technical question remains whether the article supplies a suitable image, permits a larger preview, and identifies a representative candidate.
Google describes Discover traffic as less predictable than query-driven Search traffic. It serves content according to user interests, and changes in those interests, content types, or Search updates can affect exposure. A single day's movement therefore gives you little basis for blaming a thumbnail setting. Look for a pattern across articles and dates, then return to the pages themselves.
Choose one published article that represents a common CMS template. Record the dimensions of its selected image and examine its landscape crop. Next, inspect the delivered robots meta tag and response header for the effective preview rule. Finally, compare the visible lead image with the page's preferred-image signals. Each check has a concrete outcome you can act on without guessing why Discover did or did not show the article.
If the image is unsuitable, revise the editorial image workflow or the derivative that the template uses. If the rule is restrictive or inconsistent, fix the delivered setting. If the preferred-image signals point elsewhere, correct the template's image selection. Apply a template-level repair across the archive only after the representative article shows the intended output.
The decision is now a practical one: identify which of those settings needs work, or leave a sound configuration in place. Your next step is to audit that representative page and make only the change its delivered output supports.
To publish a picture in Google Discover, include it on the article page; Google automatically considers indexed, policy-compliant content without requiring special tags or structured data. Publishers can use `og:image` or schema.org image markup to suggest a large, representative image, but Google may still choose which thumbnail to show.
Google recommends a Google Discover image at least 1,200 px wide, with more than 300,000 total pixels and a 16:9 aspect ratio. Google’s example is 1,280 × 720 px, or 921,600 pixels; these are recommendations, not a guarantee of feed placement.
Publishers can allow a larger Google Discover preview with the page-level `max-image-preview:large` directive, delivered in an HTML robots meta tag or an `X-Robots-Tag` HTTP header. Google must be able to crawl the page to read the directive, and the setting permits a larger preview rather than forcing one.
No, `max-image-preview:large` does not guarantee a large preview or appearance in Google Discover. The directive permits a larger preview, potentially up to the viewport width, but it neither selects an image nor ensures that an eligible page appears in the feed.
