Demystifying SEO for developers

[Music]
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's also on my team.
Say hi Martin. Hi John. Woohoo. Great to
have you here. So I recently went to an
event uh where there were lots of
developers and we talked about websites
and kind of developery questions.
Um you've talked with a lot of
developers yourself, Martin.
I am a developer myself. So yeah. Oh my
gosh. You're even one of those. I'm one
of those. You write code?
Okay. Well, I I got a bunch of questions
and ran into some weird misconceptions
that uh these developers have. And I
think it's kind of natural if you're not
so embedded in the world of SEO. uh
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. Mhm. Does that
make sense? Um so I I thought we would
talk through some of the misconceptions
or myths that I have seen and maybe
you've seen as well. There are so many.
Where do we even start, John? Should
should I just go with some of the the
things that I was wondering or I
believed when I was a developer, not
really taking too much care of SEO?
Sure, let's go for it. I mean, it's it
literally starts right there. Um, 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 do
we even is why Why? Why? Why do you need
SEO? Is like why why do you need search
engines or like why? No, I mean like
search engines automatically will find
what I do and show it to the people who
I want to reach, right?
Well,
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. Mhm.
But you never really know. It's like are
you doing everything right? So it's like
kind of have that unknown aspect there.
But I I think sometimes SEO is also not
so much about purely technical things
that you do but also kind of a mindset
where it's like what do you mean SEO is
technical? No, it's like a checklist I
just have to run through and get like my
te's dashed and my eyes dotted and then
I'll be fine. Right. And then and 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 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 So you're saying it's
not technical. And what
would you like developers to understand
about the nontechnical side of things?
Well, I 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, which
which 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. That I think that makes sense. In
startups, it might actually be that it's
kind of like a a one person does it all
situation, but often times you have like
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. Yeah. So, I guess if
if you're writing a blog post yourself
on your own website, then you kind of do
both things, but I think it it makes
sense to kind of separate those aspects
out.
Yeah. And with regards to making a
website, it's like I mean, there are
lots of ways that you could kind of do
it, right? But it's it also feels like
it's easy for developers 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 uh
three things that are hard in computer
science one is naming things the other
one is off by one errors and um
see what I did there um and uh 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 often times that is what gets
forgotten, I think. And um, very very
good point. So
it's not all technical. Yeah. All right.
So where where do you start when when
you have an HTML page? What what do you
start with as a developer? Well, if you
ask developers, what they start with is
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 uh SEO is two things. Uh one is
titles and the other one is meta
descriptions. And if you have those, you
are done. Yeah,
I I think you can get pretty far with
those. Uh I think I think it's important
for developers at least to realize that
these can be very visible aspects
uh 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. Mhm.
Yeah.
I'm sorry.
Keywords. Oh god. So what would you say
are like some technical things that you
would like developers to understand like
what they should have nailed down? Um so
I think first of all don't use the
keywords metatags. That that was kind of
a joke. Um I none of the search engines
use the keywords meta tag. So you don't
have to either. I mean you can but you
don't don't have to spend any time on
it. Um, another
misconception I guess that that I
sometimes see from developers. So I I
was with an audience when when I was
talking about some of these things and I
asked them like 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. Like bad
HTML is bad. You should fix it. like
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 Okay. Mhm. I don't know. I I think
even within developers there is a bit of
a split. Um,
and I think some of that stems from the
fact that we like our data well
definfined and HTML can be relatively
well defined, but doesn't have to be,
right? And then there's like these
horror tales of, oo, 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. Mhm.
Right. Yeah. So, you should have as
clean HTML as possible, but if it's
slightly broken, you might get away with
it.
Yeah, that's
kind of also what what I said. I mean,
first of all, it's like it doesn't have
to be perfect. It'll still work. Search
engines have to deal with whatever
broken HTML is out there. Um I I also
mentioned a a study that Yens Meyert did
who was one of the the first Google web
masters who actually wrote things like I
don't know working on the homepage the
HTML for Google. Um he he did a test or
an analysis last year where he found out
uh 0.5% of the top 200 websites have
valid HTML on their homepage. So just
just the homepage 0.5%.
And like 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 he's so proud of his craft
of writing HTML which which I think is
is great. Uh and he's like
what is happening? like 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
um it never mattered too much. I think
this is like a 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 like 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. Um, I 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.
Uh, and that's according to Postal's
law, I believe it is called, um, 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. Um, 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 I frame 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. So sometimes it doesn't
go so well, but most of the times it's
actually quite okay. Yeah. I I also
talked about the the kind of 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 like
the visible text and you're not using
the tags properly like most of the time
that's fine. But again, like 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, but
like whatever additional stuff you were
trying to do there won't work. Yeah. I
mean, it also makes sense to look at
like 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 or something like that, um 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 diff elements and the BIF
element is an unknown element and not a
diff element. So it might look
differently if you get lucky and the
stylesheet is very flexible. It might
even look right. So that can happen. Um,
but if you have a robots no uh 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? Is are 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 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 homepage? That has
been a really long time ago. I should
probably You know what? I'm going to try
that out. It's uh validator
W3C.
Yeah, they do. W Yeah. Okay. I'm going
to I'm going to try and see what happens
here. Uh I'm I'm Chances are if you
haven't looked in a while, it's like it
always finds something.
Um
No, it it does. code. No, here there's
an image without a source attribute
and that's because it uses some lazy
loading thing I believe. Oh, okay. So,
like one thing that is wrong. Oh, that's
that's really good. That's not too bad.
I'm actually Wow. Okay.
This round, Martin.
Lucky me. Lucky me.
So, you mentioned CSS class names. Do
you have to put your keywords in there,
too?
Uh, no. Please don't. I No. All of that
is just like technical information.
Don't. What about HTML comments? Can you
put your keywords there? Does Google
read them? I mean, we read them because
we download the HTML, but um we don't
process it. So, 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 called totally off topic in
the 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. Yeah. I
don't think we care. I think we strip
them out. Actually, I think converter
strips them. I have to double check that
in the source code. It's a really good
question. But now we discovered the
secret to SEO
comments. There was something else that
we discussed in an earlier episode if in
case people haven't heard that one yet.
Um, that was really interesting. The the
way you asked the question like so does
Google read them. I 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, ah, it's such a
tricky thing again. I love that. Okay,
so Google reads my HTML comments,
but hopefully it doesn't judge me for
what I put in there. I now I have to
check my page. I think it's fine. I
think this will be fine. This will be
fine. Okay, cool. Um, so I I think like
HTML wise, we kind of looked at some of
the things there. Uh, one of the things
that that I sometimes hear from
developers or from from people who are
using things like WordPress is,
uh, does it matter which theme I use on
my site? Are there themes that are more
or more better for SEO? Kind of like
optimized for SEO or themes that are bad
for SEO. And what did you say?
I told them, of course, they're well
optimized themes for SEO. It's like you
can boost your SEO with a good theme.
What? But what does that mean? What does
an SEO
optimize look like? It's true. I
understand. Yeah. But like, but what
what do you mean? Do you mean like these
themes make sure that they present the
content right or are they just haha
having perfectly valid HTML or like
what's what is in a theme that is SEO
optimized? Well, I mean a theme is is
basically the way that the content in
the database is presented, right? It's
like it's 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. Um, so kind of
like as as a simple
uh 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 like
technically they're they're slightly
different. They'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. Um 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 Yeah, but I mean like
boosting your SEO sounds very snake oily
be because it might be misunderstood. I
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. um 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 that's that's not it's not a magical
bullet that fixes all the problems.
Yeah. Yeah. It lays the foundation.
Yeah. Yeah. But I think I think it's
useful for people to to realize that you
can't just randomly change your themes
and assume everything else will stay the
same because like the words on the page
are the same. But that's like there's a
lot more involved with regards to SEO
than just the words on the page. Oh
yeah, that oh yeah, that is correct. But
uh
when we 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. If 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 there was
a session just before mine about core
web vitals. Oh great. So of course um it
hurts me every single time because I
love the core of 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? Yeah. 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, okay, I I think to 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 what actually happened
here. M so it's I I think a useful
metric but it's not something that maps
one to one to SEO and I I think it's
misleadingly useful in that it gives you
the score and developers love scores and
like other people also just like love
gaming numbers so it feels like oh I
should like maybe go from 85 to 87 and
then I will rank first but there's a lot
more involved It's a bit more
complicated than that. That's true.
Yeah. Yeah. But JavaScript just works,
right? JavaScript of Wow.
Who are you to say JavaScript just
works? Like that's what you always say.
It's interesting because that's not
true. It depends on who I'm talking to.
It depends. Yeah. Um 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 supposed to
do, but then it stops working in search
engines and then or doesn't work the way
that you intend it to work in a search
engine and then it gets confusing. So
that's an interesting one. Yeah, I I
think it's it's tricky for for
developers
um 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. M um
now developers are like well Google says
it's okay Google can deal with
JavaScript
and generally that is true
generally
that's I I think that's challenging so
so what would you tell developers to do
is there a simple way to to test if
their JavaScript is okay or do they have
to watch out for certain API calls yeah
we have documentation for that on
developers.google.com/arch.
If you look for JavaScript there, you
have some um 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 so like URL
inspection tool in search console or the
rich results tests and 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, um 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 kind of I'm more or less
telling them, use less JavaScript,
please. Mhm. 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. And 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 uh
skyscraper and build it completely from
from scratch, which is a huge
undertaking for no reason whatsoever. So
I have to tell SEOs, no, JavaScript is
fine. It's okay. Yes, it is okay. 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
and it's like, okay, I have to be
cautious. I will double check, watch
Martin's videos and see 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 through
sizzles out statues from from blocks of
granite for instance um or or marble um
they look at different things. Whereas
someone who's like getting this from a
mountain side uh they probably from 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.
Simple as that. It's a lot of work to
do. Cool. One of the things that that I
heard is developers love APIs.
Is that about right? 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, so if
you have an indexing issue, you just
call Google's indexing API, right? Oh,
that's amazing. Can I do that? Can I
just like That is awesome. That is
amazing. I just have like a list of all
the URLs. I just ping them to the API
and I get an okay back and that means
they're indexed. That's awesome.
Does it work like that? Hold on. Um, no.
No. Uh so we we do have an indexing API
but it's for two very unique types of
content. Uh 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 uploaded
very quickly. And for everything else
like a blog post, a homepage, an
e-commerce site, anything, the indexing
API does not work. So, of course, you
can call it uh but it's it's not going
to do anything.
That sounds a bit pointless then. Like,
why do I even bother with it?
You don't you don't have to like if it
if you don't have a site that does these
two things, it's like don't bother with
it.
Okay, fine. Fine. I'm sorry.
Okay, one one last thing. I I know we're
kind of running low on time. Um but
there's like a variety of Google code
things that you can embed on your site.
Yeah, analytics. Yeah, ads. Ads um
Angular.
Angular. Angular. You can build your
thing on Angular. I heard that multiple
times like if I build my website with
Angular, it's going to work in Google
search, right? Oh, because Angular is
also from Google. I don't know. Or is it
open source? I It is open source. Oh,
open source and from Google. Oh, so then
it must rank first.
Does it does it? Breaking news here. Use
only this framework. No. Yeah. I I I
think developers for the most part
understand that there's nuance,
right? 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. That's true.
Yeah. So, no benefits. A
I I think it's even worse than no
benefits, but kind of like if you o
overdo it with some of these things,
then of course you can have negative
effects as well. Like if you embed like
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 should never
have problems with Google stuff. Never.
I 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. That's like I I can do
HTML or I can do JavaScript, but it's
like I don't know what is SEO. And they
don't have to. That's what we have SEOs
for, right? Well, we don't have a lot of
SEOs. But we have some we have a lot of
guidance for SEOs. Oh, so developers
could listen to this podcast, even
though it's from Google, and be like,
okay,
make a list. True, true, true.
developers.google.comarch
has all of you covered. That's true.
We're trying at least. Nice. Well,
that's it for this episode. Thank you
for joining, Martin. Uh, it was great to
have you here. Very happy. I hope it
helped some developers out there.
If people have more questions from a
developer mindset, where can they reach
you? Uh, easiest is probably on
LinkedIn. Don't like try to add me as a
contact. If I have never spoken to you
before, I'll probably just decline the
request, but you can comment on LinkedIn
posts from us. You can uh use our forum
uh and ask things there. Uh you can
reach out to me using messages or again
comments under this podcast posting
probably. Um you can also use YouTube
comments that also works. Oh, what about
HTML comments? Um, I don't think I'm
going to see them. So, no.
So, sorry. I filtered them out. I don't
render them.
Oh, very nice. Oh, well.
Okay. Well, there goes my secret way to
reach Martin and ask JavaScript
questions. But maybe maybe you would
respond in HTML comments as well. And
then it's like
that's a very cryptic way of talking to
each other I think. Yeah. Like on some
and and when you say that like on random
websites somewhere on the internet like
there's a comment response in one of the
comments. I'm loving that. That's
fantastic. Martin says no. And people
are like what the hell is this about?
Awesome. No thank you very much for
having me. Well thank you folks for
listening and goodbye. Bye-bye.
We've been having fun with these podcast
episodes. I hope you, the listener, have
found them both entertaining and
insightful, too. Feel free to drop us a
note on LinkedIn or chat with us at one
of the next events that we go to if you
have any thoughts. And of course, don't
forget to like and subscribe. Thank you
and goodbye.
[Music]