Facebook Sharing Debugger: What It Actually Checks and How to Read the Output

The Facebook Sharing Debugger is the closest thing to ground truth for what Facebook's crawler actually sees on your page — but its output is dense, mixes hard errors with informational notices, and doesn't always explain in plain language what a given warning means for how your link will actually look when shared. This is a guide to reading it properly, not just clicking the refresh button and hoping the preview looks right.

What the Facebook Sharing Debugger actually does

When you paste a URL into the debugger, it does two things: it shows you the last scrape Facebook has stored for that URL (if one exists), and it gives you the option to trigger a fresh scrape right then. The tool isn't simulating a share — it's showing you the actual data Facebook's own crawler extracted the last time it visited the page, which is exactly what determines the card rendered whenever that URL gets shared on Facebook or Messenger going forward. This is why it's the primary reference point for debugging preview issues, rather than trusting how a link happens to render when you personally paste it — your own paste might be hitting a cached result from before your latest change.

Reading the Open Graph tag table

The main output is a table of every Open Graph property the debugger found, with the property name in one column and the scraped value in the other. og:title, og:description, og:image, and og:url are the ones worth checking first, since they're what most directly shapes the visible preview. A blank or missing row for og:image means the debugger genuinely found no image tag — worth distinguishing from an image tag that was found but failed to load, which shows up differently (see below). If a value in this table looks wrong or outdated compared to your live page, that's the clearest sign you're looking at a stale cached scrape rather than current content — run 'Scrape Again' before investigating further.

The image preview and why it sometimes shows nothing

Below the tag table, the debugger typically renders a visual preview of how the card would look, including the image if one was successfully fetched. If og:image has a value in the table but the visual preview shows no image, that's a specific and useful signal: the tag exists and points somewhere, but Facebook's crawler couldn't actually retrieve or use the image at that URL. Common causes are an image behind authentication, a URL that returns a non-200 status, a file below Facebook's minimum dimensions, or a format Facebook doesn't accept. This distinction — tag present vs. image actually usable — is exactly the kind of thing that's easy to miss by only skimming the table and not checking the rendered preview underneath it.

Warnings versus errors

The debugger surfaces a 'Warnings that Should Be Fixed' section separate from the tag table, and it's important to distinguish genuine problems from cosmetic notices. A missing og:type or a missing fb:app_id, for instance, will often show as a warning but rarely prevents a preview from rendering reasonably — Facebook falls back to sensible defaults for a lot of optional properties. Warnings about a missing og:image, an og:image that couldn't be downloaded, or an og:title that's missing entirely are the ones that actually change what a viewer sees and should be prioritized. Read every warning, but don't treat the presence of any warning as proof something is broken — check whether it corresponds to a real visible symptom in the rendered preview above it.

The response code and why it matters more than people think

The debugger reports the HTTP response code it received when fetching your page. This is worth checking even when the tag table looks fine, because a page that's redirecting (a 301 or 302) to a different URL than the one you pasted can produce a scrape of the wrong page entirely — the destination of the redirect, not the URL you intended to share. If you're using URL shorteners or tracking redirects in front of your actual content, confirm the debugger followed the chain to the page you actually meant, and that the final URL's own og:image is what's being read, not a generic fallback on an intermediate redirect page.

Using the debugger as a real diagnostic tool, not just a refresh button

Most people only reach for the Sharing Debugger to force a re-scrape after fixing something, which is a valid use but leaves most of its value on the table. Used properly, it's a direct read of exactly what Facebook's crawler extracted, which makes it useful for catching problems before you've even shared the link anywhere — paste a new page's URL before publishing a campaign around it, check that the image preview renders, that the title and description read the way you intend, and that no warnings point to a missing property you'd rather have set explicitly than rely on a fallback for.

What to check on every debugger run

• The response code is 200, not a redirect to an unexpected URL
• og:title, og:description, and og:image all have the values you expect, not stale ones
• The rendered visual preview actually shows the image, not just a tag with a value
• Warnings that reference missing or unfetchable properties, distinguished from purely cosmetic ones
• The og:url value matches the canonical URL you intend people to actually share

Reading the app ID and admin fields, and when they matter

Further down the output, the debugger sometimes surfaces fields related to fb:app_id or fb:admins, which relate to Facebook's older app-linking and Insights features rather than the visible preview card itself. For most sites just trying to get a clean share preview, these fields being empty isn't something to chase down — they matter primarily if you're tracking Facebook-specific referral analytics through an app tied to your domain, which is a separate concern from whether the og:title, og:description, and og:image render correctly. It's worth knowing the difference so a warning about a missing app ID doesn't send you down a debugging path unrelated to the actual visible symptom you started with.

When the debugger itself returns an error instead of a scrape

Occasionally the debugger fails to complete a scrape at all, returning an error about being unable to fetch the URL rather than a populated tag table. This usually points to something more fundamental than a metadata problem — the page returning a non-200 status to Facebook's crawler specifically (which can happen if a bot-detection or rate-limiting system is blocking the crawler's user agent), a DNS or SSL certificate issue affecting that specific domain, or the page timing out entirely under load. Because this is a fetch-level failure rather than a parsing-level one, it won't show up as a metadata warning — it shows up as the debugger simply refusing to produce a result. Treat this as a signal to check your server's request logs for the crawler's specific requests before assuming the problem is in your Open Graph tags at all.

Where useopengraph fits alongside the Sharing Debugger

The Sharing Debugger is Facebook-specific by design — it tells you nothing about how the same URL renders on X, LinkedIn, Slack, or Discord, each of which parses metadata slightly differently and has its own caching behavior. useopengraph's Cache Debugger covers that gap: it re-fetches a URL live and shows what each of those platforms would actually parse right now, in one pass, and it can trigger Facebook's own official re-scrape directly rather than requiring you to separately open Facebook's tool. For sites generating OG images through useopengraph's templates, the rendered image URLs are already versioned and immutable, so the specific failure mode of 'og:image present but not fetchable because it's stale or the wrong version' doesn't come up — every published version has its own permanent URL that never changes underneath it.