“Like”-able Content: Spread Your Message with Third-Party Metadata

Giving content proper structure is one of the most important things we can do—because the more structure we have in our content, the freer it becomes. Most of the time, structured content’s classifications and divisions allow for the content’s presentation on a multitude of platforms.

Article Continues Below

By breaking content down into its natural components, we ensure current and future compatibility and display in a wide range of devices and environments. Third-party metadata schemas, like Facebook’s Open Graph protocol and Twitter Cards, build on this ideal. And they are quickly becoming part of what it means to have a modern and complete online presence.

Facebook’s Open Graph protocol, or OG (not to be confused with rapper Ice-T’s 1991 album, “O.G.”), builds on the notion of compatibility by way of appropriately breaking down content into chunks, but from a platform-specific point of view. Twitter also rolled out a metadata scheme of its own, called Twitter Cards. These metadata protocols serve a similar function—to provide a better user experience around content shared on social platforms.

Basically, Twitter Cards and OG are discrete sets of metadata. Certain social platforms look at that metadata and display parts of it, as appropriate. In Twitter, you might see them as summaries of news articles or images in your feed. On Facebook, OG most visibly manifests itself in the image, title, and description of a shared website. (Note that this is separate from Facebook’s recently unveiled “Graph Search.” OG provides a common language for content, while Graph Search allows you to search for Facebook users based upon relationships and associations within Facebook itself.)

Now, if the rest of our content is already future-friendly, why would we have a need for such a thing?

People share things#section2

When we see something we really like online, we share it. Some copy and paste the URL into an e-mail. Some print it out and mail it with a stamp. And millions upon millions of others use their favorite social networks: Facebook, Twitter, LinkedIn, etc.

If you share a link via e-mail, you’ll probably provide a bit of context so they’ll know what’s what. A single, unsolicited URL in an e-mail without context raises red flags for all sorts of spammy, phishy reasons. Most folks avoid this situation by adding something like, “Hey, check out this cat video. SOOO CUUUTE.” But even that takes some effort.

Content producers don’t have much influence in this arena. We can’t bring along page metadata when someone pastes a URL in a blank e-mail. However, the social realm affords us a bit more room.

Standards for sharing#section3

In olden times, when that cat video was shared on Facebook, it filled in the title, description, and image slots with whatever metadata existed on the page. It may have been a garbled title with some errant HTML all up in it. Maybe you’d see the description of the homepage from 1998. Or you might get a badly cropped version of the logo as the image. The case was clear: we would all benefit from some standards, here.

When Facebook sought to establish a standard for populating those little shared-content boxes that show up in our social network feeds, they were kind enough to do it in an open fashion. The beloved Dublin Core Metadata Element Set, a standard from the library and computer science world, serves as its foundation and starting point.

Facebook created this standard for its own use—it has the level of complexity and functions that Facebook requires. However, other platforms, like LinkedIn and Google+, populate their content-sharing boxes with OG metadata as well.

Facebook, LinkedIn, and Google+ all look to OG when dealing with shared content; but in its absence, these social platforms will ultimately take whatever metadata they can get. This may not put forth the best face for an organization, adding up to a poor experience for everyone involved.

Twitter Cards, on the other hand, serve the singular purpose of providing an experience in Twitter and its supported apps only. The minor differences between Twitter Cards and OG address Twitter’s own content and display needs.

Twitter’s unique environment of sharing via retweets created some attribution problems. I might share a link, but the 140-character limit doesn’t always allow me to fit in a comment and proper attribution to the content creators or owners. Twitter Cards seek to officially establish and preserve content authorship and ownership with dedicated fields in the Twitter Card metadata schema.

Smartly, Twitter crafted its own metadata schema to maintain parity with other social platforms. Content creators and site owners who incorporate the Twitter Cards schema can now provide a richer shared-content preview experience. Twitter Cards allow people to view, watch, or listen to content like images, video, and audio without leaving the Twitter environment. As a result, people may stick around on Twitter longer, which Twitter likes. (Not just out of niceness, mind you. They can place more ads in front of more eyeballs that way.)

Content-y fields forever#section4

How does this all work? If you’ve gone down the path of structured content, or are about to, adding third-party metadata schemas should be relatively easy. Code placed in the head of each page does the heavy lifting. In fact, it lives right next to the old-school meta tags.

