where it's partially indexed in both places


English Google SEO office-hours from March 19, 2021

and we can't properly index it in either location.


That's something I would try to avoid.


But if you're trying to recognize users,


and I don't know how you would do that, maybe by IP addresses


or by cookies or whatever, and you're


sending those who have certain attributes over


to your new site, then at some point


that will include Googlebot as well.


And then at that point, we would see the site move.


So that's something where probably,


depending on how you have that set up,


we would see that move all happening at once.


And I think that's generally the optimal approach there.


I think with a site move that you're


doing step by step like this or as an experimental site move,


I would expect to see fluctuations happening there.


Because it gets very complicated when suddenly users


start linking to a new version of a site,


and that new version of the site is not something


that we've seen before.


Then suddenly we have both of these indexed.


So that's something where I would assume,


from an SEO point of view, you will see issues


until all of this has settled down.


And it will take longer than a normal site move


where you just say, on day x, we move everything over


to the new site.


And sometimes you just have to follow along with that


and say, well, the marketing team wants to do it gradually


or for policy reasons or whatever reasons we have to do


it like this.


But purely from an SEO point of view,


I would try to do this at one point


and kind of move the site over completely.


If you want to do A-B testing with the UI,


with text and things like that, you


can still do that either on the old version


or on the new version.


But I would try to avoid putting a site move into an A-B test.


Mobile-first.


You previously noticed that m-dot sites


could have issues when moved over to mobile-first indexing.


Is this still the case?


Then is it only a problem for Google


if the annotations for Google's documentation are not in place?


So the annotations are important that we


can recognize the mobile and the desktop versions.


So that's always important for us.


That's less of a topic with regards to mobile-first indexing


but more that we can show the right URLs to users


in the search results.


You can also help us with that by setting up redirects.


So if mobile users go to the desktop page,


then redirect them to the mobile page.


Desktop users go to the mobile page,


redirect them to the desktop page.


That's another way you can help us with that.


Usually, the issues that we see with these kind of sites


are not around the annotations but more around the content


that you show.


So if the m-dot version has less content,


then that would be a case where if we switch over


to mobile-first indexing, we would have less content.


So that's usually where those issues would come from.


So from a practical point of view,


I think the content side, you can probably test.


You can try out individually.


There are also some testing tools


that give you a little bit of information there.


And based on that, that's something


where I would think about, is there something


that you need to do, or do you just kind of wait it out


and let Google switch everything over?


How can I tell Googlebot that it should


stop using my cookie disclaimer as a description to a page


and instead use the description I added to the meta tag?


It's an Angular site with server-side rendering


and the server-side rendering version.


I omitted the cookie pop-up, but it still


gets used as a description.


So my guess, so I think the last part of the question


is kind of one aspect that you definitely


need to watch out for.


If you think you're serving Googlebot the content


without this cookie disclaimer and Google is still


using the cookie disclaimer in the description,


then probably that serving side is not working the way


that you expect it.


So probably there is a bug somewhere on your side


that you're serving Googlebot the cookie pop-up anyway.


In general, though, serving Googlebot a cookie banner,


something like that, is not a bad thing,


as long as the actual content is still in the HTML.


So if you're showing something like a cookie pop-up or cookie


banner on top of your normal HTML,


then that should work perfectly fine.


If you're serving this cookie banner instead


of your normal HTML, so if you have an interstitial,


you're redirecting somewhere else,


or you're only loading the full content after a user has gone


through this interstitial, then that


would be a problem for search.


And you can test that in Search Console using the Inspect URL


tool.


And there you can look at the HTML that is returned,


and you can search for some pieces of text


that you know you have on your site,


and we should be able to find that.


So I think that's kind of a critical point there.


Most of the cookie consent layers that we've seen


seem to work really well with search.


And I assume they're also testing this on their side,


that they actually work for this.


So that seems like something where maybe you're


doing something unique with your cookie banner, cookie pop-up


that you could be doing differently.


The other thing there is you could also


use a separate JavaScript file that


is blocked by robots.txt with the cookie banner.


From our point of view, that would also be fine.


And if it's a separate JavaScript file that's


blocked by robots.txt, we wouldn't


be able to process the cookie banner,


and we would just see the site without that.


So maybe that's an option.


I don't know.


Sometimes there are also policy requirements


in play which make this a lot harder.


So with cookie banners, it's kind of easier.


But if you have other legal consent requirements,


such as age interstitials, or maybe you


need to block individual countries,


then that makes it a lot harder with regards to search.


And then it gets really complicated and tricky.


But cookie banners should be something


that should be doable so that we can index these pages properly.


Cool.


Wow.


We still have a ton of questions left and so many raised hands


as well.


But I think I need to pause the recording for now


so that we have a reasonably length of a video.


I'll be around a bit longer.


So if any of you want to stick around longer and ask


more questions, feel free to do that.


But otherwise, thanks so much for all


of the submitted questions.


Thanks so much for all of the live questions as well so far.


And I hope if you're watching this as a video,


this was insightful and useful for you.


And maybe you'll join us in one of the future Hangouts as well.


So thanks a lot.


The state of web search engine optimization | Search Central Lightning Talks

I'm Alea De Solis, SEO consultant and founder at O'Reilly.


I was kindly invited by the Search Relations team


to host this Search Central Lightning Talk,


to present the 2020 Web Almanac SEO chapter,


as I had the wonderful opportunity to alter it


with the amazing Jamie Indigo and Mai Kim.


The Web Almanac is a comprehensive report


on the state of the web backed by real data.


It comprises 22 chapters spawning aspects


from page content to user experience, including SEO.


The goal of the Web Almanac SEO chapter


is to identify and assess main elements and configurations


that played a role in a website-organized


search optimization.


The Web Almanac analysis in 2020 was based on 7.5 million


websites from the August 2020 datasets of the HTTP archive,


taking into consideration both raw and render HTML elements.


It also included data from Lighthouse


and the UX Chrome report.


It's important to note that in the case of the HTTP archive


and a Lighthouse, the data is limited to the website


home pages only, not site-wide crawls.


Let's go through some of the most important SEO findings,


starting with the web page.


Here are some of the most important SEO findings,


starting with the crawlability


and indexability-related configurations.


In 2019, 72.16% of mobile sites had a valid robots.txt


versus 75% in 2020.


Meta robot stacks were found in 28% of desktop


and mobile pages.


Interestingly, rendering changed the meta robot stacks


in 0.16% of pages.


While this percentage is not high,


there is no enduring issue with using JavaScript


to add a meta robot stack to a page


or change its content either.


SEO should be careful with this.


Why?


Because if a page loads with a noindex directive


in the meta robot stacks before rendering,


Google search and potentially other search engines


won't run the JavaScript that changed the tag value


or index the page.


In the 2019 chapter, it was identified that 48.3%


of mobile pages were using a canonical tag.


In 2020, the number of mobile pages featuring


a canonical tag has grown to 53.6%.


45% of mobile pages canonical tag was self-referential


and 8.5% were pointing to a different URL


as the canonical ones.


52% of desktop pages were found to be featuring


a canonical tag in 2020,


with 48% being self-referential


and 4% pointing to a different URL.


It's understandable that there's a higher share


of mobile pages canonicalized because of those sites


using an independent mobile configuration.


However, the 4% canonicalized desktop pages


could be considered a bit too high


if we think that these are home pages


which are not self-canonicalizing.


When analyzing the canonical tags implemented


in the raw HTML versus those relying


on client-side render of JavaScript,


we identified that 0.7% of the mobile pages


and 0.5% of the desktop ones include a canonical tag


in the render but not in the raw HTML.


This means that there's only a very small number of pages


that are relying on JavaScript to implement canonical tags.


In 0.93% of the mobile pages and 0.76% of the desktop ones,


we saw canonical tags implemented


via both the raw and the render HTML.


With a conflict happening between the URLs specified


in the raw versus the render HTML of the same pages,


this can generate indexability issues


as mixed information is sent to search engines


about which is the canonical URL for the same page.


A similar conflict can be found


with the different implementation methods


with 0.15% of the mobile pages


and 0.17% of the desktop ones showing conflicts


between the canonical tags implemented


via their HTTP headers and the HTML head.


What about the content optimization status?


In 2020, the median desktop page was found to have 402 words


and the mobile page 348 words.


While in 2019, the median desktop page had 346 words


and the median mobile page had slightly lower count


at 306 words.


This represents 16.2% and 13.7% growth respectively.


It's important to note how more content


is not necessarily better.


And what is important is to satisfy user search needs


with comprehensive information that is helpful.


If you want to learn more about this topic,


I highly recommend you to watch Lily Rae's conversation


with Martin Splitz in the Is More Content Better episode


of SEO Mythbusting.


We found that the median desktop site


features 12% more words when rendered


than it does on its raw HTML.


We also found that the median mobile page site


displayed 13% less content than its desktop counterpart.


The median mobile site also displays 11.5% more words


when rendered than its raw HTML counterpart.


This might not necessarily be a problem.


However, even if Google, as well as other search engines


are continually improving in their capacity


to render and index JavaScript content,


some sites will be missing out on opportunities


to improve their organic search visibility


through a stronger focus on ensuring their content


is always available and indexable.


When analyzing the usage of the title tag,


we found that 99% of desktop and mobile pages


are featuring one.


This represents a slight improvement since 2019,


when 97% of mobile pages had a title tag.


The median page features a title that is six words long,


with no difference in the word count


between mobile and desktop context.


The median page title character count


is 38 characters on both mobile and desktop.


Interestingly, this is up from 20 characters on desktop


and 21 characters on mobile from the 2019 analysis.


When analyzing the uses of meta descriptions,


we found that 68.6% of desktop pages


and 68.2% of mobile pages have one.


Although this might be surprisingly low,


it's a slight improvement from 2019,


when only 64% of mobile pages had a meta description.


The median length of the meta description is 19 words.


The only disparity in word count


takes place on the 19th percentile,


where the desktop content has one more word than mobile.


The median character count for the meta description


is 138 characters on desktop


and 136 characters on mobile pages,


which is under the 160 characters


that is usually shared as a guideline or reference


in SEO best practices.


Let's see if things have also improved with links.


The median desktop page includes 76 links,


while the median mobile page has 67.


The median page has 61 internal links,


going to pages within the same site on desktop


and 54 on mobile.


This is down 12.8% and 10% respectively


