and after the end of the URL is there, last URL is there.


English Google Webmaster Central office-hours hangout from July 26, 2019

So in case I didn't create anything in a folder level,


let's say for cars, www.abc.com slash cars slash


bestcarsinindia.


But www.abc.com slash cars, I didn't create any page.


If a user go to the page, it will go to 404.


So is there any impact we'll create for the final URL?


Because there is nothing in a folder level,


but still the final URL is there.


That's fine.


That's perfectly fine.


That doesn't matter at all.


We see URLs as identifiers of the content.


And we don't expect that if you have a directory-based


structure that all of the folders will work individually.


That's essentially something that you can have,


but you don't need to have.


And it's not something that would change anything


from our point of view.


Also, if you, for example, remove a lot of content


on your website.


SPEAKER 2


Will it break the priority of the page or something?


JOHN MUELLER No.


No.


It's perfectly fine.


Cool.


All right.


Let me run through some of the other stuff.


It is not good, actually.


I couldn't be able to hear what I spoke.


JOHN MUELLER Oh, OK.


Sorry.


No, it's perfectly fine to have this set up


where you have folders and the individual folder URLs don't.


Oops.


Again, it's completely fine to have


folders and the folder URLs don't need


to have content on their own.


That's perfectly fine.


Let me see if I can.


Sure.


Let's run through some of the other questions


that were submitted.


Is using 302 redirect for affiliate links a bad practice?


So you basically have slash vitamins


and it redirects to vitamin shop with your affiliate URL.


Is that a problem or not?


From our point of view, that's perfectly fine.


There is nothing that we would consider bad there.


From my point of view, because this is really


nothing that provides any additional value


for your website in the sense that it looks better


by having redirects to your affiliate pages or not,


personally, I would recommend using less complexity


and not setting up these kind of redirects


and just linking to that site directly.


I think you just save yourself the effort


of trying to maintain all of these things individually.


Question about the site link search box.


Not about how to implement it, but basically,


how do I make it shown or not?


So one of the things that I've seen with the site link search


box is if you set up the markup for this on your site,


then this is something that takes quite a long time


to actually be in effect.


So it's not like other types of content


where we can see maybe crawl that page once or twice,


and then we can show that rich result type in the search


results.


The site link search box is something


that we really need to see for the long run.


And sometimes it takes a month, maybe even longer,


to be visible in the search results.


And also, the markup for the site link search box


doesn't mean that we will show a site link


search box for your site.


But rather, if we show a site link search box for your site,


then with that markup, we can pick the one that you prefer.


Like if you have an internal site search,


then we can show that one instead.


So those are kind of the tricky aspects


there in that we don't always show this for most sites.


And when you do provide this markup,


we need to see it for a longer period of time


before it's visible in the search results.


Hi, John.


So on this site link search box, so we have a main website,


plus we have international website as well.


So if this site link search was appearing for my main domain,


but it is not appearing for my other country website,


but they are somehow present in support structure.


So how can I enable the same thing for my support


for the special websites?


Yeah, again, we would see those as separate websites.


And we don't always show the site link search box.


So that's something where I think


we might show it for one country version, but not


the other country version.


We might show it for one brand within a bigger company,


but not for another brand.


So that's something that, from our point of view,


is just individual across different websites.


So in that, basically, having a same brand,


having a similar kind of practice,


like Google saying, this is one country that


is able, but not the other one.


So what is the idea behind it?


Like, am I showing for the one country, not for this?


It's mostly something where we try to provide value for users


when they search.


And we try to provide it in a way that


makes sense for the users.


So in that sense, it's not something


that we would always show for a website for queries,


but rather when we can recognize that it makes sense


to show it for users for specific queries,


then we'll try to show that.


So what you're probably seeing is that for some countries,


we've noticed that it makes sense to show it to users.


And for other countries, we're not sure yet.


Or we see conflicting signals that tell us,


well, maybe people just want to go to a home page


or want to go to a main page for that brand.


Or maybe they interact with that website differently,


all of those things.


So that's something where it can be


normal that for one country you see it, for another country


you don't.


All right.


Thanks.


Now, I wish there were an easier way


to force some of these things.


But it is something that we've noticed that sometimes it


makes more sense to show it, and sometimes it


doesn't make as much sense.


Let's see if I can run through some of the remaining


questions.


Using hreflang on all pages of a multilingual sitemap,


is that on all pages or on a multilingual sitemap?


Which is best, both of those work.


Sitemap or the on-page markup is retrieving images


through JSON or jQuery SEO friendly.


Sometimes it sounds like you're doing lazy loading.


And we have a bunch of guides for lazy loading in search.


So I would double check those.


You can also kind of simply check the page


with the mobile friendly test to see if those images load


or not.


That's a good way to get a first glance.


Let's see.


We have a page like this one.


There are a lot of areas that you can click on.


You have a pop up with text.


I don't like this design, but the designers do.


And I would prefer that all text was


visible to the user all the time without any pop up.


So my question is, how will Googlebot read this page?


Will Googlebot kind of be able to click on a page


or see the content itself?


So I didn't have time to double check this particular page.


But in general, there are two setups


that can be done for this kind of behavior, where you have


elements on the page that you can click on


or that you hover over to see text.


One is that the text itself is actually


loaded when the page is loaded.


And it's just not visible by default.


That's usually something that works fine for indexing.


The other approach is that when you click on an element


or you hover over an element, there's


actually JavaScript that goes to the server


and pulls that content and then shows that page.


That's something that we would miss because we don't know


where to click or where to hover with Googlebot's mouse.


So those are kind of the two approaches there.


One simple way to double check if it works or not


is to take a piece of text that is shown in one of those pop


ups and just search for that.


And if you can see that your page is being shown


for that piece of text, then we can obviously index that content


and show it in the search results.


A question about paywall markup for subscription websites.


There is an example for news article markup in the developer


documentation.


But how would you mark up a BBS or user reviews?


I believe the flexible sampling markup


is specific to news article and similar structured data types.


So it would probably be stretching


it to use that to mark up a BBS or kind of a forum-based setup.


So I don't know if that would really be suitable there.


I would double check how the type of markup


would fit for your particular pages in the sense


that I believe this wraps up to creative work in schema.org.


And it might be that there is a subtype that fits the type


of content that you have.


If articles don't have images and the image element


is required, is it fine to use a website logo for images


in the paywall markup?


That feels a bit wrong in the sense


that the image would not be specific to that article.


So that's something that I would personally try


to avoid in a case like that.


I also don't know if the image is actually


a required property for the article markup.


If it is, then that's something that obviously it


would make sense to show an image that


matches your actual content.


You can think of it this way in that we show the image,


for example, in the Discover feed together with the article.


And if it were just your logo, then that


would be kind of weird for users to see there.


And it probably wouldn't encourage


people to go to your pages if they just


see kind of a generic logo instead of the actual content


or an image that actually matches the content.


I have a same merge problem.


I merged two large sites together six months ago.


Tens of thousands of URLs involved.


301 redirects were made for everything.


However, I notice Google is still


showing the old merge domain for many product queries that don't


include the old site's name.


What it is showing in the SERPs is only the old URLs,


but with the new title tags, meta descriptions,


clicking on the results for the old domain


redirects you to the new one.


These queries are mostly commonly


used model numbers or product names by manufacturers.


Why is Google showing my old domain?


So I think, on the one hand, site mergers always


take a little bit longer.


So that's something where I would expect it


to take a couple of months.


You said six months ago, so it seems like it


has been a couple of months.


The other aspect there is that if you're


seeing the content of the new page in the search results


with the URL of the old page, then what is likely happening


there is we're able to crawl those different variations


of the URLs, like the old URL and the new URL,


and we find the content there.


So we find the new content.


However, it's a matter for us now


to figure out which URL we should show in the search


results, which is kind of the canonicalization aspect there.


So we see the new URL.


We see the old URL.


We see there is a redirect from the old URL to the new URL.


So that's a pretty strong sign for us.


However, there might be other signs that


point at the old URL for us.


So maybe some of the internal links have not been updated.


Maybe the sitemap file has not been updated.


Maybe there are other things that you can do to update,


like the canonical tags on these pages.


Maybe you have hreflang annotations on these pages.


All of those things essentially add up.


And that's something where we will


try to pick the appropriate URL to show in the search results.


And it sounds like we're picking the old URL at the moment.


One thing that might happen here is that this will just


settle down over time.


Another thing might be that you can kind of go through all


of those different aspects and double check


to make sure that they're all really pointing out


the new URL.


On the positive side, switching between the URLs


does not change anything from the ranking.


So just because we're showing your old URLs in the search


results doesn't mean that they're


ranking lower or ranking higher or any differently.


We're essentially saying, for the slot in the rankings,


we have multiple URLs that we can show with the same content.


And we're going to show this URL,


or we're going to show that URL.


So from that point of view, it's not a critical thing


that you need to resolve right away.


But rather, take your time, double


check all of the details to make sure


that all of the internal linking is correct.


You can use some third-party crawler tools


to double check the crawling of your website.


There's some really good ones out there nowadays.


And double check all of the annotations on your site,


all of the things that are not visible by default,


like the canonical link, any hreflang annotations


that you have on there, all of those things.


And make sure that they align with the new version.


