How to Audit Every og: Tag on Your Site (Not Just Spot-Check One Page)

The usual way people check their og: tags is opening a page, viewing source, and scanning for og:title, og:description, and og:image. That works fine as a spot check on a single page you just edited. It tells you nothing about the other pages on your site, which is where most og tag problems actually live. A proper og tag audit means checking every reachable page against a consistent set of criteria, not confirming that the one page you happened to look at is fine — because the pages most likely to have a broken or missing og: tag are exactly the ones nobody thought to check by hand.

Why spot-checking misses the real problems

Spot-checking is biased toward the pages that are top of mind — the homepage, the page you just published, the one a colleague mentioned. It's structurally blind to everything else: the blog post from two years ago, the product page generated by an import script, the docs page that survived a site restructure without picking up the current template's defaults. Those are precisely the pages where og: tags tend to break, because nobody is actively maintaining them and nobody notices when a CMS update or template change stops applying the right defaults. A site can have flawless og: tags on the ten pages everyone checks and be quietly broken across hundreds of pages nobody looks at, and spot-checking will never surface that gap because it only ever samples the pages people already trust.

What a real og tag audit checks per page

A thorough audit runs the same mechanical checklist against every page in the crawl, rather than a general impression of whether tags 'look right':

• og:title present and specific to the page, not empty and not a site-wide default repeated everywhere
• og:description present, unique, and not truncated in a way that cuts off mid-sentence when rendered
• og:image present and resolving to an actual file — not a 404, not a redirect chain, not an image so large it fails to load in time
• og:image:width and og:image:height set correctly, since platforms that don't get explicit dimensions may have to fetch the full image just to determine them
• twitter:card set appropriately so previews degrade correctly on X instead of showing a bare link
• Values consistent with the actual page content — an og:title that matches an old version of a headline is a sign of drift, not just a presence check passing

That last point matters more than it looks like at first glance. A tag being present isn't the same as a tag being correct. A page can have a fully populated og:title that says something that stopped being true months ago — an old price, a discontinued product name, a headline from before a rewrite — and a presence-only check will report it as passing every time, because as far as presence is concerned, nothing is wrong. A real audit needs to at least flag when a value looks stale or inconsistent with the page it's supposedly describing, not just confirm the field isn't blank.

Crawling vs. relying on a sitemap alone

Where an audit starts matters. Using the sitemap as a starting point is reasonable, but a sitemap only lists what someone remembered to include in it — pages generated dynamically, added by a plugin, or created outside the normal publishing flow can be live and shareable while missing from the sitemap entirely. A crawl that follows the site's actual link graph, not just its sitemap, catches pages that exist in practice but were never formally registered anywhere. It should also respect robots.txt, so pages you've deliberately excluded from crawling and indexing don't show up as false positives in an audit report — an intentionally noindexed page missing an og:image isn't a bug, and a good audit shouldn't flag it as one.

One pass isn't enough

Running an og tag audit once and fixing everything it finds solves the problem as of that moment. It says nothing about six months from now, after a template change, a CMS upgrade, or a migration quietly reintroduces the same class of problem on a new batch of pages. og: tags don't stay fixed on their own — a redesign can wipe out a template's default og:image reference, a plugin update can change how titles are generated, a new content type can launch without anyone wiring it into the same metadata pipeline everything else uses. The only way to catch that kind of regression before it's been live for months is to run the audit on a recurring basis and compare each run against the last one, so a page that used to pass and now fails gets flagged as a change instead of blending into a long list of current-state failures with no history attached.

Turning results into fixes

A list of every page with a missing or wrong og: tag is a starting point, not a finished job — the order you work through it matters. Prioritize by traffic and share frequency rather than crawl order: a missing og:image on a page that actually gets linked from newsletters or shared socially is costing real impressions every day it stays broken, while the same gap on a page with no traffic isn't urgent. It's also worth checking whether the flagged pages share a template or content type, since fixing the underlying template usually resolves dozens of individual page failures in one change, rather than requiring a page-by-page fix that leaves the root cause in place to affect the next page built from the same template.

Auditing after a migration specifically

Platform migrations deserve a dedicated og tag audit rather than folding into the general recurring schedule, because migrations are disproportionately likely to break metadata across a large share of a site's pages at once. Moving a site from one CMS to another, or restructuring URLs, tends to carry over content faithfully while dropping the metadata layer that lived in template code the migration script never touched. The failure mode here is different from the usual slow drift of individual pages going stale one at a time — it's an entire site's worth of og: tags reverting to defaults or disappearing in a single event, which is exactly the kind of large, sudden regression a full-site audit run immediately after a migration is built to catch before it's been live and unnoticed for weeks.

The same logic applies to a domain change or a redesign that touches shared layout components, even without a full platform migration behind it. Any event that rewrites how a large group of pages is built is an event worth auditing immediately afterward, on the assumption that something in the shared logic could have changed even if nothing about the individual page content did. Waiting for the next scheduled recurring audit to catch it means living with whatever broke for however long is left until that run — running one manually right after the change closes that window instead of leaving it open by default.

How useopengraph handles this

Site Audits in useopengraph crawl a site's pages, checking og:title, og:description, and og:image presence plus dimensions along with twitter:card, meta description length, and image alt text — across the whole site rather than the page you happen to be looking at. Audits flag regressions between runs, so a page that used to have a correct og:image and now doesn't shows up as a change worth investigating, not just another line in a static report. For teams on the Agency plan, Drift Monitor goes a step further and catches a tag's value silently changing even while it's technically still present, closing the gap that a simple presence check can never see on its own.