Let’s talk JavaScript

That's their big advantage.


Let’s talk JavaScript

GARY Don't we also have one of these frameworks?


Let’s talk JavaScript

MARTIN SPLITT Angular is a Google framework.


Let’s talk JavaScript

Yeah.


Let’s talk JavaScript

GARY Oh, well, that's great.


Let’s talk JavaScript

Good job, Gary.


Let’s talk JavaScript

MARTIN SPLITT That's fine.


Let’s talk JavaScript

We also have Flutter if you want Dart instead of JavaScript.


Let’s talk JavaScript

GARY Oh, Dart.


Let’s talk JavaScript

I forgot about Dart.


Let’s talk JavaScript

That went well.


Let’s talk JavaScript

MARTIN SPLITT It solved all the problems.


Let’s talk JavaScript

GARY That was also a JavaScript solution thing, right?


Let’s talk JavaScript

Like trying to solve problems with JavaScript.


Let’s talk JavaScript

MARTIN SPLITT Yeah.


Let’s talk JavaScript

That's what it's trying to do.


Let’s talk JavaScript

Or I think that's what it tried to do.


Let’s talk JavaScript

GARY Again, it went well.


Let’s talk JavaScript

Great success.


Let’s talk JavaScript

GARY But that leads us to the JavaScript problems that I prepared for you.


Let’s talk JavaScript

MARTIN SPLITT Fine.


Let’s talk JavaScript

I tried to distract you, but no, you're coming back to this.


Let’s talk JavaScript

Fine.


Let’s talk JavaScript

GARY It's right in front of me.


Let’s talk JavaScript

It's written down and I want to...


Let’s talk JavaScript

MARTIN SPLITT Is it in Google Keep?


Let’s talk JavaScript

GARY No, it's notebook.


Let’s talk JavaScript

MARTIN SPLITT Oh, you physically wrote it down?


Let’s talk JavaScript

GARY Yeah.


Let’s talk JavaScript

MARTIN SPLITT How old are you?


Let’s talk JavaScript

GARY With my hands.


Let’s talk JavaScript

I'm 30, uh...


Let’s talk JavaScript

MARTIN SPLITT Thousand years old?


Let’s talk JavaScript

Yes.


Let’s talk JavaScript

GARY Seven.


Let’s talk JavaScript

MARTIN SPLITT Babylonian script.


Let’s talk JavaScript

Mm-hmm.


Let’s talk JavaScript

Okay.


Let’s talk JavaScript

MARTIN SPLITT Seven.


Let’s talk JavaScript

More than seven.


Let’s talk JavaScript

GARY So my list.


Let’s talk JavaScript

MARTIN SPLITT Okay.


Let’s talk JavaScript

GARY I present to you my list.


Let’s talk JavaScript

MARTIN SPLITT Here it comes.


Let’s talk JavaScript

Getting ready.


Let’s talk JavaScript

GARY Scoping.


Let’s talk JavaScript

MARTIN SPLITT Oh.


Let’s talk JavaScript

GARY Why, why, why is scoping so stupid in JavaScript?


Let’s talk JavaScript

MARTIN SPLITT It's not stupid.


Let’s talk JavaScript

Come on.


Let’s talk JavaScript

Just because it's slightly different from most programming languages doesn't mean that


Let’s talk JavaScript

it's stupid.


Let’s talk JavaScript

GARY It's counterintuitive.


Let’s talk JavaScript

MARTIN SPLITT That's true.


Let’s talk JavaScript

Okay, I give you that point.


Let’s talk JavaScript

It is counterintuitive.


Let’s talk JavaScript

GARY Thank you.


Let’s talk JavaScript

Hoisting.


Let’s talk JavaScript

MARTIN SPLITT I think that comes back to historical reasons.


Let’s talk JavaScript

Should we actually explain scoping and hoisting before we...


Let’s talk JavaScript

GARY Go ahead.


Let’s talk JavaScript

MARTIN SPLITT So with scoping, scoping is about where a thing lives.


Let’s talk JavaScript

So in code, you have variables, which are basically little placeholders where you give


Let’s talk JavaScript

a name to some sort of value.


Let’s talk JavaScript

So for instance, you might have a variable called name, and that you would store, I don't


Let’s talk JavaScript

know, Anna, for instance.


Let’s talk JavaScript

And then later on, you can use that to do things.


Let’s talk JavaScript

For a very, very simple example, you have a login form with a username and a password,


Let’s talk JavaScript

and you want to send that username password combination to the server to actually do a


Let’s talk JavaScript

login.


Let’s talk JavaScript

So you will probably have a variable named username and one named password.


Let’s talk JavaScript

And then you have some code that takes whatever has been put into the input fields for username


Let’s talk JavaScript

and password and stores it in these variables to then later on send a request to the server


Let’s talk JavaScript

using these variables.


Let’s talk JavaScript

And whenever you would type into the input field again, you would update the variables


Let’s talk JavaScript

so that you always send whatever has been just typed into the input fields to the server.


Let’s talk JavaScript

Now the question of scoping is, where in the code can I access these?


Let’s talk JavaScript

And by default, if you just write JavaScript without any functions or fanciness, everything


Let’s talk JavaScript

is global, which is great and is terrible.


Let’s talk JavaScript

It is.


Let’s talk JavaScript

I would go with terrible.


Let’s talk JavaScript

It depends.


Let’s talk JavaScript

If you look at how JavaScript started as an extension to the web, where you can basically


Let’s talk JavaScript

just put building blocks and JavaScripts together to manipulate things that happen on the web,


Let’s talk JavaScript

you would end up with probably a relatively small amount of code.


Let’s talk JavaScript

Let's say you have one script and then you have a second script.


Let’s talk JavaScript

In script A, you have the variables username and password.


Let’s talk JavaScript

And then somehow you can't control that script because it comes from a third party.


Let’s talk JavaScript

You bought that from someone because maybe you're using some service for logging in.


Let’s talk JavaScript

I don't know.


Let’s talk JavaScript

But you want to also use username and password to send it to analytics, let's say.


Let’s talk JavaScript

So you have this one piece of JavaScript that does the login, and then you have a third


Let’s talk JavaScript

piece of JavaScript somewhere that does analytics.


Let’s talk JavaScript

And then the second piece of JavaScript is a piece of JavaScript that you write.


Let’s talk JavaScript

And what you write there in this JavaScript is, you know, because it's global, you can


Let’s talk JavaScript

access username and password from the script that you have no influence over that does


Let’s talk JavaScript

the login.


Let’s talk JavaScript

And you know that there is some mechanism, some function that you can call on the analytics


Let’s talk JavaScript

script to send data to analytics.


Let’s talk JavaScript

So you take the global variables username and password, because they are global, you


Let’s talk JavaScript

have access to them, and send them using this function to analytics.


Let’s talk JavaScript

So then the global variable is actually quite handy because you have direct access to everything


Let’s talk JavaScript

that any script does on your page.


Let’s talk JavaScript

The downside is...


Let’s talk JavaScript

Let me counter that.


Let’s talk JavaScript

Yeah, okay.


Let’s talk JavaScript

I could just not encrypt, for example, my password and username in my database, because


Let’s talk JavaScript

it's more convenient.


Let’s talk JavaScript

Okay, I see your point.


Let’s talk JavaScript

Yes, we shouldn't be doing that.


Let’s talk JavaScript

There's also this other issue that if you have two scripts that happen to use username


Let’s talk JavaScript

and password as variable names, then they are like clashing with each other.


Let’s talk JavaScript

I understand there's like huge downsides to global by default, which is why you can have


Let’s talk JavaScript

things non global.


Let’s talk JavaScript

So you have a choice.


Let’s talk JavaScript

I agree that looking at the complexity and size of JavaScript and web applications today,


Let’s talk JavaScript

that global by default is not a good idea anymore.


Let’s talk JavaScript

Because if you had like two or three scripts with like maybe 10 variables each, it was


Let’s talk JavaScript

kind of fine.


Let’s talk JavaScript

And you could avoid the name clashing issues by prefixing it with like, if my library is


Let’s talk JavaScript

called M query for Martin queries things, then I could name all my variables M query


Let’s talk JavaScript

underscore name.


Let’s talk JavaScript

So other people could still access it, but there's a very low chance that someone has


Let’s talk JavaScript

the exact same name in their scripts.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

Okay, fine.


Let’s talk JavaScript

I could.


Let’s talk JavaScript

I'm not saying it's a good strategy, but it used to be fine.


Let’s talk JavaScript

Nowadays, not really.


Let’s talk JavaScript

Probably not so much.


Let’s talk JavaScript

Yeah, absolutely not.


Let’s talk JavaScript

Are these new frameworks solving this?


Let’s talk JavaScript

In a way they are.


Let’s talk JavaScript

So the global naming issue is mostly solved by actually, they still use the global namespace


Let’s talk JavaScript

for things like angular.


Let’s talk JavaScript

So you register angular as a global thing or used to in the first versions of it, if


Let’s talk JavaScript

I remember correctly.


Let’s talk JavaScript

Nowadays they solving this by what's called the module system.


Let’s talk JavaScript

So the language now has a module system.


Let’s talk JavaScript

So you don't have to rely on polluting the global namespace.


Let’s talk JavaScript

Instead, what all these frameworks do and all your code does is it exports a module


Let’s talk JavaScript

and then other people can import this module.


Let’s talk JavaScript

So if I want to use angular, I have to say angular, the variable name angular as the


Let’s talk JavaScript

main component thing from angular is this module that I require here.


Let’s talk JavaScript

And then I can use it.


Let’s talk JavaScript

So I don't actually accidentally put things on the global list of variables.


Let’s talk JavaScript

I only get things that I explicitly include by importing the modules.


Let’s talk JavaScript

So that solves the global namespace issue.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

Okay.


Let’s talk JavaScript

So the global list is that it's loosely typed, which I have a beef with languages that are


Let’s talk JavaScript

loosely typed, which includes also, I think, Python because loosely typed mean that you


Let’s talk JavaScript

don't have to declare the type of the variable that you are creating.


Let’s talk JavaScript

