and I have one product page for the same entity.


English Google Webmaster Central office-hours from December 27, 2019

The topics are quite different, like top 10 things


before buying one product.


This is blog content, and buy the product is my main content.


Or buy the product is my main content.


Or main page content.


The main problem started from last three months


when Google started ranking a blog page for that product name


only.


And my main page just disappeared.


So first thing, I assume that external links


don't matter in this case.


Why?


Because my main product page was getting links from a long time.


Even I don't know from when the page was live.


And hardly six months back, we launched one blog page,


and it replaced the ranking.


So in this case, what should we do?


Because content-wise, I cannot change the content.


That is very valid content.


This is also very valid content.


Banner, I just added that in blog page


that if you want to buy this product, click here.


But I believe still there is a lot of conversion rate


difference.


Yeah, so let me try to answer the first question.


Let's see.


So internally, within a website, we do pass page rank.


So that's something which I think


is really important in that when we


see a normally structured website with internal links


going to different parts of the website,


then that's something where we would pass page rank.


And we try to understand which of these pages


are more important.


So internal links definitely play a big role


in discovering content and also in recognizing


which pieces of content are more important.


So that's maybe one thing.


With regards to different types of pages ranking,


that's sometimes a bit trickier because it really


depends on how we understand the query.


And in some cases, we can understand the query fairly


well and guide users to the right page.


And in other cases, it's sometimes a bit tricky.


So for example, if we think that a search looks


more informational, that someone is looking more


for information, then maybe we would point them


more towards a blog post rather than a product landing page.


On the other hand, if we think the page is more someone


searching for buying a product, so something more transactional,


I want to buy this thing, then we would send them more


to a product page.


And oftentimes, I think we get that fairly well.


Sometimes we don't understand the query that well.


And over time, we try to figure out


what we should be doing there.


And for cases like that, I think making it easy


for users to find the product landing page


is really important.


But also, one thing I would consider


is whether or not you're actually looking at queries


that users are using and where you're


sure that the intent is to actually go to a product page.


Because it's very easy to get hung up on specific queries


where you think, for this query, I want that page to appear.


And if you look at the search analytics for your website,


you might notice that actually nobody really


searches for this query.


So it's a good match for that page,


but it's maybe not something that people actually use.


Or you see that when users come to your website,


that they tend to stay maybe on the blog post with more


information on that product rather than actually going


to the product page, which might also be a sign that actually


they're getting the information that they need from this


product page.


So that's kind of taking a step back


and looking at the bigger picture first


and then kind of trying to go from there.


I think if you're really sure that lots of people


are going to your website and landing on the wrong page,


then having a banner or some kind of easy way for people


to find the place where they probably


can get more information, that's really recommended.


Yeah, and in this case, external links


don't matter if this is one domain has two pages,


one page is getting links, but one page is new


and new replaces the main page.


So external links value is positive to that one page.


They do matter, but it's not that they


override everything else.


We use a lot of factors when it comes to ranking.


So just because one page has more links


doesn't mean that it will automatically rank more.


OK, thank you.


All right, let's take a look at some


of the submitted questions.


As always, you're welcome to jump in in between,


and probably we'll have time towards the end


to go through some other questions as well.


For the Cloud Natural Language API,


will there be more support for different languages


in the future, for example, Scandinavian languages?


I have no idea.


I don't know how the Cloud Natural Language


API suddenly got so popular, but I


think it's really neat to try things out


with these kind of APIs to see what comes out of them.


But one thing I would kind of keep


in mind with all of these things is


that there are lots of ways to understand pages


and to understand text on a page.


And it's not necessarily the case


that just because we have an API for something like this


that we would use this in search.


We have APIs for lots and lots of different things.


So it's really cool ways to build products


on top of Google technology, but it


doesn't mean that Google Search does things exactly like that.


How can I make sure my users are having a good user


experience on my site?


So it kind of goes into I'm seeing


lots of ranking fluctuations and not really sure.


So I think that's something where


there is no absolute answer that works well for every website.


That's really something where you kind of have


to dig in on your website yourself


to figure out what you can do to improve things significantly.


I think one of the tricky parts here, at least


with the sample URL that you link to, is it seems


like something that doesn't really have a ton of content,


and it's very easy to accidentally go forth and create


millions of pages of content just with variations


of keywords in the URL.


And by creating millions of pages of content


that isn't really valuable on its own,


it's something that makes it really hard for us


to understand what the value of the website is overall.


So one thing I would tend to recommend there


is that sometimes less is more, and sometimes it


makes sense to really narrow down


the target of your website so that you have something really


fantastic to offer that is really clearly visible to anyone


who comes to your web page.


And if from there they can dig in and get more information


but that more detailed things aren't necessarily indexed,


then you still have a really strong basis


and a strong foundation for people to find you.


So that's what I would focus on there is maybe not create


so many thin pages or not have your website automatically


create them that much, and instead


try to create something that's more structured,


that has a little bit more information for people.


Are non-Latin characters a good choice for URL path


with multilingual websites?


Yes, sure.


You can definitely do that.


Nowadays, any kind of Unicode URL


tends to work in most browsers.


So I would go ahead and do that.


I think that generally makes it a little bit easier for users


who don't understand Latin characters.


Like if you have users in countries like China or India,


then maybe that's something where using local characters


makes it easier for them to understand your pages.


So that's definitely an option.


It's not that you have a ranking advantage for doing that,


but it makes URLs a little bit more understandable for users.


So sometimes that's OK.


We're planning a massive catalog update this month.


So whether I need to redirect 301 to the new associated pages,


or 200 pages, or create a new catalog


by keeping the old catalog and keeping the canonical tag


to the new catalog URL.


So it sounds like a pretty big change.


When you say this month, that sounds like you


don't have a lot of time left.


So not really sure how useful it is to change things just


at last minute.


But in general, anytime you're changing URLs on a website,


I would strongly recommend using 301 redirects


as much as possible from the old URLs to the new URLs.


And if you can manage to do it somehow,


then I would even try to look into ways


that you can keep the old URLs.


Because anytime you restructure a website like this


by changing the URLs on the site,


it means we essentially have to reprocess the whole website


to understand it again, to understand how these pages


connect to each other.


So with 301 redirects, we could kind of follow that.


We can recrawl the whole website.


We can see how things are reconnected.


But if you don't change the URLs at all,


if there is a way to do kind of URL rewriting on the server


side to reuse the old structure of the URLs,


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


almost nothing changes.


And it's a lot easier for us to just say,


well, the content has updated here.


And we can kind of recrawl the individual pages


and re-understand that content.


But we don't have to reprocess all of the URLs


and understand how these URLs are connected


and how they belong together.


So that's kind of my order of recommendation there.


First, if you can find a way to do it with 200 pages,


maybe that's doable.


Keep the old URLs.


If you can't keep the old URLs, then definitely 301 redirect


from the old ones to the new ones.


If you can't redirect at all because of technical


limitations, then a canonical is a good backup.


But a redirect is really much cleaner and much stronger


sign that you're moving things to your new preferred URLs.


How to write a perfect meta title and description.


Oh my gosh, I don't have kind of the secret recipe


for meta titles and descriptions.


The one thing I would just say is


there is no absolute length that you need to focus on,


so no maximum or minimum length.


But rather, it needs to match the content that you have.


And past that, we have a great Help Center article


on titles and descriptions and how they work that I'd


recommend taking a look at.


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


Kind of avoid artificially focusing


on just pure keywords and pure character length


and things like that.


And instead, try to understand what


it is that you're actually trying to provide on your pages


and how you want that presented in the search results.


How breadcrumbs, errors, cause my blogger.


I don't quite understand the question.


So what I'd recommend doing here is maybe


going to the Webmaster Help Forum


and trying to elaborate a little bit on what


you're exactly looking for.


In general, like I mentioned in the beginning,


if a specific type of markup isn't valid on your pages,


then we would just ignore that type of markup


and not use that to show the rich results type.


So if, for example, the breadcrumb markup


isn't valid on your pages, then we


wouldn't be able to use those breadcrumbs or that breadcrumb


markup to show breadcrumbs.


We would still rank your pages exactly the same as before.


We just might not show it in the same way in the search results.


When it comes to breadcrumbs, we're


doing more and more automatically


trying to figure out what the breadcrumbs should be anyway.


So maybe that's not that critical for you


in a case like that.


On the other hand, if there's a specific type of structured


data that you really want to have shown like that


in the search results.


So for example, if you have recipes on your pages


and you really want that picture and the nutritional or cooking


information to be shown in the search results right away,


then you definitely want to make sure that your markup is


correct so that we can show it like that.


We would still rank it exactly the same as before.


But if everyone else has this really fancy recipe rich result


type and you have kind of the plain text version,


then maybe that doesn't make your pages that interesting


for people to click on.


So it would be a good idea to focus on that.


With breadcrumbs alone, I don't think


that would be that big of an issue.


We're migrating seven store sites to the same platform


using the same content, same title tags, meta descriptions,


H1s, et cetera.


Despite my efforts to convince the developer


to create different instances of the database


and allow unique content for each store,


they're moving forward, essentially creating


seven duplicate sites for 500 brick and mortars


on the East Coast.


None of the stores are in the same exact geolocation,


but all of them are on the East Coast.


What can be expected?


What would your general recommendations


be to convince the developer to allow unique titles,


descriptions, meta tags, et cetera?


Yeah, I think this is probably the, I mean,


maybe not this specific problem, but the general type of issue


is something that a lot of SEOs struggle with.


Namely, you have a bunch of really good recommendations


that maybe you can even back up with comments from us somehow.


And developers have a very limited time,


and someone has to make a call and say, well, developers


should focus on this, or they should


focus on implementing these SEO recommendations.


And sometimes you win, sometimes you lose.


So that's something where I think


having clear data in your favor makes it a little bit easier


to make that decision, where if you can really say,


well, if we do it like this, then this is something


that we would expect, then that's


something that makes it a little bit easier to make a call


there.


But sometimes that's not so trivial.


With regards to this specific situation,


what I expect would happen here, I guess, first of all,


I'm not quite clear how these seven sites for 500 businesses


would work out, if that's like 500 sites,


or if that's just seven websites and just local addresses.


I think seven sites versus 500 sites


is a significant difference.


So that's something where, depending


on how that is set up, that might play a role there.


With regards to multiple websites that


have exactly the same content in general,


there are two things, or I guess a few things,


that could happen here.


I'm going to assume that these seven websites look slightly


different.


They have different titles on them.


It's like, I don't know, website A, website B,


and the products themselves are exactly the same.


And maybe the categories, the search pages,


all of those things are exactly the same.


So at first, what would happen here


is we would index all of these sites individually.


We would recognize that the page as a total with the title,


with the branding, with the logo, things like that,


is different across these seven sites.


So we would be able to index them individually.


However, we would also see that the primary content


or large chunk of the content for individual pages


is the same.


And then in the search results, when


someone searches for something that's


within just the primary content of the page,


like if you have, I don't know, blue shoes in your shop


and the blue shoe pages are exactly the same,


if someone searches for blue shoes,


we would see that the snippet that we would show to users


would be exactly the same.


Therefore, it doesn't make sense to show


multiple copies of this site.


So in practice, what would happen


is we would pick one of these sites


and show that to the user.


Looking at this from a business point of view,


that's not necessarily bad.


If someone is searching for blue shoes and one of your pages


shows up there in that query for blue shoes,


then you kind of have that opportunity


to get that click, to get that user to come to your site,


for that user to do a conversion on your site.


And if these sites are all the same,


then everything after kind of going to your website


is essentially the same.


So that's probably not that problematic in the sense


that one of your pages is shown in search,


and we can kind of show that properly.


The alternative, if all of these pages were unique,


if there were kind of different product descriptions


across these different versions, is it could potentially


happen that we would show two, three, four, maybe up


to seven of those sites in the search results


and say, well, these are other sites on the same topic.


From a purely ranking point of view,


one of the things that can help here


is if you pick a canonical version yourself.


So maybe that's an option from the developer side


in that if you pick a canonical version on your own,


on your website, then what will happen


is that canonical version will be much stronger


than the individual versions.


So kind of if someone searches for blue shoes,


then if there is a bit of competition out there,


then we would know this is a really strong page


on blue shoes, and we'd be able to rank it a lot better.


So that's kind of one way to kind of mitigate


this problem with regards to multiple sites showing


the same content, to pick a canonical


and kind of help us to rank that one a little bit better.


You can do this canonical thing on multiple levels.


You can do it per product if you want.


For example, if you have one site that is focused more


on garden furniture and another site that


is focused more on maybe indoor furniture,


then maybe you make the canonical for garden furniture


products be your garden furniture site,


and you do the other for the indoor content.


That might be one thing to kind of do there.


So that's kind of, I think, a smaller approach


that I would take there is to do the real canonical.


The other problem that can happen with a setup like this,


with seven sites, I'm not sure it


would happen if you have significantly more than seven


sites that are set up exactly the same way.


Then it most likely would happen is


that we would recognize at some point


from crawling these sites that actually these sites are


the same.


And we would completely skip over all of these sites


except for one.


So we would try to recognize, well, here's


kind of the content and all of the other websites


that the full content is exactly the same as what we already


have.


Therefore, we don't even need to crawl or index


all of those other versions because they're really


exactly the same.


And in a case like that, we would automatically


pick one of those sites kind of as a canonical


and focus our crawling and indexing on that one


completely.


That can sometimes be a bit problematic in the sense


that if you have different variations


across these different sites, then suddenly they


would not be indexed at all.


So for example, if these seven sites are kind of


like how I mentioned, like garden furniture


and indoor furniture, and actually they


show exactly the same content, if someone


is searching for the garden furniture


variation of that site, and we think it's actually exactly


the same as the indoor furniture version of that site,


then we would show the indoor version instead


because that's the one that we kind of picked


as a canonical for that setup.


So that's kind of the risk that you go there


in that you create these seven sites, and then in search,


we just pick one of them and we focus on that one.


So that's, I don't know, with seven sites,


I suspect it might happen, might not happen.


If you have significantly more than seven sites


and they're exactly the same, then that's


pretty certain that that would happen.


If these sites are all equal from your point of view,


if you don't care which one of them is shown in search,


then maybe that's fine.


On the other hand, if they're slightly unique


and you really want to make sure that things are uniquely


available across these sites, then that's


something I would try to avoid.


And the best way to avoid that is really


to make sure that they don't show exactly the same content.


So that's kind of the worst case scenario.


I'd say if you have seven sites that


show exactly the same content, we would just


pick one of those sites, and we would not even


bother crawling or indexing the other versions of those sites.


Ooh, so many things to keep in mind.


Seems like it can get pretty complicated.


But I guess to sum up, the one thing


I would try to figure out is if you can at least get


a rel canonical for these individual pages.


And if you plan on going to significantly more than seven


sites, then you really, really need to make sure


that you have unique content across those seven sites.


One of my pages has been ranking number one for a number


of times by Google.


And now when I've hitched a page, I get an error.


The URL is not on Google for indexing errors.


So I didn't see the URL itself in the question,


so it's really hard for me to say what


exactly you'd need to do there.


My recommendation would be to kind of take this


and go to the Webmaster Help Forum


and post the URL where you're seeing this problem


and get some input from the community on that.


Sometimes these are simple technical things


that are going wrong on your website


that you can easily fix.


Sometimes these are just fluctuations


that happen that can go away over time as well.


A long question on headers and H1, H2, H3,


what is the best setup?


I think in general, headings are a bit overrated in the sense


that it's very easy to kind of get


pulled in to lots of theoretical discussions


on what the optimal heading should be.


We do use headings when it comes to search,


but we use them to try to better understand


the content on the pages.


So kind of this question of how should I order my H1, H2,


H3 headings, and what should the content be,


that's something that, from my point of view,


isn't really that relevant.


But rather, what we use these headings for is, well,


we have this big chunk of text, or we have this big image,


and there's a heading above that.


Therefore, maybe this heading applies to this chunk of text


or to this image.


So it's not so much like there are five keywords


in these headings.


Therefore, this page will rank for these keywords.


But here's some more information about that piece of text


or about that image on that page.


And that helps us to better understand


how to kind of frame that piece of text,


how to frame the images that you have within those blocks.


And with that, it's a lot easier to find kind of the right


queries that lead us to these pages.


So it's not so much that suddenly your page ranks higher


because you have those keywords there,


but suddenly it's more, well, Google


understands my content a little bit better.


And therefore, it can send users who


are explicitly looking for my content a little bit more


towards my pages.


So obviously, there's a little bit of overlap


there with regards to kind of Google understanding


my content better and me ranking better for the queries


that I care about.


Because if you write about content


that you want to rank for, which probably you're doing,


then being able to understand that content better


does help us a little bit.


But it's not that suddenly your page will rank number one


for competitive queries just because you're


making it very easy for Google to understand your content.


So with that said, I think it's useful to kind of look


at the individual headings on a page,


but don't kind of get too dug down


into all of these details and variations.


And instead, try to find a way to make it easy for people


and for scripts to understand the content and kind


of the context of things on your pages.


How can I get in touch with Search Console?


I'm interested in website optimization,


which increases the results in the search results.


So what I would recommend doing here


is maybe going to the Webmaster Help Forum


and chatting about specific issues


that you're worried about or that you have questions about.


The folks there are generally pretty helpful


and can help you to kind of figure out


which directions you should be looking there.


How to copy content without copyright and rank at the top?


I don't know.


This sounds kind of sneaky, kind of like something


that doesn't make that much sense in the sense


that if you're copying content from other websites,


then why would Google want to kind of highlight


your website on top when the other websites already


have that content?


So my general recommendation there


would be to kind of create unique and compelling content


of your own rather than just to copy content


from other websites.


And it doesn't matter so much if you're


allowed to copy it or not.


But if Google looks at your content and says,


well, I've already seen this, and I already