And then over time, that should settle down again.


Hi, John.


What do you think about the practice of some big publishers


tagging all outgoing links with rel nofollow?


From what I know, the reasoning behind this


is that with follow links, you would leak link juice


and then rank worse.


So that's definitely wrong.


It's definitely not the case that if you


use normal links on your website that you


would rank any worse than if you put nofollow links


on all outgoing links.


I suspect it's even on the contrary


that if you have normal linking on your web page,


then you would probably rank a little bit better over time,


essentially because we can see that you're


part of the normal web ecosystem.


So it's definitely not the case that you


have any kind of ranking advantage


by marking all outgoing links as nofollow.


The one reason that I've seen from talking


with a lot of publishers is that they're often


just not sure which of these outgoing links


are paid links or placed there because of some arrangement


with the author, or maybe they have paid articles as well


in between and they just don't know how to deal with that.


And it's more a matter of they're


trying to stay on a safe side of we


will put nofollow on these links because we don't


know which ones we can trust.


And from my point of view, that is also


problematic in the sense that I understand not knowing


which links you can trust, but essentially,


if you're a news publisher, you should


trust what you're writing about, or you


should be able to understand which part of the content


that you write about is actual content


that you want to have indexed like that


that you want to stand for.


And if these are things that you want to stand for,


then make sure that you have normal links on there.


Make sure that you're referring to that content as something


that, yes, I can stand behind this link


because I researched this topic, and this


is the source.


This is maybe some other resources


that lead to more information on this topic.


This is what I researched from.


This is an authority that I'm quoting.


All of these things are reasons to place normal links


on a page.


So from that point of view, I would certainly


find a way to make sure that you don't necessarily


have to no follow every outbound link.


So John?


Yes.


So you mean to say even we are putting no follow links


or no follow links, whatever it is,


it will never affect our rankings, right?


I think I can never say never, but it definitely


is not the case that if you no follow all of the links


on your site, you will rank any better.


Yeah, even if you put some do follow links on a website


also, it doesn't mean that our rank will drop,


or our linkages will pass because we are


worrying about our linkages only.


Like, let's say if you are just putting 10 do follow links


of other sites, and of course, as per the data in the links,


maybe we just came to know that our linkages is getting passed,


and because of that, our authority will get down.


So is that true?


I don't think you would see any change on your site's page


rank with regards to no follow links or normal links.


Yeah, because your tools like HRP,


when we read about the blogs, even


they are saying that if the site's having 70 plus


authority sites, then you can just give the link over there.


But they didn't mention whether it's a do follow or no follow.


But here, you're talking about the same.


If you're putting no follow and do follow,


it will never affect the rankings.


So that's what it is.


Of course, we know that if you put no follow,


the linkages will pass.


But again, some controversial things are happening.


I don't quite follow your question.


But again, it's something where having normal links on a web


page for content that you want to stand for,


that's perfectly fine.


That's totally expected from our point of view.


Yeah.


Of course, we are seeing some US sites.


Of course, they are just getting links.


And they are just putting links up other sites also.


They are ranking on top.


But here, only we are worrying about putting no follow links


or no follow links.


Yeah, so I think, first of all, I


wouldn't focus too much on what other sites are doing.


And I wouldn't assume that other sites are always


just ranking because of the links that they got.


But rather, I'd really just focus on your own sites


and make sure that what you're providing there


and what you're linking to matches what you want


to stand for with those pages.


And it's also not something where you can say,


well, I will no follow all of these links.


But I will link to CNN and Google and Wikipedia


because that looks good.


That's not something, from our point of view,


that would make your pages look any more important than they


are.


But rather, link to the sources that you want to have linked


to, link to the places that you think


makes sense for your users.


And if there are things that you're doing where maybe you


have an ad on a page or maybe you're working together


with a friend who also has a web page, then, of course,


those are the kind of things you would like to no follow


because it's clear that this is a link that is there


for other reasons.


But everything else where you're linking between from your site


to some other site because you're providing,


kind of saying this is a reference or this is a source


or this is more information that you can look at,


then definitely just link normally.


There is no reason to put a no follow there just


because you're afraid that if you like to link out too much,


that's somehow problematic.


Yeah, sure, yeah, thanks.


All right, we're a bit over time.


And wow, we still have so many questions left.


So I don't think I can manage to get through those.


I think we'll stop here.


What I'll do now is pause the recording


and upload that to YouTube.


And hopefully, that just works.


As always, thank you all for joining in.


Thanks for the many questions.


It's cool to see that more people can join here now.


And I'll set up the dates for the next couple versions


as well.


And we can see if this setup continues to work.


Unfortunately, we don't have a live stream for these anymore,


at least not at the moment.


But we do have the recording, so that's good.


All right, then I wish you all a great weekend


and hope to see you all again in one of the future episodes.


Bye, everyone.


Bye.


Bye, John.


Thanks, John.


English Google SEO office-hours from February 5, 2021

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


Hours.


My name is John Mueller.


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


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


where people can jump in and ask their questions


around their website and web search,


and we can try to find some answers.


As always, a bunch of stuff was submitted on YouTube,


so we can go through some of that.


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


you're welcome to jump in.


Hi, John.


I have a question.


So this question is regarding e-commerce.


So there is a lot of e-commerce pages.


They have refined pages, right?


So they will be pages that they will


put a certain amount of product in the page


based on the predefined logic to show up


those products in those pages.


And those pages that, in my case, I have a client,


it's very good pages to capture long-tail keywords,


because they are refined, saying that, for example, computer


and at the same time, you have AMD chips, things like that.


And when people are searching for long-tail keywords,


like computer, AMD processor, those pages


are a very good place to capture them.


However, so here come my question is, for those pages,


there are some kind of design that people will,


there are some kind of design that, because they're


automatically a signed product, right?


And you can't put all the product


in the first rendering of those kind of pages.


So every time when there's new product


adding into the inventory or some product is removed


from the inventory, the page content of first rendering


product will change.


And I will send an example here in the comment section.


For example, this is not my client,


because I'm not allowed to show my client's website,


but it's a similar situation.


So when you click into that link, you go into,


you can see that there are a lot of product in the page.


But when you scroll down to the bottom,


they will have load more.


So people only see the product that before load more, right?


And whenever we add inventory into the product


or remove something, the first rendering product will change.


So Google will constantly seeing different content of that page.


Will they confuse Google?


How do we solve this problem?


That's essentially fine.


That's totally normal.


I think with e-commerce, with a very busy site,


you have those kind of shifts all the time.


With news websites, you have it similar,


that you have news articles all the time.


And when you look at the home page of a news site,


there are always different articles that are linked there.


And from our point of view, that's fine.


The important part, I think, especially with e-commerce,


is that we're able to find the individual product


pages themselves.


So somewhere along the line, we need


to have kind of persistent links to those products.


So that could be on that page.


It could be on page 2 or page 3 or page 4 of that listing,


something like that.


So that's kind of the important part there.


I wouldn't worry that the pages change from load to load.


Because what will happen from a search point of view


is we will recognize there's specific content


for this topic on this page.


And we'll try to bring queries to the page that kind of match


the general topic.


And if a computer model 1 or a computer model 2


is shown there, and they're essentially equivalent


because they're in the same category of product,


then that doesn't really change much for us.


AUDIENCE 1 So from what I heard is


that as long as the logic of assigning product is consistent


and the product is showing up in the first rendering,


match the, for example, title tag on the page,


then that is fine.


But if the logic is not consistent


and they suddenly have other product,


then there will be a problem.


Yeah.


So for example, if you have a clothing store


and you have a category that's just blue,


and the category blue has everything from socks


to jackets and everything in between,


then it's really hard for us to say


this is a landing page for this type of product.


So we will constantly be confused by a page like that.


Whereas if it's a landing page about, I don't know,


blue jackets, for example, like category jackets and color


blue, then it doesn't really matter


which jackets you show there.


They all match that intent, and it's pretty clear to the user


they fit into that category.


So as long as this product, new adding product,


are still blue jacket, even if different blue jacket


in the first rendering and the content is changed, it's OK.


Yeah.


But if there is like one time there's


a red jacket adding to that product,


there will be a problem.


I think individual cases is absolutely no problem.


If it's always something random in there,


then it gets hard for us to understand the pattern.


OK, thank you so much.


Sorry for taking some time.


Hey, John.


Thank you.


My question is regarding image search


and why one image might be shown preference over another.


Specifically, it's on a product page


that uses like an image slider to display


pictures of the product.


And considering that pretty much everything


is nearly identical, like alt text, file name,


nearby text, dimensions, weight, things of that nature,


why might a kind of seemingly random image


from within the slider sequence, maybe third or fourth thumbnail,


be shown preference over like a featured image,


like usually the first image that you


would see on a product page?


I don't know.


It is hard to say.


I don't think so.


So we have various things that kind of go into image search.


And on the one hand, it is kind of the aspects


that you mentioned, like the titles of the page,


the image file name, the captions, alt text,


things like that.


But we do also have some logic that


tries to understand like is this a high quality image or not.


And it's possible.


I don't know those images that our systems are either


getting confused by the contents of the image


or that they clearly see like one image is significantly


higher quality than the other.


And for us, then maybe we would show it a little bit more


visibly like that.


