we end up maybe even going to a situation


English Google SEO office-hours from September 17, 2021

where we take the whole website as one group.


So that's kind of the one thing.


The other thing is the data that we


collect is based on field data.


You see that in Search Console as well,


which means it's not so much that we would take


the average of individual pages and just average them


by number of pages, but rather what would happen in practice


is that it's more of a traffic-weighted average,


in the sense that some pages will have a lot more traffic


and we'll have more data there, and other pages


will have less traffic, and we won't have as much data there.


So that might be something where you're seeing


these kind of differences.


If a lot of people are going to your home page


and not so many to individual products,


then it might be that that home page is


weighted a little bit higher just because we


have more data there.


So that's kind of the direction I would go there.


And in practice, that means instead


of focusing so much on individual pages,


I would tend to look at things like your Google Analytics


or other analytics that you have to figure out


which pages or which page types are getting a lot of traffic.


And then by optimizing those pages,


you're essentially trying to improve the user experience


for the users on your website.


And that's something that we would try to pick up


for the Core Web Vital score in there.


So essentially, less of averaging


across the number of pages and more averaging


across the traffic of what people actually see when


they come to your website.


And I think that also goes into the second question,


like what logic does Google use to group these pages?


Essentially, first of all, we have to have data.


And if we don't have field data that we can use there,


then we can't kind of group pages in a more fine-grained


way.


We're having multiple issues on our site


where Search Console says we're ranking for keywords.


But when we check the rankings, we don't rank at all.


What might be the cause of this, and which is right?


So Search Console does not invent rankings.


It's not a theoretical ranking report


that we show in Search Console.


It is based on what people actually saw.


So from that point of view, the data


that you see in Search Console, when it's there,


it is based on what was actually visible in the search results.


However, sometimes the search results


can be really hard to figure out in terms of where


your page is being shown.


And sometimes these things change over time.


So usually, what I try to do when


I look at things like our blog and wonder,


why does this page get so much traffic


for this weird keyword, is I'll try to figure out


what the most specific setting is where this pattern is


visible in the report.


That means picking out the individual country where


it's most visible, maybe the type of page


where it's most visible, and the type of search result


where it's most visible, and then also looking at the graph


to see, is this something that was maybe a one-time spike,


or is this something that is consistently at that level?


And if it was a one-time spike, then it


might be that I can't just reproduce it anymore.


If it's consistently at that level,


then it feels like there's a chance


that if I search with those settings,


I could see that as well.


It's not always guaranteed, but there's at least


a small chance there.


And in particular, also, when you're


looking at the normal web search results in the performance


report, we also include things like the images one box


or the knowledge panel on the side and the maps one box,


for example, if that's visible somewhere.


All of these things can count as impressions as well.


So you really need to take a look at the whole page.


And especially with the images one box,


it's sometimes a little bit surprising


when you finally find a link to your site in there.


But from our point of view, that's


also an impression on the search results page.


The other thing that can happen is that sometimes the search


results are very personalized.


And it can happen that for a query that has usually


a fairly high search volume, that maybe


this really small portion of those people


see something that would show your website.


And that's usually a little bit harder to try to figure out.


But you can kind of guess at that.


If you look at the queries and you think,


oh, this is a very popular query probably,


but my website is getting very little and very few impressions


for this query, then it's possible


that the majority of the people who are searching for this


actually don't see your website.


And only a very small portion of people would see your website.


And then that could be the case where maybe there's


something happening with personalization or something


else that's playing a role here where suddenly these links are


also shown.


So those are kind of the different ways


I would try to narrow that down.


Let's see.


With the event of the MUM algorithm,


which is kind of a machine learning algorithm


that we use in Search now, will search results


be a response to multiple sources?


I mean, that is when the user searches for a topic


and the answers are selected from multiple sources


and provided to the user as a package.


We think that competition in the future


will be kind of an interaction between competitors.


Together, they can meet the needs of a searcher.


Sites focus on services that they can provide better.


Several competitors can meet the needs of the searchers.


The user then needs a portfolio that


is completed by several sites that


kind of compete for that area.


I don't know.


Maybe.


Maybe that will happen at some point.


We do have a notion of trying to provide


a diverse set of options in the search results


where if we can tell that there are maybe


things like very strong or different opinions


on a specific topic and it's a question of what opinions are


there out there, then it can make sense


to provide something like a diverse set of results


that cover different angles for that topic.


I don't think that applies to most queries,


but sometimes that's something that we


do try to take into account.


With all of these machine learning algorithms,


I think it's always a little bit tricky because we tend to,


I don't know, show them more for the user side


in our presentations.


And then turning that around and saying, well,


how can I optimize for this machine learning algorithm?


That's always a little bit trickier.


End of September, we have another search on event lined


up.


And they also mentioned something in the announcement


around machine learning, artificial intelligence.


I could imagine that there might be something similar to being


mentioned there as well.


I don't have any insight.


But it always feels like that's a time where we kind of show


off the new research and new technologies that


are being done.


But it's very often or very easy to take those announcements


that are made for the user side and try to turn them around


and say, oh, as an SEO, that means


I have to do things like this.


And often, that kind of inverse relationship


is not so straightforward.


How does Google treat subdomains versus folders?


Is authority passed through the subdomains?


Oh my gosh.


I don't know if someone is trying to troll us again.


From our point of view, when we talk with the search quality


team, they say subdomains and subdirectories


are essentially equivalent.


You can put your content however you want.


Some people in the SEO world have very strong opinions.


And if we say it doesn't matter and someone else says,


you should do it like this and you


want to follow their advice, then it's


like, go ahead and do that.


Because from our point of view, we say it doesn't matter.


I think there are a few aspects that


play a role there which are less around SEO


but more around things like reporting.


How easy is it to set these sites up?


Do you want to track their performance separately


on separate host names or together in one host name?


Those kind of things.


With some kinds of websites, it's


also something where we might treat things on a subdomain


slightly differently because we think maybe this


is more like a separate website versus all


of the same website.


So those things can all play a role there.


In practice, what I would say is try


to focus on your infrastructure first


and see what makes sense for you and then work on that.


And if you're working together with an SEO who


has a very strong opinion and everyone else is like,


whatever you want, then I don't mind


if you follow their opinion either because that should work


too.


Let's see.


When doing a site migration, on the day we pull the trigger,


there is a robots.txt block on both domains.


We do a 302 temporary redirect and switch to a 301 later on,


or we serve a 503 HTTP status code


site-wide for a day or a few hours while the developers try


to fix whatever is broken.


So from our point of view, these are all separate situations.


And it's not the case that we would say, well,


this is a site move with this variation.


But rather, if you're blocking things, if things are broken,


then we would, first of all, see that


as something that is broken.


And if at a later stage we see there are actually redirects,


then we would say, well, now the site is redirecting.


And we would treat those as separate states.


So if on the day you want to do the site move,


something breaks and everything is broken on your server,


then we would just see, well, everything


is broken on the server.


We wouldn't know that your intent was to do a site move


because we would just see that everything is broken.


So from that point of view, I would


treat these as separate states.


And of course, try to fix any broken state


as quickly as you can.


And essentially, move to the migration then as quickly


as you can after that.


Oh, wow.


Still so many more questions.


OK.


Maybe I'll switch to a few more live questions here.


And I saw some in the chat as well.


Maybe I'll just grab those quickly.


And I have a bit more time afterwards as well.


And we can go through more things live as well.


Gambling website promotion policy for publishers.


I don't know what the policies are from the publisher side


if you're talking about the ad side of things.


From the search side of things, SEO-wise, publish


whatever you want.


Would you mind taking a look at my website at the end?


OK, that sounds like something for the end.


And let's see.


How do I find the raised hands again?


Oh my gosh.


Where is it?


This.


I think you're next.


Hi, John.


I have just two questions really quick.


One submitted on YouTube.


Is it worth looking at old news and removing, no indexing,


is this allowing it?


It's a site with content from 10 plus years old.


Does it something like do some to the quality of the page


overall or crawl budget?


It's a page with 3 million pages on it.


So does it do something to that?


I don't think you would get a lot about you


out of removing just old news.


So it's also not something I would recommend


to news websites because sometimes all the information


is still useful.


So from that point of view, I wouldn't do this for SEO.


If there are reasons why you want to remove content


or put it into an archive section on your website


for usability reasons or for maintenance or whatever,


that's something that you can definitely do.


But I wouldn't just blindly remove old content


because it's old.


OK, clear.


Thanks.


And another question is, I was just really curious,


is about Googlebot.


I was working on my personal site a few months ago.


And the very first thing as an SEO idea


is verified Google Search Console and Google Analytics


and all that stuff.


So I was developing for a few months.


And when I was ready to go live and do a crawl


request for the home page in Search Console,


I really saw that Googlebot tried


to crawl pages in the crawl stats.


And I was wondering, how does that happen?


And why does it happen?


Because it's a new domain.


There are no links to it.


And I was just wondering, how does Googlebot still


find this domain and tries to crawl it?


I think it's something that we do when you verify


a website in Search Console, where we kind of say,


well, it looks like you're trying


to get this website into search.


We don't have any information on it.


We will take a look.


And I don't think it's something that we do for policy reasons


or anything.


