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

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 robots meta tag can contain several directives on one line. Some are familiar, such as noindex and nofollow, while others are less well known, including max-snippet, max-video-preview, and max-image-preview.

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.

A value of “large” does not mean Google will automatically show a large image. It is a permission setting—a limit that says, “You may display this as large as this.”

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.

As users scroll, they see large photos and short headlines—not blocks of text.

The format itself depends heavily on imagery.

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.

I have seen these situations firsthand on several sites. The assumption that “WordPress handles it by default” is theoretically correct, but in real operating environments, multiple plugins and themes interfere with one another and quietly break that assumption.

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.

And the site owner receives no direct notification of that decision.

It simply appears as a gradual decline in traffic. I consider this the most frightening kind of problem.

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.

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.

These are conditions at different levels, and both must be satisfied.

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

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.

That is why, unlike other settings, I chose not to leave this one to the user’s discretion and instead enforce it one final 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.