Reconsideration Requests
18/Dec/2018
 
Show Video

Google+ Hangouts - Office Hours - 08 September 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: All right. Welcome, everyone, to today's Google Webmaster Central office hours Hangouts. My name is John Mueller. I'm a webmaster trends analysts at Google in Switzerland, and I'm trying to bring across some of the information we have around mobile sites at the moment and hope some of this will be useful for you guys. I have a short presentation planned, but if any of you want to ask a first question around what mobile sites, feel free to jump on in and go ahead.

AUDIENCE: I have a question, John.

JOHN MUELLER: Okay.

AUDIENCE: Will the HTTPS certification help mobile sites also rank slightly better?

JOHN MUELLER: Yes. That's essentially independent of anything from mobile or desktop.

AUDIENCE: Cool.

AUDIENCE: But does the mobile ranking factor only impacts mobile search results or smartphone search results?

JOHN MUELLER: I'm not exactly sure what you mean there, Barry.

AUDIENCE: So there is a mobile ranking factor, right? Like a smartphone ranking factor?

JOHN MUELLER: I mean, primarily what we do is demote sites that we can tell don't work well on mobile at all. So that's--

AUDIENCE: You don't demote sites? [INTERPOSING VOICES]

JOHN MUELLER: Mobile ranking factor, yes.

AUDIENCE: You don't demote the sites that are desktop that are not--

JOHN MUELLER: Exactly. Yeah I mean, this is something that only makes sense to do for those users that are affected. It wouldn't make sense to demote a site in desktop search if it's just bad in mobile search or for mobile users.

AUDIENCE: Thanks.

JOHN MUELLER: All right. Let's see if I can make this presentation work. I can find the right tab and share something interesting. So some of you, I guess, will have seen some of this before. For others, it might be kind of useful. I tweaked it a little bit to include some of the newer things that we've been seeing recently. So let's go ahead and get started here. In general, what we recommend is that you also use a smartphone to access your website so that you see what users would actually see when they access your website. That's not particularly new, but it's something that I think makes a lot of sense, because people tend not to notice how bad their own site is on mobile because they rarely view their own site on a smartphone. But lots of people are using smartphones, so definitely go ahead and get started on that as soon as you can. We have a lot of recommendations, put together a lot of technical information on building smartphone friendly websites. I recommend going through that as much as you can, as much as it makes sense to you, so that you at least understand a little bit more about the basics of what we're trying to do and the basics of our recommendation about the things we recommend to avoid as well. With mobile, one thing to keep in mind is we're primarily looking at smartphones at the moment. Feature phones are something that tend not to be as relevant anymore for mobile search. There are definitely areas where feature phones are still very prominent, but for the most part, we've noticed a lot of people try to use smartphones, and that's what they have the bad results, essentially. Tablets are less of a problem, because usually they can just view the desktop site just fine. We have three configurations that we support. For the most part, you can just pick whichever one works best for you. We have one that we recommend, but essentially all three of these can rank just as well. So it's something where we try to bring a recommendation out so that people who don't really know which one to go for have some guidance there. But essentially you can pick whichever one works best for your website, for your infrastructure, for your web master, whatever your considerations are. So essentially we differentiate between two variants. On the one hand, you use the same URLs for your mobile site, or you could use different URLs. So different addresses for the mobile friendly site. Sometimes for different addresses they'll do things like an "m dot," where you have your main domain, main website on dot-dot-dot example.com, for example, and your mobile version on m.example.com to show that this is for mobile. That's fine. Just use whichever variation that you want. If you're using the same URL, you can choose to either serve the same HTML content or to serve different HTML content. Same HTML content we call responsive web design, where essentially your website works on a variety of devices and screen sizes. A dynamic serving is when your website dynamically changes the content that it sends to the user, depending on the device And for different mobile URLs, you can use either one. Most commonly, you just use different HTML there. So it will be similar to dynamic serving except on different URLs.

AUDIENCE: John, we're having an argument about this slide in the chat. You mind if I ask a question while you're on that slide?

JOHN MUELLER: Go for it.

AUDIENCE: So there's an argument saying-- some say that Google says responsive will rank better than the other two formats. Is that true or not?

JOHN MUELLER: That's not true.

AUDIENCE: Okay, thank you.

JOHN MUELLER: So you can use any of these variations. We recommend responsive web design primarily for technical reasons, because there are fewer things that can go wrong. But essentially you can use either of the three, so whatever works best for you. Sometimes there is a CMS behind your website that makes it easier to use one or the other of these. Sometimes that makes sense to kind of take that into account. But essentially that's up to you. And ranking-wise, they can all rank just the same. Webmaster Tools is really helpful for mobile sites, because there's some additional information in Webmaster Tools that you might miss othewise. So I'd recommend using it in general, but I definitely recommend using it for mobiles sitres so that you have all of the information you need. Specifically around smartphone crawl errors, if there's something specific to your mobile site that's not working right, Webmaster Tools can generally help you a little bit. PageSpeed Insights is another really useful tool that we have available. It gives you a screenshot of your site as it might appear on a smartphone and scores your site on the one hand based on speed metrics-- so what you could be doing to improve the speed-- and also to improve the user experience on a mobile site.

