It's not that you can report the whole website.


English Google SEO office-hours from December 24, 2021

That's great.


Another question that I have is about indexing.


Recently, me and a large community of webmasters,


almost all of us have problem for indexing new pages


from Google.


I'm going to ask you, even I, I publish high quality content.


I submit a site map and sometimes request indexing


from Google Search Console, but I still


have problem for indexing new content,


or it's indexed by July.


So I'm going to ask you, have you ever heard,


in this case, recently, it's a bug from Google


or it's a new address update?


I mean, these kind of questions come up every now and then.


So from that regard, yes, I have heard about these questions.


But as far as I know, there is no bug


on our side in that regard in the sense


that I think the tricky part is we just


don't index all content.


And some websites generate a lot of content.


And if we don't index everything from our point of view,


that can be OK.


But maybe you want everything indexed.


And we can't do everything all the time.


But the tricky part, I think, is that in the past,


it was such that a lot of websites


were technically not that great.


So it was a little bit clearer which kind of content


did not get indexed.


And nowadays, websites are technically OK.


And it's almost like the quality bar is a little bit higher


in that sense, that anyone can publish something


that theoretically could get indexed.


But we still have to make sure that we're


indexing the right things that are actually useful and


relevant for users.


So we sometimes have to leave some things unindexed.


AUDIENCE 1 That's great.


Thank you, John.


And I have to say you are very popular among Iranian webmasters.


Happy holidays.


JOHN MUELLER Oh, wow.


Cool.


Thank you.


You too.


AUDIENCE 1 Thank you for your time.


Thanks.


Rob, over to you.


You're very popular over here as well, John.


Oh, my gosh.


Not specifically here in this household,


but outside of here.


Outside.


People speak very highly of you.


I have an AMP question.


Our developer said that some of the pages


are not being indexed because we're using unsupported HTML


tags and attributes.


But the page is only our blog, not our normal site


that's in AMP.


And so some of the, I think, on the page,


some of the normal menu bars, header, footer,


and that sort of stuff is in non-AMP


or uses some stuff that isn't supported.


So can that mean that the whole page won't be collected?


Or do you need to, is there a best practice


to create a different header and footer and different


surroundings so that there's two versions of the page, one that's


in the same way that we do for React Java,


we create two versions of the page


so that there's a kind of backup?


Do you do that for AMP?


I think there are multiple things that


kind of come together there.


So I'd like to just say it depends.


But anyway, no.


The thing is, if it's not a valid AMP page,


then we can't process it with the AMP cache and all of that,


which means if you have a kind of a traditional HTML


page and the AMP version of that page, what would happen


is we would just index the traditional HTML version


of the page and use that.


So from kind of an indexing point of view,


that would be fine.


If you have a pure AMP site where you just


have the AMP version, then we would still index the AMP page


essentially as an HTML page.


Even if it's invalid AMP, we just


wouldn't be able to process it with the AMP cache


and all of that.


So essentially, it's an error in the AMP page.


And we won't be able to give you the advantages of the AMP


cache and all of that.


But it wouldn't affect the rest of search.


So it's not like it's dropping rankings.


Exactly.


Yeah.


It would still be indexable.


All right.


And would.


OK.


So it wouldn't get the AMP kind of boost, as it were.


But it's still a fairly quick page in general


if it's built from.


No.


So some people, therefore, consider having the whole,


when you say AMP page, it is literally the whole page,


including everything on the page, whatever surrounding it.


I think there's some issues that are warnings on the AMP side.


And those wouldn't affect the AMP treatment.


But some things are treated as errors.


And we would say we wouldn't be able to ensure


the kind of the full AMP cache.


Because we don't really know exactly what


is happening there or similar.


Yeah.


Thanks.


Cool.


Let's see.


Axel.


Good morning, John.


Hi.


Last week, I asked you about our French sexual wellness site,


about the ranking on our brand name.


I was just wondering if you passed it


on to the SafeSearch team.


And maybe you have heard something.


Yes, I passed it on.


And they're also kind of torn in terms of,


is it working as intended or not?


Because, I mean, essentially, I think it was like,


what was it, Adam and Eve, the website?


Yeah, and the query.


Those are the kind of queries where people probably


wouldn't be expecting a kind of a sex toy website.


So that's, from our point of view,


it's something where we'd say, well, it


can happen that our systems try to fix that and then wouldn't


show that automatically.


So from our point of view, I would not


assume that that would change immediately.


It's possible that at some point over time, that would,


I don't know, shift back.


But it's definitely not something


where the team, when they looked at it, that they said,


oh, this is a bug on our side.


OK, so there's nothing that we can do right now?


I don't really think so, no.


OK.


Specifically for a quick, yeah.


Can I just add something?


Because I had a look at that as well last week.


And I had a chat with Axel about this.


The funny thing is that what we see


is we do see a Canadian website with the same title, which


is also kind of like 18-plus related, which does rank.


So it's kind of confusing why in France, a French website


won't rank when a Canadian website does,


which is kind of related as far as topic is concerned.


Yeah.


I mean, if you point it out like that,


I would assume the SafeSearch team would say,


OK, then we need to fix the Canadian website too.


But I don't think they would look at that and say, oh, well,


this other sex toy site is ranking.


Therefore, we should just show all sex toy sites.


I don't see that happening.


So I think, I don't know, at some point in the past,


there was a similar website.


What was it, I think Jack and Jill, something like that,


which is a nursery rhyme, not like a Bible story.


But they ran into similar issues where


people were searching for Jack and Jill,


and they kind of expected nursery rhyme or some,


I don't know, almost like kids information.


And running across an adult website,


that's kind of unexpected and something


that, from our point of view, we would almost see


as a bug in our search quality.


So from my feeling, I don't see that changing.


It's possible that at some point,


we would try to figure out, oh, this


is someone who is explicitly looking for sex toys.


And we can recognize that somehow.


And then maybe we would be able to show that.


But otherwise, I don't see that being


treated as a bug on our side.


OK, yeah, it was just weird that another sex toy site is just


in the second position.


But I don't want to bitch about other sites, of course.


Yeah, I mean, I can pass the other side on to the team


as well to look at.


But I don't think that really helps you.


Yeah, yeah, OK.


Yeah, it's pretty much the same.


So it's not that they are doing anything different.


So it's just weird that, for example, now they are there


and we are gone.


I mean, from our point of view, it's


not that it's tied to any specific site.


It's not that the web spam team went in and said, manually,


your site should not rank for this query.


It's really essentially our safe search algorithm


is trying to figure out what is relevant to people, what


is not surprising in a negative way for people who are not


expecting that, those kind of things.


OK, OK.


Then I know enough.


Thank you.


OK, cool.


All right, Christian.


Hi, good morning again.


I was a little bit surprised to see that the Webmaster


Hangout is taking place today.


So thanks a lot for that and for all the other Hangouts


as well, John.


Thanks.


Cool.


And yeah, I figured out a question.


And it's about the product reviews update.


I was seeing that even if the update only


affects English speaking websites,


so I was seeing some movements in German search as well.


So I was wondering if there could also


be an effect on websites in other languages


by this product reviews update or any kind.


So of course, we had lots of movement and volatility


in the last weeks.


And so yeah, my question is, is it


possible that the product reviews update


affects other sites as well?


I don't know, like other languages.


My assumption was this was global and across all languages.


But I don't know what we announced in the blog post


specifically.


But usually, we try to push the engineering team


to make a decision on that so that we can document it


properly in the blog post.


I don't know if that happened with the product reviews


update.


I don't recall the complete blog post.


But from my point of view, it seems


like something that we could be doing in multiple languages


and wouldn't be tied to just English.


And even if it were English initially,


it feels like something that is relevant across the board.


And we should try to find ways to roll that out


to other languages over time as well.


So I'm not particularly surprised that you


see the changes in Germany.


But I also don't know what we actually


announced with regards to the locations and languages that


are involved.


Yeah, I was just checking to be sure.


And yeah, the blog post said it's only English websites,


English language websites.


So this was because I was so surprised.


But yeah, good to know anyway.


And even if it's only targeted on English speaking websites,


so you say it could affect other sites as well sooner or later.


OK.


Yeah, I mean, usually that's a goal


with these kind of updates where we


try to get started with one language or one location


and see kind of like what we need to tweak.


And then we expand from there.


And I imagine with something that is more content related,


usually it takes a bit longer to expand to different languages.


But I honestly don't know what all they're looking at here.


But at the same time, I also wouldn't


expect to see this as being something that,


like over the Christmas holidays,


we suddenly roll it out in 12 other languages kind of thing.


Because the team that works on this


also goes on holidays at some point.


And if they launch something briefly


before they go on holidays and it breaks,


then they have to kind of like cancel their holidays as well


and fix it again.


So we try to avoid that a little bit.


SPEAKER 1


And it's good to know so we can relax a little bit


in the next few days.


SPEAKER 2 Well, I don't know if you can relax.


I find holidays really stressful just on their own.


So whatever.


SPEAKER 1 OK.


Thank you.


SPEAKER 2 Cool.


Let's see.


Hazel.


SPEAKER 3 Hey, John.


Merry Christmas Eve.


So I got one question about localization.


Do you know any other ways to localize


the same set of pages for different English speaking


countries?


Like right now, we have several subdomains


with geo top level domain, like maybe from Australia,


New Zealand subdomains.


