as well, especially if you're saying


English Google SEO office-hours from January 21, 2022

like these are discount pages.


I don't know.


Maybe coupon pages, those kind of things.


Because sometimes certain types of pages


almost fall into the category of like,


oh, we don't know if these are really high quality pages


or more lower quality pages.


But I don't know if any of that applies


to your specific website.


So that's kind of why I think having some sample URLs


from you would be really useful.


Sure.


We'll send to you later.


OK.


And like you said, the site, the specific site,


we also have these specific pages in other subdomains


like Spanish site and also like some Germany site.


They are all good, nothing unusual.


Only that one French site.


Yeah.


I don't know.


I'll take a look.


Thanks.


Cool.


I see we still have lots of hands raised


but also lots of questions submitted.


So I'll jump over to some of the submitted questions


and get back to the people who have their hands raised as well.


Let's see.


We've been trying to create Search Console


properties for some of our country-specific folders


to monitor their performance.


We don't use trailing slashes in our URLs.


So when a new folder is added to Search Console,


the trailing slash is automatically


added to the address.


And no data is captured and reported


for the non-trailing slash version.


Is there a way to add a folder and capture


the stats for the non-trailing slash index page as well?


No.


Currently not.


So from our point of view, a page without a slash at the end


is just a page.


And if it has a slash, then it's a folder.


And that's kind of the model that we've


used for Search Console.


So if you have kind of like the home page


of one section of your website and it doesn't have a trailing


slash, then we would see that as a page


within the higher-level site.


And so on the domain level, probably you


would see all of these.


If you want the data visible independently,


you kind of have to pull that out from the higher-level


property in Search Console.


My website, averaging around 200,000 sessions a day,


was hit by a technical problem.


And the site was down for 14 to 15 hours just two days ago,


while yesterday's traffic was roughly normal.


Today, a lot of our pages have gone


missing from Google searches.


The site has been stable for eight years.


We've never had a problem like this before.


What do you recommend?


So usually, if you have this kind of technical issue


for a short period of time, it can


happen that these pages will drop out of our index.


And usually, they will pop back in fairly quickly as well.


So what usually happens is the pages that we crawl more often


probably get picked up first and get noticed


during this technical issue.


And maybe we drop them during that time.


So you probably see that reflected in your traffic


as well.


But the good news is that these pages tend also


to be recrawled fairly frequently.


So they should pop back in fairly frequently


or fairly quickly afterwards.


The best way to protect against this kind of issue


is to make sure that you have some system in place that


can serve a 503 result code when things go wrong.


And it might be that it doesn't trigger automatically.


But even if you can manually turn this 503 result code on,


essentially what happens then is when


we crawl the pages during that time and see the 503,


then we will say, oh, there's a problem here.


We will ignore it and come back later to double check.


And essentially, if you can serve a 503 results code,


then for a period of a day or two,


then we will just see that as a temporary glitch.


And we will not drop these pages from our index


because we think that they still exist.


Whereas if you serve a 404 or if you


serve an empty page or just an error page directly,


then we might assume that this page has actually gone


and we'll drop it from the index.


So that would kind of be my recommendation.


Oftentimes, you can't just jump in when things go down


and suddenly figure out how to do a 503.


So I would just prepare that kind of a system ahead of time


so that you can switch over as quickly as possible


should you notice that something like this has happened.


And if you can serve a 503 for a day or two,


then you should not see any changes in your search indexing


at all.


If it's longer, then obviously you could still.


But at least for those one day or two, you kind of protect it.


And in the case that you can't do that like you did here,


I would assume that this will just come back automatically.


I don't think there's anything manual that you need to do.


We will recrawl these pages.


We'll notice there's good content there again.


We'll index them again.


We'll kind of pick up the signals that we had before.


It should essentially be indexed and ranked similarly


to before.


There should not be any long-term issue here.


A backlink question.


We're using PR service.


To spread out our PR articles, the service


publishes on various websites, mostly with nofollow.


And I think it goes into sometimes they don't


have a nofollow on these sites.


What should we do with those kind of dofollow links?


Should we disavow them or not use the PR service at all?


From our point of view, if you're


taking care of the bulk of the issue, then that's generally OK.


And that's not a problem.


It's not something that I would worry too much about.


If it's the case that you're using this PR service


and 99% of the links have a normal link to your website


and 1% has a nofollow on it, then that


seems a little bit fishy.


But if you're saying that most of these links


are nofollowed, like they should be for PR articles,


I would not worry about this.


We want to migrate the content of one website


to two separate domains and basically split it.


What should we do in the old domain Search Console?


Which domain should we point as the recipient?


How do we notify Google?


So in a case like this where you're splitting or merging


websites, you can't use the change of address tool


in Search Console because it relies on the fact


that the move is a one-to-one move from one domain


to another domain.


And as soon as you're splitting or merging websites,


then that's not a one-to-one move anymore.


That's essentially something that has to be processed


on a per-URL basis.


So for these kind of things, essentially what you want to do


is just set up redirects properly


and follow the normal guidelines that we have for site moves


and just keep in mind that the Search Console setting


for change of address is probably not suitable there.


Also, the Search Console setting will


try to test some sample pages on your site for that redirect.


And it might be that it looks like everything is OK.


But I think it would still be wrong to use that setting


if you're splitting a website up.


Just because it could potentially mess up signals


a little bit, I doubt that it would really cause problems.


But I don't think you would have any advantage of using


that kind of change of address tool


if you're not actually moving from one domain to another.


Let's see.


I'm setting up a central US English-based page


for the About contact with schema information


for various office locations and contact points.


But there are also localized versions


of the pages in the different country versions,


often with fewer offices and phone numbers.


How important is it for these localized pages


to get their own schema?


Or can Google pull enough information


from the primary English version of the page that


lists all worldwide offices and phone numbers?


So I think there are two aspects here.


On the one hand, if you have different local versions


of a page, we would not pull the structured data


from a different page to try to apply


to that local version of the page.


So it's not that there's any magical passing


of structured data that's happening behind the scenes


to individual parts of a website.


The other thing to keep in mind here


is that structured data is something that primarily you


would use because it has a visible effect in the search


results.


It's not really something that would


change the ranking of a page.


So if you're using the structured data


to get some specific feature in the search results,


then I would put that on those individual pages


where you want that feature to be used.


If you're just using the structured data


as a way of giving Google a little bit more information


because maybe Google will find this information useful,


then that's something where I'd say it's a very, very


small thing.


And whether or not you do it or don't do it


is probably not going to change the overall perception


of a website.


So especially with regards to individual locations,


my understanding is we don't show this in the search results


anyway.


At most, it might be shown in a knowledge panel


on the side, which would probably also


be pulled from your Google Business profile listing


so probably this particular type of structured data


is not critical for your website anyway.


So from that point of view, if you


want to put it on these pages, go for it.


If you can't put it on all of these pages,


then it's probably not critical because we don't show it


If it were something that you wanted


to have shown in the search results,


then I would make sure that you put it on all of the pages.


There's no magical taking it from the search results


of taking it from one version of the site


and applying it to another version.


About a year ago, you mentioned that there were experiments


with a badge in the search results regarding page


experience and Core Web Vitals.


Is this still something that we're


going to see in the future?


So I can't promise on what will happen in the future,


unfortunately.


And since we haven't done this badge so far


and it's been, I think, over a year,


my feeling is probably it will not happen.


I don't know for certain, and it might


be that somewhere a team at Google


is working on making this badge happen


and we'll get upset when I say it, but at least so far,


I haven't seen anything happening with regards


to a badge like this.


And my feeling is if we wanted to show a badge in the search


results for Core Web Vitals or page experience,


then probably we would have done that already.


That said, everything around Core Web Vitals and page


experience is constantly being worked on,


and we're trying to find ways to improve those metrics


to include other aspects that might be critical for websites


or for users that they care about.


So I wouldn't be surprised if any of this changes,


and it might be that at some point


we have metrics that are really useful for users


and which make sense to show more to users.


And maybe at that point we'll have something more visible


in the search results or within Chrome or I don't know, anyway.


So it's really hard to say there.


How frequently does the Google News algorithm surface


or accept or review new news sites on the platform?


I don't know.


I don't have much insight into the Google News site,


so I can't really say much with regards to how frequently


things change there.


We're moving our website from Magento 1 to Magento 2.


In the past, we sold internationally,


so we had subfolders for different countries.


Now we're going to focus only on UK,


and we don't need those subfolders.


Is it best for ranking to remove the UK subfolder or to keep it?


If we do remove it, how can we tell Google to change the URL?


We have so many external links to our products


which have given us a good natural position on Google,


and we don't want to lose it when we switch our new Magento


2 site on the server.


So first of all, I don't know what


is involved with switching from Magento 1 to Magento 2.


It might be just a back end change that Google


doesn't notice at all.


So from that point of view, I would double check things


like the URL structure of your website, how that changes,


the internal linking if anything changes there,


the content that you're displaying it,


how you're displaying it to users, all of those things.


It might be that this is really just like a back end move,


and maybe some of the functionality within the site


is improved.


And in cases like that, that kind of migration


I don't think would have any effect at all in search.


So that might make it a little bit easier to look


at what you need to do with regards to restructuring


the site from different countries subdirectories


to just one country subdirectory or putting everything


on the route.


Essentially, all of these changes


would be kind of like restructuring your website kind


of thing.


So it's something where you would


expect to see some fluctuations in search


