where you need to take a look at what exactly where you're


English Google Webmaster Central office-hours from March 20, 2020

seeing kind of this slow average response time.


Because there are two places where speed plays a role


from our point of view, on the one hand,


there is the practical aspect of when we crawl our web page,


we need to be able to get that content as quickly as possible


so that we can crawl as much as possible from your website.


That's more kind of a practical thing for Googlebot.


If your server is slow, we tend to slow down our crawling


as well, and then we can't crawl as much.


So if you have a lot of content and your server is slow,


then probably we won't get through to everything.


The other aspect is with regards to what a user would


see when they go to the page.


And that's less kind of from the practical point of view


of individual files, but more from the point of view


of when you load this page in a browser,


how long does it take to actually display


the full content there?


So those are kind of the two aspects there.


With regards to the crawl speed, the time


that it takes for us to kind of fetch individual pages,


that's something that's, like I said, purely from a crawl


point of view a factor.


If we can't crawl as much, we can't show it in search.


When it comes to the speed that a user would


see in a browser, kind of the rendering speed,


that's something that can play a role in ranking,


because when we send people off to a website that's really slow,


we've done them a little bit of a disservice


by sending them somewhere where their time is being wasted.


The crawl stats in Search Console


show the Googlebot side, and the speed report


in Search Console, the page speed insights,


Lighthouse tests, they tend to show the more user-facing side,


which is also reflected in the ranking.


Let's see.


Does Googlebot desktop and smartphone always


have the text Google in it?


Because many times our Search Console crawl stats


don't match up with our Kibana server log trend.


And in our server logs, when I filter for Google,


it shows media partner Google primarily and Google Web


Lite and some other user agents that


look like Googlebot that don't contain the Google in them.


They contain things like Chrome with a server number


or something like that.


So we use the Googlebot infrastructure


for a number of different crawlers,


and that's what you're seeing in the Crawl Stats report.


The primary other kind of non-search crawlers


that you would see there are the Googlebots, what is it,


the media partner bot, which is, I believe, from AdSense.


Then there's also the AdWords landing page check, I believe.


And then there's the Merchant Center,


kind of the product search shopping landing page test


or whatever that's called.


I don't know what exactly those user agents are called.


We have them documented in the Help Center,


so you can double check there.


So it's not only Googlebot for search, but also kind of also


these other requests as well.


There's also, I believe, the rendering side of things


might also show up there.


So when we render a page for search


to determine if it has any JavaScript that we need


to execute, then we also need to fetch


all of those individual pages there, which would also


go through the Crawl Stats report.


One of the tricky things with the Crawl Stats report


and the speed there in general is that, obviously, when


we start crawling a lot more from your website,


your web server might be a little bit slower.


So we tend to balance that automatically


in that if we recognize the server is getting slower,


we'll try to reduce crawling a little bit.


The other thing that plays into speed and the size


as well is that if, for example, your website has


a lot of really large content, like perhaps it


has a ton of PDFs which are really large,


and we go off and try to crawl those,


then it might look like the average page is much slower,


or we're crawling a lot of data from your server.


But actually, it's just, well, you


have a lot of really large files,


so we ended up crawling those.


My blog is just three months old.


My posts would keep appearing in the first page,


and then they suddenly disappear after one or two days.


Why does that happen?


I think that's always a little bit tricky in the beginning


when we first see websites when they're fairly new,


because we don't have a lot of signals for those websites.


And we aren't really sure how we should show the content


from those websites.


Kind of where those websites are relevant,


we don't have a lot of information


from the rest of the web that tells us this is actually


a really good website, and we should show it in search.


And with that, our algorithms have to make some assumptions


in the beginning.


And they have to kind of look at your pages


and say, well, I don't really know a lot about this website,


but this looks OK.


Maybe I'll try to show it like this in the search results.


And we'll see how that works.


And over time, that will settle down,


where we have a lot more signals from the rest of the web,


and we can kind of be a little bit more deliberate in how


we show things in search.


So what you're seeing there is fairly common, especially


for new websites that maybe they're


shown very visibly in the beginning,


and then it drops off to kind of a stable state.


Sometimes it's also the case that the competition is really


strong, and we tend not to show these new pages as visibly


as we otherwise might.


And over time, we'll see, actually,


this is a really great site.


We should show it even in the competitive search results


a little bit more visibly.


So my kind of gut feeling would be


to say the first six to nine months of a website,


things are going to be fluctuating.


And it's up to you to make sure that the picture that you're


providing is really a good picture, where


it's clear to us that actually, this is a really strong


website, and we should be showing it very visibly in search.


So improving the quality of your website,


also perhaps finding ways to promote your website


independently of search so that users can still


find your website.


And if they really like it, they can link to it,


and they can recommend it to their friends.


You're kind of building up that traffic from both sides,


not just throwing a website out there


and hoping that Googlebot does some magic


and sends you a lot of traffic.


My website ranks for SEO, company, and location.


Keyword phrase from the last two years


at the first position at that location.


And then suddenly, another website


ranks for the same key phrase.


And that website was not even a competitor.


We analyzed the important points of that website.


We concluded that the domain name is an exact key phrase,


and backlinks are almost the same.


We also have 70% content marketing the same as we have.


So my question is, how can we beat out


that website, which is ranking now on the first position


from a couple of days?


We've been in this industry for the last 10 years.


I don't know.


It's really hard to say.


It might be that they're doing some things really well.


It might be that you're not doing things as well.


But in general, some websites go up and some websites go down.


So maybe this website was in one of the previous Hangouts


and learned a magic trick that helped


them to make it so that Googlebot can


find their website better.


So there's no simple solution to say,


I will always be ranking first.


And especially when you're saying


you've been in the industry for the last 10 years,


that historical aspect of our website


was always ranking number one.


That's something that I would just assume


is not going to be the case.


Things will always change.


So you need to always stay on top of things.


And if the way that the web evolves in your niche


is a way that requires some changes on your website,


then that's something you should think about doing.


And always keep testing, making sure


that you're doing things that work well for users.


With regards to why a competitor might be able to do that,


that's always tricky.


I would not assume that this is only because the domain name


has some keywords in it.


We do use keywords in domain names and in URLs.


But it's a really tiny factor.


And it's really something that mostly makes sense


when we have very little other information about our website.


So that's something where I wouldn't assume


it's impossible for you to beat them again and get


that number one ranking again.


But it does require work.


And it's not something where you can find that magical meta


tag that you put on your pages and suddenly everything


gets better.


So yeah, if you're an SEO company trying


to rank for these SEO company phrases,


then you probably know all of the things


that you could be focusing on, that you could be working on.


And if you're unsure of what you could


be doing with your website or with this specific situation,


I would definitely recommend dropping by the Webmaster Help


Forum and laying open what the problem is


that you're looking at, the URLs that you're looking at,


and asking for honest feedback from people.


And if you're an SEO company, there


will be some feedback in the forum saying,


oh, you're an SEO company.


You should know what you should be doing.


But it's still important to get a lot of that feedback


and to get a diverse set of opinions about this


so that you can kind of filter out which of these aspects


are things that you think really matter


or that you think you'd really like to try out.


Because some things you might say,


I don't want to do that, or that's not something


I'm good at, or I don't want to hire someone


to do that at the moment.


That's totally up to you.


But having that set of ideas is an important first step.


Are there any pros or cons for having multiple sitemap files


without completely filling 50,000 URLs?


We're planning to implement last mod tags,


but currently we have around 200 files in our sitemap index.


And some sitemaps contain fewer than 100 URLs,


and none contain more than 20,000.


Would Google be able to see last modified URLs in all sitemap


files?


Because I'm seeing Google doesn't read all sitemap files


every day.


So yes, we don't crawl all sitemap files every day.


That's correct.


But you can have multiple sitemap files.


That's perfectly fine.


What we recommend doing when you update a sitemap file


is to ping that sitemap file to us.


So there is a mechanism.


I believe that's documented in the Help Center, where


you send essentially Googlebot a request saying,


hey, I updated my sitemap file.


Take a look.


And then we'll go off and double check that sitemap file.


So that's kind of what I would recommend doing there.


Having fewer sitemap files makes this a little bit easier.


So if you can fold things together, that's also fine.


If you can fold things together in a way


that you have the fresher content in a single sitemap


file and kind of the older content that


hasn't changed for a while in other sitemap files,


that also makes it a little bit easier,


because we can focus on that sitemap file for the newer


URLs, for example.


But those are small optimizations,


I'd say, compared to just generally using


the last modification date, because the last modification


date does help us quite a bit.


Can enhance my warnings.


Hi.


Yeah.


Grazie.


Hey.


Sure.


I'm here.


I'm working on a site that has been impacted by a traffic


drop, organic traffic drop.


We analyzed the whole website.


We've been analyzing the website for the last four months.


We saw there is no technical issue.


There is no content issue.


The site loads pretty fast.


I think it's a fairly good site.


Everything checks out, but we are


thinking about this theory about bad neighborhood in the IP


address.


So is there a chance that this site being hosted on Cloudflare


and sharing the IP with too many really, really sketchy


websites?


Is that a reason for being penalized, quote unquote?


No.


Usually not.


So it's really common that websites share the same idea.


I'm sorry.


