to the new one.


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

That would help us to figure this out a lot faster.


But at the same time, if you want the old product


to remain available in the sense that if people search


for the old product, they can find replacement parts


or kind of find manuals, those kind of things,


then you don't want to completely remove


the old product.


The solution that we generally recommend


for this general kind of problem where you have one product


and then you have a replacement for that product


is to reuse the old product URL for the new product


and move the old product content to kind of an archive section.


That way, you kind of build upon the success of your old URL.


And you add the new content there,


kind of the new product, the new product description,


new pricing, or whatever you have.


And you still have the old product information.


And you just move the old product information


to an archive section where it's a little bit less


visible, kind of less strongly shown in the search results


because it's a new URL.


So that's kind of the general situation or general direction


that we would head with something like this.


I imagine for e-commerce sites, that's really kind of tricky


because it's hard to kind of move one product


to an archive section and reuse the old URL with maybe


an article ID and things like that that


are associated with it.


But that's generally the direction that we would go.


We would also use this for recurring events.


So if you have something like a yearly conference,


then instead of creating new URLs for every year,


then instead use one stable URL for the conference


and move the previous years to an archive section


so that kind of in both of these situations,


you're building a stronger and stronger URL


for the persistent version for that product.


And you're moving the old things off


to URLs which are a little bit weaker within your website


so that they're less emphasized in search.


And structured data, I don't think structured data


would play a role here at all.


So using kind of this setup with regards


to structured data of kind of like saying,


well, these are connected like this,


that's not something that we would use at all


for this kind of canonicalization


or figuring out which one of these URLs


is the one to show at the moment.


Hey, John.


Sorry, go ahead.


I actually wanted to ask a structured data question.


I thought I'd put it in the comments,


and I'm not seeing it anymore.


So I noticed that some of the Google structured data


requirements can be a little bit more


requirements there than what schema.org requires.


I work for an educational institution,


and we want to have content structured data around that


talks to our degree programs, especially


for use in Google colleges and universities.


But I noticed that in the structured data list,


there really doesn't seem to be a good type for full degrees.


In fact, some of your structured data types


specifically say it's not full degrees.


Do you have any recommendations there,


especially given that sometimes when we test out


some of the schema.org structured data types,


we get notification from Search Console that, hey,


this thing is not parseable because it's not actually


Google's structured data type?


Yeah.


So I don't know specifically about that kind of structured


data, but in general, it's certainly the case


that within schema.org, there's a lot more structured data


that's available.


And we only take a small subset of that


and use that directly for the rich results in the search


results.


If you use other parts of schema.org,


which we wouldn't use in the rich results,


we would still try to understand that.


But it's not that we would show it in any particular way


in the search results.


So kind of going past what we would use directly


is certainly an option.


But I think for the most part, you


wouldn't get any visible effect from that.


So that's kind of the starting point there.


Within the structured data testing tool,


I believe the structured data testing tool


sticks a little bit stricter or aligns more


with the schema.org markup.


And the rich results test is really


based on how Google would show that in the search results.


So it only uses a subset of the general structured data


that we would find.


With regards to which one to best use in a case like yours,


I don't know offhand.


So many different types.


But I would generally try to, first of all,


see if there is a type that is actually


shown in the search results that matches what


you're trying to achieve.


And then focus on that, which would


be what we would have documented in the developer documentation


for search.


And if there's nothing there that works for you,


then you can use the schema.org markup.


But I wouldn't expect a lot of visible results from that.


So in particular, we'd use this to better understand


those pages.


But if we can already understand that this is kind of like


a course, or there is information about an educational


setup thing here, then that's something we probably already


have that information.


And we don't need a lot more information


about that to be able to show those pages in search,


because we're already mapping them to the right queries.


Whereas if it's kind of ambiguous,


then that's something where extra structured data helps us


a little bit.


SPEAKER 2


I was really thinking about it, especially in terms of Google


colleges and universities, assuming


that there would be a heavier reliance on structured data


for that application within Google.


And I didn't know if that was something that, in my research,


I haven't found anything that specifically says yes,


but I kind of made that assumption that that would be


used moving forward.


I don't know.


So I think the tricky part is I think that's something


that we only show in the US.


So that's something where I don't see them in search,


and it's really hard to get some firsthand experience with that.


But I don't know exactly how we would show that


or where we would get that from.


But that's something where if it's not


documented in our developer documentation,


then I'd assume that we don't use the structured data there


directly.


SPEAKER 1


Thank you.


SPEAKER 2


Sure.


OK.


Is it true?


Oh, go for it, Mihai.


SPEAKER 3


I have a quick follow up to that example


you gave earlier with the same URL being reused for products


that get out of stock and things like that, events.


I was also thinking about how you would apply that


to the classified site example I gave earlier.


Would you be able to do something similar,


given that most URLs are being created by actual users?


So it's user-generated content.


But it's likely that a lot of ads


are very similar in what they have to offer.


So when one expires, would it be possible to maybe redirect


or use a rel canonical to add a new ad from a different user


that basically sells the same product or service?


Would that be a good sign?


I think that might be a bit confusing for users.


But having something like tag pages or category pages,


that seems like something that would work better,


where if you have a category page for this brand of car,


and you swap out the classified ads that you have,


so that this category page remains


relevant for the long run, then that's


something that we could probably pick up on and use like that.


But for the individual classified ads,


that seems tricky to determine that connection.


So it's very easy to say, oh, based


on this one keyword and the old classified and the new one,


I would just redirect it to something else.


I could imagine that gets a bit confusing.


Yeah.


Yeah, it could be.


So having listings or category or tag pages


is probably a better way to target those type of ads.


John, a question for you about linking from those category


pages and putting a relational tag on the links themselves.


Because it's user-generated content,


would you recommend putting the UGC relation


from the category page to the actual description page?


Or is the UGC tag irrelevant?


I wouldn't use it there, because you're


kind of linking to your own content.


And within the classified ads, of users' ad links,


then that's something where I'd use the rel UGC.


So it's not kind of for situations


where you're linking to user-generated content,


but rather where the user-generated content links


to other places.


Great, thank you.


OK.


And now an HTML5 question.


Is it true that HTML5 semantic tags, like main article,


et cetera, are very important?


One SEO expert said that HTML5 structure


is used by Google for fast understanding of the page


content before analyzing hundreds of other factors.


So we do try to understand the structure of a page,


but we can understand the structure of a page


in lots of different ways.


So it's not that HTML5 kind of section tags


are something that we would use specifically


when it comes to SEO.


And it's not that you have a ranking advantage


over other sites if you use things like main or article


elements within your pages.


So I think it's good to use proper HTML in general


so that it's a clear page.


It works well on lots of browsers.


It works well for users with disabilities.


But it's not something that, from an SEO point of view,


we would take into account.


And one of the reasons why this is sometimes


this is kind of the case is that these technical details are


things that users often don't even notice.


And it wouldn't make sense for us


to rank pages based on things that are essentially not


noticeable by users in that sense.


So that's something where you might load a page,


and it uses an old table-based layout,


and it hasn't been updated in 10 years,


but it's still the right content, relevant content


for the query that you are looking for.


It wouldn't make sense for us to say,


well, this other page has content


that's kind of OK as well, and it uses HTML5 properly.


Therefore, it must be a much better result for users.


That's definitely not the case.


So I think it's good to focus on clean HTML.


It makes things a lot easier for your site in general.


But I wouldn't see this as a primary SEO ranking


factor in that if you're struggling with ranking,


you need to fix your HTML markup because, in general, that's


not going to change anything when it comes to ranking.


Oh, wow.


And a long question, I think, with regards


to purchasing a website.


Can you explain the situation that


happens when you purchase an established website,


merge most of the content into your existing website,


and then 301 from the purchased websites pages


to the migrated content?


In principle, I would have thought


that the final single website would be some of its parts.


However, I've assumed that this is maybe far from the case.


Yeah, so in general, moving from one domain to another


is something that's fairly straightforward in that we


can take all of the old signals and forward it to a new domain.


That's kind of the simple part of a site move.


Similarly, if you move from HTTP to HTTPS,


that's something we can just take everything one to one


and pass it on to the next setup, the next domain,


kind of the next protocol version.


That's essentially the straightforward type


of site move.


But as soon as you do things like restructuring a website


within the same website, like merging multiple websites


into one website, splitting one website


into multiple separate websites, that's


where it gets a lot more complicated.


That's where essentially our algorithms


have to reprocess the whole website


and understand what is this new website that we have,


or these new multiple websites, if it's


split into multiple websites, and how do they


fit in with regards to the rest of the general ecosystem


on the web?


How should we understand how relevant some of this content


is?


Which of these pages can be kind of understood


a little bit better with the new configuration?


Which of these pages might be harder to understand


with the new configuration?


And that's a process that can take


a significant amount of time.


So in general, if you're looking at various changes


on a website and one of the options


is, oh, I will restructure everything,


or I will merge multiple websites,


or split one website into multiple websites,


then it's good to keep in mind that those are long-term


changes that will take a lot of time to be reprocessed.


You might see this as something that kind of slowly goes


from one state into the other.


You might also see it as something


where it's like we start to see this complete restructuring,


and then we say, oh, my god.


Everything is different.


We have to be careful here and try


to understand this new website first, where you see


a significant dip until we're able to kind of stabilize


on a new kind of better understanding of the website


in general.


So that's something which is really


hard to predict ahead of time, how these things will happen.


I think it's just important as a site owner


that if you're considering any of these options,


that these are things that will take a lot of time


and where you may see significant changes


in fluctuations until things settle down


into a more stable state.


And that stable state doesn't necessarily


mean that it'll be the same as before in that if you


restructure a website significantly


within the same website, you might see better results


later on because you have a cleaner structure.


Similarly, you might see worse results


because maybe the new structure is worse.


If you merge multiple websites, it


might be that you have kind of a stronger visibility in the search


results, but it might also mean that while you're


merging multiple things and they're kind of merging


in ways that are clashing with each other, which


are resulting in kind of a similar search


visibility to before, where you had multiple websites showing.


Now you have one website showing,


but it's kind of shown in a similar way in the search


results.


So this is something where it's really


hard to predict ahead of time what exactly will happen.


And it's definitely not the case that you can just blindly


assume that this one plus that one will equal the new one


because you're creating a completely new website, which


we have to essentially understand completely first.


So that's something where it's like, I'm not saying nobody


should do these kind of moves.


Sometimes you have to do them just because things are


changing within your business.


But it's good to kind of be cautious about these kind


of moves, and especially to see this as something


that you don't want to do just to try it out and see


what happens.


So if you're aware of one of these moves


needing to be done in the future,


then try to kind of do that in one step


so that you have everything moved over to the final state


so that you don't run into a situation where, like, oh,


I will merge everything first, and then I


will split it off again, and then maybe I'll


restructure part of this again.


Because all of those individual changes,


they will require a significant amount of time on their own.


So ideally, try to find the stable approach that you


can keep for the long run and focus on moving things over


to that.


Is Zulu time for a news sitemap OK?


So particularly with regards to publication date,


so Zulu time is if you have a Z at the end of the time, which


is essentially, I had to look it up, it's kind of, what is it?


GMT time, so essentially a specific time zone,


which it refers to.


From our point of view, using a specified time zone,


like if you have plus and then a number of hours or minus


and a number of hours is fine.


Using the Zulu time is also fine.


Those are both well-defined time formats that work well for us.


So they're equivalent from our point of view.


The examples that you have in the question


are not quite equivalent because they're different times


and different days.


But essentially, you can use either one of these formats.


You can also use some URLs with the Zulu time,


some with the offset.


That's totally up to you.


The one thing I would watch out for here


is to try to be as consistent as possible so that you don't end


up in a situation where you specify one time in the sitemap


and use a different time zone on the pages themselves.


So that's something that we sometimes see, especially


when it comes to news content.


On the pages themselves in the news article,


you can also specify a time.


If you specify the wrong time zone in one of these places,


then we'll be kind of conflicted.


Or if you specify the time zone in one of the places


and you don't specify the time zone in the other place,


then that's also one of those situations


where we don't perfectly know what you mean.


So if you're using any way of specifying the time zone,


then I would make sure to be consistent across your website


so that it's really perfectly clear to us


when we look at your pages, this is the exact point in time


that you're referring to.


Not that we have to guess, like, oh, the server


is located in this place.


Therefore, probably they mean this time zone.


So we'll guess that that's the case.


Really kind of be as clear as possible


if you want to specify something like this.


We use Data Studio for several reportings.


Now we recognize that URL impressions plus click-through


rate and sometimes not even URL clicks sum up


as visible in Search Console.


How is this possible?


What are we doing wrong?


Is it possible to get the correct data in Data Studio?


So I think there are a few things that are possibly


happening here.


It's hard to say exactly what you're seeing.


So on the one hand, the fresh data


currently isn't visible in the APIs


and appropriately not in the Data Studio.


I think that's also based on the API.


So if you're looking at things from today that kind of


happened in the last week, for example,


in the performance report in Search Console,


then that would not match what you would see in the API.


We're looking at ways that we can add kind of the fresh data


to the API as well in ways that don't confuse


the consumers of the API.


Because one of the tricky parts with the fresh data


in Search Console is that this is data that's not really


finalized yet, where it might be that we have to clean things


up.


And that's something that happens


in the pipelines along the way.


So sometimes you'll see the fresh data


shows this many clicks and impressions


for a period of time.


If you look at that a few days later,


you'll see a different number there.


That's just because that data has


been finalized at that point.


And if we were just to blindly inject the fresh data


into the API as well, then all of those people who are always


trying to get the newest data with the API,


they would be working with the fresh data, which could end up


in situations where that data has even stronger mismatch


to what is shown long term in Search Console.


So we're trying to find a way to make that a little bit easier.


The other thing to keep in mind is


that the aggregation of the counts that


are shown above the table in the performance reports


and the individual rows which are shown


are aggregated separately.


So it can happen in situations where the count on top


is slightly higher than the count


if you add up all of the rows.


Sometimes that's due to the privacy filtering.


Sometimes that's just due to the way that we aggregate the data.


In general, the higher count is the more accurate one.


So if you see a higher count in the sum above,


then that's the one that I would focus on.


If you see a higher count in the rows shown below,


then that's what I would focus on.


But that's something where the different aggregation methods


that are used in Search Console, they


can be a bit confusing in the UI.


Sometimes we regularly have people ask us about that.


But they're certainly also confusing


if you're using the API and comparing the API results


to one of those sets, either the numbers on top


or the rows that are shown.


So that's something where you might see differences


because of that.


MIHAI APERGHISLAMOORTHY-SINGH CAMPBELLO That's actually a good


official support article on how aggregation works,


the property aggregation versus page aggregation


if you take the rows and just look at the pages.


So I found that to be useful as well.


Oh, yeah, definitely.


Yeah, that's the other point, which also makes it tricky.


Like the property and the URL and the query aggregation


are sometimes a little bit different as well.


It gets really hard when you have a lot of data.


And all of these aggregations, they become pretty tricky,


especially for larger sites.


And one place where I've seen the differences more visibly


is if you have a larger site and you


look at a very small section of that site,


then because those small numbers are a bit out


of the aggregate from the larger site,


you might see bigger percent-wise changes there.


Oh, wow, we're running towards the end of time.


So I'll maybe shift things over to questions from you


all before I have to jump out of the room here.


Yeah, hi, John.


Just a quick question about URL inspect


in Google Search Console.


The thing here is that because we actually


have been through a couple of migration,


so we take the same product URL and tested it.


And then we found out that the current page that we have live


doesn't have any canonical URL from Google.


But the rest are pointing to a URL that doesn't really exist.


So what is pointing to a URL?


So it's pretty much the same URL that


is live without a trailing slash.


So it gets a 301 redirect.


So we don't really know how Google


comes about in picking that URL to start with because it's


never used on the site.


I don't know.


It's hard to say without looking at a specific example.


If you want to copy the URL into the chat here,


I can take a look at that afterwards.


Yeah, sounds great.


Yeah, I can do that.


OK, cool.


Yeah, super.


And just a very quick question, another one.


On referring page also in URL inspect,


so we notice that we are getting a referring page


from a different domain that seems


like a spammy domain that are redirecting


a couple of times to our page.


And Google actually referred that as a referring page.


Shouldn't Google only pick the referring page


within our domain only?


No.


If we can pick up a URL from other sources,


we might show that too.


But it's not going to be the case


that this is negatively affecting your website


because it's like some spammy domain that's


linking to your website, but rather it's just


we happen to have initially found the URL there


and we started crawling from there.


So it's not a sign of any kind of quality issue there.


It's more from a technical point of view, we found it


and we picked up on it and tried to index it like that.


OK, but if we disavow it, for example, then should we be?


That wouldn't change anything for those URLs


that we've already seen because once we've


seen URLs from your website, we've indexed them


and noticed that we can index them,


then we'll continue to try to index them.


If you disavow it, it basically just tells us


we shouldn't be passing any signals to that URL.


But from purely an indexing point of view,


from the inspect URL point of view,


that would probably remain there.


All right, any other things?


Sure.


Hello.


Hi.


Yes, I'm running a movie website and we've


been working with the shima.org review for quite some time.


And it worked for like two or three years.


But after the recent Google update,


we keep getting warnings in our Google search


console that the review item is not supported.


Even if the markup is correct in the rich results test.


And I was just wondering before we change 900 reviews,


what should we do?


Is there any thing for movie websites


that are not selling anything but are just reviewing movies?


I don't know offhand.


But I do know with regards to the,


I believe it's the review markup or one


of the other types of structured data markup,


we started sending out more warnings about situations


where we see that websites are using it incorrectly.


So it's not that there is going to be manual action


or going to block these, but more it's just, well,


this isn't aligned with our guidelines.


So we want to let you know that this currently


isn't supported like that.


And I would focus on the documentation


that we have on the developer's guide


and see if there is a type that matches what you're doing.


But I don't know if we're going to have


something specific for movie sites, for example.


OK.


Thank you very much.


Sure.


All right.


I need to take a break here.


Someone waiting for the room.


So thank you all for joining in.


The next one in English, I think, will be on Friday.


And on Thursday, we have another one in German lined up.


So if you're keen on joining, feel free to jump in there.


Thanks again for dropping by, and hope to see you


in one of the future ones.


Right to be forgotten interactive video game: Round 1 - Peter

Want to know more about what a Google reviewer looks at when assessing a Right to be Forgotten request?


Put yourself in the reviewer's shoes and play this interactive game.


Side note, not sure what Right to be Forgotten is? Check out our explainer video first.


Now, back to the game.


Round 1. Answer each scenario by pressing your keyboard number keys.


For mobile and tablet users, play by clicking the timestamp in the description below.


Question 1. Meet Peter.


Peter is running to become a member of the city council.


He was involved in a recent scandal after making racially offensive comments at a restaurant.


He has now requested this information to be removed from search.


Should you delist the information about the scandal?


For yes, press 1.


For no, press 2.


Because you haven't answered, incorrect.


Peter's scandal should not be delisted.


Here's why.


The voting public can legitimately consider Peter's activities when judging his fitness for office at the city council.


That means we'll always consider the role the person holds in society,


their activities, the level of influence, and the significance of their public position.


We also look at if and how the information relates to the public role.


For instance, purely private information about Peter's life may not be relevant to a public position.


But this recent scandal regarding his racist comments is relevant to this particular public role.


Let's try again.


Press 3 for the next question.


Time is running out.


You've left it too late and gone backstage.


If you selected the other answer, you would have been...


... correct!


Well done!


Peter's scandal should remain on search because...


... the voting public can legitimately consider Peter's activities when judging his fitness for office at the city council.


Ready for the next question?


Press 3.


Question 2.


Ten years later, Peter has left politics completely and is now a landscaper.


He wants his past political search results to be removed.


Should you now delist Peter's past political results from search?


For yes, press 5.


For no, press 4.


Because you haven't answered...


... incorrect!


Pages discussing Peter's political past can now be delisted. Here's why.


Peter has left his public role for good and is no longer active in politics or a similar field.


However, please note, if someone is likely to run for election again or this person is still in the public eye,


we'll often keep information about them available to ensure that voters and others can find relevant information about them.


Another vital consideration, which we always consider, is content age.


We assess whether the information contained in the search result is still relevant.


Better luck next time!


Press 6 for the next question.


Time is running out!


... correct!


Press 7 for the next question.


Question 3!


Unfortunately, Peter's landscaping business is not going well and he had to file for bankruptcy.


Very recently, tax authorities published a list of creditors who Peter's business owes money to on the official government website.


Peter immediately requests this information to be removed from search.


Should you delist the information on the government website?


For yes, press 7.


For no, press 8.


Because you haven't answered.


Incorrect!


This information should remain findable on search.


While Peter may want to keep this information private, we need to consider why, when and where it was published to make a fair review.


Government records play a crucial role in keeping society informed.


The government's decision to keep publishing material online and keep making it available via search engines is a strong indication that the public should still know about it.


In such cases, we defer strongly to such a decision and in this case, the information relates to a business that Peter still runs.


So it is relevant to his role in public life.


Press 9 to jump into the final summary.


Time is running out.


Press 9 for the final summary.


You've left it too late and gone backstage.


If you selected the other answer, you would have been...


Correct!


You made the right call!


Ticking


the time.


Good work!


You've completed round one of the Right to be Forgotten game.


As you can see from Peter's scenarios, making decisions about delisting in Google's search


results isn't as easy as you might think.


Please note that none of the factors we mentioned are absolute.


Frequently a case presents considerations that point in different directions, and we


will carefully consider all of them before making a decision.


To discover more about our policies, see our Right to be Forgotten explainer video, and


for a deep dive, check out our Help Center article in the description below.


Thank you for playing round one of Google's Right to be Forgotten game.


Be sure to look out for round two.


Find the link to round two in the description below.


English Google Webmaster Central office-hours from January 7, 2020

All right, welcome, everyone to today's Webmaster Central Office


Hours.


My name is John Mueller.


I am a webmaster trends analyst here at Google in Switzerland.


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


where people can jump in and ask any question


around their website and web search.


And we can try to find answers for them.


Thank you for joining the first one of this year.


I hope you have a fantastic year,


that the year works out well for you,


lots of exciting things coming up,


and that you're successful at whatever you're working on.


But I guess we can get started with questions from you


all to keep things going.


So if anything on any of your side is burning


and you really need to find an answer,


feel free to jump on in now.


Afterwards, I'll go through some of the questions


that were submitted.


I'll take a crack at it.


OK.


Well, it's not burning really.


But since Barry mentioned the URL parameters tool,


I'm still curious over what exactly


does the representative URL option mean,


since it's not really documented in the official talks?


I looked this up last year when you asked, and I forgot.


So I don't know.


I need to double check.


My understanding is we just pick one URL


as a representative for that set and index it like that.


But I don't know what exactly came out of looking things up.


So do you mean like a session ID parameter?


Should the representative URL often


be chosen for a parameter like that?


Or I would assume for a session ID,


we would drop that parameter completely.


Because usually accessing the URL without a session ID


as a part of the query string shows us the same content,


and it's a cleaner URL.


So we would probably just drop that completely.


Right, but if you like to set it up in the parameters tool,


is that the option you would choose, the representative URL


option, or just let Googlebot decide?


Or if you had to use the tool?


I don't know.


I haven't looked at it this year.


So your guess is as good as mine this year.


That's funny.


John, I have a question.


There's been a lot of chatter about reconsideration requests


after manual actions taking longer than usual.


Is that true?


I mean, obviously, people have been away for the holidays,


but.


I don't know about longer than usual,


but sometimes they do take quite a bit of time


to be reprocessed.


So there's no backlog that your team is experiencing


when you have to hire more people to get through


these support requests?


I mean, if it takes longer, then usually that's


a sign of a backlog.


But I mean, it's not the case that we kind of artificially


delay things with regards to reconsideration requests.


Sometimes what just happens is that the team works on this


in batches, and they will go through one


set of reconsiderations and then go through the next set.


And depending on how they batch things,


it might be by country or it might be by type of issue.


Those kind of things.


So that's something that sometimes happens,


and sometimes you see that with regards to the backlog


or kind of the time that it takes to process things


where suddenly a whole bunch of things


will get reprocessed fairly quickly,


and then it takes a while again for things


to kind of catch up again.


OK.


Thank you.


All right.


So let me go through some of the questions


that were submitted.


And as always, you're welcome to jump in in between


if there's anything that you'd like to add or more information


that you need.


Can you target English speakers in the US and UK


using the same content but with relevant hreflang tags?


For example, example.com slash US English page 1 or GB English


page 1.


Content is the same, not geotarget or anything.


Yes, you can do that.


I don't know if that's kind of the best use of your time


or your website in general, but you can do that.


If you want to create separate pages for individual countries


and they're all the same language


and you have hreflang set up, then you


can set it up like this.


What will probably happen in practice


is we will recognize that these pages are the same.


They are essentially the same.


And we will just index one of those pages as a canonical.


And then we'll try to use the hreflang annotations


that you have to show the appropriate URL in the search


results.


So we'll pick one canonical for that set,


and we'll focus our crawling and indexing on that canonical URL.


And when we show it to users, we'll


try to swap things out with the appropriate hreflang tags.


So it's something where you can do that.


From an indexing point of view, we just


pick one of those pages anyway.


So you could theoretically save yourself the trouble


and just have that one English page.


But essentially, that's up to you.


On larger sites, sometimes it's really hard


to separate out the content and to create separate content


versions for individual countries.


But for maybe other parts of that site,


you do have clear different country versions.


So sometimes that's just kind of a side effect there.


I wouldn't recommend doing this kind of as a thing on its own.


So don't just take an English website


and split it up into different country versions


and hope that you have any advantage from that


because essentially, you're just giving us a lot more work.


We have to crawl all of these different country versions.


We have to recognize that they're all the same.


And we'll swap out the URLs in the search results


and try to get it right.


But it's not guaranteed that we'll always get it right.


So you're creating a lot of extra overhead


and you're probably not going to get a lot of value out of that.


On the other hand, if the rest of your site


does have appropriate country versions


and you have some pages that are the same like this,


then that's not something I would lose any sleep over.


MIHAI APERGHISLAYA-SINHAVIORIYA MOHAMMADIYA 1.20.


So we're working with a website that they have a Romanian


version and an English version.


And that's because most of their business is in Romania.


But they do have one offline location


somewhere in Europe, which is why


they have the English version.


So the site has HREF-Lang tags set up


between the English and Romanian versions.


The problem is that about, not half,


but a big portion of Romanian users,


when they download Chrome, they usually download


using the English version.


So it's automatically set up to go to Google in English


rather than in Romanian.


So they keep getting the, when they're


searching for the brand name, they


keep getting the English version of the website, which


is not that ideal, even though they're in Romania.


Now, one solution I can think of is simply


add an additional HREF-Lang tag like en-ro.


So to make sure that they do get to the Romanian version,


not to the English version.


But other than that, other than actually


