when you're on a CDN and it's on a separate host name,


English Google SEO office-hours from March 11, 2022

sometimes that's really hard to spot.


And I imagine the rich results test, at least as far as I


know, it focuses on the content that is on the HTML page.


So the JSON-LD markup that you have there,


it probably doesn't check to see if the images are actually


fetchable.


And then if they can't be fetched, then, of course,


we can't use them in the carousel too.


So that might be something that we need to figure out


how to highlight better.


Yeah, if there was some way for it to show up,


then something couldn't be retrieved.


Because I think across Search Console, everything was happy.


Yeah, that was the challenge.


And in fact, the pages were coming up everywhere else


and were highly ranked.


So it's just a difficult one.


If there's a way to say, yeah, we couldn't harvest something,


these images couldn't be harvested,


that would be valuable.


Yeah, yeah.


OK, cool.


I'll pass that on.


Let's see.


I think time-wise, we're pretty close.


So maybe I'll just pause the recording here,


and then we can continue with the rest of the folks that


have their hands up.


If you're watching this on YouTube,


thanks for sticking around until the end.


If you'd like to submit your own questions,


we have the thread open in the community section.


And usually, I open it a couple of days


before the session takes place.


So you can drop your questions there,


or you can join us in person, of course, as well.


Thanks for joining in.


Thanks for all of the questions and comments along the way.


And I wish you all a great weekend.


English Google SEO office-hours from November 13, 2020

All right, welcome, everyone, to the first Google Search


Central Office Hours Hangout.


My name is John Mueller.


I'm a search advocate here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts,


where people can jump in and ask questions about their website


and web search.


This is the first kind of Google Search Central Hangout.


But essentially, it's the same as the previous Hangouts


that we've been doing.


The name has changed slightly because we


kind of rebranded everything.


So that's been pretty exciting this week.


A bunch of stuff has been submitted already.


But if any of you want to get started with the first question,


you're welcome to jump in.


Yeah, John.


Go for it.


Hi.


John, I have one of our clients.


They had to supplement the website.


So one of the websites they actually


designed for targeting Melbourne audience,


and another one they are targeting for Western Australia


state.


Now, they have planned to get rid of their second brand, which


they use for Western Australia.


And they want to use Melbourne brand for inter-Australia.


And they want to consolidate both brands.


Now, the website they have for the Western Australia,


they are going to remove the website.


And we are thinking whether we should use 301 redirection


or counter-level so that we can still


get the ranking of the Western Australia website


to Melbourne website.


I think that's kind of up to you,


depending on what you want to do there specifically.


So with a 301 redirect, you're essentially saying,


we're combining these websites.


And with the URL canonical, you're


kind of able to leave the old website where it is


and kind of focus your energy on the new one.


And leaving the old website where it is


might make sense if you want to keep it for other reasons,


other than SEO, for example.


So that's usually the two aspects


that I would look at there.


So if you're purely thinking about SEO


and you just want to combine everything and clean everything


up, I would redirect and do a proper merger


between those sites.


But if you want to keep the old website alive


for whatever reasons, then canonical is a good approach.


Thank you.


Cool.


John, curious about something actually regarding Google News.


Because there are so many surfaces out there.


You have the top stories.


You have the news tab in Google Search.


And you have the Google News app, I guess,


or different surface.


So are they all operating under different kind


of algorithms, decisions?


Does each surface?


Because we've noticed we've been working with a publisher.


And they seem to be doing very well in top stories


and the news tab in Google Search.


But when you search for the exact same query in Google


News, they're not being shown almost at all.


You can see them.


And you can see their articles if you go to their news source.


But they're not being shown for regular queries,


whereas for the top stories or the news tab,


they show up fairly well.


I don't know all of the details around Google News.


So that's kind of the one aspect there.


But for top stories and the news tab in search,


from our point of view, those are essentially just


specific variations of search.


So that's something where any website could appear.


It doesn't necessarily need to be a news website.


It doesn't necessarily need to be listed in Google News.


So those are essentially just variations of search.


And for these different variations,


because we think the intent is slightly different,


there are definitely different kind of ranking algorithms


at play there.


And I assume in Google News, they


have a whole set of their own ranking algorithms


that they use for kind of that part.


But no, I think it's getting more and more complicated


because of all of these different surfaces.


And there's also Discover that kind of plays in there as well,


which makes it a little bit harder than before, where


you can just say, oh, I'm in Google News,


and I focus on this.


And I'm also at web search, and I see myself here.


But on the other hand, it also keeps it a little bit exciting


because you have more opportunities, more


different ways to appear, and more things


that you could be focusing on slightly differently


than your competitors could be focusing on.


Right.


I don't see this as a problem having multiple services,


and each one takes its own decisions in terms


of what they should show or not.


I'm just worrying about there's a big discrepancy when


on a few surfaces, everything seems to be OK.


And on another one, the site doesn't show up at all.


So it's kind of hard to diagnose, OK, why.


Yeah.


I don't really have any great answers for that.


And I think it's also tricky because we


don't show all of those details in Search Console,


where it's kind of harder to see exactly what is happening


where.


OK.


They do have a support team, but unfortunately, they


are not very helpful.


OK, now, that's unfortunate.


Do you know if there are any office hours?


I'm not sure if.


I don't think so.


So the support form is probably the only avenue.


That's usually the best approach.


And every time I try to escalate news issues internally,


they're always like, I told them to use the form.


So.


Hi, John.


Can I follow up on that pretty quickly?


Sure.


Speaking specifically to the news tab in search,


if I'm at a site and I search for my site specifically


and I'm seeing the articles being listed not


in chronological order, is there something


I should be worried about with that?


For other competitors, I see that theirs


are showing at least correctly in my view.


But from what I'm seeing, I'll see something three weeks ago


versus seeing something 20 minutes ago.


That's something concerning I should look into?


I don't know.


I actually don't know if they're supposed


to be in chronological order or if that's just


how they sometimes end up.


One thing you could do is try to double


check that we can recognize the date of your pages properly.


One way you can kind of guess at that


is if we show a date in a snippet,


then that gives you a bit of an idea.


Another thing you can do is use the date restrict


in Google Search, where I think it's under Tools now


or in the Advanced Search settings, where you can specify


date range, and just kind of roughly double


check that we're picking up the right dates for your articles.


One of the things I've noticed is that on some sites,


the article date is kind of less prominent or less clear for us


to understand.


And we might pick up a date within the body of the article


or from the sidebar somewhere instead.


And we have a Help Center article


on how to specify dates on your pages.


And the important part there is really


that all of these things align so


that the visible date on the page


matches the date that you have in the structured data.


And if we can recognize the date properly,


then usually we'll be able to pick that up accordingly.


It's still sometimes the case that we have individual ones


that are off.


But essentially, if you're doing things right,


if you're doing things in a consistent way,


then at least we'd be able to pick up the date.


And if we need to use the date to kind of show


these articles in chronological order in the News tab,


then at least we'd be able to do that.


But like I said, I don't know if there's


supposed to be in chronological order.


I would assume that it's not necessarily always the case,


similar to in web search, where if you search for a website,


sometimes we show the home page.


Sometimes we don't show the home page as a first result.


SPEAKER 2


Let me run through some of the submitted questions.


And we'll definitely have time for more questions from you


all later on.


And if you have any comments or questions


in between to the questions or answers,


feel free to jump on it.


Do orphaned subpages, so subpages without internal links,


with duplicated or low quality content,


have negative impact for a website overall?


So I think I wasn't quite sure exactly which direction


this question goes to.


So it's hard to say exactly what would be helpful for you


in this particular case.


In particular, if you have pages that


don't have internal links pointing at them,


so pages that are hard to find from crawling,


then usually Google Search will assume


that these are not very critical for your website


because you're essentially hiding away


from people who are clicking around within your website.


And if we assume that you think they're not


very critical for your website, then probably we


won't give them as much weight in search.


And if we don't give them as much weight in search,


then it doesn't really matter that much what you actually


have on those pages.


So that's kind of the one aspect there.


If you have pages within your site


that you're not linking to at all,


then we don't really know what you want to tell us with that.


And if those pages are duplicate or low quality content


and we don't give them much weight,


then it doesn't really matter that much.


On the other hand, if you want those pages


to be findable in search, then I would definitely


make sure that you do have internal links pointing at them


and that you do try to avoid duplicate and low quality


content on those pages.


So those are kind of the two aspects


that I would look at there.


In Search Console, I'm seeing CLS issue more than 0.25


on mobile.


How does this affect SEO, even if it's not


affecting user experience?


Good question.


So I think CLS is a metric from the Core Web Vitals cumulative


layout shift, I believe, which is basically


a measurement for how much of a page shifts when a page is


loaded.


So if you open a page, and then while it's loading,


a new image pops up on top and everything shifts down,


then it's hard to actually read the content on that page.


So that, from our point of view, is a usability issue.


We introduced the Core Web Vitals earlier this year.


And our plan is to start using them


as a part of the page experience factor for ranking in search,


I think, in May next year, I think we announced.


So at the moment, that's not something


that would be affecting your SEO.


In May, that might be affecting your SEO,


because if you're not reaching kind of that good bar


with regards to the Core Web Vitals,


then that's something that could have a negative effect


on your site's ranking.


So yeah.


So my recommendation there would be to try to figure out what,


where that's coming from, and to try


to find ways to improve that so that you're


