Why your social media link preview is wrong—and how to fix it

You paste a link into a social post. The website has the correct headline and a new campaign image, but the preview shows last month’s offer, the company logo, or no image at all.

Changing the caption does not explain where that picture came from. Repeatedly pasting the link may reproduce the same result. The useful first question is: does the website provide the wrong information, can the platform retrieve it, or is an older copy still being used?

Those problems need different fixes. This guide walks through them, using Facebook and LinkedIn’s own inspection tools, then explains how to handle tracking links and posts that are already live. The troubleshooting example is fictional.

The quick route if you do not manage the website

Start with the exact link intended for the post, including any tracking parameters. Save a screenshot showing the incorrect title or image.

If you own the website, open that page’s publishing settings. Look for fields named social image, sharing image, Open Graph, or similar. Check whether they contain the intended title and image, then publish the changes. A page’s visible headline or featured image may be controlled separately from its sharing settings; your website’s configuration determines the relationship.

Next, inspect the URL using LinkedIn Post Inspector or Facebook Sharing Debugger, depending on where you plan to publish. Compare what the tool found with what you expected.

If the inspector cannot access the page or still reads the wrong information, send the evidence to the person responsible for the website. The handoff template below gives them a useful starting point.

Once the inspector reads the correct content, check the link in a fresh unpublished draft. If your problem concerns a post that is already live, read the section on existing posts before deleting or recreating anything.

Find the layer that needs fixing

A preview involves several separate pieces: the website’s description of the page, the platform’s retrieval and stored copy, and the attachment shown in a particular post. Your browser can show the latest page while another part of that process still contains older information.

LinkedIn’s URL troubleshooting guidance explains that its share box uses website oEmbed or Open Graph information and that missing metadata can lead to missing or unintended preview content. Meta’s webmaster guide similarly explains that Facebook may infer preview information when Open Graph tags are absent.

Use the symptom to choose the next check:

Treat these as investigation paths. A missing image alone cannot tell you whether the cause is an inaccessible file, unsuitable image properties, or outdated metadata.

Check the sharing metadata on the live page

The Open Graph protocol defines metadata placed in a page’s HTML <head>. Its basic properties identify the title, content type, representative image, and canonical URL. A description adds context; image-specific properties can provide dimensions and alternative text.

For a fictional article, a clear starting point would be:

<head>
  <title>Plan a better product demo</title>
  <meta property="og:type" content="article" />
  <meta property="og:title" content="Plan a better product demo" />
  <meta property="og:description"
        content="A practical guide to preparing a useful product demonstration." />
  <meta property="og:url"
        content="https://example.com/guides/product-demo" />
  <meta property="og:image"
        content="https://example.com/images/product-demo-share-v2.jpg" />
  <meta property="og:image:alt"
        content="A product demonstration checklist beside a laptop." />
</head>

The example uses absolute HTTPS addresses so the intended page and image are unambiguous. Replace the example values with real, public resources and meet the requirements of the destination platform.

Check the live output after saving. A correct field in an editing screen is only useful if the published page exposes the corresponding value.

Also check for competing metadata. A theme, an SEO extension, and custom code may each output sharing tags. Open Graph permits multiple image values and gives earlier values preference when they conflict. An old default image appearing before the intended one is therefore worth investigating.

Inspect the HTML the crawler receives

Ask your developer to inspect the server’s HTML response for the affected URL, including a request representative of the platform’s crawler. Checking the browser’s Elements panel after JavaScript has run is insufficient evidence on its own.

Framework behavior matters here. For example, Next.js documents special handling for HTML-limited bots, including Facebook’s crawler, so metadata is available in the HTML head. On your website, the practical question is whether the relevant crawler receives usable metadata without depending on a later browser interaction.

If the page was just updated, confirm that the live website or its CDN is serving the new HTML before asking the social platform to retrieve it again.

Verify access to both the page and the image

Opening a page while signed into your website does not prove that a social platform can retrieve it. Test the public URL without an authenticated session, then open the exact image URL reported by the inspector.

This quick check can expose an image stored behind a login, a temporary asset link, or a destination that redirects somewhere unexpected. A successful private-browser test is useful, but crawler access still needs its own check.

LinkedIn’s website-sharing guidance specifically identifies blocked access and protected image locations as possible causes of missing previews. It also publishes requirements for images used by its sharing module. Check that section for a link card; specifications for a separately uploaded image or an advertisement describe a different publishing context.

If retrieval fails, ask the website owner to examine the page and image requests around the time of the test. Useful questions include:

• Did the crawler reach the intended URL, or encounter a redirect, login page, or challenge?
• Did the server return the expected HTML or image rather than an error page?
• Was a firewall, bot rule, rate limit, or hosting restriction responsible?
• Does the image’s actual file type match what the server says it is?

Use the platform’s current crawler documentation when investigating. Meta lists its crawlers and their purposes, which helps distinguish sharing requests from other traffic.

Make any access change specific to the confirmed problem. A public article and its preview image may need an adjusted rule; unrelated private areas should keep their access restrictions. Merely changing a user-agent string in a test request does not establish the identity of a real crawler.

Check the image file as well as its address

Suppose the metadata points to campaign-share.jpg. You replace that file with a new design but keep its address. The website and another service may still have different stored copies of the same resource.

Your developer can check the relevant cache settings and purge managed caches where appropriate. For changed preview artwork, a versioned filename such as campaign-share-v2.jpg can also make the new resource explicit. Update og:image to that address, publish the page, and inspect it again. MDN’s caching guide explains the underlying use of versioned resource URLs, including for images.

