I have 20,000 pages that I want Google to crawl and index.


English Google SEO office-hours from July 16, 2021

And these are our 20,000 best pages.


And by doing that, it's a lot easier for us, on the one hand,


to say, well, we can crawl and index 20,000 pages.


That's fine.


And we can look at these pages and we can see, oh, these


are actually performing really well.


These are really good pages.


And then from there, over time, we


can expand to the rest of the site.


So that's something I sometimes see sites do.


And I think, in general, that's a good strategy because it also


helps you to refine a little bit and think about what actually


makes a good high quality page and how could we determine that


maybe automatically at scale.


SPEAKER 2


I would assume that takes a couple of months,


maybe half a year, something along those lines.


Because we really need to take the time


to understand the essential new site that we find like that.


And some things we'll pick up fairly quickly.


But when we're talking about the overall quality of a website,


that does take a bit of time.


SPEAKER 1 Okay, thank you.


All right.


Let me just take you, Mark.


And then I'll switch to some of the submitted questions


so that we don't lose track of those either.


Sure, thanks, John.


Yeah, I was wondering if Google has any updated guidance


on what I'll call white label providers or those that


take advantage of leasing subdomains or subfolders


from high authority sites who aren't actually creating


the content themselves.


Specifically after the latest core updates,


we see many of, I'll say, like news sites doing this


and they're jumping up in rankings pretty quickly,


taking maybe five or six of top 10 search results


for some high volume terms in our industry.


I think Google addressed this in 2019


and said those integrations would be treated appropriately.


But I'm not sure I know what that means.


Yeah, it would be treated appropriately.


That's a magic word.


Yeah, I don't think we have any updated guidance on that.


Essentially, we still feel the same way.


The idea is essentially on our side to say,


well, these are not a part of the main news website,


but maybe we can show and rank them independently as well.


And that's something of an approach


that I think is reasonably fair.


But I could imagine that over time,


there are some things that we need to reconsider.


So if you're seeing aspects where you're saying,


well, this is actually pretty bad


or these results look really terrible,


feel free to flag that to us.


And I don't know, flag it on Twitter,


send it to us directly, whatever,


just so that we can pass it on to the team and say, look,


we worked on this a couple of years ago,


but maybe it's time to work on it again a bit.


OK.


Yeah, I'm just trying to understand


if that's an acceptable model so that we understand


if that's something we'll see long term.


So I'll definitely flag it in Twitter.


And one other thing real quick.


After the latest core updates, we


see people also ask coming up higher in terms.


So I'm wondering if that changes with core updates


or how Google determines it, if it's per search


or if it's kind of per industry where


they appear in the results.


I don't think it's per industry, but usually what


happens with these kind of elements in the search results


is that we try to figure out what is the most


appropriate thing to show.


And with a core update, that does change some things


in our core algorithms.


And it can result in kind of a mix or a different mix


of elements that we show in the search results.


So sometimes that's what the people also ask.


Sometimes that's with regards to featured snippets


or rich results.


These things essentially are all kind


of tied in with the core algorithms that we have.


So it would be normal to see some fluctuations there.


Got it.


OK.


That's helpful.


Thank you, John.


Sure.


Let me run through some of the submitted questions


so that we have some of that covered.


I think some of these overlap with what


we talked about already.


How can a website related to other niches like ringtones


handle high quality content?


When I search for high quality content,


everyone talks about writing high quality articles.


But few niches, like I mentioned,


are completely different.


So what can I do?


Yeah.


I think sometimes it's really hard.


And especially if you're starting out with a website


and you're starting out with an area


where there is a lot of really strong competition


and what essentially you're providing


is a commodity product and that everyone


has exactly the same thing, then it's


really hard to go in there and say,


I will provide something of higher quality.


Usually my recommendation there is


to look at this more as a business


problem than an SEO problem.


And if you want to start a business in a very


competitive area with a commodity product,


essentially, then you're going to have a really bad time.


Or you're going to have to have, I don't know,


a long, long time available to work and improve things


over time.


So that's something where if you're starting out


with a website, I would try to find an area where you can


be the leader or where you have unique knowledge, experience,


or unique product that you can provide and then work on it


from there.


Whereas if you go to an existing niche


and just try to provide high quality information


about these commodity products, I


don't think that's really going to make a dent in the market.


Dan, a question about internal linking.


Do you think it's recommended to add a nofollow tag


to internal links that lead to nofollow?


DANIEL PIKUANUIYA MUKUNIYA MUKUNIYA MUKUNIYA MUKUNIYA


This is my question, John.


Oh, OK.


Wow, you're next too.


Perfect.


Yeah, especially on large websites


with a lot of noindex pages and a lot of internal links


to those pages.


Do you think this can save crawling budgets and link


juice?


I don't know.


I'm torn about this.


I think to some extent, if you're


linking to things like category pages or different filtered


pages on an e-commerce site, different sorting


parameters, those kind of things,


I could imagine that using nofollow helps us to focus


on the primary content.


But if you're talking about things like a privacy policy


page, you just don't want to link to that,


I don't see how using nofollow on those links


will change anything.


So we have a lot of pages that have noindex tag


because it doesn't make sense for them to compete on SERP,


but they have value for our users.


So because of that, we have a lot


of internal links that lead to those pages that


have value for the users.


But we won't want the crawler to go to them


and waste our core budget.


So Matt, like years ago, recommended


not to use nofollow tags on internal links.


So I was wondering what you think about it.


Should we use nofollow tags on internal links or not?


Because on every page, we have internal links


to noindex pages.


So this is the question in general.


Yeah.


I don't think it's something that


has a clear binary answer where you should never do it.


I could imagine in some situations it makes sense.


Like I mentioned, if you have categories or filters


and sorting parameters, things like that,


I could imagine it helps us a little bit.


But in general, even without the noindex there,


without the nofollow there, if we


see that this page has a noindex,


then we probably won't crawl it as frequently anyway.


Yeah, but it is finishing our budget.


So the crawler, when it's going to that page


and we see a non-linear stack that it's counting


on our core budget, I think it does, no?


It does count in your crawl budget.


But I think it's something that our systems tend


to learn, though.


So that's kind of the, I think, the tricky aspect here,


in that when it comes to crawling websites,


we try to understand which pages need to be crawled how often.


And if we see that a page is a noindex, then we'll say,


well, we don't have to look at this that often,


because it's essentially a soft 404 or something like that.


It's a good page with a lot of content,


but we don't want it to compete on SERP.


And we see that the crawler is going to those pages a lot,


because there's a lot of internal links to those pages.


So this is the dilemma to what you do.


Yeah.


So I don't think it's terrible to put


a nofollow on these pages.


And it might have a positive effect in that regard.


So that's something I would, in your case, at least try out.


And you can test it out and see what happens.


It's not the case that if you put nofollow on internal links


and something will explode, it's just for normal pages,


you wouldn't need to do that.


But in a case like yours, I could imagine,


maybe it makes sense.


The other approach that you might take


is to make sure that these pages are in a separate URL section,


something like a separate folder or a separate subdomain


or something like that, so that we can easier


recognize that we don't need to handle them as often.


If that's possible, then I suspect


those systems would learn that over time as well.


But I also don't see any problems with saying,


well, you'll try the nofollow and see


if that changes anything for crawling.


You can take a part of your website and test it like that.


And from my point of view, it's more a technical thing.


So it's not that we would think your site is lower quality


or anything like that.


It's something where you can purely measure,


does this have an effect on the crawling of the pages


that are linked or not?


And if so, are you sure that you can implement it in a way


that you don't accidentally nofollow links


that you do care about?


OK, thank you very much.


So you do recommend you try it at least?


I would definitely try it.


I mean, it's one of those technical things


that essentially you can measure,


and you can see how it works.


It's not going to blow up.


It's not that Google systems would just say,


oh, there are nofollowed internal links.


This is a bad site.


Yeah, but on every page, there are


going to be a lot of nofollow links.


So maybe it's a bad thing.


No, no, that's perfectly fine.


Sure.


A question on schema markup for aggregate rating.


If we have multiple services, but we collect the reviews


in one generic place, like Trustpilot,


how should we mark up the separate product pages?


As I understand, the advice is not to mark up each page.


So at the moment, I only have one markup.


We have about 1,200 reviews, and our rating


is approximately 4.7.


So we're keen to shout about this.


So unfortunately, from our guidelines around rich results,


you would probably not be able to mark these up


at all because our guidelines essentially say,


you should only mark up the pages where you actually


collect the reviews yourself.


So if some third party is collecting the reviews,


and you just take that aggregate rating


and copy it onto your website, we


would not consider that to be valid aggregate review markup.


And it might be that we don't show it.


It might even be that the web spam team says,


oh, this is so problematic that we will suppress the reviews


completely for this website.


So that's kind of the, I think, the bigger issue


that you need to think about.


Essentially, from our point of view,


these third party pages where you're collecting the reviews,


those are the ones that would be able to mark up the reviews,


but not your website.


You can kind of see it as essentially curating


the reviews because you're taking


a number from one website, and you're manually


copying it into another.


