OG image not showing? The 12-point checklist

A missing preview is almost always one of five things: the tags are not in the HTML the crawler receives, the image URL is wrong, the image is unreachable, the platform cached an old version, or two sets of tags are fighting. Work through the checks in order. Each one eliminates a layer instead of guessing.

1. Check the raw HTML, not the browser DOM

Right-click the page and choose View Page Source, or run curl -sL https://example.com/page | grep -i og:image. If the tag appears in DevTools but not in the source, it is being injected by JavaScript. Many social crawlers do not execute JavaScript, so they never see it.

curl -sL https://example.com/blog/post | grep -iE 'og:|twitter:'

If that command prints nothing, the problem is upstream of every platform. Fix the server rendering first: use the framework's metadata API, a CMS plugin that renders on the server, or a static tag in the head.

2. Confirm the image URL is absolute and public

The tag should contain a full URL starting with https://. A relative path such as /og.png is resolved inconsistently. A localhost URL is only reachable from your machine. A signed URL may expire before the crawler fetches it.

<meta property="og:image" content="https://example.com/og/post.png" />

3. Open the image URL in a private window

Paste the exact og:image URL into a private browser window with no session. It should render the image, not a login page, not a 404, and not a redirect loop. Check the response headers as well: the status should be 200 and the content type should be image/png, image/jpeg, or image/webp.

curl -sI https://example.com/og/post.png | grep -iE 'HTTP/|content-type|content-length'

• 403 or 401: the image is behind authentication, a firewall, or hotlink protection. Allow the social crawlers or move the image to a public bucket.
• 404: the path is wrong or the file was never deployed. Check case sensitivity; /OG.png and /og.png are different on most servers.
• 302 or 307: the crawler may follow a redirect, but some platforms do not. Point the tag at the final URL.
• 200 but `text/html`: the URL is returning an error page, not an image. Open it and look.

4. Check the dimensions and file size

A tiny image can be rejected or displayed as a small thumbnail. Aim for at least 600 x 315 for a large card, ideally 1200 x 630. Confirm the dimensions in an image editor or with identify from ImageMagick. If the file is several megabytes, compress it; some scrapers time out or fall back to no image.

identify https://example.com/og/post.png
# post.png PNG 1200x630 1200x630+0+0 8-bit sRGB 184KB

5. Look for duplicate tags

A CMS plugin, a theme, and a hand-written snippet can all emit og:image. When a page has two different images, the platform may pick the first, the last, or the one it parsed most recently. Search the source for every occurrence and keep one source of truth.

curl -sL https://example.com/blog/post | grep -c 'property="og:image"'

If the count is greater than one, disable the duplicate. In WordPress, that usually means turning off the social module in one plugin or removing the theme's hand-written tags. In a custom app, check the layout, the page, and any SEO component that runs on both.

6. Check the crop, not just the file

The image may be present and still look wrong because the platform cropped the headline out. A square image in a wide card loses the top and bottom. A 1.91:1 image with the text at the far left can lose it to a square crop. This is a design failure, not a tag failure: move the content into the middle 80 percent and export a new file.

7. Clear the platform cache

Platforms cache previews aggressively. If the tags and image are correct but the old preview persists, the cache is the problem. The fix is either a forced re-scrape or a new image URL.

If a platform still refuses to refresh, publish the image under a new filename (post-v2.png) and update og:image. That is the only refresh that works everywhere, including clients with no debugger.

8. Check crawler access

A robots.txt rule that blocks the page or the image can prevent a preview. Some platforms respect robots directives for unfurling; others fetch anyway. Check both the page and the image path. Also check X-Robots-Tag headers and any CDN bot rules that block unknown user agents.

User-agent: *
Allow: /
Allow: /og/
Disallow: /admin/

9. Check the page's canonical and URL

If the page is served at several URLs, the preview may be built for a different one. Use the canonical URL in og:url and share that URL. A tracking parameter can create a separate cache entry that still points at the right page but has never been scraped.

10. Check the image itself

• Transparency: some platforms composite it onto black or white. Export a solid background.
• Colour profile: use sRGB. CMYK images can fail or shift.
• Corrupt file: open it in a second viewer. A file that renders in one browser can fail in a scraper.
• Animated GIF: support is inconsistent. Use a static image.
• SVG: many social crawlers do not render it. Export a PNG or JPG.

11. Test the exact URL you shared

It is easy to test the canonical URL and share a variant with a query string, a trailing slash, or a different subdomain. Paste the exact URL that appears in the post, not the one in your address bar after a redirect. If the site redirects http to https or www to apex, test the final URL.

12. If everything looks right, wait

Platforms can take hours to refresh a preview, and some clients cache for weeks. If the debugger shows the correct image and the live composer still shows the old one, you have done the work. Change the filename if the old card is actively harmful, or accept the delay.