Google Article Rich Snippets Guide Updated for AMP

by Aaron Bradley on December 11, 2015

in Search Engines, Semantic Web, SEO

Google Article Rich Snippets Guide Updated for AMP

SEO strategist Kyle Sutton of ClickSeed noted today on Google+ that Google's guide to markup properties for article rich snippets* on the Google Developers site has been considerably expanded, and that this revision was doubtlessly "in preparation for the launch of AMP [Google's Accelerated Mobile Pages project] next year."

He goes on to note that the Google Structured Data Testing Tool now contains a filter for "AMP Articles" that returns warnings and errors for non-compliant markup.

The number of Article properties described in the guidelines have increased from six to seventeen. Only three properties were previously listed as required, whereas now the markup specifications list fourteen required properties, along with one recommended property.

A more detailed examination of these changes provides us, I think, with some insights on the direction Google is taking in their display, distribution and handling of articles moving forward, and very much substantiates Kyle's proposition that these changes have been made in support of the AMP initiative.

mainEntityOfPage added as a recommended property

Google now recommends declaring the canonical URL of the article for the mainEntityOfPage property "when the article is the primary topic of the article page" (which may not be the most edifying of annotations).

mainEntityOfPage usage is complicated enough that schema.org site provides a background note on this specific property, where it says "the mainEntityOfPage property serves more to clarify which of several entities is the main one for that page." I'm thankfully spared the embarrassment of trying to adequately explain how mainEntityOfPage works because my colleague Jarno van Driel has already written an excellent article that answers everything you ever wanted to know about mainEntityOfPage but were afraid to ask.

A couple of brief notes, though, in regard to mainEntityOfPage as it pertains specifically to article rich snippets and AMP.

First, the fact that Google recommends using this for articles suggests that the entity it really cares about when you feed its bots an article is, well, the article. That is, the focus from a structured data consumption point of view is on the entity being consumed (the article) rather than what it talks about (the topic of the article). This in turn suggests that the benefit Google hopes to gain from Article markup, in general, is the ability to better manipulate articles in the Google ecosystem due to an improved understanding of an article's components and provenance, rather than using the markup to better understand what an article is about.

Second, the syntax Google recommends employing here is likely a little obscure for many webmasters, and itself varies from the syntax employed in the AMP project documentation. The JSON-LD example on the Google Developer site uses @type and @id, JSON-LD keywords used to set the data type and uniquely identify the thing being described, respectively. The AMP guidelines on metadata don't mention mainEnityofPage, but the current JSON-LD example on the AMP GitHub repository does use it, where a simple URL declaration is employed.

mainentityofpage usage examples on Google Developers and the AMP GitHub repository

All of this to say that, should one prefer to use it, the simpler syntax is both supported by the AMP example and passes muster in the Google Structured Data Testing Tool.

headline now has a character count

An annotation has been added to the usage guidelines for the headline property saying that "Headlines should not exceed 110 characters."

Organic search marketers are well acquainted with 65-ish characters displayed in the linked title portion of a Google search snippet, which this considerably exceeds. So it seems likely this is related to the display of AMP articles.

In the post announcing the AMP project the news carousel pictured shows headlines of moderate length displayed without truncation, but it remains to be seen if that will be the case for articles that use the full 110-character allotment.

Character count of a Guardian article headline in a Google AMP example

Verbose, prescribed image information is now required

The previous guidelines for the use the of the image property required only an image URL, and the example listed an array of image URLs – consistent with the guideline that the data declared should be "[a] URL, or list of URLs pointing to the representative image file(s)."

The revised guidelines now make reference to a single image declaration, which should be "[t]he representative image of the article… that directly belongs to the article." Google, apparently, does not want to have to guess which of many images to use when displaying the article. Nor does it want to have to upsample, with the prior minimum image dimensions of "160×90 pixels" now replaced with the directive that "[i]mages should be at least 696 pixels wide."

The additional new requirement that image height and width now be declared (requiring the use of a nested ImageObject, which means that a simple URL declaration for image is no longer supported for article rich snippets) points squarely at support for AMP.

