Are there other reasons for the fluctuation in this instance?


English Google Webmaster Central office-hours from September 4, 2020

Those are good questions.


But it's kind of tricky because for us,


a featured snippet is just a different way


of showing a search result. So it's not something


that we would pull out and say it's


something completely different.


So it's something that can appear sometimes.


And sometimes it might not appear.


For some sites, they see a lot of fluctuations


there in the visibility of them.


And for others, it's fairly stable.


From our point of view, we don't have any explicit guidelines


on what you need to do to have content that works well


in featured snippets.


There are externally some people who


have written about ways that you can write your content that


works well with featured snippets.


I would definitely check some of that out.


But from our point of view, it's not


that there's a technical thing that you


have to do to make featured snippets work


or that you have to have one question and an answer,


and then you will get that in a featured snippet.


A lot of these things are things that our algorithms try


to figure out automatically.


And externally, people have written


about what they've discovered works well


or doesn't work well.


So I would take a look at some of those external blog posts


and presentations that people have done.


And I guess the other thing is in Search Console,


you can't really track those featured snippets.


So it's not something that we would pull out separately


because from our point of view, we


think they're kind of a normal search result.


What you'd probably see is that the position


of the page for individual queries


goes up and down there, where when


it's in the featured snippet, it'll be at position one.


And when it's not in a featured snippet,


maybe it'll be further down in the search results page.


So that's kind of anecdotally what you might see.


All right, thank you.


Sure.


OK, let me see what other questions we have submitted.


And we'll definitely have more time for more questions


along the way.


I'd like to know, what are the basics to avoid indexing URLs


from pre-production or development environment


and not have duplicate content issues?


I know you're not the only one with this problem.


I think pretty much everyone who has kind of a staging


environment has run into this issue as well.


So basically, the best approach to preventing


any of your staging URLs from being indexed in Google


is to put them behind some kind of a server side block, which


could be server side authentication,


that you have to enter a password, username,


or something to get to those pages.


It could be by IP address if you have a specific IP


range of your developers, your quality teams,


those kind of things.


That's essentially the best way to really kind of prevent


that content from being indexed.


There are two other approaches that people sometimes take.


One is to use robots.txt to block crawling of those URLs.


In general, that's OK, too.


For the most part, we wouldn't index those URLs


if there are no links to those pages.


However, what a very common mistake is that happens there


is that people sometimes push the fully blocking robots.txt


file to production as well.


And then suddenly, your production server


is also blocked.


So that's kind of one of those areas where


it is very easy to make mistakes.


The other approach is sometimes to use a no index meta


tag on these pages.


And that also prevents those pages


from being indexed, which is kind of what you're looking for.


But again, you also have the same problem


that it's easy to take those no index pages


and push those to production.


So by using something like server side authentication,


which generally is not a part of kind of the full set


that you push to production, by doing that,


you can kind of sidestep that.


You can push something to production.


And you can be really sure that if you can access your


production pages without a password,


then that it's actually working well.


So that's kind of the recommendations I'd have there.


SPEAKER 2 How does, just as an aside,


if those pages aren't linked from anywhere,


surely then it's fine.


You shouldn't get them.


You're not the deep state.


How do you get to the pages if they're not


linked from anywhere?


If they're really not linked from anywhere,


that's perfectly fine.


But people leave traces and links


in all kinds of weird places.


So one of the weird places where we sometimes


see our internal links pop up are all of these browser


plugins that tell you which site is popular,


which kind of users.


And then suddenly your domain is listed there


as this is one of the, I don't know, least popular websites.


Because of course, only the developers are visiting it.


But it's listed somewhere.


And then suddenly there's a link.


And it's these kind of vague traces


that are around the web, which search engines sometimes just


stumble across and like, oh, look, a new website.


I will do my best.


All right, so does it usually happen


with people using off-the-shelf CMS stuff then,


if it's plugins or things that you install


that you forget about?


Yeah, I don't know so much about plugins and CMSs.


But definitely from a browser side,


that's something that we see a lot, all of those kind


of popularity sites that track what the top websites are


in the UK or top websites in different regions.


And then it's easy to get somewhere


on the bottom of the list there.


And then it's there.


Another thing we sometimes see is when people send URLs


by email to other people.


And the other people end up being public mailing lists.


And then suddenly some public mailing list


has kind of this URL that you don't actually


want to have indexed.


And if it's a matter of just having the host name,


then that's something that feels like it can just


happen at some point.


And you're saying Google reads email.


Is that what you're saying?


If they're on public mailing lists.


Let's see.


I have the next mistake, a page in my web


hasn't got a main entity.


And I don't know what to do.


In fact, it's an old page, which I've tried to delete.


But I don't get it.


What can I do?


So deleting a page is perfectly fine.


So that's something where essentially if you


want to delete it and you can work out


how to delete it in your CMS, if you're


using something like Blogger or WordPress or whatever,


then deleting it should be possible.


In general, the main entity sounds


like it's missing some kind of structured data on your page.


And from our point of view, structured data


is not a requirement for a page, for search.


So if there's one page on your site that just doesn't


have structured data on it or doesn't


have that type of structured data on it,


then I wouldn't necessarily worry about that.


Does adding year to a post title help in rankings?


For example, how to start a website


or how to start a website in 2020?


From our point of view, it doesn't help in ranking.


It's not that we have any algorithms that


look for the current year and say,


oh, this is a recent article.


We should show it higher in the search results.


Sometimes users look at that.


I sometimes find that a bit misleading


because you see websites essentially update


all of their year numbers at the end of the year.


And then suddenly it's like, what is the best cassette


recorder from 2021?


And then actually there are no cassette recorders from 2021,


but the website is updating their content like that,


which feels a bit misleading to me.


So I don't think our algorithms would penalize that.


They definitely wouldn't favor that either, though.


Why are news websites getting down day by day?


Is there any update going on?


As far as I know, news websites are not going down day by day.


It almost seems like news websites are always


in the foreground when you look around because there's always


some crazy news happening that pushes their content to be


more and more relevant.


So there is definitely no kind of anti-news website update


or algorithm happening at the moment.


Big publications artificially freshen their stories


by messing with the timestamp on a very regular basis.


In the search results and news, will you


ever take action on such sites or only


keep affecting small websites with algorithm updates?


We do see this from time to time.


And sometimes it does happen that this has a positive effect


on a website, and that is something


that we escalate to the team so that they


can take a look at that.


On the other hand, we also have fairly robust systems


to recognize the more actual date on an article.


So if we can find an article on the web


and we can recognize when this was really published,


and then even if they change the timestamp on their pages,


it's not something that will skew our systems.


It does feel like this is a bit kind of cat and mouse thing


where we improve our systems and then they find new sneaky ways


to kind of get around this.


But in general, I think we're kind of reasonably OK there.


If you find situations where we're not catching on to this,


feel free to let me know.


Send me some examples on Twitter,


ideally screenshots where it's easy for us


to confirm that something like this


is happening because with a lot of these news things,


if you just send us the URLs and we take a look a day later


or we pass that on to the team, they take a look a day later,


then it might look completely different by then.


So with clear screenshots of examples


where something is going wrong, that's really helpful.


I'd like to know what would be the best technical approach,


follow versus nofollow, index with noindex,


canonical in the following case.


We have two domains, A and B. Domain A


is linking from the landing page to domain B's landing page,


passing a parameter with the URL.


Based on the parameters, landing page at domain B


is personalized with a different h2 heading, copy, et cetera.


There's also a default version of the landing page


at domain B available at the URL without parameters.


So ultimately, this is up to you.


It's whatever you would like to achieve there.


It sounds like the home page of domain B without parameters


is kind of one home page, and the home page of domain B


with parameters or with those specific parameters


is a different version.


And from our point of view, you can do that.


And you can have two different pages indexed.


It doesn't matter so much that it's the home page


with parameters or without parameters,


but essentially, these are two different URLs


from our point of view.


So if these are two different URLs,


then you can kind of decide on your side,


do you want them indexed individually,


or do you just want one of them indexed?


If you just want one indexed, then using the rel canonical


to the version that you prefer to have indexed,


that's essentially the right way to do it.


But you can also decide to say, well, both of these


are OK to have indexed.


I don't mind if they're both indexed.


It's essentially up to you.


Let's see, I think we still have a bit of time,


so I'll run through some more of the submitted questions,


and we can get through some of the things from you


all live as well.


If my site is in Search Console verified a long time ago


with the www protocol in front, after a site redesign,


I've removed the www.


Do you think this is a problem?


Should I add another property in Search Console without it,


or should I redirect all my assets and pages


to the www version?


Just wondering if this is a big issue from an SEO perspective.


So on the one hand, it's not a big issue


to switch from one version to the other,


but you need to make sure that you have redirects in place.


So if you were previously at www, your site, whatever,


and now it's at the same version without the www,


you need to make sure that they're


redirect from the old version to the new one.


That's kind of the basic thing that you need to watch out for.


If you don't do that, we will assume that the old version is


kind of broken, and we will kind of


let that disappear from search.


While we recognize your new version and think,


oh, this is a new website, we will kind of slowly


integrate that into search.