Those in the old guard might remember the browser-specific tags of HTML 3.2 in 1997. Luckily, OG and Twitter Cards aren’t dependent upon Netscape Navigator. NO WORRIES. But this might still reek of catering to the flavor of the moment, shackling us all to a rigid standard dictated by an outside entity. Structured content intends to set content free, not rein it in. And what happens when yet another metadata schema comes along?

Granted, there are some similarities between these third-party metadata schemas and browser-specific tags. Implementing them may seem like the least future-friendly thing to do. Ultimately, site owners will weigh the costs of implementation against the improvements to user experience and benefits to a significant potential user base (like Facebook and its 1 billion users). The available field options in both of these schemas encompass multiple formats and types. That’s a great thing, since shared content takes many forms—from cat videos to animated GIFs to regular old web pages.

For the sake of efficiency, it’s best to implement basics and only add support for the content formats and types you plan to publish (and by extension, encourage the sharing of). If audio isn’t your stock and trade, then there’s little need to set up your CMS to handle third-party metadata schemas for it.

Both OG and Twitter cards aim to provide an appropriate, in-platform presentation of shared content in its most popular forms:

  • Articles get a text summary and small image preview
  • Audio files get an audio player
  • Video clips get a video player
  • Images get a larger image preview

OG developers created several predefined objects—content types like videos, audio files, web pages, etc.—each with its own meta properties. When the object type is an audio file or video clip, the metadata associates it with a suitable player, if applicable. This list of attributes provides detail on each meta tag for an article:

<meta property="og:type"	 content="article"> 
<meta property="og:url"		 content="URL of this object">
<meta property="og:site_name"	 content="Name of site hosting article">
<meta property="og:image"	 content="URL to an image">
<meta property="og:title"	 content="Name of article">
<meta property="og:description"  content="Description of object"> 
<meta property="article:author"	 content="URL to Author object">
<meta property="article:section" content="Section of article">
<meta property="article:tag"	 content="Keyword">

It all adds up to look like this on Facebook:

Facebook link to the St. Paul Chamber Orchestra website

Twitter Cards have a similar protocol, with specific properties established for articles, video, audio, and images. The article-type content Twitter Card metadata looks like this:

<meta name="twitter:card"	 content="summary">
<meta name="twitter:url"	 content="URL of this content">
<meta name="twitter:title"	 content="Name of article">
<meta name="twitter:description" content="Description of content">
<meta name="twitter:image"	 content="URL to an image">

These optional Twitter Card items also allow you to attribute content to an organization’s or creator’s Twitter handle:

<meta name="twitter:site"	content="@username">
<meta name="twitter:site:id"	content="Twitter ID">
<meta name="twitter:creator"	content="@username">
<meta name="twitter:creator:id"	content="Twitter ID">

This is how it looks on Twitter:

Twitter card for a New York Times article link

Creating this content: focus and fill it up#section5

Metadata is content, too. It’s subject to all of the same process, workflow, and governance protocols you may already have in place. As always, it should support the core message(s) of the page. These third-party metadata schemas do have some practical constraints as well.

Field limits#section6

Be aware that certain fields have display limits on different devices, particularly the description fields. When writing these descriptions, keep it to 160 characters or fewer and this field’s automatic (and sometimes display-dependent) truncation shouldn’t be a problem.

Image selection#section7

Effective, appropriate images can make the difference between a friend avoiding or clicking on a link in her news feed. Image guidelines for article-type pages in OG are pretty straightforward: 200×200px minimum with a maximum aspect ratio of 3:1. However, a square image will allow the best use of the space. Twitter cards resize any image over 120×120px, so you would be safe using that same 200×200px image you’ve already created for your og:image.


As you focus your message on the page, focus that message in the metadata. If you’ve crafted a page with a single idea or concept in mind, the description should come fairly easily. If not, prioritize and ensure that the message is consistent. If a page has four key points, focus on a single one. The title, description, and image should all align with the point you wish to showcase in these social platforms.

For example: Microsoft’s new Surface tablet enjoyed quite a bit of press as it launched. The Surface Windows 8 Pro page on Microsoft.com did not enjoy preparation for a new Open Graph world. (It uses neither OG nor Twitter Cards.)

This page has several messages, with hierarchy established by placement upon the page:

  1. Buy this device
  2. You can put apps on this device
  3. This device is safe
  4. You’ll enjoy stellar performance on this device
  5. This device has a nice screen
  6. Use a stylus to write on this device like a Palm Pilot
  7. Buy this device

