Thank you for watching, and look out for the last episode in the Search for Beginners series


How to change my Google Search result snippet? | Search for Beginners Ep 10


English Google Webmaster Central office-hours from Nov 1, 2019

All right.


Welcome, everyone, to today's Webmaster Central office hours


hangouts.


My name is John Mueller.


I'm a webmaster trends analyst here at Google in Switzerland.


And part of what we do are these office hour hangouts


where webmasters and publishers can join in.


And there's a bit of noise.


Where webmasters and publishers can join in and ask


their questions all around web search and their websites.


There are a bunch of questions submitted.


But I know at least one of you is here


at a really late middle of the nighttime.


If you want to get started with your questions,


feel free to jump on in now.


Sure, if I may, I have a couple.


So first question is, let's say there's


a website where users can write poems that other users write.


Given the update to the ratings and reviews, rich snippets,


we're no longer able to support the creative work


property with the aggregate rating schema


for rich snippets.


So what do you suggest, given that our users do


rate these poems and we'd like for those


to show up in the SERP?


Yeah.


I mean, from a technical point of view,


you'd need to use the type of schema markup that matches


the primary object of the page.


And if that's a poem and that only works with creative work,


then those reviews would have to be based on that.


And we might not show that in the search results.


So I don't think there's much of a way around that.


It wouldn't be that you'd be able to say, well,


this poem is suddenly a product.


And we'll let people review it based on that.


It kind of is what it is there.


So I don't know if there's a real workaround to making


those available in search.


I see.


Yeah, it didn't really seem like there was any property that


made sense.


I think the closest one was media objects.


But even that was a bit of a stretch.


OK.


The other question is, let's say a website,


you search for keyword x in a domain that usually


ranks for similar keywords.


Doesn't show up on page one, even page two or three.


And at the bottom of the search, I


believe this would occur on page one.


There is sometimes a show omitted results link.


And upon clicking that link, the domain that didn't show up now


appears.


So what would cause that domain to be originally


omitted from the results?


So the show omitted results link in the search results


is basically shown when we would have multiple results that


would show the same snippet or same preview, essentially.


So that's something where we find


it doesn't make much sense to show users


the exact same snippet in the search results multiple times


for different pages.


So we try to pick one of these pages and show that one.


And with the omitted results link,


you can kind of see the others as well.


So if a website is only visible when you click on that,


usually that's a sign that we found the same content


somewhere else, and we're currently just ranking


that version rather than the version


on that particular website.


OK, that sounds good.


Thank you.


And I do have one last one.


Let's say a website has a lot of URLs.


Let's say it's 100 million.


And of those that are called daily by Googlebot,


maybe a tenth of a percent are 410 status.


Now, at some point in time, let's say maybe overnight,


that website decides to remove 20 million URLs simply


because there are no value to users.


Some of these might be crawled by Google fairly often.


Some of them might even be indexed.


But now that these 20 million URLs are removed,


let's say most of them end up getting a 410 status.


And Google starts crawling.


Of the URLs that Google crawls on a daily basis,


let's say a large percentage of them


now have this 410 status.


Maybe it's 7%.


What signal might this send to Googlebot


despite ultimately improving the quality of the URL


that it could crawl?


That's essentially a non-issue for us.


So when it comes to ranking, that wouldn't change anything.


It's not a bad sign.


It's not a good sign.


It's essentially just you have fewer URLs.


With regards to crawling, in the short term,


probably not much would change.


We would still try to crawl these URLs even


if they return 404 or 410.


And in the long run, we would probably


concentrate our crawling more on the URLs that do return 200,


where we've seen the other ones that return 404 or 410.


We just don't crawl them as frequently.


So from a ranking point of view, we


would still try to crawl these URLs.


So from a ranking point of view, nothing really


would change there.


It might be that you would see a subtle effect


of the concentration of the value


more on the pages that you have left.


But it definitely wouldn't be a negative effect.


I see.


So Googlebot wouldn't, let's say,


negatively despite the significant increase


in 410 status URLs.


Yeah, that definitely wouldn't be a negative thing.


I mean, 404 or 410 is essentially just a sign


that these URLs no longer exist.


And sometimes a lot of URLs don't exist anymore.


But that's not a sign that the rest of the website is bad


or that anything is kind of broken


and we need to be more cautious with crawling.


It's just, well, those URLs don't exist.


We have the other ones that do exist.


We'll focus on those.


OK.


All right.


I appreciate it.


Thank you for the answers.


Cool.


Thanks.


Anyone else want to get started with a question


before I jump into those that were submitted?


No?


Maybe along the way.


We'll see.


Today I got a message from Search Console.


Seems lots of people get messages from Search Console


saying that my website has the following issues.


Texts too small, clickable elements too close,


content wider than screen.


However, my site successfully passed


Google's mobile-friendly test and no issues were found.


Is that a bug?


Should I take any action?


So I get this question from time to time.


I think on the one hand, it's a little bit confusing


on our side in Search Console.


On the other hand, sometimes I think


it's also OK to flag these kind of issues.


So practically what is probably happening here


without knowing the actual URLs that you're looking at,


my guess is what's happening is that these pages


are mobile-friendly.


When we look at them in a mobile browser


and they load completely, then we can see


that they're mobile-friendly.


We essentially recognize that the text is readable,


the elements are appropriately spaced,


the content has the right viewport set, all of that.


But what might be happening is from time


to time when we try to render these pages to test them


to see if they're mobile-friendly,


something breaks.


So we might have, I don't know, 1,000 pages


that we're looking, that we're testing for mobile-friendliness.


And of those, every now and then something breaks,


so we have a handful of pages that essentially don't


pass the mobile-friendliness test that we


do on an automated basis.


So in practice, what would happen


is we would flag those handful of pages to you in Search


Console so that you can take a look to see if this is really


something that is broken on those pages, which you can test


using the mobile-friendly test yourself,


or if this is something that's just kind of like a flaky test,


where sometimes it works, sometimes it doesn't.


And often with those kind of flaky tests,


if it's not something that's significantly


visible across your website, if it's really


just a handful of URLs, then that's fine.


That can happen.


If you're working on a bigger website,


then every now and then something,


when we try to test it, it just won't work.


The next time we test it, it'll be fine.


So that's not anything that I'd particularly worry about there.


A little bit of background noise.


So it's not necessarily a bug that we


would send you these messages.


It's essentially, my guess is we're mostly


seeing that things are OK, and just every now and then,


the test doesn't work out.


So we flag those.


What's the latest position from Google


in terms of how much waiting it gives to content


hidden behind read more dropdown links,


such as JavaScript functions?


Especially now that indexing is moving to mobile first,


and we're encouraged to design best practices


for mobile users.


So with mobile first indexing, if content


is loaded in the page, and it's just not visible,


it's behind something like a tab or an accordion or something


similar, then we will treat that as normal content of the page


with the assumption that this is something


that users can access if they recognize the accordion


function or the tab or the read more dropdown links,


all of those things.


So that's the easy part.


However, you dropped an aspect into your question


that might be something that we'd see differently.


Namely, you're saying this is behind JavaScript functions.


So there's a difference from our point of view


between functions or kind of functionality


that you have on the page that is loaded by default


and functionality that has to be loaded on interaction.


And functionality that is visible in the page


by default, which is in the HTML,


maybe it's not visible by default,


but it's in the HTML by default. That's


everything that we can pick up and index right away.


However, if there's something on your page that


needs some kind of interaction to load so that it's even


in the HTML, for example, if you use JavaScript


to load something from your database or from your APIs


and then show that to the user when they click on something,


then that's something that we would not know about.


So we would not know where to click on your pages


to trigger this kind of interaction with your server


to load more content.


So that's the aspect that just purely


from a technical point of view, we


wouldn't know what to do to load that content.


So we wouldn't be able to index that content.


However, like I mentioned, if it's already in the HTML,


if you can do view source or inspect element


and it's in your HTML by default,


it's just not visible by default,


then that would be fine.


With the likes of Facebook moving away from likes


and with many leveraging fake likes,


what will Google do about social ranking signals?


So the good news here is that nothing will change.


In particular, because we don't use these signals.


So that's kind of, yeah, makes it a little bit easier,


I guess, for you in the sense that we don't use these likes


anyway as a ranking signal.


So if a social network were to change those signals,


then it's totally up to them.


It's not something that would affect us in any particular way.


OK.


A lot of the, or some of the reasons,


I guess, why we don't use those signals is that purely it's


really hard to even keep up if we were able to crawl


all of those pages.


So you can imagine a large social network,


it has a lot of content that keeps coming and going.


And if we needed to refresh all of that content so quickly


that we could pick up all of these social signals,


then that would be really kind of tricky.


So we don't use those.


What scenarios would cause Google Analytics to report


organic traffic as direct?


I don't really know much about Google Analytics,


so I can't really say anything particular to that.


The only thing I've heard over the years


is something around redirects, where I believe


redirects would lose a refer.


But I don't know if that's actually correct


or if that's just something I randomly heard.


MIHAI APERGHISLAMO


One of the big issues I've noticed


is with tracking issues due to cookie acceptance pop-ups,


where users might not accept the cookie right away.


They move to another page, and then they


accept the cookie pop-up, and then the referring information


is lost.


Or they do get, let's say, from Google to a landing page,


and they accept the cookie pop-up.


And in order to trigger the Analytics code,


it does a refresh of the page.


And that refresh actually loses referring information


rather than just push it directly via Google Tag


Manager or other ways.


And this is when that Google traffic or whatever other source


gets treated as direct.


OK.


Now, that sounds complicated.


So check in with me, Hai, I guess.


I can imagine now with all of those cookie banners


and that it actually does the analytics just


when you accept everything.


That probably makes it a lot harder now.


Yeah.


MIHAI APERGHISLAMO This is generally a big issue,


especially in Europe with the GDPR pop-ups.


There are all kinds of plugins or custom implementations


that people want to use in order to make


sure they are GDPR compliant.


And sometimes this breaks the way Google Analytics is loaded


and misses out on the referring information.


Good to know.


So I guess in future, I probably won't


be able to answer this question either,


but maybe that helps a little bit


to understand what kind of situations


you might be seeing that and probably also why


you would see a rise in this kind of traffic


over the last couple of years.


I'd highly recommend the Google Analytics forums.


OK.


There really knows all about these issues.


Cool.


All right.


So name the top 10 ranking factors


that Google is wanting from the publishers.


Yeah, I don't really have a list of top 10 ranking factors,


so that's going to be kind of awkward.


I think in general, what I would recommend doing


is on the one hand, making sure that you have a technically


valid website that works really well


from a technical point of view, and then on the other hand,


focusing on making content that is something


that people really want to see.


And that is unique and compelling,


and that's not just rehashing other people's content, where


you're essentially taking the expertise that you've gained


over the years and presenting that


to people who are really keen on picking up


this kind of content.


And that's not something that's easily


refined into some magic number where you can say,


well, I will focus on putting my keyword five times on a page.


If you have bad content, you can put it


on there six times or seven times,


and it still won't change anything.


So that's kind of the two pillars


that I would look at there.


On the one hand, really technically a valid foundation


to work on, and a lot of the common CMSs,


a lot of the common systems that are out there,


they do have really good foundations nowadays.


Some CMSs have plugins that integrate things


like Search Console, Analytics, all of that.


For WordPress, for example, we just


launched the Site Kit plugin from our side,


which is something that also automatically integrates


Search Console, Analytics, and pretty much all


of the various Google tools for publishers.


So that might be an option.


And then that alone is not something


that will make your site relevant to users.


So you can have a fantastic, from a technical point


of view, website.


But if it's on topics that people don't care about,


if your content is not something that is really


on par with the best of the best of that kind of content,


then you're probably not going to see a lot of traffic


in search.


So those two sides, they do need to be


Hi, John.


Hi.


So I wanted to ask something.


First of all, happy Halloween, and I


like what you did with your hair.


So my website is in a very spammy industry.


And still, we work very hard to create high quality content,


original content.


All of our articles rank very well,


and share the community, and bring a lot of traffic.


We have great backlinks, big institutions, all that.


So basically, we really try to make


sure to follow Google's guidelines and recommendations.


But it doesn't matter what we do and how much effort we put


into it, how much hard work we do.


Our rankings, they don't improve.


And they actually started dropping lately.


Some of our competitors clearly use scammy tactics


that you guys always tell us to stay away from.


And although it seems like we perform better than them


on every single metric we were able to see, they outrank us.


And also, in the past, we've had someone spam our website.


Thousands of spammy links we tried to disavow.


But I'm not sure we were able to get all of them.


So I kind of wondered, we're wondering


if there's something going on that we're not aware of.


Do we have any technical issue or something


that you maybe would be able to see


if there's anything spammy going on that we're not aware of?


Yeah, that sounds like something where I probably


need to take a bit of time to look into that


or to pass it on to someone to take a look.


If you want, you can just post a link in the chat here.


And then I can pick that up afterwards.


Would it be possible to send it to you by email?


Sure.


You can also send it to me by email.


I just can't promise that I'll be able to respond directly


by email because a lot of times, these


are things that I pass on to the teams.


And they take that feedback, and they work on that.


But it's not that I'd be able to bring something explicit back


to you and say, well, we fixed this, or we changed this,


or you need to change this.


A lot of times, that's really just one way path


to the engineering teams.


OK.


So there won't be any follow-up, but you would still


have someone take a look at it.


Sure, yeah.


That would be great.


And also, I wanted to say, I come very often to Tziri.


I was wondering if you were planning to do another one


of these Hangouts where people come join you guys


and join you in the Hangouts like you've done last year.


We should do that again.


Those are always fun.


We have the Webmaster Conference lined up in December in Zurich.


That might be another opportunity,


but we should do that again.


When is it in December?


I don't know.


It's like beginning, maybe first or second week of December.


OK.


That'll be nice.


Anyway, thanks a lot.


Sure.


Thanks.


All right.


I'll run through some more of the questions here,


and then we'll have more time, I guess, for more questions.


If I started link building and built 200 links in two days


and then built zero links for two years,


will Google see this as Black Hat and penalize me?


So I think on the one hand, we wouldn't


see the building zero links for two years as Black Hat


and penalize a website.


So that's kind of the one thing.


On the other hand, if you're building 200 links in two days,


it's not so much the number of links


that you're building in the short period of time.


It's really just the matter that you're probably


building links in a way that would not align


with our webmaster guidelines.


And that's something where, on the one hand,


our algorithms might take action on that, where


they might ignore those links.


On the other hand, our manual web spam team


might take action there and apply manual action.


So it's not so much the number of links in the time


that you're talking about.


It's really just the type of links


that you're building or the type of link building


that you're doing in general.


So if you're dropping links on random sites,


if you're buying links in various places,


if you're exchanging links using some kind of a weird link


network, all of those are things which


would be against our webmaster guidelines, which would perhaps


result in 200 links being built in two days.


And since they're against our webmaster guidelines,


we do try to catch those algorithmically and ignore


them.


And we do, from time to time, look at these things


from a manual point of view.


And we may take manual action on that.


So really, it's not the number in the period of time.


It's really the type of activity instead.


Do external links pointing to pages with URL parameters


set to crawl none in Search Console hold any value?


For example, one parameter is only


used to track affiliate links.


Will setting that one parameter to crawl none effectively


block any value?


So there are a few things that happen here.


On the one hand, crawl none does not


mean we will never crawl it.


If you want something never to be crawled,


use the robots.txt instead of the parameter handling tool.


With the parameter handling tool,


we will still occasionally crawl these URLs


to see if things are set up properly.


So that's one part there.


The other part is what often happens with these parameters


when they're set in the parameter handling tool


is that we try to figure out what the canonical URL is


for those URLs.


So you might have one URL set up with a parameter where


you say, well, ignore this parameter


or don't crawl this parameter.


But that doesn't mean that we would not


try to figure out what the canonical URL for this URL is.


So with the canonical URL, we essentially


mean the URL that we would try to index


for that piece of content.


So for example, if you have an affiliate parameter


that you have that you're passing there,


and we've seen that this affiliate parameter can


be ignored and that we can find the same content


without the affiliate parameter, it


might be that we have that connection kind of learned


in our systems between the URL with the affiliate parameter


and the URL without.


So if you use Inspect URL in Search Console


with the affiliate URL with the parameter, it's possible.


It's not guaranteed that we would


know that the canonical of that URL with the parameter


is the one without the parameter, for example.


And when that happens, if we have a canonical URL


for a link target, then we would change that and say,


well, this link technically points


to this URL on your website.


But we know this URL is equivalent to that one.


So we will kind of route that link to the URL


that we have as a canonical.


So that would essentially mean that it's


kind of the same as having a rel canonical on these links


or redirect, where you're saying, well,


from this URL with the parameter,


we're redirecting to the other one.


You could, of course, also use a rel canonical.


You can also use a redirect.


All of those things also make sense.


And they help us to figure out what the canonical URL should


be.


So that might be another option to do there.


The other thing just to mention is that, in general, we


recommend using nofollow or rel="sponsored for affiliate


links, because those links are essentially there because


of a financial relationship between the affiliate site


and the destination site where the links are going.


So if you have a rel="nofollow or the rel="sponsored there,


then, in general, we wouldn't be passing any value anyway.


So you wouldn't need to worry about this in particular.


But those are kind of the different aspects


that all play into this.


So it seems like a simple question,


but lots of things that can play a role here.


John, just a quick follow up, so the rel="canonical tag doesn't


foliage.


is not an issue.


It's not that it would break anything


if we crawl all of those URLs.


So I try to avoid using those settings just because it's,


I always find it's a very tricky setting.


And if you set it up wrong, then suddenly we


will not crawl things.


And then maybe we'll actually miss something.


So with the rel canonical, at least if something goes wrong,


we'll still have that one URL that we can still crawl.


OK.


Let's see.


Somehow these questions are all being cut off a little bit.


A question forward from the last Hangout.


I received a security issue on content injection


via a search console for certain pages.


I followed the steps, but I didn't find anything


on the pages that's related to spam.


Is there a chance to have a, and then it cuts off.


Let me see if I can refresh and get the rest of the question.


Oh, here we go.


Have a look to see if it's a false positive.


So what often happens here is, so I guess there


are two aspects here.


On the one hand, sometimes we get it wrong


