Reconsideration Requests
18/Dec/2018
 
Show Video

Google+ Hangouts - Office Hours - 05 May 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.

Q1: When disavowing a domain, does that mean that we only need to wait for Googlebot to re-crawl the homepage of that domain to take the reclassification into account or will it also need to re-crawl the | Show Video

A: Yes, Google needs to re-crawl those individual pages where those links are on. Using the domain operative just makes it easier so that you do not need to specify what pages those bad links are on.

My Thoughts: A common myth was that once the homepage of a domain was re-crawled that all links from that domain were disavowed. This is confirmed as not being true. Each page must be crawled so that each link can be disavowed.

Q2: If I disavow a domain does that also disavow all sub-domains? | Show Video

A: Yes, so if you disavow blogspot.com you have disavowed every blog from blogspot.com

My Thoughts: Very powerful if you don\\\'t know what your doing.

Transcript Of The Office Hours Hangout
Click on any line of text to go to that point in the video


JOHN MUELLER: OK. Welcome, everyone to today's Google Webmaster Central Office Hours Hangout. I'm John Mueller. I'm Webmaster Trends Analyst here at Google in Switzerland. I basically talk with webmasters like you guys and help to make sure that things are working smoothly for you. We have a bunch of questions in the Q&A already. If you want, you can add more questions as well, or for one of the future Hangouts. But to get started, do any of you guys have any questions?

BARUCH LABUNSKI: In regards to press releases, I see a guy with the same website doing press releases every single, like, 12 hours. And it's the same title, over and over again. What is the limit to how much you can do? What you can do?

JOHN MUELLER: With a lot of these things we don't have any hard limits, where we'd say you can do five of these every day, or five of this type of thing. Essentially, what we try to do is to make it so that if you're creating content, that you're creating it in a reasonable way, and that it's unique and compelling content. If you, essentially, just take the same content and copy it over and over again, that's not really going to be that useful for us, or for users. So that's something where you might want to take a look and see what you could do to improve that.

BARUCH LABUNSKI: OK, well, let's say-- top three cars, top three cars, top three cars. And, it's like every time-- top three cars.

JOHN MUELLER: Yeah, that sounds a bit excessive, almost. But it's something where the press release website, or the website that's aggravating this kind of content, should probably take a better look at the content they're actually publishing. And maybe find a way to make sure that their content overall is really of the highest quality possible. The big problem from our side is, essentially, when our algorithms look at this website and they see all of this low quality stuff. And they essentially don't really know where to categorize this website. Is this a website that has primarily low quality stuff, has primarily good stuff, or some mixture? How much should we trust this content? So if this site keeps publishing these kind of low quality, duplicated press releases, then that's something that the algorithms will generally pick up on over time.

BARUCH LABUNSKI: Oh, I see. OK. So I would agree, the editorial team must be more strict on that. I keep on seeing this for the past nine months-- same thing over, like top three, top three. And they change the title a little bit. The content would not be duplicated, but the content just doesn't make sense. Do you know what I mean?

JOHN MUELLER: OK. Kind of like spun content? Those kinds of things?

BARUCH LABUNSKI: Yeah. But it's the same thing over. And it's the same companies. It's the top three. And it keeps on mentioning this model, and tha model, and this model. You know what I mean? So--

JOHN MUELLER: Yeah. I do, and--

BARUCH LABUNSKI: You know, it's just the top three, the top--

JOHN MUELLER: Kind of repetitive, huh?

BARUCH LABUNSKI: Yeah.

JOHN MUELLER: It kind of depends a bit on how excessive this is. In the sense that sometimes our manual website team would take steps there, as well. But if this is just like a few copies of this content, and overall, these sites are prime, then that's probably something we wouldn't take any manual action on. That's something where we'd say, our algorithms should be picking up on this over time.

BARUCH LABUNSKI: [INAUDIBLE] examples, John. And you can have a look.

