Where every page comes from

Three layers

1. Visa matrix — fixed records. 81 entries across 9 passports × 9 destinations, each linked to the destination country’s own government or official portal, with the date it was last checked. Nothing on these pages is written by a language model when you load them.
2. Accessibility and dietary guides — OpenStreetMap data. The venue lists are OpenStreetMap tags. On the accessibility guides the overview and neighbourhood ratings around them are written by a language model and labelled on the page; the dietary guides carry no model-written text.
3. Itineraries, destination guides and tool pages — written by a language model (Google Gemini), with the safeguards described below.

Pages that exist only for navigation — month-by-month pages and itinerary variants — carry noindex, follow, so they don’t compete in search. Addresses that don’t match a published page return a plain 404.

Visa matrix

The visa pages are the strictest layer, because a wrong answer means a missed flight or refused boarding.

• A government source for every entry. Each entry links to the destination country’s ministry of foreign affairs, immigration authority or official e-visa portal. Aggregators such as Passport Index and Sherpa are useful for cross-checking, but never the source we cite.
• A check date on every entry. Each entry shows when it was last checked. Rules change, sometimes mid-month — click through to the source before you travel. Our internal weekly report lists the oldest entries so they get re-checked.
• Fees in US dollars. Costs are quoted in USD for comparability, and can drift from the local-currency amount between checks.

Accessibility and dietary guides

The accessibility and dietary guides cover 10 European cities where OpenStreetMap has enough tagged venues to build on.

The venue lists: OpenStreetMap tags

• Queried, not written. Venues come from the OpenStreetMap Overpass API — wheelchair=yes|limited|designated for accessibility, diet:halal|kosher|vegan|gluten_free for diets — and each one links to its OpenStreetMap record.
• What a tag means. A tag is a contributor’s record. OpenStreetMap asks for wheelchair=yes only when a mapper is sure — from a sign, their own experience, or someone who uses a wheelchair. diet:*=only means the place serves only that diet; yes means it offers a proper choice. A tag is not a certification, not an inspection by us, and not a guarantee against cross-contamination. Treat each venue as a strong lead and confirm what matters to you.
• Refresh. Our copy refreshes from OpenStreetMap weekly. If a refresh fails, the page keeps the last good copy instead of showing an empty list, so a list can occasionally be older than a week. For a city we have never fetched successfully, the page says the data is unavailable rather than claiming the city has none.
• Thin cities stay thin. Where a city has few or no tagged venues for a diet, the page shows what there is and says so, instead of padding it.
• Corrections without editing OpenStreetMap. When a reader report is solid, we can remove or downgrade a venue on our own pages. We don’t edit OpenStreetMap itself — if a tag is wrong, fixing it there helps everyone.

The text around them: a language model on the accessibility guides, labelled

• What it writes. On the accessibility guides, the overview and neighbourhood ratings, written by Google Gemini with an extract of the city’s Wikipedia article in the prompt and labelled on the page. Sentences about public transport are left out of this text. The dietary guides carry no model-written text since September 2026: when we checked it, too many of its claims — including ones about religious observance and health — could not be backed by a source.
• What we switched off. In August 2026 an audit of the named things in these guides found invented and misnamed hospitals, taxi operators, transit services and phrases. The sections where they lived — hospital lists, tips, transit notes, local-dish verdicts and grocery tips — no longer render. They come back for a city only after it is regenerated and audited again.
• Transport from the operators. Checked against the operators in September 2026, the model’s transit summaries were wrong or misleading in all ten cities — and always in the same direction, understating access. They no longer render. Each guide’s transport section states the operator’s own figures, with a link and the date they were checked.

Reader check-ins

Each guide has a check-in form. Submissions go to a review queue; nothing is published automatically, and no check-ins have been published yet.

Itineraries, destination guides and tool pages

The destination grid — itineraries, destination overviews, country hubs and the per-destination tools (packing, budget, day trips, food, when to visit) — is written by Google Gemini. Around the model:

• What the model is given. The destination and your trip settings (length, style, budget, pace, interests), a short list of current-state facts we maintain for some destinations — for example, that Hagia Sophia now operates as a mosque — and a rule against inventing names.
• Consistency. Answers are cached per destination and settings, so the same request returns the same page rather than a fresh roll of the dice.
• Validation. Responses are checked against a strict schema, and a malformed or empty itinerary is retried rather than cached.
• Book-ahead badges. Attractions on a fixed list of known sell-outs — teamLab, the Louvre, the Alhambra, the Colosseum and a few others — get a book-ahead badge wherever they appear, whatever the model wrote.
• Arithmetic in code. Budget pages compute each daily total from its own categories instead of printing the model’s total, which disagreed with its own breakdown on roughly three tiers in four.
• Checks after the fact. A script checks named venues against OpenStreetMap. A miss is treated as a question to follow up, not as proof of an error — plenty of real places are missing from OpenStreetMap.
• What it still gets wrong. Opening hours, prices and seasonal closures. Check them before you book.

Other known weak spots

• Uneven OpenStreetMap coverage. Some cities have far fewer tagged venues than others, for some diets very few or none. We show what is tagged rather than pad the list.
• Weather. Weather cards use Open-Meteo and are cached for up to 24 hours, so they can lag fast-changing conditions.

Corrections

• Visa: email [email protected] with the official government page showing the correct rule. We read every message; a correction we can confirm on that page is applied and the entry’s check date updated.
• Accessibility / dietary venues: use the check-in form on the city page — and if an OpenStreetMap tag is wrong, fix it there too.
• Itinerary / tool content: same email. Generated pages can be regenerated once the cause is fixed.

This page is a public record of how the site is made. If something here stops being true, tell us.