Or maybe you're using an API.


But essentially, we have to trust you


that you're taking the sum of the reviews


and not a sample that you like.


So that's kind of the reasoning behind that.


Is there any benefit to using schema markup outside


of the featured snippet possibilities,


for example, using collection page markup on category pages


to make a clear distinction of the entity?


There is a minimal positive effect


of using the non-rich results structured data on your pages


in that we understand the entities a little bit better


on those pages.


But the effect is not something that you would probably


see in most cases.


And it wouldn't be visible because it's not


a part of the rich results type.


So we wouldn't be able to show that.


So that's something where if you're


focusing on kind of like return on investment


for implementing different structured data features,


I would focus on things that are immediately


visible in the search results because that's something where


you know that there is an effect.


And the effect might not be a ranking effect,


but at least you see a visible effect of the work


that you did.


Whereas if you add structured data to your pages


and you have no idea if Google or anyone does anything


with it, then that feels a little bit futile and kind


of like, well, you're trusting that some magic will


happen along the way.


And in particular, something like collection page markup,


where you're saying, oh, this is a collection


of different things, I don't see our systems


would being able to use that in any positive way.


So it would be slightly different


if you're marking up things like individual locations


or individual entities and names and companies, things like that.


That, I imagine, might be useful to us


because we can look at the text and the text might be ambiguous,


but your structured data tells us, oh, this is a location


and not a Spanish word or whatever.


But whoa, let me just turn off the phone.


Always good surprise along the way.


But if you're just adding something generic,


like connection page or the web page markup,


then that seems like something that wouldn't really


be useful for us.


I got an algorithm penalty from Google


between the 31st of March and the 1st of April.


I didn't get a manual action email from Google.


After a few days, pages got indexed.


What can I do to recover?


So if there's no manual action or no message in Search Console,


then essentially that's our algorithms that are saying,


well, we don't really know how to place your website,


and it might be that we don't show it as visibly as before.


And usually that's more of a quality issue


than anything else.


So that's something where I would


try to take a step back and think


about the overall quality of your website


and see what you can do there to improve things.


And also, if it's really the case


that we actually start de-indexing pages


from your website or a significant amount of pages


from your website, then it feels like something


where there is a significant quality issue


that you need to work on.


And quality issues like that are not


things that you need to flag to us that you've completed that,


but rather over time we will re-evaluate your site.


And if things are OK, then we will start


showing it differently again.


Is there a need for a schema to be


used on the main category pages, subcategory pages for blog


content hubs?


I was thinking that breadcrumb structured data would be good,


but is there anything else that can


help Google to gain context into what the topic is about?


I think breadcrumb structured data is always useful,


in particular because less and less,


it feels like we're showing URLs in the search results.


And instead, we try to show these kind of breadcrumb links.


And if we have to figure out the breadcrumb links ourselves,


then that's sometimes hit and miss.


And if you can specify those yourself with structured data,


that's usually a lot better.


So I would definitely aim for that.


Other things on these pages, it's hard to say offhand.


But usually you would focus on the individual blog posts


instead and not on the category pages on a blog.


What do you recommend to young websites


that can't outrank old websites because they have many links?


Yeah, I don't know.


This is almost like one of those business questions again.


It's like you're starting off with a new business.


What can you do to compete against these old businesses?


The interesting thing is we get exactly the same question


and the other way around from existing and older websites


as well.


So usually they tend not to come to these office hours,


but they'll go to their account manager and complain.


It's like, oh, some new site is ranking ahead of us.


And essentially, from our point of view,


we don't have any preference with regards


to new websites or old websites, but rather we


try to evaluate what makes the most sense to show to people.


And it's not just based on links.


So just kind of like blindly saying, well, old websites


have more links, therefore they're shown,


I think that's super oversimplifying and, in most


cases, probably incorrect.


And it also kind of doesn't align


with when the old websites complain about new websites


ranking instead of them.


But it is something where, kind of like I mentioned before,


if you're going into a market where


there is a lot of really strong competition,


then you really, I don't know, you should expect some headwind.


And it's going to be hard.


And usually it's a lot easier to start off with something


where you're kind of like ahead of everyone else,


where you're providing some content that's


really fantastic that doesn't compete with existing content,


where you're doing something different from everyone else


rather than just saying, well, I'm writing about the news


in a little bit of a better way.


Essentially, if you're providing something different,


then that's a whole different game then


because then the old websites might not have anything


that competes with that.


So that's usually the direction that I would go there.


All right.


Maybe I'll go to some more live questions.


And then we'll pause the recording


so that it doesn't get too long.


Let's see, Jason.


Hey, John.


How's it going?


Hi.


Hey, so our question is we're ranking


in some competitive niches, and we've


been exploring different link building strategies.


One of the ones that have given us the most interest


is actually Google property stacking.


And I just want to know if it's still


acceptable to do with a new core update.


How do you mean?


So during our research, we found out


that some people were using Google properties,


like say, for example, Google Slides, Google Sheets,


Google Docs, and creating them within a Google site


and then linking that Google site into their website


to try to boost authority.


Is that an acceptable strategy, or what do you think about


that?


I don't think that would work at all because I don't know,


kind of the way that all of these user-generated content


sites are handled, I don't think that would


change anything.


So kind of going with the mindset that, oh, it's


hosted on a Google.com domain, therefore, it'll


be valuable for my website, I don't think that really works.


So I don't know.


That sounds very questionable.


I mean, I think creating Google Docs and hosting them


on your website, why not?


I wouldn't expect anything magical to happen out of that.


I think, in general, with regards to link building,


I would recommend being super cautious


and really thinking about what Google is trying


to do with regards to links.


Because we want to see essentially natural links


in that you're providing something fantastic,


and people are saying, oh, look at this fantastic thing.


And that's the kind of thing that we're looking for.


Whereas if we look at it and see, oh, it's like,


you're placing all of these links,


like I'm really fantastic, come look at me,


that's not really that useful for our systems.


And if we see that's being overdone,


then we might go off and say, we don't trust any of the links


going to this website.


Because we can't differentiate between the links


that you're creating and the links that are actually normal.


Right.


Well, we found this issue when we


were doing some backlinking research.


And we found that in the city of Austin,


there was this Google site that was just


having iframes all over, like Google Calendar, Google Docs.


And it was ranking number one.


And it's been ranking number one for well over six months.


And we're just like, man, this looks terrible,


but how is it number one?


What's going on there?


So we needed to come with some sort of solution for that.


Yeah.


No, I mean, it's definitely not because of all of those embeds.


That would be crazy.


I don't think anything like that would happen.


I mean, in the early days, there was also


talk that links from Gmail, for example,


would help your website to rank well.


And it just doesn't make any sense.


So that's something where I suspect someone is just


trying everything out.


And one thing might be working, one thing might be OK,


and all of the rest is essentially ignored.


And then when you look at it, you're


saying like, oh, they're doing all of these things.


Maybe all of these things are working.


And actually, it's something completely unrelated.


And we often see that also with small business sites


in that they'll do a lot of things wrong.


And our systems are essentially tuned


to ignoring a lot of these wrong things


because we know people just follow bad advice.


And if they're also doing a handful of things right,


then sometimes they're just ranking because of those things


that they're doing right and not because of all the things


that we're ignoring.


That makes sense.


All right.


Thank you so much, John.


I appreciate it.


Sure.


Barry.


Good morning, John.


Hi.


I've got another soft 404 issue.


I've got a site I'm working on.


They have about 40,000 products.


I've posted this in the Google Search Console support,


and they don't see an issue with the page, sample page.


And in Google Search Console, if it's


like each time there's a crawl, there


are more pages added to the software for a list.


And if I take a product that's showing is fine


and then revalidate it, it will then give a soft 404 error.


The only thing I'm seeing that might be triggering it


is there's some mystery JavaScript code


on the page with a line that says inventory false.


Would Google be looking at that and thinking


that that might say the product's out of inventory


and don't index it?


That would be kind of strange, but I don't know.


Our systems sometimes do strange things.


So in your case, I would see if you can change that line


and just test it out.


But I would also love to have those examples.


So if you can maybe copy a link to the forum thread


here in the chat, then I can pass those examples


onto the team to make sure that we pick up that properly.


I mean, it's something where I would


say we shouldn't be recognizing a random line in JavaScript


as being a reason for a soft 404.


And maybe you can fix it, but we still


shouldn't be recognizing that.


OK.


Thanks, I will post that and the bit of code.


All right, perfect.


Michael.


Hi, just a very, very quick follow up


on my first question about putting all those no script


links.


The result of that is the HTML file


went from like 89 kilobytes to about 200 kilobytes.


Our developer has a concern that the text to code ratio


might cause a problem.


Given the weight between having crawlable links


versus a high text to code ratio,


what's your opinion on the risk of that?


So we don't do anything text to code ratio wise.


So from that point of view, I wouldn't care.


The only thing I would watch out for


is the general speed of the page itself,


which you can test with all of the Core Web Vitals tools.


And my assumption is that this kind of content


would compress fairly well.


So it wouldn't be that it slows down the largest content


for paint or anything like that.