JOHN MUELLER: OK. Great. Take a look at that. All right. Let's take a look at some of the questions from the Q and A. When disavowing a domain, does that mean we only need to wait for Googlebot to recrawl the home page of that domain to take the reclassification into account? Or will it also be to recrawl the page with a bad do follow link on it? Essentially, we need to recrawl the individual pages where those links are on. So using a domain directive makes it a lot easier, in that you don't have to specify the individual pages. But we still have to recrawl those pages. And then when we recrawl them, we take those links out. So, yes we do still need to wait to recall those individual pages. My site has been hit by Penguin. And it partially recovered a little bit with every new Penguin update. There still seems to be a light anchor that is holding my site back in ranking. Is this how Penguin recovery works? It's hard to say without looking at the specific website. But it could be that what you're seeing is that things are kind of picking up. So if you see that your site is becoming more visible again, then that's something that could be the normal part of the Penguin recovery here. In that maybe there are still small parts of our algorithms that aren't completely happy with everything. But overall, things are looking up again. So that's generally good. One of you guys has a bit of noise in the background. Let me just mute you. OK. That was you, [INAUDIBLE]. If you want to speak, feel free to unmute yourself, and ask away. Is this true? Posting the same content to various multiple distribution sites [INAUDIBLE]. The penalty only occurs when one or more website publishes the same content repeatedly across its pages. Google objects to having many pages on one website. I don't know if this goes into what you were talking about before, Baruch. But generally speaking, having many pages on one website is fine. Having many pages that are kind of similar on one website is also fine. It can be a normal part of a website, depending on where this duplication is coming from. If it's, for example, just like a technical duplication, that you have URL parameters, those kinds of things. With regards to duplicating content across a number of sites, usually that's pretty easy for us to pick up on, and not something where there'd be any kind of a manual action. Because our algorithms usually would pick up on those things automatically. I don't know-- are you here, Vince? I see you're muted.

MALE SPEAKER: Yes, I'm here.

JOHN MUELLER: OK. Do you want to elaborate on your question?

MALE SPEAKER: Actually, the reason I ask this is because there's an ongoing debate. So what I was trying to explain to a friend of mine that the-- what do they call this-- the duplicating content would actually hurt their ranking if they used the same content and were just propogated through different distribution sites. But according to his argument, it doesn't hurt it. That's why I ask you the question. Is it through-- So basically, what they are doing is just using the same content in article directory sites.

JOHN MUELLER: OK. Yeah. So, essentially, if you're just taking your content and you're sending-- hitting it across a large number of websites, what you're doing is diluting your content, in the sense that some people might be linking to your pages. Other people are likely to want these article websites, or one of these other distribution sites. And essentially, all of that dilutes the value of your content. And what can happen is, for example, that one of these other sites starts ranking for your content, instead of your website. And that's probably not what you're trying to do. What you're trying to do is bring attention to your website, and make sure that people come to your website. Because you have high quality content. Because you're an authority in this kind of area. And that's something that, if you just distribute your content randomly across the web, you're showing this content isn't really that valuable-- I just want to spread it out as widely as possible. It's not something that I want to have directly associated with my website, but indirectly use it as advertising. And sometimes it can make sense to bring the word out about your website, about your content. But if you're just taking your content that you worked hard on, and spreading it across all of these different sites, then you're diluting the value. There are not so many people that are going to go directly to your website for this content, because it's already all over the web. So from that point of view, it's something where you could use this as a way to advertise your website, if these are nofollow leads, for example. But you probably want to keep the high quality content on your website, so that people actually go to your website. And not just some random article website that, perhaps, isn't even really known for the type of content that you're providing.

BARUCH LABUNSKI: Because that's not what Google is about. At the end of the day, you've got to serve the user, right?

JOHN MUELLER: Yeah. From our point of view, we want to recognize that your website is built up on high quality, unique, and compelling content. And if your website only contains content that's already available on thousands of article directories, then it's going to be hard for us to say, this is a great website, we should promote it in search. Because we don't know. Because this content is all over the place. Whereas, if this high quality content is on your website, and people are going and linking to your website for this high quality content, then that's something that builds up value over time. And that's something where you will definitely see some kind of a positive effect over time. So from that point of view, I'd really recommend not just randomly spreading your content across these other websites. But rather, building your website up to be really an authority in that area, and your website actually having this important content. Does that help answer the question? OK.

MALE SPEAKER: Yes.

JOHN MUELLER: All right. One of our sites has been hit by negative SEO recently, with lots of pingback and blog comments. However, most of them are nofollow already. A few of them are dofollow. Do we need to disavow the domains which have dofollow links? Technically speaking, we pick up on these kind of things automatically. But if you've been noticing that already by yourself-- and you want to be absolutely sure that they don't really cause any problems-- then I'd just put them in the disavow file with the domain directive. And then you don't have to worry about this anymore.

BARUCH LABUNSKI: Can I just add to that?

JOHN MUELLER: Sure.

BARUCH LABUNSKI: What I did in this case-- and I suggest all webmasters do-- is, I had a client, where he was hit over 100 times. OK? I went to each and every site to find out who that person is. And I had that removed. Right? It got to the point where I contacted that person, and they apologized to me for doing what they did. And not only that, they went ahead and removed all this mumbo jumbo to pretty much the entire site. So the entire site-- what they did, was they just copied all the links to this site and put it on the entire website. And it was just out of control. And that person apologized, and has removed it. So that's what our job should be. You know?

JOHN MUELLER: Yes.

BARUCH LABUNSKI: You can do the short way, but at the same time, no need to touch that disavow, certain times. You can just go ahead and just work a little harder, and have that kind of stuff removed.