So to prevent us from kind of losing all of the value


that you've built up, make sure that you set up those redirects.


That's kind of the basic thing there.


With regards to Search Console, it


is such that there are two ways that you can verify sites.


One is on a domain level, and one


is on the prefix and protocol level,


where you would have to specify the www and not.


So if you have it currently on the prefix version verified


and you switch to a different prefix,


you need to also verify that new prefix in Search Console.


Usually, this is pretty straightforward.


A nice way around that kind of for the future


as well is to switch to domain verification.


Then you don't have to worry about that.


Search Console is not a requirement for search.


So if you forget to do the verification in Search Console,


your site will still work.


It's not that something will break.


Also, if you switch to a different Search Console


verification, it's not that your data will disappear


and you have to start over again.


Search Console will recalculate the older data


and show that to you there as well.


So that's something.


On the one hand, watch out for the redirects


that you have those set up properly.


And then I'd just recommend making sure


that you see your data in Search Console


with whatever version works for your site.


If we have a 404 page to date and after a few days


we make it a 200 again and submit it in a site map


again and internally link to them again in the site


as well, how will Google treat these?


Will this create a negative ranking impact


when Google re-indexes these pages?


Will Google report these URLs and submit it not 404?


What bad things can happen if we start using 404 in place


of no index?


So from the early questions there, if you have a 404 page


and you make it 200 and there's content there,


then when we reprocess that page,


we will take that into account.


There is no penalty at all for that page


being a 404 in the past.


We just have a new page that we can index,


and we'll try to index it the best we can.


So on that point of view, it's not


that there is any downside to doing this.


The one thing to kind of keep in mind here,


though, is that if a page has been 404 for a longer time,


then we tend not to crawl it as frequently.


Because we think it's like we don't want to bother you


with all of these requests for pages


that you have always been telling us don't exist,


then we probably won't check that page every day or so.


It might be that we would check it maybe every other month


or something like that.


So if you have a page that you turn from a 404 to a 200,


it can happen that it takes a bit of time for that


to kind of get picked up again.


So that's kind of one thing to watch out for there.


And in particular, if you're changing a page from 404


to 200 and then back to 404 again and back to 200,


back and forth a lot, then that's


something where if we get into the state of, oh, this


is a 404, we don't have to crawl it that often,


then it can happen that we miss some of these fluctuations


back and forth.


So I would try to avoid the situation where you're


going back and forth a lot.


If you're doing this once, then that's less of an issue.


The last question, I think, is what bad things


can happen if we start using 404 in place of noindex?


I don't see anything bad really happening there.


Essentially, if you're telling us


that these pages should not be shown in search,


if they don't exist, then both of those options work.


404 or noindex.


My suspicion is that maybe a noindex


would be a little bit faster visible,


but I think if you're looking at it from a bigger picture


point of view, you probably wouldn't


notice any difference there.


So from that point of view, if you kind of


have a choice between 404 and noindex,


I would just pick whatever works best for you.


Can duplicate pages due to uppercase URLs


cause site performance downfall?


Does keyword cannibalization exist?


Those are kind of completely different things.


On the one hand, the duplicate pages with uppercase URLs,


we do treat URLs as being case sensitive.


So if you have URLs that have some uppercase characters


in them or URLs that have lowercase characters in them,


then we would treat those as being unique URLs.


And we would try to crawl and index those individually.


We would probably fairly quickly recognize if they're the same.


If your server treats them as the same thing,


we would see exactly the same content.


And we would fairly quickly realize, oh, we


can just focus on one of these.


So essentially, what you're doing


is creating duplicate content in a technical way.


I kind of call this technical duplicate content


because it's not that you're duplicating content


with the hope of kind of doing something sneaky.


It's more that, well, your server is technically


creating multiple URLs for the same pieces of content.


Usually, we can work around that fairly well.


So especially if you're a smaller site


and you have this kind of duplicate content,


then we can work around that.


That's less of an issue.


If it's a very large website where


we struggle with crawling even with one version


of the content and you suddenly have multiple versions


with upper lowercase URLs in there,


then that's a bit of a different question.


So that's something where I would really


focus on cleaning up those URLs, making sure


that you're linking to a consistent version,


that you use the rel canonical to your consistent version,


and really make it so that we can crawl


your website with the preferred URLs as efficiently as


possible.


So it feels like that's something


that a lot of sites tend not to worry about so much anymore.


In the past, it felt like a bigger problem,


especially when you were making your own websites.


When you're coding your own HTML,


then it's very easy to kind of code those links yourself.


And then some files are uppercase, lowercase,


those kind of things.


But if you're using a common CMS like WordPress


or any of the other common CMSs, then usually that's


something that's taking care of you.


You link to a specific page, and that link automatically


has the right upper lowercase version.


Does keyword cannibalization exist?


So keyword cannibalization, people


usually call it that when you have


multiple pages on your website that


are targeting the same keywords, essentially


when you're making life harder for yourself


than it needs to be.


And from that point of view, you could say it exists.


I feel that the name makes it sound scarier than it really


is.


There's nothing mystical around it.


It's essentially just you going to people and saying, well,


you're searching for this really important term on my website,


but it's like, here are five options instead of here's one


really strong option that I can give you.


So it comes across to me more as kind of a marketing question


of how do you present your website,


and do you prefer to have one really strong option that you


show to people, or do you have kind of a diluted version


across multiple variations of the same thing on your website?


Sometimes it makes sense to have multiple variations,


especially if you know that people are searching


for something with a generic term


and they're not quite sure what they actually mean.


Sometimes it makes sense to really have


one very strong version, where you really


have something that can rank really well,


because it's like you focus all of your energy into it.


You present that within your site


as the primary approach there.


So those are kind of the things that I


would watch out for there.


And let me just take one more question,


and then we can switch to more questions from you all.


My WordPress blog has date published and date modified


properties.


If I'm using date modified, why is my blog post


that I published in 2016 but have spent extensive hours


updating in 2020 still showing the date of 2016 in search


results?


It's misleading to potential visitors,


and I believe I'm losing clicks because of this.


I also don't understand the logic behind the behavior.


So I hadn't had a chance to take a look at the exact URL here.


But when it comes to dates, we look


at multiple things on a page.


I think we have a Help Center article on dates as well.


One important thing is that we can


confirm the date on the visible part of the text as well.


So just updating the metadata in the structured data,


if that's something that you're updating,


isn't going to kind of sway our algorithms


and understand that actually this is the right date to show.


But we really need to have that confirmed individual part


of the page.


So if at all possible, make sure that that's


something that you can confirm in a way that


is easy to understand.


And by easy to understand, I mean


really listing the date on the page


and not something as like updated early 2020 kind


of thing.


It should really have the same date


so that when our algorithms look at the page,


usually what happens with regards to dates


is we try to extract all the dates that we


can find on the page in the visible part


in the structured data.


And then we try to judge which of these dates


have support within the article, like which of these dates


are mentioned multiple times, which of these dates


seem to be relevant for the article,


and then we try to narrow things down on those dates.


So making it as easy as possible for us


to confirm that a date is the right one


is kind of what we should be looking for.


OK.


Wow, still a bunch of things left,


but let's switch over to questions from you


all just for a second.


I have a question on Google News, if that's OK?


I don't know everything around Google News,


but I'm happy to try.


Sure.


So there have been several complaints on the Publisher


Center forum as well as Twitter about the sites that


have got into the Google News after December 2019.


Haven't really been showing up on the News tab


if you search for them.


And that includes larger publications


like CNN Brazil, India TV.


And there are several websites like that.


And none of them really show up without adding that site


operator in the search keyword.


If you look at the older websites, which


got into the news before December 2019,


they does show up on the search without any site operator


keyword.


So what is exactly the difference


between that publisher old one and new one?


And why is it that we have to search with the site operator


on only those new websites?


Because ideally, they should show up


even if you search with the site name,


because it's been almost like 10, 11 months


since December 2019.


So there have been so many complaints on the Publisher


Center about this.


And we haven't really seen satisfactory answers out there.


So we just wanted to clarify if this is something


that publishers can be helped with.


Yeah.


So again, I'm not on the Google News team,


but I have seen a lot of these complaints as well.


And I spent a bit of time also chatting


with Danny Sullivan about this to try to understand


this a little bit more.


My understanding is that this is something


that we're working on.


So it's not by design that there is this one cutoff


date, but rather that things are being processed just


a little bit slower than they used to.


And the other aspect there, the site query,


is, from my understanding, is that even


if you're in the News tab and you do a site


query for something that's not in Google News directly,


then it'll default and show the data from Google Search.


So that's kind of, it feels like, oh, it should be there,


but it's not being shown for normal queries.


But actually, what you're seeing is kind


of the normal search indexing and not what would actually


be shown in search.


So I hope we can kind of clean that up a little bit.


I don't know what the time frame is there.


And I don't know exactly what all will change there.


But it does feel like something where


things have been going a lot slower than they should be.


Yeah, there is a bigger problem, actually, because of that.


So many publishers, they're switching the domains


which were in Google News before December 2019.


And then they're kind of exploiting this thing


to show up all those copied articles, scrapping links,


and all that.