So probably that would be fine from that regard.


But definitely, text to code ratio doesn't matter.


OK, we will measure and monitor.


Thank you.


OK, cool.


OK, let me take a break here and pause the recording.


And I'll be around a little bit longer.


I have to leave in like a half an hour.


But until then, we can hang around.


I can finish the people who have raised hands as well.


If you're watching this on YouTube, thanks for watching.


And hopefully, you can join in one of the future ones.


Also, for all of you here as well as those watching,


we have a survey running on YouTube at the moment.


And I would love to have your input there.


So essentially, we're trying to figure out


what we should tweak on our YouTube channel


and our YouTube strategy.


And if there are any things on your mind


that we should do differently or that we're doing well,


let us know about that.


All right, so thank you for watching.


And maybe see you all next time.


Setting goals for your website (and why it matters) | Search for Beginners Ep 2

If you decide to create a presence for your business on the web, like a shop on a platform


such as Amazon or Etsy, or your own standalone site, you'll be investing money and time


to get this done.


And understandably, you'd want to see a return on that investment.


What does that look like for you?


Let's say you have a local clothing store, but you want to sell to people out of town


and not just local customers.


That is a goal you can measure with your website.


To do that, you need to understand what steps people take in order to become your customers.


This works online exactly like in a real life shop.


First, people need to find your store.


Then they need to decide to enter it and look at the goods.


And finally, pick out something and pay for it.


Once you have an online shop, you can measure these steps quite precisely.


For example, if someone searches for t-shirt and a page from your site appears in search,


that would be called an impression.


This is the same as if a person in real life discovered your store exists.


If that person decides to visit your site, they would click on the result link.


By counting these clicks from search results to your website, you can measure visits.


Once the person is on your site, they might browse around and look at various products.


You can track their path across the website and see how long it took them to buy something.


Or maybe they left the site after clicking on a few pages.


You or the person who maintains your site can use a variety of tools to measure queries,


impressions, clicks, and the user's path towards checkout.


Most ecommerce platforms offer their own dashboards for tracking these metrics.


Google provides two free tools, Search Console and Google Analytics, that allow you to look


at these metrics yourself.


What are your goals?


What do you want to measure?


Once you decide that, use your analytics tools and connect them to the metrics you have.


The important thing is that you can keep track of what's happening on your website, whether


it's visitors, conversion rates, or revenue.


By following this information, you can make important adjustments and changes as needed.


You can even gain insights on what your customers may be interested in and expand your product


catalog.


Don't just let your website's metrics sit there.


Use them!


And make sure to watch the next episode, in which we will discuss how to find someone


Product page performance problems

How did that happen?


Product page performance problems

Hello and welcome to another episode of SEO Fairy Tales.


Product page performance problems

With me today is Ruth Mesfon.


Product page performance problems

You are a software engineer at Zillow and you love leathercrafting.


Product page performance problems

That's an interesting hobby.


Product page performance problems

And you also play board games.


Product page performance problems

So that's something that I can connect more with.


Product page performance problems

But you have to tell me after this episode what


Product page performance problems

leathercrafting specifically is.


Product page performance problems

That's an interesting one.


Product page performance problems

Yeah, I'd love to talk about it.


Product page performance problems

But we are not here to talk about that, unfortunately.


Product page performance problems

You brought me an interesting technical SEO case study


Product page performance problems

where you had to investigate an issue.


Product page performance problems

What was that?


Product page performance problems

How did that start?


Product page performance problems

Yeah, so what we realized was on our product page,


Product page performance problems

we weren't getting a lot of users staying onto the page,


Product page performance problems

specifically the product pages.


Product page performance problems

So the product pages is similar to, like,


Product page performance problems

if you think of Amazon's product page or eBay's product page


Product page performance problems

where there's the product and the information and all


Product page performance problems

that stuff and then they can purchase,


Product page performance problems

but they kept on dropping off.


Product page performance problems

So when I investigated it, what I did was I, one,


Product page performance problems

checked where they were dropping off in Google Analytics


Product page performance problems

and whatnot, because it was also decreasing our SEO a bit,


Product page performance problems

and saw how long they were taking in regards to load


Product page performance problems

and whatnot onto the page.


Product page performance problems

Uh-oh.


Product page performance problems

Yeah.


Product page performance problems

And I was like, oh, I think this might be a latency issue


Product page performance problems

that we have.


Product page performance problems

For real.


Product page performance problems

OK, so how did you find that out?


Product page performance problems

So you went to Analytics, and you saw,


Product page performance problems

like, you filtered for the product pages,


Product page performance problems

and you saw that they dropped off real quick.


Product page performance problems

Yeah, the product manager was looking into the analytics


Product page performance problems

aspect, and then I asked if he could deep dive on it.


Product page performance problems

And he pinpointed, oh, it looks like they're here specifically,


Product page performance problems

but it's like they're not clicking checkout or anything.


Product page performance problems

They're just leaving, and it seems like it's


Product page performance problems

taking longer to load here.


Product page performance problems

I was like, oh, interesting.


Product page performance problems

So what I did was we have a Lighthouse script.


Product page performance problems

So it will render the page as many times as you want.


Product page performance problems

So it's like, oh, render the page 500 times,


Product page performance problems

just so I could make sure the data is accurate.


Product page performance problems

Because, you know, Lighthouse kind of changes every time.


Product page performance problems

Yeah.


Product page performance problems

So we did that for the desktop page and then the mobile view,


Product page performance problems

because that was the new thing that we had,


Product page performance problems

was it being mobile responsive.


Product page performance problems

Ah, OK.


Product page performance problems

So you made it responsive for mobile users,


Product page performance problems

and how did that go?


Product page performance problems

So what we realized was that when we changed it


Product page performance problems

to mobile responsive, it was really much slower


Product page performance problems

than what we had prior, where we had a separate mobile page


Product page performance problems

for it.


Product page performance problems

And so when we investigated it, we realized a couple of things.


Product page performance problems

We had a lot of plugins and packages that was bloating.


Product page performance problems

Bloating, yeah, the latency at the time.


Product page performance problems

And we were like, oh, I think that might be a big cause


Product page performance problems

of it.


Product page performance problems

It's like this hidden custard, right?


Product page performance problems

It's like, oh, it's easy to build this feature


Product page performance problems

if I just pull in these 25 different packages that


Product page performance problems

do one thing each.


Product page performance problems

Yeah.


Product page performance problems

Ah, man.


Product page performance problems

Because it's like, oh, this is easy.


Product page performance problems

Oh, look, there's like a bar chart plugin.


Product page performance problems

Let's just use sense of creating our own, right?


Product page performance problems

Which, to be honest, usually is a good idea,


Product page performance problems

because just reinventing the wheel over and over again.


Product page performance problems

OK, so was that the issue then?


Product page performance problems

So there was a couple of issues.


Product page performance problems

Yeah, so that was one issue.


Product page performance problems

Oh, second issue.


Product page performance problems

So when we have a loading page or we're


Product page performance problems

loading a specific part of that page specifically,


Product page performance problems

we have a cute little loading apple that shows us loading.


Product page performance problems

Oh, that's cute, though.


Product page performance problems

Except that was a GIF.


Product page performance problems

Oh, that's not cute, though.


Product page performance problems

No.


Product page performance problems

So we didn't realize that a GIF is at least 1,000 images going


Product page performance problems

over and over and over again.


Product page performance problems

So think about it trying to load the page while using it.


Product page performance problems

While loading a bazillion images.


Product page performance problems

Yeah.


Product page performance problems

Ah, I've been there, done that, because the loading GIFs


Product page performance problems

are so easy to implement, but then also so not great.


Product page performance problems

The third part was that, speaking of images,


Product page performance problems

we realized that we were trying to, I guess,


Product page performance problems

load the images instead of it being lazy loaded.


Product page performance problems

So it's trying to load everything at once, which is


Product page performance problems

also causing latency issues.


Product page performance problems

True, because the browser only has so many connections.


Product page performance problems

And then if they're exhausted, you basically just add onto it


Product page performance problems

and then this waterfall kind of, oh my, OK.


Product page performance problems

So you had all these things identified.


Product page performance problems

But to go back a little bit, so you


Product page performance problems

said you have a Lighthouse script.


Product page performance problems

So you're not doing it in the browser where you actually


Product page performance problems

click on and then actually run it.


Product page performance problems

So how does the script work?


Product page performance problems

How does it work?


Product page performance problems

Yeah.


Product page performance problems

So yeah, because I used to actually do the light,


Product page performance problems

like, press the button over and over.


Product page performance problems

This doesn't, this isn't.


Product page performance problems

It's not a long-term solution.


Product page performance problems

And to be fair, I modified this script,


Product page performance problems

but I didn't create the script.


Product page performance problems

It was like, shout out to Ben, who actually did that.


Product page performance problems

He was like, ah, I think there's a more efficient way


Product page performance problems

of doing this.


Product page performance problems

And he created it and I was like, this is awesome.


Product page performance problems

So how does that work?


Product page performance problems

Do you run it as a Node.js script from the command?


Product page performance problems