JOHN MUELLER: Yeah. If you can do it like that, that's definitely a good thing to do. Really, removing this content is always a little bit better than a disavow, probably because it's really cleaned up.

BARUCH LABUNSKI: For sure. Yeah, that's the last resort. But in terms of blog comments, they remove the blog comments as well. And so, yeah.

JOHN MUELLER: Wow. You have the magic touch.

BARUCH LABUNSKI: Yes.

JOHN MUELLER: Yeah. All right. Would it be possible for the structured data view to show multi-type entity as a single data type? Currently, all types of a multi-type entity are shown as separate types, which is quite cumbersome when checking the type sound. I can pass that back on to the Webmaster Tools scene to see if we can simplify that a little bit. I wasn't really aware that this was so much of a problem, but I can take a look at that. We're seeing links from search pages, especially a site called m.biz. There are approximately 100 of these domains, which is the exact replica of the site. We have disavowed m.biz, but do we need to disavow all similar ones? Usually, we can recognize these kinds of duplication. But again, if you want to be absolutely sure that they're not counted, and you already have this list of domains, then adding them to the disavowed file is generally easy to do. Maybe, like Baruch mentioned, another alternative is to try to see if you can find the main source and have it removed there directly, so that it's also removed from all of the individual ones. That might be a little bit better. But essentially, if you know of these domains and you don't want those links to be counted at all, then putting them in the disavow file is a good way to at least to make sure that they're not used by our algorithms. When will Google start sending a referrer from when searching from IE8? Matt said two or three weeks, though it's been almost two months. I don't know. I can double check with the guys there about that. Good point. I manage sites for individual US real estate agents, who syndicate property listings through Zillow and Trulia. They are outranked by customers the ones even when searching for these listings. Will rel="canonical" help signal Google that the agents are an authoritative listing source? Yes, if you can get a rel="canonical" set up on those sites. And that might be a possibility. The other thing to keep in mind is that, even though some of these sites are copies, doesn't mean that it's something that users don't want to find in the search results. So it's similar if you have, for example, affiliates who are also selling your products. Sometimes, they might do a better job of actually selling your products than you do. And users might want to find their site in the search results directly. So that's something where you might want to see what's actually happening there. And think about whether or not it makes sense to force them to put the rel="canonical" on there, to encourage search engines to go back to your site, and show that in the search results. Or maybe this is even a situation where you say, OK, they're bringing traffic to my site. They're selling our products. What more do we really want from them? So maybe that's OK. But essentially, you have to work together with these other sites and think about what your final goal should be. Is that that your website should be the only one showing these in search results? And if so, using a rel="canonical", or having them use a no-index might be a good idea. If you just want to get the word out about your products and services, then maybe having this content on the other sites, as well, is fine. And not something that you'd need to manually hold back. Can we ever expect there to be a queried entity view, with DataBot structured data types more or less the same, like search queries view, which always shows entities, as opposed to keywords? That sounds tricky. I don't know-- are you here, in the Hangout? [INAUDIBLE] I'd love to hear more about what you're thinking about there. So if you're watching this, or if you have time, maybe, for one of the next Hangouts, it would be interesting to have you come on and maybe show something more. Or explain it a little bit better, what you're actually looking for there. That sounds pretty interesting. I don't know if it's something we could easily add to our Master Tools. But it sounds like something maybe worth looking at. Will Webmaster Tools ever show whether or not your house search results are shown? For example, is rich snippet [INAUDIBLE] Knowledge Graph, and what the clickthrough rate was. I don't think that would be happening any time soon because there's so many factors that go into exactly how we show the search results. So it's not something where we'd say you can easily tweak your website to appear in the Knowledge Graph. And then your clickthrough rate will be higher. We try to do this as algorithmically as possible. So I don't think we'd be including that kind of information any time soon. That said, I wouldn't count it out completely. Because we do show some of this information, for example, for authorship. So maybe that could be coming. I think you just joined, is that right?

MALE SPEAKER: Hi, John. I just joined. Yeah. .

JOHN MUELLER: Perfect. Can you elaborate on your idea with--

MALE SPEAKER: One of the things I'm struggling with is showing my clients the return of investment of investing in structured data. And of course, things like showing clickthrough rates help. But at this moment, there's no way to prove to my clients whether or not it's cost. Because they change anything to their content, whether they made any in structured data changes. And in real life I encounter a lot of situations where clients don't want to invest in structured data because it's so hard to show any form of return of investment.