from the 2019 analysis.


And might be suggesting that sites are not maximizing


in the ability to improve the crawlability


and link equity flow through their pages


in the way that they did the year before.


The median page is linking to external sites


seven times on desktop and six times on mobile.


This is a decrease from 2019,


when it was found that the median number of external links


per page were 10 on desktop and eight on mobile.


This decrease in external links could suggest


that websites are now being more careful


when linking to other sites,


whether to avoid passing link popularity


or to avoid referring users to them.


There is a disparity between the links


of mobile and desktop pages


that will negatively impact site


as Google becomes more committed to mobile only indexing,


rather than use mobile first one.


This is illustrated in the 62 links on mobile


versus the 68 links on desktop for the median webpage.


28.6% of pages include well-known follow attributes


on desktop and 30.7% on mobile.


However, rel.ggc and rel.sponsor adoption is quite low


with less than 0.3% of pages having IDA.


Since these attributes don't add any more value


to publishers than the rel.knowfollow,


it is reasonable to expect that the rate of adoption


will continue to be slow.


However, it is important to mention


that these attributes add semantic information


that Google can use.


So it's advisable to make use of them.


The link discoverability for major JavaScript frameworks


used for single page applications


increased thematically compared to 2019.


By testing mobile navigation links for hash URLs,


we saw minus 53% of instances of uncrawlable links


from sites using React,


minus 58% fewer from UGS-powered sites


and minus 91% reduction from Angular single page applications.


What's the status of structured data?


As part of our examination,


we took a look at the incidence rates


of different type of structured markup.


JSON-LD has become the preferred format.


It appears on 29.8% of mobile pages


and 30.6% of desktop ones.


38.6% of the pages and 39.3% of mobile pages


feature JSON-LD or micro-format structured data


in the raw HTML,


while 40.1% of desktop and mobile pages


feature structured data in the render DOM.


When reviewing this in more detail,


we found that 1.5% of desktop pages


and 1.8% of mobile pages


only feature this type of structured data in the render DOM


due to JavaScript transformations


relying on search engines' JavaScript execution capabilities.


4.5% of desktop pages and 4.6% of mobile pages,


feature structured data that appears in the raw HTML


and is subsequently changed by JavaScript transformation


in the render DOM.


Depending on the type of changes


applied to the structured data configuration,


this will generate mixed signals for change engines


when rendering them.


Also, despite the fact that the reviews


are not supposed to be associated with home pages,


the data indicates that aggregate ratings


is used on 23.9% on mobile and 23.7% on desktop.


It's also interesting to see the growth


of the video object structured data,


the usage of it grew 30.11% on desktop


and 27.7% on mobile.


The growth of this object is a general indication


of the increased adoption of structured data.


There's also an indication of what Google gave visibility


within search features increases


the incidence rates of lesser-used objects.


Google announced that FAQ page How To and QA page objects


as search visibility opportunities in 2019,


and they sustained significant year-over-year growth.


FAQ page markup grew 3,261% on desktop


and 3,000% of mobile.


How To markup grew 605% on desktop


and 623% on mobile.


QA page grew 167% on desktop and 192% on mobile.


It's important to note that this data


might not necessarily be representative


of their actual level of growth


since these objects are usually placed on internal pages.


Are websites ready for the page experience update?


When analyzing Core Web Vitals,


desktop continues to be the more performant platform


for users despite more users on mobile devices.


33.1% of websites score good Core Web Vitals for desktop


and only 20% of their mobile counterparts


pass the Core Web Vitals assessment.


From a security perspective,


77.4% of desktop pages and 73.2% of mobile pages


have adopted HTTPS.


This is up 10.4% from 2019.


It is important to note that browsers


have become more aggressively pushing HTTPS


by signaling that pages are insecure


when you visit them without HTTPS.


Also, HTTPS is currently a requirement


to capitalize on higher performing protocols such as HTTP2.


All these things have likely contributed


to the higher adoption rate year over year.


From a mobile friendliness perspective,


43% of mobile pages and 42% of desktop ones too


have a viewport meta tag with the right configuration.


However, 11% of mobile pages and 16.2% of desktop ones


are not including the tag at all,


suggesting that they might not


necessarily be mobile friendly yet.


We found that 80.3% of desktop pages


and 83% of the mobile ones are using


either the height, width, or aspect ratio CSS configurations,


meaning that a high percentage of pages


have responsive features.


On the other hand,


desktop websites that have separate mobile versions


are recommended to link to them


using the rel alternate tag in their head of the HTMLs.


Only 0.64% of the analyzed desktop pages


were found to be including this tag


with the specified media value.


It's so much data.


As you can see, some areas have improved,


but others not so much.


Let's wrap up.


Consistent with what was found and concluded in 2019,


most sites have callable and indexable


desktop and mobile pages


and are making use of the fundamental


SEO-related configurations.


It's important to highlight how the link discoverability


for major JavaScript frameworks


used for single-page applications


increased them automatically compared to 2019.


Additionally, we also identified


that there has been a slight improvement


from 2019 findings across many of the analyzed areas.


For example, robots.txt.


In 2019, 72.2% of mobile pages had a robots.txt


that was valid versus 75% in 2020.


Canonical tags.


In 2019, we identified that 48% of mobile pages


were using a canonical tag versus 54% in 2020.


Structured data.


Despite the fact that reviews are not supposed


to be associated with home pages,


the data indicates that aggregate ratings


is up 24% on mobile and desktop home pages.


HTTPS usage.


77.4% of desktop pages and 73% of mobile pages


have adopted HTTPS.


This is up 10.4% from 2019.


However, not everything has improved over the last year.


The media and desktop page include 61 internal links


while the media and mobile page has 54.


This is down 13 and 10% respectively from 2019.


Also, 5.6% of desktop pages contain no internal links


as well as 6% of mobile home pages.


Despite the growing use of mobile devices


and Google moved to a mobile-first index,


the following findings could negatively affect.


As Google completes its migration to a mobile-first index


in March, 2021, 10.8% of mobile pages


and 16.2% of desktop ones are not including


the viewport tag at all,


suggesting that they are not yet mobile-friendly.


Non-trivial disparities were found


across mobile and desktop pages,


like the one between mobile and desktop links,


illustrated in the 62 links on mobile


versus the 68 links on desktop for the media and webpage.


33.1% of desktop pages score good Core Web Vitals


while only 20% of their mobile counterparts


passed the Core Web Vitals assessment,


suggesting that desktop continues


to be the more performant platform for users.


Disparities were also found across render


and on render HTML.


The media mobile page displays 11.5% more words


when rendered than its raw HTML,


indicating a reliance on client-side JavaScript


to show content.


These findings suggest that search engines


are continually evolving in their capacity


to effectively crawl, index, and rank websites,


and some of the most important SEO configurations


are now also better taken into consideration.


However, many sites across the web


are still missing out on important search visibility


and growth opportunities,


which also shows the persisting need


of SEO evangelization and best practices adoptions


across organization.


Thank you very much for your attention.


I hope these findings help you to prioritize


your organic search optimization efforts in this year.


As you could see, the web needs SEO.


If you have any questions or comments,


please don't hesitate to leave them here.


Thank you very much.


Bye-bye.


Web Stories, Search and sheep launches, and more! | Search Off the Record podcast

Hi, everyone, and welcome to this episode of the Search


Off the Record podcast.


Our plan 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'm a search advocate here at Google in Switzerland


on the Search Relations team.


I'm joined here today by Martin and Gary, also


Gwen, Dia.


And we have a special guest today, Pascal.


Pascal, do you want to introduce yourself briefly?


Hey, John.


Thanks for having me.


So yeah, my name is Pascal Burchler.


I'm also based in Switzerland, and I work at Google


and the CMS relations team.


My focus there is on CMSs like WordPress and technologies


like AMP and Web Stories.


Oh, cool.


It's so cool to have you on the podcast, Pascal.


That's really, really awesome.


And also for those who don't know you


and don't know our office setup, where would you


be sitting in the office?


You are in which building?


Where you are?


Where you're hanging out?


Are you hanging out with the cool kids?


Well, I'm hanging out with you all in the office.


So if you consider yourself to be the cool kids, then yes.


So no.


OK, that's very fine.


Oh, I love how Gary does not like this response.


Anyway, so you said that you were working with WordPress


and that you are doing AMP and Web Stories.


What part do you like the best?


What's the most interesting you think?


I like how we are combining all these things.


So we started with bringing AMP to WordPress


with the official AMP plugin for WordPress.


And now we're bringing Web Stories to WordPress


using a visual editor and Web Stories that are also powered


by AMP under the hood.


That's damn cool.


Why did we pick WordPress?


Why not Drupal or Blogger?


How did we end up using WordPress?


Is it just that people love WordPress?


Or what's the deal?


I think it started because WordPress


has a huge market share in the CMS space


for self-hosted CMSs.


And we have lots of WordPress experience already on the team.


And that's how we started working with AMP and Web


Stories in WordPress.


So cool.


I mean, it feels like something where if we can help improve


WordPress, then that's something that could help a lot of sites,


right?


Makes it easier.


Absolutely, yeah.


That doesn't mean, of course, that we're not working


with other CMS platforms as well.


We also contribute to, let's say, Drupal or Joomla.


So yeah.


Cool, cool.


So I know that I am missing the office.


How about you?


Do you miss the office?


I certainly miss seeing you all in the office


because we don't usually work together.


Aw.


So that is our usual interaction in the office.


It's just so different now with working from home.


So I really appreciate being here.


We appreciate you being here.


And I definitely do miss our shared coffees


on the roof terrace.


That's for sure.


And the horse.


Don't forget the horse.


And Spock.


Spock.


Last time I was in the office, the horse


didn't look really well.


Yeah, it has a headache.


You could say so, yes.


And it was wearing a mask, I think.


What the heck are you talking about?


Gary, you should take a rotation day just to see the office.


It's a bit of a different.


I don't want to go out.


I'm perfectly fine here in my lair.


Fair enough.


My lair.


I don't know, I think it was like it fell.


I don't know.


And as we all know, once horses fall,


it's very hard to get them back up.


Actually, Gary, would you like to continue our conversation


on indexing, because I'm wondering generally


what else is there in the pipeline,


and also how does AMP fit into that?


No.


OK.


Yes, please.


Please tell us more, Gary.


No and?


