So that's something where our algorithms would look at that


English Google SEO office-hours from July 9, 2021

and try to understand what is happening here


and try to ignore those links.


And if the web spam team were to look at it,


they would also say, well, this is not OK.


And if this is the majority of the links


to your website like this, then they might apply manual action.


So that's something I would avoid.


Even if it is topically relevant, though?


It doesn't matter.


It doesn't matter if it's topically relevant


or if it's kind of like a useful link.


If you're doing this systematically,


then we think that's a bad idea.


Because from our point of view, those


are not natural links to your website.


They're only there because you're doing


this deal with the other side.


AUDIENCE 1 What does come under natural backlinks?


Like we have to create the quality content.


Naturally, people will give us a link.


That's only natural or something?


Because


That's essentially the idea behind natural linking.


From our point of view, it's fine to contact people


and tell them, by the way, I have this great content.


And maybe it's something that you would appreciate


for your website as well.


That's generally fine.


But anything beyond that, where you're saying,


well, you must link to me like this, or you must pay me money,


or I will pay you money for this link,


or I will exchange something for this link,


that's all something that, from our point of view,


would make this an unnatural link.


So providing it to people and promoting it and saying,


here's great content, and they link to you,


that's perfectly fine.


Providing it and saying, I will do an exchange


if you give me a link, that's something


that we would consider unnatural.


OK, thank you.


Sure, Tanush.


Yeah, hi, John.


Hi.


So I want to ask you two questions, OK?


So first one is, suppose if there


is a URL of my website which is performing good in Google


Search, getting traffic and all those things,


but for some unfortunate reasons, it got 404.


OK, so now what I did is I created a new URL


and shifted the old one to the new one, OK?


And re-indexed the new one.


So I want to ask you, will my new URL


will be able to perform the same way as the old one?


It's possible.


Yeah, I mean, it's something where with the redirect,


you're forwarding a lot of the signals from the old URL


to the new one.


So that's kind of a good starting point.


But there's a lot more than just kind


of what you're forwarding with the redirects that's


in play there.


It's like the content itself has to be relevant.


Things on the page have to be appropriate for search.


All of that has to align too.


But the redirect is essentially a good sign for us to say,


well, this URL is replacing this old one.


And ideally, we can just forward everything to the new URL.


OK, OK.


And what if I just fluctuate the situation a little bit


and made some changes, made some good changes in my new content,


and then I redirect it?


Will the situation be the same that you just told me,


or there will be some difference?


It's essentially the same.


You're changing the URL, but we can forward


some of the signals there.


But the content on the URL is also kind of what is important.


My second question is, so suppose, why is it happening


that the featured snippets are different for two locations?


So suppose I am searching a query in India.


The featured snippet is different.


But for US location, the featured snippet is different.


Why is that?


Why is the reason behind it?


It's essentially a snippet from a search result.


And sometimes, search results are different


across different locations.


So from our point of view, that's completely normal.


It's, you know, sometimes you see it


across different countries.


Sometimes you see it even within the same country, slightly


different.


Sometimes you also see just differences


when you search again, when you try half an hour later.


So these things do change, and they're essentially


normal rankings from our point of view.


So one case that can be possible in this


that the website which is ranking on featured snippet


is not ranking in the US, OK?


But what I'm saying is that the website which


is ranking on featured snippet in India


is also ranking on the US.


Then don't you think the featured snippet


will be also same?


Not necessarily, no.


Any best practice is to acquire the featured snippet


for the US location as well?


No.


Like, we don't have any guidelines


what you need to do to be visible as a featured snippet.


OK, thank you.


Sure.


Robin.


Yes.


Hi, John.


Can you hear me?


Great.


So I have a question with regards to FAQ schema.


So how would you detect that the question is


the same over different sites?


How would you differentiate between sites?


Because we have all our country websites


on the same top-level domain, but separated


by different subfolders.


And all of the websites does have


hflang tags, which tells us, for example,


that this is the Canadian English site,


and this is the US English site.


But whenever we publish English content


from our sort of master site, that


will automatically be pushed to all our English websites.


So we are looking into creating some sort of FAQ page or FAQ


component that our different webmasters can use.


But we cannot secure that they won't put the same question


on the different pages.


So would you be able to detect this?


I am pretty sure we would be able to detect it,


because it's like the same piece of text across multiple sites.


But it sounds like it's something that


makes sense for your situation, especially if these


are country-specific sites.


Then we would use something like hflang or other methods


to try to figure out which one to show appropriately.


And then sometimes for different countries,


you have the same questions.


I think that's perfectly fine.


Yeah, because we are an industrial company,


we are pushing the same products all over the world.


But we would probably be able to use the FAQ


and possibly get the image to FAQ results


on the search results page, even though we


would have the same question on the English and Canadian site.


Yeah, I think that's perfectly fine.


Because if these are international sites,


it's not that we would show them on the same search results


page.


So it's not that it would look weird.


It's essentially either we show the Canadian version


or the French version or whatever.


And if they have the same questions,


that's generally fine.


For internationalization, a good practice


is to make sure that things are really localized, not just


kind of like in the right language.


But essentially, those are small tweaks.


And that is not something that from the rich results side,


we would say, oh, this is problematic.


So I would go for it.


All right, all right.


Thank you.


Maurice.


Well, I was just going to comment.


I mean, the FAQ thing says you can only have it on one page.


So we also have a lot of sites with English, global,


and American English with the same questions,


possibly slightly varied.


So that's OK then.


We would hope, yeah.


Yeah, that's generally fine.


What problematic is for us if you have the same questions


and answers across the whole site,


or if you have a hotel site and every hotel listing is like,


what is cancellation period, and you have the same questions


and answers everywhere, then that


starts to look kind of annoying in the search results.


Ideally, we'd like to put it on individual pages.


So if we have a cocktail, we'd have the FAQs generally,


and then on the direct page.


But at the moment, we just put the text on the page.


But to my actual question, we've seen some really weird results


immediately after the July core update.


All our sites are big beverage sites.


It's a big drinks company.


So for example, on the rum brand,


we could see in desktop that basically we've


lost all search, and all of the cocktail pages


appear to be dropped from the index.


Because if we do a site and look at what page is there,


we can see all the other pages, the product pages.


But we can't see the cocktails.


And if you look at in SEMrush, for example,


if we look at, say, a mojito, which


is a very popular rum cocktail, we


could see where before we were ranking page one quite often.


And then for all of the terms related to mojito,


you can see it just dropped to zero.


Now, we thought this, obviously, we


know there's some problems with our cocktail markup, recipe


markup.


But we were thinking if the algorithm had changed,


we'd expect to see them drop lower down the page


or to page two, but not a complete wipeout.


And we've actually done research, because we've


got a Vermouth brand, and that's happened.


But ironically, in the German locale,


we don't see the same effect.


And also, we've looked at some of the competitors,


like Jack Daniels.


And there's some sites in that area, Driesli, Epicurious.


Some of these have dropped completely.


And Diffords, which is another big player


in that area, which is a review cocktail place,


they dropped off to page two.


But it seems to be OK on mobile.


So we're still ranking quite well on mobile.


Obviously, that's probably about 60% to 80% of our traffic.


But it's just really weird that it's completely gone.


We could understand if the algorithm has changed


and our sites aren't as good anymore,


but we wouldn't expect them to see completely go.


And I know, I think, there was someone else who had


a similar problem with his.


It was a blind site.


So it's really, there seems to be something really weird


happening with indexing.


Well, it appears to be indexing.


I mean, the pages are still indexed in Search Console,


but they're just not turning up at all.


Not like they've dropped from position four


to position 13 or 15.


So really, that's the question we were trying to raise.


And it does appear to be across the industry


and recipe-related.


I mean, someone suggested it is because we have the FAQ text


on there, but not the actual markup FAQ.


No.


Because that's why it's not.


So this is the problem we're facing.


Yeah.


So I looked into it a bit with the other site that


posted the details in the forums.


And it turns out we have a system that


tries to recognize soft 404s across desktop and mobile


separately.


And essentially, what happens is that sometimes we


see pages that essentially on desktop look like a 404 page.


So we say, oh, this is a soft 404 on desktop.


We don't need to index it.


And on mobile, it looks like a normal page.


So we'll actually index it there.


And that's where you would see this difference between the


indexing side, where if on desktop or mobile


you search, you do a site query for the URL


and it shows up normally, and on the other device type


you do a site query and it doesn't show at all,


then that's essentially a sign that for that device type,


our systems have picked up somehow


that this is a soft 404 page.


And the tricky thing here is, I mean, on the one hand,


this is fairly new.


So I was a bit surprised that we do this.


On the other hand, in Search Console, we do show soft 404s,


but we show it for the mobile version.


So if on the mobile version everything


is OK from your side, then in Search Console,


it'll look like, oh, it's indexed normally.


It's like, what is your problem?


Whereas on desktop, if we see it as a soft 404 there,


you would not be able to see that directly in Search Console.


So that's kind of something new that has started happening,


I don't know.


Maybe like a month or so.


I don't have the exact time frame there.


But it is something where at least the other side


with the blinds, I think a lot of those examples


were really useful for the team to figure out


how do we need to improve this classifier.


So if you have examples there where you can maybe email me


a bunch of URLs also from the other sites


that where you saw this, then that would be super useful


to pass on to the team.


Yeah, because they are actually returning 200 when we crawl it.


OK, well, I'll send you a few links.


And we've got some competitors like, say, Jack Daniels.


I think it's also got the same problem.


All right, cheers.


Sure.


Cool.


All right, Andre.


Yes, hello.


Right now I'm in job applications.


And I looked at the implementation


of JSON-LD on web pages because Google now supports


the rich snippets for job offers.


I think I asked about that four years ago.


I don't know for how long it is in there.


And I have some questions for special points there.


It's about, let me have a look, experience requirements


and education requirements.


That's something that I can place.


But I see in the rich snippets they are not displayed.


Or is it possible that, for example, in the US,


there are other rich snippets that


already show these points?


I don't know if they would be shown as rich snippets


or as those job search pages.


I think for Google Jobs, we have those interstitial pages.


I don't know offhand exactly how it all looks.


But I don't think we would show it


as a rich snippet in the search result,


but rather tied to it from the, there is a special,


I think, a special layout in the search result


specifically for the Jobs content.


I mean, I could show it to you.


And I would still have a question


about the link to the website, how Google checks


if there's the possibility of online application


on the website.


Maybe you can tell us something about that.


How we check that, I don't know.


I don't know offhand.


If you check that.


Or if there is a problem.


We do.


I think that is something that we do try to figure out.


And my assumption, like I'm not involved with the Jobs stuff


directly.


But my assumption is that we have


a mix of manual and automatic checks


for these kind of things.


Because completely automatic, I don't think


would really be possible.


So it has to be this mix.


SPEAKER 1 OK.


Do you have any tips for us how to optimize here


for good results?


Or is it just something that is based


on location of the job offer?


I think mostly the location, but I actually don't know


any of the details there.


Yeah.


Sorry.


What I would do in your situation


is find someone who's been using it for longer, maybe in the US


or one of the countries where it was rolled out earlier,


and try to pick their mind and get


their insight on what worked well, what didn't work well.


Because it's also something where, from my side,


if there were a secret ranking trick,


then I would be able to tell you.


It's like, oh, you have to put the keyword five times


and then it ranks well.


But someone who's been doing it for a while,


they might be able to give you some of these tips.


OK, that's it for now.


OK, cool.


We still have a bunch of questions lined up.


I think you're ready to go, Michael.


But let me get some of the YouTube questions


in just so that we make sure that those folks also


get an answer.


I'll run through fairly quickly.


Let's see.


Our site is still being indexed in Googlebot Desktop.


The site is facing indexing and ranking issues.


Because of that, when will the next batch


be moved to mobile-first indexing?


I don't have a timing on the next batch,


but you would not be seeing ranking issues


because of a site that is still on Googlebot Desktop.


So it's something where we expect


sites to be indexable by both desktop and mobile users.


So that's something where indexing side,


your content should be available.


If you're seeing ranking issues, that


wouldn't be from mobile-first indexing.


Then Maurice's question, we talked about that briefly.


After redirecting and changing a CDN,


we're seeing a drastic drop in crawl rate.


Yes, that's very reasonable.


If you change your website's infrastructure,


then we will change our crawling.


On the one hand, first to be a little bit conservative


and make sure we don't cause problems.


And then later on, we automatically ramp up again.


So if you change to a different CDN,


that's a significant change in the infrastructure.


And we recognize that change.


And we hold off crawling for a while.


And then we ramp up again if we think everything is fast.


If a website is migrated to React from HTML PHP,


does it negatively affect the whole website?


What are the major things that we're taking care of?


So React is a JavaScript framework.


And if you're implementing the site


with client-side JavaScript, then that


is a significant change on your website.


On the one hand, you're completely


changing the front end of the website.


So JavaScript or not, that is a really significant change.


So you would expect to see some changes in SEO in that regard.


Some of these changes can be positive.


It's not that you automatically drop in ranking just


because you change your front end.


And the other part is you're moving to a JavaScript front


end, or assuming this is the case.


Then for that, you need to take into account


that JavaScript sometimes is a bit tricky with regards


to indexing.


We're pretty good at it now.


But it's still something you need to watch out for.


And I would double check all of our tools and guides


on JavaScript SEO to make sure that you


have all of that lined up.


We tried different language subdomain for a website


where we simply translate the content.


What would be the best practice?


Is using hreflang required for this?


hreflang is not required for anything on a website.


But it does make it easier for us


to recognize localized content, either the same language


content for different countries or different language content.


With regards to automatically ranking


for all of your localized content, that does not happen.


So on the one hand, you have to provide clean internal linking


within your website.


We have to be able to crawl and index all of those pages.


And then we essentially use hreflang


to swap out the right one.


So just automatically moving everything


to a lot of different languages does not


multiply the visibility of your website.


It means it's a lot of extra work for your website.


Sometimes it's not worth it.


Sometimes it is worth it.


But you still have a lot of things


to do other than just add hreflang.


Our website had a noindex, nofollow tags,


and a source code, which we removed in April.


I think I provided a short answer on this on Twitter


just before.


So I double checked the website.


And on the one hand, April is a few months ago.


But it's still relatively seen fairly close.


And we have to recrawl the whole website


to understand that these noindex tags were dropped.


And the main difficulty we saw there,


or I saw when I looked at the website,


is that the website is very slow.


And that essentially means that we're crawling much less


than we would like to.


And that means it will take much longer to see


that the noindex has dropped.


So if there's a way that you can significantly speed things up,


that would be really helpful.


With regards to speed, I don't mean the speed


that you would see in things like PageSpeed Insights.


But even just requesting URLs from the server


takes three, four seconds on average.


And that makes crawling a lot slower than it needs to be.


Removing a tool from indexing using the removal tool


will also remove the page from the Core Web Vitals report.


No, probably not.


So the URL removal tool just hides


the URL in the search results.


It doesn't change indexing.


And you would continue to see that URL in other reports


in Search Console.


So that includes things like structured data reports,


AMP reports, the Core Web Vitals reports, all of those places


where index content is used.


You would still see that URL.


How long does it take for Google to drop pages


from the index if bots encounter a 5xx status code?


Due to problems with the server being


irresponsible for about three days,


Google de-indexed nearly one quarter of my content


without even showing any errors in Search Console.


How long will it take for my content to be back?


So usually, we recommend a 503 status code for somewhere up


to a day.


Sometimes it's OK if it takes maybe two days to resolve.


But if we're talking about an error time frame, which


is more than two days, which three days is kind of close,


but it's still a little bit longer,


then we would start dropping things from the index there.


And usually what happens is we would probably


drop the things that are most visible in the search results


first.


And that's not because we want to cause any problems,


but more because those URLs tend to be the ones


that we crawl the most.


So if the URLs that we crawl the most see a lot of errors,


then we will drop them from the index.


On the other hand, that's also an advantage for you,


because that means the URLs that we think we would show the most


are also the ones we would recrawl again the most.


So we would try to pick those up fairly quickly.


And my guess is after a week or so, for the most part,


that will settle back down again.


Everything will be normal again.


There is no kind of long-lasting grudge against the website


if it shows errors like this.


These things happen.


And we drop them out of the index


mostly so that we kind of reduce the load on your server as


well.


And we pick that up again as quickly as we can afterwards.


Implementing server-side rendering


for improving page speed and keywords ranking,


is that a good strategy?


So implementing anything that improves page speed


is usually a good strategy, especially now


that we use the Core Web Vitals as the ranking factor.


So that sounds like a good thing.


If you're implementing it in a way that does improve the speed,


obviously implementing server-side rendering


is not a magic bullet that will automatically


make your website faster.


But if you can implement it in a way to make your website


faster, then go for it.


Server-side rendering does not automatically


improve keyword ranking.


So it basically takes the existing content you have


and just provides it in a different way to users,


to search engines.


And because of that, it's not like a magic SEO bullet


that will catapult your site to position one.


But rather, it's kind of like a technical change


that you're making that could make things faster for users.


There's a lot of work with server-side rendering.


So I wouldn't just assume you can do a checkbox somewhere


in your CMS and suddenly everything


is server-side rendering.


We have three systems in our website environment,


WordPress, React, and Vue.js.


We're rebuilding the URL structure for our CMS.


However, we're having a conflict with the existing URL


pass used for Vue.js.


Let's see.


It sounds like kind of like changing the URLs a little bit.


Would that hurt our crawl budget?


What's the best practice to adopt in a scenario like this,


considering these are kind of like the ideal URL


pass for user experience?


So having different frameworks on a website,


different infrastructures on a shared domain


is perfectly fine.


That's not something that would cause any problems.


With regards to URLs, the main thing I would watch out for


here is kind of like what I mentioned before,


is if you're changing things like the URL structure,


then that's something that will be reflected in search.


And that takes a bit of time to be reprocessed.


So if you change the URL structure,


make sure that you have all of the redirects set up properly.


My recommendation is to crawl your website locally first


before you make those changes so that you have a clear list of


all of the URLs that are available on your website.


And you can double check that list afterwards


to make sure that they're all redirecting


to appropriate new URLs.


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


I don't think having different frameworks on a website


would change any of that.


It's really like you're doing a revamp of your site structure.


And because of that, you have to do all of the revamp things.


One of the difficult or I don't know,


difficult or trickier parts probably


that makes this a little bit harder


is that React and Vue.js are traditionally


client-side rendered frameworks, which means


they're JavaScript powered, which


means that anything that involves redirects


needs to probably be rendered so that a crawler can recognize


those redirects.


That means if you're using a local tool


to double check your website before and after,


then you need to make sure that it's


able to understand when there's a JavaScript redirect in play


and that it can follow those.


From our point of view, JavaScript redirects are fine.


Sometimes they take a little bit more to be processed.


But essentially, you can do a kind


of like set the location in JavaScript,


or you can use a meta refresh or whatever


to let us know about changes in URL structure like that.


Then there's a question from the other side


with the mobile and desktop version.


Like I mentioned, that I think is primarily the soft 404


change that happened there with mobile and desktop.


Is it a good sign that Google automatically


indexes new posts within hours of posting


versus taking days or even a week to be indexed before?


That doesn't sound like a bad sign to me.


So I think that's generally OK.


Does Google consider elements which


are present in the first fold section


to measure CLS, LCP, and FID, or does it


consider the whole web page to measure Core Web Vitals metrics?


I would double check the Core Web Vitals documentation


that we have on the, I think, web.dev website.


There's a ton of information there


on how we calculate and measure these things.


And I don't think kind of like me trying


to explain that in five seconds would really


be useful in that regard.


So I would double check the information


that we have there.


Also keep in mind for Core Web Vitals, for page experience,


we use the live field data from users, so things


that people actually see.


We don't use kind of the lab tests


where you would theoretically test the page.


Then Core Web Vitals, is that concerning SEO landing pages


only, or is it also important for SEM pages?


So kind of ads landing pages.


I don't know what the quality score things are with regards


to ads landing pages, so I don't know.


I would not be surprised if at some point,


or maybe if already if Google Ads is using this


as a part of the quality evaluation,


but I have no insight there at all.


We're trying to improve our discovery integration.


We have some doubts regarding max image preview large.


What would happen if we put the meta tag on a page,


but for users on mobile devices, we


serve a hero image smaller than 1,200 pixels?


Would that mean we need to serve big images for every user


regardless of the form factor?


Wouldn't that go against the Core Web Vitals recommendations?


Yes, that's tricky and problematic.


The solution that you probably need to look into


is responsive images.


In particular, there is a picture element


that you can use in HTML where you can specify


different resolutions of images.


And with that, we can recognize the higher resolution image


and the normal resolution images.


And for users, it'll automatically


show the appropriate version.


And for search, for discover, we can pick up the larger version


and show that as a preview.


If serving the same URLs for visitors to our public site


and logged in users using our software as a service


with two separate apps serving the two meaning very different


user experience in HTML for the same URLs,


will Google somehow distinguish between Core Web Vitals field


data or just simply blend them?


So if we can't recognize that these are clearly


separate URLs, then we will treat them


as the same thing with regards to Core Web Vitals.


And probably from the field data point of view,


we will mix them together.


It's a little bit different if you have completely separate


URLs.


Then probably what would happen there is we would recognize


these are different parts of a website,


and we would potentially group them separately.


So you see that in Search Console in that we try to group


similar content together.


And we look at that group and use the aggregated data


for that group of content.


And if you could provide a way to make it super clear for us


to recognize this is the internal or private content,


this is the public content, then potentially our systems


would be able to group those separately


and treat them separately.


Whereas if essentially everything


looks the same to us and from a user point of view,


it's like they happen to be logged in, therefore they see


20 times as much content and it's a much slower page,


then we would probably mix that in together


with the other field data that we have.


And it would look like some users have a really fast


experience, some users have a really slow experience,


and on average, it kind of folds in here.


I don't have the exact details offhand,


but it's also something where I believe


we use kind of percentiles with regards


to kind of figuring out which number is relevant for this.


So I would double check the Chrome, the web.dev information


on Core Web Vitals just to be sure there.


But it is something where if you have


kind of like significantly different content


on the same website, especially if you're using the same URLs,


then I would expect our systems to not


be able to differentiate that clearly between them.


How is the integration with Google Search and AdSense


regarding pages feed or page experience?


I don't know.


It's hard for me to say.


I don't know what all is happening on the AdSense side.


I do know from the Chrome side, there


are different teams involved with regards


to page experience overall, and they


do work with some of the bigger sites


out there that are providing content


or that are working on embeds to try


to help them to improve their kind of Core Web Vitals score


overall.


These are not teams directly involved in search,


so it's not that we're trying to help them to improve their


search rankings, but we're trying to help them to improve


the web overall.


So that's something where my guess is if AdSense is


something that is significantly slowing things down,


we see that as something that is shared across the web overall,


that someone on the Chrome or the partnership side


would try to get in touch and help them to improve things.


But also, I mean, they have a lot of information available


already, and our public documentation


can improve things on their side too.


I was using my home page as a landing page, which


is ranked on some keywords.


Now I need to use my home page as a home page, which


isn't a landing page.


When I redirect it, the ranks have been


transformed to the new page.


However, when I disable the redirect,


the ranks decreased again.


How can I redirect my old landing page


and use the home page for something else?


I guess you kind of saw the answer there


yourself in that you can't both redirect and not redirect


at the same time.


With a redirect, we forward the signals.


Without a redirect, we kind of keep the pages separate.


So this is something where if you're significantly


changing your sites, then it takes a while for us


to understand that.


And sometimes the new structure of your site is better.


Sometimes it's not so good.


Ooh, OK.


Wow.


Running through all the questions.


Maybe I'll jump back through some of the live questions


here as well.


And I have a bit more time afterwards as well.


If any of you want to stick around and ask more questions,


we can definitely do that.


Let's see, Michael, you're up first.


Hi, John.


So I've noticed a lot of sites now


include a short summary or a list of key points


on the top of their content.


And those bulleted points generally under the headline


duplicate often verbatim the content


that the reader will then later find in an article.


Is this helpful to Google, or is there any added value


to this practice?


I don't think it changes anything for us.


It seems like it's probably more of a usability thing,


or maybe it encourages people to read on and find


more information.


But I don't think it would change anything


from Google's point of view.


The main practical effect I might expect there


is that if this is right below the heading,


it's possible that we would pull this


in as a part of a description, which might be a good thing


or might be a bad thing, depending on what else would be


kind of like the top text on the page.


Yeah, I mean, I was wondering if people did this just


because people are generally lazy


and they'll read the summary.


But for me, as a practice, when I'm reading it,


it's just like, hey, I read the bullet point,


and then two paragraphs later, I say, I just read this.


It's not a great user experience.


No.


I don't know.


People try different things out.


Some of them end up working, some of them maybe not.


But as far as Google's concerned,


it doesn't make a difference other than if it were.


Yeah.


All right.


Thanks.


Janet, I think you're muted.


Oh, no.


Can't hear you.


There should be a microphone symbol on the bottom.


Yes.


Perfect.


Sorry.


Hi, John.


Hi.


A friend of mine has asked me to help him with his website.


He was vanished from Google.


So first thing I did was search console


connecting and looking on site column website name.


It doesn't appear anywhere.


I couldn't see any manual actions.


So I wanted to ask for a reconsideration


because I think Google has vanished it.


I don't know.


How do I do this without a manual action


because I can't see a URL somewhere?


You can only do a reconsideration request


if there is an active manual action because that's


something that would only be looked at in cases like that.


I mean, you're welcome to drop the URL in the chat here.


And I can take a quick look after the recording stops


to see what is happening there.


But in practice, if none of the website is appearing,


there are two possibilities or two common possibilities.


On the one hand, there might be something technical


that's happening on the website that maybe it's


returning an error code or something like that.


And it looks normal in a browser,


but it doesn't look normal to the search engine crawler.


That can happen from time to time.


Another thing is there is the URL removal tool


where you can remove your whole website


and hide it in the search results, essentially.


And this is something that I think


is not visible directly in the manual action section


and maybe not that visible on the dashboard in Search Console.


But it's something where we've noticed that sometimes people


use the tool to remove an alternate version


of the website.


And they don't realize the tool removes


all versions of the website.


So if you have www and non-www, for example,


if you want to remove the non-www version with that tool,


then it removes all of those versions.


And then it looks, in Search Console,


it looks like everything is normal.


But in the search results, everything is removed.


So those are kind of the common variations there.


But I'm happy to take a quick look to see


if I see anything super obvious.


It might also be that something is super complicated.


But maybe there's an easy answer.


SPEAKER 2


OK.


So when I put Search Console connected it,


would it see in the past if things had been happening?


It would be a half a week or up to a week to be updated when


you verify the site for the first time.


And then it will show the older data as well.


SPEAKER 1 Oh, OK.


Thank you.


I will put my URL in the chat.


SPEAKER 2 Fantastic.


SPEAKER 1 Thank you.


OK, bye.


SPEAKER 2 All right, Jason.


SPEAKER 3 Cool.


Hi, John.


So I've got a real fun one for you.


And I also asked this one on Ask Googlebot on Twitter.


So you answered a question about the maximum indexable page


limits and talked a little bit about static


versus dynamic pages.


So I'm curious on your take on something.


As part of our consumer journey, we


use URL parameters to kind of understand


what content a consumer was interested in and clicked on.


And then also subsequent to that,


we dynamically update page content,


both including textual content that


could be served to the consumer as well as links


to other areas of our website.


And we do that all dynamically, again,


based on that interest that's been expressed.


The consumer experience is very similar, right?


But it is, again, like I mentioned,


different with links that go to different content silos


based on the URL param.


So what's your guidance here?


Should we rel canonical to the naked URL with no parameters?


Or is it OK to let Googlebot decide


which URL is canonical and also if I could reserve a follow-up?


I would generally recommend trying to rel canonical


to the clean URL if you can, just because it makes it


a lot easier for us to understand this is the URL


that you actually want to have indexed.


And it doesn't have to be the clean URL.


It can be one of the parameter versions as well.


But essentially, to provide some guidance for the situation


where we look at the URL, we recognize, oh, it's


like 99% the same as the other URL that we saw.


Which one of these should we index?


You probably have a preference with regards


to which one should be indexed.


And letting us know about that preference with the rel


canonical, with things like internal linking, all of that,


I think, helps us to pick that version as well.


It's not guaranteed that we would.


But it kind of helps us.


And the other thing is also that if you


have all of these different parameter versions, if all


of them were indexable and we would look at them and say,


oh, they're very similar but they're different,


then we would end up indexing a lot of separate URLs


for your website.


And that means we would kind of dilute


the value of your website across all of these different URLs.


And that kind of means, well, we have more different URLs


to index.


We could show those individually.


But that also means for very competitive types of queries,


we'd say, well, none of these URLs are really strong.


And then that would be a little bit of a disadvantage


for kind of the more competitive queries


versus the more targeted queries.


OK, so I guess this isn't the follow up.


But would there be any kind of, I mean, I don't know,


any penalty associations with that at all?


I mean, based on what I've outlined?


Or is it just kind of the algorithmic aspect of it


that you're thinking through on this?


I think for the most part, it would be the algorithmic side.


So the penalty association to me would come in more


if these are essentially doorway pages.


If it's essentially the same content,


you're swapping out city names, something like that,


then I could imagine that our systems would look at this


and say, oh, it's a collection of doorway pages.


And algorithmically, we might say,


oh, we just pick one of these pages and show that


and ignore the parameter in the future.


If it were really excessive, then it's


possible that the web spam team would look at it and say,


oh, they're trying to kind of rank


with all of these doorway pages.


Therefore, we have to take a manual action.


But it's hard for me to recognize


if you're talking about doorway pages


or if you're just saying, well, these are personalized.


And they have slightly different content for different users


because maybe they came in with an ad


or they came in from a different site or something like that.


It's sometimes tricky to draw that line.


The issue with the 301 was noticed about mid to late May.


And we've noticed differences in our logs


working as it should now, and we validated it several times.


But we're still having like 25,000 URLs showing


on a site colon search for the old subdomains.


So I guess the question is, are there


any next steps on how we get the www version of those pages


in the index?


It's possible that that is working as expected,


that we've already kind of moved most of the URLs over.


The tricky part there is with a site colon,


when you're specifically searching for something


that you've moved, our systems understand that the content


used to be there.


And we will try to show it to you anyway,


even if we've already moved things over in indexing.


So that's something where sometimes when


you do a site query for an old site or a section of a site


that has moved, then you still see


a significant number of URLs.


But if you look at the cached version of some of those pages,


you'll see that the new URL is actually being indexed.


So I'd kind of double check that you're not


like searching for or trying to find something that


doesn't exist anymore, and our systems


are trying to be helpful.


And kind of check to see if the cached page is actually


the new one.


And if it is, then I would just let that go.


Cool.


Thank you.


Sure.


All right.


Let me pause the recording here.


Like I mentioned, you all are welcome to hang around


a little bit longer, and we can go through some of the more


questions.


Looks like lots of people still have raised hands.


So lots of stuff to do, but it's always


good to kind of limit the recordings


to a certain amount.


Thank you all for dropping in.


Thanks for all of the questions that were submitted.


I hope some of the answers were useful.


If you're watching this on YouTube,


you're welcome to join us for one of the future sessions


as well.


English Google SEO office-hours from April 16, 2021

All right.


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


Hours Hangout.


My name is John Mueller.


I am a search advocate at Google here in Switzerland.


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


where people can join in and ask their questions


around the websites and web search.


And it looks like a whole bunch of you are here today,


so that's pretty cool.


A bunch of questions were already submitted on YouTube.


We can go through some of those.


But if any of you want to get started


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


Hi, John.


Hi.


So my question is, when we are Googling the brand


name with the country, instead of ranking our home page,


Google is ranking the page which contains the country


name in the page content form.


So how to fix this?


Well, I guess if you're searching for the country name,


then we're just trying to show that to you.


So it's not necessarily something, I don't know,


to fix other than to change the content of the pages there.


But what I would usually do with these kind of things,


where you run across a query where you think your site is


ranking in a weird way, is to first try


to figure out if that's actually a problem in the sense of,


are people actually searching like this for your company?


And what are they expecting to find?


And depending on what you see there,


you might notice, well, actually, it's


only me that is searching like this for my company.


Or you might see, lots of people are searching like this


for my company.


And if you see lots of people are actually


searching like this for your company,


then obviously, since these are your pages,


you can adjust them and change them


however you would like to have them be.


And based on that, we'll try to show that in search.


SPEAKER 2 OK.


Thank you.


SPEAKER 1 Sure.


Yeah.


All right.


SPEAKER 2 Hey, John.


SPEAKER 1 Hi.


SPEAKER 2 OK, so I have a question.


I've also asked it in the user comments


regarding canonicalization and your official guidelines


regarding not using noindex in order to control this a bit


better.


So why do you recommend not using noindex in order


to fix it if, for instance, Google is picking up


the wrong canonical or ignoring the canonical tag?


So I think the not using noindex is more almost more


of a theoretical recommendation than something that I would say


is a requirement in the sense that if you're saying


that something is a canonical of a different page,


then you're saying that they're equivalent.


And if you're saying one of them should not be indexed


and the other one should be indexed,


then you're kind of saying, well, they're


not really equivalent because you want them treated


in very different ways.


So that's kind of where, from a theoretical point of view,


it clashes a bit in that you're saying, oh, these are the same,


but at the same time, oh, they're very different.


From a practical point of view, I


don't see this causing any problems.


So if you're in a situation where you really strongly


want to have one page to be a canonical


and you've done everything else that you need to do to make


sure that the internal linkings are in the right place,


the sitemap file has the right URLs, all of that,


then using noindex like that is something that is not


going to cause any problems.


So I think that's always kind of the tricky aspect there.


As humans, we like to simplify things a little bit


and try to fit a simple model in our mind.


And then theoretically, they're different.


They shouldn't be treated the same.


But from a practical point of view, sometimes it's


like you do what you have to do, and it just works.


So it's not that your site will rank worse


if you do it like that.


AUDIENCE MEMBER 2. Awesome, thanks.


Sure, let me just see.


So people are raising their hands, which is fantastic.


Great way to get people lined up.


Neeraj, let's see.


AUDIENCE MEMBER 3. Yeah, hi, John.


Hi.


So John, actually, I was just going


through some international target guidelines.


So we are doing, in fact, nowadays a lot of people


have to just expand internationally


if business requires this.


And I had some confusion about different multilingual.


And I just checked out all Google documents,


but still there is some confusion.


So one thing that you have recently made very clear


is that if I have different version in different languages,


then hreflang is not really required


if wrong page is not ranking.


But the other thing, the problem that I am having


is I could not understand what is country target


and why it is required.


So there are different case scenarios, right?


One version is that when I have.com version


and I am just creating different folders


and targeting them into different country.


The other case is when I am having


these country-specific domains and targeting them.


So my concern was that in.com version, a lot of times


it happens that we are targeting.com as global.


But in next phase, we are expanding it


to different countries like slash UK, slash this.


On that case, I just wanted to understand what exactly really


it helps.


Because global and specific to local is very trickier


and nowhere in documents Google has really


described all about it.


Yeah, so it is a complicated topic.


I think any website that is expanding globally


runs into these issues.


And there tend to be two approaches.


One is just I will make lots of different versions


and hope that one of them works.


But I think from a practical point of view,


that's probably not so great.


In general, we differentiate between geotargeting


and the hreflang annotations.


So with geotargeting, that's the setting in Search Console.


If you have a country-specific top-level domain that applies


there, geotargeting is a way of improving


your ranking in individual countries


when a user is looking for something local.


So if you have something that is specific to it


in an individual country and you know


that users are looking with a local intent in those countries,


then with geotargeting, you get a little bit


of a ranking boost.


With hreflang, on the other hand,


it's more that if you already have


pages that are ranking in these individual countries,


make sure that Google is showing the right version of that page.


So they're subtly different in that regard.


And I think the tricky part that you kind of touched upon


as well is you can have a global website that works well


in lots of countries.


And you could also have specific country-specific pages


or country-specific websites that also work well


in different cases.


And I think the decision on whether or not


to have a global site or country-specific versions


is tricky.


And it's hard to kind of come up with an absolute answer


for that.


On the one hand, there is the aspect of,


do you really have something country-specific


that you're offering?


Or are you just taking a kind of a globally available product


and making it available in all countries?


If you don't have anything really country-specific


that you're offering, I don't see that much value


in making different country-specific pages


because you're just diluting things.


On the other hand, there's also the aspect


of, are users actually looking with a local intent


for your information?


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


documentation on JavaScript, then people


are not going to search in their country for documentation


on JavaScript and expect to find something from their country.


They're in their language, obviously, but not necessarily


from their country.


On the other hand, if you need a washing machine repairman


or something like that, then probably they're


going to search with the kind of mindset


that they would like to actually find someone who's local


and who is nearby who can help with this problem.


So those are different aspects that you kind of


have to take into account.


I mean, you don't have to take them into account.


But I think if you take all of these things into account,


it's a lot easier to come up with an efficient approach


and say, OK, for these kind of queries,


I can tell people want to have something local,


and I do have something local.


Then I will create some geospecific content


for those different pages.


And for other types of queries, I


see users are just searching for general information, maybe


a product manual or something like that.


And for that, I don't need to have a geospecific page.


And then based on that, you can make a decision,


is it worthwhile to set up a country-specific website,


or is it essentially just trying to cover a tiny bit more,


but not actually significantly enough more


that it's worthwhile to create a whole new website for that?


So I think there's a lot of thought that goes into this.


And I think if you're just getting started


and you want to expand globally with a website,


I would definitely try to find some SEO consultant,


someone who can help you who has done this


before with other websites who can give you


some of the tips and tricks and help


you to avoid some of the pitfalls along the way.


AUDIENCE 1 And regarding this only,


the problem was that when we usually


check in Google Search Console, we


find that the country target is set as global


or as a country-specific for.com version.


And when we are changing the country target in Google Search


Console, can we expect that from global,


if from country-specific, we are changing it to global?


In that country, we may drop ranking.


JOHN MUELLER It's possible if users are searching


with a local intent.


If users are not searching with a local intent,


yeah, I mean, if users are searching for something


and they don't really care where it's from,


then switching to global shouldn't


have any negative effect in that country.


AUDIENCE 1 OK, OK, got it.


Thank you.


JOHN MUELLER Sure.


Fuck me.


AUDIENCE 2 Hey, John.


So yeah, thank you, first of all,


for hosting this beautiful questionnaire.


I mean, some good questions are being thrown around,


and you're giving some quite good answers.


I can get a lot from that.


Thank you for that.


So just a quick story from where my question comes from.


So we're a leading SEO agency in Switzerland,


which has quite a lot of clients.


And we're actually one of the biggest SEO agencies


when it comes to words and articles


in the German, Austrian, and Switzerland region.


So we have about 500 pages, plus, minus.


And we have about 550,000 words.


So the crawl budget is a good question


when it comes to our website.


But the biggest question so far that I had


is, what about the pagination of, let's say,


the blog articles and other kinds of articles?


So let's say the tags, categories, and pagination.


So what does Google think about them?


Should they be noindex?


Should they be nofollow?


What kind of tags should they contain?


Because I couldn't find a trustworthy source that


says, yeah, this should be exactly how


you want to have them.


Because at the end of the day, the user wants to see them.


But does the user actually want to see duplicate content


on the search results?


Yeah, I think that's always a good question.


So what I try to differentiate with regards to pagination


is why you're doing this, the pagination part.


So in particular, is it that you're splitting content up


into multiple pieces, kind of paginating a very long article


and splitting it into part one, part two, part three?


Or is it more a matter of you have


links to individual pages that you would like to have found?


So for example, if you have an e-commerce site


and you look at a category page, then it's


not so much that there is any content that


is unique on page two or page three,


but there are links to other products which are there.


So those are kind of the two main differentiations


that I have there.


And when it comes to content, if you're splitting the content up


across multiple pages, then of course,


you want to make sure that that is indexable.


So do whatever you need to do to make sure


that those pages are findable, that you have links


to part two, part three, part four within your website,


that those pages are also indexable,


that they don't have a canonical pointing to another page,


for example, but rather that they're easily


findable and indexable.


So if it comes to content that is split up,


make sure it's absolutely indexable.


When it comes to essentially just a matter of finding links


to other pieces of content, then I


think it's something which you could argue both ways


in terms of with a lot of websites,


the content is so well cross-linked


that we don't necessarily need to see


page five of a category page.


So maybe you'll say page five of the category pages


should be noindexed, or you can use the rel canonical pointing


back to the first page of the set.


Those are all things that you can


do to reduce the amount of pages that need


to be crawled from a website.


So that's the thinking there.


And with regards to crawl budget,


I would really only look at this if you're


in a situation where you have hundreds of thousands


or millions of pages, and then it's


more a matter of crawl budget where we say,


well, we're running out of time.


We can't actually crawl everything here.


If you're in the order of thousands or tens of thousands


of pages on a website, then from our point of view,


we can deal with that.


That's like it's a lot, but it's not an excessive amount.


And if your server is up to it, maybe we'll


crawl it all in one day even.


But if you have hundreds of thousands or millions of pages


or hundreds of millions of pages,


then you really need to make sure that that crawling


is as efficient as possible.


So those are the aspects I would look at there.


SPEAKER 1


Hreflang, I posted a question on the community tab.


And so we have a scenario where we have a huge global website


where we have to set up Hreflang in a sitemap


because HTML is just not feasible.


And I found best practices for where


you have Hreflang in the HTML where you have separate mobile


and desktop pages.


So the mobile pages point to mobile pages.


Desktop pages point to desktop pages.


How do we do this when we're setting up


Hreflang in a sitemap?


SPEAKER 2 Essentially the same way.


I guess in a case like that, you probably


don't have the mobile pages separately


in the sitemap at the moment.


Or how do you have that?


SPEAKER 1 So we have some.


We don't have them separately.


We have annotations set up for some of the websites,


but not for all.


So half of them are properly set up.


Half of them are not yet properly set up.


And you have the kind of m.pages where you have separate mobile


URLs.


Is that correct?


We have m. and we also have a different site with the slash


SP.


So we have a couple of different patterns.


Wow, OK.


That sounds complex.


Yeah.


So I think in a case like that, what I would try to do,


first of all, is map out the whole site


and get all of the URLs and figure out


how they're connected.


And essentially our guidelines with regards


to sitemaps for m.pages are such that you don't need to list


them in a sitemap file.


But I think in your case, where you have Hreflang annotations


that you want to apply to the m.pages,


then I would absolutely list them.


So it's not that there is any downside


to listing the m.pages.


Our recommendation is essentially just based on,


you don't need to.


You can save time doing it.


But if you really want to apply annotations


for those m.pages, then I would list them in the sitemap file.


And then there on an individual basis,


you can also include the Hreflang annotations


between the m.versions.


OK, so technically with this, because I


don't think we can have an m-dot something.


m-dot example is the English page.


And then the www example is also the English version.


So we can't set it up like that.


So it would be the m-dot with an annotation plus an Hreflang.


Yes.


So it would be the m-dot.


You would list the m-dot in the sitemap file.


And then you have, I think, that separate block


with the Hreflang annotations in the sitemap file.


And on a per-URL basis, you would list the alternate m-dot


versions.


So the English m-dot page would point out


the French m-dot page and the German m-dot page,


things like that.


I think I understand.


Thank you.


It's complicated.


I think Hreflang is complicated on its own.


And with m-dot, it's even more complicated.


For sure.


Great.


Good luck.


Thanks.


Joy.


Hi, John.


Quick question for us.


We have a site that is considering adding ad blocker


detection to prevent users from accessing the site whenever


the ad blocker is on.


The site also has a reg wall, a paywall,


which they do have the schema for.


Question here is, if we decide to exclude Googlebot


from seeing the ad block detection,


who would be flagged for cloaking in that situation?


Probably not.


I think, in general, that would be fine.


I would kind of see that as a way of, I don't know,


recognizing that Googlebot doesn't actually


have an ad blocker installed.


So it's kind of a unique setup that Googlebot has with


regards to rendering pages.


And I think that would kind of be OK.


In regards to cloaking, the cloaking team mostly


tries to watch out for situations


where you're really showing something different to users


as to Googlebot.


And with regards to kind of ad blocking or, I don't know,


other kind of things where it's like you


have to be logged in to actually see the content.


And that's kind of different.


So I don't know.


I'm not completely a fan of all of these anti-ad blocking


setups.


But it's something where, if you need to do it,


then I think that's an appropriate approach.


SPEAKER 2 OK, thank you.


And if we decide to serve Googlebot the ad block


and it's an overlay, do you anticipate any problems


with Google to understand the content there?


JOHN MUELLER If it's an HTML overlay


on top of the existing page, then I


don't see that as being problematic.


Because we would still see the actual content in the HTML


kind of behind that.


That's similar if you have something like a cookie banner


or a cookie interstitial that you're essentially


showing just an HTML div on top of the page.


From our point of view, if we can still


index the actual content from the page, then that's fine.


SPEAKER 2 OK, awesome.


And then last question.


For the new product review update,


a lot of the websites that do cover product reviews also


cover deals on specific days.


Do you anticipate that algorithms


affecting deals-specific posts?


Think of like a Prime Day or something like that.


JOHN MUELLER I don't know.


I don't know.


It's hard to say.


I think the change is primarily based on really kind


of review-based websites.


And all of the websites that have


a significant amount of review-based content


and also have other content, it's


sometimes tricky to say in advance exactly how


that will apply there.


OK, thank you so much.


Sure.


Joshi.


Oh my gosh.


Probably having trouble with the names.


Sorry.


SPEAKER 3 So it's an Indian name.


Hi, John.


So I have two questions for you.


One is, is it necessary to optimize the whole website


if you want to rank a particular page or the URL?


Or it's OK if you don't optimize the whole website?


JOHN MUELLER That's a good question.


So in general, we do look primarily at the page


when it comes to ranking.


But it's always embedded within the context


of your whole website.


So that's something where I would


say it's worthwhile to improve your website overall so


that actually we understand a lot better


how this particular page is really important


and what the value of that particular page is.


So in particular, things like internal linking


and understanding of the headings


and the content of the pages, all of that


helps us even if it's outside of just that one page


that you care about.


say if you care about one particular page


on your website, then you should make sure


that the rest of your website that's


associated with that page is also improved as much as


possible.


OK.


My second question is one of our competitors


is using the redirected expired domains.


They were not on the last 50 rankings also.


And suddenly, they are ranking on first page


on the first SERP ranking.


So does Google ignore the redirected expired domain


or push down the website when they find the use of redirect


expired domain?


And how much time did Google take to find that out?


Yeah.


I think this is like a tactic that is as ancient as the web.


You buy some old expired website,


and then you redirect it to your website.


And we have a lot of practice with it.


So it's something where sometimes it


feels like sites are getting away with it


or seeing some value out of it.


But essentially, from our algorithms point of view,


we do try to recognize this and work with it appropriately.


So it's not something that I would recommend doing.


I think from a business point of view,


sometimes it makes sense to buy an existing website


and say, I will like a business, work together, and have


a larger client base, something like that.


But it's very different from buying an expired domain name


and just redirecting it to your website


and hoping that something comes out of it.


So it's something where if your competitor is ranking well,


then I wouldn't necessarily assume


that it's because of these expired domains.


OK.


So Google does ignore that, or does it


push down the rankings if they found it?


For the most part, we would ignore that.


If that's the default approach that I see from our side


is that when we can recognize that something sneaky


is being done, and if we can ignore it,


then we'll try to ignore it.


If there are situations where it's so built


into the website, the sneakiness,


that we can't just ignore that one part,


then it's possible that our algorithms will say,


oh, we don't know how to treat this website anymore.


We should be more careful.


OK, thanks, John.


I can see the backlinks from the redirected domain.


I would focus on the links that you see in Search Console.


So with regards to redirected pages,


we don't see a redirect the same as a link.


So if you think that, let me just back up a little bit.


So essentially, with regards to what for us is a link


is essentially a connection between two canonical pages.


And if you're redirecting one page to a different page,


then the canonical will be either the destination


or the source page there.


And if from there you have a link to one of your websites,


then essentially that link is between those two


canonical versions.


So from that point of view, if you're


worried about individual links, I


would look at what we show in Search Console,


because in Search Console we show


the destination and the source of those links.


And that's what we would take into account.


And that's what you can use for the disavow tool.


I think for the most part, if you're looking at it


on a per URL basis like this, then probably you're


looking at it in too much detail.


And probably it's not something that you


need to change unless you have a manual action.


So if you don't have a manual action,


then I wouldn't look into all of the URLs


that are redirecting to your site


and try to tweak things there.


If you do have a manual action, then obviously you


want to make sure that things are as clean as possible


so that you can get out of that manual action.


SPEAKER 2 No, I don't have manual action.


But I have a client who is running the domain marketplace.


And every domain that he's selling,


it's redirecting to a product base.


So some of the domains that are redirecting


might have many backlinks.


And for example, I noticed that the disavowing tool


has a limit of 50,000 URLs.


So my client has more than 200,000


of redirecting domains.


How should I handle them?


Yeah, so what I would do there is


to try to find an approach that works outside


of the disavow tool and handle it in that way.


So for example, what you can do is set up a separate site that


works as a jumping place where all of these domains


are redirecting to that particular site.


And that particular site then redirects to your primary site.


And then you can use a robots.txt


to block crawling of that site or that page that's in between.


So essentially, you have all of these domains


that you're selling.


And they redirect to one central location.


That location is blocked by robots.txt.


So Googlebot doesn't see what happens there.


And from there, you redirect to your normal pages.


So users, when they go to those other domains,


they see the redirect normally.


But Googlebot essentially sees everything


going to one particular page.


And then it gets lost.


And that way, you're kind of taking


care that nothing from those links


is affecting your normal website.


So it sounds like something kind of sneaky to do.


But essentially, in a case like this,


where you have a lot of redirects going to your pages


and you want to make sure that they don't negatively


or positively affect your website,


then having this kind of a robot jumping board in between


makes essentially solves the problem for you.


Thank you.


Sure.


OK.


Let me run through some of the submitted questions.


And I'll get through back to all of you


with your raised hands as well.


Let's see.


Some of them we might have already covered too.


We recently restructured our website


to make it less convoluted due to many sub pages.


Since the site is now pretty straightforward,


we're not sure if including a breadcrumb navigation


is still necessary.


So I think there are two aspects here.


So the question kind of focuses on the user experience side,


which is something definitely to think about.


I don't have really that much advice on the user experience


side.


So just purely from an SEO point of view,


there are two aspects there.


On the one hand, we need to be able to crawl your website.


So we need to be able to find links


to the different parts of your website.


If you have this kind of cross-linking happening


naturally within your website, especially if it's a smaller


website now, then that's perfectly fine.


You don't need to add extra breadcrumb links


to make the website interlinked a little bit better.


The other aspect is the kind of UI


that we show in the search results, where more and more,


I don't know, more and more.


But it's something that I see more often.


We don't show the URL in the search results,


but rather try to show some kind of a breadcrumb


navigation for that individual page.


Oops.


There's some echo here, echo here.


So essentially, we try to show some breadcrumb navigation


in the search results for individual pages.


And you can do that with the breadcrumb structure data.


So for a smaller site, maybe that's not as critical,


but it's kind of a nice way to give


some sense of structure for users


when they're searching and finding your pages in the search


results.


So those are kind of the primary aspects there.


And if you feel you don't need breadcrumbs from a UI


point of view, and you're sure that the internal linking works


well within your website, and you


can test this with the various crawling tools that


are out there, and if you look at the search results pages


and you're saying, well, these look OK to me,


then I don't think you need to add any breadcrumb navigation


on top of that.


On the other hand, if you're saying the internal linking is


not that great, or you would like


to have these kind of clear breadcrumbs in the search


results, then adding the breadcrumb structure data


seems like a good move.


When switching a website from Squarespace to WordPress,


will this affect my Google search rankings?


Yes, most likely it will.


And it can be both.


Well, not both, but either positive or negative


for your website in terms of what the final effect will be.


So anytime you're changing your CMS,


you're making pretty big changes on your website.


And sometimes people make these big changes


because they want to improve things for SEO.


So it can be positive if you do them well.


It can also be negative if you make


this migration in a bad way.


So in particular, when we think about a website,


we don't think just about the text on the pages.


So if you copy and paste the text to the other website,


that's kind of one part of a website,


but the other part is everything around the website.


So the internal linking, the URLs that you have,


all of the signals that we've collected over time


for the individual pages that you have,


the headings on the page, the images, the way the images are


embedded, all of these things add up.


And for us, it kind of paints a bigger picture


of how we should show this website in the search results.


So if you're making a change by switching from one provider


to a different provider, then on the one hand,


this is a chance to rethink your website


and think about what could I do to significantly improve things


overall.


On the other hand, it's also a chance


to make sure that you're creating a checklist


for yourself and saying, these are all of the things I want


to make sure remain in place when I move over.


So things like, I want to make sure that all of the old URLs


continue to work or that they at least redirect.


Make sure that you have the right headings


on the right pages, not that you end up with just your company


name as a heading for every page on your website.


Think about the images as well.


And think about, are you getting a lot of traffic


from image search?


And if so, maybe you should think about images even more


than you would otherwise.


So it's like there's a lot of work that's


involved with trying to figure out


what you need to watch out for with a migration like this.


I think the good part is that a lot of these more mainstream


CMS setups, they have a lot of practice with migrations.


And for the most part, if they have tools


to kind of export and import, then for the most part,


that'll work out fairly well.


So in a lot of cases, probably it'll be pretty smooth.


But I would really recommend, if you care about search,


make sure to read up on everything around site


migrations.


Make a lot of checklists.


List all of the pages that you have,


everything that you care about, so that you can kind of,


when you make that migration, you can double check


to make sure that you really have everything covered,


that the tools that you have available actually


do what they're supposed to do.


Because the tricky part is, by the time


that you notice that something has gone wrong with a site


migration, it is often like a month or two later.


And then you're already kind of going down the wrong road.


And fixing that is sometimes a lot harder


than if you can fix that and recognize that right


when you're doing the migration.


Will AMP Stories be more prominent in the search results?


I don't know.


My guess is they will be, at least for a while,


to kind of see how things are showing up.


But I really don't have any insider information


on AMP Stories.


That guess is just purely based on, it's a cool new format.


And there are lots of people making cool things


with AMP Stories.


So maybe we should show them.


As user experience is one of the determining ranking factors,


could you give us a quick insight


into how user experience is measured by Google?


Yeah, I think that's super tricky.


So on the one hand, we don't have a pure user experience


ranking factor kind of thing.


But rather, we have individual things which kind of map


into user experience.


And the two parts that I thought I'd call out


are, on the one hand, we have the, I think it's the page


layout algorithm.


I'm not sure what the official name is.


But essentially, the algorithm where


we try to recognize when there is significant unique content


above the fold on a web page, which kind of maps


into user experience in terms of, is the page when a user


clicks on it from the search results,


is it just filled with ads?


Or is there actually content there?


And that's something we do care about.


So that's something that kind of maps as a ranking factor


and kind of also goes into usability a bit.


The other aspect is everything around Core Web Vitals, which


is coming up, I think, what is it, next month or so, where we


take into account things like speed, usability


with the cumulative layout shift, first input


delay as kind of a measure for how quickly a page is


responsive and take that into account with regards to ranking.


So those are kind of the primary aspects


that I am kind of aware of that would fall into kind of user


experience as a ranking factor.


But it's tricky because it's not that we have user experience


as a ranking factor.


It's just that there's a little bit of overlap.


As Google introduced passage ranking,


does this shift importance from optimizing the page as a whole


to optimizing certain sections of a page?


Can a good passage ranking boost the overall ranking


of a website?


I don't know.


So I would still focus on individual pages.


I think the passage ranking part is more


for if you're in a situation where you have really


long websites or really long pages,


then it's easier for Google to recognize


this particular part of a web page is important


and to rank that appropriately.


But I wouldn't see it as something


where you should go off and try to optimize


individual parts of a page.


But rather, you should try to optimize the whole page


overall.


With regards to passage ranking and the overall ranking


of a website, I think there's always


some overlap in the sense of if you have a website that


has a lot of really long pages, then maybe it's


easier for us to recognize what those pages are about.


If you're already focusing very much on SEO,


then you might also say, well, instead


of hoping that Google figures out


what these individual parts of those pages are about,


maybe I should just split those pages into separate pages


and work on them individually.


That's, of course, always an option as well.


Then this question I didn't quite understand.


What is the treatment that Google gives to a public URL


for a whole website used for test purposes only?


So I think things around, essentially, test websites


or staging websites, for the most part,


we don't try to recognize them and say,


oh, this is a staging website and treat it differently.


But rather, the tricky part is sometimes


we do find them in search, and then we end up


showing them in search.


And you, as a site owner, might say,


well, I don't want you to do that.


So that's usually the aspect that comes into play there.


And with regards to staging websites,


if you want to be sure that Google does not crawl


and index your staging website, then I


would make sure that you're using some kind of authentication


on the staging website so that Google can't actually


access the content, but rather that you can still


use it on your own to test things out.


But at least Google won't be able to access it.


So that's kind of the recommendation there.


The advantage of using authentication versus things


like robots.txt or noindex on pages


is that with authentication, you recognize right away


if you accidentally include that on your primary website.


So if you push that staging website live,


you leave authentication in place,


then that's pretty obvious.


Whereas if you push your staging website live


and you leave the robots.txt block in place


or the noindex in place, then you really


have to watch out for that.


And it happens all the time that sites end up


being blocked by robots.txt or noindex


because a staging website gets pushed live like this.


So that's why we tend to recommend authentication.


So I don't know if your question went into that area.


But otherwise, feel free to ask again or ask here live.


We're using an approved third party


to collect our service and product reviews.


And these are displayed on our website using a widget.


But the data is actually held against our listing


on the review site itself.


How would Google feel if we copied these reviews


and displayed them on our web pages as opposed to just using


a widget to display them?


So I think there are two aspects there.


On the one hand, there's the whole aspect like,


are you allowed to do this with your service provider or not?


I don't know how those things are handled.


The other aspect is the structured data side


on Google from Google's point of view.


You can include these reviews on your pages


if you essentially treat them more as testimonials rather


than reviews.


And with regards to structured data on the pages,


you can only use this review structured data


on your site in a case like this if you're collecting


the reviews yourself.


So if it's not something where you're


taking reviews from someone else's site


and copying them to your site.


So those are the aspects there.


If you want to copy and paste these reviews


and you're allowed to do so, then just


make sure that you're not using the review structured data


for that.


Are user experience for both desktop and mobile


taken into account when it comes to Core Web Vitals


as a ranking factor, or is it only the mobile experience


for the user that counts?


At the moment, the plan is only to use the mobile user


experience.


So in the desktop search results,


we plan not to use these Core Web Vitals with regards


to ranking, at least for the moment.


In the mobile search results, we take into account the mobile


Core Web Vitals of a page.


That's why also in Search Console,


we focus more on the mobile side of things with regards


to the Core Web Vitals.


The other factors that are used for the page experience


ranking element, they still apply


to both desktop and mobile.


So in particular, HTTPS, what is it?


The safe browsing side, all of these other factors


that are about the pages themselves,


they apply for both desktop and mobile.


Are seals a good way to improve the EAT of a website?


I don't know.


So I would focus on what actually provides


kind of authenticity to users, where users actually


feel trustworthy or feel trust about a website


that they're looking at.


Obviously, if there are some specific qualifications


that you have, I think it makes sense


to highlight that on a page.


But just like taking random seals


and copying and pasting them on a website,


I don't think that really impresses users


and definitely doesn't impress Googlebot.


So that's something where I would focus more


on what is actually acceptable by users


and what makes sense there.


Wow, OK, running towards the end of time


or the end of the session here.


Maybe I'll just go back to more questions


from you all for the moment.


I also have a bit more time afterwards.


So if you want to hang around a little bit longer,


we can chat a little bit more as well.


Let me see.


I think the first couple who still have their hands up,


I think we chatted briefly.


Maybe let's go with Ritu, if you're still here.


Hello, sir.


Hi.


How are you?


Pretty good.


I'm good.


So this week, I have some questions


related to schema markup and site links and Search Console.


And firstly, I will start with FAQ schema.


I have implemented FAQ schema on my web pages,


but I'm not able to recognize whether it is live or not.


It is showing in Search Console.


It is appearing.


These pages are having FAQ schema.


It's valid.


But I want to see if it's live or not,


how it is appearing.


We apply on ratings for review ratings.


It appears as a rating in Google SCRP.


But for FAQ schema, I'm not able to recognize.


How can I recognize it?


I don't know if there's a simple trick to do it.


So one thing you can do is to do a site query for your website.


So just site colon and then your domain name or specific pages


where you have this markup.


And for the most part, we will try to show the markup


that we would show there.


So that could be one way to see what it might look like.


The other thing with FAQ markup in general or schema markup


overall is we just don't show it all the time.


So sometimes you need to try different queries out and see


where it would show up.


In Search Console, in the performance report,


you can filter down by some of the rich results types.


I don't know if it's by FAQ as well.


But for some of the rich results types, you can filter down.


And you can find a little bit closer


which queries users are using.


And based on that, you can sometimes reproduce it,


sometimes not always.


Yes.


I have checked in Search Performance Report.


I've seen search appearance option.


And I have seen web results, FAQ schemas, valid pages,


which is having FAQ schemas.


I've seen.


But I want to see how it will appear when I will implement


FAQ schema on the pages, how it will show on Google's CRP.


I want to see like that.


Because it is showing just only that these pages


having FAQ schema.


If you just want to see what it looks like,


you can also use the rich results test.


And I believe it has a preview link there


where you can preview what the page would


look like with that type of structured data.


So that might also be an option.


OK, so one more question.


It is related to site links.


Actually, sir, I have some pages which


I want to appear in Google's CRP as a site links.


The site pages, I have some backlinks also for them.


And I did internal linking also.


I'm doing from last one year.


But still, those pages are not appearing.


But more tactics, what can I do for this?


Like, does it take an app in Google's CRP?


Yeah, site links are something that happens algorithmically.


It's not based on any particular markup on a web page.


So for the most part, it's not something


that you can explicitly target to try to make it appear.


So it's something where if we recognize


that there's a need for the user when they search


in this particular way to show them more results


from a website, then we'll show site links.


But it's not something that you can just tweak on your website


and we will show it.


So I wouldn't necessarily see it as something that you


would be able to optimize for.


I think if we do show site links for a particular page,


then that's something where you can think about,


are these titles OK?


Is the right selection OK?


But if we're not showing site links for a website


or for individual queries, then I


wouldn't focus so much on site links


because it's really not something


that you can control like that.


We don't have any control on it.


So one option is coming search experience.


That is WebLite results.


I'm not getting what exactly that is.


Can you explain WebLite results?


WebLite is a system that we have in place which is active only


in a handful of countries where we see that users


with very limited devices and very limited bandwidth


are able to interact with them.


And that essentially is shown in Search Console there.


So we have a Help Center page on WebLite.


I would double check that.


It also has information on how to opt out.


If you say, I don't want this to happen,


it gives you information on how you


can test your pages, what they would look like with WebLite.


So depending on your site and where your users are,


you might see that in Search Console


or you might not see that at all.


But I would check out the Help Center page for WebLite.


Now, if you have one website that you want to use,


geotargeting for multiple locations,


then you would have to just pick global.


And either not select something in Search Console


or call it unlisted, I think is, if you explicitly


want to say it is meant to be global.


But you can't take one website and use geotargeting


for multiple countries.


What you could do if you have country-specific content


is to split the website up.


And then for the individual parts,


you can verify them separately in Search Console,


depending on your domain name.


And then you can do country targeting


for those individual parts.


But taking a website and splitting it up


so that you have individual country versions


is a pretty big step.


So I wouldn't just try that out or blindly do that.


So may I know what is the meaning of not set?


I don't know.


So what might be happening is that Google Analytics doesn't


see the query that is associated with a user coming to a page.


But I thought they used something like not provided


or something like that.


Yeah, not set and not provided.


Yeah.


And essentially, for most of the traffic that comes from Search,


we don't include the query as a parameter.


So that's why Analytics, they see the traffic


is coming from Google, but they don't know which query it was.


And to see the-


Yeah, we can't see from the sources


that traffic is coming in not set.


Yeah, and if you want to see the queries,


then you have to use Search Console, the performance


report.


OK, for Search Console.


But for not set, we don't have any free options.


Like if we want to see the traffic sources for not set,


we can't see for it.


I don't know.


I don't know how Analytics does that.


Sorry.


OK, sir.


Thank you so much, sir.


Sure.


OK, let me take a break here and just pause the recording.


I still have a bit more time.


So if any of you want to hang around more


and we can get through some of the remaining raised hands


as well, feel free to stay along.


But otherwise, thank you for joining.


Thanks for all of the questions so far.


