Because the page never told the platform what picture to use. When no Open Graph image is set, a social platform guesses. It grabs a logo, a random photo, or nothing at all, and your link shows up as a grey box with a URL under it. The fix is a deliberate image on every page.
This is one of the cheapest wins in web design and one of the most commonly skipped. Someone spends six weeks on a landing page, then posts it in a Slack channel, and the preview shows a cropped fragment of a stock photo with half a face in it. The page is fine. The first impression is not.
A share image is not decoration. For a lot of people it is the only part of your page they will ever see, because most posts get scrolled past rather than clicked.
It is the picture a platform shows when your link is posted. The Open Graph protocol defines it as og:image, one of four required properties alongside og:title, og:type, and og:url. You add these as meta tags in the page head, and the platform reads them when it unfurls your link.
The protocol itself is documented at ogp.me, which describes it as a way for any web page to become a rich object in a social graph. It was originally created by Facebook and, as the specification notes, drew on Dublin Core, link-rel canonical, Microformats, and RDFa. Developer simplicity is listed as one of its stated goals.
Beyond the basic image URL, the protocol defines structured properties worth knowing. There is og:image:width and og:image:height, which help a platform lay out the preview before the file finishes downloading. There is og:image:type for the MIME type, og:image:secure_url for an HTTPS version, and og:image:alt for a text description of what the picture shows.
We treat og:image:alt as non-optional even though the specification calls it optional. Someone using a screen reader on a social platform gets the alt text and nothing else. Leaving it blank means your link is genuinely unreadable to them.
Use 1200 by 630 pixels. Meta's own sharing documentation recommends exactly that, with a minimum of 200 by 200 pixels and a note that anything under 600 by 315 will still display but appear noticeably smaller in link posts. Meta also states that the image file must not exceed 8 MB.
The shape matters as much as the pixel count. Meta's guidance is to keep images as close to a 1.91:1 aspect ratio as possible so the full image displays in feed without any cropping. That ratio is where 1200 by 630 comes from, and it is why a square image gets sliced at the top and bottom on some surfaces.
File size deserves more attention than the 8 MB ceiling suggests. That is a hard limit, not a target. A well-compressed share image should land far below it, because the platform has to fetch your image before it can render the preview, and a slow fetch sometimes means no preview at all.
Design at 1200 by 630 and then check it small. Most people will see this image at a fraction of its real size, in a feed, on a phone, moving past at speed. If it does not read as a thumbnail, the resolution does not save it.
Because the image gets displayed tiny. A 1200 pixel wide graphic might render at 300 pixels on a phone, which shrinks your type to a quarter of its designed size. Body copy at that scale becomes texture rather than text. Only a short headline in very large type survives the trip.
Our working limit is around six words. If the headline needs more than that, the image is doing the wrong job. The full explanation belongs in the post copy and on the page itself, both of which have room. The image only has to make somebody stop scrolling.
Contrast does most of the remaining work. Text sitting on a busy photograph disappears at thumbnail size no matter how large the type is. A solid background, or a photo with a strong colour overlay behind the text, keeps the words legible in both light and dark interfaces. The same typographic thinking we describe in our guide to choosing fonts for a website applies here, just with far less margin for error.
Watch the edges as well. Different platforms crop slightly differently, so anything important close to the border is at risk. We keep logos and text well inside that boundary and treat the outer band as sacrificial.
Every page that people share should. That means the homepage, every landing page, every blog post, every case study, and every pricing or product page. Pages nobody links to, like a thank you page or a privacy policy, can safely fall back to a site default.
A single site-wide image is better than nothing and worse than it looks. When five different articles all preview with the same brand graphic, they stop being distinguishable in a feed, and a reader who already ignored one will ignore the rest. The image is a signal, and repeating it drains the signal.
The pragmatic middle ground is a per-page image for anything you actively promote and a good default for everything else. Make the default specific to the site rather than a bare logo on white, because a logo tells a scroller nothing they did not already know from the domain name.
Build a template and fill it from the page content. The usual approach is a single layout with a headline slot, a category label, and brand styling, rendered on the fly for each URL or generated at build time. It gives every page a unique, on-brand image without a designer touching each one.
In Webflow, the simplest version of this uses a CMS image field on the collection, so each post carries its own share image and the page settings pull it into og:image. That keeps the control with the content team and needs no code, at the cost of somebody having to produce the artwork.
The fully automated version renders the image from a template using the post title and category, which scales to hundreds of pages and costs nothing per post. The trade-off is that every image looks like a variation on one design, which is fine for a blog archive and weak for a flagship launch page.
Our practical split is to automate the long tail and hand-design the top ten pages. Automation gets the blog past the grey-box problem. The pages that carry real campaign spend get an image somebody actually thought about.
Not through og:image directly, but image quality does matter for Google surfaces. Google's Discover documentation recommends using large images at least 1200 px wide, enabled by the max-image-preview:large setting or by using AMP. It also advises using images that are relevant and representative of the web page.
Google is specific about what not to do. The Discover guidance warns against generic images such as site logos, which is the same mistake people make with a site-wide default share image. An image that could belong to any page on your site is an image Google has been told to treat as weak.
So the two goals line up. A distinctive, page-specific, large image serves the social preview and the Google Discover preview at once, and the meta description work you already do for search sits alongside it. We covered that side of the pairing in our guide to writing title tags and meta descriptions.
What we would not do is design the share image for Google. The audiences behave differently, and a picture built to satisfy a crawler tends to satisfy nobody. Design it for a human scrolling a feed and the search benefit follows.
Specificity. An image that names the exact thing the page delivers beats an abstract brand graphic almost every time, because the scroller can tell in half a second whether the page is for them. Vague images ask people to click to find out, and most people will not.
The second factor is difference. A feed is a competition for attention against everything else in it, and most of that content is photographs of people. A flat colour field with type on it stands out precisely because it does not look like the rest of the feed, which is one reason the format has spread so widely.
Consistency is the third, and it works over a longer horizon. When every post from a site shares a recognisable visual system, regular readers start recognising you before they read the words. That only pays off if you keep the system stable for months rather than redesigning it every quarter.
Where we disagree with common practice is on faces. Plenty of advice says put a human face in every image because faces attract attention. In a feed already full of faces, a face is camouflage. We would rather use the space for a sentence people can read. The wider question of when photography earns its place is one we worked through in our piece on choosing photography and images for a website.
Post the URL somewhere private and look at it. Paste it into a direct message, a private channel, or a draft post, and see what actually renders. Platforms cache aggressively, so testing after launch means living with a bad preview until the cache clears.
Check more than one surface. The same link unfurls differently in a chat app, a feed, and a preview card, and an image that reads well in one can be badly cropped in another. Looking at two or three covers most of what your audience will see.
Verify the tags are actually in the served HTML too. If your page renders with JavaScript, meta tags added after load will not be there when a platform fetches the page, because most unfurlers do not run scripts. The tag has to be in the HTML that arrives on the first request.
Finally, view it at thumbnail size on a phone rather than full size on a monitor. Almost every share image we have rejected looked perfectly good at 100 percent and fell apart at the size real people see.
Start with the five URLs you share most. Check what each one currently previews as, and fix any that show a grey box, a bare logo, or a badly cropped photo. That is usually an hour of work and it improves every future share of those pages permanently.
After that, set a sensible site-wide default so nothing ever falls through to nothing, and add og:image:alt while you are in there. Then decide whether your blog needs a generated template, which is worth doing once you are publishing regularly enough that manual artwork becomes the bottleneck.
If you want help designing a share image system that holds up across a whole site, let's talk. We enjoy this kind of problem and it usually takes less time than people expect. You can reach us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.