Facebook Sharing Debugger: How to Use It

A cut-paper link preview card with a grey landscape panel, two blank text bars and a small embossed seal in one corner

The Sharing Debugger is Meta's tool for checking how a link will look when someone shares it on Facebook. Meta's guide to sharing for webmasters says it shows which meta tags the crawler scrapes, lists errors and warnings, and also triggers a fresh scrape of the page. That last part is why it doubles as the refresh button for a stale preview.

You need to be logged in to Facebook to use it; the tool page asks you to log in before it runs. The same page carries a second tab, Batch Invalidator, for refreshing more than one URL. If you are new to the tags it reads, start with the link previews and Open Graph hub.

Run your first check

Open the tool
Go to developers.facebook.com/tools/debug/. The page asks you to log in to Facebook before it runs a check.
Paste the full URL
Use the exact address readers share, with https and the trailing slash your site uses. Press Debug.
Read the warnings first
The top of the result lists problems the crawler hit. Fix anything about a missing or unreachable image before you look at the preview.
Compare the tags
Scroll to the raw tags list and check that og:title, og:description, og:image and og:url match your page source, one value each.
Fix, purge, scrape
Change the tags on your site, purge your page cache and CDN for that URL, then press Scrape Again in the debugger.
Pre-cache the image
Meta's FAQ says images are cached asynchronously and may not render on the first share. A scrape in the debugger pre-caches the image; og:image:width and og:image:height tags help too.

Purge before you scrape, or the debugger caches your old page again.

What each part of the result means

Meta does not publish a field-by-field reference for the result page, and its labels change from time to time. Its docs promise three things: the tags the crawler scraped, any errors or warnings, and a fresh scrape. The table maps those to what to do next.

Part of the result	What it tells you	What to do with it
Warnings	Problems the crawler hit: missing properties, values it had to infer, images it could not fetch	Fix image and URL warnings first; most others are advisory
Last scraped and response details	When Meta last fetched the page, the HTTP response code, the fetched URL and the canonical URL it settled on	A time from before your fix means you are looking at the cached copy
Link preview	A mock of the card built from the cached data	Use it as a guide; the feed can crop differently
Raw tags	Every og: and fb: meta tag the crawler found, in page order	Count the og:image lines; there should be one
Scrape Again	Fetches the page now and replaces the cached data	Press it after every tag change, once your own cache is clear
Batch Invalidator tab	A separate tab for refreshing several URLs	Use it after a site-wide template change

Common warnings and whether they matter

Missing og:image, or an image that cannot be fetched

This one matters. Without a usable image the card has no picture, or Meta picks one from the page. Meta's webmasters FAQ says images smaller than 600 by 315 pixels but larger than 200 by 200 render as a small square, that an image over 8 MB or one that is slow to serve can render as a white box, and that og:image and og:url must be absolute URLs. The full sizing advice is in our guide to the 1200 by 630 card image.

A property that was inferred

When a tag such as og:title or og:description is missing, the crawler fills the gap from other parts of the page, like the title element or body text, and the debugger warns that the value was inferred. The card may still look fine. Fix it anyway, because inferred text is what produces a cookie notice or a menu label as your share description.

fb:app_id missing

This warning is the one most people can ignore. Meta's webmasters guide says the fb:app_id tag is needed to use Facebook Insights for traffic from Facebook to your site. It does not affect whether the card renders. If you want that reporting, our page on getting a Facebook app ID covers creating one; otherwise leave the warning alone.

Response code 0, or a fetch error

The crawler could not get the page at all. The FAQ notes that it looks for an AAAA record and returns code 0 if none is found, which can happen after a server or domain move. A firewall rule that challenges unknown bots produces a similar failure.

How do I force Facebook to re-scrape a page?

Press Scrape Again on the result page. The crawler documentation says that when content was not available at crawl time, you can force a crawl through the Sharing Debugger or the Sharing API. Two rules from Meta's own pages make the refresh stick:

Change the image URL when you change the image. The webmasters guide says images are cached by URL and will not update unless the URL changes. Overwriting share.jpg in place keeps the old picture.
Keep the old image online. The FAQ warns that deleting the previous image makes existing shares show a white box.
Titles can freeze. Once a shared post passes 50 interactions, the FAQ says its title can no longer be changed. Other properties can.
Old posts keep old cards. New tags apply to future shares. For a post already published, the FAQ describes opening the post's menu and choosing Refresh share attachment.