a little bit ahead of the curve and don't have to rush anything


when it comes to May.


With regards to testing these things, one of the aspects


to keep in mind in Search Console,


the data that we show is based on data that users have seen.


So we call it real user metrics.


And this is aggregated over the course of a month.


And it's based on what users see with their connections


to your website.


So in particular, if you're testing this then locally


to try to reproduce this, and you're saying,


well, it works for me, it's important to keep in mind


that your connection to your website


might be very different from the average user's web connection


So if you're seeing very different metrics when you test


it internally, then that's something


where you might want to figure out, well,


why am I seeing this difference?


What do I need to do so that I can better reproduce


what my users would be seeing?


Which is best, rel nofollow or rel


equals sponsored for outgoing affiliate links?


From our point of view, both of these are possible.


So for affiliate links, we generally


recommend specifying that these should not


be passing page rank or any of the other search signals.


And you can do that with rel equals nofollow


or rel equals sponsored.


You can also combine these.


So in particular, some search engines


don't use rel sponsored yet.


So you could easily use rel nofollow sponsored


on these outbound links.


And you're essentially covered.


From our point of view, we prefer


having a clearer specification with rel equals sponsored.


But that's really just so that we understand


your site a little bit better.


It's not that there is a big SEO difference with regards


to handling them with nofollow or with sponsored.


Also, for the more common kinds of affiliate links,


we've generally seen a lot of those already for a longer


time.


So we're able to handle those ourselves.


It's not the case that you'll have


any kind of automatic penalty or any other search issues


if you don't clearly specify your affiliate links.


It just helps us because you're kind


of being a little bit more deliberate on saying, well,


these links, I don't need you to pass any signals to.


Two questions.


Why does the organic click-through rate


drop with the exact same ranking for two different time


periods?


This is a pattern we've started seeing


with some of our keywords.


Yeah, I don't think there's any particular reason from our side


why the click-through rate would be dropping if nothing else is


changing in the search results.


But rather, that sounds more like, well, things


are changing for the users.


And that could be because maybe your snippet or your title


isn't as clear to users or doesn't


match what they're looking for.


It could be that users are just searching


for different kinds of content.


It might be that people are searching more


or people are searching less for those particular queries.


These are essentially changes more on the user side


than on Google's side.


Because if we show your result in the same position


for these searches, then essentially, potentially, you


could be getting the same click-through rate.


But what users actually do is not something we can control.


It's more up to the user.


And oftentimes, click-through rate


is something that you can slightly


affect by working with your titles or your descriptions


to make them a little bit clearer.


The other thing to keep in mind is


that click-through rate as an aggregate metric


for the whole website overall is probably not a great metric,


because many sites rank for things that are irrelevant


for the site.


And it might be that you start ranking for something


that is very visible, because a lot of people search for it.


But they're definitely not searching


for your particular site to get there.


That's something we sometimes see with our documentation.


For example, we've been going through a lot


of our documentation to figure out


what we should be watching out for as we did the big migration


or started the migration.


And one of the things we notice is sometimes


our documentation ranks for things like video.


And people searching for videos are definitely


not looking for structured data markup


that they can put on videos.


They're probably looking for videos directly.


And if we look at the overall click-through rate of our site,


then when people search for video


and we show our structured data documentation there,


then probably our click-through rate really drops,


because it's like lots of people are searching.


We're kind of ranking in the same places.


But we're showing in search results


that are irrelevant for our sites


that we don't really care about.


And that would change the overall metrics.


So if you're purely looking at the overall click-through rate,


then probably you're missing a lot of details


that matter a little bit more.


Then the second question is, Google's domain or site


diversity update launched during June 2019.


And it doesn't seem to be working,


as we're continually seeing more than three to four results


from the same site for certain non-branded queries.


Please shed some light on this.


Oh, no, I see people nodding.


OK.


So in general, we don't have a restriction


on the number of times that a site can appear in search.


And it can happen that a site appears once in a search


result. It can happen that it appears five, six, seven


more times even in the same search results page.


And from our point of view, it's not a bug


when a site appears more often.


It's something that sometimes makes sense for users.


The update that we did at that time


is to try to reduce the number of times


that we show sites multiple times in the same search


results, but it's not to completely limit sites


from appearing multiple times.


So from that point of view, it's hard to say


that this is not working or it is working.


But rather, what would be useful there


would be to have specific examples.


So if you're seeing things for kind of generic queries


where you're seeing the same site appearing very


often in the search results and there


are very good other results that we should be showing instead,


please send us some examples.


So that's the best way to handle this on our side,


especially if you have something that's really obvious,


where if you're searching for kind of a generic term


and you find all of the whole page filled with the same site


and there is a lot of other good content for that available,


then that's something we can pass on to the search quality


team here.


And usually, they take these reports


and they try to figure out why is this happening,


what can we do to improve it, and then


what algorithmic changes could we launch in the future


to help make these kind of search results


a little bit better.


Does Google have any?


AUDIENCE 1 Is there an example provided in the question mark?


JOHN MUELLER No.


It's like non-branded queries in the ed tech space.


AUDIENCE 1 Because I only mention it because we've had,


we see that I've seen that happening more now,


similar to what happened four or five years ago.


But I think we try and be honest with ourselves


and separate what is a brand and what isn't.


Because you know our sites are experiencedays.com


and experiencegifts.com.


Those are brands, but they're also very generic terms


as well.


So sometimes it's very difficult to determine whether,


or for Google to determine whether that's a brand search


or whether that's just a generic search.


But we have seen an uptick in those first pages having


four to six queries from the same site,


sorry, results from the same site,


rather than what's been going on over the last three or four


years.


But it also goes in cycles where every three or four years


this looks like it happens.


And it looks like you guys there are doing something.


And then go, oh, no, that didn't work.


So I'm wiped out.


I mean, if you have any examples, send them my way.


I'd be happy to pass them on to a team.


It's something where sometimes the examples


that I see on Twitter are very kind of hand-picked.


And as soon as you kind of vary the query slightly,


you realize, well, actually, it's


just one very specific case where that's happening.


But I think, especially if you have a site that


is kind of with a generic name, or it's not very generic.


I guess people know you by now, right?


AUDIENCE 2 But it's still those two words also


sum up our industry.


People can be searching for our competitors,


but they're looking for a driving experience day.


And it's very difficult for you to determine


whether they're looking for us or just what someone else sells


that's similar to us.


It's one of the things we have to cope with,


but we get huge benefits from having that domain as well.


Not that an exact domain matters, anyone,


but we still do get some benefit.


So we're kind of on the fence about it.


There's no point in us complaining because we


get the good and the bad.


OK.


So we'll have to wait for your competitors to send me an email.


AUDIENCE 2 All right.


Cool.


If you find any bad examples in that case, send them my way.


Does Google have any special criteria for search terms


like best or top?


For instance, might Best Surgeon Beverly Hills


favor the site or page most optimized for the word


or phrase best?


Or are there other unique data sets


used by Google for these particular queries,


like number of Google reviews, stars, on-page appearance,


et cetera?


I don't know.


This is an interesting question.


My feeling is, from what I've seen,


that we do try to recognize these particular kinds


of queries and figure out what we should be showing there,


rather than just purely focusing on the actual words


in the query.


So that's something that you also


see with a lot of the near-me type queries,


where for a long time, our algorithms were, I guess,


more basic, in a sense, in the way


that people would optimize their site for near-me queries,


where it'd be like pizzeria near me,


and you would have a page on your site that


is called pizzeria near me, which


isn't particularly useful if you're just in one location.


But I have seen some sites kind of appear in the search results


because of the things that they did there.


And as far as I've seen, this is something


that we've gotten better and better at understanding


and figuring out, OK, this is actually the search query,


and this is more of a qualifier that doesn't necessarily


need to be on the page itself.


And I assume something similar like that


would apply for queries like best or top, where we'd


have to focus a little bit more on things


that are outside of that page to figure out,


is this really the best one to show,


or are people looking for a list of these particular kinds


of businesses to try to figure out what


we should be showing there?


So that's something where I can imagine that sometimes it's


useful to include these kind of words on your site,


but probably in the meantime, our algorithms


are a little bit more focused on things


that are outside of just purely matching


those individual words.


If there's a huge website, if a huge website updates


all its data in a single day, why isn't that data crawled?


Is it difficult for the crawler to go through it all at once?


Yes, it can be very difficult to crawl a huge website


all at once.


So that's definitely tricky.


I think there are multiple things that come into play


here.


On the one hand, we'd have to recognize that a larger website


is updating all at once.


And based on that, then try to figure out,


how do we schedule the recrawling


of all of these URLs?


And that's something you can sometimes


help with a sitemap file to let us know that all of these URLs


have changed.


And we should go up and try to refresh as much as possible


of what we can do there.


And in general, our crawling is split


into two kind of general buckets, or maybe three,


I guess.


On the one hand, we want to discover


new content on your website.


We want to discover what is happening that is particularly


new on your site.


So we'll go off and crawl new things and things


that we haven't seen before.


And on the other hand, we'll also


go off and try to update and refresh the crawls that we've


done so far in the past and try to figure out which


of these pages have changed.


And balancing these two sides is sometimes a bit tricky.


So that's something where we have to figure out,


how much do we need to spend on refreshing?


How much do we have to spend on discovering new content?


How much do we need to spend on things


like the home page of a website so that we make sure


that we don't miss anything along the way?


