Open Graph Tags and How to Check Your Share Preview

Open Graph tags let a page describe itself to any app that shows a link preview: the title, a short description and an image. Getting them right takes four steps. Define the title, type, image and canonical address on every page. Serve the image from a public address that opens without a login. Keep og:url identical to the page canonical. Look at the result in a sharing debugger before you publish. These tags are not a Google ranking lever, but they decide what people see the moment your link lands in a chat, a feed or an email.

It is written for store owners, marketers and developers who run their own site and want links to products, categories and articles to look consistent when shared. Platform crop sizes and cache behavior change often, so for those details rely on the current help page of each platform.

What Open Graph does, and what it leaves alone

The Open Graph protocol (Opens in a new tab) describes a web page as a rich object using a small set of meta elements placed in the head of the page. Each element has a property attribute that names the tag and a content attribute that holds the value. An app that understands the protocol can turn a pasted address into a card with a title, a description and a picture. Without the tags the app has to guess, and guesses are often wrong: a cookie banner headline as the title, a logo as the picture, or no picture at all.

Two limits are worth stating early. The protocol was built for link cards, not for search engines, so it carries no ranking promise. And it is an open protocol, not the feature of one platform: every app that reads it decides how to display the result. The same tags may produce a wide image card in one app and a small thumbnail in another. Building to the definition in the protocol rather than to the look of one platform keeps your setup stable when apps change their design.

Where Google mentions these tags

Google refers to Open Graph in two places. The title link documentation (Opens in a new tab) lists the sources Google can use for a title link: the title element, the main visible title, heading elements, the og:title tag and several other signals. It does not say how much weight og:title carries. The site name documentation (Opens in a new tab) calls WebSite structured data the most important signal for a site name and lists og:site_name, the title element, headings and home page text as other things it considers.

The snippet documentation (Opens in a new tab) reads differently. Google says it builds snippets primarily from page content, uses the meta description only when it describes the page better than the text itself, and the page does not mention Open Graph at all. In practice that means writing an og:description will not control the description in search results. To shape or limit what appears in search, work with the page copy, the meta description and the snippet controls, which are covered in the guide on controlling search snippets.

A realistic expectation

A good set of tags gives you a card that is readable, consistent and recognizably yours when someone shares the page. That can influence whether a recipient clicks. Higher organic rankings, more shares or more backlinks are outside what these tags promise. How social sharing relates to search visibility is a separate debate, discussed in the article on social signals and backlinks.

The four required properties in practice

According to the protocol, every page needs four properties. The table summarizes each one with the mistake that shows up most often.

Optional properties include og:description, og:site_name, og:locale, og:locale:alternate, og:determiner, og:audio and og:video. For most product and article pages, a set of seven covers the need: title, type, image, URL, description, site name and locale.

Writing the title

Each page should carry its own title. It does not have to match the title element exactly. A card does not need the brand suffix that a browser tab benefits from, so a shorter, more direct line can work better. What you want to avoid is two titles that contradict each other, because that shows one story in search and another in a chat. Google advises against repeated or boilerplate text in title elements, and the same reasoning applies here: a catalog of a hundred products that all share a single store tagline produces a hundred identical cards.

Choosing the type

The protocol groups types into verticals. Besides music and video types there are article, book, profile and website, and a page with no markup is to be treated as a website. A blog post fits article, while the home page and category pages fit website. Choosing article unlocks extra properties such as published and modified time, author, section and tag. Dates follow ISO 8601.

The optional description and site name

The protocol asks for a description of one or two sentences. Copying the meta description is acceptable, but a reader of a card has not seen the page yet, so make the first sentence stand on its own. og:site_name carries the name of the larger site the page belongs to. Because Google lists it among the signals it considers for site names, keep it consistent with the brand spelling on your home page. The guide on site name and favicon problems in Google explains how to audit that consistency.

Building a share image that survives cropping

The image is the most visible part of a card and the part that fails most often. The protocol defines a main og:image tag and structured sub-properties: og:image:url, og:image:secure_url, og:image:type, og:image:width, og:image:height and og:image:alt. They give an app information beyond the address: file type, dimensions and what the picture shows.

Address and access

Use an absolute address that opens for anyone. A file behind a login, blocked from crawling or reached through a long redirect chain may not be readable at the moment of sharing. For pages that require https, the secure_url sub-property exists. Google's image documentation (Opens in a new tab) recommends crawlable image URLs and a stable URL when the same image is used on several pages, so that it can be cached and does not have to be requested again and again. Renaming the share image with a new version number on every release works against that.

File format

