Demystifying SEO for developers

0:04JOHN MUELLERer. JOHN MUELLERER CHOEH - Hello, and welcome to a new episode of Search Off the Record, a podcast coming to you from the Google Search team where we talk all about search and maybe have some fun along the way. My name is John Mueller. I'm a search advocate here at Google in Switzerland. And today, we have with us Martin, who is also on my team. Say hi, Martin. MARTIN OMANDER MULLERER CHOEH - Hi, John. JOHN MUELLERER CHOEH - Woo-hoo. Great to have you here. So I recently went to an event where there were lots of developers. And we talked about websites and kind of developer-y questions.

0:49You've talked with a lot of developers yourself, Martin. MARTIN SPLITTMANNIKI I am a developer myself, so yeah. JOHN MUELLER Oh my gosh. You're even one of those. MARTIN SPLITTMANNIKI I'm one of those. JOHN MUELLER You write code. OK, well, I got a bunch of questions and ran into some weird misconceptions that these developers have. And I think it's kind of natural if you're not so embedded in the world of SEO. You're just making websites, and you hear along the way kind of like what you should be doing for SEO that you don't really know what actually matters or what is kind of a myth. JOHN MUELLER, does that make sense?

1:32So I thought we would talk through some of the misconceptions or myths that I have seen and maybe you've seen as well. JOHN MUELLER, Yeah, so many. Where do we even start, John? Should I just go with some of the things that I was wondering or I believed when I was a developer, not really taking too much care of SEO? JOHN MUELLER, Sure. Let's go for it. I mean, it literally starts right there. As far as I was concerned at the beginning of my career, why would I need SEO? I just build the website and then people will come, right? Why would I need SEO? Do we even? Why? Why? Why do you need SEO? It's like, why do you need search engines or why?

2:23No. Oh, I mean, search engines automatically will find what I do and show it to the people who I want to reach, right? JOHN MUELLER, maybe. Maybe if you're doing things right, on the one hand, you could intuitively just do the right thing, and it just kind of works for search. But you never really know. It's like, are you doing everything right? So it's like you kind of have that unknown aspect there. But I think sometimes SEO is also not so much about purely technical things that you do, but also kind of a mindset. What? What do you mean SEO is technical? No, it's like a checklist I just have to run through and get my T's dashed and my I's dotted, and then I'll be fine, right?

3:11And then you rank for everything, right? Yeah, number one. You have a blog post about JavaScript. It's like, show up first when someone searches for JavaScript. Yeah, that makes perfect sense in my book, no? Like, everyone should. My website is clearly perfect and the best thing ever. And I'm using the latest and greatest technology. And it performs really well. So you're saying it's not technical. Then what would you like developers to understand about the non-technical side of things? Well, I guess it's also a question of, is this like a developer who's just writing the front end or who's actually creating text on these pages?

3:55Which might be a different situation. Because if you're just creating the framework for someone else to put the text on a page, then maybe you don't have to think so much about the kind of marketing decisions along the way. It's like, who do I want to target? What do I want to write on my pages? Right. I think that makes sense. In startups, it might actually be that it's kind of like a one-person-does-it-all situation, but oftentimes you have larger teams. And I think that's the answer that developers don't necessarily realize, that they only lay the technical foundation for someone else to put the content in, usually.

4:37Yeah. Yeah, so I guess if you're writing a blog post yourself on your own website, then you kind of do both things. But I think it makes sense to kind of separate those aspects out. Yeah, and with regards to making a website, I mean, there are lots of ways that you could kind of do it right, but it also feels like it's easy for developers is to skip over things that kind of matter for SEO. I mean, it starts with things. Every developer knows this joke. Like there's, what was it? There's three things that are hard in computer science. One is naming things. The other one is off by one arrows. And see what I did there?

5:26And naming things is actually one of these things. Like when we say naming things, we think of like variables and functions and modules and libraries and all these kind of things but it starts off with how am i talking about the things that i offer um am i using the terminology that my potential customers would use and do i have the answers to the things that they will ask if my website doesn't have these answers then that's a problem and oftentimes that is what gets forgotten i think and very very good point so So it's not all technical. MARK MANDELAVSKY - Yeah. MARK MANDELAVSKY - All right. MARK MANDELAVSKY - So where do you start when you have an HTML page?

6:08What do you start with as a developer? MARK MANDELAVSKY - Well, if you ask developers what they start with, it's obviously like laying everything out and probably bootstrapping whatever technology they are using and setting up the stack. And one of the things that usually gets put into SEO chapters when it comes to setting up any kind of tech piece is, oh, SEO is two things. One is titles and the other one is meta descriptions. And if you have those, you are done. Yeah. I think you can get pretty far with those. I think it's important for developers at least to realize that these can be very visible aspects, which sometimes it feels like people are either forgetting them or filling them with keywords where they're like, oh, title, that means here's my list of keywords, when they could actually be using the keyword meta tag instead.

7:12JOHN MUELLER Yeah. Yeah. Yeah. I'm sorry. Keywords. Oh, god. So what would you say are some technical things that you would like developers to understand, like what they should have nailed down? So I think, first of all, don't use the keywords meta tags. That was kind of a joke. None of the search engines use the keywords meta tags. So you don't have to either. I mean, you can, but you don't have to spend any time on it.

7:49Another misconception, I guess, that I sometimes see from developers. So I was with an audience when I was talking about some of these things. And I asked them, is bad HTML bad for SEO? Oh. And you could really tell there was a split in the audience. Like, half of them were, yes, it's terrible. well, bad HTML is bad. You should fix it. There's no way search engines can work with bad HTML. And the other half is like, I don't even know what is bad HTML, which I think was kind of the split between developers and non-developers. But I don't know. MARTIN SPLITTENBERG, I think even within developers, there is a bit of a split.

8:36And I think some of that stems from the fact that we like our data well-defined and html can be relatively well defined but doesn't have to be right and then there's like these horror tales of ooh but broken html will get you all sorts of problems that are really really hard to fix uh and i think the the real answer to that is probably somewhere in the middle right yeah so you should have as clean html as possible but if it's slightly broken, you might get away with it? MARTIN SPLITTENBERG, Yeah, that's kind of also what I said. I mean, first of all, it's like it doesn't have to be perfect. It'll still work.

9:20Search engines have to deal with whatever broken HTML is out there. I also mentioned a study that Jens Meiert did, who was one of the first Google webmasters who actually He wrote things like, I don't know, working on the home page, the HTML for Google. He did a test or analysis last year where he found out 0.5 % of the top 200 websites have valid HTML on their home page. So just the home page, 0.5%. And 0.5 % of 200 is one. So one site had valid HTML on their homepage out of these top 200. Yes. What? So crazy. Because he's so proud of his craft of writing HTML, which I think is great. Yeah. And he's like, what is happening?

10:20Like, the world is going downhill. Nobody cares about valid HTML anymore. Yeah, but that's because it doesn't matter as much anymore, I guess. I guess. It never mattered too much. I think this is like, so what I like about the web, actually, is that it's very tolerant towards technical problems, right? So once a website is mostly downloaded and the connection cards, it doesn't matter as long as most of the text and HTML is there, you'll probably see some version of a website. Maybe it's black and white and doesn't have any nice styles if those haven't downloaded or can't be like fetched. It might not have all the image data available, but you see something that you can probably get away with most of the time.

11:09I recently had that with like a Wi-Fi login page where for some reason like the Wi-Fi was really slow, but the login page at least like gave me the form and I could just click on yes, sure, whatever, and then I could use the Wi-Fi. So that's nice. And that's according to Postal's law, I believe it is called, that you should be very forgiving with any inputs that you're getting, but not very forgiving with what you're producing as an output. And I think browsers are pretty good at figuring out what the hell you meant, but still sometimes it goes wrong. And that's like this infamous iframe in the header kind of thing where some JavaScript in the header produced an iframe and then a lot of header information moved to the body and was ignored.

11:54So sometimes it doesn't go so well, But most of the times, it's actually quite OK. JOHN MUELLER - Yeah. I also talked about the metadata aspect, where if you have something that needs to be machine readable and it just can't be parsed properly, then that's broken in a way that it can't be used. But if it's the visible text and you're not using the tags properly, most of the time, that's fine. But again, structured data or titles or descriptions, even robots meta tags, if they break, then probably they're not going to do anything in your favor, which doesn't mean that the page won't be indexed.

12:38But whatever additional stuff you were trying to do there won't work. MARTIN SPLITTENBERG Yeah, I mean, it also makes sense to look at what does it mean does not work. So if something is written in a way that isn't HTML compliant, then the browser will make assumptions. And depending on what kind of assumptions it makes, so for instance, if you have some text that is wrapped in an incorrect, like instead of div, you write biv or something like that, it will still show up as text. It will not look the way that you intention it to look like, probably, because the CSS might be targeting div elements, and the biv element is an unknown element and not a div element.

13:17So it might look differently. if you get lucky and the style sheet is very flexible, it might even look right. So that can happen. But if you have a robots no index or you want to have a robots no index and for some reason it doesn't have a robots no index, then something that you don't want indexed gets indexed. Or worse, if you have a problem on your IT setup, on your technical setup that injects no index where you don't want it, then it's not going to be indexed. So I think the broken HTML and something wrong can even have multiple layers, right? It's like, is the data wrong? Is the text that is being shown wrong?

13:57Are the images wrong? Then that's just wrong and there's nothing anyone can do about it. Or is there just like a tag missing or a typo in your code or like an incorrect CSS class or something like that? Then these things can be tolerated. Yeah. So when did you last validate your site's home page? That has been a really long time ago. I should probably, you know what? I'm going to try that out. It's validator w3c. Yeah, they do w3c. OK. I'm going to try and see what happens here. Chances are, if you haven't looked in a while, it's like, it always finds something. No. Oh, perfect code? No, here there's an image without a source attribute.

14:50And that's because it uses some lazy loading thing, I believe. Oh, OK. So like one thing that is wrong. Oh, that's really good. That's not too bad. I'm actually. Wow. OK. That is surprising. Pass this round, Martin. Lucky me. Lucky me. Woo. So you mentioned CSS class names. Do you have to put your keywords in there too? JOHN MUELLER, No, please don't. No. All of that is just like technical information. Don't. JOHN MUELLER, What about HTML comments? Can you put your keywords there? Does Google read them? JOHN MUELLER, I mean, we read them because we download the HTML, but we don't process it. So no.

15:38Oh, no. So could you put something totally off topic in there, or will that get you in trouble? I think you can actually put something totally off topic in the comments, and we probably would ignore it. I don't actually know that for sure, but it's in the comments, so why would we care? Yeah. I don't think we care. I think we strip them out, actually. I think Converter strips them. I'd have to double check that in the source code. It's a really good question. But now we discovered the secret to SEO. There was something else that we discussed in an earlier episode, in case people haven't heard that one yet.

16:15That was really interesting. The way you asked the question, like, so does Google read them? I love that because that's such a reasonable question coming from someone who has like a specific frame of mind. But it's such a sneaky question because, yes, we read them as we download them from the Internet, but we don't process them. So it's such a tricky thing again. I love that. OK, so Google reads my HTML comments. But hopefully it doesn't judge me for what I put in there. I hope not. Now I have to check my page. I think it's fine. I think this will be fine. This will be fine. OK, cool. So I think HTML-wise, we kind of looked at some of the things there.

17:02One of the things that I sometimes hear from developers or from people who are using things like WordPress is, does it matter which theme I use on my site? Are there themes that are more or more better for SEO and kind of like optimized for SEO or themes that are bad for SEO? And what did you say? I told them, of course, there are well-optimized themes for SEO. It's like, you can boost your SEO with a good theme. What? What does that mean? What does an SEO optimized theme look like? It's true. I understand. But what do you mean? Do you mean like these themes make sure that they present the content right?

17:51Or are they just having perfectly valid HTML? or what is in a theme that is SEO optimized? Well, I mean, a theme is basically the way that the content in the database is presented, right? It converts it into HTML. And of course, you can make HTML that works well or is easy to understand for search engines and HTML that is hard for search engines to understand. And so kind of like as a simple thing could be things like headings. Like maybe you have headings on the page, or maybe you just have some weird CSS that says, put a really big font here. Which they could look the same, but technically, they're slightly different.

18:41They're different. That's true. Yeah. The way that images are being embedded is probably also playing a role. Yeah, exactly. Images or what kind of like how big your header and footer are, if that's like this giant super menu kind of thing. All of these kind of aspects where essentially the HTML that is generated in the end, it depends on the theme. So of course, it's like, on the one hand, you can break your SEO with a really bad theme, but you can also essentially boost it by having a good theme. But we, but I mean, like boosting your SEO sounds very snake oilsy. Because it might be misunderstood.

19:26I think if you had a bad theme and you had like diff soup, as we developers like to call it sometimes, so diffs over diffs over diffs, rather than actually having any semantic information like this is a section, this is an article in this section, this article has a headline, and so on and so forth. Then yeah, you improve your SEO just by switching from one theme to the other. But it doesn't mean like you have a great SEO optimized theme, and now you can like get more than someone else doing the same thing. Like, no, it's not a magical bullet that fixes all the problems. Yeah, yeah. It lays the foundation, yeah.

20:09Yeah, but I think it's useful for people to realize that you can't just randomly change your themes and assume everything else will stay the same. Because the words on the page are the same, but there's a lot more involved with regards to SEO than just the words on the page. Oh, yeah. Oh, yeah. Yeah, that is correct. But while we are at the technical level, that's another thing that I find interesting because developers love something that you can measure. So I can measure the lines of code even though it doesn't make sense. Like less lines of code are not necessarily better nor worse. So if I have like one line of code that no one can read that does like 20 things in one go, that's bad.

20:55If I have a thousand lines that could have been 10 lines, that's also bad. So we love to see scores and things that we can quantify. And I think that's what happens with Core Web Vitals. Do you see that? Did you get a question for Core Web Vitals? Yeah, yeah, definitely. There was a session just before mine about Core Web Vitals. Oh, great. So, of course. It hurts me every single time because I love the Core Web Vitals. They help us make sure that our websites work for actual users. And if we look at real user metrics, we find out if they do or not. And we should absolutely measure this. But just as a SEO silver bullet, it's just as weird, isn't it?

21:40Yeah. I mean, we've probably done half of the podcast episodes about how Core Web Vitals is not the solution to everything. And yet people are like, but my website has better Core Web Vitals than my competitor. Like, OK. JOHN MUELLER - I think, to some extent, looking at your Core Web Vitals makes sense, because it's easy to spot situations where you accidentally break something, where it's like suddenly the scores go really bad, and then you can dig in, like, well, what actually happened here? So it's, I think, a useful metric, but it's not something that maps one-to-one to SEO. And I think it's misleadingly useful in that it gives you the score, and developers love scores, and other people also just love gaming numbers.

22:30So it feels like, oh, I should maybe go from 85 to 87, and then I will rank first. But it's a lot more involved. MARK MANDELAVYSCHENKOVICHER It's a bit more complicated than that. That's true. Yeah. MARK MANDELAVYSCHENKOVICHER But JavaScript just works, right? Right. JavaScript, of course. Wow. Who are you to say JavaScript just works? That's what you always say. It's interesting because that's not true. It depends on who I'm talking to. It depends. MARK MANDELAVYSCHENBAUMENOVIC. Yeah. If you do it right, it does. If you do it wrong, it doesn't. And wrong is a very tricky categorization here because it can do what you think it does or is supposed to do, but then it stops working in search engines and then, or doesn't work the way that you intended to work in a search engine.

23:27Yeah. Then it gets confusing. So that's an interesting one. JOHN MUELLER - Yeah, I think it's tricky for developers because in the olden days, they were taught that JavaScript doesn't work for SEO. And now they hear from Google, oh, JavaScript works for SEO. And then any SEO that comes to them and says, oh, you have some JavaScript here, and you have a JavaScript menu, or you even use a JavaScript framework. Mm.

24:00Now developers are like, well, Google says it's OK. Google can deal with JavaScript. JOHN MUELLER, And generally, that is true. Yeah. JOHN MUELLER, Yeah. That's, I think that's challenging. So what would you tell developers to do? Is there a simple way to test if their JavaScript is OK? Or do they have to watch out for certain API calls? Yeah, we have documentation for that on developers.google.com.search. If you look for JavaScript there, you have some caveats that you need to be aware of. And you can test it quite easily. You can plug a URL into one of our testing tools and sort of like URL inspection tool in Search Console or the rich results tests.