But it's something where I think there are always


a number of different factors that play into that.


And even for multiple images on the same page,


which are kind of in the same category of things,


it's possible that we kind of show them in one order once


and show them in a different order another time.


OK, so are you able to comment on this?


I imagine that the Cloud Vision has something


to do with that, trying to match similarities with machine


learning to the entities.


Am I on the right track here?


I don't know how far we would use something like that.


I do think, at least as far as I understand,


we've talked about doing that in the past,


specifically for image search.


But it's something where just purely based


on the contents of the image alone,


it's sometimes really hard to determine how the relevance


should be for a specific query.


So for example, you might have, I don't know,


a picture of a beach.


And we could recognize, oh, it's a beach.


There's water here, things like that.


But if someone is searching for a hotel,


is a picture of the beach the relevant thing to show?


Or is that, I don't know, a couple miles away


from the hotel?


It's really hard to judge just based


on the contents of the image alone.


So I imagine if or when we do use machine learning


to understand the contents of an image,


it's something auxiliary to the other factors that we have.


So it's not that it would completely


override everything else.


SPEAKER 2 Got you, thank you.


JOHN MUELLER Sure.


SPEAKER 3 John, just one follow up on this.


Does Google have any plan of machine learning auto detection


of what is happening and what is there in picture?


Because I am saying that different devices also


have this kind of feature.


Does Google also have any plan of implementing


this kind of feature?


JOHN MUELLER What is happening within the image?


I don't know.


Kind of like with the previous question,


it's something where it's certainly


possible to some extent to pull out some additional information


from an image, which could be like objects in the image


or what is happening in the image.


But I don't know if that would override any of the other


factors that we have there.


So my understanding is this is probably


something that would be more kind of on the side


if we have multiple images that we think are kind of equivalent.


And we can clearly tell somehow that this one is more relevant


because it has, I don't know, the


objects or the actions that someone is searching for.


And maybe we would use that.


But I honestly don't know what we've announced in that area


or what we're actually using for search there.


Because the thing to keep in mind


is that there are a lot of different elements that


are theoretically possible that might be


done kind of in consumer devices.


There are lots of things that are patented


that are out there that are kind of theoretically possible.


But just because it's possible in some instances


doesn't mean that it makes sense for search.


And we see that a lot with patents


when it comes to search, where someone will patent


a really cool algorithm or setup that could


have an implication for search.


But just because it's patented from Google and maybe even


from someone who works on search doesn't mean that we actually


use it in search.


AUDIENCE 1 Yeah.


OK.


Thank you.


JOHN MUELLER OK.


Let me run through some of the submitted questions.


And if you have questions along the way, feel free to jump in.


And we'll almost certainly have time


towards the end for more questions from all of you.


All right.


The first question is about Google Discover.


One of the sites I'm running is about anime, fan arts,


cosplay, fan fiction, was performing fairly well


in Discover.


But one day to another, the traffic


dropped to zero without any significant change on the site.


In Google Search, it's growing before and after that.


What kind of problems could bring that situation?


I don't know.


It's really hard to say without looking at the site.


But in general, when it comes to Google Discover,


one of the things that I've noticed from feedback


from folks like you all is that the traffic tends


to be very kind of on or off in that our systems might think,


well, it makes sense to show this more in Discover.


And then suddenly, you get a lot of traffic from Discover.


And then our algorithms might at some point


say, well, it doesn't make sense to show it that much


in Discover anymore.


And the traffic goes away.


And especially with Discover, it's


something which is not tied to a specific query.


So it's really hard to say what you should be expecting


because you don't know how many people are kind of interested


in this topic or where we would potentially


be able to show that.


So that's something where if you do see a lot of visibility


from Google Discover, I think that's fantastic.


I just would be careful and kind of realize


that this is something that can change fairly quickly.


Additionally, we also, for Discover,


we have a Help Center article that


goes into pretty much detail what kind of things


we watch out for and, in particular, what kind of things


we don't want to show in Discover.


So that's something that you might want to double check.


Depending on, I guess, the site that you have,


that's something that might be more relevant or less relevant


there.


But I would definitely check that out.


What are the levels of site quality demotions?


Is there a first level where everything site-wide


looks fine, no demotion?


Second level that you demote some pages that


are not relevant, or third level site-wide is not good at all?


So from my understanding is we don't


have these different levels of site-wide demotion


where we would say we need to demote everything


on the website, or we don't need to demote anything


on the website.


I think, depending on the website,


you might see aspects like this, or it might


feel like aspects like this.


But for the most part, we do try to look at it


as granular as possible.


And in some cases, we can't look at it as granular as possible.


So we'll look at different chunks of a website.


So that's something where, from our side,


it's not so much that we have different categories.


And we just say it's like in this category


or in that category.


It's just that there is almost like a fluid transition


across the web.


And also, when it comes to things


where our algorithms might say, oh, we don't really


know how to trust this, for the most part,


it's not a matter of trust is there or trust is not there.


It's like yes or no.


But rather, we have this really kind of fluid transition


where we think, well, we're not completely sure about this.


But it makes sense for these kind of queries, for example.


Or it makes sense for these kind of queries.


So that's something where there is a lot of room.


Let's see, I have a question about omitted results.


We published two large.coms, horoscope, and astrology,


each with each own URL and content teams,


after ranking on the first page for astrology queries


for multiple years.


In February last year, only one of the sites


began to show up for normal search results at a time.


Whichever site has the highest ranking for a given query


will show up, with the other site being


classified as an omitted result.


There is no duplicate content or cross links between the sites.


I'm curious why this is happening.


It's really hard to say without looking at the specific sites


and looking at the specific situation.


So usually with two websites, if they're not


completely the same, then we would rank them individually,


even if there is kind of like an ownership relationship there.


So from that point of view, it might also just


be something that is kind of not related


to what you're suspecting in that our algorithms think


that it's like the same site.


We should only show one of these at the same time.


I have seen situations where if there


are a large number of sites that are involved,


a large number of domains, that our algorithms might say,


well, all of these domains are essentially the same content.


And we should just pick one of these


to show rather than all of these.


But usually if there are two websites


and they're kind of unique in their own ways,


then that's something where we would try to show them


individually.


So I think from a practical point of view, what I would do


here is go to the Webmaster Help forums


and post the details, what you're seeing here,


maybe some screenshots, specific URLs and queries,


where you're seeing this happening.


And the folks there can take a look at that


and maybe guide you into, I don't know,


if there's something specific that you could


be doing differently there, maybe they


can point you at that.


Or maybe they can point you in the direction of saying,


well, it is how it is.


That's nothing unnatural that's happening there.


But also the folks active in the help forums


have the ability to escalate things to Google teams.


So if they think this is really weird


and maybe something weird is happening on Google's side,


then they can escalate that to someone at Google.


Let's see.


Does Google search consider each URL of a website individually?


For example, does a low score on a domain home page


have any effect on the other pages which have a high score?


So yeah, like I mentioned before,


we try to be as granular as possible,


as fine grained as possible, in the sense


that we try to focus on individual pages.


But especially within a website, you're


kind of always linking to the other pages of your website.


So there is kind of a connection between all of these pages.


And if one page is really bad and we


think that's the most important page for your website,


then obviously that will have an effect on the other pages


within your website, because they're all


kind of in context of that one main page, for example.


Whereas if one page on your website


is something that we would consider not so good


and it's some random part of your website,


then that's not going to be the central point where everything


evolves around.


Then from our point of view, that's like, well,


this one page is not so great.


But that's fine.


It doesn't really affect the rest.


The mobile section of Core Web Vitals in Search Console


shows a bad URL on original link,


while the AMP version of the same URL is a good URL.


Why are these two considered separately?


So essentially, what happens there


is that we don't focus so much on the theoretical aspect


of this is an AMP page and there's a canonical here.


But rather, we focus on the data that we


see from actual users that go to these pages that


navigate to them.


So that's something where you might see an effect of lots


of users are going to your website directly,


and they're going to the non-AMP URLs, maybe,


depending on how you have your website set up.


And in Search, you have your AMP URLs.


Then we probably will get signals or enough signals


that we track them individually for both of those versions.


So on the one hand, people going to Search,


going to the AMP versions, and people maybe


going to your website directly, going to the non-AMP versions.


And in a case like that, we might see information


separately from those two versions.


And then kind of like we have those two versions


and the data there.


So we'll show that in Search Console like that.


Whereas if you set up your website in a way


that you're consistently always working with the AMP version,


that maybe all mobile users go to the AMP


version of your website, then that's something where we can


clearly say, well, this is the primary version.


We'll focus all of our signals on that version.


The next question there is, since AMP is enabled,


will Google Mobile Search consider only the AMP version,


which passes the Core Web Vitals test when ranking the website,


or will the original link also be considered?


So I mean, on the one hand, there


is the aspect of is it a valid AMP or not.


If it's not a valid AMP, then we wouldn't show it.


So that's one aspect that goes into play there.


But I think in the theoretical situation


that we have data for the non-AMP version


and data for the AMP version, and we


would show the AMP version in the search results,


then we would use the data for the version


that we show in search as the basis for the ranking.


So in a case like that, where we clearly


have data for both of these versions,


and we would pick one of those versions to show,


then we would use the data for that version.