know that this is kind of the best place


to send people for this content for,


then why should we focus on showing your version


of that content as well?


And the same thing applies to when you take and rewrite


content, when you rewrite it yourself manually,


when you rewrite it with a script,


in that we would look at that and say, well,


we already know this is kind of the content that is out there


that people trust, that people go to.


Why should we show your version of this content?


And kind of going from there, obviously,


if this is a topic that you really care about,


then I would try to make sure that you


can create kind of unique and compelling content of your own


on this topic rather than copying things


that other people are doing.


And if you want to write about what other people are doing


and you want to include a quote on your website,


that's perfectly fine.


But really make sure that the rest of your website


has something that is significantly different, where


when people search for information,


that we would be able to say, well, this


is by far the best source of information on this topic.


It's not just the same as all the other ones,


but rather it's really significantly better.


And that's kind of the direction that you should be having.


What's the best way to distinguish


the name of the business for Google My Business?


I have no idea how Google My Business works,


so I can't really help with that.


Last month, we migrated our server,


and the number of indexed AMP pages


increased from 1,700 to 7,000.


And then from 4th of December, the number


started to drop without any issue,


and now we just have 3,700 AMP pages left.


The mobile usability graph is going down the same pattern.


We have more than 20,000 pages indexed, and all of them


are mobile friendly and have an AMP version.


Why is there a drop?


So sometimes this can be a little bit tricky


in that for all of these aggregate reports in Search


Console, we focus on a significant sample of the pages


from your website, and we report on those.


So just because you have 20,000 pages indexed in total


doesn't mean that you would see a total of 20,000


in the AMP report or in the structured data report


or in the mobile usability reports,


but rather we would try to take a significant sample


of your website, and we would use those


as the baseline number for these other reports.


And the idea here is not so much that these numbers should not


match up and it should be as confusing as possible,


but rather that we try to highlight issues


that you should really care about.


And if from all of the pages that we


have sampled in your report there are no issues at all,


then you're all set.


Probably none of the pages have significant issues


that you need to worry about.


On the other hand, if a large part of the sample of URLs


that we test for your website do have issues,


then that's something that you should focus on overall.


And usually those kind of issues are not


things unique to individual pages,


but rather unique maybe to a template


or to a significant part of your website.


So fixing the baseline problem with your website


that's causing this issue would fix it


across all of the pages of your website.


So with that said, if the total number for these aggregate


reports goes up and down a little bit,


I would not worry about that at all.


Instead, what I would look at is kind


of the ratio of the number of errors


that we flag for your website.


So kind of not expect the total number


to match the index count, but rather this


is a sample that we picked to test for these issues.


And of that sample, we found so many issues.


And kind of that ratio of the number of issues


that we found there versus the number of pages


that we have as a total for that report is what I would focus


on.


URL removal tool, removing a folder


that has more than 10,000 pages, is that considered


a single removal or not?


That is a single removal from our point of view.


If you remove a whole folder or subdomain,


that's one removal request from our side.


It can cover a lot of individual URLs.


So there are limits to the number of requests


that you can make with the URL removal tool.


So if you have thousands of URLs that you need to have removed,


then if you can narrow that down to a specific folder structure


or kind of a URL prefix on your website, where most of these


are included, then submitting that as a removal request


will save you from having to do all of the individual ones.


And the individual ones you can kind of still


use to clean up the details.


Let's see.


Then there's one about images, with product images,


where you see the big version on click.


I didn't check out the sample URL that you have there,


so it's really hard for me to say.


But in general, when it comes to images,


we want to be able to recognize the large and high quality


images on your website so that we can use those in image


search to send people to your site.


And if you have multiple resolutions,


multiple variations of images on your website,


then it's fine for us to recognize all of them.


We'll try to treat them appropriately.


There are ways that you can use responsive images to let


us know about that.


So that's kind of the direction that we usually recommend.


Using responsive images means that you


send an image that matches what the user might


need to see at the moment and still have the ability


to point to the higher resolution or lower resolution


images as needed otherwise.


So usually, that's a pretty good approach to take there.


Oh my gosh, we still have a bunch of questions left.


And we're running low on time.


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


all first to see if there's anything urgent on your mind


that I need to get through.


Yes, John, I'm Sanjit.


Hi.


Yes, so actually, John, what I did actually,


in the call budget section in our master tool,


I limit my crawl rate to, it was at maximum.


And I changed it to minimum, it's medium.


And suddenly, our number of crawl pages


dropped from 6 million per day, 6 million per day to 600k


per day.


So after seeing that, again, I make it high.


But our means, number of pages crawled per day not increased.


So could you please help me on that?


OK, so the crawl rate setting is really


for when you need to limit the amount of crawling.


It doesn't increase the amount of crawling.


And there is, I think, a maximum that you can set there.


So that even if you set it to the maximum,


it might be that that maximum in the setting


is lower than what we would naturally crawl.


So in a case like yours, where you're saying,


usually I'd have a million pages crawled per day,


then I would recommend taking the crawl rate setting out


completely and not using that and just letting Google


figure that out directly.


Because even if you apply the maximum setting there,


then what would probably happen is


that it's less than we would crawl naturally


from your website.


OK.


But I have another question, actually.


But the day actually I limit it to medium,


from a couple of days, it completely lost means number


of pages crawled per day.


But it never get back if I set up the setting


to the previous version.


Yeah, so usually what happens with the crawl rate in general


is that we try to adjust it automatically over time.


So we'll go up to the maximum of the setting


that you have set there.


And if you don't have a setting set,


then we will try to go as high as we can.


And this is something that happens


over the course of several days or maybe even weeks or longer,


in that over time, we will test the website


and see that actually it returns results very quickly.


There's a lot of content that we want to have crawled.


And over time, we will increase the crawl rate again.


So I could imagine if you set it to something much lower


for a short time, that it just takes a couple of days,


maybe a couple of weeks, to get back


to kind of the previous maximum that used to be.


Thank you.


SPEAKER 3 John, I have a question


about Google Search Console.


I see a discrepancy between in the last six days.


In Google Search Console, it says that I have 64 clicks,


and I want to see the queries, and I can't see them.


And in Google Analytics, it said it's only 10 clicks.


So I don't understand why there is discrepancy


and how I can solve it.


So maybe you can give me some advice about it.


OK.


In general, Search Console tracks things differently


than Analytics would.


So I would expect to see some amount of difference


between those two versions.


And especially when you're looking at fairly low numbers,


like 60 visits a day, that's something


where I could imagine that the differences are


pretty significant across the tools that you use there.


So in general, I would expect the trend to be fairly similar.


But the absolute counts would definitely be different.


Because in Search Console, we track what people


use to go to your website, what they click on.


And in Analytics, it tracks things a little bit


differently.


And depending on how your website is set up


with redirects and things like that,


it might be that it loses the referrer.


And then it doesn't know that actually this came from search


or this came from organic traffic.


So that's something where I would always


expect some differences.


Yes, but I want to ask, I see 64 clicks.


I can't see the quiz.


I can only see five or three quizzes,


like what people clicked on.


And then a whole bunch of rows that say me zero,


but it's saved in the, you know, as I said, 64.


So I don't understand why I can't see exactly where


the queries that people click on in order


to get into my website, why this kind of thing happened.


OK.


What we do is we filter some queries out


for privacy reasons, especially things


that are not used so often to access your website for,


which with 60 clicks probably covers a lot of queries.


We would not show those.


So that's something where over time, as more and more people


search for your content, you would


start to see more and more of the queries as well.


OK, thank you.


John, can I ask two quick questions, please,


before we end?


In the HTML, is it important that title tag


is above the meta description tag?


Because I've seen some sites doing that,


but news websites always have the title tag on the top.


So it doesn't make difference?


No, it doesn't matter.


And second question, maybe you have an answer.


I know this is a difficult question.


In e-commerce, let's say a vendor which sends a product


to a retailer's website, they come up


with a description of this product,


and they're not always great, but let's say it's OK.


But they send, because it's a large website,


you know, large vendor, they send the same product


description to 200, 300 websites.


And Amazon and others and everybody


may have the same description, selling the same product.


Now, when the retailer's website is


dealing with 1 million products or 2 million products


on their website, what is the best thing they can do?


Because it's impossible to sit down and write each,


because they add like a few thousand products every day.


What they can do to improve the content as much as possible?


I know the reviews are part of the main contact also.


To improve the EAT factor, what can they do?


What are some best practices?


I don't know specifically about EAT for e-commerce.


EAT is something that we have in our quality rater guidelines,


and more focused on kind of websites


where the type of information is critical for the user,


where they really need to know that they get


the right information there.


Probably less the case for most e-commerce websites.


In general, what I would recommend doing


is trying to find ways to improve or expand


the content that you have otherwise on these pages.


So you will have this one block of text,


which is the same across lots of different websites


from the product description.


But kind of like you mentioned, you


have reviews where people write about this product


in their own words, where they write about how it worked,


how it didn't work, where they give some additional context


for the product.


You might have people within your organization


