How to test a link preview before sharing

Two checks, in order: curl the page to confirm the tags exist in the HTML a server actually sends, then run the platform’s debug tool to confirm its crawler agrees and to populate its cache with a correct card. The first catches markup and rendering problems; the second catches fetch problems and prevents a wrong card from ever being cached.

Doing this before you publish costs half a minute. Doing it afterwards means working around caches.

Step 1: curl the page

The reason to start here is that your browser is not a preview crawler. It runs JavaScript, it has your cookies, and it may see a completely different page.

curl -s https://example.com/page/ | grep -i 'og:\|twitter:'

What you want to see: one og:title, one og:description, one og:image with an absolute HTTPS URL, one og:url, and a twitter:card.

What the output tells you:

Nothing at all — the tags aren’t server-rendered. Either they’re injected by JavaScript, or the template didn’t run. This is the single most common real failure and it’s invisible in a browser.

Duplicate tags — two sources are both adding Open Graph, and which wins is up to the parser. Remove one.

name="og:title" instead of property="og:title" — wrong attribute for the Open Graph family. Strict parsers ignore it, so it works in some apps and not others.

Unrendered template syntax in a content attribute — a variable that didn’t resolve. Obvious once you look and easy to ship without looking.

A relative image path — fix it to absolute before going further.

Step 2: check the image itself

The tags can be perfect and the image still absent from the card, because the crawler couldn’t fetch it.

curl -sI https://example.com/og/preview.png

You want a 200, an image content-type, and a content-length in the hundreds of kilobytes rather than several megabytes. Watch for:

A redirect chain to reach the image.
A 403, which usually means hotlink protection is blocking unknown user agents — including preview crawlers.
A very large file, which can exceed a crawler’s timeout on a slow origin.
A content-type of image/webp or image/svg+xml, which some crawlers won’t use.

Step 3: the platform’s debug tool

Now check what a real crawler makes of it. Each major platform has a tool that fetches your URL fresh and reports what it found — the scraped values, warnings about missing tags, and often the exact response it received.

This is worth doing even when curl looked fine, because it tests things curl can’t: whether the crawler is served the same page you are, whether it followed your redirects as expected, and whether the image downloaded within its timeout.

It also has a side effect that matters: a successful fetch populates that platform’s cache. Run it before you share, and the first person to paste your link gets the card you intended. Skip it, and any mistake gets cached before you notice.

Facebook’s debugger is the most informative of these and is worth using as a general diagnostic even when your problem is elsewhere, because it reports exactly what its crawler saw.

What to look at on the rendered card

When you have a preview in front of you, check the things that are easy to get wrong:

Is the title truncated mid-word? Different platforms cut at different lengths. Front-load the meaningful words.

Is the description cut off? Same issue, shorter budget. Say the important thing first.

Is the image cropped badly? Means the aspect ratio isn’t right for that card. 1200 × 630 fixes it.

Is text in the image legible at this size? The card in front of you is roughly the size real people see. If you’re squinting, so are they.

Is it the right page? If og:url is wrong or a redirect went somewhere unexpected, the card can correctly describe a page you didn’t mean to share.

Test on a staging URL first

The cleanest workflow, especially for a template change affecting many pages: verify on a URL you don’t mind burning.

Same template, same structure, different address. Run all three steps against it. Template-level mistakes — a missing attribute, an unresolved variable, a relative path — show up identically there, and the real URL’s cache stays clean for its first share.

A pre-publish habit

For anything you expect to be shared:

curl | grep for the tags.
curl -I the image.
Run one platform’s debug tool.
Look at the card and read the title as it renders, not as you wrote it.

Four checks, well under a minute, and they eliminate essentially every link-preview problem that would otherwise need cache invalidation to fix — plus the ones that can’t be fixed after the fact at all.