Why use URL redirections and how to setup
There are many good reasons why a company would need http redirections to redirect the user from one URL to another:
- the content previously available at one URL has changed of URL;
- the url is automatically generated based on a metadata of the page content, which has changed (you fixed a typo in an article title, you changed a product's reference, etc.) and you don't have the possibility to force a content's url;
- your company recently purchased a dedicated domain name for a specific product brand, or for a marketing campaign, and you need to redirect this domain to a precise page of your website;
- your website has recently been redesigned 💥 which is often a source of major URL map revamp:
- some contents may simply disappear, as you found that they're outdated, or you do not want to have those contents on your "new" website anymore;
- developers may have changed the way URLs are generated to allow better and more readable URL formats. For example, developers could have decided to change the previously used URLs that contained technology extensions (
index.phpfor instance) or content identifiers (
- if you launch a new marketing campaign, you could want to print material with an easy-to-remember URL on it (
mysuperproduct.com) instead of a cumbersome URLs within your website, which might be too long to be remember or printed.
In all these cases, it is of course required to create redirections, the only way of avoiding 404 responses on missing URLs.
There are several ways of creating a redirection:
- at infrastructure level: you can configure the web server (nginx, Apache, IIS, etc.) or other infrastructure parts (Varnish, Squid, etc.) to execute redirections on given URLs;
- redirection.io: you can also just setup redirection.io on your website, and be able to manage redirection rules right in our manager interface.
The first two solutions are perfectly convenient, but have several drawbacks. First, they both require to involve developers or ops to set up the redirections, which is quite annoying for those and often introduces latency (while, in the same time, you would want your redirections to be available instantly...).
At application level, you also get the problem that your application gets hit by web requests even when a redirection has to be done. Hence, even if you have built an exhaustive redirection map for avoiding 404 errors, your application will receive a lot of trafic which could have been tackled in a lower layer of your infrastructure.
At infrastructure level, configuring redirections requires the help of a Sysadmin. In large hosting projects, this can involve some latency, ranging from days to weeks, before your redirection requirements are applied. Another drawback of this approach is the scalability: above some thousands of redirection rules, the webservers performance slightly slows down - you can expect more than a 90% drop in performance with large redirection plans, which is obviously not convenient.
redirection.io is the right answer to all of these issues: newly created redirection rules get applied in seconds without requiring any technical knowledge. Also, these rules are applied as soon as possible in the way of an incoming web request in your web stack, which means redirection.io can help save workload on your applicative web servers, logging systems or relational database storages.