as all of that bubbles down.


And the important part is really that you


make sure that everything is cleanly


moved to the new location.


I don't think it matters if you use a UK subdirectory


or if you put everything on the route.


Having a UK subdirectory might make


it easier if you decide to go to different countries again,


but that's more of a strategic decision.


But any kind of a move where you're significantly changing


the URL structure of your website,


you will see fluctuations because we


have to recrawl the whole website


and understand the new structure.


And that will happen in either of these cases.


And I think the aspect to keep in mind


is these kind of fluctuations can last for a while.


It can be that it takes a month or two to kind of settle down


again.


So it would be good from a practical point of view


to try to find a time where you're not reliant on search


traffic as much or maybe where you can do some extra marketing


campaigns or something else to kind of even things out


or at least so that people who are involved with the website


have the right expectations that this


is going to take a little bit of time


and there will be some fluctuations in search.


Let's see.


And maybe the last one from the list here.


As a website owner or SEO, can we


be 100% sure that every single answer we get on this YouTube


channel is 200% factually true?


Or should we not solely rely on these answers


and always do our own search?


I don't know.


That's like a big question.


I don't know how I could be 200% factually true.


That's kind of a high bar.


In general, most of the things that we talk about


are based on the documentation.


And especially the technical details,


you can look them up in the documentation.


So there should always be a way to kind of double check


what is happening here.


Some of these things are more strategic questions.


And especially for these strategic questions,


it's something where you can use different strategies


and come to the same goal.


It's not that this one strategy is exactly what you need to do.


It might be that you could do it in a different way.


And the other part I think that is super critical to keep


in mind is I'm answering specific questions


from individual people here.


And they have very unique websites.


And it's sometimes not possible to just take one answer


and apply it to all of the web.


I think that's very tempting nowadays in that,


especially on Twitter, you have a short-form text.


And it's easy to say, oh, John said


you should get rid of all country versions


and only keep a UK website.


But that might apply to this one website.


But that doesn't apply to everyone.


And taking something simple like that will just


result in lots of discussions and then people saying,


oh, John is wrong, which maybe I am wrong.


But it's based on this one question here


and this one website.


And it's not something that you can generalize to everything


on the web.


So my recommendation here would always


be if this is something that you're relying on for business,


don't take just one person's comment on that.


But rather, use that as input to make your own decision.


And it might be that you decide to go that direction


that I mentioned.


It might be that you decide, well, I


don't care what Google says.


I think my other approach is better.


Or I have other consultants who are telling me


something different.


That's essentially up to you to decide.


And was that what you just said, true?


Or should we look that up as well?


Oh, man.


It goes endlessly.


It seems a little pointless asking the person


if they're telling the truth whether they're


telling the truth.


Yeah.


I see that sometimes on Twitter as well.


It's like, is this still true?


And it's like, of course it's true.


And then the next part is, well, Google says it's true.


Therefore, it must be wrong.


It's like, OK.


I don't know.


Can't do everything.


Let's see.


Maybe we'll take some more live questions.


Christian, what's on your mind?


Hi.


Good morning, John.


Can you hear me?


Yes.


OK, great.


Yeah, thanks for having us again.


My question today is about internal linking.


I found an interesting tweet from you


this week which says internal linking is


most important for website structure


and more than URL structure, if I got this right.


And my practical question would be,


does it make sense to look at the internal links


from important pages of a website to see if they have


links from other internal important pages


and to do some kind of link hygiene in the sense of removing


links to less important pages so that the links


to the important pages have more weight?


And does it make sense to calculate the internal page


rank, which is also possible?


I mean, it's something you can do.


It's a bit tricky because we try to be smart with how


we process internal links.


And especially some very common pages


that get a lot of links, like an About Us page or Terms


of Service, they're linked from across the whole website.


But at the same time, we understand


this is kind of a pattern that is normal.


And it doesn't mean that we should rank the Terms of Service


page for anyone who's searching for the company name.


So it's something where, on the one hand,


the internal linking is something that you can control.


But I wouldn't go overboard and say, well,


I will remove links to pages that I don't think are critical.


Because that's especially something that happened,


I think, when we introduced the nofollow, that people would


say, oh, my Terms of Service, all links


will be nofollow to it.


And that doesn't change anything.


It's a lot of work.


And you have to maintain it forever.


But it doesn't change anything for your website.


So it's kind of like wasted work.


But I would still recommend going through your website


and trying to create a kind of a graph of how things are linked.


And I think some, or probably most, SEO tools


have some capability for doing that, for crawling the website


and creating kind of this graph, where


you have different flowers and trees or whatever to show


the structure of the website.


And when you look at that, sometimes you


can tell at first glance, is there a clean structure


or is it completely messy?


And if it's completely messy, then I


think there is definitely room to clean that up


and to make it clear what the structure should be.


And by making a clear structure, you


are helping us to understand which pages you think


are more important.


So that's definitely something I would


try to find ways to clean up.


I mean, it's not that I'm saying your website will rank better


if you have a clean structure.


But it's more, if we understand your website should


rank in this range, which of these pages are the most


important ones?


And that's something that you're telling us.


And that's something that gives you value


in that you're sending people to the pages that you care about.


So that's certainly something I would look into doing.


I think that's a good use of time,


especially for larger websites that


have evolved over many years.


It just gets really messy organically over time.


And every now and then, it takes time and energy


to restructure things and make sure that everything


is well organized again.


And that is something that you will see effects from.


SPEAKER 2 OK, thanks.


And what about the internal page rank,


which is quite easy to calculate?


Would you recommend doing something


like that to see which pages do have the most important


or the most weight from internal links?


Or would you say this is something


that's not necessary?


JOHN MUELLER I don't know.


I do it for things that I play around with.


But I think it's something for people who


like to play with these things.


Sure, it's kind of interesting.


But the aspect that you can't really model in there


is that individual pages will get different external links.


And that essentially affects the internal page rank as well.


If everyone is linking to your terms of service page,


then it's suddenly it is something


that has a lot of page rank.


And page rank is something that we use in our systems,


but we use lots of other things.


So it's kind of an interesting, I don't know,


almost like a gadget from a technical point of view.


But I wouldn't see it as something


that is super critical from a practical point of view.


It's more like, oh, you'd like to mess with numbers


and play with graphs.


Sure, you can calculate this.


I wouldn't see it as something that


is reflected one-to-one at Google.


AUDIENCE OK, maybe it would make more sense


when calculating the internal page rank just


to ignore the external links and just focusing on all the links


that are within the website.


JOHN MUELLER I mean, sure.


I mean, you're kind of modeling things for yourself.


And you can decide how you want to model that.


And also, within the page rank functions,


I think there's a dampening factor and different other


things that you can mess with.


And you can play around with that


and kind of see what would that change


and do I see anything that kind of stands out


as something, an opportunity for my website.


But I wouldn't see it as this one magical tool that tells you


how to rank number one.


Yeah, OK.


Good, thank you.


Sure.


All right, and Gus.


Hi, good morning.


I have a question.


I run a site in the Netherlands.


And of course, in the Netherlands, we speak Dutch.


But we also use a lot of English terms, actually,


in our language and in our marketing terms


as well for this site.


So we have pages that contain Dutch and also contain English


and also sometimes in pieces like H1s or those kind


of elements on the page.


I was wondering, how does Google deal


with such a page that has two languages on it?


So not separated by the HREF lang.


But yeah, it's a Dutch website.


But how does Google deal with that?


Could it influence ranking?


Or would the region codes in the HREF lang


alone will be sufficient?


Or are there other things that we should look into?


So if you just have it in Dutch with some English terms


in there, then you wouldn't use HREF lang.


So that's kind of, I think, the one aspect.


Also, within the HTML, you have, I think, the language code


that you can specify.


That's something that we don't use.


I believe Bing uses it, though.


In practice, what happens with these kinds of pages


is we will try to understand the primary language of the page.


And we will understand that sometimes there


are words in different languages as well.


And we will still try to focus on the primary language


if we can determine one.


If we can't determine one primary language,


then we might use multiple languages


and assign that to the page.


And you can sometimes see that if you do something


like a site query for your website


and then go into the Advanced Search settings


and specify a language, then you can sometimes


see which language is being recognized for my website.


And if you try other languages, you


might see that, oh, it's being recognized


for Dutch and English, which doesn't mean that it


has less weight in Dutch.


It's just, well, we recognize that it's like a mix.


And from that point of view, it's


kind of something you can kind of double check there.


I think the one situation I would watch out


for is if your page is recognized


as being in a language that is not correct.


For example, if you have an English website on vacation


homes in Spain, and all the addresses are in Spanish,


and all the place names are in Spanish,


and we think the whole page is only in Spanish,


then it will be hard for us to rank that page if someone


is searching for vacation homes in Spain because we think,


oh, this is all in Spanish.


This is not English what this person is looking for.


Yeah, what I understand is if somebody,


because we have multiple language sites,


we also have an English site, and we also have a German site.


So we do use hreflang.


But we only have the region code, not the language code


on it.


But if somebody would then search for an English term,


which we do have pages for on the Dutch site, but in English,


Google sort of tries to find whether you can connect


that to that search term that says somebody,


and then on the Dutch pages.


We do not have to do something extra for it.


We can just use it like that.


Yeah, yeah.


Oh, perfect.


Yeah.


I think that should work.


Try it out.


Yeah, of course.


If it doesn't work, complain about it and let us know.


