 Hello. All right. This works. Great. OK. All right. Welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do is talk with webmasters and publishers like the ones here in the Hangout. As always, I'd like to give those of you who are kind of new to these Hangouts a chance to ask the first couple of questions. If there is anything on your mind, feel free to jump on in. Well, yes. I would like to ask about how could we, for example, signal Google to record the pages that previously were gone with HTTP code for 1.0 and now feature new content again? I mean, does Google recheck or do we have to signal Google in some way to make sure Google closes the content again? We do try to check those pages automatically over time. But one thing you could do is tell us about that. So you can either, if it's just a handful of pages, you can do that in Search Console in the submit to indexing feature. That's one thing to do with just a few pages. If it's a lot of pages, I would use the sitemap file. And with the sitemap file, make sure that you have the last modification date set to the change that you made. So a sitemap file would be enough if we update the last modification date. Yes, exactly. All right, anything else before we get started? I have a quick question, John. OK. There is a large site with about 1 million pages. And the structure basically is kind of flat. With the change in the internal structure, there's probably going to be a lot of orphan pages that are right now indexed, basically. Is that a problem if we left out, I don't know, 10,000, 20,000 pages that basically are not going to be linked from the site anymore, but they're still going to be in the index? How Google will treat those, as far as indexation, as far as, I don't know, seeing the site all together. Again, those not being linked anymore. Do they contain content that you want to have indexed, or are they basically removed? Yeah, we don't care about that. They will contain content, but we don't care about that content anymore. OK, so you don't care if they show up in search or? If they show up in search, that's good. I mean, it's not like it's going to hurt. OK. I'm just thinking, maybe it's still some kind of danger. And I was wondering, how will those still be crawled at some point? Yeah, so what will generally happen in a case like that is we won't assume that these pages are that important anymore. So we will keep them indexed for the most part. Maybe in some cases, not always. But for the most part, we will keep them indexed. We will keep recrawling them to see if there's anything new there. And they can show up in search. But if we don't find any links at all to those pages, then we assume that probably they're not that critical for your website. So it would be possible that at some point they will just be flushed out? It can happen. I mean, indexing is never guaranteed. So that's always an option. But I think if they're not linked at all, then it can happen that they fall out of the index at some point. It probably depends a bit on the history of those pages. Were they really important in the past? Or were they just on your site and nobody actually used them? So that's something that should go anyway. Short follow-up question on this. Does it affect in any way the so-called crawl budget? So will other parts of the site be less often crawled just because Google boot is spending time on those $10,000, $10,000, or whatever the number is? I mean, if we have to crawl them, then we have to crawl them. And that's something that we have to reserve some resources for. But in general, what happens is we focus on the main pages of your website when we crawl those and make sure that we're picking up all of the new and important content on your pages. And if there's time left over to crawl more from your website, then we'll cover pages like that. Pages that either we haven't looked at in a long time, that maybe have returned 404, or that aren't linked that well, that aren't seen as being that important for a website. So it's not that they're pushing the important pages out from being crawled, but more that if we have time, then we'll try to get through those as well. And one last question that's followed for this one. Would you put them up? Would you spend time, a lot of time, finding, sporting them, and I don't know, set them to 404 or something just to push them out? Or let's assume it's like maybe 10% of both are in the global. I really don't know. It really depends on the type of pages that you have and what you're trying to do there. From a personal point of view, I try to keep things clean and to either say these are important pages for my site or these are pages I don't need to have indexed on my site. Cool. Thanks. Sure. Can I ask another question, quick question? Sure. Well, we have a multi-lingual site in more than 20 languages. It has its own subdomain, OK? But the content is all user generated and the user usually only writes the content in a single language. So what would be the correct setup of HREF lines, canonicals, and this stuff? Because is it OK, for example, if we include 22 tags of HREF line tags? And then we point one canonical tag to the language in which the user generated content, the main content, is written? Or so we use the HREF line X default? Or can we mix them up? I don't know. I mean, what's the correct setup for this case? Yeah. So I assume you have the user generated content in one language and the boilerplate, the rest of the website changes in different languages. Yes. Yes. So you can use the HREF line markup for that. I think that's a reasonable thing to do. I would not use the canonical to point at any one particular version because then the other versions, they drop out of the index. So you can use the canonical within each language so that you have a canonical for English, a canonical for French, or Japanese, or whatever you have. But don't mix canonical across different languages. Because if you mix the canonical across languages, we won't index the other language versions. So we will lose the translated website version in our index. So we shouldn't use canonical? Is that what you're saying? And not canonical across different languages. So don't have the English version have a canonical for the French version, for example. The English version can have a canonical for the English version. And the French version has a canonical for the French version. But not across the line. Even if it's really the same page, but with boilerplate translated or not in this case. That's a kind of an edge page, you know? The numeric generated content is already in one and one. Yeah, so it kind of depends on I think it's something where I can see both versions making sense with the hreflang. And each of these languages being indexed individually, then someone searching in English, if they were to find this page, they would see the English boilerplate version, even if the content itself is in Japanese or whatever. So that's something where sometimes that can make sense. I don't think that's something that you absolutely need to avoid. If you really think that users should only find the original language with the original boilerplate version, then that's something you can decide and say, with the canonical, I choose this specific version. OK, OK. Thank you. John, can I have two more questions? I haven't been in the Hangouts for some time, and now I'm taking advantage of it. All right. One of them is if you have an answer box for a question, and basically you're like position zero, let's say, how does it show up in search console? So let's assume that that page is actually ranking kind of ranking for that on position two, for example. But you also get the answer box. How does search console shows in search analytics the data for that? Is it position two? But the CTR is going to be way higher anyway. We show it as the top one that you have. So if you have multiple entries on the same page, then we show the position as being the top one. So in the case of this where you have a featured snippet and maybe your website is ranking as well, then we would show the ranking of the featured snippet. There's a really good Help Center article, actually, on this that has all of these different variations, like what if you're in the side? Or how does it count if you're in the images and all of these? So I would look for that and double check there. So basically it's position one, like search console is showing as position one. Yes. OK. Thanks. All right. Let me run through some of the questions that were submitted. And as always, if you have comments in between, feel free to jump on in. And I'll probably get some time towards the end to answer any new questions that might come up. Let's say I want to rank for the query, how to lose weight fast. Is it vital to mention this exact query in the content of the page? Or is it enough to mention these words which form this five-word query separately? And Google can figure it out without using the exact phrase in the content. For the most part, we can figure these things out fairly well based on the content of the page. So it's not that you need to explicitly mention all of the queries that you want to rank for in a phrase on the page. We can try to figure out what these pages are about. So even in a case like this where you have a how-to query, that doesn't mean that how-to is absolutely seen as a requirement on a page for this page to rank. It might be that this is a page about losing weight. And it mentions losing weight. And maybe quickly instead of fast. And all of these different synonyms and all of this can still rank fairly well for a query like this. Obviously, this specific query is probably very competitive. So just by mentioning some of these words on your page is not going to make your page rank number one. There are lots of people that have probably been working really hard on trying to rank for this kind of query. And some of these sites might be really good. So that probably is going to be a hard one to just jump in. So John, just a small follow-up. The only confusion in synonyms and exact match word is that people think that if I am using exact match on the page, Google is giving me more weightage as compared with synonyms. If I am using a Google, understand synonyms. So does Google give equal weight when it understands that this is the synonym of this word? And one website has exact match. So does Google prefer both of them or give more value to one and less value to another? For the most part, I believe we can treat them equally. So there are obviously different things where depending on the query, there might be some more clear synonyms and there might be less clear synonyms. So that's obviously one thing that comes into play. It's not the case that every synonym would just say, oh, these are exactly the same words. They have the exact same meaning. Sometimes there are subtle differences. So I see this, for example, in German every now and then in that in German they have the umlauts, those dots on the U or the O. And some people search with umlauts. Some people search without umlauts. Some people search with the rewritten version of those words. And sometimes we recognize those as synonyms because we see people are using them interchangeably, but not always because sometimes people try to search for things in a different way and they expect to find different results. So just because these might be synonyms in a dictionary doesn't mean that we would treat them exactly the same in search. So this kind of all comes down to our general guidelines on making sure that your content works well for your users, that it's easy to understand, that it's written naturally. And if you focus on making things natural and easy to read, then usually you've kind of covered that ground already. And then you don't focus on just those specific keywords. You focus on providing context and providing extra value. Um, oops, I just missed a question. I think there was one of do you detect commerciality of documents or number of ads in a document for the document that contains links to other sites be treated as if it had many ads? We do try to detect the ads on a page when it comes to understanding what's about the poll. So if we recognize that when a user goes to this page, they essentially just see ads for other websites, then we might as well send them to one of those other websites directly rather than kind of having them jump through this extra hoop. So that's one thing we do look at. But otherwise, it's not the case that we're trying to detect. Is this a commercial website or not? Because obviously running any website costs money. And somehow you have to kind of cover those running costs. So that's not really something where we'd say yes or no. This is commercial or not. And with regards to links on the page, just because there are links to other sites doesn't mean that we would assume that these are always ads. I have a lot of pages on my website that rank number one for many queries for a long time and receive lots of search traffic. Does this mean that these pages are high quality? Are final relevance for the user and quality considered synonyms in this case? Could I consider a page that receives lots of search traffic daily for a long time and ranks number one to be high quality as well? So first of all, I'm kind of worried that you have a website and it's ranking really well and doing fairly well. And you're not sure if it's actually high quality. So this is something that you, as a subject matter expert, should be able to judge much better than I would be able to judge. So just because it's ranking highly doesn't mean that it's automatically high quality. Sometimes there are really weird things that are ranking in the search results. And just because they're ranking doesn't mean that they're high quality. But maybe this is something that users find relevant. So all of these things kind of come together and we try to determine the ranking based on that. So it's not that we ignore the quality of a website, but just because it's ranking doesn't mean that it's high quality. I have 2,000 words article with lots of comments and a whole page has about 6,000 words. What should I look for in regards to keyword stuffing? I want to make sure my page isn't stuffed with keywords and isn't penalized from an on-page point of view. So usually what I would recommend doing is making sure that it's really natural text, that it reads easily. One test that I've heard for a really long time that people sometimes recommend is to take the content of the page and read it aloud to someone. Read it aloud to someone on the phone, for example, where they don't have those additional cues. And if you can read it without laughing too much because it reads so weird, then probably it's a pretty normal page. If a prospective client were to come to you all you up on the phone and you read them the website that you have there, would that be enough to convince them? Would that work for them? Or would they just think, oh, this guy is reading this robot script that doesn't make any sense in my language? So that's kind of what I would aim for. It's not so much that you need to find a technical tool to determine is a keyword stuffing or not. Is it enough words on a page or not? Rather to really think about, is this good content? Is this something natural? Is this something that when people come to my website, they understand what my content is about, what my service is, my business is about, and they kind of see what they've landed on matches their expectations. On the subject of keyword stuffing, having keywords in the URL, is it penalized in some way? I mean, for example, no? No, that's perfectly fine. That's something that I think can make a lot of sense in terms of usability. So if you have keywords in the URL and users recognize those keywords, then it makes it easier for users to share those keywords. That's usually fine. The one place where this sometimes drifts off is that the keywords in the URL is one of the primary factors that people think is important for a page, and then it just stuffing lots and lots of keywords into the URL rather than actually focusing on something that makes sense and is easy to use for users. So from that point of view, putting keywords in the URL is fine. Using URLs that have text or words in them is perfectly fine. Just adding tons and tons of words to artificially put those into the URL, I think that harms usability more than it helps it. Thank you. Thank you. When I'm writing your view of a product, is it enough to mention the name of the product just once in the heading, or should I mention it multiple times on the page? I don't want to keyword stuff and mention product name multiple times just to make it more relevant for search engines. From Google's point of view, you don't need to keep stuffing those words into those pages. That's definitely not something you need to do. Again, I would focus on making things natural there. And sometimes it does make sense to repeat the product name or the main selling points a few times, because that's what people do when they want to read something and when they want to remember something. But I wouldn't do this for search engines alone. Is the homepage of a particular website usually considered to be a document with the highest information retrieval score for a query that is the name of that particular website, like when users search for a brand, brand name of that website? I imagine focusing on information retrieval score doesn't really help that much. In many cases, the homepage is pretty much the landing page that users expect to find when they search for a name of a website, but it's not always a case. And in situations where it's not always a case, that can be completely normal, too. So sometimes maybe some specific product on your website is the one that everyone knows about and that everyone writes about. And actually, your business homepage isn't really that relevant when someone searches for that brand name or that website name or that product name. So it's something where often these overlap, but it's not a requirement. It's not something that you need to fix if you see that not happening with your specific website. From Amit's 23 questions, do you check directly if the article is overly positive about a product and doesn't mention negatives? So should it rank lower or should we lower its quality or relevance? No, not that I'm aware of. There's probably not something that we would do automatically. And even when you look at that manually, sometimes some products just have a lot of positive things to mention. So just because it doesn't have anything negative to mention doesn't necessarily make it bad, but obviously as a user, you want to be critical and make sure that you're looking at the whole picture. And as a website, as someone who's making a website, it really makes sense to have the full picture there. When you calculate keyword stuffing, the motion, oh, wait a second, yes. No, no, please proceed, I will ask a question. Okay, okay, we'll have more time for questions afterwards as well. When you calculate keyword stuffing, the motion, do you look more on the main content in comparison to the comments section or would you see all of it together? So disregarding the keyword stuffing, the motion part, we do look at the whole page overall and we assume that if you're publishing this page as a webmaster, you stand behind the whole page. So that includes the main content section, that includes the comments on a page as well. We do try to understand where different parts of the page are, just so that we can better figure out which part is really the main content of this page. But if you're publishing comments on your website, if we're able to index those, then we see that as part of your content. So if people in the comments are leaving spammy comments or really leaving things there that essentially degrade the quality of your page overall, then that's something that we would take into account. So just because someone else has left those comments and not you as the owner, doesn't mean that we ignore it. How can I keep tracking a site's performance for a specific keyword, which report shows that best? The search analytics report in Search Console is probably the one you're looking for. As I mentioned before, there is some help center content on the search analytics report that gives you a bit more information as well as an article that tells you specifically when it comes to ranking what it is that we track in that search analytics report. Can too many nofollow links cause SEO problems? I'm planning to use Pinterest to generate direct traffic to my website. It creates a lot of nofollow links. Can Pinterest harm SEO? No, that wouldn't be a problem. So nofollow links are essentially taken out of our link calculations. We don't pass page rank through them. If users can go through those nofollow links and find your content, that's perfect, right? People are coming to your website and hopefully finding what they're looking for, so that's a great thing to have. On the other side, as well, if these links are all nofollowed, then these are ones that we wouldn't take into account in a positive way either. So make sure that people, when they come to your website, they can also share your URL directly. They can link to your URLs directly so that you do have kind of these multiple sides where you could be getting traffic from. When I look at my cross-stats, it says Google is crawling about 700,000 pages a day. However, when I look at the number of pages index per day for my site map, it only increases by about 2,000 per day. I have 2 million pages, so how many years will it take for everything to be indexed? That's a good question. So there are lots of aspects that come into play there. One thing to keep in mind when looking at the number of pages crawled per day, when you look at that in Search Console, it includes everything on the page. So this includes embedded content as well, meaning CSS files, JavaScript, images, all of that can be included there as well. So if you're looking at 2 million HTML pages, then obviously there's a lot of embedded content in there too that also needs to be crawled. Additionally, when we're looking at the pages that we crawl, we crawl pages at different rates. So some pages we think are really important or we see that they're changing frequently, then we crawl them faster. So maybe within those 700,000 pages a day, there are a lot of pages that we just re-crawl every day because we think maybe there's something new happening on these pages. So it's not that you can take 2 million pages, divide them by 700,000, and get the number of days. With regards to the sitemap file, one thing to mention there is that it focuses on the exact URL that you have in the sitemap file. So the exact URL has to match the URL that we picked for indexing. And then we count that as indexed for the sitemap file. So if you have a problematic URL structure on your website, if you link to one version of the page and have a different one in your sitemap file, or you link to one version of the page and the rel canonical has a different one and the sitemap file has another one, then these are all multiples that first we have to crawl and then we have to figure out which URL we have to index. And if we pick a URL to index, that's not exactly the one in your sitemap file. It won't count in your sitemap file. So in a situation like this, where you have a lot of pages that you want to have indexed, I would really, really make sure that you're using very, very clear URL structure, that you're really making sure that your internal linking uses exactly the same URL as you have everywhere else. The rel canonical matches exactly those URLs. If you have hreflang, those match exactly the way you use them everywhere else. So that when we find pages on your website, we know exactly which one to index. And we only have to crawl one of them instead of multiples to find which one is the one that you want to have indexed. So that's one thing to keep in mind there. In general, the other aspect of getting so many pages indexed is that this does take quite a bit of time. So that's not something where we can just go off fetch 2 million pages from your website and index them immediately. Sometimes that's just from a technical point of view, from a kind of natural point of view. It can take quite a bit of time to crawl and index that many pages. And once we have them indexed, some of these might be updated multiple times a day. And others might be updated once a half year or so. So even when they're indexed, it really depends on how important we think it is to update these pages quickly. So I wouldn't focus just on the raw number in a case like that, but rather look at the traffic and see if we're indexing the right ones. If we're not indexing the right pages for your website, then that's something you can help guide us by creating a clear website structure where your important pages are kind of higher up in the hierarchy on the web page. One short question on this. You just mentioned that some pages are, of course, hit once every minute or second or so, and some even once every six months or so. Is that an indication of quality from Google's perspective? So we can identify that based on the log. So if you see that, I don't know, those pages are only hit once every six months. That means that Google sees those as lower quality overall? Call that? There are various things that come together when we determine how often we crawl a page. So we do try to take quality into account as well, but we look at things like, how is the internal linking? Is this a page that changes frequently, for example? And all of these things kind of come together. And based on that, we try to determine which page gets crawled with. But it's not pure quality. Sometimes it can be that this is a really good reference page, but we've noticed it just never changed in the last 10 years. So there's no need to re-crawl it every day. It's kind of a waste of resources on both of our sides. So that quality goes into that somehow in the sense that if we recognize a really low quality site, then maybe we won't crawl that much on that site. But it's not the only factor. OK, makes sense. And also, since we're on this subject, is the Search Console Index Status more accurate than, I don't know, Site Column, for example? I know Site Column is calculated on the fly, I think. But there are sometimes really big differences between the Index Status in Search Console and the Site Column data. Yeah, I would definitely use the Index Status in Search Console over Site Column. So Site Column is optimized for speed and not accuracy. And sometimes the of-about count that you see there might be off by multiple orders of magnitude. So that's something I really wouldn't use the Site Column counts for any diagnostics purposes. The best one to use, from my point of view, is the Site Maps Index Count. That's extremely accurate. That's extremely accurate, yes. But like I mentioned before, it focuses on exactly that URL. So if you have a kind of a messy website structure where you have sometimes upper case, sometimes lower case, sometimes with a trailing slash, and sometimes with slash index HTML, then that makes the Site Map Index Count a little bit harder. Because we don't know which URL you want to have counted. And then we count only the exact URL rather than if your content is actually indexed. Yes, versus HTTP and so on and so forth. Yeah, exactly. But if you have a clean website, if you have a website that you've been focusing on to make sure that the URL structure is clean, then the Site Maps Count is really great. Because it tells you of the pages that you explicitly say you want to have indexed, how many of those are indexed. With indexed status, it can be like we indexed 5 million pages, but you have no idea which ones those are. If those are important ones or if they're duplicate, you kind of see the curve and you can recognize, oh, it just dropped a really big, big amount, so maybe something is wrong. But with the Site Maps Count, you can really see of those pages that I submitted there, how many of those are indexed. Also, with the Site Maps, you can create Site Maps for different parts of your website. So you could put all your products in a Site Map file, your articles in a Site Map file, and then you can track indexing of all of those parts separately. And the index status also contains the pages that, for example, are blocked by Robots 60 or that you still have them somehow counted? It has an option to show those. I think like a checkbox for advanced. OK. John, can I just ask you a question about something you mentioned right before those last two questions? You were talking about Site Hierarchy and URL structures. And it made me think of something. Like, I'll use automobiles as an example, because it's the simplest one I can think of. We had an old Site Structure where we had, say, trucks at the site level. So it was our site, example.com slash trucks. And then later on, years later, we added auto. And then we have, say, cars as auto slash cars. And we were always happy with our rankings and still are generally. So we've always been paranoid about following one system. Would you recommend going back and flattening that structure out or putting everything under sort of a main category? If it was yours, would you mess with it? Would you take your most popular categories? Say if 90% of your site uses one of those categories, would you have that right at the site level and have things that are maybe more obscure, like boats under a subcategory? How would you deal with that, generally? So in a case like that, where the structure subtly changes or your focus as a business, as a website subtly changes, I think it can make sense to restructure that to put your more important pages higher up in the hierarchy so that they're easier to find from the home page, for example, when users are clicking around. The one thing I wouldn't do is just artificially changing the URL structure itself. Yeah, and I don't mean navigation. We have no intentions of changing our navigation. I'm just talking URL structure itself. Does that have any bearing on anything whatsoever? Is it more to do with just links? Yeah, I wouldn't change the URL structure. So if you're just tweaking things, then I would just leave the URLs the way they are. Looking forward sometimes it makes sense to change the URL structure for maintenance reasons. If you're moving to a different infrastructure, or if you say, I just want to reorg completely, but I wouldn't change the URL structure just for subtle changes. It also goes for things like moving from a parameter-based URL to a keyword-based URL. That's something where when you make changes like that, we have to understand the website again. And sometimes that does result in a period of the drop on search, where we're just like recrawling everything, following redirects, and trying to figure out how do these pages relate to each other. And that's more visible when you make any kind of URL changes. Following up on this question, would converting or URLs that only have an ID, for example, to a more user-friendly URL and using then a 301 redirect, would that affect the rankings as well? Would there be a drop in the? Yes. So probably you will see a drop in the search results for a period of time until we can recognize your site again. So I don't think you would see an advantage by going from an ID to a keyword in the URL. So I wouldn't do it just for SEO reasons, but if you have really strong reasons for a usability point of view, then maybe that makes sense. But it's important to keep in mind that any URLs changes that you make on a website, especially bigger, broader URL changes, they do require that we first understand the website again. And that can result in a lot of fluctuations for a period of time, where maybe, I don't know, to take a number maybe a couple of weeks where things are just fluctuating and not really in a stable state in search. So if you want to make changes like that, I would do that at a time when you don't need the search traffic that much. I'm asking because we are switching from HTTP to HTTPS as well. And since there's already a change of URL, we thought maybe we could use this opportunity and make the original URLs a bit more user-friendly. I don't know. Would that be a good time? Would this be a good time to do this? Since we are moving already, and there would be a change of protocol? Yeah, so it's difficult. Because if we just see a change of protocol or if we see something like a domain move from one domain to another, and everything else remains the same, then it's a lot easier for us to just say, oh, all of this belongs to here. We don't even need to look at everything. We understand this relationship fairly well. Whereas if you're changing the URL structure, the way the URLs are formed, then we have to understand that again. We can't just blindly say, everything HTTP is HTTPS. So that's something I think it's a good chance to combine those two. But it's good to keep in mind that it's not just switching it over. And the next day, everything is fine. Thank you. All right, let me grab some more of the questions. And we can do a quick question. Sure. Yes. First of all, thank you for doing this. I don't know how long this has been going on, but it's a great opportunity for us. I have a domain. It's my name JulieStrong.com. But I have two businesses. They're related, but they're completely different audiences in different services. And I want to use JulieStrong.com for both. My thought was to use the subdomain for the second business, like, for instance, it's just x.julistrong.com. But the concern is, would that affect indexing, ranking, or would it have any other adverse effects to have two businesses and one being a subdomain? I think that can be perfectly fine. That's not something I would discourage. I think that's perfectly fine. From my point of view, I would see it more a question of your long-term direction, how you want to handle these things. If you're thinking that these are going to remain kind of related, then keeping them on one domain is fine. If you're thinking these are going to diverge in very different directions, then maybe it makes needs to have separate domains for them from the start. But it's perfectly fine to start on a subdomain and then kind of decide, over time, how you see things. OK, well, Google interprets it as one website or two. I can't tell you, because it kind of depends. So in many cases, we can understand that subdomains are different. So if they're really different businesses, then probably we will recognize that. Sometimes subdomains are used just for variations in that they have a category as a subdomain, and the main domain is the normal domain. But from a practical point of view, I don't think you need to worry about whether Google treats this as one domain or not, because we will try to rank those pages individually. Thank you. All right, I'll run through a few more of these questions, and then we can open up for more questions directly from you all as well. I'm converting to HTTPS for one domain and for subdomains. So I have to change anything in Search Console or in Google Analytics. So in Search Console, the main thing I would do there is make sure you have the HTTPS versions also listed in Search Console, also verified, so that you can look up the data that's available there. I believe in analytics, you don't have to do anything. I'm not an expert on analytics, but from what I've heard, you don't need to do anything there. With regards to each subdomain requiring their own IP, I'm not sure how that's handled from a technical point of view. I know there are ways that you can use a shared IP for a certificate, but it kind of depends on what audience you're talking to. They all have modern browsers. Then they can work with this shared setup. I believe it's called SNI. If a lot of your users are using really older browsers, then maybe you need to do this with the separate IP addresses. From an SEO point of view, using the same shared IP address or different ones is exactly the same. Can blocking spammy Russian referrals from accessing my site increase ranking? I don't think it changes anything at all. So if you're blocking users from individual countries, as long as those are not users where Googlebot is, or countries where Googlebot is crawling from, then that shouldn't change anything with regards to SEO, with regards to search. Obviously, those users won't be able to see your content. They won't be able to recommend it. They won't be able to link to it either. So there are some drawbacks there by just blindly blocking individual countries. With regards to referrals, I imagine you're mostly talking about the data that you see in analytics. And what I've seen, there's some really good blog posts on setting up analytics so that these kind of spammy referrals are blocked regardless of which location they're actually coming from. Do OG video specific tags increase a page's chance of getting on blended search results? We do try to recognize videos within pages. And when we recognize their videos embedded on a page, we can include that in video search. And that can be shown as a part of the universal search results where we mix different types of media together in the search results page. So it's not this specific tag. That's the important part, but rather that we can recognize there's a video on this page. And there are different ways of embedding a video. You can also use a video site map to let us know about that. And when we recognize there's a video on a page, we can show it in the video search results in that section of the search results. We sell tickets for performance arts. Obviously, there are specific dates for these performances. Google results routinely show events that have already taken place and really have no use after the fact. How can we prevent them from showing up once an event passes? So I guess that's kind of tricky in the sense that we don't really look at the date and see is this date good or not. But you can control that on your side. So one thing you can do is use a no index tag after you're sure that this event is no longer relevant. You can also use the unavailable after tag, which is a kind of a rarely known robots meta tag where you're essentially telling us, on this date, this content is no longer relevant. And especially for events, for performances where you know exactly when that date will be, you can specify that ahead of time and say, well, on this date, this content will no longer be relevant. You don't have to keep showing it in search. So that's something that we would take into account there as well. We have a strange website problem. For some reason, our site randomly creates new URLs. And recently, we found it had created them in topics nothing to do with our business. We are a rental site, but these URLs appear as site schools, learn English, or similar ones as if we were a language school. We then found lots of new links pointing to a site. We've automatically 404 the pages. But could there be something sinister going on? And could this harm us in any way? So from just an outside perspective, not knowing the site itself, this sounds like your site might be hacked in the sense that perhaps someone is somehow accessing your server and placing content on your website that they're using to rank for in search results. So specifically, if you see things like the content being very different from what you're actually writing about, then that might be a sign that someone else is placing this content on your website. So what I would recommend doing here is kind of as a first step, go through all of our hacked content in our Help Center on the webmasters page, which I think is google.com. slash webmasters slash hacked. Kind of go through those videos and really double check to make sure that this is not hacked content, that this is not some hacker abusing your website and placing their content on your website. So kind of as a first step, another thing that I sometimes see is that sites have dynamic content based on the queries that you submit. So sometimes you have search results pages within a website, and people can go to search results pages and they search for a boat or they search for a car, even though your website isn't about a car. And your website generates a URL with that query in there. It generates an empty search results page. But it generates a URL that could theoretically be indexed. If you're seeing something like that, if those weird URLs are kind of your search results pages, then what you could do is just block your search results pages from being crawled in the robots.txt file, which is a really quick way to kind of block those things from causing any problems. In Search Console, when updating to a new theme, web pages render blank or white. The theme author insists it's not related to the theme, suggests how to troubleshoot this. Viewers need to see the pages. They're not trying to make any content invisible. So I think this depends a bit on why you're seeing a blank page. Usually when we switch to a new theme, we can pick that up as well, and we can work with that pretty much immediately with the fetch and render tool in Search Console. If you're seeing a blank page or a white page there, it might be that we're not able to actually index your pages. So this is something to kind of watch out for. Usually what happens is, below the fetch and render tool, it has a list of the blocked resources. And maybe one of the JavaScript or CSS files is blocked there. And if it's blocked, then we probably can't render the page properly. So that's one thing I would look at there. If you're not able to figure this out, and especially if it doesn't go away after a day or so, I would strongly recommend going to the Webmaster Help Forum and getting advice from other people, because this is something that sometimes happens. And when it does happen, it's good to kind of clean that up as quickly as possible. We moved our website to HTTPS, but our breadcrumbs are still shown in Search After Migration. Also, there's no error for breadcrumbs in Search Console. So what's up with this? This is actually a problem on our side, I think, assuming this is the case that I remember, in the sense that when we show breadcrumbs in the search results, we don't show the protocol. So that can look like we're not indexing the HTTPS version. However, if you hover over the URL, you'll see probably we're linking to the HTTPS version. We're just not highlighting the protocol in the search results. And from what I understand, the main reason we don't highlight the protocol there is because of space, because we want to show the breadcrumbs, especially if you're providing breadcrumbs for us. We want to have enough room to actually show those individual breadcrumbs. And then we kind of save those extra characters that we'd otherwise use for the protocol. All right, still have a bunch of questions left, but just a few minutes. So maybe I'll just open up for more questions from you all. If there's anything else on your mind that I haven't covered that I need to look at. John. Yeah, John. John, there was just one confusion in my mind to be clear with you. In one website, what I see is in trouble websites, I have been seeing it for a long time, that in flight from X to Y, what they do is they just throw all their inventory, like X of airline from this to this and its prices. On the other hand, some websites are using SEO content, like just to tell search engine what type of things they are using instead of that inventory. I have just pinged a kayak URL in a chat and also a sky scanner URL. First one is showing all the inventory or all the airlines list. And another one is also providing some SEO content. From Google perspective, what type of things should be preferred? Because I am really, very confused in these two. OK, I would have to look at these pages in detail to see what exactly you mean. So what do you mean with SEO content, for example? Yeah, I have one option that I just throw all the inventory to the users, thinking that let us just provide them with most inventory. On the other hand, also add some SEO content. Which one I should prefer in one page? So what do you mean with SEO content? SEO content means simple text like what we serve, what type of features we have, what benefit you will get from us. Instead of that particular route detail or route inventory. OK. I would mostly focus on the user and make sure that you're doing the right thing for the user, which is easy to say, but kind of hard to figure out. And sometimes it does make sense to show more textual information. Sometimes it makes sense to show more interactive content type things, but it's not the case that I would say you always need to do this or always need to do that. I would really look at what makes sense for your user. And this is something that you can test if you have a page that already has this kind of functionality. You can do AB testing and see, if I put more text on this page, how do users react? Do they convert as well? Do they look at the content just as long? Do they scroll through my content? These are things that you can pretty much test from an AB testing point of view. And I assume that's something that these other bigger websites did as well, where they do AB testing on specific features that they show, on the amount of content that they show, the amount of listings they show on a page. All of this kind of comes together. And ultimately, their goal is not so much to always be ranking, but that if someone clicks through to their site, that they actually make a sale, that they convert the user into something. Because just ranking by itself and not being able to convert users into customers, that doesn't really help you at all. So that's something where I would primarily focus on what works for the user and then obviously make sure that search engines can also recognize what this page is about. But usually, if you focus on the user, then the search sign kind of falls into place automatically. OK, thanks. I wish you were a simple answer, like a meta tag that you need to put in there, or how many words you need to put in which part of the page. But it really depends. And I think the two examples that you provided, I haven't looked at them in detail. But if these are both ranking for these type of queries, they show that both pages with a lot of text and pages with a lot of features can rank in the search results. John, any last comments on the content keyword being gone? Should we expect it to be good or it's gone for good? I think it's gone for good. I hope. You hope? That's really bad. That one went away. I think it's something that confused people a lot more than that had actually helped. And there are a lot better ways to understand how Google thinks the page is relevant nowadays. So from that point of view, I'm happy we have this source of confusion a bit removed. And we can kind of guide people to focus on the more important parts. And while it was helping a lot to see the topicality of the site more or less, I don't think you were actually seeing that. That's kind of one of those misleading things where you see that the amount of times we show a keyword, which is essentially keyword frequency. It's kind of like a keyword frequency tool. And keyword frequency has gone out of style over the last 10 years. So it's not something I would recommend people focus on. Yeah, well, overlapping with search and analytics data was some pretty interesting data to look at. But anyway, yeah. So we shouldn't expect something new and improved. That's goodbye for good. I think that's gone for good now. John, can I ask a question about sort of going backtracking to when you're talking about blocking other countries? One of the sites we have or run is a hyper-local site. And so what we did for about six years was tried blocking other countries. But it's like playing whack-a-mole. And we have a lot of user-generated content. So we would get scammers and spammers and robots. And we tried blocking massive ranges of IPs, literally five, six years. Finally, what we did, at least for the manual spam, we were able to figure out good capture systems that worked for the robots. But the manual spam was just relentless, especially as our site got more popular. And so what we did, and I don't know how you're going to react to me, but what we did was we built a clone of our site. And based on the IP addresses, so we generated a giant list of the countries that were the biggest offenders. And we essentially cloaked this site just for them. So any US or Canadian visitors, we let them through the site just normally. So Googlebot would have no problems as long as it's in US or Canada. But it was these China, Russia, North Africa, like all these areas that were really hitting us hard. We cloaked the site, basically stripped out all the content, especially contact information and things that they were scraping sometimes. But essentially anything that made the site useful, we created a bunch of dummy forms that they could submit endlessly. And it just went to never, never land. Like would Google ever punish us for that? By the way, it's worked perfectly so far. I think that's the main point. I find it a bit of a tricky situation. Because for the most part, we crawl from the US. There's some exceptions such as, I believe, China and South Korea. I'm not sure if there are other exceptions. But for the most part, we crawl from the US. So for us, it's important that Googlebot sees the same content as the majority of your users would see. And if you're focusing on the US, then obviously that works. So we crawl from the US. Your users are from the US. They see the same content. That's fine. You could theoretically block the old risk of the world. So from our point of view, from a cloaking point of view, that would be within the cloaking guidelines. From a practical point of view, it seems kind of tricky because people sometimes travel as well, or people from other countries sometimes want to see the same content as well. So that's something where you kind of have to find balances. Additionally, this only works if you're in the US and Googlebot is crawling from the US and your users are from the US. Whereas if you're blocking users in the US because they're the ones that are problematic or because there are policy or legal reasons why you need to block them, then you'd also be blocking Googlebot. So it wouldn't work for that kind of situation. But in a case like yours, if you're focusing on the US, if Googlebot is crawling from the US, then that would, from a cloaking point of view, be fine. From an overall, I guess, website point of view, it really depends on your website. And it depends on what your users are also doing. So we see people travel a lot. We see people from other countries accessing websites that they used to use when they used to live somewhere else. So these are all people that you would potentially be blocking as well. But that's kind of between you and your users and not something that we would get involved in. OK, thank you. John, I have a follow-up question. Sure. Does masking or forwarding affect Google's ranking and indexing of a website? So what I mean by that is when we do the sub-debates, I think there has to be a forward involved. I don't know another way. And then also, sometimes if I have a longer URL, I like to create an abbreviated alias. So people don't have to type it all. They can just type the initials and then it masks to the real site. Sometimes. So I imagine with forwarding, you mean it redirects, so that if you enter the URL in the browser, it changes to the new one, right? Yeah, for the sub-domain. Yeah, so that's perfectly fine. That shouldn't cause any problems. The tricky part there is it's sometimes not clear which URL we would choose for indexing because we might see some of the old URL and some of the new URL. And what might happen is we index the old one instead of the new one. But from a practical point of view, that shouldn't matter to you because it would show up in search in exactly the same place. So it's just a matter of which of these URLs that we would show. With regards to masking, usually that's mentioned when the whole page is included in a frame on a website. So some hosting providers do this in that you provide one URL and then it has a frame where actually the actual content is within that frame. And that can sometimes be tricky for us. We do recognize this situation as well. But usually what will probably happen is we will index the content under the URL that you're trying to frame. So not the short one, but rather the long one. But again, it doesn't really matter that much because in search we would show it at the same position. Great. And is there any difference between redirecting and forwarding as far as Google's concerned? I think the technical term is redirecting. So forwarding is just like a simpler way to say that. From a technical point of view, there are multiple ways to do a redirect. And it's either 301 redirect or 302 redirect. Or sometimes they're called permanent redirect or temporary redirect. But essentially, these all work in a similar way for us. OK, great. Thank you. Sure. All right. I saw someone else had another question. Hi, John. Maybe you can type your question into the chat on the side, and then I can pick it up from there. Oh, I just see there's another one here. Does Google recognize that song lyrics are a special art of text? They're very short, and the form is strange too. I don't think we differentiate between song lyrics and other texts on a page. So we would treat that as any other kind of text on a page. All right. Here we go. What's the impact of mobile-first indexing? Does it mean I need to make sure my mobile content is updated rather than the desktop, and the speed of the mobile website should be faster? Yes, probably. So mobile-first indexing is a bigger change on our side that we're doing that hopefully most websites won't have to worry about too much. What it means is that instead of Googlebot being a desktop browser, Googlebot is essentially a user with a smartphone, and that's the version that we would use for indexing. So instead of taking a desktop version of a website for indexing, we use a smartphone version. Just because we've noticed that most of our users are using smartphones as well, and we want to make sure that the content that we give them matches with the content that they would see if they would go to these pages themselves. So if you have a responsive website where the same website works well on smartphone and on desktop, you don't have to do anything. You're already set. You have the same content everywhere. If you have separate pages for your mobile version than you have for your desktop version, then that is something where you need to double check and make sure that the mobile version is really equivalent to the desktop version, that you have the same content, that you're updating them at the same time, that you have things like structured data, hreflang, all of this set up in the same way on the mobile version as you would have it on a desktop version. If it is less than desktop? If it's less than desktop, then that's the version that we will index. So that's something to keep in mind. A good simple way of looking at this is if you have a link on your mobile version that says view as desktop and you see a lot of people are going to that link, then probably the functionality or the content of your mobile website is not good enough. So that's a really simple way to test that. Are people using the view as desktop link or are they not using that link? Also, the functionality should really be the same. So the internal linking, things like tab navigation or whatever you use on your mobile website should be the same so that we can crawl through your mobile website and find the rest of your bigger website. And John, what about hreflang? Because we are using them in canonical pages, not in alternate pages. Yes, we're putting together an FAQ document with more questions around mobile-first indexing. And that also includes a mention of the hreflang, how you should set that up with separate mobile URLs. In the chat, there is also the question about structured data. For structured data, we do recommend putting it on both the mobile and the desktop pages so that it's really on both pages. And when we switch to the mobile version for indexing, we can pick that up. And again, if you're using responsive web design techniques, then you have all of this on one page already. So that's another one of those reasons why responsive web design is something that we would recommend. Obviously, we will still support the other ways of making mobile websites. Perfect. OK. All right, let's take a break here. I'll add the next Hangouts later today. We spoke a bit on Twitter with a bunch of people with regards to how to make these specifically for December. And what we'll probably do is take a bunch of topics that were submitted and make more topical Hangouts. So we'll probably have one Hangout on internationalization, one more on mobile indexing. There's one on AMP already planned to make it a bit easier to understand which Hangout to ask my questions in or which Hangout to watch afterwards to learn more about this specific topic. All right, with that, I'd like to thank you all for joining. Thank you all for coming and asking questions, for submitting questions. And I wish you all a great weekend. Thank you very much. Bye, everyone.