The thing is that usually that you just said,


we are thinking outside.


We are trying to think outside the box,


because it's like we are even asking our SDR colleagues


to say, hey, what's going on here?


We can't figure this out.


There is no actual coincidence.


We Google update.


We are doing updates.


It's like, we have a host now.


Yeah.


So there usually is something where


there are extreme cases where when the web spam team takes


a look at a website and they see that, oh, on this server,


there are 9,000 other sites and they're all spammy,


then that's something where the web spam team might say, OK,


all of these websites are spammy.


And if there are one or two reasonable websites in there,


that's something where that could happen


that they are affected by this.


With regards to everything else, like normal hosting,


if you're hosted with a shared hosting provider,


if you're using a CDN, there's such a broad mix of websites


there that even when someone manually looks at it and sees,


oh, there are 1,000 spammy websites here,


it's very obvious that there are also


2,000 good websites there.


So just because there is a significant set of sites


that are spammy on the same IP address


wouldn't result in the whole IP address being demoted.


So it's really only kind of a really extreme case


where maybe a spammer is running a server


and they have tens of thousands of websites on that server


and they're also renting it out to other people


to make it look a little bit more legitimate.


And that's the case where maybe it could happen


that we kind of missed something.


SPEAKER 2


If that was the case, should we have a notification


in Google Search Console?


Or do we use it again?


Yeah, yeah.


That's something where we would do that as a manual action.


And with the manual action, that would result in a notification


in Search Console.


And then you can go through the reconsideration


and say, hey, my website is not pure spam.


It's like, what are you thinking?


Look at my website.


It's normal.


But yeah.


SPEAKER 2 Awesome, thank you.


I have another two questions, but I


want to open if anyone wants to ask a question.


OK, let me run through the questions


over the whole bunch.


But yeah, let's see, how much time do we have?


We have 50 minutes.


Well, we can shift to open questions


and come back to the submitted ones if we run out.


Go for it.


SPEAKER 1 Anyone wants to ask?


SPEAKER 2 Yeah, hey, John.


I have a question.


Sure.


So I work on a pretty massive user-generated content sites.


And we're mostly focused in the US.


But we've seen great growth in our international usage


and international content.


This includes content that comes from other regions that


may be in English, but also is in their native language.


And we've noted that although this content has


been driving a significant amount of traffic,


it doesn't seem to perform as well from standard engagement


metrics, bounce rates, time on sites, conversion rates.


It doesn't seem like this content


is resonating with users as well as the US content.


And we're fearful that the international content


that we're getting may be dragging down our ability


to perform when it comes to the US content.


So we're wondering if it would be a valid approach


to split the site into separate domain or perhaps a subdomain


so that way we could do a better job of protecting our domain


level kind of quality.


I mean, you can definitely split things up


into separate domains or subdomains.


I think overall, assuming this international content is


of reasonable quality, probably you


would be better off just keeping everything together.


If you're really not sure of the quality


of the international content, then that's


something I would try to figure out first,


rather than just looking at the pure metrics of things


like bounce rate and interactions on the website,


time on site type of things.


Maybe find some local speakers to double check


the quality of that content, especially if it's user


generated content, just to make sure


that it matches what you would like to see on your website,


what you'd like to have published


under your website's name.


But in general, while you can split things off and make


separate sites, I think that makes it overall almost


a little bit harder for the whole website


because suddenly you have two websites that you


have to work on and promote and make sure


that they're performing well in search,


rather than one really big website that


has this mix of different kinds of content.


SPEAKER 2 OK.


And do you think that the contents


in the native languages could potentially be,


let's say it's all within the same topic,


do you think the aspect of language difference


could be diluting the relevance for the US or English audience?


I don't think so.


I mean, what I would double check


is to make sure that this content ranks


in those languages and not in English.


But in general, that should be fine.


OK, thanks.


I appreciate it.


Sure.


So I'm a little insistent.


I'm continuing with this idea of bad neighborhood.


We have a theory about bad neighborhood traffic.


So imagine you have a news website,


but you are getting a lot of traffic from a video that


ranks for a porn search.


So it's completely unrelated and completely different topic.


So is there any chance that that traffic


coming from a completely unrelated search term


is hurting the main site?


Or the other way around, if we noindex that page


and remove that traffic, could benefit us?


Does that make sense?


Yeah.


The question is, how do you make sure


that that doesn't make sense, the question there?


In general, that wouldn't change anything.


The tricky aspect there is kind of the adult


versus non-adult angle.


Like when you say it's ranking for porn terms,


that's something where I would just


make sure that overall your website is


kind of in this clear situation where


it's not an adult website.


If you have some pieces of content


that are more adult-oriented, that's fine.


But kind of make sure that you stay clearly on the side


where, I don't know, like the primary part of your website


is clearly not adult. Because what could happen otherwise


is that the SafeSearch algorithm say, oh, we


think maybe this website is an adult website,


and we will use SafeSearch to filter the whole website.


So with a normal news website, that's


something you generally want to avoid.


But if these are individual pages, that's usually fine.


It's something where the biggest effect that I've seen


is that it makes it really hard to look at the metrics overall.


So we have this, for example, with our help forums.


Every now and then I take a look at our analytics for our help


forums, and the overall traffic is going up and going down.


And we haven't changed anything with the forums.


They're not hosted in a great way from an SEO point of view,


but we don't change a lot of things.


But when you look into the details,


it's clear that sometimes we're just


ranking for irrelevant things, and we get a lot of traffic


for those irrelevant things.


So for example, with the forums, sometimes people


will use xxx as a placeholder for their domain name,


and suddenly the help forum ranks for xxx, which is like,


obviously, they're looking for something else.


They're not looking for the Webmaster Help Forum.


I mean, I'm guessing.


But if you look at the overall traffic,


it's like, oh, so many people are searching for our forums


and coming to the forums.


And when that goes away, it's like, oh, our website


disappeared from search.


And it's not that the primary content disappeared.


It's just this big piece of irrelevant traffic disappeared.


So it's a good thing that there is no benefit or penalty


for having bad traffic?


I think there's, I'd say there is no advantage


or disadvantage.


It depends on what you want to achieve.


Some people I've seen take this kind of situation and say,


OK, I'm getting a lot of traffic for something irrelevant.


Maybe I can put an affiliate link on there.


And then it's like, I get this irrelevant traffic.


At least they click on my affiliate link,


and that's fine.


Other people say, I don't want this extra traffic


because it ruins my analytics, and they noindex the page.


So that's totally up to you.


Awesome, I have another question, but I want to let anyone else


if you want to ask some question.


I have a quick question regarding robots.txt.


So isn't it correct that when a robot throws a server error 500,


that that will prevent crawling of the website?


Yes, at least temporarily.


So if we see it for a longer period of time,


we'll assume it's a 404 kind of thing,


and then we'll think, OK, we can crawl.


And could you be sort of a bit more specific?


What's a longer period of time?


How much time are we talking about usually?


Usually, so I don't know what is written in the spec,


but I believe it's a couple of days, something


around that order.


OK.


But that should be in the robots.txt documentation


that we have in the developer side.


I think that was specified with kind of the change


to making it more of a standard.


I think they specified that.


OK, great.


Thanks.


Sure.


So me again.


I'm consulting on a really, really big website


that has over 10 medium index pages.


So we found out that nearly half of those pages


are irrelevant, low quality, or near duplicate content.


This is a really big website.


Again, it has a massive amount of traffic.


It's been in need of around 20 years.


So we are thinking about how to make


or thinking about progressively no indexing


and getting rid of those shitty pages, let's say.


Imagine a case when we no index 20% of the no index pages,


considering that those pages don't bring any value traffic


and we don't lose any money, don't


lose any significant traffic.


Do you think we, let me rephrase that.


How much time would you think we should wait


until seeing expected end of change,


if we should see any change?


So I think that's generally a good idea, especially


with a really large website where you can't double check


the quality and improve the quality of all of these pages.


I think that's usually a good idea.


There are two aspects that kind of play into that.


On the one hand, with regards to crawling,


we'll be able to focus a lot more on the actual indexable


pages, which means we can crawl them a lot faster,


a lot more frequently.


We can get the new content a lot faster.


That's always a positive thing, especially


with large and changing websites.


And the other aspect is with the overall quality of the website.


And that's something that probably


takes a little bit longer.


So my guess is if these are really low quality pages,


then they're already not being crawled that frequently.


So probably I am just hand-waving a number,


maybe three to six, nine months, until you


see changes in the crawling.


And my guess is a little bit later still,


you would see changes with regards


to the quality of the website.


So it's really more of a long-term thing,


especially with a really large website,


because it takes a while for us to even notice that there's


a significant change.


AUDIENCE 1 Yeah, we thought the same,


but it's always safe to ask.


Yeah.


I mean, the crawling aspect is something


you can monitor fairly easily with the log files,


depending on how easily the log files are.


So yeah, that's something where we occasionally


see that at SEO conferences.


People will do a case study, and it'll show,


it's like, oh, I worked for this really large website,


and I removed 30% of the pages, and these


are the results that I saw.


It's never been the case that I've


seen that if you remove a lot of cruft pages,


that you have a negative effect.


I think there's always going to be a positive effect,


