carousel launched, we have seen a diverse group of content creators using the format


Immersive storytelling on the web | Session

to tell engaging stories. Readers have seen everything from product reviews to recipes


to first person travel guides. The experience was designed so you can easily browse your


interests. When you tap on a story in the carousel, you enter an experience that's full


screen and immersive. Tap to move forward to the next page or swipe to an entirely different


story in the carousel. And to help jumpstart Web Stories, we worked with a diverse group


of publishers and creation tools to collaborate on the product and build out its features.


We have already seen thousands of websites publishing stories that have been indexed


by Google, and we can't wait to see what new use cases and narratives the rest of you come


up with. Publishers and creators of all sizes are increasingly adopting Web Stories to create


a compelling narrative experience for readers. Bustle Digital Group has been working with


Web Stories since late 2019 and has adopted the format across their nine brands. Bustle,


Elite Daily, and Input, to name a few. A major champion of Web Stories at BDG is its editor-in-chief


and executive vice president of Culture and Innovation, Joshua Topolski. He shared with


us his vision for Web Stories in the future of digital content. He said, Web Stories are


a radical new tool in the evolution of digital publishing, one that puts dynamic storytelling


front and center. As a platform for our teams, it expands our editorial language in countless


ways. As an experience for readers, it's simply magnetic. BDG is part of the broader web community


that has made 13 million stories so far in 2021. So hopefully at this point, you're either


interested in consuming stories or making your own. Let's learn how to get started and


make the most of your Web Stories. Whether you're an individual creator or a publisher,


you can easily create your own Web Stories today. But figuring out how to configure,


manage, monetize your own site can be difficult, especially if you're not technically savvy.


Thanks to the tremendous growth in the Web Story tool ecosystem, there are now plenty


of great ways to create, design, and distribute your stories. There are many types of solutions


to choose from. CMS plugins, drag and drop editors, mobile platforms, and more will help


you create and distribute your stories. And if you're technically inclined, you can always


code Web Stories yourself. Web creators around the world are figuring out how Web Stories


complement their websites. We encourage you to tell the stories that you think need to


be seen. Get creative. You have the ability to command every pixel and every story can


be designed to fit your brand. If you're looking for inspiration, check out your own Discover


Carousel. You will find stories that are geared towards lifestyle content like beauty, fitness,


science, entertainment, and more. And now let's take a look at how you can incorporate


your Web Stories into your website. We encourage you to help readers discover Web Stories through


entry points on your own site. Shown here are a couple of snapshots from our newly released


playbook that help you bring your Web Stories to your audience. These entry point designs


are flexible and can show one or multiple stories. We've developed design elements that


help readers instantly identify Web Stories. One element is flexible, making it easy to


integrate Web Stories into your look and feel of your site. Take the experience one step


further by embedding the Web Player into your site. The Web Player makes it easy for publishers


to allow your users to swipe between multiple stories and even enables you to personalize


what story to show next. When stories are easy to discover, views and engagement can


increase offering more opportunities to monetize your content. Speaking of monetizing your


stories, until now the primary ways publishers have monetized their Web Stories has been


direct sold ads and affiliate links. Well recently Google Ad Manager and AdSense have


launched programmatic ad support for Web Stories. This enables publishers to easily turn on


ad monetization and earn more from stories. The story ads themselves are appealing full


screen ad creatives that integrate seamlessly into the reader's journey, keeping them engaged


and delighted by the story content. It's still early days for Web Stories, so we're all figuring


things out together as a community. As more people and publishers use the format, we'll


continue to be there to answer questions and provide guidance. To this end, we recently


launched a program called Google Web Creators to provide tools, guidance and inspiration


for people who make awesome content for the web. You can get started by visiting stories.google


for resources, best practices and inspiration. Also, if you want a crash course to learn


the ins and outs of web storytelling, check out our educational YouTube series Storytime


with a new episode arriving every week. Now I'm going to pass it over to Wei Hong, the


design lead for Web Stories to walk you through some new interactive components to make your


stories even better. Thanks Ryan. Now let's go over the new capabilities


that we added to help you create beautiful stories. Our team has had a lot of exciting


launch moments in the past year. Now we want to focus on how Web Stories are getting even


better with a new set of highly interactive features. As Ryan called out at the beginning


of this session, it was a challenging year for everyone. We built makeshift home offices,


spent countless hours on video chat and tried to balance our work life with our home life.


So we partnered with Sean Doan, who is an amazing 3D artist, and then built a demo Web


Story together to showcase the ups and downs of working from home with all the newest Web


Story features. The best way to understand just how rich and immersive stories can be


is to check out the experience on your phone. Please feel free to follow along and get Home


Warrior story on your phone by either scanning the QR code or type in the URL. One of the


cool things you will see is the rich support for 360 media. As shown in this demo, the


reader steps into a pretty cool loft apartment and is prompted to search for the cat. A reader


can move their phone left and right and explore the room using the phone's gyroscope sensor.


The full screen 360 media consisting of videos and images provide a truly immersive and interactive


experience to your audience. There are endless opportunities to use this feature in fashion,


travel, gaming, and so much more. Please check out the documentation link on screen for more


implementation details. By the way, I never did find that cat. I hope you will. Up next,


interactivity. In the demo story, the reader is prompted to pick an outfit on that day


for the character. The demo story here is using a binary pool that gives a reader real-time


breakdown on what option was the most popular. In this example here, of course, I'll pick


the casual style over formal. This smart feature displays loading percentages and an emoji


confetti animation after the reader makes a selection. This is a fun way to keep your


reader engaged. Using a pool at the right moment of your story is a great way to create


a connection between you and your audience. You can level up from a pool with a quiz.


Chrisses serves a much different purpose from a storytelling perspective. Polls tend to


gather more open feedback while chrisses provide a guessing experience with two to four options


and one of which is correct. As the example here, the chrisses asks what will be a good


indoor temperature to help save energy during summer. After the reader makes a selection,


it displays the voting percentages and the correct choice will be highlighted in green


and red if it's incorrect. To add a little more fun, you can also add an emoji confetti


effect to celebrate the reader's victory. Now, let's talk about the design flexibility.


This interactive components are designed to give you rich control over look and feel while


ensuring consistency of user experience and interaction. The format provides three main


UI themes, light, dark, and transparent, but allows you to customize fine details with


CSS or quickly choose between simple levels like shadows. Even better, you can stitch


together an engaging story by using multiple pages of polls and chrisses. If you type in


a demo URL or scan a QR code, you can take a phone poll to find out what animal you are.


This use case has endless possibilities to set up different questions on various pages.


The backend will aggregate results from polls on all the different pages and lead the readers


to the relevant result page based on their selections. You as a creator can create customized


result pages based on the reader's choice and offer unique experiences with each of


your audiences. Now, let's move on and test out your art knowledge. Because the chrisses


calculate correct and incorrect results from each component, you can set the final result


pages to show different levels based on the reader's accuracy. Please try out art chriss


story here by accessing the QR code or URL. Now, we want to share with you this fantastic


Web Story DevTools. As many of you know, it can be challenging to develop content in a


portrait-based aspect ratio and make it look great across all devices. So we made testing


easier by creating a tool that shows you the major design breakpoints. Simply add hashtag


development equal one to the end of any Web Story URL to access the Web Story DevTools.


With the support of DevTools, you can check your story against a variety of devices and


platforms. You can also check for valid AMP documents inside the tool and access a curated


list of resources to get started with Web Stories. Please always use the DevTools to


ensure the design responsiveness and present the best of your design to all readers who


access your story URL from various environments. If you are a developer interested in stories,


there's no need to wait for the latest features to arrive in visual editors. You can always


code stories manually using basic HTML and CSS. Plus diving into the code allows you


to create templatized stories generated from a content pipeline in ways that many visual


editors cannot support. We invite you to contribute to the open Web Story format and help us fill


in the gaps, file bugs, and work with us together on the future roadmap. You can learn more


by visiting amp.dev.stories or visit stories.google.


Before we close, we'd like to thank you for attending this section today. We're able to


innovate because of the support we get from you, our web creator community, the continued


growth we have seen is made possible because of many amazing partnerships. To end, here's


the list of resources and our social handles so you can stay connected. We can't wait to


Google I/O 2021, information retrieval, and more!

Welcome, everyone, to another episode of the Search Off


the Record podcast.


Our plan for this series is to talk


a bit about what's happening at Google Search,


how things work behind the scenes,


and who knows, maybe have some fun along the way.


My name is John Mueller.


I am a search advocate on the Search Relations team


here at Google in Switzerland.


And I am joined for this episode, again,


by Martin and Gary, who are both also on the Search Relations


team.


Hi, everyone.


Hey, John.


I hope everyone found that pretty cool.


But it's, I don't know, it feels like something


where maybe we should have a little bit more presence.


Or what do you think, Martin, Gary?


Should search be more visible at IO?


I don't think.


Interesting.


Yeah, I think it's tricky.


On one hand, it is kind of my mission


to make developers more aware of search and implications


that their decisions and their work has on search.


On the other hand, it is not a traditional developer product.


Google Cloud, for instance, is very specifically aimed


like the entire user base of Google Cloud


is people who make software.


So it is developers and obviously ops people


who keep things running.


Or TensorFlow, that is by definition a developer product.


It enables developers to build stuff


that leverages machine learning and artificial intelligence.


Whereas search is aimed at the end user.


And to get the most out of it, you


need to understand the business side of things,


the marketing side of things.


You need to understand usability and user experience.


You need to also understand development and technology.


But it's just one facet.


And to be honest, if we at search do our job really well,


there isn't that much that you need to worry about.


So I don't know how or what would people expect.


What do you think would people get out of more search at IO?


I mean, you can always have topics


that are developer focused, right?


So I'm not a big fan of IO in general for reasons.


But you could have topics for developers, search developers.


Say, indexing API, for example, that could be one thing.


And I think it was publicized at IO at one point.