You are leaving it to the language to figure out what it is and how to use it, which I


Let’s talk JavaScript

have a C++ background where you have to declare everything very precisely and it will cause


Let’s talk JavaScript

problems if you don't.


Let’s talk JavaScript

Like for example, if you are trying to put an int64 integer into an 32 container, then


Let’s talk JavaScript

you will have problems, right?


Let’s talk JavaScript

In JavaScript, you are not going to have a problem.


Let’s talk JavaScript

It will just accept it and you are not going to have errors either.


Let’s talk JavaScript

It will just silently will be like, Oh yeah, yeah, dude, this is great.


Let’s talk JavaScript

I love it.


Let’s talk JavaScript

And then later when you are not even expecting it, it will throw you off with something.


Let’s talk JavaScript

Something will happen because of that one variable that you couldn't declare or didn't


Let’s talk JavaScript

declare.


Let’s talk JavaScript

And this drives me nuts, not just in JavaScript, but in Python as well, because precision,


Let’s talk JavaScript

like you are programming something, you are programming a precision machine because that's


Let’s talk JavaScript

what a computer is.


Let’s talk JavaScript

I understand.


Let’s talk JavaScript

But you are not telling the computer what are you declaring with the variable?


Let’s talk JavaScript

Is it an int?


Let’s talk JavaScript

Is it a float?


Let’s talk JavaScript

Is it a double?


Let’s talk JavaScript

Is it a string?


Let’s talk JavaScript

We'll never know.


Let’s talk JavaScript

We'll never know because JavaScript and Python, but we're not talking about Python.


Let’s talk JavaScript

I understand your quarrels with that.


Let’s talk JavaScript

Yeah.


Let’s talk JavaScript

And then you are printing something for example, and you receive something from a database,


Let’s talk JavaScript

like let's say a number and you store it in a variable and you want to print it on the


Let’s talk JavaScript

screen because why not?


Let’s talk JavaScript

And suddenly you have, for example, not a number error because JavaScript decided that


Let’s talk JavaScript

it's not a number or you want to add one plus one and print it to the screen and you end


Let’s talk JavaScript

up with 11 because you accidentally, and I'm air coding here, concatenated a number with


Let’s talk JavaScript

a string.


Let’s talk JavaScript

I'm done.


Let’s talk JavaScript

I see where you're going with this.


Let’s talk JavaScript

And I have to say I'm with you on this point that loosely typing is inviting trouble, especially


Let’s talk JavaScript

when...


Let’s talk JavaScript

Wait.


Let’s talk JavaScript

No.


Let’s talk JavaScript

You are not supposed to, like the whole point of this podcast is that you are not.


Let’s talk JavaScript

But I'll try to...


Let’s talk JavaScript

You are ruining our podcast.


Let’s talk JavaScript

Hear me out.


Let’s talk JavaScript

So I understand that you quarreled with loose typing.


Let’s talk JavaScript

To be fair, again, if you look at what JavaScript set out to do, typing was not really a consideration


Let’s talk JavaScript

because the programs would be really, really small and they wouldn't interact with such


Let’s talk JavaScript

a huge amount of different data types.


Let’s talk JavaScript

And you can also see that with the data types that it has, it doesn't have like int and


Let’s talk JavaScript

floating point numbers, like no integers and floating points.


Let’s talk JavaScript

It just has a number type.


Let’s talk JavaScript

It now also has big integer as far as I remember.


Let’s talk JavaScript

So it can actually deal with really, really large numbers if you need to.


Let’s talk JavaScript

But it wasn't originally designed for this.


Let’s talk JavaScript

And it gives you a lot of flexibility in your code.


Let’s talk JavaScript

So you can get away with certain errors that just happen because you can just ignore them


Let’s talk JavaScript

and be like, yeah, but like if someone enters this kind of bullshit, then bullshit happens


Let’s talk JavaScript

in the rest of the program.


Let’s talk JavaScript

And I'm, you know what, I'm kind of fine with it.


Let’s talk JavaScript

But there is a point that you're making where this does not work, especially in larger,


Let’s talk JavaScript

more complex applications, especially when multiple teams are working on the same code


Let’s talk JavaScript

base.


Let’s talk JavaScript

This becomes really, really tricky.


Let’s talk JavaScript

That's what TypeScript set out to fix.


Let’s talk JavaScript

So it's a superset of JavaScript where you can actually have type annotations.


Let’s talk JavaScript

And it's quite cool.


Let’s talk JavaScript

It's actually really nice.


Let’s talk JavaScript

I like it.


Let’s talk JavaScript

I use it for RenderTron, for instance, because it just allows me to know what kind of data


Let’s talk JavaScript

I'll be getting.


Let’s talk JavaScript

Because you said, like, what if I have two input fields where I expect people to type


Let’s talk JavaScript

in numbers?


Let’s talk JavaScript

Yeah, but if I read the value that has been typed into an input field, I get a string.


Let’s talk JavaScript

String is a number of characters, like hello.


Let’s talk JavaScript

So if I am asking for the two numbers to be added, I would just get the two numbers written


Let’s talk JavaScript

one after the other because they are coming back as strings.


Let’s talk JavaScript

I can fix that.


Let’s talk JavaScript

I can say like, oh, no, wait a minute.


Let’s talk JavaScript

That's not what I meant.


Let’s talk JavaScript

I actually need the numbers.


Let’s talk JavaScript

So I want to parse these strings into numbers.


Let’s talk JavaScript

That's possible.


Let’s talk JavaScript

If I forget it, I just JavaScript tries to be fault tolerant.


Let’s talk JavaScript

So it's going like, huh, OK, so I'm getting a string and a number.


Let’s talk JavaScript

So instead of just failing with an error, which is perfectly fine in a controlled environment


Let’s talk JavaScript

like a backend server where I control the entire environment, I don't really control


Let’s talk JavaScript

the client.


Let’s talk JavaScript

I don't know what kind of browser I'm having.


Let’s talk JavaScript

I don't know what exactly it does with the data that I pass around here.


Let’s talk JavaScript

There might be extensions that do something with the data.


Let’s talk JavaScript

I don't know.


Let’s talk JavaScript

And there it just tries to be as fault tolerant as possible and goes like, OK, so it doesn't


Let’s talk JavaScript

make sense to add a string to a number.


Let’s talk JavaScript

So I'll concatenate it.


Let’s talk JavaScript

I just put it at the end.


Let’s talk JavaScript

I append it at the end of the string, the number, and then we'll see.


Let’s talk JavaScript

So it's not as much as like, oh, we don't care.


Let’s talk JavaScript

It's more like a how can we make this work nonetheless, which is well-intentioned.


Let’s talk JavaScript

But I agree in large applications, not necessarily going for a good result.


Let’s talk JavaScript

The result is mixed.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

I mean, this also, it's kind of related to some of the functions or algorithms introduced


Let’s talk JavaScript

in the early days, I guess.


Let’s talk JavaScript

Like I'm thinking of stuff like array sort, for example, where it will do something different


Let’s talk JavaScript

than what you expect from the name of the function.


Let’s talk JavaScript

Because with sort, you expect it will sort whatever you throw into it, into the bag.


Let’s talk JavaScript

But that's not necessarily true, right?


Let’s talk JavaScript

Because the sorting mechanism that they implemented for that particular function is actually lexical


Let’s talk JavaScript

sorting.


Let’s talk JavaScript

And if you throw in some numbers, or even worse, some floats or doubles, you are going


Let’s talk JavaScript

to have surprises most of the time.


Let’s talk JavaScript

And that, again, is just one of those early day quirks that they added.


Let’s talk JavaScript

Because back then, it made sense because they were not expecting that JavaScript will evolve


Let’s talk JavaScript

to a point where it's actually creating a single page app, for example.


Let’s talk JavaScript

Mm-hmm.


Let’s talk JavaScript

Yeah.


Let’s talk JavaScript

That's the legacy that JavaScript kind of carries.


Let’s talk JavaScript

And the problem with this legacy is that we can't just undo it all because there's so


Let’s talk JavaScript

much out there on the web.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

What do you feel about prototypical inheritance versus object, for example?


Let’s talk JavaScript

I think for that, we also have to understand that the origins of JavaScript were in functional


Let’s talk JavaScript

programming languages.


Let’s talk JavaScript

And then object orientation was kind of a side node at the beginning.


Let’s talk JavaScript

And I think it makes sense looking at the fact that most of the objects that we dealt


Let’s talk JavaScript

with at the beginning of JavaScript were DOM elements.


Let’s talk JavaScript

And they are kind of also prototypically inheriting from each other.


Let’s talk JavaScript

So if there's this HTML element from which you inherit a subclass like HTML button element,


Let’s talk JavaScript

and then you have, that's the prototype that you're using for your thing.


Let’s talk JavaScript

It also allowed a lot of really creative and flexible things to be done because you can


Let’s talk JavaScript

manipulate the prototype object and then basically change the way that all objects that are using


Let’s talk JavaScript

that object as their prototype at the same time.


Let’s talk JavaScript

So it allows a lot of very dynamic changes to the page.


Let’s talk JavaScript

And it allows a lot of flexible augmentation of things.


Let’s talk JavaScript

And it allows us to patch the language itself quite nicely.


Let’s talk JavaScript

We very quickly learned the downsides of that as a developer community because you cannot


Let’s talk JavaScript

be sure that things on the prototype work the way that you expect them because someone


Let’s talk JavaScript

else could have overwritten them and you wouldn't know.


Let’s talk JavaScript

So I have very mixed feelings about this.


Let’s talk JavaScript

I think it has allowed us to do a lot of creative things when we needed to change the platform


Let’s talk JavaScript

in spite of lacking much forward movement from the standardization organizations.


Let’s talk JavaScript

There have been periods where development kind of stalled for a while.


Let’s talk JavaScript

Recently, it's mostly frowned upon to do things that we used to do earlier, like 10 years


Let’s talk JavaScript

ago.


Let’s talk JavaScript

And there are better ways of doing things.


Let’s talk JavaScript

But I think prototypical inheritance is not necessarily the greatest concept.


