 All right, welcome, everyone, again, to today's Webmaster Essential Office Hours Hangouts. My name is John Mueller. I am a search advocate at Google. And part of what we do is connect webmasters, site owners, SEOs with the search teams at Google. We had a bit of technical issues here. Sorry about that. Hopefully, this one will be a little bit better. But a bunch of questions were submitted. And Barry asked a really good question to start off with. So why don't you give it a start again, Barry? Thank you. I don't know if it's really good, but I'll ask it anyway. So on Friday, again, you said that if somebody was impacted by a Broadcore update, that site would not necessarily have to wait for the next Broadcore update in order to see an improvement or even a full recovery in its rankings, I believe. And then I looked at the Google blog post about Google Core updates on the Google Webmaster blog. And it says, it kind of implies that you probably might have to wait until the next Broadcore update to be released, although you might not have to. Sometimes they make smaller core updates. Or maybe there's other algorithm updates that might see the site improve over time. So you give this really, really nice explanation about how things might work. And we discussed how Panda and Penguin, and how it's not the same. So if you could just spend the next 45 minutes discussing how the algorithms work. OK, 45 minutes seems like a long time. OK, but yeah, I mean, in general, the bigger core updates are really kind of changes in the way that we calculate things on our side when it comes to the different ways that we look at a website. So it's kind of a different way of looking at the relevance for a website. But essentially, things can change incrementally over time. It's not the case that a website is stuck in one particular position until the next Broadcore update. It can happen that a website is strongly affected by a core update. And then over time, it kind of results in the state where it's kind of back in a previous position. Some kinds of really strong changes when it comes to core algorithm updates do need to kind of wait for that bigger core algorithm update to be reprocessed again. So that's something where it's, on the one hand, some really big changes might be things where you need to wait until we're able to reprocess things and take a quick new look at the way we would want to consider relevance. But a lot of small things along the way essentially can be adjusted over time. So it's not the case that if a website is negative affected by a core update that it needs to wait, you can definitely make changes over time with your website as well. So you kind of also explain that with these core updates that the actual scores within them may be refreshed continuously or regularly, not in real time, but regularly between core updates, unlike when it came to, let's say, the old Pandora Penguin updates, where that score would be assigned to whatever those scores would be, would be assigned until the next update would be released. In this case, these core updates are different in that those scores are regularly refreshed throughout and between different core updates. So that's true. And although most SEOs I've asked, saying they would never see a site recover from a core update until the next core update, that is not true and that could definitely happen. That can definitely happen. I think the important thing to keep in mind is that if a website is negatively affected by a core algorithm update, it doesn't mean that you can't do anything. You have to wait it out. It's really the case that you can improve things. And when the next core algorithm update comes after a couple of months or whenever that is, on the one hand, your website will be in a different state, which will probably be a better state. And on the other hand, our algorithms, when they look at that again, they're able to see and can confirm that better state as well. So there are certain things that kind of require us to rethink how we would calculate a score. But a lot of times we can just calculate it in the same way using the new data that we have. OK, thank you. John, a quick follow up on that. A different one this time. So I know you mentioned at some point in the past that it's, and I think it's mentioned in one of the blog posts as well, that it's not necessarily the case that you need to do something about that specific page if you're negatively affected by that update. It's not necessarily the case that your pages has something wrong with it, but that Google might decide that other pages are simply more relevant in that specific period of time or for other specific reasons. So would it be a good strategy to kind of, if you were negatively affected for certain queries, just to look at what other sites with other pages are now ranking well and kind of try to understand why Google prefers to rank those pages ahead of yours? I think that's reasonable. I don't think that's kind of totally out of the question. I think I would discourage just trying to chase the other websites the whole time. But if you do notice a bigger pattern where you're like, well, like everyone else is doing things in this way now and I'm still doing things in a very old way, maybe it's worthwhile for me to reconsider kind of also modernizing things. And it might be that you say, I'll do it the way that the others are doing it. Or it might be that you say, oh, I can do a user study and work out where things will be in the future and kind of jump to that already. All right, I'm thinking of a simple example. Maybe you have some commercial content that went down in rankings, and you kind of notice that Google is now ranking more informational content for some reason. And you don't have that. And maybe it would be a good idea to also have some informational content since it seems that users or Google believes that users are kind of preferring that kind of content when searching for those queries. Something like that. Yeah, yeah. I think that definitely makes sense. I mean, it's always something that can change over time. It's not the case that Google decides that this is the kind of content that people want, but rather we kind of see how things evolve on the web over time, over the whole web. And we think, well, this is probably a reasonable direction to take. So just because we might show more informational content for some queries that you're looking at maybe doesn't mean that you should change your whole site strategy and throw away all commercial content because you still need to sell something to survive. It's not that you can just swap everything out and say, well, Google says this is the answer. I will make everything the same answer. Oh, sure. I was thinking, in addition to your commercial content, maybe add some informational content as well. Because I think that a good reason to kind of look at the search results and see what's ranking is to also kind of try to figure out what the user behavior is because Google tries to make sure that the top 10 websites or the websites ranking well are offering a good user experience and a good result for whatever query the user has. So trying to see what kind of results show up in the first page in Google can kind of give you a glimpse on, maybe this is what users are finding relevant specific to those queries. OK. Yeah, I mean, any kind of user studies that you do essentially is a good idea. Now, cool. OK, let me try to run through some of the submitted questions. We don't have a ton of time this time, but we'll see how far we can go. The first one on top is about our domain migration. We talked about this one pretty extensively last time. I don't have any new information to share there, but the team has been looking into what might be happening there. So maybe we'll have something in the future there. Then a question about deleted pages. In my search console, there are around 15 million pages reported as crawl anomaly. From the 1,000 sample, I've seen that 90% of these are deleted. Since January, every day we have removed thousands of URLs, but not 15 million. So it's too big compared to the valid URLs. Is there any way that we could better approach crawl anomaly? So crawl anomaly is a collection of various different kinds of crawl issues that we run across, including issues where it's not necessarily a technical crawl error. So it's not that there's a 404 or 403 or something like that that happened. It could be that there was a server error that took place. It could also be that it's something like an empty search results page that we ran across, where, especially if you're talking about a site with millions of pages, it's very common to run into these empty search results pages. And from our point of view, for the most part, these are things that you need to take into account or work on. That said, with one of the future updates of Search Console, we're working on getting rid of the crawl anomaly altogether, not in terms of just hiding all of this data, but instead taking it and reclassifying it as something more useful. So instead of collecting a bunch of things and putting them into crawl anomaly, we'll kind of split that out a little bit. I don't know about the timing on this. It's not happening today. It's not just around the corner, but I know the team has been working on this for a while now. Do I still have to worry about having product schema if I already have a product feed in the Merchant Center? So this is something that I think is coming up more and more in that with the rise of organic shopping results, a lot of people tend to do both, kind of set up a Merchant Center feed, set up a Merchant Center account, and have the structured data on their pages. And from our point of view, at the moment, it's definitely the case that you can do both, and it makes sense to do both. Because the structured data on your pages is what we would show in the search results, and the information from your feed is what we would show in the organic shopping results that we also provide. So essentially, it leads or can lead to the same URL on your website, but there are different ways of giving that information. I suspect at some point we'll work out a way to make it so that you can just focus on one or the other, and you don't have to do everything double. But at least at the moment, that's the situation that you can submit your products through Merchant Center with a Merchant Center feed. That information is directly taken into the organic shopping search results. You can also provide some structured data on the pages, and we show that as a rich result in the search results. One of my clients has very weird structured data on page. They have two product schemas on the same page. Each of them is missing certain recommended fields, but both of them combined are eligible. Would that work? I don't know. It's something where I would use the rich results testing tool to double check what we see overall for that page and focus on that. I think ultimately I'd recommend cleaning this up so that you don't have this fractured structured data on these pages, especially if the structured data is of completely different types, like one micro data and the other one with JSON-OD. Then to test that and maintain that on your side is going to be hard anyway. So that's something I try to clean up. But it's possible that we would be able to combine those two and to treat it as one set of product structured data. Our site has lost a lot of rankings in the past three months, and we're trying to figure out why. Now we have two main guesses, because of the 200 backlinks that we lost due to cleaning up of a manual penalty back in April, or because of a new WordPress theme we switched to in June, which is very slow. Gets a score of 20 out of 100 in page speed. How much impact do you think each of these changes had on our SEO? So the first one is impossible to say. It's something where I can't really say what the actual effect there would be, because if your website just has 200 links and you remove all of those links to your website, then obviously that will be something that is more of a stronger effect. On the other hand, if your website has millions of links and it's well embedded within the web, and these 200 backlinks are from a paid campaign that you did, which ended up not being no follow, then that's probably a minimal change on your website. So that's kind of the one thing. The other thing there to keep in mind with manual actions in general is that if you clean up a manual action, that essentially means in the past, your website was ranking in an artificial situation. And the manual action kind of took care of that. And if you clean it up so that the manual action is no longer necessary, then your website is ranking in a different situation. And it can happen that it's very similar to before, but it can also happen that your previous positions in the search were artificially strongly inflated due to the things that the manual action was looking at. So that's something where you might see a stronger effect from manual actions and cleaning that up over time. But it's really hard to say without looking at your website. The theme change is something I suspect is less likely, but there might be an effect that you're not thinking of. So on the one hand, the speed change, I doubt that would be negatively affecting your website in a really strong way. We do take speed into account when it comes to search, but we currently only do that on mobile. And that's generally more of a kind of a soft factor with regards to rankings. So I don't think even a fairly strong change in speed over that period of time would cause your website to drop significantly in search. However, if you change the theme of your website, kind of the template, the way that your site is put together, it can also happen that you change other things on the site. And that can include internal linking, like how the different pages within your website are connected, which ones we think are most relevant or least relevant with really bad internal linking. It can be really hard to determine that. And with much improved internal linking, it can be a lot easier to recognize the important content on your site and to rank it really well. So that's something that can happen there, but also the way that you present your content can change. And that's something that probably, if the content itself doesn't change, could still have a minimal effect, not really strong on them. So one example that we sometimes saw with the mobile first indexing update is that if an image is seen as very important for a page and it's embedded very visibly in kind of like the center of the page, then for image search, we can say, this is a really good landing page for that image because when a user goes there, they find that image front and center. Whereas if your theme changes that so that that image is no longer front and center, but rather kind of the thumbnail on the bottom right corner of your page, then at least for image search, we could look at that and say, well, this is not really a great landing page for that image anymore because that image is not something that users would spot offhand. So that's something where kind of the design, the layout of the pages can have an effect. In this case, it's mostly about image search. It kind of depends on the way that you have your website set up. My guess is if you're just changing themes slightly and it more or less looks the same, it's just kind of a little bit slower because you have some fancy animations or something like that embedded there, then that theme change itself will have minimal to no effect on your rankings. Does a 410 gone send a better signal than a 404 not found that a page has been removed and will not come back? We've been using 410 for removed content and for 404 for URLs that never existed, but not sure if it's the best approach. So in the past, we've recommended using 410 in situations where you want to remove things a little bit faster. That's still the case, but I think in the bigger picture, it doesn't change anything. So if you're looking at a website over a longer period of time, then whether it returns 404 or 410 for individual pages that you don't want indexed, doesn't change anything. It's really just that initial moment from when you remove something to when it's removed from search. And if that's really critical for you that it's removed quickly, then I would use a removal tool anyway. But otherwise, that difference between 410 and 404 is almost a theoretical difference and not something that you need to worry about on a day-to-day basis. I submitted a site move back in February 2020, and it's still pending as of this Friday. Based on the timeline of the pending site move, does this indicate that there's a problem with the site move? No, that's definitely not the case. The pending site move essentially just says your site is still listed in our systems as kind of a site move that you initiated yourself, and that's useful for us. It doesn't mean that there's any problem there. It's not the case that you see a status update with the site move where it says, oh, it's complete. You don't need to do anything anymore. It's really just, well, the status at the moment is it's moving. And maybe it's completely moved since February, but you still have that setting set that says, oh, I really want that new URL visible instead. The pending site move disappeared from Search Console in Monday, August 31. I submitted the site move request and the quick validation passed again. Yeah, this is essentially just that setting timing out. That doesn't mean anything. That should be fine. Lastly, the site ranking has taken a hit. Based on my analysis, it appears to be related to the incomplete site move. What are some steps that can be taken to push the site move through? So just to kind of soothe your worries there, this wouldn't be related to the setting in Search Console. If you're seeing that something is incomplete with regards to site move, then one of the effects that you would see is that you see traffic going through the old version of the website. If you do something like a site query in the search results to look at the old domain, then you will always see the old domain there because we kind of have that association that, oh, there used to be content here, but now it's here. And if someone explicitly looks for the old content, we'll be like, oh, yeah, sure. We know that there was content here and we'll show it to you, even if the site has already. So a site query won't tell you if things are incomplete. It's more within the search results themselves, within the traffic that you see from Search where you would see if maybe a site move is incomplete. And in a case like that, where the site move is incomplete, usually the issue is that the redirects are not set up properly. And usually that's something that is kind of easy. I don't know. Well, easy is always an overstatement. But it is something that you can take a look at the individual URLs that are getting traffic from Search and try to figure out, are these redirecting properly? Why might Google be showing the old URL instead of the new ones? You can also think of all of the other things we have in the site move help center article, which includes things like have you updated all of the links within your content? Or have you reached out to the more important people who are linking to your website externally that they also update their links? And sometimes these kind of changes can affect which URL we show in Search. Is keyhole markup language still relevant to SEO? So KML keyhole markup language is something that you can use in Google Earth or maybe even Google Maps to kind of define geographic settings and things like that. And way in the beginning, there were things like geo-site map extensions, I think, where you can include KML files. But as far as I know, that's no longer relevant at all. So at least from my point of view, that's not something you have to worry about. As far as I understand, the language and the file format continues to exist, and you can still use it in some of the kind of geographic information systems. So if you have files like that, maybe they're still useful. Maybe they're not that useful. It's something you can double check on your side. It wouldn't affect SEO. Does Google ignore tracking code script when crawling pages? Sometimes, sometimes. So not necessarily while crawling, but when we render a page, if we recognize that certain scripts tend to have no functionality at all, then we will skip them when it comes to rendering. And a really common one here is Google Analytics, because that's something we see all over the web. There are lots of other analytics scripts that we also tend to skip like that. And essentially, it's not that we're trying to recognize if there's a tracking script here or not, but it's more we're trying to optimize how we render pages. And if we can recognize these scripts are not relevant for rendering of a page, we can skip them and move forward a little bit faster. John, can I ask you a question about the e-commerce page, category pages? So you did an interview, I think, with Mary Haynes, where you had said that there's risk when you put content on these category pages that Google might only rank them now for informational and not transactional searches. So I've been doing that strategy for a long time, putting content on those category pages. And it seems to work well, but I didn't know that there was this risk here for that issue. So can you clarify that a bit more and put me at ease? Because it seems to work. If it works for you, then it must be good. I don't know. So I mean, the thing that we see is not so much that there's any informational content on these pages is problematic, but if it really gets to be overboding. Whereas when we look at the page itself and there are like five items listed in the category on top and then there are five Wikipedia articles of content on the bottom, then that's something where we might look at that page and say, well, overall, this is more of an informational page about this type of product and not something where a user would go to actually purchase this product. So that's kind of the problem that we see sometimes. And usually the effect that this runs into is more along the lines of keyword stuffing than anything else, where we see like, oh, you mentioned this category name 100 times, 200 times on this page. Is it really the most important word on this page or is it something that's artificially inflated? And if we see it's embedded in these kind of Wikipedia articles of content, then we might say, well, it might be artificially inflated. So that's kind of the extreme case. On the other hand, there's also the situation where an e-commerce page has absolutely no informational content at all and is essentially just a list of products. And from our point of view, that's also hard to parse because we don't really know what this is about. We might find different brand names, different type names listed there with an image embedded with them, but we don't really know. Is this shoes? Is this shorts? Is this sportswear? What is kind of the overall goal of this page? So some amount of informational content is good. No informational content is kind of problematic. And too much informational content is also problematic. So you're kind of aiming for that center area there. And that's something I see a lot of sites doing this really well. They have good kind of, I don't know, baseline informational content there. FAQs, for example, so you can get the schema snippet. Seems to work really well as well, I find. Yeah, I don't know about FAQ there. It's kind of borderline from my point of view because often you end up having the same FAQ on all of these pages. And from our policies, we say we shouldn't have the same FAQ on the page. No, I wouldn't do that. It's like on a category page about men's shoes have one FAQ versus the category page about women's hats. It would be a different type of question and answer. So yeah, I guess it's about the balance between volume of content and as well as is it actually helpful and not duplicate or anything like that? That's the idea, yes? Yeah, yeah. Thanks. John, related to that, I know you also mentioned, I think it was also in one of those interviews where you mentioned that footer content can also be problematic, especially since users don't really get to see that content sometimes. Especially if there's an infinite loading of products or something like that, they definitely can't get to the footer to actually read the content. Can you kind of elaborate on that? Is this still not really a best practice to do that when it comes to adding a bit of content to these kind of commercial category pages? I don't know. I think, in general, adding things to the footer is fine. I mean, it's always kind of this gray area anyway if you add it to the bottom of your main content or the top of your footer. It's kind of physically the same thing, right? It's not really different kind of location. So from that point of view, I think that's kind of OK, yeah. So does Google take into account whether how easy it would be for the users to kind of read that content? So it's not really just added for search engines to understand what the category is about, but users can actually use that content for some reason as well? I don't know. I don't think we would take that into account, apart from the usual things like, is it actually readable on the page or is it essentially hidden content? But for the most part, if it's in the footer, then it's something we could take into account. I mean, what happens when we render the page anyway is we try to do that viewport expansion where we try to find the size of the page itself. And when we do that, usually we would see the footer there as well. And we would say, well, there's content here. It might be relevant to the page. We can definitely include that. Yeah, so from that point of view, I think we would just see that and treat it as normal content that's located towards the bottom of a page. OK, so there's still a difference between content that's higher above the page, main content that it's in the first fold, for example, versus content that's all the way to the bottom of the page, but not necessarily a problem, per se, just where you think the content might be more relevant for users as well. Yeah, I mean, for the most part, I just see that working out. It's not something where I mean, let's just say, I haven't run into a situation where the indexing team tells us to contact the site and say, oh, you should move your content from the footer to the top of your page so that we can index it better. That's something that they would say if we really have trouble picking up the content on a page, but that kind of situation is not something that has come up in the past. No, I'm just talking about situations where certain webmasters might know that they need some content on these kind of commercial category pages and they add a whole article at the bottom because there's no way they would add it to the top where it could push all of the product listings further down the fold. That's kind of the case, a kind of extreme case, but I've seen it happen where they have a lot of content. They want to add a lot of content to make sure they target all kind of keywords. So they put like a big chunk of almost a whole article after the product listings. Yeah, but that kind of goes into what we talked about just before, where it's basically like you're overfilling the page with essentially textual content. Well, it's not really, which is not really a good practice. Yeah. Also, regarding what you say about using certain kind of keywords over and over again, I'm guessing Google can handle well a situation where like you have a category of Intel processors, right? And every product is called Intel some code, which is the processor code. And you have all of those products starting with that brand name. That's not necessarily a problem. That's just... That's normal. Yeah. I think someone else had a question like someone in the chat. I keep seeing it pop up, but maham, nobody. Okay. I mean, feel free to jump on in. We have a few minutes left. If there's anything on your mind that I can help with, yeah, go for it, Basil. I think you're muted, or at least I don't hear you. Oh, okay. In the text, let me see. If a website is indexed by Google regularly and were to turn into 404 or domain expires and would Google de-index immediately? Usually not. So there are two things that happen here. On the one hand, we re-crawl these pages on a per-page basis, and some pages we re-crawl very frequently and they will drop out fairly quickly. Usually this is like the homepage, the higher level category pages, those kind of things, they would drop out fairly quickly and the pages we don't crawl that often, we wouldn't see that they're 404 that quickly. So that's kind of the natural situation. However, there are two other things that can play in there. On the one hand, when we see a bigger change on a website, we will try to re-crawl the rest of the website as quickly as possible. So that can happen if we see things like a theme changes within a website or we see significant internal linking changes or we see significant, I don't know, structured data changes across a website, then we might say this is a significant change on the website, we need to refresh our index much faster than normal. That's kind of the one thing that can happen. We try to do that, I mean, that happens automatically, it's not something you need to trigger. And the other thing that happens, especially when a website expires or turns into 404, is we try to recognize that the website no longer exists and we tend not to show it as visibly in the search results. So it might still have a lot of pages indexed if you search for the website directly. But if we think that the website has expired and no longer exists, then we will try not to show those pages in the search results. So the site query will still show them, but the normal kind of queries for those pages, they won't show them anymore. So those are kind of the effects that play in there. John, can I ask a question regarding e-commerce? Sure. All right. Would you recommend working on your research and working on particular pages or improving the quality and improving the overall quality of the website or working on particular pages? I think both make sense. And it kind of depends a bit on the size of the website itself. So especially if you're talking about a smaller website, then crawling will be unproblematic for us, even if you have a complicated URL structure. If you have 1,000 products and you end up having 20,000 URLs on your website, we can deal with that. That's not bad. It's not great. It's good to clean up, but it's not terrible. On the other hand, if you have millions of products and you have hundreds of millions of URLs because of a messy site structure, then that can significantly affect how we process the products on your page. So that's kind of, depending on the size of the site, I would focus more on the content or more on the technical side. Rather, when you have a really large site, you have to essentially do forth, right? Yeah. I mean, from my understanding, the page rank algorithm, I'm more talking about the old school page rank. From 1990, it was based on page level. I don't know about now, but are there any algorithms that might measure the overall string of the domain, like mass-symmetric rate? Could it be, I don't know, maybe the overall quality of the profile of the old site-driven pages? I'm not aware of anything like that. I mean, it's something where usually the crawlability is more of a technical issue rather than a score that we would calculate. So it's not that we would track kind of the crawlability or the messiness of a website. What we might look at on a domain level is things like, what is the overall quality of this website so that when we find 10 new URLs from this website, what should we do? Should we treat them as really important or are they just content that we've otherwise seen on the web as well? Thanks. Sure. OK. I need to jump to the next meeting. Sorry that this one has ended up a little bit short with all of the issues we have with the other Hangout. I will figure out with the Hangout folks to see what we can do to improve these going forward. But thanks for your patience. Thanks for jumping in on the other call as well here. And I hope you all have a great day and see you in one of the future Hangouts. Bye, John. Cheers. Bye, everyone. Thank you, John. Bye-bye.