You can cache them infinitely, because if they


JavaScript SEO office hours October 28th, 2020

change, then file name changes.


Yeah.


That's a really good practice.


I also found, I think by default,


CDNs will not cache HTML resources, because they vary.


They might have user specific stuff and things.


So I was thinking the same with that,


that that should be on a different domain to your static


stuff.


And it's probably, I'm seeing this,


because Australia is the wrong side of the world,


and I've got servers in the US, CDN here.


And so I found HTML going via the CDN would add half a second


to the basic request.


And just tossing it up, faster images, slower HTML.


So I'm thinking about this idea of split, like you're saying,


use subdomains and things like that.


Yeah, that's a really good common practice.


And as you say, it can differ quite a bit


if you're pushing non-cacheable things to those CDNs.


That's a good observation.


And yeah, I know how you feel.


We had customers.


I used to work for a company that


had a few customers from Australia,


and we ended up actually basically spinning up


a few instances on Amazon in Australia,


just because that's the only way to make it reasonably


fast without much change to our code or our infrastructure.


Fun times.


I think Natalia had a question as well.


Yes, I have a quick question, or maybe not a quick question.


We'll see.


I'm wondering, because very often when


doing page speed reports, JavaScript from third parties


is flagged.


And particularly, I'm referring to a case


that I've seen many times in international SEO, where


we use, for example, Google Analytics and also Yandex


Metrica or different third-party scripts we cannot really change


and optimize.


And I wonder if there's any best practice to solve


this issue with the speed.


Because typically, it's making the results terrible,


and it's always a battle to convince the developers


to keep the codes like that, like Yandex Metrica,


for example.


It's typically like 20-second difference in the page speed


results.


So I wonder if you have any advice on that or any concept


how to maybe execute it so it doesn't harm the result.


Oh, that's a really good question,


and definitely not a quick one.


Because it comes down to a very subtle, very delicate balance.


On one hand, you want to load these things as early


as possible so that you have a good chance of catching


everything that happens on the page.


On the other hand, it makes things slower.


That's just by the nature of these scripts.


It doesn't matter if it's Google Analytics,


if it's Yandex Metrics, if it's HubSpot, if it's Hotjar.


It doesn't really matter which one it is.


They are working really hard on making these things as fast


as possible.


But any JavaScript interaction, any JavaScript request,


or any JavaScript resource that needs to be fetched


does make things a little slower,


and sometimes a lot slower.


So you want to load them as late as possible


in the process, which contradicts what I just said,


that you want to load them as early in the process as possible


to catch as much.


So you have to be a little on the fence about,


am I more OK with losing some data in terms of analytics


and tracking versus how OK am I with losing


some of my performance?


And in my opinion, I would load them as late as possible,


and I would load them as deferred so that basically


the entire HTML gets parsed and displayed


and the vital JavaScript, the bits that actually serve


the content if you're using a client-side rendered


application, basically get to work and fire first


so that they actually display the application rather than


showing or basically loading the tracker first,


but then starting with the application.


What this balance is and what it looks like for you,


that depends.


That's a really tricky one.


There is a brilliant talk by Harry Roberts,


who talks about third-party JavaScript.


Let me see if I can find it real quick.


Third-party scripts.


I think that should give me a reasonable.


So actually, there's also an article.


Aha, OK, that's nice.


The article is from 2018.


I'll post it in the chat real quick.


I'll put it in the video notes for those


who are watching the recording.


That article, it talks about identifying these,


auditing these, and then discussing with people


about the value of these.


And what I found that surprised me a little bit


is that sometimes you run into, oh, and here's the talk video


as well.


You run into third-party scripts in large sites.


Like, there's five, six different analytics trackers


in there.


And then when I worked in a company that


had that situation, I just accidentally removed two,


and no one ever complained.


So I removed the third one and the fourth one,


And then we ended up with.


I was working there because I would be


the one to complain usually.


Ha ha ha.


Perfect.


So that's the situation that you might find elsewhere,


but then not you.


If you are on top of your trackers,


then that's not really a valuable alley to go down.


But it's tricky.


And what we found for Google, well, when I say we,


at the company I worked for beforehand,


before I joined Google, we actually


used the Google Analytics, I would call it,


API to basically fire our events when we needed.


Because we basically just wanted to see, basically,


conversion tracking, what happens,


how do people navigate through the site,


and when do certain events happen,


and how often do they happen, and which locations


do they usually happen from.


And then we basically built our own analytics tracker


based on the Google Analytics tracking API,


and then shot these requests ourselves.


It is a little tricky.


It is heavily under-documented, if you ask me.


But it might be worthwhile if that's what you're using.


Maybe Yandex has something similar.


I'm not very familiar with their product.


But besides that, just load your trackers as late as possible.


And when I say as late as possible,


as late as is reasonable for what


you need the data to look like.


Because to be fair, you always have gaps


in analytics and trackers.


I think I read numbers somewhere between 10% and 30%.


These numbers will be off.


So then the question is, knowing that there


is such a gap in the data already,


is it worthwhile making everyone wait for these trackers


to actually load and fire?


That's a question that you would have


to answer for your specific case.


SPEAKER 1 Thank you.


Yeah, that's a good answer.


A lot to think about.


Many decisions to make.


Mm-hmm.


I know.


It would be great if it would have been a quick answer,


like, yes, no, maybe.


But I mean, the short answer would have been, it depends.


But that's not helpful.


Awesome.


Do we have other questions in the audience?


Why is it always the leaf blower, people?


I'm not sure if you hear it on the recording


or if you hear it in the live.


Someone literally, like five minutes


before we started recording, decided to start blowing leaves.


Mm.


SPEAKER 2 An important update.


How are the sheep?


SPEAKER 1 Oh.


Ah, sad news.


The sheep are gone.


They were taken away on Monday.


And it was particularly sad because it was also raining,


like torrential rain.


And the sheep were standing there looking a little sad.


And they were like, bah.


And then they were taken away.


And I was like, no!


Don't take them away.


Leave them be.


But I mean, on the other hand, they did a great job.


The grass is really short now.


So I understand that they have to move on to greener meadows,


to greener pastures, I think is the term


that you use in that case, which is sad.


But it's good for the sheep, I think.


So I have to take one for the sheep.


But yeah, the sheep were fantastic.


If you are not aware of what happens with the sheep,


check out my Twitter feed.


Go back a little while, and you'll


see what I mean because there were sheep here


in the neighborhood.


And I could see them from my home office desk.


And now they're gone.


All right, excellent.


In that case, thank you very, very much.


The next JavaScript SEO office hours will be in two weeks.


That'll be the me and my calendar.


Hold on, hold on, hold on, hold on.


That'll be Wednesday the 11th.


Yeah, press F to pay respect to the sheep.


So Wednesday the 11th at 6 PM Central European Time,


we will have the next JavaScript SEO office hours.


I will post into the YouTube community thread.


So that you can drop your questions


or join the live recording next time.


Hi, Deborah.


Good morning, Martin.


How are you?


Great, how are you doing?


Do you have a question?


I do have a question.


And I'm like, is it JavaScript only?


Can I only ask JavaScript questions?


These JavaScript SEO office hours


are JavaScript only questions, yes.


Oh, JavaScript only questions.


OK.


Well, then I really have to condense my thought to being,


I'm thinking about programmers, and I'm


thinking about programming.


And my conundrum is that when it comes to,


for programmers to start understanding your code,


excuse me, understanding SEO.


That's my big concern right now is having programmers


understand SEO concepts.


And that's where my question is, is


that when you're talking to programmers, coders,


front end people, back end people,


and you're trying to explain SEO to them,


I mean, they're not getting it.


And what I mean by that is that they don't understand


the Google guidelines.


They don't understand why we do these things.


They don't understand pagination and what it means.


And my question is, how can we better explain to them as SEOs?


You're a programmer.


How can we better communicate between one another


so that I can get my thoughts over to a programmer who


said, this makes sense?


I've come up a lot lately, so I was thinking


of your thoughts on that.


That's a really good question.


Thank you very much.


That's actually kind of my mission.


That's the mission I'm on as a developer


and working in the SEO space here.


My big mission is to bridge this gap in communication


and also teamwork.


I've done a bunch of presentations about it,


but I don't think we have found the silver bullet


to solve these problems.


The way that I usually approach it


is, depending on your developers,


they might already have certain awarenesses


about accessibility or performance or usability.


And then I tie into these things.


Because if they are accessibility aware,


so they are aware that they should build things


that do not per default exclude people


with different abilities, then I say, consider this like that.


That Googlebot or any other crawler


is basically a user with assistive technology


needs, because the crawlers are not human.


They can't really see.


They can't really understand the text necessarily.


At first, they just need to be able to consume


as semantically rich as possible data and then work from there.


If they are performance aware, which most developers


at this point are, because we have been talking about this


to them for the last couple of years,


that performance is a really important factor.


And you can say, look, performance-wise,


you want to make sure that your website is fast,


because that makes users happy.


And then they say yes.


And then you say, OK.


So then consider that to make users happy,


you don't only have to be fast.


Fast is one aspect of SEO.


That's one thing that I'm looking at as an SEO as well.


But also, we need to make sure that it shows up


in the first place.


Because in the end, good developers


want to build things for people to use.


But if no one finds your thing on the internet,


there is no one using the thing.


It doesn't matter how fast you make your website.


It doesn't matter how accessible you make your website.


It doesn't matter which JavaScript framework


you use for your website if no one's ever going there.


So what I usually tell them is, if I


were to ask you a question, where


can you rent sheep to mow your lawn?


What do you do?