OK, so let's continue with the indexing theme.


Actually, let's step back a little.


We already talked about content conversion,


and there we covered a few special cases


like PDFs for which we have special plugins that we


use to convert to HTML.


But then we have other kinds of media


that are even more special than PDFs in some sense.


For example, we have images.


And images are kind of special from the point of view


that they are truly binary format,


and they are very hard to understand for machines.


So for images particularly, we have a completely different


indexing mechanism.


I'm not going to give a name for that,


because I don't think we ever did.


And I don't want to call it Fred, because Fred is special.


But what we do is during content conversion,


we extract the image tags, essentially, also


from some other image sources, and then pass those image URLs


onto this special image indexer.


And then there some magic happens.


There we do some image intelligence or image


recognition, for example.


Don't overthink it, because it's not perfect,


and it's not there yet, essentially.


Basically, it can tell, for example,


an apple from a banana.


But if you show it, I don't know,


a pencil, cheese, or parmigiano, it


will not be able to tell them apart,


unlike Pascal, for example.


Then again, stepping back to converter,


we also extract videos there, or metadata about videos.


And that's, again, a very special format,


because while with images you have basically one image,


with videos you typically have about 20,


24 images per second that you would


have to process to understand what the heck is going on


in the video.


On top of that, you also have the audio track


that you might need to process to understand


what's in the video.


And this is not easy task.


This is actually quite hard task.


It is done by the same indexing mechanism


that we use for images as well, but it gets way, way, way more


complicated with videos.


And then again, stepping back to converter,


we have, for example, AMP.


AMP, unless it's canonical, basically standalone AMP,


we don't index it.


And I know that that's a shocker,


but essentially AMP is just an alternate format


that we present for searchers in our search results


for our users.


If it's standalone AMP, basically canonical AMP,


then we will just treat it as HTML,


and it gets indexed potentially just like an HTML


page would be indexed.


And then what else do we do with AMP?


We badge it in the search results, right?


GARY ILLYES-SCHREIBER-MARTINI Yes, but that's just a special


badge that we apply to AMP.


MARTIN SPLITT RASMUSSEN I mean, people are hypothesizing


that this is also a ranking thing,


but it isn't, as far as I'm aware.


GARY ILLYES-SCHREIBER-MARTINI No, AMP is not, on its own,


a ranking signal.


MARTIN SPLITT RASMUSSEN Right, cool.


Wow, I mean, I asked about AMP, and I got images, videos,


and AMP, so that was a nice bonus.


But do you know how we are dealing with web stories?


Because I know that we are showing them


in Discover and stuff, and I'm not exactly sure


how we are showing them in SERPs right now,


but I think we are showing them separately, too,


as in a special way.


GARY ILLYES-SCHREIBER-MARTINI I have literally no idea.


MARTIN SPLITT RASMUSSEN Oh, oh my, OK.


GARY ILLYES-SCHREIBER-MARTINI But the good thing


is that we have Pascal here, who probably knows.


MARTIN SPLITT RASMUSSEN True.


Pascal, I kind of jumped ahead here


and jumped into web stories.


Would you like to explain to us how they work, what they are?


PASCAL BOTTOON Yes, sure.


I think you kind of hinted at this a little bit.


So web stories are powered by AMP.


They're built on top of AMP.


So they are canonical AMP pages.


And as Gary said, they're like regular web


pages that can be indexed.


And as you mentioned, they can be found via search


or also Discover.


I think even in image search, you'll


see images that are part of stories,


and then you can open a story.


So there's a variety of ways where they can be found.


MARTIN SPLITT RASMUSSEN That's pretty cool.


And you're saying they're built with AMP.


So I'm guessing web stories, how does a web story look like?


How can I imagine a web story to be like?


What is it like?


Is there anything comparable?


PASCAL BOTTOON So from the user point of view,


it looks like you would imagine a story.


It looks like a story you would see


on, let's say, Instagram or Facebook or other platforms


that have this story format.


It's just brought to the web.


So you have the same controls, like arrows to navigate


or a mute button.


MARTIN SPLITT RASMUSSEN That's cool.


So basically, I can create stories similar to those


created in these walled gardens, like Instagram, Facebook,


and all the others.


But I can do that on my website.


PASCAL BOTTOON Precisely, yeah.


On your website, your server, you're


in full control, which means they


don't have to disappear after 24 hours, for example.


MARTIN SPLITT RASMUSSEN Nice, because I really, really don't


like that.


That's the worst part about stories.


You're like, oh, this is an amazing story.


Gone it is forever.


So how does it work with the individual pages?


Are they separate URLs, or is it one document


which has all of those individual pages


for the story in it?


PASCAL BOTTOON So it's one document


with all the pages in it.


So the URL doesn't change when you navigate between pages.


So cool.


So do you have to make these manually at the moment,


or is there some tool out there that helps?


Great question.


Luckily, coincidentally, I work on a tool to create stories.


You could, of course, create these manually.


But would you create a website manually these days?


You probably have some kind of tool or CMS to do this.


GARY ILLYESISIOSAIS No, I'm actually doing it by hand.


I love coding by hand HTML, because it's


one of the best things that was invented for humans.


MARTIN SPLITT RASMUSSEN Sure, sure, Gary.


You and the seven other people.


GARY ILLYESISIOSAIS Well, actually, fun story.


And we should have talked about this with our tech writer,


Lizzie.


But for the dev site, for developers.google.com,


we are actually creating HTML.


And we are creating HTML by hand.


So whenever we publish something on developers.google.com,


we are literally, by hand, creating HTML.


MARTIN SPLITT RASMUSSEN Wow, so old school, Gary.


GARY ILLYESISIOS I know.


Wait, did you just call me old?


MARTIN SPLITT RASMUSSEN Gary old.


GARY ILLYESISIOS Never mind.


MARTIN SPLITT RASMUSSEN And he's a man,


so he's Gary Old Man now.


I have to also say, actually, I didn't


expect to be on Team Gary here.


But hey, here we go.


I'm on Team Gary now, because I really do like hand


coding HTML as well.


GARY ILLYESISIOS What the heck?


MARTIN SPLITT RASMUSSEN I know, right?


I can't believe it either.


And I have to say, I built a web story a while ago just


to try it out.


And I have to say, it was quite a fun experience.


It's a lot more visual than, I mean,


building websites is a visual process,


because the outcome is visual.


But you are working a lot more with images and animations


and videos and much more visual content.


So while I liked it, like hand coding an AMP story,


because it's basically built on custom elements and web


components, it's really nice and easy to build these things.


And I think the outcome is beautiful, much more beautiful


than it would be if I would build it just


without the entire framework of the AMP components around it.


But I do wish for a visual editor, honestly.


So I think if you are building that into WordPress,


that's really cool.


But will we get that outside of WordPress as well, maybe,


please?


So yeah, as you said, this visual editor we're building


is part of WordPress.


So it's a WordPress plugin that you can install.


But there are other tools available already today


that are separate or standalone.


Those are platforms like Make Stories or Newsroom AI,


where you can create a story independent from your website.


But you can still, like you could export the story


and then still host it on your server, for example.


Yeah, because in the end, it's a bunch of images in HTML.


Basically, it's static web content, right?


Yeah, very easy to move around.


That is cool stuff.


I imagine creating an editor like this in WordPress


is pretty tricky, because WordPress


can get pretty complicated, right?


Or how are you managing that?


Is the hard part doing the visual editing,


or the hard part integrating all of that into WordPress?


So the editing part is rather straightforward.


We built it in a way that we could also, let's say,


port it to Drupal or other CMSs if we


would want to in the future.


Integration with WordPress is tricky,


because if you install WordPress,


you can install plugins.


You can install themes.


So every WordPress site is really unique.


And this can cause, of course, integration issues


with other plugins.


So you have to be really careful to get it to work everywhere.


So cool.


And is this going to be open source,


or is it going to be something unique to Google?


No, this WordPress plugin is completely open source.


It's available on GitHub.


And actually, all the product specifications and roadmap,


et cetera, it's all open source there as well.


Wow, so cool.


OK, I need to try that out.


I'm thinking here, this is kind of like an SEO podcast,


because we talk about search engines and optimizations


and whatnot.


I mean, like literally optimizing search engines,


not the pages.


But if we flip this and we want to do SEO for web stories,


how would I go about that?


Great question.


I know, I get that a lot.


So because they're regular web pages,


you kind of should do the usual things


for making sure stories can be found in search,


like meta description or schema.org metadata,


things like that.


There are some additional things one


should to be valid AMP.


So the AMP story format requires things like a poster image


to be set for a story or a publisher logo to be set.


Without these, it wouldn't be valid AMP.


And I'm sure a story that is not valid AMP


will be treated differently, I think.


Oh, yeah.


Did you create the story using the WordPress plugin,


or was it the manually assembled one?


Oh, I got to admit that I haven't used the WordPress


story editor, because my website's not using WordPress.


Ooh.


I know.


You used Search Console to test it, right?


Yeah, sure.


Sure, I'm using Google Search Console.


But I basically took something that was a talk of mine


and used the visuals to put together a web story


version of a talk on developer tools for Google Search


and basically how to debug things.


And it's a very visual thing with lots of screenshots.


And I used the different text effects and animations.


And it looks really good.


And it's a lot easier to do this with the AMP components


than actually building this yourself and making


or trying to make it performant.


So it was a really good experience.


And the outcome was really good.


And that's the first moment I had discovered traffic


in Search Console.


Search Console gave me the performance report


on my discovered traffic performance.


And that was really, really fun.


So cool.


OK, cool.


Yeah, I don't know.


Talking about Search Console, one of the things


that I hear every now and then, or I


get questions about every now and then, probably some of you


as well, is like, when is Google going to launch whatever


next new thing?


Or what is Google planning to launch next week kind of thing?


And I thought I would talk very briefly


about how we work around these launches


or how we plan them, all of that,


especially when it comes to things like Search Console.


Some of this kind of applies to other parts of Google


as well, to Search or other products too.


But I just see it mostly with Search Console.


Essentially, when it comes to these products,


I see that we kind of make a roadmap fairly early on so


that we can plan our engineering time, which makes sense.


Because you can't just throw up a new feature from one day


to the next.


And then, essentially, the work is kind of set rolling.


And it started from there.


And that's something where the launch date isn't something


that we fix and say, this is going