And we have set the country in the GIC backend


and also use the offline on page level.


But other than that, we couldn't figure out some other ways


to help us to localize these subdomains.


Do you have any maybe good methods or maybe some ways


that we can improve?


Yeah.


So I think you covered the main ones.


So that's geo targeting in Search Console


and the hreflang settings.


Geo targeting works on kind of a subdirectory or subdomain level.


So it's all pages in there.


Hreflang is on a per page basis.


So if you have kind of like a home page for one country


and different product pages for the same country,


then each of those pages would need


to be cross-linked with hreflang.


So sometimes that's a little bit more work.


But essentially, those are the two main methods.


The other thing that I always try to recommend


is to have some kind of a backup plan.


Usually, that's something like a JavaScript-based banner


that you can show when you recognize


that the user is on the wrong version of a site.


So for example, if a user from Australia


ends up on the page from, I don't know, England,


then you could show a JavaScript banner saying,


like, hey, we have an Australian version of this page here.


You can go there directly.


The advantage of a JavaScript-based banner


is that you can block it with robots.txt


so that from an indexing point of view, it doesn't show up.


And if you don't automatically redirect,


then essentially all of the search engine side of things,


they will be able to process those two versions


independently.


So that's kind of the other recommendation I have there.


And I think finally, the other thing to keep in mind


is if these pages are essentially the same,


then it can happen that we treat one of these pages


as the canonical version.


So for example, if you have a page for New Zealand


and Australia, and the whole content is the same,


the only thing that's slightly different is the currency


on the page, then it can happen that we fold those pages


together, and we pick one of them as a canonical,


and we use that as the basis for search.


The confusing part here is that if you have


hreflang on those pages too, then we


will still use the hreflang to show


the right version of the URL.


But the index content will be just


from the canonical version, and all of the reporting


in Search Console will be for the canonical version.


So that makes it sometimes a bit tricky, especially


if you have a larger website with essentially always


the same content for different countries.


AUDIENCE 1 Yeah.


Yes.


So our situation is more like the second one you said.


We all have the same content for different subdomains.


We have a canonical tag, like you just said.


In this situation, how can we maybe


make Google to index all pages?


JOHN MUELLER I don't think you can.


And you generally don't need to, because we will still


process the hreflang across those versions,


and we will show the right URL in the search results.


It's just the content that's indexed


is from that one canonical version.


And if the content is the same, then we just


need that content once.


So the only really confusing part


that is there in that situation is that Search Console reports


on the canonical URL.


And that makes it really hard to recognize


when is the Australian page shown,


when is the New Zealand page shown,


because we just show, I don't know, one of those two.


AUDIENCE 1 OK.


I see.


So do you think the same content is


friendly for, like I just said, the localization?


JOHN MUELLER I think you can do it.


I don't think it's optimal in all cases.


And in particular, for things like the home page of the site


or important pages that are site-specific,


I would try to make sure that you have different content


there so that they're really indexed independently


and that they can rank for the independent versions


of their content.


So those pages, I think, are really


critical to be clearly separate.


But for products and categories and things like that,


I don't really think it matters that much if we choose one


as economical.


AUDIENCE 1 Yeah.


The product page is almost the same product pages.


Yeah.


OK.


Thank you.


I got you.


And also, another one question is,


I don't know if you remember that I


asked a question about blocking ad URL in the robots


text for Google Maps.


Yes.


Back then, you said it's perfectly fine.


But later, after we operated it, and our PPC team,


they add the new ad campaigns, but find


that all campaigns are disapproved in the ad system.


So wait.


Oh, OK.


So do you think?


I don't know how the ad side deals with that.


I thought that would be fine.


But you would probably need to check with the ads folks then,


just to be sure.


Yeah.


Just to, yeah.


And later when we found out that situation,


we immediately put the ad URL back to the normal.


OK.


And then they all got crawled again.


Just to let you know.


Thank you.


Thanks.


Cool.


Sumit.


Hi, John.


Good morning.


Thanks for the Google search form.


Actually, I have a few questions,


and also asked last week.


Like, my first question is that, like, my website


has millions of pages, like categories, subcategory,


and product, e-commerce kind of pages.


So we have added a dynamic content


because millions of pages.


So they're very difficult to add to separate content,


or maybe unique content on each pages.


So we have added dynamically template-based content


on category pages, subcategory pages, and product pages.


So that would be good for our website performance or not,


or should we update the content for each page?


Like, now content change as per the page.


Like, if page comes from rice buyers,


so content replaced with the rice buyers


kind of keywords in the content and the location.


So that is enough for the page, or we


need to add more unique content on each pages?


I don't know.


It's hard to say just based on what you describe.


So to me, it feels a little bit like you're artificially


just adding keywords and content to pages,


and doing that artificially in the sense


that, oh, we hope search engines pick up


these keywords that we drop.


I don't think that's a good idea.


But dynamically adding relevant content to a page,


that can make sense.


Because dynamically adding content


is essentially just doing, I don't know, a database lookup,


and adding content based on that.


So that's usually normal.


So I don't know.


It really kind of depends on how you have that set up.


And the main thing I would really avoid


is that you run into a situation where you're artificially


adding content to a page just in the hope


that this page ranks better for the keywords


that you artificially add.


Because then the page itself will


contain this artificial content.


And when users go there, they'll be like,


why are these random keywords on this page?


It doesn't make any sense.


So from that point of view, making sure


that you actually have good, relevant content


for those keywords, that's more what I would focus on,


and not so much that you just find a way


to inject a bunch of keywords into a page.


SPEAKER 2 OK.


So we have to write up relevant content for each page


so that Google gives the value to the page.


I mean, it's not that you have to write a book for every page.


But it should be something on the page that is relevant.


And if it's a category page, then the products


that you have listed there are very relevant, for example.


And usually, you have a description of that category.


That description is very relevant.


But it's not that you have to write a Wikipedia article


on the bottom about all of these products


and where they come from and everything like that.


That's not necessary.


But a little bit of information that is relevant to the page,


that does matter.


SPEAKER 3 Yeah.


Thanks.


And I have one more question.


Like, my website is client-side rendering,


on React with client-side rendering.


So when we turn off the JavaScript in browser,


so my page is totally blank.


So that can be the cause of lower ranking


or maybe the poor performance of the web page?


It shouldn't be, no.


Because for search, we do rendering,


and we process the JavaScript on the pages.


So if it's visible in a normal browser


and you're not doing anything particularly bad,


then we will be able to index those pages normally.


You can double check with the Inspect URL tool in Search


Console to see if the content is actually


visible when Googlebot tries to render the page.


And if the content is visible, then you should be all set.


SPEAKER 2 OK.


And one more thing.


Like, should we add Contact Us page or GMB page


on our website?


Like, we are target global.


So do we need to add Contact Us page and GMB, Embed GMB,


or Create GMB page as well for the website?


SPEAKER 3 I think, like, a Contact Us page always


makes sense, even for a global business.


The Google My Business or Google Business Profiles,


that's something that's usually more tied to a local business


location where people can go.


But if you have a local business location where people can go,


then I would definitely set that up.


I mean, it's free to set up, and it's helpful for, I don't know,


getting people to come in person at least.


SPEAKER 4 Yes.


And last question.


Like, we have already added a search box in our website.


So users come on our website and search over there.


And it generates a unique URL for every search.


So these URLs should be indexable or not?


Usually not.


The main reason for it, I think there


are two main reasons for that.


On the one hand, it's very easy to end up


in a situation where you have another million URLs that


are just different searches, which


doesn't provide any value to you.


So kind of this, we call it an infinite space.


That's that kind of a problem.


That's something you want to avoid.


And the other thing you want to avoid


is that people do spammy things in the search box


and try to get those things indexed,


which could be something like they're searching


for their phone number.


And I don't know, their business type


that they have, and then suddenly your website search


page ranks for that kind of business


and shows their phone number.


Even if you don't have any content that


matches those queries, sometimes they


do this to try to be visible in the search results.


So I would block these kind of search pages with robots.txt.


That way, you can be pretty sure that we won't be able to index


any of the content.


Yeah, thanks, John, thanks for the answer for all the questions.


Thank you very much.


Thanks.


Yeah.


Cool.


Let me go through some of the submitted questions,


and I'll get back to the others here


who have their hands raised as well towards the end,


just to make sure that we cover some of the submitted stuff


too.


The first one I have on my list is,


would an SEO firm be classified as a your money or your life


website, or is it only related to medical and financial advice


websites?


It's an interesting question, but I


don't think SEO websites are that critical to people's


lives.


Obviously, if you work at an SEO company,


then you're kind of tied to that.


But it's not that the website itself


is like your money or your life type website.


So from that point of view, I personally


wouldn't see it as fitting.


And not every website that sells something


is kind of like falling into this category.


But what I would recommend here is,


rather than kind of like blindly trying to see,


is this type of website kind of falling


into this specific category, is to read up


on where this category came from, namely the quality rater


guidelines, and to kind of understand a bit more


what Google is trying to do with kind of understanding


these different types of websites.


Because usually that will give you a little bit more


background information on what is actually happening


and what could that mean for these type of websites


that you're working on.


Then at the beginning of December,


we migrated a CMS site.


The site averaged 50,000 sessions per day.


It didn't have AMP, and it had a lot of performance and SEO


problems.


The migration consisted of making respective 301


