Which SEO tools and tests should every developer know?
MARTIN SPLITT: Why can't SEOs
describe the task that they want me to do clearly? CRYSTAL CARTER: Why
don't developers understand SEO basics? MARTIN SPLITT: Why do SEOs
give us solutions that do not work with our tech stack? CRYSTAL CARTER: Why do I have to
wait so long for my development changes? [MUSIC PLAYING] MARTIN SPLITT: With me
today is Crystal Carter, head of SEO communications
at Wix, formerly working at Optix Solutions as a
senior digital strategist, with years of SEO
experience under her belt. A Californian in
the UK, she enjoys walks in the woods,
wildlife gardening, and perfecting her
guacamole recipe. CRYSTAL CARTER: Martin Splitt is
a developer advocate for Google Search Relations team. He's a geek who loves
tech old and new. Living in Switzerland,
he also loves cheese. MARTIN SPLITT: Hello
and welcome, everybody.
With me today is Crystal. I'm super excited
to have you here. And I watched the talk
of yours a while back, and that really, really
spoke to me as a developer. And I would love to talk
to you about something that I observed coming from
the developer's perspective. Oftentimes, SEOs barge in
to the development team, and they are like,
oh my god, we need to figure out our canonicals. And there's this other problem
here with duplicate content. We're going to get a
penalty, blah, blah, blah. And oftentimes, they are
met with a blank gaze from the people
they just spoke to.
What's happening there? Why are we– we are
working on the same thing. We are all working on the
same project together. And yet we seem to be
so very, very different in terms of the
vocabulary we use. What's happening there? CRYSTAL CARTER: I
absolutely agree. This is something that I've
seen a number of times. And I think that one of
the things that's tricky is that we're sort of coming at
it from different perspectives. Sometimes if you think about
it, it's a bit like a band. Like, if you have a band,
you have your bass player, you have your guitar player,
you have your drummer, and you're all trying to
make a beautiful song. But the bass player
has different things that they need to
do, the drummer has different things
that they need to do. And sometimes they overlap,
sometimes they intersect. But really, what we
all need to focus on is making sure that we're
making beautiful music together. And so I think that,
yeah, it can be tricky. And I think sometimes
it's because people who've built the website, the
developers behind the website, are very often, they spent
a lot of time and effort putting that together.
So it's quite tricky when
someone comes in and says, oh, it's broken, oh, it's
wrong, or it doesn't work. And I think that it's really
important to think about that when you're speaking to
developers as an SEO. And one thing that I
found that's really useful is to think about
it as opportunities. So rather than
saying this is broken or this is wrong, say
"we have an opportunity to make the website faster
if we do X, Y, or Z. We have the opportunity to make
the website easier for users to access in a
different way if we do this, that, or the other." And I find that
generally speaking, if you go to it from
that perspective, then it can sort of
make those conversations a bit less brutal. MARTIN SPLITT:
Confrontational, yeah. Oh, I love that. I love framing it as
opportunities and possibilities to make things better. Because fundamentally,
that's what developers want to do in
the first place anyway.
So that's really, really cool. I like it better than framing it
as a problem or a thing that's broken or needs fixing. Because to be honest, it's
also that developers are not even necessarily aware
of these things, right? It seems to me like you are
preaching from a holy book that is written in a language
that isn't ours, and it comes out of nowhere
and out of the blue, right? One day, you're just
implementing this feature, and you're making sure it
works in all browsers, works on all devices, is fast. And then out of the blue,
someone is like, it's broken. So I like changing
that into, here's an opportunity to
make it even better. I do read up constantly
on new technologies, on new things that browsers can
do, on new trends in design.
But I don't really even know
where to get started on SEO. And I think one of the things
that us developers need to do more is get out of our
little bubble of development, and actually look at SEO, at
least at the technical side of SEO, as something that is
just part of what we deal with. Not necessarily, it's not
part of our job to do this, but like we should
know about it, I think. CRYSTAL CARTER:
Yeah, I think so. And I think Google's
really good at that trying to bridge the gap
between those spaces, and trying to make it
more clear for people to understand how that works. I think one of the things
that's really useful when you're thinking about
developing and SEO, and understanding
SEO as a developer, is remembering that with
SEO, we're essentially taking the technology that a
developer has built, and we are interacting
with it in the real world.
And users are using it in
lots of different ways. And the ways that users
are using the site, the way that users are
interacting with the site, are going to be very
different from– there'll be millions, billions of
possibilities for ways that people can access the
site, ways people will search for the site, ways that
people will use the site, from what we're able to test
in a sort of test development framework. So essentially, as soon as
we build sites at my team, and as soon as we build
a site, they always say we built the
site, can somebody run it through a few tests? And I always run it
through a few calls. And there's always a few
things that we pick up, because the SEO is
essentially thinking about– it's search engine
optimization, which means that you are
thinking about how people search for and
arrive at the site, and how people interact with
the information on the site, and how people use the site.
So SEOs will have lots of user
data based on that site itself. So let's say you're
rebuilding a new site. So we'll have lots
of historic user data about how people use the site. And then there'll also be
general sort of industry user data. So it might be that you've built
a lovely shopping framework, but we also know that within
the shopping, e-commerce space, that users have an expectation
of being able to see this and being able to
pay in this way, and being able to have a
cart that's really clickable and that sort of thing. So I think that development's
a really tricky job, because there's a million
different ways that you could build a website.
Like, there's a
million different ways that you can build an app. The possibilities are endless. So it's tricky to expect
one developer, or even one developer team, to know
every single possible way you could build a website. But when people
are using the site, that's where SEO and
development interact. And I think that developers
can speak to SEOs, and ask them for data about,
what are the sort of customer expectations for
this type of website, or how fast should it be. So for instance,
e-commerce sites tend to be a little bit
slower than other websites, and that's because they've
got lots of different tracking things on them. They've got lots
of different– oh, poor Martin isn't making it! We try! We try. But it's true.
So it's all sort of relative. We want to make sure that we're
meeting user expectations. So I think developers
can speak to SEOs and ask for more user data to
help them build ahead of time. And I think that Google
has a lot of tools that over-cross or overlap. So like, Chrome Development
Tools, I use all the time. When I'm speaking to developers,
just things like view-source can be really, really
useful in Chrome. And that sort of helps bridge
the gap between the two. And I think that where there's
the willing to understand the two different parts of
both how users are interacting with it, and how businesses
need to meet a website to work, and how it's built in
the framework and that sort of thing, that
there's opportunities for growth and
opportunities to make the web better for everyone. MARTIN SPLITT: Yeah,
and you said two things that I want to
address with you now. Let's start with the
one thing that you said is, you run a bunch of tests,
and there's a bunch of tools that developers can use.
And then the other
thing is like, there's a bunch of different solutions. And I think those are two
very interesting aspects. Let's start with the tests. Because you said, once
a website is done, I run a bunch of tests. That's what we as developers
do while we are building it. So we have a bunch of
tools that we are running to figure out bits and pieces. Like, how fast is this website? Where are our
problems coming from? Is it behaving the way that
we expect it to behave? And we actually write tests. We write test cases
such as, if I click on this button, and then I– well, if I click on this
button, I should see this thing. If I type something
into this thing and then I click this button,
something should happen. So we're having
a bunch of tests.
I wouldn't even know what
tools or tests to use for SEO. Because for pretty much
most of the things, I have stuff, right? I can run a browser basically
remote-controlled by code to click on buttons
and fill in form fields and then see what happens. But what would I
be looking for SEO? I actually don't know. And I don't know
where to find out, or what tools are
available to me. I know Lighthouse
has an SEO audit, but that seems very, very basic. So what would you
say is something that developers should look
into to support their SEO teams? What are technical aspects that
developers should be aware of? Or where would they find
out how, or what would they have to– I don't even know
what to ask an SEO. CRYSTAL CARTER: So I
would say that normally, what happens when we
launch a new site, is I'll crawl it with something
like Screaming Frog, which will give you information
about crawl errors. And then the other thing is
things like Search Console.
Search Console gives
you lots of information about the way that
Google is seeing it. Because different search
engines will have different ways that they read websites. Different bots will
have different ways they read websites. So Search Console gives
you lots of information about the way Google
sees it, and it can also give you information about how
different users are seeing it. So Page Experience
Report, for instance, is based on real
user information. So it might be that within your
test framework, that everything looks perfectly fine,
everything's lovely. But it's sometimes like if
you've ever written something, and then you try to
proofread it yourself, sometimes you don't see
your own writing things, because you've spent so
much time writing, right? Whereas if somebody else
reads it, they'll go, well, you've missed
a full stop, or you haven't said "and" there
or that sort of thing, because they've got
sort of fresh eyes.
And the other thing is
that as a developer, you're looking at it from
a developer's perspective, and you're fairly
tech-savvy, whereas users are going to be
coming at it from lots of different perspectives. So I think it's really
important to look at it the way that it's rendering
on different browsers, the way that it's rendering
on different machines, the way that it's rendering on different
mobiles and devices as well. And yeah, tools
like Search Console give you user data, how
people are using it. And once it's live, I think
once a new website is live, I think it's really
important to think about is to expect to
make further changes. And potentially expect to
make further changes even six months down the
line, because you'll have more data based on it. I think data is really
important particularly for businesses
that are seasonal, or businesses that have
sort of peaks and troughs.
So the way I think
about that sometimes is like, if you were to do data
on a tree, like, on an oak tree for instance, and you
took all your data from between May and
June, all of your data would tell you that trees are
green, oak trees are green, and they have green
leaves, and they're great. But if you do it
for the whole year, then you learn that sometimes
all the leaves fall off, and sometimes the leaves
aren't green at all.
So the more data you have,
the better you can prepare. And if you had the full
data on the full year, then you'd know that we'd
also need to buy a rake to go with the tree. MARTIN SPLITT: I love that
image, that beautiful picture you're painting. CRYSTAL CARTER: I do love
painting pictures of trees. MARTIN SPLITT:
Happy little trees. CRYSTAL CARTER: Yes, precisely. MARTIN SPLITT: We've
got Bob Ross here. CRYSTAL CARTER: Yeah, exactly. He's a legend. MARTIN SPLITT: That is awesome.
It's really nice that you
mentioned Google Search Console, because I
remember as a developer, again, coming from a developer
background, the very first time I came into contact
with it was when it was still called Webmaster
Tools, if I remember correctly. And this is going to
sound really weird. At the same time, I was
overwhelmed and underwhelmed. And it was bizarre, because I
didn't even know where to look. But I think that's exactly one
of these interfacing moments between SEOs and developers. Because if you come
to this tool and you see performance, impressions,
clicks, what's happening? Then it might be a lot
to take in at first. But I think this is
exactly where SEOs can guide the developers,
or even just provide the data that they need for
a specific conversation, to underline that
specific conversation. And I think this is
what needs to happen.
And if it happens, I remember
working with one specific SEO a long time back,
and she guided me through a bunch of the
decision-making processes that I didn't even know existed. And that was very, very helpful. And I think data collection,
as you say, like, if you look at the trees
only in the summer months, you might be very, very scared
to see all the leaves fall off. Because trees are supposed
to have leaves all the time, and you know, yeah. CRYSTAL CARTER: I think the
overwhelmed and underwhelmed thing is something that
I've encountered sometimes. So sometimes, when
SEOs to go to a dev, they say, right,
we want to make all of the title tags do this
and this, and that and that. And they go, well, that only
took me a minute to implement. Is that really important? Does that really matter? And it's like, from
an SEO perspective, it's like, yeah, that
makes a big deal, or that can make
a big difference. I've spoken to
developers and I'm like, I need you to add
this particular bit of schema markup. And they're like, well, I
just copied and pasted it.
And I'm like, well, you know,
that's fine, that's great. I'm glad that it didn't
take you long to implement. But it does have a
big impact on how Google crawls it and things. So something that's super simple
that a lot of developers miss, and something that I always
check every time we launch a new website, is the sitemap. Just literally putting a
sitemap on the website. Sometimes I explain it to people
like, if I went to a restaurant and I said, what's on the menu? If they give me a menu,
then I can figure out what's on the menu.
Or if I don't have
a sitemap, then it's like just going to the
restaurant and them just being like, yeah, you
know, have a look around, and you just see what
other people are eating. Which is essentially what
you're asking Google to do. You're asking them to guess
whether or not there's a Caesar salad on the menu. And they'll probably
figure it out. Google's very sophisticated
and everything. But it's better if
you give them a menu. MARTIN SPLITT: I
like that, yeah. Again, beautiful analogy. That's lovely. But going back to the
testing and the tooling, you mentioned a few tools and
you mentioned Search Console. Search Console, the
bigger challenge is that I, as a
developer, can only use it once the site
has gone live and Google has had a look at it. Can I use things like crawlers? Which one did you mention? CRYSTAL CARTER: Screaming Frog.
MARTIN SPLITT: Screaming Frog. And I know there's like
[? AA Traps ?] and all the others. CRYSTAL CARTER: Yeah,
[? AA Traps, ?] right. MARTIN SPLITT: Can I
use those in development as well, like before
the site goes public? CRYSTAL CARTER: Yeah,
so in a staging setting, you can use Screaming frog. To sort of understand
if you've got gaps with things like
page structure things. So for instance, h1s
are super important. I think people very
often underestimate that. That's another one
that I very often see. So people very often don't
put an H1 on the home page. And I'm like, that
is an easy win. Like, please put an
H1 on your home page. And so yeah, you can use
Screaming Frog to see a lot of different things. There are many, many, many,
many, many, many, many different layers and many
different configurations of your Screaming Frog setup. So you can see a lot of
the structural things, like headings and title
tags and meta descriptions, and the URL structure,
and that sort of thing. And you can see all of
those sorts of things. And then you can also
see the navigation and various other elements.
And Screaming Frog is
really useful with helping with understanding
how it crawled up through different pages. And so this goes
back to indexation, which is about your
website in the real world. So again, another metaphor. I speak in a lot of metaphors. But sometimes I think of it like
the developer builds a plane, and the pilot flies it. And so the SEO sort of flies it. And in the real
world, the way that it interacts with various
different things is different.
So yeah, that's something that's
really useful for understanding how the site is performing,
and how it's crawlable and how it's readable online,
and before you go live. But in a migration
setting, it's also useful. There's a couple of different
Chrome extensions that are really useful for sort of
understanding what the page was before, and what
the page is now, versus what it's going
to be in the future. So I was working with
a client the other day, and they were talking about
changing their home page. Which isn't a full migration,
but changing a home page can change a lot. Because on most
websites, the home page is the most visited page. So if you change the number
of links on that page, then that can change
the crawl depth, and that can change the
performance overall. And so yeah, there's a
couple of different tools. There's a tool that I use
called SEO Pro Extension, which is really, really good. Kristina Azarenko
put it together. I think you interviewed her
previously on another thing. Yes, it's fantastic. And yeah, so I use that a lot.
So that can tell you
what you've got now. Also, a tool that I use
particularly with migrations. Let's say you develop
something, and the client says it's not as good
as it was before, but that website is gone. So something called Wayback
Machine is really good. I've used that a few times
to sort of understand why a site before was
working, and why it's not now. So there was a site
that we had where they used to have a sort of
most recent content sort of feed showing on the home page.
And that helped us
crawl depth, and helped with retency of new content
and that sort of thing. And then when we moved
to the new website, it didn't have that. So when we moved,
using Wayback Machine, I was like we need to
put that back on, so that that goes back, so
that gives us more tools. We always we that we need a
super wizzy technical fix. And sometimes, it's not
necessarily the case that you need
something super fancy. I know there's a lot
of AI at the moment, and there's a lot of automation
and lots of things like that. But sometimes you
can do something pretty straightforward
that will fix it. So for instance, I've
seen it before where from a SEO point of view, we're
looking around and we're going, oh, there's a bunch of 404s.
And oh, we need to fix this. The developer needs to sort
something out or something. And it's like, well, if
there's a 404, if you've got loads and loads of 404s. Like, let's say most of
the pages on your website have seven links, and there's
475 404s to this one URL, it's probably in your menu. It's probably in your menu. You've probably got
a 404 in your menu. You probably just need to
change the link on the menu.
And sometimes people think, oh,
we need to do this whole thing and fix that. It's like, you
might literally just need to change one little thing
that isn't even a dev thing, for instance. So I think that thinking about
what is really, genuinely required from a
developing point of view is really, really useful. But also, thinking about how
complex the solution might be. So for instance,
in the situation you were talking about,
where you built it one way and the SEO wants a
bunch of other things. If your tech stack is
resistant to the implementation that you want, then there
might be an external tool that you can use that
solves the solution, or that gets you
where you need to go. Or there might be another
way that you can do it.
So for instance,
I had a situation where I wanted an RSS. We were trying to build an
RSS directly on the website. And we ended up using
a third-party tool, and it works fine. It does exactly
what I needed to do. Or I could have
spent a month trying to get someone to build one
from scratch doing this. But why? But why? I go to a third-party tool,
it works perfectly fine. And you don't have
any third-party lag from JavaScript.
It's literally just one little
line, and it's totally fine. MARTIN SPLITT: Yes. Yeah. CRYSTAL CARTER: And
I find other times where, for instance,
structured data is something where everybody's
going JSON, JSON, JSON. And JSON is fantastic. But if the website already
has microdata setup, then you might be able to
move the needle more quickly by just updating the microdata
if it's already in place. So I think it's useful
from an SEO point of view to think about not only
what moves the needle, but also what moves
the needle efficiently, and from a tech point of view,
and from an SEO point of view.
MARTIN SPLITT: And I
really like that statement, because I wish a lot
of the SEOs that I had to work with in the
past would acknowledge that. And oftentimes,
I feel like there is a bit of dogmatism in the
way that some people operate. As you say, you
identify the thing that moves the needle and
moves the needle efficiently. Like what is easy to do,
but has lots of impact? And we discussed that in a
previous episode as well.
But the thing is, oftentimes,
it seems that people– SEOs, specifically–
go from half-knowledge of "someone on
the internet said" or "it used to be like
that 10 years ago", and then just ask for a solution
for something that isn't even a problem in the first place. JavaScript is one topic that
invites this kind of situation, it seems. There's still a lot of
people wandering around like, whoa, no, we need to
implement dynamic rendering or server-side rendering for
this client-side rendered application. Because unless we do that,
it won't show up in search. And then I'm like, but
if I Google for a thing on your page, then it shows up. So it's already there, and
I see that it has traffic in Google Search Console.
It gets the impressions,
it gets the clicks. Why are we doing this? Oh, because Google doesn't
understand client-side render of JavaScript applications. And I'm like, but the data
clearly shows that it does. I'm not saying that
it's true for all of the situations, and all
the cases, and all the pages. Yes, for some pages,
it still matters. For some, it still
makes a lot of sense. If you see a problem,
then this might be a solution to that problem,
if the client-side rendering really is the issue that
you are dealing with.
But oftentimes, it just isn't. You spend a lot of time, a
lot of effort, a lot of money on implementing something
that invites more trouble, for solving nothing! Why does that happen? CRYSTAL CARTER: I
think sometimes, people will hear a buzzword
or they'll hear, oh, yeah, we really need
to sort out this and that. And so I think sometimes people
get excited about a new thing. And I mean, I can
hold my hand up. There's definitely been a
time when I've done that. (LAUGHS) But the other thing I think
would be really, really useful, which I would appreciate it
as an SEO, speaking with devs, is that if you don't know
what I'm talking about, tell me that you don't know
what I'm talking about.
MARTIN SPLITT: Right Yes! 100% yes. Yes. Yes, please. CRYSTAL CARTER: And
also, if you need me to give it to you
in a different way, please let me know. There's a lot of tools that
will help you to do that. So I use a lot of
screen recording tools. So like Loom is one
that I use a lot. And I think Slack now has an
integration where you can just record your screen
really, really quickly and send it in a Slack message. And that makes a
really big difference. Chrome Developer
Tools is fantastic. I do tons of PowerPoints where
I'm just like, this is here, and that is like
this, and this is like that, and that is there. And sometimes if you
can see it, and if you can show them the
code, then even if you don't know
the exact words, they can figure out what
you're talking about.
But it's also useful to learn
some of the words as an SEO. So learning what is and isn't a
variable, learning about what's going on with your server. How is it deployed? How is all of that working? It really helps, from
an SEO point of view, for you to get things
actioned quicker, if you can give the developers
more information. So for instance,
there's a couple of sites where I have access
to the folders and things, and I can root around in
Bitbucket or whatever. And I don't change things very
often, but I can root around.
And for some, I've had
clients where they still had a sort of a static
sitemap, and I was generating the static sitemap. And they're smaller
sites or whatever. And if that's
something that's taking dev resources, you
can ask them, like, can I have access, please? And then you can learn how
to do it and you can do it. Like, creating a static sitemap
is a really simple operation. Uploading it is really simple. But waiting around for
one can be quite a pain. So if you can do it
as an SEO, then that's really, really great. So there's some things
where you can ask for access to certain parts of the stack,
so that you can give them better information. But again, that's
about building trust. So if you have the conversations
with your developers, before things get heated,
before things are broken, before you start moving around
everything at everything, then it really helps. And I mean, even if you're
working with remote teams.
I work with a few
remote developers. We have developers
in-house, but we also have developers that we
work with for other clients or developers that work
in other countries, and we use Slack
and email and stuff. And I will literally send
like emojis and "hooray" GIFs and that sort of thing. So if they fix something,
I'm like, all right, thank you so much! Say "thank you." "Thank you" gets you so far. MARTIN SPLITT: Same for
developers towards SEOs, by the way. I made it a point, whenever
something was pointed out to me where we could do
better, then we just did, and then we saw the business
impact, and then it was like, thank you very much for
bringing this to our attention, and thanks a lot for guiding
me through the process.
Because oftentimes, I didn't
know why I was doing something, or how exactly it's
expected to be, and where I would verify
if it's done correctly. And then having someone to
guide me through that was great, and I was grateful for it. So say thank you. CRYSTAL CARTER:
Right, absolutely. And if you work really
well, then as a developer, that's adding another
string to your bow.
Then it's something that
makes everything better. So yeah, I think that
it's really important to build good relationships. MARTIN SPLITT: Absolutely. So I think it's important
to, A, communicate if you don't understand something. Be it you as an SEO
or you as a developer, if you're not sure about
something, just ask. Find the tools that the
other people are using. Just ask your developers
what tools are you using. Ask the SEOs, what
tools should I be using to check when I'm
building this or implementing this or fixing this? Phrasing it as
opportunities of improvement is probably much, much
better than phrasing it as a problem or a challenge.
And yeah, if we
just work together in finding the right
solutions together, I think we are doing each
other big, big favors. I guess that sums
it up quite nicely. CRYSTAL CARTER: Absolutely. Absolutely. MARTIN SPLITT: Thank you
so much for joining me for this conversation, Crystal. This has been really, really
exciting and interesting. I do hope that everyone
out there got something out of it as well. I certainly did. And I am looking forward to see
what other cool things you will be sharing with the community
and us in the future. And yeah, again, thanks
a lot for joining. And take care. Have a great time. Bye-bye! CRYSTAL CARTER: Thank
you so much, Martin! MARTIN SPLITT: Just going
to say I'm a huge fan. CRYSTAL CARTER: I thought
that would be, like, smooth. It was really not. [MUSIC PLAYING] .
