for clean share previews on every platform
A shared link with no image, a truncated title, or the wrong description looks unprofessional and gets clicked less often. Open Graph tags control exactly how a URL appears as a preview on Facebook, LinkedIn, WhatsApp, and other platforms. Setting og:image, og:title, and og:description correctly, and respecting per-platform image sizes, turns every shared link into a small advertisement instead of a missed opportunity.
Table of Contents
- 1. What Open Graph tags technically do
- 2. The complete og: tag reference
- 3. Applying image sizing rules to og:image correctly
- 4. Facebook quirks: cache, debugger, and aspect ratio
- 5. LinkedIn quirks: its own cache and Post Inspector
- 6. WhatsApp quirks: minimalist preview, hard limits
- 7. Hyvä/Magento implementation of Open Graph tags
- 8. Fallback strategy for category and product pages
- 9. Testing, validating, and solving cache problems
- 10. Summary
- 11. FAQ
1. What Open Graph tags technically do
Open Graph tags are meta tags in a page's <head> that follow the Open Graph protocol, originally introduced by Facebook in 2010 and now adopted by practically every major platform as the de facto standard for link previews. As soon as a URL is shared on Facebook, LinkedIn, WhatsApp, Slack, or Discord, the respective platform fetches the page with its own crawler, reads the Open Graph tags, and builds the preview card from them, including image, title, and description.
Without well maintained Open Graph tags, every platform falls back on its own heuristics: the first image found on the page, the <title> tag, and a randomly extracted text snippet. The result is usually unpredictable, often a wrong image, a truncated title, or a description pulled from the navigation instead of the actual content. Deliberately configuring Open Graph tags means taking full control over this appearance, regardless of whatever heuristic the platform would otherwise apply.
2. The complete og: tag reference
The foundation of every Open Graph implementation consists of four required properties: og:title, og:type, og:image, and og:url. Beyond that, there is a set of recommended and optional properties that refine the preview depending on content type. og:description provides the preview text, og:site_name shows the brand name under the title, and og:locale controls the language variant of the preview, relevant for multilingual shops with DE and EN versions.
There is a subtle but important distinction for image properties: og:image is the URL itself, while og:image:width, og:image:height, and og:image:alt provide additional metadata that platforms use when rendering, before the image has even been downloaded. If width and height are missing, the platform has to load the image first to determine the aspect ratio, which can lead to delayed or broken previews on slow servers. These fields are therefore not an optional detail, but a performance-relevant part of the Open Graph tags.
<!-- Complete Open Graph tag set for a product page -->
<meta property="og:title" content="Alpine Pro 2 Hiking Boot - waterproof, Gore-Tex">
<meta property="og:type" content="product">
<meta property="og:url" content="https://mironsoft.de/hiking-boot-alpine-pro-2">
<meta property="og:image" content="https://mironsoft.de/media/catalog/product/alpine-pro-2-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Alpine Pro 2 hiking boot in black and orange, side view">
<meta property="og:description" content="Waterproof hiking boot with Gore-Tex membrane, Vibram sole, and reinforced toe protection. In stock.">
<meta property="og:site_name" content="mironsoft.de">
<meta property="og:locale" content="en_US">
<meta property="og:locale:alternate" content="de_DE">
<meta property="product:price:amount" content="149.90">
<meta property="product:price:currency" content="EUR">
3. Applying image sizing rules to og:image correctly
The most common source of errors with Open Graph tags is a wrongly sized image. The current recommendation for og:image is 1200 by 630 pixels, an aspect ratio of roughly 1.91:1. Images under 200 by 200 pixels are often not shown as a large preview card at all by Facebook and LinkedIn, only as a small thumbnail next to the text, which noticeably reduces click-through rate. File size should not exceed 8 MB, but in practice a compressed JPEG or WebP file under 300 KB is recommended so the crawler can fetch the image reliably and quickly.
A second, often overlooked point concerns secure loading: og:image:secure_url used to be necessary for HTTPS images on HTTP pages, but with pervasive HTTPS today it is usually redundant, though many older implementations still include it twice. More important in practice is the absolute URL: og:image must always be a complete URL with protocol, never a relative path, since platform crawlers do not know the page's base URL and simply cannot resolve a relative path.
| Platform | Recommended image size | Aspect ratio | Quirk |
|---|---|---|---|
| 1200 x 630 px | 1.91:1 | Center-crops the image on mismatch | |
| 1200 x 627 px | ~1.91:1 | Own cache, 7-day TTL | |
| 300 x 200 px min. | Square preferred | Hard size limits, small preview | |
| Slack | 1200 x 630 px | 1.91:1 | Unlimited cache duration, no refresh API |
| Discord | 1200 x 630 px | 1.91:1 | Renders og:image even without og:type |
| Telegram | 1200 x 630 px | 1.91:1 | No own cache, re-reads on every share |
4. Facebook quirks: cache, debugger, and aspect ratio
Facebook caches Open Graph data per URL for up to 30 days, regardless of how often the page content changes. That means if an og:image is swapped out later, Facebook may keep showing the old image for weeks, because the crawler does not automatically re-fetch the page. The solution is the Facebook Sharing Debugger, which lets you manually refresh the cache for a specific URL, a step that is mandatory after every change to og:title, og:description, or og:image before the new preview becomes visible.
Another Facebook quirk concerns image cropping: if the aspect ratio deviates from the recommended 1.91:1, Facebook automatically center-crops the image, which produces unsightly results for product images with important details near the edges. For e-commerce images, it is therefore recommended to use a dedicated og:image that differs from the actual product shot and is already delivered in the correct aspect ratio with enough margin around the main subject.
5. LinkedIn quirks: its own cache and Post Inspector
LinkedIn uses its own crawler, independent of Facebook's crawler, and fetches Open Graph tags with a typical cache duration of about seven days. It is important to know that LinkedIn reads og:image reliably, but if the image is missing or too small it tends to show a fallback preview without an image, rather than automatically picking any page image the way Facebook does. This makes a correctly set og:image even more important on LinkedIn than on other platforms, especially for B2B content, which is frequently shared there.
To test and force a cache refresh, LinkedIn offers the Post Inspector, an official tool that shows the currently cached Open Graph data and triggers a manual refresh. In practice, it is worth systematically running the most important URLs through the Post Inspector after every redesign or content migration, before launching a major campaign with link shares on LinkedIn, to avoid stale cache entries.
<!-- LinkedIn-specific reinforcement: og:image:type helps the crawler
pick the correct MIME type without a HEAD request round trip -->
<meta property="og:image" content="https://mironsoft.de/media/catalog/product/alpine-pro-2-1200x627.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<!-- Article-type extension for blog posts (LinkedIn reads these too) -->
<meta property="article:published_time" content="2026-07-23T08:00:00+02:00">
<meta property="article:author" content="https://mironsoft.de/about-us">
The og:image:type field saves LinkedIn a separate HEAD request for MIME type detection and noticeably speeds up building the preview card, especially for images served through a CDN with a generic content type.
6. WhatsApp quirks: minimalist preview, hard limits
WhatsApp also uses Open Graph tags, but renders the preview far more compactly than Facebook or LinkedIn: a small thumbnail on the left, title, and a short description snippet next to it. The most important technical difference is a hard size limit of about 300 KB for the image in many app versions, far stricter than the 8 MB Facebook officially allows. An oversized og:image is often simply not shown on WhatsApp at all, the preview then appears with no image, only title and URL.
Another WhatsApp-specific behavior concerns the cache duration on mobile devices: unlike Facebook and LinkedIn, WhatsApp has no official debugger for manually refreshing the cache. In practice, appending a query parameter to the URL to change the cache key often helps, but only as a workaround, since this leads to unattractive, long URLs for campaign links. The most reliable approach remains keeping og:image small enough from the start that WhatsApp can reliably load it in the first place.
7. Hyvä/Magento implementation of Open Graph tags
In Hyvä themes, Open Graph tags are best controlled through a dedicated ViewModel that outputs the appropriate meta tags per page type in the head template: product pages get og:type="product" with price and availability data, category pages and CMS pages fall back to og:type="website", and blog posts to og:type="article". It is important that the og:image for product pages is derived from the existing product image, ideally with a dedicated image cache preset in the correct 1200x630 resolution, rather than delivering the original image at full resolution.
For categories without their own hero image and for CMS pages without an editorially maintained image, a default og:image at the store level, managed through Store Configuration, is recommended as a fallback. This fallback logic prevents Facebook or LinkedIn from picking some random image from the page when a specific one is missing, such as a logo at the wrong resolution or an icon from the navigation, which in practice regularly leads to unprofessional-looking previews.
<!--
app/design/frontend/Mironsoft/default/Magento_Theme/templates/html/head/og-tags.phtml
ViewModel: Mironsoft\SeoSuite\ViewModel\OpenGraph (ArgumentInterface)
-->
<?php /** @var \Mironsoft\SeoSuite\ViewModel\OpenGraph $openGraph */ ?>
<meta property="og:type" content="<?= $escaper->escapeHtmlAttr($openGraph->getType()) ?>">
<meta property="og:title" content="<?= $escaper->escapeHtmlAttr($openGraph->getTitle()) ?>">
<meta property="og:description" content="<?= $escaper->escapeHtmlAttr($openGraph->getDescription()) ?>">
<meta property="og:url" content="<?= $escaper->escapeUrl($openGraph->getCanonicalUrl()) ?>">
<meta property="og:site_name" content="<?= $escaper->escapeHtmlAttr($openGraph->getSiteName()) ?>">
<?php foreach ($openGraph->getImages() as $image): ?>
<meta property="og:image" content="<?= $escaper->escapeUrl($image->getUrl()) ?>">
<meta property="og:image:width" content="<?= (int) $image->getWidth() ?>">
<meta property="og:image:height" content="<?= (int) $image->getHeight() ?>">
<meta property="og:image:alt" content="<?= $escaper->escapeHtmlAttr($image->getAlt()) ?>">
<?php endforeach; ?>
8. Fallback strategy for category and product pages
A robust fallback strategy for Open Graph tags follows a clear priority chain: first an editorially maintained, page-specific image, then the primary product or category image at the correct resolution, then a topic-specific default image, and only last a generic brand og:image at the store level. This chain should be modeled server-side in the ViewModel, so no fallback logic is scattered across templates and every page is guaranteed to output a valid og:image, even when editorial data is missing.
Especially for product variants with many color options, a dynamic image selection pays off: instead of generating a new og:image for every variant, a representative image of the default variant is usually enough, supplemented by og:title with the specific variant name. This significantly reduces image management overhead without noticeably degrading preview quality, since most users do not compare every single variant in detail when sharing anyway.
For international shops with multiple store views, an additional rule applies: the fallback chain must be configurable per language and store separately, since a German default image with German text is out of place on an English store view. In Hyvä this can be solved with store-specific configuration values resolved in the ViewModel based on the current store ID, before the fallback chain even kicks in.
Mironsoft
Open Graph integration and social SEO for Hyvä/Magento shops
Broken share previews costing you clicks and trust?
We implement complete, platform-compliant Open Graph tags in your Hyvä theme, including a fallback strategy, image presets, and validation across all the major sharing platforms.
og tag audit
Review existing Open Graph tags and identify gaps
ViewModel implementation
Clean og tag output with a fallback chain per page type
Image presets
Automatically generate 1200x630 image variants from product images
9. Testing, validating, and solving cache problems
Testing Open Graph tags belongs on the checklist before every rollout. The Facebook Sharing Debugger, LinkedIn Post Inspector, and tools like the Twitter Card Validator or a generic Open Graph checker show what values the respective platform actually reads, not just what is in the source code. Differences between the two often come from faulty escaping rules, duplicate meta tags with conflicting values, or an og:image blocked by robots.txt or a referrer policy, which the crawler is then unable to load.
A common, hard to diagnose problem is an overly restrictive Content Security Policy or hotlink protection that blocks image requests without a matching referrer. Since social crawlers often request without standard browser headers, server-side bot protection can accidentally lock out the og:image as well. The most reliable way to detect this is to check the server logs directly for user agents such as facebookexternalhit, LinkedInBot, or WhatsApp, and verify that these requests are actually answered with status code 200.
A regular check is also worthwhile after infrastructure changes such as a CDN migration or a new WAF rule, since these systems can mistakenly block social crawlers that lack a recognizable browser fingerprint, even though they are not actually unwanted bots. A monthly run of the most important landing pages through the Facebook Sharing Debugger reliably catches such regressions before a marketing campaign launches with broken previews.
Configure Open Graph Tags Correctly: The Key Points at a Glance
Required properties
og:title, og:type, og:image, and og:url are the minimum. og:description and og:site_name belong in every solid implementation.
Image size
1200x630 pixels, 1.91:1 aspect ratio, under 300 KB compressed, always specified as an absolute URL.
Cache management
Use the Facebook Sharing Debugger and LinkedIn Post Inspector after every change to refresh stale previews.
Hyvä implementation
Central ViewModel with a fallback chain per page type, image presets at the correct resolution instead of original images.
10. Summary
Open Graph tags determine whether a shared link looks professional or shows up in a feed as an empty preview without an image and with a truncated title. The foundation of og:title, og:type, og:image, and og:url must exist on every page, supplemented by og:description, og:site_name, and precise image metadata such as og:image:width and og:image:height. Platform-specific quirks on Facebook, LinkedIn, and WhatsApp, particularly different cache durations and image size limits, require a deliberate testing strategy rather than a one-time configuration.
In Hyvä themes, og tag output belongs in a central ViewModel with a clear fallback chain, so every page is guaranteed to output valid Open Graph tags, even without an editorially maintained image. Building this structure cleanly once saves recurring debugging sessions with the Facebook Sharing Debugger and ensures that every shared link actually achieves the desired effect.