That's similar, I think, also with international websites,


where you have different URLs for individual countries.


And if we have data for one version, we show that.


Or if we have one version that we


would show in the search results,


and we have data for that version,


then we'll use the data for that version,


even if we have other data for the other language


or other country versions.


Yeah.


The only case where I know where we would fold things together


is with regards to the AMP cache,


because theoretically, the AMP cache is also


located in yet another place, another set of URLs.


But with the AMP cache, we know how


we should fold that back to the AMP version


and track that data there.


So that's a little bit of an exception.


But if you have separate AMP versions


and separate mobile versions on your site,


then it's very possible that we could track those individually.


Does Google weigh the exact match title tag more


in comparison to the title tag focused more on users?


So let's say the phrase I want to rank for is Audi A3,


and one version of the title tag is this exact match.


The other version is this car for sale, 152 great models.


Would this title be scored less relevant for the query Audi


A3 just because it is longer and not exact match?


I don't think we have any exact definition on how


that would pan out in practice.


So there's certainly an aspect of,


does this title match the query?


But we also try to understand the relevance of the query.


We try to understand things like synonyms or more


context around the query, around the titles as well.


So I don't think there's a simple exact match to the query


is better or not exact match to query is better there.


So my recommendation there would be to test this out


and just try it out.


And not so much in terms of SEO, like which one


will rank better, but think about which one of these


would work better in the search results.


And that's something you could try out on one page.


You could try out on multiple pages that are set up


in a similar way.


And then based on that, you can determine, well,


this one attracts more clicks from users.


It matches the intent that the user has better somehow.


So I'll stick to that model and use that


across the rest of my website.


So that's kind of my recommendation there.


I think with the general information retrieval


point of view of which one of these would be the better fit,


I imagine you could get into really long arguments


with the people that are working on information retrieval


on which one is better or not.


So I don't think there is this one clear answer.


Comments below the blog post.


Are comments still a ranking factor


on migrating to another CMS?


And would like to get rid of all comments about one to three


not really relevant comments below many blog posts.


Can I delete them safely without losing any ranking?


I think it's ultimately up to you.


From our point of view, we do see comments


as a part of the content.


We do also in many cases recognize


that this is actually a comment section,


so we need to treat it slightly differently.


But ultimately, if people are finding your pages based


on the comments there, then if you delete those comments,


then obviously we wouldn't be able to find


your pages based on them.


So that's something where depending


on the type of comments that you have there,


the amount of comments that you have,


it can be the case that they provide significant value


to your pages, and it can be a source


of additional information about your pages,


but it's not always the case.


So that's something where I think


you need to look at the contents of your pages overall,


the queries that are leading to your pages,


and think about which of these queries


might go away if my comments were not on those pages anymore.


And based on that, you can try to figure out


like what you need to do there.


It's certainly not the case that we completely


ignore all of the comments on a site.


So just blindly going off and deleting all of your comments


in the hope that nothing will change,


I don't think that will happen.


When using interstitials as product pages,


does Google index the content on those interstitials,


or does it only index the content on the static pages?


So I wasn't quite sure how you use interstitials as product


pages.


It seems like a kind of unique setup.


But anyway, I think it's less a matter of interstitials


or not, but more a matter of what content is actually shown


when we load those pages.


So if we load this HTML page, and by default, it always


doesn't show any product information,


then we wouldn't have that product information


to actually index.


Whereas if you kind of load that page, and it takes a second,


and then it pops up the full content, the full product


information, then essentially by loading the page,


we have that information.


And we can use that to index and to rank those pages.


So it's kind of a simple way to double check.


What we would be able to pick up with regards to indexing


is to take that URL and use something


like the mobile-friendly test or the URL inspection


tool in Search Console and copy it in there


and to see if Google is able to bring up the full product


information or not.


If Google can bring up the product information,


then probably that's OK.


Whereas if Google only shows you kind of the static page


behind that, then probably it's the case


that we wouldn't be able to pick up the product information.


So that's kind of one thing to watch out for.


I think what threw me off with this question


initially is also the word interstitials there,


in the sense that usually interstitials are something


that are kind of between the content that you're looking for


and maybe kind of like what is actually loaded on a browser.


So if you go to a page, and instead of the product page,


it shows a big interstitial showing something else,


that's kind of the usual setup for interstitials.


And from our point of view, those kind of interstitials,


if they're intrusive interstitials in the sense


that they get in the way of the user actually interacting


with the page, then that would be


something we would consider a negative ranking factor.


So if it's really a case that when you go to your pages,


it just takes a bit, and then your product page pops up,


then I wouldn't call those interstitials.


Maybe use some other word for that,


because if you ask around in the help forums or elsewhere,


and you say, oh, my interstitials,


and I want to rank for my interstitials,


then probably a lot of people will be confused.


Seems like Google Images crawls some SVG files in SVG,


and then some it renders into PNG


while serving in the search results.


What is the reason for that?


Is there a way that we can dictate this behavior


for a Google Image crawler?


I don't know.


I wasn't aware of how this is happening.


So I'm not 100% sure what exactly you're referring to.


My understanding is that when it comes to images,


especially the vector formats like SVG, which don't always


have a well-defined size, what we do internally


is we convert that into a normal pixel image


so that we can treat it the same way as we can


treat other kinds of images.


That means for all of the normal processing


internally and all of that.


And also specifically with regards to the thumbnail images


that we can show so that we can scale it down


using the normal pixel scaling functions


and get it to the right size and get it


into an equal resolution to the other thumbnails that we show.


So probably that is something that is happening there.


And that's not something that you can easily change,


because we kind of have our system set up


to deal with pixel-based images.


And that's what we would do there.


With regards to kind of the next step from there,


the expanding of the image when you click on it in the image


search results, I don't know how that would be handled


with regards to SVGs or if we do some kind of in pixel-based


bigger preview or SVG-based bigger preview.


So I don't quite know how we would handle that there.


If you have any examples where this is causing problems,


I would love to see them.


So feel free to send me anything that you


run across in that regard, especially when you see that it


is causing weird problems that could be avoided by doing it


slightly differently.


Is there anything that we can do in terms of SEO


to improve user journey?


I think those are kind of separate topics.


So it's not something that you would do SEO


to improve user journey.


But rather, you have your user journeys


that you use to kind of analyze your products


and try to find the best approaches that you


can do there.


And then based on that, you would also


try to do some SEO to improve things in the search results.


So one is kind of improving things for the user,


and the other is kind of improving things


for search engines.


Sometimes if things line well, then there


is enough overlap that they work together.


But essentially, they're separate topics.


What is the best way to treat syndicated content on my site?


If the content is already in other sites, too,


and I have do I have to noindex my page,


or do I canonicalize to original source?


Do I nofollow all internal links of that page?


Yeah, good question.


I don't think we have exact guidelines


on syndicated content.


Generally, we do recommend using something like a rel canonical


to the original source.


I know that's not always possible in all cases.


So sometimes what can happen is we just


recognize that there is syndicated content


on a website, and then we essentially


try to rank that appropriately.


So if you're syndicating your content to other sites,


then it's theoretically possible that those other sites also


show up in the search results.


It's possible that maybe they even


show up above you in the search results,


depending on the situation.


So that's something to keep in mind


if you're syndicating content.


If you're hosting syndicated content on your website,


then that's kind of similar to keep in mind,


in the sense that most of the time,


we would try to show the original source.


And just because you have a syndicated version


of that content on your site as well


doesn't mean we will also show your website in the search


results.


So usually what I recommend there


is to make sure that you have significant, unique,


and compelling content of your own on your website.


So if you're using syndicated content


to kind of fill out additional facets of information


for your users, then that's perfectly fine.


I wouldn't expect to rank for those additional kind


of facets or filler content that you have there.


It can happen, but it's not something I would count on.


And instead, for the SEO side of things,


for the ranking side of things, I


would really make sure that you have


significant, unique content of your own,


so that when our systems look at your website,


they don't just see all of this content that everyone else has,


but rather they see a lot of additional value


that you provide that is not on the other sites as well.


When we want to rank for a specific topic on Google,


is it a good practice to also cover related topics?


For example, if we sell laptops and we want to rank for that,


is it useful to create posts like reviewing laptops,


introducing the best new laptops, those kind of things?


And if it's useful, then it doesn't have


to be done in any special way.


So I think this is always useful,


because what you're essentially doing is, on the one hand,


for search engines, you're kind of building out


your reputation of knowledge on that specific topic area


and for users as well.


It provides a little bit more context on kind of like why


they should trust you.


If they see that you have all of this knowledge


on this general topic area, and you show that,


and you kind of present that regularly,


then it makes it a lot easier for them


to trust you on something very specific


that you're also providing on your website.


So that's something where I think that always kind of makes


sense.


And for search engines as well, it's


something where if we can recognize that this website is


really good for this broader topic area,


then if someone is searching for that broader topic area,


we can try to show that website as well.


We don't have to purely focus on individual pages,


but we'll say, oh, it looks like you're


looking for a new laptop.


This website has a lot of information on various facets


around laptops.


How long should we wait for Search Console manual action


response?


It's been months in.


I avoided resubmitting, because that's not nice.


But do these ever get lost?


If we don't get new replies, what should we


be doing as a next step?


