Open Graph image for a landing page: why the share preview changes everything
Published on 4 August 2026 · 7 min read
The scenario is common: you paste your landing page link into a LinkedIn message, an X post, or a WhatsApp group, and instead of an engaging preview, nothing shows up — or a broken preview, a generic image, a truncated title. The link lands in the feed as a grey line of text among dozens of illustrated posts. Most conversion effort focuses on what happens after the click — the headline, the CTA, the form. But a poorly prepared link loses part of its clicks before the page even loads, at the moment someone decides, in a split second while scrolling a feed, whether that rectangle is worth a click.
What shows up before anyone even reaches the page
When a link is pasted into LinkedIn, Facebook, WhatsApp, Slack, or X, the platform doesn't display the raw URL — it looks in the page's <head> for Open Graph tags — og:title, og:description, og:image — standardized by the Open Graph protocol introduced by Facebook in 2010 and now read by nearly every social and messaging platform. X (formerly Twitter) adds its own variant, twitter:card. These tags are separate from the ones Google reads for search ranking: a page can be perfectly well indexed and yet completely silent the moment it's shared, simply because nobody filled in those few lines of metadata.
Why a missing image costs more than you'd think
A foundational study of visual memory, "Perception and memory for pictures: Single-trial learning of 2500 visual stimuli" (Standing, Conezio & Haber, Psychonomic Science, 1970), found that participants exposed just once to thousands of images recognized more than 90% of them days later — a visual recognition capacity with no equivalent for text read at the same pace. That study isn't about social media, but it illustrates a principle that applies directly here: in a feed mixing photos, videos, and text, a link with no image simply isn't competing on the same perceptual ground as its illustrated neighbors. It doesn't stand out less — it doesn't stand out at all.
How to check your own landing page's preview
Before fixing anything, you need to see what each platform actually displays, since each one caches its own copy of the metadata:
- Facebook Sharing Debugger (developers.facebook.com/tools/debug) — shows the preview and offers a "Scrape Again" button to force a refresh after a change.
- LinkedIn Post Inspector (linkedin.com/post-inspector) — essential since LinkedIn keeps its own cache, independent from Facebook's.
- Twitter Card Validator, found via a "card validator" search on developer.x.com — specifically checks the
twitter:cardtag, which needs to be present even whenog:imagealready is. - A manual test in WhatsApp or Slack, pasting the link into a conversation with yourself — the fastest first check, even if it doesn't say why a preview is broken.
The most common mistakes
- Missing
og:imagetag — the platform then falls back to the first image it finds in the HTML at random, or shows nothing at all. - Relative URL instead of an absolute one —
og:imagemust point tohttps://example.com/image.png, never to/image.png: most sharing crawlers silently ignore a relative URL. - Image too heavy — past a few megabytes, some sharing crawlers give up the download within their time budget and show an empty preview.
- Wrong aspect ratio — the recommended format is 1200 × 630 pixels (1.91:1 ratio); a square or vertical image gets cropped unpredictably depending on the platform, sometimes cutting off text or a face placed inside it.
- Stale cache — after a redesign, Facebook and LinkedIn keep showing the old image for days unless a fresh scrape is forced via the tools above.
- Missing
twitter:card— without it, X falls back to a minimal text preview even whenog:imageis correctly set.
What to put in the image, beyond just having one
An image that's present but meaningless — a plain gradient background, a generic screenshot — captures some of the perceptual attention described above, but doesn't convert that attention into a click. Three simple elements make the difference: the name of the offer or brand, a concrete promise in a few words (the same principle as a landing page headline that hooks, but readable at thumbnail size, so with about half the words), and strong contrast between text and background — the image will be seen at roughly stamp size on mobile. A raw screenshot of the page itself rarely works: the text is too small to read at that scale.
Next.js handles part of the work, but not all of it
Since the App Router, Next.js (the framework behind all ten LanderKit templates) can automatically generate the og:image and twitter:card tags from a simple opengraph-image.png or opengraph-image.tsx file dropped into a route folder — no need to hand-write the <meta> tags. On this blog, every article automatically generates its own 1200 × 630 image (title, reading time, brand style) via a script run at build time. What the framework can't guess, though, is what to put inside that image for your offer — that part stays editorial, not technical.
A concrete example
On a coaching landing page like the Coach & Consultant template (demo), a generic Open Graph image would just show the logo. An effective one instead shows the coach's name, the concrete promise already on the page ("8 sessions to structure your offer"), and a face — a choice grounded in a separate principle, covered in our article on a landing page's hero image. The same work applies to any of the ten LanderKit templates (€89 each, €229 for the full bundle): each deserves its own share image, built for its specific offer, rather than one generic visual reused from page to page.
Pitfalls to avoid
- Reusing the same Open Graph image across every page on the site — each page (home, offer, article) deserves a preview that matches what's actually there.
- Forgetting to test after a redesign — a design change without purging the Facebook or LinkedIn cache can show an outdated version for days without anyone noticing.
- Overloading the image with text — beyond a short headline, text becomes unreadable at mobile preview size.
- Ignoring
twitter:cardassumingog:imageis enough everywhere — that's only true on platforms that read the Open Graph standard, not on X.
FAQ
Frequently asked questions
What size should an og:image be?
1200 × 630 pixels (1.91:1 ratio) is the most widely compatible standard across Facebook, LinkedIn, WhatsApp, and X. Keeping it under 300 KB avoids download failures with some sharing crawlers.
Why doesn't the preview update after I change the image?
Facebook, LinkedIn, and other platforms cache a link's metadata for several days. You need to force a fresh scrape via the Facebook Sharing Debugger or LinkedIn Post Inspector for the new preview to replace the old one.
Should every page have a different Open Graph image?
Yes. A generic image reused across every page never reflects what the shared link actually contains, which reduces its relevance and its ability to make someone want to click.
Does Next.js generate the Open Graph image automatically?
The Next.js App Router can inject the og:image and twitter:card tags from an opengraph-image file placed in a route, which avoids writing the meta tags by hand. What goes inside that image — text, visual, promise — is still an editorial choice you have to make yourself.
Read next
Related articles
- Landing pages for Meta Ads (Facebook & Instagram): what changes versus GoogleThe same landing page can convert decently on Google Ads and collapse on Meta Ads. It's not a traffic quality issue but an intent issue: one visitor was searching for a solution, the other was looking at something else when your ad interrupted them.
- Content-Security-Policy on a landing page: allowing GTM, Meta Pixel and Stripe without blocking everythingA landing page loads five to ten third-party scripts on average — GTM, Meta Pixel, a Google Ads conversion tag, a reviews widget, Stripe — and the browser runs every one of them with exactly the same trust it gives the site's own code. A Content-Security-Policy header changes that rule: it explicitly lists what is allowed to execute and blocks everything else by default. How to write one without breaking anything, and why the most common configuration protects against nothing at all.
- Images on your landing page: what the law actually says (stock photo libraries, AI-generated images, personality rights)Someone on the team types "smiling coach" into Google Images, saves the first result, and it ends up at the top of the landing page. Nobody thinks twice about it at the time — yet that is exactly the scenario behind most unauthorized-image claims. Here's what the law says about the three sources of images on a landing page, and how to cover yourself without spending hours on it.