And I can find the links of the portal site


English Google SEO office-hours from May 7, 2021

in the time linking site in Search Console


for the destination domains.


So what I think is that the Waypoint URLs deliver


most of the linkages to the destination URLs.


Am I thinking right?


I don't know.


I feel I need to take a look at how you have it set up


before I can really say if that's kind of a good way


to do that or not.


So if you have some examples maybe


that you can drop into the comments.


I can show it to you now, if you may.


OK.


I have the Yahoo Japan site.


And in here, there are kind of article lists


of kind of Waypoint URLs that has three or two redirect


URLs instead of our final destination URLs.


And their destination URLs are like this.


They're like jp.abc.com.


And the Waypoint URL is kind of abc.kr, things like that.


Now, I don't know.


I feel I'd almost need to double check the details there.


So if you could maybe drop me some sample URLs here


in the chat, then I can take a look at that afterwards.


I don't want to kind of make a quick judgment call based


on just hearing it like that, because it sounds


like a little bit more complicated.


And second is that if, OK.


And thirdly is that, lastly, should we


register the Waypoint URLs to check out what's


going on in the search console?


I would always do that.


Yeah.


So if you're using multiple domains


in the configuration of your website,


even if they redirect somewhere else,


I would try to get those verified in Search Console


so that you have error information for those URLs.


OK.


Thank you.


And I've got the URLs of the sample URL in the chat.


Perfect.


Sounds good.


All right.


Barry, I think you're next.


Hey, how are you?


So I had a question about Steve, the search engine.


So in your Google Podcast search off the record,


you said you pretty much used that


as a way of talking about some ranking signals,


because you don't like talking about Google ranking signals.


And one of the things I felt was interesting


was that you didn't mention anything


about machine learning changing the weights of those ranking


signals.


I found that very interesting, because I'd obviously


been very into saying, yeah, we have lots of ranking signals,


but we don't know what the weights are at any moment,


because machine learning and AI changes that on the fly based


on tons of factors.


Does Google do a lot of that, or it


depends on the specific ranking factor of signal?


I think it depends is probably the right answer.


It's something where for some signals,


I know that we do a lot of machine learning


to try to figure out how we should integrate them.


And for others, we don't use that much.


And it also depends a little bit on the specifics


of what we're trying to figure out, in the sense of,


do we have a clear metric that we could base this machine


learning system on?


Or are we doing something like, I don't know,


training the machine learning system on clicks,


and then it just finds the most clickbaity titles


that we can show and uses those in search,


where you kind of have to watch out for things like that.


So that's something where for some elements,


we definitely use machine learning.


For other elements, we don't use it as much.


So can I ask specifically about what


is HTTPS seems like it's not, at least Steve,


not using it, using machine learning to adjust the weights.


And it seems like the page experience update currently


won't launch that way, or you don't want to say what Steve


would be able to do.


I don't know.


I mean, the different weightings of different parts


of the algorithms is something that is pretty tricky to do,


because you can't just manually say, oh, this is weighted 10%,


and then suddenly everything else is 10% less overall.


It's like you kind of need to watch out for the whole system.


And so I could imagine some parts of that are things


that we evaluate with machine learning.


Maybe we use the values directly from machine learning.


Maybe we adjust them manually.


Maybe we just start with something manual


and then see how it goes.


I honestly don't know.


Thank you.


Sure.


Rahul, I don't see you here offhand,


or you're at least still muted.


I can't hear you.


Can you hear me now?


Yes, perfect.


Hello, John.


Hi.


I own a site.


It was ranking good before 23rd of March.


I upgraded from USTECO Premium from free to premium.


After that, the site got de-indexed from Google,


and we lost all our keywords.


We tried everything to solve the issue.


We checked our robot TXT file, site maps.


We even used the URL removal tool server,


and there was a form specific for de-indexing.


We even tried that.


We also checked, was there any manual penalty or action


from Google?


Then we could not find a purpose to the site.


For the past few days, the site has been indexing


and de-indexing.


The keywords do come back for a few hours.


Then they get vanished from the Google search results again.


What can we do, or how can we troubleshoot this problem?


I don't know.


It sounds kind of tricky.


I would say offhand, it probably doesn't


have to do with the updating of your plugins,


but it could very well be a technical issue somewhere.


Because usually, when we reduce the indexing of a site,


when we say it's like we don't need to have as many URLs


indexed from a website, we tend to keep the ones, the URLs,


that are more relevant for that site.


And that tends to be something that happens over,


I don't know, a longer period of time, where it slowly


changes the indexing.


So if you're seeing something where the whole site disappears


from indexing, it almost sounds like something


that might be related to a technical issue, something


along those lines.


What I would recommend doing there


is going to the Webmaster Help Forum


and posting the details of what you're seeing,


the exact URLs that you're seeing,


the queries that you're doing, so that others in the forum


can take a look and give you some tips.


Maybe there's some things that you can do or double check


to figure out, is it a technical issue?


Is it a quality issue?


Is it a spam issue, maybe?


Maybe the website is hacked.


It's really hard to say.


But the folks in the forum have a little bit of experience


with these kind of topics, and they can


help you to narrow that down.


Could it be a conflict of plugins


with the theme for the Google Search Console?


How do you mean?


Could there be a conflict of plugins within the site that


could result in?


It's theoretically possible.


So I've seen situations where a plugin shows a no index


and another one shows normal that the page should be indexed.


That can happen if you have too many conflicting plugins


installed.


But it's something, again, the folks in the Help Forum,


they've seen these kind of issues.


And they can tell you pretty quickly, oh, it's


like this plugin or that plugin.


Thank you.


Sure.


Andrei.


Hi, John.


Can you hear me well?


Yes.


Great.


So it's my first Webmaster Hours.


I've been trying to get in, but every time something happens.


But my question now is really serious,


because we just today, this morning,


we received a security warning from Google Search Console that


is on all of the subdomains.


We have like 400 subdomains.


And all of them are showing security warning,


like harmful downloads.


And when we actually checked all of the subdomains on Google,


none of them are showing harmful content.


The only place where it's shown is the root domain.


So we ran out of all of the possible scenarios


what could cause it.


And we're lacking some ideas what


we can investigate with our infrastructure team


to actually get kivy.com back to green zone.


OK.


And what kind of warning are you seeing?


Harmful downloads.


And no URLs are shown.


No details, like zero details.


It's like looking for a needle in the high stack.


And it's in Search Console, or do you see that in the browser?


Google Search Console.


Only in Google Search Console, and it's just


showing only for root domain.


And no subdomains, when we check every single individual


subdomain on the other tools, it's just no warnings.


Like a security issue report or on some other place,


like nowhere.


Is it the uncommon downloads message?


Is it just that?


Just harmful downloads and no details.


OK.


So I'm not exactly sure about that particular message.


But in general, with these kind of things,


what you can always do is request a review.


And usually what happens is the site


is then reviewed by someone manually.


And if there are any active issues found,


then you'll be informed of the specifics.


Thanks.


So we should probably go ahead and submit the request review


after we've done and run out of ideas.


And then we'll wait for this to be done.


Thank you very much.


I hope it will work.


Yeah.


Good luck.


If it doesn't work, if it tends to take too long,


let me know on Twitter.


Then I can double check with the team here manually.


Thank you.


Sure.


Oh, by the way, one more follow-up question.


Can this security warning be causing,


let's say, heavy traffic drop or any sort


of loss of organic traffic?


It shouldn't.


So usually that would only affect


if people are trying to download something from your site,


that they might see that warning in the download


section in the browser.


But it wouldn't be affecting the rankings or the visibility


in search.


OK.


Perfect.


Thank you so much.


All right, Olga.


Hi, John.


So I have a question about affiliate links.


So in the case of WordPress sites,


there are many plugins that kind of let you automatically


manage and track affiliate links all in one place.


And they usually work similarly in that they create


a new URL on your site.


It's kind of a friendly URL, which is then


three or two redirected to the actual affiliate link.


And so when you are adding those links on your site,


it looks like you are adding kind of internal links, right?


And those internal links usually have real nofollow tag on them.


So that's, yeah, we are kind of saying to Google


that we don't want them to be followed.


But yeah, we know that it is only a hint.


But when users are kind of reading the article


and they hover over this link, it


looks like an internal link.


But when they click, they go to the affiliate site.


And my question is, would Google consider this setup


as kind of a form of cloaking?


Or is it totally OK to have it this way?


That sounds totally fine.


Yeah.


OK.


Oh, I think the important part for affiliate links


is that there's a nofollow attached


or that we can't crawl through the links.


So if you have a nofollow or if that kind of that


bounce URL that you have on your site is blocked by robots.txt,


then essentially you have everything right.


And it doesn't matter for us so much


that when a user clicks on it, they get


redirected to the other site.


And the link initially looks like a link to your site.


That's totally irrelevant for us.


It's just we don't want to be passing PageRank


to the other site.


That's a relief.


Thank you.


Sure.


All right.


Akash.


Hi, John.


Hi.


My question is regarding the Go web battles and the AMP URLs.


OK.


So AMP URLs are basically like something you have abc.com


and then you have your own URL.


But when a user searches on Google search,


it shows googlecache.amp and then the rest of the URL.


So I should consider my URLs as a base page tool


to check what the score is all about or should the AMP cache.


Because what Google is going to consider


