Reconsideration Requests
17/Dec/2018
 
Show Video

Google+ Hangouts - Office Hours - 08 May 2015



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 Hangouts. My name is John Mueller. I am a web trends analyst here at Google in Switzerland. And part of what I do is talk with webmasters and publishers like you to make sure that information flows in both directions and that we have the appropriate feedback for our teams internally as well. Before we get started with the questions that were submitted, do any of you have anything that's on your mind?

AUDIENCE: Hello, John, my I present you with a question?

JOHN MUELLER: Sure.

AUDIENCE: So we have a new website from January. And we're doing much effort to get the best ranking. But for some of our major keywords, we don't rank at all. And we think that there may be a type of penalty or something like that. Can you check that please?

JOHN MUELLER: I can take a quick look. But, essentially, if this is a new website, then these are things that are to be expected. It takes a certain amount of time for everything to settle down and for us to have the appropriate signals that we can use to rank your website for a lot of these terms. So that's something where in the beginning, it's not something that's very, let's say, I don't know how you would say-- very easy to see directly. So it just takes time in the beginning for things to settle down. I am happy to take a quick look, if that helps. But most of the time it's just normal that it takes time for things to settle down and to be picked up properly.

AUDIENCE: Yes, I know that. But I'm asking that because in the past week we've had the cooperation with the company that we think may be used some techniques that are not so good for SEO. So we think that this is bad for us. And maybe if you can check it, it will be good.

JOHN MUELLER: Yeah, sure. You could put the URL in the comments. And I can take a quick look. Essentially, if they were doing something spammy. And that's something that the webspam team picked up on, then you would see that in Webmaster Tools in the Manual Action section. So that's something you would at least see there. Another thing to keep in mind-- if you're saying this is a new website. And maybe you use an old domain or domain that previously had other content on it, there might be manual actions associated with that. Or there might just be an older history around that domain that's something that you have to work to clean up first. So, for example, if the old domain name was used for a lot of link spam, then that's something you probably want to set up the disavow file to make sure that that's really ignored on our side.

AUDIENCE: Thank you you're much.

JOHN MUELLER: Sure.

AUDIENCE: Can I jump in with the next question?

JOHN MUELLER: Sure. Go for it.

AUDIENCE: OK, I'm calling or asking on behalf of walmart.com. Before I joined the team a couple of years ago, we were hit with our search pages being de-indexed. And we were penalized for that. And we've done everything to try to get rid of our internal search queries from Google's index. We have no index or internal search pages. We, up until recently, blocked them with robots.txt. We have our URL parameters in Google Webmaster Tools set to block the search query. But when I take a look at Google Webmasters for our search directory, we still have about 1.2 million pages indexed. We don't see them within Google Search with the site query. But we are getting a lot Google Search traffic coming in. And Google Webmaster Tools shows a fairly high number of pages still indexed. I was wondering what we could do to get these pages out of Google's index.

JOHN MUELLER: Is this like a subdirectory or a subdomain on your site?

AUDIENCE: I'd say a subdirectory/search.

JOHN MUELLER: OK, so one thing that you could do if you really were certain that all of these pages were things that you don't want indexed, you can use the urgent URL removal tool, which would also work for a subdirectory. So that's the really heavy duty method of getting it removed. In general, what's important is if you have no-index on these pages that be able to see the no-index. So if the page is blocked by robots.txt and has a no-index on there, then we wouldn't be able to see the no-index. It sounds like you removed the robots.txt and now just have the no-index. Is that correct?

AUDIENCE: Correct.

JOHN MUELLER: OK, so that would essentially be set up properly. That's something that takes a lot of time to get reprocessed. So if you're talking about millions of pages than I am guessing the more visible ones we'll re-crawl fairly quickly, maybe within a week or a couple of weeks. And the less visible ones-- the long tail of but these millions-- is probably going to take several months, maybe even half a year or even longer to be re-crawled. And then we'd have to receive the no-index and kind of process that. So that's something where you're probably looking at a time frame of maybe half a year-- three quarters of a year, something like that, for these pages to be re-crawled and dropped out naturally. So if that's too long for you-- if you want to speed that up, then the URL removal tool might be an option there for the subdirectory. It depends on how far you want to go there.

AUDIENCE: OK, when you say URL removal tool, you're talking about the remove URLs, not the URL parameters?

JOHN MUELLER: Yeah, the remove URLs tool.

AUDIENCE: I have-- sorry go ahead.

JOHN MUELLER: And you can say-- so there are two options there. One is per URL and the other is for a subdirectory. So this is one you would do for a subdirectory because I think there's a limit to 1,000 URLs. So that wouldn't really help you there.

AUDIENCE: Perfect. That's great. I do have a question about the URL parameters tool. When we have a parameter query within the URL parameters tool, does Google still crawl this and then take it out of the index of the query-- pages with the query? Like, for instance, we have facets that we have in the URL parameters tool that we don't want Google to crawl. But we still see Google crawling these facets-- or Googlebot, sorry.

