JavaScript: SEO Mythbusting – What Google Wants

[

MARTIN SPLITT: Coming from
a development background,

there are so many misconceptions
and myths about SEO

that developers come
up with or have heard,

or that come from the
SEO world, as well.

Where do these come from?

How do these get into the world?

JAMIE ALBERICO: The
myths, the legends that

come through about JavaScript?

I think a lot of it is people
with very good intentions

will try to provide
the information they

have available.

And there’s a gap in
translation between the SEOs

and the developers, and how they
think and what they consider.

So by going ahead and adopting
acceptance criteria as part

of my tickets when I
work with devs, that

lets them know
very specifically,

instead of being like, and I
want you to make magic for me.

And when you go from,
give me magic, to hey,

here’s my user story.

I would like to accomplish three
pieces for acceptance criteria,

you can bridge the gap.

[MUSIC PLAYING]

MARTIN SPLITT: Hello, and
welcome to another episode

of SEO Mythbusting.

With me today is Jamie Alberico.

Jamie, what do you do
in your job, exactly?

JAMIE ALBERICO: Thank you
so much for having me here.

I’m a Technical SEO
with Arrow Electronics.

And that means
that I am embedded

with a number of dev teams
across a number of projects.

We try to execute these
initiatives to get

new features
available on the site

in an effective and
search-friendly way.

And that means a
lot of times, we

have to have conversations about
how we’re using our JavaScript.

MARTIN SPLITT: Having you here
is fantastic because then we

can have a conversation
about pretty much everything

that you want to know from the
search side, as well as the web

developer side.

So any questions that
you have in mind?

Anything that pops
into your mind?

JAMIE ALBERICO: Oh,
so many questions.

I get to poke at the
black box of Google here.

And I have one that’s
absolutely burning.

Is JavaScript the devil?

MARTIN SPLITT: [LAUGHS]
That’s a fantastic question.

It might seem that
way sometimes,

especially when things are
not going the way you want it.

JAMIE ALBERICO: You
see the horror stories.

They’re on forums.

They’re on Twitter.

Everything is gone!

MARTIN SPLITT: Yeah, that’s
one thing, the SEO side.

On the developer side
it’s also like, oh,

it’s a language that wasn’t
designed to be super resilient.

But it actually is.

And then often, people are,
oh, it’s a C-type language,

and it’s not really.

It’s a LISP-type language,
so a lot of misconceptions

coming from both worlds
together and clashing here.

I don’t think it is the devil.

I think it has its benefits.

I mean, it allows us to build
really cool and fantastic stuff

on the web and be really
responsive to what

the user does and wants to
do with our applications.

And it has moved
the web from being

a document platform towards
an application platform.

And I think that’s fantastic.

So I think we are already
pushing hard on fighting this,

JavaScript is the devil,
and if you use JavaScript,

you can’t be indexed at all.

So that’s not true
for a long time.

But I think now the
documentation is catching up

with outlining the different
bits and pieces that you should

be aware of, and the features
that you have to deal with that

are not available.

One thing, for instance,
is you probably

have built single-page
applications, right?

JAMIE ALBERICO: Oh, yes.

MARTIN SPLITT: Has there
been problems in terms of SEO

when they rolled out?

JAMIE ALBERICO: I
was pretty lucky.

I had a dev team
who believed in SEO.

MARTIN SPLITT: That’s good.

Oh, fantastic.

JAMIE ALBERICO:
That’s really good.

That was actually my– the
big moment of my career,

when I got into technical SEO.

And I came, and I talked
to one of my new developers

for the first time with
this very specific problem

he was trying to solve.

And he just paused and
looked up from his keyboard

and went, [GASPS]
you’re not snake oil.

So I think we’re making a lot of
progress between SEOs and devs.

MARTIN SPLITT:
That is fantastic.

That’s a great story.

So you might hear a few people
in the community going, ooh,

should we do a
single-page application?

Is that risky?

And one of the things
that a bunch of developers

are not aware of and some
SEOs are not necessarily

communicating all the time
is that we are stateless.

So that means with a
single-page application,

you have a bit of an
“application state,” right?

You know which page
you’re looking at

and how you transition
between these pages.

However, when a Search user
clicks on a Search result,

they’re not having
this application state.

They’re jumping in right to
the page that we indexed.

So we only index pages that
can be jumped right into.

So a lot of the technology,
the JavaScript technology

is making assumptions of
how the user navigates

through the application.

So as a developer, I might test,
so OK, here’s my application.

I click on the main navigation
for this particular page.

And then I click
on this product,

and then I see that
everything works.

But that might not do
the trick because–

JAMIE ALBERICO: But you
need that unique URL.

It has to be something
we can get to.

MARTIN SPLITT: Correct,
not using a hashed URL.

And also, the server needs to be
able to serve that right away.

If I do this journey and
then basically take this URL

and copy and paste it
into an incognito browser.

I want people to see the
content, not the home

page and not a 404 page.

So that’s something
that we’re working

on giving more guidance for.

Lazy loading, you probably have
seen a bunch of communication

about that one, as well.

JAMIE ALBERICO: Oh, yes.

How do we get a rich media
experience out to users,

but do it in a way where, if
you’re on your cell phone,

we keep that very
small time frame

we have to get your attention?

MARTIN SPLITT: Mhm, correct.

And you want to make
sure that if you

have a long list of content,
you don’t bring everything

into the– especially
on a cell phone, right,

just dealing with like,
a hundreds images.

Ugh.

JAMIE ALBERICO: So
what about AJAX?

What about using Asynchronous
JavaScript And XML?

MARTIN SPLITT: Right,
that is perfect– ooh,

I haven’t heard AJAX
being used in a while

and spelled out in a while.

I mean, everyone’s–

JAMIE ALBERICO: Well,
I think a lot of–

MARTIN SPLITT:
Everyone’s using it,

but no one’s talking
about it that much.

And it was just like, yeah, you
just load data in as you go.

That’s perfectly fine.

We are able to do that.

Also, I often get asked about
how that affects the crawl–

JAMIE ALBERICO: Crawl budgets.

MARTIN SPLITT: I knew you
that you would still say that.

JAMIE ALBERICO: Crawl budget.

Let’s talk.

MARTIN SPLITT: So what
worries you about that?

JAMIE ALBERICO:
Well, if we’re using

AJAX, when we request,
say, a product detail page,

and we’re using AJAX to
supplement a lot of pieces

of content to it.

Google bots requested
one URL, and it’s

gotten back nine, because
each of those AJAX calls

had a unique string.

How do we handle that?

And does it negatively
impact our crawl budget?

MARTIN SPLITT: So, I wouldn’t
say it negatively impacts

your crawl budget, because
crawl budget is much more

complex than you might see.

It’s one of these things
that looks super simple,

but there’s more
than meets the eye.

We’re doing a bunch
of caching, right?

Because we expect that
content doesn’t necessarily

update too much.

So let’s say you have
this product page.

You make one request
to the product page.

And then that makes
nine more requests.

We don’t distinct
between loading

the CSS or the
JavaScript, or the images,

or the API calls that get
you the product details.

So if you have nine calls
from this one page load,

then that’s going to be
ten in the crawl budget.

But because of caching, we might
have some of these in the cache

already.

So if we have something
that is already cached,

that doesn’t count
towards your crawl budget.

JAMIE ALBERICO: So if we were
to version our AJAX calls,

those could be cached
instead of called every time.

MARTIN SPLITT: Those
could be cached.

Exactly, yes.

And then that’s one way
of working around it,

if you can do that, if
that’s a possibility.

The other thing is you
could also consider it

not just an issue
for the crawl budget,

but also an issue
for the user, right?

Because if you’re on a slow
network or a spotty network

connection, it might
flake out in the middle.

And then you are left
with broken content.

That’s not a great
user experience.

You want to probably
think about pre-rendering,

or hybrid rendering, or
server-side rendering anything

in between there.

And crawl budget
is tricky generally

because we’re trying to deal
with the host load situation,

so what can your service
actually deal with.

So we are constantly
adjusting that anyway.

So it’s like, oh, this affected
our crawl budget negatively.

Not really, because
we just had host load

issues with your service,
so we adjusted it anyways.

So we had balancing issues
across your entire content.

So I wouldn’t say that
it’s that much of a deal,

normally speaking.

But I see that it’s very
important for people

to understand that.

And unfortunately,
that’s not that easy.

JAMIE ALBERICO: Can we demystify
Googlebot a little bit?

MARTIN SPLITT: Oh, yeah.

JAMIE ALBERICO:
Because we have this–

the ominous, the
great, Googlebot!

But it actually goes
through a series of actions.

So we get that
initial HTML parse.

We find the JavaScript
and CSS that we

need to go ahead to
make our content,

then call those pieces.

We know since Google
I/O, there is actually

a gap between our initial
parse and our HTML rendering.

But I want to know
more, because Googlebot

follows HTML/HTML5 protocols.

There are some nuances
there I don’t think–

I know I didn’t know about.

Say you’ve got an
iframe in your head,

and you’ve got a closing
head script right there.

That ends your
head for Googlebot,

and all of our
lovely meta content,

hreflangs and canonicals below
that, have a tendency to exist.

MARTIN SPLITT:
[LAUGHS] That is true.

There’s a bunch
of things at play.

So when we say Googlebot,
what we actually

mean on the other
side of the curtain

is a lot of moving parts.

So there’s the crawling bit that
literally takes in URLs, right,

and then fetches
them from the server,

so that when you are
providing the content to us,

we get the raw HTML.

That tells us about the CSS,
the JavaScript, and the images

that we need to get, and also
the links in the initial HTML.

And because we have
that already, we

have such a wealth of
information already,

we can then start to go off
and fetch the JavaScript

and everything that we
need to render later on.

But we can also already
use the HTML that we’ve got

and say, like, oh, look.

There’s links in here
that need to be crawled.

So when you have links
in your initial HTML,

we can go off and basically
start the same process

for these URLs as well.

So a lot of things
happen in parallel

rather than just
one step and then

the next step and
then the next step.

So this is definitely
the start of it.

And as we get the
HTML, in parallel

to extracting the links
and then crawling these,

we queue them for rendering.

So we can’t index before
we have rendered it,

because a bunch of content
needs to be rendered first.

JAMIE ALBERICO: But in
a way, that benefits us.

If we’ve got a
single-page application,

Googlebot has the template.

They’ve just got to grab the
content that fits within there.

So wouldn’t that mean
that Googlebot likes

these JavaScript platforms?

MARTIN SPLITT: It’d
probably like that.

The more content you get us
quickly in the first step,

in the crawling
step, the better it

is, because we
can then basically

carry that information
over, rather

than having to wait for
the rendering to happen.

JAMIE ALBERICO: But
is pre-render always

the best solution?

MARTIN SPLITT:
That’s a tricky one.

I think most of the
time, it is, because it

has benefits for the user
on top of just the crawlers.

But you have to very carefully
measure what you doing there,

I think.

So giving more content over
is always a great thing.

That doesn’t mean that
you should always give us

a page with a bazillion
images right away,

because that’s just not going
to be good for the users

because they’re going
to have to then–

If you’re on a
really old phone–

and I have a pretty old phone–

and you have a page
that is full of images

and transitions and
stuff, then you’re like,

I can’t use this website.

So pre-rendering is not
always a great idea.

It should be always
a mix between getting

as much crucial
content in as possible,

but then figuring out which
content you can load lazily

in the end of it.

JAMIE ALBERICO: So for
SEOs, that would be–

we know that different queries
have different intents,

informational, transactional.

So elements critical
to that intent

should really be in
that initial parse.

MARTIN SPLITT: Yes, exactly.

And you might consider, if the
intents are wildly different,

and the content is
very, very different,

consider making it
into multiple pages,

or at least multiple
views if you’re

using a single-page application,
so that you have an entry

point for the crawler
to specifically point

at it when it comes to
surfacing the search results.

JAMIE ALBERICO: So
treat it like a hub,

and let the users
branch out from there.

MARTIN SPLITT: Mhm, yes.

JAMIE ALBERICO: So that’s
where we’d use maybe

our CSS toggle for visibility.

MARTIN SPLITT: That
is a possibility.

Just having different
URLs is always an option.

Especially with the
History API, you

can probably, in the
single-page application,

figure out which route
to display, and then

have the content separated
between different routes.

So it would be a
little more dynamic.

And we support parameters.

So even if you use
URL parameters,

basically expose
the state that is

relevant to the user in the URL.

JAMIE ALBERICO: What other ways
does that benefit our users?

Because our ultimate goal
is to make them happy.

MARTIN SPLITT: Yeah, and
that’s our ultimate–

so we are the same in
terms of what our goal is.

We both want to surface useful
information to the user as

quickly as possible.

So the user’s benefits
are, especially

if you do hybrid rendering
or the server-side rendering,

that they get the content
really quick, normally,

if it’s done well, if it’s
not overloading their device.

And they get to jump in right
where the meaty bits are,

right?

So if I’m looking for
some specific thing,

and you give me a
URL that I can use

to go to that specific
thing, I’m right there,

and I’ll have a great
time because it’s

the content that I needed.

So yeah, if you have performance
metrics going up as well,

then even if I’m on a slow phone
or a really spotty network,

I still get there.

JAMIE ALBERICO: I mean,
our performance metrics,

that’s based on a lot of pieces.

We have a stack of technology.

MARTIN SPLITT: That is true.

JAMIE ALBERICO: What should
SEOs look for in our stack?

Where should we try to
identify those areas where

we could have a better
experience for not just

Googlebot, but our humans?

MARTIN SPLITT: Yeah,
so I think a bit that

is oftentimes overlooked,
not by SEOs but by businesses

and developers, is
the content part.

So you want to make
sure that the content is

what the users need and
want, and it’s written

in a way that helps them.

But on the technology side–

JAMIE ALBERICO: Wait, so
that blurb at the top people

always do where they’re like,
here’s my hero image and then

500 words about
this thing– and I’m

a human who wants
to buy something.

And there’s so much
stuff in the way.

MARTIN SPLITT:
Yeah, don’t do it.

JAMIE ALBERICO: Don’t–

[LAUGHTER]

MARTIN SPLITT: Or at
least have two pages.

Have the promotional
page that you want

to direct marketing towards.

And then if I specifically
look for your product,

just give me your product.

JAMIE ALBERICO: Just
let me give you money.

MARTIN SPLITT: So I think
talking about performance

and all the different
metrics, it’s

a bit of a blend
of all the things.

Look at, when does my
content actually arrive?

When does my page
become responsive?

So you look at first
contentful paint.

You look at time to
first byte as well–

less important than the
first contentful paint,

I would say, because
it’s fine if it

takes a little longer if then
the content is all there,

versus–

JAMIE ALBERICO: So time to first
byte can take a bit of a hit

if we deliver that faster
first meaningful paint.

MARTIN SPLITT: Exactly,
because in the end as a user,

I don’t care about if the
first byte has arrived quicker

if I’m still looking
at a blank page

because JavaScript is
executing or something

is blocking a resource.

If it arrives a
little later, but then

it’s right there,
that’s fantastic, right?

And you can get there
in multiple ways.

I highly recommend testing,
testing, testing, testing.

JAMIE ALBERICO: What testing
tools would you recommend?

MARTIN SPLITT: So I definitely
recommend Lighthouse.

That’s a great way. [? Wepend ?]
is a more broad approach

as well.

And you could also use PageSpeed
Insights or the new SEO audits

in Lighthouse.

Mobile-Friendly Test also gives
you a bunch of information

of how–

JAMIE ALBERICO:
PageSpeed Insights

seems to look at that
full page, though.

And we have a bit of a gap.

We have almost this
futurist Lighthouse

where we want that
time to interactive.

And then we have people
adopt this methodology,

and that’s how we got so
much content via AJAX,

because full page load is fast.

But all that content
was still coming.

MARTIN SPLITT: So I would
recommend Lighthouse.

That gives you
the filmstrip view

of when things are
actually ready for the user

to work with.

So I would highly recommend
looking at Lighthouse.

But PageSpeed Insight
gives you good first view,

and it integrates with
Lighthouse really nicely now.

JAMIE ALBERICO: Wonderful.

MARTIN SPLITT: Do you think
that JavaScript and SEO can

be friends now, and that
developers and SEOs can also

work together?

JAMIE ALBERICO: I do.

I really think that
if Google is a library

and a web page is a book, using
these JavaScript frameworks

let us make pop-up books
and rich experiences

to engage with.

MARTIN SPLITT: Oh, that’s
a fantastic analogy.

I love that image.

That’s a beautiful one.

Thank you so much, Jamie–

JAMIE ALBERICO:
Thank you very much.

MARTIN SPLITT: –for being here.

And I hope you enjoyed
it, and see you next time.

Have you ever wondered
where on the map

you should put UX
and performance

when you’re talking about SEO?

So have I. Let’s find out in the
next SEO Mythbusting episode.