Fix Social Previews: Server Rendered Open Graph Tags for UK SMEs

Add a minimal Open Graph block (og:title, og:description, og:image, og:url and og:type) served in server-rendered HTML with absolute HTTPS image URLs. Open Graph tags are the bits of code that tell Facebook, LinkedIn and X what to show when someone shares your link. Get that block right first, before worrying about anything fancier, and your previews will stop looking broken or blank — a crucial step when planning an effective and impactful social advertising strategy.

TL;DR:

• Using full HTTPS URLs with recommended sizes of 1200x630 pixels ensures social platforms display your images correctly across all devices.
• Adding og:image:alt improves accessibility and helps AI engines better interpret your images during sharing.
• For X, include twitter:card="summary_large_image" to guarantee a wide, engaging preview, with core OG tags serving as fallback.
• Use platform-specific debuggers to verify your tags render properly and force re-scrapes to update cached previews quickly.
• Inject OG tags server-side in static or server-rendered sites to ensure social crawlers see complete metadata, avoiding broken or missing previews.

Table of Contents

• Essential Open Graph tags and a minimal example
• Image and media best practice for social previews
• Platform-specific notes and Twitter/X card fallbacks
• Testing, debugging and validator tools
• Implementation techniques for modern sites and CMS
• Caching, updates and common pitfalls
• Quick checklist and copyable templates
• How we handle Open Graph tags for small business clients
• Want this sorted without touching a line of code?
• FAQ
• Sources

Essential Open Graph tags and a minimal example

The Open Graph protocol names four tags as essential for every page: og:title, og:type, og:image and og:url. og:description sits alongside them as strongly recommended, and in practice you’ll want it on every page too, since most platforms pull it straight into the preview text.

Here’s a minimal block for a landing page:

• <meta property="og:title" content="Your Page Title" />
• <meta property="og:description" content="A clear one-line summary of the page." />
• <meta property="og:image" content="https://example.com/preview.jpg" />
• <meta property="og:url" content="https://example.com/page" />
• <meta property="og:type" content="website" />

For an article page, swap og:type to article and add article:author and article:published_time. That single change unlocks extra fields that platforms use to credit the writer and timestamp the piece, which matters if you want LinkedIn or an AI engine to show who wrote something and when.

You can go further with structured image properties: og:image:width, og:image:height and og:image:alt. These aren’t decorative. Declaring width and height lets platforms render the preview without having to fetch the image first to measure it, which speeds up the preview and avoids layout shift on the sharer’s end. The Open Graph protocol treats these as proper sub-properties of og:image, not optional extras, so if you’re building the block from scratch, include them from day one rather than bolting them on later.

Image and media best practice for social previews

Most broken previews come down to the image, not the text. The recommended size for og:image is 1200x630 pixels for Facebook and 1200x627 pixels for LinkedIn, a near-identical 1.91:1 ratio that works safely across both platforms, according to the Open Graph protocol.

A few rules keep images working everywhere:

• Use absolute HTTPS URLs only, never relative paths, because crawlers fetch the image directly and a relative path resolves to nothing outside your own browser.
• Keep file size well under 5MB so platforms don’t time out fetching it.
• Stick to JPEG, PNG or WebP where the platform supports it, and test WebP specifically if you’re unsure.
• Set og:image:alt with a short, accurate description, both for accessibility and because AI engines increasingly read alt text as a structured signal when parsing a page.

X favours a slightly wider frame at 1200x675 for its large summary card, so if X previews matter to you, design your source image a touch wider than the Facebook standard and let the platform crop rather than stretch it. A stretched or cropped-wrong preview image does more damage to click-through than no image at all, so this is worth getting right before you worry about anything else on the page.

Platform-specific notes and Twitter/X card fallbacks

Facebook and LinkedIn read your Open Graph tags directly: no extra platform-specific markup required. Setting og:type="article" unlocks fields like article:author and article:published_time, which LinkedIn in particular surfaces in its preview card.

X works differently. It reads twitter:* tags first, but falls back to og:title, og:description and og:image when those platform-specific tags are missing. The one exception is twitter:card, which has no Open Graph fallback at all and controls the layout itself.

• Without twitter:card, X defaults to a small square thumbnail instead of the wide image you’ve carefully sized.
• Add twitter:card="summary_large_image" whenever you want the full-width preview on X.
• Keep the core OG block clean and complete first; treat twitter:card as a one-line addition on top, not a separate system to maintain.

That order matters: build the robust fallback chain first, then layer platform-specific control where you actually need it.

Testing, debugging and validator tools

Never assume your tags work just because they’re in the HTML. Test them properly before you share a link anywhere that matters.

1. Paste your URL into a debugger and inspect the raw OG values it extracts.
2. Check the image renders, the title and description match what you intended, and nothing is truncated.
3. Force a re-scrape if the tool shows stale data from a previous version of the page.
4. Fix any flagged errors, commonly relative image URLs or images blocked by robots.txt.

