Headless SEO: I'm Sorry, But This Is Happening by Lidia Infante | MozCon 2023

10 9 8 7 6 5 4 3 2 1 All right, everybody. I'm so excited to be back at Moscon. This is really cool. It's one of the most intimidating stages that one can speak at. So, I was just like shaking backstage. Um, so anyway, let's talk about headless SEO. Is SEO dead? Well, Tom Caver told me not to make this meme. He said it was tired. Thank you for doing that. Um, something wonderful about this industry is that it dies and is reborn like 30 times per year. Do you recognize this face? This is Barry Shorts. That's when he started. This is what he looks like now. This is what the industry is doing to us, guys. And that is exactly the way that I felt when I learned about headless SEO. I was like, now there's another SEO to learn. I was ready to quit to be honest. But the truth is that headless CMS are on the rise. So headless SEO has become quite a crucial skill. Can I see a show of hands? who's on a headless CMS. Yeah, there's more and more every year. Um, we're going to talk about what is headless SEO. And I made a bit of a small definition here, but many of you might not be familiar with what is a headless CMS exactly. So, I'm going to try to cover that. A monolithic CMS looks like this. This is your classic WordPress. Um, it has a database and an admin interface. The admin interface is the bit where you type your URL/admin and go in there. And then the view layer, which is typically a website. The headless CMS ties up the database and the admin interface, but it doesn't have a view layer. So, it can deploy your content onto an app, digital signage. Um, if your content is video, you can automatically upload to YouTube, to reals, to Tik Tok, whatever your developer is able to make. Um, and it also allows you to integrate quite directly with some of your providers. When I've been uh talking to people who work in headless CMSs, I have found that there is a disconnect between developers and content creators and SEOs when it comes to what is possible within the CMS and in the website. Developers might not know what is possible. You might not know um exactly what you need. So dev SEO relationships are more important than ever. That is why I went ahead and married one. All right. I don't even like the guy. This is just for you. This is for SEO. So, let's talk about how headless SEO is a little bit different because otherwise it looks like yeah, it's SEO but with a CMS that's a little bit weird. Headless SEO starts with content modeling. And this is the first bit that we're going to talk about. And I'm going to be here for a while because it took me forever to understand the concept. Content modeling is the process of defining the types of content that you need, the attributes of each one, and the relationships between us. This means nothing. Basically, we have content, content types, attributes, and relationships in between them. So, I've told you that I married a developer, right? and he is in charge of buying groceries, but if I don't get what I want, I get violently hungry. So, he decided that he wanted to automate this chore of having a shopping list. We decided to build a shopping list generator. And to build this, we had to sit down like literally in our kitchen with a whiteboard and start content modeling. So what he wants is um list of what to buy a list of ingredients based on a list of recipes that we are going to make. We have one content type shopping list and this content type includes recipes and it includes well includes recipes which then bring in ingredients. Hopefully this is going to make sense. A recipe has a collection of ingredients. The symbol at the end of ingredients means collection of um

