Use case

Changelog Open Graph images

Changelog pages need repeatable, branded preview cards for every release. Use brand, gradient, or minimal templates with release titles and short summaries so every product update has a shareable image.

Add the generated URL to og:image and twitter:image so search previews, social networks, chat apps, and LLM browsing tools see a consistent branded card.

Why page-specific preview images matter

Search results, social feeds, chat apps, and AI browsing surfaces all compress a page into a few visible signals: title, description, URL, and image. A static homepage card wastes that surface area on specific URLs. Dynamic Open Graph images let each blog post, release note, product page, or docs guide show the exact headline and context a visitor expects before the click.

The operational pattern

Keep the template choice boring and repeatable. Store the page title, subtitle, author, price, or release name in your CMS or database, build an OGKit URL on the server, and emit the final HTTPS image in both og:image and twitter:image. The image URL becomes part of the page contract, just like the canonical URL and meta description.

How to avoid stale previews

Unfurlers cache image URLs aggressively. If a title or product visual changes materially, version the query string, update the signed URL, or force a rescrape with platform validators. Deterministic URLs are good for cache hit rate, but content teams still need a refresh habit after important launches and edits.

Recommended OGKit template

Start with the gradient template. It keeps the request predictable while still giving each changelog page its own image, headline, and visual context.

title

Use this query field when building the image URL server-side.

subtitle

Use this query field when building the image URL server-side.

accent

Use this query field when building the image URL server-side.

pattern

Use this query field when building the image URL server-side.

Copy-paste example

This pattern works in any framework that can output metadata. Keep the key in server-side code, then place the final HTTPS URL in both Open Graph and Twitter metadata. Use the API docs for all template fields, test copy in the Playground, and read the Open Graph SEO guide before wiring production pages.

const image = new URL("https://www.webmorp.art/api/og/gradient");
image.searchParams.set("key", process.env.OGKIT_KEY!);
image.searchParams.set("title", "Changelog v2.4");
image.searchParams.set("subtitle", "New templates, signed URLs, and faster previews");

export const metadata = {
  title: { absolute: "Page title — OGKit" },
  openGraph: { images: [image.toString()] },
  twitter: { card: "summary_large_image", images: [image.toString()] }
};

Common mistakes

Using internal release names as public titles
Writing summaries that are too long for link previews
Not giving each release a unique image

When to use dynamic images

Use dynamic images when every page has a different title, release, product, guide, or author. Static social cards are fine for a homepage, but they waste clicks when shared links point to specific content.

Related implementation pages

Next.js guide API reference Preview validators Dynamic preview guide

Frequently asked questions

What is the best OGKit template for changelog pages?

Start with the gradient template and pass title, subtitle, accent, pattern as query fields when building the image URL.

Should I generate Open Graph images dynamically or use one static card?

Use dynamic images when each page has a different title, product, release, author, or summary. Static cards are fine for homepages but weak for specific shared links.

Where should I place the generated image URL?

Use the final HTTPS image URL in both og:image and twitter:image metadata so social networks, chat apps, and search previews show the same branded card.

OGKit turns one HTTPS URL into a 1200×630 Open Graph image. Read the API reference, the Open Graph SEO guide, try the Playground, or sign in to create API keys.