It's basically just, oh, it looks


like you're trying to go into search.


We will help you so that you don't


have to do every step yourself.


SPEAKER 2


Thanks.


Gaston.


So I don't know how to word this question.


So the thing is, we have a sitemap with, let's say,


200 most important pages for our site.


We have this sitemap is static.


And it's been the same sitemap for three years, let's say.


But we have one page that has been,


the last time that was crawled was two years ago.


And Google, what does it mean to recrawl that page?


We added links, internal links.


We added that page to another sitemap.


We added external links.


We did a bunch of things.


But we don't get, and also, of course,


requesting the indexation from Search Console.


We don't know what's going on.


If you can give us some insights of how we should approach that.


Because we are certain that the sitemap is being crawled.


Because Search Console says that.


And we are also seeing that in our log files.


Yeah.


So you added it to the sitemap and to internal links.


And it's not being crawled at all?


Or is it just not being indexed?


It is indexed.


But it's not being recrawled.


So it has, on Google search, it has the old information.


It hasn't updated.


It hasn't updated the titles, the meta description,


and all that.


So yeah, we are missing.


OK.


Did you try to submit it separately?


Yes.


Multiple times.


Across multiple months, this is an issue


that we are facing for two years now.


And it's just one page?


It's like the rest of the website


is being updated normally?


Well, not the entire rest of the website,


because it's a very large website.


But we are focused on this particular one,


because it's about one very successful product of us.


I don't know.


It sounds kind of weird.


I mean, if you can drop the link into the chat here,


I can take a look afterwards to see if there


is something very obvious.


Sometimes it's just the case that we


don't crawl all pages all the time.


But if you're talking about something


that has been kind of like not being


crawled for several months now, and you tried all the submission


method, and the rest of the site is kind of OK with crawling,


then that feels weird.


But I don't know.


I can take that.


Yeah, I'll drop the URL into the chat.


Thanks, John.


OK.


Cool.


Stefano.


Hi, John.


Hi.


Hello.


So my question is about the duplicate content


across the manufacturer and the, say,


reseller aggregators e-commerce site.


So suppose that there is a website selling


thousands of products from a variety of different brands,


and the commercial teams have been working hard


to get all the official information from the brand.


And then the data entries people are constantly


uploading all this information about catalogs and brands,


et cetera.


And most of the time, the content,


I mean the images, the text, and the descriptions


are the same of the manufacturer.


Of course, it's the official text


and the official information.


But that obviously results in duplicate content issues.


So my question is just a small part of this.


Would it be a good idea to put an external link


to the product sheet, to the official product sheet,


from e-commerce to the manufacturer?


Ideally, the best would be to have both linking each other.


But assuming Googlebot already is aware of the duplication,


would it be an improvement for the e-commerce to say, OK,


this is where I took the content from.


Those pages are strictly related.


Or would it result in a downgrade


of the e-commerce site?


I don't think it would change anything.


So we don't need to have a single link


to the original source.


So there are two aspects here.


When it comes to duplicate content, first of all,


you don't get a penalty for duplicate content.


So that's kind of, I think, just even before you


look into it too much, the only time


we would have something like a penalty


or an algorithmic action or manual action


is when the whole website is purely duplicated content.


So if it's one website that is scraping other websites,


for example, if these are e-commerce sites


and you have the description that's the same


and the rest of your website is different,


that's perfectly fine.


You don't need to worry about any kind of demotion


or dropping and ranking or anything.


With duplicate content, we have essentially two different


things that we look at.


On the one hand, we check if the whole page is the same.


And that includes everything like the header


and the footer and the address of the store


and things like that, which in your cases


would not be the case because one is maybe


a manufacturer's website and the description is the same,


but everything around it is different.


And so that's kind of the basic kind of duplicate content.


The other kind is with regards to things like the description.


That plays a role when we show a snippet in the search results.


So essentially, what we try to avoid


is to create search results pages where the snippet is


exactly the same as other websites.


So if someone is searching for something generic, which


is only in the description of that product,


and the snippet that we would show for your website


and for the manufacturer were exactly the same,


then we would try to pick one of those pages


and show only that one.


So that's kind of the other part of the duplicate content story


is a little bit simplified.


But that also means that if someone


is searching for something generic that


is in the description and we can tell that they want to buy it,


and maybe you're the best source or the local source


of that product, or you have it in stock or whatever,


then we would show your pages and not the other one.


And all of that is independent of you marking up


where you took this description from.


It's essentially, we have this description,


we want to show it in search, and we'll


pick the best page that we can show for this description.


So from that point of view, I think


it's always a good practice to have unique descriptions


on your pages.


But if you have a lot of products,


it's not always possible.


And it's also the case that we would not


penalize a website for having duplicate descriptions


in their products.


Cool.


OK.


Let me take a break here with the recording.


And I'll be around a little bit longer as well so we can


go through more questions too.


Thank you all for watching.


If you watch this on YouTube, if you


want to join these in the future,


I always have the links in the community part of our channel.


Feel free to join in there or add more questions there


if you'd like.


And otherwise, I wish you all a great weekend,


and maybe see you next time.


Thank you, John.


Nofollow Links: Does Google Count Them as Backlinks? #AskGoogleWebmasters

Today, we'll be addressing Capitan Adrian's question.


Does Google count nofollow links as backlinks?


I'm seeing these links in the link report in Search Console,


and I know for sure that they're nofollow.


Hey, Capitan.


Thanks for asking.


We've already talked about the general usage of the rel


nofollow link attribute.


When our systems run across links tagged like this,


we take note of them, but we don't forward


any of the so-called signals to the link pages.


In general, this means we don't pass any page rank


from the linked source to the link target.


However, it's still a link on the web,


and users may be using those to reach your website.


And so in Search Console, we decided


to show these as links together with other links pointing


to your site.


Similarly, if you were to use the disavow links tool,


those links would no longer be passing any signals,


but would continue to appear in the links report in Search


Console.


In short, links with a rel nofollow


don't pass any signals to your website,


but they will still be shown in the Search Console links


report.


I hope you found this video useful and insightful.


If there's something you want to add


or if this video has helped you, feel free to comment below.


And don't forget to like our videos.


And if you want to send us more questions,


use the hashtag AskGoogleWebmasters on Twitter.


English Google SEO office-hours from November 27, 2020

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team.


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


where people can join in and ask their question


around their website, around web search,


and we can try to find some answers for you.


Bunch of things were submitted already,


a lot more than I expected.


I thought this would be a fairly low-key one,


but it's always good when things get submitted.


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


you're welcome to jump on it.


Yes, so hi, John.


We have a question that is kind of keeping us


on the edge for quite some time, because we would really


love to know when the URL Inspection


Tool will start to work again.


Do you have any suggestion or any possible time frame?


Because it's not available for six weeks,


and we had some great results and really fast indexing


in the past with the URL Inspection Tool.


And so a lot of our content and the crawling of our content


is obviously stored this way, and we would just


be very interested in a possible relaunch.


I don't have any news on the timing there.


But in general, websites should be


able to get crawled and indexed normally within reasonable time


without using manual tools like that.


So my general advice there would be,


if you rely on this for normal content


that you add to your website, is to think about ways


to really improve the quality of your website overall,


so that our systems are kind of keen to go to your website


all the time to get the freshest information.


So to me, that would be kind of a signal


that something on your side isn't the way


that our systems would ideally like it to be,


and less that you should use this tool as a way


to do normal site maintenance and normal updates.


I definitely see its uses in cases where something urgently


needs to change, and you made a mistake on your website,


and you need to get that updated as quickly as possible.


That's something where I think this tool is fantastic for.


But for everything where you're updating things,


you're adding new posts to your site, if you need this tool,


then it feels like you're kind of covering up


the actual problems on a website.


Because from our point of view, search


should just work automatically.


It's not something that should require


any kind of manual intervention.


Yeah, thank you very much.


So we'll look into that.


So it's not that the crawling is then too long


or has any crucial problems.


It's just that it's obviously, in our experience,


way slower than when you manually trigger the indexing.


So that's just because we're curious to see


when the inspection tool will be upheld again.


I don't have any updates on that.


I know the team is working on it.


So it's not that it's going away or anything crazy like that.


Though it is something where internally people


talk about it and say, well, people shouldn't really


be using it for any kind of normal site changes.


They should try to find ways to make that update automatically


with site maps and all of that.


But yeah, hopefully it'll be back soon.


Cool.


Any other questions before we get started?


If I may?


Sure.


OK.


First of all, thank you for having this call


and for giving the information and answering the questions.


I hope you will do that.


My name is Alexey Ivanov.


And I'm from Russia.


I represent Rambler and Co.


Media Holding.


And we have a question we have asked at the page where you


have been gathering the questions.


But the thing is, when you sort the questions by popularity,


it just disappears.


And when you sort them by time, it is the first one.


So I wasn't sure if you will be able to see it and answer it.


So if I may ask it, it will be great.


So the question is quite specific.


And it relates to some localization.


And the question is about live blog posting markup


and the live badge.


So what we saw that, for example, if you take bbc.com


and search for some articles from bbc.com from the US,


you might find that it has a badge live on the result.


And the same badge you can see if you search


from Russia for them articles.


So we did this markup too.


