Discover the essential considerations for SEOs when building headless websites in this insightful Whiteboard Friday by Peter Richman.

Click on the whiteboard image above to open a high-resolution version!

Hi, I'm Peter Richman, and I'm from Plug and Play. We're a web design and digital marketing agency, and perhaps for the last 15 years, we've been using Moz to help improve our customers' market penetrations, increase those conversion rates, and help businesses achieve their goals with their websites.

Over the last couple of years, we've been seeing a real trend of headless websites coming to the market. Different engineering teams, marketing teams, and SEOs that we've been collaborating with have found different challenges and different ways of working with headless to help improve their outcomes.

Today, I wanted to take you through six things that SEOs should advocate for when building headless websites because these are learnings and outcomes that we've seen from real-world projects that I would love to share with you.

Now, when you're thinking about going headless, there are a couple of things to know.

Well, first off, is how headless works. The key thing to understand is that the back-end system, that system that holds all of your data, is separate from your customer experience. Those fields and data are coming over via an API to build that front-end experience.

There are key different ways to go headless. For example, you might be using a headless CMS, but you might also be getting data from CRMs, ERPs, PIMs, or anything else. The key thing is, though, that this data is separate from the front end and has to come over an API.

So there are a couple of things to know. So, for example, engineering and development teams often make some key assumptions, perhaps about how they might go about delivering this. So, for example, we've seen a lot of back-end developers look at headless content management systems and then consider that they have to come up with a progressive web app or a PWA as a front end. But actually, that's not really the case. It's very common. And so, a progressive web app might be something like Next.js. It might be React. It might be Angular. It might be Vue. There are lots of different JavaScript frameworks that you can use to build a front end on top of a headless CMS.

But there are actually other ways of doing it. So, for example, you could use a headless CMS to serve data to a classical CMS and build your customer experience on top of that.

And we've also seen lots of businesses take into consideration of a composable architecture, incorporating lots of data from lots of different sources and bringing it together in a custom experience, which is a mix of progressive web apps, front end, and classical CMSs.

So depending on the complexity of your website and your business and how many people are involved, the key things you need to consider and advocate for I just want to highlight today.

Crawlability

So, starting from the top, classical SEO 101 on crawlability.

The thing about headless is that if you are going for a progressive web app, you need to consider all the progressive web app considerations, and there's loads of information on Moz about progressive web apps. And, of course, you can use Google Lighthouse as well to identify key progressive web app challenges.

But, for us, one of the main things about doing this is having a static front end that's been created and making sure that whatever JavaScript framework you're using, you're not creating that user experience on the fly.

So we want to see server-side rendering, making sure that that HTML is produced on the server and that you can cache that full page cache of all the HTML in situ so it's super crawlable and really fast.

And that's the key thing about this is that crawlability, creating that static page will create a really fast website.

But it does come with some considerations for administrators, marketers, and SEOs. So, for example, how you go about getting content live. You might need to consider how you flush a cache, whether you need to flush the cache globally or whether you need to flush the cache just on a particular page.

So these are key things that you might want to ask about from your developers and your engineers, ideally close to the beginning of the project, so they can bake in their understanding and their thinking about what you might want to achieve as SEOs and marketers within your website.

Speed scores

But those speed scores can be really looked into on Google Lighthouse, and using the progressive web app tools, you're actually able to see those key outcomes that you can improve your website speed scores from.

But bear in mind that all of this data lives in that back-end system, and the key thing you need to consider is that unlike, for example, a monolithic website content management system, so, for example, websites that you can go in and change the layouts and create the fields and then Bob's your uncle, you've got a website that you can actually edit and manage, that probably won't be the case with a headless website.

Tags & categories

And so you need to talk to your engineers and your developers about all the tags and categories, all the fields you need within the back-end system. So that includes everything that you want to put on the front end. The reason is, is that even if you've got the ability to add fields to your headless content management system, that doesn't mean that it's going to make its way over the API and be interpreted by the front end in a way that you want it to.

So, with your front-end interface, it's likely that an engineer or a developer is going to have to hook that up to the API and make sure that's being interpreted in the right way.

So when you're thinking about this, what we'd love you to do is look at all the data you'd want on your pages and all the considerations, so everything from sorting and searching and organizing categories, subcategories, how you're going to manage that data within the taxonomy of your back end so that you have everything you possibly need now and in the future for your front-end interface.

And in that way, you can give your developers everything they need upfront to build you the API that you're going to need and the front-end experience you're going to need to be able to manage that.

Fields for schema & headings

This really rolls into things like schema and structured microdata and headings because a lot of headless CMSs will have specific fields for specific outcomes, and you might find things like titles or headers and so on need to be considered within those fields within the headless CMS.

But schema.org information and structured microdata are ways in which you can actually bring to life products, reviews, or job titles for search engines. All of that stuff needs to be considered and baked into your back-end data so it can come over that API.

URL editability

One of the other challenges we've found with headless content management systems is, depending on the headless CMS and depending on the way in which your developers and engineers go about it, we've seen some challenges with URL editability.

Usually, this is based on individual products or the ways that developers and engineers have interpreted those products.

But we've seen things like, for example, the taxonomy of the data structure within the back-end system actually being used to represent the HTML on the front end from a URL perspective. And so you end up with this tightly bound structure between the data in the back end and the URL.

And what we'd love you to do is raise this as a flag early on within the process and say, "Actually, as marketers and SEOs, we'd love to be able to manage our URLs back to the root and have full dexterity over them. And we'd love to do this separately from the menu management, and we'd love to do this separately from the taxonomy of the data."

This will give you great dexterity between these three things on an ongoing basis and set you up to be able to create different categories and landing pages or elevate content from deep in the URL structure back to the root if you want to kind of make sure that SEO best practices are met on really difficult keywords that you're going to struggle to get high in the search engine results pages unless they are high in the URL structure.

On-page content management

And one of the other things you want to think about is actually on-page content management. The thing about the headless structure and the API system is that each of these fields is almost like a template, and that template then gets generated into a page.

The challenge, therefore is how do you manage different page layouts and content? A lot of us have become used to being able to create a page, change layouts, change structures, and the way in which those landing pages can be created.

But actually, if you're not careful, you could end up going back in time here and having to build pages on a template base.

Different headless content management systems have different approaches to this. So it's partly down to the tool you use and partly down to the way your engineers and developers use that tool. And so bringing those two things together, advocating for, actually, we want to be able to create those landing pages and manage and change those layouts, is a key outcome for us as SEOs and marketing managers to improve those bounce rates and conversion rates.

Otherwise, you may end up with a system where you've got a headless website and then a separate system for landing page management, which is just more software at the end of the day and adds more complexity to your overall website.

So those are the key things I wanted to cover.

So the main things are that the SEO 101s are crawlability and caching; how do you flush cache? What does that publication flow look like? Making sure that that cache is distributed and managed in such a way that's nice and fast, and remembering that all the data that you need is going to have to be talked about with your developers and your engineering teams upfront to make sure it's baked into the back-end system. Do keep in mind URL editability, and also keep in mind that if you edit the URL, we need to think about 301s; we need to think about site maps as well. So just keep that in mind on editability. And how you're going to manage the in-page content on an ongoing basis.

So those are the key things to advocate for from a headless perspective.

I've been Peter Richman, and this is Whiteboard Friday.

Transcription by Speechpad