And so what you do is you put in the actual page.


Product page performance problems

So what we usually do is there's two ways of doing this.


Product page performance problems

So one is that you can put the link of the page, right?


Product page performance problems

And then you preface if it's mobile or desktop.


Product page performance problems

And then it just runs through, like, as,


Product page performance problems

and you preface how many times you want it to run.


Product page performance problems

And it'll just run it over and over and over again.


Product page performance problems

Nice, yeah, over and over again and gives you, like,


Product page performance problems

aggregate stuff.


Product page performance problems

Nice, lovely Excel spreadsheet so you can see all the data.


Product page performance problems

And then, like, if I wanted to, I


Product page performance problems

could put in graphs and whatnot, which is great.


Product page performance problems

And the second part, or second way,


Product page performance problems

which is what I did to make sure that latency did,


Product page performance problems

or theoretically latency should decrease,


Product page performance problems

was that you can put the main website or the main page.


Product page performance problems

And then if you have, like, a branch site


Product page performance problems

or if you have, like, a testing branch,


Product page performance problems

you could put that link in there.


Product page performance problems

And so it will run both of them for x amount of times you want.


Product page performance problems

And then you could compare the two.


Product page performance problems

Oh, so it gives you the diff, like, so the production side


Product page performance problems

has this as our latency.


Product page performance problems

And then we have the development or staging system


Product page performance problems

that does look different and hopefully faster.


Product page performance problems

Yeah.


Product page performance problems

So you used Google Analytics, then used the Lighthouse script,


Product page performance problems

and then how did you figure out which packages


Product page performance problems

or plugins were contributing?


Product page performance problems

Yeah, so honestly, I forgot what it's called.


Product page performance problems

But there was a way to be able to see all the packages


Product page performance problems

that everyone gets by mid-memory.


Product page performance problems

So there's kid function here?


Product page performance problems

It tells your boots onave things thatAUDrey


Product page performance problems

doesn't know and needs help.


Product page performance problems

Yeah, and data ac Juneutions back in 2015,


Product page performance problems

I thought we should have bought that guysAG house


Product page performance problems

because they medieval place.


Product page performance problems

They built themlag.


Product page performance problems

Yeah, and they taxation was similar.


Product page performance problems

And if you add that site up on the thrive site,


Product page performance problems

they would then build something that


Product page performance problems

has to run as an extension on thevisor.


Product page performance problems

a bar chart, and we were like, for one page.


Product page performance problems

I was like, oh, this is useless for us.


Product page performance problems

So what we did is we removed that and actually built out


Product page performance problems

the bar chart, because that was actually much cheaper.


Product page performance problems

And then the second thing was icons, like Fabicon or whatnot.


Product page performance problems

When we used the same five of those icons.


Product page performance problems

MARTIN SPLITTENBERG


Product page performance problems

Oh, yeah.


Product page performance problems

I think isn't it like a paid feature or something?


Product page performance problems

But that's a paid feature that will pay off itself basically


Product page performance problems

in an instant, right?


Product page performance problems

So we're like, oh, we can actually


Product page performance problems

create our own icons and utilize those and not


Product page performance problems

have that anymore.


Product page performance problems

And then we just reduced that.


Product page performance problems

And then we looked at different plugins and see,


Product page performance problems

oh, we need this plugin.


Product page performance problems

However, we don't need all of this.


Product page performance problems

We just need specific.


Product page performance problems

Lodash is also one.


Product page performance problems

MARTIN SPLITTENBERG Yeah, it has a bazillion functions,


Product page performance problems

and you need five most of the time.


Product page performance problems

Yeah, it's true.


Product page performance problems

So you did tree shaking.


Product page performance problems

Did you do bundle splitting as well


Product page performance problems

so that you had different bundles for different?


Product page performance problems

Yeah.


Product page performance problems

That's a fun one.


Product page performance problems

That's hard, though.


Product page performance problems

It was.


Product page performance problems

OK, so yeah, it's hard, but it's like I love KonMari.


Product page performance problems

So I love, like they said, OK, let's simplify.


Product page performance problems

So let's get that thing out of here.


Product page performance problems

That is awesome.


Product page performance problems

OK, that's pretty cool.


Product page performance problems

It's like, oh, can we simplify this?


Product page performance problems

We can simplify this.


Product page performance problems

Let's get this out of the way.


Product page performance problems

And were you able to actually drop the loading


Product page performance problems

time for mobile users then?


Product page performance problems

Yeah, so we were able to, I think, drop the time by,


Product page performance problems

what was it, 15% or whatnot, which was great.


Product page performance problems

Yeah, that's pretty interesting.


Product page performance problems

And then it was like we were definitely seeing,


Product page performance problems

or based on what the marketing team said,


Product page performance problems

oh, we're seeing an increase of people who are on the product


Product page performance problems

page.


Product page performance problems

Excellent.


Product page performance problems

I was like, oh, that's not because you're happy.


Product page performance problems

I'm happy.


Product page performance problems

Exactly.


Product page performance problems

We made it better for our users.


Product page performance problems

We made it better for the marketing team.


Product page performance problems

That's awesome.


Product page performance problems

And then for the GIF, we replaced that with just


Product page performance problems

like an SVG.


Product page performance problems

Oh, right.


Product page performance problems

Yeah, SVG is so much nicer for loading animations.


Product page performance problems

That's amazing.


Product page performance problems

But I guess you had to have a designer do that because that's


Product page performance problems

a tricky one to do, I guess.


Product page performance problems

And we didn't want to do it.


Product page performance problems

We're like, we're not going to do a GIF kind of style.


Product page performance problems

We're like, whatever is simple.


Product page performance problems

And if it's like three dots or whatever you want.


Product page performance problems

Oh, but it used to be a cute apple, and now it's the dots?


Product page performance problems

It's actually like a circle.


Product page performance problems

Oh, OK.


Product page performance problems

Yeah.


Product page performance problems

It's like a spinner.


Product page performance problems

Yeah, it's OK.


Product page performance problems

We don't need a cute apple.


Product page performance problems

A cute apple is great and all.


Product page performance problems

You'll see lots of cute apples.


Product page performance problems

OK, fine.


Product page performance problems

Fine.


Product page performance problems

OK, giving up an apple.


Product page performance problems

An apple a day gives the latency away, I guess.


Product page performance problems

That's a nice one.


Product page performance problems

Interesting, and you saw an uptick on usage,


Product page performance problems

and you saw that people stayed longer,


Product page performance problems

and everyone was happy in the end.


Product page performance problems

That's awesome.


Product page performance problems

Cool.


Product page performance problems

If you want to do that, you let me know,


Product page performance problems

and we're going to put it in the description below.


Product page performance problems

Yeah, I'll talk to Ben about that,


Product page performance problems

because I'm sure that he would be more than happy to do that.


Product page performance problems

It's really, really an interesting tool.


Product page performance problems

It's an interesting choice, and quite an interesting tool


Product page performance problems

chain that got you to a 15% increase in performance


Product page performance problems

for mobile users.


Product page performance problems

That is really, really cool.


Product page performance problems

How long did this entire process take?


Product page performance problems

A couple of months, if I'm not mistaken.


Product page performance problems

It's not really like a 15%?


Product page performance problems

Oh, yeah.


Product page performance problems

This is not like a quick fix.


Product page performance problems

The quick fixes are the lazy loading for images,


Product page performance problems

those kind of things.


Product page performance problems

It's like this.


Product page performance problems

That's easy to drop in.


Product page performance problems

Yeah, that's true.


Product page performance problems

And even the GIF one, replacing that, a designer


Product page performance problems

has to make it.


Product page performance problems

But other than that, it's easy to swap in.


Product page performance problems

Yeah, so those were quick fixes.


Product page performance problems

The bundle?


Product page performance problems

The bundle thing, that's a longer term fix.


Product page performance problems

But it's really, really cool that you spend the time


Product page performance problems

and see the results.


Product page performance problems

And that's, I think, what matters in the end.


Product page performance problems

But it's important that we mention that,


Product page performance problems

because people kind of expect these kind of, especially


Product page performance problems

performance fixes, to be like a quick, easy, low-hanging fruit.


Product page performance problems

It usually isn't.


Product page performance problems

It usually is a little trickier.


Product page performance problems

Yeah.


Product page performance problems

And that's what we're going to talk about in the next video.


Product page performance problems

All right.


Product page performance problems

Thank you so, so much for sharing the story.


Product page performance problems

That was really, really cool.


Product page performance problems

And thanks a lot for being here.


Product page performance problems

Yeah, thank you for having me.


Product page performance problems

This was so much fun.


Product page performance problems

It's amazing.


Product page performance problems

I'm so, so happy to have you on board.


Product page performance problems

And for all of you out there, if you


Product page performance problems

see anything in the video description,


Product page performance problems

then it was published.


Product page performance problems

Are you using the CLI?


Product page performance problems

Are you using some sort of custom script?


Product page performance problems

Are you using it in the Chrome browser?


Product page performance problems

Let us know in the comments below.


Product page performance problems

And thanks a lot for watching.


Product page performance problems

And stay safe and take care.


Product page performance problems

Bye-bye.


Product page performance problems

All right.


Product page performance problems

Fantastic.


Product page performance problems

There we go.


Product page performance problems


English Google SEO office-hours from December 4, 2020

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


SEO Office Hours Hangout.


My name is John Mueller.


I am a search advocate at Google in Switzerland.


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


where people can join in and ask their questions around search


and their website.


Bunch of things were submitted already on YouTube,


so we can go through some of those.


But if any of you want to get started


with a question of your own, feel free to jump in now.


If I can start, if I can be first, would be nice.


Sure.


So earlier this week, actually, like two or three days ago,


I noticed that one of my client's websites, some pages


got indexed.


And it says that the user declared canonical


is just a different page.


But then I checked the pages.


The HTML code shows that it's a self-referencing canonical.


So it's actually pointing to the correct one.


And then when I use the live, how do you call it,


the live tool to check the live URL,


it actually shows that is the correct canonical.


But it's still reported there, and some of those pages


are still the index.


So I'm not really sure how that happened.


I checked the website.


Nothing really changed.


So I don't really know how to tackle that problem,


because we lost some keywords and ranking some traffic


because of that.


Yeah.


I, like on my side, what I need to do


is look into those specific details.


So what I would usually recommend for a case like this


is to post those details in the help forum first


and get some input from other people.


And the product experts in the help forum,


they can escalate threads when they


see that things aren't kind of working out.


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


I have seen some cases like this,


not specifically like this week or last week,


but in general, it happens every now and then


that something on the website is configured


in a way that makes it really hard for us


to crawl and index the pages.


So I've seen that, for example, with a site that


uses some ad blocker scripts or anti-ad blocker scripts,


I guess.


And then in cases like that, those scripts sometimes


redirect to a central page, and that has a rel canonical on it,


or we pick up the redirect and we


use that kind of as a canonical signal, those kind of things.


And that can sometimes trigger, depending


on the way that we crawl.


So maybe for the normal crawls, it doesn't trigger.


And then every now and then, it does trigger,


and it triggers right at that moment


when we pick up something that we want to use for indexing.


But that's something that sometimes


is noticeable when you look at the specifics of the site.


Like if you look at the other URLs, then you can see,


oh, they have similar issues sometimes,


which kind of points to this kind


of sporadic type of an issue.


And sometimes it's just like, I don't know,


some one-off quirk that might have happened maybe


from a CDN that's involved in the middle,


maybe from the hosting side, something like that,


that just happened to kind of step in in between.


AUDIENCE MEMBER 1 OK, interesting.


And I also wanted to ask, I noticed


that there is many other pages that are not indexed because


of the trailing slash.


I don't know.


This is the first time, like most of the other pages,


you don't see that.


Sorry, many other websites have seen


that there is nothing in the report, even though the pages


have the trailing slash, or if it doesn't have it,


it's still considered the same page.


But for this particular website, it


seems like many pages without the trailing slash


were the index.


I don't know if that gives us a hint of something going on.


It's hard to say.


So by default, we wouldn't see the trailing slash and not


trailing slash as the same URL.


It is something that technically we


would consider one to be kind of the root of a folder


and the other a file name within the higher level folder.


So we wouldn't, by default, try to equate those.


If we crawl them and we see the same content,


then we pick them up and we try to use them


for canonicalization.


So that's something that then kind of happens


as a second step.


And depending on the way that you have the site verified


in Search Console, if you just have that subdirectory verified


and the URL is the one without the trailing slash,


then we would assume that URL is no longer a part of that site


if you focus on the subdirectory.


And we have that same problem right at the moment


with our kind of new search documentation, which is also


hosted on developers.google.com slash search


without a trailing slash.


And we have the URL with the trailing slash verified


in our Search Console account.


So we kind of have a similar situation


that sometimes we just don't see the traffic or the clicks


and impressions there.


Thank you.


Sure.


All right.


Any other questions before we get started?


Uh-oh.


Hi, John.


I got one.


So quickly on the core update that was released yesterday,


one is, can I have some understanding


on the rationale behind the timing of that


if you at all were involved or saw any some type of emails


around why you timed it for right after Cyber Monday


but before the holidays?


What's the rationale there?


I don't know.


From my side, it feels like a reasonable time.


Like, I wasn't involved in the decisions there.


But it's like not really in the holiday season


and kind of after the whole Thanksgiving rush.


So it felt like, at least from my point of view,


it wasn't something that I would have flagged and said,


oh, you need to watch out for this.


OK, thank you.


And two, people are asking me, with the core update,


this doesn't mean passage indexing or ranking is out.


That has not gone out with this.


It's not live yet in terms of the passage indexing.


I know, because you said at the end of the year,


passage indexing will be live by then.


But it's not out yet, right, as far as you know?


I don't think.


I mean, I don't know if it's out yet.


But usually, the core update wouldn't be something


that we would bundle with other kinds of changes like that.


So it's something that maybe is coming out at the same time.


But it wouldn't be because of the core update.


It would be kind of like more of a coincidence.


I don't know what the timing plans are for that.


OK, thank you very much.


Appreciate it.


Sure.


Hello.


Hi.


Yeah.


Hi, John.


How are you?


I left you one of the comments on the post.


But I just wanted to ask you, because I


thought that I would not make it that clear.


And I thought it was easier to tell you by voice.


So basically, the problem that we're facing,


and what I wanted to ask you is if you guys still


have reports on any canonical bugs for USA content


and for USA country, because what we do


is we're a sports international media company.


And we've been having a lot of problems


with our live blogs, which usually has recurrent themes,


because they play two times during the season.


And only in US selected as language and selected as,


I mean, English as the language and USA as the country,


we don't show up, even though Google Search Console,


it's reporting that it's indexed.


But the funny thing is if you go to UK with English language


setup, we show up as the first SERP in most of the searches.


So it's something that is happening specifically just


for US.


And it only happens for our live blogs,


which we assume it has to do with something


that it's recurrent themes that we're mentioning,


because we're not really having the canonical bugs for any news


that is happening, which we only report once.


So I was wondering if you guys have


any reports on the canonical bugs that it still happens,


because they just started happening maybe two months ago.


Before that, it was perfectly normal showing up as usual.


Yeah, I'm not aware of any issues


around the canonicalization and indexing at the moment.


And also from how you describe it,


it sounds like it's less an issue of indexing


and more an issue around internationalization


for the site.


So just to double check, do you have separate URLs for the UK,


or do you have the same URL that is just visible in the UK


but not visible in the US?


It is the same URL, and we just place ref length.


But our source, it's as a publisher for US.


So everything is working supposedly the way it should.


It just stopped working two months ago,


and it only stops working for live blogs, which


we use recurrent themes.


If we make a live blog of, I don't know,


a game that hasn't been happening much,


or from a team that is not that common,


it shows up perfectly, which makes it really, really tough


to understand why this is happening.


Yeah.


I don't know.


To me, that doesn't sound like an indexing bug.


That really sounds like something


around internationalization.


And the hreflang side there might also


be something that's playing a role there.


How do you have the hreflang set up?


Is that one English URL and then a Spanish URL or a French URL?


Or how do you link those?


Yeah, we just have one URL, and we just then place it.


It's for nUS or nOnly or nMX, depending


on which countries we're trying to attack through the hreflang.


OK.


I'd have to look at the specific details.


But offhand, it feels like something where maybe


with the hreflang setup, something is not quite the way


that it should work.


And that's something that sometimes causes more problems,


sometimes causes less problems.


But probably that's something that you'd


be able to resolve there.


What you could do is maybe post some of the details


here in the chat.


And I can pick up the chat afterwards or post


the details in the Help Forum as well so that some other people


can throw some eyes at it.


All right, John.


So I will post it on the forum, and then I


will let you know where it is so you can check it.


Thank you so much.


Sure.


Thanks.


All right.


I think someone else is trying to jump in and ask


a question as well.


Go for it.


Yes.


Hello, John.


Do you hear me?


Hi.


Great.


So as you maybe know on the Twitter right now,


so we have a problem with the Discover feed in Sweden.


We have had that since, I think, like in the middle of December


last year.


And it's a fairly amount of sites that have this issue.


So yeah, these sites are not showing up


in the Swedish Discover feed when you are in Sweden.


But if you turn on a VPN, then it's turned on.


And yeah, of course, if you are outside of Sweden


and go into the Discover feed, it's also showing up.


OK.


I don't know offhand about that because I


believe that's something that we already passed on a while ago.


And you're still seeing this happening


with no changes at all?


Yeah, yeah, yeah.


Exactly.


I can show you if you want.


Or maybe you can post a link in the chat here.


Then I can pick that up afterwards.


Yeah, of course.


Of course.


Cool.


Pretty great.


Thank you.


Great.


Thanks.


OK.


Let me run through some of the questions that were submitted.


And we'll definitely have more time for your direct questions


as well along the way.


Let's see.


I'll try to run through these fairly quickly


since it seems like lots of questions are here.


When it comes to anchor text from external links pointing


to my website, do you check the anchor text only


on a page-by-page basis?