Let’s talk JavaScript

It has worked out remarkably well.


Let’s talk JavaScript

But I think we are now seeing the limitations.


Let’s talk JavaScript

Stay Forever One thing that we haven't mentioned is the


Let’s talk JavaScript

ECMA upgrades to JavaScript.


Let’s talk JavaScript

Do you think those new versions of ECMA will actually solve anything or make it better?


Let’s talk JavaScript

MARTIN SPLITT RODMANNEN Yeah, they already did and they will continue


Let’s talk JavaScript

to do.


Let’s talk JavaScript

So one thing is we got in ECMAScript 2015 or ES6, as some people call it, ECMAScript


Let’s talk JavaScript

6, we got huge updates.


Let’s talk JavaScript

We got class syntax, which we are still having the prototypical inheritance, but we now have


Let’s talk JavaScript

a better way of expressing it in code so that usually the things that can go wrong are not


Let’s talk JavaScript

actually going wrong anymore.


Let’s talk JavaScript

It's harder to make mistakes accidentally because we now have syntactic sugar that prevents


Let’s talk JavaScript

us from doing things the wrong way.


Let’s talk JavaScript

Stay Forever One Say that again.


Let’s talk JavaScript

MARTIN SPLITT RODMANNEN Syntactic sugar.


Let’s talk JavaScript

Stay Forever One Again.


Let’s talk JavaScript


Let’s talk JavaScript

Stay Forever One Oh, that's so wonderful.


Let’s talk JavaScript

I never heard that before.


Let’s talk JavaScript

MARTIN SPLITT RODMANNEN You're my syntactic sugar.


Let’s talk JavaScript

Stay Forever One That sounded wrong.


Let’s talk JavaScript

MARTIN SPLITT RODMANNEN I know.


Let’s talk JavaScript

That's why I said it.


Let’s talk JavaScript

We also saw a bunch of things in, I think it was, oh my God, now I'm not sure in which


Let’s talk JavaScript

version it was introduced, but basically we are on a yearly release cadence.


Let’s talk JavaScript

So every year there's a bunch of features coming in and some of the, I think it was


Let’s talk JavaScript

like ECMAScript 2018 or something.


Let’s talk JavaScript

It had like two features and that was it, which is nice because you don't have to like


Let’s talk JavaScript

learn a bazillion new things.


Let’s talk JavaScript

But now we have things that make it simpler to do the right things.


Let’s talk JavaScript

Those typing, for instance, can lead to situations where like I have this object, which is an


Let’s talk JavaScript

HTML element, and I want to read its inner text.


Let’s talk JavaScript

So you do like element.innerText, which is the text that is inside the element.


Let’s talk JavaScript

But what if for some reason this element doesn't exist on the page or didn't exist at the time


Let’s talk JavaScript

where I was looking for it, and now it's not an element, it's an undefined value in JavaScript.


Let’s talk JavaScript

And then if I go like undefined.innerText, my program kind of crashes because I'm trying


Let’s talk JavaScript

to access something that doesn't exist.


Let’s talk JavaScript

And the way to avoid that was to basically go like, does this object exist?


Let’s talk JavaScript

If it exists, then do this, which is a bunch of code that you had to write.


Let’s talk JavaScript

And it didn't really exist.


Let’s talk JavaScript

Good code shows you what it intends to do.


Let’s talk JavaScript

And every JavaScript developer kind of by passing of verbal information knows what certain


Let’s talk JavaScript

patterns like if they see a certain thing in the code, they're like, ah, this is meant


Let’s talk JavaScript

to do this.


Let’s talk JavaScript

But the code itself doesn't tell you that the developer actually intended to do that


Let’s talk JavaScript

thing.


Let’s talk JavaScript

This was called like a binary shortcut operator or a logical shortcut operator that you could


Let’s talk JavaScript

use instead of like a lengthy if statement to do this kind of check.


Let’s talk JavaScript

But now we have a thing that very specifically exists to make sure that you're not running


Let’s talk JavaScript

to this mistake where you basically would write the thing like element question mark,


Let’s talk JavaScript

I think it's called question mark question mark dot inner text, where if the element


Let’s talk JavaScript

does not exist, it doesn't try to access inner text.


Let’s talk JavaScript

Interesting.


Let’s talk JavaScript

So now in the code, you can immediately spot like, ah, that's the intention.


Let’s talk JavaScript

We are not sure.


Let’s talk JavaScript

We're not sure if this is actually an element or it might be undefined or something else.


Let’s talk JavaScript

So we are checking if we can potentially make this call.


Let’s talk JavaScript

And if we can't, then we just go with undefined rather than just completely crashing the program.


Let’s talk JavaScript

I mean, that's something that I very much appreciate because the silent treatment of


Let’s talk JavaScript

JavaScript, that's actually something that drives me nuts when with precompiled languages,


Let’s talk JavaScript

you get compiler errors, for example, right on the spot and you don't have to go bug hunting


Let’s talk JavaScript

like an idiot.


Let’s talk JavaScript

I mean, to be fair, the type system is not like not all type systems are equal, right?


Let’s talk JavaScript

There are type systems that are giving you fantastic compiler errors.


Let’s talk JavaScript

And then there's type systems that give you the false sense of security of, oh, yeah,


Let’s talk JavaScript

I didn't get a compiler error.


Let’s talk JavaScript

This should be fine.


Let’s talk JavaScript

And then on runtime still fail on you.


Let’s talk JavaScript

And that's the thing that I'm always a little wary of.


Let’s talk JavaScript

So to give you an example in Java.


Let’s talk JavaScript

OK, Java is one of the other things that I have grievances with.


Let’s talk JavaScript

It could also be C++, actually.


Let’s talk JavaScript

If I am trying to get a handle on a file and then I try to read on it without checking


Let’s talk JavaScript

that I actually got a handle on the file, I'm like, yeah, no, this is type file.


Let’s talk JavaScript

So I can be sure that if I open this file, I get a file object back.


Let’s talk JavaScript

But that's wrong.


Let’s talk JavaScript

Sometimes you get null back if the file can't be opened for some reason.


Let’s talk JavaScript

And then all this subsequent, you have to have an if there that checks if the file has


Let’s talk JavaScript

actually successfully been opened or not.


Let’s talk JavaScript

OK, that's fair, actually.


Let’s talk JavaScript

And in some languages with typing, we would agree that C and C++ are strongly typed languages.


Let’s talk JavaScript

But yet there is potential for an undetected runtime error in this case.


Let’s talk JavaScript

But then there's languages like Scala, for instance.


Let’s talk JavaScript

They would not do that.


Let’s talk JavaScript

They would be like, you open the file, you get an option of a file back.


Let’s talk JavaScript

I'm not sure which other language it is.


Let’s talk JavaScript

I think it's TypeScript, actually.


Let’s talk JavaScript

It would be called a maybe of a file.


Let’s talk JavaScript

So I can't just say, read this maybe of a file, because then the compiler would say,


Let’s talk JavaScript

no, no, no, no, no, wait a minute.


Let’s talk JavaScript

We are not sure that this is an actual file handle yet.


Let’s talk JavaScript

You need to make sure that this is a file handle.


Let’s talk JavaScript

So it prevents this runtime error from going undetected by the compiler telling me, no,


Let’s talk JavaScript

no, no, no, no.


Let’s talk JavaScript

FileOpen did not give you a file.


Let’s talk JavaScript

It gave you the potential of having a file.


Let’s talk JavaScript

And then in the language, you have something where you can say, OK, so this maybe of a


Let’s talk JavaScript

file or this option of a file, is this actually a file?


Let’s talk JavaScript

Or is it something else?


Let’s talk JavaScript

And then you can handle these things, which I think is really, really cool.


Let’s talk JavaScript

But again, not all type systems have that.


Let’s talk JavaScript

GABRIEL KREIMAN KINOPOLAOZNIKYANO Yeah, internally, in C++ at least, we are


Let’s talk JavaScript

solving this with a special library that we use for optionalizing something and then giving


Let’s talk JavaScript

whatever the user of that variable can handle.


Let’s talk JavaScript

MARTIN SPLITT


Let’s talk JavaScript

Many of the things are actually a historical thing, but there's a path forward that leads


Let’s talk JavaScript

to a much nicer place.


Let’s talk JavaScript

MARTIN SPLITT Yay!


Let’s talk JavaScript

That makes me very happy.


Let’s talk JavaScript

Yes.


Let’s talk JavaScript

It doesn't make me happy, but you did anyway.


Let’s talk JavaScript

MARTIN SPLITT Aww.


Let’s talk JavaScript

I mean, we're not in the happy land yet, but I'm pretty sure that we'll be seeing more


Let’s talk JavaScript

improvements to the language in this yearly cadence.


Let’s talk JavaScript

And I think we're on the right path.


Let’s talk JavaScript

MARTIN SPLITT I think that's what tipped me over.


Let’s talk JavaScript

Like when you said that it has a yearly cadence, then that's actually a good thing.


Let’s talk JavaScript

I can see how some people might not like it because then JavaScript keeps changing.


Let’s talk JavaScript

But for a language as primitive as JavaScript, and I'm saying primitive in the sense that


Let’s talk JavaScript

it was developed in an era where it didn't need to be too smart.


Let’s talk JavaScript

For a language like that, it's actually a good thing if it has a yearly release that


Let’s talk JavaScript

improves the language itself.


Let’s talk JavaScript

MARTIN SPLITT And that's something that I also really, really like because it makes


Let’s talk JavaScript

sure that we are not making one huge leap that breaks everything that has existed before.


Let’s talk JavaScript

I don't know if you have been caught up in the Python 2 versus Python 3 situation.


Let’s talk JavaScript

I loved Python until they did that weird transition.


Let’s talk JavaScript

And I am not very happy with how that transition went, to be honest.


Let’s talk JavaScript

Because now we're in this mess where you're like, oh, this library solves my problem.


Let’s talk JavaScript

Oh, but I can't really use it.


Let’s talk JavaScript

Or like, oh, I can use it, but it's a lot of work to actually make it work properly.


Let’s talk JavaScript

And oh, this is breaking now.


