{"id":15420,"date":"2022-09-15T13:49:27","date_gmt":"2022-09-15T13:49:27","guid":{"rendered":"https:\/\/www.searchenginejournal.com\/javascript-redirects-for-seo\/462072\/"},"modified":"2022-09-15T13:49:27","modified_gmt":"2022-09-15T13:49:27","slug":"how-to-do-javascript-redirects-for-seo-via-sejournal-taylordanrw","status":"publish","type":"post","link":"https:\/\/marketingnewsbox.com\/?p=15420","title":{"rendered":"How To Do JavaScript Redirects For SEO via @sejournal, @TaylorDanRW"},"content":{"rendered":"
<\/div>\n

JavaScript redirects are one of the methods<\/a> 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.<\/p>\n

Typically best practice echoes that you should use server-side 301s, 302s, or 307s.<\/p>\n

Usually, servers hosting JavaScript (JS) applications are Nginx servers, with <\/span>configuration files<\/span><\/a> where one can always implement server-side redirects, which is the recommended way by Google. <\/span><\/p>\n

However, let\u2019s 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 \u2013 these being JavaScript redirects.<\/p>\n

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\u2019re no longer running a monolith but a microservices model.<\/p>\n

Because of this, developers will look to reduce dependencies and create flexibility in the stack.<\/p>\n

Managing redirects in the front-end (e.g., Vue.JS) means you can change CMS with one less consideration.<\/p>\n

That\u2019s 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.<\/p>\n

In terms of how JavaScript redirects work, they are typically implemented through the window.location.replace function, and work well for users.<\/p>\n

But how well search engines interpret them is open to debate.<\/p>\n

In Google\u2019s Search Central documentation, the search engine warns that you should:<\/p>\n

\n

Only use JavaScript redirects if you can\u2019t do server side or meta refresh redirects.<\/p>\n<\/blockquote>\n

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).<\/p>\n

But by contrast, as recently as 2020, Google\u2019s Gary Illyes has publicly stated that JavaScript redirects \u201care probably not a good idea.\u201d<\/p>\n

\n

Js redirects are probably not a good idea though.<\/p>\n

\u2014 Gary \u9be8\u7406\uff0f\uacbd\ub9ac Illyes (@methode) July 8, 2020<\/a><\/p>\n<\/blockquote>\n

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\u2019s documentation warns against using them as a priority solution.<\/p>\n

How To Implement JavaScript Redirects<\/h2>\n

The most common method of implementing JavaScript redirects is through window.location.replace, for example:<\/p>\n

window.location.replace(\u201chttps:\/\/dantaylor.online\u201d);<\/p>\n

If you open Dev Tools (CTRL + SHIFT + I) and enter the above line in Console, you\u2019ll go to my website homepage.<\/p>\n

Another method of implementation is through window.location.href, but this can cause user issues.<\/p>\n

With the replace method, when a user clicks back, the browser will load the previous page \u2013 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\u2019s stored in the navigation history).<\/p>\n

This causes a UX redirect loop\/trap, leading the user to close the tab and have a negative experience with the website.<\/p>\n

For many popular headless platforms, like Gatsby<\/a>, there are pre-built methods of handling and implementing redirects.<\/p>\n

In Gatsby, you can install the gatsby-plugin-gatsby-cloud, and implement 1:1 redirects, wildcard redirects, and \u201csplat\u201d redirects.<\/p>\n

Similarly, popular headless CMSs like Jekyll<\/a> and Strapi<\/a> come with prebuilt modules and plugins to ease the implementation of redirects.<\/p>\n

How Google Processes JavaScript Redirects<\/h2>\n

Like JavaScript rendering, Google executes JavaScript in a two-step process and relies on the Web Rendering Service to process.<\/p>\n

You can read more about how Google processes JavaScript here<\/a>.<\/p>\n

For the purposes of this article, however, it\u2019s important to highlight the nuances of JavaScript and how Google often says multiple things about it \u2013 and how we, as SEO experts, interpret this.<\/p>\n

In 2019, during the Google Mythbusting videos<\/a>, Martin Splitt highlighted that you should use JavaScript \u201cresponsibly\u201d to help prevent content from \u201clagging behind\u201d in Google\u2019s process.<\/p>\n

In 2020, as highlighted by the Tweet earlier in this article, Gary Illyes opined that using JS redirects is probably not a good idea.<\/p>\n

During a 2021 episode of the Search Off The Record podcast, the Google advocates highlighted that you shouldn\u2019t have any issues with JavaScript<\/a>, as long as Google can see the page\u2019s critical (value proposition, beneficial purpose).<\/p>\n

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 \u201cfollow\u201d the new path.<\/p>\n

This costs additional time and resources (two things that Google limits on websites, which we often simply call a crawl budget<\/a>).<\/p>\n

Because of this, Google strongly prefers server-side redirects (the traditional 301, 302, 307) to JS redirects.<\/p>\n

This has been reaffirmed by Google as recently as June 2022 in an SEO Office Hours video<\/a>.<\/p>\n

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<\/a>.<\/p>\n

For reference, Google\u2019s Search Central documentation<\/a> around redirects first included JavaScript redirects in June 2021, so in terms of the overall \u201cSEO timeline,\u201d this is still quite new.<\/p>\n

Do JavaScript Redirects Work For SEO?<\/h2>\n

Referring back to Google\u2019s Search Central documentation and the implementation of JavaScript redirects<\/a>, it extends the warning around using JavaScript redirects with the following:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n

This ties in with another technical SEO favorite: rendering.<\/p>\n

More specifically, what can happen should the Web Rendering Service fail to execute and render the JavaScript for the redirect?<\/p>\n

If, for some reason, Google fails to execute\/render the JavaScript, then Google will load the initial request URL.<\/p>\n

Depending on your setup, two things could happen:<\/p>\n

    \n
  1. It will either be blank or result in a soft 404 error in Google Search Console<\/a>.<\/li>\n
  2. It will return the original page content, process it, and then begin to process it as \u201cnormal,\u201d which isn\u2019t ideal if you want that content to no longer be accessible.<\/li>\n<\/ol>\n

    To mitigate as much risk as possible, when implementing JavaScript redirects, you should:<\/p>\n