Because, I mean, that's the kind of thing that should just work.


And a lot of times, especially with technical vocabulary,


the terms might be in English, but the page


might be in a different language.


And it should still kind of work out there.


OK, cool.


Thanks.


Cool, OK.


Let me pause the recording here.


For those of you watching the YouTube recording,


thanks for watching until the end.


If you'd like to join us live, watch out for the link.


We post these in the community section of the channel.


And feel free to join in and come, I don't know,


join the office hours in person or at least


add your questions to the session


so that we can go through them.


Cool.


All right.


Google Search Console Training - Official Trailer (New Series)

Do you have a website and want it to be found on Google?


Do you want to bring relevant organic traffic to your website?


Do you care about your site's performance on Google Search?


Do I hear yes?


Well, you are in the right place.


The upcoming Search Console Training Series is here to help.


In this series, I'll guide you through everything you need to know


to get up and running with Google Search Console in no time,


from verification to reports and settings.


I'll discuss how to monitor your site's search traffic,


fix issues, and help users find your awesome website.


My name is Daniel Weisberg. I'm a search advocate at Google.


And I'll help you make your site shine in Google Search results


with the new Search Console Training Series


coming to the Google Webmasters YouTube channel soon.


English Google SEO office-hours from June 4, 2021

All right, welcome, everyone, to today's Google SEO Office


Hours Hangout.


My name is John Mueller.


I'm a search advocate on the search relations side.


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


where people can join in and ask their questions


around their website and web search.


Wow, lots of people still joining.


Cool.


It looks like we have a bunch of people already raising


their hands, which is great.


So we can go through some of you all.


There are also a bunch of questions submitted on YouTube.


If you want, you can add more questions to YouTube.


Or if you're in here live, feel free to raise your hand


as well.


And we'll see how far we can make it today.


All right, first on my list is Diana.


Hi, John.


Hi.


So I wanted to ask, is it really important for Googlebot


to be able to see a cookie consent message that we serve


to users?


Because we kind of decided to serve it


upon user interaction, so Googlebot


won't be able to see it.


I wonder if that can cause us any problems in terms


of Google friendliness.


In general, that should be fine, because Googlebot doesn't really


need to see a cookie banner.


Googlebot also doesn't keep cookies,


so it wouldn't accept cookies anyway


if you gave it to Googlebot.


So if you have it set up like that, I think that's fine.


Lots of sites serve the cookie consent banner to Googlebot


as well, just because they serve it to everyone.


That's usually also fine.


The important part is essentially


that Googlebot is not blocked from being crawled,


or blocked from crawling the website,


so that you don't have a kind of an interstitial


that blocks the access to the rest of the content.


Yeah, yeah.


Understood.


Thank you.


Sure.


I'm doing the same.


All right, let me see.


Michael.


Hi, John.


I have a softball question, but it's something


that I'm running into right now.


Going back to basics.


So I have a directive to use keywords, specifically


target keywords in meta tags, use it here in the H1,


use it this many times in a piece of content.


And that really just seems outdated to me, especially


with all the advances in semantic search,


and all the cool mum, and all that other stuff that's


coming down the pipe.


I just wanted a basic question.


Do you think that that's still a legitimate SEO tactic?


Or should we not be focused on using this particular keyword


this many times on a page?


In general, the number of times that you


use a keyword on a page, I don't think that really matters,


or makes sense.


When you're writing naturally, usually that


resolves itself automatically.


And also with regards to the individual keywords,


I think that's something where I wouldn't disregard it


completely, but at the same time,


I wouldn't over focus on exact keywords.


So in particular, things like singular and plural,


or kind of like the different ways


of writing individual words, that's


something that you probably don't need to worry about.


But mentioning what your site is about,


and kind of like what you want to be found for,


that's something I would still do.


So in particular, what we sometimes


see when we look at things like news articles,


if a news site doesn't really understand SEO,


they might write in a way that is more, I don't know,


almost like literature, in that you read it,


and you kind of understand what it means,


but the exact words that are used on a page


don't really map to exactly that topic.


So that's something where, from an SEO point of view,


if there's something you want to rank for,


I would still mention that on a page.


I wouldn't go overboard with a number of mentions.


I wouldn't go overboard with all of the synonyms


and different ways of writing it.


But mentioning it at least once definitely makes sense.


OK, thank you.


Espen.


Hi, John.


So I have a question regarding the URL removal tool.


So my question is, if you use that tool,


does it only affect the canonical version of the URL


since I guess this is affecting the index you're using


for publishing search results?


So does it only affect the canonical version,


or does it affect the entire duplicate content cluster,


which this canonical is a part of?


So for instance, if I write in a URL, which in my opinion


is the one to be excluded, but it's basically


a canonical variant, sorry, a non-canonical variant,


what happens in that situation?


OK, good question.


So we don't consider the canonical at all


when it comes to URL removals.


But rather, we match it one to one exactly as you submitted it.


And we include the HTTP, HTTPS, and www, non-www versions


of that URL.


And essentially what happens is we don't remove it


from our index.


So the whole indexing side stays the same.


The crawling side stays the same.


We just don't show it in the search results.


So essentially, you would submit the URL


that you see in the search results,


and then we would just hide that from the search results.


Thanks.


Cool.


Let's see, Jameson.


My question relates to templated content above the fold


from a mobile-first perspective.


And this relates to a blog restructuring


we're working on, where we're moving from all of our blog


articles living in a blog subdirectory


to building out topic clusters with specific topic landing


pages.


And based on initial designs of the topic landing pages,


they're all going to include the same hero banner


with the same header and then the same two sentences.


And then below that will be a sub-navigation


to let the user navigate to a specific topic landing page.


And my concern is, from that mobile viewport,


each of these topic landing pages, they're unique URLs,


unique titles, but they have that same header and just


above the fold content.


But right below that is a unique subheader,


which would be the H1 tag of the page.


So I just want to get your thoughts there.


I know Google, in the past, has said that they


weigh above the fold content.


And I think it's something important for us to look at.


But is it detrimental to non-brand rankings


for those topic landing pages?


Now, so the important part for us is really that there


is some amount of unique content in the above the fold area.


So if you have a banner on top and you have generic hero image


on top, that's totally fine.


But some of the above the fold content


should be unique for that page.


And that could be something like a heading that's


visible in a minimum case.


But at least some of the above the fold content


should be there.


So that's kind of the guidance that we have in that regard.


OK, cool.


Thanks.


Maybe I'll just leave the head of the segment


and change a sentence or something based on the topic.


Yeah, I mean, it's probably also something


where you want to look at how users interact


with those pages afterwards.


But that's kind of more from a non-SEO perspective.


But it's always, I think, important for cases like that


that you take a look and see what actually happens


with the users afterwards.


Awesome.


Thank you so much.


Sure.


Promotash.


Hi, John.


Hi.


Doing good?


Pretty good.


Yeah.


John, I have a question regarding the domain age.


And does the domain expiry matter?


Suppose I have a domain that is a couple of years old.


And it will expire in the next six months.


So does the SEO check the age of the domain?


No.


I don't think we use that at all.


OK.


So I have one more question on the domain only.


So do you check the who is private or public?


I don't think so.


At least not that I know of.


Because it's also something where some of the top level


domains and the registrars, they just


have everything private by default.


So it's like you wouldn't be able to compare that anyway


or use that for anything useful.


So John, so like I am a little bit worried right now.


So what happens is like now both of us


are talking in front so we can clear out things.


So there is a lot of crap means wrong information


and data spread widely across internet.


It is copied.


And the content length keeps on increasing.


Let's suppose one SEO expert in 300 words on on-page SEO


says 10 top points that you should do.


The next SEO experts come.


He writes 20 points.


And the content length increases to 100,000 words.


Then the next expert comes.


There are only five, six people.


If you search on Google, they will come on.


They are the main culprits who are spreading


all the wrong information.


Then the next one comes.


He writes 2,000 content.


And he lists 20 points.


And another person comes.


He writes 200 Google Algo points.


And he has 4,500 words.


And he claims also like I have been increasing my word count.


And Google has increased my rank from number three to number one.


So it is not directly my question.


But how the people are using the skyscraper technique


to building a bigger building than suppose another tower.


Next person is writing again crap.


There is no useful information.


His building is more bigger than another is more bigger.


And they are like, if I want to see real information,


then the actual gurus are also spreading misinformation.


But still they are competing around the five,


six gurus are competing.


And many people are taking their courses and on and on.


So SEO, suppose I want to write something truth.


We are discussing.


I am writing.


And in whatever we discuss, in 200 or 300 or 500 words,


I write the real answers.


So I think maybe with new Google algorithms,


this is my suggestion.


So Google tried to read also the content,


like the meaning of the content.


If the meaning of the content is something like domain expiry,


does not matter.


But they explicitly like maybe they're


an affiliate that your domain should expire three years.


Keep on renewing so that the expiry is longer.


So Google checks if a genuine website


will have longer expiry.


So they will have an affiliate link below.


So they want to sell the psychology I'm telling.


But this is the wrong information.


This is my concern only to share with Google.


You can advocate on it.


Yeah.


Yeah, I think it's always tricky.


And there is also the aspect of sometimes there's


just old and outdated information out there


on specific topics.


But yeah, I don't know.


People like to write a lot of things


and to promote the things that they've been working on.


So it's hard for me to say.


Why still the skyscrapers technique seem to work?


They showcased the example.


Like three months ago, I was using 500 piece of content


