Harry, what are your general thoughts on the game? Obviously, we're disappointed to not get three points. We come here looking to win games. We've still got targets of automatic motion. We see it as two-point drop. But in the circumstances, losing a man the way that we did, I think we can be proud of the fight that we put in today. And for me, that's a big ticket in the team spirit, a bit of leadership, being there for each other. There's going to be times in games where you've got to help your mates, help your mates go to make mistakes. I was proud of us for doing that today. Does it give you confidence that we can grind out even if it is just a point and when we go down to 10 men? We know that in this league that you're not going to play well every week. I think we've shown that.  We've done that today in difficult circumstances. So, yeah, it's a good skill to have, I think, is to get a result when you're not playing your best. And again, like I say, it's about digging your mates out and you've got to make mistakes across the 90 minutes. Nobody's perfect and, yeah, that was important that we showed that we could do that today. How quick does that mentality change and how quick do you have to tap into a different mindset when something like that happens? Well, that's the thing, you know, credit to Tiki. Jamie gets sent off in straight away. He's telling us how to concentrate, stay calm.  We defend, you know, you get down a little bit, you do, that's part of the game. That's just what happens. But, yeah, it's got to be an immediate shift and I think we did that today, you know, I think we managed our spells, they didn't have too many chances and, yeah, again, as a defensive player as well, I'm particularly proud of a clean sheet, I always am. Of course, they part of the pressure on, they had a lot of chances on the goal. Talk us about them saves. Well, the free kick one, I was wary because obviously at our place, he'd done me over the wall, you know, in the week, you know, it was kind of the termination, you know, I always believe that you don't want to get beat your side from a free kick, so, you know, if it was to bend it up and over the wall and put it in the top corner, you can't really do much about it, but the mindset for me as a goalkeeper is, you know, you've got your half the goal and he doesn't score a net, so he's it a good free kick, but, you know, in my mind, if that had gone in, I'd have been disappointed, but again, I've said it a million times on here, goalkeepers about moments, and in that moment, my team needed me and it was nice to come up with that. But again, from Tuesday night, you saw, it's a team effort, keeping the ball out of the net. It's not just me. It's the centre arse. It's the defenders' midfielders, and even the forwards, you know, the defenders start at the pitch, so again, a clean sheet that I'm very proud of, but it's the team effort always is. How much can we work on then going into next Saturday? Again, you know, we're at home, so the emphasis changes there. Again, I think, you know, we've got to be going into that game, thinking the way the favour is believing in ourselves, maybe a bit more, you know, look a bit more threatening on the count. You know, when you come away from home, again, as I say, you know, you want to win and we play to win, but it was important not to lose today, especially in the circumstances, but at home against the promotion rival in the automatic promotion places, sorry, the playoffs, you know, you want to be the favourite, you want to be creating things and causing them more problems than they cause you really, so that's what we've got to work out on the training pitch, and yeah, I'm sure we'll be doing that.  It's always really cool, you know. I'm aware it's a long way to travel. It's an early start for some people. I hope they're on the train, on the beers.  And it makes you feel proud, you know, I had a couple of mates here today, and you're proud to represent these guys because they're travelling their numbers, and, you know, we don't always make it easy to love us, you know, after Tuesday night, you know, to still have those numbers in the voice they're in. Yeah, it's credit to them. It's amazing to play in front of these guys.


All right, welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hours Hangouts, together with webmasters, SEOs, publishers, anyone who has a question around search, any topics like that.  But if any of you want to get started with a question of your own, feel free to jump on in now. Can you hear me? Yes. OK, my name is Sharon. And I work for a software company that has about 35 international websites. And we have several that are in the UK, India, Australia, New Zealand, use the same translated English. So we're where we have duplicated content. We use self-referencing canonicals, and we also use XML site maps with hreflang that have reciprocal links. And recently, we noticed on some of our software subscribe pages that we are aware that use a lot of client-side JavaScript. And so we've been using a tool called Prerender to render some of those pages. And then when Googlebot and other search engines come, we show the Prerender version. We recently noticed that Google was indexing the wrong site for some of those subscribe pages. So if you went to the UK page and we checked the Google cache, it would show the India page. And the way that we were aware of this is we use microdata, structured data for the billing, the price. And on the SERPs, because we're getting that snippet, for the UK page, we were seeing the Indian rupee. And we're like, that's not right. So we checked the cache on several of them. We noticed that Australia would have an India page and UK would have an Australia page. And we weren't quite sure we were hoping it was a Prerender issue, but we wanted to come here and rule out that it wasn't something maybe Google was seeing duplicate content and caching the wrong page. Now, so generally, that can happen when we think that these pages are the same. So if we think that these are really identical pages where the content is the same, then what might happen is we'll understand the connection between these URLs. But we'll just index one of these pages. So we'll index maybe the Indian version. And we'll know there's also a UK version based on the hreflang. And we'll swap out that URL in the search results to send users to the right version. But we'll just have one version indexed. However, it sounds like we shouldn't be folding those pages together because they're not really identical. Like you mentioned, the prices are probably different. So I see perhaps two things could be there. One is that we might just be getting it wrong, which is always possible. In which case, it would be useful to have explicit examples where you have a query that pulls up these pages and which of these pages were getting wrong so that we can look at that with our team here to see what is happening here. The other thing that might be happening is something with the client-side rendering. Like you mentioned, I don't know how you have it set up at the moment, but I know a lot of the pre-rendering tools use the hash bang setup with the escape fragment to provide the pre-rendered version. And on our side, we've essentially stopped recommending using the hash bang format. And we're switching to crawling just the hash bang URL instead of the escape fragment version. So if you're only serving the pre-rendered content through the escape fragment version, then chances are we'll try to be rendering the pages ourselves. And if we can't render those pages ourselves, then perhaps we have a simplified page that we're using as a basis for indexing, which might result in this kind of duplication where we see, oh, this base page that we're using for indexing is the same as the other one. Therefore, we can fold these pages together. So I'd recommend double checking the way that you're setting up pre-rendering, that you're really doing that based on the user agent, for example, and not with the escape fragment hash bang setup. If that's the case, if you're doing that properly, I don't know, send me some examples so that I can take a look at that with the team here. OK, what's the best way to send them to you on the forums The forums is an option, or on Google+. You can just send it to me directly. Thank you. Thanks. All right, anyone else before we get started and jump into the questions? Hi, John. I have a question related to the snippet of the description. So I noticed that the description has recently been shorted to, like, 150 characters. I was wondering if my content still descriptions still have, like, 200 characters or even 20 characters. If a user is searching for a certain query, the keyword is, like, we've got four lines, and the keyword is around a four line. Will Google still picking out the contents within those 200 characters? Sure. So I would not recommend just jumping in and changing a length of the description meta tag just on what's currently shown in the search results. This is something that's very dynamic, that can change over time, it can change per query or per device. These things are not something that's really worthwhile to kind of target an explicit number for. So that can change. And also, the description meta tag isn't something that we use for ranking. So if your page has content on this keyword, then I wouldn't worry so much where that keyword is in your description meta tag. Instead, just make sure that the description that you provide is really short and to the point and provide some information for users who are looking for something like that to better understand how your pages might fit in there. All right, and I think with that we have the most controversial topic covered. The change in description snippet. Let me run through some of the submitted questions. And as always, if there's anything on your side that's unclear along the way, feel free to jump on in. And we can look at that as well. On our website, the business team would like to add a redirect from our mobile site to our app if the user has already our installer app. The redirect uses deep links to redirect the user from pages on the site to the matching screen on the app. As we already have app indexing set up, we exclude users from organic search. The redirect won't redirect Googlebot either as we want to ensure that the mobile site can still be crawled. We don't want to file a file of Google's sneaky redirect guidelines. Is this OK? Essentially, this is OK. Lots of sites set it up like that. The important part is really that users, when they come to your website, through the search results for the first time that they can actually read your content and get to your website, that they're not automatically pushed to an app install screen. You can definitely use an app install banner on top of the page or on bottom of the page to let users know that you do have an app. But the mobile site should be accessible just as well as a desktop site when it comes to search. Here's that question about descriptions. We can skip that one now. Is there any way to resubmit our website for reconsideration or manual review from Google Webmaster SEO team? Our site was first directory to go SSL, has HTTP2, and top 5% in Alexa speed rankings. We may have upside our ranking previously, but fixed all technical issues and are looking for a way to trigger a manual SEO review. We don't do manual SEO reviews. So essentially, if this website is doing everything right, then our algorithms will pick that up over time. We don't look at things like who was the first to do this or the first to do that. It's really a matter of the current site and the way that it's relevant in search results to users at the moment. If you had a chance to look at our AngularJS site, I don't think I looked at the AngularJS site. So what I'd recommend doing with AngularJS sites, in particular, if you're worried about whether or not we can index it properly, maybe post in our JavaScript sites working group to get advice from other peers who've done similar things. The rest of the question says there is a title, description, canonical tags, are also dynamically generated and served with a DOM. One thing here to note is that we don't pick up the canonical link element from the JavaScript rendered version. So we'd only pick that up from the static HTML version that we pick up on initial crawl. So if you need to serve us a canonical tag, then make sure that's in the static version. Or if you can't serve it there by default, maybe consider finding a way to pre-render those pages so that we can pick that up from there directly. In many cases, that's not really necessary, but I kind of look at your site to see what the situation is there. Would you recommend adding hreflang to pagination? That can be a lot of pages on larger-scale sites and doesn't seem worth it, since Google will often serve as page one in a paginated set. Is it worth it? It's really up to you. So hreflang, in general, is something that will swap out the URLs when we see someone searching with a specific language and we see the wrong version otherwise ranking. Then we'll swap out those URLs in the search results. So if you never see those URLs showing up to users or to the wrong type of users, then probably not necessary to add hreflang links there. So that might make it a little bit easier for you. Can you tell us what the importance will be for sites to start becoming PWAs along with the use of AMP? With speed becoming more important each day, would you think we're going to start seeing a trend occurring where many e-commerce sites are going to load up as PWAs, with their informational content loaded up via AMP? I don't know so much about predicting the future. These things are really kind of they can change over time. In general, I think the PWA setup is something that makes a lot of sense and makes it possible to have really fast sites. So it's not something I'd discard by default, but at the same time, I don't see this as something that all sites need to do. So for some sites, it can make sense to have something like a PWA that provides offline functionality. That's more like an app that's kind of installable on the home screen, those kind of things. But that's not necessarily the case for all websites. So with that in mind, I definitely look into what PWAs could do for your website. And to consider them if they make sense for your specific use case. But I wouldn't just blindly use any technology just because it's out there. What kind of video result is this? I don't know. I'd probably look at you to double check what you're showing there. I need to double check. I have a site where I delay loading of videos for performance reasons. They play when a user clicks on the poster image. I'd still like to use video schema to show where the videos are on the page. I'd also like to add them to video site map. Would that be acceptable or ignored if Google has trouble seeing the video embed code? For the most part, I think we'd be able to pick that up, especially if you have a video site map to let us know about that and to give us the critical information there so that we can crawl and index that page directly, the video content. So that's kind of what I'd look into. A lot of sites use a kind of a thumbnail image for videos. That's perfectly fine. We used to have pretty bad XML sitemaps in Search Console, links to no index pages, hreflang with no returning links. And Google eventually stopped fetching our XML sitemaps here. We revamped the whole site, created 66 XML sitemaps, and submitted them with Search Console. It's been four days, and they're still all pending. Is it possible that Google is disregarding XML sitemaps for our domain since they were pretty worthless before? I don't know how you had your sitemap set up before. So it's really hard to say. It's really rare that from our side, we would say we're not going to crawl these sitemaps anymore. That's usually something where it would have to be pretty obnoxious in that there are thousands of sitemap files with totally irrelevant URLs that are just kind of a waste of resources. So since you mentioned 66 sitemap files, that sounds like it's probably not the case. And maybe it's just a matter of giving it more time to kind of settle down. Hey, so that was my question. Hi, John. Cool. Yes, and we used to have, again, 66 sitemaps, but with like 10 billion total links with duplicates. So we used to have HF-length tags in sitemaps too. So with everything included, there were 10 billion URLs, and 90% of them were actually paced with noindex. So now when we are creating our sitemaps, we take regard of the noindex tags. So now we have much more lighter sitemaps, but all of them are indexable. But for the last seven or eight months, Google was actually stopped crowding our sitemaps altogether. And like you said, it was a waste of your resources, so it makes sense for you to not crawl them. But right now, this new version is better. So how can we tell this to Google that this version is good? Yeah. OK. You can send me URL, and I can double check with the team to see if there's anything blocking on our side. All right, so I'll message you on Google+. Yeah, that sounds like a good idea. OK, thank you. Cool. We need to kill thousands of pages in redirect chains from our subdomains. But oh, boy, long question. We set them to 410 and submitted them in sitemaps. The problem is Google is not seeing them as not found and just submitted URL and not selected as canonical. Usually, this is something that catches up over time. So if you're already seeing submitted URL and not selected as canonical, then that means we're not indexing that page, so that there's essentially nothing that we'd need to take out of the index for that situation. So if you're already seeing them as not selected as canonical, then it's a matter of us not having crawled it with that kind of file I found error code. But essentially, we've already processed that, and we don't need to know about that anymore. So that sounds like it should be working as expected and not something that you'd need to force additionally. If I submit a new XML sitemap in Google and see that it has too many errors, I remove this from Search Console. Will Search Console still throw errors for that specific sitemap, or it won't show as long as there are other errors with the sitemap? Usually, what I'd recommend doing there if you submitted a sitemap file that has a lot of errors in it, then I would either try to fix the sitemap file so there's actually a more valid sitemap file, or at least remove the sitemap file from the server. So as long as the sitemap file is still on your server and it's just not listed in Search Console, we could still crawl that and try to process that sitemap file. So if you really want that taken out, I'd recommend removing it from your server directly or fixing the sitemap file. In Search Console, crawl errors, we sometimes see pages as 500 or 410 while the page is opening. Can Search Console have some option like the cache of the time when Googlebot hit the page so that we can share this with the team and tell them whatever Googlebot is hitting this page, it's finding this response code? It should only be for errors or warnings. So what happens with general server errors or 406 errors, 586 errors, is that we don't process the rest of the content of the page. So we don't actually keep track of what is shown on this page to Search Engines or to us, at least. We only keep track when we can pick up the content normally, when it returns a 200. So in a case like this, we wouldn't have any cache that we could show you in Search Console. Let's see what we have here. If the currency contact address is changed in the website, though there are thousands of pages that have duplicate version, will it be considered as different content? In Hreflang, will we consider this, or will we still see it as duplicate content? Not quite sure how you mean. In general, if there is different content on a page, then that's not duplicate content. So if you have different addresses on a page, especially if you're looking at a Contact Best page, like you mentioned there, then that would not be considered duplicate content. That would be just normal kind of content. So that usually wouldn't be something to worry about. If we did see something like this as duplicate content, for example, if you have a large piece of general text on a page and a small address on the bottom, and that general text is the same across multiple pages, and the address is just changing on the bottom, then what would usually happen is we'd still index those pages, and we'd try to pick one of those to show for queries that are more general, and kind of filter out the other versions of the same page. It's not something where we would demote a website for having this kind of duplicate content, because this is really common scenario.  So I'm asking my developers to add both, no index, no follow, and then do a redirect to the closest page. Is this the right approach? Or should I do something else to remove the pages from Google Search Index? So there are two things here. On the one hand, you can't add a meta tag to a page and redirect it, so you have to pick one or the other. On the other hand, if you remove a page, I would just return the normal result code for a removed page, which could be a 410 or 404 error code. And show a user-friendly error page, at least, so that users are able to understand that this content no longer exists. But you definitely don't need to kind of do any fancy combination of meta tag and redirect. Already asked, posted my question on Webmaster Central. So I think this is the question about GDPR. One of the things in this question was that they show an interstitial instead of actual content for users who don't have a cookie. And from our point of view, if you show an interstitial instead of content, then Googlebot won't be able to crawl past that. So Googlebot won't click on any links on this page and kind of try to follow through. Instead, it will see this text that you're providing on this interstitial page, and will try to index that text because that's what you're providing to Googlebot. So that's probably not what you're trying to achieve. And from our point of view, there is no real way to both block the content completely and show all users an interstitial. There, what you could do is perhaps use JavaScript to show an interstitial overlay so that we can still find the full content. That might be an option there. But you can't both block the whole page and expect Googlebot to click through to actually get to content, and expect that Googlebot will be able to do that to index the final content instead of the interstitial content. Also, Googlebot won't keep a cookie. So even if we do click through once, that wouldn't mean that we'd be able to understand that we can serve this cookie and get to the rest of the content again over and over again. Let's see. What factors affect visibility in Google's local news? I don't know. Google News search is kind of separate from web search. So I don't really have any factors that you can look at specifically for Google News. Let's see, lots of questions here. mDot and mobile-first indexing plus hreflang, how do I fix that? If I point my mDot canonicals to itself as a documentation itself, I break the mDot link validation. Yes, with an mDot page and a rel canonical and the hreflang link, the hreflang link needs to be on the mDot page itself as well, and needs to be between mDot versions. So your desktop page points the hreflang at the other desktop pages for that set, and the mobile page points to other mobile pages of that hreflang set. So that's kind of the way that you set that up. You don't have to do anything special with regards to rel canonical or the rel alternate. You'd leave those links as they are. So the canonical would point to the desktop page, the alternate would point to the mobile page. But within the set of mobile pages and within the set of desktop pages, that's where you set up the hreflang. We also have that documented somewhere in our developer site, so I double check there if you need more information on how that might look. We have both the HTTP and HTTPS versions of a page where HTTPS was recently launched as a best approach to redirect all HTTP to HTTPS or can they coexist? What's your suggestion? So if you keep them separate so that they don't redirect, we'll index these as separate pages, which means we might pick up some as HTTP and some as HTTPS, maybe some as both versions depending on how you serve them. And that's probably not ideal. So I'd really recommend double checking our help center guidelines on moving to HTTPS, which includes setting up redirects from all of your HTTP pages to all of the HTTPS pages. That's what I'd recommend for change there. If we do mark this fixed in Search Console, is it also applicable to the new interface? I'm not seeing any change in the new Search Console. No, mark this fixed is only specific to the old interface. I believe it's only in crawl errors, and it's really only a change in the user interface in crawl errors. It doesn't change anything on our side on the back end. It doesn't re-crawl those pages or try them again. If you need to re-crawl pages, I would double check the new Search Console in the index. What is it, the indexing report, where when we spot issues there, there is a way to validate them, which means we'll go off and check a small sample of those pages fairly quickly to see if this problem is fixed. And if it looks like it's fixed, then we'll crawl the rest of the pages that are affected as quickly as possible. So that's what I'd recommend doing there. Does Googlebot recognize the data alt attribute on image tags as well as the alt text? No, we don't. So oftentimes, the data attributes are used for lazy loading or for giving other information for other scripts on images or other aspects. But we don't pick that up for indexing, neither for image search nor for web search. I'm looking at a site that seems to be generating infinite URLs when using URL parameters and scrolling on a blog page. How does Googlebot see this? And what effect does it have on my client's site? How would you recommend to resolve this? Yeah, so if it's really generating an infinite number of URLs, that would mean we'd try to crawl a lot of these URLs and it would probably kind of keep us in a loop and essentially keep us busy with all of these infinite URLs rather than actually focusing on the useful content on your page. So I'd recommend double checking our guidelines for things like infinite scroll to make sure that you're really only providing the URLs that are necessary to have the site crawl, and you're providing them in a reasonable way so that we can pick them up. If you're using URL parameters and those parameters include things like session IDs or kind of individual bookmarks essentially within a bigger piece of content, then you might want to look into the URL parameter handling tool, which lets you tell us that individual parameters are irrelevant for your website. But I'd first kind of double check how you have this implemented and what's actually happening on our side when it comes to crawling. Hi, John, I've got a little question related to the URL parameters. If I have the URL parameters in the site in which the canonical URL will change when the URL parameters change along with it. But if I go into search console in the URL parameter settings, I said a sophisticated URL parameter do not index. And which will search engine to pick up? Is it the canonical URL or the parameter settings in the search console? We see the URL parameter settings more as a kind of a signal for us, so we don't follow them blindly like we would with the robot sex form. But they are a pretty strong signal for us. So if you tell us that one URL has a rel canonical pointer to this particular URL and your URL parameter settings say, don't index any of these parameters, then probably we won't index them. It's possible there might be some kind of interstitial time until we process that. But for the most part, we probably wouldn't index those parameters. So I'd say the URL parameter setting is kind of a signal, but it's probably a stronger signal than the canonical would be. OK, OK, great. All right, what would your recommendation for FAQ pages on fairly low authority sites, having lots of thin content coming off of the main FAQ page versus one large comprehensive page? The latter would be better in terms of one having one authoritative resource, but for the user, we'll need to scroll a lot to find it. What are your thoughts? I think this is something I would totally test. So since you mentioned that the user might have to do a lot of work to get to the content, I would do a normal A-B test for your users to see which one they actually prefer. And it might be that they prefer a really long FAQ. It might be that they prefer having it split into chunks or maybe split into individual pages. I assume if you're putting just a short question and an answer on one particular page individually, then probably that's not really that interesting for users. So if you just have a really short question and answer, I'd at least make sure that you expand in the answer section to provide some more context around what this is, where this question comes from, what other types of questions might be out there that are kind of similar in that regard. But I would definitely test this with users to see what they would prefer. My question for today is in connection with the new GDPR, which comes into power this month, and the Google Analytics settings. Is there any chance you can clarify that the option in Google Analytics, what that means, and what will be changed? I don't have any insight into Google Analytics, so I can't really tell you what will change there. I'd contact the Google Analytics posts in their help form. I believe they have a help form specifically for Analytics and get their input there. Hey, John. Hi. We'll still receive Search Analytics on Search Console for EU sites post GDPR, correct? Yes. That's not tied to individual users. That's something where we have aggregate data that's in Search Console, so that wouldn't be affected from any of these changes. In the index coverage report, I see Google has crawled through the add to cart and removed from favorites, add to wishlist, and all these other links related to an e-commerce site. Search Console automatically excluded these links and listed them as pages with redirects, should I put in no follow on these links and spare Google from going through them? Any other advice to deal with these internal links? For example, my site has 11,000 index pages and 30,000 excluded ones as pages with redirects. It sounds like that's already fine. So if you're already redirecting from these pages to maybe back to the general version, then it sounds like we're already picking that up properly. What you might want to do is look into what these URLs look like and potentially use a URL parameter handling tool to let us know that these pages are not worth indexing or crawling. I wouldn't block them with robots text and, generally speaking, doing kind of page rank sculpting but putting no follow on these links internally generally doesn't have that much of an effect anyway. So in the worst case, I would just leave it like this. It's definitely not going to cause a problem. How do you decide what to pull in for featured snippets? Does Google only pull in info from sites with a high EAT? Not sure what that is. Or is it primarily judged on relevance to the query? We look at a number of factors when it comes to featured snippets. And a big part of that is really relevance to understand what we think makes sense to show to users for individual queries. I realize sometimes we get them wrong. Sometimes we have weird featured snippets. And it's really helpful for us to get examples of these so that we can pass them on to the team. But generally speaking, it's not the case that just because you have an important website that we're automatically including everything that you write as a featured snippet. Part of the pages of our site are not getting crawled. We tried copying the portion of text and searched on Google Search, but it's not showing our page. However, when I checked the cash result, Google is showing a page fine with a text present on the page. Is there any issue with crawling over pages? So I double-checked these links that you provided just before the Hangout, and it looks like we're indexing this page normally. So that text snippet that you link to shows that page actually index normally. One thing that might be happening here is that we have a number of different data centers worldwide. And sometimes, for mostly technical reasons, we don't have all pages in all indexes across all of these data centers. So if you check once, it might be you're checking one data center. If I check here, I might be checking a slightly different data center. And that could theoretically result in a difference in the results that we see. For the most part, this settles down fairly quickly. So I suspect if you check now or if you check tomorrow or so, then probably that page will be indexed just fine on your side as well. We often link to the same handful of sites because in entertainment reporting, there are thousands of outlets that are unreliable, while only three or four are actually trustworthy and have real access to celebrities. Can this repeated reliance on the same three or four legitimate sites falsely be construed as part of a link fund? No, that's perfectly fine.  It's not something that we would see as something negative. A lot of sites link, for example, to Wikipedia or to other authoritative resources. It might not link to lower quality or random blogs that they also have on the same topic. And that's perfectly fine. That's the way that the web works. We don't use these links in a way that we say, oh, this site is linking to an authoritative resource. Therefore, it must be a good site as well. We kind of evaluate the site on its own without just looking at the links that it has there. So one really common kind of spammy technique from, I don't know, 10, 15 years ago was to link to sites like Wikipedia or Google or CNN.  So therefore, it must be a legitimate site. And that's something that I think all search engines realize in the meantime that just because it's linking to a good site doesn't make that content good. There's actually a second part of this question, which is, OK, go for it. So the problem sort of in my industry is the more outrageous or untrue story is the more likely that that story is going to accrue links very quickly, because it's easier for sites that don't fact check or unreliable sites to just link. They feel they're also indemnified legally. And of course, it's more interesting to read an outrageous story than it is the truth. The prompt for us historically has been for the last almost decade that we've been in businesses. After we correct the story, it's not that sexy or interesting to link to the correction. Is that a problem for us? Because sometimes we find it a little hard for us to rise to top stories and combat the fake made up story. For the most part, that shouldn't be a problem. So we look at more than just the number of links to a page. We try to understand the quality and the quantity of the links there when we evaluate the links going to a page. So for the most part, I think we would probably get that right. I think it's always kind of a tricky situation to be in, though, just because the nature of these, like you said, outrageous claims where people are like, oh, look at this thing. You won't believe it and then link to it. Whereas if it's like, oh, this is actually not true, nothing crazy is happening here, then nobody really cares. But for the most part, I think we would be getting that right. And we don't take things into account like social signals. So if someone is sharing these things on Facebook or Twitter, then those would be no follow links anyway. And we wouldn't take that into account. So I think, for the most part, at least from the linking side, we should be picking that up properly. I think there's always something to be done with regards to better understanding what a page is about and how it's relevant, which can be tricky as well, especially when you have a topic where essentially there is nothing amazing to say other than, well, I don't know. They're not aliens and living on the moon. It's like they're just normal people. That's really hard for us sometimes to figure out how we should be showing this in the search results when someone is searching for something like, is this person an alien? You're like, well, no, they live here in New Jersey. That's always tricky. But I do know there are a number of people on our side that are looking into this problem to try to figure out how to better catch this situation and how to surface the legitimate or correct sites a little bit better. Well, from our side, within the body of the text, we link to third-party published documentation that shows that the claim is not true. And then beneath each story, we list loads and loads of sources that prove if it says someone is pregnant. Obviously, their doctor is not going to say it publicly, but we have found that there are publicly available ways, in addition to a spokesperson, to prove that that claim is untrue. And we list that underneath each story. That sounds pretty good. Yeah. I know you've been struggling with this. So we do talk to the team about to see what we can do to make that a little bit better. I think it's a tricky niche that you're in, especially because of all of these crazy stories that are happening all the time. But we'll try to see what we can do to make that a little bit easier or reasonable in the search results, I guess. I truly appreciate that. Thank you. Thanks. Hey, John. Yeah. So I have two questions for you. The first one is about the minified JavaScripts and CSS files. I have a project now where when I minify them, it's totally broken. How much important is that for Google? My first question. It depends on what you're doing in the JavaScript. If the JavaScript is important for the page to load, if the content isn't on the page without processing the JavaScript, then, of course, we wouldn't have the content. But if it's just some random JavaScript that you don't really need to view the page, then maybe it doesn't really matter. And my second one is about the external links on our pages. Actually, do they have an impact? Or the internal links are more important? We use both when it comes to search. So we try to understand how the site fits in within the context of the rest of the web and within the context of your website. So is there a kind of signal for Google for relevancy? To some extent, yeah. I mean, it really depends on the site and the queries and things like that. But it is something that we use in some of our algorithms to understand where we should start crawling, to discover new pages, to understand which pages need to be crawled more frequently, those kind of things. So not every time for relevancy, but we can keep it in mind that they could be used for better relevancy. Yeah, I mean, we try to understand which pages are relevant within the context of the rest of the web, like how it's being linked, how it's understood by other sites. Thank you, thank you. Sure. Let's see. Here's a question. Again, with Angular, we have a bunch of product pages that are built with Angular with the hash in the URL, so the number sign that are never indexed in Google. For example, site.com slash category and then hash product one. Will removing the hash from these Angular pages make these pages indexable, or would you recommend using pre-render or some alternative? Yes, you need to remove the hash from the URLs. We essentially drop everything after the hash sign when we see a URL like that in reference within your website. And we'll try to crawl the page without that hash part. So if you want these pages to be indexed individually, you need to make sure that you're using natural URLs to let us know about the pages so that we can crawl them and actually try to index them directly. It's not always necessary to pre-render those pages. And using a pre-render service doesn't necessarily get rid of this hash in the URL. So as a first step, I'd really recommend removing the hash. We did a session on JavaScript sites and search at Google I.O. last week. I'd recommend taking a look at that. That also covers this very briefly. My question is about embedding YouTube videos on our page. Is this going to be an issue with the data protection thing, or even an advanced mode? So I don't know about the advanced mode. And as far as I know, I don't expect this to have any kind of effect otherwise with regards to data protection, because it's a YouTube video. It's not something crazy. But that's it. I don't know the details, actually, there. So I'd recommend double checking with the YouTube forum on this. I believe they have a normal help forum where a lot of the top contributors are active as well. And probably they have a bit more information on that topic in particular. It's more of an issue with regards to what YouTube does and with regards to what search does. From the search point of view, we would look at this page and just see that there's a video embedded. And we would show that in the search results. I'm not sure if the fact that it comes from YouTube or that it's served via YouTube, if that plays a role in any of the kind of data protection guidelines on your side. So I'd double check with the YouTube team instead. We're a university, and we own several different domain names. We have our main website, but we also have websites for athletics, a university store, et cetera. They're all on separate domains as opposed to subdomains, or a main domain. Can Google tell that these domains are related? Could the athletics or store domains affect the SEO of our main domain? For the most part, we can probably figure out that these are related. But I don't think we do anything special in search in that regard. So if someone is searching for your university's athletics department, we'll try to show that site. And that's usually something we'd be able to pick up on directly as well. So regardless of subdomain or separate domain, we should be able to understand that. Usually what happens in practice is that you link between these different sites anyway, that you link to maybe the main university site. From there, you link to the university store, or the athletics departments, or other departments. And that way, we understand that these are all kind of related. And that helps us to better put things in context a bit. And usually, that's enough for us to kind of understand how these belong together. How does Google see near me searches? Does it simply bring results based on location, or is there something that we should be doing to ensure that our sites are appearing when a user completes a search, whether that be by voice or text? So as far as I know, we mostly look at this with regards to location. So doing things like adding, I don't know, pizzeria near me as a title of your pages on your website probably doesn't make that much sense, because we would try to figure out what is actually near the user. So in order for us to be able to figure that out properly, there are two things that you can do. One is, obviously, put your address on your website and to mark that up appropriately with structured data so that we understand where your location is. The other is to set up a Google My Business local listing so that we know where your business is located and can connect that to your website as well. So that's kind of the two things I would look at there. Could you give guidelines on how to make lazy loaded images available for crawling? And also like responsive source set. We have some of that information in the Google IOTalk that I mentioned for JavaScript sites as well. So I double-checked that. In particular, for lazy loading, we recommend using a NoScript tag after your kind of lazy loaded image element and letting us know about it like that or by using schema.org's structured data on the page if that's something that can be marked up with an image directly within the structured data so that we can pick that up. And within the structured data, you can also specify a set of images which we'll be able to look at as a set as well. So that would cover the source set responsive side as well. We need to document this on our side to make it all a little bit easier to find and digest. We'll be doing that, I guess, over the coming weeks or so. Can I follow up on that? I am definitely not the technical guy, but I did watch some of those videos from Google IOT and much was talked about JavaScript. Because I'm not the technical guy, I asked my developers and I said, oh, do we need to migrate our stuff to JavaScript? And I was sort of told, no, you don't really have to. Is that accurate or should I press upon them a little more? No, that's correct. The JavaScript part is particularly with regard to sites that are already built purely on JavaScript and guidelines for how to make that available for search in an optimal way. But if your site isn't built on JavaScript like that, then that's perfectly fine. In particular, some of the newer frameworks and development environments, they focus a lot on JavaScript to improve the speed and improve the development cycle. So that's kind of where we're targeting there. All right, looks like we just have a couple minutes left. So maybe I'll just open up to any questions from your side. What else should we cover? Answered all questions. Oh, there's one in chat. I've seen a lot of answers from people also ask that are localized to the US rather than to my location in the UK. The feedback doesn't seem to be acted upon. Is there a better way to report this? One thing you can do is maybe send me examples so that I can take a look at that to see what's kind of going wrong on our side, how we can handle that better. I suspect with newer search elements, like the people also ask feature, that's something where maybe there are things we can improve, especially with regards to localization, when it comes to things like both pages are in English, but one is for the UK and one is for the US, which one do we actually show, those kind of things. But if you can send me specific queries and screenshots that goes a long way to reaching the team and helping them understand the problem. Cool. Otherwise, I'll grab another one from the list here. One of our affiliate websites is over a one-year-old now and started to grow slowly. We're getting around 100, 150 organic traffic from Google before traffic started to drop from 13 to 14 in December, never recovered fully yet. We tried doing everything on the site, on-page audit to content update tweaking, to links removal, but nothing helped to get a rank back. What should we be doing to get a rank back? I don't think there's a magic solution to getting your ranking back. Sometimes things are not side change with regards to our algorithms. Sometimes things on our side change in the sense that we reevaluate your website. We think maybe it's not as relevant as we thought initially. So especially since you call out it's an affiliate site right in the beginning, I'm kind of worried that this is primarily an affiliate site. And maybe there are lots of other affiliate sites in that area, or there's the original sources where you're an affiliate of, which are also available in that area. And from our point of view, it might not make sense to show all of these different affiliates if they're not providing significant, unique, and compelling value. So that's one thing where I try to take a step back and think about what you could do to kind of really provide more than an affiliate site and rather to provide something that's really fantastic and awesome, that answers people's questions, gives them a lot of value. That's something that they would refer to directly rather than to kind of the target site of whatever you're kind of selling as an affiliate. So that would be my advice there. I realize it would be nice to have a meta tag, because like, give me the rankings from last December, but that's not going to happen. There is no simple technical change that you can do on any site to kind of like say, take me back to the search results from some time in the past when I was doing better. So that's something where you just have to kind of bite the bullet and try to work on the site. All right, looks like we made it to the end. I see there are still a ton of questions that were submitted. So I'll try to double check to make sure that I'm not missing anything critical and maybe add a comment in the Google Plus post if I need to. Otherwise, if there's something on your mind that you'd like to get more information on, I'd recommend going to the Webmaster Help Forum. There are lots of really smart and friendly people there that can help you kind of get started on a problem. Alternately, we're doing more of these Hangouts, so feel free to join in on one of the future Hangouts or drop your questions there. Thanks, everyone, for joining. And I wish you all a great day. Bye, everyone. Thank you, Jim. Bye-bye. Bye.


