could be very, very helpful for discovering malicious sites,


Pop filters, nofollow, Core Web Vitals, and more! | Search Off the Record podcast

for example, the ones that force downloads and whatnots or spam,


even, I guess.


So yeah, I think no-follow links could be helpful.


But we just don't have anything yet


to say about how we use them.


MARTIN SPLITT ANDERSON


But you're trying things out?


Yes, I am actually working on, I think, three projects, sub-projects


or whatever, trying to see if it would make sense to actually


use no-follow in those cases.


And I know that one of our ranking leads


actually asked us to, if we get to launch


with one of the projects, then we should announce it publicly.


So if we are going to launch with at least one


of these things, then you are going


to know about it publicly because we kind of have


to announce it.


Cool.


It sounds like this is more to, on the one hand,


catch errors that people are making on their website


and to be able to understand the problematic parts of the web


a little bit better.


And it's less something that people will need to optimize.


If you have an existing website, you


don't need to think about this if you're doing those parts


correct already, right?


Exactly.


With the changes that we announced,


you already don't have to do anything.


You can help us with the new rel attributes if you want to.


And those could be helpful for training machine learning


models, for example.


I'm definitely not saying that we are doing that,


but it could be helpful.


But you really don't have to do anything.


This was always an optional thing for everybody.


It's good to see that people still adopted them.


Like rel sponsored is used on millions of sites already,


even though we just said that, really, you don't have to.


Only if you want to.


And they were just like, yeah, sure, why not?


So it's kind of cool.


It was an exciting project.


Cool.


Yeah, I think it's what I find fascinating about the no follow


changes is that it's like we introduce these in response


to things that we found on the web, which


were a bit problematic.


And now the web has evolved.


And we've been able to kind of change these things as well,


because the rest of the web has been moving forward


at such a nice pace.


So I think that's really cool.


Yeah.


The other thing that I found interesting


when we were working with the leads on the no follow


change, on the announcement, initial announcement,


was that I briefly talked to other search engines about it.


And they were, pretty much all of them were like, well,


we've been doing this for a very long time.


And it turned out that we were the only ones who don't do it.


That was kind of funny.


Oh, man.


OK.


And I'm starting a blog.


A new blog.


A cooking blog.


A blog.


Oh, you're creating a site.


OK, cool.


I am creating a site.


And then I will know how to rank best.


Wow.


Oh my gosh.


Gary's becoming a webmaster.


No, I'm becoming an SEO.


Oh my god.


No, wait.


Well, both.


So Spaghetti Experience Optimizer.


Yes, Japanese Spaghetti Optimizer.


Oh, god.


You know it's very rude when you call those noodles spaghetti.


Just FYI.


It's kind of offensive.


Oh, OK.


Oh my goodness.


OK, fine.


Looking forward to your non-spaghetti recipes.


Thank you.


I was talking to Lizzie, Lizzie Haraway, who is our tech


writer on our team.


And she brought up that we could just


test the structured data that we published on the blog,


like recipe markup and whatnot.


And basically, I would just give her access


to whatever generates the HTML.


And then she can go nuts on it and see


what happens, whether I get better rankings or not.


We shall see.


That's cool.


That'd be cool.


Yeah.


I think it's always tricky with a lot of these recommendations


that we give to people.


We obviously see how some sites are implementing them.


But it would be really nice to be


able to try them out ourselves so that we can talk a little bit


more from a practical point of view


rather than from a purely theoretical point of view.


So that'd be cool.


Yeah, I mean, I did that recently


with the tests for figuring out how


we are parsing structured data that


was generated by JavaScript.


And I think the things that I noticed


and where the team went, oh, interesting,


we should definitely practice a lot more of these things.


OK.


Yeah.


So does it work, JavaScript with structured data?


Yes.


Yeah, yeah, that works.


There's documentation on the dev side for this.


I will be talking a little bit more about that soonish.


But all of it is documented.


It just doesn't work in the structured data testing tool.


But as long as you use the rich results test, for instance,


or Search Console, it works fine.


Cool.


Is the discovery of the structured data delayed?


Because first, we have to render?


Not really, because we're pretty much rendering any page anyways.


And the render queue median time is like five seconds.


So normally, that isn't a significant delay.


However, if you are talking about Google Shopping,


that is different.


Because in the Google Merchant Center,


they are trying to not render as long as they can.


Basically, they look at the HTML first.


And then only if they don't find the information


they are looking for, only then they render.


So if you are doing e-commerce, it is a little different.


But for search itself, that's not a problem.


Interesting.


Then you can make your site a JavaScript site, Gary.


Single page app with non-spaghetti recipes.


You can write spaghetti code.


No.


Really, no.


I really don't like JavaScript.


Sorry, Martin.


Gary, how dare you?


I'm actually not sorry.


I demand a Japanese dessert.


Sure.


Can't pick it up.


Yes.


Why don't you like JavaScript, Gary?


Let it out.


I think if I start letting it out,


then suddenly this podcast becomes R-rated.


So I would rather not.


I just don't like it, really.


I have the same thing with, for example, Go.


I also don't like Go.


You're just old school, Gary.


I like C++.


I can like Python.


What?


Yeah.


Over Go?


How dare you?


Oh, yeah.


OK.


But not Python 3.


So you'll use tables in your site's design?


I will only use tables.


Tables.


They are very good for ranking.


I guess you have to put your dishes on tables anyway, right?


Putting this aside.


Putting it aside, moving forward fairly quickly,


we launched a whole bunch of speed metrics.


Hey.


It seems like there are lots of these metrics out there.


I don't know, Martin, can you give us


a quick rundown on what's all involved with these new speed


metrics?


Oh, OK.


And just for the record, I would also appreciate that


because I don't understand it.


So it has been a longstanding, ongoing effort


to understand how to measure performance


in the sense of performance for the user, right?


So what is a good, fast website?


What is a not so good, not so fast website


from a user's perspective?


Now, that is surprisingly hard because there


are so many things that you can potentially look at.


And the first thing we had 10 years ago


was to look at how fast does the server actually


respond with the data.


And that's not a good metric because we


have a lot of websites that are not just a bunch of HTML


and images and videos and whatnot that


need to be transferred from the server to the client.


But we also have situations where


you deliver the initial HTML, you


deliver a bunch of JavaScript, and then the JavaScript


has to generate all the content.


So the server responds within less than a second.


The network has the data in, let's say, 1.2 seconds.


So the browser has everything it needs within 1.2 seconds,


let's say.


But the page is still blank because the JavaScript


needs to be executed and needs to create all the content.


And then that metric became relatively useless


because the server response time didn't


say anything about how fast the page is to the user.


So then we looked at, OK, so maybe we


can try to find out when do we start actually painting


content.


So when does the page that you see in your browser


start to not be just a white window?


That is what we call the first contentful paint.


And that is definitely helpful.


And that was what we used the last couple of years.


But we figured that's not helpful either


because when you start painting, let's say,


like a little bit of text, but this website is about images


and the images only pop in like five seconds later,


then that's still a slow website.


So that's not helpful either.


So maybe we need to find out when most of the content


is visible.


So that's the largest contentful paint.


Like, what's the moment when most of the content


is actually user consumable, visible to the user?


That's helpful, but that's still not the entire picture.


Because if it's not just a website like Wikipedia,


or even if it's just a website like Wikipedia,


you want to probably also scroll and interact with the content.


Like, you click buttons, you click on links,


you click on whatnot.


And the fact that we paint this quickly on screen


doesn't actually mean that you can interact with it.


And you oftentimes see that the website looks like it's there.


You click on a link, nothing happens.


You click again, you click again, you click again.


And then after like five seconds,


it actually does the thing that you did.


Or there's like a dropdown, and you click on it,


and nothing happens.


That's frustrating.


So we needed to figure out how to measure that and expose that


as a measurable metric.


That is what the first input delay is for.


So now we can tell when the website starts to become


interactive for the user.


That's great, too.


But then there's one more thing that is very, very annoying.


And it's my pet peeve to be annoyed about this.


We have a website that shows you the thing you want.


And there is a link that you want to click on.


And you tap that link.


And then something else loads.


Most of the time, it actually adds.


But sometimes it's also just like the image


loads or something like that.


And then the link moves down.


And something else is in the space where I clicked now.


And now I click on this completely unrelated thing


because I didn't actually do anything.


I tapped on something.


It wasn't interactive at that point.


And then when it becomes interactive,


there is different content there.


And what happens then is that I click


on something completely unrelated without actually


wanting it.


And then I get taken to another page.


And I'm like, ah, I didn't want to be here.


Why did that happen?


How did that happen?


And that was very, very hard to find out or quantify


as a metric.


I mean, as a user, you see it.


You tap on something.


It moves.


You tap on something else that is in its place now.


You get annoyed.


But how do you measure that?


How do you quantify that into a number or a time


or something like that?


And we recently did that as a new metric


called cumulative layout shifting or shift.


And the frustration or the challenge for webmasters


was that as we developed these new metrics,


it became a little unclear what to look out for.


There were so many different metrics.


There was speed index at some point.


There was first contentful paint, first meaningful paint.


A bunch of metrics were designed to better understand and


reflect what user performance looks like or website


performance from a user's perspective looks like.


And we have been changing our understanding of that


quite irregularly.


So it was relatively hard to figure out


which metric should I actually be looking


at at this point in time.


So someone who has optimized for speed index, which


was a very old metric to model how performance from a user's


perspective looks like, they would optimize for that


and then find out once they have invested all the time


to actually make their website appear fast in that metric


that this metric was no longer used.


And that was frustrating, to say the least.


So we came up with this idea of coming up


