in that we would only report on the canonical version


English Google Webmaster Central office-hours from February 21, 2020

that we use for indexing.


I don't know if that kind of aligns with the thing


that you're seeing there with regards to your website,


but that is something that is a bit confusing


and I think which would be nice to have a little bit less


confusing on our side, but it's a pretty hard problem.


But anyway, I'll double check your forum thread


and see if there's something that we need to pass on


to maybe the indexing team.


I have a Canadian domain with Search Console geotargeting


set to Canada, but I've noticed that the US traffic has


been increasing lately and surpassing my Canadian traffic.


My site is an e-commerce site, and this


is causing a decline in conversion rate.


Is there a way to correct this issue


and communicate with Google to rank my site mostly in Canada?


Should I add hreflang tags?


I don't have a.com.


So I think the tricky part here is


we don't have a mechanism for people to say,


don't show my site in this country


or don't show my site in other countries.


But rather, when we find one website,


we may assume that this is something


that is globally relevant, even if it's on a country


code top-level domain.


So in particular, it's completely fine


to have a global website that's on a country


code top-level domain, and we'll try to rank it globally, where


we think that it makes sense.


And I think that's probably what's happening here,


in that we think your website is pretty good,


and we would like to show it to as many people as possible.


And we don't realize that actually you're not


able to serve them, or you don't want to serve people


in those specific countries, so you'd


prefer not to be shown there.


This is something that sometimes comes up,


where you don't want to have your site shown


for people in other countries.


But so far, we haven't really had any strong reason


to try to provide extra functionality or meta tags,


where you can say, discourage my site from being shown here


or only show my site here.


In particular, geotargeting is something


that helps us to promote a site in a specific country,


but it doesn't mean that we won't show it


in other countries.


What I would try to do here is just place a banner


on your website so that when users come to your website,


they're aware of what you're targeting


or what you're able to provide.


But in general, that's not something that would,


I don't know, would be seen as a negative on our side.


Also, with regards to the conversion rate,


that's not something that we would use for Google Search.


So at least from the Google Search side,


that's not something you'd need to worry about there.


It's probably more a matter of understanding your site's


analytics a little bit better and then finding a way


to make sure that you're not misled by seeing numbers that


are irrelevant for your website.


I've been having an issue lately where Google is using text


for my site's navigation in place of a meta description.


It's content that's not useful for users,


and this is across multiple pages and queries


and sections of the site.


I understand you'll sometimes replace the meta description,


but this is kind of puzzling.


This can happen, this kind of thing.


In particular, what happens is when


someone searches for something and we would show pages


from your website, we try to show them


a snippet of your page that matches


what they were searching for.


So to give them a little bit more context


about why your page is the best one that they


should be clicking on.


And if we can't find that information


within the description meta tag, then we'll


try to pull out some information from the rest of the page.


So that's something where if the best matching or, I don't know,


the most relevant match that we can find


is from your site's navigation, then we'll


try to pull it in from there.


But one thing I would try to do in a case like this


is just to make sure that your site's description meta


tag or the tags that you have on the individual pages,


that they're actually kind of aligned with the queries


that you think would happen there


and that they really describe what


is happening on this page, that it's not


kind of a generic set of keywords


that you're providing, but rather really a good


description that we can show for these kind of queries.


And the other thing I would watch out for


is if you're using a site colon query to pull out these pages


and to double check them, then keep in mind


that the site colon query is an artificial query from our side.


And the title and the description


that you'll see in the search results


does not necessarily match what a user would see when


they do a query on their own.


So instead of doing a site colon query,


make sure you're using the queries that


are shown in Search Console so that you kind of see


a little bit more what users would actually see.


I'm confused by the mobile usability


report in Search Console.


I have a main site and a mobile site, which


are correct with canonicals.


The problem is that the mobile page, pages that Google reports


via the Enhancements tab, seem to be steadily dropping


for no reason.


These pages have been OK, and there's no error showing.


So one thing to keep in mind with all of the enhancement


reports, and in particular also the mobile usability report,


is that we report on a sample of the pages from your site.


We don't report on the complete set of index pages,


but really just a sample.


Sometimes that sample can change.


And that sample can change over time as well.


So if you're seeing that all of your pages


are mobile friendly, for example,


and the number of pages that we show as being mobile friendly


are dropping in that report, that's


not a sign that you have fewer mobile friendly pages,


but rather we're just reporting on fewer pages


from your website with regards to mobile usability.


So instead of the absolute number of pages


that we report there, I would focus on maybe the percentage


or the part of those pages that have issues


and use that as a guide to help resolve things.


So don't focus on the number of pages in the enhancement


report, but rather focus on the issues that


are flagged there and their relevance


with regards to the total reported pages.


After the January Google update, the amount


of Googlebot crawling on our site has been cut in half.


And during this time, I didn't make any changes to a site.


Let's see.


So I think in general, with regards to crawling,


we have multiple things that come together.


On the one hand, we have the crawl demand,


which we call it, which is the number of pages


that we want to crawl or that we think are important to crawl.


And that's something that can change over time.


That's something where also with algorithm changes,


it can change over time as well, where


if we think that a site is perhaps less relevant overall,


then maybe we'll not crawl as many pages from that site


because we're finding trouble showing it in a relevant way


in the search results.


So we don't want to put an extra load in situations


where we're not able to actually present that page


that well in search anyway.


So that's the one thing.


The other side is the load that we can put on a server


from a technical point of view.


And that's something that we determine automatically.


That's based on the speed of the server and the errors


that we see back from the server.


So if we find that a server becomes slower in responding


or a server is sending us more server errors,


so 404 errors are fine, but more like the actual server


errors where the server is saying,


oh, I can't deal with all of these requests,


then that's something where we'll decrease


the amount of crawling as well.


So those are the two aspects there.


On the one hand, the demand.


On the other hand, the load that we can put on a server.


And the other thing that also plays a role when


it comes to crawling is our algorithms


try to find ways to optimize crawling in general.


So in particular, if you have a lot of complicated URL


parameters, then over time, we'll


try to learn which of these parameters


are actually relevant.


And we'll try to focus on the relevant and useful parameters


instead of all of them.


So that's something where you can also


see a decline in crawling, which is essentially a good thing


because it's like Google is learning to crawl the more


relevant URL.


So one way you can determine if that's the case or not


is to look at your log files and see what Google has


been crawling in the past and what Google is crawling now.


And if Google is just crawling better or more efficiently now,


then the decrease in crawling can be perfectly fine.


Might be a good thing.


On the other hand, if you're seeing


that this decrease is not based on a better sample of URLs


that is being crawled, then I would try to figure out,


is it because my server is slow and problematic, which


you can see maybe in general the server response time


that you have?


And looking at your logs, how many server errors


are you returning in general?


Or it might be that our algorithms just


think that maybe it doesn't make so much sense to focus as much


on this website in general.


And that could be a subtle hint that maybe there's


something that you can do to significantly increase


the quality of your website.


All right.


The question goes on.


Google launched a number of updates this week.


I saw a big fluctuation in third-party tools


on the 18th of February.


My keywords have been missing over 20%.


The Search Console shows my on those dates lost 90% traffic.


Our site has been doing all of the right SEO,


like long-term stable link building.


Can you tell me what I should do in this case?


So I don't know, this long-term stable link building,


that seems like a slight red flag perhaps.


I don't know exactly what you're doing there.


So that's something where I'd be a little bit cautious.


I am not aware of anything specific


that launched in the last couple of weeks


with regards to Google search rankings.


So to me, this sounds more like our algorithms


are trying to figure out a little bit better where


we can show your site in a relevant way.


And sometimes that can result in a less visible site overall.


So that's something where maybe I would go to the help forums


to get some input from other people


as well, just to make sure that you're not


missing anything obvious.


If we have a canonicalized page, page B to page A,


but after a while we thought it was good enough


to have content on page B that's not present on page A,


so we decide to self-canonicalize.


And the other way around, will Google consider it?


How will Google crawl and index it?


How much time can it take?


You can change canonicals.


That's totally up to you.


If you go from one page to another, if you want to do that,


that's perfectly fine.


That's something where, like a redirect,


it can take a bit of time for us to process that


and to switch things over.


And the rel canonical is, for us,


one of the signals with regards to which


page to pick as a canonical.


But it's not the only one.


So if you're changing which URL you


want to have shown as a canonical,


then make sure you align it with the one


and make sure you align all of the other signals


with that decision as well.


So in particular, things like internal linking, sitemap


files, if you're referring to this page in other ways,


such as in structured data with hreflang,


then make sure all of that aligns


with your choice of canonical.


But ultimately, that's your choice.


We try to pick that up if we can.


We can't guarantee that we'll pick the canonical


that you choose.


In particular, because if you're using the rel canonical,


you're telling us these pages are equivalent.


And if these pages are truly equivalent,


then it doesn't really matter which of these we index, right?


It sounds like those pages are not


really equivalent on your side.


So that's something where maybe it also makes sense


to reconsider how you're doing canonicalization there


with regards to pages actually being duplicate or not.


The images on our site aren't indexing.


I don't know why.


I analyzed the log files and noticed


Googlebot image gave 200 status code.


And when I tested the pages with images,


I saw other errors with regards to all images.