That step addresses the image resource. The platform still needs to read the updated page metadata, and an existing social post may retain its original attachment.

Once the correct file appears, inspect the composition. Keep essential words and identifying details away from vulnerable edges, and judge the image at the size people will actually see. A valid file can still make an unclear preview. Use the destination’s current requirements and preview rather than assuming one set of dimensions guarantees identical rendering everywhere.

Refresh the platform’s copy after fixing the source

A refresh is useful when the source is ready. If the live page still supplies the wrong title or image, another retrieval can simply store the same incorrect values again.

LinkedIn

Enter the link in Post Inspector and examine the resulting information. LinkedIn’s instructions for refreshing a URL identify this as the tool for an outdated cached preview.

After the inspector shows the intended information, open a fresh draft and check the link there. Compare the exact URL if the result differs. A successful inspection of one address does not settle a problem involving another destination or redirect.

Facebook

Enter the link in Sharing Debugger. Review what Facebook retrieved and request another scrape after the website has been corrected, using the rescrape control available in the tool.

Meta’s metadata documentation explains that Facebook caches the resolved canonical URL and its metadata, and that Sharing Debugger can display that cached information or request another retrieval.

Check the preview again in the intended publishing flow. Avoid promising a fixed refresh time, and do not treat a successful Facebook check as confirmation of LinkedIn’s result. Record the platform tested and the time of the check so another teammate can reproduce it.

Keep tracking links, redirects, and canonical URLs straight

Troubleshooting becomes confusing when different people test different addresses. The editor might inspect the clean article URL while the scheduled post uses a short link that passes through a campaign redirect.

Record four things together:

1. The submitted URL: exactly what will appear in the post.
2. The final destination: where the request lands after redirects.
3. The declared page identity: the page’s og:url, plus its HTML canonical setting for the developer to compare.
4. The image URL: the resource the sharing metadata actually names.

For example, a campaign might share:

https://example.com/guides/product-demo?utm_source=linkedin&utm_medium=social

The page may identify its clean article address in og:url. That can be intentional. The useful check is whether both requests lead to the expected content and provide consistent metadata.

Do not add arbitrary query parameters simply to make a preview appear new. Platform treatment varies, and Meta explicitly documents use of the resolved canonical URL. Changing the visible link therefore does not establish that a new independent preview will be created.

Likewise, keep legitimate tracking parameters while investigating the actual publishing path. You can compare against the clean URL as a diagnostic test, but silently dropping tracking changes the campaign. Our guide to UTM tags and attribution mistakes covers how to keep those measurements organized.

If a redirect selects a language or region, inspect the version delivered to the crawler. The preview should describe the destination readers are intended to receive.

Handle an already-published post separately

Fixing the website and refreshing a preview helps prepare future shares. It does not guarantee a repair to every existing post.

LinkedIn is explicit: its Post Inspector guidance says the refreshed information applies to new posts, while existing previews remain unchanged. Its post-editing guidance also distinguishes editable text from shared media that cannot be replaced through an ordinary text edit.

Before deciding what to do, assess the consequence. An old decorative image may justify a different response from an expired price or a misleading event date. Check the editing options for that specific platform and post type, then choose an appropriate correction, clarification, or replacement.

If replacement is necessary, prepare and inspect the new version first. Keep a record of the original post and consider its comments, links, and any campaign dependencies. Do not expect a new post to inherit that history.

Worked example: the article is new, but the preview is old

A fictional software company updates a product-demo guide. Its webpage displays a new headline and illustration, but LinkedIn still shows a generic company image.

The editor inspects the exact tracked link. Post Inspector reports the intended article address, but its image field points to a default logo. That gives the developer a specific discrepancy to investigate.

The developer finds that the article’s sharing-image field was never set. The site’s template therefore outputs the default image even though the article body contains the new illustration. They set the correct sharing image, publish the page, and verify the resulting HTML.

The new artwork has its own stable public address. The developer confirms that it can be retrieved, then the editor inspects the article again and checks a fresh LinkedIn draft. The draft now shows the intended image.

An earlier LinkedIn post still displays the logo. The team records that as a separate existing-post issue and decides whether a replacement is warranted. They also test the Facebook draft before scheduling it.

The investigation worked because each check narrowed the problem: exact URL, image value, website output, platform refresh, and new draft.

Give your developer a reproducible handoff

Instead of sending only “the link preview is broken,” provide a short record:

Platform and publishing route:
Exact URL submitted, including tracking:
Expected title and image:
Actual title, image, or error:
Inspector result and screenshot:
When the page was last updated:
When the problem was reproduced:
Fresh draft or already-published post:
Live post URL, if relevant:

Ask them to compare the response, metadata, redirect path, and image access for that URL. When the issue is fixed, keep the successful inspection with the campaign’s review notes so everyone works from the same evidence.

Make preview checks part of the publishing handoff

Add one practical rule to your pre-publishing quality check: inspect important destination links after the final website changes and before approving the social post. Repeat the check if the page’s headline, offer, image, or address changes.

Postoria’s social media scheduler helps organize drafts, platform-specific versions, and scheduled posts in one calendar. Use that workflow to prepare the complete post once the destination has been checked. A scheduling tool’s draft preview is another review surface; the published website and destination platform still determine how a fetched link is interpreted.

For website-to-social automations, include sharing metadata in the website’s own release process. The page, public image, and intended destination should be ready when the publishing workflow encounters the link.

That turns preview repair into a traceable task: identify the wrong value, correct its source, verify retrieval, and check the actual post you are about to release.