 Good morning, Seattle. I've always wanted to say that. This is my third Moscon. I was here back in 2019. And then last year, I was virtual. So thank you so much for inviting me back again. So yes, hey, everyone. Back in 2019, I stood on this very stage. And I told you that technical problems are people problems. And then last year, I spoke to you through the virtual stage. And I told you that as SEOs, it is fundamental that we do not work in silos. So this year, I'm hoping that I'm going to talk to you about a very specific approach to delivering value. But a little story first to set the scene. Everyone who knows me knows that I love saying stories. After around eight years in my career, I was starting to get really frustrated that I felt like I have no control over the implementation part. And when I say the implementation part, I mean the technical implementation part. So I actually sat down. This was an idea for a talk that I never ended up doing. And I calculated the percentage of recommendations that never got implemented in my career. And I found that only less than 20% got implemented, which is a little disappointing to say, but I have a feeling that a lot of us can relate to that number. So a little over a year ago, I started a new in-house head of SEO role. And it was within e-commerce company. And the only reason that I applied for this role is that it sat in the tech team. I was so done sitting in marketing. This role actually was reporting directly into the CTO, the Chief Technology Officer, which is something I've never seen before. So I thought to myself, I'm finally going to be in the driver's seat. I'm going to sit in the team that has the power to implement my recommendations. So I come from the world of large aggregator websites. I used to work for Zoopla, who are like the UK equivalent of Zillow. They had tech debt all across their site, and they had over 10 million pages. But this e-commerce website, it was only a few years old, and it was fresh. And when I say fresh, I mean it was one of the cleanest that I'd ever seen. So my first thought was, where is the tech debt? Where are the tech legacy issues? Where's the crawl budget issues? Where's the indexability challenges? Redirect chains, JavaScript rendering issues, broken internal links. Where are you, my old friends? Where are my usual suspects? What are usual suspects? Usual suspects are tech SEO issues that we are used to finding that make us feel like we know what we're doing. So if the usual suspects are missing, what do I even recommend? Is there anything scarier than a tech SEO human not finding tech SEO issues on the website that they're working on? The thing is, I mean, of course they had their share of issues, but none of them were big enough to actually make an impact. You know, as SEOs, we love talking about identifying quick wins. The first thing you do in a new job is, you know, the boss tells you, oh, find me some quick wins. What are the quick wins? And we love to use this term that absolutely everyone hates saying, but we still insist on using it, which is low hanging fruit. What is the low hanging fruit? But we never actually talk about what we should do if there are absolutely none. So at this point, I started thinking, how am I going to prove my worth? You know, I was new in the company. I was the first SEO that they hire, and I wanted to make sure that I proved to them that SEO is an important channel, and they can actually get something out of me. So I decided to do what I'm most comfortable doing, which is dive into the data, which is also known as my comfort zone. OK, so just a quick note throughout this deck. I work for Papier, which is a beautiful e-commerce stationery company. They are actually spreading in the US right now as well, but I'm going to be using examples from a lot of different e-commerce websites, not just Papier. So the first thing I decided to do at that point was I dissected the website. I wanted to split it into templates. So this is an example using the website Maid. They're a furniture e-commerce company, and I started kind of diving into them and trying to understand what are the different templates. So this is an example of a category page. What type of rooms does someone have that can have furniture in it? And then this is an example of a product listing page. So this is when you kind of dive into sofas, and you kind of see all these different sofas that are listed out, and you can filter them and sort them. And then this is an example of a product detail pages. So once you actually dive into a specific sofa, you can see details about it, and you can convert at that point. And then there's everything else. There's your about page, there's your home page, there's your blog post, and so on. So if I were to say that a typical e-commerce website has these templates, it would kind of look like that. You've got your category page, your product listing pages, your product detail page, and then you've kind of got everything else. So I needed to figure out at that point which template provided the most value. But how do we even define value? Or to be really honest, it doesn't really matter how I define it, right? What matters is how does the business define value? So what is the high level KPI that we are being measured against? So it's not visibility, it's not rankings, and it's not even sessions. It's organic revenue at that point. Like this is what people care about. This is what your boss cares about. This is what bringing in the money. So let's see which one of our templates drives the most organic revenue. This is fictional data, but to be honest, it's kind of close to the truth. When I sat down and I dissected my different templates, this is how it looked like. So with my product listing pages, my PLPs, they drove 60% of the organic revenue. And then everything else together drove around 40% of organic revenue. So if my PLPs happen to be driving 60% of revenue, then we should focus our effort and energy into optimizing those. The thing is as SEOs, we tend to focus our recommendations on site-wide issues. You know, we give an audit and the audit kind of looks at stuff like across the whole site. But the more that we dice and slice our data, the more informed decisions we can make at that point. So there's no reason to put forward recommendations that are gonna impact such a small portion of the site. If I know that a specific section only drives like 10% of revenue, then why would I spend a lot of time kind of giving recommendations on that section? So instead, we need to focus our efforts on the template that drives the highest revenue. So in our examples case and the one I'm gonna be leading with, it happened to be our product listing pages. But before I go ahead any further, I just wanna say hi to all our non-e-commerce folks in the audience. I know there's a lot of you. I'm a little worried that you're gonna tune me out. So please do not tune me out just yet. Even though this does feel like an e-commerce focus talk, some of the recommendations and the learnings that I'm gonna share, they can be applied to any website type. Because all websites are template-based. All websites have that one template that makes the most difference. And I'm sure that even before you dive into the data, you kind of know that about your own websites and the websites that you are working on. So this is using Zoopla, which is a marketplace aggregator website for property. So here's an example of a category page that they have. This looks at their new homes for sale. And then this is an example of what their version of a product listing page looks like. Once you actually look up a certain location or a zip code, you're gonna get all these different properties listed. And then this is an example of what their PDP or their product detail page looks like. Once you dive into an actual property that I definitely will not be able to afford. And then this is everything else. So this is examples of what their homepage looks like and their blog posts and so forth. So if you take one thing from this section, it is to define your one template that is worth optimizing. Okay, let's do this. So the second part is all about the discovery. So this is like my brainstorming. I knew at that point based on the data that I wanted to focus on product listing pages. But what am I gonna do about them? Now if I Google product listing pages, this is what it is for people not too familiar with e-commerce. It's basically the page on your website and we've showed a lot of examples that presents a list of products based on the category or the search query. So here's a few examples again. Etsy, very popular in the UK, also in the US. This is a PLP for their drink and bar where page. You can see here there's a bread crumb up there. The products are listed on the side. You've got the heading and then you've got your filters. ASOS, I'm gonna use them a lot as examples. So they are UK fashion e-commerce site. This is an example of their PLP. You can see like the product up there and then a little description, even some internal linkings for related links. This is what it looks like when you compare it with the mobile version. And traffic in general tends to fall directly on PLPs via different channels. But if I were to focus on what pathways people actually get to when they're on the actual website, you know, it can be very different. The journey can be different. So someone can go on the navigation and from there they can find themselves landing on a product listing page. Or someone can do an internal search on the site and from there end up going to a product listing page. Or you could be on a category page like the example we saw with made and then find yourself go on a PLP. Or you can be on the actual PLP itself and then you can set up some filters and from there you end up landing on a new product listing page. So it's really important that we break a template down into its building blocks. But the thing is you're always gonna have site-wide building blocks like your navigation and footer. But I'm not gonna focus on those in this talk. Instead I wanna focus on what are the building blocks that could be unique to each template and in our example, the one that's unique for PLPs. So let's use ASOS as our primary example now. So I've got my product name up here. I've got a product description down there. And then I've got my breadcrumbs. I've got relevant links. In this specific example, you might not be able to read it but it goes to the PLP for sleeveless blazers. And then I've got all my filters here. So if I were to kind of split that PLP into its building blocks, I would categorize it into you've got your content stuff, your internal linking and then your tech stuff. And this is what it kind of looks like. You know, name and description falls under content. Breadcrumbs and relevant links would fall under your internal linking. And then everything filter related would fall under tech. And I'm gonna explain why in a little bit. But before I go on Twitter and I see a whole bunch of how come you're not talking about page speed or how come you're not talking about JavaScript? Why is it that not included in tech? The thing is, even though these are all things to consider from a tech standpoint, in this specific example, what I really wanna do is define our templates building block. Now, I'm gonna ask this in an SEO conference, which is not the right thing to do, but I really want us all just for a minute to take off our SEO hat and to put on our product hat instead. So if I were to start diving into these one by one, when I talk about content, just some examples on what I mean there and how we can optimize some of it. Using the ASOS example, you've got, you're heading markup up there. And this is usually something that you put on an H1 and it's very important for it to be targeting your main key term. And then you've got, it's really important for you to be optimizing your description here. That block of text usually makes the most difference between one PLP to the other. And then mobile parity is something very important to consider at that point. You see a lot of e-commerce websites where their product listing pages can look completely different, desktop versus mobile. And there's a lot of important information that might be missing from their mobile version. Hidden content is also something to think about and how does JavaScript actually render some of these pages and what is it in the HTML? Are you even able to be crawl for it and ranked for it? And then thin content is also something to consider. That tends to be a problem when it comes to a lot of e-commerce sites where the content is very, very thin. And so it's very difficult to actually understand the difference between one PLP to the other. And then when we dive into internal linking, which is actually one of the most important things when it comes to e-commerce sites, I'll show a few examples based on different sites. So breadcrumbs, of course, is very important. And again, with that, what tends to happen is it might be really good on desktop, but then people might forget about it on mobile. Relevant links is another important example there. We saw the women blazers pages on ASOS do it by linking to sleeveless blazers. And then the content blocks. So here, I'm giving an example from the website I work on, which is Papier. This is their weekly meal planners page. And what we do is we tend to write content that's relevant to our PLPs. So for example, something along the lines of, well, how do you actually make the most out of your weekly meal planner or how to use it? And then we would internally link from the PLP within that content block to that specific block post. PLP cards is another way we do it, and it's really visually appealing. So within all of your products that are listed, we would add a PLP card, and that could go to either another PLP. In this case, for example, we link out to our recipe journals within our weekly meal planners because we feel those are relevant, those could be connected, and it makes sense to help drive users to something else that they might be looking for. So then the tech part, which is really what I'm gonna be focusing on for like the next 20 minutes or so. So filters can make or break an e-commerce website. And websites generally tend to have filters set up in one or two ways. So they either attempt to, index absolutely everything to capture as much ranking opportunity as possible, or they could decide, well, you know what, I'm just gonna no index a huge chunk because I really, really don't wanna suffer from index bloat. But if we attempt to index absolutely everything, then Google might not end up crawling all pages. They might not end up indexing all pages. Our valuable pages might not end up being crawled and or indexed, and our valuable pages might not even rank. So that's kind of out of the question. That's not something that we wanna go ahead and do. Well, what's gonna happen if we decide to no index a huge chunk? Well, we're probably gonna miss out on ranking for a lot of potential. So both options don't really work. And I guess the question that we're trying to get to is how and where do we draw the line? Now, where's the opportunity? If I look at all my different examples from Etsy and Papier and ASOS, these are all the different filters there. But when I say opportunity, I don't really mean search demand at this point because if you look at these two different examples, you know, the word dress or then the word maxi long sleeve dress. Yes, of course the word dress has over 800 more, you know, search demand than the word maxi long sleeve dress. But we all know which one is more likely to convert. Opportunity should be measured on conversion, not just on search demand. So the question then doesn't become which one has the most opportunity, it becomes which categories will more likely lead to users converting. And you know, in order to assess that, I now want us all to try to wear our customer insight hat. And it's okay, there's no pressure if you don't have one because to be honest, I don't have one either. But instead, what you can do is you can go ahead and you can speak to your customer team or you can speak to your CRO team, your conversion rate optimization team or you can speak to your data team or you can speak to your marketing team because they hold a lot of that data in their hand. And once you have the data, what you can do is you can sift through it to understand what's the user filter interaction look like and what are your most and least clicked filters and what are some of the internally searched terms that happen on your website that lead people to specific filtered PLPs and what are your high converting filters? And yes, it's okay. You can still look at search volume data. I'm not completely getting rid of it, but do not base your entire strategy around it because it is only one metric after all. And the thing is as SEOs, and this is something that took me a very long time to learn as well, this is where we tend to go wrong. We tend to look at data that we care about without really considering metrics that other teams care about. And again, to put it more accurately, we only look at data that we are measured on without considering metrics that any of the other teams are measured on. So I guess if you were to take one thing from this section, it would be to align yourself with metrics that other teams are measured on and then you're more likely to get their attention and their help. Okay, so let's go to the implementation part which is like the part that actually matters from all this. So if we were to dive deep again into our filters section and see what I've decided to do, we know that we wanna come up with certain rules that we should apply for the filters that we wanna surface. So if I were to give an example from Papier, we looked at all of our data and we found out that the two filters that actually matter, the ones that users convert for and also the ones that do have search demand happen to be color and style. So for one chosen filter, what I wanna do is I wanna generate an indexable URL. I wanna set a self-referring canonical tag. I wanna make sure that that URL is added to our XML site map and I want to make sure that I update our on-page meta tags to be reflective of that filter. So this should only apply when someone chooses one filter, not a combination of four than one. So if someone goes and picks a specific color or a specific style, this is when I should apply these rules. So what happens if someone goes ahead and picks a color and a style as a filter? So in this case, for more than one filter, what I want to make sure happens is the complete opposite. I want to generate an unindexable URLs. I want to make sure that that URL becomes disallowed in robots.txt. I wanna make sure that this URL is not included in the XML site map and there's no need at that point to update any of our on-page meta tags. And that same rule should be applied when I choose a filter that I do not want to surface. So in this example, designer. Designer is a filter for different people, designers who have designed certain products. I know that that's not something that leads people to converting very much and it's not something that has search demand. So in this case, for an unchosen filter, I'm gonna do the exact same as more than one filter. I'm going to generate an unindexable URL. I'm gonna make sure it's disallowed on robots.txt. I'm not gonna include it in the XML site map and I'm not gonna update my meta tag. So I love a flow chart and so if we wanna summarize that logic in a flow chart, this is what it looks like. This is what I'm gonna do to my filter rules. For one chosen filter, I'm gonna go ahead and make sure that what we just discussed gets applied, which is generating an indexable URL, having a self-referring canonical tag, making sure things are in the XML site map and updating our meta tag. And then for our other two rules, which is an unchosen filter or more than one filter, I'm gonna go ahead in the opposite route, which is making sure it's an unindexable URL, not having it in the XML site map, disallowing it and not updating our meta tags. So once I have that flow chart, that's basically what I deliver to my developers. I don't sit down and go through the whole brainstorming. They don't give a crap about anything I just said. What they care about is that flow chart, because that's what they can go ahead and automate. Because automation is key, you're gonna have a lot of filters that come in and go out, but you need to make sure that you have that summarized and it's something that's sustainable and you need to make it future proof. So as long as we brief in the exact rules that need to be applied, at that point the implementation can easily be automated. But before we make any changes, we need to actually have a plan for measuring that change because if I go ahead and change that whole architecture and then I don't have a benchmark set, how am I supposed to even know if this was a successful rollout or if it didn't matter at all? So things that I did to set a benchmark were look at the current number of index pages. I wanted to check how we currently rank for filter keywords. What's the current organic traffic that comes to our product listing pages? And more importantly, which is the KPI that I'm being measured on, what's the organic revenue that comes to our PLPs? So what do I do after that? I actually get stuff implemented or I have a team who gets stuff implemented. And for anyone who's seen my talks before, they know that this is usually the part that I'm gonna tell you. I'm sorry, I have nothing to share. I spent a full year fighting for Dev resource. Nothing happened. Please take it away and do it yourself. But you know what? Even though this was quite a substantial architectural change, I have a plot twist to share. It was fully done in two sprints only. Yes? Yes. Yes. This never happens. We've all been doing SEO for so long. Recommendations do not get done in two sprints. But you know what? Welcome to the joy of SEO sitting in the tech team. So maybe if you take one thing from this talk, it's just get out of marketing, to be honest. But here's also a few things that I decided to do, just to be on the super safe side. I made sure that I tested everything in a staging environment. And I avoided a site-wide push. So we broke things into iterations. We have several markets and we initially only targeted the smaller traffic markets before going ahead and pushing it to the higher traffic market. And we had a rollback plan in place, just in case things go wrong. But I'm gonna be really honest with you. So I wasn't even sure, you know, I overthought whether I'm gonna keep the next slides in. But you know, here goes, hopefully I don't regret it. I overthought every single aspect about that filters recommendation before writing it in a ticket. It took me more sprints to write that ticket out than for it to actually get implemented. Because you know, I come from the world of aggregator websites. And over there, I'm used to de-indexing pages. What I tend to do is I say, we need to de-index a whole bunch of stuff. But this time around, what I was doing is I wanted to surface new filter categories. So this was gonna result in, you know, tens of thousands of pages potentially becoming indexed. And the idea just absolutely terrified me. Because, you know, things that I kind of thought of at that point was, what if something went wrong? And what if my recommendation was completely wrong? Maybe that wasn't the right way around it. And what if we ended up losing visibility, traffic, revenue? But to be really honest, like here's the point that really scared me. There is a difference between writing a ticket, knowing it's gonna be a while until it's picked up, and writing a ticket, knowing it's actually going to be in the next sprint. There is something that feels both exciting and terrifying about the idea that they're actually going to implement what I'm saying. And I don't know if thinking and feeling that could potentially make me a bad SEO. But I really hope that by being honest with you right now, it helps us all open up about these internal feelings that I hope I'm not the only one thinks. Okay, so the results. What really happened, and I'm gonna be honest here as well. So I'm gonna start with the good news. The rollout was a success. Everything functioned as expected, and nothing broke. Which you know, we're not used to seeing. I work with some really, really smart engineers to be honest, and they nailed the implementation. But I'm also gonna give credit to myself, which I tend to not do. You know, I did a very thorough job briefing in the recommendation. So what's the not so good news? Another plot twist coming up, and this one will not require any clapping. Nothing happened. No impact. None whatsoever. I have no shiny upward graph to show off. I wish I did. I waited for six months. Nothing happened. But why? What went wrong? We know the recommendation was spot on. So remember my whole brainstorming, this whole framework? I was so fixated on the filters part that I completely forgot everything else. My recommendation was spot on, but it was never gonna be enough to have an impact on its own. We need all this to work out. It's not enough to only focus on this bit. So I am used to working on websites that have over 10 million pages. So when you work on those websites, tech changes tend to have a massive impact. But this isn't necessarily gonna be the case on a very fresh, small e-commerce website that's pretty much tech debt-free. So in my discovery, I did plot out everything that needed to be done, but what I ended up doing is what we usually end up doing, which is focus on what I had most control on purely based on where I sat. Because just because I now sit in the tech team, it doesn't really mean that I have control over the full process. So the other parts of my recommendation, like they needed me to engage with the content team and the trading team and the marketing team, I should have made them a part of my strategy from the beginning. You know, I always spend a lot of time preaching the importance of prioritization with tech teams. Some of you might have seen some of my posts about this where I talk about the importance of getting tech implemented and how you need to prioritize based on their impact as well and their effort, but why didn't I end up doing the same with other teams? I think I kind of thought that because I now sit in the tech team that I haven't all figured out, but you're never in the perfect place and the grass isn't always greener where you are. SEO is so cross-functional and no one has properly figured out yet where it should sit. So we need to have these honest conversations to learn more about what's working and what's not working. And as a SEOs in general, we need to find a way to work well across teams. But also we have to share these learnings. Like you've kind of learned from me today some of the things that worked being part of the tech team and some of the things that didn't. So the more we share these as an industry, the more we can learn from each other and the more we can hopefully figure out a framework on where exactly SEO should sit. So I'm just gonna leave you with one final thought. So back in Moscow in 2019, I stood on this very, very stage and I told you that technical problems are people problems. And then last year, I talked to you through the virtual stage and I said that as SEOs, it is fundamental that we do not work in silos. So this year, I was hoping to let you know how important it is to dive deep into that one opportunity that will help you deliver value. But also it's really important to ensure that we actually do that cross-functionally. And our job isn't just about knowing SEO, it's about being effective. Thank you so much. Thank you.