redirects, going to a full AMP format.


And it goes on and basically says, since the migration,


the website has basically lost all traffic,


or a lot of traffic.


So I took a quick look at this before.


Usually what I do with these kinds of questions


is go to our internal tools, where


I see something similar to what you would see in Search Console.


And I try to look at the period before the change


and after a change, in particular,


with regards to kind of like the overall visibility


that the site gets, so the impressions.


And sometimes that's tied, that kind of


matches when a site actually makes technical changes,


and sometimes it doesn't really match.


And one of the things that I noticed


when looking at this site in particular


is it used to rank for a lot of terms


where I would consider it not to be that relevant.


So for example, what I saw is it was ranking for things


like how to log into WhatsApp, or how to install WhatsApp,


how to download WhatsApp, those kind of queries.


And the website itself is not actually WhatsApp.


So from my point of view, that's something where essentially


this website got a lot of traffic for queries


where I would say it could be considered almost like a bug


on our side that this happened.


And obviously, we show a number of different sites


for these kind of queries, and it's not


that we just show that one official site for that.


But it's still something where I would say,


if you're not WhatsApp and you're kind of like suddenly


no longer ranking for queries like how to log into WhatsApp,


then from that point of view, it's


like it's not really a bug on our side that this has changed.


And sometimes these kind of queries


can drive a lot of impressions, and with them, probably


a lot of traffic as well.


So if you just look at the overall traffic to a website,


it can look like there was a significant change.


But if you look at the actual kind of relevant traffic


for a website, assuming I think this is something


like a news-type website, if you look


at kind of like the relevant traffic that


is relevant for this kind of website,


then that looks like it's actually pretty stable.


And it's sometimes tricky to figure out


which part of the traffic that you're seeing


or the impressions that you're seeing


is actually relevant to a website.


And it's hard to also have a high-level view of the website


while trying to ignore those less relevant things.


So for example, we saw this with our own search documentation


where we worked together with the SEO folks


to try to de-emphasize specific queries.


In particular, I think it was like the query, I don't know,


Google Video or something like that, where lots of people


were searching for Google Video.


And we had a page on video structured data


for Google, which technically kind of like


matches those keywords.


But practically, it didn't really


make sense for those users.


So when we looked at the overall impressions to our site,


we saw this fairly high number.


But actually, that wasn't really useful for us as a metric


because it contained this big segment of traffic


for things that are kind of irrelevant for our site.


And that, I think, is a bit tricky


and means that when you recognize


this kind of situation, it means that you can't just


look at the overall traffic to a website


and say, oh, this is a metric that should remain stable


or go up.


You should try to figure out what


is the portion of relevant traffic there,


and how can I recognize that and track that over time.


So from my point of view, looking at this specific site,


I didn't see anything technically incorrect


with regards to this migration.


It's essentially just our search systems


trying to figure out what should we really


show for queries like this.


And maybe it's not that particular site.


And probably it's not really a bug


that we would not show that.


And my feeling is that the timing here


was almost more accidental with regards


to the technical changes that were made.


And it's something that would have happened anyway over time.


Let's see.


The structured data for payroll content,


I think we covered that.


Does Google have someone tasked with the job


of recording each update in a logbook


and noting which aspects of search are impacted?


If so, is it called Google's Book of Secrets?


Yeah, I don't know.


Alan, I don't really have a good answer for you there.


We do track the changes that we make.


And we try to figure out what all is changing over time.


But there are lots of things that are changing in search.


And sometimes it's really hard to track back


because these things are approved at some point.


And then they launch at some point.


And when you look at an individual URL


and you see changes there, it's really hard sometimes


to track back, even on our side, which


of the changes had an effect here


and what caused this kind of difference in ranking.


So even if we gave you this kind of logbook of Google's search


changes, I think it's really hard to turn that


into something useful and say, well,


now that I know what Google has changed,


I will always be updating my site


to match that because you can't really do the reverse of that.


So that's kind of tricky.


And the other aspect is you want this to be tracked in Excel,


which I don't know.


That doesn't seem like a good idea.


When it comes to breadcrumb structured data,


does it have to be exactly the same as the breadcrumbs


that a visitor would see on a page?


I sometimes see a condensed version


of breadcrumbs on the page while the structured data


is a complete breadcrumb path.


Are both acceptable options?


Essentially, what we do with structured data in general


is we try to recognize if the structured data is


visible on a page or not.


And if it's not visible on the page,


then we have to figure out, does it still make sense to show


this in the search results?


So if you're doing something like showing


shorter version of a breadcrumb on a page


and we can't match that, then it might be a bit hit and miss


if we actually pick up that breadcrumb markup and use that.


If you're taking individual crumbs,


or I don't know, like the individual items


in the breadcrumb list, and you're just


showing some of those but not all of them,


then it might be that we just pick up those.


It might be that we still pick up the rest


because we see overall a lot of the breadcrumb matches.


But it's not guaranteed that we will


be able to pick up and use the full breadcrumb markup


that you have if you're not showing that on the page.


And that's similar to other kinds of structured data.


I think the main exception that I'm aware of


is I think the FAQ markup where you have questions and answers


where, from our point of view, the important part


is that the question is actually visible


and the answer can be something like a collapsed section


on a page.


But the question at least has to be visible.


I have a few sites from the same owner that


talk about different aspects of the same topic overall.


Let's say gaming, for instance, and different sites


talking different parts of gaming or different games.


Would it be considered against the guidelines


if the footer of each site of one links to the others?


So from our point of view, as long


as these are significantly different sites,


that's perfectly fine.


As long as you have a reasonable number of sites,


then I don't see a problem with that.


By reasonable number of sites, I'm saying, I don't know,


maybe like one or two handful of sites that you link like this.


If you have something like hundreds of sites


that you're linking like this, then to me,


that starts looking a lot like doorway pages, doorway sites.


And that would be something I would avoid.


But from a technical point of view,


you could do something like this,


linking between the different versions of the different sites


that you have, if it's something,


I don't know, along the lines of like 5, 10 sites,


maybe maximum.


From a practical SEO point of view,


I don't know if you actually get an advantage out


of splitting things up into separate sites like this.


Sometimes having one really strong website


is a lot more value than having multiple sites that


are kind of like lower value.


In particular, if you're active in a very competitive area


and you take your pretty competitive site


and you split it up into 10 different versions,


then it can be that those 10 different versions are


individually kind of seen as being less strong.


And then in that one very competitive area


where you're active in, then suddenly you


have 10 sites that are seen as a little bit less strong, which


can't compete at all with the first page search results.


So that's something also to try to keep in mind,


in that just because you can split things up


into separate sites, sometimes it doesn't really


make sense to do that.


And I'm a big fan of having fewer sites,


not having more sites.


On the one hand, it's easier to maintain.


But on the other hand, you can make


your sites a lot stronger too.


Let's see.


A question about multilingual sites.


We run a site with under 300 index pages, all in English.


We're looking to translate about half of these pages


in Spanish, which will be placed in the subdirectory


on the same domain, like slash ES,


and tagged as alternate language versions of the English


content.


Is it OK to translate only some of the page's content,


or should we translate everything to exactly mirror


the English website and stand the best chance


of ranking in other locations?


I think we looked at this last week.


But in any case, it's fine to just translate


some pages on a website.


We look at the language of pages individually.


So if you have some pages in Spanish,


we just look at those Spanish pages


when someone is searching in Spanish.


It's not the case that we would say, oh, there


are a lot more English pages and Spanish pages here.


Therefore, the Spanish site is less important.


It's essentially these are Spanish pages,


and they can rank well in Spanish.


So from that point of view, it's not


something where you must have everything translated.


Obviously, for users, sometimes it


makes sense to have as much content as possible translated.


But usually, this is something that you incrementally


improve over time, where you start with some pages,


you localize them well, and then you


add more pages, different pages as well over time, all of that.


The hreflang annotations are also on a per-page basis.


So if you have some pages in English and in Spanish


and you link those, that's perfectly fine.


If you have some pages just in Spanish, that's fine.


You don't need hreflang.


Some pages just in English, that's also fine.


So from that point of view, this seems like a reasonable way


to start.


Cool.


OK.


Let me see.


Let's maybe switch back to some more live questions


towards the end.


Rohit, I think you've been patient for a while.


Hi.


Good opportunity.


I hope I'm audible.


The noise is clear.


So it's a good question about the crawling.


The website I'm talking about is a WordPress website.


It automatically generates multiple unwanted URLs.


What I'm going to understand is, is there a way


that I can stop the crawler to find out this URL?


I know I can noindex it.


Those are all noindexed URLs.


But then I can see them on the search console


under the excluded part.


I mean, is this going to affect the crawl


budget of the website?


Because it's a news website.


We have thousands of URLs.


And if Google crawler is crawling unwanted URLs,


though it's not getting indexed, is there a way to stop it?


And is it going to affect the crawling budget?


How big is your website overall?


More than 5,000 to 10,000 URLs.


OK.


So I think at that size of a website, on the one hand,


I would not worry about the crawling budget.


Because we can crawl that many pages fairly quickly, usually


within days.


Yeah.


But the other thing, I think, with regards to noindex,


is the noindex is a meta tag on the page.


So we have to crawl the page to see the meta


tag, which means you can't avoid that we check


the noindex pages.


We have to check them from time to time.


However, if we see that there's a noindex on the page,