with 500 words.


And suppose on page SEO, they will give an example.


And I'm taking one example, on page SEO, I have 500 words.


And I used to rank at number six.


Then I increased to 1,000 words.


I moved to number five.


Then as it slowly increases, he naturally


climbs the ladder up to number one.


I don't think there's really a correlation there.


I think sometimes these things happen


that you rank higher when you make changes,


when you improve things.


But just purely from increasing the number of words on a page,


that's absolutely not something that we take into account.


Just to finish, I'm like quality metric.


So in the next elbow, will the page experience


see the number of DOM?


Suppose you write an article with 2,000 words,


very good, relevant.


I write again with 3,000 words.


So my DOM will increase DOM size.


It depends.


It depends, because I think the time that it takes to load


a page is partially related to the amount of HTML


that you send.


But there are also a lot of other factors.


So in particular, things like images on a page,


the way that you use CSS and JavaScript on a page,


those can have a very strong effect


on how quickly a page loads.


It's really not purely the HTML that is on a page.


AUDIENCE 1 OK.


Thank you.


JOHN MUELLER 1 Sure.


Prakyan Shoo.


Oh my gosh.


I probably have your name wrong.


Sorry.


AUDIENCE 2 Hi, John.


Thank you so much.


Yes, you pronounced it absolutely correctly.


It is difficult, though.


Hope you're doing well.


My question is related to Google Search Console.


And it has more to do with the sampling of data.


So what I'm stuck with and I'm confused with,


so in the main property of Search Console,


if I create a subproperty, so what


I see that the subproperty's numbers, the clicks,


if I take from the main property,


it is only 4,000 clicks.


But when I create a subproperty, I


see 40,000 clicks for that particular subfolder.


So when I'm seeing, analyzing the numbers


at the main property level, I might skip out


that portion of that subfolder because I see only 4,000


clicks and maybe the rest of the site sections


are doing great and all.


But when I create a subproperty, it


gives me a huge number, which is a 10 times difference.


So then what I did eventually that I created many sub


properties inside Google Search Console


to get more numbers, which gives me a better picture that, OK,


this subfolder is doing great.


It's actually not only 4,000 or 2,000.


It's actually 20,000, 30,000, like that.


So what should I do?


So should I continue pulling numbers from subproperties?


Or should I go to the main property


and consider the numbers from there?


Because if I add up all the subproperties,


the total goes beyond the numbers which


I see at the main property.


Yeah.


I think it depends on the size of your site and the way


that the traffic comes to your site


because there is a limit of the number of data points


that we collect per site per day.


And perhaps that's what you're seeing there.


So from my point of view, if you're


seeing more useful numbers or more actionable numbers


that way, I think that's totally fine.


I don't know if that's something that the average site needs


to do.


My guess is most sites don't need to do it.


But maybe it makes sense for your site.


Yeah, but the only thing is the concerning part


is that if I continue pulling the numbers


from the subproperty, that's fine.


But when I look at the main property,


so if I have to look at the overall numbers,


then it gets a little confusing because the subproperties are


speaking a different story.


And the main property, the total overall website numbers


are saying a different thing.


Yeah.


I mean, you're looking at a different database there.


So from that point of view, comparing


those different subproperties, that


probably doesn't make sense.


But if you need to look at more detailed information


within one of those subsections of your website,


then maybe that does make sense to look at it on that level.


OK, so you would recommend that it's case to case?


OK.


I mean, I think for most sites, we


chose those numbers to make sure that for most sites,


the data was sufficient and useful


and that the totals kind of line up.


But there are definitely individual cases


where it makes sense to dig more into detail


and kind of verify subsections of a site.


And a very short question.


Would we see anything in future, like premium version


of Google Search Console, where we can pay and get more data?


I have no idea.


Yeah.


I mean, it's something where we tend


not to talk about what is lined up for the future.


I don't know.


It feels weird to have a premium version of Search Console


for something like that.


But who knows?


I think seeing what people are doing with Search Console


and seeing where they're running into limitations,


that's always useful for us.


Thank you so much, John.


Thank you.


Sumit.


Hi, John.


How are you?


Hi.


OK.


So my question is, for Core Web Vitals, me and my team


have been preparing and making optimization,


whether it's theme-related in CSS.


So what we have witnessed is the data in the Google Search


Console, it's completely different to when


we go to the incognito mode of the website


and go to Inspect and go to Lighthouse


and generate a report from there.


So over there, I can see 91 performance,


and everything is good, large, just content for pain,


time to interact if everything is green.


However, if I go to Google Search Console,


I can see 100 poor URLs.


So we are in a mid-of-situation where we don't


know where to go from here.


So if you could help in that.


OK.


So I think the important part is these are different ways


of looking at the data.


And so we differentiate between the lab data, which


is kind of like if you test it directly, which


is what you would see in PageSpeed Insights


or in Lighthouse when you look at it


in incognito in your browser.


And the other variation of the data


is the field data, which is what users actually see


when they go to your website.


And that's the data that's shown in Search Console.


And from there, the differences are essentially


that the lab tests that you do, they


make a lot of assumptions with regards to probably users


will have this kind of device or this kind of connectivity


or have this kind of configuration.


And they will try to use those assumptions to figure out


what it might be.


But what they actually see in practice


could be very different.


And that's probably what you're seeing there.


SPEAKER 2


Yes.


So in search, we use the field data from real users.


There's one tricky thing with the field data


in that it takes 28 days to update in Search


Console for various reasons.


What you can do is use something like Google Analytics,


together with an extra script on your site,


to track the field data yourself as well.


So then you would have the lab data, your own field data,


and the search field data.


And usually, you would see the differences between the lab


and the other field data.


SPEAKER 3


So our aim should be optimizing for the field data?


All right.


Thank you.


SPEAKER 2


Sure.


Let's see.


Hi, Shing.


SPEAKER 4


Hello, John.


I had a question about, yeah, I know Google I


but that's essentially what happens,


when you use Google Analytics A-B testing, for example,


because it switches the content underneath you


when it does the A-B testing.


So anything that it's optimized for SEO cannot use Google


Analytics A-B testing.


Is that right?


Yes, kind of.


So the important part for us with A-B testing


is that the A-B testing is not a permanent situation


and that the A-B testing is something


where Googlebot essentially also falls into that A-B test.


And essentially, we can kind of see what users are seeing.


And when it comes to A-B tests, the important part


for us is also that the purpose of the page remains equivalent.


So if you're A-B testing a landing page


and you're selling one product, then it


shouldn't be that instead of selling a car,


suddenly you're selling a vacation or a flight


or something like that.


It should be something where the purpose of the page


is the same so that if we understand


this is a page that has a car for sale, for example,


then we can send users there.


And if the page looks slightly different when users go there,


that happens.


Sometimes you personalize.


Sometimes you do A-B testing.


All of that is essentially fine.


So the A-B testing that you would do with Analytics


usually is in that area where you say, oh, I


am changing my call to action.


I'm changing the colors, the layout slightly.


But you're not changing the purpose of the page.


Yeah, totally.


We are not changing the purpose of the page.


But we do plan to run some UX enhancements


through the experiment.


But it's kind of risky, no?


No, it shouldn't be.


It shouldn't be.


So especially if the purpose of the page remains the same,


then that's something where even if Googlebot


were to see both of the A-B versions,


then we would be able to index the page normally.


It wouldn't change anything.


So that's perfectly fine.


The cloaking side that is more problematic


is if, I don't know, you're selling a car,


and then when Googlebot looks at it, it's showing a car.


When a user looks at it, it's going to a pharmacy.


Then that's usually kind of the more spammy cloaking


that we worry about, where the web spam team would get


involved.


And all of these subtle changes, also,


if you have device-specific changes on a page,


that's perfectly fine for us.


Maybe for mobile, we use AdSense, for example.


Then the ranking should come back.


Um, I don't know.


My assumption is the ranking would not


change with normal A-B testing, because you


have the same content.


Essentially, the purpose of the page remains the same.


If you were to significantly change the page,


like remove all of the textual content in the B version,


and Googlebot sees that version, then that's


something where the ranking might change.


But for the normal A-B testing, I


don't see that as being problematic.


And if the ranking did drop, then I


would, as a first assumption, assume


that it's not related to the A-B testing,


but rather maybe related to something else.


Got it.


So ranking will not have any fluctuation, you would say?


I mean, there are always fluctuations in ranking,


but it shouldn't be just because of the A-B testing.


Cool.


Navin.


Hi, John.


Hi.


My question is, we are a WordPress site,


so we have a blog section.


We have also a services section.


Our services sections are labeled as pages on the WordPress


backend, whereas our blog sections are labeled as posts.


Our services section gets a lot of traffic,


but our blog section does not get


a comparable number of traffic.


So is it because Google treats pages more favorably


than blogs, or maybe we are missing out on other fronts,


like blog marketing?


I don't think Googlebot would recognize


that there's a difference.


So usually, that difference between kind of posts and pages


is something that is more within your backend,


within the kind of the CMS that you're using,


within WordPress in that case.


And it wouldn't be something that would be visible to us.


So we would look at these as it's an HTML page,


and there's lots of content here,


and it's linked within your website in this way.


And based on that, we would rank this HTML page.


We would not say, oh, it's a blog post, or it's a page,


or it's an informational article.


We would essentially say it's an HTML page,


and there's this content here, and it's


interlinked within your website in this specific way.


So my other question is, what is happening