And all of that kind of comes together


in a general topic of crawl budget in the sense


that we kind of can figure out how much we want


to spend on each of these parts.


But how much can we actually crawl from your website


without causing any problems?


And crawl budget is something we've


written a blog post about that I think a few years ago that


primarily focuses on two aspects.


On the one hand, how much can your server kind of sustain?


We don't want to cause any problems on your server.


We want to make sure that users, when they go to your site,


that they're not confronted with a severely slowed down server


because search engines are crawling all the time.


So that's something we try to figure out automatically.


And on the other hand, we need to balance the demand


from our side, like how much we think we


need to crawl from this website.


And some of that comes from understanding


how much we need to refresh.


So essentially what happens with a larger website


is we'll try to refresh all of the data


that we have with the website over the course of maybe


a month to three months to maybe six months.


So that's kind of the general crawling


that we do across a website.


So if we don't have any other signals at all from a website,


we'll probably have somewhere between three months and six


months time to refresh all of the content there.


So that's kind of the general crawling.


And you can imagine if you update the whole website


on one day, then we'd have to do six months' worth of crawling


on one day to try to combine all of that


and get that all kind of concentrated in one go.


So usually what happens when we recognize


that a site does larger scale updates


is we'll try to refresh as much as possible,


as quickly as possible.


So we'll try to get that in within a couple of days.


And essentially, we'll try to focus


on the most important pages first, so the pages


that users would end up seeing.


Those are the ones that we try to refresh as quickly


as possible.


And then there's a whole bunch of other pages


that also updated, but which we know are very rarely shown


in search, so we don't really need


to refresh them all at once.


So because of that, what you'll see with a larger website when


you make a bigger change, which could be something like a name


change, it could be a domain change,


it could be a change of titles, or something like that,


you'll see a bulk of the visible important pages


get update very quickly within a couple of days,


and kind of this longer tail of other pages


take a couple of months to be updated.


So that's usually the approach that happens there,


balancing all of those different parts.


So unfortunately, we can't crawl the whole web at once every day.


May I raise a question here?


There's an opportunity in the Google Search Console to let


you know about a website has changed or updated,


or something like that.


Forgot the name of that specific thingy.


But it's been off for a couple of weeks now.


You mentioned on Twitter that this is just for fixing


purposes, or something like that.


So my question would be, do you have


any updates on when that project is going to be relaunched?


And the other question would be, would you guys at Google


think about bug uploading?


How do you mean, bug uploading?


Currently, it's only possible to give you


one URL to crawl that URL and send that for indexing.


And frankly, when I have 10, 20 websites


that I updated for some reason, and I


have to type in every URL alone, and then there is that capture


I have to go through, and several clicks to be made.


And I think it's only like, even if I work with several tabs,


it's like 10 tabs is the max which is allowed or something.


So a bulk upload function would be really, really helpful


sometimes.


Oh, bulk, bulk upload, OK, I misunderstood you.


OK, yeah.


I struggle with this, because my general feeling


is if we have a way of sites to tell us that pages have changed


or that need to be updated, then we


should try to find a way to automate


that as much as possible.


So instead of telling you that you need to go and fill out


this form or upload a special file with all of the URLs


or something like that and then go through the captures


and all of this, I think our system should be set up


in a way that they can automatically handle this.


And we essentially have a system to do that,


which is all of the sitemap stuff, where you can say,


well, this page has changed, and Google should refresh


that as quickly as possible.


And my general sense is that if you go to the effort and say,


well, these 10, 20 pages have changed,


I will even fill out a capture to prove it to you,


then it feels like maybe we should


find a way to trust your sitemap files a little bit better


so that you don't have to do all of this.


And instead, your CMS updates the sitemap files,


and we say, oh, look, there are 20 new pages,


and this is a great website.


We will go and update that right away.


So that's generally, from my point of view,


the direction I prefer that we take.


I think the tool for updating individual pages


is something that definitely makes sense for other


situations, where maybe you can't do a sitemap file,


or maybe you have something really urgent,


and you can't wait for someone to create a new sitemap


file for you, or maybe there are other reasons as well.


I think that definitely makes sense,


but I really prefer that normal updates of a website,


that that's something that can be processed as automatically


as possible.


Because it feels inefficient to encourage


you to fill out captures just because you're making


normal changes on a website.


Oh, true, OK, thank you.


What's the relationship between article length and ranking?


I don't think there is any relationship between article


length and ranking.


I think the aspect that most commonly comes


into play with article length and ranking


is that, for some topics, users expect longer articles


and when they reach your site, they're


happier with finding some longer information.


And for other topics, maybe they don't need a long article.


And the one thing that I do kind of understand


is if you're kind of working together


with a team of writers and you're


ordering content from them based on specific topics


that you care about for your website,


then sometimes you specify a length and say, well,


I at least want an article this long.


But essentially, from an SEO point of view,


there is no requirement to have a certain length


of an article on your site.


But rather, it's more you need to be


able to fulfill your users' needs.


And sometimes you can do that quickly.


Sometimes you can have a really long article


with lots of details in it.


There's a lot of room in between there.


Is it necessary to use the keyword in exact match


or not in the content?


What's the best keyword strategy in the eyes of Google?


It's not necessary to use exact match keywords


within the content.


And this is something that I think


has been the case for a really long time now.


In particular, we recognize things like synonyms.


We recognize things like misspellings and kind


of singular and plural forms of keywords.


These are all things that our systems


can recognize both in the query and within the content.


And the newer machine learning-based systems


that we have, they go even further


and try to understand, well, what is it that you're actually


writing about here?


And how does that match what the user is actually searching for?


So with that in mind, you don't need


to include all of the variations of all of the keywords


that you care about within your content.


And I think most sites have been doing fairly well with that.


So it's no longer the case that you look at the top search


results and it's just filled with synonyms or misspellings,


typos of the same keywords.


So that's, I think, kind of a nice development there.


What is the best keyword strategy in the eyes of Google?


I think that's something where it's less a matter of SEO


from my point of view, but more a matter of almost marketing


and finding topics that your audience cares about


and being able to be out there as early as possible


so that you can get your content in front of those people


when they search for that information.


So that's something where it's not the case


that you need to find the exact keywords or the most


important keywords out there.


But really, you need to figure out


what it is that you have on your website that's


unique to your website that users


will be searching for where you can provide some unique value.


And those are kind of the keywords to focus on.


The one thing with keywords that I do want to mention,


though, is that while it's not necessary to focus


on exact match keywords within your content,


you should be a little bit specific about what


you want to rank for.


So if you have a news article about something big happening,


then don't use descriptive phrases


to describe that from happening, but rather mention the names,


mention the places, be elaborate,


and be specific on what is actually happening there.


This is sometimes something that I see, especially


with smaller business websites, where you go to the website


and, as a user even, if you look at the website,


you're like, well, what is it that they do?


Do they sell a product?


Do they sell a service?


Are they just a consulting company?


Is this just a general marketing page?


What is it that I, as a user, when I go to this website,


I'm supposed to be doing?


And if users can't really tell what exactly


it is that you're doing, then probably search engines


will have trouble too.


And probably search engines will have trouble


figuring out what they should be ranking this page for.


It might look really nice, but if it doesn't mention


what it is that you want to provide


and what it is that you want to appear and search for,


then it's going to be hard to show.


Could you introduce a strategy on the improvement


of the page indexing and the possibilities of time reduction


between the bot first visit and the entrance of the material


and the search results?


I don't quite know which direction that goes.


In general, when we crawl a website


or when we crawl a page from a website,


it can take a bit of time for those pages


to appear in the search results.


But it's not something that we purposely slow down.


It's more that sometimes things take a little bit longer


to be processed than others.


Sometimes we can show that within a minute or so


of being crawled.


So it's not that there's any kind of an explicit delay


there.


Who can we contact to receive the analysis of traffic


and its fluctuations caused by the core update that


occurred on September 24?


I'm not aware of any core update that occurred on September 24.


So that's kind of one thing.


With regards to receiving analysis data,


the best way to get data for your website


is, on the one hand, to collect it yourself


using any of the normal analytics packages,


and on the other hand, to use Google Search Console, where


you can kind of track how your site is appearing in search


and also get any information with regards


to issues that might have popped up that our systems


might be able to help flag for you.


SPEAKER 2


John, regarding these core updates,


do you know if there's any plans to launch any new ones


by the end of the year?


Are there any?


Yes, I just don't know what the specific launch plans are there.


I think it's always tricky towards the end of the year


because everyone's a little bit jittery, and probably


this year more than ever.


So there is a little bit of trickiness involved with,


well, we'd like to make improvements in search,


and we think our users deserve to see


those improvements in search.


But at the same time, we don't want it to be super disruptive.


So I don't know what will happen there.


It's possible at some point maybe we'll still


have an update.


I don't know what the timing would be there,


because essentially all timing is bad when it comes to,


like, the last quarter of the year.


SPEAKER 1 Right.


But just curious, these kind of updates


are needed because there's no system to kind of do


this automatically ongoing.


So is it like sort of the old Panda and Penguin updates


where you kind of needed to aggregate a lot of data,


then kind of crunch it and then push the results into Google,


and then you kind of transitioned


into doing that kind of ongoing automatically?


Is it kind of the same with the core updates?


I don't think you can really compare those that well.


So that's kind of one thing.


The other thing is a lot of times within the core updates


we'll have bigger algorithmic changes.


