SEO Tools·4 min read

Debugging Open Graph Previews That Show the Wrong Card

The page is perfect, the markup was updated on Tuesday, and the shared link still shows last month's headline with a stretched logo where the hero image should be. Debugging open graph previews is frustrating because two separate systems can be at fault: the HTML your server sends, and the cached copy each platform's scraper keeps. This article shows how to tell those failures apart with an og checker, force the caches to let go, and read the fallback rules that decide what appears when tags are missing.

Open the tool All insights

One broken card, two possible culprits

Markup problem or cache problem? Everything follows from this.

When a link preview is wrong, either the page is serving wrong og tags right now, or the page is fine and the platform is showing a scrape from before your fix. The repairs have nothing in common: the first means editing your head, the second means forcing a re-scrape. Guessing wrong wastes an afternoon.

The Open Graph Inspector settles it in one fetch. Paste the URL, click Inspect OG card, and compare the Raw tags tab against what the platform displays. Fresh tags plus a stale card points at cache. Wrong tags in the raw view points at your markup, and no amount of cache clearing will help until the HTML changes.

Debugging open graph previews in three passes

A repeatable order of operations.

Pass one: read the Raw tags tab. Confirm og:title, og:description, and og:image exist and hold the values you intended, checking for typos, truncated URLs, and http where https should be. Pass two: flip through the Facebook, Twitter / X, and LinkedIn tabs and watch for the warning that no og:image was found, which explains every text-only card instantly.

Pass three: open the og:image URL directly in a private browser window. Scrapers fetch it anonymously, so if it 404s, redirects to a login, or gets blocked by a bot rule on your CDN, the picture is invisible to platforms even though your logged-in browser shows it fine. Only after all three passes agree should you touch platform caches.

A worked og diagnosis, from symptom to fix

Right tags, wrong card, classic cache.

Symptom: a restaurant shares https://fernandco.example/spring-menu and Facebook renders the card as Fern & Co | Home with the old winter photo. Inspection input: that same URL in the og tag tester. Output in Raw tags: og:title reads Spring Menu 2026, Fern & Co and og:image points to /social/spring-menu.png, correct and live.

Diagnosis: the markup is fine, so Facebook is serving a scrape made before the page was updated. Fix: request a re-scrape in Facebook's Sharing Debugger, and the next share shows the spring card. Total time, about three minutes, because the first fetch separated the two failure modes instead of leaving you editing markup that was never broken.

Cache busting social scrapers that hold stale cards

Each platform forgets on its own schedule.

Platforms cache the first scrape of a URL aggressively, sometimes for weeks. Cache busting social scrapers is platform-specific work: Facebook's Sharing Debugger has a Scrape Again button, LinkedIn's Post Inspector refreshes on demand, and X mostly re-fetches when its cache expires on its own.

The blunt fallback works everywhere: share the URL with a throwaway query string like ?v=2. Platforms treat it as a brand-new address and scrape fresh. It splits share counts across variants, so treat it as a diagnostic and a last resort, not a publishing habit. And when a card must be right the first time, inspect before the first share, because the cheapest cache to bust is the one that never got filled with a bad card.

Missing og tags fallbacks, and what platforms invent

A page with no og markup still gets a card. Just not yours.

The missing og tags fallbacks follow a chain the Open Graph Inspector mirrors: title comes from og:title, then twitter:title, then the plain title tag; description walks the same path through its variants; the image tries og:image, then twitter:image, then nothing. That final nothing is why an untagged page shares as a bare text block.

Missing og:title: platforms show your SEO title, brand suffix and all, clamped to two feed lines
Missing og:description: some cards render with a bare headline, others lift stray page text
Missing og:image: no picture, or on some platforms a random image scraped from the body, which is how a footer badge becomes your launch visual
Missing og:url: engagement splits across every tracking-parameter variant of the same page

Og debugging moves that waste an afternoon

Skip these and the fix gets faster.

The most common one: editing markup to fix what was a cache problem, then concluding the edit failed because the platform still shows the old scrape. Next, testing while logged in, which hides that the og:image sits behind an auth wall for anonymous scrapers. Third, checking only Facebook and assuming X and LinkedIn agree, though each caches and falls back differently. Last, trusting the browser's view-source of a client-rendered app; if JavaScript injects your og tags, scrapers never see them, and a social preview checker that fetches raw HTML will show you the empty head they actually receive.

When the Open Graph Inspector hands off to other tools

Diagnose here, repair over there.

The Open Graph Inspector reads and renders; it doesn't write markup. When the raw tags are wrong or missing, build a correct block with the Open Graph Generator and redeploy. If X's layout is the specific problem, the Twitter Card Generator sets the twitter:card type that controls it. And when the audit should cover the whole head, canonical, viewport, robots, and H1 included, the Meta Tag Analyzer scores all of it in one pass, with the og checks folded in.

Try it now

Open Open Graph Inspector

The tool is one click away. No sign up, no upload, no payment.

Open Open Graph Inspector

Write a review