Setting max-image-preview:large is one of three things Google's Discover documentation asks for when it comes to images. The others are a file at least 1200 px wide and a crop that still works in a landscape frame. The robots setting alone does nothing if the lead image is a small square, and a perfect hero image does little good if a stray rule limits the preview. None of this guarantees that a page will appear in Discover; the documentation states plainly that being eligible is not a guarantee of appearing.
This guide is for publishers, editors and designers. Ranking in Google Images is a different subject, covered in the guide on optimizing images for Google; this piece stays with the Discover card.
Why large images matter in Discover
Nobody types a query in Discover. People scroll, and the image and headline decide whether a card earns a tap. That is the editorial reason behind the technical requirements.
Image conditions listed in the Discover guide
The Discover documentation (Opens in a new tab) lists these image requirements: a width of at least 1200 px, more than 300,000 total pixels (with 1280x720, which is 921,600 pixels, as the example), a 16:9 aspect ratio, and large previews enabled through the max-image-preview:large setting or through AMP. If you crop by hand, key details should stay inside the landscape crop, and you should name your preferred image through og:image or schema.org markup. The page recommends avoiding generic images such as a logo and avoiding text heavy images. Specific numbers and wording in Google's pages can change, so check the current version before you apply them.
A card is a first impression
These rules look technical but they serve a goal: the card is a reader's first contact with the story. The picture should explain the subject at a glance and agree with the headline. The documentation also tells publishers to avoid clickbait and exaggerated previews, so a large image does not help if it overpromises. It has to represent what the page really contains.
One cover file or two?
Should you prepare a separate Discover image? If your standard cover already measures at least 1200 px wide, sits in a 16:9 frame and loses nothing important in the landscape crop, one image does both jobs. If your cover is square or vertical, prepare a landscape version of the same scene and name it as the preferred image. If your team is short on time, the cheapest solution is to shoot or design every cover as a landscape composition from the start.
Which page types lean on the image
| Page type | Image importance in Discover | Watch for |
|---|---|---|
| News and timely commentary | High, the card leans on the image | An original image that fits the headline |
| How to guides | Medium, a result or process shot | Avoid text heavy covers |
| Product and promotional pieces | Medium | A scene that explains the topic, not a logo |
| Forms and bare lists | Low | Discover may not recommend these types |
The importance ratings are an editorial judgement, not something Google ranks. The last row is based on the documentation, which says Discover may not recommend job applications, petitions, forms or code repositories.
Leaving the permission out
The Discover page does not describe in detail what a page loses without large previews. The robots meta documentation says that when the rule is omitted, Google may show a default sized preview. Putting those together, a page without the permission fails the large image requirement that Discover lists. Claims about click through effects go beyond what the documentation says.
Setting max-image-preview in robots meta
The permission for large previews travels in the robots meta tag. Google's documentation is clear about what the values mean and what can override them.
none, standard and large
According to Google's robots meta tag specification (Opens in a new tab), max-image-preview sets the maximum size of an image preview for the page in search results. With none, no image preview is shown. With standard, a default image preview may be shown. With large, a larger preview, up to the width of the viewport, may be shown. If the rule is omitted, Google may show a default size preview.
Note the word may. The directive grants permission and does not promise display. The Discover documentation likewise lists large previews as one requirement and then repeats that eligibility is not a guarantee.
Quick lookup by situation
| Situation | Effect | Action |
|---|---|---|
| No directive | A default size preview may be shown | Add max-image-preview:large |
| max-image-preview:none | No image preview | Change the value to large |
| max-image-preview:standard | Default preview | Switch to large if you want large images |
| large in the page, stricter rule in header | The more restrictive rule applies | Remove the conflict |
| Page blocked in robots.txt | Meta rules cannot be read | Unblock the page |
Where the tag goes and how to write it
The robots meta tag belongs in the head of the page, although the documentation says Google also respects tags placed in the body. The tag has the name robots, and its content attribute carries the directive, for example max-image-preview:large. Several rules can be combined in one comma separated list. For non-HTML files such as PDFs, the same rules go into an X-Robots-Tag HTTP header, which can be set in server configuration to apply patterns across a site.
If you work with a CMS, look for the global setting in your SEO plugin or platform rather than editing templates by hand. The setting name varies, and the label may differ if your interface uses another language. The reliable check is to open the published page source and see that the tag is there.
When another rule or robots.txt gets in the way
The documentation states that when rules conflict, the more restrictive one applies. A stray none or a stricter rule from another plugin can therefore cancel your large preview permission. Related rules deserve attention too. According to the page, nosnippet means no text snippet or video preview in results, although a static image thumbnail may still appear when it gives a better experience. The max-snippet rule limits the length of the text snippet, and a value of zero is equivalent to nosnippet. Read all the robots rules on a page together instead of one at a time.
Blocked pages are another trap. The documentation notes that if a page is blocked by robots.txt, its meta tags and headers cannot be read, so rules on it are ineffective. If you want a page to carry the permission, do not disallow it.
Case: a stricter header from the server
A recipe site sets max-image-preview:large in the head of every article. Later, a change in its hosting setup starts sending an X-Robots-Tag header with a stricter image preview value on all responses. The page source still looks correct, yet the documentation says the more restrictive rule applies when rules conflict. The safe move is to inspect both the source and the response headers of the live page, not only the template. The fix removes or aligns the header so that no rule limits the large preview.
Setting it once in the template
Adding the directive page by page invites mistakes. Manage it from one place, the theme template or the plugin's global settings, then inspect the source of one post, one category page and one static page. Large previews are not equally relevant to every page type; archive and search result pages are not the cards you are trying to place in Discover, so decide editorially where the permission belongs. Repeat the inspection after any theme or plugin update, because updates can change defaults quietly.
Size, crop and WebP
Dimensions and crop follow the numbers in the Discover documentation. File format is a topic the documentation leaves open.
Working out the pixel counts
There are two numeric requirements: a width of at least 1200 px and more than 300,000 total pixels. In a 16:9 frame, 1200 px wide means 675 px tall, which gives 810,000 pixels and clears the second requirement easily. The documentation's example is 1280x720. Both conditions apply together, so a very tall but narrow image with plenty of total pixels still fails the width requirement.
A sensible working target for a publishing team is a 16:9 export such as 1600x900. That sits above the documented minimums and leaves a margin for trimming. The figure is a recommendation, not a Google requirement. Larger files cost bytes, so balance them against page speed; the guide on LCP image fetchpriority and preload fixes covers how to load a lead image quickly.
Cover problems and what to do
| Current cover | Problem | Decision |
|---|---|---|
| 1600x900, subject centred | None | Use as is |
| 1000x560 | Width below 1200 | Rebuild from a larger source |
| 1080x1080 square | Not 16:9, loss in landscape crop | Prepare a landscape version |
| Large headline text across it | Text heavy | Remove or shrink the text |
| Site logo only | Generic image | Pick a scene that explains the topic |
Safe zone and buffer zone
The documentation wants important details to stay in a landscape crop. A workable method is to think in two zones. The safe zone holds what the picture needs to make sense: the face, the product, the scene of the event. The buffer zone is everything that could be trimmed without harm. Keeping the safe zone near the centre of the frame reduces losses when crops vary. This is an editorial technique, since Google does not define a crop region.
From original to export
- Start from the largest original you have, because enlarging a small image fakes the width without adding detail.
- Draw a 16:9 frame and place the safe zone in its middle.
- Check the edges for sliced hands, half faces or cut-off products.
- Export at 1200 px wide or more, ideally around 1600 px.
- Upload the file and declare it as the preferred image with og:image or schema.org markup.
- Open the published page and confirm the image URL loads.
If your sources are square or vertical, losses in step two are unavoidable. Plan the next shoot or design in landscape.
Reading headline and image as one sentence
Place the headline and image side by side and show them to a colleague who has not seen the article. Ask what the page is about. If the guess is close to the real subject, the pair works. If it is far off, either the headline or the image promises the wrong thing. This test applies the documentation's rule that titles should capture the essence of the content to the picture as well. A common fix is not a new photograph but a different crop of the one you have, so prepare two or three candidate crops and choose the clearest.
Why overlays and logos are discouraged
The documentation advises against generic images such as logos and against text heavy images. Putting the headline inside the cover is tempting, but the card already shows the headline, so the overlay repeats it and risks becoming unreadable at small sizes. If you need a label, keep it short and let the scene carry the story.
Format choice: where WebP fits
The Discover page does not list required file formats, so statements such as "Discover needs WebP" are not supported by it. The practical case for WebP is page speed: it often produces smaller files at similar visual quality, which is why many publishers serve covers in that format. When you choose a format, check that the file is at least 1200 px wide, that its URL can be crawled, and that the format works wherever the og:image is shared.
Google's general structured data policies (Opens in a new tab) say that an image named in markup must be relevant to the page and that image URLs must be crawlable and indexable. An image behind a login or a robots.txt disallow rule undermines that, whatever its format.
Alt text sits outside the card
Alt text does not appear on the Discover card, yet it matters for accessibility and for the meaning of the page. Describe the picture briefly and do not stuff keywords. The guide to article image alt text and stock image licensing explains the details.
Licensing checks
A large, striking image also enlarges any licensing problem. This section is not legal advice. It lists questions to ask in your publishing process.
Where Google's pages stay silent
The robots meta documentation does not cover image licence metadata. It only notes that the noimageindex rule stops Google from indexing the images on a page. The Discover documentation does not state licence terms either. So these pages give no checklist for image rights, and your own process has to fill the gap.
The structured data policies do say to use only original content created by you or your users in markup. It is a useful reminder before you name someone else's picture as the preferred image: confirm that you really hold the right to use it.
A one-line record per image
Keep a small record for each cover: file name, source, licence type, download date and the address of the licence page. If someone questions the image later, you can answer quickly. For stock images, verify the licence at the individual asset level and not only at the collection level. Sponsored posts and promotional pieces can add rules for pictures and video, which the guide on images and video in sponsored posts covers. This guide is not legal advice; if you are unsure about a licence or copyright question, ask the rights holder or a qualified lawyer.
Rights questions for every cover
- Do you own the image, or is it licensed, and is there a licence record?
- Does the licence allow commercial online use, cropping and resizing?
- If attribution is required, is it visible on the page?
- Does the picture show identifiable people, brands or artworks that need extra permission?
- If the image was generated or edited with AI tools, do the terms of use fit your publishing purpose?
Archive covers deserve the test too
The Discover documentation notes that older content can appear when it is helpful and relevant to someone's interests. Image work therefore should not stop at new posts. Pick the archive pages that still attract readers and run their covers through the same test. Old covers are often small and fail the width requirement. For an archive pass, check width first, the robots tag second and the licence record last.
A six point image test before publishing
The test below checks a cover against the documentation before you press publish. Each item gets a yes or no, and a single no means the image needs work.
Checks to pass before publishing
- Width: is the image at least 1200 px wide with more than 300,000 total pixels?
- Ratio: is it 16:9, or is a landscape crop ready?
- Crop: do the subject and key details survive the landscape frame?
- Content: does the image represent the page and avoid logos or heavy text?
- Permission: does the published source have a single robots tag, with max-image-preview:large not restricted by another rule?
- Rights and access: is the right to use the image confirmed, and can its URL be crawled?
Division of work
The editor confirms that the image represents the story. The designer prepares size, ratio and crop. A technical owner verifies the robots tag and the crawlability of the image. Whoever handles rights completes the licence record. On a small team one person may hold all four roles, in which case running the six checks in order before publishing gives a sufficient safeguard.
Case: a street market story on a city news site
A city news site is about to post a story on a street food market. The cover is the 1080x1080 square made for social media, with the site logo in one corner. The checks fail on width, ratio, crop and content: a landscape cut would slice off the stalls, and the logo is exactly the generic element the documentation discourages. The team goes back to the larger original, prepares a 1600x900 landscape frame with the stalls in the middle and drops the logo. They confirm that the published source holds a single robots tag and complete the licence record. The result does not guarantee Discover exposure. It shows that the documented requirements have been met.
Once the page is live
Once the page is live, view the source from outside your CMS to see that the robots tag is present, and open the image URL in a browser. The URL Inspection tool in Search Console can show how Google sees the page. To follow results, remember that the Discover report appears only after the property reaches a minimum number of impressions.
Typical slips and fixes
| Mistake | Consequence | Fix |
|---|---|---|
| Using the social media card as the cover | Width may fall below 1200 px | Create a separate landscape cover |
| Trusting the plugin screen instead of the page source | Conflicting tags go unnoticed | Read the published source |
| Disallowing image URLs in robots.txt | The image cannot be crawled | Remove the block |
| Assuming a licence from the collection page | Risk of infringement | Verify at the asset level |
Related guides: Video and Discover Visibility for Publishers, YouTube Video Descriptions and Chapters: Writing Guide, How to Read the Google Discover Performance Report.
Conclusion
A large image for Discover has three parts: the max-image-preview:large permission in the robots meta tag, a file at least 1200 px wide with more than 300,000 pixels, and a crop that holds up in a landscape frame. Check the published source, because conflicting rules and blocked pages can undo the permission, and keep in mind that Google's pages set no file format requirement, so WebP is a speed choice. Licensing is your editorial responsibility, and this guide is not legal advice. Run the six checks on every cover, because careful preparation, though it guarantees nothing, is more consistent than a one time attempt.
If you would like strong editorial content with good imagery placed on relevant sites, take a look at our guest post service.
Frequently Asked Questions
What does max-image-preview:large do?
According to Google's robots meta documentation, it says that a larger image preview, up to the width of the viewport, may be shown for the page. The Discover documentation lists large previews among its image requirements. It is a permission and does not guarantee display.
How big should a Discover image be?
The documentation asks for at least 1200 px width and more than 300,000 total pixels, with 1280x720 as an example, in a 16:9 ratio. Limits can change, so check the current page before applying them.
Do I need WebP for Discover?
The Discover documentation does not set a file format requirement. WebP is usually chosen for page speed. What matters is width, crawlability and relevance to the page.
Can the cover image carry the headline text?
The documentation advises against text heavy images. The card already shows the headline, so repeating it in the image is unnecessary and may be unreadable on small screens.
What if the page has two robots meta tags?
Google says the more restrictive rule applies when rules conflict. Check the published page source to make sure no other rule limits the large preview.
Can I use a stock photo as my cover?
It depends on the licence. Google's Discover and robots pages do not state licence terms, so verify the usage rights at the asset level. This guide is not legal advice; if in doubt ask the rights holder or a qualified lawyer.
Post a comment
Please log in to leave a comment. Login