Reconsideration Requests
18/Dec/2018
 
Show Video

Google+ Hangouts - Office Hours - 23 December 2014



Direct link to this YouTube Video »

Key Questions Below



All questions have Show Video links that will fast forward to the appropriate place in the video.
Transcript Of The Office Hours Hangout
Click on any line of text to go to that point in the video


JOHN MUELLER: OK, welcome, everyone, to today's Google Webmaster Central Office Hours Hangout. My name is John Mueller. I am a webmaster trends analyst at Google in Switzerland, and I try to connect webmasters, publishers like you all, with our engineers and make sure that information is flowing in both directions. So we have a bunch of questions that were already submitted, but if any one of you who's in the Hangout now wants to go ahead and jump in and ask a first question or two, go ahead.

BARUCH LABUNSKI: I have question about 301.

JOHN MUELLER: All night.

BARUCH LABUNSKI: So we all know everything about 301s and so on, but I just really wanted to ask you, I made a really big change to this page, and I 301'd everything correctly in the entire site, so all the URLs, everything's fixed. So now I fetched Googlebot, and it took over two weeks, so the URL is finally showing up. But how long would it take for all the juice to pass from the old page to the new one? And I know you've touched on that many times, and I just wanted you to clarify that. If it's possible.

JOHN MUELLER: So that's just one page or a whole site?

BARUCH LABUNSKI: Yeah. Just a specific page. There's a lot of alteration done to the page, and, again, not for the search engine, but for the user only. Like you guys wanted.

JOHN MUELLER: Yeah. So I guess that's something where at least we'd have to crawl it a few times to kind of at least notice that it changed. And after that, some of our algorithms are faster and some of them are a little bit slower on picking up those changes. So I imagine, for the most part, you'd see those changes within a couple of days of us we crawling those pages.

BARUCH LABUNSKI: OK. Because I see certain queries show up-- the old page is still showing up-- and then the new page is showing up for different queries. Why is that?

JOHN MUELLER: I think that's probably just the way the algorithms are picking up on some of the old things and some of the new things. So that's kind of something where users will make it to the final page anyway, so that'll still be around. So I wouldn't really worry too much about that. I mean, some of these things get picked up a little bit faster, some of them take a little bit longer, it's not that it's all just, like, one crawl and then suddenly everything's over on the new URL.

BARUCH LABUNSKI: But is it normal for it to go down in rankings and then go back to itself?

JOHN MUELLER: Usually for individual pages you wouldn't see big ranking changes just if you're redirecting. If you're significantly changing the content of those pages, then of course you'll see some fluctuations. Some of the things we'll be able to pick up on a little bit faster. Other things, they kind of take awhile to understand the new page that you're essentially showing. So if it has different links, if the rest of the site has changed as well, all of these things kind of come together, and sometimes it takes a while for us to settle back down with the previous state.

BARUCH LABUNSKI: OK. Thank you very much, John.

JOHN MUELLER: Sure.

MALE SPEAKER: Hey, John, quick question about rel="canonical."

JOHN MUELLER: OK.

MALE SPEAKER: Let's assume we have an ecommerce website where products have different variations based color. For example, so let's say an eyeglasses store, and the frames themselves have different colors and there's a product URL for each of these colors. Let's say there are three or four variations per product. Would it be wise to do a rel="canonical" given that most of the products aren't really different except that color? And would it be wise to do a rel="canonical" to a single product or would that be overkill and Google would decide what URL to give to the users based on their such word?

JOHN MUELLER: So what would happen with a rel="canonical" is that we would essentially drop or ignore those other variations. So if you set the rel="canonical" of your red page to the blue page, then we won't really be able to rank that page for queries around red sunglasses, for example. So that's something where if you're taking related but slightly unique pages and rel="canonical"-ing them back to one specific page, then we'll kind of lose that information that makes that page unique. So sometimes that might not matter. Maybe you have one page that's, like, for this pair of sunglasses in all variations, and that's your main page for this specific model of sunglasses. Maybe that's fine. Maybe it lists the different colors; that could be a perfect reason to kind of set that up like that. But on the other hand, if you have just one color and you have different colors that are actually kind of unique at the same level, then that's something where I probably wouldn't use a rel="canonical," because those pages are unique by themselves. It would make sense for us to send people who are looking for red sunglasses of that model to that specific red page and not to the blue page.

MALE SPEAKER: All right. So basically I should think about what the users are actually looking for. If they aren't really interested in searching for actual color variation, then do a rel="canonical." But if they are, then the fact that all these variations have the same product description and price, for example, doesn't really affect the website from a negative point of view, right?

JOHN MUELLER: Yeah. Exactly. Yeah. I mean, it's something where you have to figure out do you want these pages to rank separately? Is there something unique on these pages that make sense to show them in the search results like that? Or are these things that you can fold together and say, this is actually my main page, and this is the one I want ranking with the content that's correctly on it.

MALE SPEAKER: OK. That makes sense. Thanks.

JOHN MUELLER: Sure. All right, let's grab a--

GREG: About cycling submitted for a second.

JOHN MUELLER: Go ahead.

GREG: When a website is displaying site links, is that any indicator of authority or trust?

JOHN MUELLER: Not directly. So I imagine to some extent we want to show them for pages where we know it makes sense. So you could say that something like trust is kind of flowing into that, but primarily we're able to understand the structure of the site. We're able to understand that if someone is searching for this specific brand or this specific item, that maybe they go to different pages as well in the search results. So we'll kind of bubble that up that way in the search results. So it's something where we probably wouldn't show it for any random website, but passed that it's not a sign that you've passed some kind of a magical threshold and now your website is good enough to be shown with site links. It's primarily something where we understand the site structure and know that these other pages make sense for the user as well, so we'll show them as site links.

GREG: Thanks.