especially for websites where things continue to change.


So if this content is out there and it never changes anymore,


then crawling doesn't matter.


But if you're continuously putting new pages up,


and you clean out the old things, the unused things,


then it makes it a lot easier.


AUDIENCE 1 Thank you so much.


Sure.


Hey, John, I have one quick follow-up


to my previous question.


Let's say cost is of no concern to us.


We have the infrastructure and the resources


to build out these country-specific domains.


Given that cost is not a factor, would we


expect any maybe inherent benefit


to having such localized websites


for international content that is both maybe in English,


but is somewhat nuanced to that geography,


but also is in that geography's native language?


I don't know.


It's hard to say.


My general feeling is unless you're


providing something specific for users in those locations,


so not just in that language, but really for users


in that location, then probably you'd


be better off keeping it all on one domain.


By doing things with country code top-level domains,


if you're really providing content


which is specific to their location for, I don't know,


for example, maybe you have a chain of pizzerias,


and people are searching for pizzerias,


and they can recognize this is from my country,


so it's more relevant to me, then that's something


where it would make sense.


On the other hand, if, I don't know,


your website has pizza recipes on it,


then the location of the website is kind of irrelevant.


Then the geotargeting aspect there


wouldn't really be that critical.


And I think with a lot of user-generated content,


it's not the case that it's geographically relevant.


It's more that it's in their language,


and they can read it, which makes it helpful.


But they're already going to be searching in that language.


So those pages are already going to be relevant.


It's not that we have to kind of add


the extra factor of it's nearby to them.


I see.


So in the case of, let's say, education,


if something was related to courses that they may be taking,


although maybe it might be tied to a specific university,


but there still isn't quite the need


to have any physical association with that school.


It's just, oh, this is content from that school


or from this course.


Do you then think that that's enough nuance


in the area of geography where it would sway a little bit more


towards the pizza restaurant example as opposed


to the pizza recipe one?


Yeah, I think that could kind of make sense,


where if it's really tied to a physical location,


or even if it's not tied to a location,


if it's tied maybe to a certificate that's


relevant in that country, that's something


where kind of the geotargeting angle would make sense.


OK.


All right.


Thank you.


Sure.


John, a completely unrelated question.


Is there any chance, or do you foresee in the future,


a webmaster hangouts in Spanish?


Webmaster hangouts in Spanish?


I don't know.


I don't think we have a lot of people


here that speak Spanish that would be able to do these.


Oh, you're muted.


Someone muted you.


Whoops.


Maybe you can twist Gary's arm.


He speaks a little bit of Spanish.


He also does kind of more off-the-record hangouts at the moment


so you can join in on one of those.


I think he mentions those on Twitter every now and then.


Awesome.


Thank you.


Sure.


I had a question.


We've been kind of debating internally


a particular use of the XML Sitemap, where


we have a lot of content.


And we have a particular set of content


that we think is our best content,


and then our kind of medium content, and our lower content,


whatever.


And there's been an internal debate


about whether it would actually provide


a benefit to that best content if we were only


submitting that best content in the Sitemap


instead of submitting everything.


Is there any validity to that?


I don't think that would change anything.


So the Sitemap file is really only used


for the crawling side, which is more


the technical aspect of getting content into Google.


It's not a quality factor.


So it's not like an internal link where we would say,


oh, you want to promote this content.


It's really just purely from a technical point of view,


like, just page change as I take a look at it.


It's not a sign that you're saying, well,


this is a good page.


You should show it more visibly in search.


Sounds great.


Thank you.


Sure.


All right, maybe we can take a break here


to pause the recording.


I can stay on a little bit longer if any of you


want to hang around.


But it's always good to kind of close out


the recording at some point.


Thank you all for joining in.


Thanks for all of the many questions that came in.


And I wish you all a great weekend.


And stay safe.


Wash your hands.


Do the usual things.


Take part in these virtual Hangouts


rather than joining a big group of people.


It's always a good idea.


All right, see you all next time.


Bye.


English Google Webmaster Central office-hours from Nov 15, 2019

All right.


Welcome, everyone, to today's Webmaster Central Office Hours


Hangout.


My name is John Mueller.


I'm a webmaster trends analyst here at Google in Switzerland.


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


where people can join and ask their questions


around their website and around web search.


And we can try to help with, hopefully, some answers.


Sometimes there are no answers.


But we try to at least explain the thoughts behind it.


A bunch of stuff was submitted already


on YouTube, which is great.


That's always useful.


But is there anything on your designs


that you need to get an answer to right away?


Yes, John.


I'm sorry.


Sure.


I'm Sanjith.


I'm from Bangalore, India.


Hi.


Yes, I have a question, actually.


So I have a website.


And part of the website in AMP and some of the pages


in dynamic serving to show the content in mobile.


And it's in a mobile-first indexing from a switch


in mobile-first indexing from May 2018.


But now I see in the primary caller setting


it's showing as TikTok.


So it not moved to smartphone.


So could you please help me on that?


Where are you seeing the primary crawler?


It's showing TikTok.


And that's?


In such console tool, in coverage


section in such console tool.


OK.


So usually when we move aside to mobile-first indexing,


then we shift that too.


But what also happens with mobile-first indexing


is we will still crawl some pages or some parts of the crawl


with the desktop crawler.


So it's not that you would shift completely over


to just mobile crawling.


It would still have some things there.


And in general, it's nothing that you


need to worry about if your pages are ready.


If things are working well on mobile for you,


then that's fine.


It's not any disadvantage to be crawled


OK, thank you.


Thank you so much.


Sure.


Hey, John.


Hi.


Yeah, so I have a question regarding,


so I have a website with a mobile version


and a desktop version.


So I'm wondering how I can use the parameter, URL parameter.


The URL parameter handling.


OK.


So that doesn't really change with regards


to desktop or mobile version.


If you have parameters within your website


that you feel are making it harder to crawl your website


properly, things like sorting or filtering parameters,


then you can specify those in the parameter handling tool.


If you're not sure, and if you think


crawling is working fairly well, then I


would just skip the parameter handling tool.


Then you should be all set.


Yes.


Yeah, so another way of doing it,


we use canonical tag to the main URL, right?


Yeah.


So in the mobile version of URL, what canonical should I give?


Should I give to the desktop version or the mobile version


you mean URL only?


So with the canonical, you should


have the link between the mobile and the desktop version.


So the desktop version will have a link rel alternate


to the mobile version, and the mobile version


will have the link rel canonical to the desktop version.


That I, yeah, so sorry to interrupt.


So that part I understood.


So actually, the thing is if I have an original version


without the parameter one, right?


So we'll do the same thing which you told.


But in case of parameter, so ideally,


canonical should, in that case, canonical


should go to the desktop version or the mobile version


of the main URL?


I would just do it to the desktop version


of the main URL.


I don't think it matters because we fold those URLs together.


But the desktop version seems like a good a choice as any.


It's maybe also another chance to suggest


that if you can move away from this separate mobile URL setup,


it would make things much easier.


You don't have to worry about that.


But I know moving away is sometimes a lot of worry.


Yes.


So yeah, I had talked to a product team regarding it,


and they are not ready to do that, basically.


So I have to do work with the mobile and desktop


versions separately.


So that's the thing right now with me.


Yeah.


I know.


It's not easy.


Cool.


I remember, Shilka, with you coming way back,


and now I'm looking back at it, and I'm like,


oh my god.


I remember telling you that there's sites, a lot of sites


that I knew that were m-dot, whatever,


and having a website as a whole.


I think it was a reasonable choice at the time


when making responsive sites was a lot harder.


And sometimes you had completely different teams


working on a mobile site.


But it does make things much, much trickier when it comes.


Now it's a dinosaur.


So to addition to that, John, another point I had.


So basically, it's a dynamic site, so big e-commerce site.


So there is a crawling problem happening,


because we started our mobile site indexing recently,


in a month back, basically.


So ideally, the site map is something


that we submit for the desktop and the rel canonical URL


has given to the mobile version, right?


So I'm wondering, can we submit a separate site


map for the mobile version, only having the mobile URL in it


to make crawling faster?


It wouldn't make crawling faster.


So we need to see the map between the two versions.


So I would be with the main desktop version


with the site map files.


Got it.


Thanks for your answers, John.


Sure.


Hi, John.


I have a question for you.


Yeah.


We have been implementing structured data


from February last year.


But unexpectedly, due to accidentally,


the structured data has been removed on last July.


And we buy some developers when they are doing.


And again, in the month of August, we have noticed it


and we have added it back.


But from that time, we are not able to see the results


of the rich snippets.


We are able to see the results of AMP and FAQs and videos


and everything.


But only for rich results, we are totally vanished right now.


So is there a way we can do a resubmission kind of thing


for the desktop?


So the way that we decide when to show rich results


is based on three things.


So it's not something that you need to do manually.


Well, not something that you need to resubmit manually,


that someone has to look at it, unless there


is a manual action already.


If the web spam team says it's not OK,


then you need to fix that.


But we need to have technically the correct structured data.


So with the testing tool, that sounds like maybe you're


doing correctly.


It needs to be logically correct.


So it needs to be the right type of structured data


for the right situation.


So if it's a product, it shouldn't use the recipe


structured data.


It should match what you're showing.