Let’s talk JavaScript

And I don't know why both of these programs are Python programs.


Let’s talk JavaScript

Why does one work and not the other?


Let’s talk JavaScript

It works on this machine.


Let’s talk JavaScript

It doesn't work on the other machine.


Let’s talk JavaScript

Oh, look at that.


Let’s talk JavaScript

This machine only has Python 3 available, but the program was written into.


Let’s talk JavaScript

It's a mess.


Let’s talk JavaScript

It makes me very, very sad that this has happened.


Let’s talk JavaScript

And I think we had a near miss with ECMAScript 2015 or ES6 because there have been years


Let’s talk JavaScript

and years between the previous version and this version.


Let’s talk JavaScript

ES5 to ES6 has been a long transition coming.


Let’s talk JavaScript

And a lot of stuff was introduced, and a lot of things have changed in the language.


Let’s talk JavaScript

And everyone was very grumpy about it.


Let’s talk JavaScript

But now with the small incremental changes every year, it's easier to follow what's happening


Let’s talk JavaScript

and deciding, do I need this feature?


Let’s talk JavaScript

Do I care about this feature?


Let’s talk JavaScript

Or do I just put it in my toolbox for a potential future situation where I might need it?


Let’s talk JavaScript

So I think yearly change cadence helps the language stay relevant and modern.


Let’s talk JavaScript

OK, fine.


Let’s talk JavaScript

Yay.


Let’s talk JavaScript

I'll accept.


Let’s talk JavaScript

Thank you.


Let’s talk JavaScript

That maybe I have to like a little bit more JavaScript.


Let’s talk JavaScript

I'll make a I love JavaScript t-shirt and send it to you.


Let’s talk JavaScript

I will burn it outside on the grill.


Let’s talk JavaScript

Oh, wow.


Let’s talk JavaScript

OK.


Let’s talk JavaScript

In that case, I might not do that.


Let’s talk JavaScript

I might save me the effort.


Let’s talk JavaScript

But at least you're not saying JavaScript is the worst thing ever anymore.


Let’s talk JavaScript

Oh, I will say that.


Let’s talk JavaScript

But you won't mean it?


Let’s talk JavaScript

I, maybe.


Let’s talk JavaScript

Go ahead.


Let’s talk JavaScript

I don't know.


Let’s talk JavaScript

Yeah, that's enough.


Let’s talk JavaScript

Leave me alone.


Let’s talk JavaScript

That's enough for me.


Let’s talk JavaScript

I'll see what I get here.


Let’s talk JavaScript

All right.


Let’s talk JavaScript

So you know what?


Let’s talk JavaScript

I'll take that.


Let’s talk JavaScript

I'm as happy as I can be with you saying maybe JavaScript isn't necessarily the worst thing


Let’s talk JavaScript

ever.


Let’s talk JavaScript

So I hope that our listeners feel the same way and that they have learned a few things


Let’s talk JavaScript

that they didn't know beforehand.


Let’s talk JavaScript

And I clearly see your point now.


Let’s talk JavaScript

I understand people out there who are like, I'm with Gary on this one.


Let’s talk JavaScript

But I would say it's a tool that can be used either way.


Let’s talk JavaScript

And with that, I guess we can go and enjoy life outside of the browser and outside of


Let’s talk JavaScript

JavaScript.


Let’s talk JavaScript

What do you think?


Let’s talk JavaScript

I don't like it.


Let’s talk JavaScript

You don't like it?


Let’s talk JavaScript

Goodbye.


Let’s talk JavaScript

OK.


Let’s talk JavaScript

In that case, bye-bye out there, everyone.


Let’s talk JavaScript

No matter if you like JavaScript or not, have fun.


Let’s talk JavaScript

Build cool things.


Let’s talk JavaScript

Bye-bye.


Let’s talk JavaScript


How to hide text in a snippet? #AskGooglebot

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


Google Bot.


I'm here from Google's Search Relations team


to answer your questions about Google Search.


Our question today comes from Ariadna,


and it's about not showing some text in a snippet.


Taking a step back, the snippet is a short description


shown per page in the search results.


Our systems try to describe how this particular page


might be helpful for the user's query.


We may show different texts depending


on what was searched for.


Usually, we focus on the description meta tag,


and sometimes we use text from the page too.


The snippet shown is not a ranking factor.


However, it can help users to choose


which result to click on, so it's kind of worth


double-checking.


In some situations, you might not


want to show specific things from the page itself.


That might be dynamic content or just something


you'd prefer only to show in the context of your own page.


Recently, we introduced a way to let us know about text


you'd like to exclude.


It's called the data no snippet attribute.


You can apply this to specific HTML elements,


and we'll then know not to show that text within the snippet.


We have to recrawl and reprocess the page


to find that so it won't be immediately changed.


There's more about this attribute,


as well as about other meta tags to control snippets


in our search developers documentation, which


is linked in the description.


And that's it for this time.


I hope you found this useful and insightful.


See you in the next episode of Ask Googlebot.


And don't forget to subscribe to see the next episodes.


hours.


From journalism to SEO with Jennifer Slegg

Hello and welcome to another episode of Search Off The Record, a podcast coming to you from


the Google Search team discussing all things search and having some fun along the way.


My name is Typically Gary and I'm joined today by Lizzie Zesman from the Search Relations


team of which I'm also part of.


Lizzie, let's make this awkward, shall we?


Like this?


Yes, thank you.


I can just keep interrupting you.


You're really good at this.


Yeah, I knew it.


Yes.


Okay, you can stop now.


Thank you for the contribution.


Continuing with our In The Spotlight series in which we present folks from the larger


search marketing community who inspire us, today we have Jennifer Slag.


Hi, Jen.


Hello.


Thank you, Lizzie.


Is this thing on?


Okay, good, good, good.


I think I've known Jen for probably like 274 years now or what it feels like.


It feels like that, yes.


It's like no time at all in the grand scheme of things.


How old are you?


How long have you been 17?


A while.


Okay, so the year was 1872 and you met Jennifer here.


Jennifer, how did this go down?


We actually met for the first time at a conference, I think maybe an SMX like many, many, many


years ago and just kind of hit it off from there.


I don't remember which conference was it.


I'm speculating that it was either SMX Advanced in Seattle or it was the New York one, but


I don't actually remember the exact one.


And I also don't remember whether it was me on stage and then after that we just chatted


about something or it was more like email or something.


I remember chatting with you, I think in the speaker's room maybe, because generally I'm


not one of the let's swarm the Google speakers after a speech kind of person.


I miss those times.


I know that's your favorite part.


Yes, especially after COVID.


That's a fantastic experience.


But anyway, we met and then we were chatting about all search stuff because that's what


we do and we were geeking out about search.


And I think I remember that at one point we discovered that we are both playing this weird


game called Ingress, if I remember correctly.


What is that?


This is like the second or third time I've heard this.


I don't know what it is.


Is it still like, is it a niche thing or?


I think it's very niche.


It's very niche.


Okay.


And you're still playing it?


Off and on.


It's kind of like a predecessor to Pokemon Go, which people are probably more familiar


with.


And you're also playing that, right?


Yes.


When Pokemon Go came around, did you stop playing Ingress or are you keeping both open?


I played both for a while, but then they released a new Ingress and I didn't enjoy it as much.


So I kind of focused a bit more on Pokemon.


Yeah, that was probably the mood killer for me as well.


The new Ingress Prime.


That was too much change.


But it's a walking game.


So you walk around like a headless chicken and then you try to kind of like geocaching


and then you find places and then you interact with places and it can be an AR experience.


Well, it is an AR experience.


So it's really good for walking.


I see.


So they incentivize you with something like...


And I remember that when we went with Jen to the same conference, then sometimes we


spent time like Ingressing around, which meant that sometimes we walked like probably 20,


25, 30 kilometers, which is...


Yes, in a day.


That's too much.


I don't know.


It was crazy.


For American listeners, that's about 750 football fields.


What do you say we talk about search a little bit?


Because you know, search off the record, not Ingress off the record.


So for those who don't care too much about quality raters, guidelines, and EAT who might


have read your publications, I want to say a few words about who are you and what are


you doing and why are you doing and why are you?


It's like so many questions.


I'm pretty much just a girl who does a lot of writing and research in history.


My background is in journalism, so I was actually published in newspapers a long time ago before


everything was online, believe it or not.


Wait, newspapers.


I know, right?


Like when I actually had to go down to the newspaper and submit my article on a floppy


disk.


What?


Wow, okay.


And then you were writing about what?


Back then I was writing about history, so different historical things that happened


where I live.


Oh.


Did you specialize in a particular time period?


Not really a particular time period, but more like interesting historical events or buildings


or places in my hometown.


So we had a few different newspapers here and I wrote for each of them at some point.


Did you have like your own column kind of a thing so that you could establish like a


piece?


No, but they typically would have, especially on like Sundays, they'd have like more of


an artsy kind of a section of the newspaper and so they would publish historical pieces


and stuff.


So that's where I got my start for being published.


And then you went from history to search?


I know, right?


How?


So what actually happened was, so I was doing writing and it came up that there was an learn


HTML.


So I'm like, internet was like brand new then and so I went to take this class to learn


how to do HTML.


And it was back when everything was hand coded.


So Dreamweaver didn't exist, Frontpage didn't exist.


I learned how to code.


I learned how to hand code in Notepad.


I don't even think Textpad existed then.


So I learned how to code by hand and that's how I designed my first website.


And I remember how excited I was when this program, Hotdog, came out where it was like


you could hit a button and it would do like your HR and like it would automatically input


your tags for you.


That was all it did.


It was just basically a shortcut for different HTML code tags.


But oh my God, I remember just being so excited and thinking it was like the best thing ever.


And then eventually I got Dreamweaver and then, you know, that was a whole different


ballgame.


I was like, this is amazing.


And also it was the devil basically because it was doing so much weird stuff with the


HTML that...


Let's just ask Frontpage though, I tried Frontpage for a little bit and that was atrocious.


Jen, Jen, we don't talk about Frontpage here.


It's one of those topics that we cannot talk about.