JOHN MUELLER: Yeah. That's a good point. I don't know. It's tricky, because there's so many factors also, on our side, which are kind of involved there. On the one hand, we try to use this to really understand the page a little bit better, which indirectly could slightly be affecting rankings. Maybe not strongly, but a little bit, of course. And sometimes we bubble this information up as rich snippets in the search results, if we can recognize that it's a high quality site, if we can recognize that the structured data was implemented correctly, and technically, and policy-wise. So that's something where you might see that, where you might see, perhaps, higher clickthrough rate as well. But we don't have a direct way of showing that in Webmaster Tools at the moment. So maybe that's something we could look at there.

MALE SPEAKER: That would be nice to have things to show return of investment. Because at this moment it's really troublesome.

JOHN MUELLER: Yeah. I think one thing I'd recommend doing at the moment, if you're working with clients like that, is to focus primarily on structured data that you can actually see in the search results. Which would be things that we would use for rich snippets. And not just markup everything that you find, for example, in schema.org, where you can markup almost every entity on a page. Because a lot of that markup are things that we're probably going to be ignoring for a while now. And it's going to be a while before we actually show that directly in search results. Whereas if you're using the markup for things like product, with the prices and availability, review ratings, those kind of things. And that's all markup that's much more likely to be shown in the search results, that will have a nice snippet in the search results. Where, at least, when you look at the search results, you'll see, oh, this is a change compared to previously. And with regards to clickthrough rate, that's always a bit tricky, but I imagine you'll see, at least some changes, when it becomes visible. But we can see if we can maybe bring a little bit more of that information into WebMaster tools as well.

MALE SPEAKER: It would be nice because that would really help me in convincing people to invest more in structured data.

JOHN MUELLER: Right. When will the next Penguin refresh happen?

BARUCH LABUNSKI: There you go. So that's a very good question.

JOHN MUELLER: We tend not to pre-announce these, so I am sure you'll see when the next one happens. It's been a while since the last one, so I wouldn't be surprised if one happens soon. But I don't have any other information that I could share with you guys at the moment.

BARUCH LABUNSKI: But it's on a yearly basis, though, right? It's on a yearly basis, like--

JOHN MUELLER: The last ones, I believe, were like [INAUDIBLE] half year or something. Barry probably has the records. Yeah.

BARUCH LABUNSKI: May 20th, 21st, right? Or around there?

JOHN MUELLER: I thought it was September, or something in the fall. I don't know.

MALE SPEAKER: October the 3rd.

JOHN MUELLER: OK. Yeah. I've got to go to Barry's site to check it out. 50 days past relocation. Traffic and ranks haven't moved. Even for keywords where we ranked number one for 14 years, our rank is low. Any time frame, after which the effects kick in? I'd have to take a look at the individual threads in the website to see what exactly is happening there. I think one thing to keep in mind is that some of these manual actions also coincide with, perhaps, algorithmic changes on our side. So maybe you saw the manual action for one issue and you cleaned that up, and the manual actions revoked. And now our algorithms are reviewing your site like they normally would, based on the normal crawling indexing algorithms that we have. And maybe this manual action was just a small part there. So maybe you're seeing a small change from the manual action. But the bigger issue is actually that our algorithms picked up on this bigger issue with regards to the website. And maybe that's something that is still being processed. Maybe you fixed the right issues and essentially it just takes time to recrawl, reindex, and reprocess all of this information. Or maybe you fixed one issue from the manual action, but not actually the one for the algorithmic problems. And in general, what I'd recommend there, is to check in Webmaster Help Forum, or one of the other Webmaster Forums. And get input from the experienced webmasters who've gone through this process before, who might be able to point out things that you missed. And maybe you've done that already. Maybe the thread that you're linking to is something in our forums. So depending on what all happened there, what issues you had there, it might be just a matter of waiting until those are actually reprocessed and cleaned up. And in the meantime, of course, this doesn't mean that your website is always going to remain in this place while we reprocess this information. You can continue working on your website, and you can continue seeing the results of those improvements over time, as well. So if one algorithm pushes your site down a bit, that doesn't mean that you have to wait for that algorithm to be reprocessed. You can work on everything else on your website, as well, during that time to get things bubbling up again. So my recommendation there would be, get more advice from other webmasters. And in the meantime, don't just wait it out, but actually continue working on your website. What's the difference between a 301 and a 303 redirect, past the technical part in from the agorithmic part? Is it different from the 307 redirect? Well, that's kind of complicated. Let me-- So essentially, what we do on our site is primarily differentiate between permanent and temporary area redirects. And we try to combine all of the other type of redirects into either, is this a permanent redirect? Or is this something that's kind of temporary? And to some extent, if we see these redirects happening consistently over time, then we'll probably tend to treat them automatically in a special way. So 303 redirect is a See Other redirect. I'm not sure. I imagine we treat this as a temporary redirect. So from our point of view, that's something-- let's see-- I wouldn't necessarily focus so much on the specific type there, than the specific details of how these redirects are actually handled. Usually, what happens here, with these kind of redirects, is we have to make a decision on whether or not to index the redirecting page, or the redirection target. And if we see a redirect consistently happening from one URL to the other one, then that starts looking like a permanent redirect to us. And that starts looking like something where we really have to make a call between picking up either the redirecting page or the redirection target. So in some of those cases we take into account other signals as well, like which URL seems to be the more popular one? Or which URL seems to be the nicer one to show in a search? So if your home page, for example, is redirecting to some really long, complicated URL within your website, then we'll probably pick the home page to show the search results, even if you're using a permanent redirect from that page to that long and complicated URL.

