Wrong Image or Title When You Share a Link? Check These Four Things

You share a page on LinkedIn or Facebook, but the preview shows an old title, the wrong image, or no image at all. The page looks fine in your browser. What should you check next?

A link preview depends on several steps: the platform fetches the shared URL, reads its metadata, fetches the image, and may reuse a cached result. A failure at any step can produce the wrong card.

Work through these four checks in order. The examples below use placeholder URLs: replace them with your deployed page and image URLs.

1. Check the metadata in the HTML response

Start with the exact URL you are sharing, including its path and any query parameters. Checking only the homepage can miss a problem on an individual article or product page.

A basic Open Graph configuration looks like this inside the document's <head>:

<meta property="og:title" content="A useful page title">
<meta property="og:description" content="A short, accurate summary of this page.">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/guides/launch">
<meta property="og:image" content="https://example.com/images/launch-card.jpg">
<meta property="og:image:alt" content="An illustrated checklist for launching a website">

Use your intended canonical page address for og:url and a public, absolute URL for og:image. Use article instead of website when describing an article. The Open Graph specification defines the fields and optional image properties.

Fetch the deployed HTML without relying on your browser's JavaScript:

curl -sS -L --max-time 30 \
  -D /tmp/card-headers.txt \
  -o /tmp/card.html \
  -w 'Final URL: %{url_effective}\nStatus: %{http_code}\n' \
  'https://example.com/guides/launch'

cat /tmp/card-headers.txt
grep -iE 'og:(title|description|type|url|image)' /tmp/card.html

-L follows redirects. Inspect the headers as well as the final status: a redirect to a login page, a challenge page, or the wrong route can explain a missing preview. A 200 response alone does not prove that you received the intended page.

The grep command is a quick search, not an HTML validator. Inspect the full saved response if tags span multiple lines or the result is unclear. Compare it with the browser's rendered DOM. Tags added only by client-side JavaScript may be absent from the response a preview crawler reads.

Next.js detail: metadata can stream for ordinary clients, while Next.js handles known HTML-limited bots differently. For example, its documented behavior for facebookexternalhit places resolved metadata in the head before returning the page. A normal curl request therefore does not always reproduce the crawler's response. You can compare a second request:

curl -sS -L --max-time 30 \
  -A 'facebookexternalhit/1.1' \
  -o /tmp/card-facebook.html \
  'https://example.com/guides/launch'

This changes the user agent only. It does not reproduce the platform's network, cache, or full crawler behavior. Use the Next.js metadata documentation and the platform inspector together.

2. Look for conflicting or inherited values

A layout, route, CMS plugin, and manually written tag can each contribute metadata. Check the final response for the page, rather than assuming a configuration file tells the whole story.

Look for:

• A product page that inherits the homepage title or image.
• An old image URL emitted alongside the intended one.
• Different canonical and Open Graph URLs pointing at unintended pages.
• A nested route whose metadata differs from what you tested locally.

Multiple og:image tags can be intentional; Open Graph supports arrays and gives preference to the first value when conflicts occur. Remove unintended duplicates and put the preferred image first. Associate each image's structured properties with that image.

In Next.js, nested metadata such as openGraph uses shallow merging between route segments. Defining openGraph in a child segment can replace fields supplied by a parent. Check that your page still includes its intended image and description after an override. See the merging documentation.

Checkpoint: inspect both the homepage and one nested page after deployment. Each should describe its own content.

3. Fetch the image without your login

Copy the final og:image URL and request it separately:

curl -sS -L --max-time 30 \
  -D /tmp/card-image-headers.txt \
  -o /tmp/card-image \
  -w 'Final URL: %{url_effective}\nStatus: %{http_code}\nType: %{content_type}\n' \
  'https://example.com/images/launch-card.jpg'

cat /tmp/card-image-headers.txt
file /tmp/card-image

Check that the response contains the intended image, with a successful status and an appropriate image content type. An HTML error page saved with a .jpg name is still an error page.

A file visible in your signed-in browser may depend on a session cookie. Expiring image URLs, hotlink protection, CDN rules, or bot challenges can also prevent a platform from fetching it. Check crawler access to both the page and image; an unauthenticated curl request is useful evidence, but it cannot guarantee that the platform can reach them.

Use a supported image format and the target platform's current size and file limits. Keep important text and logos away from the edges because platforms may crop differently. If you include og:image:width, og:image:height, or og:image:type, make them match the actual file. Add useful og:image:alt text.

Checkpoint: open the downloaded file and confirm it is the image you intended to share.

4. Check the platform's cached preview

Once the deployed HTML and image are correct, inspect the same shared URL using the destination platform's tools:

• LinkedIn Post Inspector
• Facebook Sharing Debugger

These tools may require sign-in. Review any fetch errors and the values the platform detected. Where offered, request a fresh scrape or inspection after deploying your fix.

If you replaced an image while keeping its URL, your own CDN may still serve an older file. Check that cache too. A new, stable image filename can help distinguish a new asset, but update og:image and recheck the page rather than relying on a filename change alone.

Refreshing a preview does not guarantee that every existing post will update immediately. Platforms can cache and display cards differently.

Avoid appending random query strings to every shared page URL as a permanent workaround. That can create more URL variants while leaving the original issue unresolved.

A quick way to narrow it down

What you see	Where to investigate first
Homepage card appears on every page	Route metadata, inherited defaults, and redirects
Correct title, missing image	Image URL, response type, and crawler access
Old card after a deployment	Deployed HTML, CDN caches, then platform cache
Correct in browser, wrong in inspector	Server response, user-agent differences, and access rules

These are starting points, not definitive diagnoses. Record the shared URL, final redirected URL, image URL, deployment time, and inspector result so you can compare the same evidence after a fix.

At TechWebster, we built SEO By TechWebster to help inspect metadata and social-card setup before launch. Use it as an initial check, then confirm the result with the destination platform's own inspector.

For a wider launch review, see 5 SEO Checks to Run Before Launching Your Website.

Which preview problem have you run into most often: the wrong title, a missing image, or a card that refuses to refresh?