 Welcome, everyone, to the next episode of Search Off the Record, a podcast from the Search Relations team here at Google. Our plan is to talk a bit about what's happening at Google Search, how things are working behind the scenes, and I don't know, maybe have some fun along the way. My name is John Mueller. I'm a webmaster trends analyst or search advocate here at Google. I work together with the Search Relations team here. I'm joined today by Martin and Gary. Hi, E. Morning. Ooh, all right. Gary, do you want to take us off? Why it's always me? Because reasons. It's always me. I'm in a fantastic mood because I just spilled coffee all over my keyboard, and I had to switch keyboards that I don't even know what the time is, like 10 AM. Is that a hot swap? Thanks, Martin. You're welcome. That cheered me up so much. Anyway, I wanted to talk a little bit about feedbacks. Lizzie and I, busy as in our tech writer, we are processing feedback and also the translations for the Dev side, developers.google.com. Search. And we got tons of great feedback that was actionable. You can think of translation quality, for example, where people were pointing out that we were switching between the different tones of German, like formal or informal. And we were doing some really weird things in Japanese as well. And the feedback, in general, it's really, really great. But then some people leave feedback in the form of, well, some things are just rents about something completely unrelated to the article. And they come through to us. And sometimes we read them. And, well, they are not useful. We can't really do anything about them. And another category is where people are asking for help about something. So for example, just today, I had to wake up at 6 AM for reasons that are beyond me. And I was processing some feedback. And there was this person who had their email account suspended for some reason. And I would love to help, but I really can't with that. I can't even respond to these feedbacks, which is probably a good thing for the person filing the feedback. So if you have, in general, something about the documentation itself, if you could leave feedback about that, that would be great. Otherwise, we can't really do much. On the bright side, sometimes it also gives us lots of great points to think about. For example, we noticed that we got lots of feedback from bloggers, let's say, people who are not developers. And they were commenting that we sent them, for example, structured data messages, that something is wrong with their structured data. And they can't do anything about it. They don't know what to do about it, because they just installed, for example, a plugin. And the plugin generates the structured data for them. And that prompted us to think about, how can we help also those people? And John started an internal thread, which somehow ended up, I think, a little derailed. But then I just jumped over Twitter and asked people for some help, I guess. And we'll see where that goes. But thank you for filing feedback. Thank you for filing feedback in multiple languages, because it's been really, really, really helpful. And just think about how you leave feedback and about what, because really, we can't help with absolutely everything. So where should people go for things like their Gmail account? We have specialized forums for most products, I think. And those forums are filled with people who are insanely helpful. We used to call them top contributors, but I don't have any idea what we call them nowadays. Product experts. Product experts, OK. They are insanely helpful. And they can point people in the right direction. And ideally, those who have problems with our products, they would just go to the forums and ask for help there. I think, generally speaking, it's a good idea to give us feedback. And I'm really happy that you bring this up, because I know that from the outside, sometimes it feels like talking into the void. I don't think we are able to give a response back. So I think when people are writing actionable feedback on our documentation or on Search Console or something like that, it's invaluable to have this feedback. And a lot of changes are happening because of this feedback, even though it might not necessarily look like that from the outside, right? It's actually funny, because apparently there is a setting somewhere buried that would enable us to respond to feedback. But when Lizzie found it and she was saying that, oh, my God, can you imagine Gary replying to these feedback? I lulled. Fair enough. Yeah, I'm not sure if people would want that. I think there's some kind of feedback where it's useful to be able to let them know and to kind of inform them that, oh, we read this and we totally agree. We fixed this issue. We tried to improve the documentation in that way. That's something that I see, for example, from the Google Maps team. I think they do that really well, where if you submit feedback and say, oh, actually, this road is closed or something like that, then they'll send you an email back over time and say, hey, we saw your feedback. We fixed it. And I think that kind of helps to encourage other people to submit more feedback and kind of keep things going. Because it's kind of important to us that our documentation, the help that we provide, is useful to people. So if people are confused or people don't find it as useful as it should be, it's really helpful to know. We can't kind of read that from people's mind. True, yeah. Yeah, and this is like the black hole kind of character of the feedback. You give feedback, seemingly nothing happens. And like six months later, a feature is rolled out that implements what you have been sending feedback about might not feel very encouraging. So I think it's a good opportunity for us to say thank you to everyone who provides feedback. We do take it into account. And it does matter a lot to us, especially on the docs. Yeah. Talking about black holes, maybe we should talk about JavaScript in search. What do you think, Martin? Oh, my. What an elegant segue into the thing that happened recently. John, you will get a cookie for this. Ooh, Gary's cookies are fantastic. I'm now slightly jealous. So one Lee renders free webinar recently. There's a recording of it on YouTube as well, where they invited me to talk a little bit more about rendering SEO. That's how they try to talk about specifics in rendering when JavaScript is involved. So it's not just JavaScript SEO, but they are really like focusing on rendering. And after that webinar, I got a question on Twitter as well regarding like, should we split our JavaScript into multiple smaller files, or should we bundle them together in one large file? And that was an interesting conversation, because the answer is kind of weird, because the answer is bundle it up and then split it. So what is bundling JavaScript? Is like, put it in a zip file? Not really. It's more like merging all the files together. So if you have a library and then you have code that uses that library 20,000 years ago, you would basically just have the library in one script tag and then have another script tag for the code that uses that library. But that makes a lot of HTTP requests and the number of HTTP requests is limited that you can do at the same time in the browsers. So people were like, hmm, maybe we should just like make one file where we put the library first and then the actual application JavaScript that we write. And so people are using these bundlers. There's like a bunch of different tools like Webpack and Browserify and what they are all called. Parcel and so on and so forth. That basically just puts all the JavaScript that you write from the different files that you create into one big file. And that's usually referred to as a bundle. Okay, so it's not something you manually do. You kind of run it through a script and then it creates one big JavaScript file from that. Yeah, and usually also it's like, you can do it manually, but then you're kind of like wasting your time because there's fantastic tools that do this. And these tools also do other things like shorten the variable names that it's less bytes on the wire and remove code that is never used and all this kind of stuff. So it's pretty powerful tooling and a bunch of people are using this to bundle their JavaScript in one gigantic file. Is that something that complicated sites need to use? It's like, I sometimes write JavaScript as well but it's, I don't know, maybe two pages of code. Should I run it through one of these tools as well? Or is that more like if you're creating a really complex JavaScript applet? I think it is more for people who use frameworks and libraries a lot. If you write a little bit of JavaScript to do something fancy when you click a button and like, I'd say like a hundred lines or something, I think minifying your code is useful, but not as useful, like it's not really a necessity. But if you're using a framework like React, Angular, Vue, there's so much code involved that these bundling tools are definitely helpful. Cool, yeah. And the oddity is that, so while I say that and it's an accepted best practice to bundle all these things in one big file, it comes with a downside, which is that if I have a huge application with lots of different views, like, I don't know, a blog and then I have an e-commerce part of my website and then maybe I have like a login accounts page or something like that or an order dashboard or whatever. If I have all the code to power all this content in one huge JavaScript file, that means that if any of these parts change, the entire cache is invalid and we have to like re-download everything. And also if I just come for the blog, then why would I download like an order page or a card system or account system? So you download a lot of stuff that you don't need. So that's why the recommendation is to bundle things up but then split them according to the content that people might visit specifically so that you separate the different parts of your page code-wise. Okay, that sounds pretty complex. Yeah, it's called code splitting or splitting if you ask me, obviously. You didn't. I did, I did. It's such an original joke. No one ever toys with my name like that. So I had to do it, I guess. I literally Facebook. You're welcome. What can I say except you're welcome? So yeah, a bunch of these tools that are bundling have options to specify how you wanna split your bundle as well. So for instance, you can say, oh, this is code that every page needs. It's kind of like the boilerplate or the runtime or whatever you wanna call it. And then you create one JavaScript file that contains this boilerplate because the boilerplate probably doesn't change very often. So you can keep that cached forever basically. And then you have only the code for each specific page or view separated into different bundles. So there are options and there are tools that help you with this but if you wanna do that manually, that's really, really hard to do. Do you think this is something that someone like an SEO should do afterwards or does the developer need to do this? I think it's something that an SEO should make developers aware of because not every developer is aware of this. As I said, like the old established best practice that still is somewhat valid is to bundle everything in one file. Now it's like bundle it up in multiple files but make that a reasonable bundling. And I think it's not something that the SEO needs to do afterwards. It's better if the developer does this while developing the site because it's usually embedded in the developer tools how you can split these things. And it might require some changes in the way that the code is written. So definitely make your developers aware of that. Is there a simple way that an SEO could recognize this? Like if you look at, I don't know at a waterfall diagram, would that be obvious that you need to bundle the code or you need to split the code? So I think if you are seeing your website downloading like 20 different pieces of JavaScript or like 30, 40 pieces of JavaScript that's the case where there is no bundling and you should definitely think about bundling this because that's a lot of requests and it's kind of pointless to have all these requests separate. If you see one request that keeps repeating every page you visit, like an app.js or like a main.js or something like, or bundle.js is a classic and you know that the website is very large and has lots of different pages then that's a hint that you probably wanna split your bundle, especially if this bundle is like multiple megabytes. If you have like an bundle.js or an app.js that is like five megabytes then that's a very clear candidate for splitting the bundle up into smaller chunks. Sounds cool, okay. I will test some of the web pages that I access to see if I can figure something like that out. I can't help them to fix a problem but it seems like something that you should be able to try out on random websites that you visit and kind of see if you could recognize this as kind of I don't know, an exercise. Yeah, and it's just something that is nice for the user and easier for us also to deal with caching-wise but it's not like a ranking factor or anything like that. It's not, we are not looking at this. It doesn't necessarily help you with the core web vitals or something. So it's not directly impacting your ranking or anything but it is just a helpful thing to do. Okay, speaking of ranking factors. Oh dear, please don't tell me JavaScript is a ranking factor. I don't know, JavaScript can be a ranking factor? Sure, why not? Uh-oh, uh-oh. Well, okay. It's kind of a tricky topic in that I see people write about this all the time externally. I see us using that as well. We use it when we talked about the page experience benchmark where we said this would be a ranking factor and then obviously the next question from everyone is like, well, how strong of a ranking factor is it? Do I have to like throw away my website and just make a fast empty page instead? And obviously that doesn't make any sense either. So I think there are two mental models I have when it comes to ranking factors in general. On the one hand, search is not a science. I think that's really important to keep in mind in the sense that there is no absolute truth out there with regards to which page should be ranking for which query. But rather these are things that can change over time. These are things where people are working on it to keep improving things and sometimes you can have discussions with smart people about which of these pages should be ranking first or if we have two very similar pages should they be both ranking or should only one of them be ranking? Like those are like very, I don't know, interesting discussions to have but it's all based on kind of, I don't know, opinions and kind of ambiguous information that you have from the web. So that's kind of the one thing. And the other thing is that there's so many different ways to reach a final result in search. It's not that every site has to do the same thing. So I use a mental model of something like a neural network which is not how we would do this in search but it kind of helps me in that we take the query that a user has and we try to understand it and split it up into lots of small parts and these small kind of signals that we have from what the user is looking for they go through this big network where different knots along the way kind of let the individual parts pass or they kind of reroute them a little bit. And in the end, we come up with a simple ranking for the different web pages for that kind of a query. And when you have this kind of a network there are lots of different paths that could lead through that network that end up with the same result. So it's not that every site has to do the same thing but rather there are multiple ways to get there. And you don't have to blindly follow just one ranking factor to get to the end result and it's also not the case that any particular kind of factor within this big network is the one deciding factor or that you can say that this factor plays a 10% role because maybe for some sites, for some queries it doesn't play a role at all and maybe for other sites, for other queries it's the deciding factor. It's really hard to say kind of how to keep those together. So this kind of big network thing also changes over time of course as we try to improve our search results and essentially we try to optimize how we understand the query. We try to optimize how we understand kind of the routing between the query and the search results. And these kind of changes take place all the time and the best way for a website to kind of remain in a stable position, which is not guaranteed at all is really to make sure that you have a wide variety of different factors that you work on and kind of to keep this diversity of your website upright. So similar to how you might want to improve diversity in a team to get different viewpoints that's the same thing that you'd want to see on the website so that regardless of how things are routed through this network to find the search results we can understand that this website is relevant in different ways and all of these add up into kind of telling us that it's actually relevant for a particular query. So that's all to kind of say that it's really, really hard to take any particular element and say this has such and such an effect on the search results. And similarly it's pretty much impossible to kind of go from the other way around and say, well, looking at the search results I can tell that this particular search results factor is disimportant or more important than this other factor because it's really not the case that you can kind of route things backward and say, well, looking forward it goes like this and looking backward it's exactly the same route because there's just so many different ways to get to the end result. So that's kind of my short monologue on ranking factors. I think it's worthwhile to keep in mind that when you talk about ranking factors externally there are lots of different ways to get there and it's not something that you can just kind of deduce into one specific element or kind of simplify into an ordered list of elements that you need to check off but rather you need to make sure that your website is good in a variety of different ways and don't just blindly focus on one particular element and then try to make that element look natural so that it's like, hopefully the algorithms won't think that I'm trying to do something sneaky here but instead just make sure that everything is kind of natural. Do we have hundreds of ranking signals by any chance? We have lots of them. I don't know how you would count them because it feels like things like how we sort strings is essentially a ranking factor, right? What? No, it's like all of these different algorithms that play a role in the final result is like, how do you even count them? That's a good question. I think it's 420. 420, okay. Just because of the 420 joke? Did you literally just make a 420 joke? Maybe. I would never joke about this. Come on, Martin. Seriously? We should count those ranking factors now but I really have no idea how you would count them and like how you would even kind of like split them up. On the other hand, what I think is really neat is when people externally try to understand search and they try to figure out how search might be working, kind of to look behind kind of the bigger picture and try to figure out what kind of algorithms might be playing a role here, how can I understand how search engines work because there is technology behind all of this. It's not like a magic box where you just drop things in and things come out. It's essentially something that people can code and you can learn how to code and you can learn how to make search engines. It's not something that you should ignore completely. So I think this is an important point. You say like, yeah, you can code this and you can understand how it works but I guess ultimately the goal of search engines is to show the most relevant and useful content for users to the users searching for something. So how does that work? Do we know exactly how we need to rank or like how do we, how to do this or is this something that is emerging or how does that work? I mean, it's something that we have to keep working on. Kind of like I said, it's not like a science where you can say this is the absolute correct answer and everything else is wrong but rather you could discuss that maybe this is the best answer or something else is the best answer. It might be today this is the best answer but maybe next week or next month we discover well, actually we should have been looking at it differently. Maybe something else is the best answer. And obviously there is some things where there is a scientific answer. Like if you ask like, what is two plus two? The answer is obviously 4.001 when it comes to computers or maybe it's just four, I don't know but a lot of things really don't have absolute answers. And this changes over time fairly quickly as well where maybe if you're looking for a vacation destination you'd like to find some general information about that destination but if suddenly that vacation destination is in the news then probably you want to see something different when you search for that location. I mean, I don't know who's going on vacation nowadays but at some point we'll be able to go on vacation again. So that'll be relevant then I'm sure. I just shed a tear. Oh, I want vacation. There will be vacations again at some point. Anyway, I would also like to add there that we also take quite a bit of user voice into shaping the algorithm because when we evaluate new launches then it is tested first on humans pretty much all the launches be that live experiments where actual users are getting the new algorithm or piece of the algorithm into their search results and they can see different results, differently sorted results. And then we look at things like clicks like how they reacted to the new results to understand whether the launch is good or bad. And then we also have raters, humans who would leave us feedback on side-by-sides to help us understand what went well and what went wrong with a specific potential improvement. And I think tracking ranking is also pretty weird and tricky for people externally because even if your website continues to be fantastic other websites might come into the web that have better information or more up-to-date information for something and then you just don't rank us high anymore. That doesn't say anything about your website specifically. It just says something about both how we are thinking about ranking as it comes to the different ranking factors as well as the web moving. That's just something that happens. I think that's definitely something that comes into play every now and then as well. On the one hand, our algorithms change. On the other hand, user expectations change. Some of that might be reflected in the algorithms directly. And then of course, all the other websites on the web are kind of in the same pool. And sometimes it makes sense to show some of them more frequently. Sometimes it makes sense to show your site more frequently if we think that it's more relevant for users. And I think another tricky aspect there is that sometimes there is just a lot more than just pure relevance when it comes to ranking. In particular, factors like, I don't know, HTTPS or speed are things where we can say, well, technically these sites are just as relevant to users. But we think this one provides a better user experience or maybe we feel this one makes it easier to kind of view the actual content. And maybe it makes sense to show that one a little bit higher. So these are all kind of small subtle things that also play a role in there. And in some cases, maybe they don't play a big role in other places. Maybe they do play a significant role in which of the results we show first in the search results. Interesting. Yeah. Fun stuff. OK. Well, that's I think my kind of monologue all about ranking factors and things. I do wish that people continue to stay curious about these things. But it is also worth taking them with a grain of salt to think about, well, actually there is a lot more involved rather than just one factor that you should be focusing on or one element that you should be using as feedback to send to Google and say, well, my website is faster than this other one. Therefore it should be ranking first. Mm-hmm. Yeah. Fun times. Fun times. Yeah. I don't know. Talking about fun times. How is the video recording going, Martin? Oh my. Oh my. So with like not all of us, but like some of us have been sent this bunch of kit for recording videos from home because where the studios are closed, which is super sad, but it makes sense that we are like producing video content from home now. So there's Web Dev Live is an online event full of prerecorded talks that are being like put on YouTube with live Q&A with the speakers and super cool ideas, super cool content concept. We do the same thing with the Webmaster conference lightning talks. We do record these videos continuously. We have recorded some before the lockdown and some are recording now. And yeah, it has been interesting to assemble the kit. Like there's so much stuff that you need to screw together and then like put in the right position. And then we have been like chasing around our apartments to find the right spot to film so that it looks nice, but not too noisy. And ay, ay, ay, ay, ay. So that took quite a while. And then we record it. And then I am used to recordings and I do enjoy them. And I'm normally like one or two takes for a thing, but not anymore. We recently recorded a few things from home and it took me quite a while. First, I was misconfiguring the teleprompter and then the light was changing because there were clouds and I don't know, John, your recording videos from home as well, how was the experience for you? I think it went perfect as I just had one take and we were done in like 10 minutes. I don't know, Martin. You liar. No, actually, it did take quite a bit of time. So finding the right position and moving things around so that it looks kind of reasonable. I mean, it just takes time and getting the lighting in a way that makes sense, that takes time. And of course, we're not in a studio, but rather at home. So it's like the rest of the family is out and about doing things. I think for one part of the recording, we had random noises from the kitchen all the time, which is well, kind of understandable. Like you have school and kids have to get something to eat in between. So like you have to do something quietly in the kitchen, but all of these small distractions just make it a little bit harder, I guess. But I think overall it's been interesting. You have a lot more appreciation for the team that's usually involved with recordings where it's like, usually it's like your job is just to speak some text and kind of look reasonable into the camera. And now it's like all of these small parts that have to play in together. And it's like, oh, is it color right? Is it sound the right level? All of these small things where it's really, like there's just so many fantastic people that are involved in these recordings. And we had a beautifully shared moment in one of the recordings where there were garbage trucks backing up into back alleys in three different locations at the exact same time. That was hilarious. People were looking at me like, hold on, there's a garbage truck backing up. And then one of the producers was like, oh, wait a minute, that's actually, that's on my end, like this is happening here. I'm like, no, no, it's also happening here. And then the third person in the call is like, no, no, this is also happening here as well, actually. And that was kind of interesting. That was funny. Yeah. I mean, ultimately we try to make these as clean as possible, but it's not a sterile environment. It's like we work from home and try to get things right. I think it makes them even more personable, right? It's like, oh yeah, they are at home as well. Look at that. It'll be fun to look back at these after a couple of years when everything settles down. I mean, hopefully it doesn't take a couple of years, but at some point it'll be settled down and kind of see how things were back then. Maybe we should just document it more. And it's all the anecdotes. Anna, our producer, when we were trying to find the right place was like super picky. The bookshelf was too much like clutter in the background, visual clutter. And then my walls were white and boring so we couldn't use these. And she was quite picky. It took us quite a while, but it was good. I think this, as you say, it makes you appreciate the effort even more. Yeah. Cool. Well, I... Wait, wait, wait, wait, whoa. I have one very important thing to say. Well, actually, two. One, John, your hair is back. I'm so disappointed. It happens. I don't know. It's like, I took it all out and then it came back. I think you should dye it. Dye it? Wait, what? Oh, I misheard that sentence because I'm like, wow, Gary, that's rude. Dying hair, rude. How about you, Mark? And you look like a... Careful. Something PG-13 unicorn that fell into Unicorn Lake. Yes, precisely what happened. I told you, my user agent is Pink Fluffy Unicorn. Do you have a user agent? I do have a user agent. That's perfect. Wow. Wait, you actually have a user agent? Yes. Like you modified your browser's user agent? Actually, yes. Fun story. Yes, I did just piss off one person that I know is checking their analytics for the different browsers that are accessing their website. I used to run with a very specific user agent and they're like, who the hell is this? And because I was traveling so much recently in the last couple of years, he couldn't pinpoint it down because the requests were coming from all over the place. Oh man, you're such a troll, Martin. That's amazing. I love it. I should do that. Definitely. I should just put Gary as user agent. Just put Internet Explorer 4.5. Oh my gosh, that's terrible. I actually wonder how the web would break for me if I modified my user agent to just be Gary. I think you should try it out. Yes, no. I should try it out. And if you don't see anything break, then you should color your hair. I will not do that. I promise you that. Oh. Okay. All right. Well, in that case, looking forward to seeing Gary in my server logs. All right. Well, thanks for listening, everyone. I hope you found this episode insightful. And if you did, let us know in the comments, ideally on Twitter, so that we can see kind of where we could improve, what we could change, how things are working for you as well. And of course, like and subscribe, as always, like you do with these podcasts or YouTube videos. I don't know. Now I'm confused. But let us know. All right. Thanks for joining us and hope to talk to you, I guess in the future at some point. Bye. Bye. Have a day. Have a day.