You paste your website into a message or a post and get a grey rectangle with no picture. It is not a mystery. Previews are built from a handful of tags in your page head, and platforms cache them hard.
Link previews come from Open Graph tags in your page head, and if the image is missing, one of five things is wrong. There is no og:image tag at all; the image URL is relative rather than absolute; the image is not publicly reachable; it is the wrong shape or too heavy; or the platform cached your page before you added the tags and is still showing you the old blank version.
That last one catches nearly everyone. You fix the tags, re-share the link, still see a grey box, and conclude the fix did not work. It did. The platform is showing you what it stored days ago, and it will keep doing that until you run the URL through its debugger and force a re-scrape.
We treat the share card as a launch requirement rather than a nice to have, because it is the first thing anyone sees of your site when someone recommends you.
Four tags do nearly all the work, and they live in the <head> of each page.
og:image is the picture. It must be an absolute URL starting with https://. A relative path such as /assets/preview.jpg works for a browser and fails for a platform fetching your page from somewhere else entirely. This is the single most common mistake.og:title is the headline on the card. Without it, platforms fall back to your page title, which is written for search results and often reads oddly in a message.og:description is the line underneath. Same fallback logic, same awkwardness when it is missing.og:url is the canonical address for the thing being shared, which keeps the preview consistent when a link picks up tracking parameters.Add twitter:card set to summary_large_image for the large format on X. Adding og:image:width and og:image:height helps platforms lay the card out before they have finished downloading the picture.
Roughly in order of how often each one turns out to be the real answer.
The most common reason a correct fix appears not to work. Platforms fetch once and hold on to what they found, sometimes for a long time. The tags are fine; you are looking at a memory. Use the platform's own debugger to force a fresh fetch.
Very common on older sites and hand built pages. Nothing to read means nothing to show, and the platform falls back to a bare grey box.
The tag says /assets/og.jpg. Your browser resolves that against your domain automatically. A platform fetching from its own servers has nothing to resolve it against. It must be the full https://yourdomain.com/assets/og.jpg.
Behind a login, on a staging server, blocked by hotlink protection, or sitting behind a firewall rule that treats unknown fetchers as bots. The test is simple and decisive: open the image URL in a private browser window with no session. If you cannot see it there, neither can the platform.
Wildly wrong ratios get cropped strangely or rejected. A very heavy file may time out on one platform while succeeding on another, which is why a link previews on WhatsApp and not on LinkedIn. 1200 by 630 and a sensible file size avoids all of it.
Platform fetchers read the HTML your server returns. They generally do not run your scripts. If the tags are injected client side, they may as well not exist. The check is to view page source, which shows what the server actually sent, rather than the inspector, which shows what the browser built afterwards.
Two plugins each writing og:image produce duplicate tags and unpredictable results. If you find two, that is your answer.
Right click, View Page Source, and use find. Not the inspector: the source, which shows what your server actually sent. No tag means you found the problem in ten seconds.
It must start with https:// and include your domain. If it starts with a slash, that is the bug.
No session, no cookies. If it does not load there, it is not publicly reachable, and no amount of tag fixing helps until it is.
1200 by 630 is the safe default. Check the important content is not near the edges, since platforms crop differently.
Facebook has a sharing debugger, LinkedIn a post inspector, X a card validator. They show you exactly what was fetched and, critically, let you force a re-scrape. This step is not optional after any change.
Paste the link into a message to yourself on WhatsApp, iMessage, Slack and LinkedIn. Each one is its own verdict, and they do not all agree.
Search the source for og:image again and count the results. More than one and something is writing them twice.
Honestly, this is one of the more approachable items in this section. If your site has a content management system with an SEO plugin, setting a share image may be a field in a panel. Bring someone in when:
We treat the share card as part of launching a site rather than something to notice later. It is the first impression every time someone recommends you in a message, and it is cheap to get right up front.
og:url, and no duplicate tagsAlmost always caching. Facebook, LinkedIn, X and the messaging apps fetch your page once, store what they find, and keep showing that stored version for a long time. If they cached your link before the tags existed, they are still showing you the blank version they saved.
Every major platform has a debugger or post inspector that re-fetches the page on demand. Run your URL through it, force a re-scrape, and the preview updates. Nothing else you change will show until you do.
1200 by 630 pixels is the widely used standard for the large preview card, and it is the safe default because it fits the roughly 1.91 to 1 ratio the big platforms expect. Keep the important content away from the edges, since different platforms crop differently. Keep the file reasonably light so it loads before anyone scrolls past, and use JPEG or PNG rather than anything exotic.
Add twitter:card set to summary_large_image and you get the large format rather than the small thumbnail. Beyond that, X falls back to your Open Graph tags for the title, description and image, so you do not need to duplicate everything. Open Graph is the one that carries the load across Facebook, LinkedIn, Slack, WhatsApp, iMessage and most other places your link gets pasted.
Each platform fetches independently, caches independently and has its own rules about file size, ratio and how patient it is. A slow image can be fetched fine by one and abandoned by another. Different results on different platforms usually mean your image is borderline rather than wrong: too heavy, too slow, or an odd ratio. Run the platform that fails through its own debugger and it will usually tell you exactly what it did not like.
Not directly. Open Graph tags are not ranking factors. What they affect is whether anyone clicks the link when it is shared, which is a real business outcome even if it never shows up in a ranking report. A blank grey box tells people nothing and looks abandoned. We treat it as a launch requirement for that reason, not an SEO one. For actual ranking work, see technical SEO.
Design and build a site that explains your business and brings in enquiries.
What to verify before and after a site goes live.
The crawling, indexing and structure work search engines depend on.
DNS, SSL, caching and protection, configured properly.
Decide whether to refresh, rebuild, or leave it alone.
The build itself: structure, code, forms, and the systems behind the pages.
Send us the URL. We will set the tags correctly, force the platforms to re-fetch, and show you the preview working on each one.