 What happens? 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 are these Office Hours Hangouts for webmasters and publishers, people with web search problems, or questions at least. As always, it looks like a whole bunch of questions were submitted. But if any of you who are live in here want to get started with the first question, feel free to jump on it. Yes, I have a question related to the AMP. I recently noticed that there's arrows pops up at the new beta search console. The AMP is only popped up at October 7. The arrows is related to M analytics extension, and JSON script request is not updated. But I do check on the AMP validation, and it doesn't say any of the arrows. So let me pass the question into the chat. I'm not sure this is a bug within the beta hours, because using the validation on Google, they said the AMP is correct. And it pops up like 200 or even 300 of the AMP arrows. OK, and these are the things that you haven't changed in that time? Or how did it not change? By using the WordPress and then using the plugin, and then I do check that the plugin isn't updated. But it suddenly pops up at October 7, but I beta search from there. OK, if you can drop me a URL in the chat, maybe, or send it to me, then I can take a look at that, too. One thing I am aware of at the moment is that in Search Console, some of the reports are delayed with the data, because we have some backlog with some of the pipelines. I'll probably do a tweet about that later today, once I have all of the details. But that's one of the things that might be worth keeping in mind there. So I guess in your case, it probably wouldn't be from that, because if you haven't made any changes in that time, then that should be kind of a similar state. But if you had fixed it since that time, then that might be the reason why you wouldn't see an improvement there. OK, so sorry, I have a second question. Related to mobile-first indexing, I notice that I haven't received any mobile-first indexing already on our webmaster notice. Is that means that my mobile site isn't good enough for mobile-first indexing? Not good enough. I don't think all the mobile pages or testing is over. Yeah, I don't think you have to worry about them not being good enough yet. That's something that we're trying to roll it out to a bunch of sites over time. And a lot of sites we've already managed to roll it out to. But it doesn't mean that your site is bad for mobile-first indexing if you haven't received that. So we try to take into account different things to make sure that we shift the sites over that makes sense. Let's shift over now. So if it didn't rolling out as mobile, so if it means that it's still desktop indexing? Yes. OK, got it. Thank you. Hi, John, do you mind if I jump in here for the next one? Sure, go for it. It's Chris, your favorite from Android headlines. I just wanted to kind of ask you a few questions. As you know, we had our large traffic drop-off in February and about a 60% drop-off in organic traffic and rankings. And I sent you some new detailed information since our last Hangout. And I sent you a lot of stuff. Didn't hear back from you. Not sure. I know a lot of stuff's been going on. If you've had any chance to look at with the engineer team. I have a few follow-up stuff to there, but I'd love to hear your feedback first. Yeah, we've been talking about this with the engineers to kind of see what we can do there, if things are working as expected from their point of view or not. In general, the consensus I've been seeing so far is that this is essentially a normal ranking change that has happened over time and that there's nothing unique that's happening here. It is, however, something where your examples have been extremely helpful, and especially things where you've been showing how the content that you put up on your site that's being referred to from other sites might not be seeing as much visibility as it could. So that's something where those examples have been extremely useful. One of the examples that you had there was something, I think one of the queries that you provided was something, something leaks. One of the things that one of the quality engineers brought up is that you don't actually have the word leaks on your content. So that's something where for that specific case, they were saying, well, we don't really know if this is exactly the right one that people are looking for. So that might be something to keep in mind, but that's something that I imagine for a lot of your content you're already watching out for that you actually mentioned the things that you want to really rank for. And we're definitely watching that stuff and changing up our wording of stuff. We don't want to be a clickbait type of site. So we try and definitely write conservative, but descriptive titles because there's too many sites looking for clicks. The problem where we have at this point is losing the ranking and traffic and so on like that and not really having a pinpoint when you're saying it's just a natural algorithm update kind of leaves us in the dark and with a needle in a haystack trying to find out how we fix this. Doesn't seem like as a Google partner for close to nine years, whether we live or die doesn't really matter. And I realize that every site is important and there's only so much you can do, but without some direction as to where to go, especially with you telling us everything looks fine technically, everything is copacetic. It's just an algorithm change. And then yet I see my competitors, they're not losing rankings. They're not losing organic traffic, but we are. So it feels like we've been picked on and yet we don't have an answer to it. And I think I alluded to kind of some of the SEO experts that we've worked with that are scratching their heads at the same time. And these are pretty well-known guys. I don't want a name drop, but I did explain who they were. And you know those guys as well-respected guys and even them, they're like, well, what can we do here? Especially after your comments. So we feel, whoa, where do we go next, John? Because I mean, you've given us, you've looked at it, but it haven't really said, this is where you should go, that's where you should go, or anything. Like there's no answer to it. So I mean, I understand I'm not looking for the magical answer or advantage, but it seems like you guys don't even have an answer other than algorithm change, which I'm the only one affected by it in my class. I mean, it's something where these are quality algorithms that have been changing for quite some time. So these are not so, I don't know, how can I put it? It's something that's really not specific to your site. It's not something where we're just saying, well, this particular site is something that we shouldn't be showing that much. It's really kind of a cross-bored quality changes that we've been making since, like in this case, since February. So that's something where there's no problem. We must have gotten single delt for some reason, though, right? I think these algorithms tend not to single things out. So that's why I know if you're in that situation, it's always tricky because the ones that you see are the ones that are still visible, that are otherwise out there. So it always comes across as something like this is specific to my site, not a general thing. If it was your site, John, what would you do? Like in all honesty, what would you do? Because you know my case very well. So I know if this is how you're making your bread and butter, what would be your next steps? Oh my gosh, that's a good question. Yeah. So I would definitely continue to bring these issues up. So I think that's the first thing. But I don't want to keep bugging you, John. That's the problem, right? It's something where when we see these issues come up again and again, it kind of continues to push the discussion internally. So I think that's always useful because it's also a sign that there are things that we could be improved. And there are always things that we could improve. What about we have like 3.5 million social media followers? Should we put a campaign together, bring some more media attention to the issues and blog posts? I mean, that's not the way I like to go about things, but you're talking about pushing the conversation. And is that a form of pushing the conversation that you would suggest? Probably not. I don't think that would really help a lot there. If you're escalating it to, and I'm not saying going above your head because you do a fine job, but there's many people in Google that we can address and talk to, but I felt you're the best for it, is that another route that we should go? I don't think that would change anything. Essentially, the high ranking folks, they are talking about your issue. So it's already with the right folks. Well, I should just show up every week on your Hangout. And I don't want to do that because I know there's lots of people that have lots of issues, and I don't want to take time away from them as well either. I mean, one thing that I would do is try to think about what could be done from a quality point of view to really significantly take it to the next level. Because these kind of changes, when they happen over time like this, it's really a matter of trying to recognize equality over all of the website and how relevant it is for these kind of user queries. So one thing I always recommend is going through the old 23 Questions blog post by Amit Sengal, which is probably like four or five years old now. The Quality Raiders Guide has a lot of really good information in there. Some of the SEOs you're talking with probably have gone through that as well. That's something where I would also try to get objective feedback from people who are not really associated with your website to see someone completely new when they come to your website looking for the specific topic that you want to focus on. How do they react? Is this something where they say, this is a trustworthy site that I want to go to, that I would recommend to others? Or do they come in and say, well, I don't know. There is a lot of stuff happening here. Which of this information is really trustworthy? Which of this information is, I don't know, affiliate type information? I don't know if that's something that you do. But I have. I definitely have, especially objectively, and took in the criticism and all. We are relaunching a new site. It was something that was in the plan I explained to you, SBA. And I really would love if I could pass that on to you next week. And I'd love if I could get some direct feedback to you. I don't know if you're willing to pass me your email or not somewhere in the chat or you have my email just so I'm not consuming time on air so you guys could give me proper feedback. I don't want to be the guy that shows up every week with the same question. I dropped my email into the chat. OK, thank you very much, John. And I appreciate it. And I'll let you get on with the next question, sir. All right, thanks a lot. Hi, John. Hi. Hi, are you able to come in? Go ahead. Hi. So basically, we're an online mirror store. And we're currently ranking number 52 for keyword mirrors. However, the page that's ranked in the search results is the wrong page. We'd ideally like our home page to be ranked. And for these keywords, we think it's the most relevant. However, Google's currently ranking a page which we call all mirrors, which is basically every product on our website. Now, we've tried various techniques to get the home page to rank and kind of devalue the current page that's ranking. However, nothing's working. And so we just wonder if you could offer any advice. Hard to say without looking at the site specifically. Yeah. One thing that I've sometimes seen with some e-commerce sites is that the home pages are sometimes just overly stuffed with the same keywords over and over again. And that's something where we might say, well, this home page is so keyword stuffed, we don't know how to trust it. We'd rather pick something else from this website. So that might be something that could be happening there. Yeah, the thing we're finding difficult is the page that's ranking, which is all mirrors, has barely any content on that. It's just literally a kind of a list of every product on our website with just kind of one headline title, all mirrors. Whereas we fully optimize the home page with all your kind of advice and things. And so we're just so confused as to what to do. Yeah, I could imagine that maybe you over-optimized the home page. So not that there is an over-optimization penalty or anything like that, but I could imagine that maybe our algorithms are looking at the home page and saying there's just so much keyword stuffing on the term mirrors or something like that, that we need to be more careful here. So without knowing your website, so I don't know if this is really the case. But are we able to email you the website? Do you can look at the case specifically? What I'd recommend is maybe posting in the Webmaster Help Forum with the website, and feel free to drop the link of your forum thread into the Google Plus post for the Hangout. OK. And then I can take a look there. But that's something that I see every now and then that sites kind of over-optimize their home page with regards to these keywords and really ramping it a step back and saying, OK, we're not going to go completely overboard with the term mirrors and instead provide some more information or general information on the home page. Sometimes that has a really positive effect. The website about 67 years ago as well, had a manual penalty on the home page for over-optimization kind of bad links and things like that, that we would buy into the keyword mirrors. Now, we were removed. And like I said, that was six years ago. Do you think that may be having an impact now? No, no. If the manual action is removed, then that's out of the question. OK. All right, thanks very much. Can I ask a question? Sure. Hi, John. So I'm still having problems with the 302 hijack. And what I'm seeing now is that some keyword tools are showing the ranking for my original domain name and some of the other keyword tools are showing the hijacker. So basically, depending on the vendor, we are interchangeably, it's me or the hijacker. What does it mean? I mean, is that some kind of conflicting signal going to Google or they just have different kind of sources to get that information? And the other thing is that I actually spent a lot of time on that subject and I had contact everyone possible. I'm a technical ICO myself from years and nobody can resolve that situation. I even look up to your website and your last post was just about three or two hijack. But it was some sort of old things going on there. And it didn't actually help me with the problem. And I'm really banging my hand on the wall. Just cannot resolve that situation. Although I tried everything, contacted everyone, nobody can resolve that situation. Can I post you the links just to see how these things are changing? Maybe think about if there is some kind of still vulnerability in the Google algorithm that is exploitable still in 2018. And despite what Matt could say that the situation is still resolved, it's still a problem that Google didn't resolve fully at 100%. So I'm giving you the original. Or maybe you can send it by email. OK, OK, I'll send you the email chat. So I can take a look at that afterwards, because it's like looking at these live is really tricky. OK, I think it really helps you. And the last question, because the hosting had a way that if you have a VPS with an unique IP, you can resolve the website through the IP. Is that some sort of vulnerability that can be exploited in order to point that IP to another domain name? No, that shouldn't be. So that's something usually you could set it up so that it redirects to your domain name. I did it already. Yeah, but a lot of servers are set up like that. And it's really not a problem. OK, thank you. OK, can I go next, please? Try it. OK, so I have a website with a list of real estate agents. And I'm going to show you what the problem is. So if you can see the structured data testing, so let me know. OK. OK, so as you can see, there are two different implementations for the markup here. This is done with a different language by a developer a long time ago. And it only marks up the reviews on the page. And as you can see, there are errors for every single review saying there's no aggregate rating and a couple of other errors all the way at the end, which says there's no image and name. So what I did in this one is I marked up all of those things that I'm missing over here. But is it OK to have two different implementations for it? And the reason is that there's no implementations. This one is in JSON-LD, in depth with GTM. And this one is down with a language I don't know which one it is. But is it OK to have two different implementations like this, or will Google just pick one? I think what would happen in this particular case is that we would see them separately, like in the structured data testing tool here. And if none of them are complete, then we would not use them. So if you have some in the top and some in the bottom, then we wouldn't be able to combine them because we wouldn't see that they were actually the same thing. OK, given that, how exactly can I mark up reviews using JSON-LD and GTM? Is that custom JavaScript that needed to do this? Because I cannot find any online resource on how to do that. I think that'll be tricky. I assume there's probably nothing specifically written up for that particular use case. So you probably need to try to work that out yourself. One thing you could do is, perhaps, post in the Webmaster Help Forum about that. Yeah, I thought that. The only thing that I got a response for was when there's a static number of reviews, like if there's three reviews, then how to mark those up. But obviously, some pages are going to have three. Some are going to have 20. Some are going to have 0. And this number is going to be changing over time. And no one on the forum can tell me how to do that. Now, that's usually something you'd have to do on the server side. So that's not something that you could put a static markup on the pages. You'd really have to get that implemented by your developers. There's also the data highlighter tool in Search Console that can help with things like this. But I assume for this particular type of use case, it wouldn't work because it's too general. And not specific for that kind of setup. So can this not be done with JSON-LD at all? Or is it that is JSON-LD plus GTM? It can definitely be done with JSON-LD. But maybe the hard part is really the Google Tag Manager combination there. OK. And if it's just with JSON-LD, is there any literature that I can look at on how to put that and where to put that in our code? Because I need something to give our developer. I have to give him some description. Yeah. Probably just the developer documentation that we have on the markup. But it's something that's where we document kind of how to mark things up in general. And it wouldn't be really specific to exactly that kind of use case. So that's something where the developer will need to see, well, this is the markup that Google needs. And these are the structures that I have in my code. And this is kind of where I include all of the different reviews. So I need to take this markup and include it in this loop that's generating the reviews on the page. OK. So in that case, let's say I can't figure out a solution to have an individual review markup. But we have all of the other things and the aggregating and the language and so on. Is this enough? Or do you recommend that we find a way to mark up all of the reviews as well? It depends on what you want to achieve. So some types of rich results that we show in the search results have lower requirements. So it's easier for us to pick things out. And other types of rich results that we show in the search results need very specific things. So for example, if it's just a matter of having the aggregate review, like the star ratings and the number of ratings there, then maybe that's a lot easier to do. If it's a matter of setting up a carousel that we would show in the rich results, then maybe that's a bit trickier. But what I would generally do is think about which kind of ways that you want this content to be shown in search and check in the developer documentation what the requirements for that specific use case are. So instead of trying to solve everything, really think about what is the one thing that you want to have visible in search and what is the minimum that you would need to do to achieve that. OK, sure. That's helpful. And a final question is, for things like note language, for example, there are multiple languages, but the number of languages can change age into age into some with no English, some no English, and Mandarin, for example. How can we have that within the search? I don't know. I believe these kind of fields can be sent as a raise. So you can send a number of different languages there. But probably with that specific situation, we wouldn't use that language at all in our search results anyway, so it's not something that would be critical. OK, so you're saying, well, it doesn't matter because we wouldn't show it? Yeah, yeah. So there are lots of elements in the schema.org kind of definitions that are available. And from those, we only use a very small part for the rich results. And even those that we do use in the rich results, they would be used to display the search results slightly differently. They wouldn't change the ranking of those pages. So it's something where you can really focus on what ways do I want to have it visible differently in search, and what are the requirements there. You don't need to worry about all of the kind of side details that are also available. OK, got it. Thank you so much for coming. Sure, great. How's it going today? Hi. Yeah, this is Pete from Burlington, Vermont, from the company that does the car dealer websites. We've been communicating for a little while now. We're not really seeing that cross-canonical, cross-caching issue get any better. It doesn't seem getting worse anymore, but it doesn't seem to be fully resolving. And I just kind of wanted to connect with you again and see if you guys had identified anything that maybe we should be doing differently or just give me a status update. So any ideas? We looked at that with the team, and they made a bunch of changes to kind of really separate these sites out. So that's something where, over time, as we re-index those pages, that should be getting better. But it might not be something where you'd see an immediate change from one day to the next. So that's something where, if you're looking at kind of lower level pages that rarely get crawled and rarely get re-indexed, then that'll take a bit longer for everything to settle down again. But the main pages should be settling down fairly quickly. So probably. Do you recommend like, I mean, if we're seeing pages that consistently be issues, like resubmit them for indexing through Search Console? Sure. Yeah. OK. That works, or submitting them with a sitemap file with a new last modification date. That also helps anything to kind of get those re-processed. And once they're re-processed, then that should work. OK, cool. I'll do some checking around and testing, and maybe I'll email you again if we need to do so. All right. You're going to be in the US anytime soon? In two weeks, something like that, yeah. Cool. Maybe I'll see you in person at some point soon here. Well, I usually go to Mountain View, so not Vermont. I'll come meet you. Oh my gosh, OK. So I'm probably going to be doing an office hours hangout when I'm there to kind of do something with the local time. So maybe it'll be a little bit easier for you, not middle of the night. OK, that'd be great, yeah. Cool. All right, I appreciate it. All right, let me run through some of the submitted questions so that we don't lose track of them completely. I have a bit more time afterwards, so we can go through some of the other stuff as well. Anything else that comes up from your sides, but just so that we don't completely skip the submitted ones. We recently noticed a spike in crawl errors for a site that we can't seem to find a cause of. The URL inspector in Fechers Google don't show any problems. What could be happening here? So I took a quick look at this website with the team here. And one of the things that I noticed is that you have a ton of different URLs on here. And we have a lot of trouble crawling as much as we can. And for a while, you had a limited kind of cap on the number of URLs that we can crawl. And that limit has expired, so we're trying to crawl a little bit more. And I think we're just running into issues because of that difference of us wanting to crawl so many URLs, and you're saying, I don't want you to crawl that much. So what I would recommend doing there is, on the one hand, setting that limit back up, if that's a problem for your site. And on the other hand, trying to figure out what might be happening there that we find so many different URLs, and we try to crawl them. So thinking about canonicalization across your website, thinking about the consistent URL structure so that we don't run into millions and millions of URLs that are all variations of each other. So that we can really crawl, essentially crawl freely on your website without causing any problems for you and without us running into all of these infinite spaces with regards to the URLs on your website. So that would be my recommendation in a case like this. What are the best ways to tie an author to a post and to help Google to join the dots? With Google Plus being gone, I guess the rel publisher and rel author will be out of the question here. Is article schema the way to go? What's the best advice here? So I hate to break it to you, but authorship has been gone for a really, really long time. So the rel author link is not something that we've been using. So even if Google Plus is gone, authorship will also be gone still. So that's something that I think I wouldn't have relied on for a while now. What I would recommend doing is definitely setting up normal author profiles on your website and using things like the schema.org markup that you can use for articles to tell us about who the authors of your pieces of content are. So that's something that I think you can do without Google Plus as well. So that's kind of the direction I would head there. Is there any link equity loss from redirect chains? So for the most part, that's not a problem. We can forward page rank through 301 and 302 redirects. Essentially, what happens there is we use these redirects to pick a canonical. And by picking a canonical, we're concentrating all of the signals that go to those URLs to the canonical URL. So for example, when it comes to links, we will say, well, this link is between this canonical URL and that canonical URL. And that's how we'll treat that individual link there. And in that sense, it's not a matter of any link equity loss across redirect chains, but more a matter of almost usability and crawlability. Like, how can you make it so that Google can find the final destination as quickly as possible? How can you make it so that users don't have to jump through all of these different redirect chains? Because especially on mobile chain redirects, they cause things to be really slow. If we have to do a DNS lookup between individual redirects, kind of moving between hosts, then on mobile, that really slows things down. So that's kind of what I would focus on there. Not so much, like, is there any page rank being dropped here? But really, how can I make it so that it's really clear to Google and to users which URLs that I want to have indexed? And by doing that, you're automatically reducing the number of change redirects anyway. The last big core update seems to be provoking some drastic changes on the search results for some keywords. It's a bit weird that, for example, this site stopped being relevant for some keywords in the 1st of August, and suddenly it's back again. I know you'll say there's nothing wrong with your site, but it's a bit drastic for the site owner to see them kind of disappear and come back again. I agree. Sometimes these things are a bit drastic, and it's especially weird when things kind of bubble back up. But these are essentially changes that we make in our algorithms to try to improve things across the board. And the feedback that we get from people, from SEOs, from users, really helps us to kind of improve these algorithms over time. And it can happen that because of the feedback, we'll try to improve things in a way that will result in more visibility for sites as well. So that's something that can certainly happen over time. So one thing I'd recommend doing there is really making sure that you give us feedback if you see things that are really weird. In particular, what helps us a ton is if you give us specific queries, which we can try out and specific URLs where you're seeing problems, and ideally really as generic queries as possible. So not taking a long string of text from your website and saying, well, for this piece of text, I expect this particular page to show up. But really something that a lot of users might be searching for and really giving us something where it's easy for the search engineers to look at it and say, objectively, yes, we could be doing better for this particular query. And by focusing a little bit on this particular query and queries like that, that's something that will have a positive effect on a lot of users when they search for things. So the feedback is useful for us. It's not a matter of us just throwing changes out there and hoping nobody notices. But if you see things that are weird, either going up or going down, please do let us know. And we picked this up in various places. You can use a search results page with the feedback form on the bottom. You can ping us on Twitter or Google+, or wherever. And a lot of these things, we do pass on to the team directly so that they can take a look at it. Sometimes we don't have anything that we can respond with other than thanks for your feedback. And sometimes the feedback is something that's more taken into account in the long term. It's not very often that we'll take a piece of generic ranking feedback and say, oh, we need to fix this today because that essentially means we're dropping everything that could be improving things overall and focusing on this one tiny problem. So we try to really use the time that we have available for working on these things in a way that has the most impact for the most number of users. On our e-commerce site, our internal search function returns pages that are set to follow no index. So we don't get duplication of those pages. Can you see any harm from an SEO point of view with us either setting this to no index, no follow, or setting it to follow no index for most popular categories only? I was wondering how Google uses internal search on pages, passing page rank, and whether there's a good practice here. So it kind of depends on how you have the setup on your website in the sense that, for the most part, Googlebot won't go to an internal search page and start entering queries and trying things out. But rather, we try to follow links within the website. So if there are links to your internal search pages, that's something we might try to crawl and see what we can find there. But if there are no links to those internal search pages, we're not going to just try random keywords and see what happens there. So that's something where probably unless there are specific links to those pages, unless you're using those search pages in a form of category pages, for example, then that's something where probably we wouldn't be crawling those pages so much anyway, so it probably doesn't matter so much how you specifically handle them. If you're using them more in the sense of category pages and that you have links to those search pages within your website, then that's something where you might think about how can you handle kind of the crawling of all of those pages in a reasonable way. That could be something as simple as saying, well, the first search results page is indexable and all of the other ones are not indexable to kind of limit how deep Googlebot crawls into those search results pages, because sometimes it's really more of an infinite space than anything else. But that's, again, that's something where there is no one-size-fits-all solution. It's really something where you need to think about your site and think about which of these pages you want to have indexed. And that could be popular categories, like you mentioned here. It could be the first page of all search results. It could be that you only allow indexing of a white list of search results that you have available. So maybe only queries that are really relevant to your website and not random queries that people are also trying on your website. So all of these are different things to kind of keep in mind. And based on that, you can make a decision there. It's not a requirement from our site that everyone does it in exactly the same way. I have a site that Google is, according to Search Console, excluding 28 million pages. They're discovered currently not indexed. The whole front end is a React-based single-page app with server-side rendering for the initial load, which ensures all of our metadata is present. The data comes from a PHP-based API. Could any of this be affecting the indexing? What could be the reason for the exclusion? So it's really tricky to say what might be happening there. You mentioned a bunch of technical details. Those sound reasonable to me. If you're using server-side rendering, then things like the API behind it is essentially invisible to us. The JavaScript front end is probably also invisible to us, because with server-side rendering, you're serving us the HTML version that's finally available there. So from that point of view, those technical details sound pretty good. On the other hand, it's hard to guess how big this website is overall. And what those 28 million pages mean with regards to our search results in general. So for example, if we think that overall this website is OK, but not really fantastic, it might be that we go off and crawl an index, I don't know, a couple of million pages, but that maybe we don't go off and index all, let's say, 100 million pages that you have. That's something where our algorithms try to figure out what the reasonable approach is here with regards to how we kind of judge your website overall. And that's something that can change over time, where if we see that actually this is a really fantastic website and all of this content is stuff that we've been missing for a really long time, then we'll probably go off and try to crawl and index as much of that as possible. On the other hand, if we look at this website overall and say, well, actually this website has a lot of content, but it's just a collection of phone numbers, for example, then maybe crawling and indexing another 20, 30 million pages is not really the best use of our resources. So we might say, well, we know about these URLs, but we are not explicitly crawling and indexing them because we're not sure about the overall quality and the value of these URLs overall in the search results. So that's something where I would focus more on the general quality point of view and think about what you can do to make sure that your website is actually really as valuable as possible so that when Googlebot looks at your website, it goes, well, this is a fantastic website. And I know about these other 20 million pages that we haven't touched yet. So maybe we should spend more time to actually crawl and index those pages. So that's kind of the direction I would had there not so much to focus on the technical details. It sounds like you have those covered, but more to think about how can I improve the quality overall of the website so that it's worth Google's time to go off and index more of that. I was wondering if it's possible to use AMP only for regions like Nigeria where the internet is slow and mobile users can be presented apps. Theoretically, you could do that with something like geotargeting and hreflang to let us know that there are specific pages that are specific for Nigeria. And on those pages, you have the link rel AMP HTML for the AMPs that you have available there. For one URL that you have available globally, it's not something that you can easily say. I don't think you can say it at all. How and where you want the AMP versions to be shown. So if, for example, for your home page, you have an AMP version, you can't say, I only want the AMP version shown to users in this region. I think that's something that would be really tricky to do, and it's something that probably we wouldn't easily support because we really try to keep the global view and say, well, this URL here has this associated AMP version, and we can show this associated AMP version whenever we think it's relevant. And then there's a question about session stitching with regards to AMP. I don't know how that is handled at the moment. I assume you either need to go to the analytics help forum or to post for AMP. I believe it's on GitHub now and ask the folks there. We're located in Greece, and there's some really unhelpful search results in the health niche. When looking for doctors or medical information, can I send you an email, maybe something your team will see? Sure, I'm happy to look at any kind of feedback like that and pass it on to your team. I know sometimes it's a bit tricky in regions where maybe there isn't as much content available, where when we remove some things or when we change the rankings a little bit, then sometimes things shuffle around a little bit unexpected ways. I could imagine that maybe in Greece or with Greek content, that might be something that would be happening there. So if you can send me some details there on Twitter or wherever, then sometimes that's really useful. I heard Google wants you to have an address on your website and it will show more authority. What if you're just an internet business and you don't have an address? Do you really need an address in the footer of an about us page? So from a purely SEO point of view, it's not that we explicitly look for addresses and say this is a sign of a good website, but it is something that users sometimes look at. And even for pure e-commerce websites, sometimes they do want to see who is actually behind this. If I order something here, where does this order go? Am I going to have to pay import taxes? What if I need to exchange something? Like how involved is that? And a lot of times that is easily answered by having an address. On the other hand, if it's purely an online site, like if you're a blog and you're just posting information and that's all that you're doing, then maybe an address isn't really that critical. So that's something where you need to think about your website and how that all fits together. Google is still not able to deal with people behind domains with authority backlinks. People just buy expired domain names and put new content on it, and then they rank easily. I don't know. I think we do a lot of work with regards to expired domains, and it's definitely not as trivial as you make it sound there. That said, it sounds like you're seeing a lot of these issues, and maybe you've collected a bunch of these. So if you want to send me more details there, I'm really happy to pass that on to your team. I know the WebStream team loves taking a look at these things because it's always something that gives them a little bit more insight into what maybe they're missing with our existing systems. So if you want to send me some more details, that would be awesome. If you just prefer to use the WebStream report forms, that also works. That also kind of goes through the same team. If it's a bigger collection of things, then sending it directly to me makes it a little bit easier to pass on. John, what's the outside of scammers or anything? What's the inherent problem with buying a domain that someone's put a lot of work in? Can't keep up or let's go in the offline world if it's real estate that someone's put a lot of effort into, and then somebody else comes on and takes it to get all the benefit of the traffic and everything else? I mean, there are genuine reasons to take over somebody else's blog or website or piece of land. I assume it, but it's that good. And the links are that good. It wouldn't have expired if it was sold. So where's the harm? Usually, so the ones that I see are usually really lower quality spammy type sites, where on their own, those sites would not be ranking. And they're basically just trying to use these expired domain names as a way to get their foot in the door. So they'll go off and buy a conference website that, I don't know, the conference took place like five years ago. And on that website, they'll put maybe like a phone number lookup site and use that to try to rank their phone number site using a conference website. And that's something from our point of view, like we shouldn't be ranking a phone number site based on a conference website that was there a number of years ago. All right. Multilanguage websites, are they able to leverage the site link search box if their home page is a language selection landing page without an option to search? The website is using language, regions, specific folders. So how can that be implemented properly? I think this is still one of those cases that isn't fully supported, where we try to get it right, but we don't really have a way of letting you mark that up in a reasonable way. Because we pick up the site link search box markup from, I believe, the home page, and we use it for your website. So if you have different subdirectories within your website for different languages or regions, then that might be tricky with the site link search box, which only goes to maybe one language version. So that's something where feedback for us is sometimes useful to bubble this issue up again. But otherwise, I would try to focus on your primary language and just implement it like that. Or, alternately, within the search page that you have available that you point out with the site link search box markup to try to include some kind of a dynamic switching of the languages there. In the new search console, I picked up a page and ran the URL inspection tool. It's an index, but not added in XML site map, while it is added in the site map. Is there a bug in that? What could be the solution there? That's something that should be working fairly well. So one of the things that I would look into there is more with regards to the exact URL that you're using, because what's really important for us is that the exact URL is listed in the site map, not something that looks similar. So even differences like dot, dot, dot, non dot, dot, dot, or trailing slash, or uppercase, lowercase, within the URL, all of that plays a role for us. So that's something where you really need to make sure it's exactly the same as in the site map file. And then we can match it and say, well, this is the same, and that's fine. Do you validate HTML with W3 standards? No. I mean, we probably check some pages with regards to valid HTML, but it's not that we have a requirement for search. That means we need to have valid HTML. So just having valid HTML on its own is not a ranking factor. One thing that does play a role there sometimes, though, is with structured data, if you have invalid HTML, it's sometimes really tricky for us to figure out which parts of the page belong together for the structured data. So not so much with JSON-LD, but if you use a markup between within your content and your HTML is so broken that we can't understand which of these HTML elements belong together within the same structured data element, then that will make it hard for us to extract that structured data. The other thing that is kind of touched upon here in the question is, what about JavaScript between the head and the body of a page? That is something that does play a role in that if there are elements within the head of a page that need to be in the head of a page, and your HTML is set up in a way that it breaks the head of the page before those elements are parsed, then we might not see those elements as being part of the head. So the most common scenario I've seen here is with regards to hreflang markup. So if you have hreflang links within the head of the page, but the low element in the head that is breaking the head element, essentially, then those links will be seen or might be seen as being within the body of the page rather than in the head of the page. So one scenario that comes across every now and then is that you add some kind of analytics JavaScript code to the head of your page, and that analytics code injects maybe iframe or some other visible element within the page into the head of the page as well. Then after we render that page, we'll see, well, there's an iframe here. That means if there's an iframe here, which is not allowed in the head, that means we need to implicitly close the head and open the body of the page. And the link, real HTML tag, link row, hreflang tags, those would then be seen as part of the body. So that's something that is really tricky to spot. So that's one of those things where I would try to watch out for that and maybe move those hreflang links either to the top of the head so that they can definitely process or to move the link, real hreflang links to the sitemap file where we don't have to worry about what is within the head and what is outside of the head. And there are very few elements that kind of fall into this category. It's usually the different link tags that we have. The meta tags are also something that we like to see within the head of the page. I don't know if it's absolutely required. So things like the meta robots tag, that all of that kind of is something that we need to see within the head of the page so that we can accept it properly. Let's see. Is Google in the process of migrating to no SQL? No, I'm not that unaware of. In Search Console, Google shows various types of page, having a link. For example, with a hash comment, when Google doesn't crawl hash URLs, and how does it know my web page is getting a link from one of those URLs, I don't know. I haven't seen that. So if you have any examples of that, I'm happy to take a look. In general, we don't crawl hash URLs and pre-index hash URLs, but there are some exceptions where we would be able to index hash URLs separately, where our systems have learned over time that there's something unique that we need to pick up with those hash URLs. We have a blog on our website. When writing an article, I make links to other relevant resources of good quality. Is there any need from an SEO point of view to make those links from my website to other resources no follow? If I make them do follow links, is it possible that my site could lose some authority? So if these are natural links within your content, that's a good time. I would not lose any sleep over no follow or not no follow. If these are normal links within your content, if they're not placed there because of any special agreement that you have between these sites, then it will just make them normal followed links. That's not something where you'd see any problem from. I have a website that comes in five different languages with 40 million pages each language. Well, Google indexed the alternate pages faster if I put the hreflangs in the sitemap compared to when I have the HTML. No, that doesn't change anything for us. When we have the hreflang within the sitemap, we take that into account when we reprocess the individual URLs. So if one URL is known to be in your sitemap file and we reprocess that URL, then we'll double check the sitemap file to see what hreflang information we have available there and use that for indexing. So it wouldn't make things faster to have hreflang in sitemaps versus on the page. With 40 million pages, obviously a sitemap file is always a good idea because you can tell us which of these pages have changed, but it wouldn't affect the processing of the hreflang. Is it a benefit to compress the sitemap file with gzip? Sure, I think that's always good. Just from pure bandwidth point of view, it doesn't play a role for the processing on our side. So we unzip them and process them normally. They don't get process tested just because they're smaller file size. John, just a question about that. We've noticed our sitemaps are starting to get indexed in gzip. Is this good or is there something that we should be doing to stop them getting indexed? Stop them from being indexed. So how do you mean being indexed? Are they showing up in normal search results or? Yeah, yeah, exactly, yeah. We've noticed in the last week or so that a couple of our sitemaps are showing up in the index. Yeah. So first of all, I would try to differentiate between are they showing up for normal search results or are they just like with a site query? If you can know exactly what to look for, you'll be able to pick them up. Because if they're just for these artificial queries, then it's probably not worth really doing anything about that. They are showing up for kind of queries that we are monitoring. OK. Then what I would do is use the xrobots tag HTTP header to tell us not to index those pages. So that's something that, depending on your server, you can set up a rule and say everything.xml or everything.gz should have the xrobots tag header for no index. OK, and do you think it would affect the sitemap if we've gone through Google Search Console to remove from index or not have a negative effect? No, that wouldn't have any negative effect. The removal tool in Search Console only hides it from the search results. It doesn't change anything with the processing. OK, thanks. Wow, lots of stuff happening in the chat. Let me just double check that I'm not missing anything here. Oh my gosh. Yeah, I've got one thing in there again. Sorry, John. OK, go for it. So you raised an interesting point earlier on about schema markup. And so if we're talking about product schema markup and there's a couple of line errors, say images are missing or something like that, you said that you ignore the whole schema markup. Is that correct or is that a misunderstanding of my part? So what happens there is we try to figure out which kind of way that we would process this information within the markup. So for example, if you're trying to use the article markup and we recognize their image is missing there, then we wouldn't be able to use that schema element for the article markup. If, on the other hand, you also include things like reviews and the reviews are OK and the article markup is just broken, then we would skip the article version and just focus on the review markup and use that. So just to clarify, so article markup, there's a line missing on images missing, for instance. You would ignore the whole of the article markup even though the author element is correct and so forth. You would miss the whole markup. If it's a required element, we would skip that, yeah. Right, OK, thank you. It's a bit tricky because some things we have recommended and some things we have required that there's a ton of stuff that's completely optional. But if it's a required element and it's missing or it's invalid, then we would skip that. And this would show up as red in the schema markup testing tool. Yeah, OK, cool, thank you. Hi, John. Just going back to our question earlier about Google ranking the wrong page for keyword mirrors, and I've been getting some useful insight from other webmasters in the chat. And I just wondered, were you able to quickly have a look at our home page to see if you could see anything obvious on that? I don't know if you dropped the link somewhere. I need to have to take a look probably with a bit more time. Doing a vibe is always tricky because it's easy to miss things and to guide you in some direction that isn't really that useful. Yeah, OK. But I can take a look afterwards. And if you have a thread in the help forum, then I can double check to see that the right things are there, too. OK, all right, no worries, thanks. All right, let me double check some of the questions that were submitted. Still a bunch of things here. Let's see. Otherwise, maybe I'll just open it up for you all and see what else is on your mind. Hey, John. Hi. Hi, I had a question, actually, in the thread. And it was about the rise of scraper sites and cross-domain canonicalization. I do think the issue is a little bit more complex than that. Big variables aren't usually solved by simple solutions. We have a website. They're a travel website. And they rent homes on the beach. And they also sell homes. And they have two domains, a little bit of issues on the local side with citations and authority and just understanding where the locations are. They also have a website that uses a hash fragment. And the hash versus push state conversations have been coming up a lot. But on top of that, they do have a serious backlink problem. And I've narrowed it down to these three things. Content being maybe a distant fork. But I'm trying to figure out, from my end, I've been using Chrome 41. I think I've gone through every single possible method of testing. I'm in week nine of the disavow process for all four protocols. I would love to get your thoughts on how should I be testing to see that rendering is where it needs to be and the backlinks aren't the issue because we haven't received any response. And we've actually been in contact with an analytics developer at Google. I'm in San Diego for the record. But I'd really just love to get your feedback because I feel like I'm chasing a ghost here with the backlink issue. But there are some bigger issues at play. And I just don't know where to start. Yeah, I don't know without being able to look at your site. I would assume that it's less an issue of the links. So that's something that is extremely rare at the moment when I look at sites that there are really problems with the website with regards to the links that they have. It's something where, for the most part, we can really take those out of the equation and ignore those. And once you've set up your disavow file and you've put the domains in there that you know are problematic, then I would kind of drop that part and focus on the other issues on the website. So rendering is certainly one thing that could be looked at there if you're seeing that the rendering is actually working out properly. So a simple way to check is just to search for some text that's added with JavaScript and see if those pages show up in search at all. If they don't show up at all, then obviously we can't pick up the text somewhere. On the other hand, if they do show up, then at least rendering is working, and that mark should be OK. With regards to property websites and JavaScript-based setup, one thing to keep in mind is that rendering is a bit slower than normal HTML processing. So it can easily take a couple of days or even a couple of weeks for us to render content and use that for indexing. So if your content is frequently changing, then there's always this delay of us being able to actually pick up that content and use it for indexing if you rely on JavaScript to display that content. And to jump in right there really quick, you make a good point because there is some personalization on the website for users who were logged in versus users like yourself or myself who've never logged in before. And the properties do change. Oftentimes, the images won't load until you scroll down. And I know there are options. It's just Ajax and PushDate, kind of a weak side of my game. I'd love to just figure out how to learn more and go ahead. Yeah. Personalization usually shouldn't be a problem if the kind of non-logged in version is something that includes all of the content that you want to have indexed. So that's usually the normal case. On the other hand, if it's something like you have to be logged in in order to actually see the content or you have to be serving a cookie back to the website to actually see the content, then that's something that could cause problems because Googlebot won't log in and Googlebot won't keep a cookie for your website. So that's something where you need to be able to copy and paste the URL, put it into something like a fresh incognito window, and say this content loads completely and includes everything I want to have for indexing. That also goes in with your images a little bit in that if you're using lazy loading techniques, you'd need to think about which of these images do you really want to have indexed for image search and which of those images do you kind of have more as a creative element on the page that aren't critical for image search? So with properties, I assume there's probably a lot of images that you do want to have shown in image search where maybe people are using image search to find a property and then go to your website and complete whatever transaction or find out more information about that. So that's something where I try to figure out what ways you could implement lazy loading in a way that will still work for image search. On the other hand, if these are mostly more creative images or kind of alternate secondary images that you don't need to have visible in image search, then you probably don't need to spend time trying to find a way that makes lazy loading work for you for image search, if you're not getting any traffic or any useful traffic with regards to image search there. That's a good question. I guess the final thing I'll say with the images is that they are parameterized or I always get that word wrong. They're used parameters. And it's kind of interesting because the image sizes themselves don't change too much. Just as they fit in boxes in widgets, that's really all I've got. That's fine. That's fine. That shouldn't be a problem. It's something where you might think about which of these images you really want to have in index, though. It's like maybe the thumbnail images, for example, you can block by robots.txt because who wants to have their thumbnail images indexed, but maybe you have primary images per property that you do say, well, these are really things that I want to make sure are findable in image search. And one way to kind of think about that as well is to ask your users or to do kind of a user study and to have them go through image search and try to think about how they might be searching for something where they want to complete a transaction on your website. So not with the mindset, like, I want to have a pretty picture of a house that I can copy and paste and put into a PowerPoint, but more like what kind of people might be using image search to kind of refine their search and to go to your website and complete whatever it is that you want them to do on your website. And for some kind of products and properties that might be worthwhile to go through image search and for other things, you might say, well, image search doesn't really play a role here. Thank you very much. Just one really quick question. I apologize to the room. Considering they have two websites, one for renting and one for selling properties, there may be a good chance that some of these properties that they're listed by location and keeping MLS in mind and whatnot. It seems to me that either consolidating these websites into one would be an ideal thing just from what I know but also with a local aspect because sometimes the renting and buying offices, they're actually the same name, address, phone number. It's a dumb question, but what do you think? In general, I think having fewer websites that are stronger helps your website overall. With just two websites, you could argue that these are completely different needs and completely different people are searching on one website versus the other. I don't know if that's really the case with regards to properties. So that's something to think about. What you could also do is if you know that you're listing the same properties, it's to think about which one of these you prefer to have shown in search and just use a rel canonical for those. So that you have the things on both of these websites but you say, actually, this property I really want to have sold. I don't want to promote the rental aspect. I'll set a rel canonical to the other version and that way you can really strengthen the other version for queries that would be needed. Wonderful, thank you so much. Sure. All right, running a bit low on time but maybe if any of you have a last question, we can jump through that as well. John, if I can just ask really quick. You know, well, Mirob works on the new domain and we redirected everything from that old domain to the new one. I was just wondering how much time do you think until Google kind of sends everything over to the new domain. We've done this I think three weeks ago and we're still at above 50% of the traffic that was pre redirects. So is this something, we didn't do the change of address of course. So I know this kind of influences things because signals are getting fast a lot slower but do you have any idea of a time frame or anything like that? So if it's a couple of weeks then I wouldn't worry too much yet. These things can sometimes take a bit of time especially if it's a larger website and I think it's like that probably falls into that category here then I would just give it more time. Is it something that the new search console can give us more information on? Like maybe the number, the coverage report perhaps or something like that that can help us. That should show kind of those changes there too. One thing I'm aware of is some of these reports are currently a bit delayed. So if you look at them now and you're looking at the changes from the last couple of weeks then maybe you're not seeing the full picture there just because those reports are a little bit delayed. And I need to clarify with the search console team what exactly is being delayed and how long they think this will take to kind of catch up again and then I'll probably do a tweet about that but that's kind of one thing to keep in mind especially if you're looking at changes from the last couple of weeks then maybe the last week or the last 10 days or I don't know what the timeframe is might be something where you're not seeing data yet. No data at all or just data that's not, it's not the correct data. I think it's just delayed so you wouldn't be seeing any data points there. And is this just the new search console or just search console overall? I think it's just search console overall, yeah. Gotcha. And one quick thing regarding the search console API if I find any issues or some strange things maybe data not matching up with the UI version is that something I can bother you with? Sure. Sure, yeah, okay. Send those to the app also. Okay, cool, thanks. Cool. All right, with that let's take a break here. Thank you all for your questions for all of the feedback and comments and those of you that have more homework for me feel free to send that my way. I'll definitely take a look at that with the teams here. For some of these I'll be able to get back to you and kind of give you some feedback on the things that we found. A lot of the feedback that we get are essentially just processed by the team. They take that into account with their normal prioritization and we wouldn't have anything specific that we'd be able to get back to you about but this feedback is always really important for us. All right, so with that let's take a break here. I wish you all a great weekend. For those of you that joined up in the middle of the night that's like pretty awesome, thank you. I hope I'll set one up when I'm in California next. So maybe time zones will be a little bit easier when we're over there. All right, thank you all. Bye. Bye. Bye John.