Better OG images from CMS fields

When someone shares a link on LinkedIn, Slack, iMessage, or Teams, the platform fetches the page's Open Graph image to build a preview card. If every page on a site returns the same default OG image, usually a company logo on a brand-coloured background, every shared link looks identical.

That's a missed click. The preview card is the first impression. A blog post about redirects should look different from a case study about a home builder. A services page should look different from a tool page.

Most CMS setups handle OG images one of three ways. A single default image for the whole site. A manually uploaded image per page (which editors forget or skip). Or no OG image at all, which leaves the platform to guess, usually a random image from the page, or nothing.

The manual approach is what most Payload sites use, including ours currently. Each page has a meta.image field where editors can upload a custom OG image, with a site-wide default as the fallback. It works, but it creates a maintenance burden, and editors skip it more often than not.

There's a better pattern.

Next.js supports dynamic OG image generation through ImageResponse from next/og. Instead of requiring a manually uploaded image for every page, you can create a route that generates an OG image on the fly from fields already in the CMS.

The setup has three parts. A dynamic API route (something like /api/og?slug=/blog/broken-links-ci) that accepts a page slug. A Payload query inside that route that fetches the page's title, description, and content type, using select to keep the query lean. And an ImageResponse call that renders the image server-side as a PNG.

ImageResponse supports basic flexbox layout, custom fonts, and simple styling. No browser, no Puppeteer, no headless Chrome, just a function that returns pixels.

The generateMetadata function on each page template sets the openGraph.images property to point at this route with the current page's slug. When Next.js renders the page's <head>, the OG meta tags point to the dynamic image URL automatically.

OG images don't change often, they're derived from the title and description, which editors update infrequently. The route should set appropriate cache headers so the image generates once and serves from cache on subsequent requests.

If you're using Payload's cache tag system for on-demand revalidation, you can tag the OG image response with the same tag as the page. When an editor updates a page's SEO fields, the page revalidates, and the OG image revalidates with it. New content, new preview card, no manual step.

Without cache tags, a reasonable stale-while-revalidate or time-based cache header works. OG images are fetched by platforms when someone shares a link, they're not loaded by the visitor's browser when viewing the page, so a slightly stale image has no performance impact on the site itself.

A well-designed OG image setup has a fallback chain. If the editor has uploaded a custom image in the meta.image field, use that, it takes priority. If not, generate the image from the page's SEO title and description. If neither of those fields is populated, generate from the page title alone. And if all else fails, fall back to the site-wide default.

This means every page gets a preview card, even if nobody has touched the SEO fields. The generated image is better than the default, and a custom upload is better still. Editors can override when it matters, product launches, case studies, key landing pages, without being responsible for every page.