Visit Website →
← Back to blog

Fix Link Previews, Developers: Open Graph and Twitter Cards with Next.js

October 4, 2026
Fix Link Previews, Developers: Open Graph and Twitter Cards with Next.js

Implement Open Graph plus the basic Twitter Card tags in your page head, and provide a correctly sized og:image. That alone makes link previews render reliably across platforms. The rest of this guide covers the required properties, image specs, framework-specific code, and the validator tools you use to confirm it actually worked before you ship.

TL;DR:

  • Most social platforms cache previews, so changes to images or text may not appear immediately without re-scraping.
  • Implementing the four mandatory Open Graph properties ensures consistent link previews across platforms and reduces fallback issues.
  • Using a 1200 by 630 pixel image for Open Graph and Twitter Cards helps prevent rendering problems and maintains visual quality.
  • Twitter prefers the summary_large_image card type for maximum visual impact, with twitter:image falling back to og:image if absent.
  • Client-side rendering of meta tags causes social previews to break, so server-side or static generation is essential for accurate previews.
Forge-web-studio
Make Your Website Work Harder
Forge Web Studio builds strategy-led websites with mobile clarity, effective lead flow, and local search optimization for Texas businesses.
Visit Forge Web Studio

Table of Contents

What Open Graph and Twitter Card tags actually control

Open Graph and Twitter Card tags are both meta tags that live in your page's head. They tell social platforms what title, description, and image to show when someone pastes your URL into a post. Without them, a platform falls back to whatever it can scrape from your page, usually the <title> tag and a stray paragraph of body text, which rarely looks good.

Most platforms, including Facebook, LinkedIn, and Slack, read Open Graph tags first and fall back to standard meta description or title tags only when OG data is missing. X (formerly Twitter) reads its own twitter: tags but will fall back to Open Graph properties when a Twitter-specific tag is absent, which is why most sites implement OG as the foundation and layer Twitter tags on top.

A few practical points worth knowing before you touch any code:

  • Open Graph is the broader standard, adopted by Facebook, LinkedIn, Slack, Discord, and most chat and social apps.
  • Twitter Card tags are specific to X and only affect how links render there.
  • X checks for twitter: tags first and uses og: tags as a backup, so a site with only Open Graph tags still gets a usable preview on X.
  • Platforms cache the metadata they scrape, so a changed image or title will not update until the platform re-scrapes the page.

The practical rule of thumb: implement Open Graph everywhere, then add the handful of Twitter-specific tags if you care about how links look specifically on X, such as controlling whether an image displays large or small.

Required Open Graph properties and a copy-ready example

The Open Graph protocol specifies four mandatory properties for every page: og:title, og:type, og:image, and og:url. These belong inside the <head> element, alongside your existing meta tags, not in the body and not injected after the page loads.

  • og:title: the headline shown in the preview card, often shorter than your SEO title tag.
  • og:type: usually website for most pages, or article for blog posts and news content.
  • og:image: the absolute URL to the preview image, not a relative path.
  • og:url: the canonical URL for the page, which should match your <link rel="canonical"> tag to avoid sending mixed signals to crawlers.

Beyond the required four, a handful of optional properties meaningfully improve how previews render. The same Open Graph specification lists og:image:width and og:image:height as ways to help platforms render the image immediately instead of waiting to measure it, and og:image:alt as the accessible description for users relying on screen readers. Adding og:description and og:locale rounds out the picture, giving platforms a short summary and a language signal.

Here is a minimal, copy-ready example:

<meta property="og:title" content="Your Page Title" />
<meta property="og:type" content="website" />
<meta property="og:image" content="https://example.com/images/preview.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Short description of the image" />
<meta property="og:url" content="https://example.com/page" />
<meta property="og:description" content="One or two sentences summarizing the page." />
<meta property="og:locale" content="en_US" />

Keep og:url and your canonical tag pointing at the same address. When they disagree, you risk platforms indexing or caching a preview tied to the wrong URL, which gets confusing fast on sites with query parameters or tracking codes.

Pro Tip: Write og:title and og:description as their own short strings instead of reusing your SEO title and meta description verbatim; the ideal length and tone for a social card is often different from what ranks well in search.

Twitter Card tags: types, essentials, and image rules

X supports several card types, and picking the right one changes how much visual space your link preview gets. According to guidance on Twitter Card markup, the main types are:

  • summary: a small thumbnail next to title and description, best for text-heavy pages.
  • summary_large_image: a full-width image above the title, the standard choice for blog posts and marketing pages.
  • app: promotes a mobile app with install links, used by app developers.
  • player: embeds video or audio directly in the card, used by media publishers.

For most sites, summary_large_image is the default worth reaching for since it gives the image the most visual weight in the feed.

The essential tags to include are twitter:card (one of the types above), twitter:title, twitter:description, and twitter:image. If your site or the author has a verified X handle, twitter:site and twitter:creator add attribution, though they are optional rather than required for the card to render.