and we think that something is hacked


when it's actually normal content.


So that can happen if you have a bigger website that also


includes some content that kind of looks


like the type of content that hackers would put on pages,


which might be around pharmaceuticals or, I don't


know, casino gambling type content.


If that's mixed in with the rest of your content,


we might think, well, this seems a little bit odd.


And those are the kind of issues that we love to have flagged.


And on the other hand, hackers also use a lot of cloaking


techniques to hide kind of the hacked content


that they put into your site from the webmaster.


In particular, they want to get this content indexed in Google,


or they want to use it for phishing purposes,


or something like that.


And to make sure that it stays around for as long as possible,


they'll try to find ways to hide it from webmaster.


So they might do things that only show it


to Googlebot user agents or Googlebot IP addresses.


So it's really kind of tricky to find.


What I would recommend doing here


is maybe checking in with the Webmaster Help Forum.


The folks there have a lot of experience


with these kind of questions.


And they can pretty much take a look


at that using the tools that are available to check


to see what Googlebot would see, or guiding you to using those.


And to find out more if it falls into the category of someone


is hiding something on your website,


or if it falls into the category of, well,


this is maybe a bug that we should tell Google about.


And they can also escalate it if there are issues


that Google needs to know about.


One of my websites provides information


about various schools in my country.


Each school has its own page with its own unique aggregate


rating based on reviews, which my visitors submit.


However, even though I followed all the guidelines,


my aggregate ratings don't show up in the search results.


What am I doing wrong?


Good question.


I don't know in particular what is showing up on your site.


So that's kind of tricky to say.


I'd also primarily suggest going to the Webmaster Help Forums


to double check that with other folks.


But in general, there are a few things that


can be playing a role here.


On the one hand, we've started showing


review-rich results only in a certain number of cases.


So it might be that the type of content


that you have with the reviews that you have


doesn't fall into the category of content


that we would show in the search results.


And if that's the case, there is nothing really


that you can do there.


It's essentially a policy decision on our side


that we would not show reviews in the search results


for that kind of content.


I would not recommend trying to circumvent that by saying,


well, it's actually not this kind of content.


So for example, if people are reviewing schools


and you turn that around and say, well, this is a recipe,


actually.


It's not a school.


And then that's something that, from our side, on the one hand,


you would try to recognize algorithmically.


On the other hand, the annual web spam team


would probably take manual action on things like that.


So I would not recommend doing that.


That's kind of the one thing that comes to mind immediately


there.


The other thing is, in general, for rich results,


we have different things that we try


to make sure that they apply before we show them


in the search results.


So independently of reviews or not.


In particular, the markup has to be technically correct.


So using a testing tool to see that it's correct is important.


Then the markup has to be such that it's kind of logically


correct as well, in the sense that you're marking up things


in a proper way, that the item that you're marking up


is really the primary item of the page,


that it's this right type of item.


Like I mentioned, if it's a school,


don't mark it up as a recipe.


That's the other thing.


And then finally, we need to be sure that the website is


of a reasonable quality, so that we can kind of trust


that the information that you're providing with structured data


is something that we would like to show in the search results.


So those are all kind of the different criteria that


come to mind with rich results in general,


and especially with the kind of review rich results


that we show in search, the other thing that I mentioned.


We have a blog post specifically about the changes


in review markup, I think from maybe two months ago,


something around that.


On my site, there was an issue with an author page.


It was redirected on my home page.


There were too many 301 redirections


after the core update, and my site traffic went down.


Now I fix it.


How much time will it take to restore?


So I guess the good news is 301 redirects would not negatively


affect your site when it comes to changes


like the core updates.


301 redirects would only cause a problem


if that content were not accessible at all.


So if you have kind of a circular amount of 301


redirects where you redirect to one URL


and you redirect back, and that redirect goes back again,


then we wouldn't be able to load that content.


Then that would drop out of search,


and then that would no longer rank.


But it's not the case that if you have a redirect from one


page to another, maybe you changed some URLs,


maybe you moved a part of your website within the website,


that that would be a reason for us to drop a site in search.


So in particular, if you're seeing changes


after one of these core updates that we've announced,


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


is not an issue on your website.


It's essentially our algorithms thinking, well,


maybe we judge the relevance of this website


for those queries incorrectly, and we're


trying to improve that.


And these things are things that can change over time as well,


where we think, well, in the past,


we thought this was more relevant,


and now we've seen that people see something else


a little bit more relevant.


So we'll try to adjust our relevance criteria.


So it's not so much that you're fixing something


and that it comes back, but rather, if your site is


no longer as relevant as it used to be,


then you can work on making your site more relevant


and making your site better in other ways.


So it's not you're fixing it and it comes back,


but rather, you're improving it, and it


improves in search over time.


We have a blog post about core updates


as well from sometime this summer, where I would


take a look at that as well.


It has a whole bunch of things that you can look at,


that we recommend folks ask themselves in a serious way


to figure out what they can do to improve their site overall.


Is there any impact if the path of my URL is 404 or even 310?


So if you have a domain.com slash path slash path


and slash patch and a page name, if one of those path URLs


alone is a 301 or a 404?


No, absolutely not.


So if we find links to that path directly,


then we will see that as a 404.


We'll see a link to a 404 page, like maybe there


are other 404 pages on your website.


That's fine.


It happens.


But it's not the case that we would take a URL


and split it into pieces and try the individual pieces out,


and if they don't work, then we would throw away the rest.


We understand that these URLs are essentially identifiers,


and sometimes the path that you specify in there,


they're not actual folders with files on them,


but rather essentially an identifier


that is telling us under this long URL, we have this content.


And what might be if you split that URL up into pieces,


that's essentially kind of like, well, we


didn't tell you to look there, so you don't


need to double check that.


So from our point of view, if a part of the path does not work,


that's perfectly fine.


My client paid for PR in local newspapers


and wants to post it on their website.


What's the best way to do this to enhance SEO?


So I guess kind of taking a step back in general,


if you're paying for PR in a newspaper,


then that's something from my point of view


shouldn't necessarily be affecting your SEO.


So it shouldn't be the case that you would pay to have more,


I don't know, visibility in search.


If there are links in these PR articles that are only there


because you paid for them, then they


should be appropriately marked with a rel="nofollow",


or rel="sponsored", to let search engines know


that this link is a part of a paid article, for example.


That can still make it useful for users,


and that can still mean that you can


refer to it on your website.


It's just that those particular links,


they wouldn't be passing any signals to your website, which


in general is fine.


So doing this kind of promotion for your website,


for your business, is perfectly fine, is perfectly natural.


I think that's something that almost always makes sense,


where if you know that there is an audience out there that


might not know about your website or about your business,


and you want to bring your business kind of in front


of them, then finding a way to talk to them,


which might be through a paid article like this,


is perfectly fine and reasonable.


It might be that this audience keeps coming back


to your website, and then they recommend your website


to other people, and then those links pass signals.


That's perfectly fine.


But it shouldn't be the case that your website ranks higher


because you're doing paid articles on other websites.


So kind of the direct SEO effect generally shouldn't be there.


Indirectly, you can definitely see some effects there, too,


where if your content is really good, your website is good,


people will be happy to have gone to your website.


And that's something that indirectly we might pick up.


Ranking on some sites are related to their authority,


but I see some better content on sites without this authority


that rank worse.


Can we treat this as a monopoly of information?


So I don't know what a monopoly of information is.


So that's kind of one thing.


But I think the general complaint that I see in this


question is we have a really good website,


and we think it's just not being recognized as being


a great website in search.


And essentially, why are other websites ranking above mine?


And this is, I think, a pretty basic question


when it comes to SEO.


It's not limited to authority or trustworthiness


or any of the other fancy new buzzwords that are out there.


It's really just a matter of, well, some websites we show,


and we think they're more relevant to show to users.


And some websites we think they're maybe not


as relevant to show to users.


My general advice here, without knowing your website,


without knowing your specific situation,


is to make sure that your website is not just


as reasonable as the others, as kind of useful as the others,


but rather that it's significantly better.


So that it's something where if our engineers were


to run across this case, maybe in the forums,


or if you posted about this on Twitter or anywhere,


if our engineers were to see, well, for this query,


we're showing this website at number nine instead of number


one, they would be able to look at that and say,


well, this website at number nine


is clearly by far the best of all of the websites


in the search results page.


We should find a way to rank it number one.


And that's something that our engineers


do take very seriously.


If they see that we're kind of really ranking something


much worse than it absolutely should be, objectively looking,


then that's something that they'll work to improve.


It's not something that happens overnight.


It's not something manual where they would say,


well, we will just change the numbers behind this website


at number nine to make it number one.


But over time, with our algorithms,


we do try to improve that.


But the foundation of that is really


that the website that you're looking at is not just,


well, we have just as good content,


but rather something that is significantly better.


So that anyone who objectively looks at the search results


page would say, well, this is a bug.


It's not like, well, it could be this way,


or it could be that way, but it's clearly a bug.


It's like if you ask Google, what is one plus one,


and it ranks a website that says the answer is three on top,


and the answer two is ranked at number nine,


then objectively, we're doing bad search results there.


On the other hand, if the number one result says two


as the answer and the number nine result


says two as the answer, then those


are kind of the same things.


And it's not something where our engineers would look at that


and say, we need to fix this, but rather, well,


it's the same thing.


What difference does it make to users


if we show this one or that one in the first place?


So really kind of stepping away from just focusing


on individual factors and really thinking about what could you


do to make your website significantly better,


objectively better than all of the others that are out there


for this particular topic.


An acquired domain that originally redirected


to another domain, which currently


has thousands of pages indexed.


Oh my gosh, it's a complicated question.


Domain.com redirects are cached and indexed.


I added 410 status and removed URLs in Search Console,


but I'm still seeing 5,000 results in the search results.


Valid URLs indexed, not submitted, have dropped.


Will those 5,000 results in search results


drop or do I need to continue submitting URL removals


on Search Console?


So I think I'm not 100% sure.


The question is a bit complicated.


I think what is happening here is you're moving from one


domain to another, and we're still


showing results from the old domain in the search results.


In general, that's perfectly normal.


That happens all the time.


And that's something that our systems try to do,


much to the dismay of SEOs who are explicitly


trying to move things from one domain to another.


In particular, if you're looking for one domain


and we know that content on that one domain


is not being used for the old domain results.


So if you do a site query for the old domain,


you will still see results.


If you explicitly search for the domain,


then we will still show those results.


However, if you look at the cache page for those pages,


then often you'll see that the cached URL is actually


the new URL already.


So our systems know that the old URL is an alternate version


of the new one.


And if you explicitly search for the old one,


we'll show it to you because we're trying to be helpful.


But it doesn't mean that the search results


that you would see there are indicative


of any particular problem.


So I would not recommend using the URL removal tools for that.


On the one hand, I think there are two reasons for that.


On the one hand, you don't need to because probably users


wouldn't see these in a normal search results.


On the other hand, the URL removal tool


only hides things in search.


It doesn't change indexing.


So it wouldn't force things to shift over.


It just hides them.


So that when you do a site query, it's like, well,


we would have 5,000 results, but you're hiding them,


so we show you 2,000 results.


So it doesn't really fix anything.


So that's kind of the one thing there.


So I would avoid using the removal tool for something


like this.


I'd use a removal tool for something


that you really don't want to have shown in search, where


if someone is searching for something


and you removed it from your website


because you urgently needed to remove it,


then you can hide it in the search results.


Then it doesn't matter if it's indexed or not as long


as nobody sees it.


For example, you accidentally leak some private information


about the site owner and you fix it on your site


and you just want to make sure it's not shown in search,


then of course, go for it and hide it.


With regards to the other options there,


setting 410 status code for these URLs


or something similar, I would not do that.


If you're moving from one domain to the other,


then set up redirects.


And in the worst case, what can happen


is if we show your old URLs in search,


that redirect will still bring users to the new site.


So in those cases, it's not that you


would have any negative effect from having your old URL shown


in search because users still make it to your new site.


So those are kind of the things I would do there.


In particular, just continue using the redirects


and don't worry so much if you're


like physically looking for a URL that we would show it


because our systems try to be helpful.


And as an SEO, as a webmaster, you're


trying to find the objective answers and helpful systems


sometimes get in the way there.


All right.


Wow, it looks like a bunch more questions left,


but also a bunch of things happening here


in the chat, which I haven't been able to catch up.


Anything from you all that I should be covering next?


Hey, John, it's Amos here.


Hi.


I'm touching on Google for Jobs again.


We still face problems with our visibility there.


So I was wondering if you could point me in any direction, how


we could improve our visits through Google for Jobs.


I mentioned, I think, in a couple of Hangouts


ago that we did a migration and we sort of dropped off


and I'm getting a lot of pressure


internally to give some direction to the team


on how we can recover that.


OK.


I will prod the team a little bit more on that.


Yeah.


Thank you.


Hi, John.


Hi, I'm Akshay from India.


I've got a question.


What is the best way to combat the plagiarism?


For example, my competitor is stealing the design elements


from my website that I created.


And it is taking advantage of it as it is ranking over me.


I've already reported that using the Google Search


Console under the copyright removal.


But they said that for each of the following URLs,


please identify the access content you have claimed


in frames upon the copyright.


So I wrote a detailed essay to your team.


But they replied that it is unclear to us


whether or not you are the authorized copyright


agent for the content in question.


So my question is that how can I prove my authenticity


and ownership that, yes, I created this content


and I'm the owner and that entering website owner


is copying from me?


I can't really give you legal advice there.


So that's kind of the tricky part


in that I am happy to help with the technical side


of these kind of things.


But I can't give you legal advice


with regards to what specifically


you should be submitting.


So I think the DMCA complaint is generally the right direction


if it's copyrighted content that someone is taking.


There might be some subtle differences there


that you need to watch out for that I don't know about.


Is it limited to the text part, or did you


consider the UX UI design perspective as well,


that if someone is scaling my image,


like changing the hue and situation colors


and reposting the same image on their website?


So is it considered as a plagiarized content?


I don't know.


I mean, I can't give you advice on that.


That's something where you'd need to check maybe


with a lawyer locally to make sure that what you're


submitting really fits.


I know there are sometimes sneaky people that


copy things in sneaky ways where it's


hard to differentiate if something is kind of just


a copy or if it's actually a new work that


is based on something else.


But those are the kind of decisions


that I can't make because I'm not a lawyer.


So I can't give you advice on that.


It's something I see in the forums from time to time.


What you might be able to do is double check


in the Webmaster Help forums.


I know there are some folks there


that do have a little bit of a better feeling


for the legal aspects there.


But if you need legal advice with regards


to what you can and can't do, then you really


need to make sure that you contact a lawyer yourself.


Sure, thank you.


Sure.


All right.


Hey, John, I have another question regarding


flexible sampling this time.


So it's about two years since flexible sampling


was introduced.


I know that there were a couple big publishers


that Google worked closely with for a few months, namely,


I think, the New York Times.


And we've implemented it on our sites.


And we've seen via a couple tests


some marginal improvement in organic search rankings.


But I believe that, given the limited information


and did some analysis of which publishers are currently


using flexible sampling, some aren't even


implementing it correctly.


For example, economist.com is not doing it correctly.


I don't believe the bostonglobe.com


is doing it correctly either.


And given that we're an Alexa top 1,000 site,


essentially, we feel almost as if flexible sampling has


been a bit of a neglected program.


And given the size of the site that we have


and that Google has historically worked


with publishers on this project, essentially, I


was wondering if there'd be a way to work more closely


with Google on this project, especially given


that we have a lot of data around the implementation of it.


You're welcome to send me something.


And I can pass that on to your team.


But I can't promise that they would have time


to look at this with individual sites.


So yeah.


I think, in general, with flexible sampling,


the one aspect that's always, I think, a little bit tricky


is that you basically have to find


that line of how much content you show to users by default


and how much content is behind your paywall.


You kind of have to figure that out yourself in the sense


that for some sites, for some queries,


it might be OK to show minimal amount of information


because users really, really, really


want to get to your content.


And for other kind of sites, maybe it's


worth showing a little bit more.


So giving a few more pages that they can look at automatically


or having a bigger snippet on the preview part


that they can look at.


So finding that balance, I think, is probably hard.


And that's something that more than probably the SEO aspect


has also a lot of indirect aspects


that flow into that as well, where if people always


go to your site and they never get any content,


then maybe at some point they just


won't go to your site as frequently.


On the other hand, if they go to your site


and they get all the content that you need,


then maybe they won't sign up.


So finding that balance between those two sides


is sometimes tricky.


And it's not something that I'd say is a technical question


or a question that we can solve for websites,


but it's really something that you almost


have to work out together with your users, with user studies.


But again, if you want to send me some information


that I can pass on to the team, feel free to do that.


I can't guarantee that they'll be able to get back to you,


but I'm happy to pass that on.


SPEAKER 2 OK, I appreciate it.


Thanks.


All right, let me pause the recording here.


You're welcome to stay on for a little bit longer


if you'd like, but just so that we have a reasonable length


for the YouTube video.


Thank you all for joining in.


Thanks for submitting all of these questions so far.


And I hope you all have a fantastic weekend,


and see you next time.


English Google SEO office-hours from March 26, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


I am a search advocate on the Search Relations team


here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts


where people can join in and ask their questions around search.


And we can try to figure out some answers.


Bunch of stuff was submitted already on YouTube,


so we can go through some of that.


But like always, it's always neat to get some live questions


as well.


So if anyone has something they'd like to talk about,


feel free to jump on it.


Hi, John.


I have two questions regarding AMP.


The first question is, is it a problem


if the AMP version differs slightly


from the canonical HTML version in that you have


a small ad in the AMP version, which is not in the HTML


version?


And secondly, I have discovered that the largest content


for paint for my AMP page, when I wait a while for clicking


on the search results page, is very high compared


to when I click immediately on a search result.


And I wanted to ask if that's normal.


Yeah.


OK.


So I think for the first one, that's perfectly fine.


So the pages should be equivalent.


It should be the same content, same kind of images,


that kind of thing.


But things like monetization, that can always vary.


And even within a normal HTML page,


you could have something like, I don't know,


dynamic ads, where sometimes you have an ad unit there,


sometimes over here.


So those kind of changes totally don't matter.


