In the analog world, a.k.a. real life, when something moves we have multiple methods of updating our means to find it again. When we move physical addresses, we tell our post office where to forward mail. If our connecting flight changes its gate, large displays and airport maps show us the way.
Now imagine that your whole neighborhood is moving addresses at the same time, or that every departure gate is changing in unison. Could those systems handle the influx of information requests about where to find things? That's a the problem your team, or just you, has to solve when a website picks up and migrates to new architecture.
When digital content changes location, we have a sure fire method to indicate to our devices where to find it using protocols and server codes.
Enter the hero of information that moves permanently: the 301, a wonderfully elegant HTTP status first introduced in the 1996 - HTTP/1.0 specification. It has been doing the thankless task of helping us find content on servers ever since.
Since we rarely see them in their true form, here's a 301 directive for an Nginx server that takes the URL 'learning-about-301-redirects' and routes all traffic requests to the new page '301-redirects-are-my-favorite':
server {
server_name wislr.com;
location /learning-about-301-redirects {
return 301 $scheme://wislr.com/301-redirects-are-my-favorite;
}
}
We Don't Make Enough 301 Redirects
It's no surprise the Internet suffers from a deficit of 301 redirects - it's a tedious task (until WISLR came along). Historically you had to take any changing URL paths to files, images, and webpages and manually build the rules and instructions to the new file location. Have you ever tried to map 10 broken URLs, how about 100 or 1,000?
The typical steps for this task are:
Gather all of the URLs that will change, or already changed and are broken.
Gather all of the new URLs where the content will be found.
Take the old URL and find the best (1) match to the new URL.
Avoid redirect loops, redirect chains, and redirecting to another broken URL.
In our careers WISLRs have logged countless hours to this work, manually mapping them or semi-programmatically with pattern matching formulas in a spreadsheet. Every new redirect project needed new rules. Then natural language algorithms arrived and we thought: the old way of doing 301 redirects can finally get an upgrade.
Everyone can now be empowered to do 301 redirects in a faster, easier manner. It's an essential information management task that we always defer due to time constraints, but now that you can do them quickly you can do more of them. Just think of all the hours you spent writing that travel guide or recording that explainer video. Then your website architecture changes, as all website architecture does eventually. Let's make sure our content can be found again.
The Timing Consuming Part of 301 Redirects is Now Easy
The thought of manual URL mapping is what stops more redirects from getting done. It can take hours of methodical and strategic thinking. By the time you've gathered and sanitized the data you need to work with, your battery is drained and all the time allocated has been spent. With WISLR you don't have to spend those hours mapping anymore.
We gather the URLs that are changing or broken, gather the URLs that are new and valid, and run them through the algo. You'll have a file you can implement faster than it took to read this post in most cases, so you can do anything else with your time.