then usually over time, we crawl those pages less often.


So we will still double check every now and then.


But we won't check as much as a normal page that


is otherwise indexed.


The other approach is to use robots.txt.


With the robots.txt file, you can block the crawling


of those pages completely.


The disadvantage is that sometimes the URL itself


can be indexed in the search results.


Not the content on the page, but just the URL alone.


And if the content is otherwise similar to things


that you have on your website.


So if you, I don't know, for example,


have a football news website, and you


have some articles that are blocked


and some articles that are allowed for crawling,


then if someone is searching for football news,


they will find the indexable versions of your pages.


And it won't matter that there are other pages that


are blocked by robots.txt.


However, if someone explicitly does a site query


for those blocked pages, then you


would be able to see those URLs in search.


But again, for the normal user, they're basically not visible.


So from that point of view, in a situation like yours,


on the one hand, I would not worry about the crawl budget.


And from a practical point of view,


both the no index and the robots.txt


would be kind of equivalent in the sense


that this content would probably not


appear in the search results.


And we would still need to crawl it if there's a no index,


but the numbers are so small that they don't really matter.


We might still index it with a URL


if they're blocked by robots.txt.


But again, if you have other content on your website that's


similar, it doesn't really matter.


So which one should you choose?


I don't know.


I would choose the one that is easier


to implement on your side.


And if, for example, you have WordPress


and you can just have a checkbox on the post that


says this page, no index, maybe that's the easiest approach.


It kind of depends on what kind of setup that you have.


OK, cool.


Thanks.


Cool.


OK, I don't think I can pronounce the next day.


Yeah, OK.


How do I pronounce your name?


Yeah, it doesn't matter.


Can you hear me?


Sure, yes.


Yeah.


Actually, I have some question about the people


who use traffic bot to manipulate the Google ranking.


Yeah, I'm in Vietnam, and I saw the locals in Vietnam


about SEO service.


Yeah, SEO service.


They try to use the traffic bot to drive traffic


for this keyword and this variation about SEO service,


just like advanced SEO service or something.


And I see the ranking, I see the traffic.


It grow from 20 to 30,000 all in just one week,


just one week for all of the various and the ranking.


And the ranking and the website appears from nowhere


to top one.


So what do you think?


What do you think?


Is the effect negatively on the marketplace or something?


I don't know.


It's hard to say.


I think one really tricky aspect there


is that we don't use something like that as a ranking signal.


So it feels like you might be seeing something in your tools


when you look at that, which is not actually


the reason for the change that you're seeing in search.


It might be, for example, that maybe other sites just


happened to drop out of the search results at that time.


And because of that, we ended up showing something that


was less visible previously.


But it also sounds like you might


be seeing some kind of almost like a search quality


issue in that it's perhaps not a spammy site.


Like, since you didn't mention that it was spammy,


it's just an SEO site?


Yeah, it's an SEO service site.


Yeah.


It's too bad because I couldn't share my screen for a visual


look.


But actually, I have a tweet about this case study.


So can I drop my links to this comment?


Sure.


Put it in the chat.


And then I can pick that up.


And I can show that to the team here as well to double check.


But I think it's really tricky, especially when you look


at things like search volume.


Because that's something that the external tools,


they can just guess.


You can't really know.


Just going to say that organic keyword just 43.


But organic traffic is 27,000.


Organic traffic for all of the queries of our SEO service


is quite crazy.


And maybe perhaps the search marketplace.


Yeah.


I don't know.


I feel it's really tricky when you're


looking at external tools and saying,


oh, this other person's site is getting so much traffic.


Because I've also seen cases where


the tools have reported that a site is


seeing a big drop in traffic.


And then the site itself is like, what changed?


I don't see any change.


Yeah, I see.


It's tricky.


It's kind of tricky.


But I hope you can keep an eye on this.


Because in Vietnam, in local Vietnam,


this case appears too much.


OK.


Too much.


Yeah.


I don't know if I can fix too much.


But I'm happy to pass it on to the team to double check.


Thanks.


Great.


Thank you.


Cool.


Merry Christmas.


You too.


Let's see.


Andres.


Hi, John.


I also have a question about crawling.


We see in our log files, and also proven


that it's Googlebot via ITP, a lot of crawling


from the organic bot to UTM parameter URLs, Google Display,


and Universal App Campaigns.


But we have checked, and we don't


see any links coming from anywhere to those URLs.


So we're a bit surprised of this behavior.


Do you have any idea of where or why this might be happening?


And what kind of tag URLs are they?


Google Display.


So UTM, Google Display, and Universal App Campaign.


So both basically display campaigns.


Yeah.


I don't know offhand.


The one place where with Googlebot,


we also crawl pages that you list in ads campaigns,


I think is the for product search.


So if you have a product search feed or merchant center feed,


I'm not sure what it's called, set up,


then we would also crawl those pages for Googlebot


to make sure that we can pick them up for the merchant


center.


And if you have tagged URLs in there,


then that can happen that we will keep those tagged URLs


and reprocess them.


I don't know offhand how it works with merchant center.


It might also be that other people are able to submit


these kind of products from your site in a separate feed.


So it might necessarily not be you who's submitting them,


but maybe someone who's working on your behalf


or who has the permission to do that as well.


But that seems like the most likely reason


for something like this.


I mean, the other aspect is if we find links to these pages


somewhere, we will try to crawl them.


So if you have tagged internal links within a website,


we will still try to pick that up and crawl that.


If you have things set up in JavaScript


that maybe you have tracking URLs with these parameters set


up somewhere, and when we process the JavaScript,


it looks like it's a link to those tracking URLs,


we could also process that.


But it sounds to me like it's not individual cases that


is happening for your site, but rather like a large number


of these URLs.


And that feels a lot like the merchant center side of things.


AUDIENCE 2 OK.


Yeah, because it's quite large.


So those URLs are crawled.


So basically 50% of our crawling budget


or crawling of our organic bot.


But the thing is, I've also been looking into Search Console.


And in Search Console, that's not reported.


So we don't see this parameter URLs in Search Console.


Might that be an indication of something?


It depends on where you look in Search Console.


So in the Crawl Stats report, if they're


being crawled through the Googlebot infrastructure,


then they should also be listed there.


In the index coverage and search performance side,


I don't think we would list them.


Yeah, no, it was in the crawling report.


Yeah, so if they're not visible in the crawling report,


then that almost feels like something weird


is happening in the sense that maybe it's


not an official Googlebot that is crawling you like that.


I don't know.


It's hard to say.


Because we do have different systems


that use the Googlebot infrastructure,


and they allow for that reverse IP lookup.


And all of those should be listed in the Crawl Stats


report in Search Console.


OK, because we checked the IP and also the DNS.


And look up manually for a couple of them,


and it does seem to be Googlebot.


Does it map back to Google or to Googlebot directly?


Because within Google Cloud, you can also run services.


And those IP addresses go back to Google,


but they don't go back to Googlebot.


So that might be.


Just take in a terminal, and it is Googlebot.


OK, yeah.


Then they should definitely be in the Crawl Stats report


in Search Console.


OK, so mystery.


And I have another question, if I may.


Sure.


And does Google crawl ever websites without being


Googlebot?


Without being Googlebot.


So I don't know.


For example, in cases like you're trying to check,


how do you call this, like showing two different versions


to users and bot or something like this.


I don't know if there's any systems like that.


I don't think we would crawl like that.


We might check individual URLs.


And there are lots of other systems


that go into that as well, which could be something like,


I don't know, Google Translate, for example, that might use,


I'm pretty sure, that uses a normal browser user agent.


But it still goes through Google's infrastructure.


But we wouldn't crawl through Google Translate


then it would just be like individual requests.


So a large number of URLs, from my point of view,


I don't think we would process like that.


Other than, like I mentioned, the Merchant Center


side of things or the Ads Landing Pages checks,


those are also a large number of URLs,


but they're based on what you submit to those systems


appropriately.


In any case, those would be called via ad spot typically,


right?


Yeah, I think the Merchant Center wouldn't.


I think the Merchant Center would be normal Google bot.


OK, so basically no Google crawling large scale


without showing that it's somehow Google.


Yeah, I don't think we do that for policy reasons anyway.


But I'm kind of like, theoretically,


it might be that someone has tried that at some point.


But I don't think that's something


that we would do on purpose.


Cool.


OK, let me take a break here.


Thanks a lot.


Sure, thanks.


Let me take a break here.


I'll get back to the other questions that still


have their hands raised, but just


so that we have kind of like a reasonable length recording.


Thank you all for joining in, even on Christmas Eve,


sending so many questions our way.


I hope you have a good holiday time.


I'm still not 100% sure if I'll do one next week, but maybe.


So like the absolute last chance to get an offer hours in


this year.


We'll see.


But in any case, I wish you all a good start


into the new year and a good holiday time


if you're taking time off.


Merry Christmas if you celebrate Christmas.


Otherwise, just a kind of a quiet week with less emails,


hopefully.


Cool.


All right.


English Google SEO office-hours from September 24, 2021

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


SEO office hours.


My name is John Mueller.


I'm a search advocate at Google in Switzerland.


And part of what we do are these office hour hangouts,


where people can join in and ask their questions all


around their website and Google search.


A bunch of things were submitted already on YouTube.


We can go through some of that.


But maybe we can start with some of the folks here live.


And some people already have their hands raised.