And then they would probably say, I'll Google it.


Or I'll use a search engine to find it.


And then you say, aha.


So if you were the person to build a website for sheep


rental, what do you need to make sure in order for people


to actually find your website?


Well, that it shows up in search engines.


Yes, that.


And that's exactly what I am doing.


And that's what I'm really good at.


And that's what I'm helping you with.


You can focus on the technical side of things.


But please, please, please talk to me


so that I can test the things you build


and show you what you need to be addressing if there's something


going wrong in terms of us not showing up in search engines.


And then if they are understanding


that if they get the point that, ah, this is one more


requirement, because developers work with requirements.


Yes, they do.


Right?


They get a requirement like, this website


has to load in 1.5 seconds on this specific connection.


It has to be a, well, our editors


have to be able to upload products in the background.


It has to do this.


It has to do that.


It has to be mobile-friendly, whatever.


One more requirement should be it


has to be visible in Google Search


or in search engines in general.


I'm just coming from the Google Search perspective.


But it should be visible and standing out


enough in search engines.


And then they're like, ah, OK, so that's a requirement.


I don't know how to make sure that we fulfill


this requirement.


And you're like, well, conveniently, that's


exactly what I can do.


Let's work together on making sure that we show up.


Well, I love that approach.


That is amazing.


That usually works.


That's a great one.


And that's for the conscious developer


who's on the high-end spectrum.


What I'm seeing in the industry right now


is that the clients that I'm working with


are working with people to just get a website up.


And so a lot of them are on do-it-yourself platforms.


They're on customized CMS systems that have only


been evolved for half a year.


And they're buying into it.


And that's the stumbling block.


And so I think it's a twofold piece.


We're making developers aware of this.


We also are needing to make clients aware of this


on the small side because they're not sure.


They're building on systems.


And they're putting all of this effort and money into it.


And all of a sudden, it's blocked.


Or it's not even visible at all.


So these are the hurdles we're trying to get around.


I'm so super psyched that you're doing this.


And it's 5.30 in the morning, if I sound the way.


It's a little bit chattery, Eastern Coast time.


But thank you for this.


And I appreciate this.


And I will always listen in because that


was the best answer.


MARTIN SPLITT


Gee.


See, this is exactly why I swapped the times.


So in two weeks, it will be a lot later, actually.


I think it will be like eight hours later.


So that then is a friendlier time for you.


So every second week, you don't have to get up this early


to get your questions in.


Fantastic.


And I'll sound more awake.


Are you going to be posting this on Twitter, your Twitter feed?


That's how I found it, to notify us when these rooms are


happening.


I'm super.


You can also hop into youtube.com


slash googlewebmaster slash community.


And there's all the office hours.


So the ones that John does, there's


basically a posting.


Drop your questions here.


And then you can drop a question.


And also, we post the link to this recording


in these threads.


Thank you so very much.


Have a beautiful day.


Thank you very much.


Likewise.


Have a wonderful morning.


Wow.


So we are spanning pretty much the entire world.


Now we have Australia on one end,


and we have the US on the other.


That's amazing.


Sweet.


Any further questions?


Five, four, three, two, one.


All right.


Ladies and gentlemen, it has been a fantastic time.


Thank you so much for joining the live recording.


Thanks, everyone who dropped questions into the YouTube


thread of questions.


We'll see each other again in two weeks.


Stay safe.


Stay healthy.


Have a great time.


Bye bye.


Thank you.


Bye, Martin.


Bye, Maria.


Stop recording.


JavaScript SEO office hours April 22nd 2020

All right.


Hi, everybody, and welcome to the JavaScript SEO office


hours for this week.


And I see that we have a few people in the Hangout with me


as well.


And we have a bunch of questions that were submitted,


so I'm thinking that we have quite a bit to go through.


Is there anyone in the Hangout who


wants to already ask a question before I


dive into the YouTube submitted questions?


So I have a question for the beginning.


It's OK.


So we have one problem, signs two mounts.


We have to add two index XMLs to our search console.


Yes.


So we have two sitemaps.


Two index sitemaps.


Ah-ha, OK.


With sub-sitemaps.


Sure.


And we have a look in our programers,


and we can't see any difficult with this.


And the point is how we can maybe


check from Google if the sitemap is not really good


or something else.


Then the Google Search Console show us no trouble information,


but only read two sitemaps from the second index sitemaps


from roundabout 600 sitemaps.


You mean like URLs from the sitemaps?


You don't have 600 sitemaps, right?


No, no.


We have 600 sitemaps.


How many pages does your website have?


Roundabout, let me not lie, over 1 million.


We have 3D parts with configurations.


Right, but why do you have 600 sitemaps?


This is catalogs.


Catalog sitemaps with parts from the catalogs.


For example, we have parts from MIN,


and they make something like screws and engines


and something else.


And you can go to us and download 3D files from this


to use it for your CAD models and so on.


But why is there a separate sitemap for just that?


Why is that not part of the general sitemap?


I mean, I get the point that some websites are nesting


their sitemaps, but not for the URLs.


That doesn't sound like.


I afraid we need to split by 50,000 sitemaps.


Yeah, OK.


Yeah, we need to split.


And then we need to make a new sitemap.


I know where the maximum number of URL is, actually.


But let me double check if we can.


Sitemaps is a little outside of what I'm normally dealing with.


But OK, so with the sitemap question,


I'm not 100% sure because that's a little outside


of my area of main expertise.


But generally speaking, so if I understand correctly,


the problem was that we are not seeing


all of your nested sitemaps, or we are not seeing


or we are not indexing all the URLs from the sitemap.


So the problem is the second index sitemap.


Let me explain.


The second index sitemap have over 600 sitemaps.


Index sitemaps have over.


Right, hold on.


So you have a sitemap XML.


And then in the sitemap XML, you are specifying other sitemaps,


right?


Yes.


And now we're talking about one that is specified in there.


Like you have some.


No, no, no.


We have two of this.


We have one sitemap with specified sitemaps,


one index sitemaps.


And the second index sitemaps have the problem


that only the second and the five elements,


the second and the five sitemap in this index sitemap


is only got read.


Anything else is ignored.


And I don't understand why he look


for the second and the five element, not for the first


and so.


Yes, sir.


That should not happen, generally speaking.


I would bring that up either in the Webmaster Forum


or in the general SEO office hours with John,


because he might know something that I don't


know about this kind of thing.


OK, OK.


Good.


Awesome.


Sorry that I wasn't the right person to answer this one.


No problem.


Thank you.


You're welcome.


Now, I think I take one from YouTube.


We are in the process of replacing the HTML text


content of our pages with JavaScript fill text commands


on HTML5 canvas.


That's not a good idea.


Are there any plans to index text and images canvases


in the near future?


I can't predict the future.


I can't make announcements of that sort.


I can't.


I don't know.


We don't have any plans ready for public highlight


that we are planning on indexing anything in text or sorry,


indexing text and images or in canvases.


What are the recommendations for exposing this text content


in the way the indexer can actually


read it without violating cloaking guidelines?


Honestly, for accessibility reasons to begin with,


you should not do this.


I know a bunch of projects that tried


to do this successfully and nicely and fancily.


They all are not around anymore because it turns out


to be quite hard to do this, what your browser does for you


for free.


You can't use CSS.


You can't use any of the browser given


like we resize or responsive paradigms.


You have to basically calculate everything yourself.


That is a pain for both people using screen readers as well


as bots.


And it also is not very performant usually


unless you are really using something like WebGL


acceleration for this.


But I would just refrain from doing it


unless you have a very, very important use case where


you 100% have to do this.


And then you just bite the pill that you are not getting


indexed.


But honestly, I would not do that.


To avoid impacting page load times,


we would like to populate this HTML strictly


after the visual text is painted to the canvas.


What signals can we send received


to ensure that text is ready before the index is


pushed towards the page?


There's no such thing.


Just build a normal HTML page.


Trust me, you will be better off.


That's that.


So canvas and image rendering things, I would not do that.


Now, more people joining.


That's lovely.


You advised on April 8.


That's a good one.


On April 8, you advised against no script in favor


of native lazy loading or something


like, for instance, the Intersectional Observer, what


they say is the Google-suggested way.


But the former have browser compatibility issues


with the later.


You will not show images for users without JavaScript.


Well, first things first, I didn't


say I advised strictly against using no script.


That was something that was blogged about.


But it's not what I said.


I said I would not recommend relying on it 100%


in for the future because you don't


know if we actually at some point might deprecate that.


We are not having plans to deprecate that either.


But I just say it's a fallback solution that I would not


exactly suggest.


The native lazy loading, yes, that


is not compatible with all the browsers.


A bunch of browsers don't support it.


But I think it is a nice progressive enhancement


for those people who are using a browser that supports it.


And more browser support will follow in the future,


I'm pretty sure, because it's kind


of an obvious thing to do.


And those who are on an older browser might not get it.


But they're not losing something.


They don't have the best experience, sure.


But you have to draw a line somewhere.


If you understand your user base well enough to say,


oh, most of our users are actually on a browser that


don't support it, which I think I would argue today


is actually the case for most websites, to be honest.


You can do both the no script fallback


on top of the JavaScript way that we can index it,


because that doesn't hurt you either, especially


because the no script fallback is for those users who


are not using JavaScript.


And they would get the images nonetheless.


And then the crawlers who understand JavaScript


get the lazy loading that works, using, for instance,


an intersection observer, whereas the browsers that


don't support JavaScript get the fallback,


or sorry, crawlers that don't support JavaScript


also get the no script version.


And I think that's fine to do.


I'm just saying you want to re-evaluate that.


