Open Graph Generator: A Practical Setup Guide for Any Site

If you're setting up an open graph generator on a site for the first time, the whole process comes down to four steps done in order: decide what content to represent, generate an image, add the tags, and verify the result actually works before you assume it does. Skipping the verification step is the single most common reason people end up debugging a broken preview weeks later instead of catching it immediately. This is a start-to-finish walkthrough for getting it right the first time.

Step 1: decide what each page should represent

Before touching any tags, decide what a preview should communicate for each type of page on your site. A homepage preview usually needs your brand name, a tagline, and a logo. A blog post preview usually needs the post's actual headline, not a generic site-wide image. A product page usually needs the product photo and name. This sounds obvious, but it's the step most commonly skipped — people copy one og:image across every page type because it's faster, and end up with previews that don't distinguish a blog post from the homepage from a pricing page.

Step 2: generate the image

Design or generate an image at 1200×630px, the aspect ratio that renders correctly across the largest number of platforms without cropping oddly. Keep text and logos away from the outer 5–8% of the frame, since several platforms crop tighter than the full canvas. If you're doing this by hand in a design tool, export as PNG for anything with text or sharp UI elements, since PNG avoids the compression artifacts JPEG introduces around fine detail. If you're generating dynamically — which you'll want the moment you have more than a handful of pages — a template-based tool handles this sizing and margin logic once, and every page inherits it.

Step 3: add the meta tags

With the image hosted at a publicly reachable, absolute URL, add the tag set to the page's head. At minimum:

<meta property="og:title" content="Your page title" /> <meta property="og:description" content="A one to two sentence summary." /> <meta property="og:image" content="https://yoursite.com/preview.png" /> <meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" /> <meta property="og:url" content="https://yoursite.com/page" /> <meta property="og:type" content="website" /> <meta name="twitter:card" content="summary_large_image" />

A few things matter more than they look like they should here. The image URL has to be absolute, not relative — a relative path fails silently on crawlers that don't resolve it against the page origin. The tags have to render server-side or at build time; if they're injected by client-side JavaScript after the page loads, most social crawlers, which don't execute JS, will never see them. And twitter:card needs to be set explicitly — without it, X often falls back to a smaller thumbnail even when a perfectly good og:image is present.

Step 4: verify with a debugger before trusting it

This is the step that gets skipped most often, and it's the one that actually catches problems before they've been live for weeks. Don't assume the tags work because they look syntactically correct in the page source — use a debugging tool that shows what a real crawler actually parses. Facebook's Sharing Debugger is the most commonly used, since Facebook's crawler behavior is broadly representative of how other platforms read Open Graph tags, but it's worth checking at least one other platform too, since LinkedIn in particular is stricter about image reachability than Facebook is.

• Paste the URL into a debugging tool and confirm the image actually loads, not just that a URL is listed
• Check that the title and description shown match what you set, not a fallback the crawler guessed at
• Verify the image isn't cropped in a way that cuts off important text or a logo
• Repeat the check on at least one platform besides the one you tested first

Step 5: plan for what happens when the page changes

A working preview on launch day isn't the end of the setup — most platforms cache the metadata they scrape the first time a URL is shared, and won't automatically notice if you update the title, description, or image later. If you rename a product or refresh a blog post's headline, the old preview can persist in a platform's cache until something forces a re-fetch. Deciding upfront whether that's something you'll manage manually per page, or whether you want a tool that handles cache invalidation and re-verification for you, saves a debugging session later when a stale preview shows up on a page you thought was fixed.

Common setup mistakes worth double-checking

A handful of mistakes account for most of the broken Open Graph setups actually seen in the wild, and they're worth checking for specifically rather than assuming your setup avoids them by default. The most common is a relative image path that works fine in a browser, because browsers resolve relative URLs against the current page automatically, but fails on crawlers that don't perform that resolution the same way — always use the full https://yoursite.com/... form. The second most common is tags injected by client-side JavaScript on a single-page application, which render correctly for a human visiting the page but are invisible to crawlers that only read the initial server response and don't execute scripts. The third is forgetting that a CDN or reverse proxy sitting in front of the site can itself require configuration to pass crawler requests through correctly, particularly if it's set up to block or rate-limit unfamiliar user agents, which some crawlers present as.

• Relative image URLs that resolve fine in a browser but fail for crawlers
• Tags injected client-side on an SPA, invisible to non-JS-executing crawlers
• A CDN or WAF blocking crawler user agents as if they were bots to filter out
• Forgetting og:url, which leaves some platforms attributing the share to a redirect chain instead of the canonical page

A minimal timeline for a first-time setup

For a small site doing this for the first time, the whole sequence above realistically fits into an afternoon: designing or generating one 1200×630px image, writing the tag block once and templating it across page types, and running a debugger check on two or three representative URLs. The part that takes longer isn't any individual step, it's remembering to come back and redo the verification step after the next redesign — which is worth writing down as an explicit task somewhere rather than relying on memory, since it's the step with no visible symptom when it's skipped until someone happens to share a stale link.

Set a reminder tied to your redesign or deploy process rather than a calendar date — the trigger that matters is a change to the page's title, image, or layout, not the passage of time on its own.

How useopengraph handles this end to end

useopengraph is built to cover this entire sequence in one place rather than as separate manual steps. You design a template once, publish it to a versioned, immutable render URL at /api/render/{templateId}/v{version}/..., and the Cache Debugger lets you check exactly what Facebook, Twitter, LinkedIn, and other crawlers would parse right now, bypassing their own cached version — including the ability to force-refresh Facebook's cache through their Sharing Debugger API directly, rather than leaving you to go do that manually every time something changes.