 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts on Air. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Webmaster Hangouts. As always, if there are any of you who are kind of new to these Hangouts and want to get started with the first questions, feel free to jump on in now. So hi, John. I actually have questions a little bit different. I'm just about the organic search, but I think it's kind of related. So I really like the new tool that is in. And I was going to ask, is it also going to be implemented in Google Analytics in desktop when we are using? Which tool did you mean? There is this Google Analytics intelligence in Google Analytics, if you are using your mobile device if you have Google Apps. I was wondering if it's going to be also implemented in Google Analytics, because I've seen an article about this one. But I'm not sure. I couldn't find. It couldn't happen to work it. I have no idea what the plans are. I don't know. So can I ask that? Sorry. Should I post this one into GA Webmaster? Like, sorry, GA Forum or? Sure, sure. I suspect it'll be tricky, because if you're asking what are the future plans, it's possible that, at least from Google side, the answers will be we don't have anything to share just yet. I see. Well. I just saw an article that showed a screenshot that was desktop based. So I presume it is going to be up here in there. That sounds cool. Yeah. I know they've been working on a whole bunch of stuff. So excited to see what they come up with. All right. Let me jump into the questions that were submitted. As always, if you have any comments or more questions along the way, feel free to jump on in. The first one is a really interesting one. How does Google deal with non-unicode fonts? Does using them impact the quality of a site? In Burmese, the most used font is something I can't pronounce, which is a non-unicode font. And there's a unicode alternative, but it's not always displayed correctly on all machines. What's the impact on rankings when using that font? Would it be better to use unicode? So this is actually really kind of unique and interesting problem. I think it's mostly in Burmese that this comes up. So basically what happens there is that they created a separate font for their language, which doesn't map to the unicode, and which you have to install on your computer to be able to display the content in a language. And there's also a unicode version of this available. But essentially what happens is if you don't have that font installed on your computer, you see kind of gibberish characters because they don't align with what is actually written there. And from our side, what we currently do there is we try to recognize a situation when we see pages in this font, and we map that internally to the unicode versions of the page so that we can index just one version of that page with that content. And so that people searching for that content, they can find it. Looking around a little bit internally about this to see what the current status is there, one thing I did notice is that it's sometimes still tricky if you search in that font in Google, because then we sometimes have a difficulty recognizing, are you searching in that special font, or are you searching in unicode just using those characters? And that's kind of the tricky situation at the moment. But for the most part, if your pages are in one of these in this specific font, then we should be able to recognize that. The ideal situation is still that you use unicode, so that's something that we can process without having to invert anything. That's something all search engines would be able to just process directly. But if you need to use the old font, or if your pages are still in the old font, you can't convert to the new unicode version of that font, then that should still kind of work. So this is something I believe is unique to Burmese and one other language I saw somewhere. I think in the Maldives, they have a similar problem or had a similar problem. OK, let's see. Another question from Glenn. I know quality raters can't directly impact search rankings. But what about website reputation? How is Google looking into that? Can incremental improvements to reputation positively impact a site during future algorithm updates? For the most part, these quality raters are looking into specific things with regards to our algorithms. So for the most part, they're not specifically flagging sites with regards to reputation, and that's not something that we use there directly. But we do use human evaluation for various different algorithmic ideas that we're thinking about or that we want to try out. And that could theoretically include something like reputation of a website in general. But at least from what I've seen, there's no direct kind of connection there that a quality rater says, oh, this site has a bad reputation, and then it goes down in search. Because we're trying to improve our algorithms in general, we're not trying to evaluate individual sites. A quick question about similar items rich products feature in image search. Is that still in beta? We're currently only seeing items from US websites with prices in US dollars, regardless of location. I don't actually know for sure, but as far as I know, since that relies on structured data markup on the pages, if only those pages are using that markup, then, of course, those are the pages that we'd be showing in search. So there might be some skew there. If you're seeing pages that are available in different currencies or for different languages, and we're not flagging those, then that might be useful to pass on to the team. So if you have some examples there, feel free to let me know, and I can try to pick that up. Our site was hit hard by the FRED update. I've been removing content since then by no indexing roughly 75% of the lowest performing of the total 200 pages and fixing other issues without any improvements. What can we do to take the site to the next level? So in general, any algorithmic updates that we make, they're trying to improve the quality of the search results for users, which includes trying to bring more relevant content to their search results, which also tries to figure out which pages are actually good pages to show in the search results. So that's something where maybe you need to look at your site overall and not just look at individual pages with your lower quality, but take a step back and think about what you need to do to improve your site overall. And FRED is just a name that was given externally and essentially covers all of our algorithms updates that have been happening over time. So it's really hard to say what specifically you're looking at. But anytime someone comes to me and says, oh, I've been improving the quality of my website and I've been doing some pretty drastic things to improve the quality of my website, then that kind of tells me that there was actually a pretty significant quality problem to start off with. And there are probably things that both take time to get bubbled down in search and need a significant amount of work to actually take it back to the next level. Will the Panda data be refreshed this year? The Panda data is actually something that's refreshed on an ongoing basis, so there's no individual date where we update this data. So that's something where we wouldn't have anything specific to say about this. Essentially just ongoing all the time. Mapcuts mentioned in past videos that we should build sites that users like to come back to directly or bookmark. Does that mean you're tracking how many users visit my site like that? So no, this doesn't mean that we're explicitly tracking this for search. It's essentially just saying that you should build something that users want to go to directly without going to search as well. Part of that is just for the simple reason that search results can and they do fluctuate over time. And if you want to make sure that users continue going back to your site, then you need to take those search results and the traffic that you get from search and turn them into users who go to your site on their own without having to go to the search. So that's what we're looking for there or what we're recommending there is that you should build something that users want to go to even if they don't know what they searched for in the past. So it should be something that really sticks with them, that they keep going back to, that they recommend on their own. And that's what Matt was saying there. It doesn't mean that we're explicitly looking for that through various signals. It's more that this is kind of the goal that you should have as a webmaster in general. Does having duplicate content with other websites decide low quality and site quality signals? Usually it happens in real estate websites, job portals, news websites. No, duplicate content on its own doesn't mean that a website is lower quality. But oftentimes sites that reuse a lot of content tend to be fairly low quality because they don't really have anything unique and compelling of their own that's added in there. So that's kind of the connection there. I think this kind of comes back into the general things that we talk about when it comes to websites is that a website should be able to stand on its own. It should be something that kind of regardless of the content that shared elsewhere that people go to explicitly to find this content. And that usually means that you should provide something unique, something valuable, something additional. In addition, just the same content that people can get everywhere else. If you decide that such and such a page on my website is low quality and you stop sending Google traffic to that page, is that page still hurting my website's quality unless I know index it? So this is, I guess, a fairly common question that we hear over time. And the general answer is we do sometimes look at the overall quality of a website. And the overall quality of the website is built up of the quality of the individual pages on the website, of course. So if you're noticing that a large part of your website is low quality, then that's something that we will reflect when we look at your website overall. On the other hand, if you're removing the low quality content or even better, if you're taking the low quality content and turning it into something really high quality and valuable, then that is reflected in the overall view as well. So if something is not indexed, then we don't see that as part of the website. So no indexing it can help there. But really, the better solution is to figure out why this is low quality and what you can do to prevent it in the future and what you would need to do to improve that going forward. I'm working on a website with four domains and four mobile subdomains targeting four different countries. We currently have hreflang on all desktop pages. We have canonical tags from the mobile page to the corresponding desktop page. What's the proper setup for the mobile pages? Where should they point to? So our recommendation is to just have the same hreflang links on your mobile pages as you have on your desktop pages. So they should be equivalent, both in the sense of content and with regards to the metadata, which includes the hreflang links. So between your mobile pages, you should also link to the hreflang versions of the canonicals, which would be the desktop pages in your case. So you can just take the hreflang markup from the desktop pages, copy that on the mobile pages, and then you can set. Don't need to do anything special. Just a follow-up question on this. So the hreflang on the mobile subdomain should point, sorry, to the desktop websites or to the mobile websites? Should point to the desktop websites. To the desktop. OK. OK, so just copy the hreflang from the desktop websites onto the mobile subdomains and not change anything. All right. Thank you. OK. I've added meta robot snow index to websites over three months ago. The Cache version shows Googlebot has visited recently. But some pages, not all, are still indexed. What could be the possible reasons? Googlebot isn't disallowed from crawling. So I think without checking individual pages here, the main thing to keep in mind is that Googlebot crawls on a per URL basis. So we don't crawl the whole website at one point. We crawl individual pages there. And what usually happens is some pages, usually the more common ones, the ones that have changed a lot, usually like the home pages, the category pages, we crawl those fairly frequently, which could be once a day, multiple times a day, every couple of days. And a lot of other pages on a website, because we've seen they don't change that much over time, they might be crawled less frequently. So that could be every couple of weeks, every couple of months even, maybe even up to like a half a year later. So if you add a no index to all of the pages on a website, you'll see a lot of the pages drop out fairly quickly. And some of the pages kind of linger on for quite some time until we've been able to re-crawl and re-process those. So that's kind of the normal setup here. And if you say this is something that happened three months ago that you changed, then that kind of seems reasonable and that we still have pages that we haven't re-crawled that are still indexed. Because the last time we looked at them, they didn't have a no index on those pages. So some things you can do in a case like this. On the one hand, let us know about the pages that have changed. So you could submit a sitemap file with a new last modification date for those pages. We'll usually take that and re-crawl those pages fairly quickly for the most part. And when we see the no index there, we'll drop them out of the search results fairly quickly afterwards. Another thing you could do, if this is a critical issue on your side, if you really, really need those pages removed as quickly as possible, is to submit a site removal request in Search Console. So this is something that's a temporary removal of your website. But it removes the whole website within maybe a day or so. So that's something that you could do there as well. You can also combine those two. So a site removal doesn't remove it from an index. It just removes it from the search results. You could do a site removal request. And at the same time, submit the sitemap file with all of the changed URLs. And we'll remove the page from the search results or the site fairly quickly from the search results to start with. And then still, over time, reprocess all of those URLs so that when the site removal request expires, we will have essentially cleaned out most of these old URLs. And if you notice after the expiration that there are still old URLs left that are indexed, you can do another site removal request. And they're kind of let it run for another cycle and update those last URLs that were still shown up. So from what I understood correctly, then putting no indexed URLs to sitemap makes sense if that's the case, yeah? Sure, you can do that. I mean, if these are pages that were never indexed, if they've always had a no index, then that doesn't really change anything. Because we will crawl those pages and we'll see, oh, it's still no index. We'll kind of ignore that. But if they used to be indexed and you've changed those pages significantly, then putting them in the sitemap file is fine. Also, if you change them to a 404, then it's kind of paradox, I guess, because you're submitting a URL that you know doesn't exist. But if it used to exist and we see it in the sitemap file, we crawl it from the sitemap file because it has a new date and we see it's a 404 now, then we can drop that from the index a little bit faster. Cool. Hi, John Riddick. Regarding the question about the no index, what if we accidentally add a no index tag in the website and we found that Google just removed the search result from it and then our engineering to take out the no index from normal. So the Google will record the website and will the ranking back as normal? Usually, it'll come back fairly closely to what it was before. Obviously, any time you make significant changes on a website and there's some time that passes and then you change it back, it's not going to be exactly the same as before. So things in the algorithms might have changed over time. But if this is something that's just a couple of days in between and the URL dropped out, you remove the no index and it comes back, then that should be pretty much the same as before. OK, so you won't recalculate the page from the start from zero. You will somehow get it back. OK. Doesn't it pass? So we had something similar actually on our side recently. So in our case, it was the situation that for the Search Console home page, we used the login page that had a no index on it and then suddenly the Search Console page disappeared from the search results. So some of you might have seen that. It can happen to anyone, right? So in our case, it happened to the Search Console site, which was twice as embarrassing, I guess. In our situation, it was a bit tricky to get that no index removed because it's on a shared login page across all of Google's services. So what we decided to do there is to use robots.txt to block crawling of the Search Console home page so that we would at least have kind of that blocked listing index in the search results. So that's kind of, I guess, a situation that you might see as well over time that happened to Google, happened to us as well. So don't feel bad if you accidentally have a no index on your home page or somewhere and you notice it afterwards and you have to kind of scramble to fix it. Happens to us, too. So you mean using the robots.txt to disallow the bot to crawl, get the no index to crawl? Yeah, so we used the robots.txt to disallow crawling so that Google wouldn't see the no index tag. So you won't remove the search result because you cannot crawl it. Oh, I see. Yeah. Sometimes you have to be creative to find something that kind of works. I don't think it was a fantastic way to handle this. Ideally, we would have avoided having the no index there. But especially in a case with services that are behind a login, it gets really complicated. John, just a quick one on that. Presumably, if you have just one or two pages that you either accidentally indexed or no indexed, you can just change them to the correct one and do a fetch in search console rather than having to remove absolutely everything and add it all back in again. Exactly. Thanks. John, I have a different kind of question, but it's kind of flated. So one of my clients, I've seen they didn't implement pagination, and they had paginated pages. So the first thing I wanted to do, was to implement this rel, a pre-next implementation on that. And I also saw that, unfortunately, they forgot the next button and pre-button. So for example, although the unexisting pages there were next button and Google was crowding pagination number million. So then what I did was I removed the canonical from paginated pages. And I also put index and follow, of course, for the ones that I want to be shown in the search results. But in order to cut this relationship, of course, I got this next button visible removed and then implemented no index, no follow for the ones that actually do not exist. Do you think there should be anything else? That sounds about right. So I suspect what will happen is we'll still try to recrawl a lot of those old URLs that used to exist. But over time, maybe I'd say over half a year, a year or so, the amount of crawling of those URLs should drop dramatically as we recognize that there are no index, no follow. Yeah, so that's the thing. Like, I'm looking at the index status regularly, checking that. And also, I'm looking at the log file analysis. And also, I'm doing site search, although I know it's actually not really something that I can trust for. But I'm looking at them for the last couple months, last two months. It is developing. Like, it is decreasing the numbers. But still, some of the pages are still like in cash. And you say, like, six months is a better time to wait for it there. No, no. Thank you very much. These are the things that just take a bit of time. So with regards to the site overall, you probably see very minimal effectiveness because those are pages that probably are only ranking for site queries. If you explicitly search for a page, I don't know, 500 out of the set that doesn't exist anymore, then you'll probably still find it. But if you're looking for something normal, then we'll probably show them more normal pages on your website anyway. Yeah, but still, like, having those kind of pages that are actually looking like each other and it used to be indexed before, I think it's in our way to improve the quality of the entire site, yeah? Sure. I think if you find issues like this and you can fix them, go for it. Thank you. All right. Let me see what else we have submitted, a whole bunch of questions. I wanted to ask what criteria is used when Googlebot tries to access a form, for example, a calculator with insurance questions and it refers to an older blog post about crawling through HTML forms. So the blog post specifically is more about accessing content that's behind a form. So a common situation that we sometimes see, especially on reference websites, kind of these document repository type websites, is that you just have a search form and you go to the search form and you enter some keywords and then you find links to individual pages on that website, maybe individual documents. And in a case like that, it's important for us to be able to kind of figure out a way to crawl through the search form to actually discover this content. When it comes to things where that form is actually used to calculate something, to do something, other than just searching for content, then usually we try to avoid doing too much on a form like that. So if you're talking about a calculator with kind of insurance rates, those kind of things, then probably we'd look at that and say, oh, there's nothing we need to do here. We've seen the content that's linked properly within the website. We don't need to kind of go through this form to figure out what else is there. Some websites are too poor in delivering the order. Some of them don't even have customer support. So does Google use anything like customer satisfaction? As far as I know, we don't explicitly do anything specific there. So this is something that we tend to assume that we would pick up other signals that would flag us the same thing. So if a website is really bad and nobody recommends it to other people, then we'll see that nobody is recommending the site. And we'll try to kind of indirectly infer that maybe it's not so relevant for these specific queries that we've seen in the past. I don't know if it's Panda, Penguin, or Fred that my website has dropped so much. I don't see any messages in Search Console. Does Google apply a penalty to the whole website? If I'm penalized for low-quality content? So in general, if there's any kind of a penalty on a website, then that would be manual action. That would be something that the web spam team manually takes action on a website. And that would be something that we would flag in Search Console in the manual action section. So you would see that information there. When it comes to things that aren't flagged in Search Console, then usually that's just a sign that our algorithms are looking at your website perhaps in a slightly different way, perhaps kind of reevaluating what we thought the website was about or how relevant it was in the past and decided that maybe there are other websites that are more relevant to users in the meantime. So in a case like that, obviously the answer is it's not so easy because you kind of have to take a hard look at your website yourself and see what could you be doing differently to significantly improve the relevance and the quality of your website across the board. And sometimes that's not something that kind of falls back into something like a simple technical fix where you just like tweak the meta tags or no index a couple of pages and then everything is OK. That's something where you really need to kind of sometimes rethink what you're actually providing on your website. And oftentimes it helps to get outside opinions on this to kind of step out of that comfort zone where you're like, oh, this is my baby website. I've grown up with this website. It's so awesome. Nobody can say anything bad about it to actually hearing from other people, maybe normal users from the web, that look at your website and give you a more objective view of where you could be improving things or how they think maybe your website isn't as perfect as you personally might think it is. So getting help from outside people is something I'd strongly recommend there. One domain using different folders for different countries and using hreflang tags. Does it get more benefit in ranking? No. So hreflang essentially just swaps out the URL in the search results. It doesn't change the ranking of a page. So the pages would rank normally, and then the hreflang tag just swaps out the URLs against ones that we think are more relevant based on the user's location, language, those kind of things. How does Google understand the special characters like brackets, dot, dot, dot, adding them or removing them? Does that help Google to understand the word or not? Not quite sure what you're asking for here. I don't know if you're here in the Hangout. Doesn't look like it. OK. If you want, feel free to add a new question about that so that I can take a look at what that might mean. I think it probably means that special characters will Google pick up as a title or description. So special characters in general? Let me see. So in general, if you have kind of like symbols, those kind of things in titles and descriptions, that's not something that we would explicitly use for ranking for normal queries. So I believe you can search for some kind of emojis and unicode symbols in the meantime. But unless someone is explicitly looking for those special characters, then that's not going to change anything when it comes to ranking. So if you have a star in the title or in the description, then that's not going to make your page more relevant for other words that are in the description. Our different vendors agree to add our website to their website, but if we provide them the text, that would be the same. And if Google detects a pattern and we discount those links, then what would be the best way? Kind of hard to say what specifically you're trying to do there. So if other websites are taking your full content and publishing it on their website as well, then you're kind of creating a competitive situation in that we see the same content on both of these pages. And if someone is searching for that generic content, then we might choose this one. We might choose that one and show that in the search results. If that's OK with you, if you don't mind that we might show your other vendors in the search results instead of your website, then that's something you could do. On the other hand, if you want to make sure that your website is being shown for those queries, then by giving that content to other people to publish as well is probably not the best approach there. So one thing you could do is request that they use your content but no index it so that it doesn't actually get indexed. Maybe use a raw canonical from those pages to your pages. If that's something that's possible in the setups that they're using, those are some things that you might do to make it possible for users on those websites to get to that content. But for that content, not to actually index directly on their website. Joan, although you answered that over Twitter yesterday, is there any way to request an access for better search console? Not at the moment, no. So we're kind of expanding the beta group there to something quite a bit more, which is why we did the blog post that we don't surprise too many people when they see that. But the team is specifically looking for websites that have issues that might be solvable with the new setup, with the new features there. So having some random website in the new search console better that, for example, doesn't have any AMP issues or doesn't have any issues with indexing, that wouldn't make it a useful test. It wouldn't give us that much useful feedback with regards to what we need to do to improve things going forward. So with that in mind, the team has specifically looked across the web to see what kind of sites might find the new features useful. And those are the kind of sites that are getting an invite for this beta. But I suspect this is something where the team will be moving forward fairly quickly. So if you're not in with this beta, then maybe in one of the future ones or maybe one of those lives, you'll have a chance to try things out there too. Looking forward to it. Yeah, I know the team has been doing quite a bit there and has been working on UI and on the data to get as much information in there as possible. So really excited to see what all is happening there. How frequently are the HTML improvements in search console updated? If duplicate title tag, but there's a canonical tag, that's not your process. They're shown how long will it take to get it removed. This kind of falls back to the general crawling and indexing of a website situation where sometimes we crawl pages fairly quickly and fairly frequently. And sometimes we don't crawl them that frequently. So for example, if a page that we've seen has a canonical tag on it, we might choose to not re-crawl that page that often anymore because we've seen a canonical and we can kind of follow that and focus on the canonical URL there. And that can result in something like an issue like this being visible in search console for a longer period of time. And I'd recommend using the HTML improvements feature as a way to kind of get an idea of what you could be working on, but I wouldn't recommend using that as a checklist that you absolutely need to resolve and kind of get this report down to zero to move on. It's more of a way of kind of recognizing systemic issues across your website that you could be improving in general and not something that you need to get down to zero issues to kind of move on in search. John, can I ask a related question if that's okay? Sure. And about search console, we had shared a conversation about this a few months ago in emails and emails as well, but we found that in terms of structured data in search console, there was a reporting change, it was said, around January and we had about 5,000 pages that were listed as having structured data on and the reporting change then happened and suddenly it dropped to 5,500. And I think you said it was purely reporting change. It wasn't any backend data or index changes. And it's kind of gone up a bit. It's increased to about 3,000. And I guess my question is now we're a few months on from that, which is correct in terms of do we actually have 5,000 pages in the index and it's just that search console has got a subset of the real data. So is it wrong now or was it wrong then? And the reason I'm asking is that we often see, we might appear highly inorganic results. It's an e-commerce site and there are product pages and we'll have results above us, whether the price or so forth might be shown and whatever results below us were competitive of the price of the show. And we won't have that. And I'm just wondering if there's some kind of structured data issue or pages aren't being kind of scanned quickly enough or something like that. I'm not aware of anything in general around structured data that's kind of stuck or that's not being processed at the moment. So my guess is that is just the way that we're reporting this at the moment. So within Search Console, we do make some simplifications to pick the relevant sample of the pages that we have indexed and use those for our reports. For the most part, this makes sense because a lot of sites just have a ton of URLs that are indexed but which are never really shown in Search and it doesn't really make sense to kind of flag those issues because nobody's actually seeing those pages in Search and you don't really need to do anything about them. So that's something where I wouldn't use that number as an absolute count and say this is how many pages are absolutely indexed but more as kind of a trending information like are you seeing more issues or fewer issues? Is this a significant change in the issue counting or is this kind of just like a gradual change over time as you would have on any website where things sometimes gradually go up and gradually go down? We're not seeing any changes in the number of pages index. We're simply seeing a sudden drop in the pages that say they have structured data on them and the drop happened exactly the same time when Search Console reported, there's a reporting change that happened. So there's no changes on our site, there's nothing wrong. It simply happened at exactly the time there was a reporting change so if to understand, again we had an email about it whether there are still 5,000 pages that Google has a structured data for and when Search Console has reported it's structured to the half thousand it's just a reporting thing or whether there never were 5,000 pages that actually had structured data against them and the number now is correct but there's no change in the number of pages index so when you look at the number of pages, the site map type of stuff that's all consistent, it's purely the structured data which is why it's a bit of a weird one. I don't know if you're on that. I'd have to double check. Can I pop an email? Is that okay? Yeah. Okay, thanks. Can I follow up on that follow-up? I've got several clients, e-commerce, tens of thousands of products and they are showing tens or hundreds of products in the structured data report even though thousands of pages are indexed so I've got the same sort of problem question are they having an indexing problem or is it a reporting limitation? So you're also seeing a lot of pages indexed normally and they work in the structured data testing tool but we don't show them or we don't seem to be counting them in the structured data report, is that correct? Yeah, so an example would be maybe 20,000 pages in the site map are indicated as indexed. Most of them will be product pages but only 28 products being reported in the structured data report and it's a CMS so all of them have got structured data on. Yeah, just to add here, it's very similar because again the point is that when you use the structured data testing tool the page, it's not that there are any areas with the structured data that the site is finding that respect but there seem to just be some weird reporting type of things going on. Okay, if you could send me some examples, Tony I'd love to take a look as well. It sounds like when issues come from multiple sites that there's actually something that we should be looking into a bit more and sometimes these are just like reporting issues or sometimes it's something kind of quirky on our side but we shouldn't be confusing people with the data that we show there so I'd love to kind of take a look at that as well. I'll pass that on to you. John, just a real quick one about Search Console as well obviously the new Search Console that's coming out are there big data changes in it as soon as there's going to be a larger volume of data being looked at or is it really mainly UI type of stuff, do you know? I guess a bit of both. I mean, I don't want to pre-announce anything but I know they've been looking into like slightly different data the amount of data is something that has been commonly requested so... Related to that one so after the 14th of July like when you set the data anomalies in Search Console I happen to see some rich inputs traffic coming up because it was like zero before and I also checked the... I just didn't only check the clicks but also check the positions in Search Console so positions are very low is it just because that you are now showing long tail stuff in there? Yeah, that's very likely that you're seeing that there so that's one of the changes that they made there in that they're looking at a bigger volume of queries and some of those are kind of by design more long tail because that's what we kind of skipped over in the past Well, it's quite interesting to just to see this for rich results so maybe this is because it is very small for in general data that's why I can see it in rich results I don't know it probably depends a bit on the website itself where sometimes the more long tail stuff will be something that has rich results sometimes it will be stuff that doesn't have rich results it probably depends quite a bit on the website but that's an interesting observation Alright, let me try to grab some more questions that were submitted and we're probably not going to get through most of these Wow, so many text after the footer, is that something that Google uses or not? We do use text on a page but in general we do recognize that some things are less relevant on a page especially if it's kind of repeated over time Let's see, does Fetch and Render actually reflect the length of a page? So recently when testing our page we found that the tool rendered image would cut off at a certain length I think that that observation is probably correct in the sense that we try to use the Fetch and Render tool as a way to recognize kind of like a stricter subset of a page which does include kind of a cutoff at some point where we say, well, if it renders this far it will definitely work in search So that's something where at some point there's a cutoff I believe we have that documented in Help Center as well so that's something where probably if you're seeing the top part then you're seeing the bottom part as well We do also have a cutoff for indexing but usually that's fairly large So that's as far as I remember from the last time I looked at this a couple hundred megabytes So if your pages are bigger than that then probably you have other issues than trying to get the text on the bottom of a page index But a simple way to kind of double check what we're actually indexing is to search with a site query some of the text that's on the bottom of the page and see what comes up there Do WordPress websites generally perform the same as static HTML in terms of SEO Essentially WordPress generates static HTML pages so it's essentially the same thing for us and it doesn't really matter on the type of CMS for the most part the commonly used CMSs are from a technical point of view they're fine, they just work they work well on search and it's not that we have an inherent bias and say, oh WordPress is better than this type of website the website is better than that type of website it's just we get the content we index the content we rank the website based on that content How do you report negative SEO that uses thousands of links from random image gallery sites how do you fix it when the links just keep coming So in general using a disavow file is a direct approach there using domain level disavows makes it a lot easier I took a quick look at this website before the hangout and I didn't see anything with regards to links that was causing a problem there so it might be that our algorithms are already ignoring all of these anyway Do likes and shares across social media platforms really have impact on search ranking in Google No they don't have an impact on ranking in Google This simple answer there is that for the most part these are no follow anyway so we wouldn't take them into account and for a very large part we don't even see them so that's something that's kind of blocked from us anyway so we wouldn't see that Is the site colon domain.com a true indicator of the web pages indexed No So for the number of pages indexed I'd recommend using a site map file instead because that way you can submit the URLs that you really care about and see of those pages without which ones are actually indexed Search Console also has a list of indexed web pages not a list like a graph That's also quite useful but again it includes all pages on a website and it doesn't necessarily focus on the pages that you care about So for example if you have parameters that lead to an infinite space if you have a calendar on your website if you have kind of tagged URLs that you use for affiliates or for tracking purposes then all of those could count as separate URLs for the indexed graphs but they're probably not URLs that you care about with regards to being counted So for that I'd really recommend using a site-con file instead of these kind of aggregate methods I accidentally indexed the pages of my staging website What would be the quickest way to get them unindexed on the entire website through htaccess but wonder if there's a quicker way So the best way here is to use the site removal tool in Search Console You need to verify ownership of your staging website first So if you've blocked everything already then you won't be able to use a file or the meta tag verification but you might be able to use DNS verification and once you've done that you can do a site removal That way you should have all of these pages removed from the search results Obviously if you've blocked through htaccess and they're unaccessible now anyway then over time that will disappear too But the fastest way, especially if it's something that you really don't want to have shown in Search is the site removal tool Does Google's stall indexing if a page takes more than two seconds to download No, not really So the one place where you might see some changes with regards to really slow pages so that when we try to access the HTML page and it's really slow is the crawl frequency of the hunt on the website So if it takes us a lot of time to access individual URLs then obviously accessing a lot of URLs is kind of out of the question We're trying to kind of limit ourselves to a number of URLs that we fetch from your website We do this in part also because we think that if your server is already struggling to serve us some content we don't want to put it under even more load to serve a lot of content to us Let's see Maybe I'll just switch to more questions from you all because it looks like there's lots of other things in there but all over the place Hard to take some things I have a question related to the Knowledge Graph Our website is selling the Attractions tickets So when we search for location-based keywords in the Knowledge Graph we're sharing a review from a website and one of our products Knowledge Graph will show our website So you can click it and it will show how many reviews of it So we are using the structure data that the type is called product but most of our products have the structure data But when you search for some other terms you cannot find the review from a website It's showing up So I was wondering how the algorithm is determining whether to show the review or is it based on the structure data or is it based on the other reason which it doesn't make it For the most part obviously we need to have the structure data first as kind of a baseline requirement in order to understand that this is a product and this is that specific product So that's kind of the minimal requirement there but having the structure data doesn't guarantee that we always show it there So that's probably what you're seeing there If you're testing the pages with the structure data testing tool then probably I assume those pages are passing and we can see that markup but that doesn't necessarily guarantee that we will use that markup in the Knowledge Graph or in other places in search So for that there are various factors that we try to take into account there and it's not the case that you can just like tweak things on your website and then suddenly we'll show it in the Knowledge Graph There are a lot of things involved that are kind of outside of the immediate control So it's not the if it's possible that we might use the wrong structure data type because in querying we use the product should we like change to location or change to attractions or just review type of the structure data I don't know It probably depends on exactly what you have on your pages So there's one thing that's kind of tricky for us is if the structure data really doesn't match what you have on your pages then we would tend to ignore that A really common situation where that has shown up is recipe markup because for recipes we often show the image We sometimes see people taking software for example and saying oh this is actually your recipe and the photo is my loading page or the picture of a product instead and that's something that we try to recognize and say oh you're using recipe markup but actually you have something that's not a recipe So we will ignore that markup and we won't use it If on the other hand you're looking at things that have like a subtle overlap where maybe it's a product but it's also a service and you have some reviews for that product or that service and it's not something where it's clearly this or clearly that then usually it's something where our algorithms are a bit more flexible and say oh this kind of falls into this right general area we'll try to use that as a program So if it's not completely abusing the markup then you're generally on the right side Okay, so one more point is for example if the Google listing is Universal Studio Singapore should my strategy data use the exactly same name than the Google is showing or should the strategy data using the name on the website which one should I use? In general I wouldn't recommend kind of adjusting your content based on what we use for indexing So that's kind of a general guideline overall, so not just within structure data but there's sometimes situations for example if you have a title on your page and we tweak the title and show a different title and the search results then kind of adopting the title that our algorithms generate and using that on your pages is probably the wrong idea So if you have the correct title that you think is the correct title on your structure data markup then I would just stick to that I wouldn't kind of artificially try to figure out oh Google thinks it's this therefore I will use that even though it's not really correct So if you know you have good names and titles for the markup already then I would just stick to that If you're not sure then looking up what other people are using is probably a good idea but you don't need to match exactly what Google is using John can I ask a quick question just throwing a situation at you if that's okay, you've got a web page it's got a number of images on it but those images are external resources so they come from another website but that website has got those images blocked in robots so what you effectively have is a situation where when the user looks at the site they see everything fine but when Googlebot looks at the site it sees a number of images on the page so if you look over there presumably in that situation I guess Google would treat those just as unresolved images and that might introduce quality type of issues might that happen or just Google not really care a whole lot about that sort of situation That's totally up to you that's not something that we would care about So if there are a lot of images where pages have a lot of images and they say I don't want Google to use my images and they just throw out all the images and that's totally up to them that wouldn't affect how we would show that page in web search it would affect of course the image indexing of those images because if we can't index the images we can't show them in image search but if you don't care about image search totally up to you That's great but there won't be any overall quality issues so Google won't for example look at all the pages on the site and go hang on a minute there's something is technically wrong here there's going to be an overall quality issue here No Just a bit of context which is that sometimes for example we have videos provided to us on products by external suppliers and those videos are hosted on external sites and they have like a default image to start with they block those images so when Googlebot looks at it it looks a bit of a mess but when the user looks at it it looks fine it's just to find out whether or not that's an issue or not but you're saying it's not an issue That's totally fine if you don't want the videos index or those images index then it's a block by robots text but that's totally up to you That's great and the other reason for mentioning it is that the Google customer reviews Badge at the bottom of the screen has unfortunately blocked quite a lot of its images in its robots.txt as well so it was just whether or not that was impacting us but I guess the point is it's not No That's actually fine too Thanks One last question Yes one last question well for me at least so still about the mobile topic and the hreflang is this something that is going to change when mobile first index comes or not specifically thinking for example about the canonical tag would that be an issue with the mobile first index and the hreflang should it then point to the mobile subdomains Our plan is to limit the number of changes as much as possible so currently the idea is that this should not change with the mobile first index so we're working on creating some documentation to create a reference so that you can point people at that but if you have the hreflang setup and the canonical setup pointing at the desktop pages then that could continue to just work on mobile pictures Okay thank you John just very very quickly Mobile first This might be a bit of a difficult question Is it going to impact organic only or is it going to impact anything else as well such as paid given that paid also looks at landing page quality landing page relevance and so forth so are you aware if any of the other side of Google will start focusing more on the mobile experience rather than the desktop experience I don't know so I suspect that some of this will kind of smear over and they'll be tempted to do more on mobile as well I don't know if that will align immediately or if that's something like oh search is doing this therefore at some point in the future we'll do that as well my feeling is that this is something that will just take place secondly so that search will focus on mobile first and then maybe ads will say okay mobile is also very important for us or maybe ads will say we need to keep these as separate as much as possible because people can do mobile ads or desktop ads I don't know what the details there will be alright let's take a break here thank you all for joining it's been great having all of you here good to see some new faces as well lots of really interesting questions I'll set up the next batch of hangouts probably for next week to get back into the same cycle we had before and if there's anything on your mind until then feel free to add it to those hangouts there or of course drop by the Webmaster Help forums and ask the experts there to get a first step into fixing anything or kind of solving any confusion that you have on your mind until then alright so I wish you all a good day or good afternoon or good evening or good morning depending on where you are and hopefully I'll see some of you again and then one of the next hangouts bye everyone see y'all