They're appearing very easily because they got approved


before that time frame.


So they just show up without any effort at all.


Basically, there were a couple of examples


given by the product expert in the publisher center thread


also saying there are a couple of websites which


are really virus links.


So they're coming up on news.


And it is kind of sad that the original publishers


have to suffer because of this.


It would be good if you can take a look at that.


Yeah, I mean, I'm not on the Google News team.


So I just poke at them and tell them


they should do some more there.


But one thing also to keep in mind


is that there is abuse everywhere in search.


And it's something where if you explicitly


look for some kinds of abuse, you will find it.


So it's, I don't know, it feels kind of weird to say that,


like, we should be showing in Google Search.


And look, I also found some abuse from existing publishers


because then it almost distracts kind of the effort that


could be put into your case to kind of improve things


on your side by telling them, oh, actually you


should be cleaning things up first.


So that's, I don't know, just from my personal point of view.


But we are definitely pushing a little bit on the news folks


to see if we can speed all of this up again.


Thank you, John.


Is that I am here?


Sorry, can I jump in?


Sure, go for it.


Hi, John.


This is Brittany.


I posted the first question that you


read about the domain migration gone very, very wrong.


And I have a team of 35, depending on me


and depending on this website's traffic.


So it's been just such a tough time for us.


I have a few theories of what might have gone wrong.


I was hoping to run at least one by you.


But I know this is a very specific scenario.


So if you'd prefer me, you prefer


to just follow up with me after, that's fine too.


I can jump in with one of them, sort


of taking your lead on what's best in this forum.


So usually what I do on Fridays is also just


have a bit of time afterwards where people can ask questions


kind of off the record, which makes it a little bit easier


to look into some specifics as well.


So if you want to hang around a little bit,


we can take a look at that then.


Would that work?


I will do anything to get any next steps on the situation.


So yes, thank you.


Cool.


Yes.


Am I clearly hearable?


Sir, I am asking that some websites which


do not have any content just putting three or two keywords


and are ranking in top stories, where as new publishers,


we produce high quality content but still not


able to get on the first page.


But they are ranking with just three keywords.


I have a video proof also and posted in the Google News


forum.


They are saying that it is computer algorithm


and we can do anything.


And putting a quote of yours.


What I would recommend doing there


is using a spam report form if you


think that this is really bad content


or using the feedback form to let us know


when you see bad results.


But still, the big news publisher sites


like CNN Brazil and India TV not able to get in the Google News


but don't say on that.


I think we talked about that previously.


So I don't really have any updates there.


All right.


Yeah.


I mean, one thing that I'd also just like to point out


is that a lot of the sites that I looked


at that were escalated in those threads


are things where I am kind of, I don't know,


a little bit reluctant to say that we were not


going to treat these as news sites.


I'm not on the news publisher team,


but there's a lot of, I don't know, weird things there.


So that's another thing to keep in mind,


that just because things are submitted in the publisher


center doesn't necessarily mean that we would show them


in Google News.


But like I mentioned before, we are definitely


going to poke the Google News team a little bit more


to see if we can speed some things up there.


OK.


Thank you, Seth.


Hi, John.


Hi.


I want to ask you some question about the AMP page.


This early day, my AMP page, it doesn't show up on HTTP.


I don't know what happened and if you


have any clue about this.


Because on the technical side, the AMP page


and the HTML, and we have checked into the search console,


the result is, they give the result,


is find the AMP page.


But when I search on the Google mobile, it doesn't show up.


Why this happen if you include?


So you have a setup with a connected AMP page.


With a connected AMP page, just to confirm?


So one HTML page, or like, I don't know,


are you afraid of it, legacy HTML page and the AMP version


of that page?


Is that correct?


Yeah.


We have to do it.


OK.


And you're looking in the mobile search results


and just looking at the normal search results there,


not any specific feature or ranking question.


It's really just, it's showing the HTML version and not


the AMP version.


Yeah, I think my other question is, because of the AMP page,


it doesn't show up on Google search.


I think rank also drop.


I don't know.


I mean, usually, the switch between the normal HTML version


and the AMP version is something that would happen


without any ranking change.


It's just we would show one version or the other version.


So that wouldn't affect the visibility of the page at all.


It's really just which of the URLs is being shown.


One thing you could do is make sure that in Search Console,


you also can track those versions, depending


on how you have AMP set up.


If it's a subdomain or a subdirectory,


then make sure that you can also get that data in Search Console


to see if there's anything specific that's flagged there.


Also, in Search Console, there is the AMP report


that can give you a little bit of information on issues


with AMP pages that we find, which


would result in us not showing the AMP page, but rather


the normal HTML version.


But again, all of this wouldn't change the ranking of the page.


It's really just which version is being shown.


I see.


OK, then.


So I think if you're seeing a change in ranking as well,


then that wouldn't be related to the AMP version or not.


That would be more of a general ranking version


or not?


Sorry.


In our Google Analytics, I have seen the slightly drop


on the AMP traffic.


So I think that also, because that doesn't show up


on the search, on the Google search,


I think also the rank is dropping.


OK, then that sounds more like a general ranking question.


Then I wouldn't worry so much about the AMP page.


I would think about what you could


do to improve the ranking of your pages overall.


Still confused.


I don't know.


I have checked on the AMP page validator


on the Google Console.


They checked the AMP page is valid, by the way.


I'm still confused about it.


OK, thanks for the answer.


Sure.


OK.


So I get one thing.


Is it possible for you to organize


my meet like this for the news team as well?


Just a request from our side, because there


are a lot of open questions for these news publisher guys.


So at least buy me something like that,


like what you are doing here?


I am a request from me.


Yeah, request from me.


We have some people who are interested in news hangouts.


I don't know.


I'll ask.


Yeah.


OK, thank you, John.


You're the best.


Cool.


Let's take a break here.


I'll pause the recording.


If any of you want to hang around


afterwards to ask more questions or chat more,


you're welcome to do that.


In the meantime, anyone who's watching the recording,


thank you for watching along.


I hope you found this useful with some


of the questions going back and forth.


I thought lots of good stuff happening.


I wish you all a great weekend in the meantime,


and hope to see you all again in one of the future hangouts.


Bye, everyone.


Take care.


Bye.


How to get your products into Search | Search Central Lightning Talks

Do you want to increase traffic from Google to products on your e-commerce site?


For free?


My name is Alan Kent, and I'm a Google Developer Advocate specializing in e-commerce.


In this Google Search Central Lightning Talk, I'm going to describe the benefits of providing


Google with timely and accurate product data, as well as technical best practices to achieve it.


Let's dive in.


First, let's look at the main ways we show your product data.


Google Search uses special formatting for products in search results to assist shoppers


on their purchasing decisions. This can include ratings, reviews, pricing, and stock levels.


Google Images also uses product information when available.


If Google knows how to display an image for a product, it may display additional badging


and product information with the image, such as whether the item is currently in stock.


If you visit the Google Shopping tab, products are listed with richer information.


The Google Shopping tab provides additional tools to help shoppers on their shopping journey,


such as filtering by price range or brand.


Finally, Google Maps can also show products available nearby if you provide Google information


about where your inventory is located. This helps shoppers wanting to pick up purchases in person.


While these are the most well-known surfaces for a product to show up on Google,


there are others, and we're always exploring new opportunities.


Product data is not new to Google, although its usage has evolved over the years.


Let's take a quick look back down memory lane to understand the evolution of products on Google.


Google Search was first launched back in 1998. Originally, Googlebot would crawl the web,


looking for pages, making the content available via Google Search. By 2002, Google was already


identifying products on web pages. To improve accuracy of the data captured, you could also


provide a product data feed directly to Google for indexing. Moving forward to 2010, Google's


offerings were more sophisticated. Structured data allowed website owners to more accurately


convey product data to Google from inside web pages. Google Mention Center was launched to


capture product data, which was then fed into multiple paid experiences, such as product listing


ads in Google Search, display ads in the Google Display Network, and the Google Shopping tab.


Typically, you'd only share product data for products you wanted to promote on Google


Surfaces. This changed in 2020 with the introduction of several free offerings.


First, Google now makes it free to participate in the Google Shopping tab. There are still paid


experiences, but your products can be listed for free, increasing your product's exposure to shoppers.


In addition, product data from Google Merchant Center is also fed into organic search.


This helps Google present your products more accurately to shoppers in organic search.


This means it now makes sense for you to provide all of your product data to Google


rather than just a selected subset. Google Search extracts a lot of your product data


directly from web pages. So why is product data different? The reason is product data needs to be


accurate and extracting information from web pages can be less reliable. For example, how does Google


understand which is the product's price when both the original and the discounted price are shown?


How does Google find the right product if the page also shows related products?


And how does Google understand whether additional costs such as taxes and shippings


are included in the price? Special treatments by Google are only available if Google is confident


it has correctly obtained this additional information. Also, while some product fields


are optional, others are required by Google before we'll accept a product description.


Using structured data is one way to make sure Google correctly understands


all product details you are providing on a web page. There are several ways to encode


structured data in a page, but a common way is to embed it as JSON-LD encoded content.


More information on structured data can be found in the Google Search Central documentation.


I added a link to the description below. So how to get your product data into Google


Merchant Center? There are three approaches to choose between, suitable in different scenarios.


By crawling your website, by periodically providing a feed of all your products,


or by using an API to update products individually. Let's look at these approaches in more detail.


The first way is to configure Google Merchant Center to extract product data from pages


crawled from your website. Using structured data on your pages can significantly increase


the accuracy of the collected product data. In order to participate in the Google Shopping tab,


you must also click through the appropriate approvals in Google Merchant Center.


Google Merchant Center also supports supplemental feeds that can add


additional fields to the data from the primary field. For example,


pricing, sales notifications, and stock level data can be provided by one or more supplemental


feeds. So this data can be updated more frequently without waiting for the next crawl of your pages.


The primary and the supplemental feed is combined by Google Merchant Center to form the final view


of your product data. Supplemental feeds can be provided via a Google Sheet for small


data volumes, on-demand uploads, or via scheduled fetches. Data can be provided in a tab-separated


text file or marked up in XML. The second strategy to provide your product data to Google


Merchant Center is via a primary feed. A primary feed supports the same approaches as supplemental


feeds. For example, you may dump your whole product data into your Google Merchant Center


catalog to a file once a night, then make that file available to Google to load.


It is worth noting that Google may compare your feed data to the original page to verify data


consistency. Detected inconsistencies can result in products being excluded from Google, so it's


important to keep your feeds in sync with the product data on your site as best as you are able.


There are times, however, that your website content is updated more frequently than Google


Merchant Center, particularly for product availability and pricing data. To support


these two common sources of inconsistency, you can enable automatic item updates to update


availability and price data in Google Merchant Center rather than flagging as an inconsistency.


The third and final way in which you can provide data to Google Merchant Center is via the Content


API. Using the API, you can insert, update, and delete selected products instead of supplying


complete replacement set of data for all products, as is done in the previous two methods.


The Content API can apply changes to specific products individually,


or in small batches for efficiency. This means your platform is responsible to work out which


product changes you need to provide to Google, but the results can be live in minutes rather


than waiting for the next full processing run. It is worth noting that organic search results


may take additional time to update after the new product data is updated.


It is worth noting that organic search results may take additional time to update after the new


product data is in Google Merchant Center. So, to wrap up, there are three ways you can provide


detailed product data to Google. First, via web crawling product data from your site,


preferably using structured data embedded in product pages. This can be easy to implement,


but you don't have as much control over how often your data is updated unless you use a supplemental


feed. Second, via feeds that you upload periodically, say one or more times a day.


Or third, via the Content API, where you can update specific products on demand.


With the Content API, your updates can go live in minutes.


What actions should you consider taking next?


Add structured data to your web pages to increase the accuracy of extracting data.


Decide on your strategy to get product data into Google, such as via website crawls, Google Sheets,


scheduled fetches, uploads, or API calls. And remember that SEO still matters for organic


search. Make your product details, such as images and descriptions, appealing to your customers.


If you're curious about tracking how your products appear in search,


be sure to check out our video on Search Console for e-commerce sites.


Blogger for site ownership verification - Google Search Console Training

In this video, I'll go through the steps you need to follow


to verify your blog in Search Console if you publish it through Blogger.


In order to verify your website with Blogger,


you must be logged into Search Console


with the same account you used to manage your blog.


After you click Add property,


add your website URL under the URL graphics option


and click Continue.


That's it.


Your blog should be verified automatically after this step.


Thanks for watching,


and check the Google Webmasters YouTube channel


for more videos on Search Console.


Google Webmasters


Getting started with Web Stories | Search Central Lightning Talks

Hello, welcome to another Lightning Talk


from the Search Central Lightning Talk series.


I am Pascal Bertschler,


Developer Relations Engineer at Google.


And today, I'm going to tell you all about Web Stories,


a new and modern way for immersive storytelling on the open web.


In this talk, I will explain what Web Stories are,


how to create stories,


and how you as an online marketer, blogger, or site owner


can make the most out of them.


Let's dive right in.


Web Stories are a web-based version of the popular Stories format


you might be already familiar with from certain social apps.


They blend video, images, animation, and text


to create fully immersive full-screen experiences,


typically consumed in portrait mode on your smartphone.


Stories let you explore content at your own pace by tapping through them


or swiping from one piece of content to the next.


Contrary to their social counterparts,


Web Stories allow you to create beautiful and engaging content


while having full control over the experience and monetization.


You heard right.


Every decision from how you monetize your story


to how long it stays online is up to you.


This freedom gives you great creative flexibility


and the possibility to easily link out to your other content as well,


making Stories a natural part of your website.


How is that possible?


Well, Web Stories are part of the open web


and essentially regular HTML pages under the hood.


That means they can be hosted on your own server


and easily shared or embedded across sites and apps


without any ecosystem restrictions.


So, how does one go about creating Web Stories?


There are a few ways, depending on your needs and expertise.


First, since they are just web pages, you could build them by hand.


That's especially useful when wanting to create Stories


with highly custom functionality.


However, like for regular web pages,


it is important to have the right tools at hand to create Web Stories.


After all, not everyone is a developer.


That's why there are standalone story editing tools


that help you speed up the content creation process


without having to write a single line of code,


tools that allow you to achieve better results


thanks to visual editing and guidance along the way.


Many such editors already exist today,


such as Make Stories, Visual Stories, or Newsroom AI.


And if your site is built using a CMS,


there are dedicated solutions for that too.


For example, with the Web Stories for WordPress plugin,


you can seamlessly integrate Stories into your existing editorial workflow


and make them an inherent part of your website.


Such editors make it easy and fun to produce visually stunning stories


and guide you towards a beautiful end result.


They take care of all the heavy lifting


so you can focus on the actual story creation itself.


As you can see, that part is a breeze


thanks to an intuitive WYSIWYG interface


and helpful building blocks to get off the ground quickly.


But even the best Web Story isn't worth anything


if it doesn't make you more successful.


Let's take a look at how you can make the most out of Web Stories


using the various techniques and platforms available to you.


After all, you would want to ensure Stories benefit your overall strategy


and produce a return on investment.


If you want your Stories to be found and indexed by search engines,


you would want to think about SEO.


In a nutshell, you should be doing all the SEO practices


you would do for any other page on your website.


If it helps rank your non-Story pages,


it will probably help your Stories as well.


This includes things like adding meta descriptions


and including Stories in your XML sitemap.


There are also a few Story-specific requirements to keep in mind.


For example, some necessary metadata needs to be supplied as well,


like a poster image and a publisher logo.


For more details, I recommend checking out the Storytime episode


about SEO for Web Stories


on the new Google Web Creators YouTube channel.


To measure and improve your performance on Google Search and Discover,


you can use Search Console to better understand


how Google sees your pages.


Its various tools and reports help you analyze your traffic,


fix potential issues,


and make your Stories really shine in Google Search results.


Web Stories can actually appear on Google across Search, Discover, and Images.


On Search, the appearance can range from a single search result


to a visual carousel showcasing multiple Stories


depending on your country and language.


To give you an example, when people search for


Things to do in New York,


the grid view shows Web Stories from multiple publishers.


For your Web Stories to be eligible to appear in places like that,


they have to meet certain guidelines.


Most importantly, they have to be valid AMP.


A valid AMP Story is one that adheres to various AMP specifications.


This allows the Story to be served via the AMP cache


and ensures good performance and the best experience for your users.


Use the Web Stories test tool to verify that your Web Story is valid


by typing or pasting its URL.


It also allows you to preview how the Story will look like


in Google Search results so you can decide whether anything needs further tweaking.


Once you have published your Story and validated it using the Web Stories test tool,


it is time to share it with the world.


And with that, it might be a good idea to measure


how your audience interacts with the Story.


How much time do they spend on a page?


Are they clicking on the call-to-action links?


It is possible to set up analytics for your Web Stories


with a broad range of providers, such as Google Analytics,


to get all the answers to these questions.


There are many guides and best practices available


for setting up Web Stories analytics according to your needs.


It is worth taking some time to read these materials


in order to get a better understanding of the possibilities.


Monetization is an important aspect for publishers on the web


and just as relevant for Web Stories as for other types of content.


In Web Stories, monetization capabilities exist, for example,


through immersive full-screen ads,


allowing for seamless integration into the user's journey.


The easiest way to include this is through an ad server


like Google Ad Manager or via AdSense.


Since the Web Stories runtime handles ad quantity and placement,


you only really have to set everything up once


and can then forget about it.


Pretty easy.


These are all the things to keep in mind for optimizing Stories themselves.


But what about the rest of your website?


Web Stories can shine there too.


For example, you can embed Stories elsewhere on your site


in a standalone player or display a carousel of your favorite Stories.


By linking your content this way, your readers can easily reach your Stories


from other parts of your website and vice versa.


While various components and examples exist for that


and can be implemented manually, your Story Editor of choice


likely already offers such integrations out of the box.


SEO, analytics, AMP, monetization,


these are quite a few things to take care of.


Luckily, Story creation tools like Web Stories for WordPress


are of tremendous help to set things up and stay on top of everything.