that can give more information about a general class


of product, for example, where maybe you


have kind of comparisons between different products,


or you have more information on what to watch out for when


you're buying running shoes, for example.


Kind of this informational content


that you can reuse across your website, which


is unique to your website.


That's another approach that you can take there.


Sometimes local information helps as well,


where if you can tell that someone


is looking for some local supplier of this content,


then making sure to highlight that on your pages


makes sense as well.


I think this is something that particularly plays


a role when it's multi-country targeting that you're


doing there, where maybe, I guess, users in Switzerland,


if they want to buy something, they try to find a local


supplier of that content, and they specifically


try to find a local website.


So if you can highlight that on your website,


if that's a critical factor, then that's


another thing that you can do.


But all of these things where you essentially


provide more context is something


that would add value there.


In that we understand this piece of text is the same,


but actually, there are lots of other elements


that are unique to your website.


And if someone is searching for some combination of something


in that shared piece of text, plus maybe implying


that they're looking for something local, maybe asking


for more information, maybe asking for reviews,


then suddenly your page is not the same


as all of the other ones, but rather, it's


a unique version that has that chunk of text,


but also has a lot of other things.


SPEAKER 2


John, a quick question.


The crawl setting page, it says the settings


would be valid for, it'll start getting validated


from two days after now, and it'll be valid for 90 days.


Can you explain to me what does that mean?


So it takes a while for the crawl rate setting


to be applied.


We usually take the settings, I think,


at midnight in Mountain View or one of those time zones,


and we reprocess that.


And so those two days are kind of the maximum time


that it takes for us to pick up those new settings.


And the 90 days limit is there so


that if you accidentally set a wrong crawl rate setting,


then after 90 days, our systems will go back to automatic


and we'll try to figure out how much we


can crawl from your website.


And that could be that maybe it goes down


because we see that your website is fairly loaded


and we can't crawl as much as we want.


It could also be that it goes up again, where we see,


well, actually your website is very fast,


and you artificially limited the amount of crawling


that we can do to the detriment of your website in general,


where you could be much more visible with your newer


content if we can pick it up faster.


OK.


So in that 90 days, I can still change the crawl settings,


right?


And we'll start from there.


That works.


Thank you.


All right.


Let me take a break here and pause the recording.


You're welcome to stay on a little bit longer if you want.


We can chat kind of off the record, I guess.


Thank you all for joining in.


Thank you for all of the people who joined in


over the course of the year.


It's been fantastic again and been really helpful for me


as well to kind of understand where the problems are,


what we should be focusing on more.


So I'm looking forward to more of these Hangouts next year.


I'm sure we'll find different variations


But looking forward to doing more.


English Google SEO office-hours from May 28, 2021

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


Central 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 websites and around the web search.


As always, lots of stuff has been submitted already


on YouTube, on the community page.


So we can go through some of that.


But maybe to start off, we'll just


go through some live questions from you all.


And I see people are already raising their hands.


So fantastic.


We'll start off with you, promo, Tash.


Hi, John.


How are you?


Hi.


So John, I have a few questions.


So again, some basic questions that I have


doubt because over various forums, they talk differently.


So I have three, four questions.


Can I go?


Sure, go for it.


The first basic question that I want to know


is regarding web hosting and domain registration.


Suppose I want to launch a site in Germany.


So is it required that I get a.de domain registered


in Germany and website hosted in Germany for better SEO?


No, it's not required.


In general, if you want to use geotargeting,


there are two ways to do that.


One is to use the country-level, top-level domains, which


would be.de for Germany.


In that case, the other is to use a generic top-level domain


and to use a geotargeting setting in Search Console.


So that could be, for example, a.com website or.net or.info


or.eu or whatever.


Any of those would also work.


And then you just set geotargeting for Germany.


The hosting location is also not required.


That's something that way in the early days


before we had the setting in Search Console,


we used the hosting location as a way


to guess which country the website might be targeting.


But nowadays, I don't think that's used at all.


And with a content delivery network,


if you have a fancy international website,


then the hosting location doesn't matter anyway


because you always have some local presence automatically.


OK, so next question on the Germany side only, suppose.


So now I have an English website.


So now I want to make a German website.


This question has been over again and again.


So again, I want to ask this question about duplicate


content, this is.


So I have a German content.


Then I suppose use a translator like Google Translate


to translate.


So will Google term it as duplicate?


No.


If it's translated content, it's not duplicate content.


So it's not.


But I have translated using Google Translate only.


I think that's a different problem then, though.


So just kind of in general, translated content


is unique content.


It's different words, different letters on the page.


So it's different content.


Depending on how you translate it,


that would be more of a quality issue.


So if you use an automatic translating tool


and you just translate your whole website automatically


into a different language, then probably we


would see that as a lower quality website


because often the translations are not that great.


But if you take a translation tool


and then you rework it with maybe translators who


know the language and you create a better version of that


content, then that's perfectly fine.


And I imagine over time, the translation tools


will get better so that it works a little bit better.


But at least for the moment, if you just automatically


translate it from a quality point of view,


that would be problematic.


And even a step further, if that's


something that is done at scale, then the Web Spam team


might step in and say, this is automatically


generated content.


We don't want it to index it.


So if I do it with human interface,


like with an intelligence, like this question


was asking way back in 2011.


It is already in Google Search Central.


2011 only it was asked, August.


So in 10 years, I suppose Google has come across like in a month


only Google changes.


So over 10 years, Google Translate


is like maybe a million times better.


Yeah.


Yeah, so it is a million times better than if I do some like,


I will not generate the site, but I will


take piece of the content.


I will generate it because if I go to a translator,


they will charge me in euros, and it will be very costly.


So maximum like what?


If I can express what is your name, suppose.


It can be easily translated.


There are complex situations where grammar and other things


are involved.


There is a long sentence of 15 words, 20 words.


Then I can translate some.


Then I can hire somebody, freelancer,


who could look into it and then make changes.


I think that would be good.


I think that's a good start, but I


think you have to consider the quality aspect.


I think that's that's.


It's good quality, then no issues.


Yeah.


Good quality means for content, it is like the grammar


should be good, and the sentence should


make a meaningful changes.


I mean, just like what kind of content


you would expect in your own language.


If you're searching in your language, and you find a page,


and you read it, and it's like, I don't know who wrote this.


This doesn't make much sense.


Then you wouldn't trust that page, right?


So essentially, it's the same thing.


It's like you're creating content for German users,


and if they look at it and say, oh, this


doesn't make much sense, then they're


going to go somewhere else.


OK.


Can I ask one few more?


Sure.


If nobody is, yeah.


Sorry, guys.


I have some more questions.


So then again, on the sitemap, I have one doubt.


The sitemap does not use priority.


So does Google Elgo use the last mode attribute, like last mode?


Yes.


The time.


Suppose I have not updated the sitemap,


but I keep on updating my content.


My content is updated, but it is not


linked to any Yoast or other plugin.


So I have been updating my content,


but I forgot to update my sitemap.


So sitemap is up generally, but my content is up me.


So what do we do now?


So we use a sitemap to help us to crawl better,


but it doesn't replace crawling.


So if your sitemap is old and your content is updated,


we will crawl your website normally


in addition to the sitemap.


But if you tell us in a sitemap file


that these pages are new or these pages have changed,


then we can crawl more efficiently.


So the sitemap helps us, but it doesn't


replace the normal crawlings.


OK.


Then one more.


So in sitemap, do I need to keep the support and contact us


link in sitemap, or can I avoid?


Because these links are already in the website.


Up to you.


You don't have to list all URLs in a sitemap.


Like some people will.


Only URLs that I wish to be indexed


are to be in the sitemap.


You can do it however you want.


Some people list everything.


Some people just list the important parts.


Some people just list one section


of the website in the sitemap.


It's totally up to you.


One more.


Let me get some of the other guys,


and then I can come back to you as well just to make sure.


We're not missing anything out.


Sure.


Rachiv.


Thank you.


Hey, thanks, John.


How are you doing?


Pretty good.


How are you?


All good.


So I have a question.


So if using superscripts to give outlinks a good thing to do,


for example, I have seen blogs in which what people


you should do, they write the sentences


and correspond it to the word.


For example, there is a sentence called I am an SEO.


Then there is a superscript on SEO in the square brackets.


And when you click on that superscript,


the definition of SEO or the things more related to SEO,


you will be landing on the footer of the page.


And there you will find the link.


So is it a good practice to use superscripts to give outlinks?


I think on the one hand, we can find the links.


So it's not problematic.


But we do get a lot of value out of the context


of individual links.


So in particular, we look at the anchor text for the link.


We look at the part before and after the links as well.


So with a superscript, you're essentially


just listing the URL.


And you're listing the URL out of the context


of the rest of the page.


And that makes it a lot harder for us


to understand the connection between your content


and what you're linking to.


So I would try to avoid that if you can.


There might be usability reasons why that makes sense


in certain cases.


But in general, we do like to try


to find the link within the context of your pages.


That's helpful.


Thanks, John.


Sure.


Cool.


Gus?


Oh, yeah, hello.


Good morning.


Thank you.


How are you, John?


Pretty good.


How are you?


Yeah, fine, fine.


I have a question.


I have a Dutch university that I'm working for.


And I want to implement the hreflang text


for that university.


We have a lot of Dutch pages.


And English is our second language.


That's what we want to target all the other countries with.


The only problem that we have or that I face


is that not all the pages have a translated version.


Because some pages are only in English.


Some pages are only in Dutch.


You understand it, I think.


But how do you deal with the hreflang text in that scenario?


Do you just simply skip the hreflang


on the pages that do not have a translation?


Or do you keep it there?


But not point to other pages?


What is the best practice in that?


So the hreflang annotations are on a per-page basis.


So you don't have to do that across the whole website.


So there are two, I guess, approaches


that you can take there.


One is to skip it on those pages.


The other is just to leave them there and just


have one hreflang tag.


Like you just have the Dutch version.


Or you just have the English version of a page.


And we will look at that and say,


oh, there is no hreflang pair.


So we will skip that hreflang.


So it's kind of like, depending on what your process is,


I would say both of those are essentially equivalent for us.


SPEAKER 2


Hi, John.


I have actually two questions.


So one of the questions we have received from our client.


So when someone searches by their brand name,


they can see their home page and other pages link.


And the organic search shows their Twitter account,


their Facebook account, and one of their product review site


account.


And then it shows a website which is from USA.


But they have the similar brand name of our client.


And now my client question is, they


have an Instagram page which they are updating regularly.


But that Instagram page link is appearing on the second page.


Their question is why the USA site


is appearing on the first page, not the Instagram page.


And their Twitter page, which they are not


using for last four years, it is also


appearing on the first page of the Instagram.


So what is the logic behind this and what we can do?


I don't think there is any kind of special logic behind it.


It's essentially just kind of normal ranking as we would do.


So that's something where sometimes your pages will


show up for queries.


Sometimes other people's pages will show up for queries.


And that kind of happens naturally.


I think there might be two things which they could do,


which could help potentially.


One is to use the structured data on the pages


to say that certain other pages are the same as the home page,


to link to the different profiles that they have.


I'm not sure exactly what the name is of this structured data


tag, but you can link to different social media profiles


that you have for a company from your primary website.


And the effect there is that it helps us to better understand


that these belong together.


And then maybe we will rank them a little bit closer together.


I think it's always tricky because maybe


that other person who has a similar name


is like, why don't I show up for these queries more


in comparison?


So that's, for example, something that I see a lot


with my name.


So if you search for my name, you can find me,


but you can also find lots of other people who


are called John Mueller.


And some of them are pretty famous.


And I imagine they're also like, who is this guy from Google?


And what is he doing in my search results?


And how can I get rid of it?


And that's something where it's like sometimes there just


are different pages that have a similar name


or that have the same name, and they show up


in the same search results.


The other thing that you could do


is if there is a knowledge graph entry or a knowledge


panel on the side for the company that we show,


you can verify that.


And you can add the other social media profiles there as well.


So that's something that wouldn't necessarily


affect the ranking of those pages.


But it makes it a little bit easier


that if we show the knowledge graph entry for the business,


then you can go to the social media profiles


directly and view whatever they're


posting on social media.


So those are the two aspects that I would look at there.


SPEAKER 2 The second question, I'm


not quite sure actually whom to ask this question,


because this will be tricky for me.


So what happens for our company when we search it on Google


Maps, it shows Google Business listing automatically.


There is no problem with that.


But when we search it on Google organic search engine,


it shows all the results related to our company,


but it does not show Google Business listing


on the right side of the result. But I'm not


assured to whom to ask this question, whether it is you


or whether it is the Google Business listing team.


So I just need to know.


Yeah, I don't know.


I feel that's also more of a ranking question


in terms of we can find your business


and show it in the normal search results,


but maybe we're not showing the Google My Business entry


for a business like that.


And I don't know the details of how the Google My Business


profile ranking side of things work.


I could imagine it also takes into account things


like the location, where maybe if your business is not


actually locally or nearby, then maybe we


wouldn't show the Google My Business entry in the side.


But I don't know.


My feeling is there is nothing technical


that you're doing wrong if the listing is available


and it's just not ranking in the search results.


But you can still ask in the, I think the Google My Business


team has a separate help forum specifically


for companies that are listed in Google My Business.


So I would double check with them


to see if there is something that you can do.


Maybe there is a simple trick to make it easier


to connect those two worlds.


But my feeling is that probably this


is just the ranking question.


OK.


No worries.


Cool.


All right.


Mark.


Hi, John.


My question is regarding title tags.


Traditionally, I was used to just having one title


tag at the top of the page, which would describe


the subject matter of the page.


But I've recently been using a WordPress page


plugin that's been adding title tags to SVG images.


So when I look at the source code,


I end up with approximately 19 title tags.


And now, the designers are telling me that's perfectly OK.


Google will recognize them.


But I feel really uncomfortable about that.


And what I'd like is some clarification.


Are title tags within SVG images,


do you either ignore them altogether,


or do you know it's something completely


different than the main title tag?


I think this was an issue a couple of years back.


But I think we've since resolved that.


And in general, I wouldn't worry about this,


especially if you're seeing the search results are OK.


So that's something where I would do things


like go into Search Console and look at the top queries


that people are using to find your website,


and then just try those searches out.


And then look at the titles that are shown there.


And if that looks OK, then I wouldn't worry about it.


But the title tags are showing correctly.


But the reason why I've looked in the code


is that there are pages which I do feel,


which they've been indexed by Google,


but are not ranking where I think


they should be for the quality of content.


They're not ranking in a top 100 really well-written, unique


content.


And I think they should be appearing somewhere.


And I'm looking for the reason.


Do you think it's possible that they may contribute


to confusion with Google?


I don't think so, no.


No.


It's something where, at least at the time


when I first saw this and we had problems with that,


it was more a matter of we were accidentally


taking these titles and showing them


as titles in the search results.


And that's kind of annoying.


But it wouldn't cause any issues with ranking of the pages.


So just because you have multiple titles on a page,


especially if they're in SVG files,


that's something where we would say, whatever.


That's perfectly fine.


The other place I might watch out for this


is in image search results, if those SVG files are


images that you want to have appear in image results.


Facebook, Instagram, icons.


Yeah.


No.


I wouldn't worry about that.


Yeah, that's perfectly fine.


OK, thank you, John.


Thank you.


All right.


Let me go through some of the submitted questions.


And if you have any questions along the way,


feel free to jump in.


Feel free to raise your hands as well.


I'll try to go through more kind of live questions


later on as well, depending on how things


go with the submitted questions.


So the first one is also about sitemaps.


We've recently made large changes to our sitemap file,


both adding and removing pages in an effort


to improve our SEO.


To our surprise, each change significantly reduced


our impressions and our clicks.


Does Google penalize directly or indirectly


for large sitemap changes?


Or on the other hand, does Google


boost more longstanding content?


No.


So I think for both of those questions, there is a clear no.


In particular, sitemap file changes are perfectly fine.


And some websites have a lot of sitemap changes


that they do because they make changes to their pages a lot.


And that's perfectly fine.


The sitemap file helps us to crawl more efficiently.


The sitemap file is not a ranking factor on its own.


So just because it exists, because you're


changing something, because it stays stable,


that is not a ranking factor.


Also, with regards to longstanding content,


we don't boost longstanding content or evergreen content


or content that hasn't changed.


It's something where I think the effect that most people see


is more around what people actually are expecting


to find in the search results.


And sometimes you want something more like a stable reference


to find more information on a topic.


Sometimes people want to find the newest updates


on a specific topic.


And that kind of intent can change over time.


Or usually it does change over time.


For example, if you're looking at, I don't know,


a vacation place, for example, then maybe


if nothing is happening, if everything is fine,


then you would expect to find more stable content


about that location.


Whereas if some event took place in that location just recently,


then you expect to find more news, kind of new updated


content about that location.


And then over time again, it'll shift more towards kind


of the evergreen content again.


And these are things that our systems try to recognize.


And they do change the rankings of these things over time,


depending on what we expect that users are trying to find.


Let's see.


Similar question.


We see a spike in traffic shortly


after introducing new types of pages followed by tapering off.


Though we don't expect our users to behave any differently


based on how long the content has been live,


our content isn't very time-based,


nor at all newsy.


Do you have any thoughts on why we might see


this sort of release spike?


So I guess this is kind of almost


like the opposite of the previous question,


where the previous person was like, oh,


when I make some new changes, then everything goes down.


And this person is like, when I make changes,


everything goes up.


I think probably what is happening


in this particular case is that we're seeing


new content for a website.


And especially when it comes to new content on a website


or new websites overall, there's kind of this period


where we recognize the new content.


We can crawl and index the new content,


but we don't have a lot of signals


for that new content yet.


And then we have to make assumptions.


And our systems try to make assumptions


where they think this is probably


in line with the rest of the website.


But sometimes those assumptions are kind of on the high side,