And we found out that for our website,


it's Russian, this works if you search from the US.


And we have the badge live.


But it doesn't work if you search from Russia.


And our goal, as you might understand,


was to get this badge in Russian results.


So any comments on that, maybe you


can tell us that this works with AMP, for example,


because we search through the documentation.


And some details can be found, like tip,


use the live blog posting metadata markup


so your blog can be integrated with the third party platform


features.


So any comment?


Yeah, I don't know the specifics there.


I thought the live blog posting was also something


that we're just trying out with individual sites


at the moment.


So that may be something that is playing in there.


But if you could drop maybe some examples into the chat here,


then I can pick that up afterwards and pass that


on to the team to check out.


Or if you have the examples in the question itself,


then I can pull it from there.


No, we don't have examples in the question itself.


But I think me or my colleague will drop some screenshots


into the chat here.


Fantastic.


Cool.


OK.


Happy to take a look.


Thank you.


Hi, John.


Hi.


So I had a follow up on a URL submission in Search Console.


So this tool is going to be live with more features


or with the same features that we had already.


Because the way it is taking so much time,


it could be we feel like it will be also revamped.


I don't have any updates on that.


So you all have to stay tuned.


OK, cool.


Hi, this is Derek from Singapore.


So I do have a question regarding conflicting HREF


length signals.


So let's say we have implemented the correct HREF


lengths using sitemaps.


But because of some reasons, the web pages also


have another set of HREF lengths in there,


even though they are not the most correct version.


I know that we have to try to minimize conflicting HREF


lengths like this.


So my question for you is, how does Google actually


treat these conflicting HREF lengths?


Do they prioritize the sitemaps over the on-page HREF length,


or vice versa?


So any comments for that?


What kind of conflicting HREF lengths do you have?


So for example, I may have a HREF length directive


that is correct in the sitemap that


says that this page is meant for English US users.


But then the same page, the source code for the same page


may be showing French US.


Yeah.


OK, so what would happen there is we would combine those.


So from our point of view, HREF length


is not something where we say you can only


have one language or country version on one page,


but rather you can have multiple country


versions on the same page, and you can


have multiple different levels.


So you could say this is the page for English in Singapore,


English in, I don't know, US, English in UK,


and you have a different page for English in Australia,


for example.


But you can have one page with multiple kind


of country regional targeting on them.


So if you have some HREF length in the HTML


and some in the sitemap, then we would try to combine that


and add that together.


And that means that if you have kind


of multiple different country versions


across those different things, we would just combine that


into one setup.


The one place where it would get confusing


or where we would see it as conflicting


is if you have one country language version on the page


and you use the same country language


version for a different page in the sitemap file.


That would be the kind of situation


where our systems would probably have to guess.


And as far as I know, we don't have any prioritization


where we say sitemaps is better than HTML


or better than the headers, but rather we would just see,


well, this doesn't work, and we would probably just


drop that pair.


SPEAKER 1 OK, thank you so much.


JOHN MUELLER Sure.


SPEAKER 2 John?


Hi.


SPEAKER 2 How are you?


So if a publisher owns several different sites


and sometimes promotes or recommends the same content


across its network, but they're not


trying to do Google as that it's original,


they want to signal that it's part of the same network, what


should they do to signal that it's not original content


but just being promoted or recommended?


Should they use a rel="canonical,"


or is there some other mechanism?


JOHN MUELLER Yeah, usually the rel="canonical,"


is the best method to let us know that this


is your preferred version.


And from a practical point of view,


it's not so much that the web spam team would


get upset about that situation.


It's just that the publisher is kind of spreading themselves


thin, and instead of saying, this


is one really strong version of my content,


it's like I put it on 20 different sites,


and they can all rank maybe.


So it's kind of like diluting the value.


But with the rel="canonical," you can


help to concentrate the value on the version


that you prefer to have indexed.


Yeah, I think it's more of not trying to even,


it's more of a, here's our network.


And if you're interested in this,


you might also be interested in this.


It's not really to rank, in fact.


It's just to recommend.


Yeah, yeah.


I mean, that's a totally common use case for that.


OK.


All right, thank you.


Sure.


John, quick follow-up on that.


So in cases where there's a network with the same business,


but it has like 10 websites, let's say,


and each website kind of links to another one using


keyword-rich anchor text, does Google


determine that, oh, it's from the same business,


so it's kind of like an internal link, or can it be a problem,


and can it attract manual action or anything like that?


For the most part, we can figure that out,


and we treat that as normal links.


So it's not problematic.


I think it would get problematic if you have


a really large network of sites.


And if it starts looking more like, oh, you're


just using these links for SEO means


rather than to kind of say, well,


these are other places where you can also get similar products,


or you can find our business online.


Yeah, I'm asking since there's a thread in the private forums


regarding that, and somebody has a manual action.


And within the manual action, a few examples of those links


are from a website part of the business's set of websites


network.


So yeah.


I mean, usually with manual actions,


there's a much bigger pattern involved than just like,


oh, there's one bad example in kind of the set there.


It's really kind of a bigger picture problem.


So it can happen that some of the examples


are kind of like if you look at them,


you can be picky and say, well, this link is actually OK.


But if you look at the bigger picture,


it's like, well, there's actually a bigger pattern here.


And this is just like one kind of thing


that fits into the bigger pattern


but is also kind of something debatable.


You could talk about it.


OK, so should that webmaster do anything about that link?


If he or she sees it in the manual action example links,


what should they do about it?


So my recommendation there would be


to fix the bigger issue, like the broader overall issue


first.


And if that's something specific with that link where


you're saying, well, actually, I'm


going to keep this link because I think it's right,


then that's something I would include


in the text of the manual of the reconsideration request


and kind of like say, there were five links.


And it's like I cleaned the bigger issue


that the five links point at.


And there was one extra link there that I think is OK.


And I kept that.


OK, and one more thing regarding this.


So as far as I understand it, this


is a network with very large websites.


Like they have millions of pages.


And the business sometimes buys other websites.


So in this case, the links in those two examples


that the team sent were from a property


that the business just bought.


And it was a very large million pages website.


And so can this pose as a problem in the sense


that if they just bought the website,


Google has no way of knowing that it


belongs to that business now or anything like that?


Maybe.


I don't know.


I'd have to take a look at the thread.


It sounds like there is a bigger story behind it.


OK.


Yeah.


OK, cool.


Cool.


OK, let me run through some of the questions


that were submitted.


And we can chat more afterwards as well.


I don't actually sort them in any particular order


when they come from the YouTube comments.


So it's like just taking them as they show up here.


I think this is generally sorted by whatever YouTube's ranking


system does.


I don't know how you can game that.


Do you treat anchor text that contains many words differently


in comparison to anchor text that


contains two words only?


I mean, do you assign more value to those two words


when you compare it to anchor text that


has seven or eight words?


For example, two words anchor text, like cheap shoes,


and the seven words anchor text is you can buy cheap shoes


here.


Can you elaborate on that?


So I don't think we do anything special for the length


of the words in the anchor text.


But rather, we use this anchor text as a way


to provide extra context for the individual pages.


And sometimes, if you have a longer anchor text that


gives us a little bit more information,


sometimes it's kind of like just a collection


of different keywords.


So from that point of view, I wouldn't see any of these


as being better or worse.


And it's something where, especially


for internal linking, you want to probably focus more


on things like how can you make it clear for your users


that when they click on this link,


this is what they'll find.


So that's kind of the way that I would like to get out of here.


I wouldn't say that shorter anchor text is better


or shorter anchor text is worse.


It's just different context.


Let's say you look at a page and test it to see what's there,


and you decide that it wasn't relevant


after collecting signals.


Let's say I improved that page to make it the best out there


for those queries.


Would you automatically test it and try


to look if it's the best page out there,


even though you've collected all those signals


and it wasn't the best piece of content


for those queries in the past?


Absolutely.


So pages can change over time.


Pages can get significantly better over time.


Pages can get worse over time.


That's absolutely possible.


So that's something where if we've collected signals


and found a page to be like this in the past,


it doesn't mean it will always be like that.


So from that point of view, if you have pages on your site


and you significantly improve them,


our system should be able to look at that over time


and say, well, this is a much better page now


than it was before.


So that's something that definitely gets updated.


And I think the hreflang question


we talked about briefly, I noticed


that free websites created on business.site


have a follow link in the footer that


goes to the page that redirects to google.com


slash business slash website builder.


Isn't this against Google's guidelines on link schemes?


I don't know.


I didn't take a look at the exact example here.


I think we looked at this in one of the previous Hangouts


a while ago as this kind of started rolling out.


In general, when it comes to these kind of links,


what we try to look at is the specific anchor text there.


So if it's something where when we look at it,


it looks like, oh, it's promoting this website in a way


that it uses very keyword-rich anchor text,


then that would be more problematic.


If it's essentially just linking to the URL


or if it's using the business name as something that


is linking to the website name, then usually that's


less of an issue.


So from my point of view, if this were any random website,


I wouldn't really say much there.


But since it is a Google property,


I will pass it on to the web spam team just


to double check to see that they're OK with this.


I don't know what will happen there with the web spam team.


It's very possible that we already


ignore these specific links because these


are the kind of links that are very easy for our systems


