Your WordPress page has the right photograph, but its link preview still shows an old logo, an unrelated image or nothing at all. Changing the featured image again may not help: the visible page, its sharing metadata, the image file and the receiving service can each hold a different version.
Start by identifying the first place where the image becomes wrong. If WordPress serves the wrong image address, refreshing a messaging app cannot correct it. If the website already serves the right metadata and file, rewriting your SEO title or changing your page URL is unnecessary.
This guide is for an owner checking a public business page or article. It is not a promise that every messaging service uses identical previews, and the diagnostic tables below are proposed checks, not results from a client incident.
Find which layer owns the wrong preview
Record the exact public URL you shared, the expected image and where the preview is wrong. Include whether this is a newly pasted link or a message sent before the edit. A screenshot of the card and the time you changed the page give a developer a useful starting point.
| Observation | First layer to inspect | Smallest useful next check |
|---|---|---|
| The public page itself still has the old image | Saved page content, template or website cache | Compare the saved page with a fresh logged-out view of that exact URL |
| The page looks right, but its sharing image address is old | The page’s Open Graph metadata and cached HTML | Check the per-page social image and the served og:image value |
| The sharing address is right, but opening that image shows old artwork | The image file or its CDN cache | Open the exact image URL, not a different Media Library thumbnail |
| The image needs a login or returns an error | Image access, delivery or a request-specific restriction | Have the responsible developer inspect the failed fetch without disabling protection sitewide |
| The page, metadata and image are right, but one service shows an older card | The receiving service’s cached preview | Use that service’s supported refresh method and compare a newly created preview |
These observations narrow the investigation. They do not prove that a particular plugin, CDN or messaging app is faulty. Keep the same URL throughout the comparison so that a redirected homepage is not mistaken for the article you meant to share.
Check the public page before changing SEO fields
Open the page while logged out. Confirm its final address after any redirects, visible image and intended audience. If the page still looks old, solve that first. Our WordPress changes not showing guide helps distinguish a saved-content problem from stale output.
A featured image and a per-page sharing image are not the same editing decision. A deliberately selected social image can differ from the picture in the article. Check whether someone previously chose a separate image before replacing assets across the Media Library.
Keep Google snippets separate too. A link-preview repair is not a reason to change your canonical address, indexability, original publication date or search-focused title. Those fields have different responsibilities. Preserve strong search metadata unless you have a separate, supported reason to edit it.
Inspect the sharing image the website actually serves
Open Graph tags describe a page for sharing. Yoast’s Open Graph documentation explains its native output and warns that competing plugins can emit conflicting tags. Adding a second SEO plugin is therefore not a reliable fix.
Ask your developer to inspect the public page source for og:image, og:title and og:url. The useful evidence is the served value, not just a correct-looking editor preview. If the image address is wrong, inspect the responsible page’s native social settings and check for competing output.
If two components generate contradictory metadata, establish which one should own it. Preserve their existing settings before making a narrow correction. Do not deactivate a business-critical plugin on the live site just to see whether a thumbnail changes.
A visitor can see a fresh page while another request receives older HTML. Compare the clean public URL after the site’s normal cache refresh. A cache-busted developer check is useful diagnostic evidence, but it is not the final acceptance test: customers will share the normal address.
Follow the exact image address
Open the address from og:image in a logged-out browser. Does it show the expected artwork? Does it load without a login, broken-file icon or error page? A Media Library preview of another size is not enough to answer this question.
If a file was replaced while keeping the same address, record that fact. The page metadata may be current while the image response is stale. Have the image-delivery owner refresh that specific asset through the supported cache process. Avoid deleting every attachment or changing every filename to solve one preview.
A successful browser load does not prove that a receiving service can fetch the image. If its diagnostic tool reports an access failure, ask the hosting or security owner to inspect that request. Do not disable the firewall, remove all bot protections or publish a private asset as a shortcut.
Refresh the receiving preview only after the website is correct
For Facebook, Yoast documents a supported sequence using the Sharing Debugger and Scrape Again. Review its refreshed preview, warnings and received tags. A refresh that still receives the wrong tags points back to the website rather than another round of blind cache clearing.
Only submit a URL that is already intended to be public. Do not paste a private staging address, customer document, signed download link or URL containing credentials into an external debugger.
Other services can have different refresh controls and caching behaviour. Use the relevant service’s current official guidance. Compare a new preview separately from an already-sent message, and do not promise that older messages will all redraw immediately. A correct Facebook result alone is not proof that every other destination has refreshed.
Use a stop rule instead of endless cache purges
| Checkpoint | Accept when | Stop and escalate when |
|---|---|---|
| Website ownership | The correct page and intended social image are saved by the responsible component | Two plugins or templates claim ownership and their output conflicts |
| Normal public URL | Clean, logged-out HTML contains the intended sharing values after the supported refresh | Different requests receive contradictory values or an unexpected destination |
| Exact image file | The intended public image loads at the address supplied in the metadata | The file is private, blocked, missing or still contains old artwork |
| Receiving service | A fresh preview shows the expected card or a specific remaining limitation is recorded | A supported refresh fails despite correct website evidence |
| Unrelated page behaviour | The page, navigation and enquiry path still work, with search settings unchanged | The proposed fix requires broad security, URL or template changes |
Keep a short repair record: public page URL, expected image address, metadata observed, cache refreshed, destination tested and anything still unknown. That record makes a follow-up useful without exposing private logs or repeating changes that already passed.
When a focused WordPress repair makes sense
You can usually collect the URL, expected image and failing preview yourself. Get help when metadata has competing owners, image delivery behaves differently for outside fetches, or a shared template generates the wrong card across many pages.
Webless’s WordPress development services are a relevant route for tracing that ownership and making a controlled repair. Broader image SEO and performance checks remain useful, but they should not replace diagnosis of the specific broken preview.