Skip to content

Provenance

Share preview integrity: does the card match the page?

By Hannah Voss, Editor · Reviewed September 2026 · 7 min read

Quick answer

A share preview has integrity when the card a network shows matches the page it links to: same title, same image, same disclosure line, same author. Test each network with its sharing debugger and a logged-out account, log what the card showed and what the image file carried, and repeat after every theme, CDN or plugin change.

A cut-paper link preview card with a grey landscape panel, two blank text bars and a small embossed seal in one corner
What a network reads to build a link preview, and the card it produces01Page headog:title, og:image02Image filefetched, re-encoded03Author signalsmeta, creator tags04Label linein the description05Cardbuilt by the network
Everything before the last panel is yours to set. The network assembles the card, caches it and shows it on its own terms.

When a reader shares your address, the network fetches the page once, reads a handful of head tags and builds a card. The Open Graph protocol defines the core set: og:title, og:description, og:image and og:url, with og:image:width and og:image:height as helpers. Some networks read their own tags first, such as twitter:card, then fall back to Open Graph. The guide to setting Open Graph tags in WordPress covers which plugin prints them and how to keep one source of truth.

Two more inputs matter for provenance. The image named in og:image is downloaded and usually re-encoded, which decides whether any metadata in it survives. Author signals in the head, the author meta tag and fediverse:creator, are read by the networks that support them, as the guide to authorship tags for shared links explains. A disclosure line reaches the card only from the title or description, the only text fields a card shows.

The four things that drift

A card can stop matching the page in four ways, each with a different cause. A cached title or image shows the page as it was when the network first fetched it, before an edit, a featured image swap or a correction. A re-encoded image looks the same but has lost its metadata, so any credential or source type is gone. A stripped disclosure line happens when a description is cut short or not shown at all. A missing author happens when the head tags are absent, printed twice with different values, or not yet approved by the author on the network's side.

The first drift is the one readers notice and report as Facebook showing the wrong image. The other three are quiet: a reader sees a clean card with no disclosure and no author and cannot know either was ever there. So the test below inspects the file and the author line as well.

Share preview integrity, network by network

  1. Pick a fresh address

    Use a new post, or an existing address with a harmless query string such as ?v=3. Networks cache cards by exact address, so an old address shows old results.

  2. Run the network's sharing debugger

    Paste the address into the debugger or inspector each network offers and note the title, description, image and any warnings. The LinkedIn Post Inspector and Facebook's sharing debugger are the two most used; Mastodon has none, so use a real share.

  3. Share from a logged-out or secondary account

    Debuggers show what the fetcher read; a real share shows what a reader sees, including layout, crop and truncation. Use a phone for at least one network, because crop and visible description length differ at phone width.

  4. Download the preview image

    Save the file the network is serving and inspect it with a metadata reader and a C2PA reader. Compare its size and fields with the file at your og:image address.

  5. Compare the four fields with the page

    Title, image, disclosure line and author. Mark each one as matched, cached, cut or missing. Anything other than matched gets a cause and a fix from the table below.

  6. Log it, then refetch

    One row per network in the share test log below, written at the time. After fixing the page, use the debugger's scrape-again action and repeat the check on the same address.

Drift, cause and fix

DriftUsual causeHow to confirmFix
Old title or image on the cardNetwork cache from an earlier fetchDebugger fetch time is before your editScrape again; share a fresh address
Right picture, metadata goneNetwork re-encoded og:imageDownloaded preview is smaller, no fieldsKeep credentials on the page
Disclosure line missingDescription cut, or network shows noneReal share on a phone shows truncationPut the line in the first 100 characters or the title
Author not shownTag absent, duplicated or not approvedView source; ask the author about approvalOne plugin prints the tag; author approves the domain
Wrong image entirelyTheme or plugin picked a different og:imageog:image address differs from the featured imageSet the share image explicitly in the SEO plugin

A worked example: 20 posts on four networks

Suppose an editor runs the routine on 20 recent posts across four networks, which gives 80 cards. The counts are invented for this example, but the mix is typical. In the example, 69 cards match the page on all four fields. Six show a stale title or image, all on posts edited after first share; a scrape-again fixes every one. Three lose the disclosure line because one network cuts descriptions at about 100 characters and the line sat at the end. Two fediverse cards show no author because a guest writer has not approved the domain.

Separately, all 80 downloaded preview images have lost their metadata, including the 12 that carried a valid Content Credential at the og:image address. The editor records that as expected rather than drift and relies on the page for credentials, as the guide to Content Credentials on shared images recommends. The fixes: descriptions rewritten with the line first, on the pattern in disclosure lines that survive a share, and one message to the guest writer.

The share test log

The log has five columns and one row per network per page, plus a matched column with one of four values: matched, cached, cut, missing. Keep it as a spreadsheet or a text file; what matters is that a row is written at the time of the test and never edited afterwards.

page, network, time_utc, preview_showed, file_carried, matched, notes
/2026/09/harbour-report/, Facebook, 2026-09-22 09:14, title + description + 1200x630 crop, no metadata, matched,
/2026/09/harbour-report/, LinkedIn, 2026-09-22 09:31, description cut at ~140 chars, no metadata, cut, move line to start
/2026/09/harbour-report/, Mastodon, 2026-09-22 09:20, card + author line, no metadata, matched,

A regression habit

Cards break silently when the site changes, so run the routine on three posts, one per author type, after any of these events: a theme switch or update; an SEO plugin update or a change to its share image settings; an image optimiser or CDN change, including a new format; a thumbnail regeneration; a domain, path or HTTPS change; and a change to how bylines or user profiles are stored. Once a quarter, run it on a sample regardless, because card layouts change without notice. Keep one post per network as the regression address, with a query string you increment.

Pitfalls

  • Testing while logged in as an admin. Some caching and membership plugins serve logged-in users a different page with different tags.
  • Reading the debugger's cached result as a fresh fetch. Check its fetch time.
  • Assuming a metadata-free preview image is a fault in your stack. Check the file at your own og:image address first; if that carries the fields, the network re-encoded it.

This is the card side of a wider set of checks; the provenance section covers the file, the byline and the disclosure policy.

Sources

Questions

Why does my link preview not match the page?

Usually the network cached the card from an earlier fetch. Scrape the address again in the sharing debugger and share a fresh address to confirm. If the image is still wrong, your theme or SEO plugin is choosing a different og:image.

How do I clear the og image cache?

Each network has its own cache. Fetch the address again in its sharing debugger, or share the address with a harmless query string appended so the network treats it as new.

Why does the preview show the wrong author?

Two plugins may print author tags with different values, or the tag names a publication account. View the page source for duplicate author, twitter:creator or fediverse:creator tags and keep one.

What should a preview test log contain?

Page, network, time, what the preview showed and what the image file carried, plus a matched or drifted flag. One row per network per page, written at the time.

Does the share image keep its Content Credentials?

Typically not. Networks re-encode the og:image they fetch, which removes embedded metadata. Keep the credential on the page.

Share this guide

Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.

  1. Content Credentials on shared images: what survives a shareWhat C2PA Content Credentials are, why WordPress image sizes and social uploads often strip them, and how to keep provenance on the images you share.6 min read
  2. AI disclosure lines that survive a shareWhere to put an AI assistance disclosure so it reaches readers who only see the share card: titles, descriptions, bylines and the first lines of a post.5 min read
  3. Authorship tags for shared links: author, article:author and fediverse:creatorAdd authorship signals to link previews: the author meta tag, article:author, twitter:creator and fediverse:creator, with WordPress code and testing steps.6 min read