 OK, welcome, everyone, to today's Webmaster Central Office Hours Hangouts. Today, we're actually in an office with a bunch of people hanging out, bunch of fantastic SEOs who dropped by in Mountain View to join us live, and a handful of you also online, which is probably because the time is so different than all of the usual hangouts, so everyone is confused. But that's fine. I am N. John Mueller. I am a Webmaster Trends Analyst at Google in Switzerland. And I don't know, if any of you want to introduce yourself, should we do a quick round or, I mean, no pressure? All right, my name is Dan Jehant. I'm an independent SEO consultant. I work out of Melo Park, California. My name is Josh Rubin. I own a digital firm in Sacramento, California. Hey, guys, my name is Aldrich. I work in Google, doing such outreach for Indonesia. My name is Martin Splitt. I am a Webmaster Trends Analyst on John's team. And I usually work out of the Zurich office, but I'm here for a bunch of events, including Chrome Dev Summit in a few weeks. One week, oh, it's time. Ready? I'm done. Sorry, my name is Martin McDonald, a longtime SEO former SEO for various travel companies, like Expedia, Orbitz, part of that agency, World of Unicorn. I'm now an independent consultant as well. Hey, guys, Shadow Keep. I'm here at Google. I work as a data scientist in the ads marketing department. Drill Cronrod, I am an SEO at Adobe, SEO site search. So search related stuff. Hi, I'm Julia. I had SEO ads as a small business insurance broker company in Shurion, the kayak of small business insurance, formerly with Adobe, spent there five years, but recently changed to a new company. Cool. Awesome. Do you two want to introduce yourselves, or do you prefer to stay? OK, hi, everyone. My name is Nick. I work in a web-published programmer called Meds.com. And I'm the CEO of Stingermanitor, and I'm the CEO of Stingermanitor. Cool. All right. So Martin and Aldrich have to run off soon, but there are people for JavaScript questions. If any of you have JavaScript questions, feel free to throw them at Martin now. He's the man. Well, that's not that much. My dev team just recently asked me, they are redesigning our mega manual global app, whatever you call it, and they were asking, how much of it would it be possible to do client-side, or would it be best for SEO to have a different approach? So generally speaking, using client-side rendering is not an issue. The only thing that you might find is if you have content that changes really fast, and then the sense of like, if you have a high change frequency, or your site is really large, or both, then that might lead to delays in getting that index and update it. So if a little bit of a lag is fine, then you should be fine. If not, then you might want to have a look at dynamic rendering. Also, we have documentation on that that basically went live, I think, three weeks ago. So it's a relatively new documentation. John presented it at I.O. Now we have documentation available on it as well. You should also never forget that client-side rendering can come with a user experience issue, or can come at a cost for your users, especially if you look at mobile users and networks that are not as stable and fast. So SEO-wise, you're fine. But definitely do very thorough testing on how the user experience looks like and how well it works if things are breaking. What they might want to consider is they might want to, if they want to use, so it depends on what the reason is for doing that. If you say, oh, we have a bunch of infrastructure in place to do client-side stuff, and we want to use this in this part of our site as well, that's a good reason. But then you might want to have a look at hybrid rendering or server-side rendering, because you can use the same technology. But not entirely rendered on the client-side, which brings you into a nice position, because that means that crawlers that do not support JavaScript can use it. And users get the content faster, which is something that you generally always want. More content faster to the user. So JavaScript can get in the way of that. That might be a challenge or an issue. SEO-wise, especially for Google, you're mostly fine. For other crawlers, you might see issues. My being wouldn't. Being, I think right now is one of them that doesn't execute JavaScript as far as I'm aware. They're not really very public about it, as far as I can tell. But one that is absolutely public about it is Facebook and Twitter. If you want to use open-graph tags or something like that, that does not work if it's client-side rendering. They do not execute JavaScript. So if you're relying on open-graph markup or these nice little cards that appear when you post a link to Twitter, that content has to be server-side rendered. For dynamically rendered, that's not a possibility. Thank you. All right. Other JavaScript questions? I have a good JavaScript question. So we use Adobe Target to do testing, and we have Mboxes. And I don't think we ever had issues with that, but you know which parts of the testing scripts took more, so that we never run into the flags that spam it from. I'll leave on its disallowed on the commit side. Oh, they aren't disallowed? OK. Yeah, disallowed. OK, cool. Not better. OK, OK. Thank you. Thanks. But if it was open, then they would probably be wrong. Yeah. I think if it's a JavaScript type redirect, and we can call it, then it's a redirect. But if it's blocked, then we don't do anything with it. Yeah. I had issues years ago, so not currently, where we had the relative URLs in JavaScript on pages at Adobe, actually. And Google tried to crawl it and throw 4.4, because it couldn't figure out the path. And so you can definitely open JavaScript, and it could be tricky. Yeah, no, that should not be a problem. It's a redirect, and you just use it as such. Got it. Thank you. There's a question here that was submitted. Also, dynamic rendering. They have an e-commerce site, and the products are changing rapidly, and are lazy loaded with JavaScript scrolling events. Oh. So what about lazy loaded scrolling stuff, Martin? That's fantastic timing. I love how well people are. I kind of feel like some people might know things that we haven't put out yet. So we're working on better guidance for lazy loading. We're not having the documents ready yet, but we want to publish these as soon as possible. So latest at Chrome Dev Summit, there will be more guidance on lazy loading. But generally speaking, just make sure and test really, really carefully that if your content becomes visible in the viewport, it should be fine. Reliable scrolling alone is not a good strategy for two reasons. Scroll events are three reasons. Scroll events are really expensive is one reason. The second reason why scroll events might be sufficient is that people on desktop might just resize their window. That does not trigger a scroll event. So if I have a tiny window and a lot of people keep forgetting that, but there is a bunch of people who watch Soap Opera's while they're working, and then they have only half of the screen in their browser or top half or whatever, and then they might resize the window. That does not trigger a scroll event, but that does trigger a resize event. So if you're only relying on scroll events, you're missing out on these moments when content should become visible, but it doesn't. So if the solution is only using scroll events, that's not a good solution. Third and last important piece is what was the other thing about scroll events? Oh, we are not doing it. We're not scrolling. We're doing something slightly different, but basically the browser will know that things are becoming visible, and if they are visible, you should load the content that you have hidden behind lazy loading. There's a bunch of ways of doing that. One way of doing it is making sure that your library works well with Petch and Renderer. Another possibility of doing that is making sure that you're using something like Intersection Observer. Intersection Observer is specifically designed to be efficient and working with these kind of scenarios, or you can always, if possible, you can always try to have links to the content or the content itself in NoScript tags that works as well. That should also then show up. But more detailed guidance coming up. So if the stuff is changing quickly, should they just implement the JavaScript correctly, or should they dynamic rendering? So if stuff changes frequently, as they said, then I would say dynamic rendering is the right workaround right now. And again, you might consider general user experience there. It's not just an SEO thing. It is, you wanna make sure that the users get the content as quickly as possible. So dynamic rendering or hybrid rendering or server-side rendering are solutions that I would look into. Cool. All right. Any other JavaScript questions from you? I've got a couple. So the first one wasn't really a specific question. It's kind of a Google question that comes from the world champion of SEO, the 27th Secretary, Mr. Thomas. Do Google. Now, obviously you can comment on your future plans, but I would be very interested to find out if this is the kind of thing that you can see might be useful. Would you concede that it might be useful in that case? For us webmasters to have some form of directive like a robots.txt edition or the ability to place data in meta tags or the site map telling Google explicitly not to bother rendering JavaScript on a specific page, section of a page, section of a site wherever it may be, simply because it's not involved in the rendering contents of the page. Therefore, we have no interest in you guys necessarily rolling everything and extending both of our process cycles. So, I don't know, is the short answer, the slightly longer answer to that question is there's a bunch of heuristics already in place and the rendering in general is like a really interesting and involved process. I literally today saw a diagram that I'm still processing. It is quite a bunch of stuff happening there and it's really hard. It would actually, it might sound counterintuitive but it would cause more complexity to not execute upper script sometimes. So, I don't think that's gonna happen or that's necessarily something that we're looking into because of the way that the web's moving right now and direction that the web is moving into and also it's not necessarily about JavaScript that makes rendering expensive. JavaScript can definitely contribute a lot to the cost but does not necessarily contribute all the costs. And if your stuff works great for users, it will work great for rendering, hopefully, as well. And the bigger issue comes from the fact that there's a gap between what modern browsers do and what Google Cloud does right now. We're working on closing this gap sustainably. So, it's not a catch-up game right now. It's gonna be, we're taking longer to make sure that in the longer run we are more up to speed and that's gonna give us a bunch of improvements in terms of performance and rendering cost as well. Generally speaking, you don't have to worry about these kind of things. That's our job and we're trying our best to make it happen. It's very nice if people wanna spare us computing cycles but it will actually add to more overhead and complexity right now. So, the way that it's structured wouldn't buy us much. Fair enough, thank you for the great answer. Thank you. I had a follow-up question, if I may. Which is actually originates from Cindy Cromwood, Mobile Moxie, which is, there was all the advice regarding, so this is at the intersection between page speed and rendering of contents. So, the old advice was to have important JavaScript and CSS inlined in the head that would require the page rendering. We're at the intersection here between slowing the page down and Google being able to render it. Is there a change to the current advice? I would definitely say that if your JavaScript is critical to rendering the page, definitely not put it in the head anymore because that is definitely gonna block you. Use dynamic rendering instead, as opposed to workaround or even better, use a server-side rendering because that's improving or hybrid rendering if it has to be because that's improving the user experience as well. Because generally speaking, if it's like super small, tiny JavaScript in the head, that's fine. But, then it's not critical for the rendering of the pages. It's small and trivial. So everything that is large enough to be critical for rendering the page is also gonna be horrifically bad for users on mobile, generally speaking, because it has to be downloaded first. And what's even worse on mobile, especially on reference phones, which are not phones that we are using probably. It's like the sub $100 phones. What makes JavaScript particularly expensive is it has to be parsed, it has to be compiled, and then it has to be executed. That's a lot of strain on the CPUs and these mobile CPUs are not very good at it. So if you do that, and it's a non-trivial amount, and when I say non-trivial amount, it's basically everything above 10 kilobytes, I would say, which is reasonable for something that is render blocking. Then it's gonna put a lot of strain and stress on the CPU and block rendering for a long time. So it hurts your users. Again, JavaScript not being a search issue, JavaScript being a usability or user experience issue here. So I would say try to get as much content as possible without JavaScript to your users as quickly as possible. Thank you very much. You're welcome. So things like HTTP2 would not solve the difference in line as well. It doesn't solve it even if it's not in line because we still have the parsed, compiled, execute steps, and those are the expensive ones. The transfer is, so if you have 100 kilobytes of images and 100 kilobytes of JavaScript, they're not the same. They're not equal. The JavaScript is a bigger problem than the image, because exactly the image can be, basically as it comes in, it can be streamed by a specific specialized hardware, which even most phones have on their systems. Which is separate, don't you think? Exactly, like that's easy, but the JavaScript that's gonna be rough, hard on this one, especially on older mobile CPUs. That might change with new CPUs coming to mobile, but unless they magically penetrate the market in the next year, this guidance is gonna stay the same for a few years. Cool. I thought you had a good question. So, I forgot what the answer is. This is somewhat related, maybe tertiary or entry level, but what's the best practice for third-party scripts that you have to load on a page? For instance, you're a company that has badges or tracking or things. What's the best practice for you guys for call build? Because those are the things that drive us webmasters, nightmares, and our page speed scores, right? Yeah, I was about to say, it's good that you specify that you have to load because my answer would have been don't load them. Oh yeah, yeah. Make it enough. For third-party scripts, so I think we are pretty good at not patching those, especially if it's like something like, Google AD testing stuff or analytics or something, then we just don't use them for rendering because they're, they're not useful for us in this case. On that topic, can you have a word with the page meeting and ask them to remove the page with recommendations for that specifically? Because I'm sure that causes everyone on this route on our side quite a lot of problems. It's only, it's only take manager and analytics. Stop penalizing me. Yeah, yeah. But yeah, for third-party, I mean, a lot of them do require, you know, it does require for some rendering and whatnot. So we'll do the best practice for, for to tip those away. I don't know if we have specific. I mean, part of that is also what, what happens in there and with that. If they end up not rendering anything, then like worst case, we'll spend some time and try to parse the JavaScript, but it doesn't change anything. Can we add them in robots? Like if we have a known list of things, that's what he was referring to earlier. If it's not on your site, then yeah, you can. I mean, I think the answer there was, was with regards to the rendering of the content, though, isn't it? Is your question more around, around what we do with this because we're being told to remove them for page speed reasons, but we have no ability to do so. So the question is more of a page speed woman or rendering one if I'm correct. Now, but that's something like, people come to us all the time with this and like, oh, come on, it's a Google script. You should just like, like, don't tell people that it's flat, it's bad. But from, from like a more philosophical point of view, if it's slowing a page down, we should flag that. Regardless if it's, if it comes from search console. It's also just a technical limitation. It's really hard to say which script does actually affect rendering and which does not. And not in the sense of, for us in search rendering, that's completely whatever. But for page speed, it is unclear which script contributes what to the page. And there's no easy way of figuring that one out unless you would go and like basically toggle off each of them and do a visual dip, which is ridiculously and prohibitively expensive. So just, it's a, it's a, it's a philosophical issue of trying to break down something as complex as page speed into a number or a score. So I would say like, if that's the only thing that drags your score down, you will probably find. Because I would take a bet that in 90% of the cases is not the only thing that drags your score down. I think it's also a matter of interpreting the results. Like you have to take these tools, but you have to know what they're actually showing. And if you just take that number and you say, oh, I need to tweak this number, then it's like you will end up with an empty page because that's like a perfect speed score. But it doesn't help you. You have to figure out like what, what the right balance is between making changes that work for your site, for your users, and making changes just for a tool that ultimately users are not gonna look at the page speed score and say, oh, this is a good site. I'm gonna buy something from it. Because it's page speed 95. They have other metrics. But what we're looking at is how fast people start seeing something, a logo. A good example would be your font. We had some content. So we're focusing on this, not overall page will speak. Is this the right strategy? No offense to Adobe, but your font scripts, man. They're killing me. They're killing me. When my client's like, we have to use this font. Why? Can we kill recording for a second? That's what we've been discussing for weeks. You know, pages 3.2 megabyte and 1.1 over this font. Yeah. Yeah. Yeah. No, that's very important. But let me just take a quick break to let Martin Aldrich go, if you're okay. Is that good? Thank you for joining. Thanks for all of us. There was a follow-up question. Like a quick one. So for example, if we convert a bunch of HTML links into a drop-down menu with a selector and go to this list of states, instead of listing all 50 on the page, we have a select requirements in your state, go to serial requirements button. Would it break anything? Is it wise? Would you be still be able to parse those links as normal links to the deeper pages of the site? Would it hurt rankings of deeper pages? I guess the short answer to that is if it should be a link, it is no longer a link, then that's not good. So I wasn't afraid, oh. I mean, especially the drop-down stuff, we try to figure that out. But there's like one hack you can do is in your JavaScript, you have the full URL. And if we look at the JavaScript code and we see a full URL, we'll go, this is probably a URL that's supposed to be linked and we'll try to follow that. It's still not the same as a normal HTML link because we can't really crawl it, but we can discover those URLs and pick them up. Also, if it's, so this is not a ranking issue, this is a discovery ability issue. So if you have a finite state set, like in the sense of like, select your US state for seeing something further on, and put them in the site maps, like have a URL. Well, site maps will have them, for sure. But otherwise, they wouldn't be linked within the site architecture. Is there a reason to do it in JavaScript specifically as opposed to... It's a kind of UX point of view that's listing 15 links with names of the states. You can do that with CSS. I was about to say, if we pull out the UX card, then we do not use the dropdown and do not use JavaScript to CSS to make it look different. That's totally possible. So like a good developer can fix that. But the use case for using, correct me if I'm wrong, the use case for using JavaScript here must be to display the local links to where you are, right? These are your local cities, and it's pulling in geo-coordinates and then just playing the use in JavaScript. But that, I mean, that's... So depending on where you're calling from, you're gonna see different content that is executed for you. No, that's... It's just a plain... I think that's like the next level. I think they're just trying to use the scripted mega-menu, really. I will just do it in Snorlax, CSS. And the CSS would be... I mean, even animation and stuff is... Like a lot of people prefer the JavaScript because of animation and effects or things like that for that menu, you can achieve all that through CSS. It would look like it dropped down the same way. Oh, absolutely. Yeah, so basically, the advice here is to implement it in CSS and not just... CSS, HTML, like you said. Because then the content is all there, right away. And the links would have title attributes as well, if you want. If you want, yeah, it's just an HTML. You would basically not change the HTML, you would just change the presentation. That's the beauty of the web that you have. HTML, which is the content. CSS, which is the presentation. And then JavaScript, which is magic and unicorns. Do not refer to magic and unicorns until you really have to. Because with magic and unicorns, comes a lot of radio, nuclear, active waste, and you don't want to touch that stuff. And they're likely doing what you guys are to become ending because I haven't seen it yet. I told them make it crawlable so that Google can find the links. It's just I need to know. If it's in the HTML, and if it's proper links, it has to be h tags, a tag, sorry, a tag for the h rep. Like make it proper links. Do not, like a bunch of developers then call for tools that use spans or divs and on click handlers, eh, bad idea. That's good. On click, bad for links. Write that down. Well, careful. I, you quoted it. It's on YouTube later. I'm gonna record. That was all right. Hags and h reps. Those are the important bits. So the net of all that is the advice from the JavaScript rendering guru at WebmasterTrends is just not to use JavaScript. Use JavaScript, use JavaScript where it makes sense. And if there is a solution in CSS or HTML, use that. I'm just going to try this, please. Yeah, just, yeah. You're just like, let, Ram, it's like weighing me into saying the right things. That's wonderful. Do not. Make it budget for an assistant. Do you know anything about Google images? Are these JavaScript things? Oh, that time of the day already. Oh. Yeah. I think we have to let Martin and Aldrich go first. For the images, I don't know that much. I haven't touched that much. They kind of just, like, suck scripts, right? So within Google images or? Yeah, Google images. I was wondering how Google interprets the data in Google images that is used to build. I don't think we crawl Google images, no. Let's go ahead. But, I mean, Google images is based on images that we've crawled from Web pages. Yeah, so what we're just displaying, so. Google images is the way to build images, like charts. Give Google charts. Sorry, not Google charts. Google charts, I mean, Google charts. Oh, no, we don't pull out data from, like, graphs and charts and things like that. So sometimes we can recognize text and images. So the best way is to provide commentary, like captions and explanations of what you are seeing, actually. Exactly. So if you have, like, a world map and you have different locations, and it's, like, there's 55 here and 25 here, then we're not going to know that this number refers to that location. In a way, the script looks, it doesn't make me, like, understand which number it belongs to, which country or, yeah. Exactly, yeah. All right. Thanks. I think we'll finally thank you. Thank you so much. Thank you so much, Mike. Thank you very much. I appreciate it. Thank you so much. I appreciate it. I'll let him stay in my life in all the problems. So you'll see more of Martin at Chrome Dev Summit, if any of you all would go. Oh, you mentioned that, and that's for further news. But when is Chrome Dev Summit? It's 12th and 13th of November, I think. That's not my back. That's not my back. That's not my back, though. Leave Google Google. Oh, I was over there. No, the thing is, like, it has my laptop in it, and that's, like, basic feed. I'll swap. Sure. You will also swap fingerprints, then. All right. Thank you so much. Thank you so much. All right, cool. So we have a bunch of more questions that were submitted, which we'll never get through. But maybe we can get some from you all who joined here as well. And then we'll do some more questions from here from the room as well. What's on your mind? OK. Do you guys hear an excellent microphone? When I talk, I talk. You're OK over here. I suspect. OK, I'll speak now. Hopefully, everyone can hear me. But my main questions for today, it's sort of two-part, and it pertains to content cleanup on a large scale. So first is the concept of having multiple pages of information around a specific kind of topic using pagination, things like that. Part of the cleanup and consolidation effort would be the desire to eliminate everything beyond page 1. So if a user lands on page 2, 3, 4, and so on, they would essentially be directed back to page 1, because page 1 has been deemed to contain the most quality and relevant content surrounding this subject matter. So the question is, on the fence, whether, for the sake of what Googlebot needs, would it be better to do a 301 redirect from pages 2 on back to page 1, or would it be better to do a 410 gone sort of signal to indicate to Googlebot that everything from beyond page 1 is no longer being served there? All right. OK. I found the mute button. So I guess, first of all, that kind of means that everything on page 2 and following is something you don't want to have indexed anymore. Is that correct? Largely, for the user, there would be a read more, which would load on 3x back to page 1. If that makes sense. OK. So in a case like that, I would probably go more for 301 redirects to really consolidate everything into the version that you actually do want to have indexed. You could also use 404s or 410s. But what would happen there is we would drop all of the signals from those pages and essentially lose them completely. I think the difficulty is if you still want to have the different pages indexed or available within the website, then obviously switching this around would mean you'd have to use separate URLs for those new URLs so that we can redirect the other ones. And then you're in this situation, again, that you have separate URLs for page 2 and page 3. And we would try to crawl and index those separately as well. So you're kind of like running into the same problem again. Would you not be better off canonicalizing 2, 3, 4, back to 1? You can also do that. The tricky part there is that we don't always follow the canonical blindly because we don't know is this really the same page? Is this really something that we should fold together or not? So having more signals to tell us this is something that can be folded together, that helps us a lot. So things like internal links, if they point to page 1 in this list, sitemaps, if you just have page 1 in the sitemap file, all of that helps us to understand this is really the URL. But it can still happen that we would find page 2 or page 3 and try to crawl and index that. There's a follow-on to the gentleman's question. If you just have those read more links well next and well-predicted as well, wouldn't that help us so? That also helps us. But then it's still the case that we would try to crawl and index through those things. How long? Go ahead. I think another thing that also comes into play here often is what kind of content you have on those pages. If it's actual separate content and it's nowhere else on your website, then you really need to make sure that it's somehow indexable and crawlable. On the other hand, if these are all pieces of content that are already on the rest of the website, then just block them however you want to have them blocked. And that's fine. You're not going to miss out by blocking them. Just on that note, how long do you guys keep, maybe you can answer this, the topical signals for URL that has been redirected? I've noticed a year later, Google pointing signals towards a page that really was not related to the old 3.1 redirect, but it was still showing up for a certain topic that it shouldn't have been from the old one. How long does that, a good example would be redirecting an old company with an old name to a new one. I've seen sites show up for that old company's name with no content at all a year later after redirects have been made. How long do you guys keep that? And then what's your recommendation on cleaning that up? Yeah, so I guess the question for us kind of comes down to are we indexing these separately? Or are we just thinking that it's an alternate URL for this piece of content? If we're indexing them separately, then that's something where we haven't seen the redirect or we're not processing it properly. It's probably more of a technical thing. But most of the time what happens is just like we know this URL, if you search for this URL, that page was really relevant. So we'll try to do your favor and show that to you. So that's really common if you change domain names. You can do a site query for your old domain and it'll still have content showing up years later. And it's not that we're indexing it with that URL. It's just like we know people who do the site query, they want to have these results that we'll show them to you. It's kind of like our algorithms being more helpful than they probably should be if you're an SEO trying to diagnose if something is actually indexing. So would that say, I mean, I'm just, for every URL you have some kind of data that says it's about these topics and you store that indefinitely or forever long. I don't know indefinitely, but we keep that for a while. And I think one way you can double check to see what's happening there is if you use the new inspect URL tool in Search Console and you enter the old URL, then it should say it's not indexed and that there's a canonical there, which is kind of confusing because it says it's not indexed, but if you do a site query, it will show up. But that's just because we think you're explicitly looking for it, so we'll show it to you. What's interesting is that even on some sites that's been gone for like four or five years and redirected, it's a 3.1 redirect, it's still showing up at Search Console. It shows the destination. But that's, like, if you explicitly search for it. Even for a company name that's been rebranded or maybe bought out or something, I've even seen that show up years after the fact pointing to the new company, even though I've never mentioned it on the site. I mean, that's something also where I think a lot of sites have trouble with like rebranding or with obsolete products type of thing, where if you remove every mention of that, then obviously we're going to try to dig deeper to find mention content. And that's something that we have on our side as well. Like, people search for Webmaster Tools and like if we don't have Webmaster Tools on the landing page, like something weird might end up ranking. I'll keep that in mind when I create my new features. Yeah, just make sure that you have something that can rank for those queries. This might be a complete red herring, but if domain A in that redirect chain had tons of anchor text lines pointing out at the way of the search terms, would the relevance of that anchor text then be passed and stored for the new domain? And there's an extension. If you remove the redirect, then it should theoretically stop ranking for those terms. I don't know about the remove the redirect part. That probably depends on the individual situation. But for us, we keep the links between canonicals. So if some external page has a link to some page that's redirecting and the canonical is the final URL, then we make that link between those two canonicals. And that's where things like anchor text end up going. So that's probably where that happens. But if you remove the redirect and there are other reasons for us to suspect that these two pages are the same and we should pick a canonical between them, then probably we'll still keep them forwarded. Yeah, okay. Let me grab one from the people that submitted something. We have an English US-based site that also serves six other languages. We've been working with hreflang. Let's see. We have a Spanish version and a Portuguese version. Oh, and I guess the question is if they should be translating the URLs as well instead of just the content. From our point of view, any of that works. So I don't see a reason why you would need to translate the URLs, but obviously for local speakers it looks really weird if you're trying to look at Spanish content and you have English URLs. So I try to localize the URLs if that's possible, but I wouldn't see it as something that would break things from an SEO point of view. Or maybe they should use breadcrumbs schema markup and have the localization happening in the schema so that the URL shows. That's another good idea, yeah. But then still, if people copy and paste the URL and send it to someone else, then they wouldn't see that. But in the search results, yeah, that's a good point. Would there be any benefit to a local-based like TLD, like .es for Spain or versus the .com being the totality of it? Ben, goes more into the question of geo-targeting versus hreflang. So with geo-targeting, we would, if we recognize that there's a geo-targeted version of that page, then we would rank that a little bit higher in the series that are kind of local information. And with hreflang, we wouldn't change the ranking, we would just swap out the URLs. So if you really have something local and you know people are searching for it locally, then geo-targeting is a way to go. And you can do that with a TLD or you could use .com with a folder or with a subdomain set up. That's something where people use different things for different reasons. The only thing you can't do with geo-targeting is if you have the country setting in like a parameter in the URL somewhere. Like the query string, I've seen that before. Yeah, it's like country equals whatever, then we wouldn't be able to pick that up. But in terms of URL structure, we have various sections of the site using either like slash UK and then it's going to be K or it's going to be EN slash UK or EN dash UK. Is there an SEO impact if we use like two folders for language and country? Is this better if we have one folder level? Because otherwise it's kind of, is this perceived as deeper down the less relevant to you or not really? No, not from that point of view. But for geo-targeting, we need to have that part of the site verified separately in Search Console. It is. So if you have language and then country, that means you have to have all language versions and all country versions listed in Search Console, which is kind of messy. So if you have country first, that makes it a little bit easier. All right. I can jump in. I had a question about domain splitting. So the idea that I have a client who went to a brand at TLD, and so they went from one core domain to five. And from my world, I was kind of concerned about the risks mainly the process of something that you messed up. But we went through it about a year ago. And so it was a very like, we're up here, we died, and then eventually we came back and the trough was really long. And I was wondering if there's, I found something where they had botched all their kind of deeper blog content and redirected it to the homepage of the corporate new domain instead of into the specific verticals that they had created. So we fixed that and I think that helped. I was wondering if you guys sense that when an entity goes from one to five that you still know it's the entity and that you're kind of giving it some weight behind beyond just the domain TLDs. Because I feel like that's going to be more common as branded TLDs for bigger operators. So I have to play with that. So splitting and merging sites is always really tricky for us. Moving sites is generally a lot easier because we can pass all of the signals one to one. It's a lot easier for us to debug as well. If something goes wrong, someone can look at it and say like, this is the old state, this is the new state and we can compare that. But if you're splitting or merging sites then there's no really clear and well defined like new and old state. They're not really mapped one to one because you're taking one site and you're turning it into five. And it's a completely different situation for each of those individual sites. You can't take those five sites and add them up and like come up with a new with the same number as before. So that's something that takes a lot longer to be processed and mistakes, they tend to be like more visible I'd say because it's like we have to reprocess everything and if there's a mistake in there that can be kind of another side of the equation is the back links to it. Where are those going to go now? Exactly. So I knew they were concentrated on two of the five. So going into it, I'm like, these will probably be okay. But these other smaller little brothers that you now have are going to get left behind and kind of expecting that you have a vertical that you're not struggling with. But I just felt like there were also factors maybe that come into it that beyond it you see that there's a corporate entity that's hosting in a certain area and like those factors help maybe smooth that out so that the timing I just knew was going to be long but I'm not sure if that was like an average. I don't think we have any system to kind of understand like this entity has moved from this domain to this one of these five domains. I think it's really something we kind of have to figure that out almost on a per page basis to see like this page has moved to this domain and it's now the context of this page has changed completely. We have to kind of recalculate the whole setup. Reverse canonical tag, right? Yeah. I don't know, but then you're not, you're just deferring that decision. What about like a just spitball and like a same as schema workup or something like that? I don't think we picked that. I mean we might pick that up for different kinds of structured data but not like for general site use, migrations like that. I mean you have the same situation if you take multiple sites, you merge them into one site. That's like you always run into that as well. You have like five sites. It's like what is the final state? You can't say like add them all up and that's the traffic. Yeah, it's essentially impossible to guess ahead of time and how long it takes. In that specific example though of having multiple sites that say same products currently competing in the same space. This is a hypothetical. There is a new domain which those two brands are going to merge into. Any specific considerations outside of the typical site migration checklist that you would do apart from the fact that there's two going into one? Nothing that really comes to mind. Yeah. I think it's just important to also make sure that you from a content point of view you also make sure that you have something that matches the old content so that people who are explicitly looking for their old stuff, they will have some place to go. Yeah. From the non-existent metric of authority that you were questioning but from that perspective for example a site ranks for a certain topic, a subject matter. You have a site ranking on position 5 and another one ranking on position 6 and they kind of have good authority at page 1. If you merge them and they have some signals that merge into a single piece of content on the same topic, would it move up in rankings potentially? Probably. Probably. Yeah. I think that's generally something that we see if you take two or three or four kind of weaker pages and you merge them into one even within the same site. Even within the same site or externally then that's something where we can say this is a stronger page. We can see that like more parts of the site are referring to this one single piece of content so probably it's more relevant than those individual small pieces that you had before. Now I have seen and you're an expert obviously but I've seen where you've got two that you merge and they kind of have different topics. So there might be one topic that they're starting with others and then I've seen them become weaker across the board on all because you're basically competing for more topics on the site too. I've seen that happen with a lot of mergers too though. One might have ended up here on one topic, one here and they both end up here or the new one ends up here. I think if you have really different pieces of content or different topics then that can happen because it's basically you're taking two completely separate pages you're putting them on the same page and then our algorithms have to think about like so what's the primary topic of this page? It might be this, it might be that, it might be some weird mix that we figure out. Yeah but to your point I've seen I've done things where I'm just saying site prior webmasters and content writers created multiple pieces on the same topic with a slightly different lens when you merge a few two or three or four sometimes into one single good piece explaining in depth it ranks well. Yeah I think that's something I generally try to recommend to people and it's like if you can have fewer URLs and usually that makes it easier like from a management point of view but it also helps from an SEO point of view where we can really say well this is stronger content this is something that's referred to from a lot more places than these individual other pieces that you had before. Hey John, if I could ask a question I think close and close to that conversation. I hear it, I hear it. Hold on. Is it, so on the, if you mute maybe there, that's good. On the topic of creating you know having one single authoritative page versus multiple iterative pages what about for product content expired product content that might still be relevant so in the automotive space model year car, so a 2018, 2017, 2016 model year Toyota let's say. Is it beneficial to have all of those pages in sort of like an archive section or to maybe have one you know truly authoritative Toyota Corolla page that maybe contains all of the archived content within it perhaps in like a folded accordions at the bottom whereas the top main body content contains your current model year content. Good question. I don't think there's one size fits all answer to that. What I would do is try to test that from usability point of view to see what works for the users what doesn't work. I could imagine there are situations where you have one page that lists like the older versions as well there's definitely the option of moving the older content into archive section to kind of de-emphasize it a little bit I think that's also an idea could also be that you have a mix where you say well this is the recent version and on the archive page I list all of the archive versions which might be another approach to take there but I think it really also depends on how users engage with that content and how they search for it. If you're explicitly searching for a specific year for a piece of hardware then if you land on a page with a current product you might go well this is not what I was looking for I'll search somewhere else. So that's something where you probably need to think about what users are actually expecting from an age like that. So on that note not to beat this subject down too hard but how do you contend with that when you're speaking about a home page versus an interior page competing with itself. So you've got a topic that your home page where all the external signals are saying it's about because that's how they naturally happen versus we want this page to be the authoritative how do I tell that on a home page to know this is the topic when they normally might compete with themselves. One thing you can do there is really be totally obvious with your site structure to make it really clear that these are actually really important pages. That's something that usually we pick up on that but it can still be kind of tricky where if on your home page you're listing the same product as well and you have a link to the product page and essentially the same information in both places then it's sometimes really hard for us to figure out like should we send people to the product page because maybe they can convert better on the product page or are they looking for the home page where they can find different products. So that's really tricky especially if the content is the same on all of these. If it's matter of the home page being about the company and it links to the product and the sidebar saying this is our most popular product and throughout the whole site you're linking to the product because this is our most popular product then probably we would pick the product type queries. But it's sometimes tricky. So we have people that complain to us about all variations of this like the product page, the category page, the home page it's like why are you showing your home page when you should be showing the product page or the category instead of the home page and it's like everyone wants something different and for our systems to figure that out is really tricky and essentially the only really obvious way you can give us this information is to say this is no index and this is index but that's kind of harsh. It's not reasonable for that. It's a clear option. Some subway master is like he makes the wrong page now after this call should rank 4. Let's go back to that. It's interesting to say that because I've seen that exact example back in both ways. So a very large site, millions of indexed URLs huge amounts of backlinks ranks extremely competitively once you add model year on to any model. Much smaller site I've also worked on motorcycles, not cars not the same history nor near as many pages couldn't get anything like those pages to rank until the accumulations mold together and then they started ranking for the model. So literally that exact circumstance I've seen in both ways. Cool. Cool. I had a light question. Do you guys know how soon do you have the data? What percentage actually have Google search console verified? Is it the majority? Is it some? Is it a tiny? In my world the number of times I engage with a company that's fairly large and has a lot of digital markers they don't have it. How? It's happened too frequently for it. I don't think it's not I asked the same question for being my master goals. I'm just curious because I think it's interesting data. We do have data on that but one of the things we look at is more of the search results. Not like index sites because they're the gazillions of domain names that are indexed and nobody cares about them. Who cares whether or not. If they're actually showing up in search results and we assume they'll probably maintain somehow and people care about them then that's kind of the people that we would like to see have access to search console. One of the things we started doing now is being more proactive about the analytics verification where you can use Google analytics to verify a site as well but we see a lot of sites just use analytics and not have search console setup so we've started setting it up so that if you have analytics setup we'll automatically add search console as well just because it's theoretically already there you just didn't click the right buttons to make it chill up. So that's an actual thing then? That's happening that's been happening over time and that's confused some people as well it's like why suddenly they have search console access when you just had analytics access Sometimes people still maintain access to analytics after they complete the consulting work and they get notified that they can get access to their webmaster tools and then that's a matter of maintaining access. I think that's always always kind of tricky I just got a client the other day I cleaned out like 20 people What are you doing? All your computers probably have your data What do you think? I mean people assume that they're not going to be looking at it afterwards but who really knows I think it's kind of tricky with search console data in general because you also have the removal tools there as well So like ex-employees have access to a search console account Probably not that great I've seen previous contractors D-list Can I give you two quick search console data questions First one I noticed that the external backlink section appears to have been much improved over the last couple of months Congratulations on that Are we ever going to get an API for that data? I don't know maybe I mean I have nothing to pre-announce It's not like I know it's happening but it's more that we've talked about this and kind of expanding the API in search console in general and maybe this is something we could add Did you remove the ability to download the links? I don't think so I'm missing it while I'm looking at it So the complete set of external links The reason that I ask is having looked recently in old history all of the other indexes swept up in search console I found quite a lot of stuff in various sites that is not on any of the other indexes recently that may be because sites are more often proactively blocking everyone else from crawling them or it could just be that the Google data has got better Either way I'd like that I'll be released sometime around 2019 I don't know I don't know That was the first question The second question was this was referred to me by Dejan Petridge The August 19th update where it changes the graphs when you filter the graphs in the performance report in search console as of August 19th it significantly reduces the amount of traffic that appears in the graph once you've started putting keywords into it Is that a bug? Is it going to change back? Why does it do that? That's probably not going to change back Fair enough So the background there is that we filter queries before they reach search console or search analytics if it's really rare kind of for privacy reasons and that's done before it hits search console and in the past what we would do there is we would just I think include them all in those graphs for those queries where essentially the data is kind of skewed in a positive way and now we remove all of these filtered queries from those keyword queries which skews them in a negative way because we don't know if people were searching for those and now we're just saying well if we don't know we're not going to show them in the past if we don't know we're just going to assume that maybe they were so that change I don't see that going away because it's also due to the way that we store this data internally in the search console side I'm assuming you would get that equivalent data from your broad match keyword report in AdWords that if you were spending money on clicks I have no idea Fair enough No idea what that report would show No, I'm just asking the privacy reasoning for it would seem to be the same I don't know how AdWords does that I think we're kind of out of time so if any of you out there want to ask one last question then we can go through that and otherwise I'll stop the broadcast and we can chat some more as well I'll go ahead and ask the other one Let me find the problem Yeah, there we go So last chat we had John I asked you about dynamically inserting hreflang and canonical markup using javascript so generally I've done that it seems to be okay my concern or what I'm seeing now is in search console it's still saying which targeting section it's saying no hreflang markup is on your page is that am I going to be able to resolve that if I'm going to continue to use javascript to implement okay, so how you're still muted He hasn't executed his javascript to speak yet Yeah so if it's implemented properly and you can pick that up then that will start showing up in search console I know they've had some kind of data latency problems recently so if you've made those changes in the last few weeks maybe it's just not updated yet it's been about a week now well if it's been about a week I would definitely assume it's just a matter of time that's something where I mean from a rendering point of view first we have to render and reprocess the rendered version for indexing and then search console has to pick that up and kind of process everything through their pipelines which takes a couple days as well in the normal case and I think at the moment they're still a little bit slower than normal so that should start happening awesome cool one last thing okay hold on thank you so I'm sure this is considered SEO 101 it's kind of just a general high level question but for websites with large amount of content pages we're talking tens of thousands or more the idea of pruning content or taking down pages with content deemed of a lesser quality in your opinion does that tend to improve the overall I guess quality score of a website and possibly lead to other existing content receiving more visibility as a result okay it should I mean especially if this is content that you don't want to have indexed because you know it's low quality then removing that does help us to understand the rest of the site better and it's something that I suspect is not just theoretical like I've seen various presentations at conferences where people are saying I remove I don't know one third of my site and the rest of my site is ranking a lot better because of that so that's something that's certainly an option in talking with the indexing and ranking teams usually they say we shouldn't be telling people to just remove low quality content but rather to improve it from a practical point of view of course like depending on the site the kind of content you have sometimes you can improve it sometimes it's just not that you've collected over the years that doesn't really make sense to improve on a kind of point-by-point basis so we're doing this exercise on thin content so we have a tutorial site which has a lot of quality content and what we're doing is a lot of it is not performing so what we're doing is we're looking at what kind of topics it's ranking for so if it's a good quality topic that has a lot of search demand do collect all the pages and it could be like tens of thousands then we go and put them in screen frog and run word count and anything less than like 300 words it's a thin content so we go back then and look at the pages and at this point it's going to be probably a couple hundred pages and then you look at what's there and usually you find it's going to be a video header and like a sentence to authors and then you do a transcript of the video and go to the authors and like can you write better content and then it's immediately getting feedback I mean again results because Google finds that okay that's interesting especially if you have like how-tos for videos, for tutorials so you can actually repurpose content that's not performing it's like sitting there nobody cares about it and kind of that's a new life I think you have to be careful with the metrics and not just assume that like 300 words is a magical count but like if it's your site you have to find some metrics to say like I can't look at a million pages we just looked at the sample and found that it was like 275 or whatever it was it was a a good one too it included actually navigational words as well so I mean that's something where like if you look at your site in a bigger picture like you can find these different metrics like some people use things like bounce rate or time on site all of that and it wasn't ranking so it was actually quality keywords but it was ranking like page 2 or lower and lower so it was kind of like non-performing but and when you remove content generally if there is of course matching good content you redirect it to that new matching content but if it's kind of related maybe not do you want to redirect still do you want to point to home page I think 404s are fine so redirecting to the home page is something for a lot of cases we'll pick that up as a soft 404 and we'll treat it as a 404 anyway so like if you think this is the best approach for the removed content fine but a 404, a good 404 page is also fine if you have a mass number of 404s hit at the same time as I can send some other signal no where you guys go no 404 yeah if the content doesn't have links to them or if the content does have links then would it be worthwhile saving it and redirecting I mean it all depends on the volume like if you can look at it individually and you're like saying oh this one matches this and I can redirect it and that's fine but if you have tens of thousands of pages you're not going to have time to figure out like what would this page match to maybe you can automate some of that but for the most part you kind of have to take a hard cut and just say nobody's visiting these pages they're not ranking there's like zero value for my site to keep these so I will just cut them all out alright so with that let's cut off the recording thank you all for joining thank you for watching thanks for coming great to have people here in person and hopefully we'll see more of you all in some of the future hangouts or at least more questions will you meet me tonight or early morning uh yeah I'm just going to put a picture of me on that if you could start happening to me tonight I'm not going to be ideal for us