is what users are actually looking at the URLs


or what is actually the my URL.


So this is my first question.


And OK.


Yeah.


So we would take into account what users actually see.


And that means if your AMP pages are valid AMP pages


and we're showing them through the AMP cache,


then that's what we will take into account.


Of course, if users navigate within your website


and they go to, I don't know, your traditional web version


or your locally hosted AMP pages,


then those would be taken into account there.


OK.


And in case of signed exchanges, if suppose


we implement that technology where the URLs are


being published by the publisher's original domain,


so again, that AMP cache will be considered


or then my initial publisher will be considered


as what the page was at the score?


Whatever users see.


So my understanding is with signed exchanges,


you would essentially be on the AMP cache


but with your URL shown in the browser.


So from that point of view, it's kind of the same thing


as before.


Sure, sir.


Thank you so much.


Thank you.


Sure.


All right.


Rahul.


Hi, John.


Hi.


So basically, my Google Search Console


is not showing page experience report.


So what can be the reason?


Probably the reason there is that we don't have


much data for your website.


And that is basically based on how


we collect the data for the Core Web Vitals


report, which goes through the Chrome User Experience data.


And if we don't have a lot of data for your website,


then we wouldn't be able to show anything there.


So my recommendation there would be


to just manually test your pages and see that everything is OK


and mostly build off of that.


OK, couple of more questions.


I have a scenario like we have site A and site B.


Social traffic is coming on site A,


and the site, that particular page on site A


is linking to site B. So if some of the traffic


is going to site B from that particular link,


so how will Google take into consideration?


Like is it organic traffic, or will it


consider as social traffic, referral traffic?


I don't think we would differentiate there.


I mean, for search, we don't use traffic anyway


as a ranking factor.


For the Core Web Vitals, we don't really


care where the traffic is coming from.


If we have data to those URLs, then we


can show that in the Core Web Vitals report.


It doesn't matter if that's from social, from paid campaigns,


or from organic campaigns, or bookmarks, or whatever.


OK, one more question.


Can you talk a bit about topic clusters, brand mentions,


and social signals as a ranking factor?


Oh, wow, I don't really have much to say about all of that.


That feels like something super vague.


And I mean, from my point of view,


the main thing I would watch out for is that you really have,


I don't know, essentially a good website that focuses on topics


that you know a lot about, and where


you're able to show your knowledge and your experience


and make it clear what you're working on.


And all of that kind of maps to things


like topic clusters and brand mentions and all of that.


But from a practical point of view,


especially if you're going from a situation


where your website doesn't have a lot of data


yet because there are not a lot of users yet,


I would work on just growing your website organically


and making it better and better and stronger over time.


And then at some point, you can figure out


which topic clusters you want to build out,


or which topic areas, or what kind of experts


you want to have on your site.


OK, thank you so much.


Sure.


Michael.


Good morning.


I was going to ask you about international and duplicate


content, but you already answered that on Twitter


yesterday.


And Barry posted about it this morning, so thank you both.


My question, the other major question


I have on this new site that I'm working on


is it's a fairly large site.


It's a fairly well-known company that's performing well,


but the traffic year over year over year


is flat from organic search.


I think the biggest culprit is the fact


that there's pervasive use of JavaScript.


The mega menu main navigation is all in JavaScript.


Major sections of the site, like the blog and press release


and other sections, are all built with JavaScript


and not crawlable.


I just wanted your opinion on how much that is hurting us


versus, say, like WebCore vitals, which is we fail


a lot of those tests right now.


But we're working hard to fix that,


but should we instead be focusing


on making the site crawlable?


Yeah, I think that's always kind of hard to judge


without looking at the details.


And it's definitely not the case that just using JavaScript


and having content kind of pulled in with JavaScript


is automatically bad.


So I wouldn't take it as like, oh, we use JavaScript,


therefore we need to fix that for SEO reasons.


But rather, you kind of need to look at the details there


of what exactly is happening and kind of need to figure out,


is it a problem that Google really can't see the navigation?


And if so, that's something that you can kind of attack.


Is it a problem that the content actually


isn't visible to Google because the JavaScript is too complex


or does something kind of unexpected?


And that's something worth fixing.


But these are individual items that you


can kind of test from a technical point of view.


And you can use the URL inspection tool, for example,


to test the URLs and then look at the HTML


to see if the links are there for the navigation.


You can look at the HTML there also


to see if the content is actually there.


And if all of these things are OK,


then from a technical point of view,


we can crawl and index the content.


And then it's more a question of,


what can we do to kind of optimize that?


And at that point, it's less a matter of,


is it using JavaScript or not?


But rather, maybe we have a complex navigation internally,


and we could simplify that and make it easier for Google


to find the parts of the site that we think are important.


And that's something you could do with JavaScript.


That's something you could do with a different kind


of navigation.


That's kind of the, I'd say, the normal SEO work then.


But that's kind of, I think, the first thing


I would try to figure out is, is there a technical issue


or not?


And if there is a technical issue,


then obviously I try to prioritize


that over kind of optimizations like Core Web Vitals.


OK.


Yeah, we did an Ahrefs site audit,


and it says over half of our site is orphan pages.


So I assume that meant not crawlable.


I'd be kind of careful with just taking a testing tool


and kind of blindly trusting the results.


I'd really try to dig in at specifics


and double check what Google is actually seeing.


Thank you very much.


Sure.


All right.


Mohammed.


Hi, John.


How have you been?


Hi.


Actually, before asking a question,


I just want to put a situation here.


Let's say I have a parent company called example.com,


which caters e-commerce internet marketing services.


And we have subsidiary of that, let's say, test.example.com,


which delivers mobile app-related services.


But we have hosted blogs for both on the main domain,


that is example.com.


So I here just want to know, in this case,


what would be the best possible practices


to enhance the visibility and boost the rankings for the product


pages, not for the blogs, which are hosted on the subdomain,


or we can say, subsidiary company?


I don't know.


It's hard to say just based off of that.


But it sounds like what you want to look into


is essentially the internal navigation of your site.


How can you make it so that Google can recognize


that the parts that you care about of the website


are also the parts that Google ends up caring about?


And sometimes that's a matter of,


like if you have an e-commerce site, taking the products


that you really care about and linking to them from the home


page, so that when Google looks at the home page


of your website and says, oh, this home page is probably


the most important part of the site,


it links out to these individual products directly.


So we can assume that those are very important products


for your website.


And that's kind of the way that you'd


end up kind of growing your site a little bit organically


and making it so that the products that you care about


are seen a little bit more visibly.


The thing that you can't do is just say,


oh, I want everything to be seen as more important


within my website, because you have essentially a mass of,


I don't know, I call it importance for your website.


And we have to find out on which of the pages


within your website we should distribute that to.


And if you say it's like everything


is just as important as everything else,


then we can't recognize which parts are actually


critical for your website or which parts you care about,


which could be products where you make the most money off of


or the products where you're best known for


or where you're kind of proud to offer them


or where the competition is really strong,


those kind of things.


Should we host our blocks of subdomain at our subdomain


also?


Is it fine to host them on the main domain?


Totally up to you.


From our point of view, it doesn't matter.


I would consider what is easier for you to do,


what is easier for you to track and to measure.


Sometimes the subdomain is easier.


Sometimes the same domain is easier.


OK.


Thank you.


Sure.


All right.


GK.


Hi, John.


Hi.


If I add three not one redirection for more than one


key URL at the same time, if it is affect SEO rankings?


Can you repeat that once more?


Sorry.


key URL at the same time, if it affects SEO rankings?


OK, so if you add a lot of redirects to your site?


Yes.


Yeah, that's totally fine.


That's completely normal in the case


where you do a rebrand or kind of a redesign of your website.


You have to move a lot of URLs from one part to another.


And the number of redirects that you do


is totally irrelevant.


OK, thank you.


What is the reason of sudden traffic loss


in a specific country only when other country traffic is


usual?


I don't know.


It's super tricky.


Sometimes traffic just or the visibility in search


just goes away.


Sometimes it's specific to individual countries


where maybe the situation has changed in that country,


the competitive environment has changed,


or where maybe our algorithms think


that your website is not as relevant


in that particular country.


All of these things can happen.


Thank you.


I have something to add on the redirect side.


So I just got a random phone call a couple of days


ago from a large e-commerce site from their SEO team.


And they're like, we need your help.


Our development team wants to make five redirects


over the course of a year.


So every single URL on their site would redirect.


Like on day, let's say tomorrow, be one redirect,


and then one from now, another redirect,


because they want to change how the structure works slowly.


I'm like, you could tell them I said it's called SEO suicide.


Yeah.


Yeah, that's definitely something


worth mentioning in the sense that if you do restructure


your site, try to restructure it in the way


that you move to the final destination


as quickly as possible.


And not kind of like the situation


that Barry mentioned, where it's like you kind of move here,


and then here, and then here.


Because every redirect step that you take,


it takes a while to be processed.


And you will see fluctuations in search when that happens.


So if you take everything and you do it once,


then it's like you have it all done with.


Whereas if you do everything once a month,


then like every month you have that time of things


trying to be settled down and figured out.


I did ask them to take a photo of the SEO team beforehand.


And then after it's all done, so I can see their character,


right?


Oh, man.


So mean.


Cool.


OK.


Pavel.


Hello.


My question is something that you replied to on Twitter


a few days ago.


So you said that a page may be experiencing some issues


because it's not considered to be


in a stable state of indexing.


What are some of the factors that may affect that?


I'm trying to remember back what the situation there was.


I think, as far as I recall, what was happening there


was that things were just essentially settling down


in the sense that if, for example, you put a page up


for the first time, then it takes a bit of time for Google


to find that page, to get it indexed properly.


And depending on the current situation within Google's data


centers, it can happen that we index it in one data center


and it's not quite available in the other data centers yet.


And that's more the organic fluctuations


of how things are processed.


And it's less something where there's


a technical issue on your side that makes it hard for us


to pick up.


Cool.


Oh, gosh.


Nizana.


Yes, that's right.


That's me.


Hi.


Thank you.


So my question, I have actually two questions


regarding one website that is Switzerland's classified


website.


And we were actually wanting to do some changes on our home


page due to page performances because we are actually


rendering everything server side.


And we have some JavaScript around it


that takes a little bit of time to render.


And we think that it can be helpful for the page


performance if we do it otherwise.


So we do have a menu, then we have a banner,


and then we have a few listings on the home page


that are just the most recent listings or something


like that.


So we were actually thinking of maybe removing that


from the server side on the mobile view


and actually waiting for the user to do some action,


like scroll down for it to render


or to appear on the website.


And the other solution is maybe to just render it anyway


after some time, few seconds of inactivity.


So I was just wondering, is it OK?


It's not the essential part of the home page, though,


but is it user-bought friend?


Not user, obviously.


Bought friendly, how would you approach it?


And OK, so the second question will follow.


Yeah, I think the first thing you


have to decide is if you need to have that content indexed


or not.


And it sounds like you don't necessarily need it.


It would be nice but not critical.


Is that correct?


Yes, yes.


Yeah.


So if it's a matter of it would be nice to have indexed


but not critical, then I wouldn't worry too much


about it because it's possible that we'll be able to pick it


up, and it's possible that we'll miss it.


It's not something where I would say


we would penalize a website for doing something like this.


It's just for technical reasons, we might have it


or we might not have it indexed.


The way that we usually recommend doing something


like this is essentially the lazy loading setup would


be to use Intersection Observer, which is a Chrome API,


or I guess like a general browser API, that essentially


lets you know which parts of a page are visible at the moment.


And Googlebot uses that when we render the page,


and we render the page in a way that we


take a very long viewport, like a really long monitor,


and we try to load the page.


And then we tell the page, this is your viewport, this tall.


And then we give the page time to load the content that


would be visible there.


So essentially, with that setup, if you


recognize that this part of the content is visible


and you show it, then we'd be able to index that.


That's kind of the more guaranteed way of doing that.


The other ways where we have to watch out for a scroll event


or for someone to click a Load More button, something


like that, that's usually something


that Googlebot tends not to do.


So in particular, we don't know which elements to click on


to see if something would load.


So that's something where probably we would not


be able to pick up that content.


But if you use Intersection Observer,


probably we would be able to.


AUDIENCE 1 OK, so tends not to do means probably won't


be able to do it, but not 100% sure it won't be able to do it.


Yeah, no, it's something like these extra, I don't know,


I see them as extra functionality


are things which cost time when we do them


in rendering at scale, like if we have billions of pages


to do.


And our systems try to optimize the time that they need.


And through that, it's something like clicking on elements


and scrolling are things that are sometimes


done when we have enough resources on the side


to do that, but they're not something


we would consider as kind of the baseline indexing.


OK, thank you.


And the second question also regarding this website


is that we have a home page on.ch,


and then we have, of course, the three lingual version of slash


D, slash FR, and slash IT.


So for German, Italian, and French.


And actually, the home page as German


being like the default language for Switzerland, let's say,


is pretty much the similar as the slash D version.


And I have put the canonical to it,


but Google doesn't seem to pick it up.


It doesn't seem to agree with me and thinks


that it actually should be self-canonical on the slash D.


So I was just wondering, for now, the home page


is as the slash D version, so I don't


want to have any kind of trouble with that.


I was thinking whether it's OK for now, or how can I?


Is there any way that I can correct


this in terms of the canonical or any other?


Now, I think that would probably be fine to keep like this.


It's the thing that tends to happen here


is we would see that the content is the same, or mostly


the same, and then we would try to revert


based on the other signals that we have from the site, which


includes things like internal links within the website,


external links.


We also try to figure out which URLs look nicer, usually


the shorter ones.


We use your sitemap file, hreflang links,


all of those places where we pick up links


and try to figure out which of these URLs


is the better one to show.


And I think in this situation, probably both of them


would be OK for indexing.


If you wanted to change that, you'd


almost need to figure out where are all the places where


the slash de URL is mentioned, and can I


change it to the other one.


Or just change the whole structure of homepage


and remove the canonical to the like.


Yeah.


I think what would happen then is we'd index both of them


separately.


They are both indexed now, so that's the issue.


So even though we have a canonical and slash de,


it gets indexed and picked up and doesn't


getting recognized by Google as a canonical to the homepage.


So my main point was like, is it harmful?


I haven't seen anything going on with that.


I just wanted to make sure.


Yeah, I don't think it would be harmful.


I think it feels like something where you could probably


optimize that, and maybe it makes things


like tracking better or all of that,


but it's not like a super critical thing.


OK.


Thank you very much.


Sure.


Let me skip to some of the YouTube questions in between,


just to make sure we don't lose track of them completely.


And I'll have more time for all of your questions as well.


It looks like endless number of questions today.


Fantastic.


Cool.


I have a site where 1.2 pages are indexed.


When I look at Core Web Vitals, especially for desktop,


it shows zero URLs.


What might be the reason for that?


I think we touched on that earlier as well,


in that for Core Web Vitals, we use the Chrome User Experience


Report data, which is based on real user metrics.


And essentially, what that means is


we just don't have enough data for your site


or for the pages on your site.


So that's something where, as your site grows in popularity


and has more users that end up going there,


we'd be able to pick up some data from that


and be able to use that for the Core Web Vitals report.


In the meantime, I would recommend


using the manual testing tools for Core Web Vitals, which


is, for example, the Lighthouse report.


In Chrome, you can look at the Core Web Vitals.


Also, in PageSpeed Insights is a really nice way


to look at the Core Web Vitals.


And there's also webpagetest.org,


which is a cool way to look at things there.


When testing a site, I'd recommend


checking a few pages from each kind of template that you have.


So you don't need to check all 1.2 pages,


but maybe your home page, a category page,


and one of the detail pages.


And then based on that, you have a little bit


of an idea of how things are standing.


Can a small amount of English language text


on a non-English language page negatively affect its ranking?


Usually not.


So usually what would happen here is we,


like, depending on the amount of text,


we would recognize that there are


multiple languages on a page.


And what might happen is that we show that link that, like,


there's something on here in another language,


and would you like to have it translated?


But essentially, that's not a ranking issue.


It's more kind of a bit of a usability,


maybe a bit confusing for users in some cases.


And from what I've seen recently,


it's not the case that this would trigger just


for a handful of English or kind of different language


words on a page, but really, if there's


a significant amount of different language


content on a page.


We're updating our international strategy


and consolidating markets to a folder structure.


There will be cases when the content will


change based on the IP.


Currency content will be slightly modified,


particularly if a feature is not available in that market.


When crawlers will be fetching the page,


they may be getting slightly different versions of the page


depending where they originate the crawl request from.


Will this cause instability if the page is slightly


different with every crawl?


What do you think of this strategy?


So what will happen here from a practical point of view


is we will crawl your website from one location.


And usually, that one location is somewhere in the US.


So it's not the case that we would


look from different locations to see


if there's different content.


We would just crawl from our primary data center


for your site and index the content that we see there.


So we would not even recognize that there's


something different there.


That also means if users in the US,


if we're crawling your site from the US,


are not able to see your content,


then we would not be able to index that content.


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


If, on the other hand, for example, users in Switzerland


just aren't able to see your content,


then I might be kind of upset.


But Google would still index everything


because Google is crawling from the US


and it doesn't even know that someone in another country


might be seeing different content.


And the same applies to your currencies


as well, where if you're using the same URLs


and showing different currency, then we


would only see the currency based


on where we would crawl from.


So that might be the case.


Maybe we would only see US dollar prices


for your site, which might be OK for you.


It might be something where you say, well,


I want my local prices indexed as well.


If you do want local versions indexed,


you need to have separate URLs for the local versions.


So for the currencies, maybe different URL parameters


or whatever you want to do.


Also for the individual products,


essentially it would need to be different URLs so that we


can index them individually.


And they would need to be accessible to at least


to Googlebot when we crawl.


So if we crawl from the US and we access your Swiss page,


for example, you need to let users


see the Swiss version of your page


so that it can be indexed as well.


So all of that is kind of to say it's not


quite as simple as just adding kind of IP detection


and changing the prices on the fly.


You really kind of need to think about what your strategy is


going to be when it comes to an international site in search.


Since April 13, some of my blog pages


have been de-indexed gradually.


The site is about nine months old.


How and why does this happen?


I don't know what is exactly happening with your website


here.


In some cases, it might be that they're technical issues.


If this is happening gradually, then that


sounds a bit like technical issues.


That might be something that you'd


be able to see in Search Console,


