MARTIN SPLITT: Hello.
And welcome to another JavaScript SEO Q&A, or office
hours, as we used to call them.
My name is Martin Splitt.
I am a developer advocate on the Search Relations team
at Google.
And my speciality is crawling, and indexing,
and rendering, specifically all the topics around JavaScript.
And that's what we're here for today.
A bunch of people found their way into this lovely recording.
And a bunch of people of you have asked questions
on YouTube.
So let's go over the YouTube questions first and then open
the questions for the audience as well.
DT is asking, AJAX and lazy load was
introduced to improve the page speed and load
content as needed.
However, the SEO fetch requirement
is to load the page content beforehand.
In React-based SPA applications, or single-page applications,
or progressive web applications, what
would be the Google recommendation, prerendering
or dynamic rendering, and why?
How to approach one over the other without violating Google
code of ethics for SEO?
So first things first, yes, lazy loading
is a great introduction in terms of loading content only when
the user potentially sees it.
And you can do that reacting a page,
on any single-page application, in any progressive web app,
in any website without violating Google guidelines
or without running into problems.
We actually do have a guide on developers,
so google.com/search.
That explains how to do this properly.
The recommended way in general is for images and iframes
to use the loading equals lazy.
For anything else, you can use the Intersection Observer.
You should still have some links and URLs
that actually make these paginatable so
that you get pages of content.
That's a better way of doing that.
You can use prerendering, which means--
or prerendering or server-side rendering,
actually, which means, basically,
creating the HTML content and then basically giving
that to your users as well.
That might make things a little faster.
It might not, depending a little bit on your content
and the amount of content as well.
Dynamic rendering, I would, in general, not
recommend if you can somehow avoid it
because it is a workaround.
But the dynamic rendering, what I mean by that
is if you are rendering the page and then serving that
to bots versus what you give to users, that is generally
not a violation of the cloaking guideline.
But it still means that you are creating
additional technical infrastructure that can usually
fail at some point.
It is harder to test these things.
It just adds a lot of complexity for not
that much value, unless you really,
really can't fix what you're building.
If you're building something from scratch or something new,
then I would definitely recommend
looking to server-side rendering,
just because it gives your users' benefits too
to have the content in the HTML, in the initial HTML.
Browsers are really fast at parsing that as it comes in.
Versus JavaScript-generated content,
you basically have to wait until the JavaScript has downloaded,
has executed.
And then, only then, can the browser show things.
So your mileage may vary.
And for lazy loading or infinite loading,
in specific, that is not really the main concern here.
Because how much of the content would you
put into this initial HTML, anyway?
We recommend having a bit of JavaScript that
does this infinite stream of content using an Intersection
Observer, and then also providing
some URL structure that adds pagination or, basically, slash
one, slash two, or-- question mark page equals one,
question mark page equals two, and putting that into your site
maps in order to make sure that this is indexable and visible,
because there are limitations to what intersection of servers
can do.
Marco is asking, in a page where some of the content
is geo or user-dependent and loaded via JavaScript,
how does it impact in linking and wave propagation?
That's a very ranking-specific question.
So I'd rather not answer that part.
But in general, if it's geo or user dependent,
geographically, most of the visits from Googlebot
come from the US.
So it's likely that that's not going
to load some of the content.
If it's user-dependent, that usually
means it's customization or personalization that
is behind login.
Googlebot won't be logged in.
So it will behave like a user that has never
visited your site before.
So that's what we'll be seeing.
Edward is asking, question, what suggestions
does Google Search Console have for identifying
[INAUDIBLE] pages with excessive JavaScript?
In general, Google Search Console
has the corporate [INAUDIBLE] report
that will tell you which pages are slow.
And those are the ones that you want to specifically look into.
If it's not on there, then that might
mean that we don't have enough field data.
I would probably try to have a look at PageSpeed Insights
or Lighthouse to find pages where there
is excessive JavaScript used.
Ricardo is asking a question.
Hi, Martin.
I recently came across a site that, basically,
if JavaScript is disabled on the browser,
it just shows a blank page with no content.
This is a very traditional e-commerce site,
so nothing that makes the use of JavaScript
mandatory and indispensable.
The site is normally indexed by Google.
At the moment, I have not detected any rendering
problems.
There are no worries.
Mine is just a thought on how a really good solution can
be to create a site that depends 100% on JavaScript, rendering
both from the SEO point of view and from the user experience
point of view.
From the SEO point of view, at least for Google Search,
I can't really answer for the search engines, at least
for Google Search, it's not that much of a problem.
From the user experience point of view, it is more brittle.
There might be-- some people are surfing
with certain add-ons that might consider like, oh,
this JavaScript shouldn't load.
Or first load of a page, we don't load the JavaScript.
And then they don't see anything.
And then they just move on to another site.
I think using JavaScript for something where
you don't have to use JavaScript and you're implying,
this is a traditional e-commerce thing,
and then I would question why it doesn't show content
without JavaScript.
So I feel like this is the JavaScript usage that I
don't necessarily encourage.
I would say, pages that don't rely on JavaScript
are usually more solid, more stable, and usually faster.
Again, your mileage might vary.
But I would not advise on doing that,
where you show no content whatsoever
if JavaScript is disabled, unless you have
a really, really good reason.
And, oh, we build it that way is not really
a good reason in my opinion.
Good question.
Valin is asking-- or Valin Cooperation
is asking a question.
Testing the credibility of my company's website, which
is having its SEMS upgraded to a new version.
But the upgrade will mean that the site
will be a single-page application running Angular.js
1.8.
That's a really old Angular version, I think.
I'm emulating Googlebot smartphone and DevTools
and using the Mobile-Friendly testing tool to test pages.
But sometimes, the Mobile-Friendly testing tool
renders less content for a specific page
than I am seeing in the DevTools Googlebot emulation.
Why does this happen?
And which testing tools should I trust in this situation?
Definitely trust the Mobile-Friendly test more.
So here's what's going on.
If you set your DevTools to Googlebot smartphone,
the only thing that changes is the user agent, which
is a string that is being sent in every HTTP
request that you're making.
It still uses your regular Chrome settings.
Nothing has changed.
Nothing's different.
Googlebot, however, does work differently.
For instance, Googlebot does honor [INAUDIBLE]..
Whereas, your developer tools in Chrome do not.
So, that's one of the many, many things that are different.
So I would not trust that too much, to be honest.
It's a very rudimentary, very, very simple test
to do this in DevTools.
The Mobile-Friendly test, however,
might also not necessarily show you the reality at all times.
There's this dreaded other error.
And I have spoken about this a lot of times.
The big problem there or the challenge
here is the indexing infrastructure
is built for batch processing for, basically, background
processing.
So we have a lot of time until we actually
can crawl the resources of your page.
And we can retry individual resources multiple times
before we progress in indexing.
That can take minutes to hours.
When you are using the Mobile-Friendly test,
we can't really let you wait for an hour until you see a result,
right?
So we have to draw a line somewhere and say,
after a couple of minutes, if we haven't crawled it yet,
because we don't have the crawler available,
then we'll just move on.
And then you see other error, because this is not really
an error.
This is implementation details the way
that the testing tool is implemented.
But the testing tool uses the actual Googlebot infrastructure
and the actual rendering infrastructure
that we are using as well.
So what you see there is more likely
what we'll be seeing when we're actually indexing.
I'm a little worried about Angular.js 1.8
because that is really, really old technology.
And I would recommend not necessarily using that,
because I feel like Angular has matured a lot
in the last couple of years.
I think they're a version 9 now.
So yeah, I'm not super sure about that technology choice.
But in general, in SPA, even running
an old version of Angular should be fine
if you test it thoroughly in Search Console as well
as Mobile-Friendly test and the other testing tools.
Oh, my, I actually can't read Arabic.
So I don't know what's your name.
But there is a question about someone using WP Rocket
to speed up their website.
Apparently, the site works correctly and quickly.
And the PageSpeed Insight score increases.
But the traffic drops on the Search Console and Google
Analytics.
When they deactivated WP Rocket, traffic increased back again.
I don't know.
So I don't know WP Rocket, or WordPress Rocket.
I don't know exactly what it does.
But if traffic drops, I would wonder if, also, pages
drop out of the index.
And then that would probably be because the way
that it makes things faster is by deferring content
to a later point, where we might actually miss it.
So it sounds like it makes things more brittle,
even though it makes things faster.
WordPress sites often benefit from reviewing the themes
very, very thoroughly, because teams often load a lot of stuff
that you don't really need.
So I would double-check if you can figure out
why the theme is slow in the first place instead of using
a Bandaid like WP Rocket.
Manoge, or Manoy, is asking about the cache operator.
That doesn't really work for JavaScript, which that's true.
Is there an alternative to see the Google cache page?
Yes, in Google Search Console, you can see the index page.
So you use the URL Inspection tool.
Put in the URL that you care about,
the page URL that you care about.
And then say, view crawl site.
And there, you see the rendered HTML
that we're actually indexing.
I have a WordPress site.
Should I do JavaScript SEO?
[INAUDIBLE], no.
No.
Normally, you don't have to.
Yeah, and that's it for the questions that
touch on JavaScript SEO.
From YouTube, I'll reload the page one more
time to make sure that we're not missing out on anything here.
Yep, that's it.
And with that, I open questions to the audience.
They are.
Excellent.
I was about to say that.
So Raise Hand feature here in Google Meets,
Pramod has already raised their hand.
You can also use the chat to ask questions too.
And then I'll go through these questions.
All right.
In that case, Pramod, what's the question?
AUDIENCE: Yeah, hi, Marty.
So I have a very generic question.
Is there any added advantage of using React, or Angular, or any
of the JavaScript framework in terms of SEO?
Or Google will create this framework
with the conventional frameworks?
It's the same or any different and--
MARTIN SPLITT: Nah, we don't care.
All the same.
AUDIENCE: So I think in my current company,
some of the pages are on [INAUDIBLE]..
And some of the pages are on the WordPress or other platforms.
So should we have to migrate all into one or--
MARTIN SPLITT: Not for SEO purposes.
For SEO, it doesn't matter.
AUDIENCE: OK, thank you.
MARTIN SPLITT: You're welcome.
Happy to help.
Any other questions?
Again, you can use the Raise Hand feature.
Or you can use the chat as well.
Just let me know.
All right.
There are no further questions.
Are there questions?
I hear noise coming from Suresh.
If there are no further questions,
then I'd like to say, thank you so much, everyone, for joining.
Thanks for everyone watching the recording here afterwards.
Stay safe.
Stay healthy.
Have a great time.
And continue building cool things on the web.
Bye bye.
AUDIENCE: Bye bye, Martin.