JOHN MUELLER: All right. We have a question here, if a lot of users are bouncing back to Google from a website using the back button, isn't that a strong indicator of the quality of that URL for a search term? Why would Google not use that as a metric to rank a page? This is, I guess, a tricky question, because to a big extent there are lots of reasons why people go back and forth in their search results, and it's not something where we could say on a per-page level this is an indicator of this being a high-quality page or low-quality page. Sometimes pages have content on them that users can read within a couple of seconds, and they go back and do something else. And that's perfectly fine. That's not a sign that it's a bad page. Contrarily, the user was able to get the information they wanted really quickly, and they're happy with that. We do use some kind of looking at which results people are clicking on when we evaluate our algorithms overall though. So if we're looking at specific algorithm changes, and we say, well, people are clicking on lower search results in general across this algorithm, across millions of queries that were made, then maybe that's a sign that the algorithm isn't doing what it should be doing. That it's kind of encouraging people to not find the results that they are actually looking for in the first couple of places. So on a very broad-level it makes sense to use that information. On a very page-level, focus-basis, it's a very noisy signal that I think probably wouldn't make that much sense to keep and to kind of track for ranking. It's also something that's very easily gameable. So I don't think it's something where we would say this is a useful signal by itself. But across millions of queries on an algorithm basis, that's probably something that kind of settles down and gives some kind of useful information.

NEMANJA DIVJAK: can ask how important is structured data through the web master tools?

JOHN MUELLER: For ranking, we don't use structured data. So that's something where we use it primarily for rich snippets. If we can pull out more information about your pages and we can bubble that up as rich snippet, that's a great thing to do. That gives the user a little bit more information about the page and kind of tells him that this is the page you're looking for. So from that point of view, from a kind of a clickthrough rate point of view, that's something that I think definitely makes sense. We don't use it for ranking, though. So if you have things marked up on your page, we might be able to understand the page a little bit better. But it's not that we'd be able to say, well, this has structured data. This doesn't have structured data. Therefore, this must be a better page. This is something that's kind of a technical element on the page, and from that point of view, I'd be cautious to say this is an indicator of a high-quality site. Because a lot of times we'll see spammers create technically really high-quality sites, because they have a lot of experience creating lots and lots of sites. So their sites will be technically perfect. And maybe they'll scrape content from other sites; they'll markup the structured data. But just because it's a technically well-made website and uses structured data, doesn't mean that it's necessarily a better website.

BARUCH LABUNSKI: These spammers. Ugh.

JOHN MUELLER: Well, I mean, it's just one example. It's something that comes up every now and then where a mom and pop website will kind of have this messy front page website that from a technical point of view you'd look at it and say, oh, gosh, how can this even show up in a browser? But from a practical point of view, from a search quality side, it's something that we do want to show in the search results even if it's kind of messy code, if it's messy HTML, if it's an exported Word page or something like that. That doesn't necessarily make it a lower quality search result. All right. You mentioned that Google can pick up on signals of people recommending your website to other people very directly. Can you elaborate on what these signals might be? Social shares? Bookmarks? Et cetera? I'm not really sure what specifically you're pointing at that I might have said there, but I think one thing to keep in mind is we don't use social signals for search. So things like likes or +1s, those kind of things, aren't necessarily something that we'd be able to use for search, because, for the most part, we don't have that information. So that's something that we can't really use if we don't really have it. So from that point of view, those kind of social signals kind of get lost. Anything else that essentially looks like a web page that we can crawl, that has links on it, that's something we can treat as a web page, and we can kind of pick up and reuse.

BARRY: John, with the exception of personalized search?

JOHN MUELLER: Personalized search is, I guess, something different, because that's personalized. Like you said, that's something where we do take into account who your specific friends are or your circles or however that kind of ties in. But that only works for the information that we do have, and that's specific to individual users. So that's not something where if you have a lot of friends that are posting content, that doesn't mean that that content will be relevant to people who aren't your friends, who aren't kind of in your circles or have you in their circles.

BARRY: Right.

JOHN MUELLER: All right. XML sitemaps. If the taxonomy overall site structure is good, is there any need for XML sitemaps? I've seen a lot of examples of large sites without XML sitemap files doing great for crawling and indexing, et cetera. You absolutely don't need XML sitemaps. So it's not a requirement. It's not that your website will disappear from Google search if you don't have one. The XML sitemaps help us a lot with quickly changing content-- so content that changes, content that gets added to your pages-- because we don't have to crawl your website to realize that these pages are new and have been updated. So if you have a blog, if you have a news website, if you have a shop that has maybe Christmas specials, those kind of things where you want to new and updated content picked up as quickly as possible, then that sitemap is going to help us to get there as fast as possible. On the other hand, if you have content you put up once, you keep it like that for 10 years, and you're not going to change it in the next 10 years, then it doesn't really matter if you have a sitemap or not. We have that content already. We don't need to kind of recrawl it every five minutes. We'll be able to kind of figure out what cycle make sense for us there. And if you happen to change something there, it won't be picked up immediately, but it'll be picked up sooner or later.

LYLE ROMER: Hey, John, real quick question about something we noticed in Webmaster Tools recently. We were looking through the Content Keywords and noticed that for some reason the word "logo" had come up very high in the list there. And we discovered that in a lot of our Alt text around the site where we have logos of things, we would call it "whatever logo." We were just wondering, is that something we should be concerned about? We went and redid the Alt text to take them out, but in general should we be concerned about seeing something like that?

