between desktop or mobile.


English Google Webmaster Central office-hours from May 1, 2020

Am I correct in believing that both desktop and mobile


rankings are derived from the Google indexing,


the mobile version of the website?


So would you say if we had to choose


which one from an SEO point of view to improve,


then the mobile version would be more important,


as this would impact rankings on both?


Although we receive more traffic on mobile,


the bounce rate is also higher.


So in general, if we've switched the website over


to mobile-first indexing, which we've


switched most websites over to mobile-first indexing now,


then we would only be using the mobile version for indexing


as a basis for understanding what is on the website,


as a basis for understanding the context


between individual URLs of a website.


So we would really only be using the mobile version for that,


especially if you have a different version on desktop


and mobile, then we would essentially just


be using the mobile version there.


So if you're really in this, I'd say, tough situation


that you need to decide which of your versions


is your favorite one to work on more,


then if we've switched to mobile-first indexing,


then I think the mobile version is probably the one


that you should be focusing on.


However, I wouldn't say that you can completely


delete the desktop version, and everything


will continue to be OK, because probably you still


have a lot of users on desktop as well.


Usually, my recommendation for people


who are working on their website and trying to figure out


desktop or mobile is to find a way


to move more of the content to a more responsive design


so that you just have one version,


because if you just have one version to maintain,


then you don't have to make that choice.


And by fixing the content once or the pages once,


then you're essentially fixing it for all of your users.


So moving to a responsive design would make this a lot easier.


If you absolutely can't move to a responsive design,


you need to pick one or the other,


and you really only care about SEO,


which is kind of tricky in itself,


then the mobile version would be the one to focus on.


Does the product listing page lose page rank


or some other signals?


If the product listing page has links


pointing to filtered listing pages that have meta robots


no index pages?


So I think this kind of goes back


to theoretical understanding of how page rank flows


within a website.


And this is actually something that our systems


are pretty good at.


So it's not something where I would


say that a normal website needs to worry about how


these kind of pages are linked together


with regards to how page rank flows within a website.


Usually, the bigger impact here, especially


with an e-commerce website, if it's a larger e-commerce


website, is the crawling side in that if you have links


to a lot of filtered pages that have unique URLs,


maybe there are extra filters or facets in those URLs


themselves, then that's something


where we would have to go off and crawl all of these pages


before we recognize there's actually no index there.


So from a crawling point of view,


I would try to keep it as clean as possible.


But purely from an indexing point of view


or from a page rank point of view,


this is not something that I would really worry about.


Does a link in the content of a page which


already exists in the main navigation


make any sense from a ranking point of view?


So I think this kind of goes back


to links in the main content versus in things


like the sidebar and the footer, those kind of things.


From my point of view, this definitely


makes sense if it makes sense for your users.


Purely from an SEO point of view,


if a link from one page to another


already exists on a page, then having that same link


there a second time doesn't change anything.


But users are probably more important.


And you probably want to make sure that they actually


convert on your website.


So making a website that works well for users


would be my priority here.


It's not that I would stop linking internally


within a website just because you already


have one link there, which might be enough from an SEO


point of view.


If an internal link is underneath some text


but related to that topic, does Google still


understand and recognize that?


Or should the internal link always be within the text?


We do try to understand the context of internal links.


So things like anchor text and the text around that link,


they do help us to understand a little bit more.


But if you're asking the link within a block of text


or just right after a block of text,


I don't think that plays any role at all.


So that's not something I'd worry about.


We have a number of categories on our e-commerce site


with one or two items in them.


While it might be easy for users to visually find them,


would it be better if these categories were removed or 301ed


and the products moved into bigger categories,


as currently those categories are weak


and have created a lot more internal links going


around the site?


Yeah, so this is something that is something where you almost


need to figure this out for your website individually.


Usually, it's more a question of if you have a flat website


architecture where everything is linked together, maybe where


you have very few categories, or if you have a very,


I don't know, deep website structure where essentially


any user or search engine, if they


want to go to a specific product page,


they have to jump through a bunch of different categories


or subcategories sections to actually find those pages.


And essentially, what you want is something


that's kind of a mix there.


You don't want it too flat.


Because if it's too flat, then it's


hard to understand which pages belong together.


And you don't want it too deep, because then users


have to click around a lot to find those pages.


And search engines have a lot more trouble


finding and recognizing the importance of individual pages


on your website.


So finding that kind of balanced size


where you have enough items in each category


to kind of make sure that it's more of a, I don't know,


a balanced view of a website where it's not too flat,


not too deep, that's something that I tend to recommend.


But there is no hard, I don't know,


guideline where I'd say two products is not enough,


or you should make subcategories if you


have more than 20 products.


That's something that you almost need to look at from a website


to website basis.


And it's sometimes hard, because obviously, your business


will grow over time.


And you'll have more of some kind of product.


And you'll have fewer of other kinds of products.


And at some point, you almost need


to restructure the kind of category, subcategory setup


that you have there.


And purely from a search point of view,


these kind of restructurings to make things


a little bit more balanced, I'd say they definitely make sense.


But it's always something that involves a lot of effort


to make sure that you're setting up redirects and everything


properly.


So I wouldn't just blindly jump in and say,


two products is not enough.


I will redirect them and fix things.


Then a long question about Discover again.


I'll take that to the team.


Our blog section of our website just


has a lot of articles categorized by month.


They were uploaded.


There is no grouping as such as to putting all related articles


within a particular section together.


But there is some internal linking


between related articles.


Could that be the main reason that our articles are not


indexed anymore?


They used all the index.


But then after a particular algorithm update,


you de-index them.


It's the only part of the website that is de-indexed,


even though the information and the articles are good quality.


I don't think this would be a reason for our systems


to de-index a lot of articles on a website.


Essentially, we need to be able to discover those pages


so that we have the opportunity to go out and index them.


But if we can discover those pages


and they're just linked in a way that might not be optimal,


then that generally wouldn't be a reason


for us to say those pages themselves are not useful


enough to actually be indexed.


Usually, when I see questions like this, where it's like we


have a bunch of articles and suddenly they're not


being indexed as much as they used to be,


it's generally less of a technical issue


and more of a quality issue.


So it's not so much that we can't find those pages,


because probably they're still linked within your website,


or at least they were findable in the past.


It's probably not the case that we can't index them,


because that's probably easy for you to check.


And you can double-check that there is a not and no index


and that they can be crawled properly without crawl errors.


That's usually pretty easy to double-check.


But it's more a matter of just our algorithms looking


at that part of the website or the website overall


and saying, we don't know if it actually


makes that much sense for us to index so many pages here.


Maybe it's OK if we just index a smaller part of the website


instead.


So that's something where sometimes it's


worth taking a hard look at your site


or getting someone more neutral to look at your website


and to give you some advice and say, well,


it looks like all of these articles


are about irrelevant things that happened at some point.


And maybe they were relevant at some point in the past,


but they're not so important anymore.


It might be that someone looks at these articles and says,


well, it looks like you've been rewriting existing articles


from maybe other people's websites.


Maybe that's not such a great thing to do.


Maybe that's something that Google doesn't really


appreciate, which is definitely true.


But all of these things are elements where sometimes when


you're creating this website, it's like, it's your baby,


and you're doing the best that you can to make it grow.


But having someone neutral look at it


can sometimes give you a little bit of a, I don't know,


a little bit of a kick to actually be a little bit more


critical with your website, with your own content,


and to find ways to significantly improve it.


And I realize that's always hard to hear,


and there is no simple path to significantly improving


a website.


But sometimes that's really the direction


that you need to head if you care about this website


and the way that is shown in search.


When you search for basically anything meme generator,


those three pages of the same website show up.


So there's one website that shows up,


and other sites don't show up, which arguably


have better meme generators.


So I can't judge the quality of these meme generators,


so it's really hard to say there.


But in general, it can happen that a bunch of pages


from the same website show up for individual queries.


And that's something where with our algorithms,


we try to limit the number of pages


that we show for normal generic queries from the same website.


Usually that limit is, I don't know, maybe two or three


results from the same website.


But if our algorithms have kind of a sense for the user


actually searching for one specific website,


then we will definitely show more results from that website.


And sometimes our algorithms are kind of on the edge


there or don't understand the query properly,


and they show more from one website


than maybe they should from others as well.


But in general, it's not something


where we would say it's clearly broken


if there are three pages shown from the same website.


So that's something where if you're seeing individual queries


where you feel, well, this could be improved,


if there were more diversity in those search results,


then I would definitely use the feedback link


on the bottom of the search results pages,


because that does go to the team that works on these pages.


But at the same time, I would also


see it as something where reasonable people can argue


in both directions on that topic.


And it's not something where, for the most part,


we would see this as a clear bug if we showed more pages


from the same website in a particular query.


Internal WordPress search question,


Ahrefs shows me duplicate content issues


on my internal search pages.


Is this a problem for Google even when there are noindex?


Can you tell us the best practice for internal search


on content pages?


So if these pages are blocked by robots text,


blocked by noindex, noindex robots meta tag,


then essentially they would not be indexed,


and we would not see that duplicate content.


So just purely from that point of view,


that's something where probably it's


good to take this kind of feedback from tools


and to double check that it's working the way that you want


it.


But in this particular case, I think that's OK.


Even if there is duplicate content on these pages,


if they're not being indexed, then you're


kind of doing the right thing.


With regards to internal search pages in general,


I would tend to differentiate between different kinds


of internal searches.


In particular, if you make your internal search pages


so that they're more like category pages,


then that feels like something that makes sense to be indexed,


at least maybe the first page of that.


On the other hand, if the internal search pages are


essentially any random keywords that people can provide


and you will create a search page for that,


then that feels like something that probably is not


worth indexing individually.


And then it's more a question of,


should you be blocking these by robots.txt


so that they don't go to your server at all,


or should you just use noindex?


From our point of view, both of these are valid options.


The robots.txt option makes a lot of sense


if those searches on your website


create a significant load in that you don't want


random crawlers to get stuck in those search pages


and start to try to crawl through a whole bunch of pages


like that.


On the other hand, using robots.txt also


means that we don't know that these pages should not


be indexed.


And it's possible that if someone


links to one of these pages, we would


index that page without knowing the content, of course.


So noindex might be better.


I tend to focus more on the noindex side


rather than using robots.txt for internal search pages


just because that gives you a little bit more control.


And again, if these search pages are more like category pages


in the end, or if you use the same setup for your category


pages as you would use for your internal searches,


then having those category-like pages indexed


is perfectly fine because they're also useful for users.


Client has a medical-based information page.


Now they want to also create a community


or a forum on their subdomain.


During the time of EAT, should they totally noindex the forum


because normal users will discuss there


about medical topics?


Or does Google recognize that these topics


are community-driven?


We want to avoid conflicts and problems with the main domain.


So EAT is not really a ranking factor in the sense


that you need to optimize those attributes for your website


in order to rank well.


So that's kind of the one thing there.


But I would try to see this more from a user point of view


rather than purely an SEO point of view.


And from a user point of view, it can certainly


make sense to have some kind of a forum or a community


associated with an existing, maybe well-known medical brand.


But you probably want to make sure


that it's positioned in a way that it's really clear,


that this is actually user-generated content.


Maybe it's not vetted by medical professionals.


Maybe it's people who are just anecdotally giving advice


on what they observed during, like,


maybe they had one of these diseases as well.


And anecdotally, they noticed that things


got better when they did something specific.


And purely from a medical point of view,


that might be more correlation, not causation there.


So it might not be really clear medical advice


that people are posting there.


So from that point of view, you probably


just want to make sure that it's positioned appropriately


for users.


So instead of focusing on how that would work from an SEO


point of view, make sure it works well for users first.


And then usually, the SEO side kind of falls into place


on its own.


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


If in some cases I can't automate the site map


on a back end, will crawler-generated site map


be a second best option?


Or in this case, is it just better not


to include an XML site map at all?


I would strongly recommend finding


ways to automate the site map file,


because you really want to make sure


that every small change that you make on a website


is reflected in the site map file.


And usually, that means if you have a larger website,


it's a lot easier for us to actually find those changes.


I think if you're crawling your own website


to generate a site map file, then you also


have to keep in mind that maybe Google will just


crawl your website and figure out


which URLs are there as well.


So it's hard to say that you're actually


staying ahead of the curve by providing a site map


file versus just letting Google crawl on its own right away.


However, sometimes this does help


us to get started with a website.


And even with smaller websites, sometimes


if you change something that's kind of lower level


within the website, then bubbling that up


through an updated site map file can help.


So my recommendation here would be


to strongly look towards finding automated solutions


for the site map file.


But if you still want to provide your own site map file


and you crawl your own website for that,


then that's still an option.


It's not something that you should avoid, let's say.


What will be the best solution if we'd


like to run a test for two weeks where


we change bits of the content, such as, for example, an H1?


The current setup limits us to change the content directly


on the page for a portion of the traffic.


This means that users and crawlers see the changed H1.


Could this impact rankings if the H1 is completely


different to what we had?


What if we ran a test like this every few weeks?


So I think the question is kind of refined to,


if I change my content temporarily,


will Google reflect that in search?


And yes, if we see that the content has changed,


then we will reflect that in search.


So these kind of tests where you're


changing the content to see kind of what the reaction is,


they would tend to have a reaction.


It might be that the reaction is very subtle and very small.


So if you're just kind of moving text blocks around on a page,


and Google sees the same text in just different positions


on a page, then probably for the most part,


that wouldn't change anything.


But it would still be indexed as a new page,


because you change things on that page.


If you ran such a test every couple of weeks in general,


you would have this change in indexing every couple of weeks,


which from my point of view, probably just makes it harder


to track the results properly.


Because when it comes to search, it's


a little bit unclear when exactly a page


would be reprocessed.


So if you're changing, let's say you're


changing a page once a week, and we recrawl and update


our index for that page every, let's say, six days,


then depending on when you make those changes


and that time frame of when we recrawl and reprocess


that particular page, those effects


might be visible in search in a way that


makes it really hard to track back


what actually happened there.


So if you're making these kind of changes frequently


on the same URLs, then it's really


hard to determine which particular change resulted


in which particular change when it came to search.


If we could change the current setup,


what would be the best option?


For example, using a parameter to change the content,


canonicalize to the product page without a parameter.


What would be a good solution that


would allow a significant amount of testing that doesn't


hurt our organic visibility?


So one approach that I've seen in general for A-B testing


is to set up different versions of the page


and then to canonicalize, like you mentioned here,


so that for indexing, we would tend


to focus on that canonical version.


That seems like a good approach.


The other thing to also keep in mind


is that if you're testing different things, sometimes


maybe it's also worth seeing how that reacts with regards


to SEO as well, because maybe there


are changes that you could make on a page which


don't harm your visibility in search but rather improve it.


So that's something where sometimes maybe it


doesn't make sense to completely decouple those tests


from search.


Wow, we just have a few minutes left.


Whole bunch of questions still remaining,


but maybe we can switch over to any questions from you


all in the meantime.


I have a question, John.


So I've got this website showing up in the cert


with the wrong opening hours.


Actually, I thought the reason was


due to some pages that were crawled back at Christmas time.


They showed the Christmas opening hours.


We got Google to recrawl all of those pages,


checked it in Search Console.


But still, the wrong opening hours


are displayed in the cert as a special feature,


not as a snippet from the website itself.


What data source would these be based on now


that everything seems to have been crawled correctly?


I don't know.


Hard to say.


OK, in general, if it's from the page itself,


then it might just be a matter of us recrawling that page


and being able to reprocess everything appropriately.


Sometimes it's not updated from the first time


that we recrawl a page, especially


the derived metadata of a page.


That's something that sometimes just takes a little bit longer


to be reprocessed.


That might be one thing.


The other thing is that it might also


be that we're associating other data


with that particular page.


So for example, if you have a Google My Business listing,


and we know that it's associated with this website,


and you update the hours in the Google My Business listing,


then it's sometimes a matter of, well,


do we kind of match those hours?


Do we also show that on the website?


Are these things that should be treated separately?


That's sometimes tricky.


So that's the other thing I might look at there.


If it's really been in place for a longer period of time,


and you're sure that things have been recrawled and reprocessed


a couple of times, then I'd love an example like that.


If you could send it to me, and I can take a look at that


with the team then.


SPEAKER 2 OK, I'll do that then, because we've


checked everything now.


SPEAKER 1 OK, sure.


You can just drop it here in the chat,


and I can pick it up afterwards.


It's already there, yeah, great.


SPEAKER 3 Hello, John.


Hi.


Yeah, OK, so I have a question regarding


the length of how Google algorithms can remember signals


and things for a certain website from the past.


So let's say, the question is, if these algorithms detect


patterns that appear in the span of several years,


or they in general focus only on the current state


of the website or page, minus the lack for recrawling


or something like that.


So let's say we screw something up very badly,


but then we fix it afterwards.


Is there a possibility that it will be still


doomed for next I don't know how many years?


So let's say one mistake in the past


can trigger a penalty several years later.


Is that possible?


Usually, we try to focus on the current situation of a website.


So if the current setup is correct,


then that's something that we would focus on there.


There are very few situations where things


linger a little bit longer.


One might be with regards to links.


So if there are external links to this website,


and you fix some of these, and it's just a matter of us


reprocessing all of these things,


then sometimes that can take a significant amount of time


to be updated.


Another one that I've seen from time to time


is with regards to geotargeting.


If you significantly change the targeting of your website,


then sometimes that just takes a while to be updated.


I think for the most part, those are the ones.


There are some really weird edge cases sometimes


that just stick around for a really long time.


But that's not something where I'd say that's by design.


And if you do something like this wrong,


then you're stuck with it forever.


But usually more a matter of weird systems on our side


that are not updating as quickly as they could be updating.


So I think, especially when it comes


to things like technical issues, that's


something where if you fix those issues, if we can recrawl


and reprocess those pages, then that's fixed.


That's not something that would linger for longer.


