JavaScript redirects are one of the methods available to webmasters in communicating to both users and search engines that the requested URL is unavailable, either permanently or temporarily. The URL you are then served should be seen as the alternative or new permanent.
Typically best practice echoes that you should use server-side 301s, 302s, or 307s.
Usually, servers hosting JavaScript (JS) applications are Nginx servers, with configuration files where one can always implement server-side redirects, which is the recommended way by Google.
However, let’s take a look at headless website architectures, which are becoming increasingly popular. We notice that not all headless builds allow for server-side redirects and rely on client-side implementation – these being JavaScript redirects.
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.
In terms of how JavaScript redirects work, they are typically implemented through the window.location.replace function, and work well for users.
But how well search engines interpret them is open to debate.
In Google’s Search Central documentation, the search engine warns that you should:
Only use JavaScript redirects if you can’t do server side or meta refresh redirects.
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).
But by contrast, as recently as 2020, Google’s Gary Illyes has publicly stated that JavaScript redirects “are probably not a good idea.”
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.
How To Implement JavaScript Redirects
The most common method of implementing JavaScript redirects is through window.location.replace, for example:
window.location.replace(“https://dantaylor.online”);
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.
Similarly, popular headless CMSs like Jekyll and Strapi come with prebuilt modules and plugins to ease the implementation of redirects.
How Google Processes JavaScript Redirects
Like JavaScript rendering, Google executes JavaScript in a two-step process and relies on the Web Rendering Service to process.
You can read more about how Google processes JavaScript here.
For the purposes of this article, however, it’s important to highlight the nuances of JavaScript and how Google often says multiple things about it – and how we, as SEO experts, interpret this.
In 2019, during the Google Mythbusting videos, Martin Splitt highlighted that you should use JavaScript “responsibly” to help prevent content from “lagging behind” in Google’s process.
In 2020, as highlighted by the Tweet earlier in this article, Gary Illyes opined that using JS redirects is probably not a good idea.
During a 2021 episode of the Search Off The Record podcast, the Google advocates highlighted that you shouldn’t have any issues with JavaScript, as long as Google can see the page’s critical (value proposition, beneficial purpose).
Relating this back to JavaScript redirects and how Google processes them: When Google encounters a JS redirect, the search engine first has to render the JS, identify it as a redirect, and then “follow” the new path.
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.
In another SEO Office Hours recording from January 2020, Google highlighted that JavaScript redirects do take longer to process than server-side redirects. You can watch that video here.
For reference, Google’s Search Central documentation around redirects first included JavaScript redirects in June 2021, so in terms of the overall “SEO timeline,” this is still quite new.
Do JavaScript Redirects Work For SEO?
Referring back to Google’s Search Central documentation and the implementation of JavaScript redirects, it extends the warning around using JavaScript redirects with the following:
While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.
This ties in with another technical SEO favorite: rendering.
More specifically, what can happen should the Web Rendering Service fail to execute and render the JavaScript for the redirect?
If, for some reason, Google fails to execute/render the JavaScript, then Google will load the initial request URL.
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.
To mitigate as much risk as possible, when implementing JavaScript redirects, you should:
- 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.
Research into this is more than seven years old and available through Wayback Machine. But the logic, theory, and previous studies suggest that PageRank does flow on a JavaScript redirect as it would a server-side redirect (once Google has had the opportunity to process it).
More resources:
Featured Image: duangphorn wiriya/Shutterstock
