Methodology

For each destination we choose one named base locality that represents where travellers actually stay, because a regional centre point can sit at an altitude nobody visits. Madeira, for example, is measured at Funchal rather than at the island's mountainous midpoint.

We then downloaded ten years of daily historical reanalysis values once, offline, and aggregated them into per-month statistics: the mean daily high and low, the mean monthly rainfall total, the mean number of days with at least 1 mm of rain, mean daily sunshine and daylight hours, and the spread of daily highs as a variability signal. Only those derived statistics ship with the site. The production site makes no weather API calls at all.

These are historical reanalysis statistics, not station observations and not a forecast. They do not predict your week, and we never label them “live”, “current” or “today”. Where a month has shown large year-to-year variation, we say so rather than hiding it behind an average.

Each month The SnapDestinations Team publishes three destinations on the front page. That selection is human editorial judgment, made by reading our own research for the month in question: what the historical record says about conditions, what our access and opening notes say about what is actually reachable, and what the official demand series say about when a place is busiest.

• It is not a ranking. The numbers 01 to 03 are the order of the composition, not a verdict on which place is better.
• It is not a popularity or trend signal. We hold no traffic, booking or search data, so we never describe a destination as trending, rising or in demand.
• Every selection carries its catch. If we cannot state an honest reason a reader might choose somewhere else, the selection does not publish.
• Only researched places are eligible. A destination has to already pass our publishing gate before it can be selected.

There is no single overall travel score, because suitability depends on the trip. A destination can be a defining answer for mountain biking and a poor answer for a car-free family beach week. So our matching tools do not score destinations: they read each one against your brief as a set of named evidence lines, and shows you the lines.

• What the trip is for. We classify every published destination against our activity taxonomy: a defining reason to come, strong, available but not a reason to choose it, a researched limitation, or not researched. Defining counts for more than strong, and strong for more than available.
• Must-have versus nice-to-have. A must-have is a hard constraint. Wanting a mountain-biking holiday is not the same question as hoping for some cycling, so no number of weaker agreements can outvote one must-have we cannot honour. A must-have we have not researched, or one our research records as a real limitation, sets the destination aside with the reason shown.
• Timing. Our own stated stronger and weaker periods, plus the historical record for your month, move a destination up or down — warmth for swimming, near-freezing days for anything that needs snow-free ground, heat for sustained effort, rain where it matters and not where it does not. Historical statistics are a record of past years, never a forecast.
• Cost, company, length and transport. The relative cost band against your budget, our researched traveller-type and trip-length fit, and whether the place works given how much driving you are willing to do.

Arithmetic is used internally to order the results, and every unit of it belongs to one named line, so we can always answer why one destination came above another. That arithmetic is never shown to you as a consumer score. Ties are broken alphabetically, so the same brief always produces exactly the same answer.

When we hold nothing for a criterion, it is reported as unknown under “what we could not check” — never scored as a match and never as a zero. And when nothing we have researched genuinely answers a brief, the tool says so rather than promoting the least bad option.

A destination is only published with a search-visible page once it has verified identity data, sourced historical conditions, a substantial destination-specific summary, at least three genuine strengths and three genuine trade-offs, defined experiences, traveller-fit information, practical travel guidance, seasonal interpretation, two or more suggested bases and at least two meaningful alternatives.

We currently publish 20 destinations. We deliberately do not generate month-by-destination, date-by-destination or traveller-type-by-destination pages, and a specific comparison pairing or filter state is a tool state rather than a page.

For each destination we identify the organisations that actually operate or measure the things travellers plan around — airport operators, ferry companies, public transport authorities, national meteorological services, park and heritage authorities, official tourism bodies and national statistics offices — read their own published information, and record what each one supports for that destination. Those records are shipped with the site and shown on the destination page and on Sources & data. SEO travel blogs, listicles and review aggregators are not used as factual authorities.

Time-sensitive detail is treated differently on purpose. Timetables, seasonal opening dates, lift and hut operating periods and site opening hours change every year, and we do not maintain them. So we describe the durable structure — that a coast has a seasonal ferry network, that a mountain region shuts down between seasons — and link to the operator for the current detail. A source marked time-sensitive is one whose specifics we deliberately did not copy.

Every destination page separates four things that are usually different months: the historical conditions, our own recommendation, crowding, and what is actually open or running. Collapsing them into a single best month would hide the trade-off that matters — best weather is frequently the busiest and most expensive time, and the quietest weeks are often the ones where the infrastructure is shut.

Crowding is the weakest-evidence part of travel writing, and we treat it that way. We hold no visitor counts. Where we say a period is busier, it is either drawn from an operator's own seasonal service pattern or presented explicitly as our inference, with the relevant national statistics body named so you can go to the numbers yourself.

