Reconsideration Requests
21/Oct/2017
 
Show Video

Google+ Hangouts - Office Hours - 26 February 2016



Direct link to this YouTube Video »

Key Questions Below



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


JOHN MUELLER: OK, welcome, everyone, to today's Google Webmasters Central office hours hangout. My name is John Mueller. I'm the webmaster trends analyst here at Google in Switzerland. And part of what we do is talk with webmasters and publishers, like the ones here in the Hangout, and the ones that submitted lot of questions. As always, we have a chance for those who are kind of new to these Hangouts to ask questions, before we get started with the submitted ones. Is there anyone here who wants to go ahead and take a shot? No? OK, well, we'll still have room for more questions toward the end. So I'll just go through the questions that were submitted. I see one of them here has lots of different parts, which makes it kind of hard to read. It usually helps to keep things really short and to the point so that I can go through one of these questions and figure out what it's actually about. So let me see where this one starts. We have multiple brands, and they're on separate domains, and we want to move them to, I think, subdomains, but still, of course, rank number one, like everyone else. Is it a problem to go to subdomain or for us to be on separate domains? From my point of view, you can definitely move to subdomains. If that works better for you, go for it. That's not something where I'd say you'd be worse off on subdomains. We do try to understand the structure of these sites. So if you have one normal website spread out across a lot of subdomain, which we sometimes see if people have wild card subdomains set up, then we'll probably recognize that as one site. Whereas if we recognize that there are multiple sites using subdomains, we will recognize that as multiple sites. So it's not necessarily something that always goes one way or the other. Would it be possible to provide more query data in Search Console? Right now, a lot of queries slip through the cracks as only the top 1,000 queries are shown, or 999. So the 999 comes from one query being filtered, where essentially we don't have enough query information for that query. We don't know what we can really show there. So that's why some people have 1,000. Some people have 999. Theoretically, lots of things are possible. But as always, we have to balance the different things to work on when it comes to features like Search Console, Search Analytics. We have to understand is it worth putting more query data in here? Or would it be better to add a new feature for some other feature or to add something else really fancy that people have always wanted? So these are the kind of trade-offs we have to make. And I believe Zineb has been asking on Twitter for more information on what people will do with more data in Search Analytics. So I'd check out her Twitter account and give her feedback if there is something that you feel you would do differently, if you had this kind of data. Another option is, of course, to use the API and to try to automatically filter down more information so that you can get some of these queries that you might be missing. Another idea might be to separate your site into sections. If you have really logically distinct sections of your website that you want to look at separately, then it makes sense to just look at a subdirectory or a subdomain of your whole site. Cycling query results-- what order are they displayed in? This is pretty much no specific order. So it's not that you can pull out any kind of secret information by looking at the site query results. Usually you will have something like the home page as the first one, but that's not always the case. And that's not necessarily a sign of a problem if your home page isn't the first one for site query. So from our point of view, site query is an artificial query. It's not something where someone is specifically looking for anything specific. So the order, the relevance of the results there, isn't something where we'd say there is a well-defined order that we need to provide. We know HTML sitemaps can be useful for users, but is there any SEO value in them? If we're already doing XML sitemaps and submitting that to Search Console, any SEO value in HTML sitemaps? I don't know. Sometimes. Sometimes it can definitely make sense to have these kind of HTML sitemaps, which are essentially a mapping of your category and your detail pages, especially if we can't crawl a website normally otherwise. So if you have a really complicated navigation structure, maybe if you have pages that are almost connected just through search forms rather than a logical structure, then at least having one place where we understand the structure of the site, based on the links, that can really help us.

MALE SPEAKER: So if the owner doesn't want to add the site map in Search Console, so Googlebot will recognize the HTML sitemap and go from there?

JOHN MUELLER: Yeah. We use HTML sitemaps to understand the structure of the site to find the URLs. But there is obviously a lot more information in XML sitemaps, things like the change date, for example, that tell us that these pages actually changed, which, if you have a larger website, then letting us know that this section of your site or this specific detail page changed recently, it makes it a lot easier for us to crawl there and to actually update our index, based on that change. So that's something you wouldn't be able to do with an HTML sitemap. It's almost like an HTML sitemap could be comparable to a normal site's navigation. And if you already have a good site navigation, then you probably don't need an HTML site map for search engines, at least.

MALE SPEAKER: But Bot is still amazing at recognizing sites without the HTML page like sitemaps as well.

JOHN MUELLER: Sure, yeah. If you have a normal site structure, a normal navigation within your website, that's perfectly fine. We can find all of those pages. If you already have a website that you know is bad with the navigation, then an HTML sitemap can a help a little bit. But on the other hand, if you know that your website is bad with the navigation, then you might as well just fix that, too, to tackle the problem at the root. All right, it's a common rule to just use one h1 tag per page. Is it a problem for Google to use multiple h2, or h3, tags on a page? That's perfectly fine. That's definitely not a problem from our point of view. You could also, if you wanted to, have multiple h1 tags. And we'd probably be able to deal with that, as well. So that's something where the headings help us to better understand the structure of the page, the context of the text, and the images on the page. So if you can structure your page in a way that we can understand that this block belongs together and this block belongs together, then that helps us. And it's not necessarily the case that you have to limit yourself to one h1 or always have this clean structure of h1, h2, h3. Some pages just have h3 tags on there, and that helps us to understand the structure as well.