Depending on the type of manual action,


it can take quite a bit of time.


So in particular, I think the link-based manual actions


are things that can take quite a bit of time


to be reviewed properly.


And it can happen in some cases that it takes a few months.


So usually what happens is if you resubmit the reconsideration


request, then we will drop the second reconsideration


request because we think it's a duplicate.


The team internally will still be able to look at it.


And if you have additional information there,


that's perfectly fine.


If it's essentially just copy and paste of the same thing,


then I don't think that changes anything.


It's also not the case that you would have a negative effect


from resubmitting a reconsideration request.


So in particular, if you're not sure that you actually


sent the last one, then you're like, oh,


it's like someone on my team sent it.


And now I'm not sure if they actually sent it or not.


Then resubmitting it is perfectly fine.


It's not that there will be an additional penalty


for resubmitting the reconsideration request.


It's just when the team sees that one is still pending,


they'll focus on that pending one rather than


the additional ones.


If you don't see any response with regards


to manual actions, specifically around the link manual


actions, I would recommend maybe also checking


in with the help forums or checking in with other people


who have worked on link-based manual actions.


Because when it takes so long to reprocess like this,


it's something where you really want


to make sure that you have everything covered really well.


So that's something where if you're


seeing it taking a long time, you're like,


I don't know if I needed to do more


or needed to do something different,


then going to the help forums is a really good way


to get additional feedback from people.


And it's very likely that you'll go to the help forums


and they'll be like, oh, you should have submitted


these 500 other things.


And it's not the case that you have to do.


Whatever feedback comes back from the help forum,


but rather it's additional input to take in.


And you can review that and say, OK, I


will take into account maybe a part of this feedback


and maybe skip another part of this feedback.


Because the folks in the help forum


are very experienced with tons of topics,


but they don't have the absolute answers.


I don't think anyone really has that.


So I think it's great to get all of this feedback,


but you still have to judge it and weigh it out yourself,


as with anything on the internet.


Does PageSpeed Insights use the Googlebot?


I wonder, because when I'm looking


at the rendered screenshots in PageSpeed Insights based


on our site behavior, it looks like those


weren't rendered by Googlebot.


You're probably right.


So in particular, PageSpeed Insights


is something which is based on the Chrome setup.


So that's something where, as far as I know,


the server-based system that does the PageSpeed Insights


screenshots and calculations and metrics, all of that,


is just purely based on Chrome.


And Googlebot also uses Chrome to render pages,


but there are some unique aspects


with regards to Googlebot that don't


apply to PageSpeed Insights.


For example, robots.txt.


So when Google renders a page, it


has to comply with the robots.txt of all


of the embedded content there.


And if you have maybe a CSS file or a JavaScript file


blocked by robots.txt, we wouldn't


be able to process that from Google's point of view,


but PageSpeed Insights would still


be able to review that and show that.


So that's probably where you're seeing those differences.


I think the difference is more and more blurred


because Googlebot does use Chrome as well.


So it's very similar, but you can certainly


find situations where there are differences,


and you can certainly construct situations


where there are differences.


Like I mentioned, with robots.txt


is a really simple way to see those differences.


With regards to the way that we calculate speed for search,


though, we kind of, I guess, looking forward


at the core web vitals at the moment,


I don't really know offhand how we do that.


But with regard to core web vitals,


we use what users actually see.


So it's not the case that Googlebot renders a page very


quickly, and then it gets a good score,


or Chrome in PageSpeed Insights renders a page very quickly,


therefore it gets a good score.


But rather, we look at what users actually saw.


And I think that's really important


because that's kind of a measure of what the real world


performance is.


And all of these tools that kind of render it


in more of a lab environment, like Googlebot


when it renders a page, or PageSpeed Insights


when it renders a page, is something


that is almost more of a prediction


than an actual kind of measurement.


Because there are lots of assumptions in play there,


and whenever you run something like a rendering of a page


within a data center, then you have a very different setup


than the average user has.


With regards to network connectivity,


with regards to caches, and all of that,


it's just very different.


So these tools, when you run them,


and when you look at the measurements that they show,


you need to keep in mind this is more of a prediction


rather than an actual value that users will see.


I'm sorry.


I was going to ask a follow-up.


You continue.


Yeah.


And it's something that these tools also


try to build in, in the sense that they will say, well,


I run in a data center, but I will


act like I have a 3G phone and kind of a slow connection.


And they'll try to emulate that, but it's still very different


than actual users.


Go ahead.


Yeah, I'm sorry about that.


So in terms of assessing it, I was reading a site.


Seemed like it had a lot of ads.


So I decided, OK, let me see how this


is scored on PageSpeed Insights.


And it rendered a score with the circle of 21,


which was in the red, not very good.


But below that numerical and visual representation


was a sentence that read that based on field data,


the page passed in green, the assessment.


And then below that, there were these measurement bars


for cumulative layout shift, first input delay, et cetera.


And those were all mostly in the green.


So where's the disconnect, and what should one


be paying attention to, that first visual circle


or the fact that it says it passed the Core Web Vitals


assessment?


I need to keep in mind how the PageSpeed Insights looked.


I think it has that one overview score on top, right?


Yeah, I actually, is there a way to present?


Because I did a screenshot, and I


redacted the name of the website,


if that makes it easier.


So I think what happens in PageSpeed Insights is


we take the various metrics there,


and we try to calculate one single number out of that.


And sometimes that's useful to work on


or to give you a rough overview of what


the overall score would be.


But it all depends on how strongly you


weigh the individual factors.


So it can certainly be the case that overall,


when users see a page, it's pretty fast and sleek.


But when our systems test it, they're like, oh,


these are some theoretical problems


that could be causing issues.


And they'll calculate that into the score.


So I think the overall score is a really good way


to get a rough estimate.


And the actual field data is a really good way


to see what people actually see.


And usually, what I recommend is using those as a basis


to determine, should I be focusing on improving


the speed of a page or not?


And then use the lab testing tools out there


for determining the individual values


and for tweaking them with the work that you're doing.


So using the overall score and using the field data


as a way to determine, should I be doing something on this


or not?


And then using the lab data with the individual tools


to improve things and check that you're


going the right direction.


Because the issue is also the field data is delayed,


I think, by about 30 days.


So any changes that you make, and if you're


waiting for the field data to update,


it's always 30 days behind.


And if you're unsure that you're going in the right direction


or that you've improved things enough,


then waiting 30 days is kind of annoying.


OK, thank you.


Sure.


With regards to C-Core Web Vitals,


field data is going to be the one


to pay attention to, correct, in terms of ranking signals?


Or is it going to be added?


Yes.


It's the field data.


Yeah.


OK.


While we are in this Core Web Vital topics,


I have a small question in this regard.


Is that when this becomes a ranking signal, CLS


and all the other friends, is it going


to be page level or domain level?


Good question.


So essentially, what happens with the field data


is we don't have data points for every page.


So for the most part, we need to have groupings


of individual pages.


And depending on the amount of data


that we have, that can be a grouping of the whole website,


kind of the domain.


Or I think in the Chrome User Experience Report,


I use the origin, which would be the subdomain


and the protocol there.


So that would be kind of the overarching kind of grouping.


And if we have more data for individual parts of a website,


then we'll try to use that.


And I believe that's something you also


see in Search Console, where we'll show one URL


and say there's so many other pages that


are associated with that.


And that's kind of the grouping that we would use there.


Just why I ask this, we have this set of pages


that they are slow.


They exist for a different purpose


than our other pages on the site.


And these, we have a noindex on them.


But they are very slow.


And that's why we don't want it to be accounted for.


Yeah.


I don't think or I don't know for sure


how we would do things with a noindex there.


But it's not something you can easily determine ahead of time.


Will we see this as one website?


Or will we see it as different groupings there?


Sometimes with the Chrome User Experience Report data,


you can see, does Google have data points


for those noindex pages?


Does Google have data points for the other pages there?


And then you can kind of figure out, OK,


it can recognize that there are separate kinds of pages


and can treat them individually.


And if that's the case, then I don't see a problem with that.


If it's a smaller website where we just


don't have a lot of signals for the website,


then those noindex pages could be playing a role there


as well.


So my understanding, I'm not 100% sure.


But my understanding is that in the Chrome User Experience


Report data, we do include all kinds of pages


that users access.


So there's no specific kind of, will this page


be indexed like this or not, check that happens there.


Because the indexability is sometimes quite complex


with regards to canonicals and all of that.


So it's not trivial to determine kind of on the Chrome side


if this page will be indexed or not.


It might be the case that if a page has a clear noindex, then


even in Chrome, we would be able to recognize that.


But I'm not 100% sure if we actually do that.


SPEAKER 2


All right, thank you.


I'll follow up on Twitter.


Yeah, I would also check the Chrome User Experience Report


data.


I think you can download data into BigQuery.


And you can play with that a little bit


and figure out how is that happening for other sites,


for similar sites that kind of fall in the same category


as the site that you're working on.


Cool.


More questions from any of you.


SPEAKER 3


Yes, John.


Hi.


I suddenly see as well as it started all


at the mid of January.


I suddenly saw in Search Console that there


are a lot of old URLs popping up, especially


in the 404 subcategory under Excluded


and in the URL Inspection tool.