to pick up and say, well, we can just ignore those.


But it is always awkward to get these reports that


Google properties aren't doing things perfectly.


What's the difference between?


AUDIENCE 1 But I think the problem is that everyone


that asks those type of questions


hopes that the answer is going to be, you've got us OK.


You're all right as well, rather than, OK, we'll fix our site.


You're never going to go the direction of letting


everyone else get away with it rather than just


fixing your own problem.


So I don't know why people ask these questions.


Yeah, I mean.


Well, forgive all of your penalties.


You're right.


You caught us.


Everyone's fine to do it as well.


Yeah.


It's just a question that gets nowhere.


I mean, I totally understand that it's frustrating,


especially if a website got a manual action for buying links


or doing this kind of thing and put


other links across other sites, it


is frustrating to see other sites kind of get away


with that.


But yeah.


If you build a $100 billion network,


then I think you have a little bit of leeway


to do what you want.


That's my opinion.


I don't know.


Now?


I think it's worth also to hold our sites


to a little bit of a higher standard


just to make sure that we're really


doing the right thing.


Yeah, but you'll be linking from one very high quality website


to another very high quality website with a purpose.


Is that not fine?


Yeah.


We'll see what the web spam team says.


I look forward to your penalty.


It wouldn't be the first time.


I mean, one of the tricky parts with all of these things


is that just because someone works at Google,


they don't know all of the kind of ways to do SEO perfectly.


So it is very common to see sites across Google


do SEO in a way where if it were to come to the forum,


people will be like, oh, god.


But I don't.


It's not my site, obviously.


But I'm not sure Google should be punishing naivety.


It should be punishing people that deliberately


do things to game the system.


If you don't know anything about SEO, then by definition,


nothing you've done could be penalty worthy


because you're not trying to game the system.


Yeah, I think the way I see it more


is to kind of level the playing field in the sense


that it's not always the intent, but rather kind of the effect.


And if our systems can't kind of neutralize


that effect on their own, then maybe we


need to kind of manually just kind of neutralize it


so there is no kind of negative effect on the search results.


John, I had one follow up on this penalty or link manual


action.


So I was just going through link scheme document.


There are two types of links basically


that Google has documented.


One is a first paragraph, which is talking about link scheme.


And the next paragraph talks about unnatural links.


So in links, I was just to know in links scheme,


I was noticing it was like buying or selling links


is against Google guidelines.


That was one thing, right?


Or excessive link exchange, you will give me a link,


I will give you a link.


And the other thing was unnatural link,


which was all talking about unnatural links,


like keyword rich was mentioned over there.


So I was a little confused about really Google considers


both these sections for manual action or unnatural link


is related to manual action.


Because for the first section, link scheme,


I never saw any manual action or any penalty,


like some websites are having excessive give me link


or I will give you a link.


This kind of strategy, I have also personally


saw a lot of websites buying links also in web.


They are just buying the links.


But how Google treats them, does Google also


consider link scheme as manual action for the websites?


Sure, yeah, absolutely.


I mean, it is always tricky to see this from the outside.


Just because a website has a manual action


doesn't mean it will not show up in search.


So unless there is something that


is really problematic with the content itself,


then we would keep that website in the search results.


We would just try to neutralize the effect that


is happening there.


And sometimes we can't isolate that effect completely


and we kind of neutralize a little bit more


than just that effect.


But essentially, just because a website is in the search


results and they're doing something shady


doesn't mean that they're getting away


with doing something shady or that they're


ranking because they're doing something shady.


So on the one hand, our systems try to automatically just


ignore those things.


And even if there is a manual action,


then it wouldn't remove the website completely from search.


So it means that Google also just neutralizes those link


scheme links.


Yeah, I mean, we try.


I'm sure there are situations where we don't


manage to do that automatically.


And that's what the manual actions are for.


And we can't catch everything on the web.


But it is one of those things that we work on.


All right, thanks.


Sure.


All right, now a question from the new crawl stats report.


What's the difference between discovery and refresh?


In our case, it's showing 84% refresh.


Does that mean 84% of the time Google


is crawling known URLs from the database and only 16%


of the time they crawl are site maps,


out links from URLs that they crawled from the known URL


database?


So I'm not 100% sure of what exactly we would


put into each of those buckets.


But in general, we do split things up


into refresh crawling, where we try to update the information


that we have on a site, and discovery crawling,


where we try to find new URLs that we've


heard about from the website, which


could be things like from new internal links


or from external links pointing at your website.


So that's something where, for a large part,


I would imagine for most sites, a lot of the crawling


is concentrated on just refreshing the information


that we have.


And that refresh crawl doesn't mean that we're just


updating the page's content.


We're also looking for new links,


which we can then use for discovering new content.


And yeah, that's generally how we deal with that.


Does a link that qualifies as referral traffic,


so it gets more link equity than a link that


has never been clicked on?


I don't think so.


On the one hand, I don't think we


would be able to see what people actually click on.


On the other hand, I don't think that would usually make sense.


Sometimes links are out there, and they're


really important references, but they rarely get used by users.


But that can still be a useful reference.


I have a question about indexing queries that are non-English.


Does Googlebot actually go through translation algorithm


in order to understand the meta title, meta descriptions


before indexing them?


If yes, is the same algorithm that


is being used in Google Translate


and how can we be assured when it comes to accuracy?


So for the most part, we index the content on pages the way


that we find it.


It's not that we try to normalize everything


into English and then only index it in English,


and then if people search, we try to understand the query


and translate it and show it back again.


Essentially, we index the content the way that it comes.


So if you have a website in a language


where maybe Google Translate is not so good yet,


then we will still index that content in that language.


And when someone searches in that language,


we will try to map those words and point to them directly


as well.


So from that point of view, we don't


need to translate things into different languages.


That said, we did some experiments in the past,


and I don't know if that's still live in some regions,


especially in places where we don't have a lot of content.


What we have done is when someone searches


in their local language and we recognize


that there isn't a lot of content


in that specific language, then we


may try to translate the query into a different language


and bring results from that different language


and show those as well and say, you search


for this in your language, and here


are some results that were in English,


and we can show you the Google Translate


version of those pages.


So it's not so much that we translate the pages


before indexing them, but rather we take the query


and then say, oh, there isn't a lot of information for this,


but for the translated version there is,


and then we try to search for the translated


version of the query itself.


And that's something you would see in the search results


directly.


If you search, then you kind of see that this is happening.


I don't know if we still do this or if that's just


in individual locations, but that


is something, depending on your location,


that you might have run into.


What about Google News appearing issue for new publishers


after the December 2019 update?


I don't have any update from the Google News side.


I'm also not on the Google News team,


so I can't really help you with those specific issues.


My recommendation there would be to kind of go to the Help form.


In general, when it comes to Google News,


it's something where what we show in Google News


is kind of different ranking algorithms


that we would use for Google Search.


On many PDPs, we have very old user reviews,


professional reviews.


Can old dates on those reviews create negative impact


for that page?


So PDPs, I think, are product detail pages.


So especially on e-commerce site,


if you have for one particular product,


for example, a landing page, it's


totally fine to have old reviews on a page like that.


I don't think there would be any downside to having


those older reviews there.


I think that can be very useful for users.


Is search volume of a brand a ranking factor?


How does Google know a brand of a website and show site links,


click-through rate, or backlinks?


I don't think search volume of a brand


would be that useful as a ranking factor,


because if someone is searching for that brand,


we would already try to show that brand anyway,


because probably the brand's landing page is very, very


relevant for those kind of queries.


So I don't think the volume of brand queries


themselves would make a big difference there.


With regards to knowing the brand of a website


and showing site links, that is sometimes hard,


sometimes quite straightforward when


we can recognize that a website is very


relevant to a specific query.


And sometimes we can recognize that by the site-wide


information on the website and recognize, oh, well,


this whole website is on this specific topic.


Maybe that is the name of the website,


or maybe that is the brand of the website.


So it's less a matter of people linking to this website saying,


oh, this is a brand, or a matter of people clicking on the links


but more like, well, this website


is just very relevant for that specific phrase or word.


Event-rich snippets.


I have a list of sports events on my site


that are imported through an iframe.


Can crawlers read the data on the iframe?


That's tricky, because sometimes we can, and sometimes we can't.


So my recommendation there would be to think about what you


would like to have happen here and to make


it as obvious as possible for us that we should be doing that.


So if you're embedding these sports events on your website


and you want to have them associated with your website,


then my recommendation would be to try to implement them


directly on the page itself.


If you can't do that within the static HTML,


maybe there is a way to pull them in using JavaScript


in a way that we can render the page


and also see those events on the page.


On the other hand, if you don't want those events associated


with your website, then maybe using something like an iframe


is fine.


But probably you would also want to use robots.txt


on the iframed content itself so that you can really


be sure that we don't take them into account.


So that would be my recommendation there.


I think using an iframe and saying,


I don't care if they get indexed.


Maybe they will, maybe they won't.


That's kind of fine.


But usually, when you're running a website like this


and you're trying to optimize it,


you have something specific in mind that you


would like to have happen.


And if that means you want those things


to be indexed on your pages, then


make it so that it's easy for us to recognize that.


If you don't want them indexed, then


