Article lacks max-image-preview:large
discover_image_previewShort answer
This page is an article but its robots meta tag does not include max-image-preview:large. Google Discover and some search features use large image previews only when the page allows them; without the directive the default is a standard-size thumbnail, which Google says reduces Discover visibility. This issue affects rich results in search. Add max-image-preview:large to the robots meta tag and make sure the article image is at least 1200 px wide.
Why it matters
Discover is a significant traffic source for news and content sites, and Google's own guidance for Discover is to use large, high-quality images and enable the large preview. The directive costs nothing and has no downside for the page.
How Glimana detects it
The rule fires for pages detected as articles (Article-type structured data present) when the robots meta tag or X-Robots-Tag header does not contain max-image-preview:large.
How to fix it
- Find the affected pages in Glimana. Open Issues › Article lacks max-image-preview:large. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Add to
<head>:<meta name="robots" content="index, follow, max-image-preview:large">WordPress core adds
max-image-preview:largesince 5.7 unless a plugin overrides the robots tag; check your SEO plugin's settings (Yoast: on by default; Rank Math: Titles & Meta › Robots Meta › "Max Image Preview"). Also make sure featured images are ≥ 1200 px wide.Add the meta tag to
layout/theme.liquidinside{% if template contains 'article' %}(or site-wide; it is harmless on other pages).Emit the directive in the layout for article routes, or send it as a header:
X-Robots-Tag: max-image-preview:large. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the directive is present on the page. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the directive is present on the page.