And the third thing is kind of tricky,


is that we need to be sure that the website is


of high enough quality so that we can really


trust the website.


We know that the structured data that you're providing


is something that is relevant to be shown in the search results.


So that's kind of usually the part where people get stuck,


in the sense that technically implementing things correctly


is testable.


But determining how high quality your website is


is something that's very hard to do.


So if you're not seeing rich results, one thing you can do


is do a site query for your website.


So just search site colon and then your domain name.


And if you see the rich results there,


then technically we understand the markup on your pages.


And it's usually more a matter of us


just not being sure about the quality of the website overall.


So that's something where I would say,


if you see it in a site query, then definitely


focus on improving the quality of your website significantly.


Not just fixing things a little bit,


but really getting a lot further.


Yeah.


Sorry to interrupt you.


So continuation, we have checked there are no any manual action


report is not there.


And we have been checking all the structured data


as per the tool, like structured data test tool.


And it's been passed.


For some queries, when I'm doing it with a branded keyword,


I'm able to see the recent but like future snippet in Google.


But the data is not being showing in Google Search


Console.


That's what we are worrying because we


have lost a lot of impressions.


Because in July month we have seen that.


That's where our rankings.


And will there be an impact of page speed on structured data


as well?


Because I have checked my site with the Google Lidos tool.


And it's showing SEO score as 98.


And web performance, it's in 52, something like that.


Because that's around 10,000 years old site.


And it's in the park.


And they're not able to increase the speed.


That's one more thing is worrying me.


And it's getting very difficult for me to convince my client


that this speed is the only matter.


This is one of the top three priority.


That's how I'm telling.


I just want to, if you can throw some light on it,


it will be good.


So whether or not we show rich results


wouldn't affect the rankings.


So if you're seeing a drop in rankings,


that's completely separate from rich results.


That's maybe one thing.


The other thing is with speed, it


sounds like you're in a reasonable range.


It doesn't sound that terrible.


So that's probably OK.


So yeah.


But just from what you're saying,


I would really recommend focusing


a lot more on the quality of the website overall.


Thank you.


Thanks.


Sure.


OK, let me run through some of the submitted questions.


And we'll have more time for questions from you


all towards the end.


I have this room a little bit longer.


So we can go a little bit longer and maybe go off the record


so that the recording doesn't go too long.


Let's see.


Regarding the indexing API, I'd like


to know if it can be used in e-commerce shopping sites.


At the moment, no.


So the indexing API is a way of submitting URLs directly


to Google.


And it's currently limited to live streaming and jobs


content.


So any other kind of website content


will not be processed with the indexing API.


I don't know about the future plans.


Personally, I would much more recommend


using sitemap files for any kind of general website


where you're making changes.


Make sure that you're submitting good sitemap files that


are focused on the primary content


and that you specify the last modification date and time


of that primary content.


So that's kind of what I would recommend doing there


instead of trying to go this workaround through the indexing


API.


Another one that kind of, I guess, similar to e-commerce,


product markup only really works well


for standalone one-off stores like mom and pop's t-shirt


stores who directly retail.


I would argue that's not the case, but OK.


When will it be extended to suit the case for global enterprise


brands who may have many product pages


but don't directly sell to the public?


For example, a bunch of car dealers or car manufacturers,


how do you mark up a page for a specific car model


when there is no real price there, probably


because of all the variations?


It really makes it harder for the enterprise SEOs.


So I think this is an interesting question,


but I think it's worth looking at it


from the other point of view in the sense


that what makes sense for a lot of these rich results sites


is that you're aiming for a specific way of that content


being shown in search.


It's not that you're marking things up and saying,


well, I have this magical bonus just because I mark things up,


but rather you're trying to be present in a particular way


in the search results so that users better understand what


it is that you're offering and how


your website is the most relevant one for what they're


looking for.


So that's kind of the direction I would look at this from.


And when we look at the general products


that we show in the search results,


you're searching for a specific type of device


or a specific item, and then we can show the different prices


and the related items and reviews for those items


because it's very much tied to one specific thing.


When it comes to different car types, for example,


there's so many different variations,


and reviews match different variations,


and the prices are all over the place.


How would that be suitable to be shown


in this kind of generic product display


that we have in the search results?


I don't know.


It feels a little bit stretched to me.


So from my point of view, it's not


that these kind of sites that are selling cars


or that are manufacturing cars are in any kind of disadvantage


because, well, you can't fit a car into this one


small thumbnail image with a price and a review


and say, well, this is all there is


to it for this specific item.


So until or unless there is some other way


of showing this kind of content in the search results,


and I really don't know if anything around that


is planned, then that's something


where I wouldn't try to shoehorn the generic product markup


and structured data into the use case of something so,


I don't know, different, like a car, for example,


where you have all of these different variants


and variations and reviews and all of these things


that are quite different between the different types and models.


But that doesn't mean that you can't use


structured data on these pages.


We do use structured data to better understand pages


and to better understand when a page is relevant to be


shown to users.


So I would double check the schema.org list


where we have all of the different structured data types


and think about ways that maybe there is something


on the items that you're selling,


on the items on your website that is not being picked up


properly in the search results where maybe people are


searching for something similar but they're not really


finding your pages.


And think about if there is a way


that you can specify that clearer to search engines


that your page is actually about this specific type of item.


I don't know what exactly would match there


for cars in this particular case,


but you don't need to just focus on the car aspect here.


Maybe there are other aspects on your website


where you already kind of have the situation where


it's harder for people to recognize


what that page is about.


Because I imagine for car models, people


search for these models directly,


and we can probably already show those fairly well


in the search results.


When we add FAQ schema to a page,


does that show every time in the search results?


No.


It's never guaranteed to be shown in the search results,


so it wouldn't be the case that we would show it all the time.


I think we had that before with the other case with rich


results where there are different things that we


need to look at before we do show it.


And even when everything aligns, then we


try to limit ourselves to a certain amount of rich result


types in the search results page because otherwise it just


looks too overloaded with all of these different variations.


The European data protection regulation


requires consent requests for cookies.


The forum usually overlays the content as a layer.


And then there's some examples.


How can Google handle this?


Can Google differentiate it from advertising layers?


What is to be considered?


So I looked at your examples, and at least here


in Switzerland, I don't see those overlays.


So that's kind of hard for me to say


exactly what is happening there.


I generally assume that people put Switzerland


into the same bucket as the rest of Europe,


despite us being so unique and a little bit weird.


So I don't see those there.


I'm not sure exactly what the overlay looks like there.


So that kind of leads me to two aspects here.


On the one hand, Google generally crawls from the US.


So if we don't see those overlays in the US,


then we would not see those overlays for search.


So that's kind of the first one.


The other one is we generally try


to recognize these kinds of legal interstitials


and legal banners and differentiate those


from advertising banners.


So that's something that we have quite a bit of practice with.


And in the past, I thought we would


need to create a special markup so that you can specify,


oh, this is a legal interstitial, not


an advertising interstitial.


But it turns out that we actually


figure that out fairly well.


So for the most part, that's not a problem.


The one case where it is a problem,


and it's really, really rare that I run into cases like that,


is when the interstitial replaces the actual content


on the page.


So when you load that page, instead of the actual content


also being loaded at the same time,


you either get redirected to an interstitial page,


or the server only delivers the interstitial without any


of the content at all.


In a case like that, Googlebot would not


know that it would need to do whatever


it needs to do to kind of go through the interstitial


and load the actual content.


So that's something where, from a technical point of view,


we just don't have any capability to actually get


to the content itself.


Sometimes I see that with age interstitials,


where you have to enter an age, and then it redirects you back


with a cookie to the actual content,


and then it actually loads the content.


Usually, that's something where people are aware of that,


or they notice it fairly well, because all of their content


would be essentially gone from search.


We would just only have that interstitial page.


So it's usually a pretty obvious thing


if you look at the search results for your site,


and you see that none of my content is indexed.


It's not ranking for any of my terms.


And the snippet just shows, like, please


click here to confirm.


Then that's a pretty obvious sign.


Yeah.


Those are kind of the things that I would look at there.


How does Google treat templated content,


like on real estate and e-commerce sites,


where there are hundreds and thousands of pages


being generated?


So we don't do anything special with this kind


of templated content.


It's not that we would say, this is a real estate site.


They're allowed to do this.


And other sites are not allowed to do this.


But rather, we treat this content


as we would other content elsewhere.


That means if the whole page is duplicated across a website,


then maybe we would treat that as a duplicate page


and say, well, we'll just index one of these.


We don't have to index both of them.


If just a part of the page is duplicated,


we'll try to recognize that as well.


We'll generally still index that page.


And we'll try to show, when someone


is searching for that specific piece of content,


we'll know that this piece of content is on multiple pages.


And we'll try to show the most appropriate one for that user.


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


among all of these copies that we have,


which is the best one to show in this particular case.


And usually, what we try to do is filter out


the duplicates in those search results pages.


So you'll often see, if you go to, I don't know,


page three or four of the search results page,


it'll say there are some pages filtered out.


Click here to see them all.


And that essentially means that within the snippet


that we would otherwise show, it would essentially


show the same thing multiple times, which


is not very useful for users.


So we would filter those out.