BARUCH LABUNSKI: So suppose I sell a shoe, and then that shoe is out of stock. I would 307 it, because it's temporary, right? And then I can bring it back.

JOHN MUELLER: You can do that. Yeah. So if you have a replacement product, and you're saying, this is a replacement for this product in the meantime. You could use a 307. Let's see-- what's a 307-- temporary reader. That's something we'd pretty much treat as a temporary redirect, like a 302. So you could use a 302 or a 307, and redirect to the alternative product in the meantime. You could take that back after some time. If we see that this redirect is happening for a longer period of time, then we'll probably treat that as a 301 internally, even if you're serving it to us as a 302 or 307. Because if we see that this URL always leads to this alternate product that you're sending to, then we have to assume that actually this isn't something that's going to disappear tomorrow. This is probably the permanent state.

BARUCH LABUNSKI: So, the 301, and that's it.

JOHN MUELLER: Yeah. From that point of view, it's something we'll definitely recrawl that redirecting URL, from time to time. And if we don't see a redirect, we'll pick that up again. So it's kind of similar to a 301 or a 302. And in that regard, it's not something where you really have to make this complicated technical decision, with regards to, oh, should I 302 or 301 there? That's the kind of situation where you'll probably just go with the 301, and leave it like that. The main difference for us with a 302 and a 301 is actually on the user side, in the sense that some of these redirects aren't cached and others are cached And if, for example, your website is behind the proxy for some ISP, and one user sees a redirect to one page, then the next user, if that's a cache redirect type, will see the same redirect as well. So for example, if you have a page that redirects based on the user's language setting, and that redirect is cached on the ISP side. Then if one user gets a German version, then the next user is going to get the German version, even if they have an English browser, for example. So that's the kind of situation where you'd want to make sure you're using the technically correct redirect time-- one that isn't cached. Like a 302, for example. But if you're just moving things around on your website, then I'd probably just go with a 301 and leave it like that. So I guess, in a long and complicated answer-- And again, from my part, I wouldn't worry so much about the search side of things there. But really, think about which one is cached and which one isn't cached. And then take the one that matches the behavior that you're trying to achieve.

MALE SPEAKER: John, I have a question.

JOHN MUELLER: OK.

MALE SPEAKER: So I wanted to ask this in the context of back and forth about me being hit by a Penguin algorithm. And this person's-- happens to push out privately five new websites a day for clients. Not for themselves, but they do a lot of it. They're a huge company and they do a lot web design. On almost all of them, they have a [INAUDIBLE] that says web design by, company name. No link. Not really key rich anchor text, like newer web development, it's just the name of the company dot com the link. And it's a mass amount of sites. Do you recommend they don't follow those things?

BARUCH LABUNSKI: I asked them about that. Yeah.

MALE SPEAKER: Usually, most web development design companies do only a couple a month, a few a month. Not, like, five to ten a day.

BARUCH LABUNSKI: Like, powered by--

JOHN MUELLER: Yeah. So, especially if it's not something like a keyword for rich anchor, where you're saying web design, just like as a footer link, or something like that. Then generally that's less of a problem for us if it's a keyword rich anchor. Then that's something where, maybe, the website team would take a look at that and say, this looks like they're just trying to manipulate the search results. It's not something that the client can choose to do. Then the other part, also from the website team's point of view, is whether or not this is something about that the website owners, or the person who's receiving this website, has a say in it or not. Are they consciously linking to this other website? Or is it something that's essentially forced on them? Maybe a part of the package, in the sense that you'll get this website cheaper, but you have to include this link on the bottom. And at that point, it starts looking a little bit more iffy, and something where you'd definitely want to put a nofollow on there. And if you want to put your advertising on these other websites and encourage people to go to your website, then that's fine. But that's something you'd have to put the nofollow on for.

MALE SPEAKER: So Google wouldn't necessarily know if it's part of a package, unless it's explicitly written? If a site like this was doing five or ten a day, and I don't know if it was or not. But from a Googler's perspective, a person sitting in your shoes-- maybe you don't do manual actions, but somebody else on your team might, or somebody around the corner from you might. If they saw this, would they assume it was part of the package, and ask me to go follow?