with core web vitals, so basically a set of metrics


that is our best current understanding of what


a measurably fast website looks like.


And we understand that, A, this is an ongoing process.


We do see new things happen on the web.


And they shape the way that the web works differently,


which means that also you measure performance differently.


And we are still not fully understanding or quantifying


the user performance perfectly.


So we need to iterate on this on one hand.


On the other hand, we want to give as clear as possible


of a guidance to users and webmasters alike


to figure out what is a fast and good website.


So how do we reconcile this?


On one hand, we need to iterate the metrics.


On the other hand, we want as stable as possible metric set


for users and webmasters to look for.


And we came up with a core web vitals


saying that we would update them roughly on a yearly basis.


And the first iteration of that is three metrics.


The first input delay that I already discussed,


the largest contentful pane that I discussed as well,


and the cumulative layout shifting.


These three metrics are basically


the current model of what we consider a fast website


or a measurably fast website.


This isn't perfect, but this is the best we have at this point.


And we're going to revisit this set of metrics next year


and probably iterate on it as well.


But we will communicate upfront before we make any changes.


And we use these metrics to give developers guidance to say,


OK, my website is objectively said, measurably said,


fast or not so fast or terribly slow,


to then iterate on their own websites.


We can also use these metrics in other places.


Like Lighthouse uses it to score your website.


PageSpeed Insights uses it.


There's a Chrome extension that shows you


how a website is doing in terms of these three metrics.


There's a bunch of APIs in the browser that


allow you to measure these things for yourself


and maybe log them or something.


So there's a bunch of tooling for webmasters available now


that helps them figure out how fast their website is


in the eyes of the user.


And currently, it's these three metrics.


Cool.


And if you were ever wondering if Martin


can have an eight-minute-long monologue, yes, he can.


I can.


I could have spoken longer, but I just wanted


to be as clear as possible.


As fast, I guess.


Minute four, I was about to jump in and just say something


funny.


And I was like, no, let's see how long he can go on.


Eight minutes is the current maximum.


That was really cool.


OK, so on the one hand, getting back


to Gary's fascination about JavaScript,


it sounds like a lot of this is based on websites that


do fancy stuff in the browser.


Would that be correct?


Like, if you have a static HTML site,


does that mean everything loads instantly


and you can interact with it right away


and nothing shifts around?


Yeah, no, that's the thing, right?


So of course, JavaScript is the biggest culprit here,


but you can also screw it up with HTML.


So for instance, if you have super huge images that,


if you are a photographer, you probably


want to upload the highest possible quality,


and then you just put these images in


and you just make them look small in the browser,


but the browser has to actually download the full, I don't


know, like 20 megapixel image, which is like multiple floppy


disks in size, then your website would probably be like,


why would I want to download floppy disks?


Well, it'd be like, who downloads floppy disks, Martin?


You would download.


How old are you?


You wouldn't download a car.


I actually would.


No, I think floppy disk is just such an archaic medium


at this point, and it's such a reasonable size.


And when I see people are throwing 10 megabyte images


on me, then I'm like, that's like seven floppy disks.


Why are you doing?


Because I remember the times where you would install a game


and go like, insert floppy disk 12 out of 15.


So yeah, I'm old, but still young at heart.


No, but yeah, so if you have super huge images


on your website and you force the browser to download them,


then you might actually run into situations


like the cumulative layout shift, where


the image isn't showing up yet.


I click on a link, and then the image loads,


and then somehow another link is in its place,


and then I click on that accidentally.


So you can run into these problems


without actually using JavaScript.


It's just less likely.


Cool.


So Gary is like, if you're going to put any photos on your blog,


it sounds like you need to watch out for this too.


And I guess if you don't measure those metrics,


I'm sure Martin will run those tests for you.


Lighthouse.


I'll run all the Lighthouse tests.


Martin sucks.


No, this is fantastic.


Martin hates me.


No, I don't.


I really, really like you, Gary, and you don't like that.


That's true.


But I'm sure those non-spaghetti recipes


will be good and fast.


Will you make them so that they're fast to cook,


not just fast to load?


Or does the cooking speed not reflect quality?


It's not a web vital yet.


What?


Like, just what?


Gary, just cook spaghetti, but not write spaghetti code.


You'll be good.


Uh-huh.


So how is life in kind of the pandemic times of corona,


how is it treating you guys?


Are you coping?


Are you getting all your work done,


working faster, more efficiently now


that you don't have distractions like cooks that bring you food?


Gary cooks.


I don't bring food.


You have to come here and pick it up.


You have to come to Gary Will and pick up your own food.


I'm actually cooking for, I think, seven people,


plus Martin, because I'm not people.


Wow.


Well, you're like a unicorn or something.


Oh.


So why are you eating food for seven people, Gary?


No, this is sev- what?


Just, OK.


Just cheese.


OK.


I'm actually losing weight.


Yes, he is.


Yeah, I saw a lot of your recipe photos on Twitter.


They look really cool.


It's not recipe photos.


It's food photos, but sure.


You don't see the recipes.


OK, fine.


I just saw the end result. On Twitter,


it's always hard to judge, like, does this just look good,


or is this actually something that will taste good?


But I kind of trust you.


It depends.


Oh, no.


That's actually interesting.


And it depends.


That's the easiest answer, as with many things in SEO,


because now cooking is also SEO.


So I have some experimental.


Like, my father was a chef.


And what we did in the kitchen was lots of experimentation,


because he had to experiment, and we hated it.


But I also do the same thing.


And now I kind of understand his fascination


with experimentation in the kitchen.


And sometimes my food comes out pretty much inedible,


even though I can present pretty much anything really nice.


And then other times, I just spend like five minutes


on a dish, like sugachi-based soba, or sugachi soba.


And it doesn't take more than five minutes to make,


and it tastes heavenly.


So yeah, it depends.


It depends.


Oh, my god.


It's almost like you can use that for non-SEO answers


as well.


So awesome.


Yeah.


We should make a challenge.


Use it depends more.


I don't know.


Martin, what do you think?


I think it depends.


But I think we can totally do that.


Depending on the situation, you can definitely


use it depends as an answer.


Cool.


So how is it working for you, Martin?


It's a mixed bag.


It depends, actually.


It depends on when you ask me.


So most of the time, I'm doing relatively well.


I use the opportunity that I'm more


at home to do more virtual events, which


aren't as great.


I mean, it depends.


Oh, god.


It depends on the event.


You don't get the same feedback.


You don't get the same interaction with the audience


as you do in an in-person event.


But I think it's still OK to do this, especially


as we are all at home.


I do Twitch streams, which is quite cool.


We once had a doc draft, actually


the one for JavaScript and structured data.


I had the draft pretty much ready


and then just were mulling over a few phrases


and a few ways of formulating things.


And I was just putting it into the Twitch stream.


And then people were giving feedback and asking questions.


And based on that, I was able to improve the draft even more.


So that was kind of cool, so this collaborative side


of things.


I'm planning a few more virtual events


that are a little different from the normal one person talking,


everyone listening kind of situation,


because I think that translates really badly to online.


But hey, we do have the Webmaster Lightning talk,


so that's pretty cool.


I do go biking a lot, so that's nice.


Yeah, I don't know.


But some days, it's just not great.


Let's put it that way.


Yesterday, I had a bit of a meltdown, kind of,


but I'm fine today.


Cool, OK.


Glad to hear that it's better.


I don't know, for me, it's not interacting


with the bigger office or people that you


see when you travel to work.


I don't know.


I find that really hard to adjust to,


but I mean, we've been doing this for a while now.


It's not completely new.


I think the times that really get to me


are more on the weekends, where it's like, well,


I've spent all day or all week at the office,


and then on the weekend, I'm essentially still in the office.


I mean, technically, it's like, maybe I'm not


in front of this computer, but I'm


five meters over to the side.


But it's still all the same place, all the same stuff.


So yeah, I don't know.


Like you, some days it works well.


Some days, it doesn't work well.


I think, in general, there'll be some things that hopefully we'll


be able to keep doing.


But it would really be nice to get back to the office


and see people in person and kind of fight for meeting rooms


and all of the things that you thought were frustrating


are kind of just the, I don't know, different things


happening all the time.


It'd be cool.


It spices up the life, kind of.


So I was just sitting there watching people pass by,


and I was basically learning to lip read


because the waiter was like a kilometer away from the table.


I calculated this yesterday, so I'm actually fairly certain


about that number.


Oh, it's brown caterpillars.


It's not any kind of caterpillar.


I was about to ask which kind of caterpillars.


Yeah.


And I found that super helpful, just getting out the house


and just sitting somewhere where you can see people pass by,


like you don't interact with them


and you are quite far away from them.


It was really nice.


I think that's kind of the lucky situation where


we're in here in Switzerland and probably not


the same for everyone else.


Some people are interacting more.


Some people are kind of isolating more.


It's still going to be a long time.


But on the other hand, a long time


means a lot of podcasts from us.


That's true.


So exciting.


I'm uncomfortably excited.


So cool.


All right.


I think we'll continue to do these and try these out.


It would be great to have feedback from anyone that


happens to be listening to this.


Let us know which kind of things you enjoyed,


what kind of things maybe we could do differently.


If you like the podcast, then of course,


give us a link or a thumbs up or just make it nofollow.


A nofollow link.


Yes.


So you're saying the nofollow link would count just as well?


Don't read too much into it.


Just give us a nofollow link.


OK.


Give us a nofollow link and point other people


to the podcast so that they can listen to it as well.


The podcast should be on all kinds of the usual podcast


platforms where you can get podcasts.


So subscribe to the podcast.


Watch out for the next ones.


