JavaScript: SEO Mythbusting

That's good.


JavaScript: SEO Mythbusting

That's really good.


JavaScript: SEO Mythbusting

Fantastic.


JavaScript: SEO Mythbusting

That was actually the big moment of my career


JavaScript: SEO Mythbusting

when I got on the technical SEO.


JavaScript: SEO Mythbusting

And I came and I talked to one of my new developers


JavaScript: SEO Mythbusting

for the first time with this very specific problem


JavaScript: SEO Mythbusting

I was trying to solve.


JavaScript: SEO Mythbusting

And he just paused and looked up from his keyboard and went,


JavaScript: SEO Mythbusting

you're not snake oil.


JavaScript: SEO Mythbusting

So I think we're making a lot of progress between SEOs and devs


JavaScript: SEO Mythbusting

to go.


JavaScript: SEO Mythbusting

That is fantastic.


JavaScript: SEO Mythbusting

That's a great story.


JavaScript: SEO Mythbusting

So you might hear a few people in the community going,


JavaScript: SEO Mythbusting

like, ooh, should we do a single-page application?


JavaScript: SEO Mythbusting

Is that risky?


JavaScript: SEO Mythbusting

And one of the things that a bunch of developers


JavaScript: SEO Mythbusting

are not aware of and some SEOs are not necessarily


JavaScript: SEO Mythbusting

communicating all the time is that we are stateless.


JavaScript: SEO Mythbusting

So that means with a single-page application,


JavaScript: SEO Mythbusting

you have a bit of an application state, right?


JavaScript: SEO Mythbusting

You know which page you are looking at


JavaScript: SEO Mythbusting

and how you transition between these pages.


JavaScript: SEO Mythbusting

However, when a search user clicks on a search result,


JavaScript: SEO Mythbusting

they are not having this application state.


JavaScript: SEO Mythbusting

They are jumping in right to the page that we indexed.


JavaScript: SEO Mythbusting

So we only index pages that can be jumped right into.


JavaScript: SEO Mythbusting

So a lot of the technology, JavaScript technology,


JavaScript: SEO Mythbusting

is making assumptions of how the user navigates


JavaScript: SEO Mythbusting

to the application.


JavaScript: SEO Mythbusting

So like the developer, as a developer, I might test,


JavaScript: SEO Mythbusting

so OK, here's my application.


JavaScript: SEO Mythbusting

I click on the main navigation for this particular page.


JavaScript: SEO Mythbusting

And then I click on this product.


JavaScript: SEO Mythbusting

And then I see that everything works.


JavaScript: SEO Mythbusting

But that might not do the trick.


JavaScript: SEO Mythbusting

Because if you're a unique URL, it


JavaScript: SEO Mythbusting

has to be something we can get to.


JavaScript: SEO Mythbusting

Not using a hash URL.


JavaScript: SEO Mythbusting

And also, the server needs to be able to serve that right away.


JavaScript: SEO Mythbusting

If I do this journey and then basically take this URL


JavaScript: SEO Mythbusting

and copy and paste it into an incognito browser,


JavaScript: SEO Mythbusting

I want people to see the content, not the home page


JavaScript: SEO Mythbusting

and not a 404 page.


JavaScript: SEO Mythbusting

So that's something that we're working on,


JavaScript: SEO Mythbusting

giving more guidance for lazy loading.


JavaScript: SEO Mythbusting

You probably have seen a bunch of communication about that one


JavaScript: SEO Mythbusting

as well.


JavaScript: SEO Mythbusting

Oh, yes.


JavaScript: SEO Mythbusting

How do we get our rich media experience out to users?


JavaScript: SEO Mythbusting

But do it in a way where if you're on your cell phone,


JavaScript: SEO Mythbusting

we keep that very small time frame


JavaScript: SEO Mythbusting

we have to get your attention.


JavaScript: SEO Mythbusting

Correct.


JavaScript: SEO Mythbusting

And you want to make sure that if you


JavaScript: SEO Mythbusting

have a long list of content, you don't bring everything


JavaScript: SEO Mythbusting

into the, especially on the cell phone,


JavaScript: SEO Mythbusting

just dealing with 100 images.


JavaScript: SEO Mythbusting

What about AJAX?


JavaScript: SEO Mythbusting

What about using asynchronous JavaScript and XML?


JavaScript: SEO Mythbusting

Right, that is perfect.


JavaScript: SEO Mythbusting

Whoa.


JavaScript: SEO Mythbusting

I haven't heard AJAX being used in a while


JavaScript: SEO Mythbusting

and spelled out in a while.


JavaScript: SEO Mythbusting

I think a lot of.


JavaScript: SEO Mythbusting

Everyone's using it, but no one's


JavaScript: SEO Mythbusting

talking about it that much.


JavaScript: SEO Mythbusting

It was just like, yeah, you just load data in as you go.


JavaScript: SEO Mythbusting

That's perfectly fine.


JavaScript: SEO Mythbusting

We are able to do that.


JavaScript: SEO Mythbusting

Also, I often get asked about how that affects the crawl


JavaScript: SEO Mythbusting

budgets.


JavaScript: SEO Mythbusting

I knew that you would say that.


JavaScript: SEO Mythbusting

Crawl budget, let's talk.


JavaScript: SEO Mythbusting

So what worries you about that?


JavaScript: SEO Mythbusting

Well, if we're using AJAX, and we request, say, a product


JavaScript: SEO Mythbusting

detail page, and we're using AJAX to supplement


JavaScript: SEO Mythbusting

a lot of pieces of content to it,


JavaScript: SEO Mythbusting

Googlebot's requested one URL, and it's gotten back nine.


JavaScript: SEO Mythbusting

Because each of those AJAX calls had a unique string.


JavaScript: SEO Mythbusting

How do we handle that, and does it negatively impact


JavaScript: SEO Mythbusting

our crawl budget?


JavaScript: SEO Mythbusting

So I wouldn't say it negatively impacts your crawl budget,


JavaScript: SEO Mythbusting

because crawl budget is much more complex


JavaScript: SEO Mythbusting

than you might see.


JavaScript: SEO Mythbusting

It's one of these things that looks super simple,


JavaScript: SEO Mythbusting

but there's more than meets the eye.


JavaScript: SEO Mythbusting

We're doing a bunch of caching, because we


JavaScript: SEO Mythbusting

expect that content doesn't necessarily update too much.


JavaScript: SEO Mythbusting

So let's say you have this product page.


JavaScript: SEO Mythbusting

You make one request to the product page,


JavaScript: SEO Mythbusting

and then that makes nine more requests.


JavaScript: SEO Mythbusting

We don't distinct between loading the CSS,


JavaScript: SEO Mythbusting

or the JavaScript, or the images,


JavaScript: SEO Mythbusting

or the API calls that get you the product details.


JavaScript: SEO Mythbusting

So if you have nine calls from this one page load,


JavaScript: SEO Mythbusting

then that's going to be 10 in the crawl budget.


JavaScript: SEO Mythbusting

But because of caching, we might have some of these


JavaScript: SEO Mythbusting

in the cache already.


JavaScript: SEO Mythbusting

So if we have something that is already cached,


JavaScript: SEO Mythbusting

that doesn't count towards your crawl budget.


JavaScript: SEO Mythbusting

So if we were to version our AJAX calls,


JavaScript: SEO Mythbusting

those could be cached instead of crawling every time.


JavaScript: SEO Mythbusting

Exactly, yes.


JavaScript: SEO Mythbusting

And then that's one way of working around it,


JavaScript: SEO Mythbusting

if you can do that, if that's a possibility.


JavaScript: SEO Mythbusting

The other thing is you could also consider it not just


JavaScript: SEO Mythbusting

an issue for the crawl budget, but also


JavaScript: SEO Mythbusting

an issue for the user.


JavaScript: SEO Mythbusting

Because if you're on a slow network or a spotty network


JavaScript: SEO Mythbusting

connection, it might flake out in the middle,


JavaScript: SEO Mythbusting

and then you are left with broken content.


JavaScript: SEO Mythbusting

That's not a great user experience.


JavaScript: SEO Mythbusting

You want to probably think about pre-rendering,


JavaScript: SEO Mythbusting

or hybrid rendering, or server-side rendering,


JavaScript: SEO Mythbusting

anything in between there.


JavaScript: SEO Mythbusting

And crawl budget is tricky generally,


JavaScript: SEO Mythbusting

because we are trying to deal with the host load situation.


JavaScript: SEO Mythbusting

So what can your servers actually deal with?


JavaScript: SEO Mythbusting

So we are constantly adjusting that anyway.


JavaScript: SEO Mythbusting

So it's like, oh, this affected our crawl budget negatively.


JavaScript: SEO Mythbusting

Not really, because we just had host load issues


JavaScript: SEO Mythbusting

with your server.


JavaScript: SEO Mythbusting

So we adjusted it anyway.


JavaScript: SEO Mythbusting

So we had balancing issues across your entire content.


JavaScript: SEO Mythbusting

So I wouldn't say that it's not much of a deal,


JavaScript: SEO Mythbusting

normally speaking.


JavaScript: SEO Mythbusting

But I see that it's very important for people


JavaScript: SEO Mythbusting

to understand that.


JavaScript: SEO Mythbusting

And unfortunately, that's not that easy.


JavaScript: SEO Mythbusting

Can we demystify Googlebot a little bit?


JavaScript: SEO Mythbusting

Oh, yeah.


JavaScript: SEO Mythbusting

Because we have this, the ominous, the great,


JavaScript: SEO Mythbusting

the Googlebot.


JavaScript: SEO Mythbusting

But it actually goes through a series of actions.


JavaScript: SEO Mythbusting

So we get that initial HTML parse.


JavaScript: SEO Mythbusting

We find the JavaScript and CSS that we


JavaScript: SEO Mythbusting

need to go ahead to make our content,


JavaScript: SEO Mythbusting

then call those pieces.


JavaScript: SEO Mythbusting

We know since Google IO, there's actually


JavaScript: SEO Mythbusting

a gap between our initial parse and our HTML rendering.


JavaScript: SEO Mythbusting

