that stops rendering until it hits the viewport.


JavaScript SEO office hours November 25th, 2020

Is there any implications from Google's bot side


using this at all?


I don't think that is any problem with it.


I haven't tested it yet.


That's a really good question.


I love it when you're in these Hangouts


because you always ask questions.


I'm like, oh, I should actually definitely test this.


I expect this to work out of the box


as we are upgrading the Chromium renderer,


and it should fall back reasonably.


But I definitely recommend testing this out


and making your own conclusions until I have had a look,


and probably we have some guidance on this.


If you don't see any guidance coming up


in the next couple of months, that just


means it works out of the box and doesn't


need any specific things.


And to be honest, if it doesn't work,


then that's a problem on our side


that we will need to fix sooner rather than later.


Very good question.


Thank you.


Thank you for the answer.


Very happy.


I know that I haven't tested it.


It's not the greatest answer ever,


but there's so many things that I need to test.


More hours in a day, that's what we need.


Definitely.


All right.


Anyone else having a question?


Now is the opportunity.


You can, again, also use the chat


if you'd rather not pipe up.


Let me refresh the YouTube site because sometimes people


are posting to YouTube a little late.


No, it doesn't look like it.


Newest first.


Yeah, this is a really unfortunate thing


that you have to actually say sort by newest first


to actually see all the comments.


Any questions?


Yes, hi Martin.


Hi.


Awesome.


I have a question about Core Web Vitals, particularly


the fact that the APIs, as far as we know,


are currently not supported on Firefox and Safari.


Well, they're only supported by the Blink-based browsers.


So my question is, do you have any recommendations


if you're looking to test and optimize websites,


particularly for those browsers?


Are there any particular metrics that you


would use to replace Largest Contentful Paint?


Like, what are the ones, if you had to come up with that?


Let's say workflow.


Are there any particular metrics that you'd use,


and how would you go over this problem?


I'm not sure about Safari's DevTools,


but I know that the Firefox has great developer tools,


but they don't really have anything


that allows you to gather real user metrics.


So you would have to fall back to gathering field data.


That's not field data.


Lab data, sorry.


So if you don't get any field data,


then lab data is not perfect, but it is better


than having no data whatsoever.


So I would definitely just dive into the developer tools


and do the performance audits with the developer tools


that you have there, and probably


also try to find some users or someone in your team who


happens to have devices that are not top-of-the-line devices


to actually run the performance profiling there as well.


But that's the best you can do.


I do hope that the proposed APIs are landing in other browsers


as well, because I think having more field data is just


generally useful.


But if you can't, then at least use some lab data.


I see.


Thanks.


Sorry for not having a good answer.


This is like every browser is figuring out this performance


thing so far.


So it takes a while for everyone to come up


with ways of gathering information.


Also, I think Firefox might have a philosophical stance


on the point of gathering field data.


Can't speak for Mozilla, though.


All right.


More questions?


Five comments.


If there's no one, maybe just a follow-up question.


Then what would be like, I'm not sure


if you're the right person to ask,


because I don't know how much invested you are in web


performance, actually, but let's say you cannot use Largest


Contentful Paint.


What would be your other, let's say, favorite or maybe not


favorite but most useful metrics for measuring render


performance?


Do you have any thoughts on that?


Yeah, I do.


Actually, I am relatively invested in web performance.


And I used to be very, very invested


having worked for a startup that does VR on the web


for architectural applications.


If I can't do that, I would look into frame timings.


I would try my best to see if we can basically


hit 60 frames per second as quickly as possible,


because that's a good approximation for A,


does something hog up the GPU?


And B, does something hog up the main thread?


Because if something is blocking the main thread,


then that usually results in frame drops quite quickly.


OK, cool.


Thanks.


You're welcome.


Also, frame timings are relatively, well,


relatively easy to measure.


I'm saying relatively to other things like Largest Contentful


Paint is really tricky to measure yourself


unless you have the APIs that give you this information.


Whereas frame timings, you can measure that


within a request animation frame loop


and then measuring the times.


It's still not easy.


It's still not easy to get accurate frame timings,


but it's easier than the other options, I think.


All right.


Any?


Ah, OK.


Here's a question from Muhammad in the chat.


How long a bot can wait for rendering a JavaScript code?


I'm guessing JV code is JavaScript.


Well, I don't like that this question gets asked,


because it's telling me someone is bargaining with a bot,


and that's a bad idea.


As quickly as possible, do it as quickly as possible.


We do wait quite a bit, but users don't.


So even if for the bot it is OK, users might not be so happy.


So try to get your JavaScript over the wire


as quickly as possible and get the content on screen


as quickly as possible.


If you are talking tens of seconds,


then you are already having a problem.


I know that some websites take minutes,


and they are still indexing fine,


but they're definitely not making users happy.


So all right.


Any more questions?


Seeing that we have nine people here.


Well, that's eight of me, right?


Now is your opportunity.


Don't be shy.


And again, if you are shy, that's perfectly fine.


You can also use the chat, asking questions in the chat.


It's perfectly acceptable.


Quiet.


OK, in that case, let me ask a question.


If you are here in these JavaScript SEO office hours,


what brought you here?


What is a thing that you are concerned about?


What is a thing that you have experienced


that didn't go so well?


What kind of JavaScript frameworks


have you been working with?


Feel free to put it in the chat or just talk.


That's also perfectly fine.


Quiet group today, huh?


Also, I'm trying not to butcher names,


but I'm really not sure how to pronounce.


Is it a Polish name?


Yes, it's a Polish one.


Is it Zimowit?


Zimowit.


Zimowit, ha.


I wasn't too bad.


I was super afraid to answer your question


and start with a name that is pronounced incorrectly.


And I'm really sorry that I was a little scared


about screwing it up.


So Zimowit.


That's correct.


And I completely understand.


It's rare even for Poland, so I'm used to it.


Interesting.


I'm super sorry again.


I'm super happy that you're here,


and I'm really happy to learn.


You know what?


I'll see if I can pronounce people's names.


So Carolyn is probably correct.


Dave Henning.


Henning, you from Germany or Austria or Switzerland?


Sounds like a very German name.


Yes, from Germany.


Hamburg.


Yeah, but I live in Barcelona.


Oh, wow.


OK.


That's really nice.


That's lovely.


Yes.


Yeah.


But I mean, Hamburg is nice too.


It's just a little more cold, I guess.


Gray.


Gray as well.


Gray is probably also a problem.


That's true.


Exactly.


Cool.


Barcelona.


Coming from Hamburg to Barcelona,


that must have been an interesting change


of pace and scenery.


My wife come from here.


The years we spent so much time here before we changed.


So nothing new for me.


Right, it wasn't like a drastic change.


OK, I get that.


No, not there.


Then I think we have Muhammad.


Muhammad.


I'm never sure which way to pronounce these.


Seville?


Tamas?


Thomas?


Tomek, come on.


Let me tell you.


Tomek.


And Tamas is right?


Yeah, he was.


Yeah.


From Hungary.


It's the official name, but everybody calls me Thomas.


So we have Thomas from Poland, and then we


have Tamas from Hungary.


Nice.


Exactly.


That's really cool.


Unknown, I think, is Simon, but I'm not sure.


And then we have Zimowit.


OK.


And then we actually have a comment


from Carolyn in the chat.


I used to work for a company who used AJAX JavaScript


to create product pages.


It is commonly discussed in the SEO world


that AJAX is not ideal for SEO.


We also have seen pages got not indexed properly,


but what do you think?


And is AJAX really not ideal for SEO?


Well, that's a really good question, Carolyn.


Thank you very much for sharing this with us.


So what AJAX really means is it's actually


a bit of an anachronism, or anachronism, I think,


is the English word.


Anachronism is a very German way of thinking about it.


Anyway, it's like, OK, so when we


used to build websites in the olden days, what would happen


is you make a request to the server, you get the website,


and then that's it.


That's the entire interaction that happens.


And then at some point, we're like,


but it would be cool to kind of get data back to the server,


like if I want a contact form or guest book, right, or comments.


So the way that worked is basically


you go to the website, the server response with the HTML,


and then some form in the HTML.


And then you would fill that in, click Submit.


That would submit it to the server.


The server would send back a new website, pretty much.


That's how that worked, which means


you have this page refresh in the middle.


So you have this flash of white in the middle


when the server gets the data from you


and before it has given you the response back,


like, thanks for your contact request,


or here's the new website, the new article with the new guest


book, not guest book, guest book comment that you just


wrote in it.


And then we came up with this idea of, like, hey, hold on.


Couldn't we, instead of basically


refreshing the entire website, couldn't we


just use JavaScript to send?


So you have this form.


You have this form where you can type in your comment


under a blog post, for instance.


And you hit Submit.


And instead of actually refreshing the entire website,


JavaScript makes the request in the background,


and then the server responds back.


And then we can reload the page.


Or even better, we can basically just change the page,


because we have all the page.


So we can add new stuff using JavaScript.


And that's where AJAX comes from.


AJAX stands for Asynchronous JavaScript and XML.


So originally, you would make an asynchronous,


which means in the background, kind of.


Asynchronous means a little different.


But for the sake of this explanation,


in the background is good enough.


So in the background, JavaScript makes a request


and gets XML back.


And then from that XML, you would create the HTML


that you need.


And then there were variations of it.


So AJ, as in A-J-A-H, would be basically


asynchronous JavaScript and HTML.


So the response back to that JavaScript request


would be HTML.


And then you can just plug that HTML straight into the page.


And then there was AJ, I guess you would pronounce it,


