What does your buyer's team see when your champion pastes your pricing page into Slack?
They see a link preview built from your page's metadata, usually a title, a short description, and an image. If those tags are missing or generic, the preview looks like a random homepage. If they are written for the page, the preview does a small piece of selling before anyone clicks.
In B2B deals, a lot of buying happens in Slack channels you will never see. Your champion drops your pricing page, a case study, or a security page into a thread with their manager and a few colleagues. That preview is your first impression with people who have never heard of you.
I build B2B websites and the systems around them, and link previews are one of the most neglected details I audit. They take minutes to fix, and they shape how your pages look in the exact moments when a deal is being discussed internally.
How does Slack decide what to show in a link preview?
When no Slack app handles your domain, Slack uses what it calls classic unfurling. According to Slack's developer documentation, Slack crawls the URL and looks for common Open Graph and X Card metadata, then builds a simplified preview. Your meta tags, not your visible page, decide what the preview says.
Open Graph tags are small pieces of metadata in the head of a page. The main ones are a title, a description, and an image. X Card tags, formerly known as Twitter Card tags, do a similar job. Slack reads these tags because they are a common standard, so most sites already have some version of them.
The catch is that "some version" is often a default. Many sites set one sitewide description and one sitewide image, then never touch them again. Every page shared in Slack then looks identical, whether it is your pricing page, your security page, or a deep case study.
Which pages get shared inside buying teams most often?
Pricing pages, case studies, security or trust pages, integration pages, and comparison pages get shared most, because they answer the questions colleagues ask. These are the pages your champion uses to make your case internally, so their previews deserve the most care. Your homepage matters less here than you might expect.
Think about the conversation in that Slack thread. The manager asks how much it costs, so the champion pastes the pricing page. IT asks about data handling, so the champion pastes the security page. Someone asks whether it works for a team like theirs, so the champion pastes a case study. Each preview is answering a specific question.
That is why I treat these pages as part of the champion's toolkit. I covered the wider set of materials that help champions sell in content that helps your champion sell internally, and link previews are the quiet, technical layer under all of it.
What should the preview title and description say?
The title should name the page's purpose plainly, like "Pricing for teams of 10 to 200." The description should answer the question the page exists to answer, in one or two short sentences. Write for a manager glancing at a thread, not for a search engine. Clear and specific beats clever.
For a pricing page, the description might say who each plan is for and whether there is a free trial. For a case study, it should name the customer type and the outcome in plain words. For a security page, it should state the main certifications or practices you actually have, and nothing you do not.
Keep the Open Graph title close to the page title, but do not be afraid to make it more useful. A page title written for search might include extra keywords. The preview title can be shorter and more human, because it appears in a conversation between colleagues.
What image should a shared page use?
Use an image made for the page, not your logo on a plain background. For a pricing page, a clean graphic with the page's main promise works well. For case studies, the customer's logo next to yours plus a short outcome line works. Keep text large, because previews are small on screen.
The image does more work than people expect. In a busy Slack channel, the image is what catches the eye before anyone reads the title. A generic logo image signals "marketing link." A specific, readable image signals "this answers your question."
For sites with many similar pages, like case studies or integration pages in a CMS, you do not need to design every image by hand. You can generate images from a template and pull the right one into each page. I wrote about doing this in Webflow in how to set up dynamic Open Graph images in Webflow CMS.
How do you audit your current previews?
Paste each key page into a private Slack channel or a direct message to yourself, and look at the preview. Check the title, description, and image for each one. Then compare them with what that page should communicate. Write down every page where the preview is generic, wrong, or missing.
Start with the five to ten pages most likely to be shared in a buying conversation. For each one, ask three questions. Does the title say what the page is? Does the description answer the question the page answers? Is the image specific and readable at a small size?
Also check the pages you have changed recently. If you updated pricing or retired a plan, an old description in the meta tags can contradict the new page. That mismatch looks careless to a buyer, especially in a thread where someone is already skeptical.
Remember that previews may not update instantly after you change your tags, because platforms can hold on to what they fetched before. After you fix a page, test it again later before you assume the old preview is still the problem.
Should you also think about other platforms besides Slack?
Yes. Buyers share links in Microsoft Teams, LinkedIn, email clients, and messaging apps too. Most of these tools rely on the same Open Graph style metadata, so fixing your tags for Slack usually improves previews everywhere. Still, check each platform's own documentation if a preview there looks different from what you expect.
The safest approach is to write tags that work as a standalone message. If the title, description, and image make sense on their own, they will read well in almost any preview format, even when a platform crops the image or shortens the description.
I set Open Graph and X Card tags on every page template I build, so new pages start with sensible defaults rather than a sitewide fallback. The Webflow side of that setup is in how to set Open Graph and Twitter Card tags in Webflow.
Is there anything you should not put in a preview?
Do not put claims in a preview that the page does not support, prices that change often, or anything confidential. Previews travel without context and get forwarded. If your description says something the page does not back up, a skeptical colleague will notice, and your champion pays for it.
Be careful with prices in particular. If your pricing page description includes a specific price and you change it later, old previews and cached copies can keep showing the old number. A description that says who each plan is for ages much better than one that quotes a figure.
Also avoid hype words. A preview that reads "the most powerful platform ever built" lands badly in a thread where a manager is trying to decide whether to take a meeting. Plain and specific wins in that setting, every time.
What should you do next?
List the ten pages most likely to be shared during a deal. Paste each one into a private Slack message and review the preview. Rewrite the title, description, and image for every page where it is generic. Then set better defaults on your page templates so new pages start strong.
Once the fixes are live, ask a friendly customer or colleague to paste a few pages into their own workspace and send you a screenshot. Seeing your previews in a real thread is the quickest way to judge whether they would help your champion or quietly work against them.
If you want help auditing the pages your buyers share and the metadata behind them, reach out. I build websites and the automations behind them for lead generation, and small details like these often decide whether a shared link turns into a meeting. Let's chat.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.