that this is something that is really


English Google SEO office-hours from February 19, 2021

important within your website by showing it to users


more frequently, having visible links to that content


within your website, the clearer we


can understand that this is probably something


that you care about and that you want to treat


with a little bit more weight.


So for example, if you have a lot of products on your website


and there's one product that you really care about,


because maybe it's the product that you're most proud of


or it's the product where you earn the most money from


or whatever reasons, if you have all of your products linked


in the same way within your website


that you have different categories and subcategories


and then it links to the products,


then from our point of view, we can't really


tell that this is a really important product,


because it's just one out of 1,000 other ones


that you have on your site.


Whereas if you were to go forward and specifically link


to that product from your home page,


for example, from other important pages


within your website, then it's a lot easier for us


to recognize that, oh, this one particular product is so much


more important for this website than all


of these thousands of other products


that are on the website.


And that way, you can kind of guide Google


to understanding your website and what


you consider to be relevant a little bit better.


We have a website that we found many spammy sites pointing


to in the links section.


Is it worth disavowing those domains?


We don't have any manual actions in Search Console.


And we think those bad sites are dragging down our traffic.


So in general, in cases like this,


you don't need to disavow those links.


Our systems are really good at understanding


which links are relevant and which


links we can completely ignore.


And there are lots of levels in between.


But essentially, random spammy links pointing to a website


is super common.


It's something that happens to pretty much every website


out there.


And our systems have, I don't know,


tens of years of experience with dealing with that


and ignoring a lot of that.


So offhand, I would not worry about this.


If you're seriously worried that these might not


be getting picked up properly by Google systems,


and you really, really want to make sure


that they don't cause any problems,


then go ahead and drop them in the disavow file.


The disavow file is something we see more as a technical thing.


It's something we look at and we say,


oh, you don't want these links?


Then fine, we will take them out.


It's not something that we would count against your website.


It's not something where we would say,


oh, this person must have been a spammer


because they're trying to disavow all of these links now.


It's really just a clean sign for us.


You don't want those links counted,


and so we won't count those.


So if you're really, really worried about these links


and you're losing sleep, you're kind of wondering,


is it affecting our rankings, then just drop those domains


in the disavow file and move on.


Then you're really, really sure that our systems are ignoring


it.


For the most part, I think sites don't need to do anything


there.


If you've had a site on the internet for a while,


then you'll see all of these weird links to your site.


And you can assume that Google is


pretty good at seeing that too.


During the December update, we had a ranking drop


to our game site.


This is very surprising, as in my opinion,


we have one of the best and most complete experiences


for this type of site.


While other sites offer mainly questions for the game,


we do that as well as show votes for correction.


And we even have country-specific data.


My question is, was this drop due to something technical,


such as site speed or hosting, or are we somehow


not satisfying users as well as other sites,


or was it a mistake?


I don't know.


Like the last part, was it a mistake?


I tend to assume that these kind of changes are not mistakes,


but they can happen.


So if you're really kind of super sure


that you've checked everything and you think you've kind of


gone through everything with regards to your website,


then what I would recommend doing first off


is posting in the Webmaster Help Forum


and getting some input from other people there.


And the folks in the forums can also escalate that to Googlers


as well.


So if there's something really, really weird happening,


then it's theoretically possible that there's


a mistake on our site.


I think it's super, super rare.


It's extremely rare that I run across something


where when I send it off to the engineering team,


they're like, oh, something weird is happening


that we have to fix.


But it's theoretically possible.


That said, my assumption would be that it's really more tied


to other parts of your content, other parts of your website,


and trying to understand how we should be showing that content


more.


So site speed, I suspect, is less of an issue.


In particular, the Core Web Vitals


are something that we'll start using in May.


So that wouldn't be affecting your site now.


It might be that there's some crawling issues if you


have a really large website with regards to speed.


But it sounds like if your site has been around


for a longer time, then probably we


have indexed the appropriate content for your site already.


So that's less of an issue.


So my assumption would be more in the direction


of the content and the way you're providing


that content for users.


I took a look at a handful of pages from your website.


And I could see how our algorithms might


be a little bit confused with regards


to how we should be showing this site in search.


In particular, because on a lot of these pages,


there isn't a lot of content there.


So that's something where if I go to random pages


on your site, I'll have that card in the center.


And essentially, everything else will be ads.


And I could imagine that our systems struggle a little bit


with understanding what should this page be relevant for.


So that's something where maybe it's worthwhile to rethink


a little bit how you want to be found in search


and how you can put your best foot forward when it comes


to being found in search.


One thing might be to think about,


do you actually need all of these individual pages indexed?


Or should you have something more about the content overall


itself as an indexed thing?


So maybe less focusing on individual pages,


which just have one or two questions on them,


and focusing more on a category of items


where you have more actual content on a page.


How does Google judge to show more images in the search


results in a single blog post?


I don't think we have anything specific in that regard.


Sometimes we can pick up images through structured data,


and we can show those in the search results.


But essentially, the algorithms that we


have for showing the thumbnails within the individual search


results entries are things that are more, I don't know,


broader algorithms in terms of us recognizing


there are multiple images on a page


and making the assumption that maybe these multiple images


on a page are particularly useful or relevant for users


to understand why your pages are relevant for the user


now in the search results.


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


I think there are two or three types of structured data that


are slightly different in that regard


in that you can provide a carousel of images


or a carousel of pieces of content.


I think something like the how-to structured data


falls into that category and maybe something


around recipes, not quite sure.


But all of that should be documented in our developers


guide, and you can kind of look at that to see,


is there something specific that you could be doing?


My recommendation would be to look into the search results


of what your site is focusing on and then,


based on that, to try to work backwards.


Like, is there a specific type of structured data


that these people are using, or is this just


Google's algorithms trying to be helpful and just


show more images?


Cool.


OK.


I think maybe we'll just switch back a little bit to questions


from you all, since there seem to be more and more


hands being raised.


Not quite sure where we were.


Rob, were you next?


It says Lee was, but I don't know if he's already been.


But I just want to ask about 404 errors in Search Console,


or 400 errors in general.


Are they still a thing?


Because I only see 500s and no, 400s,


despite having lots of 404s.


Are they still reported, or they moved to some other section?


Good question.


I don't know.


Yeah.


We used to have the crawl errors report,


but I think some of that was moved.


It's indexcluded, I think.


You can find them in the excluded.


OK.


So they're not errors anymore.


They're excluded instead.


Oh, OK.


They're in the index coverage report in that case.


But can you then drill down and see them?


I'm actually in that report right now,


because I had to pick out one before.


So you can click on the 404 post in the coverage,


and then excluded.


Click on the 404, and then you can drill down and export it.


Thanks, John slash Robin.


Cool.


Thanks.


You always start with an I don't know anyway as a disclaimer.


I think, yeah.


I don't know.


Like these changes in Search Console,


it's sometimes hard to keep up.


That's why we have Daniel on the team working directly


with Search Console.


I'm like, oh, yeah.


OK.


So many things.


That's all from me.


Rita?


Hi.


I have two questions.


First, I have a question about these pages that


don't have actual content on them.


And it doesn't make sense to directly put content on them.


Like online tools, online calculators, online translator,


they don't actually have content.


How do we optimize those pages for Google?


I don't know.


We should write blog posts and link to them or what?


Yeah.


I mean, from our point of view, we


don't have a kind of a system that uses online tools


and tries to see what they're useful for.


So if you have a calculator on your site,


our systems will go and just see, oh, the numbers 0


through 9 and some symbols are on this website.


We don't necessarily know that it's a calculator.


So anything that you can do to make it easier for us


to understand what this page is for, that helps us.


So that's something like using clean titles and headings


on the page, having some informational text on the page


itself is really useful.


If you have a blog where you can write about these tools,


that's obviously also useful because then we


understand a little bit the context of those tools


a little bit better.


So essentially, anything that you


can do to bring more textual information to those tools,


that helps us.


In particular, if these are tools


where you have some functionality that we just


don't see because Googlebot doesn't interact with the tool.


So if you have something like a map


and you can click on different locations


and you can see opening hours for different, I don't know,


businesses that you're working with,


Googlebot is not going to click on the map


and see what happens.


But rather, we need to be able to find


that information in some textual format in another way.


So either having more general information


on a page in a case like that would help.


Like, these are the opening hours of our different branches.


Or even listing that information directly on the page itself,


that also helps us.


So if it's like a look up of the opening hours,


then maybe just list the addresses along


with the map on the page so that users can click on the map


if they feel more comfortable with the map


or they can scroll through the list to find that information.


So essentially, when you have these kind of online tools,


anything that makes it easier for us


to understand what we should be showing this page for,


that's useful.


AUDIENCE 1 Thank you.


And the second question is, we had a big news website.


And on December update, we lost like 50% of the traffic.


And mostly the discover part, it completely suddenly got


gone away.


And we couldn't find out the issue.


Can you please explain more about that?


JOHN MUELLER Yeah, I don't know.


That's kind of tricky.


So I guess I'm tricky on multiple levels there,


because I suspect you're talking about the core update that


happened in December.


AUDIENCE 1 Yes, yes.


JOHN MUELLER Yeah.


