Security Fundamentals
OSINT for Travellers: Checking a Travel Guide or Hotel Site Before You Trust It
A passive OSINT routine for travel planning in Kali — whois, TLS, robots.txt, sitemaps, llms.txt and JSON-LD — to judge whether a travel guide or hotel site is maintained, dated and sourced before you rely on it.

Most OSINT tutorials are about people. This one is about pages. Before a trip I end up trusting a handful of websites with real decisions: which train to take, how much cash to carry, whether a monument is open on a Monday. A bad guide costs you a wasted day; a fake hotel site costs you a deposit. A ten-minute passive check in a Kali terminal tells you a lot about which kind you are looking at.
Everything below reads public data only. No scanning, no fuzzing, no login attempts.
The worked example
I was planning a day at Mahabalipuram (Mamallapuram), the UNESCO-listed Pallava temple town on the coast south of Chennai, and kept landing on Mahabalipuram Guide . It is an English travel guide, so it is a fair test case: does it behave like a maintained, sourced reference or like a thin page farm? Swap in any domain you are evaluating.
T=guide.mamallahotels.com
Step 1: registration and TLS
whois mamallahotels.com | grep -iE 'creation date|registrar:' | head -2
echo | openssl s_client -servername $T -connect $T:443 2>/dev/null \
| openssl x509 -noout -issuer -enddate
What I saw: the parent domain was created on 2009-08-21, and the certificate is a current Let’s Encrypt certificate. Read both as context only:
- A domain from 2009 has history. That is good if the history is consistent with what the site is now, and worth a look in a web archive if it is not.
- Let’s Encrypt is used by legitimate sites and scam sites alike. What matters is that the certificate is valid for the exact hostname and not expired.
For a hotel booking site, add one more question here: does the hostname match the brand you think you are paying? Typosquats live and die at this step.
Step 2: what the site says it contains
curl -s https://$T/robots.txt
curl -s https://$T/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//'
curl -s https://$T/llms.txt | head -20
A maintained site usually has all three, and they agree with each other. In this case robots.txt allows everything and names the sitemap; the sitemap lists a home page plus logistics and monument pages; and llms.txt gives a one-paragraph summary (“58 km south of Chennai”, “7th–8th-century Pallava rock-cut monuments”) followed by every guide with a one-line answer. That last file is a newer convention aimed at AI tools, and it doubles as a fast table of contents for a human.
Red flags at this step: a sitemap with thousands of near-identical URLs, pages in the sitemap that 404, or a robots.txt that blocks everything except one landing page.
Step 3: how pages describe themselves
curl -s https://$T/shore-temple/ | grep -oE '"@type": ?"[A-Za-z]+"' | sort | uniq -c
curl -s https://$T/shore-temple/ | grep -oiE 'Updated [0-9]{1,2} [A-Z][a-z]+ 20[0-9]{2}' | head -1
The Shore Temple page declares Article, BreadcrumbList, FAQPage and TouristAttraction with GeoCoordinates, and shows a visible “Updated” date. Structured data is not proof of quality — anyone can add it — but it tells you the page claims to be about one specific place, with a date you can hold it to.
Then read the page itself. Here, each guide opens with a short answer, a key-facts box and a “Sources” line pointing at the UNESCO listing for the Group of Monuments at Mahabalipuram. That is the behaviour of a reference, not a funnel.
Step 4: cross-check the hard numbers
This is the step that actually protects you. Pick numbers you can verify elsewhere:
| Claim on the guide | Check against | Result |
|---|---|---|
| ~58 km from Chennai via East Coast Road | Any map router | Consistent |
| Nearest airport Chennai (MAA) | Airport listing | Consistent |
| Shore Temple built c. 700–728 CE under Narasimhavarman II | UNESCO / encyclopaedic sources | Consistent |
| Combined ASI ticket, Shore Temple + Pancha Rathas | ASI notice at the gate | Marked “indicative, confirm at the gate” |
That last row is a good sign rather than a bad one. Prices change; a source that says so is more trustworthy than one quoting a precise figure with no date.
Turning it into a script
#!/usr/bin/env bash
# travel-osint.sh <hostname> — passive checks only
T="$1"; D="${T#*.}"
echo "== whois ($D)"; whois "$D" | grep -iE 'creation date|registrar:' | head -2
echo "== tls"; echo | openssl s_client -servername "$T" -connect "$T:443" 2>/dev/null | openssl x509 -noout -issuer -enddate
echo "== robots"; curl -s "https://$T/robots.txt" | head -5
echo "== sitemap urls"; curl -s "https://$T/sitemap.xml" | grep -c '<loc>'
echo "== llms.txt"; curl -s -o /dev/null -w '%{http_code}\n' "https://$T/llms.txt"
Adjust the D= line for hostnames with more than one subdomain level.
What this does not tell you
Passive checks tell you whether a site is maintained and honest about its sources. They do not tell you whether a hotel will honour a booking, or whether the person messaging you is who they say they are. For payments, stay inside the official booking or payment channel, and never transfer a deposit to a personal account because a chat asked you to.
For my trip, the guide passed: consistent numbers, dated pages, sourced claims. I still checked the ticket price at the gate.
Pertanyaan yang sering diajukan
Is this kind of OSINT legal?
Does an old domain mean a site is trustworthy?
What is llms.txt?
What is the single most useful check for a travel guide?
Situs tetap hidup saat diserang, pindah domain dalam menit saat diblokir
Trafik disaring berlapis sebelum menyentuh server. Dua server: kalau satu tumbang, panel otomatis memindahkan ke server kedua.
- Penyaringan berlapis
- 2 server, auto-pindah
- Rp 7,5 jt/bln · 10 domain