24:46And you can see if the content that you care about is showing up in the rendered HTML. If it's there, you'll be fine, generally speaking. What I find particularly tricky is that I have to tell developers, hey, please use JavaScript responsibly and don't use it for everything and use it where it makes sense only. So I'm more or less telling them, use less JavaScript, please. At the same time, SEOs panicking and freaking out about JavaScript cause real-world situations to deteriorate for no good reason, as in like they have a working website, everything can be indexed, everything is indexed, everything is fine.

25:27And then someone comes in like, I heard somewhere JavaScript doesn't work with Google search, so we need to like rebuild everything, which effectively means like, let's tear down this, I don't know, skyscraper and build it completely from scratch, which is a huge undertaking for no reason whatsoever. So I have to tell SEOs, no, JavaScript is fine. It's OK. Yes, it is OK. Calm down. So it puts me in this weird position where both sides hate me. It's great. I would love more nuance there. But yeah, it's tricky. I guess having people understand that it's tricky at least encourages them to use the testing tools.

26:13And it's like, OK, I have to be cautious. I will double check, watch Martin's videos, and see what he does. And it actually adds to the answer, why do I need an SEO? Because developers look at different things. So if you look at someone who makes statues, who sizzles out statues from blocks of granite, for instance, or marble, they look at different things, whereas someone who's getting this from a mountainside, they probably are from some sort of quarry, they look at the same material, but differently. And it's kind of like that. So SEOs look for different things than developers look for. And I think that just needs teamwork.

26:57Simple as that. It's a lot of work to do. FRANCESC CAMPOYOVICHERSON - Cool. One of the things that I heard is developers love APIs. Is that about right? FRANCESC CAMPOYOVICHERSON - Yeah. Oh, yeah. APIs are great. I just make a call to an API. I get a response back, and then I know what's going on. It either worked or it didn't. If it didn't work, it tells me why. I love it. That's great. So if you have an indexing issue, you just call Google's indexing API, right? JOHN MUELLER, Oh, that's amazing. Can I do that? That is awesome. That is amazing. I just have a list of all the URLs. I just ping them to the API, and I get an OK back, and that means they're indexed.

27:33That's awesome. Does it work like that? JOHN MUELLER, Hold on. No. JOHN MUELLER, No. So we do have an indexing API, but it is for two very unique types of content. On the one hand, it's job postings. So if you're saying it's like you want to hire people, maybe you could use it. And the other is live video broadcasts, which is also kind of like a very unique category of content where content has to be kind of like updated very quickly. And for everything else, like a blog post, the home page, an e-commerce site, anything, the indexing API does not work. So of course, you can call it, but it's not going to do anything.

28:23JOHN MUELLER, that sounds a bit pointless then. Why do I even bother with it? JOHN MUELLER, you don't. You don't have to. Like, if you don't have a site that does these two things, don't bother with it. JOHN MUELLER, OK, fine. JOHN MUELLER, I'm sorry. OK, one last thing. I know we're kind of running low on time, but there's a variety of Google code things that you can embed on your site. So for analytics, ads. JOHN MUELLER, Angular. JOHN MUELLER, Angular is a framework. You can build your thing on Angular. I heard that multiple times. If I build my website with Angular, it's going to work in Google Search, right?

29:08MARTIN SPLITTMANNIKI, Oh, because Angular is also from Google. I don't know. Or is it open source? MARK MANDELMANNIKI, It is open source. MARTIN SPLITTMANNIKI, Oh, open source and from Google. Oh. So then it must rank first. MARK MANDELMANNIKI, Does it? Does it? Breaking news here? Use only this framework? No. MARTIN SPLITTMANNIKI, Yeah. I think developers, for the most part, understand that there is nuance, right? MARK MANDELMANNIKI, I hope so, yeah. And just because one technology is from the same company that also happens to run a search engine doesn't mean that it's automatically optimized for search engines or that it won't cause any problems.

29:49That's true. Yeah. So no benefits. I think it's even worse than no benefits. But if you overdo it with some of these things, then, of course, you can have negative effects as well. Like if you embed all of the possible JavaScript snippets from Google possible on a website, then it's going to be really slow. And maybe it'll even have problems rendering. And then. That's mean. Google should never have problems with Google stuff. Never. I kind of agree. But it's a big company, you know? It's a big company. And the world out there is complex. So you can't account for every situation. Yeah. And even within Google, there's lots of people who are like, I don't know how to do something for a search engine.