Or do you also look at site-wide anchor text?


We look at both.


So we do look at it on a per-page basis


to understand the context of individual pages.


You notice this in particular if a page


is blocked by robots.txt and is still indexed,


then you'll see the anchor text as something


that we might use as a title in the search results


for that page.


But we also look at the anchor text for sites overall


because it does give us a little bit of a broader understanding


of how that site is embedded in the web.


So that's something that we try to take into account


where we can.


We're experiencing huge ranking fluctuations.


Where a specific page drops for most relevant keywords


from the top places to pages 3 to 5


and comes back a few days later.


And this keeps repeating.


We're quite sure it's not just normal fluctuation


since there's a repeating exact same pattern.


These are high volume, high competition keywords.


Any idea what might be the cause of this?


I don't know.


I occasionally see that from people.


It's not something that I would say is completely out


of the question that this kind of thing happens.


Oftentimes, it settles down because our algorithms


figure out, oh, this is kind of a stable place, how


we should be ranking this site.


If your site used to be ranking much lower,


then this could be a sign that our algorithms are kind


of wondering, should we be ranking a lot better?


If your site used to be ranking better for this


and sometimes gets dropped down like that,


then it could be a sign that our algorithms are a little bit


cautious more maybe.


So that's something which I would kind of take as a sign


to significantly improve the quality of the website overall


so that our algorithms are less on the fence


and have kind of clearer understanding


that this is actually a really good website that we


should be showing more.


Then my website is losing indexing.


For some weeks, my website has been losing indexing


for no apparent reason, and no significant changes


have been made except for the usual ones that are adding


and removing vehicles.


So the website was mentioned there,


and I took a brief look beforehand.


And one of the things that I noticed specifically


with regards to the indexing of the content on the website


is that it's really hard to crawl and index


the content from your site.


So for example, if I do a site query for the website,


then a lot of the pages that I find


are kind of weird listing pages where


I suspect maybe a vehicle or product used to be available


and is no longer available, and it's kind of like with an ID


of a very high number.


And my general feeling is there that we're just


having a lot of trouble crawling and indexing the website.


So that's something where what I would do


is try to figure out which URLs you really care about.


And first of all, put those in a sitemap file


if you haven't done so already.


And then secondly, try to figure out


are these URLs actually being indexed properly?


And additionally, look at the other URLs


that are being indexed for the website at the moment.


If you look at a site query, that's kind of a rough idea


to do that.


And think about how those URLs were discovered.


So the URLs that you don't care about,


why is Google spending so much time on them?


With the end goal essentially being


kind of making it really clear for search engines which URLs


you want to have indexed, being absolutely certain


that Google can crawl your website normally


and find those URLs and can focus on just those URLs


that you care about.


So that's kind of my recommendation there.


Sometimes it also helps to use something


like a third-party crawler tool to kind of crawl your website


if you're not sure where these URLs are being picked up on.


There are a bunch of different tools out there.


Some of them are really good.


So that might be an option to kind of try out


while you're figuring out why are search engines kind


of getting lost within my website.


Mobile searches related to glasses or prescription glasses


are resulting in duplicate content on the same page


in the first search results page.


It's due to the interesting find section, which seems odd.


Are you aware of this behavior?


Does Google consider this to be an issue?


So I don't know exactly what you're seeing there.


So it's really hard to say.


In particular, a lot of the different sections


in the search results page trigger in individual countries


or trigger differently in individual countries.


So when I search in English, I tend


to get Swiss sites in English.


I don't tend to see exactly the same thing


as users in the US would see.


So that kind of makes it hard for me


to figure out what exactly you're seeing there.


If you can send me some screenshots


or maybe post them on Twitter or add them here


to the YouTube comments, then I'm


happy to take those and also send those to the teams


here that work on the search results page.


I think, in general, when it comes to different elements


on a search results page, it's always


kind of tricky to find that balance between providing lots


of usefulness for users, lots of value for users,


and ultimately providing too much clutter, essentially,


in the search results, where if you look at the search results


page, there are just so many different items there,


and they're all kind of competing for your attention.


And sometimes it can happen that you have different sections


that show the same content, which, from my point of view,


is kind of just, I don't know, unnecessary clutter.


It's not something I would consider


to be a serious bug or anything like that,


or it's definitely not something we would do on purpose.


But sometimes it just kind of evolves


in that direction over time.


And having examples where this is kind of annoying,


that's really useful to pass on to your team


so that they can understand, oh, if these different elements


in the search results page are triggering and showing,


we should make sure to not show the other thing here


because that's essentially showing the same thing


or not as useful for the user.


I'd like to know how Google indexes sites


with new extensions, like.club or.tools.


Is there any preference for indexing.com domains over


these?


So we treat all of the new top-level domains


like any other generic top-level domain.


So there is no kind of additional value


to having keywords in the top-level domain.


There is no additional value in having city names or country


names in the top-level domain.


We treat them all like any other generic top-level domain,


like a.com, essentially.


So from that point of view, if you


find a domain name that works well for your site


that you want to keep for the long run


and it's a new top-level domain, then definitely go for it.


I think that's perfectly fine.


But also, keep in mind that there


is no kind of bonus for using a particularly well matching


top-level domain.


It's not that we would, from an SEO point of view,


treat those as anything better than other generic top-level


domains.


What happens to visitors if we post duplicate content


regularly?


I don't know.


I mean, visitors are kind of out of our control.


But from my point of view, if you regularly


post duplicate content that is already on your website


or that's findable on other sites,


my assumption is a lot of times visitors will just


end up going somewhere else.


Because why should they go to your site


if they've already seen that content somewhere else?


So that's kind of one of the reasons


also why we discourage people from just copying content.


Because it's something our algorithms can pick up on.


And we know users don't like it when


we show the same content multiple times,


kind of like the previous question there.


So that's something where if you want


to provide something on the web and you want to make sure


that's visible in search, make sure it's unique, compelling,


high quality, all of the usual attributes.


If our business has good ratings on some authentic websites,


can showing those ratings on our site


influence algorithms or rankings?


Not considering user behavior, I don't


think that changes anything.


So if you have a five star rating from some other service


and you put that on your website,


I don't think our ranking algorithms will look at that


and say, oh, this sounds like a good thing.


So from that point of view, from just purely an SEO standpoint,


I don't think that changes anything.


Obviously, users might care.


If you show users that your website is trustworthy,


that it's regularly kind of audited and kind of reviewed,


then that's something that they might care about.


But at least from an SEO point of view,


there is no immediate ranking change.


With this new passage indexing rolling out soon,


will this help a site, for example, a blog,


to get better rankings for more opportunities,


for more search terms per article that is published?


So the passage ranking or passage indexing update


that we talked about there, like I mentioned in the beginning,


I don't know the timing of this, when it will be visible where.


But essentially, the idea is to take particularly long pages


and understand the relevant parts within that page


a little bit better so that we can show those appropriately


in the search results.


So that's something, if you have really long articles,


then it might be that we pick up something useful in the middle


and we send users to that directly.


If you've been doing SEO for a while now,


if you've been focusing on your website for a bit,


then probably you've already split those exceptionally long


articles into shorter ones anyway


so that it's easier to focus on specific aspects of what


people are searching for.


And in those cases, there's nothing really


that you need to do there.


So that's something where I like to see it more as if you have


really long pages on your site and you've never really bothered


to watch out for what users actually want and realize that,


oh, users are looking for a part of the page, not the full page,


then that's something where I assume passage ranking will


help out a bit.


But it's not the case that we'll just take any article on the web


and say, oh, there's a good word way down


on the bottom of the page, therefore we


will rank this page higher.


It's not a general ranking improvement.


It's more a better understanding of the content.


John, can I follow up on that?


Yes, so I had a question that was very similar.


You answered part of it in there where you had said,


if you're a good, savvy SEO, you may have already


taken a long page and split it out into multiple pages.


So I guess what I'm wondering, so that is still


the recommendation, I guess.


So I had an example of, let's say


you have a business that offers four or five services.


Previously, I would have always taken that and done


and created five separate pages, one for each service,


so that Google would understand the topic of that page.


But with passage indexing, I was wondering,


perhaps does it make more sense to have one single page that


lists all five services, potentially hoping


that passage indexing or passage ranking,


as you've said a couple times now, passage ranking


understands each chunk?


And the reason why I think that that could be advantageous,


perhaps, is consolidation of link authority and link


building.


So you have one URL now that has multiple links,


and that page could be very authoritative.


Do you think that strategy makes any sense,


or would you still go to one separate page for each service?


I don't know.


So from my point of view, I would test it.


I would see how it works.


I don't think by design that's necessarily a bad way to do it.


I also don't think it's necessarily always going


to be the right approach, because when users are looking


for something that's kind of on the bottom of the page


and they land on the top of the page,


then maybe they'll be lost and your conversions


will suffer a bit.


But I would definitely try it out and see what happens.


I could imagine that maybe you find a balance that works well


and is kind of positive under the line for you.


So theoretically, that's how passage ranking or passage


indexing could work, where now, if previously they


had this one page with 10 different services,