It's a forbidden topic.


How did you end up talking about QRG, like the quality readers guidelines and EAT?


So far you have HTML.


I assume that you had a website because HTML, you know.


Yeah.


And so I just started to get more interested in like how to make it rank and dabbled a


little bit in pay-per-click back when Overture had penny clicks, which was like the exciting


thing.


Trip down memory lane, right?


And then eventually when Google became a thing, I started learning more about Google and it


literally snowballed from there.


And when I got into the interest of like really how to make good content for SEO, obviously


eventually QR quality reader guidelines kind of fell into that aspect as well.


Do you remember like when they were like published the document for the quality writer guidelines?


I'm assuming it was not when Google was founded.


There's probably some...


It must have been about 2010 I think, maybe somewhere around there.


I think it's even more or even more recent because I remember that Paul Haar, one of


our leads, was very excited about it.


I think previously it was somehow leaked or something like that.


And then people picked it up and then Paul, again Paul Haar, decided that why don't we


just like publish it because it doesn't actually have anything that we need to keep secret.


So let's just publish it and then there's no risk of leaking.


Oh yeah.


I remember I wrote about them, like all the updates for probably two or three years before


like all the leaked versions that someone would leak eventually or I'd get a copy and


be like, don't tell anyone I gave this to you.


From like SEOs who had their like kids doing quality reader guideline things.


And then eventually once they released it publicly, it was amazing because then we all


had access to kind of like...


It's kind of like the blueprint of what Google wants to see for the highly rated websites


as well as what they don't want to see, which I find just as fascinating.


Yeah.


Have you ever written about EAT, like specifically?


Not specifically.


I've given a lot of talks about EAT, but only in terms of like how it's impacted in the


whatever changes were made.


Do you think we should keep it a secret what EAT means or we should tell listeners?


Or me.


What if I don't know?


It means eating, right?


Like we're talking about food.


Sure.


Okay.


It's an acronym, right?


If people are spelling it out, it stands for something, right?


EAT.


It stands for authoritativeness and trustworthiness.


It's always a big mouthful to say that.


So we all just call it EAT.


What's the other one?


YAML.


Oh, how do people say that verbally?


Because I've literally never said it.


I call it Y-M-Y-L.


Your money, your life.


Oh yeah.


Y-M-Y-L.


Not YAML.


That's a different thing.


It's also so interesting because internally you rarely ever hear these things.


And then you go to a conference and that's all people talk about.


Everyone is talking about it.


Yeah.


And we do have those terms in the QRG, in the quality readers guides or guidelines.


But I don't know, internally you just don't hear them for some reason.


Anyway, it's kind of interesting.


You have access to the more exciting things though that we don't.


So just a bit.


I don't want to talk about it.


Okay.


So, oh, you mentioned floppy disk.


Yes.


I'm jumping back and forth on the timeline.


So now we are back in 1872.


You mentioned floppy disk, which means that you had a computer.


Do you remember which computer you had?


Like what kind of computer it was?


Well, it had four megabytes of RAM and I still had to dial up.


You were rich.


And I remember when I got my laptop and it had eight megabytes of RAM, I was like so


excited.


Rolling.


So like the floppy disk to the website, was that the motivation to learn HTML so that


you didn't have to hand carry the floppy disk or what brought you?


My newspaper didn't even have an online presence at the time.


So they wouldn't even be able to like receive anything.


It's like, mail me a letter.


It was like, it was like word document, here you go.


And and yeah, like when, so when I started learning HTML, we were still using Netscape,


I think.


I'm pretty sure Internet Explorer didn't exist yet.


So it was like purely personal project, like not something that they could better the newspaper


relationship just like you're interested in learning HTML.


Yeah, just personal.


It was, you know, it's a topic I was interested at the time.


Then I was also doing, helping out a family business.


And so it just kind of went from there.


Was that your first website or did you build something for the class?


We did.


I can't remember if we built something for the class, but a little bit later, I took


a class at university.


So I was working on a history degree, but I took a minor in professional writing.


And there was a class on learning HTML.


Well I'm like, well, I already know how to do this.


I'm going to take this and get the, you know, the easy A+, which I did.


But one of those things was creating a website.


And so that is actually how I really got interested in SEO was because it was that website that


I worked on just on a hobby topic at the time that made me kind of start getting interested


in how to, you know, promote it better online.


Do you remember what the hobby topic was?


I do, but I'd rather not say.


Oh no.


It actually still exists out there in some form.


It's a little bit of money.


Oh, okay.


Now I have to find it.


I know.


The intrigue.


Are you done?


I know what this evening will be like.


I'm sure it has, like, I haven't really touched it for a long time, so I'm sure it has horrible


SEO techniques on it that people would be like, oh my God.


But it's, it just kind of exists right now.


Where is it?


Tell me.


Maybe, maybe one day I'll go and refresh it, but it's not really been high up on my radar


when I have other sites.


I need to know.


I get to know.


You mentioned that you were already thinking a little bit about SEO, but you just got on


the internet with your website and we don't know what kind of search engine were you optimizing


for.


Oh, back, was it Yahoo back then?


Well, when I originally started, I think it was like web crawler maybe?


Like one of the original, I know I'm blowing my mind.


It was like 92, 93.


Yeah.


I remember voting on like their icon they were going to use when they were going to


change their logo.


Was there much written on the web about how to do this?


Like how did you come about like, oh, this is even a thing to do.


And then you were going to write about it.


It was just kind of like an up and coming kind of thing.


And you'd, you know, you'd search the web and, you know, really slow results obviously,


because everyone's up on dial up and then, you know, you'd land on a webpage where they'd


have the MIDI playing in the background, of course, which was the big thing with their


counter of how many hits they had.


And so just kind of like, well, I'd like to learn how to do this.


But obviously, there were just no builders back then.


So it was you literally had to learn how to do it yourself then.


Yeah, the internet was so much more different than today is because it was kind of like,


I don't know, like Wild West.


Like you had really weird websites.


And then in contrast, you had really like popular big websites that were trying to do


something nicer.


But then you also had those weird sites like the $1 advertising space, like the guy that


was selling one pixel.


The pixel?


Oh, that was much later.


That must have been only 10 years ago, maybe.


Really?


I think it was more recent than that.


Oh, wow.


Okay.


Blurring the timelines.


I know.


Fine.


But yeah, the internet was much weirder than nowadays.


Yeah.


It was also really weird that you couldn't really find the information.


Like even if search engines were doing a better job, the information was just not on the internet.


Like nowadays, we have Wikipedia and basically, you can find literally anything about pretty


much anything.


Back then, it was kind of empty.


If you've got one or two results, it was kind of like a big deal because there was just


a lot of searches that just returned nothing just because there was such a limited number


of people that were capable of making websites back then.


Was there any data available about what people were searching for even at that time?


No.


You're just kind of flying blind.


No, I don't think so.


I remember that with AltaVista, we were trying to guess what other people were searching


for based on what AltaVista was returning to us when it was not matching our queries.


For example, you searched for funny cat or whatever.


And then the first two results on the top were about funny cats, but then below that,


you could see just cat, something like feeding cats or funny trees or whatever.


So the information retrieval part of those search engines was very different, but it


was helpful to understand what kind of content people are creating on the internet.


Yeah, you had kind of like a small, because there was just not many people creating websites,


you kind of had really random topics.


And back then, like web rings was a thing.


So you'd click on the web rings and you actually could find some really interesting, you know,


niche topics back then, just because there wasn't a lot out there.


What is a web ring?


Sorry.


It was basically this thing that people would put on the footer of a website and you'd have


a bunch of people that would all join it and you'd click it and it would take you to like


the next random website.


Oh, like shuffle.


Just play me a next song that's random.


Pretty much, yeah.


And it would, some of them would just not even be related whatsoever.


Others would be loosely based on a theme like sports or history or, but pretty generic still.


It's also kind of interesting that there were, or it feels like, and maybe this is my memory


fooling me, but it felt like there were much fewer commercial websites or sites that were


trying to make money out of their content or off of their content.


Basically just went to a website, like a recipe website, and you didn't read about Adam and


Eve and how the apple became the pie, but it just got to the point like you need two


apples and this is the recipe, the rest of the recipe.


And there were no ads, no nothing.


It was just the content itself.


And that was kind of nice.


Yeah.


So there wasn't the mentality of where people are like, oh, I'm going to make this website


to make money.


It was like, I want to make this website because I really want to share this information with


people.


Yeah, it was nice.


And then the downfall of the internet.


And then Google launched in 96.


And then AdSense launched and that was kind of like the big game changer for people being


able to.


I think AdWords launched in 2000, 2001.


Around there, yeah.


I think AdSense was 2003 or 2004 maybe.


And then people started making money and then, oh boy.


Then everyone became an expert on like mesothelioma.


Oh, yeah.


Oh my god.


How can you even pronounce that?


I have to say I did not know it was a thing until people were like, this is the most expensive


keyword on AdWords.


What's the deal behind that?


Like why?


It was lawyers were willing to pay a lot of money to have their ads show up for mesothelioma.


Interesting.


Yeah.


Back in the days when I was doing things differently, like I was spamming the internet, then I had


an affiliate network of which I was making some money.


And I wanted to target this mesopotamia or whatever, sure, thing.


And it was like, you actually have to pay the affiliate.


No you actually had to pay to become the affiliate of the network or something like that.


It was a very, very specialized affiliate network.


And apparently the commissions were like mind blowing.


But it was big money to get in.


And the same was for AdWords as well.


Like if you wanted to advertise content that was targeting this mesopotamia or whatever,


then you had to pay very, very big money to get like basically like it was like I'm making


stuff up, but it was like 100 bucks per click or something like that to even show up for


that.


And then.


The internet evolves.


Jen starts writing.


Like she starts writing about search.


She stops doing just HTML hobby website to then you are publishing on your own site about


search.


Yeah.


It's again, it was just kind of like writing about what I was interested in.


That's part of why I one of the things I'm probably best known for other than the quality


radar guidelines is I wrote a big thing about Panda.


Oh no, not Panda.