AUDIENCE: I'm obsessed with that. I'm obsessed with that. I just wanted to ask you a question, though just in regards to the-- I see some of my clients have above 83, but does that help to have above 83? I mean, does that help ranking as well?

JOHN MUELLER: At the moment, that's not something we take into account directly. So there are things like around the user experience where you have indirect effects, where you might see some changes where if users are using it on mobile, they can recommend it to other people. One element that's involved there, which does have an effect in the search results, is whether or not your site uses a lot of Flash, for example. I believe that also shows up in Pagespeed Insights. And if your site has a lot of Flash, we might show the little Flash badge in the search results or say that this is primarily a Flash site and kind of make it clear to users who are using smartphones that this site probably isn't going to be as useful for them because they can't really use it if they don't support Flash.

AUDIENCE: Google already did say that it's better to have above 83, right?

JOHN MUELLER: I don't know what the threshold there is. I think that's something you'd have to look at yourself with those sites, especially around user experience. It's really hard to say this number is good, this number is bad. But it's something where I try to look more into comparative metrics, where you find a site that you really like, that you think works great on mobile. Check that score out, and say, I want to aim for at least that. Or as you're working on a site, show that you're improving on that score. So you start off with, like in this case, 46, and you came out with 71 or 85 or whatever. So it's showing the improvements that you're doing there. Like I mentioned, Pagespeed Insights also takes into account user experience elements, so things like whether or not the page is of [INAUDIBLE] so that it works well on smartphones, how big the user interface elements are on that page. And those are things that users will generally notice, but which also make it a lot easier to recognize that the site is doing things properly for mobile users. It doesn't have two pixel titles or links to click on. It actually has buttons that users with normal sized fingers can tap on. One thing we haven't mentioned so much in the past, but I think is picking up a little bit in the sense that we're noticing that this is a bigger problem than we initially thought, is robots have text issues around mobile sites. So this isn't something that users would see, because users don't look at the robots.txt before they access a page, but we see that a lot when we crawl these pages. Essentially so that we can recognize that a site is mobile friendly, we need to be able to crawl it in a way that we could see the mobile friendly page. So that includes things like being able to crawl the CSS, being able to crawl the JavaScript, especially if the JavaScript is used to create a redirect to your mobile friendly pages. So if CSS, JavaScript, or the mobile friendly pages are relevant, then that's something we'd need to crawl. Sometimes people also block the crawling of their [INAUDIBLE] pages, for example, because they say, oh, Google should index my main desktop site, and again, that's a problem for us. We see a redirect to a page that essentially we can't look at, so we can't tell if this is really a mobile friendly page, and we can't really take that into account in the search results. So as much as possible, if you have a mobile friendly site, I definitely recommend letting us crawl CSS, JavaScript, and of course the mobile friendly pages. Interstitials is a common problem that we've seen, where we try to crawl page with a smartphone, and instead of getting content, we get an interstitial that says, hey, you should download our app instead. And from our point of view, what happens there is we find this interstitial. We index the interstitial, maybe on a separate URL, and we can't actually find a connection to your desktop pages. So we are disconnected from recognizing the connection between the desktop pages and the mobile pages, and we can't rank that appropriately in search, then. We can't see that this is actually mobile friendly page. Broken redirects is something we've sometimes seen, where if you have different URLs for the mobile friendly page and for your desktop page, and you redirect from one version to the other. If you redirect to an error page, that's a really bad user experience. Sometimes we see soft 404 pages as well, where you access a page in the search results, and it brings up an interstitial that says, hey, this page isn't available for mobile. And in a case like that, the best solution is really just to keep the user on the desktop page. If you don't have a mobile page for that, let the user at least see the desktop page. So that's something to keep in mind. Faulty redirects is also a really common problem that we've seen. We've sent out lots of messages to webmasters about this, where essentially someone clicks on a desktop URL in the search results, and instead of seeing that specific page in the mobile version, they get redirected to the home page of the mobile version. So you click through to some article, on, I don't know, SEO Roundtable, and essentially, instead of getting that specific article, you get redirected to Barry's homepage, which is a really bad user experience. And it's almost impossible for us to recognize the connection between the desktop and the mobile pages, so that's one reason we send out a lot of messages about this. Unplayable videos, Flash content, obviously, as we mentioned before, if this is something that doesn't work on mobile, try not to show it to mobile users. For videos, there are alternatives, like HTML5 compatible videos, or HTML5 video players that download the right files for the right devices. So that's something where it makes sense not to serve the Flash content to mobile users. If you prefer to use an app instead of a mobile website, that's also possible now, in the sense that you can connect pages from your website to your app. And depending on how you do that with this app indexing set up with the site maps and the different-- what are they called-- action links between the app and the page on your website, we can actually show a link to your app in the search results so that users can go directly to the app or they can download the app instead of going to your webpages. So that's something probably worth keeping in mind if you want to create an app. If you don't have an app, obviously maybe look at this in the future when you do create an app. But it's worth keeping in mind. One thing that's fairly new is in Chrome. It's really neat in how you can look at pages now with a mobile device. So to emulate different types of smartphones, different sizes of tablets or different phone types. And you can also emulate different network situations, so if a user's on Wi-Fi or using 3G, and try your site out like that. So that makes it a lot easier to double check how you set your site up to see that it actually works. And if you're looking at different themes, for example, for your blog or for your website and you have a theme directory that you're going through, this is something that makes it a lot easier for you to double check that these themes actually work fairly well on mobile. All right. So kind of through the list here. Like I mentioned, there are different ways you could make your mobile site work. All of them are possible from our point of view. From a ranking point of view, they're all essentially equivalent. We recommend using Webmaster Tools and Pagespeed Insights so that you get all of the information you need from our side. Avoid blocking crawling of CSS, JavaScript, or mobile pages. If you have separate URLs, avoid app interstitials. Make sure you redirect correctly, and avoid technologies that don't work on mobile. So if you have a Flash site, maybe it's worth setting up either dynamic serving to serve an HTML5 version of the site, or maybe even moving to something newer overall. And of course, try your own website out yourself, or at least user a Chrome emulator so that you're sure that it's more or less works. And that's essentially it for my side. [APPLAUSE] Do you guys have any questions?