And hopefully, if all goes well, we'll


continue to do these on a fairly regular basis.


Especially now that we are stuck at home.


Yep.


And maybe next time, we'll have pop filters and pop music.


Pop filters.


I mean, if they're pop filters, then we can't do pop music.


But we can do pop culture references.


I'm actually in the red when I say pop filters.


Uh-oh.


I just noticed the same, yeah.


Well.


Pop.


Well, our producer will kill me, but that's fine.


OK, so maybe we should take a break here.


Thank you guys for joining in.


Thank you to everyone who's listening to this,


who's linking to this with a nofollow link, of course.


And hope to see you all again in one of the future episodes.


Yeah, yeah, yeah.


Bye-bye.


Bye.


Have a day.


Indexing (JavaScript) comments and much more! | Search Off the Record podcast

Welcome, everyone, to the next episode of Search


Off the Record, a podcast that we are trying out.


Our plan is to talk a bit about what's


happening at Google Search, how things work behind the scenes,


and maybe have some fun along the way.


My name is Martin Splitt.


I'm a developer advocate at the Search Relations team.


And I'm joined here by John and Gary.


You don't see this, but we are waving.


That's fantastic.


Everyone waves into the microphone,


which is a great idea.


Sweet.


So Gary, how is your website coming along?


Why do I always start this?


Oh, I can start if you want to.


But do you want to start?


Do you want to start?


Well, actually, I'm funnier, so probably I should start.


Yeah, so there you go.


Website.


Websites are hard, it seems.


And yeah, I'm on track, I guess.


But I reached a point where I would rather


pay someone to actually create the things that I want


to create rather than developing myself,


because I'm running a WordPress installation.


And it's great, as usual.


But I need some custom plugins, and I'm actually


developing that.


So the idea is that Lizzie, our tech writer,


and I test out things on the website


once we actually published the docs about those features


or structured data or whatever.


And for that, I need some custom plugins.


Like, for example, I can't just use a normal recipe plugin


because there might be a lag between our public release


and how fast plugin developers implement those new features.


So I want to be able to add custom structured data


to every page.


The second thing is that I do want


to have dropdown or an accordion or something where


I say a few words about why I added certain things


to the page.


For example, why I chose this title,


or why did I link to johnmoo.com slash hacking, and so on.


And those take time.


And I was wondering if I should just create,


let's say, an HTML page from scratch for every single recipe


that we want to publish.


And then that would be relatively easy


to add whatever we want to.


But I thought that's perhaps a bad idea.


The second idea was that I actually


create a CMS from scratch, which is not a foreign concept for me


because I did create a CMS, I think,


right before I joined Google.


And that was actually quite great.


And it was working pretty well.


It was based on the Google Docs API.


And basically, you were writing your content in Google Docs.


And then there was a container running on standard web server,


an Apache web server.


And that was pulling in content from Google Docs.


And back in the days, that was quite cool.


And it worked quite fast.


Serving time was under one second.


But then it got more slow, as I imagine more users started


to use Google Docs API.


And at one point, I think the load time for the content


itself, the container loaded perfectly and snappy,


in a snappy way.


But then the content appeared only with a five-second lag,


I would say.


And that was a no from me.


And the second problem was that the website got fairly popular.


And I got an email from the, I think, API team at Google


that maybe I should scale back or upgrade my plan.


And at that point, I think I already


signed my contract with Google.


And I was like, hmm, maybe this is a good time to stop.


GARY ILLYES-SCHREIBER.


Oh, my goodness.


PABLO PARRO.


Yeah, but it was fun.


So yeah, back to the website, or my new website.


It's probably on track, but I like procrastinating.


And this is a good time to procrastinate as well.


And I'm baking cookies for Martin.


MARTIN OMANDER.


Third-party cookies, yes.


So that's more important than the website itself.


Absolutely agree.


The CMS app was right before I joined Google.


And it was one of my favorite projects.


It kind of makes me happy to see that other people also


built their own CMS.


I think I built multiple CMSs myself,


because the first one sucked.


And then the second one was quite nice.


But also, it relied on some third-party service


that then just got discontinued or something.


As they do.


PABLO PARRO.


Fun times.


How did you join, John?


Or when?


And why?


JOHN MUELLER.


When did I join?


MARTIN OMANDER.


And what?


And how?


That was a long time ago.


I think, what was it?


Maybe 2007?


So I don't know.


12, 13 years ago, I forgot how to count.


Something like that.


I think at the time, I was also making my own CMS.


Maybe this is a requirement.


I don't know.


But basically, I had a small software company.


And we started doing more and more things on the web,


as you do.


And I started working on some of these websites,


because it was interesting, something kind of new.


And at some point, I started helping out


in the Webmaster forums, as they were just started.


So I think sitemaps just launched around that time.


And I was active kind of helping people with the sitemap stuff


and trying to give them my opinion on things


they're all doing wrong.


And at some point, I received an email from someone at Google


saying, it would be nice if I would drop by the office


in Zurich, since I'm already in Switzerland.


It was kind of weird, because the email


came to a domain that I don't actively check for emails.


So it was almost accidental that I noticed.


But it was pretty neat.


So I went to Zurich.


I met some of the people from the sitemaps team


who were active in Zurich.


And it was pretty interesting.


It was like a small office, not a ton of people.


And that's kind of the first connection I had there.


And then we set up interviews.


And I learned all of the Webmaster guidelines by heart,


because that's what I assumed I would be asked about.


I flew over to Mountain View, met a bunch of the people


there.


And we had good conversations.


It was really interesting.


And then, essentially, I had to make the tough decision of,


should I keep my own company, or should I


join this big corporation, which at the time


was not as big as today.


But it still felt quite a bit bigger than kind


of running your own company.


And I decided, well, might as well try something new out


for a change.


So I ended up going over to Google and doing stuff there.


I think at the time, there were two other people on the Webmaster


Trends Analyst team, Jonathan and Susan.


Oh, I missed them.


No, they were great.


And I don't know, for a while, we


were pretty much kind of a small team working together


with the Webmaster Tools team back then.


So that was my one chance to say Webmaster Tools and be correct,


I guess.


And we started trying to expand and trying


to find good matches for the team and for Google,


which is kind of hard, because it's a tricky role in that


it's not like a software engineer where


you can test on whether they can do coding properly,


but rather there's some amount of communication,


some amount of guessing and understanding involved.


And I think you, Gary, were also active in some of the forums


at the time, especially the news publisher forums.


And for whatever reason, I don't know, we were in touch.


So at some point, we thought, maybe we could hire this guy.


Yeah, that was a mistake.


That was great.


Yeah, the way we met, actually, was you set up a chat,


I think, and you were trying out things on that chat.


And some of the Bionic posters, some of the contributors


joined the chat, and then we were just chatting there.


Oh, and one thing that I thought was really cool,


sorry to interrupt, Gary, so sorry,


was you set up this cool system on how Google


could index JavaScript pages.


Oh.


Remember?


I remember.


I hated JavaScript back then as well.


Surprise.


And I set up a headless Firefox that


was doing server-side rendering.


Oh, that was a long time ago.


That sucked so much.


I'm shocked.


Shocked, I tell you.


Yeah, it's so weird.


It's like, and then we found someone else to also help us


with JavaScript at some point.


Whoo, Martin.


That was such a weird, weird thing.


I got contacted by a recruiter at some point,


and then Elia reached out to me like, hey,


I saw that you're in touch with the recruiter on this position.


And I'm like, yeah, but I still don't fully


understand the position because it was like web content


ecosystem, and it was really vague.


And I'm like, sounds interesting,


but I'm not exactly sure what's happening there.


And then I asked Elia, and Elia's like, oh, you know,


this is not so much about the web platform and JavaScript.


This is more about search and SEO and maybe news and maybe


a little bit of assistant.


And I'm like, OK, sounds less interesting.


And then I had a conversation with you, John.


And I think we went for lunch because I


was in Zurich at the time, and you all


have also been in Zurich.


And then I asked about the position,


and it's like, yeah, it's a lot about JavaScript


and the web and Chrome.


And I'm like, oh, OK, this is misleading.


This is weird.


And then I asked all of you what a typical day looks like,


and I got the least satisfying response, which was like,


there is no such thing as a typical day.


It can be whatever.


And I'm like, well, thanks.


That's helpful.


And then I was going through the interviews nonetheless.


And then once I got the offer, I was like,


I'm still not sure what the hell I would be doing.


And I figured out that you all were basically super pros


in how Google Search works internally, and I had no idea.


And I couldn't see myself being super helpful in that regard.


So I remember this moment that sealed the deal for me


was when I asked you, I think, either during our second lunch


or after our second lunch, OK, but why me?


And then you were like, because you were a web developer,


and we need to figure out this JavaScript thing.


And I'm like, oh, oh, yeah, that makes sense.


Oh, yeah, that's actually pretty cool.


So yeah, that's how I got my mission


and how I signed the contract in the end.


Probably also a big mistake for you all.


I'm sorry.


GARY ILLYES-SELLSBERG, JR. You're way too optimistic and way


too happy all the time.


It's kind of annoying.


MARTIN SPLITT, JR. I'm kind of balancing someone else then,


I guess.


GARY ILLYES-SELLSBERG, JR. It's a fantastic team.


Don't worry.


MARTIN SPLITT, JR. Yeah.


GARY ILLYES-SELLSBERG, JR. It's like, everyone fits in.


MARTIN SPLITT, JR. That's just like your opinion.


MARTIN SPLITT, JR. I'm super happy to be part of this team.


I like you all.


And it's quite cool that we get to help so many webmasters


all around the world.