MALE SPEAKER: Yes, so, John?

JOHN MUELLER: Yes? Oh, you're muted.

MALE SPEAKER: Sorry, sorry. So John, it means keywords being in the heading tag or in simple content doesn't make any difference to search engine? The content should be good.

JOHN MUELLER: Well, obviously having some information what the sections of the page are about with the keywords, for example, that helps us. So it's not the case that you would want to just put an image in the heading and not tell us anything about what the section is about. On the other hand, just stuffing keywords in a heading doesn't really help that much either. Or marking up the whole page and saying the whole page is actually one big h1 tag and assuming that Google give this page more weight, that's not going to happen.

MALE SPEAKER: OK.

JOHN MUELLER: These are things that everyone has tried out, probably.

MALE SPEAKER: So call the classic SEO.

JOHN MUELLER: Yeah.

KREASON GOVENDER: I just have a follow-up question then, John.

JOHN MUELLER: OK.

KREASON GOVENDER: Does it matter at which point do you put the most important keywords? So should your most relevant keyword be on the h1 right at the top of the page, or can it be lower down on the page and have a less relevant [INAUDIBLE] higher up? Does it make a difference what order it's in on the page?

JOHN MUELLER: We essentially want to understand what this page is about. And the clearer you can make that for us, the easier it is for us to pick up and, of course also, the easier it is for users to understand that this is the page that they're actually looking for. So I would definitely not put the most important keywords or terms that you're trying to rate for somewhere way on the bottom in the footer in small font somewhere. But rather, make it really clear that this page is about this topic. And yo probably have that in the headings. You might have that in the title. You might have that in multiple places.

KREASON GOVENDER: OK, thanks, John.

MIHAI APERGHIS: By the way, I noticed that you can use anchors on the headings. And then you can link them. And Google will pick that up. So it will show them in the search results, under the results, under the result itself, under the metadescription, it will show the anchors that you marked up, or the headings.

JOHN MUELLER: Sometimes, yeah. Sometimes we do that.

MIHAI APERGHIS: And that can help with click-through rates. So that's really strong.

JOHN MUELLER: Yeah, if it's a longer page, and we can understand the structure properly, and you have these-- I don't know what they're called-- jump marks or anchors within the page, where you can go directly to a specific part of the page, sometimes we do show that as a type of almost like side links below the page. OK, here is a question about redirects. Everybody loves redirects, 301 or 302. We should change our opinion from time to time, just to throw people off. Or maybe not. Redirect chain-- a 302 to a 301 to a 200, or a 301 to a 200 directly-- which one passes the most link juice or page rank?

MALE SPEAKER: Page rank.

JOHN MUELLER: From our point of view, they essentially do the same thing. So you're forwarding users from one page to another. And depending on which of these pages we keep in the index, that'll be the one that collects all of these signals. So if we decide to index the destination page, then that one will be the one that collects the page rank and the other signals from that page. If we decide to index the redirecting page, then that will be the one that gets all of these. So it's not the case that a 302 kills any page rank or that you need to do a 301, and if you combine a 301 with a 302, then you get 50%. Essentially we try to pick out which of these URLs we want to keep indexed, nd that's the one that's going to get signals.

MIHAI APERGHIS: John, is it the case, though, with 302's that maybe you wait a bit more to be sure whether you should treat it as a 301?

JOHN MUELLER: Probably. So essentially, that's a hard question. That's a really hard problem, deciding which URL to actually keep indexed. So it's essentially the question of canonicalization. You have two URLs. There is some signals between those URLs that you know about. And the question is, which one of these should you show in the search results? Which one should be the canonical URL? And if you have a redirect, then that helps us to understand the situation a little bit better. With a 302, you're saying that the redirecting URL is the one that you prefer. And a 301, you're saying the destination one is the one that you prefer. So a 302 is like saying, well, this is one better. And a 301 would be saying that one is better. But we don't look at just the redirects. We look at other things as well. As if there's a canonical tag on this page, how the internal links within the website point at these pages, what you have in your sitemap file, external links as well, all of these things add up. And they say, well, overall, the signals point at this URL, or overall the signals point at that URL. So it's not so much a case that you leave a 302 in place for a while and then it magically turns into a 301. It's more the case that over time, these signals change. And if everyone starts linking to the destination page, but there's a 302 redirect, then probably we should be indexing the destination page instead, because that's the everyone is using. So it's really a hard problem, I'd say, with search engines to pick the right canonical URL, and this is something that we have teams that are still working on this. So it's not a solved problem, even though we've been at it for such a long time.