However, this hierarchy is not reinforced by the metadata. Microsoft gives the Surface’s performance top billing by titling the page “Surface Windows 8 Pro is powerful.” But I don’t see anything about the performance until I scroll down and reach the fourth message on the page. That’s a pretty big disconnect. The page’s meta description delivers even less.

Try to share this link in Facebook, and this unfocused approach becomes even more apparent. People can choose between two 1280×450px images, far from the ideal size or aspect ratio for display on any social platform news feed. Meanwhile, the rote “Learn more” call to action mercifully stops short of an old-timey “click here,” but still screams old-school marketing models.

Facebook link to a Microsoft page

What could Microsoft have done in this situation? Better represent the page on social platforms by focusing on one of those core page messages. Then:

  • Use a more compelling and descriptive title. Sure, Surface Windows 8 Pro is powerful, but compared to what? The competition? A weightlifter? A Ford Mustang? How will it help me do what I need to do? And they haven’t yet mentioned that it is a tablet. Pretty important detail, that.
  • Take advantage of those 160 characters in the description. Sum up the page here, then maybe say “learn more.” What will I learn if I visit this page? Can I buy one there? Does it have Solitaire? Why should I consider this versus the competition?
  • Provide an interesting and representative image. Social platforms are stingy with real estate. Use it up. Create an image that accurately represents and supports your message. And format it properly to avoid its dissection via automatic image cropping.
  • Give them a reason to click. Present a clear, concise call to action appropriate for the platform. And make sure you deliver on what you offer. (All time-tested, these tips.)

Workflow and implementation become triage and training#section9

Adding OG and Twitter Cards to older, existing pages might be a bit tougher than incorporating them in new content. Especially if you have thousands upon thousands of pages.

Consider a phased approach to provide consistency across your entire online presence, while allowing improvements to other, lower-profile areas as time allows. Focus on getting things in place on high-impact assets first, such as pages already seeing strong share activity. Then, meet minimum standards on others.

Though most pages on a site are technically shareable, people aren’t necessarily going to share them. Think of optimizing your “Contact Us” page for sharing. Bad idea. Map your current page types to some simple third-party metadata divisions:

Frequently shared pages#section10

Pages supporting active campaigns, blog posts, product pages, and pages with high profiles and traffic.

  • Requires the most time and resources.
  • Create page-specific metadata with input from subject matter experts. Write it with the same gravity as other marketing or promotional content.
  • Use unique titles, descriptions, and images.

Infrequently shared pages#section11

Transactional, transitional, or navigation pages.

  • Less resource-intensive.
  • Create section- or topic-specific metadata content to provide relevant (but not page-level) detail.
  • Use specific titles and section-specific descriptions across pages, but generic images (like your logo or icon).

Pages not intended for sharing#section12

These include pages like contact, legal disclosure, and the sitemap.

  • Least impact on resources, easiest to maintain.
  • Create generic metadata content to meet minimum brand standards.
  • Use specific titles, but a generic, site-wide description and generic images (your logo or icon works well, here, too).

Communicate the importance of these new fields to content creators and approvers, many of whom are likely avid Facebook users. Show them a good example of a site successfully using OG. Then show them a site not using OG at all. Chances are, they’ll get it right away.

A clear understanding of the uses of structured content chunks will give them the context they need to create appropriate content. (It’s worth noting that this isn’t unique to OG or Twitter Cards—this understanding is important for all structured content.)

A word of (cautionary) encouragement#section13

As with any third-party relationship, certain things are slightly out of your control. We’ve become accustomed to regular changes in hardware, Google search algorithms, and Facebook privacy settings. These changes are inevitably disruptive; all the more reason to keep a close eye on the evolution and development of these (and other) third-party tools and platforms.

While implementing third-party metadata schemas will add to the content creation workload, that extra effort will provide a much better user experience across multiple platforms and devices, both current and upcoming. Crafting content in discrete chunks with an eye on universal application and flexibility is the way of the future. “Like” it or not (groan).

About the Author

Clinton Forry

Clinton Forry is vice president, content strategy at Weber Shandwick. He writes about content on his Content-ment blog. He’s on Twitter as @wd45. When he’s not thinking about content, he’s probably thinking about vinyl LP jazz records. And he fancies wearing ties with his paisley and floral print shirts.

