These days, almost every website encourages visitors to share its pages on social media. We’ve all seen the ubiquitous Facebook and Twitter icons, among others, just begging to be clicked. This comes as no surprise as sharing via social media, the internet incarnation of word-of-mouth, is one of the most effective ways for businesses and individuals to gain awareness.
When users choose to share these links, it is tasked to the web developer to make sure that the associated web pages are properly prepared, which is what we’ll look at now. Facebook and Twitter are, by far, the most popular social media platforms, so let’s focus on those two.
Sharing on Facebook and Twitter
Facebook offers developers various options on how a shared web page appears in its timeline depending on the website’s content. Unless otherwise specified, every website defaults to the type called, appropriately, “website”, which is the example we’ll use.
Let’s say someone has shared the home page of a fictional travel company – Facebook displays it like this:
Twitter, as well, has multiple ways to format shared web pages that appear in its feed, but we’ll look at the one that’s quite similar to the above example from Facebook, which Twitter calls the “Summary Card with Large Image”:
As we can see, each features multiple attributes of the shared Web page:
- a prominent image and title
- a description
- the domain name
Proprietary <meta> Tags
How do we specify these attributes? With <meta> tags. When a link is shared, both Facebook and Twitter scrape the associated web page and read its <meta> tags to display the appropriate information.
Facebook uses <meta> tags leveraging the Open Graph protocol, a classification system for Web pages that extends beyond those <meta> tags already defined in HTML5. A complete list of <meta> tags available can be found at the Open Graph Web site. There are so many from which to choose that it can be somewhat intimidating, but only four are actually required:
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="https://www.imdb.com/title/tt0117500/" />
<meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />A previous version of this post listed these four
<meta property="og:title" content="European Travel Destinations">
<meta property="og:description" content="Offering tour packages for individuals or groups.">
<meta property="og:image" content="http://euro-travel-example.com/thumbnail.jpg">
<meta property="og:url" content="http://euro-travel-example.com/index.htm">So we were either wrong or it changed.
Twitter has its own <meta> tags that are similar to the Open Graph protocol, but uses the “twitter” prefix instead of “og”. As with Facebook, only a few are required. The type of display format we’re requesting from Twitter is also specified:
<meta name="twitter:title" content="European Travel Destinations ">
<meta name="twitter:description" content=" Offering tour packages for individuals or groups.">
<meta name="twitter:image" content=" http://euro-travel-example.com/thumbnail.jpg">
<meta name="twitter:card" content="summary_large_image">Both Facebook and Twitter offer guidelines on how to use the above <meta> tags. They are quite similar to each other, although they can be somewhat subjective in interpretation. Note that, for our purposes, Facebook is referring to the shared Web page when using the term “object”:
| Title | The title, headline or name of the object. | A concise title for the related content. [Maximum 70 characters.] |
| Description | A short description or summary of the object. [Between 2 and 4 sentences.] | A description that concisely summarizes the content as appropriate for presentation within a Tweet. You should not re-use the title as the description or use this field to describe the general services provided by the website. [Maximum 200 characters.] |
| Image | The URL of the image for your object. It should be at least 600×315 pixels, but 1200×630 or larger is preferred (up to 5MB). Stay close to a 1.91:1 aspect ratio to avoid cropping. | A URL to a unique image representing the content of the page. You should not use a generic image such as your website logo, author photo, or other image that spans multiple pages. Images for this Card should be at least 280px in width, and at least 150px in height. Image must be less than 1MB in size. |
| URL | The canonical URL for your page. This should be the undecorated URL, without session variables, user identifying parameters, or counters. |
Since these proprietary <meta> tags are, in the end, referring to the same elements, it would be ideal if there were somehow a way to reconcile the two. Fortunately, there is.
Reconciling
There’s no harm with having multiple <meta> tags that appear redundant. Too much information never hurt anyone except by adding a few extra bytes to the HTML file.
But for our purposes, and for the sake of brevity, we can leverage the fact that Twitter allows us to substitute Open Graph <meta> tags for its own. In the end, except for the necessity of specifying a display format, none of the custom Twitter <meta> tags are needed. This gives us the following, which could be considered the bare minimum of <meta> tags necessary to make a web page amenable for sharing on social media:
<meta property="og:title" content="European Travel Destinations">
<meta property="og:type" content="article" />
<meta property="og:description" content="Offering tour packages for individuals or groups.">
<meta property="og:image" content="http://euro-travel-example.com/thumbnail.jpg">
<meta property="og:url" content="http://euro-travel-example.com/index.htm">
<meta name="twitter:card" content="summary_large_image">Reconciling the guidelines for the image is simple: follow Facebook’s recommendation of a minimum dimension of 1200×630 pixels and an aspect ratio of 1.91:1, but adhere to Twitter’s file size requirement of less than 1MB.
Validating <meta> Tags
If there are any doubts about the legitimacy of paring down to these five tags, we can use the helpful Facebook Sharing Debugger and Twitter Card Validator. Both these tools will scrape any Web page hosted on a public server for relevant <meta> tags and display how it would look when shared. It will also list any errors and provide suggestions. So how did we do with our particular example? Twitter seems fine with things, but Facebook, on the other hand, lists one item as a warning:
This provides a perfect segue to talk about…
Social Media Analytics
What Facebook is indicating is that if you’re going to use their analytics tool, which they call Domain Insights, you must provide the unique ID number associated with your account. The tag would then look something like this:
<meta property="fb:app_id" content="your_app_id" />Twitter has something similar that they call Twitter Card Analytics. To get the most out of this tool, Twitter recommends using the following tag that contains the Twitter username that you want associated with the shared Web page:
<meta name="twitter:site" content="@website-username">
Keep in mind, though, that if you have no particular interest in using these analytic tools, then omitting the above two <meta> tags has no effect on how a shared Web page appears on a Facebook timeline or Twitter feed.
Anything Else?
Facebook documentation recommends one additional <meta> tag, though it’s not required. A tag that denotes the name of the Web site in which the shared page resides:
<meta property="og:site_name" content="European Travel, Inc.">Twitter suggests one other tag as well that is recommended, but not required:
<meta name="twitter:image:alt" content="Alt text for image">This provides an alternative image description for those who are visually impaired.
Final Markup
That should do it. To reiterate, when you look at documentation from Facebook and Twitter for sharing Web pages, there are many other tags available that can be used to specify different types of content. But, in general, the following will suffice:
<!-- Essential META Tags -->
<meta property="og:title" content="European Travel Destinations">
<meta property="og:type" content="article" />
<meta property="og:image" content="http://euro-travel-example.com/thumbnail.jpg">
<meta property="og:url" content="http://euro-travel-example.com/index.htm">
<meta name="twitter:card" content="summary_large_image">
<!-- Non-Essential, But Recommended -->
<meta property="og:description" content="Offering tour packages for individuals or groups.">
<meta property="og:site_name" content="European Travel, Inc.">
<meta name="twitter:image:alt" content="Alt text for image">
<!-- Non-Essential, But Required for Analytics -->
<meta property="fb:app_id" content="your_app_id" />
<meta name="twitter:site" content="@website-username">
This is so helpful, thanks!
One tiny detail missing for some validators:
Unless type is something different than “website”, it is redundant. We shouldn’t include code just to make random SEO-validators happy. At least as long as we can help it.
This is a very important meta tag. The og:type property is required by Facebook according to the Sharing Debugger (https://developers.facebook.com/tools/debug/sharing/).
Excellent post by the way, very useful!
Interesting that only 5 meta tags are needed! I did not know that.
Actually, while FB tells you, that og:title and og:description are needed, last time I checked they weren’t and they really should’t be.
HTML already has a proper title and meta:description tag and FB can perfectly well use those instead (although their scraping tools are otherwise quite flawed). So the proprietary tags are completely redundant, unless you want a different title/description in FB. I suspect the warning’s only purpose is to inflate the importance of their proprietary “system”.
og:url is similarly redundant, as it will usually be identical to your canonical url (which I think is more or less standard by now), which FB actually recognizes just fine. If you don’t have that, FB should and will just use the URL that was shared (last time I checked at least).
The only useful one is og:image – and it is actually really important, as FB does a terrible job of finding a proper Image of its own.
I didn’t check, but I would be very surprised, if it wasn’t the same with Twitter (as they even use the og-tags).
If you like clean code, I absolutely advise against redundant code/content and metas without a clear and “measurable” purpose. They do no good at all and do indeed harm (if only a tiny bit). Worst of all: If you stop being vigilant and start using “only a few” (without a serious fight), with most agencies/clients demand for ever more obscure “SEO-“metas will rise, your position will erode and your code will eventually be flooded with useless cruft.
The title of this very web page is
The Essential Meta Tags for Social Media | CSS-Tricksbut while sharing you would expect to show a clean title, i.e.The Essential Meta Tags for Social Mediawhile the bottom part will showcss-tricks.comas the website. This is only one example of why you would want to use a proper Open Graph title.Not to mention the fact the OG meta tags are also recognized by some other websites or apps (I think about e.g. Telegram or Whatsapp) which may not scrape the code as “well” as Facebook does (whatever “well” means). :)
This is not specifically about social meta tags, but might come in useful. It’s basically a document that shows everything that can/should be in the
<head>, and also includes the social meta tags available.https://github.com/joshbuchea/HEAD
DUDE!!! @Todd, That link is AMAZINGLY helpful.
Also, @Chris & @Adam, THANKS for this awesome article!!! i was just pulling my hair out trying to figure out the differences & what’s needed without being redundant etc; THEN google decided to present me with a link to this article. very helpful.
Good read! I didn’t know Twitter actually falls back to Open Graph when their proprietary format is missing.
I wish there was a Twitter share button on this page.
Godo post, didn’t know FB & Twitter had those tools. I found Yoast SEO in WordPress handles these tags pretty well for Twitter, Facebook, Pinterest, and even Google+. Helps that it doesn’t require entering titles and descriptions in multiple places for each page/post. However, I did use an mu-plugin to hide Yoast’s nags after every update.
I didn’t know that Twitter used OG as a fallback, makes sense though if they want to share engaging content.
Did you see Jeremy Keith’s post about how to make this a little more streamlined as well? https://adactio.com/journal/9881
The general gist is that Twitter uses the name attribute on the meta element, whereas the Facebook (OG) uses the property attribute meaning you can use them both on the same item and cover all bases.
I don’t think it will happen, but in case Twitter decides to drop OG support, just mix up the tag names and it should be fine. E.g.:
can anyone else pipe in on this? are these two things combined legit or would there be repercussions?
I don’t think Twitter employees will come to chase you :) but I found this link that might be interesting for your question: http://stackoverflow.com/a/28319985/1101509
Nice overview! You sometimes use
meta property=""and sometimesmeta name="", even among the different OpenGraph tags. Are these interchangeable or what’s the difference between them?In the final markup: Is the slash (near the end) needed?
Not in HTML (optional), but trailing slashes used to be required in XHTML. Also necessary in JSX.
I’d recommend to add
og:image:widthandog:image:heightas both help facebook to get the size of the og:image when a link is shared the first time.If both values are large enough, facebook will reserve the space for the large preview image, even if the facebook user shared the link faster than the image could be fetched.
If both values are not set, facebook will fall back to the smaller og:image in such cases.
An anonymous email said:
I was just trying to implement it on my site and found that Twitter will not display the large summary image unless the following are included:
I did not confirm the fact that Twitter won’t display an image without this (that seems highly unlikely), I did confirm those are real and the documentation says: