Paste a link into Slack, Facebook, or a text message and a card pops up: a headline, a snippet of description, and a picture. That picture didn’t appear by magic. WordPress, together with whichever SEO plugin you’re running, decided which image represents that page and handed it to the platform doing the preview. Understanding how that decision gets made, and how to override it, saves you from the awkward experience of sharing a post only to watch the wrong image, or no image at all, show up in the preview card.
This piece walks through the mechanics behind preview images: what WordPress uses by default, how Open Graph tags actually work, what happens when nothing is configured, and how to troubleshoot the most common cases where the wrong image shows up.
The Short Answer: Featured Image, Then Fallbacks
In the vast majority of properly configured WordPress sites, the preview image is your post’s featured image (sometimes called the “post thumbnail”). This is the image you set in the “Featured Image” panel of the block editor or Classic Editor sidebar. It’s used across the site in multiple contexts: on archive pages, in RSS feeds, in related-post widgets, and as the default source for social sharing previews.
If no featured image is set, most modern setups fall back through a short chain: first checking for the first image embedded in the post content, then falling back to a site-wide default image if your SEO plugin has one configured, and finally falling back to nothing (a text-only preview card) if none of those exist.
Open Graph Tags: The Actual Mechanism
The featured image alone doesn’t control what shows up when a link is shared. What actually controls it is a set of HTML meta tags in your page’s <head> section, known as Open Graph tags, originally defined by Facebook but now read by nearly every platform that generates link previews (Twitter/X, LinkedIn, Slack, Discord, WhatsApp, and search engines to a lesser degree).
The specific tag that controls the preview image is:
<meta property="og:image" content="https://example.com/wp-content/uploads/2026/01/photo.jpg" />
When you paste a URL somewhere, that platform’s crawler fetches the page, reads this tag (among a handful of others like og:title and og:description), and builds the preview card from whatever it finds. If og:image is missing entirely, most platforms fall back to grabbing the first <img> tag they find in the rendered HTML, though this behavior varies by platform and isn’t guaranteed.
WordPress core does not generate Open Graph tags by default. That job is handled by whichever SEO plugin you have active, most commonly Yoast SEO, Rank Math, or All in One SEO, all of which auto-populate og:image from your featured image unless you’ve manually overridden it.
How to Set and Override the Preview Image
Setting the Featured Image (the Baseline)
In the block editor, this lives in the document sidebar under “Featured image.” Click “Set featured image,” choose or upload a picture, and save the post. This single step handles the preview image for the overwhelming majority of use cases, since your SEO plugin will typically pick it up automatically for the og:image tag.
Overriding Per-Post Through Your SEO Plugin
Sometimes the featured image you want for the post header isn’t the image you want shown in a social preview card, maybe the featured image is a tall vertical photo that crops awkwardly into a wide preview card, and you’d rather use a differently cropped or composed version specifically for sharing.
Yoast SEO, Rank Math, and All in One SEO all expose a “Social” tab in their per-post metabox where you can upload a separate image specifically for og:image, independent of the featured image. This override always takes priority over the featured-image fallback when it’s set.
Setting a Site-Wide Default
For posts or pages that don’t have a featured image at all (an FAQ page, a simple contact page), most SEO plugins let you configure a site-wide fallback image under their general social settings (in Yoast, this lives under SEO > Social > Facebook; in Rank Math, under Titles & Meta > Global Meta > Social). Setting this prevents your generic pages from sharing with a blank, imageless card.
Recommended Image Dimensions
Preview images aren’t displayed at their native size, platforms crop and scale them into a fixed aspect ratio, and an image with the wrong proportions can get cropped in unflattering ways (a face cut in half, important text pushed out of frame).
| Platform | Recommended Size | Aspect Ratio |
|---|---|---|
| Facebook / Open Graph general | 1200 x 630px | 1.91:1 |
| Twitter / X (summary_large_image) | 1200 x 675px (min 300 x 157px) | ~1.91:1 |
| 1200 x 627px | ~1.91:1 | |
| Pinterest (if applicable) | 1000 x 1500px | 2:3 (vertical) |
1200 x 630px is the practical sweet spot most sites design around, since it satisfies Facebook, LinkedIn, and Twitter’s requirements close enough that you don’t need separate images per platform. If your featured images are being used as source photography rather than purpose-built preview graphics, consider designing a dedicated 1200 x 630px template with your logo, title text overlay, and consistent branding, this is standard practice for content-heavy sites and noticeably improves click-through when links are shared.
Why the Wrong Image (or No Image) Shows Up
A handful of specific causes account for almost every “wrong preview image” support ticket:
No featured image and no site-wide fallback configured. The post shares with a blank or generic placeholder because there’s genuinely nothing for any platform to pull from.
Cached preview data on the sharing platform’s side. Facebook, LinkedIn, and similar platforms cache the Open Graph data they scrape the first time a URL is shared. If you change the featured image after the URL has already been shared once, the old cached preview can persist for that platform even though your site is serving updated data. Facebook has a Sharing Debugger tool, and LinkedIn has a Post Inspector, both let you force a re-scrape of a specific URL.
An image that’s too small. Most platforms enforce a minimum image size (often around 200 x 200px, sometimes larger for large-image card formats) and will silently refuse to display anything if your image falls under that threshold, defaulting instead to a text-only card.
A conflicting plugin or theme setting overriding the SEO plugin’s tag. If you’re running more than one SEO or social-sharing plugin simultaneously, or a theme that injects its own Open Graph tags, you can end up with duplicate og:image tags in the page’s HTML, and platforms typically use whichever one appears first, which may not be the one your SEO plugin intended.
Server-side image restrictions. Some hosting or CDN configurations block external crawlers (including Facebook’s and LinkedIn’s scraper bots) via firewall rules meant to stop bad bots, which prevents the preview image from loading at all even though the tag itself is correct.
Checking What Tags Your Page Actually Outputs
Rather than guessing, view the raw HTML your site outputs for a given page. Right-click the page in a browser and choose “View Page Source,” then search (Ctrl+F or Cmd+F) for og:image. You’ll see the exact URL being sent to sharing platforms, which tells you immediately whether the problem is a missing tag, a wrong URL, or a duplicate tag pointing two different directions.
For a faster check without digging through source code, both Facebook’s Sharing Debugger and Twitter’s Card Validator (where still available) will show you exactly what image, title, and description their crawlers are reading from a given URL, along with any errors they hit trying to fetch it.
A Note for Community and Membership Sites
On a BuddyPress-powered community site, members frequently share activity posts, group updates, and profile links outside the platform, in emails, in other social networks, in messaging apps. The same Open Graph mechanics apply to these dynamically generated pages, though the source image is usually pulled from the member’s avatar or group avatar rather than a manually set featured image, since there’s no “post” in the traditional sense behind a member profile URL. If your community theme or a BuddyPress add-on doesn’t output Open Graph tags for these dynamic pages by default, shared profile and group links can end up with a generic or missing preview image even when the rest of your content shares correctly, worth checking specifically if member engagement relies on people sharing their profiles or group invites externally.
Twitter/X Card Types: A Separate Layer
Twitter (now X) historically used its own meta tag namespace, prefixed twitter: rather than og:, though the platform will fall back to reading standard Open Graph tags if Twitter-specific ones aren’t present. There are two card types relevant to image previews:
summary: a small, square-ish thumbnail alongside the title and description, roughly the layout used when no large image is specified.summary_large_image: the wide, prominent image card most people associate with a well-formatted tweet link, this is the format nearly every site wants.
SEO plugins generally default to summary_large_image automatically, but it’s worth confirming in your plugin’s social settings if your links are showing up with the smaller thumbnail card instead of the wide format you expect.
Image Format and File Size Considerations
Not every image format behaves identically across sharing platforms. A few practical notes:
JPEG and PNG are universally supported and remain the safest default choice for both featured images and dedicated social images.
WebP support is inconsistent. Modern browsers render WebP fine, and WordPress has supported WebP uploads for several versions now, but some social platforms’ scrapers historically had spotty WebP support for preview generation specifically, even when the format displays correctly everywhere else on your site. If you’re seeing missing previews specifically on a site that’s converted its media library to WebP, this is worth testing directly.
SVG images generally don’t work as preview images at all. Most platforms’ scrapers expect a raster image and will either reject an SVG outright or fail silently, leaving you with a blank card. If your logo or a graphic element is stored as SVG, don’t rely on it as your og:image source.
File size matters less than dimensions, within reason. Platforms generally don’t publish a hard file-size cap for Open Graph images, but an unusually large, unoptimized upload can slow down the scraper’s fetch and occasionally cause a timeout on slower hosting. Standard image optimization practice (compressing to a reasonable file size for a 1200 x 630px image, typically well under 1MB) avoids this entirely.
RSS Feeds and the Featured Image
Featured images don’t automatically appear inside your RSS feed’s content by default, WordPress core doesn’t inject the featured image into the feed’s post body unless your theme or a plugin explicitly adds it. This matters if you syndicate content to email newsletters or feed readers and notice posts arriving without any image at all, despite the featured image displaying correctly on your actual site. A short filter added to your theme’s functions.php, or a dedicated “featured image in RSS” plugin, resolves this by hooking into the_excerpt_rss or the_content_feed to prepend the image.
Dynamically Generated Preview Images
Some sites skip manually designing a preview image per post entirely and instead generate one programmatically at request time, pulling the post title, category, and a background template into a single composited image on the fly. This is common on content-heavy blogs and news sites that publish at high volume, where designing a custom graphic for every single post isn’t practical. If you’re evaluating this approach, look for a plugin (or a custom solution using a service like an image-generation API) that outputs to a stable URL your SEO plugin can reference as the og:image source, and test the generated output through the debugging tools mentioned above before rolling it out site-wide, since a broken dynamic image generator affects every post’s preview simultaneously rather than just one.
Frequently Asked Questions
Does the featured image need to be the same image used in the post body?
No, they’re independent. You can use one photo as the featured image (and by extension, the default preview image) while using entirely different images throughout the post’s actual content.
Why does my preview image look fine on Facebook but broken on Slack?
Each platform runs its own scraper with its own caching behavior and its own minimum size requirements. It’s entirely possible for one platform to have cached an old version of your page while another fetches fresh, or for one platform’s size requirements to reject an image another platform accepts without complaint.
Can I use a video as the preview instead of a static image?
Some platforms support an og:video tag alongside or instead of og:image, but support and behavior vary significantly by platform, and a static fallback image is still recommended even when video preview tags are present, since not every platform or context (an email client, for instance) will render the video tag.
Does the preview image affect SEO ranking directly?
Not as a direct search ranking factor in the traditional sense, Open Graph tags are built for social sharing platforms, not primarily for search engine ranking algorithms. Indirectly, though, a compelling preview image can improve click-through rates wherever your link is shared, which is a meaningful practical benefit even without a direct ranking mechanism behind it.
Debugging Tools Worth Bookmarking
A short list of the tools that actually save time when a preview image isn’t behaving:
- Facebook Sharing Debugger. Paste a URL and it shows exactly what Facebook’s crawler currently has cached, along with a button to force a fresh scrape. This is the single most useful tool for the “I changed the image but the old one still shows” problem.
- LinkedIn Post Inspector. Same concept, LinkedIn-specific, with its own separate cache from Facebook’s.
- Browser “View Page Source.” No tool required, just search the raw HTML for
og:imageto confirm exactly what URL your site is outputting, before worrying about what any external platform is doing with it. - Your SEO plugin’s built-in preview. Yoast, Rank Math, and All in One SEO all render a live preview of how a post’s social card will look, directly in the post editor, which catches obviously wrong images before you ever publish.
Working through these in order, confirm the tag is correct in your own source first, then check whether a specific platform has a stale cached version, resolves the overwhelming majority of preview image complaints without needing to touch any plugin settings at all.
Quick Troubleshooting Checklist
- Does the post have a featured image set at all?
- Is your SEO plugin’s social override empty, or is it pointing at an outdated image?
- Have you re-scraped the URL through Facebook’s Sharing Debugger after making a change?
- Is the image at least 200 x 200px, ideally closer to 1200 x 630px?
- Does “View Page Source” show one clean
og:imagetag, or duplicates from conflicting plugins? - Is your hosting firewall blocking known social crawler user agents?
- Is the image an SVG or an unusually large unoptimized file that a scraper might time out on?
WordPress itself doesn’t make the preview-image decision in isolation, it’s a handoff between your featured image setting, your SEO plugin’s Open Graph output, and the specific platform reading that output. Once you understand which layer is responsible for what, tracking down a wrong or missing preview image usually takes a few minutes rather than a guessing game.
It’s worth building a habit of checking the social preview any time you publish something you expect people to share widely, an announcement, a big roundup post, a launch. Open the post in an incognito browser tab, paste the live URL into Facebook’s Sharing Debugger before promoting it anywhere, and confirm the card looks the way you want. That thirty-second check, done before the link goes out rather than after someone points out it looks wrong, is a lot cheaper than trying to force a re-scrape across five different platforms after the fact.
Interesting Reads:
Should I Upload Entire WordPress Site At Github