MIHAI APERGHIS: OK, so it's the case that the more signals you've had that confirm a certain scenario, the better are you at understanding whether you should treat it like this or that?

JOHN MUELLER: Exactly. That's why we say you should be consistent. Because if you have a redirect in place and you tell us a little bit that maybe you prefer this one but some of your site says, prefer the other one, then we're torn. And we don't really know. And it could go either way. But if you're really consistent, and say everything should point at this URL. I have internally all my links at this URL. There's a canonical setup clean. The redirects are clean. The sitemap is clean. Everything is pointing at this URL. Then we'll say, well, it's no question. The webmaster really, really wants this one. So we'll pick that one for the index instead.

MALE SPEAKER: Because AMP is live now, are you going to make that a ranking signal?

JOHN MUELLER: AMP. AMP a ranking signal--

MALE SPEAKER: Is that [INAUDIBLE]?

JOHN MUELLER: At the moment, it's not a ranking signal. So it's obviously one way to make really good mobile friendly pages. So that might be an option, where I've already seen some sites that have moved their whole website to the AMP format. And obviously, that's a mobile friendly setup. So that gets at mobile-friendly boost. But just AMP itself is not something that we have a ranking signal at the moment.

MALE SPEAKER: Like they also updated their plug-in in [INAUDIBLE]. So it's pretty easy.

JOHN MUELLER: Yeah. I even put it on my blog. Now I just need to generate some newsworthy content and hide all of those eight-year-old posts.

MALE SPEAKER: And put it in live on Google News.

JOHN MUELLER: I don't know if I could get it in Google News. I probably wouldn't pass the criteria. Like posting once every eight years is kind of-- I don't know not a perfect news source.

ROBB YOUNG: You could answer my question. That might be newsworthy.

JOHN MUELLER: Your question. Oh, your general question. I don't know. I don't know. Now it's getting tricky. Let's continue with the questions that were submitted. If I have a website-- page.com-- and the content in English, and I want to create the same in Spanish, is it better to create a separate page, like page.es, or include a translator on the original page, and redirect it to .com? So in general, for multilingual pages, we recommend making the language clear per URL. So you have one page in English, one page in Spanish. And the whole page is in Spanish, and the whole page is in English. And with that, it's a lot easier for us to recognize this is the English page, and we should redirect people to the English page. And we don't have this situation where the page is part English, part Spanish. And we don't really know which language this page should be ranking for. So from the general question here-- should I make separate URLs or to use the same URL-- I would definitely use separate URLs. You don't have to put it on a separate domain, though. When it comes to language, essentially you can use any unique URL, per language. That could be with a parameter at the end. That could be a separate subdirectory or a subdomain. But it doesn't have to provide any structural information for a specific language. When it comes to geotargeting for countries, there we do need to understand the structure of the site, and say, this whole part of the website is for that country. But for languages, you can use whatever structure you want. In Search Console, a website ranks position one for most keywords. We discovered these positions reflect the presence on the map above the organic results. But it there a way to see the organic listings rather than the map listings, in Search Console? I don't think we differentiate that within Search Console. So we would essentially look at the normal web search results that we'd show if you just go to Google and search for something. And if your site ranks in one of those blocks on top, which might be-- what is it called-- the featured snippet on top, or with a map entry, or in a news entry, or in the app carousel, then that's what we count as the ranking. So where the rest of your site ranks within the organic search results is not something that we take into account there. And specifically for Search Console, we use the average position of the top most result for your website. So if your website ranks number one, number seven, and number nine, for example, in one search results page, then we take that number one ranking and use that for Search Console. We wouldn't reflect the lower rankings of the other pages there. What you can do, however, is look at it on a per URL basis. And that does give you a little bit more information there. So for your home page, obviously, it will be tricky in this situation. Because your home page will be the one that's probably connected to your map entry. For other URLs, that we are also ranking in the search results, you can, however, see this specific URL is ranking in this position for these keywords. So that's one way to get more detailed information there. The important part here is also to keep in mind that when you're looking at it per query, we aggregate that across your site. Like I mentioned, the topmost result from your site we use that. And when you're looking at it per URL, we look at it per URL. So the numbers there won't necessarily add up completely.

ROBB YOUNG: And John, are they supposed to roughly agree from Analytics to Search Console? Because you remember the thing that Mihai and I both mentioned on Tuesday about our www dot appearing as one of the queries? In Analytics, over the last 90 days, that has something like 4,000 impressions. In Console, it has 400 impressions.

JOHN MUELLER: OK.

MALE SPEAKER: [INAUDIBLE].

JOHN MUELLER: Yeah. Usually I'd expect trends, at least, to line up, but--

ROBB YOUNG: I added that that in there to the chat as well, so you could see it again, so Mihai could grab it again. We're just trying to get to the bottom of whether someone is genuinely searching for that URL, or whether it's something they're just typing in and that somehow their browser or toolbar or something is triggering a search, and it's not-- like there's so many searches for a www dot and no clicks, that it's just weird.

