Open Graph image SEO: size, Next.js metadata, Google thumbnails & LLM crawlers

Open Graph (OG) and Twitter/X card metadata control how your URLs look when shared in Slack, Discord, LinkedIn, iMessage, and search-driven discovery. A strong setup uses one canonical HTTPS image per URL, stable 1200×630 dimensions, readable typography at thumbnail size, and titles that still make sense when truncated.

Hosted template APIs like OGKit trade maximum layout freedom for operational simplicity: you pass title, subtitle, logo, and product fields as query parameters instead of maintaining Satori JSX, headless Chrome, or design-tool pipelines yourself. For Next.js teams, the usual integration point is generateMetadata on the server, which keeps secrets out of the client bundle.

Skim the rest of this guide for internal links to the HTTP reference, pricing, the live Playground, the dynamic previews use-case page, and the Next.js-specific framework guide—then ship a first preview URL in minutes using demo mode.

Social networks and messengers increasingly behave like secondary search engines: the image, title, and description decide whether someone opens your tab or keeps scrolling. Even when rankings are stable, a weak preview lowers click-through from the same position because humans compare adjacent cards in the feed.

From an SEO lens, previews reinforce topical relevance. When your article title, hero art, and meta description align with the query intent, you reduce pogo-sticking after the click. That alignment is easier when the preview image is generated from the same structured data you already store for the page—release name, price, author, or doc section—rather than a single static marketing banner reused everywhere.

Latency and caching matter too. Crawlers and unfurlers fetch og:image as a separate HTTP resource. Deterministic URLs that include only stable fields (or a signed hash of them) help CDNs cache aggressively, which keeps Slack and LinkedIn rescrapes fast when a link is reshared weeks later.

At the HTML layer you typically emit og:title, og:description, og:image, og:image:width, og:image:height, twitter:card, and twitter:image alongside your canonical link element. Width and height help clients reserve aspect ratio before the PNG finishes downloading, which avoids layout jump in some in-app browsers.

Absolute HTTPS URLs are non-negotiable: relative og:image paths break in aggregators that resolve against the wrong host, and http URLs fail mixed-content expectations on modern clients. If your app is mounted under a path prefix, bake that prefix into outbound marketing links so canonicals, sitemaps, and image URLs stay consistent.

When you evaluate vendors, ask how they handle cache headers, signed URLs for public endpoints, and per-plan quotas. Those operational details matter more than pixel-perfect gradients once you are rendering thousands of cards per month across blogs, changelogs, and programmatic landing pages.

The App Router encourages colocating SEO with routes via the metadata API. Build your preview image URL in generateMetadata or a small server-only helper, assign it to openGraph.images and twitter.images, and never import API secrets into client components. That single rule prevents an entire class of security regressions when someone later refactors a page to a client boundary.

If you compare maintaining opengraph-image.tsx with a hosted OG API, the trade-off is control versus toil. Custom routes shine when every page needs bespoke JSX. Template APIs shine when product, growth, and docs teams want predictable cards without waiting on a frontend deploy for every copy tweak.

For a focused walkthrough with pitfalls and snippets, read the OGKit Next.js framework page linked below; it mirrors what we document in the HTTP API reference and pairs well with the comparison articles when you are choosing between hosted templates and in-repo Satori.

SaaS marketing sites benefit from brand-forward cards: logo, short tagline, and a restrained accent color so the preview still reads when Slack shrinks it. Documentation sites often prefer code-forward or minimal templates so the page title and section name carry the signal. Ecommerce share cards should show price and product photography where policy allows, because those fields answer the first shopper question before the click.

Changelog and release-note URLs are easy to neglect: teams reuse the homepage OG image and wonder why engagement is flat. A simple pattern is one card per release with the version in the title and two lines of summary text. That small habit compounds when power users subscribe to RSS or social mirrors of your feed.

Internal education matters: link writers should know that editing page copy without regenerating the OG URL can leave stale previews until caches expire. Either version your query string when content changes materially or rely on a signing scheme that rotates when the underlying record updates.

Using client-side-only metadata updates is the classic SPA pitfall: crawlers and most unfurlers do not execute your JavaScript bundle. Anything that matters for distribution must be present in the first HTML response.

Another failure mode is gigantic custom fonts or unbounded text: preview renderers enforce tight timeouts. Template systems that cap line counts and font file sizes behave more predictably than unconstrained screenshot browsers on cold start.

Finally, mixing testing and production keys in the same environment variables creates incidents. Keep demo mode for design reviews, signed URLs when exposing generation to the public internet, and domain allowlists when a single key must serve multiple properties.

