This article will help you understand how our URL redirection engine processes your incoming traffic and picks which target URL to send your visitors to.
Set Up Tips
1. Hostnames in URLs are not case sensitive, but paths are case sensitive.
So example.com is the same as Example.com, but example.com/path is not the same as example.com/Path.
Our URL redirect service supports enabling case insensitivity on paths and query parameters on a per-hostname basis. See our article on Understanding Redirect Matching Settings for more information.
2. You do not need to specify an HTTP and HTTPS version of the same URL.
Our URL redirect service handles both protocols automatically without needing to add them individually. This means if you add example.com to your source URLs it will forward both http://example.com and https://example.com to the target destination.
3. The order in which you configure redirects in your dashboard does not matter.
The method that our URL redirect engine uses to determine which redirect to serve is based on exact matching, so it does not matter what order you add redirects to your dashboard, nor how redirects are displayed to you in your dashboard.
How Traffic Is Served
Our URL redirect service determines which redirect to serve based on specificity of the paths.
We will first look for an exact match that matches the path and the query parameters
We will look for an exact match that matches only the path without considering the query parameters
If there is no exact match, then we will look for a partial path match
If there is no partial path match, we will look for path forwarding
If there is no path forwarding, we will then look for a match not found on the requested source hostname
If there is no match for any of these, your redirect will 404 and will show in your lost traffic
Again, the order in which these are added to your dashboard does not matter.
Some Examples
Let's look at an example to further understand these concepts.
Assuming you had the following redirects set up in your dashboard:
source.com/helpdesk –> target.com/knowledgebase
source.com/software –> target.com/apps
source.com –> target.com
1. When path forwarding is disabled
The following redirects would be served:
source.com/helpdesk –> target.com/knowledgebase
source.com/software –> target.com/apps
source.com/ –> target.com/
source.com/path/without/redirect –> (match not found action for source.com)
2. When path forwarding is enabled
The following redirects would be served:
source.com/helpdesk –> target.com/knowledgebase
source.com/software –> target.com/apps
source.com/store –> target.com/store
source.com/software/myapp –> target.com/software/myapp
3. When query parameter forwarding is disabled
The following redirects would be served:
source.com/helpdesk?query=123 –> target.com/knowledgebase
source.com/software?query=123 –> target.com/apps
source.com?query=123 –> target.com/
4. When query parameter forwarding is enabled
The following redirects would be served:
source.com/helpdesk?query=123 –> target.com/knowledgebase?query=123
source.com/software?query=123 –> target.com/apps?query=123
source.com/store?query=123 –> target.com?query=123
source.com/software/myapp?query=123 –> target.com/apps?query=123
5. When path forwarding and query parameter forwarding are enabled
source.com/helpdesk?query=123 –> target.com/knowledgebase?query=123
source.com/software?query=123 –> target.com/apps?query=123
source.com/store –> target.com/store?query=123
source.com/software/myapp?query=123 –> target.com/software/myapp?query=123
If you have any questions regarding how our URL redirection works, please don't hesitate to reach out to us. We're happy to help.