is that the blog section has a longer URL, the root


URL slash blog slash category slash the article name.


So is it because the URL is longer


and it is getting harder to rank the blog?


It shouldn't be, no.


I think, I mean, I don't know your website,


so it's hard to say.


But what might be happening is that the internal linking


of your website is different for the blog section


as for the services section or the other part of your website.


And if the internal linking is very different,


then it's possible that we would not


be able to understand that this is an important part


of the website.


But it's not tied to the URLs.


It's not tied to the type of page.


It's really kind of like we don't understand how important


this part of the website is.


OK, so how important is the length of the blog?


We are following the guideline of 300-plus words.


And recently, I've read in many places


that Google favors long-form content.


So maybe are we missing on that front?


We are writing shorter blogs?


We don't use the word count at all.


So the number of words in your articles,


that's totally up to you.


I think some people like to have a guideline with regards


to the number of words.


But that's really an internal guideline


for you, for your authors.


It's not something that we would use for SEO purposes.


Yes, thank you, John.


Sure.


Let's see.


Tomas.


Hi, John.


Hi.


So I have a question about Google Search Console.


My website has around 120 external links.


And about 40% of them are non-working Japanese domains.


I have no idea where they came from


and what do I have to do with them.


So yeah.


I probably don't need to do anything with them.


If these are just random links from the internet,


I would just ignore them.


Sometimes, it's not specific to Japanese links,


but sometimes spammers include normal URLs


within the URLs that they use to promote spam.


And that means on random forums and blogs,


they will drop these URLs as well.


And sometimes that ends up with, I don't know,


a lot of links that are posted in non-English


or in foreign language content.


And I've seen that a lot with Japanese, Chinese, Arabic,


all kinds of languages.


OK.


And the almost 50% count doesn't matter.


I shouldn't be worried that I get some kind of penalty


for that.


Yeah.


No, I mean, if these are not links that you placed,


things that you bought where you put these links there,


then I would just ignore them.


What if my competition was the one buying those links for me?


I wouldn't worry about it.


You wouldn't worry.


No.


I mean, those are the kind of links that I mean,


on the one hand, if they don't exist anymore,


then we will ignore them over time anyway.


So that doesn't matter if you disavow them or not.


If they don't exist, they don't have any value.


And on the other hand, these are the kind of links


that we see so often since, I don't know, 10, 20 years.


And we just ignore them.


But why do you show them in Google Search Console?


Just because we want to show you everything that we know about.


So yeah, I agree.


In a case like this, it's like, oh,


if Google knows these are stupid links,


then maybe they shouldn't show them.


But in Search Console, we try not


to make a judgment with regards to the links.


And we also include things that are nofollow and all of that.


So it's like we show them to you.


But if you look at them and say, oh, these don't matter for me,


then you can just ignore them.


SPEAKER 2 OK.


Thank you very much.


JOHN MUELLER Sure.


All right.


Let me run through some of the submitted questions.


And then I'll get back to all of the hands that are still


raised.


Wow, so many people.


Let's see.


Maybe I'll see how I can go through these


a little bit faster.


And I have a bit more time afterwards as well.


Let's say I have 500 physical shops that


are selling my products.


And I want to create for each of them a specific landing page.


Would this be considered doorway pages?


No.


That would be essentially fine.


It'd be kind of like having different products.


Because these are unique locations.


These are physical locations.


Having individual pages for them is perfectly fine.


Sometimes it might make sense to combine these and put them


on a shared page, such as if you have


a lot of shops in specific countries.


Maybe just list the shops there instead


of individual pages per shop.


But that's totally up to you.


Then second, from a ranking point of view,


does Google treat nofollow, UGC, and sponsored rel


attributes any differently?


We do try to understand these and try


to treat them appropriately.


So I could imagine in our systems


that we might learn over time to treat them slightly


differently.


But in general, they're all with the same theme


in that you're telling us these are links that I'm placing


because of this reason.


And Google doesn't need to take them into account.


Let's see.


The WordPress site we looked at briefly.


How might a poor site structure affect indexing?


Some of my older articles are getting de-indexed.


But these were articles on page 8 to 9 of our blog.


I've since created static category pages


that make it easier for Google to keep track


and to find these pages.


But what could be the indexing issues here?


It's certainly the case that we don't index all content


of all websites on the web.


So at some point, it can happen that we say,


oh, these pages are not critical for the web.


Maybe we're not showing them in the search results.


Maybe just generally we don't think


these are critical for the web.


So maybe we will drop them from our index


so that we can focus more strongly


on the important pages within your website.


And that's something where we use the internal site structure


quite a bit to try to figure that out,


in that if we understand that your site is important


and we see within your website that you're telling us


this part of my website is important for you,


then we will try to focus on that.


Whereas if you're saying these pages are also on my website


and they're linked, like you mentioned here,


like 8 to 9 pages away from essentially your home page,


then we might say, well, you don't think these are important.


So maybe we won't focus so much on them.


We'll focus on the other ones.


So that's something where your internal site structure


can help us a little bit to understand that.


But it's definitely also the case


that we just don't index everything on all websites.


How much of an impact disavowing links in bulk


is going to make?


We recently disavowed many backlinks on our site.


They were all HTTP sites with low domain authority.


Many of them were comments with link back to our site.


However, we haven't seen any positive improvement.


There are currently no manual actions against us.


Is disavowing not necessary these days?


Probably you could save yourself the effort


of disavowing those links.


So probably they wouldn't have any effect at all.


I would mostly use a disavow links tool, really,


for cases where you either have a manual action


or where you look at what you've done in the past


and you realize, probably I will get a manual action if anyone


from Google sees this.


And in those cases, I would go off and try to disavow that


and try to clean that up.


But just generally, links from low domain authority sites


or links that essentially are part of the web


since years and years, I would not disavow those.


I don't think that makes any difference at all.


Let's see.


Could you do some questions around the sources


behind Google News?


So I don't really have much insight


into the Google News side.


So if you have questions about Google News,


I'd recommend going to the News Publisher Forum


and posting there.


So I don't really have much insights


on the labeling and how things have to be set up for that.


Subproperties, we talked about briefly.


Does Googlebot still heed pagination and breadcrumbs,


or does it affect the ranking?


What's the best practice?


We use pagination and breadcrumbs


as a way of understanding the site's internal structure


a little bit better.


So that's something that definitely still plays


a role with regards to crawling and indexing a site.


So if you have pagination and breadcrumbs on your site


and you remove that, then that does


mean that the internal structure of the site is now different.


A good way to double check how those factors play


a role within your website is to use an external crawler,


some kind of a tool that you can run across your website


to crawl the website the way that it is now.


And then you could analyze from there,


are these breadcrumb links the reason why these pages are


being crawled or not?


And then based on that, you can make decisions


on whether or not to remove them or to change them


or however you want to modify things within your website.


Question on 301 redirect.


In a scenario where a group of URLs have been changed,


but for some reason, the 301 redirects


have not been set up right away, roughly how long is the time


frame that you have to implement redirects to transfer


the ranking authority from the old to the new pages


and prevent ranking drops?


So it's tricky because there is no specific time for this,


especially because there are different variations


of this kind of problem situation that you have here.


In particular, if the old content still exists


and you've created a copy of that on a new URL,


then in a case like that, we will treat those two URLs


as being a part of a same cluster,


and we'll try to pick a canonical URL


between those two URLs.


And it can happen that we switch over to your new URL for that.


And if that's the case, then essentially we


will forward all of the signals from the old URL


to the new URL automatically, even without a redirect


in place.


So in that scenario, probably you


will not see a big difference if at some point


later on you add a redirect.


The main difference you would see


is that it would be a lot clearer for us


that you want the new URLs to be indexed and not the old URLs.


So in that setup, probably you wouldn't see a ranking change,


but probably you would see that we would switch over


to the new URLs a little bit more consistently.


In a situation where you delete the old URLs


and just add the same content somewhere else on your website,


then that's something where we would essentially,


in a first step, lose all of the information


we would have about this page because suddenly it's a 404.


And we would treat the new page as being something new,


and we would essentially say, well, there's a new page here.


And we would not have any connection


between the old page and the new page.


And that's something where at some point


we will drop the old page from our index


and lose all of those signals.


And if you wait too long and add a redirect much later,


then those signals are already gone.


And that redirect is not going to forward anything anymore.


So in that situation where if you delete things and just move


it somewhere else, then probably after a certain period


of time, I don't know how long that would be,


depends on the website, you would not


see any improvement from adding redirects.


And in a case like that, it would, from my point of view,


still make sense to start adding redirects there just


so that you're sure that if there is any small value still


associated with those old URLs, then at least that


is still forwarded over.


So those are the main scenarios there.


Can you tell us something about the new Lighthouse tree map?


I haven't actually taken a look at the Lighthouse tree map.


And probably for questions around Lighthouse,


it would make more sense to check in with the folks


from the Chrome side and kind of pick their brains on that,


on what you should be focusing on there.


I saw some screenshots, and they look pretty cool.


But it's like all of these speed-related topics,


they can get pretty complicated.


Some insight into the optimization of free listings


on Google Shopping.


If we manually edit the description and title


to match keywords that we're interested in in positioning


our listings for, will we be penalized if these keywords do


not appear on our site?


For example, edit the free listing


to include the word low cost or cheap


in the description of a product like a gold-plated ring


where the words are not referenced on the reference


domain for that listing.


I don't know.


My feeling or my understanding is