Use official debugger tools and your own staging fetches: curl the page HTML, extract og:image, then curl the image URL and inspect content-type, cache-control, and total bytes. Large PNGs are fine at 1200×630 if compression is tuned; runaway megabytes suggest a misconfigured screenshot pipeline or lossless assets that should be quantized.

Watch referral quality from social and community sites after you ship dynamic previews. You should see higher session depth when cards match destination content because visitors arrive with accurate expectations.

When you are ready to automate generation in production, start with the HTTP docs, validate keys in the dashboard, and keep llms.txt in sync so coding agents pick up canonical examples without inventing hosts.

One primary H1 on the destination page, supporting H2/H3 sections, and metadata titles that do not fight the visible headline.

One OG image URL per canonical URL, absolute HTTPS, width and height meta, twitter:image mirroring og:image unless you intentionally diverge.

Quotas, signing, and key rotation documented for whoever operates billing—not only the engineer who wired the first prototype.

The consensus dimension across Open Graph scrapers is 1200×630 pixels at a 1.91:1 ratio. LinkedIn and Twitter/X render large cards at approximately that ratio; Slack and iMessage sometimes crop narrower on small viewports. Keep a 64 px safe margin on all sides and avoid pinning meaningful text within the outer 10 percent of the canvas so nothing important is clipped when clients crop to a square thumbnail in notifications or mobile previews.

Font size matters more than layout cleverness. A 72–96 px headline holds up across desktop feeds, mobile browsers, and shrunk Slack thumbnails; anything under 48 px starts to blur below 400 px rendering width. Limit headlines to two lines and use a conservative line-height so rogue long titles do not overflow into logo zones or clip the author byline. When a template offers a "dark" theme, ensure body text clears WCAG AA contrast against the darkest background patch, not just the average.

PNG is the default output format because every major scraper decodes it losslessly and sizes stay below a few hundred kilobytes with modern palette optimization. Avoid JPEG for text-heavy cards — chromatic compression artifacts show up first on sharp letterforms and logos. WebP and AVIF are faster but not universally supported in older unfurlers, so they should remain an option, not a default.

Google and Bing are no longer the only audiences for Open Graph metadata. Perplexity, ChatGPT browsing, Claude and Gemini retrieval pipelines, Cursor Docs, and other AI systems fetch HTML and extract structured data (Open Graph, Twitter cards, schema.org JSON-LD) to build citations and previews. If your og:image is a generic brand splash and your schema.org block is missing, the AI surface shows a weaker card than a competitor who spent a day on metadata — and AI users rarely scroll deeper in the result set.

A robust setup gives AI crawlers three layers: a canonical HTTPS og:image (1200×630), a schema.org Article or TechArticle node with headline and description, and a text-based companion file at /llms.txt that summarizes the site in machine-readable form. Each layer reinforces the others: the image gives the UI, the JSON-LD gives the semantic summary, and the llms.txt gives crawlers a deterministic index to choose which URL to cite. OGKit already ships an llms.txt route — inspect it, extend it, and keep canonical URLs aligned with your sitemap.

Operationally, this means your preview system is part of the retrieval pipeline, not just a social-share nicety. Treat og:image generation as deterministic infrastructure — stable URLs, short cache TTLs for content edits, and signed keys for public pages — so AI ranking models see the same card a human would. The same discipline that wins Google rich results increasingly wins AI citation placement.

When a preview refuses to update, the problem is almost always caching. Facebook, LinkedIn, and Slack aggressively remember the first og:image they fetched for a URL; editing the image without a cache-busting query string or a forced rescrape leaves the old card live for days. Run the Facebook Sharing Debugger, LinkedIn Post Inspector, and Twitter Card Validator after every material change to force a refresh, and consider versioning the image URL with a short content hash so CDNs see a new resource automatically.

When a preview renders but looks broken (cropped text, missing logo, wrong colors), inspect two things. First, view the og:image URL directly in a browser and confirm the PNG itself is correct at full 1200×630. If the PNG is fine, the issue is with the consuming client — LinkedIn, for example, applies its own recompression and can darken thin text. Second, check that og:image:width and og:image:height meta tags match the served PNG, because some scrapers use those hints to skip aspect-ratio guessing.

When the preview is simply missing, the usual culprits are a relative og:image URL, a missing Content-Type, a 4xx from the image host, or a CSP/CORP header that blocks external fetch. A final check: inspect the raw HTML of the page with curl — not a rendered view in DevTools — to confirm the metadata ships in the first response. Many SPA bugs disappear only after a server-side render is configured; otherwise the metadata lives only in client JavaScript that scrapers never execute.