That's really interesting.


At least to me, that's interesting.


Maybe I help you with a plugin, Gary.


GARY ILLYES-SELLSBERG, JR. So how is the JavaScript stuff


working out now?


Do you think we have it all solved?


There's like no more bugs.


MARTIN SPLITT, JR. Oh, my.


Definitely not.


The biggest thing I learned in the last two years at Google


is that developers and SEOs are both extremely creative


in building things that don't work in interesting ways.


It's quite fascinating.


Most of the things are fantastic ideas on paper.


And then you implement them.


And then you find out, oh, it doesn't work the way


that you would expect it.


Sometimes that's because the creativity is misplaced.


And sometimes it's because we're just having glitches.


Recently, I think it was on Twitter.


I think Gary made me aware of it.


So someone was asking about Disqus comments, I think.


And that's not something that is very specific to Disqus,


by the way.


It's basically websites using a third party to pull in content


that they care about.


This can go wrong for many different reasons.


In this case, it was a glitch on our side.


We found out what the glitch was, fixed it.


And basically, within a day, we had it back working.


But I think this kind of started a larger discussion


as to how you should do things when


it comes to JavaScript and critical content


from third parties.


Because the challenge is that you, as a website owner,


don't really have control over a third party.


And if you are using client-side JavaScript


to pull in content from a third party in the browser,


things can go wrong.


They could robot their JavaScript API,


and then we can't make the request.


Or maybe their servers are really under load,


and then we decide not to make these requests


to the third party because they are already experiencing


high load situations.


And there are usually ways of doing this on the server side.


So if the third party exposes an API


that you can interact with from the client side,


from the browser with JavaScript,


you can very likely also do that on the server side


and then basically avoid these problems.


Because then your server controls


what happens when in terms of when the data comes in


from the third party.


But I think not as many people do that.


And I would hope that people are warming up


to the idea of doing that instead of doing everything


in the client side.


So is it a bad idea to rely on third parties?


Or is it just you have to be careful?


It's an OK idea to rely on third parties.


You just have to be careful, and you


have to understand that in the browser,


you have very little control over what happens


and how it happens.


And if you are relying on Googlebot


to do the heavy lifting and figure out


how to get the data from the third party,


then you are less in control than when your server does


that work.


Because your server is an environment


that you have control over, hopefully.


That sounds a bit like Gary's problem with the plugins,


where if the plugins are doing one thing


and you're trying to do something slightly


different than kind of balancing the offloading of writing code


to whoever is making the plugin versus being able to choose


exactly what you want to do.


MARTIN SPLITTENBERG Yeah.


And I guess for many people, it's fine.


I think if you are pulling certain pieces of content,


I don't know, like comments or something,


and you don't really think that they are your main content,


then I think it's fine to just go with an off-the-shelf


solution with a third party that may or may not work well


in Googlebot and other browsers.


But if you want to have control over things,


like Gary wants to have control over the structured data


on his pages, then I guess you want


to run that on your server in a controlled environment.


GARY IGLESIASEK-MARTINSENI So Martin, I was taking notes


while you were speaking, and I just wrote down one thing.


And that's, do not use JavaScript, exclamation mark.


Did I summarize right?


MARTIN SPLITTENBERG No, not really.


But I mean, for your point of view, JavaScript is evil.


So I kind of see where that's coming from.


But then I think you can use JavaScript.


It's kind of fine.


But if you don't want to, then don't.


By the way, JavaScript can run on the server side, just FYI.


GARY IGLESIASEK-MARTINSENI Because that's such a great


idea, yes.


MARTIN SPLITTENBERG It's a fantastic idea.


You could hypothetically, so there's


a thing that lets you run PHP in JavaScript.


So you could do that.


GARY IGLESIASEK-MARTINSENI Brilliant.


MARTIN SPLITTENBERG Yeah.


And then there's a thing that lets


you run JavaScript in PHP.


So you could build a fantastic stack.


GARY IGLESIASEK-MARTINSENI Don't give him any better ideas.


GARY IGLESIASEK-MARTINSENI I'm rolling my eyes.


GARY IGLESIASEK-MARTINSENI He already


with a CMS that was built on top of Google Docs, which is built on JavaScript.


So I don't know.


MARTIN SPLITTENBERG It's a great thing.


GARY IGLESIASEK-MARTINSENI No, no, no.


I was actually doing with that what Martin was saying,


that pull the content on server side.


MARTIN SPLITTENBERG Good boy.


GARY IGLESIASEK-MARTINSENI And that actually worked excellently.


GARY IGLESIASEK-MARTINSENI Until things started to slow down.


But that was out of my control.


GARY IGLESIASEK-MARTINSENI That was probably


before speed was a ranking factor.


So you were probably OK.


GARY IGLESIASEK-MARTINSENI Oh, no, you said it, you said the bad word.


Because of ranking.


Is ranking a bad word now?


MARTIN SPLITTENBERG Well, this killed the discussion, all right.


GARY IGLESIASEK-MARTINSENI No, no, no, no.


MARTIN SPLITTENBERG Well done.


So one last thing, Gary, I guess.


With regards to indexing the comments,


because discuss is basically comments from other people,


is that generally a good idea or a bad idea?


Should sites kind of block the comments from being shown,


or should they get them indexed?


GARY IGLESIASEK-MARTINSENI I mean,


it depends on the comments, right?


Like, you can have comments that are super useful and worth


having them in the index and having them help you rank


for certain things, a little at least.


But then you go to certain blogs that are,


I don't want to say that will be R-rated then.


You go to certain blogs, and you read the comments,


and you just want to take a spoon and just eat ice cream.


I don't know, just pop out your eyes or something.


Like, it's just really bad.


In those cases, you probably don't want the comments.


Also, I think we said this before,


but depending on where the content is on the page,


it might weight less than, for example, content


that's in the centerpiece.


Like, for example, if we can detect


that the meaty part of the content is in the middle


and between these sections, then very likely


that that will be the pulling content for your ranking,


meaning that that will help you the most with topicality,


with relevancy, I guess.


And then if we detect that something


is outside that boundary, then that will weight less,


and it will help you less with ranking.


And then you have, for example, footer,


where generally people just put a bunch of links.


We kind of detect that that's not that useful for users,


and so it doesn't help you all that much with ranking.


JOHN MUELLER


OK.


So it sounds like if suddenly the comments of a site


started to get indexed, it's something


that's been going on for a long time.


And then you have a lot of people


who are like, oh, I'm going to clean out all of the comments


and all of my old posts.


It's like, it's OK to look at it, but it's not critical.


GARY ILLYESISIOSAKE LABORDE


Sure.


I mean, there is one corner case where you probably


want to look at it, and that's how many, for example,


F-bombs people drop in the comments


and how R-rated the comments are.


Because if you are writing about cookies, for example,


comments below your recipe that are all of them R-rated,


then that might easily confuse our safe search algorithms,


for example.


And then your content wouldn't do so well


when safe search is on in Google search.


And links just use rel="ugc"?


rel="nofollow ugc", if you want to help.


I would definitely use nofollow just


to make sure that you are following the guidelines


that you learned by heart before you got hired, John.


Thank you.


OK, cool.


Oh, my.


All right.


Well, this was really interesting.


I kind of liked the excursion into understanding


what to do with comments.


I think we can take a break here.


It's been great doing this session with you all.


Looking forward to seeing how your cookies turn out,


Gary, and maybe hearing a review from Martin


in the form of a comment on a blog post at some point.


I'll comment on Gary's blog.


They will be epic.


I will not have comments on my blog.


Then I'll comment on Twitter.


That you already do.


Does Twitter get indexed?


I think so.


Let's not go there.


OK.


All right.


Well, thanks, everyone, for listening in.


I hope you found this useful and insightful and a little bit


entertaining, perhaps.


Hopefully, I'll see you all again, or rather,


you'll hear us again in one of the future episodes.


And until then, bye, everyone.


Bye.


Have a day.


English Google SEO office-hours from May 21, 2021

So maybe it'll start.


Welcome, everyone, to today's Google Search Central SEO


Office Hours Hangout.


My name is John Mueller.


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


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


where people can join in and ask their questions


around their website and web search.


And we can try to find some answers.


Bunch of stuff was submitted on YouTube,


so we can go through some of that.


But it also looks like a handful of you


are already raising your hands.


So maybe we'll just start off with all of that.


I hope you're doing well.


I hope you caught up and had a chance


to take a look at all of the Google IOs stuff.


It seems like there was some pretty neat stuff happening


there.


So I don't know.


I don't have a ton of really super new insights


to the super new announcements.


But maybe I can help if anyone has questions.


All right.


Barry, looks like you're lined up first.


Cool, thanks. I guess two questions on IO, one is, can you


tell us what you like most about the show, like maybe a session


or what you found most interesting about it?


And two, is there anything that you may have not


seen the community discuss that maybe should have been


discussed from the IO event?


I don't know.


I think the parts I found really cool


are, on the one hand, the adventure game, which I thought


was done really well.


And it was almost like seeing people at a conference.


You run across names that you've seen before.


Not quite the same, but it was pretty good.


And the other one is everything around RSS,


where suddenly all of that is kind of back.


And you can follow sites in Chrome and keep up with them,


which I thought was pretty cool.


Excellent, thank you.


You had a second question, right?


Yeah, anything you saw that you didn't


see the community talking about that maybe came up in IO


that wasn't discussed by the community.


Like, I can't believe they missed this announcement or that


announcement.


I don't know.


It's like such a whirlwind.


I'll probably notice in the coming weeks.


But it seems like a lot of stuff got picked up.


I mean, some of the aspects were a bit tricky with regards