AUDIENCE 1 So would you say it mostly


concerns third parties, like links, for example, right?


That it's not so easily crawlable


when it's on our website?


Yeah, yeah.


I think there might be some.


I mean, just because we look at the cases that go wrong,


I feel like sometimes there are lots of things


that are going wrong.


But it's probably just a very small subset of pages


where I really see things stick around a little bit longer


than I'd like to see them stick around.


I think another case where I've seen something similar


like this happen is when we recognize that a website is


really, really spammy, and they go out of the way,


and they clean things up completely,


then it's possible that our algorithms might think,


oh, well, this is just an affiliate website.


We need to be a little bit more careful here,


and that this kind of status sticks around


for a little bit longer.


Or for example, if we recognize that a website


is an adult website, and at some point


we pick up that information, and if the website itself changes


completely or if the same domain name is reused


for other purposes, then that's something


where it can sometimes take a little bit longer


for our algorithms to kind of get used to the current state.


And by a little bit longer, that can sometimes


be a couple of months.


That can also be several years.


OK, thank you.


John, sorry.


I know I've asked a question already, but.


Sure, go for it.


Thanks.


I've always wondered if high value keywords,


like a big section of the population


is searching for certain keywords,


is there any human part of the algorithm


that qualifies these high value key terms?


Or is it all just algorithms called by bots?


It's pretty much all algorithms all the way, yeah.


I think there are some aspects that


might look like there's a little bit more human touch to them.


In particular, when we see that certain types of queries


tend to be a lot more spammy, then what can happen


is that the web spam team will go through those search results


and try to figure out which one of these


are actually legitimate content and which type of this content


is more spam.


And then it's not so much that they're


kind of like determining the search results,


determining the order, but rather they're


looking at those queries and saying,


well, this is a really important query.


Lots of people are searching for it.


And we're providing terrible search results


because spammers are getting through our system somehow.


Therefore, we need to take manual action


on some of those sites.


So it's not that we're filtering or sorting things out


for those queries, but rather that the web spam


team takes the time to look for the normal type of spam


within some of these queries.


OK, yeah.


OK, I think we're pretty much at time.


I'll pause here, but I'll remain online a little bit.


So if any of you want to stick around,


you're welcome to stick around kind of off the record,


I guess.


So thank you all for joining in.


Thanks for submitting so many questions


and for asking so many things.


I hope you all have a great weekend.


In the meantime, I'll set up the next batch of office hours


probably early next week.


So if anything is still missing, you're


welcome to drop those in there.


Or of course, drop by the Webmaster Help forums


or catch us on Twitter.


All right, thanks a lot, everyone.


And I wish you a great time.


Until next time.


How to make your ecommerce website stand out in Google Search (6 Tips)

Last episode, I shared 8 tips for SEO, techniques that can help you improve your rankings in


search results.


In this episode, I talk about your appearance in search results, with extra attention to


products.


My name is Alan Kent and I'm a Developer Advocate at Google, focusing on e-commerce.


Let's get into it.


Your ranked position within search results is obviously important.


The higher on the list, the more likely you are to be seen and visited.


Well another way to stand out is your visual appearance in search results.


Originally search results were text and blue links.


These days, search results are shown in different ways to help users more easily understand


the results.


Images can help users better understand your product.


Our ratings can help increase user trust.


And pricing and availability data can help users choose between sellers.


So let's look at 6 tips on how to improve your appearance in search results.


The first tip is to check the title links Google is showing for your products in search


results.


A good title link can greatly help users understand your offering, bringing quality traffic to


your site.


Title links are normally extracted from the title element in the HTML markup of pages.


If Google thinks a title looks incomplete, or does not match the page contents, it may


look at other sources, such as the main visual heading of the page, or even the source text


of links to the page.


If you automatically generate page product titles from product attributes, take care


to avoid duplicated information or poorly formatted titles due to missing data.


Low quality title links can harm a user's impression of your site.


Another challenge with title links is there can be a lag of multiple days before an update


on your website is visible in search results.


This means putting dynamic information in a title, such as current stock levels or price,


is not recommended.


A simple way to check how your titles appear in search results is to perform a site search


specifying the URL.


In the Google search box, enter site, colon, and then the URL of your page.


It is a good idea to check multiple pages to ensure title links are as expected.


If no match is found, use the URL inspection tool to check that a page has been indexed.


Collecting site analytics data can help determine the effectiveness of different titles.


If you try to change the title over time to see which works better, make sure you allow


sufficient time for Google to index each variation.


Experimenting with different titles can help determine the importance to your customers


of different product attributes, such as brand name.


To improve your title links, check out Control Your Title Links in Search Results on Google


Search Central.


Follow the provided advice as best you are able.


The second tip is to include high quality images that showcase your products.


Google may display these images directly in search results.


We have observed that users generally respond well to high quality images and recommend


that key images be at least 1200 pixels wide.


Again, the best way to see if product images are being shown in Google search results for


a page is to perform a Google site query specifying the URL of the page.


You may also like to perform an image search specifying your domain name in a site query.


The first step to improve images in search results is to replace any lower quality images


with higher quality ones.


Again, review robot settings such as Max Image Preview, which provides guidance to Google


on how you'd like images to be treated in search results.


For more details, check out Robots Meta Tag, Data No Snippet and X-Robots Tag Specifications


in Google Search Central documentation.


Also, if your images are not appearing in search results, consider adding product structured


data to your product pages.


Which leads me into the next tip.


Tip number three is to share rich product data with Google.


If Google does not correctly understand the intent of your pages, you may miss out on


special presentation treatments in search results.


One way to help Google understand pages is using structured data, additional markup you


add to your web pages.


For example, there are structured data types for recipes, how-to guides, articles and products.


For a longer list, see Explore the Search Gallery in Google Search Central, which documents


structured data types and common presentation formats supported by Google Search.


For products in search results, it is recommended to at least include the product title, description,


images, product ratings, price and availability.


If you've added structured data to your pages, but not seeing any special presentation, check


the page using the URL inspection tool to make sure it is being indexed.


Then try the Rich Results Test tool to see if it identifies any errors in your markup.


Errors reported by the Rich Results Testing tool provide guidance on what to fix in your


structured data.


If you're using a platform that does not give you control over structured data, you may


need to contact your platform vendor for assistance.


Another problem that can occur is Google may include information from your page that you


do not want shared in search results.


Check out the No Snippet Controls in the robots documentation I mentioned earlier for different


ways to request Google to exclude contents from search result listings.


Oh, and as a final note, you can also supply product data via Google Merchant Center feeds.


I'm going to dig into Google Merchant Center and its relevance to search in a future episode.


Tip number four is to highlight that if you share pricing product data, Google may highlight


price drops in product rich results.


Price drops are calculated by Google based on the running historical average of your


product's pricing.


Price drops, along with some other experiences, are not available in all countries.


To see if price drops are being displayed, check your products in search results.


Be aware, however, that it can be hit and miss as Google doesn't guarantee to display


all price drops and you have to get the timing right due to Google indexing delays.


To be eligible for price drop display, make sure you have an offer in your product structured


data.


The price in the offer must be a specific value and not a range.


In addition, it can be worth checking the rich results tool for structured data errors.


Tip number five is to clearly identify which products you sell by providing accurate product


identifiers such as GTIN identifiers.


This is best done using a combination of Google Merchant Center feed and product structured


data on pages.


This can increase your exposure and experiences that list products with multiple sellers per


product, such as the top products carousel.


The final tip is, if your business has a physical presence, create a Google business profile.


This can be done via the Google Business Profile Manager.


Business profiles are displayed when appropriate alongside search results.


At this time, pure online businesses are not eligible for a business profile.


Only businesses with a physical presence, such as a physical store or a service area


they cover, can have a profile created.


Google is always exploring new ways to help users understand search results.


Over the years, search results have become increasingly visual and this trend is likely


to continue.


The best long-term advice is to provide Google rich structured data describing your products.


It is also recommended to create a Google Merchant Center feed with product data updates.


Google can then use this data to present your pages in search results in a more engaging


way to shoppers performing searches.


If you found this video useful, please subscribe to get notified of new content.


Google Search Central publishes new videos weekly to help website owners get the most


at a Google search.


English Google SEO office-hours from April 9, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


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


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


where people can join in and ask their questions


around their website and search.


Looks like a bunch of people are joining already,


so I'm sure it'll be an interesting one.


A bunch of questions were submitted on YouTube as well.


So we can go through some of those.


But maybe I'll just go through some of the live questions


first.


And it looks like we already have two people who


are raising their hands.


Wow.


OK, cool.


Praveen, you made it first.


Hi, John.


How are you?


Hi.


Oh, so just a very quick question.


This page experience algorithm, which is coming in May,


just wanted to know if it will be a real-time algorithm


or something like core updates, where it will be updated


from time to time?


I don't know.


I don't know if that's decided completely yet.


I mean, part of that is also there's just a general lag


for the data anyway.


So we kind of have to wait that period of time


until we have collected enough data.


So I suspect it's not something that will be optimized


for speedy updates, but more kind


of to have a clearer understanding


of the overall picture.


So my guess is it'll be more something of a slow thing


rather than a real-time change.


Sure.


OK, thank you.


Cool.


OK, Max.


Hi, John.


I've got a couple of questions with regards to core web vitals.


So the first one is we recently updated our site,


and now we're getting 100% score in Lighthouse.


But after deploying the changes, the amount of poor URLs


have increased dramatically in Google Search Console


being reported.


So our poor URLs have gone up, and our good URLs


have actually gone down.


Now, I understand the difference between lab and field data,


but it seems a bit weird that we're now


getting a much better score in Lighthouse, the lab data 100%


or 100%, but now our real field data seems to be getting worse.


And it just seems a bit strange that we've improved so much,


but yeah, the real-world data seems


to be the opposite of that.


Yeah.


So I think one aspect that you need to take into account


is the delay with regards to kind of the Chrome User


Experience report data, which is that I think like 28 days


period, essentially, during which the data is collected.


So essentially, if you make a change now


and you test it in Lighthouse or PageSpeed Insights,


that's what you would approximately


see in about a month with the data from Search Console.


So from a timing point of view, that's a little bit decoupled.


So if you made a change now and immediately


afterwards in Search Console you see that it changed,


then the change in Search Console


would not be connected to the change that you just now made.


Yeah, so we're aware of the 28 days delay,


but we deployed it more than 28 days ago.


We still seem to be an increase in the pull URLs.


Yeah, I don't know.


It's hard to say without looking at the details.


One thing that I would try to do there


is to try to figure out which part of Core Web Vitals


is affected by that, if it's like Largest Contentful Paint


or if it's CLS.


And based on that, try to figure out where it might be coming


from.


One of the things that generally happens


with the lab versus field data is that with the lab data,


it's basically an assumption.


It's an approximation of what our systems think


might happen in the field because there are just


so many unknowns out there that depend a little bit


on your users, where they're coming from,


what kind of devices they have, all of that,


which mean that you can use the lab data to incrementally


improve, but you don't necessarily


see a clear connection between the lab results and the field


results.


I don't know if that's something that


might be playing a role there.


Well, it actually leads quite nicely


to my second question, which is, with the scores in Core Web


Vitals, is there any consideration with regards


to different internet speeds in different countries?


So we're based in Southeast Asia,


in nine countries in Southeast Asia, where the speed is less,


especially for mobile.


So for example, in one of our countries,


it's the 90th slowest country for mobile speed.


So how does that affect the score?


Is there any different scores in different countries?


And then if there isn't, in some of our countries,


our English-speaking countries, we're


potentially competing with websites from other countries.


For example, in the Philippines, we


have a lot of Western websites in there.


So a lot of their users will be from America, Europe, et


cetera, where the speed may be faster.


And there, we're kind of competing against them,


where our users are coming from the Philippines, where


the speed is slower.


Now, I don't know what the final setup there will be.


It is something where we have country information in Chrome


User Experience Report data.


So it is something where we'd be able to figure out


where users are primarily coming from.


But the general idea is still kind


of that users should be able to have a good experience.


And if the bulk of your users sees a slow experience,


regardless of why, then essentially, that's


what will apply there.


So that's, at least from what I know,


that's kind of the general standpoint there.


It's like, if 90% of your users are coming from locations that


are slow, and essentially 90% of your users


have this kind of suboptimal experience with your site,


then that's kind of what will be taken into account.


OK, one last question, with AMP, can AMP page actually fail Core Web Vitals?


OK, thanks, John.


Sure.


Rahul.


Hi, John.


Hi.


So my question is about referral traffic.


Does referral traffic improve search rankings


for a particular page if that page is ranking


for a certain keyword?


No.


It's sometimes useful to get traffic to your pages,


regardless, but we don't take that into account when


it comes to ranking, primarily because you


can have lots of different traffic sources that


don't necessarily mean that your page is good.


For example, if you go out and spend a lot of money


on social media advertising, you might


get a lot of people coming to your site.


But just because there's a lot of people


coming doesn't mean that we should be ranking it higher


in search.


OK, one more question.


Suppose we have a product, and in the particular niche,


we are having some competitor, like a big competitor,


Amazon or something.


So what happens is actually their on-page SEO


is brilliant, like they are having 50 products


on the first page, so obviously they are ranking on the top.


And their page speed and everything is good.


So my question is how to outrank them.


I mean, what we can do, it's extremely tough.


Yeah, it is tough.


I don't think there is a simple solution for that.


If there are really strong, strong products,


there are really strong competitors in a market,


and it's a market where people have kind of grown,


then breaking into that market is always going to be hard.


I don't think there is a magic trick to doing that.


But the good thing is I think we occasionally


hear from large sites as well that come to us and complain


and say, oh, this small site is ranking for our terms now.


Shouldn't we be ranking first?


Because we're the most well-known.


And so essentially what I want to say


is it's not impossible to rank well


when there is a lot of competition,


but it's going to be a lot harder.


OK, thank you.


Sure.


Olaf.


Sorry, I have to turn my microphone on.


Hi, John.


We got a serious problem with the project


at the moment since last week.


We got only for the Google Desktop bot,


we got soft 404 errors.


And so the rankings are daily decreasing only


for desktop rankings, and we don't know what is the error.


We can't find a solution for that.


OK.


I think you also posted on Twitter.


On Twitter, yeah.


Yeah.


There are several other people who had similar problems.


With the other people, I was able to pick up the URLs


and send them to the team, and I think


they're looking into what is happening there.


But if you want, maybe you can just


drop your domain in the chat here, and then I can pass that


on.


It's a big German brand, so we can't do it because of, yeah.


Well, if you want to send it to me in some other way,


let me know.


I'm happy to pass it on.


I think the team has found some things


that they're looking into, but having more examples


is always really useful.


It is a Google problem or a website problem that would be?


As far as I could tell from the information I have so far,


it's essentially a small change we made in the soft 404


detection, and somehow that's picking things up


in weird ways.


OK.


I would send you the domain or the URLs


via Twitter in the private message.


Sounds good.


Cool.


Nicolas.


I don't.


Might be expected, but about the article in the Search Central


book about providing better product


information for shoppers.


Does this apply to all type of review in the web?


Because the product reviews in e-commerce left by customers,


and they are not under our control.


On other site, our affiliate websites and their reviews,


where the control is in our end.


So can you share more information?


How do you mean?


So the affiliate sites, I understand.


And what was the aspect that's less under your control?


Yeah, in the e-commerce, the control is in our customers


because they let the reviews.


But in affiliate website, when we


trying to promote some other business,


the reviews is coming from our end,


in our top counterparts and team.


OK.


Yeah.


So basically, if you have a product page


and your customers can review it on the product page,


that kind of thing.


From my understanding, the changes that we made there


are really specific to the more likely affiliate approach


that you mentioned, where you're actively


reviewing one product or multiple products


on a separate page, not where the primary purpose is


the product page, but where the primary purpose is really


the review.


Sure.


That's it.


Thanks.


Perfect.


Barry, what's on your mind?


Hey, how are you?


OK, so you guys posted something in the Search Console Data


Novelies page, talking about how the image, starting


the 6th of this month, that performance report for image


search impressions was updated to make it more accurate


and so forth.


The question is, can you describe more detail?


What changed?


Is it counting the search results differently?


Is it just the reporting?


Can you tell us what changed there?


I'd have to look it up again.


I don't know offhand.


But I'll try to figure it out what we can say there.


My understanding is it's mostly a matter of how we track these


and show them in Search Console.


So not like a ranking change or anything like that.


But I need to dig into the details


because it was kind of weird and complicated.


I was just curious if it was more of like Google Discover,


you started to track impressions in Chrome,


maybe in Google Images.


Maybe you're saying if the images show up


in this carousel or that carousel,


or maybe in a product rich results


for counting the image.


I'm just curious if it's related to that or just the math change.


I don't know.


I'd have to dig into my emails.


I remember that was like some relatively long and complicated


thread.


So I'd rather not try to interpret it on the fly.


You can forward over to me.


I'll take a look.


Sure.


I'll just send you my email login.


Thanks.


Two factors can be annoying.


But if you wanted to send me that QR code,


that'd be useful.


GK.


Hey, John.


My AMP pages passed the CW test.


Is it enough?


Or we should optimize my mobile version?


If we show the AMP pages in search,


then that's what we will use.


So usually for modern browsers, we


would probably show the AMP pages,


especially if they're valid AMP pages.


If they're not valid AMP pages, then probably we


would show the mobile or the responsive version.


Can I use my users to review below my health articles?


This user-generated content affects my article's authority.


Can you repeat that once more?


Sure.


This user-generated content affects my article's authority?


You can use user-generated content like that.


The important part to keep in mind


is that we essentially look at your page overall.


And if your page overall looks like it is lower quality


because of the user-generated content,


then we would see your page overall as being lower quality.


So it's less a matter of is it user-generated content or not?


And more, is the page overall good, or is it not so good?


Thank you.


All right.


Clint.


Oh, no, we can't hear you.


