Facebook Debugger

The Facebook Debugger does one thing well: it shows you exactly what Facebook sees when it crawls your URL. Paste a URL, click Debug, and you get a clean breakdown of the title, description, image, and any warnings. Last week I checked a client's product page. The debugger flagged that the og:image was only 200x200 pixels. Facebook recommends 1200x630. I uploaded a larger image, hit Scrape Again, and the preview updated within a minute. Without the debugger, that product would have been shared with a tiny, blurry thumbnail. The Scrape Again button is the killer feature — it forces Facebook to re-crawl the URL and update its cache. Some developers argue you can just use browser developer tools to inspect the page source. But the source doesn't tell you what Facebook cached. The debugger shows the actual data Facebook uses. A decision rule: only use Scrape Again after you have confirmed the new tags are live. Running it twice in a row without changes won't help. An edge case: if your site is behind a CDN, you may need to purge the cache before scraping again. I've had cases where Cloudflare's cache served an old version even after I updated the tags. I changed my mind about relying on a single scrape — now I always check the CDN first.

The biggest limitation is that it only checks Facebook. If your link gets shared on Twitter or LinkedIn, you need separate validators. I once spent hours debugging a Facebook preview only to realise my page's schema markup was wrong for Google. The debugger gave no clue about that. Another awkwardness: sometimes it shows stale data even after you hit Scrape Again, especially if your server or CDN has aggressive caching. I used to think a single Scrape Again was enough. Now I know I need to wait for the cache to propagate, and sometimes do two scrapes. Also, it doesn't provide bulk checking — you have to enter URLs one by one. For site-wide audits of Open Graph tags, you want a crawler like [Screaming Frog](/screaming-frog/) to export missing or broken values across hundreds of pages. The debugger's warnings can also be vague: it'll say 'Inferred Property' without telling you which og tag is missing. And it doesn't check structured data or schema markup at all. If you need that, you're better off with [Ahrefs](/ahrefs/) site audit or [Semrush](/semrush/) on-page checker. I've learned to treat the debugger as a quick sanity check, not a comprehensive diagnostic tool. For speed-related issues that affect cache, I sometimes use a [website speed test](/website-speed-test/) to see if server response times are causing delays in Facebook's fetch.

For Twitter previews, I use the Twitter Card Validator directly. For LinkedIn, the Post Inspector is identical in concept. For a broader social preview check across platforms, I sometimes use Metatags.io, though it doesn't force re-scrapes — it only shows a one-time rendering. For search engine snippets, I rely on Google Search Console's URL Inspection tool or the rich results test. For site-wide metadata audits, I'd run a crawl with Screaming Frog to export all og tags and check for missing or broken values. Ahrefs site audit has an OG tag check and Semrush on-page checker can flag missing metadata, but for a quick one-URL fix, the Facebook Debugger is still the most direct tool for its platform. The debate between using a dedicated tool versus a general [SEO tools](/seo-tools/) suite comes down to frequency: if you only fix one page a week, the debugger is fine. If you manage dozens of sites, invest in crawler software. The debugger is free and requires no login, though you may need to log into a Facebook account to see some details. If you want to automate social preview testing, consider hitting the Facebook Graph API's scrape endpoint — but for daily use, the debugger's interface is simpler.