JOHN MUELLER: No. So the Content Keywords feature looks at the content that we see when we crawl the pages, and we'll pick up on things like logo. Or if we happen to crawl and index your robots.txt file or your sitemap and kind of treat it as a normal HTML page, then we'll pick up things like HTTP or WWW or whatever might be in there. So it's basically just a signal that we found this text while we crawled your pages. It doesn't mean that it's relevant for your website. It doesn't mean that it's relevant for ranking. It's not that your website is going to rank for the term "logo" or anything like that. It's just we found the text; we thought we'd let you know about that so you're kind of aware of that. The main reason I'd use that feature is to make sure that there's not something completely irrelevant that kind of pops up. So if your site is about cars, and suddenly you see things about casinos in there, then chances are someone has been spamming your site or hacked your site or something like that. So that's a really good sign that something really weird is happening with your website, and that's worth kind of digging into and figuring out what happened there. But if this is based on something that you have on your pages, like the Alt text for your logo or when we crawl a sitemap or robots.txt file, whatever, it happens. It's not going to change anything for ranking. It's not going to change anything for the rest of the words that were found on your site. It's just, we found this on your site. We thought we'd kind of let you know about.

LYLE ROMER: OK, great. Thanks.

JOHN MUELLER: OK. Webmaster Tools and HTTPS. What's the difference between HTTP and HTTPS in Webmaster Tools Verified Properties? So for some of the features in Webmaster Tools we differentiate between HTTP and HTTPS versions, and we'll show you the data separately. So specifically, I think this is around Index Status, this is around the Search Queries feature, where if you're moving from one variation to the other; you'll see the one variation kind of go down, the other one kind of go up again. And we primarily do that separately so that you can look at these versions separately and figure out if anything weird is happening with your transition, if everything is being picked up properly, if the search queries are picking up over again, those kind of things. Also, as with everything else in Webmaster Tools, this doesn't affect your rankings if you have those variations verified or not. But if you're doing a move from one version to the other, I'd definitely make sure that you have both of them in Webmaster Tools so that you can kind of double check that technically things are working the way they should be working. Another sitemaps question. Are there any advantages in splitting up the XML sitemap into smaller files, like 5,000 or 10,000 items per file? You can definitely do that if you want to. What will probably happen there is we will have to recrawl more sitemap files to pick up the changes. Usually that's not a big load on your server. These are just text files if you're not generating them dynamically. The advantage I see there with smaller sitemap files is, specifically when you're looking at the indexing of those URLs, it's a lot easier to kind of pinpoint individual issues. So if you split your sitemap file in a logical structure, like category pages, articles, blog posts, products, something like that, you'll be able to look at the Indexing Status of each individual sitemap file and see, oh, for this type of page, most of my pages are being indexed. For this other type of page, maybe half of my pages are being indexed. And by knowing which type of page is indexed how well, you can figure out is this a critical problem or is this essentially fine. So if we're able to pick up, let's say, half of your product pages, but we can pick up all of your category pages, then probably your site will still rank normally and things will work well in Search anyway. On the other hand, if we're not able to crawl any of your articles or any of your category pages, and your product pages are being picked up, then that's a sign that maybe something technically is wrong with the way your category pages are set up or the way they're maybe linked internally. Something like that. So by splitting it up, it's usually a little bit easier to diagnose problems. If you don't have any problems at all with you sitemap files, than it doesn't really give you any advantage in splitting them up or keeping them be.

GREG: John, if I can jump in real quick with a question about, not penguin per say, but disavowing in general?

JOHN MUELLER: OK.

GREG: A lot of talk about how great it would be if Google could offer some sort of notification on when we download the latest links in Webmaster Tools to kind of identify which ones have already been disavowed when we update the file. Is there any possibility of that coming out in the future? It would make our jobs as webmasters so much easier.

JOHN MUELLER: So if you would see within the download which ones are kind of blocked by your disavow file already?

GREG: Exactly.

JOHN MUELLER: I don't see that happening any time soon, but it's an interesting idea. I think it's also something that probably someone could make a simple Tool for, because taking a disavow file and comparing it to a links download shouldn't be that complicated.

GREG: Sort of like matching a one-to-one?

JOHN MUELLER: Yeah, because I mean your domains are things that are easy to match. The individual URLs are easy to match. It shouldn't be that complicated. So if someone is looking for a Christmas project, that might be something to try out.

GREG: I'm going to hire Barry.

JOHN MUELLER: I don't know. Maybe if I have time in between I'll put together a simple script to kind of do that for you.

GREG: That'd be great.

JOHN MUELLER: But I don't see that happening in Webmaster Tools anytime soon. They're working on a variety of features, and at the moment the Links feature isn't something they're spending too much time on. So I don't see them kind of jumping in and tweaking that just for that feature.

GREG: OK.

BARRY: John?

JOHN MUELLER: OK. Go ahead, Barry.

BARRY: Are you sure? OK. All right. Two questions. Two questions; one's fast, one's kind of longer. So you said, John, in the past that obviously hidden or tab contents may not be fully indexed or ranked in some sense; I'm not going to go through all the details. But there was an argument on Friday's Hangout between webmasters, because you said also that for many mobile ranking factors you just look at the desktop version. So when you change the CSS style sheets to hide some navigation or content to make it more mobile friendly on a responsive design, are you looking at that on the mobile side for hidden content, or you're still looking at the desktop version of the hidden content? That make sense?

JOHN MUELLER: We're looking at the desktop version. That's the canonical version, so if you have the connection between the two pages, if they're separate pages, then we'd be looking at the desktop version, and that's the one we'd be using for indexing. So if it's visible on the desktop version, and you're kind of folding it away, simplify it on the mobile version, then that's absolutely fine. If we run across situations where we see that people are abusing this, that they're kind of, I don't, showing cartoons on the desktop site and showing adult content on the mobile site, then that's something where we might have to kind of reconsider that and see what we have to do there. But for the most part, I don't see that making sense that you'd kind of show something significantly different on the mobile site than on the desktop site, because then on the mobile site, people would be kind of lost. Like, what should they be doing there?

BARRY: Cool. Thank you. And a very question, blink twice if it's true, once if it's not true, did you make an offer to Duane Forrester to work on Google?

JOHN MUELLER: I think he's working at Bing now.

BARRY: I know. I just wanted to know between that time.

JOHN MUELLER: What do you mean?