And I think one of them dropped out.


Maybe I'll just start with you.


I don't know where you are, Jason,


but I'll just start with you.


Get everyone as well.


Oh, cool, thank you.


So kicking it off, we have a key button as part


of our mobile site navigation.


And we're looking to change it from a static button, which


always links to the same URL, to dynamic based


on some elements of the page the user is on in order


to make our experiences more relevant,


bring users closer to our key conversion pages.


So I've proposed a change which would update the button anchor


text dynamically, but it really pissed off our designers


by potentially increasing the button size


to accommodate the new text.


Then I proposed a change to the acceptance criteria resizing


the text based on the available button real estate,


thereby pissing off my accessibility folks.


So given all of that context, my question


is, is the global title attribute


an adequate replacement for anchor text,


or should we perhaps change the button to be a graphic


and use dynamic alt text?


What would your recommendation be here?


My understanding is we use the title plus the anchor text.


Essentially, together.


So if you have things in the title that kind of cover


the part that you're missing in the anchor text,


that should work out.


I'm not 100% sure, but this is probably also something


you could test with a made up word


that you put as a title attribute


and wait for a while for everything to get indexed


and see how that gets picked up.


But I'm pretty sure that we just combine those two together.


Cool, that really helps.


Thank you for the context.


Also, how important from an SEO standpoint


would it be for the dynamic nature of the button


to be based on the page content rather than personalization


through using cookies?


So we wouldn't use cookies, so we wouldn't


see what would happen there.


That's kind of the one thing.


So essentially, for Googlebot, it


would look like it's always based on the page content.


Because we wouldn't be able to give you a cookie,


so you wouldn't be able to keep any personalization for that.


We would essentially always see the same thing


that a non-cookied user would see.


OK, perfect.


I just needed that for my technology folks,


so thank you.


Cool.


All right.


Roshan.


Hi, John.


Hi.


So John, I joined a couple of months back


to ask a question on e-commerce product ranking.


So my business is around green tea, herbal tea.


And I don't think you'll be able to recall as much,


but just to give you some background.


So we have a small blog section.


We do useful blogs, and we are happy with the way they work.


And it's kind of directly proportional to the amount


of effort we put in.


So if we can see the amount, then that ranks right away.


More or less our experience is that it's


related to the amount of stuff in the article.


So we try to kind of collate all the information possible


by sorting out information from all research papers


and authoritative websites.


So that is working well.


My product pages do not rank.


And this is the question I asked you last time.


So your one piece of suggestion was


to focus on internal linking.


So for example, if we have a blog on weight loss green tea,


for example, so we're only linking to that very product


itself.


Because whenever we write a blog,


we have this on our agenda to only cater to one topic,


one kind of product.


And we don't link to random products.


We link to just one product from one blog.


We don't have a huge blog section.


I think there will be around 10 to 12 blog pieces.


But all of them work well for us.


We have product structure data in the search pages.


I can see that it's correctly picking up the reviews,


quantity, item, price, everything.


And we have enough amount of text,


especially compared to the product pages that are ranking.


We may not have as many backlinks to our product pages.


But when I do an eight way comparison of other websites,


I don't see that a lot of them have backlinks.


At this point, I am kind of lost.


So at some point, the product is going to go.


I need your help in that direction.


JOHN MUELLER-GRANT, MD, PhD OK.


It's very hard to understand you because you're breaking up


in between.


So I think what you're asking is you


have a blog section with blog posts, which


is ranking appropriately.


And you have product pages on your site as well.


And those product pages are not ranking as well


as you would like.


Is that correct?


VINAYAK LOHANI, MD, PhD Yes, yes.


Get it.


OK, so I think the aspect with internal linking


that you talked about, I think that continues to be important.


It sounds like you're already doing some of that.


One of the things also to keep in mind


is that for some types of queries,


we try to understand what the intent is behind the query.


And we try to figure out if someone


is looking for information about a product


or if they're looking to buy a product.


And then we might try to show one kind of page


or a different kind of page.


And it might be, I don't know your queries and your site,


but it might be that we're interpreting


the queries that are landing on those pages


as more almost like information seeking queries,


that people want information about a specific kind


of product rather than that they're looking


to buy one specific product.


And that's something that you can't really


change on your side because it's essentially


based on what we assume people are trying to find.


And the best thing that you can do there


is just to make it as easy as possible for people


to get to your products so that you have a clear call


to action on your blog post, for example,


so that it's easier for people who


land on the informational blog post


to move on to the product page as well


if they want to buy something.


And it might be that a lot of these people


are just looking for information and they're not looking to buy,


and then they might not follow that link.


But that's kind of something that's


almost a bit out of our control, I guess,


so what people are actually looking for.


With regards to maybe the competition that's


also appearing in search, I think


it's tricky to simplify it to just the number of words


on a page and the number of links that these articles have


because we use lots and lots of factors in search.


And it's something that sometimes just takes


a lot of time to be built up.


And sometimes it takes a lot of work


to build that relationship with your audience


to make it so that, I don't know,


they're happy to go back to your website,


that they also recommend your website, that it's not so much


like only the links that you placed


are visible for your website, but actually people


are buying things and they're reviewing things


on your website.


They're giving you information and they're


recommending your business, your products to other people.


And that sometimes just takes a lot of time.


So John, interlinking from a dedicated blog page


to that product itself and having a call to action


are implicitly different, right?


Different suggestions.


So by CTA, do you mean you could utilize something


graphical, a button?


Sure.


I mean, if people are going to your blog post


to find more information about this kind of product,


then it's either that these people have a different intent.


They just want to find information.


Or they need some simple way to actually be able to go off


and buy that product.


And sometimes that's something that you


can do with a graphical element.


It's not so much an SEO aspect that you're doing,


but more that, well, your pages have visibility.


And how do you convert that visibility into something


that you find valuable, that people go to a product page


and buy something?


OK.


Also, no, I kind of understand that.


So also, at the same time, speaking to the part


that you mentioned, that the most popular query for us,


for our business, would be green tea.


And every time we Google something like that,


we get a mix of search results.


Some are blogs around green teas.


And there are a couple of product pages and collection


pages.


And I have in focus those product and collection pages.


And that's what I am trying to complete in that very instance.


And they don't stand out to me as some page.


They don't even have as much content as we do.


But they are popular.


They are popular in the sense that they are a bigger website.


We know for a fact that people buy a lot of stuff


from these websites.


So could it be that it's with time


and with continued effort of whatever you mentioned,


it can get to that stage without anything


that is kind of coming across as a gap right now


in my strategy?


JOHN MUELLER-HUNTMANN I think it can.


But for a query like just green tea,


I suspect the competition is going to be very, very hard.


So that's something where you can make a very good page


about green tea.


But if the competition is just so hard,


you are almost never going to be visible.


And for instances like that, my recommendation


is usually to find more specific queries, more specific kind


of products, where you can stand out,


where there is less competition, which might be, I don't know,


some organic type of green tea or a special, I don't know,


shape or leaf type or I don't know.


I don't know the topic.


But something that is kind of unique where you can stand out.


And then you can start there and build up your visibility


until you're the most visible one for that very specific


type.


That type of query doesn't get enough comparable traffic


to just green tea, but it gets enough for your business.


And from there, you can kind of build out


and take the next more specific type of tea


and add that as well and kind of work


on expanding things like that.


So that's usually the direction I would recommend there.


Instead of trying to kind of, as a new company,


take on existing competition and go


into a very intense and competitive market,


find something small where you can stand out.


Actually, I'm using that strategy when it comes to the blog.


So we go for niche queries and we rank.


But I've also targeted very competitive queries


and we rank.


So sometimes we are ranking ahead of websites


like WebMD and Healthline about a benefit and loss query.


I just don't know what it is that I could do to push


my product pages higher.


So my product pages do get some visibility


like they're on the fifth and sixth page.


John, I'm sorry I'm eating into everybody's time here,


but I'm kind of lost here.


So do you also think that the number of reviews


that we are gathering over time will be a factor?


Or is that a direct or indirect ranking signal?


It's not something direct that we would take into account.


But if you're seeing that people are engaging with your product,


then usually that's a good sign.


And that means that other signals


might be built up over time.


OK.


OK, I'll try to assimilate that information.


Thank you so much, John.


Thank you.


Sure.


Good luck.


Cool.


Andrew.


Yeah, hello, John.


Hi.


Well, after it was announced that the page experience


update rolled out, one of our sites


lost 20% of organic traffic.


Coronavirals are not very bad.


They are in the orange zone.


Is it safe to suggest that the site will regain traffic


after we will fix the issues with Coronavirals?


And also, how long could it take?


Do we need to wait some maybe another huge update?


And how do things in general work


with Coronavirals and the algorithm


from this point of view?


So you saw the change immediately


after it was finished?


Or when did you see it?


Yes, after it was announced that the page experience update


rolled out, like it was completed.


OK.


I don't think that would be related.


So the reason I don't think that would be related


is because we started rolling this update out, I think,


in July, and it was finished at the end of August.


But the rollout, it was on a per-page basis, essentially.


That means if we saw that your website was


slow for Core Web Vitals, you would see a gradual change


over time, and from July until that.


Not the exact.


Exactly.


Yeah.


And if you see an exact drop on that date,


it seems like it's probably something else.


So I don't think that would be from the Core Web Vitals.


And also, the gain would be also gradually, right?


