So here are some examples of things


Improving Search Over the Years (WMConf MTV '19)

that we've done over the years.


In some cases, I worked to create the problem that


underlies this.


In other cases, I worked on the solution.


And in some cases, just work by other folks.


And I'm presenting it because it's a good story.


So first, I'm going to talk about something


in one of our language understanding systems, which


is the synonym system.


And so what is our synonym system?


It's something that is there to bridge


a gap between user vocabulary and document vocabulary.


That is, when we see a query, it often


is written in a different language than the documents


use.


And we're trying to match those things.


The way this actually works is it


looks a lot like we had a bunch of terms with OR.


Who here in the audience has used the OR operator?


You're experts.


So there are probably a bunch.


Not many people use it these days.


Back in 2002, 2003, back in the Alta Vista days in the late 90s,


you really needed to use OR a lot in your searches.


And the way our synonym systems work is, effectively, we


take a user query, and we add a lot of OR terms to it.


And this is actually one of Google's most important ranking


components, that it's something that we launched


roughly 15-plus years ago.


It has improved a lot over the years.


I'll give you one example here, which


is, if you do the query, cycling tours in Italy, what we actually


search for is cycling, or cycle, or bicycle, or bike, or biking.


Tours turns into tour, or holidays, or vacation.


The in, I didn't mark up, but we actually allow,


that's what we call a stop word, so we're


willing to drop it.


And then Italy, we say Italy or Italian.


And you'll notice that bike holidays in Italian


doesn't make sense to a reader.


But Italian bike holidays might.


So that's why that shows Italian shows up there.


These are also synonyms are not just straightforward rewriting,


because they're actually done in context of a full query.


So in the context of truck, GM turns into General Motors.


In the context of baseball, it turns into General Manager.


In the context of various foodstuffs,


it turns into genetically modified.


And so there's a little bit of smarts in the system


to try to understand not just an individual word,


but a whole query.


And I just want to make clear that this is not


the same as something that's trying to provide synonyms


for actual content, because this is not a thesaurus equivalent.


It doesn't work that way.


And it's really designed just to help


you find good search results.


So it's hidden behind the scenes mostly.


There are some ways you can probe at it.


But mostly, we hope that from an optimization perspective,


you don't need to pay attention to it.


From a user's perspective, you don't


need to pay attention to it.


And it's really unimportant whether these are actually


synonyms to a human reader.


One of the secrets of the synonym system


is actually that, for a long time,


I don't know if this is still true or in what context


this is still true, we considered buy and sell


synonyms.


Because if somebody was looking to buy something,


a page that was selling it was actually good, and so on.


But, and this was one of the bugs, in 2005,


the top result for United Airlines was continental.com.


Now, before people say, but wait, didn't they merge?


Yes, they did merge.


It was 2010.


We don't think it was our fault. We really hope it wasn't.


There were a number of bugs involved in this.


But the big one was that we were actually


rewriting United Airlines as United or Continental Airlines


or Air or Airline.


There were some other things that


sort of removed some safeguards.


And those were my fault. The synonym system bug


here was not my fault.


And so how do we learn this?


Or how do we fix this is actually,


we want algorithmic solutions.


We did not go in and say, OK, we're


going to prevent this synonym from happening.


We do not manually block these problems.


We want something that scales.


We want something that's going to attract


or that's going to affect similar problems


across the entire synonym system and so on.


So we want to look for patterns of failures.


And so what we were doing here, we learned that, yes, people


use United and Continental in very similar ways, which


is how our synonym system learned it.


That is, they are interchangeable.


If you look at words as the meaning of words


is defined by their context, which


is the sort of linguistic notion or philosophical notion


of the word, they are interchangeable.


Or philosophical notion of how you


understand the meaning of words.


But occasionally, when you do this,


you will find what we call siblings, which


are two words that serve similar roles


but aren't at all interchangeable.


And rival siblings is something that happens a lot.


So how do we solve this?


And again, we started looking at the searches


that people were doing.


And it turns out that people compare synonyms, compare


siblings to each other.


So we actually looked through our query stream


and looked for things where people


were comparing United versus Continental,


or Canon versus Nikon, or Beatles versus the Stones,


and said, these things are actually bad synonyms.


And it turns out that was the beginning of a solution


to this one.


The only problem with it was, and it worked,


and we learned that we had been synonymizing cat to dog.


And we learned that we had been synonymizing part time


to full time.


And these were all bad things to do.


But in the process of fixing this,


we also lost some really good synonyms.


We learned that sign in and sign on were siblings in some sense,


probably because people were comparing


the usage of those two words.


And that address and contact, which are actually


really good synonyms to have in a whole bunch of places,


were bad synonyms.


So this sort of process of looking at the data,


running some experiments, evaluating the results,


and repeating and repeating gets us to a point


where we're happy with the trade-off between what this


helps us with and what this hurts us with.


And so where I'd summarize this one,


or generalize from this one, is that understanding patterns


of failures can be very useful in fixing


your problems like this.


I think the rigor of not doing manual patches


over algorithmic problems and looking


for algorithmic solutions really helps us keep things general.


And this is just sort of an example of where,


one of the places where we did that.


And we have these issues multiple times every day


where it's like, oh, this is one little stupid thing.


Should we just fix it?


And the answer tends to be no.


And we tend to be pretty rigorous about that.


But then also the side of every change we do


has wins and losses.


And Feroz is in the back, one of the ranking leads.


And he'll tell you that if you get a 6 to 5 win-loss ratio,


you're really happy.


So understand that everything we do


is sort of approximate and probabilistic like that.


Another thing I'm going to talk about,


next example I want to talk about is something called


non-compositional compounds.


And I'll get to what that means in a second.


But I want to just point out that the original version


of this was actually done by Ben Gomes, who's currently


the SVP who leads search.


So he was a working engineer at one point, at least.


So information retrieval, which is sort of the basic area


that I work in, that Google Search is based on,


core underpinning of all search engines really,


is mostly about matching and counting words and things


like, are the words in the title or the body?


Are the words in links?


What is the frequency in which they occur?


And things like that.


And you have to understand that's where everything starts.


And so relevance just comes from matching words.


So consider these pages and the query New York hotels.


Oh, I should mention a little notational thing.


I put queries in brackets because that's


our internal convention.


So if you see something in square brackets,


that means it's a query.


So these are pages that Google, at least today,


thinks are good for New York hotels.


And you might be able to recognize them or not.


And again, you have title hits, you have body hits,


you have links, et cetera.


They mention the words the right amount, all these things.


And nothing surprising there.


And now the question is, are these pages


good for York hotels?


And if they're not, why not?


Because they say York every time they say New York.


And they've got all the same counts and frequencies


and so on.


And this is where I'm going to introduce actually


what the notion of compositional and noncompositional compounds


are.


So compositional compound is a phrase of two or more words


where the words in the phrase have


the same meanings inside the compound or inside the phrase


as they do elsewhere in their conventional meanings.


And a noncompositional compound is one


where the meanings differ.


And so New York is noncompositional.


And the observation is that even though it's


formed by compounding New and York, and at one point,


the city was named after the city of York,


there's nothing really York-related now.


But you should note that not all place names follow


the same rule.


You don't talk about New York as York.


But you do talk about Vegas as Las Vegas.


You do talk about New Jersey as Jersey.


So it's not like this is a rule about place names.


There's something more specific going on.


And the question was, could we figure that something out?


And here is what we built. We started


with a set of two-word phrases.


There are three-word noncompositional compounds.


Turns out not to be as much of a problem.


Look at pages where they occur.


If on a lot of those pages only one of the underlying words


appears, you probably have a noncompositional compound.


And you need to get the counts right and the ratios right.


But for New York, new appears alone on a lot of those pages.


People will talk about a new thing in New York.


But York appears alone on very, very few of those pages.


And you can look at the ratios there,


and you can look at the ratios on compositional compounds,


and they're very, very different.


And that lets you distinguish them.


And then what do we do once we have


noncompositional compounds?


Well, we actually built something special


into our retrieval system that says,


if you see York hotels, because York


is part of this noncompositional compound,


don't match York if the word to the left of it is new.


And it's this really funky thing that we actually didn't realize


we needed in the system.


But it turned out to be useful.


So note that this is a very, so some lessons here.


First of all, this is an edge case.


It is very, very hard to predict in advance


if you do an information retrieval system


that you're going to have this problem until you've


seen the problem.


And then once you've seen the problem, you can't unsee it.


You can't forget it.


Once seen, it's actually pretty obvious


that there's a general pattern here.


Here are a couple of other ones where this solution triggers


today in ranking.


Fantasy game is not Final Fantasy.


View office is not Mountain View.


And we've had problems with both of those.


If you turn the system off, we actually get those wrong.


So the hard work here, it's done all offline.


It's done all by looking at building a language model


to understand what are the phrases in this category.


And then there was a very small change


in how our code works at serving time to support this.


One more example.


So I said that these three examples are about language.


This is a way that probably people don't think of language


as evolving.


But if somebody had sent you the rolling on the floor laughing


emoji in 1996, would you have known what it meant?


And I'm going to bet probably not, because emoji didn't


appear till the next year.


But who here has not used an emoji today in a text?


A couple of us.


Or received one?


OK.


So I'm not the only old person in the room.


So people use emoji all the time.


People actually use emoji a lot without knowing


what they mean.


And so they search for emoji and try


to figure out what they mean.


And of course, that would be our job.


Unfortunately, for a very long time,


we completely ignored emoji and all other special characters


because nobody searches for them.


And it is actually expensive to index them


if they're not searched for.


One of our biggest costs is the amount


of storage used in our index and how we manipulate the index


as we build it.


So we just didn't have any information.


So if you searched for a smiley face,


we just didn't find anything.


If you search for a smiley face and the word smiley face,


it sort of worked.


We turned what the words smiley face returned.


And most of the time, that worked.


If you searched for smiley face and meaning,


we found dictionaries.


And I guess you could look up emoji


in some of those dictionaries.


And that would maybe sort of work.


But it wasn't a great experience.


So there were sort of two reasons


why this ended up being a very difficult thing for us to do.


First is changes to actually what we index


are incredibly difficult for us to pull off logistically.


And it's that we first have to update indexing to allow emoji.


Then we have to wait for all the documents in the index


or enough of them to be re-indexed.


And then we change how queries are handled.


But first, we actually had to make the argument


that it was worth it to do.


Because again, big expense, lots of process in changing things.


And the argument that we actually ended up making


was people are searching for emoji greater than a million


times a day, even though it doesn't work.


And eventually, that argument worked.


So we did this.


It took literally over a year to do.


After the data was in the index, we fixed query parsing.


We ran some evaluations.


And there were some very negative results.


And it turned out there were lots of other systems


that needed to be updated before we launched.


Link processing didn't know how to deal with these things.


So a link to a site that used an emoji, we didn't see the emoji.


We didn't see the text.


It was all bad.


Spelling, if it's on emoji in the query,


it thought, this is just garbage.


We're going to drop the whole thing.


Autocomplete didn't know about emojis and so on.


So it took actually just time going through dozens of systems


and making sure they were ready to deal with this data


and fixing them and so on.


While we were at it, we actually fixed it for math symbols.


Someone else added punctuation.


So there's actually more than just emoji.


It does work.


You can search for emoji today.


The points I'd make here are things


which look easy from the outside can be a lot of work


to implement.


And those stupid assumptions you bake into your code


20 years ago, they will come back and bite you.


Nobody thought about emoji when we started this process.


Anyway, and by the way, this was the search emoji team


out on our launch celebration launch.


So that is what I was going to talk about.


How Alamy’s website migrated to React

No!


How Alamy’s website migrated to React

We come on SEO.


How Alamy’s website migrated to React

I will stay a developer forever.


How Alamy’s website migrated to React

Hello, and welcome to another episode of SEO Fairy Tales.


How Alamy’s website migrated to React

With me today is Roxana Stingo, who is the head of SEO


How Alamy’s website migrated to React

and search at Alamy.


How Alamy’s website migrated to React

You also play a lot of Minecraft in your free time,


How Alamy’s website migrated to React

and you used to do competitive Scrabble for the, what was it,


How Alamy’s website migrated to React

Romanian Scrabble Federation?


How Alamy’s website migrated to React

Yeah.


How Alamy’s website migrated to React

How did you get into competitive Scrabble?


How Alamy’s website migrated to React

Oh, it's actually a funny story.


How Alamy’s website migrated to React

We used to play in the back of a bar,


How Alamy’s website migrated to React

and my dad wanted to meet with his friends to have a beer,


How Alamy’s website migrated to React

and he would just drop me off to play Scrabble.


How Alamy’s website migrated to React

Wow, OK, that's pretty cool.


How Alamy’s website migrated to React

And then you just made that a thing into the, OK,


How Alamy’s website migrated to React

competitive Scrabble.


How Alamy’s website migrated to React

That sounds fun and tricky.


How Alamy’s website migrated to React

Another thing that is fun and tricky is technical SEO.


How Alamy’s website migrated to React

That's what we're going to talk about today.


How Alamy’s website migrated to React

What kind of challenge did you experience that you would


How Alamy’s website migrated to React

like to talk about today?


How Alamy’s website migrated to React

Yes, so we have a very old website.


How Alamy’s website migrated to React

It's been online for about 20 years.


How Alamy’s website migrated to React

That's awesome.


How Alamy’s website migrated to React

That's not a bad thing.


How Alamy’s website migrated to React

It's a.net platform.


How Alamy’s website migrated to React

And we're now trying to improve it, make it faster,


How Alamy’s website migrated to React

and we're moving it to React.


How Alamy’s website migrated to React

Oh, wow, that must be a challenge.


How Alamy’s website migrated to React

Like a 20-year-old website into React,


How Alamy’s website migrated to React

that sounds like a big undertaking.


How Alamy’s website migrated to React

It is.


How Alamy’s website migrated to React

But another thing about Alamy, it's a massive website.


How Alamy’s website migrated to React

We have 300 million products because we


How Alamy’s website migrated to React

sell stock photography.


How Alamy’s website migrated to React

Millions, wow.


How Alamy’s website migrated to React

Yes.


How Alamy’s website migrated to React

But good thing is everything is a template.


How Alamy’s website migrated to React

So most pages are just a couple of templates, and that's it.


How Alamy’s website migrated to React

So that makes it a bit easier.


How Alamy’s website migrated to React

We're trying to also adopt SPA, single-page application,


How Alamy’s website migrated to React

to make it faster for our users, but also


How Alamy’s website migrated to React

because it is templated.


How Alamy’s website migrated to React

It works well.


How Alamy’s website migrated to React

GIANT.


How Alamy’s website migrated to React

STAYT.


How Alamy’s website migrated to React

S.


How Alamy’s website migrated to React

All right.


How Alamy’s website migrated to React

You're using React.


How Alamy’s website migrated to React

You want to build a single-page application.


How Alamy’s website migrated to React

So you're probably going to choose client-side rendering.


How Alamy’s website migrated to React

Yes and no.


How Alamy’s website migrated to React

OK, good.


How Alamy’s website migrated to React

Good answer, yes.


How Alamy’s website migrated to React

So we're doing server-side for all bots,


How Alamy’s website migrated to React

and we're doing client-side for our clients.


How Alamy’s website migrated to React

But we're keeping parity between the two.


How Alamy’s website migrated to React

Dynamic rendering, then.


How Alamy’s website migrated to React

Yes.


How Alamy’s website migrated to React

Ooh.


How Alamy’s website migrated to React

And what happened?


How Alamy’s website migrated to React

Where did this not go smooth and well?


How Alamy’s website migrated to React

So we do all our checks on staging.


How Alamy’s website migrated to React

We're now moving our search pages.


How Alamy’s website migrated to React

These are pages that return images for a key term.


How Alamy’s website migrated to React

But because we have so many images, we have a set of results that's usually very large.


How Alamy’s website migrated to React

So we split it by 100 results per page and we use pagination.


How Alamy’s website migrated to React

So this would be the equivalent of any category page on any commerce website works the same way.


How Alamy’s website migrated to React

When we were checking the new React implementation, our crawler was showing us certain results for page 2, 3, 4 of the paginated series.


How Alamy’s website migrated to React

But our manual checks were showing us different results.


How Alamy’s website migrated to React

So manually we were seeing in React what coincided with the live website.


How Alamy’s website migrated to React

So what we wanted to see.


How Alamy’s website migrated to React

But during the crawl, we didn't.


How Alamy’s website migrated to React

So we were trying to figure out why would there be a difference.


How Alamy’s website migrated to React

Right. And when you say you checked manually, you mean like you visited the website with a certain user agent?


How Alamy’s website migrated to React

Yes.


How Alamy’s website migrated to React

And that did not differ from what users were seeing, but differed from what the crawler was seeing.


How Alamy’s website migrated to React

As a regular user and as Googlebot in the browser using a user agent emulator, it looked completely fine.


How Alamy’s website migrated to React

But then when crawling with one of our crawler tools, it looked completely different.


How Alamy’s website migrated to React

Which tool was that?


How Alamy’s website migrated to React

Screaming Frog.


How Alamy’s website migrated to React

Screaming Frog. All right.


How Alamy’s website migrated to React

And okay.


How Alamy’s website migrated to React

I already have like a few ideas of what might have been going wrong, but I don't know.


How Alamy’s website migrated to React

So what did you do to figure out what was happening? Or could you figure out how to reproduce it to begin with?


How Alamy’s website migrated to React

So yeah, that's the hard part because we could only do it in the crawler.


How Alamy’s website migrated to React

So even if we talked to our QA, it was, you know, how to use the crawler to see.


How Alamy’s website migrated to React

Exactly.


How Alamy’s website migrated to React

So then I'd be lying if I said it was me who actually figured it out, it was somebody in my team.


How Alamy’s website migrated to React

Can be more proud of her.


How Alamy’s website migrated to React

And she said, okay, what's different between what we're doing in the browser and what we're doing in the crawler?


How Alamy’s website migrated to React

We're using Googlebot as a user agent in both.


How Alamy’s website migrated to React

What would be the difference?


How Alamy’s website migrated to React

And then something, you know, made her think, maybe it's cookies.


How Alamy’s website migrated to React

Oh, see, that was not even in my list of hypotheses.


How Alamy’s website migrated to React

All right.


How Alamy’s website migrated to React

That's usually not in any SEO's list of hypotheses because we don't really pay attention to cookies, do we?


How Alamy’s website migrated to React

Not really.


How Alamy’s website migrated to React

You know, Googlebot is not going to pick our website cookies anyway, so we don't care about them.


How Alamy’s website migrated to React

But this is where the difference was.


How Alamy’s website migrated to React

Even though we were simulating Googlebot in the browser, the browser does store cookies.


How Alamy’s website migrated to React

So then the way pagination was showing was dependent on those cookies.


How Alamy’s website migrated to React

What is pagination?


How Alamy’s website migrated to React

Pagination dependent on cookies.


How Alamy’s website migrated to React

That is wild.


How Alamy’s website migrated to React

It is not actually because I did a bit of Googling.


How Alamy’s website migrated to React

And it turns out a lot of developers use this as a solution to create pagination.


How Alamy’s website migrated to React

So it's not really far-fetched from a development point of view.


How Alamy’s website migrated to React

Oh, okay. Fair.


How Alamy’s website migrated to React

But from an SEO point of view, we don't think about it.


How Alamy’s website migrated to React

Honestly, from a developer point of view, I've never thought of using cookies for pagination.


How Alamy’s website migrated to React

Okay, so what did they do exactly there?


How Alamy’s website migrated to React

How did that work?


How Alamy’s website migrated to React

So our internal search engine is very complex, as you can imagine, to handle so many products.


How Alamy’s website migrated to React

And it stores different values for the search and the filters in these parameters.


How Alamy’s website migrated to React

And we pass those on as a cookie.


How Alamy’s website migrated to React

Rather than the URL parameters.


How Alamy’s website migrated to React

And we use that to kind of determine what's the search and what page number do we need from that result, from that set.


How Alamy’s website migrated to React

And then we pull it in.


How Alamy’s website migrated to React

Which means that if the cookies are missing, you're seeing very different things and probably not...


How Alamy’s website migrated to React

How did that manifest?


How Alamy’s website migrated to React

Like, what did you see when you were using the crawler?


How Alamy’s website migrated to React

So page one, the first page of results was identical in both cases.


How Alamy’s website migrated to React

But page two in the crawler was showing completely different results than what we had on live.


How Alamy’s website migrated to React

But not like page one again, it was just showing completely different...


How Alamy’s website migrated to React

No, page one was fine in both cases.


How Alamy’s website migrated to React

Right, but it wasn't showing the same for all the different pages when cookies were not present.


How Alamy’s website migrated to React

No.


How Alamy’s website migrated to React

So it was randomly kicking results instead of picking the ones that it should have.


How Alamy’s website migrated to React

So I'm not quite sure.


How Alamy’s website migrated to React

That's wild.


How Alamy’s website migrated to React

I'm sure it wasn't random. There must have been some logic.


How Alamy’s website migrated to React

There must have been some logic. It's just hard to determine the logic.


How Alamy’s website migrated to React

Interesting.


How Alamy’s website migrated to React

Do you know how your coworker figured this one out?


How Alamy’s website migrated to React

Was it just like a hunch, like a eureka moment?


How Alamy’s website migrated to React

Like, oh, cookies. Or did they use some sort of tool or process?


How Alamy’s website migrated to React

Or how did they come up with the solution that it is?


How Alamy’s website migrated to React

Well, she thought initially, what's different between a user and Googlebot?


How Alamy’s website migrated to React

And that's the only thing that she needed to figure out.


How Alamy’s website migrated to React

Like, wait a minute, cookies.


How Alamy’s website migrated to React

Yeah, because Googlebot would not store cookies while a user would get them in the browser.


How Alamy’s website migrated to React

Like, just coming up with that idea is awesome. That's really, really cool.


How Alamy’s website migrated to React

Sweet. All right. So you identified cookies to be the culprit.


How Alamy’s website migrated to React

Then what happened next? Because you needed to resolve the problem.


How Alamy’s website migrated to React

So once we knew it was cookie-related, we passed on that information to our QA team.


How Alamy’s website migrated to React

And we told them, this is what we're seeing. This is what we're expecting to see instead.


How Alamy’s website migrated to React

And we think it's cookie-related because the moment we clear our cookies and refresh the page, we get the correct results.


How Alamy’s website migrated to React

All right. And then they were like, oh, yeah, it is cookies.


How Alamy’s website migrated to React

And then developers had everything that they needed?


How Alamy’s website migrated to React

Or was there a conversation that was necessary to get developers to choose a different solution?


How Alamy’s website migrated to React

They told us, okay, we use cookies. We pass this query term from the parameter from the internal search engine.


How Alamy’s website migrated to React

We do pass it on, and then we look at that.


How Alamy’s website migrated to React

And if it has a value, we then look at the page number we're requesting and get it from that result set.


How Alamy’s website migrated to React

But we told them we can't do it that way because Googlebot is not going to store that cookie.


How Alamy’s website migrated to React

And not just Googlebot. I mean, any bot is not going to store that cookie.


How Alamy’s website migrated to React

So we need a different way of doing it. So we do get parity between user and bot.


How Alamy’s website migrated to React

How did they achieve that? Did they switch to URL parameters?


How Alamy’s website migrated to React

It was actually a very simple fix. If you look at the code, it's just they added a condition where they do accept that the query term, that parameter is passed on as null.


How Alamy’s website migrated to React

So it's not actually passing on any values.


How Alamy’s website migrated to React

Ah, that was all that was necessary.


How Alamy’s website migrated to React

And that was it. A very simple solution, I might say.


How Alamy’s website migrated to React

Okay, that is amazing. That's really, really cool.


How Alamy’s website migrated to React

So just to recap, you were seeing something that happened only in the crawler, not in manual testing, even if you switched the user agent.


How Alamy’s website migrated to React

And then you were basically looking at, okay, so your coworker was looking at, okay, so what's different between the crawler and the Googlebot as well and the normal user?


How Alamy’s website migrated to React

And that is how you determine, oh, it must be something that happens in the browser that doesn't happen in the crawler or bots, cookies being one of them.


How Alamy’s website migrated to React

Could have been something else, to be honest, but it was cookies in your case.


How Alamy’s website migrated to React

And then you verified that by deleting your cookies and saw the same thing.


How Alamy’s website migrated to React

So you basically established a baseline truth before you went on.


How Alamy’s website migrated to React

And then you could use that to get the developers to fix it.


How Alamy’s website migrated to React

And the fix in this case was just to be more lenient to what they expected or accepted as data from cookies.


How Alamy’s website migrated to React

That is a wild ride.


How Alamy’s website migrated to React

It is because I don't think it's the kind of bug that I will ever see again or maybe most people will never see again.


How Alamy’s website migrated to React

But things like this do happen once in a while. So it's good for us to kind of keep in mind cookies are being used.


How Alamy’s website migrated to React

Just generally, I think the thing that a lot of people are not super aware of is you need to know the differences between the different platforms as in crawlers, bots, your actual browsers.


How Alamy’s website migrated to React

And even within browsers, it could be like someone disables cookies.


How Alamy’s website migrated to React

There are plugins in browsers that make you disable cookies for privacy reasons, for instance.


How Alamy’s website migrated to React

And then these users would see the same wrong behavior, which you don't want.


How Alamy’s website migrated to React

So that's really, really cool. And it's a good reminder to always think about where could be edge cases that you might not foresee.


How Alamy’s website migrated to React

And then basically go on this wonderful treasure hunt.


How Alamy’s website migrated to React

That's really, really cool.


How Alamy’s website migrated to React

All right, Roxana, that has been a wild ride through a murder mystery of cookies, basically screwing up your internal search engine result pages.


How Alamy’s website migrated to React

I think that was a really interesting story because it does remind us to be very careful about how different, different settings can affect our products.


How Alamy’s website migrated to React

You all out there, let us know if you had similar issues that were very surprising or were caused by browsers behaving different than crawlers and what these were in the comments.


How Alamy’s website migrated to React

Also, leave us a like and do subscribe to Search Central on YouTube here.


How Alamy’s website migrated to React

If you want to see more of our content in the future, there's more episodes coming up as well.


How Alamy’s website migrated to React

And thank you so much, Roxana, for being here with me today.


How Alamy’s website migrated to React

Thank you for having me.


How Alamy’s website migrated to React

And all of you out there, thanks for watching and stay safe.


How Alamy’s website migrated to React

Take care and bye bye.


How Alamy’s website migrated to React

On the dark side, we have cookies.


How Alamy’s website migrated to React


JavaScript SEO office hours March 25th 2020

Instant.


Interesting.


The more you learn.


All right.


Hi, everyone, and welcome to the first official JavaScript SEO


office hours.


Martin Splitz.


I am working in the Search Relations team in Zurich,


currently working from home, as you can probably tell,


which is probably what most of you are also doing.


I'm guessing COVID has pretty much reached a global working


from home peak at this point.


And this is our opportunity to discuss JavaScript SEO


specific questions.


If you have questions that are not related to JavaScript,


I've seen a few people who are already asking questions


on YouTube that were not really fitting this format.


Also, the regular office hours that you


can use to ask some JavaScript questions.


So don't worry about it.


If you don't have anything specific to JavaScript,


you might still learn something today.


Cool.


In that case, any one of you wants


to ask a question already?


There, I see 20 people showing up.


That's really cool.


I have a question.


Sure.


So let me see if I can also type it here.


So my question is, if you use robot attacks to block JS


or CSS, external JS files, CSS file, in other domain,


or it's in other domain that blocks in,


so user will see different things in Googlebot, right?


So would Google distrust this kind of page


and downrank them?


That's a very good question.


Thank you very much.


No, we won't downrank anything.


It's not cloaking.


Cloaking very specifically means misleading the user.


Just because we can't see content doesn't necessarily


mean that you're misleading the user.


It is still potentially problematic


if your content only shows up when


we can fetch these resources and we don't see the content


in the rendered HTML because it's blocked by robots.txt,


then we can't index it.


If there's content missing, we can't index that content.


So it's definitely worthwhile trying out our testing tools


to see if the content that you want us to see on the page


is actually visible on the page, even though some


JavaScript or CSS resources might be roboted.


But generally speaking, roboting JavaScript or CSS resources


isn't per se a problem.


It can be a problem if we can't see the content,


but it is fine from the standpoint of cloaking.


It's not cloaking.


I see.


So from what I heard, what you mainly said,


if the JavaScript only do enhancement,


like make it beautiful or like change it,


there won't be a problem.


But if JavaScript later inserts some text or something,


there will be a problem?


Yes, correct.


If the content is loaded by JavaScript


and we can't load that JavaScript because it's roboted,


we're not going to see it that is potentially problematic.


But if it's like an enhancement, let's say like a chat box


or a comment widget that allows users to add something


to the page that isn't visible immediately anyway,


then that isn't an issue.


So in this case, if we load something in,


is that a penalty for doing that?


Or it's just that the thing that we load won't be right?


It's just that we don't see the thing that you


load if you robot it away.


Thank you.


You're welcome.


Very good question.


I'm also trying to keep notes on the questions,


but actually I have the recording.


But if you hear me type, then that's


because I'm trying to keep tabs on the questions being asked.


Awesome.


Anyone else having a question?


Hello, Martin.


Hi.


Hey, I'm Bahan, lead developer at Search Engine Journal.


So today we have implemented the infinite scroll on mobile.


And in the past, we had it on the desktop.


And my concern is, would Google index the infinite scroll


articles as part of the main article, which is opened first?


The Ajax URL, which the page queries,


has a new index applied.


But is there any guarantee that the appended content will not


be indexed as a part of the main web page?


Very good question.


The answer is it depends on how it's implemented


and how we see it in the rendered HTML.


I would highly recommend checking out the testing tools


to see the rendered HTML, because it depends a lot on how


you build your infinite scroll and how we can discover


additional content.


But if it's like, for instance, using some sort of link that


tells us to go to another URL, and then that URL is no index,


then we would not see that content.


The feature is implemented the following way.


When you scroll down, it loads the article through Ajax.


At some point, when you are about to end reading the article,


but the Ajax URL, which sends the content of the next article,


has no index, a header tag applied.


So that makes me really happy.


That makes me somehow confident that the appended content will


not be indexed.


But I would like to know how we can make sure


that infinite scroll articles will not be indexed


as a main part of the article.


Test.


Is there a certain trick I'm testing?


It really depends on the exact.


So the way that you describe it, it can go either way.


I don't know.


I'm not fully sure how we see the rendered HTML.


Use the testing tools.


Specifically, the URL inspection tool


can help you figure out how the rendered HTML looks like.


If the rendered HTML somehow still contains


the additional content because the viewport has changed


or something like that, then we would index it


as part of the main page, as in the page that you've seen.


And then no indexing, that doesn't really help that much.


It can also be that you accidentally no index


the content that was previously on the page


so that you might end up in no indexing too much.


I would always test these things and look at the rendered HTML.


The rendered HTML tells you what we are seeing.


You can use the URL inspection tool


to see what we have crawled.


So you see it in the crawled rendered HTML.


But you can also use the live test


to see what we see if we would do it again.


So it depends really is the answer in that case.


You're welcome.


Thank you.


Today is March 25th.


Is that correct?


Yes.


Woo-hoo, I got it right.


Very good question as well.


And I see that we have one question in the chat


that I would like to take at this point.


As a JavaScript developer, what are the top five things


that we should consider to have or not to have


for web security?


Web security is a vast and huge field,


not really related to JavaScript SEO, though.


But I would say definitely make sure


that you test for cross-site scripting and cross-site


resource forgery.


Those are two very important things.


Make sure that you implement the content security policy


headers.


That's what they are there for.


They prevent a lot of problems.


You can set the content security policy


to report only so that you basically get feedback


on potentially problematic settings


before you switch them off.


Yeah, what else?


JavaScript will update your dependencies,


reduce dependencies to begin with.


This is a big one.


Don't include modules for one functionality


that you can build in five lines yourself.


Phew, what else?


Security is not exactly my strong side.


So I'm not quite sure what else I would do for security.


But definitely look at your dependencies.


Reduce your dependencies.


Keep them up to date.


Use content security policy headers.


And make sure that you are not accidentally


allowing some sort of cross-site scripting on your site.


Anyone else having a question in the Hangout?


Or should I go to the questions that were submitted?


Hey, I have another question.


I recently noticed that Google Found and third-party Found


can affect web performance a lot.


And I wonder what is the best way


to prevent third-party found to affect your site performance.


Is it worth to query third-party Found in CSS?


Because CSS itself is render blogging,


and then you query again and need to send another request.


So you're saying you're worried about the performance


of third-party Fonts?


Yeah.


Yes.


I wouldn't worry too much about that.


You can hypothetically cache it on your end.


So make sure that you're not downloading it over and over


again.


But I think one way, I'm not sure what it was called.


I think it's Font Display or something.


It's the CSS property that you can use to specifically say


that it should already start rendering with the system


font or with the fallback font and then swap in


as it has the new font.


That might reduce the performance impact there.


But I would consider other things as well.


There's like you can subset a font


to make sure that you only download


the subset of the font that you actually need,


reduce on the weights in the font file.


So maybe it is definitely worthwhile


looking into inlining or basically just not necessarily


inlining, but like hosting your own version of the font.


But if you can for licensing reasons or whatever,


definitely at least use Font Display Swapping.


OK, thank you.


Awesome.


Another question.


What is the best way to QC lady loading?


What I do is I use develop tool, and I just


record it without scrolling.


And to see that is there any image loaded before content


download.


Is that a right way, or is that other way


that there is a more efficient quality assurance lady load?


That is a tricky one that I never really thought about.


I just, yeah, I think I also just use the developer tools


and then resize the window or scroll in the window


and see if it actually loads the actual sources.


I wouldn't know for sure.


That's a good question.


Yeah, because if that is the best way


that if you have 1 million pages,


you have to do 1 million times.


Yeah, I'm not sure if that's a great one.


I think you might be able to script something


with Puppeteer maybe.


But even then, it would probably be really, really hard


to do that at scale with all the pages


if you have so many pages.


That's probably something you should do on a page level


as the pages get created by someone.


I don't know.


If you use the native lazy loading implementation


in Chrome, then you don't really have that problem


because then you can make it a problem with the browser


to do that.


But not every browser supports it.


So I see that at this point where


you have a bunch of custom implementations,


this might be pretty hard to test at scale.


I see.


Thank you.


You're welcome.


All right, now I think I'm going to take


a question from the list.


What are some of the best practices


to follow while optimizing speed on JavaScript websites?


What's the best CMS for JavaScript websites?


I don't know about CSSes because I'm


pretty sure that you can probably make it work


with pretty much all of them.


But for performance and JavaScript,


I would suggest, A, to defer as much JavaScript as you can.


And also, if you can, if you reasonably can,


not rely entirely on client-side rendering for your most


critical content because the quicker you deliver HTML


to the browser, the better it is.


And the more you rely on JavaScript to do that,


the slower it will be, especially for landing pages


and static pages.


You'd want to consider server-side rendering


or server-side rendering and hydration.


If you are to start a new project,


I would look into higher-level frameworks such as Next.js,


Nuxt.js, or Angular Universal to do that.


But if you really have to stick with client-side rendering,


then at least try to make your JavaScript as fast as possible


by basically tree-shaking your dependencies so that you only


have the absolutely crucial and necessary piece of code


from your dependencies and not just drag dead code around.


Consider splitting, actually bundling up


as much code as possible, but also splitting your code


along the packages where it makes sense.


So for a specific page, I might not


need all the bundle for all the application.


So you could split those and then preload the,


or actually not preload, but prefetch the other bundles


so that it's faster as the browser does


that in the background.


But yeah, the less JavaScript you ship, the better it is.


That's a general rule of thumb.


OK, and then we have a few more questions in the chat.


For caching stack assets such as fonts,


using service worker would be recommended.


Yes and no.


Yes, generally for your users, that


is fantastic to use a service worker to reduce the network


activity, especially in the sense of reducing


the latency because it's always going to be faster to fetch


from a local cache than from the network.


But search engines also usually are heavily and aggressively


caching, which is why we would suggest to generally use


long-lived caching and fingerprinting


or some sort of content hash or versioning of your assets.


There's an article on web.dev which


is called HTTP Cache, Your First Line of Defense,


if I remember correctly.


I can post that in the chat real quick.


If I find it, yes, I do find it.


Here, it's fantastic.


Where's the chat?


Here's the chat.


So definitely try to make it easier for the browser


by having long-lived cache.


For e-commerce collection category pages


that display product ratings is a good, bad, unnecessary thing.


That's a structured data question.


I would take that to the office hours real quick.


Last call I asked about JavaScript files


that were being requested by Googlebot after four years


after they were embedded on our site.


That is really weird.


I would be very surprised if that


isn't some sort of glitch in the way that the indexing runs.


I wouldn't worry too much about that normally,


especially if your content gets indexed anyways.


But if you share that problem with either


this fantastic mailing list.


Shit, I can't type anymore.


There's mailing lists called the JavaScript Science Working


Group, where you can ask this with a sample URL,


because this needs to be investigated,


and I can't do private support.


So you can't send that to me privately.


But the Webmaster Forum or that mailing list


is a fantastic place to get some feedback from others


who might be able to help you with this problem, Trevor.


For a client-side rendered site, does having a site map


speed up the second wave of crawling,


or does this stay the same without the site map?


This is for a site with 2 million pages.


It depends is the answer to that question.


First things first, there's no such thing as a second wave


of crawling-ish.


The second wave is a oversimplification


that is coming back to us with interesting implications


every now and then.


Basically, a site map just helps us discover things


that we can't discover as quickly otherwise, which


means if a site map helps you with discovery,


generally, it's depending on your site structure


and on your crawl frequency, which has nothing to do with


if you have a site map or not.


If you have a very well-linked structure


between different pages anyways, then the site map


is probably not going to be a big speed up.


But the site map definitely helps us discover new content,


generally speaking, quicker.


2 million pages, it might give you some advantage.


It might not give you some advantage.


Try that out.


It definitely doesn't hurt.


But it doesn't replace linking in the clean menu structure


and a clean linking structure between your pages anyway.


It's just a different way for us to consume content and discover


links on your site.


Awesome.


Now, there was a question submitted


on YouTube, which is from Dave.


When fingerprinting resource files is better,


is it better to change the name, like vendor.


some version string.js, or can parameters work?


For example, vendor.js question mark version equals something.


Parameters work for us.


That's perfectly fine.


It might be tricky depending on your setup.


If you have a cache in between or a reverse proxy that somehow


kills query parameters, I know that some CDNs do,


then it might not work.


And it is sometimes harder to debug because you might not


have the level of logging that you


need to actually troubleshoot issues


throughout multiple hosters and pieces of infrastructure.


I would say generally it doesn't make a huge difference.


But having it in the file name is probably


a little more robust across different environments.


So I would balance that.


But generally speaking, it's fine to use parameters.


Yeah.


OK.


I'll read myself after that because if you do it


with a parameter and it changes, then it would potentially still


load, wouldn't it, if Googlebot or something is taking


and rendering.


So you would get the fresher version,


which I suppose could be about the button and the cursor.


But that was the reason behind the question.


Then you make your life with debugging even harder


because then you're like, I think we loaded version 5.


But then it turns out that it was version 6.


I was like, huh.


It really depends on your use case and on your environment.


I would say from experience that putting it


in the file name is slightly more robust.


But either way works.


It's not that one way wouldn't generally work.


It's just if it doesn't, then debugging parameters


is usually a little harder.


Depending on how the systems are configured,


it might be a lot harder, in fact.


Cheers.


Thank you very much for the question.


Anyone else here having a question before I go back


to the written questions?


Silence.


OK.


So sorry, Mike.


I just typed one out because it's


a bit of a long-winded one.


So probably better to write than try and verbalize it.


Right.


A client currently building a new front end in Gatsby.


Nice choice.


And it's setting up their own ABO.


AB testing, yeah.


Fun times.


Development is against URL changes and guidelines.


How to separate URLs and canonicals


are desired if we move to parameter injection


dependent on version and canonical injections.


Yeah.


JavaScript.


I'm not sure I fully understand the question.


So a little bit of further context.


So obviously, we're building a custom front end.


I want to do my own custom AB solution.


Obviously, if you're going to be doing AB,


I want to append URLs with versions


of some sort of control.


I mean, cross canonical back.


They've said that will require a lot more engineering.


So I'm trying to find a compromise where


I can get parameter potentially injected.


Obviously, because it's all being done in JavaScript


and there's no CMS because it's all being done headlessly


as well, then do you perceive that if we inject, say,


a parameter onto version B and then inject it to canonical


that way, that would still meet the requirements for basically


canonicalizing B to A, C to A, et cetera,


from a Google perspective?


I think that would.


If you have parameters in your canonicals,


even if they are JavaScript injected, that should be fine.


OK, that could be a good compromise.


Thank you, Martin.


MARTIN SPLITTENBERG


All right.


I'm going to copy this over then.


Oh, more people are still joining.


That's amazing.


Anyone else having a question for me at this point?


Now is your chance.


So I'm not sure if it's a JavaScript question or not,


because I'm not sure closed caption is created by JavaScript


on most of the page.


So my question is, if you have multiple languages of closed


caption on the video, and I know they are not in the source


code, so they might later insert it in JavaScript


or something like that, do people go closed caption,


or do they know that they have different language


if I have multiple language?


And is that a way to make sure that people know that?


Video indexing is so far away from what


I work on that I have no idea how we're indexing videos


and how we're dealing with closed captions.


So I can't really answer the question.


But I would assume that whatever mechanism there


is to provide closed captions, if you provide those,


even if it's with JavaScript, it should be fine.


I don't know how exactly this entire mechanism works.


I've never worked with video that much.


But I guess maybe the Webmaster Forum people


might know about this.


Or definitely, it is something that I can then hopefully send


on to other teams to discuss.


But that's not something that I can answer that easily.


OK, thank you.


You're welcome.


All right, in that case, do we have more questions in the?


I'm using JavaScript to set my title and description.


It was stated that Googlebot respects it.


But I noticed that sometimes it uses those titles


and descriptions, but other times treats the website


as if it had no, sorry?


OK, as if it had no title and description.


How to prevent that and be sure that the Googlebot actually


waits for JavaScript to kick in.


Notice that the page is not empty,


because it looks as though it is like that.


It's not a problem of us thinking that it's empty,


because if it would be an empty page,


we wouldn't index it, because there is nothing to index then.


So we'd definitely be seeing the content if we index the page.


This effect seems to be random.


My website sometimes has a description and title


and serves and sometimes does not.


I'm not sure what's going on there.


I would definitely post this in the webmaster forums


or in the JavaScript sites WG.


Generally speaking, whatever we see when we are done rendering,


we put into the index and then move forward.


We might rewrite the title anyway.


I'm not sure if you're aware, but basically when


you give us a title and description


and we figure out that it's not relevant to the query


or not relevant to the content on your page,


we might consider alternatives anyways.


There's an entire system that deals with that.


And sometimes the system picks a title


that you don't think is right, or sometimes it


might not find a title that is worthwhile picking.


But I don't think that we usually end up with empty titles.


That is a really, really weird situation.


I would definitely have a look at the URL inspection tool


and look at what kind of rendered HTML


we had in the crawled page.


I'd probably also run a live test,


especially if it's an on-off thing that


suggests that there is some sort of issue on your end


with the way that you are generating


your HTML and JavaScript.


It can be that your server sometimes times out,


sometimes gives us a 404 or 500 or something like that.


I would check the server logs to find out what's going on there,


especially because it sounds like your website is client


side rendering, or at least uses JavaScript


to change the content because it does change


the description and title.


So I would check that your server definitely does not


return any weird errors to us.


And I would consider posting a URL into the JavaScript sites


WG or into the Webmaster Forum so that we


can take a look at this.


Awesome.


Anyone else here having a question?


Madhav, I just went and tested a few URLs.


And since it doesn't index infinite scroll articles,


so that is very good.


But I'm going to research a little bit more


and find out what is the like edge case when it does index


and doesn't index.


But I believe that as John Mueller


said that when you have an Ajax URL noindexed,


Googlebot will not crawl that content.


That's why I asked again to get some sort of confirmation.


Generally, that is true.


It does depend on your implementation, though.


OK.


But good to hear that your implementation apparently


seems to work the way that you expect it to work.


So then that should generally be fine.


Thank you.


You're welcome.


How big of a problem is it when a part of the website


has client-side rendering and Google can't render


any image of the website?


Hold on.


Sorry, I needed to admit someone to the Hangout.


And Googlebot cannot render any image of the website.


I know it's not an optimal situation,


but I have to convince the development team


that this might be a problem.


All textual content can be rendered, for example.


And then we have a sample URL.


I would have to look at the sample URL


to see what is happening there.


Actually, let's do that real quick.


Generally speaking, if there is an image URL


and we can't render it, that shouldn't necessarily


be a problem unless you want that image indexed.


If you care for your images, which you probably should,


then you might want to know why we are not rendering it.


And then you can use various tools


to see why the thing is happening.


So I'm not sure I used the wrong tool for this.


Let me quickly run this through mobile-friendly test.


This is really annoying because there's a weird redirect


thing going on.


And I don't want the YouTube redirect.


I want the URL itself real quick.


I can probably share this with you all on my screen


if I figure out where that is now, my entire screen.


And I want this screen.


This is going to be funky.


So I threw this into the mobile-friendly test.


We can see that there are no images being rendered, which


is because there's nothing specifically


preventing us from seeing them, except that there's


some CSS and some JavaScript not running.


But that should not be a problem.


Let's have a look at the HTML.


If I scroll down here, can I search for the image tag maybe?


Well, that's the image for the, that's


a bunch of images for all sorts of things in the menu.


Now someone wants to join, so I'll let them in real quick.


All of these are present basically


like menu images or something.


And none of this is actually an image image.


So I'm not sure what kind of image he's missing here,


but I can't find them in the HTML.


If they are not in the HTML, we're


not going to even discover them.


I'm not sure.


Let's actually try this URL in the regular browser tab


and have a look again.


So there are a bunch of images that we are supposed to see,


I would say.


Yeah, they are definitely present here.


They are not present for whatever reason


in the rendered HTML, because I couldn't


find any of this previously.


Also really interesting, so there's an out tag here.


And an out tag, an out attribute here.


And we can maybe search for this in the, come on,


don't do this to me.


Yes, there we go.


Whoops.


So we do find this in the text.


But I'm not seeing this in an out attribute.


So that tells me that whatever they're doing,


we are not seeing it in the rendered HTML.


If we're not seeing it in the rendered HTML,


you know what that means?


That means that we are not able to index this.


If you care for these images being indexed,


definitely you need to figure this out,


because that means that we are not


seeing them right now.


Any more questions from you all before I go back


to the list of questions?


I have a quick question.


Oh, multiple people.


Oh, OK.


One after the other.


Yeah, go ahead.


Go ahead.


OK, great.


So we have clients who are not using the same HTML


as we have clients whose website is awfully outdated,


and they are about part of a big corporate system.


So an upgrade is a bit out in the future.


And currently, they can't add any sort of editorial content.


How would Google look at it if we made a sort of a workaround


where we added content using JavaScript?


Like, at the front page, we might add a URL with a parameter


through JavaScript to a sort of a fake page by overriding


another or adding another, like, fictitious parameter


with custom content.


So you can totally do that, especially


if the content is basically an update of the previous content


at the same page.


Then that's not a problem.


And Googlebot would see that rendered content,


unless your implementation has some flaw or problem.


You can test that with the testing tools.


Creating fake pages through History API


is a little bit of a tricky one, because then you


can't necessarily assume that it will always


return the right content if you're getting on the page


and the JavaScript breaks.


But fundamentally, it works.


It is a brittle solution, but it is better


than probably dealing with, like,


we can't do anything on our website at all.


I would definitely very, very carefully test


the implementation, whatever you're building.


But if you use JavaScript to inject content,


we see it as normal content.


OK, great.


Thanks.


You're welcome.


I just wanted to ask, if now with the JavaScript-aware


Googlebot, Googlebot still doesn't scroll the pages


nor click the buttons, or?


Correct.


Correct?


Yeah.


OK.


So any JavaScript buttons that opens, for example, dropdowns


and stuff like that with content inside, you won't see it?


Depends on the implementation.


The way, if you only load the content into the DOM


or only make it part of the active HTML document


after user interaction, then we won't see it.


But if it is rendered into the HTML beforehand


and only becomes visible through user interface,


then we might still index it.


We just won't click on anything.


So if you have a button that takes you to a different page,


we won't click on it.


We won't see that.


The only thing you don't click on, quote unquote,


is anchor tags, right?


Yes.


Yeah.


We don't click on those either.


We use the href URLs.


OK.


Thanks.


You're welcome.


There's a follow-up question.


We can't index an image if it's not in the HTML,


since this is the case.


How to make sure lazy-loaded images are indexable.


Lazy-loaded images.


There's two options here.


So one is if there is an image tag that


has the loading equals lazy, we will see it,


because it has a source attribute.


If you do not use the source attribute and lazy load


and basically update the image, then it


depends on your implementation.


For instance, if you are using an intersection observer,


that would not become a problem, because we are doing something


to make the viewport large enough for your website.


And then the lazy loading would kick in


and would create the image source attribute that we need.


And then in the rendered HTML, you


would see the actual image source.


And I can show you an example of that.


Let me really quickly show you something.


OK, someone wanted to be in this.


So based on what you just said, it


indicated that Googlebot do scroll down.


No.


It does not scroll down.


There's other ways of changing the viewport


so that things become visible.


I don't want to discuss this too much,


because it's an implementation detail that I don't


want people to cling on.


But actually, this is the wrong website.


Where did I have this?


I think it was here somewhere.


Lazy-loading experiments, I guess.


Yes.


No?


Oh, god.


OK, let me see if I can find this back.


And I think someone wanted to join the Hangout.


Yes, OK.


So I can actually make this larger.


So I built a bunch of test cases for lazy-loading.


Let's use lazy sizes, for instance.


The way that these pages work is they, oops,


I'm not in front of the protocol yet.


The way that this works is we have a bunch of HTML,


a very, very boring text.


And then we have an image tag that does not have a source.


Well, it has a source, but it's only a one-by-one pixel source.


And then the data source is what's used to actually lazy-load


this content.


And I can show you that this works by actually seeing


100 by 100, 200 by 200, 300 by 300, 400 by 400, and 500


by 500.


So these images lazy-loaded as they became visible.


And if I'm lucky and this thing doesn't break on me


while I'm doing this, because every now and then we


run into interesting resource situations here, where it's,


the problem is the testing tools are very impatient.


So sometimes if things take too long,


then the testing tools bail out where they shouldn't have


bailed out.


We can see all resources.


And here you see it loaded 100 by 100.


It loaded 200 by 200, 300 by 300, 400 by 400, and 500 by 500.


So all these images have been successfully loaded


and will be indexed.


And that's actually what really matters


when it comes to lazy-loading.


So this implementation actually works.


You can also see that in the rendered HTML.


If I scroll down to, let's say, here,


then we see that the source has been replaced by the 200


by 200 image source, as lazy-loading would do.


So this is how you can test your implementations.


And that way, you know if your lazy-loading works or doesn't.


It is not very easy to say, yeah, that totally works.


And this other thing doesn't.


You have to test these things, unfortunately.


So not just loading anything that is Java inserted,


if they show up in a rich result,


they can potentially be indexed too.


Mm-hmm.


OK.


Thank you so much.


You're welcome.


Do we have more questions in the notes?


No, there's not more questions on YouTube.


So if you have any further questions,


now is a good time for those.


Can I ask another one?


I just remembered.


For example, we use Google Maps API.


And since now Googlebot executes JavaScript,


does that mean it will consume the quota?


Oh, my God.


That's a really good question.


There is a potential that this might actually happen.


But I think, if I remember correctly,


because Google Maps does not normally generate.


I'm not sure.


You would have to check if Google Maps gets roboted away


or not.


But generally speaking, we are very aggressively


caching things.


So I wouldn't worry too much about this.


But definitely test that, because I


don't know if we are skipping Google Maps or not.


That's a very good question.


OK.


Thank you.


You're welcome.


Thank you very much for asking all these good questions.


I'm really happy with the questions being asked today.


Martin, just one thought that came to my mind.


Like, I have implemented the Infinii School Awesome AMP


beyond next page new feature.


So I'm guessing the way it's implemented,


the next page feature of AMP, does guarantee somehow,


like, next articles will not be indexed


as a part of the content, right?


Because the way you thought and planned and implemented


the next page of AMP should suppose also avoid that issue.


Can I?


I'm guessing, yeah.


Yeah.


OK.


I'm not sure about AMP.


All right.


Cool.


Any further questions?


Let me check the chat.


No.


No questions in the chat.


So is Googlebot doing the two-part thing?


Like, before it reads the HTML, and then after a while,


it renders the JavaScript and gets rendered the source


or something like that?


Or is now faster?


Because I remember that it used to be, like, there


were experiments of people, like, creating different versions


of their pages and saying, hey, after a week,


this appeared on Google.


And after a couple of days, this appeared on Google.


So generally speaking, we are still somehow looking.


So we are running some analysis on the initial HTML,


specifically to discover links.


So link discovery is fastest if you server-side render still.


But fundamentally, you can assume


that every page gets rendered, and you can assume


that between initial crawling and rendering, on median,


there's a delay of five seconds in the queue,


and then plus the time that it takes


to actually render your page.


If your page renders in 10 seconds,


then we have 15 seconds at median.


If your page renders an hour, actually, no page renders


an hour.


That's bullshit.


Like, a minute, then that extra minute comes on top of that.


But yeah, generally speaking, JavaScript rendering


got a lot faster these days.


MIHAI APERGHISLINGA. And do you cut off the rendering


at some point, like, if you have a very long page or a loop?


MARTIN SPLITTINGER.


We do.


It is very hard to specifically say something


because it depends on a bunch of heuristics and signals.


So I would not worry about it too much.


If it's fast for your user, then you should not have a problem.


If you have to bind your user for two minutes


to actually get any content, then you


might run into problems to begin with.


It's not an SEO-specific problem.


So you shouldn't worry too much about that,


specifically for SEO.


MIHAI APERGHISLINGA. OK, OK.


Thank you very much.


I've got another question, if that's OK.


If on an SPA that you're rooting locally,


I know there's kind of two options for a 404.


You can either no index, or you can redirect off


to an actual 404 outside.


Is there any benefits between the two,


or is they're both just as good a solution as another one?


It just depends on what's easiest.


MARTIN SPLITTINGER.


Yeah, both of them are as good as a solution.


It really depends on what's easier for you.


And there's not that much of a difference between the two.


MIHAI APERGHISLINGA. OK, thank you.


MARTIN SPLITTINGER. You're welcome.


There is, however, this one note that I would like to give.


If I've seen it happen, and I've done that mistake myself


many years ago, if you think that it's a smart solution


to have a robots no index in your rendered HTML,


in the HTML that you sent initially,


and then switch that back with JavaScript,


don't, because what happens is we see the initial HTML,


we see no index, and we stop, and we don't execute the JavaScript.


So the robots thing has a risk attached to it


if someone somehow decides to put no index in the HTML,


and then switch that with JavaScript,


which redirects don't have.


But I could see people screwing up either solution.


So both of that is risky to a certain degree.


Thank you.


MARTIN SPLITTINGER. All right.


MIHAI APERGHISLINGA. Just to be clear,


you just said that if the HTML contains no index,


that would prevent you from executing the rest of the page,


basically, right?


MARTIN SPLITTINGER. Pretty much.


And when I say no index, I specifically mean


like a meta robots content no index.


If you have a no index in the robots tag,


we basically do not render the page.


That's what happens.


We also mentioned that in the documentation,


if I remember correctly.


I can see if I can find the documentation link real quick.


And, oh, OK.


That has changed.


Let's see.


I believe this might be here, or is it in the other one?


I'm not sure.


No index.


OK. We don't explain it here.


I think it's explained here.


Yeah. This one.


So we explain this in the documentation.


You can swap.


You can basically dynamically add a new index.


You cannot dynamically remove a new index from the page


with JavaScript.


OK.


One last question.


Or maybe two more.


I don't know yet.


All right.


So if there are no further questions,


I would like to take this opportunity to say thank you


so much for coming to the first official JavaScript SEO Office


Hours.


I hope this was useful and that you got the answers


you were looking for.


If you have any further questions,


remember we do have the Webmaster Forum.


We do have the JavaScript Sites Working Group


that you can post questions to.


It's usually a good idea to send us also URLs,


as in like send either the Webmaster Forum or the Sites


Working Group to send a URL there


where we can see the problem in action,


or even try to build like a tiny little prototype that


exhibits the behavior you're wondering about so that it's


easier to debug these things.


Please continue watching out my Twitter feed,


as well as the YouTube channel's community page for the next


Office Hours to happen.


I expect them to be approximately every two weeks.


And yeah, I'll upload the video to YouTube later on.


And thank you so much for being fantastic people


and asking great questions.


And have a great day.


Thank you, Martin.


Thank you.


Thanks to everyone for coming.


Bye-bye.


Bye.


Goodbye.


Oh, I need to stop the recording somehow.


Stop recording.


English Google SEO office-hours from December 17, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google.


And part of what we do are these Office Hours,


where people can join in and ask their questions


around their website and web search.


And we have a handful of submissions on YouTube already,


so we can go through some of those, but also some people


already jumping in to raise their hands.


So maybe we should get started with you all.


Let's see.


Akash, I think you're first.


Hi, John.


Hi.


I just have two follow-up questions on my last,


the previous one, for the outage one, the server outage


we have asked already.


So this is like, does it really matter what type of server


you have and in which country it is located?


Like, let's say I have a client whose target audience


or everything has been in India, but the server is in the US.


So does it matter that Google will start sending more


of the traffic from US, or is it like showing


more of the pages in the US rather than in India?


Is it something like that?


There's nothing around geotargeting


with the server location.


So from that point of view, it doesn't matter so much.


Sometimes there is a bit of a speed difference


that you might want to look at or at least test,


where if you can host your server closer


to where most of your users are, then it


tends to be a bit of a faster connection.


Sometimes that plays a bigger role.


Sometimes that plays a smaller role.


It's, I don't know, sometimes worth trying out.


Also, if you use a content delivery network,


then oftentimes the content delivery network


will have nodes in different countries anyway,


and it'll be essentially the same


as if you had your server in multiple locations.


So it's from an SEO point of view,


from a geotargeting point of view, it's a non-issue.


From a speed point of view, maybe you


can usually test that as well.


If it's a critical speed issue that


affects the Core Web Vitals and the page experience ranking


factor on your side, then that could have a ranking effect.


But it's not so much that it's because you have your server


in a different location.


It's just because your website is perceived


as being slow by your users.


Last week, sir, you said if your website will be down


for an outage, so you can show a status code of 503,


like 503, not for a couple of more days, but for a day


it will work.


So recently, my client is again trying for a server migration,


to which he said, we don't want a lot of 301 redirects


from images, HTML files, and CSS.


So what they were thinking is to just for an hour or so,


just take the whole website down and add it to the new server.


And just for a couple of hours, let's say one or two,


the website will be like 503, and then it will be back again.


So is it going with the 301 for a couple of days or per month?


And let Google understand that we have migrated from A to B


server or just down the website for a couple of hours,


and then again showing up the website.


Since just a server migration happened,


but it does not show the complete 301.


You promise?


Yeah.


So usually that's kind of expected,


where if you do a server migration in that you change


your IP address or you move from one server


to a different server, then usually you


would keep all of the URLs the same.


And if the URLs are the same, then you


don't need to do any redirects.


So from that point of view, not having 301 redirects in place


is kind of normal.


With regards to whether taking it down for an hour or two


to do the migration is kind of the best approach,


I don't know.


I mean, ideally, you would not need to take your server down.


But if you need to take your server down


and if you can serve a 503 result code in the meantime


for that hour or two time that you need to move everything


over, usually that should be fine.


From a search point of view, we will


see that there's a temporary error.


We'll try back after a couple of hours.


And if it works then, perfectly fine.


There shouldn't be any effect at all in search.


So one last question.


Let's say we have no landing pages for the ad campaign.


There are like a lot of landing pages they wanted.


So a part of their content is then


taken by, let's say, our products or the services pages.


However, what we feel is since it's the landing pages


and it might have some kind of presence online,


so the news publishers or any kind of authors or bloggers


may write about those things and they directly link


from their page to our pages.


So is it right to add a canonical tag


of that particular landing page, which is an ad campaign,


of the product or the services?


Because in that way, can I tell Google the links


or the influence that you are getting


for this particular page?


The canonical has been different.


So the canonical is the My Product page, however.


So can you just shift the overall influence


to the product pages in the canonical


is being changed of that landing pages


and just help my page a little bit rank better.


I know that does not matter, as you said,


how many times on the Twitter.


But since that influence shift can be done.


Yeah, yeah.


You can definitely do that.


I mean, it depends a bit on how you set up


the ads landing pages.


Obviously, if they're blocked by robots text,


then the canonical, we will never see that.


But if they're crawlable, if they're otherwise indexable,


and you have the rel canonical to your preferred version,


that's perfectly fine.


Thanks, also.


Thank you so much.


Sure.


Jeroen.


Hi, John.


Hi, everybody.


John, we have been working on CLS problems


for a couple of months now.


Most of them are OK now.


I think we're almost up to the finish.


But there's one thing that is popping up from randomly out


of nowhere.


Is it possible that the font could be a CLS issue?


The font.


The type of font, because we have some CLS contribution,


like 0.01, 0.09, 0.08.


And it's all just in the same paragraph on the font.


At least it looks like it's the font.


It could be.


I'm not an expert on the CLS side of things.


But depending on how you set things up on a page,


if you're using an external font file,


then that file has to be loaded.


And depending on how you display the content,


it might be that you display the version of the content


without the font file first.


And then it loads the font, and that shifts the layout around.


So that could be something that might be happening there.


I think someone in the chat also just mentioned it,


the web font side of things.


I think on web.dev, the Chrome folks


have an article about using fonts


and minimizing the layout shift.


So I would check out for that.


OK.


Is it easy to find?


I think so, right?


So probably, hopefully.


OK, then I will just check it regarding the font.


If I cannot manage to fix it, because also the developer did


not see any problems with it, like, hey,


what's going on in the paragraph.


But OK, then we check the overlay of the font,


and then the variant's loaded.


Yeah.


I think also in Chrome Developer Tools,


you can do things like block the URL of the font file,


and load the page, and compare it a little bit clearer


to really see, is it really from the font,


or is it something else maybe that's causing this issue?


Yeah, I'll take that in depth.


Thank you.


Cool.


Good luck.


Thanks.


Axel.


Hey, John, can you hear me?


Yes.


Yes, great.


So I work for a website in sexual wellness.


So it's really with the sex toys and everything.


And since maybe almost two months now,


we are no longer ranking on our own brand name in France.


I asked this question already, and then I


mentioned that it was a biblical story, because the brand


name is Adam and Eve.


Yeah, now we are clueless of what we can do,


because we have always ranked on position one.


When people search for Adam and Eve, there was our store.


Now people can find us, but then only when


they type Adam and Eve together.


So we are really wondering, which way


can we go to get a certain ranking on Adam and Eve?


We were thinking, maybe remove all the sex toys


from their own page, but then it's not


like we got a penalty, because it's only that page.


Pretty weird.


And we can still advertise, of course.


And it's only in France, and only the home page?


Yeah, that's only our brand name in France.


So that's where we have the problem.


And we know that Google wants to, of course,


offer people what they're looking for.


And we understand that when people look for Adam and Eve,


it's not quite a store in sex toys.


But then it has always worked.


So it's kind of odd.


Yeah.


So any IDs?


I think it might be tricky, but I probably


need to pass it on to the SafeSearch team to check out.


Because one of the tricky aspects


there is if our systems recognize somehow


that people are looking for something


that is very different, kind of from the style,


specifically with regards to this adult content,


then that's something where they might say,


well, you're looking for this term,


and this website is called exactly that.


But if we show that to people who are not expecting that,


they might be confused.


They might find something is wrong.


If you're searching for, I don't know, some Disney character,


and suddenly you see a sex toy store,


then that would be something kind of unexpected.


And the average person who's looking for that character,


they might say, well, why is Google showing me this?


This is a bug in Google.


Yeah.


And I don't know if something along those lines


might be happening there.


I feel it's possible, especially if it's just on the border


and in individual countries maybe,


or individual variations of the search term that you're using,


that our algorithms are kind of on the edge


and not quite sure, is this something


we need to watch out for, or is this something


that is pretty straightforward that we can just


show this website?


And I could imagine with something like a sex toy website,


it gets tricky there.


Yeah, it's always hard.


Yeah, but I'll definitely pass that on to the team


here to kind of take a look and see


if there's something on our side that


isn't working as expected or is working as expected.


Yeah, because now you're talking about like a position one


ranking for a long time, like sometimes competing


with Wikipedia, of course, and now just out of the top 100,


gone, and maybe close to 150k of traffic a year on our brand


name.


That's a lot of traffic that we're talking about.


It's really messed up.


And a lot of people are kind of upset about the fact


that we can advertise, but no longer organic.


So.


Yeah.


Yeah, I don't know.


I mean, on the one hand, there's the aspect of just


because it worked in the past doesn't


mean it'll work in the future.


So that's kind of like one bias I think


is worth watching out for.


But to me, it feels like something


that's kind of edge case.


And it could be that if we chat with the SafeSearch folks,


they'll be like, oh, the next time this guy comes up,


tell them to do these five things


and everything will be better.


I don't know if that's something along those lines.


But I'll check with the team.


Thank you.


Sure.


Let's see, Craig.


Hi, John.


How are you doing?


Hi.


Very interesting subject, that, the Adam and Eve one.


I've gone through all the sort of safe site terms


on your terms and conditions there.


So yeah, not interested.


Anyway, just wanted to pick your brains on something, really.


So I had a bit of an issue earlier on this week


where my paid team were, our media team,


were doing paid ads with Pinterest.


And it caused a massive issue where


Pinterest were crawling our website


and then actually putting our servers into overload


and meltdown and brought up a load of 503 errors.


So we figured out the problem.


We blocked Pinterest, turned them off.


But we got a lot of pages, quite a few hundred pages


that are now still on a 503 in Google Search Console.


I know there's some issues at the moment with Google Search


Console.


So I've gone through the pages.


Well, quite a chunk of them.


They're all working.


Everything's fine on our side.


So I've entered revalidation.


It's been going for the last two days.


So just wondering what sort of time scales are we looking at?


Or is there anything I can do to,


could I resubmit site maps to get it to work quicker?


Is there any advice?


How long was the 503 in place, do you recall?


We sort of found it last Monday, Tuesday,


fixed it, blocked, Pinterest.


And we're back to normal now.


OK, so a couple of days, I guess.


Yeah, yeah.


Yeah.


So if it were less than a day, then we


would probably just automatically pick that up


and retry it again.


If it's more than a couple of days,


then it can happen that the URL drops out of the index


because we think it's more of a persistent server error.


And in a case like that, it essentially


needs to wait until we recall that URL again,


which can happen, depending on the URL,


can happen after a couple of days.


Maybe it takes a week or so to kind of be recalled.


But essentially, that's something


where it goes through the normal recalling process


and then picks up again.


So what I would usually do with a situation like this


is look at the errors that you see in Search Console


and try to prioritize them and figure out


if there are any that are really critical for you.


If there are random long tail landing pages on your site,


then I would just let them get recrawled over time, which


will happen at some point.


If they're important pages, then I


would do things like resubmit them in Search Console


directly, manually.


Yeah, so I did that with a few category pages, like manually.


So I could just do the category ones


and wait for the long tail ones to then come.


OK.


That sounds good to me.


I'll give it a go.


It's got a lot of pages to do in multiple markets.


So I'll get cracking.


Any idea on time scale?


I don't know.


So submitting to indexing through Inspect URL


does go a little bit faster.


But it's not something that is guaranteed


to get picked up automatically.


So it can still take a little bit longer


to be reprocessed off of that.


What if I resubmitted the XML sitemaps?


Does that do anything?


I don't think that would change that much in a case like this.


Because on the one hand, just resubmitting the sitemap file


isn't really a strong signal for us.


We would look more at the date in the sitemap file.


And if you just manually update all the dates and say,


oh, we change it today to encourage Google to pick it up


again, then we'll look at the sitemap file


and say, all the dates are the same.


This is not really useful.


OK.


Sounds good.


I'll get cracking on that.


Thank you very much for your time, John.


Cool.


Good luck.


Thanks.


Bye.


Let's see.


Lau, I think.


Hello.


Hi.


How are you doing, John?


Pretty good.


Yeah.


My name is Ben.


And I have some questions.


I hope you will answer it for me.


Like three weeks ago, I received a message from Google.


This is a manual action, unnatural link to my website.


So I export the list of the domain, external domain,


to my website.


And I find out that there are more 400 websites that


could be our content.


It's kind of the whole website, design and content.


And some websites, it could be a part, some page of my website.


And I tend to see the reason that's


why I get the manual action.


And I don't know how to take down these copy websites.


So I conduct the survey called GMCI to take down website.


And this cost me one website is $199 USD


to take down this website.


And I see the list that there are more 400 websites.


And I think the cost of take down these copy websites


will be huge.


And our technical developer tried


to take down but only nine websites and a lot more.


And after I took down one website,


they create a new website.


It could be our content.


And in our content, there is an internal link.


So insert console, we see there are lots of unnatural link


into my website.


And I got manual action.


So I don't know how to deal with this situation.


So do you, yeah.


OK.


So I think there might be multiple things at play.


On the one hand, for the DMCA process, it should be free.


So if there is someone charging you money for it,


then that sounds like some, I don't know,


third party company that is submitting them in your name.


Because usually submitting DMCA complaints


is something that is free.


So it's free to submit them on Google.


It's something that you can submit directly


to the hoster through the abuse address, for example.


And there should be no charge associated with that.


So if you ran into someone who is charging you money


for DMCA complaints, then I suspect


that it's not a legitimate kind of DMCA complaint there.


So that's kind of the one thing.


The other thing is what you can also do for cases like this,


where you can't remove the content,


you can use the disavow links functionality in Search Console.


It's not directly built into Search Console.


So you have to search for it separately in the Help Center.


But you can use that to submit whole domains.


So you can make a list of those 400 domains.


You can use a domain directive in the disavow file


and just submit all of those to us.


And that way, we will know that you


don't want these links counted.


And we can just ignore them for our systems.


And that can also work for the manual action.


The other thing I think which is perhaps more relevant


is usually the manual actions team would not


take a manual action just based on someone else copying


your website.


So for the most part, the manual actions that you receive


are done manually by the web spam team.


They review the situation for your website.


And based on what they find, then they


submit a manual action if there's


something that our systems can't filter out on their own.


And for things like just purely copied websites,


like some spammer is copying your website,


that's something our systems can deal with fairly well.


And that's not something that we would do a manual action for.


So that means to me either maybe there


was a mistake with a manual action.


It's always possible.


Or there is some other kind of link-related issue


with your website that you need to resolve first.


So from my point of view, what I would try to do here


is maybe go to the help forums and post about your situation


and get some input from other people as well.


Some of them have different tools for looking up links.


And that way, you can get a little bit


clearer of a confirmation of, is this really something


that I did, which maybe I didn't know that you shouldn't be


doing it like this?


Or is it something that maybe Google got confused


and I just need to tell Google, you should figure it out,


kind of thing.


So that's, I think, the more important part


that I would try to figure out.


Is there really a link-related issue


that I need to resolve or not?


And the copied sites I would see as something


you can take care of.


But it's not something that traditionally would result


in a manual action for links.


Does that help a little bit?


AUDIENCE MEMBER 1 Yeah, yeah.


That's a lot of information for me.


Thank you.


Cool, good luck.


And Kai.


Yeah, hello, John.


Hi.


Yeah, so my question for you today


is regarding translation and more specifically,


automated translation.


I know that kind of already mentioned in the guidelines.


That's not something that Google encourages.


We do, but our side is mostly user-generated content,


a lot of which is very high quality.


But since it's user-generated content,


users usually only write them in one language,


their own native language.


And for us, doing any kind of manual translation


is kind of hard because we are talking about tens of millions


of pages.


And since Google Translate has improved so much


in the last few years, I wonder.


So I've reached a point that I actually


think that users who land on our pages


and see the automated translation, translated version


would get a better experience than seeing the content


in the, let's say, original language.


So I wonder if that's something the guideline


about automated translation still applies or is.


I mean, at some point, I mean, a translator


could also translate your content badly.


I don't know.


I just wanted to hear your latest opinion on this.


Yeah, I think our stance is still the same.


So we would still see that as automatically translated


or automatically created content,


essentially, if it's an automatic translation


without any kind of a review process around that.


So I think, at least from our guidelines,


that would remain like that, at least for the moment.


I mean, one way that you could work together


with those guidelines is say, well,


for your most important content, you


will do the automatic translation


and have it reviewed by someone local.


And if it's OK, then make it indexable.


But that's still something different than just taking


a million pages and running them through Google Translate


for 50 languages and then publishing them.


Maybe for the pages that we can't review due to the volume,


maybe we can just show a button and let


the user click on that and see the automated translated


version.


I think that wouldn't be a problem for Google.


Yeah.


That should be fine.


OK.


I don't know how this will evolve over time.


I hope the translating systems will get so


that you don't recognize it.


But sometimes you see things and you're like,


this is still very far away.


Because we do have a lot of very unique content.


And it's very well written by the users.


It's just that it's only one language.


Thank you.


Cool.


All right.


Let's look at some of the submitted questions


from YouTube.


The first one is also about different languages


in countries.


We have two country websites that share common content,


including daily news.


We noticed from time to time that the wrong news


page is ranking in the corresponding country.


For example, the DE page in Switzerland.


Does it therefore make sense to work with hreflang in the news


area as well?


Because the implementation of hreflang tags in news sector


would require a lot of technical effort.


And we want to be sure that this effort will


be worthwhile for us.


So I think just purely from the point of view


that you have different versions of content


and you're seeing the wrong version sometimes in search,


that is essentially the situation


that hreflang tries to solve, in that you


have the content available for different locations


or in different languages.


And sometimes the wrong one is shown.


So with hreflang, we can guide that


to be more the correct version.


So from that point of view, that seems


like the perfect scenario for implementing hreflang.


The other thing to keep in mind is


that geotargeting and even hreflang is never perfect.


So if you are very reliant on the right version being shown


to the right users, then you always


need to have some sort of a backup plan.


And my recommendation for a backup


is usually that you have some kind


of a JavaScript-powered banner on top or on bottom


or somewhere that essentially says, hey,


we have a better version of this content for you


specifically for your location, for your language,


and link to it from there.


That way, we can still crawl and index


all of the different versions, but users,


when they end up on the wrong version,


they can quickly find their way to the correct version.


So that's usually my recommendation there.


But I think the scenario that you described there


is very clear, kind of like, this is what hreflang is for.


You have the same language content for different countries,


and you're seeing the wrong one shown.


With hreflang, you can tell us about what


you prefer and which plays.


The next question is also about different countries' languages.


We run a website with 300 index pages, all in US English.


We're looking to translate half of these pages


to Spanish, which will be placed in a subdirectory