[CODE]

Why Your OG Preview Image Does Not Show on LINE: Six Places to Check

I debugged OG preview failures across multiple B&B client sites. There are at least six independent cache layers that can each silently break your preview image.

5 min read
og seo web debugging

A few months back I was helping a few small bed-and-breakfast clients get their sites looking right when shared on LINE. The sites looked fine in the browser. The og:image meta tag was there. And yet — blank preview. Every time.

I probably spent more cumulative hours on this than I’d like to admit. Turns out there are at least six completely independent things that can each silently break your OG preview image, and they fail in ways that look identical from the outside.

Here’s what I found, roughly in order of “how likely this is to be your problem.”

First: Verify the meta tags are actually there

Before anything else, check what a scraper actually sees. Don’t trust your browser devtools — your browser renders the page with JavaScript, ignores og: meta, and generally lies to you about what scrapers get.

Use curl to fetch the raw HTML:

curl -A "facebookexternalhit/1.1" https://yoursite.com/some-page | grep og:image

The -A flag sets the User-Agent to Facebook’s scraper. If you see your tag, great. If you don’t see anything, the problem is in your HTML — wrong page, server-side rendering issue, or the tag is being added by JavaScript after load.

The six failure modes

1. Your image URL is relative, not absolute

This one is embarrassingly common. og:image must be a full absolute URL:

<!-- wrong -->
<meta property="og:image" content="/images/hero.jpg" />

<!-- right -->
<meta property="og:image" content="https://yoursite.com/images/hero.jpg" />

Scrapers don’t have a base URL to resolve relative paths from. They just skip the image silently.

2. Image dimensions are wrong

The minimum is 200×200 pixels. Facebook and LINE will refuse to display smaller images. The recommended size is 1200×630 — that aspect ratio fills the preview card nicely. If you’re using a square image that’s 150×150 or some tiny thumbnail, the scraper will fetch it and then not show it. No error, just blank.

3. The image Content-Type header is wrong or missing

Fetch the image URL directly and check the response headers:

curl -I https://yoursite.com/images/hero.jpg

You want to see Content-Type: image/jpeg or image/png. If it says application/octet-stream or is missing entirely, the scraper may not recognize it as an image. This can happen with CDN misconfigurations or S3 buckets that weren’t told what file type they’re serving.

4. Bot protection is blocking the scraper

Some sites have rate limiting or bot protection (Cloudflare’s “Under Attack” mode, firewall rules, etc.) that blocks scrapers. The scraper gets a 403 or a CAPTCHA page instead of your HTML.

Test this explicitly:

curl -A "facebookexternalhit/1.1" https://yoursite.com/
curl -A "Twitterbot/1.0" https://yoursite.com/

If you get a 403 or HTML that looks like a Cloudflare challenge, you need to allowlist scraper User-Agents in your firewall rules.

5. Cloudflare cache is serving stale content

If you updated your og:image after the page was already cached, Cloudflare may be serving the old version to scrapers for hours or days. You can purge specific URLs via the Cloudflare dashboard or API:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://yoursite.com/some-page"]}'

Alternatively, set up a Cache Rule that bypasses cache for known scraper IPs or User-Agents. Scrapers usually don’t need to hit your CDN cache anyway.

6. LINE’s own cache (the sneaky one)

Even after you fix everything else, LINE has its own internal cache with a 72-hour TTL. So you fix your og:image, you test with Facebook’s Sharing Debugger, it shows the correct image — but LINE still shows the old one (or nothing).

The fix is the LINE Page Cache Refresh Tool: developers.line.biz/en/docs/messaging-api/sharing-rich-menus-between-multiple-line-official-accounts/. You paste your URL and it forces LINE to re-crawl the page. After that, shares should pick up the new image within a few minutes.

Facebook’s Sharing Debugger also does a fresh fetch when you paste a URL and hit “Scrape Again” — I usually start there because it shows you the parsed og: tags and any errors it found.

The actual diagnosis order

When I hit a broken preview now, I go through this sequence:

  1. curl with a scraper UA to confirm tags are in the HTML
  2. Check the og:image URL — is it absolute? Does it load directly in a browser?
  3. curl -I on the image URL to check Content-Type and status code
  4. Paste the page URL into Facebook Sharing Debugger and read the error output
  5. If the debugger shows the right image but LINE doesn’t: LINE Cache Refresh Tool
  6. If the debugger can’t even fetch the page: bot protection issue
  7. If the debugger shows a stale image: Cloudflare cache purge

Six independent things. Any one of them can be your entire problem. The frustrating part is they all look the same from the user’s perspective: you share a link and get a blank card.