we do try to map the landing page with the products


that you have in your Merchant Center feed.


And if they don't align, then we will


have to make a call with regards to which of these versions


do we actually use.


So that's something where I would generally


recommend trying to make sure that these two versions align


as much as possible so that you don't give Google


this situation where you're saying this data doesn't really


match.


Which version should we take into account,


or should we ignore half of your data completely?


Essentially, if you can give the data in a clear way such


that Google can actually take that into account immediately,


then usually that's a lot better in the long run than kind


of just short-term, like tweaking individual keywords


where you probably don't see much value out of that anyway.


Question about two different anchor texts to a unique URL.


Which anchor link does Google value?


Does Google value the size of the anchor text


or size that the anchor text takes up on the screen?


I don't think we have that defined at all.


So those are the kind of things where from our systems,


it can happen that we pick one of these


and we try to understand which one is the most relevant one.


But I wouldn't kind of make the assumption


that we just naively take the first one on a page


and just only use that or only take


the one that has the longest anchor text


and ignore the other ones.


We essentially try to understand the site structure the way


that a user might understand it and take that into account.


And the way that kind of this ambiguous situation


is handled, that can also vary over time.


A question regarding AMP.


We're a news site and we're thinking about implementing


AMP, but Google announced that AMP is not


necessary to rank in the top stories carousel


and the AMP badge will be removed.


So my understanding is that we need


to focus on Core Web Vitals and fine-tune our website


to make it fast and create high-quality content.


Can you give us some more information on getting


into top stories carousel?


So yes, we did announce that AMP is no longer required


for the top stories carousel.


And instead, we will be focusing on things like the Core Web


Vitals and the page experience factors


to try to understand which pages we should be showing there.


I think the important part with AMP


is that it's a really easy way to make pages extremely fast


and to kind of make sure that you're kind of in an easy way


almost by default achieving the metrics for the Core Web


Vitals.


So that's something where if you're


trying to make your pages fast and you


don't know which framework to use,


then maybe AMP is a good approach there.


Maybe that's also something where


you can take individual elements out of AMP


and just reuse those on your pages and then over time


kind of migrate more of your pages to the AMP framework.


But I would see it more as a framework


rather than a kind of a feature that you


have to turn on or turn off.


So with that in mind, there are other ways


you can make your pages really fast.


You don't have to use AMP, but sometimes using AMP


is an easy way to do that, especially


if you have something like WordPress,


if your site is built on WordPress


and you can just enable the AMP plugin,


then sometimes that can kind of automatically shift


your site over into the good side of the Core Web Vitals.


OK, we're kind of running towards the end.


So maybe I'll shift back to some live questions from you all.


And like I mentioned, I have a bit more time afterwards


as well if any of you want to stick around and ask


even more questions.


Let's see.


Neeraj, I think you're on top now.


Yeah, John, so actually I was talking to some other SEO


friends at the meeting, and he has the problem.


He was saying, so this kind of websites


are there are so many websites like this.


So this is related to job.


And in job, what happens is that one website


has the structure where in India it just shows one generic page,


asks the user to give forcefully, in fact, his city,


and then redirects that particular user


to that respective city jobs.


So he was just trying to discuss about whether this will


be cloaking or not for Google, because to Google, they


had the structure that in USA, they


will be serving the page as it is,


no force fully as city selection.


So from my understanding, as I know,


it works for different country-specific domains.


We can redirect user to respective countries.


And for Google, we are allowing crawling.


So I was just thinking that this can also not


be cloaking from Google's side.


If we are providing one page to Google,


but in users in the same country,


we are just asking for the city and redirecting


into that respective city.


Please just give me your ideas on this.


Yeah.


So the important part for cloaking in a case like this


is that Googlebot sees the same content as other users


from the same country where Googlebot


is crawling from would see.


And most websites would crawl from the US.


So if a user in the US were to access this website,


they should see the same thing as Googlebot would see.


So that's kind of the general assumption.


And the extra situation, like in your case,


where maybe in India or in some other country,


they're doing something slightly different to personalize


the experience for users in that region, from our point of view,


that's perfectly fine.


So it's really just a matter that Googlebot


sees the content that other users would see in the US.


And if you're doing something more unique in a country


where Googlebot is currently not crawling from,


that's perfectly fine and up to you.


The important part here is, I think, also


to keep in mind that Googlebot will be crawling from the US.


So if, for example, you have different jobs


in different countries, and when a user from the US


comes to your website, they only see the listings for the US,


but most of your users are based in India,


then we will index your home page, at least,


as looking like a jobs website for the US.


So if someone is looking for a job in San Francisco,


then we would say, oh, yeah, here's one on this website.


But if someone is looking for a job in Mumbai


or some other place in India, then we


might not necessarily know that the home page of this website


would be relevant, because we never see jobs from India


listed on the home page.


On the lower level pages of the site,


usually there's less personalization there.


But especially with the home page,


that's one area that you kind of need


to watch out for if you're doing a lot of personalization.


My recommendation there would be to say


you have one part of the home page that is very personalized,


that it kind of matches where the user's location is,


and another part of the home page


is essentially very static, something that all users would


see.


And then you can kind of guide Google to index the home page


and say, there is some US jobs information here,


but there's also some worldwide jobs information here,


and the home page is kind of relevant for all of that.


John, regarding this cloaking, I was also going to Google


Documents.


I have.


So what I would recommend doing in a case like this


is trying to find the most related page


within our documentation and using the feedback link there


to let us know that it would be useful to have more


examples or more details there.


But I can also pass that on to the team.


But the feedback link is kind of the best way


to get the information directly to the team.


Yeah, sure, I will do it, and my only concern


was that let us share it with you too.


I will also do that one.


And the dos and don'ts will always be welcome.


Please do this, please don't do this.


So at least no need to getting confused and then coming


and asking you the same question.


Well, I don't know.


People are always confused.


I think that's always fine.


OK, thank you, John.


Sure.


Let's see, Michael.


Michael, I think you're on mute.


Can you hear me now?


Sorry about that.


Yes.


OK, sorry about that.


So in a previous question about keywords,


you mentioned how it's important that the writing is good,


that people use plurals correctly.


And it made me think about a headline


I saw a few days ago from a major outlet that


read, so-and-so announces they're engaged to so-and-so.


So I read it, and I said, good for that outlet


for correctly referring to that particular non-binary


individual as they.


And then, of course, my mind immediately went to SEO


and wondered whether Google understands


that this isn't poor grammar, but rather inclusive English.


Is Google's natural language processes,


does it understand a plural followed


by a singular form of verb, like they is doing this


or they is doing that?


That's grammatically correct.


I don't know.


Probably.


I mean, usually, I mean, it's something where usually


our systems would learn this automatically.


We would not manually define English grammar


to be like this.


And I could imagine that, especially these kind


of shifts in language where over the years,


this becomes more and more common,


that's something that probably takes a bit more time


for our systems to learn automatically.


And probably, if we were to run into situations


where we obviously get it wrong and we see feedback about that,


then I could imagine that our researchers would say, oh,


it was like, on the web overall, this is kind of rare still,


but it's important.


So we will try to tune our models to also deal


with that properly.


AUDIENCE 1 Yeah, I was wondering whether that


was affecting actually the way that that particular story


ranked because it was a subject about one person.


Other people just used the person's first and last name


to sort of get around it.


Yeah, I don't think that would be affecting the ranking there


because it's like we would probably be picking up,


like if we're taking that headline apart,


we would pick up the two individuals.


And we would focus on like, oh, these two are now related


or kind of mentioned in the same headline kind of thing.


But kind of like the individual words,


they're probably less critical for us.


Thank you.


Sure.


Ritu, I think you're also on mute if you're speaking.


Ritu.


OK, otherwise we'll get back to you.


Let's see.


Giacomo.


Hi, John.


Hi.


So a question about links, but not ranking related.


Don't worry.


The scenario is Googlebot crawls a page and gets links.


Those links are pointing to someone else on the internet


or internally.


So the question is, is there a span of time


after which not crawling a specific page,


you delete the links contained in that page,


let's say from the link graph, or you


keep those links till Googlebot crawls again that page?


And just to clarify, I mean the links


that are contained on the page and not the links that


are pointing to the page.


OK, so kind of like if we would ignore the link


if we haven't recrawled the page in a period of time?


Yeah, yeah.


If you crawl a page, for example, a year ago,


and after one year, you stop using the links on that page


because you didn't crawl the page again.


That's that.


Yeah, I don't think so.


I think we would continue to use those links.


What would probably happen is the rest of the web


and kind of that website would evolve over time.


And it could happen that those links are less relevant


after some period of time.


But we would still keep them.


So for example, if you have a link in an article on The New


York Times and it's currently an article on the home page,


then that link might be seen as very relevant for us.


But five years later, that link is within an archive section


of The New York Times and somewhere hidden away


in the cellar.


Then that link would still be there,


but it's a lot less relevant within the context of The New


York Times.


So those are kind of the changes that tend to happen.


But it's not that we would say, oh, we


haven't looked at this link in five years.


Therefore, we will ignore it.


Perfect.


Thank you very much.


Sure.


OK, let me take a break here for the recording.


And you're all welcome to stick around a little bit longer


and we can answer more questions as well.


But just so that we have a reasonably sized recording,


thank you all for joining in.


Thanks to, it's cool to see so many of you here.


Wow.


And thanks for all of these questions that you submitted.