So with the core updates, it's not so much


that we're flagging problems within a website


and saying we think this website is bad or has a problem,


but more that we're trying to understand


the relevance of these pages a little bit better.


And the relevance is something that


is tied to so many different factors.


And that's essentially what we try


to pick up with the core updates.


And the information from the core updates


is also used in other parts of search,


in particular in Discover as well.


And because of that, it can also happen


that maybe a change is kind of subtle in search in general,


but has a stronger effect in Discover,


just because we're a little bit more critical on the Discover


side.


With regards to improving the situation there,


we have a blog post about core updates


that has a little bit more background information


on the kind of things we look for when


we try to understand relevance.


I would definitely go through that.


It also has a little bit of information


on how things work with regards to recovering after making


changes within your website.


Because from our point of view, it's not the case


that a website is doing something wrong,


that it has to fix when it comes to core updates.


But obviously, you want to have similar traffic as before.


So improving your website overall,


that will help us to better understand


how the relevance is kind of better


than before for your website.


So unfortunately, there is no one simple thing


to focus on there.


There are lots of small things that kind of add up.


And a lot of that is listed in the blog post as well.


SPEAKER 2


And Feros, I don't know if I'm pronouncing


your name properly.


SPEAKER 3


Actually, I have a question.


When I'm working for him, I apologize for my English.


It is very good.


So please don't mind.


Yeah, so the issue is that a few of the competitors,


they have laid some kind of reviews on other websites.


So the problem that we are facing right now


is that our ORM is not maintained as it was before.


So what we did is we asked the website that were showing up


the reviews in Google.


But ultimately, the result is that they


are asking for $2,000 to remove those reviews.


So I'm not sure that what exactly should we do.


Yeah, I don't know what the best approach is there.


I mean, that's something we sometimes hear about as well.


I think the most straightforward approach


is either to find some kind of a solution


there in regards to having that content removed.


If that's something where you think for legal reasons


that they're publishing things that are not correct,


then that might be an approach that you could take there.


The other approach in general with regards to reputation


online is to make sure that the more relevant content is also


visible in the search results, which


could be something from your side that you provide there.


So that might be an option there.


If this is something where it looks


like there is a really big scheme in play with regards


to this kind of content, then that


might be something that we can pass on to your team


here to take a look at and to understand a little bit better.


But I would see that more as kind of a long-term approach.


So for things like that, I would recommend also


maybe posting in the Webmaster Help Forum


so that other people can take a look


and give you some tips there.


I don't think there is one simple answer that you


can use in these kind of cases.


And it's similar with other situations


where maybe there is a legitimate negative review


out there, where you can't just force people


to remove negative reviews.


But in the Webmaster Help Forum, you'll


probably get some input on some options that you can do there.


Maybe you'll also get some, I don't know,


more straightforward feedback on how, well, maybe you


should just be providing a better service or whatever.


But I think this kind of direct and, I don't know,


more or less honest feedback is sometimes


very useful to understand, well, what


is the general perception externally with regards


to this type of issue?


And is it something that I can resolve on my own,


or is it something I need help with from other people,


or do I need to kind of rethink what I'm doing with regards


to how you're active online?


That might be something that also comes into play there.


And as I mentioned in the other questions before,


the folks active in the Help Forums


can also escalate these issues to Googlers.


So if they see something that comes up again and again


in the forums from the same sites


or doing similar schemes kind of thing,


then they do pass that on to the team here.


And we do try to take a look at that.


It's sometimes tricky with regards


to what we can do in cases like that.


In particular, if the website is not spammy,


if it's a normal website that we wouldn't remove for web spam,


then there's no kind of web spam policy reason


for us to remove it.


There might not be other policy reasons for us


to remove it either.


Sometimes it's really quite complicated.


But yeah, I think taking the step


and getting more input from other people


might be a good first step.


Thank you so much, John.


I have one more question.


That is, can I please?


Sure.


Yeah.


So basically, one of our page was not indexing.


I don't know the exact reason what it was.


So what we did is we started Google Ads for that page.


And besides this, we started social sharing.


We started to share this on Facebook and other platforms.


Now, I'm not sure what was the exact reason.


But first, that page was on third page of Google's result.


And now it is under 10.


So I'm a bit confused at what was the exact reason.


Was it traffic that matters?


Or was it, yeah, please.


So both of those things, ads and social sharing,


are not things that we take into account for search.


So my guess is it's either something, an indirect side


effect of that, or it's just that our systems decided


at some point that, oh, we should also


index this page there.


But both the ads and the social sharing side


are things that we don't take into account.


Traffic, in general, also not.


It's something where various SEOs externally


have made tests with regards to traffic


to see if traffic can get a page indexed.


And that's not the case.


So from my point of view, probably it's just,


like, it was almost indexed.


And at some point, our system said,


OK, we will actually index this page and show it in search.


OK, so it was the hard work of our team, thanks a lot.


All right, sure.


Lena?


Yeah, I'm happy that we got some time.


So we have a news website that, in addition to articles,


published a bunch of URLs with short updates,


so not much content.


So I'm wondering if there's a best practice for news websites


to avoid thin content, and if you would recommend


to just noindex all of these URLs


with just the short stories?


I mean, if you don't want them showing up in search,


you can use noindex.


But I don't think you would need to noindex something just


because it's a short news article.


Sometimes short articles are completely fine.


So I wouldn't focus so much on the length of the article,


but rather, do you want it indexed or not?


Yeah, we would.


But I was just afraid that it will be viewed as short stories


because it's just a paragraph, nothing else.


Yeah.


So for web search, we don't care about the length


of the articles.


I don't know if there's any kind of policy


thing around Google News.


So especially if you mentioned that this


is on a news website, I vaguely recall some errors


that we had in Search Console way in the beginning where


we would show this content, this news article,


is too long or too short.


Maybe that's something that plays a role there


with regards to news content.


But if that is the case, you can also


use the Google News, google.news meta tag


to specifically block it from Google News


so that you can keep it shown in search


and just block it for Google News.


OK.


Thank you.


Sure.


OK, let me just pause the recording here.


I'll stick around a little bit longer


for all of the questions that are still pending.


And if anyone has anything else they want to share.


But thanks for joining and watching so long,


if you're watching this as a recording.


And thanks again for all of the questions that were submitted.


And hopefully, I'll see you all again


in one of the future Hangouts.


Bye, everyone.


SEO Mythbusting - Official Trailer (New Series)

No one understands how the Googlebot actually works.


The ominous, the great, the Googlebot.


What are the top three things that I should be doing?


Is there much of a difference between framework sizes and approaches for how those might get


crawled?


Is JavaScript the devil?


On one end is content and the other is app, but it blends at a certain point.


People often find that their sales will go up.


They'll get more engagement from audiences they didn't know they had just because they


can now access the content.


There's a gap in translation between the SEOs and the developers and how they think and


what they consider.


Let's bust these myths and let's shed some light on these topics.


I don't know, Martin, do dogs look up?


I think so.


We should myth bust that.


Yeah.


It has nothing to do with SEO.


It has nothing to do with SEO, but it's pretty good.


Right.


See you later.


Why does the indexed pages count vary?

Today's question comes all the way from Brazil.


Why does the indexed pages count vary?

Marco asks, why is the number of pages indexed on Search Console


Why does the indexed pages count vary?

different than what appears on Google.com?


Why does the indexed pages count vary?

Depending on where you look, you might see different numbers


Why does the indexed pages count vary?

for your site's count of index pages.


Why does the indexed pages count vary?

Which one is the right number, and which one should you use?


Why does the indexed pages count vary?

The actual number of pages on a website is surprisingly hard


Why does the indexed pages count vary?

to determine.


Why does the indexed pages count vary?

At first, one might assume that it's just


Why does the indexed pages count vary?

a matter of counting through the pages,


Why does the indexed pages count vary?

starting with the home page, and following the links from there.


Why does the indexed pages count vary?

However, on most websites, there are many, many ways


Why does the indexed pages count vary?

to reach a specific page.


Why does the indexed pages count vary?

There might be different URL parameters,


Why does the indexed pages count vary?

so everything after a question mark in the URL


Why does the indexed pages count vary?

that lead to the same page.


Why does the indexed pages count vary?

Sometimes, upper and lowercase URLs also lead to the same page,


Why does the indexed pages count vary?

or perhaps you can add a slash to the end


Why does the indexed pages count vary?

and still get the same page.


Why does the indexed pages count vary?

Some websites have a calendar or something similar


Why does the indexed pages count vary?

that leads to an endless number of new and valid pages.


Why does the indexed pages count vary?

Assuming that most websites have an infinite number


Why does the indexed pages count vary?

of possible URLs, should Google just show an infinite count?


Why does the indexed pages count vary?

That probably isn't that useful.


Why does the indexed pages count vary?

So which numbers can you see, and where do they come from?


Why does the indexed pages count vary?

There are three main places to get counts


Why does the indexed pages count vary?

for the number of indexed URLs.


Why does the indexed pages count vary?

First, you can check a site query in Google Search.


Why does the indexed pages count vary?

Second, you can use the index status report in Search Console.


Why does the indexed pages count vary?

