Google Search Off The Record Podcast: Let’s Talk About UX and SEO

Martin 0:11
Hello, and welcome to another episode of Search Off The Record, a podcast coming to you from the Google Search team, discussing all things search and having some fun along the way. My name is Martin. And I’m joined today by Lizzi and Gary from the search relations team, of which I’m also part of. Hi, Lizzi.

Lizzi 0:30
Hi, Martin. Hi, Gary.

Gary 00:31
Guten morgen.

Martin 0:33
Ooo Swiss German. Very nice. Oh man. I don’t know if you notice, but we have this thing called core web vitals. And it’s a thing in search. And recently when I was at the first in-person event, after the weird time, I got asked a question about core web vitals that fundamentally was like, but what if all my users are on slow devices or slow networks? And isn’t that unfair for ranking? If I get ranked on that? And I thought, isn’t it unfair to the users when your website is super, super slow on the devices and connections they’re using? And it got me thinking like, shouldn’t it matter to you as a business and a website owner how your users are experiencing your website? And then that got me thinking, how important is user experience for someone who makes a website? And I mean, for instance, our documentation at developers. google.com/search. We want our users to succeed when they use our docs, but how do we actually know if they do? How do we? How do we do that? How do we know how our users are experiencing our website?

Lizzi 1:49
You know, this is like a huge topic. Because it does seem like there are two different things. There’s page experience and user experience. And are these two different things? Is page experience like part of user experience?

Martin 2:02
I think so. Yeah. Yeah. Is it a certain thing? It’s a subset…

Lizzi 2:06
Or what when we say page experience, what do we mean?

Martin 2:09
So I would say things like interstitials, like, misleading or disruptive interstitials, I think we call it. Core web vitals, mobile friendliness. So is the website working well, on mobile, HTTPS is a thing. But that’s all very technical bits and pieces.

Lizzi 2:28
Yeah, I mean, I think that I did go into our documentation to see what we say about user experience to prep for this episode for UX and SEO. And we don’t actually have anything about that term UX or user experience. But we do have page experience. And I think it’s just because we’ve branded that, like, from a marketing perspective to label these set of signals to be like a thing in search. But it doesn’t necessarily include all of the things for users.

Martin 2:57
True. True. But, Lizzi, you are, fundamentally, the site owner of our documentation. How do you think about user experience?

Lizzi 3:06
That is a loaded question. Oh, where would we start? Oh, no. Okay, I opened Pandora’s Box, huh?

Martin 3:10
Yes. Right. Okay, rephrasing, if I were making a website, where would I start in our documentation to figure out what to do? Like how to make it a good site?

Lizzi 3:26
Well, I think we would probably point you to the webmaster guidelines. And it’s interesting, because there we don’t actually say user experience or UX. But we do say to think about the user and make the website work for the people who are coming to your website that the like, what you do when you’re designing your website should work for users first and then machines. But is that the same thing?

Martin 3:52
I think so to a degree, I think that at least encapsulates that the technology side of things is just an aspect of it, I guess. But then I mean, there’s like so much other things going into user experience, as you said, for instance, working with you, I realized, how [expletive] I am at writing.

Lizzi 4:10
I hope I didn’t make you feel that way.

Martin 4:13
No, no, no, no, you you made everything always a lot better. So that made me feel supported. And you know, that was great. But it also meant that probably whenever I wrote things like website copy, I was probably not doing the best job. So when writing things or when when putting the content together. Is that UX would you say?

Lizzi 4:36
I mean, definitely. It’s what people are seeing when they’re reading a web page. So it’s the words on the page. But in our guidelines, we’re kind of hand wavy about that. And maybe for good reason, I don’t know. To say sort of like make sure that you write for your users. It’s super like general. What does it mean to write well for your users? We don’t necessarily spell that out. Should we?

