Social images: size, safe area and the crop you did not plan for

og:image requires an absolute URL, with the scheme and the host. This is the single most common way the tag fails, and it fails in the least helpful way possible: the value is present, the syntax is valid, nothing reports an error, and no image appears.

The reason it catches people is that a relative path works everywhere else on the page. An <img src="/img/hero.jpg"> resolves against the document URL because the browser knows what document it is in. A scraper reading a value out of a meta tag is not resolving anything: it takes the string and requests it. Some readers do resolve it and the tolerant ones have taught a lot of teams that a relative value is fine. It is not, and the surfaces that drop it do not tell you.

wrong                              right
---------------------------------  -----------------------------------------
/img/hero.jpg                      https://example.com/img/hero.jpg
img/hero.jpg                       https://example.com/img/hero.jpg
//example.com/img/hero.jpg         https://example.com/img/hero.jpg
http://example.com/img/hero.jpg    https://example.com/img/hero.jpg
https://localhost:3000/hero.jpg    the production host, not the build host
https://cdn.example.com/h.jpg?v=2  fine, as long as it returns 200 to a bot

The protocol-relative form on the third row is the subtle one. It is legal in HTML, it works in a browser, and as a bare string handed to an HTTP client it has no scheme, so it is not a fetchable address. The fifth row is what happens when the value is built from an environment variable that was right in development.

Two related properties are worth setting while you are in the file. og:image:alt describes the picture for anyone who cannot see it, which is the same obligation as alt text everywhere else on the page. And og:image:width with og:image:height lets a surface reserve the right space before the file has downloaded, which is the difference between a card that appears and a card that appears, jumps, and reflows.

You supply one image. Different surfaces show it at different aspect ratios, and none of them ask permission. A wide card keeps most of the frame, a compact card takes a centre square, and a thumbnail in a chat client can take less than that. All of them crop from the middle outward, which means the middle is the only part you control.

Two rules follow from the shape and they are the whole of the practical advice. Keep text well inside the centre, and never let a word run to an edge. Then check the square crop rather than the wide one, because if the image survives being squared it survives everything.

The corollary is about templated images. Generating a share image per page from the page title is a good technique and it is where edge-crowding gets baked in at scale: the template is designed against the widest ratio, the longest title wraps to three lines, and the third line sits in the cropped band on every page with a long title. Test the template with your longest title, not a representative one.

Not for retrieval, and the reason is worth stating plainly: a share image is not part of your content. Nothing in it is indexed as an answer, and a model reading your page to resolve a question has no use for a 1200 by 630 JPEG containing your headline in a typeface.

There is one narrow exception, and it is an accessibility artefact rather than an image one. og:image:alt is text, so it is readable, and on a page whose subject is thin it is one more sentence describing what the thing is. That is a marginal effect and not a reason to do any of this.

The real connection runs the other way. Assistants that cite sources render those citations as cards, and a card with no image is a smaller, quieter, less clickable object in a list of results that mostly have one. So the image does not help a model choose you. It helps a person act on a model having chosen you, which is the only step in that funnel where a picture has ever mattered.

Every real failure here is downstream of the declaration, so the check has to follow the URL and look at what comes back.

URL=https://example.com/guides/sharpening

IMG=$(curl -s "$URL" \
  | grep -o 'property="og:image" content="[^"]*"' \
  | sed 's/.*content="//;s/"$//')

echo "declared: $IMG"

# absolute? a relative value is the failure that reports no error
case "$IMG" in
  https://*) ;;
  *) echo "NOT ABSOLUTE, most scrapers will drop this" ;;
esac

# status, type and size, as a scraper would get them
curl -sI "$IMG" | grep -i '^HTTP/\|^content-type:\|^content-length:'

A content-length in the millions and a content-type of image/svg+xml are both silent failures on some surfaces. A 403 means your CDN is refusing the request that builds every preview of your site.