Web Performance: SEO Mythbusting

to actually process JavaScript-heavy sites could take up to a week to happen.


Web Performance: SEO Mythbusting

Does this mean that JavaScript-heavy sites are effectively getting penalized in Google search results?


Web Performance: SEO Mythbusting

Right. They are not getting penalized, so they are ranking just fine,


Web Performance: SEO Mythbusting

but the indexing stage is where the problem is.


Web Performance: SEO Mythbusting

Because, as you say, we are processing by putting them first into a rendering queue,


Web Performance: SEO Mythbusting

and then eventually as we have the resources available, we are rendering them,


Web Performance: SEO Mythbusting

and if the resources take a while to actually render,


Web Performance: SEO Mythbusting

that means that we cannot refresh the content in the index as quickly.


Web Performance: SEO Mythbusting

So, new sites might want to look into that.


Web Performance: SEO Mythbusting

But then again, you have usability issues anyways, right?


Web Performance: SEO Mythbusting

Yes.


Web Performance: SEO Mythbusting

And that's because that's bad for the user.


Web Performance: SEO Mythbusting

We try to find search results that are good for the users,


Web Performance: SEO Mythbusting

and if a page takes ages to load, that is not a good experience for me.


Web Performance: SEO Mythbusting

So, you want to fix that because of the users, not necessarily just because of the crawler.


Web Performance: SEO Mythbusting

So, if a page is built using...


Web Performance: SEO Mythbusting

I know I have a bit of a bias against these JavaScript-heavy front-end rendered pages


Web Performance: SEO Mythbusting

because they're terrible for everyone who doesn't have an iPhone or a latest Pixel or something,


Web Performance: SEO Mythbusting

or a desktop computer.


Web Performance: SEO Mythbusting

But anyway, for these sites, if the way they make their money is delivering fresh content daily,


Web Performance: SEO Mythbusting

does this mean that the content in the search results might actually be out of date for them?


Web Performance: SEO Mythbusting

They might be lagging then, yes, absolutely.


Web Performance: SEO Mythbusting

And I think, again, it's really important to get the users a great experience,


Web Performance: SEO Mythbusting

and I don't think you can do that when you are heavily relying on client-side rendering


Web Performance: SEO Mythbusting

because the devices might be really old.


Web Performance: SEO Mythbusting

So, yes, one way of working around, unless you want to properly fix this


Web Performance: SEO Mythbusting

and do hybrid rendering or server-side rendering,


Web Performance: SEO Mythbusting

one way around of that is to do dynamic rendering


Web Performance: SEO Mythbusting

and basically give us a static rendered version of your page for the crawler


Web Performance: SEO Mythbusting

so that we can index it quicker.


Web Performance: SEO Mythbusting

But that's not making the usability and user experience problem-scoring.


Web Performance: SEO Mythbusting

So would you say it's generally safer to rely more on latest HTML and CSS,


Web Performance: SEO Mythbusting

knowing that they degrade more gracefully than JavaScript?


Web Performance: SEO Mythbusting

Yes, generally speaking, if you look at the tristar of technology that we have in the web platform,


Web Performance: SEO Mythbusting

like HTML, CSS, and JavaScript,


Web Performance: SEO Mythbusting

HTML and CSS are just more resilient than JavaScript is.


Web Performance: SEO Mythbusting

So relying on JavaScript too heavily is always going to probably get you into trouble with certain ways


Web Performance: SEO Mythbusting

and spotty network connections and stuff.


Web Performance: SEO Mythbusting

So I would say use polyfills, use progressive enhancement,


Web Performance: SEO Mythbusting

use what the web platform offers you, and use JavaScript responsibly.


Web Performance: SEO Mythbusting

It's really great to hear, especially from a Googler, that reducing reliance on JavaScript


Web Performance: SEO Mythbusting

and taking advantage of good HTML and CSS where it's available can actually do wonders for your SEO.


Web Performance: SEO Mythbusting

Absolutely.


Web Performance: SEO Mythbusting

Ada, thank you so much for being here and talking to me about performance and SEO.


Web Performance: SEO Mythbusting

Do you have a feeling that SEO and web developers can work together nicer?


Web Performance: SEO Mythbusting

Or is there still...


Web Performance: SEO Mythbusting

I think as long as the goals of what people are trying to accomplish are clear,


Web Performance: SEO Mythbusting

and we're not just resorting to auguries or looking at the stars to work out what Google is thinking,


Web Performance: SEO Mythbusting

then it's going to enable developers to actually build sites that make sense


Web Performance: SEO Mythbusting

and take advantage of the web platform.


Web Performance: SEO Mythbusting

Anything Google can do to ensure that the web works for everyone


Web Performance: SEO Mythbusting

and not just in the wealthy western web, then it'll be really, really fantastic.


Web Performance: SEO Mythbusting

Fantastic closing words. Thank you so much for being here.


Web Performance: SEO Mythbusting

Thank you.


Web Performance: SEO Mythbusting

This just in.


Web Performance: SEO Mythbusting

The next episode of SEO Mythbusting is going to be about SEO in the age of frameworks.


Web Performance: SEO Mythbusting

Jason Miller and I will talk about what that entails.


Web Performance: SEO Mythbusting


English Google SEO office-hours from January 15, 2021

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


Hours.


My name is John Mueller.


I'm 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 their websites and SEO and Google Search


and all of that.


A bunch of things were already submitted.


But as always, if any of you want to get started,


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


Hey, John, how's it going?


Hi.


So my question is pretty quick.


There's this website that keeps showing up in search results


in very prominent positions.


And the problem is that when you actually click on the links


from that website, it actually takes you


to something else completely irrelevant for those queries.


And obviously, this is taking up valuable real estate


from other websites that would be


more relevant for those terms.


So my question is, first of all, why doesn't Google


pick up on these situations and remove


those websites from the index?


And because in this particular example,


I've been seeing this publication for over a year.


And if I may send you in the chat box, perhaps, the URL


so you can investigate.


Sure.


Yeah.


Feel free to drop a link in the chat.


In particular, also queries where you're


seeing this kind of an issue.


It kind of depends a bit on what is actually happening there.


If it's more that they're returning content, which


isn't great, then that can happen.


If it's a matter of being redirected to malware


or to phishing content, then that's a little bit


of a different situation.


Usually, that's something where if you submit it


to the appropriate forms, then someone from that team


will take a look at that.


But if it's just low quality content


and you don't think it should be ranking like that,


then sometimes that's a matter of discussion


rather than something where there's


like a clear yes or no thing that we can do


or where the web spam team would jump in and make


a manual action.


But I'm happy to take a look at the examples


and pass that on to whatever team needs to take a look


there.


Cool.


Thank you.


Hi, John.


How are you?


Hi.


Yeah.


So my question is about Web Vitals report in Search Console.


So we are working on Web Vitals.


And Search Console is that there are few pages on the website


that has a poor CLS score.


So when we check those URLs in page speed insights


or other tools like webpagespeed.org,


the score is pretty good, like 0.06.


But Search Console is reporting it around 0.60 or more


than that.


So I'm not sure what we can do here


because Search Console is saying something else and PSI


something else.


So what do you suggest we can do here?


I think what you're seeing there is


the difference between lab data and field data.


So lab data is when you do a theoretical test


and you're kind of theoretically looking


at the website using your connection, using your browser,


using a standardized browser, standardized connection,


or what have you.


And field data is the data that is actually


collected from users when they're using Chrome


and accessing the website.


And in many cases, the lab data is


kind of predictive of the field data that you would see there.


But there definitely are situations


where what you see in your kind of theoretical tests


doesn't match exactly what your users are actually seeing.


And that can happen, for example,


if a lot of your users are in locations


where they have a bad internet connectivity


or where they use devices that tend to be different than what


you're testing for.


And that's kind of where that difference tends to come from.


So yeah.


In our case, actually, the Search Console


is giving like 0.60 for that URL.


But page speed inside in field data and lab data


in both these sections, it is showing around 0.04 or 0.06.


So the difference is pretty much like the only Search Console


is getting some kind of error, but page speed inside


or other tools are not getting.


So that's the field data is pretty good, 0.06.


Lab data is 0.04.


But Search Console is saying it's 0.6.


So.


Yeah.


I mean, the Search Console data is


based on the Chrome User Experience Report data, which


is the field data.


So it's not that Search Console is doing separate tests there.


And what might just be happening is


that there's kind of a time delay


that you're seeing there.


But essentially, they're based on the same data.


The other effect that you might be seeing


is that we're grouping things slightly differently in Search


Console than when you test them individually.


But that's also something which tends to settle down over time.


So should we wait?


I would continue to keep an eye on it.


But Search Console is not inventing these numbers.


It's not making these measurements itself.


It's basing them on something that it


has seen from the field data.


So I would definitely take the time


to investigate a little bit further,


try other parts of your website, and try the Chrome User


Experience Report field data directly, all of those things.


Sure.


OK, sure.


Thank you.


Hi, John.


How are you?


Hi.


I don't know who was first.


He can go.


It's OK.


No problem.


OK.


Me too.


Is this OK?


Thanks.


So John, I have a question about international SEO.


So we have multiple websites for different countries.


And actually, they have similar content in English.


We have used, of course, the hreflang for each website.


And now, actually, we are facing a major decision


whether we should keep it like this with different ccTLDs


or just switch to a generic domain with subfolders.


So we're not sure yet which one to choose.


Yeah.


From our side, both of those approaches would be valid.


So it's not something where we would


say there's an inherent SEO advantage of ccTLDs


or a generic domain with subdirectories.


Both of those would be valid approaches.


The only thing I will keep in mind


is if you make a change, try to make a change that you


can live with in the long run.


Because every time you restructure your website,


you will see some fluctuations.


It will take a bit of time for everything


to settle down again.


So it's not so much that it'll be better automatically


or worse automatically.


It's just during that transition time, which might be a month,


might be two months, you will see fluctuations.


And Search will have trouble understanding


the full picture of your website.


So if you make a decision, make it


based on what you want to have for the long run.


And realize that you will see fluctuations.


So maybe plan the timing in a way


that it doesn't affect your business overall.


That you can say, well, people are not


searching so much during this time,


so I'll do the migration there.


So if I understand well, it's like having


this kind of structure of multiple websites.


It's like fine for ranking factors.


So it doesn't matter whether we switch to subfolders


or keep it like this.


Yeah, exactly.


For SEO reasons, both of these are valid.


Sometimes there are policy reasons to change.


Sometimes there are practical reasons


that the infrastructure is more expensive


or takes more time to maintain.


All of those, I think, are valid reasons.


For SEO reasons, you can do either way.


OK, and you've said something interesting about change.


Actually, our URLs, like for the blog posts,


let's say the current path is URL slash the post name.


So is it bad, for example, to change the structure


to site.com slash blog slash post name?


So is this change good harm our ranking factors?


So it's very important to notice.


You will also see fluctuations when you make that change,


but afterwards, it can be the same as before.


So it's not that you automatically


have an advantage or disadvantage


from changing the URLs, but it will just


take time to settle down and be understood.


OK.


Thank you.


You can go, Mike.


Sorry.


All right, thank you.


Hey, John, I have a question regarding search intent.


How does Google handle search intent?


Does BERT have anything to do with it?


And what can I do to optimize my website for a better search


intent?


I mean, search intent is kind of based


on what users are looking for, what they're trying to do.


So it's not so much that you would optimize your website


for search intent, but rather, you


would optimize your website for what it is that your users are


looking for and how they're searching.


So that's something where you could


look at the queries that are going to your website.


You could also do user studies for a broader batch of users


who maybe are not going to your website already.


And based on that, try to figure out what aspects


do I need to cover there.


So for example, if a user is seeing a specific query


a long tail query, then I should have that exact sentence


on my website.


Is that what you're saying?


It doesn't have to be the exact sentence.


But if you're seeing that as a pattern of something


significant with regards to traffic to your website,


then you can kind of assume people


have this kind of a question, and they're


trying to find information on that.


So it's less a matter of you have to match that sentence


one to one.


But if you think this is an important query,


then have some content that kind of addresses those questions.


So it doesn't have to match exactly,


but it would be good if it helps to kind of solve the problem


that you think these users are having.


And BERT has nothing to do with that,


or it does have something to do with that?


I mean, BERT is more about better understanding


the queries and better understanding the content.


So it's not that you would be optimizing for BERT


or anything like that.


It's more that we just try to match


the content and the queries a little bit better.


OK.


Thank you.


Sure.


Can I also offer a small point of view here?


Since we generally try to figure out kind of the same thing,


search intent behind certain queries


in order to kind of understand what kind of pages


should be created or optimized.


And this is specifically for more general queries


where not even knowing the audience,


you're not really sure what people are looking for.


So for example, somebody's searching for something


like progressive glasses.


You're not sure if they're searching to buy something.


You're not sure if they're searching


to understand what they are or are searching for information.


So I think a good way to go about it


is basically kind of check the top 10 results,


kind of figure out, because kind of sort of reverse engineer


what Google kind of thinks that the most relevant results


should be, like maybe more informational results.


Because if there are just information results


and you're trying to improve or optimize the commercial page,


that might not have a lot of chances


to rank because it's not really relevant based on the intent


that the user is looking for more information


about the subject, not necessarily to purchase anything.


And that can change.


I've noticed, for example, certain holidays,


like Black Friday and things like that,


the search intent might actually change a bit.


And the search results might change


to be a bit more commercial maybe,


rather than informational.


Or something that's newsworthy might change that a bit


as well.


But that's kind of a general idea


of using what else is ranking in the top results


to kind of understand what kind of result you


what kind of page you should create in order


to make sure you're relevant for whatever


the users are searching for.


I also noticed, too, depending on the search query,


that the tabs at the top of Google will change.


So whether it's an image, a video, a map, whatever it is,


that order will actually change based upon the query.


So does that give me any insight to what information


I should have in the hierarchy of the information


I should have on my page?


I think it's useful to take a look at these kind of things


and kind of the existing top rankings.


But you need to also kind of keep in mind


that you're kind of optimizing for the current situation,


where, especially with a query like Black Friday,


if in the summer you're saying, oh, I


want to optimize for Black Friday, and you search for it,


then you'll find informational content on that.


Whereas during the time that you care about,


that informational content is probably not the right thing


to kind of focus on with your website.


So it's something worth keeping in mind


that the current results are kind of representative


of the current state of our understanding of those queries,


but not necessarily of the long-term understanding.


Gotcha.


John, question about a SafeSearch filter and potentially


content that I'm concerned is getting


filtered by the SafeSearch.


And I can see why, potentially.


But I want to try and understand,


is there a way to definitively tell if content is being


filtered by a SafeSearch?


And if so, and once we can determine that, how can I


and I make changes to try and get around that,


do I need to wait for just a Google


to recrawl that content or those images?


Or does it need to pass through another algorithm


and filter or manual action or something like this?


The easy way to test if SafeSearch


is kind of triggering for that content


is to just turn the SafeSearch filter on and off.


So doing something like a site query,


and then just in the search URL on top,


you can just add ampersand safe equals on, I think,


or safe equals off.


And based on that, you'll see if there are different results.


And if there are no different results,


then SafeSearch is essentially not affecting that site.


OK, so site pull-in with SafeSearch on or off


and analyzing those results.


OK, simple as that.


Yeah.


Sure.


And with regards to changes that you make on your website,


that is something where we have to reprocess the content.


We have to kind of re-understand it a little bit.


So it's a little bit longer than just recrawling.


But if it's individual pages, usually that's pretty fast.


If it's a broader part of your website


that we kind of misclassified in that regard,


then that can take a bit longer for us


to kind of aggregate those signals on a broader page.


So if it's an image, images we're specifically


concerned about, that would affect the entire URL


that those pages are on, or those images are on?


Or just, yeah.


I mean, yeah, because we associate the image


with the landing page.


And if there's something problematic in the image,


then it's very likely that we'll just say, well,


kind of this pair of landing page and image


is the thing that we have to filter for safe search.


SPEAKER 1


Got it.


And then I think earlier, at the end of last year,


you had mentioned that if the site is being flagged


in safe search or has been flagged as having adult content,


that it won't be eligible for rich results.


OK, so with regards to safe search,


it's something where we try to do it as granular as possible.


But we can't always do that.


So sometimes if we have individual pages


across the site that we think need


to fall into the safe search category,


it's possible that our algorithms will just


say, we'll take the whole domain and say,


we don't know for sure.


So that's something that kind of plays in there as well.


So the individual pages are essentially


what we try to focus on.


But if we don't know for sure that these individual pages are


OK or not, and it's not like a quality kind of assessment,


it's just safe search or not, then it's


possible that we'll filter that out for those pages.


Yeah.


SPEAKER 2 John, I think we talked about this in 2014


or so when all these female celebrities were being hacked.


I had an entertainment site, and we


were doing legitimate reporting about so-and-so was hacked.


So there was naked photo or naked video were the words.


And just by reporting on it the sheer number


of those women who kept being hacked,


we were getting bucketed.


I think you said that the systems were sort


of accidentally bucketed.


Not accidentally, but they were seeing,


because it was over two or three days,


a ton of that content that you're writing repeatedly


these words and the subject matter


that you could get bucketed.


I think that's what happened.


It was about six years ago or so.


Yeah.


Cool.


Hi, John.


I might have a short and sweet question.


OK.


Google earlier announced that the rollout


date of the new page experience ranking signals, like LCP


and FID and things like that, that the rollout date


was May 2021.


I was wondering if this is a global rollout on May 2021,


or are there certain countries going


to be before that date or after that date masking specifically


for the Belgian market?


My understanding is that this is a global rollout.


So it's something that we collect on a global scale.


And there is no big reason to not do that on a global level


if we can.


So my understanding is it will be global.


With regards to experiments before that,


I don't know for sure.


So in particular, we want to do that badging of the search


results when we see that a site is within the good page


experience bucket.


And usually, badging is really hard to do,


is really hard to get right.


So we have to do a lot of tests before we figure out which way


to badge these search results.


And my assumption is that we will


have some tests around the badging before that time.


And some of those might get seen.


Some of those might not get seen.


But it's something where when we make visible changes in search


like that, we really have to be sure that we do them in a way


that the average user can understand them fairly quickly.


OK, thanks.


Hi there, John.


Yeah, I work in a camper van rental company.


And recently, we have been facing a big problem


that I've been losing a lot of time to the last few months.