AUDIENCE: Yeah, faulty redirects. So is there a limit, I mean, if a site has, let's say, 20 faulty redirects on an ongoing basis, is that going to eventually-- because Pierre did touch on that. He said that it can affect ranking, right?

JOHN MUELLER: Yeah, so I think pages that have a faulty redirect, I believe we demote at the moment. We show this label, "may redirect to the home page," and you can click on "try anyway." So for individual pages, you've probably seen a lower visibility of those pages on smartphones. For the site on a whole, I don't think you'd see any big change there, because we know that this is an issue that is primarily an issue on individual pages, not across the whole site. So it makes sense to try to treat that as granular as possible.

AUDIENCE: So once it's fixed, it'll go back to itself, right? Or is it demoted for--

JOHN MUELLER: Yeah. As we re-crawl and re-index those pages, when we can see that it's redirecting correctly, we'll remove that label in the search results, and it'll rank normally again.

AUDIENCE: Okay. Thank you, John.

AUDIENCE: Hey, John?

JOHN MUELLER: Sure.

AUDIENCE: So Barry and I were debating this responsive design thing, and I'm confused at your answer a bit. I mean, I understand that Google will allow you to use each three methods, but back on November 18, Pierre Far and you were in a Hangout, and Pierre Far said that responsive design had both, and I quote, "second order wins and first order wins." And on June 27 of this year, you mentioned, and I quote, that "the responsive gives a boost," and I quote you, "you kind of credit your website with that extra value you are providing," end quote. So it still seems to me based on that, that not only does Google prefer responsive, but it might even give you a slight boost, or there's some kind of SEO win. Or maybe not messing up the redirects or-- I don't know what it is, but--

JOHN MUELLER: It's definitely not something where we'd say if we recognize the site is using responsive design, or if it's using some other method, we'll promote the responsive version higher. Essentially we treat them equivalently. There are just some aspects of responsive web design-- for example, by using the same URL-- that make it a lot easier to avoid mistakes. So you don't have this issue with the redirects, you don't have the multiple URLs, that could potentially be linked to where you'd have to watch out for the rel canonical pointing back to your main URL. All of those issues kind of fall away. So there is a lot less, I'd say, potential problems that you can cause yourself by having one single URL. And of course, you can check this page a lot easier on desktops just by choosing a smaller view port, for example. It's not something where you have to actually try it out on a mobile device to make sure that it's working correctly. So I think there are a lot of advantages there, but it's not that we'd say there's an inherent ranking advantage by using responsive web design.

AUDIENCE: Cool, thanks for the answer. Barry is now very happy that I'm wrong, and he can bug me about it.

JOHN MUELLER: Good. Well, I mean, I think it's not a matter of who's right or who's wrong, but it's important that you guys have all of this information so that you can take that into account when working with websites who want to move to mobile.

AUDIENCE: Oh no, for Barry, it is a matter of who's right and who's wrong, especially when it's me.

AUDIENCE: It's OK to be wrong sometimes.

JOHN MUELLER: I mean, everyone is wrong sometimes. And these things can change over time. So it's good to keep asking us these questions just to make sure that you're not missing anything subtle there has slightly changed.

AUDIENCE: Speaking of wrong, Matt Cutts just himself switched from HTTP to HTTPS. He used a 302 redirect. Is that the wrong approach?

JOHN MUELLER: I don't know. I don't know what Matt is doing there, so it's possible that he's still looking into this or that he's just trying something out. 302 could work there as well. It kind of depends on what you're trying to do. For the long run, we definitely recommend using a 301 so that it's clear that you really want this other URL to be indexed. But if you're trying things out, 302 is a good way to do that as well. In the long run, I imagine our algorithms will try to figure out what this 302 actually means. So if you were to leave it at 302 and it were to stay like that for, I don't know, a year or whatever, then at some point we think, well, this isn't really a temporary redirect. It's permanently there. And we might treat it as a 301 anyway. But there are lots of possibilities, and I can't read Matt's mind. So maybe he's just trying things out. And it's good to see more sites trying try to move HTTPS. I think that's not always trivial, and there's some things involved there that people just have to try out and take step by step.

