The launch post is live. The homepage is fast. The article ranks. Then someone shares it on LinkedIn and the preview shows the wrong title, no image, and a stale description from last month. The URL works perfectly, so uptime checks stay green. The only broken thing is the metadata that decides whether anyone clicks the link.
Open Graph and social-card metadata are small tags with outsized distribution impact. They control how your pages appear in Slack, Discord, LinkedIn, X/Twitter, Facebook, iMessage, WhatsApp, and many internal tools. When they break, you lose social traffic, trust, and campaign performance without a single server error.
This guide shows how to monitor Open Graph metadata in production: which tags matter, how they break, what to assert, and how to catch broken preview images before a campaign goes live.
What Open Graph Controls
Open Graph tags live in the <head> of a page:
<meta property="og:title" content="Example title">
<meta property="og:description" content="Example description">
<meta property="og:image" content="https://example.com/og-image.png">
<meta property="og:url" content="https://example.com/page">
<meta property="og:type" content="article">
Twitter/X cards use a similar set:
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Example title">
<meta name="twitter:description" content="Example description">
<meta name="twitter:image" content="https://example.com/og-image.png">
These tags are not only for social networks. Chat apps, sales tools, internal docs, and AI crawlers use them as page summaries.
How Social Cards Break
1. Missing image after asset deploy
The page still contains og:image, but the referenced image 404s after a static asset cleanup or CDN path change.
Monitor both the page metadata and the image URL itself.
2. Relative image URL
Some platforms require absolute URLs. This is broken:
<meta property="og:image" content="/assets/og.png">
Use:
<meta property="og:image" content="https://example.com/assets/og.png">
3. Wrong canonical or og:url
og:url points to staging, a previous slug, or a canonical that redirects. Social platforms cache the wrong URL and keep showing stale previews.
4. Image dimensions wrong
Large-preview cards generally expect 1200x630. A 500x500 image may crop badly or render as a tiny thumbnail.
5. Metadata generated client-side only
Many crawlers do not execute JavaScript the same way browsers do. If OG tags appear only after hydration, link previews may miss them. See JavaScript SEO Monitoring.
6. Social crawler blocked
robots.txt, WAF rules, or bot protection blocks facebookexternalhit, Twitterbot, LinkedInBot, or Slackbot. The page works for browsers but not preview crawlers.
See Sitemap & robots.txt Monitoring and HTTP Security Headers Monitoring for adjacent deploy-safety checks.
Metadata Assertions That Work
For every page template, assert:
| Tag | Assertion |
|---|---|
og:title |
Present, non-empty, matches expected pattern |
og:description |
Present, under practical length |
og:image |
Present, absolute HTTPS URL |
og:url |
Present, production URL, no staging host |
og:type |
website, article, product, etc |
twitter:card |
summary_large_image where expected |
twitter:image |
Present or fallback to og:image |
For image URLs, assert:
- HTTP 200
- Content-Type starts with
image/ - Dimensions match expected (1200x630 for OG images)
- File size is not zero
- Cache headers are sane
Which Pages to Monitor
Start with:
- Homepage
- Pricing page
- Product pages
- Top blog posts by organic traffic
- New blog posts for first 7 days after publish
- Landing pages used in paid/social campaigns
- Docs pages that sales/support frequently share
For blogs, add a post-publish check: every new article should have the correct og:image and appear in the sitemap. Pair with Structured Data Monitoring.
Social Preview Cache Reality
Platforms cache previews aggressively. If a bad card is fetched once, fixing the tag may not update previews immediately.
Tools:
- Facebook Sharing Debugger
- LinkedIn Post Inspector
- X Card Validator (where available)
- Slack unfurl testing
Monitor before launch, not after the campaign starts. A preflight check can catch a missing image before the first share poisons the cache.
Alerting Thresholds
Critical
og:image404s on campaign landing pageog:urlpoints to staging or wrong domain- Social crawler receives 403/blocked response
- OG tags missing site-wide after deploy
High
og:imageis relative URL- Image dimensions differ from expected
og:titleorog:descriptionemptytwitter:cardmissing on share-heavy pages
Informational
- OG image changed
- Description changed
- Image cache headers changed
Open Graph Monitoring Checklist
- OG tags asserted on homepage, pricing, product pages, and top posts
-
og:imageURL monitored separately - OG image dimensions checked
-
og:urlasserted against canonical production URL - Staging domains denied in metadata
- Twitter/X card tags present
- Social crawlers not blocked by WAF or robots rules
- New post publish workflow includes OG preflight
- Campaign landing pages checked before launch
- Preview cache refresh process documented
How Webalert Helps
Webalert can catch social-card breakage with simple external checks:
- Content validation - Assert
og:title,og:image,twitter:card, and canonical metadata exist. - Negative assertions - Alert if metadata contains
staging,localhost, or an old domain. - Image monitoring - Check
og:imageURL status, content type, and response time. - Crawler simulation - Use social-bot user agents to detect WAF or bot-blocking issues.
- Post-publish checks - Monitor every new blog post for OG metadata before indexing and sharing.
Example Webalert setup:
- URL:
https://example.com/blog/new-post - Must contain:
<meta property="og:title" - Must contain:
<meta property="og:image" content="https:// - Must not contain:
staging.example.com - Image URL check: expected 200 and
image/pngorimage/jpeg
Summary
Open Graph metadata is small, but it controls how your pages travel through social channels, chat tools, and link previews.
Monitor the tags, monitor the image URL, and monitor social-crawler access. The page can be up while the preview is broken, and by the time a platform caches the bad version, the damage is already public.