Wrong Image or Title When You Share a Link? Check These Four Things
A share card is wrong when the HTML, an inherited title, the image fetch, or the platform cache has not been checked. Four checks, in that order.
TechWebster5 min readDiscussion on DEV (opens in a new tab)
You share a page on LinkedIn or Facebook, and the preview shows an old title, the wrong image, or no image at all. The page looks fine in your browser. The preview was not built from that view.
A link preview is four steps. The platform fetches the URL you shared, reads the metadata in that response, fetches the image, and may reuse a card it stored earlier. A failure at any step produces the wrong card. The press below seats them in that order.
The check that has not seatedHomepage plate, an inherited cardImage plate, once the fetch is publicA preview is wrong when any one of the four has not seated. The title comes from the HTML response, not from the page you see in a browser. The homepage plate is an inherited card. The image has to answer as an image with no login. The slide is the platform cache: the inspector can still be holding the old card after the file is fixed.
Work through the four checks in order. The examples use placeholder URLs. Replace them with the deployed page and the image URL.
This is the closer look at check 4 of the five pre-launch SEO checks.
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 misses a problem on one article or product page.
A basic Open Graph set looks like this inside <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 the canonical page address for og:url, and a public absolute URL for og:image. Use article instead of website when the page is an article. The Open Graph protocol (opens in a new tab) defines the fields.
Fetch the deployed HTML without relying on JavaScript in your browser:
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'
-L follows redirects. Read the headers as well as the final status. A redirect to a login page, a challenge page, or the wrong route explains a missing preview. A 200 does not prove you received the page you meant.
Search the saved response for og:title, og:description, og:type, og:url, and og:image. That search is not an HTML validator. If a tag spans lines, read the file. Then compare it with the browser's rendered DOM. Tags that only appear after 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 treats known HTML-limited bots differently. Its documented behavior for facebookexternalhit places resolved metadata in the head before returning the page. A normal curl therefore does not always reproduce the crawler's response. Compare a second request with that user agent:
curl -sS -L --max-time 30 \
-A 'facebookexternalhit/1.1' \
-o /tmp/card-facebook.html \
'https://example.com/guides/launch'
That changes the user agent only. It does not reproduce the platform's network, cache, or full crawler. Use the Next.js metadata documentation (opens in a new tab) together with the platform's own inspector.
2. Look for conflicting or inherited values
A layout, a route, a CMS plugin, and a hand-written tag can each contribute metadata. Check the final response for the page, rather than assuming a config file tells the whole story.
Look for:
- A product page that inherits the homepage title or image.
- An old image URL emitted next to the one you intended.
- A canonical URL and an Open Graph URL that point at different pages.
- A nested route whose metadata differs from what you tested locally.
More than one og:image can be intentional. Open Graph allows a list and prefers the first value when they conflict. Remove the ones you did not mean, and put the preferred image first. Keep each image's width, height, type, and alt with that image.
In Next.js, nested openGraph objects merge shallowly between route segments. Defining openGraph in a child can replace fields from a parent. After an override, check that the page still has the image and description you intended. See the merging notes (opens in a new tab).
Checkpoint: after deployment, inspect the homepage and one nested page. Each should describe its own content.
3. Fetch the image without your login
Copy the final og:image URL and request it on its own:
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'
The response should be the image you meant, with a successful status and an image content type. An HTML error page saved under a .jpg name is still an error page. Open the downloaded file and confirm it.
A file you can see while signed in may depend on a session cookie. Expiring URLs, hotlink protection, a CDN rule, or a bot challenge can also stop the platform. An unauthenticated request is useful evidence. It does not guarantee the platform can reach the file.
Use a format the platform currently accepts, and stay inside its size and file limits. Keep text and logos away from the edges, because platforms crop differently. If you include og:image:width, og:image:height, or og:image:type, they have to match the file. Add useful og:image:alt text.
4. Check the platform's cached preview
Once the deployed HTML and the image are correct, inspect the same URL in the destination platform's tools:
These tools may ask you to sign in. Read any fetch errors and the values the platform detected. Where the tool offers it, request a fresh scrape after you deploy the fix.
If you replaced an image and kept its URL, your own CDN may still be serving the older file. Check that cache too. A new, stable filename can distinguish a new asset, but update og:image and recheck the page. A filename change on its own does not refresh a card.
Refreshing a preview does not guarantee that every existing post updates immediately. Platforms cache and display cards differently.
Avoid appending random query strings to every shared URL as a permanent workaround. That creates more URL variants and leaves the original problem in place.
A quick way to narrow it down
| What you see | Where to look first |
|---|---|
| The homepage card appears on every page | Route metadata, inherited defaults, and redirects |
| The title is right and the image is missing | The image URL, the response type, and crawler access |
| An old card after a deployment | The deployed HTML, the CDN cache, then the platform cache |
| Right in the browser, wrong in the inspector | The server response, the user agent, and access rules |
These are starting points. Write down the shared URL, the final redirected URL, the image URL, the deployment time, and the inspector result, so you can compare the same evidence after a fix.
SEO Analyzer reads a public page's metadata and social card before launch. Use it as a first pass, then confirm the result with the platform's own inspector.
For the wider launch review, go back to 5 SEO checks to run before launching.