So it's not so much that we're changing,


I don't know, the page rank of all of these pages kind


of thing, but rather we're kind of making bigger


algorithmic changes in the way that our systems show things


in the search results.


So it's something where, like, if you change the algorithms


between with regards to how we rank things in search,


then sometimes you just have kind of that jarring jump


from one change to the other.


SPEAKER 2 But are these changes related


to what happened between these months from the past core


update to this one?


I mean, does it take any data based


on crawling data and indexing data and anything like that


in order to kind of judge what the changes should


be in the next core update?


I don't know how to best answer that, because I mean,


we do look at what has been happening over time,


and it's something where we obviously look at the data


that we've collected until then, and we


try to use some of that with the next algorithmic changes.


And for bigger algorithmic changes,


we do all of the usual tests, the A-B test


with the quality raters, all of that.


And essentially, that takes into account the data


that's been collected until then.


So it's, yeah, I mean, yeah.


It's, I don't know.


I generally prefer if we could do these algorithms a little bit


smoother in that there isn't this jarring jump from one


to the other, but sometimes that's just


the way that it works out.


This is why I was comparing to the panguin algorithms,


because there was also that big change overnight.


So this is why I was wondering if it's something


like that in the sense that you are planning to smooth out


these changes so it's more an ongoing thing rather than all


of a sudden.


Yeah.


I mean, if it were just a matter of changing the page rank


values or something like that, then that's


something where you can smooth that out and easily spread that


out over the course of a couple of weeks or so.


But it doesn't look that jarring.


I think, I mean, sometimes also having a jarring change


is useful for site owners, because then you


can understand a little bit where things have changed.


But I generally prefer when things are smoothed out.


One last thing.


So are these changes usually related to kind of you


understanding the data better, or are they more related to,


maybe we should weigh this factor a bit more


or this factor a bit less?


Or is it kind of the same, but, oh, now we better


understand what this page is about or something like that?


I think all of that comes together.


Yeah.


Makes sense, yeah.


I think there are always so many factors that


are involved with these algorithmic changes.


So it's always tricky.


Cool.


We're kind of running towards the end of time.


Well, the end of this session, at least.


Not end of time, hopefully.


If there are any questions from you


all that you'd like to ask, feel free to jump on in.


Hi, John.


OK.


You go ahead.


Thank you.


Ben, with my team.


So now I'm translator for him.


We are Thai.


So I could say I'm sorry for my Thai.


I'm not that good.


So but I will try my best.


For our problem is the search console,


all the indexing in the part of user declare.


It's not our website.


And we try to figure it out.


We try to figure it out on this problem.


But we couldn't fix it.


We couldn't fix it.


And we have a Google host in Thailand.


And they couldn't help us as well.


So do you have any suggestions for us to do or how we can do?


And the second one about the site, our website,


that we can find our website on Google,


it's another website that I mentioned to you.


So what can we do?


Thank you.


OK.


That sounds a little bit more complicated.


So my recommendation there would be perhaps


to post the details as much as you can in the Webmaster Help


Forum.


We have a forum in English that I know is fairly active.


Mihai, for example, is active there.


I don't know if we have one in Thai specifically.


But if you can post in the English forum,


that would almost certainly.


Oh, yeah.


Search Central Help Forum.


We change the name.


If you post there with the details of your website


and maybe some screenshots of what you're seeing,


that would really help.


Because it feels like maybe there


is something specific with your website


or with the way that it's hosted or the way that it's


shown in search.


And those are sometimes hard to just give a general answer for.


It would almost need to be that someone


looks at your specific case.


Thank you.


Sure.


Hey, John, if I can just quickly jump in.


This is sort of related to the question that someone else


asked on the YouTube page, Solomeo.


It was around indexation and how you guys are serving pages


after they run through your indexation process.


Do you know of any delay that occurs


between a website or a page, a web page being indexed


and then served due to and there's


a delay because of bad usability or mobile usability?


Is there anything that exists like that, or does that just


not happen?


I don't think we have any delay based on quality issues


or things like that.


So I mean, one of the things that happens


is we have to be able to index the content.


And if we have the content in the HTML form,


then we can pick that up right after the crawl.


If we have to render that page first,


then sometimes that causes a bit of a delay.


But even that rendering delay, for the most part,


is a matter of minutes.


It's not a matter of hours or something


that would be visible.


And once we've indexed the content,


then essentially it could appear in search.


What might happen is that there's a bit of a delay


until we rank it appropriately in search.


So if you're searching for something


and it's very competitive, then understanding,


oh, this is a good page for that query,


that might be something that has a delay.


It might also be, depending on the query, an issue.


Well, not necessarily an issue, but kind


of a matter of understanding how timely this page is.


So if you have a news article on your site


and we don't recognize that it's a news article offhand


and it's a query where people are expecting news


about that topic, then it might be


that we say, well, this is more of a general article


on this topic.


It's not a news article, so maybe we


won't show it for this query.


So kind of the indexing side is one thing


where I think the timing should be fairly tight,


and the ranking side is kind of a completely different


question.


Right, OK.


Do you know, like, I get you on the ranking side


where it might not show up because it's a really


competitive term.


But if you're searching for the exact headline


or if you're doing like a site search


and you're not seeing it there, would you


say that's problematic?


Or is that normal behavior?


I don't know.


It seems weird, but it can happen sometimes.


So for the most part, if you're explicitly looking for that


page and you know that it's indexed,


then it feels like we should be able to show that,


unless there's something really kind of blocking


with that page in particular.


Yeah, that's kind of why I was rounding back


to the mobile usability and that potentially being a hindrance


there, where there's an issue with Google


being able to process things.


I don't think so.


I mean, if it's a matter of usability of the page,


but we have the textual content, then that


shouldn't be an issue that would prevent us


from showing it at all.


It might be kind of going into more of the ranking


side of things, where it's like, well, we could show it,


but we're not showing it in the top position


or something like that.


But it shouldn't be something that would block us


from showing that page.


OK.


OK, thanks, John.


Sure.


Hi, John.


Can I follow up on that?


Sorry.


Yeah, so you just mentioned that if you recognize


or if you don't think an article is newsworthy,


you wouldn't serve it for specific terms.


I'm curious kind of what you're looking at on that page


to identify that, other than mentioning what people are


kind of looking for at that time,


are there any other things you're looking


for on the site specifically?


It's hard to say.


I think, so I don't think we have any explicit guidelines


on what you need to do to make something


look like a news article.


Usually, I imagine that's something


that we just pick up overall for our site.


So it's less a matter of specific kind of meta tags


or specific headings or specific site structure


that you need to have there.


It's more about understanding, well, there's


an article associated with this page,


and we regularly see new articles


on the site with new dates, kind of that general setup there.


It's not, I don't think it's the case


that we look for any one particular factor to say,


well, this is a news article or this


is more of a reference article or an evergreen article.


Thank you.


Hi, John.


Can I pop in with just a quick question?


Sure.


OK, so just a brief context.


I have a website that was stolen about one year ago.


And two weeks after that, the guy that stole my website


redirected to another domain.


And two weeks after that, he redirected that domain


back to my original domain.


So meanwhile, I was able to recover my website


with a court action in US.


So I entered a court action in Victoria State.


So I was able to recover my website.


And that other domain is no longer working.


So the B domain that the other guy created


is no longer working.


But Google is still indexing that other site


with the contents of my site, with the fresh contents


of my site.


So if I go to Google, if I search for the other website,


I will see the contents from my website from yesterday,


from two days ago.


So why is Google indexing the site


that when you go to that site, it's returning a Cloudflare


5.22 error?


But Google is showing my contents,


my fresh contents of my real website.


What kind of query are you?


Redirection, historical redirection that that site


added, because it does not find the site real,


it will go to that redirect.


What kind of query are you doing to see the other side?


So if I do site semicolon and then the site,


I see 13,000 pages with my contents.


But for some specific queries, I see


that other site also appearing before my site


or at the same level of my website.


OK.


So usually, if you do a site query


for a site that is redirecting, we


may show the previous site for that.


And that's something where our systems,


when they look at the ranking, they


try to understand what it is that you're searching for.


And if it looks like you're searching


for one specific website, then we'll


show you that website in the search results,


even if we know that it has been redirecting for a longer time.


So you see this often with site moves,


if you move from one domain to another, probably also


in a case like yours.


One way to confirm that this is the case


is if you look at the cached page of one of those results.


And usually, if you look at that page,


then the URL we show on top is from the destination page.


And that essentially means we're indexing your pages.


But we know that these old URLs were also associated with it.


So if you explicitly look for those old URLs,


then we will show you those URLs.


But if you look for the normal content,


then we will show you the website.


So that's kind of the one thing there.


If you're still seeing it for generic queries, where someone


is not explicitly looking for that old website, that


seems more like a bug on our side or an issue of us


just not having processed it for those particular URLs.


So if you want, you're welcome to send me some examples there.


I'm happy to take a look.


But in general, also, that's something


that might just depend on the timing, where


if you've kind of updated your site and it's fairly fresh


and we just haven't recrawled those old URLs


and understood that actually these are separate now,


then that's something that can still take place


in terms of a couple of months, even


after these changes are made.


And one way to kind of help with that


is to make sure that on your website,


you're submitting a proper sitemap file so that we really


understand this is your website and we can recrawl your website


as quickly as possible with your fresh content


and show that properly in search.


SPEAKER 2