BARRY: OK, I got you. Thank you.

JOHN MUELLER: No, I didn't-- I got lost. OK.

BARRY: I'm just with you.

JOHN MUELLER: Oh. So if we made an offer for Duane, I don't know. I didn't make anything so-- it sounds like he got a lot of different offers, but he's a good guy. I'm sure he'll find something really interesting at Bing to do there so--

BARRY: Yes. Thanks.

MALE SPEAKER: John, going further on Greg's questions regarding Webmaster Group Features, if I can add a few suggestions that I've noticed recently that would help me manage my websites better with Webmaster Tools. Is it possible to add a filter or something like that so I can select both web and mobile? For example, when I'm looking at search queries, I want to see such queries for both web and mobile. So for search and exclude images, for example, because right now you can search [INAUDIBLE] for web or for mobile, but not both at the same time. Sure, you can see all, but that would include also images and everything else that is there. And if it's also possible to maybe add a local filter so we can see queries that show local results. Maybe that's possible?

JOHN MUELLER: OK. Let me just jot this down.

MALE SPEAKER: Maybe if I can? Instead of just having a drop down where I can select Web or Mobile for images, maybe just check boxes so I can select multiple? Web and Mobile, but not Images? Also, do you know if there's going to be any better integration with Google Analytics? There hasn't been any changes with that.

JOHN MUELLER: I can definitely pass the search query things along, because I know they're working on some fun stuff there. I don't know how far they are with regards to how much your feedback will still be able to make it in there, but I'm happy to pass that along. With regards to Analytics, I'm not aware of anything specific happening there. I know they still kind of have the bucketed numbers in Analytics, so that's something that's definitely still open. I imagine that will get fixed at some point, but I don't really know what the Analytic side of things is planning.

MALE SPEAKER: OK. And is it possible that we SCOs would have like something along the MCC account that PPC managers have where they have multiple clients in the same account and they can just ask a website for permission to handle their-- because when we're getting new clients who aren't really tech savvy, they king of don't understand how to give access and that to users and even create their webmaster to those accounts. So that's a lot of time wasted at the beginning. Maybe there is going to be better integration like the PPC people have with the client center?

JOHN MUELLER: I don't know how that actually works on the outward side, but in Webmaster Tools you can already delegate access.

BARUCH LABUNSKI: Yeah.

JOHN MUELLER: Maybe it's just too complicated from what I hear from you.

MALE SPEAKER: By delegate access you mean just add another user or?

JOHN MUELLER: Yeah. Yeah. You can add a read-only user if you wanted to to kind of let them look at Webmaster Tools without making changes.

MALE SPEAKER: Yeah, well, so in the client center for PPC so you actually have an option to actually request access to a certain website without actually telling that person could you go ahead and click that button and add this email and so forth. So actually, just request an invitation and the user receives an email or in the account a notification, and he just accepts or denies it.

BARUCH LABUNSKI: Yeah. It's basically like the same kind of system as the My CC Account, you know? I don't know. I mean, clients, basically, I tell them where to go. They add me, and you become an administrator or a read-only access like you were saying. So, yeah, I mean-- [INAUDIBLE] just making it the same like an easier way like with the MCC, you know?

JOHN MUELLER: I have no idea how that works with outward, so--

BARUCH LABUNSKI: I figured.

JOHN MUELLER: I will take your word for it that it's a lot easier. I'm not sure if requesting access would be that much of a good idea, because it obviously spams the owner. But maybe there's a way to do that in a reasonable way. So I'll definitely take that up with the team that handles the verification. It sounds like an interesting idea.

BARUCH LABUNSKI: But, I mean, it's fine the way it is now. Like--

JOSHUA BERG: John? Could we see some grouping of the different domain types? Or is that in the works by any chance?

JOHN MUELLER: I know that's a commonly asked question, so I'm sure they're kind of aware of this issue, but I don't know of any plans of that changing immediately. So I imagine at some point that'll kind of work out in a way that we can kind of have these sites a little bit more grouped, but it's not something that's coming out today or tomorrow.

GREG: John, I know you were saying--

JOSHUA BERG: I think another popular one will be to show, I mean, I don't know if it's going to be too much extra data, but to show six months or so instead of three months. You know, the default three months that we've got now is difficult to work with. Some people save that data, but as webmasters, when we come along to work on someone's site, they have not saved any of that data. So all we've got to look at is the three months.

JOHN MUELLER: Yeah.

BARUCH LABUNSKI: John, I--

JOHN MUELLER: That's something I've heard before as well. Yeah. I know some of these things seem easy to do, but sometimes they're a bit harder than they initially look. So I know with the data, that's something that we've brought up with the team as well, and they're aware of this, but there are a lot of sites out there tracking a lot of data, so it's a lot of stuff they'd have to kind of duplicate or triplicate depending on how far back you'd want that data.

BARUCH LABUNSKI: John, last time you touched on mobile usability, and I said if there's just a small option, can you still pass feedback or no?

JOHN MUELLER: What do you mean?

BARUCH LABUNSKI: OK, so for mobile usability, like, when it scans the pages, right? So after you look at it and you've fixed it along with the developer or with a team of 20 people-- as in big Fortune 1,000s; it's not that easy-- and you've done that, you don't have to come back to the same problem again. You just mark it as fixed just as with crawlers. Is it hard for them to do that? Like, once you're done, you fix the problem, check the page insights, because it takes you there anyways, and then you've corrected the problem, it's 100 out of 100, and you're dealing with, like, 5,000 pages, you come back to Mobile Usability again all the errors are there again and you're kind of confused. Just an easier-- just for--

JOHN MUELLER: I don't know if marking as fixed would be the best solution there, but for example another idea might be just to say, we can recognize that you fixed some of your pages. We can see that it's all the same template. We'll just kind of recrawl all of the similar pages and reprocess them to make sure that they're, like, OK now.

BARUCH LABUNSKI: Perfect.