Yes.


And the updates take place automatically.


So it's something in Search Console,


you will see the data is always delayed, I think, 28 days.


But it's gradually updated.


It's not that it has to wait for a bigger update.


That's OK.


Thank you.


OK.


Cool.


Kamal.


Hi.


I have a question about the e-commerce website again.


We're going to create content space on the keyword


suggestions, auto-complete by Google,


to include more content around the one main topic.


For example, the main topic or transactional intent


is smartphones, and we're going to create


tech-related contents around the smartphone, like blog posts.


Should we really need to create separate contents


for separate keywords around one topic,


or is just combining all different keywords


in one intent and optimize our content around this intent?


You can do either way.


It's more of a strategic decision, I think.


In general, what you are balancing


is making pages that are specific for individual topics


and making pages that are more general,


but where you have fewer pages.


So you're kind of balancing many pages versus fewer pages.


And if you have fewer pages, generally, those few pages


tend to be a little bit stronger,


whereas if you have a lot of pages,


then the value is spread out a little bit more.


So if there are specific topics where the competition is


stronger, then you want to have very strong pages,


so maybe fewer pages.


If you are targeting areas where the competition is not


so strong, then maybe having more pages is fine.


So that's kind of the balance that you


would try to take there, where if you're starting out,


probably having fewer pages is a good idea


so that you can be as strong as possible in that area.


And then over time, as you see, like we're very good here,


you can split off individual pages for more niche topics.


OK, in that case, I'm going to create a few stronger pages


on intents.


And what should I do to make Google prefer the best


content for others to the main intent?


For example, I want Google to prefer some smart form


transactional intents to my stronger blog posts.


How can I handle it?


You can't give any priority for them,


but you can help with internal linking.


So within your website, you can really highlight the pages


that you want to have highlighted more


and make sure that they're really well linked internally.


And maybe the pages you don't find that important,


make sure that they're a little bit less well linked internally.


So I have to give some call to action button to smartphone,


for example, category page.


Right?


Yeah, I mean, it's something usually with internal linking,


you can think of it as the important pages you would have


linked from your home page and the less important pages


are linked from like a category or subcategory page,


something like that.


So that when we look at your site,


we see, oh, the home page is very important.


And the home page points at these five pages.


So these five pages are almost as important as the home page.


And then from there, the value is spread out.


And that's kind of the way that you


can help us to figure out which pages you think are important.


It doesn't mean we will always follow that,


but it's a good way to give that kind of information.


Should I give links on all these different keyword-related


blog posts?


How do you mean?


I've been giving a link to the smartphone page,


for example, product page, from that blog post.


All of them are important?


Sure, sure.


Should I use canonical URL to these blog posts?


Or is it important?


The canonical URL is important if you have multiple URLs that


show the same content.


So if you have tracking URLs, for example,


within your blog or something like that,


then with the canonical link element,


you can tell us what is the primary page there.


But for a normal website where you're just


linking to different things, usually you


wouldn't critically need it.


It's a good best practice to have,


but it's not that you're going to get any SEO


bonus out of it.


OK.


Thank you very much.


Cool.


All right.


Alejandro.


Hi, John.


Yes.


We are planning to release the Spanish version for the US


market.


And we already have a multi-language website


in around 92 countries and 70 languages.


However, when it comes about the US, there's google.com.


And we have a lot of traffic coming from brand keywords,


mostly.


That's the biggest amount of traffic.


And we have some concerns about the impact of this.


We have a comprehensive issue of land solution in the site maps


and also page language for each patient


we are going to release by the CMS.


However, we still have this kind of shyness


to go live scenes.


Probably the traffic to the brand keywords,


that is the majority, could be mess up in the search results.


Do you have any additional advice


that we should consider regarding this opening up


for the Spanish speaker in the US?


So are you seeing any issues at the moment?


Or is it more kind of with regards to future plans?


Yeah, I mean, also that some products,


and they even have any translation.


The brand name is the same.


So probably we will have some cases


that it shows up more traffic to the results to the English


than to Spanish or vice versa.


So our biggest concern is if we should


consider additional technical requirements


or maybe make some kind of variations


to the Spanish content to be sure that they position


by the sales with some other relevance


down in that content in English.


OK.


But do you have the Spanish content already?


Or is it?


No, it's planned to go live in October.


So I think the things that you mentioned, they sound great.


So that seems like a good approach.


One thing I would try to do, I don't


know if it's possible in your specific case,


would be to add a JavaScript-based banner


to these pages to try to recognize if the wrong user is


on the wrong version of the page.


So if that's something, I don't know if that's possible here.


But to recognize maybe the browser language or the user's


location with JavaScript, and if you


can tell that they're on the wrong version,


then show a little banner on top saying,


hey, we have a better version for you.


You can follow the link here.


Using a banner like that means that Google will still


be able to index all of these pages,


but you can guide users to the appropriate one


a little bit faster.


If you were to do it on the server side,


for example, with a redirect, then the problem


could be that Googlebot never sees the other version


because it always gets redirected.


And the banner is kind of like a backup plan,


where usually hreflang will help.


Maybe geotargeting is set up.


But the banner is kind of like, well,


we can't guarantee that only the right users go to these pages.


So we will catch them and then help


them to find the right ones.


Yeah, we already have implemented geotargeting


on the web browser.


So maybe from the web browser and the interface in Google


might change the results.


Yeah.


I would just assume that sometimes users


get to the wrong page because everything


around geotargeting and hreflang is sometimes


a bit flexible with regards to how we recognize it


and how users are set up.


So that's mostly why I would recommend


the banner as a backup.


But otherwise, I think you understand the topic,


and you probably have it set up so that it'll work.


Yeah, yeah.


Thank you for that site.


I just have an additional question.


It's more about Google Search Console.


And due to some kind of migration and legacy,


we cannot make forcing the URL rewriting from the URL


without training slash with training slash.


So we still have this duality, even though, well, the page


is canonical and all the text is OK.


But when it comes about Search Console,


I wanted to just to have a property, for example,


and mydomain.com slash SE, I sued them,


without the training slash.


But then since I already have a property in Search Console


with the training slash, it's forcing me just to use that one


and I cannot see or create a separate property.


Is it something that I should just remove all the properties


and go and scratch on zero to do this?


I don't think you can do that because without the trailing


slash, it's essentially, from our point of view,


it's a file that's on the root domain.


And with the trailing slash, then it's a folder,


and then you can add it as a property.


So you wouldn't be able to add just like slash


SE without a trailing slash.


OK.


Thank you very much for this information.


Cool.


Let me go through some of the submitted questions,


and I'll get back to the rest of you with your hands raised.


Oh my gosh, so many.


And a little bit later as well.


Let's see.


The first one is, we're a news publisher


and experiencing an issue where Google


shows the wrong publish date in the search results.


And it kind of goes with, we have everything


set up properly on the article.


We have x minutes ago or something


like that in the text.


What can we do there?


So when it comes to dates in the search results,


we try to find the date that essentially


aligns the best across all of the signals that we have.


And that means we look at things like the structured data, which


it sounds like you're already using,


to understand what the date might be.


But we also look at the page text.


And if we can't recognize that the same date and time is used


across multiple locations, then we


have to try to figure out which one of these


might be the most relevant.


And in particular, if you have something just like as a date,


like, I don't know, 10 minutes ago or five hours ago


or yesterday as a date in the visible part of the article,


then that's something we wouldn't


be able to kind of match because we don't really know exactly


what date you mean with that.


So that's something where if you can give us


the date and the time in a visible way in the article


together with the structured data,


then it's a lot more likely that we'll


be able to actually use that.


So that's kind of the recommendation


I would have here.


It's definitely not the case that we just blindly


ignore the structured data.


But we need to make sure that whatever we pick


is kind of supported by the rest of the page.


And it's important that you watch out


for things like time zones.


That's one that we often see where things go wrong.


Yeah, time zones, essentially.


And with regards to the visible date,


it's not so much that it needs to be an exact format,


but it should be something that we can recognize.


So those are kind of the directions


that I would look at there.


In recent weeks, we've seen a huge increase in direct spam


traffic on some of our websites coming from all over the world


using Chrome as a browser.


This spam traffic is very slow.


We're a bit concerned about Chrome metrics


that are used to evaluate page speed and rankings.


Is Google aware of this?


Is there something that we can do?


So I don't know.


We get lots of weird, or we see lots of weird spam traffic


on the web over time.


And we have a fairly good understanding of that.


And the way that I understand it with regards


to the Core Web Vitals, what we use for the, what is it,


in the Chrome experience, Chrome User Experience report data,


there are certain requirements that we watch out for.


And we almost certainly also filter out


for the usual spam traffic that's also out there as well.


So from that point of view, I wouldn't


expect this to cause any problems.


If you're really worried about it and you have some data


that you can send me, then I'm happy to pass that


on to the Chrome team so that they can take a look.


But I would not assume that this would cause any problems.


We see all kinds of weird spam traffic all the time.


And our systems are pretty tuned to avoid that kind of thing.


I manage one of the largest classified sites


in the country.


We have several category pages that


list only three to four products.


They're receiving traffic from search.


But I know that users won't be satisfied with our page.


I'm thinking in a line of no indexing such pages.


I know it might hurt traffic numbers.


But in the long run, users overall


might be more satisfied with our site.


What are your thoughts on this strategy?