So again, it's not that we would treat these kind of sites


in any way different.


It's essentially just we recognize it,


or those elements as duplicate content,


and we try to deal with that.


And there's no penalty for this kind of duplicate content.


So it's not that your site would be seen as less valuable just


because you have the same product


listings as other sites.


It's just we know that it's the same thing as on other sites.


So when people search, we try to pick the right one to show.


Can you talk about Google Discover


and put more light on Google Discover versus Google News?


So I don't know what there is really


to say about Google Discover.


It's something where we try to recognize


when content is relevant to users,


and we surf to them directly in the feed.


So from a website point of view, the tricky part


is there is no keyword associated with it.


There is no ranking associated with it because you're


somewhere in this feed.


So that makes it a little bit trickier to focus on


because essentially you have to create relevant content that


is useful for users that makes sense to be


shown to users at that time.


One thing I would think about when it comes to Discover


is that visual content tends to perform a little bit better


and that it draws people's attention.


So things like large images, if you


can mark up a large image on your page,


that makes it a little bit more interesting for people.


If you use AMP, then it automatically


uses the wider image.


If you use the, what is it, the max image preview,


robots meta tag, you can also specify a larger image


to be used in Discover.


I think that makes it a little bit interesting for users


when they're in their feed.


It doesn't mean that we would be more


likely to show your pages, but it makes it probably more


that people would click through and say, well, this is actually


pretty interesting topic.


You don't need to be in Google News to be in Discover.


Discover is based on essentially the normal web search content.


We do have a set of guidelines and policies for Discover.


So if you're really curious about Discover,


I would double check our Help Center on that.


Then a few other questions.


How can we use the Next Back button safely?


I'm not quite sure what you mean there.


So don't really have an answer.


How can we integrate affiliate marketing with news websites?


I know Google hates this, but I see big brands doing it.


So I don't know.


I'm not aware of Google hating affiliate marketing.


So that's something maybe just worth saying.


The one thing that we do tend to see with affiliate sites


is that there's often a tendency to just put minimal work


into them and to just say, well, I


have this feed of 100,000 products.


I will just create pages for 100,000 products automatically.


And if you're creating this kind of low value content,


then of course Google Search is going


to say this is low value content because that's what it is.


On the other hand, if you're creating really good content


and you have affiliate links in there, then go for it.


It's like that's a fantastic way to monetize your pages,


a fantastic way to get a reward for the work


that you're putting into these things.


Go for it.


There's nothing on Google's side that


would say using affiliate links within your normal content


is a bad thing.


The thing that we do say is creating low quality content


So it's not the affiliate links, but rather the quality overall


that I would focus on.


I've been charged by my company with reviewing our backlinks,


reading through old documents.


The company engaged in some unnatural building schemes


a decade ago.


I also discovered that the company made


use of one of those JavaScripts that


placed automatic attribution links with fragment links


on copy and pasted content.


My question concerns a later practice.


Has Google considered these automatic attribution links


natural?


So I really don't know how those links look like.


I am not aware of the older JavaScript things there.


Offhand, it feels like something that's probably not an issue.


But I really don't know how that specifically


looks like for your website.


In particular, in the past, JavaScript


would be one of those things that we would recommend.


If you don't want search engines to actually find something


on your pages, you can use JavaScript


to put a link on this page, for example,


and search engines won't use that.


In the last couple of years, of course,


search engines are capable of processing JavaScript.


So all of that is suddenly visible.


So my feeling is, offhand, that if this is something


that took place a decade ago, then on the one hand,


probably the intent behind those links


is not to manipulate page rank.


So it's probably less of a thing.


On the other hand, it sounds like maybe it's still


worth looking at that to see how would those JavaScript


links be looked at nowadays.


Is that something that would have an effect that you maybe


should care about and you should clean up?


Or is that something that continues to essentially not


have an effect at all?


The amount of not provided data in my analytics account


is steadily increasing.


How are we supposed to improve our SEO


when Google doesn't deliver the search keywords?


So I guess, first of all, I don't see the not provided part


going away any time soon.


This has been the case since, I think, before I joined Google,


that the referrer no longer shows any keyword information.


So that's something where I would not


focus on the referrer data that you're seeing in analytics


or that you're seeing in general when


you're tracking the referrer data for keywords.


I would really focus on things like Search Console, where


we do aggregate all of these keyword data


and we do show it in a way that makes it easier to use.


So that's the direction I would head there.


I honestly do not see that trend changing back.


It's been like this for a really long time.


It's something where probably the amount of traffic


that you're seeing with a referrer


is very minimal because we still have some holdback experiments


to double check that things are working as expected.


And it might be that some kinds of browsers


don't fall into the category where we can strip the referrer


out.


So those are probably the few things


where you would still be seeing that kind of traffic.


But I honestly don't think that's something


that would be going away or that I'd recommend focusing on


to try to get back.


The Google Burp update affected two of my websites,


and traffic dropped by 40%.


The only thing I'm doing is following Google's guidelines.


I haven't built a single link, and I


focused on creating content, user experience.


The site ranked in the top three,


and traffic was getting better day by day.


But after Burp, the site moved to the fourth and fifth page


with main keywords and long tail keywords remaining unchanged.


My site is the best user experience,


and average user stays are five minutes,


so a lot bigger than my competitors.


What's happening here?


So I think maybe first of all, this would not be from BERT.


So the BERT changes are particularly


around understanding queries better


and around being able to understand text better


in general.


So it's not that we would say that suddenly your page is less


relevant, but rather with BERT, we would try to understand,


does this question that someone is asking us,


does that match this website best?


And usually that's for more complicated questions.


So if someone is searching for, I don't know,


cheap smartphone, for example, then that's


a pretty obvious query.


We kind of know what to do there.


But if someone is asking for, where


can I buy a cheap smartphone when I'm not in India,


then suddenly that becomes a lot trickier because


of all of these extra elements within the sentence,


within the questions.


Like, well, India is mentioned, but you explicitly


don't want pages that mention India.


So those are the kind of things where


I would expect a site might see changes in long tail traffic,


kind of these more longer queries where


people are searching for something a little bit more


complicated.


And there I would expect to see more relevant results going


to those appropriate sites.


So some might see a little bit more,


some might see a little bit less.


But it wouldn't be the case that overall your website would


drop in rankings or be less visible because


of this kind of change because we're really just trying


to understand things better and to find which of these pages


are more relevant.


The thing to keep in mind is that we


make changes all the time.


We've made several core algorithm changes


as well over the last months or so,


which kind of overlap with the role of BERT as well.


So that's something where my guess is that these changes


here are totally unrelated to the BERT change,


but more just regards to the general algorithm changes


where we try to figure out which pages are more relevant, which


of these pages are better, higher quality,


how can we show the more relevant pages in the search


results.


So my recommendation here would be to not focus on BERT,


not focus on purely technical aspects.


So you mentioned user experience.


You mentioned speed.


It's something where I would really


focus on the site overall and the kind of improving things


overall.


For the core algorithm updates, we have a blog post


that has a lot of details on different things


that you could be focusing on.


So I recommend checking that out rather than worrying


too much about BERT and machine learning


and all of these crazy things.


Site speed concerns.


Let's see.


I think we talked about something similar like this.


Search Console doesn't show any data in PageSpeed Insights.


There's different results for desktop and mobile.


I understand speed is an important metric.


So how can I get the right data to be shown for my site?


I feel like I'm simplifying things


to run through a little bit.


Sorry if I got your question wrong.


So maybe the first thing here is that Search Console, as well


as parts of PageSpeed Insights, are based on Chrome User


Experience Report data, which is real world


data that is aggregated from users as they see your site.


And for smaller sites or sites that


don't have a lot of traffic, we might not have enough data


to make a meaningful judgment call here.


And that's completely normal.


That's not a sign that we're ignoring your website.


It's just a sign we don't have enough data to meaningfully


make a decision here.


So that's maybe the first thing to say here.


That's also very visible for larger sites as well,


where if you look in Search Console,


it'll say you have, I don't know, 10,000 pages indexed.


And the speed report says here 200, which is, well,


I have more than 200.


Why don't you show me more?


And that's mostly just based on we don't have


a lot of data for those pages.


The good part there is that this is based on people


who are viewing your website.


So it's not an artificial test of speed,


but actually of what people have seen on their devices


in real world conditions under all of the flakiness


of the real world.


The lab tests that are available in PageSpeed Insights,


where we test your pages and see how they perform,


that's something that is based more


on a theoretical calculation on how the speed would


perform in a browser.


And that's something that you can test, on the one hand,


in your own browser.


In Chrome, you can run the same PageSpeed Insights test.


You can also run the PageSpeed Insights test from our side.


So both of those give you some meaningful data as well.


And if you're seeing bad scores there,


then I would try to focus on the low-hanging fruit.


Usually, there are small things that you


can do that have a fairly big effect on speed.


So I would definitely double check those things.


I realize it's sometimes tricky with smaller sites,


sometimes tricky if you're focusing


on a specific region of the world


and you know Google's data center isn't nearby.


But there are almost always things


that you can do to significantly improve the speed.


Related to schema, Google says JSON-LD is the preferred


format, but JSON-LD is JavaScript,


and JavaScript is bad or takes longer to be processed.