AUDIENCE: John, I'm just on secure browsing. You hear me?

JOHN MUELLER: Sure, yeah.

AUDIENCE: Secure browsing is obviously very popular at the moment. Is that basically the-- it's not any kind of boost or a benefit from having a secure version, but from forcing a secure version, rather? So a 301 you get rather than just saying, well, I do have an HTTPS which you can go on the site. We're using it all the time.

JOHN MUELLER: We're essentially looking at the page as it's indexed. So if you happen to also have an HTTPS version, but that's not the one that's being indexed, then we wouldn't take that into account.

AUDIENCE: All right. So it needs to replace it, basically.

JOHN MUELLER: Yeah, exactly. All right. Let's go through the questions and see if we have any mobile ones there to keep everything themed together. Is there a preferred method of mobile site currently can serve up totally different versions of the website or have the website responsive? Which is preferred by Google? We look at this previously, and essentially, those three options are up to you. Whichever one works best for you. And go with that. So it's not something where we say there is a ranking advantage. We recommend using responsive web design because there are just fewer things that can go wrong. It's a little bit easier to keep up with technically. But essentially, you can use any of these methods.

AUDIENCE: John, isn't it, technically, isn't it heavier to have a responsive site?

JOHN MUELLER: It depends on how you set it up. I mean, it sends the full HTML, but it kind of depends on how you set it up, how you use images. It doesn't necessarily have to be a larger site. But of course, depending on the type of your website, there might be a lot involved in actually keeping something really sleek and responsive. So it depends a little bit on your website and a little bit on what you actually want to provide on the mobile version or what you don't want to provide. So if, for example, your desktop page has a lot of banners on it, a lot of ads, a lot of images in the sidebar, those kinds of things, a lot of extra HTML in it that you don't really need to serve on mobile, then maybe it makes sense to strip that out and go with something dynamic serving or with separate URLs even to really have a sleek mobile version. But if you have a really sleek desktop version already, then maybe there's not much that you need to strip out for mobile. It kind of depends on your website.

AUDIENCE: Cool, thanks.

AUDIENCE: I have an HTTPS question.

JOHN MUELLER: All right. Go for it.

AUDIENCE: If it's [INAUDIBLE] on the questions. About a week ago, Searchmetrics came out with a study reporting that in their analysis, there is no relationship at all between any ranking boost on the HTTPS side, meaning those sites that are HTTPS have seen no improvement at all, even though it's a minor signal, they've seen actually nothing at all in terms of ranking improvements when switching to HTTPS. Do you have any thoughts about that or--

JOHN MUELLER: Well, I don't really know how they checked all of this, but we do see this is as a lightweight signal. It does affect-- I think we said 1% of the search results. So it's not something that is visible everywhere. So from that point of view, it might be that they're looking at it slightly differently or slightly different. But it is something that's live at the moment. It does affect the search results.

AUDIENCE: Okay, thank you.

AUDIENCE: That's not completely accurate, Barry. It only showed a not scientifically significant increase when they removed the outliers. For the outlier sites, there was a major increase for HTTPS. But the outliers where big sites like Walmart and stuff like that.

AUDIENCE: No, the outliers are big sites like Google. That's a big outlier.

JOHN MUELLER: It's really difficult to reverse engineer this, considering that we do so many changes in search all the time anyway. And trying to reverse engineer one specific change and how it might be affecting the search results is really hard to do. I think it's interesting to see these kind of reports, because it also something that shows how webmasters or how these different data analyst sites look at this data as well. So I think it's interesting. I think it's great that people try to analyze this. But I don't think that you'd always see a one to one matching with everything that we'd see on our side. But it's definitely something we do take into account. I think depending on what you're doing specifically on your website, what is still left to do, you have to prioritize things. I wouldn't necessarily put HTTPS on the top of my list for all websites, but for some websites it might make sense to put it just a little bit higher up. For other websites, it might make sense to put mobile a little bit higher up. I think overall if you're a small business and you have a normal desktop website and you can choose between making a mobile friendly version or getting everything moved to HTTPS, I definitely recommend going with a mobile version at the moment. There are a lot of wins with having a mobile version. It's something that all users essentially see when they come with a smartphone to your website. So there's a lot of extra possibilities there. But if you're looking at a complete redesign at some point and you're saying, well, I can put this in with my 50 other things that I'm redesigning at the moment, then I'd definitely put that in at some point.

AUDIENCE: John, can I ask you an important question regarding hreflang, please?

JOHN MUELLER: Sure.

AUDIENCE: One of the things, obviously, you-- [INAUDIBLE] and all these situations that we've already been through. The thing that becomes very apparent is that the site that we have, a dot-com that has a Penguin penalty is the X-Default. Now, I'm wondering now-- obviously everybody's waiting for the update. Nobody sees it coming anytime soon. We've got 130 offices worldwide. They're affected by these changes for years now. What would happen if I created another site to be my X-Default? And kind of relegated the dot-com being some obscure version of whatever we can think is most convenient?