Let me just drop my email here in the chat.


OK.


And then, yeah.


But like I said, the site query results,


I think those will continue to be there


for a longer period of time.


I've seen cases where we've kept that connection


for several years, even though the site has


moved to a different domain.


But if you explicitly look for the old domain,


our systems will try to be helpful and say,


oh, we know what you're looking for.


And it's not really, like if you use it for diagnostics


purposes, that's not very useful.


OK, OK.


Thank you, John.


Cool.


We're essentially out of time for here.


I have a little bit more time that I can stick around.


So I will just pause the recording for the moment


if any of you all want to hang around a little bit longer


and continue to talk about these topics.


You're welcome to do that.


Otherwise, I wish you all a great weekend.


And hopefully, see you all again in one of the future Hangouts.


Thanks, everyone.


Thank you, everyone.


Bye.


JavaScript SEO office hours May 6th, 2020

All right.


Hello and welcome to this week's JavaScript SEO office hours.


My name is Martin Splitt.


I work for the Search Relations team at Google in Zurich,


right now working from home office,


as you can probably tell.


And it is my pleasure to answer your JavaScript SEO-related


questions.


With me today are a few people from the community,


and people have submitted questions on YouTube.


So if you want to be part of this,


check out the YouTube channel community tab


to see when the next Hangout is happening.


I'll also post the link to the Hangout there.


And then later on, I'll also post the recording.


So even if you can't make it for the recording,


it's still valuable to submit your questions.


Right, before I go into YouTube, is anyone in the Hangout


burning to shoot a question?


Yeah, I wanted to know, is eventually one day


will Lighthouse become a ranking factor for website issues


and so on?


I mean, I know you have to pay attention a lot to it.


But I just wanted to ask you just a generic question


in regards to the page speed addict.


I'm not an addict of page speed insights,


but I love the new feel compared to how it changed over time.


And I've been watching it from day one, right?


So I wanted to know, is there any discussions out there?


I know there's a lot of things that you can say,


you're not allowed to say.


But I mean, it's not that I'm not allowed to say.


So there's like three parts to this question in the answer.


First things first, Lighthouse and page speed insights


are developer tools, or actually tools also for SEOs as well


as developers to determine how fast the website feels


to the user.


Now, modeling performance in terms of user experience


is very tricky.


And you have to find the right proxy metrics.


And we're still changing the way that we model.


If you look at Lighthouse a year ago or two years ago and now,


you'll see an evolution of the metrics


and how we mix them to generate the Lighthouse score.


It's not something search specific.


It is for you to determine and for developers


to determine how fast the website feels to the user


and where are the low-hanging fruits, where's


the potential to improve this.


Now, currently, I think like yesterday,


we announced the web vitals, or this morning or something


in the European time zone.


We announced the web vitals, which are three already


existing metrics that we are thinking


as the best way to approximate user experience in terms


of loading speed.


Web vitals are made out of the largest contentful panes,


cumulative layout shift, and first time to interactive.


And that's no first input delay.


That's what the third metric is for.


These metrics, again, model user experience.


As you know, we are trying our best


to give the best results for our users in our search results.


I don't really answer ranking questions because, A, I'm


not working in the ranking part of things.


B, I don't really want to talk about ranking


because there are so many other things that you can do


to make a website good for your users that


will reflect in ranking.


Ranking is basically trying to model what


is a good answer for this query.


So that's the second part.


The third part is page speed is already a ranking factor.


So that will not change as far as I can tell.


MIHAI APERGHISLINGA.


Because it's embedded into Search Console


and there's a delay in the updates in Search Console


for page speed, like for moderate low speed report.


Yeah, the speed report, there's a huge delay in that.


So that's why I asked.


And of course, user experience is the number one thing


that every SEO should just worry about.


And it was just that I wanted to know.


So eventually, as Lighthouse will get evolved,


it's going to change even more as time goes by.


And then I guess other factors will come in.


And then they'll become a ranking factor eventually.


MARTIN SPLITTENBERG. Lighthouse itself, again, is a tool


for developers and webmasters.


It's not any way related to search.


What it does, though, is it tries


to emulate a way of determining how fast the website is.


And under both lab conditions, as well as if you run it


side by side with the Chrome UX report,


then you'll also get real user metrics.


These things will become more important for us


in the future, not as in search, but basically,


as developers and the web ecosystem,


we want websites to become faster.


So you don't have to rely entirely on the Search Console


report. Any way of you figuring out how fast the website is,


especially in terms of real user metrics, not just lab metrics,


is important.


And I also take into consideration


that this is unthrottled all the time.


Throttled is much better.


Checking the throttled connection


as opposed to unthrottled, a lot of this shows there's


the metrics.


They change because you've got to keep on refreshing.


Lighthouse, in general, runs on your computer.


So it's not a real user metrics tool.


It is only lab data.


Right, right.


I just wanted to, yeah.


Yeah, so the more real user metrics


you can get your hands on, the better.


The more lab data you can also correlate with


is also helpful.


Basically, just build fast websites.


That's the goal, really.


And Lighthouse is one tool to look into how you're doing.


Right.


My second favorite, am I allowed to say it on this Hangout


or no?


Sure.


GTmetrix is my second best favorite.


And that's how I achieve an amazing, amazing results


for user experience.


So I mean, there's Pingdom.


Plenty of tools.


And you can choose whatever you think works best for you.


It doesn't really matter.


Because none of these tools shows you the reality.


They are all giving you different views


in terms of what we think of as performance


and how we are all modeling performance.


And when I say we, I mean the entire world.


The entire web community is trying


to figure out a way to model speed and performance.


But one of the reports within Search Console


and seeing which pages suck and why


are people not coming there, that's


what I really watch for is the user experience.


So yeah.


Nice.


Yeah.


Awesome.


Thank you very much for the question.


And I think I'm going to drag one from YouTube in.


And then you'll get the next chance in the Hangout.


Hi, Martin.


One of the websites that I'm tasked


with trying to improve search visibility for


is serving the canonical tag via JavaScript.


The JavaScript is located in the footer.


The canonical appends to the head when rendered.


My question, is that acceptable?


Or should the canonical be hardcoded within the head?


That is acceptable, especially if you use the testing tools,


like the mobile-friendly test, the rich results test,


or Google Search Console, and see that in the rendered HTML,


the canonical tag is, A, the one that you expect it to be


and is in the head, then you will be fine.


It doesn't really matter where the JavaScript runs,


as long as it gets inserted into the DOM in the right position.


And that would be the head.


So as long as it shows up in the head


and is the canonical that you would expect, that's fine.


Well, isn't that great if there's


multiple canonical tags on the page for some reason,


or if the canonical doesn't make sense when we are seeing it?


Like, if you're canonicalizing to something like,


I don't know, a 404 page, then we're like, oh, I don't know.


We don't think that's the same thing.


But generally speaking, using JavaScript


to inject the canonical is perfectly fine,


as long as it's injected in the head, which,


according to your question, it is.


So that's not a problem.


OK, that was a quick one, another real quick one.


Any advices for best practices when implementing tags


using Google Tag Manager?


How does it impact speed optimization?


Generally speaking, there isn't anything inherently wrong


with Google Tag Manager.


And oftentimes, it is the best bet


you have if you don't have that many front-end developer


resources, or if you have other needs that


can't be done otherwise.


Then it's a viable solution.


It is additional JavaScript, though.


And it loads additional JavaScript.


So it does have some speed impact, obviously,


because it's just another piece of JavaScript


that needs to be loaded.


So my best practice is, if you can implement it directly


in the page or with your own JavaScript


that you have to ship anyway, then do that.


If you do not have access to developers or actually making


changes to your site yourself, and Google Tag Manager


is the way that you can actually influence things on the site


and implement additional tags, then use that.


But don't use it if you can avoid it,


because it is an additional dependency.


It is an external piece of JavaScript


that has to be loaded.


So reducing that is generally a good idea.


That being said, there's nothing inherently wrong with using


Google Tag Manager.


All right, question from the audience


while I'm scrolling YouTube for the next question.


I think I submitted one on YouTube,


but I can't find it at the moment.


Maybe we can do it like that.


Sure.


So we're currently building, or we want to build a React app,


and we want to use pre-render to serve dynamically rendered


content to Google.


And of course, whenever you are entering a URL,


it will always return a 200, which is because it's


a single-page application.


Yes.


There is a way for pre-render to serve to Google Bot 404 or 301.


And how does it behave when Google tries to validate?


Or is Google validating if we are serving the same


to the user as to Google Bot?


Because it would result in having the 404 page rendered


to the user having a 200 as HTTP status code.


But for Google Bot, it would be a 404 in this case.


How is generally?


Yeah, so the question aims in the direction of,


is it cloaking to do that?


Exactly.


Generally not.


Unless you do really shady things with that,


then it's not cloaking, especially


if we are seeing that the page that is served with the 200 OK


is also basically just an error page,


then we would highlight that as a soft 404.


Unless we are seeing it because of dynamic rendering,


we're seeing it as a 404 page, then you are in safe waters.


So that's not something that you need to worry about,


generally speaking.


OK.


Perfect.


Awesome.


Martin?


Yes.


Just a quick question.


Some websites are using just watching certain websites


out there, and I do send John some stuff for spammy stuff.


A lot of this brand is misbehaving with its subdomain.


And so it's using its subdomain for links.


And then the webmaster is injecting anchor text and so