29 Reader Comments

  1. It’s not entirely true to say that we can’t bring along page metadata when someone pastes a URL in an email. We can design the URL to be readable and include a little metadata — perhaps the type of page, publication date if relevant, and an abbreviated title. This URL on ALA includes the type and the title, but there are some websites that use meaningless unreadable URLs.

  2. @Barney — I totally agree that URL design is helpful and important, but link shorteners and truncation are the rule of the road these days. URL design will only get you so far (and it won’t get you very far at all with folks who don’t even know what a URL is).

  3. I’ve started to use Twitter cards and the rel=author microformat to stand out in Twitter and Google search. It gives and air of authority to the post or search result.

  4. Great article–this is an important subject, and my opengraph.inc include full of these sorts of things seems to grow more refined every month.

    Regarding email, third parties like ShareThis actually use your OG tag info to populate their “share via email” feature, and the result, an HTML email, is pretty cool. I tell clients to use it to share stuff with friends (or board members) who don’t use Facebook much. People get a much better idea of what the link offers this way.

  5. Wow! You really cover all of the basics here. I have dabbled with the Open Graph tags a bit on our website, but your examples are truly stunning! I will have to go back through our web design website and make sure that we are representing our website in style in social media!

    Bookmarked this so I can go back through my website! Thank you so much!

  6. Thanks @forry for giving us a excellent idea about the importance of website content.

  7. Great that this is getting some more attention! Though personally, I think it’s a shame that Facebook and Twitter decided to roll their own and didn’t build on already standardized technology like RDF (and RDFa).

  8. @Marc Carson – The ShareThis use of third-party metadata is an interesting (and smart) one. I’m guessing they’ll see even better returns on it if and when OG becomes more ubiquitous.

  9. @mb21 – I think Facebook and Twitter had a few platform-unique quirks that fell outside of existing standards. (Specifically with user IDs and so on.) That said, without the luxury of millions of users, they would have a tougher time trying to establish/impose metadata standards.

  10. Fantastic post here Clinton. Microdata is going to be a much bigger force behind brand messaging than ever before. Who would of thought that 10 years ago?

  11. Nice article, well explained and of course a developers nightmare without standardisation. Remember the browser wars of the 90’s?!

  12. Thank you! Very nice article, very didactic. Very worrisome to standardization efforts. IE also used to own a huge share of the browser market, and did what it did to us…

  13. The issue that I find with Twitter and FB implementing their own “tags” as such (i know its not a tag, but its network specific code) is that if each network does the same each page will have multiples of duplicate declarations.

    Also, LinkedIn’s implementation of using OG data appears to be a little hit and miss. Often it does not work.

  14. Microdata is quickly becoming an important part of content marketing most likely to better catalog the massive amounts of content being pumped out in the search space everyday.

  15. @Sebastian Green — that’s definitely true. If too many platforms outline their own standards for tags, we’ll soon have pages loaded with heaps of partially-duplicative metadata. Each requiring upkeep. It can turn into a governance nightmare.

    Organizations need to weigh the pros and cons of implementation against what they might gain in return.

  16. If you think about it, a lot of this can be automated. Titles will likely be the same as HTML titles, image thumbnail creation can be scripted to resize an articles representative image (although aspect ratio conversion can be a bit tricky here), and social network usernames can be linked to your authors in your CMS. It all depends on how you want to present the information on the different platforms, of course, but I, captain obvious, think automation has a role to play here to eliminate repetitive non creative work.

  17. @clinton great article! I personally have been hoping for some standard in this realm to help prevent us from having to create multiple sets of meta tags for specific services that may or may not be relevant for a brand in the future. We’re often adding Schema.org tags to our markup to aid in search visibility and cross platform sharing. In your experience, is it possible to substitute vendor specific meta tags for a more universally accepted open-standard like Schema.org?

  18. If you think about it, a lot of this can be automated. Titles will likely be the same as HTML titles, image thumbnail creation can be scripted to resize an articles representative image (although aspect ratio conversion can be a bit tricky here), and social network usernames can be linked to your authors in
    xuat tinh som

  19. Nice post! Curious…do you have any reccomendations for automated opengraph / meta tag testing services? Checked out Sitebeam. Have you used it or others?

  20. Nice article, Third Party meta data is really best according to Google because he is not use the promotion meta date. google hat promotion meta data in search engine result page. you need to insert free meta data in your website or post. Flicks point is offering third party meta date.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA