if you just turn it off.


English Google SEO office-hours from March 12, 2021

So that's something that would be something


more of a temporary effect.


That's something you can also try


to mitigate by using the AMP cache API, I think,


where you can force a refresh so that we


can see these AMP pages actually no longer exist kind of thing.


I think we have a Help Center article on disabling AMP,


actually, that covers all of those steps.


The other effect that you might be seeing there,


depending on the type of site, is that for certain search


experiences, kind of like search features


that we show in the search results, we do use AMP.


So I think that's, in particular,


the top story section on mobile, where we essentially require


AMP pages, at least at the moment.


And if it's a news website, for example,


that has a lot of content that is shown in the top story


section when it's on AMP, then you


will see that kind of disappear.


That's something where with the update


that we're doing in May around Core Web Vitals and page


experience, we're going to start allowing normal pages as well


when they reach that appropriate bar to be visible in the top


story section.


So that'll be a little bit more mitigated.


But it really depends on the kind of site.


If it's not a news website, if there's


no kind of newsy content on there that


would have been featured in the top story section,


then it would be kind of weird to see


a drop in overall organic traffic.


DYLAN WALKER-GRAVESPIEFFE:: OK, yeah, it's not a direct news


website per se, but it's a medical article website.


And we do have a feature in the carousel, AMP carousel.


So yeah, that would be that.


JOHN MUELLER-GRAVESPIE:: Yeah, that could be.


Cool.


DYLAN WALKER-GRAVESPIE:: OK, thanks.


JOHN MUELLER-GRAVESPIE:: Mohamed.


MOHAMMAD EL-SAADI:: Hi, John.


Hi.


I work in an IT company.


We put lots of tons of quality content at our website.


But recently, we got to know that there


are a few websites that have been copying our content


and publishing it on their website.


In fact, they are not making an effort to change the images.


So I just want to know what kind of action we can take,


or how does Google consider these kind of activities,


and how we can protect ourselves in future regarding


these fraudulent activities.


JOHN MUELLER-GRAVESPIE:: I think the primary action you could


take there, depending on the situation,


is to look into the DMCA process.


The DMCA process is a legal process.


So I can't give you legal advice on when it applies


and when it would not apply.


But that might be something that you could look into.


With the DMCA process, you're basically


saying my content is my content, and someone else has copied it.


And you're giving Google that information on a per-page basis.


And based on that, our systems or the legal team,


I don't know the details, will review that and take action


on that, and also inform the other side about that,


so that if, for example, they were the original source,


they would be able to raise a concern


and try to find a different resolution for that.


But that's, I think, the primary approach


that you could take there.


The other thing that I would also keep in mind


is that if you're regularly seeing other people with copied


content ranking above your content, then to me,


that points at a situation where maybe the overall perceived


quality of your website is something


that our algorithms are having trouble with.


That could be something where maybe it makes sense


to take a step back and think about your website overall


and try to find ways to significantly improve


the quality of that to make sure that when our algorithms run


across your website with the content on it


and some random website that they don't know about


with the same content on it, that they say,


well, actually, your website is the one that we should trust.


And not so much like some random website


is perhaps just as good or even better than this website


that we know about that we know we don't want to trust that.


So that's a different thing to think about there.


But I would definitely look at the DMCA process first.


And also, if you're regularly seeing this,


I would really think about what you can do


to improve the quality overall.


AUDIENCE 1 OK, that means that we have loopholes


in our own website.


JOHN MUELLER 1 How do you mean?


AUDIENCE 1 Like we are not up to that quality.


That's why other websites are copying our content.


I don't know why other people are copying your content.


I can't say.


But if you're regularly seeing that the copied content is


ranking above your content, then to me,


that would point at some kind of quality worries


that our algorithms have.


OK, thank you.


Sure.


John, hi, how are you?


Back in, I think it was mid or late February,


a couple of the tracking tools were reporting some drops


in featured snippets and the amount of times


that those showed up.


Judging by your reaction, I don't


know if you are familiar with that at all.


Just wondering if that was deliberate by any means.


On Google's side, to reduce featured snippets from showing


up or if it was maybe for another reason


that that might be happening, it's


just featured snippets, when you get them, are pretty awesome.


And to lose them is pretty disastrous.


At least you've been used to riding this wave of traffic


that can come with a featured snippet.


So to lose it, yeah, just wondering


if this was deliberate.


Just wondering if there's any additional rationale


or if you know of any maybe it was a side


effect of another change.


I don't know.


Like the featured snippets and rich results in general,


those kind of things can fluctuate over time.


And I know the teams are always working on those features


and trying to fine tune the triggering,


so when we would show them or when we wouldn't show them.


Sometimes the triggering changes over time,


that we just kind of reduce the threshold overall


or that we change the focus a little bit


and say it's like less here and more here.


Sometimes that happens across geographies or languages.


But these kind of changes from our side


are essentially normal organic changes in search,


how they can always happen.


So it's not as though we're not really


it's definitely not the case that we say,


well, there's some technical requirement that's


missing on these pages.


Therefore, we dropped it.


It's more we need to refine which types of results


we show over time.


So yeah, just more of a balancing act, I guess.


Yeah.


So would you think that it was a deliberate kind of reduction


in featured snippets or maybe some other change that


might have then caused that reduction?


Any idea?


I don't know.


Usually we don't think of it as much


as we want to reduce the number of times we show a feature,


but rather we want to improve the targeting


and the relevance of when we show the feature.


And sometimes that does mean overall it's like fewer,


but it might be that there are fewer here


and there's a little bit more here kind of thing.


And that's something that just happens over time.


They're always trying to find a better


balance of what to show in search and improve that.


Gotcha.


Cool.


Thank you so much.


Sure.


Clint.


Morning, John.


My question relates to the mobile index


and specifically responsive design.


So if, for example, there is an element on the page which


links to, let's say, it's an online catalog or something


like that, so that component on the page


is essentially linking to the catalog,


the catalog itself is not mobile friendly.


So as a result under the responsive design,


we would basically hide that component.


But essentially it's still part of the DOM.


So under the new mobile index, will this content still


get called an index?


Or because it's not rendered on mobile,


it's basically not getting called an index?


If it's in the DOM, then we would be able to pick that up


for indexing.


So that would be perfectly fine.


I would only show up then on desktop potentially,


not on mobile.


Yeah.


Sometimes what we try to do is figure out


which parts of a page are visible


and kind of emphasize those with regards to ranking.


But especially on mobile, we see that there's


a lot more interactivity on a page


in that you kind of activate different tabs,


you kind of see different things,


and actually it's all a part of the same HTML page.


And from that point of view, if it's not visible


but it's in the HTML, in the DOM,


then that would work for us.


All right, thank you.


Sure.


All right, SEO team.


Hello, everybody.


Hi.


I am very interested in that I can talk with you, John.


I was waiting for this online session because


of a particular reason.


I have four more important questions for an excellent


purpose, but the four questions are somehow big.


Then I will ask the first two questions.


I wish that I can get some time during the session


to ask the remaining questions.


First of all, for websites that have AMP pages and non-AMP


pages, how we can measure the core of vitals


to get a general idea about the whole performance


of the website?


I mean that, do we need to measure the performance of AMP


pages alone and the non-AMP pages alone?


What is the best practice here?


So depending on the way that you have the AMP and non-AMP pages


set up, you may be able to see the difference in Search


Console or in the Chrome User Experience Report data


because that could be split out by URL.


So I would double check that.


The other thing that you definitely can do


is do lab testing, especially if you're modifying pages,


if you're trying things out.


Then I would do lab testing with like PageSpeed Insights,


with Chrome directly in the browser to test things,


especially to compare different versions of the same page.


And when it comes to lab testing for AMP pages,


if it's a valid AMP page, then definitely also check it


on the AMP cache to see what users would see when


they click on a search result. And that's


kind of the approach that I would take there.


I also recommend when it comes to testing


that you set up some kind of a monitoring system on your side


to regularly test the important pages on your website


for the Core Web Vitals so that you


are able to recognize quickly when something goes wrong.


But that's more of kind of like the long-term thinking.


SPEAKER 2 OK, OK, thanks a lot.


Another question is that I found a lot of difference


between Google Analytics and Google Search Console data.


For Google organic traffic, I read a lot


about the causes of such a difference.


And I know that each tool have its own algorithm


in collecting and measuring data.


But we are facing a lack in reading our Google organic


traffic, in which we have some articles that get thousands


of clicks on Search Console.


But Google Analytics shows that it only


have 10 or 20 Google organic traffic.


So we're sure for same date range and the same article.


More than that, in Search Console sometimes


we see articles that have an increasing curve


for a number of clicks.


But Google Analytics show a decreasing curve


for Google organic traffic.


So why we are seeing that?


And is there any step-by-step guide about how we can solve


the big difference in data between Google Analytics


and GSC?


I don't know, so that's something I would check


with the analytics team and with the analytics help forum


to get some input there.


The one thing I would kind of suspect,


but I don't know how it's implemented on your side,


is since you mentioned AMP pages,


it's possible that the AMP pages are being tracked separately


in analytics.


So depending on how you have AMP set up,


it might be that you have a separate property


for the analytics pages and they're kind of separated out.


Whereas in Search Console, we focus on the canonical URL.


So we would show all of that traffic together.


So that might be one reason, but I would really


get some tips from the AMP help forum.


Yes, yes, Jun.


Analytics help forum.


Yeah.


But sorry, sometimes we saw vice versa data.


We saw that Google Analytics show


data more than the real data in Google Search Console.


Not every time Google Search Console


show data more than the number of organic traffic


at Google Analytics.


Yeah, I don't know.


So the tricky part is Search Console


can track what happens in search but doesn't


know what happens on your website directly.


And people can go to your website


directly with a referrer from Google,


and it can look like someone is coming from Google Search.


But in analytics, you can't tell is it really


from Google Search or is it someone just using


the wrong referrer?


This kind of weird behavior is pretty common.


It just happens on the web.


So sometimes you do see some discrepancies.


But especially if you see a lot more data in Search Console


than in Analytics, then to me, that


feels like something in Analytics is tracking wrong.


OK, OK.


Thanks a lot.


Sure.


Ritu, I don't know if I'm pronouncing your name right.


Hey, John.


How are you?


Hi.


Actually, I have a few questions related to schema.


Actually, I have implemented schema Markov


for knowledge panel graph on my website.


But still, it is not appearing knowledge graph.


Please let me know which factors we


need to consider to implement knowledge


panel graph for a brand.


Please let me know.


Yeah, I don't think there's any specific markup that you


can use to force a knowledge panel to appear for a brand.


So what you can do is give some general company information,


like the logo, like address, opening hours, things like that.


But just because that's specified in structured data


doesn't guarantee that we will show a knowledge panel entry.


Sometimes what you can also do is the Google My Business


entry, which also appears in the side similar to a knowledge


graph entry.


So that's something where you can try different approaches


there.


But it's not that there's one structured data type


that forces the knowledge panel to appear.


OK.


Another question is related to site links.


Actually, I need to appear some desired pages as a site link


in Google SCRP.


But still, I'm trying from last six months,


and I have given lots of activities.


But still, my desired pages are not


appearing as a site link in Google SCRP.


Please let me know what can I do for this.


So site links are generated automatically as well,


kind of like with the knowledge panel.


And there's nothing specific that you can do to force those.


We try to pick up the site links based on your site's


internal navigation primarily.


So if we can understand how people can kind of navigate


your website better, then we have more of an opportunity


to show site links.


But it's not guaranteed that they will be shown.


And for most websites, I think we just don't show site links.


OK.


And what we can do to appear site link search box?


Which appear just?


Yeah.


The site link search box is something


where you can add structured data to your pages too.


But the structured data is only used when


we show the site link search box.


And it's similar to site links in that for a lot of sites,


we just don't show the site link search box.


I think it's a confusing feature because of that,


because you can add markup.


But the markup only has an effect


if we would already show something for your site.


We can't depend on the schema markup for it.


Exactly.


Thank you so much for the inclusion.


Sure.


And then, Kit.


Probably pronouncing your name wrong.


Sorry, I think you're muted.


How about?


Yes.


Hello, John.


Perfect.


Hi.


OK.


I have a question.


I hope my website have problem with redirect.


Sometimes.


I can't size in the conversation.


It's really hard to.


My old URL, my website does whole human city content


on horn about information on whole human city.


And canonical whole human city.


And I have different URL, whole human city,


and paragraph ID, district one, someone content, district one.


And other URL, this is too.


Most URL, canonical, go to whole human city.


Yeah?


Yes.


A new URL is whole human city.


And canonical, whole human city.


OK.


District one.


But when I redirect 301, from old URL to new URL,


is that I have any problem with my website for whole human


city?


I have problem when I redirect 301.


So you're redirecting a part of your website


to a different part?


Is that?


When?


To a lean, clean URL.


To clean URL.


To a clean URL.


My URL, whole human city, will have battery, so on Google.


Any problem?


You understand?


Yes.


A little bit.


It's hard.


But in general, when you redirect from one URL


to another, we try to forward all of those signals.


So if you have links to the old URL


and you redirect the old URL to a new URL, a cleaner URL,


then we will forward all of those signals


and all of those links to the new URL.


So that's, I think if I understand your question


correctly, we would pass all of that information


to the new URL.


The old URL has which parameter?


Which parameter, basic one or digital?


But it's canonical to just whole human city.


If I pass it, it means I redirect whole human city


to many URL.


Is that right?


Yeah.


Yeah, I think so I'm having trouble understanding exactly


the configuration for your website.


But in general, if there are parameters with the old URL,


that's perfectly fine.


We can also forward that.


If you have other URLs on your website


that you're not redirecting, then that's also perfectly fine


to just keep them.


So that should, I think, just work.


If I understand your question correctly.


John, the question is also in the chat.


I think it's much more clear with the structure there.


I think it's the case that there are some district-related


pages that have canonical to the main city page.


But the new structure includes a separate district page


as their own pages.


So what would happen if those parameter URLs are then


redirected to the new district pages


if they had a canonical until now to the main city page?


OK, so basically taking a set of city pages


and redirecting them to one general page, more general


page.


No, I think there was a general page in the beginning


with a few parameters for each district that had all of them


had a canonical to the main city page.


But now there will be separate pages for each district.


So if until now every parameter URL


had a canonical to the main city page,


and now there are separate pages for each district,


if they redirect from the parameter,


from those parameter pages to the new district pages,


if that will affect the main city page, I think.


Yeah, as I understand it, it's like we


would follow these redirects on a per-page basis.


And if there are individual redirects there


that take place where you have multiple pages redirecting


to one page, or if you have individual,


like this parameter URL redirecting to one clean URL,


and you have other pages that stay the same,


that's like we would all look at that on a per-page basis.


So I think if you're cleaning things up,


like for a handful of pages for different sections


of your website, that's perfectly fine to do like this.


That's perfectly fine.


Is it OK?


It's no roll-up.


Yes, yes, thank you, thank you.


I have one question, one question.


My website is classified website.


It has 100,000 content.


Yes, after two months, after two months,


this content has over time.


It means someone buys a house, someone buys a motorbike.


When they post to my website, just two weeks or one week,


they saw this.


My question is, if the content is too old,


what should I do with this?


I delete it in my website, or I delete it on my website?


Yeah, that's a very common problem.


If you have classified content, then it


comes and goes fairly quickly.


There are two approaches that people take, and for us,


they are very similar.


So one is to say the old product that no longer exists


or the page that no longer exists redirects


to the category page.


To us, that would be seen as a soft 404, which


is something we discourage, but for users, maybe it's OK.


The other is to just say this page that no longer exists


returns a 404 error, and then we would just drop that page.


So in practice, in both of these cases,


the old page would drop out of the search results,


and we would be able to focus on the rest of the website more.


So the only thing I would not recommend doing


is, for the long run, keeping the old page


and just adding a label on top saying, oh, this is obsolete.


It's expired.


Because then you have a lot of pages on your website


that Google has to crawl and first recognize,


oh, there's content here, but it says it's expired,


so I can ignore it.


So that's what I would avoid.


But redirecting or 404 is fine.


AUDIENCE MEMBER 1


Thank you.


Thank you so much.


Cool.


Yeah.


All right.


Mihai.


AUDIENCE MEMBER 2


Hey, John.


By the way, regarding the question in the chat,


I think a more general, I mean, to put it


in a more general way, is when you


have a lot of URLs doing something,


like they all have a canonical to a certain page,


and then you change it.


And all of those URLs no longer have a canonical,


but they do something else.


Maybe they're just indexable.


Maybe, let's say you have an e-commerce website


and you have a category page, and all of the filters


or something like that, they all have a canonical back


to the main category page.


But then you decide, OK, I need those filters


to be indexed or redirect them somewhere, I don't know.


And you break the canonical, and then you


use them in whatever other way you want to use them.


Does that mean that the main category page starts


to lose some of the signals that were until now aggregated


from all of those filters and things like that?


Is it kind of a balance?


You kind of gain some, you lose some?


Probably, I mean, it depends a little bit on what


you mean with signals.


Because with a canonical URL, when you specify that,


we don't take the content itself into account.


So if you have a blue car and the canonical is a green car,


then we will index the green car.


We won't know about the blue car.


If someone links to the blue car,


then we know there's a link that indirectly


goes to the green car.


But we don't know it's like blue car.


Right.


But that means that if you start making the blue car indexable


or do whatever else with it, that


means that the blue car will start gaining maybe in rankings


and get traffic, especially if it has links and everything


else.


But you're no longer canonicalizing


to the green car.


So the green car kind of loses that,


loses those ranking signals that came through the canonical


until now.


So it's, yeah, you lose some, but you


might get a lot more traffic by being more


specific towards certain queries.


I think that's always a balance that you have to figure out.


There's no absolute answer where you


can say you should always split it up


or you should always combine it.


Sometimes it makes sense to split.


Sometimes it makes sense to keep it separate.


I guess it's a lot based on what your users are really


interested in.


And if they're looking for something more specific


and you have a page that could provide a better


experience for them, then that might make sense.


So I want to ask very quickly about something


regarding Core Web Vitals in Search Console,


because the Core Web Vitals are taken from the Chrome User


Experience Report.


So the data in Search Console is taken from the Chrome User


Yet for, let's say you have a CLS issue


with a bunch of your pages, you have the option