A-J-A-J, which is asynchronous JavaScript and JSON,


JSON just being a different representation.


So XML, HTML, and JSON are just structured ways


of sending data.


If you look at an HTML document, it's structured information.


It's like, this is the body.


This is the title.


This is the headline.


This is the sub-headline.


This is the link.


This is a button, and so on and so forth.


It's just structured information.


You can use other things, like XML


is a more flexible way of structuring information.


And JavaScript Object Notation, or JSON in short,


is another way of structuring data.


And is this bad for SEO?


Yes and no.


It made life harder for search engines,


because no longer we can just make a request to the server


and get the website, because now some content might


be loaded with JavaScript.


So you make a request, get a pretty much empty website back,


and then JavaScript does these AJAX requests


to actually fetch more data and put it into the website.


But since a couple of years, Google


has been at least very capable in terms


of running JavaScript, so the AJAX requests themselves


are not really a problem.


But there are additional complexity,


and complexity is usually a thing


that you want to minimize as much as you can.


You cannot really avoid it, but you can minimize it.


And the reason why I'm saying is that there


are more ways of things going wrong, more ways for things


to go wrong.


For instance, what if this JavaScript request


that fetches data to show on the website is roboted?


If for some reason your JavaScript makes


a request to slash API slash cats


to get a list of cats to show on the website,


and then robots.txt slash API is disallowed.


It works in the browser, because the browser doesn't really


care for robots.txt, but it doesn't work in Google search,


because we do care for the robots.txt.


And then we are basically seeing this empty website.


We are running the JavaScript.


The JavaScript is like, can you fetch me a slash API slash cats?


And then the robots.txt says, no, you cannot.


And then we're like, whoops.


It's harder to test these things.


It's harder to fix these things.


So it isn't fantastic for SEO, but it's not really


a problem either, because once you implement it properly,


it's fine.


It's not a problem.


Yet I would say it's additional complexity


that you don't necessarily need, unless you have a good reason.


Thank you very much for explaining it that well.


It's really good.


Thank you.


You're welcome.


Trying my best here.


Momet is asking, does it affect the rest of the content


if some JavaScript code is blocking


rendering some part of the content on the page?


Yeah.


So if you have a piece of JavaScript


that doesn't finish forever, it basically is stuck.


We would run through the page.


We would run that JavaScript and then get stuck.


And eventually, it would stop rendering, because it's like,


OK, this gets stuck.


So we have to try again later.


And in that case, we don't see the content


that this JavaScript would fetch.


We don't see the content that would be in the HTML


after the blocking JavaScript either,


because the processing would be stuck at that point.


So that is a potential problem in terms of indexing.


All right.


Do we have more questions now that we all


got to know each other a little bit and got the ball rolling?


And again, feel free to use the chat


if you don't want to speak up.


Oh, Henning is asking, is there a problem


with pre-rendered pages for the Googlebot with prerender.io?


Sometimes these pages are not up to date anymore.


And therefore, the resources, so like JavaScript and CSS,


are no longer accessible, because the hash


and the file name has changed.


Can this influence the indexing, or does it only


refer to index and influence rendering?


Well, so what prerender.io does is basically dynamic rendering.


And it is tricky.


So the reason why prerendering is a tricky thing,


and when I say prerendering, I don't


mean the actual prerendering.


OK, let me run back.


So there's a bunch of different ways of doing things, right?


One way is, let's say you have a blog.


This blog only ever changes if you update a blog post


or create a new one or remove an old one.


So you know exactly when it changes.


If you are using some JavaScript,


you could basically run this on your machine


and make it generate all the HTML


and then only upload the HTML, because this HTML only changes


when you make a change.


That actually is prerendering, or what's


usually named prerendering in developer circles.


Then there is client-side rendering,


where you have a bunch of templates in HTML,


and then you have some JavaScript that catches data


from APIs or backends or CMSs or whatever.


It doesn't really matter.


The JavaScript in the browser grabs the additional content


and puts it in the HTML.


That's client-side rendering.


And then you could do server-side rendering,


which you can do with JavaScript, with Python,


with Perl, with PHP, with Java, with ASP.NET, with Golang,


with Rust.


I don't know.


Basically, that works by sending some requests,


then some program runs, and that could be a JavaScript program


generating the HTML, and then you send the HTML back.


That also works.


And then there's what we call dynamic rendering


that you normally only do for bots


with things like Rendertron or prerender.io


or any of the other providers out there.


And what that does is basically a request


comes to the prerendering service from Googlebot


or from users, if you configure it that way.


It comes to one of the prerendering services.


The prerendering services open a browser on the server.


That then makes a request to the actual server.


It then gets the response back, runs all the JavaScript,


waits until there's HTML in the browser,


and then takes that HTML snapshot and sends it over.


Do you see a problem here?


You should, because opening a browser on the server,


opening the page in that browser,


waiting for that page to load, that takes time.


So these requests are usually a lot slower.


And I don't know.


Have you ever seen a browser crash?


I did.


Just this morning, a browser crashed on me.


On my phone a few days ago, my browser crashed on my laptop.


Browsers can crash.


So what happens then?


Well, then we have to catch that crash.


Then we have to reopen the browser.


It takes even longer.


If our code here in the prerender solution isn't great,


then maybe it doesn't notice that the browser crashed,


sends back empty HTML.


So it invites a whole new load of problems.


And it takes a long time.


So because it's taking so long, oftentimes you would instead


basically cache these things.


So you would say, oh, we don't always open it in a browser.


We open it once and then cache the HTML


that we get for a day, for an hour, for five minutes,


because that's usually good enough.


Sometimes these caching decisions


are not great, because you might cache too long,


or you might not cache long enough,


and then things get slow again.


So prerendering isn't the silver bullet


that magically makes all the problems disappear.


If this happens and it tries to access resources


that it doesn't have anymore, with a CSS,


it's probably fine, because the web will succeed nonetheless.


It should be fine.


The content should still be there.


It might look weird, but it doesn't really


matter that much.


If the JavaScript resources fail and the JavaScript


is what actually fetches the content,


then the rendered HTML by the prerender solution


might miss the content.


And if it misses the content, then the indexing


won't see it.


So it's not just the render issue.


If content is missing in rendering or after rendering,


then indexing can't index it either.


So that can immediately become or escalate


into an indexing issue for you, which


is why I would keep the old assets around for a while


to make sure that you're not running into these problems.


I don't know how long prerender.io caches things,


but yeah, I would keep the old versions around.


Also, I see that Tomik has raised his hand.


Tomik, what can I do for you?


TOMIK MALHOTRA KALSIU-MARTIN GILBERT-STUDENT 1


Hello, everyone.


I have a question for you, Martin.


What kind of analysis do you run on initial HTML?


MARTIN SPLITTENBERG What kind of analysis do we run on initial


HTML?


Pretty much anything that we also run on.


Well, that's not true.


We run a few things on the initial HTML.


One thing is it's early link extraction.


So once we have HTML, we can immediately


have a look if this looks like a link or if it looks it.


But if it has something in it that looks like links,


because then we can immediately queue them for the scheduler.


We obviously do that again once we have rendered,


because usually that produces more links that we


need to queue for crawling.


So but that's something that we do on the initial HTML.


We also, I think, try to understand


if this is an error or not.


So if it comes back with a 404, it's not really the HTML.


But if the initial crawl comes back with a 404,


then we treat it as such.


So you can't really use a 404 page to run JavaScript


to load some content.


I've tried that in the past.


It got everything de-indexed.


Not a good strategy, really not a good strategy.


We also look for meta tags.


So if there are canonicals in there,


if there's a meta description in there,


or if there is a meta robots in there,


we definitely do look at those, which


also means that if you say no index in the meta


robots in the initial HTML, and then the JavaScript runs,


you have a problem.


Because when the initial HTML contains a meta no index,


we're like, oh, this page doesn't want to be indexed.


So we don't need to render this, because you already told us


you don't want this to be indexed.


So be very, really careful with that.


I think we also try to do canonicalization at this point,


or at least D-dub management, which sometimes does not


give us clear signals.


And in that case, we might ignore


the initial canonical tag.


We might ignore the initial, basically, content hashing


that we do on the initial HTML if the content hash differs


in the rendered HTML.


So canonicalization, being a longer running process,


starts in the initial HTML, but also


takes into account what happens in rendering.


What else do we do in the initial HTML?


Nothing that I can think of right now.


Let me actually see if I can.


Do I have the slides for this?


The Gary copy of the slides, but that works as well.


Let me see if I can, if I forgot something.


I wish we would make this public.


I keep pushing Gary to give a specific presentation


that he gives for new search Googlers,


because it has a lot of useful information in it.


But we don't really have everything in this shared yet.


We have everything in here, roughly.


But we don't have it in this specific format, which


I think is awesome.


And I hope that he makes a video one day.


What else do we do?


Content parsing.


Yeah, I know that we don't do that for the HTML.


But if it's like a PDF or something, we would parse that.


Yeah, we gather some signals already.


But we also then mix them with what we get from the rendering.


So most of it happens also after rendering again.


Does that help?


What about duplicate content detection,


regardless of canonicalization, et cetera?


Well, canonicalization and or dedupping are related, right?


So we basically, when we say canonicalization,


it really is a deduplication.


We first see all the pages that are similar enough.


And then we elect which of these is the canonical.


So it's kind of like it's related to each other.


We do that.


As I said, we do that on the initial HTML.


But we also do it in the rendered HTML.


So I don't think there is a chance


that we would kick out a page without having