And that's like one piece that got a lot of good feedback because I actually was able


to get a lot of quotes from Google about things related to Panda that hadn't really been confirmed


before.


And it's I don't know.


That's like one piece I'm really proud of.


It's I like teaching people like how to create good content like and not create kind of like


crappy content and why it's so important to like write for your audience and not write


for Google per se.


So I think that article kind of did a really good job of kind of trying to like show people


how important it is to write for your audience and not keywords and search engines.


But it's not easy to write about these topics.


Like you wrote about the QRG, you wrote about Penguin, Panda, whatever.


They are all quite abstract.


Like when we are talking about these externally, they like we are abstracting quite a lot.


And yet the articles that you publish or posts that you published, they are very understandable


and very relatable for website owners.


And that's one thing that I don't understand.


Like how did you digest what we said, what we abstracted into those long winded posts


that actually explain the thing really well?


So I really tried to not just be like, this is what Google says and this is what changed.


But I also like to go into like, OK, this is what changed.


But this is why it's important for readers and SEO writers and the industry to know like


how it's all good.


And I'll find that need to be like, oh, you need EAT.


But I try to go more and show like, OK, why is this important, how you can do it rather


than just do it.


So I guess I try to be more to explain it more, I guess, and break it down rather than


just say, do this, let a lot of other people tend to do.


But that also makes it a lot long winded.


No, it's like super detailed, super thorough.


And there's this like element of analysis that is generally missing from other posts


that are just like straight up reporting like this is what happened.


But yours has like the take, like your particular take on what each thing means, which feels


unique.


Yeah, that's what I really try hard to do.


And I think I usually nail it.


Do you think we could create an AI gen and then just generate those posts?


I mean, well, I think that the whole idea of AI is kind of fascinating.


Like I've seen some of the stuff that AI can put out and it still kind of reads a little


bit stilted.


Like you read it and you're kind of like something's like not quite right or it's missing.


But then I've seen some AI content where they use tools or whatever to make the AI content.


But then if they have like a really skilled copywriter go and kind of like touch it up


and grammatically phrase things how you'd want to be reading it if you're a reader,


then I've seen some good stuff done that way.


But I think the mass churn and burn kind of approach to AI like spit out a thousand articles


by this AI generator and just publish them all.


That's not really the way to go.


But I mean, there are some benefits I can see where people are taking that content,


but then kind of reworking it that can work, I guess.


Would you ever consider using like a tool to help with anything?


I don't know.


I've not played around with it enough to be confident in what it's producing, at least


at this point.


I just prefer to write it myself and then plug it into like Grammarly and make sure


my grammar is as perfect as I think it is because sometimes I spell things wrong.


I never do that.


You never do that?


My favorite typo ever was I accidentally published rage rank instead of page rank.


Nice.


You can just sell it, it's intentional.


Everyone's like, oh, that's a Freudian slip.


And I'm like, yep.


So, like your writing process with this, is it like, do you approach it in sections or


like do a full stream of consciousness draft?


It's very research approach to like you're like systematically going through the changes


that happened and then there's the big analysis at the end.


Could you talk us through like the writing process?


Yeah.


So often what I do is like I know my points I want to cover, but often I'll be like writing


a section and then I'll be like, oh, I need to write about this as well.


And I'll go and I'll put a little headline or something or subsection headline later


on to know that I'm going to be doing it.


So then I go back and write some more and then, you know, oh, I can't forget to write


about this and the same thing.


And eventually I'll write it all.


And usually what I do that a lot of people don't do is I'll print out a copy and then


and go over it again.


And it helps me kind of visually see like, oh, this section should move here and that


section should move there that you don't necessarily notice when you're kind of like scrolling


down a page as you're writing.


So I'll do that as well.


Then I'll do my edits and make sure that, you know, I have no rage ranks in there and


or that you do have them, inject them.


And I often then will just like set it aside for, you know, a couple hours or overnight


and then come back to it and it'll be like, oh, I forgot I need to add this part or oh,


I should expand on this section a little bit more because I think people would, you know,


be interested to know a little bit more about the thought process or why this is important


or that kind of thing.


How long do you spend in kind of the thought process before you start writing?


Like the new Quality Raiders guidelines comes out, you read it and you're like percolating


on the magic.


So usually when it's like the Search Quality Raider guidelines, I'll have, I'll print out


copies actually.


Okay.


Because I've seen some people use like a tool to kind of show the differences and for some


reason it doesn't read the Quality Raider guidelines very well.


So I actually go through and I'll have like copies, each copy and I go through with my


highlighter and as I go through it, I'll highlight things that are missing or highlight things


that have been added and then I'll actually like write my notes right on the copy so that


when I go back to actually write it, I have all my notes right there, like all the little


things I'm like, hmm, this is interesting or oh, that's kind of interesting that they


removed that or added that or I'll be like, hey, this is the third time they've mentioned


this unique thing about the Quality Raider guidelines that have been added this time.


So I think I tweeted once a copy of what one of my note pages looks like from a random


Quality Raider guidelines that is like highlighted and stars and notes written all over it.


So that's kind of like part of why I think my posts, why people really enjoy them because


I do kind of go right down into the nitpicky aspects of every little nuance that changes


and why it's important.


Correct.


And also noticing when something is happening multiple times, like it's not just, oh, a


change lock.


And it's also annotating the change lock itself.


Like why did they include these things in the change lock?


Like this is interesting.


Yeah.


So a lot of it is speculation like, hmm, you know, okay, Google has added this thing in


five different spots in the Quality Raider guidelines.


This is telling us that this is somewhere that they're wanting their algorithm to go


in the future.


So if your site's either doing this or not doing this, this is something that's important


to pay attention to.


And you know, maybe it's something you want to focus on for your own sites.


Do you think people listen?


Well, I think sometimes, I mean, it's all, I mean, you know, people like to, there's


some people that are like, you know, this is the Bible and then there's other people


like we don't need Google to tell us what to do.


And so there's kind of like two interesting thought processes I think of people in the


industry of what they take away from them.


That said, I know that pretty much everyone will, you know, go over it themselves at least


and try to see what's new and changing because at the end of the day, they want to know what


Google's doing for the future, right?


Because then you can future proof your own content.


That's fair.


Do you still like doing it?


Yeah, I always find it fascinating.


Like it's, I just find it really, really interesting to kind of see where the changes are.


And there's been a lot of times where I've gone and I've, you know, noticed something


that has changed.


And usually because mine are so involved, a couple other people will publish it or people


will be tweeting about it and then I'll come out and people are like, whoa, I didn't even


notice that part.


So it makes me feel good.


Cool.


So if people wanted to read about the QRG and YMYL and EAT from your pen, where could


they find you?


They will find it on thescmpost.com or just at GenStar on Twitter where I tweet all kinds


of random stuff when you guys release something new and interesting.


Oh yeah, Twitter.


That's a thing.


It is.


Interesting.


Well, Jen, thank you very much for joining us here.


I really, really, really hope that we are going to meet again at some conference and


we play some Pokemon Go because that's life.


And which one is the next conference?


I will be at PubCon Austin.


That'll be my first post-COVID conference.


Oh, exciting.


Early next year.


Yeah.


Wait a minute.


I'm going to that too, I think.


Imagine that.


It's highly suspicious.


This is highly suspicious.


Okay.


Again, thank you for joining us.


Thank you for having me.


Have a wonderful day.


On the next episode, we are going to talk about search incidents and search incident


reporting.


We've been having fun with these podcast episodes.


I hope you, the listener, have found them both entertaining and insightful too.


Feel free to drop us a note on Twitter at Google search C or chat with us at one of


the next events we go to if you have any thoughts.


And of course, don't forget to like and subscribe.


Thank you and goodbye.


Bye.


