Only known paths go to Leadpages
An exact-path allowlist selects the matching landing page. Trailing-slash variants resolve consistently; unknown paths stay with Webflow instead of being swept into the legacy system.
Cloudflare routing case study
Keep Old Links Working
A training business had years of video and campaign links pointing to landing pages on an old website. The old WordPress site was gone, but the offers still existed in Leadpages. I built a small routing layer to reconnect those URLs without sending the newer Webflow site to the wrong platform.
By Kesava Belletty · Client details withheld; the focus here is the routing repair.
- My role
- Cloudflare Worker Developer & Technical Troubleshooter
- Delivered
- 40 legacy paths restored
- Systems
- Cloudflare, Webflow & Leadpages
The problem
The links outlived the website
Replacing a homepage does not replace every link already published elsewhere. Older video descriptions and shortened campaign links still led to specific paths on the main domain. Sending all of them to the new homepage would lose the offer the visitor had clicked for.
The repair needed to distinguish a known legacy landing page from an ordinary page on the newer site. It also needed to account for old URL aliases that did not match the current landing-page names.
Diagnosis
Build the map before changing the route
I inventoried links from the public video archive, resolved shortened URLs and compared old destinations with the available landing pages. That produced a checked mapping rather than a rule based on guesses about URL names.
The resulting map covered 40 paths. Where an original offer was no longer available, a related live workout was used instead of pretending the original page had been recovered. Private or unlisted videos were outside the public inventory.
What I built
One domain, two deliberate routes
The original URL stays usable
The Worker fetches the landing page server-side and returns it at the branded URL. Existing campaign links do not need to be replaced across the public archive.
Preserve the journey around the page
The implementation forwards query strings, keeps the existing absolute form endpoints and rewrites canonical and social URL metadata where present.
A small, inspectable repair
The route map is explicit and testable. The landing-page proxy avoids edge caching that could freeze split-test variants, while the rest of the site continues through its separate Webflow path.
Verification and result
Check the destination, not just the status code
I tested the routing map and deployed the Worker, then checked the legacy paths on the public domain. All 40 returned HTTP 200 through the landing-page route, while the homepage continued through Webflow. A follow-up routing check in September 2026 confirmed that split still worked.
The result is a working route to the mapped landing pages, not a measured revenue or conversion uplift. These request-path checks do not prove every form submission, payment or third-party short-link network works on every device.
This was a bounded routing repair, not a claim that the wider website rebuild was complete. It let the old acquisition links work while broader site cleanup remained a separate job.
Old links, new platform?
Start with the URL that no longer works.
Send the failing path, where it should lead and what changed. I can inspect the request path before recommending a fix.