I think ultimately that's more of a strategic decision,


I think, than a pure SEO one.


So that's something where I don't know.


It's kind of like the kind of thing where I'd say,


well, try it out and see what happens.


It's always tricky when you have pages that are currently


being shown in search.


And if you no index them or if you remove them,


then obviously those pages won't be shown in search anymore.


And then it's almost open, like, will Google


pick other pages from my website and show those instead?


And it's possible that we would be able to pick up other pages


and show them instead.


It might also happen that we just say, well,


we don't have anything good from this website.


We'll take other websites and show those instead.


And that's, I think, kind of the risk that you have to take.


And sometimes it's also a matter of letting it settle down.


So if you have a large website and you


want to kind of try this out and you feel very strongly


that users going through those pages


are going to have a bad experience,


then maybe take a section of your site


that gets sufficient traffic so that you can measure it


and try it out and see what happens.


My feeling overall is, like, it's


I suspect some will work, some won't work that well.


I would almost try it out.


I mean, there are other things that you could do here,


which might involve things like changing things in the UI


to make a call to action a little bit clearer.


So if you're already ranking like that and you know people


tend to want to go somewhere specific on your website


with those kind of queries, make it easier to get there.


And that might also be an option.


But it feels like something you'd almost need to test.


What's up with EAT?


Is that determined through quality backlinks


or more on the subject than thoroughness of the pages?


So EAT is an abbreviation for Expertise, Authority,


and Trustworthiness.


And it's something that comes from our quality rater


guidelines.


And the quality rater guidelines are not


kind of like a handbook to Google's algorithms,


but rather something that we give


folks who are reviewing changes that we make in our algorithms.


And especially EAT is specific to certain kinds of sites


and certain kinds of content.


So from that point of view, it's not something


where I would say Google has an EAT score


and it's based on five links plus this plus that.


It's more something that our algorithms over time,


we try to improve them.


Our quality raters try to review our algorithms


and they do look at these things.


So there might be some overlap here,


but it's not that there's a technical factor that's


involved which would kind of take specific elements


and use them as an SEO factor.


But it is definitely something I would look into, especially


if you're running sites that map into the broad area


where Google has mentioned EAT in the quality rater


guidelines.


An online pharmacy I work for is going


through a complete rebranding and raise


some interesting questions.


In terms of EAT, again, for a site operating


in different countries and languages,


is it better to get an English speaking clinician


with a lot of authority to review your content


and then translate it or get a local clinician with less


authority to do it?


I would not kind of base this decision purely on SEO aspects,


but rather I would try to figure out


like what would actually end up with better content


on your side.


So that's kind of the direction I would head here.


I don't think our algorithms are tuned


to kind of like trying to recognize


English speaking medical people rather than other languages,


but rather we try to figure out where


it makes sense to pull this information


and then to show it.


With regards to less authority and more authority,


I think on the one hand, you can't really quantify it.


So that's always tricky.


On the other hand, it's definitely also the case


that some markets are large and it's


important to be very strong there,


and some markets are just smaller where it's


obvious that there will be a difference compared


to the people who are interacting in a larger market.


Is Google better at understanding sarcasm in 2021


or should you still try to avoid it?


For example, the sentence, Seldon, oh, Phil, oh, gosh,


I can't pronounce it.


Some medical name works for jet lag.


If you're a hamster, is correct medically


because no study has been run on humans,


but is there a risk that it confuses Google semantically?


I would say there's definitely a risk that we misunderstand


things like that or that we don't understand when


there is sarcasm on a page.


And especially if it's something where it's really critical


for you to get the right message across to Google


and to all users, then I would make sure


that it's as clear as possible.


So maybe in cases where you're talking


about medical information, maybe try to avoid sarcasm.


If you're writing about, I don't know, an entertainment topic


or something like that, that's probably less of an issue.


But especially if it's really critical information,


then really make sure that it's as easy as possible


to understand.


My website is on non-dub-dub-dub,


which is ranked number one on Google, both pages and posts.


I want to switch it to non-dub-dub-dub to the dub.


Sorry.


I want to switch from the non-dub-dub-dub version


to the dub-dub-dub version.


What's the best way to do it without affecting SEO,


and is there any risk of changing


when you do that?


So the best way to do this is to follow the normal site move


guidelines that we have.


And essentially, everything is outlined there.


So with regards to tracking the URLs that you have previously


to the following through with the redirect


and making sure that all of that is set up properly,


I would follow those things.


My feeling is that overall, a move within the same domain


where you're just changing essentially


a different subdomain is something


that is fairly unproblematic and should happen essentially


fairly smoothly.


And if you set up the redirects properly,


if you're not blocking things in any specific way,


then I would imagine that this is something


that is processed within a week or so,


even for a medium-sized website.


It should be a fairly straightforward move,


just from one subdomain to another.


Moving between domains is a little bit trickier.


Moving or splitting or merging websites, that's a lot trickier.


But this move from one version to another version


is usually totally unproblematic.


And it's also something where, if it


were to take a little bit longer,


it doesn't change anything for the user


because they would click on the old link


and just end up on the new page.


And it would all just work.


So I think this is totally unproblematic and probably


something that's easily doable.


The main thing I would think about here,


though, is that this is always like a site move


kind of situation where you have a lot of work that's involved.


So I would kind of consider, what are you really


trying to do by moving like this?


What is the problem that you're trying to fix?


Because it might be that you do all of this stuff,


and essentially everything is the same in the end


if you get it right.


But if everything is the same in the end,


why do you even do it?


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


Yeah, and Michael just asked the same question as well.


It's kind of like, why would you do this?


I could imagine there might be situations


where you have a CDN where you need


to do that to have kind of a separate host name.


But if there's no strong technical reason to do it,


I would just keep it as is.


I have a question about local rankings.


So I don't know if I can help with local things.


Let's see.


My client had extremely good local pack presence


for important search term they target


until a couple of months ago when the rankings fell off


a cliff.


I noticed there was another Google My Business


listing for their business.


I feel you probably need to go to the Google My Business help


forum for that because I really don't have any insight


on the Google My Business side.


Nathan, I think you're here.


I am, yeah.


Thanks.


Yeah, I have been there and tried that.


It seems a very specific case, so I thought I'd try here too.


But if it's not your area, and I did wonder,


I'm not sure where that leaves me.


Now, I don't really have any insight or any connections


on the Google My Business side, so it's


something where I really can't help out that much.


But I think they also have some kind of live support


as well, either by chat or by phone.


So that might be an option to try there.


OK, thank you, John.


Sure.


Let's see.


You wanted to know whether the indexing or crawling is


impacted if there are captures presented to avoid scraping.


My website has strict capture policies


on these directory pages.


The whole purpose for these pages


is to make sure that the pages are crawled and indexed.


However, do the captures slow the process down?


So Googlebot doesn't fill out any captures.


Even if there are Google-based captures,


we don't fill them out.


So that's something where if the capture needs


to be completed in order for the content to be visible,


then we would not have access to the content.


If, on the other hand, the content


is available there without essentially needing


to do anything and the capture is just shown on top,


then usually that would be fine.


Now, what I would do to test is use, in Search Console,


the Inspect URL tool and fetch those pages


and see what comes back.


On the one hand, the Visible page


to make sure that matches the visible content and the HTML


that is rendered there to make sure


that that includes the content that you want to have indexed.


So that's the approach I would take there.


From a policy point of view, we're


OK with situations where you serve us the full content


and you require a capture on the user side.


So if you need to do that slightly differently


for Googlebot or maybe other search engines


than you would for the average user, from our point of view,


that's fine.


Can an author write an article on site A


and then write another article on the same topic on site B?


The content will not be duplicated and will be unique,


but the topic is the same.


Also, site A and site B are under the same company.


I don't see an issue with this.


So from Google's point of view, we


don't have any guidelines on where people can write


and what kind of content they can create.


So if people are creating content on multiple sites,


then go for it.


I think that's perfectly fine.


From a practical point of view, what I've seen,


I don't know if we have this in any guidelines or anything,


but what I've sometimes seen is people


tend to have a profile page for themselves, where they collect


all the information, all the things that they do.


And pointing to something like your author home page or profile


page or however you want to call that


is a good way to make sure that search engines understand


that this is all the same person,


to understand that this is a person with this name,


and they're writing here, they're writing here,


they're writing here, having that collection, that link


back to your home page or whatever you choose.


OK, I became muted.


OK, I, whoops, I have no idea when I became muted, but OK.


Let's see.


Maybe I'll go back a little bit and see how much


it was in the recording.


Yeah, so talking about profile.


So I think having a shared location for your author home


page, I think that makes sense.


It's not something that we have in our policies


and our guidelines that you must do that,


but it makes it a little bit easier for us to understand


this is all the same person.


So that's kind of the one thing I would watch out for.


But writing on multiple sites on the same topic,


on different topics, whatever, is totally up to you.


Definitely no limits from our side.


I manually submit links of each article after publishing,


and usually the pages get indexed within a few hours.


At most, it takes a day for indexing.


Currently, about 60 articles have been indexed this way.


However, on the 15th of September,


I published four articles with just the intro text


and submitted them for indexing, hoping


to update the articles the following day.


Since this day, those four articles, let's see,


plus any article posted afterwards


have not been indexed by Google.


Could the four articles posted with thin content


have triggered this?


No.


I don't think that would be related.