to having to record them ahead of time.


You never really know exactly what will happen until then.


But I think some of the cool stuff got announced anyway.


So that was pretty nice.


But I don't know.


The big announcements, it's hard to judge


what people didn't pick up because it


feels like people picked up a ton of details.


Sounds good, thank you.


Sure.


Let's see, Shao.


Hi, Sean, John, sorry.


I have a question regarding to schema markup, data markup,


structured data markup.


So I remember that Google preferred JSON-LD.


But for e-commerce site, it will be quite hard to do so


because the review and the price are always changing.


So it is, to some degree, it's more easy


to use microdata to do so.


However, since Google preferred JSON-LD,


is that a way that we can use JSON-LD and dynamically inject


it without using JavaScript?


Because I remember if we use JavaScript,


there is a possibility that Google Merchant Center


bot do not throw it.


So we also don't want to use JavaScript.


Is it possible to do HTML-based but JSON-LD,


but at the same time dynamic, maybe some fancy PHP?


Sure, I mean, you can use anything


that runs on your server, essentially,


to generate the HTML.


And that can include the JSON-LD like that.


I mean, that's usually how, I mean,


I haven't taken a look at the details.


But my assumption is that's how most e-commerce sites do that,


that they look up the database information, the pricing,


the availability, and they put that


into markup in JSON-LD or microdata or whatever format.


And I think the part with our preference


there is mostly along the lines that oftentimes people


externally just want, like one preference.


Like these are multiple options that you can do.


And we recommend using JSON-LD because it usually


makes it easier for sites to implement.


But that doesn't mean that there is any less value passed


with the other types of markup.


So if whatever feature you're looking for


supports that type of markup and that's what you want to do,


then go for it.


I wouldn't say you need to do Google's preference.


Because usually people just come to us and say,


oh, you have two or three options.


Which one is the best one?


And if we just say, oh, I don't know,


just figure it out yourself, then everyone's like, oh,


I won't do anything.


But if we say, oh, we really like this option,


then it's a lot easier for them to say, OK,


I'll just start and do that.


AUDIENCE MEMBER 1 So by Google prefer JSON-LD,


the preferential is actually not that significant.


They basically judge the three formats practically equally.


Would you say that?


Yeah.


I mean, if the feature that you're looking for


is available in those different formats,


then they're completely equivalent.


It's not that we would give any special treatment to JSON-LD.


I see.


Thank you.


Cool.


All right.


Fabrizio.


Can you hear me?


Yes.


Hi, John.


Hi, everybody.


Fabrizio Ferraro, virtualshadymusic.com here.


John, we had a quick chat a few weeks ago


about this image and image search related issue we


got on our website.


And I wanted to know your thoughts about it personally.


I also discussed with Glenn Gabe about this.


And I know that he's very interested in your thoughts too.


So on March 23, we changed the source URLs


of our main image on our product pages


to a new optimized image.


And the previous image was supposed


to be used for high density devices


to be set inside this source set attribute.


Fact is that we forgot to implement that.


And after two days, we had a drop of 30% traffic


for image search.


And we didn't realize that then after four weeks.


So after four weeks, we added the source set tag attribute.


And so we are still hoping to have our traffic back.


But after two months, that's not happened yet.


So I wanted to know from you, is it just a matter of time?


Or is there anything else we can do about it?


I don't know.


It feels like two months is a pretty long time.


But especially since you mentioned


these are product pages, it sounds like an e-commerce site


in that case.


And you're looking specifically at traffic from image search?


Yeah, because we got a 30% drop on image search.


But consequently, we had also something like 5%, 10%


drop in traffic from regular search because of that.


No.


So it's possible that the two months time there


is just the time that it's still taking to catch up


with a larger site.


One thing you could do is maybe send me some details.


And I can look at that with the image search team directly.


I would also double check the details on your side


with regards to which image URLs are actually


shown in image search.


Has it picked up the change in image URLs?


I still see that they're all the images.


But it looks like they dropped in rankings for some reason.


And I think it's related to that because that happened


two days after the change.


Two days is a really short time.


Because if you're looking at an e-commerce site,


then if we recrawl the different products,


my guess is you, depending on the site,


it'd be in the range of two or three weeks for us


to recall a bigger e-commerce site or even


a medium-sized e-commerce site.


So if you're seeing changes two days after a change


that you made, that feels like it


wouldn't be related to that.


So well, that's amazing because we had that kind of traffic


for years.


And then we made this change.


After two days, we dropped 30%.


And we didn't do anything else than that


around that time frame.


And so I don't know.


Then Gabe also suggested that was directly related to that.


But I wanted to hear from the source.


Yeah.


You're welcome to send me some examples.


Sure.


If you're seeing a strong change across a larger


part of a website within a short period of time,


then that doesn't feel like it would


be related to something technical on the pages.


Unless it's your home page.


And suddenly your home page is not showing any more.


Then you'd see a big change immediately.


But for a larger set of product pages,


each one individually has a small change,


you would see a gradual decline.


Right.


But in case that was the case, should Google


pick up the updated version with the source set


defined and fixed things later on?


Is that something that should happen?


If it's really just related to a change of image URLs,


I would expect that to happen over the course


of a couple months.


But two months is kind of like I would expect


to see some effects by now.


But to me.


Sorry.


Actually, it just passed a month since I put the source set tag.


Yeah.


So maybe I still need to wait.


I mean, to me it sounds more like maybe a quality change,


where our algorithms are overall kind of re-evaluating


the quality of your website.


Because that's something that could happen from one day


to the next.


And I wouldn't see this as something


that's tied to a technical change across a lot of product


pages.


OK, I see.


All right.


Thank you very much.


I'll save you some details.


Thank you.


Promotash, I think.


So I got your name right.


Hi, John.


Hi.


Yeah, yeah, you got my name right.


Actually, you were the first person to get my name right


on the first instance.


Oh, wow.


Cool.


So actually, I have some basic questions


that I have asked many people.


But I am unable to get a straight answer.


OK.


OK, so I have a few questions.


Like one is, suppose I have a WordPress blog in which I have


created some tags and categories.


So what happened?


Now I want to delete those tags and categories.


These tags were created for some post,


but these tags don't have any backlinks.


And these categories also don't have any backlinks.


And if I delete, what will happen?


Like Google will down my rankings, or it will not?


So just because there are no external links to those pages


doesn't mean that Google would not be able to find them.


So that's kind of the first thing,


because especially if you have posts that have tags


and categories on them, then you have links from the posts


to the tags and category pages.


So what I would look at there instead of external links


is how those pages are currently being shown.


So in Search Console in the Performance Report,


look at the individual tag and category pages,


or kind of like the group of those pages.


And then based on that, you can make a decision,


can I just delete these pages?


Do I need to redirect them or not?


If there's almost no traffic or no visibility of those pages,


then cleaning that up is perfectly fine.


OK.


On the same question, I have another question.


I have been using some SEO tools which suggest that I


should create canonical links.


Suppose there are two tags and there is a post,


so it is better to direct all the tags and the post


to the same canonical link.


So is it correct or I should not do?


We usually recommend using the canonical link element


when you have multiple URLs for the same content.


And it sounds like these are different pieces of content,


like the category page, the tag page.


Suppose I create a, suppose it's an example.


Suppose my post is dog food.


So I have a tag called dog.


I have a tag called food.


And there is a category called animal.


OK.


Or pets, there is a category.


So now I want to delete pets plus food and dog


because I want to create some different tags or categories.


So you already gave me, like, I have to group and check


after that.


So if, like, suppose, let's take an example of WordPress using,


which we can define the canonical links.


So while testing the SEO, SEO for readability and SEO,


we find that it shows, like, within the tag also,


you have to create some content.


Or within the category also, you have to write some content.


Because if I check on any SEO tool,


it will suggest that your tag is empty.


You need to create content.


Again, the problem is, like, I am unable to reproduce


the same content.


Suppose I have a content called food,


and I have tagged it for dog food.


And the food is a generic term.


And how can I write the content for, like, dog?


Canonical will also not work.


I have to, again, if I create a tag,


then Google will expect that I would write around 500 to 800


words.


So I guess a couple things.


Just to add, do you think, like, tags have an importance?


Like, if the tag should have a proper content,


like 500 keywords for a tag in WordPress?


We don't count the words.


So I would not look at the word count


and say it's like it needs to have this much content.


Usually, what I recommend doing is


looking at the tag and category pages


more as kind of groupings of categories of things.


So if you have a lot of posts about different kinds


of pet food, then making a category for pet food


makes total sense.


However, if you only have one post about dog food,


then making a category for dog food is kind of like, well,


it's the same thing.


It's not a group of things or a category of things.


So that's something where I'd say, well,


probably you don't need that.


But purely from an SEO point of view,


I would try to minimize the number of pages


that you create across your website


and try to make sure that for all of the pages


that you do have that you have significant content there.


So if you're saying this category dog food doesn't


have anything unique on it, then maybe you


don't need that category.


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


It's not that we would penalize a page if it's a category page


and there's just one item there.


It's more that you're diluting the value of your website


across a lot of unnecessary pages


that you could concentrate and make your existing important


pages more stronger.


OK, so I can hardly hear you.


It's very broken, the connection at the moment.


Oh, no.


I just hear individual short pieces of sound.


Or maybe you can type the question in the chat,


and I can get back to you afterwards.


OK, maybe we'll just move to the next one first.


And like I said, if I see your question in the chat,


we can get back to that.


Ratnesh, you have a question?


We can get back to that.


Good evening, John.


So it's the first time I'm talking to you, and thank you.


So I have a couple of questions.