Build a successful web presence with Google Search (Google I/O '18)


Hi, everybody. I'm really glad to see all of you here. You


skipped lunch to come hear about Search. No pressure.


We're both from Google Switzerland.


Our role at Google is to help the web ecosystem


to be more successful in Google Search.


So we hope we can bring some of this across here as well.


Right.


So I want to start us off with an example of how this actually


works so you can get an idea of what you as a developer


can do to be more successful with Search.


So this is a Japanese website Rakuten Recipes.


And they wanted to get more users.


They also have a ton of delicious recipes


on their site.


So they were wondering, what can we do to get more people


to notice us in Search?


And what they decided to do is they changed their CMS


in order to be able to mark up every recipe that


is added to the site with structured data markup.


What this does is it lets the search engine


know that there are different entities.


So things like cooking time, different ingredients,


a picture, and lets us display the result


in a much more attractive way in the search results.


And the site itself was in Japanese.


So we decided to switch off the markup for those of you


who don't speak Japanese to something more legible.


So instead of dumplings, you have here a party coffee cake,


but it works the same way for dumplings.


And this is how this ends up looking


like in the search results.


So you can see that in addition to the regular elements


of the search page, so they have a title, they have the URL,


and then they have the description,


they also have a really nice picture of dumplings,


and then they have the cooking time as well.


So this worked out for them pretty well, in fact,


kind of spectacularly.


So they got 2.7 times more traffic from Search.


Yeah, and we thought developers usually don't get as much


advice around Search.


And they might not even know about all of the pitfalls


and possibilities.


Shouldn't we share some of the knowledge with them?


So with you all as well?


So we hope we can show how Search


can make your projects a little bit more successful.


So today, we'll look into various types of public web


presences and give you a broad overview of specific details


that you, as a developer, can watch out for and implement.


And these details can help make your projects more successful


on Search, making it easier for search engines


to send users to your projects directly.


So you might be thinking, as a developer,


I don't really care how or if my stuff appears in Search.


But probably your customers, your users,


the people that you're building these projects for,


they do care.


And since you control how your content appears in Search,


you can have a huge impact here.


Think back about Rakuten Recipes and what they did there.


Globally, Google Search and Google News


sent billions of visitors each month to websites for free.


And it's not just about websites.


We're going to be looking into various ways


that Search can work depending on what you're working on.


A website is just the most common format.


You could also be building a web app, which is kind of similar,


but slightly different as well.


Or you could be contributing to a content management system,


a so-called CMS, which enables others


to build websites of their own.


Or as a part of that, maybe you're


working on plugins or themes or extensions for these content


management systems.


We'll take a brief look at these,


as well as detailed recommendations


for each of them.


And as I mentioned before, Search


brings billions of visitors to websites every month.


That's a lot of visitors.


We serve trillions of searches each year.


And out of those, this is quite surprising for me


every time I look at it, about 15% of the queries every day


are completely new ones, things we've never seen before.


So maybe they're looking for one of your projects.


And regardless of what you're building,


if search engines understand your content,


you could get a lot more visitors and potential customers


with Search.


So you as a developer, you can control that through the way


that you set up your website or content platform.


So to understand these better, let's take a quick look


at how Search works.


Right.


So in order to be successful as a developer in Search,


you need to know at least the basics of how it works.


And I'm going to take you through the super, super


high-level picture of how it works.


If you're interested in the details,


google.com slash jobs, welcome to apply.


And then we can go into a lot more detail.


But let's get started with the super high-level picture.


So we generally talk about three things.


First, crawling and discovery, then indexing, and finally,


ranking and serving.


So I'm going to show you very briefly what


each of these things is about.


So of course, in order for us to be


able to show anything in the search results,


first we need to be aware that it exists.


So we have a series of systems that


are going around, following links on the web,


and downloading web pages, HTML files,


all the different resources that come


into making a website, like JavaScript files, CSS, images,


what have you.


And those systems collectively are crawlers,


and we call them Googlebot.


So the goal for us is to find everything


that is fresh, new, interesting, relevant, and important,


and to do that in an efficient way.


And in order to know which URLs to crawl and in which order,


we have another set of systems, which are known as schedulers.


So they queue the URLs for the crawlers to go and fetch.


And all of this gets then stored.


So you might think that this is a pretty simple process,


but if you start thinking that we


have to do this 20 billion times per day,


then you kind of get an idea that it's


a little bit trickier than it seems at first sight.


In fact, in 2016, we saw 130 trillion pages.


And every new link that we see, usually there's


two more links that we've never seen before.


So there's constantly new stuff, and we


have to decide what to crawl, how to update,


and to do this in the most efficient manner.


So once we find the content, we have a series of other tasks.


First, we have to make sure that we are


allowed to access that content.


And for that, we will first go, every time we access a site,


we'll go to a file called robots.txt,


which is a pretty simple file containing instructions


to search engines and other crawlers.


And it tells you, this is OK to fetch, and this is not OK.


And we obey this very strictly.


So that's the first thing that we'll try to find on a website.


The other thing that we'll try to do


is to get as much content as possible


without troubling the normal work of the server


so the website can function and serve its clients as usual.


And then finally, we'll try to handle errors gracefully.


So as a developer, you have two tasks here.


The first, if you remember again,


that we do fetches 20 billion times a day,


and we see trillions of pages every year,


is that your content should be really easy to discover.


So ways to do that, and John will go into a little bit more


detail later, is to, for example,


submit to us a list of URLs that you have, like a site map.


Or also check that all the resources that


are necessary for your site to be rendered


are accessible to our crawlers.


So once we fetched everything that we were able to fetch,


we go to the next stage, and that is indexing.


So here we're going to parse the content,


and into this comes things like, what language is this page?


Are there any images?


Is there a title?


Is there a description?


And are there different elements on the page?


So to do that, we also try to render the page.


And as a developer, especially if you're


building a lot of really cutting edge fancy things,


you have to keep in mind that currently the search systems


are using Chrome 41 to render pages.


So not all of the different functionalities


that you might be thinking about could be supported by the search


rendering systems.


And if you want to find out more,


I would suggest that you have a look at the talk


that John did earlier today in the morning,


in case you didn't wake up at 8.30 to see it.


It will be available in YouTube, and you'll


be able to see a lot more about what we support in search


and how to render things properly.


So of course, given the huge amount of pages on the web,


we also don't want to index more than one of each unique thing.


So we have a lot of systems in place to eliminate duplicates


and to keep only one copy of each thing.


And then finally, we don't want error pages,


and we also don't want any spam.


So we will kick all of that out, and everything else


that we want to keep, we put in the index


and we process it so that it's ready to serve to users


when they search.


So for you as a developer here, I guess,


it's important to remember that key elements like titles


and descriptions are available in each page


that your users are creating, and then also


to check how it's rendered.


But John will go into a lot more detail here later.


And then finally, once we have everything in the index,


when users start searching, we're


going to pull a set of pages that we


think are relevant results.


We're going to add a bunch of information


that we've already accumulated to them,


like how important they are and how they relate to the user's


query.


And then we're going to show them in some specific order


that we think is most relevant for this user.


So this is mostly on our side, and you


don't need to worry about anything here


if your content is already accessible and easy to render.


But if you're really interested in ranking and search quality,


again, google.com slash jobs, there's


plenty of interesting problems to solve.


So now that you know how search works,


let's have a summary of the two things


that you need to remember.


First, you have to help us find the content,


and second, you have to help us evaluate the content.


So if you're able to do these two things,


you're pretty much set as a developer.


Now, this is super, super high level.


So what we're going to do next is


show you how you can apply this for each specific thing


that you need to build.


So we're going to start with websites,


and John is going to share with you some very specific advice


about what to do and what not to do when you're


building a website for someone.


All right.


Thanks, Maria.


That was a great introduction into search.


So like you said, let's start with websites.


You can build and maintain one for yourself to showcase


your own content, or maybe you're


doing that for other people to let them


create websites on their own.


You might be thinking that showing up in search


isn't really your job as a developer,


but like we mentioned before, as a developer,


you play a really big role in kind of putting everything


in place so that search can pick up the content properly.


So that's really important for us.


When it comes to websites, I think


it's worth taking a really big step back


and looking at the absolute basics.


So for us, that's a URL.


That's essentially the address that's


used to address a single piece of content on the web.


Perhaps surprisingly, URLs are the cause of and solution


to a lot of web search problems.


Traditionally, URLs on the web started out quite simple.


They're requests that's sent to the server,


and the server responds with unique HTML per URL.


Fragments within the URL, so everything after the hash sign


here, they essentially just lead to a different part


of the same page.


JavaScript changed that a little bit,


and suddenly a single URL could do a little bit more


and show different kinds of content


and provide extra functionality.


To keep state, some JavaScript sites


use fragments since these were easy to set with JavaScript.


However, Google generally doesn't support this.


And as far as I know, no search engine


supports addressing unique content


with individual fragments.


So nowadays, we recommend using JavaScript's history API


to use normal, traditional-looking URLs.


So in short, with URLs, stick to something more traditional.


Another really important thing that comes into play with URLs


is that often you have many different URLs that


lead to the same content.


As a developer, that's usually no big deal.


And you can look at that and you think, well, index HTML,


that's obviously the home page.


I mean, that's like every developer knows that.


But for search engines, that's not so obvious.


It could be something completely different.


Sometimes you also just add tracking parameters to URLs.


And all of these different URLs are essentially,


for search engines, separate pages


that we could look at and say, well, there


might be something different here.


And you can imagine at 20 billion times a day,


that could lead to a lot of inefficient crawling.


So we prefer to have a single URL per piece of content.


And there are two ways that you can do that.


The first is to consistently use the same URLs


across your whole website.


So if you have internal navigation linked


to the same pages, if you have a sitemap file,


like Maria mentioned, use the same URLs there.


If you use anything to guide people to your websites,


make sure you use the same URLs there,


instead of having these different patterns that


all lead to the same thing.


And secondly, one element that you can also use


is the rel canonical link element,


which is something you can place in the head of a page that


tells us, well, search engines or Google,


if you look at this page, this is actually the URL


that I prefer you look at.


This is the one that I want you to index.


And together, this makes it a little bit easier


for search engines to pick the right URL.


So we have URLs covered.


What else is there?


Let's take a look at a typical search results page.


So we have on top the title, in this case,


the Google IOs schedule page.


Then we have the URL, which is right below it.


In this case, it's a breadcrumb URL.


We'll look at that briefly a bit later as well.


And then you have the description.


So these are three elements on a search results page


that are immediately visible to everyone


who is searching for something.


And they come from your pages directly.


So it's something that, as a developer,


it's really easy to place.


When you look at an HTML page, they're


very visible and easy to find.


So we have the title on top.


This is really easy to put in here.


We have the canonical tag, the rel canonical link element,


which is also really easy to place here.


And we have the description, meta description.


So while these elements don't directly affect the ranking,


so the order that Maria talked about,


they do affect how we show a page in the search results.


And with that, they do affect how people actually come


and visit your pages or not.


So we've seen a few of the basic elements


here, like the metadata, the titles, the URLs,


and the descriptions.


What could you, as a developer, do


to make that a little bit easier?


Especially if you have various people


who are using your website, your project, to put content online,


we recommend making it as easy as possible for them


to do the right thing.


So not just for you, as a developer,


to put titles, descriptions, and all of that into your pages,


but also for those who are creating pages on your platform


to put that in there.


So here, you see a user interface


from Blogger with a really easy way


to just add a description to individual pages.


And we feel the easier it is for people making your pages


to actually put this content in there,


the more likely they'll actually do that.


So when we looked at the search results,


we saw this kind of breadcrumb there as well.


And a breadcrumb is, for us, something


that you can provide on your pages


to make it easier to understand where this page belongs


within your website.


We call this a type of a rich result,


because it's not just a pure text result.


And there are different kinds of rich results


that you can also use.


For example, you could add markup for articles.


If you have articles on a page, you


could tell us about podcasts, which


is really cool, because there's a podcast player built


into the search results.


So if you have a podcast, if you have a project that


includes audio content, then suddenly that content


is immediately available in the search results


without anyone needing to install an extra app, which


is really cool.


And then finally, recipes, of course,


which we saw with Rakuten in the beginning.


So how do you get all of these rich results?


Well, Maria mentioned that briefly.


Essentially, it's just a bunch of JSON-LD markup


that you can add to the top of your pages that gives us


a lot more information.


So this is something that you can just add to the pages here.


It's really easy to add.


We have a bunch of different types of markup


that you can add here.


There's a code lab here for IO as well on adding


structured data markup.


So if you're curious on how to do that,


I'd definitely take a look at the code lab.


I have a link here.


And the code lab includes information


on finding the right types of markup to add, how to add it,


and how to test it.


So that's a great thing to check out.


Another element when it comes to web pages,


if you're working on just a general web page project,


is speed.


For us, speed is a ranking factor at Google.


So it helps us to determine which


pages we should show in the order in the search results.


But generally, we've also found that speed


makes a big difference even outside of search engines.


And there are various tools to test speed.


We have a link here that gives you


an overview of the different testing tools that we have.


One of the tools is PageSpeed Insights,


which I showed here, that gives you


a great overview of what you could be testing,


what you could be looking at, what you could be improving.


And then one other really important tool


when it comes to search is Search Console,


kind of what the name says.


So within Search Console, you get a lot of information


about this whole pipeline that Maria showed, everything


from discovery to crawling to indexing and to serving,


so how we show your pages in the search results.


You can find information about this in Search Console.


Additionally, we'll also alert you of critical issues


as they arise.


So we strongly recommend that everyone checks this out


if you're making a public web presence, anything


that you want to have indexed in search.


And looks like a lot of you do.


So the first step when it comes to Search Console


is to verify ownership.


We don't show the data in Search Console to just everyone.


You have to prove to us that this is actually your website.


One thing that I find really important here


is if you're making a project for others online,


make it as easy as possible for them to verify ownership.


So make it possible for them to add any of these verification


tokens so that they don't always have


to go back to the development team


and say, hey, I need this special file that


has this content, and put that on the page.


So we talked about websites quite a bit,


but web app is another really important topic, which


I imagine a lot of you have seen in different ways


here at IO already.


For us, a web app is kind of like a normal website,


but it provides a lot more interactive functionality,


interaction, maybe a logged in view, personalization.


Maybe it has parts that don't actually


need to be indexed as well.


For example, a travel business might


have information about timetables and general pricing,


but also have detailed information


about kind of specific connection


plans for individual connections or personalized pricing


as well.


Or in this case, for Search Console,


we have a lot of general informational pages,


as well as a lot of content that's kind of unique


and where you have to be logged in to actually gain access


to that.


So for these types of sites, you kind of


have to balance between what you want to have indexed


and what you don't really want to have indexed.


And for web apps in general, I'd also


take a look at the JavaScript site session from earlier


today.


So there are a few things that we


found that are kind of unique when it comes to web apps


that generally don't play such a big role on websites


in general, especially if you're making normal HTML pages.


The first one is how to actually find URLs on your site.


So we talked about URLs briefly.


Maria mentioned how important they are for discovering pages.


And within web apps, we've seen that people sometimes


don't use traditional anchor tags


to let us know about URLs.


So in particular, we love finding things like this,


where we have an a tag.


We have a link to a page.


We can crawl that.


It's really easy to find.


It's a lot trickier when you have something like a span that


essentially just calls a JavaScript function


with an on-click handler.


Then search engines, when they look at that, they're like,


I don't know.


What do we need to do here?


Does this show a dialogue?


Does this show a new page?


Does this go somewhere?


We don't know.


So we can't crawl this kind of a link.


So what you can do if you want to have an on-click handler


and handle things in JavaScript is combine the two.


So you have your on-click handler,


and you have your href attribute to let


us know about the other page that we can go off and crawl.


Another extreme when it comes to web apps


is that we often run into situations


where we see tons of different URLs, which makes it, again,


quite inefficient to actually crawl through.


So there are different things that you can do here


to let us know about this.


The first is obviously to avoid us actually going off


and crawling all of these different URLs.


So if these don't provide unique functionality


that you need to have indexed separately,


maybe you can use other ways of linking to them


other than a element.


Another thing that you can do is, within Search Console,


tell us about individual parameters within the URL


that you don't care about.


So this is a really neat tool, but it's also


very strong functionality in that if you set this up


incorrectly, then, of course, we won't go off and crawl


all of these URLs.


And if this is something that you care about,


then suddenly we won't be able to index that.


So I'd watch out for this, but this


is a great way of handling this kind of duplication


within a website.


Again, like we talked about before, a lot of web apps


use JavaScript frameworks.


And for JavaScript frameworks, you


have to watch out for some specific details as well,


so that we can actually render the content,


that we can crawl and index the content in an efficient way.


For that, I'd really refer back to the JavaScript site session


that we had this morning.


A really quick way, if you just want


to have a short view of whether or not your JavaScript site,


your web app works for Search, is


to use a mobile-friendly test, which is shown here,


which shows the mobile view as mobile Googlebot would show.


This is really important for us, because we're


switching to mobile-first indexing, where


Googlebot is actually using a mobile device to crawl pages


rather than a desktop device.


So it definitely makes sense to check this out.


And we also have a bunch of best practices and general guidelines


that apply more to web apps that you can check out


in the other session as well.


So what do you do if you're not just building


one application or one website, but rather a whole platform?


I don't know.


Maria, can you tell us more?


I have some ideas.


All right.


So you could be building an individual site or a web app


for someone or for yourself.


Or you could be contributing to an entire content management


system or another hosting platform.


And here, what I mean by this is any type of platform


where other people can create their own online presence.


So it can come in different flavors.


For example, it could be something like WordPress,


where you could download it and host it on your own server.


Or it could be a fully hosted system plus your own domain,


like Squarespace, for example.


Or it could be something where you just get a URL


on their own domain, and also it's


hosted by them like Tumblr.


So there are all these different flavors.


And you could be working for a system like this,


which in its own turn has a bunch of users.


So what you do affects all of these people.


And that is a lot of power and a lot of responsibility.


So we're going to talk about what


can you do to make all these people successful in search


by making some changes to the platform itself.


And this is a really important topic for us


right now because more than 50% and growing of the web


is currently built on various CMSs.


So more than half of the content on the web


is affected by the systems.


And if you're working on one of them


or planning to do so in the future,


it's really great if you're able to make those people


successful in search as well because that's


why they came on the web.


They wanted to connect to others, maybe find


some customers, and so forth.


So we've been thinking a lot about this.


And we've built a set of APIs to help you integrate search


functionality directly into the interface of those systems.


And I want to show you some APIs and how they've


been integrated already, maybe to give you


some inspiration and some ideas about what you can do.


So as John was mentioning before,


the first thing that we need in order


to show any type of search information or search


functionality is to have proof that you're indeed


the owner of the site.


And he mentioned how this works for individual sites.


So you can have an HTML file.


You can use a DNS entry and so forth.


But for those users, especially for the less savvy CMS users,


wouldn't it be great if you could actually


simplify it to one click?


And it is possible with the verification API and three


legged OAuth.


So we've built this API so that you can use it.


And if the user authorizes you, you


could verify their site, which is hosted on your platform,


on their behalf.


They just need to click one button.


And they immediately have access to all the search information.


So the experience for them is really smooth.


And you can do this for 1,000 users or for 2 million users


or whatever it is.


And then immediately they get access to all kind


of interesting stats, which brings me


to the next API, which is the Search Console API.


And that provides access to aggregated stats per site.


So you can see things like clicks, impressions,


crawlers.


You can submit a site map through there.


And you can slice and dice this in many different ways.


So for example, you can look per country, per time period,


or per device.


And you can build very interesting interfaces


with that.


And here on the slide is an example


of a request where you just pulled the top 10


queries per clicks for a specific period of time.


And then as a result, you would get a table


with the query, clicks, impressions, position,


and so forth.


Now, a table in itself might be informative,


but it's not really exciting.


So let me show you some ways in which existing CMSs have


actually integrated this.


We've been working with Wix.


And they created this achievements sidebar


for their users.


So they're using the search analytics data


to give these little badges every time something


happens that they think the user will be happy to hear about.


So their users are super excited about this gamified approach.


And they're constantly looking there in order to see,


OK, what did I get now?


What did I get now?


So here is clicks and impressions


built in an achievements sidebar like this.


We've also been working with Squarespace.


And actually, just this Monday, they


announced this new report that they


integrated into the interface of their own CMS.


So what you see here is the one-click verification.


When the user click connects to Google in the back end,


their site gets verified.


And then this report gets populated with information


from Search Console.


So here, the user can see clicks, impressions,


and the time series over the last month.


Squarespace has a bunch of other analytics reports


inside their CMS.


So people can compare and build the full picture


of how they're doing in Search.


And at this point, they don't even


know that Search Console exists.


But they have everything that they


need to know how they're doing and to accomplish


the correct tasks right there in their Squarespace dashboard.


So we are pretty excited about this kind of functionality.


And we want to build up on it.


And we would be looking forward to work with other CMSs


if you're representing one and you're interested in this.


Another thing that we really wanted to help users with


is get their content as fast as possible on the search results.


And so we've been looking into ways to use the indexing API


that we have in order to get content submitted super


quickly and then also be able to share the indexing decisions.


So what did our search systems think about the CRL,


and what did they want to do with it?


And we worked on this for a few months.


And at this point, it's in a place where


this can happen within seconds.


So again, with Wix, we built a pretty cool integration


where when a user submits a page and it matches a certain


quality criteria, basically they can click a button


within the Wix interface.


And then the page gets submitted through the indexing API.


And then after that, they immediately get a response


if their page got on the search results or not.


So for the Wix users, this is a pretty cool experience


because they can see their page in the search results


immediately after they've created it.


There's no waiting.


There's no wondering, am I on search or not?


Within seconds, they're on Google.


So we're interested in working with other CMSs.


And if you represent some kind of content management


system or a platform which lets users create their own presence


online, and especially if your users are less savvy


and they don't really know what to do with search,


we are really interested in talking to you


to see if it might be a good fit to participate in the CMS


partnership program.


So there is a link on the slide which will take you to a forum.


And there you can tell us a little bit more


about who you represent and how you would like to work with us.


So looking forward to hearing from some of you, hopefully.


Now, you could be contributing not just


to the core product of the CMS, but to a bunch of other things