JOHN MUELLER: Yeah, I don't know. I'll double check what you posted in chat afterwards.

ROBB YOUNG: But in general, they should roughly match where possible?

JOHN MUELLER: They won't be exactly the same, because of the way Search Console counts, and the way Analytics counts. [INAUDIBLE]. So you shouldn't need like 400 versus 4,000, that you mentioned.

ROBB YOUNG: Right. Yeah, there's a lot that are similar, just for the two named experience, say, one is 2,500. One is 5,000. They're way off. Now that's not to say that our is the best example to use for results that everyone else can pin their hopes on. But I'm assuming whatever problems we have, we could at least still measure the results accurately.

JOHN MUELLER: Yeah, yeah.

ROBB YOUNG: So as to know whether they're good or bad.

JOHN MUELLER: Yeah, exactly.

ROBB YOUNG: OK. Well, I've posted the image again.

JOHN MUELLER: I'll take a look at that again. OK. All right, if a project is, for example a sports event site with events, which naturally expire-- for example, a cricket match-- would you add the expires after a header tag and then set the response to 410 after the expiration time and date? Probably. If you're sure that these are URLs that wouldn't be relevant afterwards, then you can definitely use the expires after meta tag and use the 410 or the 400. 404 would work just as well to let us know that this is not relevant anymore and that we can drop it out of the search results. Of course, some types of events you might want to keep longer. So it's not necessarily something where I'd say any event that has already taken place should be deleted from the index. It really depends on the site itself. For some sites, it definitely makes sense to weed out all of the old stuff so that you can focus on the new ones. For other types of sites, maybe the old events are really the ones that provide value for your website. Does a site-wide internal link get treated any different from a footer site-wide link? And would the amount of page rank that's passed be less than having the link on, say, the best pages only? It's a tricky question, I guess. Within a normal website, I wouldn't worry about where you link to your pages. And essentially we try to figure out the structure of the site and understand how these pages belong together or what the context is of these individual links and how we can understand one page a little bit differently from the other page. If you're talking about linking from one site to another site, that sounds an awful lot like a natural links, where you're optimizing the position of the link to your site on someone else's site. And that's really something I'd recommend not going down the path of. So again, if this is just internal, within your website, do whatever makes sense for the users so that we can still find the link to that page, and we can try to understand the context. If you're placing links on other people's sites, then I'd try to avoid that. In 30,000 unique URLs on a site, if the average crawl rate is 5,000 per day by Google, is that a good or bad sign? That can be perfectly fine. So what's worth keeping in mind with the crawl rate of a website is we're not crawling random URLs from the website, like random 5,000 URLs or lining all the URLs up and going through those 5,000. We're crawling some pages a lot more frequently, and other pages a little bit less frequently. So within those 5,000, you'll probably have a lot of pages that get crawled maybe daily and a bunch of pages that get crawled maybe once a week, and then a bunch of other pages that might get crawled once a month or even less frequently. So it's a mix there. You can't say, well, 5,000 a day, 30,000 total, therefore it'll take-- I don't know-- six days for the whole website to be crawled. That's not how it works. But 5,000 a day for a website of that size seems like a good thing. Another thing maybe to keep in mind with the crawl rate is crawling more doesn't necessarily mean that your website will be seen as more relevant or rank higher. So there is no need to artificially push a higher crawl rate if we're already picking up all of the content that you're providing. Will AMP affect the search results? Should I start implementing it now or wait for a few more months and look forward to Google's further guidance as there are not many proper AMP plug-ins available yet. So there is an official AMP plug-in for WordPress available. I'd definitely take a look at that. It seems to be working fairly well. We do show AMP being kind of a news carousel in the search results, on mobile. So that's one place it's definitely visible. I suspect it'll become more visible over time. I know the AMP people are extremely fast and extremely passionate about improving the web. So that's not something that I'd expect to go away. Also, I expect other sites also to implement the kind of AMP furor. It's open source. Anyone can essentially implement it on their site. I think Twitter, and Pinterest, and maybe some others have said that they're looking into doing this as well. So it's not just for search. It's not just for news. It's something that maybe it makes sense to dig into a little bit more regardless of your website. And if you work with multiple websites, if you're consulting for them, if you're an SEO agency, I'd definitely understand how AMP works so that you can inform your clients a little bit better. And when they come to you and say should I be doing AMP? You can say, well, you should do it now. Or you should keep it in mind for later. Or at the moment, this doesn't seem to make sense with your specific website.

MALE SPEAKER: But what if the CDN is really strong, though? Because there are certain CDNs that have servers all around the world, one of them being a very popular one that everybody knows that starts with a C.

JOHN MUELLER: C? I don't know which one starts with a C. [?

MALE SPEAKER: CloudFlare. ?]

MALE SPEAKER: OK, you said it.