In the future, it's not a bulletproof thing forever,


unless you are using the way that


works for Chromium-based browsers,


because that's, I think, what Bing uses as well,


because they use Edge, and Edge is now a Chromium-based


browser, as well as we are using a Chromium to render.


So we are seeing the content.


I'm pretty sure Bing will see the content.


You would have to test with their tools


to make sure that they see the content.


And that's not going away, whereas the no script


fallback, if that's your only strategy,


it might go away at some point in the future.


Might being the keyword here.


I'm not saying we are about to deprecate it.


What I'm saying is it's not a future proof


thing for SEO purposes.


It is still future proof for your users.


So go with that.


But anyway, you would have to more or less


evaluate what works for your user base


and for your use case as well.


Martin, that is my question.


I have a follow up question on that.


So I also have it here.


So compared to the method that you just


say using JavaScript and fallback to non-script,


there is another method that also progresses enhancement


required by Lighthouse.


I paste the link here.


What they do is that they say that you actually


can do one thing.


They said you use native lady loading first,


but you don't put RFE first.


You put data as RFE in the lady loading.


And then you use JavaScript to detect if the browser support


is not.


They polyfill the JavaScript to do.


So it's basically natively and fallback


to JavaScript load.


So my question here is that first,


how do we specify placeholder in this kind of fallback?


Because it's like if you use lady load first directly,


you know the placeholder is the INC source.


But if you do this kind of progressive enhancement,


how do we specify placeholder?


And another issue is that compared to this


and use direct JavaScript lady load directly


and fallback to non-script, which one is more safe?


And yeah.


There's no simple answer to this is the thing.


Then I would say using either the JavaScript approach


with the intersection observer or maybe


using this hybrid approach that web.dev documented here


is a very fine way to go about it.


You can always also specify the no script version.


That never hurts.


It won't hurt you.


You should not rely on the no script version


to fix all your SEO problems in the next 100 years.


But for now, it works even for Google search,


which would just mean you have multiple ways of actually


giving us the image.


We don't really worry about that.


It's not a problem to have a no script fallback.


So if you want to be super foolproof


and make sure that it always displays images,


you can use one of the lazy loading strategies


plus the no script fallback, for instance.


You can use the approach that web.dev took.


I'm guessing as a placeholder, you can just


specify the image source here on top of the data source.


I guess that's fine.


I'm not sure about that.


You would have to ask whoever wrote this article, which is


not clear from the page itself.


Yes, it is.


The authors were Hussein, Adi, or Matthias


would be the persons to ask for this specific approach


that they documented here.


But yeah, so no script will be foolproof


and is a way of making sure that it also works


when JavaScript does fail.


OK, thank you so much.


Follow up question, not really related.


A lot of developers worry about a no browser


don't support JavaScript.


But actually, how many browsers actually


don't support JavaScript?


So that's a good question.


And the answer is that's the wrong question.


Because the thing is, yes, pretty much every browser


supports JavaScript.


But there are privacy extensions that some people


use that are very, very clearly disabling pretty much


everything unless the user specifically opts in.


So they might not see the content immediately.


There can always be transmission issues


if you're on the mobile phone.


And the HTML, as the HTML arrives over the wire,


can already start rendering.


With the JavaScript, I have to wait until everything comes


down.


And if my JavaScript is like half a megabyte,


and then in the middle of it, the connection is cut,


the JavaScript won't execute, and I won't


see anything on my phone.


So that's the case that you might want to prepare yourself


for, but only if you have data that you


need to prepare for that.


So if you have, for instance, telemetry on the errors


that you're getting, and there's errors that support


the hypothesis that JavaScript loading failed


for a bunch of your users, you might


want to consider that a case for no script.


But generally speaking, pretty much every browser


has JavaScript, and it normally works.


There are cases where it might not work.


SPEAKER 1 OK, thank you so much.


MARTIN SPLITT


We might also just consider it a bad title


if the title does not seem to be relevant to the actual page


content, and then we just might rewrite it.


The same goes if the query suggests


that we might want to rewrite the title,


we might rewrite the title.


But generally speaking, the rendered JavaScript title


should take precedence unless there


is something going wrong in rendering, which is unlikely.


Do we have questions from the Hangout


before I continue with the submitted questions?


SPEAKER 2 I have another one.


MARTIN SPLITT Sure.


SPEAKER 2 OK, so my question here


is that since HTTP 2 is supported


by most of the browser now today,


and most of the websites using them,


is that still important to limit HTTP requests


for external JavaScript and CSS?


Because they are download parallel anyway.


Like for example, if I have 100 external JavaScript,


and they are deferred through async,


would there still be a problem for page speed?


MARTIN SPLITT That's a good question.


I think there is still a maximum of multiplexing that


can happen in HTTP 2.


I'm not sure what that would be like.


But I'm not sure if you can just say, OK,


I'll just get everything over HTTP 2 in parallel.


Some browsers and some connections


might still fall back for whatever reason to HTTP 1.


So I would be a little careful with that.


I would still try to minimize the amount of resources


that you're loading specifically,


which is like this weird thing.


You have to find the balance between minimizing


the amount of resources and also making sure that you're not


forcing the entire application bundle down on every request.


And so it's a dance between splitting the bundles


reasonably and minimizing the amount of external resources.


MARTIN SPLITT OK, so from what I heard,


is that it's still safer to try to not request


too much a request from?


MARTIN SPLITT It definitely is safer


until we are very, very surely in HTTP 2 land.


Also, for instance, Googlebot will still


fetch from HTTP 1, at least for now.


So hm.


AUDIENCE MEMBER OK, thank you.


MARTIN SPLITT You're welcome.


So I run site audits for clients.


And one point is to check JavaScript navigation.


But I thought Google can follow JavaScript navigation.


Are there any cases where it can't?


What's the proper way to execute this so it's not a problem?


Is the person who asked this question in this Hangout maybe?


No.


OK, generally speaking, if you use JavaScript


to generate your navigation, that should be fine.


If you are generating proper links,


and proper links are links that have a proper URL,


and an href, and are an anchor tag, and all that,


then that should be fine.


If your navigation, for some reason, is a dropdown,


we are not going to interact with that.


If your navigation is, and when I say dropdown,


I specifically mean like an HTML select element,


or something like that.


If your navigation is a bunch of span elements, or LI elements,


with an onclick handler, we're not going to see that.


But that's not specific to JavaScript navigation.


That's just generally specific to links.


So just make sure that we see the content rendered


in our testing tools.


So you can use Google Search Console, or the rich results


test, or the mobile-friendly test, to make sure that


the content is in the DOM.


And then with that, you should be fine.


That's pretty much it.


Oh, there's another good question that I saw earlier.


Many sites we review enjoy using full-page hero images


that require a scroll to see the rest of the content.


All data is in DOM without scrolling.


So Google render look poor, like the screenshot


that you get looks poor.


Can this be an indexing handicap to the content


you need to scroll to, so there's hidden content?


No.


No, that's not a problem.


If it's in the DOM, that's fine.


That's it.


Don't worry about it.


Just make sure that it's in the DOM.


That's really important.


Do we have questions from the live audience?


Sure, I have a question.


Sure.


Maybe a little bit a crawling problem with Google


bots and JavaScript.


So we have for around about five months


changed our URL schema.


So from URL question mark, we have


question mark q equals blah, blah, blah, blah, blah,


to slash folder like stuff.


And we have from time to time a problem


that Google crawled new URLs with the wrong URL


schema, with the old one.


Right.


This is about the last one is from one week.


And the question is, this is the problem from Google


that they catch the JavaScript too long.


And when yes, how long catch the Google bot to JavaScript?


That is one possibility.


It is possible that we are seeing the old URLs


because your JavaScript wasn't updated.


That is definitely a possibility.


We are trying to catch as long as possible.


We might catch longer than you specify in the cache header.


The best thing that you can do is version your JavaScript


assets.


Yeah, we do this.


And we can see if I can, yeah, sorry.


Then that shouldn't be a problem.


There are certain situations where


we might hit the old version, but it's very unlikely.


What can also happen is that we are just


seeing somewhere else linking to the old URLs.


OK.


And the second question is, if I look at this link,


you say to me the canonical is like the link he get.


And this is totally wrong.


He can't get this canonical.


We have write something that we change the canonical


to the new one.


Save.


That is great.


However, that's not how that works.


The canonical that you give us is a hint to us.


There are situations where we might


decide that that's a nice hint that you give us,


but we think the other thing has a good reason to become


the canonical lead in this case.


So we basically cluster the URLs,


and then we choose the leader from that cluster.


We say, OK, so all of these URLs point to the same thing.


And then we look at signals.


And one of the signals is the canonical that you pick.


But very often, webmasters pick the canonical incorrectly.


So we can't just use that and then be merry with it,


because we would break half of the internet that way


in Google Search.


So what we do is then we look at other things,


like how many inbound links do we have on this,


and how often do we crawl these, and what kind of content


do we see at these.


The canonical can change over time.


So if these old URLs are dying out,


then I wouldn't worry too much about that,


especially if your server setup is anyway


redirecting to the right URL, then whatever.


I wouldn't worry too much about it.


It can be a little bit of a pain to actually track reports


in a search console then, because they


are using the canonical.


I'm aware of that.


But unfortunately, I don't have an easy answer for this.


If you have a sample URL and you post that in the Webmaster


Forum, and you point me to the thread, or you post it here


in the chat, or in the YouTube thread for the questions,


I can take a look at it, but I can't do much about it.


I can only maybe at least explain why this happens.


But there's not that much action that can be taken by me


or anyone else, really.