it rendered first.


So we do get the hashes immediately.


But we compare them to what we get after rendering.


And usually in rendering, we get different hashes.


And then that's what we use continuously.


Unless we get the same hashes, and we're like, yeah, no,


this is actually an empty page.


Or this is actually a page that we already have in the index.


OK, thank you.


You're welcome.


Any more questions?


And again, feel free to both use the chat or just speak up.


Or actually, the Raise Hand feature is kind of cool.


Oh, Dave is raising his hand.


Hi.


Yeah, it's about when you're fetching stuff


from an API, et cetera.


I'm just like, if you do a get one,


does Google cache that the same as it would another resource?


It does.


Yeah.


But if you did a post, would it not cache that?


Then we would not cache it.


Yes, that's correct.


OK.


Just another one as well with calls and stuff.


I mean, it could be logging on my side or logging out.


But I've never seen preflight requests, an option request


come from Googlebot.


Or it doesn't seem that way.


And yet, you kind of expect that.


Does Google handle it in a different way?


Or is it just my logins not great?


That's an excellent question.


I think we do not follow the course protocol.


Because we are going through the,


we're kind of not really a user acting upon things.


But I'm not 100% sure.


That's a really good.


Ah, Dave, every time you ask a question,


you create work for me.


I love that.


That's fantastic.


I would love more questions like this.


Because I did a course test once,


but I can't remember what the outcome of it was.


Ah, man.


I need to find that out.


Thank you.


That's a really good question.


Good question.


Right, anyone else raising their hands?


No.


Any anyone else having questions in the chat?


Feel free to drop no questions.


Definitely do that.


Also really happy to see a good mixed bunch of people here.


And I think we have lots of different locations, right?


So we have Hungary.


We've seen Poland.


We have seen Germany.


No, hold on.


We don't have anyone from Germany.


Well, we have Switzerland.


That's me.


I think Simon is in the call as unknown.


And I think he's based in Germany.


What other countries do we have?


Barcelona?


So we have Spain involved as well.


UK.


But I'm from Germany.


Interesting.


Oh, where from Germany?


Stuttgart.


Not too far away.


So we have, well, UK.


Yeah, sure.


Dave is also from the UK.


Pakistan.


Wow.


Global office hours today.


Awesome.


Do we have more questions on YouTube?


No.


All right.


Hi, Martin.


Hi.


So I had one question regarding this fetching and finding


the content as duplicate.


In two-wave indexing system in initial HTML,


does it happen that in an initial HTML,


Google could not find out duplicate content,


hence it indexed the page?


Then after a final rendering and indexing,


it figures out that the page is duplicate, therefore


removes the page from indexing.


OK.


That's a very good question.


Niraj, is it?


Yeah.


Yay.


Niraj, thanks for the question.


Good question.


It's one of the questions that haunts me the most.


Not this specific question, but the two waves of indexing


has been a metaphor that has slightly gone wrong, I think,


because there's not really two waves of indexing.


We are pretty much processing the initial HTML


and then decide to render and then index.


So pretty much anything that gets indexed


has been rendered in the middle of it.


That's why I'm always a little conservative when people are


like, oh, this has been indexed without rendering.


Most pages actually, pretty much nearly 100% of the pages


get rendered before they get indexed.


Hypothetically, what you are describing


is possible if rendering continuously


failed for some reason, if there's some JavaScript that


got stuck, if there's some fundamental error.


And then it might be that the page starts flip-flopping.


It is also just possible that what you are seeing,


especially if you think that it's dropping off the index


and coming back into the index, sometimes what happens


is that there is a change in the canonicalization.


So as I said, we put all the pages


that we think are roughly duplicated into a cluster,


and then we choose which one we think should be the canonical.


And sometimes the only thing that happens


is we understand that this is a duplicate page,


and it's just like different canonicals are being chosen,


thanks to signals fluctuating.


That is normally not related to rendering.


That's normally related to other things,


because we are combining a bunch of signals


into the leader or canonical selection


within these duplication clusters.


But normally, no.


There is very few opportunities for a page


to be indexed without rendering.


So it's very, very unlikely that a page gets not seen


as duplicate before rendering and then seen


as duplicate after rendering, unless there's


something really funky going on.


OK.


And what happens if our content is coming from API,


and API gets failed, and Google retries,


and then only the content is appearing,


then only it will be able to?


Yeah.


That is a problem, because then we might be seeing,


depending on how it failed, we might just


not see the content that comes from the API


and then basically cluster up URLs that are not technically


the same, just because multiple URLs have


failures with the API.


That's why it's very important to make sure


that you have mechanisms in place


to make sure that your API doesn't fail.


And if your API is flaky, then that's


something that I would investigate.


OK, thank you.


You're welcome.


Pomek has raised his hand.


So when there is no index on that page,


do you take structured data into consideration or not?


I don't think we do, because if you think about it,


structured data is then used for rich results, mostly,


and some other additional semantic enrichment.


But it's basically if the information we have on the page


says, do not put me in the index,


then I guess we stop processing before we would


look at structured data as well.


What about link extraction in that case?


Because that was one story.


That is a good question.


I don't know, because these processes


should be running in parallel.


So I could imagine us to actually do


link extraction on a page that tells us no index,


and then only find out that it's no index after we already


started scheduling URLs for crawling,


and especially if the crawling has already happened,


then we can't uncrawl something.


If a request has been made, it hasn't been made.


But I guess you might see mixed signals here.


Sometimes we might discover the link.


Sometimes we might not.


And really, it's a case of if you don't want something


in the index, put a no index on it.


And if we discover the other links,


that's not a problem unless you also don't


want these things to be indexed.


If you don't want these things to be not indexed,


put a no index on them as well.


The clearer you can make the signals,


the easier it is for us to not do something


that we don't expect.


Make sense?


JONATHAN SCHAFFER-FENSELAAMEN.


MARTIN SPLITTENBERG.


Awesome.


Let's check the chat.


Yeah.


Henning, I said Catalonia.


I said Spain or actually Catalonia.


So I am aware that there is sensitivity in that area.


Anyone else with questions?


I mean, you may have overheard it because I said Spain.


And I was like, no, actually, Catalonia.


Someone asks for this link on Twitter.


So I'll be so nice and share the link on Twitter as well.


Because why wouldn't I?


There we go.


Maybe someone else joins us today.


If not, feel free to ask your questions either in the chat


or by speaking up or raising your hand.


That's actually it.


I keep forgetting that we have this feature now.


That's really nice.


I like that feature.


Ooh.


Holy moly.


I just, ooh, I'm not sure if these are.


So I'm enrolled for a computer science degree.


So I'm enrolled for experiments in Hangouts.


And now I need to find out if certain features are actually


available to everyone or just basically aren't testing.


And let me see.


Because I don't want to use a cool new feature


if I'm not sure that feature is actually public yet.


I don't want to accidentally leak things.


That would be awkward.


That would be so awkward.


Let me see.


Do I have these features here as well?


No, then again, I also don't have the Raise Hand feature


here.


Oh, god.


If only I knew if this is public or not.


Dang it.


Because I just saw a few nice features.


Actually, I can probably try to read.


Ah.


OK, ha ha.


OK, it's actually public.


I can start a poll.


Which JavaScript framework do you mainly


work with, question mark.


And then there's Angular, React, Vue, Other.


If this and I can launch this.


I don't know how it shows up for you,


but we now actually do have a poll, a vote


that you can vote with.


Oh, yeah, OK, so people are already, oh.


Oh.


Oh, wow, OK.


Aha.


Angular and React taking the lead.


React taking the lead.


That's what I expected, to be honest.


For those of you who selected Other,


what are you working with?


I selected Vue, but I do use Other probably a bit more now.


I use Svelte and Sapper a lot, particularly Svelte.


Yeah, someone just said Svelte in the chat as well.


So Svelte seems to be, should I do a livestream with Svelte?


Probably should.


That might be interesting.


JavaScript noob, that's fine.


Every one of us started at some point.


And if you watch the Twitch streams


that I do every now and then, you'll


see that even I struggle with syntax and stuff.


That's no shame in that.


It's cool.


Awesome that you are getting into Svelte, gmovit.


So that's pretty cool.


Hold on, what happens in the poll?


Angular and React leading.


Cool.


That's more or less what I expected.


Just quick question for the Angular people.


Would you consider your projects or companies more enterprise-y


or more startup-y?


Because I have a feeling, I have a suspicion


on which environments Angular is used more


and in which environments React is used more.


But maybe I'm wrong.


Or maybe I'm just biased.


I could run a separate poll for this.


But then again, eh.


How does this work?


OK.


Well, that doesn't seem so useful.


But the polls feature is quite interesting.


That's nice.


So we ran a poll.


I wonder how that comes out in the recording.


In case it doesn't come out in the recording,


I asked which JavaScript framework


people mainly work with.


I got eight responses.


And three people use Angular.


Three people use React.


One person uses Vue.


And one person uses Svelte, as we just found out.


Awesome.


In case anyone has a question, I think


we are running out of time.


But I will take one more question.


Yes, Asaf, I did cut my hair.


Thank you very much.


It is more useful when diving.


Long hair and cold air don't go well together.


So I'm pretty happy that I don't have


to deal with long hair in cold weather after diving anymore.


Even though I do miss the long hair a little bit,


it feels weird as well.


I can still color it.


But eh, might as well not.


I think colors come out nicer when you have a transition.


And for transition, you need a certain length.


I also still have some blue and blond bits in my hair.


And it looks a bit weird, I think.


But it'll disappear eventually.