I'll go by one by one.


So the first question is, my website


is 100% Core Web Vital past, and all the URLs


are Core Web Vital valid.


Now I want to restructure my site.


Restructuring, I mean to say that I


want to change the URL to the better SEO-friendly URL.


So earlier, a lot of subfolders were present,


and a lot of subdirectories were present


for the primary content, which we want to rank organically.


So my first query is now I have already changed the URL.


So will the Core Web Vital metrics,


whatever exists for my pages, will


be passed to the redirected URL?


This is the first question.


That should be the case, yeah.


Because those pages are entirely different,


like page X is in folder XXX.


Now there is a new page which is not under folder,


but now we have a redirect.


So the Web Vital score is directly


captured from the Chrome User Experience Report.


So users have not opened the page.


So do you think that Core Web Vital benefits,


whatever captured in the Google Webmaster, will be passed?


My understanding is that they would be.


Like any other signal from search, if we see a redirect,


then we would forward the signals that we have


and apply them to the new URL.


And it doesn't matter so much if the URL looks different.


It's more that you're moving from one URL to another URL.


But I would expect this kind of a change.


Whenever you're doing a restructuring of a website


internally, especially with changing URLs,


I would expect that to be something


where you would see fluctuations in search,


maybe for a month or two.


OK, fine.


I got the answer.


So I'll go with the next question.


So my next question is, like, suppose I have a website


and I have only 100 pages indexed.


So Google will capture the CUX report, Chrome User Experience


Report, only for those index page by the Google


or for all the pages which are even not indexed by the Google.


So in general, Chrome would be collecting this data


on a per-URL basis and be using the usual anonymization


techniques, kind of what is used with the Chrome User Experience


Report data to collect that.


And then how that would be applied to your website


in search would essentially try to be done on a per-URL basis.


So you might have 1,000 pages in total.


And if 100 of those are shown in search, then for those 100


that we would show in search, we would use those 100 pages


and their signals.


We wouldn't really use the other 1,000 pages that you also have.


I got your answer.


Thank you.


So my third question is, like, I have a page where


I'm putting, like, tag lang equal to en, English,


in the meta tag I'm marking that language I'm using is English.


But I have other content also, like in Spanish or French


or something which is in non-English.


But I'm not making this adding the tag, meta tag lang


equal to French or something like that.


So will my non-English language content


will be used by Google for ranking factors,


or it will be considered, like, OK, I have other content also


which is in non-English language,


and I still want to rank?


Without that, what's that?


I mean, if we find internal links to those pages,


we can crawl and index those pages.


And it's something where, like, if we have links there,


we will crawl and index those pages.


We don't use the lang meta tag on pages,


but rather we try to understand which language a page is


in based on the text.


So if you have content in different languages,


we'll try to find that and show that in search appropriately.


And then it will be used for ranking,


because it could be shown in search.


OK, so the last question I have is a little bit more related


to the schema.org, not last, second last.


Content not adding any value to the content system or the web


system, or not even adding much value to the content or the user


experience.


So what we have done, like, we have done a lot of hardware


from almost more than two years to think on that.


And we have added a lot of schema.org, JSON-LD,


whatever required, like FAQ page.


And we have captured almost most of the things which


can add value to the users.


When forgetting about whether we are going to get traffic


or not, we have considered that, OK, the user experience,


and it should add the benefit.


Like if user is browsing our site or browsing our page,


let him benefit from the site first.


So considering that, like, I have a page,


like I am listing a Walmart sale event.


So the sale event, like, they can have n number of sale event,


like Black Friday sale, or New Year sale, or Christmas sale.


So can I have a page on my site where I list all the sale


events, and can I also mark them with the sale event schema?


Is that allowed?


Because I have seen on the Google,


like, we should not add a markup,


and it can bring down our ranking


and can penalize if we put a wrong schema or something


which is not misleading the user or the system.


So the question is, like, I'll summarize.


I want to list down the sale event for a particular merchant,


and I want to mark those sale events.


Like, what is the sale event name, like, say, Black Friday?


What is the time period of that?


I just want to mark them in the form of schema.org.js on LD.


So is that fine?


Should we go ahead and make this change?


I don't know offhand the requirements


for that type of markup.


My understanding is if you're using the event markup,


that would not be suitable for this.


And in general, the structured data on the pages


should be applicable to the primary type


of content on the page.


So I suspect listing a bunch of events


from one vendor on a single page and marking that up


would not be in line with the guidelines for structured data


on our side.


But I don't know all of the guidelines by heart,


so I would recommend checking out the documentation


and just double-checking before you implement it.


Also, keep in mind there's a lot of structured data


in schema.org which we don't necessarily show.


And search.


So it might be that the sale event, structured data,


I'm not aware of it.


It might be something that we don't even use at Google.


OK, fine.


I'll double-check the standard.


So the last question is, what is the importance and significance


of making page as a corner store content?


How do you mean?


I didn't quite understand.


I mean, in the plugin, like SEO Yoast plugin,


we can mark a post as a cornerstone content.


Cornerstone.


I don't know.


That sounds like something specific to the plugin.


OK.


The thing is, I mean, we are still


like we have followed the best practices


in considering the user experience


and adding the best content.


So we are still struggling with some traffic.


So if we can get some pointers, like what


is causing the issue with our site or something?


Like what is exactly making our site


to struggle to rank organically instead of like after we


have put a lot of efforts?


Yeah, I don't know.


It feels like something that's kind of out of scope


for the office hours here.


My recommendation there would be to go to the Search Central


help forums and post some of the details of what you've seen,


some examples from your website with URLs,


and try to get advice from other people there.


You probably won't find like this one thing


that you need to do to improve your ranking,


but they might be able to give you advice and say,


oh, it looks like this is just a collection of affiliate links,


or it looks like there's not enough content actually


on these pages.


And I think that's the kind of input that can be quite useful.


Yeah, thank you, John, for all the answers and long questions.


Thank you.


Sure.


Let me run through some of the submitted questions,


and then I'll get back to all of the hands that


are raised as well, just so that we don't lose


track of the submitted things.


Let's see, we have different types of pages on our site,


contract pages, vendor pages.


We recently released product pages and category pages.


After our release of product pages,


we saw meaningful site traffic decrease


as product pages were being frequently


ranked above supplier pages.


Any tips on how to indicate to Google what product pages are


less relevant than other types of pages,


other than de-indexing our product pages?


Yeah, it also mentions the priority in the site map.


We don't use the priority in the site map file.


We originally, I think we thought


that would help us to figure out which pages to crawl more


frequently, but it turns out not to be that super useful.


With regards to a general website


where you have different types of pages


and you want to have one type of page kind of ranking


above another one, there's no HTML markup


where you can kind of specify this


is my most important type of page


and this is less important type of page.


But what you can do is create the web structures such


that Google will recognize which pages you care about most.


In particular, for most websites,


we tend to look at the home page as something


that's the most important part of the website.


And from there, we see kind of the links


that lead out to the rest of your website.


And then kind of all of those individual steps of links,


like going to the first step and then going from there


to the next step, all of that essentially


gives us a little bit of a guidance


on what you consider to be the most important part.


So we'll start with your home page, and we'll think, well,


the most important pages you probably


mention on your home page.


So we'll go off and crawl those and try


to give those also a little bit more weight in the search


results.


And from there, we'll go to the next pages.


So if you have a structure where you have category pages,


subcategory pages, and then product pages,


and they're kind of linked like a tree structure from there,


usually we'll see kind of the category pages


as being kind of more important and kind of less importance


as things kind of fan out a little bit.


And you can also control that a little bit yourself


in that you could kind of individually take


individual products where you say,


so this is my most important product.


Either maybe it's a new product, or maybe it's


a product where you sell a lot of things,


or where you have kind of a high ROI on the specific products,


and you could specifically mention those on the home page.


So when we crawl your site, we'll see, oh, category pages,


but also these five products are mentioned on the home page.


Therefore, those five products must be really important.


And you can apply the same thing with your specific kind


of site structure there.


So take the URLs that you care about the most,


make sure that they're linked from kind


of the root of your website, and then from there,


think about what the structure for the rest should be.


And especially if you have kind of like a medium


to large-sized website, that's something


you can probably pull together fairly nicely.


If you have a smaller website where you have like 10 pages


and they're all equally important,


then it's a lot harder for us to figure out


which one of these pages is actually


the most important for you, because they're all usually


all linked together anyway.


But it sounds like you have kind of a structure


where you could tweak things a little bit.


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


My website has limited traffic within a threshold,


and I didn't get a notification in Search Console


about page experience.


And I couldn't get any field data


from any of the tools, like PageSpeed Insights or Chrome


User Experience Report.


Just wondering how to find the field data of the website's


benchmark and work on that.


So yeah, I think this is a super important question,


because we do use the field data as essentially the metric


that we would use for search.


When we start rolling out the page experience


update for rankings, we would base that on the field data.


And if your website doesn't have any field data available,


then of course we don't have anything to work on.


But that doesn't mean that you don't have anything to work on.


On the one hand, you have the different lab tests


that you can use to try to figure out which pages you


need to work on most.


On the other hand, you can also use snippets of JavaScript


on your pages directly and collect the field data


yourself.


And by collecting the field data yourself,


you also go around that 28-day time period of the time


that it would take for Google to collect the data


and show it to you in Search Console as well.


So that's the direction I would go there.


On the one hand, use the lab tools to test immediately.


And then if you really need or feel


the need to collect field data, even though your website


doesn't have a lot of traffic, then


make sure to implement those scripts on those pages


to collect the field data for yourself.


There is, I think, an article on web.dev where essentially it


