Why Your Link Preview Is Blank, and How to Fix It

The four reasons previews fail

When an og image not showing, it is almost always due to one of four specific technical failures rather than a mysterious platform bug. The most common causes are a file that exceeds the size limit, a relative URL path, a redirect that the crawler refuses to follow, or a stale cache from a previous version of the page.

Crawlers for X, LinkedIn, and messaging apps are not browsers. They do not execute JavaScript, they do not wait for dynamic content, and they often have strict timeouts. If your HTML does not present a clear, absolute, and optimized image path within the first few seconds, the crawler gives up. This is a constraint of how these services work, not a flaw in your code. You must treat the crawler as a dumb, impatient client that only reads static HTML.

Check the file size and URL structure

The first thing to verify is the Open Graph tag in your HTML. The og:image property must contain an absolute URL, starting with https://. If you use a relative path like /images/logo.png, many crawlers will ignore it because they do not know which domain to resolve it against. Always use the full domain.

Next, check the file size. While specific limits vary by platform, a safe target is under 300 kilobytes for a standard 1200x630 pixel image. If your image is a high-resolution JPEG or an uncompressed PNG, it may take too long to download. The crawler might time out before the file loads. Compress your images using tools like ImageOptim or Squoosh. A smaller file loads faster, ensuring the crawler can fetch it within its timeout window. This is a simple optimization that prevents a large class of failures.

Redirects and caching issues

If your image URL redirects to another location, some crawlers will not follow it. For example, if your image is hosted on a CDN that redirects to a different domain, or if your site uses a trailing slash that redirects, the crawler may see the initial URL and stop. Test your image URL in a browser. If you see a redirect, ensure the final URL is direct. You can force this by serving the image from a static path without any server-side redirects.

Caching is the other major culprit. When you update an image, the crawler may still have the old version in its cache. This is particularly common if you have changed the image URL but not the metadata. To force a refresh, you can append a query string to the image URL, such as ?v=2. This creates a new unique URL, forcing the crawler to treat it as a new file. This is a standard technique for cache busting. It works because the crawler sees a different string and fetches the new file.

Testing and maintaining your metadata

Do not rely on visual testing in a browser. Use the official debugging tools for each platform. X has a Card Validator, LinkedIn has a Post Inspector, and Facebook has a Sharing Debugger. These tools show you exactly what the crawler sees. If the image is not appearing in the debugger, it is not a platform issue; it is a configuration issue on your end.

For our own products, we serve static builds directly from disk via Caddy. This means the HTML is identical to what the crawler sees. There is no server-side rendering to wait for. We keep our Open Graph images small and use absolute URLs. When we update an image, we change the file name to ensure a cache bust. This approach is simple and reliable. It avoids the complexity of dynamic rendering and ensures that the metadata is always available to the crawler. If you are building a static site, this is the most effective way to ensure your previews work. You can see examples of this in our PracandyFlix articles, where the preview images are always consistent across platforms.