Where they started
The resort’s contract with its old booking engine was ending, and the replacement generated a completely different URL pattern for every room and rate page: different slugs, different query parameters, different pagination. Roughly 400 indexed URLs were about to 404 on the same day. The room pages weren’t decoration either: the “swim-up suite” page alone pulled a meaningful slice of direct-booking revenue, and it was about to change address. Nobody on the property team had run a migration before, and the engine vendor’s answer to SEO was a shrug. The brief was blunt: don’t lose what we have.
What we did
- Full inventory before touching anything. We crawled the live site and pulled every ranking URL from search data, then mapped each old address to its exact replacement, with no “close enough” and no catch-all rules. That map became the redirect spec.
- 1:1 permanent redirects, staged and crawled first. Every old URL got a 301 to its specific new one. We ran the whole set against a staging copy of the new engine and crawled it end to end, catching the chained and looping redirects before launch instead of after.
- Launch-week monitoring, not launch-day relief. We watched crawl stats, index coverage and rankings daily for the first two weeks. A handful of redirects the vendor’s cache had swallowed showed up immediately and got fixed the same day.
- Then the growth work the flat months paid for. With rankings intact, we turned to content the resort had never built (activity guides, seasonal rate explainers, a “which suite” comparison) and earned 15 links from travel and hospitality sites.
The flat stretch at the start of the curve is the case. Traffic that doesn’t move while every URL on the site changes underneath it is a migration done right. The climb afterward was the easy part. It only happened because there was nothing to recover from first.