How to write OG tags that drive social CTR

Open Graph tags are the most-skipped on-page work in SEO, even though they often produce the highest immediate ROI of any change you can ship. They don't help you rank on Google. They DO help you collect 30-50% more clicks every time someone shares your page on LinkedIn, X, Slack, Discord, iMessage, Facebook, WhatsApp, and every other platform that renders link previews.

This guide skips the basic "what is Open Graph" framing (the tools below cover that) and goes straight to the writing playbook: the per-platform image dimensions that actually matter, the cache-bust workflow when previews don't update, and the og:image fallback chain that prevents broken thumbnails when the primary image fails.

Inspect any URL's social preview right now

Two tools work together here. The Open Graph Tags Checker pulls every og: and twitter: tag from any URL, so you can see what Facebook, LinkedIn, and X are actually reading. The Google SERP Simulator covers the on-Google preview - useful when you want to see the title and description side-by-side before publishing.

Why off-Google previews matter as much as the SERP

Most teams treat OG tags as a nice-to-have. Look at where your traffic actually comes from and you'll see the math doesn't support that:

• For B2B SaaS, ~30-40% of new-visitor traffic comes from social shares (Twitter/X, LinkedIn, Slack, internal Slack channels at customer companies). All of these render OG-tag previews.
• For B2C content, every viral spike happens on a platform that uses OG tags - Facebook, Twitter/X, Reddit. The peak-traffic moment for any blog post is governed by what the OG image looks like, not what's in the body.
• Internal company tools - Slack, Microsoft Teams, Discord, Notion, internal wikis - render OG previews when employees share links. A polished preview signals "this is a serious resource"; a stripped link looks like a quick aside.
• Search-result pages on Bing, Yandex, and DuckDuckGo also pull from og:image for some result types. Even if you only care about Google, og:image gives you free coverage on the long tail.

The investment-to-return ratio is unreasonably good: 30 minutes per content template to set up OG tags correctly, and every share on every platform from then on gets a polished preview.

The image dimension trap (and the one size that actually works everywhere)

Every platform has slightly different image-dimension specs. Facebook says 1200x630. LinkedIn says 1200x627. Twitter/X says 1200x675 for summary_large_image. Slack pulls from og:image. The web-developer's instinct is to provide multiple sizes via twitter:image, og:image, and platform-specific tags.

The pragmatic answer: ship one image at 1200x630. Every major platform handles it correctly:

• Facebook renders it natively.
• LinkedIn auto-crops the bottom 3px - imperceptible.
• Twitter/X with summary_large_image card renders the top 1200x675 region (it crops the bottom 45px). As long as your text/logo is centered in the top 75% of the image, this looks fine.
• Slack and most other unfurl-renderers respect 1200x630 as-is.

The audit move: do not ship multiple per-platform images unless you have a high-volume use case that justifies the maintenance cost. One 1200x630 image, set as both og:image and twitter:image, covers 95% of share contexts cleanly.

The image content matters more than the dimensions. The image should:

• Be readable at thumbnail size. Most platforms render OG images small (300-600px wide on Slack/Twitter timelines). Tiny text disappears.
• Not put critical text in the bottom 45px (Twitter cropping zone) or in the leftmost / rightmost 50px (universally cropped on some mobile views).
• Include the page title or value-prop text - the og:title rendered alongside is often truncated more aggressively than expected, so the image carrying the message is a safe pattern.

The cache-bust workflow: why your preview shows the OLD image

You ship a new OG image, share the link in Slack to test, and the preview shows the OLD image. This is the most common OG bug, and it has nothing to do with your code - it's the platforms aggressively caching previews. Each platform caches independently and invalidates on different rules:

• Facebook caches OG data for 7 days. Force a refresh at developers.facebook.com/tools/debug/ - paste the URL, hit "Scrape Again."
• LinkedIn caches OG data for 7 days. Force a refresh at linkedin.com/post-inspector/.
• Twitter / X doesn't have a public refresh tool anymore (as of 2024). The workaround: append a cache-busting query string (e.g., ?v=2) when sharing the link. The new query string is read as a different URL by the cache.
• Slack caches per-workspace per-URL for ~6 hours. The cache-bust query string trick works here too.
• iMessage / WhatsApp cache aggressively per-device. There's no refresh mechanism; the only fix is waiting or using a different URL.

The audit move when launching a new social-share image: shorten your test loop by always testing with the platform debugger (Facebook, LinkedIn) rather than by pasting in a private channel. The debugger forces a fresh fetch, which is what you want for verification. Once verified there, the preview will be correct everywhere within the platform's cache window.

The biggest mistake: missing fallback when the primary image is unreachable

The most common OG bug in production is not a missing tag - it's an OG image URL that returns 404 or that's blocked by a CDN rule. The image was deleted from S3, the CDN was misconfigured to require auth on bot user-agents, the image was moved to a different path. The OG tag still exists; the image it points to no longer loads.

Result: when someone shares the link, every platform falls back to ITS guess at what the page is about. Facebook scans the page DOM for the largest image and uses that. Twitter shows a card with no image. Slack shows a stripped link with no preview. None of these are good.

The fallback workflow that prevents this:

1. Always have a default fallback image at the site level - a clean branded image at /og-default.png that works if no page-specific image is set.
2. Pre-publish, run the page through the OG tags checker - it shows whether the image URL actually loads and what dimensions the platforms see.
3. Block the OG image URL from any auth or rate-limit rules at the CDN. Bot user-agents (Facebook External Hit, LinkedInBot, Twitterbot) need access without browser-like challenges.
4. Monitor uptime on a sample of OG image URLs. If your monitoring tool can ping /og/posts/post-slug.png on a schedule, you catch CDN regressions before they kill social CTR site-wide.

The 404 OG image is one of those bugs that doesn't break anything visible on the site - the page still renders fine for users; just the social preview is silently broken. That's why it lives for months on most sites before someone notices.

What a clean OG audit looks like

Run this on the top 20% of your pages by inbound social traffic, plus on every content-template page (one blog post, one product page, one category page) after any template change.

1. Run the page through the Open Graph Tags Checker. Verify every required tag is present: og:title, og:type, og:image, og:url, og:description, twitter:card (= summary_large_image), twitter:image, twitter:title, twitter:description.
2. Verify image dimensions and accessibility. The og:image URL should return a 200 status code with an actual image. If it returns 404, blocks bots, or returns an HTML page, fix it before doing anything else.
3. Test image rendering at thumbnail size. Open the image in a browser, shrink the window to ~300px wide. If the text or logo becomes unreadable, redesign the image - that's how 60% of users will actually see it.
4. Run the URL through Facebook's debugger and LinkedIn's post inspector. Hit "Scrape Again" / "Inspect" to force a cache refresh. Verify the rendered preview matches what you intended.
5. Spot-check Slack and X by sharing the link in a private channel with a fresh cache-buster query string. Confirms the multi-platform behaviour matches the single-platform tests.
6. Audit the og:title and og:description for duplication with the SEO meta tags. Sometimes they should be identical (the page is about one thing); sometimes they should differ (the og: variant is more click-baity for social, while the SEO meta is more keyword-aligned). Don't blindly emit identical tags - decide per content type.

Quick quiz: are you ready to audit your own OG tags?

Five questions, takes two minutes. We'll show you the right answer and a one-line explanation after each one.

You've finished the On-Page SEO pillar

That's the full On-Page SEO pillar: titles, descriptions, headers, canonicals, and Open Graph. Each guide has a working tool, a checklist, a download, and a quiz - the four embeds are deliberate, because the goal is to close the loop from "I read about it" to "I can rewrite my own pages right now."

The next pillar in the SEOGraphy Learn hub is Off-Page SEO and Link Architecture, covering anchor text, internal linking strategy, external links, the nofollow / sponsored / UGC rels, and broken-link cleanup at scale.