JOHN MUELLER: So it's kind of like requiring that you mark them individually as fixed. Maybe we could just figure that out ourselves, but that definitely sounds like something that would make it a little bit easier and a little bit clearer for you to also show what work you've done there on that site. Instead of saying, OK, we'll just wait six months until everything's recrawled, and then we'll see a drop in the numbers. If you can see that change a little bit faster, then that's probably useful.

BARUCH LABUNSKI: It'd make a big difference, yes. Thank you so much.

JOHN MUELLER: All right, looking us through some of the questions that were submitted here, and then we'll get back to Feature requests for Webmaster Tools. Webmaster Tools-- back to Webmaster Tools. How accurate is the Index Count in Webmaster Tools? What about the Webmaster Tools Count versus a site count? So I definitely wouldn't use a site query for any kind of diagnostics purposes. I generally just use that to see if individual pages are indexed or not indexed. Webmaster Tools Count is pretty accurate. It's based on the current index data that we have, but it's sometimes based on everything that we've kind of crawled and indexed for your site. So instead of looking at the aggregated number for your whole website of all pages that are indexed, I'd recommend using the Sitemap File and submitting a Sitemap File, then looking at the Index Count for that Sitemap File. Because then you'll know, based on the URLs that you've submitted, the ones that you actually want to have indexed, how many of those got indexed, and not how many random pages did we find on your website and index. So both the Sitemaps Count and the Webmaster Tools Index Status Count are pretty accurate numbers. They should be updated fairly frequently. The Sitemaps Count, I think, gets updated daily. So that's something that gives you very actionable feedback on what we have indexed. Another sitemaps question. You mentioned last year in a Hangout that XML sitemap files for pages that are set to 404 or 410 in order to speed up the process is not the best approach. However, I've seen very good results with it. Yes, I guess you can do this in the sense that if you update the last modification date, submit the URL with the sitemap, we'll recrawl that. We'll notice it's a 404 and we'll drop it out of the index a little bit faster. What I wouldn't do is keep them in there persistently. So if you've made a big change on your website and you need to kind of drop these pages fairly quickly, then submitting them in a sitemap like that make sense. But keeping them there for the long-run where you know that within your sitemap file half of the URLs don't exist anymore, that just makes it very much harder for you to diagnose any real issues, because the index count for that sitemap file will be completely weird. Because on the one hand, you submit URLs that you know don't exist, and on the other hand, you submit some that you do want to have indexed. And that makes it really hard for you to kind of take action on the number. But if you do this as a one-time thing, and you say, I'm submitting them now. Google should recrawl all these pages and recognize that they're gone, fine. That seems like something you can do.

NEMANJA DIVJAK: I have to ask. We have more than 160,000 pages removed from Google, and we can remove, I think, about 2,000 links at this point per day. So does that affect the ranking because of the big number? It will take, like, six months for us to go to zero errors.

JOHN MUELLER: So what kind of pages are you removing?

NEMANJA DIVJAK: have websites similar to YouTube, so we've removed all the [INAUDIBLE] content, we removed duplicate content, canonical content, we removed more than 150,000 users from the website that they were link building to their pages. So we removed everything, so we have about 160,000 errors at this point.

JOHN MUELLER: OK. And these are pages that return 404? Something like that now?

NEMANJA DIVJAK: Yeah, everything is all 404.

JOHN MUELLER: Yeah. That's fine. I would just let them be recrawled and re-indexed like that naturally. So I wouldn't use a URL removal tool for that manually, and that's fine. It's not that it would cause any problems for us if we see a lot of 404 errors. It's actually a sign that your site is working, technically, correct, because if we see 404 errors, then we kind of know we can drop that out. Whereas if you try to hide the 404 errors with redirects or by serving a 200 result code to make the error count look lower, that's something that actually causes more problems for us. So 404s are perfectly fine. And that's a perfect use case for letting those pages dropout naturally.

NEMANJA DIVJAK:

BARUCH LABUNSKI: What if we--

NEMANJA DIVJAK: Sorry. It's not a problem for dropping them; we wanted to remove all the bad content. It's just that in the Google Webmaster Tools we went from 50,000 visits from the Google search. We are hitting, like, 150 visits per day at this point. So it's been, like, three years now going down, and we have removed-- about three months ago, everything is cleaned up, and it's just waiting. When will happen? I think we got hit by the penguin, some kind of penguin, but is there a chance to repair that domain in the following months? I know it's algorithm and everything, but--

JOHN MUELLER: It's really hard to say without looking at the site, but if this is something that has been happening over the course of multiple years, then that sounds like we've kind of picked up on this issue step-by-step and said, OK, this site overall is kind of lower quality. And it sounds like we almost have to reevaluate those general decisions that are algorithms are made. And if you've removed a lot of really low-quality content, then that's something that I think our algorithms will pick up on over time. But it's not something where you'd see a change from one day to the next, or even from one month to the next. So I imagine this is something that will take a couple of months to kind of settle down again. And if your page was raking so well a couple years ago, a lot of things have changed on the web, a lot of things have changed in our algorithms. I wouldn't expect that it will automatically pop back up to the old state. It might pop up to a newer state that's higher; it might pop up to a newer state that's lower than before. So things have changed on the web over those couple of years. I think if you significantly cleanup the lower quality content and make sure it kind of stays out of your site, maybe you revamp your site to really look fantastic and have fantastic content, then those are good prerequisites to kind of showing up more visibly in search. But it takes a lot of time for things like that to kind of settle down and pop back up.

LYLE ROMER: Hey, John, if there's pages that the algorithm doesn't index even though everything seems right with them and they're in the sitemaps, is that an indication that the algorithm feels that that page is of low quality?