Basically, in the specific regions of the UK,


we see that for specific queries that have kind of the same


terms, the search intent is exactly the same, I think.


I'm going to give you an example like camper van rental


and camper space van rental.


We see that our competition has consistent results.


They basically rank on the first page.


And for the two queries, they keep the same position


while our company for camper van rental, for example,


goes top five, 10 results.


And camper space van rental, we go to 60 or 80th position.


And I went deep into this problem.


And I checked how many times I used this word.


I hate to go by keyword by keyword,


but I actually did it this time.


And I see they don't use it.


There's no discrepancy here.


They use it as much as we do.


And I'm trying to figure it out.


And I'm losing my mind about this.


OK.


I suspect what is happening there


is that we don't see these words as being 100% synonyms.


And that's something that our systems


try to pick up automatically.


So it's not that we have, at least as far as I know,


I don't think we have linguistic models that are there


to try to figure out what are the possible synonyms


for these words.


But rather, we see these are unique queries.


And we try to understand what the entities are behind that


and to try to match that as much as possible.


But probably we don't see them as 100% synonyms.


Otherwise, the results would be exactly the same.


And that's something that is some usually it just works


itself out over time in that when we have enough data


to understand that, OK, people searching for the word together


mean exactly the same thing as with separate words,


then that's something that we'll take into account and say,


OK, this is more of a synonym rather than just


kind of very similar.


And with regards to optimizing for something like this,


improving your rankings, I don't really


have any super, super fancy tips there.


It's more a matter of if you're seeing that a lot of people


are searching in one particular way,


then maybe use that way on your website as well


so that we can find that appropriately across your site.


And if you're seeing kind of a balance between those two ways


and you're seeing that Google isn't kind of matching them


as synonyms or as being kind of close together,


then maybe it makes sense to mention both of those


variations on some pages.


It is kind of an awkward shift into the traditional SEO


picture of like, oh, they're just


optimizing for all synonyms.


And usually we figure that out fairly well.


But sometimes it's kind of more practical to say,


well, Google will figure it out at some point,


but I need to solve it for myself now.


So I'll just kind of do the awkward thing.


SPEAKER 2'SINGH'S SPEAKER 1'SINGH'S SPEAKER 2'SINGH'S SPEAKER


1'SINGH'S SPEAKER 1'SINGH'S SPEAKER 2'SINGH'S SPEAKER


1'SINGH'S SPEAKER 1'SINGH'S SPEAKER 1'SINGH'S SPEAKER


OK, I caught that.


Yeah.


That's a very good question.


So there's a video I think white, what is it,


Fall 2019 from Webmaster Conference


in Mountain View from Paul Harr where,


so Paul Harr is one of the top quality


engineers that work at Google on search quality.


It's not going to solve your problem,


but it'll give you a little bit of background information


on what might be happening there.


All right.


Thank you very much.


Hi, John.


Our website has about 60,000 products,


and we have a rather robust layered navigation


that uses a number of product attributes.


We're preparing to go to a migration to a new system


where our search parameters are going


to be changing from the current system to the new one.


And we were hoping to preserve some of our SEO value


for many of those parameters since they do appear


in the search results page.


What is your suggestion on the best approach


to take to preserving the SEO value for those legacy URLs


once we're on a new system?


Should we preserve those?


Should we translate them?


How do you see that playing out?


Yeah.


I think any time you do a migration on a URL level,


ideally, you would redirect the old URLs


to the appropriate new ones.


So if you're changing parameters or the setup


on how you use the parameters within your website


and you care about the old or the new URLs,


then make sure that you have redirect setup.


And with that, we can pretty much pass all of the value


there.


And if you have a very complex setup for your website


where you can't just set up redirects for everything


automatically, then I would at least


take a look at the traffic that you're


seeing from search for the URLs on your site


and make sure that the most important URLs


or the most important URL patterns


are covered with redirects.


So we shouldn't do anything like no index the legacy URLs


or anything like that?


No, I would not use, I mean, if it's something


that you care about the traffic to the old URLs,


kind of that gets forwarded to the new ones,


then I would definitely make sure you have a redirect setup.


Or at least if you can't do a redirect,


then set the rel canonical to the appropriate new URL


so that we can forward any of the value collected


with those old URLs.


If you use a no index and just create the new ones,


then essentially all of the value that was collected


by the old URLs gets dropped.


Oh, that's great to know.


Thank you very much.


Sure.


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


And we'll have some more time for other questions


from everyone along the way.


I think some of them we might already


have covered or gone through.


So the first one I have here is our business


is going through a rebrand and a system update.


We're planning on executing quite a hefty migration.


And then they list a ton of different things


that they're doing, like a domain migration, CMS


migration, consolidating pages, updating content,


updating the site structure, template redesign,


switching hosting providers.


And kind of the question is, how should we do this?


From my point of view, these are all pretty big changes.


So it's something where you will definitely


see fluctuations along the way.


And that's something where if you


plan to do so many different changes


because you think the end state will be important,


then you could theoretically spread that out and do it


one after another.


But practically speaking, that's probably not going to work.


So practically, you're probably going


to have to bite the bullet and say,


well, I will switch from the old setup to the new setup.


And make sure that you have all of those details


from the migration nailed down, in particular, all


of the redirects that you need from the individual URLs,


any internal linking that you have, structured data that


uses URLs, all of that, that it matches the new setup.


And usually, that means creating tons of spreadsheets


and really big lists of URLs and matching things


so that beforehand, you have a really clear plan


of what you need to do.


And once you do the migration, you


can do kind of a QA of the migration


and really confirm that you have everything lined up.


And kind of that confirmation that you have everything


lined up is really critical because you


will see fluctuations, at least kind of intermittently,


while things are being reprocessed.


And you need to be sure that you can kind of trust


that these fluctuations will settle down.


And you can only kind of trust that if you're


sure that you have really done all of the details right.


And that's something where you don't


want to wait for everything to settle down to figure out,


oh, I forgot to redirect my blog,


and now everything is gone.


And with regards to potentially the most dangerous thing,


with regards to the rankings there,


it's important to keep in mind that you will see changes


in ranking, at least during the migration.


You will see different rankings afterwards as well.


If you have a really clear plan and you have a really nice


setup for the final configuration there,


maybe you will see positive changes overall.


If the final setup is a lot more confusing


than the initial setup was, maybe you will see lower


rankings.


So it's not possible to guarantee


that the final configuration will be equivalent in terms


of SEO to the initial one.


And sometimes it's not even reasonably


possible to determine what order of magnitude


the final setup will be.


In particular, if you have multiple sites


that you're combining into a single site,


it's not really possible to just add up all of the traffic


the individual sites got before and assume


that your new site will get it.


It's possible that your new site will be so much stronger


that you'll get a lot more traffic.


It's also possible that the combination that you're doing


essentially results in one site rather than a couple of sites


and that you might lose some visibility in search.


So if you're doing this for the first time,


I would definitely recommend getting help from someone


who's done it before so that you can hear some, I don't know,


war stories around migrations, what went wrong,


and make sure that you don't do those things.


Do you have any information regarding web stories,


when they might be released in Australia?


We want to be early adopters.


So if we can get any estimation.


I don't have any information on when new features will launch,


particularly web stories in Australia.


With web stories, it's important to keep in mind


they are normal pages too.


So you can already adopt and use these web stories


in on your website.


And we will crawl and index them like normal pages as well.


And when we start to kind of show them more visibly,


you'll see them a little bit differently


in the search results.


You might see them more prominently in Discover as well.


But essentially, you can go ahead and implement these


already.


With regards to us kind of turning on individual features


in individual countries, sometimes that's


a matter of working out the policies


and working out the technical details.


Sometimes that's also a matter of us


being able to look into the data from that country and say,


oh, lots of people are already implementing


this structured data.


Maybe we should just turn it on for them.


So in that regard, if you're tempted


to try something like this out, I would say go for it,


even if you're not seeing all of the advantages yet.


Please detail the difference between a doorway


page and a landing page and why doorway pages are frowned upon.


So usually, I think we have a Help Center article about this.


But usually, doorway pages are individual pages


where you're just funneling people


to the actual part of your website that you care about.


And my assumption is that for the most part,


our systems are able to understand these doorway pages


better nowadays anyway so that when


we look at these doorway pages, we see, oh, this


is a kind of a low-quality page.


It mentions these keywords, but it's kind of a low-quality


page, so we will probably not show it as visibly in search


anyway.


But essentially, the idea is that instead of setting up


a number of different pages for just variations


of different keywords, make one really strong page


that really kind of covers that topic really well so


that our systems can recognize this is a fantastic page.


And appropriately, we can understand, well,


this is a part of this bigger website, which


is also really fantastic.


And that helps us to kind of better rank those pages


overall.


Will adding history API functionality


into infinite scroll pages, is that enough?


Or do I need to add physical pagination links


on top of this?


Yes, if you're using infinite scroll,


then having paginated links is very important for us


because then we can crawl and index those paginated links


separately.


History API is something we can sometimes pick up on,


but often it relies on kind of the user doing something


specific on a page, like scrolling


to a specific location.


And Googlebot, in general, when rendering a page,


does not trigger any of these actions,


but rather renders a page in kind of a really long viewport.


And maybe that will trigger your history API or not.


Whereas if you have links to the individual paginated versions