These old URLs are, for example, old HTTP versions of URLs.


And it's even old domains because the websites


were moved to a new domain like three years ago.


So my question is, why is that?


Should I be worried?


And if yes, how can I fix it?


So these are showing up as 404 errors, or?


These are showing up as 404 errors.


And for some URLs, if I use the URL Inspection tool,


they also show up as referrers in the URL Inspection tool.


OK.


I think if they're just shown as 404s,


I would completely ignore that.


What happens in our systems is that pages which are 404


are essentially still tracked on our side.


And from time to time, we will double


check to see that they still have a 404.


And that can happen, like that a site has changed significantly,


doesn't have these pages for years now,


and still, from time to time, our systems say,


well, we will double check those old URLs


and see if they still return 404.


And that's not a sign that anything


is stuck with those pages.


It's just our systems trying to make sure


that we're not missing anything from your website.


And if they show up as referring URLs in the URL Inspection


tool?


So how do you mean as referring URLs?


Like that they link to another page, or?


Yes, for example, I used the URL Inspection tool


on a URL that's still present.


And then in the URL Inspection tool,


you see where Google knows this page from.


And there it says, for example, it knows it from the site map.


And then there are four URLs listed below that.


And in that list, this list contains, for example,


an old HTTP version.


It contains the same file name, but from the old URL


of the website, which are all URLs that don't exist anymore.


So this is also something that makes me worry, or shouldn't


it?


That's completely normal, yeah.


That's something where I am not 100% sure which data we show


there in Search Console.


But we have a concept of the first seen location of a link


to a specific page.


And we might have seen that URL from that page at some point


way in the past.


And if that page doesn't exist anymore,


it's still like, this is where we first saw it.


OK, so it's basically just make sure


that if the original page doesn't exist anymore,


it returns a proper 404.


If it's redirected, then make sure it's a proper redirect.


And in other cases, just ignore it if you get the correct one.


Yeah, exactly.


Yeah.


So usually, if you have an older website, then over the years,


you will collect more and more of these 404 pages.


And our system is, even when they rarely check a 404 page,


it's just like the amount of URLs


that could be returning 404 grows.


So if you look at your server statistics


and you look at what Googlebot is requesting,


then it can look like, oh, Google


is spending so much time on 404s.


But for us, it's just checking it maybe once a year or so.


But because we have so many that we check once a year,


it overall looks like a lot.


But that's just what, yeah.


Yeah, sorry.


This website is like 10 years old.


And last question for that, because the websites


I'm talking about, they were also moved to new domains.


We used the address change tool.


And so basically, just make sure that the old domain still


redirects to the new website.


This would be then the perfect, good setup.


And we shouldn't worry about anything further.


Yeah.


That sounds great.


One place where people also get confused with that,


which is kind of similar, I guess, with old URLs,


is that when we recognize that pages have moved,


we still have some association of the old location.


So we will know that this page on the new website


used to be located as a page on the old website in some sense.


So if in the search results you do a site query


for the old domain, then even after a couple of years,


you'll still see a lot of URLs that are shown there.


And it's not the case that we have them indexed there.


But rather, we know they used to be there.


And it looks like a user is explicitly


looking for the old location.


So we'll show them.


So if you look at the cached version of the page


in a case like that, then you'll see that actually it


shows a new domain.


So it's a little bit confusing if you look at it like that.


But essentially, it should be working properly.


OK, thank you.


Sure.


So I have a related question.


For example, if you said the proper 301s redirects.


And I was just trying to understand the relation


of backlinks, only the ones if Google


has the history of the old links.


Is it possible that it passes some sort of page rank


to new URLs that we set 301 redirects for?


For example, we have a site with the backlinks.


And we decided to change the URL with the proper 301s.


And backlinks are always there.


We normally change a few of those.


But they are still there.


So if you say Google has some sort of history there,


so would it be possible that it passes some sort of rank juice


or page rank juice to new URLs?


Yes.


So essentially, what happens there


is we will have the old URL on your website that


has some signals from the links that go to the old URL.


And we have the new URL on your website.


And with a redirect, you're basically telling us


these are equivalent.


And you probably prefer the new URL to be shown.


So what we will do is we will put both of those URLs


from your website into a group and say


this is kind of a group of URLs that


have kind of collected signals.


And then with the redirect, we will pick usually


the destination URL and say this is the canonical


for that group.


And the canonical page will then kind of


inherit all of the signals that go to that group.


So if there are links to the old version of a page,


if there are links to a copy of that page, then all of that


will be kind of combined together


in the canonical version.


So that's something that kind of gets passed on there.


Specifically, when you're talking about site moves,


we still recommend making sure that you, as much as possible,


can update the old links anyway.


Because what happens there is we will put those URLs


in the same group, kind of like I mentioned.


But we use various factors that determine which of these URLs


is the right one to show, which one is the canonical one.


And redirect is one factor.


But also links are another factor.


So if all of the links, like internal and external links,


go to the old version of your URL


and you redirect to a new version,


we might take the old version of the URL to show in search.


So that's something kind of to keep in mind,


that if you want to move everything to a new URL,


then make sure that everything is aligned with the new URL.


So the redirect, the sitemap files, the internal linking,


as much as possible, also the external linking,


so that everything just fits together with that new kind


of URL that you want.


Yeah.


Thanks for this question.


I have another question.


You know, most of the tools, the SEO checkup tools,


they pop up in the warning, which


says, low text to HTML ratio, which


means code is more than the original text.


Would it be something we need to worry about?


Or is it OK for Google to pick the right text?


We don't have a notion of text to HTML ratio for search.


So that's something where I think a lot of these tools


are able to calculate this, and they think, oh, it's


worthwhile showing.


But it's not an SEO ranking factor kind of thing.


There are two places where it could play a role.


On the one hand, with regards to speed,


so if you have a lot of HTML and you have very little text,


then obviously we have to load a lot of content


to display the page.


So that's one small factor.


The other one is with regards to extreme situations,


where you have a lot and lot of HTML and very little text.


We have limits with regards to what the maximum page size is


that we would download for an HTML page.


And I think that's in the order of, I don't know,


hundreds of megabytes, something like that.


So if you have an HTML page that has hundreds of megabytes


of HTML and very little text in it, then yes,


that could be playing a role.


But that's something that I suspect is extremely rare.


And if you have that problem, then that's


like a bigger problem than just like, oh, it's


not perfect HTML to text ratio.


Perfect, yeah, I got that, thank you.


Probably later today, which will also be next Friday, but evening


European time, more for the American folks.


So Michael doesn't have to get up in the middle of the night.


I don't know how he does it, but thank you.


Cool, all right, let me just pause here


Cheese, Web Workers, universal search, and more!

Hi, everyone, and welcome to another episode of the Search


Off the Record podcast.


Our plan for this series is to talk a bit about what's


happening at Google Search, how things work behind the scenes,


and who knows, maybe have some fun along the way.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


And I'm joined for this episode by Martin and Gary, who are


also on the Search Relations team.


Hi, guys.


Hi, John.


Guten tag, meine Damen und Herren.


Woo-hoo.


So cool to have you two here again,


which is kind of like every podcast, I guess.


But anyway, I looked at the notes,


and I saw we've done a bit over 20 of these episodes


so far, which is pretty cool.


What do you think?


Yeah, I'm very happy to see that this is working out well


and that people enjoy listening to these as much as we


enjoy recording these, I think.


Except Gary.


I think Gary doesn't enjoy this.


No.


Yeah, that's what I thought.


OK, fine.


He doesn't like nice things.


That's the problem.


So how should we celebrate the 21st episode of the podcast?


What do people do?


With a big gathering.


We could cut this short.


Cut it short?


No, never.


Why?


Oh, Gary, come on.


Don't be such a party pooper.


So what were your favorite parts so far in the series?


Yeah, Gary, what were they?


I really liked the endings of the recordings.


Because you speak in a different language every time?


No, because they end.


Yeah.


I actually really enjoy your journey


taking us through search from beginning to end.


That's kind of cool.


That is cool.


OK.


I mean, the endings are nice.


Because then you had a nice episode until then.


That's true.


It's kind of like dessert, right?


It's like you've had this really nice meal,


all of this good stuff.


You learn something along the way.


And then you have, I don't know, some cheese.


And then it's done.


And you're like, oh, this ending was good.


Hey, John, do you like cheese?


I like cheese.


I have it on Twitter, right?


It's recorded.


I mean, it's not that I put it on Twitter.


But it's on my Twitter.


It's on the record, so to say.


You want to say it's on the record.


On the record.


Well, this is the off the record podcast.


So nobody can count it against me, I guess.


I don't know.


How does that actually work?


Well, but you have it on Twitter that you love cheese.


Well, yeah.


I don't know how that got there.


It's so weird.


You remember the strange cheese we had at the cheese master


class thing that we did a couple of years back, the Bell Park


Knoller?


I have it now.


It's amazing.


Wow.


OK.


I finally found a place that sells it nearby.


So that's pretty cool.


And actually, it's literally across the street.


So I didn't expect it to, you know, that's really nice.


So you like cheese?


I do like cheese.


After that master class, I got what is called the blue cheese.


It also won some award.


Jersey blue.


Yeah.


The blue cheese.


And it's so amazing.


