You finish a post, hit publish, and the CMS does its job. The page is live, the URL works, the sitemap updates. Then you paste the link into X to share it, and the preview card comes up blank or grabs some random image from the page. The share image that was supposed to sell the click doesn't exist yet, because making it is still a manual step nobody automated.
That gap between "published" and "actually shareable" is small and constant. Every post reopens it. The fix isn't remembering to make the image faster; it's arranging things so the image already exists the moment the post goes live.
💡 The one-sentence version: The OG image shouldn't be a task you do after publishing. It should be a render that fires on publish, from a template you designed once.
The gap between "publish" and "posted"
The Open Graph image is the 1200x630 card that shows up when your link is shared on X, LinkedIn, Slack, or iMessage. It's the first thing a scroller sees, usually before the headline. A post with a blank or mismatched card looks unfinished, and it competes for attention against every post that got its card right.
Why it keeps getting skipped
The image is the last step in a publishing flow that already feels done. The writing is finished, the page renders, the analytics fire. Opening a design tool to build one more asset, at the exact moment you want to move on, is the kind of task that slips. Do it for one post and it's a minor chore. Do it for every post, on a blog that publishes weekly, and you've signed up for a small recurring tax with no end date.
What "already made" would look like
Picture the same flow with the image handled. You hit publish, a render fires in the background from a card you designed once, the finished PNG lands in storage, and its URL is written back into the post's og:image before anyone shares the link. You did nothing. The card is on-brand because the template was locked to your brand months ago, and it matches the last hundred cards because it structurally is the same template with different text.
Why the usual fixes don't hold
Most teams reach for one of two workarounds, and both leak.
Making it by hand
The manual route means a designer or, more often, the writer opens Canva or Figma per post, retypes the title, exports a PNG, and uploads it. It works until volume shows up. The cards drift as different people rebuild them, the brand slips a little each time, and the step gets skipped entirely on busy weeks. It's the human copy-paste machine problem: you're not designing, you're re-entering the same data into the same layout and exporting one file at a time.
Handing it to an AI image generator
The other reflex is to have a model dream up an image per post. It's fast and it's novel, and it's wrong for this job. A generated image is different every time, rarely on-brand, and priced per image, so a blog with an archive turns into a running bill. Worse, you can't trust that render number 400 will look anything like render number one, which is the entire point of a share card.
| Approach | How it goes |
|---|---|
| By hand (Canva/Figma) | Slow, one at a time. Drifts off-brand. Skipped on busy weeks. Won't scale. |
| AI image generator | Fast but off-brand. Different every render. Pay per image. Unpredictable at volume. |
| Curated template + data | Instant. Locked to your brand. Identical every time. No designer, no per-image fee. |
⚠️ The consistency test: if you can't guarantee the card you render next month looks like the one you rendered today, you don't have a system. You have a slot machine.
The pattern: template plus data, fired by a webhook
The durable version of this is boring in the best way. You design one OG template, lock it to your brand, and wire your CMS so that publishing a post hands that template the post's data and gets back a finished image. No render-time decisions, no design tool in the loop.
What runs when you hit publish
The flow has four moves. Your CMS fires a webhook when a post is published. A small handler reads the post's title, author, and any tag or category you want on the card. It calls a render with the template and that data, and gets back an image URL. It writes that URL into the post's og:image field through the CMS API. The reader who shares your link ten minutes later never knows any of it happened.
Where the image comes from
This is where a curated template engine like Lemtika fits. You design the OG card once in Lemtika, lock it to your brand kit, and expose it as a render target. The webhook handler passes in the post data, and Lemtika returns a deterministic 1200x630 PNG that matches every card before it. Same template, same brand, same output shape every run. The render path has no model guessing and no design step, so the result is predictable in the way a share card has to be.
📋 The four moving parts: a locked OG template, a publish webhook from your CMS, a render call that turns post data into an image URL, and a write-back into
og:image. Set once, runs forever.
Three ways to wire it up
The right surface depends on how much code you want to own. Lemtika exposes the same render three ways.
The API call, for developers
If you run your own backend or a framework like Next.js, the handler is a few lines. On the publish event, you POST the template and the post's fields to Lemtika's render endpoint and get back an image URL to store. Conceptually it's this shape:
POST /render
{ "template": "og-card", "data": { "title": post.title, "author": post.author } }
→ { "image_url": "https://.../og/your-post.png" }
One call in, one URL back. You decide whether to cache it, push it to your own CDN, or write it straight into the post record.
The no-code trigger, for marketers
No backend required. A Zapier or Make scenario listens for "new published post" from WordPress, Webflow, Ghost, or a headless CMS, passes the fields into a Lemtika render step, and drops the returned URL back into the post's SEO image field. It's the same four moves, assembled by dragging boxes instead of writing a handler.
Let the agent do it, over MCP
If an AI agent already drafts or schedules your posts, Lemtika runs as an MCP server, so the agent can render the card itself as part of publishing. No glue code between the writing step and the image step. The agent reads the title it just wrote, calls the Lemtika tool, and hands back a finished on-brand card in the same run.
*Photo by Terrillo Walls on *Unsplash
Whichever surface you pick, the result is the same: the share card stops being a thing you remember to make and becomes a byproduct of publishing.
FAQ
Can't I just let my framework generate the OG image?
You can, and for a solo project that's fine. The tradeoff is that your card design now lives in code, so changing the look means a deploy, and matching it across several sites or a client's brand gets fiddly. A locked template keeps the design separate from the pipeline, so anyone can update the card without touching the render.
Does the image regenerate if I edit the post later?
Only if you want it to. Because the render is deterministic, firing it again on an update produces the same card unless the underlying data changed. Wire it to the update event too, and an edited title quietly re-renders; leave it on publish only, and the original card stays put.
What about posts that already exist?
Run them as a batch. Export your published posts to a CSV, point Lemtika at the template, and every row comes back as a finished card in one pass. You backfill the whole archive once, then let the webhook handle everything new.
Will the cards actually stay on-brand?
That's the reason to use a locked template instead of a generator. The colors, font, and logo are fixed to your brand kit, so the only thing that changes between cards is the text you pass in. Render one or render a thousand, they belong to the same set.
Do I need to be a developer to set this up?
No. The API path is for teams that want to own the code, but the Zapier or Make route wires the same flow with no backend, and the MCP path hands it to an agent. Pick the surface that matches your stack.
How is this priced?
Lemtika is a lifetime deal, pre-launch: you pay once and own it, with no per-image fee and no monthly bill. That matters for OG images specifically, because the whole point is rendering a card for every post you'll ever publish without a meter running.
Design your OG card once, wire it to your publish event, and let every future post ship with its share image already made. You can start from a template in Lemtika, call it from your backend, or hand it to an agent over MCP, whichever fits how you publish.