make it so that we can recognize that they shouldn't be indexed.


Can I use an anchor in an event snippet link?


I mean, you can definitely use it.


But whether or not we would show it,


I think probably we would not show it.


As far as I know, the only place where


we would show links in the rich results


would be the FAQ markup in the answers


to the individual questions.


I think otherwise, we don't show links that


are included in rich results.


Do I have to satisfy all the criteria for event snippets


to show other websites don't satisfy them


and their event snippets are visible?


I don't know.


I mean, it kind of goes back to the first part


there where it's like, well, what


do you want to have happen?


And if you really want these snippets


to be shown for your website, then I


would make it as clear as possible that everything is OK,


that we can recognize them, that you're following the guidelines,


and that you're kind of doing everything


you can to make them appear.


And it's kind of regardless of what other websites are doing.


It's really a matter of, is your website really doing everything


it can to make sure that our systems can recognize


that it's relevant and OK to show those snippets?


I'm very interested in the development of web stories.


As of now, they only appear in Google Search


and discover in the United States, India, and Brazil,


is there a time frame when they will come to Europe?


I don't know.


Good question.


Yeah, whenever I think about web stories,


I assume that they're already everywhere.


But apparently, they're just shown in individual places.


The thing with web stories is also their normal HTML pages.


So they can rank in the normal search results


like any other kind of page.


However, I think the embedding, especially in search


and discover, where it's a little bit the more


fancy type of embedding, that is something


that is limited to individual locations at the moment.


With all of these things, I can't


give any prediction of when they will be expanded and come


to other locations.


Sometimes it's a matter of refining the technical details


and the UI.


Sometimes it's a matter of policy questions as well.


So that's always a bit tricky and not something


I can guess for other teams at Google.


Just curious, regarding web stories,


what do you do if you have a certain type of content


that you wish to present in kind of a long-form format?


Maybe it's thousands of words.


But you also want to benefit from exposure


via the discover and search web stories carousels.


Should you do both?


Should you do just one, isn't it,


with the web stories being kind of a smaller format in terms


of text content?


Can that be a problem?


Should you canonicalize the two?


I think it's totally up to you.


So what I have seen a lot is that a web story is a really


nice way to build interest on a topic


and then to link to the more detailed page.


Because a web story is usually something


you would look at on your mobile phone.


You're kind of like in a mood to be a little bit entertained


and informed.


So presenting it in a way that is


visually compelling and interesting


and then having kind of that read more link at the end,


I think that's a pretty nice model.


But how that works for your specific content


is really hard to say.


And it is also something where I've


seen some sites do it really well in that they have really


nice and visually compelling content, a little bit animated,


and other sites essentially just use clip arts


or just use images from a blog post,


where when you look at them in web story format,


it's like, well, it's not really that exciting.


And probably what, I mean, I don't know the details.


My guess what will happen there is we might show this web


story, but if users kind of get lost


on the first couple of pages, we're like,


this is not really that interesting,


then they're not going to click through to your site.


So, yeah.


So in cases where the traffic is coming from desktop pages,


can you have a fallback so instead


of showing the web stories, the same URL


shows a normal blog post and anything like that?


I don't think that would work that well with search


because we would index one set of content for that URL.


And if you have a long form blog post


and you show Google the web story


so that you get the web story ranking,


then you miss a lot of information


that is not in the web story.


So that's something where I would


tend to just see them as separate formats where maybe


you're kind of like referring to one or the other


in the different locations.


OK, but if it's not that much content, though,


is it OK to have a blog post, a normal blog post,


and a web stories and the blog post canonicalizes to the web


stories so that Google shows, would Google


show the normal blog post on desktop users


and the web story for mobile users?


I don't know.


Yeah, my guess is our systems aren't kind of designed


for that, and the outcome is a little bit unknown.


So I mean, if it ends up that people do this very, very


frequently, which from my point of view,


probably doesn't make sense because the amount of content


is just very different.


But if people ended up doing it more frequently,


then I think we'd have to come up with a way


to deliberately do this so that you can kind of like,


with a desktop and a mobile page,


you can say this is my alternate for the desktop page,


and this is the canonical for the mobile page kind of thing.


But at least at the moment, I don't


think we have any provision to understand


that one URL is both a web story and a traditional page.


Yeah, yeah.


Right.


Right, I was thinking since I think,


if I remember correctly, with web stories,


you can kind of swipe up and put more content there.


So you kind of have a bit of content on the image


that you're being shown.


And then you can swipe up and see like additional text


that's by default is hidden, but users


can swipe up and see the text.


So you can put a bit more text there.


Apparently, I haven't tried this.


I've just seen an example.


So I'm guessing you could kind of maybe smaller blog post,


kind of retrofit them into a web story format.


My recommendation would be to try all of these things out.


Especially with web stories, with kind


of the newer technologies, it's something where theoretically,


you can talk about this in a long time.


But it's sometimes more interesting to just try out


and see what actually happens.


And then you also kind of gain experience there.


I know also the team that is working on web stories,


they also run the Web Creators channel on Twitter.


And they're currently looking for questions about web stories.


So you might want to kind of like find their Twitter account


and drop some of the questions in that thread there too.


Yep, cool, thanks.


Pages, I check Google's cached versions


of the pages of various pages of various sites


that use this solution.


And the content does not appear navigable.


The links are also not clickable.


So I don't know this specific cookie solution.


So it's hard to say.


In most of the cases that I have looked at,


we can crawl and index the content normally.


So what is important for us with any kind of interstitial


or anything that you use as a pop-up or as a banner


on a page is that in the HTML version of the page,


when we crawl it, we can find the information


that you want to have indexed for that page.


And that includes textual information.


That includes all of the layout information, the CSS,


the images, all of that.


Also, the links on the page.


And if those are in the HTML, even


if they're blocked with some kind of an overlay


or some kind of a banner on top, then essentially


from an indexing point of view, we can crawl and index that


site.


And at least what I've seen with the different kinds of cookie


banners that sites tend to use, that all tends to work out.


And this is something that is fairly easy to test.


On your site, you can use the Inspect URL tool


to do a live test of your pages.


And then you can look at the HTML version


that Google actually uses for rendering and indexing.


And within the HTML, you can check to see,


is my content actually there?


Are my links there?


Is it formatted in a way that Google could understand?


And if that's the case, then you're all set.


And because these tools exist and have existed for a while


now, pretty much all of the, I would say,


mainstream types of implementations for this,


they should be able to get this right.


When it comes to the cached page that we provide,


one of the things to keep in mind


is this is based on the HTML page


that we have fetched from the server.


And sometimes JavaScript can run within the context


of the cached URL, and sometimes it can't.


And it depends a little bit on the JavaScript itself.


The main issue here is that the cache page is, of course,


hosted on some Google domain.


It's no longer hosted on your domain.


So if you have JavaScript that requires


that it runs on your domain and is not


able to run on other domains, which is often the case


with the security implications of JavaScript,


then that JavaScript won't run.


So a really common place where this comes into play


is if you have a JavaScript-based website,


and you look at the cache page, and it's empty,


then you might assume that Google is not


able to index the content.


But that's actually more a technical thing


that within the context of this cached URL, JavaScript can't


run, so you can't see that actual content there.


And what might be happening in this case


is maybe JavaScript can run for this particular kind of banner


that you're using, and it's also blocking


the cached version of the page.


So that's something where essentially that cookie banner


thing that is running on the cached version of the page


would also apply there.


But like I mentioned, the cached version


is essentially more a technical copy of the HTML


rather than a representation of what we would actually index.


And to check the indexing, you'd need


to use the Inspect URL tool.


OK.


We have just a few minutes left, so maybe I'll


switch to questions from you.


And I also have some more time afterwards if any of you


want to hang around a little bit longer.


I have a question, actually, if you hear me, John.


Sure.


It is about actually programming languages


and their documentations.


Since we have so much versions in programming languages,


they create really duplicate content or nearly duplicate


content.


So we are using canonical tags for making only one of them


index, or Google chooses one of them as canonical version


and tries to index just one of them.


But this is also creating a kind of confusion


between programmers, because actually we


are using old versions too.


But when we search for them, we can find them


on the Google search.


So we need to find them in the stock overflow


while with internal source system, with the websites.


And some of the developer sites or programming language sites


are using canonical tag in a manipulative way.


They are marking the new version as canonical


from the older version.


But actually, the content is different.


Yeah, purpose is same, but the content is different.


So what can we do to improve this situation?


I think that's always tricky, because usually the names are


exactly the same.


And maybe the way that you call the functions


are slightly different.


And it's hard to know.


Also, the queries don't have versions.


So even if I search for, I don't know,


ECMAScript 6 or ECMAScript 5, I am using just ECMAScript


in the query.


So I understand your point too.


But I'm in a solution to it.


Yeah, so my usual recommendation for this kind of issue


is to try to keep the current version of the URL stable


and to move the older versions to kind of archive setup.


So this is something that we run across with events


or with different product generations that


happens fairly frequently.


Like if you're searching for an iPhone,


you probably want the newest iPhone.


But you also want to find information


about the older iPhones.


So what we recommend doing there is then


having a kind of a stable URL for the current version, which


could be, like, I don't know which iPhone version is


like the current one, whatever number it is nowadays.


