Typically best practice echoes that you should use server-side 301s, 302s, or 307s.
Whilst some headless CMS platforms have provisions in place to configure redirects either at a server or application level, one of the benefits of moving to a headless architecture is that you’re no longer running a monolith but a microservices model.
Because of this, developers will look to reduce dependencies and create flexibility in the stack.
Managing redirects in the front-end (e.g., Vue.JS) means you can change CMS with one less consideration.
That’s where we, as SEOs pros, need to outline and establish URL redirect capabilities when a client is looking to migrate to a headless architecture or any other form of JAMstack tech stack.
But how well search engines interpret them is open to debate.
In Google’s Search Central documentation, the search engine warns that you should:
And with their inclusion, it eludes that they work for Google and from an SEO perspective (anecdotally speaking, this is definitely the interpretation that many developers have had).
Js redirects are probably not a good idea though.
— Gary 鯨理／경리 Illyes (@methode) July 8, 2020
This was in direct response to a thread around internationalization and redirects. Nonetheless, it raises questions as to why they might not be a good idea, potentially reaffirming that Google’s documentation warns against using them as a priority solution.
If you open Dev Tools (CTRL + SHIFT + I) and enter the above line in Console, you’ll go to my website homepage.
Another method of implementation is through window.location.href, but this can cause user issues.
With the replace method, when a user clicks back, the browser will load the previous page – but with the href method, the browser will load and redirect the user back to the same page they were just trying to leave (as it’s stored in the navigation history).
This causes a UX redirect loop/trap, leading the user to close the tab and have a negative experience with the website.
For many popular headless platforms, like Gatsby, there are pre-built methods of handling and implementing redirects.
In Gatsby, you can install the gatsby-plugin-gatsby-cloud, and implement 1:1 redirects, wildcard redirects, and “splat” redirects.
In 2020, as highlighted by the Tweet earlier in this article, Gary Illyes opined that using JS redirects is probably not a good idea.
This costs additional time and resources (two things that Google limits on websites, which we often simply call a crawl budget).
Because of this, Google strongly prefers server-side redirects (the traditional 301, 302, 307) to JS redirects.
This has been reaffirmed by Google as recently as June 2022 in an SEO Office Hours video.
This ties in with another technical SEO favorite: rendering.
Depending on your setup, two things could happen:
- It will either be blank or result in a soft 404 error in Google Search Console.
- It will return the original page content, process it, and then begin to process it as “normal,” which isn’t ideal if you want that content to no longer be accessible.
- Remember that Google is stateless; any front-end redirects shouldn’t rely on local storage or HTTP cookies (aka data persistence).
- Don’t rely on user permissions to initiate the redirects, as Google declines user permission requests.
- Don’t use fragment URLs.
- Reduce internal linking to the “original” URL and remove it from the XML sitemap, ensuring the new “destination” URL is there instead to give consistent signals to search engines.
A last note, touching on link equity and the distribution of PageRank/link equity.
Featured Image: duangphorn wiriya/Shutterstock