Along with schema.org, Google has been guiding the way we structure data on the web for years – with structured data recommendations for everything from addresses to eCommerce products. So it should come as no surprise that Google and schema.org, as voice search becomes a more pressing issue, have announced that they will be supporting ‘Speakable’ markup (beginning in the US before roll out to the rest of the world). But should you look to get ready in advance, and how should you do it? Hopefully, I can answer those questions for you.
What is Speakable markup?
Speakable markup is a form of structured data that highlights sections of an artile as useful for text-to-speech (TTS), using an id value reference and either CSS selectors (like a class attribute – commonly denoted by the hash symbol, like those used when giving same page links) or XPaths.
Why should you use Speakable markup?
As I’ve written previously, the need for clear communication should not impact on your decisions when it comes to writing for crawlers and bots (see: ‘We need to write for robots’). The speakable beta is only available to US users and only to those sites registered as news publishers at the moment (and works, as the below markup on Search Engine Land shows), so if it’s not available to the masses, why implement it now? I’m by no means the first to infer from current data that much of your future audience will be controlled by machine learning algorithms that will parse your site for communication via either rich results or by your choice of digital assistant. State of Digital doyen, Barry Adams covered the topic in a recent talk (Search in a screenless world) where he noted that in excess of 50% of current web traffic is made up of various types of bot, while Rand Fishkin pointed out the increase of ‘no click’ searches back in April: https://twitter.com/randfish/status/989851189532614656 I understand that doesn’t exactly explain why you should implement the markup, but bear with me. The truth is that voice search and the age of the digital assistant is on its way, and while (unless Amazon manages to sort it out) it is unlikely to impact on your sales figures for a while yet, it will begin to impact your traffic in the next few years – especially if you offer any kind of ‘information’ content – which virtually all brands do to build authority and audience. It’s for that reason that you need to implement Speakable markup (and other applicable information markup schemas – like HowTo, or even types of location markup) – a lot of content on a brand’s site is there to build authority or address specific user queries and to, therefore, build an association between the brand and the product or service they supply; the available real-estate for this kind of content rapidly and vastly decreases in the age of the personal assistant. With only one spoken result at present and with it extremely unlikely to exceed three – simply because of the time and demand on attention it would require from the user. If you want your brand to continue to build that recognition as an expert in the field, you’re going to need to be ready as soon as the markup is rolled out to the general population.
How to use Speakable markup
While the markup is only functional if you are a registered news publisher using US English in the USA, the schema is available to see on schema.org already (it’s been in various states of construction for well over a year), so can be implemented by any party wanting to be ready at the moment the inevitable roll-out commences. The current schema is marked as ‘to do’ for the microdata/RDFa types, but is available as JSON-LD. Here you can see the implementation you would need to replicate (minus the “TYPES…JSON:” section): This is placed in the header section of your page’s html (or in the site html if you can work out a way to standardise the naming of Speakable sections site-wide.
Provides Google with the information it needs to contextualise the code as relating to schema markup.
Gives Google a point of reference for your schema (allowing it to know what to expect and what it’s required to do with it).
Tells Google where to look on the page (you can also use the xpath property for this purpose), this selector must then be added to the appropriate text inline – so, were we to use the above example, the code would read: Though the requirements needed to be included in the beta are prohibitive to many brands who don’t want to implement separate news feed URLs and spend the time ticking other boxes, there is nothing stopping even the smallest brands implementing this markup in anticipation. It is also likely that this (or similar) will become a requirement for featuring in various text based rich results.
As machine learning and various digital assistants grow in importance in search, the industry is going to need to begin or increase the frequency at which it cross skills its content creators. Increasingly – and for much longer than brands can afford to wait – the age of assistance (as Google employees have begun to consistently refer to it) will require us to communicate our needs, wants and intentions as content creators to the various bots and crawlers that will deliver our content to the end user. For that reason, it seems to me to be in the best interests of brands to ensure they’re riding the markup train rather than waiting on the tracks to be hit by it.