AuthorSamuel Hurley
LinkedIn
We often get asked by clients “Is headless bad for SEO”? Or “how does a headless set-up impact SEO”? Or a more broad but related question: “Can Google still read a headless set-up if the front end is all JavaScript”?
So…
Here’s our incredibly simplified and top-level answer that we give to those (and related questions) as well as a comparison vs the other major platforms of choice for an eCommerce brand. There’s little scientific evidence behind the numbers below; they’re just based purely on our experience of working with over 150 eCom brands. If you want more detailed insights into Headless & SEO see our simplified SEO guide to headless.
As with most things in SEO, ‘it depends’ and there are many more caveats to throw into the overall answer.
Our usual outline goes something like this:
- Shopify: With Shopify, out of the box your SEO is likely to be around a 5 or 6 out of 10. We can help to take that to around an 8 out of 10 but due to platform limitations, we can’t take it to a perfect 10 out of 10 for onsite SEO.
- Magento: Magento on the other hand, out of the box your SEO is likely to be a 1 or 2 out of 10. We can help to take that to an 8 out of 10 maybe even a 9 out of 10, however again due to platform limitations, it’s unlikely that we’d be able to get it to a perfect 10 out of 10.
- WooCommerce: For WooCommerce we liken it similar to Magento, however out of the box it’s more like a 3 out of 10 and we can get it up to an 8 out of 10 (depending on the size of the catalogue and initial set-up).
- Headless: In contrast, a headless set-up (on either platform or alternative), and with the appropriate JavaScript set-up (more on this below), out of the box with no support your SEO is likely to be a big fat 0 out of 10, however, we can help to take that to a perfect 10 out of 10 onsite SEO set up. This is due to a completely customisable front-end, resulting in no platform limitations.
Our backend preference?
When you migrate to headless the backend largely becomes redundant from an SEO perspective, and our focus shifts to the front end JavaScript framework and how this is translating to the back end and getting rendered.
This is because with a headless set up the back end has now been separated from the front end. It’s the front end version of the site that Google will be crawling and rendering. The developer can code the front end in their favourite language (see JavaScript reference below), not needing to worry about back end technology (or limitations). The back end and front end then connect via APIs.
We’ve worked with Prismic and Contentful as headless only platforms to serve the content to the user which both work well from an SEO perspective.
The way these platforms serve content can impact SEO. As a quick example, Contentful uses a large number of tags to manage and connect content, these tags can be shown as pages on the front end of the site, if these are in the sitemap Google will be finding them and indexing them. It will depend on your SEO strategy whether this is something you want to be happening or not.
Front-end JavaScript
There are a few options here. Our preference is either React or Angular. See our Guide to React SEO here and our Guide to Angular SEO here.
Angular Universal is our preference, as it’s server-side renders directly in the framework. Older versions of Angular will require more work (see below).
It’s super important to serve your rendered content to Google when using JavaScript. This is where the myth comes in around Google being unable to read JavaScript.
Google can render JavaScript (with other search engines it’s a mixed bag), however, the process is much more resource and time-intensive than simply crawling the source code.
Headless sites generally contain very little information in the source code and are fully reliant on rendering the full DOM to be understood.
Preferably you render directly from the server. Next JS with React helps to tick this box. Make sure you test and test again and then test again every month (week ideally).
If server-side rendering is not an option then tools like Prerender.io will do the trick. These tools store your rendered content in a cache and return this only to search engines. Customers using a standard user agent will get the normal client-side rendered site. This is a middle ground which can sometimes be easier to implement than server-side rendering.
Headless caveat (and it’s a big one)
Due the dynamic nature of headless and the multiple components that go into a larger tech stack, only consider Headless if you have enough resource to maintain and manage the platform, as well as additional resource on the top to focus on growth initiatives.
We have direct experience of this as an agency. We migrated our own website from standard WordPress to Headless WordPress. We’re only a small team with 1 person in marketing therefore we’ve faced challenges with doing basic changes on the website, even uploading a blog takes twice as long as standard WordPress, any changes we need to make to the site we require a specialist (and more expensive!) developer to make basic design or build changes. The trade-off being our site is super fast and doesn’t have loading issues we used to have on the previous WordPress site.
We’ve worked with many eCommerce brands that have set up headless from the start as it’s the nice big shiny tech they think they should be on. However, with a small dev team, they are literally treading water and the big shiny tech is actually holding them back from growth due to the inability to make basic changes without needing a lot of dev resource.
On top of this from an SEO perspective if they’ve not implemented a form of SSR they’re making Google’s job much harder and causing a drag factor on overall SEO growth (certainly not the intention at the start).
If you are adopting headless early on (or are using it now) consider a dedicated growth team within the development team to support marketing initiatives while the main dev team focuses on maintenance and BAU work. We’ve seen this work well in the past.
We’ve even worked with a brand that actually went bust from migrating to headless with little consideration of the resource and costs needed to maintain, not even considering growth. Of course, a lot more went into them going bust than just the platform, but it was a big factor in restricting their potential and increasing their costs.
If your internal resource is limited then our recommendation would be to go with Shopify. It’s a great platform that will tick many boxes in the early stages of growth. It’s also very difficult to integrate significant errors into Shopify therefore the limitation of its fixed rigidity can actually be a positive if you have limited dev resource.
You can also move to Shopify Plus as you grow which hosts many large brands (Gymshark being one of the largest) then you can consider a headless option once you have the dev resource or in-house resource.
We’re obsessed with headless, it’s by far our favourite platform to work on due to the complexities it brings, the unique challenges each brands set up has, as well as the relatively small set of limitations you get from a standard platform. It’s important to highlight and highlight again the above is an SEO perspective only, if you want a broader perspective (and you should!) then chat to our friends over at Vervaunt, they can assess your needs, goals and resource to recommend the best platform for you.