Why Link Previews Look Wrong, and How to Fix Them

A link preview is built from tags you control

You paste a link to your new page into WhatsApp, and the preview shows the site name and nothing else. Or it shows the homepage title on a product page. Or it shows the photograph you replaced a month ago. The page itself looks fine in a browser, which makes this confusing.

Here is what happens. When a link is shared, the platform's crawler requests the page, reads a handful of tags from the HTML, and builds the card from them: title, description, image. Those tags are the Open Graph protocol, originally from Facebook and now read by almost everything that shows a link preview, including WhatsApp, LinkedIn and Slack.

So a wrong preview has one of three causes. The tags are missing or wrong. The crawler cannot see them. Or the platform is showing a copy it saved earlier. Check which before changing anything: paste the URL into the Open Graph checker, which fetches the live page the way a crawler does and lists every social tag it finds, with the missing ones marked.

The four tags that matter

The Open Graph specification lists four required properties. In practice you want those four plus a description:

<meta property="og:title" content="Wedding Cards with Gold Foil">
<meta property="og:description" content="Proofs in two days, collection on the date you choose.">
<meta property="og:image" content="https://www.example.com/images/gold-foil-card.jpg">
<meta property="og:url" content="https://www.example.com/wedding-cards/gold-foil/">
<meta property="og:type" content="website">

og:title is the headline on the card. It does not have to match your page title exactly. The page title is written for a search result, where the brand name at the end helps; on a card that already shows your domain, the brand can often go.

og:description is the line underneath. One sentence that makes somebody want to tap, not a list of keywords.

og:image is the picture, and the tag that goes wrong most often. More on it below.

og:url is the canonical address of the page. Facebook's guidance is that it should be the plain URL, without session IDs or tracking parameters, so that shares of the same page count as one page.

og:type is usually website, or article for a blog post.

The specification also recommends og:image:alt, a short description of what the image shows, for people who cannot see it. If you are writing these by hand, the meta tag generator produces a complete head block, including the Open Graph and X card tags, from a few fields.

The image: 1200 by 630, and an absolute URL

Most broken previews are broken images. Three rules prevent nearly all of it.

Size and shape. Facebook recommends images of at least 1200 by 630 pixels, as close to a 1.91 to 1 ratio as possible, and rejects anything under 200 by 200. LinkedIn's help pages give 1200 by 627 as the minimum with the same 1.91 to 1 ratio. Design at 1200 by 630 and you satisfy both. Keep the important part of the image away from the edges, because platforms crop slightly differently.

File weight. Facebook allows up to 8 MB and LinkedIn up to 5 MB, but those are ceilings, not targets: a smaller file is fetched faster by the crawler, and the person tapping the link pays for the download too. Design at the right shape first, scale it to 1200 pixels wide with the image resizer with the ratio locked, then shrink the file with the image compressor. That order is not arbitrary, and preparing images for the web explains what each step costs.

An absolute URL. Write the full address, starting with https://. The specification defines og:image as an image URL and every example it gives is absolute. A relative path like /images/card.jpg works in a browser, because the browser knows which site it is on. A crawler reading tags out of context may not.

Facebook also suggests adding og:image:width and og:image:height. Its documentation says these let the crawler render the image straight away, rather than downloading and processing it first, which matters for the very first share of a new page.

What this blog does

Every post on this blog gets its own title card, a 1200 by 630 image rendered from the post's title by a small script in the site build, and set as that page's og:image with an absolute URL. When a card has not been rendered yet, the page falls back to the site's own sharing image rather than to nothing, so a new post never shares with a blank space. It is a typographic card, not a photograph, because a studio blog with stock photography on every post is claiming something it did not do.

Tags the crawler cannot see

A page can have perfect tags and still produce a bad preview, if the tags only exist after JavaScript runs.

Many sites built as single-page applications put a generic title and no Open Graph tags in the HTML the server sends, then fill in the real ones in the browser. A visitor never notices. Most link preview crawlers do not run JavaScript, so they read the generic version, and every page on the site shares with the same title and image.

This is exactly what the Open Graph checker shows you, because it reads the raw HTML rather than the rendered page. If the tags you see in your browser's inspector are missing from the checker's report, they are being added client side. The fix is to put them in the server response: prerendering, server rendering, or a static page per URL.

Why the old preview will not go away

You fixed the tags, the checker shows them correctly, and the platform still shows the old preview. This is caching, and it is the cause of most "I fixed it and nothing changed" moments.

Platforms save what they scraped the first time a URL was shared, and reuse it. Facebook's documentation is specific about images: they are cached by URL and are not updated unless the URL changes. So replacing card.jpg with a new picture under the same name can leave the old picture in place for a long time.

Each platform has its own way of clearing it:

• Facebook: paste the URL into the Sharing Debugger. It shows exactly which tags Facebook read, flags errors, and lets you ask it to scrape the page again.
• LinkedIn: use the Post Inspector. It shows the preview LinkedIn will use for a URL, and running the URL through it after a change is how you get LinkedIn to read the page again.
• WhatsApp: there is no public debugger. The dependable fix is the one Facebook's image rule points to: give the image a new URL, for example card-v2.jpg, and update the tag.

The image URL trick works everywhere, and it is worth building into how you work. If you change a page's image, change its filename too. We have a version of this problem ourselves: our title cards are named after the post, so if a post is ever retitled, the card at that address changes, and a platform that has already cached it will keep showing the old title until the URL changes.

X wants one more tag

X reads its own card tags, and the one that decides the layout is twitter:card. For the large image layout, the one most people want, set:

<meta name="twitter:card" content="summary_large_image">

Add twitter:title, twitter:description and twitter:image as well if you want to be certain what X shows, rather than relying on it to use your Open Graph values. The meta tag generator produces both sets together.

A five-minute check for any page

1. Run the page through the Open Graph checker. Fix anything marked missing.
2. Confirm the image is 1200 by 630 and the og:image URL is absolute and loads on its own.
3. Check the title and description read well on a card, and in a search result with the SERP preview, since the same page usually needs both.
4. Run the URL through the Facebook Sharing Debugger and the LinkedIn Post Inspector, which prompts both to read the page again and shows you what they see.
5. Send the link to yourself on WhatsApp. If it is still stale, rename the image.

Previews matter most for businesses whose customers share links in chat rather than find them in search. Our guides to local business websites and restaurant websites and QR menus cover the rest of that page. If you are moving pages to new addresses at the same time, read how to move a website without losing search traffic first, since every moved URL starts its preview cache from scratch.

If your site builds pages in the browser and the previews are generic everywhere, that is a fix to how pages are rendered, which is website fixes and maintenance for an existing site and SEO when it is part of a wider search problem.