It's fine.


All right.


Final countdown.


Five, four, questions, three, two, one.


OK.


Ladies and gents, it has been a huge pleasure


hosting the office hours.


The next office hours will be actually, I think, next week.


Is it next week?


Or is it in two weeks?


I confuse myself with how I schedule these these days.


No, it's in two weeks.


It will be in the later time zone as well.


It will be at 5 PM CET.


So it will be seven hours later than this one.


And then in four weeks, we'll be in this time slot again.


Has been a huge pleasure.


I'll upload the YouTube video as soon as I get the recording.


And I wish you all a fantastic day.


And for those of you who are watching this,


the YouTube recording, feel free to drop in your questions.


Go to our channel.


Go to the Community tab and watch for the next announcement


post for the SEO office hours.


Has been a huge pleasure having you all here,


answering all your lovely questions.


See you soon.


And I hope to see you all in the next upcoming Hangouts as well.


Bye.


Tools for publishers (and understanding their benefits) | Sustainable Monetized Websites

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


And in this video, I'll talk about…


Excuse me, sir, I think you're in the wrong series.


But I received a special invitation.


It's alright, Monetized.


Daniel is our special guest in this episode, in which we'll talk about tools for publishers


and…


Of course, we have to talk about Search Console.


We definitely do.


And before diving in, some introductions.


I'm Aurora and I work in Policy Education for Publishers at Google.


Daniel, meet Monetized and Organica.


As I was saying, in this episode, we'll talk about what tools can content creators


and content managers use to benefit their monetized websites.


And how to use them together to succeed on Search and the web in general.


For that, we'll need to roll our sleeves and get our hands dirty with data.


But nothing to be scared about.


Let me start by saying…


There are many Google tools you can use to monitor and optimize different aspects of


your website.


Knowing what each does and how to use them together will help you better understand your


site from the organic and the monetized angles alike.


Let's start with Search Console.


Daniel, I thought you had already said every possible thing about Search Console on your


Search Console training series.


I thought so too.


But as you can imagine, the team works really hard to continuously improve the product with


new capabilities.


And we can't forget the older reports too.


They've been around for so long for good reason.


As Brazilians say,


The gentleman means that old saucepans make the best food.


Don't look so surprised.


I know some Portuguese too.


Mr. Weisberg, would you be so kind as to discuss these new and old capabilities for publishers


to make the most out of Search Console?


Por su pueso, I'll start with the most helpful reports to publishers in general.


And then I'll focus on a report that will be particularly relevant to news publishers.


If you publish content on the web, you want to be sure Google can crawl, index, and serve


your pages to users.


Search Console will inform you of issues Google found in your website with regards to all


three of these processes.


Remember, you will have to verify your website ownership in Search Console to be able to


see the reports Daniel is going to tell you about.


Check the links in the description to learn all the ways to verify your website in Search


Console.


The best place to start is the Index Coverage Report.


Here you'll find information about all the pages Google has access to in your website.


By default, you'll see a list of errors that prevented your pages to be shown on search


results.


If you click a row in the table, you can find more details about the issue, sample URLs,


and the process to validate a fix you've implemented.


How about rich results?


I'm very interested in them.


Monetized.


Before you get any ideas, rich results are simply a way for websites to enhance their


search results appearances.


That's why we call them rich.


However, while they will not affect website monetization directly, they could actually


increase how often users click through to your pages, which would in turn increase your


organic traffic.


In order to take advantage of rich results, you'll need to implement structured data,


which is simply an HTML markup that provides Google with more information about your pages.


For example, if you publish recipes or how-to guides, you can implement structured data


to be eligible for rich results.


Check out the search gallery to learn what are the options available to you.


And how will I know if I implemented my structured data correctly on my site?


You'll find information about your implementation on the Search Console Rich Results Status


Report.


You can check the pages where Google recognized the markup and whether it found any structured


data issues.


Daniel, don't forget about the Search Performance Report.


I wasn't going to.


The Search Performance Report helps you monitor the trends on how your website is performing


on Google Search.


For example, you will find what queries people use to find your site, pages where they landed,


countries they accessed your content from, devices you used to access your site, and


rich results you've appeared on.


This report is very insightful for publishers to learn what is working and what is not when


it comes to bringing organic traffic to your website.


For example, if you don't find specific queries that you would expect, maybe you don't have


enough content about that topic.


If I remember correctly, you mentioned you had something in particular for news sites.


Are there any reports that can bring them specialized insights?


Apart from the ones I already mentioned, there is another report that will be especially


useful for news organizations, the Google News Performance Report.


It is similar to the Search Performance Report, but it provides data from the Google News


apps on Android and iOS, as well as the news.google.com website.


There's some interesting info in there, so make sure to check it out.


If you want to learn more about Search Console, check out Daniel's series on this channel.


On the monetized side, an essential tool is the AdSense Ad Manager and AdMob Policy Center.


It helps you identify and resolve issues that affect ad serving to your account, which could


include those involving your content, crawler access, or regulations, among other factors.


This tool will warn you if we detect that your pages, sections, sites, or apps have


policy or other issues that prevent you from fully monetizing them.


At a glance, you'll be able to see how many of them are affected by issues and what percentage


of your ad requests are disabled or restricted due to policy violations.


There are useful filters that will help you prioritize what issues to fix.


Among other parameters, you can arrange issues by ad serving status or impact numbers.


And if you prefer to organize data in your own way, you can download it as a CSV file.


If you monetize your content with Google AdSense, Ad Manager, or AdMob, you should have access


to the Policy Center through your account.


To learn more about this tool, check out the series Inside the Policy Center, linked in


the description.


If you're creating and monetizing content, Search Console and the Policy Center are really


useful tools to monitor the health of your website, but there are other Google tools


you can use on top of that.


Many publishers use Google Analytics, which provides valuable insights into how users


behave in websites.


To make things even more interesting, if you monetize your website with AdSense or Ad Manager,


you can link it to Google Analytics.


This will help you identify which traffic sources, countries, pages, and other segments


bring the highest value users to your website, enabling a data-driven approach to optimizing


your AdSense revenue.


Here are three things you can do right away.


Find which content type and topics generate the highest revenue and create content based


on this data.


Understand which page templates bring the best results and design your website based


on revenue metrics.


And analyze which users have the best CTR and revenue metrics to make sure you're targeting


the right audience.


We briefly talked about Google Trends in episode 2.


It gives you access to a sample of actual queries users search on Google.


The data shows search interest in topics from around the globe or down to city level.


Here are two ideas on how to use this data.


One, check top queries in your region and compare them to the queries you're getting


traffic from, the ones Daniel just mentioned.


If there are queries missing from your traffic, see if you have content on that subject.


Two, relate queries to topics you're interested in.


This may surface rising queries and help you prepare your site for them, for example, by


adding content related to it.


Try it out by visiting trends.google.com.


It's pretty fun and insightful.


SiteKit is another way of using Search Console.


Hmm, yes and no.


Actually, I just happen to have the SiteKit product manager Maria Mueva here.


Maria, is this the case?


Not quite, but nice try Daniel.


If you create your site with WordPress, SiteKit can help you gather insights about how people


find and use your site and how to improve and monetize your content.


It brings the best of Google products to WordPress like AdSense, Analytics, PageSpeed Insights,


Tag Manager, Optimize, and of course also Search Console.


And how does it do this?


First, it will ask you what your site goals are and then it will help you get there.


When you choose which Google products you want to connect, it will place the tags directly


on your site on your behalf.


So you don't need to know how to edit the code of your site.


Provides you with easy to understand metrics and actionable insights directly on your WordPress


dashboard.


If you create your site with WordPress and you have both Search Console and SiteKit,


you might be asking yourself like Daniel, why and when should I use these different


tools?


The main benefit of SiteKit is that it will give you an overview of how you're doing in


several tools at a glance.


It helps you connect existing Google product accounts or create new ones in a couple of


clicks so you can see the most important metrics from each tool directly in your site.


So if you're busy or you don't want to spend time on complex reports and multiple tools,


SiteKit could be a great solution to achieve your goals.


Thanks Maria.


Also, make sure you keep up to date with new tools and that you give them a try.


We hope this episode helped you better understand what tools are available to you when creating,


managing, and monetizing content.


And that you see the benefits of using them to monitor your site's health.


After all, the better data you have about your site, the more informed decisions you'll


be able to make.


Daniel, thanks so much for joining us in this episode and sharing your knowledge.


The next episode will cover penalties and the steps you need to take to resolve them.


Don't forget to like and share this video and subscribe to this channel so that you


don't miss anything.


Adieu!


How long does SEO take for new pages? #AskGooglebot

Hi, everyone, and welcome back to another episode of Ask


Googlebot.


I'm here from Google's Search Relations team


to answer your questions about Google Search.


Today's question comes from YouTube.


The user FileCoffee is asking, how long


does SEO take for new pages?


Answering this question is hard.


I'd love to just throw my hands up and declare, it depends,


and leave it at that.


But let's take a look.


I'll focus on two parts here, indexing


and how to speed things up.


First, however, two short disclaimers.


There is no guarantee that Google


will index any particular page.


In fact, most search engines don't


index a lot of the content on the web.


On the one hand, there's a lot of duplicate content


on the web that doesn't need to be indexed.


On the other hand, there's a lot of content


that is unlikely to ever be seen by users,


so it's not useful to index it.


The other disclaimer is that even when something is indexed,


it's not necessarily shown to users,


and it can drop out of the index over time.


So let's start from the top.


When a new page is published on a website,