Not only do they provide solid default configurations out of the box


for things like analytics and serving ads,


they will also include the required metadata for Stories


and tell you when something needs optimization.


And thanks to integrations with other aspects of your website,


you can measure your Web Stories success all in one place.


With this, you should now have a better picture of what Web Stories are,


how you can create Stories,


and how you can fully leverage their potential.


For more information about Web Stories and a collection of inspiring examples,


I recommend checking out the dedicated Web Stories on Google website.


And on the new Google Web Creators YouTube channel,


you can check out the Storytime series


in which you will learn more about Story creation best practices


and how to make the most out of Web Stories in general.


I'm already looking forward to seeing all the amazing Stories you create.


Thank you very much for listening, and have a great day.


Google Search Central Thank You: 400,000 Subscribers!!

OK, seriously, who called this meeting?


Gary, your camera is off.


John, you're on mute?


Oh, oh, sorry.


Anyway, I just wanted to share with all of you


that our YouTube channel has reached 400,000 subscribers.


What? 400,000 subscribers?


That's a great piece of news.


Arigato to all of our viewers.


Yeah, thanks a lot from all of us.


Let's take a look at some of the best of them from the last few years.


Great idea, Takeaki-san. Let me present that.


Roar! Warning, dinosaur videos!


Roar!


Is a hot dog a sandwich?


Pure spam stands for what webmasters usually call black hat SEO.


Junior, what are you doing there? That's not a site map.


Stay tuned.


One, because I guess it depends on the site.


It's the typical, it depends answer.


It's like walking away with the cable is hard.


That doesn't work.


Well, well, well. That's all for today.


I hope you found this video useful.


The Webmaster Team.


A virtual webmaster unconference.


Look for areas where you can change the title text


between the appropriate HTML title text.


But don't worry about magical SEO dust.


We live and breathe everything around websites and websites.


So that's a really big topic for us.


Hello and welcome to SEO Mythbusters.


Today I have been...


What?


SEO Mythbusters.


Sorry, am I late to the meeting?


English Google SEO office-hours from March 11, 2022

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


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


where people can jump in and ask their question


around their website and web search.


We have a bunch of questions on YouTube


as well, which we can go through.


But there are some people here with their hands already up.


So maybe we'll just jump right in there.


Let's see.


Aakash, I think you're up first.


AAKASH SINGH SINGH SINGH SINGH SINGH SINGH SINGH SINGH SINGH


Hi.


So my question is related to the pages which are directly


getting dragged at 8th or 10th or 12th,


and suddenly they disappear from the search.


So is it really like Google is still


trying to understand the overall website quality,


or there could be some other technical issues?


Because when the pages are live, they are in the search.


When they get indexed, they are placed at 8th position, 10th,


or 12th, or 15th.


So being at very close or near to the first page


and suddenly dropping out from the search,


how does Google take it?


Like, is it more kind of the quality issues


that Google feels, or there could


be some other technical issues?


I don't think there is anything specific that would cause


rankings to change like that.


So that usually is something which is quite natural.


And sometimes over time, things go up,


and then they can also go down.


It can also happen that pages drop out of the index


and new pages come into the index.


Kind of this, I don't know, this light change over time,


that's kind of expected.


So I wouldn't say it's indicative of a quality


issue or a technical issue.


Of course, quality and technical issues can cause that too.


But just because this happens for some pages,


I wouldn't necessarily see that as a sign


that it must be a quality or a technical issue.


However, it is mostly related to 99% of all pages.


So all of my pages, they suddenly


get ranked at somewhere more closer to the first page,


and suddenly disappear.


They could be there for one or two days,


and then they disappear.


So is it more related to the website quality


that Google is still trying to figure out


whether this website is being correct to show to the users,


or still there could be some more kind


of technical issues, or maybe some JavaScript issues


because we are using React as a server-side rendering.


So even that would have been caused something related


to that.


I mean, if you're using server-side rendering,


then the JavaScript wouldn't be playing a role there


because we would just see the HTML version.


If it were technical issues, usually that


would be pretty clear in Search Console,


in that those pages would return the 404, or no index,


or something like that.


I mean, it's really impossible to say,


in general, for a website.


But for most websites, it's pretty normal


that some pages kind of get indexed and show up


in the search results, and then at some point,


they drop out again.


And things kind of shuffle around a little bit over time.


It shouldn't be the case, like everything is indexed,


and then everything disappears.


If it's really the whole website,


then that would sound more like a bigger issue.


But the general light fluctuations across search


are kind of expected.


Oh, one more question, so sure.


Like currently, one of my plans that's set


is supposed to be in India.


So when we do site colon, we have,


let's say, x number of URLs, like this many URLs


have been indexed in this particular,


from the nearest web server, might be correct or might


be wrong, or in Indian location.


However, I've been noticing many of the clicks


from different countries.


But I see if there are a few countries where


we don't receive any clicks, I've


tracked in Google Search Console, or in Google Analytics,


not even one session.


However, in those particular countries,


if I do site colon and my particular domain,


I see 40,000, 50,000 kind of URLs.


However, in my own country, I see only 500 or 600.


That's the usual amount of pages that


have for that particular client.


So how can this be possible?


Because even I make sure the staging domains


are being blocked.


But countries which have got no relevant traffic or clicks


or inflation or sessions, how can when


we do site colon something in that particular country,


we get like 40,000 and 50,000 of the site colon,


that particular number?


How is that possible?


I think there are two things.


So on the one hand, we don't have separate indexes


for individual countries.


So it's not the case that we have one index for India


and one index for, I don't know, Hong Kong or whatever.


It's really essentially just one index.


We have multiple data centers around the world.


But for the most part, that kind of evens itself out over time.


And if something is called an index in one data center,


then usually it's visible in most data centers


fairly quickly.


So from that point of view, it's not


that there is a different number of pages indexed


in different countries.


That definitely shouldn't be the case.


The other thing to keep in mind is


that the numbers shown there for things like site queries


are not meant for diagnostics purposes.


It is not a reflection of what we actually have indexed.


It's purely a very simple approximation


based on kind of a very quick look at our index


for that specific query.


And it can be off by several orders of magnitude.


So that's something where I would definitely not


use the site colon numbers for anything


to try to figure out what actually does that mean.


OK, short talk.


Sure.


Thank you so much.


Thank you.


All right, Christine.


Hi, John.


Thanks for doing this always.


I have two questions, so make it quick.


The first one being, we recently added a page


to our site that is consistently driving significant traffic


and engagement, like levels we've never seen before.


So it's really through the roof.


My question for you is, can a single page


with extremely high engagement and traffic


have an influence on the domain as a whole?


Do these signals trickle to other pages on the site


and play a positive role at that domain level?


So I don't think we would use engagement as a factor.


But it is the case that usually pages within a website


are interlinked with the rest of the website.


And through those internal links across the website,


we do forward some of the signals.


So if we see that a page is a really good page,


and we would like to show it in search a lot,


maybe it also has various external links going there,


then that gives us a lot of additional context


about that page.


And we can kind of forward some of that


to the rest of the website.


So usually, that's a good thing.


The thing I might watch out for is


if it drives engagement for the kind of things


that you care about.


That is just something that I've sometimes


seen where a page might be very visible for certain queries.


But when you look at the queries,


I don't really want to rank for that.


My topic is something else.


So that might be something just to kind of take


a cautious look at the metrics.


Absolutely.


Thank you.


The second question is, for Core Web Vitals,


we prioritize our high search pages for product improvements


like anyone else would do.


Can a subset of pages with Core LCP or CLS


say only the video page on the site that


are in the main or secondary or even tertiary search traffic


driving pages on the site impact the rest of the site's


overall Core Web Vital score?


So why I mean by this is like, can a group of bad pages


with little search traffic in the grand scheme of things


actually drag the overall score of the site down?


And do we need to prioritize those bad pages,


even though they are in high traffic pages?


Yeah.


Usually, that wouldn't be a problem.


So I think there are two aspects there.


On the one hand, for the Core Web Vitals,


we look at a sample of the traffic


to those pages, which is done through, I don't know,


the Chrome User Experience Report functionality.


I believe that's documented on the Chrome side somewhere.


But it's essentially a portion of the traffic


to your website.


So that means that, for the most part,


the things that we will look at the most


are really the pages that get the most visits.


So if you have random pages on the side


that nobody ever looks at and they're really slow,


then those wouldn't be dragging your site down.


And the other way around as well,


if those random pages were really fast,


they wouldn't be pulling your site up.


Even if it's a lot of random pages,


if overall they just don't get a lot of traffic,


then we don't really care about it.


The idea there is the things that people see


should be, I don't know, have a good user experience.


So if most people are seeing a certain portion of your site,


then that's the part that we want to focus on.


The other thing is, with the page experience update,


depending on how much data we have for our website,


we might split it up into different sections.


And we try to do that by understanding


which pages across a website are essentially similar.


And that can be by type of template or something


like that, which means if we can see that all of, I don't know,


say for an e-commerce site, all of the product pages


are really fast, and maybe we have enough data


to look at the product pages separately,


then we can have that group of pages treated on its own.


And if there is a different kind of page


