All right, welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what we do is talk with webmasters and publishers like the ones here. Today, we have a bit of a special hangout in that it's focusing on one theme, structured data, rich snippets. And we have one of the experts that works together with the structured data team in Dublin, which would be Sven. Hi, Sven. Hello. I think you're here. So Sven prepared a short presentation on structured data in general to get us started. There were also a ton of questions submitted. We'll try to get through a bunch of those as well. If there are any questions along the way, feel free to jump on in and ask away. We probably won't be able to answer all questions. But if they're in the event listing, then we'll try to get back to them afterwards as well to kind of cover the things that either we didn't get to or where we don't have a perfect answer for you off the hand. All right, let me switch to the presentation. Which one is it? This one. All right, yeah. So I've prepared a couple of slides on this topic. And in general, it's a couple of sort of tips and tricks and best practices. And especially in our team, we've been looking at your feedback, a lot of your Webmaster's feedback on our forums, and also what we've seen in the reconsideration requests. So it seems that on some of the issues there, there's still quite a bit of confusion. And ideally, after that session, the majority of those of this confusion is gone. I mean, at least that's the plan. So let's see how that goes. And yeah, so let me run you through this. So in general, just as a couple of common points and something that sometimes people also forget is that we generally don't kind of guarantee that we show any rich snippets in the results. So even if you have valid and working markup, so it still doesn't mean that always we are going to show you the rich snippets of your site. So that's also something where, for example, if you're using the Structure Data Testing Tool and you notice that everything is shown OK, there are no errors, everything is good, it still doesn't mean that always we will show the rich snippets. So one thing also to notice here is that the tool itself only checks for the sort of technical aspects that the markups valid. And the syntax is correct and everything, but it doesn't really check for any sort of policy or guideline issues. So that's something to be aware of. And one interesting trick as well for you can be if you sort of want to see how your rich snippets look like, even though even if they are not yet shown in the search results, you can do a site search using the site operator. And that's usually a way how you can kind of see how they will be displayed. And if, for example, you see them there and you don't see them in the regular results, that could be an issue that maybe you might look into working a bit more on the quality of your pages and your site, just as a thing. So it can be a very good quick way for you to check what's going on for it. And one of the core sort of principles that's sort of underlying all of the general idea of social data that we have when making use of the data that you provide is really that ideally the social data that you provide in your pages should be never misleading or deceptive. So it always should be like an accurate representation of your actual content. So the structured data should really match to the content that you're offering and to the content that you are showing to your users. That's sort of one underlying sort of theme that you should always be aware of. And now in the next slide, again, I mentioned a couple of tools. I already mentioned the structured data testing tool. I guess most of you are aware of it. And that's essentially where you can do the live testing of your markup, both checking the individual URL that you provide, that we then crawl basically in the inside the tool. Or you can also paste in individual code snippets to check it. And another very interesting thing that people sometimes forget about is actually that in Search Console, you also get a lot of really, really helpful information around structured data and also rich cards, kind of the newer thing in this space. So basically if you go to a Search Console for your account, if you're using a structured data, you find tons of interesting reports in the sense of any issues or errors we've encountered. And that also happens for the new rich cards. For example, the new ones that are recently started like courses or sort of local restaurant ones. So it's basically a very good resource to see what's happening in that space. And yeah, so the next slides essentially capture the most common feedback and issues we've seen, both from the forums and also from reconsideration. Because quite often we've seen people, for example, having some issues with their site, there might have been some mail action even regarding implemented search data. And in reconsiderations, often we see that webmasters right in kind of not being reassured what's happening. And so this is essentially now a collection of the most common issues where we see that some people might still be a bit confused and there might be some uncertainty. So one thing here as the first element is that if you, for example, are using product markup to markup items that you have, for example, in your store or services that you're offering, that's really good to know to actually use product markup individually for each item that you present on the page. So just make sure to avoid using product markup over a generic category page. For example, if you say you have a product markup and you say, I don't know, holiday homes in Barcelona and then you have a list of individual holiday homes, that would be kind of misleading in the sense that you have the product markup itself associated with a very generic term. For example, holiday homes in Barcelona, because this is a very generic list of items or like a category, and that's why for users it kind of would be confusing if you, for example, also combine this with reviews because then it would not be really clear what that particular review is sort of referring to. And the same kind of applies to aggregate reviews in general. It's also the case that if you are using aggregate reviews, ideally they should relate to one specific item or service and kind of be attributed there individually for each item. So again, it shouldn't be across a generic list or category of items, but rather specifically for each item. So that was, I guess, that's one of the main issues we are often seeing where people get a little bit confused. Yeah, with the next item here, this also very, very interesting in the sense that also coming back a bit to this generic statement I had earlier in the sense of markup ideally not being sort of misleading or deceptive for users, that kind of means that if you markup, for example, if you use reviews on your page and you have this embedded in your markup, then ideally users should also be able to see the reviews. So if you only have to the markup, but on the page itself, as a user visiting the page, if you have no way of actually seeing those reviews and if you have no way to sort of recognize where those reviews are coming from, for example, is it like some widget that you embed on the page itself or maybe you have like a sort of a test terminals page, like a review page, a separate dedicated page for this where all of this is collected or you might be using a third party service, all of those things ideally should be clear for your users in the sense that if somebody comes to your page and there are reviews, people should be able to see them and it should be clear where those reviews are coming from. And yeah, and also kind of simple things in the sense that if you are, for example, using like a review widget, which is very common, like those little items where you can, as a user, select the number of stars, for example, then of course ideally that also should work in the sense that if a user clicks on the stars in the end, that should translate into that vote getting recognized. And in the end, in the back end, when we look at the markup, that vote should be kind of counted, increase the overall number of votes and so on. So it should be like a real thing and not just something that looks like it's working, but it's actually not working. Yeah, looking at the next slide, that's also a very common thing we've seen in a couple of questions around where people are not so sure when it comes to like third party review sources. So in general, we are absolutely fine with people using third party review sources for their reviews. I mean, that's absolutely fine. There's nothing like bad about that. The only thing to keep in mind when doing this would be, again, to kind of make sure to point out where this particular review is coming from. So that you actually sort of link, for example, to the source of that review. So that as a user, if you see that review coming from this third party site, that you can just click on a link or click on a logo and end up on the third party site where the actual reviews are presented so that the user basically has this full transparency of where those reviews are coming from. And if you do it that way, that's definitely no, there's no problem in embedding reviews coming from a third party site. And then there's essentially the last slide I had here which is also a common source of confusion, especially when it comes to product markup is the sort of the naming of the product that you use in your markup. So essentially, this ideally always should refer to like a specific product or service, like really the specific thing, the specific item that you're offering on the page and it should rather not be a very generic description of for example, the generic company, like for example, not only saying shoes, but rather the specific item inside that category. And also a common thing we're seeing quite a bit is people using the company name inside product markup and that usually also would not be a very good use because usually the company doesn't translate to a particular product or service. There might be some very rare kind of corner cases where maybe the company name really sort of represents a particular service, but usually that be kind of rare. So in general, sort of a good guidance would be that company name wouldn't be a good fit for the product markup. Usually for those cases, we would have the local business markup for example or any other of those subcategories of this element which essentially refer to like companies or business entities. And another common thing here would be matching, for example, reviews that are for one entity, for example, for the company and matching this with other markup, for example, product markup. Like imagine if you have a product markup element on your page and you combine, you add an aggregate review element to it, but those reviews actually refer to the company and not the particular product that you have marked up, then that would be also very, very confusing. So that's also good to keep in mind to not like mix elements that are not sort of really related in that sense, especially when it comes to reviews. Yeah, and essentially those are pretty much the major issues we've seen so far and the main sources of confusion. I hope that was bringing some clarity around that. So I don't know if you have any particular questions around the content on the slides or otherwise we could, I guess, have a look on the other subject questions. Yeah, I have a question regarding the reviews. Because you were saying the reviews and so if the website is not a directory and it's not like a so-called like a trip advisor website, a lot of companies just try to kind of add something in the review, like in the markup. If I mean, they need to somehow back up the reviews, right? So like if they're not a directory of reviews, if they're not like a site like a trip advisor, they can just go and add the reviews, right? Well, no, I mean, if they themselves provide the facility for users to leave a review, for example, the classical sort of review widget or you have also certain, in addition to leaving sort of the review stars or something, people can leave written individual review texts and stuff and the site is basically collecting those, like customer or user reviews and presents them sort of transparently on their site. That is perfectly fine as well, right? So as long as they don't, it's not a good idea. Well, I mean, yeah, if a site only, if for example, a site implements review markup, like in the source code, like basically presented as a markup, but as a user, you have no idea to see like where this review is coming from, how it is generated, that indeed, that would be not a good practice. Okay, do you want to say something? And how about when that markup is added to the reviews are added to JavaScript? Sorry, could you repeat again? And what if those reviews are added to a page by means of JavaScript? So they're not part of the real HTML? I mean, usually if we can sort of access the resources to need it to like render, to like, yeah, to read this and to fully render the page, including those JavaScript elements, essentially then, if that's possible, and that both the user would see the reviews when they simply load the page, plus when Googlebot cross it and our systems essentially render the page and most likely will be able to interpret the JavaScript so that we've seen sort of the equivalent of the render page that the user sees, then that also should be fine. Essentially, as long as Googlebot can reach that markup and at the same time, users would see the related corresponding like content that you should be awkward with. Thank you. So can I ask, we have a site which does reviews, but it's doing reviews of concerts and these are not kind of short user reviews or product reviews. They're like six to 800 words, sometimes a thousand of a large event. I'm saying that the item reviewed is a music event. Does this make sense? Is there something Google understands or should I be looking at something different? That in general should be fine. So I mean, there are, since there will be those different sort of subcategories and music event being one of them and that seems to fairly well mapped to your need in that sense. So that should be definitely okay. Okay, thank you. It's really hard to hear you. Okay. Very vaguely. I have seen that they use aggregate website aggregate reviews, like 43 reviews. So if I'm saying correctly, you mean that if a website embeds reviews and says for example, they are 40 reviews and the average rating is like four stars, whether then they also should provide a link, for example, to the actual source of the reviews, right? Yeah, yeah, yeah, essentially, I mean, you would use the markup to represent this like the number of the reviews with the individual reviews generating essentially than the average review and you should, on the page, visible to the user ideally kind of have a link or to the actual reviews, like where they happened in a sense. Unless it's for example, only the thing where you have this review widget where a user simply selected stars and then the average of the user selection is presented plus the counter, for example, is displayed. If that's all there is, and that is also, that is fine. So essentially, if there's no other aspect to your reviews where people leave text content or whatever, where you would have a dedicated page for it, which ideally you could link to, that also would be fine if you have only the widget itself and it displays the same information, both for users and being present in the markup that should be good as well. All right. Let me run through some of the questions that were submitted and we can open things up for more questions from you all live afterwards or if you have any comments or questions in between, we can do that as well. I'll ask the question and see if Sven has an answer for it. We went through some of these to double check that we kind of know what to say, but there might be some in here where we don't have an answer offhand and where we'll try to post an answer later on in the Google Plus event page. So the first one I have here is, how important is the geo-coordinates property for type local business in local search as we want to improve the location point in the Google for Business branch listings? Is it imperative that we update the geo-coordinates as well? Can any mismatch harm rankings? Yeah, interesting question. So I mean, my take here would be that essentially it's not necessary to really add it there. Essentially it's pretty much like with many other signals a very useful thing to add if you have that information available. So it can be just a nice addition in the sense of giving us additional signals for various purposes. And ideally if you use it, then it should reflect also the correct location. But yeah, I don't know if John has anything to add there. Yeah, as far as I know, we don't use that for the local business search, but it's the first time I hear of this. That's why I am assuming that we don't use it. But if you're worried, or if you're wondering specifically around the Google My Business listings there, I would go ahead and post in the Google My Business forum and ask the folks there because they understand these connections a little bit better. Okay, next question is with regards to price range thing. What should I put in there? The price range for business, for example, dollar, dollar, dollar, this is appearing as an error within the local business markup. Do we just put the price range for all of our products from X to Y or what should we put in there? Yeah, that's interesting. So in general, that actually kind of should be the sort of this dollar range kind of, for example, as similar to what you very often see in restaurants, it's one of the typical sort of examples for this particular feature in the sense of determining whether this is more cheap or more expensive restaurants where they have this from one to three or four dollar signs to kind of just indicate in which range it is. And that should work perfectly fine with the structured data testing tool. So I've checked a couple of examples earlier and didn't spot any particular errors around that. So that might also be something where maybe if you specifically with your website are seeing some errors, maybe you could come to the Webmaster forum as well and post your example. Maybe somebody there could have another look to check what's going on. But in general, it should be fine and be also supported by the testing tool, but also like supporting our end in terms of displaying it as well. As far as I'm aware of the recent changes to the restaurant markup for rich cards, from that moment on, the structured data testing tool starts to report errors about images being provided for local business, but also the price range. Was that ended or was it actually meant to be added for the restaurant listings and accidentally was pushed through to the rest of the local businesses? I don't know. I don't know if you know off-hands when. We can double check with the structured data folks as well. I know one of the kind of limitations there is that I believe we only show one type of issue in the structured data testing tool and we can't show if something is more like a warning rather than an actual error. So I think that's one of the misleading elements there is that for some of these, we would like to guide people towards providing the full set of information, even though it's not necessarily required and in the structured data testing tool, it might flag that as an error instead of as a warning. And I think there also, because I think in the past, we've received a couple of sort of feedbacks along the lines of people, sometimes getting also confused a bit by the fact that sometimes stuff gets flagged as an error, which might not necessarily be one. So I guess there also, we had a couple of like a bit of feedback along those lines and sometimes where the structured data team, like who's looking at that? Essentially, sometimes those things generating a bit of confusion. I think there's discussions around ways how like in the long-term, I guess we could make this a little bit less confusing. I know you see a question about Freebase quickly. Oh, sure. I hope we can answer it. No, it's just that when Freebase, like when Freebase moved to Wikipedia, some people still made the final changes in Freebase or their own name and stuff like that. Or are you still gonna leave those changes? You know, are you just gonna leave them the way it is? Because it's kind of not fair. They moved to Wikipedia and the people that didn't have a chance to create something about themselves on Freebase now can't. And the ones that did, their stuff kind of remained on your end. Do you know what I mean? So... I think that should be dynamically updating from a variety of sources. It's not just limited to the initial Freebase dataset that was there. So that wouldn't have been that way. It's like the people asking me, what's going on? How come this guy has this and then the other guy can't get it? I'm like, well, you need to be an established source in order to create that page and I gotta give him the whole information on why and how and I can't tell. I'm like, you know, this guy did it, going to Freebase, logged in, he did this, you know? I mean, like... You know, the person doesn't know what's going on. Stuff changes, stuff changes. That's kind of the way it is. So that's something that we moved more to kind of an automatic pipeline, but the things that are already in there, they might stay in there for a while. Yeah. What's a while? What would you say a while is? I can't make up any numbers.  Okay, thanks. All right, we have another question here. I use third-party approved company to get our service reviews. We have a widget that's on our site linking back to the reviews, which are hosted on their site. How should we implement mark these up on our site? I think you kind of covered that already. Yeah, anyway, I mean, it would be sort of regular review markup in that sense, kind of the regular map, essentially just mapping the third-party reviews, the data that you're getting to the relevant sort of structure data elements. And once you essentially, which I guess most likely, if you're using that third-party tool, I would imagine they also provide the data in the sort of needed format anyway. So you most likely get kind of a feed that you immediately sort of can use and embed on your site. The thing to note, as I mentioned earlier, would be that if it's a third-party thing, ideally, you should sort of link to that source so that essentially, once you have the markup and the data in your pages, that users also just see where this is coming from and they easily can get to the actual source and sort of verify and sort of further see what's happening. All right, here's one. When you update the schema testing tool, why can't you publish your changes so that we can figure out what you changed?  Yeah, well, I think we'll take this as feedback and pass that on to the team. This is something that we hear every now and then where someone will ping us and say, hey, how come suddenly the testing tool says I need to do this, where previously it said I need to do something slightly different. And it seems like we could do a better job of letting people know what is actually changing there. All right, let's see. Should the use of the same as property be used to link all of your citations? We have a number of branches, and we're currently using the same as property to links to Google Plus page for that branch, the main social profile, but we also have Yelp, Yelp, and all the other places linked. Is there any advantage to doing that and can it help with local ranking? Yeah, so I'm not sure about local ranking, and in general, how it would really help you so much. In a sense, I guess it's just for us another interesting signal also to find out more about how your elements are connected. So it's kind of similar to the canonical tag where you also just specify which one is sort of how certain things belong together, which one is your preferred one, and also for us just here a reference to the different sources. And so in that sense, having it is useful, but it's probably also not necessary, especially if you have a very complex setup with lots of different places than having each and every individual one being resembled there. I mean, it's probably not really necessary, but having as much of that structure mapped to this thing would be helpful. I don't know if maybe John has some additional points here. Yeah, that's, I guess like Sven mentioned, that the local rankings is a part that we don't have that much insight into because it's essentially a different team. So we can't really tell you what is involved there. I think if it makes sense to provide structure between your various locations where you're giving information, then I would go ahead and do that. I wouldn't go overboard with this kind of markup and assume that it will make your ranking skyrocket, but if you can give us some kind of semantic setup for your content, for your pages, that's all. There's some more local business questions here that I'll skip over, because like I said, we don't really know that much about what's happening there. Does Google support connecting entities across URLs via IDs or URLs, for example, a product, could reference a brand via an ID outside the page where the organization brand is marked up? Yeah, good question. I am not so sure about that, to be honest. That's something I guess we might just check back with the team how that, whether that's possible. Yeah, I think for some of these, we'll have to double check with the team. Many feel there's no point in adding markup to sites beyond what you support for rich snippets and rich cards and knowledge panels, making it extremely difficult to convince folks there's a point to going beyond rich snippets. Is there anything tangible you can say about the merits of marking up beyond like the basics of rich snippets? Yeah, that's pretty interesting. Definitely, if you feel like there would be interesting use cases for the particular sort of services or things that you're offering, it's always a good thing to maybe experiment with it and sort of try things out. But in general, in practice, when it comes to real tangible benefits, it's kind of hard to tell. So usually beyond sort of the established things where you can clearly see, for example, rich snippets or rich cards for certain elements and whatnot, beyond those sort of already supported elements, you might not directly see any sort of immediate benefits. So it's more like for you to maybe try things out and kind of be maybe looking at certain future technologies and be in a good position for whenever, if ever certain things sort of get supported. But immediately you wouldn't necessarily see any additional tangible benefits from that. But does Google look at that information and maybe use it in a different way to better understand the content itself? As far as I'm aware, not really. So I mean, aside from the things that are officially yet or in some ways sort of in the testing phase kind of supported, aside from that, I don't think that we would be using it because also the amount of data that we would be getting there since it's if it's not fully supported, not official and whatnot. So hardly anybody would be using it. So it would be very hard to kind of base any, like you use those things in a way since also the users should be so sort of limited. And yeah, in that sense that there would be any tangible benefits in that sense. No, but in industries like e-commerce sites, for example, those often produce quite a lot of structured data yet you only use, what is it, review and pricing for the rich snippets. And beyond that, there's no visual evidence you use those other properties. Yet the majority of e-commerce sites produce just quite a lot of structured data. Does that mean they don't have to? From talking with various people from the ranking side, we try to understand the kind of the attributes and the elements on a page more from the text itself rather than just from the markup. Because like Sven mentioned, if it's not officially supported for rich snippets, then the quantity of the markup is generally fairly low and the quality of the markup is like all over the place. Because if we don't have any guidelines on how to mark things up, then people will just mark things up in all kinds of ways. So this is something more that I'd say is almost like forward-looking from the webmaster's point of view rather than something where you would see any effect at the moment. Thanks. Are there any merits to marking up e-commerce category listing pages? And if so, what type of markup would you prefer? Like schema.org-slash-item-list-press-products or schema.org-slash-offer-catalog-press-products? Yeah, so there my understanding so far is that it wouldn't really make much of a difference. So for example, if you have an item list and use this as a collection for the different items you're offering or the offer list there, it doesn't really matter too much. So essentially, it's kind of up to you. In a sense, we understand both and several sort of variations along those lines. And especially if you use category pages or listing sort of overview pages, that definitely would be very good to do in the sense of using such an item list to really kind of especially using category pages or listing sort of overview pages. That definitely would be very... Okay, was that myself? Interesting. Whenever you use those, like category, if whenever you have category or listing pages then using those item lists or similar sort of list type of structures would be extremely helpful to be able to actually then have an actual markup representing sort of the individual items in that sense. All right, schema.org has recently started with industry-specific extensions. Do you intend to support those? Yeah, good question. I'm not sure, so in general also I guess we wouldn't really talk much about whether this is planned or not. So essentially that's I guess something where we can't really try too much at the moment. Yeah, it's always hard to make predictions ahead of time. Even when we know internally that something is going to launch next week, it's sometimes hit and miss whether that actually happens. So kind of looking forward even past that and saying, well, we intend to do this is really hard and we try to avoid that as much as possible. I think this goes in a similar direction with the next question. Last May I wrote a post asking whether there's any chance Google will add rich snippets or rich card support for schema.org slash service. So webmasters are no longer forced to use schema.org slash product to describe services if they want to have rich snippets. Is there any word about this yet? Yeah, similarly not really. Okay, we should double check on some of these and kind of see if the team has anything that we would like webmasters to prepare for. Because it's always, I think a frustrating situation for us to be in, on the one hand, we don't want to pre-announce things to make webmasters kind of unhappy about things that aren't here yet. On the other hand, if nobody knows about something then they won't be able to provide this markup so that when we do have time to actually turn it on, we wouldn't have any markup available. Exactly. Yeah, that match is always tricky, but we'll double check with some of these with the rest of the team as well. What can we use for the price range of a local business? It doesn't make any sense for us. For example, dollar, dollar, dollar. I think we looked at this in one of the earlier questions. Yeah, should be pretty much the same thing. Even though Google offers no rich snippets for category pages, I regularly encounter search results containing rich snippets for listing and category pages due to malicious markup. Most of these go against your guidelines, but end up generating rich snippets nonetheless, often forcing competitors to do the same thing. Are there any plans to step up countermeasures to discourage the publishing of such malicious markup? I filled out plenty of spam reports, but I hardly ever see any action. Okay, yeah, that's a good point. So, I mean, essentially, only for example, because you might see some competitors doing it and you might see it at least at some point in time kind of working, like doesn't mean that it is really good practice, right? So it's not something to copy in that sense. And also one thing to note is that in general, not all of those scenarios that you have also posted in the comment, and not all of them are clearly violations of our guidelines. So some of them are more like what we would perceive to be kind of more low quality. So definitely not recommended and not best practice, but we also wouldn't really take action against them. For example, one common thing that we see a lot is if somebody has, for example, their local business marker and they have reviews for the company and maybe they embed those reviews in the future of maybe most or even all of their pages. And this might lead to sometimes, lead to some of those reviews being shown in search as well, even though they're kind of for the company. But that's something where we wouldn't necessarily see this as I am per se. So that's kind of one of those more low quality scenarios where we definitely don't recommend doing it, but we wouldn't necessarily take action against this. It definitely will be a completely different story if somebody combines this markup with actual product markup. So if they have a product on a page and they then add a review and instead of the actual product review, they add this review aggregate from the company then immediately it would be definitely a clear violation of our guidelines and that's something we would definitely take action on. And I've seen, let's say, I've seen a lot of spam reports and in my experience, we definitely, whenever it's clearly a violation of our guidelines, we definitely do take action. So it's not like they get lost or it's not like nobody looks at them. They're actually getting looked at very regularly and essentially are also for our team an extremely important source of finding out about new ways how people are either intentionally or maybe accidentally doing stuff that might be a bit beyond our guidelines. And definitely, let's say if you filed certain spam reports and you still are really strongly believing that there's something kind of wrong and you see nothing is happening, that would also be an interesting case maybe to flag on the Webmaster forum to just bring it to our attention again so we can have another look to see what's happening there. It's important to say there's two spam reports. One for the Webmaster and there's a Rich Snippets spam report. Right? Sorry, what was that? There's a Rich Snippets spam report and there's a regular spam report. Yes, and if it really resembles something closely related to Rich Snippets, definitely I recommend to use the Rich Snippets spam report form. That's really where somebody from our team that's sort of dedicated member of the team that is really aware of all our policies in the Rich Snippets structured data space, they would look at it and it's also good to have it separate from all the other Web spam reports just in terms of also the volumes because I guess structured data Rich Snippets is a bit of a more compared to the old landscape and niche topic in a way. So having it a bit separated also makes a lot of sense. So I recommend if you want to file spam reports and definitely use the structured data Rich Snippets one. Okay, the values for action platform property, your documentation mentions, aren't valid schema.org enumerations. They aren't in schema.org. Interestingly enough, structured data testing tool generates errors for them if you don't add them. And when you do add them, it shows another value. How come these enumerations aren't hosted as an extension either on Google schema.org or schema.google.com? That's another of those questions where I'm at the moment not really aware of what's the story there. So that's I guess one where we ideally need to check back with the team to get back to you later on and kind of post a comment in the events page. Like that's something too, we need some more feedback. All right, we sometimes show prices with three or four decimal places. We sell electrical components in unit prices in large volumes. Our schema markup is correct, but in Google listings we get some weird stuff going on. An offer price of 0.138 euros shows on Google listings as 138 euros. Quite a difference. Is there any known schema or Google issue for price offer schema with usage of more than two decimal places? Yeah, like I'm not aware of an existing issue. However, this exact sort of question, I think we are like has already been escalated to the team. So there's kind of like a discussion going on, but I think we don't have yet any final like feedback around that. So that's something I guess we just have to wait a bit more to get some more. Comments from the team there. OK, many SEO developers are worried about how many pages they should include the schema markup code. We constantly see the entire site getting the same code repeated. What's the right way? Yeah, I mean this I guess touches also a bit on the previous one with this third party review things put in sort of on every single page, right? So in general, I guess the same like guidance there would apply as well in a sense that ideally best practice would be to just, I mean, use kind of common sense in a sense that if you have certain important elements on a page, let's say you have a product page, then obviously using product markup that reflects this particular item and describes the properties of this item that would make a lot of sense. And that would be in that case kind of also limited to those individual pages. So it would be kind of a page by page thing matching the individual requirements of a page. And that would be sort of the common best practice and I guess common approach like usually what muscles should have. And as I said before, like those elements where sometimes people place them on all of their pages like company reviews and stuff like that. It's definitely not recommended. It's not sort of best practice, but in the end, I mean like nothing better happens if you do it as well. So like, yeah. All right, with supporting Jason LD, the rules were changed about directly marking up visible content. Is it now okay to use meta tags for micro data as long as there's also visible text to confirm? Is it safer to still use micro data on visible content? That's making it easy for you to verify the markup does represent what's on the page? Yeah, I'm not one of the censors there. It's definitely what is important to make sure that for users, it would be kind of visible as well. So I believe both ways should be fine, but that might be also unless you know like more certain nature, that's something where maybe we could check the detail as well to see what's the story there. But I believe both ways like described should work. I think with the move to Jason LD, we'll have to figure out what the final recommendations will end up being because since the Jason LD markup is something that's separate from the actual text on the page. But it's usually easier to just mark up the text directly, I guess. How come when we add posts to the Webmaster forum, we never hear anything back? This is frustrating, Sven. Can you fix this? Yeah, well, the fix is in the works, no, but yeah. I mean, it's kind of I guess the general sort of thing that we sometimes have on the forum that I mean, future of the high volumes and things happening on the forum, I mean, it's kind of hard to always get back to each and every single question or issue that's posted there. So I guess everybody in the TC community and also the Googlers active there, I guess do their best to try to really pick up on sort of everything. But sometimes I guess it can happen that stuff sort of falls through the cracks a bit. But I mean, if you believe you have a sort of a problem and issue that you posted and sort of nothing happens, definitely kind of persist a bit and ask, ask again. And I'm sure that after some time somebody will pick it up. And usually, especially my experience like the TCs, for example, they're super, super active in really once they recognize some interesting issues or problems to kind of escalate it to the Googlers and to our team. And usually it works really well to flag issues if there are issues. No, I've had several posts being flagged already and being put through to Googlers. But still you never get to hear anything back. And I know other folks who have the same experiences. And these are folks who are most of the time also pretty active in the SchemaDARP community. So actually folks who really know how this stuff works. And even those get nothing back. Even on Christmas, John is active. No, it's not so much John itself, but it's really, most of the time, it's really bugs and structure that are testing to which folks who participate at SchemaDARP GitHub even recognize where the issue is coming from. And they go out of their way to even describe what's going on and why it's happening. But yeah, those folks never get to hear anything backside. I know five, six folks already have completely stopped editing those types of issues. Yeah, I guess that's a good feedback, I guess. I mean, it's tricky in the sense that we get a lot of escalations also from the top contributors in the forum. And we try to handle those internally, regardless of what we can say externally. But it definitely makes sense to make sure that we can at least get some kind of update out there to those threads so that you notice that we did something. That would be great. All right, there is a question in the chat here. What's the qualification for the site link search box? I added this to my site, but it's still not showing. What could the problem be there? So I guess with the site link search box, one thing to keep in mind is that this markup you can put on your page for the site link search box, in particular, is only used when we already show the site link search box algorithmically in search. So putting this markup on your pages won't make it so that the site link search box is shown. But if we do show the site link search box, then we'll try to use your markup to pick the appropriate pages to link to. So that's kind of confusing and a little bit frustrating, I can tell, because you go out of your way to add this markup, and we only use it when we would show it anyway. But that's kind of the way that this is implemented on our site. How about a follow-up to that? I think it's Lynn's question. God bless Google Translip, the only one I felt his name. So basically the box, by default, showed up for a lot of websites. So if they don't use it, and then you notice that they don't use it for a certain period of time, it just disappears. Is that correct? Default, I saw a lot of websites because when you introduced it the first time. I don't know. I don't know if it has to do with the markup. As far as I know, the showing of the search box isn't related to the markup itself. So we only use a markup if we would show it anyway. And especially with new features, sometimes they twiddle with the dials to try to find the right amount of sites or the right amount of times that we show that in the search results. So that's something where you'll probably see some fluctuations with regards to how many sites see something like that. OK, thanks. So John, related to the Sighting Search Brass question, so even with a website that don't have a markup, so you won't appear the Sighting Search Brass anyway? If there's no markup for the Sighting Search Box, we'll do a site query for that website. So if you enter, I don't know, if you search for NASA and then you enter in that Sighting Search Box, Moon or Mars, then we'll do a site query for the NASA site and search for those extra keywords that you have. So my scenario is if there's no Sighting Search Brass, then you won't show up in the future, correct? Yes. I mean, that can always change over time. So I can't say it will never show up, but it will only show up when we do actually show the Sighting Search Box. So is there any other way that you go to show the Sighting Search Brass beside the markup? No. OK. All right. I have to run. Someone else needs this room, but it's been great talking to you all. Thank you so much for joining us then for your presentation for all of your answers. We'll try to go through the questions that were left and answer them in the thread where we can and get back to you then. All right. Thanks so much for everyone and hope to see you all again in one of the future Hangouts. Bye, everyone. See you. Bye-bye.