of those pages, then for sure we can figure out,


like, these are the different pages.


They belong to this one list.


And we can index those individually.


So history API alone without using links on the page


is kind of hit and miss.


And depending on how you implement it,


it's likely that we won't be able to pick up


on those paginated versions.


The other thing to keep in mind is sometimes


we don't need to trigger infinite scroll on a website.


So in particular, if you have something


like a blog on a category page and you use infinite scroll


there, if we can already find all of those blog posts


then we don't really need to trigger infinite scroll.


So it's not something where you'd


have to say, well, if we use infinite scroll,


we must make sure that it's crawlable.


But rather, it's a good practice.


And if you care about those pages being indexed,


then sure, you should watch out to make sure


that they're crawlable.


If you don't care, that's totally up to you.


Please tell us about Google Sites search.


So I don't really have a lot of information about Google Sites.


I think we have a help forum specifically for Google Sites,


and I would recommend going there.


So I don't really know what the kind of things


to watch out for with regards to Google Sites.


MIHAI APERGHISLOOO-MUNDEZ-SINGH CAMPBELLO-SINGH NGUYENIYU


MIHAI APERGHISLOOO-MUNDEZ-SINGH NGUYENIYU


So I think that then you can use a normal pagination,


and Google will kind of figure it out on its own.


What I noticed is that for a couple of our clients


where we have a View All page, but it's simply


there because the platform allows


you to see kind of all of the results,


and there's like a parameter like page equals all


or something like that, Google will actually


use that index data and rank that despite us not wanting


to write it has a canonical to the non-parameter version,


but Google simply seems to be ignoring it.


And I wonder whether it is because Google kind of figured


out, oh, this is a View All page.


This is a strong signal for us to kind of use it


despite having the canonical to something else.


So yeah, and those kind of View All pages in some cases


can create a bit of problems because it loads like,


in some cases, 200, 300 products.


The page kind of starts to load fairly slowly.


And other than a redirect, I don't


see how else we could kind of push


Google to stop using that page and just


use the canonical versions then.


Yeah.


I don't know what we do with the View All pages at the moment.


My guess is that you might be linking to that View All


page from all of the pages within the paginated set.


And then we'll say, oh, this must be a really important


page.


We should focus on it instead of the individual paginated


versions.


That might be where we're picking that up.


But that then kind of depends on, well,


do you want to keep a View All page or not?


And if you don't want to keep a View All page,


then obviously don't link to it.


And then we'll kind of work that out.


If you do want to link to it, then maybe we will end it.


Yeah, it looks like we're linking to it.


So yeah.


I thought it was just a dropdown with no anchored actual links,


like HTML tags.


But it looks that they are HTML tags.


So yeah, that seems to make sense.


So removing it might lead Google to drop it and use the, yeah,


OK.


Yeah, yeah.


Cool.


Then a question about backlink badges.


So I don't know.


This seems like something that feels a little bit older.


But the question is, a few days ago,


I invited members of my website to use an HTML snippet that


shows a badge on their websites linking back to their profile


page on my website.


Users may edit the HTML snippet to their needs.


The default alt tag is a picture of one


of the site's main keywords.


Using the badge is entirely voluntary.


There are no incentives whatsoever.


And using the picture itself without a backlink


is also possible.


In other words, users will use the badges


solely to show their appreciation for the website


in question and promote their profiles on that website.


Is there anything wrong with that?


That sounds essentially OK.


I mean, that's something where if there's really


no kind of value associated with that link in terms of,


like, you must link to my website with this badge


in order to gain access to these features or whatever,


then that's perfectly fine.


Some sites do this in other ways.


For example, that they'll have a link on a page that


says, link to this page.


And you click on that, it opens a little text window


where there's an HTML snippet that you can use and just copy


that to your website.


That's also perfectly fine.


The important part is really that this is completely


voluntary, that people are able to edit this kind of markup


if they want to use it or not.


That's essentially the important part.


Then there's another question about CLS and kind


of page speed insights and the field data there.


I think we talked about that a little bit beforehand as well.


It, I think, also goes into kind of a difference


between the field data that you see in page speed insights


and the data in Search Console.


So I'll definitely pass this on to the Search Console team


to take a look at.


If you have any examples, feel free to drop them in the chat


or send them my way, maybe on Twitter, for example.


Having specific examples makes it a little bit easier.


Does it negatively affect SEO for internal linking


if an anchor tag only contains a button tag?


Does Googlebot take the text inside the button tag


into account as a signal for internal links,


or would it be better to use a plain text


inside of an anchor tag?


So at least as far as I understand it, by default,


a button element on a page is essentially


tied to a form element.


And you could use JavaScript to trigger a kind of a navigation


to a specific URL, which makes it kind of like a link.


But essentially, Googlebot won't click on these buttons


to see what happens.


So we would not see that there's a link associated to another


URL within your website.


So in that regard, if you want to use kind of something that


looks like a button for internal navigation,


then I would use normal HTML links


and just style it with CSS to make it look like a button,


rather than to use button elements in HTML


and then add JavaScript that kind of makes


them act like a link.


Question about internationalization.


We have the same version of the website in English


for different countries.


And we use hreflang.


And I think this is similar to the question


we had in the beginning.


So currently, we're using different ccTLDs


for the individual countries.


And we'd like to move to a generic domain


with subdirectories.


And yeah, like I mentioned, we support both of those setups


with regards to international websites,


as long as the main domain is really


a generic top-level domain.


So you mentioned, or the question here mentions.io.


I believe that.io is theoretically a country


code top-level domain.


It might be that we treat.io as a generic top-level domain.


You can look that up in our help documentation.


But I believe by default, that's a country code top-level domain.


And for country code top-level domains,


you would not be able to set geotargeting.


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


Sometimes, the kind of the cute top-level domains


are actually country code top-level domains.


And it's worthwhile to double-check


that you can actually set the geotargeting in Search Console


before you kind of invest everything


to move all of your international versions


into that.


SPEAKER 2


So I just wanted to understand if there


is one page in top-level country, top-level domain,


and we have decided to go with the ccTLDs,


or we have decided to create separate country


pages for the same page.


On that case, obviously, new pages, older page


was having a lot of backlinks.


But now, new pages won't be having those backlinks.


On that case, how Google deals with backlinks to main page?


If we have expanded to different country-level pages.


Now, so for example, I have right now one page in.com.


And we have decided to go ahead with three separate countries,


because from them, we are getting a good number of leads.


So we have planned to go ahead with separate country


pages for those countries, like PK for Pakistan, IN for India.


But the problem is that older pages ranking in India.


And if I am introducing new IN page,


that won't be having any backlink.


But hreflang tag would be mapped properly.


Yeah.


So if you create new pages and they're not linked internally,


then we would see them as separate pages.


With regards to hreflang, what would happen there


is if we understand that these pages are part of a set,


and we see a user from a different country


doing a search where we would show that page in the search


results, then with hreflang, we would swap that out.


But by default, if you expand your website


to include more countries, then you're


kind of, in a sense, diluting the value of your pages


by expanding it across multiple country versions.


So you really have to keep in mind


that you should also focus on those country versions,


that you shouldn't just say, oh, I


can make 50 different country versions of my website now.


And you shouldn't assume that copying everything


onto 50 different versions will make it more visible,


rather than maybe even less visible,


because you're diluting the value across all of those.


So if you're adding individual pages,


then I would definitely make sure


that you have normal HTML links between those existing pages


and individual country pages so that we


can understand how those new pages kind of map


within your website.


And hreflang helps us a little bit,


but hreflang is not the same as a normal link on a page.


So on that case, internal linking is fine.


We will be doing it.


hreflang tag also we will be doing.


My only concern was that older page was getting the backlinks


from India.


Now there is new India page targeted for India market.


On that case, will hreflang tag swap all external backlinks


to new page?


It depends on what you do.


If you take that existing page and you link to your new India


page, then we can forward some of that value.


It's not the same as kind of redirecting or posting


everything on the existing page, but it does


spread some of that value.


So it's not the case that you have


to kind of work to get individual links


to all variations of all of your pages,


but rather that kind of spreads naturally


with the internal linking of your site.


Thanks.


Sure.


All right, let me see.


One, I guess, quick question here.


If I gain do follow backlinks due to paying bloggers


to write highly relevant review articles


or paying for high quality PR news articles,


are they page links that go against Google's guidelines?


So I feel like this question is asked a little bit pointed.


And I guess the quick and easy answer


is, yes, if you're paying people to create content with links,


then you're paying people for those links, right?


And if you're paying for links, then that


would be something that would be against our webmaster


guidelines.


So that's kind of the easy answer there.


Of course, if these links do not pass page rank,


if they have the no follow attached to it


or rel sponsored attached to it, then that can be fine.


That's essentially a way of advertising your website.


It doesn't pass any value to your website,


but it still helps users to find your content


and kind of indirectly helps to promote


your content and your website.


So maybe that helps a little bit.


Then a question.


I think there are two similar ones like this.


With regards to structured data types for tourism companies


in the schema.org website, there are different suggestions


for a travel sector, such as tourist trip, travel agency,


or trip.


Are the schema types mentioned above supported or relevant


for Google indexing and ranking?


If not, what would be the most suitable structured data type


for a trip landing page?


So it's important to differentiate