JOHN MUELLER: Sometimes, yeah. It's really hard to say without looking at the pages, because most of the time this is more of a technical issue where we say, we crawled this page. We found no index. Or we crawled this page, and it looks like it's redirecting us to a different page by JavaScript. Maybe that's something users see; maybe they don't see that. But it's usually more of a technical issue. It's fairly rare that we would look at a page and say, well, this whole website looks OK. But this page is so low quality, we're going to skip on it. So that's kind of a rare situation. It can happen that our algorithms look at those pages. Usually they'd look at the whole site and say, well, this whole site is kind of low quality. It doesn't make sense to spend too much energy on crawling and indexing everything from this site. So that's usually the level where the quality algorithms come in with indexing. Most of the time, if this site is being crawled normally and indexed normally otherwise, then it's more a matter that there's something technically weird with that individual page that it wouldn't get indexed.

LYLE ROMER: OK. Thanks.

GREG: John, if I can jump in one last time with a question about subdomains?

JOHN MUELLER: Sure.

GREG: Regarding subdomains, if you have a blog that's hosted on a subdomain-- you know, blog.website.com versus website.com/blog having it in the root domain-- when you're doing outreach and acquiring links back to the blog, wouldn't it make more sense to have the blog hosted as part of the root domain instead?

JOHN MUELLER: From a search point of view, it doesn't really matter that much. Sometimes for technical reasons, sometimes for marketing reasons, you put it in a subdomain or a subdirectory. That's essentially up to you. That's not something where we'd say from a search point of view it makes any big difference. The other thing from your question that sounds more tricky is you're going out and doing outreach for link building, which sounds like you might be doing something sneaky with regards to your links. But that's independent of where you have those pages located. So that's more of a thing I'd be kind of cautious about, or make sure you're handling that in a way that you're not, I don't know, buying links or trading links, those kind of things. I don't know. You're shaking your head, so that sounds like that's not something you're doing.

GREG: Correct.

JOHN MUELLER: OK. But from a technical point of view, like subdomain or subdirectory, is essentially up to you. What I would shy away from is using wild card subdomains, so you have, like, keyword.yourwebsite.com, because that makes it a lot harder for us to actually crawl your pages properly. But if you just have blog and WWW, fine. That's no problem.

BARUCH LABUNSKI: John, just a very quick on the homepage, OK? I don't remember from all the Hangouts that I've been in that we've ever touched on that. What would you recommend? So if brand, not a brand, family, locally owned business, how much content should be on the homepage?

JOHN MUELLER: At least 250 words or 700 characters.

BARUCH LABUNSKI: OK. Because I see a lot of brands that don't have--

JOHN MUELLER: Sorry. Sorry. I just made that up. No, I mean, it really depends on what you want to put on your home page.

BARUCH LABUNSKI: No, I know, because a lot of professionals recommend 750 and up, and make big blogs and things about it and so on and talk about this forever. So I just thought--

JOHN MUELLER: It's not the case that we go out and count those words, and, like, our algorithms have a threshold and say, this is a good page, because it has more words on it or fewer words on it. We try to find out what's relevant for these pages, and a lot of times that's in the text. So having enough text in there to kind of help us recognize those pages, what they're about, what's actually relevant on those pages, that's an important aspect there. But it's not that you need a specific word count for that or anything like that.

BARUCH LABUNSKI: OK. There's many blogs out there that touch and say, 750, 1,000 will help you.

JOHN MUELLER: Yeah. I really wouldn't worry about the word count there. I'd really look at the pages and look at the text and see if it's actually relevant. If it's something that you can pick up on where you can kind of use that information. And also make sure that you're looking at the actual text and not looking at things like the images. What I still see a lot of times is people will kind of format text in a fancy way and keep that as an image on their page. And then suddenly the logo with, like, the subheading, that tagline, all of that, is an image, and if we don't see that at all in text form, then that makes it really hard for us to see that this is actually relevant for this page. We're getting better and better at understanding pages, but kind of extracting text from images and saying this is a part of a page, is still a pretty hard problem.

BARUCH LABUNSKI: And brands that don't have text at all on their homepage, you recommend that they do have text, right? I mean, I see still a lot of brands that don't have text, and the person that owns the site tells me, hey, we don't want text because we like the style. And so we don't care about the text.

JOHN MUELLER: Yeah. It's always tricky, because some of these sites that are really, really nice. They have really minimalistic design, and it kind of matches their marketing, the kind of general corporate identity of the site, of the business, and sometimes it just looks really nice. But if we don't have a lot of text on these pages, it's really hard for us to pick up which pages are relevant, which pages we should be showing in search. So things like brand queries or someone searching for the company name, we'll still usually be able to pick that up and say, well, this website belongs to this company. We'll show it in search. But if they're looking for specific products, and we actually never are able to find that text on those pages, then that's going to be really tricky and kind of hit and miss for us to actually be able to use that.

BARUCH LABUNSKI: Thank you for touching on that. Thanks.

JOHN MUELLER: Sure.

MALE SPEAKER: Doing a small follow up on that question. We're working with a very big automotive website. And as an automotive website, they have a lot of photos. They usually do car news and car reviews, and they have hundreds of thousands of article for that. And for each article, there's the gallery page, and of course for each photo, there's a separate URL from that gallery. The idea is that each photo URL only has the actual photo and links to all the other photos and then back to the picture gallery. We did a rel="canonical" back to the picture gallery from the picture URL, because we thought it's too little content and too similar from all the other pages. But of course we sacrificed the image traffic that was-- the images are not longer indexed. Is that something that we should remove? Is it OK for us to have a lot of image URLs with pages that only feature that image?

JOHN MUELLER: That's fine. I think that's a decision you can make. And I know some sites don't want their big images indexed in the image search, and that's their decision to do. It's not something where we'd say, this website is lower quality because they're blocking the images from being indexed. That's essentially up to you. So if that makes sense for you to kind of get this kind of traffic, fined. If you want to kind of concentrate things on your other pages, that's fine, too. One thing you could do is maybe treat, like, a sample of these pages differently, and see which one actually works better for your site. And you'll quickly see, does it make sense to do this change or does it not make sense to do this change? And that's something that should only be affecting those specific types of pages. So that's something you can fairly quickly kind of test to see are users really picking up on this? Do they want to go to these individual photo pages? Or are they happy with the other kind of content on the rest of your site?