Historically, the importance of wholesome, nutritious food is a matter of record. Superior performance by Men at Sea has always been related to good nutrition and sound health. A wholesome, high-quality diet is essential for all naval and marine personnel. For more than 60 years, the Army and later the Air Force Veterinary Services have provided food inspection support for the United States Navy and Marines during peace and war. Because of their expertise in the field of animal health, as well as their knowledge of food chemistry and microbiology, veterinary service personnel are more than capable of shouldering the food or subsistence inspection responsibility. American seapower commitments are worldwide, at most naval facilities are within reach of Army veterinary support. Typical Army veterinary missions supporting naval operations can be observed at the San Diego branch of the U.S. Army Medec at Fort Ord, California. Here the military veterinary service performs the mission of safeguarding the health of Navy and Marine Corps personnel and preventing financial loss through accurate and timely inspection of subsistence during purchase, handling, and storage. This food inspection may require coordination with one of three different accountable agencies. The Navy resale system, the Naval Supply System Command, or Defense Personnel Support Center. Inspection coordination for DPSC controlled subsistence is accomplished in accordance with their directives. When subsistence is intended for consumption in dining facilities, a shore or a float, the Naval Supply Officer assumes total responsibility. The officer in charge of the commissary or the resale system is accountable for items destined for resale that are procured either from DPSC or local procurement. He operates under commissary store region similar to the present Army concept. This region functions under the direction of the Navy resale office. An inter-service support agreement or ISSA, executed by the Army Command providing the veterinary support and the requesting Navy Command, specifies the type and amount of veterinary support provided a particular naval facility. The Marine Corps order and Navy supply instructions are considered in developing the ISSA. The ISSA establishes the relationship between the naval facility and the veterinary service. It should describe support that the veterinary service requires from the Navy such as offices, billets, utilities, finance, janitorial services, and transportation. It should also specify the veterinary services to be provided such as food inspection, food establishment sanitary inspections, and animal disease prevention and control. Provisions of the ISSA will vary from station to station. Five of the nine recognized classes of military food inspection may be performed at Navy installations. Class four inspection, the procurement inspection at destination of subsistence purchased for the Navy by DPSC is for all terms of the contract, just as at an Army installation. Veterinary personnel work closely with Navy personnel to assure that only quality products in good condition are accepted. Products which have undergone excessive deterioration will not be accepted following class four inspection. Low grade eggs will have less eye appeal and shorter storage life than higher quality eggs. Contaminated food could possibly cause foodborne illness which is always a problem and would be particularly significant in a submarine. In the case of fresh meat products, class four inspections are normally performed at the time of delivery to the commissary. Inspection is performed to ensure a wholesome product and the quality ordered. Class four inspections of defense personnel support center contracted items follow procedures outlined in the DPSC inspection manual. Non-conformances are reported to the commissary officer or supply officer who will determine acceptance or rejection of the item. The commissary store region authorizes local purchase of those items catalogued in the Navy commissary stock list and price catalog. These items do not usually have specification type requirements but inspection will be performed if requested by the naval officer in charge of the commissary. It is his responsibility to ensure that local purchase items originate from approved sources and it is the inspector's responsibility to notify him when violations are noted. Joint service regulation AR 40-657 directs surveillance inspection of government owned subsistence at Navy and Marine Corps installations. The ISSA may designate this as a responsibility of the veterinary officer. Class five, six, seven and nine inspections deal with subsistence already owned by the government. Class six inspections surveillance inspections prior to shipment may be performed either at dockside or at a warehouse prior to loading a board ship or transfer to another shore station. These stocks will be under DPSC control. Only Code A semi-perishable subsistence will be accepted for use aboard ship. Code A indicates the product has at least six months shelf life remaining and may be issued without restriction. The subsistence officer may request an inspection of the product to extend shelf life and continue the Code A classification. Inspection of delivery vehicles for general sanitation and proper temperatures is conducted prior to loading. The product is inspected and any discrepancies are noted on the inspection report and reported to the accountable officer. The class six inspection report is retained in the inspection office unless the subsistence is being shipped overseas. Reference may be made to these reports in the event of an unsatisfactory material report or other communication pertaining to receipt of distressed products. Class five inspection or inspection performed on any receipt except purchase is performed on government owned subsistence when received at destination. The inspector must be alert for deterioration that may have resulted from transportation problems such as an excessively high temperature or shifted loads. It may be necessary to perform destructive sampling to detect internal deterioration. Problems should be reported to the food services officer of the supply office and to the veterinary office that conducted the class six inspection. The transportation officer must also be notified if the problem is due to transportation. Upon request subsistence items intended for use at Navy commissaries undergo class seven inspection. This is a surveillance inspection performed at issue or sale. Navy commissaries are tenants on the installation. They operate under regulations issued by the commissary store region. Veterinary inspectors should establish a close working relationship with the officer in charge of the commissary to resolve such problems as temperature or code date discrepancies of fluid milk. When major problems or recurring deficiencies occur it may be necessary for the veterinary officer to coordinate with the commissary store region. Class seven inspection is an inspection performed at the time of issue or sale. Items intended for use in dining facilities are warehouse to the supply center. The customer service division of the center may request class seven inspection. A detailed report of a class seven inspection is submitted to customer service division when a problem is encountered. Class nine inspections are cyclic inspections performed during storage on government owned perishable and semi perishable stocks to be held in storage for long periods of time. Computer listings on stocks controlled by the Navy may not be available. Therefore the inspector should develop a system that ensures timely inspection in accordance with AR 40-657. He may select his samples and mark them for warehouse personnel to remove at a later time so the actual inspection can be performed in the laboratory. The inspector should be alert for damaged cases even if the product is not due for an inspection. The officer in charge of receiving and storage and personnel in the requirements division should be notified if distressed products require expeditious handling. When inspecting DPSC stock managed by the Navy, Appendix S of DPSC manual 4155.5 is used to determine the sample sizes. Inspection of the product ordinarily may be accomplished by organoleptic methods. In some cases special equipment is needed such as a vacuum chamber used to check for faulty packaging of vacuum packed foods. The veterinary service may recommend the disposition of damaged food items but the naval supply system makes the final decision on the disposition of the product. The ship supply officer or subsistence officer may request veterinary inspection of subsistence aboard ship. When boarding a ship the ensign or flag is saluted first and then the officer of the deck is saluted. When departing the officer of the deck is saluted and then the ensign. This protocol is a tradition unique to the Navy. Veterinary personnel should become familiar with and comply with Navy protocol. Both perishable and semi-perishable products may be inspected. Inspection of semi-perishable products may be requested to determine if shelf life can be extended. When one sees the congested storage area aboard ship it is very apparent that proper marking and display of markings are essential to assure proper identity and rotation of subsistence stocks. Proper rotation of stock is important both aboard ship and in warehouses. Veterinary personnel should also work closely with the Naval Preventive Medicine Unit. The PMU may often assist the veterinary service by providing such services as the identification of insects infesting subsistence items. Military Standard 903 is a joint Army Navy publication which outlines the procedures for inspection of commissaries. When the ISSA provides for a veterinary inspection of commissaries this document should be utilized. The veterinary service provides support for Naval hospitals that utilize laboratory animals for research. Full-time Army veterinary officers may provide this expertise at Naval Medical Research Units or NAMRUs. Veterinarians have supported NAMRUs not only in CONUS but in such areas as Egypt and Taiwan. The military working dog used by the Navy or Marine Corps has provided complete veterinary medical care. Dog's training is periodically observed to determine its effectiveness. Personnel arriving at a veterinary duty station supporting Naval operations should first familiarize themselves with the standing operating procedures. This will help him determine whom to contact when problems develop and how to provide the services specified in the ISSA. Incoming veterinary personnel should be introduced to Naval personnel with whom he will be working. Upon arrival, supervisory veterinary personnel should call on the senior medical officer. Continuous coordination with medical and command personnel can be maintained by periodic reports and personal visits. Major problems should be brought to their attention immediately. At home and abroad the veterinary service shares in the duty of keeping American sailors and Marines fit and ready for any contingency.