forcing or forcefully redirecting them,


I'm not sure what we can do about that.


Because we don't really want Romanian users


to get to the English version of the site from Google.


Usually, what I recommend for things like that


is to show a banner on the page so that users,


when they go there, they have a banner in their language


or where the banner clearly says,


if you're coming from Romania, here's the Romanian version.


That's usually the recommended approach.


I think flagging a page as saying English for Romania


and then it's actually in Romanian,


that would probably be a bit tricky


because we do try to recognize the language of the page


as well.


And if you're telling us it's English,


but it's actually recognized as being Romanian,


then there's a chance that we'll just ignore that hreflang value.


So that's something that might be kind of making it tricky.


But in general, also, especially with Chrome and other browsers


where when you download it and it kind of defaults


to the English US settings, that's


something that we do try to catch


when it comes to localization.


So especially on Google, when you go to Google


and you have kind of the default default browser settings,


then that's something where we say, well,


this is kind of the absolute default version.


And there's a chance that maybe this user didn't explicitly


choose the English version, but rather it


was kind of installed like that by default.


So that's something where we do try


to figure out which of these versions


is actually the right one to show.


But especially for brand queries,


that's something where I could imagine


it's really tricky for us to recognize what language


they're actually looking for.


So for things like that, I try to do more with just


like a banner or some other way to let people know


about the appropriate local version.


Theoretically, you could also redirect


to the Romanian version, but that


might make people unhappy who explicitly


want to go to the English version of a local website.


Right, well, we've checked analytics


for this issue specifically.


So one problem is a big portion of users.


So it's not just like 10%, 5%, 10%.


It's like 30%, something like that,


of Romanian users get to the English version.


And the vast majority of them then


choose to go to the Romanian version.


So it's basically not an ideal situation.


It's an extra step for them to take in order


to get to where they actually want to get.


So if you're part-time or wider considering Google?


Would redirect them actually posting a banner


in case they did actually want to see the English version


and maybe something like that?


No.


Would the redirect mess up any of your signals


or a 302 redirect, something like that?


I mean, it wouldn't mess things up for us


because we would probably crawl from the US anyway,


so we wouldn't see that redirect.


But it could confuse people.


I mean, another approach that you could take is to put


the language into the title tag so that when people search


for the brand, they see explicitly


like English or whatever the Romanian word is for Romanian


so that they can make that choice themselves.


But I would tend to focus more on a banner


rather than forcing a redirect.


But that's something you can also test.


Set up a banner and see if people actually click on it


or not.


Try it out with a redirect.


Maybe have a banner then that lets


them go back to the English version if they want.


And then you can test both of those sides.


I'm not sure what you mentioned about the title tag


because it is set up like this.


So you have the brand name and the Romanian description


of the shop, then the brand name and the English description


of the shop.


But obviously, it's just one of them showing up


in the search results when you're searching for the brand


name.


So it's not like users can choose one or the other.


Well, in that case, you probably don't need to do anything.


Yeah, let's do that.


Yeah, thanks.


Sure.


All right.


If you have a real estate site that


has listings in various countries,


do you need an hreflang tag for the listings as well?


The listings will technically not


be translated because they're totally different.


So in such a case, the hreflang tag


will only be used on a subdirectory,


like the language version.


Yeah, if these are different things,


then the hreflang tag would not be appropriate here.


So the hreflang tag link element, I guess,


is only relevant if it's the same thing


and you have a version for one country in one language


and the same version of that thing for a different country,


different language.


But if these are completely different things,


like one is a radio and the other is a car,


then you wouldn't have the hreflang links


between those pages.


For category pages, it definitely


makes sense for the home page.


Maybe for some marketing pages, that definitely makes sense.


But in your case specifically, I'd


say for the individual items, it wouldn't make sense.


It's also something where you have


to consider the amount of work that's


required to set up this hreflang annotation between pages


and to maintain that annotation.


And if you're not seeing the wrong traffic going


to individual page types, then it's


probably a sign you don't need to set up


the hreflang annotations.


So that's something where I'd really


try to save yourself the trouble of just setting it up


for the sake of having to set it up, because you're not


going to see any ranking advantage for the hreflang


annotations.


It's just that when we do show one of those pages,


we'll try to show the appropriate one.


I'm a product expert over on the Google News Publisher Forum.


I'm hearing more and more publishers


reporting that they're either being outranked


by sites that are scraping and republishing their content


or being scraped in the scraper sites appearing on Google


with their articles hours before Google indexes and surfaces


the original content.


What advice can you give for publishers


experiencing these issues?


What can Google do to try to help these publishers?


PS, DMCA complaints, removals are too after the fact


to be effective for news sites.


So I would still do DMCA kind of complaints if you can do that,


if that's something that makes sense


in your legal environment.


Obviously, that's something that depends a little bit


on the legal situation.


You can't just randomly send them out to people.


But that's something I would definitely still do,


even if that's afterwards, because that's something


that we do try to understand on a bigger picture scale as well.


So that's definitely one thing.


The other thing where I guess the second part


of your question, where when scraper sites are appearing


hours before the original content appears,


that seems to be more of an issue


that we're actually not crawling and indexing


the normal content as quickly, rather than kind


of that these scraper sites are doing something different.


And most of the time, that's due to technical issues,


in the sense that if we can't crawl and index a site that


quickly, if there's something making it hard for us


to crawl a website, then it will take longer.


So that could be things like we're not


able to understand where the main hubs of a new site


are, where the category pages are, where the main home page


is.


And we get lost crawling all of these different URL parameters


or different parts of the website.


And we don't, through our normal crawling,


we don't run into the new content as quickly.


And for things like that, you can


do the normal SEO things, like making sure


that you have fewer of these pages


out there that you don't want to have indexed,


we don't get sidetracked with all of this,


making sure that you have a clear structure set up


with canonical URLs, that you don't have too many URLs


leading into different parts of the site,


and then making sure that you have proper site maps set up


in a way that you will flag new URLs as quickly as possible


when you publish them, ideally with a correct last


modification date in the site map file.


Because that does help us to understand when new content is


published.


So those are kind of the main things.


Then obviously, with regards to the server


that we can crawl as quickly as possible,


we need to have a server that responds fairly quickly, that


doesn't return server errors.


So those are kind of the, I'd say, kind


of technical baseline things.


One of the difficulties that sometimes plays a role


is that sometimes things get stuck on our side


as well, where we try to crawl sites fairly quickly,


and then sometimes things kind of get backlogged a bit


in some of our pipelines, and then suddenly we're


like a few hours behind in crawling sites.


And that's generally pretty rare.


I think that has happened maybe last year a few times,


but I know the team is working to try to avoid that.


And that's not something that you can really work around.


And when I ask the team about things like that,


and ask them, are you going to improve this?


And they're like, of course.


We see this as a bug.


It's not something that we're doing on purpose,


that we're crawling sites slower.


In any case, it's more that, well, sometimes things


break on our side as well, and then it gets a bit slower.


So that might be some of that, what you're seeing there.


The first part of the question is


something that's really kind of hard for me


to answer in a general way.


It's like when a scraper ranks above your original content,


that's something where I really need to see more examples.


So if you want to send me some example URLs, some queries


that you see, especially kind of the timely things


when you see them popping up in the forum,


I'd love to pass that on to the team,


because that is something that they do also


care about as well.


One tricky aspect there is also that sometimes a site might


technically be a news website, but that doesn't mean


that it's a really good website.


And trying to understand that difference is sometimes


a bit tricky, but I'm pretty sure you've seen that


in the forums quite a bit, that people will say,


I have this great news website.


And you look at it, and it's like,


you can hardly read the English, and it


looks like you copied it from somewhere else.


It's like, eh.


Right, right.


I'm talking more about sites that actually


have original content.


They have something good, and then some scraper


ranks above them.


And it's just so disheartening for the publishers.


Yeah.


I mean, if you can send me some examples,


I'd love to pass that on to the team.


OK.


What's the best way to send those to you?


You can drop me a note on Twitter.


That's probably easiest.


Let me just drop my email address here in the chat.


And anything, essentially, when you


see these things coming up in the forums,


and it feels like it's kind of timely,


then send those over my way, and I


can chat with the team to see what we can do to improve that.


OK, great.


Thank you very much.


Sure.


All right.


When going through a change of address,


what's the preferred amount of time


to keep 301 redirects in place from the original domain?


What kind of ranking disruption should be expected


as a result of the change?


So technically, 301 redirect is a permanent redirect.


So ideally, you would keep that forever.


I think as a minimal baseline, what I recommend


is at least a year, because what can happen on our side


is, depending on the URLs, it can take up to maybe a half


a year or so for us to crawl all URLs on a website.


So if you give it a year, then at least we've


seen that redirect twice across all


of those URLs on the website.


Practically speaking, I would try


to keep it longer still.


So especially if this is a website that you've built up


over the years and you're moving to a new domain,


then I would try to keep that redirect in place


as long as you can so that anyone going to that old domain


will still get a redirect.


And even if that's a couple of years later,


the other reason why I would try to keep that redirect up


as long as possible is to make sure


that you don't accidentally drop that domain


and some spammer takes over your old domain,


