Open Graph – how to improve link previews in social media?

Open Graph is a simple mechanism that determines how a link is presented when pasted into Facebook, LinkedIn, Messenger or other social channels. It is embedded in the page code, so the user usually does not notice it, whereas services read it automatically. This makes it possible to set the title, description, thumbnail and address shown in the share preview. It has a very practical impact, because a badly fetched link can look random or simply unreadable. Well-implemented Open Graph does not improve the content of the page itself, but it does genuinely improve how it is presented in social media. In practice, the most time is spent not on adding the tags themselves, but on matching them to page types, graphics and the way individual platforms interpret metadata.

What is Open Graph and how does it work?

Open Graph is a set of meta tags placed in the head section of a page that tell social platforms which title, description, image and address to show in the link preview. Most commonly these are the og:title, og:description, og:image, og:url and og:type tags. Twitter Cards are often implemented alongside them, because some services rely on their own markup. In practice, this is not a “for the whole site” solution with a single setting, but a set of rules prepared for specific page types such as articles, products, categories or landing pages.

The mechanism works in such a way that after the URL is pasted, the platform’s bot visits it and reads the metadata from the HTML code. On that basis it builds the preview, i.e. the thumbnail, heading, short description and destination link. If this data is missing or inconsistent, the platform starts “guessing” and then often chooses the wrong image or a random fragment of text. That is precisely why Open Graph is used primarily to take control over what is displayed.

Implementing Open Graph does not affect what the user sees on the page after arriving from search or an advert. It does, however, change what a given platform fetches and renders before the click. This is an important distinction, because many issues with shares stem not from the page content, but from the fact that the social media parser reads different information than a person does in the browser.

In practice, the way the page is rendered also matters. If meta tags are added only via JavaScript, some parsers may not read them correctly or may not read them at all. For SPA-based sites, you need to ensure server-side rendering or prerendering; otherwise, the link preview may be empty or incorrect. This is one of the more often overlooked aspects in modern implementations, where the devil is in the detail.

Why is Open Graph important for social media?

Open Graph is very important in social media because it determines the first impression made when a link is seen. The user first assesses the thumbnail, title and short description, and only then decides whether to click. When the preview is unreadable, cut off or shows the wrong image, the link loses credibility and stops attracting attention. In social media, the best content often does not win — the best-presented preview does.

The role of Open Graph grows especially where the same address is shared repeatedly: in posts, campaigns, messengers, groups and entries published by employees or partners. Without correct tags, each such share can look different or worse than it should. This makes it harder to maintain consistent brand communication and can weaken the effect even of a carefully prepared publication.

Open Graph is also important operationally because platforms do not interpret data in the same way. One will use the image from og:image, another will shorten the description more aggressively, and another will show an older preview version from cache. That is why the mere presence of tags is not enough — it is also worth checking whether the given platform fetched the correct URL and refreshed the data after changes.

In practice, the biggest problems result from minor technical slip-ups. An image that is too small, the lack of an absolute image URL, duplicate tags, a conflict with the canonical or a bot block on the server side can cause a theoretically correct Open Graph not to work. For that reason, it is better to treat it not as a cosmetic extra, but as an element of the technical quality of the site and publications in social channels.

Which Open Graph meta tags are key?

The most important are og:title, og:description, og:image, og:url and og:type, and for traffic from platforms using their own rules, also Twitter Cards tags. These are the ones that most often determine which title, description, image and address the user sees after pasting the link. If this data is missing or not consistent with one another, the platform starts “guessing” and chooses the elements of the page in its own way. In practice, that is a straightforward route to an ugly or misleading preview.

og:title should be short, unambiguous and written with the link preview in mind, not solely for the page itself or SEO. A long title is often cut off, so it is best to start with the key information. og:description should complement the title, not duplicate it. Usually the best option is a concise description that indicates the benefit, topic or context of the link without stuffing in keywords.

og:image usually has the strongest impact on how a link is perceived, because the image is what grabs attention first. The graphic should be publicly accessible, of good quality, at an absolute URL and without any bot restrictions. The most common problem is an image that is too small, a relative address or a file that the platform cannot fetch. It is also worth keeping in mind that individual services crop thumbnails differently, so it is better to keep text on the image to a minimum.