to validate fix.


But that doesn't make as much sense


as you would validate fix on a coverage report,


because it doesn't matter if Google recroles those pages.


The data is not from Googlebot.


It's from the Chrome User Experience Report.


So that's a bit confusing.


Yeah.


We have that there for consistency reasons,


but it's based on, like you said,


the Chrome User Experience Report data.


So it wouldn't be the case that we would be able to say,


more people should click on this link,


and then we have more data to look at.


We basically have to wait for things to update there.


So it's just a kind of a display report thing


that the validate fix actually helps you just kind of see.


Exactly.


OK.


Makes sense.


Cool.


We're running low on time, so let


me just go through some of the questions that were submitted


that we didn't get to yet.


And I'll stick around a little bit longer


if anyone wants to chat for more as well.


The first one I have on top is about AMP.


I think we talked about that.


Also AMP, the ranking factor.


Will Google consider the origins field core web vitals


data for the whole domain, or will it


be ranking on a per-page basis?


We talked about that a bit as well,


kind of the different groupings that we show.


How accurate is crawled currently not indexed


in Search Console despite being a page with sufficient content


without issues?


Many pages are excluded from the site from being indexed.


That's fairly common.


So for the most part, we don't index all pages


that we know about on a website.


We have to prioritize a little bit.


So that's something where it's less a matter of,


like, this individual page is fantastic,


but more that we need to understand


that there's a lot of value to be


gained from showing your website more visibly in search.


And that's something that's more of a long-term process,


unless something on a per-URL basis where you can say,


this page is good now.


For passage indexing rolling out,


does passage indexing relate with core web vitals


for ranking or indexing factors?


No, that's something completely separate.


Also, passage indexing is a kind of a bad name.


I hope the people who decided on calling it indexing


don't listen.


But it's not based on indexing.


So nothing changes with indexing.


It's really based on ranking, so understanding


what is on a page and how to show that in the search


results.


Does the URL parameters tool in the old Search Console


still work?


When will the new version go live?


Yes, it continues to work.


I don't know of any date with regards to new version.


I think that's one where we're talking with the team


to figure out what the right approach is there.


And it might be that at some point


we decide, well, it still works, but it's not


as valuable for all users to actually migrate


to the new version of Search Console.


And maybe it'll go away at some point.


Maybe it'll be migrated in a different way.


Maybe it'll be taken over one to one.


I don't know.


How do the core web vitals interact


with AMP site enhancements?


I think we talked about this as well.


We have two regional sites under different subdomains, one


in German for the German region, one in English for the US.


We kept the URL handle of our products


the same for easier forwarding, but this


means that the URLs in our US store are in German.


Is this a problem for search ranking in the US?


No, it is definitely not a problem.


We use the words in a URL as a very, very lightweight factor.


And from what I recall, this is primarily something


that we would take into account when we haven't had access


to the content yet.


So if this is the absolute first time we see this URL,


we don't know how to classify its content,


then we might use the words in the URL as something


to help rank us better.


But as soon as we've crawled and indexed the content there,


then we have a lot more information.


And then that's something where, essentially,


if the URL is in German or in Japanese or in English,


it's pretty much the same thing.


The only effect where I would worry about this a little bit


is that users might be a bit confused


if they're copying and pasting your URL,


if they're recommending it to other people.


Then if the URL is in German and it doesn't make any sense


at all to them, then that might be something where they're


like, what is this URL actually about?


Usually, if it has product names in there or descriptions that


have very similar words in English and German,


then that's less of an issue.


But if the URL were in Japanese and the users were in the US,


then that could be something where they're like, what am I


actually forwarding to my friends here?


But that's not an SEO factor.


That's more of a marketing issue.


I work on a big news site, and some parts of the articles


are blocked from the user until they click the Read More button.


For the Google user, by default, let's see,


it's not blocked behind a login page,


and we show Googlebot the whole article.


So in general, I don't think this is really problematic,


but it might be worth thinking about whether or not


this should be used with the paywall structure data, where


you can clearly specify this part of the page


is visible by default and this part isn't.


I think probably paywall would be not perfectly suited


for this.


And probably, if this is really something where you just


click a link on a page and then the CSS switches over


to show more content, then that feels like something


where, from Google's search point of view,


we wouldn't really care.


It might be that your users are a bit annoyed by this,


but that's more of a usability issue on your side


and less of an SEO issue.


Does the structured data from YouTube carry through embeds?


For example, does the structured data


need to be recreated on the page that embeds the video?


So if you're using something like an iframe,


then we can definitely understand a little bit


about what's happening within the iframe


and associate that with the page itself, which


could be something like the title of the video,


for example, on YouTube embed.


But I would strongly recommend using normal video structured


data on a page as well, because you don't want


to rely on this vague, Google might be able to figure it out


thing, but rather, you want to really clearly provide


that structured data to Google so that Google can show


your pages as proper video landing pages,


because it has all of the information


that it needs there.


So that's something we definitely


can carry some things over.


But for optimal video implementation,


for video optimization in search,


I would use the normal video structured data.


Why in the crawl stats report in Search Console


there are also very old URLs that are sometimes


crawled for discovery and not for refresh?


I don't know.


I'd have to take a look at some of the examples


to see a little bit more about what actually is happening


there and chat with the team.


But I wouldn't necessarily worry about this difference.


It's something where I think splitting those parts out


makes it easier to understand that Googlebot is actually


refreshing a lot of your pages and that it's


normal for it to access pages that have been the same


for a longer period of time.


But I wouldn't worry about individual URLs falling


into one bucket or the other bucket.


Will the ranking boost from core web vitals


be based on the mobile or the desktop numbers?


We announced that the core web vitals, or rather the page


experience ranking factor, would apply to mobile and not


to desktop, at least initially.


I don't know what the long-term plans are.


And my guess is at some point we'll figure things out


a little bit more fine-grained.


But at least the initial announcement that we made


is based purely on the mobile side.


And that's also where, for the most part,


I think the harder barriers are, where users really


see things a lot slower than on desktop.


Because on desktop, you tend to have a really powerful computer


and you often have a wired connection.


And on mobile, you have this much slimmed-down processor


with less capabilities and smaller screen and then


a slow connection sometimes.


And that's where it's really critical that pages load very


fast.


Search console data question.


Data on the Search Console UI is slightly different


than from what's pulled from the API.


And the data in the UI looks more approximated.


Is the data pulled through the API more accurate?


So both of these sources are based on exact same databases


internally at Google.


It's not that we have one set of data for the API


and one set of data for the UI, but rather it's the same data.


It's available in different ways.


And depending on how you query the API,


you might see slightly different numbers.


But essentially, it's exact same data.


If a domain organizes its international sites


and subfolders, would Google crawler


have an issue with different international sections


on a site using different page templates or navigation?


Since a site navigation template consistency


has been mentioned before as a factor in SEO,


that's perfectly fine.


So we do try to understand the templates of a page


and to understand which parts of the page


are the primary content and which parts are more


boilerplate, like everything around it, the menus,


the footer, the titles, things like that.


But we can pick that up for different parts of a website


in different ways.


So it's not that the whole website


has to have exactly the same template.


Most websites don't.


The thing I would watch out for, especially since you mentioned


international sites, is if you're using hreflang


and you have very different infrastructure


across the different language versions,


then it makes it really hard to link those pages together


with hreflang.


It's not so much that Google would have trouble with it.


But if you can't specify the hreflang yourself


on those pages and you want Google


to understand the connection between the language versions


or the country versions, then that just


makes it a little bit harder.


But purely from an SEO point of view,


if you can create proper hreflang,


if these pages are normally crawlable and indexable,


then I wouldn't worry about that.


OK.


Wow.


So many questions and so much more left.


But maybe I can take a break here, pause the recording.


And if any of you want to stick around longer,


you're welcome to do that as well.


Thank you all for listening in, for watching,


for asking so many questions.


It's like, wow, so many hands are still up.


So many questions still in.


It feels like we could do these for hours and hours.


But then I would probably, I don't know,


fall into the ground or something


afterwards, which would be unfortunate on a Friday


evening.


Cool.


Let's take a break here.


I'll pause the recording.


And like I mentioned, if any of you want to stick around,


feel free to do so.


Otherwise, have a good weekend and maybe see you


in one of the next sessions.


Thanks, John.


Goodbye.


Cheers, John.


English Google SEO office-hours from April 23, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


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


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


where people can jump in and ask their questions around search,


and we'll try to find some answers.


As always, a bunch of stuff was submitted on YouTube.


We can take a look at that.


And maybe to get things started, we


can take some live questions as well.


I see, Bhushan, if I got your name right,


you have your hand raised.


Do you want to get started?


Hi.


How are you?


How are you doing?


Pretty good.


Let me just see.


Bhushan, are you here somewhere?


Yes, John.


Could you give me one minute?


I'm just dealing with something else.


OK.


Sorry.


Let me take the next one first, then.


Eric.


Yes, hello again.


I noticed that you rolled out a new feature in the Search


Console, some page experience tab.


And I wonder, there's a counter of views,


and I can't correlate it to any other metric.


For us, it shows like 12 millions of views.


But then in the SERP tab, which was


used in the search results, it's like three times as much.


So what does this number correspond to in a page


experience?


I don't know offhand without taking a look.


But my understanding is the number of impressions


that we show there are specifically for the pages


that reach the good threshold.


So the pages that we can classify in that good bucket.


And if a lot of your site is in the good bucket,


then probably a lot of your pages will be in there.


But if parts of the views do not map into that good bucket,


then that's probably that difference


that you're seeing there.


Yeah.


It shows 100% for us.


So does it mean all of our pages are OK?


It sounds like it.


That sounds pretty good.


Congratulations.


Thank you.


It's a lot of work when we hit that.


But it's still like only a third of what we get in the SERP tab.


I don't know if those are meant to map one to one.


I'd have to ask.


OK.


I don't know.


Sometimes it's something like two times as much.


On some days it's like 3 and 1-2 times as much.


I mean, it shows the net SERP tab.


Could that be the mobile users versus the total users?


Yeah, it's all the users.


That's still too much, I think, of a difference.


Anyway, OK.


Thank you very much.


And I have another question.


Sure.


Thank you.


In the Courage tab, I'm sorry, no, not Courage.


Where is it?


Yes, usability.


Yes, mobile usability, I think it is, or something like that.


Sorry, no, Core Web Vitals.


I'm sorry.


Core Web Vitals.


And for the past two years, the way


we've been trying to optimize for Google,


the graph that's there to show you the good pages


and the pages that need some attention,


it's been steady for those years.


But in the past two months, it just


started going up and down.


And I don't know.


I thought it was something to do with the crawl budget thing.


But I don't know.


We have zero bad pages.


We have zero yellow ones.


All of our pages are in green.


But it went from 45,000 to 27,000.


And now it's 30,000.


So I wonder why that is.


Yeah, I think that's a bit confusing.


So basically, what happens in the aggregate reports


is that we show the information from a significant sample


of the pages of the website.


And depending on the website, that can be almost all pages.


Sometimes it's less than all pages.


And that sample can change over time.


So for example, when you're looking at speed,


if your pages do not change with regards to speed,


you might still see the number of pages going up and down


there, and that's just based on us using


a slightly different sample.


So essentially, what you should watch out for there


is the errors that are mentioned there.


And look at a sample of those errors that are mentioned


and work based on that.


I wouldn't assume that the total number that


is shown there in these aggregate reports


maps one to one to the total number


that you have in index coverage, for example.


Yeah, that's right.


It's a lot less.


OK.


OK, thank you.


Sure.


Prushan, are you ready?


Actually, it was regarding to the crawlability issues.


The answer is already covered by you.


So I'm done.


Thank you.


Fantastic.


Cool.


Rahul?


Hi, John.


Hi.


So I'm having multiple questions.


The first question is about 301 redirect.


So my question is that I have implemented 301 redirect


for a page, and it's working fine.


The page is being redirected to the new URL.


But the thing is, Google is not selecting the new one


as a canonical URL.


And it is indexing both the pages as two different pages.


So what can be the, should I do anything externally


to provide that this is one, the new URL is the one


as canonical or anything like that?


Yeah, so when it comes to canonicals,


we essentially recognize that these two pages are equivalent.


And then we try to pick one of them


to show in the search results.


There is no ranking advantage from having this one


or the other one shown.


It's purely a matter of which one


is shown in the search results and which one is used


for attribution in Search Console.


So it's not super critical.


But when it comes to canonicalization,


we use redirects as one signal.


But we also use other signals as well,


like internal links, sitemap files, external links,


all of the annotations that you have across your pages.


All of that can play in.


And it can happen that you redirect one page


to another page, but our systems say the canonical should


remain the original URL.


And the way that you can help us to switch that over


is to just make sure that everything is aligned,


that all of your internal links are pointing at the new URL,


your external links are pointing at the new URL


in the sitemap file, and all of the annotations that you have,


you always point to the new URL.


And then when we look at the bigger picture, we see, oh,


it's pretty clear.


You want that one indexed, so we'll focus on that one.


But like I said, there is no ranking change or anything.


So it's not that there's anything critical


that you need to do.


SPEAKER 2


Another question is that I've come across a video of Matt


Kurtz for link building.


That video was uploaded 11 years ago.


So my question is that in the video,


he proposed that if we do answering questions


on forums or communities like Quora,


it can help building authority or kind


of backlinks for your site.


So is it helpful in this video also?


I don't remember what all Matt said.


So it's hard for me to say.


In general, a lot of the sites that use user-generated content,


they use a nofollow on all of their links.


So it's rare that you would get any kind of advantage out


of that.


It's also something where over the years,


we've seen that people try to abuse this for link building


and that they'll go to forums and just


add random unrelated comments and add their links there.


And that's something that we would


recognize as being kind of almost like borderline spammy


behavior.


SPEAKER 3


One more question.


We are having a product paid in that we


are having multiple products on the same category.


So what is happening is all the products,


almost we are having 10 parameters for every product.


And almost eight parameters are remaining


same for every product.


So my question is, does Google consider it as thin content


or anything like that?


Because we are not changing all the parameters.


No, it sounds essentially just like you


have different parameters.


And some parameters are not critical.


And usually what happens is we learn


which parameters are not critical,


and we tend not to focus on them.


You can also tell us about that in the URL parameter handling


tool if that's something where you have a clear map of which


parameters are actually important


and which ones aren't.


But it's not thin content.


OK, thank you.


Sure.


Melissa.


Hello.


Hi.


I am a director of engineering for the Atlantic


and have a couple of questions about AMP and Google


News for you.


OK.


I'll try.


I don't know everything around Google News.


So.


I might be the wrong person, but we'll see.


I'm curious because we've got the JSON-LD for the news


article rich results on all of our pages.


And we're seeing some different things


between the news.google.com results for articles


and the default search.


And so I was wondering if they use different algorithms


or pull metadata from different places to populate the news.


Different places to populate the results.


I don't know.


That's OK.


It sounds like we are based on what you've seen.


So for the most part, we would crawl the same way


for news and for web.


But it is very possible that depending


on how we need to process that information,


that we have slightly different pipelines from there.


So I could imagine that there might be subtle differences


in that regard.


Cool.


OK.


That makes sense.


And then I just have another question


about mobile results right now with AMP


and obviously ramping up on the core web vitals.


And I've noticed this on other news US publications results


that the AMP and their core site, the results are mixed.


So it's not all AMP articles or it's not all kind


of the mobile web experience.


So I was wondering, in this interim period between now


and when core web vitals become the main signal for results,


where should we be focusing?


Where should publishers be focusing


on improving the AMP experience or improving core web


vitals for ranking currently?


Essentially, core web vitals would apply to both.


So when it comes to the core web vitals, especially the speed


aspect, whether the largest contentful paint,


cumulative layout shift, and first input delay,


those metrics, we would use the pages


that users actually see in a search result.


So that's based on the field data.


And if users are seeing the AMP pages in the search results,


then we would base those metrics off of the AMP pages.


If users are primarily seeing mobile web results,


then that's what we would base those metrics on.


And from that point of view, if you're


seeing that your AMP pages, for example, are slow on mobile,


then that's what I would focus on to kind of improve


that what users are actually seeing.


It's less a matter of we will not show AMP pages later on,


because we'll continue to have AMP pages.


It's really just from the speed point of view,


we take into account that what the users actually see.


SPEAKER 1 Got it.


OK.


That makes a lot of sense.


Thank you so much.


JOHN MUELLER Sure.


Thanks.


Syed.


SPEAKER 2 Hello, John.


How are you?


Hi.


Hello.


Hey, John.


John, my question is regarding an e-commerce site


which has a product and has descriptions.


And those descriptions are very much


similar to the manufacturer descriptions.


So I just wanted to know how important is it


to write something unique which includes the same thing,


or probably I should go with the manufacturer's descriptions.


So I came up with this question after reading


the blog on product reviews, where the last point says,


describe the key choices in how product has been designed


and their effect on users beyond what manufacturer says.


So if you could please clarify this, it would be great, John.


Yeah, so in a normal e-commerce shop,


you're not essentially creating review pages.


You're creating these product pages.


So from that point of view, I think


looking at the guidance that we have for product reviews


is good, but it's not critical because that's not really


your primary focus.


But when it comes to the description on a page


or for products, it's something that we do take into account.


And essentially what happens is we


will index the different pages because the different shops


that have the same product, the pages themselves are unique.


They have extra other information


around the product description.


But if someone searches specifically for something


within that shared description, then we


will pick one of these pages to show because we think,


oh, these other ones have essentially


the same information.


So from that point of view, if you have something


unique around your pages, then that already


helps us a little bit.


Having unique descriptions on their own,


that also helps us a little bit to make sure


that we're showing your pages.


But it's not the most critical thing.


In particular, if there are aspects within your shop that


make it unique on its own, like if you're


located in a specific location and users search


for that location plus the product name,


then obviously it doesn't matter if your descriptions are


the same as other people's because your shop will


be the most relevant one.


So that's kind of my advice there.


I think if you can make unique descriptions,


that's always worthwhile.


But depending on the type of shop


that you have, the number of people


that you have working there, sometimes it's just not


realistic to do that for everyone.


But depending on the type of shop that you have,


it's just not realistic to do that for everyone.


OK, cool.


So we have an online e-commerce flow.


So probably what I can, let me just


