Practical answers about metadata, image selection, crawler access and stale cards.
Social apps usually fetch HTML and read machine-facing metadata instead of rendering the page like a browser. Open Graph tags give them a title, description, canonical URL and image without requiring JavaScript or a signed-in session.
Start with og:title, og:description, og:url and og:image. Add og:image:width, og:image:height, og:image:type and og:image:alt beside the image. Add twitter:card when X matters, and keep the ordinary HTML title, meta description and canonical link accurate too.
Use a direct, public 1.91:1 image around 1200x630 as the first og:image. The Open Graph protocol gives the first value preference when repeated properties conflict. Separate platform checks may still recommend a different crop or additional image.
Keep the wide Open Graph image first for ordinary link cards. When Pinterest is important, add a high-resolution portrait image to the page's supported Schema.org or Rich Pin markup. That adds a Pinterest candidate without making every other crawler start with a tall image.
Yes. A browser can load a page while a crawler receives a challenge, 403 response or non-HTML interstitial. Allow known or verified bots through the relevant rules where your provider supports verification. Do not use a user-agent string as the trust boundary because it can be copied.
A redirect is not automatically broken, but every hop adds another host, TLS handshake, cache rule and security policy that can fail. Prefer a stable final HTTPS image URL and test the redirect chain if a CDN or image optimizer makes a redirect unavoidable.
First confirm that the public HTML contains the new og:image and that the image URL returns the new bytes. Purge your own page and image caches, then use the platform's refresh tool when it has one. If an image proxy still holds the old asset, publish a versioned image URL and make sure your CDN cache key distinguishes that version.
There is no dependable cross-platform duration. A service can cache page metadata, proxied images and an already published post separately, and public retention details can change. Diagnose the current HTML and image first; use an official refresh tool where one exists instead of waiting for an assumed number of hours.
PreviewChecks compares a regular HTTP fetch with requests that use common crawler user agents. A difference can expose user-agent rules, challenges or server failures. These are diagnostic requests from PreviewChecks infrastructure, not verified traffic from a social platform's published IP range.
Yes. The website and public API do not require an account or payment. Fair-use limits keep the shared service available for everyone.
The public API allows 20 uncached checks per minute for the same client IP and target host, and 60 uncached checks per minute for that IP across all hosts. A cached response does not use that allowance. Abusive traffic may be blocked.
There is no account or check history in the product. The submitted URL and standard request data can be processed temporarily to return the report, enforce rate limits, secure the service and investigate failures. The privacy policy explains those purposes and retention limits.
No. PreviewChecks gives you one cross-platform report and can show what its own requests received. An official inspector can refresh platform-owned data and test behavior that only that platform controls. Use both when a report is clean but one published card is still wrong.
Do not start by guessing a cache duration. Work from the public response outward so you know whether the stale copy belongs to your origin, your CDN, an image proxy or the social platform.
Step 1
Check the response body, not only the browser DOM. Confirm the title, description, canonical URL and first image are the values you expect.
Step 2
Follow every redirect and verify the final status, MIME type, dimensions and bytes. A correct tag cannot repair an image response that fails.
Step 3
Invalidate the page HTML and image at the origin or CDN. Recheck until an uncached request receives the new content.
Step 4
Use an official inspector where one exists. If only an image proxy is stale, publish the image under a new versioned URL rather than changing unrelated page parameters.
These tools can inspect or refresh data owned by their platform. PreviewChecks does not submit URLs to them and cannot clear their caches on your behalf.
Inspect what Facebook fetched and request a fresh scrape.
Inspect a URL and refresh the data LinkedIn uses for new posts.
Other platforms may provide documentation without a public purge tool. In that case, confirm the live response, avoid repeatedly changing the page URL, and version only the asset that is actually stale.