Social Share Images and SEO Images Are Two Different Jobs

A surprising amount of confusion in image work comes from treating "the image for the page" as one object. It is two, and they are optimised against different constraints by different consumers.

The share image is scraped by Facebook, LinkedIn, X, Slack, WhatsApp and iMessage when someone posts a link. Its audience is a human scrolling past at speed. It never appears in a search result.

The content image is what a visitor sees on the page and what Google Images can index. Its audience is a reader who has already arrived, plus a matching system that has no interest in typography.

Optimising either one by the other's rules produces predictable failures: a share image nobody can read because it was composed for image search, or a hero image full of baked-in marketing text because someone applied social advice to it.

The specification, in one table

Property	Share image	Content image
Typical dimensions	1200 × 630 (1.91:1)	Whatever the layout needs
Declared by	og:image meta tag	The <img> element
Consumed by	Social platforms, messaging apps	Browsers, Google Images
Format	JPEG or PNG — safest for scrapers	WebP or AVIF, with fallback
Text on the image	Usually helpful	Usually harmful
Alt text	og:image:alt	alt attribute
Affects search rankings	No	Indirectly, via page quality and speed
Cached by	The platform, sometimes for months	The browser and CDN

The rows that surprise people are the format and text rows, and both come from the same fact: a share image is rendered by a scraper's own pipeline into someone's feed, while a content image is served by your site to a browser.

Format: the one place to stay conservative

Everywhere on the page, modern formats are the right answer. WebP is universally supported by browsers, AVIF compresses better still, and the format comparison between WebP, AVIF and JPEG works through when each is worth the encode cost.

Social scrapers are not browsers. Support for modern formats across the major platforms and the long tail of messaging apps is inconsistent, and the failure mode is not a fallback — it is a preview card with no image at all, or a bare link. Since the share image is a single file per page and not a bandwidth concern, the trade is easy: serve JPEG or PNG for og:image, and use the modern formats for everything the browser renders.

The tags that matter

Minimum viable markup for a page:

• og:title, og:description, og:url, og:type — the text half
• og:image — an absolute URL, not a path
• og:image:width and og:image:height — lets a platform reserve layout before the fetch completes
• og:image:alt — alternative text for the preview
• twitter:card set to summary_large_image

The absolute-URL requirement is the most frequent single error. A relative og:image value validates in a code review and produces nothing in a preview, because the scraper has no page context to resolve it against.

The twitter:card value matters more than people expect. Without it, X may render a small square thumbnail rather than the wide card, so a perfectly composed 1200 × 630 image gets centre-cropped into a square and loses both ends of its headline. One meta tag prevents it.

You generally do not need a separate twitter:image — the platform falls back to og:image — but if you want a differently composed image for that specific feed, that is where it goes.

Composition: build for a thumbnail

A share image is frequently displayed at a fraction of its resolution and often centre-cropped by the platform. Compose accordingly.

• Keep the essential content in the middle 80%. Assume the edges may be cropped.
• Use type large enough to survive. If it is not readable at 400 pixels wide, it is not readable.
• High contrast, few elements. A feed is a hostile viewing environment.
• Keep branding small and consistent. A logo in a corner is recognition; a logo across the middle is a billboard nobody asked for.
• Do not repeat the headline verbatim. The title text sits directly beneath the image in every platform's card. Repeating it wastes the only visual you get.

This is also the reason generated imagery works well as a background for share images and poorly as the whole thing. A clean photographic backdrop with a type layer on top composes reliably; a busy generated scene with text fighting it does not. If you are producing the backdrop, the craft of prompting for photographic rather than illustrative output applies here as much as anywhere.

Generating share images automatically

For a site with more than a handful of pages, hand-designing each share image does not scale, and the common fallback — one generic image for the whole site — produces link previews that all look identical in a feed.

The middle path most modern frameworks now support is to render the share image at request time from a template: a background image plus the page title, category and logo, composed by the server into a PNG at a stable URL. Next.js exposes this through its image-response API, and equivalent approaches exist for most stacks.

Two rules if you do this:

1. Cache the output. Rendering an image per scrape is slow and the platform will time out. Cache aggressively and key on the page.
2. Give each page a distinct URL for its share image. This is what makes cache-busting possible later, and it is what prevents the whole site sharing one cached preview.

Messaging apps are the forgotten consumer

Most advice on share images is written about the social networks, and for a great many businesses the larger share of link previews is generated somewhere else entirely: WhatsApp, iMessage, Slack, Teams, Signal, Discord. A link pasted into a group chat is a distribution channel, and it renders under different rules.

Three differences worth designing for.

Aspect ratio is less predictable. Several messaging clients render a small square or a compact horizontal strip rather than the wide card social platforms use. A 1200 × 630 image with content near the left and right edges loses those edges entirely. This is the strongest single argument for keeping essential content centred.

File size limits are tighter and quieter. Some clients decline to fetch large previews and fall back to a bare link with no visible error. If a preview works everywhere except one messaging app, weight is the first thing to test — keeping the share image comfortably under a megabyte removes the variable.

Caching is per-client and opaque. There is no debugger for most messaging apps and no way to force a re-scrape. This makes the "publish at a new URL" approach more attractive than it looks from a purely social perspective, because it is the only method that works in an environment you cannot inspect.

None of this changes the specification. It changes the composition: centre the content, keep the file small, and check a real preview in whichever chat app your customers actually use before assuming the social platforms are representative.

Caching, and why your fix appears not to work

The single most common support question in this area: someone updates a share image, re-posts the link, and sees the old one.

Platforms cache the outcome of a scrape. Replacing the file at the same URL does not invalidate that cache, and there is no header you can set that reliably forces a re-fetch across every platform. Two remedies:

Change the URL. Publish the new image at a new path, or append a version query string, and update the tag. This works everywhere because it is a different resource.

Force a re-scrape. Facebook's Sharing Debugger and LinkedIn's Post Inspector both re-fetch a URL on demand and show what they parsed, which is also the fastest way to diagnose a preview that is not rendering at all.

Whichever you use, check the preview before a launch rather than after. A link posted to a large audience with a broken card cannot be fixed retroactively for the people who already scrolled past it.

Where the content image gets the attention instead

Everything above concerns one file per page. The rest of your image work — the part that actually earns search traffic — has different priorities:

• Filenames that describe the subject, because the URL is one of the few textual signals attached to an image file. The rules for SEO-friendly image filenames are the fifteen minutes with the best return in image work.
• Alt text written for a person, not for a keyword slot.
• Weight and dimensions matched to the layout, since the hero is frequently the Largest Contentful Paint element and therefore a Core Web Vitals problem before it is an SEO one.
• Metadata written into the file so attribution survives the copy.

None of those apply to the share image, and none of the share image's rules apply to them. Keeping the two sets of rules separate in your head is most of the work.

A five-minute check for any page

1. View source and confirm og:image is an absolute URL.
2. Confirm the file is JPEG or PNG, 1200 × 630, under about a megabyte.
3. Confirm twitter:card is summary_large_image.
4. Paste the URL into a platform debugger and look at the rendered card.
5. Separately, check the page's actual hero image: descriptive filename, real alt text, sensible dimensions, modern format.

Steps one to four are the share image. Step five is the SEO one. If you only ever do step five, your pages will earn search traffic and look broken when anyone shares them — which is a shame, because the fix is four meta tags.

SEOpix produces the photographic backgrounds for both jobs with filenames and metadata already written in. Compare the plans or try the free tier if you want to see what comes out of the box.