I cannot be connected.


How can I solve it?


I don't know specifically what you're testing there.


But I probably need to take a look at the site


more exactly to see what might be causing a problem there.


In general, when it comes to images,


we need to have image tags on the pages


so that we can recognize which images belong to which pages.


And we need to be able to crawl the images that you


specify there.


So in particular, if you're doing something


like progressive enhancement or responsive images


where you're swapping out images depending on the device


or depending on the viewport or kind of lazy loading


those images, then you need to make sure


that Googlebot is able to understand which images


actually belong to that page.


So having clean image tags pointing at the actual image


URLs is really critical for us.


So that's something where some kinds of lazy loading,


they cause issues in that we can't recognize which image


you're actually pointing at.


So that might be something where I double-check those pages


to see, is Googlebot actually able to see image tags


on that page with a proper source attribute there?


And then double-check those images with regards to,


are they able to be crawled with regards to the robots.txt file?


The tricky part here is that the Inspect URL tool, which


you can use to test crawling, only applies to web pages.


So you can't test images with the Inspect URL tool.


But what you can do is use Inspect URL for the HTML page


where you have the images embedded,


and then look at the rendered HTML code that's


in a separate tab there where you can double-check


to see if those image tags are actually


being rendered and recognized.


Is photo metadata important or not?


It's not going to make or break your site.


So it's not the number one ranking factor.


But you can put some more information in photos.


And sometimes that makes sense for us to understand.


I would say for most websites that are just


interested in having the normal web search rankings, well,


for web search rankings, you definitely


don't need photo metadata.


With regards to image search, that's


something where for most websites,


probably the photo metadata is not important.


We recently launched a functionality


where you can specify licensable images on your pages.


That might be something where if you have those kind of images


that you're able to license to other people,


well, that might make sense.


And that's essentially kind of photo metadata.


If I'm changing my platform from 6 to WordPress,


will it affect my rankings?


And having different niche content on a subdomain


is good for ranking or not.


So if you're changing your platform,


definitely it can affect your rankings.


Because essentially what you're doing


is you're revamping your website.


You're recreating a new version of your website.


And when you do that, then that's


something that can have a positive or negative effect


on your site's ranking because suddenly your pages are


completely different.


If your internal site structure is also completely different,


then that, again, can have a positive or negative effect


on your site's rankings.


If you're changing the URLs on your website,


then one thing you need to do when


it comes to changing platforms is


to redirect from all of the old URLs to all of the new URLs.


Because if you don't do that, then essentially all


of the information we have collected over time


from your old website will be dropped because suddenly all


of those pages are invalid.


So if you're changing the URL structure,


if you're changing the URLs on a site,


always make sure to set up redirects.


I'm in a news vertical, and I often


see stories, time stamps that are not properly represented


in Google Top Stories carousel.


We run into many instances where the time is being pulled.


It's very old.


What could be causing this to happen?


We update the last mod for the story in our news site map


to structured data and the on-page timestamp reflect


any new updates.


It would be really good to have examples of this,


which we can double check.


The most common cases where I see this happening


is where there is a conflict with regards to the data


that we were able to see for those individual pages.


And sometimes that's a matter of time zone.


For example, if one of the date stamps


that you're using has a time zone and the others don't,


then without a time zone, we really have to guess.


And sometimes our systems are able to guess properly,


but that's kind of, I don't know,


relying a little bit too much on Google systems


trying to figure it out.


So I would really double check those kind of cases


to make sure that everything is really aligned,


that all of the time zones are specified exactly the same way


so that there's really no confusion at all from Google


side with regards to how that should be presented in search.


And if you see cases like this, then by all means,


send me some screenshots so that I can double check with the team


to see what might be causing that.


Wow.


Oh my god.


Still so many more questions.


Let's see.


There's something with regards to structured data


for academic content.


I don't know.


So I think that's specifically around kind of the education


program that we sometimes show information on in search.


I don't know specifics with regards


to that particular setup.


So it's not something I'd be able to help with specifically.


But if you could set up a forum thread,


that might be something that we could escalate to the team.


I have a travel agency blog.


One of our guests wrote a great blog covering the tour


that we arranged for him.


He already posted it on his blogger site.


However, he'd like to publish it on our website too.


If we publish it on our website, will we


get a duplicate content penalty or any other penalty


from Google?


No.


There is no duplicate content penalty.


If you're publishing something that's already published


somewhere else, it's not that there's


going to be a penalty on this content,


but rather if someone searches for something


from that piece of content, then we'll


try to show just one of those pages in the search results.


And that might be perfectly fine.


That might be your version.


That might be the original version.


That depends on a lot of other factors.


But there is definitely no duplicate content penalty


for something like this.


And if you're worried that something like this


might be problematic with regards to ranking


and you want to make sure that you don't kind of negatively


affect the original blog post that they wrote,


then you can always put a no index on these pages


so that they're findable within your website when


people go to your website, but that they don't show up


in search.


But in general, if this is kind of like every now and then


it happens that someone writes a blog post


and you also have the same blog post on your website,


then that's perfectly fine.


That's not something I would worry about.


Let's see.


My main site is hosted by SiteGround.


I also have 48 other sites which are hosted by them.


All 49 are in the same account on SiteGround.


If I move my main site into a separate account,


do you think the traffic for my main site might improve?


I don't think that would change anything.


We probably wouldn't even know that these


are all in the same account on the SiteGround site.


So I don't think that would affect anything.


The only comment I would have here


is if you have 50 websites that you're hosting like this,


then sometimes it makes sense to concentrate all of those


into one really strong website rather than to have 50,


let's say, mediocre websites.


So that might be something where instead of spreading yourself


thin like this and creating all of these individual websites,


maybe you'd see a more positive effect


by having one really strong website where you're really


focusing all of your energy into that website


and making sure that one website is as awesome as it can


possibly be.


So that's something where it's not tied to the hosting setup


that you have, but just generally speaking,


when you spread yourself thin, then it often


results in sites that are kind of subpar.


OK, wow.


We're kind of running out of time,


and I'm running out of breath.


So maybe I'll just open it up for more questions


from your side.


Is there anything that I can help with?


Hey, John.


Hi, it's Amos here.


Hi.


I was wondering whether you could give some guidance


in terms of reporting on performance for a website.


So the efforts that SEOs put into optimization


of their site, how would you then


report that to the business in terms of progress?


Yes.


I don't know.


It feels like I have to completely switch gears.


Yeah.


I think there are always two kind of metrics that


come out of work.


On the one hand, you have the effort-based metrics


where you're saying, I've done all of these things.


And on the other hand, you have the more impact-based metrics


where you say, well, these things


have resulted in these changes.


And ideally, you'd have a combination of both of those


that you'd be able to kind of pass on and say, well,


I did all of these things.


These are in line with these best practices.


I did these because of maybe there are issues


or maybe there are improvements that could be done here.


And these are the changes that we've seen so far.


And sometimes doing things and the changes that you see


are a little bit skewed time-wise


so that you do a lot of things, and it takes a while for that


to be visible.


But kind of documenting both of those sides, I think,


is useful to do.


And in the performance reporting Google Search Console,


what I struggle with is reporting


on brand versus non-brand performance because


of the sample data.


Do you have any suggestions, recommendations


on how to then communicate that to the business on how things


are going from a non-brand perspective


for a site that has a lot of traffic coming through brand?


I think one of the things I would try to do there


is to pull that data out maybe with an API


or through the download so that you can separate


the branded and non-branded part a little bit clearer.


And that's something that I think


with the UI is a bit tricky to do because you can search


for one keyword, and then you kind of see,


well, for this keyword or not that keyword,


you see these things.


Whereas if you download the full data set


and you can filter it out, I don't know, in a spreadsheet


or with a small script, then that's a little bit easier


to get relevant data for the bigger picture.


Great, thank you.


Sure.


Hi, John.


Just to follow up a little bit on the question


a couple of days ago is that we saw that we went


through a couple of migration.


And then when we check in Google Search Console URL inspect,


we are seeing that the URL that Google picked for us


as canonical is actually not a valid one.


It's actually 301 redirect URL.


So how is it possible that Google actually


picked the URL that we don't use at all?


And how can we correct this?


For canonicalization, we use a number of factors.


So we use things like redirects, definitely,


like you have there.


We use the rel canonical.


We use internal links, external links.


We use sitemap files.


We try to pick URLs that look a little bit nicer.


So usually those are URLs that tend to be shorter.


And all of these kind of are combined with different weights.


And based on that, we try to pick a canonical


from a set of URLs.


So if you're seeing something like what you described,


where a URL that is redirecting is chosen as a canonical,


then that's usually a sign that there


are various signals that are still pointing us at that URL


and saying, well, it's redirecting, sure,


but everything else tells us that this


is the right one to show.


So a common situation where that happens is, for example,


if you have a home page that redirects to a detail page.


Some CMSs are set up like that, where you go to the home page


and automatically redirects to some lower level page.


Then from our point of view, the home page


is probably still the right one to show in search


and the right one to pick as a canonical,


even though it redirects to a different page.


So that's something where I wouldn't necessarily


see that as a bug or as something


that you need to fix, but rather it's almost a hint


that perhaps the signals that you're giving us


