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.
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.