CONTENT AND PREVIEWS

Why your website's social preview looks wrong

Diagnose missing Open Graph metadata, stale share images and inaccessible image URLs before promoting a new page.

NewSiteCheck editorial · Updated October 14, 2026 · 3 min read

A wrong share preview often comes from missing social metadata, a stale cached preview, or an image the platform cannot fetch. Inspect the page's declared Open Graph fields first. Then verify the actual image and the platform's current fetch; a correct HTML tag is only part of the path.

Check the exact shared URL

Use the same URL someone pasted into the social app, including any redirecting host or path. The metadata checker follows the public response and shows Open Graph title, description and image values. A page can have a good ordinary title but no social fields, leaving a platform to infer the preview. A redirect to another page can also explain why the preview describes a different destination.

Look for shared template defaults

If many pages show the same image or an old brand name, inspect the common template before editing every page. A default image may be appropriate for a simple site, but the page-specific title and description should still describe the destination. Compare a homepage, guide and product page to see which values are inherited. A screenshot from your page editor is not proof that the live HTML has changed.

Verify the image independently

Open the declared image URL in a private browser window. Check that it is public, uses the intended protocol, returns an image rather than an HTML error, and does not require a login or a short-lived access token. Review cropping, readable text and the actual subject. NewSiteCheck reports the declaration and does not download or validate the image; that manual step is essential before calling the preview ready.

Account for platform caching

A platform may keep a previous preview after you change the page. Compare the time of your deployment with the platform's latest fetch. Use the platform's own preview/debugging workflow where available. Renaming an image can be useful when the underlying asset is aggressively cached, but do not randomly change the page URL to work around every stale preview. Keep the preferred public page consistent while resolving the caching layer.

Build a useful visual, not just a logo

Choose an image that communicates the page's subject at small size. Avoid dense text, low contrast and details that disappear in a crop. Make sure the headline in the image matches the page rather than promising something broader. Reserve visual space in page layouts separately; an Open Graph asset is not a substitute for optimizing the on-page images. A simple clear composition often travels better than a screenshot full of interface text.

Retest before the next campaign

Keep a short promotion checklist: public URL, final destination, correct metadata, accessible image and actual platform preview. Save the metadata result as a timestamped snapshot, then test the post draft itself. If a colleague manages social publishing, share the exact final URL and approved image instead of a vague instruction to use the new page. That handoff prevents a technically correct launch from being promoted with outdated assets.

A practical action checklist

  1. Inspect the exact shared URL and final destination.
  2. Compare page-specific metadata with template defaults.
  3. Open the declared image without signing in.
  4. Refresh or verify the platform's cached preview.
  5. Approve the actual post preview before publishing.
Reference documentation

NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.