In general, the thing to watch out


for when publishing thin content is sometimes


it takes a little bit longer for us to recrawl the page


and to pick up the new version of the content there.


So I would try to avoid doing that on a regular basis.


But sometimes it happens that you update an article


and you expand it over time.


And we will try to pick that up over time.


With regards to four articles resulting in no new content


being picked up from that website,


I don't see that as something that would be related.


So from my point of view, I wouldn't


assume those four articles are the reason for Google


to be reluctant with indexing.


The one thing I did see in this question


is you're manually submitting all of the links


of every article after publishing.


From my point of view, that kind of points into the direction


that Google is already reluctant in picking up content


from your website.


And usually that reluctance comes


from us not being sure of the quality of the website


overall.


So that's something where those four articles are probably not


pulling down the overall quality of your website.


But maybe the overall picture that you have painted so far


is something that is making us a little bit nervous


and a little bit pickier.


And that is resulting in us maybe not indexing all content


as quickly as we could.


And usually what happens is if you


have really fantastic content, then we


will go off and crawl your website regularly


all the time.


You don't need to manually submit things


to make them indexable.


So that would be kind of my suggestion there,


to kind of take a step back and think about your website's


quality overall rather than to kind of fixate


on those four articles that were submitted that one time.


Does Google prefer micro-niche websites


over macro-niche websites?


I don't know exactly what you mean with micro-niche


and macro-niche.


My general recommendation is to make fewer websites


and make them stronger.


So I don't know if that's a macro-niche or something else.


But kind of the idea of making very small websites


on a very specific topic, I think that's OK.


But it means that these websites tend not


to be very strong overall.


Because you're not building value over time.


You're basically putting out this one tiny piece


of information on one website.


And then it takes a long time for us to figure out,


well, actually this website has good content overall.


Whereas if we had one very strong website


and you added another article to it, then we would say,


well, this website is really strong already.


And oh, look, there's something new.


We'll go and pick that up as quickly as possible


and show that as visibly as possible.


And then among all of the 200 ranking signals,


which are the most important?


I don't like to rank ranking signals.


So I can't give you an answer there.


And the other small thing there is


we've kind of moved away from the over 200 ranking signals


number because it feels like even having a number like that


is kind of misleading in the sense


that, oh, Google has a spreadsheet with all


of the ranking signals.


And they can just sort them by importance


and tell me which ones they are.


And that's definitely not the case.


But a lot of these things just take into account


so many different things.


You can't just isolate them out.


Cool.


OK.


Wow.


We're running low on time already.


So maybe I'll take some more live questions.


And we can extend a little bit afterwards as well


to make sure all of the live questions are kind of handled.


Let's see.


John, I think you were just raising your hand.


You're still here.


I'm good.


You answered my posted question.


Thank you.


Oh, cool.


All right.


That was fast.


Vincent.


Hi.


I've already answered one of my questions.


But I've got another one for you.


It's about EAT again.


Sorry about this.


So yeah, Google recommends that medical content


should be written by clinicians.


So for example, if you have a page related to acne,


does it make a difference if you get a top, top dermatologist


to someone who's got also profiles


on a lot of medical journals, who've got a knowledge graph,


who's got a reputation in the community,


these type of things?


Or if you get any general practitioner,


does it make any in terms of ranking an SEO?


Does it wait somehow?


Or as long as they are qualified doctor,


it doesn't really matter?


I don't know if there would be a quantifiable difference.


Because it's also not something where


we say it's a direct ranking factor, that we say,


oh, we look up the author and double-check this


and double-check that.


It's more something that kind of comes into play


when we look at the bigger picture of the content


of the website.


So my feeling is purely from an SEO point of view,


it probably doesn't matter either way.


From a long-term, being seen as an authority point of view,


maybe it does make sense to have a stronger author who's


associated with it.


But I don't think you would see an SEO ranking difference


if you picked this author or a different author.


OK, thank you.


Hi, hi.


Hi.


So my question is on Google for Jobs.


We have jobs on our job post on our website.


And once we added the structured data,


the job postings started to appear on Google for Jobs.


But we also have some remote jobs.


And when we looked at the queries in Search Console,


we found that about 95% of them had the word remote or work


from home or online.


So only the people who are looking specifically


for remote jobs were able to see our job posts.


So we feel like we're missing out on a lot,


especially because we have, in some cases,


some unique job titles.


So how do we overcome that and make it visible?


I don't know.


It's hard to say because I don't know the details of how


Google Jobs pulls this together.


But if you can give me some examples,


then I'm happy to pass that on to your team,


at least in the form of feedback, where maybe kind


of the things where you're seeing


that people are searching for a job in general


and the remote options are just not bubbling up,


those kind of things.


I think that would be useful for the team.


I don't know if we have any specific guidelines on what


you need to do there.


I know some things changed around the policies


of remote jobs for Google for Jobs,


but I don't know the specifics.


So if you want to kind of put something in the chat here,


feel free, or if you want to ping me on Twitter


and give me some information there, that's also fine.


Sure.


Cool.


Fethi.


Hello, John.


Hi.


My question will be also about indexing and the indexing


issues that we've come across lately.


We are running an international multi-language website.


And on Google Search Console lately, almost all of them,


we've come across this indexing issue.


Generally, it takes a while, but in the reports,


we see discovered but not indexed.


I tested some of them.


We made sure that we have internal links from homepage


on a number of articles.


When we search for the H1 of that article,


Google shows these articles or pages that has internal link.


In the cage version, it is visible.


You can see the link.


But when we submit it again, it still doesn't index.


It pushes to discovered but not indexed.


And finally, we had to share it on social media.


It didn't help.


And at the end, we have updated the content fully and published,


and it came back.


But it is happening lately too much since the beginning of,


say, after all this June, July core update season.


And another thing about indexing we came across


is that we published articles about some events, sports


events.


And Google, again, sees, either says not indexed


or discovered not indexed.


But when we search for part of this content,


we find that all the articles from 2018 related topic,


not exactly but similar, Google updated H1 description,


all the content.


But the link is old link, old URL.


And yeah, that's the question.


What can we do to solve this issue?


Or is it an issue, or is it some part of the update


that Google finds similar content


and tries to update to one link?


It's hard to tell from your question


if the content is actually indexed,


if it's just reported incorrectly in Search Console,


or if it's actually not indexed.


There are cases.


In one case, it's not indexed by Google.


It is possible to see the index being.


It is possible to see the encores


that we have internal links.


It is possible to see the links in those internal links.


But content is definitely not indexed.


OK.


Offhand, I mean, I don't know your website.


I don't know how much content it is there.


But it sounds like it's a lot of content.


And offhand, what tends to happen


is if we're not really sure about the quality


of the website, then we might just not crawl and index


all of the content.


And then it can happen that you publish new things,


and we understand that they exist.


We discover them.


But we end up not indexing them because we're not


100% sure how much content we need to have indexed


from this website.


And usually, the main approach to try to solve this


is to try to find ways to increase the quality


of the content overall.


Sometimes that means removing some old things


and making sure that everything that you publish


is really fantastic.


That's, I think, the ideal situation


to help in this direction because if our systems are


convinced of the quality of your website,


they will crawl and index more.


And it will try to pick up things as quickly as possible.


Whereas if they're not 100% sure, then sometimes it works.


Sometimes it doesn't work.


It sounds a little bit like what you're seeing here.


What you could also do in the meantime,


perhaps, is if you have content that's


replaced by new content that you provide,


to set up redirects from the old versions to the new ones


so that if we should crawl the old pages,


then we automatically get the new ones.


And if users are already redirected,


all the old related content, our articles, URLs,


are redirected to the latest one.


But the latest URL is not indexed.


One of the old ones is indexed and stays indexed.


But content, title, description, everything changes.


Oh, OK.


So in that case, we probably have indexed the new version,


but we use the old URL.


And that's something that happens


with canonicalization.


So with the canonicalization process,


we understand there are multiple URLs on your website that


show the same content, like the old one and the new one.


The old one redirects to the new one,


so it's definitely the same content.


And we try to figure out which of these URLs


to show in the search results.


And that's something that we do use redirects for that.


We also use internal links, external links, sitemap files,


hreflang, all kinds of structured data annotations.


All of these links that we find, we


try to combine that and say, so many apply to the old version,


so many apply to the new one.


We will pick whichever one has the most points, essentially.


And that's something where I suspect


we're indexing the new one, we're just using the old URL.


From a ranking point of view, it would rank exactly the same


way.


It's just the old URL that's being used


OK, thank you very much.


Cool.


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


and I'll get to the rest of you after we pause.


Don't worry.


If you're watching this on YouTube,


thanks for sticking around so long to the end.


If you'd like to join us live with one of the next Hangouts,


feel free to jump on in.


I'll post the links in the community section afterwards.


And yeah, hope to see you all again in the future.


JSON-LD Structured Data: Where to Insert in a Page? #AskGoogleWebmasters

Today, we have a question from Virginie, who's asking,


is it possible to insert JSON structured data


at the bottom of the body instead of the head?


It seems to work fine for many websites.


Thank you for your question, Virginie.


JSON-LD is one of the ways that Google can process structured


data on a web page.


The other supported formats are Microdata and RDFa.


RDFa is an HTML5 extension that supports linked data


through additional attributes added to existing HTML tags


on the page.


Microdata is an open community HTML specification