SnapDestinations recognises 3,206 places — countries, cities, islands, archipelagos, regions, mountain ranges and national parks — from Wikidata (CC0, retrieved 2026-08-30). That index holds identity and geography only: no weather, cost, transport or suitability data. It lets us answer “where is this, and do you know anything about it?” for almost anywhere, without pretending we have researched it.

Names are cross-checked against GeoNames (CC BY 4.0 — attribution required, retrieved 2026-08-30). The cross-check is a quality step, not a growth step: it independently agrees with the identity of 951 places and adds 4,671 alternative spellings, each of which must sit within 25 km of the coordinates we already hold, look like a variant of the same name, and be unique in the whole index. It adds no places and no travel data, and it introduces no fuzzy matching: two places with the same name are still reported as ambiguous rather than guessed at.

How much we may say about a place is a computed level, recalculated from the record every time we build. It is never typed in by hand. The level depends on two things at once: the structure of the record, and whether the evidence behind it is still usable. If a transport source passes its expiry window, the capability it supports degrades and the level falls automatically — a page can drop out of Decidable, and therefore out of the index, without anyone editing a field. Levels rise the same way, when a source is re-read.

• L0 Unrecognised. We cannot reliably identify this place, so we say nothing about it.
• L1 Identified. We know what this place is and where it is. We hold no travel research for it.
• L2 Conditions known. We can talk about when to go, not about how a trip there works.
• L3 Decidable. We can help you decide whether this place suits the trip you have in mind.
• L4 Enriched. We can support the planning decisions inside the trip, not only the choice to go.
• L5 Reference. Full calibration standard: decision, logistics, sub-areas, cost basis and sourcing.

Completeness decides what the product may answer. Publishing approval decides what search engines may index. The two are separate on purpose. A place we can identify gets a live answer inside the product and no page at all: no URL, no sitemap entry, nothing for a crawler to find. A permanent destination page becomes possible only from L3 Decidable upward, and only once a fourteen-point publishing contract passes — the last requirement of which is a human approval recorded in the repository by a person, never by automation. Today 20 of our 20 destinations are approved and published, all of them at L5 Reference.

This also runs in reverse. If a published record loses sourced substance, its computed level drops and it leaves the index — reaching a level once does not buy permanent search presence.

Trip-length bands are editorial. For each destination we ask what a specific length of stay realistically contains and what it sacrifices, and the bands differ by destination because a two-night island trip and a two-night city trip fail in different ways. There is no formula behind them.

Comparison tables describe destinations against each other in words — character, strongest use, mobility, cost level, main trade-off — and never rank them with a total. Cost levels are four named bands with the reasoning shown; they are relative classifications, not prices, and we publish no rates, fares or daily budgets because we hold no source for them.

A cost level is only publishable if we can say what it is made of, so every destination records five named factors and whether each pushes the overall level up or down: accommodation pressure, eating and drinking, local transport, dependency on a car, lift or crossing, and how far the same trip moves between peak and shoulder season. Those five entries are written per destination and shown in full on the destination page underneath the label, which is why the label never appears anywhere on the site without a legend or the basis beside it.

What the bands mean is comparative and nothing more: Good value means cheaper than most of our set for the same style of trip, Expensive means the high floor is structural rather than the result of choosing badly. They are not statements about your spending, and no band implies a daily budget. We could produce apparent precision by copying figures from budget-aggregator sites; we would not be able to defend a single one of them, so we do not.

Where to stay is usually a larger decision than where to go, so every destination page compares its own sub-areas — valleys, coasts, districts, island ends — with the same columns: where it is, who it suits, what it is strongest for, what it gives up, transport, car dependence and useful stay length. Which area suits whom is our editorial judgment. The transport structure behind it is sourced from the operators and authorities listed on each page, and we keep the whole comparison on one page rather than splitting it into thin per-area pages we could not support.

Physical demand is described, never scored. We publish walking burden, terrain, public transport, how much a car changes the trip, and the single largest challenge — in words, with sourced detail where a transport operator or authority states it. We deliberately do not label a destination “accessible” or “wheelchair friendly”: those judgments depend on individual requirements, specific buildings and specific vehicles, and no source we hold supports them at destination level. Each snapshot ends by stating what we do not know, so the gap is visible rather than implied away.

If a fact on this site is wrong, out of date, or attributed to the wrong source, tell us through the contact page. Corrections we accept are made in the version-controlled data files, which means the change is visible in the build rather than quietly edited in a database. Where a claim cannot be sourced properly, our response is to remove it rather than soften it.