og:image not showing? How to fix social previews
·4 min read
When og:image is not showing, the platform's crawler either never found the tag or could not download the image it points to. Check the HTML your server sends for one og:image tag with an absolute https URL, then request that URL as a stranger would and confirm it returns 200, an image/ content type and a JPG or PNG of sensible size. If both pass and the preview is still wrong, the platform is showing a cached copy.
| Cause | Fix |
|---|---|
| Relative or http image URL | Use the full https URL |
| robots.txt, login or bot protection blocks the image | Let the preview crawlers fetch it |
| Tag added by JavaScript | Render it in the server HTML |
name="og:image" or duplicate tags |
One property="og:image" tag |
| Image too small, too large or SVG | 1200 x 630 JPG or PNG under 1 MB |
| URL returns HTML or redirects | Point at the final image file |
| Old preview cached | Rescrape with the platform's tool |
og:image not showing? Start with the image URL
Most broken previews have a bad URL in the tag. Open view-source and read the content value literally.
<!-- Breaks on most platforms -->
<meta property="og:image" content="/images/share.jpg">
<!-- Works -->
<meta property="og:image" content="https://www.example.com/images/share.jpg">A browser resolves /images/share.jpg against the page. Crawlers often don't, and the Open Graph spec at ogp.me gives the image as a URL, so write it out in full. Use https too. An http image on an https page can be refused by apps and in-app browsers.
Two more URL problems pass a quick glance. It can point at a page that displays the image, so the crawler gets text/html and throws the preview away. Or it redirects. Some crawlers don't follow image redirects, so point the tag at the address where the file actually lives. Run curl -sI on it and read the status and Content-Type lines. You want 200 and image/jpeg or image/png, with no Location header.
The crawler cannot fetch the image
The image loads for you because you are logged in and carry cookies. The crawler doesn't.
robots.txt. A Disallow: /wp-content/ or Disallow: /assets/ rule written to save crawl budget also blocks the preview crawlers from your share images. X's card troubleshooting guide names a robots.txt that blocks Twitterbot as a known cause. Add a group for the preview bots:
User-agent: Twitterbot
User-agent: facebookexternalhit
User-agent: LinkedInBot
Allow: /Our robots.txt tester guide shows how to confirm a path is allowed for one user agent.
Auth and hotlink protection. Staging sites behind basic auth, private buckets, signed URLs that expire, and hotlink rules that check the Referer header all answer the crawler with 401 or 403.
Bot protection. A WAF rule or JavaScript challenge can serve the crawler a challenge page instead of the image. Meta's crawler docs say to allowlist facebookexternalhit by user agent or IP address.
The tag is not in the HTML the crawler reads
Preview crawlers read the raw HTML your server returns. If React, Vue or a tag manager writes og:image after the page loads, the tag shows in your browser's element inspector and nowhere in view-source. Neither Meta nor LinkedIn says its crawler runs JavaScript, so render the tags on the server or prerender the page. Our JavaScript SEO guide covers the rendering options.
Two smaller tag problems:
- The wrong attribute. Open Graph uses
property=. Facebook tolerates<meta name="og:image">, stricter parsers skip it. - Duplicate tags. A theme and an SEO plugin both writing
og:imagegives you two values, and platforms disagree on which one wins. Keep one source of tags and turn the other off.
The image is too small, too large or the wrong format
A tag can be perfect and the image still rejected. Meta's image guidance sets a 200 x 200 minimum and an 8 MB maximum, and X's guide says its crawler downloads images up to 5 MB. Below 600 px wide, Facebook drops to a small square thumbnail, which people often report as "no image".
SVG and AVIF are the other trap. Facebook, LinkedIn and X take JPG, PNG, GIF and WebP, so export the share image as a JPG or PNG. A 1200 x 630 JPG at quality 80 usually lands between 100 and 300 KB. For per-platform dimensions and crop safe zones, see our Open Graph image size guide.
You fixed it and the old preview still shows
Every platform caches the preview it built first, missing image included, until it scrapes the URL again. Facebook also caches images by URL, so upload a replacement under a new file name rather than overwriting the old one.
Refresh with the platform's own tool. The steps are in our guides to the Facebook Sharing Debugger and LinkedIn Post Inspector.
Check your og:image and share card
Our Open Graph checker fetches your page, lists every og: and twitter: tag in the head, and shows which title, description and image a card would use. It flags a missing or relative og:image, an image on http, og: tags written with name=, conflicting duplicates and an og:url that differs from the canonical. Then it downloads the image and reports its status, content type, format, pixel size and file size. It flags an image that fails to load, returns something other than an image, uses SVG or AVIF, runs over 5 or 8 MB, falls under 200 px or 600 px wide, will be cropped, or redirects to another host. When a 403, rate limit or bot check stops the download, it says so, because the same rule can stop the preview crawlers.
A run costs 5 credits. It reads the HTML your server returns, so tags added by JavaScript won't appear. It doesn't test your robots.txt or refresh any platform's cache. Fix what it finds, then rescrape the URL on each platform.