and suddenly they're putting spam


out that looks like it might be associated with your brand,


or at least with your previous brand.


And that's something that is always kind of awkward


because you don't have control over that domain anymore,


so you can't really fix that problem.


But at the same time, it looks like you're


putting all of that spam out there, which


is not really what you want.


So ideally, keep that redirect as long as possible,


and definitely try to keep the old domain as long as possible.


Yeah, sorry.


Go for it.


I'm guessing this kind of depends also if there are any


Google will likely crawl those old URLs


less rather than finding links.


Yeah.


I mean, any time you're moving domains in our documentation,


we also have that step of going out and trying


to get all of those old links updated so that they point


at the kind of new location as well.


But it's always awkward when you see kind of spam ranking


with your old domain name.


So I try to keep that as long as possible.


And if you decide to reuse the domain name yourself


for something else, then that's something


a little bit different.


I'd still give it that one year at least with the redirects.


But then at least it's still under your control.


And kind of what you put out there


with your previous brand name attached to it


is still something that you can control.


So that's a little bit less of an issue, I'd say.


I'd like to know how representative the sample is


of the data of clicks in Search Console for a big site


with lots of users.


The site has many more URLs and queries than the 50,000 a day.


And there's no way of knowing how representative that data


sample is when you exclude brand queries.


That goes on a little bit.


And YouTube cuts it off.


So essentially, we do try to show as much as possible.


And for very large sites, it is possible


that you have more queries than the 50,000 a day.


That's the limit.


Or the 50,000 data points that we have there a day.


Not quite sure where that number is.


But that's something where for most sites,


we try to get as much as possible.


We filter things out like queries


that are only done on a very rare basis, which


could potentially be kind of private information


in the queries.


So we try to filter that out.


For very large websites, we try to show essentially


the bulk of the queries there.


And at some point, we'll cut it off and say,


well, these are queries that just have fewer URLs.


So we kind of cut it off there.


So that's generally how that set is put together.


With regards to how representative that set is,


I don't know how you would quantify


how representative that is.


It's essentially as much information


as we can give there.


What sometimes do where I think you can probably


get a little bit more information is


if you have a subdirectory set up or a subdomain set up,


then verifying those sections of the site


separately sometimes give you kind of the full set


of information for each of those sections.


So that might be one thing to try out there as well.


Can you explain how Google calculates the average position


in Search Console?


Search Console uses a weighted average with impressions.


The documentation doesn't explain it in depth.


We actually have pretty good documentation


on how the average top position is calculated.


So I would double check that Help Center page.


I think it's called What Are Impressions, Clicks,


and Position, something like that in the Search Console Help


Center.


So I try to dig that up.


Essentially, what happens is we have


two ways of looking at this information.


On the one hand, we look at it per URL.


And on the other hand, we look at it per site for each query.


So the per query thing is essentially,


if someone is searching for something,


and multiple of your pages would rank for that particular query,


then we would take the average of the topmost position


and use that.


Whereas if you're looking at it on a per URL basis,


then obviously we use the average position


of that particular URL.


So what can happen, for example, is


if you have things that are shown as site links,


you might have maybe your home page as position one,


and individual pages otherwise on your site


that are listed as position five or six in the site link


section.


So on a per query basis, we would count that


as position one.


On a per URL basis, for the individual things


shown in the site links, we would count that as position


five, because that's where that one particular URL is shown.


So if you compare across per query and per URL basis,


then there will be a difference.


And that's essentially based on that.


So that makes it a little bit tricky.


From my point of view, I think it's fine to separate it out


like that.


But I think it's something that, especially with a larger site,


you really need to be aware of how this data is put together


so that you can compare these results a little bit easier.


So that when you look at Search Console and you see one number


shown on top and then one number from the table,


and you look at it in a different way,


like you filter things out, and you see different numbers,


then that's something where you kind of need to understand


this is not like Search Console trying to mess with you,


but rather this is essentially a side effect of how things


are counted in Search Console.


All right.


Subdomain, subfolder leasing.


Wow, OK.


This gigantic question.


I am going to have to cut this a little bit shorter, I guess.


So I think we've gone through this for a number of times.


So I don't really know how much more I can say here.


Essentially, I think what kind of the question comes together


is sometimes large websites take a part of their website


and they essentially rent it to other sites,


or they let others place ads essentially


on that part of the website.


And sometimes that shows up in search


because it's content that's on websites.


And there's lots of back and forth


on whether or not that should be OK, or that should not be OK,


or how that should be treated.


And I think they're just different points of views


out there with regards to how that can be seen.


So this is a gigantic question with lots of statistics


and examples in it.


So I don't really have anything specific to add there.


But I think, in general, this is something


where, when it comes to search, there are always


different ways of looking at things.


And there are different ways of looking at it and saying,


well, this is a good result, or this is a better result.


And people can have different opinions on this.


So that's something where I wouldn't see this


as a clear black and white thing where this is always bad


or this is always good, but rather


that we, with our algorithms and the engineers that


are working on the quality side, we


need to find the appropriate way of showing


this kind of content in search.


And sometimes it makes sense to show it very visibly.


Sometimes maybe it doesn't make that much sense.


Maybe we need to find other ways of recognizing


high-quality search results and showing that appropriately.


So from that point of view, I don't


think we'll have a clear black and white answer,


like you're always allowed to do this,


or you're never allowed to do this,


or you'll never see this in search.


But rather, over time, as we get feedback on our search results,


we'll try to improve things the way


that we can show them in search.


Hello, John?


Yeah.


Yeah, hello, everyone.


Can I ask two questions?


Sure.


I have the first one is about the sponsored link attribute.


I've seen four months or so.


You announced, guys, all the different user-generating


content and role sponsor and so on.


So I have analyzed a few sites, and I've


seen that just a few of them, pretty much the biggest ones,


use this attribute.


But most of the common sites still don't use it.


So I don't know.


My question is, do you recommend using it for media reach


and things like that?


Or what would be the most common using of these attributes?


And the second?


Well, I don't know if I asked the second.


Yeah, just, yeah.


So I would try to use them as appropriate.


So it's something where I wouldn't


say you need to revamp your website immediately


and switch to whatever kind of link


attribute is most appropriate for your specific use case.


If you're using nofollow and that's working for you,


then that's fine.


If you're setting up a new website


and you have user-generated content,


then maybe using the rel UGC is kind of the right approach


there.


From our point of view, we don't see the more specific types


as something that is required from a website.


So it's not something that we wanted to push out and say,


like, hey, everyone needs to change how


they're working with this.


But rather, it can give us more information


if you are more specific.


So going forward, if you can give us


more correct information, that would be great.


If you don't want to update your website to do that,


then that's also fine.


So it's not a critical thing that everyone must do.


Right, got it.


Thanks.


And the second one, please, is imagine


you have a really large website and you


generate thousands of URLs with, let's say, Team A and Team B.


Imagine it's a betting website, sports betting.


And obviously, you have the generic sport betting category,


let's say football, basketball, tennis, or whatever.


And then you have Team A versus Team B. Usually,


people is always searching to bet just


for the specific category, not for Team A or Team B.


Wouldn't make sense for, I mean, what


is the most correct way to proceed during this case?


Just getting the main category page of the sports betting


as a to follow with the right canonical tag,


and then the rest of the Team A, Team B with a no index.


Or the whole bunch of URLs of the website,


that could be half million URLs, all of them indexed.


And when it's Team A versus Team B with the right canonical


to the right category, which is the best practice?


Essentially, that's up to you.


So that doesn't really help you in your specific use case.


But it's something where you're balancing


having concentrated content on your site, where you're saying,


I only have 10 pages because I focus on the category pages,


and the rest of the pages are no index,


or they have the real canonical set to those 10 pages.


That's fine if you want to concentrate things together.


But it might also be fine to say,


well, these specific individual items


are things that people are looking for,


and I want to provide that information in search, where


you say, well, I will expand and show those pages as well.


And that's sometimes more of a strategic decision


rather than a pure SEO decision, because you


can have fewer pages, and they can be stronger.


So they could rank better for more competitive queries.


On the other hand, you could also have more different pages,


and they rank more in the long tail queries.


And finding that balance between content


for the competitive area, where you have fewer pages that


are focused on that, and also covering the long tail area


is something like finding that balance is sometimes tricky.


Sometimes that's also something where you can test it out.


And you can say, well, for this one specific event,


I will only create category pages, fewer pages,


and see if that works well.


And for the other one, maybe I'll


create a certain amount of long tail pages


Right, yeah.


The thing with that is with the long tail queries,


we already generate content for covering them.


So it's kind of they do cannibalize sometimes.


You know, so that was my, I don't know.


Yeah, I mean, in that case, I think


you have the answer there yourself.


If you already cover those long tail queries well,


then make sure your important pages


are kind of in that competitive area, where


you're really concentrating the value on those core pages.


Absolutely.


Thank you very much.


Sure.


Do they do unnatural queries like a site colon?


Are they also counted in Search Console performance reports?


As far as I know, they're not counted.


At least I haven't seen them in any of the reports


that I've looked at.


So from my point of view, I think


we try to filter those kind of things out.