Your main tools here are the Facebook Sharing Debugger and the LinkedIn Post Inspector, both of which show the raw OG tags and the last time the platform scraped your page. For X, a handful of third-party validators fill the gap left by X’s own tooling. The Foglift OG debugger fetches a page server-side and shows how it will appear across Facebook, X, LinkedIn and Slack in one pass, which is handy when you’re checking several platforms at once rather than running each debugger separately.

AI search engines read the same metadata. A server that returns a complete OG block on first fetch, rather than relying on JavaScript to inject it afterwards, gives these tools something solid to parse and cite.

Implementation techniques for modern sites and CMS

Social crawlers and most AI engines don’t execute JavaScript. If your framework injects meta tags client-side after the page loads, as many single-page apps do by default, crawlers never see them. They fetch the raw HTML response and move on, and your preview ends up blank or pulls from whatever fallback the platform guesses at.

• On WordPress, an SEO plugin typically exposes OG fields directly in the page editor, which get rendered server-side with the rest of the page.
• Static site generators bake the tags into the HTML at build time, so there’s nothing left to render client-side.
• For a custom server-rendered app, set the tags in server middleware so they’re present before the response ever reaches the browser.
• For a Vue or React single-page app, use SSR or pre-rendering specifically for the routes that get shared, even if the rest of the app stays client-rendered.

A minimal server-side pattern looks like this: the server receives the request, pulls the page’s title, description and image from your data source, and injects them into the HTML template before sending the response, so the OG block is already sitting in the markup the crawler receives.

Pro Tip: Always set a canonical URL alongside og:url, matching exactly, so platforms and search engines agree on which version of the page is the real one.

Caching, updates and common pitfalls

Platforms cache your OG data, sometimes for days, which is why an updated title or image doesn’t show up immediately when you reshare a link. Use the Facebook Sharing Debugger or LinkedIn Post Inspector to force a re-scrape, or add a harmless query parameter to the URL to bypass the cache entirely.

• Relative image URLs: the most common reason previews break; always use the full https:// path.
• Images blocked in robots.txt: the crawler can fetch the page but not the image it’s meant to display.
• Oversized images that time out before the platform finishes fetching them.
• Missing og:tags altogether, leaving the platform to guess from whatever text it finds on the page.

Update article:published_time when you genuinely republish or substantially revise a piece, not on every minor edit.

Quick checklist and copyable templates

1. Add the five core tags: og:title, og:description, og:image, og:url, og:type.
2. Use an absolute HTTPS image URL, sized 1200x630.
3. Confirm the tags render in the server response, not injected by JavaScript.
4. Test with a debugger and force a re-scrape.
5. Check image file size and add og:image:alt.

How we handle Open Graph tags for small business clients

Every site we build ships with the core OG tags set server-side, not bolted on after launch, because that’s the only version that actually renders for crawlers. Hosting, testing with a debugger, and a re-scrape before go-live are standard, alongside AI search optimisation and SEO baked into our build process. If you want a second pair of eyes on your current setup, we’re happy to take a quick look.

— Rhys

Want this sorted without touching a line of code?

Most small business owners don’t want to learn the difference between og:image:width and a cache-busting query string, and fair enough. We build sites with the full Open Graph block, managed UK hosting, SSL and AI search training included from the start, with transparent monthly pricing and no chunky agency invoice waiting at the end. Website Sale! plans run from £10 a month, with no hidden charges and no upfront fee, and that covers everything from a pay monthly website design for sole traders to a plumber website design package built to actually convert quote requests on mobile.

Whether you’re after a simple website for a sole trader, a landing page that works as a checkatrade alternative, or just a mobile friendly quote page for trades that doesn’t fall over on a phone, we build it properly the first time: server-rendered, tagged correctly, and tested before it goes live. Check our packages and get started and we’ll have your site live in 5 to 7 working days.

FAQ

What are Open Graph tags?

Open Graph tags are HTML meta tags that control how a web page appears when shared on social platforms, including the title, description, image and URL shown in the preview card. They were defined by the Open Graph protocol and are now read by Facebook, LinkedIn, X and various AI search tools.

How do I check my Open Graph tags?

Paste your page URL into the Facebook Sharing Debugger or the LinkedIn Post Inspector to see the raw tags each platform has extracted, including the title, description and image. If the preview looks stale or wrong, use the same tool to force a re-scrape rather than waiting for the cache to clear on its own.

What are Facebook Open Graph tags?

Facebook reads the standard Open Graph tags directly, meaning og:title, og:description, og:image and og:url with og:type set to website or article depending on the content. No Facebook-specific markup is needed beyond what the Open Graph protocol already defines.

How do I add Open Graph meta tags to my site?

Place the tags inside the <head> of your HTML, and make sure they’re present in the server response rather than added by client-side JavaScript, since social crawlers don’t run scripts. On WordPress an SEO plugin usually exposes the fields directly, while custom-built sites need the tags set in server-side templates or middleware.

Sources

• The Open Graph protocol
• Open Graph and Twitter Card tags explained (Uberflip)

Recommended

• Website Build, AI Training, SEO & UK Hosting
• Why Cheap Website Development Fails (And What To Buy Instead)
• Website Examples & Templates