But I want to know more, because Googlebot follows HTML and HTML5


JavaScript: SEO Mythbusting

protocols.


JavaScript: SEO Mythbusting

There's some nuances there I don't think


JavaScript: SEO Mythbusting

I know I didn't know about.


JavaScript: SEO Mythbusting

Say you've got an iframe in your head,


JavaScript: SEO Mythbusting

and you've got a closing head script right there.


JavaScript: SEO Mythbusting

That ends your head for Googlebot.


JavaScript: SEO Mythbusting

And all of our lovely meta content, our hreflangs


JavaScript: SEO Mythbusting

and canonicals below that, have a tendency to exist?


JavaScript: SEO Mythbusting

That is true.


JavaScript: SEO Mythbusting

There is a bunch of things at play.


JavaScript: SEO Mythbusting

So when we say Googlebot, what we actually


JavaScript: SEO Mythbusting

mean on the other side of the curtain


JavaScript: SEO Mythbusting

is a lot of moving parts.


JavaScript: SEO Mythbusting

So there's the crawling bit that literally takes in URLs


JavaScript: SEO Mythbusting

and then fetches them from the server


JavaScript: SEO Mythbusting

so that when you are providing the content to us,


JavaScript: SEO Mythbusting

we get the raw HTML.


JavaScript: SEO Mythbusting

That tells us about the CSS, the JavaScript, and the images


JavaScript: SEO Mythbusting

that we need to get, and also the links in the initial HTML.


JavaScript: SEO Mythbusting

Because we have that already, we have such a wealth


JavaScript: SEO Mythbusting

of information already, we can then start to go off


JavaScript: SEO Mythbusting

and fetch the JavaScript and everything


JavaScript: SEO Mythbusting

that we need to render later on.


JavaScript: SEO Mythbusting

But we can also already use the HTML that we've got and say,


JavaScript: SEO Mythbusting

oh, look, there's links in here that need to be crawled.


JavaScript: SEO Mythbusting

So when you have links in your initial HTML,


JavaScript: SEO Mythbusting

we can go off and basically start the same process


JavaScript: SEO Mythbusting

for these URLs as well.


JavaScript: SEO Mythbusting

So a lot of things happen in parallel,


JavaScript: SEO Mythbusting

rather than just one step, and then the next step,


JavaScript: SEO Mythbusting

and then the next step.


JavaScript: SEO Mythbusting

So this is definitely the start of it.


JavaScript: SEO Mythbusting

And as we get the HTML in parallel to extracting the links


JavaScript: SEO Mythbusting

and then crawling these, we queue them for rendering.


JavaScript: SEO Mythbusting

So we can't index before we have rendered it,


JavaScript: SEO Mythbusting

because a bunch of content needs to be rendered first.


JavaScript: SEO Mythbusting

But in a way, that benefits us if we've got a simple page


JavaScript: SEO Mythbusting

application.


JavaScript: SEO Mythbusting

We now, Googlebot has the template,


JavaScript: SEO Mythbusting

they just got to grab the content that fits within there.


JavaScript: SEO Mythbusting

So wouldn't that mean that Googlebot likes


JavaScript: SEO Mythbusting

these JavaScript platforms?


JavaScript: SEO Mythbusting

MARTIN SPLITT


JavaScript: SEO Mythbusting

The more content you get us quickly in the first step,


JavaScript: SEO Mythbusting

in the crawling step, the better it is.


JavaScript: SEO Mythbusting

Because we can then basically carry that information over,


JavaScript: SEO Mythbusting

rather than having to wait for the rendering to happen.


JavaScript: SEO Mythbusting

KATIE HEMPENIUS WILKINSON That is pre-render always


JavaScript: SEO Mythbusting

the best solution.


JavaScript: SEO Mythbusting

MARTIN SPLITT That's a tricky one.


JavaScript: SEO Mythbusting

I think most of the time it is, because it


JavaScript: SEO Mythbusting

has benefits for the user on top of just the crawlers.


JavaScript: SEO Mythbusting

But you have to very carefully measure what


JavaScript: SEO Mythbusting

you're doing there, I think.


JavaScript: SEO Mythbusting

So giving more content over is always a great thing.


JavaScript: SEO Mythbusting

That doesn't mean that you should always


JavaScript: SEO Mythbusting

give us a page with a bazillion images right away,


JavaScript: SEO Mythbusting

because that's just not going to be good for the users.


JavaScript: SEO Mythbusting

Because they're going to have to then,


JavaScript: SEO Mythbusting

if you're on a really old phone and I have a pretty old phone,


JavaScript: SEO Mythbusting

and you have a page that is full of images and transitions


JavaScript: SEO Mythbusting

and stuff, then you're like, I can't use this website.


JavaScript: SEO Mythbusting

So pre-rendering is not always a great idea.


JavaScript: SEO Mythbusting

It should be always a mix between getting


JavaScript: SEO Mythbusting

as much crucial content in as possible,


JavaScript: SEO Mythbusting

but then figuring out which content you can load lazily


JavaScript: SEO Mythbusting

in the end of it.


JavaScript: SEO Mythbusting

KATIE HEMPENIUS WILKINSON So for SEOs, that would be,


JavaScript: SEO Mythbusting

we know that different queries are different intents,


JavaScript: SEO Mythbusting

informational, transactional.


JavaScript: SEO Mythbusting

So elements critical to that intent


JavaScript: SEO Mythbusting

should really be in that initial parse.


JavaScript: SEO Mythbusting

MARTIN SPLITT Exactly.


JavaScript: SEO Mythbusting

And you might consider, if the intents are wildly different


JavaScript: SEO Mythbusting

and the content is very, very different,


JavaScript: SEO Mythbusting

consider making it into multiple pages, or at least


JavaScript: SEO Mythbusting

multiple views if you're using a single page application,


JavaScript: SEO Mythbusting

so that you have an entry point for the crawler


JavaScript: SEO Mythbusting

to specifically point at it when it comes


JavaScript: SEO Mythbusting

to surfacing the search results.


JavaScript: SEO Mythbusting

KATIE HEMPENIUS WILKINSON So treat it like a hub


JavaScript: SEO Mythbusting

and let the users branch out from there.


JavaScript: SEO Mythbusting

MARTIN SPLITT Yes.


JavaScript: SEO Mythbusting

KATIE HEMPENIUS WILKINSON So that's


JavaScript: SEO Mythbusting

where we'd use maybe our CSS toggle for visibility.


JavaScript: SEO Mythbusting

MARTIN SPLITT That is a possibility.


JavaScript: SEO Mythbusting

Just having different URLs is always an option.


JavaScript: SEO Mythbusting

Especially with the history API, you can probably,


JavaScript: SEO Mythbusting

in the single page application, figure out


JavaScript: SEO Mythbusting

which route to display, and then have


JavaScript: SEO Mythbusting

the content separated between different routes,


JavaScript: SEO Mythbusting

or be a little more dynamic there.


JavaScript: SEO Mythbusting

We support parameters.


JavaScript: SEO Mythbusting

So even if you use URL parameters,


JavaScript: SEO Mythbusting

basically expose the state that is


JavaScript: SEO Mythbusting

relevant to the user in the URL.


JavaScript: SEO Mythbusting

KATIE HEMPENIUS WILKINSON What other ways does that benefit


JavaScript: SEO Mythbusting

our users?


JavaScript: SEO Mythbusting

Because their ultimate goal is to make them happy.


JavaScript: SEO Mythbusting

MARTIN SPLITT That's true.


JavaScript: SEO Mythbusting

Yeah.


JavaScript: SEO Mythbusting

And that's our ultimate.


JavaScript: SEO Mythbusting

So we are the same in terms of what our goal is.


JavaScript: SEO Mythbusting

We both want to serve as useful information to the user


JavaScript: SEO Mythbusting

as quickly as possible.


JavaScript: SEO Mythbusting

So the user's benefits are, especially


JavaScript: SEO Mythbusting

if you do hybrid rendering or server-side rendering,


JavaScript: SEO Mythbusting

that they get the content really quick, normally,


JavaScript: SEO Mythbusting

if it's done well, if it's not overloading their device.


JavaScript: SEO Mythbusting

And they get to jump in right where the meaty bits are.


JavaScript: SEO Mythbusting

So if I'm looking for some specific thing,


JavaScript: SEO Mythbusting

and you give me a URL that I can use


JavaScript: SEO Mythbusting

to go to that specific thing, I'm right there.


JavaScript: SEO Mythbusting

And I'll have a great time, because it's the content


JavaScript: SEO Mythbusting

that I needed.


JavaScript: SEO Mythbusting

So yeah, if you have performance metrics going up as well,


JavaScript: SEO Mythbusting

then even if I'm on a slow phone on a really spotty network,


JavaScript: SEO Mythbusting

I still get there.


JavaScript: SEO Mythbusting

But our performance metrics, that's based on a lot of pieces.


JavaScript: SEO Mythbusting

We have a stack of technology.


JavaScript: SEO Mythbusting

That is true.


JavaScript: SEO Mythbusting

What should SEOs look for in our stack?


JavaScript: SEO Mythbusting

Where should we try to identify those areas where


JavaScript: SEO Mythbusting

we could have a better experience for not just


JavaScript: SEO Mythbusting

Googlebot, but our humans?


JavaScript: SEO Mythbusting

Yeah.


JavaScript: SEO Mythbusting

So I think a bit that is oftentimes overlooked,


JavaScript: SEO Mythbusting

not by SEOs, but by businesses and developers,


JavaScript: SEO Mythbusting

is the content part.


JavaScript: SEO Mythbusting

So you want to make sure that the content is


JavaScript: SEO Mythbusting

what the users need and want, and it's written


JavaScript: SEO Mythbusting

in a way that helps them.


JavaScript: SEO Mythbusting

But on the technology side.


JavaScript: SEO Mythbusting

Wait, so that blurb at the top people always do,


JavaScript: SEO Mythbusting

where they're like, here's my hero image,


JavaScript: SEO Mythbusting

and then 500 words about this thing,


JavaScript: SEO Mythbusting

and I'm a human who wants to buy something,


JavaScript: SEO Mythbusting