The Google image guidance lists JPEG, PNG, WebP, GIF, SVG, BMP and AVIF as supported formats. The Open Graph document does not state a preferred format; it only lets you declare the MIME type through og:image:type. So the format decision depends on what the apps you care about can render, and that support is not described in the documentation. The safe route is to test a real share on the target platform and see the picture. For file weight, moderation is enough: do not inflate the file beyond what the quality needs, which also helps page speed.

Width, height and framing

og:image:width and og:image:height declare the pixel size. In the protocol example one image has dimensions and another has none, so the fields are not mandatory. Declaring them lets an app prepare the layout before it downloads the file. Which aspect ratio looks best depends on the platform, and the protocol does not recommend one. A practical framing rule is to keep the key element (product, logo, headline) near the center and keep text away from the edges, since different apps crop differently.

Alt text

The protocol says that if you specify an og:image you should specify og:image:alt too. It describes the alt value as a description of what is in the image, not a caption. A good example is "A handmade ceramic mug on a white table with a wooden spoon beside it". It does not need to be identical to the alt text of the image on the page, but both should describe the picture accurately.

One page, one address: og:url and canonical

The protocol defines og:url as the canonical URL that serves as the permanent ID of the object in the graph. That is very close to the job of the canonical link element. The protocol page does not explain how og:url relates to rel canonical, so keeping them consistent is your responsibility.

Google's canonical guidance (Opens in a new tab) offers plain rules: use absolute URLs, give the canonical page a self-referencing canonical, link internally to the canonical URL and do not declare different canonicals for the same page through different methods. It also contrasts a clean product URL with one carrying a tracking parameter. Applying those rules to Open Graph gives a simple instruction: write the clean, https, absolute address that matches your canonical.

When one page has two addresses

If a product can be reached at /product/mug and at /product/mug?utm_source=newsletter, both versions should output the same clean og:url. The share link may carry a parameter while the card identity is read from the clean address. A side benefit is that signals stay together rather than splitting between versions. How to handle parameter URLs more broadly is covered in the guide on canonical tag issues, audits and fixes.

Redirected addresses

Do not put an address that redirects into og:url. If the page redirects to the non-www version, write the final non-www address in the tag. Otherwise the card has an identity problem between two addresses, and an older version of the preview may keep appearing.

Language tags for a bilingual site

For a site with Turkish and English versions, Open Graph can carry language and region. og:locale declares the language the tags are written in using the language_TERRITORY format, and its default is en_US. So if a Turkish page omits it, an app may treat the page as English. Use tr_TR for Turkish pages and en_US or en_GB for English ones. og:locale:alternate lists the other languages in which the page exists, as repeated tags.

Two cautions apply. The tag content must match the page language, since an English og:title on a Turkish page shows a confusing card. And Open Graph locale tags do not replace hreflang, which tells search engines about language versions and is a separate job. In templates, derive the language value from one variable so the two systems cannot drift apart.

Images that contain text

If the share image has a headline printed on it, you need one image per language, otherwise the English page is shared with a Turkish picture. A simpler approach is to keep text out of the image and let the card text carry the headline, so a single image serves both languages.

When tags collide

The protocol allows a tag to be repeated and says that, in a conflict, the first tag from top to bottom is given preference. Structured properties attach to the most recent root tag, and when another root tag is parsed the previous structured property is considered finished. Together these two rules make the order of image tags matter.

Suppose a page has three og:image tags and the width tag sits in the wrong place: the dimension then attaches to a different image than you intended. The correct pattern is a root tag immediately followed by its own sub-properties. A theme, a plugin and hand-written code can each print their own set of tags, and the Open Graph protocol says the first tag is the one preferred.

Finding duplicate sources

The check is simple. Open the page source, list every line that starts with og:, and count how often each property occurs. If og:title or og:url appears twice, switch off one source. Two different og:url values are especially harmful because they blur the canonical signal.

Choosing the type by template

Each template type needs a slightly different set. The table is a practical starting point.

The type list in the protocol has no product type; a page without markup is treated as a website. Product facts such as price and availability are marked up separately in Google's product structured data, which is a different topic from the share card.

Article properties

On the article type, published_time and modified_time use ISO 8601. Keep them in line with the date visible on the page and refresh modified_time when you update the text. The author can point to a profile page and the section to a category name. article:tag is available, but it should reflect the real topics of the piece rather than become a pile of keywords.

A walkthrough before you publish

Writing the tags is half the job; the other half is seeing the result. This sequence works as a pre-launch checklist.