What you were doing a couple of years ago with Zoe,


I think, someone, a software engineer working


on rendering service.


And you both did a great job explaining how rendering works


and how JavaScript contributes to breaking the web.


So.


What?


Breaking the web?


What do you mean?


Sorry, Freudian slip.


I meant how to make JavaScript work in search.


Right.


Nice safe.


Yeah.


I think, I mean, it's awkward to say.


But I mean, IO is over.


So I can probably say this now.


One of the things I noticed briefly before IO,


when looking up my talk on what's new in search,


I don't know.


I was just wondering if I could find this on Google, actually.


And it turns out I couldn't find it on Google


because most of the IO site was actually not indexable


by Google.


It was not rendered.


JavaScript.


It was JavaScript, wasn't it?


I didn't look at the details.


It might have been something else.


I think it was JavaScript.


You think, ha.


Ha.


Yeah.


I mean, it's like one of those things where on the one hand,


I always feel like, well, we've talked about JavaScript


and SEO for such a long time.


It's like, we don't need to talk about it anymore.


It's like, it just works.


And developers just know what to do, right?


But at the same time, you see this happening


with a site that is so closely associated with Google.


And then it's like, well.


But it shows the reality.


And I got cured from the, oh, this is obvious.


I don't need to talk about this disease.


When we ran the Web Almanac Test 2020 or 2019,


and we found like 12% of the landing pages


that we had in the crawl for the Web Almanac


did have links that were not proper links.


And I'm like, oh, god.


This should be obvious enough to not be represented


in a two-digit percentage.


But yeah, here we are.


And it just goes to show that, yeah, sure, we are Google.


Yes, we are big.


But making the event website for IO


is not really our core business.


And then the people who do this and make this happen


are smart and clever and do fantastic things.


But they might not necessarily keep an eye on all the aspects.


Because making a good, successful website


is actually keeping a lot of ducks in a row.


And that's not necessarily easy.


And things go wrong.


And that's why there will continue to be a need to educate


and to actually keep yourself updated on what's happening.


And a couple of years back, it might


have been some crawling issues.


Before that, it might have been some robots.txt issues.


And now it's apparently JavaScript


that is new enough and unwieldy enough


to allow you to do things that are not great.


It's not great, it's really not great.


You're right on that.


It's JavaScript, yeah.


It's not a grape.


So should we be doing more search sessions at IO?


Maybe.


I mean, I would love to hear from the community what they


would love to hear and see at IO.


I mean, we have done a bunch of Q&A and show and tell.


And as Gary said, when there was a big change


in how we do rendering, we presented that.


Zoe Clifford and I were on stage,


on a big stage for this particular thing.


I know that in 2018, when I joined the team, Maria,


Moeva, and you were also presenting


on JavaScript and search.


So we have done this in the past whenever there was something


big to talk about.


And I think this year has been lots of small, important


changes, not necessarily on the developer side of things.


Cool.


Yeah.


I mean, it's also still something in Lighthouse


as well.


So if you're using Chrome developer tools


and you use Lighthouse to test your pages,


you probably would be able to see this too.


So yeah.


That brings me to the next thing.


We definitely need to clarify.


There's still a lot of people running around there saying,


oh, Google page experience update


will use Lighthouse and PageSpeed Insights to measure


things, which is not true.


So the tools are great, but you need


to understand what they are, what they do,


and they're not being used in the page experience thing.


We should probably have more sessions at IOH next year.


We should have more sessions.


OK.


Maybe we should include some kind of basic JavaScript SEO


tests in the Core Web Vitals as well.


That seems to be something everyone's talking about.


I don't know.


Oh my god.


So Martin had a valid point in the beginning about search


figuring out things on its own.


And that's the other group.


So historically at Google, there were two bigger groups.


One that was like, we will figure it out,


and we don't have to deal with web spam and blah, blah, blah.


And Google will just understand everything.


And then there was the other group


who was like, no, we have to talk to people


and explain to them how things work,


because otherwise it will take us eons to get there.


And I think they are both right in their own sense.


And there are things that we can figure out,


but then there are also other things


that we cannot figure out.


For example, I imagine that eventually we


can figure out the JavaScript links at one


point in the future and make use of them in ranking


and other places where we need them.


Or it might happen that we are not


going to need structured data anymore,


because we get so OK with understanding structure


in an otherwise unstructured web.


But we are not there.


So until then, we just have to talk about things.


And after that, we can stop talking and go away and go


to, I don't know, Tenerife and just hang out


there drinking margaritas.


JOHN MUELLER-GRANT, MD, PhD Oh, man, that would be so fantastic.


I don't know.


It'll be awesome when we can finally travel a little bit


more and see other countries.


Yeah, I guess another thing that we could do


is try to figure out if we could recognize failures like this


and at least alert the site owner of those kind of issues.


Is that something that you think would be realistic, Martin?


Is like if we can't render a page,


would we be able to recognize that it's because of something


weird in the JavaScript?


MARTIN SPLITT, MD, PhD The thing is define we can't render


a page.


I mean, in this case, we could render the page.


It's just that none of the content showed up.


And that can be on purpose.


That can be accidental.


But I think this is a case of it looks like thin content,


and then where do you draw the line.


And I think it's hard to detect that,


but I think we could probably do it somehow.


And it's actually worth looking into.


And I was, oh, god, this reminds me.


I had this idea that I at some day


probably will actually make happen.


It's just a lot of work, and it's


work that I'm not necessarily familiar with because I'm not


a data scientist.


But we have a lot of error logs that


were produced during rendering.


And you know you see them in the testing tools as well.


And I would like to know what are the most common problems


that we are seeing.


And I think we can actually do that.


It's just someone has to do it, which is a great way of saying


no one does it.


And I need to make that happen eventually.


JOHN MUELLER, MD, PhD Martin, what are you doing this summer?


MARTIN SPLITT, MD, PhD Oh, yeah.


Ooh, we could get an intern.


Oh.


So one thing that could be interesting,


if you want to look into it, is if rendering fails,


let's say that the navigation, for example, the loads


and footer loads and whatever, but not the centerpiece,


then that might mean something.


Like for example, if we couldn't detect centerpiece on the page,


I imagine that we would have a counter for that in indexing.


And then you could look into that


and see if that's useful in any way.


MARTIN SPLITT, MD, PhD That's actually an interesting question.


I also don't think we have ever talked much


about the centerpiece annotation.


Have we?


I mean, I mentioned it briefly in indexing podcasts.


But basically, it's the center of the page, the part


that you are actually reading or using on a page as a user.


So you're helpfully saying that the centerpiece annotation


is annotating the piece that we think


is the center of the page.


JOHN MUELLER, MD, PhD I call it the primary content.


But it's like geographically speaking,


or geometrically speaking, I don't know.


GEOFFREY SINCLAIR, MD Geometrically speaking,


maybe the center is the right place.


MARTIN SPLITT, MD, PhD I really wish we would be broadcasting


the video feed of this as well, because the look that Gary just


gave the camera when I made that previous comment was priceless.


What?


You just looked so like you didn't do anything.


OK, in that case, you just have a resting non-interested face.


So it's like, I look like that inside all the time.


It's not new.


Oh, but you're not.


You're such a nice person.


I need to visit, I think.


Hang on, I need to throw up.


No.


So what do you think?


Should we have gone to the IO folks


and fixed their website for search for them?


But it's like a Google site.


It's like, surely people will expect a Google site


to be perfect in SEO.


Well, it sucks to be them, but we still have honest results.


You are working on search, so you don't go to other teams


and say, hey, I need to fix your website,


because it's not ranking.


You can't do that.


I mean, they can.


And then they get the email response from us saying, sorry,


here's the link to the Webmaster Forum video


or public office hours.


Oh, man.


So tough.


John, we had a podcast about this.


You have to listen to it.


Oh.


Listen.


OK.


Fine.


Or watch the podcast.


Watch the podcast.


On YouTube, yeah.


Oh, yeah.


You can watch them now.


So cool.


Yeah.


I kind of like listening to stuff on YouTube


because it's easier to do higher speed settings.


I'm sure there are podcast players that do this too,


but it's just like, once I figure it out,


it's like I just keep doing the same thing.


It's so weird.


I started in the whole pandemic situation.


I started watching Star Trek because Star Trek


is that one show that all of the search people always


talked about.


And I was like, oh, we want to make a Star Trek computer.


So I started watching Star Trek, and there


are like a gazillion episodes.


So the only way that you can kind of make progress


is you have to watch them at two times speed.


And at some point, you just get used to it.


And this weekend, I was like, oh, I


will just watch Star Trek on the normal TV


to kind of get the next episode in.


And it was so tiring to watch that at normal speed.


It's like, why are they talking so slow?


I do that with audio books.


We were listening to Haruki Murakami books,


and the narrators were always very, very, very, very slow


at the normal speed.


And then we sped up to two times the normal speed.


And it was wonderful.


You could understand everything, and you could still


consume the audio book in a fast manner, I guess.


But then you started the next audio book,


and for two chapters, doesn't matter.


Like in the intro, you couldn't speed up the intro.


And you had to listen to that in the normal speed.


And it was like we were thinking about writing this book.


Yeah.


And it was just so painful.


I bet it's pretty meta if people are watching this


or listening to this and playing it at double speed itself.


I have to say, I recently had to kill 15 minutes,


and I found a documentary or an episode of some series


on YouTube that was like 12 minutes.


But then they spoke so slowly that I sped it up


to twice the speed.


And then I was angry because I then still had like nine


minutes to kill afterwards because I sped it up so much.


It's like, ah, damn.


Oh, man.


I fooled myself here.


Anyway, back to events.


So how did you find the in-person IOs?


It's like, Martin, you've been at a couple, right?


Were you at any as a developer before you joined Google?


I haven't gone before I joined Google,


but I was joining one of the IO extendeds


here in the Zurich office a couple of years back.


And I did usually check out the live stream


or at least read up on what happened.


But I have to say, the biggest value of IO


has been the last two ones that were happening in person.


One was 2018.


One was 2019 where I attended in person.


Because lots of people from the community


that I really enjoy interacting with are joining in person.


And you can just hang out.


It was so overwhelming, especially in 2019,


because we had two sessions, like presentations on stage


that we had to prep the days before.


Flying to Mountain View also means


that you're trying to meet all the teams that are there,


which is like a lot of teams.


So you have lots of meetings.


You run from one meeting to another.


Then you prepare the IO sessions.


Then you go on stage, do the sessions,


and then you hang out with people pretty much all day


long.


Basically, I met people in the morning for breakfast


in the office.


Then we went together to IO.


Then we hung out during IO.


Then more people were hanging out with me in the evenings.


And we had dinner together and stuff.


And then suddenly, the day IO ended,


everyone just went to the airport and flew off


or went on road trips to God knows where.


And the campus was deserted.


It was empty.


And I was there, and I was like, did the apocalypse happen?


And I somehow missed it because it was on,


I think it was a Friday that day.


And there was no one.


It was completely empty.


And I sat in the micro kitchen in this completely quiet


office.


And I think the light turned off at some point.


And I just had to wave so that the light would turn back on.


And I'm like, yeah.


No, you know what?


I'll grab a Google bike and cycle around the area


a little bit for a while.


And then I went on a little bike trip.


And yeah, it was bizarre.


JOHN MUELLER-GRANT, PhD I'm guessing it would be the same


if you went to the office now.


MARTIN SPLITT, PhD Probably, yeah.


Oh, man.


So what other events are lined up?


Like the in-person IO, I don't know.


Maybe we'll have something next year.


I think that would be cool.


But what else is happening?


MARTIN SPLITT, PhD Oh.


So we are actually lining up a few virtual events


later this year.


The first one coming is the Search Central Virtual


Unconference.


That's going to happen June 21.


So keep your eyes peeled for a blog post


and watch our Twitter feed because we'll


open the registration soon.


And take note, this is the unconference.


It's not a normal conference.


It's not Search Central Live.


It's the unconference this time.


So what do you mean unconference?


Is it basically like not a conference?


It's not a conference.


No.


So you know at conferences you have, on one hand,


the stage-focused sessions where you


have a speaker or multiple speakers telling


whatever they have to tell and talking about whatever


they have to talk about.


But then you, that's the audience,


are basically passively just listening to it.


And maybe you ask a few questions at the end.


An unconference tries to take what


the other thing that happens at conferences, which is the hallway


track, where people are just like meeting each other


and talking about stuff and discussing.


So it's going to be a limited.


We got lots of pushback last year for this.


But because it is a discussion-focused format,


we are going to limit the number of people


who can participate.


And we are going to choose participants carefully


in order to make sure that we have a good balance


across all sorts of different dimensions,


as in regional distribution, background,


demographic details, all that kind of stuff.


We want a good mixture.


We are probably opening up 100 to 200 spots.


And then people can propose, as Googlers and product experts


can, and GDEs, Google Developer Experts, can propose sessions.


And then these sessions are not presentations,


but discussion sessions.


So for instance, some product teams


are going to ask for input on things


that they are planning to do in the future.


So they want roadmap input.


Others will do a show and tell, where


you can show other people in the community and the product team


what you build with their product.


And yeah, so it's going to be a lot


of interactive small sessions.


They won't be recorded.


They won't be live streamed, because the discussions


themselves should just happen in this ephemeral small group.


But then the conclusions we draw from that, that we will write


up and publish afterwards.


OK, cool.


So if people want to join in, they have to be fast,


or they have to just be in the correct random set, I guess.


It's basically a lottery in the end.


But fundamentally, we will keep the sign up


open as long as we have a reasonable amount of spots


available.


So if we open 200 spots, we'll probably


allow 400, maybe 500 registrations,


which means roughly every second person gets in.


But yeah, you have to be quick and lucky.


And I'm sorry that we have to limit it,


but that's just how unconferences work.


We can't just have a reasonable discussion with 100 people.


That just doesn't work.


And we've seen that the small group size work really well.


And we are not picking based on name or profile or whatever.


We are anonymizing it or pseudonomizing it.


And then looking at the background, at the region,


at things like that rather than anything else.


The bigger problem is I really want


people to understand they are expected


to participate actively.


So if you just want to sit in and listen,


this is not the right event for you.


Then we will have a Search Central Live later this year


as well.


That's the right event for you if you just


want to listen and learn and maybe ask a few questions.


But this is really for people who want to proactively


contribute in a discussion.


OK.


So not me.


Yeah.


No.


We need you.


No, Gary.


We need you for other things, not for this.


I'm sorry.


So you won't learn the secret to number one ranking


in the unconference, I guess.


It's more about being able to share your experience of where


you've been struggling with search


and maybe on specific features or products or setups,


those kind of things.


Exactly.


So we could have a session on hreflang and have Gary there.


We could have a session on robots.txt.


Bad job.


Do you want to talk about robots.txt specification?


I guess hreflang is too easy.


It's like nobody will say they have any questions about it


or confusion.


Yeah.


That's simple.


Just do it right and it works.


Done.


I'm happy that there are a handful of people


out there who really understand it


and are willing to talk about it.


I'm thinking about Aretasolis, for example,


or Bill Hunt, who create tools for validating hreflang


and proactively talk about hreflang


and explain it to people in multiple ways


so everyone can understand the idea behind it


and how to implement it and also how to debug.


So we don't actually have to do all that much about it.


I think we reached a point where if we start talking about it,


we just add more confusion than do any good with it.


So I'm reluctant to give more talks on hreflang.


Even when we were doing in-person events,


I would rather answer questions about hreflang


rather than giving a talk about hreflang at conferences


like International Search Summit, for example,


because it felt like most people in the room, at least,


already knew what hreflang is.


So for them, giving a primer on what hreflang is


didn't make any sense.


And the very few people who were not familiar with hreflang,


for them, we gave a one-minute overview of what it is


and then let the others ask questions.


And by the end of the talk or Q&A or whatever,


even the others understood at least a big picture.


So yeah, I don't want to talk about hreflang.


JOHN MUELLER!


We'll see.


Maybe we can get Aledha to join us.


That would be cool.


She's been doing fantastic stuff.


MARTIN SPLITT!


Pretty cool, yeah.


Yeah.


I mean, she's been doing fantastic stuff


for the past decade, if not more.


Actually, probably more.


I remember recording Crawling Monday with her


in the Zurich office in 2019.


That was fun.


Which is amazing.


Like, if you ever went to one of her talks,


it's one of the most energizing things that you can go to.


It's really, really brilliant.


Cool.


All right, Gary.


What?


How are things going on the search side?


Pretty good.


Thanks for asking.


How are you currently retrieving your favorite recipes?


Well, that was mean.


I'm not retrieving my recipe.


Well, actually, I am retrieving my recipes.


They are all stored on Apple Notes.


And when I have this idea to cook something,


then I just go onto Apple Notes and just look for the thing


that I want to cook.


And it works great.


You mispronounced Google Keep twice.


I did not.


So cool.


So tell me more about how retrieval works in search then.


It's like, for recipes, of course,


you have to have a phone.


But I guess for search, it doesn't run on a phone, right?


I see.


That's where this is coming from.


OK.


I think in one of the previous episodes,


we talked about query parsing and understanding


and briefly touched on synonyms.


So for example, if you search for something like buy a car,


then that would be expanded to buy cars and purchase auto


or purchase car and so on and so on.


And then we search in our index for all those words, right?


Because it might be helpful for some people.


Now, searching the index, that's an overloaded term


because we don't actually go through our whole index


when we are looking for these words.


We have something that we covered previously, something


called posting list.


And that is essentially a map of terms


to pages or documents containing those words.


So for example, we could identify easily


that the term car appears in doc A, B, C, D, E, F, and G.


And then buy appears in, I don't know, B, C, D, E, F, G.


And technically, in the simplest form, what you want to do


is to return an intersection of the two groups.


Basically, you would return B, C, D, E, F, G


because those were the docs that contained both words.


In reality, it's not that simple.


We would return both or all the documents


to our serving system and let that


deal with documents that are not relevant enough,


let's say, to the query.


Now, relevancy is an interesting concept


because it's determined by multiple things.


One thing is that, well, one part


is rooted in the query itself, where


you could say that my original term was buy car or buy a car.


We dropped the A because it's irrelevant to the query.


So we would have buy car.


And then those would be the terms


that we are most curious about.


Those are the terms that we really, really


want in our result set.


So you could say that those terms have the highest


weight during the ranking process, during the sorting


process.


Everything that we expanded the query with,


like purchase auto, for example, that


would have a lower weight than the original term


because that's not what the user searched for.


It's just related terms to what the user searched for.


And it might be helpful, but it's not


what the user searched for.


So we are going to look for those terms as well.


But we will consider their relevance lower


than the original term's relevancy.


And in the first stage, we will retrieve all the documents


that we can.


So basically, if we have 1 billion documents that


contain the terms buy car, then in the first stage,


we would have all those billion documents collected in one


glob.


Then a sorting mechanism kicks in,


which is basically our ranking system.


And it will create a reverse sorted list


of all those billion documents and makes


a cut at roughly 1,000.


And then those 1,000 documents will be pushed up in serving.


I have no idea why I'm gesticulating here with my hands


because no one can see it.


But basically, those 1,000 documents


are pushed back up towards the user.


Here, I mentioned a little bit about ranking.


And I think that's a topic on its own for next episode.


We are not going to go there.


But once we have those 1,000 documents,


basically, we can start essentially serving them.


And they are not finished ranking.


Basically, we just created a sorted list


based on some of the signals that we have.


But we need more signals to finish ranking those 1,000


documents, basically sorting them


in the order that we believe that would be OK for the user,


essentially.


And that happens in another stage of ranking.