And you can deep fry it, and then it's even more amazing.


What, you deep fry cheese?


Yeah, you bread it, and then you deep fry it.


It's amazing.


I'm telling you, it's amazing.


You hit it with some pepper.


It's fantastic.


We should have a cheese podcast.


This seems to be bringing your attention in quite well.


It is relevant.


It's cooking.


Cooking.


So talking about cooking, it's like,


should we have more guests?


Yeah.


I think it makes sense.


What do you guys think about getting someone


external on the podcast as well, not just like internal folks?


I have candidates.


No.


Would you mind spilling the beans or no?


Surprise.


I mean, I know a bunch of people I really, really


like to talk to.


Not you, Martin.


Sorry.


And I meant external people.


And I would love to chat with them again on a podcast.


Like, for example, I don't know, Aleto Solis, for example.


I forgot her company's name, but she's


one of the most prominent SEOs externally, I think.


Jennifer Slag, she's brilliant.


And our interviews at those in-person conferences


were one of the few ones where I was actually sweating on stage


because the questions were so hard to get out of.


Eric Enger, I really like talking to him,


very smart guy.


Eric is great.


Mark Trapp-Hagan, super interesting dude.


Yeah.


I have a long list.


Nice.


OK.


That sounds pretty interesting.


Or should we add more people internally as well?


No.


Like, from different parts of Google?


Or how do you see it?


I would love to have David Price, one of our lawyers


or legal counsel, I don't know, like, what's


the proper term, on the podcast.


Because I'm pretty sure he sees interesting things happening,


no?


That he can't talk about.


I mean, he can talk about a few things, I'm sure.


And I'm pretty sure that the things that he can talk about


is probably interesting.


Or we could add someone or invite


someone who's more local, someone like Aurora, perhaps.


Yeah.


From the, I don't know, she's on the Trust and Safety team,


I think, right?


I think it is.


I think it's ads policies or publisher policies


or something, right?


I mean, she's been doing the Sustainable Monetized Website


series on her channel, which is pretty cool.


So it's almost like, maybe we should figure that out first.


Yeah, I mean, she's in reach.


We had Maria already.


Who else is local?


Someone from the Assistant team, maybe?


I don't know.


Is like voice search still a thing?


People haven't been asking me about it anymore for a while


now.


What's voice search?


Oh, that's a surprise.


Do you search with voice?


No.


No?


I mean, like now that you're in a room by yourself,


you can talk to your phone and you don't get any awkward looks,


right?


So is it easier?


I'm a fast typer.


I type.


OK.


I mean, I'm a developer.


What do you expect me to say?


Like, I type quickly.


And that comes natural to me at this point.


You're like a machine interface, Martin.


I'm like a statically typed machine.


Oh my gosh.


Gary, what about you?


Do you ever do voice searches?


The short answer is no.


The long answer is that I tried and still no.


I don't have voice enabled.


Like, for example, on my phone, I disable Siri right away


as soon as I set up the phone.


I just disable it.


On the TV, I have, I think it's the Google Assistant that's


enabled.


And I couldn't figure out how to turn it off,


unless I haven't spent all that much time trying.


But the few things I tried didn't work out all too well,


probably because of my accent, perhaps.


You, an accent, no.


But your German is so great.


Yeah, about that.


Did you know that the Google Assistant doesn't necessarily


like Swiss German?


I can imagine that.


It's like, who really likes Swiss German?


Oh, it's a beautiful language.


Come on.


I love Swiss German.


I love Swiss German way more than the whole German.


OK.


Swiss German is so melodious.


Yeah.


But could you imagine if more people started


searching by voice, and all the people in Switzerland


started using Swiss German?


Like how that would change the SEO world?


Aren't there like 40 different sub dialects in Swiss German?


Because I think every village speaks slightly varied.


So you'd have to set up hreflang for all of those, right?


Could you imagine?


Try to imagine.


Like even if you go down to Bern, for example,


understanding their Swiss German is tough, to say the least.


Yeah, no.


Versus the Zürichl one.


Or you go down to Graubünden, for example,


and try to understand that when you are coming from Berlin,


or Hamburg, or whatever.


It's tough, even for locals and German speakers.


Let's not talk about, like what if you go up


on top of a mountain and you find a shepherd, for example,


and you try to talk to that person, you will fail.


Like even if you are born in Zurich.


OK.


So you're saying like voice search in the mountains


is a bad idea?


I mean, you have 4G reception in Switzerland on the mountain.


So you could try.


Sure.


But it's the mountain.


So you have echo, echo, echo.


I think we have echo canceling.


That should be OK.


On this episode of Swiss languages.


Yeah, we should switch more to kind of the web again.


Maybe invite some web workers.


What do you think?


Did you just?


Yes, yes, you did.


Oh my.


Yeah, this is a fun one.


Back in 2018, when I joined, I did a bunch of tests


around our JavaScript capabilities.


And one of the things that I tested was web workers.


And web workers are basically just a way


to have like multi-threaded code on the web


and offload some stuff from the main thread.


I'll explain all of these lovely words in a moment.


I see big eyes here.


And I noticed that in rendering, web workers don't really


work the way that you would expect them to work.


And that's normally fine because very few people are using them.


And even fewer people are using them


for content-related things.


But Giacomo Cecchini, I hope I didn't butcher your name,


Giacomo, if you're listening to this,


recently tweeted out that specific question.


Since 2018, no one has caught up on this.


No one has noticed that behavior.


And he ran a few tests, apparently.


And he noticed that the behavior is


different from what you would expect


and asked me a question about it.


And I'm like, oh, here we go.


This is interesting.


Because I talked to the rendering team,


and the rendering team is like, yeah,


but is anyone really using it for anything


where Googlebot would need to run the web worker properly?


And I'm like, I don't think so.


But I would love to hear from the community


if they have considered using web workers


and then not done it because they wanted to do something


that involves the content.


And they found out that it doesn't work super well


in rendering.


Because I wonder if it really is a problem.


I don't know, to be honest.


So I guess web worker is something


you would do more on an interactive level?


Like, you click a button, and it does some fancy calculation


and then brings the results back?


Yeah.


Yeah, that's pretty much the traditional use,


where the problem or the challenge on the web


is that JavaScript is a single thread of execution.


So if you have a website with lots of cool things on it


and then a button that does some long-running task, whatever


that is, it could be some sort of calculation that just takes


a long time, for instance, or it needs


to do something on the network.


Network is kind of fine because that kind of happens


in the background naturally.


But when you do calculations, that kind of


is running on the same process or on the same thread


of execution if you want to with everything else that


happens on the page when you interact with it.


So scrolling, the code that runs the calculations, any buttons,


any link clicks, anything that happens on the page


is kind of blocked once this long-running task starts.


So if you are having some very heavy calculation,


like, I don't know, you have an input box,


and you can type and give me the 100th prime number.


Prime number calculations take a while.


So if you click that, it might take 10 seconds


to get to the 100th prime number.


During these 10 seconds, you can't click on anything.


You can't scroll the page.


You can't do anything on the page.


That's a challenge.


So why would you do this with a web worker


and not just send it to the server


and have the server do the calculation?


Because it's like a big server with lots of CPU.


That is true.


But sometimes you might not want to do that.


Or sometimes you might have to make it work offline as well,


which we can do now thanks to a specific kind of web worker


called the service worker.


If you can push it to the server, by all means,


do, because that's the easiest thing you can potentially do.


But if you can't, because you can't rely on the server


to be there, on the server to be available,


on the network to be available, on the network to be fast,


or if it's just like a lot of data


needs to go into the calculation,


then uploading the data to the server


can take really, really long.


Let's say you want to do some sort of image processing.


There's like scoosh.app, where you can upload an image.


And it doesn't really upload it to the server.


It keeps it in your browser locally.


And then you can try out different image encodings


and compare them.


If you were doing that with a server,


A, you would have to have a pretty powerful server


to do that for all the users that you


may have on the application at the same time.


And the other thing is you need to upload the image


and then download the image.


And images are big usually.


So it's nice to do that on your device


so that the network does not really play a role here.


But again, image data conversion takes a while.


So instead of running this conversion on the same thread,


blocking the app and making it unresponsive


for a couple of seconds, they are doing it in the background


with a web worker.


Cool.


And a service worker is essentially the same thing?


Or is it like, how does that fit in?


That's like a PWA thing, right?


Yeah.


A service worker is basically a very specific kind


of web worker.


So web workers are just scripts that


can run in a separate environment,


basically as if they were running


on a separate computer kind of inside the browser.


But they only run when the website that starts them


is actually active.


Whereas a service worker is the same thing.


It is also a script that runs in its own environment.


But it can be triggered by the browser in certain conditions.


So for instance, whenever the website makes a network


request, the service worker is triggered and asked


what should happen with that.


Another thing is if your phone receives a push notification


and the service worker has subscribed to them,


then the service worker would be woken up to process this push


notification.


So it is a specific kind of web worker,


but it uses the same mechanisms as web workers.


OK.


OK, cool.


Yeah, the network request side, that kind of makes sense.


Because that way, you could make it


so that it kind of works offline and that it caches


a lot of these things, right?


I guess that's where it fits into the PWA side of things.


Yeah.


Because it allows us to be offline capable and push


notifications and background fetches