across the site that has enough data that is slow,


then we'll say, well, this kind of page is more slow.


So that's the second part there in that


if you have a kind of page that is very slow,


and we have enough data for that kind of page


to understand, well, this is just that part of the website,


then just that part will be affected by the Core Web Vitals


and the page experience update.


SPEAKER 2 Got it.


So it'll be isolated to the content type.


Or the content template.


Exactly.


It kind of depends on how much traffic those pages get.


Thank you very much.


Cool.


All right.


Solonia.


SPEAKER 3 Hi, John.


Hope you're doing well.


Well, this time I'm only with one question,


but rather sensitive one.


So can we expect that Google will stop


ranking Russian propaganda sites on Russian language inquiries


concerning war in Ukraine on demand of EU sanctions?


I'm talking about the sites that provide misleading information


and detected by Russia Today analysis.


Can you please elaborate on the actions of Google here?


I don't really have any insight in that regard.


So I don't really know what all is happening there.


I do know it's something that I've seen on Twitter


and people talk about it.


So I'm pretty sure the search quality folks are aware of that.


But I don't know what the details are there.


Sorry.


OK, good.


Thank you.


Sure.


Hazel.


SPEAKER 4 Hey, John.


Good to have you here.


So I've got three questions.


The first one is about internal links.


So in the previous office hour, you


once said that using too many internal links


on the same page can dilute their values.


And maybe Google won't be able to understand the site


structure.


So in your opinion, what's the amount


of ideal internal links per page for e-commerce sites


based like maybe with millions of pages?


I don't think there is an optimal number.


The part that I would watch out for


is that when you crawl the website,


that you can still recognize there is a structure.


So especially with an e-commerce site,


that you can still recognize here's the main home page.


Here's the top level categories, second level categories.


You can still recognize that structure.


So that it's kind of clear how the context


is of individual pages.


So for example, it would be problematic.


Well, I mean, I guess not really problematic,


but it's harder to recognize the structure if every page was


linked with every other page.


And if you have millions of pages on your website,


it's not going to be the case that you have millions


of links on every page.


So from that point of view, I usually


don't see any issue with this with e-commerce sites


just because the e-commerce CMSs tend


to be set up in that way anyway, that you


have different levels of categories


and then the individual product page at some point.


Yeah.


So like you said, we don't have millions


of internal links on our page.


But we do have some different type of internal links,


like some category pages also have category internal links


and also have product internal links and also


like some other supplier page like that.


I mean, usually what I'd recommend


is trying to use one of the crawlers


that you can run on your own, something, I don't know,


like Screaming Frog or I don't know what they're all called.


And most of these let you generate a graph


of the internal linking within your website.


And it should be something where you


have a clear structure there, where everything


is around one central point and pointing off and growing


almost like, I don't know, like tree roots or something.


Hard to visualize without showing.


But usually when you look at that,


you recognize, oh, there is a structure here.


Whereas if it's just a collection of dots


and everything is linked with itself


and there is no clear visible structure,


then usually that's a sign that it's, I don't know,


perhaps not ideal.


OK.


Good.


So the pages that are linked closer to the home page


will index faster than pages like far away


from the home page.


Is that right?


In most cases, that'll be true.


It depends a little bit on the individual website.


For most websites, the home page is kind of that central place


where everything kind of rotates around.


For other websites, it might be that you


have one specific category for which the company is known.


And then almost like that category page


or that main product page is more like the, I don't know,


the central point of the website.


But for most websites, the home page


is usually that central place.


OK.


So I raised this question because we


find that many of our category pages


didn't get indexed faster than other specific pages


like product pages.


And these category pages, they are at a formal place.


Like they are closer to the home page.


So we're just wondering if this theory is right, correct.


Yeah.


I think a difficult part there is also


that kind of linked closer from the home page


is kind of a general rule of thumb.


But it doesn't have to be the case because we


have a lot of systems also in play


to try to figure out how often we should recrawl a page.


And that depends on various factors.


It also depends on how well it's linked within the website,


but also based on what we expect will happen with this page.


How often do we think it will change?


Or how often do we think it will change significantly enough


that it's worthwhile to recrawl and re-index it?


And that might also be playing a role here.


I don't think with e-commerce sites that would be common,


but it could happen that we kind of say, well,


category pages tend to link to a lot of product pages.


And maybe the price changes are more visible on the product


page, so we go to the product page faster.


OK.


Understood.


John, can you also just comment on,


I was just going to say, can you comment on flat hierarchy


versus strict kind of URL hierarchy


because there's no such thing as closer.


With a flat structure.


How do you mean?


I guess.


Well, closer to the home page can be number of clicks


to get to the page you want on the home page,


or it can mean sections of the URL


if you've got a strict hierarchy in the URL.


Oh, OK.


Yeah.


Then there's no such thing as closer to the home page


because they're all under one folder structure.


OK.


For us, we don't care so much about the folder structure.


We essentially focus on the internal linking.


And it's also kind of links from the home page,


not links to the home page.


So from that point of view, if you


have a URL structure that doesn't have any subdirectories


at all, we still see that structure


based on the internal linking.


And a lot of times, the architecture of the website


is visible in the URL structure, but it


doesn't have to be the case.


So just looking at the number of slashes, for example, in a URL


doesn't tell us that this is lower level or higher level.


It's really like from the home page or from the primary page,


how quickly can we reach that specific page?


And that's still just that one part where we kind of say,


well, within the general page rank calculations,


that plays in there.


But the other stuff also still plays


in where it's like how often we think


a page will actually change.


I think you had another question, Hazel.


Yeah.


So the second question is about index pages.


So the number of index pages of our site


has increased significantly, like more than 30%.


But the traffic only has increased by 2%.


And since there are millions of pages in our site


and these pages are indexed, so it means the page quality is


OK, but these index pages didn't bring the same level of traffic


to the site, in our opinion.


So we think the traffic driving ability of these pages


are not so good.


So in this way, how can we increase the traffic?


And any tips to improve this?


Increase the traffic.


I don't know.


I don't think there's one simple trick to just getting


more traffic.


I think, especially with an e-commerce site,


it's probably normal that you have


this growth of index pages first and then at some later stage


maybe more traffic, because more people are looking for more


specific items across your website.


But it can also be the case that we just


index a lot more pages.


And then over time, we realize, well, actually, these pages


are not bringing that much usefulness


to the search results.


Maybe we'll have to drop some of those


again and focus on a different part of the website.


But I wouldn't see it as a problem, per se,


in that you have 30% more pages but only 2% more traffic.


Sometimes that's just normal, because you


have products that are important and useful,


but they just don't get a lot of traffic.


And those are just as useful, even if they just


get a few visitors every day or whenever.


AUDIENCE 1 Sure.


Sure.


I got you.


And also, one last question is a general one.


So for large e-commerce sites, how


to improve the perceived quality of a whole website


at Google's site?


Many blog articles, maybe backlinks,


maybe some content quality.


But for e-commerce sites, we don't


know how to improve our content quality.


Yeah.


I also don't think there's this one trick that you can do.


I think we've given some tips of things


that you can focus on with the reviews updates


that we've done for product reviews.


Some of that might apply.


But I don't think there is one solution


to improving the overall quality of any larger website,


and especially on e-commerce sites.


I imagine that's quite tricky.


And there are sometimes things like working


to improve the quality of the reviews that people leave.


If it's user-generated reviews, for example,


making sure that you're highlighting the useful reviews,


for example, I don't know.


It seems like a lot of things come in there.


What I usually recommend is that people


do some kind of a user study in that they take some people who


are not directly associated with your website


and have them run through some tasks on your website


and on other people's websites and try


to get as objective feedback as possible from them.


So I don't know, what is it?


Maybe five years longer, probably.


We did a blog post specific for a Panda update


about 20-something questions that you


can ask yourself about the quality of your website.


And I find those kind of questions really useful.


And doing a user study usually brings up some ideas of things


that maybe you missed or maybe you didn't want


to accept for whatever reason.


So that's kind of the direction I would go, not


focus on purely like, well, for SEO, I will make a blog.


Or for SEO, I will try to do some link building campaign


or something like that.


But rather, try to really work together with real people


and figure out where are some areas that you can improve.


And it might be better to end up like you


improved the design of your website and that changes


the perception of users significantly enough


that we can pick up some of that and use that for ranking


as well.


It's really hard to say.


SPEAKER 2


So it's like care about the users and then the site well.


Yeah.


I mean, very simplified, that is essentially it.


Obviously, it's not very directly actionable.


You can't send your users cake and they'll be happy.


And then your website will rank higher.


Sure.


I got you.


Thanks.


OK.


Cool.


Pablo.


Hello.


I posted my question on YouTube,


but I'm going to say it now just because I'm doing it anyway.


We have looked at the cross-stats reports


on the Search Console and have been


trying to identify if there might


be some issue on the technical side with Google


crawling our website.


What are some of the signals or things


to identify that will point us if Google is struggling


to crawl something or if Google is distracted by files that


are irrelevant and things that it's trying to index


that are irrelevant for us?


So I think in your question, you also


mentioned that it's a fairly small site.


Is that correct?


Yes.