JOHN MUELLER: It's hard to say. So we'd probably respect the hreflang markup in a case like that and try to combine that with other signals that we have and use that as the default page there. But it's a complicated situation in your case, because you have, I think, the UK version and the dot-com version?

AUDIENCE: Yes, that's correct. UK has the hreflang, and the dot-com is the X-Default.

JOHN MUELLER: Yeah, I don't know.

AUDIENCE: I don't want to have to do this, so--

JOHN MUELLER: I don't know if there's any-- at least there's no clear, technical advice that I'd say go for either way. Because it's possible that we'll just follow the X-Default. It's possible that we just have so many signals pointing at the dot-com version that we'd say, well, this is more likely to be the default version. It's really harder to say in general. Sorry.

AUDIENCE: Yeah. I mean, I don't want to go down this route, obviously, because I'd much more prefer that we know our site's in a good situation. Otherwise you wouldn't like our [INAUDIBLE] UK, which is ranking well. So I've kind of been backed into a corner a little bit by the offices in different countries who are struggling. Dot-com, we're still in 300th place for major keyturn virtual office, but we're in the top five in the UK. So that's such a disparity, but the sites are identical.

JOHN MUELLER: So I guess one possibility might be to just do this for individual countries or try it out with individual pages. But I don't think I'd have any general advice and say, this is a really quick way to fix this problem. But if you want to try it out for individual countries, I could see that making sense. If you want to trust the individual pages, that shouldn't have an effect on the rest of your site.

AUDIENCE: And so from an SEO point of view, the thing that obviously I really don't understand is that the [INAUDIBLE] has no back links, but the dot-com gets switched out. So I'm wondering if the X-Default gets changed. Does the power to the [INAUDIBLE] UK get affected by that? It's a very difficult question for me to even structure, but I hope you understand what I'm talking about.

JOHN MUELLER: I don't know for sure. I don't know how that would work out. It's tricky because I imagine most of the signals are pointing at your main site, and it would be kind of fighting with the signal that you give us and say, well, actually my main site is this one. But I could totally see this as something you might want to try out on individual pages just to see how it works out. And I'd love to hear your feedback on what you find out.

AUDIENCE: Yeah, I'll either be applying for a new job or I hope it will go well. But yeah, thanks, John.

JOHN MUELLER: All right. Let's go through these questions, because there are lots of them there, and people submitted them. So, "my very non-spammy design news website seems to have been negatively impacted by the Google algorithm Payday Loans. I'm baffled as to why and what we can do. Any ideas?" If it's not a Payday Loan website, then it probably wasn't affected by the Payday Loans update, because that would be something completely different. I don't really see anything specific with your site just [INAUDIBLE] now. I think, to a large part, it's probably just ranking as it normally would. But I can double check after the Hangout and see if there's something specific I can add. "In our business, we rent rooms in the same apartment. Each room has a separate page. Also, they have different photos per page. Except the same title and reference, most copy of the original is the same. Do I need to set one of the rooms as canonical?" You don't need to set them as canonical. It probably wouldn't even make sense to set them as canonical. It would be essentially like having an image gallery and picking the first image as the canonical. You'd probably want to have all these pages indexed separately. So from that point of view, I'd probably aim to have them indexed separately. Maybe you can embed the images all on one page, if that makes sense. But essentially, you don't need to set one page as a canonical for something like an image gallery. "You stated last year that Penguin [INAUDIBLE] should work on fixing link profiles. Wait for refresh. It's highly possible no refresh is coming. Do you still stand by fixing as the best way to resolve?" We are working on a Penguin update, so I think that saying there's no refresh coming would be false. I don't have any specific timeline as to when this happened. Barry asked me jokingly if it was happening today. And no, it's not happening today. But I know the team is working on this and trying to find a solution that generally refreshes a little bit faster over the long run. It's not happening today, and we generally try not to give out too much of a timeline ahead of time, because sometimes things can still change.

AUDIENCE: So faster meaning that it's going to be on a regular basis, like Panda?

JOHN MUELLER: We'll see what we can do there. So that's something where we're trying to speed things up, because we see that this is a bit of a problem. When webmasters want to fix their problems, they actually go and fix these issues. But our algorithms don't reflect that in a reasonable time, so that's something where it makes sense to try to improve the speed of our algorithms overall. And some of you have seen this firsthand. Others have worked with, probably, other webmasters that have this problem. And I think this is something good to be working on there.

AUDIENCE: But the impact won't be as big, right? Like before?

JOHN MUELLER: That's always hard to say. And I imagine the impact also depends on your website and whether or not it's affected or not. So if it's your website, the impact is always big, right? But it's something-- we're trying to find the right balance there to make sure that we're doing the right things. But sometimes it doesn't go as quickly as we'd all like.

AUDIENCE: Thank you.