Gary 5:01
I mean, in many cases, we are abstracting away from things because, for example, they are hard to define. That’s not the only reason. But when something is hard to define, then we might be abstracting away from it. And in this case, in case of UX, I think the the reason why we are abstracting away is that it’s very hard to define it. Because, what you mentioned the website copy, that’s already one thing. So basically, right for your users is an abstraction from right for your users level reading level, perhaps. Then, other things like headings, and how to structure headings, how to structure navigation, those are all part of what the users will experience on the page. So we are abstracting away from that, because you can define exactly what kind of headings people should use, where they should put their navigation and how the navigation should be structured. So with some things, we probably can go into detail like with reading level, but then with other things it’s probably not that easy, like with navigation.

Martin 6:19
Okay, no dumb questions time. What is reading level? What does that…

Lizzi 6:22
Oh, so it’d be like, right for eighth grade reading level or something like that. And they have these tools that can measure how complex your sentences are. So if it’s like, over a certain number of words, in the sentence, then maybe it’s more complex, or like the words that you use, are they longer, more complicated words? Or are you picking simpler words that are easier to understand? And typically, I mean, for our docs, we do try to target–I mean, it’s hard because our Doc’s are writing about technical things. So you have terms that are like, well, this is like jargon, or like this is a technical term–but we want to write about the things in a way that is like as clear as possible, so that people understand. And then also for translation. So making sure that the sentence structure is set up in a way that like, okay, I can see like where the sentence is going. And there’s not too many ideas in one sentence. Like you should be able to say the sentence in one breath. Sometimes we do that when we’re reviewing something that’s just like, become a paragraph long. And this is, like, try to read this out loud. Okay, I ran out of breath. Maybe this is not the best way to communicate whatever this thing is. Not just for native English speakers, but then when it goes to translation, it could become even more like, What are you even trying to say?

Gary 7:44
Yeah, sometimes I just put the verb like miles away from the subject for whatever reason, and then put multiple substance sentences in between them. Just because I can and then when we get to review them, Lizzi’s like, yeah, no.

Lizzi 8:05
Well, usually, it’s like, oh, we want to add this one clarification or this one, like edge case thing. So maybe we just say it like as an aside, and then we like shove it into this existing sentence. But then when you read it back, you’re like, oh, this sentence has, like, run away with us. And maybe we should have multiple sentences now or like if we read this in the context of the whole page. But I mean, this is becoming like, super granular. So you can see how this is complicated with even just the the writing or the words on the page, just within the context of like, we’re looking at a paragraph on a page, and then there are headings, and then there are like, the words that you get to other pages on your site. And if people land on a page, do they know where they are?

Martin 8:52
Okay, so it’s also like navigation and structure? Does it make sense to go from one thing to the other? And is it is it a flowing or a jarring experience?

Lizzi 9:01
Correct. And so within a page event, because I’m guessing you could probably land in the middle of a page, maybe from search results, I think that they’re jumped to the section or something like, we do that sometimes. So that’s sort of thinking about, like, the user journey, like how are they coming to our page and from search from some experience in search could be one path? And do they land in the middle of this document, and they should sort of know where they are in the context of whatever this like larger page is about, and then also in the context of our site. So if they’re looking for like, documentation about Sitemaps or something, and maybe they were searching for some specific thing, they should be able to see in the site navigation, like other related documents that are related to Sitemaps in case maybe this was like not the thing that they were looking for. And actually they want to know, something that’s more high level like what is the sitemap? All of that should be accessible.

Martin 10:01
Oh, that’s, that’s interesting. Speaking of accessible, I think that’s like a whole different rabbit hole that we should probably have an episode on the entire, like accessibility conversation…

Lizzi 10:12
100%. That’s also mentioned in the Webmaster Guidelines section about, make sure that your site works for users. There’s like a bullet there that says yes, like, make sure it’s accessible, because that is part of, I guess, the user’s experience on your website. It’s making sure that they can, there’s alt text for images and things like that.