And hopefully, if you're watching this on YouTube,


you're definitely welcome to join us in person at some point


in the future as well.


I try to do these on a weekly basis, alternating


between early my time and later my time


to try to get more time zones involved.


But you're always welcome to join in.


So with that, let me pause the recording


JavaScript SEO Office Hours April 7th, 2021

Yeah.


Come on.


Do the thing.


That takes longer than usual.


Or is that a new way of showing me that?


Hello, and welcome to the JavaScript SEO office hours


on April 7th with this lockdown.


I can't tell, but from the weather,


it's clearly April here in Zurich.


We have seen sunshine, rain, and snow in a single day


at this point, also some wind.


So yes, we definitely, I think it's April 7th.


Yes, it's April 7th.


This time it's the right date.


Yeah, we do these biweekly, roughly,


where you can basically have a post on our community


tap in the youtube.com Google Search Central channel.


You can ask your questions there in the thread,


or you can join these live recordings


as these wonderful people around me here have done today.


We do not have YouTube questions this time around,


so I'll open the floor to questions from the audience.


Feel free to either unmute yourself, raise your hand


if someone else is speaking, or use the chat


if you don't want to talk out loud today.


Do we have any questions?


Silence.


OK, so I'll go first.


Yes.


Hi, Giacomo.


Hi, Martin.


So the first question, I don't know,


is in the last JavaScript SEO meeting,


you say that Chrome is improving, and blah, blah, blah.


All the system is improving, and so you


are getting less JavaScript error than before


in the rendering inside WRS.


So can you give us, I don't know if you can now,


you can later on tweet, a list of the most common errors


in WRS?


The first one you say is like a result is blocked by Robot XT


or not reachable.


I don't know if there are other issues that are very common,


so we can just evaluate some things to.


Oh, that's a fantastic question, Giacomo.


I should, but I can't, because the thing is


we have a bunch of data.


We basically have the logs that we get from each website


in the WRS, so the JavaScript console logs,


like whatever you would see in the JavaScript console,


we also get that.


We highlight that in Search Console


if you run a live test.


We have this information.


I have not had the time or expertise yet


to actually go through it and categorize it


so that I could see trends.


That's a project that I have on my long list of things


that I want to do.


I haven't done that so far, because so far no one


has cared, so I thought no one is interested.


But now I know at least one person who's interested,


and maybe there's more people out there


who might be interested.


And then I have a good reason to actually go through and try


these things out again.


And I need to find out where the data sits again,


because I had access to it at some point,


but I'm not sure if I still have.


But that's a good question.


I'll see if I can get that information out,


and then maybe we can even put out


a blog post on the most common JavaScript errors


that we are seeing in rendering.


Good question.


Thank you, thank you very much.


So you have more than one?


Yeah, I don't know if Adel has a question.


Yeah, let's see.


Let's see.


Floor is open.


Yeah.


Now go for it.


OK, OK, OK.


It's not a problem.


OK, so the second question is about the layout information.


So when you render a website, you


are getting the render tree, layout tree, blah, blah, blah,


and you have all the position for the element in a page.


How bad is not being able to get those information for problem,


not for WLRS problem, but for problem like you


can't get the CSS and so on?


So the first problem I can guess is the mobile check.


So that's the first one.


But there are also other problem like understanding better


the page, understanding where the main content is, and so on.


So generally speaking, it's not that big of a problem


because as long as we have the content,


we at least know what's hypothetically on the page.


But similar to, so the question is


very similar to how important is to have semantically


correct or valid HTML, right?


If you don't, that's fine.


If everything is a diff on your page, that's OK-ish for search.


Will not necessarily be OK for accessibility tools.


It will not necessarily be OK for your users.


And it will definitely rob us some semantic information.


So the more information we have, the better it is.


The easier it is for us to make it well-not educated guesses,


but to know what you think is important,


to know what looks like it's the centerpiece.


We don't have that information.


We don't know.


That happens sometimes.


And it's not like we can't do anything with that page


or we will not rank it or anything.


It's just we have less information than otherwise.


So that's always going to be a little bit of an issue.


That's also one of the reasons why


we advocate against people trying to simplify things


by excluding CSS resources.


That's actually not making things simpler.


It's making things harder.


It makes things less information-rich for us.


So that's also not a good idea.


And last but not least, as you said,


there are signals such as mobile friendliness


that might be impacted when things go wrong


or go sideways there.


So it's not the most important thing.


It's not a big problem that you really


need to address if it's not there.


If it's there, it just gives us additional information


that we can work with.


Thank you very much.


Very happy to.


Do we have more questions?


We have smart people in the audience.


So I expect more questions.


If not, then I'll refresh YouTube one more time.


There are no questions coming in.


OK.


So no problem at all.


No problem at all.


So I don't remember.


Probably a week ago, I asked on Twitter about the queue


priority.


I'm not going to ask about that again,


because I can understand this at implementation detail.


But can a page with an error blocking


other page from the same origin to rendering?


Let's say we have 1,000 page from the same domain.


This because you probably have some sort of concurrency.


So I don't.


Yeah, I can understand that you are splitting all the page


through a bunch of machine.


But if one or more of these pages


are not rendering correctly, you have to render again those.


You're still processing other page before.


So you are moving the page in a different queue,


like every queue at the time.


We don't want to say anything about that.


So there's nothing that would block other pages just


for one page having a problem.


Fundamentally, there's just different queues


with different service level agreements, so to speak,


or service level objectives.


So for instance, live tests are usually prioritized


in a separate queue and going to separate instances,


because that just needs to be a lot faster.


Whereas when indexing, when the whole rest


of the process of the signal collection


might take a few hours, minutes, then the rendering time


does not necessarily become a problem.


So we could potentially render a little later.


And an error would just mean that we have to retry.


So that's the only real difference


that happens to pages that have errors happening or preventing


them from being rendered, is that we retry them.


That's the only thing that go back into the queue.


They're being retried.


But it's not that we are keeping tabs on, oh,


this page from this website has a problem.


So we now have to hold back all the other pages


until we have done this page.


That's not the case.


SPEAKER 1 OK, cool.


Thank you.


Welcome.


All right.


If you're not sure if you're running over someone else's


desire to ask questions, there is a raised hand button


at the lower part of this wonderful tool called Meet


that you can use to get my attention as well.


Or you can use the chat in this lovely tool too.


But please, please ask more questions.


SPEAKER 2 I have also a question.


SPEAKER 1 Awesome.


Hi, Thomas.


Hi.


So it's regarding the m-dot websites.


So there are still a lot of m-dot websites.


And as far as I know, as long as the setup


is correct with the canonical, with the real alternate,


the website can perform as good as with the responsive layout.


What happens if the www version has a lot of links,


the mobile version, so the m-dot version,


has not that much link on the layout.


The AMP version has, again, all the links, internal links


as the www version.


So long story short, the mobile version


has only a few links on the website, so internal linkings.


Does it have an effect on the performance?


Because it's a mobile first index, so which


is with the page, but Google crawls?


And if Google comes with the mobile crawler,


Google crawls the m-dot version and sees only


the few links, internal links?


Or how does it work?


Or what's the secret behind it?


SPEAKER 1 That's not really a JavaScript-specific question.


And with the link graph and ranking, that's where I'm out.


I don't know.


OK.


Don't know.


Sorry.


I would suggest asking that question in John's office


hours, but in general, what I can say


is if the m-dot version has a very different linking


structure, and we would eventually


prefer crawling the mobile version,


then we would probably see that as the actual page structure


and not necessarily the desktop one.


It's always a good idea to try to keep them


as consistent as possible, because that definitely


minimizes the opportunity for us to misunderstand the way


that your page structure looks like.


But I think generally, if it works now,


it should probably continue to work fine in the future.


SPEAKER 2 OK.


All right.


SPEAKER 1 Cool.


Thanks.


SPEAKER 1 No worries.


More questions?


Oh, yeah, there we go.


Raise the hand.


Yes, Michael.


Hi, Michael.


SPEAKER 3 Hi, Martin.


I'm the guy who made the post.


Does Google currently have problems


with the pre-render service that thereby 500 errors arise?


Our technicians told us that Google leaves connections open,


and it thus comes to a traffic jam


that no further connections are possible.


And I set you a bitly link so that you


can see the original page.


Where did you post that?


I posted this on YouTube in the comment section.


But can I post a link here now?


Yeah, sure, sure.


Because in the YouTube comments, I'm


only seeing time warning for Europeans.


OK, then you didn't see the other thing.


Because I couldn't get in before I tried again and again.


Yeah, I noticed that I accepted you,


and then you didn't come through.


And that worried me.


OK.


So OK, where can I post you?


There's a chat in here on the lower right-hand corner.


There should be a little chat button.


Chat, chat, chat, chat, chat, chat.


Should be amongst details.


OK, it doesn't show me the chat button.


No?


Interesting.


Up here.


It's on the right upper.


OK, in that case, it's in different places


for different people.


I think I have some experiments enabled here.


Right.


Yes.


And it went better now.


It went better now.


And the pages are returning to the Google search results.


But the Google search console told us that we have 503s.


And the technicans told us that it is the problem with the,


wait, I post in the comments section.


I post everything so you can read it sometimes.


It's easier to read than to hear it if someone talks.


Maybe it's in the, let's see.


Maybe it's in the previous ones.


I don't know.


OK, I should not open our YouTube channel


because there's always something making noise.


Maybe here?


No, I'm still not seeing it.