And when a new device comes out, you


take the old current version and move that into a separate URL.


So maybe you would have, like, the new one is,


I don't know, iPhone 15 or whatever it is.


And then the iPhone 14 moves to a different URL,


which would be like iPhone-14 or something like that.


And what would happen there is we would not


lose those older versions of content,


but rather we would notice that the stable URL is


kind of the one that is the main version of the content.


So if someone is specifically searching


for just the newest iPhone, they would find that stable URL.


But if they're looking explicitly


for the older version, then they would still


find the older version of that.


And with programming languages, you


can probably do something similar where you say,


well, this is the newest version of the JavaScript syntax,


and this is the current version.


And when something new comes out,


then we take the current version, move it to an archive,


and say this is ECMAScript 5 and kind of focus on,


kind of move that to an archive situation.


OK, thank you for the recommendation.


I will try that.


OK.


Hi, John.


Hi.


I have two questions about manual actions.


The first is, after a manual action is revoked,


is there a kind of time frame in which the website has


less trust than it would have without the previous manual


action?


And the second question is, if you


start using the disavow tool, what


happens if you completely remove the disavow file


after many years?


Is there a risk of getting another manual action?


Yeah, so when a manual action is revoked,


essentially everything that is associated


with that manual action is turned off.


So if there were issues with links to your site


or with the content on your site and the manual action


is resolved, then that is completely resolved.


Sometimes there are technical things


on our side that just take a little bit of time


to get updated.


So for example, if a site is removed completely


from indexing because it's just a scraped copy


of other content and we revoke that manual action,


then it takes a bit of time to get indexed again.


And that's not because we don't trust the website anymore.


It's just for technical reasons, it takes some time.


With regards to the disavow file,


if you remove the disavow file, then all of those links


will be treated as normal links again.


And it could happen that at some point,


the WebFam team looks at that and says, oh, well, this


is very problematic.


And there is no disavow file here at the moment.


So we will have to take a manual action there.


And that's something that from a spammer point of view,


we have sometimes seen, where people will say,


oh, I get a manual action.


I fix my manual action.


I know what to do because I'm a professional at this.


And the manual action is revoked.


And they'll be like, OK, I will switch on all of the spam


that I've been doing again.


And that's something that the WebFam team has also


run across.


And when they see this kind of switching back and forth


happening regularly, then they might say,


OK, the next reconsideration request,


we will just wait a while to see what they actually want to do.


But with, I would say, normal websites,


where after a couple of years, you just


remove the disavow file because you think it's no longer


relevant anymore, your website is in a new clean state,


then probably that is less of an issue.


AUDIENCE MEMBER 1 OK, thanks.


All right, maybe I'll just pause the recording here.


If any of you want to stick around a little bit longer,


you're welcome to do so.


In any case, thank you all for joining.


Thanks for all of the questions that were submitted.


We didn't get through all of them.


It looks like there's still a bunch left.


I'll try to add some questions, some answers in the Q&A


on YouTube as well.


But hope to see some of you again in the future.


And like I mentioned, if you want


to stick around a little bit longer,


Thank you, John.


Thanks.


See you.


Welcome to the Search Off the Record podcast!

Fun fact, every day we discover 40 billion spammy pages.


That's a lot of spam.


This is crazy.


They found your site, Gary.


I learned that there are more than 10,000 search quality ratings.


Oh my God.


Today we'll be talking about the future of SEO.


What could possibly go wrong, John?


If you geek out on SEO as much as we do, then we have a podcast for you.


Search Off The Record is a podcast series where we talk a bit about what's happening


at Google search.


One topic that has come up over and over again externally is everything around core web vitals.


Go behind the scenes.


I mean, we are definitely thinking more about the sustainability of crawling and indexing.


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


If we were to create a search engine, what should it be called?


Search makes search fail.


Okay, we'll go with Steve.


That totally rolls off your tongue.


We'll go with Steve.


Created by us, the Google search relations team, Lizzie, Martin, John, and me, Gary,


chief of happiness and sunshine at Google.


Gary, Gary, Gary, Gary, Gary.


Okay, stop, stop.


Shut up.


So, whether you're new to SEO or love all things internet, or maybe you just miss talking


to us at conferences, check out our series with one of the apps below or wherever you


get your podcasts.


How to think about ranking in Search and much more! | Search Off the Record podcast

Welcome, everyone, to the next episode of Search Off


the Record, a podcast from the Search Relations team


here at Google.


Our plan is to talk a bit about what's


happening at Google Search, how things are working


behind the scenes, and I don't know, maybe


have some fun along the way.


My name is John Mueller.


I'm a webmaster trends analyst or search advocate


I work together with the Search Relations team here.


I'm joined today by Martin and Gary.


Hi.


Morning.


Oh, all right.


Gary, do you want to take us off?


Why it's always me?


Because reasons.


It's always me.


I'm in a fantastic mood because I just spilled coffee


all over my keyboard, and I had to switch keyboards at, like,


I don't even know what the time is, like 10 AM.


Is that a hot swap?


Thanks, Martin.


You're welcome.


That cheered me up so much.


Anyway, I wanted to talk a little bit about feedbacks.


Lizzie and I, Lizzie as in our tech writer,


we are processing feedback and also the translations


for the dev site, developers.google.com


slash search, and we got tons of great feedback


that was actionable.


You can think of, like, translation quality,


for example, where people were pointing out


that we were switching between the different tones of German,


like formal or informal, and we were


doing some really weird things in Japanese as well.


And the feedback in general, it's really, really great.


But then some people leave feedback in the form of,


well, some things are just rent about something, completely


unrelated to the article.


And they come through to us, and sometimes we read them,


and, well, they are not useful.


We can't really do anything about them.


And another category is where people are asking


for help about something.


So for example, just today, I had


to wake up at 6 AM for reasons that are beyond me,


and I was processing some feedback.


And there was this person who had their email account


suspended for some reason.


And I would love to help, but I really can't with that.


I can't even respond to these feedbacks,


which is probably a good thing for the person filing


the feedback.


So if you have, in general, something


about the documentation itself, if you could leave feedback


about that, that would be great.


Otherwise, we can't really do much.


On the bright side, sometimes it also


gives us lots of great points to think about.


For example, we noticed that we got lots of feedback


from bloggers, let's say people who are not developers.


And they were commenting that we sent them, for example,


structured data messages, that something


is wrong with their structured data,


and they can't do anything about it.


They don't know what to do about it,


because they just installed, for example, a plugin.


And the plugin generates the structured data for them.


And that prompted us to think about how can we


help also those people?


And John started an internal thread,


which somehow ended up, I think, a little derailed.


But then I just jumped over Twitter


and asked people for some help, I guess.


And we'll see where that goes.


But thank you for filing feedback.


Thank you for filing feedback in multiple languages,


because it's been really, really, really helpful.


And just think about how you leave feedback and about what,


because really, we can help with absolutely everything.


So where should people go for things like their Gmail account?


We have specialized forums for most products, I think.


And those forums are filled with people


who are insanely helpful.


We used to call them top contributors,


but I don't have any idea what we call them nowadays.


MARTIN SPLITTENBERG product experts.


GARY ILLYES-SELLS-SUSSMAN product experts, OK.


They are insanely helpful, and they can point people


in the right direction.


And ideally, those who have problems with our products,


they would just go to the forums and ask for help there.


MARTIN SPLITTENBERG I think, generally speaking,


it's a good idea to give us feedback.


And I'm really happy that you bring this up,


because I know that from the outside,


sometimes it feels like talking into the void.


I don't think we are able to give a response back.


So I think when people are writing actionable feedback


on our documentation or on Search Console or something


like that, it's invaluable to have this feedback.


And a lot of changes are happening


because of this feedback, even though it might not necessarily


look like that from the outside, right?


GARY ILLYES-SELLS-SUSSMAN That's actually funny,


because apparently there is a setting somewhere buried that


would enable us to respond to feedback.


But when Lizzie found it, and she was saying that,


oh my god, can you imagine Gary replying to this feedback,


I lolled.


MARTIN SPLITTENBERG Fair enough.


Yeah, not sure if people would want that.


JOHN MUELLER Yeah, I think there's some kind of feedback


where it's useful to be able to let them know


and to kind of inform them that, oh, we read this,


and we totally agree.


We fixed this issue.


We tried to improve the documentation in that way.


That's something that I see, for example,


from the Google Maps team.


I think they do that really well, where


if you submit feedback and say, oh, actually, this road is


closed or something like that, then they'll


send you an email back over time and say,


hey, we saw your feedback.


We fixed it.


And I think that kind of helps to encourage other people


to submit more feedback and kind of keep things going.


Because it's kind of important to us


that our documentation, the help that we provide,


is useful to people.


So if people are confused or people


don't find it as useful as it should be,


it's really helpful to know.


We can't kind of read that from people's mind.


MARTIN SPLITTENBERG True.


Yeah, and this is like the black hole kind


of character of the feedback.


You give feedback, seemingly nothing happens.


And like six months later, a feature


is rolled out that implements what you have been sending


feedback about.


Might not feel very encouraging.


So I think it's a good opportunity for us


to say thank you to everyone who provides feedback.


We do take it into account.


And it does matter a lot to us, especially on the docs.