Martin 10:35
Yeah. And I think that stuff’s probably all tricky to like, get a reading on so to speak. So I guess that’s why page experience is only looking at a very technical subset. I mean, there’s like these metrics that were defined. I actually don’t know how, have we discussed in the in the episodes. So we have an episode on core web vitals, that we will link in the description for those of you who want to listen to that as well. But I’m not 100% sure. Gary, do you remember if we talked about how these metrics came about?

Gary 11:06
I mean, we talked, I wasn’t in the episode, but you talked about how hard it was to define those metrics. And how there’s no one metric that can fit the whole bill.

Martin 11:24
Yeah, and I think that’s not just limited to the technical side of things. I mean, core web vitals are a limited view into how a user experiences the page. But then when I hear about like, the headings and the structure and navigation…

Lizzi 11:38
Right, like in our in SEO Starter Guide, or like webmaster guidelines, we say write high quality descriptive headings. Like, can you measure if it’s high quality or descriptive? Is there something that you could programmatically look at all of the headings I’ve written on onesie our website to see which ones are like providing a good user experience?

Martin 12:04
Yeah, it’s a tricky one. I remember we had a similar thing with, with lighthouse, where there is an SEO test for descriptive link text that’s similar, right? Like, oh, yeah, have descriptive link text. And how do you detect if it is not? And we’re like, Well, if it says click here, or like click or here, it’s very rudimentary to figure out if it’s descriptive or not. I actually don’t know I have no answer for that. So what did you come up with? Oh, we just have like a bunch of phrases that we catch us, which is great. Because if your website is in German that we don’t catch if it just says, here, or click here, because we’re just looking for the English Oh, phrases. It’s not great.

Lizzi 12:51
Is this like a pattern across other language sites to do this, like here link text thing? Or is this like, specific to English Web Design?

Gary 13:01
It’s in every language. Because I mean, we are humans, and we try to do things simply. And having something just like, download here, or just download, or here. That’s very simple and very quick to do. Right. And you don’t have to think about anything else, basically, excluding those people who use a screen reader. And I don’t know if we have a good answer for that. Or if we could ever have a good answer for it. Unless we have some magical NLP.

Martin 13:39
What My Little Pony? Yes.

Lizzi 13:42
A metal pony that will give us all the answers? No, my My Little Pony, My Little Pony.

Gary 13:48
Why would you have a metal pony?

Lizzi 13:51
I don’t know. Maybe this is like a new term? I don’t know.

Gary 13:55
No, I said N as in NATO. Lima. And what’s the P? P? Peas? No. There’s a code for it. Anyway. So natural language processing. Library or something? Or if we had a model for it, I don’t know how we would come up with it. Because descriptive might mean something completely different to me than to Martin. Yes. And that could be a big problem. Because with the technical things in core web vitals, it’s relatively easy to or easier maybe, to come up with a metric, because there you have numbers that you can measure, like how long it took for something to do X. While with something like descriptive…

Lizzi 14:41
I mean, you could come up with numbers like the number of characters, but that would not necessarily mean that it’s good.

Gary 14:48
Sure. So I think it’s more subjective. When it comes to, to some UX things.

Lizzi 14:58
Like for words on the page because it depends on probably the type of the context, like the type of site, who the users are like, what would be descriptive for whatever this thing? And who is it for?

Gary 15:09
Yeah. And what are you writing about? Like, if you have to boil it? Like, how long do you have to boil an egg to have a hard boiled egg? Like, how many words do you need for that? or

Lizzi 15:21
No to stand out against all the other hard boiled egg recipe people? This triggering?

Martin 15:29
Back when I was a child, my mother used to make

Lizzi 15:31
I don’t know, there’s like, actually so many ways that you could like, what kind of like hard, like how well done is done. You could be like, Oh, eight minute, 10 minute egg, like what kind of egg?