Sorry.


One minute.


With regard to the mobile index rolling out,


if our website is already being predominantly


pulled with the mobile crawler in Search Console,


and once the mobile index is fully rolled out,


should we expect any changes?


Or given the fact that we're already


being called with the mobile crawler,


that there will be no change at all?


Yeah.


I wouldn't expect any change.


All right, thank you.


Rob.


Thanks, John.


I have an international sitemap question.


So the advice on webmasters is that having


a separate international sitemap seems to help,


but it really talks about in conjunction with hreflang


and language tags, et cetera.


So our site, the new one is global,


but we do break it down by country.


But it's all English.


But is it still helpful for the crawler


to have a country-level XML sitemap,


or does it not matter until you get to 50,000, 100,000 URLs?


Yeah, you don't necessarily need a country-specific sitemap


file.


I think for country-specific content or localized content,


if you use hreflang, then you can put that in a sitemap file


or you can put that into the head of the page.


But we don't really differentiate


between the source of the hreflang annotations.


So essentially, the hreflang side


is the part which is relevant for us.


And how you split things up into sitemaps is totally up to you.


Some people split it up in logical sections.


Some people buy country.


Some people just, I don't know, split it up alphabetically.


It's totally up to you.


But there's no technical reason why one would be easier for you.


No.


I mean, for us, it doesn't matter.


On your side, the one reason why you might split things up


into separate sitemap files is so you can track it separately


in Search Console.


Well, we have each of the subdomains broken down


in the countries in Search Console.


We've added each country separately


so that we can do the geographic targeting


and so we're getting some errors to say this is indexed but not


in a sitemap.


That's totally up to you.


In general, I would try to make the sitemap file comprehensive.


But if we're already crawling those pages,


if we're indexing things well enough, then that's it.


And what if we have both?


If we have the global sitemap, but then we still


have the country level?


Is that going to confuse things?


No, that's fine too.


OK.


I'll do both then, I think, just to cover.


Mihai, it looked like he had an opinion there.


No, he doesn't.


No, it doesn't.


Lucky.


I'm sure he has many opinions, maybe outside of sitemaps.


Rushlika.


Hi, John.


I have a question regarding when we are searching for web search


for a site link, our site homepage doesn't pop up.


They are like other pages which do pop up,


but not our homepage.


So what can be the reason for that?


Can you tell me that?


So what would you be searching for there?


It's like site colon and our site link,


like everything beyond.com.


OK.


And you just don't see your homepage ranking first


in there?


No, I can't see my homepage at all.


Like, not on the first page, but there are other pages,


like other categories which we are selling.


That does pop up, but not the homepage.


And is the homepage otherwise shown in the search results?


Like if you search for your company name?


Yeah, that does, but not like when you search.


I'm not sure I have to search for it.


If I directly search my site, the link does come up.


Yeah, there is a link, but when you search site colon


and site link, that doesn't work.


Yeah, I wouldn't worry about that too much.


In most cases, we show the homepage


in the first results for a site query, but it's not necessary.


It's not something that means that something


is wrong on your website if it's not happening.


The only thing I would watch out for


is if the homepage is not indexed at all.


And if that's the case, then probably there


is some technical reason for it.


But if it's just in a site query, not on top or not


on the first page, I wouldn't worry about that.


OK, so that doesn't have any impact


on the ranking of this page?


It shouldn't.


I don't think that would affect the ranking of the homepage.


Especially if you're saying it's ranking


when you search for your company name, then to me,


that's a sign that the homepage is indexed.


It's showing up for the right queries.


And a site query, from our point of view,


is a very artificial query because we


don't have any notion of what should be shown first.


It's basically like, show us some pages


that you have indexed from this domain.


And in many cases, we show the homepage first,


but it's not always accessible.


SPEAKER 2


Yeah, thank you.


Thank you, John.


Sure, all right, Mihai.


Hey, John.


So a quick question regarding the switch


to mobile first indexing.


I know you're kind of at the last batch of websites


that need to be moved over.


I know there's a bit of a delay until that actually happens.


If there's a website that's still on the desktop crawler,


so it's basically in this last batch to be moved,


is that kind of a concerning sign


that it hasn't been moved up until now


and you're not moving it to prevent maybe some issues that


might come up when you're actually going to move it?


I mean, I would double check what the mobile version looks


like and what kind of things you have there.


But if you're pretty sure that it's OK,


then my assumption is that it's our algorithms picking up


something incorrectly and doing kind


of an incorrect analysis of the mobile first indexing


readiness of the site.


So that's something I wouldn't necessarily worry about.


If, on the other hand, you're really aware of,


well, the mobile content isn't there,


the internal linking doesn't work,


the structured data doesn't work,


the images are not embedded properly or anything like that,


that's something I would fix.


But if, when you do your test, your analysis,


you say it looks OK to me, then I


would assume it's just our algorithms kind of being


too picky.


So from a quick analysis, it does


seem that there are some differences


in internal linking, some internal links, navigation


basically, especially from a specific sidebar that


does show on the desktop, but it's hidden on the mobile.


But when it's hidden, it's completely hidden,


like the HTML is not there anymore.


So I'm assuming that could be one


of the reasons the internal navigation being


a bit different.


When the algorithm kind of tries to figure out


whether it's OK or not, is it just checking for differences,


or is it checking for differences


and assuming that this is actually


going to have a negative impact if we do move right now?


So is this just like, oh, it's different,


so we're not going to move it, or it's different


and you might get hit in terms of rankings if we do it?


As far as I understand, it's basically just to understand


if there are differences.


So the general assumption is if there are differences,


then you might not like those differences.


But if you're saying, well, I know there are differences


and I think it's OK, then that's perfectly fine.


So I wouldn't worry that suddenly it'll disappear.


Right.


And do you have any idea when this last batch will officially


get moved over?


I don't know.


My guess is sometime this month or early next month.


Yeah, I don't know.


It's hard to say.


But fairly soon, basically.


That's kind of the idea.


Yeah.


I mean, the idea was in March, but sometimes things happen.


And it's also one of those things


where when talking with the infrastructure team,


they're saying, well, it's not like we're turning any systems


off completely.


And it's like we need to turn it off


because we have to save computers or something.


It's more that we've been trying to go


in this direction for a while.


And when we get there, it'll be good.


But it's not that we have any urgent deadline to do that.


Right, but the reason for the delay


has nothing to do with the fact that some sites haven't


fixed whatever differences there were,


and you're kind of worried or anything that it


will cause a breaking impact.


Yeah.


As far as I know now, yeah.


It's really more on our side that it's like, well,


we need to figure some things out still.


And just one quick follow up.


If there are sites, there are businesses


that still have their majority of traffic coming


from desktop users, there are certain niches


that still tend to do that.


They will still be moved over to mobile indexing,


and they shouldn't really see much of a difference


as long as the content is similar.


I mean, as long as the mobile website is not,


it's like this page is not available for mobile users,


then that should be fine.


There are lots of sites out there


that just have a desktop friendly home page,


and maybe they're selling something


that make more sense on desktop, like, I don't know,


Windows apps or something like that.


And from our point of view, it's one version.


It's kind of a responsive design.


It's not very usable on mobile, but we can index it on mobile,


and that's perfectly fine.


OK.


Sounds good.


Thanks.


Cool.


All right.


Let me run through some of the submitted questions,


and then I'll get back to people who have been raising


their hands as well.


So much happening.


And the first question is essentially just the same


as Mihai's question.


If our site is only meaningful to desktop users,


such as driver downloads, will Google still


use mobile-first indexing?


Yes.


And then referral traffic.


We talked about that briefly.


What's the difference between core updates and this product


review update?


Does it work in a similar way?


Is there a difference, like, the product review update


looks at queries overall that deal with reviews and best


of list articles?


I don't know how to frame the difference.


I mean, from our point of view, they're


different algorithms that try to look at different things.


Usually, the core updates tend to look at things overall


across the board for websites.


And this particular update is really


more focused on product review websites or product review type


content.


So I guess they look at the sites overall in a broad way,


both of them, but they look at different aspects.


I could imagine at some point we would see this product review


algorithm just as a part of our normal web search ranking


and not tied to specific kinds of pages, for example.


But for whatever reason, they decided to roll this out


a little bit separately.


Will the core web vitals and Google passages


roll out at the same time, or did the Google passages already


start rolling out already?


I don't know.


I bet Barry would know if the passage indexing stuff has


rolled out.


SPEAKER 2


Passage indexing has rolled out January, I believe.


OK, cool.


We should have you answer more of these questions.


Let's see.


We're moving our site from a separate m.domain


to one responsive URL in batches,


and we're starting with the home page.


From the responsive home page, is it OK to link to the www


URLs that will have alternate tag pointing to identical pages


on the m.domain, and those pages will have canonical back


to URLs for the desktop version?


Seems kind of complicated, from a setup point of view.


In general, a kind of a migration from an m.version


to a responsive version is something


that, from our point of view, what happens there


is we essentially change the canonicals from the m.versions


to the www version.


So it's kind of like a site migration.


And from that point of view, it's


something you can do incrementally if you wanted to.


You can also do it all at the same time.


It's, I think, a little bit tricky


because you have the link rel canonical from the m.pages


pointing to the desktop version, but we


will pick the m.version as a canonical because


of mobile-first indexing.


So it's kind of confusing, probably,


to track this in Search Console.


But if you're moving to a responsive setup,


then the destination of your setup


is at least going to be less confusing.


So from my point of view here, what I would watch out for


is that you move things over incrementally,


if you prefer to do it incrementally,


and that you make sure that all of your internal links


and redirects and things like that, that they're


updated as well as you move things over.


So if you move the home page over, then


make sure that the internal links go to your new home page.


And if you have structured data on your home page,


then make sure that applies to your new home page URL as well.


If you have things like hreflang annotations or rel canonical


or any other kind of URL-based metadata on these pages,


make sure they also apply to the new home page URL.


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


I suspect it'll be hard to track this in Search Console because


of the weird m dot being canonical but not flagged


as canonical thing.


But you should see how things settle down


on the www version over time.


So kind of the tracking part is the only one


where I'd say it's probably a bit confusing to follow along.


But moving things over, at some point, it just makes sense.


And it'll all be a lot easier when


you have a responsive design where you just have one URL


for the piece of content.


Are floating mobile ads on AMP always


going to be non-compliant for core web vitals


because it always fails to pass the test with that ad type?


I don't know.


I haven't looked at specific ad types on AMP.


But I forgot who it was before who asked,


are AMP pages always going to pass core web vitals?


I guess this is one example where they


don't pass core web vitals.


And my assumption is that this is based on the CLS score.


I don't know this specific example here.


But my assumption is it's based on the CLS, which


is based on how things move around on a page


as a user interacts with the page.


And that's something where we do have some changes lined up


in regards to how we measure CLS.


There was just, I think, this week a blog post on that.


So it might be that it'll get better in that regard.


It might also be that this specific type of ad


is just annoying for users.


And it does perhaps cause bad scores.


So if you really want to keep that ad type


and you see it doesn't pass the core web vitals because of it,


then you kind of have to make that decision.


Like, do I keep the ad type because it's useful for me,


or do I focus on core web vitals?


It might also be something where you say,


I will just watch out to see what


happens when core web vitals roll out,


and I'll decide based on that.


If a website covers both YM, YL, so your money or your life


topics as well as non-YM, YL, non-sensitive topics,


and for some reason we're unable to establish EAT,


so kind of expertise authority trustworthiness


in the eyes of Google algorithms,


does the rank of all articles on the website


get hit, including the non-YM, YL topics,


as well as where the required EAT score is relatively low


to rank well or just those that belong


to the YM, YL category?


It's really hard to say.


So we don't have an EAT score.


So kind of first off, so it's not that we look at one metric


and we say this is the score for the authoritativeness


of your website overall.


That's kind of one thing on the side.


The other thing is I think if you


have a website that covers very sensitive topics as well


as very trivial topics, then it's


always going to be challenging for Google's algorithms


to figure out how to deal with that website.


So regardless of anything around YM, YL, or EAT or anything,


if you have this mix of very polar opposites


almost with regards to content, then I


would assume that Google's algorithms are always


going to struggle with figuring out how to rank your website.


And it might be that they tip over and say,


oh, this is actually a pretty good website overall


and everything will rank better.


It might be that they tip over and say, oh, actually,


there's a lot of really trivial, useless stuff on this website.


We will not rank it better.


And it's also possible that we can figure out


the kind of the clear separation between those two areas


and try to rank them individually.


But that's not guaranteed.


So one place where the separation is often


a little bit more visible is when it comes to adult content.


If a website has adult content and kind of non-adult content


or, I don't know, like more general content,


and if we can recognize that there's


a clear separation between those two areas


based on the URL structure.


For example, if you have a subdomain


or if you have a clear subdirectory


for a specific type of content, then it's


possible that we can learn that this part of the website


should be treated like this, maybe with SafeSearch.


And the other part is not treated with SafeSearch,


but it's not guaranteed.


So essentially, what I'm saying is


if you really want to make sure that Google treats these


as completely separate websites, then you probably


need to make them separate websites.


If you do want to kind of keep this mix of very sensitive


and very trivial content, like I'm probably exaggerating,


I don't know your website, then you kind of


have to assume that Google's algorithms might


go one way at one time.


They might change their direction at some point


over time.


It might be that we can figure out the split between them.


But especially if there is no clear URL structure split


across them, then it's very possible


that we will just treat this as one website overall


and not as some completely separate areas.


With the new product review update,


will that increase the chances of reviews showing up


for brand searches?


And does this only affect third-party review sites


or all sites including reviews?


Here I'm thinking of an e-commerce store including


review content on its blog, for example.


So my understanding is if you have a review blog


post, that would essentially be what this algorithm is for.


And it's less a matter of is this hosted on an e-commerce


site or is this hosted on a random blog?


But rather, this piece of content is a review.


And based on that, we will look at that.


With regards to higher chances of showing up


on brand searches, I don't know.


My assumption is that this update is not specific


to specific types of queries but more with regards to reviews


being visible overall.


It's certainly possible that we might end up


showing more reviews for some kind of queries.


My guess is this is probably something


that we will experiment with over time.


And we'll try things out.


And some things will make sense.


And some things will fail miserably.


And we'll try to improve the things that make sense


and keep focusing on those.


Whether or not that means we'll have more reviews showing up


for brand queries or not, I don't know.


I can't predict that.


I don't think anyone really at Google


can predict that because it all depends quite a bit on how it's


received by users, how it's received by site


owners, all of these things.


At our website, we have 100 white labels


that are copies of the main site.


And they're closed off by x robots tag, no index.


Due to technical limitations, all pages


have meta robots HTML tag set as index follow.


Over the course of last week, we have over 84 million pages


added in Search Console as excluded but blocked by robots.


And the number keeps increasing by millions.


Wow.


Will the search for this be a good idea


Wow, will this bring any negative effects for the site?


It seems that the x robots tag is not being respected,


even though documentation clearly


states that it should take precedence over the robots


meta tag.


What should we do to stop Googlebot


from endlessly crawling auto-generated search pages?


Yeah.


So I think there are two aspects there to keep in mind.


One is the no index robots meta tag or x robots tag


is essentially specific to indexing.


It's not something that would prevent crawling.


So in particular, we have to first crawl the page in order


to see the no index.


And because of that, we end up crawling a lot of these pages


just to see, oh, actually, there's a no index,


so we can drop it.


And especially in the beginning, as we


start to see things like this across a website,


we will probably go off and crawl a ton of content


and see that it's all no index.


And usually what happens there is over time,


our systems realize actually crawling these specific URL


patterns leads to nothing.


We can't index the content.


Therefore, we will reduce the crawling


of those specific URL patterns.


So that's something that kind of settles down on its own.


But we still need to crawl all of these patterns first.


And if kind of the crawling is a problem for you,


then on the one hand, you can use robots text


to block crawling of those pages completely.


The tricky aspect with robots text


is that it doesn't prevent indexing necessarily.


So with robots text, we wouldn't be able to look at the page,


and we wouldn't know there's an xRobots tag with a no index


associated with the page.


So it's possible that we might still index these pages


without the content.


In practice, that means if you do a site query for those URLs,


you might see those URLs shown without any snippet.


But they're unlikely to rank for any kind of normal queries


that you're trying to target because we don't have


any content for those URLs.


And probably, we have one version of the content


already in our index from your main site,


and we'd be able to rank that.


So theoretically, you'd see those indexed.


In practice, probably not so.


That's kind of one approach there.


The other approach is you could tell


us to reduce crawling overall.


And if we reduce crawling overall,


our systems tend to kind of scale back in a way


that they focus on the more important URLs


rather than the bulk of the URLs that we find.


And that generally results in us focusing more on the actual


URLs that you care about.


You can set that in Search Console.


And there's a third thing that you could potentially do.


If you're seeing that this is causing serious issues


across your site and you don't want to just generally dial


back the crawling overall, there's


a reported problem with Googlebot form in Search


Console as well, where you can report


specifics of crawling issues that you're running into.


And that goes directly to the Googlebot team, who


can take a look at that and see if they need


to tune anything on our side.


So those are kind of the approaches there.


I think my general recommendation


would be to focus on just keeping the noindex in place


and letting it settle down.


But if that's kind of feasible from your side,


that's more up to you.


I'm building a new website for a client


in a suburb of a large metro area.


And the URL, title tags, meta description, et cetera,


should I use the name of the suburb or metro area,


they draw from many other suburbs and the city itself.


I know you've mentioned that we should not


do separate location pages.


That's unfortunately a lot of device I'm seeing online.


So if the location is really important and relevant


for this website, I would definitely


mention it on the website and in the title, things like that.


One thing that I've always seen as being kind of useful


with regards to titles in particular,


probably also with a snippet, is that you


can test some of this specifically in search


by using ads.


It's not that I want to recommend you run ads


so that you can do better SEO, but it's more