Al Jazeera reports that at least four people have been killed and several more injured in a suspected U.S. drone attack on a house in Pakistan's northwest. Pakistani intelligence officials say the missile strike targeted a hideout of anti-government fighters in the Babar-Ragazi area of North Waziristan last weekend. But local security officials told Al Jazeera that those killed in the attack were all civilians. Unmanned drones are often the weapon of choice for the United States as it targets Taliban fighters in remote rugged areas along Pakistan's border with Afghanistan. But the U.S. military has rarely confirmed the attacks. The use of so-called unmanned aerial vehicles is expected to grow in the coming years, with the U.S. military expected to buy 700 drones next year alone. The long-distance remote-controlled warfare influx heavy civilian casualties and has sparked significant public anger in Pakistan. Senior U.S. officials are now pushing to expand CIA drone strikes beyond Pakistan's trial region and into the city of Kedah. Kedah is a major city in Pakistan, home to 850,000 people.


Hey guys, Ken Ross here, and I'm a business consultant that specializes in reducing costs for businesses by looking at their essential expenses And today boy am I excited today because yesterday I got to watch the WWDC from Apple and I'm sure if you're a developer like me or a former developer like me somebody who's really in the IT It's something you want to check out regardless of if you like Apple or regardless if you are really into technology all that much anymore Because honestly they get into some really good details about their enhancements and software and they also made some great Announcements about their hardware and their move to the new M2 processors. It's something that's very exciting I know a lot of folks are really excited and been anticipating these announcements for quite some time I know I'm pretty excited about M2. Just like pretty much anyone else These days Apple announced two brand new Macs the redefined MacBook Air and like four different colors, which is Outrageous and the 13 inch MacBook Pro with M2. Now. It's just really the M1 Upgraded because they took the old platform and they put the M2 in it So there's really not much of a difference there. I know for you I know this may not be something that necessarily is relevant like hey as a business I'm not looking to upgrade all my computers But I'm paying attention to those things and the reason I pay attention to those things is because I said before I look at the specifications and let me tell you a little bit about what I found and so to get really into it what I am Really paying attention to when I when I think about businesses and when I think about what it is that I do for businesses I look at what types of hardware they put into these machines and one of those things that I'm very much looking for is Wi-Fi 6e not Wi-Fi 6 Wi-Fi 6e and let me tell you why because 6e Unlike just standard Wi-Fi 6 is the next generation of wireless technology for your home Most people they have wireless internet in their home and if they don't well get with it It's the 2020s right we've had it for quite some time But Wi-Fi 6e is supposed to in some sense level the playing field when it comes to wireless providers internet service providers such as cost communication and century link and spectrum all those places and your and your wireless carriers like Verizon Sprint AT&T Offering wireless internet in your home. You've been following this channel at all and you've been listening to anything I've said 5g is coming to your home 5g is already in your home if you wanted it to be because you could invest in it It's something that during the big game and I mentioned this in one of my videos I'll put it put the link up there in the top here. They are Investing in your home. They want you to buy 5g and put it in your house why because they can offer the same speeds if not better speeds than wireless and Wireless carriers want to do that. They want you to have I say brand loyalty in some sense They want to offer you something that they couldn't offer you before which is gig speeds in your home as well as a Cell phone plan that you can use while you're out. You'd have the same coverage inside as you would outside You'd have gig speeds on your phone as well as all your devices in your house Because not only would the the 5g allow for gig speeds to your phones But to all your wireless devices inside your house as it offers the Wi-Fi in your house You'll be able to use it and the reason you can do that is because of Wi-Fi in your home Right Wi-Fi 6 in your home Wi-Fi 6 e is going to give Internet service providers the ability To do some of those same things Inside your home at a much faster rate So you're gonna have this competition of sorts and I I have some I have a link to a resource that I got from Samsung that talks about the various differences between 5g and 6e but let me give you some of the highlights in general 5g and 6e It's gonna be kind of hard for me to do this all day But 5g and 6e they both offer millimeter wave technology They're both also Tapping into new spectrums that the FCC is allowed for 6e is going to open up the six gigahertz spectrum Right, and I've already talked about 5g and how there's many different bands with those upper bands or where ultra wide band and all of their gig speed Advertising that's where they're gonna be able to offer you those types of speeds Not only in your home, but out when you're out and about using your cell phone That is one of the major things that both technologies will offer the other thing They'll also offer is enhanced security now with 6e they are going to open up the new version of WPA WPA version 3 If you're familiar with any of these technical terms Wireless standards for security has changed over the years many different times But WPA is the is the standard that that pretty much everyone follows and is stood the test time over time The original wireless standard actually was invented by Texas Instruments, and it wasn't a very good standard So WPA is the standard and we're on version 3 now So that is the enhanced security and Wi-Fi that's also being offered in Wi-Fi version 6e The other thing that they're going to offer and I've already kind of hinted at it Both 5g and 6e they're both offering over one gig speeds. They advertise it all the time When you talk about Verizon and AT&T and T-Mobile, they're offering Gig speeds to your devices and with 6e there's no exceptions the same thing It's going to be offering the same very fast wireless connection that you would have from a mobile device and You should be able to stream Netflix and who no problem to any of your devices inside your home So that is something as a business owner when you think about businesses that you have to consider Right is this something worth investing in is this something to keep track of because I'm keeping track of it I'm looking at every device that's coming out now, and I'm saying to myself Do I want to over invest in the older technologies or What is the newer technology is going to offer me and how do I position myself so that I can take advantage of them This is something that you should be really thinking about When these types of announcements come out because what you didn't find in the devices that Apple released today is Wi-Fi 6e They're still giving out devices that just have standard Wi-Fi 6 and not to say Wi-Fi 6 isn't a good standard Not to say it's something that you shouldn't invest in It's just not going to be the latest standard. And what is that going to do down the road? That means Apple has to then release or they're going to at some time in the future release 6e capable devices Apple is out to continue to revolutionize the way we think about Computing about devices in general and I think if you're paying attention You'll understand that they know just as much as we should know Where the market is going what people are willing to invest in right now? And where you should go because something like Wi-Fi 6e is still in its infancy just like 5g but at some point We're gonna have to make a choice or we're gonna have to understand what choices we have and I think that's something that At least at this time is valuable. It's something to definitely find value and understanding and learning So please check out some of the resources I have in the comments section below about these two things I really do think As a business owner as somebody who really follows technology is something you should look at and Also, take a look at couple a couple of my other videos where I talk about 5g Understand kind of what 5g is because I really think it's here to stay in and stay tuned because I am gonna get a Little bit more in detail about Wi-Fi 6 6e because I really think that's something else I could spend some time in doing and helping you understand because Like I said, it's gonna level the playing field It's gonna make it so that telecommunications providers and internet service providers have Very equal opportunity in your home very equal opportunity in your business and saying hey I want to offer you a replacement to your ISP and you're gonna say what why would you want to do that? They want that business as well. They want to offer you every solution that they can so with that That's what I have for today Really appreciate your time And for you to take taking the time out to check out these videos Tell me what you think about the Apple announcements if you're into that thing into that sort of thing And tell me what you think about 5g and 6e 6e. It's it's something. I really think it's interesting Tell me what else you'd like me to talk about. I know I spend a little bit of time doing research On topics that I love, but I'd love to do research on topics that my viewers love So if you're watching this video, you have every right to say hey, why don't you talk about this next? I'd really love to hear about that Like and share this video with others subscribe to my channel if you haven't already Check out my website. I am Ken Ross calm until next time. I'll see you around