depending on the type of issue there.


The other thing is that our index is limited.


We can't just index everything on the internet all the time.


We kind of have to pick and choose the content


that we want to have indexed.


And it can happen that a site is indexed more at some point,


because we think it's great content.


And then at some point, maybe we think, well,


maybe the content isn't that great.


And we indexed less of the site overall.


So these kind of fluctuations are totally common.


If you look at any bigger website in Search Console


in the indexing report, you will always


see things going up and down.


That's kind of just a part of the way that our systems work.


So from that point of view, it's not


something where I'd be able to point at something


specific for the most part.


My recommendation there is, if you really


are kind of lost with regards to why are things being indexed


the way they are, is go to the Help Forum and post the specifics.


So your site, some of the queries that you expect,


some of the pages that you see go away,


so that others can take a look there and give you


some tips on what you might be missing.


All right, let's see.


Would you mind to advise if our structure could


be seen as cloaking by using the reverse proxy with CSR and SSR


web apps for dynamic rendering?


So I took a quick look at the screenshot


that you included in the question.


And it looks offhand like you essentially have two versions


of your site running.


One is kind of the client-side rendered version that users see,


and one is a server-side rendered version


that Googlebot and other bots see.


And in general, that's OK.


That's kind of like how you mentioned it there.


It's dynamic rendering.


We don't recommend doing that anymore.


It's something you can do, but it's not recommended anymore.


The main reason we don't recommend it anymore


is that it's very easy to mess up


and to have Googlebot index something that is not


what your users actually see.


And usually, it happens in a way that Googlebot sees errors,


and your users see normal content,


and you don't even recognize that there are errors


being shown to Googlebot.


And that's kind of the thing to watch out for.


So overall, you could be doing something like this.


I would just be very careful when


you're doing this, especially with the server-side rendering


of something slightly different.


The other thing I noticed in your screenshot


is that you also routed Lighthouse and PageSpeed


Insights to your server-side rendered version, which


from my point of view doesn't make much sense,


because these tests are meant to give you


information on the speed and usability of your website.


It's not that the tests need to see a perfect result,


but rather, you need to find the errors


and improve on them for your users.


We also don't use Lighthouse and PageSpeed Insights for search.


It's really purely for you.


So I would at least route those testing tools


at least partially through client-side rendered version


so that you really have a view of what users would see.


Then there was a question regarding US home page


and Indian site links.


I need to double check what is happening there.


So I don't know offhand.


I see some sites that are creating posts,


but they're only accessible from the site map,


so not accessible from the website itself.


From a UX point of view, I believe


it's a good practice, because most of the information


can still be found on the other pages of the website.


And this way, they can keep the website well organized


and only the relevant posts on the website.


So the posts are only for SEO purposes.


Do you think?


What do you think about this?


Is this OK?


So first of all, I think that's a bad practice,


because Google might be able to find and index those pages


based on the site map file, but we're not


going to be able to give them any weight.


If they're not linked within your website,


then we have no idea of the context of those pages,


and we have no idea of the weight that we should give them.


So it essentially means you're creating these pages, putting


them on your server, and Google is probably ignoring them.


So from that point of view, if you


think that this is important content,


then embed it within your website.


If you think it's not important content,


then maybe just get rid of it completely.


So that's the standpoint I take there.


The second part is having a get to know us


in the top menu of a big blog.


Is that a bad practice?


On the one hand, it's probably signaling to Google


that it's an important page.


So Google will value this page, but we won't


have Google traffic for it.


Can it harm the other links?


Because it's on the same hierarchy as other menu links.


So I think this is the general case where


you have an About Us page or a Contact Us page,


and it's linked within the rest of your website.


From our point of view, that's completely normal site


structure.


That's something that we can deal with.


It doesn't cause any problems.


So I don't know.


Looking back maybe, I don't know, five or 10 years,


at some point, people would use a no follow links


to try to discourage Google from looking at the About Us page.


But we know that an About Us page


is a part of a normal website.


So we're not going to say, oh, it's linked from every page.


Therefore, it must be the most important thing


on your website.


And it does have information about you on that page.


So we can crawl that page.


We can find it.


And we can show it where it's relevant,


but that doesn't mean we'll show it all the time.


So from that point of view, putting these links


across your pages where users can find them,


where Googlebot can find them, perfectly fine.


Oh, OK.


Wow.


More and more questions.


I don't know.


Maybe I'll just take one or two more here,


and then I'll pause the recording,


and then we can hang around a little bit longer


and go through more of the questions.


Let me see.


I'll just take the first one here.


Rishpa, I don't know if you're still here.


Probably.


Hi.


So my question is mostly about the pop-ups.


So any type of pop-up which covers complete screen,


can be called an intrusive pop-up,


or can be harmful or bad for SEO?


Or is there some pop-ups like allow browser notification,


or some pop-up which helps users to get


correct page or correct information on the page,


saying that we have, for an example,


they have a category page where a pop-up comes up


for the user which asks the user whether they are on the right


page or not.


If they select yes, they will be continuing on the page.


If not, they will redirect you to the home page.


So what's your thought on it?


We would probably see those as intrusive interstitials.


So the thing that we would try to exclude


from the intrusive interstitials guideline part


is if something is illegal interstitial, which


means maybe a confirmation for cookies


or confirmation of your age, that kind of thing.


That's something we would consider a normal part


of a website, and that wouldn't be problematic.


But if you have a full page pop-up that essentially


is providing extra functionality,


like a sign up to a newsletter, or saying


you're on the wrong version of the website, that kind of thing,


that would be something that we would consider probably


as an intrusive interstitial.


And at the very least, we would try to index that content


because we think, oh, this is the primary content


of the page.


Therefore, we should index that and show it visibly.


And that's probably not what you want.


Oh, no, you're muted.


Yeah, so you are saying it can harm SEO in the wrong way.


Yes, yes.


So if it's not a legal interstitial,


then it can cause problems.


It can cause problems, yeah.


If the pop-ups which has not covered the complete screen,


but part of it, and there's no close button.


So these pop-ups, either you take an out,


you have to take an action on the pop-up.


If you have not taken any action,


you will not be able to see any content on the page,


or you cannot do anything on the page.


But it is not covering complete screen.


It is just on the bottom of it.


And you can see the page content,


but you cannot do anything there.


So what about that?


We would probably also consider that intrusive interstitial.


Yeah.


I think the tricky part is we don't have a percentage


of a page that can be covered like that.


But if you're saying the functionality is blocked,


then that seems intrusive.


Thank you.


Sure.


All right, Sagar.


Hi, sir.


Hi.


Sir, recently one of our competitors


did some changes on his website.


What he did, he had content and internal links below the fold.


What he did, he took it above the fold.


And what we observed that the ranking and the click


share increased massively.


So the Google gives preference to content above the fold


more or below the fold more?


I don't think we have strong preferences in that regard.


So the main thing is that we want


to see some content above the fold, which


means a part of your page should be visible


when a user goes there.


So for example, if a user goes to your website


and they just see a big holiday photo


and they have to scroll down a little bit


to actually get content about a hotel,


then that would be problematic for us.


But if they go to your home page and they see a holiday


photo on top and also a little bit of information


about the hotel, for example, for a hotel site,


that would be fine.


So it's not purely that the content


has to be above the fold, but some of the content has to be.


SPEAKER 2 OK, thank you, sir.


So I had one more question.


Can I ask?


JOHN MUELLER Sure.


Sure.


SPEAKER 2 So what we have an AMP website.


So the user, they cannot see a website URL directly.


They will get to when they search on a mobile,


they will see the cache version URL.


So recently, I was checking this in a Google page


page insights.


What I observed that the cache version URL is passing the core


web vitals, whereas the normal URL is not


passing the core web vitals.


So what should we do?


Which is the correct one?


JOHN MUELLER Both.


Both can be correct.


So we take into account for the core web vitals


what users see in their browser.


And if the first point of where they visit your site


is on the AMP cache, then that is taken into account.


If the next click on your site for a user who


is browsing your website is to the AMP version of your website


locally, then that is also taken into account.


And there are lots of ways that users


can get to your content.


And essentially, however we show your content to the user,


however they see it in their browser,


that's what's taken into account.


AUDIENCE OK.


Thank you, sir.


Thanks a lot.


JOHN MUELLER Sure.


OK.


Let me pause the recording here.


I'll still be here for more questions


if there's anything on your side.


And it looks like lots of hands are still raised.


But always good to have recordings


for a reasonable length.


Thank you all for joining.


Thanks for watching this.


If you're watching it on YouTube,


I hope you found it useful and insightful.


And hopefully I'll see some of you


again in one of the next Hangouts.


All right.


English Google SEO office-hours from October 2, 2020

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


hours Hangout.


It's not Hangout anymore.


I guess the Hangout part we have to drop at some point.


But Google SEO office hours, I guess.


I'm John Mueller.


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


And part of what we do are these Hangouts office hours,


I guess.


So awkward with the names that keep changing.


But anyway, a bunch of questions were submitted already


on YouTube, which is fantastic.


And it's good to see a bunch of you here as well.


If any of you would like to get started


with the first question, you're welcome to jump in.


Hi, John.


Hi.


Can I start?


Sure.


First of all, thanks, because the favicon problems,


I don't know if you remember from a couple of months ago,


has been fixed, finally.


So thanks.


Now it appears.


OK.


Thank you very much.


This is the question.


If I look at the statistics of the Google Search


Console in the past six months, I


see that the number of impressions has nearly doubled.


So in six months, Google shows twice the time


on the Search Console to people in internet.


So I can say, OK, this is very good,


because maybe Google is liking the site.


But at the same time, the average position


went down, significantly down.


And so the overall number of clicks is the same.


So how can I interpret this?


I mean, what is to be changed to improve the situation?


Because these are two different signals.


One is positive, and the other is negative.


Yeah.


So with any kind of changes that you see in the performance


report, my recommendation is always


to try to drill down and find some examples of this change


in a way that is very visible.


So for example, you could look in


to see if there are specific pages that


have changed in the ranking or in the number of impressions


or if there are specific queries where you see this change.


So one thing that might be happening


is that maybe just more people are searching.


It might also be happening that you're


showing for slightly different queries


than before, where it's like there may be more impressions


for those queries, but you're not quite


in that competitive range yet.


So all of these things can help you


to figure out a little bit better where your site is


positioned at the moment and what you might


be able to do to improve there.


So for example, if you're being shown


for more competitive queries, more things


that more people are searching for,


then that could be a sign that Google


has recognized that you're relevant for those kind


of queries, and now it's up to you


to really improve the quality of your website overall


so that Google says, well, this is actually


a good result for this query.


And that's something that ultimately you


have to figure out with your business goals in mind


and think about, is this the query that I think


my site should be ranking for?


Or maybe is Google showing it for the wrong query?


And if so, how can I help Google understand my content


a little bit better?


So it's not just blindly focusing


on the number of impressions and the number of clicks


and the number of the rankings that you have there,


but rather trying to figure out how can you position


your business in a way that makes sense for your business,


for your business goals, and kind of brings it


into the right place for users.


AUDIENCE 1 OK.


Thank you very much.


And it's sometimes really tricky with these kind of things,


also because of things like internationalization.


So that's something that we sometimes


see with our own content.


For example, I don't know, the Webmaster Central blog in Canada


sometimes ranks for the word Google.


And you can imagine then the number of impressions


from Canada is suddenly really high,


but the number of clicks is really low


because normal people, when they search for Google,


they don't want to go to the Webmaster blog.


So it's something where sometimes you


can do something to control it, and sometimes it's just,


I don't know, the algorithms being a little bit weird.


Thank you.


Thank you, John.


Thank you very much.


All right.


Any other questions before we jump into the submitted ones?


Sergio, I think you're trying to say something,


but I can't hear anything.


No.


He did post a question in the chat, though.


Oh, in the chat.


OK.


Let me see.


Oh, OK.


Long question.


One of my client sites has been around for more than five years


and held good rankings for keywords related


to hypnosis, self-help, venereal waves, and subliminal messages


as a form of therapy.


We've noticed over time, especially


after the medical and birth updates,


that these rankings dropped to the second and third page


of results.


Oh, man.


I see you're struggling with the microphone,


but I'll just read for the moment.


And it's like, if you get online, no problem.


The content has always been great in comparison


to the pages that now rank on page one.


I can see that the first five positions for many keywords


have been awarded to medical and psychologically


authoritative sites, which is great.


But position five to 10, there are many low-quality sites


in comparison.


And then there's some examples there.


I think you also submitted this as a question.


Let me see if I can find your question.


I do see that the site is thriving in other areas


and other pages that we consider more supplementary content,


while the main content seems to be plummeting.


My suspicion is that Google thinks


the site and its authors' areas of expertise


are not relevant enough to be trusted


to award better rankings.


Could that be the case?


If so, how could we recover from it?


So it's definitely possible that this is the kind of thing


that is happening here, especially when it comes


to, I think, medical kind of queries.


It is something where our algorithms


try to be a little bit more critical with regards


to the site and the information that we find there.


So that's something where I would try to find a way,


oh, I can hear something from you.


AUDIENCE MEMBER 1 Yeah, I think I fixed it.


OK, cool, cool, yeah, I just would like to add,


I didn't want to really interrupt you, but I wanted to add,


I mean, I've been looking at all the queries


and it seems like the pattern indicates


that the specialized sites like the psychology


and all this traditional, I would say, medical institutions


would dominate those rankings, top five positions.


But then let's say that the alternative sort of ways


of treating those mental illnesses


are falling a bit after that, between 5 and 10 sometimes.


So my question really is, is it worth it


to keep and try and going after those queries,


or is it something that maybe it's never going to happen,


and maybe we should just do something else?


I would never say that it's never going to change,


because the web is very dynamic and these things do change.


But I think just leaving it as it is


and hoping that it magically changes on its own,


I think that's generally a bad strategy.


So I kind of, on the one hand, I think kind of shifting


the focus a little bit and trying to find queries


where it makes more sense to show these sites.


That might be an option.


The other idea might be really to find a way


to really highlight why your site is really


the one that should be shown for some of these queries.


And I realize that's kind of tricky in the sense


that my usual advice is to say, well,


you should make sure that your site should


be ranked number one by far.


And it sounds like in your position,


you're saying, well, the number one rankings are kind of OK,


and we agree with those.


We would just like to be kind of on the first page as well.


And I think that's kind of a tricky balance.


So one thing I would recommend, though,


is to look at what some of the other people in the SEO area


around EAT have been writing about.


There are lots of really good, I think,


case studies or examples of sites that worked hard


to improve their expertise, authority, and trust


in terms of how they present their content


and in terms of how they create the content, how they have


things like author profiles, all of this.


That might be something where you could look into it.


So I don't know all of the names offhand.


And I feel if I mentioned some of them,


then the other ones that I forget would be upset.


But there are some really good SEOs


that have been working in this area,


have been working with medical sites on this topic.


And I would try to search out their content


and look at some of those examples.


I can't guarantee that if you improve your site


in that regard, that suddenly our algorithms will say,


oh, this is a really fantastic site.


But it sounds like you're touching on the medical area


there, and it definitely makes sense, at least for users,


to make sure that you have all of those signals as well,


that you're really saying, well, this is not something that,


I don't know, some kid dreamt up in his basement,


but rather we spent a long time researching this.


And here is the research, and here are the people behind it,


and presenting it in a way that is trustworthy for users


as well.


And then sometimes we can pick that up for searches as well.


Thank you.


Thank you, John.


OK.


Hey, John.


Hi.


Go for it.


Sure.


OK, my question is regarding mobile first indexing


and ranking.


So for example, there's some website


that is on mobile first indexing.


So from Google's perspective, I think


Google will use mobile versions content and ranking signals


for rankings on desktop and mobile both.


Is that right?


Yes.


Now, the second question is if the website is on voice


first indexing, but the majority of traffic


is coming from desktop, because their product is


a desktop-only product.


It's a software application that runs on desktop only.


So the majority of traffic is coming from desktop.


So in that case, will Google consider


their desktop content for rankings,


or it will still consider their mobile version for ranking?


It would only use the mobile version for ranking.


So when we shift to mobile first indexing,


or if we've already shifted that site to mobile first indexing,


then we will only use the mobile version


for indexing and for ranking.


So in a case like that, one thing you can do


is if it's really primarily a desktop site,


like for example, if it's a software company that only


sells desktop software, then you can just make a desktop site


and don't have kind of a simplified mobile version


for that.


But it doesn't matter where the traffic is coming from


or what type of users are searching for the site.


If it's in mobile first indexing,


we only use the mobile version for indexing.


SPEAKER 2


Yeah.


Thank you.


Sure.


SPEAKER 3


John, a quick follow up on that.


I know we talked last time about a classified site


I'm working with and the fact they're still on desktop.


And one of the reasons it wasn't migrated yet


was because differences in content for pages


with very high impressions.


So I checked a bit into that.


And I noticed pages with the highest impressions


are usually kind of like category pages


for classified ads.


And those change very fast.


I mean, there are a lot of it's one of the biggest


classified ads in Romania.


So the pages themselves change a lot in a very short amount


of time.


So I was wondering when Google checks


whether the desktop version is similar to the mobile versions


in terms of content, is there any delay?


Does it check it at this exact same time?


Or is there some time passing between the individual tests?


I mean, there's always a delay because you can't really


do everything at exactly the same time.


But in general, we should be able to deal with that.


So on news sites, we kind of have the same problem


that there are always new news articles.


And my understanding is we should


be able to deal with that.


What I have seen on not on classified sites in particular,


but sometimes on e-commerce sites,


is when you look at category pages,


sometimes the mobile category page


has a lower number of articles on it.


So you might have on desktop, you


have kind of like this matrix of content where you have,


I don't know, maybe 50 items on the desktop category page.


And on mobile, you have a lot of other things


on the category page, and on mobile, you just


have 10 because you have this one row or one column


of content.


So that's something where we could kind of pick that up on.


And I think we have that in the last blog post on mobile first


indexing as well.


We kind of touched on that subject.


I think in general, in a case like this,


I wouldn't necessarily worry about it


if you're sure that kind of like this


is how we want to present it.


And if we index the mobile version,


it's like we have all of the content.


It's just a different number of items,


and it's like it's all the same.


Then in a case like that, I would just leave it be.


It's not that you're going to rank better or higher


with mobile first indexing.


At some point, we'll just shift the site over and say, oh,


we've waited long enough.


And if you're happy with the mobile content and the desktop


content, then it's like, well, nothing will change, right?


So that should be fine.


Right.


Makes sense.


In this particular case, the number of individual listings


is the same.


But again, due to the freshness of the new ads,


the actual content changes in minutes.


So if we're talking about minutes in terms of delay,


it's already different content, especially for those very


high impression categories.


Yeah, I could imagine that maybe that throws us off.


Yeah.


As you mentioned, it doesn't really matter anyway


because whether it's on desktop or you shift on mobile,


it's just going to be the same content, I mean, new content


anyway.


Yeah, that's an interesting one, though.


I think with mobile first indexing,


it's always kind of a case of if your site is not shifted over,


do you have a problem or not?


And as long as you can determine that actually our site is OK


and it's just Google that is a bit confused,


then I would just leave it be and let it kind of take


its time.


Right, I mean, if it was an internal linking problem,


that would actually be more of a concern


because then ranking signals might not be transferred


correctly and so forth.


But in this case, it's not the case.


Yeah, cool.


Thanks.


Hey, John.


Hi.


Quick question.


So I've been working with a news media publisher,


and they did a recently in early August, they did a redesign.


And after two to three weeks, their traffic


dropped by almost 40%.


So they are quite big in terms of traffic


and in terms of keyword rankings and authority.


And the only thing that changed during this, let's call it,


light redesign was some fonts and not a lot


in terms of layout changes.


So one thing, and we've tried different things


to kind of investigate why this drop happened,


worked on pay speed issues that were there before


but maybe could have been the reason.


We knew that some internal linking might have changed,


but that doesn't totally explain why the drop happened side


wide, not in just some specific articles and other things.


But one thing that we are suspecting


that might be the case is a page layout penalty.


So here's what happened.


When the article starts, there is a video there.


And sometimes that video, an ad plays.


Not all the times, but in some cases.


When we are auditing the pages through Lighthouse,


in some cases, it shows that there is no ads.


In some cases, there is.


So we are suspecting that that is causing the Google to see


that there are a lot of, like, there is this ad on mobile


that's above the fold that is considerably taking space.


And that was before the redesign at the same place.


But our suspect is that because of the light redesign,


Google totally rehabilitated the whole site


and now is thinking that this shouldn't be there


and it's not a bad user experience for the users.


It's a bad user experience.


And for that reason, we are suspecting


that this might be the reason for the drop


because we are struggling to find one reason to explain


the site-wide traffic drop of about 40%.


Yeah.


I don't think a redesign would trigger a re-evaluation


in terms of kind of understanding the page layout.


So that seems like something that would be unlikely.


It's hard to say with what you're saying about the redesign.


It sounds like that wouldn't be playing a role with kind


of how we rank things there.


But sometimes there are subtle effects


that aren't visible at first.


So for example, if you were to shift to a JavaScript framework


rather than a static HTML site, then it


could look very similar.


But from a more general perspective,


it would look very similar, but from a technical point of view,


it would be very different.


Which we didn't in our case.


Yeah, so one item less to worry about.


I mean, not that JavaScript is bad or problematic.


It's just like these kind of changes are pretty big.


I don't know.


Offhand, I think if you have videos on the pages


and they're towards the top of the page,


then that should be something that we


would be able to recognize as kind of like a video landing


page rather than to assume that the video is an ad.


Just to clarify, because maybe I didn't give enough insights.


So basically, it's a news site, and the pages


are a news template.


So basically, it is the standard style


that you see in all news media sites.


And nothing, let's say, very different from that.


In terms of the videos, you've seen those videos


when you go to some news site that they are on top.


Not necessarily super relevant to that article,


but they are on the same topic.


Let's say there is an article about Google


launching the new Pixel phone, and then we are just


talking about the Pixel line, not the specific new phone that


was launched.


And sometimes on that video, an ad plays.


Some other things that we've been working on is the CLS.


So one thing that we've noticed compared to other publishers


is that we had these shifts happening in our site


because for some images and some ads, the space wasn't reserved.


And it would kind of push the pages down a bit


when the ad would load.


Or sometimes the ad would be a medium rectangular,


and sometimes another format would show.


And this wasn't always predictable.


We were addressing that.


But again, we are not very sure if that


could have been the reason for a 40% drop,


and that issue has been before the site redesign.


So again, it's very tricky to pinpoint what


the exact reason could have been.


I don't think the CLS metric itself


would be the cause because we don't use Core Web Vitals


as a ranking factor yet.


So just kind of the CLS side itself wouldn't be an issue.


It might be that there is some indirect issue that


users are confused, and they start hating your website


because of this shift.


And then over time, you see an effect.


But that wouldn't be an immediate effect.


Yes, and it's a very light redesign,


meaning that some users, it's just small improvements


on making something clearer and cleaner in general.


So we double checked a lot of things.


It's not a tracking issue because you're


seeing the same things on Search Console


and Ahrefs is reporting.


And one interesting thing is that our top three rankings,


which we had a lot dropped, they are staying on the first page.


But we are just not ranking on the top three rankings.


And this has had quite some effect on the traffic


that we're getting.


Yeah.


So I don't know your website, so it's really hard to say.


But my general feeling here is that this


is less of a technical issue from the redesign


and more a matter of our algorithms


just re-evaluating the overall site quality.


So that's something where it's, especially


when you're looking at the top queries for a page


or for a site, then you might see


that those are still ranking really well


because we think your pages are really


relevant for those queries.


But if the general shift is a little bit downwards,


then it's almost like, well, overall, we


think your site is a little bit less important from a quality


point of view.


So it's like, overall shift is a little bit down,


but the top ones are still very relevant,


so we still show those.


So just from hearing these things,


it sounds like it's something in that regard.


And it's really hard for me to say.


If I'd be able to figure out, more specifically,


if I had the site and were able to use my tools,


my feeling is that this is just an overall shift


in how we evaluate the quality of the site.


SPEAKER 2 may I share the site with you in private on Twitter


just so you can take a look?


Perfect.


I mean, you can also leave it here in the chat.


I pick up the chat afterwards and look through the URLs that


are submitted there.


So if you have a comment and just drop it in the chat,


then I can pick it up here too.


I'm happy to take a look, but if it's just


like a general shift in the way that we understand


the quality of your site, then I don't think I'd even


have anything specific to say, because I wouldn't


be able to say, oh, on this page, you need to improve this.


It's just, well, overall, our algorithms


are a little bit more critical with regards to news.


And maybe overall, things could be improved there.


SPEAKER 3 Yeah.


The only thing that kind of had made this very tricky for us


is that it was immediately after the light redesign.


So it could be a coincidence, but we couldn't base.


Yeah.


Yep.


I'll share that with you.


Thanks a lot.


I think it's always tricky with these things that


happen at the same time, but we make so many changes,


it's really hard to kind of avoid some coincidences


sometimes.


Thank you.


OK.


Let me run through some of the submitted questions


so that we don't lose track of those,


and we'll definitely have more time towards the end


to discuss more other topics.


Follow up to the last Hangouts question on naked URL links


without anchor text.


So naked URL is essentially just when


someone uses the URL as the anchor text instead of a text


or word for the anchor text.


Doesn't mean that without the anchor text,


there is no value in that link.


Like this great website is linking to another site


with just the URL.


Would you pass some of the greatness to the link site


even though there is no anchor text?


Yes, there is absolutely value in a link without anchor text.


But of course, we just don't have as much context.


So you could imagine a situation where even internally


within your website, you just use the link itself


without an anchor text.


And of course, we would be able to crawl your website.


Of course, we would be able to figure out which


of these pages are important.


But we will lose a little bit of value


or a little bit of context from that link.


So it's a bit like, I don't know,


making a page with a text file instead of an HTML file


where you can format things and specify headings and titles


and things like that.


So you could do that, but we lose a bit of information.


I updated my content at the end of last week.


And Google only picked up the updated content yesterday.


I've never seen such a delay.


Usually, it takes at maximum a few hours to update content.


Why does it currently take so long?


Will it be back to normal soon?


So we don't guarantee any specific time


with regards to crawling and indexing.


And depending on the site and where


things change within the site, sometimes we


can pick up those changes within a couple of minutes,


sometimes hours or days, and sometimes it


takes months to pick up those changes.


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


it's not that there is a clear minimum response


time for indexing, but rather, depending on the pages


that you change, sometimes it takes longer.


Sometimes it's very quick.


For example, if we recognize this


is a page that is very critical to your site, where things are


changing very frequently, then probably we


will pick those changes up fairly quickly.


On the other hand, if we realize this is actually


a page that has been the same for the last 10 years


and you make a change there, then probably it


will take a couple of months for us


to realize that actually you changed this page.


So from that point of view, there's a wide range there.


What you can do to make it so that we pick up


these changes a little bit faster


is to let us know about the changes.


So you can do that with a sitemap file.


That's very common.


Most CMS systems, if you're using something like WordPress


or Blogger or whatever, they will automatically


generate sitemap files or feeds for you.


And then it's just a matter of you kind of submitting


that feed to Search Console.


And then once that feed is submitted,


then all of the updates automatically go to Google.


So that's kind of the fastest way


to get things automatically get picked up.


If there's something really critical on your site that


is changing and you really want to make sure Google picks that


up as quickly as possible, then you


can also use the Inspect URL feature in Search Console


and submit the change there.


I would really only use this for kind of exceptional purposes.


So if you're just changing text naturally,


if you're adding a few new articles,


then there's no need to use any of the kind of Submit URL


features.


But if there's something really important and urgent


that you need to change, then that might be an option.


If we submitted an incomplete sitemap,


does it affect the overall search performance


of the website?


All web development work is done by another agency,


and we already sent recommendations


to replace the old sitemap with a new one.


So until this is done, will this affect our search campaign


at the moment?


Probably not.


So the reason I'm saying probably not


is if your sitemap file is missing the pages that you care


about, kind of the new and updated pages, then of course,


we need a little bit longer to actually find all


of those new and updated pages.


So that's kind of the potential downside.


On the other hand, a sitemap file


only helps us to crawl a little bit better.


So it's not the case that our crawling would only


focus on the sitemap file, and we would crawl kind of the


or we would kind of suspend the normal crawling of the website


and only focus on the sitemap.


That's not the case.


It's really the case that we crawl your website normally


anyway, and then the sitemap file helps


us to crawl a little bit better.


So if you make changes on your website


and they're picked up through the normal crawl, then


that's perfectly fine.


The sitemap file doesn't change anything


with regards to ranking.


So if you have an older sitemap file,


then that doesn't mean that your pages will


rank in any way differently.


It's really only about this crawling part


where we might want to pick up changes a little bit faster


if you make specific changes on your site.


And if you have an old sitemap file,


then that doesn't get picked up.


One thing I'm kind of worried about here with this question


is that you're telling the agency to use a newer sitemap


file, where really what you should


be doing with a website like this,


or in general with a website, is to have your sitemap


file generated automatically.


So instead of kind of manually replacing the sitemap file,


you should make sure that you have


a system in place that automatically generates it


all the time, just so that any time you make changes


within your website, then those changes


get picked up automatically.


And there's no kind of manual step involved


in getting that updated.


So that's kind of my recommendation.


One thing you can do, depending on your setup,


especially if you're at a company where


you have different departments working


on different parts of your website,


and you have kind of a marketing department that


does the website, and then maybe a tech part that


does something different, you can host your sitemap file


somewhere else.


So in your robots.txt file, you can specify a location


of your sitemap file.


And that can be somewhere else.


It could be even on a different domain.


So if you have access to the back end of your server


and know when things are changed,


then you could put your sitemap file on a separate domain,


just for sitemaps, for example, and use


that as a way of submitting always live sitemap files,


even if the content itself is something


that takes longer to be updated.


So that might be an option there.


How to write a canonical tag and use a sitemap


for a multilingual website.


Wow.


So many sitemap questions.


So cool.


So the canonical tag, it's not really a tag.


It's a link element that you place


into the head of the page, the web page itself.


So it's not something that you would put into the sitemap


file, but rather it needs to be in the HTML page itself.


And that's something that needs to be


in a specific format in a specific part of the file


so that we can process that and trust it.


So that's, depending on how you create your web pages,


you might need to look into that in particular.


For a multilingual website, you can


use the hreflang annotations between different language


versions.


And these different language versions


you can put either into the head of your page,


like with the rel canonical, or into a sitemap file.


And that's, I guess, a little bit different from the rel


canonical in that the hreflang annotations can


be in either one.


With regards to the mix of canonical and hreflang,


the important part is that all the individual language


versions of your pages should be canonical to themselves.


So the canonical tells us which of your pages


you prefer to have indexed.


And if you say, for example, the English version


is my canonical for the French version, then we may say,


well, then we don't need to process the French version.


We will only index the English version.


And usually, that's not what you want.


Usually, you'd like to have all of the different language


versions indexed individually.


So lots of different answers there.


I don't know which of these might help you there


with your question.


It's a little bit vague.


But hopefully, that helps to refine things a little bit.


I've been trying to feature my website on Google News.


I successfully submitted my website in Google News


three to four months back.


Is it mandatory to add a new sitemap in order


to feature it in that section?


Any other recommendations would also be helpful.


So I don't know too much about Google News with regards


to how to get things submitted there and into the Google News


side of things.


So I can't really help you there.


I have heard from other people that things


are a little bit backed up with regards to getting


new websites into Google News.


So maybe that's something where you'll


need to be a bit more patient.


With regards to the news sitemap, I don't know for sure.


So I do know it's something that we strongly


recommend to use a new sitemap.


Because especially on news sites,


it's really critical that we pick up the news content


as quickly as possible.


So that's something to keep in mind.


But we do have a lot of this documented in the News


Publisher Help Center.


So I would strongly recommend going there.


And I believe there's also a News Publisher Help


Forum where you can ask more specific questions


on these kind of things.


But also, like I mentioned in the beginning there,


I have heard from people externally


that getting new sites into Google News


is a lot harder now or it takes a lot longer time.


So yeah, I don't know, just to set expectations.


How breadcrumbs help SEO?


Does a breadcrumb schema show any rich result in search?


Should we include the home page as a first position


in the breadcrumbs schema?


Should we add the current page as the last element


of the breadcrumb schema?


So I think you almost answered your first question,


how breadcrumbs help SEO.


In general, breadcrumbs, especially


when you're talking about the breadcrumb structured data,


they don't change anything for SEO.


It's not that your pages rank any differently,


but rather that we would show them differently


in the search results when we understand the breadcrumb


markup.


So we could show kind of that breadcrumb trail


in the search results as a rich result.


It wouldn't change anything from ranking.


It just makes it a little bit easier


for people to kind of jump in at the place


where they would like to be.


With regards to the home page and the current page


in the breadcrumb schema, I'm not 100% sure,


but my understanding is that we made it a little bit


clear in the documentation that this is optional.


So you can include your home page and the final page.


You don't necessarily have to.


We definitely understand where your home page is.


We definitely understand where your final page is.


So we can interpolate a little bit from there.


The one place where breadcrumbs could have an effect on SEO


is less around structured data, but if you use them to actually


create links on the page.


And in a case like that, the effect


is essentially that you're cross-linking


these different pages.


So if you have a website that has multiple category levels,


for example, then you're linking from one product


to maybe the subcategory and to the higher level category


in the breadcrumb in the HTML on the page.


And oftentimes, that's a good thing.


For users, they can navigate and find the category


that they want.


For crawling, it definitely helps us as well.


So that's something that kind of makes sense.


But if you already have this HTML


and you're wondering, should I add the structured data or not,


then that's really just a display change.


And with regards to the display, we also


try to figure out which breadcrumbs


to show automatically.


So it might be, depending on your website,


that we're already figuring out which breadcrumbs to show.


You can see this when you search for your own content.


I'm running a local business website.


There are few competitors.


My question is, for a long time, my web and some


of my competitor websites are working very well


against some competitors who made a website on WordPress.


But now, suddenly, for the past two to three months,


all of the webs made on WordPress are on top.


And the most frustrating thing is that their entire content


is copy and paste.


Their page speed, PA and DA scores are worse.


Just a quick side note, PA and DA


are not metrics that Google uses.


These are from third-party tools.


But they can be useful sometimes to compare things.


There is nothing which I'm able to find


that they have better than my website,


except their backlinks.


They have 80% more backlinks than mine.


And all those three to four webs are made on WordPress


and ranking well.


And they're only one to two years old.


So the question, are backlinks still this much


important for web ranking?


So I think a few things worth mentioning here.


On the one hand, the age factor is not necessarily something


where we'd say, well, older sites


deserve to rank higher, or newer sites deserve to rank higher.


Sometimes new content is very relevant.


We will show that visibly.


Sometimes older content is.


Sometimes we show a newer domain.


Sometimes we show an older domain.


So it's definitely not the case that you need an old domain


name to rank well.


The other question that I kind of read between the lines


is, is WordPress better, or is a custom CMS better?


Is another CMS better?


And from our point of view, we don't care which CMS you use.


So it doesn't matter to us if a site is using WordPress.


It doesn't matter to us if a site is using Wix or Blogger


or any of these other systems.


Essentially, we look at the HTML pages that are generated.


And all of these systems have worked really hard


to make reasonable HTML pages.


I think that's one of the really cool things about the web


in, I don't know, the last 10 or so years,


in that if you're using any of the common setups


to create web pages, then chances are, kind of by default,


things will work reasonably well with regards to search.


And you don't need to do anything custom


to make them work even better.


So from that point of view, if WordPress works for you,


and even if you're not creating a blog,


but rather maybe a company website or in shop even,


then feel free to keep using that.


Or if some other system works for you,


then that's also totally fine.


So from that point of view, I think


whether or not a site is on WordPress or not


does not play a role.


With regards to links, we do use links


as a factor in some of our algorithms,


but we use a lot of other things.


And links are probably not the one


that I would say is the most critical item here.


It's really hard to say much about this specific case


because there's not a lot of detail here.


So this is something where I'd be


tempted to say it would be useful to go maybe


to the Webmaster Help Forum so that others can take a look


to see if there is something specific here.


But the shift from position three


to position one or the other way around


is something that can happen for a lot of different reasons.


And just because a website has some things that are worse


doesn't mean that it will automatically


rank lower than other ones.


So a really common case that comes up in the forums


and when talking with people is, for example, maybe


a site has hidden content on it somewhere.


And people will come to us and say,


oh, this website is ranking above mine,