Or third, you can look at the index count per sitemap file.


Why does the indexed pages count vary?

Let's take a look at these options.


Why does the indexed pages count vary?

In Google Search, you can just enter a site, and then a colon,


Why does the indexed pages count vary?

and then your domain name.


Why does the indexed pages count vary?

Google will show you a sample of the pages indexed


Why does the indexed pages count vary?

from your website together with an approximate count


Why does the indexed pages count vary?

of the URLs found on your website.


Why does the indexed pages count vary?

This number is generally a very, very rough approximation


Why does the indexed pages count vary?

based on what we've seen from your website over time.


Why does the indexed pages count vary?

We try to show search results as quickly as possible,


Why does the indexed pages count vary?

so that count is optimized more for speed


Why does the indexed pages count vary?

rather than for accuracy.


Why does the indexed pages count vary?

It's useful to look at this as a very rough order


Why does the indexed pages count vary?

of magnitude, but we don't recommend


Why does the indexed pages count vary?

using that count as a metric.


Why does the indexed pages count vary?

The second and third methods require that you


Why does the indexed pages count vary?

use Google Search Console.


Why does the indexed pages count vary?

Search Console is a free tool you can sign up for and verify


Why does the indexed pages count vary?

your website with.


Why does the indexed pages count vary?

In Search Console, there is a report


Why does the indexed pages count vary?

that shows the number of indexed URLs from your website.


Why does the indexed pages count vary?

This count is much more accurate and includes the actual indexed


Why does the indexed pages count vary?

URLs from your website.


Why does the indexed pages count vary?

It's mostly based on pages that have unique content,


Why does the indexed pages count vary?

so it would usually exclude URLs with irrelevant URL parameters,


Why does the indexed pages count vary?

for example.


Why does the indexed pages count vary?

However, it can still include many URLs


Why does the indexed pages count vary?

that you don't necessarily care about.


Why does the indexed pages count vary?

The third place to check is a site map's indexed URL count.


Why does the indexed pages count vary?

Per site map file that you submit,


Why does the indexed pages count vary?

you can see how many of those URLs were actually indexed.


Why does the indexed pages count vary?

One thing to keep in mind is that this count


Why does the indexed pages count vary?

is based on the exact URL as specified in your site map


Why does the indexed pages count vary?

file.


Why does the indexed pages count vary?

So if your page's content is indexed


Why does the indexed pages count vary?

with a slightly different URL, then that


Why does the indexed pages count vary?

wouldn't be counted there.


Why does the indexed pages count vary?

In practice, we recommend either the site map file


Why does the indexed pages count vary?

or the indexed URL report in Search Console


Why does the indexed pages count vary?

as the basis for your website's metrics.


Why does the indexed pages count vary?

These are currently the most accurate indexing numbers


Why does the indexed pages count vary?

available to site owners.


Why does the indexed pages count vary?

You can also leave your burning questions and comments here,


Why does the indexed pages count vary?


Thin content (and why quality content matters) | Sustainable Monetized Websites

Welcome back to the series Sustainable Monetized Websites,


a series for online content creators and content managers


who also handle monetization.


I'm Aurora, and I work in policy education for publishers at Google.


Oh, and these are my two co-hosts, Organica and Monetized.


In this episode, we will talk about why it is important


to have a more sustainable, more inclusive, more inclusive,


to have good quality content.


Let me start by saying, provide unique and relevant content


that gives users a reason to regularly visit your site.


Google may classify pages that have thin content


with little or no added value as low quality.


I'll talk about four types of low quality content


that will impact how your site does,


both in organic search as well as in your monetization strategy.


First, automatically generated or auto-generated content.


This is programmatically generated content.


In cases where its intention is to manipulate search rankings


and not help users, Google may take algorithmic


or even manual actions on it.


Organica, give us some examples.


Text that makes no sense to the reader,


but that contains search keywords,


low quality translations by automated tools


with no curation before publishing,


stitching or combining content from different web pages


without adding any sufficient value.


Second, thin affiliate pages.


There are many great sites monetized with affiliate links


that add value, for example,


by offering original product reviews, ratings,


or product comparisons.


If you participate in an affiliate program,


make sure you differentiate your site from the rest.


Unique, high quality and relevant content


provides value to users


and distinguishes your site from others,


making it more likely to rank well in Google search results.


However, thin affiliate websites


do not provide additional value for users.


These sites are often templates


with replicated or similar content.


Thin affiliates create a frustrating user experience


and they're not useful for our users.


Thin affiliate sites consisting of content


that appears in many other places on the web


may be negatively perceived by search engines


and users alike.


What can you do to help your site stand out


and differentiate from others?


Ask yourself, why would a user want to visit my site first


rather than visiting the original merchant directly?


Make sure your site adds value


beyond simply republishing content


from the original merchant.


Avoid making the affiliate program


the central part of the content of your site.


Move your unique and exciting features into the foreground,


such as information about price or product category.


Ensure your affiliate program


matches the product category of your audience.


The story goes this way.


The better the affiliate program fits your site's content,


the more value it will add


and thus the more likely you will be


to make money from the program.


Use your website to build a community among your users.


Regularly create unique and valuable content


that your frequent users will care about.


This will help build a loyal readership


and can also create a source of information


on the subject you're writing about.


Keep your content updated and relevant.


Fresh on-topic information is more useful to users


and in turn is compelling for search engines


to keep up to date in their search results too.


A third type of low quality content


is replicated content from other sources.


You can learn more about it


on the replicated or duplicated content


and what to do with it episode in this series.


Fourth, doorway pages.


These are sites or pages created with minimal unique content


meant to focus on specific keywords.


They're bad for users


because they don't provide unique value


and end up taking the user


to essentially the same destination.


Sometimes they also lead users to intermediate pages


that are not as useful as the final destination.


They're made just for search engines


with little or no original content.


Search deprioritizes them,


publisher networks such as AdSense


have policies requiring original content


and they're generally a waste of everybody's time.


Including the publisher's time.


Organica, give us some examples of doorway pages please.


Having multiple domain names or pages


targeted at specific regions or cities


that funnel users to one page.


Pages generated to funnel visitors


into the actual usable or relevant portion


of your site or sites.


So remember, make sure your site provides unique


and relevant content to your users.


Although monetized and organic content


work in different ways,


sites that don't meet the monetization


and organic search guidelines


may be removed from the search index


and have their ads disabled.


In the next episode,


we will deep dive into user-generated content


and building your community.


Subscribe to this channel so that you don't miss anything.


Don't forget to like and share this video


and leave a comment if you have any cool topic suggestions


for future episodes.


English Google Webmaster Central office-hours hangout from August 9, 2019

All right, welcome everyone to today's Webmaster Central


Office Hours Hangouts.


My name is John Mueller.


I am a Webmaster Trends Analyst at Google here in Switzerland.


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


where webmasters and publishers can join in and ask questions


around web search and the website.


As always, it looks like a bunch of questions were submitted.


But if any of you want to get started with the first question,


you're welcome to jump in now.


I would like to ask a question.


Yeah, it is about geoblogging, because we


have a web page which has a lot of video and programs, which


we are only allowed to show in our country.


So we have geoblogs.


So if people come outside, they actually


redirect it to a page where it says that they


can watch this program.


And also, if you enter the front page,


you can only see content which you're able to watch.


So my question is whether we can whitelist Google


Quoas, or that is a no-go, or how we can fix that.


So in general, you should treat Googlebot


the same as any other user from the same region.


So since we mostly crawl from the US,


you would need to treat Googlebot


like another user from the US.


That's a bit, I don't know, problematic in some cases,


because the other way around would be no problem.


If you have a website in the US and you


say, I want to block users in Europe,


then that would be no problem.


But if you're a website in Europe


and you want to block users in the US,


then you would be blocking Googlebot as well.


So that's not really something that you can get around there,


or at least according to our guidelines.


What you can do for video content


specifically is specify which countries


the content is available for.


So what you could do, theoretically,


is make it so that the HTML pages are


accessible by users everywhere, and that the videos only play


in the appropriate countries.


And the video files, those are things


that you can show to Googlebot, even though users in the US


would not be able to see it, because you can specify


the limitations with markup.


SPEAKER 2


Yeah.


OK, cool.


I just wanted to make sure, because that


was the easiest workaround.


I think from a web spam point of view,


the web spam team would probably not take action on that.


But according to our guidelines, that would not be appropriate.


Yeah, OK.


Thank you.


Sure.


All right.


Any other questions before we jump into the submitted ones?


SPEAKER 3 Hey, John, I have a question.


We have a main domain redirect.


So will it affect my data in Search Console?


How do you mean main domain redirect?


Say example.com slash.


It is redirected to the example.com slash en.


So should I have to change my main domain in the Search


Console?


Oh, no.


That's a perfect time.


If you're redirecting to a lower level page


on your domain, then you can keep the whole domain


in Search Console.


You can if you want.


Just verify the subdomain or subdirectory.


You don't need to.


OK.


So if verifying two domains, will my data


will be available in both the domains?


Yes.


Thanks.


Sure.


All right.


Let's jump into some of the submitted questions.


As always, if you're ready.


Sorry, John.


Hello.


