Dates blocked that you never blocked: where ghost blocks come from

If a platform closes nights you never closed, it is almost always an echo: the platform re-read your own export link and is handing your block back to you as if it were a booking of its own.

How the echo forms

The mechanism is logical, which is exactly what makes it treacherous:

1. A booking arrives, say on Booking.com, for 10–14.
2. Your shared calendar publishes those nights as busy.
3. Expedia reads that link and closes 10–14 on its side: precisely the point.
4. But Expedia then re-exports that block inside its own link.
5. Your tool imports it back, this time as a line coming from Expedia.

While the original booking exists, the two lines sit on top of each other and nobody notices. The problem appears if the original booking is cancelled: it disappears from Booking.com, but the echo stays on Expedia, and nothing explains why those nights are closed any more.

Recognising a ghost block

Three signs together: the dates are closed with no booking visible anywhere, the line comes from a platform you sold nothing on, and the block appeared shortly after a cancellation.

Releasing it

In iCalSync, open the block in the planning and use “This block comes from a cancelled booking — stop passing it on”. The whole run of nights is released and no longer republished. Without a tool, you have to reopen the dates by hand in the platform’s extranet and wait for them to propagate.

Avoiding it

The rule is simple: one shared link per listing. Never import a platform’s own export link back into that same platform, and do not route blocks that already came from elsewhere through another platform. Every loop you create between two calendars eventually produces an echo.