We also try to filter a lot of other kinds of more unnatural


type queries out.


Oftentimes, these fall out automatically anyway,


because very few people use site colon queries to search.


If you publish news content, but sometimes


unpublished after discovering that your editorial guidelines


have been breached, would a 410 help speed up


the removal from search so that you


don't have thousands of readers landing on a 404 page?


Submitting to Google for a removal option


can take a long time.


So I think for news content, probably 404 or 410


doesn't make any difference.


So I would say that you can save yourself


the trouble of trying to special case that kind of situation.


The URL removal tool would probably be a good approach


here.


The URL removal tool, if you have the site verified


in Search Console, usually takes effect in less than a day.


So that's fairly quick.


With regards to general news content like this,


where you really want to make it clear that you did not mean


to publish something like this, I would still return 404


and maybe show some kind of information on that page


and say, well, this article doesn't exist,


or whatever you would want the user to kind of guide them


to the existing content on your website.


But I don't think you would see any advantage of using 410


versus 404.


So from a practical point of view,


so from a theoretical point of view,


410 generally falls out a little bit faster for normal web


content.


Like if we're crawling things every couple of days


and we see a 410, then that generally


falls out a little bit faster.


From a practical point of view, that difference is very minimal.


So compared to the amount of effort


that you need to kind of special case the situation of returning


410 for this particular type of situation


where a page no longer exists, I would just save myself


the trouble and just return 404 normally


across all of those pages.


So that difference between 410 and 404 is sometimes overrated.


Let's see.


If we have a backlink from a site that


has declining traffic, is the value of that backlink


devalued in the eyes of Google as a result


of the decline in traffic from the site


that we have the backlink from?


If so, should we disavow?


So first off, you do not need to disavow any links


just because you think that maybe the site is not


getting as much traffic as it used to.


So definitely no need to disavow anything like that.


If these are natural links to your site,


if these are normal sites that are linking to your website,


there is nothing wrong with that.


There is no need to disavow anything like that.


I remember way in the early days when


we had PageRank in the toolbar, people would be like, oh,


do I need to ask people to remove links to my site


if their PageRank is three or PageRank is two?


It was like, low PageRank links, they will cause my site harm.


And that's also not the case.


So just because a site is not as popular or not as popular


as it used to be, that does not mean


that that link from that site is in any way bad


and that you need to in any way react on that and say,


oh, this is bad, I need to block it from Google.


So that's something where I would really look at it more


as this is a link that I kind of placed there a couple of years


ago when I didn't know better and I can't contact the web


master anymore or they don't want to remove it anymore


and I don't want to take it into account,


then that's something you might want to disavow.


Or if you had someone do that on a large scale,


like go out and buy a ton of links, and now you


have a manual action on your website for link spam,


then maybe that's something you'd


want to disavow to kind of help clean up.


But just because that site is not as good as it used to be


or it doesn't get as much traffic as it used to,


that is definitely not a situation where


you need to disavow anything.


So I would really use the Disavow tool only in those


cases where you do have a manual action when it comes to link


spam or when you look at your links


and you're like, Google is going to catch me and give me


a manual action next week kind of thing.


That's another reason to use the Disavow tool to kind of


preemptively catch that.


And those are really the primary use cases of the Disavow tool.


Definitely not for things that just aren't as popular


as they used to be.


Another really common variation of this question


is, what if I got a link from a page in a language


that I don't understand?


Do I need to disavow that?


And that's also not something that you need to disavow.


It can happen that you get a link


from a website in a completely different language.


And it's a normal link.


You don't need to block that.


Can Google detect if my content is the same,


even if I change my WordPress theme


or even if I modify my HTML5 structure?


Sometimes.


So a lot of times, we can recognize


that the content is the same.


And if you're moving things around on your website,


you move things from one URL to another,


and for whatever reason you can't set up redirects


properly, then we will try to recognize that and treat


that more as a move rather than a completely separate URL.


So that's something we can kind of do.


But obviously, if you're moving things around on your website,


using a redirect is much cleaner and makes it much easier


for us to recognize what's actually happening there.


The question goes on, I guess, in a different direction.


Some people copy my content.


Is Google prepared to know that my content was the first?


And if so, what happens if I then modify my article


to add some more paragraphs?


Will Google still consider me as the author?


What would happen if I changed the authority of an article?


So I'm not quite sure how you change


the authority of an article.


But in general, we do try to recognize original content


and show that appropriately in search.


That doesn't mean it will always rank first.


So that's something that I see quite a bit with our blog,


for example, in that we will publish a blog post,


and it's all fantastic.


And then Barry goes out and writes a blog post


about our blog post.


And then suddenly, Barry ranks for our content,


which from one point of view, you're like,


why is this guy ranking for our content?


But on the other hand, he adds a lot of value to those pages.


And those are completely valid pages.


And it makes sense sometimes to rank those above our content.


So just because someone else who is writing about your content


or using parts of your content ranks above your content


doesn't necessarily mean that something is broken


or that there's something wrong there.


So sometimes it's just, well, other people


write about the same topic, and they


quote some of your content.


And that's perfectly fine and valid.


My question about backlinks, I was reading some articles,


and I commented on that article.


As we know, mostly when we comment on an article,


they take our URL and our name.


So I put my name, not the company name,


and the company URL.


And now the problem is they're showing my content


on the latest comments page, and the latest comment


is showing on all pages of their site.


So now I have 33,000 backlinks coming from that site.


Is this a sign of backlink spam or something


that I should disavow or do something else?


So if this is a legitimate comment on a site,


then that's not really backlink spam.


That's essentially a comment that you placed on a website.


I think it's a slippery slope in the sense


that people sometimes take this and say, oh,


if this is a natural link, then maybe I


should go out and comment on 100,000 sites


and get 100,000 links.


And then at that point, our algorithms


will probably say, well, all of the links


are links that the person placed themselves,


so maybe we should kind of ignore those links.


But if these are individual comments that


are left across the web, you're interacting


with the rest of the web in comment sections,


that's completely fine.


A lot of cases, these kind of comment links


will be with a nofollow or with a rel UGC nowadays anyway,


so it's not that we would take those links into account


when it comes to ranking.


But we would still show them in Search Console


when you look at the links report in Search Console.


So we also show nofollow links there.


So I guess circling back, just because suddenly you


see a lot of links from one website


doesn't necessarily mean that there's


anything bad that's happening there


or that you need to disavow that website.


If those are natural links, those are natural links.


There is nothing to disavow about that.


We have a directory site that's been online for nine years.


We've collected 5 million reviews


and had rich snippet local business review star ratings


display for more than eight years.


Around December 6, these went away,


yet we have no manual action against us.


And need to cut the rest of the question off.


Let me see if I can reload.


Let's see.


Where are we?


Here we go.


We're stumped while competitors remain intact.


Can you provide us some insight?


So it'd be kind of useful to know which site specifically


you're looking at there.


Maybe if you can post in the forum, we can take a look there


or other people can take a look.


We did change some things with regards


to the review star ratings when we showed them


in search with regards to kind of what type of reviews


we would show.


So that might be something where you're seeing those changes.


And those kind of policy changes, from our point of view,


they can happen over time, where we say,


well, this is something that didn't work out so well,


so we're going to change the way that we show them in search.


And that's not necessarily something


where if you're implementing it that way


and we decided that way is not something


we want to show in search, then that's


essentially something we wouldn't show in search.


With regards to competitors remaining intact,


sometimes people implement rich results in the wrong way.


And that's not necessarily something I'd recommend copying.


So if your competitors are implementing them incorrectly


and they're still being shown, then my recommendation


would be not to just blindly copy the wrong markup


that they're doing, but rather to kind of leave it at that.


OK, wow, we're running really low on time.


So maybe I'll just open it up for any questions from any


of you for the last couple of minutes.


Yeah, I have a quick question.


Is there a reason we've got a pretty big website that's


about 200,000 URLs and it's also being dynamically created


site maps every day, I think closer to the end of the day?


In the last month or so, I've really seen the last red


numbers go down in Search Console in terms


of how often all of our different site maps are red.


It usually used to be like every day or the other day


and now it's just really flagging.


And I didn't know, since we're creating so much new content


day in and day out, it's pretty crucial that it's


being read all the time.


Is there any way, one, is there any reason why that's happening?


And two, is there any way we can help improve that?


Thank you.


Yeah, I'd almost tend to post that in the help forum


to try to get some more eyes on it


because it might be that there are ways that you can improve


the structure of the site map.


It could be that maybe we're just not catching up


with the amount of crawling on the website itself.


It could also be that just from the kind of content


that you're creating, we're looking at that and saying,


well, it's not worthwhile to index all of the new content


all the time.


Maybe there are ways to kind of concentrate things a little bit.


But a lot of that is feedback you could


get from the help forum.


So I try that there.


You can also ping me on Twitter, maybe send me


a URL that I can take a look at to see if there is anything


generally wrong there or not.


I have a question.


So I direct from Bing, basically made a short video


saying keyword research practices are kind of going away


and should be replaced by intent research practices.


So it's not thinking about keywords,


thinking about intent.


Do you have any thoughts about that?