og:url specifies which address the platform should recognise as the correct one for a given piece of content. It should match the canonical and not involve unnecessary redirects. When og:url, canonical and the actual page URL diverge, the link preview can be incorrect or “flicker” over time. Meanwhile, og:type helps the platform understand what type of content it is dealing with, for example an article or a general page.

If traffic from X or from tools using their own tags is important, it is also worth adding the equivalent Twitter Cards, especially twitter:card, twitter:title, twitter:description and twitter:image. Some platforms can rely solely on Open Graph tags, but this does not always work identically. Therefore, it is wiser to complete both sets wherever a given channel matters commercially.

How to carry out an Open Graph audit and implementation?

An Open Graph audit and implementation come down to checking the current link preview, defining rules for page types, correctly adding the meta tags, and testing whether the platforms actually read them from the code. It is not limited to adding a few lines in the head section. You also need to ensure that the data is consistent, rendered at the right moment and available to social media bots. In practice, most issues stem not from the tags themselves, but from the way the page, images and platform caches are generated.

• First, check the actual link preview in the selected channels and compare it with the page source code.
• Next, analyse the templates separately for the homepage, articles, products, categories or landing pages.
• The next step is to define the rules for the title, description, image and URL for each type of subpage.
• Only then do you implement the tags in the CMS, template or page rendering layer.
• Finally, carry out validation, cache refresh and quality control on specific URLs.

The audit is best started with a few representative URLs, rather than a single example. Quite often the homepage looks fine, but a product, article or category already has duplicated tags, an empty description or a default image. It is worth checking whether the code contains several versions of the same field, whether the image is accessible without logging in, and whether the platform bot is not being blocked by robots.txt, server headers or hotlink protection security.

At the implementation stage, it is crucial to establish where the system draws the data for the tags from. If individual types of subpages use different content sources, it is worth documenting and organising this clearly rather than imposing one universal template across the whole site. One shared title, description and image scheme for the entire site usually lowers the quality of the preview and limits control over what the user will see. In the CMS, it is also a good idea to provide editorial fields where automatic generation does not produce satisfactory results.

The rendering method is also important. In sites based on SPA, changes introduced only in JavaScript may not be correctly read by social media parsers. Therefore, meta tags should be rendered server-side or via prerendering, so that they are visible immediately in the HTML source fetched by the bot.

After implementation, you should test a specific page URL, not just the model template. You need to verify the server response, redirects, final HTML code, availability of the image file and compliance with the canonical. Finally, cache must be refreshed in the platform’s tool, because without this the old preview may still be displayed despite the changes being implemented correctly. Only such a test shows whether the platform uses the correct image, does not overwrite the description and does not fetch a different URL than expected.

What are the most common technical problems with Open Graph?

The most common technical problems with Open Graph include: tags not visible to the bot, an incorrect image, an inconsistent URL and an out-of-date preview stored in the platform cache.

In practice, the source of problems is often not the content itself, but the way the page is rendered. In SPA solutions, meta tags are sometimes added only after JavaScript has been run, and the social media parser does not always wait for that moment. If the tags are not rendered server-side or via prerendering, the platform may not read them at all.

The second common group of errors concerns the image. Platforms expect a single publicly accessible file at a full URL, without logging in and without problematic redirects. When the graphic is too small, in the wrong format, blocked by a CDN or returns a server error, the link preview loses its thumbnail or pulls a random image from the page.

• duplicate og:title, og:description or og:image tags added by several plugins or modules,
• a relative rather than absolute URL in og:image,
• a conflict between og:url, canonical and the actual address after redirects,
• access blocked for the bot by robots.txt, server headers or hotlink protection security,
• an image that is too small or poorly cropped, which looks good on the page but bad in the thumbnail,
• empty fields on individual subpages, even though the template works correctly for the rest of the site.

Quite a lot of confusion can also be caused by discrepancies between the individual meta tags. When title, meta description, canonical and Open Graph provide different information, the platform may decide on its own version of the title, description or address. The greater the consistency of the data in the page head section, the lower the likelihood that the preview will start “guessing”.

Platform-side cache is a separate issue. After tag fixes, the change does not appear immediately because the social network is still showing a previously saved preview. This does not necessarily mean there is a problem with the implementation. Often, you need to manually submit the URL for re-scraping in the debugging tool and only then assess the result.

