OG Image Not Showing? A Debugging Checklist (2026)

First: confirm the page has OG tags

Before you touch your design, verify the HTML that bots actually see. A lot of preview issues come from tags being present only in client-side rendered HTML (which some bots do not execute), or tags being overwritten by frameworks or templates.

Start with the OG Validator. Paste the URL and confirm you have:

• og:title
• og:description
• og:image
• og:url
• og:type

Second: confirm the og:image URL is valid

The most common hard failure is the image URL itself. Bots are picky and they do not have patience. Check these items:

1. Absolute URL: use https://example.com/og.png, not /og.png.
2. Public access: the image must load without cookies, auth headers, or VPN.
3. Fast response: if your image endpoint is slow, some scrapers time out.
4. Correct content-type: return image/png or image/jpeg.

Third: watch out for redirects

Redirects are normal on the web, but they can break previews when chained or inconsistent. Typical offenders:

• HTTP to HTTPS redirect loops
• Trailing slash canonical redirects
• Geo redirects (different content for bots vs browsers)
• Image URLs that redirect to signed CDN URLs that expire

Fix: pick one canonical URL and keep both the HTML URL and the image URL stable. If you use a CDN, use long-lived public URLs for OG images.

Fourth: caching is real (and it is the reason your fix "did nothing")

Social platforms cache preview metadata. When you change og:image, you may still see the old preview because the scraper is not re-fetching your page yet.

What to do:

• Facebook: use the Sharing Debugger to force a refresh.
• LinkedIn: use Post Inspector to re-scrape.
• Twitter/X: use the Card validator (or validate via another scraper flow).

If a platform has no official debugger, test by sharing the link in a private channel and waiting.

Fifth: check robots, firewalls, and bot blocks

You might be blocking the exact bots you want. Common causes:

• robots.txt rules that disallow major bots
• WAF rules that block non-browser user agents
• Country-based blocking
• Hotlink protection on images

Fix: allow-list social scrapers and ensure the image URL is fetchable without a browser. If your site is behind a login, host OG images on a public CDN path.

Sixth: do not rely on client-side meta tags

Some frameworks let you "set meta tags" in JavaScript after the page loads. Humans see them, but many scrapers will not. For reliable previews, render meta tags in the initial HTML response.

If you are on Next.js, follow the guide in Next.js docs or use our generator export to produce server-compatible code.

Seventh: verify size and aspect ratio

Even if the image loads, bad sizing can produce ugly results: unintended crops, blurry text, or a preview that falls back to a smaller card style.

Default recommendation: use a single 1200x630 image. For more details, read OG image size guide.

Common symptoms (and what they usually mean)

The fastest way to debug is to map what you see to the small set of real causes. Use this table as a starting point, then validate the live URL to confirm.

Check HTTP status codes and headers (HTML and image)

Scrapers are not full browsers. They do not retry forever and they do not click through interstitials. Two quick checks save a lot of time:

• HTML URL returns 200 and includes OG tags in the initial response.
• Image URL returns 200 with a real image content-type (image/png or image/jpeg).

If your image endpoint returns HTML (for example, an error page or a blocked response), scrapers will quietly ignore it and fall back to no preview or a random image.

Quick verification commands:

curl -I https://example.com/page
# Expect: 200 OK

curl -I https://example.com/og.png
# Expect: 200 OK
# Expect: Content-Type: image/png (or image/jpeg)

If you see 401/403/429 responses, you are blocking bots. If you see redirects, reduce them. If you seetext/html for the image URL, your image endpoint is not serving an image reliably.

Make the image URL boring (and stable)

The best OG image URLs look boring: static path, no auth, no expiring signatures, no redirects. If you update the image frequently, version the filename (or query string) so caches can distinguish "old image" from "new image".

Example strategies:

• Versioned path: /og/v3/home.png
• Content hash: /og/home.9f3c2a.png
• Query busting: /og/home.png?v=2026-02-12

Avoid expiring signed URLs for OG images unless you can guarantee they stay valid long enough for caches. A signed URL that expires will work for you (because you have a fresh link) but fail for scrapers that retry later.

CDNs and cache headers

CDNs can help, but they can also confuse debugging. If you have a CDN in front of your image URL:

• Make sure the CDN serves the same bytes to bots and browsers.
• Set reasonable cache headers (and purge when you update).
• Prefer immutable versioned URLs for images that change.

If you are debugging and seeing inconsistent results, try hitting the origin directly (if possible) to confirm the source of truth.

Multiple og:image tags and precedence

It is common for pages to accidentally output multiple og:image tags: a default from a layout, plus a page-level override, plus a plugin. Some scrapers pick the first image, some pick the last, and some pick "the best looking". If you see the wrong image, inspect your HTML and make sure you only output one canonical og:image for the page.

Also ensure you are not mixing protocols. If your site is HTTPS, prefer HTTPS image URLs. When in doubt, set og:image to the HTTPS version.

Dynamic OG endpoints: watch for timeouts

Dynamic image generation can be great, but it adds failure modes: cold starts, slow renders, and timeouts. If your og:image points to an endpoint like /api/og?title=..., make sure it is:

• Fast enough for bots (low latency)
• Cacheable (so repeated shares do not regenerate)
• Stable (same inputs always return an image)

If you cannot guarantee speed and reliability, pre-generate static images and reference them directly.

A practical fix flow (10 minutes)

If you want the shortest path to "fixed", follow these steps:

1. Generate a fresh 1200x630 image in the Generator.
2. Create correct tags in Meta Tag Generator.
3. Deploy and verify the live HTML contains the tags via Validator.
4. Force a re-scrape via the platform debugger (Facebook/LinkedIn/Twitter).
5. Share the URL in a private channel to confirm the real unfurl.

If you have many pages: audit the whole site

If this problem shows up on multiple URLs, do not debug them one-by-one. Run a bulk audit. Our Site Audit crawls your sitemap and reports missing or broken OG tags at scale.