But at this point, we could give those results to the user.


And they probably would be OK with them already in most cases.


In our life of query classes, usually we


show this pre-sorted list.


And usually, it looks OK.


Of course, you can search for weird things.


And as we all know, there's weird things on the internet.


So sometimes, you can see very weird things


in those pre-sorted lists.


And that's why further ranking is important.


Like for example, I don't want results about pineapple pizza.


And those would be demoted very aggressively,


at least in my case.


But in the pre-sorted list, it would still


be there because ranking is not finished yet.


So this happens basically across the different kinds of indexes


that we have as well.


Or is that a different topic almost?


So in the context of this episode,


we are only talking about the web index


and not image index or video index


or whatnot because they work slightly differently.


And I never worked on them.


So I can't authoritatively talk about them, I guess.


On the web index, I actually did work.


So I know way more about it than any of the other indexes


that we have.


So one thing that kind of bubbled up in my head


as I listened to you, and it's not coffee.


Is it cookies?


Cookies.


I miss cookies, yeah.


I keep clicking on the cookie banners, but nothing happens.


It's terrible.


But anyway.


Well, they are banned.


Anyway, yeah.


So one of the things I noticed, like you


were talking about buy cars and buy automobiles


and all of these things.


Would we also consider sell this internet to buy?


In the sense that if I'm searching to buy a car,


would we say, well, we're looking


for pages that say sell car?


Yes.


You are touching on a topic that's


very interesting from information retrieval


perspective.


And I think Paul Hart covered that in his webmaster


conference talk in Mountain View.


But yes, we would consider that a low-weight synonym.


So buy and sell from information retrieval perspective


is kind of synonyms, which can also cause confusions,


of course, and hence why the weighting was introduced.


OK.


Why sell is a lower-weighted synonym than purchase,


for example.


So I wonder, from a practical point of view for websites,


is that something they should consider?


It's like, should they think, well, people


are looking to buy a car.


Therefore, my sell car page has to mention buy car.


So I don't think so.


Because if you are just creating a site for the user,


and you are loading the page with content


that is relevant for what the user can do on the page,


like purchase a car, for example,


then you wouldn't want to overload


the page with the term sell.


Because your primary target is to make the user buy


through your website a car.


And then there is a subsection of users


who would want to also sell their car.


But they are not your target audience.


Your target is to make the user buy a car.


OK.


I don't know.


I never discussed this with you.


I think this is really cool in the podcast


that we can kind of chat about this.


But I guess if you're making a page,


then about you have a car that you want to sell,


you would title it more as like, would you


like to buy my Ford, rather than I want to sell my Ford.


GARY ILLYES-SELLERSOLECKO.


I see where you're coming from.


Well, that's a marketing thing, I think.


Basically, you are asking the user two different things.


In the buy case, you are prompting the user


to buy the car from you.


And at least from a marketing perspective,


I think that makes more sense.


In the second sense, I guess, you


are just stating that you are selling your car.


And then you do whatever you want with that information.


But you are not prompting anyone to buy from you.


And as far as I remember from my marketing classes from uni


is that you have to, well, actually not marketing,


but writing classes, is to tell the person reading the content


what you want from them, if it's an instruction sort of thing.


And these things like Craiglies, for example,


they are essential instructions, basically, buy this car from me.


Versus, I'm stating that I'm selling this car.


You do whatever you want with this information.


Yeah.


Another place where I just ran into this recently


is About Me pages.


So it's something like, I don't know.


About you?


Yeah, about.


There are pages about you on the internet?


Not well.


If I have a site, like a lot of people have the website,


and you have a page linked somewhere,


it's like, who is this weird person who


wrote this blog, for example?


And one of the things I noticed, also in talking


with Jason Bernard, who's external from Google,


he's been doing a lot of really cool things,


I think, with Knowledge Graph, knowledge panels,


and trying to figure out the connections there,


is that if I have an About Me page,


and I title it About Me, then from a search point of view,


probably also from a retrieval point of view,


it's like, well, About Me.


It's like, OK, we can retrieve this document for these two


words.


But we can't really have a synonym for me,


because it's like, for this page, me is John.


But for another page, me is someone else.


So instead of titling the page About Me,


it would almost be easier to title it


about John Mueller, for example, to match what


people are actually looking for.


GARY ILLYESISIOSAKE LYNN FESCHIELSKIYO Sure.


But then it's what you want to do with that page.


Basically, if I'm on the blog, for example, on your blog,


and I'm reading about hacking FTP, for example,


and I'm midway through, and it's like, oh, this is really smart.


I wonder who wrote this.


And then I click the byline, and then I end up


on the About Me page.


I didn't reach it from search.


You just wanted to have a page for the author of,


or the main author of johnmoo.com.


Well, probably the only author of johnmoo.com.


JOHN MUELLER 1, 2, 3, 4.


Guest posts.


GARY ILLYESISIOSAKE LYNN FESCHIELSKIYO But then in search,


you didn't actually care about having that in the results.


The one thing that you cared about was to have a place where


you explain who you are and why you are.


Yeah.


I guess that depends on how I expect


people to reach that page.


GARY ILLYESISIOSAKE LYNN FESCHIELSKIYO Yeah.


I mean, that's a marketing thing.


And if people are searching for, who


is this weird John Mueller person?


Is he the guy who runs a barbecue in Texas?


GARY ILLYESISIOSAKE LYNN FESCHIELSKIYO Right.


And that's exactly my point.


You have to decide what you want with that page, what


the purpose of that page should be.


If it should be something that funnels users to the site,


then yeah, you have to come up with something better


than About Me, because there are many me out there.


Many me's.


There are also many me's.


It's almost like all of this technical computer science,


information retrieval stuff kind of


aligns with the search best practices


that we've been telling people.


No.


What?


So awesome.


OK, what a coincidence, huh?


Who would have thought?


I mean, basically the best practices


thing that's like an abstraction from information retrieval.


Basically, people are transforming information


retrieval into something that is appropriate for larger


audience, I guess.


There's nothing all that special about it, in my opinion.


It's just saying the same thing differently.


Yeah.


Cool.


I don't know.


Sometimes I get a bit nervous when


I see SEOs go off and do all of these information retrieval


courses, because I'm like, oh, maybe they


will recognize that there's a trick around all


of these things.


And usually they come back and say, well, it's like,


you should just make good websites


and think about your users, what they're searching for.


I love kind of seeing that circle close.


I mean, you've been working on search for like 13 years


or whatever.


And you've been sharing lots of information


that the outside doesn't have.


And at this point, I've been with Google for almost 11


years.


And I know that there isn't all that much trick in search.


Like, we are not trying to trick anyone


into making better whatever.


What we are trying to do is helping the search user.


And for that, we are telling people how search works


and how you can make sites that will be


beneficial and useful for users.


There's not that much trickery going on, really,


except when I tweet in your name.


JOHN MUELLER-GROVE-MARTIN LEEUWENFELD


Oh, geez.


Geez.


GARY ILLYESANDER-CHAVEZ HUANG


Mm-hmm.


OK.


This is why we're working at home.


It's like, you don't have to worry about leaving


your laptop unlocked.


But now Gary is probably like, how can I go and visit John


when he's not paying attention?


Whew.


Cool.


Well, I thought this was really insightful.


I thought this was cool to chat about all of these topics.


No, it was good.


It was good.


I'm agreeing.


I'm sorry.


It didn't sound like agreeing.


Plus, agreeing is kind of out of character for you.


So I guess that's why we were confused, Gary.


OK.


Anyway, it's been fun having these podcast episodes


together.


And I hope you, the listener, have


been enjoying them as well.


At any rate, let us know how you're liking these,


if there are any topics that we could be including


in any of our future episodes, or any maybe other people


from the team that we should be including.


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


And thank you.


Until next time, bye, everyone.


MARTIN SPLITT AND GARY ILLYESANDER-CHAVEZ HUANG


Bye.


Riesztof Hallastra.