it'd be hard to understand the topics of all of them.


But now passage ranking might better understand,


well, this is about service A, this one's about service B,


and then rank those sections or passages


appropriately for queries.


So this theoretically could work.


Could it be better?


I guess that's to be tested.


Yeah, I don't know.


I mean, it's kind of tricky, because we could still


understand that that part of the page


is appropriate for that query.


But would there perhaps be a factor


saying, well, the other parts are kind of contrary


to that part of the page is understanding?


Like, if you have completely independent services,


then it might look like, oh, you're offering consulting


and you're selling products.


And if someone is trying to buy a product, then it's like,


well, how do we weigh these things?


Yeah, that totally makes sense.


If it's way off, yeah, that probably,


but maybe an electrician that offers outdoor lighting,


interior lighting, all these different services,


they're all electrical services.


Yeah, OK, that's cool.


I might give it a shot.


I would try it out.


I mean, all of these new things I think


are just always interesting also to see how they kind of react


to something like that, where you kind of have


an understanding of what you would expect,


and you can see if you would see changes like that.


Wonderful.


I'll wait for you to tell us when it goes live.


I mean, you could also do something like that now


and see what the effect is currently,


because some effect will also be there,


because it's always this balance of taking multiple pages that


kind of have to rank on their own, you're diluting the value,


or you're concentrating that value on a single page.


So some effect you might see already,


and when we switch that on, you might see,


oh, well, overall, there's an even stronger effect now.


But I honestly don't know.


And I think it's something that probably depends quite a bit


on the type of site that it is.


So just taking any random 10 pages


and putting them together on one page,


that's probably a bad idea.


But maybe there are certain configurations,


like you mentioned, where it could make sense, yeah.


Awesome, thanks so much.


Sure.


And I have your question next.


Is there anything else that you'd


like to add there with regards to passage indexing?


No, you covered it very thoroughly.


Thank you.


OK, cool.


Are you still planning on dropping support


for the webmasters discovery document?


End of the year?


There haven't been any updates since the original blog


post in August, and I urgently need to plan changes


if this is still true.


I just double-checked with the team.


I haven't heard back.


So I'll double-check to see what is happening there


and maybe post an update in the YouTube comments


to your question.


From looking at the old blog post from August,


it seemed like it was pretty clear


that we're going to drop that discovery document.


But maybe there's a new discovery document


that you can switch to.


I don't know.


Feels a bit like I'm following you,


but I could really use your help.


We have a website, which is a finished site, that


got penalized in January for thin content.


Since then, we basically rebuilt it


from scratch, addressing every possible issue related


to thin content.


Affiliation on the site is minimal and with value to users.


We're trying our best to make the site as good as possible


for them.


But we keep getting rejected from the reconsideration


request.


And not sure what to do now.


And in general, how does a site owner


get more clarity when dealing with such issues,


such as manual actions?


So kind of to the last part with regards


to getting a bit more clarity, what


I would recommend doing there is posting in the help forum,


in the Search Central help forums.


Because like I mentioned, the product experts


have seen a ton of websites.


And they can give you advice in lots of different directions,


especially with regards to manual actions.


A lot of those cases also end up in the help forums.


And they can escalate issues where appropriate


when it looks like someone from the web spam team


might need to take a better look at that.


So that's essentially the place that I would go there.


I think I briefly looked at your site.


And the manual actions that were associated there.


And I didn't double check with the web spam team


with regards to what you should be doing


or what you could be doing differently there.


But one of the things I noticed is


that you have a lot of different sites that are essentially


focusing on very similar topics.


And I know the web spam team sometimes uses this kind


of manual action as well to help clean up these issues where


you have a ton of different sites that are essentially


targeting the same keywords where


it tends to look more like a collection of doorway sites.


So that's something where, if that's the case,


if you have a lot of different sites that are essentially


all the same content, then that's


something I would try to resolve in addition to just fixing


things on this one particular site.


Because one of the things the web spam team kind of worries


about is you fix this one site.


And your manual action is resolved there.


And then you take that, and you use that


across a big network of sites.


So that's something at least to address in a reconsideration


request when you submit that.


And probably something the product experts would also


pick up on where when they look at your thread


and look at your site, they're like, oh,


but what about this network of sites that you have here?


What is the relationship here?


And if you end up not getting anything useful from the Help


Forum, feel free to escalate it here


in one of these office hours again.


And I can pass that on to the web spam team


directly to see if I can get something more specific


that I can point you at.


When considering multi-language and multi-regional sites


and hreflang implementations, is there


any problem with combining usage of subdomains, country


code, top-level domains, generic top-level domains,


and subfolders?


For example, example.com slash uk or fi.domain.com


or domain.se.


You can definitely combine all of these.


For hreflang, it doesn't matter at all which URL patterns


that you use.


For geotargeting, we need to be able to understand


a clear section of your site.


And in particular, for geotargeting, what we look at


is either the country code top-level domain


or, if you have a generic top-level domain, the setting


that you have in Search Console, which


you can apply on a subdomain or subdirectory level as well.


So something like domain.com slash uk


would be perfectly fine.


You can set geotargeting for that.


However, something like domain.se slash uk,


that would not work for geotargeting


because we would see that as being part of a country


code top-level domain.


And we would not let you set the UK geotargeting


for that subdirectory.


But for hreflang, if you just have


the same content on different pages


and you don't care about geotargeting,


then that's perfectly fine.


In general, with hreflang, I would use hreflang


when you're seeing issues with the wrong country


version being shown in the search results.


A really common use case is if you


have an international brand where someone searches


for a brand name.


And just from the brand name alone,


we don't know which language version


that we should show the user.


Then there, hreflang helps us to pick out


which version we should show.


Whereas if someone is already searching


in a specific language for a generic term for a product


or for your services or something like that,


then the hreflang annotation is not really that helpful


because we already understand this user is


searching in that language.


Therefore, we should show that user that content.


So that's something to keep in mind ahead of time


when you're planning the implementations there.


With hreflang, it's very easy to set up


very complex implementations.


And a lot of times, you don't need to have complex hreflang


implementations.


You might just need it on a handful


of pages across your website.


When determining search ranking or where to position websites,


apart from organic traffic, does Google


consider traffic from other sources like YouTube


or Facebook or Pinterest?


So if a user enters a page via a social media platform,


finds the information useful and relevant,


does it have any effect on search rankings?


No.


At least, as far as I know, none of that applies.


It's not the case that we would track that for search.


It's not the case that we would use that


for any kind of search ranking.


So if you're using social media and you're driving traffic


to your website, that's fantastic.


But I would see that as something


that you do for social media and not as something that you're


doing for SEO reasons.


Of course, you can kind of combine


that in looking at the longer view.


So if you drive traffic to your site using social media


and you encourage them, for example, to link to your site


or to recommend it so that we can pick it up for search,


then indirectly we could pick that up for search.


But it's definitely not the case that just because someone


comes from social media, we would rank the site higher.


We have a relatively high volume of URLs in discovered,


currently not indexed in Search Console.


What can we do to get Googlebot to crawl those URLs?


Is having a CSR, so I guess client-side rendering,


a contributing factor for this issue?


I don't think client-side rendering


would be associated with this because we would still


be able to crawl those pages regardless.


And client-side rendering, so kind


of like if you have a JavaScript-based website


and we have to do JavaScript to pick up the content,


that's something that usually is less problematic with regards


to indexing.


We can do that fairly easily.


Usually, if you have a lot of URLs in this discovered,


currently not indexed section, that


means we've crawled your website.


We've seen a lot of these URLs.


But we currently are not convinced


that indexing them will be valuable to our users.


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


technical that you need to change on your website,


but more a matter of making it clear to us or to the search


engines in general that actually all of this content


is very important and useful to have index.


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


and focus a little bit more on kind of quality


rather than just purely quantity.


In general, it's extremely common for websites


to be partially indexed.


That's kind of essentially that's normal.


And the indexing rate of any website


will fluctuate over time.


So that kind of that number of discovered but currently not


indexed, that number will always fluctuate,


I think, regardless of the type of website that you have.


We had m.urls for mobile site, which


were used as alternate versions for the desktop version.


We now have just the desktop version, so www.


And the m.urls are redirected.


Should we use a change of address tool in Search Console?


Will it change anything with SEO or a crawl budget?


You don't need to use the change of address tool.


That's something that we would just pick up the versions


automatically.


So if you're redirecting, then we will pick that up.


There's no need to use a change of address tool.


The change of address tool is more


if you're actually moving between different websites.


In this case, you're essentially going from m. to www.


And that's kind of within the same website.


So there is nothing special that we need to do there.


With regards to crawl budget or SEO, this has no effect.


So what will happen there over time


is we will primarily crawl the www version of the URLs.


We will occasionally look at the m. versions


because we might still find links to those pages


or we just want to make sure that we're not missing anything.


But for the most part, we'll concentrate on the www version.


And from a crawling point of view,


that shouldn't be any change overall.


Can additional properties and schema,


which are not mentioned in the Google documentation, give


any benefits to Google, especially


in the case of AMP, non-AMP article schema?