BARUCH LABUNSKI: Over time, for their experience, I would say, yes-- right?

JOHN MUELLER: It kind of depends on the overall picture. And if they're doing five to ten of these websites a day, then it probably gets a little bit trickier, and something where they'd want to look into the details a little bit more. It's probably something where they wouldn't just say, oh, I see 500 links, so this is good, or this is bad. They'd probably look at the details actually try to figure out what exactly is happening there. And whether or not this is causing any problems on our side. So that's something where just glancing at it, you probably wouldn't be able to make a call. But looking at the bigger picture and seeing how this is working within those websites, within the website that's actually providing those websites-- probably is something worth doing there. But from a webmaster point of view, what is probably the easiest thing to do there, is to just say, OK, I'll put a nofollow on those links, and say I'm using this as a way of advertising my services. I'm putting out a lot of websites. These are high quality websites. I can vouch for them. I want my name on them. And I'm happy to see this as a way of advertising my services. And in that view, just having a nofollow on there is generally fine. And I don't think you'd see a big problem in search if you went with the nofollow in a case like that. It'd be interesting to look at the exact example. And I'm happy to check with one of the website teams, to look at that. If you want to give me that, that's fine. I'll try to make sure that they don't just push the red button on it when they see it. But it might be interesting to look at that, so I can give you a more exact answer next time.

BARUCH LABUNSKI: That's OK, to have an anchor text like ABC in Toronto SEO, ABC, SEO? Or is it just-- even with a nofollow I mean, like--

JOHN MUELLER: Even if you put the nofollow on, you can use whatever you want. It's essentially an advertisement for us, right? So we're not going to count it within our links. And so, if you put a nofollow on there, you can use whatever anchor text you want. You can use an image, or whatever you want to do.

MALE SPEAKER: [INAUDIBLE]

JOHN MUELLER: I didn't quite get that. So branded anchors or--

MALE SPEAKER: Yes, let's say you have many [INAUDIBLE] and your website not from the manual [INAUDIBLE]

JOHN MUELLER: Normally, we'd work on recognizing that and treating it appropriately. It's something-- if this is your brand and it's your company name, it's your website name. If someone is searching for that, your website will already be ranking for that. So it's probably not something you absolutely need to have these branded anchors for. So from that point of view, it's not something you absolutely need. But it's something that our algorithms can also work on treating appropriately, so that they don't cost. The other issues there. So I wouldn't necessarily worry about but primarily. Unless of course your brand is something like you were one key or two key, or three. And you're saying, this is my brand name, but actually, it's just a collection of keywords. It's not really a brand by itself. All right. Do internal backlinks affect Penguin? For example, if a commercial anchor text is used internally to link to other internal pages, is this how it can affect Penguin? That's not something that we'd use for our algorithms when it comes to webspan issues. Because essentially, within your website, you're just shuffling the page rank around a little bit within your website. You're not artificially gaining what that page rank them. So from that point of view, that's generally fine. The only thing I'd watch out for there, is that you're not overdoing it with internal links, in the sense that when you look at this page it looks just like keyword stuffing. So sometimes we see that on websites where they have content on top and then they have a section on the bottom, which is just like 100 different keywords that are linking to internal pages, various parts of your own website. And from our point of view, that starts looking a lot like keyword stuffing. And that's something where our algorithms will try to step in and say, OK, these pages are clearly keyboard stuff. They have a lot of keywords on them that aren't relevant for the primary content on these pages. So we have to think about what we can do about these pages. So it's not so much the problem with the links between those internal pages. But rather that you're just using the same keyword rich anchors all over your website, which makes it really hard for us to recognize what those pages are actually about. If I disavow a domain, for example, apples.com, does that mean that all subdomains like-- dot, dot, dot-- apples.com are also disavowed? Yes. That does mean that. So, for example, if you disavowed blogspot.com, and then you've disavowed pretty much all the blogs that are hosted on blogspot.com that are indexed as blogspot.com. So that's something where you'd probably want to watch out for making sure you're disavowing the right thing. A lot of times you'll want to disavow all of the subdomains. So if apples.com is a bad website, or one that you don't want to be associated with, then maybe you'll want to disavow all of their subdomains as well, at the same time. And if you want to disavow individual subdomains, I'd just do that on a more granular level on your end, and use a domain director with the subdomain. What if my page links to the same page internally from different anchor tags more than 100 times because of dynamic page templates, and just using a pound sign of the URL? For example, if you see the ABC slash/ pound, will this give the wrong signal to Google about the relevancy of the page, probably? Essentially, you can do that. This is kind of similar to the previous question. You can put a lot of internal links on your pages. What will probably be more visible for us, or actually the anchor text, like the text we see on the page themselves. So not so much that you're linking all of these pages, but when we look at them, we just see all of this text as well. So that's essentially fine. With regards to the number sign in the URL, that's something where we generally crawl and index the primary URL without the number sign there. So we'll probably automatically canonicalize that to the main path with the file name, instead of adding the number sign at the end.