and there's so much stuff in the way.


JavaScript: SEO Mythbusting

Don't do it.


JavaScript: SEO Mythbusting

Or at least have two pages have the promotional page


JavaScript: SEO Mythbusting

that you want to direct marketing towards.


JavaScript: SEO Mythbusting

And then if I specifically look for your product,


JavaScript: SEO Mythbusting

just give me your product.


JavaScript: SEO Mythbusting

Just let me give you money.


JavaScript: SEO Mythbusting

So I think talking about performance


JavaScript: SEO Mythbusting

and all the different metrics is a bit of a blend


JavaScript: SEO Mythbusting

of all the things.


JavaScript: SEO Mythbusting

Like look at when does my content actually arrive?


JavaScript: SEO Mythbusting

When does my page become responsive?


JavaScript: SEO Mythbusting

So you look at first contentful paint.


JavaScript: SEO Mythbusting

You look at time to first buy it as well.


JavaScript: SEO Mythbusting

Less important than the first contentful paint, I would say.


JavaScript: SEO Mythbusting

Because it's fine if it takes a little longer.


JavaScript: SEO Mythbusting

If then the content is all there versus it takes.


JavaScript: SEO Mythbusting

So time to first buy it can take a bit of a hit.


JavaScript: SEO Mythbusting

Yeah.


JavaScript: SEO Mythbusting

If we deliver that faster first meaningful paint.


JavaScript: SEO Mythbusting

Exactly.


JavaScript: SEO Mythbusting

Because in the end, as a user, I don't


JavaScript: SEO Mythbusting

care about if the first buy has arrived quicker


JavaScript: SEO Mythbusting

if I'm still looking at a blank page


JavaScript: SEO Mythbusting

because JavaScript is executing or something


JavaScript: SEO Mythbusting

is blocking a resource.


JavaScript: SEO Mythbusting

If it arrives a little later but then it's right there,


JavaScript: SEO Mythbusting

that's fantastic.


JavaScript: SEO Mythbusting

And you can get there in multiple ways.


JavaScript: SEO Mythbusting

I highly recommend testing, testing, testing, testing.


JavaScript: SEO Mythbusting

What testing tools would you recommend?


JavaScript: SEO Mythbusting

So I definitely recommend Lighthouse.


JavaScript: SEO Mythbusting

That's a great way.


JavaScript: SEO Mythbusting

WebHind is a more broad approach as well.


JavaScript: SEO Mythbusting

And you could also use PageSpeed Insights or the new SEO


JavaScript: SEO Mythbusting

audits in Lighthouse.


JavaScript: SEO Mythbusting

Mobile-friendly test also gives you a bunch of information.


JavaScript: SEO Mythbusting

PageSpeed Insights seems to look at that full page, though.


JavaScript: SEO Mythbusting

And we have a bit of a gap.


JavaScript: SEO Mythbusting

We have almost this futurist Lighthouse


JavaScript: SEO Mythbusting

where we want that time to interactive.


JavaScript: SEO Mythbusting

And then we have people adopt this methodology.


JavaScript: SEO Mythbusting

And that's how we got so much content via Ajax.


JavaScript: SEO Mythbusting

Because full page load is fast, but all that content


JavaScript: SEO Mythbusting

was still coming.


JavaScript: SEO Mythbusting

So I would recommend Lighthouse.


JavaScript: SEO Mythbusting

I really think that if Google is a library and a web page


JavaScript: SEO Mythbusting

is a book, using these JavaScript frameworks,


JavaScript: SEO Mythbusting

let us make pop-up books and written experiences


JavaScript: SEO Mythbusting

to engage with.


JavaScript: SEO Mythbusting

Oh, that's a fantastic analogy.


JavaScript: SEO Mythbusting

I love that image.


JavaScript: SEO Mythbusting

That's a beautiful one.


JavaScript: SEO Mythbusting

Thank you so much, Janie, for being here.


JavaScript: SEO Mythbusting

Thank you very much.


JavaScript: SEO Mythbusting

And I hope you enjoyed it.


JavaScript: SEO Mythbusting

And see you next time.


JavaScript: SEO Mythbusting

Have you ever wondered where on the map


JavaScript: SEO Mythbusting

you should put UX and performance


JavaScript: SEO Mythbusting

when you're talking about SEO?


JavaScript: SEO Mythbusting


English Google SEO office-hours from February 12, 2021

All right, welcome, everyone, to today's Google Webmaster SEO


Office Hours Hangout.


My name is John Mueller.


I am a search advocate at Google in Switzerland.


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


where people can join in and ask their questions around search


and their website.


As always, a bunch of stuff was submitted directly on YouTube


already.


So we can go through some of that.


But if any of you want to get started


with the first question, like Barry, feel free to jump on it.


BARRY SCHWARTZ-GALBRAINER Sure, thank you very much.


First, it's no longer the Webmaster Central.


It's the Search Central Office Hours Hangout.


I know it's hard to even saying that for, what, 20 years?


And for maybe 100 years in SEO years.


In any event, Passage Indexing was


launched Wednesday night, Pacific, or Wednesday


afternoon Pacific time.


And there's a lot of confusion in the industry.


I just want one clarification.


I know Danny Sullivan said it's going to look exactly


like any other snippet.


It's not going to look like a featured snippet.


It's not going to look like a weird snippet,


even though you guys had an image of a snippet looking


differently in the tweets about it.


One, confirm that.


And then two, are the Passions ranking snippets


using scroll to text feature that


are in some featured snippets and other elements?


Those two questions.


I don't know about either of them.


So I think with the first question,


I don't really know how that will be shown.


And it's hard for me to tell because I never


see it here in Switzerland.


Danny might know more there.


He's been a bit more involved with that directly.


With regards to the scroll to snippet part,


I believe that's something that we're just still


experimenting with.


So not necessarily that it will automatically use that


or that it's like always use that or not.


But my understanding is that's still


something where we're not 100% sure how that will


be embedded in the long run.


For specifically Passage ranking or for any general snippet?


Just in general.


Do you know if they're being tested for?


I mean, would there be a difference


for testing that in Passage ranking versus any other snippet?


I don't think there would necessarily


be a big difference there.


I did see some tweets from people saying,


oh, we're starting to see this more in Search Console


since you launched this.


I don't know if that's more of a coincidence


or if that's kind of like directly tied to that or not.


OK, in summary, you don't know.


I don't know.


Yes.


All right, thank you.


Not even it depends.


Yeah.


All right, other questions?


Maybe I'll know some answers along the way.


Anything else to get started with?


I can ask a quick one if that's OK.


Hey, John.


OK, go for it.


So this is related to the unavailable after robots value


tag.


So we're working with a classified site


where that tag would definitely be helpful in order


to stop Google from keep trying those 404 expired ad pages.


It's just that we're concerned that a lot of users


are able to refresh their ad.


So in that case, it won't expire at the date


it's supposed to expire.


So they might refresh it for another week or even more.


And they might keep refreshing it if they choose to.


What is the unavailable after option still a good one?


Would Google updating it make Google


kind of understand that the date keeps moving forward


into the future?


Yeah, I mean, if we refresh that page for crawling and indexing,


then we would see the updated unavailable after meta tag.


So that would work.


It's not like you can only specify it once,


and then it's cemented like that.


If we recrawl that page and see the new tag,


we'll take that into account.


So I guess the situation would be kind of tricky


if you set the unavailable after meta tag for tomorrow,


for instance, and we just recrawl it the day


after tomorrow, then we would have dropped it, potentially,


in the meantime.


So is there any way to make sure that doesn't happen?


I mean, would using the site map and the last modified date


help if we choose the unavailable after tag?


OK.


Sure.


Yeah, I mean, it's something where


you could change the last modification date and say,


it changed now.


It's not guaranteed that we would recrawl the page right


away, but it's one of those signals you can tell us,


this page has changed.


Double check to make sure that we're not missing anything.


But what happens if I set the unavailable after tag


for tomorrow, let's say, and the crawler


knows that tomorrow going forward,


it should not crawl the page anymore?


And let's say a week from now, the user


decides to reactivate their ad.


Will the last modification date in the site map


make Google understand that, well, maybe I


should recrawl that page because it seems it's not working?


I mean, the unavailable after meta tag


doesn't say not to recrawl it afterwards.


It's more that the site owner is saying,


this will probably be a no index or a 404 afterwards.


So it's more that Google can drop it out a little bit faster


without needing to recrawl it.


It's not a sign that we would stop refreshing that page.


OK.


But it will still help with the kind of overall budget


making Google kind of slow down on recrawling these?


Yeah.


John, regarding this, I just wanted


to understand if we are using unavailable after tag


in seasonal pages like some Christmas Day page flights.


On that case, does Google have the same page index even


after unavailable after tag?


Or this will drop it from index also?


The idea is that we would drop it even


So our assumption is that if you have the unavailable


after meta tag set to a date, that that page is no longer


available afterwards.


And that it will be no index or 404 afterwards.


So our systems, I think the way that I understood it


is our systems are essentially going


to treat it as if there is a no index on there after that date,


even if we don't recrawl it by then.


So it means that the page for all the time when it is


not season will be no indexed.


Yeah.


I mean, it's something where if you have a seasonal page that


has a limited lifetime, then you can definitely


use that, especially to let us know about things that expire


quickly, to let us know about the long tail content


that we don't recrawl that often.


That's really useful.


Like, for instance, classified sites, for example, I think


is a really good example for that.


Seasonal content itself, like if you have one,


I don't know, Christmas page.


Usually that's going to be very prominent within your site


during that season.


So we're going to recrawl that quite a bit.


And if you add a no index to that page at some point,


we'll pick that up fairly quickly.


So usually for that kind of seasonal content,


the unavailable after meta tag isn't really critical,


but really for the content that we


don't recrawl that frequently.


OK.


Thanks.


Hi, John.


Hi.


I have a question about our robots file.


We see that some of our clients, they


don't have any robots file on their site.


Now, if a site does not have any robots file,


does it affect its ranking or indexing or crawling?


No.


It's totally optional to have a robots.txt file.


If there is no robots.txt file, there