Google Search and JavaScript Sites (Google I/O'19)

It's great that we have you all here


and that you all gathered today to learn more


about JavaScript and search.


And the coolest thing is today I have


the pleasure of not just being the only one presenting this,


but I have Zoe with me who is working on the rendering team.


So she is, yes, she's the one from the team that made


the new Googlebot happen.


So please, like, cheer and give another round of applause.


Oh, well, it was a team effort, Martin.


Thank you.


And it's great to be here.


Martin, I know you've done some work around JavaScript


and search.


I'd love to discuss with you if you have some time.


Actually, I have like 40 minutes until I


have to do the next thing.


So let's talk a bit about it.


But before, I would like to go into something else.


You know, I talk to SEOs and I talk to developers


all around the world.


And it's great to do that.


But I keep getting the sentiment, especially from SEOs,


that JavaScript is like the worst thing ever.


And it's the new Flash.


And it's evil.


And you can't have a successful website


if you're using JavaScript.


So.


Oh, oh my gosh, Martin.


That sounds a little bit extreme.


I think both developers and SEOs should work together


to make sure their web content works well.


JavaScript is a tool.


And it can be used to make great websites.


But every tool can be used incorrectly and do harm.


That is absolutely true.


And I think that's such an important point to drive home.


I mean, it is an essential part of the web.


It is what enables so many new capabilities on the web.


At the same time, if you use it incorrectly


or if you overuse it, that's a very, very bad thing.


And I mean, we see that with things like this.


You see the graph from HTTP Archive.


We see that the amount of JavaScript


that we are shipping to users loading our pages


is growing and growing and growing over the years.


So what I'm wondering is, with JavaScript


being an essential part and a good tool if used right,


but JavaScript being so much in use,


how does Google Search deal with that?


Well, we keep improving Google Search for JavaScript sites.


At the same time, we make sure we keep crawling and indexing


efficiently.


That sounds very nice and airy.


But do you have any examples for that?


Oh, yes.


OK.


So let's start with the big news.


You know Googlebot used to render pages with the engine


from Chrome 41, right?


Yes, the number one question I got and the number one question


I asked you over and over again.


It was like, hi, Zoe, long time no see.


So Googlebot update, no Chrome?


So we're getting this update?


Yes.


Actually, we already got the update a couple days ago.


Woo!


So this means we haven't just updated it


and we will start crawling your sites with it.


We are already doing that.


Yes, that's correct.


So I somehow nearly missed the announcement on Tuesday.


That was a little weird.


But I think this is fantastic and this is amazing.


And just to make sure to get that absolutely right,


this is the latest stable Chrome rendering engine.


Absolutely.


Cool.


So that is good news.


But what I'm wondering is, what does that mean for me


as a web developer?


Well, it gives you access to over 1,000 new features


that is now available to Googlebot when rendering pages.


That's really, really cool.


I mean, that's not 1,000.


But if you look around, you'll see


that there's tons of new stuff.


So that's great.


So we have a modern web rendering service in Googlebot.


That's lovely.


But I have another question.


Do you know what my next question is going to be like?


Oh, your next question?


Are you wondering if we'll get like four years out of date


again?


Yeah.


So when do we get the next update?


Actually, we'll update the render engine regularly.


So we'll be more or less around the same as desktop Chrome,


give or take a few weeks.


A few weeks?


Something like that.


We're not making any promises, but that's the idea.


A few weeks.


That's amazing.


I love that.


That's really big news.


All right.


OK.


Let me get that straight.


So modern JavaScript is no longer a blocker for SEO.


Absolutely.


Yes.


And what kind of new features are these?


Well, you can use pretty much any modern JavaScript feature,


including let, const, a whole bunch of new array methods,


and so on and so forth.


Right.


But that's JavaScript language features.


What about new APIs?


Yes, many of those are available too,


like Intersection Observer.


I hope for that one.


So that's fantastic news.


And that probably also means if we have more of the APIs


available in the browser, that I don't need as many polyfills


as I used to.


You should still consider providing polyfills


for older browsers.


But if you have a polyfill that exists purely


for Googlebot compatibility, you can remove them.


Yes.


So I think one of these examples would be,


I know that one of the JavaScript frameworks


shipped polyfill for array.fill as an optional thing


for Googlebot.


We can, like, fill that.


That is amazing.


You know, that's great.


And these ongoing updates will probably also


mean that we update the user agent eventually, right?


Eventually, we'll update the user agent string


to reflect the version of Chrome that we're running.


That's cool.


So right now, we are telling people


41 because we don't want to break


sites that have it pre-coded, hard-coded.


But we'll do that update eventually.


That's great.


That's amazing.


So what else will the future hold?


Speaking of the future.


What else will the future hold?


We're going to update the testing tools too.


We didn't get around to updating many of them yet.


But look forward to that in the coming months for them


to run Chrome as well.


Right.


So unfortunately, that means, so we


wanted to make sure that we get you this upgrade as quickly


as possible.


But that means that you might have some rockiness on the way.


But look at it from a different perspective.


This means that if the testing tools we provide you


with, like mobile-friendly tests and the URL inspection tool,


if they say it's fine, it will definitely be fine.


If you get JavaScript errors, you still


have a chance to actually make it into indexing.


But you have to double check things.


And I think that's OK.


You're working on that?


Yeah, we're working on it.


Sorry for the glitches in the meanwhile.


Things like that happen.


I mean, there was a huge update.


You worked on this for years.


And now we finally have it.


And I think it's great that you give this to developers


and SEOs out there.


You can now run modern JavaScript and Googlebot.


And I think that's the real update to focus on here.


And with all that said, I don't think this is a silver bullet.


What I'm wondering is, I, as someone who's building websites,


should I look at something else?


Can I do something to help everyone on the web?


Why, yes, Martin.


You should keep your users in mind.


Fair point.


That's a good point.


And look, this example page, it has quite a bit of loading time.


It takes a while for the cat pictures to load.


Yeah, I mean, come on.


It's lots of cat pictures.


And I guess, like, for cats, you can wait a little bit?


Yeah, but maybe we can do a little better.


The browser streams the HTML as it arrives.


But there isn't much that can be displayed right away.


We got some script tags, but the body is empty.


And the browser won't discover and display the cat images


until JavaScript has been downloaded, parsed,


and executed.


Right, right.


So what you're saying is, sure, I load a lot of images,


but it could be so much faster.


And the browser gives me the capability


to do that faster for free.


And I'm breaking that.


Yeah, and it may hurt your users.


Isn't there some way to use your JavaScript framework


to produce HTML and ship that to the browser up front?


Good question.


And the answer is yes.


But that brings us into this whole new world


of web app architecture.


So I think we need to talk a little bit about terminology.


So I think the first thing that you want to probably look at


is universal JavaScript.


Universal JavaScript?


That's the same thing as isomorphic JavaScript, right?


Yes.


Because we don't have enough terms,


we have to invent new ones.


So it's like universal JavaScript,


server-side renderable JavaScript,


and isomorphic JavaScript.


But it's pretty much the same thing.


Cool.


And that's just JavaScript code that


can run either on the server or in the browser, right?


Yes, absolutely.


It's kind of nice.


So like, JavaScript itself is a pretty agnostic language.


But there's features that only work in the browser.


And then there's features that only work on the server.


And you want to make sure that you use the subset that


works on both sides.


And that enables us to do server-side rendering.


Ah, yes.


Server-side rendering.


Like the olden PHP days.


When the server gets a request, run some code,


and generates the HTML that is sent to the browser.


Exactly.


Except that we are not running PHP.


I mean, you can.


But we are talking about running the JavaScript


from your framework code, basically, on the server side


and generating that.


And what else is there?


So server-side rendering has a few, well,


not necessarily drawbacks, but a few characteristics


that you want to not forget about.


So one thing is it doesn't really


like give you the quickest response, because you


have to run it every request.


So you can also do pre-rendering instead.


Pre-rendering.


That happens when you make changes, like at build time


or on deployment, right?


Absolutely.


So basically, instead of doing it on every request,


you're only running the JavaScript


until you know that the content has actually changed.


And that's useful if your content


doesn't change that often.


So it could be useful on stuff like landing pages, blogs,


and so forth.


Oh, absolutely.


I mean, those are fantastic candidates for pre-rendering.


Because when you have a blog and you


know this content isn't going to change until I make an update,


until I publish a new post or edit an existing post,


that you can run the pre-rendering at that point


and just be a static website the rest of the time.


Oh, cool.


And by the way, I think I heard another term at some point.


I think it was hydration.


What's that?


So hydration is the thing that every human


should do properly.


You should drink enough and keep yourself hydrated.


But in this case, actually, it means something else.


It's a variation of server-side rendering.


Because what we discussed so far,


pre-rendering or server-side rendering, the pure version,


just generates static HTML sites.


Yeah.


And just generating static HTML wouldn't


be quite what I want if I'm building an awesome single page


web app.


That's the thing.


If you build a highly interactive app,


you want this interactivity to still be there,


while the initial content should also already be rendered.


So basically, yeah, that is what hydration is about.


I see.


So it sends the HTML to the browser


and then upgrades it in the browser


once the JavaScript is downloaded, parsed,


and executed.


Exactly.


So that gives you this nice dynamic nature of the website,


even if you have the initial content in HTML already.


And let's look at how that would look like in a project.


So for instance, if I'm using React,


I can use something like React Snap.


It starts with my home page and then crawls all the links


it finds and then generates static HTML for that.


But that's pre-rendering.


And unfortunately, if you have a regular React application,


what you might want to do if you want to hydrate stuff


to swell on top of it, that means


that you also need to do some changes to your code.


So again, this is the main application code.


You have to make this change that if you


see that the root element has already some child nodes,


then that means that we actually are


in the pre-rendered HTML in the browser


and then the app hydrates.


But if it doesn't have anything in there yet,


then we are on the server.


And then we need to basically run this


to generate the initial HTML.


And is there some other way to do this with React?


Yes, especially if you start a project from scratch


and have no old legacy code base,


then I highly recommend taking a look at Next.js, for instance.


I mean, it does require some changes,


but it is definitely worth it.


But I don't want to rewrite everything.


OK, that's a fair point.


So the thing is, when I said Next.js,


Next.js is like a higher level framework in the sense of it


uses your React components, but it gives you


helpers for server-side rendering and hydration as


well.


I see, I see.


So right, this is that.


But you might use other frameworks, right, Zoe?


What is your favorite framework?


Oh, oh, my favorite.


I just say.


My favorite framework's JavaScript, Martin.


OK, well, yeah, vanilla JavaScript,


that's a fair point, I think.


But if you would be using other frameworks,


like Vue.js, for instance, you actually have options as well.


You have three options for Vue.js.


And the first one is the Vue.js server renderer,


and that gives you SSR plus hydration.


That's kind of cool, you know.


And that.


But you still have to rewrite a lot of your code, right?


Yeah, well, you still have to have universal code


in your Vue application.


So, hmm, that's unfortunate.


But, well, if you don't want to do that,


there is another option.


I think the second option is called the pre-render SPA


plugin.


I like that because I want to be in a spa sometimes.


Now it's like SPA plugin.


So it basically pre-renders your page,


like we saw in React Snap, but it doesn't give you hydration.


So this only gives you pre-rendering and not


the benefits of hydration.


So what if I start a new Vue project?


So similar to what we said about React,


there's the thing that you should


look into if you're starting a new Vue project.


And I think the thing that I would recommend you look at


is Nuxt.js.


Nuxt.js is inspired by Nuxt.js.


Surprise!


The name is one letter difference.


It does pretty much the same thing as Nuxt.js for React,


but it does this specifically for Vue.


But it says pre-rendering right there as well.


OK, yeah, you caught me.


So it does SSR and hydration, but it


comes with a command line interface that you can install.


And then you can say, OK, this page, and this page,


and this page, I actually want to pre-render as well.


So you get to mix and match a little bit.


I see.


So you can choose one or the other.


And what does the server-side code look like?


Well, the server-side code depends a little bit.


But let's say we use Express.js, which


is a pretty popular Node.js server-side code


framework or library.


The first step is you create the Vue server renderer


if you would be using the Vue server render option.


I see that it creates a renderer with an HTML template.


What's all that for?


So the HTML template allows you to have the site-wide data,


like the general HTML structure.


And basically, just the Vue application that runs just


gives you the content inside that template.


And does this template allow interpolation


of page-specific data, like the title or metasnippet?


Title and metasnippet, yes.


So in the next step, whenever a request comes in,


because we are now not pre-rendering,


but we are doing the access as R plus hydration,


when the request comes in, we can


specify the page-specific data.


And that gets replaced in the template as well.


I see.


So that will produce a string of the template HTML


together with the HTML generated from Vue.js, I guess.


Correct, exactly.


And once we have this HTML in the string,


we can give it to the browser.


And that's what it's about, really.


Nice.


And that works with your Vue.js components?


It does, unless they're not written


in Universal JavaScript.


So you would still have to make sure that your JavaScript also


runs on the server.


You see a theme is evolving here, right?


By Universal JavaScript.


So we still have to make edits to make sure our code is


Universal JavaScript.


But what about Angular?


How does it work?


So for Angular, it's pretty much a similar story.


The project is called Angular Universal,


and it does SSR plus hydration as well.


It comes with a bunch of stuff.


So if you use Express.js, for instance,


it comes with this ngExpress engine that you can use.


And you pass in the App Server module ngFactory,


which is a really easy thing to say.


And yeah.


So that ngExpress engine runs our Angular app code


on the server and generates the HTML we can serve, right?


Yeah.


It's part of the Angular Universal.


All the hydration code and that kind of stuff


piles on top of it.


And you have to make some code adjustments.


But basically, you get SSR and hydration for Angular that way.


And it's pretty well supported.


But again, without Universal JavaScript,


that's not a good thing.


That was a lot to take in.


Is there somewhere to learn more about all this stuff?


Funny that you ask, because we happen


to have made this YouTube video series that's


called JavaScript SEO.


If you haven't checked that out, go to youtube.com


slash googlewebmasters, subscribe to the channel,


and check out the JavaScript SEO playlist as well.


Cool.


Now, we have been talking quite a lot about dynamic, sorry,


server-side rendering, server-side rendering, hydration,


and prerendering.


But last year at IO, I remember that John actually said


something about dynamic rendering.


So I think that dynamic rendering was this thing


that you can use to prerender, but only do that


for bottom crawlers and SEO.


So does that now mean that we have the new Googlebot,


after all?


Does that mean that we can ditch that and it's going away?


Well, we want site owners to focus on the user experience


and content quality.


For the time being, dynamic rendering may be useful,


but it's not a long-term strategy.


Ah, right.


But like, hmm.


So what would be use cases for dynamic rendering then?


First and foremost, it's a workaround.


Unfortunately, not all crawlers and bots


support JavaScript right now.


Right, like the social media crawlers, most of them


don't run it, and some other search engines


don't do that well as well.


Right, OK, gotcha.


Right.


But I think it could also be a stepping stone.


It's a workaround, but it can be a stepping stone


towards improving your website, because server-side rendering


and hydration, that's a bunch of work that you have to do,


right?


Yes, yes.


But remember that server-side rendering and hydration


bring the great benefits to your users,


while dynamic rendering, not so much.


Right, and that's because dynamic rendering basically


only improves your HTML content coverage that basically


is in the first stream that goes to the browser only for bots,


not for users.


So users still get the slower site if they are unlucky.


Yeah, that's correct.


So consider dynamic rendering a workaround


until other bots have caught up or you have upgraded


your website to server-side rendering or server-side


rendering plus hydration.


I think that makes sense, yeah.


Phew.


That was a lot to take in, wasn't it?


That was like so much stuff in so little time,


but I think it actually gives you all a foundation


to build from.


And I think that's a very, very important thing to do,


isn't it?


Do you like what you just got?


Yes, but wait, there's more.


So Zoe, why have I caught you on stage?


I was wondering, now that I build sites and consider SEO,


can I also test what I'm building


and if it's actually working properly?


Oh, good question.


Let's take a look at a few tools.


OK, fair enough.


A great first stop is Lighthouse.


It's right in your Chrome DevTools.


Come on, I know that one.


It has the performance audits, it has best practices,


it has accessibility, but what does that have to do with SEO?


Well, it's also got some SEO audits as well,


and they help you improve your website's discoverability


and make your users happier.


Let's run the audit, and there we go.


Here are your results.


This is not looking good.


I mean, whoops.


OK.


Yeah, 44 points, but no worries.


Many of these are low-hanging issues and easy to fix.


The best candidates are probably the title and meta description.


Right, yes, because if you use JavaScript frameworks,


you often forget about these.


And it's not always quite obvious


how to make this happen in JavaScript frameworks.


So let's look at React, for instance.


React is a great framework, and if you use React Helmet,


it's even better because you can do all these things.


My React Helmet, Martin, I'm building a website,


not going on a bicycle tour.


What's that React Helmet for?


You should go on a bicycle tour.


It's quite nice weather outside.


But similar to a bike helmet that might not look fantastic


but is really helpful, it protects you


from not looking great in the, I mean,


bike helmets oftentimes don't make you look great,


but they make things work out for you.


So it's similar to React Helmet.


React Helmet allows us to add to our template


and basically use any props in our component


to set the title and the meta description


to something that is specific to the page.


Let's say I have a product detail page, right?


I could take the product name and put it in the title


and then some description for the product


into the meta description.


That's going to look fantastic in search results.


Great, great.


So this works for React, but what about other frameworks?


Right, OK, so the other frameworks,


Angular, for instance, has it built in.


They're called the title and meta service.


And they do the exact same thing.


Got it.


So here we have the same thing.


We take the title and the meta description


and put something that is in our component into them


to show what's on the page exactly.


And now that's Angular and React.


You might be asking next, what is about Vue.js?


Vue.js has an extension called Vue-meta.


Gives you this additional method in your components


called the meta info, and it does the same thing.


And so that's it?


Oh, actually, for Vue.js, you want


to make sure if you use the Vue router to switch to history


API mode.


History mode?


What's that for?


So it defaults to the fallback mode, which uses hash URLs.


And hash URLs aren't exactly great for crawling.


I see.


So maybe only the home page would be indexed.


Yeah, because we're not really crawling this fragment URLs,


right?


We said that last year in the IOTalk as well.


So that's no good.


Speaking of no good, Martin, Googlebot


only sees the placeholder images on your website.


Wait, hang on.


That's weird.


It works in my browser.


So why does it not work here?


We have a fresh Googlebot and everything?


Yeah, yeah.


Well, do you maybe use lazy loading images?


I actually do.


And I do that.


This is the code.


So this should be fine, right?


I mean, whenever you scroll, I figure out


if the image is within the viewport.


And if that is, then I load the actual image.


So that should be good.


Well, Googlebot does support lazy loading.


But keep in mind, it may interact with the page


differently from your users.


In your case, Googlebot doesn't scroll.


So the scroll handler isn't triggered.


And the lazy loading contents aren't loaded.


Right.


But I guess what I should be doing


is I should use something else, like IntersectionObserver


maybe?


Yes, you could use an IntersectionObserver.


This is an API that triggers a callback whenever any observed


element becomes visible.


It's more flexible and more robust.


So I can use the same code to still load my images.


But now it's more robust thanks to IntersectionObserver.


And that's supported in modern Googlebot.


That's amazing.


Yes, it is.


So I wonder, can I also use the new native lazy loading


that Chrome's getting?


Absolutely.


It's still an experimental feature.


But worst case scenario, it gets ignored.


So feel free.


Ah, so that's pretty cool.


Because it's just this additional thing.


We just ignore it.


And it just works.


OK, that's cool.


That's nice.


So you can't run, which is nice.


So I can ask you another question, I guess.


Is it OK if I ask you another question?


Oh, yeah.


Go ahead.


So I was using Search Console earlier today.


And I noticed that we have this weird thing called


soft 404s.


Sorry, not soft 404s.


We have this issue where my pages,


I basically update my website.


And then they get like, you know,


crawled but not really, discovered but not crawled yet.


So that's the one that I'm having struggles with.


What does it mean to be discovered but not crawled yet?


Oh, it means Googlebot hasn't indexed your page yet.


Perhaps your site's crawl budget is too low for those pages


to be indexed.


What's crawl budget?


Well, crawl budget is a rate limit


on how frequently Google can crawl the site.


Oh, could you go back a slide?


Oh, sorry.


Right, let's stay here for a moment.


So it's how much Google crawls my site.


Yeah, yeah.


And we do this to be a good web citizen


and avoid knocking over web servers


with too many concurrent requests.


OK.


Is there something else that I should know about crawl budget?


Well, crawl budget also applies to resources


loaded from the page during rendering.


What do you mean by resources?


For example, JavaScript files loaded from script tags or XHR


or fetch requests triggered by JavaScript.


Those count against my crawl budget?


Yeah.


All right.


OK, so I need to make sure that I'm not making


too many requests, I guess.


But one more thing, Martin.


One more thing.


We don't have forever to perform a render.


And staying within the crawl budget


can be tricky sometimes.


To help with this, we cache certain sub-resources


across renders.


So that means that if I have multiple pages


and they all use the same libraries or the same code,


you don't fetch it over and over and over again?


Correct.


Googlebot might just fetch it once and then reuse it.


OK, that's pretty nice.


So what do you do if my site has an infinite loop?


Is it OK?


Is it going to be indexing what it's got so far?


Yeah, yeah.


If your site has an infinite loop, then at some point,


we'll cut off the JavaScript and cut off


any fetching that might still be going on


and return the contents that we have up to that point.


Oh, that's pretty cool.


So that's nice.


Is there something else that I should know?


Yes, yes.


Did you know that we put URLs we discover into a queue


and crawl, render, and index them separately?


It's not like Googlebot is clicking on links


and going from page to page.


Damn it.


That means that the render queue is still a thing.


We haven't removed that even with a new update yet, right?


OK, right.


But what if I use, let's say, I might


have a website that requires you to set a cookie,


and only if the cookie is set after the second time,


we actually show you the content.


Would that work?


No, that would not work.


Googlebot does not store cookies across requests.


So it always sees the page like a signed out user would.


Right, OK, so it doesn't do that with cookies.


But what about the other ways to persist data across page loads?


Would you use local storage, session storage, or index DB?


These APIs are available.


But like cookies, they don't persist data between renders.


So they're basically only available


within a single render pass.


All right, so that means I can't persist data across.


OK, right, fair enough.


But what about other things like service worker or cache API?


Well, currently, we don't support the service worker API.


But if we did, every render would start with no service


workers installed.


Oh, right, because basically, someone


coming from search results is pretty much a first time user.


So we can't rely on that.


That makes sense.


I think that makes sense.


So in that case, whenever I use some feature on the web,


I need to feature detect if it actually is present.


Ah, yes, feature detection is a great idea.


Progressive enhancement is a good strategy


where different users might be on devices


or use browsers with varying capabilities.


But you should make sure and also handle


the not so happy path.


Oh, wait.


So what you mean here is error handling, right?


Yeah.


I need to make sure that my code does that properly.


So let's say there's something like this right here.


The idea here would be that I have localized content.


So I check if geolocation exists.


If not, I just load the fallback content.


I think that's fine, right?


And then when it exists, I just use the current position


to load the localized content.


Is that fine?


Or what happens if there's a mistake?


Well, imagine the getCurrentPosition function


throws an error or an exception.


Then your web page's contents would not be shown to Googlebot.


Oh.


Because the geolocation feature is available,


but an error happens.


Yes, this can and does happen to Googlebot.


I've seen it more than once.


OK.


When?


What kind of APIs could be affected?


For example, I think this is in another slide, but web sockets.


Web sockets, all right, but also things


that require permissions, like mobile microphone, webcam.


What do we do with these things?


We deny all permissions.


OK, I think that makes sense.


After all, what would the webcam picture


look like for Googlebot, like a server room or something?


That would be weird.


So I think to fix this, what I could do


is I could basically just have an error fallback that also


loads the fallback content.


Yes, and making sure you treat these error conditions


appropriately is important.


You don't want to leave the mistake of leaving Googlebot


or users without contents.


Yeah, that would be a mistake.


Oh, by the way, you're going to love this,


because this keeps happening to me.


I noticed something in our performance report


in Search Console.


So we have the support page, and it is great,


but it keeps losing impressions and clicks on the search


results, so this is not exactly great.


But I don't understand what's happening here,


because our code is perfectly fine.


The site is on Google.


It's indexed, and all the content is there when I test it.


But there's something weird going on,


because we figured out that it's not actually


fetching the data from the API, but we're not sure why.


Well, would you mind showing me the code, Martin?


I mean, we are amongst us, so sure, here we go.


So our support bot basically opens a WebSocket connection


and then uses the connect event to show


like a bunch of initial FAQ data and then give you


a welcome message, and then it starts handling the chat code.


This is what I mentioned earlier,


and what I was worried about when you said your requests


don't show up.


We don't allow WebSocket connections in Googlebot


for architectural reasons.


Oh, OK.


So that explains why we're not seeing the data.


I guess making that static content


and maybe even use the new FAQ structured data


is probably a good idea.


Right.


That makes sense.


So I have one more question.


I have some time for that.


Yes, we have a few minutes left.


We have a few minutes left.


So basically, I noticed that we have this soft 404 problem,


and I'm not so sure what that means.


Oh, a soft 404 means you gave us a 200 HTTP OK.


But the contents look like an error page.


OK, yes.


That does happen in my single page application


because my server doesn't actually


know all the different routes and products


that we are serving.


So what we do is we give you the index HTML,


and then the JavaScript runs and figures out


if that thing actually exists.


And if not, it shows an error, but we can't change the HTTP


code anymore.


So what would I do in this kind of case?


Well, you've got a couple of ways out of this situation.


You can either redirect to a URL that


returns a 404 from the server, or alternatively, you


can use the meta robots tag with no index.


Ah, but why do I even have to care about that kind of stuff?


Like, can't you just catch it for me?


Well, HTTP status codes, Martin, they're kind of important.


They tell Googlebot how to interpret the response we get.


You know, you tell crawlers and user browsers,


this is a good URL.


Here's some content, and all is good.


I mean, that sounds good so far.


But in the case of a soft 404, you tell us this is fine,


and then turn around and give us something that says otherwise.


It's a bit backstabby.


That doesn't sound good.


Oh, and it's not good, Martin.


HTTP status is give crawlers and users valuable information.


OK.


OK, so in that case, can you like elaborate


on that a little bit more?


Oh, all day.


So for example, if you remove a page and give us a 404 status,


we will remove the page from the index


after a short while if it's not coming back online.


Duh, I guess that makes perfect sense.


And that's how it's supposed to be.


But let's say this content wasn't removed.


It has just moved to a new URL instead.


We wouldn't know that.


OK, that's fair, because I guess if we just remove it,


then you have to rediscover it from scratch.


And then you wouldn't know that there's a new thing somewhere


else, right?


That's right.


And that's why using 301 to indicate a redirect


is a much better idea.


OK, so I got this.


But I actually have an idea for you.


So hold this.


Like this is, oh my god.


I have a fantastic solution to the soft 404 problem.


So how about this?


I basically just add a no index to all my pages, right?


So the Googlebot doesn't care.


But then once I know that the cat that I'm loading actually


exists, I change that to please index me.


That solves the problem, right?


Oh, well, that might not end well.


Why?


Look, we see a no index early on.


So we could stop the process right there


and not take the removal through JavaScript into account.


And all your pages would be marked as no index in that case.


So that would remove all my website from the index.


That's a terrible idea.


I understand that now.


Thank you very much for preventing that from happening.


OK, right.


Looking at the time, we don't want to hold you all too long.


So I think it's time to summarize this a little bit.


I mean, we have been talking about a bunch of edge cases.


But luckily, all of those things are edge cases, right?


As long as you follow the best practices


and do the right things as a web developer and an SEO,


you should pretty much be safe, right?


Right, right.


And I think it's important to mention


that we're continuously working to improve things as well,


like the new Chromium headless, the Chromium in indexing.


It's good stuff.


Yes.


And also, so that's the big one, really.


But also, it's quite cool that we


discuss server-side rendering and server-side rendering


with hydration and pre-rendering,


because that can also improve the user's experience


of your site, not just the SEO side of things.


Yeah, hydration.


Also, we talked a little bit about something else.


Network testing.


Yeah, testing plus one.


So it's basically test early, test often.


Absolutely.


You don't want any bad surprises.


Bad surprises are bad.


Is there anywhere to find out more about this stuff, Martin?


Indeed, that's a very good question.


So again, we have a YouTube channel with lots of content.


We also do biweekly office hours if we


want to hang out with us online and ask us questions.


That's a great idea to do that as well.


And don't forget the docs.


Oh, right.


We keep adding new docs all the time.


Yes, that's true.


And I think the thing that we both of us


would love to take away from the session for you guys,


this is the main point here, is we


don't want you to worry too much on building stuff


for search engines.


We want you to build great user experiences on the web.


Yes.


Our goal is to empower you to build great discoverable web


apps and websites.


That's why the new Googlebot is such a big leap forward.


It is an amazing thing.


And we will continue to improve Googlebot and generally


Google Search with new features and capabilities.


So please, please, please continue


to make fantastic content for your users


and blow everyone away that comes to your website.


And with that being said, I would


like to say thank you so much for coming to the chat.


Woo!


You did it.


You're very welcome, Martin.


It's been a great pleasure having you.


And thank you all, audience.


Thank you so much for being here.


If you have any questions, we'll be around.


You can ask us questions.


Follow us on Twitter.


Check out our YouTube videos.


Thanks.


Titles, Snippets and Result Previews (WMConf MTV '19)

So my name's Feroz Parakh, and I'm going to be talking about


titles, snippets, and result previews.


My general area of focus is core ranking in search.


But the last few years, I was asked to look into this area


about result previews.


And there's a pretty good reason for it.


If you think about it, on a search page, one of the large


tasks that a user has is to find the content they want,


find the page they want to get to.


And in the world of 10 Blue Links, this was the only


information they had, literally, was a title and a


snippet and perhaps the URL.


So part of what we did was we sort of rethought what would


be the important pillars for an effort


around result previews.


So primary to our goal, of course, is relevance to the


user need.


We certainly cannot have previews not be relevant to


the user query.


Our second goal would be to make sure that whatever


preview we generated actually helped users make a choice.


We wouldn't just generate previews absent


mind of that.


A third one would be we would want to illuminate the depth


of content within websites.


I personally believe that there's a ton of content out


there written by wonderful people out


there, like yourself.


And it's important for users to understand that there is a


lot of relevant information within sites.


And if they don't know that information is within that


site, they're unlikely to visit it.


So this is a large pillar.


And the final one was this notion of diversity.


There is a ton of different kind of content out there.


It goes from imagery to videos to forums to lists to tables.


I mean, it's sort of boundless, I think, in terms


of human imagination.


And so we needed to catch up.


And we need to be able to express the diversity of the


content that was out there in the ecosystem.


And our sort of sense was if we did this, then people would


benefit, users would benefit.


And then consequently, the ecosystem would benefit.


So here's what we had to work with.


We had to work with something called attribution, which is


the source of the site, the name of the site, the title


itself for the URL, and then this sort of abstract notion


of a content preview with its character


limits and size limits.


So the next few slides, I'm going to talk through some of


the newer formats that we sort of have built out.


These are all algorithmic, driven by


those original pillars.


But as you'll see, they're actually


quite useful for users.


We were putting a lot of effort.


It's not that the previews themselves were just built


without effort.


Here's an example of us attempting to change the


snippet in response to the query.


The very same algorithm that decides that a page is


relevant for a query can be used to decide what part of


the page should be relevant for the user if


they were to choose it.


So if you change the query, you can expect your snippet


to change, and you can expect the user to read that to


understand if that page indeed is relevant for them or not.


But we can do more than that.


So an example, one of the things we discovered, I think


it was around 2016, 2017, was that images really help users


choose between different results.


There's often this latent desire.


I want to see a particular type of image.


I want to see a particular type of flower.


Or I'm looking for a particular type of shoe.


And the image suddenly becomes exceedingly relevant for them.


So we can algorithmically extract relevant images from


the page and show them.


The placement's on the right.


This is important because you want the image to be secondary


to the main source of information, which is the


title in the snippet.


Occasionally, we can extract galleries.


This is when the content of the page cannot be rendered by


a single image.


Rather, the user would benefit if they saw a sense of this


kind of content, the kind of imagery on the page.


And we make sure not to use all the images.


There's limits on what fraction is used.


And as a consequence, we noticed that users actually


would start visiting a greater diversity of sites.


So this was sort of a very strong sense.


In a strong sense, this helped us understand that this can


benefit the ecosystem.


Following images, the obvious thing to do is then look at


videos, and you can understand similarly that you're going to


look for relevant videos.


There could be multiple videos on the page, but you're going


to look for the relevant one.


And you can sort of mutate your preview type depending on


whether the video is the dominant content on the page.


And you'll see this notion in subsequent previews, too, or


whether it is only supportive and therefore on the right.


If you wanted to express the depth of content within sites,


then within that height limit of ours, the only information


we have is this ability to generate


what are called site links.


And these are links to pages within your site that we


believe are relevant for the user.


So if you're looking at a restaurant, then clearly


contact drinks, private events, finding tables.


These are all links that can be very useful for users.


These are all extracted algorithmically.


Occasionally, the site structure does help us, and it


drives traffic into your site.


Site link images was another change we added when we


realized that if their page had image previews, then it


should be simple for us to, again, algorithmically decide


whether the site links could have images.


And this actually helped in cases where the site links


don't really help the user disambiguate the type of


content that's on your site.


We could go further.


We went down this path of entity facts.


This is when, if you can imagine, as in the bottom


right, if you're, in this case, I think, Killen Jornet


is a wrestler.


And there are facts around this wrestler that are


pertinent to the user.


Entity facts are a way for us to illuminate some of those


facts so that people can then say, oh, this site is pretty


legitimate.


It does explain facts about this user, and therefore it's


deep, and therefore I'm willing to go to this site.


Similarly, forums.


I think Alan had talked about structured markup to help us


understand forums.


But there are tons of forums, Q&A sites, there are tons of


forums out there that don't have structured markup on


them, and it's a big disservice to users if we're


not able to help people understand that this is a


forum and help people understand what kind of


content's out there.


So algorithmically, we can extract posts subject to our


ability to do so.


We choose the forum cluster.


There's a set of related content on the site that might


be related to the query for the user.


We certainly see users engaging with this a lot.


And we know that if you're going to provide us with


markup, then we certainly want to use that.


And so markup always takes priority over these


algorithmic forums.


We can do the same thing with tables and lists.


So if your site has a dominant table and we want to show the


preview for that page, then clearly showing that table to


some extent is a better thing for the user, because they can


understand this is really what the content is on this page.


And the structure and the position of that HTML does


guide the preview.


So in summary, relevance infuses everything.


If these previews have to be relevant to the user, they


have to be relevant for the query.


Attribution helps the user choose the source.


We make a lot of effort to ensure that the depth of your


content is well expressed and therefore a user is invited to


visit your site.


And you can see that both with site links and forums.


And we make sure that we have a diversity of preview formats


to support the ecosystem.


JavaScript: SEO Mythbusting

Coming from a developer background,


JavaScript: SEO Mythbusting

there's so many misconceptions and myths about SEO


JavaScript: SEO Mythbusting

that developers come up with or have heard


JavaScript: SEO Mythbusting

or that come from the SEO world as well.


JavaScript: SEO Mythbusting

Where do these come from?


JavaScript: SEO Mythbusting

How do these get into the world?


JavaScript: SEO Mythbusting

The myths, the legends that come through about JavaScript.


JavaScript: SEO Mythbusting

I think a lot of it is people with very good intentions


JavaScript: SEO Mythbusting

will try to provide the information they


JavaScript: SEO Mythbusting

have available.


JavaScript: SEO Mythbusting

And there's a gap in translation between the SEOs


JavaScript: SEO Mythbusting

and the developers and how they think and what they consider.


JavaScript: SEO Mythbusting

So by going ahead and adopting acceptance criteria


JavaScript: SEO Mythbusting

as part of my tickets when I work with devs,


JavaScript: SEO Mythbusting

that lets them know very specifically,


JavaScript: SEO Mythbusting

instead of being like, and I want you to make magic for me.


JavaScript: SEO Mythbusting

And when you go from give me magic to, hey,


JavaScript: SEO Mythbusting

here's my user story.


JavaScript: SEO Mythbusting

I would like to accomplish three pieces for acceptance criteria.


JavaScript: SEO Mythbusting

You can bridge a gap.


JavaScript: SEO Mythbusting


JavaScript: SEO Mythbusting

Hello, and welcome to another episode of SEO Mythbusting.


JavaScript: SEO Mythbusting

With me today is Jamie Alberico.


JavaScript: SEO Mythbusting

Jamie, what do you do in your job exactly?


JavaScript: SEO Mythbusting

Thank you so much for having me here.


JavaScript: SEO Mythbusting

I'm a technical SEO with Aero Electronics.


JavaScript: SEO Mythbusting

And that means that I am embedded with a number of dead


JavaScript: SEO Mythbusting

teams across a number of projects.


JavaScript: SEO Mythbusting

We try to execute these initiatives,


JavaScript: SEO Mythbusting

get new features available on the site


JavaScript: SEO Mythbusting

in an effective and search-friendly way.


JavaScript: SEO Mythbusting

And that means a lot of times, we


JavaScript: SEO Mythbusting

have to have conversations about how


JavaScript: SEO Mythbusting

we're using our JavaScript.


JavaScript: SEO Mythbusting

Having you here is fantastic, because then we


JavaScript: SEO Mythbusting

can have a conversation about pretty much everything


JavaScript: SEO Mythbusting

that you want to know from the search side,


JavaScript: SEO Mythbusting

as well as the web developer side.


JavaScript: SEO Mythbusting

So any questions that you have in mind, anything


JavaScript: SEO Mythbusting

that pops into your mind?


JavaScript: SEO Mythbusting

Oh, so many questions.


JavaScript: SEO Mythbusting

I get to poke at the black box of Google here.


JavaScript: SEO Mythbusting

And I have one that's absolutely burning.


JavaScript: SEO Mythbusting

Is JavaScript the devil?


JavaScript: SEO Mythbusting


JavaScript: SEO Mythbusting

That's a fantastic question.


JavaScript: SEO Mythbusting

It might seem that way sometimes,


JavaScript: SEO Mythbusting

especially when things are not going the way you want it.


JavaScript: SEO Mythbusting

You see the horror stories.


JavaScript: SEO Mythbusting

They're on forums.


JavaScript: SEO Mythbusting

They're on Twitter.


JavaScript: SEO Mythbusting

Everything is gone.


JavaScript: SEO Mythbusting

Yeah, that's one thing.


JavaScript: SEO Mythbusting

The SEO side on the developer side


JavaScript: SEO Mythbusting

is also like, oh, it's a language that wasn't designed


JavaScript: SEO Mythbusting

to be super resilient.


JavaScript: SEO Mythbusting

But it actually is.


JavaScript: SEO Mythbusting

And then a lot of people are, oh, it's a C-type language.


JavaScript: SEO Mythbusting

And it's not really.


JavaScript: SEO Mythbusting

It's a LISP-type language.


JavaScript: SEO Mythbusting

So a lot of misconceptions coming from both worlds


JavaScript: SEO Mythbusting

together and clashing here.


JavaScript: SEO Mythbusting

I don't think it is the devil.


JavaScript: SEO Mythbusting

I think it has its benefits.


JavaScript: SEO Mythbusting

I mean, it allows us to build really cool and fantastic stuff


JavaScript: SEO Mythbusting

on the web and be really responsive to what


JavaScript: SEO Mythbusting

the user does and wants to do with our applications.


JavaScript: SEO Mythbusting

And it has moved the web from being a document platform


JavaScript: SEO Mythbusting

towards an application platform.


JavaScript: SEO Mythbusting

And I think that's fantastic.


JavaScript: SEO Mythbusting

So I think we are already pushing hard


JavaScript: SEO Mythbusting

on fighting this JavaScript is the devil.


JavaScript: SEO Mythbusting

And if you use JavaScript, you can't be in Next at all.


JavaScript: SEO Mythbusting

So that's not true for a long time.


JavaScript: SEO Mythbusting

But I think now the documentation


JavaScript: SEO Mythbusting

is catching up with outlining the different bits and pieces


JavaScript: SEO Mythbusting

that you should be aware of and the features


JavaScript: SEO Mythbusting

that you have to deal with that are not available.


JavaScript: SEO Mythbusting

One thing, for instance, is you probably


JavaScript: SEO Mythbusting

have built single-page applications, right?


JavaScript: SEO Mythbusting

Oh, yes.


JavaScript: SEO Mythbusting

Has there been problems in terms of SEO when they rolled out?


JavaScript: SEO Mythbusting

I was pretty lucky.


JavaScript: SEO Mythbusting

I had a dev team who believed in SEO.