Adding Social Metadata To Episode Pages

[robbettis]

To more easily share new episodes on social, it would be nice to have the appropriate metadata added to episode pages.

<!--  Essential META Tags -->

<meta property="og:title" content="[episode title]">
<meta property="og:description" content="[episode summary]">
<meta property="og:image" content="[url to image]">
<meta property="og:url" content="http://domain.com/[episode number]">
<meta name="twitter:card" content="summary_large_image">

<!--  Non-Essential, But Recommended -->

<meta property="og:site_name" content="[podcast title]">
<meta name="twitter:image:alt" content="[Alt text for image]">

Pros:

• Users could set a podcast-specific or an episode-specific image for social sharing, depending on the implimentation. This would allow users to chose between the current default image (cropped cover art) and whatever custom image they upload, as seen here. It seems to me the appropriate implementation would include a podcast-specific default image and then the option to upload episode-specific images if desired, just like how Cover Art and Header Images are currently dealt with.
• Users have more control of what episode data shows in link previews on Facebook & Twitter. This could be done with the current fields (title, summary, etc) or new social-use-only fields could alternatively be provided for greater control (or perhaps for character restraints).
• Unlike the current Simple Share Page option, this links users to a page that includes all calls-to-action: embeded player, the full selection of subscription links, and full episode data.
• Twitter should pull the cover art, which is appropriate for their needs (square image) and Facebook should pull both the the cover art & og:image, which is appropriate for their needs (1200px X 630px).

Cons:

• Facebook caches preview images fairly agressively. So if users uploaded an image, shared it, and decided to change the image, they would likely need to a) wait a while for FB to recogize the change or b) manually request FB to re-scrape the page via their URL debugger. This would likely create some support headache as users that are not familiar with the debugger get confused by their image not updating.

Additionally, Dan mentioned (in Slack) the nightmare that is the Facebook API. As a marketer (read: not a developer), I can not speak to that. But in the situation outlined above, I'm not sure the API needs to be invovled. It seems that the API might be a step above what is needed to accomplish these users controls.

[dan]

Check out our Sharing page, which is designed for the specific purpose of sharing data, and should contain this information. Have you viewed source on that page?

[robbettis]

Correct, the metadata is on the sharing page. However, with either option, you do not have the ability to set a specific image for sharing to the various social networks. In my experience, to look at Facebook specifically, the preview image it defaults to is an awkwardly cropped version of the podcast cover art, which is less than ideal.

Twitter defaults to a square image, so you get the cover art in a smaller, but manageable way. However, in either situation, I would typically not share the show art every time I link to the podcast. (You used to be able to substitute alternative preview images with services like Buffer, but Facebook no longer allows that. They only honor what's on the page (favoring the og:image image, if available).

I find the episode pages to be much better landing pages for social traffic, as they include 'all the things' - the show links, sponsor info, and subscription links for all of the various podcast apps.

What is the benefit to having the share page/url? Is there a benefit I am overlooking other than the social metadata?

IMHO, if the episode page had the social metadata (especially with the ability to set Twitter and Facebook-specific share images), I wouldn't have a need for the share page. Neither addresses the sharing needs perfectly. Perhaps if they were combined, that could help simplify some redundancy.

Just my two cents. Thanks, Dan.