 Welcome, everyone, to today's Google Webmaster Hangout. My name is John Moore. I am a webmaster trainer here at Google in Switzerland. And part of what we do is these Webmaster OfficeHour Hangouts. As always, if you're new to these Hangouts and want to get your first questions in, you're free to jump on in now. All right, John, I'm not bashful. How can you hear me? Hello? OK, AMP is my question. I've got some AMP pages I'm building, making a mirror of my HTML site. My question is, I understand that the reciprocal canonical and AMP HTML link that each page must have. What I don't understand or what I'm curious about is the navigation within the site itself. If I have an AMP page, should those AMP pages be pointing to the other AMP pages, or does it matter at all? That's usually up to you. So you can link to your other AMP pages. If you want, you can link to your normal mobile pages. If you have a responsive pages, link to those pages, that's kind of up to you. So the tricky thing there, I guess, is that you need to make sure that you're linking to something on your site. Because if you just leave it, if you point to the cached AMP pages, then there's no guarantee that those cached pages will actually exist already. So in any case, when they click on a link in the cached page, they'll go to your site somewhere. OK, so from an SEO perspective, it doesn't matter. As long as you're connected within your site, absolutely. OK, thank you. Joan, can I step in with the question, please? Sure, go for it. I want to know if anything changed within the mobile version, because I want to know if it's OK to hide the breadcrumb navigation for mobile version. Because it takes a lot of space. And of course, I know for sure that in the past, we could even change some of the content to make the mobile version to look more appealing. Is that the case? So now can I? At the moment, we use the desktop version for indexing. So it wouldn't matter what you show or hide on the mobile version. With the change to mobile-first indexing, it's more of a matter of what you actually have on the mobile version. So at the moment, we haven't nailed down the exact suggestions or recommendations or requirements specifically for structured data on mobile versions. It's very possible that we'll say you can simplify the UI on mobile pages and still specify the full breadcrumb markup on those pages. So I don't have anything nailed down yet. I understand. Do you know when it's going to be live, the mobile version first index? It's pre-programmed? We don't have a fixed timeline. So the team is currently looking at it in the way that they want to roll this out step by step. And that means we'll look at sites individually. And if they're ready for the mobile-first index, if that works for them, we'll switch them over to the mobile-first indexing. And those that aren't ready yet will wait a bit longer. But we'll have more to announce around that later on. So, of course, these parts with hiding or showing the breadcrumb and hiding and showing some of the content will be announced also because right now it's not defined. Thank you very much. John. John. John. John. John? Sorry, my husband's also called. John, he's shouting. I'm here. Sorry. You know what you said about the staging system like a staging system of adding people to the mobile-first index. Will people that are kind of for the next phase or their sites deemed as ready, will they be notified perhaps by Webmaster Tools or will it just happen for them and not for everybody else? Perhaps. So if there is something useful that we can tell them about that, then we'll try to tell them. If it's just we changed something internally and now we're counting your site differently but everything is the same, then there's nothing really to kind of tell them about. So if you're on a responsive site and we index the mobile version, then nothing changes. Yeah, because it might stop the whole like the sky is falling in, mobile-getting thing. If people just don't have it all up at once and they know about it, do you know what I mean? Like when the tax man has put you onto a staging scheme for a certain change, they'll sort of do people in batches and stuff and it stops the chaos. Yeah, I think as much as possible, we want to let people know what's happening so that they're not surprised by things. But it's still a matter of messaging overload. I think some sites get a ton of messages through Search Console, some sites kind of panic when they suddenly get a message from Search Console and finding the right balances is not that easy. But it's definitely something we'll expect, especially if there's something that we can tell people to kind of help them get them on the right path. Prepare, yes. Thank you. That's great. I'll stop right now. Cheers. All right. Cyrus, I think you've been trying to get in. Yeah, hello. Hey, thank you. I was wondering about near-duplicate comparison sites. For instance, if you had a couple of very, very, very similar sites, but not quite, like where just certain things differ on those sites, how would you address these duplicate content issues if there are any? So across different websites or different ones? On one website, if you had dozens of sites where different elements just differ and you had one with a check mark here and a check mark here and there, you had a cross instead, where it shows that you had certain features on one product and one without these features. Because I fear that this is getting a bit of a duplicate content issue, or the product might be too similar to really stand for themselves. Yeah, I think that's really the main point that you touched upon. It's not so much duplicate content that we would penalize a site for having these very similar pages, but it's very often just the case that these pages don't stand by themselves. And that makes it hard for us to rank them appropriately. So if, for example, in extreme case you have a shoe store and every shoe size is a different page, then those pages have to rank on their own and they have to collect links on their own and they're competing against each other in the search results. So that's something where you're diluting things quite a bit and you're making it harder for your content to be visible. Whereas if you had one page as really strong for this type of shoe and all of the different sizes are just attributes shown on that page, then that makes that page much, much stronger. But it's not something where there is a clear guide that all sites have to follow. For some sites, it makes sense to be more granular and to have more specific pages. For other sites, it makes sense to have very broad pages where you maybe have a lot of very different products. So you want to make sure that, I don't know, all of your sport shoes are on one page, for example. Because would it make sense to no index pages then? I wouldn't recommend no indexing them because then you're still competing with these other pages. It's just that the other pages are not shown in search. It's better generally to use the rel canonical and say, this is my preferred page for this topic. And all of these variations essentially fold up into this preferred main page. But doesn't the canonical stand for, if you showed different, let's say, review pages or such for one and the same product, wouldn't it count as different content for this specific review? These are different reviews, though, aren't they? Well, if they're different things, then they're different things. And I would keep them separate. But if it's the same thing, just variations of the same thing, then it's something that you could fold together. One more question, please. About no indexing pages at all, do you think that is for category pages, does that make sense? Like if you had lots of news, for instance, and a vast network of sites. And for instance, you had the old news which are outdated. And then you would just no index them so that they wouldn't be shown anymore. That's totally up to you. You can do that if you want. If you think these are pages that aren't relevant for search anymore, totally up to you. I think that's generally a good strategy if you constantly rethink what you want to provide in search and to say, I want to focus on this. And all of these other things are things I did in the past, but they're not important now. And I will cut them out. That's always a good strategy to keep the garden clean and to focus on the things that you really want to have shown in the foreground. Fair enough. Thank you very much. Sure. All right. Let me run through some of the submitted questions. And I'm sure we'll have more time for questions from you alive as well. And as always, if there are comments in between, from any of you, feel free to jump on in. All right. You mentioned previously that when the mobile index comes out, it can affect the results of desktop search. Are you therefore saying that a bad mobile site can have a negative effect on desktop search? Yes. Theoretically, it can. So if your mobile pages exist and your mobile pages don't have any of the actual content that your desktop pages have, then when we start indexing the mobile version instead of the desktop version, then we'll lose all of that content. And it'll be really hard for us to show your website in desktop search or on mobile search appropriately. So these are the type of things where it makes sense to make sure that really your mobile site is equivalent to your desktop site. And that's something we've been recommending since the start, essentially, that these should be equivalent. And people should be able to do the same things on both of these sites. Like I mentioned in the beginning, we do want to try to recognize well-working mobile sites and separate those from not so well-working mobile sites so that we don't switch them over immediately. But it's something where sometimes these differences are subtle and hard for us to recognize. So that's still something that I'd recommend kind of looking into and double checking how your mobile site is set up. So there's still a time to fix everything around half a year? Yeah. I mean, a lot of these are issues that we've been bringing up for a while. So one issue that I know the team ran into recently is one of the sites they were double checking had an end-to-one redirect issue. So that basically means that any page that you open on your desktop page, when you open that URL on a mobile phone, it redirects to a single page that says, hey, this is our mobile website. Thank you for visiting all of this. So basically, if we switch to mobile-first indexing, then the whole website would be replaced by this single one page. And that's the kind of issue that we've been flagging in Search Console. We send messages in Search Console about that because it's also bad for mobile users in general. But that's the kind of issue we try to recognize ahead of time to prevent it from causing problems. But obviously, there might be subtle variations of that that we can't recognize, that you do need to solve on your own. So ideally, if you have the chance, use some of the SEO tools that support mobile crawlers. If not, definitely use a mobile phone to navigate your website. And if you don't want to use a phone, then you can also use a lot of the browsers have the ability to change the user agent and the design to also match the mobile UI. So, for example, Chrome has a nice option for that. But anything you can do to really make sure that your mobile site works just as well as your desktop site, that's kind of what I'd aim for. And I think there might even be some extreme cases where you say, well, my mobile site is so terrible, like it's totally unusable, that it might make sense to even switch off the mobile site and say, I'll just keep my desktop site, users on mobile phones can still use my desktop site, it still works, it's not great, but at least they can do everything there. And if we have a desktop site to index for mobile first indexing, that works just as well. But believe it or not, I'm still finding out that people don't know what Webmaster Tools is and where do I find my messages and how do I get there? Yeah, that's definitely a challenge sometimes. I always say, do you know where your car keys are? That's pretty much your password, it's your website. You know, they're like, oh really? But it's also understandable, like this is the type of thing that you need when you have problems, if you don't have problems with your website and like why bother looking into all of these crazy tools that are out there? Well, I'm just saying, because if you guys wanna relate the message, if you're leaving a message in the person's Webmaster Tools inbox, they don't see it, so are you gonna make that message, are you gonna go out there in the media and kind of before this index thing goes? That's something that I think will happen anyway. Yeah, okay. For the most part, I think we're pretty good at recognizing sites that do well with the mobile first indexing and we can kind of handle that switch properly. So I don't expect this to be a big thing and I assume this kind of subtle transition is going to take quite some time until we kind of force the last person to switch over and hopefully that'll give people time to actually clean things up and fix some of the mobile problems where essentially a lot of people are already on mobile and they're running into the same problems already. So it's not. Well, sites that are not, sites that don't have the M.dot without the M.dot and sites that are not mobile friendly, will they be impacted as well? The just the one domain, like the whole site without? If there's only a desktop version of the site, we'll just index the desktop version. If it's not mobile friendly, and if it's not mobile friendly, what's gonna happen? If we only have a desktop version, then we'll just index that. So that's, I don't see any problem there. It's almost better for sites not to have a mobile version than to have a really bad mobile version. So that's kind of tricky to bring across sometimes, but it's something where if you use your phone to use your site to try to do a conversion to buy something from your site, to try to contact them through a contact form, then a lot of these issues are just so obvious that you wonder how people even manage on mobile phones. But yeah, try it out and... Your eyes open. All right, totally different question. We've been tidying up our citations. How important is having accurate maps listing on third-party citation sites as well as name, address, phone on, opposed to just making sure the maps listing on Google My Business is correct? So this is mostly, I think, with regards to the local search results on the maps listing. So that's not something from a search point of view that we would worry about too much. So from personal point of view, I think it's worthwhile to clean these things up because sometimes you run across situations where things clash, like opening hours say it's open and this site says it's closed, which is correct. That's kind of confusing to users, but from a search point of view, it's less of an issue. It's really more a matter of the map side where they try to use this kind of metadata. We offer services within a 10-mile radius of our branch. So this kind of goes into the same type of question. I don't have any advice with regards to Google My Business listings. That's something where you'd need to ask in the Google My Business forum. Can the alt image text have any bearing on the algorithms affecting desktop search results? Or is it only used for image search? Yes, it can. So the alt text is essentially shown when the images are turned off in most browsers. So that's something that we would count as part of the on-page text. So if there's something in the alt text that you don't want to have associated with your site at all, then obviously we might still show that in desktop search. And people with accessibility, of course. Yeah, I mean, it makes sense. Some people have images turned off. Some people have screen readers. Even on mobile phones, they have screen readers that try to read out the text that's shown, the alt text that's kind of behind the image. So using alt text is a great idea. I mean, it's just part of the content like anything else on a page. Excuse me? Are you saying that if the alt text is actually that important, do you think that the title attribute might be getting more important again? Like, for links or such? Image, I guess. Huh? For the image, do you mean? No, for regular links or like for anything. Basically, you could put a title attribute to anything, couldn't you? As far as I know, we do use that. But it's... Yeah, we can add context, John. Add context. I mean, it's kind of like additional anchor text, essentially, for whatever is embedded. And we do use that on the page as well. So as far as I know, that's just something on the page. All right. Also, the alt text thing is something that I specifically heard about from the mobile first indexing team as well, in that a lot of sites don't use alt text for images on mobile pages. And for us, that is a big loss of context, where especially for image search, we do use the alt text quite a bit to understand the images better. And if we switch to mobile first indexing, and we can see the images, but we lose all of the alt text, then that's a big loss of context there. So when you're viewing sites for mobile first indexing, I'd really recommend making sure that the alt text for images is there, that the images are embedded as well, so that we can actually get those images normally and use normal image search and show those images there as well. Isn't, John, isn't there like quite a huge amount of evidence as well that on mobile, people use images loads to do. Yeah, there is quite a lot of evidence in research. I have no idea. Yeah, no, mobile is mobile in images. Mobile? Do you feel? I don't know. I'll find the stuff, but it's a big deal anymore. Yeah, but this is something where, especially with mobile first indexing, apparently we notice that a lot of mobile sites, they don't use alt text. So they assume that it's important for mobile devices, but it is important for those that use screen readers and it's a best practice in general and it does make a difference for mobile first indexing for us. How do you handle alt text spam when they abuse that? Do you ignore that? Kind of the same as any other kind of keyword stuffing on a page. So it happens, we deal with it. It's been around for a long time. Sometimes it's pretty crazy when you look at the pages and it's this nice image and the text on a page is normal and then the alt text for the image is a big paragraph. Crazy. All right. Can adding tags or categorizing the blog section of your website help with regards to SEO and how your site is perceived by Google? Currently all we do is we link similar articles together and have links to relevant articles on language pages, but nothing more. So adding more context between pages is always a good idea, I think. So if you have category pages that you feel stand on their own and should be indexed like that, that can make sense. Some sites go a bit overboard and that they create like hundreds and thousands of tag pages that don't really provide a lot of value to users and probably that's worth blocking. But if you're doing something reasonable and these category and tag pages make sense for your users, then why not? It was you, I think, and I think it was you and Gary. I'm not sure where it was, but you were saying, don't block. Oh, it was an interview. But you were saying, don't block the tag pages because then Googlebot can understand all of that. So if you're running CMS, so with a lot of tag pages, don't block anything we understand. For the first part, I think we picked that up properly. Sometimes tag pages essentially turn into search results and that's something that we'd want to have blocked because they don't provide any additional value. Why would you do them anyway? Why would you do them if they were just like, I've seen them, I've looked at sites where people just go absolutely nuts the minute that they can add tags and they just add ridiculous generic words like their own name and the one at one. They're just anything that just enters their head and they're just rubbish. So I think that's the point really. Yeah, yeah. The block is to simplify SEO. Don't let people go nuts because they are mental when it comes to being able to focus on it, they're just crazy taggers. Yeah, I guess we could simplify SEO into be reasonable. Yeah, that's irrelevant. Yeah. So if there's a lot of tags, then you do the site colon and then whatever, abc.com and then take a look at everything and then if there's a lot of tags, you're saying block, it's worth blocking. I mean, it's something where you need to look at what's actually happening there. And sometimes it makes sense to no index some of those. Sometimes it makes sense to no index all of them. Sometimes it makes sense just to keep them all but that's something where you kind of have to use your own judgment and think about like if someone were to land on this specific page, am I providing anything of value for that keyword? Or is this basically just like trying to rank for gazillion keywords but not really rank in a way that people will have value from visiting them. One more question regarding the no ODP tag, is it like landing on the graveyard of meta tags like the keyword tag? I think it already is, yeah. So I think we already stopped using, I'm not a hundred percent sure but at least we don't have the data anymore so it's kind of gone now. And I think we did a blog post about that where you end making sure that your titles and descriptions are actually useful on your page because without the DMOZ data we don't have those additional sources of titles and descriptions. All right, let me run through some more of the submitted questions and maybe we'll have more time for questions from you all as well. When Google looks at the importance of content on a page as a location of that content above the fold matter for the most part, no. But this is something where I think the usability aspect has a much stronger effect than the SEO side where if people land on these pages and they can't find what they were actually looking for they're not gonna do anything on your page. So any ranking that that page gets is kind of irrelevant because users are not going to convert and do something useful on your side. Content behind fold, behind tabs still going to be discounted on mobile site like it is for desktop. And no, the current plan is to treat content on mobile in a way that even if it's behind a tab or behind kind of a user interface element that will counter this normal content on the page just because on mobile the UI is obviously much more limited. So there are fewer opportunities to do that differently. Is it against Google's guidelines to mark up reviews with micro data that are gathered by a company through websites like TrustPilot specifically rating stars for local businesses. What's up with that? So I double check with the team. Let me just pull out my email so that I make sure I say it correctly. So from our point of view using reviews on third party sites is fine. The things you should be aware of is you need to reference the third party source. So kind of link to the reviews so that people know where they're coming from. You need to make sure that what you mark up on your pages stays in sync with what the third party has. So kind of the, if you're using a widget that probably works automatically and you need to make sure that you're using this markup only where it's really appropriate. So essentially using the markup on pages that are specifically about that item that you're marking up. So for example, if you have a company-based reviews and you're on a webpage about one of your products then the company reviews would not be relevant to that specific product. On the other hand, if you have a page about your company and you have reviews for your company then that would kind of fit. But it really kind of like with rich snippets and structured data markup in general it should be appropriate to the type of page that you're actually on. Hi, John. Hi. Hi, just have a question about some of the sites we have. So with the mobile first index we currently have a site which when viewed by desktop user agents you've got all of the HTML links but then when resized to mobile view with a mobile user agent you don't see these links because we have JavaScript for accessibility. Now we just wanted to know how we should handle this, whether or not we should be including, for example, the links in the source of the page so that they can be crawled. And so when we simulate a crawl with a mobile user agent all of the pages can be accessed or whether or not maybe you will be able to crawl the JavaScript, what we should be doing essentially. If we can crawl the JavaScript and render the page with those links from the JavaScript then that's okay for us. On the other hand, if the JavaScript doesn't actually include the links to those other pages when it's kind of accessed with a mobile device then we wouldn't have any links to the other pages. So that would be kind of a loss. But the JavaScript executes and it generates these A elements in the DOM and they're just not visible on mobile or they're visible when you kind of like hit the tab to open that then that's fine. Okay, and what's your view on, for example, having these HTML links in the source of the page so they're also accessible? Perfect, yeah, I mean that's the easiest solution. If you can do it like that then you don't have to worry anyway because it's in the HTML, we see it in the HTML, we see those links. That's perfectly fine. Even if they're hidden, they're not like when you resize they're not actually on the page but they're hidden, that's fine. I mean, I just make sure that from a usability point of view your site still works. It's not that you're removing all navigation and users are stuck on that one page. Okay, great, thanks. All right, on our news blog section all the articles are put into an archive date folder. Should these links be no index, no follow given that in effect duplicate content. Again, that's totally up to you. Sometimes it makes sense to have archive pages index, sometimes it makes sense to no index them, sometimes it makes sense to just show a snippet on these archive pages so that you actually have the full content on the individual articles themselves. That's really kind of up to you how you want to deal with this. If tons of canonical URLs are pointing to one common page, is that harmful? No, not necessarily. The one situation where I have seen that be problematic is if all of the URLs on your website have a canonical to the homepage of the website then essentially our systems kind of realize that something is probably wrong with the way Dwell canonical is implemented here and we'll probably try to ignore that that's set up on those pages. But if you just have a lot of different parameter URLs and you're using tracking URLs for different traffic sources or have session IDs or anything like that where you have tons of URLs but actually it's just always the same content and it can be simplified to a cleaner URL then that's perfect use of rel canonical. Hi John, just to ask this question. So we have this page is similar to that one but the thing is like it is not by the, you can say by the family it is something like it is like by the sorting option. So maybe it is a color or maybe it is a type of fabric. So ultimately the product is the same basically it's the listing page but I mean the differentiation between them is it colors or maybe you can say size. So something like that. Is it good I get to like apply canonical to these pages to my what a problem parent main page. Good. For variations of a product if you wanted to. The thing to keep in mind with the rel canonical is we will focus on that one canonical URL for indexing. So if you have one page for a red shoe, one page for a blue shoe, one page for a green shoe and your canonical is the red shoe, then if someone is searching for a blue shoe we'll just have the red shoe in our index. So that's kind of it's essentially up to you if you want to do it like that. My recommendation is really to have a canonical page be equivalent to the other pages so that when we index your canonical URL that has all of the content that provides all of the information that we need for search. John, I'm sorry, I bought it in here. Sorry, I'm gonna go in a minute. I was reading about that and I was thinking about canonicalization last week. You know, I was looking at the all the RFC papers and it was kind of quite clear really that it either has to be duplicative or a superset. So ultimately you have to, the context URI or IRI or whatever has to basically refer to something that includes what you're referring from. So like a Russian doll type thing. So as you said with the red shoes, blue shoes, et cetera if the page about shoes includes red shoes, blue shoes, green shoes and all the different shoe sizes that would be that you could canonicalize the shoes because actually if there's a section on red shoes, blue shoes, green shoes in there that's basically correct, isn't it? It's like a superset. Yeah, yeah, I mean that's a perfect use case. That's kind of like a view all page I guess in the case of pagination. It's some sites still do it kind of the theoretically wrong way in that they pick one of these versions and say this is the canonical and systems will just follow that but they have to be aware that when they do follow that they'll lose kind of the faceted information that's not on the canonical page. So whatever you're, whatever you canonicalize to effectively you're saying, right well we're canonicalizing from blue shoes to red shoes because the page is the same but actually you're never gonna show up for blue shoes then. Exactly. You're gonna show up for red shoes. So you better to make a better shoe page with all the shoes in it or make a really good page with loads of blue shoes in a really good page with loads of red shoes in and focus on the topic of blue shoes or red shoes and make them stand on their own two feet. Perfect, yeah, exactly. Yeah, okay, thanks. All right, so completely different type of question. I'm considering adding an email capture modal to my site. I've had concerns around interstitial penalties would a delayed pop-up still be considered intrusive? Yes, for the mobile pop-up, mobile interstitial ranking change that we had even delayed pop-ups would be considered that. I'd recommend more doing something like a banner on top or on the bottom of the page or maybe something that happens when you navigate within your website after reading that page. So don't just delay it, don't just show the interstitial when people scroll really provide it then when they've had a chance to actually digest the content that you're providing. What's the best way to handle duplicate content in e-commerce website? Wow, lots of duplicate content questions. So I think this is kind of covered already, so different variations. Another question about duplicate content, we have a product page in Germany where we're selling it, we're not selling it in Switzerland, a partner is doing that there. They're selling it with another brand name and they have their own website. They copied our text saying that they have to change the text because of duplicate content. Let's see, should we create our own website for Germany or for Switzerland and redirect from this fake domain to their Switzerland website? So in general, this is less an issue around duplicate content but kind of around internationalization. So I wouldn't worry about the duplicate content part, that part kind of takes care of it's on its own but what you could do in a case like this where you have one product in one country and the same product under a different name in a different country is just use the hreflang markup between those pages. So it doesn't mean it matter if the product name changes, if the company name changes, if it's the equivalent product, you can use the hreflang links between those pages. So that might be an option there, especially if you're working that closely together with the other company in the other country that maybe they'd be up for doing something like that. What happens with the hreflang markup is not so much that there's a big ranking change but rather for users in the appropriate country we'll try to show the appropriate URL in the search results. So people in Switzerland would be more likely to see the Swiss URL and people in Germany more likely to see the German URL even from a ranking point of view it might be slightly different. I'm looking at using the free CDN by Cloudflare. Would this affect my SEO images or indexing? CDNs are perfectly fine. Cloudflare is fairly well known. So I assume that there's no issue there with regards to any of these problems. On the other hand, it's something where crawling will be a bit faster probably. It might take a bit of time for us to pick up on the new crawl rate and for users, of course, it's something where if your site is faster you'll probably see more indirect effects there and that people stick around on your website more. They click around, they convert a little bit better. So that seems like a good step. I spotted one something the other day on that John because I just added Cloudflare, Railgun, Rocketloader and all sorts of things. And I was doing some testing on the various tools, GT Metrics, Pingdom, blah, blah, and Google Search, PageSpeed Insights. PageSpeed Insights, Gary kind of confirmed that it doesn't pick up on all the Cloudflare optimizations that you make at this moment in time. And then GT Metrics came in and explained the reasons why. So that's one thing that people maybe should know about Cloudflare. If you're trying to optimize it for speed, which is often what people are doing it for, when you go and check it with PageSpeed Insights it'll still show up as pretty slow. But when you check it with other tools, it will show up like A and B and stuff. Yeah, I mean, these are all tools. It's not a machine that's happening behind the scenes. You kind of have to know what these tools are doing to interpret their output. And sometimes it's easy to take something that's like a grade from A to F and just say, oh, I'm doing good. I don't have to do anything. But usually it's more important to actually understand what actually is being tested and what that actually means. It might so mean that there are things that you need to do. It might mean that you're actually doing things fairly well. It's something that you kind of, I don't know, you have to have a lot of knowledge to also interpret the tools. Can I ask you a question since we're in the CDN topic. Does Varnish have an impact on ranking? I don't think so. So Varnish is pretty caching. You know, I'm just going to ignore all the articles out there. Almost 90% of all the SEO articles should be removed from Google. We're going to do that starting later on. Like there's just so much talk. I mean, honestly, what's the point in having these articles online? I just went through looking and also talked to this guy and he was saying, yeah, yeah, yeah. He works for a very serious hosting company. So Varnish, from what you know, has no impact on HTTPS. On HTTPS. So Varnish is just something that you can install on your server that, depending on how you set it up, can make your site faster. And of course, site faster is something that we could pick up for search or that we could pick up and kind of indirect signals for. If people stick around on your site and they tend to recommend it more because of that, then there's kind of these indirect effects as well. But I think it's important to understand that a lot of these things are not direct ranking factors where you can say, I saved 10 milliseconds here. Therefore, I'll rank, I don't know, half a position higher because of that. But they're good for users. I mean, if you're serving a site load or a page load miles faster because you're using things like Varnish, which massively speeds things up, that's going to be a better user experience overall. I imagine that depends a lot on how you set it up. I mean, just by turning a feature on doesn't necessarily mean you'll improve your site by that. So that's kind of something where, like with a lot of things, you have to kind of know what you're doing instead of just picking checkboxes and saying, oh, I heard this is a good thing. Therefore, I'll turn it on. Because if you have competing caches on your server, it could end up being that you actually slow things down or that you've barred your server down more than is necessary because maybe you have a different kind of cache that's happening outside of your server. And all of these things, you kind of have to know what you're doing, I guess, to basically pop from them. So if you're in the milliseconds, then there's no need, basically, to turn on AMP, right? Since you already have a fast website and you've got the Varnish and it's working amazingly for you, there's no need to turn on AMP, right? Well, AMP is something different because it's not just about speed. It's also about speed. If your site is fast already, you don't need AMP. I can send you the tweet. Well, it's something where AMP does a lot of different things. So it's like the AMP cache is there. The ability to preload the content, to pre-render the content above the fold so that when people click on a search result, it loads instantly. There's some search features that require the AMP markup so that we can embed the content better in search. So it's not just like a speed tweak. There are a lot of other aspects around AMP that are kind of relevant to some sites. They're not relevant to all sites. If you're loading in the US at one second and I'm loading in New Zealand at two seconds, I still need AMP, right? It's not just a speed thing. So I think that's important to keep in mind. AMP is not just the way to speed up your site. It has various aspects that are all there. The page takes quite a while to paint, for instance. So I know that on one of mine, there's like a huge image that we're looking to replace. It's like when we looked at the video, that loading, it seemed to get to the first byte reasonably quicker, even though that needs to be speeded up. But then it seems to take ages to paint and then there's just this massive image that comes in at the end. So that's kind of the thing, really, that is picked up on, isn't it, painting? That's something that could affect users as well, yeah. If like part of your page loads quickly, but actually until it's usable, it takes quite a bit of time. That could be something that users are upset about. And these are probably also things that would be interesting to test on your side, where especially if you're aware of something like a giant image slowing things down, you could set up a kind of an A-B test and say, well, here's a fast image, here's the slow original image, or maybe an artificially slow image and monitor the conversions for those different types of users. Imagine that would be a really interesting blog post to kind of follow along, too. Yeah, good idea. Excuse me. I was wondering, picking up on this, like using page speed insights, like with all my clients in the last year, like one of the main issues which I have encountered all the time was that actually Google was serving me the browser caching, like it was always complaining that browser caching from apis.google.com were not really optimized or so. And I was wondering how to address those issues. You kind of have to understand the details there, I guess, because some of these static files, especially from a larger host server, served in ways that are very optimized for specific user agents. So for example, this is something that I believe used to affect the analytics JavaScript file as well. Depending on the user agent, we would do fancy optimization with compression or not, and using a random testing tool, we wouldn't do that optimization because we weren't sure how much we could optimize for this testing tool. So that's something kind of to keep in mind there. The other thing to keep in mind is that we try not to special case Google services or scripts for these testing tools. So if you use a lot of AdSense on your pages and analytics and lots of other code from Google, we will still flag that as being slow, even if it's using Google services because for the user, it's still slow if you use a lot of these different things. So we want to avoid saying, well, this is from Google, therefore we all say it's always fantastic. We want to kind of mirror what actual users would see when they go through that. Let me double check the questions. If there's anything really kind of critical to call out that we haven't looked at in the past. One thing I guess worth mentioning, someone said that the CTPLD as a domain hack for non-English speaking country negatively affect my site in English. So for example, read.it. So from our point of view, what happens there is we will promote that site for queries that are kind of leaking content in Italy, for example, and we'll treat it as a normal site elsewhere. So if you don't mind that it's kind of being shown more in Italy, then that's generally fine. On the other hand, if you're trying to target a different country, so if you have read.it and you're trying to target users in Germany, then you need to keep in mind that you can't set up geo-targeting for that. But if this is a global site, then you can definitely do it like that. That would be fine. Yeah, wow, so many questions left. Okay. I think I probably need to take a break here. So if I didn't get to your questions and you're still really curious what the answers might be, I'd recommend either copying them to the next Hangout or maybe even just posting them in the Webmaster Help Forum and checking them out with other webmasters and the fantastic top contributors that are active in the Help forums there. So maybe I could take one more live question from one of you and then we can take a break. What happened on the weekend? What happened on the weekend? I don't know, some sun, some rain. That was an easy one. I haven't seen anything like that in a long time. Okay, so Mihai has a one in the chat. Can AMP be with the same URL as desktop and dynamic serving? Do we still use very HTTP header? What about real alternate? Yes, you could theoretically do dynamic serving for AMP content, but I suspect it's very tricky to get right and very tricky to diagnose issues with regards to that. So if possible, I'd recommend using separate URLs for AMP pages or just saying, well, my AMP is my canonical page. AMP could be a responsive page that works well on desktop as well and just using everything on AMP if that works for your pages. Is it also a problem if the headers are not set properly for HSTS, like for HTTPS? Is it also a problem if they're not set up properly? HSTS is optional. It's something you can do. Essentially, it means that you've committed to moving everything to HTTPS. So if you want to do that, that's perfectly fine. If you aren't sure about your HTTPS setup or if you're wanting to double check that everything is actually working well, then I'd wait with the HSTS setup. Okay, so if it's still there and it's not sitting correctly, that's okay with Google. Yeah. I ask if Google can detect the AMP without a real alternate. As far as I know, we need that kind of back and forth link with regards to the real alternate anyway, for AMP pages so that we can recognize, actually there's an AMP page that we can fetch here and from the AMP page to rel canonical back to the desktop page or whichever page you want to be canonical for that. So we'd need that setup. All right, let's take a break here. It seems like Mihai still has a bunch of questions specifically around AMP. Maybe you can send them by Twitter to me or post them in the Web Manager Help Forum and I can get some of the folks from the AMP team to take a look as well. There's also a dedicated AMP HTML forum that you can post these type of questions to and the AMP team is fairly active in response to that. All right, thanks a lot for jumping in. Thanks for all the questions that you speak. Really, I wish you all a great day. And I'll see you again in the future hangouts. Thank you, sir. Thank you. Thank you.