Fairly small, maybe five or six months old.


OK.


So my guess is the cross-stats report will not


be useful for you in that case.


Because with the cross-stats report,


you're really looking at an aggregate view


of the crawling of your website.


And usually that makes more sense


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


a couple hundred thousand pages.


Then you can look at that and say, oh, well,


on average, the crawling is slow.


Whereas if you have a website that has, I don't know,


maybe around 100 pages or so, then essentially,


even if crawling is really, really slow,


then those 100 pages, we can still get them.


Like once a day, worst case, maybe once a week,


it's not going to be a technical issue with regards to crawling.


It's essentially more a matter of understanding


that the website actually offers something unique and valuable


that we need to have indexed.


So less an issue about the crawling side,


more about the indexing side.


The exception there would be if there's really


a big technical issue with your website.


But that's something that you would see right away.


Because you would probably check individual of these URLs


and notice, oh, Google can't crawl them at all.


There's an error that's returned.


Or there's a no index that's returned.


And that would be very obvious.


So my assumption there, especially for a smaller


website, is that it's really a matter of making sure


that Google understands the value of the website


and that it knows that it makes sense


to index as much as possible.


Because the crawling side is not going


to be the limiting factor.


It's really more like, well, you have


to convince Google first that actually it should try to crawl.


SPEAKER 2 OK.


And just to confirm, you said that the crawl stats are not


an exhaustive report.


It's a sample and should be treated as a sample.


JOHN MUELLER I don't know.


I think the numbers shown in the report would be complete.


But maybe the URLs that are shown there,


I believe that's only limited to something like 1,000.


I don't know offhand.


But the graphs, that should be essentially complete.


The thing that sometimes throws people off


with the crawl stats report is that it includes


other systems within Google that use the same Googlebot


infrastructure.


So for example, if you run ads, then I


believe the ads landing page checks,


they also go through that infrastructure.


If you have product listing ads, those also


go through that infrastructure.


So sometimes you'll see a number that


is much higher than if you look in your log files


and just look for Googlebot, just because there


are different things that run on the same infrastructure,


and we treat them the same.


But it's not purely web search.


Thanks.


Cool.


All right.


Ankit.


ANKIT SHAHANAPPA Hey, John.


Hi.


Thank you for your time.


Yeah, I have a question.


It's a kind of lengthy one.


So there is a problem going on with me.


I have a new website.


So what the issue is going on?


I have been running this website for three years.


So everything is perfect and good.


So this month, I also answered this question on last Hangout.


But the problem also comes bigger.


Now it has grown.


So like on first March, my website homepage,


like it was gone from the search results,


completely gone from there.


OK, I can.


It's a kind of Google thing.


So I ran everything.


I kind of do everything.


I tried many things.


But the homepage was not in the search results.


But there's an interesting thing in the Google Search Console.


For every keyword, Search Console is saying,


I'm still ranking on first position.


For that, every keyword, I was ranking before first March.


But the significant amount of expression and clicks


has gone.


About 90% has gone.


But the rankings and the CTR is same.


For about one week, I tried everything.


But nothing works out for me.


I have also gone for central health forms and everything.


But nothing.


So I take a bold step.


I migrate the website to a whole new domain.


So in a couple of hours, everything


gets indexed about 100 pages, gets indexed in a couple


of hours.


And the new websites, in three hours,


ranking on the first position.


So those keywords, everything was good.


And redirects in the proper, everything else, take care of.


After three days, the same problem


happens with the new website also.


The home page, only the home page


gone from the search results.


But the Search Console is still saying


that I'm ranking on the first position for it.


But I can't find my website in the search.


I tried many different devices, IPs.


But I can't find my website on those keywords,


specifically my own page.


But Google Search Console is saying


I'm still ranking on the first position still.


But every day I'm checking, it's still ranking on the first.


I don't know I'm out of option now.


No, I don't know what I should do.


So what I would do, first of all,


is try to figure out if it's a technical issue or not.


And one way you could try to find out more there


is to use the URL inspection tool.


Yeah, I did the URL inspection tool with the old website also.


Everything is, there's no error in the search console.


I tried different crawlers, also screen for everything.


Everything is good.


There's no error in everything.


And now I also switched to AMP for the core web


vitals are 100% for the old website also


and for the new ones also.


There's no error in the technical point of view,


nothing.


It's a home page.


I kind of not say it's a quality issue because it can happen,


because it's a Google thing.


But I don't think it's a quality thing because search console


is still saying I'm ranking on the first position,


but I can't find my website.


And the traffic has also gone like 90% off.


I'm still getting the traffic from those keywords,


I tried different IPs, countries, search engines,


devices, but I can't find my website anywhere.


Yeah, I mean, the check with the URL inspection tool is mostly


to determine is the page indexed or not.


And from what you're explaining, it's indexed,


but it's not ranking, at least when you search.


And the thing with, I think, the performance report in Search


Console, especially the position number there,


is that is based on what people actually saw.


And it can be the case that a small number of people


saw your website, but when they did see it,


it was ranking really well.


And in those cases, we would say, well,


that ranking is what we saw.


It doesn't mean that it will always


be ranking that high when people search.


It might be that for a short period of time,


it's ranking at number one.


And then for a longer period of time,


it's ranking at, I don't know, position 200, for example.


And if nobody goes to number 200, then the only thing we see


is that number one ranking.


And that's what we would show in Search Console


then because we just essentially report


on what people actually saw.


And kind of that, the history that you said there


with regards to I moved to a new domain for a brief time,


it was very good, and then it disappeared again,


to me, that hints very much at a bigger quality issue


where when Google systems was able to understand


your website again, it was like, well, we're not convinced.


And kind of that period in between when Google says,


well, we don't know much about this website yet.


We will try to kind of treat it as something reasonable.


That's kind of that time when Google wasn't even


able to understand your website that well.


So to me, without knowing your website,


that sounds a lot like a quality issue.


And it sounds like something where


it might help to have multiple people who are not


associated with the website to also give you some tips


and kind of say, here's what you should be doing differently


or what you could be doing differently.


And I think as a site owner, when you're running the website,


you're making the website, it's sometimes really hard


to take this kind of feedback.


But I think it's important, especially


if you care about the bigger picture in the search traffic


side of things.


Yeah, sure.


I appreciate that also.


So I work for that also for the user feedback.


I have community or some social networks for this website.


I also ask them, but they also said


that they are not finding my website in the search results.


But I don't know.


I'm checking for everyday performance report.


I am still getting the same.


There is no drop in the ranking and the CTR,


but there is a drop in the performance


and the impression in the clicks.


And yeah, still, I don't know what can I do.


I'm still generating the content.


I'm still posting my new content daily.


But it doesn't help me a lot.


So I don't know what should I do right now.


And for the most part, I will try to get some feedback


from people who are not in your community already,


like people who don't already go to your website.


Try to get as neutral as possible.


Because it's always, if people are already going to a website


or if they're making similar websites themselves,


then they'll say, oh, yeah, your website is fine


because it's just like mine.


And they don't realize, well, actually, my website


is also bad.


So that's something where really trying to get neutral people,


I think that makes a big difference.


But it's hard.


Yeah.


Thanks.


Yeah, there is one interesting thing also with this regard.


One user sent me the screenshot.


For the same queries in the search console,


in the Google Chrome, when they change the language,


like in the mobile days, in the photo language option,


you can change the language.


When they change the language for the same keyword,


my website is ranking on the first position.


For every language, they change for that keyword.


But when they go on the English version,


the website is not in like 10 pages also.


But for most of other languages, they're ranking there.


I think that this ranking coming from there, I think,


I don't know what's the issue.


That could be the case.


Yeah.


So sometimes you can drill down in Search Console


to try to get more details.


I had an issue with my website where


it was ranking very high for some term


that I wasn't aware of.


And it turned out it was only one specific country where


it was like that.


And at some point, that went away and fixed itself.


But it was weird because I could never see it like that.


But it was that one specific setting or country,


and then you see it like that.


So it can be a matter of time.


I should stay on this.


And maybe with the time, Google will.


I wouldn't wait.


I would really try to see what you can do to improve there.


Because it can happen that it pops back in for a bit.


But I would assume that that will also be very temporary


and disappear again.


So you really need to convince Google's algorithms


really strongly that this is a fantastic website.


I should.


Thanks, John.


Cool.


Good luck.


OK.


Let me run through some of the submitted questions.


Seem to be running low on time already.


But let's see.


Why might there be tiny differences


in synonyms or search terms that make such a big difference


in ranking position?


And the example they gave here was edit video.


And then for the query video editor,


the page is nowhere to be found.


So from our point of view, that can be completely normal.


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


we do try to understand things like synonyms in a query.


But we also try to look at the, I guess,


like the full context of the query.


And especially when it comes to synonyms,


we might assume that something is like mostly a synonym.


But that doesn't mean that it's completely a synonym.


And especially when you're looking at something like edit


video versus video editor, the kind of the expectations


from the user side are a little bit different.


Like on the one hand, you want to edit a video.


On the other hand, you might want to download a video


editor.


And it seems very similar.


But kind of the things that the users want there


are slightly different.


So from my point of view, that kind of