If the old URLs are disappearing from the internet,


and you are also submitting the new URLs via sitemap,


and you are making sure that pretty much everything


redirects to that new URL to be the target,


then eventually we'll see that, OK, so yeah,


the old URL that we picked as a canonical


is no longer a good candidate for this.


And then we might switch over to the canonical


that you're giving us.


Shouldn't cause a problem, but is a little inconvenient,


especially in reporting, I'm aware.


SPEAKER 1 OK, thank you.


I can.


MARTIN SPLITT I can.


You're welcome.


So let's pick another question from here.


Mm.


A bunch of them aren't actually JavaScript related,


but that's fine.


Hi, Martin.


How does Googlebot handle the spoiler boxes?


What's a spoiler box?


Like this.


There's a link, and then there's an href to some ID,


and then there's a onclick handler that does


a bunch of stuff with jQuery.


Oh, that's an easy question.


We don't click on links.


So if the content, it looks like you're not


loading different content.


You're just moving things around and making


them visible or invisible.


So if the content is in the DOM, how it looks like to me,


this will be mostly fine.


If it's hidden content, we might think it's not that important.


If this is your main content, the spoiler box


is your main content, you do not want to hide this,


neither from the user nor from the bot.


I think if it's hidden, we will consider it.


We might not highlight it in the snippet,


but we will see the content in the DOM if it's in the DOM.


If it's just in the DOM and hidden, we will see the content.


But we won't click on the thing, so we won't ever


see the spoiler box open, I think,


which should not be a problem.


Right.


More questions from the audience?


Yeah, I've got one.


All right.


A little bit.


Kind of more performance and speed related, really.


Particularly when you've got something like an SPA,


initial load might be much slower than obviously


navigating through the routes or something that hydrates.


But I assume that maybe Google would consider maybe


that first load, because that's what's


important from Google's perspective,


rather than speed that might be sort of someone's using the app.


Would that be roughly right assumption?


That sounds pretty much right in the sense of, yes, sure.


The moment a new user comes in, the website will be slow,


and then it will be faster on subsequent navigations.


So that's the same kind of situation


that you run into, especially if you use a service worker.


If you use a service worker, and your service worker caches


everything on the first load, and then everything else


is fast, that's fantastic for the user,


except that you still need to worry about the initial load


time, because that's what a first time user sees.


And the first time users are normally the ones that are,


from a user experience point of view.


If I'm doing a user study, the first visits


are what I most worry about, because those are the people


who are most volatile.


They come to your website the first time, and they're like,


ah, this is not loading.


And then they are gone.


So all of the things that your service worker


or your single page application did in the background


are lost.


So I would say, for page speed, you definitely


want to have a close look at the first load experience.


Awesome.


Also, just that reminds me, someone recently,


somewhere, asked me to explain a service worker in layman's


terms, and I'll try.


If the person who asked that is in here or sees this recording,


you'll be happy.


A service worker, very fundamentally said,


is basically an intermediary between your application


and the network.


So you can imagine, if you have a normal website


without a service worker, the website, whatever it does,


when it sees like, oh, there's an image that I need to load,


it goes to the network and fetches the image from the network.


That's what it does.


There is also a cache that the browser controls,


but that might or might not happen.


So the website goes, oh, there's an image I need to load.


And then the browser might go, you


don't have to go to the internet.


I happen to have it here.


It's like, oh, cool, cool, nice.


But you don't really have control over that cache as much,


because you only control that via your server headers.


And if there's a proxy in between,


it might strip the headers.


And there's a bunch of things that


can go wrong with caching.


Now, a service worker is basically a little program.


It is literally a JavaScript program


that you can specify for your site.


I can say, OK, I'm owning example.com,


and I want to install this little service worker, which


is a little JavaScript program, where whenever the network is


somehow involved, this little program gets woken up


and gets to decide what to do with that situation.


So basically, if I'm the service worker now,


and there's the website over there,


and the website goes, oh, I have an image to fetch,


that will basically ring a little bell.


I will wake up and be like, oh, you need to fetch an image.


All right.


And now it's the decision and the job of the service worker


to figure out what to do.


It can do a bunch of things.


It can just be like, oh, you need an image.


OK, cool, you need that something, something,


header.png, sure, and then goes off to the network


and fetches it.


That's the dumbest service worker possible,


because it does what the browser would do.


But it also has options to, for instance,


have its own little cache, which is basically a storage room.


So the service worker gets woken up, get me that image,


and it goes like, oh, all right, OK, cool.


In that case, I'll get it, and I'll make a copy,


and I put that copy in my storage room.


Here you have it.


And then the next time the website asks for the image,


it has, again, more choice, because now I


have it in my storage room.


So I can either go like, this might be old,


and there might be a new version of this image,


but this is fine.


This is just the logo of the company, for instance.


Here you go, right away, without even considering the network.


Then I can optionally ask the network


if I want to update my copied version of that image,


or maybe I only do that once a week, or whatever.


I have the full flexibility as the service worker.


So you program how your application behaves.


The biggest advantage of that is that now the website,


without making any changes to the website,


if my service worker stores everything it sees in the cache,


and maybe I give it, even when I install the service worker,


I give it a list of things to put in its cache beforehand.


So basically, the first time I visit the website,


sure, the thing has to go to the network and fetch the image,


but my service worker also fetches everything on the site


and puts that into the cache.


And then the next time I'm asking,


I can get it out of the cache right away.


That's a lot faster than actually going to the network.


And the biggest advantage is, if I'm offline,


and my service worker is programmed in a way


to check its cache before it even tries to go online.


If I'm offline, it doesn't matter that I'm offline,


because my service worker has all the things


that it needs already in the cache.


So we can actually function independent of the network.


We can also say, OK, the website asks for this image.


I get it from the thing, and I try


to update it from the network.


Oh, I'm offline.


OK, in that case, I don't update it from the network.


So you get a middleman that you control,


and you control it by writing a little JavaScript, which


is your service worker.


So that's roughly it in layman's terms.


I hope that made sense.


So that's done.


And service workers are really, really flexible,


because I get to program the service worker to whatever


I need it to be.


I once built a service worker where


I ran into the situation that the API was


done using post requests only.


Post requests can't be cached, which is bad.


So what I did instead is I basically


rewrote the front end side of things


to actually make GET requests.


And the service worker that was in the middle


would take the GET requests and turn them


into the actual post requests and then cache the results,


because we can cache for GET requests.


So that way, I actually know, hold on.


We made post requests, but I basically


knew that if it's an API post request,


I decided I wanted to cache it anyways,


even though for some API calls I couldn't cache it.


So I got to program a service worker that very specifically


cached things from an API that was by default uncacheable,


which is quite cool.


If you don't have a service worker installed


or if the service worker fails for some reason,


you would still make the request straight to the back end


and get the data back.


It would just take longer.


So service workers are a really cool progressive enhancement


way of adding niceness to users where the service


worker successfully installs.


That's kind of nice.


All right, any further questions from you all in the call?


Oh, yes, actually, there's one in the chat.


Is that a question we've seen?


All right, so we've seen JavaScript play a major role


in how websites are built and how JavaScript frameworks


adopted and take advantage of it.


Most of the concerns now run around HTML and JavaScript


rendering.


What do you foresee will be the next challenges


for the upcoming years regarding the use of JavaScript


on websites?


Honestly, making things faster.


JavaScript still has this really not great property


of inviting you to build a bunch of stuff that will not perform


fantastically well for two reasons.


One reason is that it can't be parsed progressively.


You just cannot.


HTML, you can start rendering HTML as it arrives.


You don't have to wait until the entire HTML has


arrived on your end.


The same with CSS.


You can progressively build the CSS tree from the data


that you get from the network.


You don't really have to deal with that.


Whereas with JavaScript, you have


to wait until the entire blob is over.


And we are still not having easy to deploy


and easy to build ways of doing server-side rendering.


So that will be a thing where you


would be able to build the JavaScript applications


or the web applications with all the flexibility


that JavaScript provides you with,


but still have a fast experience for the users.


So that will be something that is not


easy to achieve right now that will hopefully


get easier in the future.


Then the entire, how do I split my bundles,


that still requires a bunch of manual work from developers


that hopefully we can somehow make easier


and the default thing to work.


So performance is going to continue


to be a big avenue of change or playground for change, I hope.


So do you think there will be attempts


to make JavaScript render progressively


or attempts to make it possible?


I don't think that there is a technical possibility for that.


An imperative language, as JavaScript is one,


is not really possible.


It's one of the downsides of it gives you


a lot of flexibility, which is fantastic,


but it also gives you the downside


of not being able to start rendering as things happen,


because you need the entire context to actually


be able to execute, to parse and execute JavaScript.


So I'm not sure that we're going to see


progressive rendering JavaScript.


I'm not sure where WebAssembly goes,


but as far as I'm aware, WebAssembly


has the same problem that you can only execute instructions


once you have the bundle compiled.


But maybe we have a way of actually getting that working.


That would be surprising and really cool.


And we are in future territory, so I'm like, I don't know.


Maybe none of what I just said makes sense,


where tomorrow someone finds a way to actually do the thing


that I found to be impossible.


But definitely also tooling is a big thing.


A lot of websites, I would argue,


that are built with JavaScript these days


don't really have to be built with JavaScript.


It's just the tool that's just a novelty.


No, no, I'm not saying that it's just a novelty


and people like to play with it.


It is just a way that allows you to build a lot of things


very flexibly, and then you might


be tempted to either use that for everything like a novelty,


or you might have reasons for it.


I remember when I was building a very dynamic web application


where there was no way around it.


We did VR in the browser.