and all that kind of cool stuff.


And where would this come into play


with pages for indexing?


I imagine most of these web workers


would be kind of like these interactive things, where,


like you mentioned, the Squoosh app, where you upload an image


and then it does some processing and brings the results back.


How might it play in with normal indexing?


Because you probably, I guess that


would be something that would have to work while the page is


initially loading?


That's a really good question.


And the one thing I learned in my career as a developer


and now as a developer advocate is that developers' creativity


is infinite.


So people come up with fantastic uses of technology


that you do not anticipate.


So for instance, you could use web workers to basically,


your server would give us a skeleton and placeholder


version of the content that kind of just takes up space.


And then the web worker would do some whatever heavy lifting


needs to be done in the background with lots of API


calls and stuff happening.


And then eventually, once it has the content already,


it passes it over to the main thread.


That's one way of reducing main thread work.


And I think it's one of the things that does come up


for time to interact or first input delay, which


might become more important because of the COVID vitals.


But as I said, I can only guess what developers out there


have built. I could imagine things like, oh,


the content is somehow encrypted and needs


to be decrypted on the client's device or something like that.


But then I would say, yeah, but if the key has


to be sent to the client, why encrypt in the first place?


Nonetheless, I've seen people do this kind of stuff


where crypto was kind of just like the black magic


that they needed to keep people calm.


I'm intrigued.


I would actually really like to hear out there


if people are struggling with this,


if people for SEO reasons had to not use web


workers for something.


And if so, what that was.


Because I'm just intrigued what kind of creativity


is out there that might need our help.


I guess it's tricky to recognize if we ignore it for rendering,


then we don't really have a log of people


who are trying to do it.


That's true.


Yeah.


Cool.


I guess you could just write your content in Swiss-German,


and then you wouldn't have to encrypt it and decrypt it.


It's like the simple solution is like,


why do all of this magic JavaScript?


It's so complicated.


Why JavaScript?


Why?


Because JavaScript, that's why.


Does any of this play in with promises?


That's another one of those JavaScript constructs


where it's like you wait for something to be finished.


Is that a connection to these web workers,


or is that totally unrelated?


It's somewhat related, because both of it


are ways of tackling asynchronous code.


So normally, code is synchronous.


So you say like instruction one, and then instruction two,


and then instruction three.


And maybe if some condition is met,


then we do instruction two and three again until it's not met,


then we do instruction four and five, whatever.


With JavaScript, the way it works


is that with a lot of stuff, you are kind of basically


scheduling a task, and that task is eventually


run when there's space available to run that task.


So for instance, a click isn't immediately executed.


If I have like an on-click handler for a button that


doesn't run asynchronously, so it's not that my code stops


until the button is clicked and then it does something,


it basically says like, when the button is clicked,


run this function.


So what happens in the browser, the button is clicked,


and the browser goes like, OK, so I'll


add the code that is on this on-click handler to a queue


where all the scrolling or the other clicking


is happening as well.


And then eventually, the time has


come to run that code for the on-click handler.


So that's asynchronous.


And then there's different ways of doing this.


There's promises, where you say like, hey, when that happens,


run this code.


There's also callbacks.


It's another way of saying, hey, when that happens,


But all of this still happens in the same thread.


So the same, like all this is sharing the same execution


environment, the same processor, if you want.


Whereas the Web Worker, that is a completely separate


environment that is completely detached


from the rest of the code.


And it communicates with your main thread,


with the main line of execution through messages.


So you send messages to and from.


So it's somewhat related, but it's not the same thing.


Promises run in the same environment.


Workers run in a separate environment.


OK, so it's like with JavaScript,


you write JavaScript, which is human readable,


at least developer readable, let's say.


So this text then needs to be translated into machine


readable instructions.


And then these machine readable instructions


are being executed.


That's great for normal amounts of JavaScript,


but for a bunch of stuff, it would


be cool to kind of have a way to skip this first part,


to have the human written code and the human readable code


translated straight into this machine readable format


and then executed.


And that's what WebAssembly is.


That's where it came from.


The original idea was, hey, we can actually speed things up


by skipping the first part or making it as quick as possible.


So browsers have now implemented a way


to basically give us a preinterpreted,


a pre-translated version of the human readable JavaScript.


It's a machine readable version of that.


And then that can execute faster.


And that brought us a really, really cool thing,


which is the idea of taking something that


is in a programming language that traditionally does not


run on the web, like C++ or C code or Rust code,


and then basically make it into this machine readable


JavaScript form and then run that.


And that's exactly what Squoosh did.


So for instance, the code to transform an image into JPEG,


that is C code normally that you would run on your machine.


It doesn't really run in the browser.


So they made a WebAssembly version of it.


And in order to not have the website block entirely,


because if you have an image that's, say,


4,096 by 4,096 pixels, that's a whole lot of pixels.


It sounds large, but it actually isn't.


Or actually, make a different example.


If you look at a full screen image for a 1080p screen,


then we have, and I'm actually typing this into a calculator


because my math isn't that great,


we have to process 2 million pixels, each pixel being


at least 3 bytes large.


That's a lot of data that you need to process.


And that would mean that if I would


do that in a WebAssembly or JavaScript environment


just as part of the page, it would take a few,


maybe like two seconds.


But in these two seconds, it wouldn't


respond to any scrolls, any clicks, anything


that I do with the page.


So they are running their WebAssembly in a Web Worker.


So they basically say, hi, here is the data.


Here are the, I don't know, 3 megabytes of image data


that we have, or 2 megabytes of image data that we have.


Please make that into a JPEG.


And then they throw that over.


And the website is now available to respond


to clicks and everything.


The Web Worker does the work, does the WebAssembly execution


for the C code that has been compiled into WebAssembly


to actually make it JPEG data.


And then it sends that JPEG data back.


And then we can display that in the image tag.


Ta-da.


Wow.


OK.


It all fits together.


Seems like a lot of works.


And you're saying Web Workers currently


don't work for rendering?


They kind of do.


I mean, we execute them.


We register them.


It's just that because they are in a different environment,


we are not very good at picking up


the events that happen in them.


So for instance, if you have a Web Worker that


gets sent a message and then immediately responds back,


that works generally.


But if you have a Web Worker that fetches something


from the network, then we don't really wait for the Web Worker


to actually get the network response


and send the response back to the main thread.


So you see really funny things happening in Web Workers


when you execute them in rendering.


Yeah.


So what about Promises and Wasm?


Do they work?


Like if you have them in your normal thread?


They do work.


I think we are waiting for the task queue to be empty.


And Promises adds something to the task queue of the main


thread.


And so as long as it happens in the main thread,


you will be fine.


So cool.


OK.


Well, I didn't understand anything out of that.


What?


Come on.


That can't be true.


It's JavaScript, Gary.


It's the language of the future, apart from Swiss German.


I don't like the future.


Oh.


Swiss German is the encryption of the future.


I think someone should make a programming language


using Swiss German commands.


I think that would be super cool.


Do you remember the time when someone had this brilliant idea


that I don't remember which programming language should


have German instructions?


Oh, that's the VBScript, Visual Basic Script?


Yeah.


That was like that as well, right?


Or was that just like in Excel or something,


like if you ran it there?


I think it was VBScript.


And that went well.


All right.


Well, I mean, the thing that always annoyed me there


is you could never copy an example from somewhere


on the web and just make it work because you


had to translate all of the commands as well.


But I'm thinking of a programming language that


is Swiss German by default and doesn't have local versions.


Interesting.


I know that there was this if PHP were British article ones.


That was pretty hilarious.


Instead of like if else, it's per chance and otherwise,


I think.


And instead of switch, it's what about.


Yeah.


And try catch becomes would you mind and actually I do mind.


And it's hilarious.


OK.


See, something like that just was Swiss German.


I think that would be perfect.


It's like all of these computer people that just speak English.


And it's like they should see what


it's like to actually have to learn something new again.


Wonderful.


I was writing some C++ code internally.


And I wanted an example for something very specific.


And I found this blog on the internet which had, well,


it promised that I would find the example there.


But it looked like someone ran perhaps grammarly or something


like that on the code as well.


So a bunch of things were corrected.


Like I don't even know.


Like if statements, for example, they


were expanded to sound more human-like.


Like the parentheses, for example, were dropped.


And then if whatever, blah, blah, blah, this, then


it was like, ah, this, what?


Yeah.


I just noticed that sometimes when you have quotes in code,


depending on how people put the code samples together,


it'll be like those weird smart quotes.


And you copy and paste it and nothing works.


It's like, ah.


And then your compiler is like, nope, nope, nope, nope, nope.


I have never seen this symbol before in my life.


And it's like, come on.


It's a quote.


Do smart for me.


Sorry.


If only there were universal compilers.


Double quotes or single quotes?


Yeah, that's confusing too.


It's like in some programming languages, they're the same.


And in others, they're not the same.


It's like, why can't they make up their mind?


Oh.


What is it?


Shell script.


I love shell script for that reason.


It's like you used a double quote here.


I can't interpret whatever you put inside the double quote.


OK, here's a single quote.


OK, now I will execute it.


But you put this other character inside,


which you forgot to escape.


Put it in double quotes.


Yeah, if only the error messages were that clear.


Usually it's just like, oh, deleted all your files.