Broken OG Image Checker: Finding Dead Image URLs Across a Whole Site

A broken og:image checker exists because the failure mode it catches is invisible everywhere except the one place that matters. The og:image tag itself is a URL, not an embedded file, and a URL can point at nothing — a deleted asset, an image host that migrated domains, a CDN path that got restructured — without the page that references it showing any sign of trouble. The page renders normally in a browser. Search Console doesn't flag it. The only place the break is visible is inside a social platform's card renderer, after someone has already pasted the link, and by then the damage — a blank gray box or a broken-image icon where a preview should be — is already showing to whoever they shared it with.

Why og:image links die even when nothing about the page changes

The page's HTML can stay completely untouched and the og:image tag can still go dead, because the image URL and the page are usually served from different systems. A few patterns account for most of it. Asset migrations move images to a new CDN or storage bucket and update the site's rendered pages but miss the URLs baked into older, cached metadata. Image hosts get decommissioned or renamed entirely, taking every reference with them at once. A CMS plugin or theme change alters how image paths are generated going forward, but doesn't touch the paths already saved on existing posts, so new content works fine while a large slice of the back catalog silently breaks. And straightforward deletion — someone cleans up an old media library and doesn't check what still references a file — kills the reference without anyone noticing until a share goes out.

None of these show up in a normal QA pass, because normal QA means loading the page and looking at it. The og:image tag isn't rendered on the page itself — it's metadata read by crawlers, not by browsers — so a page can look perfect and still ship a 404 to every platform that tries to unfurl it.

What a broken og:image checker actually verifies

Checking whether an og:image is 'broken' is more than checking whether the tag exists. A tag can be present and still fail in several distinct ways, and a real checker needs to catch all of them rather than stopping at presence:

• 404 or 5xx response — the URL returns an error instead of an image
• Redirect chains — the URL resolves eventually, but through enough hops that some platforms time out or refuse to follow it
• Wrong content type — the URL returns HTML (a login wall, an error page styled as a page) instead of an actual image file
• Fetch timeout — the image exists but is hosted somewhere slow enough that a crawler gives up before it downloads
• Zero-byte or corrupted files — the response succeeds but the image data itself is empty or unreadable

A checker that only confirms the tag is present and skips the fetch will pass pages that are actually broken, which defeats the point — the whole failure mode being guarded against is a tag that looks fine in the source and fails the moment a real platform tries to load it.

Why checking one page at a time doesn't find the real problem

The instinct when you notice one broken preview is to fix that one page and move on. That's usually a mistake, because a single broken image URL is rarely an isolated incident — it's almost always a symptom of a systemic cause, like a CDN migration or a plugin change, that affected every page built the same way. Fixing the one page you happened to notice leaves the other fifty untouched, and you'll keep discovering them one embarrassing share at a time instead of all at once. The pages most likely to be affected are also the ones least likely to get checked manually: older posts, low-traffic product pages, anything nobody has opened in months, which is exactly where a stale image reference sits quietly until someone finally links to it.

Crawling instead of spot-checking

A site-wide crawl treats every reachable URL as a candidate rather than relying on someone's memory of which pages exist. It walks the sitemap or link graph, pulls the og:image URL off every page, actually fetches each one, and records what came back — not just whether a tag was present in the source. That distinction is the entire value of the check: a crawler that only parses HTML for the presence of an og:image tag will happily report a page as passing when the image behind that tag is a 404. Fetching the image and checking the response is what turns a checklist item into an actual finding.

Prioritizing what you find

A crawl of a large site will usually surface more broken images than you can fix in an afternoon, so triage matters as much as detection. Group findings by root cause first rather than fixing URLs one at a time — if forty pages are all missing images from the same old CDN path, that's one fix (update the template or bulk-update the stored URLs) rather than forty. After grouping by cause, sort by traffic or share volume: a broken image on a page that gets linked from your newsletter every week is costing you real click-through right now, while the same issue on a page nobody visits can wait. Re-run the check after each fix, because a template-level fix that looks complete can still miss edge cases — a product type with a different field name, a legacy post format — that only a follow-up crawl will catch.

The false confidence of viewing a few pages by hand

A common way teams reassure themselves is opening a link in a debugger tool like Facebook's Sharing Debugger or Twitter's card validator, seeing the image render correctly, and concluding the site is fine. That check is real, but it only proves the one URL you tested is fine at the moment you tested it. It says nothing about the other few hundred pages you didn't test, and it's especially misleading right after a fix, because a debugger tool often shows you a cached preview from before the fix rather than the current live state — so a page you 'confirmed' working might have been broken the whole time and you were looking at stale cache. The instinct to trust a spot-check because it looked fine is exactly the gap a systematic checker is built to close: it doesn't sample, it checks every page, and it fetches the image fresh rather than trusting whatever a platform happened to have cached.

Third-party image hosts add a layer you don't control

A meaningful share of broken og:image URLs trace back to images hosted somewhere other than the site's own infrastructure — a design tool's asset export, a stock photo CDN, a marketing platform's media library used because it was convenient at the time. These are riskier by default, because the uptime and URL stability of that image is now dependent on a third party's decisions, not yours. A stock image provider reorganizing its URL structure, a design tool changing how it serves exported assets, or a free-tier hosting limit being hit can all kill an image reference without a single change happening on your own site. Auditing for broken og:image URLs is partly a check on your own site and partly a check on every third-party dependency your metadata quietly relies on — which is one more reason a manual, occasional glance isn't enough; those third-party failures happen on someone else's schedule, not yours.

How useopengraph handles this

Site Audits in useopengraph crawls a site's pages — the page limit depends on plan tier — and checks og:image presence and dimensions as part of the standard audit, alongside og:title, og:description, twitter:card, meta description length, and image alt text. Because it fetches and validates rather than just parsing tags out of the HTML, a dead image URL shows up as a flagged finding on the specific page it's broken on, not as a false pass. Audits also flag regressions between runs, so if a CDN migration or a media library cleanup takes down a batch of image URLs after your last audit, the next run surfaces exactly which pages newly broke instead of leaving you to rediscover them one bad share at a time. For agencies or teams running the Drift Monitor on the Agency plan, the same mechanism catches an og:image tag whose value changes to point at a different — and possibly broken — URL, even when the tag itself never disappears.