Martin 15:42
See and this is why we are vague and hand wavy in our documentation, because there’s lots of detail that is tricky to cover, I guess, without blurring the the actual concepts that you want to transport in the documentation. So that’s a tricky one.

Lizzi 15:56
It’s interesting, because, uh, yeah, I guess that’s why we fixate or not fixate. But we document the things that are specific to the machines like what stuff like for our URL structure guidelines, we say stuff like, oh, put a hyphen instead of an underscore, like make your URLs readable to humans. But what we really mean is for machines, I guess, because are humans looking at the URL text? Is this something that a user would think of when they’re using our site, I guess? Is this something that’s just for machines?

Martin 16:30
I actually don’t know about that one. But I think the core there is it should be consistent, because as a user, I don’t want to have to remember where that it’s all in which places it’s a hyphen, and when it’s an underscore. So make–Oh–choose one, pick one, stick with one, but or I don’t know, maybe there’s a technical difference that…

Lizzi 16:51
The user, do you mean, like as developer implementing this on a website? Or like what you’re

Martin 16:57
No no, no, no. As, as someone who might potentially try to remember the URL.

Lizzi 17:03
Ohh. To like manually type it in?

Martin 17:06
Yeah. That’s why brevity, for me, is important as well. Yes, sure. You can use a URL shortener, but then you get links like, I don’t know, something dot something slash 8907 D 12. And I’m like, yeah, that’s not easy to remember at all. But if it’s like, mobile dash friendly dash test, and I can remember that, but if it’s like mobile underscore friendly dash test, or something like that, then but Gary, you said it, there’s a difference.

Gary 17:35
There’s a difference. And that’s in our segmenter. Basically, we use some parts of the URL for understanding what the page is about. And the way it works is that we need to be careful about where we are segmenting because many things on the internet, things that people write about, have an underscore in them. So we can’t easily segment an underscore, and that’s why we are recommending dashes.

Martin 18:09
Oh, okay, that makes sense. But also, it’s easier to read it. It’s interesting how much of it is so logical and tangible. And at the same time, it’s just so hand wavy, tricky. I like that kind of stuff.

Lizzi 18:28
You like confusion and chaos?

Gary 18:32
Are you becoming me?

Martin 18:33
Yes. Give me chaos. No. Maybe. I don’t know. It’s classified. No, it’s interesting, like things such as site navigation, site structure, you can probably measure to a degree like if it’s overly deep, or if it’s very, very shallow. On the other hand, if it’s a small site with like four pages, then do you need more nested sets? Yeah, I mean, I’ll see even that isn’t the…

Lizzi 19:01
The site structure thing? Like seems okay, like we’re putting things in directories and organizing them in a way that makes sense for like the person who’s maintaining the site, the people who are reading it, trying to find the URLs and like in a logical way, and then the machines that are consuming it. But for the navigation stuff, there’s like a whole design side of it, like does this look nice to users? And I actually had this thought, like, I don’t know if we’re like doing something bad on Wednesday or not. Because in the guidelines, it says that you’re not meant to hide things like it should be immediately visible, like don’t zip things up in the navigation, like in our table of contents that’s on the side. We do have things like that are expandable. And our guidelines say that it’s like Google can see what’s in there, but like it’s preferred that you don’t zip them up like that. Is that an issue that we’re doing that from an SEO perspective and then from users as well? Like, is it clear that you can it expand stuff or like at the top when you can hover over a menu for it to then drop down, are some of these things obvious or not obvious. Okay, something that…

Gary 20:10
That’s interesting. We could take a look at that, because I don’t see a reason why you shouldn’t zip something up. So right, yeah, or since probably 2014 or something, we can actually see what’s under the zipped or it doesn’t have any negative effects on the content itself, as it’s represented in search. So I am not sure why we still have that.

Lizzi 20:40
It’s phrased in a way that seems like it’s okay, but not preferred. So yeah, maybe something for us to look at to see. Like, why, like, is this like just a user consideration, that it’s not great to like, hide things.