MALE SPEAKER: But would it be a problem for us-- let's say we remove the rel="canonical," and we have, as I said, a few hundred thousand articles, but if you remove the rel="canonical," we'll have, like, a couple of million photo URLs suddenly added to the index. Again, pages with the photo and links to the other photos and back to the picture gallery and the article. Would that be a problem? Would Google consider it less of a quality?

JOHN MUELLER: That shouldn't be a problem. That's something where I think this is unique content, it's relevant content. If someone is searching for that image, then that's the type of thing that might be fine. I think you probably want to just watch out for your server capacity to make sure that your server is able to handle this load. If Googlebot were suddenly able to crawl, like, 100 times the number of URLs, is that something that would cause problems for your site? And if so, maybe it makes sense to kind of hold that back a little bit. But if your server can handle that load without any problems, or if you can ramp this up step-by-step, that's something to try out. I don't see any problems with that.

MALE SPEAKER: OK. Thanks.

GREG: John, I have to follow up on that last response you had. I'm dying on the inside, slowly. I just want clarify. Outreach and content marketing is not against Google's guidelines, correct? We're not buying anything or doing anything of that sort?

JOHN MUELLER: As long as you're not going out and kind of creating artificial links on other sites, I don't see a big problem with that. If you're drawing attention to your business, drawing attention to your website, that's generally fine. If you're going out to hundreds of directories and saying, hey, please put a link to my site on your site, then that's something I kind of shy away from, because I know that's something our algorithms would pick up on as kind of a web family type thing. And maybe the Manual Web Spam team would also look at that and say, well, it looks like this guy is just dropping his link everywhere; maybe we should be more cautious with the links to his site.

GREG: But when I only do editorial-based links through contacting different websites and bloggers, not spammy stuff?

JOHN MUELLER: Yeah. I don't know what kind of links you're doing, so I can't say everything you're doing is perfect. But it sounds like you're doing the right thing. It sounds like you're kind of drawing attention to your business, to your website, and if people like what they see and they link to it, fine.

BARRY: Thank you, sir.

JOHN MUELLER: All right. If a website main menu relies on some links made with JavaScript, do those JavaScript links carry page rank on their target URLs? Yes, they do. So we're getting better and better at understanding JavaScript, and if we can crawl and process your site's JavaScript, and it's kind of like a menu for your website, then we'll be able to pick up those links and treat them like normal links. So if you want to have them treated as no-follow links, I'd just make sure that your JavaScript generates the no-follow attribute as well, and then we can pick that up and use that appropriately. But if this is a normal menu for within your website, then, in general, we should be able to pick that up and crawl your website based on that like any other type of menu.

ARTHUR RADULESCU: John, can I shortly follow up on this?

JOHN MUELLER: Sure.

ARTHUR RADULESCU: What if those links are hidden? Because with JavaScript, when you mouse hover over it, it will pop up, and then it will go back. What about this? Is this a problem from Google's point of view?

JOHN MUELLER: That's fine. I mean, that's similar to other type of menus. If you use CSS, if you use JavaScript, I think with HTML5 you can do something similar where on hover it kind of displays things. Otherwise it highlights them. That's fine. I mean, a lot of websites have that kind of navigation.

ARTHUR RADULESCU: OK. Thank you.

ROBB: John, can I ask a question?

JOHN MUELLER: Oh, just let me just go through this one, and I'll get you right after that.

ROBB: OK.

JOHN MUELLER: In Webmaster Tools we're getting server error since the 9th of October, no response failure rate is about 5% out of 200,000 requests per day, server's not overloaded, no maintenance, no firewall problems, no 50 times errors in logs, Fetch as Google works fine. What could be the problem? I'd probably have to take a look at that site specifically. So if you can post in the forum and maybe drop a link from the Hangout event page, I could take a quick look at that. Sometimes this can be kind of a misleading error in the sense that, for example, if your robots.txt file is unreachable once a day, then that'll affect a lot of potential crawls that we have on your website. It's actually just one request that's unavailable, but because it's unavailable, we'll kind of delay crawling of anything else until we can fetch it again. So sometimes this kind of situation comes up with individual requests that we can't get to. Sometimes it's a legitimate problem that we just can't crawl everything that we try to request from your server. And somewhere along the line, in the firewall, maybe in the hosting environment somewhere, those requests might be getting blocked. But I can take a quick look if you post your URL on the forum.

JOSHUA BERG: Is it OK to limit the speed?

JOHN MUELLER: I'm sorry?

JOSHUA BERG: Is it OK to limit the speed of the Googlebot indexing to slow it down? I've seen some people do that. I didn't think it was the best idea.

JOHN MUELLER: So when we run across a lot of errors, we'll generally slow our crawling down because we think-- well, when we run across a lot of connection errors or server errors, we'll generally slow the crawling down because we think maybe Googlebot is the reason why these errors are showing up. Maybe we're doing too much. So that's something that will happen. With normal crawl errors, like 404s, 410s, we don't slow down, because that's the normal server response. But if we can't get a normal response, then we'll slow down a little bit. But if this is like a stable 5% that we see errors with the connection problems like this, then generally that's not going to cause any problems for indexing, because we can still crawl more than enough with the other requests. But I still like to kind of resolve these kind of issues as a webmaster, because that way you know that it doesn't cause any problems. That way you know that there's nothing kind of flaky in your network leading to your server. All right. Robb? I think you're muted.

ROBB: Can you hear me now?

JOHN MUELLER: Yes.

ROBB: Is there any-- do search results vary according to the time of day ever? We're a gift company, so we see seasonal fluctuation, which is obvious, but is there any chance the search results could be influenced by time of day as well?