to launch on exactly this date.


But rather, we'll try to launch it as soon as it's ready.


And because of that, as soon as it's ready part,


it's really hard to have launch dates ahead of time.


And when people come to us and say,


well, I would like to know what's


happening next week or next month, what's launching then,


then sometimes it's really hard to give that information, even


internally.


Externally, it's, I think, even harder


because people have all of these expectations then.


And they kind of watch out for that launch


that they're waiting for.


And we say, it's going to happen on this date.


And then it doesn't happen on that date


because it's not ready yet.


Then that's all kind of annoying.


That's something that I think is also a bit tricky


because sometimes there are aspects that come into play


fairly late in the product, in the design,


or in the finishing of the product,


where maybe there's a legal or a policy review happening just


briefly before launch.


And for whatever reason, one of those reviews


says, oh, we need to change something.


So we need to make this a little bit better,


make this a little bit clearer.


And sometimes that can push back a launch by several months,


even.


So even when we do things like trusted tester launches,


where we kind of try things out early on,


it can still take a significant amount of time


until things are actually launched.


So because of that, it's really hard for people


to come to us and say, hey, I'd like


to know what's happening next week,


or can you give us a heads up or a preview of what you're


going to launch now, then oftentimes we


don't really have any of those details that we can share.


I think one exception that comes into play


is when there's something tied to a specific external event.


With Search Console, that's pretty rare,


but it could also happen.


So for example, on May the 4th, I think last year


or the year before, I was like, I have no idea


how time flies anymore.


Everything is weird now.


But on May the 4th, we did a Star Wars theme


thing in Search Console.


And of course, that had to be ready on that date.


We couldn't do the May the 4th features on May the 15th.


It's like nobody would have noticed or figured out


what that was supposed to be about.


That's kind of the one thing there.


I think with the hardware products that we have,


they're a little bit more tied to the consumer dates


around Christmas or when things have to be ready, all of that.


But Search Console isn't really tied to any of those dates.


One other thing that also comes into play with regards


to launches is we have regular launch freezes at Google.


And these are specific times of the year


where we know that a lot of the teams are on vacation,


and we want to make sure that we don't launch anything


during that time.


So during those specific times, we


tend to hold back all of the launches


so that we don't run into any problems accidentally.


Usually, that's around end of the year, around Christmas


time, where we would say, well, everything


until this date in December can be launched.


And then from January, some date,


things can launch again as well.


There's a weird story around this, I think,


right around the time part of the Search Console team


moved to Tel Aviv, where they said, well,


we don't really care about the end of the year time.


That's not our holiday season, so we will just


continue launching anyway, which was kind of awkward


because these are broader dates.


But I think what happened there in the end


is that we just decided, well, we really


need to stick to these dates because it's not just one team


that's working on the launch.


There's lots of teams at Google that kind of play into that


as well, where something could go wrong


in one of the infrastructure sides of Google,


and that might be something that you rely on for a launch.


I think kind of with regards to launches and Search Console,


that's kind of how it goes.


It's I wish there were an easier answer where we could just


tell people at a conference, it's like, by the way,


we're going to launch this cool feature tomorrow.


But it just doesn't work that way.


So unfortunately, we can't do that.


Well, Daniel had a really easy answer for these questions


at the Webmaster Conference in Zurich 2019,


where basically every single question


he got regarding launches just was answered with no.


And that was his easy answer regarding


launches in Search Console.


OK, yeah.


Oh, and when I say Daniel, I mean


Daniel Weissberg, who is also on our team.


And he is mostly our expert on Google Search Console


and does these Google Search Console training videos


on our channel as well.


And he was also part of the Webmaster Conference in Zurich


last year.


I mean, it's also something where


I'd love to tell people some of the stuff that we're working


on, because I think some of these things


are really cool and exciting.


But you never really know when exactly things will be ready.


And then you make everyone excited about something.


And then it's like, oh, actually, maybe next year,


which is super frustrating.


Yeah, I mean, it's a lose-lose situation kind of thing, right?


If we are announcing something that doesn't happen,


then people are annoyed.


And if we announce something early on,


then people might forget about it,


or the enthusiasm might die down.


So these freezes, what do they affect?


I think the one thing to keep in mind


is that a lot of the ranking stuff, a lot of the search


results side of things, is purely


algorithmic and automatic.


So if the web changes on Christmas day


on the 1st of January, then we're


going to reflect that in search automatically.


It might be that we don't make any new algorithms or new


launches during that time, but the rest of the systems


continue to work automatically, right?


So from that point of view, you'll


continue to see changes in search during the time


when we don't make any algorithm updates,


just because the whole web continues to evolve and change


all the time.


Is that what you were looking for?


Yes, yes, yes, yes.


They shipped the sheep indeed, yes.


Why do you have sheep?


Yeah, I should probably give a little bit of background


for those of you who haven't heard of the sheep before.


I mean, probably most of you have heard about the sheep,


but the sheep that my neighbors use to mow their lawn,


basically.


So we have a building next to ours


that has a pretty large lawn surface around it.


And so far, they have been very spotty


on actually mowing the lawn.


So it has always looked a little wild, I would say,


which the neighboring cats loved,


because they were hunting mice and stuff in there.


But I guess that at some point, someone


might have decided that it would be good to do a little bit


of lawn care here.


And I think right after the lockdown started,


I was live streaming on Twitch while I


was doing Rendertron work.


And then there was this really annoying thumping sound


that repeated every couple of minutes.


And it was really loud as well.


And I apologized to my viewers.


And I took a look outside.


And I'm like, I'm not sure what they are building.


But it looks like they are building a fence.


But why?


There is already a fence.


And then I noticed this specific kind of fence.


It looked very much like the kind of fence


that I know from my childhood growing up in rural Germany.


I'm like, are they putting sheep or goats or something on here?


And I guess you wouldn't put goats on a lawn


to mow it, because goats kind of rip out


the entire thing with the roots.


And that kind of ruins a lawn very easily.


So they jump a lot.


It was on the edge of the Sahara, very few trees.


And all the trees looked quite pathetic.


They were not very happy about the Sahara situation.


And then these goats were on the branches up in the tree,


eating those few leaves that were still on the tree.


MARTIN SPLITTENBERG


It's bizarre.


So yeah, and I was right.


They actually put sheep on the lawn.


I was really excited.


And elated about it.


And then they had the sheep here for a week or two.


And then the sheep were done with mowing the lawn,


well, eating basically, the lawn away.


And then they were gone.


One morning, I heard a lot of maa, maa.


And I was like, what's happening here?


GARY ILLYES-SELLERSI sorry, could you


repeat that?


I couldn't catch that.


MARTIN SPLITTENBERG Ah.


Anyway, so yeah, they're back.


And I'm really excited.


I'll keep you posted on how long they'll be here.


And I'll go there and pet them for you all.


GARY ILLYES-SELLERSI Thank you.


This is very important for us.


GARY Could you perhaps set up a webcam?


Yeah.


MARTIN SPLITTENBERG Could I set up a webcam?


I knew you would ask that.


I might, actually.


GARY Oh, wow.


The sheep update.


MARTIN SPLITTENBERG That's a good idea.


And as we speak, they are coming around the house.


Because they have a really large area that they can cover.


So normally, they sleep on the other side of the house.


I'm not exactly sure why.


But I will investigate.


GARY This sounds like a perfect topic for a web story, Martin.


MARTIN SPLITTENBERG Yes.


GARY I can also set up a WordPress site for you.


MARTIN SPLITTENBERG Oh, please do.


I will love that.


I'll get a funny domain name for it.


So cute.


But they're a lot thinner than they were in April.


GARY Well, yeah.


MARTIN SPLITTENBERG Good that they're here.


I'll make sure that they are well fed.


GARY You're not supposed to feed them.


Come on.


MARTIN SPLITTENBERG Well, if I feed them,


then they don't eat as much grass,


which means they stay longer.


I have it all worked out.


After last time's disappointment of them being gone so quickly,


I'll make sure that they stay longer this time.


GARY Oh, my god.


MARTIN SPLITTENBERG Oh, god, they are so cute.


GARY I think we should just cut off here now.


Martin is totally distracted now.


MARTIN SPLITTENBERG So fluffy.


Yeah, this is going sideways.


It's going forward towards the sheep.


GARY All right.


So on mute, Martin.


Quick, quick.


MARTIN SPLITTENBERG I can see them.


GARY Thank you for joining us here, Pascal.


It's been great having you here.


It's cool to hear about WordPress and Web Stories.


Looking forward to trying that out a little bit more.


In general, we've been having fun


with these podcast episodes.


I hope you, the listener, have found them both entertaining


and insightful too.


And let us know how you're liking these,


if the topics that we talk about are useful to you.


And if not, give us some ideas of what


we could be doing differently.


Feel free to drop us a note on Twitter


or chat with us at any of the online conferences


that we go to.


Unfortunately, the physical conferences


still aren't happening.


Or maybe just stick to Twitter.


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


this podcast with others.


Thank you, and bye, everyone.


Bye.


Image Search Ranking #AskGoogleWebmasters

Today's question is from Sashin Khanna.


Hi, John.


Please tell us how to rank images on Google.


Please tell us some useful tips.


Well, images are awesome.


For example, images of cheese.


Who doesn't like cheese?


Anyway, when it comes to images, the number one thing to consider


is how you'd want to be found in image search,


what you expect users to search for,


and how can your site be useful to them when they find you?


In short, don't just optimize for images because they exist,


but rather do it with a specific goal in mind.


Once you have that, you can look at the technical details.


Let's start with these.


Use high quality images.


Place them on your pages in a relevant and visible way.


Use great titles on the pages themselves.


Provide useful alt attributes for the images.


Potentially add captions.


Pick good file names for your images.


And host your images in a way that they're


fast for your users.


There's a lot more that can be done


to optimize images for search.


If you're curious, then check out the article I linked to


in the description below.


That's it for today.


Don't miss any of the future episodes of Ask Google


Webmasters, and subscribe to our Webmasters YouTube channel.


This is Botha.


JavaScript SEO office hours June 17th, 2020

Hello, and welcome to the JavaScript SEO office hours.


Today is June 17, and I see that we have a few YouTube


questions.


Besides Dave, no one else joined the Hangout recording today


so far.


Oh, now as I speak, here's Pedro joining or not joining us.


I don't know.