cooking time. It has instructions. It has an image. It has nutritional info. If you work in a recipe site, you are familiar with this because it's very close to the recipe schema that you're working with. And then each of the ingredients has nutritional info, whether or not they're a pantry staple. So, we don't buy olive oil every time that a recipe asks for olive oil. Um, allergen info, and because he's vegetarian, whether or not he can eat it. So, here we have content types. Their attributes would be the bits listed below. Um, and the relationships between them are the uh fact that one is a collection of the other. Um, we didn't just type this in. We used some data sources that we integrated um, an ingredient database and a recipe database. So, we didn't have to like write it all out. And because I'm a marketer, I looked at this beautiful piece of software that he had built and thought to myself, how do we monetize this supermarket APIs? So what he does now and it saves us a ton of money. Um he we select what we're going to eat in the week and then we put it in the software and then it pulls uh the prices of supermarkets around us from the API and then we understand where it's cheaper to go shopping. This is pretty obvious but if you are structuring your content from the get-go it is a lot easier to you to add structured data to your site. Something that I didn't understand even when I thought I understand content modeling is that we all have a content model. Um it's just not an explicit one most of the time. And your CMS, even if it's a traditional CMS, also starts with content modeling, but you don't have control over it. Another interesting thing about doing SEO for with a headless CMS is that you unlock um the omni channel. there's like the never- ending promise of um publish it once, reuse it forever um that most CMSs have not been able to like deliver on. Um but the truth is that search behavior is changing and users are searching across more and more channels. We've all seen this article. It came out a while ago. Um and it was Google saying visual search is a thing now. Get on board. I have an Android phone. So Google pings me like don't type just use a picture. Um and according to Google um people now use lens for 12 billion visual searches a month which is um a lot more than I thought. So if we uh take into account how content has become more and more omni channel content reusability becomes key for SEO. Another article that everybody here has probably seen is this one where we thought that Tik Tok was taking over Google. There's some interesting things that Tik Tok is doing though. Going back to the recipe um schema reference, if you have a website where you have your recipes, you can and you you're using recipe schema and you publish a video on Tik Tok on how to make the dish that you're making um through a third party, you can integrate that schema into making that little tiny um web page in there for yourself and drive traffic to your site with Tik Tok, which is not something that's that easy to do if you're simply posting videos. And as we're going omni channel, keeping the content consistent um becomes like really difficult without a central source of truth. Otherwise, you need to go and change everything everywhere. But if you have a central managing point, it's a lot easier. And the truth is that inconsistent content can damage your brand. If you have uh opening hours and your website that don't match the opening hours on your Google My Business profile, um like you are creating a very poor experience for your users. They don't really know when they can come or not. Then, well, I've been talking about like nice stuff, but there's like bad stuff as well. You've got limited plugins and add-ons. Um, we're all used to using Yos for example, and it's just no bit of the graph, the custom integrations. Um, the concept of plugins itself, uh, they're created to extend the functionality of your CMS. So what uh WordPress couldn't do initially like you add in a plug-in and you are extending that functionality but um what we're trying to do in the composable era is um just connect different systems through an API that talk to each other instead of making plugins. And you can have plugins. It's not as easy though as it is with traditional CMSs where you just plug them in. There's a whole community of devs making them. Apparently, they're less risky because they cannot run code on your server. Um, but the truth is we don't have a lot of SEO plugins yet. Now, what everybody asks me is, is headless better for SEO? But it depends.

The thing is, and this is tricky when you're talking about headless SEO. Traditional CMSs can be perfectly fine. More gut rails, less fuckups, but it's also less potential for greatness. Now, when I'm here speaking to you and like after I do this vid and talk to you about when it's better to go headless and stay traditional, um, I'm going to talk to you about basic implementations that put the guardrails on onto your headless CMSs. But the potential aspect of it, it's all down to you. your creativity and what you think you can do with your content. I can tell you about what I've done, but um headless SEO presentations are inherently a little bit boring. Anyway, traditional CMSs will require development resources too. Um but a headless CMS can help you do a little bit more. I would recommend that you use headless CMSs in a bunch of use cases. When you do a lot of content reuse, headless CMSs can be really, really helpful. internationalization. I have found it miles easier uh with headless CMSs. Something that I've been able to do is um look at my content model and say this content attribute is a low stakes translation. So to go to market faster, we're just going to integrate with Google translate and make this go and then add a layer of um traditional by hand uh revision because you can pretty much connect it to anything that has an API. So if you have a business with a very volatile um stock and inventory, you are quite better off working with a headless CMS. So here we go. These are the seven tips for a flawless headless SEO setup. These are the guard rails that you have on traditional CMSs that will prevent the fuckups on headless CMSs. Request all the key meta tags. We are absolutely spoiled with our technical implementations on traditional CMSs because we don't even have to think about it. But an article is going to have a bunch of code here in the head that we need to request specifically to our developers and fit within our content model. Otherwise, it's not going to be there. Remember to request title, meta description, meta robot, the viewport. for some reason it falls onto us the content type, open graph tags and language tag. And you can even include validation rules for these fields. For example, you can program into the CMS that the language tag only me uh matches the ISO for international SEO and you'll never have silly href lang mistakes again. Um, which is really cool. Always give your request that your um content editors can have an editable URL slug. Now, some of the people that are touching your website should not be anywhere near the URL slug because we don't want them to change it. like ruin our very good um architecture. And it seems simple, but it is not a given. You don't want to end up with that. like an exact replica of your title. you want to do exactly the URL that you wanted to use. Now, you're going to need to set up rules for canonical URLs. And this is even more important if you're an e-commerce. Um, remind your developers to use absolute URLs. This means include the domain and the protocol and tell them to define only one per page. um you're going to have to evaluate your specific needs with a dev team. But a small horror story that I'd like to share with you, um I was at a pretty big enterprise um site a while back and we had a bit of a big hiccup where um whatever URL was displayed in the like the browser was then taken in as the canonical URL and then it would replace the URL that we had in the sitemap. That's a stupid rule, which meant that we had a lot of um sitemap URLs that pointed to like UTMs or Google ads. And speaking of sitemap um bamboozlements, you're going to have to determine and define your XML sitemap setup. This beautiful thing that we get done on some traditional CMSs, forget about it. You're not going to get it. You're going to need to create a validation rule so that only 200 indexable canonical URLs get added. Otherwise, you're going to end up like me with a broken international site. You have to be quite explicit as well. Another issue that we had in that site once we fixed the canonicals thing, um I went back to the development team and I told them, "There's a bunch of URLs