on.


I mean, to what point do you guys say, OK, enough is enough?


If the system cannot detect it, the system is right.


So we are pretty much outside of my depth


here, because that's definitely for the web quality,


so search quality and web spam teams.


But in general, there would be no follow, right?


I'm not sure I fully understand the setup.


But if it's spammy and if it's doing


things that are considered non-organic linking,


then that's something that the web spam team is definitely


working towards figuring out.


And if you're giving us hint stores


where we can see samples of that behavior,


then we'll look into them.


And definitely, if it's something non-organic,


then we want to know about these things


and we want to catch these things.


Right, so in general, if you have subdomains


and you're using your clients for links,


that's against your guidelines, right?


I'm not sure how the subdomain plays in it.


Generally speaking, if you are using non-organic links


and don't tell us about that being a sponsored link


or something like that, then that's a questionable tactic.


OK.


I don't understand the subdomain part of this.


So this is probably another question for Jonathan for me.


There's a click.


They're using it.


They're basically taking these subdomains


and pasting it on their clients' websites


and then using it for?


Aha.


Right.


Yeah, that sounds like classical link spam to me.


Yeah, but the thing that exactly.


I even shared it with other of your colleagues.


And it's been going on for years.


And I've been watching it.


It just keeps on going on.


And I don't know, every day there's new links coming in.


We all ask you.


As I said, I'm the wrong person to talk to.


That's a question for Jonathan.


OK.


But in the end of the day.


It has nothing to do with JavaScript either.


So I don't know.


I'm out of my depth here.


Well, no, it's just being injected internally.


Yeah, but I would have to see the example.


And it's not really my topic.


So I would ask John that question.


Right.


One more from the YouTube list of things.


My website runs a ready-made site builder, something


like Wix, but a local company in Thailand.


Since they upgraded their front end from PHP to Angular,


where canonical HREF meta details are dynamically


rendered for Googlebot, I have noticed a huge drop


in ranking.


Is it because Googlebot can't process all the script properly


for both meta tags and content?


And is in GSC excluded URL section,


I notice too many URLs being crawled


are weird URLs with parameters.


Generally speaking, this is unlikely the cause


of the rank drop.


There are many factors and hundreds of factors


that go into this.


And I don't really discuss ranking to begin with.


But it is not impossible that there


is some technical reason for why we are not seeing the data.


It can be that the site builder is somehow


preventing us from crawling some JavaScript resources.


It is possible that the JavaScript is buggy.


You would have to use the testing tools


to see if we see the content that you put in your pages.


If we do see that content, then you


are at least on the technical side, you are safe.


But then you would have to figure out


any of the other things is off.


Is the page really slow?


Is it doing something weird when Googlebot is indexing it?


Is there anything happening that shouldn't be happening?


It can also be that their site maps are not helpful.


Because if you say you're seeing lots of URLs with parameters


that you don't expect to be there,


then that's probably a problem on their end,


where they generate additional URLs.


And that is not necessarily helping us.


And then combine that with a technical issue


that there might be, then you would have very easily


an interesting situation at your hands


that you need to clean up.


So I would talk to the platform that you're


using to figure out what they do, how they do it,


and how they can help you resolve these things.


Without looking at the URL, it's impossible for me


to judge what's happening.


I have a React static website hosted on React static, OK,


on AWS S3 behind an AWS CloudFront CDN.


How can I do a 301 redirect on the client side?


There is no such thing as a client-side 301 redirect.


301 is the HTTP status that you're using.


The HTTP status comes from the server.


I'm not 100% sure.


I haven't used S3 and CloudFront in a while.


But I'm not sure if you can set that up on CloudFront.


I guess you could potentially route some URLs


through Cloud Functions or something


and then actually generate a 301 response.


But once you are in user and client land,


basically once you're in the browser,


there's no such thing as a 301 redirect.


What you can do, though, is you can use JavaScript


to generate a client-side redirect.


That is not a 301 redirect.


Googlebot does follow those and pretends


it to be like a normal redirect.


So it doesn't really make a difference to us


if it's a 301, 302, or client-side redirect.


So that's a way around this problem.


But there is no such thing as a client-side 301 redirect


because 301 is a server-side HTTP status.


One more, and then a question from the audience.


We have a website which is built on Angular


and has a client-side rendering, which


means that when you view the source,


you see the Angular tags and the code and no tags.


The text is dynamically shown after the page loads.


When switched to server-side rendering,


it shows the content wrapped around the text.


What would you suggest?


Client or server-side rendering?


I guess according to me, I should


go with server-side rendering as Google


will require the text content to be crawled and indexed


to understand the context.


Yes and no.


We don't need the server-side rendering for Googlebot


because we are also running JavaScript.


So if you are putting your client-side rendered version


into our testing tools, like the Move By Friendly test,


the Bridge Results test, or Google Search Console,


you will see that we are very likely seeing


the actual content rendered once JavaScript has executed


and your Angular application is ready in the client-side


rendering scenario.


That being said, if you can enable server-side rendering,


and there is no good reason not to in terms of you


know what you're doing and you have that setup tested,


or even better, you're starting a new project


and you get to choose which way to go,


I would highly recommend looking into server-side rendering


as an investment because server-side rendering usually


is faster for the users and also works for bots that


don't understand JavaScript.


So most of the major search engines


to understand JavaScript, as far as I know, I can tell for sure.


For Google, I know that Bing is also rendering.


I don't know about the others.


But things like social media bots,


when you share something on social media,


they oftentimes do not run JavaScript


or don't understand JavaScript, and those would be left out.


So if you use like open graph tags for social networks


and use them in JavaScript, then you wouldn't see them


on these social networks because they


don't execute JavaScript.


So I recommend looking into server-side rendering,


but it's not necessary for Google search at least.


OK, time for a question from the Hangout.


Can I ask a question?


Sure.


Cool.


We're doing a server-side rendering


like the common practice.


And clearly, as we render the page,


we have state built on the server side,


and we serialize it and push that down along


with the already built HTML to the client.


So my question is, when the bot sees that payload,


it's like a duplicate content.


Everything appears twice, right?


Once in the state, like this JSON string,


and once within the actual DOM or the actual HTML.


Is that a problem, like this duplication?


No.


If it's JSON state, especially if it's just application state


in the memory, we don't care.


We look at the DOM, and we only take what's in the DOM.


Thank you.


You're welcome.


Here's an interesting question.


Is it OK for SEO to use services such as Cloudflare's Rocket


Loader?


It helps us reduce paint times speeds,


but I'm not sure how Google would read it.


I don't know either.


I haven't tried Cloudflare's Rocket Loader.


I haven't used Cloudflare much.


It's pretty good.


I'm not doubting that.


The thing is, the easiest way for you to test this


is point our testing tools to one of your URLs.


If your content shows up, you should be fine.


That's all I can tell.


I know what Rocket Loader is and what it does,


but I just don't see why it would inherently be a problem.


But I'm never saying something like, oh, yeah, this is fine


when I haven't tested it.


So as I haven't tested it, I highly


recommend you all test this.


Try this out for yourselves, and if it renders the page fine


in Googlebot, then you should be fine.


In Search Console, when live testing a JavaScript rendered


page, we sometimes see static resources


like JavaScript or CSS files.


The requests are failed, but there's


no details about why they failed.


Retesting the thing, again, sometimes work.


What is the recommended way to debug such issues?


This is unfortunate, but this is a limitation


of the testing tools, unfortunately.


So the thing is, generally speaking,


the way to debug these things is look


at the reason in the mobile-friendly test.


For instance, there's a reason field or something like that.


And I can actually see if I can bring this up


on the screen real quick.


I should be able to.


Maybe I'm actually getting an error now.


That would be convenient, but maybe I'm not.


And then I have to deal with the fact that I'm not


getting the error.


I want to share the Chrome tab.


Oh, my screen has gone again.


This becomes really annoying that it does that now.


OK, here we go.


I think this has something to do with the screen getting


too warm, because the sun is shining onto my screen


right now.


OK, if I go to some URL experiments,


keep an eye on the features.


And if I'm lucky, there's actually,


I think features is a bad example,


because I don't think it loads anything interesting.


Interesting.


Oh, I know why my SSL certificate for this one


has expired.


And honestly, I don't really care too much for this page.


That's new.


Right, fantastic.


I can't show this right now, but basically,


is this because my website is somehow broken or something


like that?


Let's see.


Code.


Or is there a fundamental bug in?


No.


OK, so at least the testing tools


don't seem to be like broken, broken.


They just didn't like that URL, and I'm not sure why.


Maybe I made something weird happen on that URL.


No, it's also just, oops, something went wrong.


Is this because I'm locked in with that specific account?


Maybe I need to use a different account.


Can I actually share?


It's a good one.


I think this is the right window.


I think you should be seeing a fresh Chrome window now.


Let's try this one more time.


This might work.


I don't know.


Let's try this.


So there is a column that says why the request has failed.


And oftentimes, interesting.


OK.


Is it because you have got the HTTPS?


I don't think that should be the problem.


Because it's paired with a different URL as well.


I'm not sure.


Let's see what happens when I try this again


with a completely unrelated URL.


How about, I don't know, this one


that's from a previous office hours.


Maybe I'm just unlucky right now.


Maybe we're over capacity or something.


Who knows?


Anyway, so you see the reason why it failed.


And there is the infamous other error.


If you're seeing the other error column or status code