JOHN MUELLER: Yeah, so essentially what happens is we use that as a strong signal on our side. We try to crawl a lot less than we normally would there. But we still spot check URLs there. So that's something where depending on the number of URLs, the spot checks might still be fairly visible. So that's one aspect there. The other thing is if these pages are already indexed, and you have no-index on them now, then by using the URL parameter tool, you are limiting how much we crawl for those URLs, which means it'll take a little bit longer for us to re-crawl them and drop them out because they have a no-index on them.

AUDIENCE: OK, perfect thank you so much.

JOHN MUELLER: Sure. All right, more questions? Mihai, I thought you had something.

MIHAI APERGHIS: Yeah, I was just waiting for anyone else to see if they have. OK, one of them is actually regarding the new search analytics in Webmaster Tools. I actually gave you this feedback in one of your posts on Google+. It would be really nice if the filter is applied. So you're looking on one of your websites, and you apply some filters to see CTR and position on a certain date. And when you change to a different website, it would be nice that the filters still apply rather than just reset to their default values. That happens in Google Analytics, for example, when you switch from site to site. And you're just looking like organic traffic that carries over to the new selection-- site selection. So that would be nice if it would be in Webmaster Tools.

JOHN MUELLER: Yeah, we talked about this internally before we decided on the behavior. And one of the problems was that if you set something up that makes a lot of sense for one site, and you change sites, then it quickly looks like there's no data for the other site because it doesn't really match what they were looking for. So if you picked a query, for example, and you selected a different site to look at that data, than maybe that other site doesn't even have that query at all. So that's something where we consciously made that decision. I think there are pros in cons to that. One thing I do when I compare sites is I just change the URL in the URL on top. It's kind of tacky, but it works.

MIHAI APERGHIS: Yeah, well at least if the date, for example, or the fact that you're comparing a date to another date would carry over, that is actually what I use it mostly, I guess.

JOHN MUELLER: Yeah.

MIHAI APERGHIS: I don't know if you can do that just for that or you need to do overall. But I--

JOHN MUELLER: I'll talk with the team to see-- maybe we can convince them. I've heard the same feedback from other people as well. But, of course, we don't hear from the people who like the current behavior. So it's--

MIHAI APERGHIS: Yeah, yeah, yeah, I guess you're right. One other question-- this is actually a site-specific question. I asked a few Hangouts ago regarding removing the geo-targeting for one of the websites that was already targeted to the United States. And they actually have an international audience. So we set it to unlisted [INAUDIBLE] completely. And we have seen some drops in organic traffic. And I wanted to ask you to take a quick look. When we took the website six months ago, all we found a lot of problems with the backlinks really, really spammy, which did not help at all. But I don't if there's any webspam going on. Or is it just the fact that we did that change in geo-targeting? So if anything pops up--

JOHN MUELLER: I don't see anything really obvious. So I am guessing this is just an effect of the geo-targeting changes you made or just normal changes on the website on the web-- so nothing fantastic.

MIHAI APERGHIS: Yeah, we've got quite a few categories of things. So I am guessing Google picked some time before processing everything, if there are a lot of changes going on at the same time.

JOHN MUELLER: Yeah.

MIHAI APERGHIS: OK, thanks.

JOHN MUELLER: I see a question from Tim in the chat as well. "We can contact someone from Google Webmaster Central regarding an interview?" I'd have to take a look at that and see what we can do there. So in general, if you need to contact someone from Google for an interview for a publication or something, the best way to do that is to email press@google.com. And they'll try to route it appropriately. But I can take a look at what you posted there and see what we can do there. We usually have to do all of this through the press team anyway to make sure that they're aware of what's happening. So we'll see. I can't guarantee you anything.

AUDIENCE: Hi there, John.

JOHN MUELLER: Hi.

AUDIENCE: Good morning, everyone. So on that note, I'm just going to piggyback. So what is going on with this mobile update? How come there's been such a blip, not the impact that was expected? Is this the right forum to ask that question?

JOHN MUELLER: Sure What do you mean such a blip?

AUDIENCE: Well, this mobilegeddon is no mobilegeddon. It doesn't have the impact, or is it that it's still rolling out? And so we still haven't really seen the impact? When I'm talking impact, I'm talking numbers. We haven't seen much of a variance. We've seen a variance on the 22nd and the 23rd-- but not as big as the impact was expected to be.

JOHN MUELLER: OK, so you would have liked it to be more visible?

AUDIENCE: I'm wondering why it isn't. Or will it be? What's your thoughts?