Yeah.


One more before we go.


So I asked the question on the Masters Help community.


The question is about Google Search Console.


In the old version of Google Search Console,


we had a great way to discover blocked resources.


Now, as I understand, in the new one,


we have the URL Inspection Tool.


The Help Center suggests to use this tool


if you want to discover blocked resources.


So when I use Test My Site tool, I see blocked resources.


But I can't find the same data in URL Inspection


Tool in Search Console.


Well, I wonder why.


And also, wasn't it better to provide the information


about blocked resources for all sites,


not on a single URL basis?


Thank you.


Yeah.


That's a good request.


So I think we dropped that feature


because we noticed that most sites were no longer running


into problems with that.


Because with the shift to mobile friendliness,


that was a big problem.


If a resource was blocked from crawling with robots.txt,


then sometimes we can't tell if a page is mobile friendly.


But that has improved significantly across the web.


So we decided to drop that feature.


But it's good to hear feedback that it was actually useful.


So I'll definitely pass that on to the team.


OK.


Yeah, I don't have any work around at the moment


to get a broader list of all of the blocked resources.


OK, thanks.


Sure.


Hello, John.


How are you?


Hi.


Yeah, John, I have a question regarding the Webmaster Office


Hours, which was streamed live on November 2018.


Oh, gosh.


Yeah, it was very, very ago.


So yeah, so in that session, you mentioned


that the discovered but not indexed thing,


which will not happen because the pages are duplicated.


Or maybe the pages have the same theme,


but they are having different content.


But once the Google will crawl 1,000 pages,


then Google will get to know, right now,


this website has the same design,


same way of content showing on the website.


So I mean, in this way, you mentioned this.


If we are using the script-based title and meta description


automation, if we are putting the title and meta description


using the scripts, right?


We are using the, for example, we have, I mean, right now,


we have 2 lakh pages, 200,000 pages right now


we have on our website.


And we are using script automation


by putting the Google, like, meta tags, metadata,


all tags, and metadata, everything.


We are using this script-based automation.


So you mentioned that it is not a good practice.


And my question is, in the Magento,


when people are uploading Excel sheets, right?


So that is also a kind of automation


because they are updating their metadata by using the Excel.


So how Google is reacting towards the Magento websites


and how Google is reacting to the custom-based websites which


are using the script-based automation?


OK.


I think those are two quite different things.


So I think what you're referring to


is using Google Tag Manager to edit titles and description.


No, no.


We are actually not using Google Tag Manager right now.


We are just using GTM only for the schema-based variable


creation thing.


So we are just using the script-based automation


for our metadata.


In this way, what we are doing is we are just putting,


you know, in Excel, we do concatenation, right?


So the concatenation process, we are just


using the script for that on our website.


So every time when we upload, for example,


50,000 more pages for our website, so we have a template.


We upload that template again.


Then every page has its own meta tag, all tag, and everything.


So because right now we have products, we have different.


We have different content.


We have different fact pages on our page,


different, different pages.


But still, our indexing is not improving.


I mean, my main question is, is it because of the design?


Is it because of the automation?


Is it because of the script?


I mean, what could be the reason?


Because right now, we are doing everything.


I mean, at our end, we are trying to keep unique content


on our website.


We are doing everything, I mean, you know, in a best way.


But still, we are facing this problem in the indexing way.


So we have like 28,000 pages indexed only on.


So that's why.


Yeah.


OK.


So I think there are a few aspects that might


be confusing and being mixed up.


So in general, when you say you're using a script-based


approach there, it sounds like you have these scripts running


on the server.


It's not JavaScript.


It's not on the server.


Sorry to interrupt you.


But it's not on the server.


But once we, before uploading the website live, what we do


is we have the developer version of our website.


What we do is we upload our data on the developer version.


And then the developer, what they do


is they upload that version on live server.


So we are not actually creating the script-based thing


on live website.


So we are doing on our before version,


you can say, the first version of the website.


Yeah.


OK.


So I think, in general, you wouldn't


need to worry about the script part.


Because it sounds like I don't remember


that particular Hangout.


So it's been quite a while.


But one of the things we have talked about


is using JavaScript to update titles and descriptions.


And that would be something very different from what


you're doing.


So it sounds like you're uploading things.


And then you have a script that processes them.


And then you upload that to the server.


And that results in normal HTML pages


being uploaded to your website, which we can process completely


normally.


So that's very different from using


JavaScript that runs in a browser


to update the titles and the descriptions.


So from that point of view, I think you're fine.


I think the general problem that you're seeing


is just that you have a lot of pages.


And only a part of them are being indexed.


And that's something that can be quite normal.


It can also be a sign that maybe there


are some technical issues there.


What I would recommend doing is posting that maybe


in the Webmaster Help Forum and having some other people


double-check your site and just give you some general advice.


It could be that, for example, that we're just not convinced


about the quality of the website.


It could be that there's a technical issue that's


blocking us from crawling these pages completely.


But it's very hard to say just off the hand.


I think, in general, the approach


that you have with uploading your content with an Excel


file and your server generates pages out of that,


that's perfectly legitimate.


That's something that a lot of sites do.


AUDIENCE MEMBER 1 Yeah, because when


I checked the Magento processing,


when I checked our website, so we are using PHP.


Magento is also on PHP.


So Magento is right now moved to React JS in 2.3 version.


So they have some different things.


But right now, I was just confused.


If we are doing the automation process in Magento,


then how could it harm to our website in the custom way?


So that was my concern.


JOHN MUELLER I think from the automation


that you're doing with uploading the information with a sheet,


that's perfectly fine.


That's not an issue.


And Magento is a fairly big platform


in that a lot of sites use it.


So if there were a general problem with Magento,


I think that would be very visible.


And it would be something that they would fix very quickly.


So I would just try to get advice from other people,


specifically for your website, and see


if there's something small that maybe you can change.


Or maybe you have to find other approaches to make


the website work better.


AUDIENCE MEMBER 1 OK, sure.


I'll get it done on Google Webmaster Forum.


Thank you.


Cool.


Hi, John.


Do you mind if I ask a question?


JOHN MUELLER Sure.


Go for it.


So I'm working with a site at the moment.


They have actually posted this on the forum.


So what's happening is we've got a bunch of pages


that are noindexed.


They then get the noindex gets removed,


gets introduced to the site map.


They then throw a load of errors in Search Console


that they're in the site map, but noindexed.


If you hit the Revalidate button,


it just says it just it checks a few


and then says that they're noindexed still.


It seems to me that the Revalidate button doesn't work


because we can go through them.


And there's definitely no XRobots header or tagging


the head of the page.


But it still just keeps throwing this error.


And we wondered if.


So the pages are not noindexed, or they are?


They previously were noindexed.


It's a user-generated site.


So the noindex gets removed when the content reaches


a certain threshold, i.e.


if it's had enough engagement.


They then get put in the site map.


And at that point, they error in Search Console,


saying that they're noindexed but in the XML site map.


So then there's like 2,000 of them at the moment.


But you can click the Revalidate button,


and it just says, no, they're still noindexed,


even though they're definitely not.


OK.


I suspect what's happening there is


that Search Console is a little bit faster


than the rest of indexing, which is surprising sometimes.


But what's probably happening is we're


seeing that these pages are noindexed.


And Search Console recognizes that they're in the site map


file, because that's where they are now.


And then Search Console will throw an error.


So basically, we're taking the old status


of the noindex pages and seeing that they're now


in a site map file and thinking, oh, you added noindex pages


to the site map file.


And we haven't actually reprocessed


the individual pages since you've


added them to the site map.


So does it revalidate, but not actually go off


and recrawl all of those pages?


Revalibate, is that in the index status, or is that the site map?


No, it's like a, so you can go into Search Console.


You pick the section of errors that you've got,


in this case, in site map, but noindex.


And there's just a button that says, revalidate.


From what I understood, it goes off and rechecks all those


pages.


But it doesn't seem to do that, from what I can tell.


It should.


The idea there is that it checks a sample of the pages first.


I think maybe like five or 10 pages,


and double checks that the error is resolved.


And then it'll trigger a reprocessing


of the rest of the pages there.


I'm not 100% certain how it would handle the situation


where you have the site map file in between,


if it just revalidates that these URLs are in the site map


file or not, or it actually recrawls the URLs themselves.


But I can double check with the team on that.


All right, cool.


Thank you.


Cool.


All right, let me run through some of the questions that


were submitted, because people spent a lot of time


pushing them in there.


So we should get through some of those.


What could be a reason that a huge listing, very popular


site not being switched to mobile first indexing?


Essentially, we have multiple classifiers


that try to understand when a site is


ready for mobile first indexing.


And usually, what we've seen with larger sites


is not so much that we'd say this is an important site.


We'll switch it over quickly.


But rather, we'll switch it over when we think it's ready.


And with larger sites, what often happens


is there are multiple sections of the site that


use slightly different setups.


So that's something that happens quite a bit, where you have


maybe multiple CMSs involved or multiple back ends


and front ends involved within the same domain.


And it can happen that maybe some of those systems


are not ready for mobile first indexing,


according to our classifiers, and others are.


And in a case like that, we'll hold off and wait a little bit


to make sure that everything is really ready.


Also, with really large sites, what we've started doing


is shifting a handful of URLs over to mobile first indexing,


maybe 1%, maybe a few percent, and seeing


how the site generally performs.


Are they seeing that the indexing is working well


with mobile first indexing for that site?


And if so, we'll ramp that up slightly.


So all of those things are aspects


that you might be seeing there with mobile first indexing.


I wouldn't see it as a sign that anything is broken or wrong.


If your site is not switched to mobile first indexing yet,


it might just be that our classifiers are still


a bit cautious and try to stay on the safe side.


The meta tags, keywords, and news keywords


aren't used anymore, I believe.


However, I see a lot of publishers are still using it.


Is it just redundant?


Should we use them, essentially?


We don't use them at all for search.


So you don't need to use them.


But at the same time, they also don't cause any problems.


I've used the keywords meta tags for my own sites


just as a way to help me focus on a specific topic


so that I know what I want to write about on a specific page.


And that's more for myself and not something


that search engines would really care about.


So maybe others are doing that, too.


But again, this is something that essentially is not


something that you'd need to fix or change.


It's just we ignore them if you want to provide them.


If your systems provide them automatically, no problem.


I recently uncovered a big canonicalization issue


on a large scale site where many pages were incorrectly


being canonicalized to other pages


with non-equivalent content.


Google was simply ignoring the rel canonical,


which makes sense.


Now I'm surfacing more examples across the site


of Google ignoring rel canonical, also


where it makes sense.


This got me wondering that if Google sees the wrong canonical


tags on a site often, if it then starts


to not trust the user-selected canonical URLs


across the whole site, and if it does lose trust,


then maybe Google systems think it's


better to select canonical URLs across the site on its own


versus using the canonical tag.


Do you know if that's the case?


So it's theoretically possible that we


ignore the canonical tag across the whole site,


but I think that would be extremely rare,


because that would generally be something


that our engineers would have to do pretty much manually.


What usually happens with the rel canonical tag


is that we do this on a per page basis.


And on a per page basis, we use a number


of factors that come into canonicalization,


including the rel canonical, including information


about the URL, about the content,


about other URLs that have the same content,


and we try to pick a canonical based on all of those factors.


And the rel canonical alone isn't enough of a signal


for us to say we will always be able to trust it.


If we see other signals that come into play,


then we might ignore the rel canonical on a page like this.


And that's something that happens on a per page basis,


so not something where, at least as far as I know,


we would do this on a per site basis and say,


well, the canonical links on this website overall are wrong.


Therefore, we'll ignore them completely.


It's more that on a per page basis,


we'll try to pick the canonical URLs that we think make sense.


I have a lot of excluded pages in my search console.


My valid pages are about 1 10th the number


of the excluded pages, and it's a big site


with 170,000 valid pages.


I'm wondering if excluded pages count towards our crawl budget.


Once Google decides a page should


be excluded from the index, does it still


crawl the page periodically?


Should I be concerned that the high ratio


of valid to excluded pages is eating up our crawl budget?


That's a good question, and a complicated one,


I think, in the sense that, yes, the excluded pages are counted


in the crawl budget in the sense that when we try to crawl them


and we end up not including them in the index,


then we've tried to crawl them.


And they count as an attempted crawl


and essentially count in that bucket of crawl budget.


However, what usually happens is when


we exclude a page for any particular reason, that


could be because maybe it has a no index tag on it.


It could be maybe we have a duplicate URL


and we picked a different canonical.


Then what generally happens there


is we crawl these pages a lot less frequently.


So while you might have a lot of pages that are excluded


and we might be recrawling them from time to time,


we'll be recrawling them a lot less frequently


compared to the URLs that we think


are important for your website.


So on the one hand, they do count in the crawl budget.


On the other hand, the effect within your site's crawl budget


is generally minimal.


Also, when we have a number of URLs


that we want to crawl for a website


and we also include a number of maybe excluded URLs or URLs


that we're not sure about, and we run into a situation


where we're limited by your site with regards to crawl budget,


then we will try to prioritize the URLs that we think


are more important over the ones that are less important.


So let's say in an extreme case, we can crawl 1,000 URLs a day


from your website.


And we know about 900 URLs that are good and about maybe 10,000


URLs that are from this excluded bucket.


We'll try to get those 900 good URLs in first.


And then the rest that we kind of have available there,


we'll pick from the excluded bucket


just to make sure that we're not missing anything,


that pages from the excluded bucket


did not end up suddenly becoming includable


and that maybe a no index is gone now


and we can pick that up again.


So yes, they're included in the crawl budget.


But generally, it's not something


that you need to worry about there.


OK, two really big questions.


Let's see.


I'm working for a travel agency.


We have our main platform and some


that revolve around the main one.


The revolving ones are all linked to the main one,


but they're not linked between each other


and all have a different domain.


The revolving ones spoke about the same thing


but ranks with different keywords and content.


So the subjects in these are identical.


It's all about travel.


The content is different, but there can be similarities.


My websites are all divided into continents,


and we're speaking about a lot of countries and cities


in those.


So it can look the same.


We're talking about the same cities and locations


in each of those but worded differently,


like if it was a different opinion


on an identical subject.


OK.


Let's see.


So maybe before I get into the questions,


this sounds a lot like something that you


might want to watch out for in that you're


creating a ton of content that can look a lot like doorway


pages in that you're just kind of switching different keywords


across all of these pages here.


So that's something where I would


tend to be pretty cautious about just running


a system like this with so many different domains and sites


that essentially cover the same content.


A lot of times what you'll find is


that if you have fewer pages or fewer sites,


you can perform a lot better in search


because we can see that these are really important pages


versus you're kind of diluting things across a lot of pages.


So let's look at the questions.


My issue is that I'm using a premade theme,


and I wanted to know if those would have an impact


on the ranking of my websites.


Not necessarily.


So whether or not you use a premade theme or a custom


theme, that's essentially up to you.


From a user's point of view, that


might be something that users recognize,


and maybe that's something where users will say, well,


I don't know if I can trust this website


if they're just using a theme that kind of came with WordPress


by default. But that's essentially up to you.


Let's see.


The second question, this is also


about having multiple websites.


Would applying a nofollow rule suffice?


So I think it's basically between the different websites,


or should I do some kind of Jedi mind trick,


like transforming those links into spans


and using JavaScript to redirect to my domain?


So I think, in general, the links between these sites


and pages is less of a problem than just the plain existence


of so many variations.


So I wouldn't worry about trying to hide any of the links


between those sites.


I would instead try to find ways to combine


a lot of these sites and pages so that you don't have


to have that many separate ones.


Usually, having fewer sites means


you can make those a lot stronger.


You can concentrate your energy on those sites.


A question about JavaScript.


If I can see my text in Google's mobile-friendly text,


can I ensure that Google doesn't have


a problem with reading and indexing


my content and my pages?


For the most part, yes, that's correct.


There can be subtle issues with regards to JavaScript.


But in general, the mobile-friendly test


is something that uses the new Chromium setup that we


use for Googlebot.


So if it works in the mobile-friendly test,


it should work for indexing as well.


One of the things to watch out for here


is that the mobile-friendly test, as far as I know,


doesn't follow the robots text rules.


So that's something where you might


want to use the inspect URL tool in Search Console


to make sure that actually your JavaScript files and your server


responses and all of that are working well


from that point of view.


I changed normal images to Instagram embeds


on one of my articles and saw a decrease in rankings, clicks,


et cetera, for image search.


It was a 43% decrease in image search clicks overnight


on a very reliable article.


Can you talk a bit about the difference


between normal images versus Instagram


embeds from Google's perspective?


So I thought that was an interesting question.


And I created a test page to see how this actually works.


Because it really depends a lot on how Instagram sets this up.


Because you're essentially just taking code from Instagram


and putting it on your website.


And depending on how they set up that code on their end,


it can have an effect on your website.


So in general, what the bigger picture change


is you're going from a situation where the images are embedded


in the HTML directly on your website,


where they're really easy for us to discover and really easy


for us to crawl and index, to a situation where we have


to process some JavaScript and do some fancy processing


to get to those images.


So that means it's a lot more work for us


to actually get to those images.


We can recognize those images.


And we can crawl those images using the mobile friendly test


shows those embeds as well.


So it kind of looks OK.


However, what I notice is specifically with the way


that Instagram embeds these images,


they use an iframe to embed the posts from Instagram,


which kind of makes sense.


But with an iframe, you're basically


adding another layer of indirection


between your page and the images.


So it goes from your page to this iframe,


and then from the iframe content to your images.


So that makes it a little bit harder for us


to pick up those images.


But what really kind of breaks the story for us


is that within the content that is embedded from Instagram


within the iframe, they use a no image index robots meta tag.


And this meta tag tells us that you


don't want those images indexed together with the page itself.


So if we just look at that iframe content,


we can recognize that there is an image there.


We can crawl that image.


But with that meta tag, you're basically


telling us that you don't want this image indexed together


with that landing page.


So essentially, by switching from a direct embed


of an image on your website to using Instagram embeds,


you're kind of telling us that you don't want these images


indexed for your website.


And with that, I think it would be