are no restrictions for robots.txt, essentially.


So that's a perfectly fine setup.


And the next question is about blog post category and blog


post tag.


The post category and post tag, does it


have any impact on ranking of the blog post?


Not necessarily.


So it's not that we would try to recognize tags on a page.


But these are links.


And potentially, they go to a category page or tag page.


And that would be another page that we could index


or that we could use to pick up links to your articles.


So it's not that there is any inherent magic around tags.


It's just it creates more links and more pages


within your site.


Thank you.


OK, let me run through some of the submitted questions.


We'll definitely have more time for your live questions


as well.


And if you have any comments or, I don't know,


more questions to the questions that we go through,


feel free to jump on in.


A large site has legacy code that generates


parameters on internal links.


These parameters are unique for every session.


If the site serves Googlebot these pages


with the parameters stripped, would that


be considered cloaking?


Technically, yes, we would consider that to be cloaking.


The search engineering team would say, oh, this


is cloaking, like you shouldn't do it.


From a practical point of view, it would not be problematic.


So it's not that the web spam team would take manual action


on this.


It's essentially something where you're


kind of providing an optimization for Googlebot


that you're not providing for users.


And it's more a matter of you're making it kind of hard


for yourself to maintain your site because you always


have to look at both versions.


And if you never see the version that Googlebot sees,


it's very easy to run into a situation where suddenly


Googlebot gets error pages or Googlebot gets bad links.


And every time you check that with maybe a local crawler,


you don't see those broken links.


So that's something from kind of a best practices point of view.


I try to avoid that.


But it's not that you're going to get flagged or get


a manual action because of that.


If a niche news portal is moved to a subdomain of a larger


general news portal, can its visibility


be affected by the main domain?


So for example, before the migration,


both sites ranked for top positions on a lot of topics.


Now, many times, only the main domain portal


is able to reach top positions in the first page


while the subdomain has dropped considerably.


So any time you do this kind of migration


where you're kind of splitting a site into separate parts


or you're taking multiple sites and combining them


into one main site, I would expect


to see fluctuations with regards to kind of ranking,


in general, kind of temporary fluctuations,


but also long-term fluctuations.


And it can be that the overall result is something


that is much stronger than the individual ones before.


It can also be that the overall result


is kind of a mixed bag of things.


And it causes problems in the long run.


So that's something where it's really


hard to determine ahead of time what the actual effect will


be when you go into the situation of merging


or splitting sites.


So from a theoretical point of view, yes, it


can happen like this.


It is something where you can put in time and get


some help from experts and more experienced folks


to see, should you expect problems,


or will this probably be OK?


But it is different from the general site move situation


where you just move one site to a different domain.


You're taking everything from one site


and just passing it on to a new one.


As soon as you merge or split things,


then we essentially have to reprocess things overall


and try to come up with a bigger new picture for that site.


Would adding an audio version of a page's content


help with search in any way other


than the obvious accessibility improvement?


As far as I know, we don't do anything


with audio versions of content.


We also wouldn't see that as duplicate content.


So it's not that you have to avoid that.


I mean, duplicate content itself isn't really


something you really have to avoid.


But even if you wanted to avoid the situation


that you're suddenly ranking for the same things


with different pieces of content,


the audio version is something that we, as far as I know,


would not even process separately.


So at most, we might see that as a piece of video content


and show that also with a video snippet.


But essentially, it wouldn't help or detract


from a page's overall ranking.


SPEAKER 2


John, wouldn't it show us if they've embedded an audio file,


for example, to play on the page?


Doesn't that do anything?


I mean, if you've got a page that literally just has


text versus a page that has text, pictures, video, audio,


and therefore provides more variety and depth,


isn't that not adding anything to the quality of that page


to have an audio file?


I don't think we would look at that and say,


oh, there are different kinds of content here.


It's a better page because of that.


It might be that they're indirect effects.


Like, if users find this page more useful


and they recommend it more, that's


something that could have an effect.


But it's not the case that we look


at the types of content on a page


and say, oh, two types versus five types.


Like, the one with five types is better.


I think it's a bit different with video and images


in that images and video themselves


can rank independently.


Like, in image search or in video search,


you can also have the same piece of content


be visible in those other surfaces.


But for audio, we don't really have a separate, I don't know,


audio search where that page could also rank.


I think the closest that could come there


is the podcast search that we have or the podcast


kind of one-box thing.


But that's really tied to the podcast content type,


where you have a feed of podcast information


and we can index it like that.


But just having audio on a page by itself,


I don't think that would change anything automatically


in our systems.


OK.


A website has a small snippet.


Sorry.


Go ahead.


Oh, hi.


I have a question about mobile-first indexing.


So I just did a working on a site that just


went through a site move.


So I actually spoke to you about it a couple weeks ago.


But basically, it's just a change of domain name.


So it didn't change the URLs or site architecture.


So the old site was being indexed by mobile Googlebot.


But now it's being indexed by desktop.


And it hasn't switched over yet.


So it's only been a week, actually, since it launched.


So I know it can take a bit of time.


But I was wondering if there is maybe a sandbox effect


because the domain itself was pre-existing.


And it was kind of a parked domain.


But it was a site that was probably previously indexed


by Google.


It's currently, according to the crawl stats report in Search


Console, currently being crawled 96% of the time


by smartphone Googlebot.


So I'm wondering how long, I guess,


might we expect for it to switch over to mobile-first


or if there is potentially a sandbox effect because it


was previously a site being indexed by desktop?


So I wouldn't worry about the mobile-first part


for something like that because we kind of have


the timeline set for switching everything over to mobile-first


anyway.


So that will happen in, I don't know, what is it, in March


or April?


I don't know what timeline we had there.


So that will happen anyway.


But with regards to kind of moving to a previously existing


domain where there was part content,


you can definitely see some temporary effect there.


Not so much in terms of kind of like a sandbox effect


or something like that, but more in terms of if we've always


seen a no-index page on this site for the longest time,


then probably we're going to assume that it's still


no-index for a while.


And you might see kind of this, I don't know, moment where


for, I don't know, I've seen it happen for maybe a week or two,


maybe up to three weeks, where it's just our systems assume


that this is still a part site and essentially treat


the new content that is there as being parked as well.


And then it either doesn't get indexed at all


or it ranks kind of really badly in the beginning.


And then at some point, our systems go,


oh, it's no longer parked, and essentially it just


pops back in.


AUDIENCE 1 OK.


Yeah, I think it's starting to, we


are starting to see some recovery with rankings


and stuff that had dropped in the last week.


But yeah, I was just wondering if there


is any sort of negative impact from being indexed by desktop


given that we're using a responsive design


and it's the same architecture as the previous site.


No?


No, that definitely wouldn't be the case, so it's not


that there is any kind of ranking, I don't know,


penalty or anything holding a site back


if it's being crawled with a mobile or with a desktop


crawler.


That's really just a technical thing on our side.


Are we crawling with mobile or desktop?


And then essentially the same content goes into the index.


AUDIENCE 1 OK.


Yeah, because I'm seeing something that I'm not


sure if it's related, which is I'm getting some AMP


warnings for domain mismatch.


And it seems to be like sometimes the old version


of the new version of the site has the AMP page indexed,


but the old page hasn't been recrawled yet since the move.


So I guess maybe the redirect hasn't been spotted yet.


And I was wondering if that is because of primarily the


crawling is being done by desktop.


I don't think that should be a problem.


Because if we understand the connection


between your legacy pages and the AMP version of the page,


then we would crawl those appropriately.


So that's something where I could imagine


you might see a temporary effect until all of that


settles down a little bit, where maybe we have the AMP URL


somewhere linked, and we go off and crawl it with the desktop


crawler initially.


And then we realize, oh, we have to use mobile because it's AMP.


Then we would pick that up.


But that's something that I would expect should settle down


fairly quickly.


I don't know, order of a, I don't know, one, two,


three weeks, something around that range.


AUDIENCE 1 OK, and it wouldn't be necessary to, say,


redirect AMP pages from the old to the new?


To maybe speed it up?


JOHN MUELLER I would redirect those too.


I would redirect those too.


AUDIENCE 1 Redirect those.


OK.


JOHN MUELLER Yeah.


Also images, anything that was essentially


hosted on the old domain.


Yeah, we've done them for all the other types of pages.


I'll add the AMP ones though.


Thank you very much.


Sure.


All right.


Let's see.


Let me just run through some more of the submitted questions


first, because we always seem to run in short of time for them.


I'll definitely have more time for live questions as well.


A website has a small snippet of client-side JavaScript


that updates the URL with the history API.


For example, the server response shows slash page,


and the browser address bar shows slash page dash updated.


No resources named page updated is


seen in the network resources.


Would Google see the updated URL?


Which address would the content be indexed under?


So if we see during the loading of a page


that the history API changes the URL,


then we would try to classify that as a redirect.


And we would try to take the destination URL,


or the new URL that you provide there,


and try to use that for indexing for the next time.


So essentially, what would happen the first time


we would see slash page.


If it does the history API swapping with page dash updated,


the next time we would try to crawl slash page dash updated


and use that as the version essentially for indexing.


I mean, it's not 100% certain, because it's essentially


a question of canonicalization.


But we would see that as a redirect.


And redirects are a pretty strong sign for canonicalization.


The important part here is that slash page dash updated


is actually a page that we can crawl.


So it shouldn't be the case that you kind of swap out


the URL for something that is not existent


if you go there directly.


So that's kind of the main thing to watch out for.


I've written outsourced about 600 articles in a year.


All were made more or less in the same way.


Still some rank and show in Google,


and some are not in Google at all,


even those that are more than 60 years old.


Then I manually need to go through all those 600 articles


and make some changes and update them.


And then they start showing up in search.


What should I do here, essentially?


So I think the main thing to keep in mind


is we don't guarantee indexing of all pages on every website.


In fact, for most websites, we index just a, I don't know,


small portion of the total website.


So if you have 600 articles on your website,


it can be completely normal that we go off and index


maybe 100, maybe 500, maybe somewhere in between.


It would be unexpected, from my point of view,


if we would always index all pages on all websites.