confirm my understanding, what it's like.


Probably it's something like it's


great if you could make unique.


Yeah, I think it's a good practice.


It's not critical.


Yes.


OK, OK, OK.


Thanks, John.


Thanks for answering that.


Sure.


Jeremy.


Hi, John.


Just for some framing, I work for Pueblos's Health Media.


So we're dealing with a lot of larger pharmaceutical


and health care clients.


And we've had a number of them come through and ask


about personalization technologies that


leverage JavaScript to change the experience on a page based


on the user's referring path.


So if they come through from a certain condition area,


they land on a certain page, it might alter


some of the calls to action or some


of the multimedia on the page.


And that's a half measure that we've come up with,


because initially they wanted to change everything on the page.


But we were concerned about how Google


might perceive that both from a cloaking perspective


or from a perspective of JavaScript crawling


and not seeing everything initially, that kind of thing.


So I'm just curious about whether you


can put a stamp on that to know if there's


any sort of best practice around that or what sort of guidance


we need to point them at, whether it's the cloaking


guidance or things like that.


Yeah, I think the cloaking guidance is definitely


worthwhile to look at.


We also, I believe, have some guidance on A-B testing


in general.


So I would take a look at that.


In general, with regards to JavaScript-based A-B testing,


we don't necessarily differentiate


between JavaScript and other kinds of A-B testing.


We can render some JavaScript.


So it's possible that we would fall into one of these A-B


tests and then just see that version.


And then we would use that version for indexing.


The one thing I would watch out for with regards to A-B tests


is that Googlebot has a fairly persistent view of the pages,


not that it changes every time we crawl the page.


So if there's a way that you can put Googlebot into one bucket,


then that makes it a lot easier for us


to have kind of a stable view of your page.


Shifting things around, like call to actions,


changing colors, designs, things like that,


that's absolutely no problem.


If you were to significantly change


the focus or the purpose of the page,


then I think that would be something that would fall more


into the cloaking area.


And that would be something where


from the web spam, from the quality side,


people would be kind of upset with that.


But if you're just tweaking things, that's perfectly fine.


The other thing maybe to mention is


Googlebot doesn't keep a refer.


So if you're doing A-B tests based on refer,


we would just not send anything back.


OK.


And just for clarity, it does look like A-B testing


technology to me, but they're looking


to use it in a permanent fashion.


Is there a problem with that over the A-B testing


end of things?


Not necessarily.


So if you're tweaking things, I don't see a problem with that.


If you're, again, if you're significantly changing things,


then I would just make sure that Googlebot sees


the primary version of the page, not


that 90% of the users see one version,


and Googlebot alone sees something different.


But usually, that kind of falls into place anyway.


And just for my own clarity, when you're saying,


we can do user agent kind of funneling Googlebot


to another area, and that's not perceived as cloaking?


I mean, technically, that falls into cloaking.


But essentially, what you want to avoid


is that Googlebot regularly jumps into different buckets


when you're doing this kind of test.


And from that point of view, some people


do do it by IP address or location or username


or something like user agent.


But essentially, the idea should be that you're not


special case in Googlebot, and Googlebot alone


is going this way, but rather, there's


a whole group of people going this way,


and it includes Googlebot.


OK.


Cool.


Thank you very much.


Sure.


GK, I think.


Hi.


Hi, John.


Recently introduced Google Search Console page experience tab


source.


Our website has 98.8% URLs with a good page experience.


But core webinar tab shows that 10.8k failing URLs.


I can't understand what it shows.


Kindly explain.


So the page experience tab takes into account


the core web vitals plus all of the other factors.


So that's why you might see a slight difference with regards


to those two.


And it might also be that the basis out of which the pages


are counting are slightly different in those two


reports.


So that's something where usually what I recommend doing


is with these aggregate reports is


trying to recognize the issues, the problems,


and focusing on those and not using


the total count as a metric.


OK, thank you.


OK.


Valpav.


Oh my gosh.


Hi, John.


I have a blogging website, and it


was ranking on number one or two position in many keywords.


But after the Google product review update,


my website ranking was down to 10 or 11 on the same keyword.


So my question is, how can I improve my content according


to the Google product review update to regain my position?


It's hard to say without knowing your website.


So that's kind of first off.


What I would recommend doing is double checking the blog post


that we have with all of those tips on there,


and also double checking some of the external blog


posts that were made around the product review update, where


people bring in some more information from things


like the quality rater guidelines


and some of the other aspects that could also


play a role with regards to review-based content


or content that might be perceived


as being focused on reviews.


If you can explain about the Google product review update,


because there's a lot of confusion related to it.


I can't go through all of the details here.


I would really recommend taking a look at the blog post,


because it's pretty comprehensive


and has a lot of information in there.


Thank you so much, John.


Thank you.


Sure.


Divakar.


Yeah, hi, John.


I'm from New Delhi, India.


Hi.


So my question is related to international targeting tool


under Search Console.


From last few years, I am seeing that this tool


comes under legacy tools category in Search Console.


And when we try to access this tool,


then it will redirect us to the old version of Search Console.


So just to know better about this tool,


just to know the future about tool,


I just wanted to know that is Google,


is the importance of the tool still the same


as it was previously?


Or Google wanted to retire this tool in future sometime?


I don't know.


It's still in Search Console, so it's still supported.


I would continue to use it.


It's not something where we say we're


going to remove it completely, because we would have removed


it already.


I don't know what the near-term future is.


If we will update it, or if we will decide in the end


that maybe we don't need it as much as we thought we would,


It's hard to say.


But its importance is currently same as it was previously?


Yes, exactly.


It still works.


It's still functional.


OK, OK.


Perfect, perfect.


Thank you.


Thanks a lot, John.


Thanks.


Ruchika.


So hi, John.


So this is Ruchika from Ahmedabad, India.


So my question is, usually a site page or a site ranking


do depend on how stable the site is.


If you make frequent changes on the site,


the ranking goes down, right?


Not necessarily.


Just because you make changes doesn't necessarily


mean it's worse.


It shouldn't go down the ranking.


Actually, we recently made many changes content-wise


and also designing-wise, we have made some changes.


And yeah, our ranking has gone down a lot, from 11 to 30,


I would say.


Yeah.


I mean, if you make changes on your website, then in search,


we will try to reflect that.


And if our systems, when they look at the new website,


see that everything is better than before,


we will try to rank it better.


But if they see that things are maybe not as good as they were


before, then it can happen that it goes down in ranking


as well.


So in particular, if you do things


like changing the layout in a way that


changes the internal linking within the website,


then that's something where we would look at that and say,


we can understand the structure better,


or maybe we can't understand the structure as good


as it was before.


And that can have a pretty visible effect on the rankings.


So it doesn't make any sense, because we have just


made some recent changes like content,


like adding more keywords and making the pages more appealing,


like the product page.


Yeah.


I don't know.


Yeah, it's hard to say what you made,


what kind of changes you made, and how that worked out.


I am kind of worried when you say we just


added more keywords, because that sounds like keyword


stuffing almost, and kind of going in that direction.


But it's really hard.


What I would recommend doing there


is taking a sample of the pages from your website


and maybe converting them back to how they were before,


and then seeing if that change in content


was really the issue that changed things for rankings.


And then based on that, you can decide what you need to do.


OK.


Thank you, John.


Sure.


Let me run through some of the submitted questions for a bit,


and then I'll get back to the live questions as well.


Wow, so many people, so many questions.


Let me see.


What contact information is it better


to indicate on the author's page, social network accounts,


email addresses, or both?


If we can choose only one option, what is more preferable?


So I thought that was actually a pretty interesting question.


I don't think we've run across this before.


So essentially, what I see on our side


is when it comes to things like author pages or information


about the author or information about entities in general


behind a website, an article, or something, what happens there


is our systems try to recognize who that is,


what that entity is.


And we do that based on a number of different factors.


And that does include things like links to profile pages,


for example, or visible information


that we can find on these pages themselves.


So my recommendation here would be


to at least link to a common or kind of like a central place


where you say everything comes together


for this author, which could be something


like a social network profile page, for example,


and use that across the different author pages


that you have when you're writing so that when


our systems look at an article and they see an author


page associated with that, they can recognize,


oh, this is the same author as the person who


wrote something else.


And we can kind of group this by entity.


And we do that based on maybe this common social networking


profile that is there.


I don't know.


Long ago, we used to have the rel author annotation.


And all of the older SEOs will probably facepalm now.


But it's something essentially where


we try to use structured data to explicitly apply this.


But it is something that like the rel author annotations


are no longer used at Google for quite a while now.


But we do try to understand who the entity is


behind an author page.


And for many authors, it's pretty clear.


There's one name.


And it's very obvious this one name


is associated with this one person.


For other people, it can be a little bit more complicated.


Like me, for example, John Mueller.


If you search for me, you'll find Wikipedia pages, barbecue


restaurants, bands, all kinds of people


who are called John Mueller.


And if on my site I don't kind of specify who I actually am,


then it could happen that our systems look at my pages


and go, oh, this is that guy that


runs that barbecue restaurant.


And then suddenly, I am associated


with a barbecue restaurant, which I don't know,


might be a move up.


I don't know.


But these subtle things, I think,


make it a lot easier for us to recognize who


is actually behind something.


We call that reconciliation when it


comes to structured data, kind of recognizing


which of these entities belong together.


Then a question about meta title and meta description.


Google is showing the same title tag but the wrong description.


And automatically fetching data from my website,


how can I correct that?


So essentially, we try to use the information


that you have on your pages when it comes


to titles and descriptions.


But when our systems recognize that maybe this information is


not as useful to users as possible,


then we will tweak that.


And we can show different titles and descriptions


based on the query.


So that can vary from time to time.


The best way to work on making it


so that Google does take into account your title


and description is to make sure that you're following Google's


guidelines with regards to titles and descriptions.


And in particular, making sure to avoid keyword stuffing,


making sure to avoid making it overly clickbait-y,


the title and description, so that it's really


something where our systems, when they look at it, say,


oh, this is a good recommendation for this page.


We will show that one.


We still use the title in our search in ranking systems.


Even if we've modified it in the search results,


we don't use the description at all when it comes to ranking.


It's really just what we would show in the search results.


How can I deal with missed redirects


for moving from HTTP to HTTPS?


Does it make sense to catch up now?


I'm new at the company, and back then they missed to do this.


Is it now too late, or should we still do it?


I would definitely still do that.


So especially when it comes to HTTP, HTTPS,


having that redirect in place, make sure


that everyone is going to your HTTPS version.


And then you can also set up HSTS,


which is a way of automatically sending people to the HTTPS


version of your site.


So even if you didn't do it back then,


I think just purely from a user best practice point of view,


it makes sense to set up those redirects.


I don't think you would see any visible effect when


it comes to SEO, but really just from a user's point of view,


it's still a good practice, even if you


didn't do it in the beginning.


We've been working on improving our page speed scores.


LCP lab data and field data are below 2.5 seconds,


but Core Web Vitals still lists many pages as failing.


Running revalidation doesn't help.


Additionally, the number of failed pages


changes erratically for no reason.


It drops from 160 to 90 and then jumps up again a bit later.


So the number of pages, as I mentioned in the beginning,


that could be just based on the sample


that we look at for your site.


And that sample size can vary over time.


So that might be something that's less relevant to worry


about.


I would focus more on the number of issues that are found,


and in particular, the kind of sample URLs


that are shown there, the patterns that are shown


for the individual issues.


With regards to page speed scores versus Core Web Vitals,


I assume this is in Search Console,


because it's essentially using the same thing.


In Search Console, we use the Chrome User Experience


reports, the field data, the real user metrics.


And they take, I think, 28 days about to be updated.


So as soon as you make changes on your website,


and if they're visible enough that users would see them,


then it takes that 28 days before we even


start to see a slight change in those metrics.


And even then, you would not see that change jumping up


immediately, but rather you would


see more of a subtle climb over time as things settle down


with the new score.


So that might be something that you're seeing there.


The other thing that commonly pops up


is the difference between lab data and field data.


Essentially, with lab data, you're


doing an approximation of what users might see.


And that approximation might be wrong,


because we don't know where your users are, what


they would actually see.


And because of that, it can happen


that the approximation looks good,


but the user data looks bad.


Or similarly, the approximation looks bad,


but the actual user data is pretty good.


And that's why you do sometimes see those differences.


In general, when it comes to optimizing things for speed,


I recommend using the user data, the field data,


as a way of recognizing broader areas of problems


and then using the lab data to incrementally improve


your website in that regard.


So if you're seeing, for example,


that CLS is really bad in the field data,


then I'd recommend looking at the lab data for CLS


and trying to figure out how can you significantly


improve that.


Maybe the numbers don't match up completely,


but you do see those differences in the scores over time,


where if you're improving your website with the lab data,


then you would assume that at some point


that improvement will also trickle down


to the field data as well.


And sometimes that just takes a while.


So it's a matter of patience, but also


a matter of trying to find the right things to work on.


Let's see.


Is it common to see URLs of images


in crawled currently not indexed report in Search Console?


The URLs return the correct file header for a JPEG,


but they don't contain a JPEG extension.


Yes, that can happen.


So essentially, we have some heuristics in place


to recognize when you're linking to images.


And when we can tell that a link goes to an image,


then we will say, oh, this is probably an image,


and we will process it in image search.


And we won't even look at it for web search.


However, if we can't recognize that it's an image,


then we'll try to crawl that URL for web search,


and then the crawler will say, actually, there


was no web page here.


And then within web search, we'll say,


oh, we weren't able to index this page.


And that's not necessarily a bad sign.


It's just essentially us telling you,


we tried to crawl these URLs, and we just


didn't get a web page out of it.


And from that point of view, it's


more of an informational thing for you to understand,


well, Google tried to crawl.


So you'll see it in your logs, but they weren't actually


indexed as web pages.


Probably they ended up being indexed


as images, which is something you'd


have to kind of try to figure out almost indirectly,


because we don't have the same index coverage


report for images as well.


But you could see, maybe in the performance report,


which landing pages are showing images,


and then you can double check to see


what is actually shown in Google Images for those pages.


So I think one of the things that I would take out of this


is, if you're seeing issues with regards


to your images being indexed, and you


know they don't have image extensions,


then it might be worthwhile to swap those around and make


it at least look like they have image extensions,


so that we can process them immediately with Google Images,


rather than going through web search and then thinking,


oh, they're not web pages, maybe they're images,


and we'll try that there.


For a particular page, I discovered in Search Console


that it has poor LCP on mobile, except the LCP,


no other Core Web Vitals are reported as poor or bad


for the same URL.


But calling the PageSpeed Insights API,


I saw that according to the field data,


the page also has a bad CLS score.


Why is that not shown in Search Console as well?


I don't know.


It's really hard to say on an individual URL basis.


What I would recommend doing is not worrying too much


about individual pages, unless they


are very critical and important pages for your site,


and instead focusing on the broader


pattern for your website.


So for example, if you have a template for your blog,


and there are individual pages that are not OK,


but overall, most of them are OK,


then I would see that as something


like probably that's OK.


On the other hand, if you have for your main product


a very unique landing page, and that is not OK with regards


to these Core Web Vitals, then that would be something


that I would focus on.


But especially when you're looking at individual pages


across the different tools, you need


to keep in mind that the tools have a different databases


in the sense that the report in Search Console


is based on groups of URLs.


The reports in PageSpeed Insights


are also kind of based on the information we have for one


URL, plus for the origin overall, plus the lab test


as well.


So all of these reports could have slightly different bases.


Yeah.


In general, I think it can get very tricky


when you're looking at individual pages like this.


My recommendation is really to kind of try


to take a step back and look at the overall patterns


rather than focusing too much on individual pages,


especially if those pages are part of a common theme


that you have across your website.


Let's see.


And there's a question, another one about Core Web Vitals.


Wow, everything.


We've done everything we could to get the lab data


below the required numbers, however field data is still not


changing.


Again, there's the time difference


that is there on the one hand, and on the other hand,


the factor of the lab test being an approximation.


Essentially, they're guessing at what the field data might


be for an individual score based on specific assumptions


that they make, like with regards


to how fast the connection is, what kind of a device


it might be, all of these things.


And all of that can vary from site to site,


depending on where the users are,


what kind of devices they have, what connections they have.


So that's something where I would use the lab data


to incrementally improve, but I would


use the field data as kind of the basis of truth


for the site.


What you can also do if you don't have time


to wait those 28 days or so for the field data


to start updating is you can annotate your pages


with a specific JavaScript snippet


that you can use to make it so that you can track the Core Web


Vitals of those individual pages in something


like your analytics system.


And there are various snippets that we


have on web.dev, our developer site for Chrome,


where you can add some JavaScript to your pages


and then track the CLS, or you can track the largest content


full paint, all of those things.


And you can track those then in analytics.


And then fairly quickly, you start


seeing were these changes OK, were the changes not OK.


You can also compare different individual pages.


If you have ABC versions of a page


where you're making individual changes


and not sure which one is the best,


then you can track that a little bit faster as well.


Is it possible to rank a single page website?


Yes, absolutely.


So it doesn't need to have a lot of pages on a website.


We can rank a website that consists of a single page.


My general recommendation when you're working on a website


is to try to build out one website


and make it as strong as possible


and to grow that over time rather than to create


a bunch of disconnected single page websites.


But sometimes you just want something completely separate


that maybe you use as an advertising landing page


as well.


And that can absolutely appear in the search results.


It can absolutely rank fairly well as well.


For a while, it was very, I don't know,


fashionable to have single page websites, really long pages,


kind of these longer experiences.


But it's totally up to you.


You can try it out.


My mobile URLs have an LCP problem,


but not in the AMP version.


The mobile search results have already have AMP URLs.


So can I just ignore the LCP issue?


Maybe.


Maybe you can ignore it.


So like I mentioned in the beginning,


we use the page that is actually shown to users


as the basis for tracking these things.


So if you have valid AMP pages and we're always


showing the valid AMP version to users


when they search on mobile, then that's


what we will take into account.


Whereas if you have an AMP version


but it's not a valid AMP version,


so sometimes we don't show it as an AMP version in the search


results, then we would take whatever page


that users see in the search results


and use that as the basis.


So that's kind of the different things there.


With regards to connected AMP pages,


one of the things to keep in mind


is that we would fold those scores together.


