Programmatic OG Image Generation for Marketplaces and Listings

A marketplace, real estate site, or job board doesn't have a few dozen pages that occasionally need a new OG image — it has thousands of listings, most of them created by someone other than the marketing team, many of them created automatically, and a constant churn of new ones going live and old ones expiring. Programmatic og image generation is the only workflow that actually fits that shape: there's no version of "a designer makes an image per listing" that survives contact with a catalog that size.

Why listings are a different problem than blog posts

A blog has editorial control over every page — someone decides to publish it, reviews it, and could in principle spend a few minutes on its social preview. A marketplace listing is usually created by a user, a seller, or an automated feed import, often without anyone from the platform ever looking at that specific page before it goes live. That changes the requirements substantially: the OG image has to be generated the moment the listing exists, from data that's already structured (price, title, primary photo, location, category), without a human in the loop at all. It also has to handle listings that are incomplete, inconsistent, or entered by users who didn't follow any particular formatting convention — a robust template needs sensible fallbacks for missing fields, not just a happy path.

What a listing template actually needs

• A primary image slot that gracefully handles a missing, broken, or oddly-cropped source photo, since listing photos come from users and vary wildly in quality and aspect ratio.
• Price and title formatting that reads correctly regardless of currency, length, or whether a discount is present — a template that only looks right for one price format will look broken on a meaningful share of real listings.
• A category or type indicator, so a browsing listing and a real estate listing don't look identical if a platform spans multiple listing types.
• A consistent brand element (logo, color, layout) so previews are recognizable as belonging to your platform even when the underlying photo varies completely from listing to listing.

The generation trigger: on-demand vs. at creation time

There are two reasonable points to generate a listing's OG image, and the right choice depends on traffic patterns. Generating at listing-creation time means the image exists and is cached before anyone ever shares the link, so the first share is as fast as the millionth. Generating on-demand, the first time a crawler or user actually requests the image, defers the work until it's needed — which saves render volume on listings that are created but never shared, at the cost of a marginally slower first request. For a marketplace where most listings do eventually get shared or at least crawled by search engines, generating at creation time is usually simpler to reason about; for one where the vast majority of listings never get a single share, on-demand generation avoids paying for renders nobody will see.

Versioning matters more here, not less

It's tempting to think versioned, immutable render URLs matter less for listings, since listings themselves are often temporary — a job posting expires, a rental gets rented. In practice it matters just as much, for a different reason: listings routinely get edited after creation (price drops, updated photos, corrected details), and a listing's OG image needs to reflect the current state without breaking links that were shared before the edit, and without regenerating and re-caching an image on every minor field change. Immutable, versioned render URLs handle this cleanly — an edit that meaningfully changes the listing's preview creates a new version, while a listing's already-shared links keep pointing at whatever was accurate when they were shared.

Handling scale without handling it yourself

The operational risk with programmatic generation at marketplace scale isn't the rendering logic itself — it's everything around it: making sure a burst of new listings (a feed import, a seasonal spike) doesn't overwhelm a render pipeline, making sure a CDN is actually caching rendered images instead of re-rendering on every crawler hit, and making sure a bad template change doesn't silently break OG images across the entire catalog at once. Building and operating that infrastructure yourself is a real engineering commitment, not a side project — which is exactly the case for using an API built to already handle it rather than replicating it in-house.

Backfilling an existing catalog

Most marketplaces adopting programmatic generation aren't starting from zero — they already have thousands of existing listings with no OG image, a generic fallback, or a stale one. A backfill script that loops over existing listing data and calls the render API for each one, using fields already in the database, can bring an entire existing catalog up to date without touching the listing pages themselves — the meta tag just needs to point at the newly generated, versioned URL.

Handling listing removal and expiration

Marketplaces have a churn pattern most content sites don't: listings get sold, rented, filled, or expire and disappear from the live site entirely, often within days or weeks of being created. That raises a question a blog-focused OG image setup rarely has to answer — what should happen to a render URL for a listing that no longer exists? Because rendered images are just data derived from a template plus a set of values, they can keep resolving even after the underlying listing is gone, which is usually the right behavior: someone who shared a listing before it sold should still see the preview that was accurate when they shared it, even though clicking through now shows an "unavailable" state on the actual page. The image staying stable and the page's live state changing independently is a feature of decoupling the render from the listing's current status, not a bug to work around.

Localization across regions

Marketplaces operating across multiple countries or languages add another wrinkle: the same listing template needs to render correctly with different currencies, different date formats, and sometimes entirely different scripts, depending on where a listing is being viewed from. A template system that treats currency and locale as just more variables — rather than requiring a separate hand-built template per region — avoids multiplying maintenance work by the number of markets a platform operates in. This is one more reason a rigid, code-owned template tends to become a liability at marketplace scale: every new region shouldn't mean a new deploy.

How useopengraph fits a marketplace's needs

useopengraph's REST API and template system are built for exactly this pattern: a listing template is designed once with variables for the fields that actually vary — price, title, primary photo, category — and every listing render is then a single API call passing that listing's data. Renders are served from versioned, immutable URLs at /api/render/{templateId}/v{version}/..., cached aggressively at the CDN layer, so a marketplace generating renders for thousands of listings isn't paying the cost of re-rendering on every request, and a template redesign never breaks a listing link that's already circulating. The same API is reachable through useopengraph's MCP server as well, so triggering a batch of renders — during a migration, a backfill, or a bulk import — can be done conversationally by an agent instead of a bespoke script.