The weird thing is the canonical makes no sense.


English Google Webmaster Central office-hours from June 23, 2020

It's like a news page, and the other one is a weather page.


So it's very clearly distinct.


Yeah.


Usually what happens in cases like that,


where our systems get confused about this kind of thing,


is that we try to understand the URL structure.


And it's not so much at that point anymore


what is actually shown on this URL,


but rather it's like our systems have determined this part


of the path is irrelevant.


So we don't even look at it.


And then we say, to simplify things,


we will fold it together as this canonical.


So that's something where my guess is something like that


is happening there.


And maybe our systems pick that up at some point


when maybe it wasn't as clear within the website how


these things were structured.


But this is usually something that we can resolve on our side.


So I'll check with the team.


Thanks.


Sure.


All right.


We're kind of running low on time.


Let me see.


One last question in the list.


And then we'd have it kind of complete


unless someone submitted something new.


What would you suggest as a better solution for users


and machines having a permanent redirect of all 404s


via meta refresh of five seconds to the home page


so that users can find a search box and helpful links,


such as popular stores and categories,


or having a designated 404 page showing


that the pages no longer exist and helpful resources?


A real 404 page is always preferred.


So if you remove content, serve us a 404 page,


we can understand that the content is gone.


We can reduce our crawling of those URLs.


It's completely fine.


Redirecting people to the home page is confusing for users.


It's confusing for us as well because for us,


we see that and say, oh, this looks like a soft 404.


So we will generally end up still crawling a little bit


more but still treating it as a 404.


So you might as well just give us a clear 404


and make that 404 page user friendly.


All right.


I'm sure there are some more questions that


got submitted along the way.


But maybe we'll switch to live questions from you all.


So anything that I can help with?


Hi, John.


My name is Ruchit.


And I posted on channel also, but I just joined later on.


So we have an event website which


has around 250 million events.


And currently, we are facing a huge issue of crawl budget,


especially as we are having 250 million events.


But most of the events are past.


So that doesn't make sense for Google and our first two.


So we get our most of traffic on the 5% to 10% events,


which are upcoming events.


So we want to de-index all these past events.


But what we are seeing for that, we


added that no index tag in the pages.


But what is happening is every day,


we are seeing that Google is crawling


three to four million pages.


And most of them are past event page.


So our upcoming events are taking long time


to get indexed, and it's like how to fast,


like how to de-index these pages faster.


So we don't have to wait Google to crawl all of these 200


million event pages and then de-index it.


OK.


So I think there are two things you can do.


On the one hand, there is the unavailable after meta tag


that you can use, which is the unavailable after meta tag.


Which tells us ahead of time when this page will no longer


be available or when it will be irrelevant.


So that's something you can use going forward.


If you have an event that takes place at some point,


you can say unavailable after maybe, I don't know,


a month later or whatever you decide.


That helps us to understand that these pages are


going to go away fairly soon and to help us to focus


our crawling on other ones.


And the other part is if you just kind of relatively


recently added the noindex to the old events,


then that's something we just have to process.


And that can take a bit of time.


I wouldn't worry so much about it


because usually this kind of refresh crawling that we do


is something that is usually lower


priority within our systems.


So we do try to prioritize the crawling of new pages


that we discover on your website.


And if we recognize we still have room to recrawl old pages,


we will recrawl the old pages as well.


From an absolute numbers point of view,


it can look like we're crawling 10% of the new pages


and we're crawling like 90% of the URLs are really old pages.


But that's essentially just because the 10%


crawls from the new pages we think


are kind of the important parts that we should


be picking up for indexing.


So I would try to let this settle down


over the course of maybe, I don't know, half a year


or a year.


And I assume that at that point, we


will be able to focus a lot more on the newer pages.


And we'll have recognized that the old ones are really


gone in the meantime.


But even when we recognize that they're gone,


because you have so many of these old pages,


we will still occasionally try them.


So if you look at the absolute numbers in your server logs


later on, you will probably still


see that we crawl a lot of old pages.


But again, that's not because we think


these are important pages, but rather just because we


know they exist and we just want to double check.


Another thing you can do to make sure


that it's clear to us which pages we should be crawling


is to have a clear internal site structure in that regard,


in that maybe you take the really old events


and you move them into an archive section of your website


that isn't linked so prominently within your website.


And you really prominently focus your internal linking


on the new events that are upcoming.


So make it as clear as possible when we crawl your website,


this is what you want us to focus on.


And oh, I also have all of these other old ones here.


But you can find your way there, but it's not the most visible


part of the website.


Thanks, John, that helps.


John, can we talk about updates?


Or I haven't asked you about updates in about 2 and 1


and 1 2 years.


OK.


I don't know.


Could you name what's going on this week, the past couple


of weeks, June 10th, June 18th, today?


Lots of little fluctuations.


We call it something?


I have no idea what you're referring to.


So I don't think we have a core update at the moment.


Right.


Nothing was confirmed.


Danny didn't tweet anything.


You're not aware of any tweaks.


It seems to be a lot of fluctuations going on.


I know Google's always fluctuating,


constant changes, yada, yada, yada, but no idea.


I don't think it's, I mean, I don't know.


There are always things happening within Google.


So it's really hard to say.


But I'm not aware of anything specific where it's like, oh,


we're doing something crazy here.


And people might see this kind of thing.


My guess is these are just kind of the normal things that


are happening.


OK.


Last chance.


No change.


You don't want to name it.


I don't even know what I'm naming,


if it's a good thing or a bad thing.


So it's hard.


I didn't see a lot of stuff on Twitter


where people were seeing changes.


So I don't know.


I guess I'll watch out for your blog and see what you say.


I really don't know.


Hi, John.


Can I ask a bit of a follow-up question


to what I wanted to speak about earlier,


about you can sort of look through URL structures


and see if pages belongs to go through there.


So would that mean that something


that has quite a flat URL structure


might be a bit of a disadvantage in that respect?


I think we would probably still be able to figure out


parts of a URL like that.


But if you have an extreme case where you have no folders


at all, then it does make it a little bit trickier for us


to understand which parts are really relevant or not.


So for example, compared to something


where you have clear URL parameters, where


you have city name equals this and language equals that,


then it's a lot easier for us to understand, oh,


this parameter here varies and changes the content.


Whereas if it's a really flat structure where you just


have dashes in between all of the parts,


then it's really hard for us to understand


what happens when individual parts are different or don't


exist.


With parameters, we can drop them and see what happens


if they still serve content or not.


Cool.


OK.


So maybe we can take a break here.


I have the next one in English lined up on Friday.


So if there's anything still on your mind,


feel free to drop your questions in there.


I'll see if I can figure out something about updates


that are happening.


I don't know if there's anything explicit we'd be able to


announce, but who knows?


Always something new and surprising.


And we'll see what happens with all of those discussed comments


if suddenly there's a giant surge of indexing


of comments on the web.


We'll see.


All right.


Thanks, everyone, for joining in.


And I hope you found this useful.


And hopefully, see you all again in one of the future Hangouts.


Bye, everyone.


Thanks, John.