between the broader schema.org ecosystem, where there are lots


of different ways that you can add structured data


to individual pages, and the Google side of that


in terms of Google search.


So in particular, we support a subset


of the functionality or the different types of markup


from schema.org.


And those are the things that we would


show in the search results.


And everything else is essentially kind of, I don't


know, more like a nice to have, or more like something


where you're adding a little bit of extra information


to your pages.


But I would not expect to see any change in search because


of that.


And I think that refers to all three


of those types in that sense.


So what I would recommend doing is going to our search


developer documentation and looking at the rich results


types that we have listed there, and trying


to work out which of these types map to the kind of content


that you have, and then focusing on those types


first so that you have the visible effect nailed down.


And you know that if you spend time


on that specific kind of markup, you


will have a visible effect in search.


And then if you want to go further and provide


additional information through other schema.org types,


you're welcome to do that.


I would just assume by default that you would not


see any effect in search at all.


So there is a slight sense of, well,


we understand the pages a little bit better with more types


of structured data on our page.


But I would not assume that that's


something that would have a visible effect in terms


of ranking or better visibility in search.


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


OK, we're kind of running low on time.


So I'll switch to more questions from you all.


And I have a little bit more time afterwards as well


if any of you want to hang around a little bit longer,


ask more questions, or whatnot.


SPEAKER 1, John, I saw some tweets this week


with you and Gary about an old subject,


but it's still a favorite.


Domain names.


An old domain name, whether you're


going to have problems with it down the road


because you bought one that had bad content, bad links directed


to it.


I mean, the only way I know of is


to look through Wayback Machine.


But that will give you a sense, OK, maybe it was parked


or maybe it had content.


But could you ever really tell if it had links?


Is there a way to do that?


And then I guess the next step would


be to disavow if one needed to.


Yeah, I mean, to disavow, you'd have


to have the site verified in Search Console.


So if you have it verified, then you'll


also see links in Search Console.


So that kind of helps a little bit.


If you're still at the stage where


you're unsure if you should buy that domain name or not,


then maybe it makes sense to look


at some of the third-party link checking tools that


are out there.


I think there are a number of providers


that essentially crawl the web similar to how we do it


and provide some aggregate views of those domains.


And usually, you'll see that it matches a little bit what


you would see in the Wayback Machine, where you see, OK,


this is, I don't know, a small business.


And the links that you would find


are probably the kind of links that a small business might


have.


Or maybe it was a casino or some crazy affiliate site.


Then you can kind of assume that, well, probably the links


will also be similar in that regard.


Thank you.


Cool.


Hi, John.


I'll just jump in.


So I do have a question about how


Google's treating the date modified for certain articles.


So we've tested live blog posting,


and we've noticed that Google consistently either ignores


or cannot correctly detect our last modified date.


So what we tend to see is we've updated the post,


let's say, five minutes ago, and Google's still


showing in the service that it was updated or published


seven hours ago or four hours ago, something like that.


So I think this puts us at a competitive disadvantage.


We do have the proper markup in the schema.


Our front end does reflect the correct last updated date


timestamp.


And it's also in our site map.


So I'm curious if you have any insights as to how


we can resolve that one.


I'd almost need to see some examples where


we get that wrong so that I could pass that on to the team.


So one thing that's important is that we're


able to recognize the same date on the page as well.


So if you have a date set in the article structure


data for the modification date, then that


should be something that's also visible on the page as well.


So that's one thing to keep in mind.


The other thing is to watch out for time zones.


That's something that I've sometimes


seen where people will specify a date and a time on the site.


And we're kind of not sure about which time zone that refers to.


And then we can't match that correctly to the structure


data on the page.


So that's kind of another aspect that sometimes plays in there.


And I guess the third thing that I've sometimes seen


is sometimes we get it wrong in terms of maybe we'll


show the proper date in the normal search results.


And then in the, what is it, I think the top stories


or what are the different news blocks that we have,


sometimes we'll show a date that is several hours off.


And I believe we fixed that.


But if you're still seeing something


like that, that kind of like a different timestamp


is shown in different places in search,


then I'd love to have some screenshots of that happen.


Yeah, so we are seeing that as well.


So I'll definitely send those over.


I'll send you an email if that works.


I do have another question on the same topic.


So our live version also has this AMP component.


But for some reason, our AMP cache


doesn't update with our current updates.


And we've tried purging manually.


We've tried it over API.


And it should kind of work alongside with the updates


on the non-AMP version.


But for some reason, this is not at least


being accepted by Google.


So I'm curious if you have any thoughts on that as well.


I don't know how that is connected.


So my general answer there would be


to use the API to request those cache updates.


But it sounds like you're already doing that.


So I don't know what might need to be done there additionally.


Is that specific to pages where you're


updating things on the page, kind of like the live blog


situation?


Specific to the live blog.


So for other pages, we can request a purge.


And it will update.


It may take some time.


But it will update.


But for this live blog, for some reason, this doesn't take.


It does give us a 200 response and everything.


But we don't see any kind of changes on the AMP version.


OK.


Now, if you can send me some examples of that too,


that would be useful.


Thanks so much.


Hi, John.


If I may jump in.


Sure.


I have a problem with the site and submitting the site map


in Google Search Console.


When I try to submit the site map,


the Search Console will give me a generic HTTP error.


And when I have a look at the server log file,


then I can see that Googlebot can fetch the site


map with a 200 status code.


And I can load the site map from a web browser


using all the other tools.


The site map is structurally correct.


I've tested it using various tools.


And it's within the limits of 50 megabytes and 50,000 URLs.


So do you have any idea what I could


try to make a Search Console to accept and download


the site map?


It sounds like you're testing for most


of the important things.


One aspect that sometimes plays in there


is the topic around crawl budget.


I don't know if that's something that might apply in your site


in the sense that if we're having trouble crawling enough


from your website, then it might be


that we would deprioritize something


like that site map file.


But it's hard to say.


So what I would do there is either send me the URL


so that I can take a look or post maybe in the search help


forum so that some of the other people can throw an eye on it


and give you some initial feedback


and escalate it if need be.


Can I send you the URL in the private chat?


Sure.


OK, I will do.


Thanks.


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


You're welcome to kind of hang around a little bit longer


as well if you'd like to, but just


so that we have kind of a reasonable length


for the recording.


Thank you all for joining in.


Thanks for all of the many questions that were submitted


and that were asked here.


If there's something on your mind


that you still need to find an answer for,


I'd recommend going to the Search Central Help Forum


and asking the folks there.


The people there are pretty smart


and have a lot of experience with websites,


so they can generally help you along.


And they can also escalate issues


if something pops up that is completely weird or different.


So maybe that will help.


I'll set up more of these Office Hour Hangouts as well.


So if you want to join in one of the future episodes,


watch out for the, I think, the YouTube community page


is where we list them all.


And they're also on the event calendar


on the Search Central site.


All right, with that, I'll pause the recording


English Google SEO office-hours from July 2, 2021

All right.


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


Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


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


where people can join in and ask their questions all around web


search and their website.


Wow, looks like a bunch of people are still jumping in.


But maybe, as always, we can get started


with some first live questions.


And then we'll go through some of the submitted questions


on YouTube as well.


Let's see.


Nathan, I think you're on top of the list.


Thank you, John.


Hi.


So we are working on a website that uses hreflang.


And I've been trying to figure out what's going wrong,


because they're ranking in France with their Belgian pages.


They're ranking in France with some Luxembourg pages.


And I was trying to figure out what was wrong.


So one of the things I found out is


that they didn't make a general language page.


So there is no main fr page.


So that was the first suggestion I made.


But I was wondering, since they're currently


focusing on Germany alone, would they


need to have a DE then DE again?


Or is just DE enough if they're just focusing on Germany?


Just DE would be enough.


If that's kind of the broader level


that they want to target, like the German language content,


that would essentially be enough.


OK, but so they're selling in Germany alone.


It's not Austria, not Switzerland.


So I was wondering whether they need the DE DE as well,


or if it's just DE when it doesn't matter.


I think that's generally fine.


So with the hreflang, it would not kind of


hide it in the other countries.


It would essentially just, when one of these German language


pages is shown, we would use the hreflang


to swap out the URL for the more appropriate URL for that page.


So it's not that it would rank higher in Germany because


of that, but more it's like, well,


if someone is searching for the brand name, for example, where


we might have the French page and the German page,


and they could be equally relevant


because from the brand name alone,


we might not know which language version,


then we'd be able to swap to the German language


version for users who have their setup in German.


Yeah, all right.


I think I got it now.


Thanks.


Sure.


Let's see, Vahan.


Hi, Mr. Mohan.


I'm a director of IT at search engine in Germany.


So we are trying to fight issue with the Twitter embeds


on optimizing for core web vitals.


And as you know, it causes a lot of troubles,


like content layout shift, first of all.


Secondly, it does start loading all the resources instantly


on page load, whereas Twitter embeds are below the fold,


and one have to scroll to see it, right?


Does Google work with Twitter somehow to fix that issue


or has plans?


Because embedding tweets is a very common practice


across all the web.


Core web vitals is a very big focus for Google.


So I do think that it could be fixed with cooperation.


Google does not have any plans on that.


I don't know about any plans, but we essentially


don't have any special treatment for any other providers,


essentially, of specific content.