normal to see a significant drop in image search traffic


to those pages because you're essentially telling us


you don't want these pages to be indexed like that.


So from my point of view, it essentially kind of


comes back to you and kind of your preferences there.


I can understand that sometimes it makes sense


to embed Instagram posts directly or social media


posts in general because you get a lot of added value


from just kind of the whole everything


around that with regards to comments


and maybe the likes and the shares


and all of that information that is available within the embed.


On the other hand, it makes it a lot harder for us


to actually index those images.


So that's something that you almost


need to balance on your side.


Do you need to have all of this extra detail around the images,


or do you really need to make sure


that those images are well indexed for your website?


And depending on the website, you


might have preferences one way or the other.


If you want to have both kind of the Instagram embed


and to have your page ranking for those images,


then that will probably be tricky


and might involve weird situations


like having to put it in there twice.


Since a few months, we're seeing a new strategy


where big news websites lease a whole subfolder or subdomain


to a media company.


I think we've looked at this a few times here as well.


So the question is, this is spammy and I don't like it.


And does a search team know about this?


We do talk about this with the search quality team


from time to time.


And we do try to find examples where


we think that things are kind of worse for users and maybe also


situations where we think that things are actually


pretty good for users.


In general, I think these kind of changes


happen from time to time in that people will find something


that works really well for them.


And it happens to work really well in search.


And then suddenly everyone does it.


And then at some point, it becomes so, I don't know,


kind of problematic in the sense that it results in a lot more


low quality content.


And then the websites themselves get


seen as low quality content.


And things kind of settle down into a more reasonable place.


I haven't looked at this situation for a while now.


But I feel it's something where things


will be settling down into a more reasonable place.


And in general, when it comes to changes like these,


we try to avoid going down the route of manually kind


of adjusting the rankings of individual websites


because of these issues.


Specifically, when it comes to kind of topics


where it's more about quality rather than pure spam,


then we wouldn't have the web spam team go in there and say,


we need to manually adjust the ranking of these websites.


But rather, what we would try to do


is algorithmically try to recognize the situation overall


and kind of work out where the high quality,


the useful content is within setups like this


and to promote that appropriately in the search


results and to find places where our algorithms can


automatically recognize that this is not


so useful for users overall and to make


those less visible in the search results.


And sometimes this takes a little bit of time.


If a site has a fairly large volume of internal links, which


generate 301 redirects to reach the final destination pages,


will this impact crawl budget?


I see Google regularly visiting the 301 redirect URLs


and am assuming that placing the correct links


to the destination pages would be better utilization


of crawler resources and would speed up page load


time significantly for users.


This is a fairly large e-commerce site


where these kind of links are regularly and repeatedly


available 10,000 plus times.


In general, if we recognize that a page just bounces from one


URL to another in the sense that we find a link to one URL


and it redirects directly to the next one,


then that's something that wouldn't negatively


affect the crawl budget in the sense


that it's like we can process it right away.


It can mean that we spend a little bit more time


on a per URL basis to crawl this website.


And that can, in turn, still affect the crawl budget.


So in particular, if we recognize that we need,


I don't know, so many seconds to actually get to the content,


then we'll try to limit the number of simultaneous requests


to that website just to avoid causing any issues.


And if each request takes longer,


then that, in turn, does mean that we are not


able to crawl that much.


So theoretically, that could play a role.


In practice, it seems pretty rare.


And especially if you're talking about something


like 10,000 pages, then for most websites,


being able to crawl 10,000 pages,


especially if it's a fairly large e-commerce site,


that's not something that would cause any issues there.


So I think you'd probably see a small incremental change


with regards to our crawling if you were to link directly


to the target pages.


But you probably wouldn't see anything significant


when you're talking about 10,000 pages.


If you're talking about all pages within the e-commerce


site, so maybe you're always linking to a tagged URL,


and from that tagged URL, you're redirecting back to a clean URL


and you have that millions of times


across the whole website, then that


is something where I'd say you probably


would see a significant change in how much content we


can crawl from that website by fixing that setup.


But if you're talking about 10,000 pages


within an e-commerce site that has millions of pages,


then that seems fairly insignificant overall.


To increase the EAT of a medical page,


should I use article schema, for example, or for example,


web page or medical web page as a latter two has an option


for reviewed by property?


Or maybe Google can find that the article was reviewed


from the context if I provide such details and schema


property reviewed by is not necessary.


I think that's kind of up to you.


We do try to recognize these additional details


about information about the author, information


about the reviewers, about the website overall


through a number of ways, partially


through the content directly.


So kind of similar to how users would see it


if they go to the page and they see kind of information


about who has reviewed this content


or who has provided it, that's really useful.


If it's just hidden away in structured data,


then that's not very useful for users


because users tend not to use view source when


looking at a page to determine whether or not


they should trust it.


So I would try to find an approach that


works well primarily for users and focus on that.


With regards to article or web page,


that's something where I'm not exactly sure what


the difference there would be.


It seems that from a semantic point of view,


they're slightly different.


There's a bit of an overlap there, though.


So depending on the page that you have,


I would try to pick the appropriate one there.


So if you have an article, then maybe the article schema


is the right one.


If you have something more like a tool or a lookup or a forum


or something, then maybe article is not the right approach


there.


Google has a penchant for adding branding


to title tags in search results where there


are none written on the site.


For example, HubSpot has a guide to cryptocurrency


without the brand name in the title,


and Google added HubSpot to the headline in the search results.


Is this purely aesthetic, or is there possibly more to it?


For example, a signal that Google


likes to see sites add branding to titles themselves.


So for the most part, we do this automatically


because we find that it helps users to better understand


the context of the individual pages


that we show in the search results.


And a lot of times, I think we do a fairly good job of that.


Sometimes we pick the wrong ones.


And for those that we pick wrong,


it's useful to get feedback on that.


So if you see something weird happening with the title tags,


then feel free to let us know about that.


But it's not something where I would


say you have any kind of a ranking advantage


if you add a site title to your title tags


or any other kind of advantage there.


It's essentially purely something


that we end up doing for users.


Sometimes we also rewrite the titles.


Sometimes we have to shorten them


if they're on a mobile device, for example.


The same thing happens with the descriptions.


Sometimes we adjust them subtly based


on the query that was made.


So all of these things are aspects


that we try to do to make it easier for users


to understand how your page is relevant for them


in their specific situation.


And it's not a sign that you have


to copy that and do the same thing on your pages directly.


I have a question about Google Analytics.


For one of my clients under GA Organic Keywords,


I see something like np dash or np dash user slash register.


What could possibly be that I'm doing wrong


in terms of tracking?


I don't know anything about Google Analytics.


So I can't really help you with that.


My guess is maybe you're providing URLs


to track on your own.


But I really don't know how those things end up


in Google Analytics.


We have a website with 50 million monthly page views.


And when people search for our brand directly,


they don't see site links nor the site link search box


below our home page result. Search Console


detects the site link search box markup correctly,


but it just won't show up in the search results.


Does this mean that Google considers


our site to be low quality?


60% of our traffic comes from organic search,


and the average session time is over four minutes.


So no, it doesn't mean that we think


your website is low quality.


Maybe just first of all, that's something


that I really wouldn't worry about specifically


with regards to the site links or the site link search box.


We show site links and the site link search box


when we think that it makes sense for a site


and for the queries that are going to the site.


And it's not necessarily something


that is tied to the quality of the website.


Obviously, the website could still be low quality.


So it's not that I'm saying your website is high quality.


But just because we're not showing site links or a site


link search box is not a sign that we think


the website is low quality.


Specifically to the markup of the site link search box,


that's something where if we were to show a search


box below the listing, then we would use the markup


to show the version that you prefer to have shown.


But it's not the case that just because you have the markup,


we would be more likely to show that box.


So it's still kind of as a first step.


If we were to show a site link search box,


then we would use a markup.


It's not that if you have the markup,


then we would show the site link search box.


My question is regarding multiple countries targeting


for multiple products.


If I have product one, which is in demand in the US,


and product two, which is in demand in Canada,


and there are other products for both countries.


Oh, this is complicated.


If I target product one, product three, and product four in US,


will it make it complex for Google


to understand in which country I'm


targeting my entire website?


Usually, this is not an issue.


So in general, when it comes to geotargeting,


you can specify that in multiple ways.


But it needs to be a clear section of a website.


So for example, you can say your whole site is targeting


one specific country.


Or you can say I have multiple subdomains


or multiple subdirectories.


And if you list those separately in Search Console,


you can specify the geotargeting for those parts individually.


What you can't do is specify geotargeting


for individual pages within your website.


So kind of with that out of the way,


that kind of means if you have a shop with multiple products


on it, then you would use geotargeting


to specify the primary geotargeting of the website


overall.


Or you can use geotargeting to say,


I don't want to have any geotargeting for my website.


I just want to rank normally.


And probably, that would be the right approach here,


in that you're essentially a global website.


And some products are more popular


in individual countries, and that's perfectly fine.


We will try to rank them appropriately,


but there's nothing special that you need to do there.


So there's no special markup that you


need to put on these pages to say,


this product is specifically for the US,


and the other product is specifically for Canada,


