 OK. Welcome, everyone, to today's special webmaster hangout with a bunch of fantastic Czech webmasters. Do you want to introduce yourself briefly? Oh, yes. I will just introduce myself as a host today from Google Office in Prague. My name is Pavel Rashek. And together with Pavel Unger, we're going to organize this event. And we're very glad to have John Miller with us today for one hour session talking about important questions for our Czech webmasters. And we can probably run a very short introduction to all the other people that are here in this room, just so the others do know will ask you some tough questions, John. I think that's good. So, hello. First question? No, introduction. Introduction. Hello. My name is Paul. I'm working in agency H1. And I'm a CO team leader. So I'm waiting for your answers. Hi, John. My name is Stanek, and I build leagues. Hello, John. My name is Arty, and I work in websites. Any questions about it, because of the technical purpose? I am Pavel Unger. I am co-organizer with Pavel of this event. And I'm doing SEO. Hello. My name is Yarda, and I'm from the SEO agency, Irriganso. Hi, I'm Udyk. I'm a SEO consultant. Hello, I'm Martin. I'm head of the SEO team in this agency, Revendemic. Hello, I'm Erda. I'm from sasnom.cz, and I'm a CO consultant. Great. I'm sort of sorry for the other guys that have joined us, that we won't have so much time to introduce all of us. But we'll probably use the hour for practical questions. And if you don't agree, we'll kick off with the first one regarding Christian's pets, and I'll let Pavel to ask it. Sounds good. I don't. I have one question about rich snippets. What can we do if, technically, is everything OK? The testing tool shows everything is OK, but rich snippets is not appearing in the search result. What can we do best to appearing rich snippets? OK, that's sometimes tricky. So the most important part is really making sure that, technically, you have everything correct. That's the basic foundation that we need for rich snippets, for structured data in general. So with the testing tool, checking to make sure that it's technically correct. That sounds like you've done that already. The second aspect is it has to comply with our policies. So you have to mark up the content on your page in a way that matches what we recommend. So the markup should be visible on the page. If you have reviews, then that should be visible on the page. If you have reviews, then that should be with regards to the primary product or the primary item on this page, not with regards to the website overall or with regards to other types of things. Similarly, if you have the recipe markup, it should be a recipe. It shouldn't be a pair of shoes, for example, that you're marking up, unless you're cooking shoes, which I hope not. And finally, the aspect that's most tricky, I think, is our algorithms have to understand that the website is of high quality. So looking at the website overall, we have to see that this is actually a really high quality website that we can trust to provide us with the right markup. So that's something where if you've done the other things, then figuring out how to improve the quality of your website is sometimes not that easy, because it's not a line of HTML that you can fix. Sometimes it means taking a step back and thinking about the bigger picture or getting advice from other people or doing user studies where other people are coming to you and kind of explaining how they see your website and explaining where they get confused or where they feel, oh, this doesn't feel so trustworthy. So that's usually the aspect that's the trickiest. But that's also one of the items that we look at when we consider structured data for rich snippets. OK. Thank you. That's good. OK, what was another question? We'll go ahead with the automation techniques, for example. Yes, we can. So my biggest question, maybe, is about the automation techniques about the content. So for example, when I have facet navigation filters on the eShop, and I have a lot of pages, it's possible. It's OK for Google to do some automation with content. So for example, I can dynamically write a name of the category, some parameters, or something like this. Is it OK for Google or not? Or what can we do best? That's perfectly fine. So if you have an e-commerce shop, if you have a lot of items and you have different filters and facets where you can navigate down to individual items, then automatically writing titles or descriptions, that's essentially the only way you can do this. You can't write everything from hand and say, oh, these are shoes in this size with this price category in this color. That's not something you could write from hand. So that kind of automation is perfectly fine. What I would shy away from is if you're using automation to create content. If you have an article and you're rewriting it automatically or you're re-translating it automatically, then that kind of automation would be bad. But if you have an e-commerce shop or if you have any kind of website that's database-driven and you pull your content from the database and the content that you pull is valuable for your website, then that's perfect. OK. OK, we can ask another question, isn't it? Yeah, I have a question for you, John. If I have an old domain, let's say my old block, then I would like to stop it. And I created a new site, which is, let's say, typically all of the same is relevant. Is it OK for you if I redirect the old domain, like 301 redirection, all pages to just new domain? Is it OK to consider this 301 redirection? Because I have read somewhere that you can handle this situation like soft 404. So if you move from one domain to another and you have slightly different content? No, I cancel my old page. I would like to keep the domain. I will only make a 301 redirection to another domain. Everything to home page. Is it OK or not? So within the same domain or? The other domain. Domain abc.com, and I will move to xyz.com. OK. And I will just, all pages from abc.com will be redirected to home page of xyz.com. Yeah, we would probably see that as a soft 404. It's kind of hard to say, but in general, when our systems feel that the redirect is actually assigned that the old content doesn't exist anymore, which kind of is in your situation here, then we would treat that as a soft 404 and we would drop those pages from our index. Of course, there's some amount of redirection there that is still valuable in the sense that you're redirecting your home page and maybe the home page is about the same topic, then that's something that would definitely work. Or if you have individual subpages that you're redirecting to new subpages, that would certainly work. But if you're redirecting a lot of different URLs to one individual URL, if that's on a new domain or on the old domain even, then probably we would see that as a soft 404. So best solution in this case is to keep the content on the new domain. I mean, the best solution depends on what you want to achieve. And probably what you want to achieve is not just random traffic. You want to bring that information that you have to your users or provide something for your users that is valuable. And if that's something new on the new domain that matches the old content, then fine. Then I would redirect. But if you don't have that content at all, then those are users that are useless for your website that don't really bring you any value. So it's something where I would take a step back and think about what you're really trying to do. And what you're really trying to do is probably not just get as much traffic as possible, because you could set up a script that just pings your website every minute. And that would be a lot of traffic, but it wouldn't be very useful for you. OK. So thank you. Sure. So is there something you want to focus on in the near future, in organic traffic? I mean, from the website on the field. Like this year, it was HTTPS. A year before, it was mobile websites. What except mobile index? What it will be in, for example, in the next year? Do you always think that? No. That's really hard to say ahead of time what we will focus on. On the one hand, we don't want to pre-announce too much. On the other hand, there are a lot of topics that are already very active in the community, where people are already talking about this a lot. So I think mobile is something, even taking a step back, is something that is still very, very important. And where I still see a lot of especially smaller websites, smaller businesses, they don't even have a mobile website yet. And more and more people are using mobile. We're switching to mobile first indexing. And they don't even have the basic mobile website yet. So that's something where I think we need to do a lot of work still. HTTPS is really important for the future, for things like PWAs, for some items around AMP. For example, it's really important. So that's going to be a topic that will continue to be important for us as well. AMP, I think, is another one of those topics which, from our point of view, gives a chance for people to really take a step forward on the web to go from just having a mediocre kind of bad mobile website to something that works really well on mobile. So I think those three are definitely going to be areas we will focus on, because that's areas where we think that the ecosystem still needs a lot of work. I don't want us to kind of randomly pull things out of our hat and say, oh, this year we will make all websites pink. Or this year, I'll make all websites in this special font that we have. But I think it's important to solve the problems that people actually have. And if more and more people are using mobile phones, then we need to make sure that webmasters, that businesses, are able to create something that works well on the internet, where they get a lot of value out of it as well. So basically, you will ignore websites without goods about websites? No, no. I don't think we can do that. There are still a lot of websites that aren't mobile friendly, but they are good. And for search, it's sometimes better to have a bad website from a usability point of view that has your content than no websites. But still for the user, it's something that makes a big difference in their conversion. So if you're looking to buy, I don't know, a car or insurance or anything, and the best website is one that is not mobile friendly, where you have to fill out a form with 20 different fields on your mobile phone, then, of course, nobody is going to really do that. And that business is going to suffer, and the users are going to suffer. And in turn, our search results are going to look bad, because we sent them to this page that doesn't work so well for them. So helping the general kind of web to move to the next level when it comes to mobile, I think that's very important. But we have to make sure that we don't leave anyone behind. John, can we also enable chat on the stream, please? I don't know. I will look to see if I can find some options. I don't know. Maybe. OK, so the people that have joined us via the YouTube live have any question, then please reach out to me via Twitter, Pavel Jasek. And I will just mention it here in the room. Thank you. OK, I think I enabled chat, but I? Yes, it seems so. OK, I hope I didn't turn off the livestream by doing that. Hopefully. OK. It works. We'll switch to another question about Martin. I have a question about knowledge-based trust. How far in this is it? And will it someday replace the backlinks to signal relevance? Yeah, I don't know. So what specifically do you mean by knowledge-based trust? Like, you know, you have a knowledge base right now, a knowledge wall. And you can take some signals that are not based by backlinks, just content. And you can see, OK, this content is quite good. And I will use it to store all the backlinks. I read some paper from you. I think it's two years old from Google. Maybe it's patent. And you are the only one. Somehow, maybe. Not me, personally. I don't think so. But yeah, so I guess one thing to always keep in mind is that we have a lot of really smart people here and a lot of really smart engineers with fantastic ideas. And they write a lot of papers. And they create a lot of patents. But just because something is written up as a patent or a paper doesn't mean that we're actually using it like that. Sometimes they just want to get their ideas out and say, well, this is a really fantastic idea. I don't know if or how we could implement it. But I want to share my knowledge or share the ideas that I have come up with. So that's something, especially when you look at patents, it's good to be cautious there. And not just say, well, this is patented. Therefore, Google must be using it or must have been using it for 10 years now. Just because it's a patent doesn't mean that we're actively doing it. With regards to knowledge graph in general, with regards to understanding the content on a page, I think that's something that's already happening quite a lot. So we try to pull in a lot of this information into the featured snippets. So if you ask a question and it has this answer box on top, then that's something where we try to understand the page and try to understand the entities on the page. And to understand what is this page talking about? Is this page talking about the president? But which president do they mean? Which year was that? Is it talking about maybe Bush? And what type of Bush? Is this the person Bush? And which person Bush? Or is this kind of the plant? Those kind of things, that's something that our systems have been doing for quite some time, to try to understand the page better. And in turn, to also try to understand the questions that people ask in search better. So if we see an ambiguous query where we don't know if they mean golf, the sport, or golf, the car, then maybe we'll provide both types of answers, or maybe we'll provide in the sidebar a way for the user to refine the query and say, oh, I mean VWGolf and use VWGolf or something like that. So back into it, we'll take some types and then we'll answer and we'll use their jobs in the future, right? Yeah, so I guess the question of will backlinks be replaced by something like this, that's really hard. I don't think that that will happen immediately. The important part for us in search is that we use a lot of different factors. Officially, we say over 200 factors when it comes to crawling, indexing, and ranking. So it's not that we only look at links and only look at anchor text and then we do the ranking based on that. We take a lot of these different things and combine them together. And depending on what we think is relevant for the user, for this time that the user is searching at the moment, we will try to show the right results. And that sometimes means we show results that have a lot of backlinks. And sometimes it means we show results that have zero backlinks but are based completely just on the content that we found. So it's already the case that backlinks aren't the only way to show up in the search results. OK, thank you. I have a question about mobile-friendly tests. I have a website, TVScheduler, which is wider than we use for it. So in mobile tests, I have error. I get error content wider than on screen or something. Should I be worried about this error? I think you posted the URL in the question as well. The TV guide, was I correct? This is it. So I took a quick look at that. And from what I can see, our systems are flagging that as not mobile-friendly because of the width of the viewport. I asked some of the people here about that, but I don't have a perfect answer yet. I've seen other sites use a similar technique with side-spiping that didn't change the size of the viewport, where they created the viewport in the right size of the phone and they kind of moved the content within that viewport. So technically, the viewport the phone sees is the right size, but the content within that viewport is just a cutout of a bigger div in the background. So that's something that, if you see that your site isn't being recognized as not mobile-friendly, then that might be an approach that you could use there. So it's not so much that I would say this is a critical issue at the moment, where we would not rank your site properly, but it does make it harder for us to recognize that it's mobile-friendly. And I could imagine, in the future, when we switch to mobile-first indexing, that this is a bit confusing for us because it's a very different layout than the traditional kind of up-down scrolling, where we might not know what to do with all of this content that's off to the side of the viewport. I don't know for sure what will happen there with mobile-friendly with regards to content like that. I know they do try to take that into account and try to make sure that nothing problematic happens there, but it's something you might want to watch out for. And I also passed it on to the team that is working on mobile-first indexing, but I haven't heard back on how that would actually be considered for indexing. One important thing to keep in mind there, especially with a page that has a lot of content to the sides and maybe up and down as well, is if you're dynamically loading this content, then that's probably something we wouldn't be seeing. So if the initial page is just the viewport and then when the user swipes to the side or up or down, then it does an HX call in the background and pulls in more content for the sides or for the top and the bottom, kind of like with infinite scroll. Then what will probably happen there is that we might get one or two of these extra calls and process them for rendering, but we wouldn't be able to render the whole page because we don't know how many calls we have to do or what actions we have to do to trigger this additional content. So depending on how you're building those pages, that might be worth looking at. OK, thank you very much. I'll try your solution. Thank you. Sure. OK, John, one more question from me. About such ones all, I think it's an issue because sometimes in a report of early errors, I see for all four errors, with errors which never exist, but they're still in the report. I don't know how we found it. And what we can do with these errors which never exist on the web page? Well, if they never exist, then returning 404 is fine. So I think this report, in general, is something that sometimes confuses people because it shows all of the errors that we see when we crawl a page or when we crawl a website. And a lot of these errors, for us, they're perfectly expected and they're perfectly fine, and you don't have to fix them. If it's a URL that never existed and it returns 404, that's what your website is supposed to do. If I enter a random URL, then it should return 404. So that's something where I wouldn't necessarily worry. We try to show these 404 errors ranked by importance. So if a URL is linked within your website, if a URL used to receive traffic from search, if it's linked from a sitemap file, all of those are signs for us that these pages are probably important or they used to be important, and we try to show them a little bit higher in this list in Search Console. So if you don't see them listed high in Search Console, then probably that means these are random URLs that we found while crawling or indexing that aren't that important. And you mentioned sitemap. So if I have in sitemap many URLs which ends in 404, does it mean that this sitemap is not testable for Google? No, that's perfectly fine. I mean, it's not a great practice, but it won't mean that we think the sitemap is bad. So we take all of the URLs in the sitemap file, we send them all to the same pipeline, and we try to recrawl them based on the last modification date there. And if some of these return 404, they return 404, and we throw them out of the index. If others are good, then we keep them. If there are a lot of errors in the sitemap file, we don't ignore the sitemap file completely. The only place where we do something similar to that is when it comes to the last modification date in the sitemap file. So if you give us a last modification date, and all of the URLs within your sitemap file always have the same, like today's last modification date, then we think this last modification date probably is not correct. And we will ignore the last modification date and just crawl those URLs like we would normally crawl when they come through a sitemap file. So you accept the last modification date or priority in sitemap? Or is it something maybe or something insane? I would focus on the last modification date. That's the one that's the clearest for us, and that's the one that's the strongest signal that something has changed. If we see that a page used to have an old date and now has a new last modification date, then we can crawl that much faster. The priority field and the change frequency field, as far as I know, we ignore those completely. OK. Thank you. You mentioned the inversion of the site, and I have a question. Can you see me? Yeah, this is only for the use of MI. OK. So if it's already allowed for check market, and Google will send me on the end version that I will post something on Google. And the second is, if you think the end version is like future of future of the mobile optimization or the responsive layout is good enough, well, like the responsive site, which will be fast, is good enough. The future is always hard. So I think for a lot of sites, the AMP version is one that will be a lot faster than the existing content and will provide the best user experience for normal content. As soon as you have something that's interactive, then it might be that currently at least the AMP version is not the optimal approach. But it's something where I think, especially at the moment, if you have static content, if you have informational content, then with AMP, if you have a CMS plugin that just creates AMP automatically for you, then that's something I would definitely do. I think that can provide a lot of value and can provide an experience that's much faster than a traditional responsive website. As some websites, I've seen even go so far to say, we have a desktop version, and then we have the AMP version. And the AMP is our mobile version. And they work like that. I've also seen other websites that say, we only have an AMP version, where everything that they do is within AMP content. And obviously, there might be some limitations around what you can do there. If you have something interactive where people log in and they get personalized content, then that's not really possible with AMP at the moment. I know they're working on a lot of these aspects as well. But at the moment, that's not easily possible. So a lot of the e-commerce sites, you can't easily move the whole website to AMP at the moment. But if you have a blog, you could easily move your whole blog to AMP. And that's something that would probably work really well. From search point of view, one thing to keep in mind is that AMP is not a ranking factor. It's not that we say, oh, there's AMP. Therefore, we will rank it higher. It's not like that. So the advantage that you see is really purely from the user interaction point of view in that users come to your site. They see your content a lot faster. They can browse through it, read it a lot faster. And usually, if a website is a lot faster, they spend more time on this website, which is almost counterintuitive. But if they recognize that the website is fast, then they will click around. They will navigate through your website and try things out. And that, in turn, can be quite valuable for you as a website. And that users are discovering your content, the products that you're trying to sell, the services that you're trying to offer. Maybe they're also seeing a lot of ads that you have on your website that are relevant to their interests that might result in them going and clicking on those ads. So this is something where I think the advantages really need to be on the webmaster side. And it's not so much that we will say, this is a ranking factor. You must do this. But really, the value is in how users interact with your website. I have another question. One of my sites have been hacked recently. And we think, no, it's OK. It's been sold in a while. But it was like the attackers created a few pages on my blog. It's OK. I deleted them. But recently I found out that these pages have been linked from a links pub network. Should I be worried about those links because they are pointing to 404 page right now? So how would you handle those links in the link graph? So OK, if they point to 404, it's OK for me. Yeah, if they point to 404, we drop those links. So usually, like in your case, the links go to a page that was hacked before or that was created by the hackers. And if you remove the hack, then that page is deleted on your website. So those links go nowhere. And then we drop those links. And how quick is this story to happen? I mean, this drop. And the estimation, is it like immediately? Or you go there once or twice to confirm that there is still 404 page? Usually it's pretty fast. But we have to recrawl those pages that are linking to your website. So this usually isn't something that I would worry about from a linking point of view because we have fairly complicated systems who try to recognize this specific type of hacking because it's really common. That people create hack content on a site and they link to it from other hacked sites. And they create link spam through, I don't know, scripts that are posting in forums. And all of these links are things that we have a lot of practice with. And usually, we can use our hand sites to create link spam through, I don't know, scripts that are posting in forums. Yeah, I can do. I don't know what I'm saying. Yeah, so this is something where if you deleted the hack, then I would ignore that. If when you search for your name or for your website's name, you still see those hacked pages in the search results, then I would use the URL removal tool to just take those pages out. But if you only see those hacked pages when you do a site query and nobody else sees them, then that's fine. They will disappear on their own. OK, thank you. I have some similar question. What if we do if something goes terribly wrong, something like the next case? Or if we got, for example, penalty and we are sure this is a mistake, is any possibility in our context Google as fast as we can, or only Search Console? Search Console is, so I guess for the manual action, the penalty case that you mentioned, Search Console is probably the right place to go and do the reconsideration request there. You can also go to the Webmaster Help forums if you want to post there, contacting us on Twitter or going to one of these Office Hours Hangouts. Also, sometimes helps, we don't have a hotline phone number where you can call and say, oh, my site is not ranking as I wanted to rank. Can you fix that? So that's not something that we have at the moment. But there are lots of different ways to contact us. The most important advice I think I would give there is outside of the search area is to make sure that you're not building your website only for Google Search, but rather that you have a group of users who go to your website anyway, or that you have a diverse set of traffic sources where people come from maybe social media, maybe from paid campaigns, maybe something, I don't know, other campaigns that you have where you have different sources of traffic. So you're not reliant completely on Google Organic Search. Because even when everything works well in Google, sometimes things change in our algorithms and sometimes a website that was ranking number one will go down to number 10. And then it's on the second page. And this isn't something that we would say is always a bug that we can just fix. Sometimes it's the way that our algorithms are changing. So make sure you have a backup plan or kind of already have diversified in the beginning and then use the normal channels to try to reach us. Usually when it comes to malware, that's something where I have maybe rarely seen any kind of false positives where our systems automatically flag something as malware that actually isn't malware. When it comes to manual actions, sometimes that can happen, because these are done manually by people who are looking at your website and trying to understand your website. And sometimes they have a different opinion than other people. And the reconsideration process there is really fantastic, because other people then look at your website again and say, oh, was this manual action correct based on the feedback that the webmaster provided? They think it wasn't correct. And someone else can take a look at that and review that to see, is this correct? Is this not correct? When you are talking about the notice, I would like to ask you about the win. Is it correct that now the bad links doesn't harm the target site or not? So does negative SEO works or not? Does negative SEO work? So we hear a lot of people talking about negative SEO, but it's really, really rare that I run across any case where I think it might have had an effect, even in the past, even before this Penguin update, where when we look at the details of what is actually happening there, quite often there are things that have been happening before that aren't due just to the negative SEO, because these are things that we have a lot of practice with over the years. So even outside of just this Penguin update, I think maybe I've seen one or two cases where I'd say, this looks like something that might have been due to negative SEO, and it might have had a visible effect. Most of the other cases I've looked at, almost all of them, even when I look at them with our internal tools and I'm not a specialist when it comes to links, I see that, OK, well, this website has been doing a lot of crazy stuff over the years, and they claim it's negative SEO, but they've been doing these linking things for the last five years. It's like, how is a competitor so strongly focused on linking to this website for five years that doesn't really make sense? So that's kind of the situation that I usually see when it comes to negative SEO. With regards to the Penguin update, it is the case that we try to ignore links more than that we would use them against the website. So if we can recognize that these are problematic links and we can be pretty sure that we can isolate them well enough, then the Penguin algorithm will try to ignore those links. That doesn't mean that you can just go out and buy links like crazy, and maybe some of them will work and the bad ones will be ignored, because the manual web spam team still looks at these links as well. And if they see a pattern of bad links going to a website, they will kind of research this and look at what is happening here and whether or not it's relevant to take a manual action. And last but not least, I know that we can use, in some cases, the level two. Is the content of the level two accepted every time? Or how we can find out that you accept the content of the level two? We added a test to the disavow tool right when you upload. So if you upload a file that is broken, then we will tell you right away. But everything else that is uploaded, we accept that. And we process that immediately. That means it's not that we take those links out immediately, but the next time that we crawl that URL that is linking to your site, we will ignore that link. So that's something where also from a manual point of view that the web spam team isn't going to look at the disavow file and say, oh, this person put five links in a disavow file. Therefore, they're doing link building. Therefore, I need to take an extra special look at what they're doing. We see that disavow file as a technical tool. And if you put things in there that you don't want to have associated with your website, that's completely up to you. Essentially, you're putting a no follow on those links. And that's a technical measure. That doesn't mean that you're admitting to doing anything wrong or that there's anything problematic with that. It's just you don't want to be associated with those links. That's fine. That's perfectly fine. What we don't do is we don't look at the comments in a disavow file. So if you have a disavow file and you put text in there and you say, oh, dear web spam team, I am disavowing these links because the webmaster is mean and doesn't want to take the links down, we don't look at that. So we process that automatically. We handle those links automatically. Nobody looks at the content of the disavow files. OK, thank you. Great. I'll just have one question from the YouTube live chat by Mariko, who's asking about some most problematic things that you would recommend to SEO professionals or web developers that they should change immediately. What do you see as the biggest obstacle? The biggest obstacle? Our most problematic technique that they should avoid? The biggest technique to avoid? I think it's really hard to say it. It really depends on the website itself. So sometimes what we see is if a website is using modern web technologies, maybe something with Angular or Polymer, they will set up a website that doesn't have real URLs. They have just the hash and then some text after the hash as URLs. And we can't index that. So that's a critical problem, for example. That's something definitely worth fixing. Yeah, some other things. I guess are the more obvious ones that you have a noindex on a website that you have everything blocked by robots text. These are things that surprisingly often, even big websites, they mess up. So what I would recommend doing there is having some kind of a script that runs in the background on your server or somewhere else that always checks your home page, for example, to see can this be crawled, can this be indexed? It's surprising how often we see people putting test versions of their website live, and then they leave those blocks that they had in place for the test version, so blocking all crawling or noindex, robots tag, on the home page suddenly. And sometimes the indexing team comes to us and say, hey, John, this really important website has a noindex on their home page suddenly. What does this mean? Should we remove the website from our index completely or is this an accident? And what sometimes happens is we will get in touch with the webmaster and see, did you put this there on purpose or was this an accident or if it's an accident, can you please fix this so that your website comes back to the search results as soon as possible because people are searching for your website and we don't have any good content to show. So those, I would say, are almost the more common and the really strong SEO mistakes. Obviously, there are lots of smaller technical things that you could do better with canonicalization, with hreflang, with geo-targeting. But for the most part, those are not things that we would see as mistakes because we can still show your website in some ways. Maybe not perfectly. Maybe we can't crawl perfectly, but we can still bring people to your website. And for us, that's already a pretty big step. Thank you for that question. I have a question now. It's not from me. It's from Tomasz Kołba. But I'm also interested in your answer. If you have a page that is ranking for some keyword on page one, and it constantly drops to like fifth or sixth page for one or two weeks and then it comes back and then again drops like one or two weeks again up and down, what can be possible solutions if we are sure that it's not a spamming page? Can you tell me anything about this? Yeah. Usually, when I see something like this happening, it means that our algorithms are unsure how to deal with this website. And sometimes they will say, well, I think maybe it's good enough and we should show it very high. And then the next time they look at it to say, oh, it's not really that good. So usually, this for me means that the quality of the website is pretty good, but it's not as great as we would have it on a website that we would consistently show on the first page of the search results. So something around the quality and trying to figure out how you can improve the quality over all of the website, that's what I would aim at doing there. And sometimes this is kind of the natural progression of a website where you start ranking very low and you improve some things, it goes up a little bit, then it jumps up really high and then it jumps back down and you keep improving. And you notice that the jumps to fairly high stay a bit longer, or maybe it stays there for longer run. And that's kind of a sign that you're on the right path. But there's no technical reason from a website where we would say, oh, it has this meta tag. Therefore, sometimes now, yes, sometimes no. Usually it's just that the quality algorithms are looking at your site, at the signals with your site, and not sure. Some day they say it's good, some day they say it's bad, and it's just kind of like right on the edge. And you need to make sure that it stays up on the positive side. I'd like this observation about this behavior almost every time when a page gets a link, it happens in days. It's like removed from set and it comes back. The similar position method or more so. Yeah, I don't know how the links would fit in there. I suspect that's more of a coincidence. But this is something that really depends on the pages themselves, on the queries themselves, on the competition for those queries. And usually it's really just our algorithms overall. They're not 100% certain about how to deal with this page. OK. Hi, John, again. I would like to ask you about indexing JavaScript pages in situation where I can't use progressive enhancement and I don't want to skip fragment because it's deprecating. So are there some best practices? How Googlebot determines the HTTP status? How long does Googlebot render the page until, I don't know, time out or something? And how can I depack the page or sites which have a lot of pages in situation I cannot just take one page and put it into fetch and render? No, usually the most important aspect there is that we have a clean URL that we could index. So that you don't just work with the hash, that you really have separate URLs per piece of content that we can index those URLs separately. And when we render those pages, we actually get content back that matches those URLs. So that's, I think, the biggest step. And that's something that a lot of sites do wrong. That's something that even our sites sometimes do wrong, where I realize they're using a fancy JavaScript framework and it's really nice and it looks nice. The interaction is nice, but they have all the URLs behind the hash. And we only index the home page. And all of the rest of the content is kind of hidden from search. So that's probably the first thing I would do there. The second thing, when you do have indexable URLs, is really use the Fetch's Google Fetch and Render tool to double check that we can actually crawl and render the pages. This is something where, for the most part, we can index pages when they use JavaScript to create the content. But sometimes pages use a lot of embedded content, a lot of scripts, a lot of calls to servers, maybe extra APIs that use additional calls, where when we try to render this page, we just get a timeout. We don't get any content at all because the JavaScript fails. So that's something that you can test with the Fetch and Render tool. What I would recommend testing there is not necessarily every page, but the most important pages, the ones where you expect a lot of traffic, and a sample of pages from each individual template that you use. So if you have one template for the category page, one template for the product page, then test a handful of category pages, test a handful of product pages to make sure that this template, in general, works. And usually, if some of the pages from the template work, then the rest of the pages from the template will also work. I did a video in October, I think, at Angular Connect with a presentation about Angular sites in general. I would recommend taking a look at that to get some more tips, some more to watch out for with regards to specific technologies that work on Googlebot or that don't work on Googlebot. For example, if you need a service worker to run on your website to even render the first version of the page, then that's something that Googlebot wouldn't be able to do. Googlebot doesn't run service workers for all pages that are out there. So depending on how you have the technology implemented on your site, you will see that fairly quickly with the trying to render it in Search Console and watching out for those issues that are mentioned in that video will make it a little bit more deterministic on how we actually index the content like that. OK, thank you. I'll take a look on the video. As you mentioned, the embed content APIs from other pages are there some limits to these embed or ejected resources? So page speed insights tells me some error for one of my pages. I think it's something about a lot of external resources or something, and the page doesn't load. So are there some limits? There are limits, but it's really hard to quantify them. Because what happens on our side is if we can cache, for example, a JavaScript file or cache a server response or CSS files, we will use a cache version for rendering the page, which means they don't count against any limits or any time outs that might be there. So it's not that we can say, oh, 100 embedded resources is too much, because sometimes we can easily handle 100 if we can just take them all from our cache. On the other hand, if all of the JavaScript files are such that we can't cache them, then we have to fetch them all individually every time we render a page, and that can be a bit too much. So in general, what happens, the fetch and render tool in Search Console has a timeout, I think, I don't know, seven seconds, 10 seconds, something like that. That's something to aim for. For Search itself, when we render pages, we have a bit of a higher timeout, because we try to give the site a little bit more of a chance. But that's still something where if it works in the fetch and render tool, then probably it will work for Search. What I would double check there or what I've double checked for other sites in the past is what is it, webpagetest.org, which is a really nice way to get an objective view of how your page actually loads. And it lists all of the embedded resources that have to be pulled up in order for this page to actually be rendered. And sometimes you can look at that and you see, oh, it takes 25 seconds to render my page with all of these resources. That seems like a lot compared to other pages that take maybe two or three seconds to render. So that's kind of something I would look at for testing. I don't have an exact cutoff number where I can say this many seconds or this many embedded resources. OK. Thank you very much. Do you want to have a question regarding the Zelo tool? You already spoke about, do you use the data from this tool as a keyhole or a hint to England or some algorithm that can analyze sites? As far as I know, we don't. So I know sometimes we take this kind of data and we do statistics to see, does this match or does this not match. But it's not the case that we would use the disavow tool and use that as a direct way of recognizing bad websites. Because in a lot of cases, websites will have both good and bad links on them. Maybe they have really great articles and the links in those articles are fantastic. But maybe nobody is monitoring the comments and the comments have normal followed links in them by accident and they're full of spam. So the article is really fantastic. It has good links that we should trust. It's a good website, but the comments are full of spam. So how do you treat that kind of a situation? It's not that the website is bad. It's just, well, some of the links here, people don't want to have taken into account. Do you have an idea how many data do you have from this tool, like millions or so? I don't know. That's an interesting question. That would be interesting to look at. In general, the disavow tool is not directly tied into Search Console. And we did that on purpose because we believe most websites don't need to look at this at all. So if you have a normal website that is not like in the SEO niche and you've never done any crazy link building for it, then you don't need to focus on this. You don't need to worry about this tool. So we don't even have it listed in the normal Search Console UI. You have to go through the Help Center and search for that tool. You have to know that it exists to get there. So that's something where probably the number of submissions there doesn't reflect completely the number of links that people think are problematic. But it's always interesting to kind of look at these numbers overall. So I don't know if we would even be able to share these numbers, but you made me curious. I'll probably ask in turn. John, thank you. Just in terms of timing, do you think you'll have another 10 minutes for us? Sure. I can do 10 more. That's fine. And if anyone who is joined directly to the Hangout have any question, then unmute yourself and go and chat with it. Raise your hands. Or you can raise your hand. If not, we still have a pretty good stack of questions that Pavel can follow. So we'll probably give you a little time and Pavel will follow up with one question right now. I would like to ask something about tracking. OK, go ahead. Do you have a question? I won't sit down. Do you have a question? Yes. So we're not going to talk about that. Who should I have this one? Yep. No, we can do this. Sorry. OK, man. When I have, for example, changed somewhere and I do it right, how long have you CO1 or data stayed in the place? And when I can do this, cancel or something like this, is OK, for example, months for Google or have it stayed longer, months, years, and something like that? I don't have a great answer for you there. But usually, we can pass the information through 301 redirect as soon as we find it. Sometimes it takes a few cycles to pass all of that information. But whoops, I have a weird pop up here. OK, so sometimes it takes a bit of time to pass that information. So a couple of times that we have to recrawl that URL. But even if we have to recrawl it a few times, then that's usually a matter of a couple of days. It depends a bit on the URL itself. So we don't crawl all pages the same frequency. So some pages we crawl several times a day, some pages every couple of days, some maybe every couple of months, if it's something that we think doesn't change that often. So that's something kind of as a baseline when it comes to 301 redirects. The other thing that can happen is we will forward some of this information to that new URL. But if you take the redirect away, then the next time we try to forward those links going to the old URL, then we will probably not be able to associate the two. And we will split kind of this cluster that we have between the old URL and the new URL and treat them as separate URLs again. So if you're trying to forward a link to a new URL and reuse the old URL, then I would guess you probably need to keep that in place maybe a year until it's really less relevant for us to kind of keep that old URL in place. So if you're moving from one domain to another, I would definitely keep those redirects in place for at least a year. OK. And the similar question is about canonicals. I know that you are still visited canonical URLs and something like this. How often is it in compare with normal URLs which are in index or something like this? Anything to say? So for the most part, we treat canonicals and redirects about the same in the sense that we have two separate URLs and we want to pick which one of these is the main URL. And we will try to recrawl the main URL more often, but we will still check the other URLs every now and then. So it's not that there's a fixed ratio that we say 10 times the main and one times the other one, but it's something that really kind of depends on our systems. So I wouldn't I don't think we'd have any numbers on how often we recrawl the non-canonical URL. The other thing there to keep in mind is we use a number of different things to figure out which URL is canonical. And that includes the rel canonical link. That includes 301 redirects. That includes things like internal linking, sitemap files, hreflang links within these pages, where we take all of this together and we try to figure out which one is actually the right URL to show. And sometimes what can happen is you have a rel canonical set to this URL, but we actually pick a different one as the canonical for our systems because we think it's the better match. So just because there's a rel canonical there or just because there's a redirect there doesn't guarantee that we will always pick that one. OK, we have another question on YouTube live chat from Arctis, who's asking about some large websites. He's building a website that has 100,000 uniquely written pages, and he wants to expand it to other languages, like Russian, German, and Japanese, totally different ones. Are there some good guidance for these large websites? Yeah, I think regardless of large or small, I would look into the hreflang markup. The hreflang markup tells us this page in this language is associated with this page in another language. And what that does is when someone searches and we would show the wrong language version, we can show the right language version instead. So that's something I would really focus on there. With regards to putting translated content up, I would just put it up. Sometimes there are questions from people, should I put it up in pieces, or should I put it up all at once? From my point of view, you can put it up whenever you want. So when it's ready, put it up. Whenever you're ready to make it live, put it up. You don't need to artificially change the way that you put your content live just for Google. So if you put up 100 million pages today and this is fantastic content, then we will treat that as 100 million pages and try to crawl that just the same as if you put up five pages today and say this is really fantastic content. Obviously, for most websites, it will take longer to crawl 100 million pages than five pages. But that's more of a technical issue and not something from ranking point of view. For translations, the important part is don't use automated translations. So don't put everything into Google Translate and take the result and put that on your website and say this is great content because probably the translation will not be that good. I imagine if you take English content and you automatically translate it into Czech, you will say, oh, this makes a little bit of sense, but it's not really how a Czech person would write. And similar for us, we would look at this content and say, oh, this is in English, but it's not really useful English. We wouldn't want to show that in the search results. I have a question from our medit on Google+, from Michal, I think I'll read his family name. Gary Ios said that when a site has a user comment and discussions you can use to determine the site is of better quality. Can you talk about this in detail? How do you mean? Well, it's not from me, but it says, if you see a page that has a comment or discussion, you can use this to see if the page is better quality or not. OK. Kind of signal or? So usually what happens there is we look at the pages overall and we look at everything on the page. And that includes the comments on the page. So if you publish low quality comments on your content, then we think you, as a site owner, you want to have this associated with your pages. So just like you would try to make sure that the primary content of your page is high quality, I would recommend making sure that the comments on your page are also high quality so that when our systems look at your page overall, when other users look at your page overall, they see that you have something that is valuable and something that is relevant. So that's kind of what I would look at there. I don't know what specifically Gary was talking about there. Sometimes our quotes get taken out of context a little bit, and it makes it a little bit harder. But in general, this is kind of what I would focus on. I see this a lot from people where they say, oh, I have a fantastic high quality blog, but these comments, these are from random people from the internet, and I don't want to have them associated with my website. Google should not count them. But for us, we look at this page overall and we see, oh, there's lots of good content here, and then below this line here, there's lots of really terrible content. Overall, I would say this page is medium or mediocre, not so good. So that's something to keep in mind, just because you didn't write these comments, they are published on your website, so they're part of what you want to provide to the internet as content. OK, so I hope it helps the answer. Great. And we'll have probably one last question, so it's to achieve the time. I have a last question about indexing in a search console. Do you plan to put webmasters information or numbers you know, which URLs are indexed exactly? Because we know the numbers there, for example, 80% or something like this, but we can see which URLs are indexed and which are not. And I think it will be very helpful for us. We don't have any plans for this at the moment. I do get this question a lot. I got it at a conference last week as well, so maybe we need to find a different way to look at this in Search Console. But especially if you have a really large website, if you're Amazon, what can you do with this list of URLs that we provide? Even if we could give them to you as a download, it's really hard to say there is something valuable that you can do there. So we try with Search Console to give you information that lets you make decisions on your side. And the clearer you can tell us, well, if I had this data, I could fix this problem or I could recognize this problem, then that's really important for us. And that's something we could take to the team and say, webmasters are missing this bit of information. And if they had it, they could make better websites. And then our users would be happier as well. Then that would be really important for them. On the other hand, if we go to the team and say, oh, webmasters love to see random lists of URLs, we should give them more URLs in a list to download. It has no value for them overall, but they like to have this control. Then the team will say, why should we spend time working on this rather than making it easier for them to fix problems that maybe are affecting users? So this is something where if you have ideas for how we could use this information or how webmasters could use this information to improve the quality of their websites, I would love to hear them. I mean, feel free to send this to me directly. I'm happy to take this to the team and to figure out how we can give you this information in a way that works for both sides. OK, thank you very much. OK, great, John. I think it was really fantastic. Thank you for all the answers. We're glad that you could answer all the hard questions that we prepared for you. And please, if you can run a little applause for John for being here. Yeah. Yeah. Thank you for organizing this. This was really fun. We should do more like this. OK, that sounds like a good promise. I don't know. I'm sorry. OK, thanks a lot. Then I'll click the Stop button here. You're still welcome, of course, to send me more questions for the other Hangouts or maybe we'll set up another one of these in the future as well. Thanks again for setting this up. And maybe I'll see some of you later on. Bye, everyone. Thank you. Bye.