Rendering (WMConf MTV '19)

My name is Eric Hendricks.


Rendering (WMConf MTV '19)

I work on rendering.


Rendering (WMConf MTV '19)

Talk a little bit about how rendering works


Rendering (WMConf MTV '19)

and some of the challenges that we've


Rendering (WMConf MTV '19)

run into trying to render everything that goes


Rendering (WMConf MTV '19)

into the Google search index.


Rendering (WMConf MTV '19)

So before we get started, I'll talk a little bit


Rendering (WMConf MTV '19)

about what rendering is, just so that we're all


Rendering (WMConf MTV '19)

on the same page.


Rendering (WMConf MTV '19)

So rendering is the process that allows


Rendering (WMConf MTV '19)

Googlebot to see the same content that we


Rendering (WMConf MTV '19)

do as normal users on the web.


Rendering (WMConf MTV '19)

It's been a long time since web content was a blob of HTML


Rendering (WMConf MTV '19)

that referenced a few images.


Rendering (WMConf MTV '19)

Your browser does a lot of JavaScript and additional


Rendering (WMConf MTV '19)

fetching these days to actually load the content


Rendering (WMConf MTV '19)

that you see in the end.


Rendering (WMConf MTV '19)

Just kind of a visual example of what that means.


Rendering (WMConf MTV '19)

On the left, we have YouTube without rendering.


Rendering (WMConf MTV '19)

And we've rendered it a little bit,


Rendering (WMConf MTV '19)

just to do a layout and get something that we can paint.


Rendering (WMConf MTV '19)

And then on the right, we've actually


Rendering (WMConf MTV '19)

run all the JavaScript on additional fetching


Rendering (WMConf MTV '19)

and gotten all the content.


Rendering (WMConf MTV '19)

So Googlebot needs to do this as well in order


Rendering (WMConf MTV '19)

to see the same content that you do,


Rendering (WMConf MTV '19)

which basically means it needs to behave like a browser.


Rendering (WMConf MTV '19)

That's a tall order, because browsers are complicated.


Rendering (WMConf MTV '19)

They do a lot.


Rendering (WMConf MTV '19)

They're fairly expensive to run.


Rendering (WMConf MTV '19)

Good news is that we actually have a good browser


Rendering (WMConf MTV '19)

available to us.


Rendering (WMConf MTV '19)

So Googlebot actually renders with Chrome these days.


Rendering (WMConf MTV '19)

That's been true since about the beginning of this year.


Rendering (WMConf MTV '19)

What that really means is that when


Rendering (WMConf MTV '19)

we crawl your page with Googlebot,


Rendering (WMConf MTV '19)

we go fetch the content.


Rendering (WMConf MTV '19)

We give it to Googlebot.


Rendering (WMConf MTV '19)

And then Googlebot does what Googlebot, sorry,


Rendering (WMConf MTV '19)

we give it to Chrome.


Rendering (WMConf MTV '19)

And then Chrome does what Chrome does.


Rendering (WMConf MTV '19)

So it runs all the script.


Rendering (WMConf MTV '19)

It loads additional content.


Rendering (WMConf MTV '19)

Googlebot goes and fetches that content on behalf of Chrome.


Rendering (WMConf MTV '19)

And then once everything's loaded,


Rendering (WMConf MTV '19)

we take a snapshot of the page.


Rendering (WMConf MTV '19)

And that's the content that actually


Rendering (WMConf MTV '19)

gets indexed into the web.


Rendering (WMConf MTV '19)

So great.


Rendering (WMConf MTV '19)

This works wonderfully.


Rendering (WMConf MTV '19)

It gets interesting at scale, though.


Rendering (WMConf MTV '19)

So we have trillions of pages in the web index.


Rendering (WMConf MTV '19)

And we want to do this to all of them.


Rendering (WMConf MTV '19)

So things get interesting.


Rendering (WMConf MTV '19)

They get interesting along two axes, mostly.


Rendering (WMConf MTV '19)

And the first one is fetching.


Rendering (WMConf MTV '19)

So if we want to render a page, we


Rendering (WMConf MTV '19)

need to fetch a lot of additional content that's


Rendering (WMConf MTV '19)

going to become visible on the page in the end.


Rendering (WMConf MTV '19)

And then we have to run the JavaScript that


Rendering (WMConf MTV '19)

actually does that.


Rendering (WMConf MTV '19)

So that's a lot more logic than we ran before.


Rendering (WMConf MTV '19)

So I'm going to start with fetching,


Rendering (WMConf MTV '19)

because it's probably the more difficult problem


Rendering (WMConf MTV '19)

from our point of view.


Rendering (WMConf MTV '19)

It's harder for us to solve within Google.


Rendering (WMConf MTV '19)

And that breaks down into basically two things


Rendering (WMConf MTV '19)

that we see.


Rendering (WMConf MTV '19)

And this is all us trying to be good citizens on the web.


Rendering (WMConf MTV '19)

So we don't want to fetch content


Rendering (WMConf MTV '19)

that you don't want us to fetch.


Rendering (WMConf MTV '19)

And we also want to make sure that our crawl volume is


Rendering (WMConf MTV '19)

reasonable enough so that we don't cause problems


Rendering (WMConf MTV '19)

for servers.


Rendering (WMConf MTV '19)

So robots.txt is how you tell us not to grab something.


Rendering (WMConf MTV '19)

But this cuts both ways.


Rendering (WMConf MTV '19)

If you want some content to appear on your page,


Rendering (WMConf MTV '19)

don't block it with robots.txt, because we won't fetch it.


Rendering (WMConf MTV '19)

And then there's just limited crawl volume.


Rendering (WMConf MTV '19)

So we don't want to overload your server.


Rendering (WMConf MTV '19)

So we limit how much we're willing to fetch


Rendering (WMConf MTV '19)

from any server.


Rendering (WMConf MTV '19)

So that's really the big problem.


Rendering (WMConf MTV '19)

And here's a few numbers to put that in perspective.


Rendering (WMConf MTV '19)

So when we render a page, we see about 50 or 60 fetches.


Rendering (WMConf MTV '19)

This number is a little lower than what normal users usually


Rendering (WMConf MTV '19)

see, because we're obeying robots.txt.


Rendering (WMConf MTV '19)

So that actually protects us from some crawling,


Rendering (WMConf MTV '19)

things like ad networks and so on.


Rendering (WMConf MTV '19)

Don't like robots, and that's fine with us,


Rendering (WMConf MTV '19)

because that's less fetching we have to do.


Rendering (WMConf MTV '19)

And if you render a bunch of pages with a large shared cache,


Rendering (WMConf MTV '19)

you can expect to see a cache hit rate around 60% or 70%.


Rendering (WMConf MTV '19)

So if you do the math here and multiply it out,


Rendering (WMConf MTV '19)

you end up with about 20 fetches or so per page.


Rendering (WMConf MTV '19)

Or another way to look at that is my crawl volume


Rendering (WMConf MTV '19)

is going to go up by 20 times when I start rendering.


Rendering (WMConf MTV '19)

So that's a problem.


Rendering (WMConf MTV '19)

That's not going to fly.


Rendering (WMConf MTV '19)

This is the point where I say, hey, I want to render your page,


Rendering (WMConf MTV '19)

and the crawl folks tell me, get out.


Rendering (WMConf MTV '19)

So we have to do something to reduce this number.


Rendering (WMConf MTV '19)

This can't stay the way it is.


Rendering (WMConf MTV '19)

So we cut some corners.


Rendering (WMConf MTV '19)

And the big one that we cut is around HTTP caching.


Rendering (WMConf MTV '19)

Lots and lots of webmasters err on the side


Rendering (WMConf MTV '19)

of marking their content not cacheable.


Rendering (WMConf MTV '19)

And frankly, it's too many for us to really obey those rules.


Rendering (WMConf MTV '19)

So we will over cache.


Rendering (WMConf MTV '19)

We cache anything and everything for long periods of time.


Rendering (WMConf MTV '19)

The best way to cope with this as a webmaster


Rendering (WMConf MTV '19)

is really just to not rely on clever caching tricks.


Rendering (WMConf MTV '19)

Try and make your content cacheable.


Rendering (WMConf MTV '19)

It's good for end users.


Rendering (WMConf MTV '19)

It's good for Googlebot.


Rendering (WMConf MTV '19)

Even when we do that, though, we still


Rendering (WMConf MTV '19)

have a very large fetch volume.


Rendering (WMConf MTV '19)

And there are cases when we can't fetch everything.


Rendering (WMConf MTV '19)

So this happens frequently when there's


Rendering (WMConf MTV '19)

a lot of fan-in onto a single domain.


Rendering (WMConf MTV '19)

So you can think of a comment section


Rendering (WMConf MTV '19)

that's served from a common server.


Rendering (WMConf MTV '19)

Gets a lot of fan-in from lots of sites.


Rendering (WMConf MTV '19)

Harder for us to load.


Rendering (WMConf MTV '19)

So the way to deal with fetch volume issues


Rendering (WMConf MTV '19)

is there's really two things.


Rendering (WMConf MTV '19)

So reduce the number of fetches.


Rendering (WMConf MTV '19)

This has been good practice forever.


Rendering (WMConf MTV '19)

So it's also good.


Rendering (WMConf MTV '19)

And then mostly be resilient.


Rendering (WMConf MTV '19)

So you want to be able to show as much content as you can


Rendering (WMConf MTV '19)

given the set of fetches that succeeds.


Rendering (WMConf MTV '19)

Because when a fetch fails, it basically just looks


Rendering (WMConf MTV '19)

like a fetch failure in a normal browser inside Googlebot.


Rendering (WMConf MTV '19)

OK.


Rendering (WMConf MTV '19)

Right.


Rendering (WMConf MTV '19)

So pivoting a little bit, I'm going


Rendering (WMConf MTV '19)

to talk a little bit about the other half of the puzzle here,


Rendering (WMConf MTV '19)

is JavaScript.


Rendering (WMConf MTV '19)

So the good news is, as I mentioned earlier,


Rendering (WMConf MTV '19)

we are running Chrome, which means


Rendering (WMConf MTV '19)

that the JavaScript environment is more or less


Rendering (WMConf MTV '19)

what you'd expect.


Rendering (WMConf MTV '19)

There's not really a whole lot to say about it.


Rendering (WMConf MTV '19)

The bad news is that there is a whole lot of JavaScript out


Rendering (WMConf MTV '19)

there, and we are aiming to run a whole lot of it.


Rendering (WMConf MTV '19)

So performance matters.


Rendering (WMConf MTV '19)

We need to, sorry, we are constrained with CPU globally.


Rendering (WMConf MTV '19)

So we need to make sure that errant pages will not


Rendering (WMConf MTV '19)

damage the system by consuming too much.


Rendering (WMConf MTV '19)

If you have a page that runs lots and lots of JavaScript


Rendering (WMConf MTV '19)

for a long time, we will eventually interrupt it.


Rendering (WMConf MTV '19)

This is a different behavior than normal browsers have.


Rendering (WMConf MTV '19)

In extreme cases, we've actually seen this render page


Rendering (WMConf MTV '19)

is unindexable.


Rendering (WMConf MTV '19)

Or I should say unrenderable.


Rendering (WMConf MTV '19)

Because the CPU consumption is such that we just


Rendering (WMConf MTV '19)

can't get anything to load reasonably.


Rendering (WMConf MTV '19)

And most pages don't have any problem with this.


Rendering (WMConf MTV '19)

So any decently constructed page is not


Rendering (WMConf MTV '19)

going to run into the thresholds that we have.


Rendering (WMConf MTV '19)

But there are some cases where good pages run afoul of this.


Rendering (WMConf MTV '19)

And so I'm going to talk about some of the common failure


Rendering (WMConf MTV '19)

scenarios that we have.


Rendering (WMConf MTV '19)

So popular ways to fail.


Rendering (WMConf MTV '19)

Error loops are one.


Rendering (WMConf MTV '19)

So in this case, I'm talking about JavaScript


Rendering (WMConf MTV '19)

that fails at something, and then it wants to retry.


Rendering (WMConf MTV '19)

And it does so immediately.


Rendering (WMConf MTV '19)

And then it fails again.


Rendering (WMConf MTV '19)

So why might something fail?


Rendering (WMConf MTV '19)

Like robots.txt.


Rendering (WMConf MTV '19)

It tries to fetch something that's blocked by robots.txt.


Rendering (WMConf MTV '19)

It immediately turns around and tries to fetch it again


Rendering (WMConf MTV '19)

and spins.


Rendering (WMConf MTV '19)

That sucks.


Rendering (WMConf MTV '19)

Missing features are another way to do this.


Rendering (WMConf MTV '19)

So you can try and use a feature that


Rendering (WMConf MTV '19)

doesn't exist on Googlebot.


Rendering (WMConf MTV '19)

For example, you can't use WebRTC.


Rendering (WMConf MTV '19)

It's sort of an interesting networking feature.


Rendering (WMConf MTV '19)

We just don't support that.


Rendering (WMConf MTV '19)

So if you fail on that and spin, that's bad.


Rendering (WMConf MTV '19)

Another one is cloaking.


Rendering (WMConf MTV '19)

So cloaking refers to the process.


Rendering (WMConf MTV '19)

Or sorry, the practice of serving different content


Rendering (WMConf MTV '19)

specifically to Googlebot.


Rendering (WMConf MTV '19)

Some major websites do this.


Rendering (WMConf MTV '19)

I think this content doesn't receive


Rendering (WMConf MTV '19)

the same level of scrutiny, because we've


Rendering (WMConf MTV '19)

seen egregiously broken JavaScript coming


Rendering (WMConf MTV '19)

from major domains at times.


Rendering (WMConf MTV '19)

And again, it causes problems.


Rendering (WMConf MTV '19)

This last bullet, cryptocurrency miners.


Rendering (WMConf MTV '19)

We don't actually see this a lot,


Rendering (WMConf MTV '19)

but it kind of made us laugh, because we


Rendering (WMConf MTV '19)

had a bunch of pages that embedded these scripts.


Rendering (WMConf MTV '19)

They are tremendously heavy, and they actually


Rendering (WMConf MTV '19)

exploded the entire renderer every time


Rendering (WMConf MTV '19)

and prevented indexing.


Rendering (WMConf MTV '19)

So all right.


Rendering (WMConf MTV '19)

And that's what I got.


Rendering (WMConf MTV '19)

Thanks.


Rendering (WMConf MTV '19)


How to optimize images for your ecommerce website (6 tips)

They say a picture is worth a thousand words and there is no field where that is not more


true than e-commerce.


My name is Alan Kent and I'm a Developer Advocate at Google.


In this episode, I'll explore six tips to optimize images on your e-commerce website.


It is not uncommon for an e-commerce page to reference hundreds of images.


These images are everything from full-size product images, smaller product thumbnails,


category images, banners, page decorations, and button icons.


Given their abundance, how can you make sure that they are fast and efficient?


The first tip to optimize image usage on your site is to eliminate cumulative layout shift.


Conclusive layout shift, or CLS for short, is where the contents of a page visibly moves


around on the screen.


You know those sites.


You start reading or you try and click on a link and suddenly the page content moves.


It's really annoying.


Images can contribute to this problem if used incorrectly.


CLS is so impactful to a user's experience, Google has defined CLS as one of three core


web vitals.


These are factors that Google considers important for user experience on all web pages.


So why can images cause CLS?


To load a page, your web browser starts to download the HTML markup of the page.


Most browsers will start displaying the top of the page before the whole page has been


downloaded to reduce your wait time.


Any references to images encountered are added to a queue of resources to download.


JavaScript and CSS files are also added to the queue.


These files are then downloaded in parallel to the main page, a few at a time.


The problem is when the browser does not know the image dimensions before rendering the


page content.


Layout shift occurs if the browser discovers it did not leave the right amount of space


for an image.


CLS is often easy to spot on a page manually, watching it to load, but there are also automated


tools that can measure it.


But let's first take a slight detour and talk about lab versus field data.


Lab data is collected by testing tools that you point at your web page, such as Google's


Lighthouse.


You can perform a lab test at any time and have complete control over the process.


Field data is collected by measuring what happens to real users on your site in production.


Field data can be collected using JavaScript you embed in your own web pages or via anonymized


data collected by Chrome.


Chrome makes data for popular sites available in the Chrome User Experience Report, or CRUX


for short.


Lab data can be easier for developers to collect and analyze, but it has some limitations.


For example, CLS lab data can miss shifts that occur after a page finishes loading.


Ultimately, it is field data that demonstrates whether you have really solved a problem for


your users.


ImageSpeed Insights is a useful tool as it presents both lab and field data in the one


report.


For CLS, look for warnings such as avoid large layout shifts and images do not have explicit


width and height.


Just be aware that layout shifts in the report can be caused by things other than images,


such as JavaScript.


Fixing image CLS issues can be as simple as including image dimensions in the HTML markup.


That way, the browser immediately knows exactly how much space to reserve for the image.


There are other CSS tricks that can be used as well, if the CSS is loaded properly.


The second tip is to pick the right width and height for your images.


Larger files take longer to download, particularly on mobile phones with slower network connections.


Larger files also require more time to process, especially on mobile phones with less powerful


CPUs.


Sizing images correctly can be complicated by the range of device sizes and resolutions


that access your site.


If the browser shrinks or crops the image, the download file is larger than needed, which


is wasteful.


One easy way to detect incorrectly sized images is using the Properly Size Images section


under Opportunities in the PageSpeed Insights report.


PageSpeed Insights identifies images on a page that have larger dimensions than needed,


listing their URLs.


Once you have detected there is a problem, how to fix it?


Responsive images refers to techniques to make images behave well on different sized


devices.


For example, in HTML there is a source set attribute that allows you to list URLs for


different sizes and formats of images, so the browser can pick the best one to download.


This requires you resize the images in advance, or perform image resizing on demand.


If resizing images is too much work for your own site, consider using a Content Delivery


Network or CDN.


Many such services can resize images and convert them to more efficient formats on your behalf.


The next tip is to think about the file format of your images, such as whether to use PNG,


JPEG or WebP files.


The file format affects the file size.


Care should be taken however, as formats such as JPEG and WebP can reduce files using lossy


compression algorithms.


Lossy means image quality may be reduced as a trade-off for reducing the file size.


If pixel perfect images are required, such as for button icons, less efficient but pixel


perfect formats should be used.


While lower quality images may sound like a bad idea, remember that the degradation


in quality may not be noticeable by shoppers.


And the speed benefit can be substantial.


Shoppers may abandon your page if it takes too long to load.


To detect if your site can benefit from using a different image format, look in the Serve


Images in Next Gen Format section of the PageSpeed Insights report.


This report lists images on a page that are candidates to be converted to a more efficient


file format.


So is there a single best image format to use?


One complication is not all image formats will work on all browsers.


The caniuse.com site can be used to check which browsers support which image file formats.


For example, WebP is now supported by almost all browsers in use, so offers a good combination


of efficiency and adoption.


Alternatively, rather than picking a single format, you can have your website return the


most efficient format that the browser says it supports.


Again, this is a service offered by CDNs.


Tip number four is to use the right quality factor for your images to encode them efficiently


while retaining the desired image quality.


The Encode Images Efficiently section of the PageSpeed Insight report can be used to identify


candidate images for compression optimization.


The report also shows potential file size savings.


Be aware, however, that the report does not perform a visual check on your compressed


images.


The report is based on commonly used compression factors.


To find a quality factor you are happy with, use your favorite image conversion tool on


several images using different quality values.


A common default value for WebP is 75.


The Squoosh.app site can be useful for this purpose as it makes it easy to compare the


before and after version of images.


Remember also, there are times when you want higher resolution images, such as when you


want to allow the shopper to zoom in on a product image.


Want to go deeper?


Jake and Surma have a great session on image compression they gave at web.dev live.


Tip number five is to tell the browser how long it can safely cache images.


When you return an image from your site, you can include a HTTP response header with caching


guidance, such as how long it is recommended for a browser to cache an image for.


One approach to detect if the HTTP response cache headers has been set appropriately on


your site is, again, to use the PageSpeed Insights report.


The Serve static assets with an efficient cache policy section of the PageSpeed Insights


report identifies images that may benefit from caching improvements.


Another approach is to use the networking tab in developer tools inside Chrome to examine


the HTTP cache response headers.


To fix issues on your site, check to see if you have platform or web server settings you


can change to adjust the cached lifetime for images on your site.


If you do not change images frequently, or if you always give images a new URL, then


you can set a very long cache lifetime.


In addition to cache duration, using a CDN frequently makes downloads faster by caching


copies of your images in multiple locations around the world, closer to where users connect


from.


The final tip is a more advanced tip.


Correctly sequencing the order in which resources, including images, are downloaded can significantly


improve page performance.


Because downloading the images one by one can be slow, browsers using HTTP1 typically


download several images in parallel over independent network connections to the website.


If the website supports HTTP2, most browsers now multiplex downloads over a single network


connection.


This is generally faster and avoids problems such as large files blocking the downloads


of smaller files.


Whichever approach is used, there is still a network bandwidth bottleneck.


In general, you want images to be downloaded in the following order.


First, you want to download large hero images at the top of the page, as they can affect


the largest Contentful Paint score for the page.


Largest Contentful Paint, or LCP for short, is the time it takes to show the user main


content of the screen.


Largest Contentful Paint, like Cumulative Layout Shift, is a core WebVital metric.


Next you want other images that will be visible without scrolling to be downloaded.


Images that are visible without the user scrolling are referred to as above the fold.


The rest are referred to as below the fold.


As a web page may be viewed on devices with different screen sizes, it is common to estimate


which images are above and below the fold by checking your site on multiple devices.


Finally, you want images to be downloaded that are just off the screen, so that they


can be ready for display when a user starts scrolling.


Other images that are not likely to be displayed soon are often best to load lazily.


If the user does not scroll the page, fetching them would be a waste of resources.


To detect if your site is loading images efficiently, again, the PageSpeed Insights report can


help.


For example, the Defer Off-Screen Images section of the report identifies images that can be


loaded after other images.


There are other sections that can be useful, such as Avoid Chaining Critical Resources,


although these chains typically involve JavaScript and CSS files.


A common technique to improve the order of image loading is lazy loading.


This is where images are not downloaded until the user scrolls to that portion of the page.


Lazy loading was originally implemented using JavaScript, but now most browsers support


the loading equals lazy attribute of HTML.


Care should be taken, as performance degradation can occur if lazy loading is used for images


above the fold.


Recent versions of Lighthouse will highlight if an image is lazily loaded that will impact


LCP.


With the advent of HTTP2, there are additional optimizations that are possible if the browser


and website both support HTTP2.


A HTTP2 website can start pushing images to the browser that its knows are going to be


needed without waiting for the browser to request them.


The HTTP2 also allows browsers to more efficiently download multiple images in parallel over


a single network connection.


To take advantage of HTTP2, either your web server must be configured so it knows which


resources to push, or use a CDN with HTTP2 support and configure it to push resources


as required.


To wrap up, I've shown common problems that can occur on ecommerce sites with static images.


Some of easy fixes, such as ensuring that image tags in HTML always specify the image


width and height attributes, or using the loading equals lazy image attribute.


There are more advanced techniques that you can implement directly on your website, but


it may be easiest to use a third party CDN with suitable support.


Such services can serve images in the best format supported by the browser, convert images


from a single source image to more efficient formats as needed, pre-scale images to multiple


sizes for efficient download and display across a range of devices, and compress images to


reduce download sizes.


Thanks for watching.


If you enjoyed this video, make sure to click subscribe.


Video Key Moments on Google Search | Search Central Lightning Talks

Do you want users to engage more deeply with your videos?


Key moments in Google Search can help you do just that.


I'm Danielle, a product manager for videos in Google Search,


and in this lightning talk, I'll walk you through some ways to enable key moments for your videos.


We'll answer questions like, what are key moments?


How does Google identify key moments in a video?


And, how can I get this feature on my videos?


By the end of this talk, you should be all set to enable key moments for your videos on Google.


Before we start talking about key moments, I want to make sure you have the foundation


to understand how videos work in Google Search.


So if you haven't seen my previous talk on video best practices, you might want to start there.


Check out the link in the description below.


With that taken care of, we can dive into the topic of key moments.


So, what are video key moments?


Key moments are a way for users to jump directly to the point within a video that's most relevant to their query.


In Google Search, key moments can appear alongside a video result, like this.


For each key moment in the video, you'll see a timestamp indicating where that moment starts,


a label describing what happens at that moment, and sometimes a thumbnail from that moment in the video.


When you click a key moment and land on the video page, that video will begin playing from the specific moment you selected.


You can find this feature on both mobile and desktop search.


Key moments can appear for results where a video is the main content on the page,


but they won't appear today for pages that mix videos with other content, like a news article or e-commerce product detail page.


With key moments enabled, users can see if there's a part of your video that has what they're looking for,


so they might be more likely to engage with it.


Now that you've seen key moments in action, let's talk about how to enable them for your videos.


With the right setup, Google can automatically identify and display the key moments in your video,


or you can choose to manually label the key moments yourself.


If you don't want key moments at all, you also have the option to opt out using the no snippet tag.


First, let's talk about how Google automatically identifies key moments, and how you can enable this for your videos.


Google uses several different signals to look for key moments in videos.


With speech recognition, Google analyzes the words that are spoken in a video to infer key topics being discussed.


With optical character recognition, Google looks for text that's displayed within the video, kind of like this,


which might indicate important sections of a video.


In limited cases, Google may also use visual signals to understand what's happening in a video,


like the moment a goal is scored in a soccer game.


We expect to add more use cases for visual signals in the future.


These technologies let Google do the work for you and save you time,


so you don't have to manually choose the key moments in each of your videos.


All you have to do is some one-time setup work.


Make sure Google can fetch your video content files, and add schema.org markup to your pages.


From there, you can sit back and relax.


First, in order to analyze your videos, Google needs to be able to fetch your video content files.


Use the content URL property within video object schema.org markup to identify the video file URL.


Make sure Googlebot can access that file, and that it's in a supported format listed in our developer docs.


One common pitfall is that sites sometimes use expiring URLs that change frequently as a method of access control.


Unfortunately, this also prevents Googlebot from fetching your video file,


so Google can't analyze the video to identify key moments.


If you're concerned about bad actors accessing your video files,


you can display a stable version of your content URL only to trusted crawlers like Googlebot.


Follow the guide in our developer docs to verify if a requester is Google,


and if so, display the stable content URL on the page.


Google won't expose these content URLs publicly. They're just used for internal processing.


The links that Google displays in search results are the URLs for your web pages where the videos are embedded.


In order to support key moments, these video page URLs must support a parameter that begins playback from a specific number of seconds into the video.


For example, in this URL, the t equals 30 parameter indicates that the video should start playing from the 30 second mark.


Now, you just need to add schema.org markup to tell Google where to insert the number of seconds in your URL.


Within your video object markup, include a potential action property.


This property should be of type seekToAction, and have a target property that contains the URL for your video page,


with a placeholder for where Google can insert the number of seconds to skip to in the video.


That placeholder is the seekToSecondNumber string that you see in this example.


This tells Google that in order to link to a particular moment in your video, for example, 30 seconds in,


Google can replace that placeholder string with a number, in this case 30, and display that link in search results.


When users click, the video will start playing from the 30 second mark.


Check out the description below for a link to our developer docs with more detail.


The seekToAction markup and video content file guidelines are only necessary for videos embedded on your own web domain.


For videos that you upload to a third-party platform like YouTube, it's up to that platform to implement these best practices across all their videos,


since individual creators can't control the site markup.


We just covered how Google can automatically identify key moments for your videos.


But sometimes, Google might not find key moments, or you might prefer to replace Google's selections with moments you chose yourself.


So, let's talk now about how you can choose your own key moments manually.


For videos embedded on your own domain, you can do this using clip markup.


Within your VideoObject schema.org markup, you can use the hasPart property to specify each moment as a clip.


Give each clip a name to label what happens at that moment, and include the start and end time for the clip.


Just like with seekToAction markup, your page URLs need to support parameters that will start the video playing from a particular timestamp within the video.


Use the URL property to specify that URL.


This should be the URL of the page where your VideoObject markup appears, with an added parameter to start the video from the right moment.


For videos that you upload to a third-party platform instead of your own domain, it's up to that platform to give you a method to identify the moments in your video.


The platform can then add clip markup to identify the moments you chose.


For example, on YouTube, you can mark key moments in the description.


These moments will be eligible to appear on Google Search and as YouTube chapters.


To recap, there are two ways you can enable key moments for videos on your domain.


If you want Google to automatically identify key moments in your videos, use seekToAction markup, and make sure that Google can fetch your video content files.


If you want to choose key moments for each video yourself, use clip markup.


Google will prioritize showing the key moments that you define.


And remember, for both clip and seekToAction markup, your web page URLs need to support parameters that start playing a video at a particular timestamp.


Don't forget to check out our Developer Docs, linked in the description below, for full details on the topics we covered today.


English Google SEO office-hours from October 22, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


I am a search advocate on the Search Relations


team here at Google.


And part of what we do are these Office Hours sessions


where people can jump in and ask their questions around SEO


and their website.


And we can try to find some answers.


As always, a bunch of questions were submitted on YouTube


already.


So we have some of those to go through.


But we also have lots of new live people here.


So maybe we'll go through some of the live questions first.


And sure, then let's get started.


Let's see.


Christian, I think you're first.


Hi, John.


How are you?


So nice to see you again.


Yeah, I've got a question regarding Core Web Vitals.


And I would like to know if the weight of the Core Web Vitals


or the page experience can depend on the kind


of the website you are looking at.


So let's say you have a website which


is more sensitive to loading time, like online gaming


or something in that direction, versus some plaintext website.


Are there any differences in the weighting of the page experience


or Core Web Vitals as a ranking factor?


No, not really.


So it's not that we would evaluate the kind of website


and say, oh, speed is more important here.


It's really like if we can take it into account,


we'll take it into account.


I think the tricky part is in some search results,


the competition is quite strong.


And everyone is very similarly strong.


And then it can look like it has a stronger weight.


But it's not the case that we look at it by type of website


and say, oh, it's more important here or not.


All right, good to know.


Thank you.


Sure.


All right, Andrew.


Yes, hello, John.


Hi.


Yes, so we are trying to improve page experience


on one of our websites.


Currently, we are working on a CLS metric.


So the background of the problem is that the images


on our website use lazy load.


But before loading, we don't know their sizes.


So we put an empty SVG in the src attribute


with the viewport meta tag.


And the original image is in the data src.


And once the image is there on the screen,


we replace src attribute with the original image.


Is it the same?


Well, it is the same setup that is recommended


in their article on web.dev.


But we use their data src instead of their data source


set, is an example.


And we also switch an image in the src.


Is this setup OK for Google in terms of indexing images


on such pages?


Yes.


I mean, this switching thing.


That sounds OK.


I think for the core web vital side, the CLS side,


that's something you can test where you try it


in one way or the other way.


With regards to indexing, what is important


is that we have information about the images


on those pages.


So what you can do if you're not sure,


if you're lazy loading is recognized by Google,


is use the image structure data.


So kind of on the pages themselves,


give us the structure data for those images.


And then we can definitely pick that up.


OK, in such setup, does Google or the algorithm


understand that there is a meaningful, possibly even


useful image, not just a gray square?


I don't think we care.


Ah, OK.


To be quite honest.


So I don't think for web search, we


look at the specific images on the page and say,


oh, this is a nice image and this is a boring image.


We basically use those images in image search.


And that's where we care what the content of the images are.


But within web search, we don't really


care if it's a gray square or if it's a picture of a beach.


OK.


And also I wanted to ask, is it OK in general not


to use the SRC at all and instead use only the data SRC


attribute?


Do you recognize and, well, not recognize,


but use this attribute for indexing pages or images?


I don't think we use it by default.


But if it loads with lazy loading


as an image element on the page, then we can pick that up.


And if you use the structured data or an image sitemap,


we can also pick that up.


So it's not by default that you would use the data SRC,


but we use what ends up being rendered on the page.


Oh, OK.


Thank you.


Sure.


GK, I think.


Hi, John.


I have a question about reputation research.


Does Google collect Android and iOS application reviews


in the process of extensive reputation research?


This type of review still affect our company website quality


scores?


I don't think so.


At least for web search, I don't think


we would take that into account.


And we don't have a notion of a quality score


when it comes to web search anyway.


So I could imagine that indirectly,


if these reviews are published on the web somewhere,


we might pick them up and we might index them.


But if they're in an app store somewhere,


I don't think we even see them for web search.


For other kinds of searches, I don't know.


OK.


Thank you.


John, may I add something to this question?


Sure.


If you don't mind, of course.


Yeah.


I also don't think that Google is


able to see these stores because they


are kind of closed ecosystems, especially the app store.


So if you don't have an account, you cannot access them.


In other words, so it's almost the same like with the websites.


If you have something that is locked with the user


and passwords, it's not possible to be publicly accessed


by a software like the Crawl in this situation.


That might be.


I don't actually know the details


of how the web kind of the Play Store or the app store content


is shown or accessible in search.


But yeah, that might also be the case.


Cool.


Let's see, Hazel.


Hi, John.


Nice to have you here.


So my first question is, recently,


the crawl request on my company site


has dropped nearly over 90%.


And we have checked all aspects according


to the official doc, like robots, techs, or salience.


And we want to know any other possible technical factors that


can cause a sudden drop of crawl requests in a day.


What main aspects do you recommend us to also check?


So it sounds to me like our systems


have trouble accessing your content quickly enough.


So when it comes to the number of requests


that we make on a website, we have two kind of things


that we balance.


On the one hand, the crawl demand,


which is how much we want to crawl from a website.


And assuming this is a reasonable website,


then the crawl demand usually stays pretty stable.


It can go up if we see a lot of new content.


It can go down if we see very little content.


But usually, these changes are very kind of slow over time.


And the other side is the crawl capacity.


This is how much we think the server can support from


crawling without causing any problems.


And this is something that we evaluate on a daily basis.


And it can react quite quickly if we


think that there is a critical problem on the website.


So for critical problems, we think


of things like server errors, if we see a lot of server errors,


if we can't access the website properly,


if the server speed goes down significantly.


So not the time to render a page,


but the time to access the HTML files directly.


And those are kind of the three aspects that play into that.


And if, for example, the speed goes down significantly,


you would see that in the Crawl Stats report in Search Console.


And that's something where if we think


we cause problems from crawling too much,


we will scale that back fairly quickly.


AUDIENCE MEMBER 1 I see.


So the response time is highly relevant.


It's highly related with the crawl request, right?


Yeah, correct.


Do you think the response codes of huge 5xx and 4xx


also may reduce the crawl rate?


5xx errors, definitely.


Those are server errors, which we would see


as being potentially problematic.


400 errors are less problematic because it's basically


content doesn't exist.


So we can crawl normally.


So if a page disappears, that's no problem.


If it has a server error, that is a problem.


So how many levels of 5xx code would you see as a main cause


of server error?


Like if we have 100 pages and maybe


among 15 pages returns to 5xx due to some technical errors,


will Google both think our server may overload?


Like how many percent would make?


I don't think we have a fixed number.


So what I would check if this recently dropped the speed,


I would go into Search Console in the Crawl Stats section


and see if one of those numbers there changed significantly.


Like it will have the graph.


And then you can see on this date, we saw the change.


And did the 5xx errors go up or go down?


Or is the speed kind of changing there?


Anything like that.


AUDIENCE MEMBER 1 I see.


So assuming that we find the critical problem,


and maybe it's because of response time or maybe


the server error, if we fix this problem maybe


in one or two weeks, when will we see the crawl rate back


to the normal request?


We update the crawl rate on a daily basis.


So probably within a couple of days,


you will see step by step increasing again.


So maybe if we fix it in the right direction,


we can see it increase.


OK.


I see.


Thanks.


Sure.


Let's see.


Alessio.


Hey, hi, John.


How are you?


Hi.


Very good.


I don't know if you remember.


I joined the office session a few weeks ago.


And I asked you about some software before.


I sent you a couple of examples.


And you said you would send them over to the team


to check what the problem exactly was.


Because as I described back then in the URL inspection tool,


it will show us that everything was pretty much there.


And then you said maybe there is an issue on our side.


I don't know if you recall that.


Just want to follow up.


It's possible.


I don't have offhand the escalations that we did there.


So yeah, I don't know.


I think if you posted the URLs, then I definitely


pass them on to your team.


But I don't know what changes they would make based on that.


Is there a way to understand if the issue is


on our side or on your side?


Because obviously, if it's on your side,


we don't have to worry about that.


But if there is something we are doing wrong,


we would like to fix it.


At the moment, for us, it's a bit


difficult to understand what we are doing wrong.


Usually with soft 404s, it's based on the content


that we find on the website.


So if we see things like an error page on a website


or if we see, I don't know, no index pages or something that


mentions errors in the text on the page,


then that's something we could potentially


classify as a soft 404.


So I don't remember the actual URLs that you had.


So it's really hard for you to say.


But I imagine these are normal pages on your side.


Then that would probably be something


that just our systems have to pick up over time.


And with the escalations that I do for the soft 404 team,


usually they take that into account


for future algorithm of that.


So it's not that they would manually tweak it and say,


oh, this one is not.


But rather, they fix the code and improve it


so that it doesn't catch those kind of pages.


AUDIENCE 1


OK.


Perfect.


Got it.


Thanks a lot.


Appreciate it.


Philip.


Hey, John.


All right.


I've got a question on query strings and facet navigation,


how to deal with this.


So we've got our site.


We load our faceted nav on our category pages.


With JavaScript, there's no href links on them.


So Google is not going to find those.


And we don't want those indexed either.


So the way we kind of have it set up,


the only way these kind of seem to be accessible to Google


is if someone externally links to them.


And so to prevent that indexation,


we've got Canonical set up.


We decided not to do it through robots.txt.


But I was thinking about this, and I


know that Canonical is more of a suggestion.


So I get a little paranoid sometimes.


I'm like, I don't want all these things to get indexed


and stuff like that.


So then I started kind of thinking about the Search


Console parameter tool.


So I started kind of poking around there.


And that seems, if I block those parameters,


is that really essentially the same thing


as blocking with robots.txt and then Canonicals


wouldn't get seen?


I guess that's question number one.


So we use that tool as a way of recognizing pages


that we shouldn't index.


And for picking better Canonical choices.


So basically, what would happen there


is if we've never seen that page before, then


nothing will get indexed anyway.


If we've seen that page before and we've


noticed it has a rel canonical on it


and we're unsure what we should do with this rel canonical


because it's not a 100% clear signal,


then having it listed in that tool


basically skews that discussion and basically says,


oh, we don't want this index.


Then we just won't index that.


And we've seen a rel canonical here.


So we'll just follow that rel canonical.


OK.


So it will crawl it.


So it wouldn't act similar to the robots.


Yeah.


Usually what happens is the crawling still happens,


but it doesn't happen at the same speed


just because we recognize ahead of time


that actually this is probably not something that we need.


That makes sense.


Because then that takes care of the next question


because then I was thinking about because they had the,


you know, there's the options if it's just tracking based


or if it actually changes the page.


And the tracking one allows you to follow only


the representative URL, which in my head


was like, oh, yeah, that sounds great.


But I guess if the other one does the same thing,


then we're coached.


I think using the blocking setting makes a lot of sense.


All right, great.


Thanks, John.


All right.


Let me run through some of the submitted questions.


And I'll get back to the rest of you with your raised hands


as well.


Don't worry.


And I probably have some time afterwards as well


for more questions if needed.


Let's see.


The first question I have on the list here is in Search Console,


we can see for keywords after we have filtered the country


that every month on the 27th, there's


an impression increased by 300%.


There are no clicks at these time periods


when the posting is always close to one.


I wanted to ask whether bots can trigger such impressions


and what should we do about it?


It can definitely be the case that bots or scrapers


or things like that are triggering these impressions.


We filter and block bots at different levels in the search


results.


And it can certainly happen that some of these


go through into Search Console as well.


So it's almost like a weird situation


that if you're running these scrapers to see


what your position or ranking would be on these pages,


then you're kind of getting some metrics,


but you're skewing the other metrics.


So it's something where, on the one hand,


from our terms of service, you shouldn't


be scraping our search results.


And of course, others shouldn't be either.


So I kind of discourage that if you're


checking these things yourself.


If this is not something that you're running


and you just see this appearing in Search Console,


it's fine to flag this with the feedback function, which


it sounds like you already did.


And it's fine also to completely ignore it,


because it's something where, like I said,


we filter at different positions in our search systems.


And all of the ones that I've escalated,


which were like this, ended up being filtered just a little


bit after Search Console.


So it's not that it causes any problems.


It does make it harder to track impressions.


And you can't filter them out in Search Console.


So it's kind of annoying.


But it's not something that you can manually tweak yourself.


Let's see.


My question is related to internal links,


specifically on the home page.


Assuming the home page got a certain value,


will having lots of internal links going from the home page


to other pages affect the value of the home page,


therefore affecting its performance and ability


to rank for a specific query?


Interesting question.


So basically, what you're doing with the internal linking


is spreading the value that you're


getting from your pages relative to the rest of your website.


So if, for example, all of the external links


go to your home page, and that's where all of the signals


get collected, and your home page has absolutely no links,


then we can focus purely on the home page.


As soon as it has other links as well,


then we kind of distribute that out across all of these links.


And depending on the way that you have your internal linking


set up, that can mean that there are certain places


within your website that are, relatively speaking,


more important based on your internal linking structure.


And that's kind of how we pick things up.


So it's not a one-to-one mapping of your internal linking


to your ranking, but it does give us


a sense of relative importance within your website.


And from that point of view, it definitely


makes sense to link to important and new things


from your home page where you're saying,


this is really important, or this is really new.


People should take notice of this.


Then we can pick that up a little bit faster,


and we can give it a little bit more weight in the search


results as well.


It doesn't automatically mean it will rank better,


but it does mean that we kind of recognize, oh, you're saying


this is relatively important.


So we will kind of take that on as feedback


and try to treat it appropriately.


Let's see.


Several questions we would like to know more about.


What's the possible technical factors


that can cause a sudden drop of crawl requests in a day?


I think we touched upon this fairly briefly before.


The response time, like I mentioned,


and the frequency for Google to recalculate the crawl budget,


that's essentially once a day we try to look at that.


Also, in Search Console, if you're


seeing that we're crawling too much, which doesn't sound


like this problem, but if you're seeing


that you adjust the maximum crawl rate in Search Console,


that's also taken into account about once a day.


So that once a day factor is kind of at play there.


I know it has been mentioned before


that making technical improvements


is less important to SEO than having quality content.


I just want to pause there and say,


I don't think this is absolutely true.


It's something where both the technical side of SEO


and the content side of SEO, they're very important.


And they play a big role in how search engines understand


your content.


And I would not say that technical SEO is less important


than the quality side.


I think they both have to be good.


And the other thing I just want to mention while I'm here


is that when it comes to the quality of the content,


we don't mean just the text of your articles.


It's really the quality of your overall website.


And that includes everything from the layout to the design,


like how you have things presented on your pages,


how you integrate images, how you work with speed,


all of those factors, they kind of come into play there.


So it's not the case that we would


look at just purely the text of the article


and ignore everything else around it and say,


oh, this is high quality text.


We really want to look at the website overall.


So I think that's even for all of your questions.


So I hope it doesn't ruin the rest.


Let's see.


With that in mind, is there a point


where technical improvements are still extremely valuable?


Yes.


Like I mentioned, it's definitely still important.


Maybe just an aside here, I suspect some of this


came from a discussion we had in one of the previous Hangouts


where someone had an issue with regards to a core ranking


change that Google made, and they saw their website


drop in rankings.


And that was a case where I'd say probably


those technical issues are not the reason for a drop


of a website when it comes to core ranking changes,


because those core ranking changes are really


about relevance more.


And they're less about the technical factors.


But in general, technical SEO is just as important as content,


and they both have to work together.


Let's see.


Question goes on.


When LCP is over 20 seconds and blocking time over 10 seconds,


are there some more general guidelines?


So that, I think, is specific to the page experience ranking


change that we made.


And those numbers sound pretty bad,


and it sounded like a pretty slow page.


So that's definitely something I would work on to improve.


I think if you want to pick apart


the individual factors of how a page is ranking,


then you can't just blindly isolate one element there,


which in this case would be speed or the page experience


ranking factor, and say, I will fix this one issue.


And then the ranking will improve,


because maybe the ranking is stuck because of this one


issue.


Maybe the ranking is stuck because of 500 other issues


that you have on a website.


So that's something where you can't just


blindly isolate that.


I've been treating improvements that cut off about half


a second or more LCP as valuable,


and we've seen jumps in organic traffic corresponding


to the weeks we've made these improvements.


But we're not certain that these increases


are tied to the changes, and we're


nearing a point where it seems that we may be better


served working on something else.


Yeah.


But like I mentioned, it's hard to say


if it's really specific to this one change.


One thing maybe worth mentioning specifically about speed


is that for the Core Web Vitals, we take into account the data


that is, I think, delayed by 28 days or something like that,


so about a month back, which means


if you make significant speed changes on your website that


affect the Core Web Vitals and accordingly the page


experience ranking factor, then I


would expect it to take about a month


to be visible in the search results.


So if you're seeing changes in search that


happen on the next day, then probably that


wouldn't be related to the speed changes that you made.


And similarly, if you make bigger speed changes,


then you need to take into account


that it's going to take about a month before you even


see any effects from that.


Yeah.


I think it's also one of the hardest parts of SEO


is finding out which parts of this big catalog of SEO things


that you could be doing are currently


the most critical for a website.


And that's something where experience comes into play


and understanding the competitive environment there,


the queries that you're trying to rank for comes into play.


And there's essentially no tool that will just go out and say,


it's like, here are 500 things that are wrong,


and this is the one thing that you should be doing.


That's kind of, I think, the exciting part of SEO


is you kind of gain some experience over the years


to figure that out.


I'll be adding structured data on a page that has a product.


It's reviews and FAQs related to the product.


It doesn't matter if the FAQs are not nested,


but the script is still included in the page header.


I think that's fine.


I would use the appropriate structured data testing tools


just to make sure that you can pull out that data.


But from what I understand from the structured data guidelines


for those elements, these don't necessarily have to be nested.


So that's probably OK.


But you can test with the testing tools.


The testing tools essentially do what we would use for indexing,


and they'll tell you right away if it's good or not.


Does a website which includes great content


improve in trust with Google, or is that only


determined through links?


I don't think we have a trust factor


that we can kind of look at and say, oh, trust is at,


I don't know, 9 out of 12, or whatever numbers


you would have there.


So that's kind of, I don't know, it's


almost like a philosophical question at that point.


It's like, does improving the quality of your content


overall make a website more trustworthy with regards


to Google?


And it's like, well, I don't know.


There's no metrics specifically for that.


I think improving the quality of your content


is always a good idea.


But it's, yeah, I don't know.


Lots of things are involved there.


And when it comes to trust, it's definitely


not a matter of just the links that are pointing at a website.


Would delaying loading of non-critical JavaScript


until the first user interaction affect SEO ranking in any way?


This will not affect UX and UI.


Is there anything we should be concerned about,


such as affecting the Chrome User Experience report data?


So I think from what I understand from the question,


it's basically you're lazy loading the functionality that


takes place when a user starts to interact with a page


and not lazy loading the actual content.


If that's the case, then that sounds perfectly fine to me.


That's something similar to, I believe


they call it hydration when it comes


to JavaScript-based sites, where you essentially


load the content from HTML as a static HTML page,


and then you add the JavaScript functionality on top of that.


From our point of view, if the content is visible for indexing,


then we can take that into account,


and we can just use that.


It's not the case that Googlebot will go off and click


on different things.


We essentially just need the content to be there.


The one thing where kind of clicking on different things


might come into play is with regards to links on a page.


If those links are not loaded as A elements,


then we won't be able to recognize those as being links.


And similarly, as one of the questions I think early on


was with regards to lazy loading of images on a page,


if those images are not loaded as image elements,


then we don't recognize them as image elements for image


search.


And then it's good to have kind of a backup


in the form of structured data or an image site map


on your file so that we can understand


that even if those images are currently not


loaded on the page, they should be associated with that page.


I think you have your hand raised as well.


So I just wanted to check.


Does that work for you?


It does, yes, thank you for answering that.


What we're trying to address here


is the page speed, which we're using the CDN, which


does this part of the lazy loading, let's say JS and CSS.


So yes, we're trying to increase the speed.


This did increase the web vitals as well by a lot,


more than 50%.


So I don't know if such a big change will affect us


in any way in a bad way.


Is this considered, I mean, lazy loading CSS a bad practice,


or is there anything on that?


I think that's perfectly fine to do like that.


With regards to CSS in particular, so I don't know,


JavaScript probably less so.


But CSS in particular, since it affects


the layout of the page, that could affect the CLS score.


And it could affect the understanding of whether or not


a page is mobile friendly.


So that might be something to watch out for.


But otherwise, if you're using lazy loading


and you're making your pages much faster for users,


then it's like, good job.


Yeah, that sounds good.


Great.


Thank you very much.


Sure.


Let's see.


My client is having a rather unique issue


that is relevant to the times.


Ordinarily, I would recommend that if a product is out


of season or out of stock that they keep the URL alive,


then put a note to the user as to when the product will


be available.


With supply chain shortages, this company


is experiencing an inordinate amount


of temporarily out of stock products,


and this creates a negative user experience.


How do we balance the user experience with SEO?


They want to take all the URLs offline


so that customers stop complaining


about the number of out of stock items on the e-commerce site.


However, this means their URLs and SEO is impacted.


Yeah, I don't know.


I think this is always a bit challenging,


specifically around out of stock and temporarily out


of stock content.


It is something where what works best for us


is if we can keep the URL online for things that are really


temporary, in the sense that if the URL remains indexable


and with structured data you tell us


this product is currently not available,


then we can at least keep this URL in our index


and keep refreshing it regularly to pick up


that change in availability as quickly as possible.


However, if you decide to no index these pages


or if you decide to just remove the internal linking


to these pages, then when that state changes back,


we would try to pick that up fairly quickly as well.


And we try to understand these state changes through things


like sitemaps and internal links.


So especially if you add a product back


and then suddenly it has internal links again,


that helps us to pick that up again.


You can speed this up a little bit


by being a bit deliberate with your internal linking.


So in particular, like I think one of the questions


earlier, where when things are linked from the home page,


we think that they're a little bit more important,


and we go off and try them out fairly quickly.


If you add those products back and if you add a link


to your home page saying, oh, these things are now


in stock again, then we can take that and say,


oh, this seems to be an important thing.


We will double check these pages a bit quicker,


and we'll see if they're actually now in stock or not.


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


I think also with regards to in stock and not in stock,


especially when it comes to products, one thing you can


also do is kind of hedge your SEO together


with product search.


So if you submit a merchant center feed,


then we can also show those products within the,


I don't know what it's called, the product search sidebar


thing or product listing ads.


I think it used to be called, I don't


know what the current name is.


We can also show those products there,


and we can show them there based on the feed.


So we don't necessarily need to recrawl the individual pages


to recognize, oh, the page says it's in stock.


We can just recognize in the feed that you submit to us,


like suddenly the availability changed,


we can put that back in.


So those are kind of the aspects there.


On the one hand, if you want to remove it


with a no index or just removing internal links, that's fine.


That's up to you.


If you change it back, make sure to make it


so that we recognize those changes as quickly as possible.


And ideally, also use the merchants center feed


to kind of hedge your bets with regards to SEO


so that it doesn't depend purely on recrawling


all of these pages.


After doing a Lighthouse report on our site,


we noticed a common JavaScript library


we use was flagged as having two security vulnerabilities.


Do these vulnerabilities have any effect on SEO,


or would you say this is more just to let us know?


So Lighthouse is, I think, a tool within Chrome and also


a standalone tool, I think.


I'm not sure if it's just in Chrome.


But it's basically from the Chrome side.


It's not, by definition, an SEO tool.


But it does have a lot of things that you can use for SEO.


And specifically, security vulnerabilities


are not something that we would flag as an SEO issue.


But if these are real vulnerabilities on scripts


that you're using, and that means that your website ends up


getting hacked, then the hacked state of your website,


that would be a problem for SEO.


But just the possibility that it might be hacked,


that's not an issue with regards to SEO.


So from that point of view, I would take this as something


to double check, together with maybe developers,


or double check if you can update those libraries.


But I wouldn't see it as something that will change


your rankings immediately.


I run a theater news, reviews, and ticket website.


Some of the content that's posted


is generic from the show's producers.


Is it OK to post this on the website with admin


as the author?


Or is it always best to have a person as the author?


So I think this kind of comes from everything


around the quality rater guides and information


that we've published around EAT, which is Expertise


Authoritiveness Trustworthiness.


And this basically applies to sites that are really critical.


And essentially, sites where you're


giving medical information, or where you're


giving financial information.


Then for those kind of really critical situations,


you want to make sure, as a user,


that this is actually written by someone who's trustworthy,


or who's an authority on this topic.


But when it comes to theater news, for example,


or SEO news, or anything kind of random on the web,


that's not necessarily something where


the trustworthiness of the author is a big issue.


So that's something where I would say it's the less


critical how you frame this.


I think having admin as an author seems kind of,


I don't know, too generic with regards to any business,


where maybe you're better off just saying,


well, there is no author for this specific piece


of information, or it's just written by our website.


But essentially, that's more up to you.


The one place where author, I think the author name does


come into play, is some types of structured data


also have kind of information for the author.


And in that case, it might be something


that are shown in the rich results on a page.


So from that point of view, you might


want to make sure that at least there's a reasonable name there


or you explicitly don't use that kind of structured data.


But otherwise, for I think a generic news, and reviews,


and tickets website, I wouldn't necessarily


worry about the name of the author that you specify there.


Recently, we added post section to the home page,


as most sites have.


And that section has been constantly changing.


And we don't really want to rank these pages


for any specific query, meaning we don't


want to favor them in any way.


Instead, we want to rank categories and tags.


So my question is, will adding a nofollow attribute


to these pages in that section cut the internal link juice


flow to them or give more value to the other links


on the home page?


So for the most part, I don't think


it makes sense to try to fine tune the internal linking


with the rel nofollow attribute on links.


I don't think that's something that's very easily,


I don't know, even recognizable as having an effect there.


So I wouldn't focus on just putting nofollow on these links


and putting them there.


Either you want to have those pages indexed, in which case


you have normal internal links to them,


or you don't want them indexed, in which case


you don't have internal links to them,


or in which case you could just put a noindex on those pages.


But I wouldn't try to tweak things


with internal linking of this kind of content


with the rel nofollow.


So that's something where I would


try to figure out on your side, this is totally up to you,


and this is more of a strategic question than an SEO question.


Do you want these pages indexed, or do you


don't not want them indexed?


If you do want them indexed, then link to them normally


and make them indexable.


If you don't want them indexed, then don't link to them,


or put a noindex on those pages.


And decide based on that.


Can we add a view of a week and a month


in the search report in Search Console?


I don't know.


I would submit feedback for that so that the Search Console


team knows what you would like to do there.


How does, I mean, one thing you could do


is just export the data and do it in a spreadsheet.


So that might be an option for you.


How does Google's search engine differentiate


between e-commerce website and informational website?


Is it from the plugins installed, or from the CMS,


or from the website structure?


We want to use WooCommerce plugin for a specific purpose


other than e-commerce.


We don't want to sell any products.


Will the WooCommerce installation


classify our website as an e-commerce website?


So we don't classify websites based on the infrastructure


that they use.


And I sometimes get this question with regards to blogs.


It's like, I want to publish an article,


and I do it in WordPress.


Does this mean that Google thinks


that my article is a blog post?


We don't have this notion of trying to understand


what type of content something is just based


on the infrastructure that it uses.


You can use, essentially, an e-commerce site


set up for posting your blog posts if you want to.


It's probably not very suitable for things like that,


but you could if you wanted to.


And if we see that, we will say, well, this page


has a lot of content on this specific topic.


We will rank this page based on this content.


So from that point of view, if you


want to use a specific infrastructure which


you think works well for your website, then go for it.


It's not going to be the case that we will say,


oh, your website uses this infrastructure,


so it must be this kind of a website.


That's not the case.


We essentially look at the pages that we see there,


and based on the content that we find on those pages,


based on that, do we try to classify these individual pages?


And even then, it's not the case that we would say,


oh, this is an e-commerce page, or this is an article page.


But rather, we would try to figure out what intent does


this page cover, and how does that map to the search results?


If someone is looking to buy something specific,


and we see it's a product page, then we might say, well,


this covers this user wants to buy something


intent fairly well, therefore we'll rank it.


So it's, I don't know, lots of those things


kind of flow into that.


OK, let me see.


We have lots of raised hands, and a bunch of questions left.


Maybe I'll just go back to the raised hands.


Adriana, I think you're next.


Hi, John.


My question is kind of an elementary one,


but it's wildly debated at my agency,


and it's about impressions.


So can you tell us what classifies an impression


in Google Search Console, and then


how that might be changing with the infinite scroll?


OK.


There's a lot about that.


So we have a Help Center page on what is impressions, clicks,


and positions, I think it's roughly called,


that has a ton of details on those impressions.


So that's something that I would look at first.


It's something I usually look at when I get this question.


So that would be my recommendation, first of all.


With regards to infinite scroll or kind


of this continuous scroll setup that we're trying out,


I think it's a little bit tricky,


because it's hard to determine what exactly is happening


from an SEO point of view.


But essentially, from our side, we're


still loading the search results in groups of 10, essentially.


And as a user scrolls down on the page,


we kind of dynamically load the next set of 10 results there.


And when that set of 10 results is loaded,


that counts as an impression.


So that basically means that kind of the scrolling down


and you start seeing page 2 of the search results, that we


would see is like, well, this is page 2 now,


and it now has impressions, similar to if someone


were to just click on page 2 directly in the links.


So from that point of view, not much really changes there.


What I think will change a little bit


is that users will probably scroll a little bit easier


to page 2, page 3, or 4.


And based on that, the number of impressions


that a website can get in the search results


will probably go up a little bit.


I don't think it'll be an extreme change,


but probably it'll be more the case


that if you were ranking on page 2,


then suddenly your website gets a lot more impressions,


just because it's easier to reach page 2 in the search


results.


And the number of clicks, I suspect,


will remain similar, because people will scroll up and down


and look at the results on a page,


and they'll click on one of them.


So probably what will happen is impressions


go up a little bit, clicks stay the same.


That means the click-through rate tends


to go down a little bit.


And if you're focusing purely on click-through rate for SEO,


then I suspect that will be a little bit of a kind of,


I don't know, weird situation, because it's


hard to determine did the click-through rate drop


because this page was shown in this continuous scroll


environment, or did it drop because users saw it,


but they didn't like to click on it as much anymore?


So that's, I think, kind of tricky there.


One thing that, I don't know, helps a little bit, I think,


is we do this continuous scrolling just


for the first four pages.


And then afterwards, you click on kind


of the Load More or Next Page.


I don't know what exactly it's called.


So it's not something that you would


see if you're ranking on page five or six,


at least not at the moment.


Nobody knows how these things evolve.


And at the moment, it's only for English results in the US.


I suspect if they see that this works well for users,


they'll roll it out in more countries and more regions.


But as always, who knows?


And it's hard to determine what the timeline there will be.


So I think the short version is probably, over time,


the number of impressions for a lot of these pages


will go up a little bit.


And at some point, that will stabilize again


when people are used to this new UI,


when it's rolled out everywhere.


But my guess is the click-through rate number,


if you're just purely looking at that,


that will go down slightly.


And if you see that kind of a downward change


with the click-through rate, I wouldn't


assume that it's something that you're doing wrong


with the search results.


It might just be that the impressions has gone up.


Right.


So for paginated SERPs, like we're used to seeing,


you're not necessarily getting an impression for your site


if you're ranking on page two until a user clicks


onto page two of Google, correct?


Exactly, yes.


OK, awesome.


Thank you so much.


Mark.


Oh, no.


I can't hear you.


I could hear a buzzing, so something is on.


Can you hear me?


Yes, perfect.


Sorry.


My question kind of links to Neil's question,


and it's about your money, your life.


Would you consider texts about energy supply for the household


or telecommunications supply for the household,


would you consider them to be part of the your money,


your life structure as well?


I don't know.


I think for things like this, on the one hand,


we don't have this hardcoded inner algorithms


that we try to look out for these specific kinds


of pieces of content.


So it's not something where we would have an absolute answer.


But what I would do is look at the quality rater guidelines


and see what kind of sites they're talking about there.


And then based on that, try to estimate.


But it's also something where you can ask users directly,


where you can do a small user study,


or where you could do maybe A, B testing on your website,


where you have some of your content with an author


and some of it without an author.


And you just kind of see, from almost a natural point of view,


do users react differently to this content?


And based on that, make your decision.


OK, thank you very much.


Rafael.


Hey, John.


So my question is, I have a customer


that they have a very high average response time,


two seconds to be precisely.


And I'm having a very hard time to have buy-in from them


to improve that.


So I would like to know, how does the average response


time impact rankings and search?


Or improving that, what benefits this website


would have for Googlebot or from an SEO point of view?


So this is question one.


And then question two is on a different subject.


That is, another customer, they just redesigned their website.


It's still the same CMS and content.


And after that, all of our FAQ schemas


stopped being displayed in Google search results.


And this is three months old now.


And we still are not there, even everything


being passing on the rich results


test and inspection tool.


So what did that happen?


And when should I expect to see FAQ being displayed again?


Or if it will ever be.


So thank you.


OK.


So average response time, I assume


you're looking at the server response time in the crawl


stops or things like that?


Yeah, in Google Search Console.


So two seconds seems pretty long to me.


Usually, I recommend, like, we don't have any fixed numbers.


But I recommend somewhere along the lines


of maximum 200 milliseconds to aim for.


And two seconds is a lot more than that.


What this affects is how quickly we can crawl.


So if we want to crawl, I don't know, 100 URLs right now


from your website, and we think we


can do maybe five connections in parallel to your website,


then based on that response time,


those 100 URLs will be spread out.


And we won't be able to crawl that much per day.


So that's usually the primary effect,


that we just don't crawl as much as we could.


And does 30-part scripts, do you use 30-part scripts


into consideration when measuring that?


Or it's purely my server?


That's purely your server.


And that's purely the HTTP requests


that we send to your server.


So if you have one page that has CSS and images and things


like that, the overall loading time,


that goes into the Core Web Vitals.


But the individual HTTP requests,


that goes into the crawl rate.


That answered my question.


Thank you so much.


And that doesn't affect the rankings.


It's purely just from a technical point of view


how much we can crawl.


And the other question, I think, was the FAQ schemas.


I think there are two things that might have happened.


It's hard to say offhand.


One is that we might have re-evaluated


the quality of your website overall at about the same time


that you made those changes.


It's probably more of a coincidence,


if that were the case.


But it could be that we are not that convinced


about this website anymore.


And if we're not convinced about the website,


then usually we don't show any rich results.


And that would include the FAQs.


So one way to kind of double check that


is if you do a site query for these individual pages,


do the rich results show up there or not?


If they do show up there, then that means technically we


can recognize them, but we don't want to show them.


So that's kind of a hint that maybe from a quality point


of view, you need to improve things.


If they don't show up with a site query,


then that means more that there is still


something technical which is broken with regards to that.


So it's not that there is a fixed delay


after a restructuring of a website for us


to start showing them again.


It's more like maybe there was coincidentally weird timing,


or maybe there is a technical issue.


SPEAKER 2 Yeah, no, thank you.


But I didn't know about this hack.


I will try here.


Thank you.


Yeah, it's not 100% perfect, but it


works for a lot of these cases when it comes to rich results.


Cool.


Let me take a break here with the recording


so that we have kind of a shorter


recording for the channel.


And I can answer more questions afterwards with you all as well.


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


Feel free to submit more questions on YouTube


for the next Office Hours or join us in person


if you'd like to.


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

All right, welcome everyone to today's Webmaster Central


Office Hours Hangout.


My name is John Mueller.


I'm a Webmaster Trends Analyst here at Google in Switzerland.


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


where folks can join in.


Anyone who is working on a website


and has questions around their website and web search,


we can discuss these questions and find or try


to find some solutions.


A bunch of questions were submitted already


on YouTube, which is awesome.


So we can go through some of those.


But as always, if any of you want


to get started with a question, feel free to jump on in.


I have a question, if you like me.


Sure.


I wonder if Googlebot can crawl user-driven events on a page


or not.


What kind of pages?


I'm asking that Googlebot can crawl or not user-triviable


events on a page, like single events or JavaScript events.


I am also talking about.


Usually not.


So how can I show this to Googlebot?


Like dynamic rendering or HTML snapshots?


What kind of a technology I can use?


So anything like dynamic rendering works.


Anything that you can do to make it so that the content loads


with the link rather than interaction, that helps as well.


Let's say I am using a pop-up, which can be


seen after 30-second sessions.


So I wonder if Googlebot can see this or not.


Maybe.


So we render the page, and we try


to give it a bit of time to settle down.


But if you're doing something where in 30 seconds,


something changes on the page, I don't


know if that's long enough wait that Googlebot has already


rendered the page or if Googlebot is still


rendering the page.


OK.


I have another question.


So let's say I am refreshing the web page after 30 seconds,


and I am redirecting it to another URL.


So Googlebot can see this or not,


because it is a kind of sneaky redirect, as you know.


Yeah.


So maybe we can see that.


That's similar.


If you're waiting a certain period of time,


then it's possible that we can see that.


It's possible that we don't see that.


OK, thank you, John.


Sure.


Hi, John.


Hi.


We have got a question from one of our clients.


They want this clarification.


So the question is, if they show their Google


review on their website, will that affect their ranking?


Will that help to improve their ranking?


What are they showing on the site?


Google business listing review.


So the review they are getting on their Google business


listing, if they show those review on their website,


how does it impact their ranking?


I don't think it would impact the ranking at all.


OK.


It's not that we would rank it higher, definitely


because of the review content.


If they use the markup for the review for their business


on their business home page, we would not


show those review stars.


And maybe there is something in the reviews that


is content that they wouldn't otherwise have on the page.


If a customer writes about their service


and they don't have the service described on the page,


then that might be something where it could rank.


But by definition, just by having


the Google review or any kind of review on a page


doesn't make it rank better or worse.


And one more question.


So we have found recently that some of our clients


have a lot of issues with their structured data.


And most of the structured data actually


are generating from the markup.


So those markup actually generated by what this plugin.


So it is very difficult to fix those structured data.


Because if we need to fix this, we have to fix the entire


plugin.


So will it affect the ranking for having wrong structured


data on the website or invalid structured data on the website?


No.


It won't affect the ranking.


But it might be that we don't show the rich results for that.


If the markup is such that it doesn't match the requirements


anymore, then we wouldn't show those rich results.


So it wouldn't affect the ranking.


But it might affect how it's visible in search.


And with that, it might affect how


people click on the results.


So even if they rank the same, if users


can recognize that this is really


a good result with the extra structured data,


then maybe they'll click more.


So it's something where I think it's worthwhile to try


to get these fixed.


But if you can't do it, you can't do it.


But then I would consider double checking with the plugin


creator to see if they can improve that.


Because if they fix the plugin, then that's fixed for everyone.


So I think that would be useful.


SPEAKER 2


So one of our clients has a lot of pages


related to one keyword or the variation of the keyword.


So what we are trying to do, we are


trying to remove those pages and try


to put all the content in one page


and redirect those pages to that one page.


Now, the rank, those web pages have


rank on Google search results.


So if we do this, the new page will get the rank,


or that will take time?


That will take time, so yeah, so if you combine multiple pages


into one page, then it's not like just adding the page,


the visible, the impressions from all of these pages


up and saying, well, it'll rank like three times as much.


It'll take a bit of time.


In the beginning, you probably see a short-term effect.


And then over time, you'll see that it settles down.


I think in general, it makes sense


to combine multiple pages that are on the same topic


into one stronger page.


So I think that's a good approach.


Thank you, John.


Sure.


Morning, John.


Can you hear me OK?


Yes.


Great, so we sell floor pane online.


And one of our main category pages is floor pane.


Now, we're struggling to rank in Google


for that page or that category.


Instead, Google's choosing for that particular term floor


pane to rank one of our product pages.


Now, we've tried various optimization techniques,


sorting out the canonical URLs, the H1 tags, on-page content,


everything.


And we're still getting issues with getting that category


page to rank.


I just wonder if you could offer us any advice.


OK.


So it's basically a product page that


is ranking instead of the category page that you'd like.


That's right.


Yeah, I mean, the product page is still somewhat relevant,


but obviously not as relevant as the category page, which


has got the keyword in the URL and things like that.


OK, and the category page is indexed.


So if you.


Yeah, definitely indexed.


OK, so I think from a technical point of view,


that's pretty much kind of OK in that if it's indexed,


then we can try to rank it.


What is probably, or I don't know, some of the things


that you could look at here.


One thing is to make sure that the category page is well


linked within your website.


So if you have multiple products that


are all in the same category or related to that category,


then link to the category page so


that when we crawl the website, we can really


understand this category page is actually really important.


We should focus on it.


So internal linking.


Yeah, internal linking is one thing.


Another thing that I've sometimes seen,


especially with e-commerce sites that kind of struggle