JOHN MUELLER-GRANT, MD, PhD Talking about black holes,


maybe we should talk about JavaScript and search.


What do you think, Martin?


MARTIN SPLITTENBERG Oh, my.


What an elegant segue into the thing that happened recently.


MARTIN SPLITTENBERG John, you will get a cookie for this.


MARTIN SPLITTENBERG Gary's cookies are fantastic.


I'm now slightly jealous.


So Wanli ran this free webinar recently.


There's a recording of it on YouTube


as well, where they invited me to talk a little bit more


about rendering SEO.


That's how they try to talk about specifics in rendering


when JavaScript is involved.


So it's not just JavaScript SEO, but they are really


focusing on rendering.


And after that webinar, I got a question on Twitter


as well regarding, should we split our JavaScript


into multiple smaller files, or should we bundle them together


in one large file?


And that was an interesting conversation,


because the answer is kind of weird,


because the answer is bundle it up and then split it.


JOHN MUELLER-GRANT, MD, PhD So what is bundling JavaScript?


Is it like put it in a zip file?


MARTIN SPLITTENBERG Not really.


It's more like merging all the files together.


So if you have a library, and then you


have code that uses that library, 20,000 years ago,


you would basically just have the library in one script tag


and then have another script tag for the code that


uses that library.


But that makes a lot of HTTP requests,


and the number of HTTP requests is limited


that you can do at the same time in the browsers.


So people were like, hmm, maybe we should just


make one file where we put the library first,


and then the actual application JavaScript that we write.


And so people are using these bundlers.


There's a bunch of different tools,


like Webpack and Browserify and what they are all called,


Parcel, and so on and so forth.


That basically just puts all the JavaScript


that you write from the different files that you create


into one big file, and that's usually


referred to as a bundle.


JOHN MUELLER-GRANT, MD, PhD So it's not something you manually


do.


You kind of run it through a script,


and then it creates one big JavaScript file from that.


MARTIN SPLITTENBERG Yeah, and usually also it's like you can do it manually,


but then you are kind of wasting your time,


because there's fantastic tools that do this.


And these tools also do other things,


like shorten the variable names so


that it's less bytes on the wire,


and remove code that is never used,


and all this kind of stuff.


So it's pretty powerful tooling, and a bunch of people


are using this to bundle their JavaScript


in one gigantic file.


JOHN MUELLER-GRANT, MD, PhD Is that something that complicated sites


need to use?


It's like, I sometimes write JavaScript as well,


but it's, I don't know, maybe two pages of code.


Should I run it through one of these tools as well,


or is that more like if you're creating a really complex


JavaScript app load?


MARTIN SPLITTENBERG I think it is more for people who use frameworks


and libraries a lot.


If you write a little bit of JavaScript


to do something fancy when you click a button in, say,


like 100 lines or something, I think minifying your code


is useful, but not as useful.


It's not really a necessity.


But if you are using a framework like React, Angular, View,


there's so much code involved that these bundling tools


are definitely helpful.


Cool.


Yeah.


And the oddity is that, so when I say that,


and it's an accepted best practice


to bundle all these things in one big file,


it comes with a downside, which is


that if I have a huge application with lots


of different views, like, I don't know, a blog,


and then I have an e-commerce part of my website,


and then maybe I have like a login accounts


page or something like that, or an order dashboard or whatever,


if I have all the code to power all this content


in one huge JavaScript file, that


means that if any of these parts change,


the entire cache is invalid, and we have


to redownload everything.


And also, if I just come for the blog,


then why would I download an order page or a card


system or an account system?


So you download a lot of stuff that you don't need.


So that's why the recommendation is to bundle things up,


but then split them according to the content


that people might visit specifically,


so that you separate the different parts of your page


code-wise.


OK.


That sounds pretty complex.


Yeah.


It's called code splitting, or splitting,


if you ask me, obviously.


You didn't.


I did.


It's such an original joke.


No one ever toys with my name like that,


so I had to do it, I guess.


I literally face-spawn.


You're welcome.


What can I say except you're welcome.


So yeah, a bunch of these tools that are bundling


have options to specify how you want


to split your bundle as well.


So for instance, you can say, oh, this


is code that every page needs.


It's kind of like the boilerplate or the runtime


or whatever you want to call it.


And then you create one JavaScript file


that contains this boilerplate, because the boilerplate probably


doesn't change very often.


So you can keep that cached forever, basically.


And then you have only the code for each specific page or view


separated into different bundles.


So there are options, and there are


tools that help you with this.


But if you want to do that manually,


that's really, really hard to do.


JOHN MUELLER


I think it's something that an SEO should


make developers aware of, because not every developer is


aware of this.


As I said, the old established best practice


that still is somewhat valid is to bundle everything


in one file.


Now it's like bundle it up in multiple files,


but make that a reasonable bundling.


And I think it's not something that the SEO needs


to do afterwards.


It's better if the developer does this


while developing the site, because it's usually


embedded in the developer tools how


you can split these things.


And it might require some changes in the way


that the code is written.


So definitely make your developers aware of that.


Is there a simple way that an SEO could recognize this?


Like if you look at, I don't know, at a waterfall diagram,


would that be obvious that you need to bundle the code


or you need to split the code?


So I think if you are seeing your website downloading


20 different pieces of JavaScript or 30,


40 pieces of JavaScript, that's a case


where there is no bundling.


And you should definitely think about bundling this,


because that's a lot of requests.


And it's kind of pointless to have all these requests


separate.


If you see one request that keeps repeating every page you


visit, like an app.js or a main.js or something like that,


or bundle.js is a classic, and you


know that the website is very large


and has lots of different pages, then


that's a hint that you probably want to split your bundle,


especially if this bundle is like multiple megabytes.


If you have like a bundle.js or an app.js that


is like five megabytes, then that's


a very clear candidate for splitting the bundle up


into smaller chunks.


JOHN MUELLER-GORDON... Sounds cool.


I will test some of the web pages


that I access to see if I can figure something like that out.


I can't help them to fix a problem,


but it seems like something that you


should be able to try out on random websites


that you visit and kind of see if you could recognize this


as kind of, I don't know, an exercise.


MARTIN SPLITT... And it's just something that is nice for the user


and easier for us also to deal with caching-wise.


But it's not like a ranking factor or anything like that.


We are not looking at this.


It doesn't necessarily help you with core web vitals


or something.


So it's not directly impacting your ranking or anything,


but it is just a helpful thing to do.


OK, speaking of ranking factors...


Oh, dear.


Please don't tell me JavaScript is a ranking factor.


I don't know.


JavaScript can be a ranking factor?


Sure.


Why not?


Uh-oh.


Well, OK.


It's kind of a tricky topic in that I see people write


about this all the time externally.


I see us using that as well.


We use it when we talked about the page experience benchmark,


where we said this would be a ranking factor.


And then obviously, the next question from everyone


is like, well, how strong of a ranking factor is it?


Do I have to throw away my website


and just make a fast, empty page instead?


And obviously, that doesn't make any sense either.


So I think there are two mental models


I have when it comes to ranking factors in general.


On the one hand, search is not a science.


I think that's really important to keep in mind.


In the sense that there is no absolute truth out there


with regards to which page should


be ranking for which query.


But rather, these are things that can change over time.


These are things where people are working on it


to keep improving things.


And sometimes, you can have discussions with smart people


about which of these pages should be ranking first.


Or if we have two very similar pages,


should they be both ranking?


Or should only one of them be ranking?


Like those are very, I don't know,


interesting discussions to have.


But it's all based on kind of, I don't know,


opinions and kind of ambiguous information


that you have from the web.


So that's kind of the one thing.


And the other thing is that there


are so many different ways to reach a final result in search.


It's not that every site has to do the same thing.


So I use a mental model of something


like a neural network, which is not


how we would do this in search, but it kind of helps me


in that we take the query that a user has


and we try to understand it and split it up


into lots of small parts.


And these small kind of signals that we


have from what the user is looking for,


they go through this big network where


different knots along the way kind of let


the individual parts pass or they kind of reroute them


a little bit.


And in the end, we come up with a simple ranking


for the different web pages for that kind of a query.


And when you have this kind of a network,


there are lots of different paths that could lead through


that network that end up with the same result.


So it's not that every site has to do the same thing,


but rather there are multiple ways to get there.


And you don't have to blindly follow just one ranking factor


to get to the end result.


And it's also not the case that any particular kind of factor


within this big network is the one deciding factor,


or that you can say that this factor plays a 10% role


because maybe for some sites, for some queries,


it doesn't play a role at all.


And maybe for other sites, for other queries,


it's the deciding factor.


It's really hard to say kind of how to keep those together.


So this kind of big network thing


also changes over time, of course,


as we try to improve our search results.


And essentially, we try to optimize


how we understand the query.


We try to optimize how we understand


kind of the routing between the query and the search results.


And these kind of changes take place all the time.


And the best way for a website to kind of remain


in a stable position, which is not guaranteed at all,


is really to make sure that you have


a wide variety of different factors that you work on


and kind of to keep this diversity of your website


upright.


So similar to how you might want to improve diversity in a team


to get different viewpoints, that's the same thing


that you'd want to see on a website.


So that regardless of how things are