JOHN MUELLER: Well, it's fine to mention names as long as you're not calling them out.

MALE SPEAKER: [INAUDIBLE] your own club thinks so it doesn't--

JOHN MUELLER: Oh, yeah. The neat thing about AMP is that it's not just a CDN. It's actually a way of letting sites integrate your content directly so that your content gets a little bit more visibility.

MALE SPEAKER: So let's say if I'm searching from India, and my website is located in the UK, yeah, it's a bit faster. Because the actual library's located in India. So this way, it serves the user the library from the actual location, right?

JOHN MUELLER: Yeah. With AMP, it basically uses-- so within Google search results, it uses Google's cache for AMP pages. So you essentially have Google's infrastructure behind your website should it become really popular. And I think the interesting part with AMP is really the combination of all of these different factors in that by being able to understand your pages better by knowing that it is restricted to a very well-defined format, we can integrate those directly in the search results. And people can go, really quickly, to your pages, to your content within the search results. So that's something where, even if you have a really fast site now, if you already use a CDN, if you have a great mobile friendly version, then sometimes it does still make sense to create these AMP pages so that you can do more with your content as well.

MALE SPEAKER: So now [INAUDIBLE] should be like in the milli-milli-milliseconds.

JOHN MUELLER: Well, you could test the AMP pages with-- what is it-- webpagetest.org, to see how they work. I think the Google AMP cache URLs all have the same URL structure with the hosting in front and then the website URL afterwards. So that's something you could compare pages and see what happens. I think that might make an interesting blog post. I suspect the team is still going to be refining the whole setup there since it just got launched two days ago. So I wouldn't expect the current status to remain one-to-one in place forever. And if you find issues where there are really speed problems or where there's a big speed difference with the way that we host it and the way other people might host it, then that's definitely worth looking into on our side.

MALE SPEAKER: All right, sounds good.

JOHN MUELLER: Sounds like an interesting blog post to do to compare different website setups with the AMP pages.

MALE SPEAKER: What do you think-- [INTERPOSING VOICES]

MALE SPEAKER: I normally use a site like Pingdom. What do you think of that? Or do you trust more--

JOHN MUELLER: I don't know specifically what Pingdom does. But if you're just pinging the host, then that probably doesn't give you much insight on how it actually serves content.

MALE SPEAKER: No, they do website tests.

JOHN MUELLER: OK. Well, if they check like the whole web page, then sure. Why not? When are you going to add more business types to schema.org markup? Currently we have to use local business markup as opposed to tool rental, which is our business. So I think schema.org is a public organization that handles all of this markup. And I'd double check where they discuss proposals and make sure to get your proposal in there as well. And if there is something that you think makes sense for your specific business that would be valuable within schema.org, by all means go reach out to them and see how they pick up your proposal. We have rel=publisher tag on every page on our site. I've heard you don't use this anymore. Should we remove it? Does it cause any harm? I don't actually know if we still use that. Good question. It's essentially meant to link your Google+ page to your website. And I don't know what Google+ is doing with that specific markup. So from a web search point of view, that's not something we would use directly. Because it's more for the Google+ side. So from my point of view, you can do whatever you want with that. I am sure it won't cause any problems in web search, because we essentially don't use it for web search. Whether or not it's still important for the Google+ side is something you probably want to check up with them. Why, if we choose a 302 redirect for our home page with a different local version, sometimes the URL shown by Google is not the original URL but rather the local version instead? That can happen if we don't understand the relationship between the different URLs properly. So with the href flag markup, you can definitely let us know about that kind of collection of URLs, where what you would do is, say, the home page is an [? xdefault ?] file page, which means it is a default version that redirects based on the user's location. And the individual local versions would be indexed separately with their individual local href flag tags. So you'd have this cluster of the local URLs and the one [? xdefault ?] URL. And if you link those properly, with href flag tags, then that's something we should be able to understand and show a little bit better in the search results. Now, does every folder in a URL need to exist? And if it doesn't, will this impact the flow of SEO equity across a website, for example, slash hats, slash cats hats, and slash hats alone just returns a 404? So I don't know what kind of hats cats would wear. That seems problematic on its own. But from our point of view, URLs are just identifiers. We don't require that something that looks like a folder is actually treated like a folder. So if you have one URL that's really long, if the shorter version of that URL doesn't exist, then that's perfectly fine. That's not something that our systems would count against you. That's what happens on the web, in practice. And we have to deal with that, too.

ROBB YOUNG: John, so that reminds me about one of the arguments between a flat hierarchy versus a proper hierarchy, within the URL structure. And one of the arguments for a proper hierarchy is that if you consider one of those files the URL, say, the category page URL in this scenario with the hats, that's considered to be like a chapter of a book. And if you open that chapter, it's got loads of other things inside it. And therefore, that folder contains lots of content. So it's nice and important. Whereas, if you open it, and it's essentially empty, then it's not. But are you saying that's not the case? As a general resource, if you open something and that's full of lots of content and links or subfolders for other things, that looks like a genuine resource for content. But if you open it and it's empty, then anything underneath that is also essentially useless.

JOHN MUELLER: I don't think we do that. I think what we usually do is just look at the links within the website. And if there are no links to that specific subdirectory, then we probably wouldn't even look at it. So I think, in the past, when users were savvy enough to understand what a URL was, and to manually tweak the URL in the browser, that probably made a little bit more sense, in that they'd say, oh, I just want to look at all the hats, and then I'll change the URL and look at that. But nowadays, URLs aren't even that visible in browsers anymore. In mobile phones, you really have to work hard to even look at the URL. So it's not something that I think users would do. And I don't think it's something that search engines would do at all.

ROBB YOUNG: No, but users might expect to see a breadcrumb, that would mirror a URL structure somewhat.

JOHN MUELLER: I don't think a lot people would-- [INTERPOSING VOICES]

ROBB YOUNG: If you land on the cats hats page, you might think, oh, actually, I'll look up at all of the hats. And if you can't then--

JOHN MUELLER: But you could do that with normal breadcrumbs on the page, too. That's probably the easier way to handle that. I don't think a lot of people would navigate a site by URLs.

ROBB YOUNG: OK.

JOHN MUELLER: The one exception that I know of is the home page. So if your site's home page disappears, it goes 404, or it has a parking page that's just blocked from being accessible, then oftentimes we'll assume that the whole website actually is broken. So that's the one exception that I know of. But that's also the case where we're always linking to the home page, and you're explicitly telling us to look at this page. Whereas with a specific folder within a website, I don't think we'd even care. Even if you linked to that folder and it then turned out to be a 404, that's life. We're not going to say everything below that folder is broke.

ROBB YOUNG: OK.

JOHN MUELLER: All right, someone has a quick question to ask. I'll let you go ahead. Michael?

MICHAEL: You have to remember those keyboard shortcuts for unmuting-- [PHONE RINGS]

MICHAEL: Let me just cancel that.

JOHN MUELLER: Oh, no. Now he's frozen. That was probably the wrong button to press.

ROBB YOUNG: Michael did ask a question on the actual page, on the Hangout page.

JOHN MUELLER: OK.

ROBB YOUNG: It's on there if you want to--

JOHN MUELLER: Whoa, lots of questions. That's crazy.

ROBB YOUNG: I can paste it into the chat if it helps.

JOHN MUELLER: OK.

ROBB YOUNG: Here.

JOHN MUELLER: Let me take a look at the chat. Whoa, OK. We have a client that would like to register a number of domains for various languages. The website will presented in, rather than a 301, the primary domain slash language. We would like to mask the domains. However, are there any caveats to be aware of, for example, required canonical. The intention would be that the domain.es would redirect to domain.com/es, while the other domain would redirect to /co.uk, for example. From my point of view, you can definitely do that. So if you're moving from [? CCTOV ?] structure to a generic [INAUDIBLE] domain structure with subdirectories, you can definitely do that. I'd just make sure that you use geotargeting within Search Console for those individual subdirectories, so that we still have that that geotargeting information for them separately. I'd also expect that this is the kind of situation that's a little bit harder for us to process, because you're essentially combining different sites into one big site. And that means we have to recalculate all of the signals that we get for those individual pages and understand the new site structure instead. So this is not something where I'd say it's like a trivial domain move from one domain to another, but rather you're combining multiple sites, and we really have to re-understand everything first. So I would expect that you need to be a bit patient for things to really settle down there.

ROBB YOUNG: And it looks like they're talking about getting the country-level domain, just buying the domains and redirecting them to the dot com slash country.

JOHN MUELLER: OK, so basically--

ROBB YOUNG: If I read write it right. But then it looks like if that's the case, then none of the header tags would be read anyway. So none of the--

JOHN MUELLER: From my point of view, if you're using these for marketing purposes, like in offline ads or for other types of ads, you could just do whatever you want with that. That's not something that would really bother us because we'd focus on the URLs that actually have the content and use those instead.

ROBB YOUNG: But you wouldn't read any of the info, the tags, canonicals, because the 301 would kick in before.

JOHN MUELLER: Exactly, exactly. So we wouldn't take the country information from that URL, that's redirecting. We'd expect the country information to be on the URL that we actually index. All right, let me run through two or three more questions. And then we can open things up. Would the content within a blog post be used in rankings when that blog post is linked to an internal page-- I mean the rankings of the page it's being linked to? Essentially, we'd look at these pages on a per-page basis and use the content there. What we would take into account from a link is maybe the anchor text. So if within the link to another page you give us some context of that other page, then that's something we'd take into account. Does Google give added weight to blog posts which have a picture to ones which don't? And how descriptive should the file names be to help? No, I don't think we give added weight to web pages that have pictures, compared to pages which don't have pictures. Of course, if you have pictures, then that's something we could pick up for image search. But that's separate from the whole web search side. If the top three results in e-commerce have AMP pages, then how will search engines show them in search results? I know news websites, but what about e-commerce websites, which use Schema for e-commerce websites? So at the moment, we only show news content within the AMP carousel. So we wouldn't show your e-commerce landing pages there. But of course, an e-commerce site can also have a blog, can also have a news section. And that content could be shown within the AMP carousel. So that's something that might give you some ideas on what you could do there, too.

MALE SPEAKER: Actually, John, recently just you said that if other website also want, they can go for AMP.

JOHN MUELLER: Sure.

MALE SPEAKER: So I just wanted to understand if any e-commerce website goes for AMP and the top three or four results are AMP pages, so how Google has a plan to show them that these are the AMP pages?

JOHN MUELLER: I don't know. We'll see when we get there. I suspect there are lots of other types of content that will pick up first for AMP and show that in the search results. But I wouldn't be surprised if, over time, we also got to e-commerce content, and we're able to show a little bit better as AMP in the search results. But I'm not aware of any specific plans there.

MALE SPEAKER: But for now, it is good for news websites and all informative kind of websites, like blogs?

JOHN MUELLER: Yeah.

MALE SPEAKER: OK.

MIHAI APERGHIS: John, you mentioned if any web e-commerce website has a blog or a resources section or something like that, you could use AMP, true?

JOHN MUELLER: Sure, yeah.

MIHAI APERGHIS: So don't you need to be in Google News to be able to be shown?

JOHN MUELLER: No, it is purely for the web. Of course, some new sites are also in the Google News part as well. But any website can be shown in the AMP carousel. And that's similar to the previous In The News blog that we used to have on the search results, where any kind of newsy content could be shown there.

MIHAI APERGHIS: OK, good to know.

JOHN MUELLER: Now that Google has removed the right-hand PPC ads, any insight on what will be put in all the white space?

MALE SPEAKER: My commercials. My banners.

JOHN MUELLER: I suggested cat photos. But I don't think they took me seriously.

MALE SPEAKER: What about YouTube videos?

JOHN MUELLER: YouTube videos, well, sure. I don't know. So I don't know what the specific plans are there. I know it's always hard to figure out what the combination of the elements in the search results page should be. And I know that this is something that they work really hard on, doing experiments to try to figure out how it actually works out, what works out, how we can make sure that the search results stay relevant for users.

MALE SPEAKER: But this is the longest test you guys have done. Six years is a long time. You started in 2010. And it's not just overnight.

JOHN MUELLER: Well, things change. I'm happy when I see people do crazy experiments and crazy changes. Because that tells me that they're still passionate about this and still trying to figure out what the right combination is. And sometimes the right combination changes, over time, where we see users got used to this for a long time and worked really well. But actually, the web has moved on, or users have moved on. And now everyone is browsing the internet on their watch. And we have to figure out how to remain relevant there. It's just the same as all of you. It's not like your website works once, and you leave it alone for 20 years. You have to keep working on it to make sure that you don't lose touch with your user base.

MALE SPEAKER: Absolutely.

ROBB YOUNG: This also isn't a universal change, is it? There's right-hand side ads, still, for a lot of things.

JOHN MUELLER: I have no idea about--

MALE SPEAKER: No, it's gone pretty much for everything. But there's still some cache left. They said that they were tweaking that.

JOHN MUELLER: I have no idea what the ad side does. We try to separate that fairly well.

MALE SPEAKER: John, is there a ranking issue, if you have issues with JSON-LDs? Like if some JSON-LDs don't work on certain pages, [INAUDIBLE] a problem?

JOHN MUELLER: If you're using JSON-LD to provide structure data, then we wouldn't be able to pick up that structure data. So that aspect there-- and if that structure data was important your page, if we're using that for rich snippets, for example, that were visible in the search results, then obviously we wouldn't be able to show those rich snippets. But rich snippets aren't a ranking factor. So it would just affect how your site is shown in search, not in which position.

MALE SPEAKER: OK, thanks.

JOHN MUELLER: Let me just grab two more questions here maybe. Link rel=canonical to HTTPS page with colon 443. I guess it's a port thing. Is that bad for SEO, or is that fine? So 443 is the default port for HTTPS, which means we treat it as equivalent to the URL, without the port number. And it would be the same. So that's not necessarily a bad thing. From my point of view, it's probably cleaner without the port. It's less likely to make a mistake there. But it's not going to cause any problems. And similarly, for HTTP, the default port is 80. So if you have colon 80 at the end of the URL, then it's really the same thing as just without that colon 80. Did you change the way you read robots.txt and interpret the wild card and the disallow option? We didn't actually change this. I think we updated our documentation a while back, just to reflect what the current state was . It was like that for a long time, where essentially the change is that you have to have a slash as the first character. And after a disallow directive, if you were specifying a path in the robots.txt file, it can't start with an asterisk, or with a dot, or anything else. It needs to start with a slash. And we also added that to Search Console, to the Robots.txt Testing Tool, which is why some people are seeing this flagged in Search Console as well. And essentially we were trying to treat it the right way, anyway. But we want to flag that in Search Console so that people are aware that, theoretically, this is the wrong way to submit that line. OK, let's open it up for questions from you all. What else do we have left?