With regards to largest content for paint,


I don't know exactly when that starts counting when it comes


to the crux data.


But it would surprise me if the time on the search results page


were counted in that.


That would seem kind of the wrong way to set that up.


I checked the head-up display in the Chrome Canary version.


There you have the crux data that is transmitted.


And there I had 250 seconds after I waited some minutes


for clicking.


And when I clicked immediately, it just were three seconds.


So it was a little bit scary.


OK.


What I would do is contact someone from the Chrome side


to kind of let them know about that


and maybe see if that's the way it's supposed to be working


or if there is something weird just with regards to the data


that you see.


Thank you.


Sure.


All right.


Let me see.


Praveen, I think you have your hand up next.


Hi, John.


How are you?


Hi.


So first of all, thank you for these office hours.


These are free SEO classes for us.


A lot of knowledge is there.


Thank you for what you do.


So I have a very, very basic question, basically a doubt.


Suppose there is a website that has moved to mobile first


indexing.


So as far as I know, Google will use


mobile signals or mobile content to rank that website.


So the doubt is whether Google will use these signals just


for mobile rankings or even for desktop rankings.


Sorry.


What was that last part?


Will Google use mobile signals just for mobile search


rankings or desktop search rankings as well?


So we will index the content once with the mobile crawler,


and we will use that version with all of the signals


that we have as a basis for both desktop and mobile rankings.


So that's something that's mostly focused on the indexing


side.


It's not focused on things like Core Web Vitals,


where we do use different metrics for different places.


But just purely when it comes to the content


and how we would rank that content,


we would only use the mobile version.


Yeah.


Sure.


Thank you.


All right.


Xiao.


Hey, John.


So I have a question about the product variant.


So I read an article from Google Merchant Center guide.


They say that if you have two products


and have very different attributes,


but the same product, like green shoes, red shoes,


or maybe 2 GB computer and 10 GB computer,


in Google Merchant Center, they said


you should canonicalize to one of them


or the one without attribute.


But I am not quite sure it's the best thing


to do on general search.


Because sometimes I think it's probably better


to index them separately.


Because sometimes the difference do matter.


So I wonder what is the best practice for general search.


And why Google Merchant Center say


you have to canonicalize it?


I don't know what Google Merchant Center says there.


So that's kind of the one side.


But it is something where you can, at least


from the search side, you can choose whether or not


you want to canonicalize them or not.


And sometimes I think it makes sense


to have one strong page with all of the variants on that page.


And sometimes it makes sense to have multiple pages.


It kind of depends.


And I don't know exactly how the Merchant Center side plays


in there, because you also have the product


feed where you can submit URLs that end up


being canonicalized somewhere else.


So I'm not 100% sure what the best approach is there.


AUDIENCE 2 I see.


So if the two variants are significant enough


and people do search for the variant,


so it's better to index them separately, right?


That's what I would do, yeah.


But if they, like for example, if even two products are


very similar, but they are different color


and you index to one of them, will Google


pick it up, because Google knows it's different color, right?


So if we follow the rel canonical for that,


then we would only index the canonical version.


It's not that we would say, oh, we


know another page has a rel canonical to this page


and the other page is about red shoes


and this one is about blue shoes.


It wouldn't be that we'd know this is also for red shoes.


We would just see the blue shoes page


because that's what we index.


AUDIENCE 2 I see.


Thank you.


Sure.


Mark.


All right, sorry.


I got to mute myself first.


This is probably more of an academic question.


When I got it right, Google is now


able to show certain paragraphs of a site as a search result.


And now I wonder if you have something like a product


page where you can find third parties content,


like for example recommendations or tests


or something like that.


I mean, that is useful content for the user.


However, it's still duplicate content in a certain way.


So is there a chance to kind of mark these things as,


I don't know, do not index this paragraph or something


like that?


Not really.


So at least there's no direct way that you can do that.


So you could use the data no snippet


to say that this is something that you don't want


to have shown in the snippet.


That might be enough in a lot of cases.


If it's really content that you must avoid to have indexed


there, like if there are licensing reasons


or other legal reasons why it should never


be indexed like that, one of the things


you could do is use JavaScript to pull that content in


and use robots.txt to block that JavaScript file


from being crawled.


So that would essentially mean that when


Google tries to render the page, it


wouldn't be able to fetch the JavaScript file.


And therefore, it wouldn't be able to pull


in that other content.


I think that's something that I would


say for really critical situations


where it's really like there are legal reasons why that must not


be indexed, if it's just you prefer that this is not indexed


or you prefer that Google doesn't give this much weight,


then I would just let it be indexed normally.


If it's duplicate content within the website,


then we'll try to pick one of the pages anyway.


It's not that we will see your page


as being worse because it also has some duplicate content


on it.


Because it's kind of a really common situation,


especially with product pages where if you have products


from, I don't know, various sources,


you often have the original product description on there.


And then that product description is duplicate,


but that doesn't mean the page is bad.


All right, thank you very much.


Sure.


Rishabh.


Oh, man.


I'd probably say your name wrong.


Sorry.


No, no, that's correct.


That's correct.


It's Rishabh.


Hey, John.


Hi.


My question is mostly related to site migrations.


So we have a site which has a desktop and mobile version


separately for our website.


And we migrated, let's say, from XYZ to ABC.


And the desktop version will go to desktop,


and mobile version will go to mobile.


The m.xyz will go to m.abc.com.


So it's been a month and a half.


We have migrated from a different domain name


to a different one.


And we have also requested this change


of address using Webmaster tool.


Now my point is now I kind of convinced my developer


to remove m dot and have a responsive site.


And then they're going to remove m dot version and have abc.com.


So my question here is now, since there


is another redirection going to be happening from m


dot to our website, and since I don't have an option in change


to address because it's already going on from older website


to newer website.


So how it kind of impact overall on SEO


and how Google sees it?


I just wanted to understand about it.


I think that's perfectly fine.


That's like a normal move, essentially.


So that's something where I would set up


the redirects from the m dot version


to your new responsive version.


What I would make sure is that the change of address


that you have in Search Console goes to the final destination.


So if you have, I don't know, www and m dot,


that the change of address goes to the www version,


not to the m dot version, just so that we can really


transfer everything directly to your preferred version.


But otherwise, it's like setting up the redirects,


making sure the internal linking works well.


All of that, I think, is fairly normal.


So that should be fine.


So there's one problem that change of address


is already being used from older website to newer website.


So I don't have an option to kind of change it


from m dot abc.com to abc.com because it's been already


moved from xyz to abc.


OK.


But you're moving to the main website


then in the change of address tool, not to m dot.


Probably.


No, I didn't understand.


No, no.


So in the change of address tool,


it probably says moving to www, your new domain, right?


Your new site.


Yes, so change of address I have applied for a month back,


which is in process already and which is from older domain


to newer domain with respect to desktop and the mobile version.


No.


I think that's, yeah, that should be enough.


I don't think you need to do anything special there.


Also, the change of address tool helps us a little bit


to move things a little bit faster, but it's not critical.


A lot of site moves are done without the change of address


tool.


So if for whatever reason you can't use that,


then that's also perfectly fine.


So as long as it's pointing to the current site


that you want to have everything moved over, then


I think you're OK.


Got it.


Thanks, John.


Thanks.


Sure.


Mihai.


Hey, John.


I have two medium-sized questions.


I hope they're not that convoluted.


One is actually regarding the last topic with site


migrations and one of your favorite topics, which


is subdomain versus subfolders.


And this is with regards to a project we're working on


that is on a ccTLD.


They want to expand internationally,


so we're going on a generic domain.


And in terms of expanding to each individual country,


and since for each individual country,


the services differ a bit.


So it's not the case that we use HREF line, for example,


because there are different landing pages


specific to those countries.


So in terms of subdomain versus subfolders


and how the whole website, like the menu and everything,


internal linking is structured, does Google


have any, does Google treat the silos,


like these services are specifically


for this country different from a subdomain to a subfolder?


Or is it just in Search Console, you set up the geotargeting


and that's basically it and it's the same?


Yeah.


It's pretty much just Search Console


and kind of the technical infrastructure on your side.


So that's where I would just look like,


what's easier for you to maintain?


What's the long-term stable approach for you?


And then pick that.


And when it comes to internal linking,


there's no difference if the URL points to a, like in the menu,


if you link to a URL that is on a subdomain


or is on a subfolder, it's the same internal linking.


Google treats it the same.


That should all be the same.


Some sites, I don't know, for some reason have subdomains.


Others use folders.


I don't know.


We have to deal with both.


Yeah, we're looking towards subdomains


since the services, again, are different for each country.


So it's not the same page just translated


or anything like that.


So I think it makes more sense, even from a user experience


point of view, to kind of see that subdomain there.


But it's good to know there's not much of a difference


anyway.


And the second one is regarding geo-targeting, geo-IP


redirects.


And that one is, let's say the main site


targets a specific country.


And then you have subdomain that targets a different country.


But you don't want people from, let's say,


from the UK to type in the main domain name, which


is targeted to the US, and try to purchase something there.


IP redirects aren't the best solution


when it comes to indexing and everything


and ranking in those specific other non-US countries.


So with something like, I don't know,


maybe disabling the cart for somebody who is still