where we say, oh, this is fantastic content, probably.


And sometimes the assumptions are more on the lower side


or a little bit more conservative and like,


oh, we have to be careful with showing this new content.


And that's something where you will


see that sometimes new content performs particularly well


for a period of time, and then it settles down again.


Sometimes it performs kind of badly initially


and then settles down in a higher state.


This is something which is essentially just


our systems kind of trying to figure out


where this new content should fit in before we have a lot


of signals about the content.


And in the SEO world, this is sometimes


called kind of like a sandbox, where Google is keeping things


back to prevent new pages from showing up,


which is not the case.


Or some people call it like the honeymoon period,


where new content comes out and Google really loves it


and tries to promote it.


And it's, again, not the case that we're explicitly


trying to promote new content or demote new content.


It's just we don't know.


And we have to make assumptions.


And then sometimes those assumptions are right,


and nothing really changes over time.


Sometimes things settle down a little bit lower, sometimes


a little bit higher.


I'm trying to add my site map to Search Console


and receiving a 403.


We have a firewall blocking the request.


I guess that might be the reason.


Can we get a region or IP address


that Google is trying to access the site map to whitelist them?


So we don't have a list of the IP addresses for Googlebot


because they can change over time.


But we do have a method of you verifying


whether or not a Googlebot request is legitimate or not.


And we have that documented in our Help Center.


So in a case like this where you really


need to block everyone else and only let Google look


at the content, that's something that you can do.


Specifically for site map files, we've said that's OK.


I would, of course, watch out for the other search engines


as well so that you don't block them


from accessing your content because otherwise they


wouldn't be able to access it.


But essentially, for site map files,


you can verify the request.


Usually, the way that this is done


is you look at the user agent.


And if it's a Googlebot user agent,


then you take the IP address that the request has


and you do a reverse lookup to find the host


name for that IP address.


And then you do another lookup of the host name


to double check that the IP address is correct.


And that's something that you can do at scale.


You can cache these for a while.


You can keep them like that for a bit


and collect those IP addresses if you want.


I would just be careful with the assumption


that one IP address will always be the same one because we


do have different data centers in different locations.


And sometimes you end up with different IP addresses


that are used for crawling.


So I would regularly at least update your lists


if you're generating these lists on your own.


If we have a blog post about the finances of a company, which


is only relevant for a few months per year


until the next report comes out, is it better


to update that blog post or to create a new one in terms


of SEO for Google?


Does it hurt the SEO to have a page change every month


or every three months?


So that's, I think, something that comes up regularly.


Well, regularly, of course, if you're


creating content regularly.


And our recommendations there are essentially so, I mean,


this is assuming that you want these financial pages


to show up in search.


If you're maybe taking a step back, if you're just like,


well, we put these pages out there, but we don't really care


if people find these pages.


We care about the rest of our website.


Then in a case like that, you can do whatever you want anyway.


But if you do want these pages to be found,


then usually the approach is to have one stable URL


for this content.


And usually, you would want to keep the older


versions of the content and move those to an archive section.


So essentially, you would have the current report


on a kind of a clear URL, which is, I don't know,


financial report, that HTML.


And you would take the last report that you have


and move it to something like, I don't know,


2020 financial report, kind of an archive section


of your site.


And the goal here is essentially that that primary page


that you have, kind of the normal financial report page,


that that page is the page that collects the signals over time,


where over time, we will see if someone


is searching for the financial report for your company,


this is the place to go.


And if someone ends up searching for the financial report


for 2019 for your company, then we


can still dig up those archive pages as well.


But essentially, the primary financial report page


would not be relevant there.


And you can apply the same technique for anything


that you update regularly.


So if you have an event that takes place once a year


or every couple of months, then you


have one stable event landing page.


And then from there, you link to an archive section


with the older versions of that event.


Or if you have products where you're saying,


I don't know, I have an Android phone 27,


and it replaces the Android phone 25 or whatever,


then people will be searching for Android phone.


And they want to find that Android phone


general stable landing page.


So that's the approach I would take here.


You just have one stable landing page for the overall topic


that you keep updating and move the old content


into an archive section so that if people


are searching for the old content,


they can still find it.


But most people, when they're just


searching for the topic overall, they


can find that stable page.


And over time, that stable page will just


gain in importance across your website anyway.


So that's kind of the approach I would take.


Then a question with regards to iframes.


My site has a page with multiple iframes,


which are updated monthly.


The source is graphs that I make with Plotly JavaScript, which


I then host on the web pages.


And they're not available throughout the website


anywhere else.


So the first question is, should I


put a nofollow on those pages so that they don't get ranked?


I don't think you can do a nofollow on an iframe.


So probably that doesn't matter so much.


What you could do is use a rel canonical on the iframe


to content to point back to your general page.


That makes it a little bit easier.


But you can't put a nofollow on the iframe.


The second question refers to PageSpeed Insights test.


They appear to be very slow due to having


to load the Plotly library for each iframe separately instead


of just caching it.


Do you think I would be better off for going, let's see,


iframes, user interactiveness in the graphs altogether


and just switch them out with pictures


in order to rank them better?


Possibly.


I don't know.


So on the one hand, I would try to figure out


what you can do to make the JavaScript faster


in terms of caching.


So there is a lot of things that you


can do with regards to how you serve content from your server.


And with caching, you can probably


do some things to help improve the speed of those JavaScript


libraries.


So I wouldn't say it's absolutely necessary to get rid


of all of the JavaScript.


But probably you can do quite a bit to improve the speed


as well.


The other thing is with regards to the content of the iframes,


one of the things that happens here


is if you're generating these graphs with JavaScript,


we would not be able to index them as images.


So if, for example, you have fancy images


that you're creating and people are actually


looking for those images in image search,


then we wouldn't be able to index those as images


because we would essentially process the JavaScript


and see, oh, it does something fancy with the canvas


or whatever.


But we wouldn't see that this is actually an image that we


would be able to index.


So if you're seeing that people are looking for these graphs


using Google Images, then I would at least


make it possible that people can view them as images.


And the final thing here with regards to speed in particular,


it is possible that you can achieve a significant speed


boost by swapping out the JavaScript libraries


against static images.


Sometimes there are things that you


can do to make it so that they're still


kind of interactive, such as having the images


as placeholders.


And when you click on them, then you


go to the JavaScript version of the page


and you can interact with those images a little bit more


directly.


It depends, I think, a little bit on your pages themselves


and whether or not that actually makes sense.


Like if everyone is always interacting


with those JavaScript pages, then probably you


want to kind of keep it interactive by default.


However, if most people are just looking at those images,


then maybe you don't need to make them interactive


by default. And you can just cache the image,


make it so that when people click on it,


that they can go to the JavaScript version


and then do kind of the interactive bit there.


So those are kind of the aspects that I would look at there.


But kind of, again, just with regards to JavaScript library,


a lot of things you can do with JavaScript


and with the serving content from your server


that can make it fast too.


And yeah, I don't know.


I think there are probably also some other aspects


with regards to speed and ranking


that you could look at here.


Let's see.


In particular, if this is like a small part of your website,


then probably the overall aggregate data


for your website with regards to speed


will be independent of these particular pages.


If this is the primary part of your website,


then maybe it is a stronger aspect of the overall speed


of your website.


Question about responsive web design and display


none under mobile first indexing.


Can I assume that the content that is in HTML,


it's seen on desktop but can't be seen or accessed


from smartphone because it uses display none?


And responsive design is indexed in the web page


and responsive design is indexed and evaluated equally


as other visible and accessible content


under mobile first indexing.


So it has a little bit more details


on kind of what's happening here.


In general, we would be able to index this content


and we would be able to show it in the search results.


I would, however, go with the caveat


that you can test this yourself.


And you can double check to see if this is actually


ranking well or the way that you want


it to rank in the search results just by searching


for your content yourself.


In that regard, it's something where


it's like you don't have to take my word, but rather you can try


it out and see what actually happens there.


So purely from an indexing point of view,


we would be able to pick that up.


And we might not recognize that on mobile you would never


be able to access this content.


If it's accessible on desktop from our point of view,


that's also OK.


So it's not the case that the mobile version


has to be one to one exactly the same as what


is visible on desktop.


It can be the case that there are actual content differences


there.


If most sites at the moment are on mobile first indexing


already, so perhaps your site is on there as well,


and then you kind of see exactly what's happening already.


We're still kind of struggling with some of the last sites


with mobile first indexing.


So hopefully we'll be able to shift more of those over,


I don't know, next couple of months or so.


Let's see.


Yes.


Regarding this, I also get sometimes confused about,


so if the mobile is mobile first index,


then Google will take the content which is appearing


for mobile device.


That is one step for indexing, and next step is for ranking.


And you have also told that we take


consider mobile content for ranking and indexing purposes.


But we are just trying to serve that content in desktop


but not in mobile.


So how Google will take this kind of infrastructure


or this kind of elements for ranking and indexing purposes?


Now, if your site is on mobile first indexing


and you have content that is only in the HTML on desktop,