Before you scrape, confirm what the crawler will receive. Meta's crawler page gives this command for simulating its request; run it against your URL and look for one og:image line.

curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" \
  -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" \
  "https://example.com/town-clock/" | grep -i "og:"

The same page says Open Graph properties must sit within the first 1 MB of the response or they are cut off, and that the server must support gzip and deflate. A theme that prints tags late in a very heavy head can fail this.

Batch Invalidator: many URLs at once

After a change that touches every post, such as a new default share image or a switched SEO plugin, refreshing pages one by one is slow. The Batch Invalidator tab is built for that. The Meta pages fetched for this guide do not document how many URLs it accepts, so try a handful first, then check two or three of them in the main debugger to confirm the new tags were picked up.

The Graph API alternative: scrape=true

If you publish from a script or a deploy hook, you can ask for a re-scrape without the browser. The Graph API URL reference documents a POST to graph.facebook.com with the URL as id, scrape=true, and an access token. The URL must be encoded so it does not clash with the other parameters. A success returns {"success": true}.

curl -i -X POST \
  "https://graph.facebook.com/{latest-graph-api-version}/?id=https%3A%2F%2Fexample.com%2Ftown-clock%2F&scrape=true&access_token={access-token}"

Keep the token out of your theme and your page source. How to get one, and where to store it, is in the Facebook access token guide.

Check the page before the debugger

The debugger needs a public URL and a login. For a draft, a staging copy or a page behind a password, paste the HTML into our paste-the-source preview checker, which reads the tags in your browser and fetches nothing. Once the tags are right, publish and run the real debugger. If the card still shows the wrong picture after a clean scrape, work through the wrong image fix list, and remember that LinkedIn keeps a separate cache with its own tool, the LinkedIn Post Inspector.

What goes wrong

Scraping before purging. The debugger fetches your cached HTML and stores the old tags again with a new timestamp.
Debugging a different URL from the one shared. http against https, www against bare domain, or a missing trailing slash are separate URLs to Meta, each with its own cache and share count.
Two og:image tags. The raw tags list shows both; the card takes one, often the logo. Turn off the second source in your theme or share plugin.
Replacing an image under the same filename. Cached by URL, so the old picture stays. Upload under a new name.
A security rule that blocks the crawler. The debugger then reports the challenge page's title as your title. Allow the facebookexternalhit user agent.
Chasing the fb:app_id warning. It does not change the card. Fix image and URL warnings first.

Check it worked

The last scraped time in the debugger is later than your most recent cache purge.
The raw tags list shows one og:title, one og:description, one og:image and one og:url, all matching your source.
The og:url and canonical URL shown are the same address, character for character.
No warning mentions the image; any remaining warnings are about fb:app_id or optional tags.
The preview shows the large card, not a small square.
A test share from a personal account shows the same card as the debugger.

Sources

Questions

Do I need a Facebook account to use the Sharing Debugger?

Yes. The tool page asks you to log in to Facebook before it runs a check. Without a login you see only the description and the two tabs, Sharing Debugger and Batch Invalidator, with no way to paste a URL.

Why does the debugger still show my old image after Scrape Again?

Usually your own page cache served the old HTML, or you replaced the image under the same file name. Meta caches images by URL, so purge your cache, upload the image with a new name, update og:image, and scrape again.

Does the fb:app_id warning affect my link preview?

No. Meta's documentation ties fb:app_id to Facebook Insights for your site's traffic. The card renders without it. Add the tag only if you want that reporting from Meta.

Will Scrape Again update posts that were already shared?

Not directly. New tags apply to future shares. Meta's FAQ says older posts can be refreshed from the post's menu with Refresh share attachment, and a title may be frozen once a post passes 50 interactions.

Can I trigger a re-scrape without the debugger?

Yes. Send a POST to the Graph API with the encoded URL as id, scrape=true and an access token. Meta's URL reference documents the call, and a success returns a JSON body with success set to true.

Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.

About the editor and our methods

What does the Sharing Debugger do?

Run your first check

Open the tool

Paste the full URL

Read the warnings first

Compare the tags

Fix, purge, scrape

Pre-cache the image