JOHN MUELLER: So it had rolled out completely. So this is essentially the current state that it's in. I think one of the difficulties here is that it's a very broad change. So while it has a fairly big impact across all of the search results, it doesn't mean that in every search result you'll see very visible changes. So that's something that affects a lot of different sites-- a lot of different queries. But it's not such that these sites disappear from the search results completely if they are not mobile-friendly. So that's-- I think, on the one hand, that makes a lot of sense for the sites that aren't able to go mobile-friendly just yet-- maybe like small businesses who don't have the time or the money to set up their sites for that. And these are results that are still very relevant in the search results. So we need to keep them in there somehow. The other aspect that we noticed is that a lot of sites really moved forward on going to mobile. So where we expected essentially a little bit of a bigger change because a lot of bigger sites weren't really mobile friendly, a lot of those really big sites did take the time to go mobile-friendly. And with that, they didn't see that much of a big change.

AUDIENCE: Ah, OK, So what was it? I just had one last question here then. What's the most surprising aspect about this update that you're observing?

JOHN MUELLER: The most surprising aspect-- I don't know. That's hard to say. I was really happy to see a lot of sites jump on and actually go mobile-friendly. I think the mobilegeddon name that was picked there was probably a bit too scary. And it scared a lot of people, maybe a little bit needlessly. But it also encouraged a lot of people to actually take that step and make their sites mobile-friendly. So it's something that had pros and cons there.

AUDIENCE: Do you think the biggest impact will be seen with the small business sector? Or not so much? I mean, they really weren't ready by April 21st.

JOHN MUELLER: Yeah, we worked a lot with the algorithm to try to make sure that we picked the right sites, the right queries and made sure that the results were still relevant there. So taking the small businesses out that have-- maybe older websites that aren't mobile friendly or that take a lot of work to make mobile-friendly. I don't think that really would have been the right approach there. So it's something where I think we rolled out something that's fairly broad that has a fairly big impact. But it's something where at the moment, we're trying to balance it to make sure that the relevance is still given that we just don't removed everything that's not mobile-friendly. I think over time maybe it'll make sense to dial that up a little bit-- maybe to include other factors as well. There was talk about speed-- maybe interstitials-- those kind of things. And I think over time, this will definitely evolve. But we need to make sure that the relevance of the search results are still given, even if you're on a smartphone, even if the sites are mobile-friendly.

AUDIENCE: Thank you.

JOHN MUELLER: Sure. All right. Let's grab some questions from the Q&A. "What's the best practice for posting press releases on a company website? We send out press releases via a service then posting the same content to our site. Will this cause duplicate content? Should they posted on the site first then sent out?" So essentially with regards to duplicate content, that's not something I'd worry about. That's something that we generally take care of fairly well on a technical level on our side. So we wouldn't penalize a site for having the same block of text on your website as there is on the press release site. That's something where we understand that sometimes there are technical and practical reasons for that-- that you have these texts duplicated. And we try to de-duplicate them in the search results. So if someone is searching for your company and we know that this press release is on a bunch of press release sites and your website, then we'll try to pick one of those sites, show that in search, and kind of keep it at that. So we'll index the different versions. But we'll try to pick one of them to show in search. With regards to posting at first to your site and then to other sites, I generally think that's up to you. That's something that I don't think would have a big impact on how we pick the sites-- the page to show in search. What is it? That other thing-- the main thing to watch out for with duplicate content is really not that you have some content which is duplicated. Sometimes there are like practical reasons for that-- also not that maybe there are some technical reasons why some content is duplicated, but rather just to make sure that primarily your website really has unique and compelling content of its own. So when we talk about something where we're penalizing site for duplicate content or manually or algorithmically taking action on that, that's really the case where the whole website is essentially just duplicated content. It takes content from various other sites. Maybe it rewrites them. Maybe it spins that content. Then that's something where we'd say, well, it doesn't really make sense to look at this website at all. We can take this out completely in an extreme case. In an other situation like this one with a few press releases that are duplicated or maybe there is a technical reason why you have things on two domains, These are all things where we say, well, that can happen. We have to deal with that on our side. The rest of the website is still really important-- really good content. So we'll still show that in search. And we won't demote a site or we won't penalize a site for having some aspects that are duplicated. "We had product schema for getting stars in search results in the past. However, none of schema shows when we switch to review schema. And it still doesn't work three months later, when even our competitors works with no reviews." So I'm not-- I don't quite understand this question with regards to whether or not this the star showed in the search results previously, and they don't show now. It's not that you basically switched to markup for them. If they showed previously and they don't show up now, then I would assume that maybe something is wrong with the way you implemented the markup there. If the stars never showed up at all, then I would assume that maybe there's something on our side where we're saying, well, we see this markup on these pages. But we can't really trust it. Maybe the rest of the website isn't really high-quality enough, trustworthiness enough that we say, well, we need to take a step back and consider what we show at all from this website with regards to rich snippets. So that's something where I differentiate between those two variations. And maybe there's a mix of that happening as well. But I'd definitely make sure that the markup is really used correctly. Also that you double check in our help center to see that the markup can be used for rich snippets because a lot of the schema.org markup is essentially supported on our site, but we don't use it for rich snippets. So if you want to use rich snippets, make sure you're using the type of markup that actually is supported on our side rich snippets.

MIHAI APERGHIS: Hey, John, regarding rich snippets, I actually have an issue a few weeks ago with breadcrumbs. So usually for breadcrumbs, we use the markup for the home page as well-- so the home page, then the category page. And in one of our client's cases, the homepage wasn't -- there was no anchor text. There was just an icon. An itag with a class that shows the home icon thingy. Now we use that. We added the markup of the testing tool showed everything is OK. In Webmaster Tools, we saw there about a week that everything was picked up OK. But it wasn't showing up in the search results. So is that a problem? Should we add-- well, we actually did add a few days ago text with a display-- a non-CSS style. Would that be a problem or is there any other reason that the markup would have shown up even if everywhere was resulting in OK?

JOHN MUELLER: So this is on the homepage?

MIHAI APERGHIS: No, on any page, any category or [INAUDIBLE] page, just the home link was actually an icon that was not anchor text or no actual--

JOHN MUELLER: OK like a house symbol or something like that for the home page. OK, I don't know. Good question.

MIHAI APERGHIS: The Webmaster Tools and the testing tool show everything is OK. Indeed, there was no anchor text as the title. So the URL showed, but the title-- there was no title-- a row in the testing tool. But there were no errors whatsoever. And in Webmaster Tools it did show them as being picked up and no errors at all. But we didn't see them in the search results. So now we added the brand name also, but display a non-CSS file not ruin the design. So is that a problem?

JOHN MUELLER: Generally speaking, that should work. I think one thing to watch out for with the breadcrumbs is we recently updated the schema that were breadcrumbs. I don't know if you saw that or which breadcrumb markup are you using?

MIHAI APERGHIS: The data vocabulary one, I think. I saw the post regarding the schema.org. Although on the web master help page, it still shows a message that is not supported yet. I wasn't sure if we should--

JOHN MUELLER: Oh, we should update that, yes. So basically there-- if you're using the data vocabulary markup, then that should work in any case. I think it might be kind of tricky if you're using displaynone for a text because we do expect to use visible content for rich snippets. One thing that might work is to use an Alt text on the image to let us pick up that text like that. That would be an option. I don't know if you had that?

MIHAI APERGHIS: It's not an image. It's a before content. And it's an icon CSS file that uses content in the code. So it's not an actual image file.

JOHN MUELLER: It might be interesting if you could send me a URL, then I can take a look and pass that onto the team so that they can double check. But in general, that's something we should be picking up. I don't know how quickly we would be showing the breadcrumbs. But if you waited a couple weeks, then that seems like something we should have been able to pick up there. But if you can send me a URL, then I can double check with the team on that.

MIHAI APERGHIS: Sure.

JOHN MUELLER: "A client's site I've been working on has no manual penalties against it. But it's as if it's been delisted. I still see lots of indexed URLs in Webmaster Tools, but nothing in terms of Google traffic. What could be going on?" That's really hard to say without being able to look at the site directly. So that's something where I'd recommend going to the help forums and checking in with other webmasters-- other people who have worked on websites so that they can take a look at your website to see what might be happening there, Checking for manual actions is definitely the first thing I would do there. I'd also check for technical issues-- maybe crawling errors-- maybe no index that's on these pages-- maybe wrong canonicals-- those kind of things. These seem like the normal technical things I would watch out for. But at the same time, I'd also make sure that if you're sure that the technical side is great, that also the content-- the quality of the content is given-- that it's not something where we'd say, well we've crawled an index's content. But it's not really something we want to show to users. Therefore, we're not going to rank it very well. But people in the webmaster forums or in the Google+ communities around webmasters-- they have a lot of experience with these things. And they can probably give you some tips on what you could be looking for. I've noticed some of the largest sites in the world allow Googlebot to index their internal search queries and search results using different tricks, all with no-index tag. This is against Google's guidelines. What action is Google taking on these sites? We do take action on these things. And this something where we try to take action both algorithmically and manually. The part, I guess, to watch out for is that sometimes something that looks like a search results page could actually be a very useful page to users. It could be a category page. It really depends a lot on the content on what is shown there. So that's something where I wouldn't categorically say everything that has a search in the URL is something that should never be shown. But it's something we try to find the right balance in. The big aspect also involved with search pages, especially if we can call them, is that we can easily spend a lot of time crawling these pages. If you can specify any variation of URL parameters there, then we can crawl and index millions and millions of these pages from even just a normal website that isn't that big. And that's a lot of wasted resources on your side and on our side. So that's something where we essentially spend a lot of time looking at the same things over and over again while crawling your pages. But we're not actually pickup up anything valuable-- anything that we can show in search. So this is something where the one hand, the webmaster guidelines try two point of the quality aspect. But there's also a very strong technical aspects involved with crawling and indexing search pages where everyone is essentially wasting time and resources on something that's not really that important. And maybe the important things on your website are being skipped because we're too busy crawling the search pages, which are things that we ultimately might not show that visibly in search. So there's always this dual aspect there that you have to keep in mind. "Title Rewrites recently launched a new product version. And on the day of launch, Google decided to revise the title to a three-year old version. This continues to be an issue with our website-- would love an ability to tell Google not to rewrite those titles." Yeah. I guess this isn't the first time we've heard this. Our algorithms do try to pick up the right things for these titles and to show them. But especially if you're looking at something that recently changed and we're rewriting it to something that doesn't make that much sense, that'd be something I'd really love to have that feedback directly. So if you can send me the URLs and the queries where we're doing this, that would be something that the titles team here would love to take a look at and would love to have as an example of something where something changed on the web. And we didn't reflect that quickly enough in the search results. And it's confusing you. So it's not that we're trying to confuse users. We're trying to simplify things a little bit show and show that appropriately. So if you have an example of a title issue like that, you're always welcome to forward that onto us. "Does priority and frequency matter in a sitemap? If not, how can we tell Googlebot to crawl specific pages on daily and high priority?" Priority and change frequency doesn't really play that much of a role with sitemaps anymore. So this is something where we tried various things. But essentially, if you have a sitemap file and you're using it to tell us about the pages that changed and that were updated, it's much better to specify the timestamp directly so that we can look into our internal systems and say, oh, we haven't crawled since this date, therefore we should crawl again. And just crawling daily doesn't make much sense if the content doesn't change. So that's something where we see a lot of sites. They give us this information in a sitemap file. They say it changes daily or weekly. We look in our database of what we see when we crawl. We say, well, this hasn't changed for months or years. Why are they saying it's daily? Clearly, there is a disconnect here we should probably ignore something there. So what I'd really recommend doing there is just using the timestamp and making sure that the timestamp is always up to date so that we can work with that timestamp and say, well, we crawled on this date. You're seeing a change on the other date. Therefore, we should call crawl again. And another thing to keep in mind there that crawling doesn't mean-- that isn't directly related with ranking. So just because we crawl something more regularly doesn't mean it will rank higher. It can happen that something stays static for years. And we've crawled it once maybe half a year ago. And it might be one of the most relevant results for some of the queries out there. So that's something where crawling and ranking isn't really directly related. So I wouldn't artificially try to make Googlebot crawl more if you don't actually have anything there that we can pick up on for indexing. Hreflang question-- "If Google Webmaster Tools reports one error with the sitemap, no return tags, does it mean that the entire file is ignored? Or would the only issue be related to that one region without return tags?" This is done on a per URL basis. So it's not that we ignore the whole sitemap, but rather we see that for this set of pages that you have specified, if that one return tag isn't there, then we kind of have to disregard that pair of pages. But the rest of the site map is definitely still processed. "Is the doorway pages algorithm now in place? If not, is there a projected date for it to take effect?" This is already launched-- the doorway page update. Also will it run in real time like the mobile-friendly? Or will it require periodic updates like Penguin?" I don't know for sure. But from what I've seen, it's something that does run regularly. It's not like every day. But it is run fairly regularly. Also, since this question suggests that you're still seeing a lot of doorway pages in the search results-- if that's the case, then I'd love to have those examples so that we can pass them on to their team. And we can figure out a way to improve our algorithms there. So if you're still seeing these kind of problems, we should definitely have those examples so that we can take a look with the team. "My site has an annual conference URL page annually that we archive at the end of the year in Google Search our 2014 annual conference URL appears before our 2015 conference URL. Is there any way to reverse this?" This is something that's always tricky because usually what happens is the older years collect a lot more information. We collect a lot of signals around the previous versions of this conference or if you have maybe different product models-- maybe the older versions have a lot of press around them-- have a lot of links-- a lot of signals that we've picked up on. So if you're searching for the product name, we might show the older version first because we just think that this is the more relevant one. One trick that I've seen people do, which essentially works here, is that you have one generic URL that you use for your product or for your conference. So you would have, I don't know, yourconference.com. And on your home page, you just have the current version. And when it comes to creating a new version for the next year, you move the current version to an archive. And you say, OK, this is 2014 to a new URL. And you put the new version on the home page again. So you reuse the main URL over and over again. And then we know that this is actually the most relevant version that we should be showing in search. But there's also this archive version where we have also information somewhere in our archive as well. So that really helps there.

JOSHUA BERG: John, on that question there, so would it make much difference or would it not be recommended to say move the previous content down-- say we're talking about different content in general where someone has a new article on this specific topic. And it's the same topic. Would it make sense to move that down and have a number of them there from some previous years versus just replacing them?

JOHN MUELLER: You could do that. I think that's something that's less of a search problem then maybe a design problem or philosophical problem almost like how you want to present your information to the user, if you want to keep the essentially older versions of that information on that same page as well. But essentially, that's kind of up to you. That's similar to how perhaps a blog might do that where you have the main information on the homepage directly-- some of the older information as well. And it rotates out over time. Maybe the older information just has a snippet and a link to the archived article. That's essentially up to you.

JOSHUA BERG: All right, thanks.

JOHN MUELLER: Where can you report do-follow comment spam links? Is it the same form as the page links form. Sure, you can use a paid links form. You can also use a general web spam form. Both of those end up going to the webspam team. And they can take a look at that. I imagine with comment spam, it's a little bit tricky because it's hard to tell who added that comment spam. But if we recognize that there's a general pattern that we need to take action on, then that's something that the webspam team might want to know about. The important part there is also that the webspam team can't promise to take action on all the reports that we get there. We get a lot of reports. And we need to prioritize those somehow. So the easier you can give us the bigger picture in the webspam report, the more likely we'll be able to take action on the bigger picture. Whereas, if you just give us one comment URL that has a spammy link in it, that's something that we say, well, it doesn't really make sense to take manual action on this one comment spam link that was dropped there. But if you can give us a bigger picture, that's definitely something we can look at and figure out how we can prioritize that appropriately. 'My site has a warning that it may be hacked. But there's no warning in Webmaster Tools. Also Google's cached version of the home page is very out of date. I've tried to submit via Google Webmaster Tools to advance the process, but no change. The SERP looks very odd. What else can we try?" So sometimes what happens there is that a site might get hacked or defaced by hackers in a way that isn't directly visible to the webmaster. So maybe you open a page, and they're cloaking to Googlebot or they are cloaking to our IP addresses. And that's something that you don't directly see in your browser. So I'd recommend going with Fetch as Google in Webmaster Tools to double check that it's really your normal content and not something where there are hidden pharmaceutical links or any kind of other links on these pages. I'd also double check with other search engines, maybe do a site query for the site, and add a bunch of spammy keywords that you think might be involved there and see if anything from your site pops up there where maybe some search engines have noticed that this there is this spammy, hidden content on your site. If you're sure that everything is clean or if you've noticed something, and you've cleaned it up, there is a form that you can submit which I linked to in a Google+ post a while back. I'll try to dig it up and add the link to the event entry. If I forget or if you can't find it there, feel free to contact me on Google+, and I'll send you a link to that form. That's one that goes essentially to our engineering team to work on that feature to double check what actually is happening here-- why we're picking this site up as still being hacked when maybe it hasn't been hacked or maybe you cleaned it up and we just aren't recognizing that cleaner state yet. So this is something where the algorithm essentially runs on its own. But giving feedback to the engineering team sometimes helps us to make sure that we're getting it right that the algorithm is picking up the right issues. "Webmaster Tools needs a tool to handle keywords not associated with the site. Now that it's hard to see what keywords someone used, it's hard to tell why they bounce many times. It's unrelated keywords I would rather reject and not ruin my bounce rates." That's an interesting feedback. Usually we hear the opposite that people want to specify more keywords for the site to rank. But I can totally understand that maybe it makes sense to understand where things are happening-- why people are going to your site if you're tracking things in analytics and want to have cleaner data there. I think in general this isn't something that is likely to happen in Webmaster Tools just because we do try to pick up the most relevant keywords on our page. And if we have trouble picking up the relevant keywords on a page or ranking the page for irrelevant terms, then that's something that is more of an issue on our search algorithms and something that I'd say the webmaster would need to manually override. So if you're seeing that a site is ranking for irrelevant keywords, you're welcome to pass that on to us to let us know about that. But I will also take this up with the Webmaster Tools team to see if there's something that they might be able to add there. OK, here's a question about the interview. I'll double check that later. "As we all know, Google's main income is from ads. Many SEOs, online marketers, et cetera believe that Google makes SEO more difficult in order to increase revenue from ads. Is that true? If not, can you explain why?" This is definitely not true. So this is something where we have a very, very strong firewall essentially between the paid side of Google and the organic search side. And that's not something that we would connect where we would say we would make algorithms that make the search results worse so that people go and click on ads more because essentially if we make our service worse, then people are going to go to other search engines. There are other search engines out there. And some of them are really good as well. So it's something where we're not artificially trying to make it more complicated or harder or the search results worse so that people click on ads because in the long run, we need to be able to provide really high quality, fantastic search results if we want people to stay with our service. So that's something where on the one hand, we really have the strong separation between the two sites. On the other hand, we really need to keep that upright so that we can make sure our search results are really as neutral as possible as high-quality as possible and really provide what users want. "What actions does Google take on grey hat SEO technique similar to black hat-- no actions at all. What exactly does Google consider grey hat?" I don't know what you're referring to as grey hat. So from that point of view, I don't know how we would be able to react to that. Essentially when it comes to things that are clearly black hat and clearly white hat, that separation is sometimes very easy to do and sometimes it's very hard to understand what exactly is happening here. Sometimes we have to take a look at the bigger picture for these websites and see what is really happening here. So that's something where we take manual action. On the one hand, we take algorithmic action. We try to make our algorithms robust against any kind of abuse. We try to make our algorithms so that they ignore the accidental abuse that happens. So you've probably all seen this where a website follows advice from someone who read something on an SEO blog 10 years ago. And they stuff hundreds of keywords in the meta-description tag. And when we crawl that, we look at that. And we say, well, clearly someone was trying to follow outdated SEO advice. But instead of penalizing site for doing that, we try to see that and say, OK, well, we recognize this. We'll just ignore it completely. Or when it comes to keyword stuffing, that's essentially similar. We will try to recognize that. We'll say, well, clearly they are trying to abuse our servers and trick us into thinking that this page is more relevant. But maybe they're doing accidentally. Maybe they don't really know what they're doing. Maybe they copy and paste something wrong. We'll try to err on the side of caution and just say, well we'll just ignore this keyword stuffing and focus on the rest of the site as it were a normal site-- a proper site-- where they're trying to do the right thing. So we don't assume that everyone is out to spam our systems by default. But rather, we try to figure out which parts of these pages are relevant, which parts are maybe artificially exploded that we can ignore and rank those pages appropriately. "Search analytics can only provide 99 queries per website. Are there any plans to expand it? If not, please take this as a request?" I've heard this from other people as well. So your request is certainly heard. I think there might be some tricks where you could get a little bit more information about the queries. For example, if you drill down to maybe filter for a subdirectory or you filter for specific queries or specific sets of pages, then you can get more specific information there. But at the moment, I don't think we'd show more than 1,000 results in the table below. So that's something we'll definitely take that on and see what we can do to expand that over time. "How important is it for a site to have a last modified HTTP header?" It's hard to say. It depends on the website. So it's not something that you always need that every site needs. But especially if it's something where we crawl a site very frequently, then this helps us to save bandwidth to make it easier for us to crawl your site. So if you have the last modified header, and you respond to those requests appropriately, then essentially we'll just ask has this page been modified since the day when we crawled it. And you say, no. And that's fine for us. Whereas if you don't have this header, we'll ask your server, hey, has this page been modified since the last time crawled it. And your server will say, I don't know. Here's the contents of a full page. And that's a lot of bandwidth. So if a website is constrained on bandwidth-- if you're limited on bandwidth-- if you have a lot of pages that change frequently or that need to be crawled regularly, then obviously this header makes it a little bit more efficient. But it's not something where I'd say these pages will rank higher because of this header. It's similar to the question the beginning where the crawling of these pages isn't really related with the ranking of these pages. So if we can pick up the content appropriately and we can index that content, then we'll try to take that into account for rankings. You don't need to force us to re-crawl that content or you don't need to use this header to optimize the crawling of these pages. Essentially, we have that content. And we can work with that. That said, this is always a good technical best practice. So if you're implementing websites, then that's definitely something to do. I think a lot of the CMS systems out there already implement this by default. So it's not something that you need to manually add yourself. So if you're using WordPress, for example, it does this automatically. There's nothing magical that you need to do on your side to get that implemented. "We want to launch--"

AUDIENCE: Hey, John, can I ask a question?

JOHN MUELLER: Sure, go for it.

AUDIENCE: You have released a webmaster as a beta version-- a new design where we can figure out the [INAUDIBLE] particular design in [INAUDIBLE]. However, it's more of a request of if you could get the data in terms of once. We usually get to see the data in three months. So if you could increase to that range to over six months because as you know, that search organically-- it takes time. So again, it takes time to build that data to analyze. So three months is a very short time to analyze that sort of data. So is there any possibility that you could do that?

JOHN MUELLER: That's a good request. We've heard that before. And I know the team is aware of that. But I don't have any plans to announce just yet. So this particular feature is still very new. So I know the team is still working on some of the aspects there. Maybe that's something that they can add at some point. But I don't have anything to announce just yet.

AUDIENCE: Thank you.

JOHN MUELLER: All right, let me run through the remaining questions very briefly. And then we'll get back to questions from you. We want to launch in English, French, and German. Is it OK to do that on different domains, not only TLEs, but the domain itself? Yes, it's certainly possible. You can do hreflang between those versions as well. It doesn't need to be the same domain name. It can be a different domain name-- a different TLE-- whatever you need for the different language or country versions. That's certainly possible. "Best practice on thin category facet pages-- a few listings that occasionally are empty-- no listings. At the moment, we're using no-index and getting lots of soft 404s. Is that something to worry about?" That's fine. Using no-index on those pages is perfect. We'll treat that as a soft 404 because essentially you are saying, well, there's no content here to index. But that's not something that would cause any problems. So, essentially, we're dropping the page from our search results. And from your point of view, it doesn't really matter if we're dropping it because of a soft 404 because of the no-index. Essentially we're not showing it. And that's what you want to have done. So that's perfect. "I have noticed a big difference between Google and CloudFlare analytics on my site. Sometimes this difference is over 50%." I don't have any information about either of those services. So specifically analytics versus CloudFlare analytics-- I don't know what they're tracking. So you probably want to check in with the analytics forum on that. "Is there a problem I have to fix? And if not, what's the reason for this huge difference?" Yeah, I think this is something you'd probably want to pick up with the analytics team to see what you're seeing there-- what they're showing in their system as well. "I've been working for this website-- [INAUDIBLE] web site metatags-- sidelanes information are not showing up in search results. I have requested they crawl the domain and Google Search shows the old data. Googlebot is not crawling and indexing our domain." I don't know. That sounds like something I'd have to take a look at separately. In general, usually we would still be crawling. So this is something where I'd check Webmaster Tools that the crawl rate setting is set appropriately-- that we could still crawl your content-- that you're not blocking us with robots.txt or with server errors-- any temporary errors that we're seeing. Those are kind of the technical things I'd watch out for there. "A website is mobile friendly. But search results say it's not. Here's the website. And the question-- Webmaster Tools forums. I have copied that onto the site so I can take a look at the forum thread afterwards." In general, one of the things we've noticed with regards to a lot of sites when they're mobile-friendly, but we can't pick that up as mobile-friendly with our testing tools, is that maybe some of the content-- the CSS or the JavaScript-- is being blocked by the robots.txt file. And if we can't crawl the CSS-- JavaScript images, for example, then we can't always tell that it's actually a mobile-friendly website. So that's a common reason there-- something that I'd look out for and make sure that it's not happening. I'll double check in the forum thread though to see if there's anything specific to add there. All right, we still have a couple minutes left. What's on your mind?

MIHAI APERGHIS: Yeah I'm going to go ahead. Really quick things-- I hope that the breadcrumbs URLs issue can be checked. I hope you got them. Regarding soft 404s, we actually use a method on actually the same site where we count the number of products on a category and if that is zero, we add the no-index. So for example, the owner of the website wants to create the categories because he knows he'll be adding products in the future. So that's no issue if he has a product that no-index will be automatically removed. That's no problem?

JOHN MUELLER: Perfect.

MIHAI APERGHIS: OK, and since you already reached a new feature of Webmaster Tools search analytics, what's next in store. What can we expect for the next few months coming as the features?

JOHN MUELLER: I don't have anything to announce sorry. I think there might be some interesting things coming up. One of the things we've been working on is a lot with app indexing. So I did a submission form for people who have Android apps and are using app indexing and would like to try some things out. So if you're doing that, I appreciate your submissions. And we'll get you to try some things out there. But at the moment, I don't have anything else that I can really pre-announce for you, sorry.

MIHAI APERGHIS: All right, OK, cool.

JOHN MUELLER: All right, more questions-- everything clear?

JOSHUA BERG: John, I think what people have mentioned about the doorway pages algorithm is that there was such a small difference, or at least that's the way it appeared. Maybe that's similar to what you were talking about earlier with the mobile-friendly algorithm. But many people are still seeing a lot of doorway page type of content. So is that something where a future fine-tuning with picking that up.

JOHN MUELLER: Yeah, I think it's something where having feedback from you guys where you're still seeing this happening would be really useful. I know the team that has worked on this. They've try to make sure that we're really picking up the right things. And maybe that's too limited of a scope. Maybe they need to broaden that out a little bit more. But having really concrete feedback on what you're seeing-- where you're saying, well, this is probably not that great. Google should do a better job of recognizing these are all the same-- maybe folding them together or maybe demoting these sites a little bit more so that the actual content is actually more visible. That's something where your feedback will be really useful. So especially if you're saying people are still seeing these in the search results, that's something we'd love to clean up. And if you are seeing these things in search results, by all means, send me screenshots, send me queries, send me sites, and I could pass that on to your team so that they can discuss this to see where they need to fine tune things for the future.

JOSHUA BERG: Would user reactions to these types of pages have a significant effect so that if particular doorway pages maybe had a significant amount of content although it was very much a duplicate to a lot of other pages and just the city name was changed et cetera? But maybe that was especially popular in a particular area for particular queries so that it wouldn't necessarily be targeted. Or would that be outside of that realm?

JOHN MUELLER: I don't know specifically how you mean that. But the feedback that we get from users about these search results especially through the feedback link on the bottom of the search results-- that's something we do to take into account. That's something that the search team gets forwarded as well so that they can work on improving the algorithms there. So from that point of view, that's definitely something that happens.

JOSHUA BERG: All right, thanks.

JOHN MUELLER: All right, so with that, we're out of time. I'll set up to the new Hangouts for I think in two weeks. And maybe we'll see you again on one of those. Thanks for dropping by. And I wish you all a great weekend and good start into next week as well.

AUDIENCE: Thank you.

JOHN MUELLER: Bye everyone.
ReconsiderationRequests.net | Copyright 2018