or reason, I'm not sure what we call it in the tool, actually.


That's why I'm trying to run the tool.


The other error basically just means,


welcome to the world of limitations.


While Googlebot, when we are indexing pages,


is very patient with things and can retry stuff over and over


again, so hypothetically, it can take anything between seconds


to hours to I don't know how much, because we are retrying


if something goes wrong, the test does not.


The test does not have the affordance to actually


our status.


Thank you very much, Dave.


So the status in the Resources tab


tells you, ha, OK, fantastic.


So I have opened a random website


that was in the previous office hours, I believe.


And I can now share this with you


as well, because it says actually finally loaded.


And I think we are lucky, because we actually, yes.


So this happened multiple times in this case.


Am I sharing the right window?


I'm not sure.


Yes, I think I share the right window.


If I zoom in a little bit, we see here in the status.


Thank you again, Dave.


In the status field, we have other error.


If you see this, that usually means


that we just didn't have the resources or the time


to wait for the resources to load.


We have a limited quota of how much we can fetch in one test.


So sometimes it just takes you a few iterations.


Also, normally we are caching quite heavily.


The test tools are not caching.


And that's why sometimes things time out.


That isn't a problem.


That is not a problem.


As I explained, the Googlebot is actually very patient


and usually does not have these limitations.


So what you can do to figure out if things look fine,


as far as you can tell, is you can use Search Console


and see if the page is indexed, as you would expect.


And you can use the URL inspection tool


to see the crawled page, which shows you what is the HTML


that we saw when we rendered the last time.


If you would see that the crawled page has issues,


then that's something you want to investigate and make sure


that it's not something like robots.txt or something


blocking us.


But also, you would see the error in the testing tools


if that is the error case.


If you see other error, that is just the fact


that the testing tool both does not use caching


and B is a lot less patient, because we don't want you


to sit in front of your computer for an hour


until the tool actually shows you any results.


That would be unfortunate.


So that, unfortunately, sometimes happens.


All right.


Before I scroll further on this list,


any further questions from the audience?


AUDIENCE MEMBER 1 What's your favorite framework?


MARTIN SPLITTENBERG I don't have a favorite.


For me, they are tools.


It's like asking what's your favorite tool,


and that depends on what's the job that I'm trying to do.


I think all the frameworks today are very, very similar.


I like to think of it as a, for me,


a framework is basically a bunch of decisions made for me


and a bunch of tooling around it and the community around it.


So for instance, if I say, OK, I work in a large company


environment where we have lots of developers working


on the same application together and the teams are distributed


and the application is really, really big


and there's a lot of interaction,


the application is really, really big and there's a lot of interaction


with the back end and everything,


then I might want to choose a tool that


facilitates the successful deployment and development


in such an environment.


And one of these things that makes these things a lot easier


is TypeScript.


TypeScript adds system information


to more or less JavaScript.


So it gives you a type safe variation of JavaScript


or a superset of JavaScript, if you wish to say that.


And then one framework has that built in.


So I don't have to configure it.


I don't have to work out how it works with this framework.


It's just built in.


And that's Angular.


So maybe use that then.


If TypeScript is a big thing for you,


then I think Angular is an easy choice


to make because it comes as a TypeScript version.


Sure, you can use TypeScript with React.


Sure, you can use TypeScript with Vue,


with Ember, with everything.


It's not that you can't do it.


It's just more effort.


Also, if you are working with a team


where Java developers from the back end


now have to work on the front end as well,


then Angular feels a little more familiar, I think,


or TypeScript feels a little more familiar.


So I think that's a good choice.


If you are working in an environment where you don't


really need a framework, framework,


but you need a bunch of components


that are mostly vanilla in a way,


then maybe Vue or React are the better choices.


If you really like the Vue ecosystem, then go with that.


If you prefer the React ecosystem, go with that.


I don't think there is a best framework because they just


made different decisions in different spots.


For instance, React's biggest thing


is that they have a DOM abstraction layer.


So React has the ability to say, oh, I just


want to compile everything that I wrote


into a mobile application or into something


that runs on the Oculus Rift VR display, for instance,


whereas the others don't really have that.


I mean, there were and are options for this,


but what's the point?


So you can integrate more with React.


You can do a lot of integration with React where Angular,


I mean, Angular is getting there, right?


And also, the other thing is I don't


know how easy these interactions or integrations


with React really are because I heard


a bunch of people who tried React Native


and weren't as happy.


But then again, other people who were super successful


with React Native.


So I guess it doesn't really depend on the tool.


It depends on you, your resources, your project,


what are you trying to accomplish,


and what decisions would you make


in the process of designing the system.


And then you find the framework that has made


more or less the same decisions.


That's how I would do it.


So I know in my previous job, I was


tasked to figure out which framework we should


be going with as we were rewriting our application.


And I just sat down and talked to the developers on the team


and figured out what are their preferences, how do they think


about systems, how do they approach


building web applications.


And then I made a decision based on that.


And I figured out, OK, so pretty much all the frameworks


are an option for this thing, which are the decisions


that we would like to make, and then


which framework mirrors that.


Cool.


Back to SEO.


Are there quotas that Googlebot uses


when crawling JavaScript rendered pages or sites?


So crawling has not much to do with rendering.


That's two different phases.


Crawling is just we give a URL to the bot,


and then the bot makes an HTTP request to it.


That's where crawl budget comes in.


And that is kind of like how many requests


we can do in parallel.


And these requests also include things


like API requests and JavaScript file requests


and all that kind of stuff.


So it does have a little bit of an impact,


but not as much as people might think, especially


because caching is involved.


I wouldn't worry about it too much.


Unless you have a really, really, really big site


with lots and lots of JavaScript files,


you might want to consider bundling and also tree


shaking a little bit and maybe also looking at code splitting


at the right spots.


But there's no such thing as a render budget or a JavaScript


budget or anything like that.


There is crawl budget for crawling specifically, though.


But that's also true for non-JavaScript websites.


Does Googlebot still recommend using snapshot tools


like RenderTron for serving websites built


with modern JavaScript frameworks?


No.


It's a workaround.


You can use these tools.


And RenderTron is still actively being maintained,


as you can see Tuesday and Thursday


when I do the Twitch streams where I actually


do maintenance on RenderTron.


But it is not necessary for Googlebot.


And we consider it a workaround because if you


have JavaScript that causes interesting situations


in Googlebot, it probably also causes interesting situations


for users.


So you either have to fix that or actually possibly


consider server-set rendering as an alternative.


The dynamic rendering was and is a workaround rather than


a long-term solution.


And I think that's it for the YouTube questions.


So more questions from the audience here?


MIHAI APERGHISLAYA-SINHAVIORIYA Hey, Martin.


MARTIN SPLITT I'm Mihai.


MIHAI APERGHISLAYA-SINHAVIORIYA Just actually a quick follow-up


to what you just mentioned.


So just curious if you have, I mean,


we work with a website that only part of the content


is being generated asynchronously


through JavaScript.


So it's an e-commerce website.


And the product listings on category pages


are loaded after the initial page load.


It works very fast.


It shows up OK in the URL inspection tool.


Should they do anything special if everything


seems to work fine as it did?


MARTIN SPLITT No, I wouldn't fix what isn't broken.


MIHAI APERGHISLAYA-SINHAVIORIYA OK, so no server-side rendering


or anything special will work?


MARTIN SPLITT Unless you have a good reason to.


I mean, as I said, server-side rendering, if done right,


is fantastic.


But it's also an investment.


If you don't want to have that investment made


or if it's not a priority and your website is fast already,


then you're probably not winning as much.


So I would not change something that works.


MIHAI APERGHISLAYA-SINHAVIORIYA But these being category pages,


is there a risk that Google might take a bit longer


until it finds the links to the product,


since the products are loaded after the initial page load?


So you have to look and discover the links?


MARTIN SPLITT So we can only do the link discovery


after rendering it in.


But normally, that isn't a problem.


For 90% of the pages, or URLs, we


are actually seeing a render time, well, a render queue


time within minutes.


So you would only probably shave off a few minutes.


And usually, the investment into server-side rendering


for an existing project is quite substantial.


So I don't think you're going to win much, really.


MIHAI APERGHISLAYA-SINHAVIORIYA Right, right.


OK, cool.


Good to know.


MARTIN SPLITT You're welcome.


All right.


We have a bit of time left.


That's nice.


So more questions?


Do you recommend a shared server or having a dedicated server?


That depends on many things.


It doesn't make a difference for us.


It can make a difference for you if you notice


that your performance isn't great,


as in server-side performance isn't great.


If things take longer to save into a database,


for instance, that will mean that users maybe ordering


something from you will take longer until they


have the order confirmation.


If the hoster doesn't balance things properly,


then the server might go down because someone else


is having a lot of traffic.


So there isn't fundamentally anything


wrong with a shared server, especially


from our perspective.


We're just going to do as many requests


as we can reasonably do and want to do.


And there isn't an inherent upside or downside.


We don't want to rack up more expenses.


It doesn't make sense that we go from a shared to a dedicated.


But then you show them the slow speeds.


And then you explain to them that it can be a ranking issue.


With slow speeds, you have to be careful, though.


What is slow?


Time to first buy it being slow?


Or is it that their server process takes too long?


Or is it network being slow?


The website and the server.


Right.


And then there's a lot of people on the shared server.


So the server responds very slowly.


Extremely, yeah.


Because that's the thing.