Because there's just, I don't know,


there's a limit to the number of pages


that we can index in our system.


So we have to try to prioritize a little bit.


And by changing pages on your website,


it's certainly possible that you trigger something


where Google starts seeing, again,


that these pages have changed and goes off and crawls them


and sees, well, is there something important


that we need to index here?


And then maybe it'll index it.


Maybe it'll be indexed for a while.


Maybe it'll drop out again after a couple of weeks


or a couple of months.


It really depends.


It's not something where there is a guarantee that we go off


and crawl and index all of the changed pages


or that there's a guarantee of having


an old, evergreen page will rank high, anything like that.


So especially if you're talking about a large number of pieces


of content on your site, then that's


something where it's worthwhile to figure out


a system on your own where you can


work to determine the quality of these pages


and to work to try to improve those pages over time


so that Google also is able to go in there and say, well,


these are really fantastic pages.


We do need to crawl and index more of these pages.


And then over time, that'll pick up again.


Let's see, Core Web Vitals question.


We know that all user interaction pages or URLs


are considered.


My question is, does Core Web Vitals


need to meet the 75th percentile across all devices


or mobile only?


The doc says segmented across mobile and desktop devices,


but it's not a clear interpretation, at least not for me.


What does that mean?


I don't know, Pedro, I think you're here.


I don't understand your question.


PEDRO CABRERA ARABARROA-SALGADO I am.


My question is, the word segmented across devices,


does it mean that the ranking boost or the algorithmic factor


is going to be factored only to the segmented device,


or you have to meet across all devices to receive the boost?


For example, if you meet Core Web Vitals on mobile only,


you only get on mobile only, or do you get on desktop too?


I don't know.


I don't think we have clearly defined exactly how


the ranking boost would happen there.


But essentially, we would track these per device,


and we'd be able to take them into account per device.


So I would assume it would not be the case that if your desktop


pages are really fast and your mobile pages are slow,


that we would still count that as being fast overall.


My assumption is that we would try to separate that out.


But I don't know what the final mix will be in terms of,


do you just have to meet the bar,


or is there a flexible range that you can reach to see


the effects there with regards to ranking?


I think for the badging, it's a little bit easier.


And I hope we have some more information on that


in the near future.


But especially when it comes to ranking,


it's something where it's oftentimes not something


that is just on or off.


Yeah.


Thank you.


Sure.


Let's see.


Really long question.


I have this website with subdirectories


on it for Korean and Japanese.


And I think the question goes into a little bit hreflang.


Do you need hreflang?


How the links between these versions work?


That kind of thing.


And whether these different language versions


need to be in line.


So I'm super simplifying.


Sorry.


But I think, in general, when you


have pages in different languages,


in significantly different languages, so in this case,


it sounds like it's Swedish content, Korean content,


and Japanese content, that's something


where we would be able to rank those pages individually.


And it's something where, if we see someone searching


in Japanese, we're not going to show them


the Swedish version of your page because it's pretty obvious


that they're searching in Japanese


and that your Japanese pages would fit that query best.


So that's something where, probably to a large extent,


in a situation like this, you would not even need hreflang


because it would not be the case that suddenly, accidentally,


your Swedish pages rank for someone searching in Japanese.


So I think that makes it a little bit easier


in terms of the whole hreflang setup


and what exactly you need to do there.


But this general situation of, if the queries are really


split by language, you don't really


need to focus on hreflang, though.


It would be different, for example,


if you had something like a global brand, where someone


in searching in Japanese would search with exactly


the same word as they would search in Swedish.


And then it might be hard for our systems


to understand this user in Japan who


is searching for this one name.


Do they mean the original Swedish site?


Do they mean the local Japanese site?


It's hard for us to understand.


And in a case like that, we would


use hreflang to swap out the appropriate country language


version for that user.


So I have a follow-up question, John.


Sure.


In the case where you have indicated hreflang appropriately


through XML sitemaps and specifically related


to English-speaking countries, what should one do,


if you see in Search Console, that Google's not


getting it right?


So we've indicated canonicals on both UK and US pages,


for example.


We've marked our sitemaps up with hreflang,


and we're still seeing Search Console say, hey,


we've actually selected the UK version in the context


of the US account.


Yeah, so that gets a little bit complicated


because there are other aspects that come into play there.


So the first thing I would do there


is try to reproduce that and see if that's actually


happening like that.


Because Search Console tries to do something really smart


that really throws things.


I don't know, makes things more complicated in Search Console


itself in that it tries to show the canonical version.


And with hreflang, in cases where the same content is


available for multiple countries,


we can still recognize that actually this


is duplicate content.


We'll index one version, and we'll


use hreflang to show the appropriate local URL when


someone is searching.


So that's something you might see in English,


where you have the same content in English.


In German, it's really common that this happens.


So that's something we see quite a bit here in Europe.


And essentially, what happens is in Search Console


and the URL inspection tool, if you check the UK version,


if you check that one, you see the canonical


shows the US version.


That's kind of what's happening there,


in that we understand it's the same content.


We still see the hreflang there, so we can swap the URLs out


in the search results.


But we will index it as the US version.


And the tricky part is in Search Console,


we report on the canonicals themselves.


So in the search results, we might show the UK version.


Because we know they're equivalent,


we can swap out the URLs.


But in the performance report, we


will track that as the US version in Search Console.


So if you just look at the performance report,


it's like, oh, the UK version is never shown.


But if you try those search results out yourself,


then you see that actually the UK URL is shown.


But since the content is exactly the same from an indexing


point of view, we're kind of simplifying that.


So two quick follow-ups to that.


One is I think a pretty good indicator for geo mismatch


would be looking at a geo-specific Search Console


account, looking at the traffic makeup between different geos.


So let's say, for example, I look at Canada,


and I see that 50% of their traffic is coming from the UK.


That would pretty clearly indicate


that there's some mismatch.


Is that appropriate?


Yeah, but then you might still be seeing that effect


that we're kind of showing the right URLs,


but we're tracking it with the wrong ones.


So that is super complicated in cases like that.


Because if we have Canada and US versions,


and we pick one of those as canonical,


then we will track even the Canadian URLs


when we show them as the American URLs in Search Console.


Yeah, it's like you pull out all your hair,


and you start scratching your head.


And it gets really crazy there.


From our point of view, it's something


where the reporting in Search Console


is confusing in cases like that.


And you might say it's wrong, because it's


reporting on the canonical, but not reporting on the one that


is actually shown.


But from an indexing, from a ranking point of view,


it should be working out fine.


If you need to have it differently,


then essentially what you need to do


is make sure that these versions of these pages


are unique enough so that we don't run into the situation


when we say, oh, we will make it easier for you


and just pick one version to index.


If we clearly understand these are absolutely unique pages,


we should index them separately.


Then we'll show them separately.


We'll index them separately.


We'll have separate canonicals.


SPEAKER 1


There is no number or anything like that.


But yeah, I think it's always tricky in a case like that,


because theoretically, from a ranking point of view,


it's OK.


It's just everything around tracking is super complicated.


MOMAN VEDIYA BASS Hi, John.


Hi.


This is Momad Veda-Bass from India.


Actually, I have just stepped into the SU industry,


and I have two questions to you.


First one is regarding domain name, sorry, domain


and subdirectory.


Suppose I have a domain called example.com,


and I have created four subdomains,


like example.one.com, like till four.


So if I host the blog for all four subdomains on the name,


how will it be from the SU perspective?


JOHN MUELLER You can do that.


I think it's something where some people use subdomains,


some people use subdirectories.


If you ask the SEO industry overall,


you will get lots of arguments in either direction.


So technically, you can do that.


From Google's point of view, you can


use subdomains or subdirectories.


That's perfectly fine.


I would, first of all, try to think about what possibilities


you have available from a technical point of view


on your side.


So if your hoster makes it really hard to put WordPress


into a subdirectory, and it has to be on a subdomain,


for example, then maybe that's kind of the first way


to get started.


And then at some point later on, you can decide,


oh, I know enough, or I can move to a different hoster,


and I can set my system up slightly differently.


But that's kind of the thing where, from a first step,


I would look more at the possibilities


that you have available and then really learn


from making a website, learn from interacting with search.


And over time, you'll see, maybe it makes sense


to put it into a subdirectory.


Maybe it's fine like this.


Maybe I want to move to a whole different domain.


Maybe I want to focus on something different


with my website.


You'll kind of grow into that a little bit more.


Second question is related to backlinks.


I have heard a lot about backlinks


that Google consider quality backlinks.


When it comes to quality, what exactly does you mean about,


does you mean for quality backlinks


and how Google analyzes between natural and paid backlinks?


Yeah, so my recommendation, I think,


especially if you're getting started,


is not to focus on backlinks.


Because it's very easy to get stuck into the situation of,


like you said, Google wants quality backlinks,


or Google wants natural backlinks.


Therefore, I will make my backlinks look like quality,


or I will make my unnatural backlinks


look like they're natural.


And it's very easy to spend a lot of time focusing on that.


So that's something where, from my point of view,


I would focus on your site first and really work to build that


up really strongly first.


And then over time, you'll see maybe there


are opportunities where you can mention your site


with other people with regards to advertising, perhaps,


with regards to other ways where you can create something


really fantastic and point that out to other people


and say, look at this cool stuff that I did.


And then they link to your page because they think,


oh, this is really neat.


And essentially, when it comes to links,


Google's point of view is that these


should be things that are not organized by you,


that are not paid for by you, that are not created by you.


But rather, they should be naturally people who say,


well, this is really cool.


I really like that.


Similar to how, if you make a website,


you probably have seen lots of other sites


where you say, this is cool.


I will link to that.


I will refer to that because it's something


useful for my users.


Thank you.


Sure.


Let me run through some more submitted questions.


And we'll definitely have more time for you all as well.


Can I prevent a section of my page


from being used in the meta description?


Google is choosing a component within the product information


as a description of a page, which reads really


odd in the search results.


Yes, you can do something there.


Namely, we have a data no snippet HTTP attribute


that you can apply to some HTML elements within your pages.


And everything that is within these HTML elements


