Your link previews are broken and your own site will never tell you

Someone shares your homepage in a Slack channel, a LinkedIn post, or a group text. What shows up is a gray box, a bare URL, and maybe a cropped slice of your logo. Everyone else's links in that same thread render a sharp image, a clean title, and a one-line description. Yours looks abandoned.

Nothing in your analytics will flag this. Your pages pass every test you run from your own browser. The failure only happens on someone else's server, at the moment of sharing, in front of the exact audience you were hoping to reach. This post explains how link previews get built, the handful of ways they silently break, and how to check yours without guessing.

How a link preview gets made

When you paste a URL into a social platform, a chat app, or a messaging tool, that platform sends its own crawler to fetch the page. It does not render your JavaScript, wait for your analytics to load, or scroll. It reads the raw HTML response, looks in the <head> for a specific set of meta tags, and builds a card from whatever it finds.

Those tags follow the Open Graph protocol, originally created by Facebook and now read by nearly every platform that renders previews. The four that matter most:

• og:title sets the headline on the card.
• og:description sets the line of text under it.
• og:image sets the picture, which is usually the whole reason anyone clicks.
• og:url declares the canonical address, so shares of tracking-parameter variants roll up to one page.

X (formerly Twitter) reads Open Graph tags as a fallback, but it also looks for its own set, starting with twitter:card. That tag controls the layout. A value of summary_large_image gives you the big landscape card. Leave it out and you may get the small thumbnail version, or on some clients, nothing at all. MDN's reference on social metadata covers the full list of names each family recognizes.

The crawler takes the first valid tags it finds and stops. There is no second chance and no error shown to you. If the tags are missing or wrong, the platform guesses from your <title> and whatever image it can scrape, and the guess is usually ugly.

Why your own site never warns you

Every tool you normally use to check your site runs in your browser, with JavaScript enabled. A preview crawler has none of those advantages. That gap is where the problems hide.

You see the rendered page. The crawler sees the raw response. If your site injects meta tags client-side, the tags exist in the DOM you inspect but are absent from the HTML the crawler receives. The page looks perfect to you and empty to Facebook.

You never share your own links the way strangers do. Most teams test the homepage once and move on. Blog posts, product pages, and landing pages built on a different template each have their own <head>. One of them is almost certainly missing an image.

Platforms cache aggressively. Once a crawler has fetched a page, it stores the result, often for days. You can fix the tags, reshare the link, and still see the broken card because the platform is serving its stale copy.

Errors are silent by design. No platform emails you when your og:image returns a 404. The card quietly degrades, and the people sharing your link are not the ones who will tell you.

The five ways previews break

These account for the large majority of broken cards in the wild.

1. The tags are missing entirely

Many CMS themes ship without Open Graph support, or ship with it turned off until a plugin is configured. The page has a <title> and a meta description for search engines, but no og: tags at all. The preview falls back to the page title and, with luck, the first large image the crawler can find, which is frequently a navigation icon or a tracking pixel.

2. The image is unreachable or the wrong size

og:image must be an absolute URL, including the https:// scheme and hostname. A relative path like /images/hero.jpg is invalid under the protocol, and most crawlers discard it. The image also has to be publicly fetchable without cookies, must not sit behind a hotlink-protection rule, and must be large enough. A safe target is 1200 by 630 pixels. Under about 600 pixels wide, several platforms drop to a tiny thumbnail layout or skip the image.

3. The tags are only added by JavaScript

If your framework renders meta tags after the page loads in the browser, the crawler never sees them. This is the most common failure on React, Vue, and Angular sites without server-side rendering. The fix is to emit the tags in the server response through server-side rendering, static generation, or a prerender step for crawler user agents.

4. A redirect or blocking rule gets in the way

Preview crawlers follow redirects, but not infinitely, and they are stricter than browsers. A chain that hops from http to https to www to a trailing-slash version wastes the crawler's patience. Worse, firewall rules, bot protection, and robots.txt entries sometimes block crawler user agents outright. Facebook's crawler identifies as facebookexternalhit, X's as Twitterbot, and LinkedIn's as LinkedInBot. Block any of them and the card comes back blank, every time.

5. The tags conflict with each other

Duplicate og:title tags from a theme and a plugin fighting over the same slot. An og:url that points at a staging domain. A twitter:card set to summary while the og:image is a wide hero shot that gets cropped into a square. None of these produce errors. They produce cards that look slightly wrong, and nobody flags those.

How to check yours properly

You need to see what the crawler sees.

Fetch the raw HTML. Use curl, not the rendered DOM. Confirm the og: and twitter: tags are present in the response body before any script runs:

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

If that returns nothing, you have a server-side rendering problem, and no amount of tag editing will fix it until the tags are in the response.

Request the image directly. Paste the exact og:image URL into a private browser window with no cookies. It should return a 200, be at least 1200 pixels wide, and carry an image Content-Type. An image served as text/html because of a misconfigured CDN rule fails silently.

Walk the redirect chain. Count how many hops your canonical URL takes to resolve, and confirm the final host matches what your og:url declares. More than one or two redirects is a warning sign.

Check for crawler blocking. Read your robots.txt and any WAF or bot-protection rules. Make sure none of them catch facebookexternalhit, Twitterbot, or LinkedInBot. Then fetch the page with one of those user agent strings and confirm you get the same HTML a normal request gets.

Use the platform debuggers to clear the cache. Facebook's Sharing Debugger, X's Card Validator, and LinkedIn's Post Inspector each let you force a re-fetch. This is the only reliable way to flush a stale card after a fix.

Spot-check more than the homepage. Pick one URL from every template on your site. Each one has its own <head> and its own opportunity to be wrong.

Making it stick

Fixing the tags once is not enough. Templates change, plugins update, and the next redesign ships without anyone remembering to check. Treat Open Graph tags as part of your deployment checklist. Any time a new template goes live, fetch it with curl and load the image URL directly.

If you want this checked automatically, the full AcuityScan site scan includes Open Graph and Twitter Card coverage inside its SEO module. It fetches your page the way a crawler does, flags any of og:title, og:description, or og:image that are missing, and checks for a twitter:card declaration, with the exact tags to add when something is absent. It pairs well with the free redirect checker, which maps the hop chain a preview crawler has to follow, and the HTTP headers tool, which shows the Content-Type your image URL actually returns.

Run a complete scan at acuityscan.com to see link preview findings alongside 350+ checks across 8 modules covering SEO, performance, security, accessibility, and email authentication. Every finding comes with a plain-English fix. The individual free tools are open to anyone, no account required.

TL;DR

• Link previews are built by a crawler reading the raw HTML <head> for Open Graph and Twitter Card tags. It never runs your JavaScript.
• The core tags are og:title, og:description, og:image, and og:url. Add twitter:card set to summary_large_image for the large layout on X.
• Most failures are silent: missing tags, a relative or undersized og:image, client-side-only rendering, blocked crawler user agents, or a long redirect chain.
• Test with curl, not your browser. Load the image URL directly. Platforms cache cards for days, so use each platform's debugger to force a re-fetch after any fix.