MALE SPEAKER: $350,000 sponsorship that you guys did for Let's Encrypt. But just forget the buying links and all that thing. No, honestly, this is without criticism. I just wanted to find out so you attend, let's say, a half a million dollar sponsorship event. And you didn't place that link. You guys never placed that link. And it's a natural thing. You guys are attending it. It's not done intentionally. Just oh, we got a link. So is that still against your guidelines? Because in your guidelines, if you read it, and let even a lawyer analyze that, you never placed that link. They just added you, because you're a part of the sponsors. They have a page that's dedicated to [INAUDIBLE]. So how is--

JOHN MUELLER: I'd say it's kind of a weird situation when you look at it from our side because people might assume that we were supporting Let's Encrypt, just [INAUDIBLE]. And that's definitely not the case. So essentially, what the webspam team does when they look at things like this is they try to understand the intent of these individual links, and they try to understand how important are they within the general site itself. Is this a very common thing? Or is this something that just happened to happen for a couple things? So if we see that overall, this website is well supported, naturally, externally, and there are some problematic links, then that's going to cause any problems from the webspam side. And that's the same for websites on our side as for any random other website externally. So if we see these kind of sponsorship links, and we can recognize that the intent isn't really to manipulate the search results, that's not something that's going to cause any problems. And I think, in some cases, what the webspam team might do is just say, OK, we will just discount these links in the back end and treat them like disavowed links so that they don't pass any page rank. But we understand that there is no harm meant here that's not with the intent to cause any problems. So we'll treat that fine. This is the same as if you're a local business, and you're active in local charities, or local events--

MALE SPEAKER: Right, exactly.

JOHN MUELLER: --then they're going to put links on their website. And you're not going to have any control over what's--

MALE SPEAKER: Yeah, you don't have any control of that because it's a part of the event. I mean, they just want to put you in the spotlight.

JOHN MUELLER: Yeah, these are things we have to deal with. This is like on the web we're not going to go out and penalize all of these local charities and say, oh, you let people buy these links and tackle it from that side because that would be the wrong approach. On the other hand, if we recognize that individual sites are going out and saying, oh, well, I can donate $5 this charity. And then I can get this linked with free casino poker, or whatever, to my website, and we see that this is all of the links from that website, then we might assume that actually these donations that they're doing are not just to support that charity, but maybe there's something more behind it. So we try to look into it from the context of the whole website and to understand what's actually happening there.

ROBB YOUNG: Are half million dollar paid links a big issue? Are there many of those out there?

JOHN MUELLER: I don't know. I'm really happy that we're supporting Let's Encrypt. And I noticed they changed the link to No Follow for us. So it's something where we try to hold ourselves to have a higher bar. But at the same time, looking at the overall picture, this wouldn't change the ranking of the Google Chrome home page anyway. So it's not something where I'd say the webspam team would be sent out and say, oh, you need to penalize this website for this one individual link here. Or maybe there are five. I don't know. I'm sure the Chrome team supports lots of other good causes as well. But that's something we do for any website. It's not the case that we treat our websites differently. If anything, we'd hold our websites up to a higher standard. All right, one last question before I have to run off.

MALE SPEAKER: Yeah, John. Can you confirm us if Google has taken any action against reviews in search schema, in search result page?

JOHN MUELLER: Reviews--

MALE SPEAKER: [INAUDIBLE].

JOHN MUELLER: Yeah, this has come up in a couple places, where people have asked and said oh, the review stars have been shown less frequently. And we double checked with the team on that, actually, just to make sure. Because usually, it's normal that the structured data mark-- the rich snippets come and go, depending on changes on our side. But they double checked. And they said there was actually a bug and it should be fixed. So it should be getting fixed soon, so that these will show up again, a little bit more visibly.

MALE SPEAKER: It's back. It's back.

JOHN MUELLER: It's back. OK. I'm never sure if that's a good thing or a bad thing.

MALE SPEAKER: It's a good thing.

JOHN MUELLER: But it's good to know that the turnaround time is pretty good.

MALE SPEAKER: Or your click-through rate.

JOHN MUELLER: All right, perfect. OK, so with that, let's take a break here. I will be joining the AMP Hangout later today as well if you want to join in there. That's with the Google project manager for the AMP team, which I'm sure will be interesting as well. All right, so otherwise, I wish you a great weekend. And maybe I'll see you again in one of the future Hangouts.

MALE SPEAKER: Thank you.

JOHN MUELLER: Bye, everyone.

MALE SPEAKER: Thank you. [INTERPOSING VOICES]
ReconsiderationRequests.net | Copyright 2017