So it's not that we would say, oh, this is a tweet.


Therefore, we will let it do whatever crazy stuff it


wants with core web vitals.


But it is something where if a lot of sites


are using those embeds, it feels like it


would be in Twitter's best interest


to provide a way to enable people to embed those


in a reasonable way.


There was recently a conversation


on Twitter about this where someone mentioned


that they were using kind of, I don't know,


specific CSS setup to make sure that these tweets don't


move around that much.


I think it was something like minimum, maximum height


and width, something like that.


And apparently with that, they were


able to significantly improve things around CLS and I


think FCP as well.


So that might be something to look into to see


if that's an option there.


I mean, it's also something where


if you're embedding a lot of these from them,


then it's like going to them and saying, OK,


you need to get this working better.


Otherwise, we'll swap it out against something else.


That might also be an option.


SPEAKER 2


So you redirected from page A to page B,


and then afterwards you decide page A should remain indexed?


Yes.


Yeah.


And page B should drop out or?


Can either drop out or can stay alive.


So what would be a correct path to handle those scenarios?


So if the new page is not meant to exist,


I would just redirect back from that old page.


If they're essentially parallel pages that are separate,


then I would just leave both of them at 200.


You don't need to do anything special to kind of like revert


that.


That's similar to when you accidentally 404 a page,


then just making it work again is essentially good enough.


Gotcha.


Thank you very much.


Sure.


All right, Darcy.


Hey, John, how's it going?


Pretty good.


How about you?


Well, doing well.


So a question about the page experience update.


So in order for a page to benefit from the page


experience update, it needs to have all the marks, right?


It needs to have a mobile friendly HTTPS


and then either have needs improvement, I guess,


or good Core Web Vital Score.


Is that correct?


Yes.


So it needs improvement, but kind of like in or what is it?


I just envision your little chart


every time I talk about it.


Exactly.


That graph.


Yeah.


So if previously, before the page experience update,


you had a URL that was benefiting from HTTPS,


whatever little benefit that is, once the page experience


update rolled out and say that URL had a bad Core Web Vital


status, would then it have lost whatever little benefit


it got from HTTPS because now it doesn't qualify for the page


experience update?


I don't think so.


I mean, I haven't checked specifically on that.


But my understanding is that the HTTPS aspect would essentially


be parallel.


Sorry, meaning that you still hold on to it?


OK.


OK, cool.


I can cast one other just little small question.


Well, maybe small.


If I'm doing a site migration and in Search Console


I've executed the site migration to another Search Console,


am I to believe that it has not fully completed in Google's eyes


until those notifications in Search Console are gone?


Or will I get a new notification where


it says one of your other sites is moving to this site,


and on the other one it says this site is currently moving?


Do I have to wait for those to tell me something else


before I know that it's done?


Or will it just stay like that forever


until I click the Got It button?


Yeah, I think there is a timeout there,


but it's a Search Console-based timeout, which


is essentially something I'm not sure what the number is.


I think maybe it's 180 days or 90 days, somewhere


in that range, where essentially that status essentially drops


out.


But that's not a sign that the migration is complete.


I don't think we have any kind of internal status


like that, where we'd say this site has completely


moved over, because often they're


just like these lagging URLs that


are left for a pretty long time.


Got it.


OK, OK, so then I'm not waiting for the new notification


in Search Console, basically.


Exactly, yeah.


Wonderful, thanks so much.


Sure.


Ashwani.


Yeah, hi, John.


Hi.


Yeah, my question is related to language targeting.


The question is, can we put two different language


in a single content?


Suppose my content is in an English language,


and now I wanted to target Portuguese language


or a France language.


Can we include Portuguese plus English or French plus English?


Can we include these two languages?


So different language content on the same page,


is that what you're looking for?


For different directory.


I have a different directory of Portuguese language,


and I'm asking you, can we insert


something like 30% English content and 70% Portuguese


content?


Sure, absolutely.


So it doesn't create a problem, right?


Yeah, that's perfectly fine.


For languages, we primarily look on a per-page basis.


So we want, ideally, to have one clear language


on a specific page.


So that's something where if you have different pages


with different language, that's perfectly fine.


But it makes it a lot easier for us


if we have one clear language on a page,


because then we can clearly say, oh, this isn't French,


or this isn't Portuguese, or this isn't Spanish,


and show it to people appropriately.


OK.


And again, the same question related to suppose


I have an English content of 700 words,


and I just converted all those content into Portuguese.


So it is also like 700 words.


Now, I want additional 200 or 300 word content


in Portuguese language.


So does it reflect any changes in ranking,


position, and all that?


Does it impact our SEO strategy?


These pages would essentially rank independently.


So if you have some content in English


and slightly different content in a different language,


then we would just rank those pages independently.


So that's something where sometimes it


makes sense to have more content in a certain language.


Sometimes a certain language just


has more words for the same content or fewer words.


That's all perfectly fine.


No, I'm just like, suppose we have


a content in English language, and we


have a similar content which is in Portuguese language.


But additionally, I want to add a few more information


in Portuguese.


So I just wanted to add a few more.


So in that case, I'm asking you, is there


any problem to add a few more content in your Portuguese


language?


No, that's perfectly fine.


OK.


And does it like if I use a passive voice or active voice,


does it also matter in terms of ranking?


I don't think so.


I think that's more a matter of how people understand


your content.


But I can't see that mattering for SEO.


That's all.


Thank you so much.


And one more question is related to stability.


Like for a few keywords, my ranking is not stable.


Someday it is on a first page, first or second question.


Someday it's on fifth page or sixth page.


So what is the issue?


That can happen.


So I mean, search is very dynamic.


So it can certainly happen that sometimes a page ranks really


well, and then a few hours or a few days later,


it ranks a lot worse, and then it


ranks a little bit better again.


Usually when you see these kind of fluctuations,


it's because our algorithms are not 100% sure yet.


And over time, it will settle down somewhere in that range.


But it's not a sign that there's anything specifically


wrong or bad with that page.


That's essentially sometimes the algorithms are just unsure,


and they kind of switch between different variations.


Does revamping of website happen?


I mean, if you significantly change your website,


then our algorithms have to understand it again.


So that sometimes takes time.


OK.


Thank you, John.


Thank you.


Sure.


All right, Nancy.


Hey, John.


First of all, thank you very much for doing these.


Watch every week and really get a lot of value out of them.


I work with a lot of small companies,


and we try to apply all the SEO best practices that Google


lays out for us.


It's a little harder to do some of the fancier back end


code kind of things.


More of a content writer and SEO than a digital code guru.


How can I help these sites to rank well


when they're competing against these big enterprise


organizations that have a lot of resources and money and people


to throw behind their SEO and tend


to rank higher because they are enterprise corporations?


Do you have any advice?


Yeah, I think that's super hard.


So.


Just give up.


No, no, no.


But I think small companies have a lot of advantages,


especially online in that area, because it's a lot easier


for them to kind of shift and to move quickly


compared to large companies.


So I see that, at least within Google,


where when we come up with a really cool idea


that we should implement in Search Console,


it's going to take one or two years until we get there.


Whereas external SEO tools, when they come up


with the same idea, they'll be like, oh, I'll


just do this next week.


And it'll be done.


So I think as a small company, you kind of


have that advantage of being able to move quickly


when something shifts in the ecosystem,


when some new trends come up, when something, I don't know,


significantly changes.


You can move really quickly.


And you can be visible like that essentially immediately


in search.


Whereas with large companies, I mean, sure,


they have a lot of power, and it's like a strong brand


and all of that.


But they can't move as quickly.


And that, I think, is kind of one of the advantages


with a small company.


The other, I think, is something where, as a small company,


sometimes it makes sense to be active in areas that are just


not interesting for large companies, where you kind of


have the ability to focus on a smaller segment of the market


and kind of do something really unique there, which


the larger companies will say, oh, it's


so much work to actually get that set up


and to kind of prioritize that.


And then it's only like a $5 million business.


What are we going to do with all of that small change?


And as a small company, you're like, whoa,


it's like a couple million dollars.


That's fantastic, right?


So that's something where I also see, especially small companies,


kind of have the ability, especially


online, to focus on these small areas


and say, well, we'll do something really unique here.


And maybe if it picks up, a really large company


will also do something similar a couple of years down the line.


But we have that kind of headway, at least,


and can kind of move ahead of all of these big companies


during that time.


SPEAKER 2 OK, thank you. Can you give me an example of that,


what you mean by do something really unique?


SPEAKER 1 I don't know.


I kind of always struggle to find explicit examples


that we can mention there.


But I see it, for example, with SEO tools,


because I work together with the Search Console team.


And it is something where a lot of the external, or I don't


know, non-Google SEO tools essentially


have the ability to kind of do things


in ways that wouldn't really be possible on Google's side,


be it for policy or legal reasons or whatever.


And I think that gives these tool providers


a little bit of a kind of a heads up,


even in a market where, I don't know,


Google is like this giant corporation,


and they're even offering it for free.


But yet all of these small SEO tool companies,


or smaller SEO tool companies, still


have a chance to kind of grow a significant user base, which


is relevant for them.


So I mean, that's not something that I


imagine the average small business would


be creating SEO tools.


But it's one of those areas where


I tend to see that happening.


Thank you.


Sure.


Let's see, Praveen.


Hi, John.