Gary 20:57
I mean, it’s, it feels kind of silly, because, for example, if you go to Galaxy or amazon.com, their menus are massive. And and when I say massive, it’s like, several dozens of levels deep. And I don’t I don’t, I don’t know how it would be or how it would look like if it wasn’t zipped up, like that would render this the whole site unusable, or the pages unusable. So yeah, I I’m not sure why we would prefer unusable sites.

Martin 21:37
Isn’t it a matter of: Are we looking at the render tree and basically think if something isn’t visible on the page, it is a little less important than the things that are visible on the pages? And we don’t do something like that? Oh, you don’t do that anymore?

Gary 21:55
No you don’t?

Martin 21:58
Oh, that’s fascinating. I did not know that.

Lizzi 22:01
When we say visible on the page is it like immediately visible because if you click that, then it would be visible. Or if you’re looking at the HTML that would be visible, it’s just sort of…

Martin 22:09
It’s just fair.

Gary 22:10
It just has to be in HTML. So basically, if you well, or in the immediate JavaScript, like, for example, if JavaScript brings in some content from within the JavaScript that’s on the page, or linked from the page, basically not using an XHR to bring in content.

Martin 22:29
An XHR is a network request that is triggered by JavaScript.

Lizzi 22:33
Thank you. Yeah. My eyes glazed over there for a second.

Gary 22:35
Thank you for that. I forgot where I was going. You could have waited like five more seconds.

Martin 22:42
I’m sorry. I’m sorry. I just I thought I would forget it. So if it’s in the immediate JavaScript, we see it. But if it’s coming from an, from a network request that was initiated by JavaScript, we usually also see it.

Gary 22:53
But if you have to click something, like for example, if you have an accordion, and then you click the accordion, and then there’s an XHR that brings in the content, we are not going to see that.

Martin 23:04
Yeah, that’s correct, because Googlebot does not do any user interactions, as far as I’m aware. Like the rendering does not click on things. It used to. It doesn’t.

Gary 23:13
Yeah, we had some extension for it for some very limited things. But I’m not sure if that exists anymore.

Martin 23:20
As far as I’m aware, it exists but is disabled, because it is very costly to do that.

Gary 23:25
I don’t think that hiding stuff is a big problem, maybe from like, if you hide big chunks of content, then users might not like it. Or they couldn’t…or they wouldn’t find the content that you’re hiding. If it’s not obvious, and then you’re missing out, basically, they are not converting perhaps.

Lizzi 23:46
Right. I guess it depends on how you’re hiding it. And if that is a design pattern that makes sense to people or that they’re used to like, okay, like, there’s a little drop down arrow like I’ve seen this thing before. I know to expand that. I think the one that we have on onsie is a plus sign. And we had somebody write in to say like, this doesn’t look like something I’ve seen before. Like, I don’t know if this would be obvious that you could hover and click over it just based off of the symbol, which is I just fix it. Fix it. I did fix it. I removed it.

Gary 24:16
But good job. No, it’s not obvious at all.

Lizzi 24:20
It’s no I just like got rid of it. That’s a problem solved. It did make me think like, Are there best practices for the design side of things like to design something that is usable? Or is this again, one of these things that is up for interpretation based off of your audience and what they’re used to seeing on the web, or even maybe regional differences, like I’m used to interacting with the hamburger menu. So I know when I hover over it, something will pop out and show me more things. But if this was not something that you’re used to like maybe you don’t even know that you could hover over it and more options would appear. Is this something that’s specific to your audience, like the same way that we were talking about general writing guidelines versus something that yes, we could measure?

Gary 25:08
That’s probably also very regional, as you said, like I’m trying to think of Japanese sites. And yes, some have the hamburger menu. But sometimes I have to look at or look more closely to to find the menu. And it’s even worse on like, I do lots of Chinese cooking, for example. And that, like for that I go to o Chinese sites. And very often I just can’t, for my life, find the menu.

Lizzi 25:39
And this is because they’re using like a different symbol, or like the way that the menus are laid out, or it’s just using a different design pattern than what we’ve seen before?

Gary 25:47
The thing or the site that I’m thinking of actually uses different everything. Like for example, the search is different also. And like, you start typing in something, and then you get these little chips, as refinements, it’s probably also from the, from the writing pattern that they are using. So it’s easier, like if you start typing in characters, like, I don’t know, start typing in Shui for water. And then it will give you suggestions about like, okay, so this word that you started could go in these different ways, ordered by popularity. So that’s, for example, different. The menu is different. And it took me probably like three days to find it. And I’m not ashamed to admit it. So, yeah, it’s probably regional.

Lizzi 26:51
But this would be something. Oh, I don’t know if this is an assumption or not. But like, would this be something that users have no problem in the local region. But maybe Google has a problem or no problem finding things across the site, like when we say make sure that your site navigation is easy to navigate? Would there be things that these different navigational structures should be doing?

Gary 27:12
Right? So that’s like, now it’s more technical SEO versus UX. Because from a technical SEO perspective, we just don’t care about that being navigation when we are talking about discovering parts of the site, so for us, those are just links. Well, if they are using links, like as in anchor elements properly, like Martin has the documentation on how to write proper anchor elements. And if they are using href attributes properly, then that’s what we care about, we find the URL and then from there, we start discovering things. If they’re using something else, like images, unlinked images, or on-click events, or whatever else, they might come up with, Flash, then we probably wouldn’t be able to use that.

Lizzi 28:11
It feels like there’s this Venn diagram of like UX and SEO and some things that overlap in the middle. But when we say like site navigation, it could mean different things. Or like the parts that we mean that are applicable to SEO are different than the parts that a UX designer or like someone who’s putting together the website would consider all these other things. On top of that.

Gary 28:33
I-I’m I have a I just had a epiphany, I actually had the epiphany: what if we make this a series UX and SEO? Because we are at, I don’t know, over a 30 minute mark, or roughly 30 minute mark, and we still have stuff to talk about.

Lizzi 28:51
I feel like we’re barely scratching the surface.

Gary 28:53
Yes, we are.

Martin 28:55
So, but even if we’re just scratching the surface, we have uncovered a lot. So I think making it into a series is a really interesting idea.

Gary 29:03
And I would like to subscribe to your comments. So yeah, let’s make this a series and then come back to this. Probably we can just take things apart and just focus on focus on one topic.

Martin 29:13
Well, as you said, I think it’s time to give a wrap up for this episode. I think the biggest conclusion is we need a series on UX and SEO and there’s a lot more than meets the eye. And then there’s definitely a lot more than is just captured in page experience. And a lot of it is also very, very hard to measure. But yeah, I think we learned a lot and there’s a lot more to uncover and explore. So I had another epiphany. What is it?

Gary 29:46
We could approach one of the UX people from Search Console.

Martin 29:50
Let’s do that. I’m sure Masha or others would be interested.

Lizzi 29:54
Oh, like UX researcher or UX designer. Designer. Oh. Very nice. All people who touched UX.

Martin 30:05
Anyway, I do think that’s a good point to wrap up this lovely, lovely episode, I do hope that all of you had as much fun uncovering the link between UX and SEO as we had, and that the learnings we have so far are useful for you all out there as well. Next time on Search off the Record, we will be looking into blocking. And by that we’ve been blocking content from search, which is also probably an interesting rabbit hole to fall into. But thanks a lot for listening. We’ve been having fun with these podcast episodes. And we do hope that you, the listener, have found them both entertaining and insightful, too. And yeah, please feel free to drop us a note on Twitter at Google search c, or chat with us at one of the upcoming events that we go to. If you have any thoughts and of course, don’t forget to like and subscribe. Thanks for joining us, everybody. Good bye.

Lizzie 31:02
Bye.