would not be shown in the snippet.


So we call the description that you see there


the snippet in the search results page.


Oftentimes, it's based on the description meta tag.


Sometimes, it's also based on some of the content on the page


itself.


The important part is also that the description that we show,


as well as the title, they can vary for individual pages,


depending on what someone is searching for.


So if you do a site query for your pages, for example,


you might see one title and one description.


Whereas if you search the way that you


see in the performance report in Search Console,


you might see that users see something slightly different.


So before jumping off and trying to block


certain parts of your pages from appearing in the snippet,


I would double check to make sure


that this is actually something that people are seeing and not


just something that only you are seeing while you're trying


to diagnose your pages.


Will the.gq ccTLD get AdSense approval?


I have no idea.


I don't know anything about this TLD.


I don't know about the AdSense approval process.


So I have no idea.


How to increase organic traffic on new blogs?


I don't think I have a one-sentence answer


for that.


What I would recommend doing maybe


is checking out the SEO starter guides.


We have one that we've worked on for quite a while.


There are some from some of the bigger other companies


out there as well that cover a lot of the things


that you can think about with regards to SEO.


And there's definitely no single meta tag


that you can put on your pages, and suddenly you get a lot


of traffic to your site.


But rather, you really have to think about this whole thing


for a longer period of time.


How can a team technically improve


SEO when the URL was previously associated with malware?


The URL was changed to get away from that,


but still running into issues with visibility,


having our content show on Google News.


So I don't know about Google News,


but essentially malware is something that usually someone


who hacked your website, added to your pages,


and provided some bad content for people


when they go to your pages that maybe it


infects them with a virus or something like that.


And when it comes to malware, that's


something that is generally flagged by the Safe Browsing.


Safe Browsing?


I don't know.


Is it Safe Browsing?


Safe Browsing team, I think, and would


be shown as a warning in the search results


and in the browser as well.


And essentially, when that is resolved,


so you can also see that in Search Console,


and you can fix that on your site,


and we will automatically recrawl your site every now


and then to check if it's fixed.


And if it's fixed, then we will remove that warning,


and everything will go back to normal.


Also, in Search Console, you can tell us you fixed that issue,


and we'll go off and check that.


And if it's OK, then that malware warning


will be removed.


And essentially, the site is ranking


exactly the same as before.


So there is nothing that is for the longer term holding back


a site if it was hacked with malware at one point.


Usually, that's something that jumps back completely,


kind of like on and off switch right away.


That said, if a site is hacked and is


hacked in ways other than just malware,


for example, if someone adds a lot of content to your site


that doesn't belong to your site,


or if they add phishing pages to your site,


or if they add hidden content on your pages,


maybe links to other hacked pages or anything around that,


then that's something we also try to catch as hacked content,


and we try to ignore that as much as possible.


But if that remains on your site for a longer time,


then we might assume that this is actually something


that you want to provide on your site.


And perhaps you want to change your website


into a Canadian pharmaceutical.


It's possible.


It doesn't have to be the case, but it's possible.


And in a case like that, we would start ranking your site


with that amount.


And if you fix that, which I hope


you do find all of those things and are able to fix that,


then over time, we will see that as well in the content


that we've recrawled and re-indexed over time.


But that is something that is less like the real malware


where it's like a virus on a page kind of a thing,


where it's on and off, but more something where over time,


if that content is on your site for a longer period of time,


we'll associate that with your site.


And if you remove that, it takes a bit of time for us


to kind of de-associate your site from that,


to recrawl all of these pages and recognize,


oh, it's no longer a pharmaceutical,


but rather maybe a jewelry store or something else.


So that's something where there is no kind of magic thing


that you can do to have Google refresh everything


for your website.


Making sure that all of this hacked content is really gone


is kind of critical, the most important step.


Making sure that it can't get hacked in the same way,


again, is also critical, because a lot of times,


these hacks are almost automated in the sense


that there is no hacker out to try


to hack your specific website, but rather they just


want to hack any website that they can.


So that's something where you need


to make sure that you don't just remove the hacked content,


but rather you also remove the hole where they got through.


And for both of those things, I would almost


recommend getting help from someone who's


experienced with hacked sites, which


could be an expert that has worked on these for a longer


period of time.


There are various people who have done that.


It could also be as a first step going to the Search Central


help forums, where the folks there


are very experienced with websites as well,


who may be able to find some of these issues


and help you to clean out any of the remaining hacked content.


Because it can get really tricky in that if there is a security


issue on your website, then multiple hackers


could be involved.


And you might have cleaned out some of the hacked content,


but not everything.


It might be that there's still some hacked content kind


of lingering around that you don't see when you look at it


with your browser, but that Google would see


when it crawls your website.


And getting some tips and help on that


can be quite helpful and speed things up a little bit.


Wow.


OK.


Still more people joining.


OK, we're kind of getting into the last 10 minutes.


I have a bit more time to hang around if any of you


want to stick around longer.


But maybe we'll go through some of the local things here.


I see some of you are raising your hands,


so I'll just go through the list as I have it there.


Davor, I think, if I got your name.


Hi.


Just have a couple of questions, short ones hopefully.


So Core Web Vital said that field data is more important


than lab data, right?


So what happens if we fix our vitals 10 days


before the update?


How bad will that be, or will it be good,


or how will Google look at it?


Probably we would not notice that.


So the field data takes, I think,


around 30 days to be updated.


So that's something if you make a short-term change,


then probably we would not see that at the first point.


But of course, over time, we would see that again.


And it's not the case that on that one date,


we will take the measurement and apply that forever.


So if you need a couple more weeks before everything


is propagated and looks good for your users as well,


then take that time and get it right


and try to find solutions that work well for that.


The tricky part with the lab and the field data


is that you can incrementally work on the lab data


and test things out and see what works best.


But you still kind of need to get that confirmation


from users as well with the field data.


SPEAKER 2


Pictures, not preferences directly,


but we do in the image search guidelines


recommend that you use useful image names specifically


for image search.


So instead of just using a number, maybe use,


I don't know, some words kind of describing the image


as the image file name.


Yeah, we would describe what's on the picture, actually.


So that would be fine, I guess.


Is there a reason why our English article shows up


in Discover in the United States,


but our Spanish one doesn't show up in Discover in Spain?


I don't know.


I don't know the exact triggering there


from a Discover point of view, but I


could imagine that we might look at things differently


depending on the language.


But it's all kind of tricky with regards to Discover


because it's so much tied to what we see that users prefer


to see in Discover.


SPEAKER 3


Yeah, it's tricky.


OK, thanks.


And the last one is if a page is not active for two years


but they hold pretty good positions,


what will happen to them?


They're not doing actually anything and we, you know.


It depends.


Some pages remain useful over time, even without updates.


So just because a page is not being changed


doesn't mean that it's lower quality.


Yeah, OK.


Cool.


All right, Eric.


Yes, hello.


I have a few questions for you.


So first of all, we were discussing this two weeks


earlier.


If Google sees a newer, more recent article for a topic,


let's say a review or a product or whatever,


does it mean that it prefers the more fresh page over maybe


the higher quality one?


Not necessarily.


So we do try to take kind of the, I don't know,


age or the freshness of content into account for some queries,


but it's not the case that that would always apply.


And that's something that can also change over time,


where if, for example, something happens


in the news in one location, then suddenly, I don't know,


the fresher content for that location


will be more relevant for users.


Whereas if nothing has happened there for a while,


then maybe the more stable reference content


for that location would be relevant.


That's what I was hoping for, yes.


But we have a few examples of reviews


that we think are higher quality on our page


than they are on others that rank higher,


a lot higher than ours.


And it's frustrating.


Yeah, I think.


Can we somehow debug this or maybe just solve it somehow?


Change the content to be, I don't know,


fool Google into thinking it's more fresh or something


like that?


I don't think you can really do that.


I mean, what you can always do is give us


information about these kind of queries


where you think the results are bad.


But when talking with the ranking team


about these kinds of issues, they really


need to see that it's really significantly bad.


So not like my page is just as good at number five


as the page at number four kind of thing.


Really, really cool.


Yeah.


One paragraph, five lines of some copied text


versus a really big review with photos and everything.


So yes, OK.


We should contact the Google team or how would we do that?


What we could do is either post in the Help Forum.


That's one way to do that.


The folks in the Help Forum are able to look at that


and give you some tips on that as well.


And if there's something that is really weird,


then they're able to escalate that to Googlers as well.


OK, perfect.


I thought it was only the community.


OK.


And then I have another one.


Doesn't matter if we have share buttons or links


to social networks of our site, does Google


take this into account?


Maybe the like counts or the community


on other social networks?


No.


And I don't know if you can speak about analytics.


Not really.


OK, but we noticed that we had some issues with analytics


for like a year.


And I was asking that maybe, I mean,


do Google Analytics filter inputs like hits and page views


from other domains?


Like let's say our code is on someone else's domain.


And does this maybe change our statistics somehow?


I mean, I would say that it should filter it out.


I don't know.


I have actually no idea how that is handled.


I vaguely remember that there is some way to set that up.


But I have no idea.


I would double check in the Analytics Help Forum.


The folks there have definitely heard that


might have a tip for you there.


OK, perfect.


Thank you very much.


And have a great day, all of you.


Thanks.


All right, Darcy.


Yes.


Hey, John.


Quick one about the home activities schema.


Any idea if that has rolled out outside of the US


or plans to do so?


I have no idea.


Yeah.


Documentation still just says US.


I'm assuming it is.


But we'd like it in Canada too.


I don't know.


Maybe you have to move.


Usually the folks that are handling


the documentation of all of the structured data stuff,


they're pretty on top of things, changes like that.


But sometimes the teams also make changes


without telling the bigger teams at Google.


And then it's suddenly live in other locations.


We didn't hear about it yet.


But we try to keep that in sync as much as possible.


OK, cool.


Thanks.


Cool.


Mohamed, I don't know if you asked a question before


or that's something separate.


OK.


Mohamed.


Hi.


Hi, John.


This is Mohamed from India.


My question, I have two questions.


So I don't know whether this platform is the right platform


to ask.