Image handling on X overlaps heavily with Open Graph but has its own limits. The same Twitter Card guidance notes that validators exist specifically to confirm card rendering, which matters because X enforces its own file-size ceiling separately from whatever your OG image settings specify. When twitter:image is missing, X falls back to og:image automatically, so sites that only implement Open Graph still get a usable, if less controlled, preview.

Image best practices for Open Graph and Twitter cards

Image specs are where most previews break. Platforms generally render Open Graph images best at 1200 by 630 pixels, a roughly 1.91:1 aspect ratio that matches the wide card format used across Facebook, LinkedIn, and Slack. For square previews or app cards, 1200 by 1200 pixels is the safer default. Because scrapers and cards often display at smaller sizes on mobile, starting with a slightly oversized source image and letting the platform scale it down produces sharper results than scaling up a small original.

The Open Graph protocol specifies image width and height as optional properties that help platforms render previews without measuring the file first, which shortens the delay between a link being pasted and a preview appearing.

A few format and size notes worth building into your workflow:

  • Use JPEG for photographic images and PNG for graphics with text or sharp edges; WebP works on most modern crawlers but test it before relying on it exclusively.
  • Keep the file under roughly 1 megabyte where possible, both for faster scraping and to stay comfortably under platform-specific limits.
  • Always set og:image:width and og:image:height even when the image is a standard size, since some platforms skip the dimension-detection step entirely when they are present.
  • Provide og:image:alt with a short, literal description of the image, both for accessibility and as a fallback label some platforms display if the image fails to load.
  • Host a single fallback image (your logo or a branded placeholder) for pages that do not have a natural hero image, rather than leaving og:image empty.

Specifying dimensions and alt text is not cosmetic. The Open Graph specification ties both to faster, more accurate rendering and to better support for assistive technology, which is a low-effort addition with a real payoff on every page you ship. For deeper guidance on compressing and sizing images without hurting quality, see this image optimization guide, and for writing alt text that actually describes purpose rather than just keywords, see this alt text guide.

Implementing OG and Twitter Card tags in Next.js and WordPress

Next.js handles social metadata through file conventions rather than manually writing meta tags. According to the Next.js metadata documentation, you can drop a static opengraph-image.jpg or opengraph-image.png file into a route segment and Next.js will generate the correct tags automatically, no manual markup required.

  1. Place a static image file named opengraph-image (with the appropriate extension) inside the route folder for automatic tag generation.
  2. For dynamic images, such as a blog post title rendered on top of a branded background, create an opengraph-image.tsx file that uses the ImageResponse API to generate the image at request time or build time.
  3. Add a matching twitter-image file or function when you want Twitter-specific dimensions or content different from the Open Graph version.
  4. Confirm the generated images are cached appropriately. The Next.js App Router metadata guide notes that generated images are cached by default unless you explicitly use request-time APIs, which matters for pages with frequently changing content.

WordPress sites typically handle this through a plugin rather than hand-editing theme files. Plugins like Social Preview and Open Graph Tags add OG and Twitter tags automatically and expose per-post overrides, so an editor can swap the preview image on a specific post without touching code. Check three settings in particular: whether post-level overrides are enabled, what the global fallback image is set to, and whether WooCommerce product pages are pulling product images correctly rather than a generic placeholder.

Single-page applications introduce a separate problem that has nothing to do with Open Graph itself. Social preview scrapers typically do not execute JavaScript, so meta tags injected client-side after the page loads are invisible to them. If your app renders meta tags with client-side JavaScript only, previews will show blank or stale data no matter how correct your tag content is. Server-side rendering or prerendering the relevant pages is the fix, not a different tag format.

Server-rendered metadata reaching crawler

Pro Tip: If you are debugging a blank preview and the HTML looks correct in your browser's dev tools, check the raw server response (curl the URL) rather than the rendered DOM; client-side rendering often looks fine to you and invisible to a scraper.

Three tools cover most validation needs. The Facebook Sharing Debugger shows exactly what Facebook's crawler sees, including which tags it found and any image errors, and its "Scrape Again" button forces a fresh crawl when you have changed tags or images and the old preview is still showing. The X Card Validator, referenced in general Twitter Card guidance, does the same job for X specifically, rendering the card as it will actually appear in a tweet.

Reading the output matters more than running the tool. A few patterns to watch for:

  • Missing tags in the debugger output usually mean the HTML was not server-rendered or the crawler hit a robots block.
  • An image load error often points to a relative URL where an absolute one is required, or an image file that exceeds the platform's size limit.
  • A stale preview after a confirmed tag change almost always means the platform's cache has not been cleared yet, not that your code is wrong.

LinkedIn has its own post inspector with similar behavior, and several third-party previewer tools let you check multiple platforms at once, which is useful when validating a batch of pages after a site migration. Remember that CDN caching can also serve an old version of your HTML to the crawler even after you have deployed a fix, so check your CDN cache alongside the social platform's cache before assuming the code itself is broken.

Deployment checklist and common troubleshooting flow