are not completely aligned with what you want to have done.


SPEAKER 2


Yeah, because we are seeing this happen to, I would say,


around 70% of all the URL on the site.


So first it got de-indexed, and it


reappeared without a trailing slash in the end in the SERP,


which is a typical site.


So you're doing a kind of a site migration


and seeing these kind of changes happening?


Is that correct?


SPEAKER 3


Yeah, I mean, after migration, it was a couple of months,


actually, around five or six months after migration


that this happened.


So it didn't happen right away, but it just happened.


Yeah, yeah.


That's something where it sounds like the signals are just


not aligned yet.


So that could be based on things like external links


going to those pages.


But in general, if you set up redirects for those URLs,


then even if we were to index those URLs


and show those URLs directly in search,


then users will make it to the right page.


So from that point of view, I don't


think it's a critical issue that you need to focus on.


But I would take a sample of these URLs


and try to follow back on where might Google be confused


and getting information that this other URL is actually


the one to pick as a canonical.


Yeah.


OK, thanks.


Yeah, we will share that.


Sure.


Oh, one last thing about the robot.txt.


If we have in our subdomain, there


is a robot.txt blocking a certain path,


would can that affect the whole domain,


or would it only stay within the subdomain?


The robot.txt is only for a specific host,


so that would only be in that subdomain.


OK, all right, Daniel.


Thanks a lot, John.


OK, let me take a break here.


I have a bit more time, so if any of you


want to stick around longer, that's perfectly fine.


But just to kind of pause the recording at a reasonable time.


Thank you all for joining in.


Thanks for submitting so many questions.


I didn't get to all of them, but I


think we got through a lot more than usual.


As always, you're welcome to post in the Webmaster Help


Forum if there's anything else that's on your mind.


There are folks there who are able to help out


and who are able to escalate these questions as well.


So thanks again, and I wish you all a great weekend


in the meantime.


English Google SEO office-hours from November 26, 2021

OK.


All right.


Welcome, everyone, to today's Google Search Central SEO


Office Hours Hangout.


My name is John Mueller.


I'm a search advocate at Google.


And part of what we do are these Office Hours sessions


where people can jump in and ask their questions


around their website and web search.


And maybe we have some answers.


We'll see.


A bunch of questions were submitted already


on YouTube, which is always good.


It makes it a little bit easier for me


to go through questions a little bit ahead of time.


But there are also a couple of people


who are raising hands already.


So maybe we'll just start off with some of the live folks


here.


Let's see.


Akash, I think you're first.


Hi, John.


Hi.


So my question is regarding hreflang tags.


So I have to target two countries, let's say UK and US.


And both the pages are like duplicate of each other,


like exactly the same wording because it's


in English language.


Should I create pages like EN US or EN UK and then target


because it will be localized for English with US


or English with UK since both the pages are exactly the same?


Or should I only create an EN page


and then let it be for all the English users?


But my geographies are defined.


It has to be only UK and US.


So how should I go with this?


How do you mean your geography is defined?


Because the client only wants the pages


should be only available in these two countries,


not for any other English speaking countries.


So it has been defined, but the pages are again duplicate.


So the content will only be the same.


OK.


So I think, first of all, probably you


have to set expectations because you


can't define that pages will not appear in the search results


in other countries.


So essentially, if they're in English,


they can appear to any user who is searching in English.


So that's kind of the first thing there.


And the English US and the English UK version,


it basically just means it would swap out


the URL for the appropriate version,


depending on the country.


So if you have different content for English US and English UK,


even if that's something like a contact address or currencies


or things like that, then that makes sense


to have on separate URLs.


If it's all the same content, if it's really just


like a text article, then I would just


make it one English version.


Because you can't limit it to those countries anyway.


So you might as well make one version.


And the advantage of having one version


versus multiple English versions of the same thing


is that you save yourself a lot of work in that you just


have to maintain one version.


And when it comes to search, it's


a lot easier for us to rank that one page versus you


taking the same content and putting it on multiple pages.


So my recommendation there would be essentially


make one English version of the content.


And also, let the client know that you can't limit it


to just those countries.


So one more question.


Regarding the pagination, we had a talk a couple of weeks back.


And I have asked which of the pagination method is right.


Let's say page one, all the rest of the other pages,


pages two, three, and four, have been


canonized to the page one or the homepage or that thing.


Or all those pages will be self-canonicalized.


So during that time, you said both the things


work on the internet.


We don't give a preference to the only rel next and rel


preview.


But if you do canonize all the page two, page three,


two, the page one, or self-canonicalize those pages,


like two to two or three to three, it doesn't matter.


Our bots or our systems can easily


recognize those changes.


However, in the best e-commerce practices by Google,


it's been clearly defined that the pagination sequence


has to be self-canonicalized, I guess.


And what we have opted for is we have done a little.


All the rest of the pages have been canonized


to page one.


So is this still bad for us?


Or should I see to that the best practices sequence?


I think it's up to you.


And it depends on your website.


So what happens if you canonicalize everything


to page one, then the content on pages two, three, and four


will not be indexed.


If we follow the canonical to map everything to page one,


then essentially everything on the other pages is ignored.


If that's OK with you, if you have enough cross-linking


that you can still make that content findable,


then that's fine.


If on page two, three, four, and five


you have things that are unique to those pages,


then obviously you want to have those pages indexed.


Sure.


Thank you, sir.


Thank you.


All right, Sergio.


Hey, John.


Mine is a rather simple question.


I just wanted to know if there was


any known issues the past few days regarding indexing.


So I have a client side that we've


been trying to index a few pages for a couple of weeks now.


And the inspect tool says everything is crawlable,


indexable.


Everything is OK.


It's been submitted by sitemaps.


It also has some internal links, but still taking very, very


long.


So I don't know if there was anything there


that maybe you knew, or if I can maybe just send


via the chat one of the URLs just to see.


Yeah.


Maybe if you can drop them in the chat,


then I can pick them up afterwards and double check.


And then I'll just drop those URLs there.


Yeah, I mean, it's not that I have a secret backdoor


to index in.


But I'm happy to look at these kind of things


because it's always, I don't know,


it's easy for me to make a hand-wavy answer of, well,


we just don't index everything.


But sometimes it's also interesting to look


at the details and see, well, what is actually


happening here?


Is this something we should be indexing,


or is this kind of expected?


Cool.


OK.


I'll copy those out and check those out afterwards.


Thank you.


All right, Denise.


Hello.


So my question, I have a website which has,


it's pretty bloated.


And it's been hit really hard with the changes


from the summer and onwards on the core web vitals,


I think it was.


So I'm now redesigning that website in AMP pages.


And I'm converting all my images to WebP format.


I don't know if it's wise, but I'm just a little concerned.


I'm trying to use the same URLs.


So I have two questions.


The first is with the images, they currently rank.


But if I convert from the JPEG to WebP,


is that going to impact those rankings?


Potentially.


So I think there are, I mean, what I've seen


is some people just use the same image extensions


and make them WebP files.


And if that works, then that would essentially


save you the trouble.


Because then you just swap out the content,


but keep the same URLs.


And all of that will continue to work.


Whereas if you change the image URLs,


or if you change the URLs of the landing pages for the images,


then obviously for image search, that


takes a little bit longer to pick up.


But the thing to also keep in mind


is that not all sites get significant traffic


from image search.


So sometimes it's something where theoretically it's


a problem if you make these kind of changes and it takes time.


But if from a practical point of view, you get, I don't know,


maybe 5% of your traffic from image search,


then maybe that's not your highest priority.


OK.


I get substantially more from image search.


So I need to try to get this right.


The next question then would be, am I wise in converting


to AMP pages for everything?


Or is that a silly move at this point?


I'm pretty fresh, shall we say.


I'm not very good at this stuff.


Yeah.


I think in general, that's fine.


AMP is a fairly fast framework.


You can also make fast websites outside of AMP.


So it's not something where I would


say moving to AMP is a requirement


if you want to make a fast website.


Depending on the kind of things you have available,


sometimes you can make really fast websites even


with a standard WordPress installation.


So that's one thing to keep in mind.


The other thing is the page experience update is generally


quite a subtle update.


It's not something that would make or break a website.


So if you saw a significant drop in traffic from search,


I would not assume that it's purely due to you


having a slower website.


So that's the one thing there.


I just want to mention that ahead of time


because it's easy to sink a lot of time and money


into making a faster website.


And sometimes there are bigger problems


on a website than just speed.


I think right now, the mobile experience isn't a good one.


I think that's what's hitting me so hard.


So when I use any of the tools, like Lightning, for example,


what I'm seeing is the page doesn't actually render.


It's too slow.


Oh, OK.


If it's even too slow to be tested,


that seems like something to fix just from a user point of view.


But again, I think from a search point of view,


for most of these things, I would not


assume that making a website from really slow


to really fast would cause a significant rise in visibility.


There will be some changes, but it's usually much more subtle.


OK.


I had a 50% drop at the end of June, the beginning of July


in traffic.


So I know there was a big update then.


I think it was Core Web Vitals at that point.


Maybe I'm wrong.


I think we launched the page experience Core Web Vitals


updates from June onwards.


But I don't think you would see a 50% drop in traffic.


That seems like something.


It has been slow.


