And decent amount of search volume for the keyword.


English Google SEO office-hours from September 25, 2020

And then I verified the SERP on Google Search Console,


Third Party SEO Tools, and then asked several people


to verify the position.


And does the ranking or the feature snippet


mean anything, or just Google indexing doing its work?


And can I assume that at least the post


is eligible for the feature snippet position


or the top ranking eventually providing everything


remains the same?


Thank you.


It's hard to say.


So it can happen that a piece of content


appears very visibly in search in the beginning,


and then it settles down into a lower state.


It can also happen that a piece of content


starts off kind of low and over time gets a higher ranking.


And both of those situations are, from our point of view,


essentially normal.


So that's something where I wouldn't necessarily


say there's a technical issue on your website


or there's something problematic with those pages.


It's essentially just how ranking works.


And it can happen that it goes back up, that over time we see,


actually, this is a fantastic article.


We should be showing it more.


It can happen that we show it as a featured snippet.


It can also be that we show it as a featured snippet,


even if it's not ranking first.


So all of these things are possibilities.


One thing that I would generally recommend


if you care about the visibility of this article,


don't just kind of take it and say, oh, I'll leave it


as it is and hope that something changes in the future.


But rather, if you care about it,


then continue working on it and continue


trying to make it better so that when we look at it again,


we see, well, there's a lot of new information here.


There's something really useful here


that we do need to show more visibly.


Thank you so much.


Sure.


John, good morning.


Hi.


Yeah, I've submitted a question regarding


website with separate mobile version and three language


versions.


And the problem is that in the desktop search,


Google shows mobile URLs for the most important keywords.


And despite alternate and rel canonical are set correctly,


in the Google Search Console, no impressions


for the mobile URLs are shown.


In addition to this, for some German searches,


English URLs show up in the search.


And hroflang is implemented for every language.


So I'm wondering what could be the problem here.


OK.


I cheated.


I looked at your issue beforehand.


Just so the people who are watching this


don't think I have a crystal ball.


And essentially, what is happening in your situation,


you have the mobile version with separate mobile URLs


and the different language versions.


And you have different language versions


for both desktop and for mobile.


And what is happening is your site


is switched over to mobile first indexing.


So the primary version that we index for your pages


is the mobile version.


So kind of the m dot version of the pages.


I think you call the mobile in the subdirectory or something.


It doesn't matter, m dot or something else in between.


So this is the primary version that we index.


In general, when we recognize there


is a desktop and a mobile version,


we will swap out the URLs in the search results appropriately.


However, also when we recognize there are different language


versions, so using hroflang, for example,


then that's something where we would also swap out the URLs.


So what is happening here is we swap out


the URLs for the different language version in your case,


and we don't swap out the URLs for the desktop mobile version.


So what is happening there is basically in Search Console,


we count it as an impression for the primary version


of the page.


And we swap out the language version,


and we show that to the user.


And that's the mobile German version


or the mobile English version.


And that's essentially what is happening there.


From talking with the mobile-first indexing


and the internationalization team,


they don't feel this is critical enough to really work on


and say, oh, we need to change our algorithms


to figure this out better.


But rather, what they recommend is


that if you have a separate mobile version


and a separate desktop version that you redirect


on both of those.


So if a mobile version goes to the desktop page,


redirect to the mobile version.


I think you're doing that.


But also, if a desktop user goes to the mobile page,


then redirect to the desktop version.


So if you add that redirect, then even


if we show the mobile version in the search results,


people will go to the appropriate version


of the site.


SPEAKER 1 OK, thank you.


I think that's really tricky.


I didn't see that in particular for your site.


But I suspect that's for the brand name or the city name


that you have there.


Now, I think that's really tricky there


because it's hard for us to recognize


that this query is in German or in English


because you're searching for that specific name.


And it's the same name in English and in German.


So we probably primarily think, oh, the user settings


are in German.


We'll try to show the German page.


But it could also be that the user is searching in English.


We can't completely tell just based on the query.


SPEAKER 2 OK, thanks a lot, John.


SPEAKER 1 Sure.


SPEAKER 3 Hi, John.


Hi.


SPEAKER 4 Starting September 22, our new articles


have stopped in this indexing.


And old articles are disappearing.


When I check on inspection tool, it says duplicate cannot heal.


And Google has picked a completely different URL.


So we have our traffic has stopped.


Yeah, I don't know where specifically


that would be coming from.


So that's something where it would


be useful to maybe have a forum thread with the details.


SPEAKER 3 Yeah, I commented here.


OK, cool.


If you can drop the link to the forum thread in the comments


here, I can take a look afterwards as well.


SPEAKER 3 Yeah, thanks.


Sure.


SPEAKER 4 Hey, hi, John.


I need your advice on something related to images.


So we got a lot of images on our website.


And our pages load quite quickly on the normal networks


or faster networks.


But if the user is coming from a slower network,


say 3G network, so the page takes a lot of time


to fully load something somewhere around five


to six seconds.


So we're trying to fix this issue.


And one of the solutions that Tech Tim suggested


is that what if we just don't show those images to the people


who are coming from slower network.


So I need your advice.


Can this impact our SEO?


Not or probably not directly because Googlebot


will probably be crawling with something


that you recognize as a kind of higher bandwidth connection.


But what you can do in a case like this,


instead of trying to recognize the user is coming


from different locations, use something like,


I forgot what the name is.


When you have different image files for the same image,


I think a source set is how you implement it.


That might be something that you could implement there.


So that instead of not showing the image at all,


you just have a very low resolution version


of that image.


I'm not completely sure how you would implement that just


on the speed of the connection.


But that might be something to look into there.


Sure, I'll try.


Yeah, but also, if you really recognize


that these users can't use the full content of your pages,


then showing them a limited version is fine.


Yeah, maybe that.


Yeah, images are just part of the content just to show.


The text part is there just to show


that the content is rich, because we got a games website


and images are part of that.


Yeah, I think if the images are critical for your pages,


then I would find a way to show them in any case,


even if you have to show lower resolution


or do something fancy that people click


to get the full version.


If images are just decorative on your website,


then that's something I wouldn't worry about.


But in particular, if people go to your pages


and they go there because of the screenshots that you show


or because of the images that you show,


then it shouldn't be that those images are just not shown.


Sure.


Thank you.


I think, Dejan, you had a question.


We can't hear you.


I don't know if your microphone is off.


Ah, I can't hear you.


OK, maybe you can type it into the chat


or we can try again later.


OK.


John, can I just follow up on that page speed image question?


Is it still the case that in Insights, one


of the things that suggests your images is using


the next gen formats?


And yet, until recently, I haven't looked recently,


but they weren't really supported


by a lot of the browsers.


It seemed to be that you were suggesting one thing,


but browsers said, no, we don't like those.


Is that still the case, or has that been updated?


I don't know which formats are currently listed there.


So I think one of the newer formats was WebP.


And I believe that's supported everywhere.


But if you use, I forgot what the name was.


I think it's a source set for images.


If you specify different image files there


with different formats, then the browser


can pick the format that works for them.


So even if you have one version with WebP


and the other version as a GIF or JPEG or something,


then the browser will pick which one works best for them.


So that means for things like modern browsers,


like Chrome, where we would pick up the speed,


we'd be able to use the fast images.


And if the browser has to use one of the fallback versions,


then that still works.


But it also means that you have to generate your images


in different formats and sizes.


So it's a little bit extra work.


Some CMSs probably make that a little bit easier.


OK.


Cool.


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


And we'll definitely have more time


afterwards if people want to hang around, ask more questions.


Let's say we have a good article that we


want to publish on several high-traffic websites.


So we send the article to the owners of those sites,


asking them to publish it.


Afterwards, 10 out of 30 websites publish our articles.


But we also notice some unwanted websites


have taken over the article and published it as well.


So how does Google treat the backlink


from the unwanted websites?


Can this backlink harmless?


Should we disavow it?


Or is it considered a natural behavior in the eyes of Google


and we should just keep the link and the article there too?


So in general, we recommend not doing guest posting


for link building.


So that's something where if you're really only sending


this article out and trying to get it to other sites


to get a link from that, that's something that, if done


on a high scale, is something that the Web spam team would


look at and say that this is not a collection of natural links.


And maybe algorithmically or manually,


we have to take action there.


So that's kind of the first thing there.


In general, though, if you do have one article


on multiple websites, then we will


see that article on those multiple websites.


And we will see those links there.


And if these are on websites that you don't kind of want


that to be published on, then it's kind of up to you


to take action there.


And that can be using the disavow tool if you want.


That might be contacting a site owner


and asking them to take it down or using the DMCA process.


That's essentially up to you.


The second part of the question is,


how does Google treat the 10 out of 30 webmasters that decided


to publish the same article?


Is it considered duplicate content?


Yes, of course it is duplicate content


because it's the same article.


So essentially, what would happen in the search results


is we would recognize that it's the same article being


published multiple times.


And we would try to pick one of them


to show in the search results.


And it can be that we show a version on one other person's


website.


It can be that we show the version from your website.


It's not guaranteed that we would always show


the version from your website.


So if you syndicate your content,


then you kind of have to live with the aspect of, well,


maybe Google will show a syndicated version instead


of your version.


And essentially, the way to prevent that from happening


is not to syndicate your content.


When auditing links for my client's websites,


I see some naked URLs that are pointing to valuable resources


on the site.


How does Google treat such links when there's no anchor text?


So I think by naked URL, it's basically


just someone is linking with the URL as the anchor text.


So in that situation, we see that URL as the anchor text.


From what I understand, our systems


do try to recognize this and say, well,


this is just a URL that is linked.


It's not that there's a valuable anchor here.


So we can take this into account as a link,


but we can't really use that anchor text for anything


in particular.


So from that point of view, it's a normal link,


but we don't have any context there.


Yes?


Can Google get context for the text around that link,


maybe, if it doesn't have any?


Sure.


But that's more secondary, that really strong piece of context


from the anchor text that's missing in that case.


And then small things around the side,


that does help us a little bit.


But really, the primary aspect of that link is kind of gone.


And usually, that doesn't matter.


It's not that it counts against your website in any way.


It's just, well, for this particular link,


we don't really know what the context is.


All right, I'm asking since the majority of organic links,


so to speak, usually use either branded anchor text,


like the brand name of that website, or something


like the URL or nothing, specific no keyword,


specific keywords being used.


So since that is the case, since the majority of the links


that point to a website aren't really


specific around the keywords that


are related to the website, does Google


use the content around or the topic of the article


where that link is, or things like that?


Yeah, that's something we do definitely take into account.


But it's very secondary.


So there is no value of strength for the context there.


But I'd say it's like that anchor text is really obvious.


And we can collect that.


And we can look at that overall.


And the context of the linking pages


is something, well, we also need to think about at some point.


But the anchor text is really the primary thing.


Right, but it's also the anchor text that also points you


in cases where that link doesn't seem to be very organic,


because it's very like that's that.


Sometimes, yeah.


I recently changed the layout, look and feel, of my blog


and moved away from WordPress and now using


Hugo static site generator for publishing my post.


Does the change in layout impact my ranking and search results?


On this side note, there's no change


in content and the URL structure.


It's still the same as before.


So changing the layout of your pages


can affect your search results.


So this is something that some people work on actively


as well with regards to on-page SEO.


So things like figuring out how to use titles properly


on a page, how to do internal linking properly,


how to provide more context for the article itself, all of this


can definitely affect SEO.


So just because the primary content, like the blog posts


that you have, and the URLs themselves don't change,


doesn't mean that there's nothing else around all


of that that search engines won't be able to pick up on.


So it can definitely affect SEO.


And it can be a good thing.


It can be a bad thing.


So it's not that you need to avoid making these changes,


but rather, when you make these changes,


make sure to double check that you're kind of doing everything


really well.


My blog traffic is 99% from desktop,


and I get very rare traffic from mobile and tablets.


But sometimes, I see the mobile usability issues,


like clickable elements too close.


Should I be concerned more about that?


Will it put a negative impact on my site's ranking or search


results for desktop?


I optimized my website for mobile,


and it's responsive as well.


So I think this is one of those aspects where sometimes


our systems see fluctuations in how we process the pages.


And that can result in things like the mobile usability


report in Search Console saying, oh, I


found a number of pages that are not really mobile friendly.


And if you check those pages manually


and you see that they are actually mobile friendly,


then I would just leave it at that.


That's basically our systems, for whatever reason,


at one point were not able to render your pages properly.


So we wanted to let you know about that ahead of time.


If you see that the majority of your pages


are recognized as not being mobile friendly,


then I would definitely take a look at that.


If it's just individual pages every now and then,


that's perfectly fine.


With regards to mobile friendliness in general,


with regards to a site that is mostly


visible on the desktop search results,


the mobile friendliness is a factor


that we use in mobile search results particularly.


It's not something that we currently use for the desktop


search results.


So if, for example, your site were actively not


mobile friendly, like you never worked on mobile friendliness,


and it's a table-based layout, and you have to zoom in,


and everything is really hard to use on mobile,


but nobody is searching for your site on mobile,


then that's also kind of fine.


The thing to watch out for there,


though, is it might just be that nobody


is using your site on mobile because it's not


mobile friendly.


So that's one of the things, especially in the beginning,


as everything around mobile came up.


Even on the Search Console side, the Search Console team


was like, well, we don't have to make our site mobile friendly


because nobody is using Search Console on their mobile phone.


And of course, if you can't use it on your mobile phone,


then nobody will use it.


So you kind of have to avoid running into that situation.


I've been a webmaster and SEO professional since 2001.


I have a hypothesis that I'm hoping you can confirm or deny.


Uh-oh.


I'm wondering if referral traffic


from organic backlinks and referring domains


play a part in the legitimacy, trust, and authority


when it comes to the page rank algorithm.


It seems to me that a backlink that is never clicked on


would be less useful than one that does.


Therefore, a backlink that is actually used by visitors


may be counted or regarded with higher trust or authority.


And since the purpose of the backlink is to drive traffic,


if some backlinks never drive traffic by way of referrals,


why would they matter?


Yeah, I think this is an interesting question.


It comes up every now and then.


Essentially, in our algorithms, we don't look at that.


So it's not that we kind of monitor


what people actively click on and see how the traffic goes


back and forth.


There are lots of reasons for traffic


to go to a website that is completely unrelated to SEO.


So from that point of view, it's something


where I think, as a site owner, it's


useful to think about where your traffic is coming from.


And if you see a lot of your traffic


is coming from some particular sites,


then that might be a sign that maybe there's


something you can do together with that website


to make it work even better.


Maybe that's a sign you could work with other websites


to make it better there.


Maybe it's a sign that there is a large overlap of audience


between those two websites.


But just because there's traffic coming


or there's no traffic coming from individual links


doesn't play a role in our algorithms.


In particular, with regards to page rank,


page rank is really kind of a simple algorithm


that is just complicated because of the scale of the internet.


But that's something where we try to essentially just focus


on the link.


So it's not that there is anything special also


kind of flowing into that.


So from that point of view, if you have links to your site


that nobody is clicking on that can be perfectly fine,


it can also be something where you might say, well,


why do I have these links from these sites


if nobody is actually using them?


Then maybe that link is just hard to find.


Or maybe there's kind of a mismatch


with the audiences there.


But essentially, that doesn't play


into the SEO side of things.


If my original site is faster than the AMP version,


do you still recommend having an AMP version?


That's an interesting question.


So I think if you have a site that


is faster than the AMP version, then to me,


that would point at the AMP version being


kind of a suboptimal version.


Because in general, AMP is really


optimized for really fast delivery,


especially if you're using the AMP cache.


If something is being served from the cache directly,


then from my point of view, unless you're


doing something really weird with those AMP pages,


that should be really fast.


That said, there are multiple reasons to use AMP.


Speed is definitely one of them.


If speed is the only reason that you're using AMP pages,


then of course, feel free to just use your own version.


That's something where it's really up to you.


Other people might decide to just say, well,


I will just use the AMP version and make my AMP version


the fastest one possible so that you don't


have to work on both of them.


That's also a way to kind of deal with that.


But in general, if you really are only doing AMP for speed


and your normal responsive pages are just as fast or faster


than your AMP versions, then that


seems like one place where you could optimize.


With regards to some of the features


where we do show AMP pages, that's


something where we recently announced with, I think,


the page experience ranking factor


that we would start taking into account pages that are not AMP


as well, provided they kind of reach that same threshold


with regards to the core web vitals.


So at some point in the future, it's


not the case at the moment for things like the top stories


feature.


If your pages are really fast and they kind of


reach the core web vitals factors,


then we would also show them there,


even if they're not AMP versions.


What is Google's vision of the future of its search engine?


There have been multiple, there have


been a few changes in recent times with all the extra boxes


in the search results page that make me wonder


what they're driving towards.


They seem to me to be aiming at or preparing


something new for the future.


Wow, I don't know what the big future vision


is with regards to search.


It feels like we could probably have a long session just


speculating on different topics.


So I don't really know what I can tell you here.


I think the important part to keep in mind


is that we make changes all the time.


And we try a lot of things out, as I think pretty much


every website should do.


And that's something where if you try a lot of things out,


if you try some risky things along the way as well,


then you'll see which things work out


and which things don't work out so well.


So for example, for last year, I think, I don't know,


we did over 100,000 tests and experiments


with different things over the course of a year.


And it led to something like, I don't know,


3,500 changes in the search results.


So that's something where it's like you


say you've seen a few changes in recent times.


There are lots of changes happening all the time.


Some of those changes are very small,


that just small pixels shift around


or the colors slightly change.


Some of them are fairly visible.


And we have to keep testing.


We have to keep improving things because people online,


they expect even better things all the time.


It's not the case that you can just keep one thing stable


and it'll be relevant forever.


How does Google treat blogs that are built on expired domains?


Is it a recommended practice?


So in general, I wouldn't recommend


using expired domains as a way, as a kind of an SEO strategy.


That seems very risky.


Sometimes these domains, on the one hand,


can be quite expensive.


Sometimes you might be getting a lot of extra cruft


with that expired domain.


So we do try to recognize when a new site is being built


on an expired domain.


And we try to ignore as much of the past as possible.


However, if the old version of the site that


used to be there on the previous owner


was something that was really problematic, for example,


they built a lot of links in ways


that were against our webmaster guidelines,


then that's something that can still


be associated with your website.


And that's something that you probably


need to clean up before you can really


be sure that you're starting with a clean slate.


So my recommendation there would be, as much as possible,


if you really want to dive all in on a domain name,


then investigate its past so that you kind of know


what you're getting involved in.


And if you're doing this just to kind of try something risky


and you don't need to rely on it for your business,


then feel free to try things out.


But if your business really relies on it,


then investigate the past and make sure


that you understand what it is that you'll


need to clean up at some point to get back to a clean slate


and whether that's worth it for you overall.


SPEAKER 2


That's sometimes really hard to tell because of the way


that the registrars work and what information they


provide publicly.


So that's what we try to recognize


is there is essentially a new site here.


And we also try to recognize situations


where people take an expired domain,


they go to archive.org, and they download


the old version of the site.


And they put it back up.


And they add five new links along the way


and try to make it look like, oh, this is just like,


you know, I forgot to renew my domain.


And it's all the same now.


I don't know.


It's been a practice since forever.


But these are things that we try to recognize from a web spam


point of view and also just generally


from a general ranking point of view


to make sure that as much as possible,


people can reuse domain names, but also


that the cruft and the extra value that


was associated with the old domain


is kind of neutralized as much as possible.


Sometimes we can't do that completely.


If there are really lots of problematic links there,


then sometimes that's just kind of like but less like.


AUDIENCE 1.


Are you trying to neutralize problems or neutralize


benefits?


Because if you're in the real world, if you own,


I don't know, a restaurant chain and you buy another restaurant


chain, and you then have more sites,


you might want to close some and just merge them,


fire half the staff, and get economy to scale.


Why is that not the case in the online world, where you still


have all of those links coming in which are now


pointing to your new business and offer the same value


if it's a genuine takeover?


You're diminishing the value in the business


you've just purchased for no reason.


Yes.


It's hard.


I mean, a lot of these, so what we do try to recognize


is when things are essentially kind of just being taken over


and the business continues to run normally, where essentially


it's just kind of like a change of ownership situation,


but it's essentially the same business.


That's something we do try to say,


well, that seems like a reasonable change.


That can happen.


But a lot of times, the reuse of expired domains


is essentially like one business goes bankrupt,


and the business stands still for a while,


and then someone else goes there and says, oh, actually,


I'm Rob's business, and I'm just the new owner kind of thing.


Treat me as if I were still a legitimate business.


Which isn't that right, though?


Benefit in buying bankrupt assets.


It's tricky.


I wasn't planning on doing this, by the way.


It just feels like a real world situation is usually


the best way to judge an online situation.


Would you do it in the real world?


No, then probably don't do it.


Yeah.


I think it's also something that we just see at scale a lot


of times, that people go off and it's like, oh,


I can buy 1,000 expired domain names,


and I'll look up the links to those domain names ahead


of time, and I'll just buy them all


and redirect them to my site.


That's something where, from our point of view,


it's not that your site has gained any value, any more


relevance because of that.


It's really just, well, you're taking a lot of expired domains


and then redirecting them to your site,


and that's something we shouldn't really kind of treat


as being a part of your site.


I can see both sides, but it's something


where the legitimate side, where it's


a, like, this matches kind of like what would happen


in the offline world, and your business


should be able to do this.


That's something that is significantly


rarer than the other side, where people just take expired domain


names and try to reuse them.


Right, because the barriers to entry in the online world


are almost zero, where it takes some effort


to go buy a bankrupt business.


Yeah.


Yeah, probably.


It's a strange business in the real world.


And this is something that sometimes has really weird


effects in that people will buy expired domain names


from conferences where it's like, I don't know,


some scientific conference 2014, and you go to the website,


and they're selling, I don't know, fitness equipment now.


And you're like, OK, why?


Why did you essentially act like you're in a conference,


but you're selling something completely different now?


Yeah, but that would be the same in the real world.


If I bought a restaurant chain and turned it into a gym,


I wouldn't expect to still serve restaurant customers.


Yeah, but I mean, in that case, you would be like, well,


actually, it's a gym now, and you


can't kind of build off of the reputation


you have as a restaurant.


I mean, I'm sure there are ways you could twist that and say,


like, well, actually, this is the gym for the old restaurant.


I don't know.


OK, well, yeah, I think with expired domain names,


it feels like one of those topics


that there's so many different aspects there, but no.


OK, let's see.


In my search console, I am noticing a continuous decrement


in mobile-friendly pages.


When I inspect the pages in mobile-friendly testing tool,


all of my pages were mobile-friendly.


I haven't changed anything on my site.


What's the reason behind the continuous decline


in mobile-friendly pages on my website?


What should I do to overcome that?


So one of the things to keep in mind


is that the aggregate reports in Search Console,


like the mobile-friendly report, the structured data report,


I think the speed report as well,


they're based on a part of your website.


So it's not that these are all of the index


pages from your website or that it's your whole website that's


listed there.


It's just a sample of the pages from your website.


And it can happen that that sample becomes smaller.


And that doesn't mean that you have fewer pages


that are mobile-friendly.


It's just in that report, we're just showing


fewer pages in that report.


And what I would recommend doing there


is continue to double-check your pages individually


so that you're sure that things are OK.


But if you don't see a rise in errors in that report,


then I would just assume that, well, for this sample,


we've determined that these are all mobile-friendly.


And we might be showing you a smaller sample of pages there,


but that's perfectly fine.


So in short, this is not something


that you need to fix in any particular way.


Just make sure that that sample is all OK,


that things are OK there.


How deep is the bond between Top Stories and Google News


old algorithm?


I see Top Story being tested in the News tab on Search.


I don't know what you mean with how deep


is the bond between these different elements.


We do have different elements that we


show in the search results.


And I could imagine that we would


show some of these across the News in Search


and maybe also in Google News as well.


So from that point of view, it's not


that there is a deep connection between all of these things


or anything that can be quantified.


It's just for practical reasons.


If we recognize that one UI element works really well


for users, maybe we'll use it in other places.


So that's something that can happen.


Our website was affected by a hack,


and we've been dealing with it on and off for two weeks.


Things got cleared out.


And when they popped back up, we're


in the clear now from the hack.


But I've noticed our ranking has dropped


for some of our strongest keywords during all of this.


What are some best practices I should


be following to get our site to be viewed as reputable


by Google again quickly?


Do I need to resubmit the site map since one of the hacks


messed with ours?


I repaired with it, but I'm not sure if I should resubmit.


I would definitely resubmit the site map


because that's just generally something that helps us


to understand your site better.


And if you're using a common CMS to generate that site map file,


then probably it's already been resubmitted automatically.


So probably that's already OK.


In general, if you're faced with a situation where someone


is actively hacking your website for a longer period of time,


and I think two to three weeks or so


is something I would kind of quantify


as a longer period of time, then it


would be normal for our algorithms


to be a little bit confused about what


it is that you're trying to host on your website


and what you want to rank for.


So that's something where I can definitely


see our algorithm saying, well, we don't really


know what we should be showing this website for.


And probably during that time, the ranking for the keywords


that you do care about goes down.


It's possible that maybe ranking for keywords


that you don't care about goes up.


In particular, people add things to your website.


So if a hacker is using your site


to not redirect to other people's sites,


but rather to host kind of hacked content,


then that's possible that our systems will be like,


on the one hand, maybe we'll show you for, I don't know,


athletic shoes because that's what the hacker placed there.


And then when we recognize that it's actually hacked content,


we'll show you for less and fewer of these searches


overall.


In general, the important thing that you really, really


need to do is make sure that you've cleaned up the whole hack


completely, that you've done things like remove any owners


that the hacker has added to Search Console or to Analytics


so that you're really making sure that you're starting


with a really clean slate, make sure that the security


issues that were used to get in are really cleaned up,


and then clean out all of the hacked content.


And that includes checking things


like the server control files, where sometimes there


are redirects that are placed there that are only


visible to search engines.


Also double checking all of the index pages, of course,


so that you're sure that all of those are cleaned up.


And I would also double check your server logs


to make sure that there's really no traffic going to pages


that you don't want to have indexed.


For example, one thing we sometimes see with hacked sites


is that they're used for phishing attacks.


And phishing content is often not indexed by Google,


because maybe it has a no index on there.


But if people are using your site


to host phishing content that they use for Gmail,


for example, then that's something


you might not be seeing directly in your search results.


So all of these things I would definitely clean out.


And once it's all cleaned out, once you've


resubmitted your sitemap file, that's


something where I would say it's probably


a matter of a few weeks or so for things to settle down


again.


And it is frustrating to be hacked like this.


It's something that really pulls things down and is annoying,


and it's hard to clean up sometimes.


But it just takes a bit of time for things


to settle back down again.


But with all of these things, if you do clean up


the hacked content on your site, it will settle back down.


It's not something where Google will hold a grudge and say,


oh, you were hacked once.


Therefore, we cannot trust your website ever again.


Lots of websites get hacked.


That's something that unfortunately happens.


John, I've got a question about site colon searches.


OK.


So we're trying to look at the performance of a particular


product category, a set of product category pages


that would include pagination, would include some facets.


So maybe along with the category,


you have a selection for brands.


And you have a lot of those indexed.


Dozens, maybe hundreds.


And if you were to choose to place a no index


on those pages, would you be sending Google the signal


to then not index the products that exist on those pages?


Well, what would happen to the products that would


be listed on those pages?


So you have a category page and from there,


you link to the product.


You've got a category page about pagination.


Google's indexing all of those pages, pagination,


some facets.


But somebody is concerned that you


have too many of these category pages indexed,


knowing that these category pages have the products listed.


And if you were to no index those pages,


what would be the end result of those products being indexed?


Yeah, OK.


So what would usually happen if you have category pages


and pagination on those category pages and you, for example,


no index everything from page two onwards,


what would usually happen is we would start to drop


those pages from our index.


And when we drop those pages from our index,


we would essentially drop those links as well.


So probably if you put a no index on page two,


then it would be less likely that we would even


go to page three to figure out what is even shown there.


So that's one aspect there.


It's possible that we'd still notice


some of the links on page two, but everything linked


further back would be a lot harder to find.


With regards to e-commerce sites,


sometimes that doesn't matter so much because a lot of times


products are in different categories


or you have products that are cross-linked with kind


of related product links.


So what I would recommend doing there


is first double checking to see that we can still


find all of your products.


But if we ignore the no index pages,


often you can do that with a local crawler or something


like Screaming Frog or some online crawler


to kind of test your site.


And just make sure that with the no index in place,


we can still find all your products.


If we can't find your products with the no index in place,


then that's definitely something to watch out for.


Perfect.


Thank you.


In general, our recommendation, though,


is to allow the indexing of the paginated category pages


and only disallow the indexing of things like facets.


So if you have different sort filters or kind


of different filters for sizes or kind of sub-attributes


of those products, that's something I would no index.


But the main category pages, I would allow indexing of those.


So you wouldn't see value in, again, simplified.


I'm not throwing out all of our facets for Google to crawl,


but just a select few.


So for example, the category and brand combinations,


would you recommend not allowing Google to go to those?


So it can be really tricky with e-commerce


because on the one hand, it's about crawling


to find those pages.


On the other hand, these can also be valuable landing pages.


So if in any case you're saying, this


is a valuable landing page for me,


just like someone is searching for men's athletic shoes


in blue, and this is a really popular query for your site,


then keeping that facet available for indexing


makes a lot of sense.


People are searching for it explicitly.


You have a good landing page for it.


Definitely keep that.


On the other hand, if this is really just for usability,


if nobody is searching for this particular facet


and you just have it for usability there,


then that's something I would disallow indexing of.


OK, thank you.


We can also do canonical tag, right, instead of just


no indexing, basically?


Yeah, I think you can do pretty much both of those.


From my point of view, I think it makes more sense


to use no index for those kind of things


because that gives you a clearer mental model.


What we often see is people use rel canonical on the pages


that they don't want to have indexed,


and from our point of view, we will look at that and say,


oh, you're saying these pages are equivalent,


and we could probably pick one or the other


to show in the index.


And that's not really what you're saying.


You're kind of saying, well, just don't index this page.


So for content that's not really identical,


I would just use a no index and not the rel canonical.


And I'm sure this will lead to lots of long discussions


online now.


Thanks.


Sure.


John, can I try?


Can you hear me?


Sure, yes.


Sorry for the previous problems.


I have a question that maybe has been asked many times.


It's about cloaking.


We have a dynamic website which is not indexed at all,


and in the cache, the text version is completely empty,


which means that I think that maybe I


can take the HTML with property or something like that


and just see if Googlebot or any other bot is coming.


I can serve this page, and for any other,


if it's not Googlebot, I can just give the dynamic


and actual version of the website.


How bad is that?


That's perfectly fine.


So we call that either server-side rendering


or dynamic serving, I think we call that,


depending on how you have that set up.


And that's perfectly acceptable as an approach.


One thing I would just caution against


is just because the cache page is empty


doesn't mean that Google is not able to index the content.


So what usually happens with JavaScript-based sites


is the cache page shows the HTML version of the page


that we have.


And if the JavaScript can't run on the URLs


that we use for the cache page, then it doesn't show any


content.


But you can double-check that by taking some of the content


and just explicitly searching for that in Google.


And if you see those pages showing up,


then that's a sign we can find the content.


And I wouldn't worry about the cache page in that situation.


AUDIENCE 1 No, it was just like an indicator


what is happening, because obviously something is wrong.


I was just curious, can we apply this?


And I just want to safeguard that we are not cloaking,


like accused of cloaking.


Because if we do that, we'll do it with Chrome job


like every 24 hours.


And it won't be fully dynamic.


And every manual check on the web page


will see, OK, this is not what is the life.


Thank you very much, John.


Yeah.


We have that documented.


So if you need to point something


for whoever makes decisions on your website,


we have documentation on that in the Search Developer


documentation on how you can set that up with JavaScript.


So we would definitely not see that as cloaking,


because the content that's shown in the end is the same.


It's just the delivery method is slightly different.


What we would consider cloaking is


if the content is very different.


When you go to the page and show shoes and Googlebot sees,


I don't know, something completely different,


like vacation photos or something,


that would be considered cloaking.


What about if there's some, the content


depends on the app request, does the bot wait?


How long it waits for?


Is it wait for network idle?


We don't have a specific time that we wait there.


We essentially try to see until nothing more changes on a page.


And on the one hand, we have some hard timeouts.


On the other hand, we try to figure out


when things stop changing.


The difficulty with waiting is that we use


a lot of caching on our side.


And we don't run Chrome with the same speed setup


as a normal user would.


So you can't really compare how Googlebot


would wait for that page to how a user would see it.


The Inspect URL tool in Search Console


gives you an idea of what Google would show.


Thank you very much, John, for your answer.


Sure.


I will leave because I'm technically at work, so by all.


Yeah.


Thank you.


Thanks.


Bye.


All right.


Any more questions before we pause the recording?


I have a question.


OK.


With our new site, we have the ability now


to have dates booked.


So there's live inventory of dates.


So in our meta information, that's


now sometimes pulling through, saying,


next available on the 1st of October.


And that looks nice in the search results


because people can probably improve clickthrough


for people that are interested.


But the problem is, obviously, of course,


if that stays there until the 2nd of October


and Google doesn't index it again in the meantime,


then it looks like an expired search result,


and it's probably worse.


Have you seen this sort of thing before


and how any other people deal with that problem, where


there's dynamic content and therefore might


be dynamic meta information?


And so how do people deal with that?


Or can we just ask you to index it every 20 minutes?


Every 20 minutes.


I don't know.


Yeah.


I think that's easy to do on a small website


and really challenging on a large website.


So we see that a lot, or I don't know, a lot.


We sometimes see that with e-commerce websites,


for example.


If they go through and they change their prices


significantly in a short term, like, I don't know,


for Black Friday, suddenly all the prices are 10% lower,


then that's something where we would


need to essentially recrawl all of the products


to see those changes.


And for that, we don't have any special method available there.


It's really in the sitemap file, you


have to tell us this page has changed,


and then we may go off and recrawl that page.


And sometimes we recrawl it fairly quickly


after you tell us about it.


Sometimes we recrawl it a month later.


So that's something where, on the one hand,


you can help us by optimizing what you allow us to crawl.


So having a really clean URL structure


where we don't end up getting lost in variations of URLs


helps a lot.


Having a fast server so that we can crawl a lot helps a lot.


But it doesn't guarantee that we will pick up


all changes immediately.


If you're seeing that this happens regularly


or you make these changes fairly quickly,


like you have something that's not happening next month,


but rather it's always a couple days ahead of things,


then you could also use the data no snippet attribute in HTML,


where you say, well, actually, this particular thing


is something that is very dynamic.


I don't want you to show it in the snippet.


And then you don't have the advantage


of being there with a date in the near future,


but you also don't have the disadvantage


if it's still indexed at some point later on.


And you can use that for dates, for anything on the page.


You can use that for prices, for something that's


shown in the structured data.


For anything that you don't want to have shown in the snippet,


you can let us know about it like that.


AUDIENCE 1. And is there markup for dates


that would help if we really wanted it to be?


There is some markup for dates, but it's mostly


based on what you want to provide as the article date.


So if you're writing a blog post or an article


and you have today's date as a change on there.


For event dates or ticket sellers.


Yeah.


So for events, you could probably use the event markup.


Maybe that would work.


If you have specific dates where you're saying,


this is taking place on this date at that time.


We're pulling the dates through via an API


for live ticketing feed.


So it is accurate.


So we can do that.


That sounds a good thing.


OK.


And with the event markup, if we recognize that,


then we can show that as a rich result under the result.


Sometimes we also show it in the sidebar,


where if you're searching for a specific event,


then in the sidebar it'll be like,


this is happening at that date.


And then it links to your pages.


And then there's specific events because they happen every week.


There's a cooking class every week or a skydive every week.


And yet they kind of are specific


because they're always happening on a certain date.


Yeah.


All right.


Sure.


Thanks.


Maybe we can take a break here.


I'll pause the recording.


If any of you want to stick around,


you're welcome to stay a bit longer.


Thank you all for joining.


I hope you all found this useful.


Lots of good questions here.


So thanks for asking all of that.


And hopefully, I'll see you again


in one of the future Office Hours Hangouts.


Bye, everyone.


Bye-bye.


Site Kit, Web Components, shards and more!

Welcome, everyone, to the next 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 am a search advocate on the Search Relations team


here at Google in Switzerland.


I'm joined today by Martin and Gary,


both also on the Search Relations team.


And we have a special guest today, Maria.


Maria is a product manager on the Search team.


Maria, for those that don't know you yet,


could you introduce yourself briefly?


MARIA MARTIN GORENO-MARTINENO Yes.


MARTIN SPLITTENBERG That was brief.


MARIA MARTIN MARTINENO This is the briefest I can do.


MARTIN SPLITTENBERG Can you elaborate a little more?


MARIA MARTIN MARTINENO Sure.


So I'm Maria, and I'm also based here in Zurich.


And even though I haven't seen you guys in a really long time,


we work together in our little couch, couch gate, remember?


And I work on something called Site Kit.


MARTIN SPLITTENBERG Site Kit, nice.


What is Site Kit?


MARIA MARTIN MARTINENO I thought you'd never ask, Martin.


Site Kit is super exciting.


So if you imagine that you have something


that you want to share online or you want to sell something


online, especially over the past year,


online has been pretty much the only way to do that, right?


So imagine you're a beekeeper, and you


want to find clients for your honey.


You set up a site, but you don't really know how to get started.


You're pretty good at making honey,


but you're not good at websites.


And so it can be really overwhelming


with so many tools and complicated dashboards


to figure out what to do.


So that's why we built Site Kit.


It's an open source plugin, free for WordPress, maintained


and built and continued to be developed by Google.


And it's a way for you, basically,


as a site owner to get the most relevant of Google's tools


directly in your dashboard.


So you don't need to go anywhere else.


You log into your site.


It's already there.


And it has information from Analytics, from Search Console,


from PageSpeed Insights.


So it tries to show you everything about your site,


how people found you, how long they stayed on your pages,


how fast your pages are.


And if you choose to make money with AdSense,


also how much money you make with AdSense.


So think about it a little bit like Swiss Army


knife of Google products directly in your site.


And it's really good for people that


are kind of focused on their business.


And they are on WordPress to kind of promote their business,


but they don't want to deal with super technical things.


So one person that I recently talked to online


is a ski teacher.


And he started a site to share his favorite destinations


in Colorado and also to teach parents how


to teach their kids how to ski.


And he had put some AdSense on his site.


And he was using SiteKit especially


to understand who was coming to his site and how to grow it.


And he was able, over the course of a year,


to make enough money to buy himself


a super fancy pair of skis.


So that's the kind of thing that SiteKit is good for.


It helps you understand what's going on at a glance


and make decisions how to improve your site.


And I'm super excited about having it on WordPress.


I hope that we can build something for other platforms


as well in the future.


MARTIN SPLITT RODERBERG Ooh, nice.


I nearly forgot that you are actually a beekeeper.


How are you bees doing?


My bees are currently sleeping.


They made a little bowl around the queen.


And they basically flipped their wings


to keep the temperature around her very stable.


So they have turned into a little air conditioner for her.


And we're going to start feeding them sugar very soon


because the temperatures are going up.


That is amazing.


I think we're done here, aren't we?


That's the pinnacle of this podcast, probably.


That's the best episode so far.


No?


More.


Right, right.


So Maria, is SiteKit like an SEO tool?


Does it help you to rank better?


Or how would you classify this?


SiteKit is definitely helping you rank better


when it's a leap year and only on full moons.


You will experience about 0.75% improvement


in your average position.


But other than that, essentially, the goal of SiteKit


is to make things simple for you.


So it's not necessarily an SEO tool.


The goal is to bring everything that you


need from Google in one place.


So yeah, it can help you with SEO.


You can see what are the most popular queries.


You can see which are the most popular pages from your site.


Do these things match?


Should you be writing about something else?


So in that sense, you can take some decisions,


but it's not explicitly meant as an SEO tool.


OK, so it kind of makes all of these other tools


a little bit easier to understand.


I don't know.


When I go into analytics, it's always so overwhelming.


And I'm like, oh, I'm so glad to get out of there


as quickly as possible.


But it's still useful to get some information there.


So I guess it makes some of those things


Yeah, we filtered out almost everything.


So you will see very few numbers, and they're very big.


So there is little information on the dashboard


and hopefully only the important stuff.


So you don't have to get lost in reports.


But if you did want to dive deeper,


there are links that can take you to Analytics,


to Search Console, to AdSense, or whatever


you have activated so you can see all the details if you


wanted to.


Or if there's someone helping you with your site,


you could help them and send them there


so they can see the details.


So cool.


And since WordPress is an open source tool, I guess,


or platform, or CMS, I don't know what you call it.


A magic place.


Open source, magic place.


Site Kit is also open source?


Or is this some secret Google box that we just add on top?


Nope, everything is open source.


All the development happens on GitHub.


Everyone can go and complain or add suggestions and comment


and see what we're doing.


And we say, OK, we're going to do this in the next two weeks.


We have a release.


Then we publish exactly what we changed.


So it's super transparent, and it's very clear what's going on.


And I love that about it because everyone can come and see


what we're doing.


MARTIN SPLITTENBERG


And you and the other maintainers


are really, really friendly.


I think, if I remember correctly,


working with you convinced me to actually fix something.


And then I made a tiny little contribution to the plugin.


Oh, man.


I think that was after we were all in Berlin in 2019


for the WordCamp.


And I think, didn't you announce something?


What?


Yeah, I know.


We traveled.


Don't you remember?


People together in a place?


In a closed space in Berlin.


That was amazing.


Man.


That was good stuff.


Wasn't it also where you announced the developer preview


or the developer beta for SiteKit or something?


Because I think we had a booth there.


Yeah, we had a booth, and we announced it.


And many people installed it, even


though it was developed beta.


And here we are now, almost two years later,


with more than a million active users for the stable release.


So it's pretty exciting to see where we're going.


Wow.


Awesome.


That's really cool.


I remember it was my first WordCamp,


and I was so excited for the positive vibe in the community


and how everyone was nice and friendly, which is not


true for all communities, I guess.


I mean, they do have their controversial moments.


I think when Gutenberg launched, I


remember that Felix, for instance,


was super excited about it.


And other people were like, oh, no, we


don't think that's a good thing.


And I think this has kind of been established now


that it's a good thing, and it's based on web components.


And that made me interested, and that's


why I was kind of interested to follow


how they are doing stuff.


What's a web component?


Oh, web components are basically a bunch


of standards that allow you to make your own HTML elements.


So you can basically, within WordPress,


build different things like, I don't know,


an image carousel or whatever as a component


so that you can use it as an HTML tag,


as if it would be a normal HTML tag, like a link or button


or text input.


You can build your own kind of elements,


like a tab box or, as I said, an image carousel or whatnot.


And you don't have to do this with weird hacks.


You do it with mechanisms that are built into the browser,


into the web platform.


And that's actually quite a cool thing to do, I think.


So it's kind of like a Java applet for HTML pages?


No, it's not, because a Java applet towards the web


is a black box, and it's an enclosed, separate thing


that is built with different technologies.


Web components are really just inside the browser.


And if you look at things like input elements, for instance,


or video element, for instance, on a web page, all of these


are, if you inspect the user agent shadow DOM, all of that


is actually built with web components.


So browsers are using web components, at least Chrome,


I'm not sure about the others, are using web components


to build normal HTML components on top of each other.


So that's kind of cool.


So cool.


So you could take an existing web components library


and just add the HTML tags to your pages


and use it like that?


Yeah, yeah.


It does have a few challenges with a few tools,


like Rendertron, which is something that I maintain.


I was having a bit of a hard time in actually rendering


what's inside the shadow DOM, which is unfortunate,


because our renderer at Google Search actually does this.


So in rendering, we can actually see the content inside web


components.


In Rendertron, we are struggling with that at the moment.


So that's an interesting challenge


that I hope to actually address this year.


So we'll see how that goes.


So by the content within the shadow DOM,


you mean kind of like if you have a web component


for a calendar that you'd be able to see the individual


days?


Yeah.


Is it that?


Yeah, pretty much.


All the components that you build your component from,


so let's say it's an image carousel.


Then you have the different images and maybe some buttons


to go to the next and previous image.


And you don't want the outside website to accidentally


do something with it.


For instance, the outside website


says, oh, all the buttons need to be pink and then also really,


really large.


Then somehow, magically, the components buttons


inside the carousel get really big and pink.


That might look really, really weird.


So you want to have some sort of isolation layer, kind


of like a border that can't be easily crossed.


And that's what a shadow DOM provides, basically a black box


towards the outside.


So cool.


And that all works in Google Search, you said?


Or is that also challenging?


That works in Google Search.


We are doing that quite well in the rendering service,


web rendering service more specifically.


But yeah, I'm having a hard time replicating


that behavior in Puppeteer and thus in Rendertron.


OK.


Why?


Or how so?


Oh, that's a really good question.


It turns out that different web components libraries


are using these things slightly differently.


And how do I put this nicely?


Developers are surprisingly creative when


it comes to using things.


And we are using a few very clever tricks


in the web rendering service that are not publicly


documented and are actually not really


in the public versions either.


That's basically custom patches.


There is a feature that I think looks promising to do that,


which allows you to actually traverse the shadow DOM


boundary and then also extract the internals.


But I haven't really tested this.


And the last time I tested it, there


were a bunch of developers that worked with the web component


standards in ways that would break even that mechanism.


So I'm like, ah, there must be a better way.


So yeah, we'll see if we can open source


more of the things that we do.


But then if you can descend into the shadow DOM,


then isn't that a fault of how shadow DOM is set up?


I mean, the reason you have a shadow DOM


is to not let third parties to descend into them.


That's a very good point.


And it's interesting to see that this


was a node coming from Apple in the standardization process.


So when the shadow DOM standard was proposed,


there were basically the other vendors that said, yeah, no,


it's fine.


There should be an easy way to cross the shadow DOM border


so that you can still customize the styles of a web component,


because that would be the easiest way to provide that.


And also there was a shadow pseudo selector in CSS


and all that kind of stuff.


But then Apple said, no, no, no, no.


We think it is better to have the option


to say if a user land thinks that if a website owner can


cross into the shadow DOM or not.


So now there is the opportunity to create open or closed shadow


DOMs to specifically choose as the web component author


if you would allow crossing the shadow DOM border or not.


And the thing is the shadow DOM border is not a security


feature.


It is sheer isolation for the sake


of avoiding accidental manipulation of elements


inside the web component.


I think from the composability standpoint,


it is good if you can cross the shadow border.


But you have to do so consciously.


You shouldn't be accidentally ending up within the shadow


DOM.


But having the opportunity to deliberately do that


is, I think, fine.


This all sounds like a science fiction movie, Martin.


Yeah.


I was just going to say cross into the shadow border,


like Mordor or something.


Yes.


Is there also a ring involved?


Well, maybe there's the hover ring, I think.


So it's not like a sandbox that, for example, extensions


function in more like, I don't even know,


like a controlled border.


I would consider it like it's not a wall.


It's a curtain.


You can open the curtain and then look what's behind.


But a wall is a relatively rigid thing.


Unless there's a window or door, you


can't necessarily easily traverse it.


And that's basically how I think about it.


If I basically say like all the things, all the objects I see,


I want to paint them all red.


If there isn't a set of other objects behind the curtain,


I wouldn't see them, so I wouldn't paint them red.


But if I wanted to, I can draw the curtain to the side


and then still paint all the objects behind it red.


Interesting.


Yeah.


Fine.


I'll accept it.


That's very nice of you.


That's great.


I'm very happy to hear that.


I know.


I get it a lot.


You're a gift that keeps on giving, Gary.


I don't get that a lot.


So I guess we could index the tokens in the Shadow DOM,


right?


Yes.


Cool.


I think that was my cue.


Very subtle.


Was it?


Yeah.


Oh.


OK.


Then I will talk.


One of the last episodes that we had,


I was talking about indexing.


And we were talking.


We have different kinds of storages


that we use based on how often we


think that documents indexed in those tiers would be served.


But we haven't talked about the serving index, which


is slightly less abstract than what we were talking


about in a past episode.


And the serving index is actually


what is in our data centers and from where people get


their search results on their screens.


And I think it's not that much of an interesting topic.


It's just I want to cover it before we actually


move into serving because it feels that if I don't,


then people might misunderstand things, which would never


happen ever on the internet.


So the serving index, that's essentially


a lot of index shards that were pushed by caffeine


into our serving data centers.


I don't remember the exact number of data centers


that we have for serving web search, search in general.


But it's over 10.


And each of these data centers would get, well,


between 10 and 15 somewhere.


And each of these data centers would get the index shards.


And each of these index shards would contain the documents


that we have indexed.


Now, these documents are not actually the things


that we grabbed from a URL.


They are broken down into tokens.


Basically, we tokenize them because we don't actually


need all the fluff that comes with the HTML.


For example, script tags, why would we


want to index those tokens, those keywords or key phrases


from pages?


We just don't need them.


Certain HTML elements we do need because reasons, I will not


say.


JOHN MUELLER! Emojis, right?


We need them too.


PABLO LUPO! Yeah, we need them.


Those are very important indeed.


So we will keep certain HTML elements.


We will keep the actual words that appear on the page


and their positions on the page because that's also important,


as we've said a number of times before.


And then these index shards are distributed


among the data centers.


Each data center will have a duplicate of the shards


because that's how it should be.


So each data center can serve relatively the same documents


as the results if needed.


Of course, that doesn't always happen.


Like sometimes some shard might lag behind in a data center,


and then interesting things can happen.


Like you search for something, let's say cookies,


and then Martin also searches for cookies,


and they get completely different results.


And that's sometimes because we are querying different data


centers, and the index shards are


different between those data centers that we are querying.


Now, the index shards are, I like


to think of them as rawr part files,


like a packaged part file.


I keep bringing this up, but back in the 90s, for example,


when we were installing Doom or Quake or Age of Empires,


for example, then we got these floppy disks.


And I remember that.


MARTIN SPLITT RODGERSEN, JR. Yes, Martin, floppy disk, woo-hoo.


Now, Martin, sit down.


For example, Age of Empires came on 30-something floppy disks.


Doom came on, I think, 12.


Then Diablo 1 that came on 50-something.


So you had to insert each floppy disk into your floppy drive,


copy over the files that you found there,


and then unites them.


And then you would have the final executable


that you would use to run your game.


And the index shards are not so dissimilar from that


conceptually.


They are essentially a part of the index


all together forming the entirety of the index.


We have many index shards in many data centers.


I don't know the number, but order of thousands,


or tens of thousands even.


And that poses a challenge.


The challenge is that you have to find fast documents


in those index shards.


And if you think about it, when you search for something,


you get the results under one second.


Now, if you have to look in all index shards for every query,


you are not going to deliver results in under one second.


Because even the smallest index shards


would be several megabytes big.


And going through all the records


that you have in a shard will take time.


And to help serving, identifying the index shard that


needs to be queried, we have something


called shard indexes, which identifies


the shards for certain queries, which is basically


a map between the keywords that we encountered


or token that we encountered on pages


mapped to the index shard's number or identifier.


But that will not be enough to seek inside the index shard.


For that, we need new map, which is


what we call the posting list.


And that identifies the document ID


that contained a certain keyword, for example.


Like if you search for oatmeal cookies, for example,


then the posting list would tell us


that the word oatmeal appears in the documents 1234567.


And then cookies would appear in 5678910.


And then we would send the intersection of the two


up to serving.


Now, this is oversimplified.


And there are other processes that take place,


like for example, the tokenization itself,


which can be a challenge in certain languages.


But conceptually, this is how we actually


build our serving index.


So cool.


So it's kind of like the index in the back of a book,


where you see the page number.


And then on that page with the posting list,


you figure out, oh, it's line 17 or something like that.


Yeah, that's literally what it is.


And if I remember correctly, that's


where the idea came from, actually.


Woo-hoo, OK.


And they're called sharks because they


are swimming in the pipeline of the internet.


I think, no, just no.


It's with a D, not with a K. Shards.


Shards.


Oh, shards.


Oh, OK.


That sounds like a JRPG.


Why are you hurting my brain like this?


So sorry.


Not sorry.


That sounds like a thing from a JRPG,


like, oh, you have to bring all the shards from this crystal


together.


And then you will, I don't know, free


the princess that has been frozen inside the crystal.


Bling.


I keep thinking of that data center


that we have in Finland, where we cool the data center


with water from the ocean there.


So it's like, we're sending the sharks up there.


And then they go into the data center


and provide search results for all of Finland.


I seriously want indexing shards.


I'm going to go out on a limb and say


that that's not how it works.


But I think the sharks don't contribute anything


to cooling our data centers.


But I might be wrong.


They are at least a threat for the internet


because they bite the cables.


Yeah, that's true.


We actually had failures due to sharks


biting the underwater cables, I think,


close to Egypt, Alexandria, I think.


So cool.


So the sharks were holding back the shards.


Yeah.


OK.


I love all of this indexing stuff.


It's almost like science fiction as well, especially the names.


I don't know, where people come up with this stuff.


Anyway, moving back to Site Kit, which hopefully doesn't


have too many sharks.


Where can people find Site Kit, Maria?


Now you've let the cat out of the bag, John.


Site Kit essentially turns your site into sharks.


And then sends it to the index.


But let's just keep this between ourselves here.


Well, there is a website, sitekit.withgoogle.com.


And also, you can easily find Site Kit


if you search for Google Site Kit or Google Analytics


or something like this in the WordPress plugin repository.


So that's the two easiest ways to find it.


So cool.


And if you wanted to stay on top of all of the algorithms that


are launching in Site Kit, where is a good place


to watch for the changes there?


There is a blog on the same site that I just mentioned,


sitekit.withgoogle.com.


And sometimes when there's something especially exciting,


we also might do a guest post on the Search Central blog.


So there, too, might be a good place to keep an eye.


Yeah.


I think I installed the beta version on my blog


at some point.


But I don't know if I actually got the final version, which


maybe I should install after all.


Or maybe I should, I don't know, post something


on my blog at some point.


Speaking of blogs, how is that recipe blog going, Gary?


I mean, we still have things to finish on the dev site


with one site move.


So I'm focusing on that.


It's getting a little painful because we


have to import all the language blogs


that we have from way too many locations on Blogspot


or Blogger.


And fortunately, they are all using


slightly different templates somehow,


which makes parsing very, very exciting.


It's great.


OK.


So it's kind of like a disconnected collection


of shards.


And we have a full circle.


Sitekit sharks, doo, doo, doo, doo, doo, doo,


sitekit sharks, doo, doo, doo, doo, doo.


Martin!


I want to quit.


I think maybe we should wrap it up here before things


get completely out of hand.


Thank you all for joining us here, folks.


And thanks for dropping by and chatting with us, Maria.


I hope you found this as insightful and useful


as I found it.


In shark-full.


Yeah.


Shark-full.


Anyway, we've been having fun with these podcast episodes.


And I hope you, the listener, has


been finding them both entertaining and insightful


as well.


And regardless of how you're liking these,


please let us know.


And tell us if there are any topics


that we should be covering slightly differently


or going into more detail.


You're welcome to drop us a note anywhere


you can leave feedback on podcasts,


or maybe just contact us on Twitter directly.


Or who knows, it's some virtual event at some time.


We'll see.


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


And share these podcast episodes with other people


if you find them useful.


Thanks a lot.


And see you next time.


Bye-bye.


Bye.


I love you, darling.


Let’s talk about accessibility

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


Let’s talk about accessibility

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


Let’s talk about accessibility

way.


Let’s talk about accessibility

My name's Lizzie, and I'm on the Search Relations team here at Google, mainly taking care of


Let’s talk about accessibility

the Google Search Central website, which we sometimes call 1Z.


Let’s talk about accessibility

In this episode, we're going to focus on accessibility and websites.


Let’s talk about accessibility

And to help me with that, I'm joined by Danny, who also works at Google.


Let’s talk about accessibility

Hi, Danny.


Let’s talk about accessibility

Hey, Lizzie.


Let’s talk about accessibility

It's so good to have you here.


Let’s talk about accessibility

I'm so excited because I feel like I'm going to get free design tips or something from


Let’s talk about accessibility

you just based off of your job title alone.


Let’s talk about accessibility

I did stalk you before coming to this podcast recording, and I see that you're a UX interaction


Let’s talk about accessibility

designer.


Let’s talk about accessibility

Could you tell me a little bit more about what you're doing at Google?


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

What is UX interaction design?


Let’s talk about accessibility

What is UX interaction?


Let’s talk about accessibility

It's interesting because working in accessibility, you might experience a different take on interaction


Let’s talk about accessibility

design.


Let’s talk about accessibility

It's certainly a little bit different from previous roles in some ways, but what I'm


Let’s talk about accessibility

working on specifically, and I just joined the central accessibility team about a couple


Let’s talk about accessibility

of months ago, I think now, but my primary role is sort of working on this Android app


Let’s talk about accessibility

that Google has called Lookout, which is intended to allow users to experience the world around


Let’s talk about accessibility

them using their camera.


Let’s talk about accessibility

So thinking about the audience being sort of blind and low vision users, you can use


Let’s talk about accessibility

this app to point your camera around at various things, and it tells you what's happening.


Let’s talk about accessibility

So there's like a currency mode if you want to understand the denominations of the currency


Let’s talk about accessibility

that you have in your hand.


Let’s talk about accessibility

There's a documents mode that allows you to read documents.


Let’s talk about accessibility

It sort of ingests that, creates that text on your phone and reads documents to you.


Let’s talk about accessibility

We also recently launched a images mode, which allows you to share an image to Lookout or


Let’s talk about accessibility

upload an image, and it tells you what's in that image.


Let’s talk about accessibility

Right now, it might tell you there's maybe two adults, there's trees or woods or something


Let’s talk about accessibility

like that.


Let’s talk about accessibility

So that was just launched, which we're really excited about.


Let’s talk about accessibility

So that's, I would say, the majority of where I've spent my time with this new team.


Let’s talk about accessibility

I mean, I'm still just ramping up, but I've sort of been in the accessibility.


Let’s talk about accessibility

Yeah, just a few months ago, like that's brand new to the Lookout.


Let’s talk about accessibility

You already gave like a perfect summary about what the team is working on and you're just


Let’s talk about accessibility

ramping up.


Let’s talk about accessibility

So I mean, that's like five stars.


Let’s talk about accessibility

If you know what the new project is that you joined, I think ramping up, that's good.


Let’s talk about accessibility

So the images thing, so that's something that you could save the image and then upload later


Let’s talk about accessibility

to look at it?


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

Or what would be the use case?


Let’s talk about accessibility

The way I kind of like to use it is, you know, you get a text, let's say, from friends and


Let’s talk about accessibility

you want to take that image and share it to, you would share it to Lookout as if you're


Let’s talk about accessibility

sharing it to any app and it will automatically be in images mode and communicate to you what's


Let’s talk about accessibility

in the image.


Let’s talk about accessibility

But if you're in the app as a starting point and you go to images mode, there's an image


Let’s talk about accessibility

upload button.


Let’s talk about accessibility

You can choose your image as you would with, you know, any other image upload experience


Let’s talk about accessibility

and you can get the image into Lookout that way for it to tell you what's going on.


Let’s talk about accessibility

Okay.


Let’s talk about accessibility

So it could be something that maybe you found like on Reddit or the internet or something


Let’s talk about accessibility

and you saved it and then you wanted to look at it later.


Let’s talk about accessibility

You took a picture when you were out and about and then you're at home and you're like, okay,


Let’s talk about accessibility

I'm now ready to review whatever it was that I took a picture of later.


Let’s talk about accessibility

So it's sort of asynchronous.


Let’s talk about accessibility

It doesn't need to be like hovering right now above the thing.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

And you don't even need to save it per se.


Let’s talk about accessibility

I mean, you could just share it, right?


Let’s talk about accessibility

You don't need to go through that process of sort of downloading it to your local.


Let’s talk about accessibility

Saving to device.


Let’s talk about accessibility

Yeah, exactly.


Let’s talk about accessibility

And then you just have like all these like screenshots or something from your messages


Let’s talk about accessibility

that people have texted you.


Let’s talk about accessibility

It's like too much.


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

Exactly.


Let’s talk about accessibility

Okay.


Let’s talk about accessibility

So taking it back, I don't know, more than from a few months ago, how did you come to


Let’s talk about accessibility

be involved in accessibility and was it designed before accessibility or when did the two kind


Let’s talk about accessibility

of intersect?


Let’s talk about accessibility

Yeah, it was definitely designed before accessibility.


Let’s talk about accessibility

I became a UX designer.


Let’s talk about accessibility

I started to kind of study UX back in 2013 and I sort of, you know, was able to become


Let’s talk about accessibility

a UX designer just learning while being a Googler.


Let’s talk about accessibility

I started at Google in 2011 and it was definitely designed first.


Let’s talk about accessibility

What was your first role at Google or what did you get hired in to do?


Let’s talk about accessibility

My first role was in the ad space.


Let’s talk about accessibility

I was a technical account manager.


Let’s talk about accessibility

So I was sort of a technical liaison.


Let’s talk about accessibility

You know, I would kind of work alongside our account managers and salespeople and folks


Let’s talk about accessibility

that interact with our clients and sort of have that technical expertise for any time


Let’s talk about accessibility

we needed to understand the backend of our advertising products a little bit better and,


Let’s talk about accessibility

you know, maybe do some custom work or something like that with the client.


Let’s talk about accessibility

And then eventually I was sort of, I didn't know about UX when I joined Google, but once


Let’s talk about accessibility

I understood it, I was kind of, I just reached out to a UX designer at Google and he was


Let’s talk about accessibility

super kind and took me on as a mentor.


Let’s talk about accessibility

I love that.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

So I was still sort of working on the same product as a technical account manager, but


Let’s talk about accessibility

also learning about UX through that lens and working with a designer of the same product.


Let’s talk about accessibility

So that's sort of the beginnings of how I started to get involved with UX design.


Let’s talk about accessibility

Had you always been sort of like design minded, like a creative person, like in your free


Let’s talk about accessibility

time that that sort of blend into like, I want to also do this at work, like find a


Let’s talk about accessibility

way to be creative at work is sort of, I find sometimes difficult, I think for, for creative


Let’s talk about accessibility

minded people.


Let’s talk about accessibility

Yeah, I think so.


Let’s talk about accessibility

I never thought of myself that way, but once I had this profession, it helped validate


Let’s talk about accessibility

to me that I am a creative person.


Let’s talk about accessibility

I was always interested in tech and I always had an opinion on how things were laid out


Let’s talk about accessibility

and how apps worked and why did they do it like this and why couldn't it just be this


Let’s talk about accessibility

way?


Let’s talk about accessibility

And even something as trivial, seemingly as how you format your documents for school,


Let’s talk about accessibility

right?


Let’s talk about accessibility

That was like stuff that I would probably be geekier about that type of stuff.


Let’s talk about accessibility

Okay.


Let’s talk about accessibility

So if we were in a group project together, you would be formatting the doc that we're


Let’s talk about accessibility

in to make sure that the sections are in the right spot or if we're doing like a PowerPoint


Let’s talk about accessibility

presentation, you would be driving that part of the project probably.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

Stuff like that.


Let’s talk about accessibility

Also stuff that's a little bit more sinister.


Let’s talk about accessibility

You know, when you're really young, you're kind of like trying to make the number of


Let’s talk about accessibility

pages that you have look longer for school or, you know, like stuff like that.


Let’s talk about accessibility

Sneaky.


Let’s talk about accessibility

I would say that making the period larger.


Let’s talk about accessibility

Let me see, what are the top tricks?


Let’s talk about accessibility

Like spaces between sentences.


Let’s talk about accessibility

Yeah, exactly.


Let’s talk about accessibility

But no, I did always like to make things more readable.


Let’s talk about accessibility

That was sort of when I look back the beginnings of it.


Let’s talk about accessibility

And yeah, and then I also I did a fair amount of coding.


Let’s talk about accessibility

I felt like when I got into school and when I got into the professional world, it was


Let’s talk about accessibility

kind of like everyone, if you wanted to work on software, you needed to code or needed


Let’s talk about accessibility

to understand it in some way.


Let’s talk about accessibility

And I always felt like that was a barrier.


Let’s talk about accessibility

And so I learned it a little bit and I always kind of had to experience it in some way.


Let’s talk about accessibility

But I ultimately was just like, my mind doesn't work like this.


Let’s talk about accessibility

And so when UX design came up, that was a way for me to be like, okay, you can have


Let’s talk about accessibility

an opinion on the software and the UI and how it works and not necessarily be the one


Let’s talk about accessibility

coding.


Let’s talk about accessibility

And I'm sure some people are, you know, there's plenty of very technical UX designers out


Let’s talk about accessibility

there, UX engineers who do have that experience and were developers first.


Let’s talk about accessibility

I know, you know, plenty of designers who were developers first, but that wasn't exactly


Let’s talk about accessibility

my interest.


Let’s talk about accessibility

So I think that also drew me into UX design, just knowing that it could be visual.


Let’s talk about accessibility

To me, that sounded fun, just going to work and playing with shapes and colors versus


Let’s talk about accessibility

just sitting in Excel and sitting in a spreadsheet and documents and emails and stuff like that.


Let’s talk about accessibility

Totally.


Let’s talk about accessibility

And I can imagine having that background to know what's possible or be able to speak the


Let’s talk about accessibility

same language as the developers is helpful to say, like, this is what I want and I know


Let’s talk about accessibility

that you can do it because I know at least what sort of functions behind what the shapes


Let’s talk about accessibility

can do and say it in the words that they know about.


Let’s talk about accessibility

For sure.


Let’s talk about accessibility

So how did this then meet accessibility?


Let’s talk about accessibility

So it was developing and then design and then accessibility.


Let’s talk about accessibility

Yeah, I guess I found myself asking about accessibility and it became apparent to me


Let’s talk about accessibility

that there was an opportunity to become a subject matter expert in accessibility on


Let’s talk about accessibility

one of my previous teams as a UX designer.


Let’s talk about accessibility

And so once I started to learn about accessibility, I saw that there was a very rich amount of


Let’s talk about accessibility

content that was already there that wasn't taken advantage of just in general.


Let’s talk about accessibility

I didn't hear about it as much as there was depth of content, if that makes sense.


Let’s talk about accessibility

Yes, I can definitely relate to that because I've delved into accessibility more this year


Let’s talk about accessibility

in particular.


Let’s talk about accessibility

I knew about it before, maybe just from the writing angle, because we have style guidelines


Let’s talk about accessibility

for writing for accessibility.


Let’s talk about accessibility

I'm a technical writer, so that's generally the thing that I would think about first.


Let’s talk about accessibility

But in terms of testing and starting to look at what's out there, like, okay, I want to


Let’s talk about accessibility

now see how accessible my website is and you do a search for it or look at what we have


Let’s talk about accessibility

internally.


Let’s talk about accessibility

There is a million things laying around.


Let’s talk about accessibility

Everybody has checklists.


Let’s talk about accessibility

There's so many resources that it can be, I think, overwhelming to know which thing


Let’s talk about accessibility

is like, how do I know?


Let’s talk about accessibility

You could spend a lot of time just reading to find out, okay, what are all the things


Let’s talk about accessibility

that I could be looking at?


Let’s talk about accessibility

And that there are so many different guidelines or tips or testing tools and things that people


Let’s talk about accessibility

have written to just sort of ingest that.


Let’s talk about accessibility

I can see as a curious person that that can be definitely a trajectory that you could


Let’s talk about accessibility

find yourself exploring.


Let’s talk about accessibility

Yeah, I think it's also just nice because you can find all the resources yourself for


Let’s talk about accessibility

the most part.


Let’s talk about accessibility

Yes.


Let’s talk about accessibility

And so you can learn, I mean, there's plenty of books, there's tons of guidelines on the


Let’s talk about accessibility

internet and it's really up to you how quickly you want to learn about accessibility.


Let’s talk about accessibility

And it gives you the ability to just kind of take something from some guidelines or


Let’s talk about accessibility

some website and then you come back to your own sort of scope, whatever it is that you


Let’s talk about accessibility

work on, and you can immediately sort of apply it.


Let’s talk about accessibility

Or if you understand code, you can kind of be like, oh, this tag is missing.


Let’s talk about accessibility

Maybe I can go back here and find it and see if I'm following these guidelines, so to speak.


Let’s talk about accessibility

So I think if you just take the time to do the right searches and just look around, you


Let’s talk about accessibility

can take those resources and apply them pretty quickly.


Let’s talk about accessibility

And that's really nice if you're trying to make sure that your work is more accessible.


Let’s talk about accessibility

But I think on a more human level, as a professional, you want to do things that are good for the


Let’s talk about accessibility

world, right?


Let’s talk about accessibility

There's plenty of jobs out there where the end goal is making money or reducing inefficiencies


Let’s talk about accessibility

or whatever.


Let’s talk about accessibility

And I think that the business world is always going to have that.


Let’s talk about accessibility

And I think my goal in becoming a designer and learning about accessibility was sort


Let’s talk about accessibility

of just to continue to inch towards that human thing, right?


Let’s talk about accessibility

Like empathy and understanding people and feeling good about what you do, all that good


Let’s talk about accessibility

stuff.


Let’s talk about accessibility

And so I guess I've always just sort of been iterating on what it is my role is and inching


Let’s talk about accessibility

towards whatever my idea of that is.


Let’s talk about accessibility

So I think that's what helped me get into accessibility is just like, this is really


Let’s talk about accessibility

interesting and it's undeniably a good thing for business or sites or whatever.


Let’s talk about accessibility

And there's also just kind of a massive deficit on the internet.


Let’s talk about accessibility

Most of the internet's just like not really accessible, right?


Let’s talk about accessibility

It doesn't follow those guidelines that we're talking about, color, contrast and structure


Let’s talk about accessibility

and all that good stuff that I'm sure we'll talk about.


Let’s talk about accessibility

So there's a lot of resources to follow.


Let’s talk about accessibility

There's a tremendous amount of space to improve.


Let’s talk about accessibility

And so just knowing that I think it makes it an easy space to dive into if you want


Let’s talk about accessibility

to just make your website more accessible or you want to just be a subject matter expert


Let’s talk about accessibility

in anything.


Let’s talk about accessibility

Yeah, it can be very rewarding as well, especially if you want your thing, like whatever it is,


Let’s talk about accessibility

your project, your website, whatever you're working on to work well for everyone who's


Let’s talk about accessibility

using it or could be using it.


Let’s talk about accessibility

And this is like a huge pocket where you're like, oh, all these things.


Let’s talk about accessibility

Like I didn't know that it wasn't working in these conditions.


Let’s talk about accessibility

And once you sort of realize that and you're able to make fixes, it can be very rewarding


Let’s talk about accessibility

to broaden the scope of whatever it is, especially as an interaction designer.


Let’s talk about accessibility

You're thinking about how are things working for people, like the actual functions behind


Let’s talk about accessibility

like is this nice or usable?


Let’s talk about accessibility

Not even nice.


Let’s talk about accessibility

It's just like, can you use this thing?


Let’s talk about accessibility

Let alone is it pleasant or delightful or easy to use it?


Let’s talk about accessibility

It's just like, can you use it at all?


Let’s talk about accessibility

And are we even there yet for it to be like, this is delightful?


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

Yeah, I agree.


Let’s talk about accessibility

I totally agree with that sentiment.


Let’s talk about accessibility

I also just feel like I do love design.


Let’s talk about accessibility

And to me, accessibility is just a part of creating good design.


Let’s talk about accessibility

It's not like this tangential thing.


Let’s talk about accessibility

It's a part of that purview per se, or that sort of scope or that interest of mine.


Let’s talk about accessibility

So they're one in the same to me.


Let’s talk about accessibility

I would agree with that.


Let’s talk about accessibility

I think once you sort of, I guess, get introduced to the concept that there are these other


Let’s talk about accessibility

things to be looking at, it makes sense to go that direction.


Let’s talk about accessibility

So I guess when you're approaching a project and you're thinking about design or assessing


Let’s talk about accessibility

something, are you typically auditing an existing thing to improve it?


Let’s talk about accessibility

Or are you handed a new thing?


Let’s talk about accessibility

Like we're working on a launch to launch this website or this app afresh or something that's


Let’s talk about accessibility

maybe been sitting around for a while that you may want to audit.


Let’s talk about accessibility

Because for me, I've been working on this website and it's a thing that's been existing.


Let’s talk about accessibility

So then it seemed like the first step would be then to audit what I have to see how is


Let’s talk about accessibility

it even doing right now?


Let’s talk about accessibility

Is it terrible?


Let’s talk about accessibility

Where are the areas and how do you even approach making improvements?


Let’s talk about accessibility

So for you, what would be one of the things that you first start to look at?


Let’s talk about accessibility

Would it be something from an audit perspective or from a launch?


Let’s talk about accessibility

We are pushing this project out.


Let’s talk about accessibility

Well hopefully you're not waiting until launch.


Let’s talk about accessibility

Yes.


Let’s talk about accessibility

New things I guess.


Let’s talk about accessibility

It's more of a design first.


Let’s talk about accessibility

You're not handed something that's like, oh these people before me had not thought about


Let’s talk about accessibility

accessibility and they might be missing certain things and this thing is already out there.


Let’s talk about accessibility

I think a lot of people are probably in that boat and it's sort of, I don't know, is it


Let’s talk about accessibility

nicer?


Let’s talk about accessibility

Probably it's nicer to launch with the thing working well from square one but you might


Let’s talk about accessibility

not have the luxury I guess, depending on what you're working on perhaps.


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

I've definitely heard that before.


Let’s talk about accessibility

I would agree with you.