 All right. Welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what we do is these Office Hours Hangouts, where webmasters and publishers jump in and ask us lots of questions. As always, if any of you who are kind of new to these Hangouts that want to grab the first question or two, feel free to jump on in now. OK, hi. I've made a question here on the comment side. I don't know if you are now going to read. Go through those later, but feel free to get started with your question. OK, so let me just. Well, it's about how to make Google understand our heritage content. We have an outdoor trail site. It has a trail, and then the waypoint, and then photos. So we are trying to make the site maps. How can we put that information in the site maps? So Google understand that there's the hierarchical structure in there. I don't know if we can make some microdata or a structured markup in the site maps, or how can we? The location, specifically? Yes. No, I don't think there is a direct way to do that at the moment. So it used to be that we would have geo site maps where you could give us some geographical information for specific URLs, but that has gone away quite some time ago. So apart from mentioning the address, the location on the pages, maybe embedding a map of that location so that we can understand these are kind of the coordinates where you're focusing on, those would be the things that I would aim for. But as far as I know, there's no direct way to say this is the coordinate, and this is kind of information that we should be using to focus on for maybe recognizing what the user is trying to find better. So I kind of try to make sure that at least you have the location mentioned on the pages, that it's in clear text, that it's easy to extract the location and understand where that is on a map. But past that, I don't know of anything specific that you should be aiming for. So for images, if you have images on these pages as well, you can put images in the sitemap file. I'd make sure that you have clear alt text for images, maybe a caption below the image. Make sure that also your mobile pages have clear alt text and that they have kind of this context around the images as well. OK. And in the sitemaps, how can we put that images? There's a special sitemap extension for images that you can use. That should be mentioned in our help center. So if you search for something like images sitemap, then this is something additional that you add to the sitemap file per landing page URL where you say, these are the images on this page. And here's some extra information about those images. OK. And we have to put the source files of those image in there. OK. Thank you very much. All right. Another question from anyone who's kind of new to these Hangouts that wants to jump in. Otherwise, go for it. Yes. Hi. Sorry. I really like to use one of the popular do-it-yourself platforms, GUI, what you see is what you get platforms. And I, of course, make full use of the SEO page and title tags and descriptions and all that. And a lot of other things, too. And I use the I connect the Google products and things. But what my question is, is there anything inherent in the code or the nature of those do-it-yourself site building platforms that I need to be aware of that could negatively impact a site's search engine optimization, assuming that I'm taking advantage of those tags and things that I could be using in the on-page title tags and all that stuff and good content and all that. Yeah. So traditionally, people have kind of shied away from those do-it-yourself platforms because they thought, from an SEO point of view, they're not optimal. From my point of view, it's not something that you really need to worry about at the moment anymore. So that's something where from my side, when I look at these platforms, they create good web pages. Those web pages work in search. There are things that you can definitely use like that. The main issues that I see people talk about sometimes is kind of extending that do-it-yourself content page into something more interactive maybe. If you want to add more functionality to your pages where maybe you have a widget or something that's running on your server and you can let yours assign in and they can do something fancy on your website, that's something that's usually not supported. But if you're looking to bring your content out to the web, out to search, then for the most part, they just work. It's really easy to set them up. You don't have to worry about the technical details. You don't have to worry about maintaining the server or about keeping up to date with all of the updates that need to be done. All of that is kind of handled for you. So from my side, those are really a lot easier ways to get online nowadays than it used to be in the past. The main thing I would just watch out for is that these platforms use normal URLs so that you can copy and paste the address and put that into a different browser window and it just works. All of the platforms that I'm aware of, they do this just fine. So this is something that maybe five or 10 years ago was more of a problem. But for the most part, now when I look at the common kind of website builder platforms, they just work. I just wanted to say that a lot of these platforms are duplicated, John. And a lot of them sometimes, if internally different hosting providers, they offer you that. But if they ever, if you ever wanted to migrate that website, John, to another content management system, it's not possible. So there's no way. It's usually their own, and that's it. You won't be able to migrate something. I don't know. I mean, this is obviously something where if you're looking very far down the line and you have hundreds or thousands of pages, then that's something maybe to look into. But if you're just starting out, if you're creating a smaller website with maybe tens or maybe up to 100 pages, then these platforms work just well. And if you have a common platform, a commonly used platform, then for the most part, they have some basic import outboard, import-export functionality so that you can migrate to another platform. So it's not that you're locked in forever. But from my point of view, it kind of takes away all of these technical hassles that you'd otherwise need to worry about, where otherwise I basically, when I talk to small businesses and they say, oh, I want to go online, and you try to explain to them what it would take for them to set up a WordPress on a server of their own, they're like, I just want to put my stuff online. Like my opening hours, my email address, my phone number, my location, some photos from my shop, all of that is something that you can just put up on all of these site builder sites. Whereas if you want to set that up on your own server, then you have to think about, OK, so who's going to be installing updates? Who's going to make sure that my server doesn't get hacked? Who's going to make sure that my server kind of stays online, that it doesn't go down? All of these things, they're just kind of, they hold you back from actually focusing on what you're really trying to do, maybe running a business. So especially when you get started, that's something where from my side, I would prefer that people start with something where all of these technical hassles are taken care of. Agreed? I mean, as professional SEOs, as professional website builders, obviously, you're going to say, oh, but if I want to build the next eBay, I can't do that on Blogger. Of course, that's like, if you want to build a big e-commerce system, that's something you can't do with most of these kind of do-it-yourself platforms. There are some good shopping platforms out there that do take care of all of those kind of hassles as well, but that's something different than the common kind of copy and paste and put this image here and put that image there kind of tool. All right, let me run through some of the questions that were submitted. And as always, if there's anything on your mind, as I go through these, feel free to jump on in, ask more questions, ask for more details. We've seen a few examples where an official page doesn't rank at all for an official name. For example, BlueWidgets.com for the term BlueWidgets. The appearance of just being out of the index for branded terms lasts a few months, then almost randomly they start ranking on the page. How can this be explained? How does a page that doesn't even appear index for certain terms jump through the first page? So I looked at a few of these examples that Andrew sent over time. For the most part, this is something that from our side is kind of normal in the sense that changes happen in search, ranking changes happen, especially if you start out with something completely new, then it can take a bit of time for us to understand that. In this case, he mentioned some of these were movies, so one of the things that's kind of common to movies is if you search for the name, it's often something that already has been out there for a while. So I don't know, I can't think of any recent movie, maybe Star Wars. That's something where if you put a new Star Wars site out there, then obviously we will have all of these other pages already that have those words in the title that have those words on the pages that are relevant for those terms. And to understand that this new website is actually the official page for this term that we already know, that sometimes takes quite a bit of time for our algorithms to understand. So that's something where from my point of view, sometimes it does take a bit longer. Sometimes it takes a lot longer than I expect. And feedback is definitely welcome. So if you're seeing this happening with your sites, then that's definitely feedback that's useful for us. That's something we love to follow up on with the team. But for the most part, this can happen if you're trying to set up a new site for a term that's essentially already known. How should I help Google crawl and understand the hierarchical nature of the information on my site? I think we talked about this briefly, the outer trails. So can I also add there's also there are structured data for the articles and all that kind of metadata. Which one do you think fits the most for that kind of data? Because there's also a data set, but that's not only an article. I don't know if it's strictly for news and blog posts. I think that's a tricky one, because for the most part, we don't use that in search. So it's more a theoretical question, like which markup is theoretically correct. And if you talk with the folks that are working on schema.org or in the structured data communities out there, then they probably have a strong opinion and say, this is the right markup to use. This is theoretically the right thing to use there. From Google's point of view, from search side, if we don't show anything special for that specific markup, we probably don't use it. So that's something like article or blog post or data set. For example, these are things if we don't show them differently in search, then we're kind of taking them and find you're marking it up like this. That's really nice of you, but we're not using that to change your rankings in any way. And for the markup that we do use and do show in search, it's more a matter of changing the snippet. So that we see, oh, there are some reviews on this page. Therefore, I'll show the reviews in the snippet. But it's not the case that we would say, oh, there's rich snippet markup on this page. Therefore, I'll rank it higher. So it changes the way we show the search result, but it wouldn't change the ranking of those pages. OK. So it's something, I mean, if you're interested in this topic, I'd definitely go and chat with the folks that are working on the different structured data communities. Maybe they have some ideas that would work well there. But I just keep in mind that if Google isn't really showing that structured data, you're kind of providing that for yourself. You're not getting any additional search value out of that structured data. OK, thanks. I understand that grammar and well-written content is very important for SEO. But what would you advise on keywords that have search volume with incorrect spellings? For example, this word that I can't pronounce, which is probably why people can't spell it, if we wanted to rank for the incorrect versions as well, would Google downgrade our content if we put these versions on our content too? What do you recommend in these instances? So for the most part, we would recognize that this is a misspelling. And if someone searches for the misspelling, we try to kind of guide the user to the correct spelling. So that's something I don't know if we do that in this specific case. But it's really common that that ends up happening. You search for misspelling, and it shows the search results for the normal spelling anyway. So there's kind of no additional value in having that misspelling on your pages as well. From a ranking point of view, it's not the case that we would say, oh, this page has a misspelling on it. Therefore, we will rank it lower. So if you think this misspelling is something that makes sense to have on your pages, then go for it. If you think it's something that makes your page look less professional, because you're kind of showing a known misspelling of a word, then maybe you shouldn't use that. But from an SEO point of view, for the most part, we probably understand these misspellings anyway, and we can rank those pages regardless of how the user actually spells them. We identified a drop in traffic dating back to Panda 4.0 in May 2014. Wow. So we're improving our content to improve our score. If we were to go through category by category improving content, then would our rankings improve category by category as Panda gets lifted, or is a score, a blanket score, applied to the whole site? So for the most part, we've moved more and more towards understanding sections of a site better and understanding what the quality of those sections is. So if you're kind of going through your site step by step, then I would expect to see kind of a gradual change in the way that we view your site. But I also assume that if this is something that you've had low quality sites since 2014, that's a long time to kind of maintain a low quality site. And that's something where I suspect there are lots of different signals that are telling us this is probably not at such a great site. So that's one thing to kind of keep in mind there in that kind of going through your content now and trying to improve it is obviously a good thing if you care about this website. But I wouldn't expect to see any magic changes from one day to the next. This is something that's more of a really kind of a long term thing, a long term project where you'll probably see gradual changes over time, where you'll probably also see changes with regards to how users interact with your site over time. So some of that might be due to getting more traffic to your site. Some of it might just be due to users saying, oh, the site has actually gotten a lot better. I'll recommend it to my friends and kind of grow your traffic organically that way outside of just search. Joe, can you hear me? Yes, very. Oh, OK. Actually, this query was regarding last question that you read about wrong misspelling of the words. So if Google is understanding what is the correct spelling, what is the misspelling, then if I click on cheap flights, CHWEP, so why the search result is different for both of these words, like simply cheap flights, CHEA, and CHWEP? I don't know. I'd have to look at those queries in particular. Yes, but I have seen that the result are different for both of them. That's possible. I mean, this is something where we probably understand that they're synonyms, but we might still show them separately. In Canada, it's, I don't know. I mean, I don't know the specific query. So it's hard for me to say what exactly is happening here, but that's something where it's possible that we understand that these are synonyms, that we bring like the did you mean recommendation and that we still kind of have subtle differences in the way that we rank those pages. But from my side, I just keep in mind that on the one hand, there is their search. On the other hand, when users aren't on your site and they see that you're using all kinds of misspellings, they're not really going to assume that you're a professional business that is trying to sell them something legitimate. So that's something where I wouldn't just put misspellings on my pages just in the hope to rank for these misspellings. You kind of have to think about the full picture of users coming to your site, users seeing your content, reading your content, and then being convinced and then converting into whatever it is that you're trying to sell or provide on your site. You can actually create a lot of backfire where actually people will just email you telling you that you have a spelling mistake on your page. That's a good case, actually. That kind of means that people care about your site, about your business, about what you're doing, and they trust you enough to actually fix this. I think the more common case scenario is that people go to your site, they see that you're using all of these misspellings and they're like, do these people even know what this word means? Is this really a site that I want to trust with my credit card number? Is this a site that I want to kind of stay on, recommend to my friends? So that's kind of, I think, the more common scenario there. All right, let me grab the next one here. I'm trying to manage what information shows up on a knowledge panel, specifically my company's phone number. Is there a way to avoid showing the number? Because my customers will be served faster through my web page. So as far as I know, there is no easy way to avoid showing the phone number, but you can specify which phone number that you want using the structured data markup that we use for, I believe it's company pages markup that let you specify which phone numbers you want to actually use on your site. So that's something that you could be doing there. Can we have both a critic review and aggregate review markup on the same page? If yes, which one will be shown in the snippet? The reason I ask is I feel it's better to have both critic review and reviews on the same page rather than to separate them. If and when the mobile first index comes, is it OK to have slightly less content on mobile because of the screen size? So two questions, I guess, with regards to different types of markup on the same page. So I am not particularly aware of the details of the policies around the different review markups there. So I don't know if from a policy point of view you can just put those two on your site. But in general, when it comes to the second part of this question, which one of these will show up in the snippet, that's something where you have to assume that if you're providing both types of markup on a page, that Google's algorithms might pick one or the other. It's not the case that we'd say there's like a prioritization of markup on pages and we will show this above that, above that. It might be that we show this markup or it might be that we show a different one or that we show a mix. So if you have strong feelings about which markup you want to have shown in your snippet, then just make sure that markup is actually on those pages and not something that's kind of competing with the same real estate in the search results. With regards to mobile first index, yes, it's OK to have less content on pages because of the screen size. But just keep in mind that we will be indexing those pages based on the mobile version of the page. So if your mobile page doesn't have any content about what you're trying to rank for, then obviously that could result in those pages not ranking for that content because we don't see it there. So that's one thing to kind of keep in mind there. A really common scenario that I've run across quite a lot is that the sub pages collect a lot of cruft and they have a lot of extra content on them that you don't really need. Sometimes it goes so far that it's kind of like keyword stuff text that you put on bottom of pages and a lot of mobile pages don't have that. And from my point of view, those mobile pages will probably rank just as well because the primary content is the same and all of this extra cruft was kind of just weighing you down and being more ignored and actually used by Google at all. Can you clear the confusion regarding the update if it's towards the end of the year or beginning of the year for mobile first? I have no update on the date, sorry. Sounds good. Yeah. So we're still working on it. So it's probably not going to happen in January, February, March, or April of this year. But I don't know the situation. Hello, mama. How are the shit works? Yeah, it's not for me. So my guess is what will happen is we will provide you with more information about the type of issues that we've run across so far in our tests. And based on that, we'll give you more guidance on when we expect some changes to happen. It's also possible that we'll say, well, this batch of sites works perfectly fine on mobile first indexing. So we'll just switch that over and wait with the next batch until we're certain that they've been able to solve these problems. But that's something where we'll have more information kind of as time goes by. Right. And then it's not also like it's not you're not sure. Like this can still be a test for like Gary said, or if I'm not mistaken, where it might be just a test for like maybe three, four months. It's either you're going to go with it or either not, right? So it's still not even. Well, I wouldn't assume that it's going to disappear. So some variation of this is bound to happen just because we see everyone's using mobile phones. And if more than half of our users are using mobile phones, then it would be wrong for us to say we will provide search results based on a desktop version, but you'll see the mobile version. So that's something where we need to reflect what users actually see on the devices that they're using. And that shift is obviously not trivial. So it's not going to be hard, but I don't see any way around that where we'd say, oh, we will still index a desktop version. And even if 90% of our users are using mobile phones and may be seeing very different content, we will still rank based on our desktop version because desktop is the right version. So we kind of have to go with the times. And if everyone's using mobile, then we have to make sure our index reflects that. Very tricky. OK, thanks. Yes. In Search Console, I have over 2,000 pages that are showing not found crawl errors for broken links. My site is almost 20 years old and has lots of old articles with bad internal links. Should I try to fix all of those broken links or just ignore them? Will all these broken links internally or outbound going hurt my SEO? So I guess the more common scenario is we've seen a lot of old URLs on your site and we're crawling these old URLs and they're 404s. That's usually the scenario where I'd say, well, probably not a problem. If these links are still live within your website and you're still linking to pages that essentially don't exist anymore, then that seems more like a usability issue that you might want to kind of work on resolving. So from my point of view, that's something where I would use analytics to figure out which of these pages are actually commonly used, where are people actually, people themselves, actually ending up and getting stuck within your website while trying to click through two different parts of your website. And those are the type of issues that I would try to prioritize and resolve. And if you have a bunch of crawl errors that essentially nobody, no human is ever actually running into, then that's something where I'd say, well, this is just old cruft. You don't really have to worry about that. And there's also spammy 404s that I see a lot, where they're coming from spammy. So you have to be careful what you're 301ing or redirecting. Well, that's usually less of a problem if you're redirecting too much. But a lot of these spammy sites just link to broken URLs on your website. If you're seeing that no normal user is ever actually going to those pages, then I would just ignore them. There are ways you can clean that up with redirects. But for the most part, I would just ignore that. It's a lot of hassle to follow up on so many different pages and set up all of these internal redirects. It's probably not worth the effort from an SEO point of view to do too much into that. Obviously, if you're seeing that actual users are going to those pages, then it's not just an SEO issue. It's really kind of a usability issue that is probably worth resolving on your side. Then, John, if the URLs don't even exist, one's linking basically created a link to your domain for such cheap sneakers, which doesn't exist anyway, you're best off leaving those rather than redirecting because you don't want the bad traffic or the bad signals coming in or does it really not matter? I would just leave those as 404s. It's not that I'd worry about bad signals coming into your website, but it's just a matter of you don't need to worry about that. You don't need to do anything special for those kind of things. I just said that. Well, theoretically, if you did 301 them or create the thing, could it cause harm? Because you're then legitimizing what they're saying is happening, even though it's not. Probably not. So for the most part, there are two variations there. On the one hand, we probably recognize that this is a weird spammy site that's doing all of these links, and we probably ignore that already. So that's kind of the first step. We would still see those links and try to crawl them just to be sure. But for the most part, those aren't passing any signals anyway. The other aspect there is if you're redirecting a whole bunch of these URLs that essentially are four pages to one URL, then we would see that as a soft 404 anyway, and we would probably drop those out anyway. So between those two, you're probably covering 99% of those things. OK. All right. OK. Wow, now for the easy questions. What defines a good website structure on an e-commerce site from a not-so-good structure? I don't know. That's a tough one. So I guess on an e-commerce site, what generally is quite useful for us is to be able to crawl the website normally. And most of the e-commerce site setups that I've seen recently, they crawlable perfectly fine. So it's not something that you kind of need to do manually. It's more something that the e-commerce site does for you automatically. What is kind of useful, I think, is to have information about related products linked together. So if you go to a blue shoe or blue running shoes, and maybe you have some other running shoes on the site that are available that are cross-linked from there, so that when we start crawling in any particular part of your website, we can kind of branch out from there and understand the context of those pages a lot quicker. Then if we have to go up and find the home page or the category page and then crawl out from there. So that's kind of one thing I would watch out for there. Other than that, for most part, at least the e-commerce sites that I've looked at recently, they work just fine. And it's more a matter of making sure you have great content, making sure you have something really useful on your sites, than a matter of the internal linking structure. Ranking badly after an upgrade to HTTPS, but also cleaned up doorway pages, which seem to have been working. I'm thinking of putting those back in order to regain positions. I don't know, it sounds like a bad idea to put doorway pages back if you're aware of those having been problematic. My guess, without having looked into the site in detail, is that it's less a matter of the move to HTTPS, but more a matter of just general changes across your website that are taking longer to kind of be updated and reflected in search. With regards to doorway pages, I don't know what type of pages you had in the past. So it's really kind of tricky to say if this type of page would be OK or if this type of page would be against our web spam guidelines. And if the web spam team saw that, they would say, oh, we need to take manual action on this set of sites or a set of pages. So what I would recommend doing there is maybe taking that site and posting in the Webmaster Help Forum and getting some broader feedback from peers who can tell you a bit more about where they think your site might have problems, where they think your site might have potential to be improved, and where you can kind of discuss, well, I had these kind of pages on my site before. Are they OK? Or how can I get this information on my normal site so that it ranks for those terms, again, without using doorway pages? Hi. Hi. Oh, now, this is going to sound like a dumb question, but I admit I haven't been following this his past few weeks. So I'm looking for the latest update on that HTTP versus HTTPS in terms of higher ranking. So what is the latest? I think you mentioned earlier that you're not going to be ranking the HTTPS sites higher, but you originally were a while ago you were. So what's the latest on that? That hasn't actually changed in the sense that we do use HTTPS as a ranking factor, where HTTPS sites do rank subtly higher than the same site without HTTPS. But it's more a matter of a tiebreaker for us in that if we have two versions that are essentially the same, then we'll kind of default to the HTTPS version rather than the HTTP version. So it's not a matter of your site jumping up from page 10 to page 1. It's more a matter of us picking the right version of those pages. And that's something that I suspect will happen like that. So it's not the case that that will go away, that we won't kind of change the way that we handle HTTPS ranking. It's also unlikely to happen that we'll kind of boost that significantly, where we maybe say, oh, OK, we'll, I don't know, increase your ranking by a number of positions if you're using HTTPS. Just because from a quality point of view, we need to make sure that we're not viewing the quality of our search results through a factor like the HTTPS. So HTTPS is definitely something to do. It's definitely a best practice to implement on a site. But I wouldn't expect any magical search jumps from going to HTTPS. But you still see the significance now with the new Chrome updates that the HTTPS are not being seen. And besides the ranking, you should kind of weed that out and just say, hey, I mean, I need to go HTTPS. And then who cares about the ranking? It's just right now it's really important to even go HTTPS. Yeah, I think it's totally a best practice to implement. Anyway, if you're setting up a new site, then I would recommend just doing HTTPS from the start. That's something that with most hosting providers, it's usually not that much more effort to just go with HTTPS from the start and kind of avoid having to do that change sometime later on because HTTPS is not going to go away. It's not going to be the case that everyone is going to say, oh, I think it would be better if my website were kind of available in an insecure fashion. That's not like the direction that the web is going to be headed. It's we're really kind of thinking that HTTPS is where everything is going to go. Are all certificates OK since the whole Norton thing has been going on? So is it still you guys talking to them again? Or because a lot of the word there was a talk where you should have gone through it. I don't know what specifically happened with Norton there. But essentially, if your certificate works in a modern browser, it works for Google search. OK, great. All right. We're seeing the same aggregate service rating stars appear constantly in search for nearly all of a competitor's top product pages going on in seven months now. The review stars come from markup generated via TrustPilot's SEO TrustBox widget. Does the appearance of the service rating stars mean Google approves of the site-wide usage of this widget? We haven't done so yet because it doesn't seem to support the intent of the review snippets. So I don't know the specifics of this individual case there. So it's really hard to say. I don't know the specifics of that widget either. In general, you should make sure that any review markup that you have on your pages reflects the content on the page, not the business, not the web page itself, but the kind of what you're writing about there. So if you have a blog post about, I don't know, a specific laptop brand or whatever, then the review markup should reflect that laptop. It shouldn't reflect the blog post. It shouldn't reflect the website. It shouldn't reflect your company. It should reflect that specific product that you're reviewing there. And if you're not doing that that way, if you're using widgets that don't do it that way, then that would essentially be incorrect. So if you're seeing sites that are using it incorrectly, on the one hand, you can let them know. On the other hand, you can also use the Rich Snippets BAM report form in our help center and let us know about it so that someone from the web spam team can take a look and see, are they doing this correct? Are they not doing it correct? Do we need to tweak things on our side to better understand what these sites are doing? Or do we need to maybe turn off the root snippets for the site until they've managed to set up the markup properly? If you have an affiliate website and you use the same branches as the company you're affiliated with, how can you do this in such a way that you rank well? You obviously want to add value to be a good affiliate, but you also want to have the relevant information to help customers as well. So from my point of view, an affiliate website is just a normal website. And if you have an affiliate website and you're an affiliate using the same content as other sites have, then you kind of have the problem of any other website that reuses the same content as other sites have, in that Google will probably look at this and say, oh, I already know about this. I will skip this site and kind of focus on the other one that I already know about. So instead of kind of running into that situation, you really want to make sure that what you're providing is actually something unique and compelling that's kind of new to the web that's unique to your website that would be a good reason for Google to say, oh, people searching for this topic should really, really go to your website primarily. Your website should be the one that definitely ranks number one for this query because it's the best result for this type of query. And so that's kind of where I would aim. I wouldn't just say, oh, I will tweak my content subtly so that it looks slightly different. And otherwise, it's exactly the same affiliate content as everyone else. I'd really try to find a unique spin and say, this is the way to provide this information that users have been looking for. And this is going to be the single most important result in the search results when people are searching for this topic. Therefore, it would be a failure of Google's algorithms if it didn't rank my website as number one. So instead of trying to be within everyone else and say, oh, I also want to rank for this query like everyone else here, really aim for the situation where you're primarily really the main source of information for this topic where it would be a failure on Google's site if we didn't show your site ranking as number one. Hey, John, may I jump in with question? Sure. I appreciate you talking more about the mechanic that devalues invisible content. So specifically, what does visible mean? If a page has onload and made from opacity 0 to 1, would SEO not see that content? Should we avoid those sort of transitions? And Google Plus is actually a pretty good example of that. If you refresh the page, it'll slide in and fade up. But it seems like it might start with an opacity of 0.5. Thanks. So where is the cutoff or transparency with regards to hidden text or not? I don't actually know if we have a cutoff value where we'd say this is not enough. In general, we try to recognize situations where the content isn't visible at all. So this is usually something where you set the content to not being visible, to not being displayed on a page where maybe something else is on top of that content. That's something that we try to recognize and say, well, in this case, this content probably isn't the primary content on the page. And we'll focus on the other visible content on the page as the primary content. For the most part, that works fairly well. If the whole content kind of fades in subtly, then probably what would happen is we would say, well, this content is visible when we've kind of finished rendering the page, therefore we'll treat it as visible content. Even if it's just partially visible, if it's like somewhat still transparent, then from our point of view, when we finish rendering the page, it's there, so we can actually use that. This is something you probably mostly see when you're doing searches with regards to which content we show in the snippet, for example. So if you specifically search for a piece of text in quotes that's hidden on a page, then we'll still show that page because we kind of still know this content is on that page. But if you search for something more general, then probably we would say, well, this is not something where this page is really specifically about, therefore we'll show something that's more where this kind of piece of text is visible and more in the visible part of the page. So there's kind of this subtle transition there where from my point of view, I would focus more on what actually users would see when they click on that result. Do they find that content or not? That's kind of the guiding thought we had behind that, where we don't want to send people to a page where the content that they're looking for is essentially not visible by default. Is there a timeout involved with that if it becomes fully visible within 200 milliseconds? Am I OK? Is it just a snapshot of as soon as page loads? We don't specify a specific timeout for that because that can change subtly depending on how Google renders a page. So if we have everything cached, then that timeout will probably be a bit different than the situation where you have to start with a cold cache. So that's kind of why we don't have a documented timeout there, but we're looking more in the range of a couple of seconds rather than milliseconds. So if you have this subtle transition, then that's, for the most part, perfectly fine. That's not something I'd worry about. You can test that with the Fetch as Google tool to kind of see what Google would actually render from this page. And that gives you some insight into where that timeout is for that specific tool. And for web search, we tend to be more lenient than that tool so that even if something takes a little bit longer than that to actually render, we'll try to pick that up and use that. John, if site A has, let's say, 3.1 seconds and site B is 2.9 seconds, would site A rank higher than site B? No. At least not just based on those two differences. So I mean, for the most part, there are lots of signals that are coming up where we can't say it's like they're completely equivalent, except this page is like this and this page is subtly like that. That's a very artificial situation that doesn't happen in practice. But we differentiate between pages that are really, really slow and pages that are kind of normal. So if you're looking at a page that renders in a couple of minutes, then that's something where we might say, OK, this is really, really slow. Nobody has this much patience to wait for this page to load. Whereas if you're looking at 2.9 or 3.1 or even 10 seconds, then that's something we say, oh, this is kind of in the normal range. It's not. What are you guys going to take Google page insights to consideration into your ranking? When will you ever? Because it's just. Oh, you've been in these hangouts before. You know I can't give you information about what will happen in the future. So I don't have any time on back for God's sake. So I suspect that at some point we'll take a bit more of that into account. Maybe when it comes to mobile more, because that is obviously something that's even more exaggerated on mobile. But at least for the moment, we don't have any kind of announced plans to say, OK, we will take the Google page speed insights score and apply that to search as a ranking factor. Question. Yes. So you've talked about mobile versions of sites and ranking versus desktop versions. But when we're talking about just a site that's responsive instead of two different versions of a site, is there anything that? How is the responsive site treated? Does that make sense? Yeah. So for us, a responsive site is usually the best variation when it comes to mobile sites. That's the variation that we recommend. On the one hand, the same content is available in the HTML for both the desktop and the mobile version, which means we can pick up the same content, the same structured data, the same images, the same alt text on the images, the same captions. All of that is available by default on a responsive page. On the other hand, it uses the same URLs as the desktop site. So we don't have to worry about things like redirects. Which URL do we show in search? You don't have to worry about things like which one is rel canonical, which one is used for rel next, rel previous, all of that. You basically have one URL and it works for any device that people use. So because of those two main reasons, that's kind of why we recommend using responsive sites. There are also some other reasons that are attached to that, namely that it's usually a bit easier to develop and maintain because you don't have separate sites, separate code locations, separate content pieces to kind of worry about. It's one site and you can test it on your desktop and it'll still work the same way on your mobile phone, essentially, for the most part. Good. Thank you. That was my thinking. I just wanted to make sure I wasn't missing anything. So thank you. Perfect. Let's see. Can content placement and general layout of a page have a big effect on how the content is ranked? I know above the fold is deemed more important than below the fold, but is there anything else we should think of? With regards to search, we pretty much pick up the content as you have it on your page. The one thing that I would keep in mind here is not so much with regards to ranking better or ranking worse, but understand the context better. So if you have a whole bunch of different divs on a page and you're using your CSS to put them in different locations on your page, and actually, these divs are related in some sense, in the sense that maybe you're using them as a table type thing where you have some piece of text here and the div that's shown next to it has kind of the follow-up piece of content. But from an HTML point of view, those divs are completely different places on a page, then that makes it a lot harder for us to understand, OK, this piece of text here belongs to this piece of text here, and maybe this is a heading, and this is a piece of content that should fall under this heading. That's a bit harder to understand. So having something that is easy for us to understand the context of the individual pieces of content on your pages, that's kind of the thing that I would aim for there. It's less a matter of kind of like ranking high, ranking low. Kind of if you put this piece of text on top of your page and suddenly rank a lot higher, it's more a matter of kind of this subtle understanding of which pieces of content belong together. Is there any way to be able to show my phone number on the Knowledge panel? I think we talked about this briefly. Basically, there is a phone number markup that you can use on your pages to let us know a bit more about the preferred phone number that you have. I don't think you can suppress, which that you don't have any phone number shown at all. Let's see, is HTTPS even important, even if you don't sell products or require any type of login? Yes. So HTTPS has essentially three aspects that are important. On the one hand, it's authentication that you're really connected to the server that you think you are. On the other hand, the information that you're passing is encrypted. So even if you're not logging in, obviously if you're not logging in or not sending anything to the server, then that's less of an issue. And the third one is that the content that you're seeing is really the content that the website is providing. So it's not manipulated along the way. And that's something, from my point of view, that makes a lot of sense for any type of website. So if you care enough about your website to put something online, then you probably want that content to be actually shown to the user, not something slightly modified. So that's, in a nutshell, those are three things why we think HTTPS is important and why I think I would aim to use HTTPS on any type of site nowadays. All right. Kind of running towards the end of the time, there's one question from someone who I keep being muting, I guess, because there was a lot of background noise. If you want to unmute, feel free to jump in and ask away. Hi, John. Hi. Hear me? Yes. So I had a question. It's about treating one person. So one week, you might see the page, it's on the top page. If you do another week, it disappears, and it comes back. I mean, you can't understand the life of the guy who's doing that. Nothing's been changed on the page and things like that. It's been going on for over a year for maybe two or three keywords. And this is particularly in the US. We've got a geo-site, it's sort of in the UK. It doesn't happen in the UK, but it happens in the US. Hard to say without looking at the specifics there. So I'd recommend either posting in the Webmaster Health Forum or just sending you the URL and some of the queries where you're seeing this happening. And I can double check there. But for the most part, I don't think we'd have anything that kind of does this on purpose. But there might be different things that kind of come into play there that cause things to jump around a bit. OK, how do I send the URL to that on the photo chat? Function? You can put it in the chat or send me a note on Google+. If you just add me there, then you can send me a private note there too. I'll do that. Thanks. All right, one last question before I have to jump out of the room. What else is on your mind? Can you talk about Google Owl? Google Owl. The project, yeah, the project. I don't have anything specific about that that I can share. So it's whatever's on the blog? Yeah, so as far as I know that that was kind of to recognize the fake news type issues, I haven't been following up on what is actually happening. So it applies to blogs as well, right? I mean, it applies to blogs as well. I mean, OK. I don't really have anything specific about that, yeah. Right, just facts only, real stuff only. That's it from now on. Yeah, I mean, that's always a good practice anyway. Absolutely. All right. OK, John, maybe I'll last question, a quick one. We are planning to make both content and URL changes. Do you think that's better to make it separately, so gradually, or both changes at once for Google? I suspect you will see fluctuations for both of those situations. But if content changes is just like subtle changes of the content on your page, then probably less so. But if content changes mean you're changing your whole template, then that probably means some significant changes in the way that we understand your website. So for both of those, what I would recommend doing is finding a good time in the year where you don't rely on search traffic that much and to do them then. And really kind of take into account that maybe for a month or so, things from search will be a bit different. And give yourself enough time for things to actually settle down. So if you think that the template changes and the content that was on both, on two sites, on two pages now, it's in one, in a single one, you think it's better to make it at once? I think usually it's best to separate these things out so that you can refine what is happening based on the reactions that you see. But if you have to make significant changes on your site anyway, then it's hard to do that in two separate times because each time is already kind of painful to do. So that's something where maybe for practical reasons you say, well, I can't afford to do this twice. I need to do it once. OK. OK, thank you. All right. So with that, I need to jump out. Thank you all for joining. And I hope to see you all again in one of the future Hangouts. Bye, everyone. Bye. Thank you. Bye-bye. Thanks.