It's just gone down, down, down, down, down.


So yeah.


That seems too extreme for just the speed and the page


experience update.


From my point of view, I would assume


that there are other issues that are kind of stronger issues


there.


OK.


I'll dig deeper then.


Thank you.


Good luck.


Hazel.


Hey, John.


Good morning.


So we have two questions about JavaScript.


The first one is we're just wondering


if we delete all JavaScript on page for Googlebot,


not for users.


Will there be any crawling issue or maybe


authority issue of our site?


I think maybe we just fear that maybe Googlebot


can crawl our page, like maybe simulate the user end.


And so it will notice there may be no interactive functions.


So will this be an issue or this will be not an issue?


Probably not.


So if JavaScript is not required for your pages,


for the content, and for the internal linking,


then that doesn't change anything.


I don't think it would significantly improve things


from your side.


So I would be cautious about just making that change.


It's also tricky because once you kind of go down


this route of making more, I don't know,


simplified pages for Googlebot, it's


very easy to fall into a situation


where Googlebot sees something very different than what you're


users usually see.


And that can make it very hard to diagnose issues.


So if there's some bug that's only


affecting the Googlebot version of the site,


you wouldn't see it if users always see a working website.


So right now, there are many functions


like addToCart or byteNow and also localization function


like selectLanguage and selectCurrency.


These are all achieved by JavaScript.


So we just, in regards to response time,


so we also want to reduce some loading time.


So we just want to know if we can disable this JavaScript


on page.


Probably you can.


I mean, I don't know the details of your site,


how it actually uses JavaScript.


But you can disable JavaScript in your browser


and try the website out.


And then you kind of see what Googlebot would see there.


The one thing maybe that you mentioned


that I would watch out for is I think in product search,


we sometimes check to see what happens when you add something


to your cart, just to kind of double check


that the pricing and things like that are the same.


And if you remove the addToCart functionality completely


for crawlers, then maybe that affects kind of those checks


that the product search does.


But I don't know the details of what exactly product


search is looking for.


AUDIENCE So Googlebot will not simulate the users


to crawl page?


Yes.


I mean, we try to render the page


to see if there's something that we're missing.


But we don't interact with the page,


because I think that would just take too much time


to crawl the web if we had to click everywhere


to see what actually happened.


Yeah.


Yeah, I see.


Thank you.


So for the second problem is also the JavaScript.


So for our scenic models, we rendered


is through the browser end.


So we just wonder which one will be crawled either


by Googlebot.


It's all the browser end, but the different forms.


One is in the HTML, and another is in the form of JSON.


I don't know.


I would double check the testing tools in Search Console


just to see what gets picked up there.


My suspicion is we would recognize both of them.


Right now, we have these both of them.


And they're both crawlable, but we just


wanted to know which one may be easier to crawl.


I mean, easier to crawl is probably the one


in the HTML directly.


But I will just use a testing tool to double check.


And if you can make a test page with just maybe one of them


turned off and one of them activated,


you can see if it works or not.


So it's all the scenic models that maybe not the scenic cars.


So yeah.


Yeah.


OK, I got you.


Thank you.


OK.


Gabi.


Yes, good morning.


My name is Gabi from a Swiss platform.


My question is concerning featured snippets


in the context of different countries


with the same language, in our case, especially


Switzerland and Germany.


So on our platform, we have kind of B2B pricing benchmarks


for various products and services that show pricing,


especially for Switzerland.


What we found now is if the user is searching for, for example,


what is the price for or what is the cost for cashier


system in Switzerland, we have no problem


to appear in the featured snippets.


But if the user in Switzerland is


searching for what are the cost of a cashier system,


and I mean, his context is in Switzerland.


He is searching for Switzerland.


But then we found that the featured snippets are always


in euro and come from platforms in Germany that


target the German market, but not the Swiss market.


So my question is, is there something


we can do from our side to take more influence to be shown


in this context of Switzerland, even that he does not


type in Switzerland, but he is coming from Switzerland?


Or why is Google showing the search results then


or the snippet previews from German countries?


Yeah.


I so in general, the featured snippet


is, from our point of view, kind of a normal search result.


So I wouldn't focus too much on whether it's


shown in the featured snippet or not.


But it's essentially a normal search result.


And it has a little bit of a bigger snippet, a little bit


more information there.


But otherwise, it's a normal search result.


And from our point of view, we try to do two things


when it comes to searches.


On the one hand, we try to recognize when a user wants


to find something local.


And when we recognize that the user wants


to find something local, we'll use the geotargeting


information that we have from the websites


to figure out which are likely the more local results that


would be relevant for the user.


And with local, you mean the country?


Because I'm talking about the whole country, which


is, of course, a little bit small compared to Germany.


Sure, yeah.


And I think that local aspect is something


that helps to promote local websites.


But it doesn't mean that they will always


replace anything that is global.


So probably what we're seeing are these bigger websites


from Germany.


I assume they're bigger websites.


I don't know.


Sometimes they're smaller, too.


But these essentially global websites that we're seeing.


And on the other hand, we have the local results


from the same country.


And depending on how we understand the query,


then we might show more local results.


And we might show fewer local results.


I mean, not fewer, but essentially more


would be the global search results.


And probably what is happening when someone


is searching for in Switzerland, then, of course,


we recognize, oh, they want something from Switzerland.


And then we can really strongly promote the local results


from Switzerland.


But without that addition, sometimes it's


hard for us to determine, is the local context really critical


here or not?


And sometimes we'll just take global results


in a case like that.


And that's not really something that you as a site owner


can influence.


It's more this is what we've learned from users over,


I don't know, billions of searches that they've done.


And it can change over time, too,


where if we recognize that, I don't know,


users in Switzerland tend to go more to Swiss websites


for this kind of query, then maybe we


should kind of adjust our systems to learn that as well.


But it's not something that you can force.


The only thing you could do there


is essentially use the feedback link


on the bottom of the search results and say, oh, I


was looking for something in Switzerland


and you showed me German stuff.


OK.


Yeah, because we found that in about 50% to 60%,


it's German results, even if there is services connected


and it's clearly products or services that you would not


buy from Germany because you do not have the local support.


Yeah.


I don't know.


I mean, sometimes it's, yeah, I think


it's super tricky sometimes, especially


with Switzerland and Germany because the language is


the same.


But it's also something where I think


from a practical point of view, sometimes people just


buy things in Germany because they're cheaper.


And then you kind of have this skew of, well,


I was looking for something.


I don't care if it's from Germany


and I don't have good support.


But it's like cheaper.


But I imagine you fight with that all the time.


Yeah, exactly.


OK, thank you.


Cool.


All right.


Let me go to some of the submitted questions.


And then we'll definitely have more time for you all as well.


Let's see.


Are there any situations where Google negates, say,


site authority that can't be recovered even


if the cause has been rectified?


So assuming the cause was a short team


turbulence with technical issues or content changes,


how long for Google to reassess the website


and fully restore authority, search position, and traffic?


Does Google have a memory as such?


So for technical things, I would say


we pretty much have no memory in the sense


that if we can't crawl a website for a while


or if something goes missing for a while and it comes back,


then we have that content again.


We have that information again.


We can show that again.


That's something that pretty much picks up instantly again.


And this is something that I think


we have to have because the internet is sometimes


very flaky.


And sometimes sites go offline for a week or even longer.


And they come back.


And it's like nothing has changed,


but they fix the servers.


And we have to deal with that.


And users are still looking for those websites.


I think it's a lot trickier when it comes to things


around quality in general where assessing


the overall quality and relevance of a website


is not very easy.


And it takes a lot of time for us


to understand how a website fits in with regards


to the rest of the internet.


And that means on the one hand, it takes a lot of time for us


to recognize that maybe something is not


as good as we thought it was.


And similarly, it takes a lot of time for us


to learn the opposite again.


And that's something that can easily take,


I don't know, a couple of months, a half a year,


sometimes even longer than a half a year for us


to recognize significant changes in the site's overall quality.


Because we essentially watch out for, well,


how does this website fit in with the context


of the overall web?


And that just takes a lot of time.


So that's something where I would say compared


to technical issues, it takes a lot longer for things


to be refreshed in that regard.


The other thing that I've very, very rarely seen


is that a site gets stuck in some kind of a weird


in-between state in our systems in that, I don't know,


at some point our algorithms reviewed the website


and found it to be absolutely terrible.


And for whatever reason, those part of the algorithms


just took a very long time to be updated again.


And sometimes that can be several years.


And I don't know, this random person raising his hand,


I will try to ignore him.


But these are things that I've seen every now and then,


but they're extremely rare.


So the chances of any random websites falling into


is fairly low.


But it is something where if you struggle


and you really see that you're doing a lot of things right


and nothing seems to be working, then do reach out to us


and see if there is something on our side


that might be stuck.


But I would say at least technical things,


they resolve very quickly.


Kind of the, I don't know, weird things stuck in the algorithms


side, I would say that that's a lot rarer nowadays.


But especially if something happened, I don't know,


5, 10 years ago and your site is kind of stuck


in a weird limbo state, then that's


something where reaching out and seeing


if there's something weird is always worthwhile.


Let's see.


All text for lazy loaded images.


Should the alt text be kind of appropriate for the image


