Why Your Link Preview Looks Wrong: Checking Open Graph Tags Before You Share
When a link is pasted into a chat app, a social feed, or a messaging thread, most people do not see a bare address. They see a preview card with a title, a short description, and often an image, and that card is built from tags in the page itself, not from the platform guessing. The Open Graph protocol defines those tags: og:title, og:description, og:image and og:url, among others. The Open Graph Checker reads a page's tags and shows what a preview would be built from, so a publisher can catch a missing image, a truncated title, or a wrong description before the link is shared widely. It checks the tags the page publishes; it cannot force any platform to use them, since each platform applies its own rules and caching.
The title tag deserves the first look, because it is the largest text on most preview cards. A good preview title matches the page's actual headline, reads as a complete thought on its own, and avoids being cut off mid-phrase on narrow cards. The description should summarise the page in one or two sentences, without repeating the title word for word, and without making promises the page does not keep. The image is what most people notice first, so it should be relevant, legible at small sizes, and hosted at an address the platform can fetch, since an image that fails to load leaves the card looking empty even when the text is perfect.
How it works
A checker fetches the page, parses its head section, and lists the Open Graph tags it finds, together with any that are missing or malformed. Common findings include a missing og:image, an image address that is relative rather than absolute, a title that is far longer than a card displays, and a description that is empty because the tag was never written. Some checkers also show the fallback behaviour: when Open Graph tags are absent, many platforms fall back to the page's HTML title and first paragraph, which may be a navigation label or a cookie notice rather than a summary, and that fallback is often the real explanation for a strange-looking preview.
How it works
Caching is the second half of the story, and it surprises more publishers than any tag error. Once a platform has fetched a page's preview, it may keep that preview for days, so fixing the tags does not immediately fix the card that people see. Most major platforms offer a debugger or refresh tool that re-fetches a page on demand, and using it after a fix is part of the job, not an optional extra. The checker itself only reports what the page currently publishes; the refresh step is what propagates the fix to the platforms that have already cached the old version.
Worked example
Worked example with sample values. Suppose a page publishes 4 Open Graph tags: og:title of 68 characters, og:description of 210 characters, og:image, and og:url. The checker runs 5 checks: title present, description present, image present, image address absolute, and URL canonical. It reports 2 findings: the description at 210 characters will be truncated on most cards, which typically show around 150 to 160 characters, and the image address is relative, so some platforms cannot fetch it. The other 3 checks pass, giving 3 passes out of 5 checks, or 60 percent passing. The fix is to shorten the description to 150 characters and to make the image address absolute, which would make all 5 checks pass. These are sample values for illustration.
Worked example
The same page also shows why the image dimensions matter. Suppose the image is 400 pixels wide and 300 pixels tall, a ratio of 4 to 3, while the platform's card crops images to a wider ratio, cutting the top and bottom of the picture. The subject of the photo, a person's face near the top of the frame, would be cropped out even though the image file itself is fine. Checking the image at the card's displayed size, rather than only confirming that the tag exists, catches this class of problem before the link is shared, and it is the reason a checker that shows a rendered preview is more useful than one that only lists tags.
Mistakes to avoid
One common mistake is writing different titles for the page and its preview, so the card promises something the page does not deliver, which erodes trust even when the click-through rate rises briefly. Another is using an image that contains small text, which becomes unreadable at card size, or an image with no relation to the content, which confuses readers. A third is forgetting that some pages should not have previews at all, such as private or internal pages, where a rich preview in a chat thread can leak information that the page itself was meant to restrict.
Mistakes to avoid
A further mistake is checking the tags once and assuming they stay correct. Templates change, images move, and content management updates can silently drop a tag or change an image address, so a preview that was correct at launch can break months later without anyone noticing. Re-check the most-shared pages after template changes, after migrations, and after any change to the image hosting setup, and keep a short list of the pages whose previews matter most so the re-check is quick rather than a full-site exercise.
Putting it into practice
Add a preview check to the publishing routine: before a page is announced, run the checker, confirm the title, description and image, and view the rendered preview at card size. After fixing any findings, refresh the cached preview on the platforms where the link will be shared. Record the agreed title and description length limits for the site, so every author works to the same constraints, and re-check the top shared pages whenever the template or image hosting changes. A correct preview is a small detail, but it is the first thing most readers ever see of a page.
Related tools and reading: Related tools and reading: the Social Card Preview and the Metatag Length Checker cover neighbouring checks that pair naturally with this one, and the guide at [/blog/website-seo-audit-guide/] extends the same topic with further background and examples for readers who want to go deeper.
Key points
- Preview cards are built from Open Graph tags, not from platform guesswork
- Check the title, description, image address and URL, not just one of them
- Platform caches keep old previews, so refresh after fixing tags
- View the image at card size, since cropping can remove the subject
In short: p.review cards are built from Open Graph tags, not from platform guesswork
One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.