How are you?


Hi.


So we got this multilingual website.


We recently launched it in April this year.


So apart from English, we got content for users in Taiwan


and for users in China.


Now, the issue is that when someone is searching


for this website on Google, like searching for the brand name,


the site links that they see in Taiwan, half of the site links


are in Taiwan language, and half of the site links


are in Chinese language.


And Taiwan users, they don't appreciate


that kind of behavior.


Their language is mixed with Chinese language.


So what we can do to fix this, we


have used hreflang tags properly.


We are using breadcrumbs to show the proper hierarchy


of these language categories.


We are interlinking relevant pages.


But what else we can do here?


Those are essentially the things that you would be doing.


So hreflang to make sure that we can provide the most matching


ones and a really strong internal linking


to make sure that we understand which of these pages


belong together.


And even in those cases, I've seen situations


where sometimes the site links are in different language


or for different countries.


And that's not something that you can control explicitly.


The only thing you could really do


is to noindex those pages that you don't want to have shown.


But then they're not shown anywhere,


which is probably not what you want.


AUDIENCE 1 Yes.


To add this, I think the domain is a.gg domain, which


is kind of country code domain for some country.


But also used by gaming websites.


And we are also kind of in the same industry.


So could that be an issue?


Like we are using this?


No?


I don't think so.


I think it's probably just something where


the site links are suboptimal.


And if you could point me to a screenshot,


I'm happy to pass that on to the team.


But these kind of things happen, I don't know, all the time.


Maybe not all the time, but from time to time.


And it's kind of annoying.


It settles down usually over a while.


But it's not something that you can explicitly control.


But maybe the site is new for Google.


Like it was launched in April.


So it might be Google is taking time to process all the links.


It's possible that it'll settle down.


Yeah.


OK.


Thank you.


Thank you for this.


Sure.


Sergio.


Hey, John.


I have a very specific question.


I'm working on a multilingual website.


And we've been using the hreflang tags in the sitemaps,


not at the page level, but sitemaps.


And let's say that the website is structured in a way


that the main tool and the main site


is completely multilingual.


And then there is a blog section that, at the moment,


is only one language.


But it will be multilingual.


And we have this situation in which we want to create sitemaps


per language.


So let's say we have the different blocks


of main language page and all the alternate tags.


So it would start, let's say, for the English,


then English, all the translations,


then the other sitemap, let's say German,


would have then first the German main version of the page


plus the alternate.


So I wanted to ask, one, is that a good practice?


Would there be any problem if that's OK?


And then the other question is, we have the blogs.


And the blogs, there are some blog posts that, of course,


are not relevant to other regions, other languages.


So some will have a translation.


Some other won't have a translation.


So can we pack all of those within one single sitemap


for each language that, for some cases,


would have a hreflang tag and the other one wouldn't?


So those two questions.


Now, so you can structure sitemap files however you want.


You can make them by language, by site section.


Essentially, it's totally up to you.


I would try to make them in a way


that they can be kind of stable with regards to the URLs


that they include.


So don't take all of the URLs from your site


and randomly put them into sitemap files,


but have some kind of a system to distribute them.


Primarily so that when we process one sitemap file,


we get kind of the same URLs back when we look at that.


More for the situation where we, like usually we


don't process all sitemap files all at the same time.


So if the URLs were to jump between sitemap files,


we might process one file and see one URL,


process the other file, and then see the same URL again.


And then in the end, we might miss some URLs


because it's randomly swapping between files.


But having it kind of persistent in any method


that you think is relevant for your site,


it can also be alphabetical or whatever you want to do,


is kind of that's the important part.


With regards to content that's only in certain languages


or that doesn't have any hreflang annotations for it,


that's also perfectly fine.


Like I mentioned before, not having the annotations


doesn't mean we won't show it for other languages.


But having annotations kind of helps


us to show the appropriate version.


So if you just have one version, then


that's the version that will show.


You don't need any hreflang annotations for that.


AUDIENCE MEMBER 1 OK.


Understood.


Thank you.


JOHN MUELLER Sure.


Let's see.


Tanush.


I got your name right.


Oh, no.


OK.


And Dave, in that case.


Hi.


It's an international day today, and another hreflang question,


I'm afraid.


Got a client I've been talking to.


They're having a problem.


They've got English in different regions of Canada, US,


Australia, UK.


They've got hreflang, which seems


to be working to share the right one, but rich results.


They've got product, rich markups.


That doesn't seem to get switched out.


That seems to be sticking to just the one version.


Is that the way it's meant to work,


or have they got something else going on


that we're not sure about?


How do you mean?


So the rich results, the stretch of data for products


seems to be coming from the US, the.com,


which is the next default. So they will


search for a product in the UK.


Actually, the UK does seem to sometimes pick up things.


They'll search one in Canada sometimes,


and it will show the US dollar result in rich results.


So basically, it appears to be taking the markup


from the default page from the one.


The US, if you check as well, is the canonical one.


So it's showing wrong prices, because obviously, US


and Canadian dollars are different,


as are Australian dollars.


So it gets a little bit confusing.


I'm not sure if that's just the way it works,


or they've got something else going on.


OK, so you mean within the normal web result,


the rich results markup in there?


OK, so not like the product search separate.


No.


OK.


So what's probably happening there


is we're seeing these as duplicates,


and we're picking one of those versions as the canonical,


and then using hreflang to swap out the URL.


But since we have one as a canonical,


that's the one where we pull the rich result information from.


Yeah.


So that seems kind of unfortunate


that we would kind of pick one canonical


across different currencies.


I mean, it literally is just the price and maybe a number


that's different on the page.


So it's entirely understandable that it is deduced,


but it just makes it kind of awkward in this situation.


If you can send me some examples where that's happening,


I'm happy to pass that on to the team.


Because usually, we do try to recognize


when things like phone numbers or prices


are different across different versions and say, oh, we


shouldn't kind of like deduplicate these pages


because they are unique.


So if you have some examples, I'm happy to look at that.


But sometimes, when it's really just the currency symbol that's


different across these pages, then it


can happen that our algorithms say, well, this


is almost exactly the same page.


We should just make it easier for the site owner


and treat them as one page, which in this case,


makes it more confusing.


But yeah.


OK.


I'll have to chat with them, see if they'll share some.


Cheers.


Thanks.


Cool.


Let me run through some of the submitted questions


as well so that we don't lose track of any of that.


And we'll have more time for your live questions


along the way as well.


Let's see.


We're going to relaunch Migrate our site.


A few important pages won't be ready for the launch,


but will be added later.


How should we handle these pages?


Should we leave them as 404 and redirect later?


How long until they lose their SEO signals?


Should we redirect them to a less fitting page


and later to the right one?


So yeah.


I think this is kind of tricky.


One of the things that I would try to do in a case like this


is try to leave the old page up as much as possible


so that we see that part of the website is moving,


but also part is still there.


And that way, we can kind of transition the old URL


to whatever new URL ends up being there


in a consistent way that we don't have


any kind of gaps in between.


If you do need to kind of move everything over


and you're saying the old page is really not relevant anymore


and we need to create something completely new,


then a 404 is certainly a possibility.


If you're sure that the new page will be up within a day or so,


a 503 might also be an option, which


you're kind of being almost sneaky and saying,


well, the page doesn't work at the moment,


and then Google will retry it a little bit later,


and then suddenly the page is there and ready.


So that might be an option if you know


that it's just a day or two.


A 404 can also work, but there you kind of


have a situation where the page ends up dropping out


of the index completely.


And when it comes back, we essentially


have to rebuild the information that we know about that page.


So it's not that the information will be lost forever,


but it takes a bit of time to rebuild again.


So those, I think, are kind of the options.


My preference would really be to try to at least keep


the old page there until you can swap it out against the new one.


So keep it out of 200 if you kind of absolutely


need to keep it.


If you need to redirect it and have


the old version on the new site, I think that's also OK.


If you need to kind of really remove


the page for a longer period of time,


the 404 is kind of the right choice,


but you have to assume that it'll take a bit of time


to catch up with you.


I'm looking at merging two brand websites where one brand will


overtake the other.


However, there'll be a 90-day window


where we run both sites announcing the merger.


What's the best way to set up schema as an early indicator


that they're essentially the same site before we 301


redirect and ensure that the primary brand is what's


ranked as the secondary brand resolves,


like a canonical for the entire website?


So the suggestion of a canonical is probably a good approach


here.


With the rel canonical, you're essentially telling us


that this content is equivalent to the other one,


and you prefer the other one to be the primary version.


I think the downside of using a rel canonical in this situation


is that we will already start migrating the search results


over to the new version of your site.


So users would still be able to see both of those versions,


but in search, essentially, the new version


or the primary version would start


to become more and more visible.


And it might be a little bit awkward


if someone is looking explicitly for the old version.


But with the rel canonical, you can kind of


set that up ahead of time before you start doing the move


as well.


Otherwise, there is no kind of way


of using structured data markup to say, well,


we're going to merge in a certain period of time.


The other thing to keep in mind when you do end up


doing the kind of merging of the different sites


is that merging and splitting sites


tends to take longer than just a pure redirect from one domain


to another.


So that's something where I would


expect a little bit of a longer time, maybe a couple of months,


for things to settle down around search before it actually ends


up working, that kind of like everything is moved over