There's no way in heaven that we can do that reasonably


without JavaScript.


We would have to run JavaScript.


So it was a dynamic web application,


but it also had an e-commerce kind of system attached to it.


So that also needed to be built and actually maintained


somehow.


We were a very small team.


So the only reasonable way of doing this was to say, OK,


so we can't afford having to run with two completely different


systems.


We can't afford to maintain a CMS and this application.


The only way forward for us reasonably


is to somehow integrate this into our existing system, which


is a JavaScript web application.


And so we ended up having a Vue.js-powered blog.


But because I was aware of the situation,


I was like, OK, as soon as possible,


we need to figure out how to at least server-side render


the static bits and figure out a way to keep the static bits


static without having to drag in a CMS or a completely


different set of tools that people have to deal with


to publish something on the blog.


So that's where server-side rendering then came in.


And I remember that was 2016 or 2017.


Server-side rendering of Vue.js applications


wasn't the obvious thing.


It wasn't easy.


And that's the same for every other framework


back in the days.


And that's just how you end up with situations where, like,


we know it's not great, but that's the only thing


that we can reasonably do at this point.


So I would hope that the tooling ecosystem explores


more way of giving you a well-lit path to success


where that kind of thing is considered from the get-go.


Because most of the frameworks that came out around 2014


until maybe, like, 2016 or something in that area of time


were pretty much like client-side rendering,


and then everything else was an afterthought.


So I would like to see us steering into clearer waters


where it's easier for developers to just build things


that are progressively rendering by default, no matter how.


And that would fundamentally have


to break down to server-side rendering at this point.


Server-side rendering and hydration is a great thing,


but it's not the default for most frameworks.


What I'd like to see is that what makes


me hopeful for the future is that both higher-level


frameworks like Next.js or Nuxt.js or Angular Universal


are getting a lot of traction recently,


as well as that more and more people are jumping


on what they call the JAMstack or jumping onto static site


generators like Gatsby or Eleventy or these kind of things


where you can build things with the technology


that you have at hand.


And you can use the same technology


to build something much more dynamic,


but you can also compile or pre-render it into HTML.


I always like to think when we are dealing with this now,


what's going to come ahead?


And I know the web technology that we use for websites


has gone from like, you know, JavaScript


always existed, it's like as old as almost as HTML.


And then we had stuff like ActionScript and Flash


and all of the things that came in and disappeared.


So I'm just thinking like, what's potentially


gonna come afterwards and what's gonna,


is JavaScript here to stay?


Is it just something that we are gonna deal with it


more natively going forward, more in the backend,


more in the frontend?


I mean, this is just like things that I try to anticipate


just to think the problem ahead of the time.


I think this is not a fad or whatever.


I think this is a fundamental shift


that has been going on for at least 15 years at this point.


When we started with Ajax around 2005-ish,


it became clear that the web is a fantastic application


platform.


It used to be a document platform.


That's how it was built and designed originally


to exchange documents and make them linkable to each other.


Since I would say 2012, 2013, 2014, 2015,


not, no, 2004, 2005-ish, it became clear


that we can build applications on this.


And if I look at my daily work, I


notice that a lot of this happens like Meet,


Google Meet that we are using right now is in the browser.


That's not a website.


Google Meet is not a website.


Maybe the landing page, yes.


But what we are using right now is not a website.


That's an application.


Google Mail is not a website.


I do things that I would do in an application, Google


Spreadsheets, Google Docs.


So many different things.


There's video editing tools.


I don't know.


There's so much going on, Facebook, Twitter,


all these things, social media.


Social media is actually an interesting thing


because you could argue it's a website,


but it's also more than a website.


So I think the paradigm shift from a documentation platform


to an application platform is powered and driven


by JavaScript.


And I don't think this has been at least happening


for the last 15 years, maybe even longer.


I don't think that's going to go away anytime soon.


And I don't think that we will fully


replace JavaScript with something else anytime soon


either.


So I would say prepare yourself for JavaScript to stay around.


It's just that we are learning where the limitations are,


and we're learning where the real world hits


the hopefulness of JavaScript developers in the way of,


oh, I can do this with JavaScript.


I don't have to deal with servers at this point.


And then it's like, oh, yeah, if I deal with a server,


I get a lot of benefits from that.


I do also hope that we continue to work


to bring things into a more declarative state of things.


So for instance, I know that we are working


on things like HTML modules.


We are working on things like declarative Shadow DOM.


And hopefully, eventually, we might get declarative web


components where we can then hopefully build things


with a little less reliance on JavaScript


and have more of the web platform take care of it.


Web platform meaning that the browser does the thing for you.


But I don't know.


This can go either way.


Either we find out, OK, this really


needs to be done in the web platform


and needs to happen in the browsers,


or no, this should not be done in the browsers.


We definitely need to make sure that we


are doing this in JavaScript land


because that's easier to deal with.


But JavaScript itself is not a fad.


And using JavaScript to build web applications


is not a short-time fad.


This will stay with us for a longer time, for sure.


Yeah, thanks for that.


I didn't want to monopolize so much the conversation.


No, no worries.


No worries.


Can I ask just one question before you finish?


Sure.


So actually, I posted my question in the comments


that you didn't pick it.


Let me see.


It was posted for like five minutes


before the meeting should have started.


So I'm not really sure whether it's JavaScript-related,


but I'm trying to get some kind of answer from anyone


from Google.


For some time now, I'm getting desperate.


So one company where I work, one of the main portals recently


had front page dropped from Google index.


It's actually not dropped from index,


but it doesn't show in search results.


And I'm not sure what could have been the reason of it,


because when I check it in Webmaster Tools,


it says that the page is indexed.


And I don't know when you try to see the search


results for this page.


It shows that from 23 days ago, it


doesn't have any appearance in search results.


The problem with that question is,


and I see the question in front of me right now,


and the reason why I didn't pick it and why I would never,


I would guess no one would pick this in an office hour


is that I don't know.


From the question itself, it can be anything.


It can be a manual action.


It can be that this is a display issue,


and we're actually seeing it in search results.


So it can be everything.


Without a URL, I don't know.


I can't do much.


MIHAI APERGHISLINGA. Maybe I can send you a URL,


and you can check.


MARTIN SPLITTENBERG. We only take information


through public channels.


But I think if you're using the webmaster forum,


there will be ways of getting the URL to us


to double check if it's a problem on our side


or if it's something.


Because the problem here really is I can't help you.


Because if I would, that would be unfair to everyone


else that I can't help.


And if I would have to help everyone


who has similar problems, I would not


get anything else done.


That's the reason why we're not offering private support.


What I can do if you give me a URL


is I can look if it's a problem on our end that affects


other sites as well.


And if it's a problem on our end that affects other sites


as well because it's a bug, then we would fix it.


But I cannot answer what you need to do to fix this problem,


unfortunately.


The best place for placing this question


really is the webmaster forum.


Because there are other users might have an idea.


And you can send these other users private messages


or basically like, I'm not sure how exactly the new system


works.


But basically, you can get messages


to what we call product experts who are very fantastic users


who help and dedicate their time for other users struggling


with things like this.


And you can get the URL to them privately.


You can also feel free to send me the URL separately.


Or you can share it now.


And I can have a look maybe.


That would definitely work.


And then maybe I can, ah, right, OK.


Maybe I can have a look at this and see.


And it's only the landing page, the home page.


SPEAKER 1 So it's only the home page


or other pages are not affected.


MARTIN SPLITTENBERG Okay.


That's an interesting one.


HTTPS www.


Just making sure that I copy and paste it correctly.


Because that's like this weird YouTube changes.


Or actually Hangouts changes the links.


As far as I can tell, it has impressions.


Plenty.


So if your search console somehow shows you


that this page does not have any impressions from search


results, then that would let me wonder


if there is a bug in search console.


SPEAKER 2 Yes, well, when I and everybody,


anybody from the company or even the country,


I've seen the URL that was most indexed.


For this page, you don't see this page as first search


result. It's actually the section


on the site, which is the URL.


Slash vst, which is new.


So if you try to search just a keyword,


it won't be the first result in Google results.


MARTIN SPLITTENBERG I mean, it's not the landing page that


is the highest ranking result. But that's a ranking question


now.


This is no longer an indexing issue or some JavaScript issue


that we have the content.


It does show up.


Your site shows up multiple times,


just like subsites of it, not the front page, which


might mean that we think the front page is not


a good hit for the specific thing, the specific query.


SPEAKER 2 Well, that started happening, like I said,


23 days ago.


And this was a page that was best ranked Google index.


And in two days, from, I don't know,


300,000 results per day fell to zero.


So I think that is possible.


MARTIN SPLITTENBERG I mean, the first thing is you say zero.


And that's not something that I can see here.


I see you have impressions.


So people are clicking on it in search results.


People are seeing it in search results.


It can't be zero.


So it must be, whatever tool, what tool


are you using that says this does not have any impressions?


SPEAKER 2 I'm using Google Webmaster.


So I can send you an interesting.


MARTIN SPLITTENBERG Because that sounds like there is a problem


with the reporting on this page rather than the actual page,


because you do have impressions on this.


SPEAKER 2 Well, I don't think I have impressions


for the home page, exactly.


MARTIN SPLITTENBERG You do.


SPEAKER 2 I do.


MARTIN SPLITTENBERG Yes.


This might be a reporting issue, if any.


SPEAKER 2 Is it possible to send?


MARTIN SPLITTENBERG I don't think you can send screen


shots.


So again, let me reiterate, the best place for this


is the Webmaster Forum.


SPEAKER 2 OK.