that when you're doing this kind of A-B testing with regards


to which title works best, which snippet works best, with ads,


you can just quickly swap between the different versions


and you can kind of see the results of that fairly quickly.


You don't need to spend a lot of money on ads to do that.


You kind of see the effect fairly quickly.


And then based on the results that you see there,


that's something that you can use and then implement


on your pages itself and say, well, this kind of title tag


performed the best in our ads.


Maybe it performs well in search as well.


I wouldn't assume that it's going to change


the ranking significantly, but when you're shown in search,


at least it makes it a little bit easier


to get that click from users.


Let's see.


I've seen issues like invalid traffic


that's being reported by AdSense.


I'm kind of out of ideas to eliminate the bot traffic.


I don't know how AdSense deals with that.


It's hard to say.


I've heard some people block individual countries


because they see a lot of problematic traffic


from individual countries.


Personally, I don't really like that approach


because Switzerland is one of those weird countries as well.


And people tend to say, oh, this is not a European country.


I will block it.


So I don't like it from a personal point of view.


But if you're seeing significant issues with traffic


from an individual country, then maybe that makes sense.


From a search point of view, we primarily crawl from the US.


We don't always crawl from the US, but we primarily do so.


And essentially, that means if you


need to block individual users in individual countries,


then you need to make sure that you're not blocking Googlebot


so you're not blocking users in the US, for example.


So that's kind of the search-specific aspect


I would watch out for there.


If you need to block individual countries,


just make sure that that's not a country where Googlebot


is crawling your site.


You can confirm Googlebot traffic with a reverse DNS


lookup if you want to do that.


But essentially, for most websites,


we would crawl from the US.


I think it's very rare that we would crawl sites


from other locations.


And we generally don't crawl sites from multiple locations.


So it's not going to be the case that we would crawl from the US


and from, I don't know, Singapore


or some random other country.


We would generally pick one country


to crawl this website from.


So based on that, the important part for search


is really that you're not blocking users from the country


where Googlebot is crawling from.


If you're blocking them from other countries,


that's kind of up to you.


It also means that you might be blocking legitimate users


from those countries.


So I wouldn't just randomly do that.


But if you're seeing significant issues,


then that might be an approach.


How do I encourage customers to write reviews more


particular about the product?


I don't know.


That's almost more of a marketing question.


I feel like I don't really have experience to help answer that.


Let's see.


Bunch more questions.


But we're kind of running low on time.


So maybe I'll just switch back to live questions from you all


and pause the recording.


Once the hour is over, I can still


hang around a little bit longer for more questions from all


of you as well.


Ritu.


Hello, sir.


Hi.


How is you?


Pretty good.


How are you?


I'm good.


Sir, I have a few questions related to recent updates


which Google has recently announced related


to review product update.


And one is a subject's update for Google Search Console.


And in the review product update,


may I know what will be its positive and negative impacts


like for our website?


How do you know?


How it's going to impact a lot of that site?


In the product update?


Yeah.


I don't know how it'll affect individual websites.


So I think the first thing there is


we're rolling this out in individual countries


and languages.


And I think we mentioned we rolled it out in the US already.


So it's not live everywhere yet.


And it generally focuses on websites that


focus on review type content.


So if your website doesn't focus on that kind of content,


then I wouldn't necessarily worry about it.


I mean, the questions and the content in the blog post,


I think, are still relevant to all kinds of websites,


like how to create good content, essentially.


But it's probably less going to affect your website


if your website is not really focused on review type content.


Yes, sir.


As I did browsing for this update, I have seen,


they have mentioned if we got insightful reviews


and we got full and the content reviews,


we can get the benefits by this update.


Google will help in promotion of the reviews, product reviews.


It will help in this.


Is it true?


I mean, there are always two sides


with these kind of algorithms.


On the one hand, we demote some things


when we think that they don't really


align with these algorithms.


And then essentially what happens


is the others see kind of the rise.


So it's like if we lower some sites,


then others automatically rise.


It's not necessarily the case that we


would say we will promote your website more because you're


following this advice.


But rather, if other sites are going down in search,


then it kind of looks like your website is seeing


a little bit more visibility.


OK, sir.


So one more question related to GMB.


Actually, recently Google has updated.


We can't update our phone number and call to action there.


So may I know, is there an impact if our listing up


in Google search results, is there an impact


on our listing ranking?


I don't know.


I don't know how the Google My Business side


would deal with that.


Because has recently updated, we can't update call to action


and phone number in that.


So may I know, is there an impact?


I don't know much about the Google My Business side.


Sorry.


May I know about Resix update in Search Console?


It is not live right now.


It is not coming in dashboard section.


But may I know how it is going to hit the websites when


it will get live?


Which update do you mean?


Google Resix, it is for filtering for the pages data.


Oh, the regular expressions.


In Search Console.


Yeah, that should be live in the performance report.


I think that rolled out, what was it, yesterday


or the day before?


Yes, but it is not appearing in dashboard section right now.


So for that, it should be in the performance report


when you select the filters.


You can say kind of include or exclude or regular expressions


for things like queries.


But so what are the benefits of this update?


Because earlier, we were filtering the pages, queries,


everything we were filtering.


But what are the additional benefits of this update?


Oh, OK.


Kind of the value there is that you can easily, well,


I don't know, easier.


It's hard to say.


But you can combine different things together


in one kind of filter setting to filter things out


a little bit more specific to what you actually want.


So with regular expressions, you can kind of


build a construct and say, I want


to filter all pages that have these kind of URLs.


And then we will just show them.


It's not that you have more information in Search Console.


It's more if you want to look at a specific part,


then you can use this to look at just that part.


You can also export the information to a spreadsheet.


There's also a really cool plugin


that connects with the API with a spreadsheet.


And then in a spreadsheet, you can just manually filter that


out.


You can copy the lines that you like


and kind of remove the lines that you


don't care about for your report.


And you can do that.


So it's kind of a more complex way of filtering the data


that we already showed.


OK.


So one more question.


It is related to Core Webinar issues.


I'm seeing a daily, I'm doing this on a daily basis.


And I'm seeing Core Webinar issues recently hit our website.


It is going to badly impact our website


if we are going through these issues.


But earlier also, I have asked this question with you.


But I'm never getting a perfect solution for this.


And I want to resolve my website issues for like,


we are facing lots of Core Webinar issues.


But may I know before hitting this update,


how it is going to hit our website?


What will be its impact?


It will impact our ranking, obviously.


And apart from the ranking, what will be its impacts?


Yeah, it's mostly specific to the ranking.


And it's really more something where


when we see that results are kind of equal or very similar,


then we can use these kind of additional metrics


to swap things around and say, oh, we


have five pages about this topic.


And they're all kind of similar.


Then we can use the Core Web Vitals


and say, oh, but this page kind of meets the thresholds


for Core Web Vitals.


Maybe we should show it a little bit higher.


It's not the case that the website


will be removed from search or anything drastic like that.


It's really more of a ranking change, especially


in areas where we think the relevance is kind of equivalent.


So if someone is searching for your website,


then obviously your website is the most relevant


possible result. And even if your website is slow,


we will still show it, probably in the first position


if someone is searching for your website's name.


But if someone is searching for something very general,


and you have a page that is just as good as a competitor,


and your page is faster or meets the Core Web Vitals


and their page doesn't, then that for us


is a sign that maybe we should show your page because it's


a little bit better user experience for the users.


And it's very similar with regards to relevance


with the other pages.


OK, so thank you so much for your suggestion.


All right, let me pause the recording here.


Thank you all for sticking around to the end.


Thanks for submitting questions and for asking


so many live questions.


If you're watching this on YouTube,


feel free to join us in one of the future episodes as well.


I try to alternate these between my morning and my afternoon


to try to get some more time zones.


But see if there is one that matches you.


And come and join us at some point in the future.


English Google SEO office-hours from January 22, 2021

All right.


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


Office Hours.


My name is John Mueller.


I'm a search advocate 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 their website and Google Search.


And we'll try to find some answers.


A bunch of things were submitted on YouTube already.


So we can go through some of those.


But as always, if any of you want


to get started with a first question,


feel free to jump on in now.


Hey, John, just wanted to ask a quick question.


Yeah, so as we see, Google adjusts the crawling according


to the server capacity.


So does Google set a discovered traffic limit?


Like, that website received that much of traffic from Discover


that its server can handle?


No.


I don't think so.


I mean, we generally don't have any kind of search traffic


limits.


So that applies to Discover as well.


So it's not that we would say this website gets


1,000 visitors from search, and then we stop showing it.


Thanks.


Sure.


Thank you.


Because I mean, the ideal situation


is we show a website that is really good for a search query,


and we show it to everyone who comes


because it's a good website.


So it would be kind of weird to say,


we think it's a good website, but we're not


going to show it to people.


OK.


Thank you, John.


Because the discovered traffic is sort of on and off thing,


but we see there is a limit of impression that never


achieved that traffic.


So I thought there is a limit related to the search server


handles that.


But OK.


So thank you for that.


Yeah.


I don't think we would tie it to kind of how fast