Before shipping, confirm the basics: tags present in the server-rendered head, images reachable over HTTPS, correct image MIME types, width and height attributes set, alt text written, and nothing in robots.txt or a noindex tag blocking the crawler.

  1. Validate the raw HTML response with curl or "view source," not just the browser's rendered DOM.
  2. Run the page through the Facebook Sharing Debugger and the X Card Validator and compare the output to what you expect.
  3. Check server response codes and caching headers to confirm the page returns a 200 and isn't serving a cached, outdated version to crawlers.
  4. If the preview still looks wrong, force a re-scrape on each platform before changing any code.

The most common mistakes are injecting meta tags with client-side JavaScript only, letting og:url drift out of sync with the canonical tag, and shipping an oversized image that fails or loads too slowly for the crawler to grab in time.

Pro Tip: Keep a bookmarked checklist of your validator URLs so re-testing after a deploy takes thirty seconds instead of becoming its own task.

Forge Web Studio's approach to scalable social previews

Forge Web Studio builds Next.js sites for Texas businesses using the same file-based metadata conventions covered above, with dynamic opengraph-image generation set up once per site template so every new page or blog post inherits a correctly sized, branded preview without manual image design. That matters most for sites with dozens of service or city pages, where hand-crafting a unique image per page isn't a realistic use of a project budget.

The Ember & Oak Website Concept and the broader demo gallery show how this plays out across different industries and layouts, from restaurant sites to architecture firms. Each demo reflects the same underlying principle: get the metadata structure right once at the template level, and every page downstream benefits automatically.

Security and privacy considerations with social metadata tags

Open Graph and Twitter Card tags are public by design: anything you put in them is visible to anyone who views your page source, scrapes your site, or pastes your URL into a chat app. That makes them a poor place for anything sensitive, including internal tracking parameters, unpublished content titles, or draft page descriptions you don't want indexed early.

A more common mistake is image hosting. If your og:image URL points to a private or authenticated image path, most social crawlers can't authenticate and the preview will simply fail to load an image, since scrapers generally don't carry session cookies or login credentials. Always host preview images on a public, unauthenticated path.

Dynamic OG images generated at request time, such as those built with Next.js's ImageResponse API, deserve a second look if they pull any data from the URL itself, like a query parameter reflected into the rendered image text. Treat that data the way you'd treat any other user input: validate and sanitize it before it reaches the image generation step, since an unvalidated parameter rendered directly into an image or page is still an injection risk, even if the output is a picture rather than HTML.

When to automate OG images versus design them by hand

Hand-crafted images earn their cost on evergreen pillar content and campaign landing pages, where one strong image gets shared for months. Automated generation wins everywhere else, blog posts, product pages, city or service pages, because consistency at scale beats a slightly nicer image nobody has time to make for page 400. Have a designer set the template once, let engineering wire up the data, and check click-through on shared links before investing further design time.

— Dylan

How Forge Web Studio handles OG and Twitter Card setup for your site

If your current site has no Open Graph tags, broken previews, or a generic placeholder image on every shared link, that's a fixable gap, not a rebuild. Forge Web Studio builds Next.js sites with file-based metadata and dynamic OG image generation set up from the start, so every page, including new ones added later, gets a correctly sized, branded preview without manual work per page.

Forge-web-studio

Projects often include local SEO and lead-flow work beyond metadata, with clients working directly with the team and retaining ownership of their site and content. If you want a quote or a sense of scope, check the pricing page for Starter, Growth, and Custom Business Website options, or start with a new project if you already know you need a full build.

FAQ

What is a Twitter Card?

A Twitter Card is a type of metadata that controls how a link appears when shared on X, including the title, description, and image shown in the preview. It works through twitter: meta tags placed in the page head, and X falls back to Open Graph tags when a specific Twitter tag is missing.

How do you troubleshoot a broken Twitter Card?

Start by checking the raw server HTML response rather than the rendered browser DOM, since client-side-only tags are invisible to scrapers. Then run the page through the X Card Validator and the Facebook Sharing Debugger to see which tags and images the crawler actually found, and force a re-scrape if the preview is stale after a fix.

A width of 1200 pixels with a roughly 1.91:1 aspect ratio, commonly 1200 by 630 pixels, works well for the summary_large_image card type and overlaps with the standard Open Graph recommendation. Keeping the file size modest, generally under 1 megabyte, helps it load reliably within platform limits described in Twitter Card guidance.

What are OG meta tags?

OG, or Open Graph, meta tags are placed in a page's head to control the title, image, and URL shown when the page is shared on social platforms. The Open Graph protocol requires four properties on every page: og:title, og:type, og:image, and og:url.

Do Open Graph tags affect SEO rankings?

Open Graph tags don't directly influence search rankings, but they shape how a link looks when shared, which affects click-through rates and engagement when content circulates on social platforms. Search engines and social platforms read metadata differently, so OG tags support visibility and sharing rather than ranking signals directly.

Sources