But it's related to AMP web stories indexing on Google.


So we have two, three websites.


One is in English, obviously, and then regional sites.


But what we have seen is the English articles


get indexed very soon.


And we get the results as well.


But the regional languages don't pick up


or don't come on Google search.


And we don't get the page views.


So is there anything to do?


The question is whether there is a preference in languages


compared to English and regional languages.


And now we have tried to put English text as well


in the regional languages.


But it's not working.


So any preferences are there?


I don't know.


So especially around web stories,


I think there are two aspects that


might be playing a role there.


On the one hand, we show web stories


in that unique UI in the search results.


But that's only in certain countries.


And we also show them in Discover.


And especially the first one with web stories in the search


results with that special UI, that's


something that depends on whether or not that UI is shown


in your country, for example.


I think, for example, in Switzerland,


it's still not shown.


So I would not see that.


If someone were to make web stories specifically


for Switzerland, that would be kind of awkward


because most people here wouldn't see that.


The other part in Discover is probably


where you're seeing similar things as the question


like a while back with regards to English and Spanish content


in Discover, where these are essentially just different,


I don't know, completely different environments


or ecosystems essentially in different languages,


where it's not automatically the case that if something


in English is shown in English Discover for users in English,


that any localized version would automatically


be shown similarly.


So those are essentially completely different things.


And it's very likely, I don't know


about the languages in India, but it's


very likely that users interact with Discover differently


across different languages, where maybe in English they


look at Discover more, and they see that more often,


and your articles have more views, more clicks there.


And maybe in some other languages,


they just don't use Discover as frequently,


and therefore, your pages don't get that many views or clicks


there.


So what I would recommend doing there


is not so much trying to make your non-English pages look


like they're English as well, because then you'd just


be showing them to people who are trying to find English


content, but rather to continue to build out


your non-English content.


And especially if you know that the web stories are not


shown in the regions that you're targeting,


then maybe it's worthwhile to say I will focus more


on the regions where I know it's shown for the moment.


And then at some later point, when


you know that it is shown more in those regions,


then put more energy into those versions as well.


SPEAKER 2 OK.


OK.


Thank you.


Thank you so much.


JOHN MUELLER Sure.


Let me just pause the recording here.


I'll stick around a little bit longer.


It looks like there's still lots of questions left,


lots of raised hands.


So we can continue on a little bit.


But thank you all for your questions so far.


I hope you found this useful and insightful,


and that was a reasonably good use of your time.


And hopefully I'll see some of you


again in one of the future Hangouts as well.


All right.


Google Search Console: What should I do with old 404 errors?

Today's question comes from San Francisco.


What should I do with 404s in Search Console that are from ancient versions of my site?


So sites evolve over time, URLs change, you add redirects, redirects get dropped over the years,


sometimes URLs are just no longer needed. These URLs end up returning 404.


So they show up in Search Console as crawl errors. But what does that mean?


When an invalid URL is opened, it's the right thing for a server to return a 404


page not found error. When doing a restructuring of your website, we recommend redirecting from


old URLs to the new ones and updating the links that go to the old URLs to point to the new ones


directly. However, over time, you might decide to drop those redirects, maybe because of the


maintenance overhead, or just maybe you forgot about them. These URLs are now 404s in Search


Console. In your server logs or analytics, check for traffic to those URLs. If there's no traffic,


that's great. In Search Console, check for links to those URLs. Are there no relevant links? That's


great too. If you see nothing special in either the links or the traffic, having those pages return


404 is perfectly fine. If you do see traffic to those URLs, or see links pointing at those URLs,


check where they're coming from, and have those links point at the new URLs instead.


Or if it looks like a lot of traffic or links are going to those URLs, perhaps putting a redirect


back in place would be more efficient. That works for a few crawl errors. But what if you have a


ton of 404 errors? Search Console makes this easy. It prioritizes crawl errors for you.


If the top errors in the report are all irrelevant, you can rest assured that there's nothing more


important further down on the list. Crawl errors for 404s that you don't want to have indexed


don't negatively affect the rest of your site in search. So take your time to find a good approach


that works for you. If you found that useful, please like and comment on the video so that we


English Google SEO office-hours from June 18, 2021

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


Central Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google in Switzerland.


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


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


It looks like we have a bunch of people here today.


So that's pretty cool.


A bunch of questions were submitted on YouTube already.


So we can take a look at some of those.


But as always, maybe we can go through a handful


of live questions first to get us started.


A bunch of people are already raising hands.


So it's just super, super quick, everyone.


So good.


Let's see.


Nothing.


SPEAKER 2 Thank you, John.


So my question is, we have recently


added aggregate rating review snippet to our website.


And because of the fact that most pages in our website


share the same template, the review snippet


is now being shown in search results for most of our pages.


However, since we added the review snippet,


we have seen a decline in terms of click through rate and rank.


Could the addition of review snippet have been a factor?


Moreover, we added the rating number and rating value


present in a third party site manually into the website.


Could this manual addition have been an issue?


We have not received any warning from Google till now.


But the search performance is decreasing every day.


So what could be the issues on?


So that wouldn't be related to a drop in rankings.


But if you're adding structured data,


it should apply to the primary element of the page.


And it shouldn't be something that you just copy and paste


across the whole site.


So that's kind of the one thing there.


So if you're using the same structured data


on all of the pages of your site, that would be incorrect.


The other thing, specifically with regards to reviews,


they should be based on reviews that are actually


published on your site.


They shouldn't be kind of like hand-picked reviews


from third party sites.


So that would be essentially against our guidelines


as far as I understand it.


So both of those things are not really


in line with our guidelines.


And it's something where if someone were to manually review


that, they might flag that and apply a manual action for that.


But it wouldn't affect your site's ranking.


It would just affect how we show information for your site


in the search results.


OK, thank you, John.


Sure.


Let's see.


Ibrahim.


Yes, hello.


So I have a question about 404 pages.


We recently gained a lot of 404 pages


because we have online shop.


And so sometimes a lot of our products


we finish in the stock.


So we came to this point.


So we have temporary 404 pages and permanently 404 pages.


For permanently 404 pages, we know


that we can use 410 code, so we tell Google to just remove


from search result. But for the temporary one,


we are not sure what is the best approach.


And I would like to get your recommendation on that.


We can customize that for sure.


And we can also use 410, but we are not sure about that.


Or we just let it go.


I think it doesn't matter.


So there are different strategies


for dealing with temporary products that are out of stock.


And essentially, all of those can work for search.


So you can just mark it as out of stock.


You can use a 404.


You can put a noindex on the page.


It's essentially up to you the way that you want to handle it.


And some sites handle it in different ways,


and that's perfectly fine.


You can also say, if I don't know if it's permanent or not,


I'll just mark it out of stock and keep it as a 200 page.


And after a month, when I realize


I can't get that product anymore,


maybe I'll make it a 404.


So all of that is essentially up to you.


SPEAKER 2


So the last question I have is, it's


not going to somehow affect or impact bad on our rankings


or indexing stuff, right?


That's OK.


JOHN MUELLER No, that shouldn't.


I mean, especially if you're talking


about individual products that come in and out


of inventory, then those are the kind of fluctuations that


always happen on websites.


If you say your whole website is suddenly not available anymore,


then that's a bit trickier.


But individual products coming and going,


that's completely normal.


SPEAKER 2 OK, thank you so much.


JOHN MUELLER Sure.


SPEAKER 2 Merci.


SPEAKER 1 Ratnash.


SPEAKER 3 Well, thank you, John.


So today my question is, the question


is about where keyword placing within the page.


So basically, as we know, Google is following mobile first


indexing.


So according to that, it will crawl the site.


I mean, the Googlebot will crawl the site


as a smartphone and the desktop.


And it will give preference to whatever


the Google crawled as a smartphone,


I mean, mobile first indexing.


So now I have a page where there is a lot of content,


say 20,000 words of content.


And my focus keyword is at the bottom of the page.


So how it will impact the ranking.


Because as I know, like when the user


has opened the page on the smartphone, the real user, not


the Googlebot, so that keyword is not in the active viewport.


So unless he's crawled down, the focus keyword


will not be visible to him because it will be not


in active viewport.


So how Google can see that page, or like how


Google crawls as a smartphone, then


what is the maximum height of the viewport Google will fetch


that page as a smartphone?


Yeah.


So I would recommend if there's something


that you want to tell us that your page is about,


to make that as visible as possible.


So don't just put that as like a one word


mentioned on the bottom of your article,


but rather use it in your titles,


use it in your headings, use it in your subheadings,


use it in captions from images, all of these things


to make it as clear as possible for users and for Google


when they go to your page that this page is about this topic.


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


I would not worry about like, can Google


get to the word number 20,000 or not?


Because if you're talking about the word 20,000


and you're saying this is the most important keyword


for my page, then you're already doing things wrong.


You really need to make sure that the information that


tells us what this page is about is as obvious as possible.


So that when users go there, they're like, yes,


I made it to the right page.


I will read what this page has to tell me.


Thank you, John.


Sure.


Mohamed.


Hi, John.


Actually, a week or a month ago, I


asked you a question related to copied content.


And at that time, you suggested about DMCA


because some websites are copying our content


consistently.


But at that time, we were not aware that some of the keywords


they are ranking higher than us.


So at that time, you suggested about some factors


we have to look into our websites.


So I do not remember it properly.


So can you tell me if someone who


is copying my content consistently and ranking


better than us, so what could be the factors which we should


look into or what measures we should take into immediately?


I don't know.


It's hard to say exactly what we talked about back then.


But in general, I think the DMCA process is probably the one


that you should be looking into.


If someone is really copying your content.


And the DMCA process is a legal process.


So I can't give you advice about that.


That's kind of one of the tricky aspects there.


But that feels like the direction


that I would head there.


And with regards to why this can happen,


it's really hard to say without looking at examples.


But it's, for example, really common


that someone writes about something else


and they include a snippet or a copy of the text,


but they provide additional information.


And that additional information is valuable enough


that we would say, well, this is a page


on its own, which we will rank independently of the other one.


For example, we often see that with our blog posts


where someone like, I don't know, Barry Schwartz


