Webinar Recording: Making the Business Case for Structured Data

There's a lot of talk around the theory and results of structured data, but we found that a lot of the SEOs we've spoken to are struggling with how to make a business case to get it implemented.

On the 14th of October we ran a live Q&A session focusing on making the business case for structured data.

We asked Sitebulb users and the wider SEO community to submit their questions for the Sitebulb team and our special guests to discuss. We took these questions, chucked in a couple of our own, along with some from the live chat, and had a bloody good blether about them!

Special Guests

We were lucky enough to have two amazing guests join us for the live Q&A session - Lily Ray and Jono Alderson are both at the forefront when it comes to structured data and SEO (don't tell Jono I said that), so getting the chance to chat with them about the practical side of making the business case for it was a great opportunity.

Alongside our guests were myself (Geoff Kennedy), and Patrick Hathaway, co-founder of Sitebulb. We also had Simon Cox very kindly helping us out on the live chat.

Watch the Full Livestream

You can watch the full, un-edited Q&A livestream recording here:

If you like the video, please subscribe to the Sitebulb channel so we can keep you updated with future livestreams.

Jump Straight to the Questions

If you want to dive straight to one of of the questions, use the links below which will take you the the section of the video where we covered that question, along with a full transcript:

1. What are the biggest challenges in getting buy-in for structured data from businesses?
2. How do you measure the potential impact of structured data in order to justify the investment?
3. Is structured data worthwhile pursuing if you can't shake off all warning status by fulfilling all data fields?
4. What's the business case for structured data beyond what's supported by Google?
5. What are your views on the lifespan of structured data?
6. What info should I provide the dev team on when/where/how to use structured data?
7. Do you see structured data becoming a standalone discipline? Or merging into wider SEO?
8. How rigidly should we follow Google's structured data guidelines?
9. Is poorly marked up structured data worse than no structured data?
10. Have you got one last tip on making the business case for structured data?

Resources

Here's a few links to resources that were either mentioned on the livestream, or we thought might be helpful for some of the topics we discussed:

• Path Interactive
• Yoast
• How to Use Structured Data to Support E-A-T - Lily Ray
• Yoast Developer Portal - Schema Specification 
• How to Secure SEO Budget - Chris Simmance
• Sitebulb structured data validation and auditing 

Full Livestream Transcript

Don't like video? Well that's a bit weird, but we've got you covered anyway. Here's the full transcript of the livestream: 

Geoff:
Hello and welcome, everyone. So I'm going to do a few introductions first. So my name is Geoff Kennedy. I'm going to be hosting our Q&A session today on making the business case for structured data. Today I've got Patrick, co-founder of Sitebulb, and we're delighted to be joined by Lily Ray and Jono Alderson. In a moment, I'll get everyone to introduce themselves, but first I'm going to give a quick overview of what they'll be covering tonight.

Geoff:
Right. So we all know there's lots of opportunities for structured data just now. But, as with most things, if we can't make a solid business case for it, then we're not going to get very far. One of the reasons that we're really keen to cover this topic is because at Sitebulb we've spent a lot of time working with structured data that integrated into the tool. But we are quite disconnected at times from the front line of actually needing to sell line to clients or stakeholders if you're in house.

Geoff:
So that's where Lily and Jono come in. So the format today is going to be fairly informal Q&A. We've got some great questions lined up. Some have been submitted, others have been asked by Sitebulb users, and then we've got some that have just come up when we've been talking about structured data through various discussions. I've loosely structured the flow of questions. We're going to start off with the why. So why do you implement structured data, what you should be implementing, how you should be implementing it. And then we've got a couple of questions at the end on selling. So as SEOs, how should we be looking to sell this as a service?

Geoff:
Should have mentioned before, we've also got Simon Cox helping us out in the live chat. So if you've got any questions as we go along, please drop them into the chat and we'll fit them in as and when we can. And I've done enough talking for now, so I'm going to pass you across to our guests to introduce themselves.

Geoff:
I'm sure most of you will know who they are already, but I'm going to ask each of you to briefly tell us who you are, what you do, and what is structured data to you? Would you like to go first, Lily?

Lily:
Sure thing. So my name is Lily Ray. I'm the director of SEO at Path Interactive. We're a digital marketing agency here in New York City. Live in Brooklyn, New York, where it's very sunny, so I apologize if there's a lot of glare on my face right now. So I lead the team of a bunch of SEO professionals, and we work across dozens of clients, all of whom need structured data in various capacities. So our role is to make structured data recommendations where it's relevant to do so and where we think it will have a business impact. So very relevant to today's discussion.

Lily:
And then just basically figuring out what's the best type of structured data to implement, and how can we implement it, because they all use different CMS platforms and website platforms and things like that. So excited to be here, thanks for having me.

Geoff:
Jono, you're up.

Jono:
I was enjoying you taking your drink there. I've realized I don't have a drink with me, so I might need to very professionally disappear for a moment in a minute here.

Geoff:
You've poorly timed.

Jono:
Yeah, yeah. Thanks for having me, this is a delight. So I'm Jono. I'm a big schema nerd. So I work for a little company called Yoast which hopefully some people here have heard of, especially if you're in the WordPress space. We have an SEO plugin that runs on something like 12 million websites, which is pretty awesome. And I... A big part of what I spend my time doing is trying to work out how do we automatically, invisibly, perfectly, give everyone, every single one of those sites, the world's most sophisticated schema output.

Jono:
And for 99 percent of those users and sites, they shouldn't even know or care that that's happening. And for the one percent who do care and know that it's happening, they should be able to extend, modify, enhance, build on the stuff that we've done and do, crazy cool awesome stuff. And it's a really interesting challenge trying to balance both of those audiences. So I spend most of my time thinking about the mechanics of how do you implement schema?

Jono:
So schema.org is really good at defining what schema is, and Google's documentation says what they want, and there's really nothing in between that says how do you connect these two worlds. So that's my world.

Geoff:
That makes a lot of sense. Patrick, you're up.

Patrick:
Sure. So I'm the co-founder of Sitebulb, and alongside Gareth, who basically does all the building, I kind of help guide what the product does and what the product should be. And Geoff, you get involved in that as well. But one of the things we've recently released is our sort of structured data extraction and validation. And that has meant that we have had to dive deep into the world of structured data way more than we ever did before. And our challenge is slightly different to Jono's and Yoast's challenge in that we're trying to extract the information, tell you about it, tell you what's there, and also tell you what things you need to fix and give you ways to explore the data in a way that can allow you to make meaningful recommendations to clients.

Patrick:
And extracting that across all the pages, aggregating the data and aggregating the results for you, that's kind of the biggest thing, so that you're not always having to look one page at a time. Because that's the difference between using a tool like Sitebulb to using something like the structured data testing tool, where you're only ever looking at one page at a time. So trying to connect those dots and make it easy to make those findings. And that's me.

Jono:
Nice. And we're done, let's go.

Patrick:
[crosstalk 00:07:18]

Geoff:
Sorry about that, my internet connection is being slightly dodgy there. So if I suddenly disappear, that's my excuse.

Patrick:
Oh, I've got the questions as well, so I'll just fire them.

What are the biggest challenges in getting buy-in for structured data from businesses?

Geoff:
Yeah. Hopefully I won't, though. Right? So first question, this is a bit of just a starter one. So for... Sorry. So what are the biggest challenges in getting buy-in for structured data across businesses? So Jono, what do you reckon to this one?

Jono:
Go go go. So I have a lot of very strong opinions on how schema should be approached and managed, and I think in most cases, businesses shouldn't be in a position where they are having to even think about it this way. The fact that you're in a position where your content management system doesn't support it and you're wondering if you need a business case to even consider it probably already means that you have comprehensive, fundamental technical debt, you have the wrong kind of culture, you're not thinking about or resourcing SEO in the right way, your teams are structured incorrectly, et cetera, et cetera, et cetera.

Jono:
So you've already lost. But that aside, I think if you're in that position you probably have other challenges and it's a question of prioritization. Like you have a CMS that doesn't support the fields you need. You have a slow website. You probably still have security issues. And it all comes down to cost resource benefit. And if you're in a business or a site like that, and there are very obvious things that are on fire that you can see and you can quantify, this abstract, behind the scenes, let's play with the language so that nobody really understands stuff is never going to be prioritized.

Jono:
And no matter how far down that list of to-dos you get, there are always going to be things that visibly on fire. You're always going to have problems with our business is losing to competitors, et cetera. So yeah, there's always going to be shinier stuff. And there's always going to be things which are easier to understand than this behind the scenes stuff. And I don't think that's ever going to be really fixable.

Lily:
Yeah, I would-

Jono:
Oh, Geoff's gone.

Lily:
Geoff's gone. [crosstalk 00:09:30]

Lily:
I agree. I think... So the problem often stems, as you said, is from people not prioritizing it correctly, or just grouping it into the other technical tasks that they have to do and not understanding the value, but I think the biggest fundamental disconnect, and one that's been widened a bit this year, is what Google chooses to display as a rich result and everything else that's on schema.org.

Lily:
So my team and I, we're going really, really far in this direction of marking up all the things, and being as specific as possible with our schema. And Google kind of... When they announced that they were deprecating the structured data testing tool, it made it a lot harder for us to convince our clients that it's worth doing if it's not a type of schema that will generate a rich result. So that's been one big point of contention this year. But I think there's a lot of other benefits to schema that we'll talk about today.

Jono:
Yeah, and we're probably skipping around a bit, but it was so wonderful to see. There was a quote from John [Mooder 00:10:28] recently on a webmaster hangout saying explicitly that even when they don't use schema to show a rich result, they... it profits them to help understand the pages that they're analyzing. And I keep coming back to this word understand. Right? If their objective is to match consumers who have problems with websites that solve them, then the better they understand that, the better they can match it to the right websites.

Jono:
Yeah, even if you're not getting the shiny results, this is, increasingly, the way that we communicate the details of our businesses, our products, our services, to Google. But then you're back to the first problem of you can't validate any of that, you can't measure any of it. You've got to take it on faith. And we're talking about businesses who don't operate on faith. They operate on technical debt and opinion and legacies. So yeah, it's really hard.

How do you measure the potential impact of structured data in order to justify the investment?

Geoff:
I think the next question we've got, then, we've already addressed quite a few of the reasons why it's really difficult, but there was a good one that we've had submitted from Tom Mauger. He's asked, "How do you measure the potential impact of structured data in order to justify the investment?" So we've already talked about that a little bit, but he's also added, "Particularly the more subtle examples where visibility inserts might be negligible?" So for the likes of article marker, where it's not strictly you mark something up and you get a result?

Lily:
Yeah, so sometimes the results manifest themselves over time. So let's say, for example, you show up in the knowledge graph, and you weren't there before. But that's because you added some type of organizational schema or person schema a couple months back. That's probably a pretty clear example of the ways that schema can sometimes manifest itself in ways that aren't directly rich results. Or maybe something like you fixed a knowledge graph issue where somebody else's name was appearing for your targeted name.

Lily:
There's those types of things that you can do in the back end, but I think by implementing schema proactively, it helps to ensure that when Google chooses to make a change in its knowledge graph, or when Google chooses to roll out new structured data, which, this morning in the Pubcon keynote, John Mueller confirmed we will have new schema types and new rich results rolling out on Google soon. I think just being proactive and almost defensive with your schema strategy by marking up as much as you can puts you in a good position when those changes are made.

Jono:
Yeah, a hundred percent. And we know as a fact that using this kind of information to provide rich results and cards and snippets that aren't the conventional ten blue links is absolutely the direction of travel that Google are going. And that we know that when there are cases that you have the right structured data and the right content with the right mark up, you bypass all of the conventional ranking systems and constraints because you are demonstrably the right fit. And that will happen any place where your result is the best.

Jono:
So how do you measure the potential impact? You look for where your competitors are already a perfect match for your users and where you're not getting traffic, and you look for where you are. And if there's a gap, then it makes sense to start to be investing in that... Investing in that. I think there's an interesting loaded component in this question that suggests that, in this case, the site doesn't have any structured data, and it's like a do we or don't we at all. I can't imagine... That's akin to saying should we think about TV advertising in the '50s. And is this Internet thing really going to be significant.

Jono:
This is increasingly the mechanism by which we describe and market to and through Google. And the way you measure the potential impact of that is you watch your market share dry up as your competitors get there first. And, yeah, every week Google are going to be launching new formats, new verticals, new integrations. And if you're not there now, the people who get there first to market have weeks and months ahead of you.

Jono:
And they... Because you've got a backlog of dev tasks and IT time that needs to be done. And dislodging an incumbent in that situation is going to be so hard, because they're going to build so much trust and so much brand recognition that then not only do you have to finally get around to implementing more structured data, you have to have a better proposition and better brand recall than the people who've already eaten your lunch. It's going to be so hard.

Patrick:
And Lily, so on this stuff, as well. Do you find that clients have got awareness of the opportunity, or you're having to kind of beat the drum for it and just convince them all the time?

Lily:
It depends on their digital IQ, basically. Depends on the brand. So some brands have in house SEOs where they obviously know what structured data is. But in most cases I feel like, even to this day, when you're communicating with C levels, it really requires showing... And I love doing this, because obviously they use Google in their own time, and they've seen FAQ schema, they've seen star ratings and things like that. But when you show them, "Your competitor has these stars and you don't," they're like, "I need the stars."

Lily:
So rich results makes it much easier to provide a business case for why it should be implemented. But the level of effort that we have to put into convincing them that it's important is kind of contingent on how visible it is in the search results, and also how knowledgeable they are about digital marketing in general.

Jono:
Do you think it's... Slight tangent. How frustrating and bizarre it is that, given how evidently important this is for Google, beyond just the immediate rich results schema, that Google has done such a poor job of communicating, incentivizing, building those bridges. Yes, they have the documentation on the kinds of shiny things you can unlock, but I can guarantee that we're the only people who are looking at those. Their positioning this out into the real world has been pretty much nonexistent, so it's a real shame that they're not making more noise, saying, "Hey, look at this. This is how this works. Here are the business cases."

Jono:
This should be something that they should be owning, I think.

Is structured data worthwhile pursuing if you can't shake off all warning status by fulfilling all data fields?

Geoff:
Yeah. I think, as well, Tom's follow up question kind of hints a little about how Google have put people off in a different way, as well. So his follow up was, "Is it worthwhile pursuing structured data if you can't shake off all of the warning statuses by filling all the data fields?"

Geoff:
So I've thought about this question quite a bit, and I'm kind of... I've made a few assumptions about what he was asking. But I think it's split into two areas. So your first one is, is an entity worthwhile if you can't populate all the fields? So if you haven't got everything there. We saw examples of that a while ago with the likes of the recipes, where people were putting in nutritional data just to make sure they've ticked all the boxes. And then we've got the whole warnings thing about well, how much should you listen to them?

Geoff:
I know Patrick's got some strong feelings on the whole warnings thing with work we've done. So I'll let you start with that one, Patrick.

Patrick:
Yeah, and so... I guess first I just want to clarify that when you see these warnings in the structured data testing tool, basically what they mean are you could also include these recommended fields. And there could be an opportunity for more exposure here. And essentially when we were building our version in Sitebulb, we really did not want to use this naming convention, because we don't like it. But then we thought, well, we kind of want to make sure it's consistent with everything else that Google are saying so that people are like, "Well, I understand that this thing is a warning there, so it should be a warning here."

Patrick:
So we kind of relented and did that. But, essentially, they should be called opportunities, because that's really what they are.

Jono:
We've had similar challenges. So we have a huge support overhead at Yoast, where we provide things like how-to blogs and FAQ stuff, and people implement them. And then they immediately start getting incomprehensible emails from Google saying, "Warning! Warning! Your how-to guide doesn't have a tool." And I'm like, the how-to guide was how to tie a shoelace or how to boil an egg. Do I really need to be explicitly saying this requires a shoe or a pan? It doesn't make sense.

Jono:
So we have the same kind of challenge of where is the balance between adhering to Google's arbitrary laws, where they... So schema.org has not concept of requiredness. It's only Google's interpretation. So Google says a recipe must have an image, because they can't conceive of our utilizing a recipe that doesn't have a picture. But it's only their [inaudible 00:18:57]. So the thing we ended up with was something similar. We have required, recommended, and optional fields. And we're really, really careful in what we say is explicitly required, and then it gets more liberal as you go down.

Jono:
But yeah, it's such a bizarre situation to be in where Google have just overlaid this law, and poorly communicated it, of what's required and what's optional. So yeah, it's pretty challenging to manage how far do you go.

Lily:
Yeah, I think for us the criteria is whether or not it will break the rich results, pretty much across the board. As an agency, we wake up and have 40 different emails from Google about how our breadcrumbs are invalid. And we're like, "Hmm, does it change the way our search results look? No? Okay, we're leaving it, we have other priorities." It's not... You know?

Lily:
So if the schema's broken to the point where rich results are also broken, or there's something literally invalid in the code and it can't process the code, that's one conversation. But with all the warnings, it's generally stuff that doesn't have a huge business impact.

Patrick:
Yeah.

Geoff:
Yeah.

Jono:
Your breadcrumbs don't have a color. That's fine. That's really fine.

Patrick:
And so, I guess, to properly answer Tom's question, get rid of the errors, and don't worry so much about the warnings. The warnings are there as optional. If you have the data and you can put it in there, great. If you don't have the data, don't feel like you're... It's a check box exercise to check everything off.

Geoff:
Mm-hmm (affirmative).

Jono:
Yeah.

Lily:
Unless you're a perfectionist.

Geoff:
I think in a way...

Patrick:
Well...

Geoff:
I think in a way that's one way that Google's actually... Not depreciate, that's not the right word, but damaged their own structure there by trying to force people to fill these things in.

Patrick:
Yeah. Adding extra data that you don't really have. Or you just... I'll make something up just to fill the box and stop getting this stupid warning.

Jono:
I guess the flip side of this argument is the reason why they're pushing these entities so... These attributes so hard is because they want to use them to solve their users' problems, whether that's ill-conceived or otherwise. And it means that it's... You can already see examples in the recipe space where you cannot rank unless you have a recipe that has a high-res image and the calorie count, and the set of ingredients. Now, calorie count, as you point out, is optional. But not really, if you want to compete. So none of this happens in a vacuum. So if... Anything that Google is saying is optional or recommended, then that's probably a strong hint that that's what they're looking for to feed their users. And if you're competitors have that information and you don't, then you might be on the back foot.

Jono:
So don't feel like you have to, but it's definitely a strong hint that you probably ought to at least aim for it.

Patrick:
Mm-hmm (affirmative).

Geoff:
Yep.

Lily:
I think that's more true depending on the type of schema that it is.

Jono:
Yeah.

Lily:
In your recipe example, 1,000 percent, you should pay attention to the warnings, because especially in the recipe space, it's so difficult to compete as it is. If you have a chocolate chip cookie recipe, there's 5,000 other ones on the internet. Five million other ones on the internet. So whatever you can do to beat the competition, you're going to have to do that. But when we're talking about things like bread crumbs, where it doesn't really have a big impact, necessarily, maybe. But if it's less visible in the search results themselves, then it's less of a priority.

Jono:
Yeah.

Patrick:
Cool.

Geoff:
So the next question is a bit of a big one. I've heard you talk about this before, Jono, so I'm going to let Lily go first before I let you rant about it.

Lily:
Yeah.

What's the business case for structured data beyond what's supported by Google?

Geoff:
So the big one is, beyond Google, what's the business case for structured data? And just to give a little bit more context on this, because this is a one that we've looked at a lot. Patrick, I think you had a bit more background on why we came up with this... This question, rather.

Patrick:
One of the reasons for us is that we're tool builders now, we don't do this. We don't talk to clients anymore, we don't actually have to deal with this as a... And so, essentially, when we were building our structured data validation inside the tool, we asked our customers, "What do you want to see?" And it basically, pretty much came back, "We want to see what Google supports, number one. And then everything else as well." And so we're like, right, okay, we need to validate the whole lot, we do need to do both.

Patrick:
But then, they obviously want it, but why do they want it? And why is this important? Those questions... We knew they wanted it, we just didn't really know the next step. Actually why? How are they selling this stuff? How is the business case being made?

Lily:
Yeah, so... Honestly, it's really challenging to say, "Oh, the other search engines benefit from it," or, "It helps with machine learning." That stuff doesn't really process for clients who are just focused on sales in most cases. But one thing that you can do that's more tangible with structured data that doesn't necessarily rely on Google, and my teammate Josh pointed this out to me this morning, which is a really brilliant example, is you can pull the data from structured data in your own business analyses.

Lily:
So you can, say, if you have an e-commerce website, you can pull those attributes and then cross-reference with things like sales or conversion rates or whatever. So it just makes it easier to actually internally understand how your products or something like that are performing. And then he mentioned a couple tools. So MongoDB and Neo4j, I'm not familiar with them, but you can actually feed the schema attributes into those tools as a way of doing recommendation engines and internal search and things like that. So there's use cases for it from an analytics perspective that doesn't have as much to do with rich results.

Patrick:
Nice.

Geoff:
Yeah.

Jono:
I think that's a really interesting space. I went to a conference when they were a thing. I can't remember what it was called, but it was in London and it was a 50/50 split between schema-y people like us who were saying, "How do I implement this on my site and do stuff," and then people who use structured data and schema internally in their organizations. Like we are a factory that manufactures cars, and we have a schema internally about the parts and the way they connect, and their places.

Jono:
And what they really wanted to do, both sides, is find this middle ground where they can share and standardize language so that they can optimize processes and power systems. I thought that was cool.

Patrick:
That was really good to see.

Jono:
Yeah. And nobody's really thinking about that bridge. But there's definitely a world of... Schema.org is a standard for describing all the things, so why not take that further than just your website? I guess, in more practical terms, we'd be remiss not to point out that Facebook is a big consumer of schema, especially if you're doing e-commerce stuff. They will scrape and use your product information to update your product catalog. Your prices, your availability. Which, I think, is a profound change in how the web works. Your website is now a live database, and the primary version of the truth for your product information, whereas previously you'd rely on feeds and APIs and slow, clunky, expensive stuff.

Jono:
Now your website is not only a marketing layer for consumers, it is your database. And I see that trend, and Google are doing some similar bits, but not a ton. And one last thought, which I think is possibly the most important, which is that there are huge arguments against doing anything with schema on the premise that Google will just hoover up our data and use it and take our clicks and destroy our businesses, without necessarily having a good answer to what do the economics look around that, and how do we make that fair? And there is no good answer to what happens with that.

Jono:
However, one of the reasons Google can do that, and can do a whole bunch of things and continue to be insurmountable and have this competitive moat is because one of their biggest strategic advantages is their ability to crawl and consume and pass data at scale. They can just eat the web in a way that if I tried to build a search engine tomorrow, I would find inordinately expensive. What does schema markup do? It standardizes the descriptions of all the things. And if all the restaurants in New York put schema markup on their websites tomorrow, I can build a search engine that says, "Find me their opening hours, but only if they're within five minutes' walk of a major football venue and if their prices are..." You can start to do that in a way that doesn't require you to build a Google.

Jono:
So yes, whilst this feeds Google and predominantly this is about rich results and snippets, it paves the way for a different type of web, and for competitive advantages and new types of business models that we can only imagine because we're so used to this Google world. So I think that's not the kind of way we're conditioned to think as SEOs, but there is opportunity there of a different type.

Patrick:
Mm-hmm (affirmative).

What are your views on the lifespan of structured data?

Geoff:
Yep. I think there's an interesting question in the chat there that kind of links into this same thing that I'll put up. So Pedro is asking what are your views on the lifespan of structured data? I'm assuming thinking about well, is it worthwhile investing now? Is it going to be the longevity to it? I've covered you up a bit there.

Jono:
Very nice, [crosstalk 00:27:53]

Geoff:
Oh, hi.

Jono:
That was fun.

Lily:
It's hard to say. In some cases you have unstructured data showing up as rich results on Google, or you have them... I have client recently where one of my teammates, Ian, was like, "How did this meta description appear? We didn't mark up anything on the page." And it's like Google just made that into a structured meta description by crawling the content on the page. So I think they're getting a lot better at it. They won't necessarily need schema as much in the future, but it's interesting that this morning John Mueller literally said, "We're going to have new rich results types soon."

Lily:
So it's hard to say how long in the future that will be.

Jono:
I'm going the other way. I think this is absolutely the future. I think the days of them crawling the web and guessing what pages are about are numbered. I think that they are as about as far as they can with that approach. When you look at the types of search experiences they're trying to create, they all lack something. Everything that they do at the moment is based on extracting some content and making some kind of soup of it based on what they understand about the entities and their relationships. It's not enough. Because what they're missing is context.

Jono:
And that context is of the specific business or the specific page. They can really easily say, "This is a product and it has a review." It's much harder to say, "This is a review of this product reviewed by that expert who works for this organization who published this website," you'll have... And you can imagine how those webs of complexity get much, much harder. You cannot infer those magically through large-scale machine learning. You need the business or the website to describe those relationships. And I think that's going to be so profoundly important, because that's marketing. Controlling that narrative and presenting how we want our stories to be told and understood by a third party, in this case Google, that's what we should all be doing.

Jono:
And I don't think we can live in a world where we rely on Google guessing that. And they don't do a pretty great job of it at the moment. All they really do it just hoover stuff up and fire it back to us in a different format. They're not doing anything intelligent or smart with it because they don't understand. They just regurgitate.

Patrick:
Yeah. Taking that control, that's the thing that structured data allows us to do, right?

Jono:
Yeah. Absolutely.

What info should I provide the dev team on when/where/how to use structured data?

Geoff:
So jumping back to another very practical question, I spoke to Mandy King by email earlier in the week, and she's working in house, so she's asked what info should she provide the dev team on when, where, and how to use structured data? So she gave a little bit more context on this, so she's saying she's the main stakeholder of a corporate website, juggling with what info she needs to provide the development team. So she says she's got, for an example, location pages. She wants to have the correct structured data pull in on location searches on search, but when she asks for... When she says she needs the correct stuff on there, the dev team look like she's crazy.

Geoff:
So where does... What I've interpreted from that is where should the line be in terms of, as SEOs, should we be going down the route of saying this is exactly what you need to put on the page? Or do we, as we keep getting told from Gareth, who does all of our development, don't tell me the solution, tell me what you need to see.

Geoff:
So where do you think that line lies? You're probably the closest to this, I would say, Lily.

Lily:
Yeah, again, it depends on the web site, the CMS platform that the website is using. So if you're using WordPress, as Jono knows, it's already going to be built in, a lot of the stuff that you need. And then if you're using Gutenberg on top of WordPress, the developers don't have to do anything, because you just click on the right type of block and the schema's there by default. So CMS platforms like that make it much easier.

Lily:
Or you can do something like basically taking ownership of schema through Google Tag Manager and being able to insert it yourself from the SEO side of things, and that also eliminates the need to work with developers on it. But the more that you can have schema built in to the page templates where it matters and where it generates rich results from the Google SEO perspective, the better. So things like location pages, product pages, authors and articles and things like that. As much as you can build that into the infrastructure of the page, that's going to be beneficial.

Lily:
But also being able to be more nimble and make modifications to JSON files and everything. It's much easier as an SEO to have the flexibility to be able to write the JSON yourself and implement it yourself, if you can.

Jono:
Ooh.

Lily:
Because it just takes out the need to be constantly telling developers they have to make changes to the page. So... Yeah.

Geoff:
Was that a disagreement, Jono?

Jono:
It was a disagreement with the caveat that I accept that the world isn't perfect and sometimes you've got to roll your sleeves up and write some schema. But I think if you find yourself in that position, something has already gone horrendously wrong. In the same way that the SEO probably shouldn't be applying security patches to servers or serving people lunch. Yes, everybody should be multi-talented, but you create real problems when you start having SEOs write bits of schema and injecting them via Google Tag Manager.

Jono:
What you build is brittle, it's disconnected, it breaks, it doesn't scale. And you get stuck in a position where these conversations keep happening. Where you fight with the developers to say, "Please can we add this bit?" "Oh, I don't understand, we don't have a framework. We don't know what this is because you've done it..." We create these barriers, and you end up iterating yourself into a wall.

Jono:
I think there are only really two ways that you can do this. One, if you're on WordPress, yay! Use Yoast, wonderful. If you're not, then use either Schema App or Wordlift, which are really great tools which are kind of plug and play, sit outside, define the business object, tie it up. If you do absolutely have to do this yourself, and if you have to convince and engage with your developers, I have a magic wand. Which, as I said earlier, one of the bits of schema that's missing is the business logic for how all these things behave and what happens if your author doesn't have an avatar.

Jono:
The other thing that's missing is the basic approach for developers to understand how this stuff should be built and constructed and interact, and how should my organization relate to my website? It just so happens that I've spend far too many hundreds of hours of my life that I'll never get back writing all of that documentation. It's all on developer.yoast.com. You start at the beginning as a developer, you gain an understanding of the foundational approach, and then this becomes super easy. And then the conversation is can we add a person piece when there's an author, and they look up the documentation and they do the thing. And it all goes away. So, nice.

Jono:
If you find yourself doing this manually, that's a big red alarm button, because it's not going to scale. Certainly not unless Google add more stuff.

Lily:
No, I would add... So, yes. 100 percent, and as you mentioned, what you're describing is, in theory, how things should work. I'm speaking from the perspective of someone with so many different clients where getting the buy-in, and maybe they're not on WordPress, and this is the only way that schema will be implemented. So I completely agree with you, it's not sustainable, it's not ideal. But as it stands right now, just because so many business owners don't understand the impact of it, or they don't understand why it's important, that's often the only option that we have from the SEO side.

Patrick:
And can that work as your proof of concept on this, as well? You do it that way first, and then go, "Right, what we've done is not adequate, it doesn't scale well."

Lily:
For sure.

Patrick:
"Now let's do it properly." Now, kind of you can see, already, oh, we've got some rich results, we've got some increased click through rates. We've made the business case by doing it this way, and now you've got that proof of concept.

Lily:
For sure. Up until, I don't know, six months ago, I was saying never use Google Tag Manager to implement structured data. And the only reason I've changed my tune on that is because so many clients literally that's the only way that it will get done. And then also because Google, John Mueller, recently... Or even the Google web site. They were like, "Use Google Tag Manager for schema." I was like, "Okay, that's new."

Lily:
But yeah, to your point, for sure. Once you have it implemented, then you can show them the shiny objects that are happening in the search results, and then you can actually create data studio reports or just Google search console reports that actually show this is the increase in click through rate. It's much easier to get buy-in at that point.

Geoff:
I think that's the thing that as SEOs we're usually brought in because things aren't working, or things can't get pushed through. So we never get to deal with that perfect world. So-

Jono:
Well, unless you're on WordPress, of course.

Do you see structured data becoming a standalone discipline? Or merging into wider SEO?

Geoff:
And Yoast, obviously. So jumping ahead a little bit, and sort of bigger picture thing, so one that I quite liked. Where do you see structured data sitting as a discipline. Is it standalone, or is it just going to become another part of SEO that we include in normal SEO audits and it just becomes an everyday thing?

Jono:
That's interesting.

Geoff:
So yeah, I suppose the alternative to that is... Mentioned before, but developers. Does it become part of the developer's tool set. Is that where it sits?

Patrick:
We're already seeing some SEOs kind of shifting out of the SEO role and being specialists in terms of structured data. Aaron Bradley is one, I think, Dave [Ojeda 00:37:50] is another who's just... They're now sort of schema specialists, and what they do as a role is help with implementation. They make these business cases, they kind of get hired, brought in, to do... I'm just doing the structured data implementation for this side. That's my thing. So I already see... You can already see that it's shifting to some extent with... I guess that's like right at the edge, that they are possibly just educators at the moment.

Patrick:
I think the bit about this question, for me, that's interesting, is where does this part... Where does the structured data stuff fit as part of an SEO audit?

Jono:
Yeah.

Patrick:
So that's the thing that Sitebulb is built for. You're doing an SEO audit, and maybe you... You're using Sitebulb, you tick the structured data thing and it gives you a whole load of stuff back, and you're like, "Shit, there's a load of problems here." Are you at that point going, right, here's your technical audit, over here. And then separately, I recommend that we come back and do an audit, proper validation of this structured data stuff, and spend some time getting this right, because it's a bit... It's a hot mess at the moment.

Patrick:
Or are the sort of merged together? How do you guys think that works?

Lily:
So speaking from the side of someone who works on a team of about 15 people, what's been happening as schema has been evolving is that a couple people on my team who weren't even necessarily the most technical people on the team, they just kind of developed this passion for writing schema and addressing schema issues, and then they got excited about all the different opportunities that are available on schema.org and looking for all the different ways they can mark up the content.

Lily:
So I do think it's this new kind of niche area within SEO, the same way we have... Like me, I talk about EAT. Not everybody in the SEO world talks about EAT. There's these niche subtopics within SEO. So I do think it falls within the realm of technical, but I could envision it as something where you go to a job interview and you're like, "I'm the schema person." And me at an agency, I need that sometimes. So I can envision it as kind of its own career path.

Jono:
I wonder... It's difficult, isn't it? Because the bit that's the expertise in schema isn't an SEO thing at all. It's an understanding of which vocabularies are available and which might be relevant for this business case, and how does a local business relate to a place with an address? And what's the relationship between those? Like that's only incidentally an SEO-y thing because Google are big on it at the moment.

Jono:
And I think the more I look at this, one of the challenges we've always had with the distinction between technical SEO and other distinctions is is this a page level thing, i.e., do I need to go in and edit some content and a description, or is a template level thing? Do I need to change the way this platform works? Whereas this is now a third layer. This is somewhere in between. Because we're talking about... There should be a one to one relationship between everything that's described on the page and the schema equivalent.

Jono:
But then there are also bits beyond that. Like this article is part of this web page that has this organization that is authored by this person, which aren't necessarily strictly things on that page. So I don't really know where it lives, other than as part of the platform. And in principle, when it's configured and structured and coded correctly, it shouldn't need to be owned and managed by anybody, because it should just reflect what's on and in the page in the same way that your canonical tags and your meta descriptions and other things do. But we know from experience that that's not always that case.

Jono:
So yeah, I guess this becomes another specialized arm of SEO until such day as, hopefully, it's just all baked in and working, much the same way that most SEO stuff now does, like it's very rare to come across a site that doesn't have working title tags, for example. But once upon a time, that was a common issue. So maybe 20 years from now, this will all just be standardized and fine and we won't need specialism.

Geoff:
Yeah.

Jono:
Maybe. Hopefully.

Geoff:
I'm not thinking that far ahead. Next year's about the limit.

Patrick:
Yeah. Can we get through 2020?

Geoff:
Yeah.

Jono:
Sheesh.

How rigidly should we follow Google's structured data guidelines?

Geoff:
So we're getting close to the end, so I'm going to grab a couple of questions from the chat. So I've got one from Phil Isherwood here. So what's your opinion, thoughts on adding FAQ mark up to any page that has FAQs. As guidance says, it should only be on specified FAQ pages. I'd like to open this up slightly in how tightly do you recommend that you stick to Google's guidelines, because bit torn on this at times, whether you need to stick to it religiously, or do you just go with what works, what gets you rich results?

Lily:
I love this question.

Jono:
Yeah.

Lily:
As far as it relates to FAQ schema, I've been saying this since they launched it, this is one of the rare opportunities on Google where they... Until recently, it was a little bit of the wild west. You were a little bit allowed to just push the limits of what the guideline says. For example, in the original FAQ schema documentation, it said don't advertise yourself. And I have seen plenty of people advertising themselves within the questions and answers. And, granted, they did crack down on it, I want to say June or July of this year. They did start to reduce the amount of visibility that you get for FAQ schema it it's breaking the rules, but it is still an area where it seems like, to this question's point, you can put FAQs on virtually any type of page, and FAQ schema, even if it has other types of schema, and often it will show one or the other or both.

Lily:
So we recommend that for a lot of our clients, because why not take up the extra real estate?

Jono:
I guess from a technical perspective there's some interesting answers, in that Google's approach to FAQ mark up in particular is an absolute mine field. The way they implement it is radically different to the way that it's described in schema.org. It breaks in a whole bunch of places. It's radically different to the way that Google implement other bits of schema. It's interestingly the only type of schema at the moment in Google's world where the thing on the page has a relationship with and affects the page itself. So if you put FAQ content on a page, your web page item now needs to be an FAQ page.

Jono:
But then there are also other types of web page, like contact page. So you can now not really have FAQs on your contact page, and describe that without compounding things, and then there are other issues. You also, as Lily touched on, you could have multiple types of schema on a page. So you could have FAQs, and a recipe, and an event. But almost always, the... For example, an event will always beat an FAQ because of the way that Google have implemented it. The whole thing is a real mess.

Jono:
I think that, if you were tactical, not wanting to aim for perfection, definitely opens up opportunities to say I will add FAQs to every damn thing that I can, and transform all of my pages into FAQ pages and six other things, and just hope for a bit of extra search real estate. I think the worst case scenario, then, is you've added some useful FAQs to a whole bunch of pages that maybe didn't have them before.

Jono:
I wouldn't write rubbish ones for the sake of it. But yeah, sure, why not? Generate some FAQs and make your pages more useful, and maybe get some rich results when Google sorts them back out.

Is poorly marked up structured data worse than no structured data?

Geoff:
Yeah. And one more from the chat before I tie things up. So is poorly marked up structured data worse than no structured data? Is it worth doing it if you can't do it properly? I suppose it is just kind of same sort of question. You mentioned before, Lily, about if it works, what does it matter? Whereas Jono, I'd imagine maybe you've got a slightly different take in saying that it should be right. If you're going to do it, then...

Lily:
Yeah. I think if you run it through the rich results testing tool, and it works. I hate to keep harping on that, I'm speaking from the perspective of an SEO director, where that's what matters to us. From the other perspective of writing clean code, probably It's better to not have it. But if it gets you rich results, then go for it. Sorry.

Jono:
I guess this is about quality and resource and prioritization. Would you be comfortable with a big billboard of your brand that had a typo in the name that generated some sales. I guess yes, but you shouldn't be comfortable with that, and you should make sure, A, that you fix it and prevent it from happening again. I guess take Google out of the picture for a minute, having some structured data is better than none, but having incorrect structured data is bad. If we're saying that this is increasingly the primary language that we use to communicate with search engines and Facebook and other systems, what we are, what we do, what our value propositions are, if you're misrepresenting that because your saying, oh, our opening hours are wrong or this is an article when it's actually something else entirely, that's going to have repercussions, in the same way that having a slow website has repercussions.

Jono:
In the same way that having thin content has repercussions. So much of SEO we try and approach incrementally, and we take baby steps and get proofs of concepts. That's fine when you're working on something like a content piece. The difference with schema is this has to be well structured. It has to be correct, it has to be technically robust. Otherwise you're either completely removing the value of it, or you're describing nonsense. And there isn't really a middle ground where you can get it sort of right and it'd be good enough. If it's wrong, it's wrong. It's a very specific thing.

Geoff:
Yeah. Anything to add quickly before we go, Lily?

Lily:
No, I think what Jono is doing, and WordPress and Yoast, is really awesome. A lot of the needs that we have for schema are built in to Yoast, which is pretty sweet, because a lot of our clients are on WordPress.

Jono:
Nice.

Lily:
So it definitely makes it a lot easier. But yeah, I guess that's pretty much it.

Geoff:
Yeah. Well, I could talk about this stuff for a long time to come, but unfortunately we are out of time. So thank you for everyone that's been watching. Thanks to Simon for managing the chat, unfortunately I haven't managed to dip into their as much as I'd hoped. We've taken a few really good questions. And thank you, especially, for Lily and Jono, been great having you here. Patrick, thank you as well, but I'll see you tomorrow, so it doesn't... [crosstalk 00:48:19]

Patrick:
I'm not a special guest. They're the special guests.

Have you got one last tip on making the business case for structured data?

Geoff:
Very quick last question for both of you. Have you got one last tip on making the business case for structured data? And also anything you'd like to pitch that you've been working on recently that people can go and look at?

Lily:
I've been doing a lot of work with structured data as it relates to EAT, so using things like the knowledge graph API search to see how prominent your entities are on your website, and if they're mentioned in Google's knowledge graph, because structured data can directly influence that. So I've actually influenced my own relevance score in the knowledge graph through structured data on my website, and that was through WordPress and Yoast, it just made it really easy.

Lily:
So I would say pay attention to that, because that has a lot of benefits. A lot of benefits directly within the search results and how Google understands the entities on your site. So...

Jono:
Oh yeah, definitely. Schema.org is open source and an evolving standard. And it's still very young, only 10 years or so, which in real world terms is still pretty new. There are huge areas which have not yet been defined. There is no schema for anything to do with animals. Now, that's particularly interesting when you also consider that the only people who are actively contributing to and shaping schema as a standard are Google employees and people who are close to it. Which means that if, for example, you run a pet store franchise, you could put some resource into schema.org and going and defining the schema for animal stuff. And then you might be able to nudge nudge, wink wink, and influence Google to say hey, we've already done the hard work, maybe a Google pet vertical might be a thing you want to support. Or some kind of rich results for cat sounds, I don't know.

Jono:
You get the idea. There is opportunity whether you're altruistic or nepotistic or commercialistic to get in there and to have an opinion that might shape a thing. I think that's really interesting. And then aside from that, one last tip is I mentioned at the beginning, most of what I spend my time doing is trying to make this invisible, but the work we've done in documenting the business logic, the technical approach, is all open source as well, and we've done tons of stuff around defining APIs and scalability and flexibility so that if you want to take what we're doing and do stuff with that, not in WordPress, not in Yoast, on your own, on top of what we're doing, the idea is this becomes the way that we build schema.

Jono:
There are other ways to do this, but we should be doing it together because it's complex and difficult. Please go and build on the work we've done to take this to the next level and to describe all of the animals. Why is that not a thing yet?

Geoff:
Well, I'm going to go and start working on [crosstalk 00:51:06]

Lily:
Marking up all the animals.

Jono:
Yeah, nice.

Patrick:
Marking up sheep.

Geoff:
Yeah, that's-

Lily:
They have animal sounds, don't they?

Patrick:
You literally mark sheep up, as well, it's perfect.

Geoff:
Yeah. We better leave that one now. Well, thank you again, Jono and Lily, it's been great having you on. And thank you for everyone that joined us on the live stream.

Patrick:
Thank you, everybody.

Geoff:
Please subscribe to YouTube channel, the thing down there. So we're going to do some more of these, hopefully, and please have a look at Sitebulb, the structured data features.

Jono:
Do the Sitebulb thing.

Geoff:
Yeah.

Jono:
Thank you guys. That was awesome.

Geoff:
That was great. Thank you very much for joining us.

Jono:
Bye bye!

Patrick:
Thank you.

Lily:
Thanks, everyone.

Geoff:
Bye, night.