The pipeline that caught 386 wrong booking links
Every hotel page on Got Cosy links out to a booking-link provider so a reader can check rates and availability. That link is generated from an internal ID, matched against the provider's inventory, and it's supposed to land on the same hotel the page is about.
Supposed to. I didn't trust that word, so I built a way to check it.
The problem with trusting a matched ID
A matching system can look correct in the code and still be wrong on the page. IDs collide. Names are ambiguous, chain hotels share addresses across cities, and a fuzzy match can quietly grab a neighbor instead of the property you meant. None of that shows up in a database query. It only shows up if you follow the link and look at what loaded.
So that's what we did. Not spot checks, not a sample. Every hotel.
The method
A real browser opens each generated link, waits for the destination page to load, and reads back what property actually rendered there. That gets compared against the hotel the link was supposed to point to. Four possible outcomes:
- Exact match: landed on the right property page directly.
- Selected match: landed on a page where the right property was pre-selected among options.
- City-level match: landed on the right city, but not the specific property. Not wrong, but not precise.
- Wrong property: landed on a different hotel entirely.
- Unmatched: no usable destination found at all.
Redirects on booking sites are sometimes flaky, loading a placeholder or an error on the first try and the right page on a retry. So a link that failed once got a second visit before being marked wrong. That two-visit rule cut false failures without hiding real ones.
The numbers
Across 6,344 hotels checked:
| Verdict | Count |
|---|---|
| Exact match | 2,937 |
| City-level match | 1,725 |
| Selected match | 882 |
| Unmatched | 313 |
| Wrong property | 386 |
386 links, checked one by one, pointed to the wrong hotel. That's not a rounding error. That's 386 readers who would have clicked "check rates" on one hotel and landed on the booking page for a different one.
What happens to a wrong link
A wrong verdict doesn't just get logged for someone to fix later. The verdict is read at display time: a link marked wrong doesn't render as the primary call to action. It swaps to a safer fallback until it's corrected. The failure is caught before a reader ever sees it, not after someone complains.
What I'd tell you to steal from this
If a link, a redirect, or a match is important enough to put in front of a reader, don't trust the record that says it's correct. Follow it yourself, with something that behaves like a real visitor, and let the actual destination decide what gets shown. A system that checks its own output at the point of display catches failures that code review and unit tests both miss.