And I hope this was useful for you all.


And maybe we'll see more, even more people,


I guess, in one of the future Hangouts


if you'd like to join.


Site Migrations: SEO Mythbusting

I wrote a post actually one time after I helped a large-scale e-commerce retailer that hadn't


Site Migrations: SEO Mythbusting

301 redirected its images, right?


Site Migrations: SEO Mythbusting

So that the images were not right.


Site Migrations: SEO Mythbusting

So I wrote a post about like, don't forget to redirect images during migration, right?


Site Migrations: SEO Mythbusting

Visual content, so important.


Site Migrations: SEO Mythbusting

Very important.


Site Migrations: SEO Mythbusting

You would recommend obviously making sure to 301 redirect all images and then just wait


Site Migrations: SEO Mythbusting

if it takes a little longer to refresh in the image index then just do that.


Site Migrations: SEO Mythbusting

And just check the server logs on the old domain to see if traffic really has ramped


Site Migrations: SEO Mythbusting

down and once you're happy with not seeing as much crawl activity, you can flip the switch


Site Migrations: SEO Mythbusting

and say like, okay, we can now discard this.


Site Migrations: SEO Mythbusting

So, let's get started.


Site Migrations: SEO Mythbusting

Let's get started.


Site Migrations: SEO Mythbusting

Hey and welcome everybody to a new episode of SEO Mythbusting.


Site Migrations: SEO Mythbusting

With me today is Ben Gape.


Site Migrations: SEO Mythbusting

And we usually meet at conferences when we are speaking on various stages.


Site Migrations: SEO Mythbusting

Or we talk on Twitter.


Site Migrations: SEO Mythbusting

But what are you doing when we are not meeting on conference occasions or when we are on


Site Migrations: SEO Mythbusting

Twitter?


Site Migrations: SEO Mythbusting

Yeah, sure.


Site Migrations: SEO Mythbusting

So I run my own consulting business, G Squared Interactive, where I typically am helping


Site Migrations: SEO Mythbusting

companies that have experienced a drop in traffic.


Site Migrations: SEO Mythbusting

Cool.


Site Migrations: SEO Mythbusting

Yeah.


Site Migrations: SEO Mythbusting

All right.


Site Migrations: SEO Mythbusting

That sounds pretty awesome.


Site Migrations: SEO Mythbusting

Absolutely.


Site Migrations: SEO Mythbusting

And today we are here to talk about one possible issue that they might encounter and that's


Site Migrations: SEO Mythbusting

site moves, right?


Site Migrations: SEO Mythbusting

Site moves, URL migrations, domain name changes, right.


Site Migrations: SEO Mythbusting

Okay, that's really cool.


Site Migrations: SEO Mythbusting

So what are like the misconceptions or problems that people are facing there?


Site Migrations: SEO Mythbusting

So there's lots of myths and there's actually a lot of confusion in the industry about these.


Site Migrations: SEO Mythbusting

I mean some site owners are scared to actually pull the trigger on it because they don't


Site Migrations: SEO Mythbusting

know what's going to happen and others are actually pulling the trigger too quickly,


Site Migrations: SEO Mythbusting

not preparing for it.


Site Migrations: SEO Mythbusting

And then there's a lot of people in between, right?


Site Migrations: SEO Mythbusting

So I guess the biggest myth is that you will always experience a drop in traffic with a


Site Migrations: SEO Mythbusting

domain name change or site migration.


Site Migrations: SEO Mythbusting

Yeah, right.


Site Migrations: SEO Mythbusting

I think that's a very good one because the answer to it is it depends as you know.


Site Migrations: SEO Mythbusting

So a lot of times people are not understanding what a site move is.


Site Migrations: SEO Mythbusting

So if you are literally just moving from one domain to the other, copying pretty much the


Site Migrations: SEO Mythbusting

entire URL structure and the entire content over, then you not necessarily see a drop


Site Migrations: SEO Mythbusting

of traffic.


Site Migrations: SEO Mythbusting

I mean you will see that traffic drops off over time on one domain and picks up on the


Site Migrations: SEO Mythbusting

other.


Site Migrations: SEO Mythbusting

But overall that doesn't really mean that you have a traffic drop.


Site Migrations: SEO Mythbusting

You're not losing traffic.


Site Migrations: SEO Mythbusting

If we can do this very clean move, then there's not really going to be like a drop period


Site Migrations: SEO Mythbusting

where one drops and then the other picks up.


Site Migrations: SEO Mythbusting

But there's more like a fluid transition.


Site Migrations: SEO Mythbusting

Got it.


Site Migrations: SEO Mythbusting

Now what's interesting is that, you know, I've been part of some domain name changes.


Site Migrations: SEO Mythbusting

Let's stick on that one for a second.


Site Migrations: SEO Mythbusting

That went completely smoothly.


Site Migrations: SEO Mythbusting

Sometimes the site will actually go up over time, so on and so forth.


Site Migrations: SEO Mythbusting

Then there were some weird anomalies, right?


Site Migrations: SEO Mythbusting

And like you said, it depends, right?


Site Migrations: SEO Mythbusting

So a site that three days after completely takes by 70%.


Site Migrations: SEO Mythbusting

And is it based upon the history of the domain?


Site Migrations: SEO Mythbusting

Maybe the domain that they're actually moving to was bought and had a history of its own.


Site Migrations: SEO Mythbusting

Is there anything that you could elaborate on that maybe?


Site Migrations: SEO Mythbusting

So normally it's not much about the history.


Site Migrations: SEO Mythbusting

I mean the history does play a little bit into it, especially if it's like basically


Site Migrations: SEO Mythbusting

being used for spamming purposes and then you buy and then immediately switch.


Site Migrations: SEO Mythbusting

That's a tricky one.


Site Migrations: SEO Mythbusting

You want to make sure that you're not like dealing with weird issues and you want to


Site Migrations: SEO Mythbusting

make sure that you have your monitoring and search console and all that set up properly


Site Migrations: SEO Mythbusting

before you do the switch.


Site Migrations: SEO Mythbusting

It can also just be like if you are making other changes as part of your site move.


Site Migrations: SEO Mythbusting

That's a risky one because then we can't really, we don't know that it's just a move, but we


Site Migrations: SEO Mythbusting

see like, oh, hold on that, like when we are crawling this, there's differences in what


Site Migrations: SEO Mythbusting

we're seeing here.


Site Migrations: SEO Mythbusting

Maybe we need to like be careful and recrawl a little more and then you might, depending


Site Migrations: SEO Mythbusting

on how large your site is, might run into crawl budget things.


Site Migrations: SEO Mythbusting

So it depends on a bunch of factors, but normally getting a domain that you know is not like


Site Migrations: SEO Mythbusting

dealing with issues from the past should be just fine.


Site Migrations: SEO Mythbusting

And even if it's a domain with history, we are aware that content on domains do change.


Site Migrations: SEO Mythbusting

But depending on what the domain looked like beforehand, we might not consider it a site


Site Migrations: SEO Mythbusting

move and then we would have to recrawl and reprocess everything.


Site Migrations: SEO Mythbusting

That takes a little longer.


Site Migrations: SEO Mythbusting

Interesting.


Site Migrations: SEO Mythbusting

So let's say that there's a site, a domain name that was used.


Site Migrations: SEO Mythbusting

I'll give you an example actually.


Site Migrations: SEO Mythbusting

It was a client that had a really long domain name.


Site Migrations: SEO Mythbusting

They were an e-commerce retailer and they're like, wow, they want to get just the four


Site Migrations: SEO Mythbusting

letter domain name that represented their company.


Site Migrations: SEO Mythbusting

They finally got it.


Site Migrations: SEO Mythbusting

They went live with it, right?


Site Migrations: SEO Mythbusting

Did the domain name change?


Site Migrations: SEO Mythbusting

And then they called me about a month in and they're like, oh no, this is not good.


Site Migrations: SEO Mythbusting

What's going on?


Site Migrations: SEO Mythbusting

It ends up that domain, they didn't research and it was some like rock band from the past


Site Migrations: SEO Mythbusting

that had all sorts of crazy spammy links and all sorts of stuff.


Site Migrations: SEO Mythbusting

So they definitely in the short term saw a dip, but then it corrected itself over time.


Site Migrations: SEO Mythbusting

As we see, content can change.


Site Migrations: SEO Mythbusting

I mean, you buy a spammy domain or you just literally have it hacked for a while and then


Site Migrations: SEO Mythbusting

you fix it.


Site Migrations: SEO Mythbusting

You know how that goes, right?


Site Migrations: SEO Mythbusting

Whenever you have problems that we detect and point out to you and you fix them, it


Site Migrations: SEO Mythbusting

takes a while for us to understand that it has changed and everything is better now.


Site Migrations: SEO Mythbusting

But that's generally what happens.


Site Migrations: SEO Mythbusting

So you want to make sure that you clean out anything that might be problematic upfront


Site Migrations: SEO Mythbusting

and give us time to understand that things have now changed and we're now back to a clean


Site Migrations: SEO Mythbusting

slate.


Site Migrations: SEO Mythbusting

So you have to do some cleanup if there was problems in the past.


Site Migrations: SEO Mythbusting

Got it.


Site Migrations: SEO Mythbusting

So in that situation, it probably would have been smart.


Site Migrations: SEO Mythbusting

First of all, they researched the history and then maybe filed a disavow.


Site Migrations: SEO Mythbusting

If there were a bunch of bad links there just to make sure from the beginning that this