Why is my link preview not showing up?

It is almost always one of four things - no og:image tag in the page head, a relative image URL instead of an absolute one, an image the scraper cannot reach because it sits behind a login or a redirect, or a platform serving an old cached version. Set an absolute 1200×630 og:image, confirm the file loads in a private window, then run the URL through the platform's sharing debugger to force a fresh scrape.

How do I refresh a link preview after I change the image?

Run the page URL through the platform's own debugger. Facebook's Sharing Debugger and LinkedIn's Post Inspector both re-fetch the page and refresh their cached copy on the spot. Scrapers hold onto the first image they see, sometimes for days, so a change will not show until you force the re-scrape or the cache expires on its own.

Why does my link preview show text but no image?

The og:title and og:description are being read, but the og:image is missing or unreachable. The usual cause is a relative image path like /cover.webp, which resolves to nothing on the scraper's server. Switch it to a full absolute URL starting with https, make sure the file is public, then re-scrape.

Why Your Link Preview Is Not Showing Up

When a link preview comes up blank, it is almost always one of four things: no og:image tag, a relative image URL instead of an absolute one, an image the scraper cannot reach, or a platform serving an old cached copy. The fix for all four is the same two steps - set an absolute 1200×630 og:image, then force a re-scrape with the platform’s debugger. That is the whole answer; the rest is how to tell which of the four you have and clear it for good.

The reason this trips so many people is that you are debugging someone else’s robot. When you paste a link into Slack or LinkedIn, that platform sends a scraper to your page, reads the og: tags, fetches the image, and builds the card. You never see that round trip. So a card that comes up blank could be a problem on your page, a problem the scraper hit fetching the file, or a stale result it cached weeks ago. Walk the four causes in order and you find it fast.

A link-preview card with a blank, broken image slot - the post shared with no cover showing. — Same link, two outcomes: a blank card when the scraper cannot find or fetch your og:image, and a full unfurl when it can. Open the fix in Lede

The same card with the cover image unfurled - the post shared with its featured image showing. — Same link, two outcomes: a blank card when the scraper cannot find or fetch your og:image, and a full unfurl when it can. Open the fix in Lede

The four reasons a card comes up blank

Most broken previews are one of these, and they fail in different ways. The symptom tells you which.

Cause	What you see	The fix
No `og:image` tag	Bare link, no image, often no title	Add an `og:image` tag to the page head
Relative image URL	Title and text show, image blank	Make the URL absolute (`https://...`)
Image not publicly reachable	Title shows, image blank or broken	Open the file in a private window; unblock it
Stale platform cache	Old image keeps showing after a change	Force a re-scrape in the debugger

The tag itself - every og: property and how each platform unfurls it - is covered in Open Graph image size. This piece is the troubleshooting walk: how to spot which row you are in, and how to clear it.

First, confirm the tag exists

Before anything else, open your page and view source. Search the HTML for og:image. You are looking for one line in the <head> that looks like this:

<meta property="og:image" content="https://yoursite.com/blog/post/cover.webp"/>

If that line is missing, the scraper has nothing to fetch and the card renders bare. Add it. If you publish through a CMS, the platform usually writes this tag for you once you set a featured image, so the real fix is upstream - on WordPress specifically, getting the featured image to register is its own troubleshooting path, and adding a featured image the right way shows where the tag comes from.

If the tag is there but the card is still blank, you are in one of the next three rows. Read the content value carefully, because the most common bug lives right there.

The relative URL trap

This one breaks more previews than any other single thing, so it earns its own section.

The content value of your og:image has to be an absolute URL - the full https://yoursite.com/cover.webp, including the domain and the https. A path that starts with /cover.webp will not do it. A relative path works fine in your browser because the browser knows what site it is on. The scraper does not. It runs off its own servers, so a path starting with / resolves against nothing and the image comes up empty. The title and description still show, because those are plain text in the tag, but the picture is gone.

If your card shows the words but not the image, check this first. Nine times in ten, that is the bug.

Make sure the scraper can actually fetch the file

An absolute URL only helps if the file at the end of it is public. Scrapers are anonymous robots with no login and no cookies, so anything that stops a stranger from loading the image stops the card too.

Open your og:image URL in a private or incognito window - no session, no extensions. If the image loads instantly, the scraper can reach it. If it asks for a login, throws a 403, or bounces through a redirect chain, the scraper hits the same wall and the card stays blank. The usual culprits:

The image sits behind authentication. A staging site under HTTP basic auth, or a file in a members-only folder. The scraper gets the login page back and never reaches the picture.
A redirect the scraper does not follow. Some scrapers refuse to chase a redirect on the image URL. Point og:image at the final file, not a shortener or a redirecting CDN path.
A robots.txt or firewall rule blocking bots. If you block crawlers broadly, you can block the social scrapers along with them. They identify by user agent; let them through.

Clear the file’s path to a logged-out stranger and this row resolves.

The stale cache, and the re-scrape that fixes it

You fix the tag, the URL is absolute, the file is public - and the old image still shows. This is the last row, and it is the most common reason a correct setup looks broken.

Every social scraper fetches your og:image once and holds onto the result, sometimes for days. So a freshly changed image keeps serving the old one until the scraper re-fetches. Nothing on your page is wrong. The platform is just showing you a copy from before your change.

The fix is to force a fresh scrape. Each platform ships a tool for exactly this:

Facebook’s Sharing Debugger takes your URL, re-scrapes the page on demand, and shows you every og: tag it read plus the image it pulled. Hit it again after a change and it refreshes the cache.
LinkedIn’s Post Inspector does the same for LinkedIn cards - paste the URL, and it re-fetches and previews the result.

Run your page through the debugger, read what it actually saw, and you get two things at once: the cache clears, and the tool tells you if a tag is missing or an image failed to load. That is why the debugger is the real diagnostic step and does double duty as a cache buster. It shows you the page through the scraper’s eyes.

A blank card is rarely a mystery. It is the scraper telling you it could not find, reach, or refresh your image - and the debugger shows you which.

The two-step fix, in order

When a preview breaks, do this and stop guessing:

Set an absolute og:image. A 1200×630 file at 1.91:1, declared with a single og:image tag, pointed at by a full https:// URL. One image covers Facebook, LinkedIn, X, Slack, and Discord. The one-card spec and which size goes where cover the dimensions.
Force a re-scrape. Run the URL through the platform’s debugger. It re-fetches, refreshes the cache, and reports back what it read.

Two more checks save you the next time it breaks: keep exactly one og:image tag, because multiple tags let the platform pick and it rarely picks the one you meant, and declare og:image:width and og:image:height so the card reserves the right box instead of collapsing while the file loads.

If the terms themselves are getting tangled - whether the thing you are debugging is your featured image, your cover, or a separate OG file - the difference between the three sorts that out before you chase the wrong tag.

A quick checklist

Run this top to bottom when a card comes up wrong:

View source and confirm a single og:image tag is present in the <head>.
Check the URL is absolute - https://yoursite.com/cover.webp, never /cover.webp.
Open that URL in a private window and confirm the file loads with no login.
Make sure the image is at least 600×315 so it renders as a full card instead of a small thumbnail.
Run the page through the platform’s debugger to force a fresh scrape after any change.
Keep one og:image tag and declare og:image:width and og:image:height.

Get the file right and the rest is one button. When you want to make the 1200×630 image itself, open Lede - it has an OG preset and a one-click 2× WebP export - or start from a gallery template and swap in your own title. Build it once, point an absolute URL at it, and your card unfurls everywhere.