Yeah, yeah, here we go.


Hi, Pedro.


You're on air now.


I just started the recording.


I'll edit this part out.


No worries.


All right.


So assuming that we just, how are you doing?


Just came to say hi.


I'm doing good.


Oh, OK, that's good then.


Sweet.


So I'll officially start the recording now.


I mean, I started it, but I'll just retake the intro.


Hello, and welcome to JavaScript SEO office hours


of the June 17, 2020.


Great to have you watching this video


or joining this recording or asking questions on YouTube.


We have a few YouTube questions today that I'll go through.


Then I'll give the audience an opportunity


to ask their questions, and then you'll


have the chance to submit questions for the future


JavaScript SEO office hours on YouTube.


So first question is a React.js question.


They got two different homepage SEO on the Google,


on the page Google crawled.


OK.


I'm guessing that they mean like meta tags or something.


I'm not sure.


One is index HTML, and the other one is the helmet component.


Well, the helmet component is probably


part of what gets rendered for next engine.


All right, let's see.


How is it possible?


I have checked.


Oh, right.


I have checked with a tool, some sort of tool.


I have not heard about the tool beforehand.


So they use the tool, and the tool gives a grade of zero


and says content is not available.


Then that's not a good tool, I would guess.


So I would say don't use tools that


don't reflect the real thing.


I would always recommend using the tools that we provide,


because they show you the rendered HTML as it comes out


of our actual indexing rendering pipeline.


So if we see them in the testing tools, then that should be fine.


Now, they posted the website that they have.


I'm not going to pull it up on screen, but I had a look.


And they do have the meta description


and a few other meta tags twice.


I would assume that you have put it in the actual index HTML


file, but then React, as it renders the page,


creates its own set of these tags.


So I would suggest that you either remove them


from the index HTML and rely on React helmet


to render these tags specifically


on the components that get rendered.


Talk to your developer.


If you're not sure what happens there, talk to your developer.


But very likely, you want to remove the ones in the index


HTML, because they are not specific to the content that


is on the page for React if you're using client-side


rendering with React.


Then we have a second question.


Does the CSS and JavaScript formatting of a website


affect SEO?


Not sure what you mean by the CSS and JavaScript formatting.


But generally speaking, use the testing tools,


look into the rendered HTML.


The thing that we see there, that's


what we actually care about.


So if you feel like I'm not answering the actual question,


try to give me more details for the next Hangout


so that I can answer the question better.


And we have a navigation-related question.


And I think that is the second-last question


that I'll have today.


And then the audience gets their turn


to ask questions on top of it.


A large website has a three-level flyout menu.


Three-level?


Wow, OK.


Fair enough.


Second-level links are provided in Coda's Ahrefs links.


Good.


Third-level links are loaded by a JSON file


when hovering with a mouse.


Right.


Do I understand it correctly that the third-level links,


which are packed in JSON file and not provided,


and will be ignored and not crawled if they are not


linked elsewhere?


Yes.


Anything that isn't in the HTML as we render it.


So you can use the rendered HTML that


is produced by all the testing tools, for instance,


like mobile-friendly tests, rich results tests,


Google Search Console URL inspection tool.


Anything that isn't there as a link,


we're not going to see it.


Especially if there's a user gesture involved,


it's not going to happen.


Last question.


Google is crawling URLs on the site, like a certain example,


with the only references to something like that


and rendered code being associated with a form.


So there's a form that has a form action,


and that's where these URLs show up.


Google crawls these URLs and gets a 404 error.


Why would that happen?


Without a specific sample site to look into,


many options come to mind.


It might be in the site map.


It might be that there is some other website out there


linking to these things.


It is possible that somehow we get


JavaScript that submits these forms or something.


Things can definitely happen.


It can also be that we think, oh, maybe there


is interesting content behind this form.


I don't think we do that, but I don't know.


So I'd rather not speculate on that.


But basically, if it's a 404 URL,


then that doesn't really hurt you


unless you are running into very specific problems with you.


If you're not having a problem, you shouldn't really


worry about it much.


If you want us to not crawl these URLs,


then you can also block them via robots.txt.


That's also an option.


But then we won't crawl them anymore.


But generally speaking, if it's a 404,


I don't see that as a problem.


There's nothing then for us to index.


And besides maybe crawl budget, if your site


has millions of pages, that shouldn't be a problem.


Awesome.


Sweet.


With that, I hope that was helpful for those


who posted questions on YouTube.


If not, feel free to post follow-up questions


for the next thread.


And now I'll open it up to the audience.


Anyone questions in the audience that you would like to ask?


Hi, Xiao.


Hey, Martin.


How are you?


I have a follow-up question.


I think one of the YouTube questions


touched base on that a little bit about CSS and JavaScript.


I remember several weeks ago, I asked you


if we blocked CSS, JavaScript, the problem or not.


You say, no, it's not considered cloaking.


But in some cases, we let them crawl,


but sometimes we return robot non-index.


And sometimes we don't let them crawl then.


Even the content, like textual content itself doesn't change.


They do change some user experience and some


functionality of JavaScript.


Do they be beneficial?


I mean, if you don't let Google crawl,


then it's not considered cloaking.


But if we let Google crawl, then it lets them index them.


Is it beneficial to help Google better understand and in turn


beneficial for SEO?


So if you're giving us a no index,


then that doesn't mean that we can't crawl them.


So we would still crawl them.


We would just not put them in the index.


But I don't think we would put them


in the index in the first place.


So that's already a little bit of an edge case.


When you block us from running JavaScript and CSS,


then you are running into a situation that can potentially


be problematic.


For once, if there is content that somehow gets generated


from running some JavaScript, then we


are not going to see that content.


It can also be that, as you say, if you have user experience


improvements, such as lazy loading that


isn't using native lazy loading, but you


have some JavaScript library that does this correctly,


then we might not see the image URLs unless you


use the no script workaround.


So I would not block Google from using and crawling


the JavaScript and CSS files.


CHINMING WANG, QUIETLY.


From what you said, you say that Google


don't index CSS or CSS or something?


They don't?


So how do Google know what's happening on the page?


MARTIN SPLITT, QUIETLY.


So I think what might be the problem here


is a misunderstanding of what is crawling, and what is indexing,


and what is rendering.


These are three different distinct things.


When we crawl, crawling just means we make an HTTP request


and fetch the result back.


If you use robots.txt and say, disallow crawl,


that means we can't make this HTTP request.


That is a problem, because then we


can't execute the JavaScript, because we can't


download the JavaScript.


That's one thing.


That's crawling.


Then we render, which means we take the crawled JavaScript


and run it in the browser.


And then whatever content that produces


on the page that includes that JavaScript


can be put in the index.


And that's the third stage, where we say,


here is content that we want to potentially show to a user.


So we put it in our database, so to speak.


Normally, JavaScript does not have interesting content


for us to show to a user, because it's not really


a website.


It is just an asset to another website.


So we would index the website that uses the JavaScript,


but not the JavaScript file itself.


So we wouldn't put application.js in the index,


because that's not something that we would ever


want to show to a user.


We would crawl it.


We would render it, but we would not index it.


So the robot noindex HTTP header on JS or CSS


is meaningless in the first place,


because Google don't do it in the first place.


Pretty much, yeah.


There are certain situations where somehow, sometimes, we


get it wrong and then put something in the index,


and then you can remove it from the index using that.


But it's very, very rare that that happens.


So Google don't index the HTML file itself in that Google


index file?


The HTML file, yes.


JavaScript file, no.


So when Google indexing a page, it's


indexing the DOM, rendered DOM, or the HTML.


Well, the rendered DOM is pretty much what gets.


And also, not even that.


So it is even more complicated.


So basically, what happens when we index is we take the URL


that we are getting from wherever, link, site map,


whatever, and then we index a bunch of information


about the content on the page.


And the information on the content in the page


comes from the rendered DOM.


But it isn't exactly the rendered DOM.


I see another thing that I found interesting is that I realize


some pages is blocked by robot.txt,


but some URL that redirects to that page is not blocked.


And Google sometimes still rank those URL that


redirect to the blocked page.


So Google knows that that URL is redirected to that page,


and they can see the page that being blocked


but being redirected to.


Wait, so you have a page A that redirects to page B,


and page A is blocked by robots.txt?


Or?


Page B is blocked by robot.txt.


So do you?


Then Google rank page A very highly,


which indicate that Google actually know that page A link


redirected page B, and they consider


the content of the page B because they can see that?


I would not expect that to be the case.


But it is possible that if page A gets enough positive signals


from elsewhere, so if it's linked from a lot of places


and just generally seems to be useful for whatever reason,


I don't know where the signals come from.


But if it looks like this might be a good candidate to show,


then we could show it even though it is just


a redirection to a page that we can't crawl.


It also actually, we sometimes index pages


that we can't crawl.


Even though we don't know what is on there,


we might get the information of what


might be on there from the context at which it


is linked to.


So in this case, you will say that we shouldn't


block page B in the first place if page B is important?


If you care about page B, you shouldn't block it, yes.


OK.


Go back to the JavaScript thing.


Sorry.


No worries.


I just wanted to finish that up.


You say that if they have contextual problem,


it's a problem.


But let's say there is no contextual problem,


textual change from JS or CSS, it's just user experience.


And I am under impression that Google


take user experience into account, especially


for some more interactive page.


In this case, JavaScript and CSS will be relevant to SEO.


In this case, if we block JS and CSS


that serve inferior user experience,


would they hurt our SEO?


Yeah.


OK, thank you.


You're welcome.


Awesome.


Good questions.


I like good questions.


Do we have another question from the audience?


I'd like to ask one if that's OK.


Sure.


Is there any way to reset the performance observer


between routes?


So if you've got an SPA site or something like an upside


hydrating, it ends collecting on the first page you hit.


Well, then you go to a different route,


you go to a different page, and it's kind of then the sum of two


because it is one page.


Is there some kind of method that you


can reset between the two?


So you're getting the proper CLS, the LCP, et cetera,


data from that page?


I don't think you get an opportunity to reset it.


That's a really, really interesting question.


And I wonder how we would go about that.


Because technically, the browser,


in a single-page application, the browser might not know


that there is effectively a navigation happening.


So I don't think there is a way to measure that.


You can probably know you can't even


use any other APIs or metrics.


I mean, the scruffiest thing is just kind of timestamp it


and take it from there and reassess it.


