Fixing your OG tags does not fix the preview you already shared. Set them before it goes out.

Meta caches preview images against the URL and LinkedIn refreshes only new posts, so the first share is the one you control. The four tags, per surface.

Last updated September 25, 2026

A preview is a separate artifact from the page

Paste a URL into a chat and the card that appears underneath it is not a small picture of your page. It is something the surface assembled from four tags it read in your HTML, at the moment somebody first sent that link.

What happens next is the part that costs money, and both Meta and LinkedIn document it plainly. Meta: “Images are cached based on the URL and won’t be updated unless the URL changes.” LinkedIn says the same thing from the other end, describing the limits of its own refresh tool: “The changes you make will only affect the URL’s preview image and information for new posts.” WhatsApp publishes nothing either way, and that silence turns out to matter more than either rule.

Read those two sentences together and the whole topic turns around. You can fix your tags this afternoon. On Meta’s surfaces that will not touch an image already cached against your URL, and on LinkedIn it will not touch a post that has already gone out. Those are finished objects, and the tags are the live part.

So this is pre-flight work, and nearly everything written about it is written as repair. Clear the failures that produce nothing at all first, because they are the ones no tool warns you about. Then the fields that are the wrong size. Then the image, once. Refresh tooling earns its place at the end, because by the time you reach for it you are already out of good options.

The failures that produce no preview and no error

Four tags do the work: og:title, og:description, og:url and og:image. Meta names all four as the basics for any shared content, and for WhatsApp specifically it requires the first three to sit inside the <head> tag and says they “should not be empty”.

Then there is the rule the guides leave out, and it is the interesting one: “The <head> containing the HTML mark-ups must appear within the first 300KB of the HTML.” Not the page. The first 300 kilobytes of the document.

View source on your own site and you will probably find a head measured in single kilobytes, which is why this rule reads like a formality. The heads that reach 300 kilobytes are the ones you would expect: inlined critical CSS, a tag manager, a consent script, a font loader and a preload block, with the Open Graph block added underneath all of it because that is the order the work happened in. Cross that line and the preview stops appearing, with nothing logged anywhere, on a page that renders perfectly in a browser. A head that has grown heavy enough to do this is also a render-blocking problem worth measuring properly.

The same reasoning kills the other common failure. That requirement is about the HTML the fetcher receives, not the page a browser eventually assembles, so tags written in by script after load are not in the document being read. Server-render them, or prerender them.

The third one is infrastructure, and it is worth knowing because it presents as a tag problem. The fetchers identify themselves. WhatsApp sends a User-Agent of WhatsApp/2.x.x.x A|I|N, where the letter is Android, iOS or web, and Meta’s crawler sends facebookexternalhit/1.1. A bot rule, a firewall or a hotlink protection that does not know those names blocks the fetch, and your tags are immaculate the entire time. LinkedIn names this cause itself: where an image meets every requirement and still will not appear, “your website may be blocking us from pulling the image or the image may be located on a protected directory or website”. Fetch your own page as those agents and read what comes back before you touch a single tag.

The description tag is an 80-character field

Here is the mismatch that produces a preview which is technically correct and still reads badly. Meta’s WhatsApp documentation describes the description as one or two lines with 80 characters recommended, and the title as bold across a maximum of two lines. A meta description written to fill a Google result runs to roughly twice that.

So a team that sets og:description to whatever the SEO plugin already had hands the card a sentence engineered for a search snippet, cut off mid-clause. The fact that would have earned the tap is in the half that did not survive.

Write the pair deliberately instead. The title earns the tap; the description carries the one thing the title could not. Both should read like something a person would actually send, because that is the context they turn up in. And front-load them, because everything past the cut may as well not exist.

Our SERP and Social Preview tool renders the Google result and the LinkedIn and X cards from a title and description you type, and shows where each one truncates. For the WhatsApp card your live page actually produces, run it through our Link Preview Checker.

One image, three sets of rules, one size that clears them all

The specs are published and they disagree, which is how a site ends up with an image that works on one surface and embarrasses it on another.

WhatsApp asks for an absolute URL, a file under 600KB, at least 300 pixels wide, and an aspect ratio no wider than 4:1. LinkedIn sets a 5 MB ceiling, a floor of 1200 × 627 pixels, and a recommended ratio of 1.91:1. Meta publishes a third set for Facebook sharing: a hard minimum of 200 × 200, at least 1200 × 630 recommended for high-resolution screens, and an aspect ratio kept as close to 1.91:1 as you can manage so the card is not cropped in a feed.

Stack all three and one file clears them: 1200 × 630, compressed to sit under 600KB. Note that the odd number in the set, LinkedIn’s 627-pixel floor, is a floor rather than a target, so 630 sits above it and matches Meta’s recommendation in the same file. Matching 627 exactly gains you nothing and costs you the recommendation.