we would not be able to index that.


So that would be essentially invisible to us.


The way that you can test is by using the Inspect URL tool


in Search Console to do a live fetch with the mobile version


and to look at the HTML to see if it's actually in there.


If it's not in the HTML on the mobile version,


if it's only visible for desktop users, for example,


then we would not be able to index it,


and we would not be able to use that for ranking.


SPEAKER 2


Yes.


SPEAKER 3


In mid-June.


So I want to optimize my page speed.


And there is one issue.


There is a recapture, JavaScript.


So how to optimize that?


I'm facing issue there.


I don't know.


It's something where if you're using JavaScript on your pages,


which is slowing things down for your users,


then we would see that as your page is being slow.


So it's not the case that we would say, oh, this is recapture.


We will ignore it, or we don't count it against your website,


or this is, I don't know, Google Ads,


so we won't count it against your website.


It's really users are seeing that things are slow,


and that's what we use for the speed.


SPEAKER 4


It's a really facing issue with recapture JavaScript.


There is a third party showing as a third party.


So is there anything to defer the particular JavaScript?


I don't know how the recapture script is embedded.


So that's something where sometimes the way


that you embed a third party script


can play a big difference in how the speed is done


or is seen by users.


Sometimes scripts are just slow.


And I don't know.


In particular, the recapture script,


I could imagine that it has to do some things to recognize,


is this a user or is this not an actual user?


And maybe some of that is more processing intensive


and just takes time.


So if that's the case, then I would just


think about what you can do to improve


the speed of your site overall.


And maybe that includes removing some of these scripts


or removing some of these scripts


from pages that don't necessarily need that script.


So I mean, I don't like to say, oh, you


should remove Google's scripts from your pages.


But if these things are slowing your pages down,


then that's something that sometimes you have to do.


And sometimes it's also something


where you can contact the team that is implementing this script


and say, hey, your script is so slow.


I'm going to remove it unless you make it faster.


And maybe if they get this feedback,


they'll be able to improve things.


I don't know.


Let me just run through some short questions that


are still submitted.


And then we can get back to more live questions.


And I also have a bit more time afterwards if any of you


want to hang around longer.


Does getting more Google reviews or responding to them


increase your SEO ranking in any way?


As far as I know, no.


So it might be that it affects something in Google My Business


and the local listings and the Maps listings.


But at least from an SEO point of view,


we don't look at the number of Google reviews that you have


or the back and forth that you have with regards


to Google reviews.


How do you deal with hreflang when there's not


a translation for every page?


I think we touched on this.


I implemented custom tracking for my website


that is triggered by JavaScript on-page load


and hits a subdomain.


Seeing crawl stats for my domain property,


I identified that one third of all crawls


are on that tracking subdomain.


Could this be interfering with the crawling


of the main subdomain?


What would be the best approach to avoid this tracking


subdomain to be crawled?


So I guess, first of all, if it's a tracking script


and it's not necessary for your content,


you can block it by robots.txt.


And if you block it by robots.txt,


we would not crawl that part of your site.


So we wouldn't take that into account.


So that's kind of the practical effect there.


My guess is that this wouldn't be negatively affecting


your website anyway.


So it's very possible that you're


seeing this as something that is visible in the reports,


but not necessarily as something that is actually


causing issues on your website.


In particular, if we can crawl your normal content quickly


enough, if we can pick all of the changes, the new things


that you put out, if we can pick them up quickly enough for you,


then I would not worry about this.


I think it's something you could optimize with robots.txt


to block the tracking subdomain.


But if you're not absolutely sure what the tracking


subdomain all does, maybe there's also an API there


that pulls in content or I don't know,


then I wouldn't necessarily just block it by default and say,


oh, I don't want any of this crawled,


because it could have other effects as well.


But if you're sure that this is just a tracking script,


it doesn't affect the rest of your pages,


everything loads normally without it, go for it.


Search Console mobile usability report


says text too small to read.


What is the minimum font size we should maintain?


I don't know.


So I looked briefly for our documentation on this.


I don't think we have the exact font size documented.


However, in the Lighthouse tool, where there's also


kind of the mobile friendliness test that you can do,


it looks out for 12-point font.


So that might be something to aim at,


or at least try out the Lighthouse tool


and see how that works out there.


One of the things with font too small


that I've seen with mobile friendliness tests


is sometimes this is triggered when the CSS for your pages


can't be loaded properly, when we think, oh, it's


a big desktop-sized website, so we


have to shrink the whole page down,


and then it looks a lot smaller.


So that might be something that throws things off


a little bit.


In particular, if you're seeing this issue being


flagged for individual URLs across your website


and not for the whole website overall,


then it might just be that, oh, we


weren't able to get the CSS file once,


and next time we can get the CSS file, and it'll be fine again.


I'm running a website using WordPress.


I have a question about structured data.


For non-AMP pages that contain structured data,


is there anything else that I should be setting besides


the substantial guidelines?


If I'm concerned about structured data,


is it better for SEO to make my site AMP?


So AMP or not AMP is essentially independent of all structured


data questions.


For structured data, I would primarily


focus on the aspects that you can see in the search results.


So that means if you have content


that matches a special format that we would show in the search


results, I would try to use the right structured data


to be visible like that.


For example, if you have recipes on your site,


then using the recipe markup makes it possible for us


to pick up nutritional information,


to show a nice thumbnail image, all of that.


If you don't have recipes on your website,


then obviously there's no need to add recipe markup


to your pages.


That wouldn't make much sense.


So my recommendation here would be


to see the AMP or not AMP question as something separate.


And a lot of times using AMP is a great way


to make a site very fast.


So if you're struggling with speed with your non-AMP version,


then maybe shifting to an AMP version or with the AMP plugin


would be an approach.


But independently of that, on the structured data side,


I would go through the structured data


that we have documented on our site


and think about the different types that we show there


and think about which types might make sense


for your website.


And based on that, then decide on the actual markup


that you put on your pages.


Cool.


OK.


I think maybe we'll just go to more live questions


to close things out for the recording here.


Let's see.


Roushik Kesh, I think.


I hope I got your name right.


Hi, John.


Hi.


So I have a website consisting of medium pages.


So basically, we fail automotive part.


So putting static content on every page is hard for us.


So we just change the part description and part number


on every page.


So my question is, does Google consider this


as a duplicate content first?


And second thing, is there any other way


we can use to create dynamic content for my pages?


So these are my two questions.


What kind of dynamic content is that?


So basically, we are saving automatic parts pages only.


So it's like code pages only.


So we take information from the user.


And then we take a lead on this.


OK.


So it's basically a big catalog of parts that you have.


And you're creating web pages for that, right?


Correct.


Yeah, I think that's perfectly fine.


It's essentially a database-driven website,


which tends to be generated dynamically like that.


From our side, we wouldn't necessarily differentiate


between you're generating the HTML pages with a database


or you're generating the HTML pages with static files.


We don't see that difference.


So we essentially just look at the content


that you're providing.


And if the content is useful, if it


matches what people are searching for,


then that's perfectly fine.


How you get to that content is up to you.


Sometimes it makes sense to go through a database.


Sometimes there is separate text files.


That's totally up to you.


I think the important part here really


is the content itself has to be useful and compelling.


So if, for example, you're a reseller


for a catalog of products, like, I don't know,


maybe for a big car manufacturer,


you have all of their parts.


And you get their database of parts.


And you just put their database of parts online as well.


Then essentially, you're not providing


a lot of unique value by just putting the same database


online.


And you really want to focus a little bit more on the, I


don't know, additional value that you can provide past just


taking someone else's database and putting it online.


OK.


So currently, we are facing de-indexing of these pages.


So we are not taking this data from other side.


So it's an in-house content only.


We are just taking the part numbers and all those.


So we are facing de-indexing issues now.


So is this could be a reason for that?


Yeah.


It's hard to say without knowing more about your website.


But I think you're probably on the right track.


The thing with indexing a large database like that


is that our systems are also very dynamic in that they will


kind of re-evaluate how much content we need to have indexed


from individual websites over time.


And especially with larger websites,


it's completely normal that sometimes a lot of content


is indexed, sometimes less content is indexed.


And these kind of fluctuations, they happen all the time.


What I would watch out for here is


that within your website structure,


you structure it in a way that the critical pages are


recognizable for Google as well as being critical pages.


So that could be things like your category pages


or your subcategory pages or kind of the blog posts


or content that you have written about your products.


In that sense, we don't need to have


all of the individual products indexed


if we have your category pages indexed, for example,


because on the category pages, you also list the products.


And if someone is looking for a specific part number,


they can find your category page.


And from there, they can still go to the individual part.


So that's kind of what I would watch out


for here with a larger site is assume that some of this content


will not be indexed.


And assume that with the kind of structure


that you provide of your website,


you can kind of guide Google to focus on the parts


that you think are important.


And as long as those important parts are indexed,


then the rest can fluctuate a bit.


And if you have a million products and, let's say,


1,000 category pages, if those 1,000 category pages are all


indexed, then the fluctuations with those million products,