to your preferred site.


Does Googlebot read information on a page


if it's in a toggle, a small symbol


that you click on which opens up with more information?


Can you recommend a helpful step-by-step video


for beginners to implement structured data?


So if the content is within HTML,


then essentially we'd be able to use that for indexing.


On the other hand, if the content


needs to be loaded after someone clicks on this toggle,


then we would not know that you have to click on this toggle


to get that information.


So those are kind of the two variations there.


One way to try this out is to just open the page in a browser


and then look at the source code and see,


is that information already loaded or not?


If it's loaded already, then most likely it


will be available for indexing.


If it's already on the page and your website is already


being shown in search, a simple way to check


is also just to search for that piece of text in quotes


and to see if Google can find it.


With regards to getting started with structured data,


I am not aware of any kind of simple getting started


guides for structured data because I


think it depends quite a bit on the way


that you have your website set up.


So that's something where if you're working with pure HTML


and you're doing everything manually, then


going to the developer documentation


is probably a good idea.


You can copy and paste the examples there.


If you're using an existing CMS or a hosting system


like WordPress or Wix or something like that,


then oftentimes there'll be plugins


that you can just enable for the site, which make it a lot


easier for you to add structured data in a way that


doesn't require you to actually do any of the code part itself.


So that's kind of the direction I would head,


where I'm going to assume that you use something


like WordPress or Wix or Squarespace


or something like that.


I would try to find a plugin or a simple way


to just activate that within your website


and then just fill out the fields


and let the plugin do the structured data for you.


Can backlinks from low-quality websites


make a negative impact on a blog's SEO?


And do user comments have any effect on page ranking?


So just backlinks from low-quality websites


usually we will just ignore those.


I don't think that would have any negative effect


on a website's SEO.


What would be more problematic is


if you go out and actively buy a significant amount of links


for your website or kind of do something else, which


essentially goes directly against our webmaster


guidelines.


So that's something where I'd say that's problematic


and that's something I would avoid doing and clean that up


if you notice that happening from someone who previously


worked on your website.


But if you're just seeing random low-quality links


to your website, I would totally ignore those.


They absolutely have no effect on this site.


And regarding user comments and page ranking,


if these are comments on your website,


then the primary effect that I would expect from that


is essentially that sometimes user comments do


provide a lot of value additionally to your content.


And sometimes those comments can be used for ranking as well


in search.


So if someone is searching for something


that is only visible in a comment on your website,


then your pages could be visible because of that comment that


is also embedded on those pages.


So essentially, it's a way of having content


that is available on your pages.


It's just not content that you wrote yourself.


But at the same time, it's also something


where if these user comments are really low quality


and they drag your site's overall quality down,


then that is something that we would also


see as a part of your website.


Where we say, well, we look at your website overall,


and we're not really sure about the quality of your website


overall.


And our systems wouldn't really differentiate between, well,


this is content you wrote, and this is content


someone else wrote but happened to leave


in a comment on your website.


A number of our pages can rightly


be classified as an FAQ, a how-to, and an article.


Should we add all three types of schema.org structured data,


or is it better to just choose one?


So I think there are two aspects here.


From our guidelines, we want to make sure


that the structured data you have on your page


matches the primary element on your page.


So if you're saying that you can add an FAQ to a random page


on your website, sure, you can do that.


But is this FAQ the primary part of the page


or relevant for the primary part of the page?


That's something that you need to figure out.


So that's one aspect.


The other aspect is that in the search results,


some of the rich results types we can combine, and some of them


we can't combine.


So for example, if you have a recipe and you have ratings,


then we can often combine that in the search results


in one rich results type.


However, if you have an FAQ and you have an how-to, then


at least from what I recall what these look like,


these are things that wouldn't be combined


in a single rich result type, which


means our systems would have to pick one of them to show.


And maybe we'll pick the type that you would have chosen


or maybe you would have a different preference


on your side.


And if you have a strong preference on your side,


I would just make that super clear to us


by just providing that kind of structured app.


So if you're saying, oh, the FAQ results,


I really like those for these pages, super relevant here,


but it's also kind of an article and kind of a how-to,


then I would just focus on your preferred one,


kind of the FAQ in that case.


Or if you're saying the how-to is really


the way that I want to have this page shown in search,


then I would focus on that type.


As I understand it, internal links can path authority.


And that authority can be divided or diluted


as more internal links are added to the page.


Is this another SEO myth, or is this roughly how it works?


If so, does that mean that having


a lot of internal links on a page


could do more harm than good?


So yes and no.


I think in the sense that we do use the internal links


to better understand the structure of a page.


And you can kind of imagine the situation


where if we're trying to understand


the structure of a website with the different pages that


are out there, if all pages are linked


to all other pages on the website, where you essentially


have a complete internal linking across every single page,


then there's no real structure there.


It's like this one giant mass of pages for this website,


and they're all interlinked.


We can't figure out which one is the most important one.


We can't figure out which ones of these


are related to each other.


And in a case like that, kind of like having


all of those internal links, that's


not really doing your site that much.


So regardless of kind of page rank and authority


and passing things like that, you're


essentially not providing a clear structure


of your website.


And that makes it harder for search engines


to understand the context of the individual pages


within your website.


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


And similar to the second question


that you had there with regards to lots of internal links


doing more harm than good, yes, if you do kind of dilute


the value of your site structure by having


so many internal links that we don't see a structure anymore,


then that does make it harder for us


to understand what you think is important on your website.


And I think providing that relative sense of importance


is sometimes really valuable because it gives you


a little bit more opportunity to kind of fine tune


how you'd like to be present in the search results,


where if you tell search engines pretty clearly and directly,


well, this is my primary page.


And from there, you link to different categories.


And the categories link to different products.


Then it's a lot easier for us to understand


that if someone is looking for this category of product,


this is that page that we should be showing in the search


results.


Whereas if everything is kind of cross-linked,


then it's like, well, any of these pages could be relevant.


And then maybe we'll send the user to some random product


instead of to your category page when they're actually looking


for a category of products.


Let's see.


Regarding images on a website, how


do you find the perfect balance between maintaining


high image quality as well as making sure that images


are lightweight and load fast?


It seems that both of these things


are encouraged by Google, but they both take away


from each other.


Yeah, I don't know if there's ever a perfect balance.


But especially with regards to images,


there are lots of things that you can do,


especially with the responsive images setup in HTML,


where you can essentially specify different image


files for different resolutions and, through that,


make it possible that when users load a page, for example,


on a mobile phone, they'll get a page that loads really quickly


because it has optimized images for that device size.


Whereas when a user loads that page with a really large


screen, we can swap out and show the higher resolution images


as well.


So that's something where the whole responsive image


is set up.


I think is a really good idea.


The other aspect here is also that a lot of the modern image


formats that are out there, I'm thinking of WebP and AVIF.


I don't know how to actually pronounce that.


Where you essentially have ways of providing


really high quality images at a fairly high resolution with not


that bite-sized price that you would usually


have for really large images.


So those are all different options that you can look into.


There's also image lazy loading that you can use,


where if an image is below the fold, you can say, well,


the browser doesn't need to load that image until the user


scrolls it into view.


So there's lots of things that you can do there.


And I think what is kind of interesting specifically


about images and SEO is a lot of the things that you can do


are very technical and things that you


can measure fairly clearly.


Where you can take Lighthouse or one of the testing tools


and just measure the page as it loads,


and see how large is that page, how many bites


need to be transferred, and really kind of work


with the numbers rather than working


with that black box of SEO, where you tweak some things


and then wait a month or so to see how the rankings evolve.


What's your vision for the future of SEO?


I don't know.


Good question.


I don't have that five-minute answer on the future of SEO.


I think one of the things that people always worry about


is everything around machine learning


and that Google's algorithms will


get so far as to automatically understand every website


and SEO will be obsolete.


Nobody will need to do that.


I don't think that that will happen.


But rather, with all of these new technologies,


you'll have new tools and new ways of looking at your website


and making it maybe easier for you


to create really good content, to create clear structures


for your website.


Similar to how things have evolved, I think, the last 10,


20 years as well, where in the beginning,


you would write your own PHP code and craft your own HTML,


and it was a lot of work.


And over time, all of these CMSs evolved,


where essentially anyone can go off and create a website


without having to really understand any of the HTML


and kind of server-side basics.


And I think that evolution will continue


and that there'll be more and more tools available.


And you'll be able to do more and more things in a way that


kind of works fairly well for search engines.


And it's not that the SEO work will go away,


but rather it'll evolve.


So maybe instead of can tweaking h2 tags and h1 tags,


you'll just kind of delegate that


to a CMS that makes sure that the most important content is


already included as a heading on the page.


OK.


Since page rank is a finite resource,


is it a good idea to preserve page ranking using PRG


pattern for not important pages like privacy policy pages?


So the PRG pattern is kind of a weird trick


to make something kind of work like a link,


but actually not be a link.


And it uses things like posting to the server,


and then the server does redirects and all kinds


of weird things.


From my point of view, you absolutely


don't need to use any of that.


If you want to make sure that a link does not pass any page


rank, then use the rel="nofollow".


If you want to make sure that a link works well,


then don't use the rel="nofollow".


That's essentially my perspective on that.


So I would not go off and create these kind of fancy constructs


where you're doing things like posting and redirecting