and maybe a third product is global.


We'll treat all of these products as being global


and still try to rank them appropriately


within the individual countries.


And a Google My Business listing question,


which I don't really have any insight on.


In a recent webmasters meetup, it


was said that the ccTLD is still a strong ranking factor.


So does it mean that a.com website with a separate folder


is not a correct practice?


No.


Essentially, when it comes to geotargeting,


we use two main factors, or two main ways


to try to figure out the country.


On the one hand, if you're using a country code top level


domain, then that's a pretty clear sign


that you want to target that country.


On the other hand, if you use a generic top level domain,


then you can specify that in Search Console.


And both of those things are very important.


So both of these ways are equivalent.


So if you have a generic top level domain,


you can specify the geotargeting for the whole website.


You can verify just the subsection of that site


and set the geotargeting for just that subsection


in Search Console.


And all of that is essentially equivalent.


In practice, that means you can use the layout,


the kind of the setup that you think works best for your website.


But there might be some maybe market specific approaches


that you want to look at as well, in the sense


that from an SEO point of view, like you


can do all of these things.


But from a practical point of view,


maybe users in one country really


prefer to see their own top level


domain in the search results.


And they're really kind of cautious


about the more generic ones.


And then that's something where it's


more a matter of marketing which setup that you use.


Sometimes it's also a matter of policy in that maybe,


if you're, for example, if you're


targeting users in China, maybe there


are some policy reasons where you'd have to say,


well, I need to use a Chinese top level domain,


because that's kind of what's required there.


I don't know if that's the case.


But I could imagine there are situations


that end up like that.


John, can I just follow up on that question?


OK.


So in current Search Console, I haven't looked,


but so can you set up forward slash US and target US


and then forward slash UK and target UK?


Can you do all that in the new Search Console?


I think you're targeting is not yet in the new Search Console.


So you'd have to do that in the old one.


But you can kind of mix and match.


The thing that you can't do is if you use domain verification,


then that's only in the new Search Console.


But if you have the subfolder verified,


then that would be available in both of them.


Hi, John.


Hi.


So John, actually this was my question regarding geolocation.


So a little different, a little conclusion


was like best coffee shop in New York.


One website is in New York or in USA, which is targeting US.


And one website is in India, which is set up


country target in India.


Then how geolocation works, basically.


Like somebody searching from India,


we'll see India site first.


Possibly.


So what happens with geotargeting is


when we recognize that a user is in one country


and they're looking for something


that seems to be specific to their country,


then we will use geotargeting to promote the local sites.


So there are a lot of situations where if you search,


you're basically trying to search globally.


If you're searching for an instruction


manual on one product, then you don't really


care which country that's from.


And then geotargeting is not really a primary factor.


On the other hand, if it looks like you're


searching for something to buy, then maybe geotargeting


should be a stronger factor.


So that's something where if you're


doing a query that is kind of artificial,


like best coffee shop in New York while located in India,


then I could imagine that our systems get a little bit


confused because they don't really know exactly what you're


trying to do.


But if you're searching for best coffee shop


and you're located in one country,


then we'll try to bring results from that region.


I think with that specific query example


that you had and the location that you had there,


then that's not really something that


would map well to the general user side of how


users use geotargeting.


Hey, John.


Can I have a question about the Google Search Console API?


Sure.


So we're a site that's in the Alexa global top 1K.


And around the 1st of April, we've


noticed that hundreds out of the many thousands of sitemaps


that we have have since then been reporting


incorrect indexed data via the API.


So in some cases, ever since early April,


the index count is the same.


And we know for sure that that can't be the case.


The index count in some cases is reported as zero.


Or in other cases, the index count


just seems wildly inaccurate.


Meanwhile, the submitted count does seem accurate.


And so essentially, we posted on the webmaster forums


asking for some insights into the issue


and to see if others were facing a similar problem.


But we weren't able to gain much ground there.


So I was just kind of wondering what you think


the next steps should be for us.


And perhaps maybe we could escalate this issue,


because it seems like if there is some indexation


bug or something around the API that maybe was resolved


for most sites, our site still seems to be affected.


That's unfortunately something in the API itself.


So that's something where at some point, when


we switched over to the new UI for sitemaps reporting,


I think they stopped updating that data in the API.


So that's probably why you're seeing some stale data


for some sitemaps and some zero data for some sites


within the indexing count there.


I need to talk with a team about what the next steps there are.


I know they've been looking into it


and trying to find a way to resolve that.


But I think it's been long enough


that we need to at least document this state to make


it clear for people who are seeing this problem


that this is not something that they're doing wrong,


but rather we just aren't updating


that data at the moment.


I see.


Is there any interim solution that we can employ, perhaps,


submitting those sitemaps as new sitemaps


or doing anything else differently that could enable


us to get this data?


Because this data is pretty critical for us,


and not having it for a large portion of the sitemaps


that we submit is pretty unfortunate.


I don't think so.


I think at the moment it's not being updated at all.


So for the sitemaps where you are seeing a number there,


I suspect it's just the number that was there since April.


And for the ones where you're not seeing anything,


it's basically we haven't added anything there.


But I totally get your point.


I know that this is something that others are using as well.


So we should definitely find a way to get that data back in.


I just don't have any ETA on that.


So I think what will probably happen


is we will try to get it updated, at least


in the documentation, so that it's clear that this data is


not available.


And then in the next step with the API,


where I know the teams are working


on improving some things there, that we'll get that back in.


I see, and so despite some of the sitemap index counts


seeming accurate and seeming like they're being updated,


it's the case that entirely for that sitemap API,


the index counts should be considered invalid entirely?


Yeah, yeah.


I would consider them invalid.


OK.


Yeah, sorry.


OK, no problem.


Thanks for the insight.


Sure.


We still have a bit of time left.


Well, actually, we don't have much time left.


But I have this room for a little bit longer.


So we can continue a little bit longer if you like.


If there are any other questions that are on your side,


feel free to jump on in.


Hey, John.


We run the e-commerce business.


So we have two listing pages.


One listing pages will consider all the brands.


The other listing pages is only a specific brand.


The specific brand page is considered as duplicate.


So how to eliminate that?


And I want it to be indexed.


If we consider them to be duplicate,


then that's probably because of the content on those pages.


If they're about the same brand, then I


could imagine that we might run into that situation.


So if you need to have them indexed individually,


then I would make sure that the content is really significantly


different.


If you don't need to have them indexed individually,


then I would pick one of those on your side


and use the rel canonical to tell us


which one of these versions that you want to have indexed.


OK, done.


Then one more question also.


Is there any necessity to specify the domain name


in the meta title and description


if there is no ranking advantage?


So is it necessary?


No, it's not necessary.


Some sites use the domain name as a brand name for the sites.


And putting that in a title is fine.


But there's no ranking advantage of using a domain name


in the title or description.


Then one more thing also.


Google reads the image or text.


So if suppose if I hover over an image and I display the text,


so is that Google reads it?


Yeah.


We do use the alt attribute for images.


We use it as a part of the page for the web page


and for better understanding the image itself.


OK, thanks.


Wow, 20 people in here.


Crazy.


I guess this is one advantage of the new setup.


More people can join in at the same time.


Any other questions from any of you?


Hey, John.


Yeah, so this is related to the domain diversity


update, which was released in, I think, June or July.


So it was not top stories part of this diversity update,


because what we see is most of the time,


the same news source is repeated two or three times


within the top story carousel.


I don't know for sure if top stories would be included


in that specifically, because a lot of times


when we have one boxes or carousel elements there,


then we see those as separate parts of the organic search


results page and not as the same thing as the normal listings


there.


So it's quite possible that top stories


has its own setup for determining


how the diversity should be set up across the pages


that we showed there.


Yeah, because it's not like other sources are not


covering that same topic.


They are covering it, but still, I mean, the same source


appears two or three times.


So that's why it's wrong.


I don't know how top stories would deal with that.


I do hear this from time to time.


So if you have any specific examples or screenshots


or something that you can post on Twitter and send my way,


that would be useful to pass on to the team.


It's sometimes a bit tricky with top stories,


because it's so specific to the location and the exact time


when you do that query.


So screenshots are really helpful for that.


Sure, we'll do that.


We'll do that.


Cool.


Thank you.


John, the same applies to PA also,


not a part of that domain diversity update.


People also ask.


I don't know.


Probably.


I don't know how those results are created.


But that's also essentially a separate block.


So generally speaking, they would


have their own kind of internal ranking within that block.


OK, let me double check the.


All right.


Yeah, please.


Let me double check the submitted questions


to see if anything new that we can add.


I think for the most part, we have things covered.


What else is on your mind?


I had one query in my mind.


OK.


So John, nowadays I am seeing that people have some escape


like if we want to ship to other domain,


let us just redirect it for one year and we will leave it.


In Webmaster Forum, I am also seeing a lot of people


discussing the same thing that we please tell me


for how long we should have this redirect 301


and then we will leave it.


How does Google really see if we have shifted this domain


to in the market or we have sold this domain


and now links are still pointing to x domain, which was earlier


redirecting to y domain?


How Google determines later on that, yeah,


this link equivalent to this link, y,