uses, I think, analytics to collect the field


data on a website.


So that might be an approach you could take.


A couple of months ago, I used the Yoast video plugin


to submit a video sitemap for my recipe site.


Since then, I've seen a dramatic decrease in click-throughs


on my recipes.


My rank itself has stayed the same,


and impressions are about the same.


But now in mobile, I'm seeing recipe videos


start autoplaying a few seconds in the search results.


I'm wondering if that is contributing


to the drastic decrease in click-through rate


So that was a little bit more in the question.


But essentially, I think there are a few parts here.


On the one hand, it is possible that if your site is being


shown in a different way in the search results


that people are interacting with that slightly differently.


It could be that, especially if you have a video snippet shown


in the search results, maybe they look at the video


and they say, oh, this isn't actually what I was looking


for, and then they tend not to go to your site.


They could also be looking at the video snippet and saying,


oh, this is exactly what I was looking for.


And then actually go to your website.


So that's something where, based on the content you


have available, you can kind of control that a little bit.


The other thing with regards to video site map and the video


snippet in general, there is a robots meta tag


that you can use to control whether or not


you want to have a video preview shown for your pages.


And if you do want to have a video preview shown,


how long that preview should be.


So that's something you can control there.


The other thing is with regards to kind of removing that video


snippet completely, just removing it


from the video site map file won't necessarily


remove the video thumbnail.


So essentially, if we spot a video on a page


and we think this is a relevant part of the page,


we can still show that video thumbnail in the search results.


I think you can suppress that with the robots meta tag.


I'm not 100% sure offhand.


But essentially, if you want to make sure


that we never show a video thumbnail for your pages,


then removing the video is kind of the right step there.


So those are kind of the different options there.


My general recommendation here is


if you're seeing a decrease in traffic to your site


based on that video thumbnail, then I


would consider that maybe this is also a sign that you need


to improve that video so that it actually


is a better representation of what you're providing


on your pages so that users look at the video


and say, oh, this is actually fantastic,


and then go off and look at your site.


So that's, I think, kind of the long-term recommendation


that I would take there.


I wouldn't just blindly say, oh, people


see that my pages aren't that great,


and then they don't come and visit.


But rather, I kind of use that as a kind of a nudge


that you should increase the quality of those videos


and the content too.


Why does the crawling request for my home page fail?


This has started happening in the last two weeks.


I don't know.


I'd probably need to take a look at the individual URLs there.


And this is probably also something


that could be done in the Help Forum


if you don't have a way of kind of giving me those URLs


directly.


Essentially, in the Help Forum, the folks there


have a lot of experience with different kinds of website


issues, and they can probably help you to figure out,


is this a technical problem?


And if so, where could it be coming from?


And they can also recognize when it's


an issue that's on Google's side or probably on Google's side


and escalate that to the Google team that


is kind of monitoring the forums.


Are Google currently testing a new search result layout


for local businesses on mobile?


We're seeing instances of the Google My Business listing


showing for brand search in top position.


Then there's no organic listing underneath.


I don't know what is happening with local search results.


I'm not involved on that side at all.


That's usually kind of more something on the map side.


So I honestly don't know.


I have seen some tweets about changes in the kind of Google


My Business search results.


But I don't know what is actually happening there.


And with regards to testing new layouts,


I would go with the assumption that Google is always testing


and always trying to figure out better ways of showing


the content in the search results.


We've been previously told that the impressive organic


visibility growth of domains at Google


has nothing to do with its owner and the fact


that the folks who work on SEO at Google


almost have a disadvantage compared to other people.


And then it goes on into a fairly long discussion of,


why is this website ranking like it is?


I'd love to kind of dig into this


and give some more input here.


But in general, we don't talk about why other people's


websites are ranking the way they are.


But rather, we try to focus on what


you could be doing to improve the visibility


and the quality of your own website.


So just kind of like, why is this website ranking like this?


Why are they shown like this?


From my point of view, not particularly useful.


I'd rather kind of focus on individual websites themselves


and try to give some input on what


you could be doing to be appearing differently there.


I want to add a page on my site where I list all sale events.


Oh, I think we talked about this one briefly.


My crawling has been slowed since the new Search Console


was launched.


I see sites take longer now to index.


A new site could take two to three days versus the minutes


with the older Search Console.


Also, is there any way to limit the amount of interactions


you can have with Search Console?


The limits seem to be unseen also.


Where can you see your daily credits?


So I think there is some confusion with the question


itself in terms of Search Console is essentially


mostly a reporting tool for what is happening in search.


It doesn't control what is happening in search.


So it's not the case that when a new Search Console is launched,


then all of Google's search systems are changed.


But rather, the new Search Console is kind of a new UI,


uses new systems, and then it's kind of a new UI


uses new systems to display information about your site.


And if you're seeing changes that were crawling your site


slower than before, then that would not


be related to Search Console.


So that's, I think, the most important aspect here.


With regards to limiting the interactions


that you can have in Search Console,


I'm not aware of any limits like that.


I could imagine that if you use a script to automate Search


Console that at some point our kind of denial of service


and abuse systems will kick in and just say, whoa,


this is not the way that Search Console was meant to be used.


But essentially, for normal interactions,


there's no limit or credits that you


can get with regards to how to use Search Console.


Let's see.


We're still experiencing a canonical issue


with our international sites.


Currently our page so-and-so is indexed and canonicalized


to the DECH version.


I have no errors in Search Console for my hreflang site


maps, but I do find the URLs in duplicate submitted URL not


selected as canonical session.


Is this a bug?


Is there something I can do to fix this?


So I'd probably need to take a look at the examples.


The example is what exactly is happening here.


But it looks like one URL is the German for Germany version,


and the other one is a German for Switzerland version


of the same page.


And what often is done across websites


that target different versions of the same language


is that they use the same content.


And I don't know if that's the case here.


But for example, what we would often


see is that a page in German for Germany, Austria, and Switzerland


might have exactly the same content.


And in a situation like that, our systems


would try to recognize that.


Even if the pages are only mostly the same,


we would try to recognize that and pick one of these URLs


as the canonical for indexing.


The advantage there is that it's a lot easier for us


to focus on one URL rather than to focus


on three separate URLs.


We can recrawl, reprocess that one URL a lot faster


than we can three individual ones.


In practice with the hreflang annotations on those pages,


what would happen is that we would still


process those hreflang annotations,


and we would still be able to replay those URL changes


in the search results.


So practically speaking, we would


index one of these versions as the canonical.


Then if a user from the other location is searching,


then we would swap out the URL that is shown


based on the hreflang annotations.


So practically speaking, the hreflang would be working.


Technically speaking, we would be indexing just one version.


And I think the most confusing part of all of this


is that Search Console tries to be smart about this


and focuses on the canonical URL so it doesn't report to you


that we're showing these different language


or these different country versions to users.


So in the performance report, you


would only see performance data for the canonical.


In the indexing report, you would only


see indexing data for the canonical.


And for the other country versions,


you would see what you're seeing there is that it's a duplicate


URL, and we picked a different one as a canonical.


So that makes it a bit tricky.


What I recommend doing in a case like this


is just searching with those country settings.


So I use the hl equals for the language parameter


and gl equals for the country parameter and the URL


parameters when searching.


And search for something like, I don't know,


some title from the page.


And then just double check to see that it's actually


swapping the URLs.


And if it's swapping the URLs and everything is fine,


it's like the reporting side is completely messy and hard


to trust.


But at least from a search point of view, it's working well.


And if you need to change that so that we absolutely index


these versions individually, then they absolutely


need to be different.


And it needs to be something where when our systems look


at these pages, they can say, oh, this is really


a completely different page.


And then we'll index them individually.


We'll report on them individually, all of that.


From an SEO point of view, you're


not going to get any advantage by having completely


separate URLs indexed.


It's really just like the reporting side


is a lot easier if we index them individually.


OK, let me see if I can find something short here.


We operate an online reading platform for books.


When you search for a book, book schema for Google Search


can pull up the book in a section below the Knowledge


Graph on the right-hand side.


To submit the books, you need to implement the schema


and submit your books through a form to a team at Google.


We followed all the documentation,


submitted a number of times, but we haven't had any progress.


What can we do there?


Yeah, so especially for some of the newer or less used


features, we tend to have this set up where you submit


your site, and then someone at Google


will take a look at that and see if it's aligned.


And if everything is OK and we're still


adding new sites to that part of Search,


then we'll kind of activate that for that site.


But I guess there are two situations where sometimes that


doesn't work that directly.


On the one hand, if there's not a big team that


is working on this feature at the moment,


then maybe they won't be processing those submissions.


On the other hand, if there is work


being done to activate this across the board


so that anyone can use this markup,


then sometimes they just wait until they can actually


launch that kind of fully open version of that setup.


But if you want, if you can give me maybe some sample URLs,


maybe some information about what you tried to submit there,


I can try to find a team internally and pass that on.


I can't guarantee that they'll be able to activate this


for your site, but I'm happy to let them know,


oh, this site has been trying to get into this feature


for a while and hasn't had any response so far.


OK, kind of running low on time, but maybe I'll


take a couple of live questions.


And then, like the last couple of times,


I'll hang around a little bit more to answer more


of your questions after recording stops.


Let's see.


Ibrahim, I think you're next.


AUDIENCE 1 Hello, everyone.


So we are one of the big pharmacists in Switzerland.


And recently, we gained about 300 to 400 spammy backlinks.


Most of them are hosted by Blogspot.


So my question is, do you recommend


me to disable them in Search Console or no?


Just let them go and just, yeah.


I think if you're a big site and you're


seeing a couple hundred kind of spammy links,


