GitHub Pages does not provide server-side redirect rules, and Zensical does not yet support the redirects module we would otherwise use.
Plan
Now
Do not add redirect infrastructure. There are currently no legacy public URLs that need preserving.
Soon
For individual page moves, add a static redirect page at the old URL. Keep each redirect in version control beside the documentation so it is reviewed with the restructure.
Later
Once the developer site's DNS is resolved through Cloudflare, manage redirects as Cloudflare redirect rules for true HTTP 301/302 responses. Keep the redirect mapping in this repository as the source of truth, then use Cloudflare's API to reconcile the deployed rules from that mapping.
Acceptance criteria for the later phase
- A version-controlled redirect mapping identifies every legacy path, target path, status code, and rationale.
- CI validates that each target exists and that legacy paths do not collide.
- A controlled Cloudflare API workflow applies the mapping without storing credentials in the repository.
- Automated checks confirm the deployed HTTP redirect status and destination.
Related: Zensical tracks redirects compatibility in zensical/backlog#23.
GitHub Pages does not provide server-side redirect rules, and Zensical does not yet support the redirects module we would otherwise use.
Plan
Now
Do not add redirect infrastructure. There are currently no legacy public URLs that need preserving.
Soon
For individual page moves, add a static redirect page at the old URL. Keep each redirect in version control beside the documentation so it is reviewed with the restructure.
Later
Once the developer site's DNS is resolved through Cloudflare, manage redirects as Cloudflare redirect rules for true HTTP 301/302 responses. Keep the redirect mapping in this repository as the source of truth, then use Cloudflare's API to reconcile the deployed rules from that mapping.
Acceptance criteria for the later phase
Related: Zensical tracks redirects compatibility in zensical/backlog#23.