How to Set WordPress Featured Images the Right Way
- max-image-preview:large — The essential requirement for appearing as an image card and how to enforce it automatically
- The robots meta tag is a collection of directives, not a single instruction
- Why is this especially critical for Discover?
- WordPress enables it by default, so why enforce it again?
- The problem is that it breaks quietly
- That is why I added one more safeguard at the end
- Understanding how it relates to the 1,200-pixel rule
- Conclusion: Setting up featured images in SOHO SEO
max-image-preview:large — The essential requirement for appearing as an image card and how to enforce it automatically
In my previous article, I explored how Article JSON-LD can structurally demonstrate the credibility of a piece of content.
At the end of that article, I briefly mentioned enforcing max-image-preview:large in the robots meta tag. This time, I’m taking a closer look at that single setting.
Why is a seemingly insignificant meta tag value an essential condition for appearing in Discover? And why shouldn’t you simply assume it’s taken care of because “it’s enabled automatically”? Those are the questions I want to address here.

The robots meta tag is a collection of directives, not a single instruction
Many people think of the robots meta tag as something that only determines whether a page may be indexed.
I also discussed this tag when covering noindex management.
The last three directives control how much of a page’s content Google may preview, and how prominently it may display that preview, in search results or the Discover feed.
max-image-preview has three possible values.
none disables image previews altogether. standard allows only a small preview. large permits Google to show a large image.
There is an important distinction here.
Whether Google actually displays a large image depends on the image’s quality and dimensions, along with other signals.
But if the limit is set to standard or none, the page is disqualified from appearing as a large card in the first place, no matter how good the image is.
Why is this especially critical for Discover?
In ordinary search results, a lower setting has a relatively limited impact.
Search results are primarily lists of text links, with images playing a supporting role. Discover is different.
Discover is fundamentally an image-driven, card-based feed.
As users scroll, they see large photos and short headlines—not blocks of text.
The format itself depends heavily on imagery.
That is why, if max-image-preview is not set to large, it is much like being ineligible to enter the Discover channel at all. I think of it as standing outside a party without a pass.
You can show up in your best outfit, but without a pass, you still cannot get inside.
WordPress enables it by default, so why enforce it again?
That raises an obvious question.
WordPress has reportedly set this value to large by default since version 5.7, so why does SOHO SEO enforce it again? I can answer that directly.
After examining sites in active operation, I found that this default is easier to break than you might expect.
There are several real-world scenarios.
First, another SEO plugin may rebuild the robots meta output in its own way and omit this value.
Multiple plugins can attach themselves to WordPress’s wp_robots filter, and depending on the execution order, a later filter can overwrite values set by an earlier one.
Second, a caching or security plugin may filter out tags it considers “unnecessary” while optimizing headers and meta tags.
Third, custom robots meta output code that someone added to the theme’s functions.php file years ago may still be there, creating a conflict with the core default.
The problem is that it breaks quietly
What I consider truly dangerous is that this problem occurs without any visible warning.
If an image breaks, you notice it immediately. If text fails to appear, that is obvious too.
But if the robots meta value quietly changes from large to standard, the page can look perfectly normal when viewed by a human.
The page renders correctly, and the image displays as expected.
The problem appears only when Google decides whether to show that page in Discover.
And the site owner receives no direct notification of that decision.
There is a long delay between cause and effect, and the cause itself is invisible.
That is why I added one more safeguard at the end
My solution to this problem is straightforward.
Regardless of how other code has modified the value, SOHO SEO forces it back to large at the end of the wp_robots filter chain.
It overwrites only this directive, regardless of what value was there before.
I treat it as a non-negotiable setting.
Other SEO settings remain configurable, but I made an exception for this one.
The reason is clear: it is difficult to imagine a user deliberately wanting this value set to anything other than large.
There are very few situations in which someone would intentionally want to reduce an image preview or remove it altogether.
In that case, I decided that locking the setting to the optimal value would serve users better than giving them a choice.
Understanding how it relates to the 1,200-pixel rule
It is important to clarify how this relates to the 1,200-pixel featured-image rule discussed in my previous checklist article.
max-image-preview:large is permission for Google to display the page’s image at a large size.
A 1,200-pixel featured image answers a different question: is there actually an image with enough quality to be shown large? Permission alone is not enough; if the image quality is poor, there is no reason to display it as a large card.
Conversely, if the image is excellent but the permission is blocked by the robots meta tag, the page is excluded from consideration before that image can help it.
I designed these as a pair and placed them next to each other in the checklist. The most common mistake is to check only one of them and assume everything is fine.
Conclusion: Setting up featured images in SOHO SEO
max-image-preview:large may look like just one meta tag value, but it is the minimum eligibility requirement for participating in Discover, an image-driven channel.
Rather than taking comfort in the fact that WordPress enables it by default, you should assume that this value can be quietly changed in a real-world environment where multiple plugins and themes operate on top of one another.
When a problem can quietly break something out of sight, the system should protect against it automatically rather than relying on people to check it every time.
In the next article, I’ll move on to another part of index management: the “Index Selection” feature.
I’ll explain how I built a safeguard that can apply noindex selectively to archive pages without ever affecting posts or pages.

This article was designed using DECOBLOCKS.