that's a big number of fluctuations.


But it doesn't matter so much for your overall business


because people can still find the content that they're


looking for.


OK, John.


Thank you.


Sure.


All right, Shashi.


Hello, John.


Hi.


Actually, today my question is quite technical.


I just want to know what are the best practices to handle


JsRentorBlock?


To handle what?


Sorry.


JsRentorBlocking, JavaScript-rendered-blocking.


JavaScript-rendered-blocking.


So to block JavaScript from being rendered or to fix it


so that it's?


To fix it.


Yeah.


Yeah, I think it's a big, big range of things


that you can look at here.


So it's really hard to say what the best practices are.


I would recommend as a start to at least go


through all of our documentation on JavaScript and SEO


because we have a lot of things documented.


We have a lot of videos about this as well.


And to use the tools that we have to double check your pages.


And it might be that your pages are all OK in that regard


and you don't have to do anything special.


It might be that you recognize some issues


that you have to focus on.


And the other thing that I would recommend doing here


is if you run into specific technical issues


with regards to JavaScript and rendering and SEO


is to make sure to join the office hours with Martin.


He does them, I think, every other week or so.


And he's our expert on everything


around JavaScript and SEO.


And if you come with a technical challenge to him,


then he will be super happy to help


you to try to figure that out.


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


SPEAKER 2


For the loading, is it workable?


It can certainly be OK.


I mean, these are techniques that you


can do to improve the speed of your pages.


And depending on what actually happens


on your pages in that regard, it can


have an effect on improving the speed for users


without necessarily causing issues for SEO.


Deferred loading, for example, is something


that essentially takes the JavaScript


and processes it a little bit later.


If that JavaScript is not critical for your pages,


if it doesn't generate any special content,


then it doesn't matter for SEO purposes


if it's loaded later or earlier.


However, if that JavaScript generates the primary content


of your pages and you're deferring it


from being loading until after Google processes your pages,


then we wouldn't have that content for indexing.


So that's something where you kind of


have to make a judgment call on your side


and say, this makes sense, or this doesn't make sense,


or this improves speed but causes technical SEO issues,


or maybe things improve speed and they work well for SEO


as well.


All of these are things that you can test out.


Yeah, because they find that 50% of Js are unused data,


unused Js.


Yeah.


Yeah, I mean, a lot of sites have tons of JavaScript on them


that is never used.


So that's something where I suspect by focusing


on the JavaScript that you have on your site,


cleaning all of that up, you can save quite a bit of time


or rendering time as well for users.


I think there are multiple approaches


that you could take there.


And you could, for example, go into the JavaScript files


and tweak things line by line.


Sometimes you can just take a tool


and run it over your JavaScript files


and it does everything for you.


Sometimes it's a matter of switching


to a more lightweight library rather than including


everything, just include the parts that you actually need.


I don't think there's one answer that


would fix it for all websites.


Yeah.


Thanks, John.


Thanks for that.


Sure.


OK, let me pause the recording here.


And we can go through the rest of the questions that


are still lined up.


You're welcome to stick around a little bit longer.


But just for sake of having a reasonable length


for the recording, I always like to pause things.


Thank you all for watching if you've


been watching this on YouTube.


And feel free to drop in in one of the next Office Hours


as well if there's something on your mind


that you'd like to talk about.


All right.


Language complexities in Search index selection and more! | Search Off the Record

Welcome, everyone, to the next episode of Search Off the Record.


This is our podcast.


Oops.


And I'm reading the script wrong.


Welcome everyone to the next episode of the Search Off the Record podcast.


Our plan is to talk a bit about what's happening at Google Search, how things work behind the


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


My name is John Mueller.


I'm a search advocate on the Search Relations team here at Google in Switzerland.


And I'm joined here today by Martin and Gary.


Plus, we have a special guest today, Cherry.


Cherry has been working on our team for a bit over a year now, and it's cool that she


was willing to join us here for an episode.


Cherry, do you want to introduce yourself briefly?


Sure.


Hi, I'm Cherry.


I have been on our team for not too long, but I've been working on Search for quite


some time now.


Before joining the team, I was part of the Search Quality team.


Some of the things that I worked on and maybe you might have come across are the web spam


reports that we publish every year on our blog, the Search for Beginners video series


on the YouTube channel, and other initiatives that happen in Asia, such as webmaster conferences


and the launch of local blogs and online help communities.


Cool.


So all of these are in Asia.


Where are you located, Cherry?


I am based in sunny Singapore, which is a little far from everybody else.


So I have been focusing a lot more on search in Asian markets.


So cool.


It's almost like way on the other side of the planet.


Travel is so far away.


So it feels even further away nowadays.


Can you tell us a bit more about the search quality work and the web spam team?


Is that like all one thing or are these different parts of Google?


Well, they are different team, but the goal of both teams is the same, which is to surface


good search results and also to keep the search result away from spam as much as possible.


So given that task, which is quite a big scale, basically the two teams work together and


from different angles.


So the methods and the focus, the responsibilities are different.


Okay.


Wow.


Sounds like we must have a ton of teams that are working on search to make sure that everything


comes together in the right place.


One of the things I heard is that in some countries, in particular around Southeast


Asia or probably also other regions, we have trouble with the amount of content that we


can show in search.


Is that something that you've run into?


Right.


Yeah.


So in Asia, Asia is a diverse region actually.


So this means that you can't treat Asia as one bucket, which I'm sure it's also the same


with other continents too.


So like there are different needs for each country and in some cases, like each part


of the country.


And yes, one specific problem that we do run into is that we don't have enough content


in certain Southeast Asia languages and in certain verticals.


Okay.


Wow.


So I don't know, is that a problem of the content that is out there or is that just


that our index is so skewed towards, I don't know, Western content, Western languages?


I don't know.


Gary, is that something you've run across?


Well, yeah, definitely.


I mean, I spent quite a bit of time in Asia when we don't have this, you know, corona


and things.


And also this ties really well into my next topic in how search works, topic that we started


previously and we can talk about index selection here.


Generally speaking, we don't have a bias towards any one language.


In fact, we are paying quite a bit of attention into ensuring that every language has the


same potential indexing wise.


So basically regardless if it's a tiny language like Hungarian, for example, or a big language


like Chinese or English or Arabic, each has or will have enough resources to end up in


our index.


And when I say language, I do actually mean the set of docs that are written in that particular


language.


We do have trouble with certain regions.


And if you think about it, there are languages, for example, that are not really meant to


be written, although they are written nowadays to preserve them.


So for example, if you think about the Pygmy language in Africa, there is lots of clicking


going on that's very hard to express in writing.


And for us, that's very hard to understand indexing wise and probably for us ranking


those languages, those more special languages is also very hard.


But indexing wise, we do try to index them and store them in case someone figures out


how to search for those languages.


And of course, the same applies to Southeast Asian languages or Asian languages as well.


They have the same potential indexing wise, and we just select them and then wait for


people to search for content from that segment of the index.


Now, selecting those docs, the docs that are in those languages, is actually a very sophisticated


business.


We are using the signals that we collected in the previous stages of indexing to make


a decision whether a document should be indexed or not.


Now, if you compare languages here, then you are going to have a very hard time.


So for example, if you compare any of the Arabic languages or Persian languages to English,


then you will have trouble getting enough of that content, of the non-English content


in the index, because they would be just overwhelmed by the amount of English content.


And for that, we have, I will say, quotas, but it's really just basically an insurance


policy for us to ensure that those languages also end up in our index.


So they have an equal chance with English for ending up in our index.


And then when we build our index and we use all those signals that we have, let's pick


one, say page rank, then we try to estimate how much we would serve those documents that


we indexed.


So will it be like every second we will have a query that triggers those stocks, or will


it be once a week, or will it be once a year?


And based on that, we might use different kinds of storages to build the index.


If you think about it, when you are building your computer, for example, if you are an


idiot like me and builds their own computer, then you will think a lot about the storage


mechanisms that you put in your computer.


First you are going to have RAM, for example, RAM, random access memory, which is the most


expensive kind of storage that you can possibly put in your computer.


Well, maybe the L1 caches or L2 caches are more expensive, but you are not putting those


in your computer.


Those are integrated.


But the first one that you can put in your computer, that's RAM.


That's the most expensive kind of storage.


They come in small capacities, and then after that you have to choose between a hard drive,


like a magnetic hard drive, or a solid state drive.


The solid state drive is more expensive, but it's way faster.


I don't remember the exact number, but it's orders of magnitude faster than a hard drive.


And that's because, for example, you don't have seek time on solid state drive.


You can just go to a specific section right away at the speed of light, quite literally,


and start reading from that section.


While with a magnetic drive, like a hard drive, you actually have to move the arms of the


hard drive to a specific section, to a specific disk, and start reading from the section where


you believe that the data is.


So based on how many times we think that the document might be served, we might store the


documents in our index in these different kinds of storage mechanisms.


And that's what practically defines the index tiers that we have.


So for example, for documents that we know that might be surfaced every second, for example,


they will end up on something super fast.