using the IP and detect that the user is not from the US


and then disable the cart or do something


that disallows them from actually


purchasing from a different country or anything like that.


Sure.


Yeah.


I don't see a problem with that.


Usually, when it comes to IP redirects,


and especially if you're just looking at one page,


usually it's like the home page where people type


in the address kind of thing.


Usually, the recommendation I have


is to only do that on the generic home page.


So you have www.yoursite.com.


That one redirects to the different country versions.


And the individual country versions don't redirect.


That way, the generic home page can be linked.


We can kind of crawl that.


We can see the hreflang annotations, things like that.


But essentially, the redirect goes


to whatever country version.


But the individual country versions


don't have any problems with redirects, blocking indexing,


or crawling.


But if most ranking signals usually


point to the home page length and everything else,


how do you deal with that when it comes


if the home page redirects?


So we would follow the redirect initially.


And we would probably see whatever US redirect


that you have there.


But if you have hreflang across the home pages,


then we would be able to treat that as a cluster


and say, well, we swap out the URL.


We do the ranking first and swap out the URL, essentially.


So that should just work.


So as long as you can crawl and index the individual versions


correctly, that hreflang takes care of Google understanding.


Yeah, I mean, it's not a guarantee.


Someone can still go to the wrong version.


And having a backup, like you mentioned, I think


is something you should always have.


A lot of sites use something like a JavaScript banner


or something which shows your wrong country version,


here's the right version for you, essentially.


You can also block the cart.


Blocking the cart, I think, from our point of view,


would almost be invisible.


I think the Google Shopping side might check things


like the cart to just make sure that if you're submitting


something with a fee that it's actually matching


what you can purchase.


But from a search point of view, it's


like one internal link that doesn't work.


It's like, whatever.


And usually the cart is blocked from robots.txt or no index


anyway.


Right.


Or maybe allow the cart, but disallow people


from choosing an address outside that country or payment.


But if our main site is, for example, on the United States,


or exists and it's expanding into the UK,


and using the homepage as a general page


to use those redirects, would kind of modify the whole US


structure that has been in place until now


and is ranking fairly well.


So if we want to avoid that and just


add a subdomain for a specific country,


just avoid the redirects, right?


General speaking.


Yeah.


OK.


Sounds good.


Cool.


Ritu.


Hello, sir.


Good morning.


Hi.


How is real?


Pretty good.


How are you?


I'm good.


Actually, sir, I have a few questions related


to my e-commerce store.


Actually, I'm working for a medical equipment store.


Like, I have a medical website equipment store.


And I have done so many techniques for it,


like to get the traffic and to enhance number


of new users for the website.


Like, I did company listing, forum posting, review listing,


and so many techniques I did.


May I know apart from these techniques, like,


which we can proceed for it to get good traffic


and to enhance visibility?


Like, I'm not getting for medical equipment.


Yeah.


I think that's always hard.


I don't think there's like one magic trick that gets you


traffic from search automatically.


I think following the best practices in general


for making a good website is always a good idea.


Making sure that you can get the word out is important.


But especially for medical topics,


anything that's a little bit more critical,


I would also keep in mind everything


around the so-called EAT, so the Expertise,


Authority, Trustworthiness, and to make sure that the site


that you're providing represents a really high standard


and that the content is of really high quality,


that it's put together by really people who understand what


they're doing, that it's not something run out


of a garage kind of a site.


And that's something that I think,


especially for the medical area, is super critical.


We have a blog post that goes into some


of that specific for the core algorithm updates


that we did, I think, last year at some point, where


it goes through a bunch of questions


that you can ask yourself.


And it also links to the raters guidelines


that talk a little bit about these kind of sites.


So we call them YM, YL, Your Money, Your Life sites.


And I would see kind of a medical e-commerce site kind


of falling into that category as well.


And there are various things that you can think about there.


And I don't think there's one simple trick


to make it look official.


You really have to make sure that you actually


do have kind of that official touch.


As for my experience, I did research on it.


I got very less techniques for it for medical sites.


For others related categories, we can go for lots of techniques.


But for this medical equipment store,


we have very little, not much techniques for it


to get the traffic and to enhance the number of uses


for the website.


Like content posting, I'm doing high quality content.


I'm doing in different sites.


I'm posting content syndication also.


I'm following for it.


And forum posting, these are all techniques I'm following.


But I'm not getting good results.


Yeah.


Yeah, I don't think there is one simple approach to that.


And I think especially when it comes to medical content,


I think that's super important that our algorithms are


very picky there with regards to what we show.


So I would look at the quality rater guidelines


and really think about how your site might be perceived


by the quality raters.


The quality raters don't make the algorithms.


But they do give us a lot of insight


into what we might do in our algorithms.


So I would strongly recommend going through that.


And I think it's, especially when


it comes to these kind of sites, it's less about the tactics


and really more about making sure that it really


is a legitimate business and that it's backed up


by appropriate, trustworthy sources.


So not just like high quality content


and doing all of this syndication,


all of these things, but really making sure


that it's written by doctors.


It's created by medical professionals who


are legitimate in their field.


So I have one more question.


So it has the visibility of this tool.


In general, e-commerce sites are normal websites for us.


So that's kind of the starting point.


So anything that you would do on a normal website


would apply for e-commerce.


I would also look into everything


around Google Shopping, where you


can go to the merchant center and submit a feed.


I think submitting a feed is for free now pretty much


everywhere.


So that's something that you can also set up.


A lot of e-commerce systems have connections


for that automatically.


So that might be an option to kind of be


a little bit more visible.


But otherwise, there is no special trick specifically


for e-commerce that you could do.


So can I know about brand monitoring mentions?


How do you mean?


Like in Sendra's, I have seen the option


of brand monitoring mentions.


So here I have seen some domains.


I got some mentions from some domain,


like some trustworthy domains which


are having good authority and good traffic.


And I'm seeing the number of mentions


are decreasing day by day.


What is the reason behind it in Sendra's tool, SEM-RISP?


I don't know.


I don't know what they're looking at there.


So that's hard to say.


I think it's also worthwhile to keep in mind


that a lot of these SEO tools use


kind of analysis that don't match what Google uses.


So just because it's flagged in the tool as something


that you should be looking at doesn't necessarily


mean that it's something that is critical for your site.


OK, so one more thing.


I'm facing in Google Search Console.


Google Search Console, I'm facing


like HRE fling tag errors issues.


So which factors we need to consider to resolve HRE fling


tag errors issues?


Yeah, it depends on the type of issue that you see there.


Usually, the HRE fling annotations are things that,


so the idea is that it connects to different language


and country versions of your pages together.


And in many cases, I think if you're not


aware of the specifics there, it sounds like your content


management system is going to be a little bit more


important because your content management system is


doing that automatically.


So if you're seeing issues in Search Console about that


and you never set anything up yourself around HRE fling,


then I would check in with the people who


are making the content management system or whatever


plugins that you're using there just to kind of see


what they might say.


But it might also be that this is something


that's been on your site for a long time.


And essentially, the errors there just


mean we don't use that markup at the moment.


It doesn't mean that your website will be less visible


because of those errors.


OK, so thank you so much for your time.


Sure.


May I just jump in here because she raised


a really interesting question?


OK, sure.


I've got kind of the same issue as Ritu does,


it's about writing in the medical area


without being a doctor.


You mentioned an interesting link


to a blog post, which could be very helpful.


Could you just post them in the comments or somewhere?


I have already shared in the chat.


Oh, OK.


Thank you very much.


Cool.


Yeah, the one about the core updates, essentially.


I mean, the core updates are not specific to medical sites.


But a lot of the questions and input around them


generally applies to that as well.


Yeah.


Your money, your life sites hit very hard.


I saw that my site went down to a middle line, which


might be fair enough.


But still, I want to kind of improve the performance,


obviously.


So any tip is welcome, really.


So my recommendation there would really


be to go and look at the quality rater guidelines


and really go through that and think about it more


with the perspective of if a quality rater were looking


at your site or at the general area


where your site is active in, like some of your competitors


as well, how they might respond to kind of review requests


there.


And the quality raters are not one-to-one mapping


to our algorithms.


But rather, they give us some input.


But oftentimes, going with that mindset


and trying to be objective when looking at your website, that


gives you some ideas of what you might


be able to do differently.


And sometimes, those are small things,


like just highlighting better who


is creating the content, where it's coming from,


who has reviewed the content.


Sometimes, it's bigger things where you kind of realize,


well, actually, if I'm writing about medical topics,


maybe I should make sure that I have


a doctor or some medical professional


actually review the content, kind of changing


the perspective there a little bit.


But all of these things are, I think,


trickier because it's not a pure kind of like yes or no kind


of situation.


You kind of have to look at your site


and think about what variations might there be that I could do


or where might I be kind of running


into issues unexpectedly.


There are also a handful of really smart SEOs


that have focused on the whole EAT topic.


And they write about this regularly.


They present at conferences about this.


I would definitely also look into that,


kind of some of the case studies that they have shown,


I thought were really insightful.


Super, thank you very much.


From a hosting company, basically the Indian home page no longer ranks in the Indian search results,


but rather the generic home page does rank, and the Indian one is as a site link.


And they're trying to figure out what might be the problem here.