So on the one hand, if you have something like a slash AMP


page and a slash web page, we would fold those scores


together.


And also, the score that we would have from the AMP cache,


if we're serving your AMP page from the AMP cache,


we would also fold that together and kind of make


one score for that page based on the canonical itself.


So that kind of comes together there.


And if we're always showing your AMP pages,


always showing them from the AMP cache,


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


The other thing to keep in mind is


that we track this data not based


on what is shown in search results


and where people click from the search results,


but essentially based on what people see when


they are within your website.


So if they go to your AMP page on the AMP cache


and they click on a link and all of the links


lead to your traditional mobile page,


then suddenly they're on the mobile page.


And the experience that they're seeing


is based on what they see on the mobile page.


So that's kind of that mix of AMP cache, AMP, and mobile page.


That's something that you can also kind of control


a little bit with regards to how you set up


your internal linking.


If you link your AMP pages with your AMP page,


then they'll probably stay within the AMP version.


Whereas if you link your AMP pages


to your traditional mobile version,


then it's very likely that if someone stays on your site


for a little bit longer, which is usually a good thing,


that they end up on your traditional mobile version.


Yeah.


So we're kind of running low on time.


Maybe I'll switch to one or two more questions from you all.


I also have a bit more time afterwards.


So if any of you want to stick around more off the record,


then welcome to join in as well.


Let's see.


From names, like with the hands, Shao, I think you're next.


Well, I think Ruchika first before me.


I think she already asked before.


Oh, I see.


OK, thank you.


So my question is about Google product review.


So I'm just wondering if the demand that we post


at that review matter, because previously you


mentioned the product review content is


optimized for professional product review.


So for example, what I mean is that if I am Apple.com


and I write a review about a different computer,


it will obviously be biased compared


to more like seemingly neutral site, like consumerreported.com


or something like that.


So would Google rank something that seemingly less biased


websites product review higher than, say,


a brand write an article about their product


or even compare their product to their competitors?


I don't know.


My guess is there will be some kind of a mix, where


we take the different kinds of reviews into account


and then rank them like that.


I don't think we would have something explicitly saying


that this review was written by the company that actually made


the product, therefore we should ignore it.


But I really don't know, because it can also


happen that the company that makes the product has


a collection of fairly serious reviews by more


neutral providers.


But I don't know.


AUDIENCE MEMBER 1 So if I am the brand, I can write both


my own product and my computer's product


and posting on my own domain, and they can potentially


still rank high.


It's possible, yeah.


I see.


Thank you.


Thanks.


Sure.


All right, Sanjay.


Hi.


I have another question about Core Web Vitals.


We receive traffic from three devices, tablet, mobile,


and desktop.


So my question is, will Google consider tablet data


in the rankings or not?


I think at the moment, we don't.


Especially for the Core Web Vitals,


we only differentiate between mobile and desktop.


And we only plan on only using mobile,


at least for the moment.


So it's possible that can change over time.


But at least the current plan is only on mobile.


OK.


And I have another question about e-commerce.


If we create a master page for the pages,


like a mobile phone with 128 GB, 256 GB,


and we create a master page for all of those variant pages


and canonicalize variant pages to the master page, right?


And if a user searches for the variant page,


will Google show our canonicalized page?


Probably, yes.


If we follow that rel canonical and we


focus on the canonical page, we will only


show the canonical page.


And we'll only be able to rank and index


that based on the information on the canonical page.


So for example, if on the canonical page


you say we have three variants, one, two, three,


and you just link out to the different variants,


and then on the variant page you say, well,


this is the blue iPhone and this is the green iPhone,


if someone searches for blue iPhone


and those words are not on your combined page,


then we will probably not be able to rank that page.


So the things that you want your users to be able to find,


you should make sure that it's also on the canonical page.


OK, can I ask another question?


So when I use the Lighthouse tool, it suggests us to use


no-refrer, no-opener for outlinks, for external links


that we are providing, outcome links.


No-opener can help us in this.


Can you help us understand what is


the use of no-refrer and no-opener in case


of performance or SEO?


I don't think it changes anything for SEO.


So it's purely a usability and security best practice.


So for ranking, I don't think it changes anything.


I kind of have a vague recollection


of what those two attributes do, but I would really


recommend checking out the documentation for them.


And then based on that, deciding on what you do.


I think the no-referrer essentially just


doesn't pass a referrer along.


So that's usually less a matter.


And the no-opener is something that is


more used for security reasons.


So it will not affect our performance


like speed vertices?


That's correct.


It doesn't affect speed definitely


because it's just a different type of link on your page.


It doesn't affect SEO either because we can still


see the rest of your content on those pages.


Sure.


Jan?


Hello, John.


Hi.


I have a question about responsive images


and which one Google tries to rank.


I've put a little piece of code in the chats


just to have some kind of sense what I'm trying to say.


I was wondering which images Google eventually


indexes or crawls.


I'm guessing you crawl all URLs or all sources,


but maybe you just index one.


Is it the biggest one, or is it the one


in the source attributes?


For a while, it used to be just the one


in the source attribute.


I don't know if that has changed.


But in general, it's very common for us


to recognize multiple sizes of images


and to index all of them and to recognize


that they're the same image.


And then what will happen in the search results,


in the image search results, if you click on the image


sometimes it shows the different versions as well


for that image in that preview pane on the side.


So that's something where it's usually less a matter of which


one we pick.


It's more that we can at least definitely index


the one with the source tag because that's


the standard setup.


And if we can recognize the other sizes,


then we could match those when people are explicitly


searching for something like a larger image or a smaller image.


But I think for the most part, it's


also something where sites tend not


to care so much about the different image variations.


They just want to be findable with any of the image


variations.


Yeah.


And would you say, if I understood correctly,


that it's very important to have the source


attributes because I think for the browser,


if you just use the source set attribute,


it would work just fine, I guess.


I think that changed in our system at some point


that we also use the source set to pick up


the different variations.


But at least in the beginning, it


was such that we only use the source.


And I could imagine that other search engines also


focus on only the source attribute.


OK.


Thank you.


I don't know if I have time for one more question.


Sure.


Go for it.


Regarding the core web vitals, you


mentioned the field data as being the one,


and it's also, in regards to ranking, only focused on mobile.


In the FAQs, you also, or somebody from Google


also said that it's kind of in the cutting edge,


or how do you say it, when it's two equally relevant pages


striving for the top.


Then it might matter more in those situations.


But what happens if you have two pages, two websites,


with an equally relevant content?


And then it's the question of one page


with mediocre core web vitals score and one page


where you have insufficient data.


Which one would outrank the other one?


I don't think we would have that defined.


So that could vary.


It's something that, in practice,


is less likely to happen.


Because usually, you would be comparing different sites


in the same niche.


And if they've been relevant, kind of fairly similar


in the past, then they have kind of similar traffic


from search already.


So they would be pretty much in a similar grouping already.


So that's something where my guess


is we will leave that undefined for the moment.


And we'll try to figure out how to best deal with that.


It's similar with other factors in search,


where sometimes we just don't have a lot of information


about a site, especially if a site is completely new.


And suddenly, there is new content there.


Then our systems have to make assumptions.


And sometimes those assumptions are more positive


than the end result ends up being.


Sometimes the assumptions are more negative


And this is something that we kind of


have to fine tune over time.


So I don't think we would have a kind of a clear definition


where we'd say, if a page is in the 50%


and the other page has no data, then we would always


pick it this way or that way.


I don't think we'd be able to define that.


OK, thanks.


Let me pause the recording here.


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


But it's always good to have a reasonable length


for the recording.


Thank you all for joining.


If you're watching this on YouTube,


I hope you found this useful.


And maybe you'll join one of the future Hangouts as well.


SEO for Single Page Apps | WMConf Lightning Talks

Hello and welcome to another Webmaster Conference Lightning Talk.


This time, as you can see, recorded from home.


In this video, we will discuss how to make sure that your single-page application is discoverable via Google Search.


Before we dive in, let's recap what a single-page application actually is.


Unlike a regular website, a single-page app uses JavaScript to control the page's lifecycle.


JavaScript is typically used to create the HTML that creates the page.


It also uses JavaScript to load other content when users are navigating to other parts of the single-page application.


These are often called views rather than pages.


This technique allows us to load views without the browser doing a full reload


and allows us to use custom transitions between the different parts of the application.


Single-page apps might use an architectural pattern called the App Shell model


where the shared parts of the UI and code, like menus, headers, footers, and so on,


are loaded when initially loading the single-page application.


And the different views are dynamically loaded into this shell,


reducing the amount of data needed to send over the network.


Okay, so what do we need to look out for when building single-page apps?


I think it is time to look at our sample app, test it, and then improve it where we see potential.


Our example application is an e-commerce web app, a cheese shop.


You can browse different product categories, learn more about a specific product, and you can put it into your cart.


It also uses the user's location to display prices in the local currency.


When we run the mobile-friendly test, there is a bit of an issue. The main content doesn't show up.


Time to investigate this.


In the JavaScript console messages, we can see that there is a problem with our code.


We are incorrectly using an unsupported feature.


That's an important point here. Sometimes we do forget that code doesn't always take the happy path.


In our example, we assume that we always get the user location,


but we forgot to deal with situations where that isn't available.