I'm paraphrasing.


Sorry.


So yes, JSON-LD is JavaScript, but it's essentially provided


directly on the page itself.


So that's something that we can process right away


that all scripts can just extract from the HTML directly.


So it doesn't need to be rendered to be viewed.


It works right away.


So there's definitely no disadvantage


to using JSON-LD compared to using


microdata or some of the more HTML-based formats that


are out there.


We recommend JSON-LD because it's easier to implement,


because it doesn't have to be interwoven within your HTML.


It can be one big chunk that you put


on the top or the bottom of your page.


And we can extract that, and we can use that in one place


rather than having to parse the whole HTML DOM of a page.


Product structure data descriptions and H1 tags.


It's my understanding that meta descriptions and product markup


descriptions are two things.


For a product markup description,


is there a best practice, a number


of characters, description?


As long as a product markup description


matches the product appropriately,


is there a need to worry about the length?


I'm not aware of any restrictions regarding


the length of the description in the product structure data.


But I would kind of look at it more from the perspective of,


how will this be shown in search?


And think about how much text it actually


makes sense to show there.


So if you have a two-page article about your product,


then maybe that's a bit too long.


If you have just five words, maybe that's a bit too short.


Finding that sweet spot in the middle


is something that you kind of need to look at on your own.


And I don't think there will be one optimal length that


works for all products.


So I'd kind of focus it on that.


With regards to the description meta tag, that's similar.


We don't have any guidelines regarding the optimal length


of a description meta tag.


So that can be longer, can be shorter,


depending on your pages.


We don't use a description meta tag for ranking.


So there's no need to stuff keywords in there.


It's really something where I would try to describe


what your page is about.


And like you mentioned, it doesn't need to map one to one


to the product data as well.


For H1 tags, if a site has over 70% duplicate H1 tags


across the site, does that harm SEO?


Should H1 tags be diversified across the site?


So H1 tags are headings, usually the primary headings


of a piece of content on a page.


Usually, I would recommend matching those headings


to the actual content.


So it's clearer for us.


This piece of content can be simplified or kind


of titled with this specific heading that you have there.


We use H1 headings for the content itself,


for the text on the pages there.


We also use it for images.


So if you have images that are within this chunk of HTML


that's below a heading, then it's easier for us to say,


well, this heading definitely applies to those images


because they're a visible part of this page.


So with that in mind, using the same heading across the site


and larger parts of a site is kind of, I don't know,


wasting signals that you could be


using to give search engines more information


about the actual content on your pages,


where if you're just using the same thing over and over again,


then we say, well, we've seen this heading before.


It doesn't help us to differentiate


which page on your website is the most


suitable for this question that a user is currently having.


So it's not so much a matter of harming your SEO,


but you're not taking full advantage of all of the signals


that you could be sending search engines.


Multi-language websites and URL structure.


I took a look at this one beforehand,


so I'll simplify it as well.


Basically, you have some English URLs, like slash about us,


and then you have some French URLs,


which would be slash fr slash contacte nous, which


would be kind of like the French words for about us


or contact us in this case.


Does Google have a harder time figuring that out,


or is that OK?


So from our point of view, that's totally fine.


If you use hreflang annotations between these URLs,


that's perfectly fine.


Having a clear language or country code in the URL


structure makes it easier for us to understand


the language or the country versions


if you're not telling us about it with hreflang.


But if you're already telling us about this with hreflang,


then we would already figure that out.


So that's kind of the main thing there.


With regards to the language itself,


usually that's also less of a problem,


because we try to understand the language of a page based


on the content of the page.


So if you give us a French URL, a French page,


and the URL is just 1234, we will still


understand that that's a French page.


And similarly, if you give us an English page


and the URL is 3456, we'll still understand


that's an English page, even if the URL doesn't


have a clear identifier telling us this is in English,


or this is like an English keyword associated


with that page.


So the URL itself is not something


that I would use as a critical signal to say,


this page is in that language.


If you're using hreflang, then I would not worry about this


at all.


If you're not using hreflang, then having a clear language


or country ID in the URL makes it a little bit easier for us


to guess.


But probably we'll figure it out anyway.


Lots of questions left.


Let me see.


We have 10 minutes left, so maybe I'll just open it up


for questions from your side.


And if nothing comes, then I'll continue down the line.


Yeah, I wanted to know, like, very long URLs.


I mean, how long should a URL be according to your data?


How long should a URL be?


So you can pretty much make it as long as you want.


I think some of our systems are, like for web search,


I think we can pretty much deal with everything.


I think in Search Console, it's limited to something


like 2,000 characters per URL.


So that's a pretty long URL.


So I don't know.


I'd focus on shorter URLs.


I think it's easier to diagnose and to troubleshoot


and to monitor all of that if you have short URLs


with a nice structure in them.


But sometimes you have crazy parameters with IDs in them,


and they get a little bit longer.


But 2,000 characters is a lot of room.


So those tools that show, hey, don't exceed 140 or whatever,


just you can ignore that?


I think those are good practices,


but it's not that there is a critical limit.


Definitely not at 140.


It's more like around 2,000.


SPEAKER 2 OK.


Thanks.


SPEAKER 1 OK.


So quiet today.


SPEAKER 3 Hello, John.


SPEAKER 1 Hi.


SPEAKER 3 Hi, how are you?


SPEAKER 1 Pretty good.


How are you?


SPEAKER 3 Fine, thank you.


So I have two questions.


We have a 200 e-commerce site, and we


used to have a category pages and product pages


at the same depth, crop depth.


So that led us thinking that those URLs might


be competing with each other.


So we took the 10 category pages and raised them up a level.


Is this something that would take a while to process?


What is this?


It definitely takes a bit to process,


to re-understand that structure.


But I think it's a good idea to do that.


The main reason why I think it's a good idea


is that if, in general, with most sites,


the closer things are linked from their home page,


the more frequently we crawl them.


So especially with category pages,


that's one place where new products, for example,


would show up fairly quickly.


So it makes sense for us to crawl those category pages


a little bit more often so that we


don't miss any new product that you put on your site.


That doesn't mean that the category pages will


have more weight in search, but more


that we can find those new products a little bit faster.


And if people are searching for those new products,


we can show them a little bit earlier.


So that's generally why I would recommend this kind of structure


where you have the home page and then maybe the category


pages or something in between, and then that leading off


to the individual product pages.


SPEAKER 2 OK, so the other one is


looking at our internal linking report in the Search Console,


I see some long ago dropped URLs from index in the part that


says your page is linked to this page section


in each top linked page.


So does this mean that Google is still


taking this into consideration for working purposes?


That means we still have it in our database, essentially.


But if it's a really old page, then we


would keep that in there until we can reprocess that old page


and drop it out.


So if we haven't reprocessed that page in a really


long time, then there is minimal value


in that page from our point of view, in that link especially.


So usually that's a sign that we've seen this.


We know it used to exist.


Maybe it exists now.


Maybe it doesn't.


We don't really know for sure.


But we haven't had a chance to look


at this page in a really long time


because we don't think it's that critical to check that free one.


So for the most part, you can ignore that.


It's essentially just we found it.


We want to tell you about it.


It might be something that's older that you don't really


need to worry about.


SPEAKER 2


So I took a look at in Search Console,


basically when you submit a site map,


it's not like the old school.


I don't see you for some reason.


It's not like the old school Search Console


where you would submit the site map.


You would see something right away.


But now you have to wait.


Is that correct with the site map stuff?


Because there's a delay in site map for some reason.


Last week crawled November 6.


I'm just trying to troubleshoot the thing


as I'm talking to you in Search Console


for that particular site.


But it's saying last crawled was November 6.


And then even though you submitted, like.


Yeah, I don't think there's the Resubmit button that


used to be in the old Search Console.


So what you could do is do an HTTP ping for that URL.


So there's a special URL that you can construct.


And you just open that URL up in a browser.


And it has a text that just says,


thank you for submission.


And that essentially reprocesses the site map file.


The link for that should be in the Help Center somewhere.


Yeah, I would try that.


OK.


All right.


But you can't.


Anyways, right?


Sorry?


You'll take a look at it, I guess, when you get a chance.


Yeah.


OK, thanks.


In the chat, let's see.


There's some things around security alerts


with injected content.


I probably need to have some examples there.


So if you can.


I can give one about content injection.


So we had a security issue for content injections.


What is blog pages that haven't been re-indexed for three


months?


So how do we get those pages re-indexed?


Submitting a site map file would probably be a good idea.


If it's just individual URLs, you can use inspect URL


and submit those there.


So if you just want to double check that it's actually OK,


then I would use inspect URL for that.


One thing I've seen on and off is that hackers,


when they inject content in your pages,


they also add some cloaking to those pages


so that when you look at it in a browser, it looks OK.


But when Googlebot looks at it, it still has the hacked content.


And with inspect URL, you can double


check to see what content Googlebot would actually


see as well.


So that'd be it.


The other thing that we're using is looking at the core command


using different user agents and then comparing the content.


Everything good is just about re-indexing those pages again.


If it's just a handful, I would just use inspect URL


and do it manually.


I believe there is also someone that created a script that


does a little bit more automated.


But there's some limits with inspect URL.


So if you really have a lot of URLs that you need to submit,