Yeah, that would be an opportunity.


Yeah.


I think you can also use, I think there's like,


I think it's called the user timing API


that you can possibly use to build your own.


But I'm not sure how well that would work.


Yeah, there's like performance.mark


that allows you to set marks on the timeline.


So you could maybe use that.


And yeah, there's no ready-made easy solution for this to see.


Excellent.


Do you know how that rolls back into Crux data


and what's sent through?


Not sure.


I'm not familiar with how Crux gathers its information


telemetry.


Good question.


Don't know.


I'm wondering if there's anywhere


where you could bring this up.


I'm pretty sure there's the standard has,


not sure if the standard is finalized.


I think the standard is still pretty much in flux


for performance observer.


So this might be a question that would


be good to take into the standards body, which probably


is literally just a GitHub discussion for this.


Yeah.


The spec is on GitHub.


And if you have questions for the spec,


then probably literally opening an issue on GitHub


is a good way.


It's very likely a good way to get a feeling for what


they think about this, because I'm not sure if anyone ever


thought about this.


So I'll post the link to the GitHub repository


where that spec is being worked on.


Good question.


Thank you very much, Dave.


All right.


I think we have time for one or two more questions.


Anyone in the audience?


Yes.


Now is your opportunity to ask.


No more questions?


OK.


So I think let me reload the YouTube thread,


not to miss a question.


Sometimes we get a few late birds.


Oh, yeah, there are late birds, I think.


There's now nine comments before, and there has been less.


We're updating our website to a responsive design


and possibly incorporating headless e-commerce.


What are the main considerations that


should be taken into account from an SEO JavaScript


perspective?


That the Google caller can still see your content.


You can test that in all the testing tools.


Look at the rendered HTML.


It sounds a little bit like a broken record,


but that's more or less what you should always do.


And surprising amounts of people don't do that.


So definitely check for the rendered HTML.


Oh, OK.


Can't join the Hangout.


But someone just joined, so I'm not sure.


I hope that this isn't a random thing,


because I heard that Hangout apparently sometimes kicks out


more than six people, but we're eight at some point now.


We are seven.


I hope that this isn't a larger problem.


But sorry, Clint, that you couldn't join.


I hope I answered your question reasonably well.


The biggest concern is making sure


that your content shows up in the rendered HTML.


That's the biggest concern.


I have an Ahrefs link to navigate to my website.


Good.


But when you click on the link, the on-click code


prevents the default action, so the Ahrefs is actually ignored,


and the on-click updates the content on the current page.


Is that considered choking?


No, unless the content is very different from what


you would expect to get.


And yes, we would still consider this to be a link.


Unless, again, you're misleading the user


and you're doing weird stuff, having


an on-click handler that overwrites what the Ahrefs would


do is not a problem.


OK.


Anyone in the audience?


Last question.


Last opportunity to ask a question.


No questions?


There are no further questions.


Thank you very much for joining the Hangout,


and thank you very much for posting all your questions


on YouTube.


I hope this is helpful.


Let me know if you have further questions.


I will post to the YouTube channel


a new thread for next week's JavaScript SEO office hours.


You can always ping me on Twitter as well.


And have a great time.


Stay safe.


Take care.


Thanks a lot for watching.


Page Speed: SEO Mythbusting

What do you think are misconceptions about page speed and especially is page speed and ranking?


Page Speed: SEO Mythbusting

Well, a lot of people think that it's a big ranking factor.


Page Speed: SEO Mythbusting

In fact, I was literally looking at a document that a company had produced.


Page Speed: SEO Mythbusting

This document actually talked about SEO and it had section on SEO, which is good.


Page Speed: SEO Mythbusting

They're at least thinking about it.


Page Speed: SEO Mythbusting

But the first thing they listed was page speed and they were actually quite insistent in the write-up


Page Speed: SEO Mythbusting

that it was the most important ranking factor.


Page Speed: SEO Mythbusting

Oh, no.


Page Speed: SEO Mythbusting

And I was like, okay, I've got to find the right way to tell them that I want them to deal with this


Page Speed: SEO Mythbusting

because it's really important and it clearly impacts user engagement and conversion.


Page Speed: SEO Mythbusting

No, it doesn't mean you're going to move up three spots in the vault.


Page Speed: SEO Mythbusting

Hello and welcome to another episode of SEO Mythbusting.


Page Speed: SEO Mythbusting

With me today is Erik Enger.


Page Speed: SEO Mythbusting

Would you like to introduce yourself because you're doing so much stuff?


Page Speed: SEO Mythbusting

Sure.


Page Speed: SEO Mythbusting

What is it that you're doing?


Page Speed: SEO Mythbusting

Well, you know, I'm a general manager of part of the digital marketing team at Proficient Digital.


Page Speed: SEO Mythbusting

And altogether we do, let's see, SEO, content creation, content marketing, pay-per-click, analytics,


Page Speed: SEO Mythbusting

conversion rate optimization.


Page Speed: SEO Mythbusting

Trainings, Twitter, conference speaking.


Page Speed: SEO Mythbusting

Yeah, that's a fair amount of stuff to keep us busy.


Page Speed: SEO Mythbusting

A fair amount of stuff to keep us busy.


Page Speed: SEO Mythbusting

But today we're going to get busy talking about page speed.


Page Speed: SEO Mythbusting

That's a great topic because so many people get it wrong.


Page Speed: SEO Mythbusting

Oh yeah, it's quite a deep topic as well.


Page Speed: SEO Mythbusting

So what kind of questions do you have around ranking factor, page speed and page speed in general?


Page Speed: SEO Mythbusting

So let's actually start in general and just talk about why page speed is important.


Page Speed: SEO Mythbusting

How's that sound?


Page Speed: SEO Mythbusting

Ah, that sounds fantastic.


Page Speed: SEO Mythbusting

I think if you look at what you're trying to accomplish is you're trying to accomplish that you're building a good website for your users, right?


Page Speed: SEO Mythbusting

Right.


Page Speed: SEO Mythbusting

Now, how many times have you been on the metro or in a car or somewhere in the countryside where you didn't have fantastic reception on your mobile phone


Page Speed: SEO Mythbusting

and you were basically just like really quickly trying to find something out and it just took ages for the content to actually show up?


Page Speed: SEO Mythbusting

That's painful, isn't it?


Page Speed: SEO Mythbusting

It is painful and in fact on some sites that can happen when you are in a place where you have a perfectly strong signal.


Page Speed: SEO Mythbusting

That's actually true, yeah.


Page Speed: SEO Mythbusting

And that's not, that's so frustrating.


Page Speed: SEO Mythbusting

Right, and you don't want to frustrate your users.


Page Speed: SEO Mythbusting

And we as a search engine do not want to have users frustrated when they like see content.


Page Speed: SEO Mythbusting

So for us it makes sense to consider fast websites a little more helpful to the users than very slow websites, right?


Page Speed: SEO Mythbusting

It does make sense and I guess my thought process in this has always been that, well, yes, it's likely that you're using it at some level as a ranking factor.


Page Speed: SEO Mythbusting

But you can't make it such a strong ranking factor that you won't show the most relevant content.


Page Speed: SEO Mythbusting

Oh, yeah, absolutely. So, yeah, if you have bad content, if you are the fastest website out there but the content is not great then that's not helping you.


Page Speed: SEO Mythbusting

Right, right. I mean to get the content you don't want quickly is probably not what the users want.


Page Speed: SEO Mythbusting

Exactly, like I have a blank website, it's the fastest website ever. Yeah, what's the point?


Page Speed: SEO Mythbusting

Exactly. But it does make sense to consider it at least at some level and there's actually a fun pair of statistics.


Page Speed: SEO Mythbusting

I think they're both from Google. One is that something like 53% of sessions are abandoned if it takes longer than three seconds for the page to load.


Page Speed: SEO Mythbusting

And then the companion statistic is, and I think it's a little bit old but still, the average page takes 15.3 seconds to load.


Page Speed: SEO Mythbusting

Oh, yeah. What a frightening combination. It is frightening, it's frightening.


Page Speed: SEO Mythbusting

And it's so many different factors, right? Sometimes it's those servers but sometimes it's just like the server responds really quickly but then there's a ton of JavaScript that has to be processed first.


Page Speed: SEO Mythbusting

And JavaScript is a very expensive resource because it has to be like fully downloaded and then parsed and then executed.


Page Speed: SEO Mythbusting

Right. But, yeah, so we keep seeing this and everyone knows this and anecdotal evidence is there as well.


Page Speed: SEO Mythbusting

Like you have studies, you have the anecdotal evidence of you sitting in front of a website going like, ugh.


Page Speed: SEO Mythbusting

And just imagine being on a metered connection where you actually pay by megabyte when you fly or something.


Page Speed: SEO Mythbusting

It's like you can buy 20 megabytes for 10 euros or something and you're like, oh, OK.


Page Speed: SEO Mythbusting

Open one website, you said, what was it, 15 megabyte is the average or something?


Page Speed: SEO Mythbusting

Well, it's 15.3 seconds.


Page Speed: SEO Mythbusting

Sorry, 15.3 seconds. But, yeah, so you can just imagine like how much data you're pulling in these 15 seconds.


Page Speed: SEO Mythbusting

Yeah, in fact, I did see, I really was looking at this just yesterday.


Page Speed: SEO Mythbusting

There is this data from Think with Google where by market sector it shows the average web page size and they're all in the megabytes in every market.


Page Speed: SEO Mythbusting

And I think your recommendation is 500K bytes or less if I'm not mistaken.


Page Speed: SEO Mythbusting

The fewer the better, the fewer the better really.


Page Speed: SEO Mythbusting

Of course, right.


Page Speed: SEO Mythbusting

And just think about it. Like I grew up with entire video games on like two or three floppy disks which each fit like a megabyte and a half or something.


Page Speed: SEO Mythbusting

So why are we doing this on the web now?


Page Speed: SEO Mythbusting

Hmm, what a great idea. Well, maybe we should help people speed their sites up. What do you think?


Page Speed: SEO Mythbusting

That's the thing. And that's why ranking these by speed is also an important factor. But as you say, like content still is king.


Page Speed: SEO Mythbusting

Like there's no question about that.


Page Speed: SEO Mythbusting

Right, absolutely.


Page Speed: SEO Mythbusting

How do you think people are thinking about page speed as a ranking factor?


