A social media link preview that is missing, incomplete, or out of date can be caused by several different problems: the page may be inaccessible to a crawler, its Open Graph tags may be absent from the HTML response, or the platform may be showing a cached scrape. This guide gives you a diagnostic sequence to separate those causes and check the exact URL you shared.
Key Takeaways
- Test the exact URL you posted, including its scheme, path, query string, and trailing slash.
- Check that the final HTTP response is successful and that the Open Graph metadata appears in the HTML delivered by the server.
- Make sure the page and its preview image can be fetched without a login or other access barrier.
- Use the relevant platform’s inspection tool to check its scrape and request a refresh when available.
- A successful check on one platform does not guarantee the same preview on another; platforms can fetch, cache, and display links differently.
Diagnose the problem in order
Start with the URL as it appears in the social post. https://example.com/article and https://example.com/article/ may resolve differently or have different cached scrapes. So can URLs with different query parameters. Test the exact version you shared before changing page metadata.
Then work through the page response, the HTML metadata, and the platform’s stored scrape. This order helps you avoid refreshing a cache when the page itself is still serving incorrect or inaccessible content.
1. Check whether the page is publicly reachable
A social crawler needs to retrieve the page. Open the shared URL in a private browser window to check for an obvious login or access requirement, then inspect its HTTP response with curl:
curl -sS -L --max-redirs 5 \
-D /tmp/preview-headers.txt \
-o /tmp/preview-page.html \
-w '\nFinal status: %{http_code}\nFinal URL: %{url_effective}\nContent type: %{content_type}\n' \
'https://example.com/article'
Check the final status, final URL, and content type. A redirect is not automatically a problem, but the chain should end at the intended public page, not a login screen, error page, or unrelated destination. Review the saved headers if you need to trace the redirects. If the request fails, investigate TLS or DNS problems, server errors, access controls, or network rules before changing the metadata.
A browser loading the page successfully does not prove that a platform’s crawler can fetch it. A firewall, bot rule, rate limit, or crawler-specific access policy might treat requests differently. Comparing responses with a crawler user-agent can help find server-side differences, but changing the user-agent in curl only simulates a request; it does not prove what a platform can access.
2. Inspect metadata in the HTML response
Check the HTML saved by curl, not only the page displayed in your browser. The relevant tags should be present in the document’s <head> when the server returns the page. For example:
<head>
<title>Guide to Example Topic</title>
<meta property="og:title" content="Guide to Example Topic">
<meta property="og:description" content="A short summary of the guide.">
<meta property="og:image" content="https://example.com/images/guide.jpg">
<meta property="og:url" content="https://example.com/article">
</head>
To find Open Graph tags in the downloaded response, you can use:
grep -i 'og:' /tmp/preview-page.html
This quick search may be inconvenient with minified HTML or unusual formatting. If it finds nothing, inspect the full response or use your browser’s View Source option. The browser’s Elements panel shows the live DOM after scripts have run; that is not necessarily the HTML a crawler receives.
If your site adds Open Graph tags only after JavaScript executes, a crawler that reads the initial server response may not see them. Prefer rendering the tags into the initial HTML, and check the actual response again after deploying the change. Confirm that the title and description are accurate, the image URL is absolute and publicly reachable, and og:url names the intended page. Also check that a redirect or canonicalization rule is not sending the crawler to a different page than the one whose metadata you edited.
3. Check access to the preview image
A page can be fetchable while its image is not. Open the exact image URL from og:image in a private browser window and check that it returns the intended image without a login, an expired signature, or an access-denied response. The image should be hosted at a stable URL, and its format and dimensions should suit the platform’s requirements.
If the image requires cookies, is blocked by a bot rule, or redirects unexpectedly, fix that separately from the page metadata. A valid og:image tag cannot compensate for an image that the platform cannot retrieve.
4. Inspect the platform’s scrape and cache
After confirming the page response and metadata, use the relevant platform’s link-inspection or sharing-debugging tool, if available, to inspect what that platform reports for the exact URL. Look for fetch errors, the metadata it detected, and any preview it provides. If the tool offers a way to refresh or rescrape the URL, use it after the corrected page is live.
For Meta, use Meta’s current sharing-inspection tool rather than assuming an older tool name or menu is still current. I cannot verify the current Meta documentation or interface in this environment, so check Meta’s official documentation for the tool’s present name, supported checks, and refresh behavior. Treat the inspector as a diagnostic for Meta’s fetch and scrape—not as a guarantee that every viewer or placement will display an identical card.
Give the platform time to fetch the updated page, then check the result again. If the inspector still reports old metadata, first confirm that the URL being inspected exactly matches the URL in the post and that the corrected response is live. Repeatedly editing tags without checking the fetched response makes it harder to identify the cause.
5. Compare results across platforms
If one platform shows the card and another does not, compare each platform’s inspection result rather than assuming the page is broken everywhere. Platforms may use different crawlers, cache policies, metadata interpretations, and display rules. They may also apply their own image or content requirements.
Keep a short record for each test: the exact URL, final HTTP status and destination, tags in the response, image accessibility, and what the platform’s inspector reported. This makes it easier to see whether the issue is page-wide, specific to one crawler, or a stale cached result.
Common Mistakes
- Checking only the browser’s rendered page: JavaScript may add tags after the initial response. Inspect the source HTML returned by the server.
- Refreshing the cache before fixing the page: A new scrape can still capture missing metadata or a broken image. Verify the live response first.
- Testing a different URL: A slash, query parameter, redirect, or hostname variation can produce a different page or cached result.
- Assuming a page preview proves the image works: Check the image URL itself; it may have different access controls from the page.
- Treating one platform’s inspector as a universal test: A result for Meta does not confirm what another platform fetched or will display.
- Assuming a successful inspection guarantees a card: Platform checks can confirm what that tool reports, but final display may differ by platform or context.
Best Practices
- Render important Open Graph tags in the server-delivered HTML.
- Keep preview pages and images publicly accessible to the intended crawlers.
- Use stable, absolute image URLs and verify them after deployment.
- Test the exact shared URL and follow its redirects to the final destination.
- Recheck platform-specific scrape results after metadata changes, while recognizing that cache refresh and display behavior vary.
Conclusion
Diagnose a missing social media link preview by checking the exact URL, its HTTP response, the metadata in the returned HTML, and access to the preview image—in that order. Then use each platform’s current inspection tools to check its scrape and cache. These checks narrow down the cause, but no single platform’s successful inspection guarantees identical previews everywhere.