Fast, stateless Network Diagnostics

Learn

Open Graph Tags Explained: Why Shared Links Look Broken

Paste a link into Slack, iMessage, or a tweet, and a card appears — an image, a title, a short description — before anyone actually clicks through. That card is not generated by the platform reading the visible page the way a browser does. It's built entirely from a small set of meta tags in the page's own <head>, and when those tags are missing or wrong, the card is blank, wrong, or just doesn't appear at all.

The Tags That Actually Matter

  • og:title — the headline shown on the card. Often the same as the page's <title>, but not required to be.
  • og:description — a short summary shown beneath the title, usually truncated to one or two lines by whatever platform renders it.
  • og:image — the preview image. This is the single tag most responsible for whether a shared link looks intentional or broken.
  • og:url — the canonical URL the card should link to, useful when a page is reachable at more than one address.
  • og:type and og:site_name — secondary context (content type, publisher name) that most platforms use quietly rather than displaying directly.

Twitter/X reads its own overlapping set of twitter: tags first (twitter:card, twitter:title, twitter:description, twitter:image), falling back to the equivalent Open Graph tag for anything it doesn't find. A page that only sets Open Graph tags still gets a reasonable Twitter card in most cases; a page that sets neither gets nothing but a bare link.

Why a Shared Link Sometimes Looks Broken

A missing og:image is the single most common cause of a blank or generic-looking card — some platforms fall back to scraping the first image on the page, which is often unrelated to what the link is actually about (a logo, an icon, an ad). A relative image URL (/images/preview.png instead of a full https://example.com/images/preview.png) causes a similar failure even when the tag is present, because most link-preview crawlers fetch the URL exactly as written and don't resolve it against the page's own address the way a browser would.

Another common cause is a page that blocks the crawler itself — some platforms' preview bots identify with their own user agent, and a site that only serves real content to recognized browsers will show that crawler an empty or error page instead of the actual content, producing a card with no image or title at all.

A Few Things Worth Checking Directly

  • The image referenced by og:image actually loads, and is a full absolute URL, not a relative path.
  • The image is a reasonable size — most platforms expect something in the neighborhood of 1200×630, and will crop or scale unusually-shaped images in ways that look worse than intended.
  • og:title and og:description are both present and reasonably short — most platforms truncate long text rather than wrapping it.
  • The tags are in the actual HTML response, not injected by client-side JavaScript after the page loads — most link-preview crawlers read the raw HTML and don't execute scripts.

Since caching means a platform may keep showing an old preview even after the tags are fixed, most major platforms offer their own cache-refresh tool (Facebook's Sharing Debugger, LinkedIn's Post Inspector, and similar) for forcing a re-scrape once a fix has actually shipped.

Frequently Asked Questions

I fixed the tags but the old preview still shows up — why?

The platform is almost certainly showing a cached preview from before the fix. Most major platforms offer their own cache-refresh tool — Facebook's Sharing Debugger, LinkedIn's Post Inspector, and similar — to force a re-scrape rather than waiting for the cache to expire on its own.

My og:image tag is set but the image still doesn't show — what's wrong?

The most common cause is a relative URL (/images/preview.png) instead of a full absolute one (https://example.com/images/preview.png). Most link-preview crawlers fetch the URL exactly as written and don't resolve it against the page's own address the way a browser does, so a relative path just fails silently.

Do I need separate twitter: tags, or is Open Graph enough?

Open Graph alone usually produces a reasonable card on Twitter/X too — it reads its own twitter: tags first, then falls back to the equivalent Open Graph tag for anything it doesn't find. Dedicated twitter: tags are only worth adding for finer control, not as a requirement.

Why does the card show the wrong image, one that isn't even in og:image?

Some platforms fall back to scraping the first image on the page when og:image is missing entirely — often a logo, icon, or ad that has nothing to do with the actual content. Setting og:image explicitly is what stops that fallback from kicking in.

The tags look correct in the page source — so why is the card still blank?

Check whether the tags are actually in the raw HTML response or only appear after client-side JavaScript runs. Most link-preview crawlers read the raw HTML only and don't execute scripts, so tags injected after the page loads are invisible to them even though a browser shows them fine.

Use the Open Graph Checker to see exactly what tags a page publishes, and preview the resulting card before sharing it.