Notice which half of that is the hard part. The dimensions are a decision you make once. The file size is the one you have to keep checking, and the format is what decides it: the same photographic card exported as a PNG at this width runs to several times the 600KB ceiling, where as a JPEG it sits comfortably inside. While you are in there, a warning about the guides: several of the OG-preview posts in circulation give WhatsApp’s image limit as 300 KB. The documented figure is 600KB, and building to a stricter number that nobody published costs you quality on every surface at once.

Two details get skipped, and both matter more than they look. Give the image a full URL with the domain in it, which is what the documentation asks for, because a relative path fails the requirement outright. Then declare og:image:width and og:image:height. Meta’s reason for those two is the whole argument for doing this early: “Specify height and width for your image to ensure that the image loads properly the first time it’s shared.” The first time is the share you do not get to redo.

A bilingual site needs a second set of tags, and a decision about the image

Open Graph tags live in a document, and a document is one URL. Run an Arabic side at its own URL and you have two sets of tags to write, and two 80-character descriptions to get right, in two languages, across every template.

The image is where this stops being a translation task. An og:image is a raster file, so any words in it are baked in at export, and Arabic and English do not share a glyph set, so there is no swapping one headline for another inside the same artwork the way two Latin-script languages would let you. A card designed in English, with the headline set into the image, renders in English on the Arabic page, underneath Arabic text, to a reader who is deciding in that exact second whether your site was built for them. Nothing in the spec catches it, because nothing in the spec is being broken.

Two ways out, and we would take the second. Export a second image per template with the Arabic treatment, and accept that you have doubled both the design work and the maintenance. Or design the OG image with no words in it at all and let og:title and og:description carry the language, which they were going to do on both sides anyway. The wordless version is cheaper, it never goes stale when a headline changes, and its cost does not move when a third language arrives, where the text-bearing version needs one more export per language, per template, indefinitely. Either way the Arabic side needs its own review cycle, the way the rest of that build does.

What each surface lets you refresh, and what it does not

Search this topic and the refresh tools are what comes back first. They are smaller than that billing suggests.

Facebook gives you the Sharing Debugger, and Meta states what it does beyond reporting: “The debugger also triggers a scrape of your page.” LinkedIn’s answer is the Post Inspector, which it describes as a way “to refresh the URL”, with the limit attached in the same breath. New posts only.

WhatsApp gives you nothing. Its documentation covers the requirements in real detail and says not one word about caching, expiry or refreshing, and neither Meta tool is documented to reach it. The sharing documentation that describes the Debugger does not mention WhatsApp anywhere. Which means the durations you will read everywhere, several days to weeks, 24 to 48 hours, LinkedIn’s widely repeated seven days, are not in anybody’s documentation. LinkedIn’s help page states no duration at all. Treat those numbers as folklore and plan without them.

That leaves the trick. Append a query parameter, ?v=2, and the surface treats it as a URL it has never seen. It works, and for the plainest possible reason: a different URL is a different URL, and Meta’s caching rule is keyed to exactly that. But look at what you are doing. WhatsApp’s documentation asks for an og:url that is “undecorated”, without session variables or user identifiers, and the fix decorates the URL to get around a cache. Two addresses for one page are now in circulation, and if campaign parameters are already being appended by whoever shares the link, those are splitting the same cache for their own reasons. If you build share links with parameters, build them somewhere you can see them, like our UTM Builder, and keep og:url pointing at the clean canonical whatever the shared address looks like.

Use the trick when you have to. Do not design as though you have it.

X, and the order to work in

X is the one surface where the honest answer is that the ground moved. The card reference the guides still cite, at developer.twitter.com, now redirects to the root of docs.x.com rather than to a card specification, and the validator at cards-dev.twitter.com sends you to a login screen instead of a preview. Both checked on 18 September 2026.

The practical read: keep twitter:card on the page, keep the Open Graph tags correct, and stop treating X as a surface you can verify. Guides will tell you X falls back to your og: values wherever the twitter: equivalents are missing, and that has held for years, but there is no live X document we can point you at that says so today. Correct Open Graph is what carries you there now. One good set of four tags will serve you better than four sets tuned per platform.

Then the order, cheapest and most decisive first:

Fetch your own page as both named agents and confirm HTML comes back, not a challenge page.
Confirm the four tags are in the served <head>, non-empty, and that the head lands inside the first 300KB.
Rewrite og:title and og:description for two lines and 80 characters instead of inheriting the search-engine versions.
Ship one image at 1200 × 630 under 600KB, absolute URL, with width and height declared.
Do all of it again for the Arabic URL, and settle the image question once.
Send yourself the link on every surface you actually use, before anybody else sends it.

Titles and descriptions that read well are also part of the foundations that decide whether the page gets found at all. A card nobody ever sees is a different problem with the same four tags underneath it.

Standing offer

The hard part is deciding what to do first

Bring us a URL, an audit report, or a proposal you're not sure about. We'll tell you which problems deserve budget this quarter, and you'll leave with an order of operations you can hand to whoever does the work, whether that's us or not.

Book twenty minutes