If we add AMP article properties on non-AMP pages,


is there any harm or benefit?


So there is probably no benefit at all and probably also


no harm there.


In general, we recommend using structured data for elements


that you want to have visible in the search results.


And the ones that we have visible


are based on the properties that we have documented.


So if you add structured data for things


that we don't use for visible rich results,


then we can crawl those pages still normally.


We just don't use that kind of extra information.


It's fairly rare that you would be


able to provide some structured data on a page which gives us


unique information that we don't see from the page itself.


That helps us to understand that page better.


And I think, in particular, the AMP article markup,


that's not something that tells us something


different about the page.


It's just a different way of providing metadata


for the page in general.


So it definitely wouldn't cause any problems,


but I don't think you would see any advantage of doing that.


The mobile-friendly test is showing our page


as mobile-friendly.


But when I generate the report through Lighthouse and Chrome


inspection, it's showing me some issues like tab targets


are not sized properly.


Can that influence our rankings?


So if the mobile-friendly test is saying things are OK,


if the Search Console mobile-friendliness report


is saying things are OK, then you should be all set.


The tricky part with mobile-friendliness


is there's no objective measure to say this


is mobile-friendly or not.


In particular, like the tab targets that you mentioned,


you could argue with people that there's


a certain size tab target that needs to be there by minimum.


But that's not something that necessarily


will be the case across all different sites


or all different devices or all different people.


So that exact size that kind of is valid for a large enough tab


target, that's something that could vary across


the different testing tools.


So if you purely care about how Google Search sees


your site for mobile-friendliness,


then I would use those tools.


If you kind of want to get a better view of how other tools


might see your site or give recommendations


with regards to mobile-friendliness,


then I would definitely take those other tools


into account as well.


OK.


SPEAKER 2


Hello, John.


Hello.


That was my question.


Actually, I have a follow-up.


Recently, we have revamped our site.


And since then, GSC is reporting mobile-friendly issues.


But when we do a live inspection within GSC,


it shows that the URL is mobile-friendly.


Should we consider that as an issue or not?


JOHN MUELLER It's hard to say when you say you've


re-ramped your site.


My general assumption is if the mobile-friendly test


says it's OK, then I would not worry about it.


I assume that those issues in Search Console


are mostly with regards to kind of rendering your site.


And because we cache some of the embedded elements on a page,


also like the JavaScript and CSS,


it can happen that we have kind of a mixed view of a site that


has just been revamped completely.


So my assumption is, without looking


at those specific examples, that probably this


is just a temporary phase.


And things will settle down over time,


like over a couple of months, then


our kind of understanding of the site


overall with regards to mobile-friendliness


that settles down again.


Cool.


Yeah, I think the only new question that came


was with regards to the update timing, which


I think we chatted about with Barry already in the beginning.


What else is on your mind?


What else can I help with?


Hi, John.


OK, you can stop.


Oh, OK, OK.


John, I have the question about duplicated content,


because you replied to this question


that it depends on the situation.


And if you are talking about moving service, for example,


if we need to move stuff from Toronto to Vancouver


or from A to B, and I found that many pages on the top 10,


they have two pages separate.


For example, if we want to move from Toronto to Vancouver,


this page usually submits some information


that are related to Vancouver, why you need to live there,


better school, better shops, and something like this.


And if we create two pages from Vancouver to Toronto


and from Toronto to Vancouver, is it OK?


Or because we have similar titles,


Google will understand that these pages


have different content?


Yeah, I think it's hard to say comprehensively there.


So for just the situation where you have two cities like that,


I don't see a problem.


That's kind of like you have a handful of pages,


and you kind of add the alternate versions


of those pages.


If you take all of the cities in Canada


and you say all of the combinations,


then that's essentially a giant network


of unnecessary content on a site that we would probably


see as doorway pages.


So that's something where finding


the balance between providing value to users


and just filling it out with a database


because you have a database of cities, for example,


and you have some information from Wikipedia on every city,


just because you have that doesn't


mean that those are going to be good pages.


But users have different intent when


they are searching for service to move stuff from Toronto


to Vancouver.


And they want to know about Vancouver.


And when I check out the top 10 results,


I see that they submit this information.


It's not only about some Wikipedia page about Vancouver.


They reply to some questions that people


might ask their intent, the distance from these cities,


and something similar.


And we don't know, do we need to create two separate pages


or just to create one page?


JOHN MUELLER I would just create one page,


especially if you're talking about a large amount of pages.


Then that's something where I would try to limit it


on the number of pages.


I think it's sometimes misleading


when you look at the search results and you see, oh,


other people are creating this kind of thin content,


automatic content in different variations.


Therefore, we also need to do it.


I think that's sometimes misleading.


But especially when you're starting out,


I would focus on a lot fewer pages


and make those a lot stronger.


So especially in competition with other websites,


having fewer pages that are just significantly stronger


makes those a lot more valuable.


And it's also something where you


need to watch out for kind of misleading yourself with


regards to the user intent.


So kind of the question that you had there,


well, users might want to find out more about the city.


I really doubt that someone who is looking for transport


services from one city to the other


wants to have background information about neighborhoods


in the city or something like that.


That's something where it's very easy to get


this kind of information and just put it on a web page,


because you can.


It's like there are APIs, and the data is there.


You can rewrite it automatically.


But I don't think it provides value.


And more and more, our systems are such


that we understand when pages are being compiled


automatically.


And then we will say, oh, maybe the whole website


is just automatic content.


We should demote the whole website.


So that's kind of the long-term view.


I would focus more on having fewer pages


and making them a lot stronger.


AUDIENCE 1 OK, I understand.


Can I ask in more details?


For example, when people are searching,


moving from Toronto to Vancouver,


they are living in Toronto.


They know about the city.


And if I submit a lot of information about Vancouver,


if someone wants to move from Vancouver to Toronto,


they will read information.


They don't need it.


They don't need to know more about Vancouver.


They want to know about Toronto.


And at that point, we can confuse some people


to submit information they don't need at all.


JOHN MUELLER I would argue they probably


don't need the information the other way around either.


If you're trying, imagine you're in this situation.


You need to move to a different city for work.


Do you need background information


on what the weather is like there?


You're looking for a transport company.


You're not looking for city information.


Whereas if you're looking for city information,


then you explicitly look for city information.


You don't say, well, oh, look, on this transport company page,


there is now a weather report from the other city.


How useful.


That's something where it's very easy to provide


this kind of information.


But I don't think it's something that search engines would say,


oh, this is so useful to have this extra information here.


They really try to focus on that individual query.


AUDIENCE MEMBER 1 Worth it.


Thank you.


JOHN MUELLER Dave, I think you had a question.


AUDIENCE MEMBER 2 Oh, yeah.


Just a quick one, really.


I was quite interested to see that the call web vitals will


count for noindex pages and things


box with robots text and stuff.


It's quite interesting because obviously in Search Console,


these are aggregated.


You get a group of pages.


How do you understand that this is a group?


If these are noindex, then you've


not got the context and stuff?


Or is it just based on URL path?


And I know it's not even a ranking factor yet.


So in the future, we don't really


know exactly how it's going to apply.


But that's quite worrying if you've got something


in the members area, some kind of tool that takes a while,


you've got bad vitals, but it's not really bad


because it's expected.


It's what it is.


If that's going to leak out into your other site,


that's probably going to be quite worrying for some people.


JOHN MUELLER I don't know.


I mean, my general feeling is there


that that's something that's also part of your website.


So if you use some extra functionality


and that's noindex, then people see


that as a part of your website and say, well,


this website is slow or this website is fast kind of thing.


I don't know how Search Console reports on that particularly.


I think within the Chrome User Experience Report


data in the Chrome Developer site,


they have some information on how the grouping is made.


But I don't know how detailed that is there.


Right, sounds like a good one to go with.


Thanks, John.


I mean, one of the tricky parts is also


it's very hard for us to understand


when a page is something that is not


meant to be indexed because all of the canonical decisions


and all of that, just looking at an individual page on its own,


it's sometimes not absolutely clear


is this something that can be accessed directly


or does that cookie that was set in the beginning


need to be set to access the page


or what all is involved there?


So I imagine that's always kind of tricky to balance out.


Yeah, a lot of moving parts.


John, I had one follow up on that.


It is actually very interesting.


I was also thinking the same.


So from a SEO side, how SEO team should be worried about it?


Because there are a lot of pages that are noindex,


a lot of pages, especially in travel websites,


there are so many search pages.


On that case, then how to ensure that pages are not at least


decreasing the mobile ranking?


It is very tricky for us.


I don't have any great answers for you at the moment.


So should we expect it till May there


should be some document update?


Maybe.


I don't know what the information out there


is on the grouping at the moment.


So it's really hard for me to say exactly what you need


to watch out for or what you can kind of ignore.


In general, when it comes to grouping across websites,


when we try to do grouping, we try


to do that on the one hand by URL pattern and on the other


hand also by the kind of content on the site.


And those are, I think, the way that we do the groupings


in Search Console, for example.


So if you have parts of your website


that you want to be seen as belonging together,