Page Speed: SEO Mythbusting

Like what are they trying to do when they are trying to optimize for it?


Page Speed: SEO Mythbusting

So, well, in terms of what they try to do, I think there's a few things that people are really good at thinking about related to page speed.


Page Speed: SEO Mythbusting

So I think almost everybody recognizes that images are a potential issue.


Page Speed: SEO Mythbusting

And certainly pre-sizing the image rather than making the browser do it, for example, and things like that.


Page Speed: SEO Mythbusting

And so they get to that first level of optimization.


Page Speed: SEO Mythbusting

Right.


Page Speed: SEO Mythbusting

But I think there's other things that they find a lot more difficult.


Page Speed: SEO Mythbusting

So, for example, the idea of not loading the content below the fold until the content above the fold is present.


Page Speed: SEO Mythbusting

Of course, that's a little harder to implement.


Page Speed: SEO Mythbusting

We have native lazy loading for images now, so that's something at least.


Page Speed: SEO Mythbusting

Yes, it is something.


Page Speed: SEO Mythbusting

And then I think another thing that they have trouble with is, and you actually mentioned it a moment ago,


Page Speed: SEO Mythbusting

the idea that the way you're hosted and the way your CDN is set up can be big factors if those aren't actually set up properly.


Page Speed: SEO Mythbusting

First of all, they might not have the CDN.


Page Speed: SEO Mythbusting

Oh, yeah, yeah.


Page Speed: SEO Mythbusting

But they may have it and it may not be properly configured as well.


Page Speed: SEO Mythbusting

No caching and stuff. We've seen all of this.


Page Speed: SEO Mythbusting

Yeah, exactly.


Page Speed: SEO Mythbusting

And then it could be as simple as I need more memory in my web server or a dedicated server when I'm on a shared server connection.


Page Speed: SEO Mythbusting

Well, that sounds pretty solid, but is there any misconceptions or myths that are going around where, like,


Page Speed: SEO Mythbusting

what's happening here, where is this coming from, is that true?


Page Speed: SEO Mythbusting

So, I do think maybe I could state the myth almost as an inverse,


Page Speed: SEO Mythbusting

is they're too focused on just a few surface level factors.


Page Speed: SEO Mythbusting

Oh, yeah.


Page Speed: SEO Mythbusting

And they don't realize there's other layers to this problem.


Page Speed: SEO Mythbusting

There's layers to this, yes.


Page Speed: SEO Mythbusting

Although there's another thing I can suggest actually as a myth, if you will, which is if I go into and get my Lighthouse tools report on a page


Page Speed: SEO Mythbusting

and I see it says, oh, this will cut six seconds out of the load time, and then they do that thing and the page didn't speed up by six seconds.


Page Speed: SEO Mythbusting

And I don't think people realize that some of these things are threaded.


Page Speed: SEO Mythbusting

So, yes, I did something good, but I have four other problems that also need to be fixed.


Page Speed: SEO Mythbusting

So, I do see a lot of people getting tripped up on that.


Page Speed: SEO Mythbusting

Yeah, and Lighthouse is a tricky one to begin with because people are getting confused by the idea that what they are seeing in Lighthouse


Page Speed: SEO Mythbusting

is what users are seeing, and that's not the case because you are literally testing from your machine, from your browser,


Page Speed: SEO Mythbusting

from your internet connection, and not necessarily what real people are experiencing when they're on their mobile phones on a spotty connection out there.


Page Speed: SEO Mythbusting

So, I think it's important to remember Lighthouse is lab data, and it makes predictions on what you can improve,


Page Speed: SEO Mythbusting

but that doesn't necessarily mean that, oh, now you're all doing fine.


Page Speed: SEO Mythbusting

Do you also think that people are paying too much attention to the scores itself?


Page Speed: SEO Mythbusting

Because I hear that quite a lot.


Page Speed: SEO Mythbusting

So, like the myth is like, oh, we're using the Lighthouse score for ranking.


Page Speed: SEO Mythbusting

That's not happening. That's not what we're doing.


Page Speed: SEO Mythbusting

Right. No, exactly. In fact, they get too attached to that score,


Page Speed: SEO Mythbusting

and sometimes it misleads them into thinking that they're doing just fine when they actually still have problems.


Page Speed: SEO Mythbusting

And another area that I see people running into is it works fine from my phone, but the user doesn't have such a nice phone.


Page Speed: SEO Mythbusting

So, you have to remember that there's different devices.


Page Speed: SEO Mythbusting

And you could see that in Google Analytics.


Page Speed: SEO Mythbusting

You can actually figure out what kind of devices you're seeing on your site,


Page Speed: SEO Mythbusting

and then you can specifically try to understand.


Page Speed: SEO Mythbusting

The best way would be to buy one of the phones that is most prevalent on your site, and have a look.


Page Speed: SEO Mythbusting

A very interesting idea.


Page Speed: SEO Mythbusting

And I actually shared a slide in one of my presentations recently, which showed data actually for CNN.com processing,


Page Speed: SEO Mythbusting

and it was around three seconds for the high-speed phone,


Page Speed: SEO Mythbusting

but by the time you got to a user with a less than $100 phone, it was 15 seconds to load.


Page Speed: SEO Mythbusting

And you just really need to remember that the users have all different devices.


Page Speed: SEO Mythbusting

You probably want to do a good job by the great majority of them.


Page Speed: SEO Mythbusting

Absolutely. And you want to be aware that a slow phone on a slow connection


Page Speed: SEO Mythbusting

is the worst situation you can probably run into in this kind of situation.


Page Speed: SEO Mythbusting

And you can use things like web page test to get a better feeling for how that would feel.


Page Speed: SEO Mythbusting

You can test from different locations and different network connections.


Page Speed: SEO Mythbusting

I would definitely recommend doing that.


Page Speed: SEO Mythbusting

There's so much more that you can do.


Page Speed: SEO Mythbusting

And also, if you have a website that is listed in Chrome User Experience Report, or CRUX,


Page Speed: SEO Mythbusting

then definitely use that as well.


Page Speed: SEO Mythbusting

And I think not many people are trying that out.


Page Speed: SEO Mythbusting

Well, it's good to get real-world data.


Page Speed: SEO Mythbusting

Real user metrics, absolutely.


Page Speed: SEO Mythbusting

Absolutely. Well, in fact, you can broaden that piece of advice


Page Speed: SEO Mythbusting

of well beyond the page speed conversation, by the way.


Page Speed: SEO Mythbusting

Because it relates to all manner of aspects of things around mobile, for example,


Page Speed: SEO Mythbusting

because we have everybody who designs for a desktop


Page Speed: SEO Mythbusting

and then has to slam that down into a mobile phone format.


Page Speed: SEO Mythbusting

Maybe design for the mobile, and then it's kind of easy to figure out how to render that on a desktop.


Page Speed: SEO Mythbusting

Exactly, you have more screen states.


Page Speed: SEO Mythbusting

Yeah, exactly. But for the page speed conversation, absolutely.


Page Speed: SEO Mythbusting

You just have to do that.


Page Speed: SEO Mythbusting

Definitely, right. And yeah, it's such an important thing.


Page Speed: SEO Mythbusting

And people, do you remember the entire controversy when people were like,


Page Speed: SEO Mythbusting

AMP is a ranking factor?


Page Speed: SEO Mythbusting

Oh my, yes.


Page Speed: SEO Mythbusting

It's not. And then people are like, but...


Page Speed: SEO Mythbusting

And page speed pays into that as well, right?


Page Speed: SEO Mythbusting

AMP gives you a certain expectation that you can have for your sites in the search results.


Page Speed: SEO Mythbusting

And I've seen good, fast websites rank higher than the AMP equivalent.


Page Speed: SEO Mythbusting

So like, maybe it is not the most important ranking factor,


Page Speed: SEO Mythbusting

but it's definitely an important one, as in like page speed is an important ranking factor.


Page Speed: SEO Mythbusting

And not so much. AMP is just like this little batch that gives the user an expectation


Page Speed: SEO Mythbusting

that they can have about it.


Page Speed: SEO Mythbusting

But page speed does matter for your users, and it does matter for your conversions, as you said.


Page Speed: SEO Mythbusting

Like sometimes it's configuring your CDN, getting a CDN, configuring your CDN,


Page Speed: SEO Mythbusting

making sure that caching is done right, and making sure that you architect your websites


Page Speed: SEO Mythbusting

and web apps in the way that they are fast by default.


Page Speed: SEO Mythbusting

And if you can do that without AMP, then that's fantastic.


Page Speed: SEO Mythbusting

AMP is a fantastic toolkit to help you do that if you don't know how.


Page Speed: SEO Mythbusting

Yeah, and you could go with progressive web apps as well, by the way.


Page Speed: SEO Mythbusting

Which are very nice because of their ability to preload content into the cache on your phone.


Page Speed: SEO Mythbusting

So by the time the user requests the page, it's content-ustained.


Page Speed: SEO Mythbusting

Yeah, that's true.


Page Speed: SEO Mythbusting

Yeah, so that's another way to scan a cat. No, I'm not supposed to say that.


Page Speed: SEO Mythbusting

Because that's really uncomfortable for cats.


Page Speed: SEO Mythbusting

Uncomfortable for cats, yeah.


Page Speed: SEO Mythbusting

So take it the way I meant it.


Page Speed: SEO Mythbusting

I get it, I get it.


Page Speed: SEO Mythbusting

So anything else around page speed where you're like, what's happening there?


Page Speed: SEO Mythbusting

Any questions you have on page speed?


Page Speed: SEO Mythbusting

I mean, really, I guess it's reasonable to presume that there's not any prospect of Google


Page Speed: SEO Mythbusting

dialing up that ranking notch. It's basically you're kind of set with what you've done.


Page Speed: SEO Mythbusting

I mean, I know that algorithms change all the time.


Page Speed: SEO Mythbusting

Algorithms change all the time.


Page Speed: SEO Mythbusting

But just from the logic perspective, the issue that we talked about already


Page Speed: SEO Mythbusting

between the relevance of the content being king, it's still going to be king.


Page Speed: SEO Mythbusting

Absolutely, absolutely.


Page Speed: SEO Mythbusting

You have to deliver the right result.


Page Speed: SEO Mythbusting

You want the relevant content first.


Page Speed: SEO Mythbusting