couldn't be with us this week. He is taking some well temporary CO, face-plated Cobra Command. Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Cough Pardon me, snaking my throat. Today, we are going to be taking a look at a very singular vehicle in the Cobra Command Arsenal, The 1987 Cobra Bus Boar. The Cobra Buzz Board was first introduced in 1987. It was also sold in 1988 and was discontinued in 1989. In 1989 it was not replaced by any similar vehicle, because the Buzz Board is utterly unique in the annals of Cobra's military machine. The Cobra Buzz Board is what is classified as a monowheel vehicle, which is defined as a one-wheeled single-track vehicle. Unlike a unicycle though, the rider is seated either inside of or adjacent to the wheel-ring, as opposed to above it. Extensive research has turned up no instances of any real-world military applications for monowheel designs, aside from the use of pedal-powered monowheels in the Chinese army, possibly used for the development of balance, or perhaps just for fun. And now, let's take a closer look. The most prominent feature of the Buzz Board is, of course, the boar's teeth, which the blueprints inform us are specially hardened, variable-pitched digging teeth. They are made of a red rubber and fit relatively snugly around the circumference of the main body of the Buzz Board. When played with on carpet or other grippy surfaces, the blade spin fairly easily, and the effect is pretty great. However, I do recall that my childhood Buzz Board was particularly snug and did not spin well, so I am unsure if that is a common problem with the Buzz Board or not. It is possible that this example has loosened with age. The right-hand side of the Buzz Board has a forward-hinging scissor-wing door, which rotates roughly 160 degrees to allow for entry into the main cabin. The door has molded-in, rearward-facing vision vents, whose only real purpose is to allow you to see the figure when it is inside of the vehicle. Over the door's hinge is a very cool-looking cobra emblem, which is a separately molded piece. The interior of the cabin has a few molded-in features, like what appears to be a vent grill and possibly some speakers for a comm system. The pilot's seat is made of orange plastic and has fairly little detailing, just a headrest, some ribbed seat cushioning, and a joystick, presumably for steering the vehicle. Though the fit is so tight in the cockpit, I would not recommend attempting to get your figure's hand around said joystick. There are no viewports or even a view screen for the pilot of the Buzz Board. This vehicle is driven blind. I will return to that point later. Placing your figure inside the Buzz Board is a special trick in itself. Allow me to demonstrate. Drat, I'll need a troop. Actually, this was a gift. Maybe I'll just open this regularly. So, as I was saying, the clearance for the main cabin is too small to squeeze a figure in the way one might normally attempt to, in order to fit your figure inside, you must first pose it into the sitting or fetal position. Then, with the figure laying sideways, tuck the head in first, then the feet. And finally, rotate the figure into the sitting position. To remove, reverse the procedure. Or comes equipped with two Destro anti-obstacle or DAO missiles. They do not have pegs but are held in place by wedging one of their fins into slots on the side of the vehicle. These slots are temperamental and the missiles often fall out. When purchasing on the aftermarket, make sure both missiles are included and that all four of their fins are intact. On the opposite side of the Buzz Board are what the blueprints call pounder, 50 caliber, dual-repreting machine guns. Although I am relatively sure that's a typo and they meant to say dual-repeating machine guns. My research has not found any dual 50 cal machine guns that look anything like the ones mounted on the Buzz Board. The Canon has a roughly 180 degree rotational arc but is not permanently affixed to the fuselage. It is attached over the port into which the cabin seat is pegged into. The Canon comes off fairly easily so it is another item to make sure is included with your Buzz Board when purchasing on the aftermarket. Now, let's take a look at the packaging. The front of the box has some beautiful artwork of the Buzz Board in action driven by a Cobra Viper. It appears to be coming up out of the ground and firing both its dual 50 cal machine guns and one of its DAO missiles. The Viper has opened the cockpit door presumably to see where he's going and what he's shooting at as the cabin has neither windows nor a view screen. On the left side of the box printed in bold block letters is the name of the vehicle, the Cobra Buzz Board with the caveat in parentheses informing the buyer that weapons do not shoot. In case any parents out there were concerned they were purchasing a lethal weapon for their child they can now rest easy. The top of the box has the standard GI Joe logo with the Cobra Enemy logo emblazoned over the top of the red, white and blue stripes. Beneath the GI Joe logo is the subtitle a Cobra Command Vehicle. The sides and bottom of the box repeat the name of the vehicle and the front artwork of the box. The back of the box has a photo of the vehicle and a breakdown of the parts included inside the box. It also includes a description of the vehicle with its large rotating wheel the board digs underground to cache top secret implements of destruction. The bottom corner of the box informs us that enclosed within the box are top secret blueprints for our Cobra Command files. The Cobra Buzz Board was worth one flag point and retailed for about $3.50 so roughly the same ballpark as a standard action figure. Now getting back to the operation of the Buzz Board I believe that what we have here isn't a Cobra Assault Vehicle. Without any way for the pilot to steer the Buzz Board no view screen or forward facing window and no additional wheels or thrusters with which to effect a change in direction. I believe that what we in fact have here is a Cobra Kamikaze Vehicle. It would certainly be just like Cobra to launch its soldiers at the enemy without any concern for their safety. I suspect that the machine guns and missiles are there merely to give the Cobra Pilots a false sense of security. The Buzz Board will just plow through whatever is in its path until it eventually is stopped. Hopefully at that point the pilot can emerge and continue to inflict damage upon their adversaries but if not that would hardly be of any concern to Cobra Command.  Only to pop up and surprise the enemy before taking that left-turned Albuquerque. But we all know the score. Those missiles and that machine gun would both be immediately sheared off if the Buzz Board actually did burrow under the ground. Not to mention that the cockpit would be filled with earth and the pilot suffocated through those rearward facing vents. No, the Buzz Board is Cobra's diabolical Kamikaze soldier delivery system. The Cobra Buzz Board is very decidedly on the sci-fi end of the military vehicle spectrum. As a general rule, I prefer my tech to be more grounded in reality when it comes to GI Joe. However, I usually grant Cobra more leeway in this regard. I don't really have a good rationale for that other than they're the bad guys and it's more fun to have GI Joe overcome greater odds to achieve their victories. I've always enjoyed the Buzz Board.  Essentially a giant weaponized buzz saw blade that you ride in. It looks dangerous, it sounds dangerous, and that makes for some exciting playtime. And that concludes my review of the Cobra Buzz Board. If you enjoyed it, please give this video a thumbs up on YouTube and don't forget to subscribe. There are a lot of great GI Joe toy reviews coming up that you won't want to miss. Don't forget to like hooded Cobra Commander 788 on Facebook and follow him on Twitter. You get a lot of updates there you won't find anywhere else. Tune in next time for another vintage GI Joe toy review. Get ready for the GI Joe code. Look out Cobra, better clear the road cause Joe's coming at you with an armored tow. For more firepower, Joe Hawes in the Coastal Defender the sides fold down, reveal a mobile missile station. It's right down in Tunnelrack. But Cobra's fighting back with the Bore. Mr. Bore! Riven law, Cobra Bore, gotta be trouble bore. We are real American heroes. Live the adventure of GI Joe, road towed Coastal Defender, Cobra Bore, figure so separately. Joe Joe!