In brief, many AMP elements are concerned with the layout of an article, and explicitly declaring image dimensions gives Google the ability to render images associated with AMP articles correctly on different devices (one of potential optimizations of AMP is to "[r]eplace image references with images sized to the viewer’s viewport"). The requirement to declare image dimensions is also consistent with the amp-img requirement that the tag "[m]ust include an explicit width and height."

Additionally, the ImageObject url declaration in the new example is an absolute URL rather than the relative URL used in the prior example. This is consistent with the broad AMP markup directive – found in a comment in some AMP example code – that "[a]ll marked-up URLs should be absolute."

In aggregate Google doesn't want to have to parse code in order to calculate image dimensions and absolute image URLs: it now wants image data upfront.

Rich publisher data, including logo, now required

The publisher property wasn't previously required, and in fact wasn't referenced at all in the prior version of the specifications or examples for article rich snippets. Without recourse to speculation publisher data obviously makes it easier for Google to support a diversity of sources in news carousels and to correctly identify the publication source of AMP articles in various Google environments if it knows an article's publisher (I'm a little surprised a sameAs declaration didn't find it's way into the requirement).

The requirement that publisher logo dimensions be declared is a variation on the image requirements discussed above. The requirement for a logo itself can (along with the specifics of the size and aspect ratio requirements), again, be readily linked to the way in which AMP articles are displayed in Google's examples to date.

Publisher logos highlighted in a news carousel of AMP articles

The footprint of a logo container displayed in the Google AMP demo SERP screenshot displayed above is 600×60 px, exactly the size recommended in the revised article rich snippet documentation.

dateModified added

Joining the already-required datePublished property is the dateModified property. Obviously this is good information for any search engine to have when its pertinent, both for calculating the currency of article information and for generating visible article time-stamps and labels (like "updated").

An article's author must be named

As with publisher, author was not referenced at all in the previous version of the article rich snippets documentation, but is now a required property.