JOHN MUELLER: I don't think we do that.

ROBB: Or would that be customer behavior?

JOHN MUELLER: Yeah, it could be customer behavior. I know we've looked into that a couple years ago. At least here, where we were kind of analyzing what people were searching for in various countries to kind of see if we need to tweak things around a little bit and kind of make sure that the right kind of content is visible. Also, with regards to, like, weekend, weekday, maybe it makes sense to show different search results. But as far as I know, we don't do that.

ROBB: All right. Because we've seen a lot of buying patterns change to the evening, and I didn't know whether it was because everyone's far more mobile. We started ten years ago, and we saw that during the day, when people are at work and had access to a computer, they'd buy, and then in the evening they didn't. But obviously that's now completely switched. But--

JOHN MUELLER: That's interesting.

ROBB: This year in particular, we've seen evening purchases go up a lot versus during the day.

JOHN MUELLER: I don't think we do anything with the search ranking there that we'd see. Evening we'll kind of boost this type of site, and during the daytime, we'll boost a different type of site. I think it might be an interesting thing to experiment on, but it's very tricky to try out.

BARUCH LABUNSKI: Would you ever do that?

JOHN MUELLER: I mean, we run experiments all the time. So I wouldn't say that we'll never do that, but if this causes more confusion and we notice that users are kind of getting lost with the search results because what they search for in the morning when at work doesn't match what they search for in the evening when they want to go buy it, that can be confusing, you know?

BARUCH LABUNSKI: The morning plumbers to the morning people, and then the 24-hour plumbers--

JOHN MUELLER: I don't know. I could imagine if we had, like, lots and lots of data, that might make sense. Or if we knew that people in evening times were more likely to, I don't know, do informational searches, then we should interpret them a little bit differently. But I think that's probably not the case at the moment. I don't know, maybe it'll happen in the future, but I don't think that'll happen that soon.

LYLE ROMER: Hey, John, could I just ask one quick final question? In Webmaster Tools we've been getting some errors on mobile usability. I just wanted to get an idea of how much of a red flag we should look at that at with respect to ranking in general.

JOHN MUELLER: You probably see a stronger impact from your users directly. So if users are using your site on their smartphone, and they can't get to the content that they want, they're going to bounce and go somewhere else. I think the statistic I had from a recent conference was something like 60% of the users, when they run across a site that doesn't work well on their smartphone, they avoid it in the future. So that's something that people use their smartphones a lot for search, and if they can't get to the content, they're going to go somewhere else. So from that point of view, you're probably going to be seeing a stronger effect. You probably also have trouble seeing that in your logs though, because if people go to your site once, and they don't come back on their phone, then you don't see that 50% of your users are using smartphones, for example. Because they just go there once, and they don't go there a second time. From a search point of view, at the moment we show the little mobile friendly label in search results. I imagine, over time, users will kind of get used to that and focus on those sites more when they search on a smartphone. At some point we're going to look into whether or not it makes sense to rank those sites differently for smartphone users as well. So if your site doesn't work well on a smartphone, maybe we shouldn't be showing it in the search results as visibly for smartphone users. Maybe we should show it normally for desktop, but not as visibility for smartphone users. But that's still a bit off. So we still have a lot of experiments to do and to figure out how we should handle that appropriately. But I think that's going to be a general direction that we're going to be heading for. But in the meantime, you'll probably see a much stronger effect, really, just from the way users are using our site.

BARUCH LABUNSKI: Like, I mean, I tried to go to Adobe.com, and it's all, like, just a black site on mobile. Like, I don't understand. Can you guys take a look at that?

JOHN MUELLER: Yeah. I imagine something like Adobe will be a bit different, because there are people who are specifically going to that company's website on purpose. But if you're looking for something generic and you just want to buy a pair of shoes and you're on your smartphone and you're not on your laptop, then you're not going to bother with, like, one site that doesn't work well on your smartphone when you know that other people offer the same product in a way that does work on your smartphone. So in cases like that, users are going to go somewhere else where they can get that information or that product.

BARUCH LABUNSKI: All right. Thank you for a wonderful year.

JOSHUA BERG: Thanks, John.

BARUCH LABUNSKI: Thank you so much for everything you've done, John.

JOHN MUELLER: Yeah. Should we do another one next week? Are you guys around?

BARUCH LABUNSKI: No. No. We're here.

ARTHUR RADULESCU: That would be definitely a good thing to do another one. [INTERPOSING VOICES]

JOHN MUELLER: All right. Yeah. We have a couple questions to wind up.

NEMANJA DIVJAK: Sorry. I said it seems that the same people are always here.

BARUCH LABUNSKI: We're always here. We never stop working.

JOHN MUELLER: That's why I try to invite some new people from time to time. I think sometimes that works; sometimes not so much.

ARTHUR RADULESCU: John, can I propose to do a funny one? I mean, closer to the new year? It would be very, very nice to have a funny one.

JOHN MUELLER: A funny one. OK.

ARTHUR RADULESCU: Yeah. Where you are answering, directly, the questions and with data and stuff. Real numbers.

JOHN MUELLER: Real numbers. Or maybe I'll just say yes or no for all questions. We can go through more questions that way, instead of having to explain why.

BARUCH LABUNSKI: We'll start with Barry.

JOHN MUELLER: OK. I'll set one up for next. I'm around as well, so we can set that up and see if we can do something a little more light-hearted.

ARTHUR RADULESCU: Thank you, John.

JOHN MUELLER: All right. Thank you all for joining. I wish you all a great Christmas, if you're celebrating. And thanks for all the questions, and maybe I'll see you next week or next year.

NEMANJA DIVJAK: Thanks, John.

GREG: Happy holidays.

BARRY: Bye, John.

JOHN MUELLER: Bye.
ReconsiderationRequests.net | Copyright 2018