but it has hidden content.


And your Webmaster Guidelines say hidden content is bad.


Therefore, you should remove that website from search.


And from our point of view, we might recognize other things


that are good here.


And we might even recognize that there's hidden content there.


But if we can recognize there's hidden content there,


then we can also ignore it.


So just because there are some aspects of a site that


are worse than yours doesn't mean that it will always


be ranking lower.


Maybe there are other things that


are actually pretty reasonable.


Or what might also be happening is


that these sites in the search results


are actually kind of very similar or very kind


of similar with regards to how they fulfill the user's need.


And then it's something where if we


were to take this to our search quality team


and say, well, these sites are all very similar,


but the one at number three is the one that really


wants to be number one, then they'll tell us,


well, if they're so similar, then there's


no reason for us to change anything with regards


to ranking here.


And the way that you kind of work around this


is by making sure that your website is by far


the most relevant one for these queries.


So make it something so that if we


were to take this case to the search ranking team,


then we could go and say, well, we have a bug in our systems


because what we're showing in the top results


here is clearly a bad result. And what


we're showing at number three or number four


is clearly the one that we should be showing here.


And in a case like that, then the ranking team


will be able to look at that and say, yeah,


we need to make some changes to better understand


the unique things that are happening here.


But if all of these are kind of equivalent


and they're kind of doing the same thing,


then the ranking team will say, well,


we could spend a couple of months working


on tweaking the ranking for this site,


and maybe 50 people will see this improvement, which is OK.


Or we could spend a couple of months improving something


for a lot of other sites or a big mass of users,


and probably they'll focus on the bigger issues.


So I don't know.


I guess in short, my recommendation


would be to maybe go to the Webmaster Help Forums


and get some input from other people, kind of more, maybe


more objective input, and really to think


about what you could be doing on your site


rather than to focus on what your competitors are doing.


Can fragment identifiers be used to optimize


for rich feature snippets?


I don't think so.


So fragment identifiers are these URLs


with the hash or the number sign in them,


and they're generally generated as links on a page,


and they jump to a specific part on that page.


So that's kind of the traditional thing with regards


to fragment identifiers.


And essentially, you're on the same page.


You're just going to different parts of that page.


And when it comes to indexing, we essentially


drop all of those fragments.


We ignore them completely.


We see them as a link to the same page.


And then if it's a link to the same page,


there's nothing we need to do there.


And that wouldn't change anything


with regards to rich features or kind of the featured snippet


aspect there.


Sometimes we do pick up the fragments


with regards to making a cleaner snippet in the search results,


but that's really something where


we understand this is a specific part of the page,


and we can link to that part of the page directly,


and we will just link to it like that.


So you often see this for Wikipedia pages,


which use these fragment identifiers quite regularly.


The other place where these fragments are used sometimes


is on JavaScript sites.


And for us, this is really problematic


because, like I mentioned, we drop the fragment for indexing.


And if the content on the JavaScript site


is only loaded when the fragment is included,


then it's very likely that we will not


be able to index that content.


There is a very, very small number


of sites where we do use the fragment


identifier for indexing.


And that's essentially a very small number


of cases where in the early days of JavaScript indexing,


we thought this would be the only way to pick that up.


And in the meantime, we realized that we


shouldn't be doing this because it just causes so much trouble.


So for the most part, we drop those for indexing completely.


While Google rejects AdSense applications,


just say specifically what went wrong with that application.


That's the best update you can do


for the sake of your customers.


I don't know how AdSense is handled here.


And I imagine they get a lot of applications for things


that are not relevant to be shown.


But I have no idea.


You would need to maybe add that to the AdSense help forum.


I have a Hindi word in my domain, which


is a language, will it affect my articles written in English?


So we do use some signals from words in a URL,


but it's very, very small.


And especially if we can pick up the content on the page,


then we can essentially ignore the words in the URL.


So if you have, I don't know, a Hindi word in your domain name


and your content is in English, then that


feels perfectly fine from my point of view.


It is very common to also have international websites where


you have maybe a domain name in French or in German


or in English, and the content itself


is in other languages as well.


And that's totally fine.


So that's not something I would worry about.


Is it recommended to use keywords


as it is the content to get the best results on Google?


Does the crawler use fundamentals of AI to make


combination of keywords that are closely related to the content


and then rank them?


We want to know how a crawler picks up keywords


to be ranked on Google.


So I don't know.


There's lots of ways that we pick up keywords,


but I think in general, we essentially


look at the content of the page.


Way in the early days, the keywords meta tag was a thing,


but essentially the content on the page


is really what users see.


So that's where we try to understand which words we


would show this query for.


And we do try to figure out combinations


that are more like synonyms or that


are equivalent with regards to keywords on a page.


Sometimes we figure out which things are acronyms or singular


and plural, and we try to understand,


is this page relevant for both of these versions,


or maybe it's just relevant for one of those versions.


But this is something that is quite complex.


There was a video that we put out,


I think, beginning of this year from the Webmaster Conference


we did in Mountain View from Paul Haar, which was, I think,


a really interesting session.


And he goes into a lot of these aspects with regards


to keywords and when we understand


things are similar or equivalent,


when we understand that things are different.


So I think some of the examples that he had where you have


a page that is about New York and a user is searching


for York, should that page about New York also be ranking?


And of course, we should be understanding


that New York are two words, but they belong together.


And York is a different word, a different location that


should be ranking individually.


And all of these things are really kind of unique problems


and interesting to look at.


So I would definitely take a look at that video.


I think the only short answer, if you really


want something short here, is you


don't need to put all of the variations of all


of your keywords on your pages.


If we understand your page is about a specific topic


and has some of those keywords on there,


then we can understand the rest itself.


So you don't need to put all synonyms on your pages.


You don't need to kind of do this SEO thing where


you include all of the typo versions of your keywords


on the same page.


We can figure that out.


OK, wow, we're already at time.


Maybe I'll just open things up for more questions


from some of you, and then I'll pause the recording so


that it doesn't get too long.


And then maybe we can continue a little bit kind of off


the recording afterwards, too.


Whew.


SPEAKER 2 Hey, John.


Hi.


I did post a question.


So we have the, I understand Google mobile indexing


is going through AMP sites first for ranking,


but we don't, it's an e-commerce website.


So not the entire website is AMP.


I want to say about 50% of it.


So Google is first trying to index AMP.


At some point, it's hitting like a regular desktop site link,


but the desktop is responsive, hence mobile friendly.


So it's now also grabbing all the mobile or the rest


of the sites.


From a regular page, I'm linking the AMP pages


with the link rel AMP HTML and from the HTML doing AMP.


So I'm kind of tagging them each other.


But this ideally would be duplicate for mobile versus AMP,


right, or no?


So when it comes to the paired AMP setup,


I think that's what you have there, like the normal HTML


and then the AMP page and then the linking between the two.


We would use the normal HTML page for indexing.


So from that point of view, the AMP page


is more supplemental for us.


And we can show that when people are


on mobile on inappropriate devices.


But for indexing, we would use the normal HTML version.


SPEAKER 2


Yeah.


I don't know why that might happen.


So one thing that has to be the case


is this cross-linking has to be correct


and the AMP page has to be a valid AMP page.


You can use the AMP tester for that.


The other thing that sometimes happens


is because of the way the AMP pages work,


you have to do the analytics there separately.


And especially when we show it as a page on the AMP cache,


then you can't just use the same Google Analytics setup there.


You have to mix those two together.


And that's something that's sometimes confusing


in that you look at the analytics side


and it seems, oh, nobody's going to my AMP pages,


but then you kind of need to add that separate AMP part to it


as well.


SPEAKER 3


For the most part, since AMP is a separate setup


from development perspective, do you


suggest user maintaining two versions or potentially three,


desktop, mobile, and also AMP?


Or just kind of step away from AMP?


I see a value for speed and all, but what are your original


thoughts?


JOHN MUELLER I don't know.


So I think, in general, from Google's point of view,


AMP is a great way to make really fast pages.


And there's some features in search


that rely on AMP to work well, especially things where


we need to embed kind of a page in an AMP viewer


type of situation.


Then we need to have an AMP page for that.


If your content is not relevant for those search features,


then it's more a matter of kind of like the speed side.


Can you generate the same kind of speed


with your normal HTML pages as you can with the AMP pages?


And if so, maybe it makes sense to focus more


on the regular HTML pages.


But if AMP is the way that you can make your mobile site


really fast, then I would definitely continue using that.


SPEAKER 1 OK.


All right, thanks.


JOHN MUELLER Sure.


SPEAKER 3 Hey, John.


A follow-up question on the issue.


I've shared the domain on the chat,


so you know for what site you're talking about.


Just to clarify, I think you mentioned earlier on


that you don't think that the site was re-evaluated because


of this, let's call it, design refresh.


Could something else that we've been using,


and that has been used even before the redesign,


we've been using something like tracking parameters


on the URL, so to all the articles


that we learn from the home page so we know what traffic is


being generated from the home page to which article


so we know which kind of sections of the home page


are driving the most clicks internally.


This is just to measure some things that we needed.


But the pages themselves, they have the canonical


implementation the right way.


Could that have had some impact?


Because home page is the most authoritative page of the site,


and maybe those pages weren't getting as much value,


but this has been implemented pre-redesign as well


for a couple of months.


That could, I don't know, depending