MALE SPEAKER: John, another question about structured data.

JOHN MUELLER: Sure.

MALE SPEAKER: You said earlier that even though schema.org offers a lot of entities, we don't use that many. Personally, I'm quite involved at the discussion group at the [INAUDIBLE], with regard to schema.org. And there we are working our butts off to get as many things fixed and added to schema.org as possible. What, on average, is the adoption rate of Google and the schema.org types that edit it?

JOHN MUELLER: It's hard to say. We also have people working with schema.org directly to make sure that we can get that working as well as possible. But one of the big difficulties from our side is that webmasters generally want to see some kind of effect on their side, or in the search results, like you mentioned as well. And there's only a limited amount of room that we have in the search results where we can bring more of the structured data into view. So that's something for individual search results. I imagine it's going to remain fairly limited between the--

MALE SPEAKER: [INAUDIBLE] The rich snippets. The visual light on.

JOHN MUELLER: Yeah, exactly. So that's probably going to remain a bit limited because we just don't have that much room. And I know that the people working on user experience, they always come to us and say, oh, you shouldn't put so much fancy stuff in the search results. It should be as clean as possible, so that people can find information they need. With regards to using some of this, for example, in the sidebars, or with other interactions, that's something where I imagine it'll be more possible to bring in more things in there, kind of like we did with the events. In that you search for a musical artist and it will show the events in the sidebar of the Knowledge Graph and link to those pages like that. So I imagine we'll see more there. But even there it's kind of limited, in the sense that we can't bring everything from all websites directly into the search results. So I doubt you'd see a big jump in adoption, where we'd go from-- I don't know-- the seven types of rich snippets to the 100 types of schema.org entities, and we suddenly support for Knowledge Graph. But it's always-- also a problem, it's like the chicken and the egg, in the sense that if no websites are using this kind of markup, then we're not going to invest any time to actually show that in search results and use it for rankings and understanding these pages better.

MALE SPEAKER: So about the rich snippets, just what I imagine is that, even though you don't have any visuals for it, it still helps in regards to people understanding your website and disambiguiate the subjects of your website, and in that sense can help them understand and return your website for those relevant.

JOHN MUELLER: Yeah, a little bit. It certainly helps in that regard. Usually the bigger effect that I see when a site goes to implement structured data is that their website overall just becomes-- gets a very clean structure. In the sense that maybe it used to be almost like a Word file that was exported as HTML, and has all kinds of messy markup that's really hard to understand. And suddenly, when you implement structured data, you have to use a strong and a strict structure on those pages. And that by itself makes it a lot easier for our algorithms to understand those pages better. So theoretically, even if you didn't add all the structured data markup, if you significantly clean up those pages, make it a lot easier for us to actually pick up this content and understand it-- understand the context of the images and things like that, that are embedded there-- then that already helps quite a bit. But I can see where you're coming from, in the sense that there's so many different types of entities out there. And it would be great to know that they're being used for something useful at the moment. So I am definitely going to continue working with the structured data guys to make sure that we can at least bubble up a little bit more information there. Maybe Webmaster Tools or somewhere else.

MALE SPEAKER: Or maybe do a Hangout together with Dan [INAUDIBLE]. That would be nice.

JOHN MUELLER: Yeah. Yeah, definitely.

MALE SPEAKER: John, now that we know that Google+ is going under, what's going to happen with the authorship, in terms of that?

JOHN MUELLER: Come on. Google+ isn't going away.

MALE SPEAKER: It what if it cuts off, right in between, right away--like right now?

BARUCH LABUNSKI: We'll let you know.

JOHN MUELLER: I mean, as long as I do these Hangouts, it means that Google+ is still up, right? I mean [INAUDIBLE] was definitely a very important person for the team. But there are lots of really smart engineers and managers on the Google+ team, so I don't see them packing their bags and going off and-- I don't know-- building something completely different. So I think Google+ for us is a very important platform, and a lot of other things build up on Google+. So it's not going to disappear from one day to the next.

BARUCH LABUNSKI: All right. I won't be able to use my background in this and that, you know.

MALE SPEAKER: John, you saw the schema action stuff?

JOHN MUELLER: I briefly looked at that. I didn't see it in detail.

MALE SPEAKER: OK. Then forget it. I'm looking forward to seeing more on what Google supports now, what they're working to support-- the schema and markup. That'd be very exciting.

JOHN MUELLER: Yeah. I think there's a lot of stuff happening with structured data, so it's interesting. All right. We're running kind of low on time. Do any of you guys have more questions?