essentially if you have a placeholder image that


is being lazy loaded?


So what I would watch out for here


is essentially when we render the page, we have to,


or we try to lazy load the images as well


because we try to load the page in a very high viewport.


And usually that triggers lazy loading.


And usually that means we can pick up the alt text associated


with the right images.


If you have kind of the alt text already in place


and the placeholder image is currently there


and we just see that, then I don't think that's a problem


per se.


It's kind of like you're giving information about an image


that you don't care about, but it's not


that the rest of your site has kind of like a better,


a worse standing from that point of view.


So I think that's kind of fine.


The thing I would watch out for here more


is that we can actually load the images that you're


trying to lazy load here.


So in particular, we don't watch out for things


like the data source attribute.


We essentially need to see the image


URL in the appropriate source attribute for the image tag


so that we can pick it up as an image.


What would be an explanation for sudden drop in ranking from one


out of the top 100?


After years of perfect ranking for our brand name,


our brand name is the same as a biblical story.


So we did compete with Wikipedia sometimes,


and now we're just gone.


We cancel advertising, of course,


so it isn't quite unfair.


I don't know.


It's hard to say without knowing the website.


I don't know if you're here or if you can drop me a link.


I'm happy to double check.


I think the general tricky problem


is if you have a brand that is essentially something


that people commonly use for something else,


then it makes it very hard for us


to understand when someone is searching for that term


if they mean your website or if they mean the other thing.


And if we can recognize that people mean something


very specific with that term, then we'll


try to show that very visibly in the search results, which


also means if we can recognize that people are searching


for this biblical story with that name,


then we'll try to focus on that biblical story.


And if there's also a website that


is kind of unrelated to that biblical story,


then it can be quite hit and miss


whether we actually start showing that website.


And this is something where with biblical stories,


I don't know, it probably depends a bit on what exactly


you're seeing there.


But I see this very often where people


will take essentially the keywords


that they're trying to rank for and say, this is my brand.


Best car insurance is my company name now.


And just because your company is called Best Car Insurance


doesn't mean we will show your website as number one


for someone searching for best car insurance.


Because usually we can tell that, well, people


have in the past at least used this term


to search for something different.


And just because your website is called that doesn't mean


it will rank number one for that term.


Let's see.


Google updates more than 10 times a day.


During the core update period, do you


carry out the same updates as on regular days?


If the changes in the core updates are subtle,


it's indistinguishable from regular updates.


I don't think we hold back on normal updates


during this core update time or when we roll it out.


The core updates usually take, I don't know, a week or so


to be rolled out.


So I imagine the rollout now will probably be complete soon.


And the normal updates, we tend not to hold them back


during that time because we make lots of updates


over the course of time.


The things we would hold back a little bit


are maybe other bigger updates that we


want to let people know about.


So essentially, if we have, I don't know,


some bigger update involving structured data


that we want to talk about, then probably we'll


try to hold that back a little bit so that it's not


one update after another, but more kind of like we


can talk about the update a little bit clearer


and make it a little bit easier for people to understand


what exactly is changing.


But the kind of normal updates that we do all the time,


like, I don't know, shifting the UI slightly


by a couple of pixels, changing colors, or things like that,


those are all updates that we can do independently.


Let's see.


In Google Analytics or organic traffic,


sometimes a huge amount of traffic


starts dropping into the direct channel.


What could be the reason behind this?


So on the one hand, I don't know that much


about Google Analytics.


So I can't give you detailed information on what specifically


is happening there.


But one of the things that could be playing a role


is Google Discover.


In particular, Google Discover, I


think, is mostly seen as direct traffic in Google Analytics.


And Google Discover is sometimes very binary in the sense


that it's either you get a lot of traffic


or you don't get a lot of traffic from Google Discover.


So that could be something where if you're just


looking at analytics, you might see those spikes kind


of happening there.


In Search Console, there is a separate report


for Google Discover.


So you could double check in Search Console


and see is there something happening with Google Discover


or not.


There's a blog on an e-commerce website of our clients.


And for some reason, one particular article


just won't get indexed.


Yeah.


I don't know.


In general, we don't index everything on the web.


So that's kind of like the standard situation there.


It's something where maybe we're just not indexing this.


If it's something where you see that everything else tends


to get indexed from that part of the website, so for example,


if you have 10 blog posts and just one of them in between


just randomly doesn't get indexed,


I would suspect that maybe there was some technical issue


at some point that just takes a bit of time to be resolved.


But it's also just very hard to tell.


In general, we don't guarantee indexing.


And even for a smaller website or a section


of a larger website, it can happen


that we just don't index everything.


But if you want, I don't know if you're here in the Hangout,


but if you want to drop me a URL to look at,


I'm happy to take a look and see if there's something,


I don't know, weird happening on our side


there that maybe we can help with.


I have a question about shop ratings.


So schema.org, organization, aggregate, markup,


are they still relevant for Google search results?


It seems to me that the overall organization rankings are not


really in use.


So as a regular retail shop, which ratings


should you prefer, product ratings or shop ratings?


Would you show shop ratings on category pages?


Good question.


So I double checked just to make sure I get this right


in our documentation.


In particular, when it comes to shop ratings,


we would not try to show them if they're on the shop themselves.


So essentially, for local businesses,


the idea is that if you have a directory of local businesses,


then putting ratings on those local businesses will be fine.


And that's something we might show in search.


But if you're the local business yourself,


and then putting a rating on your own website


is not really like an objective rating.


It's like I am five stars out of five, or 4.5 out of five


to make it look a little bit more legitimate.


But that's not really something that we can trust and show


in the search results.


So from that point of view, if you're an e-commerce shop,


then I would use product ratings because


the individual products can be reviewed either by yourself.


You can clearly specify that as something reviewed by yourself.


Or you can use aggregate ratings,


which would be from users, and show those there as well.


So that's kind of what I would focus on there


with an e-commerce site.


On the other hand, if you're really


a directory of other e-commerce sites, then, of course,


having ratings on those individual sites


would be an option.


The data and the page usability page of Search Console


of our site is gone.


And has become no pages of your site.


It's just efficiently user friendly.


Though the percentage of red, yellow, green zones


is similar to the rest of our projects.


Let's see.


Not really sure what exactly you're seeing there.


But I think you're up next anyway.


So maybe I'll just, maybe you can elaborate a bit on what


exactly you're seeing there, Alexei.


Oh, no.


OK.


Looks like, ah, there you are.


Oh, sorry.


Sorry.


So my English is very, very bad.


And I'm not very fast.


We have seven of our projects.


It is a big project.


It's a magazine.


Internet magazine.


And in one of our projects, I see that on page experience,


we have one day 20,000 good pages.


But yesterday, I feel that good page is 1,000.


But on the next week, I don't see statistics about last week.


I see another picture every week.


Every week, I see another picture and another date.


And the


OK, do you see bad pages going up


when the good pages go down?


Or is it just the overall number goes down?


No data.


OK.


So I think what is happening is you're


seeing an effect of the way that we track this data in Search


Console.


And it sounds very confusing.


It's probably confusing.


So essentially, what we do with regards to the Core Web Vitals


and the speed in general, we track the data


based on what we see from users.


A specific kind of user, I think that's


documented in the Chrome side.


And only when we have sufficient data from users


will we be able to use that in Search Console.


And additionally, in Search Console,


we create groups of pages where we think this set of pages


is the same.


And if we have enough data for this set of pages,


then we will use that.


That also means that if you have just barely enough data


for that set of pages, then you could see the situation where


sometimes we have enough data, and then we show it.


And that's the good pages that you see there.


And sometimes we don't have enough data.


And then we say, well, we don't have any good pages or not


as many good pages as before.


And you see that kind of drop again.


And that essentially doesn't mean that your website is bad.


It basically just means we don't have enough data to tell.


So if you see that just the overall number goes down


and over time the overall number goes back up again,


then probably you almost have enough data


for us to use for that.


If you see the good number go down and the bad number go up,


then that's a sign that there's a problem that we see there.


So if just the overall number goes down, I would ignore it.


I think that's perfectly fine.


SPEAKER 2 We have seven projects,


and it is our biggest project.


Small projects have good data.


All our projects are on the same platform.


It's our platform, and it is the same for our projects.


But in one project we see data, but on the biggest project


we couldn't see data.


SPEAKER 1 That sounds confusing, but it can still be the case.


Depending on the kind of users that are going to these pages,


because we don't take the data from all kinds of users,


and the aggregation on the group of pages is, I don't know,


sometimes unclear.


So it can happen that you see that even on a larger website.


So I would not assume offhand that this is a bad sign.


It would be bad if the number of bad pages were to go up.


But if you're just seeing less data from time to time,


even if that's on a weekly cycle,


I don't think that's a problem.


SPEAKER 2 In this biggest project,


we have a second part of our questions


about cover page in Search Console.


On the biggest project, we see that primary robot


is PC, not smart phone.


Why?


It just is.


I duplicate my question in chat.


OK.


Yeah.


So for some sites, we are still crawling


with the desktop Googlebot.


And it's something where we're currently


working through a bigger set of sites


to switch them over to mobile indexing.


And once we have all of that covered,


we will switch and start working on the smaller sites


again to switch them to mobile indexing.