makes sense that we would show different rankings there.


And we have the same with things like slightly different


spellings of words.


Like if you have the British or the American version


of an English word, if you have a word or a letter


with an accent and it doesn't have an accent,


we understand that these are mostly the same.


But we also understand that they're slightly different.


And we try to show search results that kind of take that


into account.


Let's see.


Questions about FAQs.


I have two websites.


One of them is a service website.


The other is a recipe website.


So on the service website, I have different FAQs


based on different city pages for my services.


Do I have to create separate pages for FAQs?


Or can I just add them to the same city pages?


And from our point of view, you can do whatever you want.


So the FAQ rich result type can be shown in the search results.


And it's not guaranteed that it's always shown.


But it could be.


And it's shown for the page where we found that markup.


So if you make a separate page with the FAQ markup on it,


and that separate page is shown in the search results,


then we can show it.


If that separate page is not shown,


then we wouldn't be able to show it.


And let's see.


I think the same applies to the recipe website example there.


We've seen that most recipe websites are not


providing very useful information in my country.


And we try to change that by providing


more useful information and going


to the point of adding FAQs to every recipe.


What is the best way to add these FAQs?


And again, from my point of view, it's totally up to you.


The one thing I would watch out for in cases like this, where


you have multiple rich results types that are potentially


relevant for your pages, is that some of these types


we can combine, and some of them we can't really combine that


well.


I don't know specifically when it comes to recipes


if we can combine them or if we essentially


have to choose one or the other.


And if you notice that no other recipe website has


kind of like the recipe rich snippet plus the FAQ


section on the bottom, then probably we can't combine those.


And then it's probably better for you


to pick which type of rich result type


you really want to have shown and to focus on purely


that type.


Let me see.


I think there was a question in the chat.


Wouldn't competing schema not be a good thing?


Yeah, that's essentially what I was meaning there,


in that if you have different rich results types which


can't be combined, then our systems have to pick one.


And if you have a preference which one you prefer,


then I would just make sure that you just have that one.


Google explains in its subscription and paywall


content guidelines that a specific schema must


be added to a page in order to share paywall content


into the index and not trigger a cloaking penalty.


After implementing this, however, the rich results test


does not seem to identify this enhancement.


How can we be sure that Google has detected the enhancement


and that we aren't inadvertently risking a cloaking penalty?


So I assume the rich results test will show this,


but I haven't actually checked it,


because the rich results test, for the most part,


focuses on what Google actually would show in the search


result as a rich results type.


And essentially, the paywall content


is probably not one of the things


that we would show as a specific rich result type.


So it's possible that we wouldn't show that in that test.


One simple way to do that is to make a very simple test page


and just test that page individually.


The other test that you can do to make sure


that Google is actually seeing the full content


with the markup is the normal URL inspection test, where


you can do a live fetch of the page,


and you can look at the HTML that


is generated for that page.


And you could copy that out into an editor


and double check to make sure that your structured data


that you want to have visible there is actually shown.


So that's the direction I would head there.


Let's see.


You recently reiterated the importance of internal linking


to signal to Google how important


specific content on a site is.


I want to know, are links within certain sections of a site


looked at differently?


For example, if a page is linked within a header or a footer


and therefore included on every page of a site,


does Google view those links differently


than links within the body of the page?


We don't really differentiate there.


So if things are linked in your footer of the page


and they're linked from across the whole website,


then from our point of view, you have those links


from across your whole website.


It's not the case that we would say, oh, links in a footer


have less weight or are not as useful.


We will ignore them or anything like that.


So from that point of view, when it comes to links,


we essentially just see them as links on a page.


It's slightly different when it comes to text in there


in that we try to understand what the primary content is


of a page.


And when it comes to ranking relative


to the other content on your website,


we'll try to focus on the primary content


section of the page.


But links, from our point of view,


just help us to better understand the site structure.


And whether they're in the header


or in the footer or in the sidebar or the main content,


that doesn't really change anything for us.


Our question is, does mobile-first indexing


help with search rankings?


Our website is still being crawled by Googlebot desktop,


and we can't figure out why it isn't switching to mobile-first.


We've been through the Google documentation


and troubleshooting, but nothing jumps out.


Would moving across to a progressive web app


and offline support help?


So first of all, mobile-first indexing


does not change anything for ranking.


So it's not the case that you need


to force any kind of a move to mobile-first indexing.


It's purely a matter of indexing and picking out the content


that we would use on a website.


So from that point of view, I would not worry about this.


If your website works fine on mobile, then at some point,


it'll be switched over.


I believe there's still some sites that are left that we


haven't switched over yet.


But for the most part, we've switched, I guess,


most sites over.


And those that are kind of remaining,


we continue to double-check them when they're ready.


And when we think they're ready, we'll just switch them


over.


But it's not the case that you would notice any ranking change


there unless the mobile version is significantly different


from the desktop version.


And that would also be a reason for us


not to switch over to mobile-first indexing.


And if the mobile version is significantly different


and we did use mobile-first indexing for your site,


then we would essentially just index your content


based on the mobile version.


And if there's more content on a desktop version,


we would ignore that.


So from that point of view, I wouldn't try to force this.


Moving to a Progressive Web App is something you can do,


but I don't think it would affect


how mobile-first indexing looks at your website.


And usually, when it comes to Progressive Web App,


usually there are JavaScript framework websites.


And usually, that brings a whole set


of other challenges that come with that,


in that you need to make sure that Google can actually


see your content because JavaScript is something


that we can usually render and handle well,


but it's not always as easy as a pure static HTML page.


On our website, we have a lot of shortcuts, such as, I guess,


like the English version would be e.g. for example.


How does Google handle that?


And the short answer is we don't do anything special


with those kind of things.


We essentially treat them as tokens on a page.


And a token is essentially kind of like a word or phrase


on a page.


And we would probably recognize that there


are known synonyms for some of these


and understand that a little bit.


But we wouldn't really do anything specific there


in that we have a glossary of what this abbreviation means


and handle that in a specific way.


So that's something where, especially


when it comes to synonyms, our systems learn these over time.


And for the most part, we handle them when people search


and not when we do the indexing.


There's a video with Paul Harr on the Search Central YouTube


channel from an event, I think, like maybe December 2020


or 2019, I don't know, a while back.


And he's one of the engineers who


works on the search quality side at Google.


And in that video, he goes through some


of the synonyms, challenges that we've run across in the past.


And I found that super interesting to look at


and probably also gives you some ideas


on how we might handle some of these kind of expansions


when it comes to abbreviations.


Let me just take maybe one quick one here more,


and then we go back to live questions.


I have a website related to JavaScript and prerendering


using Angular.


Currently, it's impossible to change to server-side rendering


and wondering what other solutions for JavaScript SEO


that I can try.


So I would recommend taking a look


at the videos on our YouTube channel from Martin Split.


He's essentially been focusing on the JavaScript side


of things around search.


And he has a lot of information on what


you can do to test your pages and make sure


that they work well in search.


We've also expanded the documentation there over time


so that there's a lot of information


on how you can test to make sure that Google can understand


your pages.


And server-side rendering is not a requirement there.


We can render JavaScript-based pages for the most part.


Like I mentioned before, sometimes it's a bit tricky,


and it's worth double-checking.


But we have the testing tools.


You can try it out.


Maybe your setup just works by default.


A lot of the JavaScript frameworks,


they essentially just work without any specific changes.


Cool.


OK.


Back to people with their hands up.


And I have a bit more time afterwards, too,


if you want to stick around and ask more questions.


Let's see, Matthew.


Hi there.


Hi, John.


We ran into a bit of a tiger trap,


I would say, in terms of rich recipe results.


We have hundreds of thousands of recipes which are indexed,


and there's lots of traffic coming through


from the recipe gallery.


And then suddenly, or not suddenly, over a period of time


it stopped.


And all of the metadata checked out,


and Google, the search console, was saying, yeah,


this is all rich recipe content.


It's all good.


It can be shown.


We finally noticed that in the preview, when


you previewed the result, the image was missing.


And it seems that there was a change at Google,


and that if a robots.txt was required in order for images


to be retrieved, but nothing we could see in the tools


was actually saying anything was invalid.


And so it's a bit awkward, right,


when you check something to say, is this a valid rich recipe


result?


And it says, yeah, it's great.


It's absolutely great.


We've got all the metadata.


And you check all the URLs, and all the images are right.


But it turns out, behind the scenes,


there was a new requirement that you have a robots.txt.


How do you mean that you had to have a robots.txt?


What we found is, if you requested the robots.txt


from our CDN, it gave you like a 500.


When we put a robots.txt there, immediately the previews


started appearing correctly.


And that involves crawling and putting it


onto the static site, I think.


So operationally, we found adding that robots.txt


did the job.


Yeah, OK.


So from our point of view, it's not


that a robots.txt file is required,


but it has to have a proper result code.


So if you don't have one, it should return 404.


If you do have one, then we can obviously read that.


But if you return a server error for the robots.txt file,


then our systems will assume that maybe there's


an issue with the server, and we won't crawl.


And that's kind of something that's


been like that since the beginning.


But these kind of issues where, especially