because six months back it was redirecting.


So now it is also the link value should be passed to this.


Unfortunately, if you reuse a domain for something else,


which could be either on your side


or it could be that someone else has bought that domain


and we discover links to that domain,


even if these are older links, then we


will count those links as applying to the new domain.


So it's not that we would say, well,


this is an old link that was there


when that redirect took place.


Therefore, we'll ignore that link


or pass it to the website that has moved on.


It's really the case if you remove those redirects


and we discover links to those old URLs,


then we will probably try to apply them


to the new website there.


So it's not something that you would get to keep


if you move to a new domain and you let the old one expire.


Because of that, that's something


where I really recommend, on the one hand,


going through and updating the links,


kind of how we have that listed in the Help Center,


and also trying to keep that old domain for as long as possible.


Even if you're not using redirects anymore,


just at least keep it within your own control


so that you don't run into a situation


that suddenly a competitor is taking your old domain


and using it to try to rank their content.


So if you're moving from one domain to another


and set up permanent redirects, I'd


try to keep them as permanent as possible.


And in any case, I'd try to keep the old domain name so that it


doesn't expire and end up being something completely unrelated.


SPEAKER 2


John, can I ask a quick question about image links


versus regular links?


Sure.


OK, because we want us to link to the other websites


that we have, but showing the logo,


so it's more user friendly and that people can see it


and not only have a text link to that domain name,


would it still be OK to have the link in the image?


What I think is useful there is either


that you have the text link as well,


or at least that you use the alt attribute for the image


to give us the anchor text that you want


associated with that link.


So that the alt text can be the full domain name?


OK.


But you will also have a text under it.


So it will be linking with the image and then the text under.


Yeah, that sounds good.


Yeah.


Perfect.


Thanks.


Hi, John.


Hi.


My question is, Google is solving queries on its own,


such as, what is the capital of UK?


It is possible that Google got to know about this


from such websites as Wikipedia and others.


If Google will keep answering these questions


without mentioning the website source,


it is possible that in the future, Google


is going to kill all the traffic to the webmasters who


is providing such information about the persons and places.


Is Google thinking about the criteria


of these kind of webmasters right now?


Sure.


Absolutely.


I think that's something that pretty much everyone


on the search team thinks about and tries


to take into account.


So trying to find the balance between giving people


information and making sure that the whole web ecosystem has


a reason to remain kind of a thriving ecosystem,


that's something that we definitely think about a lot.


I think there are some kind of queries


where it makes sense to show information directly


in the search results and maybe others where


it doesn't make that much sense.


So for example, if someone is looking


for the opening hours of a business,


then showing those opening hours doesn't


cause any problems for that website in the sense


that users aren't going to the website


and clicking on that page anymore


to find the opening hours.


But they find the opening hours, and they use these opening


hours to go and visit the business in person.


So for the business itself, clicks to that page


are not really the critical aspect there,


but rather kind of being visible in search and being findable


and having their information available for users


at the right time so that they can then


make it have it a little bit easier to actually convert


with that business and become actual customers there.


And that's one aspect there.


The other aspect is, of course, if you


have content that is very limited in the sense


that you ask, what is the capital of India,


and the answer is one word, then if your whole web page is


essentially just to answer that question, then of course


that will be trickier.


Because on the one hand, there's a lot more competition


for those kind of pages out there now.


And on the other hand, a lot of this information


is general information that we can just show in search.


So if the whole reason for being of your website


is to answer kind of these one word questions,


then I do imagine that's something


that you'll have to figure out on your side,


kind of migrating the change in how search works,


how the web works overall.


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


is normal, is a normal part of the web in the sense


that things evolve over time.


The user need evolve over time.


The expectations change over time.


And therefore, websites themselves


also need to find ways to stay with the times


and find ways to be unique and compelling so that users


want to go to your web page and don't just


want a one word answer.


Actually, in recent article of Ryan Fishkin,


he's saying that Google is providing


answering the queries 48% without mentioning the source.


Isn't it alarming to the webmasters?


I did not read that article, though.


It's really hard for me to comment on that.


OK.


Thank you.


John, do you have a number of, or do you


know a rough percentage of what queries


you answer on the page rather than not?


I don't know.


I don't think we have a public number.


I think it's also tricky to say because some things are


answered directly in a snippet on a page.


And it's kind of hard to say that this is something


that Google is doing differently versus maybe the answer is just


in the meta description of the page.


All right.


I just wonder, because I suspect it's not a big issue.


People just notice it.


I imagine it's a small issue.


Yeah, I imagine it's something that changes over time as well,


depending on how people search, what kind of questions


people use to search.


It's one of those things where I think


user needs and user expectations change quite a bit over time.


I think business expectations have changed as well.


I think people now think you can monetize


what's the capital of India, where 20 years ago, you


look at it in a book or you ask someone else.


There's no money to be made from that query.


So people have got lucky for 20 years


and maybe have made some money out of it, but things change.


You can't make money out of everything.


That's probably the case too.


I mean, like capital of India, I could imagine


that for a long time you could make kind of ads,


major ads landing pages that worked really well


in search for that.


And like you said, for a while you


could probably make a decent living just answering


these basic questions.


But things change.


And especially when it comes to, I think, bigger websites,


that's something that has changed significantly


as well, where in the beginning you


could make a landing page on specific book


topics or specific things just because there


is no kind of general source of information on the web.


And you could rank for those and perform really well.


And nowadays there are lots of different sites


that are trying to compete for all of these queries.


Yeah.


I think Axel, you're raising your hand.


Go for it.


This is Axel from Germany.


I'm managing a really old site where


we have special charts in the URL.


So like some editors created URLs with copyright names


and French accents, like Avan or LXG.


And I noticed that the GSC, the check URL tool,


is not accepting the URL at the moment


because it says it's long encoded.


Could you investigate on that?


Do you have some example URLs that maybe you


can copy into the chat?


I'll give you one in a minute.


So we have here one URL where the editor or the person


basically putting the product in the this one


is it's a German site.


And there's a product.


And there's a percentage AE, which is the copyright sign.


This one I would say is not so legit.


But there's another one where the brand name


is called French Avan.


There's also a famous toothpaste in Germany called


LXG, which has an E. And so the content editor just


types in the name of the brand.


And the CMS is converting the URL.


And if you paste that into check URL, it's not.


OK.


Yeah.


Trying those in the browser also doesn't show the character.


But it should at least load.


So I'll double check with the team on that.


In general, what we recommend for kind of non-standard,


I mean, these are standard characters, but kind


of the non-ASCII characters.


The kind of special characters is


that you use Unicode if you include them in a URL.


That way we can always pick that up.


But we should, I mean, if you can load this page


in a browser, we should be able to test it with the testing


tools as well.


So that seems like a bug on our side.


The tool says at the moment URL is not in the correct format.


And we are trying to switch our system from user


alerting 1 to YouTube page.


So it's going to be probably solved.


If you could pass it to the devs.


Yeah, I'll definitely pass that on.


Thanks.


Cool.


Any last questions before we close out for the week?


Everything good.


OK.


That's good.


I think the indexing issue that we had yesterday


should be mostly resolved now as well.


So maybe we can go into the weekend


with a little bit less stress.


I hope the week has been good for you all.


And I wish you all a great weekend.


Thanks, everyone.


And see you next time.


Bye.


Webspam manual actions and reconsideration requests #AskGoogleWebmasters

Today, Alma is asking about her website that was flagged as spam and is unsure how to fix


it.


Well, if you're uncertain about a web spam manual action on your website, I strongly


recommend going to our Webmaster Help forums to get input from peers.


In the forums, you'll find folks who have seen lots and lots of sites with issues that


resulted in web spam manual actions, and you'll get input on things that you can either improve


or fix on your website.


When you go there, make sure to include all of the information you have about your website.


Explain the original issue and what you've done since then to clean up.


I recommend not trying to hide anything about your website.


Everyone makes mistakes at some point.


That's fine.


The important part is that it's a lot easier for folks to help if you're honest about what


has happened so far.


Sometimes, the input you'll get isn't easy to take in, especially if you've spent a lot


of time just focusing on that one website.


But regardless, I find it's always useful to get external opinions from folks who have


seen a lot of different websites.


Once you've made significant changes to clean things up, go ahead and file a reconsideration


request.


Detail the changes that you've made, perhaps even link to the forum thread for more context.


These reconsideration requests are reviewed by the web spam team manually.


So, be clear about what you submit without overloading it with unnecessary details.


I hope this helps.


Do I need a robots meta tag? #AskGooglebot

On Twitter, a user from Turkey asks whether or not having a robots.meta tag is bad for ranking.


Well, thanks for asking. We talk about some of these SEO elements so often that it's easy


to assume that they're required. In this case, no. A robots.meta tag is not required for ranking.


The robots.meta tag can specify how a specific page should be shown in search


or if it shouldn't be shown at all. This meta tag is only necessary if you want to change the


default appearance of a page in the search results. For example, if you want to limit


how long the snippet can be, then you can use the maxSnippets robots.meta tag.


If you don't have any preferences regarding how a page is to be shown in search,


then not having a robots.meta tag on a page at all is also perfectly fine. If you're curious