So that's, it just is.


It's not something that you can force the other way around.


But it also doesn't affect any of the indexing or crawling


or ranking side of things.


It's just we're indexing it with a desktop crawler still.


OK, thank you.


Sure.


All right.


Maybe, let me see.


I'll just grab the next two questions,


and then we'll switch to more live questions


because more people are still here.


I also have a bit of time afterwards


where we can talk about things more.


Let's see.


Will Google simulate users to crawl and check pages


to check if a page can normally place an order?


I don't think we do this from a web search point of view.


I do think we sometimes do this for product search, though.


So specifically for product search,


I could imagine that we do this.


Similar how we do it for ads where


we check the ads landing page quality, those kind of things.


How does Google determine out of stock page?


Will Google take actions on the out of stock page,


for example, crawl less and lower the rankings?


Structured data has been deleted,


so it won't display out of stock in the search results.


We do try to understand when a page is no longer relevant


based on the content of the page.


So in particular, the common example is a soft 404 page


where you serve as a page that looks


like it could be a normal page, but it's essentially


an error page that says this page no longer exists.


And we do try to pick up things like that for e-commerce


as well.


So that's something where you might


see that out of stock products are


seen as soft 404 pages.


When they're seen as soft 404 pages,


we drop them completely from search.


If we keep the page indexed despite being out of stock,


we will not change the ranking.


It'll be ranked essentially normally still.


It's also still ranked normally if you


change the structured data and say that something


is out of stock.


So from that point of view, it's not


that the page would drop in ranking.


It's more that either it's seen as a soft 404 page or it's not.


If it's not seen as a soft 404 page, it's still a normal page.


All right.


And then I guess the complicated question


about handshake domains.


So I had to look this up.


I think, Damian, you're here as well somewhere.


Yes.


OK.


Can you explain a bit more what handshake domains are


and what is happening?


Sure.


I guess the question and what I'm trying to look for is,


I guess the best way is I'll give you the example of how I


went about it.


I had three, I guess you'd say, of the handshake domain.


Basically, a handshake is set across for it


being decentralized platform.


The way the files rest on the platform


is scattered across, let's just say, for time's sake,


a few FTP servers.


With that known, I put a HTML file


for test on three different of these, let's just say, servers,


that being the three different companies.


And I noticed that the indexing of that HTML file


varied drastically between one actually indexed probably


within two to three weeks.


Another one that was maybe about a few days,


actually fairly quick.


And then the third final test was probably about,


geez, about almost 20 days before it even


got any light of search showing.


Now it's a little tricky question here,


and it's a little out of the realms of normal search.


So that's why I was kind of curious.


Yeah.


So I think the aspect of indexing


across different domains, that's kind of normal


and to be expected in the sense that we


try to understand the overall context of a domain


or of a website and try to figure out


where does it make sense for us to invest our resources.


And that can mean if we don't know much about a domain,


maybe it'll take a little bit longer for us


to start crawling and indexing stuff there.


Whereas if we already know that this


is a really great website, then we'll probably


crawl and index a lot faster.


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


that you're seeing there.


I think the other part with the hand-shaped domains,


I took a quick, I don't know, five minute look


at what it was.


So from what I can tell, it's basically


kind of like an alternate DNS system, which is kind of based


on blockchain technology.


And usually what happens there is on our side,


our systems are essentially tuned to using kind of,


I don't know, the traditional DNS system, which for the most


part works fairly well.


So that's kind of what we would focus on there.


However, we do have, let's say, an open mind in general


at Google.


And lots of people are playing around


with all of the new technologies around blockchain as well.


So I wouldn't say that that will never shift.


But it's probably not something that's


going to happen very quickly.


And it's, I think, similar to the onion domains.


I don't know if you remember those.


It's kind of like also an alternate DNS system.


And that's something where I think in the end


we never index the onion domains directly.


But if over time we recognize that this is something


that is very popular, that people are using this actually


to host their content and make it accessible, then


I could understand that our systems would be like, well,


we have to figure out a way to deal with this


and to index this content as well.


Because if people are searching for information


and that information is only findable through this way,


then maybe we have to find a way to make that accessible.


Confirm.


So from that point of view, if you need something short term


to work well in search, I would use a traditional DNS setup.


If you want to grow this, I don't know, alternate setup,


then I think that's worthwhile trying out


and keeping as more like, I'd say,


like a side project or something to kind of, I don't know,


try things out.


And it could also be that there's


some kind of a middle ground there in that since these are


also still IP addresses that are hosted on the internet normally,


maybe there is a way for kind of almost like a gateway setup


to help out there so that we can still


kind of crawl one set of URLs that lead to the final content.


Got it.


Awesome, thank you.


Cool.


All right, let's see.


Konstantinos.


Hi, John.


Hi.


We have an issue with one of our sites.


It shows good search.


It has a good rank for keywords it writes content for.


It shows up on Discover.


We get a lot of traffic there.


We have no Core Web Vital issues.


The page experience is over 99.5%.


However, we show up on news, Google, on mobile version.


However, our site does not show up on news, Google desktop


version and does not show up on top stories.


What could it be?


We have, I believe, good structured data on our site.


Yeah.


Could it be something from our site, maybe?


I don't know.


So especially the news site, I don't


know if they do something specific there.


What I would recommend doing is using the contact form


in the Help Center to reach out to someone from the news team.


From the news team, OK.


Because especially if you're saying


it's visible in parts of Google News


and not visible in the news, it's


in parts of Google News and not visible in other parts,


then maybe there is something that you


can do on your side to make it clear that actually it's


relevant for both parts.


Maybe there's also some setting on our side


with regards to Google News that someone can kind of nudge


the algorithm in the right way to make sure


that it gets picked up.


But I don't know the details of Google News.


So it's really hard for me to say


what you should be doing then.


OK, thank you very much.


Cool.


Mark.


Hi, good morning.


I just wanted to.


Oh, no, you're muted again.


OK.


Am I back?


Yes.


I just wanted to come back to something you explained earlier.


It was about these five star ratings about your own company


on your own website.


I mean, I see Google's point saying


that it would be quite senseless to have that in the form of,


OK, I have a five star rating.


However, it's pretty common in the business context


that you ask your customers to kind of give you


feedback if they're happy with the service you provide.


And it'll be also some additional value


for people searching on the internet


if they were able to find these recommendations.


So is there a way, kind of in a Google sense,


legal way or helpful way that we ask our customers


to rate our service and to display that new customer?


So OK, beef win.


I don't know, 4.6 stars out of five would trust Pilot


or something be an alternative that we could somehow play out


in the search results?


So you can definitely put these on your home page.


We would see these more as testimonials


because you're kind of picking and choosing


what you want to show.


Using structured data for that on your own website


is something that we wouldn't like to see.


We would probably ignore that.


But sending users to a third party review site


where they can review it, I think,


is kind of the best approach there.


Because what would happen then is


if we show that listing from that third party review site,


we can show the structured data for your business there.


So if that's, I don't know, for example, you're


listing on Yelp and they leave the reviews there,


when that Yelp listing is shown in search, we will know,


well, this is a list of businesses, essentially.


So we can show this structured data about the business.


And then we can use that review markup


and show those stars in the search results.


So I don't know if Yelp has structured data.


But if they do have this structured data,


then that's something that we could pick up there.


Showing it on your website as well, kind of in a textual form,


is perfectly fine.


And testimonials are super common and super popular.


But it's just that we wouldn't show the stars in the search


results for that.


So if someone searches for, I don't know, some company


and SEO, and you have a testimonial from that company


on your SEO business, then we can still


show that as normal kind of text on a page


that we found on the web.


Yeah, OK, so there's actually no way


to link the search results about us and the star rating about us


since it's on the search result page.


Yeah, I don't think so.


I think for some kinds of knowledge graph entries


that we show for individual businesses,


sometimes we link essentially different profiles


where you have essentially more information


about that one entity.


I don't know how that works with regards to companies,


if that's something that we also do there.


But that might be something worth trying out


to see how are other companies being shown in that regard.


Is it just the Google My Business?


What is it, Google Profiles?


What is it, Business Profiles, all these names.


If it's just the Business Profile being shown,


or if it's more like a knowledge graph entry


where we have more information about that business being


shown.


And probably for businesses that are more online and not


based on a physical location, probably


it's more about that knowledge graph entry


where we do try to pull out information


from different sources.


OK, thank you.


Cool.


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


I'll get back to the other people that have raised hands


and more questions as well over time.


If you're watching this on YouTube,


thanks for watching all the way to the end.


If you'd like to join some of these


at some point in the future, feel


free to watch out for the entries in the community


section where we post the link and kind of pre-announce them.


And yeah, and for all of you that submitted questions,


all of you that came here, thanks for dropping by.


Thanks for all of the interesting questions.


And hopefully we'll see each other in one


English Google SEO office-hours from January 21, 2022

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google.


And part of what we do are these Office Hours sessions


where people can join in and ask their questions around web


search.


And we can try to find some answers.


A bunch of stuff has submitted on YouTube already,


so we can go through some of that.


But I already see people raising their hands here.


So maybe we'll just start with some of the live folks here.


And wow, that was a cue.


Like, suddenly lots more hands.


Let's see.


Vahid, go for it.


