 All right, welcome, everyone, to today's 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 are these Webmaster Office Hours Hangouts, where webmasters and SEOs and interested people can join in and ask their questions around web search. As always, a bunch of things were submitted already. But you're welcome, any of you here are welcome to kind of jump in and ask the first questions if there's anything on your mind that you want to start with. Good morning, John. Hi, it's Amos here. Good morning. I have a question about Google for Jobs. So we recently migrated away from a third party that was hosting our Jobs Ward. And we moved that on to our own website. But we lost the majority of our Google for Jobs traffic when we did the migration. Now, all of the technical setup is actually correct. So we checked also with the guys at Google through the forum. And they said, yeah, everything's perfect. But they said there's a ranking problem. So we're sort of in the blind. We don't really know what the problem is. The content is exactly the same as it was on the Jobs Ward we migrated away from. So any kind of direction you can provide would be really helpful. Hi, I don't really know much about Google for Jobs other than that there's a markup and that you can use the indexing API. Is this all on the same domain? Or did you move to a different domain? It's exactly the same domain. We just had kind of a CMS that was on a different provider. There's a Magix. They're specialized in job boards. And we decided to actually bring that into our own platform. OK. And you noticed the change in traffic right about the time when you switched over? Yes, it was pretty much the easiest. So when we did the switch, everything was obviously true on redirected. Everything went pretty smoothly. But the Google for Jobs was the part that really just dropped off. OK. If you can drop maybe some sample URLs into the chat, I can take a look at that later on. I don't really know much about the Google for Jobs side. Or if there's anything kind of weird ranking related on their end. But I'm happy to kind of take a look and poke at the team to see if there's something, at least if there's something technical that you can fix. OK. Thank you. Sure. Hi, John. Hi. Recently, we have got a question from one of our clients. I think you answered this before. But I want confirmation from you again. The client has H1 tags on all the web pages he has. Only the home page does not have the H1 tag. Now, some agency told him that it is bad for his search engine ranking. It will impact badly the organic ranking. But I tried to ensure him that it is not 100% accurate. So just I want to know how important the H1 tag for a web page to rank on Google. So headings in general help us to better understand the context of the pages. So it's something that I wouldn't see it as a critical ranking factor. And for things like the home page, usually you would rank for the company name anyway. And that's not a matter of are you ranking well or not. Your company is probably the only page that is relevant for that query anyway. With H1 tags, we see it a little bit like making text bold on a page. It helps us to better understand like this is really important on this page. Some people have multiple sections that are bold. If you have the whole page that is bold, then obviously we think, well, if everything is important, nothing is important. So it doesn't help that much. But you can give us this extra information in lots of different ways. It doesn't have to be H1 tag. So I wouldn't see it as a critical thing. But it seems like one of those things is trivial to fix and to add. So I would just take care of it. And then you don't have to worry about it anymore. I think a lot of SEO tools check for the H1 headings in general. So if you use other tools, they will flag it otherwise as well. And the second question. One of our clients want to move his website to new domain. So now we are going to do all the 301 redirection from the old domain to new domain. But just our concern, does it affect their search ranking if we move to another domain? Maybe. Maybe. So yeah. So in general, site migrations can be tricky. So if you're moving purely from one domain to another, and all of the URLs stay the same within the website, and you have set up the proper redirects, and you follow all of the guidelines, then usually that's a matter of maybe a day or two where things get a little bit uncertain. And otherwise, it works out well. If you move to a different domain and things like country code top-level domains come into play, or if you change the content on the site or the internal setup of the website, then that's a pretty complex move. And that's something that usually takes quite a bit of time to settle down. OK, thank you. Hi, John. Hi. Hi, it's Paul here. I have a question. If you were making a decision, would you go PWA or AMP, or would you do both? Oh, my gosh. Which of my children do I like best? Right? The last one kind of answered it. Oh, my gosh. I don't know. So from my point of view, it feels like there are slightly different things in the sense that at PWA in general, you can use it to make something that is more like an app, which means that you kind of have a different setup on the website in general. So it's less a matter of like you're just providing content. So I could imagine that makes sense if you have more interactive elements on a page, if you care about things like offline accessibility, all of those kind of traditionally PWA level things. Whereas with AMP, I think it's a great platform for publishing content. It makes it really easy to get stuff out there. If you need to do interactive things, there are also ways you can do that, but it's kind of a little bit trickier. So that's kind of where I would try to make the call initially. It's like, are you primarily just publishing content? Then probably AMP is a good setup. Are you planning on doing something interactive, where you have calculators or other kind of interactive elements on the site? Do you need to be available offline? I don't know if you have a train schedule, for example, that you just want people to have accessible regardless where they are. Then obviously, PWA is a good choice. With another thing, I think it's worth keeping in mind is that setting up a PWA can be quite complex. So in general, if you're doing this in-house, if you're creating it yourself, then you need some pretty savvy developers who can do all of this work with the JavaScript frameworks, who can make sure that this JavaScript-based PWA will also work well in search. Whereas with AMP, you can pretty much use existing plugins. If you have to code it yourself, the code is pretty easy. It's a great way to kind of get started making web pages. So if you have fewer developers in-house, and especially if you're mostly publishing content, then I would go towards AMP. If you want to do something crazy fancy, then maybe PWA is the right approach. OK, thanks. Hello, John. Hi. Hello, everyone. I have a question regarding mobile hosting, mostly, I guess. So I have a client who has a site with dynamic serving. So does the way site appear on smartphones and desktops need to be exactly the same with all text, images, graphics, et cetera? It doesn't have to be exactly the same. But with mobile-first indexing, we'll only index the mobile version of the page. So if there's content on the desktop version that is important for you, and it's not available at all on the mobile version, then we wouldn't index that with mobile-first indexing. So that's primarily what I would watch out for. It doesn't have to be exactly the same. Sometimes people write it shorter for mobile because it's easier to read. Sometimes they have smaller images or different layout. That's perfectly fine. OK, so we'll Google Switch site to mobile first if it has slightly different content on desktops and smartphones. We have a classifier that tries to recognize if the content is similar enough. It's not that it has to be identical. So we would probably still switch it over if everything else is OK and the content is just slightly different, then we would probably still switch it over. OK, thank you. Sure. All right, let me run through some of the questions that were submitted. And if you have questions along the way, feel free to jump on in as well. Let's see. The first question is about material design icons. It's a pretty long question. But basically with the material design kind of recommendations from the framework, it looks like the way to embed these icons is to have an I element, so kind of an italics text element with a specific class, and then the text name of the icon. And the question is, well, these appear to be showing up in our meta descriptions or in the snippets, in the search results. What can I do about this? Is this like a bug in Google Search or immaterial design? I took a quick look at this beforehand to kind of try to see what is happening here. And essentially from the search side, we see this as text within the page. So you're trying to display an icon, but it's essentially text on the page. So we try to index this text on the page, and we show it in the snippet, if appropriate. We might make it available if people search for it explicitly. So from that point of view, this is probably not an ideal setup if you're putting these icons between important text on your page that you need to have indexed or that you think would make sense to be shown in the snippet. There are two things that you can do to make this a little bit better. On the one hand, specify your own meta description using the description meta tag. And we can try to pick that up and use that. On the other hand, looking at the material design site, there's also a way that you can specify these icons using a code point where instead of the text name, you specify kind of a number that refers to that specific icon that you're trying to show. And we would essentially see that as a single kind of strange character. And that wouldn't have the same effect as if you write out keyboard error left, for example. So those are kind of the two directions that I'd recommend there. I will follow up with the material design team, though, to see if we can make this a little bit better in the sense that it will just work well for search. And can you surprise that this is the first time this has come up? Because it seems like something that anyone who's using material design might potentially see. Let's see. My site has a configuration of separate URLs. And it's a pretty long question. So basically they have a dub dub dub version that's for desktop and an MDOT version that's for mobile. And sometimes they see the mobile version in the search results. From our point of view, that can sometimes happen, especially with mobile first indexing. That's similar to before, where sometimes on mobile you would see a desktop URL in the search results, even though you have kind of this connection between the two versions set up. So the things I would watch out for here are, first of all, make sure that you have the connection between those two versions set up properly so that we can pick that up. And then secondly, make sure that you redirect from the mobile version to the desktop version if the user is a desktop user. So that's something that's often easier to set up on the server side, where if you can recognize it's a desktop browser redirect from the mobile version to the desktop version. Similarly, a mobile browser going to the desktop site, they would be redirected to the mobile version. With both of these setups, it's easier for us to recognize that. And if we happen to show the mobile version in the search results, it wouldn't cause any problems. So it's not something that you need to worry about. I think in the long run, the best approach here is to go down the direction of either responsive design or dynamic serving, where you have a single URL that serves all users instead of having multiple URLs that are valid for individual users. So long term, I would go towards a single URL solution. In the short term, I would set up the links and definitely the redirects. If you have the redirect set up, then you don't need to worry about the mobile page sometimes being shown in search. Why does Google index 404 pages? We don't. So if a page returns a 404 error code, then we will not index that page's content. There are two things that might be something that you're seeing here. So I don't know exactly which pages you're looking at. It might be that a page has recently turned 404. And in that case, if we haven't seen that the page returns a 404, then we won't know that it's a 404. So that might be something that's happening. The other thing that sometimes happens is that the server shows a 404 page, but the result code that's shown to crawlers is actually 200. And 200 means OK, that this page is OK to be shown, OK to be indexed. And if we don't recognize that the text on this page says, oh, wait, there's an error here, then we might index that page separately. So if you have custom error pages, make sure they return 404. If this is your site and you've recently removed content, then sometimes it just takes a while for all of that to kind of drop out of the index. Is it true that top level domains are best for ranking? No. You can rank your content on any kind of domain. It can be on a subdomain. It can be on a subdirectory. That's totally up to you. Sometimes it's even tricky to recognize what a top level domain is, because some country versions have something set up that looks like a unique top level domain, but it's actually a subdomain. So it's definitely not the case that only top level domains are best for ranking. If you're creating content on your own, what I would recommend, however, is that you use your own domain name for hosting your content. By using your own domain name, you're kind of making sure that, regardless of what infrastructure you're working on, you can keep your content and keep that in search. You can continue building on your own website, whereas if you use a subdomain, for example, from Blogger or, I don't know, any of the other hosting platforms, if at some point you say, well, Blogger isn't enough for me. I want to do something fancy, then you have to do a site migration. You have to migrate that subdomain from Blogger to some other domain or subdomain. Whereas if you use your own domain for hosting and you decide, well, Blogger isn't enough for me. I need to use something fancier, then you can continue using your domain and you just need to watch out that these URLs remain the same. Is Googlebot degrading sites traffic which work like automated programs? So the question is pretty complicated. I think what this site essentially does is automatically generate pages that match what a user was looking for. In many cases, that comes off as being very spammy. If you're automatically generating kind of textual content based on something someone's search for, then that could be seen as an auto-generated page, which the web spam team could take action on and say, well, I don't know if this is really useful content. In this case, it's automatically generating a ringtone based on kind of the text that people enter, which, I don't know, sounds pretty neat to me. So I haven't tried it out. But it sounds pretty useful and neat. But with regards to search, this generally wouldn't be something where we'd say, this is bad, because we can look at the content. Even if someone manually looks at the content, they can say, well, there's something kind of useful that's being provided here. It's not just a matter of someone kind of copying, pasting the same text over and over again or automatically generating some text. That said, if you're automatically generating pages based on things that users enter, then you quickly run into a situation that the amount of pages on your site explodes. The kind of value of each individual page is questionable, because you don't even know what people have entered. And it's possible that users enter some really crazy stuff that you don't want to be found for. So perhaps someone goes in there and says, I would like to generate a page for, I don't know, Mihai is the world's best SEO. And then that could come out as like, well, your site is promoting Mihai as the world's best SEO, whereas actually you just want to provide a ringtone. So my recommendation there, when it comes to user generated content, find a way that you can filter out kind of the high quality stuff and separate it from all of the rest, because you want to be found for the high quality stuff, and you want to make sure that search engines, when they look at your site, overall, they see, well, all of this stuff is really high quality stuff. Therefore, maybe this is actually a really good website to show, whereas if search engines go there and say, well, there's some good stuff here, but there's this big pile of junk that people have just submitted, then they might say, well, overall, this website, I don't know, is hard to see as something being fantastic. Not to say that Mihai is not a good SEO, though. I know Google doesn't penalize for duplicate content. I heard that in one of the videos, but what about Spun content? Does Google penalize for using Spun content? Yes. So anytime you're using auto-generated content to create pages, textual pages like that, that would be considered against our webmaster guidelines. So that's something that I would definitely try to avoid. They're common setups that the WebSpam team runs across every now and then on the one hand, pages that are completely auto-generated, where you just have a few seed words and then it goes off and generates a big tree of text that is essentially just trying to target those words and has no value at all for users. Then other common use cases we see are scripts that take existing content on the web, and they just swap out individual words. That's also seen as Spun content and would be against our webmaster guidelines. And then there are cases where people take existing content and just translate it into other languages, often using automatic translating tools. Sometimes they translate it back to make it look like it's actually English again or whatever language it originally was. And that would also be seen as automatically generated content and against our webmaster guidelines. The WebSpam team generally, when they run across situations like this, they do take action. And that can be action anywhere from the site is not showing up so well in search to the site is completely removed from search when we think there's really no value at all in that site. John, I have a question about this. Because on these automated tools, we sometimes see that our images are pulled into these spammy pages and using our own hosted images. They're not downloading them and re-uploading them. And does this have a negative effect on SEO because we're associated with this page? Or not really? No. OK. Yeah. That's a common setup. They just scrape stuff from image search and they take it directly from those web pages and show that. And I mean, sometimes we don't catch this right. Sometimes our algorithms don't pick it up properly. It's useful to have a spam report if you run across things like this or if you run across a bigger setup that just seems to keep working, then maybe send me a note. But for the most part, this is something that is very widespread. And we have a lot of experience with that. Internationalization, duplicate content, a site is multi-regional and all in one language with the correct hreflang and canonical setup. But Google is increasingly choosing its own canonical. Does that mean it's because the content is the same that it's seeing it as duplicate content? Yes. If the content is the same, then it's seen as duplicate content. That's kind of, I guess, the definition of duplicate content. When it comes to international sites like this, what generally happens is we would pick one URL as a canonical. And we would use the hreflang annotations to swap out the appropriate URL in the search results. So indexing-wise, we try to focus on one version because it's all the same. And in the search results, we would just swap out the URL. So usually that's OK. Yeah. Hi, that was my question. So our site is multi-regional, but it's in one language, as you said. However, we do have the correct hreflang setup and canonical. And we've seen this increase quite suddenly. So it's only happening in one market. Like you said, because it's the same, it's seeing it as duplicate, but the increase is all of a sudden. So I was thinking, is there something behind it? We've spoken to our dev team, and we've seen that there's been an increase in the API pages being crawled. So we were just trying to understand, what is the reason for the sudden change? It might not be anything on your side. So what sometimes happens is our algorithms over time will try to reevaluate what is actually duplicate content. For example, if the bulk of the page is the same and the footer is slightly different, then it might be that our algorithms will at some point say, well, actually, these are the same. And then you might see a shift like that. So it's not necessarily something that you're doing wrong. It might just be our algorithms suddenly recognizing, oh, wait, this is all the same. Despite having correct hreflang canonical, it's just the same content. So usually what happens is in the search results, we would show the right URL. So it's not that anything is broken, or you're seeing lower traffic there. But it is confusing if you look at things like the Search Console Index Coverage Report or the Performance Report. Both of those focus on the canonical URLs. And if we pick one version as a canonical, then we'll have all of the data there. And it might be a different canonical, depending on the page. So it could, for example, I'm just making this up. Maybe you're about page. We pick the UK version as a canonical. And your terms of service page, we pick the Australian pages canonical. So that's something that makes it a little bit tricky. If you have a single domain with the country versions as subdomains or subdirectories, you can use Search Console kind of on the domain level to get the full picture. If you have multiple separate domains for individual country TLDs, then you need to kind of manually calculate the appropriate numbers across Search Console. There's no real way to get an overview there. OK, great. So is the solution in future? I know it doesn't hamper our performance in rankings and traffic. But moving forward, is it just best to have those markets translated in their correct language? I mean, translated is probably the best in the long run anyway. The question that I don't really have a great answer for is should you kind of artificially change the content across? Like, say you have multiple English pages, should you artificially shift sentences around so that they're not seen as duplicate? Theoretically, you can do that. We probably wouldn't see it as duplicates anymore. It would be easier to track. From kind of a practical point of view, I don't know if that would change anything in your search results. It would just essentially make it easier for tracking. OK, great. Thank you. Sure. I've read that Google only takes a number of backlinks rather than a number of high DA backlinks for ranking. Is that true, at least currently? So we don't use DA at all when it comes to search. So this is a metric created by a third party company. I think it's cool that companies create different metrics to kind of try to evaluate how a website is doing a cross-search. But we don't use DA at all. Anything like domain authority, the metric provided by other companies, is not something that has anything to do with Google Search. So from that point of view, if you want to use this metric on your site to compare things, and it helps you to better understand how your website fits in with the rest of the web, go for it. But I would not assume that this is something that has anything to do with regards to Google Search. Does Google have any red flag if a site is using an old PHP version? No, we don't. So what can sometimes happen, depending on the setup and what is happening on our side at the time, we may send out messages through Search Console to sites that are using either kind of an older server version or an older CMS version. Say you have an old WordPress version installed. It might be that we send you a message and say, like, be aware, there are vulnerabilities out there for this setup that you have running, and it's possible that you'll get hacked. And we recommend that you update as urgently as possible. So that's something that can happen, and it can certainly happen if you're running an older version that is not patched appropriately that your site gets hacked. And getting hacked has like its whole set of hassles that are attached to it. And so I'd try to avoid that if at all possible. But it's not the case that there is any kind of a ranking effect or any kind of red flag on our side that we would say, oh, it looks like they're running an old PHP version, therefore we shouldn't show the site as high in the search results. Is there any risk in pointing park domains to our live website? No, that's perfectly fine. I would not assume that you're getting any value out of redirecting all of these park domains to your website. But I have seen cases where people use them, for example, for marketing reasons. So if you're doing some kind of offline advertising, then maybe you'll pick a certain domain name that redirects your main website as the ad URL that you would show there. And that's perfectly fine. It makes it easier for you to track how that's performing. So I wouldn't mind just doing that. OK. In one of Google's patents, I've read about a new page rank concept that is very intriguing. It's about seed pages being used to calculate page rank. So a few questions about that. In general, I don't really have anything to say publicly about any of the patents that we have. A lot of these patents are done in the sense of kind of like, we ran across this really cool concept, and we would like to patent it so that it's clear that kind of nobody else can take it. So that's something that doesn't necessarily mean that we would use that directly in search. There are tons of patents out there. Bill Slavsky, he runs a blog that covers all of these really cool patents. And I'm always amazed at the cool stuff that people at Google are working on. But I wouldn't assume that just because there's a patent out there that this is how Google Search works. I was recently approached by a company promising great rankings through the use of their plugin. Apparently, it allows them to publish content on my site and on other client's site. The plugin also creates what they call a network of SEO links between their client's sites. The content isn't quite hidden. It's only linked through the copyright link in the footer. This screams bad news to me, but they claim to have over 39,000 clients and 50,000 domains in the network and nobody's being banned. Is this a legit practice or a case of run florist run? So I love that last part. And I would kind of agree with that. Agree with that. If essentially, this plugin automatically generates content for your site that kind of goes into the area we've talked about before, and if it automatically generates this kind of network between other sites, then it's kind of a link network. I mean, well, it's not kind of. It is a link network. Then that's something that the web spam team, when they run across that, they will take action on this. And it's not necessarily the case that we would remove all of these sites from search. So you might still be able to find them in search, but we would definitely take action on this network. And we would make sure that all of these artificial links, which are only there because you're using this plugin, that they're taken care of. And this is something that's not particularly novel. It's like, I think when I started in SEO, what was it? Maybe, I don't know, 15 years ago, there were various kind of link networks out there that were doing essentially the same thing. So that's something that, for a long time, has been clearly seen as a bad thing that goes against our Webmaster guidelines. So I would stay far away from something like this. Any way to help for new Search Console index coverage errors, if Google could tell us what the errors are. I have 520 errors with submitted and has a crawl issue desperately trying to find a fix, but it can't figure out what's wrong. The page comes up fine, but validation fails. So I think what would be really useful here is to have some sample URLs. And probably what would work out here is to take this question and post it in the Webmaster Help forum. So the folks in the Webmaster Help forum have a ton of experience with these kind of problems, and they can quickly help you to narrow things down. So it might be a case that there was just like a temporary crawling problem that essentially you don't need to worry about because it's kind of come and gone again. It might also be the case that there's something systematic on your website that is preventing Google from being able to crawl these URLs. And there are a number of ways that you can test these pages using maybe the Inspect URL tool in Search Console, using other tools as well. And by kind of getting help from other people who have done similar things, it's a lot easier to kind of narrow things down and to figure out what exactly is the problem here. And at the same time, you also learn how to kind of diagnose these types of issues, which is, I think, always a good skill to have. So I'd recommend taking this with some sample URLs, maybe some queries or screenshots even, and posting it in the Webmaster Help forums. What happens if we disallow the robots text by robots text? Then everything explodes. No, not quite. So essentially, we will still have to fetch the robots text to be able to see the robots text. So disallowing the robots text file in robots text does not change much with regards to the requests made to the robots text file. It does prevent indexing of the content of the robots text file though. So what you would see is if someone links to your robots text file in the sense of, well, maybe this is an interesting page to show, which probably it isn't, then technically we might go off and try to index a robots text file. And we could theoretically show that in the search results if someone is searching for a way that clearly looks for this robots text file. And if you block crawling of the robots text file in robots text, then we would still show that URL in search. We would just say, have the snippet saying, well, we can't give you any more information because we can't crawl this page. So practically speaking, I don't think anything will change. I don't think you make things any more complicated or harder or anything, but it's kind of unnecessary. You don't really need to do it. It's similar, for example, if you want to block all crawling of a website, you would use disallow, colon, and then slash. That would also block crawling of the robots text file. But I think blocking it explicitly doesn't really make much sense. It adds a little bit more complexity to your robots text file. And a year later, you'll be like, what was I thinking? There must be a reason for me to block the robots text file when perhaps you're just doing it for a bit of fun. My blog is so-and-so. I'm writing quality content for my readers. Currently, I don't have a lot of traffic. Let's see. Recently, my blog was approved for AdSense. Still, I choose not to show ads because I'm worried about the quality of my traffic. I'm trying to look at my articles again and again. What can I do to kind of better present my site to users? I don't know. So I took a quick look at your site. It seems like a very reasonable site. It's really hard to say what exactly you should be doing differently. What I'd recommend doing is maybe going through the SEO starter guides that are out there. There's one from us. There are a bunch from other people as well. And kind of going through to make sure that you have everything covered. On the one hand, there are things around the way that you present the content on your site. Maybe you're doing well there. Maybe the content that you're writing is fairly well. On the other hand, there are also ways that you can kind of help promote that content and get it out there so that other people talk about it and so that other people have a chance to find it and link to it if they find it useful, all of these things. It's sometimes tricky to get started. I think it's also really tricky to get started and say and kind of start with an SEO topic on a blog because there are lots of SEO blogs out there. It's really hard to kind of differentiate one blog from another sometimes. So that's something where my first thought when looking at your site was maybe it would make sense to find a topic where you're really passionate about. That's not something that's already extremely well covered in the industry and to kind of find your audience there and to start off with a small audience that really loves your content and grow that step by step rather than starting off completely fresh and saying, well, I want to create an SEO blog like all of these hundreds of others that are out there. Because if you're kind of starting off completely fresh and you want to compete with this giant set of other sites, then that's going to be really, really hard. That's not something that you can just kind of tweak by having some nice blog posts on your website. You really need to provide something unique and compelling across your site as well. Yeah. Yeah, I have a question. So John, we know that the Googlebot can't able to crawl the infinite scroll pages. But my question is, how can Googlebot be able to figure out all the URLs or all the links in the infinite scroll pages? Example, sitemap is the one way. So is there any other way that Googlebot can crawl all the infinite scroll links? We have a blog post on infinite scroll. I will take a look at that. There are some techniques that you can do where you show paginated links on the bottom of the page, for example. And then we can follow those paginated links as well. So I'd definitely check that out. I think it's maybe three or four years old in the meantime. But it's still valid. OK. So I have a question. So if you see there are a number of headers and photo links are there in our each and every website. So whenever Googlebot crawls, how it will consider the header and photo links? Because in your Googlebot, it will crawl from the top to the end of the page. So how it will consider the headers and photo links? It will crawl each and every page headers and photo links or it will just keep the headers and photos and it will just crawl the remaining links? Does it affect the crawl budget? We do try to crawl all of the links on a page, regardless of whether they're in the header or the footer. It's something, if you're linking your site in the header, if you have a menu on top, then that's a great way for us to kind of crawl through the website. So it's not a matter of where those links are. It's essentially just that these links exist. The thing to keep in mind with regards to headers and footers and sidebars is that generally speaking, these are repeated across the website. So from our point of view, we see them as something that's not critical to that specific page. So we understand these belong to your site. We can still crawl them. We think there's probably good content here. But when we try to index pages and show them in the search results, we try to focus on the primary element on the page. So if you have a blog post, for example, we'll try to take that blog post and treat that as the primary element. And the headers and footers, we'll follow the links. We know they kind of exist. But it's not seen as critical as that primary blog post that you have in the middle. OK. So I have one final question. So yeah. So in our site, we have a number of old 301 redirection URLs are presented over there. So let's say I have 1000 URLs or 1000 links of old 301 redirection URLs are presented in my website. So does it affect my new category of which is redirected? Which does it affect the ranking of a new category? No, it wouldn't affect the ranking. That definitely not. It could potentially make it harder to crawl your website. So in particular, if we need more than five redirect to find the final page, then we will try to recrawl that in a second step. If you just have a collection of redirects from one old page to the new page, then that's perfectly fine. If you have maybe two steps in between, that's perfectly fine. If you have more than five steps, then that's something that I would avoid. In general, I recommend making sure that your redirects go as direct as possible, just to avoid running into a situation where you go from 2 to 3 to 4, and then suddenly you have 7 or 10 redirect hops, which make things a lot harder for us to crawl. OK. Thanks, John. Sure. Yeah, there's still a few questions left, but maybe I can just switch over to you all. What else is on your mind? What can I help with? Hey, John. I asked that question in the chat, but I can ask it here. We have syndicated some of our content on a new website with another website, but they are outranking us. We've added our canonical tag, but still they're winning. Is there another way to avoid this, apart from adding a no index on the other website? Because they really want more traffic, apart from organic traffic, since it's a new website. But I'm afraid it's hurting us, since it's no longer what you call it, the content will be duplicated, so it's no longer unique. Yeah. So generally, it wouldn't harm your website in this kind of situation, so I think that part is kind of fine. But any time you syndicate content to other sites, it can potentially happen that they outrank you. So that's something that is always worth keeping in mind. I think it's also something that's, I don't know, both a risk and an opportunity in that sense, in that it could be that your site is ranking number three. And if they kind of syndicate the content for you and they can rank number one, then suddenly your content is a lot more visible than if it was just on your website. But at the same time, it's also a little bit of a risk in that maybe you want people to go to your website instead of to their website. So that's, I think, always something to keep in mind. When you're syndicating content or when you have affiliate relationships, if you kind of have resellers that sell your products, it can happen that any of these other people that are essentially reusing your product or reusing your content, that they rank above you. And there's no kind of meta tag at Google where we'd say, this is the original. You have to show us at number one, not the other people. The rel canonical helps us a little bit there, but it doesn't guarantee that we will always follow that. So I don't really have a solution there. I think it's something where you kind of need to probably discuss internally and think about, do we want our content to be visible like this? Or do we need to make sure that people only go to our website? OK, but it's not hurting us, but it's not hurting you. It's not that your website would be ranking lower because of this kind of syndication setup. OK, great. Thank you. Sure. All right. I mean, we still have time. I can run through some of the submitted questions, but sometimes it's more interesting with live questions if there's anything from any of you all. I can ask something, if that's fine. All right. It's regarding the how to structure data markup. I'm wondering for more complex content, for more technical content, perhaps, where you kind of lay out the steps you need to take to do something, but you also have to include a lot of maybe more in-depth explanations. But you don't really want to include that in the how to markup because it kind of makes it a lot bigger and you don't really have the right attributes to kind of include that. So I'm wondering if the content is not exactly the same. So maybe it's more of a summary of steps within the markup. Is that still fine or does it need to be a one-to-one exact match? I think that would probably still be fine. So on the one hand, it's something manually, if we look at that, that would probably be fine. Algorithmically, I could imagine that our algorithms might be a little bit confused. They say, this isn't a markup and this is visible on the page and it doesn't match. If in the markup you're providing a subset of what you're showing on the page, then I don't see a problem with that. So if you have something like how-to steps and you say, like, here's the first step and then click here to see the rest, I generally wouldn't see a problem with that. And one more thing. I'm wondering, so for a more technical IT-related content like where you actually need to run, you have, for example, run this command. Maybe I'll install Python on Ubuntu or something like that and you need to run this and this and this. Does that need to be included? The actual lines of the actual commands, they need to be included within the markup or how would you go about this? That's totally up to you. I think that depends a lot on the website and on your goals. So if, for example, you need to get that information out and you don't really need to have people visit your page, like put it in the markup. If, on the other hand, it's really important for you to have people visiting your page, maybe that's how you track your metrics, your performance, maybe you have ads on the page, then that's something where you might say, well, I'll limit the amount of content I have in the markup so that it encourages people to visit my page instead. I think there are totally valid use cases for both of those directions. For example, if someone is looking for your opening hours, they don't need to visit your page. They want to come and visit you in person. They just need to have the opening hours. Whereas if someone is interested in potentially hiring you because you're an expert on this topic, then probably you don't want to expose all of the kind of secrets that you know directly in the markup directly. You want people to visit your page and learn about the fancy things that you've been doing. So for example, if I have a man like Git and to take the latest version of Python, maybe it should be better to just include in the markup, use Git or get the latest version from GitHub and not actually include the actual line of, yeah. So that's fine as well. That's totally up to you. And that's something that I would certainly test and see, given the number of impressions that you get, are you getting the clicks that you think are useful, kind of double check your other metrics as well to figure out those people who are coming to my pages, are they actually relevant users? Or are these people who are basically confused and just need something to copy and paste and they will disappear again and never come back? I don't know. It really depends on what you're trying to achieve. OK, I just want to make sure that Google, as you mentioned, doesn't get confused. Well, you're saying this in the markup, but the content is a bit different if I look at the actual page. Yeah, I think if the markup is a subset of your actual content, I don't see a problem with that. If it's completely different, then that might be something where our algorithms say, well, wait a minute, this doesn't match what's on the page. But we don't know if this markup is really important to be shown directly in the search results. OK, I'll test it out. Sure. Cool. There's a question in the chat from someone in a noisy environment. I have experience with, I think, e-commerce apparel sites. And this is the first time I'm encountering a site from a manufacturing company. The site structure is not set up in a way that the product detail pages only contain one product. Like I usually see for a typical e-commerce site, is it common for manufacturing companies to set up their site structure so that multiple, so in this case four specific products, are shown on a single product detail page? Is there a big effect for SEO friendliness and ease of crawling if each product has their own respective product detail pages and not bundled into one page for multiple products? In general, if the content is on your site, then we can show it in the search results. So it's not kind of a deal breaker completely. But it does make it a little bit harder for us to recognize what these pages are exactly about. So if the multiple products are all related, it's more like variations of the same product, maybe different colors, different sizes, then I don't see a problem with that because that's kind of all about this one product. And these are different variations. And having one product page rather than one page per variation makes it a little bit easier for us to kind of focus our signals on those pages. On the other hand, if these are completely unrelated products, then it's really hard for us to recognize that this is actually a useful landing page for someone who's looking for that product. So let's say if you have, I don't know, shoes and you have one model shoes with different colors and sizes, having that on one page is fine. People will search for shoes and they can go to that page. On the other hand, if you have shoes and then dresses and then hats and you put a variation of these all on one page, then if someone is searching for a pair of shoes, we don't really know if this is the best match for them because it has so much information about hats and dresses as well that it's like maybe someone searching for a collection of clothing makes sense. Maybe someone searching for an individual hat, maybe it doesn't make so much sense. So that's something to kind of keep in mind there. If these are variations, I definitely don't see a problem with that. If these are completely unrelated, then that makes it a lot harder for people to find those pages. If this is a manufacturer site where end users are not really meant to go to those pages and buy products there directly, maybe it doesn't matter. Maybe it's enough that distributors are able to kind of look up, I need to find a manufacturer who has this specification of products, then that's specific enough to still bring up these pages. So I guess in a typical SEO way, I would say it depends. But it's something where based on your knowledge of that website, of the company, and of their goals, that's something that you can probably make a decision on whether or not this is OK or if this is perhaps suboptimal. Maybe there's also a way to tweak things a little bit where you say, well, currently these are unrelated products, but I can tweak it so that the related products come together on one page, then that would probably be a lot better. Hello, John. I still have a bit of time. So if any of you want to ask questions, jump in. Hi, John. Hi. John, I have a question regarding Google Search Console. So I was checking this URL. I can share you that URL in chat also. That URL particularly is, when I was checking it into the Google Indexing, it was showing me that URL has some indexing issues. So this is the URL I have shared you in the chat. So this is the URL. It's showing me URL is not on Google Indexing Errors. But the same URL, when I check into the live test, it's showing me URL is available to Google. And it's showing me the availability URL can be indexed, mobile usability, fax, logos, everything is done on the page. But when I check this into the Google Index, it's showing me that the pages, the referring page is not detected because maybe the URL is not interlinked. Maybe that could happen. And the page fetch is also showing in the error crawl anomaly. So I'm just confused like which one I should follow. I'm in Google Index or live test. Because right now, one is telling me that my page is on Google. But one is telling me I have indexing errors. So what should I do in this situation? I don't know exactly which errors you're seeing. So it's kind of hard to say. Just purely from looking at the URL, my worry is a bit that on this website, you're generating URLs for a ton of different variations. So it looks like you have car service center, and then you have a location, and then you have a type of car brand, all of these URLs. So my worry would be that you have hundreds of thousands, or even millions of URLs that are essentially variations. It's like all car service centers, and then you have lawyers, and then you have teachers, and you have all of these different locations. And you're generating URLs for all of them. Then that's something where I could definitely see that our systems might say, well, we're seeing so many URLs from this website, we don't know if it's worthwhile to crawl and index all of them. That's something where probably the right approach first would be to think about what kind of content do you really need to have indexed. And also to think about, are there perhaps ways to limit the amount of content that is on your website? Are there ways to make sure that all of the content that you're providing is of the highest quality possible? So that our algorithms, when they run across this URL, they try a little bit harder to actually get it indexed. So that's kind of the, I think the first step that I would take there is to avoid running into a situation where you have millions of URLs that are essentially like I could index them, but they're not really fantastic. We are planning to rewrite the URLs for the whole website, because right now we have one extra directory in our URL system. So that's why I have already discussed with my developer team. But right now, I was just this bit I was confused because of maybe this error is coming because of that pop-up also, maybe you have seen that pop-up once the page is loading. But the problem is, this URL is into different categories. So right now, this is into submitted URL has a crawl issue. Into this error, this is showing me. So I mean, my confusion is just a little bit this, like I'm seeing it into the Google indexing, as well as in the live test. So yeah, of course, I'll be making the changes to the particular all the, I mean, around the website. I'm changing this, the city-based pages into one particular, like car service center and car service center, Hyderabad. So I'm merging this, these two categories. So I'm creating only one category, car service center, Hyderabad. So I'll remove the previous category. And then I'll create URL in this way. But yeah, I mean, my question was like this, how can I solve this issue? Or maybe if this is having the crawl issue, so reducing the crawl depth can help me? Or I mean, or should I take any? So what I guess happened here is that we tried to crawl this URL. It didn't work out. And because we have so many URLs otherwise on this website, I didn't check, like what the rest of your website looks like, I'm just guessing. But because we have so many other URLs on this website, we don't bother spending a lot of time retrying it. Maybe we'll try it again in a couple of months. But it's not something where we would say, well, we really need to get this URL. We'll retry a few times until the crawl error goes away. So my guess is it kind of ran into that. The other thing to keep in mind is that with mobile-first indexing, we would be using a mobile crawler for that. So what we sometimes see is that testing tools, when they check with a desktop crawler, it looks OK. But when they check with a mobile crawler, it doesn't want it. So that might be another thing to kind of double-check. Make sure that that's OK. Well, yeah, currently, actually, the source is smartphone. So on the people who are showing this source is smartphone for this particular URL. So I mean, yeah, I have to look into the directory level. But yeah, I mean, that was cool. Sure. I think it's tricky with really large websites like this. If you look at individual URLs, then it can often be the case that we say, we just have so many URLs from this website. We look at individual URLs maybe once a month, maybe once every two or three months, because we just have such a mass of things that you want to have crawled. Yeah, it's also pretty much dynamically. And then errors stick around for a little bit longer, because we don't get around to double-checking them that quickly. Cool. Yeah. Thank you, John. Cool. OK. I have a question for you. All right, let me just switch off the recording so that the YouTube video doesn't get infinitely long. I still have a bit of time, so you're welcome to stick around. But I'll just stop the recording now. Thank you all for joining in and hope to see some of you again in one of the future Hangouts. And if you want to stick around for a little bit longer, feel free to do that as well. All right.