1. Open the page source and confirm that the og: tags are present in the response. What you see rendered in a browser can differ from the raw response.
2. Confirm all four required properties exist and that each appears once.
3. Open the og:image address in a new private window. If it does not load, the card will not show a picture either.
4. Compare og:url with the canonical element and confirm they are the same absolute address.
5. Confirm og:locale matches the page language and differs between the TR and EN versions.
6. Read the og:image:alt value and check that it describes the picture and does not repeat the title.
7. Test the address in the sharing debugger of the target platform and refresh the preview.
8. Send the address in a real messaging app and look at the card on a phone.

When the preview does not refresh

Platforms can store a preview of an address for some time. If you fixed the tags but still see an old card, use the preview refresh tool of that platform. Cache length and refresh methods differ by platform, so check the current help page for the details.

Tags added by script

If the tags are inserted by a script after the page loads, an app that reads only the first server response may not see them. The documentation does not describe this behavior, so the safe choice is to print the tags in the initial HTML response.

Who owns each tag

Tag errors often come from the job belonging to nobody. Content staff know the titles, design knows the images, developers know the template, and an SEO owner knows canonical and language. The table proposes a split for a small team.

This split is a suggestion; in a small team one person can hold all of it. What matters is that the checklist has an owner and is not skipped on publishing day.

After a template change

Theme updates, a new SEO plugin, a product template rewrite or a CDN move can break tags quietly. The page looks normal in a browser and the problem only appears when someone shares it. Add the tag check to the acceptance list of every template release: compare the og: lines for a home page, a category, a product and an article, verify og:url against canonical, make sure image addresses still open and test one page in the platform debugger.

When an image moves

Renaming or moving an image file can break the card of every link shared earlier. Google recommends a stable URL for images reused across pages. If a move is unavoidable, leave a permanent redirect from the old address to the new one and update the tag at the same time.

Example scenario: an independent bookshop

Example scenario: A small online bookshop runs its catalog and a reading blog on the same template. The owner pastes a blog link into a messaging app and sees a card with the shop name and an empty grey box instead of the cover picture.

The source shows a pattern: og:title is a fixed shop name on every page, og:image is a relative path, og:url carries the campaign parameters from the newsletter link, and og:locale is missing. The fix goes in order. The title is built from the article headline field. The image address becomes absolute and public, with width, height and alt text added. og:url is read from the same field as the canonical and written without parameters. og:locale becomes en_US for English articles and tr_TR for Turkish ones.

Afterwards the owner tests the address in the platform debugger, refreshes the preview and confirms the card in a real message on a phone. The order matters more than any single tag: source first, then image address, then address identity, then preview test.

Common mistakes and fixes

Campaign links

Adding parameters to campaign links is normal. The point is that parameters must not change page identity: og:url and canonical stay the same, and tracking parameters live only in the link. Then the same page has one card identity no matter which channel shared it.

Keeping the share image honest

The share image and the main picture on the page do not have to be the same file, but a mismatch hurts trust. If the card shows one product and the page shows another, the click feels like a trick. The image should represent the topic of the page truthfully. For the search side of image work, see the guide on image SEO for Google.

Frequently Asked Questions

Do Open Graph tags improve Google rankings?

The documentation makes no such claim. Google lists og:title among the sources it can use for title links, but it does not promise any ranking effect. The real job of Open Graph tags is to define the preview that appears when a link is shared.

Which Open Graph tags are required?

The protocol requires four properties on every page: og:title, og:type, og:image and og:url. og:description, og:site_name and og:locale are optional but generally recommended.

Should og:url match the canonical tag?

The protocol defines og:url as the canonical URL and permanent ID of the object. Declaring two different canonical addresses for one page is risky, so the safest practice is to make both point to the same absolute URL.

Is there one correct share image size?

The Open Graph document does not recommend a size; it only lets you declare width and height. Crop and size expectations differ between platforms and can change, so check the help page and the sharing debugger of the platform you target.

My preview will not update. What should I do?

First confirm that the tags are present in the page source and that the image address opens without a login. Then use the preview refresh tool of the platform in question. Platforms can keep an older preview for a while, and how long varies by platform.

Can TR and EN pages share the same Open Graph tags?

Title, description and og:locale should be written in the language of each page. The image can be shared, but if it contains text you may need one image per language.

Conclusion

Open Graph tags are a small job that sets the first impression of every shared link. In short: define og:title, og:type, og:image and og:url on every page; add description, site name, locale and image alt; keep the image address absolute and public; tie og:url to the same clean address as the canonical; avoid producing the same tag from several sources; and look at the preview in the target platform before you publish. Google documentation lists og:title among title link sources and og:site_name among the signals for site names, but these tags are not a ranking promise. Platform crop and cache behavior can change, so check current help pages before you rely on a specific detail.

If you want your brand pages to read well wherever they are shared and to gain visibility through content on publisher sites, you can browse the guest post listings on Akua Adforce; scope and terms are stated on the relevant product page.