MARTIN SPLITTENBERG It turns out to be, sorry?


SPEAKER 2 Well, I'm happy that you gave me some answers.


MARTIN SPLITTENBERG Sure.


Not a problem.


That's what I'm here for.


And even though this isn't JavaScript related,


it seems to be fine.


From what I can see in our tools,


it does have impressions.


It does have clicks from search.


So there's nothing that prevents it inherently.


SPEAKER 2 Could I ask a JavaScript related question?


SPEAKER 2 Hi.


You look wonderful.


It's good to see you.


MARTIN SPLITTENBERG Thank you.


SPEAKER 2 We have a site that is executing third party


scripts via JavaScript.


The big problem is that they seem to fire


this sort of JavaScript and then converting a lot of stems


to the party.


And it appears to be causing a lot of rations.


Question, what would be the best way


to execute these third party scripts in a way


that they're not interrupting the time to interact?


Perhaps limit the amount of resources


Googlebot then has to exert to the third party script


that calls a friend that calls a friend that calls a friend.


It's got a crazy map.


MARTIN SPLITTENBERG So the best way


to, if the third party script work with that,


is to give them the defer attribute so that they are only


loaded very well at the end of everything


so that they can't interfere with the rest.


Also move them as far down as possible on the side


so that they get discovered as late as possible.


And that should be doing it.


The thing is that with defer, it might


be that if your application code somehow uses something


from the third party script, then that can get


SPEAKER 2 It wouldn't be there to catch the metrics.


I think that's the thing repeating it right now


is they need that loopback for tracking.


So would it be effective then to figure out


if we could split that main bundle into one


of the analytics needed and then the actual request


to request it?


MARTIN SPLITTENBERG Yeah, that could be an option.


JAMIE LIEBERMANN Thank you.


MARTIN SPLITTENBERG You're welcome, Jamie.


Thanks for popping by.


All right, time for one last question.


JAMIE LIEBERMANN I have another question.


Yeah, so is it a question about native lady loading?


Is there any specific condition to make native lady loading


work?


Because I see a lot of examples is


that there is a lot of web pages that use native lady loading.


And when I tested using desktop, it doesn't work.


But when I use mobile simulator, they work.


I have an example here, like this one.


When I use desktop, I do the network tab,


and you see that they start loading even


before down construct.


But if you use mobile simulator in the dev tool,


you will see that it actually only


loads when the viewport is close approaching.


Do you have any idea of, is there


anything that will happen to prevent lady loading


happening on desktop side?


I'm guessing either this is a browser bug,


or they do something like somehow specify that they want


this to be preloaded, or maybe there's


like a service worker involved that preloads it that


doesn't do that on mobile.


I'm not sure.


I'm not familiar with the website.


But generally, it should work on desktop.


Or should it?


Let me actually see.


Like, I have a very simple test page.


Actually, no, I don't.


Not for native lady loading.


I need to try that still.


I would ask either the Google Chrome devs account,


or maybe submit a bug in the Chromium bug tracker


to just get a feeling for it.


But for that, I would highly recommend


building a very minimal reproduction or reproduction


test case, where you're basically just loading


a bunch of images that are large enough to be out of the view


port as well with native lazy loading.


And if that doesn't work on desktop,


that sounds to me like that's a Chromium bug.


I see.


So if that is a Chromium bug, it's not just the


Might be.


So I mean, if that is the case, then every native lazy loading


will behave like that, not just the website that I saw.


Pretty much.


Well, I mean, it depends.


It depends on the bug.


If there is something that needs to happen to trigger that bug,


then no, not every website will happen.


But if you can't reproduce it, then it's


less likely that it's a Chrome bug than it's more likely.


Like, the harder it becomes to reproduce,


the likelier it is to actually be


a problem of that specific website,


and maybe others that are having similar problems.


That's a whole investigation.


I never did that in a lab environment,


but I saw several web pages behave like that.


Yeah.


I would try that with a reproduction case.


And if you can reproduce it on pretty much every website,


then it's definitely a browser bug.


Thank you.


You're welcome.


So I am looking for university3png.jpg.


This is a weird website, png.jpg.


Anyway.


So yeah.


Right.


In which case, I would think that I have exhausted


the YouTube questions mostly.


And I would think that we are over time a little bit,


but that's fine.


It's not that I have to be anywhere.


It's locked down anyway.


So in that case, thank you very much, everyone, for joining.


The next version in this time slot and time zone


will happen in two weeks on Wednesday again.


And next week on Wednesday, I'll do a more APAC-friendly one


in a different time zone, kind of, basically.


So if you are basically getting up very, very early


or staying up very, very late for this office hours,


there will be a better suited version for you next week


as well.


Thank you so much.


Keep submitting questions on the YouTube things


for the upcoming office hours.


And thanks for hanging out with me.


And have a fantastic day.


Stay safe and stay healthy.


Bye-bye.


Google Site ownership verification - Google Search Console Training

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


to verify your classic Google site in Search Console.


In order to verify your classic Google site,


you must be logged into Search Console


with the same account used to manage your site.


Click Add Property, add your website URL


under the URL prefix option, and click Continue.


That's it.


Your Google site should be verified automatically


after this step.


If you have a new site or a site with a custom domain URL,


you will not be automatically verified.


If that's the case with your site,


you should use the Google Analytics method.


If you're not sure whether your site is classic or new,


check the link below in the site's Help Center.


Thank you for watching, and see you on YouTube.


English Google SEO office-hours from September 3, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


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


where people can join in and ask their questions around search.


And we can try to find some answers.


A bunch of questions were submitted already on YouTube,


so we can go through some of that.


But it looks like people are already raising their hands


here, so maybe we can start with some live questions again.


Cool, let's see.


Andrew, I think you're on top.


Yeah, hello, John.


Hello, everyone.


Yes, I wanted to ask a question regarding the latest change


well, connected to generating titles.


Is it safe to think that Google still


rely on initial titles when changed for ranking?


Yes, yes.


At least that's the way it is at the moment.


So you never know how these things evolve over time.


But at least at the moment, it is the case


that we continue to use what you have in your title


element as something that we can use for ranking.


It's not like something that replaces everything


for the website, but it is a factor that we use in there.


Even if when we display the title for your page,


we swap out maybe that one keyword that you care about,


we would still use that for ranking.


So I think the one thing, the other question that I always


get around the titles is, should I


change my titles to be what Google has chosen?


Because obviously, Google knows better.


And the answer is no.


These are algorithms that are looking at things


and trying to figure things out.


But you know your site best.


You know your users best.


So I would not blindly follow what Google's algorithms


are doing.


Maybe there are cases where Google's algorithms


give you good ideas, and that's fantastic.


But I would not blindly follow that.


OK, thank you.


Cool.


OK.


Paul.


Hi.


I'm just asking about the link span update.


So we have a medical site which links to another site


to allow the customer to book the doctors, which


is on a separate domain.


How would you treat these links under the link span update?


Would you mark them as sponsored?


Or we own both domains, but they're different.


So how would you treat these with the link?


I would just use normal links.


I think that's a completely natural link between those two


sites.


That's kind of the functionality, if you will,


part of the website.


I would just use normal links for that.


So it wouldn't be seen as an affiliate link by Google


because it's going from one domain


to another with a UTM or something like that?


No.


No, that's perfectly fine.


OK.


Thank you.


Patrick.


Yeah, hi.


I have a question regarding website migration.


And currently, we are running a blog and larger websites.


Both are running on separate domains.


And we want to move the blog to the bigger website.


But since we don't want to change many things at once


and risk our rankings, we would first


adjust the current blog section and URL structure


on the website and then integrate all the articles


from the blog domain to the new website.


So is it better for the rankings to move all the blog content


at once to the new domain after all the changes are done?


Or should we maybe move only a few articles once a month?


Because my thought is that with the second approach,


we won't really see a big impact on the relaunch.


And yeah, so what's a better approach?


I think they can both be reasonable approaches.


So it's not something where I would say you need


to do it one way or the other.


In general, when it comes to website migrations,


when you're moving from one domain to another,


I think it makes sense to do it all at once if you can.


But when you're merging or splitting websites,


then that kind of all-at-once advice, I don't think,


really applies.


So especially when you're merging things together,


when you're combining different websites,


then doing that incrementally is perfectly fine.


Doing that all at once is perfectly fine.


There is no penalty, if you will, for moving too fast.


It's really more a matter of how you can organize this


on your side and how you can handle that migration.


OK, thank you.


I think always these merging and splitting of websites,


it's always a bit tricky because it's hard to guess


what the final outcome will be.


But yeah, good luck.


Hope it goes well.


Thanks.


Cool.


Clive.


Yes, hi, John.


We've got a Google News listed sports website.


And we'd like to know what we can do to have our newsreels


listed in the Google carousel.


I don't have a lot of insight into the Google News side.


So I can't give you that kind of like one simple answer.


We did do a blog post, I think maybe two months back or so,


about Google News and kind of the whole inclusion process.


I would double check that.


One of the things that has changed over the years


is that it's moved much more to kind of an out of the box


moved much more to kind of an algorithmic inclusion process


rather than to manual one.


So in the early years, it was like you


would kind of apply to get into Google News.


And then you were accepted into Google News.


And you were shown everywhere.


And nowadays, it's more that you apply


to get into the Google News Publisher Center.


But that doesn't mean that you're automatically


shown everywhere.


So kind of that step, that next step


is something where you kind of have


to convince the algorithms that you're actually


a fantastic news site.


But there's a bit more about that in the blog post.


AUDIENCE MEMBER 1


Giuseppe.


Oh, we can't hear you.