It's important to make sure that you cover all code paths to avoid these scenarios.


Googlebot, for example, declines the request for the geolocation.


I also noticed something else when using the shop.


It does not change the URL when navigating between different views.


But as Googlebot uses URLs to locate these different pages, or views in our case,


this would mean that Googlebot would only see our homepage and nothing else.


To fix this, we can use the History API and proper link markup with href attributes


to expose the other views as URLs within the links.


It's also a good idea to take a look at the titles and meta descriptions for our different views.


Right now, all views have the same generic title and meta description.


This isn't really helpful when people are searching for the one specific product or a specific category in our shop.


With a little bit of extra JavaScript, we can fix this quite quickly.


Ah, nice. This will look much better in the search results.


A very common problem is the way that single-page applications are dealing with error scenarios, such as invalid URLs.


In our example, the application displays an error message, but the server reports an HTTP 200.


That is a bit of an issue, specifically in single-page applications, because the server doesn't really do the error handling anymore.


Usually, the server serves the web app in all cases, and then the JavaScript in the browser decides if it wants to display an error.


But HTTP status codes do help Googlebot and browsers decide how to deal with a response.


So we should fix this.


Here's the JavaScript that deals with the error situation.


It reads the URL and fetches the data, and if that fails, it displays an error message.


But we can't just tell JavaScript to report a different status code, because the status code can't be changed once the server sent it.


What we can do, though, is to configure our server to respond with an error code for a specific URL, like "/not found." gives a 404, "/maintenance." gives a 500, and so on.


When we do that, we can use JavaScript to redirect to the designated error URL.


This signals to the browsers and Googlebot that the page is just a redirect to another URL, and this URL is an actual error.


Alright, now our webshop can be crawled and indexed, gives useful product information in search result pages, and behaves properly when there is an error.


If you are interested in learning more, do check out the links for a tutorial, our documentation, the JavaScript SEO video series, and like and subscribe if you want to see more videos like this.


Index coverage status in Search Console - Google Search Console Training

Hi, I'm Daniel Weisberg, Search Advocate at Google.


And today, I'll talk about how to use Search Console


to learn which of your pages have been crawled and indexed by Google,


and any problems found during that process.


How to Use Search Console to Learn Which Pages Have Been Crawled and Indexed by Google


Crawling is the process by which Googlebot discovers new and updated pages


to be added to the Google index.


Googlebot processes each of the pages it crawls


in order to compile a massive index of all the words it sees


and their location on each page.


When a user enters a query, Google machines search the index for matching pages


and return the results we believe are the most relevant to the user.


The Index Covert report, discussed in this video,


will give you an overview of all the pages Google indexed,


or tried to index, in your website.


To learn more about how indexing works, read through our documentation.


It will help you get the most out of this video series.


Check the links in the description.


Before I go into the report, I want to say a few words about when


and how often you should check the Index Covert Status report.


If Search Console detects a new index coverage issue on your website,


you will get an email.


But if an existing issue gets worse, you won't.


This means that you don't need to check the coverage report every day,


but keep an eye once in a while to make sure that nothing is going from bad to worse.


When you open the Index Covert report, the first page you see is the summary page.


The default view shows indexing errors on your website,


but you can click to show valid with warnings, valid, and excluded.


In addition, you will find a check box to add to the main chart


with the number of impressions your pages got on search.


Here is what each status means with some examples.


Errors prevent pages from being indexed.


Pages with errors won't appear in Google search results,


which can mean a loss of traffic to your website.


For example, you might get an error when you submitted a page


containing the no index directive.


Additionally, Google might find a server error,


or your page might be returning a 404.


All these cases would prevent the page from appearing on search results.


Issues on pages you submit via sitemaps are explicitly called out,


since they're most likely to be problems we should resolve.


Valid with warnings are pages that may or may not be shown on Google search results,


depending on the issue, but we think there is a problem that you should look into.


For example, Google might find pages that are indexed,


though blocked by robots.txt.


This is marked as a warning


because we're not sure if we intended to block the page from search results.


If you do want to block this page, robots.txt is not the correct mechanism


to avoid being indexed.


To do so, you should either use the no index directive


or request HTTP authentication to see your page.


Valid pages have been indexed and can be shown on search results.


No need to do anything.


Excluded pages were not indexed and won't appear in Google,


but either we think that is your intention,


or we think it's the right thing to do.


For example, the page has the no index directive, your choice,


or the page is a duplicate of another page, Google's choice,


or the page is simply not found and returns a 404 error.


For a more comprehensive list of issues, check our Help Center.


In the summary page, you should start by checking the chart


to learn if your valid page's trend is somewhat steady.


Some amount of fluctuation is natural,


and if you're aware of content being published or removed,


you might see that reflected here.


Let's take a look at the errors list now,


as they are the most pressing issues.


The table is sorted by severity and the number of affected pages,


so start investigating at the top of the list.


If your site doesn't have any errors,


you can also follow along with any of the other tabs.


Click the top issue to drill down into the issue details.


The details page shows an overtime distribution


of all pages suffering from this issue


and provides a list of examples that you can check more closely.


You'll also find a link to learn more about the error


in the Search Console Help Center.


In addition, you should click an example URL and inspect it.


This will show all the details available for a specific page,


as explained in the URL inspection episode of this series.


Try both the indexed and live versions.


What you see in the index coverage report


reflects the indexed data in the URL inspection,


and it might differ from the live test result.


Watch the URL inspection episode to learn more about it.


Once you understand what needs to be fixed,


you have two options.


Make the required changes yourself,


or share the details with a developer


that can perform code changes to your website.


You can do that by grabbing a link using the Share button.


The link grants access only to the current page,


plus any validation history pages for this issue.


It does not grant access to other pages for your resource


or enable the shared user to perform any actions on your property.


You can revoke the link at any time by disabling sharing for this page.


After you or your developer have fixed the error on all your pages,


click Validate Fix, and Google will validate your changes.


That's the index coverage status report.


Hopefully now you understand how to read the information,


prioritize your fixes, and let Google know when you do it.


Don't forget to subscribe to the Google Webmasters YouTube channel,


where we'll be publishing lots of Search Console videos.


Stay tuned.


Hey, Green. Hey, Blue. What's up?


Oh, good. She watched the new episode of the Search Console training series.


No, I didn't watch the last one.


Average Position in Google Search Console #AskGooglebot

Have you ever wondered about the average position metric in Search Console?


Well, so has Mohit, who's asking how relevant and believable is the average position metric in GSC?


Well, the data in the Search Console Search Performance report is based on actual search results that were shown to users.


It's not a theoretical number, but rather based on actual results.


We have a Help Center page with more information about these metrics if you're curious about the details.


I'll link to it in the description below.


The average position is based on the average top position of a URL from your site.


If there are multiple URLs from your website which are shown in the search results page,


we'll use the topmost one for this average.


You might not always see the same position when you check yourself.


That's generally due to personalization or geotargeting or because of short-lived visibility in search.


You can sometimes make assumptions that this is happening if you see a number of impressions


which is significantly lower than what you'd expect for those queries.


That's usually a sign that your site was only visible for a small part of the overall impressions.


For web results, keep in mind that your site might also be appearing in the images within the normal search results.


In short, the average position and other metrics in the Search Performance report are based on actual search results.


But actual search results can be quite varied.


I hope you found this video useful and insightful.


English Google SEO office-hours from December, 2022

Hello, hello and welcome to the December edition of the Google SEO Office Hours, a monthly


audio recording coming to you from the Google search team answering questions about search


submitted by you.


Today you'll be hearing from Alan, Gary, John, Dewey and me, Lizzie.


All right, let's get started.


Vertical web asks, my old site is going from 30,000 products down to two and a half thousand.


I will generate 400,000 301 redirects.


Is it better to start on a clean URL and redirect what needs to be redirected to the new site


or do it on that old URL?


We generally recommend keeping your existing domain name where possible.


We support redirecting to a new domain name as Google will recognize the 301 permanent


redirect and so understand your content has moved.


However, there's greater risk of losing traffic if a mistake is made in the migration project.


It is fine to clean up old pages and either have them return a 404 or redirect to new


versions, even if this affects lots of pages on your site.


Sina is asking, it's been formerly asserted that Google ignores links to a 404 page.


I want to know whether links to that page will still be ignored when it is no longer


Well, as soon as a page comes back online, the links will be counted again to that page


after the linking pages have been recalled and the links have been deemed still relevant


by our systems.


If my website is failing on the Core Web Vitals but performs excellently on GT metrics speed


tests, does that affect my search rankings?


Well, maybe.


There are different ways to test speed, different metrics, and there's testing either on the


user side or in a lab.


My recommendation is to read up on the different approaches and to work out which one is appropriate


for you and your website.


Somebody asked, why does Google not remove spam web pages?


Well, over the years we blocked about several spam-specific algorithms that either demote


or remove spam results completely.


One such example is SpamBrain, our artificial intelligence system that is very good at catching


spam.


Sometimes for some queries where we don't have any good results to show, you might still


see low-quality results.


Did you see spam sites are still ranking?


Please continue to send them to us using the spam report form.


We don't take immediate manual actions on user spam reports, but we do actually use


the spam reports to monitor and improve our coverage in future spam updates.


Thank you so much.