Why Open Graph meta tags break previews in messengers
Most often the problem is not in the social network, but in the page markup. A messenger or social platform requests the page, reads the Open Graph meta tags, and builds a link preview — a card with an image, title, and description.
If the tags are not served on the server side but are injected by a script after loading, the platform's robot simply does not see them: it does not execute client-side code and receives an empty shell.
Then a bare link without an image goes into the chat — and clicks on it drop off, because the recipient has nothing to catch their eye.
The second most common cause is that og:image does not display because the image is closed to external requests, is served via a relative path, or sits on a domain that the platform's robot cannot reach.
Sometimes delivery gets in the way: the file is served with a type that the platform does not consider an image, or the size and proportions do not meet its requirements — the preview either fails to build or is cropped so that only half the logo is visible on the card.
The preview cache deserves separate mention: platforms keep the built card on their side and do not re-read the page on every request. Editing the tags without resetting the cache looks like "nothing changed," even though everything is already correct on the server.
The cost of the mistake is not cosmetic. A card in a messenger is the first contact with the brand before the transition to the site: without it, a link in a chat looks like spam, the share of clicks falls, and in ads and mailings part of the acquisition budget is lost.
Below we break down how this is fixed: which tags are mandatory, how to serve them so that the platform's robot sees them, and how to verify the result before publishing.
What correct Open Graph and Twitter Card markup delivers
Correct Open Graph and Twitter Card markup determines what a person sees when a link to your site is pasted into a messenger, social network, or professional network.
Without it, the platform decides on its own which title and image to show: it often pulls in the first logo it finds, crops the image along a random edge, or takes the description from boilerplate text. The card looks raw, and the user scrolls on without clicking the link.
With markup, each platform gets a ready-made set: title, description, an image in the right format, and the content type. Twitter Card defines a separate scenario for a large preview, while Open Graph covers the remaining sources.
As a result, the same link expands into a consistent card view everywhere — from a work chat to a social feed, with no manual tweaking for each platform.
The effect is measurable in two ways. First, click-through from social networks: a tidy preview with a clear title and image gathers noticeably more clicks than a random fragment of a page, because the person understands where the link leads before clicking.
Second, eliminated manual work: auto-generating previews from a template removes the need to prepare an image and description for every piece of content by hand.
Separately, this eliminates a class of errors that don't surface right away. A link sent to a messenger is cached by the platform — and if there was no markup, the corrected card won't appear for everyone and won't appear immediately.
When meta tags are set at the page template level, every new publication gets a correct preview automatically, rather than relying on the editor's memory.
Ways to Set Meta Tags: Comparing Approaches
The choice of how to set Open Graph meta tags determines how predictably a page's card will look in social networks and messengers.
On a static landing page, manual markup in the template is enough, but on a catalog with thousands of pages, the same approach turns into a source of discrepancies: titles are duplicated, images serve the wrong format, and new sections go live without any markup at all.
In practice, approaches are combined: the base set of tags is set in the template, while the variable parts — title, description, image — are pulled from the page data. Below is a comparison of the three options that are usually chosen between.
| Option | When it fits | Limitations |
|---|---|---|
| Manual markup in the template | Static pages, landing pages, a handful of sections | Edits only through a developer; as pages grow, discrepancies and forgotten tags appear |
| Markup via a content management system | Editors manage pages themselves, control over the card text is needed | Requires fields for each tag and validation; it's easy to end up with an empty description or an image of the wrong size |
| Dynamic generation by page type | Catalogs, product cards, articles, thousands of same-type URLs | Requires substitution rules and fallback values, otherwise the card is assembled incorrectly on incomplete data |
Manual markup gives full control but scales poorly: every change goes through a release. A content management system takes the load off the developer, but shifts responsibility for card quality onto the editor — without server-side checks, tags go into the markup as is.
Dynamic generation covers the volume: title, description, and image are assembled from the page data according to rules, while the template sets fallback values in case a field is empty.
The most reliable setup is a combination: the template handles the constant tags, the content management system handles manual overrides where special text is needed, and generation handles mass page types. This approach removes manual labor at scale and leaves the editor with pinpoint control.
How we implement markup: stages of work
Preview markup is not "adding a couple of tags to a template" — it is a managed process: each page has its own entity (product, article, category), and how correctly it is described determines how the link looks in messengers, social networks, and search results. Below is how we carry out this work so that the result is reproducible rather than one-off.
- Audit of current meta tags. We collect all page types, review what is already being output in the markup, where values are duplicated, where they are automatically pulled from the heading, and where they are missing. We separately check pages with dynamic content and pagination — that is where the preview image most often breaks.
- Designing the markup schema. For each page type, we fix the required set of properties: title, description, image, object type, canonical URL. We determine which values come from the database, which are set manually, and how the markup behaves when data is missing.
- Preparing preview images. We set uniform proportions and requirements for the image content so that it is not cropped on different platforms. For products and cards, we pull the image from the catalog; for other pages, we use a template with the heading inserted.
- Implementation in templates and data output. We define the rules at the level of templates and models, not individual pages: a new entity automatically receives correct markup, without manual editing. This is the key difference from "spot" fixes, which fall apart in the next release.
- Checking previews on real platforms. We run links through debuggers and live publications: messengers, social networks, professional channels. We look not only at correctness, but also at how often a platform picks up updated data instead of cached data.
- Update regulations. We hand over a document: which fields are required when adding a new page type, who is responsible for images, how to check changes before release. Without this, the markup degrades within just a few development iterations.
As a result, the client receives not a set of tags, but a working mechanism: the markup is updated together with the content, and link previews remain predictable on all platforms.
What the client receives
The deliverable is not "we fixed something in the code," but a complete package your team can keep working with after we're gone. Everything related to Open Graph meta tags is handed over as working files and rules, not verbal explanations.
- Meta tag templates — ready-made blocks for each page type: product, article, category, service page, landing page. The template pulls the title, description, and image from the page fields, so an editor doesn't fill in the markup by hand and doesn't break it.
- Page type map — a table showing, for each template, which fields are required, where the image comes from, and what preview size to expect. It immediately shows what will happen to a card when a new page is added.
- Set of preview images — prepared variants for different content types and for cropping in feeds: square and wide. Plus rules for how a single source produces a correct frame without over-compression.
- Documentation — a short description: which tag is responsible for what, how to check the result before publishing, and what to do when the design or domain changes.
- Update procedure — the sequence of steps for rebranding, changing a template, or bulk-editing titles: who makes the change, where it's checked, and how it's rolled back.
- Configured validation — markup checking is built into the publishing process, so a broken card doesn't go into the feed unnoticed.
We separately document the points where the markup connects to other systems — the page generator, the content management system, the cache.
If a connection exists, it's described in the documentation: the next time the site changes, no one has to guess why the preview stopped updating.
Case study: how previews stopped breaking on all platforms
The client — a chain of service centers — complained that links to blog articles in messengers and social networks opened as bare text: without an image, without a title, sometimes with someone else's description.
After each publication, the content manager manually checked the preview in four channels and fixed it if something displayed incorrectly. This took 20-30 minutes per piece, and when an article was updated, the card could "break" again.
What it was before
The markup was assembled haphazardly: some pages returned only a basic title, some — an image without specified dimensions, and some materials had no social tags at all.
Platforms built previews in their own way: somewhere they substituted the site logo instead of the cover image, somewhere they truncated the title, somewhere they cached an old version and did not update it after edits. It was impossible to track down the cause without manually checking each channel.
What was changed
We described a unified meta-tag template for all page types — articles, service cards, catalog sections — and moved it into a shared markup layer so that the content manager only had to fill in the title, description, and cover image.
For images, we set fixed proportions and a fallback image in case the cover failed to load. Separately, we wrote rules for platforms that read markup differently, and added tag validation to the build: a page without the required fields simply does not pass publication.
What the result was
Previews stopped breaking: the share of correctly displayed cards grew from about 60% to 98%, and manual fixes left the process entirely.
The time to publish a piece dropped from half an hour to a couple of minutes, and the content manager no longer had to keep a list of platforms to check in their head. When an article is updated, the card pulls the new version without developer involvement.
The project was led by our engineer responsible for markup and the build. We did a similar review for a media portal on WordPress — the problem there was the same: the markup lived in the theme template and did not cover new post types.
How does Open Graph differ from Twitter Card?
Open Graph is a standard originally defined by Facebook, and today it is read by almost all major platforms: messengers, social networks, link aggregators.
Twitter Card is a separate specification that grew out of Twitter's needs, with its own set of properties and its own behavior when parsing a page.
The differences between the standards are not in ideology, but in which tags each platform is guaranteed to take into account and how it builds a preview if the required property is missing.
The key technical difference is tag priority and fallback rules. Open Graph describes an object in full: type, title, description, image, URL, site name. Twitter Card largely relies on the same data and, when its own properties are absent, substitutes values from Open Graph.
But if both sets are specified, the platform gives priority to its own tags — which is why a mismatch between them produces different previews on different platforms for the same link.
In practice, it looks like this: a card in a messenger shows one title and image, while when published on another network, a stale cache or a cropped image is pulled in.
The cause is almost always the same — some properties are specified in only one standard, and the image dimensions and proportions do not match the platform's expectations.
A separate headache is dynamic pages, where meta tags are generated on the application side: if rendering fails, the crawler sees an empty template and builds a preview without an image.
When are both sets needed? If the link will be distributed across several channels — yes, almost always. Open Graph covers the main scenario, while Twitter Card refines the behavior of a specific platform and eliminates discrepancies.
We specify both standards in a coordinated way, set explicit image dimensions to meet platform requirements, and verify the result on real crawlers, not just in a debugger.
This eliminates the class of errors where the preview looks correct for the developer and breaks for the link recipient.
It is also worth remembering the cache: platforms store parsed metadata and do not re-read it instantly after an edit.
That is why tags are checked before publication, not after — otherwise, fixing a discrepancy between the standards will stretch into days of waiting for the cache to update.
Common technical concerns
Previews in messengers and social networks are cached on the platform side: after editing the title or image, the old version may still be shown for a day or longer.
This is solved not by "waiting" but by forcing an update through the platforms' debugging panels and changing the image URL — linking to a new file name reliably resets the preview cache.
Tag conflicts are the second common cause of an "empty" preview. If two sets of markup live on a page at the same time (for example, one from the theme and one from a module), the platform picks the first one it encounters and shows the wrong thing.
We consolidate the markup into a single source and verify priorities on every page type — product page, article, category, homepage.
What happens if the preview image is made too large or too small?
Platforms crop or ignore images outside the recommended aspect ratio. We prepare previews at a 1.91:1 ratio, with margin at the edges for cropping and a separate square version for messengers — that way the card looks correct in any feed.
How quickly will the preview update after new content is published?
With correct markup — immediately upon the platform's first request to the page. If the preview is "stuck," we run the URL through a debugging tool and, if necessary, change the image file name: the preview cache is reset, and the up-to-date card appears in the feed.
Can different previews be set for the same page across different social networks?
Yes. A basic Open Graph set covers most platforms, while separate tags for Twitter and Telegram cards allow fine-tuning the appearance of the link. We check that these sets do not conflict with each other and do not override one another.
All the concerns above come from practice: we configure the markup so that the preview is predictable during publishing, updating, and changes to the page design.
Let's discuss your meta tags task
To make the conversation concrete rather than "just tell us in a couple of words," it's enough to gather the minimum before the first call: the URLs of pages where the previews are currently broken, and examples of how they look in messengers and social networks.
That's enough to understand the scope and come back with an estimate and a plan, rather than generalities.
What's worth preparing in advance:
- a list of pages or templates where correct previews matter (home page, product cards, articles, campaign landing pages);
- screenshots of how links currently look when sent to a messenger or published — this shows where the wrong title or an empty image is being pulled in;
- access to the repository or templates where the meta tags are output, and to the site's admin panel;
- requirements for preview images: aspect ratio, what should be in the image, whether there's a logo and text;
- a list of page types that are generated automatically — for these, tags are output by template rather than manually;
- preferences on timelines and on who on your side signs off on the result.
Next, we compare this against the current markup, check how tags are served for different page types, and pin down exactly what we're changing: default values, templates for cards, preview images.
As a result, you get an estimate of the scope of work, a plan for template and timeline edits, and a format for working together — one-off changes or ongoing support with preview checks after every release.
Describe the task in whatever form is convenient: links, screenshots, or a short list of pages. We'll come back with an estimate, a plan, and timelines — and we'll say right away where a template fix is enough and where separate output logic is needed.