it can take anywhere from several hours


to several weeks for it to be indexed.


In practice, I suspect most good content is picked up and indexed


within about a week.


Sometimes there are technical issues


on the web that make it take longer,


and sometimes it's just that our systems are


busy with other things.


There are a few things you can do to help speed this up.


Make sure that your server can handle


a reasonable number of requests in a timely way.


When your server slows down, search engines


tend to slow down as well.


Link to your new pages prominently


within your website.


The easier our systems can recognize


that you think this is an important page,


the easier it is for them to prioritize


crawling and indexing of it.


For example, if your website is for e-commerce,


it helps our systems to find links


to your new products on your home page


so that we don't have to crawl through several layers


of categories to find them.


Avoid filling your website with unnecessary URLs.


Whether it's an event calendar that


goes back to the dawn of civilization or shop category


pages that allow filtering and sorting


by every possible combination, search engines


can get bogged down trying to figure out all of these URLs


and might miss URLs that you do care about.


On dynamic websites like these, work


to keep functionality open for users


while preventing crawlers from getting lost.


Again, make it easy for our systems


to recognize that your new pages are important.


Then use URL submission methods available to you.


Use a site map to tell Google about new pages automatically.


For individual URLs, use the Inspect URL tool


in Search Console.


Last but definitely not least, keep your website's


overall quality high.


Taking a step back, the easier it


is for our systems to recognize that your website is


critical for users on the web, the better


they can prioritize the website for crawling and indexing.


This is easier said than done, of course.


And just to get back to our disclaimer,


forcing something to be indexed does not


mean Google will show it prominently in search,


and it does not mean that it will remain indexed.


The best way to improve those parts


is to make your site fantastic overall.


So in short, there are a lot of aspects


that come into play with making new pages visible in search.


There's no absolute timeline for any of these steps,


and they can change over time.


Apart from the technical issues, it's


also important to keep the overall quality


of the website in mind.


Google systems want to recommend fantastic content to users


as quickly as possible, so it's always worth focusing on that.


And that's it for this time.


I hope you found this episode useful and insightful.


See you in the next episode of Ask Googlebot.


Don't forget to subscribe to see the next episodes.


Can my URLs use non-English words? - SEO Snippets

Today's question comes from John from Switzerland.


That's me.


My question.


So can URLs use local non-English words?


For sites that target users outside of English-speaking


regions, it's sometimes unclear if they can really


use their own language for URLs.


And if so, what about non-English characters?


Google Search uses URLs primarily as a way


to address a piece of content.


We use URLs to crawl a page, which


is when Googlebot goes to check the page


and to use the page's content for our search results.


As long as URLs are valid and unique, that's fine.


For domain names and top-level domains,


non-Latin characters are represented


with puny code encoding.


This can look a little bit weird at first.


For example, if you take Mueller, my last name,


with the dots on the U, that would


be represented slightly differently as a domain name.


For browsers and for Google Search,


both versions of the domain name are equivalent.


We treat them as one and the same.


The rest of the URL can use Unicode UTF-8 encoding


for non-Latin characters.


You can use either the escape version or the Unicode version


within your website.


They're also equivalent to Google.


Regardless of what you place within your URLs,


make it easy for folks to link to your pages.


For example, avoid using spaces, commas,


and other special characters in the URL.


They work for Google, but they make


linking a little bit harder.


Use dashes to separate words in your URL.


Some prefer using underscores.


That's fine, too.


Dashes are usually a little bit easier to recognize.


And if your site is available in multiple languages,


use the appropriate language in URLs


for content in that language.


So to sum it up, yes, non-English words and URLs


are fine.


We recommend using them for non-English websites.


Check out the links below.


And don't forget, you can drop by our helpful.


And remember, subscribing to the channel