Hello, John.


Nice to meet you.


Today I'm going to ask, is the value of internal links


are similar?


For example, is there a difference of value


of internal links in header, footer, or in content?


It's pretty similar.


I don't think there is anything quantifiably


different about internal links in different parts


of the page.


I think it's different when it comes


to the content in different parts of the page, where


we try to figure out what is unique to a page.


But with regards to links, I don't think that's anything.


OK, thank you.


And the second question is, Google


says pay for backlinks is spam.


But in Persian web, we see many websites,


mostly they sell flight tickets.


They spend a lot for site-wide backlinks.


But still, they are on the top of the search results.


So why is there such a contradiction here?


I don't know.


I mean, it's hard to say without looking at the sites


themselves.


But a lot of times, what I see is


that sites will do some things wrong,


but they will do other things really well.


And because of that, it still makes sense


to show them in the search results.


We would not remove a site from the search results


just because they're doing one thing bad,


especially if in our algorithms we can recognize that


and ignore or reduce the weight of that factor.


And that's what we try to do with links in general


to understand which of these links


are actually good, natural links,


and which should we give weight, and which ones aren't.


And just because there's some bad links there too that maybe


they're buying, I don't know, that doesn't mean that we would


not show the site at all.


SPEAKER 2 OK, thank you.


Even if the backlinks are millions?


JOHN MUELLER Even if the backlinks are millions,


I think one of the things that I kind of like


about our algorithm is that we have so many different factors.


And you don't have to be perfect with all of these factors.


And sometimes people do bad things accidentally.


Maybe they follow bad advice.


Maybe they think that this is really important to do.


But it doesn't mean that the rest of their website is bad.


SPEAKER 2 OK, thank you so much.


Let's see, Mohammed.


SPEAKER 3 Hi, how are you?


JOHN MUELLER Hi.


SPEAKER 3 Sir, I want to ask, after November,


Google search can sort of update my website not crawling.


Some links are crawling or some are not.


Some on daily basis, but some are not.


JOHN MUELLER Yeah.


SPEAKER 3 How can I fix it?


Can you tell?


JOHN MUELLER I think there are two possibilities.


One is that maybe there is a technical issue.


I don't think that's necessarily the case in your case,


because it sounds like some of the pages


are being crawled normally.


The other is essentially just that we don't crawl everything


all the time.


We don't index everything on the web.


And sometimes we have to prioritize things.


And that can mean that we try to understand


what is kind of the overall value of a website


in terms of how much resources should we spend on the website.


And that is kind of reflected in how much we crawl as well.


So that might be something that you're


seeing where our algorithms are not


sure of the overall quality of the website overall.


And helping to kind of improve the quality of the website,


that usually ends up making it so that we crawl


more of the website as well.


But when I am manually trying to index,


then showing me your URL index, but after one day or two day,


link are going to excluded.


Yeah.


That sounds very much like that.


We're not convinced of the quality of your website.


So really taking a bit more time to figure out


ways that you can significantly improve


the quality of the website, that would be my recommendation.


OK.


Thank you very much.


Sure.


Let's see.


Suave.


So over the last year, we've been


making a lot of technical improvements to the site.


And our customers seem to be pretty happy with the site.


However, since the end of October,


the number of pages indexed by Google


has dropped dramatically, 25%, about 500,000 pages.


And the ones that we've submitted,


so that was for all pages known, the submitted ones


have dropped by 50%, over 50%.


We've done the kind of research we can


imagine that would be relevant.


And the thing that we found is that if there is a review


on a product page, or if there are no reviews on the product


page, the schema validator is unhappy


because there's no review mentioned,


but we're doing something wrong there.


But that's the only big change that we


can see that's gone from a slow but steady growth all year


to a dramatic drop in the last two months.


Is there something that we're missing


that we should look at next?


Or is that actually enough to have been the core cause of it?


So just because structured data is not


completely valid on a page wouldn't


mean that we would drop it from the vaccine.


So that seems unrelated to me.


I imagine maybe the report in Search Console


shows all of these errors, and you look at them,


and you say, well, I don't care about the markup there.


And that's fine.


It's not a sign that we think your website is bad


because the structured data isn't valid.


It's just we want to let you know,


in case you wanted to use the structured data,


it's like it's not working.


But that wouldn't affect crawling or indexing or ranking


or anything like that.


It's kind of hard to say offhand what might be causing that.


It could be similar to the previous question


that our systems are kind of unsure about the quality


overall of your website.


When it comes to such a large website,


where you're kind of looking at the mass of numbers there,


one thing I would also do is try to look at some samples


and try to see, is the number really


reflective of an actual issue, or is maybe


the number of index pages essentially just


reflective of maybe something technical that


is being cleaned up?


So for example, sometimes we index pages


with different parameters attached to them,


maybe analytics tracking parameters.


And it can easily happen that we suddenly index,


I don't know, 100,000 of those pages.


And they're all indexed.


And in the graph, it looks like that's a big thing.


But if we were to drop all of those pages,


it wouldn't change anything for your website


because these are kind of accidentally indexed pages.


So in the graph, that could look very dramatic


in that it goes up, and all of these things are indexed.


And then it goes down.


You're like, oh, what broke?


But it might just be that our systems are kind of fixing


an issue with regards to indexing that doesn't really


affect the rest of your website.


So I guess what I try to do is figure out


which of these issues are really affecting


the traffic or the divisibility of your website.


And maybe the indexing issue is something that falls into that.


But I would try to kind of separate that out.


OK.


One thing that we noticed was this


is the first time we've ever seen crawled but not indexed.


And maybe that's just because before it's


been not crawled and not indexed.


This is kind of a new thing where we're like, OK,


we feel like this is telling us something,


but we're not quite sure how to interpret it,


what to parse from it.


Yeah.


Maybe that's just quality.


I don't think there's really much you can kind of pull out


from that.


I think the two statuses, crawled and not indexed,


and discovered not indexed, I think,


they're essentially equivalent in that we know about the URL.


It's like we confirmed that we've heard about it,


but we decided not to index it.


And that's something where we're looking with the indexing teams


to figure out, is this really a general problem?


Because we hear more and more reports about this.


Or is it essentially just it's more visible


than it used to be?


Because even in the past, we would always only


index a portion of a website, but we never showed people


that in Search Console.


We just focused on the traffic that you're getting,


not why we're not indexing individual pages.


Yeah.


But if you want, you can drop your URL here in the chat,


and I can pass that on to the team,


especially if you have some sample URLs from your website


where you're kind of feeling, well, this


is really important content, and it's not being indexed.


And is it something you're doing or something


we're doing kind of thing?


Yeah, I'd love to.


Thanks.


Sure.


All right.


Marcos.


Hello, John.


I'm trying to find out some more information about the images I


recently see increasingly in the organic search results directly


in search, not in image tab, because there's


no documentation in Google in the Search Central.


And I tried to find out some common things about images


or some differences, but I don't see anything


connected to the resolution or size or the ranking position.


So is this just a test, or will there


be coming documentation?


Do you have any information about these image snippets?


From our side, these are essentially


just a kind of snippet.


So it's not based on any particular markup


that you're doing on the pages.


It's not something specific that you define on the pages.


It's really just we recognize these images


are on these pages, and for whatever reason,


our algorithms think that for users,


showing some images or kind of the snippet images


would help them to decide which of the results to click on.


So that's, from our side, it's something like, yes, we


are showing images and snippets.


And I think in the past, we didn't do that so much,


but it's not based on anything specific that you can control


other than maybe deciding you don't want any images


on these pages indexed, and you want to use the, what is it,


no image index meta tag.


But it's not something where you can say,


I want these images indexed or these images shown


in the snippet.


It's essentially, we're picking images from the page.


SPEAKER 2 OK, it seems a bit random,


and I was doubting that Google is doing things randomly.


But yeah, if there's nothing to control or to do about, yeah.


JOHN MUELLER How do you mean random?


Is it taking bad images, or?


SPEAKER 2 No, not bad images.


But sometimes it takes one, sometimes six,


sometimes no images.


Even there are images on the landing page.


So I don't see the connection why or where


this decision happens to show or not to show an image.


Yeah.


I don't know what we can do to make it a little bit easier


to understand, but yeah.


Maybe we should at least document


that we do show images in the snippet


and that it's not something that you can easily control.


That's a good point.


SPEAKER 2 OK, thank you.


All right.


And then we have the agency Web Plus.


Oh, I think you're muted.


SPEAKER 3 Yes.


SPEAKER 2 Perfect.


SPEAKER 3 Should be better.


Thank you for having me here.


We have a client that ran a French business in France,


and all the other businesses in France


So they have multiple websites, one for each location,


they run the business.


The thing is that every website has exact same content,


but location address and phone number.


So the first two websites, the first one is a website


So the first two websites are performing very well


in terms of positioning for some related search keywords.


But every new location that has been added


based on the first two websites, they are not indexed at all.


And despite asking the search console to index them,


they are not indexed.


So the reason being is for duplicate content.


So what is your recommendation for that


to solve this problem and puzzle?


I can see how it would be correct for our systems


maybe to flag it as duplicate content


if it is duplicate content.


So that's, I think, kind of a tricky part there.


The best way to make sure we don't see it