missing from my sitemap. What's going on? " They're like, "Well, we created the sitemap that you requested two months ago. " And I'm like, yeah, but a sitemap is dynamic. Like you have to update that. Um, so you can make different arrangements with your development team. Um, what I recommend is if you're running a small site or you're not in e-commerce, just define a preferred update frequency for the sitemap. If not, you're going to have a very like explicit clear conversation of what you're trying to accomplish with your sitemap. um and tell them again only indexable 200 and canonical URLs can go in there. But what do you do if um a URL is dropped from your sitemap because a product runs out of stock? You're going to have to define exactly how you're going to manage that. Now you might find that your sitemap for whatever reason cannot live in the root. So do indicate it in the robots txt file. And depending on your vertical, you might need to request image sitemaps, uh, video sitemaps, or sitemaps for news. Then you're going to want to make room for structured data. And to me, this is one of the most exciting bits that I've been working on. Um, actually since I delivered this deck, I've tried a bunch more things and it's really, really fun. So add validation rules to avoid breaking Google's guidelines when you when you're surfing the web. The easiest way to know if a company has an SEO on like the payroll or not is if there's an FAQ section at the in the article, right? You go there, you scroll down, and at the bottom you've got like a bit of an FAQ frequently asked questions that nobody ever asked that are just scraped from BAA from for the people also asked uh feature um with answers that are recursive or have already been answered within the main content. What I have done is every time that one of our headings um ends up with a question mark that becomes a question for FAQ schema and the immediately below paragraph becomes the answer and then I have put a little rule little trick in the CMS that flags up to whoever's writing hey make sure that the paragraph below um answers the question fully and dive deeper afterwards because this is going to show up on Google search like this and then it comes with a screenshot and so far nobody has messed up and that's really nice. Another thing that you can do and that I've been enjoying is um build on EAT. So I have a lot of author profiles that I work with and I've put them through like a chat GPT thing where I go make a person schema and I've gone through many iterations of this. What I have working right now um is I have a workflow where chat GPT grabs the um author bio and it outputs a person schema but it also um tells me what this person knows about and what this person talks about and I put it in there explicitly. Um, I think we also have the same as when um there's a Wikipedia entry that matches the um the entity very closely. So that's really good and you can add it in bake it into your CMS to avoid um breaking Google rules. You can put it in um at document level or at field level and then you can like ask the final code to have two entries on the head is usually fine. Um, and you can combine structured content and AI, which I find also really exciting. I have already talked about this. I forgot that I had a explicit um slide for it. One of the things that happens when you're doing headless is that you stop talking or thinking about pages and you start thinking about content that you kind of compose together and pull together onto whatever surface your content is being consumed which can be like Google watch or an app or even um the ordering kiosk for Burger King. So you're going to start talking and thinking about heading hierarchy in a different way. And I know that it's not that important for SEO anymore, but it is key for accessibility. You have several options to make this happen. You can build a module library where you compose your pages um knowing which ones like which modules have which headings and then you control that kind of manually. You can have a flexible module that you use for everything and then the heading gets determined at module level or you can create rules on the front end that ensure that the headings um are valid every step of the way. Now, because headless CMSs uh sit mostly

on something called the Jamstack, u the Jamstack is um I don't know, it's like a bunch of JavaScript developers that got really happy on a night out drinking together and created an entire framework to deploy content to the world. Um so, it is very JavaScript heavy. We're going to have to treat our uh site as a very JavaScript heavy site and we're going to have to perform a parity audit to make sure that the content that we think we're putting out into the world is the content that gets rendered. Remember that Google doesn't scroll or click. If it's not in the source in the rendered source, it's not there. So, make sure that all of your key content and internal links appear in that rendered source. There's other places where you can find mismatches. Um, it could be in your metadata. It could be within the canonicals or content. You absolutely don't want to bring those mismatches onto your live site. So, I recommend that you perform this parity audit before you go live. if you feel like trying it out. Um, we are trying to be friendly SEO community as a company. I am also trying personally, so go find me at the drinks after. Um, and we have a free boosted plan on sanity that you can use. Thank you very much.