I took a quick look at this before they hang out,


and I actually didn't see what exactly is happening here either.


So that they didn't figure it out kind of means they like,


I don't know, it's a tricky problem.


So one of the things that I tend to do with regards to hreflang


is first figure out if there is some kind of canonicalization


issue happening in that maybe the Indian version has


the same text as the generic version.


That could be something that could happen.


In this case, both of these home pages are indexed normally.


So that's something where it's easy to check with the inspect URL tool.


You can double check, are these pages indexed individually,


or is there some kind of different canonical associated with them?


Sometimes you also see that they're both indexed,


but one of them has a different URL as a canonical.


So maybe like a trailing slash or some extra parameter in the URL somewhere.


In this case, both of these are fine.


The other thing is looking at the search results.


Usually what happens when we have hreflang annotations


that we have processed, then we just show one of these URLs


in the search results.


So we would either show the generic English one


or the Indian English one.


And in this case, we're showing both of them.


So to me, that would point at us not


being able to process the hreflang annotations


for whatever reason.


I noticed the hreflang annotations here


are in a sitemap file, and it looks like we


can process the sitemap file.


So theoretically, we should be able to figure this out.


But for whatever reason, we're not picking that up properly.


So I pass this on to the team here to double check.


I haven't heard back from them yet,


but I'll see if they have something to bring back.


Usually the other thing that I recommend


for this kind of situation is that you always


have a backup plan because you never


know how people might be reaching your site.


And in this case, there is also a backup plan in place.


So it's kind of, I think, a geo IP redirect scheme,


similar to what Mihai mentioned, in that


if you go to the generic home page,


it redirects you to a country version.


So for me, it redirects me to a Swiss version.


So I assume that a user in India,


if they clicked on the generic home page,


they would be redirected to the Indian version as well.


So from a practical point of view,


we're not using the hreflang annotations properly here


for whatever reason.


But users are still reaching the right version of your site.


So essentially, the effect is almost negligible on your side.


So from that point of view, I think


it's something worth looking at from our side


to try to figure out what we're picking up wrong,


or maybe if there's something malformed in a sitemap file


or something like that.


But it's not critical on your side,


because users are still going to the right versions.


Your pages are still ranking properly for those queries.


All of that is essentially still working.


So I'll see if I can come up with something there.


But essentially, this wouldn't be


something I would consider as being critical or problematic.


MIHAI APERGHISLAVA, MD, PhD, FITZERAT MOHAMMAD,


FITZERAT MOHAMMAD, MOHAMMAD, MOHAMMAD, MOHAMMAD.


So you mentioned earlier where the main domain is,


let's say, for the US, and you want to expand to the UK,


but your main domain is already geotargeted towards the US.


That means that subfolders are kind of out of the question,


because you cannot geotarget the main domain on the US


and then just a subfolder for the UK.


You kind of have to use it for that.


No, you could do that.


You could do that?


Yeah.


OK.


So you could have the main domain


on the US and a subfolder for the UK or something like that?


I did not know that.


Just a comment here in terms of critical


that users can get to the right site,


but certainly a worry to the SEO team


that they're not getting credit for the sale


because it's no longer showing up as an organic visit,


and all of a sudden, they're seeing traffic going down


and sales contributed to organic going down.


But from a user experience, it's seamless for the user.


So I just thought I'd comment on that side.


OK, so the redirect doesn't count as a visit


from search in that case?


Mike, that's what my guess would be, that the geo redirect would


pick it up, and then it would be kind of like self-referral,


so like a direct visit at that point.


OK.


Yeah.


That's kind of awkward.


I mean, I'll double check to see what we can do on our side


there, but in general, with all of these hreflang annotations,


it's always something where you kind of


have to take into account that sometimes we get them wrong.


So if there's a way to make sure that kind


of the organic search refer stays in place over a redirect,


then that would be something I'd try to get set up there.


Hi, John.


Just adding to this code ID problem, just wanted to ask,


is it like I have checked the robots.txt file,


and it seems like they're mentioning


multiple instruction single line.


I think it's very unusual format for me


to see robots.txt in that way.


Usually we have one instruction per line,


but they are using multiple.


Can there be an issue?


Can it be some kind of crawling issue?


I mean, it might have an effect on crawling


of the rest of the website, but it wouldn't have an effect


on the home page here.


At least when I looked at the home pages,


we were able to crawl them individually and index them


individually, and they're also canonical on their own.


So that's something, if the robots.txt file is not perfect


and we can't crawl everything properly,


that would be affecting more the rest of the site and not


the home page.


So that wouldn't be affecting that one URL is


less visible in search.


It would either be not visible at all


because it's blocked by robots.txt,


or it would be visible in search because it's not


blocked by robots.txt.


Good, OK.


Sure, I think the next question I have on my list


is the other version of the hreflang issues,


where I would say, well, this is kind of the way


that it's supposed to be working.


So here, what's happening is we have a slash DE version


of a page, and it's no longer being indexed.


So if you look at it with the inspect URL tool,


it probably says something like it's not indexed at the moment.


And what is indexed instead is the AT version, so


the Austrian version.


And both of these pages are exactly the same.


And from our point of view, when these pages are exactly


the same, we will index just one of them


because it's exactly the same thing.


And we're kind of saving space.


We're saving bandwidth from crawling


and just picking one of those as the canonical.


So that's what's happening here in this case.


However, we are picking up information


that these are for different country versions.


So if you search with the German parameters in search,


then you do see the German version.


And you also see the Austrian version separately.


So while we're just indexing one of these versions,


we're actually showing the individual country versions.


And usually, from our point of view,


that's fine because the hreflang annotations are working there.


And we can show the different versions.


The way I check the individual country versions


is with the gl equals parameter in the URL.


So usually, what I do is I search


for something like a prominent piece of text on the page


and then simplify the URL that is shown on top for the query


so that it just has a query and then add ampersand hl


equals for the language and gl equals for the country version.


And by doing that, looking at the de and the at versions


of the search results page, you see


we're showing the right URL there,


even if we're just indexing one of those pages.


So it's confusing when you look at it in the Search Console


individually because it looks like, oh, it's


not being indexed.


And also, in the performance reports and all the other


reports in Search Console, it's confusing


because we show the canonical only there.


But in the search results, we show both of these versions.


So it's still essentially working properly.


It's just confusing with all of the reporting.


AUDIENCE 1 Hello, John.


What I wanted to add here is that we consider this


to be hreflang folding at first.


But the odd thing is that when we checked in Search Console,


we had no index HTTP header.


So we looked at the page.


There's nothing there, nothing as an HTML tag,


nothing in the header.


Then we've checked every other signals.


And then we saw that, for example,


we have a referring page that does have this.


And it's a 302, which makes me believe it kind of became


permanent redirect.


And now I'm thinking, are we in a case


where we have inherited that no index xRobots tag from the site


that is redirecting to us?


Because that's quite an odd one.


JOHN MUELLER I think that's just confusing reporting.


When I look at it in the systems here,


I essentially see we understand that these pages are the same


and that we're just picking one of them for indexing.


So I mean, the pages on your site, the DE and AT versions.


And I don't see anything from an external no index kind


of playing a role there.


If you're seeing that in Search Console, that feels like it's


just something in Search Console that's confusing.


Yeah, that was an odd one and completely different


from what we've seen before.


Because this folding has happened in the past.


But after resubmitting it, a few days later,


the pages were re-indexed.


We know the content is similar, so we


know what's the best practice here.


But usually, this would be fixed in a few days.


Now it's been more than a week, and it hasn't.


Yeah, I think since the content is pretty much the same here,


I would be surprised if submitting it to indexing


would change anything there.


So it's possible that you would be


able to achieve kind of like a temporary,


like it's indexed individually thing.


But from my point of view, our system


should be able to pick that up again fairly quickly


after it gets indexed and say, oh, it's


actually the same thing.


We should fold it together again.


And another thing here is why German


is being folded into Austria when


Germany is our main market?


So more signals are going to those pages in general.


So why selecting Austria?


I don't know.


So for canonicalization, we use a lot


of different factors, which do include things


like external links, but also internal links, sitemap files.


Lots of other things come into play there.


And my assumption is that these are seen


as being fairly equivalent.


And then it's kind of hit and miss,


like if it falls this way or that way.


So that's kind of, from my point of view, the situation there.


And I think you could go into there


and say, I will change the text significantly so that they


don't get seen as duplicates.


But I don't think you would see any positive effect from that


with regards to search.


So it would make it easier for tracking,


because then we would be able to keep them separate.


But I don't think you would see that they rank better


individually in search.


Yeah, usually when we have the swap,


the Austrian page ranks a bit worse than the German page.


So always when this swap comes in,


we see a decline in rankings because


of the signals of the Austrian page, which are clearly


not the same in Germany.


This is why I'm thinking the pages to be considered equal,


the signals are not there, at least not


the ones we're looking at.


Yeah, you're probably looking at the signal slightly differently


than we are.


Yeah.


I mean, it's some, like this kind of thing,


I could send to the team that works on the duplicate content


detection on our side and canonicalization


to see why we're doing it exactly like this.


But I don't see them saying, oh, it's


like something we should change it,


because they would look at this and say, well,


these are equivalent enough.