JOHN MUELLER: "Is it bad to have links pointing to your site that are from websites hit by Panda, Penguin, or a site with a manual penalty?" No, not necessarily. So it's not that we'd look at the site and say, oh, this is a bad site. Any link from it is also going to bring some badness to the site that's being linked to. But rather, if this is an actual link, then that's fine. If it's not a natural link, that's not so helpful. There are some situations where we see sites that are linking out to all kinds of sites, and we might say, well, we can't really trust any of the links on the site, so we're just going to ignore the links out from this website. But that doesn't have a negative effect on your website. So if you're being linked to by a site that you suspect Google is ignoring, then we're just not passing any page rank through that link, and it's not negatively affecting your site. It's not having a positive effect, either.

AUDIENCE: John?

JOHN MUELLER: I can't hear you, Joshua. [INAUDIBLE]

AUDIENCE: All right. There, how's that?

JOHN MUELLER: Oh, it's perfect. Great.

AUDIENCE: These sites that aren't passing authority with page rank-- can we have any idea about-- is that a small percentage or a really big scale? I mean, in 20%, 30% or more, or are we just talking about a relatively small number of sites that don't pass on the authority? Because that seems to be like a long term thing.

AUDIENCE: It's something really, I'd say, fairly rare in the sense that if we see that your site has unnatural links from the site, we'll also bring that up in Webmaster Tools and use that as a manual action in Webmaster Tools so that you're aware of the situation. But it's not something where I'd say a large part of the internet is affected and essentially held back. It's really only for rare situations where we see that a large part of the links from the site are actually unnatural links. Therefore we want to be careful with any links that are coming out of this website, just to make sure that we're on the safe side. They're not causing any problems with the search results.

AUDIENCE: All right, thanks.

AUDIENCE: Hey John, will you always give the manual action for these kinds of sites?

JOHN MUELLER: I think so, yes. So this is something we do manually. It's not something where algorithmically the algorithm would just silently go in and say, we're ignoring everything from this website. So since it's a manual action, we bring that up in Webmaster Tools for this website and we'd let the webmaster know about that as well. There might be some extremely rare situations where something similar happens on our logarithmic side or where maybe there's some manual action that we need to take that we can't directly show through the webmaster, but for the largest part, I'm not aware of any exceptions at the moment. So this is something that we would try to always show to the webmaster. "I'm running a price comparisons site. In July, we got a ranking drop to the category and product pages, but the blog section is still ranking well. So my question is, why is the blog section ranking so well and the other sections not?" I guess it depends a bit on the type of content that we find there and how we can differentiate between the content. And if you're running a price comparison site, and you're just taking feeds from various distributors or sites and essentially just comparing them, then that's not that much value add, and that might be something our algorithms look down upon. So if you're not really providing something significant, unique, and compelling of your own, then it's possible that we won't rank your site as high as it used to in the past. And in the blog, maybe you're writing better articles there, and maybe that looks like something that we prefer to show in the search results. So maybe the ranking will be just the same. But overall, this is something-- especially what price comparison sites or generally affiliate based sites that you'd want to watch out for and make sure that you're really not just combining these feeds and showing that one to one on your site. You're actually doing something unique and compelling of your own on these sites. What makes sense for us to send visitors to your site, because you have more information about these individual products, for example, then maybe even the main website itself. So that's something where you really need to make sure that you're doing a little bit more than just combining feeds and pushing them out onto the web. "If I change my site to HTTPS and use a 301 redirect, do I also need to upload the disavow file from the HTTP site?" I'd definitely also upload the disavow file in cases like that. If you're moving from HTTP to HTTPS, or if you're moving into a different domain, all of these situations I'd definitely make sure you're uploading the same disavow file so that we can take that into account just the same.

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

JOHN MUELLER: Sure.

AUDIENCE: I have a big doubt about some domains I want to buy, so I want to ask you some technical things. Supposing I'm buying some premium domain names from a company who has something like 500, 600 premium domain names listed online-- also in the same web directory, same content, same design, same outgoing links-- basically, is the same web directory published in all of these premium domain names to keep them online and live, OK? So my big problem is, is possible, or better, what is the probability that all these sites connected between them with links to be penalized already by Google for duplicate content or maybe by Penguin? Because they are all connected between them.

JOHN MUELLER: So we wouldn't do [INAUDIBLE] penalize it for duplicate content. We try to treat that as a technical issue, and we might show only one of these pages in search. But we wouldn't penalize the site for duplicate content. In general, if there's a manual action in place, you can fix that by having a good website on that domain and doing a reconsideration request. It's important that there's something on that website, not just like an empty domain name and you say, I want to reconsider this website and I'll put something new up as soon as I have an OK from the manual actions team. We really want to see that there's actually content there first. Otherwise it might look like you're just jumping back and forth with the same content. So we really need to see some legitimate content if there's a manual action. Algorithmically, it's a little bit trickier in the sense that sometimes these domains collect a lot of shady history. And that can take a little bit of time to shake off again. So if you switch to something that's really legitimate, that's a great website, it can still take while for algorithms to get rid of all of this bad, old history and understand your new site the way it is now. So that's something to keep in mind where I definitely look at things like archive.org to see what kind of content was on there before. If it's a really blackout site that was on there before, you see all these blackout links pointing to the domain name, then chances are those algorithms might still be affected a little bit for a while. So if you need that domain name as quickly as possible, you need to have something visible in search. Maybe choose something that has a little bit of [INAUDIBLE] in our history. If these were just directories and they have no other history past that-- maybe the just have links between each other and no spammy backlinks-- then that's something that you can probably just put your new website on and work from that.

