Take any link to your website. Paste it into a Facebook status, a LinkedIn post, an iMessage thread, a Slack channel, a Discord server. Look at what shows up.
If your link previews as a blank rectangle, a tiny generic icon, or a low-resolution screenshot of the wrong part of the page, that is an Open Graph problem. It is invisible from your end (you do not see what your visitors see when they share), but it costs real engagement every time someone tries to share your work.
Open Graph images are part of the standard plan on every site I build. This post walks through what they are, why they matter, how I produce one for every key page on every client site, and how you can check your own site in 30 seconds with the free OpenGraph.xyz inspector.
What Open Graph actually is
Open Graph (OG) is a small set of meta tags Facebook introduced in 2010 to tell social platforms how a webpage should appear when someone shares its link. The standard now extends well beyond Facebook: LinkedIn, X (formerly Twitter), Slack, Discord, iMessage, WhatsApp, Pinterest, Reddit, Microsoft Teams, and the unfurled-link previews in Notion, Roam, and Obsidian all read the same OG tags.
The four tags that matter most:
og:title— the headline shown above the link preview.og:description— one or two lines of preview text.og:image— the rectangular image that appears alongside (the most visible piece).og:url— the canonical URL the platform should link to.
Twitter / X reads its own near-identical set (twitter:title, twitter:description, twitter:image, twitter:card). LinkedIn, Slack, iMessage, and the rest fall back to the OG tags and render a card from those.
If your site is missing these tags, every shared link defaults to a generic preview: a blank or near-blank box, a thumbnail of whatever image the platform happened to find first, or a low-quality screenshot of the page header. The link is far less likely to be clicked, and the brand impression that comes with the share is wasted.
What a good Open Graph card looks like
The technical specification is consistent across every platform that consumes OG:
- Image dimensions: 1200×630 pixels exactly. Anything smaller renders as a thumbnail (tiny). Anything larger gets cropped (often badly). The 1.91:1 aspect ratio is the standard for full-width social cards.
- File format: PNG or JPG. WebP works in some places but not others; PNG is universally safe.
- File size: Under 5 MB; in practice under 300 KB is ideal so previews render fast.
- Image content: Some text large enough to read on a phone preview (about 22 point and up at the original 1200×630 size), brand identity (logo or wordmark), and ideally a call-to-action element so the shared card feels purposeful.
The dimensions matter more than people realize. A site that declares a 2400×1260 image (a 2x retina export) often gets rejected by Facebook's preview cache, because the file does not match the declared og:image:width and og:image:height meta tags. The fix is to export at exactly 1200×630.
How I build OG cards for every client site
The standard plan ships with a per-page Open Graph image generator that runs at build time. The flow is:
- Each client gets a brand-aligned OG template at design time. Same fonts as the site, same color palette, same wordmark placement, an explicit call-to-action button. The template is one HTML file with CSS variables for the title and eyebrow text.
- For every blog post, every season landing page, every key conversion page, and the homepage, the build pipeline renders the template with that page's specific title and saves a 1200×630 PNG to a per-page path.
- Each page's HTML
<head>declaresog:imagepointing at its own custom card, withog:image:widthandog:image:heightmeta to lock the aspect ratio. - A small alt-text string is included for screen readers (most platforms ignore it but LinkedIn uses it).
The result: every page on the site has a unique, branded share card. When a client posts a link to their roofing-warranty page, the preview shows that page's title rendered onto the brand template with the company logo and a "Get a free inspection" button. The share looks like a polished asset, not a default fallback.
None of this requires the client to do any work. They write the page. The build does the card.
Why per-page beats a single sitewide image
A common pattern on small-business websites is one Open Graph image set sitewide: every link, regardless of which page is being shared, previews with the same generic homepage card.
This is better than nothing. It also misses the point.
The Open Graph card is the sales card for the specific page being shared. A blog post about hail damage shared on a community Facebook group should preview with the post's actual title, not "Welcome to ABC Roofing." A service-area page shared in a regional homeowners' forum should preview with that area's name. The link being shared is the link being shared; the preview should reflect the page, not the brand's main marketing pitch.
The lift in click-through rate from per-page OG cards over sitewide cards is real. The Markup, BuzzFeed, and major publishers all run per-page; the reason is that the cards earn the click on engagement-driven platforms.
How to check your own site in 30 seconds
The easiest free tool I have found is OpenGraph.xyz. The flow:
- Visit opengraph.xyz.
- Paste the URL of any page on your site (the homepage is fine to start; an individual blog post is more revealing).
- Click "Inspect."
- Read the report.
The tool returns a side-by-side preview of how the page will look on Facebook, X, LinkedIn, Discord, and Slack. Each preview shows what the actual platform would render: the image, the title, the description, the URL. If the image is missing, broken, or the wrong size, the preview shows what the visitor would see, which is usually a sad-looking fallback.
The tool also lists the raw OG and Twitter meta tags it found. If og:image is missing, it says so. If the image dimensions do not match the declared og:image:width and og:image:height, the tool flags the mismatch. If the title is too long (over 70 characters tends to truncate on Twitter), the tool flags that too.
What the most common failures look like
"og:image is missing." The site has no Open Graph image at all. Every shared link previews as a blank box. This is the most common finding on small-business sites built five or more years ago, before OG became standard.
"og:image returned a 404." The site declares an image URL that does not exist on the server. Often happens after a site migration when the meta tag was not updated. The result is the same as missing: blank preview.
"og:image is 2400×1260 but og:image:width is 1200." The image is technically correct but the dimensions do not match the declared meta. Facebook in particular is strict about this and may reject the image entirely.
"og:image is the same on every page." Sitewide image instead of per-page. Functional but suboptimal. Usually a fixable configuration issue rather than a missing-image problem.
"og:title is the same as the page title but og:description is missing." Half of the meta is in place. Add the description tag and the previews will show the line of context that was missing.
How to fix it
The fix path depends on what platform your site is on.
Custom-coded sites: Add the meta tags to the page's <head> template. If you are using Eleventy, Next.js, Astro, or any modern static-site generator, every framework has a built-in pattern for this. The build pipeline can also auto-generate the per-page image if you set up a small script. (For my clients, this is part of the standard plan and runs without any client involvement.)
WordPress: Yoast SEO and Rank Math both handle OG tags out of the box. Both have settings panels for sitewide defaults plus per-post overrides. The image generation is manual unless you use a plugin like Open Graph Image (which is decent but creates an extra plugin dependency).
Wix and Squarespace: Both platforms handle OG tags automatically and let you upload a per-page image. The catch is that the auto-generated card design is generic and not customizable, so the brand fidelity is low. Squarespace 7.1 is meaningfully better than older Squarespace builds.
Shopify: Built-in, with theme-level customization. Newer themes do this well; older themes vary.
The thirty-day argument
If your site is missing or broken Open Graph data, the lift from fixing it is substantial and shows up within thirty days. Every existing share starts looking right (most platforms re-cache periodically). New shares look right immediately. Click-through rates on shared links measurably increase. The work is small relative to the impact.
The reverse is also true: a site that has been live for years without working OG tags has been quietly losing engagement on every share that has happened in that whole time. The link previews looked broken; the people who saw them assumed the brand was casual about its own marketing. That is an unrecoverable cost on links already shared, and a recoverable one going forward.
Run the check on your own site
Two tools, both free, both worth bookmarking:
- opengraph.xyz — the cleanest free OG inspector. Shows previews across five major platforms and flags common failures.
- Facebook Sharing Debugger — Meta's own tool. Useful when Facebook has cached an old version of your card and you need to force a refresh. The "Scrape Again" button is the fix for stale Facebook previews.
Run them on your homepage, then on three or four interior pages (a service page, a blog post, a case study, a contact page). The differences across pages tell you whether the implementation is sitewide or per-page. The presence or absence of an image tells you whether the implementation is there at all.
If the report comes back with missing tags, broken images, or sitewide cards where you would benefit from per-page, that is a real opportunity to improve. The fix is not expensive in any of the platforms above, and the return on getting it right shows up the next time someone shares one of your links.
Per-page Open Graph cards ship with every site I build.
Custom-coded sites with branded share images on every blog post, season page, and key landing page — generated automatically at build time. $175 a month, flat.