A quote is ready, the site is live, someone drops the link into a group – and instead of an inviting card there is only a bare address with a grey placeholder. The first impression of a website today often forms not on the page itself but in the chat bubble or feed where the link is shared. Whether a large preview image with a title and a small brand symbol appears there, or just a pale line of text, is decided by the Open Graph markup in the page head together with a properly set favicon. This article shows how the preview is produced, which entries create a preview image, a title and a card in the chat, how large the image has to be and why a preview that once loaded wrong tends to stick stubbornly. The focus is explicitly on how a link looks when shared – not on the entry in Google search, which a separate article covers.
What actually happens when you share
When a link is pasted into a messenger or a social network, the app quietly fetches the page in the background, reads the document head and looks for special meta entries. If it finds a preview image, a title and a description, it builds a card from them: a large image, the headline below it, the domain and often a small brand symbol. If those entries are missing, only the bare address or a grey placeholder remains. This preview is called a link preview or unfurl, and its language is the Open Graph protocol. The reach is considerable: around 90 percent of internet users in Germany use messengers (Bitkom), and about two thirds are active on social networks (Bitkom). That is exactly where shared links land – in personal recommendations, team chats and posts. Anyone who wants a click to follow should not leave the card to chance. How enquiries then reliably reach the inbox is a topic of its own, covered in the article on business email deliverability.
The distinction from Google search matters. There, the page title and meta description decide how the entry looks in the results list – a different channel with its own rules, covered in depth by the article on titles and descriptions in search results. When sharing, by contrast, the Open Graph image is what counts, and the two channels can look entirely different. A page can be flawless in search and still show nothing but a grey box when shared, because the preview image is missing. Both representations therefore want to be checked separately.
Open Graph: the building blocks of the preview
The Open Graph protocol is a small, long-established set of meta entries in the head of an HTML page. Each entry consists of a property and a value, such as the title, the description or the image address. Adoption is high but patchy: Open Graph is set on around 64 percent of pages (Web Almanac 2024), yet the decisive preview image og:image on only about 48 percent (Web Almanac 2024). Put differently, almost every second page gives away the most eye-catching part of the card. And it is only a handful of lines that make the difference between an inviting preview and a pale line of text. The most important building blocks are quickly named.
og:title
The card headline. Short and specific, usually 40 to 65 characters so it is not cut off mid-sentence.
og:description
One or two sentences below the title. They explain the value of the link; not every platform shows them.
og:image
The large preview image. If it is missing, only a grey box remains – the most eye-catching and most often forgotten block.
og:url
The canonical address of the page. It keeps the preview stable even when the shared link carries parameters.
og:type
The kind of content, such as website or article. It classifies the page and drives additional fields.
og:site_name
The name of the website. It appears as the source next to or beneath the card title.
<!-- Open Graph for the link preview -->
<meta property="og:title" content="Sample Trades - extensions and renovation" />
<meta property="og:description" content="Local trade business for extensions, renovation and fit-out. Send an enquiry in two minutes." />
<meta property="og:image" content="https://www.sample-trades.com/preview.jpg" />
<meta property="og:image:alt" content="The Sample Trades team in front of a renovated house" />
<meta property="og:url" content="https://www.sample-trades.com/" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Sample Trades" />Setting the preview image correctly
The preview image is the block with the greatest effect and the highest error rate. A size of 1200 by 630 pixels has become the robust standard, an aspect ratio of about 1.91:1 – the crop the large card expects. Smaller images are demoted to a small preview by many platforms or not shown at all; around 600 by 315 pixels is the lower bound for the large format. The image address in og:image has to be absolute, meaning the full domain over https, otherwise the fetching services cannot find it. JPG or PNG work well as file formats; the file should not be needlessly heavy so the preview appears quickly. If there is text in the image, it belongs in the centre, because edges are cropped differently from platform to platform. And finally: a single image for the whole site is better than none, but a dedicated motif per key page works noticeably harder. How image formats, compression and alternative text fit together in general is explored in the article on images on the website.
- Keep the aspect ratio at 1.91:1, ideally 1200 x 630 pixels, so the large card appears without cropping.
- Give an absolute image address over https – relative paths are not resolved by many services.
- Place the key message and any text centrally, because edges are cropped depending on the platform.
- Use a meaningful motif per key page instead of one single image for the whole domain.
- Provide a text alternative with og:image:alt so the card still makes sense when read aloud.
- Keep the file lean so the preview loads without a noticeable delay.
Scroll table sideways
| Aspect | With preview image (og:image) | Without preview image |
|---|---|---|
| Appearance in chat | Large card with image, title and source | Bare address or grey placeholder |
| Attention | Stands out in the feed and the group | Blends in with plain text messages |
| Perceived credibility | Looks maintained and current | Looks unfinished or outdated |
| Control over the motif | Image and crop are chosen deliberately | The service picks any image or none |
| Effort | Set once in the page head | Seemingly zero, but costs clicks |
The preview is not the search snippet
Favicon and chat card
The favicon is the small brand symbol that shows in the browser tab, the bookmark list and, in many chat cards, next to the domain. It is tiny, yet it carries a lot of recognition – and is forgotten surprisingly often: around 18 percent of pages still have no favicon (Web Almanac 2024). Technically, a single symbol is no longer enough, because different contexts expect different sizes and formats. A small set has proven itself: a classic favicon.ico as a fallback, a scalable SVG for a crisp rendering at any size, an Apple touch icon at 180 by 180 pixels for placement on the home screen, and a set of PNG symbols plus a web app manifest for mobile systems. What matters is that the motif stays recognisable even at 16 pixels across – a reduced mark works better here than a shrunken full logo.
<link rel="icon" href="/favicon.ico" sizes="32x32" />
<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<link rel="manifest" href="/site.webmanifest" />In the chat card, preview image and favicon work together: the large image draws the eye, the small symbol anchors the source. Some messengers also show the favicon to the left of the title, others display only the domain – the symbol should be present in either case. For placement on a phone home screen, the Apple touch icon or the manifest ensures a clean tile sits there instead of a screenshot. Keeping the brand consistent across channels – the same symbol in the tab, in the card and on the home screen – builds trust without writing a word for it. During a relaunch it pays to carry these symbols over deliberately so recognition is not lost; what else to watch there is collected in the article on a relaunch without ranking loss.
Title and description of the preview
The title and description of the card may differ from the entries for search. The og:title is the bold text under the image; it should be short and specific so it is not cut off mid-sentence – as a rule of thumb, about 40 to 65 characters stay reliably visible. Where a page title for search often bundles a place name and a service, the sharing title may lean more on curiosity and benefit, because it appears in a personal context. The og:description adds one or two sentences that get the value of the link to the point. Not every platform shows the description, so the card also has to work without it – image and title carry the main load. If you offer several languages, maintain the entries per language version so the shared card matches its destination. How a title for the search results list is built instead is shown in the article on titles and descriptions for more clicks.
Why the old preview keeps sticking
A common annoyance: the preview image was corrected long ago, yet the card keeps showing the old motif or a grey box. The reason is a cache. As soon as a link is shared for the first time, the platform fetches the page and stores the preview for a while instead of regenerating it on every share. Changes to the head therefore do not take effect immediately. Two routes help: many platforms offer a preview or debug tool that triggers a fresh fetch; and if you are swapping the image anyway, give the new file a new name so the preview reliably notices the change. It is important to check the preview before the first big distribution – because the first fetch shapes the image for many users. For the same reason the preview test belongs in the launch phase of a new site, as described in the checklist for the first weeks after launch.
The first impression of a website often forms not on the home page but in a chat bubble – where someone passes the link on.
Set once, stable everywhere
Test before you share
The test takes a few minutes and spares awkward moments. The fastest step is a look at the source: does the head contain og:title, og:description and og:image with an absolute image address? Then comes the practical trial. Most platforms provide a preview tool that shows the card as it will appear when shared – and refreshes the cache at the same time. A test within a closed circle helps as well: send the link to a private chat or a note first and look at the card there, ideally on a phone, because that is where most links are opened. Check not only the home page but the pages that are actually shared – the offer, the booking flow, the article. How a shared booking flow holds up in practice is set out in the article on online appointment booking for local businesses.
- Check the head: og:title, og:description, og:image (absolute https address) and og:url are present.
- Preview image at a 1.91:1 ratio with a centred motif, ideally 1200 x 630 pixels.
- Favicon set complete: favicon.ico, SVG, Apple touch icon and manifest.
- View the card with the platform preview tool and refresh the cache.
- Share the link in a private chat first and check the rendering on a phone.
- Do not check only the home page, but every page that gets shared.
- After swapping an image, assign a new file name so the change reliably takes effect.
How XICflow sets the preview image and favicon
The preview image and favicon are exactly the kind of detail that slips through in the rush of a website project – and shows up the moment the first link is shared. XICflow carries these blocks from the outset: for every page the Open Graph entries are set with an absolute image address, the preview image is produced in the right crop and the complete favicon set including the Apple touch icon and manifest is derived from the brand symbol. Because the pages ship as static HTML, the preview sits stably in the head instead of being assembled afterwards by a script – so nothing falls away when the link is shared. Which blocks are part of that is shown in the XICflow service overview; how a page is assembled step by step is described in how XICflow works. None of this replaces choosing a good motif yourself – the image remains a design decision – but it takes the technical error out of your hands.
A good preview image starts with a clear briefing: providing a logo, colours and one or two meaningful motifs gives the card a foundation – which entries an AI website builder needs for that is collected in the article on briefing inputs. How finished pages and their preview look can be explored in the example sites in the demo gallery, and what the build costs is shown in the pricing overview.