I don't think you're muted.


It's just no sound.


Oh, no.


Otherwise, I'll go to the next one and come back to you.


Maybe there's a setting or something to kind of tweak.


Or otherwise, maybe drop the question into the chat,


and we can take a look at it there.


OK, Stanley.


Hello, John.


Hi.


Yeah, my question is specifically


around structured markups for recipes.


The reason why I'm asking this question


is because I'm seeing long-form articles, for instance,


listicles ranking for recipe carousels.


And because those pages have been marked up as recipes.


For instance, if you Google for things like easy lunch ideas,


easy dinner ideas, you will see listicles being ranked


under recipe carousels.


So I was wondering if it's websites trying


to game the system or if it's a bug by Google or something


along those lines.


I think it's something along those lines.


So I saw your question in the YouTube questions as well.


Oh, we can hear Giuseppe.


OK, we'll go back to you in just a second.


And I took a look at some of those results,


and that seems like something that we shouldn't


be showing rich results for.


So in particular, in the rich results guidelines,


we do have that it should be just one item on the page.


And it shouldn't be like a list of recipes for you


to use the recipe markup.


So on the one hand, that's something


where I think we could potentially take manual action


with the Web Spam team on that when we take manual action


on rich results.


Usually that means we would just not show the rich results


for those sites.


But because at least the examples that you gave there


seem like something where there are just a lot of websites that


are doing this, I think the smarter approach would


be on our side to see if we can algorithmically recognize this


and kind of just not show those rich results


for those kind of pages.


So instead of manually trying to chase everyone down,


find a way to do that in a more scalable way.


Thank you.


That was actually my follow-up question.


Cool.


OK.


Yeah, I think it's always awkward to see


these kind of examples where when you look at our guidelines


and you look at the results, it's like, oh, this doesn't really


match, and especially when there are a lot of sites like this.


But this is the kind of feedback that


is very useful for the folks that work on the algorithms.


Giuseppe, back to you.


Now it's fine?


Perfect.


Yeah.


Thanks.


So a question about mobile-friendly criteria


in the Google Search Console.


And we have information sites with, let's say,


about 1,400 pages now about product specification, reviews,


and so on.


And the first strange thing is that only the 20%


of these pages are listed in the valid mobile usability list.


Even if the structure of the pages


are more or less the same because the structure


is the same, of course, it changes the product


to be described and then the review.


So this is very strange.


But even more strange, since 10 days ago,


I saw a major drop, about 40% in the number of the URL


that are listed as mobile valid and without any site


restructure.


So what I did, I took the list of 10 days ago


and took the list yesterday.


I compared the list.


The list from yesterday is much, much shorter.


And I picked up some URL that are no more appearing as valid.


So they were valid 10 days ago.


They are no more valid.


And I used the search check URL tool in the Search Console.


And the search tool says they are mobile optimized.


So they are fine.


And so what's happening?


What to look at?


Thanks.


Yeah, I agree this is kind of confusing.


What is happening there is in Search Console


for these kind of aggregate reports,


we show a sample of the URLs from your website.


And that's what we report on there.


And that doesn't mean that we ignore the other URLs


from your website or that they're bad in any way.


It doesn't mean that they're not mobile friendly.


It's just that we didn't check them.


So essentially, you can think of it a little bit


like you have 1,000 URLs on your website.


And we will double check 200 of them for mobile friendliness.


And that number 200, that can change over time.


So it can happen that maybe one time we only


check 100 URLs to see if they're mobile friendly.


That means the total mobile friendly count can go down.


But that doesn't mean that the number


of pages that are mobile friendly on your website


go down.


So in short, what you need to look for there


is more the number of errors and kind


of the proportion of normal pages to errors


that we report in Search Console for those reports.


So this is, I think, specific for mobile friendly,


for the different structured data reports,


also for the AMP report, and in a different way


for the Core Web Vitals as well.


So it's not a sign that these are not kind of well made


for mobile friendliness.


It's just that we didn't check them.


OK.


If I can just a very small addition,


because the only thing we were trying


to do in the last couple of weeks


is about using structured data markup about product.


But since this is an informative information site,


so with aggregational information,


I know that Google prescribes that to include the product


markup.


You need at least to include either a reviews


or aggregate rating or offers.


One of the three, at least.


Otherwise, the structured data is not valid.


But I know that about reviews, you cannot link,


put links to third party sites.


So the reviews must be on the current sites.


And the question is about offers.


I mean, is it allowed to include the links to other sellers,


like affiliate links, Amazon links,


or you have to sell the product in the specific site


to be valid?


Yeah.


I think it should be fine to include links


to other sources like that.


Because it's also something that sometimes sites


are just set up this way, that they're affiliate sites.


Sometimes they're set up in a way


that the shopping cart system is on a separate site.


So I mean, I haven't explicitly asked the team about this.


But from my point of view, that seems OK.


That seems unproblematic.


OK, thanks.


Sure.


Daniel.


Hey, John.


Just a couple of quick questions, actually.


First one, category pages.


Content at the top or the bottom of the page,


especially where you've got, say, quite a lot of products.


Having content at the top or the bottom page,


will it make a difference to ranking?


A little bit of content I think is always useful.


But it's not the case that you need


to turn it into kind of an article


about that kind of content.


So a little bit of content is useful in the sense


that we have a little bit more context of the articles


that you're listing there.


So that always makes a little bit of sense.


And that's something that we saw as being


problematic in the early days of mobile first indexing,


for example, where on desktop you


would have some context about kind of the type of products


that you have in a category page.


And on mobile, you often just have a list of products.


And in the early days of mobile first indexing,


that was a bit of an issue.


But I think that has settled down.


What I would try to avoid is making it


so that you have like a Wikipedia article


on the bottom of your pages.


And really, it's something where you can provide


a little bit of context, but you don't


need to rank for every keyword in the galaxy


with these kind of category pages


because I think it just dilutes the overall view


of those pages.


Because we try to find them, on the one hand,


for people looking for that category of products,


but also to find links to the individual products.


So it's kind of a little bit is good,


but overdoing it doesn't really make sense.


Because we've got different examples


where we'll have like a little bit of content


at the top of the page and the rest of the bottom,


or it's in a read more functionality.


And generally, in the past, if we've seen rankings drop,


then OK, well, maybe if we put the content


at the top of the page because they're


associating the relevance more now,


and they say going top to bottom.


So will it not make a difference then?


I mean, because from what you're saying in terms of conversion


rate, obviously, you don't want the content


to be putting all the products down.


But I think in terms of relevance,


would you associate more relevance


if the content was at the top or the bottom, do you think?


Top or bottom?


Without all these random products,


but there's loads of different products.


So you could have loads of different H1s and all that


should be pulled through.


I don't think there would be a big difference.


My hunch would be that probably having the context at the top


makes it a little bit easier for us to pick up.


And also, things like understanding the headings


and things like that with regards to a page


probably makes it a little bit easier.


But I don't know if there would be a measurable difference.


OK, cool.


My second question, obviously, with all the stuff


going over title tags now, are there


any instances where you wouldn't use a title


tag in the waiting, i.e.


if it's too long as an example?


I don't think so.


You just can use it every time.


Yeah, I mean, I think with titles,


you should see it a little bit like headings in the sense


that if everything is in the title tag,


then essentially the value of each individual item


is very small.


So it's kind of like you should focus a little bit about what


this page is really about and not just blindly stuff


keywords in there.


Because at some point, it'll be like the value of the title


tag is, I don't know, let's say two,


and you have 200 words in there, then the value of each word


So you kind of need to find that balance


and almost still treat them as something like, well,


if users see this, would it encourage


them to click through, or does it just look like you're just


throwing keywords out there?


Yeah, yeah.


Does it make any difference if you were to have, say,


the country you're targeting?


Obviously, if you're in the national SEO,


if you had the US in the title tag versus if you had the UK


in the title tag, would that be considered at all?


I don't think we would use that for geotargeting.


OK, that's actually really good to know.


Cool.


That was it.


Thank you very much.


Appreciate it.


All right.


Polina.


Hi, John.


Hi, everyone.


So I posted a couple of questions on the community tab


already.


So first question is a quick one.


For Core Web Vitals data, does data from WebView pages


count towards it?


I don't know.


I tried to look it up, but I couldn't find anything there.


There's some criteria for Core Web Vitals.


So basically, you would need to look up the Chrome User


Experience Report data.


And on web.dev, they have some documentation


on what the requirements are for that data to be collected.


I don't know if the WebView would count into that.


What I would do is try to pull out that article


and just ping the author of the article on Twitter


and ask them directly.


OK, great.


Thanks.


So you also wouldn't know if WebView performance


is included as a ranking factor for page experience signals,


right?


I mean, if it's included in the Chrome User Experience Report,


then it would be included.


But that's something where I don't


know if that's taken into account for the Chrome User


Experience Report data because we really


need to be sure that people are opting in to giving this data


to Google.


And I don't know if with WebView,


there's this notion of even opting in or being


able to opt in.


Right, thank you.


And another question is maybe something a bit too complicated


for you to give me much help, but I'd like some ideas.


So basically, we have a huge problem


on one of our e-commerce websites we look at.


On listing pages, the JavaScript that's


responsible for loading all the listing products,


Googlebot cannot access it, cannot render it, apparently


according to Mobile Friendly Test Tool and Search Console.


So we get zero products.


Robots.txt doesn't block it.


We check server logs.


They say that Googlebot isn't blocked,


and it can access the resources.


Other parts of the page are absolutely fine.


Other JavaScript on the website's fine.


Another absolutely identical website


we have, which is in a different country, it's also fine.