Damn it.


Here you go.


There's Google.


Our technicians told us that Google is connected.


I can send you now the original page.


But I didn't want to post it on YouTube.


It must look like a link page.


I understand that.


The page itself seems to be, so at least the home page


is definitely listing.


And I'm wondering if I can see.


Ah, come on.


Don't do this to me.


Our lovely, lovely internal tools.


The technic people told us that Google leaves connections open.


That would surprise me.


And they would have a traffic jam.


And so now we have to figure out, find out,


can we believe what we heard?


And if yes, maybe you just say, this is the point.


This is what I would love most.


So I don't think we leave connections open.


That would very, very much surprise me


if we were to do that because then other people would


be complaining.


In general, we don't have any special treatment


for prerendering services or anything.


One thing I would check with them


is if we are crawling with HTTP2 or if we are crawling with HTTP1


when we are crawling.


That might be something.


If anything, I would be not surprised to see


glitches in HTTP2 crawling.


Let's see.


Does it tell me something here?


No, we seem to be crawling with HTTP1 as far as I can tell.


Yeah.


What does it say in terms of crawling information?


Indexing crawler is mobile.


SPEAKER 2


The page is also HTTP2 ready.


MARTIN SPLITTENBERG That is possible.


We haven't rolled it out for everyone just yet.


I do see that there was a peak around March 17th.


Yes.


Escape fragment.


OK.


Let me throw that.


So everybody else who also wants to join us,


the link is in the chat.


I wish I could show you how weird debugging


is in our internal tools, but unfortunately, I can't.


OK, so then that website's host.


I need the host, not the URL.


So I'll remove this part.


And I would like to see how our crawler has done in the past.


Yeah, so there is definitely someone wants to join.


I'll jump over.


Oh, another person I know.


But again, it seems to not have worked properly.


Dang.


So this is strange.


This is very, very strange.


I am seeing a peak in terms of connections


that we had in parallel around that time when you were seeing


issues there.


I would have to check with the team, with the Googlebot team,


to see why there was an increase in connections at the time.


And I could imagine that your tech people are not


wrong to say the connection stayed open longer,


or at least there were more connections than usual.


But that happened beforehand and didn't raise any problems.


So it's not an unusual thing for us to use more connections.


What is unusual is that this time it


caused 500 responses on your server.


That's interesting.


What is the error threshold?


And there's also, from our perspective,


there aren't more errors than usual either.


Strange.


That's an interesting one.


I'll probably have to get back to that question probably


over Twitter once I know more about this.


But it seems to be that it's an HTTP1 crawl.


The connections should not have stayed open longer than usual.


But there were 500 responses that I


would investigate on your end.


Because as far as we can go, we know that we got a 500 back.


But they are back to normal.


So this doesn't seem to be a problem anymore.


So I'm guessing you changed something,


or it went back to normal on its own.


I don't know.


OK.


So shall I tweet you directly?


Yeah, you can respond.


Basically tweet at me, and then I'll try to track this.


Interesting is also that the response size went up


when we were seeing 500 errors.


That's funky.


Yeah.


And so we always get some feedback from the agency.


And then our rankings are dropping,


and we never know what's going on technically


in the behind area.


This might be a hosting-related issue on your end,


but yeah, interesting.


But as they also host big running events for an energy


drink, they should have enough power regularly to solve that.


They should, but you would be surprised.


OK.


Awesome.


Cool.


Thanks a lot, yeah.


Take a look and see if anything from our side comes up.


All right.


Sweet.


Anyone else wants to ask a question?


I don't see any other raised hands.


Was a really nice use of the raised hand feature.


I like that.


I like that feature a lot.


Oh, it's talking over each other.


Hi, Snezana.


Oh, Gabe.


Gabe raised.


Hello.


Yes.


Nice to meet you.


Hi, Gabe.


Nice to have.


Hello, Martin.


Can you hear me?


Yes, sorry.


Cross talk.


No, I just wanted to make sure.


No worries.


It's nice to officially speak with you


after kind of stalking you via video


and watching all your wonderful tips and tutorials.


Oh, god.


I just don't have, I guess, a specific site question.


I get some general questions just around analyzing


just kind of your thoughts.


One of the things that I think that kind of coming up


against with the page experience update coming out


is identifying page load speeds and that kind of thing.


And traditionally, I think as SEOs,


when it comes to JavaScript, there's


always this input to externalize it and call it


in and that kind of thing.


And now there's more feedback about inlining certain scripts.


So you can kind of pick up your speed a little bit more


and that kind of thing.


Do you have any suggestions on any tools


that help kind of identify when to inline


or which scripts to inline?


Sometimes when you're kind of going through all the,


especially when you're not a JavaScript developer,


you're kind of going through all the script


trying to identify which ones are activating,


which parts of code, and that kind of thing.


So I don't know if there's any secretive tools or maybe things


that you keep close to your chest


that you might want to throw out here on our call.


So my first secret weapon is to not inline but remove


JavaScript whenever possible.


But that's obviously not always the case.


And you will not be able to remove all JavaScript.


You'll just be able to remove unused bits relatively easily.


What I do like as a JavaScript developer


is the tree-shaking ability of most of the bundlers.


So I think Webpack has it built in.


I'm not sure if Rollup can do it as well.


But pretty much all the good bundlers out there


are able to remove unused code paths.


So that's definitely a win, because code


that you don't have to download is just


saved bandwidth and safe processing power to begin with.


When it comes to inlining JavaScript,


you want to inline the bits and pieces


that you absolutely, essentially, really, truly,


100% need to get the users the content and the core


experience.


Any kind of tracker is not that.


You want to load the trackers as late as possible in the process


any kind of analytic solutions, any kinds of, I don't know,


stuff that is not core to the experience of the user


should be moved down.


I think some of the JavaScript frameworks


have a mode which is called server-side rendering


plus hydration, where they inline the core runtime


of themselves plus what's needed to get the core content to then


hydrate and actually become a fully functional JavaScript


application.


They should do that automatically.


So I think Next.js has that built in.


I think Nuxt.js has that built in if you work with Vue.js.


I'm not sure about Angular Universal,


because I think Angular Universal goes


a slightly different route.


There is, oh, god, what's it called?


There's a tool that I've never tried myself,


but I have people here singing the praises for it.


I think it's called Razzle Dazzle or something,


if I remember correctly.


I know the name is fantastic, but the tool


is apparently good and works across different frameworks.


But yeah, the question, there is not really much tooling


around to identify which ones to inline,


because that's a very subjective, very hard


to automatically answer question.


It's only in sitting down with developers


and thinking about what is the absolute minimum JavaScript


that we need to get the content there.


And then the answer, 95% of the times, if not 98% of the times,


is not, oh, we inline this and this and this.


It's more like we need to change the architecture in which we


are building our application in, most likely


pointing towards server-side rendering of some flavor.


No easy answer.


I'm sorry, Gabe.


GABE LEHMANNEN-SINGH CUMMINGER Yeah, it depends, right?


MARTIN SPLITTENBERG I mean, I tried to avoid the phrase,


it depends.


But it does, unfortunately.


It depends.


Because with most applications, you'll


end up with having more or less the runtime of your framework,


which is huge in its own.


And inlining that does not really help.


It minimizes a little bit in terms of network latency.


But you could probably get the same results


by preloading or prefetching that blob early on


in the header versus actually inlining it.


So inlining is a foot gun, very, very careful


not to shoot yourself.


GABE LEHMANNEN-SINGH CUMMINGER That's good to know.


Thank you.


I appreciate that.


MARTIN SPLITTENBERG You're welcome.


With JavaScript, a lot of things are foot guns.


That's the tricky, gnarly reality.


GABE LEHMANNEN-SINGH CUMMINGER It certainly feels that way


sometimes.


MARTIN SPLITTENBERG Because it is.


JavaScript is fantastic until it isn't.


All right.


Anyone else?


As I said, you can use the chat.


You can use the raise hand feature.


Or if no one speaks up, you can just.


Ah, yeah, there we go.


Zajana.


ZAJANA ZHANGI Hi.


Yeah, I have kind of a question where


I was wondering if it's possible to get some kind of ups


and downs in crawling if we actually implement


the banner that is cookie privacy specifically


for Switzerland.


Because now we have this kind of regulation


where we need to pay to users like privacy settings,


all of these things.


And we've seen some of the work web vitals,


traffics, everything going up and down.


And actually for some time, the content


was picked up as the primary one,


even though the banner was waiting for the whole content


to load.


So I was wondering if it's something


that just happens normally that we should wait for a while?


Or is it something that we should do,


like contact the service provider


and tell them this is happening.


We don't know how to do it.


Because they say from their side, it's all optimized,


let's say.


Yeah, that's a fantastic question.


In general, I would always talk to the tool providers.


Because if they're not being held accountable for the tool,


then they kind of let things slip


that they shouldn't let slip in the first place.


In general, I would assume that we are soon


going to get better at detecting these things.


Because we're continuously working


at improving the metrics, especially for LCP, FID,


and CLS, CLS being probably revamped at some point soon.


Because I've seen that the team is not


super happy with how the metric works right now.


We'll see how that goes.


But yeah, these kind of fluctuations


can certainly happen from these kind of patterns


and implementations.


And I don't really have a general answer to these things.


Because I have tried out a few solutions.


And at least the lower profile kind of self-baked


ones work well.


It seems to be that I have received a bunch of reports


for constant management platforms and constant