AUDIENCE: OK, so even if they link between them, it should not the problem if they are new site, new domain names?

JOHN MUELLER: I can't say that for sure, but in general, if they don't have a really spammy history with spammy backlinks, then I wouldn't be that worried about it. We can't give you this information ahead of time, so it's something-- you have to look into the history yourself and use your own judgment into saying, it was just a part site. There was nothing special about it. Or it was actually this crazy blackout site that I don't want to be involved in. I don't want to have to worry about the history about.

AUDIENCE: OK. Thank you very much.

JOHN MUELLER: "Can I get a manual action for great content, hyperlinks?" Wait. "Can I get a manual action for great content hyperlinks pointing back at us that are keyword anchorage?" So if someone else is scraping your content and linking to your website, in general that wouldn't be a problem. That wouldn't be something I'd worry about. You wouldn't get manual action for that. That's almost for sure, because the website team manually has to look at these sites. And if this other site is just scraping your content, then that's not something that we would say is going to be your problem. That's more something where we'd say, technically, we try to filter that out. If you want to take action on your side, you could look at things like a DMCA, which might apply, which might help you to clean that up. But that isn't something where the manual web server team would take action on your site for someone scraping your site. "We have indicated we prefer the dot-dot-dot version of our site in Webmaster Tools. Should we upload the disavow to both versions?" In general, we apply that to the current canonical version. So if your website has always been on dot-dot-dot, that's the one I'd definitely keep the disavow file on. If you're switching between these versions, I'd definitely upload it to both versions just to make sure you're covering everything. "This week I saw an updated site link search box. I don't understand the mechanism. Can you explain it?" So this is a specific markup you could put on your pages where if we show a search box in the site links section of the search results-- which we don't always do for all sites-- but if we show that for your site for specific queries, any searches that user is doing there will be sent to your site to your site's internal search page. So for example, if you have a Wordpress blog, and you have search set up, and you have the search box on your website, you add the markup to your website. If a user in the search results searches for something specific within your website, we will redirect them directly to your website to the appropriate search page within your website. So that makes it a little bit easier for you to try to fine tune your internal search results that you would show the users and also to track how users are clicking through into these search results pages. And this is a fairly simple markup you can add to your pages. If you don't have side links shown for your pages, maybe it's not worth the effort at the moment. But especially if people are seeing side links to your site, that might be something that provides a little bit of extra value. "How is waiting determined in the priority--" Oh, oops. It disappeared. I think the question was about the ranking in the priority from the crawl errors. We use, I think, four or five factors there for the crawl errors priority. We have them in a blog post where we initially announced this feature, which was probably four or five years back now in the meantime. But it includes things like, is this a page that's linked internally? Is it included in the site map file? Those kind of things. And if we can tell that this is a more important page, we'll show it a little bit higher in the crawl errors section so that you see that at first glance, and you can take action on that. If all the problem here as you see in the crawl errors section are completely random URLs that you think are totally irrelevant to your website, then that means we haven't found anything that's really useful on your website that's currently returning a crawl error, which is usually a good sign. "Is there a negative SEO effect when using a website builder like Squarespace? I'm located in the Netherlands and target Dutch customers. Squarespace web servers are located in the VS." I don't know which country that is. But, "What's the best choice SEO-wise when using Squarespace?" Oh, probably United States. So in general, we do take the server location into account but only as a very, very lower priority factor for geo targeting. So if you have a country code top level domain like a .nl, .de, or you set the location in Webmaster Tools, and we'll definitely use that. And if we don't have any information at all about geo targeting for your website, we might take the server's location into account. So if this is a good place for you to host your website, go for that. That's not something I'd hold you back. That's not something that would have any kind of negative effect with geo targeting.

AUDIENCE: John, when do domains-- like I got an invite to get the domains from you guys, and so, when is it going to be available in Canada?

JOHN MUELLER: I don't know. You'd have to ask the domains folks, but I imagine their answer's also-- it kind of depends on-- I don't know what factors they're waiting for. But I know they'd love to expand on that, but they need to make sure that the base product is working really well first and taking things step by step.

AUDIENCE: Sounds good.

AUDIENCE: Yeah, John, what is the deal with all this stuff coming out in the US and not for Canada? I find that unethical.

JOHN MUELLER: Unethical. [INTERPOSING VOICES] I don't know, you guys set up those borders. I don't know why you have two states. It's one continent, right?

AUDIENCE: Justin Bieber--

JOHN MUELLER: Seen you guys just get along, you know?

AUDIENCE: The US sneezes, we get a cold, you know?

JOHN MUELLER: I don't know. I mean, in Europe, it's generally even later than Canada. So I'm sympathetic, but I can't really solve that problem for you guys, sorry.

AUDIENCE: It's all right. Thanks.

