Skip to main content

OG Image Not Loading? Server vs CDN Fixes

7 min read

Your og:image tag is in the HTML. Facebook Debugger shows the URL. But the preview has no image or a broken placeholder. That is a loading problem, not a missing tag problem.

This guide covers server failures, CDN misconfiguration, and bot blocking when the image URL exists but crawlers cannot fetch it. If the tag itself is absent, read How to Fix a Missing OG Image instead.

Short answer

When og:image exists but the image does not load, open the image URL in an incognito tab and run curl -I on it. Look for non-200 status codes, redirects to login pages, wrong Content-Type, slow response times over 2-3 seconds, or bot challenges from Cloudflare and similar WAFs. Fix server access for crawler user agents, correct CDN cache rules, and ensure the origin returns the image bytes without authentication.

Server vs CDN: where failures happen

Crawler → CDN edge → Origin server → Image file
              ↑              ↑
         cache miss     403, timeout,
         stale HTML     wrong path
LayerSymptomTypical cause
Origin403, 401, 500Auth required, app error, wrong file path
CDN403 to bots onlyBot fight mode, geo block, hotlink protection
DNS / SSLConnection failedCertificate mismatch, expired cert
Application200 but HTML bodyRewrite rule serves SPA shell instead of image

The meta tag is fine. The bytes never reach the crawler.

Step 1: Reproduce as a crawler

Open the exact og:image URL from page source in an incognito window. No login, no cached session.

Then test from the command line:

curl -I "https://yoursite.com/images/og.jpg"

Check:

SignalGoodBad
HTTP status200301 loop, 403, 404, 502
Content-Typeimage/jpeg, image/png, image/webptext/html, application/json
Response timeUnder 2 secondsTimeout or 5+ seconds
Content-LengthMatches file size0 or tiny (error page)

Also test with a Facebook crawler user agent:

curl -I -A "facebookexternalhit/1.1" "https://yoursite.com/images/og.jpg"

If this returns 403 but your browser returns 200, bot protection is the culprit.

Step 2: Server-side issues

Authentication and paywalls

Staging sites behind basic auth block every crawler. Production pages with membership plugins may protect /wp-content/uploads/ paths. The image must be publicly readable without cookies.

Wrong path or case sensitivity

Linux servers are case-sensitive. OG.jpg vs og.jpg breaks on production but works on macOS dev machines.

Application route returning HTML

Dynamic image routes that crash return an HTML error page with status 200. The crawler stores garbage. Open the URL and confirm you see an image, not a Next.js error overlay or JSON.

See Dynamic Open Graph Images Explained for route debugging.

Slow origin

Oversized PNG files (2 MB+) or cold serverless starts cause timeouts. Compress to under 300 KB. See the format guide.

Step 3: CDN issues

Bot protection (Cloudflare, Akamai, Sucuri)

WAF rules challenge or block non-browser user agents. Social crawlers do not solve JavaScript challenges.

Fix: Allowlist crawler user agents (facebookexternalhit, LinkedInBot, Twitterbot, Slackbot, Discordbot) or disable bot fight mode on the image path.

Hotlink protection

CDNs that block requests without a matching Referer header break OG fetches. Crawlers often send no referer or a foreign one.

Fix: Disable hotlink protection for /images/ or your OG asset path.

Cache serving stale or wrong content

CDN may cache a 404 or an old HTML response for the image URL. Purge the specific URL after upload.

Fix: Purge CDN cache, verify with curl -I, then re-scrape in platform debuggers. See Open Graph Cache Busting.

Content negotiation mismatch

CDN serves WebP to some clients and fails on others. Confirm the file extension matches the bytes and Content-Type header.

Step 4: SSL and redirect chains

Crawlers follow up to a few redirects. Long chains or HTTP-to-HTTPS misconfiguration cause failures.

  • Use HTTPS directly in og:image
  • Avoid redirecting image URLs through URL shorteners
  • Fix mixed content: never point og:image at http://

A redirect to a login page returns 200 HTML after the redirect. Always curl the final destination.

Step 5: robots.txt and firewall rules

robots.txt rarely blocks image URLs directly, but some setups disallow /media/ or entire CDN subdomains.

Corporate firewalls and geo-blocking can prevent US-based crawlers (Meta, LinkedIn) from reaching EU-only origins. Test from an external uptime monitor outside your network.

Platform-specific loading behavior

Facebook and WhatsApp

Meta's crawler is aggressive but timeout-sensitive. Images over 8 MB or slow TLS handshakes fail silently. Use the Facebook Sharing Debugger and check "Image" scrape warnings.

LinkedIn

LinkedInBot fetches og:image separately from page HTML. A page that loads fine in browser DevTools can still fail if the image URL blocks LinkedInBot specifically.

X (Twitter)

X validates twitter:image and OG fallbacks. Card Validator shows fetch errors when the image URL is unreachable.

Discord and Slack

Both fetch OG images on unfurl. Discord is sensitive to slow responses. Slack caches per workspace; a fixed image may need a new unfurl to appear.

Fix checklist

  1. Confirm og:image URL in View Source (tag exists).
  2. curl -I returns 200 with image Content-Type.
  3. curl -I with crawler user agent returns 200 (not 403).
  4. Image opens in incognito without login.
  5. File under 1 MB, ideally under 300 KB.
  6. CDN cache purged after changes.
  7. Scan page with OpenGraph Check - image shows in previews.
  8. Re-scrape in platform debugger.

Common mistakes

Fixing the tag when the tag is already correct

Adding duplicate og:image tags or switching meta plugins does not help if the URL returns 403. Fix access first.

Testing only in logged-in browser

Your session bypasses auth. Crawlers have no session.

Blaming platform cache first

Cache shows an old image, not a blank one. No image at all usually means fetch failure, not stale cache. See Social Preview Cache Explained for the difference.

Blocking all bots in robots.txt

Disallow: / or aggressive bot rules on CDN WAF block preview crawlers along with SEO bots.

FAQ

Why does og:image exist but not show?

The crawler cannot download the file. Common causes: 403 bot block, auth wall, timeout, wrong Content-Type, or URL returning HTML instead of image bytes.

How do I test if crawlers can reach my OG image?

Run curl -I -A "facebookexternalhit/1.1" YOUR_IMAGE_URL. Status must be 200 with an image Content-Type. Then scan with OpenGraph Check.

Does Cloudflare block Open Graph images?

Bot Fight Mode and some WAF rules block social crawlers. Allowlist facebookexternalhit, LinkedInBot, Twitterbot, Slackbot, and Discordbot on the image path.

Why does the image load in browser but not in link previews?

Your browser has cookies, passes JS challenges, or uses a different CDN edge. Crawlers do not. Test incognito and with curl.

Can a CDN cache a broken OG image response?

Yes. A cached 404 or HTML error page persists until you purge that URL. Purge and verify with curl.

Is this different from a missing og:image tag?

Yes. Missing tag means the meta property is absent from HTML. Not loading means the tag points to a URL that crawlers cannot fetch. Different fixes.

What response time is too slow for OG images?

Aim for under 2 seconds to first byte. Responses over 5 seconds often fail on Meta and Discord crawlers.

Bottom line

An existing og:image tag with a broken preview is almost always a fetch problem at the server or CDN layer. Curl the image URL with crawler user agents, fix 403s and timeouts, purge CDN cache, and confirm with OpenGraph Check. Leave tag syntax fixes to the missing OG image guide.