 Welcome everyone to the next episode of Search of the Record, a podcast that we're trying out. Our plan is to talk a bit about what's happening at Google Search, how things work behind the scenes, and maybe have some fun along the way. My name is Martin Splitt. I'm a developer advocate at the Search Relations team. And I'm joined here by John and Gary. You don't see this, but we are waving. That's fantastic. Everyone waves into the microphone, which is a great idea. Sweet. So, Gary, how is your website coming along? Why do I always start this? Oh, I can start if you want to, but do you want to start? Do you want to start? Well, actually, I'm funnier, so probably I should start. Yeah, so there you go. Website. Websites are hard, it seems. And yeah, I'm on track, I guess. But I reached a point where I would rather pay someone to actually create the things that I want to create rather than developing myself because I'm running a WordPress installation, and it's great as usual, but I need some custom plugins and I'm actually developing that. So the idea is that Lizzie, our tech writer, and I test out things on the website once we actually published the docs about those features or structured data or whatever. And for that, I need some custom plugins. Like, for example, I can just use a normal recipe plugin because there might be a lag between our public release and how fast plugin developers implement those new features. So I want to be able to add custom structured data to every page. The second thing is that I do want to have dropdown or an accordion or something where I say a few words about why I added certain things to the page, for example, why I chose this title or why did I link to johnmu.com slash hacking and so on. And those take time. And I was wondering if I should just create, let's say, an HTML page from scratch for every single recipe that we want to publish, and then that would be relatively easy to add whatever we want to. But I thought that's perhaps a bad idea. The second idea was that I actually create a CMS from scratch, which is not a foreign concept for me because I did create a CMS, I think, right before I joined Google. And that was actually quite great. And it was working pretty well. It was based on the Google Docs API. And basically, you were writing your content in Google Docs. And then there was a container running on standard web server, an Apache web server. And that was pulling in content from Google Docs. And back in the days, that was quite cool. And it worked quite fast, like serving time was under one second. But then it got more slow, as I imagine more users started to use Google Docs API. And at one point, I think the load time for the content itself, the container loaded perfectly and snappy in a snappy way. But then the content appeared only with a five second leg, I would say. And that was a no from me. And the second problem was that the website got fairly popular. And I got an email from the, I think, API team at Google that maybe I should scale back or upgrade my plan. And at that point, I think I already signed my contract with Google. And I was like, hmm, maybe this is a good time to stop. Oh, my goodness. Yeah, but it was fun. So yeah, back to the website or my new website. It's probably on track, but I like procrastinating. And this is a good time to procrastinate as well. And I'm baking cookies for Martin. Third party cookies. Yes. So that's more important than the website itself. Absolutely agree. Yeah. The CMS that was right before I joined Google. And it was one of my favorite projects. It kind of makes me happy to see that other people also built their own CMS. I think I built multiple CMSs myself, because the first one sucked. And then the second one was quite nice, but also relied on some third party service that then just got discontinued or something. Yeah. As they do. Fun times. How did you join, John? Or when? And why? When did I join? What? That was a long time ago. I think, what was it? Maybe 2007? So I don't know, 12, 13 years ago. I forgot how to count. Something like that. I think at the time I was also making my own CMS. Maybe this is like a requirement. I don't know. But basically, I had a small software company, and we started doing more and more things on the web, as you do. And I started working on some of these websites, because it was interesting, something kind of new. And at some point, I started helping out in the Webmaster forums as they were just started. So I think sitemaps just launched around that time. And I was active kind of helping people with the sitemap stuff and trying to give them my opinion on things they're all doing wrong. And at some point, I received an email from someone at Google saying, it would be nice if I would drop by the office in Zurich, since I'm already in Switzerland. It was kind of weird, because the email came to a domain that I don't actively check for emails. So it was almost accidental that I noticed. But it was pretty neat. So I went to Zurich. I met some of the people from the sitemaps team who were active in Zurich. And it was pretty interesting. It was like a small office, not a ton of people. And that's kind of the first connection I had there. And then we set up interviews. And I learned all of the Webmaster guidelines by heart, because that's what I assumed I would be asked about. I flew over to Mountain View, met a bunch of the people there. And we had good conversations. It was really interesting. And then essentially, I had to make the tough decision of, should I keep my own company? Or should I join this big corporation? Which at the time was not as big as today. But it still felt quite a bit bigger than kind of running your own company. And I decided, well, I might as well try something new out for change. So I ended up going over to Google and doing stuff there. I think at the time there were two other people on the Webmaster Trends analyst team, Jonathan and Susan. Oh, I missed them. Oh, yeah. No, they were great. And I don't know. For a while, we were pretty much kind of a small team working together with the Webmaster Tools team back then. So that was my one chance to say Webmaster Tools and be correct, I guess. And we started trying to expand and trying to find good matches for the team and for Google, which is kind of hard, because it's a tricky role in that it's not like a software engineer where you can test on whether they can do coding properly, but rather there's some amount of communication, some amount of guessing and understanding involved. And I think you, Gary, were also active in some of the forums at the time, especially the news publisher forums. And for whatever reason, I don't know, we were in touch. So at some point, we thought maybe we could hire this guy. Yeah, that was a mistake. No, that was great. That was great. That was great. Yeah, the way we met, actually, was you set up a chat, I think. And you were trying out things on that chat and some of the Bionic posters, some of the contributors joined the chat. And then we were just chatting there. Oh, and one thing that I thought was very cool, sorry to interrupt, Gary, so sorry, was you set up this cool system on how Google could index JavaScript pages. Oh. Remember? I remember. I hated JavaScript back then as well. Surprise. And I set up a headless Firefox that was doing server-side rendering. Oh, that was a long time ago. That sucked so much. I'm shocked, shocked, I tell you. Yeah, it's so weird. And then we found someone else to also help us with JavaScript at some point. Ooh, Martin. That was such a weird, weird thing. I got contacted by a recruiter at some point. And then Ilya reached out to me like, hey, I saw that you're in touch with a recruiter on this position. And I'm like, yeah, but I still don't fully understand the position because it was like web content ecosystem. And it was really vague. And I'm like, sounds interesting, but I'm not exactly sure what's happening there. And then I asked Ilya. And Ilya was like, oh, you know, this is not so much about the web platform and JavaScript. This is more about search and SEO and maybe news and maybe a little bit of assistant. And I'm like, OK, sounds less interesting. And then I had a conversation with you, John. And I think we went for lunch because I was in Zurich at the time and you all have also been in Zurich. And then I asked about the position and it's like, yeah, it's a lot about JavaScript and the web and Chrome. And I'm like, oh, OK, this is misleading. This is weird. And then I asked all of you what a typical day looks like. And I got the least satisfying response, which was like, there is no such thing as a typical day. It can be whatever. And I'm like, well, thanks. That's helpful. And then I was going through the interviews nonetheless. And then once I got the offer, I was like, I'm still not sure what the hell I would be doing. And I figured out that you all were basically super pros in how Google Search works internally. And I had no idea. And I couldn't see myself being super helpful in that regard. So I remember this moment that sealed the deal for me was when I asked you, I think, either during our second lunch or after our second lunch, OK, but why me? And then you're like, because you're a web developer and we need to figure out this JavaScript thing. And I'm like, oh, yeah, that makes sense. Oh, yeah, that's actually pretty cool. So yeah, that's how I got my mission and how I signed the contract in the end. Probably also a big mistake for you all. I'm sorry. You are way too optimistic and way too happy all the time. It's kind of annoying. I'm kind of balancing someone else then, I guess. It's a fantastic team. Don't worry. It's like everyone fits in. That's just like your opinion. I'm super happy to be part of this team. I like you all. Of course you are, Martin. Ah, it's wonderful. And it's quite cool that we get to help so many webmasters all around the world. That's really interesting, at least to me. That's interesting. Yeah. Maybe I help you with a plug-in scary. So how is the JavaScript stuff working out now? Do you think we have it all solved? It's like no more bugs. Oh, my. Definitely not. The biggest thing I learned in the last two years at Google is that developers and SEOs are both extremely creative in building things that don't work in interesting ways, like it's quite fascinating. Most of the things are fantastic ideas on paper. And then you implement them. And then you find out, oh, it doesn't work the way that you would expect it. Sometimes that's because the creativity is misplaced. And sometimes it's because we're just having glitches. Like recently, I think it was on Twitter. I think Gary made me aware of it. So someone was asking about discus comments, I think. And that's not something that is very specific to discus, by the way. It's basically websites using a third party to pull in content that they care about. This can go wrong for many different reasons. In this case, it was a glitch on our side. We found out what the glitch was, fixed it. And basically within a day, we had it back working. But I think this kind of started a larger discussion as to how you should do things when it comes to JavaScript and critical content from third parties. Because the challenge is that you as a website owner don't really have control over a third party. And if you are using client-side JavaScript to pull in content from a third party in the browser, things can go wrong. They could robot their JavaScript API and then we can't make the request or maybe their service are really under load. And then we decide not to make these requests to the third party because they are already experiencing high load situations. And there are usually ways of doing this on the server side. So if the third party exposes an API that you can interact with from the client side, from the browser with JavaScript, you can very likely also do that on the server side and then basically avoid these problems because then your server controls what happens when in terms of when the data comes in from the third party. But I think not as many people do that. And I would hope that people are kind of warming up to the idea of doing that instead of doing everything in the client side. So is it a bad idea to rely on third parties or is it just you have to be careful? It's an okay idea to rely on third parties. You just have to be careful and you have to understand that in the browser you have very little control over what happens and how it happens. And if you are relying on Googlebot to do the heavy lifting and figure out how to get the data from the third party, then you are less in control than when your server does that work because your server is an environment that you have control over, hopefully. That sounds a bit like Gary's problem with the plugins where if the plugins are doing one thing and you're trying to do something slightly different than kind of balancing the offloading of writing code to whoever is making the plugin versus being able to choose exactly what you want to do. Yeah, yeah. And I guess for many people, it's fine. I think if you are pulling certain pieces of content, I don't know, like comments or something, and you don't really think that they are your main content, then I think it's fine to just go with an off-the-shelf solution with a third party that may or may not work well in Googlebot and other browsers. But if you want to have control over things like Gary wants to have control over the structured data on his pages, then I guess you want to run that on your server in a controlled environment. So, Martin, I was taking notes while you were speaking and I just wrote down one thing and that do not use JavaScript exclamation. Did I summarize right? No, not really. But I mean, for your point of view, JavaScript is evil, so I kind of see where that's coming from. But then I think you can use JavaScript. It's kind of fine. But you know, if you don't want to, then don't. By the way, JavaScript can run on the server side, just FYI. Because that's such a great idea, yes. It's a fantastic idea. You could, hypothetically, so there's a thing that lets you run PHP in JavaScript, so you could do that. Brilliant. Yeah. And then there's a thing that lets you run JavaScript in PHP. So you could, like, build a fantastic stack. Don't give him any better ideas. I mean. Then rolling my eyes. He already started with a CMS that was built on top of Google Docs, which is built on JavaScript. So I don't know. It's a great thing. No, no, no. I was actually doing with that what Martin was saying, that pull the content on server side. Good boy. And that actually worked excellently. Good boy. Until things started to slow down. But that was out of my control. That was probably before speed was a ranking factor. So you were probably OK. Probably. Oh, no. You said it. You said the bad word. Oh, my God. Because of ranking. Is ranking a bad word now? Well, this killed the discussion, all right? No, no, no, no. Well done. So one last thing, Gary, I guess, with regards to indexing the comments, because discuss is basically comments from other people. Is that generally a good idea or a bad idea? Should sites kind of block the comments from being shown? Or should they get them indexed? I mean, it depends on the comments, right? Like you can have comments that are like super useful and worth having them in the index and having them help you rank for certain things a little, at least. But then you go to certain blogs that are, I don't want to say, that will be R rated then. You go to certain blogs and you read the comments and you just want to take a spoon and just eat ice cream. I don't know. Just pop out your eyes or something. Yeah. Like it's just really bad. In those cases, you probably don't want the comments. Also, I think we said this before, but depending on where the content is on the page, it might weight less than, for example, content that's in the centerpiece. Like, for example, if we can detect that the meaty part of the content is in the middle and between these sections, then very likely that that will be the pooling content for your ranking, meaning that that will help you the most with topicality, with relevancy, I guess. And then if we detect that something is outside that boundary, then that will weight less. And it will help you less with ranking. And then you have, for example, footer where generally people just put a bunch of links. We kind of detect that that's not that useful for users. And so it doesn't help you all that much with ranking. OK. So it sounds like if suddenly the comments of a site started to get indexed, it's something worth kind of looking at, but it's not probably not your highest priority to figure out, like, do I need to, I don't know, clean out all of the comments and all of my old posts. It's like, it's OK to look at it, but it's not critical. Yeah, sure. I mean, there is one corner case where you probably want to look at it. And that's how many, for example, F-bombs people drop in the comments and how R-rated the comments are. Because if you are writing about cookies, for example, lemon cookies specifically, and there are a few thousand comments below your recipe that are all of them R-rated, then that might easily confuse our safe search algorithms, for example. And then your content wouldn't do so well when safe search is on in Google Search. Fun. And links just use rel, UGC? Rel, nofollow UGC. If you want to help, I would definitely use nofollow just to make sure that you are following the guidelines that you learned by heart before you got hired, Chan. Thank you. OK. Cool. Oh, my. All right. Well, this was really interesting. I kind of like the excursion into understanding what to do with comments. I think we can take a break here. It's been great doing this session with you all, looking forward to seeing how your cookies turn out, Gary. And maybe hearing a review from Martin in the form of a comment on a blog post at some point. I'll comment on Gary's blog. They will be epic. They will be epic. I will not have comments on my blog. Then I'll comment on Twitter. That you already do. Does Twitter get indexed? I think so. Let's not go there. OK. All right. Well, thanks, everyone, for listening in. I hope you found this useful and insightful and a little bit entertaining, perhaps. Hopefully I'll see you all again, or rather, you will hear us again in one of the future episodes. And until then, bye, everyone. Bye. Have a day.