If you have five right results, then maybe it nudges something up.


Page Speed: SEO Mythbusting

Yeah, like if you have two results that are basically doing fine content-wise,


Page Speed: SEO Mythbusting

we would probably get the one that is faster, more for prominence in the search results.


Page Speed: SEO Mythbusting

And also, I think it's important to understand that we are not doing it by score or lighthouse


Page Speed: SEO Mythbusting

or something like that.


Page Speed: SEO Mythbusting

It is more we are bucketing pages into like, this is a programmatically slow one,


Page Speed: SEO Mythbusting

this is an OK one, and this is a fast one.


Page Speed: SEO Mythbusting

You see that in the speed report as well in the search console.


Page Speed: SEO Mythbusting

Right.


Page Speed: SEO Mythbusting

I think people need to just figure out if they have really slow pages,


Page Speed: SEO Mythbusting

how to make them faster.


Page Speed: SEO Mythbusting

And probably if they're in the middle bit, you also want to go to the fast bit.


Page Speed: SEO Mythbusting

But it doesn't matter if you have a lighthouse score of 90 or 95.


Page Speed: SEO Mythbusting

That doesn't really make a difference.


Page Speed: SEO Mythbusting

All right, Eric, thank you so much for being here and talking all things space speed with me.


Page Speed: SEO Mythbusting

That was amazing.


Page Speed: SEO Mythbusting

And I hope that everyone liked it.


Page Speed: SEO Mythbusting

And leave comments and likes with us.


Page Speed: SEO Mythbusting

And thank you very much.


Page Speed: SEO Mythbusting

Hope you all enjoyed it.


Page Speed: SEO Mythbusting


Search Status Dashboard

Hello, and welcome to another episode of the Search


Search Status Dashboard

Off The Record, a podcast coming to you from the Google Search


Search Status Dashboard

Relations team, discussing all things search


Search Status Dashboard

and maybe having some fun along the way.


Search Status Dashboard

My name is John, and I'm joined today


Search Status Dashboard

by Lizzie and Gary, who are from the Search Relations


Search Status Dashboard

team, of which I'm also a part of.


Search Status Dashboard

So in today's episode, we're going


Search Status Dashboard

to be talking about the Search Status Dashboard.


Search Status Dashboard

So Gary, you've been working on this for a while.


Search Status Dashboard

Can you tell us a bit more?


Search Status Dashboard

Yes.


Search Status Dashboard

All right, and that was it for today's episode.


Search Status Dashboard

The shortest episode yet.


Search Status Dashboard

Well, maybe we should talk about this a little bit more.


Search Status Dashboard

So can you tell us why we have this dashboard now, Gary?


Search Status Dashboard

Is it because we just don't like posting things


Search Status Dashboard

on Twitter or on our blog?


Search Status Dashboard

Or what is the reason for this dashboard?


Search Status Dashboard

Well, one of the reasons is that we promised it in 2019.


Search Status Dashboard

We said that we would have a dashboard?


Search Status Dashboard

Well, we said that we would have a more structured and better


Search Status Dashboard

communication channels for search incidents.


Search Status Dashboard

So that was one of the motivations for the dashboard.


Search Status Dashboard

Oh, cool.


Search Status Dashboard

So there was a lot of outrage when this initially happened?


Search Status Dashboard

Or why did we say we were going to do more?


Search Status Dashboard

Well, there was a perception that we are not doing enough.


Search Status Dashboard

So we kind of both internally and externally,


Search Status Dashboard

and then we kind of wanted to fix that.


Search Status Dashboard

Because I was told that we have to be nice.


Search Status Dashboard

And yeah, we started communicating more


Search Status Dashboard

about these incidents first on Twitter,


Search Status Dashboard

but that comes with some overhead.


Search Status Dashboard

Because, well, one thing is that for me,


Search Status Dashboard

logging into Twitter takes like half an hour.


Search Status Dashboard

And by then, the incident might be over.


Search Status Dashboard

Wow, they closed that fast?


Search Status Dashboard

Well, some incidents, yes.


Search Status Dashboard

Or maybe I was just exaggerating.


Search Status Dashboard

Never heard of it.


Search Status Dashboard

Yeah.


Search Status Dashboard

I can't believe that.


Search Status Dashboard

Well, but the actual posting is not that long.


Search Status Dashboard

It's actually coming up with the wording.


Search Status Dashboard

That seemed to trip everyone up.


Search Status Dashboard

In previous times, we've talked about this


Search Status Dashboard

as like, what should we say, and how to say it,


Search Status Dashboard

and when to say it.


Search Status Dashboard

Yeah, that's the other thing.


Search Status Dashboard

That on Twitter, we were not using templates.


Search Status Dashboard

So basically, every time on the spot,


Search Status Dashboard

we came up with something.


Search Status Dashboard

And then if someone was around, like John or you or someone,


Search Status Dashboard

as in John Miller.


Search Status Dashboard

Not the other John.


Search Status Dashboard

Then we would double check, basically, a peer review.


Search Status Dashboard

And then we would post if it looks good.


Search Status Dashboard

I mean, but this wasn't just like a peer review thing.


Search Status Dashboard

There are way more people involved


Search Status Dashboard

for these big messages.


Search Status Dashboard

That also depended on the message.


Search Status Dashboard

Yeah.


Search Status Dashboard

Because sometimes you just don't have time for that.


Search Status Dashboard

So you were trying to rush it out


Search Status Dashboard

because you already saw that things are burning


Search Status Dashboard

and people are getting upset about it.


Search Status Dashboard

So if the incident was just annoying


Search Status Dashboard

and just wanted to let people know


Search Status Dashboard

that we are looking into it, then we


Search Status Dashboard

could have said that, I don't know,


Search Status Dashboard

we are looking into some reports about indexing delays


Search Status Dashboard

or something like that.


Search Status Dashboard

And that doesn't necessarily need that many approvals.


Search Status Dashboard

But I would be absolutely comfortable with just


Search Status Dashboard

a sign-off from John and just posting on Twitter.


Search Status Dashboard

But if it was something more elaborate, something


Search Status Dashboard

that is affecting more sites or something that's affecting


Search Status Dashboard

search users, for those, we definitely


Search Status Dashboard

would have needed approvals from more teams,


Search Status Dashboard

including the site reliability engineers, the SREs that we


Search Status Dashboard

have.


Search Status Dashboard

Because they need also to confirm the nature


Search Status Dashboard

of the incident.


Search Status Dashboard

Basically, we also want to be accurate with the reporting.


Search Status Dashboard

And most of the time, we can understand what's happening.


Search Status Dashboard

But sometimes it's more obscure, I guess.


Search Status Dashboard

Yeah, I mean, that's a good point because is it still


Search Status Dashboard

useful if we just say something generic?


Search Status Dashboard

There's an issue.


Search Status Dashboard

And we don't say anything more about it.


Search Status Dashboard

Is that not helpful to people?


Search Status Dashboard

So by giving what level of detail is appropriate


Search Status Dashboard

and helpful?


Search Status Dashboard

I think that depends on the incident.


Search Status Dashboard

Because if the incident is something


Search Status Dashboard

that is going to go away in five minutes,


Search Status Dashboard

we know it's going to be fixed in five minutes,


Search Status Dashboard

then we might not even need to say anything.


Search Status Dashboard

Because you also don't want to overcommunicate things


Search Status Dashboard

because that would just fill up the feed with random,


Search Status Dashboard

oh, we are looking into this.


Search Status Dashboard

Oh, we are looking into that.


Search Status Dashboard

Oh, we are looking into this.


Search Status Dashboard

We are looking into that.


Search Status Dashboard

It's kind of pointless.


Search Status Dashboard

It could also cause confusion.


Search Status Dashboard

Yes.


Search Status Dashboard

If it's not actionable for anybody to do anything


Search Status Dashboard

or it's not noticeable to you, why would we cause panic?


Search Status Dashboard

Or I don't know.


Search Status Dashboard

Yeah, and then we would check in with our SREs


Search Status Dashboard

and confirm that it is actually an incident that we should


Search Status Dashboard

communicate externally, which again, takes time.


Search Status Dashboard

So yeah, Dashboard and the procedures


Search Status Dashboard

that we defined for the Dashboard kind of fix this.


Search Status Dashboard

So it makes things a little bit easier and more streamlined


Search Status Dashboard

to talk about, I don't know, when something weird happens


Search Status Dashboard

around search.


Search Status Dashboard

Would that also include things like my blog


Search Status Dashboard

is not ranking anymore?


Search Status Dashboard

It must be an error on Google's side.


Search Status Dashboard

John, your blog is not ranking for other reasons.


Search Status Dashboard

OK, that's not very helpful, Gary.


Search Status Dashboard

I'm not here to be helpful.


Search Status Dashboard

Wait.


Search Status Dashboard

So I guess this would be more for bigger issues


Search Status Dashboard

than when your blog goes down in ranking.


Search Status Dashboard

Also, no.


Search Status Dashboard

Spamiguy.com is not an important website, I think.


Search Status Dashboard

But if many sites are affected, I


Search Status Dashboard

don't want to make a mistake.


Search Status Dashboard

If many sites are affected, I don't want to make up a number,


Search Status Dashboard

but lots of sites are affected by an incident,


Search Status Dashboard

then that would trigger our procedures


Search Status Dashboard

of externalization and potentially posting


Search Status Dashboard

something on the Dashboard.


Search Status Dashboard

So it's basically more of a way of letting people


Search Status Dashboard

know that we're aware of an issue,


Search Status Dashboard

we're working to resolve it.


Search Status Dashboard

It's not something that the site itself needs to resolve.


Search Status Dashboard

Yes.


Search Status Dashboard

Don't really need to change anything.


Search Status Dashboard

If they see something weird during this time,


Search Status Dashboard

just be patient, I guess.


Search Status Dashboard

Yeah.


Search Status Dashboard

Well, I mean, it should be a little bit of a relief.


Search Status Dashboard

It's not anything you did wrong or that you


Search Status Dashboard

need to fix if it's something that's


Search Status Dashboard

wrong with our systems.


Search Status Dashboard

I think there will still be sites


Search Status Dashboard

that will think that they are affected by an incident,


Search Status Dashboard

but they are not.


Search Status Dashboard

Oh.


Search Status Dashboard

I mean, we see this with ranking updates


Search Status Dashboard

where a site goes down in rankings