Open graph tags are the reason one shared link turns into a large card with an image and a clean headline while another turns into a bare URL nobody clicks. The specification at ogp.me describes the aim plainly: “The Open Graph protocol enables any web page to become a rich object in a social graph.” It was “Originally created at Facebook”, and it is now read by most platforms and messaging apps that build link previews. This guide covers what the tags are, which ones you need, how to add them, and why they are a sharing job rather than a ranking one.
What open graph tags actually do
When a link is pasted into a social post or a chat, the platform fetches the page and looks for Open Graph properties in the <head>. If it finds them, it uses them to build the preview: the title, the image, the description and the canonical address. If it finds none, it guesses, usually from the <title> element and whatever image it stumbles on first.
That guess is the problem the protocol solves. Without the tags, you hand the decision about how your page looks to someone else’s parser. With them, you choose the headline, the crop and the summary that appear in front of people deciding whether to click.

The received wisdom worth challenging is that Open Graph is an SEO task. It sits in SEO plugins and SEO audits, so people assume it affects search. Nothing in the protocol is about search engines. It describes objects for a social graph. Treat it as presentation for shared links, check it properly, and do not expect a ranking change when you add it.
The required and optional properties
The specification lists four required properties. Every page you expect to be shared should carry all four, and each one has a precise meaning.
| Property | Status | What it does |
|---|---|---|
| og:title | Required | The title of the object as it should appear in the graph |
| og:type | Required | The type of object, such as a website or an article |
| og:image | Required | The image URL that represents the object |
| og:url | Required | “The canonical URL of your object that will be used as its permanent ID in the graph” |
| og:description | Optional | A short description of the object |
| og:site_name | Optional | The name of the wider site the object belongs to |
| og:locale | Optional | The locale the tags are written in |
| og:image:alt | Image property | A text description of the image |
Two properties deserve more attention than they usually get. The first is og:url. The specification calls it the permanent ID in the graph, which means it should match the address you want shares counted against: the same clean URL your canonical tag points to, without tracking parameters. Mismatches split share counts and can surface the wrong address.
The second is og:image:alt. The specification is direct: “If the page specifies an og:image it should specify og:image:alt.” Most sites skip it. Adding it costs one line and makes the preview usable for people on screen readers. The image can also carry og:image:width and og:image:height, which help a platform lay out the card before it has downloaded the file.

How to add open graph meta tags
The tags are ordinary <meta> elements in the page head, using a property attribute rather than name. Here is a minimal, illustrative set for an article on example.com:
Use absolute URLs for the image and the page. A relative path that works in a browser means nothing to a platform crawler fetching the page from outside. Make sure the image is publicly reachable, not behind a login, a hotlink block or a firewall rule that challenges unknown bots.

Write og:title for the feed, not for the results page. It can match your title tag, but it does not have to. A search title often carries a keyword and a brand suffix that look clumsy in a social card. Our guide to SEO title length covers the search side; for sharing, a shorter, plainer headline usually reads better. The same goes for og:description against your meta description: related jobs, different audiences.
Adding them in WordPress and other CMSs
On WordPress you rarely write the tags by hand. Most SEO plugins output Open Graph properties automatically from the post title, excerpt and featured image, and add a social tab where you can override each one per post. That default is fine for most pages. The override is worth using on pages you actively promote, where the featured image is a poor crop or the title is built for search.
The common failure on WordPress is duplication. A theme, a social sharing plugin and an SEO plugin can each print their own set, and platforms then pick whichever they read first. View the page source, search for og:title, and make sure it appears once. If it appears twice, switch off the output in every plugin but one.

Headless and static setups need the tags in the server-rendered HTML. Platform crawlers generally do not run your JavaScript, so tags injected client-side after load may never be seen. If your framework renders the head on the server, you are fine. If it builds the head in the browser, check what a plain fetch of the URL returns.

Testing, caching and the limits of the tags
Test before you share, not after. The large platforms offer preview debuggers that fetch your page, show the properties they found and render the card. They also let you ask the platform to re-scrape, which matters because previews are cached. If a link was shared with a broken image yesterday, fixing the tag today will not change the cached card until the platform fetches again.
Some platforms also read their own tags alongside Open Graph and fall back to Open Graph where theirs are missing. Fill in Open Graph first; add platform-specific tags only where you need behaviour Open Graph cannot express.
The limitation is that you do not control the final rendering. The protocol tells a platform what your object is. It does not oblige that platform to show every property, crop the image the way you hoped or keep the same layout next year. Good tags make a strong preview likely; they cannot guarantee it.

Keep the job in proportion. Open Graph is not structured data for search. If you want search engines to understand an article, a product or an organisation, that is the job of schema markup, which uses a different vocabulary and is read by different systems. The two often describe the same page, and a well-built template outputs both from the same fields so they never disagree. Set the four required properties and the image alt text in your template once, check a sample of pages in a debugger, and then leave it alone. Revisit only when you redesign the template, change the featured image sizes or notice a share preview that looks wrong.
Frequently asked questions
Do open graph tags help SEO rankings?
No. They control how a link appears when shared on social platforms and in messaging apps. They are not a search ranking signal.
Which Open Graph tags are required?
The specification lists four: og:title, og:type, og:image and og:url. If you set og:image, it also says you should set og:image:alt.
Why does my share preview still show an old image?
Platforms cache previews. Fix the tag, then use the platform’s debugger to ask it to fetch the page again.
Should og:title match my title tag?
It can, but it does not need to. Write the title tag for search results and og:title for a social feed.
The takeaway Set the four required properties plus image alt text in your template, keep og:url canonical, test in a debugger, and expect better previews rather than better rankings.