JOHN MUELLER: "Does Google use the size of watermarks in image ranking? Do images with smaller watermarks rank in image search better?" We do try to take the quality of the image into account for image search rankings. But usually if there's a reasonable watermark on it, that's not going to be a problem. If the watermark covers the whole image, then of course that's something that changes the image from being a picture about something to just being the watermark. But if you have a reasonable watermark on there, that's not going to be a problem. So you don't need make it tiny, you don't need to hide it completely, you don't need to remove it. Just make sure that the image is still kind of the image that it's supposed to be. All right, we have a couple minutes left, so let me just open it up for you guys. What's on your mind? I see the chat is clicking away like crazy. What can I help you guys with?

AUDIENCE: Can I--

AUDIENCE: Oh, sorry, go ahead.

AUDIENCE: Excuse me. Do you hear me, John?

JOHN MUELLER: Yes.

AUDIENCE: So returning to my problem I asked before, if I buy a domain name who has 500, 600 low quality backlinks already on it, is that a problem?

JOHN MUELLER: It might be that these are links that are picked up by the Penguin algorithm and where you'd need to wait for a refresh. If you're aware of those spammy backlinks, I'd definitely at least do a disavow for them what you get that site. But it's not something where I can guarantee that it'll go either way. If you know that it has this kind of a spammy history, you have to work with that and, I guess, take your chances if you really, really want is that domain name. Or if you want to really play it safe, you can say, I don't have time to mess with any bad history. Maybe choose a different domain name. It depends a little bit on how far you want to go, how much information and knowledge you have about handling these issues, how far you want to fix this on your own, or how far you just want to have something that's as easy as possible and is just like a new website from the beginning.

AUDIENCE: You're saying it's not the best choice I can have?

JOHN MUELLER: Well, I think if you're very experienced, if you know about these issues, if you can find all of these problematic backlinks, and if you say, I don't need this website to rank from the first day, then maybe it's worthwhile. Maybe it's a really, really good domain name that you might miss out on otherwise. So that's the two sides of the equation that you have to think about, whereas if this is just some random domain name that you don't really care about and you know it has a bad history, then it's probably not worth the time and effort to fix that up.

AUDIENCE: John, can I ask you a recommendation? Would you recommend a dedicated server as opposed to a shared server? I know it's not like [INAUDIBLE].

JOHN MUELLER: It's whatever works best for you. I guess it depends on the website, how much resources you need, but you don't need to have a dedicated server. You don't have to worry about things like on a shared server in general, so that's not something where I'd say you should go either way. It depends on your website and your needs.

AUDIENCE: Right, right. Because I heard that there's a-- if your neighbor on a shared server does something crazy-- because I talked to this famous hosting company there, they were saying that hey, you can get penalized if a neighbor does something crazy and you were right next door.

JOHN MUELLER: It's more of a problem for us if the whole server is spammy and you're the only clean site on there. Then from a manual web spam point of view, it might happen that the website team says, oh, well, I found 50,000 domain names on the server. They're all completely spammy. We're going to take action on this whole server. But if you have a normal shared hosting environment, the host is going to take care of those sites well. And they're going to have some kind of terms of service where they say, oh, well, if you're just spamming people, then we're going to throw you out of our system. And they kind of police this a little bit. Then there are going to be some spammers that get through, and a lot of normal sites that are on the same server. So in those kind of situations, that's not something I'd worry about. It's more, I guess, if you're buying your shared hosting from a known blackout that is hosting all their blackout domains on the same server. It just wants to add some variety into the mix. Then that's probably not going to be a good use of your time, of your money. But if you're posting with a normal provider, like, I don't know, Go Daddy or any of those other ones, then those shared servers are going to work just as well as other ones.

AUDIENCE: Thank you.

AUDIENCE: John, just a quick one. For probably the last three or four months, I brought up a particular website that is probably the only spam result left in the results for my industry. And nothing's been done about it by anybody. And I presume by this point that either Google or you agree with them, or we've got the usual delay that we've seen for many, many years of nothing being sorted out for it. And now they're ranking number one for almost everything instead of employing the same link building techniques. Should I open up a webmaster thread about it? What should be done about it? But it's bad for customers, and it looks and reflect badly on the Google results. And the fact that I'm bringing it directly to you multiple times, and you either don't agree with it all passed it on to somebody else, also just goes to show that we're still not getting around the issue of people like me helping to solve spam issues.

JOHN MUELLER: Yeah, I'll double check with the analysts there to see what they came up with. I don't really know, exactly, what the final situation was there, but I can double check there to see if there's something I can bring back to you.

AUDIENCE: I posted the URL in the chat there, just in case you needed a reminder.

JOHN MUELLER: Okay, great.

AUDIENCE: Thanks, John.

JOHN MUELLER: OK, and with that, we're out of time. So thank you all for all of your time for the good questions, for the good feedback, and I wish you guys a great week.

AUDIENCE: Thanks, John. Have a great week.

JOHN MUELLER: Bye, everyone.

AUDIENCE: Thanks, John. Bye. Thanks.
ReconsiderationRequests.net | Copyright 2018