will write about our blog post, maybe quote


some of the blog posts.


And essentially, he will rank his content


almost better than our content.


And from our point of view, it's like they're


copying the content, but they're also


providing additional insight and maybe questioning


some of the things that we wrote about there.


And maybe there are people that are commenting


on the other side as well.


And that provides additional value


where we'd have to say, well, it makes sense


to show this in the search results additionally.


Maybe it even makes sense to show it


above the original content.


And these are the kind of things where sometimes,


a copy makes a lot of sense.


And it does make sense to show it separately


in search results and sometimes even more visibly


in the search results.


But if you're really in that situation where you're saying,


I don't want people to copy my content,


then that's almost a situation where


you'd have to take legal steps to prevent that.


SPEAKER 2 We have opted for DMC.


But I want to ask, is Googlebot not


able to consider which content is original


and which content is copied?


Maybe I have published my content a year back


and he's copying right now.


JOHN MUELLER I don't know.


From my point of view, it's something


we can determine to a large extent.


But even if we know which one is the original


and which one is a copy, sometimes it


makes sense to show a copy in the search results.


So that's something where it can happen.


And one of the situations where I


have seen this happen consistently


is if a website is of lower quality overall, where


when our systems look at it, they're like, well,


we can't really trust this website.


But if a higher quality website were


to take some of this content and publish it, we would say,


well, we know more about this website.


And actually, maybe we should show this content


in the search results.


So that's also one of the situations


that you might be running into where maybe it's


worthwhile to also invest in improving the quality


of your website overall.


So not just that one article that apparently people like,


but also the rest of your website overall.


OK, thank you.


Sure.


Praveen.


Hi, John.


How are you?


We are doing great.


Hi.


So this question came to me from a friend of mine.


So they have this website on ccTLD domain,


which is dot info for India.


Now, they want to make this website a global website.


But as you know, ccTLD is like we cannot geotarget on ccTLD


to other countries.


So the question was, can we do, with the help of HRF link tags,


can we geotarget other countries on a ccTLD domain?


Or they need to take a different route,


like either go for dot com or something else.


So there's a difference between geotargeting


and this language regional targeting with hreflang.


With geotargeting, if we can tell


that a user is looking for something local,


then we will use geotargeting to try to promote local sites


in the search results.


With hreflang, we essentially purely focus


on the language and the region.


And we swap out the URL.


So it doesn't change ranking.


So hreflang tries to bring the correct URL in the search


results, but it doesn't change ranking.


And geotargeting can change ranking


if we think that the user is looking for something local.


With a country code top-level domain,


you can't use geotargeting for other countries.


But you can use hreflang.


And if the topic that your content is about


is not something where the local requests are


made by users in search, then using hreflang


is perfectly fine as an approach there.


AUDIENCE 2 OK, good.


Got it.


From language perspective, we can go with hreflang text.


But if there is something which is local,


then it's good to go with the local version.


Yes, exactly.


OK, so there's a follow-up question,


which is more kind of a hypothetical question.


For example, there's a global brand


which is using a.com for US and ccTLDs for other countries,


like UK for UK and.au for Australia.


And as we know, when Google analyzes the website,


it looks for overall quality of the domain, not just


a few pages.


So in a setup like this, where a website is using different ccTLDs


to geotarget where.co.uk is a website on its own.


So in that case, for example,.com


is, from a quality perspective, it's


a great website from Google's point of view.


But.co.uk is not.


It's below standard.


So can that UK website impact performance of.com in a way,


because they are interconnected somewhere through geotargeting,


and Google can figure out that they are both.


Yeah, I mean, usually they would be essentially


the same website just kind of written for the local audience.


So from a quality point of view, I


think it would be unexpected if a ccTLD website were


significantly different than a generic top-level domain,


for example.


But essentially what happens is we would rank those pages


appropriately for the user, and then swap out the URLs.


So it's not that we would say this


is one giant website across all of these different domains,


but rather we would say we will rank the pages that we know


about from all of these websites.


And then when we have a page that we


want to show in the search results,


we'll double check the hreflang annotations


and swap out the URL for whatever local one there is.


So for example, if we would never show the UK version


in the search results because it's a really terrible website


and someone in the UK were to search,


then probably from geotargeting we


would focus on the UK version of the site,


and it would rank lower.


And then with hreflang, we would swap out the URLs there.


So it's something where there's kind of this subtle mix


across the way that that would be handled.


But again, it feels like something


that's very theoretical, which is unlikely to really happen


like that.


SPEAKER 2


U.S.


Website but different with different fundamentals.


So that's asking this question.


Yeah, thank you.


Sure.


Pramod.


Yeah, hi, John.


Hi.


So my question is related to core web vitals.


Basically, I'm assessing my web pages


on different core web vitals tools,


like web.dav slash measure pages within site, Lighthouse.


And all of them are giving different values for web vitals.


So according to you, which tool we


should use to improve the web vitals for our website?


We are basically a bit confused.


Yeah, whichever one works best for you.


So there's one thing I think which is really important


is we differentiate between what users actually see


and what the testing tools say.


And for search, we use what users actually see.


We call that the field data or the real user metrics.


And the testing tools that are out there,


they use kind of like their own personal tests.


And that is called lab data.


We would call that.


And all of these lab data testing tools,


they try to approximate what a user might see.


But they can't know for sure what users will actually see.


And sometimes your users will see something different


than what our lab tools assume that users will see.


So that's, I think, really critical when


it comes to core web vitals to understand


that difference between what the testing tools show


and what Google would use.


What Google would use is in Search Console in the Page


Experience Metrics section there.


And that's something you would also see in the Chrome User


Experience Report, which is a separate site as well.


The different testing tools can make different assumptions


with regards to what they think users might see.


So you would see differences there.


My recommendation is to use the real user metrics


as a way of recognizing, is there a problem


or is there not a problem?


And if there is a problem, then to use the different testing


tools to try to figure out where this problem might


be coming from and what you might


need to do to improve that.


So it's more like the data in Search Console


is used as a directional sign saying everything is good


or everything is bad.


And then you use the different testing tools


to figure out what exactly you can do to improve things.


And some tools are easier to use.


Some tools have more detailed information.


Some tools are faster to run or easier to use.


So it's something where you need to find the tools that


work well for you.


In general, they all go in the same direction.


But you would not expect to see exactly the same number


in the different measurements for all


of these different tools.


OK.


Sure.


Raunauk.


Oh my gosh.


I probably sent your name wrong.


Sorry.


That's fine, John.


So it's Raunauk.


Hi, John.


So I had a question about disavow list.


So back in 2014, actually, we disavowed more than 5,000 links


because of a manual action.


And recently, in March, so three months ago,


we submitted around 300 links, again, on the source console.


And somewhere around that time, we


started noticing a significant reduction


in SEO traffic and rankings.


So it accounted to about more than 30% loss in traffic


in 90 days.


So do you think our action in March


could have caused an impact on our Google rankings?


If so, how would you recommend fixing this issue?


I think it's theoretically possible


that it had an effect like that.


But I think it would be rare that that would happen.


So in particular, it could happen


if you take all of the most important links to your website


and you submit those in a disavow file.


Then I could imagine that our systems say, well,


there are no really good links for this website anymore.


Therefore, we will have to be a bit more cautious with regards


to how we deal with this website.


But if you're looking at the links before submitting


the disavow file, if you're really going through and only


submitting things that are actually problematic,


then that would not be a negative factor


for your website.


OK, that makes sense.


Yeah, thanks, John.


Sure.


John, can I add something on this?


So if, suppose, I have already submitted the list


and it is not working well, what will


be the effect of reverting back?


So will reverting back and forth send some back signal


to Google?


No.


The disavow file is purely technical for us.


It's purely a sign saying, don't take these links into account.


And we reprocess that when we reprocess the external pages.


So it's basically like just saying, well, use these links


or don't use these links.


It's not a sign saying, I am a spammer


and here is proof that I was a spammer.


It's really just purely saying, I


don't want you to use these links for whatever reason.


And the reason is totally up to you.


It's not something that our systems will judge.


So the number of iterations don't matter?


Yes, exactly.


Yes, thank you, John.


Sure.


Nikolai.


Hi, John.


Thank you.


Hi.


I represent the Ukrainian news agency


and our site has a monthly audience of 11.5 million users.


It is licensed as a news agency.


Ukrainian top officials give us interviews regularly.


The content is 70% exclusive.


We have about 90%, 95% page speed insights.


Our media outlet always tries to adhere


to recommendations regarding search engine optimization.


Since January 2021, we have fallen down in search results


for the case related to politics issues from the top one


to the third page of search results or even deeper.


And our stories on politics and economics


have ceased to be included in the Google Discover.


The rest of the content from our own domain


is still in the top and gets into the Google Discover.


We have received no letters about function from Google.


So we have also noticed that during the same period of time,


many low quality sites were stealing content from us.


Please tell us, what can we do to change the situation as we


keep losing our traffic and money?


Yeah.


I don't know offhand.


So I think, first of all, I don't have much insight


into the Google News side of things.


So if you're seeing effects that are kind of tied to the way


that Google News processes a website,


I don't really have much insight there.


That would be something where you'd


need to go through the Google News contact in, I believe,


the Help Center for Google News for Google News publishers.


Otherwise, I'm happy to kind of forward your issue along


if I can get more information from you


with regards to which site it is and what specifically


you're seeing.


So my recommendation would be, I think you posted also


in the YouTube comments.


My recommendation would be if you


could add a little bit more detail there,


then I can pass that on to the team.


And they can take a look to see if there's


something specific on our side that we need to adjust.


OK, so we can just post it here, yes, in comments.


Yes, please.


OK, thank you so much, John.


Sure.


Let me run through some of the submitted questions as well.


I realize there's still lots of people with their hands raised.


But just to make sure that the submitted things are also


taken care of a little bit, I recognize


some of the questions here.


So there's a little bit of overlap here.


I also have a bit more time afterwards if any of you


want to stick around and still have questions


that we need to get through.


Let's see.


How much influence does direct traffic


have in terms of Google taking it as a signal


and ranking content from the website?