You want to be very careful that you make sure that it's


actually this.


If you ping the server, it's really slow.


And if you make network connections to the server,


that's where the time is spent.


You can see that in the network timeline where time is spent.


If their server is really slow, it's


fine for them to not care about it.


Generally speaking, it is one ranking factor.


But it's not the most important one.


And it's also not the only one.


So I wouldn't argue that that's necessarily time best spent.


Making the website faster, as in the client-side performance


of things, that's separate from the server question.


If the client-side performance of the website,


as in once things have arrived over the network,


it takes a long time to actually show things to the user.


That's something that they probably want to fix.


Because that's something that drives people extremely mad.


A slow server can be oftentimes compensated with good caching.


So that's something they probably want to look into.


And only if really the server gets very, very slow


and also unreliable, then that's something


that I would bring up with my hosting provider.


And maybe they can move you to a different part on their side


so that you're still on the plan of a shared server,


but you're on a less busy server,


on a less busy physical instance if they don't want to rank up


or rack up more expenses.


And then they have to figure out where do they


want to spend the money.


It's also a possibility to use a CDN in front of their server


so that more things get handled by the CDN


instead of the actual backend.


There's ways of working around slow servers


without having to get a separate dedicated server for more


money.


Yeah, no, of course.


You've got many options for CDNs out there.


OK, thank you.


So that's something that I would look into before I recommend,


strongly recommend switching servers or providers.


Awesome.


Any other questions?


I think there was someone else trying to get a question in.


Yeah, it's just a quick one.


In some ways, I suppose it follows on from Mial's stuff.


With things like Nuxt and Next and everything,


you've got this nice, hydrated server-side stuff.


Occasionally, there'll be components people use


that are only client-side or only work client-side


because they don't want to fix things, things like window.


Is that really a problem as long as you use the testing tools


and they show?


Is there any kind of panic where you're sending out something


then hydrating part of it?


No, I think that's fine.


That's fine.


Again, especially hydration is a really nice thing


because you get best of both worlds normally.


And if it takes longer to hydrate, that's OK, I guess.


There's no inherent issue.


It depends.


And I would very carefully use the test tools


to see if we are actually seeing what we need to see.


Also, things like Lighthouse will show you


if there is things like layout shifting


and all that kind of stuff that also is not


great for user experience.


But unless you see something wrong there, stick with it.


It's fine.


Just to follow up on that as well, if I'm sorry,


do you know much about the CLS score, the thing that the


I haven't really looked into it yet, I have to admit.


But I think it makes perfect sense


as that is a factor that is super annoying if you


experience it as it would deserve.


The amount of things that popped up on my phone


just because I clicked or tapped on something


and it actually moved while I was tapping,


frustrating, I tell you.


So I'm really excited to see more work around these things.


And it's also very impressive to look at how the metrics have


evolved from years ago.


We looked at page load times.


Like, what is a page load?


Is it the time when the HTML is completed?


Is it the time when JavaScript has completed?


But what is?


And yeah, it's quite interesting.


And we'll see more in the future, I'm sure,


because that's an ongoing challenge to better understand


and model what performance means to a user on the web.


Awesome.


You think it's important?


Do you think it's important as well


when people are looking at things like performance,


they take into consideration what their site is?


Because something that's very interactive,


FID might be more important.


Something that's just an article.


Something more like LCP might be more important.


And that's a huge challenge.


That's true.


That's the huge challenge.


On one hand, you want an easy to grasp metric


that makes sense if you just look at it in a glimpse,


like the Lighthouse score.


But at the same time, you can't break it down


into a single score.


Because you might think, actually, fun fact,


this is a thing where users only come in once and do the thing


once.


So I don't really care if we have a service worker,


because they are not coming back normally to this website.


Or well, actually, we kind of don't


care about our first user journey


or first time visitor, because we actually,


the first time visitors come in through these other landing


pages, which are really fast.


And then they log in, and then they get the service worker.


So it is really, really hard to model this and really, really


hard to balance both needs, which


is why when people ask me about the Lighthouse score,


I'm always like, see it as a smoke test.


If your Lighthouse score is 5, you definitely have work to do.


And you should get to it as quickly as possible.


If your Lighthouse score is 95, sure, there


is a bit of shaving the yak, as we like to say.


There's a little bit of turning knobs and fine-tuning dials


there.


But I'm not sure if it's going to buy you


as much as you think it does.


And if you're somewhere in the middle,


then it depends on where is the problem.


As you say, if you have a highly interactive chat app,


and every value is fantastic except first time


to interactive.


If your FID is first interactive delay, or sorry,


first input delay, if the first input delay is really,


really high, then people will get frustrated trying


to actually interact with the crowd,


and they can't because the website's still loading.


It doesn't matter how great the other values are.


If that's a blocker in your application,


then you have to address that.


Whereas a website like Wikipedia might not


care as much about the interaction delays,


because they're like, well, we just


have to get content for the reader


to actually observe and read as quickly as possible.


So we care more about the largest contentful paint.


So yeah, it's not easy to express all of these differences


in a single score.


So take your Lighthouse scores with a grain of salt,


which doesn't mean that you should rationalize having


a Lighthouse score of five.


That's very likely.


It might also be that Lighthouse had an issue understanding


your page, which you can then say,


it's not a performance problem, or it's a performance problem.


Not easy to break this down.


So is 5G going to make things easy?


Sorry?


Or is 5G going to make things easy for JavaScript or worse?


Looking at how it has been evolving so far, no.


I don't think so.


Because the tendency is, if you look at things like,


we have so much faster machines these days.


Yet, software hasn't gotten faster.


It still takes ages for me to open some websites.


It still takes ages for me to open certain applications,


even if it's native applications, where I'm like,


how does this happen?


We used to have this fast and relatively well-working,


even if the UI didn't look as fancy.


This was fine 10 years ago.


This is still fine, but not great.


So I think a faster network speed will probably only


invite different use cases, use cases that we probably


haven't seen today.


Maybe like more wet VR, so that we are all


doing our Zoom meetings.


Instead of in Zoom, we do them in VR


and in the browser, which is fantastic,


but also means that we have to move a lot more data.


So then that eats up the more bandwidth, the more speed


that we have.


What?


And sorry for that.


And so I don't think that more bandwidth and faster


mobile speeds will fix these issues inherently,


because we tend to just use the bandwidth more than.


Right.


Hopefully I'm wrong.


That would be fantastic, but I have a feeling


that it won't be so easy.


All right.


Anyone else having a question?


I think it's a good time for the last question.


There's one more on the YouTube submitted questions,


but I'm not sure how to answer this one,


because it's a very vague question.


In what aspects should I be aware of


if I want to change my website by applying


single page with Ajax?


I'm assuming this question was about building a client side


rendered single page application, at which point


my suggestion would be consider a higher level framework,


like Nuxt or Next or Angular Universal


or any of the other frameworks available that have server side


rendering built in, because server side rendering usually


means a better user experience, and it's usually a lot faster.


That being said, there are a few things


that you want to watch out for.


Definitely test your implementation


with our testing tools, making sure


that we are seeing the content in the rendered HTML.


And yeah, there are a few things.


Check out our documentation on developers.google.com


slash search.


And in the guides, we have a bunch of guides


that give you hints and ideas.


Or check out the JavaScript SEO series on our YouTube channel.


Good.


Thank you very much, Martin.


You're very much welcome.


Be helpful, yeah.


Awesome.


I think we have time for one last question for real


this time, if anyone in the audience has a question.


Hi, Martin.


Hi.


This is Vahan from Search Engine Journal.


I would like to ask one question about the service worker.


We have implemented service workers


to serve the web P images instead of using the picture


tag with the HTML plot with the source tags in it.


So actually, there is the action we do.


We check through the service worker


if browser does for the web P. We change the image format


to web P. We fetch API and return web P image in response


to JPEG or PNG.


But when the images are opened directly


in the browser without the HTML web page,


we do serve correct format, like PNG.


So it's PNG and JPEG, so it's JPEG.


So actually, web P are served only


when the images are fetched from HTML web pages.


So may this cause any image ranking issues or trouble


issues?


I don't think this is going to cause any specific issues


within it with the images.


But it also means that we are not seeing the web P formats.


Because we are not running the service worker, so we


won't see the web P file format.


But when I check via web.dev or a page speed tool,


it does see web P.


Because that has nothing to do with Googlebot.


Googlebot doesn't see it.


Yeah.


OK, gotcha.


Thank you very much, Martin.


You're welcome.


All right, ladies and gentlemen, thank you


so much for joining this week's JavaScript SEO office hours.


I hope that this was helpful and entertaining a little bit


as well, especially unlike the discussions that


creep in every now and then.


We will be back next week.


I'll post in the Community tab on our YouTube channel.


This recording will be up soon-ish.


And thanks so much for joining.


Have a fantastic time, and stay safe, and stay well,


and stay healthy.


Bye-bye.


Thanks, Martin.


Goodbye.


Thank you.


English Google SEO office-hours from October 8, 2021

Any hands to ask questions?


Yes.


OK, then I'll raise my hand.


Thanks.


All right, welcome, everyone, to today's Google Search Central


SEO Office Hours Hangout.


My name is John Mueller.


I am a search advocate at Google here in Switzerland.


And part of what we do are these Office Hour sessions,


where people can jump in and raise their hands


and ask questions.


And we have a bunch of questions also submitted on YouTube.