routed through this network to find the search results,


we can understand that this website is


relevant in different ways.


And all of these add up into kind of telling us


that it's actually relevant for a particular query.


So that's all to kind of say that it's really, really hard


to take any particular element and say


this has such and such an effect on the search results.


And similarly, it's pretty much impossible to kind of go


from the other way around and say, well,


looking at the search results, I can


tell that this particular search results factor is


this important or more important than this other factor


because it's really not the case that you can kind of


route things backward and say, well, looking forward,


it goes like this.


And looking backward, it's exactly the same route


because there are just so many different ways to get


to the end result.


So that's kind of my short monologue on ranking factors.


I think it's worthwhile to keep in mind


that when you talk about ranking factors externally,


there are lots of different ways to get there.


And it's not something that you can just kind of deduce


into one specific element or kind of simplify into an ordered


list of elements that you need to check off.


But rather, you need to make sure


that your website is good in a variety of different ways.


And don't just blindly focus on one particular element


and then try to make that element look natural


so that it's like, hopefully, the algorithms won't


think that I'm trying to do something sneaky here.


But instead, just make sure that everything is kind of natural.


GARY ILLYES-SCHREIBER-MARTIN


Do we have hundreds of ranking signals by any chance?


JOHN MUELLER-SCHREIBER-MARTIN


We have lots of them.


I don't know how you would count them.


Because it feels like things like how we sort strings


is essentially a ranking factor, right?


What?


No?


It's like all of these different algorithms


that play a role in the final result,


it's like, how do you even count them?


MARTIN SPLITTENBERG That's a good question.


I think it's 420.


420, OK.


MARTIN SPLITTENBERG Just because of the 420 joke?


Did you literally just make a 420 joke?


GARY ILLYES-SCHREIBER-MARTIN


Maybe.


I would never joke about this.


Come on, Martin.


MARTIN SPLITTENBERG Seriously.


We should count those ranking factors.


No, but I really have no idea how you would count them


and how you would even kind of split them up.


On the other hand, what I think is really neat


is when people externally try to understand search


and they try to figure out how search might be working,


to look behind the bigger picture


and try to figure out what kind of algorithms


might be playing a role here.


How can I understand how search engines work?


Because there is technology behind all of this.


It's not like a magic box where you just drop things in


and things come out.


It's essentially something that people can code.


And you can learn how to code, and you can


learn how to make search engines.


It's not something that you should ignore completely.


MARTIN SPLITTENBERG So I think this is an important point.


You say, yeah, you can code this,


and you can understand how it works.


But I guess ultimately, the goal of search engines


is to show the most relevant and useful content for users


to the users searching for something.


So how does that work?


Do we know exactly how we need to rank,


or how to do this?


Or is this something that is emerging?


Or how does that work?


JOHN MUELLER I mean, it's something


that we have to keep working on.


Like I said, it's not like a science, where you can say,


this is the absolute correct answer,


and everything else is wrong.


But rather, you could discuss that maybe this


is the best answer, or something else is the best answer.


It might be, today, this is the best answer.


But maybe next week or next month,


we discover, well, actually, we should have


been looking at it differently.


Maybe something else is the best answer.


And obviously, there is some things where


there is a scientific answer.


Like if you ask, what is 2 plus 2?


The answer is obviously 4.001 when it comes to computers.


Or maybe it's just 4.


I don't know.


But a lot of things really don't have absolute answers.


And this changes over time fairly quickly as well,


where maybe if you're looking for a vacation destination,


you'd like to find some general information


about that destination.


But if suddenly that vacation destination is in the news,


then probably you want to see something different when


you search for that location.


I mean, I don't know who's going on vacation nowadays.


But at some point, we'll be able to go on vacation again.


So that'll be relevant then, I'm sure.


I just shed a tear.


Aww.


I want vacation.


There will be vacations again at some point.


Anyway, I would also like to add there


that we also take quite a bit of user voice


into shaping the algorithm.


Because when we evaluate new launches,


then it is tested first on humans, pretty much


all the launches, be that live experiments where actual users


are getting the new algorithm or piece of the algorithm


into their search results.


And they can see different results,


differently sorted results.


And then we look at things like clicks,


like how they reacted to the new results


to understand whether the launch is good or bad.


And then we also have raters, humans


who would leave us feedback on side-by-sides


to help us understand what went well and what went wrong


with a specific potential improvement.


MARTIN SPLITTENBERG


And I think tracking ranking is also pretty weird and tricky


for people externally.


Because even if your website continues to be fantastic,


other websites might come into the web that


have better information or more up-to-date information


for something.


And then you just don't rank as high anymore.


That doesn't say anything about your website specifically.


It just says something about both how


we are thinking about ranking as it


comes to the different ranking factors,


as well as the web moving.


That's just something that happens.


JOHN MUELLER I think that's definitely


something that comes into play every now and then as well.


On the one hand, our algorithms change.


On the other hand, user expectations change.


Some of that might be reflected in the algorithms directly.


And then, of course, all the other websites on the web


are kind of in the same pool.


And sometimes it makes sense to show some of them


more frequently.


Sometimes it makes sense to show your site more frequently


if we think that it's more relevant for users.


And I think another tricky aspect there


is that sometimes there is just a lot more than just


pure relevance when it comes to ranking.


In particular, factors like, I don't know,


HTTPS or speed are things where we can say, well, technically,


these sites are just as relevant to users.


But we think this one provides a better user experience.


Or maybe we feel this one makes it easier


to view the actual content.


And maybe it makes sense to show that one a little bit higher.


So these are all small, subtle things


that also play a role in there.


And in some cases, maybe they don't


play a big role in other places.


Maybe they do play a significant role in which of the results


we show first in the search results.


Interesting.


Fun stuff.


OK.


Well, I think my kind of monologue


all about ranking factors and things,


I do wish that people continue to stay


curious about these things.


But it is also worth taking them with a grain of salt


to think about, well, actually, there is a lot more involved


rather than just one factor that you should be focusing on


or one element that you should be using as feedback


to send to Google and say, well, my website


is faster than this other one.


Therefore, it should be ranking first.


Yeah.


Fun times.


Yeah, I don't know.


Talking about fun times, how is the video recording going,


Martin?


Oh my, oh my.


So with not all of us, but some of us


have been sent this bunch of kit for recording videos from home


because the studios are closed, which is super sad.


But it makes sense that we are producing video content


from home now.


So this Web Dev Live is an online event


full of pre-recorded talks that are being put on YouTube


with live Q&A with the speakers and super cool ideas,


super cool content concept.


We do the same thing with the Webmaster Conference Lightning


Talks.


We do record these videos continuously.


We have recorded some before the lockdown,


and some are recording now.


And yeah, it has been interesting to assemble


the kit.


There's so much stuff that you need to screw together


and then put in the right position.


And then we have been chasing around our apartments


to find the right spot to film so that it looks nice,


but not too noisy.


And aye, aye, aye, aye.


So that took quite a while.


And then we recorded.


And then I am used to recordings,


and I do enjoy them.


And I'm normally one or two takes for a thing,


but not anymore.


We recently recorded a few things from home,


and it took me quite a while.


First, I was misconfiguring the teleprompter,


and then the light was changing because there were clouds.


And I don't know, John, you're recording videos from home


as well.


How was the experience for you?


I think it went perfect.


I just had one take, and we were done in like 10 minutes.


I don't know, Martin.


You liar.


No, actually, it did take quite a bit of time.


So finding the right position and moving things around


so that it looks kind of reasonable,


I mean, it just takes time.


And getting the lighting in a way that makes sense,


that takes time.


And of course, we're not in a studio, but rather at home.


So it's like the rest of the family


is out and about doing things.


I think for one part of the recording,


we had random noises from the kitchen


all the time, which is, well, kind of understandable.


Like you have school, and kids have to get something


to eat in between.


So it's like you have to do something quietly


in the kitchen.


But all of these small distractions


just make it a little bit harder, I guess.


But I think overall, it's been interesting.


You have a lot more appreciation for the team that's usually


involved with recordings, where it's like usually,


your job is just to speak some text


and kind of look reasonable into the camera.


And now it's like all of these small parts


that have to play in together.


And it's like, oh, is a color right?


Is the sound the right level?


All of these small things where it's really like there's


just so many fantastic people that are


involved in these recordings.


MARTIN SPLITTENBERG And we had a beautifully shared moment


in one of the recordings where there were garbage trucks


backing up into back alleys in three different locations


at the exact same time.


That was hilarious.


People were looking at me like, hold on.


There's a garbage truck backing up.


And then one of the producers was like, oh, wait a minute.


That's actually on my end.


This is happening here.


I'm like, no, no.


It's also happening here.


And then the third person in the call is like, no, no.


This is also happening here as well, actually.


And that was kind of interesting.


That was funny.


Yeah.


I mean, ultimately, we try to make these as clean as possible.


But it's not a sterile environment.


It's like we work from home.


And try to get things right.


MARTIN SPLITTENBERG I think it makes them even more personable.


It's like, oh, yeah.


They are at home as well.


Look at that.


It'll be fun to look back at these after a couple of years


when everything settles down.


I mean, hopefully it doesn't take a couple of years.


But at some point, it'll be settled down and kind of see