How we do it
There are multiple ways ↗ of performing redirects, including at your server, client-side redirects, and using a CDN.
We use various Cloudflare products for our redirects, due to ease of use and speed1.
Our primary method takes advantage of the Pages platform, defining redirects in a plain text file ↗ in our GitHub repo.
This setup allows us to use the same workflow for redirects as for any other documentation change. We implement a redirect in the same pull request as the content change and can test these changes in our preview branches.
We also love the flexibility provided by the Pages syntax.
In certain situations, we also use Bulk redirects.
Normally, bulk redirects only come up when another team is adding a large number of individual redirects to our site, such as when all of our previous support.cloudflare.com content was migrated and needed individualized redirects per locale.
We use this method when the contributors are outside of our team and when the total number of redirects is so large that it would clutter our _redirects file and count against our limit for Pages redirects.
Our team adds redirects in two situations: during the course of normal content and as needed based on data.
During normal content work, you want to add redirects when you do the following to a page:
- Change any part of the URL (filename, folder).
- Delete the page.
We have some automation to help flag needed redirects.
Another time to add redirects is when you see a lot of 404 response codes on certain paths of your docs site. These 404 responses might be due to a missing redirect or mistyped link.
We identify these status codes either through our Cloudflare analytics (ad hoc) or Logpush job (more thorough, quarterly).
-
Performing redirects through Cloudflare lets you implement redirects on the Cloudflare global network instead of making requests travel all the way to an origin server. ↩