Tutorials
Claude Opus 5.5 social preview checks for product links
Use Claude Opus 5.5 to compare the initial HTML, the referenced image and the sharing platform's observed card when a product link shows the wrong thumbnail.
Use Claude Opus 5.5 to compare the initial HTML, the referenced image and the sharing platform's observed card when a product link shows the wrong thumbnail. These are three different pieces of evidence. Changing the visible product photo does not prove that the link-preview metadata changed, and correct metadata does not prove that an older card has refreshed.
Locate the mismatch before editing
| Evidence | What it can establish | Next action |
|---|---|---|
| Initial HTML has the wrong `og:image` | The served metadata is wrong | Fix the route's metadata source |
| Metadata URL is correct but image response is wrong | The referenced resource is wrong | Repair that asset or its versioned URL |
| Both are correct, one platform remains stale | A consumer-specific issue is possible | Record the platform result and use its supported inspection route |
| Only the hydrated page looks correct | Browser UI and initial response differ | Inspect server output before changing the design |
The Open Graph protocol defines `og:title`, `og:type`, `og:image` and `og:url` as basic metadata. It also documents image dimensions and alternative text. The protocol describes metadata, not a universal cache lifetime or a guarantee that every service will render the same card.
A hypothetical wrong-color product card
Suppose an ivory cup page displays the correct cup, but sharing its link produces a blue cup. First save the initial HTML response for that exact URL and note redirects. If `og:image` still points at the blue image, the defect is in metadata generation. If it points at an ivory filename that actually returns blue pixels, investigate the asset. A filename is not proof of image contents.
Now suppose the initial response and image both match the ivory product, while one previously shared card stays blue. Record when and where the card was observed; keep the explanation provisional. A historical Stack Overflow question reports different preview behavior between services, but it does not establish their current caching policy. Do not promise a fixed refresh time or change page identity merely to chase a preview.
Create a small evidence bundle: requested URL, final URL, response status, initial metadata values, image status and content type, actual image dimensions, and a dated platform screenshot. Use only public product data. The example above is fictional and is not a measured Opus result.
A complete metadata review prompt
Audit this product link preview. Inputs: exact public URL, redirect chain, initial HTML response, extracted Open Graph tags, image response status/content type/dimensions, and a dated screenshot from the sharing service. Separate missing evidence from confirmed failures.
Compare product identity, title, description and image across these inputs. Detect duplicate or conflicting metadata and distinguish the initial server response from values inserted after JavaScript runs. Check whether the referenced image is publicly retrievable and depicts the intended product. Do not infer crawler access from my signed-in browser alone.
Return an evidence table, a ranked diagnosis and the smallest metadata or asset patch. Keep the canonical page identity stable unless there is an independent reason to change it. If only the sharing service remains stale, state the uncertainty and the supported next inspection step; do not invent a purge API or cache duration. Give verification steps for a fresh fetch and a new observed share without claiming either has already run.The official Opus guide supports providing context and specifying the desired output. This article supplies a review workflow, not a claim of native publishing or platform-cache control by the model.
Verify identity through the final response
After deploying the patch, fetch the public page again and inspect the initial tags and image response. Check that each product route has its own intended identity and that translated pages describe the appropriate language. Then observe a real share on the destination service. Keep server correctness and card refresh as separate results: one may pass while the other remains pending.
Common questions
**Is the browser tab title sufficient?** No. The visible title does not prove what the sharing service received in the initial response.
**Should I append random query strings everywhere?** Not as a blanket repair. Preserve page identity and use deliberate asset versioning when the asset actually changes.
**Can Opus force a social platform to refresh?** This workflow asks it to diagnose supplied evidence. Any actual inspection or refresh depends on the service's available tools and access.
Prepare the image before distributing the link
Create an approved product visual in Panelly Studio and keep it aligned with the product named in the metadata. For tracking parameters and destination changes, use the separate campaign link audit. No Opus integration or automatic social publishing by Panelly is asserted here.
