Dies ist ein Blog-Beitrag, der bisher noch keine Auflösung hat. Am 9. Februar war noch alles normal. Booking.com holte regelmäßig bei uns die ical-Daten für 180 Objekte alle paar Stunden ab. Zwar nicht alle zwei Stunden, wie sie es auf ihren Webseiten schreiben, aber immerhin alle paar Stunden. Und manchmal auch häufiger. In zwei Tests konnten wir sogar sehen, dass bei einer Verfügbarkeitsanfrage für eine Ferienwohnung auf der Booking.com Website der Crawler “noch mal schnell” vorbeikam um zu prüfen, ob die Wohnung wirklich noch frei war. Manchmal aber auch nicht.
Alles war gut. Dann wurden es täglich weniger Objekte, die jeden Tag von Booking “gecrawled wurden”. Am 20. Februar 2026 wurden gerade einmal 50 der 180 Objekte von Booking.com gecrawled. Wir erkennen einen Aufruf daran, dass eine dedizierte URL für Booking angefragt wurde, nicht daran, dass der Crawler Booking.com hieß. Daher kann es sogar sein, dass von diesen 50 Objekten einige über andere Wege abgefragt wurden.
More-Bookings hat leider keinen Ansprechpartner bei Booking.com, da wir kein Channel-Partner sind. Wir nutzen eine öffentlich dokumentierte Funktion und in den vergangenen Jahren gab es niemals Probleme damit. Über die normalen Support-Anfragen bekamen wir vorgefertigte, aber leider nicht hilfreiche Antworten. Unsere URLs sahen folgendermaßen aus:
https://api.more-bookings.com/api/ical_calendar?channel_id=bookingx&object_id=ag1mZXdveWllbGRtZ210chwLEhFjdXN0b21lcl9wcm9wZXJ0eSIFZGVtbzEM&file=calendar.icsWir haben noch einmal das Dateiformat der ical-Feeds überprüft, aber das musste ja eigentlich in Ordnung sein, denn bei einem Abruf über “Verbindung aktualisieren” wurden die Daten abgeholt und auch sofort verarbeitet. Daran lag es also nicht.
Hypothese: Booking hat immerhin 180 URLs von unseren Kunden unter der o.a. Domain, die regelmäßig gecrawled werden müssen und durch irgendeinen Vorfall in der Vergangenheit kam diese Domain auf eine “Blacklist”. Um dies zu prüfen, haben wir unseren API-Server unter einer alternativen Domain erreichbar gemacht und für drei Objekte diese neuen Links bei Booking eingetragen. Diese Links sahen so aus:
https://api2-dot-fewoyieldmgmt.appspot.com/api/ical_calendar?channel_id=bookingx&object_id=ag1mZXdveWllbGRtZ210chwLEhFjdXN0b21lcl9wcm9wZXJ0eSIFZGVtbzEM&file=calendar.icsAuf einmal lief alles wie ein schweizer Uhrwerk und die drei URLs wurden herrlich regelmäßig abgerufen. Daraufhin haben wir ein Schreiben an alle betroffenen Kunden herausgeschickt uns die gebeten, die URLs in Booking.com zu ändern.
Und dann begannen die gleichen Probleme auf der neuen Domain. Wir waren ratlos. Woran lag es?An den HTTP-Headern?
Wir haben folgende Prüfungen vorgenommen:
– Funktioniert das HTTPS-Zertifikat für api.more-bookings.com
– Reagiert unser Server auf einen Hash-Wert, den Booking aus dem letzten Crawl anfragt und antwortet ggf, dass keine Änderung vorliegt? Ja
Content-Type: “text/calendar”
Content-Disposition: “attachment”
Jeder ical-Checker, den wir kennen, sagt unsere Files sind gut.
Vielleicht die Geschwindigkeit?
Seit 10 Jahren arbeitet jeder Crawler asynchron. Das heißt, dass er einen Request abschickt und dann nicht wartet, bis die Antwort kommt, sonder der Server schickt sehr viele Requests los und arbeitet dann alle Antworten dann ab, wann sie kommen. Das haben wir auch von Booking.com erwartet, aber vielleicht war Booking.com doch wählerisch bei der Geschwindigkeit. Daher haben wir den Cache optimiert und lassen nachts “warm-up-requests” laufen, nur damit die Daten im Cache liegen, falls Booking.com mal vorbeikommt. Mittlerweile sind fast alle Responses in unter 50 Millisekunden ausgeliefert, also kann es auch daran nicht liegen.
Korrektur: Es gibt wohl DOCH einen nachvollziehbaren Grund von Booking.com auf kurze Antwortzeiten zu bestehen. Denn auch wenn die Server asynchron crawlen können, so belegt jede URL während der Wartezeit einen HTTP-Port. Und da deren Anzahl auf ca. 65.000 pro IP-Nummer begrenzt ist und deren Verwaltung durchaus Ressourcen frisst, ist der “Wunsch” von Booking.com nach kurzen Antwortzeiten durchaus verständlich. (Quelle: Prof. Peters, Uni Halle. Vielen Dank!)
Update: Heute (am 24 Februar) wurden bisher 45 verschiedene URLs von Booking.com abgeholt. Mehr nicht!
Wer auch immer eine Idee hat, woran es noch liegen kann, oder wer vielleicht sogar einen Kontakt zu einem Booking.com Mitarbeiter hat, kann sich sehr gerne bei mir melden: cpetersen@more-bookings.com. Ich bin ratlos.
Momentan liegt die “Abhilfe” darin, dass alle Nutzer von More-Bookings nach einer Buchung aus einem anderen Kanal (außer Booking.com) sich bei Booking.com einloggen müssen und auf den “Verbindung aktualisieren” Button klicken. Das wird irgendwann zu Doppelbuchungen führen und das geht einfach nicht.