I didn't see that.


But I think in general, there is probably always


going to be a little bit of room for keyword research


because you're providing those words to users.


And even if search engines are trying


to understand more than just those words,


showing specific words to users can make it a little bit easier


for them to understand what your pages are about


and can sometimes drive a little bit of that conversion process.


So I don't see these things going away completely,


but I'm sure search engines will get better over time


to understand more than just the words on a page.


Thank you.


All right, I need to jump out.


It's been great having you all here.


Thanks for joining in for the new year.


And I have the next one lined up on Friday,


so feel free to join there, or the German one on Thursday,


of course.


All right, bye, everyone.


JavaScript SEO office hours January 13th, 2021

Hello, and welcome to the JavaScript SEO office hours


in January 2021.


I hope that you all had a great turn of the years.


I think that's what we say in German,


but I'm not sure if that's an English thing that you can say.


I hope you had a good start to the new year,


that you're all safe and sound out there.


I'm really happy to see that it has


a bunch of really good questions on the YouTube post


site for this Hangout.


I'll also, obviously, invite my two guests here in the live


meeting to also contribute.


But let's go through the YouTube questions first.


So first question came from or comes from Jane.


Jane asks, how often does Google crawl or render JavaScript


for indexing?


Is it the same frequency as crawling HTML, or is it less?


Really good question, because it's


a non-simple and non-trivial answer.


So the very short couple of words version of it is, yes.


Googlebot crawls and renders JavaScript for indexing


as much as it's scrolling HTML, because pretty much it's


like an entire workflow.


So it goes in, the crawl happens,


and then the rendering happens, and then the indexing happens,


roughly that.


If you want a little more detail,


I'll happily provide more detail.


But if that's the level of understanding


you are looking for, stick to that.


It's basically the crawling happens,


and then the rendering happens as well.


Interestingly enough, there might


be reasons for us to render more often than we crawl.


Sounds weird, but hear me out.


We might experience situations where we crawl the HTML


and then render, and then rendering for some reason


has some sort of problem, not even related


to your JavaScript or your website specifically,


but to our infrastructure.


So we might render a second time.


That's totally transparent, so it's not something


that you need to worry about or you can influence.


It's just it happens automatically.


It can also be that if the crawl brought a lot of resources that


might change in the meantime, we might actually then basically


crawl the subresources as part of render.


So we might render more often than we crawl.


But in general, we render as often as we crawl.


Sometimes, however, we might crawl more often


than we render.


If, for instance, another part of Google Search


wants to validate something or check something,


or if there is crawls going in to see if something has happened


on the content, then we might crawl,


decide nothing has changed, and then not render hypothetically.


That is a situation that can happen.


So we might not render as much as we crawl.


It can also be that we crawl.


We make the request, then something goes wrong


before we can render, and then we have to recrawl again.


In this case, we would also crawl more often than we render.


Again, in general, the rule is we crawl and render


similar amounts.


So whenever we are crawling, we're


also rendering afterwards.


So that's not something that you need to worry about


or need to take action on.


But to answer the question completely,


I'll give you a little more background information,


which ends up saying, generally, yes, the same amount.


But there are cases where we might render more often


than we crawl, or we might crawl more often than we render.


But again, that's not something that you


need to take action on or need to be aware of


or need to worry about.


Next question comes from Kevin.


Kevin is asking how they should apply metadata to 360 degree


photos for Google My Business.


That's a question for the Google My Business support forums.


That's not something that I know or I'm aware of.


That's not something that is specific to search


or JavaScript.


So that's something that you need to talk to the Google My


Business folks about.


And then it's like, can businesses get their products


on Google Lens?


That's a Google Lens question or a Google search question,


Kevin.


I'm sorry to not be able to answer these ones a little


outside of my area of expertise.


Harris or Harris, not sure, is asking,


does Google really execute JavaScript?


Yes, it does.


I mean, whether Google Robot reads the source code


or renders the page on the client side and then reads,


we do render the page.


We actually render the page just like your browser would.


So we execute the JavaScript.


And whatever gets injected into the DOM by the JavaScript,


that can be taken forward.


You can see that by looking at the rendered HTML in the URL


inspection tool or the rendered HTML in the mobile friendly


test or in the AMP test.


All of that includes content that


is generated by JavaScript because we


render that properly.


And Harris has a second question and actually a third one


as well.


So how does Google deal with dynamic content


by JavaScript, which changes with some condition


like user clicks, location, browser, or timing?


You can find that information in our wonderful documentation


at developers.google.com slash search.


Googlebot does not click or scroll or whatever.


So things like location where we reject location requests,


so you can't really get location in Googlebot.


Or clicks would not work with Googlebot


because we don't carry out clicks


and we don't give you the user's location in Google Search


and Googlebot rendering paces.


If it depends on timing, that might actually work.


Because the way that time works is different from how time


works in the real world when Googlebot accesses your website.


You can use the URL inspection tool or any of the other


testing tools that we provide from the search side of things


to see what's in the rendered HTML.


If your content shows up in the rendered HTML,


then you'll be fine.


How does Google work with Pjax?


And that's a jQuery library load HTML content


without loading and changing the address URL.


I think what they mean by Pjax is like an older technique


where you kind of have a single page application where


the JavaScript just replaces the content on certain actions.


I'm pretty sure we do not see that because, again, we're not


interacting with your content.


So if it's only loading different content on a click


rather than just on URL, that would not work.


You can see that described in the best practices guide


that we have for JavaScript.


Again, developers.google.com slash search.


There you find more information on how JavaScript is processed.


Next question comes from Lorenzo.


Lorenzo asks, how can I be really sure


that Google is accurately rendering


all of the content on the page?


In the screenshot from the URL inspection tool in GSC


and from the mobile friendly test,


I see that a lot of JavaScript elements are not loaded.


Instead, the rendered HTML code is perfect.


Can I be sure the perfect rendering only


by checking the HTML code with these tools?


Yes, you can because that's what we use for indexing.


So we don't actually use any images


to look at what the page looks like or anything.


We care about the rendered HTML code and some of the layout


information.


But fundamentally, if it's in the rendered HTML,


you will be fine.


That's what you should be doing.


Could I be sure also viewing and checking


the versions of my web page is cached in Google search


results?


No.


The cache is not meant to include


JavaScript-run content.


It is an outdated old feature that we just


keep around for convenience.


But it might not follow the pipeline


as well as other things.


The testing tools and the rendered HTML


is what we want to look for.


Bhagavari asks, how are Wix websites


doing in terms of rendering?


Wix uses a lot of JavaScript for almost everything.


And will a lot of JavaScript affect my crawl budget?


There's a few things in these questions.


So I'll run through these.


How does WebWix sites page render,


just like any other website?


You can check it in the URL inspection tool


and all the other tools that we provide


to check and see the rendered HTML.


If you're content is there, you'll be fine.


A lot of JavaScript may have an impact on your crawl budget,


depending on how it's built and what it does.


Generally speaking, if you have less than a million pages


or more, crawl budget shouldn't be a problem.


So I wouldn't worry too much about it.


If you have a smaller website on Wix or a smaller website


somewhere else, then crawl budget does not really


impact you.


If there is a lot of JavaScript files, all of these


have to be fetched to render them.


These fetches count towards your crawl budget.


The other thing is, if the JavaScript then


makes additional network requests


to fetch the content, like API requests


or fetches additional images, all of these


count against your crawl budget as well.


But again, unless you have a really, really big site,


that does not really impact your site too much.


Mustafa is asking about regarding partial indexing


on the pages, how to quality assure our URLs


and get to know what parts of the pages


Google is indexing or not.


Partial indexing is a tricky one.


We are not really partially indexing things.


We are having an index where all the information from the page


is in there.


With partial indexing, people sometimes,


I think this might be my fault, because I


think I at some point said partial indexing, which


is not true.


We are indexing the entire page.


And then we are looking at the content


to find the bits that are more important than the other bits.


So if you have a youth page about making an apple pie,


and then on the page somewhere down there,


there's also a story of your cat.


And we might decide that this page is really good for apple


pie, but the cat part is not as relevant and not as


interesting.


And so the page might not rank for cat,


but it might rank still for apple pie.


But then sometimes people are searching for the cat,


and they're like, oh, it's not in the index,


so the page was not indexed.


It was indexed.


It's just not the content isn't ranking,


because we don't think it's relevant enough to rank.


Passage indexing, sorry, passage ranking


is officially called passage indexing,


but that's actually really passage ranking.


Might change that a little bit, where we can then say,


oh, actually, this part about the cat is also really good,


so we can rank that for cats as well.


But that's not something that you can really check,


and I don't think you have to worry about that.


As long as your content shows up properly after rendering


and the page is indexed, you'll be fine.


And then you can basically try out the different search terms


and search queries that you're interested in


and see what happens in them.


And also use the performance report in Google Search Console


to find out for what you're showing up to.


And if that is not what you want to show up for,


then you have to see how to make the content more


relevant for the terms that you care for.


Lino, a lovely, fantastic, ridiculously clever product


expert from the Webmaster Forum, is asking me as well.


And he is saying, hello, I'm testing or trying