I would just use a sitemap file.


Let's see.


Are reviews on Google Business a ranking factor?


Not for web search.


I don't know how that's handled within Google My Business.


I could imagine that maybe they do use them.


But for web search, we don't use them.


Will the next Webmaster Conference


be in German or English?


So we have one in Zurich that's lined up.


I think we'll have the plan is to have the registrations all


sent out today.


We're a little bit behind there, but we


said we would do it by today.


So we'll manage to get that out today.


It'll be in English.


So the content will be available to everyone.


It's a little bit bigger.


We have people from external as well


who are presenting something.


So I think it'll be cool.


We also have one lined up in Tel Aviv.


So if you're closer to that, that might be an option too.


We have some old low volume pages with mobility issues


in Search Console, but they haven't


been re-indexed in three months.


How can we force re-indexing to get the error to go away?


So if it's flagged as a coverage issue in Search Console,


then you can request verification


through Search Console, which will speed up crawling


a little bit of those pages so that we can get through those


a little bit faster.


But otherwise, I would focus just on sitemap files,


kind of like before.


Let's see.


There's another question about BERT.


How would BERT affect Chinese search queries?


I think at the moment it doesn't affect it at all.


So in the blog post, we explicitly


said it was for English content.


Some of these kind of natural language understanding models


are very language dependent, and we


need to figure out how things work well in one language


first before we can generalize them to all other languages.


So sometimes that takes a little bit of time.


I could imagine, especially with languages like Chinese


where there's lots of variations and where it's a lot harder


to kind of extract the meaning from a sentence that


might be a little bit harder.


But I'm pretty sure there are people working on that too.


I'll just continue going down the list until any of you


step in with questions from your side.


Does Google ever strip off parameter values


for managed parameters when crawling URLs?


A client is seeing empty applied parameter values


in their log files, but not in their internal linking.


Could these be legacy URLs that Googlebot


has seen in the past?


They could be legacy URLs.


They could be things from the parameter handling tool


where we're just dropping the parameter values


because the parameter handling tool says


the value is irrelevant.


We do try to figure that out algorithmically as well.


So the parameter handling tool is your way


of telling us about this.


But a lot of people don't use that tool, which is fine.


So we try to figure that out as well.


A really common use case, or it used to be really common,


is session IDs in URLs where every time you access a page,


it would use a different session ID as a parameter.


And that's something that we also try to understand


automatically so that we don't overload your server crawling


all of these session IDs.


So that's kind of a really simple example,


but that applies to a lot of other parameter values as well.


The more we can optimize our crawling for your website


by limiting the parameters that we use,


the more we can crawl more efficiently,


which means the more frequently we


can crawl your important URL.


The more frequently we can crawl your important pages.


So that's kind of a win-win for everyone.


SPEAKER 2 I have another question about if there's time.


JOHN MUELLER 1 All right.


Go for it.


Live questions are great.


SPEAKER 2 So I know that you talk about taking low hanging


fruits, but I would like to know what Google used for ranking.


Are they using the score, the performance score?


Are they using the speed index for first content with pain?


Which one are they using for the rankings?


JOHN MUELLER 1 Everything.


Well, probably not everything.


But we use a mix of lab data and real world data.


So it's not that we focus on any specific score


or that we would say that we use any specific score,


but we try to use a mix that matches what


we think is representative of speed for that website.


So on the one hand, it makes it a little bit trickier


because you can't see exactly what score


Google is focusing on.


On the other hand, that makes it a little bit easier for us


because over time when new kinds of metrics


come up which we can better understand the speed for,


we can use those rather than being tied to some old school


score or test that's happening.


So that's kind of the mix that we try to apply there.


So if you want to do SEO just for speed,


then I would focus on speed in general


and focus on the areas where your site is being seen


as slow rather than trying to just take one metric


and try to get 100 on that.


So we used to see this a lot with page speed insights


where people would say, I'm going to optimize my site


until it has 100 there.


And you can optimize a site to have 100 there without it


actually being a fast website.


So there are tricks you can use to make


it look like it's really fast to a specific testing tool,


but it's actually still pretty slow for users.


So instead of doing that, I would


recommend making sure that across the board


your site is pretty fast.


All right.


Let me take a break here to pause the recording.


If you want, you're welcome to stay on


and we can chat a little bit more.


But anyway, it's been great having all of you here.


Thank you for submitting so many questions


and bringing questions into discussion as well.


I hope you found this useful, and maybe we'll


see each other again in one of the future Hangouts.


Thanks a lot, everyone.


Google Search News (April ‘21) - Page experience & Core Web Vitals ranking change and more

Hi, everyone, and welcome back to the Google Search News.


I hope life is treating you reasonably well wherever


you are.


I'm your host today, John Mueller,


here from Google Switzerland.


With this show, we want to give you


a regular summary of what's been happening around Google Search,


specifically for website owners, publishers, and SEOs.


If you find these useful, which I hope you do,


and if you'd like to stay up to date,


make sure to subscribe to the channel.


It's been a while since we last saw each other.


There's been so much keeping us busy lately,


which is why it's good to have these videos from time to time.


In this episode, we'll be covering


an update of the page experience ranking change,


video best practices, Search Console, and more.


So without further ado, let's dive right in.


Starting us off is the page experience change.


As you may recall, this is an upcoming ranking change


which takes into account the user experience on web pages.


It includes technical elements like HTTPS,


as well as quantifiable metrics for speed and responsiveness.


We just published some additional information


on this change.


Here are a few highlights.


First off, you have more time.


We moved the start of the rollout to mid-June.


The change will take place slowly


over the course of two months on a per-page basis.


This gives you a bit more time to improve your website


before things start off.


And to be clear, this is just one of many factors


that our systems take into account.


There's no need to do a scramble.


Take the time to find good solutions


for your websites and your users.


Every website is a bit different.


The core web vitals part of the ranking factor


is based on real user metrics, which


take a while to be collected and which are automatically


updated over time.


Making improvements at any point will be reflected there.


A website doesn't need to be and rarely


is perfect from the start.


You'll start to see positive results as your pages pass


the needs improvement mark.


We also plan on using these factors for the top stories


carousel and within Google News.


Additionally, signed exchanges will


be available for all web pages.


In short, signed exchanges is a setup


that enables Google Search to prefetch your pages in a


privacy-preserving way to make the experience for your users


even better.


There are a lot of details in the blog post


and even more answers in an FAQ post in our help forum.


I'll link to these below.


Wow, so much information about this particular search change.


I hope it's not too much, but let


me know if there's something we should cover more.


Luckily, there are also folks outside of Google


who are fantastic at explaining some of the technical details


and practical aspects.


For example, recently I saw an amazing guide


on cumulative layout shift, or CLS,


which is a part of the core web vitals.


It includes explanations about the metric, different ways


to measure it, and a bunch of really practical tips


on how to improve your pages for it.


The guide was written by Jess Peck,


and I'll link to it in the description as well.


Next up, and it almost feels a bit


recursive to talk in a video about a video about videos.


Anyway, here is an update on video best practices.


Video is a fantastic way of reaching people,


and it doesn't even need to be a news video like this one.


We've been improving how videos are shown in search results.


To help your site to take advantage of these changes,


we've updated and expanded our documentation


on video best practices.


This includes a video from Danielle,


who actually works on the video search team here at Google.


Wow.


In the updated documentation, you


can learn how to help Google to find your videos for indexing.


Additionally, you can learn about ways


to express how you'd like your videos to be highlighted


in search.


If you've been including videos in your web pages,


you may already be aware of some of these things.


Regardless, I strongly recommend double-checking


to make sure you're using all the available features


to your best advantage.


And of course, if you haven't been


making videos for your web pages,


perhaps it's worth giving it a shot.


Now over to our evergreen topic.


Google Search Console.


Search Console is a way of finding out


how your website is doing with regards to Google Search.


Where and how are people finding your website?


Are there issues holding your site back?


There's much more, though.


To get started, just verify ownership


of your site's domain name.


Within Search Console, we recently


added regex support in the performance report.


With regex, some people mistakenly call it regex.


You can enter patterns instead of words for matching.


You can use it for the search queries, as well as


the pages shown in the report.


It's been one of the most requested features for Search


Console, so it's cool to see it here now.


Additionally, we've added a special report


for the page experience update, which covers


all of the elements involved.


At a glance, you can see how your site is doing.


In particular, how many pages are


seen as reaching the fairly high threshold of good


across the metrics, how the site is


doing in terms of mobile usability,


and all of the other aspects of the page experience factor.


This is the first time we've put together


such a comprehensive report for a specific ranking change,


and we hope it makes it easier for you to improve


your website for your users.


That's almost it.


But wait, there's a bit more to mention.


For example, the web creators team at Google


has been busy making lots of content


for all of the amazing folks, like you perhaps,


who regularly create content of their own for the web.


This includes, but isn't limited to bloggers, for example.


The team has created videos and articles


to help with complex topics like monetization and better


understanding of your audience.


Similarly, on this channel, we've


started a series on sustainable monetized websites,


where we cover other aspects of monetization,


in particular, explaining how to take into account


the various policies and guidelines that apply.


Finally, also on this channel, we've


been actively publishing Search Central Lightning Talk videos.