It's like, obviously, you see some slight differences there.


But for the bigger web context, we would say, well,


it's the same content.


We pick this one, we pick that one,


it doesn't really matter.


So that's some, I mean, from my point of view,


if you wanted to have them indexed individually,


making sure the text is unique is definitely an option.


I don't think you would have any big effect from that,


though, otherwise.


So that's kind of the trade-off that you would have there.


Like, invest a lot of time to make the text unique,


or just keep them like that and focus on some bigger problems


there.


It's hard to say.


SPEAKER 2


So geotargeting is different than hreflang.


With hreflang, we essentially don't change anything


with the rankings.


We just swap out the URLs.


With geotargeting, we do use the location


as kind of a ranking factor, especially


if we're thinking that the user is looking for something local.


So geotargeting is not the same as hreflang.


So in other words, if you have content from multiple countries,


then I would try to make sure that you can use geotargeting.


If you just have content in different languages,


then hreflang is obviously fine.


With regards to translated content,


that's like completely different content.


I don't know.


When I talk about this internally with the teams,


it's like there are different opinions in this in regards


to when it's necessary or when it's not necessary.


I think, in particular, when you see


that people are reaching your pages with the wrong language


or kind of reaching the wrong language version of your pages,


then to me, that's a sign that hreflang would be useful.


And this is particularly the case if we see or if you see


that people are searching in a way that


is hard to recognize a language that they're actually


looking for.


So that could be something like they're


searching for your brand name, and you have the same brand


name in lots of different countries,


lots of different languages.


Then just by the brand name itself,


we don't really know which language version


to show to users.


And in cases like that, hreflang is absolutely something


that is super useful because then we


can swap out kind of the right home page for your site


based on the user's language settings and their location.


When it comes to more long tail queries


where people are searching for, I don't know,


I would like a blue running shoe of this brand,


then that query itself is already in a specific language.


And based on the query alone, we can recognize,


well, this is that language, and those words are on this page,


and we can map this page to that query fairly well,


then the language usually is going to be the same thing


across those two pages.


So for that, from my point of view, hreflang is less critical.


It all, I think, depends a little bit


on how people are searching for your site,


but also what options you have available for your site.


If it's a case of either you turn on hreflang for everything


or you don't turn it on, then obviously turning it


on for an international site definitely makes sense.


If you have to implement hreflang individually,


manually, then I would be a little bit more picky


with regards to which pages you actually set it up on,


because it's a lot of work to implement this properly


and to keep all of that maintained.


So those are my thoughts there.


And yeah, I think I answered that question.


Do you recommend a short URL structure without directory


depth?


In my understanding, it's not bad to show users


where they are.


Yes, absolutely.


So essentially, the URL structure


that you have on your site is something


that you can use however you want.


Google does not count the number of slashes in your URLs


and say, oh, this is like five levels down.


Therefore, we will not show it as visibly in search.


You don't have to have an artificially flat directory


structure.


So from that point of view, if you have a directory structure


that users can recognize and where you can tell that


sometimes people are even typing in the URL


or copy and pasting parts of a URL together,


I think that's perfectly fine.


There's no need to hide that kind of URL structure


from users by doing URL rewriting, anything like that.


For the most part, we treat URLs as identifiers of content.


We don't try to understand the site structure based


on the URL.


So essentially, setting up your URL however you want


is our recommendation there.


It's definitely not the case that you need to artificially


make it look different.


Can we spend a few minutes talking about sitemaps


and sitemap index files?


Specifically, is there a rule of thumb


around when an index is appropriate


and does sitemap naming matter like URL structures?


So we just said URL structure essentially doesn't matter.


You can use whatever you want.


You can also use whatever you want for sitemap file names.


Also, for the contents within a sitemap file,


totally up to you.


Some people have a lot of URLs in a sitemap file.


I think you can have up to 50,000.


Some people have a lot fewer URLs per sitemap file.


The trade-off there is essentially


having a lot of sitemap files versus having fewer


sitemap files.


Having more sitemap files makes it easier


for you to drill down on specific sitemaps


in Search Console.


So that can be useful.


It doesn't change anything at all for Search.


So essentially, what happens in our systems


is we process these sitemap files when we get a ping,


and we throw them all into the same database,


and then we crawl the URLs that we find there altogether.


So it's not the case that any kind of sitemap file structure


that you have changes anything with regards to how we crawl


the URLs on your site.


I think if you have one sitemap file per URL,


then you're probably overdoing it,


because it's like we have to crawl almost twice as much


to get all of the URLs.


But anything between several URLs per sitemap file


and all URLs on one sitemap file, that's kind of up to you.


Just wondering if you have any insights on what


impact switching from www to non-www has on indexation.


So essentially, this is kind of like a site move,


but you're staying within the same site.


And for that, you'd essentially just set up the redirects


and make sure that all of the signals, all of the information


that you give us aligns with your new preference there.


So making that kind of a change is


something that will take a while,


but probably it'll be pretty straightforward and pretty


smooth, because everything stays within the same site,


and you're just kind of shifting URLs around.


I would expect that there is some fluctuation


as we process these, but I wouldn't


see that the same as when you're moving from one domain


to another.


So probably it just takes a while to be reprocessed,


and then it'll be fine.


Question is about offering relevant content.


As you say, Google gives priority


to relevant and unique content.


But in the tourism sector, when we change content


so it affects the Google ranking as well,


please, let's see, is it possible to maintain


the same position by changing the content as well?


So I'm not quite sure what you're referring to here.


So that's kind of tricky.


But in general, if you change the content,


then I would expect to see changes in search,


because we should be reflecting what


the content is on your site.


So from that point of view, it's like, I don't know,


if you're changing things on your site,


then usually you should see changes


in how we show that content in search.


And if you're working to kind of improve things on your site,


that means you would see improvements in search.


Of course, if you just swap out all of your content


against something that's less useful, less relevant for users


then maybe you don't see improvements with that.


But there is no kind of, I don't know,


magical trick to going in and saying,


I want to change all my content.


I don't want to see any changes in search,


because that wouldn't match what we would see on your site.


OK, wow.


I think we still have more and more and more and more


questions.


And I see a bunch of raised hands as well.


But I need to pause the recording here.


I can stick around a little bit longer if any of you


want to hang around as well.


We can continue to chat about these things


and go through some of the remaining questions.


But thanks for submitting so many questions,


for coming over, hanging around so long,


asking so many live questions as well.


And hope to see some of you again


in one of the future ones.


All right, thanks a lot.


Looking back on 2020 with Search Relations | Search Off the Record

La, la, la, la, la, la, la, la, la, la, la, la, la, la, la, la,


la, la, la, la, la, la, la, la, la, la, la, la, la, la, la,


hey.


Welcome, everyone, to the next episode of the Search


Off the Record podcast.


Our plan is to talk a bit about what's


happening at Google Search, how things work behind the scenes,


and who knows, maybe have some fun along the way.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


I'm joined here today by Martin and Gary, who


are also on our team.


Hi, Martin.


Hi, Gary.


Hi, John.


Buongiorno.


So this will be our last podcast episode this year.


We'll, of course, have more of these next year, so stay tuned.


Martin, looking back at this year, what are your thoughts?


What is left in your mind?


Oh, that's a great ball to be thrown, I think.


I mean, all of you probably know that we


had a bit of a situation going on worldwide,


and that that pretty much has toppled over everyone's plans.


What?


I know, right?


It's mind-boggling.


And it was quite interesting to observe


how it changed the way that we do events,


because we had planned our Webmaster Conference series,


and we had lots of events lined up.


And then we also had lined up a bunch of external events


that we would be going to.


And I remember having a coffee with Gary


and planning out the event series,


and we wanted to expand the events as well to meetups


and things.


And that somehow did not really happen this year


for some obscure reason.


But it was quite interesting.


That's a shocker.


But it was interesting to see that we


started a few initiatives that basically helped


us get across the message anyway and basically shift


our strategy as needed.


So before this all happened, our producer, Anna,


was like, hey, how about we create a short talk version


of the talks that you have at the in-person events?


And we put them on the YouTube channel.


And we were like, yeah, that sounds great.


And we had recorded a few of these


beforehand in the studio, which was really nice.


So we had something more or less ready to publish


when we basically ran out of the possibility


to actually run real in-person events.


And that means that we needed time to actually figure out


what to do instead.


And Gary and I have quite differing opinions on that,


I think.


I understand Gary's point.


I think, Gary, you're not really into virtual events, are you?


What do you mean not really, but all into virtual events?


And then the Chrome team made their web dev live event


happen.


And it was a great event.


It's just I was lacking the interaction with the audience.


It was really nice for the one-to-many kind of like,


let's share the message that we have.


Let's share the insights that we gathered from the community


with the community.


But it didn't have this dialogue kind of thing


that usually happens in the hallway tracks


or in the panels at the in-person events.


So I decided we should try something new and different.


And it turned out to be not that easy and actually quite tricky


to get this right in terms of making the audience size not


too large and basically making sure


that we have enough content and also facilitators


for interactive sessions.


And that's how the unconference came to be.


And I know that John had been a facilitator in the unconference


sessions.


How was your impression of the first unconference that we did?


I thought it was super cool.


I think one of the things in the beginning I was a bit afraid of