as duplicate content is really to make sure


that it's not duplicate content.


And the address and phone number, I think,


is a big step in that direction, but it's sometimes not enough.


Because we do try to understand what the main content is


of a page, and we use that, essentially,


for recognizing duplicates.


And that's something where I suspect


where you're running into issues at the moment,


in that the main content of the page


is essentially the same for all of these sites.


And because of that, we see them as being duplicate.


I think there are two approaches that I would recommend here.


One might be to pick one domain and focus on that


and have individual landing pages for the locations


within that one domain.


That means that the content is just indexed once,


and kind of like the addresses are more like attributes


of that main content.


That would probably make it also such


that the content is much more visible in search,


because instead of having to promote


all of these individual websites,


you promote one strong website.


And that makes it a little bit easier


to rank that content in search.


So that would be the one approach.


The other would be if you know that this


is going to be a good way to do that,


maybe if you know that this is going


to be a very small number of different locations,


then maybe there is something that you


can do to make the content a little bit more


unique across these locations.


If you're talking about, I don't know,


20 to 100 different locations, then obviously that's


not really feasible.


So that's kind of the, I think, the two main options


that I would have there.


So to sum up, the first option is


if we have a large amount of locations,


is to regroup all the locations under a single domain


and create some sort of landing pages for specific locations.


And if we have a smaller amount of websites,


try to make them very unique and to have as much as possible,


as less as possible, same content.


Yeah.


I mean, they don't have to be very unique in that they're


completely different websites kind of thing.


But it should be clear that when our systems process


the text on a page, it's something separate.


So that's kind of a, yeah.


That's a big challenge.


I mean, the other approach is to focus on things like Google My


Business, Google Business Profiles,


I think the new name is, and to see the websites more


as kind of like a business card for the Google Business


Profile listing.


And in cases like that, you don't necessarily


need to have all of these websites indexed.


That might be another way to look at it.


But that's probably not ideal if you're


focusing on making the websites and you


want them visible in search.


Well, it's a pretty new brand.


So it's a challenge because people are not


looking for brand name.


People are looking for services that match their local area.


So yes, of course, if the brand was very well established


already and very well known, I mean, there's no problem at all.


But the thing is that the brand is unknown yet.


And yeah.


But in that case, I would really focus on making


one very strong website because that also makes it


a lot easier to rank because then you just promote


that one strong website.


You can use that for any marketing campaigns


that you do and all of the links, the kind of the signals


that you get for your business.


They're concentrated and then spread out


through the individual locations rather than having


each individual location kind of fight for themselves.


I understand.


Thank you very much for your answer.


Sure.


Let's see.


Philip.


Hi, John.


Good morning.


Hi.


So we have a pretty strong US.com presence


with no real international implementation at the moment.


But we are starting to build out into Canada and UK


and we are kind of at a crossroads today.


Should we go ccTLDs or keep it under just the dot com?


We're a real estate company.


So our pages are pretty location specific.


We're probably going to end up in about a dozen countries


within the next year or two.


So my thought process is being able to take advantage


of being able to target locally and search console


where with the ccTLDs where I can't do that with the global


dot com and technology is not an issue for us.


So either way kind of works.


So I was wondering is there an advantage


of going one way or the other or is it easier for Google


one way or the other?


I think there are multiple things that kind of come


into play.


One is probably also the aspect of having multiple sites


versus having one really strong website.


Kind of like with the previous question,


if you're talking about a dozen different locations,


maybe that's less of an issue.


Maybe that's something that works out.


The other thing is with geotargeting,


we do use that when we recognize that people are looking


for something local.


So either way that you go, I would try to make sure


that we can figure out what you were targeting


to use for the website.


And ccTLDs is super obvious.


So that's I think a good approach.


Subdomains is an option.


Subdirectories would be an option.


What I wouldn't do is just kind of use URL parameters


or something like that where it's like,


well, you have your main global website


and you can search for an individual country


and then somewhere in the URL that country is also mentioned


because that would essentially mean that we can't do


geotargeting at all for the website.


Right.


OK.


Yeah, right now we're doing like the dev site


is like slash FRCA or we're looking at the.ca for Canada.


But it's just we're trying to figure out which makes sense.


Yeah.


We have like our US site has 40 million pages.


Our Canada site would probably have a half a million pages


with only 5% of them are actually one to one


because they're location specific.


So I don't know if that might make any difference.


Now, I think from a technical point of view,


they would all be kind of equivalent.


It might be that from kind of an SEO ranking point of view,


you could have some advantages by kind of building


on your existing domain.


But I think it also depends a little bit


on what your marketing goals are.


If you want to really position these as like,


we're the real estate company for Canada,


then you kind of want to have your own domain.


If you want to position it as like we're a global company


and we also do Canada, then having


that within your existing domain might be OK.


So I think from a technical point of view,


like all of these options are open, which way you go


is kind of almost like a strategic decision.


OK.


I really appreciate your time.


Thank you.


Sure.


All right.


Hazel.


Hey, John.


Can you hear me?


Yes.


Great.


So this time I only have one urgent and important question


is about index pages.


We just found that from January 13


that our index pages dropped like over 90%.


Like these are index pages and with actual traffic


in JSC backend and also in our log report.


So we check our JSC, we check the report,


coverage report in the JSC backend


and like almost 40,000 URLs and 14,000 index pages are dropped.


And this 14,000 URLs also increased on the quote


but currently not indexed that one time.


So the number is the same, exact same.


And we also check the samples.


We also check the samples that index and also the quote


but not indexed.


In our site, we didn't find anything unusual


like the canonical and also some also the Manta tag


marked as no index.


No, there is not that issue.


So we just couldn't find a way to identify the problem.


So we just hope that you can give us


some recommendation on which aspects can we figure out


and to identify the problem.


No, I don't know offhand.


It sounds very similar to one of the previous questions.


So I'm kind of worried that I need to dig


into this a little bit more.


If you can send me some sample URLs,


then I'd love to take a look or maybe drop them here


in the chat and then I can pick them up afterwards


and check them out with the team.


I think the one aspect that you probably also want to check


is whether or not we can actually crawl them properly.


I imagine you already looked into that,


but it's always good to double check there.


Again, if you can drop me some URLs,


I'm happy to take a look at that with the team


because one site going down and indexing is one thing,


but if there are multiple people at the same time coming


in with this kind of topic, then we


should probably take a better look.


So like you said, we have checked the URLs in Google Live text.


Yes, they are all crawlable and also indexable,


but the weird thing is they are not.


We also check our sitemap and the robots text,


all good, nothing unusual, and also the mobile friendly text.


Yes, I will drop the URL in drop to you later


and I also want to specify that when we check the samples,


we notice that Google crawl our URLs.


Like the URL, the Google crawl have some unusual mark


like question mark and also some plus mark in the URL,


but our actual URL don't have these marks.


And yes, that's one thing unusual we spotted.


We are guessing that if that's a problem,


but like I said, we already analyzed our log report


and find the actual rate of these URLs


that Google crawl is very less, maybe 2% to 3%.


Yeah, so it's not a huge amount of these URLs.


Yeah, I mean, what always happens


is we discover a lot of URLs for websites


and if we don't think that they're important,


we will kind of keep them in our list


and at some point we'll try to crawl them.


And I suspect these are just kind of random URLs


that we discovered over time and we try to crawl them


from time to time to see if there's anything


that we're missing, but it's not a sign


of a problem of a website if we also crawl some random URLs.


Yeah, the question is for these random URLs,


we can find these URLs either.


So in our website, in internal links, anywhere,


we just can't find this URL that Google crawled.


Yeah, that's weird.


Yeah, I mean, that happens.


And sometimes we collect these URLs for a longer period of time


and then try them maybe a year later.


So it's sometimes hard to track back,


but it's not a sign of a problem.


It's really just our systems recognize,


oh, we have some extra space to crawl URLs


and we also happen to have this big collection of URLs


that we don't know anything about.


So we will just try them.


OK, great.


So as for the index pages, do you


have some maybe main technical aspects that maybe affect this,


maybe result in this?


It's hard to say.


I mean, usually the main issue is really


about overall quality of a website, which


kind of goes into the decision whether or not


to index individual URLs.


And that's something that can also change over time,


not so much that the quality of your website changes,


but kind of our perception of the quality of the website


can change over time.


And that's usually the main element


that comes into play there.


And if you see these kind of indexing changes happening


over a short period of time, then it


could be that our systems have just kind of changed the way


that we evaluate quality for your website


and suddenly everything is in a slightly different bucket.


Whereas if you see them over a longer period of time,


then it's usually more that over time our systems are less


and less confident about the website.


So our situation is more like happening in a second,


in a day.


And also one weird situation we spotted


is that the thing is we have one main domain


and several subdomains based on different countries.


And the situation I just said about the drop index pages


only occur in one subdomain site and only occur


the several specific pages in this one subdomain.


Like this subdomain we have product pages, category pages,


and also some online discount pages.


Yeah.


And we found this situation in specific online and discount


pages, not in other pages.


That's the weird thing we also spotted.


I mean, if it's a specific like the change


in the perception of quality by country or by language,


that is also normal from our point of view.


But if you're finding it in a specific kind of pages,


then that might be something to look into a little bit more