to catch JavaScript errors generated when Google loads


and renders JavaScript.


I use an event listener to load Pixel


when the error is detected, and I add error messages


to the URL of the image.


After that, I can hopefully analyze my server logs


and get the messages and save them.


Is there any other way to get error messages?


I think there is no other easy way.


You might be able to get something like,


what's it called, Sentry or, oh, god, I can't remember.


They're all called.


Greylock might have a thing.


So there's different logging libraries


that can send error information out to a separate service that


shows you the information that might be possible.


But I think your way of doing this is not bad.


That sounds actually like a good plan.


Smart, interesting idea.


Next question comes from Marco.


Marco is asking, hi, Martin.


There's a rumor that Googlebot does not


like content and blocks which have SEO combination


in classes, like div class SEO.


And this content is treated less valuable than content


and blocks without class SEO.


That is a myth, yes.


The question is if that's a myth, and the answer is yes.


That is a myth.


Interesting, though.


The next question comes from Eigtee or Eigtee85.


Is lazy loading of a news channel page


with a lot of news articles constantly changing,


subject to SEO?


All content is currently communicated


to Google with sitemaps and by index API later.


Yes, what are the pitfalls?


What are the best practices here?


We actually do have a best practices guide


for lazy loading.


But generally speaking, if the news articles independently


are submitted to us via sitemaps or RSS or index API,


and we can index them, that's not a problem.


We might just not rank this one specific page


with lots of things in there.


So I wouldn't say it's very relevant to the SEO.


If you want to make that page relevant in terms of search


results for some reason, then, again,


developers.google.com slash search.


And then under Guides, there is a guide


that explains a little bit about lazy loading of content.


But you don't really have to worry too much about that,


to be honest.


Miguel has the next question.


We display different main navigations


for desktop and mobile.


I'm considering the use of JavaScript


to remove hyperlinks from the DOM for links


that are only available on desktop for mobile users.


Is there a benefit or risk?


I think from the SEO perspective,


it doesn't really matter that much.


We probably will only index one of the two versions,


depending on if you're mobile first or not.


We might still crawl and potentially index


the desktop version.


We might just not highlight it that much in search results.


The risk is that if the websites,


if you remove links that are nowhere else,


then we might lose the semantic information


on how to navigate between the different things there.


But if it's in the sitemap and there's lots of other places


to reach the content from, I wouldn't worry too much about


this.


And now I shall reload the page to see if we have additional.


Oh, yeah, there's even more comments coming in.


Yeah, someone is asking for the Google Meet link.


That's funny.


I know that this happens because the way that YouTube is


ordering comments, unfortunately.


It is happening.


So two more people want to join and can't see the link,


it seems.


But I'll happily help them.


So we might see them join in a moment.


But thank you, everyone who submitted their questions


to YouTube.


This is great.


These were great questions today.


I'm really, really excited to see


the quality of the questions constantly improve.


And I now know that I have four people in the Hangout.


If anyone has any audience questions,


now is a great time to head into the audience questions.


I'll get the ball rolling, Brett.


Excellent.


Thanks, Dave.


Also, by the way, a brilliant product expert


from the Webmaster Forum.


Always a little nervous about your questions.


Let's see.


You're right.


It's a bit back to what you were saying earlier, that sometimes


you render something more than you'd crawl.


How would that impact, say, if I'm making an API call?


Say I had a page, almost that news thing,


and it was calling API, pulling in the latest articles.


Would there be a point where you're going back and fetching


that API and re-rendering from what you've already got?


Or would that only ever be triggered


if you went back and crawled the main page?


That's a very good question.


That's a very, very good question.


So the way that it works in the pipeline


is the crawler basically crawls the main resource, the HTML,


fetches that, caches that.


And then the rendering happens to use the crawler


to fetch all the resources.


They also go in the cache.


So that being said, if the rendering, for some reason,


has to be restarted or is done at a later time,


again, for whatever reason, we would go through the cache


first, especially when it's get requests.


So you said specifically API requests.


If that is a get request, so it can be cached,


and it happens to be in the cache,


and the cache happens to not have expired,


we would just take what we had in the cache.


Because the general idea of the rendering process


is to produce as consistent renders as possible.


So the idea is given the same amount of data


that we got from crawling at some point,


we want the same output, which is


why things like random number generating or time and date


work slightly different.


You might actually see us operate with data and timestamps


that are coming from when we crawled rather than when


we actually render.


So to keep this consistency, we use the cache.


Fantastic.


But what if it is a non-cacheable request


or the cache has expired or the cache, for some reason,


doesn't have this request?


Well, in that case, the second render that would run


would send the request to the crawler.


The crawler would fetch the data,


and then it would go into the cache.


Or if it can't be cached, then it would skip the cache.


So you would actually see the render then


updating without necessarily seeing the crawl.


You can probably see that in the server logs,


because you would see the requests coming in


from the crawler for one specific resource.


But again, we would try to reduce


that amount of additional fetches or fresh fetches,


because we want the renders to be as consistent as possible


and to hopefully only update when we also


do the crawl run before.


But that might happen, especially with post requests


that we can't.


If it's an API request that is a GraphQL request that


is using post, it might actually fetch fresh.


So it's not something that you would think, oh, well,


I've learned this page.


Only ever really updates by doing a fetch request.


We'll just do that.


And then every time we're getting there,


it's more in the scope of, oops, something went a bit wrong


last time.


We're back on fetch.


Yeah, exactly.


Yeah, yeah.


That's pretty much what normally happens.


OK, thank you.


You're welcome.


Awesome.


Any other audience questions now that we


broke the ice?


I don't want to do the teacher kindness.


Oh.


Hi, this is Miguel Martinez.


I know this probably isn't the most pressing question.


But I had asked about considering


using a JavaScript to remove hyperlinks


from the DOM for links that only appear on our desktop


version for mobile users.


Yeah.


There's some discussion within my organization


about whether or not it's a good idea versus a bad idea


from an SEO standpoint, and if Google would even


run the JavaScript as part of the crawl.


So this is going to be interesting on the recording,


because we answered this question earlier.


But I'll very happily answer again,


because I would like to hear if that's


a sufficient answer for you or not.


And it's always tricky to guess that from here.


So I apologize.


No, no.


All good.


All is well.


I know that that's why I'm very happy to take this live,


because it's YouTube's formatting


or sorting of the comments.


They have this top comment by default.


And usually when you submit links,


they are not rated as top comments.


And then people don't see them unless they switch to the,


what's it called, to the new comments first ordering.


It's a little weird.


Anyway, so we do execute the JavaScript.


So we'll very likely see whatever comes out of the


JavaScript runs.


So either if you remove the hyperlinks


or add hyperlinks to JavaScript, we


will see or not see them, depending


on if you removed or added them.


In general, it shouldn't really matter that much.


You can do that change.


If you feel that it brings you other benefits than SEO


benefits, I would probably do that.


If you, for some reason, say, oh, yeah,


but it's better for the users, then that's


a decision for you to make.


There is no inherent benefit for SEO purposes.


There is a potential risk for SEO purposes


when the pages that you just remove the links to are


actually no longer or basically are orphan pages,


and we can't actually get there from somewhere else.


Then we might have a hard time to put them back


into the rest of the structure of the website,


even if they are submitted in the sitemap.


Sitemaps don't really give us hierarchical information.


So that's a thing that is a little tricky.


But I don't see navigation links necessarily


as being very much superior over sitemap thing,


because that's, again, if it's in the navigation,


it's on every page.


And that, again, is kind of non-hierarchical, really.


Yeah, unfortunately, it's a flat site architecture,


very dependent on a legacy platform.


And it's to the magnitude of about 1,300 hyperlinks


difference between the desktop and mobile versions.


Wow.


So if these pages are in the sitemap,


and you would rather keep the mobile menu lean


and remove these 1,300 links, and I understand


why you want to do that.


I'm pretty sure this has a performance


impact on mobile devices.


Then I think this is fine.


Just be aware that we might be like, ha, OK,


so all of these pages no longer link to this other page.


So they might not regard them as highly anymore.


So it does update the link graph.


But yeah, just be aware that it does that.


And if the SEOs on your team are like, yeah, this is fine,


then that's OK.


That's not a big deal.


They might think differently, though.


I would understand if they're like, no, we kind of


care about the links being specifically here.


I do appreciate that feedback.


That's very helpful to us.


Good.


That's very, very happy, or makes


me very happy to hear that that was a useful answer.


Because these questions, I can answer them


in a shallow way or in a deep way,


and I'm never sure which way to go unless I


have the person in the audience.


That's fantastic.


Thanks for joining and asking.


Awesome.


So we had Dave.


We had Miguel.


Who else has a question?


A few people hanging out, just hanging by.


All right, I'll check the social networks one more time.


Let's see if someone else said something.


Oh, a question that came through Twitter,


not specifically for the JavaScript SEO office hours,


but good question nonetheless.


Someone was wondering, Ryan actually,


was wondering if there is a different user


agent between what we actually do when we crawl versus when


you use the live test versus when you


use the mobile-friendly test.


No.


They are all using the same user agent.


We might, depending a little bit on which route