Google Search News (Sept '19) - changes in GSC, nofollow links, new meta tags, and more

Hi, everyone, and welcome to the first Google Search News.


I hope life is treating you well wherever you are.


I'm your host today, John Mueller, here from Google Zurich in mostly sunny Switzerland.


With this show, we want to give you a regular summary of what's been happening around Google


Search, specifically for webmasters, publishers, and SEOs.


If you'd like to stay up to date, make sure to subscribe to the channel.


Today we'll be covering Search Console, changes in nofollow links, some new meta tags to watch


out for, and a bit more.


Google Webmaster Tools, I mean Search Console, made a big step towards moving over to their


new interface recently.


Search Console is a free tool that gives webmasters and site owners information on how Google


Search interacts with their websites.


The most visible change is that the old homepage and dashboard are now replaced with a new


one.


This is a big step for the team and allows them to focus more on interesting new features


for the millions of websites that use these tools.


We haven't moved everything over yet, and some legacy features are still linked from


the new Search Console for now.


But stay tuned.


Search Console will continue to evolve.


In other news, there's been a change in the Webmaster Office Hours.


The Webmaster Office Hours are a way for anyone to chat with a Google employee about their


website and Google Search.


Let's take a quick look at how it works now.


First, we introduce new sessions about a week beforehand on the YouTube community page,


as well as in the event calendar.


For each session, you can leave questions that you'd like to cover directly as comments


and vote on other questions.


Once the session starts, we'll add the link to the live video conference as a comment,


and you're welcome to join in person to ask, elaborate, or just discuss.


These sessions are recorded, and the recordings added to our YouTube channel afterwards.


Everyone is welcome to join.


Fifteen years ago, we introduced the rel nofollow attribute on links.


The web has evolved significantly since then, so recently we gave it a bit of a revamp and


expanded it.


Google announced two new attributes for outbound links.


These are rel="sponsored", and rel="ugc".


The first, rel="sponsored", is for advertisements, sponsorships, and the like.


The other, rel="ugc", is for links created by your users in user-generated content.


All of these are considered hints for ranking purposes.


Starting March 2020, we'll also be treating these as hints to help us discover new pages.


This helps us to better understand the web overall.


Existing sites don't need to make any changes, but being clear with rel="ugc", and rel="sponsored",


is an option.


If you're unclear about which attribute best fits, drop by the Webmaster Help Forum.


Recently, Google changed when review stars are shown in search results.


The change has two parts.


First, review-rich results are only shown for certain types of items where reviews really


make sense.


Additionally, if a local business, organization, or subtype of these includes reviews about


itself on its own website, those would not be shown in search.


This includes both reviews a business collects itself, as well as those from third-party


providers that are embedded with widgets.


Reviews about other supported items continue to be shown as before.


Curious to find out more?


Check out the blog post linked below.


On September 24, Google announced a set of new meta tags that give publishers globally


the ability to express preference regarding how much of their page's content is shown


as a preview in search results.


In particular, there are meta tags that let you specify how many characters may be shown


in a text snippet, whether and how large an image preview may be, and how long a video


preview may be shown.


Additionally, there's an HTML attribute that can be used to restrict parts of text from


being shown as a preview.


We call it the data no snippet attribute.


That feature will become available later this year.


Next to these, our documentation goes into how AMP pages and how structured data may


be shown in search.


I'll link to the documentation in the description below.


In other news, we've been holding a number of webmaster conferences worldwide in places


like Kuala Lumpur, Bali, Ho Chi Minh City, and Sapporo, Japan, with more locations lined


up.


These events are made for local webmasters and generally run by Googlers from offices


close by.


If you see one nearby, feel free to register and say hi.


That's all for now, folks.


And now, on to the weather.


Well, it's autumn here now, so there's a bit of sun and a bit of cloudiness.


So whether it'll be a nice day is hard to say.


I guess you could say, it depends.


But stay tuned for the next weather report and, of course, Google Search News coming


English Google Webmaster Central office-hours from August 18, 2020

All right, welcome, everyone, to today's Webmaster Central


Office Hours Hangout.


My name is John Mueller.


I'm a webmaster trends analyst at Google in Switzerland.


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


where people can jump in and ask their questions


around their website and web search.


And we'll try to come up with an answer.


A bunch of stuff was already submitted on YouTube.


But if any of you want to get started


with your first question, you're welcome to jump on in.


MIHAI APERGHISLOOO-MUNDINEZ-SINAKASENKO.


John, I have a couple of questions


regarding internal linking.


OK.


So one would be whether, let's say,


you have an architecture of categories


that use your main navigation.


And it's one way on the desktop site.


So for example, you might have some dropdown, some mega menus,


things like that, that you can hover with your mouse.


The dropdown shows.


But you can also click on the link


and go to that top category if you'd like.


However, on the mobile, since you're


kind of limited both interface and functionality,


maybe that top category is still there with our HTML link.


But when you tap on it, it just lowers up the dropdown


or something like that.


So my question is, if Google treats the fact that, well,


there's a link there in the navigation,


but when users tap on it, it doesn't actually


go to that page.


It just launches a dropdown or something like that,


even though there is an HTML link.


So the behavior of the link is not actually


acting like a link.


It just shows you a dropdown or something like that.


Does Google treat those in any way differently?


I guess it depends on how that is modified on mobile.


Because if we render that page, and essentially that HTML link


is swapped out with a JavaScript event,


and that HTML link is no longer there in the rendered page,


then we might not see that internal link.


But if the HTML, if the link element is still there,


if it's just something like a span on top of the link element


and that catches the click and does the JavaScript fanciness,


that's perfectly fine.


OK, so there's no worry that, oh, it's


not taking into account or anything like that


in terms of crawling.


OK.


Second question is kind of related


to how there's been this information that when


Google sees multiple links going to the same page on a given


page, it only takes into account the anchor text


for the first link that sees on the page


and kind of ignores the rest.


I'm not sure if that's kind of exactly true.


And whether, so for example, if you have a link in the menu,


but then you write an article about it,


then you might reference the same page


with a different anchor text.


Does Google understand that and see, well,


it's in the main content?


So even if you have it in the menu,


I'll take a look at that anchor text in the main content,


because it seems more important.


Does that play any role?


I don't think we have that defined, like that behavior.


So it can go either way.


And it can be that we take kind of the multiple links


that we find, and we combine the signals from that.


So that's something where that kind of misconception


that if you have multiple links to the same page on one page,


then you need to make sure that the most keyboard


which anchor text is the first one on the page, that


is not the case.


That's not the case.


So from that point of view, it's not


that you need to artificially tweak the order of the links


on the page.


But it's also not the case that we have kind of this one defined


way that we always treat things when we find


multiple links on a page.


OK, I was mainly asking for e-commerce website,


you just have women or men or anything like that.


But in the content, let's say you have a blog,


and then those articles, you kind of reference those pages


with more relevant anchor text.


So I was wondering if Google could also take


those anchors into account.


Yeah, from my point of view, we could take those into account.


It's just not clearly defined that we


will do exactly one to one.


I think for the most part, with normal websites,


there are so many different links going to every page


with internal linking that it's not critical,


like which anchor text you use from this one page


to this one other page, because we


have so much other information from the rest of the site.


OK, last one.


So let's assume that certain pages


are linked from multiple sections that are site-wide.


You have one in the main navigation,


but you also have one in the footer,


like let's say to the contact page or to the FAQ page


or anything like that.


And since page rank usually works


by also counting the number of links on the page matter


and the time you mentioned you link to a certain page


also matter, is that something like Webmaster


should take that into account?


Maybe don't have four links to the privacy policy page


on every page on your site, because that kind of takes away


from the rest of the links you might have in your navigation.


Or is that too little of a factor to bother about?


Yeah, I don't think that would play a role.


So I mean, I'm kind of tempted to see


if I can play with something like that maybe on our blog


or something where we put links to, I don't know,


maybe a privacy policy 10 times instead of one time.


But my feeling is that wouldn't change anything at all.


I'm only asking since certain tools like Screaming Frog,


for example, they calculate the link score


in a very basic way similar to how page rank works.


So you might see a link, the FAQ page or the privacy policy


page having a very, very high link


score over some of the pages that you might


want to be better internally linked.


So I'm just wondering if Google, I


know it's a very basic calculation that they


do versus what Google does.


But I was just wondering if it's something


that you could kind of try to treat maybe here and there


or not really bother because Google kind of doesn't really


care about that.


Yeah, I think for the most part, it's wasted time to do that.


I think it's important that these tools show this kind


of score internally because sometimes you


do kind of lose track of pages.


And you think this one thing is really important,


but actually you only link to it once on your whole website.


And then kind of getting that highlighted is really useful.


But for the most part, I wouldn't really


worry about those details.


Also, the follow up question from there


is sometimes like, should I no follow the links


to my privacy policy page because I don't want it to rank?


And we have a lot of practice with privacy policy pages


and similar pages where we understand


they're linked from everywhere within the website,


but they're not the most important piece of content


on the website.


So we kind of understand these kind of relationships.


But I think kind of having some kind of score,


having a way to look at how a crawler would


look at a website in a naive way, I think is really useful.


So I wouldn't discount those tools


just because they don't map one to one to what Google does.


Gotcha.


OK, thanks.


I'm done.


Sure.


Cool.


Anyone else before we get started?


Hi, John.


I have one.


OK.


One of you might.


Yeah, that's me.


So I asked in the last Hangout question


about that one of our websites kind of duplicating home pages


via like, I mean, from one Japan, one from Brazil.


But they're kind of holding together,


and Google thinks they are duplicating.


So just wanted to follow that part.


Like, I mean, is there something that we can do from our end


that can make it Google for, like, you could say,


visible, like the different pages?


Or like, how we should go about that one?


I don't remember the details there.


But was that something like you have the same English content


on the page for Japan as well as on a page for another country?


No, they are different.


Both pages are different countries.


OK.


Yeah.


Um, I don't know.


I probably need to take a look at the examples again.


If you want to drop the links into the chat,


I can pick that up afterwards.


Sure.


Thank you so much.


Maybe add a comment as well.


Then I know exactly what to watch out for.


All right, cool.


Thanks.


And links in the chat don't pass any page rank.


All right.


Someone else had another question as well.


Hey, John.


How are you?


Hi.


OK, I have two very, very small questions for you.


One is regarding the search console


inside that Google recently launched on Google Search


Console.


It seems the data that Google shows


is based on Google Search Console plus Google Analytics.


So just wanted to confirm if your website doesn't


have Google Analytics account.


So will that insights will still be there,


or you need to have Google Analytics account for that?


My understanding is you need to have a tie-in with Google


Analytics.


Because the firm, so I haven't been following


all of the details with Search Console Insights.


But my understanding is that the idea


is to kind of provide a mix of the data


from Analytics and Search Console in a way


that it's a little bit easier to understand for people who


don't spend their whole life in Google Analytics or in Search


So that's something where we really kind of need


to have both of those data sources


so that we can show that kind of simplified data there.


OK.


The second question is regarding nofollow.


Like, it is believed that Google doesn't pass page rank


to a nofollow link.


But recently, like, Google decided


to crawl if the link is even tagged as nofollow.


So if this Google decides to crawl that URL,


will it pass page rank to that URL after crawling?


Or if Google thinks that this URL is good enough


to be crawled and indexed, but we should pass the page rank


or not?


I don't think you can simplify it that much.


There are multiple aspects with regards to nofollow there.


On the one hand, like you mentioned,


we decided to start trying to treat it as a hint rather than


a clear directive.


And that can result in us following


links that have a nofollow to discover new URLs.


So especially if there is something


that we haven't seen before and we see there is a nofollow link


there, then we might go off and try to crawl that page.


And if we think it's worthwhile, maybe we will index that page.


So that's kind of the one aspect.


But the aspect with regards to passing page rank and passing


signals, that's something that's totally independent of that.


That's something where we also need


to take into account a lot more rather than just,


is this a new page or not?


So just because something got crawled


that has a nofollow link doesn't mean


that we're going to start passing all kinds of ranking


signals to that page.


It can, but it's not necessarily required.


trying to follow up on that last I heard from Gary was that it's


kind of those nofollow links, we could theoretically use those


to pass signals.


I believe we are using them for discovery already now.


But I don't know.


Gary would know more.


All right.


Thank you.


Maybe I should drop him a tweet and find out.


OK, let's jump into the questions.


We have the top question from Barry.


Can you comment more on the August 10th indexing system


failure and maybe what happened this past Saturday?


See your favorite SEO blog for more details.


How do you know what my favorite SEO blog is, Barry?


That's like, are you reading my email?


I have a little malware installed in the computer.


OK.


Well, if it's just that, bye.


I don't have any more information.


So my feeling is with the August 10 issue,


that's something where it get resolved reasonably quickly.


And I don't know if the team would have more information


to share on that publicly.


And with regards to the one on the 15th,


I don't know the details of what happened there.


But that also seemed like something


where even you kind of didn't really


see what exactly was changing.


Just like everyone was complaining,


and then suddenly it was gone.


So maybe that was just something really short.


I think technically it was only short


because I didn't get back online until Saturday night.


But I think it happened Saturday morning.


OK.


And then there were some screenshots


from like Glenn Gabe and other people


where it showed some pretty significant changes.


And then things went back sometime or at night,


at least Eastern time.


Are you aware of anything that went wrong?


Not specifically telling me what went wrong,


but did something go wrong?


I don't know.


There are lots of systems at Google.


Is this an I don't know that I can't comment?


Or I don't know.


I really don't have any additional information on that.


So I mean, there are lots of systems at Google.


And sometimes when something kind of quirky


happens for a really short period of time,


they just go off and fix it without letting everyone know.


I think the earlier issue seemed to have been a bigger one.


And that's kind of also why it took a little bit longer


to get everything redone.


And we ended up tweeting about it briefly.


OK.


Thank you very much.


Sometimes we don't have a lot of internal details to share.


Now, a question about pagination, or five questions.


What's the importance of pagination?


Are there issues with pagination?


What about infinite scroll?


Should paginated pages be indexed?


What is the best practice of pagination?


So lots of questions.


I don't know, let me see if I can run through them briefly.


So essentially, when we talk about pagination,


we mean you have one thing that is really large,


and it doesn't fit on one page.


So you split it across multiple pages.


And that could be maybe one long article where you say,


well, it's worthwhile splitting this.


It could be a list of individual products, maybe in a category,


where you say, well, I have 5,000 products.


I can't put them all on one page.


I will put them on five pages, or 1,000 pages, or whatever.


So that's kind of where pagination comes in.


And from our point of view, it's important


that we can recognize this kind of pagination


and essentially index those individual pages so that we can


pick up all the content or all the links to individual items


that you have on the paginated pages.


Usually, with pagination, one of the questions that comes up


is, well, this creates a lot of new URLs,


because you have to go through all of these pages


to get all of the content.


And yes, it does generate a lot of URLs.


And we have to index a lot of different pages.


But if we want that content in our index,


if we want to understand those internal links


to your other pieces of content, we kind of have to do that.


Infinite Scroll is a way of doing pagination without the


user having to click Next.


The important part there is that you


do Infinite Scroll in a way that works for search with regards


to crawling and rendering in particular.


And we have some guidelines on how to do that.


So in particular, one recommendation


is to have separate URLs for each page


so that you can still go to the individual pages


to have links to those individual pages.


And for the user, if they scroll down to the bottom,


then it's fine to load the next page kind of thing.


Should all paginated pages be indexed?


Yes.


Kind of like I mentioned before, if there is something on there


that you want to have known by Google, which could be a link


to a different product, which could be a part of a longer


piece of content, then it has to be indexed.


And the best practice is, following up


on the other steps there, we have


to know about these paginated pages.


So you have to link to them, usually


with a next and a previous link.


And with normal HTML links, we can pick that up fairly easily.


You don't have to do anything special


for this kind of pagination.


So just link from one page to the next


and link to the previous page as well.


Then we can crawl through all of those paginated pages.


I kind of ran through this.


And I know there is a lot more, depending on what kind of setup


you might have.


So this is something where we will probably


have a bit more information, in particular for e-commerce sites


to make it a little bit easier to understand what exactly


should be indexed with pagination.


In general, we find that most sites implement pagination


in a way that just works.


So we've kind of stepped back from saying,


we need to define exactly what people


need to do for pagination.


But rather, if you understand these pages need


to be indexable, then you understand


they need to be linked.


You can test them with a local crawler.


And usually, that just works out.


Google is indexing pages with parameters.


Is this considered duplicate content?


Should I use the URL parameter tool in Search Console


to fix it as a best method?


So in general, pages with parameters


aren't necessarily bad.


It's something where in the past, maybe going back,


I don't know, 15, 20 years, like a really long time,


search engines were kind of reluctant to index URLs


with question marks in them because it's


easy to create a lot of URLs that way.


But that has since changed since a long time.


And URLs with parameters in them are perfectly fine.


Sometimes they can lead to duplicate content.


And in most cases, we figure that out ourselves.


We recognize this URL with this parameter


is the same content as the different URL


with a different parameter.


And from our point of view, that essentially just works out.


If you find that within your website


you have a significant amount of duplicate content


and a significant amount of pages


so that you can assume that crawling is really


hard within your website.


So say, for example, you have, I don't know, 100 million pages.


And you recognize with the parameters


that you're linking within your website,


you're creating 10 times as many URLs as you have pages,


then those numbers are really, really big.


And that's something where it definitely


makes sense to go off into the parameter handling


tool to resolve that, also to think


about your internal navigation, where


these parameters are being picked up on,


and to improve that.


So that's kind of, I guess, the extreme situation.


Most sites are somewhere in between.


Some have just a few pages worth of parameters.


And at that scale, I really wouldn't worry about those.


Any comments on Google blocking new publishers


since December 2019?


So I saw a bunch of your tweets as well.


I don't have any insight on that.


It's definitely not the case that we're blocking any new


websites from appearing in search.


There have been lots of new websites since then.


And they do appear normally in search.


But it is something where you mentioned a bunch of examples


where you thought things weren't working as well as they should,


specifically for Google News.


And I forwarded that out onto the Google News team


to double check to see if there's anything that we


could be doing better there.


One of my websites.


I think that was related to the News Publisher Center.


If you submit it through Bear, it's not getting,


I'm not even sure.


But it sounds like it's all around the new Google News


Publisher Center.


That provides more of something for you to look into.


I don't know.


I don't really have any insight into the news side.


But since crawling and indexing is combined


when it comes to news, if we can pick it up for search,


then we should be able to pick it up for news as well.


I think most sites don't do anything special


to be picked up in news.


Right, yeah.


No, I'm just, yeah.


I don't know if there's anything specifically


buggy with the News Publisher Center,


like the Google Search files, Open News Publishers.


I'm not sure.


It's always possible that there is something buggy.


But it would surprise me if it were completely broken


since December 2019.


It seems like a pretty long time.


I agree.


Yes.


One of my websites got backlinks from a domain that embedded


my Twitter page feed.


And the backlinks are coming from a tweet link.


I don't think embedded feed content links


are followed by Googlebot.


Please enlighten me.


I don't know how these tweets are embedded.


But in general, when we see things that are embedded


with JavaScript or with an iframe on a website,


it is possible for us to say that this part of the content


could be seen as a part of that page.


And it is possible that we will pick up


links in tweets like that.


That said, my understanding is that Twitter pretty much uses


nofollow links everywhere.


So essentially, those would be nofollow links


pointing to your website there, where for the most part,


we wouldn't be passing any particular signals there.


So from that point of view, I don't


see anything particularly positive or negative


with regards to SEO if you get a link from one of your tweets


that was embedded on another person's website.


Usually, it's a good sign that people like the tweets


that you're writing and maybe are OK with the content


that you're providing on your website,


assuming they're writing about it in a positive way.


But essentially, that's independent of any kind


of SEO effect from those individual links.


The thing to also keep in mind is


that, in particular, in Search Console,


the links that we show there are just all links or a sample


of all of the links that we know from the web for your website.


So it's not that we would only be showing you links there


that pass any signals or that have any special weight.


It's very possible to show things there that are maybe


even disavowed, maybe that have a nofollow, anything


like that too.


How does Google know about the category of a new URL


being added later?


So the URL wasn't mentioned in the sitemap.


I don't know how you mean the category of a new URL.


But assuming it's just generally,


how does Google know about this new URL


that I added to my website and I didn't put it in my sitemap


file, we use lots of things to pick up new URLs,


but we don't make them up.


So essentially, somewhere, there must


have been a link to this page within your website


that could be within your own content, that


could be within a sitemap file, within an RSS feed, maybe


someone else, maybe a tweet, anywhere, essentially.


And if we spot a URL and we think,


oh, this might be something that's useful,


we might go off and look at that page


and see if we can index it.


And if we can index it and we think it's something useful,


then maybe we will index it.


So that's essentially the story of where the URLs come from.


It's not that we have any kind of magic back door


to your server and can look at what


you're doing on your server or anything like that.


We really kind of have to follow those links.


And sometimes, the links that we find


are a bit surprising to people in that they don't realize


that maybe a link is included in their RSS feed,


even if they don't manually include it in a sitemap file.


Or maybe they don't realize that someone else has tweeted


a link, or maybe you shared a link by email,


and the email address you shared it to


is actually a public mailing list,


and suddenly that link is in a public mailing list


where we could also pick that up.


Our website and our blog have an English and a Spanish version.


In Search Console, we have a property for each language


where we upload the sitemap separately,


while the pages related to our service are translation,


and therefore, through hreflang, we


indicated clearly the English blog and the Spanish blog


are not linked, as they have different contents.


And we try to track traffic by offering


different contents and different experience for each language.


In the blogs, we implemented AMP versions for the articles.


Here are some questions.


Is it necessary to define the articles as canonical URL,


since I comment there the AMP version?


Yes.


So for connected AMP pages, I assume


this is the case, that you have one traditional page


and the AMP page, and you link to them.


With that kind of a setup, you need to use the rel canonical.


That's the definition of these pages.


Even if you have standalone AMP pages where you just


have AMP pages and no traditional content,


you need to have a rel canonical on that page pointing


to itself.


So that's independent of any translations,


independent of any hreflang.


For the AMP setup, you need to have the rel canonical.


Is this configuration correct?


It's essentially fine to have it set up like that.


So if you have some pages that are localized,


and you have the hreflang links between them,


and other pages that are just in different languages,


but not localized versions of each other,


then you don't have the hreflang there.


That's perfectly fine.


hreflang is a per page annotation.


You don't have to do it on all pages.


You can do it just on the home page,


do it just on an About Us page.


You can pick and choose however you want.


We have some concern that URLs don't have an AMP page,


can't be fast enough, can just generate problems


for the ranking of the blog articles.


So we do use speed as a ranking factor,


but it's a fairly small factor.


And you can make really fast pages that are not AMP.


And you can also make slow pages that are using AMP.


So just because one part of your site uses AMP,


and another part doesn't necessarily


mean that the part without AMP is slower,


or in any way kind of treated less favorably compared


to the rest of your content.


So I wouldn't primarily worry about this difference AMP


and not AMP, but rather think about speed overall.


And you can test speed on your side


as well using the various speed testing


tools that are out there.


So instead of just kind of purely AMP or not AMP,


I would look at the speed overall.


Are the AMP versions used to measure and rate


the URL speed performance of our articles?


So in particular with the new core web vitals


that is coming to search, we don't have a date for that yet.


When that will be used as a ranking factor,


we'll let you know at least six months ahead of time.


But with that, we look at the page that users actually see.


So if users see the AMP version of a page,


and that's essentially the main version they see,


maybe on mobile, then we will use that when it


comes to our speed calculations.


On the other hand, if people see kind


of the traditional HTML version, they


have to click a link to go to the AMP version


or something crazy like that, then we


would use that page that we showed the users,


which in that case would be the traditional HTML version.


We used to have pagination on our main blog,


but we realized that they were indexed in Search Console


by mistake.


The same pages with different URLs for pagination.


We removed the pagination, and it


looks like the issue is solved.


We need to de-index those mistaken URLs.


So wow, more pagination questions.


No, you generally don't need to do that.


Usually what happens when you have pagination activated


like that on kind of a blog setup,


then it's just like paginating through different previews


of articles on your site, and it's just a parameter


that's added to the page.


And if you disable that, then essentially going to those URLs


just shows the home page again.


So if we recrawl and reprocess those URLs over time,


we will see the home page, and everything will be fine.


If, on the other hand, it results in those URLs returning


404, then we will recrawl and reprocess them and drop


those URLs out of the index as well, which is also fine.


So either way, it's not that you necessarily


need to do anything to remove those URLs from the index.


Can monetizing your website with an ad partner


potentially hurt your rankings in Google?


Because after signing up with these partners, what I realize


is they like to show more ads on your website,


so I'm just worried if it will cause a drop in my ranking.


Well, I guess in general, if you add monetization


to your web pages, then that monetization


has to be visible somehow, which can result in ads


being shown on your pages.


So that's, on the one hand, kind of to be expected.


On the other hand, with regards to Google rankings,


we do have some things that we watch out for.


So in particular, the above the fold content


is something where we want to see some actual content, not


just an ad.


Depending on the way that you have monetization set up,


you might need to watch out for that.


Then there is a better ad standard,


which is something that, particularly from Chrome,


they look at for some pages, where


if they realize that a site is significantly not


compliant with a better ad standard,


then Chrome might decide not to show ads on that site at all.


So that's something to look at.


That's not necessarily related to SEO,


but it kind of falls into the same category


of types of issues.


And I think that's pretty much it.


I think, in general, when it comes


to monetization on your site, it's


important that you do that in a way which


is long-term sustainable so that you don't drive users away.


Because if you drive users away from your website,


then they're not going to be out there recommending


your website to other people, which


is something that indirectly we might pick up on in search


with regards to SEO things.


So if you do decide to work with monetization on your website,


which, from our point of view, is perfectly fine.


It's like you have to pay for your website somehow.


You have to pay for your time and your work somehow.


So monetization is bad.


But if you do decide to implement


some kind of monetization, make sure


that it's implemented in a way that you can stand behind


where you can say, well, this is really the way


I want my website to be presented in search,


the way I want my website to be presented to new users


when they come and visit from the search results.


Second question there, cross-posting my article


on another forum with a canonical URL,


will that downgrade my ranking?


My blog is all about programming,


and I do like sharing my posts with a canonical URL


on other developer forums.


So is that going to hurt my ranking


because the other forums are very authoritative


and ranks very well on Google?


So in general, there are, I think,


two situations that can occur here.


And it's something which our systems can't guarantee


one outcome or the other.


It's possible that we will index both of these pages


individually.


If we look at these pages overall,


and it looks to our systems like these are significantly


different pages, then we may index them individually.


And we may end up showing them in the search results


separately, which could mean that the website that


is syndicating your content is ranking above you.


So that's something that theoretically can happen.


The other alternative is that we recognize that these pages are


significantly the same.


And in that case, we will try to pick one canonical URL.


And the rel canonical does help us to understand


which of these pages you prefer to have


being chosen as a canonical.


And in that case, we will concentrate all of the signals


on that one canonical URL.


And we will use that one for indexing and ranking.


The thing to keep in mind is that the rel canonical


is just one of the signals that we use for canonicalization.


So there are also things like internal and external links,


sitemap files, the hidden links within a website,


all of those things which play a role in determining which URL


we should choose as a canonical URL.


So it's not always guaranteed that we will pick


your URL as a canonical.


But those are the two situations that can occur.


And like I said, it's not guaranteed that it'll


happen one way or the other.


So if you do choose to syndicate your content like this,


I think that's just something to keep in mind,


in that it's possible that your information will


be shared more broadly.


And your information will be findable on other people's


websites, and that maybe we will show the other website


as the one in search results ranking a little bit higher.


So that's something where you have to think about,


is it important that my page is visible in search?


And if that's the case, then maybe make sure


that you're just publishing content on your website.


Or is it important to you that my information


is available in search?


And in that case, maybe it's fine to publish it


on multiple different websites.


So those are kind of strategic decisions


that you can make there.


And I don't think there's one answer that works


for all websites.


If you have security reports in Google Search Console,


after some submissions, Google will start to review them.


After a couple of weeks, will this reflect other crawlbots,


like desktop, mobile, et cetera?


So I'm not quite sure how you mean there.


So it's really kind of hard to say.


Usually, if there are security issues, for example,


reported in Search Console, that would mean, for example,


that maybe your website is hacked.


Maybe there is malware that was found on some of your pages.


Maybe there was some phishing that someone


hosted within your website.


Then those issues wouldn't affect


how we crawl the rest of your website.


It can affect how we show it in search,


in that if we understand your website is hacked,


then maybe we need to be more careful with what


we show your pages for.


So that's something that can play a role there.


But I don't think it would affect how we would crawl


your website overall.


But regardless of any effect on crawling or indexing,


if your website does have security issues,


I would recommend resolving those as quickly as possible


and trying to figure out where they came from.


So if your website got hacked, then don't just fix that hack,


but rather think about how were hackers


able to actually get into my website


and add that hacked content?


And what can I do to prevent that in the future?


Do backlinks from guest posts have any ranking value?


Or are we wasting our time for the sake of ranking and not


for traffic?


I don't know.


It feels like this topic comes up every couple of weeks.


We've kind of had our stance on this since a number of years


now.


And essentially, the idea is if you're doing guest posts just


for those links, then for the most part,


I would assume that those links have no value at all.


So that's essentially our stance there.


And there are lots of kind of fine details there.


But we've talked about them so often.


There's lots of information out there to kind of check


into as well.


I work on a UGC website with more than 30 million pages


of content.


Main content of the pages does not change much.


But the auxiliary content, like reviews and comments,


are added frequently.


We don't track very well when each content is updated.


Our site maps are updated daily with current value URLs,


but setting last mod for them as the current date.


We also set priority and change frequency to static values.


We suspect we're being limited by crawl budget.


Can our site map structure negatively


be affecting how Google is crawling our website?


Website.


So yeah, I think there are multiple things


that come together here.


In general, if you always have the same date in your site map


file for all of your URLs, we're going to be ignoring that date.


So if you're doing something like you mentioned here,


where you're taking 30 million pages and saying,


all of them changed today, then we're


probably going to be looking at your site map and saying,


well, we're just going to look for new URLs


within the site map file.


We're not going to look at the date,


because a date doesn't give us any more information.


It's not that we can go off and recrawl your whole website


every day.


So that's kind of the main thing here.


The priority and change frequency settings


are also settings that we generally


ignore, because we found that they don't provide


a lot of extra information.


If we have a date that we can use,


then we don't need to know how frequently a page might


be changing.


With regards to kind of setting a date as a change


date in a site map file, we recommend


using a date that is really significant for a change


on your pages.


So if things like just a number changes on your web page,


that's not usually a sign that this page needs


to be recrawled and re-indexed.


But if something significant changes


on your website on those pages, then that's


something where I'd say it's worthwhile picking that up


and using that as a new change date.


So that's kind of the recommendation with regards


to change dates in general, the last modification.


If you don't do that, if you have it set up


like you have here, we will ignore the last modification


date, essentially.


And we will just use the site map file


to try to recognize new URLs on a website.


But we don't kind of penalize a site


for this kind of site map file.


It's not that we would crawl less frequently


or we would crawl worse if you have a bad site map


file like this.


We would just crawl naturally like we


would any other website.


And usually what that means is we will just go off and crawl


pages on your website, try to refresh them in cycles


that we think kind of make sense.


to recognize new things on your website.


This doesn't affect crawl budget at all.


So crawl budget is specifically more


of a kind of foundational technical thing, which


is based, on the one hand, on the demand


that we need, that we have on our side with regards


to crawling and indexing.


How many pages do we think we need to recrawl


from this website every day?


That's kind of the one thing.


We would like to do this much.


And on the other hand, we kind of


have the limits, which can be the limit that you


set in the Search Console.


It's also based on the server capacity.


How quickly do we think your server can respond?


How much, I don't know, how many requests can we send it


every day, those kind of things?


And those are all independent of the site map file.


So just because if you have a bad site map file,


doesn't necessarily mean we will crawl less frequently.


We'll just crawl a little bit more organically,


rather than direct, based on your site map file.


Is canonicalization a best practice,


or is not having duplicate content at all a best practice?


I think a little bit of both.


So not having duplicate content makes it easier


for us to crawl and index the primary content


that you want on your site.


But it's kind of impractical for all websites


to not have any duplicate content at all.


It's essentially normal part of the web.


So because it's such a common thing on the web,


using the rel canonical, using proper canonicalization


just makes it a lot easier for us


to focus on the good parts of your website.


So reducing the duplicate content on your site is good.


Using rel canonical is also good.


Wow, lots of questions left.


Let me just double check to see.


There's one other crawl rate question.


Can you suggest an optimal crawl limit for Googlebot?


If I set a limit of 30 requests per second, is that enough?


That's totally up to you and your website.


So we don't have any specific limits that we recommend.


Usually, with regards to the Search Console setting,


we suggest that you just leave it as, like, Google decide.


Because the Search Console setting


is more of an upper bound limit.


It's not that you're saying Google will crawl this much.


But it is that Google can crawl at most this much.


So for most websites, you don't need to set an upper limit.


We will figure that out ourselves.


If you do notice that we're killing your server


and causing you a high bandwidth bill or something like that,


then setting that upper limit is definitely a good idea.


Wow, still a bunch of questions left.


But time is running kind of low.


Maybe I'll switch to any questions from you all.


If there's anything left from your side.


SPEAKER 2


Just wanted to quickly confirm that this person is saying,


not a single website since December 2019 has been indexed


or ranked that is new, like a new website.


And I asked on Twitter, has any SEOs


had any new websites indexed or ranked since December 2019?


And I'm getting a bunch of yeses.


So there you go.


OK.


I mean, yeah.


I mean, maybe it's not a general issue.