 Welcome, everyone, to today's Webmaster Central Office Hour Hangouts. My name is John Mueller. I'm a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts, where everyone can join in and ask their web search, website-related questions. And we can try to find some answers, hopefully. Bunch of things were already submitted. So we can go through those during the session. But if any of you want to get started with the question, you're welcome to jump on in now. Well, everybody seems silent. I'm out there. Go for it. Great. I'll turn on my camera so it's a bit more personal. Good morning. Thank you for hosting this. Yeah, we've tried to adhere very strictly to all the structured data guidelines. I run a website that offers a comparison of courses, so education courses, e-learning, things like that. So we've migrated, basically, from using education event as our main data type to course, which was newer and felt like, oh, that's the more correct thing. We've implemented it all over the site. And then we lost all our data snippets that would list, OK, this course has a starting date on this day in that city, et cetera. We used to have them while we use education event. And now, of course, they've disappeared. And now it's been about three months and they're still not back. So I've been asking around. And then one of the replies from some supposed expert was, well, course isn't really live yet in the EU. It's launched in the US first. And I haven't seen it anywhere in the EU yet. And after doing some research, I concluded the same that I don't see any sites here offering it. So can you offer any guidance on what we could expect or how we can research it? Good question. I don't know if that rich result type is specifically launched for European sites yet. In some cases, it is the case that we launched first in the US or in some other country. And then we try to figure out what the right approach is, how much we should show, how we should handle this. And then we start to expand from there. I don't know if that's the case with course at the moment. But I can double check with the team to see if there's something that we can do to speed things up so that those who have been implementing it are shown appropriately. I tried it out, I think, a couple days ago to get some screenshots for a presentation. And I believe we show the course results in Europe, but it might be just that we don't show it from European sites yet. Right, yeah, that's a thing. Yeah, I'd love to see examples, because now I've been looking at competitors or others ranking for queries where we are ranking. And they're all still using event and education event. So we feel like the best boy in class who do the new thing and then don't get the snippets that they get. So I'm really looking for examples as well. Or we'll just migrate back and wait for a reality to set in or something. Yeah, sometimes these things take quite a bit of time. Yeah, yeah. Something where I like to have it so that we roll these out as quickly as possible worldwide. But sometimes it takes several months or even a year or so for everything to be finalized. Sometimes there are things around policy and what we're allowed to show that play into that as well, which makes it a little bit trickier. I don't know if that's the case with courses. Yeah, it makes sense. I can imagine you would also wait for webmasters to actually implement it, because otherwise you're also doing something that nobody does. Or is there a logic there in your experience? That helps a little bit in the beginning. But usually with the rollouts when we roll them out in other countries as well, it's less of an issue because the markup has been documented for quite some time already and people have been using it on and off anyway. So that's something where usually the adoption itself in specific countries is less of an issue. OK, cool. So OK, but you said you could check it out at least to see if there are examples and who knows. I can double check with the team to see if there is anything that they would find useful to speed things up. Yeah, great. Well, I appreciate it very much. Thank you very much. I look forward to that. Which country are you in? Which country is your site focusing on? Main sites in the Netherlands, secondary is Germany. And both haven't shown anything. And all competitors are still using the old stuff. So it's also very hard to see if we're doing the right thing here. That's a big problem. So those are the main markets in the UK is third, but less important. OK. Yeah, thank you. Cool, I'll check with the team on that. Cool, and then you would normally update in the community on YouTube as well? Or is there a difference? If there's something specific that I can bring back, I'll try to put it on Twitter. We can check there. But a lot of times it's just that we give feedback to the team, and then they continue working on it. We know. There's nothing special that we can tell. OK, if you happen to spot an example of site using course in the wild in the EU, and they do get snippets, I'd love to see it as well. Then I at least have some proof to my team that it might work, and it's just a matter of time. So if you happen to stumble across an example, that would be really cool. Or if you know one. So this is just totally random, because I was looking for screenshots to put into a presentation. And I think there was something like Android Developer courses or something like that, where from course era, we were showing the course-rich result type. Yeah, yeah, makes sense. Yeah, I've seen US sites get it. But you've seen it from the EU, because you're in Berlin. Yeah, I mean, I saw it here in Switzerland when I was looking for screenshots. But I don't know if there are any European sites. OK, well, I'll for sure check that to see something in the wild. OK. OK, thank you very much, Gregg. Any other questions before we get started? I'm sure they'll come over time as well. So OK, let me go through some of the questions that were submitted. There's a site out there going down the similar road that another site once did, and is building massive amount of backlinks to specific pages on their site with links in their badge code. While they're not paying for links, if you link to them without their code, they start bugging you for a link practically demanding that you link to them. There's no anchor text in the link, but they're targeting specific pages on their site. Would you consider this aggressive link building tactic to be a link scheme, which could get them penalized? It's possible that that would go down the road of being a little bit over the top. So that's definitely a possibility there. In general, what's important for us is that if you create widgets, for example, on your site and you give them to other people to put on their site and they do contain a link back to your site as the source of traffic, or the source of the data, then we recommend using no follow links for that. Just to make sure that when you're giving things out to other people that it doesn't come across as this trade of, it's like we give you the widget and in exchange you give us a followed link back to our site. As soon as it becomes an exchange where you're kind of swapping things like that, then that would be a link scheme from our point of view. So that's essentially what we would look at there. And the Web Spam team does take action on a lot of these and it's something that our algorithms also take into account as much as possible. So I wouldn't assume that this kind of setup is something that I wouldn't recommend it from a practical point of view. I wouldn't assume that these kind of links are something that will remain valuable over time. Instead, I'd really make it so that if you find people who like your widget and they really like it, then see if they'll be willing to give a normal natural link back and not kind of like force it on them through the widget itself. News website story, we automatically make links to tag pages in the text of news articles. For example, the anchor Donald Trump leads to a page with lists of news about the US president. Is there a risk that Google will consider this to be spam? No, I don't see any problem with that. These kind of tag pages are really common. That's a setup that a lot of sites have. It's something where you're essentially linking within other pages within your own website. And if you're able to provide more context for the pages that you're linking to, then that's generally a good thing. So from that point of view, I don't see any problem. The main thing I would watch out for here is that we don't generate massive amount of tag pages. So now, essentially, just the collection of tag pages and the actual content is very minimal. So use these kind of in a way to create more clear category pages, if you will, and less in the sense of automatically generating every combination of words as pages. So that's kind of the direction I would head there. Company is preparing for site migration where the old website.com is 301 redirected to newwebsite.com, so root domain change. However, can you advise if there are any SEO repercussions if we do not redirect a handful of paid digital URLs? They want to continue to drive paid traffic to various oldwebsite.com paid landing pages. While I'll set up one-to-one 301 redirects, I plan for catch-all just in case. I'm worried that Google Search Console will deny the request for a site move if we continue to drive paid traffic to some of the old website URLs. So I think, first of all, the site move request, the change of address in Search Console won't be a problem because we just look at a handful of pages to see if they're redirecting. So that kind of submission there should be no issue. The main thing I would watch out for here is really that you're moving all of the pages from the old domain to the new domain. I'm not completely sure how the setup was that you're looking at there. If you're looking to keep some pages on the old domain and drive traffic to them, or if you're just driving traffic to the old domain URLs and then it redirects to the new domain URLs. If you're keeping pages on the old domain that are not redirecting, then that's something that will confuse our systems because when we crawl and index your website and we run across those pages, then we start to question whether or not this is actually a site move. And then it essentially goes from being a move from one domain to another, where if we can just like transfer everything to the new domain, it becomes a situation where you're splitting a domain. You're taking one domain, you're keeping some things there and moving some things somewhere else. And from our point of view, that becomes a lot harder to process. That essentially means we have to repost both of these domains and see like, well, what is this new website and what is on this other website that we already know about and how does the content kind of interact with itself there? So that's something where if you're looking to do a site migration and you want to keep some URLs on the old website, then that's something where you really need to be aware that this will take a lot longer to be processed than if you really moved everything over to the new domain. And if it's not the case that you're keeping URLs on the old domain, but rather you're just driving traffic to the old URLs and they're being redirected to the new URLs, then that's totally non-issue. People come and visit the old domain from various sources if they get redirected to the new one, then we see that's a part of the site move. That's absolutely no problem. It's really just like keeping things on the old domain. That's something which I would try to discourage as much as possible. Does Google still respect the meta robots unavailable after? Yes, yes we do. So the unavailable after is a way of specifying a date when a page is no longer available. And we do use that. We even made some, I believe some changes there fairly recently with regards to the date format that we support. So that's something that we definitely still use. The thing to keep in mind here is you're essentially telling us this page will not be available then, but we need to make sure that we're not just removing pages from the index that are actually still available. So it's very likely that our systems will go and re-crawl that page around that date that you specify and watch out for no index or watch out for a 404 which would tell us, well, actually it is no longer there. So make sure you're backing up anything with an unavailable after tag together with actual guidance to tell us that this page is really not available anymore. In the HTML source code of an internal page, canonical tag is mentioned of the homepage and while doing inspect element on the same page I found the canonical is self-referential internal link and the URL inspection tools sometimes shows user declared canonical as self-referential URL and sometimes the homepage canonical. So which canonical URL will Google consider? So it sounds like you have a page that is not the homepage and it has a rel canonical pointing to the homepage and sometimes it doesn't have that rel canonical page. That's something which would confuse our systems because sometimes you're telling us to use the homepage instead of that page and sometimes you're telling us to use that page itself. So as much as possible, I'd recommend making sure that the rel canonical stays consistent and matches the URL that you do want to have indexed. If this is a case of a JavaScript page where you're using JavaScript to change the rel canonical then that's something where I would recommend making sure that the static HTML page that you deliver doesn't have any rel canonical on it so that you're not changing the rel canonical but rather that you're adding it. If you use JavaScript to add a rel canonical to a page then that's perfectly fine. We can pick that up after rendering. We can process that and use that. However, if you're using JavaScript to change the rel canonical from one URL to another then you're potentially in that situation where depending on if we process JavaScript for that page or not, you're giving us very different information. So that's something I would try to avoid. So ideally, if this is a JavaScript site within the static HTML page don't have a rel canonical on there and then with JavaScript add a rel canonical to that. There are some similar cases where you also need to watch out for this. For example, if you have a no index on a page on a static HTML page and then you use JavaScript to remove that no index then depending on what we process we might see a no index or you might not see a no index there and that can get confusing and especially if JavaScript removes a no index then it's very possible that we will take the page see that there's a no index and say, oh, we don't need to do any rendering here and we'll just drop it. So if you're using JavaScript with regards to the no index and I would only use it to add a no index so that it drops out and not remove a no index. Will you tell me about the Google BERT update? Which types of work can I do on SEO according to the BERT algorithms? So this is I guess a fairly broad question. I would primarily recommend taking a look at the blog posts that we did around this particular change. In particular, what we're trying to do with these changes is to better understand text which on the one hand means better understanding the questions or the queries that people send us and on the other hand, better understanding the text on a page. And the queries are not really something that you can influence that much as an SEO. The text on a page is something that you can influence and our recommendation there is essentially to write naturally. So it seems kind of obvious but a lot of these algorithms try to understand natural text and they try to better understand like what topics is this page about? What special attributes do we need to watch out for? And that would allow us to better match the query that someone is asking us with your specific page. So if anything, there's anything that you can do to kind of optimize for BERT, it's essentially to make sure that your pages have natural text on them that they're not written in a way that kind of like a normal human would be able to understand. So instead of like stuffing keywords as much as possible kind of write naturally. In terms of site links, what influences, which links are picked up to show, the order of the navigational internal links, breadcrumb markup. So site links are the kind of sub links that we sometimes show in the search results where if you're searching for something, we show one page and then you have like smaller links to other parts of that website shown there. Essentially site links are normal search results from our point of view, but we try to kind of figure out when we can pull those out and something that really helps us to understand when we can pull those out is if you have a really clear site structure and if you use clear headings and titles on pages so that we understand what these pages are really about. And then with a real clear site structure, we can kind of understand that if someone is looking at the homepage or looking at one specific page within your website, then these are kind of like the four or five related pages on your website that are really commonly used and that might make sense for this particular user. So in terms of that, that's kind of the direction that we would go there. And I believe we have that documented in our help center as well that for site links, things like the navigation, clear internal structure do make sense. What happens for brand sites with products that are only sold via third parties, there's no price that we can add as the price varies, for example. For example, a brewer, the price of a pint of beer varies by location, what would you suggest? So this one I think is kind of obvious in the sense that if you have products and you don't have any prices that you can show, then you can't mark up any prices. And what practically happens here is you can use the product structure data markup for these kinds of pages, but for us to be able to display the product structure data markup, I believe we need either reviews or a price. And if you have neither reviews or price on your pages, then we will just not show that as a product rich result type. So from that point of view, you can continue to use that structure data markup, we just won't show it. And with regards to, well, what can you do? There's not really a workaround for that in the sense that if you don't have a price and you don't have reviews, then you don't have those things. So that's something we just wouldn't show. From a ranking point of view, this is not really a problem. It's really just how that search result is shown in the search results pages. I see a lot of WordPress sites that have different schema on their desktop, mobile and AMP sites. For example, I'm looking at one that has website on the desktop pages, organization and blog posting on the mobile pages and hcard and news article on their AMP pages. Oof, that sounds complicated. Is it safe to assume that Google is using the schema that's on the version of the site that's being crawled as per search console? For example, if mobile crawling is indicated, that's a schema that it's using. Yes, for the most part. So within the desktop and mobile pages, we would pick whatever version we're currently crawling. If we switch to mobile first indexing for the site, then we would not use the desktop version at all for indexing, and that includes the structured app. So that's kind of the easy part. For AMP, it's a little bit different in that for some AMP features, certain structured data types are required on the AMP pages. So we take that into account for those AMP pages when they're kind of eligible to be shown for specific AMP features. So that's kind of the complicated part there. In general, I would strongly recommend making sure that you're consistent with your structured data, that you don't have different types on different types of pages across your website. It's not so much that your website will be seen as low quality or be bad if you do this, but rather it's really just from a practical point of view. If you have different types, you don't know what you're getting out of it. So if there's a way for you to kind of double-check the structured data types you have on the different types of pages and to be consistent across those pages, then it's something where we can look at any of these pages and we get all of the information that we need, and then we're definitely going to be happy. Whereas if the information depends on the type of page that we're looking at at the moment, then you can't really rely on us being able to take your website into account on its whole. So it makes it harder for you to diagnose like why isn't Google showing this specific structured data type? And then you're like, well, on this specific variation of my page, I have it, then it's very possible that maybe we're not looking at that variation of the page. Or especially if you have different variations in different places, sometimes the combination is what makes it important for us. And if we don't see that combination clear, then we can't take that into account. So that's something which purely from a practical point of view, I'd recommend trying to focus on. It's really hard for us to flag these kinds of issues in Search Console because when we just look at one type of page, we don't know what we're missing because we don't actually look at the other types of pages. So that's something where potentially there are third party tools that will help you to crawl your website and pull out the different structured data types. And maybe there's a trick to flag these kind of inconsistencies across variations of the same page. If anyone knows any tricks to do that, it'd be cool to hear from you. Maybe that's something we can share as well. My client site is still being indexed by regular Googlebot and not switched to mobile first indexing. And also this site is experiencing great traffic loss now. What could be the reason? Or could this be the reason the site was migrated to the current domain and the old domain was switched to mobile first indexing. The migration was in August and the site is mobile friendly. So I think there are a few things here that are kind of combined. On the one hand, mobile friendly doesn't mean that a site is suitable for mobile first indexing. Mobile friendly is kind of that mobile users are able to use that site without any hindrance. And mobile first indexing requires that we actually are able to index the content in an equivalent way across desktop and mobile. So for example, a site could be mobile friendly if it just has very minimal content, but it might not be ready for mobile first indexing if that mobile version doesn't match what we have indexed for the desktop version. So that's kind of one thing to keep in mind. Mobile friendly is different from mobile first indexing. In general, with regards to traffic loss, it's not the case that if a site is still in the desktop index that it would get less traffic. So the ideal situation with mobile first indexing is we switch sites over to mobile first indexing when we believe they're ready. And when we believe they're ready is essentially a simplified form of when we think there is no change in the traffic to the site when we use the mobile version for indexing. So in that sense, you wouldn't see a drop in traffic when we switch to mobile first indexing or if we don't switch to mobile first indexing. If you are seeing a drop in traffic, then that would be due to any number of other reasons. Could be from the site itself, or it could be changes in our algorithms, it could be changes in user behavior and that they're looking for different things now. It could be, that would be completely separate from mobile first indexing. When you use a site query for the old domain, Google still shows a lot of pages. There are only 50 pages in Search Console for the old site, mostly PDFs, but the weird thing is Google shows a search result of the new site when you use a site query. So that part is completely normal. That's something that confuses, especially SEOs, I think, and it's something that we tend to do more for normal users in the sense that, so what is practically happening here is we understand that the site has moved from one domain to another, and we've essentially moved all of the URLs from indexing to the new domain. However, we still understand that connection between the old domain and the new one, so if you explicitly ask us for the old domain, then we'll say, well, we have some pages that we know are associated with this old domain, we'll show them to you in the search results. So with a site query, you often see that. Often you also see that if you just search for the domain name itself. And from a practical point of view, this is not a sign of anything going wrong. This is essentially just us saying, well, we know there's this connection here and these are some of the old URLs. And if you look at the Cache page for the pages that we're showing, you'll see that we're actually showing the pages from the new domain. So we're essentially showing something that is no longer indexed like that, but because we believe the user is explicitly looking for that, we show it to the user. So that generally wouldn't be a sign of anything problematic there. You mentioned the URLs here as well, so I can double check that. I took a quick look before the session and I didn't see anything that kind of popped out. So my guess is this change in traffic that you're seeing is essentially a natural change in traffic, not something that is due to kind of the site move or due to anything around mobile first indexing. It's something where I try to focus more on the actual content itself and try to figure out like, what could you be doing differently with regards to the content, with regards to maybe some of the different changes that we've talked about over the past year or so. John, hello. Thanks, it was my question. I just wanted to clarify one thing, do sites which were switched to mobile first index and have some benefits in comparison with my site? Not really, not really. So the benefit is mostly for us that we're able to index the version of the site that users mostly would see because most users use mobile devices nowadays. So it's more that we're consistent, but it's not that there is any kind of ranking bonus for being in mobile first indexing. Okay, also I wanted to say that this site has more than 80% of mobile users. So I don't see the reason why Google still indexing is still indexing with desktop user agent. I could imagine that if you did a site move, like late last year, like you mentioned there, that our systems are just kind of being on the cautious side. So that's something where I know the mobile first indexing team tries to focus on batches of sites and move them over in groups. And it might be that they're just focusing on maybe different kind of site at the moment. And then once they rerun everything for all kinds of websites, then that will shift over. But I wouldn't worry that this is a sign that you're doing anything wrong with regards to mobile first indexing. Okay, and is it okay that Google shows it shows in results the name of the new site when you search for the old site in snippet? I mean, okay. I think that's normal because we understand this connection, but we try to show the old URL. So usually if you click on the cache page there, you will also see actually it's the new URL that's being indexed, not the old one. Okay, thank you. Sure. I have a four sub-directory website that serves four different regions. For example, example.com slash in slash ca slash us slash slash us slash GB. When I inspect element for example.com slash ca, it shows me the inspected pages index. I can also see the page in the Google search results, but the cache of this page is shown as example.com slash us. Also when I do a site query for example.com slash ca, the first result is slash us. There are no IP redirect and canonical tag issues, hreflang is implemented. What could be the cause here? So what is probably happening, I don't see the actual pages here, it's hard to say, but what's probably happening is that we're seeing these different English versions as being substantially similar in the sense that for our systems, it's just as useful to just index one of these pages and just keep that. Because if the English version is the same across all of these different country versions, then it doesn't make much sense for us to kind of index the same thing four different times. So with indexing, we'll pick one of these versions. And if you have hreflang annotations on these pages, then when we show that version in the search results, we'll try to match that to the hreflang version that you have specified. So user in Canada, if they search for something on your website, they would tend to see the Canadian URL and the user in the UK would see the UK URL. However, the index version, the cash version would be one of those pages. So for the most part, that's usually less of a problem. It's just confusing in the sense that as an SEO, when you're double checking, which pages are actually indexed and suddenly it feels like not all of these pages are indexed properly. The other part that is definitely confusing is the way that we would show this in the search result, not in the search console. On the one hand, in the performance report, in the performance report, we would report on the canonical URL. So we would just report on whichever one of these we would choose as a canonical. We would not show these different country versions independently. You can, however, look at the country breakdown in the search performance report to see which kinds of users are going to that page. And the other place where this also shows up as being confusing is the index coverage report in search console because we would count this as one page being indexed, which kind of it is. It's like that one version that we pick as a canonical, that's the one that's indexed and the three other versions of the same content, they would be seen as not indexed or probably flagged in search console as, I don't know, another URL was chosen as canonical, one of those categories. And again, it's not a sign of a problem. It's not a sign that these pages would rank worse. It's really just like it's confusing the way that it's reported in search console. And as an SEO, if you're drilling into those details, that can be confusing. So what I would recommend doing there to double check that it's actually working is to just search for something generic for these particular pages and to watch out that these URLs are actually changing in the search results pages. The one place where I would be kind of careful with this if you're seeing it happen and try to find a way to fix that or change that is if you have specific prices on these pages and you have different prices across the different country versions, and then you don't want to have kind of the wrong price shown in the search results page compared to what a user would see when they go to that page directly. And if you're seeing something like that, then my general recommendation would be to make sure that these pages are not really identical apart from the price. So that the price on these pages is not the only differentiation, but rather that you really have something kind of clear on this page that tells us this is a different page from this other page that you have which otherwise isn't the same language. And just to be really clear, this kind of situation can be really confusing and it's not something that I'd say is trivial to kind of debug and look into. So if you feel kind of overwhelmed with this and I'd definitely go to maybe the Webmaster Help Forum and try to get some help there or try to find a consultant that can help you who has more experience with international websites because it does take a little bit of looking into the weird edge cases to understand what's happening. And it is sometimes really helpful to have someone saying, well, actually this is confusing and it's fine the way it is. Like you have it set up properly and it's working pretty much the way that it is. You just can't measure it the way that you would like to measure it. I'm getting mixed results for the Google Event card which displays above the search results for something like artist plus tour. Adding structured data to the performance website has mixed results. And in one case removing a broken plugin that was generating incorrect events, structured data and then using HTML only seemed to improve the situation. My research indicates that many venues and most ticket outlets are hosting incomplete or incorrect structured data. So my questions are, is the Google Event card structured data aware? Yes, we do use structured data for the events that we show in the search results. And I believe that's even the primary source of data there. So that's something like yes, yes, we do use that. Which type of entity if any would be the most authoritative for hosting structured data events scripts? My understanding is we don't really have that difference between in terms of authority across these different website types. I'm sure our algorithms try to figure out which ones are the most relevant ones for specific structured data types like events where you have kind of different websites hosting different pieces of the puzzle. However, what is really important, especially for events where you have one essentially entity that is described on many different websites, the thing that's really important for us is to be able to consolidate all of the information that we have there. And sometimes what happens is we have some pieces of information here, some pieces of information here, we can understand they're about the same entity like that one concert in this one location by this one artist. And we'll try to take that information and combine it and make one kind of entity out of it. Because as a user, when you're searching for concerts you don't want all of these different entities listed separately, you want one entry for this concert that you want to go to or that you want to present to people. So it's not so much that we only pick the data from one source and only show it there, but rather we have to consolidate it and understand which parts of the puzzle if you will come from which different websites. And then as a kind of a last step almost like figure out which of the URLs to link to when someone clicks on that type of structured data result. So it's not so much that you need to do everything with your structured data on your pages, but rather you need to make sure that it's consistent enough that we can match it to the primary entity that's involved there. John, a quick question regarding this. So what do you do or what can one do in cases where you're generally using maybe some providers or there's simply not a lot of information regarding how to get into certain rich snippets maybe like, I don't know if this is a good example movie tickets or something like that. I know that Google, especially in the US uses certain providers for that kind of information, but in other countries those kind of rich snippets don't show at all, regardless whether you have any structured data on your website or anything like that. Maybe you're a cinema somewhere in Romania, let's say. So that kind of decision whether the rich snippets show or not is entirely related to the fact that Google has those providers or can webmasters do anything to kind of help speed that, speed the showing up. Yeah, I think for most features we do rely on structured data, but there's very few that rely quite a bit on feeds from trusted sources and especially movies. That's one of those things where a lot of the movie providers work together with, I don't know, some local companies that kind of aggregate all of the movie feeds and we consume those movie feeds directly. So that's something where we try to focus on the information that we can really trust and show that appropriately in the search results. So if we're not picking up individual movie theaters I double check to see if there's kind of like this regional place where all of the feeds come together and make sure that you're included there as well. And if that's not the case, then that's something where you can also come to us and say like, hey, I have this information in this feed. Can you consume that from our side as well? So it could be that for some countries we don't really have a clear provider or we have spotty coverage. So for movies that's kind of a bit unique. For pretty much everything else we try to just pick up the structured data that we pick up on the pages. And that's something where it's often also less critical if it's 100% correct. With events, for example, we can kind of figure out where things are slightly incorrect because we have different sources of data for things like reviews on a page or prices. It's something, well, if it's not correct, it's like you're telling us and we're pointing at your pages. It's kind of like your problem if it's not correct and not our problem, but with movies people expect that the showtimes and the information that you have is correct. And they're usually not that many sources of information. Right, and I think that's the same for, I'm thinking of another example now like sports events and things like that. I know again in the US there are a lot of features and if it's regarding teams, playing scores, things like that, I assume that's also one case where you're using certain trusted teams. I believe so. So especially things like the sports results which have to come in fairly quickly, that's something where I believe we also use special feeds. So in these cases, outside of the US, is there any way, certain webmasters have this kind of verifiable trusted information? Can they contact Google in any way to, is there a program like for working with these providers or selecting these providers? Usually that goes through the business development so I believe there's some general contact page there or if you have a local Google presence, in most countries we have some sales offices and things like that and then often you can go do that. Okay, cool. Okay, let me see if there's something that we can answer very quickly and then otherwise we can switch to more questions for you all. After configuring the pages to correctly send structured data to Google, how long does it take for them to show up? Is it 12 weeks? So it's definitely not 12 weeks. In many cases, we can show the structured data as quickly as we can index that page. So if we're willing to show that structured data from your website and you've provided it in a valid way, then we can pick that up and show that essentially the next time that we crawl and index that page. Can we add jumping link into internal pages? Will it add kind of like past page rank and help improve the ranking? So jump links within internal pages are essentially where you're linking from one part of the page to another part of that same page and from our point of view, that's not something where we need to pass any signals because you're linking between the same page. It's not that that page suddenly has more page rank because you're linking to yourself but rather what you're doing is giving us a little bit of information about the structure of the page and that can sometimes be helpful in the sense that when we show something in the search results, we know this is a really long page and we have a kind of a link to a part of the page that is particularly relevant to a user's query. Then sometimes we can show that kind of as a jump link in the search results directly so that you can jump specifically to that part of the page. What helps us there is on the one hand to have these links between the parts of the page. On the other hand also to have clear headings and subheadings on that page so that we know this part of that long page is actually very relevant to the user and here's a way to get there directly. Okay, and a bunch of backline questions. Let's see, many times hackers hacked into search console to change the targeting country. Can I submit the hacker email address so that Google can blacklist them forever? So I guess there are a few things here. On the one hand, we do try to understand which email addresses are problematic and we have different ways of dealing with that. I don't think we would just blacklist them from search console forever. The other thing is that if people are able to verify your site in search console with their own account, then it's not the case that they hacked into search console or into your search console account but rather they hacked into your website and they're able to make changes on your website itself which means they're able to add like a verification tag to your website which would then allow them to go into search console. So instead of thinking about just how you can lock down your Google account so that other people can't get into search console, you need to double check to make sure how people were able to get into your website and what you can do to lock down your website, not your Google account but your website itself so that people can't make changes there because ultimately the goal of a hacker is not or I'm guessing in this case, I can't speak for all hackers of course but the goal is not just to go into search console and then change the targeting country and then it's like ha ha ha I'm confused you but rather they're probably placing pages on your website or they're placing specific links on your website to add their more malicious content or their kind of monetization methods. So that's something where the setting in search console is less of a thing that they actually care about. It's kind of like a side effect but what they do care about is like all of these other changes that are happening on your website. So if you see people kind of verify your site in search console and you think they're hackers and they're doing something crazy then I would not worry about search console primarily but rather think about your website and how they were able to get into your website, fix all of those issues on the website first and then you can also make sure of course that things like search console are cleaned up as well. Okay. We have a few minutes left. If any of you want to jump in with the last question feel free to do that. I also seem to have a little bit more time left so we can continue kind of off the record afterwards as well if any of you want to stick around. John, I've got a very specific question just regarding something we spoke about on the 13th of December. It's regarding a very specific site so I don't know if we would wait until after the hangout. I can stick around. Maybe we can take a look at that afterwards, yeah. Okay, I'll stick around, thanks. Hi, John. I have a quick question about the search link site box. And I know that in the past the structured data markup for the site link search box doesn't support subfolders or subdomain. Is it like this right now? I believe that's still the case, yes. Okay, so it's not possible to target the multi-language website that are structured with subfolders. Exactly, yeah. The site link search box, I believe, is on a per-domain basis so you specify one site link search box for the whole domain. In some cases that's a little bit suboptimal. Sometimes you can do things like add a banner to that page to make it a little bit more useful for your users. Okay, thank you. Yes, we can take a break here. Thank you all for joining in. Thanks for all of the questions that were submitted. I'll set up the next batch of hangouts probably later today. And if there's anything that's missing that you need to get answered until then, of course feel free to jump in on Twitter or join us in the Webmaster Help forums where a bunch of experts are able to help as well. All right, so with that, I wish you all a great weekend and hopefully see you next time.