In larger sites, there is also the issue of data exceptions. The template may have correct code, but an individual product, article or landing page may have no image assigned, have a title that is too long or pull the description from the wrong CMS field. That is why Open Graph should be verified on real URLs from different types of subpages, not only on one test page.

How to test and validate the correctness of meta tags?

The correctness of meta tags is checked by combining a review of the source code, a readout in the platform’s tool and an assessment of the preview after refreshing the cache.

The first step is to verify the HTML itself. You need to open the final source code of a specific URL and check whether the og:title, og:description, og:image, og:url and og:type tags appear only once, have the correct values and are not being overwritten by other modules. At this stage, it is easy to spot duplicates, empty fields and incorrect relative URLs.

The second step is a technical check of the assets that are meant to be fetched. The image from og:image should open without logging in, return a valid server response and not get stuck in an unnecessary redirect chain. The simplest practical test: copy the image URL from the code and open it in incognito mode, just as an external bot would.

The third step is to use the platform’s debugger or validator. The tool shows which tags have been read, which image has been selected, and whether any error warnings have appeared. It is also the place where you can usually force the URL to be fetched again and check whether the cache has been refreshed.

Once you have checked it in the tool, it is worth assessing the result in practice as well. Not every platform will display a link in exactly the same way, even with correct tags, because some services shorten the description, crop the image differently or omit selected fields. The aim of validation is not identical appearance everywhere, but a predictable and readable preview in the most important channels.

A good practice is to test using a short sequence: real URL, source code, image availability, server response, readout in the debugger, cache refresh, preview check after publication. This order saves time because it immediately helps separate a content-side error from a technical issue. If the site has many types of pages, it is worth going through the same path for an article, product, category and landing page.

At the end, it is a good idea to compare the result with the rules adopted for the given template. The title should be short and unambiguous, the description must not be cut off halfway through an idea, and the graphic must remain legible after cropping. The most common post-implementation mistake is treating the test as passed just because the tags are in the code, even though the preview still looks poor.

What are the best practices for implementing Open Graph?

Best practices for implementing Open Graph include matching tags to the page type, maintaining data consistency and testing live URLs after every change. Most problems stem from a “one set for everything” approach, which only works correctly on some pages. Open Graph should be treated as a separate layer of link presentation, not an automatic add-on to SEO. This makes it easier to set sensible rules for articles, products, categories and landing pages.

A good practice is to prepare separate rules for generating og:title, og:description and og:image for each important template. The title for social media should be concise and readable, rather than just copied from the title tag. The description should complement the heading instead of repeating it word for word. The less randomness there is in the CMS rules, the lower the risk of odd previews after sharing a link.

The image needs to be prepared as if it were a key element of the entire preview. In practice, it is best to stick to a single main file for a given URL, at a full absolute address, without blocks, without logging in and without unusual redirects. The graphic should remain legible after the thumbnail is cropped, which is why small text, thin lines and elements at the edges often fail. If a company uses several page formats, it is worth preparing a package of social share graphics straight away instead of relying on automatic cropping.

The implementation should work in harmony with other signals present in the page code. When canonical points to a different address than og:url, or the Open Graph content clearly differs from the on-page data, the platform may fetch the wrong URL or show an unpredictable preview. The same happens with duplicate tags when several plugins or modules generate them at the same time. The safest option is to have one set of sources of truth for the address, title, description and image.

From a technical point of view, it is worth making sure that the meta tags are available immediately in the HTML code returned by the server. This is particularly important on SPA-based sites, where changes added only by JavaScript may not be picked up by social platform parsers. If the frontend architecture requires it, SSR or prerendering for bots should be implemented. The fact that it is “visible in the browser” does not yet mean that the link preview will work correctly.

• define a minimal set of tags for each page type: og:title, og:description, og:image, og:url, og:type and Twitter Cards equivalents if needed,
• provide editors with fields for manual adjustments where automation falls short, for example on important landing pages and campaigns,
• test specific URLs after publication, because problems often come from exceptions in the data on a single page,
• refresh the cache in platform tools after changes, otherwise the old preview may persist despite correct code,
• keep a short implementation checklist for developers and marketing to keep consistency between content, graphics and code under control.

The most effective process is one in which the Open Graph implementation has an owner and clearly defined maintenance rules. When nobody keeps an eye on images, CMS exceptions, language versions and tests after template changes, the quality of previews quickly takes a back seat. In practice, this is not a one-off fix, but a small yet important element of publication quality control.