The relationship to AMP here is less obvious, but nonetheless the Structured Data Testing Tool generates an error for pages that lack the required author declaration. It's worth noting briefly that, AMP aside, explicit information about authors is extremely useful for search engines in coming to some sort of understanding of an author's topical expertise and authority (although, like the publisher markup guidelines, there's no requirement for a sameAs URI that could be used to disambiguate authors with the same name).

The expected type for author in the guidelines is Person, which at first blush is limiting, as many organizations – including news organizations – often publish articles that aren't ascribed to a specific author. However, the second expected type for author in schema.org, Organization, also passes validation for AMP articles in the Structured Data Testing Tool when that type is used for author.

The AMP articles filter and the morphing definition of "article rich snippets"

While the updated documentation on Google Developers is still headed "Enabling Rich Snippets for Articles", not including newly-required Article properties does not generate error messages in the Google Structured Data Testing Tool when the "Articles Rich Snippets" filter is selected. It does, however, when the newly-added "AMP Articles" filter is selected.

Google Structured Data Testing Tool output for modified Google article rich snippet example code

This suggests that whatever Google is calling these guidelines, these are their de facto code requirements for Accelerated Mobile Pages metadata.

I underline "their" because Google requirements aren't AMP requirements, even if Google's article rich snippets requirements are a proxy for Google's AMP page requirements.

Dan Scott noted in a comment on Kyle's post that "schema.org markup is only a recommendation of the AMP HTML spec". Both in that spec and in documentation on the main site schema.org use is only recommended, and the requirements listed on the Google Developers site are absent. The site documentation is careful to point out (emphasis in the original):

For some platforms, this metadata is additional, for others it is a requirement, meaning they won’t show links to your content if you didn’t include the right metadata. Make sure you include the right metadata for the platforms you want your content to appear on.

Although AMP is a Google initiative, it's an open source project of which tech lead Malte Ubl says "[n]othing is set in stone." So it makes sense that Google would want to keep its metadata requirements separate from those of the likely-to-change AMP. And it also makes sense for AMP to keep its metadata requirements as lean as possible so that AMP is easier to integrate with other platforms.

Whether the AMP specifications will ever align with on the Google Developers site remains to be seen, but all the evidence suggests that this revision of Google's article rich snippets documentation was undertaken in support of AMP.

UPDATE – On 16 December Google Webmaster Trends Analyst John Mueller confirmed in a tweet that these changes are AMP-facing:

Yes, these changes are specific to AMP, not for Article markup in general. We'll clarify that in the docs.

* I know that the Google name for these are "articles rich snippets, but I just can't bring myself to use that awkward construction, so I use the singular throughout except when quoting Google documentation.


{ 18 comments… read them below or add one }

1 Alex December 14, 2015 at 7:48 pm

Wow, this will be fascinating to see how quickly this is implemented and rolled-out throughout 2016.

Do you see this mostly affecting magazines/newspapers and other big publishers? Or do you think SMBs have a shot at really cashing in some CTR ROI by really sharpening up these rich snippets?

Reply

2 Aaron Bradley December 15, 2015 at 9:21 am

Thanks for your comment Alex.

While Google’s enthusiasm for AMP does, indeed, seem mostly focused on large publishers, if they open up AMP to all (as they suggest they will) then there’s no reason why any publisher can’t find their way into the AMP carousel.

Of course inclusion doesn’t mean visibility, and it will be interesting to observe whether or not the ranking of AMP articles in mobile will mirror the ranking of those same articles for searches conducted on desktop devices.

Reply

3 Ryan Rodden December 15, 2015 at 1:54 pm

Another great read. As to Alex’s comment above – is it stated somewhere that preference would be given to “larger” publishers? If SMBs or small publishers got the jump on this, couldn’t they perhaps temporarily dominate local or small niches by providing a superior mobile experience?

I guess it will be up to Google to decide who gets rewarded?

Reply

4 Aaron Bradley December 15, 2015 at 5:10 pm

Thanks Ryan! As far as I know Google has not indicated that any publisher will be treated preferentially for AMP, so it just might be possible for SMBs to carve out a (yes, perhaps temporary) competitive advantage for themselves by adopting the recommended markup standards.

It’s also possible that even without support AMP versions of articles, some sort of rich snippet might be generated on the basis of compliant markup, which too would confer a competitive advantage on the early adopter.

Reply

5 Sam January 2, 2016 at 4:51 am

Is this requirement only for the AMP pages (created using AMP HTML)? Or will Google use this Article schema to support AMP for even the non AMP-HTML sites?

Quite confusing.

Reply

6 Aaron Bradley January 4, 2016 at 9:43 am

As per my update at the end of the post, Google’s John Mueller has said that “these changes are specific to AMP, not for Article markup in general,” and that the documentation will be updated accordingly (though, as of time of writing, these modifications to the specifications have not yet been made).

Having said this AMP and schema.org/article markup are two different technologies. That is, the answer to your question “will Google use this Article schema to support AMP for even the non AMP-HTML sites” is unequivocally “no”, as schema.org use is neither a sufficient nor necessary condition for AMP, which relies on a number of protocols unrelated to schema.org.

Reply

7 baguz January 5, 2016 at 1:37 pm

it is very hard to fix error in rich snippets in my wordpress site. But in hard work i can reduce error in testing-tool. Need to learn again to boost the SEO.

Reply

8 Raun January 14, 2016 at 7:54 am

This is insane. The structured data testing tool is now showing error for non-AMP pages as it is required.

Getting Error:

Image ItemType is invalid. AMP Article required!

My site is WP with 200+ articles and last time I spent 3 days in fixing and adding Structured data. Now this? 696 pixel? Seriously?

Google is just pushing AMP without giving thought to data which is already present and posted all over net. So, I am supposed to fix such thing all my life or focus on writing. Today is this, after some time, something else.

Not happy.

Reply

9 Aaron Bradley January 18, 2016 at 9:08 am

Thanks for your note Raun. Two things to note. First, the update to the article in which Google has confirmed that the changes to the guidelines are AMP-facing and that they’ll clarify this in the documentation (more than a month after the revised guidelines, however, this update has not been forthcoming).

Second, the guidelines are different for “Articles Rich Snippets” and “AMP Articles”. Do you get the same error(s) if “Articles Rich Snippets” are selected (I’m not 100% sure I understand the errors you’re reporting, as I’ve never seen “AMP Article required”)?

Validation differences between Articles Rich Snippets and AMP Articles in the Google Structured Data Testing Tool

Reply

10 Tom January 15, 2016 at 5:23 pm

Any changes in the handling of AMP in the Jan 8th update? Actually I came here today to read a post on the update 🙂 looking forward to it 😉 get your skates on.

Reply

11 Aaron Bradley January 18, 2016 at 9:09 am

No updates of which I’m aware!

Reply

12 Hafiz Bilal January 27, 2016 at 4:18 am

It is very difficult to fix error in rich snippets in my website. Need to learn again to boost the SEO.

Reply

13 Tyron Jenkins March 24, 2016 at 9:09 am

Great guide Aaron, I had to reference this a few times when I was setting everything up last night.

I have a question though – for Author property, I added “Blog” as the type and it passed validation in the structured data testing tool (although I haven’t enabled AMP yet). I understand this is not an expected type in schema.org for the Author property. Because of that, is this not a good practice even though it validates in the testing tool?

Best, -t

Reply

14 Aaron Bradley June 6, 2016 at 2:31 pm

Hi Tryon. Thanks for your comment and my apologies for the delayed response.

Not certain I understand your situation correctly, but this seems to be a bug with the Structured Data Testing Tool, as indeed it shouldn’t accept the value “Blog” for the @type for “author”, as the expected values are the @type “Organization” or “Person”. But I just tested this and, indeed, the Tool didn’t throw an error for this markup.

One way or another it’s not best practice, either syntactically or strategically. You should only provide values for a property that schema.org or the data consumer explicitly support in order to ensure the data consumer understands your markup correctly. And, one way or the other, there’s no value I can think of of having the author of an CreativeWork being declared as a Blog. The better, somewhat equivalent approach, would be to declare the type as Organization and then provide the publisher of the blog or, in a pinch, even the name of the blog in question as the value.

"author": {
"@type": "Organization",
"name": "Jenkins Inc."
},

Reply

15 Investment Hunting May 2, 2016 at 12:14 pm

I keep getting an Image error, even though I have a featured image. The error is “A value for the image field is required.” Is this a size issue? Here’s my code:

{“@context”:”http:\/\/schema.org”,”@type”:”BlogPosting”,”mainEntityOfPage”:”http:\/\/www.investmenthunting.com\/dividends-earned-april-2016\/dividends-earned-april-2016-11-stocks\/”,”publisher”:{“@type”:”Organization”,”name”:”Investment Hunting”,”logo”:{“@type”:”ImageObject”,”url”:”http:\/\/www.investmenthunting.com\/wp-content\/uploads\/2016\/04\/Investmenthunting.com-Homepage-Logo.jpg”,”height”:”160″,”width”:”380″}},”headline”:”Dividends Earned April 2016 – 11 Stocks”,”datePublished”:”2016-04-30T15:36:06+00:00″,”dateModified”:”2016-04-30T15:36:13+00:00″,”author”:{“@type”:”Person”,”name”:”Investment Hunting”}}

Reply

16 Aaron Bradley June 6, 2016 at 4:55 pm

You’ve declared your logo (which is one image), but not your featured image (which is a separate image). See the first JSON-LD example here. You need an additional declaration that looks like this, where you’d replace “https://example.com/example.jpg” with the path to your featured image (and you’d need to adjust the width and height values to match it):

"image": {
"@type": "ImageObject",
"url": "https://example.com/example.jpg",
"height": 800,
"width": 800
},

Reply

17 Zumvo Tv May 9, 2016 at 1:03 am

my website Zumvo Tv is on Blogger hosted network and i cannot get it that how i can implement it on blogger hosted site ? will you PLEASE HELP ME ?

Reply

18 Aaron Bradley June 6, 2016 at 5:10 pm

Not sure what you’re asking here: you might try asking the same questions with more details on the appropriate Google Product Forum.

Reply

Leave a Comment

Previous post:

Next post: