Why Google Shows a Different Image for Your Page Than the One You Chose

You publish a page with a carefully chosen hero image. You set the Open Graph tag. You check it renders.

The search result shows your footer logo.

Or an icon from the sidebar, or the author avatar, or an image from three sections down that has nothing to do with the title. This is one of the more irritating problems in the field because it looks like a settings issue and is not one. There is no field labelled "image to show in search results".

How the choice is actually made

The mental model that helps: nothing you provide is an instruction. Everything you provide is evidence, and the selection is a judgement made per query and per result format about which image best represents this page for this search.

That judgement takes in the images present on the page and their prominence, whatever structured data declares, the markup you have supplied, technical eligibility such as dimensions and crawlability, and the relationship between image and page content.

Which means the question is never "how do I set it" but "why is a different image winning". There are four common answers.

Reason one: your intended image is not eligible

This is the most frequent cause and the easiest to miss, because the image is clearly visible to you.

Delivery method	Eligible as a page image	Note
Standard img element	Yes	The reliable case
CSS background-image	No	Invisible as a page image
Inline SVG	Rarely	Generally not treated as a photograph
Lazily loaded with a JS library	Sometimes	Depends on whether the real src is discoverable
Native loading="lazy"	Yes	Fine, this is the supported mechanism
Behind a carousel, non-first slide	Often not	Only the initially rendered slide is reliably seen
In a tab or accordion, closed by default	Often not	Same problem

A hero implemented as a CSS background is the classic version. It is the largest, most prominent thing on the page to a human and does not exist as an image element at all. The logo in the header does exist as one, so the logo wins.

Carousels are second. If your best image is slide three, it may as well not be there.

If the intended image genuinely is not being crawled at all, that is a broader problem than thumbnail selection and worth resolving first, since the diagnostic path for images that never appear in Google Images covers the crawl and index layer that everything here sits on top of.

Reason two: it is too small

Requirements for display are more demanding than requirements for indexing. An image can be perfectly well indexed and still be ineligible to appear as a preview because it does not meet the resolution bar, and that bar is higher than typical thumbnail dimensions.

The trap is a well-optimised responsive setup where the source in the markup is the small variant. Everything about that is good practice, and it can leave no version large enough to be used as a preview. Supply a genuinely large original and let srcset and sizes serve appropriate variants to devices rather than capping the largest available version.

Reason three: the signals disagree

Different surfaces read different inputs, and it is common to have them saying different things without realising it.

• og:image is read by social platforms and messaging apps, which generally honour it directly.
• twitter:image does the same for that platform.
• Structured data image fields are read by search and are the strongest lever available for search results specifically.
• The images actually on the page carry their own weight regardless of any tag.

A page whose og:image is a branded card with text on it, whose structured data names a different file, and whose visible hero is a third image has given three answers. Social will show the card, search will pick from the other evidence, and the result feels arbitrary from the outside.

The fix is alignment: the same image, or at least the same subject, across all of them. How Open Graph images and search images differ in purpose is the underlying distinction, and the practical consequence is that a social card designed with text overlays is often a poor choice for search precisely because it is a graphic rather than a photograph.

Structured data is where to invest if you want the most influence. An image declared on the page's primary entity type is a clear, machine-readable statement of which image represents this page. Using ImageObject and related markup properly is worth doing carefully, since it is simultaneously the strongest selection signal and the mechanism for licensing information in image results.

Reason four: the wrong image genuinely looks more relevant

Sometimes the selection is defensible and the page is the problem.

If your hero is an abstract gradient and the page contains one concrete photograph of the actual subject, choosing the photograph is reasonable. If the title promises a specific thing and the hero is decorative, an image further down that actually depicts the thing is a better representative.

This shows up on templated pages where the hero is chosen by layout rather than by content. The remedy is not markup. It is putting a genuinely relevant image at the top, which is what choosing images that depict the actual work is about, and which fixes the problem at its source rather than arguing with the selection.

What to do, in order

1. Check how the intended image is delivered. View source, not devtools' rendered view. Confirm it is an img with a real src visible in the initial HTML.
2. Check its dimensions. The largest available version, not the one currently served to your viewport.
3. Reconcile your signals. og:image, twitter:image, structured data image and the visible hero should agree.
4. Check max-image-preview. A restrictive robots directive suppresses large previews and is sometimes set site-wide by a plugin. Worth ruling out, particularly if previews disappeared abruptly.
5. Confirm the image is crawlable. Not disallowed in robots.txt, not behind a login, not hotlink-protected in a way that blocks crawlers.
6. Ask honestly whether it is the most relevant image on the page. If not, fix that instead.
7. Wait. Changes take days to weeks. Social platforms cache separately and usually offer a debug tool that forces a refresh.

Steps one and two resolve the large majority of cases, and both are ten-minute checks.

One thing not to do is keep changing the markup while waiting. Because updates take days to weeks, a sequence of adjustments made every few days produces a result you cannot attribute to any one of them. Make the change, note the date, and leave it alone long enough to learn something.

Different surfaces, different answers

Part of what makes this confusing is that people compare outcomes across surfaces that never used the same inputs, then conclude something is broken.

Surface	Primary inputs	How much control you have
Standard web result thumbnail	Page images, structured data, relevance to query	Influence only
Image search result	The image itself, its page context, alt text and filename	Influence only
Discover-style feeds	Large page images, structured data, preview directives	Influence, and large images matter more
Social share preview	og:image and twitter:image	Effectively direct control
Messaging app preview	og:image, occasionally the first page image	Mostly direct control

The practical consequence is that a mismatch between your social preview and your search thumbnail is normal and usually means both are working as designed. The og tag is being honoured where it applies, and search has made its own judgement where it does not.

It also explains why a branded card with text overlaid is a reasonable og:image and a poor candidate for search. A graphic dense with words is exactly what social previews are built for and exactly what a search thumbnail tends not to favour, which is a solid argument for supplying a genuine photograph on the page and reserving the composed card for the og tag.

The one surface where large images matter disproportionately is the feed-style presentation, which strongly favours high-resolution imagery and is where a restrictive preview directive causes the most visible loss. If a page performs in normal results and never appears in feed-style surfaces, the preview directive and image dimensions are the first two things to check.

Setting expectations

Even done perfectly, there is no guarantee. Different queries can produce different images for the same page, and result formats change over time. The realistic target is making the correct image the obvious choice, not forcing it.

That tends to be achieved by unremarkable means: a large, relevant, genuinely descriptive image, delivered as a normal element near the top of the page, declared in structured data, matched by the og tag, with alt text that says what it shows. The standard pre-publish checklist covers most of this, which is another way of saying that the pages where the right image gets chosen are usually the pages where nothing was skipped.

If images across your site are generated rather than sourced, the delivery and markup questions above are unaffected — but filenames, alt text and metadata arriving correct at creation removes the most common reason an otherwise fine image has nothing useful attached to it. See what SEOpix writes automatically, or try ten images free and check how they present on a real page.