English Google Webmaster Central office-hours hangout

Key Takeaways

All right, welcome everyone to today's Google Web Master Central office hours hangouts. Uh, my name is John Mueller. I'm a web master trends analyst here at Google in Switzerland. And part of what we do is talk with web masters and publishers like the ones here hangout. And it looks like we still have some room. So, um, maybe I'll just, uh, open it up for you guys for the moment and, uh, do a short tweet. Uh what else is what all is on your mind? Who wants to start with a question? I've got one if no one else is uh ready to go. Go for it. Sure. So, uh we had a technical SEO uh audit done on the site and one of the things that came out was looking at search console on a number of 404s. It's building on something you said on Tuesday. Um I've been diligently working my way through setting up. So, we're an e-commerce site, lots of dead URLs to our product. I've been working my way through finding alternative URLs for um same products, different finishes, different brands, um different sizes, but fundamentally the same product. Um the question is, should this be a good use of my time? Um, I I think cleaning up issues like that is is always worthwhile, but I I suspect you won't see a big jump in in rankings for for making kind of this cleanup activities. Okay, thank you. Right, more questions. What else is on your mind? Um, we still have the same problem with the breadcrumb in search. I think I'm I'm not sure if you got the mail like two weeks ago. I asked you if um we had a problem with um how the breadcrumb is being displayed in the search results. Um yes, it was basically it was like uh continent, region, city, and then the hotel. Um, I'm not sure if you got the mail or if um it's still the same. Like we just don't know why. Sometimes it works, why sometimes it doesn't, but you have the markup on the pages. Yeah, the markup is the same. It's same on all pages and some it works and some it just doesn't. Okay. So, in in general, that means our algorithms are are trying to do something different than what you're trying to do. And uh those those are things where we bring that feedback back to the team, but usually they're not able to like manually tweak that for individual sites. Yeah. Kind of on the on the algorithmic level. And uh what they need to do there is work to improve the algorithms to handle that better. So that's usually not something they'd be able to like just make make work better from one moment to the next. Okay. But like is there anything we can maybe do better? like maybe something is I checked everything with a social data testing tool and everything is fine. Yeah. Um I I need to double check with the team on that. So I I passed your your note on to them, but I don't think I heard back on whether or not there's anything that you could do in the meantime. One thing I'm guessing like our site maps have been broken for like two months now. Like no new site maps which is not ideal. Um that should be that much of a problem. So I I mean obviously everyone wants to have great sitemaps and they're definitely useful for us for crawling uh new and updated content, but if we're already crawling and indexing your content and just not showing it in the way that you'd like, then the site file isn't going to be the one that's that's the reason. Okay. All right. Thank you. All right, let's jump through some of the questions that were submitted. Um, okay. If a quality raider assigns a low quality score to a website, will you take this into consideration when you launch the next algorithm update? Uh, if there are no manual actions, does this mean the quality raers have no impact on that specific website's rankings? Uh, yes, that's that's the case. So uh we use craw quality raers to try to determine where where we need to improve our algorithms or to give them variations of different algorithms to to see which one of these is is the best one for with regards to the the relevance in the search results primarily. Um but but in general we we give them multiple ideas and we essentially ask them which of these are better. And if a quality raider says well this website isn't really useful for this specific query that doesn't have any impact on that website in the search results immediately and it doesn't have any impact even after that algorithm is rolled out on that specific website because these algorithms obviously they're they're made for the whole web. They're not focusing on individual websites. But at the same time, if you think a quality raider when they look at your website and they would say, "Oh, this is a terrible website," then probably you're aware of quality issues that your users could be seeing as well. So, that's something I I'd still think about and consider actually cleaning up. Um, our forums text editor uses deprecated font and align tags. So, all formatted posts uh contain these tags. Is this a big disadvantage in terms of ranking? Should we update to another platform? That's perfectly fine. Uh, we don't use valid HTML as a ranking factor. We don't uh check for these deprecated HTML tags. That's totally up to you. Uh sometimes using deprecated HTML means that it's not displayed well everywhere on all devices. Um I assume with these specific tags, it's it's less of a problem with regards to displaying the content on all devices. So if if you're happy with the way things are working on devices, then you can definitely leave it like that for the moment. Uh, should I improve quality of my page and uh when I improve quality of my page and users notices, how long until Google notices this and improves the quality of my pages and how long until Google takes that into account on the whole domain level. Um, that's hard to say. I I don't think there's any specific timeline that that we'd have available for that. Uh in general, if you improve the quality of your pages, then there's always this uh indirect effect that takes place where users love your pages and they recommend it to other people. And with those recommendations, we might find more links and pick that up and show that uh appropriately in the let me just uh mute you, Max. Uh feel free to unmute if you have any questions or comments. Um so there's this kind of indirect effect with regards to improving the quality of your pages and that's not something where there's a specific timeline on that and uh across a whole website. Obviously there's also the factor that we don't crawl a whole website on one day. Uh we have to crawl that incrementally. We'll crawl some pages more frequently, some pages less frequently and it'll take time for us to re understand this website over time. So, that's not something where you'd have any kind of like a countdown uh that we would run to update our search results based on changes that you've made on your website. There's essentially just this organic time that that it takes for everything to update. Uh we lost half our rankings after an algorithm update, probably Panda. um and other sites that copied our content started ranking above us. Will Google restore our rankings uh copy pages by others when we fix all of the search quality issues? Um in general, we will try to take that into account when we see that a site makes significant changes in the quality of its pages. So that's something where I suspect you'll see positive changes. It's almost never going to be that uh we will just restore the previous state because things evolve on the internet. Things evolve in our algorithms and any previous state will be different when you look at it now. So even if nothing happened in with your website and with our algorithms in the meantime the rest of the web will have evolved. So that previous state might be different from then the new state that that will come up. So that's something where sometimes we we see this question with regards to short-term changes, but sometimes we also see this question with regards to long-term changes where it's like three years ago my site was ranking at this position for these queries. Um I fixed the issues that were involved. Will I rank like that again? And obviously especially over a longer period of time like a couple of years, the the web will have evolved. things will have changed quite a bit in search. Uh, is it true that sometimes a domain name is never going to recover and will always have some kind of manual or algorithmic penalty against it no matter what you do to correct any previous issues. Uh, plus no matter how helpful user content you keep adding. Um, I don't know. It's hard to say, but uh for for the most part, this is not correct. So, uh pretty much everything that's associated with a website can be updated and our algorithms can take that into account. Uh for some things, it just takes much longer than for other things. So uh the never is I would say would be wrong here. But uh it's not the case that any issue that you run across on any website if you clean that up then within a short period of time you will see a positive change. Sometimes it does take quite some time. Sometimes it can even take years for for that to kind of resolve itself. Uh, my client has set the expires header to a date from two decades ago and set the cache control header to no cache for pages that are updated on a daily basis. Does this affect crawling and indexing of my pages in any way? Uh, what should we do? Um, I'm I'm not sure what you should do. That's kind of up to you. Um, essentially this is something that's more relevant for the client side. So users would would take these headers into account and they wouldn't use their cache. So that's something where if uh you really need users to update their cache every time they they visit your content, then maybe this is the right thing to do. On the other hand, if you have mostly static content and you use cache control headers that essentially prevent users from caching the content, then they'll have to fetch that content from your server every time and that might slow things down. Uh the one place uh within Google where this might might play a slight role is when it comes to embedded content. So when you're looking at things like JavaScript files, CSS, uh images, anything that's embedded within a web page, when we render those pages, which which we do for essentially every page that we crawl, uh we'll try to get those that embedded content. And if we see that we can't cache that, then we have to fetch that again as well. So that's something that might slow things down. Um so for example, if you're sure that your JavaScript page files aren't changing that frequently, maybe you could set a a higher uh cache um cache time frame there so that we can cache these p these files a little bit longer. That doesn't affect the crawling and indexing of the HTML pages themselves. It's really just for the embedded content. uh we build one of our client websites here uh and then we park this domain. Uh both are using the same C panel. Will that be a problem for SEO? Um so those are different domain names as as far as I can tell. So or different host names at least. Uh so on the one hand you have fencing um realclickstaging.com and the other one is fencingmanufacturers.com. Um they're different domain names or different sites. So we wouldn't take that into account. Uh that wouldn't be an issue from our point of view. What is sometimes an issue when it comes to to parking content on a site is if within the same domain uh or the same host name even we see some parts that are parked and some parts that are kind of live sites. Uh then that makes it really hard for us to determine is this generally parked? Should we kind of ignore this site or is this generally a live site and should we take all of this content into account? So particularly uh we've sometimes seen cases where the the dubdubdub version is actually a parked version of a domain and the non-dubdub version is the actual site and we'd look at that and see well dubdubdub is parked therefore maybe this whole site is parked maybe we should ignore it in the search results. So that's something you'd probably want to watch out for. In this case it doesn't look like that's really happening. Those are completely different host names. uh if they're on the same server or not is essentially irrelevant. Um but we should be able to tell that these are different sites and treat them differently. Uh our client is selling various types uh on supplement on his website. Some supplements are muscle recovery supplements. Uh some are post preworkout. Some are men hormone supplements. uh selling these types of supplements will affect uh his organic ranking. Um if you're trying to sell these products and you have them on your website, then ideally we would show your website in the ranking for those products. So that's not necessarily something where I'd say you have some I don't know I I'll call it shady content. Uh, in an extreme case, you have some shady content and you have some good content, then that's not necessarily something I'd say is really a problem. Um, it gets trickier when it starts looking like the site is actually hacked, where you have some content that looks completely normal and some content matches essentially what what people tend to put on hacked websites, maybe pharmaceutical spam, that kind of stuff. Then sometimes our algorithms look at that website and say, "Well, some of this looks like a normal normal website and some of this looks like a hacked site. What what is actually happening here? Maybe we should flag these individual URLs that look like they're hacked because they don't really fit into that site. Um maybe we we can't separate that out and we flag the whole site as hacked." So that's something kind of to keep in mind uh that uh your website should kind of work together as as one piece I think. Uh is there any chance that the keyword planner will be added to search console soon? What about the rumors that this tool has restrictions for users without an active campaign? Uh so the keyword planner is a part of the the AdWords tool set and I don't really know the details of what what they're specifically doing and uh from a search console point of view I'm not aware of that being actively integrated into search console at the moment. Um, I've seen some some feedback on the web uh on Twitter about about these tools and I passed that on to the team. So, they're they're aware of kind of the worries or the the difficulties there. Uh, but as far as I know, there there haven't been any decisions made in that regard. Uh, can we trust bots to correctly determine the document outline of pages using HTML 5 sectioning content? Uh, for example, can H1 elements be descendants on the doc outline or they're generally treated as top level? Um, for the most part, we don't do anything special for HTML 5. So we we try to parse the the HTML that we get from from rendering the pages and we use that to try to figure out which parts of these pages are relevant. Uh which parts of these pages add more context and uh take that into account. Uh but it's not the case that we would say well HTML 5 is unique in this specific way and we expect pages to comply with the HTML 5 standard. we essentially have to take what we get and like I mentioned in the beginning we don't uh require HTML validation so sometimes we'll be able to figure that out better sometimes it's uh it's a bit trickier uh I submitted sitemap on web masters uh in web master tools I guess 10 days ago containing 3,000 URLs and it's still processed only 80 of them without any error how much time does it usually take to process and index all URLs from a sitemap file. Um there is no time frame for that. We don't guarantee crawling and indexing of all URLs. We don't guarantee that uh from a sitemap file. Uh we use various factors to determine how much of a website we crawl and index. And that applies to URLs that are submitted with a sitemap as well. So just by submitting a sitemap doesn't mean we'll be able to kind of go off and crawl all of that content. Um, ideally we'd be able to crawl your website. We'd be able to recognize that it's high quality, unique, and compelling content and take that into account and say, well, this is something that uh our users have been waiting for or that we know users are are keen to to find and therefore we'll spend more time on crawling and indexing the website through normal crawling, but also through sitemaps uh crawling. So again, there there's no specific timeline there. Your your best bet there is really to make sure that your website is as awesome as it can possibly be. And from a technical point of view, make sure that we can actually crawl it within a reasonable time so that the server has a a low response time and low latency is able to respond to requests fairly quickly so that when we do decide to crawl, we can easily crawl, I don't know, a thousand URLs a day from your server without causing any issues. Uh Google seems to be moving towards constantly updated content and changing text. For a static uh website, this content will be staying the same. Uh what would be the best SEO strategy for Google long term? Um we don't require constantly changing content. So it's really kind of up to you what what you want to do. Sometimes we notice that for specific queries, users are looking for more fresh content, more new content. But sometimes for the same queries, uh, we notice users are looking for more static content, more reference content. So, it's definitely not the case that you need to artificially make your pages look like they're constantly changing uh, for those pages to show up in the search results. We essentially try to take what we find on the web and uh, look at what users are searching for and try to match that. So the relevance uh works. Uh for example, if uh some topic suddenly ends up in the news because people are talking about it everywhere, something some event happened there, then maybe we'll start showing newer content there. But on the other hand, over time, if when that settles down, we might say, well, people aren't looking for new content anymore. They're looking for reference material or more static type content, more evergreen content, and we'll try to show that in the search results. So, my recommendation there would be to to find your niche and make sure that you have something that's really awesome and fantastic on your website that works for for that topic that you're focusing on. And uh try not to kind of artificially make it look like something else, but rather kind of really stick to what you're able to do really well and make sure that you can do that very well. Uh there are two pages whose URLs are similar but each cover independent needs with original content and has a self-conleical. Uh however page A is indexed and page B is indexed as page A. Uh it seems Google takes B as a dupe of A. Any suggestions to index them both? Um it's it's hard to say without looking at uh the specific URLs there. Um one one thing we do uh in in some of these cases is if we can tell that these pages are essentially duplicates, we'll try to treat them as duplicates. So that's that's one thing that might be happening here. Uh another thing that might be happening here is if these URLs use parameters in in the URL and within the parameter handling tool uh we either show you that Google has determined that these parameters are irrelevant or you have uh kind of submitted that these parameters are irrelevant for us and maybe we'll say we'll crawl these URLs as one URL. So that might be another thing that's that's happening there. So in general my recommendation there would be to first of all make sure that these pages are really unique that they provide unique value of their own that they're they're different from a content point of view uh from a targeting point of view and uh also make sure that we can actually crawl and index them separately. So double check the parameter handling tool. Uh double check uh maybe from a technical point of view the the internal linking on your site that both of these are actually linked. That's not the case that you're just linking to one of them. Uh double check the canonical as well so that they're really set individually. Uh what's the impact of AMP uh to an article website and an ecommerce website? Um, good question. So, AMP is a way of providing your content um, in a way that is really fast to display for users in a way that can also be cached on content delivery network. So, these are things where um, we can try to take this AMP content and show it in a slightly different way in the search results. Um the the impact at the moment is really that we're taking this and showing it in in the search results slightly differently. We're not using it as a ranking factor at the moment. Uh because of the way AMP is set up, there are certain limitations with regards to the type of content that this works best with. And usually that's at the moment that's more the the static type content. Uh so for example an article website that would be something that would probably more be better suitable for something around AMP. Uh an e-commerce website on the other hand would be something that's probably less suitable for AMP uh just because of all the dynamic elements that that are involved there. Um, Google will treat lowquality pages uh if we change major part of the website indexed URLs page structure. Um, not really sure what what this refers to. So, I don't really know what uh what what I can answer there. Um, I have a question regarding machine generated content. Does Google have publicly available guidelines on what's acceptable and what isn't? Uh how can publishers leverage artificial intelligence algorithms to write content and not get punished down the line? Um so in general, our guidelines are pretty clear in that automatically generated content should not be indexed. So that's kind of like the the first step there with regards to what is acceptable from our web master guidelines and what isn't. Um with regards to using artificial intelligence and algorithms to create content uh like that from our point of view, you can definitely do that. We just recommend that you don't allow it to be crawled and indexed. So that's kind of the the line that that's there. If you want to provide this content to your users within your website so that they can kind of click through it and find that content, that's perfectly up to you. But if you want that content to be indexed in search, then that would not be okay. Um, search console reports some 404 errors which were never created on site and also not uh getting created by any means, JavaScript, etc. How is Google finding these? If we check the link from then it shows no link from uh pages um and it continues here for example URLs for 404 pages uh which have no link from pages for example.comappleapp association. Okay. So, I guess these are kind of two different questions. Uh, on the one hand, we we do find URLs uh in lots of different places on the web. Sometimes within uh JavaScript on your site, sometimes on other sites, sometimes they're linked within userenerated content, sometimes they're found within text files as well. So, this is something where we discover URLs in lots and lots of different ways. And uh our systems are curious usually and if we think there's great content on your website and maybe there's even more great content on your website then we'll try to crawl those URLs to see if we can find something fantastic there. So that's kind of the the first step there. Uh essentially if you see these 404 errors for URLs that uh don't make any sense, that don't really exist on your site, then that's a sign that we'd love to get more content from your website. essentially. Um, with regards to that specific URL that you mentioned, the the Apple App Site Association, um, I believe that's a specific URL related to app indexing, which means uh, our systems are essentially just double-checking to see if your site has this URL on the web server. uh because that would let us know that maybe there's an app associated with your website and that we can index it together with uh your website. So, that's something where we're just double-checking that file kind of like we double check the robots text file to see if there's anything there that we need to watch out for. And uh we use that to figure out is there an app associated with this site? And if so, maybe that's additional content that we could be showing in search results as well. Uh when do you plan to incorporate the new schemas from schema.org 3.1 into your structured data testing tool? Um, I don't know if there's any official timeline on that, but I have seen the team talk about that and uh I imagine they're they're getting ready to to implement that as well. So, I don't know what what the usual time frame is there with regards to schema.org or updates and uh updates in the testing tool, but uh we do know that these change from time to time and we try to make sure all of our tools adjust to to the new updates. Uh we have two different product pages uh like one product is 3000 series, another is 3001 series and both having mostly the same content. How does Google treat these uh pages? um if they're different pages, we treat them as different pages. If they're mostly the same page, then in general, what will happen is we'll index both of these pages. And uh if someone is doing something like a site query for your website or looking for uh that series of products in general, then we'll pick one of these to show because they're just so similar. Uh, but if someone is searching for something unique to one of these pages, we'll try to show that specific page as well. So, we'll probably recognize that there's a a block of text on these page that's duplicated across these pages, maybe across even more pages. And uh, if someone is searching for something within that block, we'll try to find the most relevant of these pages because the same block is everywhere and they're just as as relevant essentially. uh but if someone is searching for something unique to one of those specific pages and we'll try to pull that out. So that's generally not something you'd need to worry about. Uh we're online Java's training portal and we have questions which are similar looking but which are different. Uh what's the best way to index them? Should we have only one page or should all of them point uh to the same canonical? Um essentially this is up to you. So that's something where you can kind of look at this uh from from a more general userfacing point of view. Do these individual pages add value of their own or are they essentially variations of the same thing? And if they're just variations of the same thing, then maybe it makes sense to fold them together. Uh on the other hand, if they're really standing on their own, then maybe it makes sense to just keep them separate. It's kind of the same where if you had an e-commerce site, uh you would probably put each mo each product model on a different page, but if you have variations, uh of the same product, then maybe you would pull those together. So maybe you would have one page for one shoe model and all of the different shoe sizes and colors on that page as well as options. On the other hand, if you know that someone is looking for a very specific shoe model in one specific color scheme, which is really really popular, then maybe you would separate that out and say, well, this page is really important on its own. It's the same shoe model as somewhere else, but it's that really uh important color scheme that everyone is looking for. Therefore, it makes sense to separate that out. So that's something where you kind of have to look at it from a user point of view. Does it make sense to fold these together? Are these just different variations, attributes of the same thing or are they really unique items? Uh when it comes to questions from forums or user submitted questions, for the most part, you probably want to keep them separate because they are different and unique questions. But uh it's it's hard to tell for sure how how that would be in your specific case. Uh will Google treat a website as low quality if we've changed a major part of our URL rewrite? Um just looking at the URLs themselves would probably not make us uh kind of make any kind of a quality judgment. So if you're changing the URLs, then that's something that users would probably see more and it would have a more of a technical effect on our side in the sense that we have to rec crawl all of your website to understand the context of all of the individual URLs again. So that's more I' I'd say from a technical point of view, it's it's tricky and something you'd need to watch out for, but definitely not something that we'd say, well, from a quality point of view, we think your website is a lot better because you have a different URL structure. That I I don't think that would really make sense. Um, are AMP pages in mobile going to get a ranking boost? Um, I can't speak for the future. um everything can change and I know teams are working to to make lots of changes anyway uh with regards to AMP pages on mobile in general uh AMP pages are essentially mobile friendly by default. So if you have for let's let's take an extreme example if your whole website is on AMP then we would see that as being mobile friendly and we would give you that mobile friendly ranking boost. On the other hand, if you already have a mobile friendly page and you add the AMP pages in addition, then nothing really changes there. They're still mobile friendly. You still have that mobile friendly ranking boost. Uh kind of the the fact that there are AMP pages there additionally doesn't give that site any kind of a ranking boost. Um obviously that could change in the future. Um it's it's really hard to say at this point, but uh in general we we do try to make sure that uh the search results remain relevant and we show something that's useful for the user. So sometimes that can make sense to to have a a ranking change there. Sometimes it it doesn't make that much sense. Uh why being on position one for a query? Uh the content is high quality so that it's first position. Google shows a diff the different website with featured snippet for the same query. Uh ranking algorithm for both are different. One website with pos six position getting all CL. I'm not really sure what you mean here. Uh can you elaborate? Yeah. Hi John. Uh just a few minutes back I joined this. Uh actually the thing is John that for some queries we are ranking on first or second position but some websites are just using uh you can say tabled data or just in bullet points data and after some time we see that they are coming up for the same query they are showing as featured snippet. So my point was that we were we are already using best content but not in table form or not in bullet point form while they are only using the data into this form and just rank coming higher than us. Yeah. I mean we we use a lot of factors for crawling, indexing and ranking. So it's it's hard to say what you should be doing differently in a case like that. Uh when it comes to featured snippets, we we do sometimes show results that are not the first in in the normal search results as well. So that would sometimes be normal that h you would see another site getting a featured snippet uh while while your site is essentially ranking first there. So that's that's something that that can sometimes happen. Um obviously that can also happen in a good way for your website. If you're not ranking number one, then we could sometimes show your site as a featured snippet uh despite it not ranking number one. So, that's something where sometimes it makes sense to look at your content and think about what you could change there to to make that uh more relevant for for easier pulling out for a snippet. But sometimes that's essentially just a difference in the way that different websites kind of handle the same problem. So John can you tell me uh what factors are helping us in ranking as featured snippet depend from any algorithm factors or um I I don't actually have any ranking factors that uh will get you kind of guaranteed a featured snippet. So I yeah um we we've talked about that uh with the team a few times and we we've discussed like maybe we should have a structured data markup that people can use to to create get featured snippets. Uh but for the most part, the team is happier to kind of organically take the content uh from a website and show that as as a snippet as appropriate rather than rely on web masters adding even more structured data markup to their pages where they're already kind of getting overburdened with with the different markup types out there. So ideally, we'd just be able to pull that out organically from a website and show that like we like we show any other type of snippet in the search results. Okay, thanks. Um, can you add third important point in SEO? First is speed content and next is I don't think we have something as simple as the top three ranking factors that uh you need to focus on. U I think speed and content are definitely good things to look at. uh but uh there there are lots of things that we use to try to determine the relevance for specific queries. So my my recommendation there would be not to focus so much on individual items but rather make sure that as a whole your website is really providing the best value it it can possibly provide. So that's something that's obviously harder to express in any uh specific factors, but uh oftentimes we'll see that websites try to focus on technical elements or try to focus on one specific factor and kind of lose track of the bigger picture. Namely, that users want to find something that's really fantastic for them, that's easy for them to use, uh that gives them additional value, that uh is of high quality. So that's something where where I'd recommend not just focusing on individual elements but rather taking a step back and looking at things overall. Uh we recently flew out of the index before two days with our complete.de domain and uh their main page and product pages. We didn't do any changes. Uh we don't know the reason uh for that. Are there currently any changes or testings happening in fact of redirects? Um it's hard to say what what might be happening there. If in in general um one thing I try to to figure out is if this is something that's uh kind of an immediate change that happened or if it's something that happened more gradually. Uh if it's something more of an immediate change where really the whole website disappeared from one day to the next, then it sounds like that might be some setting that you have maybe uh with the URL removal tool that you accidentally remove the whole domain from the search results. On the other hand, if you're seeing more of a gradual change, then that sounds more like something maybe technical on the website where we're having trouble crawling and indexing it properly and we're kind of dropping the most important pages quickly and then kind of you see this kind of gradual curve of the rest kind of disappearing. And that's usually something that uh you can control a little bit better on your side and try to figure out what what is happening there so that it kind of comes back again. But if you can't figure out which of these it might be, uh, I recommend posting in the help forum and getting some advice from other people who can give you some ideas on what settings you should look at, what things you should test, and they're usually also able to escalate that to us if it's really something where something totally unexpected is happening that uh, nobody's able to figure out. Um, does Google really rely a lot on the Moz DA? Uh, my AHF's ranking is pretty high. However, Moz takes a long time to index my back links. I've been creating backlinks since 22 days ago. Um, also I see a lot of bots coming to my website. Is that bad? So, where do I start? Um, uh, we don't use the Moz tool for crawling, indexing, and rankings. Um, we don't use a refs either. Uh, in general, sometimes it makes sense to use thirdparty tools like those. Some of these tools are really great for kind of diagnosing issues on website, understanding a website properly. Uh, but uh they're thirdparty tools. They're not associated with what Google is actually doing. Uh, with regards to building back links, in general, I'd recommend making sure that your back links are organic, that they kind of grow on their own rather than that you go out and build them because if you're going out and creating these back links, we would see those as nacho links and they might cause more problems to your website than they would actually help. So, that's something I definitely avoid doing. So taking a snake back looking at this question, I'd recommend making sure that your website as a whole is really the highest quality possible that you don't focus on creating backlinks manually and that you use these third-party tools in a way to improve your website and to understand your website better from both a technical and from a quality point of view. But keep in mind that these are external tools. They're not used by Google. So, they should be help better, but they're not something that would be indicative of anything that Google is going to do with with your website, with your content. Uh, will Googlebot crawl the content or text which is used in JavaScript tags? Um, if we can crawl the JavaScript files, we'll try to crawl them. So crawling from from that point of view probably we will crawl that with regards to indexing the content that depends a bit on on the pages. If we um render the the the page using that JavaScript and that text appears on that page then we'll try to take that into account for indexing. On the other hand, uh if we render that page and use the JavaScript file to kind of render the page and that text is more like a comment uh within the the source code or is something that's not actually displayed on the page when the page is rendered, then probably we won't take that into account. Uh does the order of a of ATF lang tags matter? No, the the order doesn't matter at all. Uh, one thing I would just watch out for if you're using HF lang tags within the head of your pages is make sure that those HF lang tags are towards the top of the head so that we're sure to take that into account because if they're lower in the head and especially if you use JavaScript to kind of modify the head in any way, then there's a chance that they will essentially slip into the body when we render the page. And if they're in the body of your content, we can't take them into account as HF lang tags. But uh the order which which languages you put first, it's default first or kind of English first or French first or whatever, that's totally up to you. That's uh not something we care about. Uh in featured snippets, there are a lot of fluctuations recently on the same query it appears and after some time it doesn't. Also, the results in featured snippets are changing quite frequently. uh any updates on this? Um our algorithms are constantly in changing. So I think it would be normal to to see fluctuations with regards to uh featured snippets like that as well. So that's not something where I'd say there's anything special you need to watch out for. Um how how to participate in a live blog. We've implemented all the guidelines for the same including schema design etc. Uh but it's not working in search because it's open for initial providers. Rest of schemas work uh on our domain for example ratings news article recipe etc. Um, I'm not 100% sure, but I believe for some of these early features that that we have available there, there's a form in the developer documentation that you can use to submit your site for review uh by the team. And uh, for some of these features, we're still kind of figuring out what what the final setup will be and how we will show these in search. So, it's kind of limited in the display. Um, but uh if you've already set that up, then let us know about that through that form. Uh, if you can't find that form, you can also send it to me by Google+ and I'll just forward that on to the team. I can't promise that the team will be able to take that into account for some of these features. they get a lot of submissions uh but they still sometimes they want to limit things a bit to make sure that it's all really working the way it's expected before they open it up to a broader audience. Uh should we avoid placing primary page content in tabbed or expandable modules on a page as it may be discounted by Google even though it may provide a better user experience. So from the question, it sounds like you already know what what we've been talking about. Uh namely that uh if this content isn't visible on when we load the page, then we assume that it's not the primary content. So if it's really primary content for your page, for your users, then that's something I'd make sure is really upfront and center when people actually open these pages. So from that point of view, if it's the primary content, make sure it's visible as the primary content. If it's not the primary content, if it's just additional content uh that provides some additional value, uh then maybe it makes sense to keep them in in a tab section or some section that's not immediately visible. Uh if this is really important content that you do want to make sure that it's indexed separately, then it might make sense to actually make a separate URL for that content. Uh generally Google doesn't want us to use one domain to one city. Recently one website was targeting and it was duplicate content only the name was changed. Uh so he was not able to use any HR lang and also the cache of one website was coming out of the other website. Um can you elaborate? Yeah. Yeah. Yeah. John actually uh someone from India India was just having different cities matrimony website basically like Bangalore matrimony.com or Delhi matrimony.com. So uh he was he he told us that uh only one version of his website was indexed and uh other versions were not indexed. So obviously for each city it is not recommended to use one domain and the website was duplicate. But we were not able to tell him how to deal with this except saying that please have only one domain. Yeah. We we would see that essentially as doorway sites. So from a from a technical point of view, we try to recognize that all of these belong together and just pick one of them to index. Uh from a web spam point of view, if the web spam team were to take a look at that, they would probably remove all but one as well. So that's something where you really need to make sure that you have one website with your content. Uh so that you're really kind of focusing on one website. I think from a from a marketing point of view, from a general SEO point of view, that also usually makes more sense because then you have one domain which you can build up which can be really really strong rather than all of these individual domains that you have to maintain separately. So that's something that kind of from multiple points of view makes sense to to fold everything into one thing instead of keeping them on separate sides. Okay. Thank you. objective. Uh, search results pages on our real estate websites sometimes return very similar listings due to properties being located in neighboring suburbs. Does this count as duplicate content? And how can we improve our relevancy signals for Google to avoid duplicate content? Uh, so we would probably look at these pages and say they're not completely duplicate. So we would index these pages, but we would recognize that individual blocks of text are duplicated across these pages. So we would probably pick one of these pages for indexing or for showing in the search results rather than all of them. So ideally on the one hand I'd make sure that you're not allowing random search results pages to actually be indexed but rather that you're providing a kind of a category page experience essentially so that you really know that the URLs that you have indexed are providing unique value of their own and uh really work together like that. Uh the other thing that we often see with regards to search results pages is that you can enter any any possible search query and it'll create a page for that and that can make it really really hard for us to crawl your website and and result in us kind of being lost within a sea of URLs from your site. Uh, can you clarify the difference in image requirements for Google News? The news article structured data page states one size and the Google News image help page states another. I took a quick look at this uh yesterday and essentially the the Google News recommendation has a minimum size of something really really small. And uh for the the article structured data page, the markup that we use for AMP pages within the um what is it uh the in the news section on in the search results that specifies a bigger size. So for Google News alone, you can definitely use those small pages. If you want to be included in the AMP um in the news section there, then that's something where you need to comply with the the AMP markup, which requires a a larger image. Okay. Uh we just have a few minutes left, so maybe I'll just open it up for more questions and comments from you all. What else is on your mind? I've got another one, John, if that's okay. Sure. Um, so our developers here, back on the subject, 301 redirects, they were saying that a browser will cache a redirect. So once it realizes a redirect, a permanent redirects in place, it will remember that redirect. And even if I were to change the destination that it may still remember the original redirect was in place. Um, the question they asked me was, would Google do the same? So once it recognizes a 301, would it then if I change the destination URL, would it always remember the original one I'd set up? Probably not. So we we tend to retry URLs fairly regularly. Not as often as URLs that we know are kind of the destination URLs, but we we do retry them regularly. You'll you'll usually see this more visibly when it comes to error pages, for example. We'll know that it's an error page, but we'll still recheck it every couple of months. So that's that's something where we we understand that the web can change and even though you technically told us this is a permanent redirect and we'll never change, we will go back and double check that every now and then to make sure that we're doing the right thing. That's great. And then one other very quick one. Um so we're an e-commerce site. So one of my challenges is to get uh make a category or a list page that essentially just has products on. How to make that useful beyond it being a list of products. Uh, one thing I've noticed a lot of e-commerce sites doing is dynamically bringing in some key features of the products from product pages onto the lister. So, two or three bullet points. Um, feels like quite a useful thing to do, but I just be interested to know your thoughts on that. Sure. I mean, anything you can do to make sure that these pages provide unique value of their own. I I think that's that's totally fine. Fantastic. Thanks very much. All right, more questions from you all. Uh I would have one last quick question. Um we just relaunched um picture gallery and basically we've done that for our Austrian domain and we have millions of pictures. But the thing is we used to have two pages or two URLs that would have like the full screen and like a small more thumbnail type of version of the image but it would be for that specific image. Now we did the relaunch. We try to do everything, prepare everything with canonicals from the full screen version to the small one, redirects, everything. Um, now the whole thing, the problem is we have the same content, the old content on the German version. So what what we're seeing is we just get instead of having the new better Austrian ones, we have the old German ones. I just I don't know what to tell the team. like you're going to have to wait two weeks until tell I can I can tell you what to do or and it's just holding the whole development process back a little bit and I'm a bit under pressure of telling them okay two weeks one week. Okay. So you have the same images on on two sites is that correct? Uh yes like but for different countries. Yeah. Um and are you looking at image search or is this in in web search? image search both actually like sometimes you know it the results show up in both primarily image search so there are a few things uh on the one hand for images we don't use the real canonical so if you have the real canonical header in the images themselves we don't use that um on the other hand we rec crawl images much less frequently than the normal web pages so if you make any changes with regards to the way your images are embedded on pages, then that's something where you'll probably see quite some time for that to to settle down properly. So, that's like in a situation where you do one-time move, that's obviously something you kind of have to wait it out until it settles down again. um in extreme situations which we've seen where people append uh kind of session ids to the image urls or dates to the image urls to make sure that they're they're constantly refreshed then sometimes what we'll see is that they're never actually indexed properly. I I don't think that's the case in your situation. U but uh especially if you make changes with regards to the landing pages or the image URLs, then that does take