These are short videos on specific topics


similar to how we might present them at events.


Physical events are not taking place for now,


so we hope these tide you over.


They cover important topics and hopefully


make it a bit easier for you to be successful on the web.


And on the topic of events, I also


wanted to call out Google IO.


It's taking place mid-May and will be held virtually.


There are lots of sessions, including some live Ask Me


Anything slots.


I'm sure it'll be neat, so make sure to register ahead of time.


And that's all for now, folks.


Thank you for watching this episode.


It always feels good to me to look back and pull together


the things that really stood out.


I hope you find it useful and insightful as well.


If there are elements you'd like to have covered differently,


then please let us know in the comments below


or drop me a note on Twitter.


If you'd like to see more of these episodes,


make sure to subscribe to the channel.


We're regularly publishing new videos here.


I'm sure there's something coming up which


you'll appreciate as well.


And as always, I look forward to seeing you all again


in one of the future episodes of the Google Search News.


Bye, everyone.


Within Search Console, we recently


added Regex support, Regex, Regex,


with Regex, which some people mistakenly call Regex.


With Regex, some people mystique,


this is going to be terrible.


It's Regex, Regex.


How to grow your WordPress site with Site Kit? | Search Central Lightning Talks

Hello, and welcome back to the Search Central Lightning


Puck series.


This time, we'll talk about WordPress sites


and how to make sure your website is working for you.


My name is Maria, and I'm a product manager in the Search


Ecosystem team at Google.


I'll show you four steps you need


to take to make sure your site is all set up


to help your business, and then we'll


look at some real examples of how to apply these steps.


The first thing you need to do to have a successful site


is to translate your real-life business


goals into online metrics.


You know why your business exists.


Maybe you have a shop where you want to sell Swiss cheese,


or maybe you're writing a blog where


you talk about traveling to parts of the world.


But how can you know if you're doing well


in the online world?


So for example, if you have a blog,


one thing it might be worth to keep track of


is what portion of your readers are visiting only once


and what portion come back, as well as how much time,


on average, each of these groups is spending on the site


and how many pages they're looking at.


And if you have a shop, you might


want to keep track of cart completions


on the online version instead of sales in the real world.


So once you determine what type of site-related metrics


you should track exactly, you need


to define what tools provide them in a reliable way.


You need to check things like how comprehensive the data is,


what the sources are, and does it


answer all of your questions, because it might turn out


that you need to mix information from a few different tools


to get the full picture of how your site is doing.


And of course, usability and price factor in here as well.


Can you make this work with your site?


If it requires a significant learning curve


to just start using it, then maybe something else


would be a better option.


Or maybe it provides really interesting data,


but it's charging you every month,


whereas you could find the same data somewhere else for free.


Once you pick the right tools for your purposes


and set everything up, the data will start aggregating.


The most important thing here is to set a baseline


so you can compare and track improvements later on.


How is your site doing right now?


How many cart completions are you getting per day?


Or if you have a blog, what's the breakdown


of new versus returning readers?


You probably need to track this for a few months


to get a solid set of data and really draw any conclusions.


Be patient.


If you don't know your site's baseline,


you would know if you're improving or not.


And of course, when you set a goal,


the other thing is to be realistic.


We very often hear things like,


oh, I want to show up for a word such and such


at position number one in search results from site owners.


But depending on how competitive your industry is,


this might not be something worth chasing after.


Even if you're showing up for a specific word


in a specific place, people actually don't visit your site


from the search results.


Finally, it's important to remember


that this is an ongoing process.


It's not a one-time setup.


Think about what actions you can take


to improve specific metrics that are important


to the success of your site,


and then commit to following up


when you see the metric change in either direction.


Also, set a schedule to check in on your site regularly.


Soon, you'll notice seasonality or weekly patterns,


and you'll get a feel for what to expect.


Now that we've seen the four principles in action,


let's look at how this would work in practice.


Taking the example of Rosemary Rocket,


who's a blogger writing about her travels


on a WordPress site.


Rosemary makes money in two ways.


The first is from recommending places to stay


and things to do in all the countries and cities


she has already visited.


She places links, which give her a small commission


when people book via her site.


So one good online metric that she needs to track


to understand how well her website is working for her


is the click-through rate, or CTR, on these links


in her blog posts about different destinations.


Rosemary also offers a service


to help build out an entire trip for people


to a specific destination.


Online, people can sign up on her site


to get a custom retainer rate for her.


So a good metric would be to track completions


of the signup form here as well.


And now that she has defined two concrete,


detailed metrics to keep track of,


it's time to track down which tools


might have that information.


In the case of click-through rate, or CTR,


for her booking links, some good options might be


to set up goals in Google Analytics to track the clicks


and then compare these to page views


for each post containing a link.


Additionally, it would be a good idea


to understand which posts are most popular in search,


which is available in Search Console,


and how people find these posts,


which is also in Search Console,


where you can see all the queries


that your site is showing up for in the search results.


For the other metric, how many people completed the form,


it's possible to set up a tracking goal


in Analytics as well.


And it would also help to track bounce rates from Analytics


and understand how people find the page from search results


via the search query information in Search Console.


We know all of this can be a lot.


You have to translate your goals


into concrete online metrics.


You need to find the right tools.


You need to track down specific stats in each tool,


and you need to log into 17 different things every day


to check in on everything.


It's tough.


That's why we made SiteKit.


SiteKit is Google's official WordPress plugin,


and it brings the most relevant stats and functionality


from key Google products directly


in your WordPress dashboard.


So when you log into your site,


you can have a look at how you're doing right there


in your dashboard without needing to visit


multiple other places or download stats somewhere


to compare them in a spreadsheet or something.


A simple, easy to understand dashboard will save you time,


and it will help you get insights instead of just numbers


because everything is together in one place.


We made SiteKit extremely easy to set up.


It places all the necessary verification


and product snippets in the right places of your site


on your behalf, so you can complete the setup


with just a few clicks without having to figure out


how to modify the source code of your site


or do anything else complicated technically.


You can literally set it up in a couple of minutes,


and in the process, we'll also help you define your goals


and translate them into online metrics


by asking you a few simple questions.


For example, what's the goal of your site?


Is it to write a blog?


Is it to publish news or something else?


And what you need most help with?


For example, do you want to grow your audience?


Do you want to expand to a new market?


Or do you want to make your site faster?


Once you figure out what your goals are,


SiteKit will give you tips,


what metrics to put on your dashboard to customize it


so you can track the most relevant things


for you and your site.


It will also give you updates on how you're doing


related to your goals over time.


If you've done the setup,


but your site is new to Search Console,


it might take a day or two


before you begin seeing stats in your dashboard.


So take a break and come back in a bit


to check out the first stats


or set up some of the other Google products


like Analytics or AdSense.


If you're already using them for your site,


you'll see data right away.


With some data available over time,


now it's time to set a baseline.


How many people visit the site per day?


20, 2000, more?


Is it different on the weekend?


And what about where they visit from?


All of this is available in SiteKit's All Traffic section,


where you can filter by location, device,


and traffic source, and also see trends over time.


Set the expectations right,


especially if your site is new.


It might take a while to find your audience.


It's the same like opening up a new store in town.


It's not enough to just open.


You have to think about attracting shoppers as well.


Here's some useful questions you can ask yourself


to get orientated in how people experience your site.


Which are my most popular posts?


What do they show up for in search?


How do people find the sign in general?


In search or via other channels?


Does that match my expectations?


How would I like people to find me


and what can I do to change that?


SiteKit provides you a neat funnel


using a combination of stats from both Search Console


and Google Analytics,


where you can trace how many times


your site appeared in search,


out of those people, how many actually visited your site,


out of them, how many were on the page,


and if they actually completed the goal


that you wanted them to,


in case you set up goals in Google Analytics.


There's also information about your most popular pages


and also the top search queries,


how people find you in search,


available on the main dashboard.


You can get a detailed view for a specific page


by using the search field on the dashboard


or simply by accessing the stats


directly from the admin bar at the top


when you're looking at the live page


and you're logged into your site.


There's many useful things to check here.


For example, you can see


how people found the specific page in search


because all the search queries are listed


or you could check the bounce rate


which is available from Google Analytics.


And if you run out of ideas what to write about,


SiteKit has a really neat feature


which will show you unanswered questions


directly from search that are related to your site's content.


So you can use these topic suggestions as inspiration


to create new posts for your site


and give even more useful information,


potentially get some new visitors.


Of course, all of this information is only useful


if you take action on it.


So how to do that?


Here are a few examples.


If Rosemary's top queries


are about restaurants in Singapore


but the pages with highest click-through rate on her site


are about hotels in Bangkok,


it might be a good idea to consider


readjusting what she writes about,


adding more of the content


that attracts more people to her site.


Similarly, if one of the main services she offers


is planning trip itineraries to Japan


but she's seeing that the top viewed pages on her site


are about trips to Indonesia,


maybe that's a new business opportunity


to expand her service offering.


You need to continuously track what's going on


and adjust your strategy


depending on what the metrics are telling you.


This is an ongoing process.


Take into account factors like seasonality


and how competitive your industry is


to put your site's performance into perspective.


SiteKit will help you


by showing you regular summaries of how you're doing