BARUCH LABUNSKI: [INAUDIBLE]

MALE SPEAKER: I always have questions. [INAUDIBLE]

JOHN MUELLER: Go ahead.

MALE SPEAKER: Here's one. There's no such thing as a dofollow tag, right? So just do follow instead of no following their links Is that , like, a red flag? Is that what you'd tell people not to do?

JOHN MUELLER: We basically just ignore that. You can put, like, rel="pumpkkin" in a link, and it doesn't make any sense for us. So we'll just ignore that. We'll just treat it as a normal link. But if we see a rel=nofollow"pumpkin" then we'll see, oh, it says nofollow. And we'll treat it as a nofollow.

MALE SPEAKER: That way any Googler out there trying to find code to find spamming links that have dofollow in it. Don't have much It's like is somebody specifically link there, saying, please Google, do follow this external link to some other website.

JOHN MUELLER: There are a lot of signals of people doing something spammy. And there are a lot of signals of people just not knowing exactly what they're doing. But I wouldn't say that every time someone doesn't know what they're doing, they're being spammy. So from that point of view, I wouldn't necessarily treat that as a pure spam signal. We have other, things like the meta tags, like the robots meta tags, where they'll say, I want Googlebot to index this page and follow all the links. And essentially, we do that by default, right? Or the meta tag-- what is it-- revisit after. I don't think any search engine is used ever, but it's still very common. Lots of people put it on their pages and say, oh, I want my home page revisited every day, and this page every five days. And that's something you could say, they don't really know what they're doing. But I don't think it makes sense to penalize them for anything like that. So similarly, with, like, a dofollow tag on a link, if you want to put that there for yourself, fine. We're going to ignore it. It's not going to cause any problems, it's not going to have any advantage, it's just random text there. And we have to deal with broken and invalid HTML all the time. So it's not something that I think our algorithms would get hung up on, or we'd even spend any time manually looking at those kind things.

MALE SPEAKER: Two is, you said I think, either this morning or a couple days ago is that, do not use the in what access rules the--what's it called the feature to remove a site for HTTPS because that will remove the HTTP version as well. I Does the same apply when you use a robots.txt file for blocking HTTPS version?

JOHN MUELLER: So the site remover request is a bit special because that's in Webmaster Tools. And essentially we assume you mean that you want this content removed completely. So we remove HTTP and HTTPS versions of the site. And if you're trying use this for canonicalization, then of course you just removed everything and there's nothing to canonicalize anymore. But the good news there is at least you can click the cancel button and it'll be back to normal pretty soon. Robots.txt is different in the sense that it is separate per host name and per protocol. So theoretically, you could have a separate robots.txt for HTTPS that has different crawling restrictions initiative users. So you could block crawling on HTTPS, if that's what you wanted to do, and allow crawling on all HTTP URLs. If you want to do that, that's fine. It's up to you. Usually you wouldn't use a robots.txt for canonicalization, though. So if someone, for example, were to link to the HTTPS version of your site, then by having it all roboted out, that link would essentially go to a page that we don't know what it actually contains. So we might show that you're actually in search if it's blocked on robots.txt because we say, oh, lots of people are linking here. We can't crawl it, we don't know what it is. But it seems to be important, so we'll shorten the search. So the better thing there would be if you don't want your HTTPS site to be indexed, either turn it off completely, or use the redirect to the preferred version, or just put authentication on it. So, server site authentication so that we can't actually crawl those URLs at all.

MALE SPEAKER: OK. And finally, that SSL stuff going on last week-- any update on that?

JOHN MUELLER: Yeah, we're working on making those messages a little bit clearer, so that it's not quite as confusing as it was last week. I don't know how soon we'll be back with those messages, but we'll definitely send those out again. To some extent it's tricky, because it does point out an actual problem on these websites, even if nobody has been using the HTTPS version of the science. If you're providing it and users get a certificate error when they go there, that's the problem that's worth fixing, even if nobody else has been looking at those pages before. So from that point of view, it makes sense to send it out to a lot of these sites, because it's really an issue that's out there. But we probably have to make sure that we have the phrasing right, so that they don't all panic and wonder if their website is going to disappear tomorrow.

MALE SPEAKER: Also, the last question, just on record, do you think Google is immoral or unethical for penalizing or demoting websites?

BARUCH LABUNSKI: Barry.

MALE SPEAKER: I'm just joking. I'm good. OK. Thank you for your time.

JOHN MUELLER: All right. And with that, it looks like we're out of time. So thank you all for joining. And maybe we'll see you guys again in one of the future Hangouts. And until then, I wish you guys a great week. [INTERPOSING VOICES]
ReconsiderationRequests.net | Copyright 2018