You send a customer a project page, but the preview shows an unrelated photograph. Or you share a new service on LinkedIn and the card still carries the old title. The page looks right when you open it, which makes the mismatch harder to explain.
Start by checking what the website supplies for sharing, whether the platform can retrieve the image, and whether it is displaying an older copy. Changing the visible page heading or uploading another photograph may leave the actual cause untouched.
This guide covers previews created when a website link is shared in a post or message. For descriptions beneath organic search results, see our guide to Google showing the wrong website description.
Record the exact link and the incorrect preview
Before editing anything, copy the address that produced the problem. Include any campaign parameters or shortened-link route. Open it while signed out of your website and record the final address after redirects.
Then capture the preview and note where it appeared: a newly composed post, an existing published post or a message. These give you different things to test. Also record the photograph and wording you expected.
Use a small comparison to narrow the work:
- One page is wrong: inspect that page’s sharing settings and image.
- Several unrelated pages show the same incorrect details: inspect the shared template or site-wide defaults.
- The page itself is outdated: establish that the intended website changes are live before investigating the platform’s copy.
These are starting points, not diagnoses. Keep the original URL throughout the investigation so you can prove that the link customers already use has improved.
Check the sharing metadata behind the page
A website can supply a separate title, description and image for shared links. LinkedIn’s URL troubleshooting guidance says it uses oEmbed and/or Open Graph information; missing information can result in absent or unintended preview content.
Ask your developer to inspect the published page’s HTML. The Open Graph protocol defines these core properties:
og:title: the title representing the page.og:type: the kind of content, such as a website or article.og:image: the URL of the image representing it.og:url: the canonical address identifying that content.
The protocol also recommends a short og:description and supports an image description through og:image:alt. Check that the values describe the particular page being shared.
Look for competing defaults
If the HTML contains several og:image values, inspect their order: the Open Graph specification gives the first preference during conflicts. Ask which part of the website outputs each value before removing anything.
On a WordPress site, have the developer check the relevant page fields, active plugins and theme output. A useful repair makes the source of the metadata clear to the person maintaining the site. Avoid adding another plugin simply to hide an unexplained conflict.
Choose an image that represents the destination
For example, a joinery business sharing a completed door installation should consider using a photograph of that installation. A generic workshop image may be suitable as a fallback, but it tells the customer less about the page they are about to open.
Check the actual file referenced by the sharing metadata. The photograph displayed prominently on the page and the image URL supplied for sharing should each be reviewed.
For LinkedIn, its website-sharing requirements currently list minimum dimensions of 1200 by 627 pixels, a maximum file size of 5 MB and a recommended ratio of 1.91:1. Use the sharing requirements when preparing a link image; the same help page also contains separate advert specifications.
Preview the composition at a small size. Keep the important subject clear and allow room around it for cropping. Do not rely on tiny text within the photograph to explain the offer.
Check that the platform can retrieve the page and image
LinkedIn’s website-sharing guidance also warns that an image can meet its requirements yet fail to appear because the website blocks retrieval or the image is protected.
As an initial check, open the exact image URL in a private browser window. Does it load directly, without requiring a website login? This checks public access from your browser; your developer should also investigate the platform’s requests.
Give the developer the failed URL and approximate test time. Ask them to examine the page request, the image request and any redirects, checking for access denials or challenges. That evidence should determine whether a targeted hosting or security-rule correction is needed.
For custom websites, check the response sent to crawlers
Ask the developer to confirm that the platform receives the metadata, rather than relying solely on what appears after the page finishes loading in a browser. For example, Next.js documents special handling for crawlers that expect metadata in the page head, including Slackbot. If your website uses that framework, the developer should check its metadata delivery against the version and configuration actually deployed.
Separate website caching from platform caching
Once the metadata and image are correct, establish which system still has the old information. Ask your developer to check the HTML and image served publicly, including any website or content-delivery cache involved.
Then test a newly composed share using the original URL. LinkedIn’s URL troubleshooting guidance explicitly describes outdated previews caused by cached information. Clearing your own browser history does not establish what LinkedIn has retrieved.
If the image contents have changed, ask whether the replacement should have a new image filename and whether the page’s metadata points to it. Keep that separate from changing the page address: creating a new customer-facing URL merely to obtain a different preview makes the original problem harder to verify.
Allow for the platform’s refresh process and record when each test was made. Avoid promising a precise update time across every sharing service.
Review existing posts separately
A successful new preview does not prove that an already published post has changed. LinkedIn’s shared-post editing guidance says post text can be edited, but shared rich media cannot be replaced and a new URL will not produce a new preview image through that edit.
Check the existing post before deciding what to do. If it contains a materially misleading offer or image, weigh a correction or replacement against losing its existing discussion and engagement.
If only one platform is affected, investigate that platform’s route
Repeat the test where customers actually share your links. A correct LinkedIn preview is useful evidence for LinkedIn; it does not verify a messaging app or another service.
For businesses using Slack, its link-unfurling documentation says the classic preview process reads Open Graph and X Card metadata when no app handler manages the domain. It also supports app-generated previews, so establish which route applies before changing website metadata to solve an integration problem.
If your team uses a scheduling or publishing tool, compare its preview with the platform’s own composer. Record where they differ and check any explicitly selected image in the publishing workflow.
Give your developer a focused repair brief
Send the original shared URL, the final destination, a screenshot of the incorrect card and the intended photograph and wording. Include whether the problem affects one page or many, and whether you tested a new share or an existing post.
Ask for a short explanation of the cause, the setting or code changed, and the evidence that the public page and image can now be retrieved correctly. If this involves template output or custom metadata delivery, BuzzBoost’s web development service covers this kind of technical website work.
Verify the preview and the customer journey
Before using the link in the next campaign or sales conversation, check:
- The original URL reaches the intended live page.
- The published sharing metadata contains the intended title, image URL and page identity.
- The referenced image loads publicly and meets the target platform’s requirements.
- A newly composed share on that platform shows an appropriate preview.
- Following the link reaches a page that matches the preview and offers a working next step, such as an enquiry or booking.
Save the test date and screenshots so the next person can distinguish a website regression from an old post. Add sharing checks to the release process for important service pages, case studies and campaigns.
If the preview still misrepresents your website, contact BuzzBoost with the affected link and an example. We can help identify the next technical step and check the route your customers use.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