we think the server is.


At most, if we see that the server starts getting slower,


then we will slow down our crawling.


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


will slow down how much we show the website in Search


or in Discover.


So the crawling side might slow down,


but the rest should remain normal.


Thank you.


Sure.


All right.


Any other questions before we jump on in?


So quiet today.


OK.


Sure, go for it, Alberto.


I think you're on mute.


So can you hear me now?


Yes.


Hello.


Here, Italy.


Excuse me for my very bad English, OK?


No problem.


I have only two questions.


I am a newbie, OK?


Fourth question is, how much is important?


The speed of website.


Because I make a test with the Lighthouse from Chrome


and with the G-matrix, OK?


Another tools.


I discovered that if I have 100 point on Lighthouse,


it's not always better than have a speeder website


with the G-matrix.


It's better how many times to load the first painful content,


OK?


Another thing.


First question.


The second, the last question.


I don't know why.


I find a problem with the sitemap XML.


On the Google Search Console, I have always


a message I couldn't fetch.


Couldn't fetch.


Couldn't do it.


But the file is OK.


You can discover the file XML without any problem.


Other tools says it's OK.


From my point of view, can be a bug of Google


that is pending review instead of couldn't fetch, OK?


Thank you.


Sure, so with speed, I think the confusing part


in the beginning when you start looking at this


is that all tools say something different.


And it's not the case that there is


one number that represents everything


that users do on your website.


So all tools that look at different metrics,


they try to say, well, I think this number is


very important for users, or this number


is very important for users.


And they will highlight that in the tools.


And because of that, when you use different tools,


you will see different results.


And it's not the case that one tool is better than the other.


It's just they look at your website


in slightly different ways.


So my recommendation there would be


to use these tools to find the bigger problems


within your website where you see your website is very slow,


and to focus on those.


And at some point, you're going to have a fairly fast website,


and it's going to be hard to find more problems.


So that's something where you probably


can move on to other things.


But I would not take these speed testing tools as,


I don't know, it's not a law or a speed limit


that you have to reach, or something like that,


but rather use them to improve your website overall.


With on Google's side in search, we


plan to use the core web vitals for speed.


And those include, I think, three metrics


that you can focus on.


Some of the tools also include those three metrics now.


But that's something that we plan to use, I think, in May,


we said, starting in May.


And it's something where I think,


especially for a new website, it's useful to focus on it.


But it's also important that you don't lose


track of the bigger picture.


You can make a very, very fast website if it's empty,


but it's not very useful for users.


So that's something where, especially with a new website,


I would almost recommend make sure you


have a really fantastic website.


And then work slowly to improve the speed


so that it's something that is fantastic and also useful.


I would not use speed as the first thing to focus on.


I would really focus on your website and the content first.


SPEAKER 2


If you want, you can copy the URL of the sitemap file


into the chat here.


And I can take a look afterwards.


Or another idea might be to post in the Search Central Help


Forum, where other people can take a look.


And oftentimes, there's something


that they can find there which is useful to point out.


But I always get a copy of the chat messages afterwards.


So that's something where I can look that up afterwards


and see internally if there's something on our side that's


maybe stuck or something that you can change there.


Usually, these kind of couldn't fetch errors


are things that go away on their own.


So it's not something where, if your website is working


normally, sometimes we just can't fetch it.


And then at some point, it works again.


And we don't show you anything when it works.


And then later, maybe we can't fetch it again.


And then we say, oh, it couldn't fetch again.


But if we can pick the sitemap file up in between every now


and then, then that's perfectly fine for us.


AUDIENCE 1 OK.


Thank you.


Thank you, John.


JOHN MUELLER OK.


Let me run through some of the submitted questions.


And if you have any comments or questions along the way,


feel free to jump on in.


And we'll probably have time for other questions


towards the end, too.


My question is, on my blog, I have


added tags at the end of each internal link,


for example, question mark footer, question mark home,


question mark menu, question mark side mark,


to better analyze and know from where they


have clicked on an article.


I think Google could consider duplicate content.


And I've added in Search Console the crawl URL parameters


footer, home, and sidebar to indicate


that they are canonical.


Is this the correct way?


Or maybe not necessary, because Google knows that there


is only one original page.


So this is something that, theoretically, what


would happen here is we would see these as separate URLs,


and we would try to crawl these individually.


So instead of one page, one URL that goes to an article,


we suddenly have all of these different variations.


And our systems would crawl these versions


and recognize that they're the same


and then, essentially, fold them together into one page.


So that's something where, theoretically, it's


not a great way to do this.


For the most part, I think, especially


with smaller websites, it's less of an issue,


because we can crawl more than enough from a website


to keep all of the content indexed,


and that's perfectly fine.


There are, however, two better approaches


that you can do here to make it so that Google doesn't


have to figure out which page is the right one.


One is to use the internal anchor notation,


like with a number sign, a hash sign in the URL,


and then the part.


Let me just maybe mute you, Alberto.


So just a second.


So to use a number sign in the URL.


And with the number sign in the URL,


we will ignore everything that comes afterwards,


and we will focus on the part in the beginning.


So if you link to your article and then the hash sign


or number sign and then footer, then you


will still see that in your analytics when you track that,


but search will focus on the first part of the URL.


So that's one option you can do.


The other is if you're using Google Analytics or probably


all of the other analytics platforms as well,


you can also tag links individually and let us know


or let the analytics side know that these are


specific locations, for example.


And then you can track that individually


like that without it actually being visible to search.


So those are the two approaches that I would take there.


In general, I think it's fantastic to better understand


how users navigate through your website.


So I would recommend keeping this kind of tracking going,


especially if it helps you to understand your website


and which parts you can improve.


And instead of using question marks,


use a different mechanism that lets us focus on the main URL,


and you still get that data.


Is brand search a ranking factor?


How does Google measure website authority?


We don't really have something specific like brand search


as something that we would call a ranking factor.


One of the reasons I tend to mention it every now and then


as something that you can focus on


is that if someone is searching for your brand,


then essentially your website is the primary one


that is relevant.


If someone is explicitly looking for, I don't know,


the website that you've been working on


and it has a fairly unique name, then we


can understand that this user is exactly


looking for that website.


And then your website will definitely be ranking there,


or I mean, as long as nothing goes wrong.


And as long as your brand is something


that we can clearly recognize.


So the clearly recognized part sometimes


comes into play in the questions here in that people will say,


oh, my brand is Best Insurance Company.


And then they assume that if someone searches for Best


Insurance Company, we will show their website automatically.


And that's not the case, because those words are essentially


normal words as well.


But if you have a brand that is fairly unique,


that people can search for specifically,


and we can understand that they're really


looking for your website, they will find your website.


So it's not something where I would say it's


a ranking factor per se.


But if you can build up that awareness for your brand,


then you have this kind of almost guaranteed amount


of traffic in that people explicitly search


for your website and then they go to your website, which


otherwise would be people search for your general topic.


And maybe your website will rank there,


and they'll be able to go to your website.


So that's something where I think


it's almost like a parallel track of getting traffic


to your website.


So that's kind of why I suggest looking into this every now


and then.


How does Google measure website authority?


We don't have any kind of public documentation,


and there's probably no simple way to just measure authority.


So I don't think that would be that trivial.


What's the best approach when creating a new site?


Getting the buzz out and focusing


on acquiring a loyal user base, finding


an intent behind a query that is not served well


by the top result and creating the best content for that,


any other tips?


I think those are all good approaches that you can take.


I think, especially if you're in the situation where


you don't exactly know what you want


to make your website about, then it is always worth the time


to really take a lot of time to figure out what topics would


really be relevant.


And on the one hand, that's kind of


based on what topics you have a lot of knowledge on,


where you can bring kind of your existing experience


and knowledge in.


And on the other hand, it can be based on things like where


are some holes that I can fill?


Where can I tell that people are really keen to find information


but there isn't really great information out there yet?


And with my background, my experience,


maybe I can bring in some insights there.


So those are definitely some approaches.


In general, I would also consider


making sure that you have something that you can build


out for the long run, not something where you say,


well, I can write about, I don't know, sparkly running shoes


because nobody else is writing about it.


But then kind of expanding from there is very hard.


And the next topic might be, I don't know, private jets


or something like that.


And kind of connecting those things is really hard.


Whereas if you can find a topic where


you know you can bring a lot of information in


and that you can grow out over time,


then that gives you a little bit of a more stable base


to work on.


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


With regards to getting the buzz out and getting a loyal user


base, always.


I think that's a really fantastic approach.


I think having users who love to go to your website, who


recommend your website to other people,


be it through links on their blogs


or just recommending them in social media or whatever,


I think that's always a fantastic thing to build on.


And it's also a way of quickly getting feedback from people


and that if you know these people are coming back


regularly, then you can ask them, what am I doing well?


What am I not doing so well?


So those are definitely good approaches.


I don't think there's one simple approach


to making a website that will just work for everyone.


And with that, it's something like,


there are lots of different ways to do it,


and you can find the angle that works well for you.


The difficult part, I think, with new websites nowadays