JOHN MUELLER: OK, Welcome everyone to today's Google Webmaster Central office-hours Hangout. My name is John Mueller. I'm a webmaster trends analyst at Google in Switzerland. And part of what I do is talk with webmasters like you to help answer your questions and make sure that information flows both directions, as well. I have a bit of a cold today, so I don't know if we'll do the full hour. But we'll see how far we can go. Otherwise, you'll have to resort to asking me yes or no questions. I don't know if that works. We'll see. Do any of you want to get started?

MIHAI APERGHIS: I'll take a shot, since nobody else wants to. It is actually a pending question, since you said that you're not currently refreshing monthly or very regularily, but you plan to do that. Is it fair to say that there has been no refreshes of data of Penguin this year?

JOHN MUELLER: I don't know. It's possible. I don't know the specific dates. So I think that might be correct, but I can't confirm it 100%.

MIHAI APERGHIS: So on the next refresh, will you be able to announce it? Or might it just go?

JOHN MUELLER: I don't think we preannounce it. But if this is something bigger that happens that people have been waiting for, we will try to confirm it. That, definitely.

MIHAI APERGHIS: OK. Cool.

JOHN MUELLER: We have locations page with lots of locations. It loads with AJAX. How do we mark it up? I took a quick look at this page, and it looks really nice. But a lot of the JavaScript files are blocked by robots.txt. So we can't actually see any of the markup that you're generating there with AJAX. You can test that with Fetch as Google in Webmaster Tools, and you'll see which script files are blocked so that you can go through that individually and clean that up. Once we can crawl the page normally, we can render it normally. And then we can pick up the markup even if you're embedding it with JavaScript. What's the best route to go? TLD across countries, folders, or whatever? Which variation should I put my x-default tag on? Essentially, for geotargeting, for country language targeting, you can pick whichever option works best for you. So if you prefer to use a generic top level domain and folders, or subdomains, that's essentially up to you. That's whatever works best for you on your side. Your x-default is also up to you. So if you decide that you want the French version as the default, that would be fine. Hold on. I'm going to mute you.

MALE SPEAKER: Sorry John, can you repeat that again?

JOHN MUELLER: So the x-default is also up to you. If you want your French version as a default, that's fine. If you prefer your English version as the x-default, that's fine too. That's essentially however you want to be seen by people that you're not specifically targeting within your existing hreflang sets.

MALE SPEAKER: So the reason why our cost equation is because if it [INAUDIBLE], and com is our main type, basically--

JOHN MUELLER: Aw, man. I think you got muted somehow accidentally.

MALE SPEAKER: Hello?

JOHN MUELLER: Try again. Yes?

MALE SPEAKER: OK. What's going on?

JOHN MUELLER: Maybe ask again.

MALE SPEAKER: So the reason why I ask that question is because what if-- dot com is our main TLD, right? And would it be better then to have it indirectly, making com the main [INAUDIBLE], rather than having them across the 10 TLDs?

JOHN MUELLER: It's essentially up to you. You can use different TLDs if you prefer, or if there are legal reasons, maybe you need to do that. But essentially, it's up to you. And from a ranking point of view, we will treat these equivalently if we have the right geotargeting information for those individual versions. So that's not something where I'd say you need to use country code top level domains or you need to use generic with subdomains or with subdirectories. That's essentially whatever works best for you. Maybe there are legal reasons to go with one or the other. Maybe there are just practical reasons that you have a CMS that doesn't support different subdirectories. Maybe you'd want to put it on different subdomains or on different domains completely. But that's essentially however you want to handle it.

MALE SPEAKER: OK. And then obviously, doing it across these, one would then have to get hreflang implemented properly, right?

JOHN MUELLER: Yeah. Regardless of how you set it up, make sure that you have the hreflang set up between the different versions, even if it's on the same TLD. So hreflang works everywhere.

MALE SPEAKER: OK. Thanks.

JOHN MUELLER: Sure.

MIHAI APERGHIS: John, if I can do a small follow up. The reason a lot of webmasters are asking this and SEOs is because sometimes, we are afraid that using separate TLDs, separate domains might increase the work that they need to do to get some exposure to their domains so that Google ranks them better, rather than having subdomains and subfolders where everything is consolidated into a single domain. Would hreflang work somewhat like a command code? So Google sees all these different domains as part of the same entity, as the same website, and ranking signals once one domain might also influence the other domains since the hreflang kind of binds them together? Or is it not the case?

JOHN MUELLER: A little bit, but not like you would have with a rel canonical, because then we can really fold everything together. And we need to be careful that we don't run into this situation where one really strong company in one location, for example, suddenly ranks number one everywhere just because they're very strong in one location. So if you take a really big, let's say, American distributor, and they're really big in the US, because everyone goes there. Just because they open up a store in Italy doesn't mean that store in Italy is suddenly going to be number one in Italy just because they're number one in the US. So some amount of cross talk always happens there. But it's something we do try to look at on an individual basis. So it's not that the strength from one version automatically goes into the other one. The issue with separate TLDs or separate folders, I think, is something where you kind of have to think about how much content you actually have in those individual languages and different locations. So it's not something where I'd say you can create country-specific versions for all the countries out there. And Google will just rank it as local content automatically, because we do expect that this content is somehow specific to that area. So you have to balance between being able to target these individual countries and languages, but at the same time, holding yourself back from spamming and diluting your content across all of these different languages. So sometimes it makes sense to broaden that. Sometimes it makes sense to concentrate more and say, OK, I'll limit myself to two or three countries, and people outside of those countries will still be able to find my content. But I know that the content for these countries is really, really strong, because I've been able to focus my energy on it. I have great content that matches there. This is great stuff for ranking. So there's no automatic answer between splitting things up and concentrating. You have to look at what you have available, where you want to go, and what you want to do.

MIHAI APERGHIS: Right. I was mainly referring to if we did decide to split up between the few countries where it makes sense to, whether going separate TLDs and the separate subfolders by geolocating those subfolders or subdomains. Would it be the equivalent or because we're on the same domain with the subfolders and subdomains Google will-- or it would matter that there is a single domain rather than separate domains, multiple websites?

JOHN MUELLER: I suspect there might be some small factor involved there. But it's not something that I'd really worry about from a practical point of view. If you have strong preferences internally for one or the other variation, I'd just go with that. Like I said, I caution away from just splitting things up for the sake of splitting it up. But if you prefer TLDs, fine. If you prefer having everything on one domain, that's fine too.

MIHAI APERGHIS: OK. Cool.

MALE SPEAKER: Maybe I can give you some background, John. We actually had it all in one domain and added the countries with different languages into directories. Since we launched our new sight, we then moved to TLDs. And our traffic has dropped off for the past year. All the 301 redirects were done correctly page by page, not just on domain to domain or directly to domain. But I've been wondering over the past year. It's just dropping and dropping. It's actually not having a benefit to us.

JOHN MUELLER: Yeah. I would expect that that wouldn't be related to that. So anytime you make a move like that when you split up a site or you concentrate a site, you will see some fluctuations. It's not always smooth sailing, because we can't take all of the signals and just transfer them immediately like we could with a site move if you're splitting things up. But if you're looking at a period of over a half a year, then I suspect that these are just normal fluctuations, normal changes in the way that things are evolving in search around that market.

MALE SPEAKER: So you wouldn't suggest we go back to that, having it indirect again seeing as we moved it over a year ago.

JOHN MUELLER: I wouldn't go back just for that. I'd really think about what else might be happening there outside of just the SEO side of things? And that's where I'd focus and try to put more weight on that. I don't think switching something like that back will have any significant effect.

MALE SPEAKER: OK. Thank you.

JOHN MUELLER: How important is it to have a mobile site versus an app? We notice a lot of ecommerce sites these days are now moving to apps instead of a mobile site. How does Google treat these sites? This is always an interesting question. But I think on the one hand, we are able to understand how apps work more and more. Especially Android apps, we're able to use them for app indexing, which means we can crawl the app content, and we can tie that together with your web content, which might be desktop content. And we can show links directly to your app content in search instead of to your desktop pages, for example. And that can be a really good user experience. So if you're searching for specific blue shoes and you find your favorite distributor in there with an app deep-linked to their app, to their apps page, on blue shoes, then that can be a really good user experience. So that's something that could make a lot of sense. On the other hand, if you have apps, you need to keep in mind that they're very platform specific. If you make an Android app and you don't have an iPhone app, then users on an iPhone are not going to be that happy with just the desktop pages. So my recommendation would generally be to make sure that you always have a mobile-friendly website. And if you want to go a step further and also provide an app for your pages, then by all means, take that step, and go down that road. If you want to tie that into your website, I'd definitely take a look at the app indexing functionality. That's something I suspect will just gain more on prominence over years or over the near future. So that's something where if you're already working on an app, you already have a website, you can tie those in together. And that'll make them a little bit easier for us to show appropriately and search directly.

MALE SPEAKER: Hey, John? Can I ask a follow up question on mobile rankings?

JOHN MUELLER: Sure.

MALE SPEAKER: I know a couple of years ago, I tried to google if the response was better compared to an m.domain.com. But is it now the case that either of them can rank equally as well?

JOHN MUELLER: Yeah. So in our documentation, we have three different variations. The m dots are separate URLs, responsive sites, and also dynamic serving where you use the same URLs, and you just serve the content dynamically depending on the device. And all three of those, if they're implemented properly, are perfectly fine from our point of view. And that's something where I'd say you need to go to a responsive to get a ranking benefit. From our point of view, they're essentially equivalent. For users, they click on the result. They land on a mobile friendly page, and that's essentially what we're looking for. We're not looking for promoting any specific technology. It just should work well on a mobile device.

MALE SPEAKER: OK. Thanks.

JOHN MUELLER: One of my clients was hit by Panda after copying his old articles as LinkedIn. Is it possible to be hit even if your original article was posted on your blog before posting it to stronger websites? Can't use a canonical on LinkedIn. So in general, the Panda algorithm is a quality algorithm that we run which tries to promote higher quality content, which looks at a variety of factors around content quality around the content. So just by copying an individual article to another website and publishing it there, that's unlikely to upset our algorithms. That's something where in general, when we look at a website, we try to understand the quality of this website. And we look at everything around this website. So by copying one particle over to another site, that's not going to affect that. So my recommendation there would be to not worry so much about this specific thing that was happening there, but really to take a step back and look at the quality of the website overall and maybe find some people who aren't associated with your website who can give you a little bit more insight, as well about what might be happening there or how they feel about your website when they come to it for the first time, when they see it for the first time. How they navigate within the website, how trustworthy they feel this website is, if this is something that they'd give their credit card number out to. So these are the kind of things where you'd want to have someone give you really hard feedback about your website and things that you probably don't want to hear directly, because someone might be criticizing something that you've been working on for years. But I think a lot of times, it's really important to get this neutral feedback, even if it's harsh. Even if it means that you have to rethink your whole model. So from that point of view, I wouldn't focus so much about this individual article that got copied to LinkedIn, but rather, think about how your website interacts with users overall-- how they feel about it when they go there. And maybe do some user studies, maybe find some people who aren't associated with your website who can give you a little bit more help. We syndicate some of our products to third party websites. For example, affiliates, aggregator deal sites all link back to our site with rel nofollow. An SEO guru said this could give us a penalty, despite the nofollow. Is that true? That's not true. So if these links are there with a nofollow, then we drop them from our link graph. That's as simple as that. So it's not something that you'd have to worry about there. And links from those kind of sites with a nofollow is perfectly fine. They drive traffic to your website. They make it possible for people to go to your business to buy these things that you're offering. And that's perfectly fine. That's a good use of a nofollow. So from that point of view, that's absolutely not a problem. If I have a paginated list and change the default sort order but keep the same URL, does that matter? The tricky part here is we'll crawl it in one variation, and we'll look at that variation. So we can't see how you're changing the sort order for users. And if we can find all the individual items that are linked from there, then that's perfectly fine. If we can't find them unless someone does the right step of clicks and gets the right cookie, the right setting to actually get that collection of links, then that's more of a problem. But if this is something we can still crawl through, we can find all of your content, that's fine.

MALE SPEAKER: John? Can I step in with a follow up on this?

JOHN MUELLER: Sure.

MALE SPEAKER: How about the secondary, tertiary pages, and so on, so fourth? If those pages contain a noindex tag, you still see all the products, which maybe there can be thousands. Those specific pages have a noindex. How do you treat those products on those pages? They have noindex follow.

JOHN MUELLER: Yeah. So we follow the links. We crawl them. We don't index those pages. But we follow the links.

MALE SPEAKER: That means you won't index, even the products, of course?

JOHN MUELLER: Well, if it has the noindex, you're telling us not to index it.

MALE SPEAKER: Yeah. Then it makes sense that those pages have rel prev/next, have the pagination if they have no index?

JOHN MUELLER: If they are no indexed-- I don't think it really makes sense to do it like the rel previous and next, at least not for Google. But at the same time, we'd probably just ignore it there. So it's not that you would cause any problems. If you're using rel next and previous for other reasons, then maybe keep them there. But at least from Google's point of view, if we can't index them, then we can't take them as a collection of pages about this topic.

MALE SPEAKER: I understand. So if we drop the noindex, then the rel prev/next pagination would make perfect sense, right?

JOHN MUELLER: Yeah.

MALE SPEAKER: OK. Thank you very much.

MIHAI APERGHIS: By the way, John, would you recommend the rel prev/next tags over noindexing a page 2, 3, 4 of a category? Because a lot of CMSes kind of noindex these pages automatically. Even Wordpress and [INAUDIBLE] gives you this option [INAUDIBLE]. So would you recommend the rel prev/next and leaving the pages to index or rather just noindex them?

JOHN MUELLER: I don't have any strong preference either way. I'd leave that up to you. I don't think this is something where Google would say, you should do it this way or that way. I can see perfectly good reasons to say I want to noindex these pages because they're not really that interesting. It might also be that there are situations where you have sites where this is actually useful and interesting content that make sense to index or that makes sense to at least index as a part of a series. So it's up to you.

MIHAI APERGHIS: OK.

JOHN MUELLER: I noticed new markup for video games. If putting this on an official site, will this directly influence the Knowledge Graph? Will this impact any other searches? I saw this for the first time. So thanks for linking that. That's really cool. The important part here, I think it's worth a mention that this is for an official site. So if you have a fan page, if you have an affiliate page for one of these video games, then that's not really the markup that you need to use. But for official sites, this is a great way to give us the information that you really want to have used in the Knowledge Graph, in the Knowledge panel on the side. So that's something if you have an official site for a video game, then by all means, give us that information. I think there's attributes like publisher name, those kinds of things in there which we do try to show in the Knowledge Graph. And if you can give us an authoritative source, then that's even better. So that's something we will try to take into account. It doesn't apply for other searches though. So I'm going to the other part of the question there. What's the best way to find the number of pages indexed in Google? Site query shows a different number, index status, site maps, et cetera. So this site query is more like a very, very, very rough number which can sometimes be a few orders of magnitude off. So plus or minus a couple zeroes at the end. And I don't think that makes it very actionable. So as an SEO, I wouldn't focus on that. The index status is essentially the correct number of pages that we have indexed. That can be a bit misleading, because it shows everything that we happened to run across, an index from a website, which could include a lot of duplicate content, which could include a lot of things that you don't really care about. Personally, I prefer the site maps count, because that's something where you can submit the URLs that you really care about. You can say, these are the URLs I actually do want to have indexed. And we'll give you information saying, well, out of this set of URLs that you submitted, this many actually are indexed at the moment. And we look at the exact URLs. So if you submit one version like with slash index HTML in the site map, and we index it just with slash at the end, then that's something that we wouldn't count as being indexed. But at the same time, for you that's interesting information, because it tells you that maybe your site map file isn't completely perfect if you see bigger mismatches there. So I'd focus as much as possible on the site map count there. I really like site maps.

MALE SPEAKER: John, can I ask a follow up question please?

JOHN MUELLER: Sure.

MALE SPEAKER: Is there any way to download a list of your indexed URLs from Webmaster Tools? I can't seem to find anything like that. It shows you how many are indexed. But if I'm missing something on a site map, can I find out which ones in my site map aren't indexed?

JOHN MUELLER: No, not at the moment. So we had that as one of the wishes submitted with the wish list we did earlier this year. But at the moment, that's not something that you can do directly in Webmaster Tools. What you can do is narrow things down on your side if you want to take the time to do that. So you can submit multiple site map files, of course. And you can separate the URLs on your site into logical sets of site map files where you say, well, these are all my category pages. These are all my product pages. These are all my articles. And that way, you can narrow things down a little bit. But sometimes, it's a lot of manual work. So I don't know how useful that is to do in practice.

MALE SPEAKER: Yeah. OK, thanks.

MALE SPEAKER: John, regarding things that get omitted from the index. Is it at all possible, or should you-- like often, I'll be looking around for things that I need to fix. And some of the things are omitted. Is it worth fixing those things first or other things that are currently in the index?

JOHN MUELLER: Both, I guess. If you know about issues on your website, those are things I'd fix. If you know about the pages that aren't indexed yet, it might make sense to look about how you can link to them better within your website. But essentially, it's hard to say which one you should concentrate on more. It really depends on your website and where you think your bigger problems are. Sometimes, the bigger problem is that your website isn't really crawlable, and that we can't index any of the content, because we can't actually crawl to it. And that can be a really serious problem. But sometimes, it might be that we can crawl it just fine, but the content that we find there is actually not so hot. Then fixing the content would be something I'd recommend there.

MALE SPEAKER: Sure. Thanks.

JOHN MUELLER: With Google adding mobile as a ranking factor, we have sites that average 20,000 pages. And lots of them are mobile optimized. But a few aren't. What's going to happen? So essentially, we're looking at this on a per-page basis. So if those pages that are mobile friendly are the ones that we're showing in search, that's perfectly fine. The ones that aren't mobile friendly are probably the ones that you really want to work on. But if these are pages that nobody really sees in search, then maybe that's not so critical. But it's not the case that the whole site will disappear on search if you have just a part of the page that's mobile friendly at the moment.

JOSHUA BERG: Now John, hi. I've got a question about Panda quality algorithms. Let's say a site that's been around for a long time got hit by the Panda 4 or the May, 2014 algorithm, and then they didn't do anything about it, because they were still planning on improving the site. And then later on, the next Panda algorithm comes out, like the September 2014. Do these, in general, the quality control algorithm build on each other? Or are they still just taking it from where it's at? So the reason I'm asking is because I've got some old sites for clients. And then they didn't update in a while. Like they got hit badly by the last Panda update. So should they be looking at oh, we need to get working on this before the next one rolls around, because they will technically build on each other? Or will the new algorithm just take the site from where it's at in its current relevance?

JOHN MUELLER: No. In general, our algorithms are looking at the current state of a website. And of course, that involves things like crawling and indexing, because when we say the current state, that means the current state as we know about it, which means we had to crawl, and index, and process all these signals first. And at that point, we're looking at that current state. But it's not the case that we'd say, well, a previous algorithm looked at your site a year ago and thought it was bad. Therefore, you have to do even more work than a normal website would have to do to get out of that. It's essentially if we look at the current state and we say, well, this is fine, then that's a good sign.

JOSHUA BERG: So what I was thinking about are the longer term algorithms like we've seen in the past two years or so ago. There was a Panda or some update that came out which when it refreshed, it led up some sites that had been down for a year plus. So these are the longest of the quality control type of updates. Will these be more reflected by this scenario so that if someone is considering rebuilding an old site, they should say, well, there's been a few Panda updates, and we haven't worked on it for a long time. So we'd be best off starting with a new URL and going from there. Or is it not the case that because the site's been a problem for quite a while that it's got hit by these longer term problem algorithms?

JOHN MUELLER: I wouldn't worry about it from that point of view. If you're considering revamping your website and making it significantly better, then that's not something where I'd say you need to move to a different URL to profit from that. I think users are going to respect that if you make bigger equality changes like that. And the search engines will pick up on it as well as it reprocesses data. So from that point of view, I wouldn't artificially hold this back or artificially push it into a specific bucket. But I'd rather think about what you can do to improve the site overall and actually go ahead and do that.

JOSHUA BERG: All right. Thanks.

JOHN MUELLER: My Magento website automatically applies templates depending on user agent, which means with the exact same link, mobile users see different content from desktop users. How does Google treat my website? Which version does it choose to index? If you're separating between mobile and desktop users, then that's essentially dynamic serving, as we call it, where you serve content based on the device that the user's using. And that's perfectly fine. That's a legitimate strategy to create a mobile-friendly website. So from that point of view, that's something that sounds like you're doing the right thing there. As to which version Google would index? In a case like that, we'd index the desktop version in general, because that's the main version, the version that we see with the normal Googlebot. And that's the one that we would focus on. If you don't have a desktop version and your whole site is just mobile, then of course, we'll focus on that too.

MALE SPEAKER: Hi John. Just wanted to follow up on this one. So we're also providing this [INAUDIBLE] website. So one version is shooting to our Indian users, and one for the US version. So Google is always indexing our US version. All the time, I'm just caching or [INAUDIBLE] version. I only see the US version, not the Indian version. How can I make sure that my Indian version is also getting indexed by Google? We're updating it regularly on a daily basis, maybe [INAUDIBLE]. But the US version always gets crawled.

JOHN MUELLER: Yeah. That's a good question. That's tricky. Let me just mute you for a second. There's a lot of background noise. So that's kind of tricky, because it's a difficult situation, of course. Our recommendation is generally to have separate URLs for the different language or location versions. So you would have one version for slash US and one version slash IN for India, for example. That's essentially the optimal situation. Then we can crawl and index both of those versions separately. If you have hreflang set up between those versions, we understand that they belong together. If you have one version like the homepage that automatically redirects depending on the user's location, then you could also include that in the hreflang set as the x-default page. But essentially, the important part is really that we have separate URLs for the different country versions so that we can actually craw. And index the separate versions. Because otherwise, like you said, we tend to crawl from the US. And we'll probably just see the US version, and we'll miss out on all the content you have specific for Indian users. So that's something where if you can set it up to have separate URLs, that would be the optimal solution there.

MALE SPEAKER: All right. Thank you.

JOHN MUELLER: Mobile responsive versus desktop. Could it be a problem if we hide too much content on the mobile version with display none? The UI is better if we hide it on mobile, but the difference to desktop is becoming pretty big. In general, like I said, we do try to focus on the desktop version for crawling, for indexing. So in general, we try to pick up on that. Our requirement is that the mobile version be essentially equivalent to the desktop version. That doesn't mean all the text is exactly the same. It doesn't mean that the whole UI is the same, that you have all the links in the sidebar the same. But essentially, the primary content should be equivalent on the mobile version. And if that's the case, that's perfectly fine. So you don't have to show all of the sidebar, the footers, the headers, maybe bigger images, those kind of things. That's perfectly fine to adapt that for mobile and not show that, or limit it, or to show a different variation of that. So a lot of sites, for example, take big images, and they fold them into smaller ones or ones that you need to click on to actually see for mobile. And that's perfectly fine. We're seeing a lot of content mismatch errors in Webmaster Tools for Android apps. Being an e-commerce site, we end up showing different content on desktop and m-site. How do we tackle this issue? Will it affect our m-site ranks? So this wouldn't affect how we rank your website in general. This is essentially a problem when it comes to app indexing where you give us one URL that goes to your app and one URL that goes to your website. And we try to figure out what the primary content is on the app page, as well as on the web page, and make sure that it matches. So for example, we're looking for if you have one page on your website about blue shoes and the equivalent page on your app is about red socks, then that would be essentially a content mismatch. But if the equivalent page on the app is also about blue shoes. But written slightly differently, then that's something where we might not be picking it up perfectly there. So if you see things like that and you think the content is actually equivalent but we're not picking up on it properly, then definitely let us know about that. Maybe post in the help forum. Give us the information that we need from the app specifically that you're using there so that we can follow up with you and see what exactly is going wrong there. Is it something on our site maybe that's interpreting your content wrong? Or is there maybe something in the app that makes it hard for us to actually pick up that content?

MALE SPEAKER: Hi John. I just want to follow up on this question. We have this site where one is desktop and one is a separate URL, basically. So where do we need to add this app index and URL, to our desktop site or to our mobilized website?

JOHN MUELLER: Good question. I don't know for sure. I'd double check in the documentation. My understanding is that it needs to be tied in with the desktop site. And if you have a mobile site that's already set up as an alternate, then we'd see that three-way connection anyway. But my understanding is it should be with the desktop site. But I'd really double check in the documentation first.

MALE SPEAKER: OK. Thank you.

JOHN MUELLER: My voice is giving out, so I'll take a break here. It looks like we still have a bunch of questions left. I'll copy them out and see if I can answer some of them offline afterwards. But otherwise, so far, thank you guys for all the questions, and I hope this was a useful Hangout again. And maybe we'll see each other again in the future ones.

MALE SPEAKER: Thank you John, and a lot of health we wish you.

JOHN MUELLER: Thanks.

MALE SPEAKER: Bye-bye.

MALE SPEAKER: Thanks have a good weekend.

JOHN MUELLER: Thanks have a good weekend everyone. Bye.