It doesn't have this issue.


And the issue just resolved itself for one month


when developers didn't change anything,


and the server folks also didn't change anything.


So we have no idea what's happening,


and I don't really know where else to look.


So if you have any ideas.


Is this something that you only see in the testing tools,


or is it something that you also see in the search results?


SPEAKER 2


We see these pages being seen as duplicate, for example,


or we see less indexing that we expect.


So I think it's actually not rendered correctly.


And I think one way you could do that potentially


is to do a site query for those specific pages and some


of the keywords that are only added with JavaScript.


Just to kind of double check the assumption


that it's really not being taken into account by Google,


because especially with the testing tools that we have,


we set them up in a way that they have much stricter


deadlines with regards to how quickly a server should


respond, because we want to give you a result as quickly


as possible.


And when it comes to search, we don't


have those kind of deadlines, because we can say,


well, we will just kind of take time to cache these scripts


and then execute them separately.


We don't have to do it all within a couple of seconds.


So it can certainly happen that a testing tool


will say it didn't work, but actually in search it did work.


So I kind of watch out for that.


But usually also when this happens,


it can be a sign that things are kind of on the edge,


in the sense that sometimes it works


and sometimes it doesn't work.


And that, I think, is still something


worth trying to figure out.


What I would do, especially if this is a JavaScript site,


I would join one of Martin's sessions.


He does Office Hours specifically


for JavaScript-based websites, and maybe submit


one of those URLs to his question and answers ahead


of time so that he can take a look


and get his input on that.


Because it might be that there's something small


that you can do to improve the whole process there.


It might be that when he looks at it, he says,


oh, it's a non-issue.


It's the testing tool that is confusing you.


But that's kind of the direction I would take there.


So I would first check if it's really a critical issue,


and then also check in with Martin


to see if it's maybe something on the edge,


where sometimes it works, sometimes it doesn't work.


SPEAKER 2 OK, thank you.


So just quickly to check, because we


did see when the issue self-resolved itself,


the indexes went up.


And then when it went back, they dropped.


So assuming the issue exists, what do you think is,


what are some of the big reasons when Google cannot access


JavaScript aside from being blocked with robots.txt


or being blocked by servers?


Yeah, so I think probably what happens the most there


is that it's more of a general rendering speed


issue in the sense that maybe you have something set up


that the JavaScript or the API responses


are created in the way that they almost have session


IDs associated with them so that we can't cache them properly.


Or anything where essentially you're rendering the page


takes a significant amount of resources extra.


So what I've done in the past when


looking in these kind of issues is to look at webpagetest.org


or in Chrome at the waterfall kind of diagram there to see,


is this a page that has a significant amount


of JavaScript and other content that needs to be loaded?


Or is it something where maybe there are just


like 50 requests in total?


And it's maybe a slightly different question then.


But at least in the cases I've looked at,


it is more something where there are almost


like hundreds or 200, 300, 400, 500 requests that


are required to render a page.


And when you have that many in place,


even if we cache a lot of those requests,


it can be a bit hit and miss if the timing works out


that we can actually complete all of those requests in time


for rendering.


Thank you very much.


That helps.


Cool.


All right.


Mustafa.


Hello, John.


Hi, everyone.


Wait a second.


I think someone else was in between,


but somehow they dropped out.


I think we let you go travel?


Yeah.


Yeah, yeah, exactly.


Thank you.


OK, sorry.


Sorry.


I'll get back to you, Mustafa.


OK.


No problem.


Good morning, John.


We have just one question regarding to the titles.


We built up a strategy for the meta title,


and some weeks ago, it could change.


It has already been known.


But the main issue is for us that only our brand name


was changed.


So nothing changed, only our brand name.


It was appeared uppercase in the last time,


but now it was replaced by domain.


And my question is, is it possible to ask


for the change of it, or we should accept it?


I would submit it to the Help Forum thread.


I think you already did.


Is it possible?


I thought I saw it there as well.


But anyway, in the Help Forum, we


have a thread with feedback for these kind of issues.


And the team that is working on titles


is actively monitoring that and trying


to figure out what kind of bigger issues there are.


So they wouldn't be able to go in and say,


for individual websites, we will change the titles


based on the feedback.


But they do try to recognize the general type of problem


and then try to fix that algorithmically.


So my understanding is that what will probably happen


is we'll have a number of smaller updates


in these algorithms over time.


I don't know how quickly, maybe in the next couple of weeks.


And things will get better.


And we'll see kind of how things settle down.


And it might be that this already fixes the issue


that you're seeing.


But if not, then feel free to make sure


that it's known to us.


OK, thank you.


Thanks.


Cool.


OK, and Mustafa.


Hi, everyone, again.


I'd like to ask you, Jean, please, about a manual action


that we received that is a bit confusing.


The description says, job posting markup


used on expired job without the valid through-property set


in the past.


So basically, it says that the job post is expired.


However, our structured data says that it's still valid.


The issue is when I check the job post,


it's a user-generated content.


So when I checked the job post, I


found that it's not expired.


It's relatively new.


And there's nothing on the page indicates that it's expired.


So I don't want to respond to it in a defensive way,


that, hey, guys, there's some human error or something.


But I'd like to do it the correct way.


So what do you think that I should do?


I would double check to see if you can find maybe a bigger


pattern there.


Because usually, with manual actions,


we give some example URLs when we can.


But we only do the manual action when


we think that this is something that is more


widespread across the website.


So the URLs that we give usually are more examples and not


a complete list of the problem.


So I mean, it's something where you can definitely


respond to the manual action and say, I think you got it wrong.


Because if it's a manual action, sometimes maybe we


do get it wrong.


But I would also check if there is a way


to check across your website to see if, I don't know,


this expired job listing issue is


something that is maybe a potential issue


on other listings as well.


Just to double check that it's really not just this one page


that is kind of like a problem, but rather


that there is actually no broader issue on your website.


AUDIENCE 1 Yeah.


What I say that it's most likely only against that single page


because the traffic that comes organically from Google


is rising.


As a matter of fact, yesterday, we


received the highest number of clicks


ever from Google organic.


So I guess that that's something related to the page itself.


But it's good note.


Yeah.


Again, look at it.


To be honest, user-generated content


is really difficult to control.


I think some manual checks from our site should be applied.


OK.


We'll see this.


But you think, in general, it's OK to say


that maybe you got it wrong?


JOHN MUELLER I mean, it happens.


I would first check your website to make sure.


Because this back and forth, if they come back and say,


oh, no, we double checked, and it's actually a bigger problem.


Then you're just kind of like deferring


the time that you need.


But when you double check, you see, oh, it actually looks OK.


Or maybe there is something confusing on your pages


where you can tell them it's like maybe you were confused


or maybe users are confused.


That's also something that might be useful feedback


for the manual action folks.


AUDIENCE I see.


So suppose that some manual action comes in relation


to some spammy content.


That's what we fear always.


Because it's a user-generated content.


Would it be acceptable to say that, yeah, it


was a spammy content, for example, posted by the user.


We're going to apply some checks ourselves.


But that doesn't guarantee 100%.


Yeah.


I think that's perfectly fine.


With user-generated content, it's


always a bit tricky.


But if you can explain to the manual action team


that you took action on the examples they gave,


you improved your processes to make sure


that it doesn't happen in the future, that's


kind of what they're looking for.


Sure.


Yeah, but there's still a slight chance


that something might happen in the future.


No.


I mean, it's always something where


with user-generated content, you can improve your processes.


But you never know what they will do next.


So the team would understand that it's a bit tricky.


Right, OK.


That's clear.


Thank you very much.


Cool.


OK.


And I have been avoiding the submitted questions.


So if you submitted something, sorry.


I'll go through some of these now.


And we can do more live questions later on,


or maybe after the recording stops as well.


Let's see.


Search Console shows a page on a specific position


in the search results, when I look it up,


it doesn't show on that position.


So this is something that is super common.


And it's sometimes a bit confusing,


especially in the beginning when you see that.


But the data in Search Console is


based on what users actually see in the search results.


So it's not a theoretical number for the position.


It's what was actually seen.


And that means that if when you check those pages


and you see something different, then maybe users just


saw something different than what you saw.


So sometimes what happens is we show an image from a page,


and then we show the position very high in Search Console.


And when you look at it, maybe you


don't notice that this image is from your website,


or maybe you don't see any images in the search results.


So that can be a difference there.


But also, with different countries,


there are slightly different rankings.


With different language settings,


With different device type, there


can be different rankings.


There are lots of things that kind of play into the rankings.


And a lot of that just means that you can't always


confirm one to one exactly what is shown in Search Console.


Usually, if I see something really weird, what I do


is try to drill down in very specific settings in Search


Console to see, oh, from this country, this language,


this kind of search, this kind of device, they saw this thing.


And then I can try to reproduce that.


But it's still not always 100% sure.


And these things also change over time.


So it can happen, but you see something


in Search Console that happened yesterday or the day before.


And when you look at it, it's different


because it has changed.


So there is not much that we can do to say,


it should always be the same.


But rather, it's just, well, that's how we recorded it.


And when you look at it, it might be different.


SPEAKER 2


Can I just ask, sorry, on that, with impressions,


if it's just something you do, does the user physically


have to see the URL for that impression to get counted?


Or does a page just have to load with you there?


It has to load with it there.


Yeah, but the user doesn't necessarily


see it as an impression.


Yeah, so if it's on the bottom of the search results page,


that would still count.


The one place where it's slightly different


is when there's a carousel of results,


such as with the top stories or with, I think, images.


I don't know.


If it's kind of off to the side for the carousel,