I would just ignore them.


So it's something where if you know that in the past


you've kind of bought links, then that's worth kind


of disavowing.


Or if you look at it and you say, anyone from Google,


when they look at this, they will think,


oh, I bought these links.


Then that's worth disavowing.


But if these are random blogger links


and they're just spammy weird blogs that


are linking to your site, I would just ignore them.


AUDIENCE 1 They are weird spammy backlinks.


So thank you so much.


AUDIENCE 2 Sure.


AUDIENCE 1 Amazing.


All right.


Tom.


You've already answered my question, John.


I was the online bookstore.


So thank you very much for that.


And I'll put something together and I'll get in touch.


Cool, fantastic.


Pavel.


AUDIENCE 3 Hello, John.


Hi.


Just a quick question, actually.


So I'm here with PocketPills.


We are one of the biggest online pharmacies here in Canada.


We serve the whole country.


And we are debating this question,


which I've tackled as well before.


I know you probably have covered,


but I wanted to bring it up once again.


So it is very interesting for us to be able to obviously target


the term, for instance, online pharmacy


plus a particular geotarget or province or city,


such as maybe Ontario, British Columbia, or whatnot.


So the question here is really, should we


aim to have separate landing pages for each province


and potentially each city?


Or should we just stick to our main home page, right?


The issue here is, of course, from the data


that we see coming in from our current existing users,


people might benefit from having some dedicated content


specific and tailored to their particular specific location.


Some medications are more popular than others


in different areas of Canada.


And so we really want to serve the user in that way.


And that's what we thought about separate landing pages.


But at the same time, of course, we


are concerned about keyword cannibalization.


So could you give us any input on that?


Now, I think the aspect I would worry about more


is doorway pages, kind of everything around.


I don't know how many provinces there are in Canada.


So I feel like I'm missing some crucial piece of information.


But if this is something along the lines of, I don't know,


a handful, maybe, I don't know, up to 20 things,


then that feels like something where maybe that makes sense


to have individual pages for that,


especially if you know that there


are individual guidelines for these individual provinces,


for example.


Then that's something where I'd say, well,


maybe it makes sense to have something for those provinces,


for kind of like a global company,


where you're really saying this is actually


unique information for people in that province and information


that they need, and not just popular products


from your region kind of thing, but rather actually something


useful from that.


On a city level, I think that's going almost way too far,


because then you suddenly have hundreds or thousands


of these pages.


And you can't realistically provide unique guidance


on a city level if you're a kind of a global or countrywide


company.


So that's something where I'd say


if you end up with, I don't know, 10, 20 different versions


of these pages, that seems like something reasonable.


If you're going way past that, then you're


essentially going into the area of doorway pages, where


you create a lot of pages.


Maybe they map to individual keywords,


but you're diluting the value of your site


on the one hand, which means kind of like the bigger mass


that you already have built up is kind of diluted,


which means if there's a lot more competition,


I imagine there is, then that makes it harder for you.


It's easier to rank for some random city name plus pharmacy,


but then kind of like the head terms,


you kind of really lose out there.


And by also not diluting it too far,


you avoid the risk of being seen as having a bunch of doorway


pages as well.


Perfect, John, thank you so much.


I have another quick question, if you don't mind.


And this is regarding, I don't know,


this topic has also been covered as well before.


I'm bringing it up once again.


And it is the matter of how to handle on-page citations.


And this is just to give you a specific example very quickly.


We sometimes have to reference certain details


from the manufacturer or pharmaceutical


that we get pretty much our medications from.


And so we obviously would like to provide a link and a source


to our visitors so they can always go back and check


the manufacturer's details.


So the question here is, how should we


handle these citations on our page?


Is it best to have them, for instance,


obviously using something like Chicago-style?


So I mean, at the bottom of the page, perhaps, food noters,


right?


But should they be follow link attributes?


Should they open on a separate tab?


Should they open an existing tab?


Should they be in an accordion?


Should they not be in an accordion?


How do you suggest we handle those?


Thank you.


So from an SEO point of view, I would make these normal links,


so not with a no follow.


Because it's essentially information


that you're providing.


So as long as those are not affiliate links,


then it's not that they're paid links.


It's more information that is organically


provided within your website.


And how you structure that within your website


is more something I would look at from a user experience


point of view and maybe do some tests with users


to see which way works best for them,


how they can best recognize that these are useful links,


these are authoritative links because they're


from the manufacturer, and all of these subtle details.


From an SEO point of view, I don't


think it matters if they open in the same tab or a different tab


or if you have an accordion or whatever.


It's really more the user side that I would worry about there.


Perfect, OK.


I wanted to add to a previous answer you brought up,


because I think it actually might


be helpful for everyone here.


And it was the notion of, for instance,


sometimes adding, of course, category pages


to your home page or perhaps the most important products


that we would like to feature right on our home page.


So this is something that we experience quite frequently,


because we may add new medications onto our product


catalog.


The issue or the question we have here


is sometimes swapping out, for instance,


some of the feature products on our home page


in favor of having some of the newer products


that we add to our catalog for us to get them indexed first,


of course, and then ranked by Google as well.


Would it somehow dilute then perhaps even the ranking


or the credibility of the previously submitted


important products as well that we actually


have on our pharmacy?


Could you give us some input?


Yeah, I mean, if you change the structure of your website,


then we'll try to reflect that in search.


So if you previously said, this product


is one of the most important ones,


it's linked from the home page, and you remove that link,


then suddenly we say, oh, it's no longer


one of the most important ones.


We will still be able to crawl it, because probably it's


still indexed.


We will still be able to find it and update it.


But we'll kind of say, well, it's


not one of the most important ones anymore.


So with that in mind, usually what I see on e-commerce sites


is that they have different sections in that home page area


where they say it's like the most popular products, newest


products, something like that.


And that kind of works for users,


because they go to their home page and see, oh, new products.


I'll take a look.


And it also works for search engines,


because we can pick up, oh, most popular,


and we can also see kind of the newest products as well.


I see.


Perfect.


Thank you so much, John.


I'd like to give more time for you guys as well.


Thank you.


Cool.


OK.


Let me take a break here with the recording.


And I'll be around a little bit longer


so we can continue to chat.


But kind of make sure that the recording


is a reasonable length.


Thanks for all of you who are watching


this recording afterwards.


I hope you find it useful.


And maybe I'll see some of you in one of the future Hangouts


as well.


All right.


Bye for now.


Google Search News (Jan ‘21) - crawling & indexing updates, link building, and more

Hi, everyone, and welcome back to the Google Search News


series.


I hope life is treating you reasonably well wherever


you are.


I'm your host today, John Mueller, here from Switzerland.


With this show, we want to give you


a regular summary of what's been happening around Google Search,


specifically for website owners, publishers, and SEOs.


If you find these useful, which I hope you do,


and if you'd like to stay up to date,


then make sure to subscribe to the channel.


I hope your year both ended well and is starting off well.


What a unique year it was, right?


If you're watching this in the far future,


then first off, congratulations for making it that far.


And secondly, as you can see, in early 2021,


we're still recording from home in Switzerland.


In this episode, we'll be covering some neat new things


around the foundation of Search, namely crawling and indexing,


as well as another relevant part of Search, namely links.


If you're curious to find out more, then stay tuned.


As a bit of background, crawling is


when Googlebot looks at pages on the web,


following the links that it sees there to find other web pages.


Indexing, the other part, is when


Google systems try to process and understand


the content on those pages.


Both of these processes have to work together,


and the barrier between them can sometimes be a bit fuzzy.


Let's start with news about crawling.


While we've been crawling the web for decades,


there is always something that we're


working on to make it easier, faster, or better


understandable for site owners.


In Search Console, we recently launched an updated


Crawl Stats report.


Google Search Console is a free tool


that you can use to access information


on how Google Search sees and interacts with your website.


This report gives site owners information


on how Googlebot crawls a site.


The report covers the number of requests by response code


and the crawl purposes, host-level information


on accessibility, examples, and more.


Some of this is also in a server's access logs,


but getting and understanding them is often hard.


We hope this report makes it easier for sites of all sizes


to get actionable insights into the habits of Googlebot.


Together with this tool, we also launched a new guide


specifically for large websites and crawling.


As a site grows, crawling can become harder,


so we compiled the best practices to keep in mind.


You don't have to run a large website


to find this guide useful, though.


We'll add a link in the description if you're keen.


And finally, still on the topic of crawling,


we've started crawling with HTTP2.


HTTP2 is an updated version of the protocol


used to access web pages.


It has some improvements that are particularly


relevant for browsers, and we've been using it to improve


our normal crawling, too.


We've sent out messages to websites


that were crawling with HTTP2 and plan


to add more over time if things go well.


As you can see, there's still room


for news in something as foundational as crawling.


And now let's move on to indexing.


As mentioned before, indexing is a process


of understanding and storing the content of web pages


so that we can show them in the search results appropriately.


For indexing, I have two items of news


to share with you today.


First, requesting indexing in the URL inspection tool


is back in Search Console.


You can once again manually submit individual pages


to request indexing if you run into a situation where


that's useful.


For the most part, sites should not need to use these systems


and instead focus on providing good internal linking


and good sitemap files.


If a site does those well, then Google Systems


will be able to crawl and index content from the website


quickly and automatically.


Secondly, in Search Console, we've


updated the index coverage report significantly.


With this change, we've worked to help site owners


to be better informed on issues that affect the indexing


of their site's content.


For example, we've removed the somewhat generic crawl anomaly


issue type and replaced it with more specific error types.


There's a bit more about this update


in our blog post, which I've linked in the description


below.