Your Chatbot Is Only as Good as Your Database

TL;DR

I read a piece in Travel Weekly last week about destinations playing a "high-stakes game with AI." Smart people, real numbers, named DMOs. Brand USA, NYC Tourism, Granicus, Satisfi Labs. Everyone agreed the stakes are high and organic traffic is falling off a cliff.

And then every single expert quoted prescribed the same thing: bolt AI onto the front end. Chatbots, agent networks, dashboards, AI policies. Not one of them mentioned the thing that actually determines whether an AI answer engine can name your destination in the first place, which is your listings database.

The general advice seems to be that DMOs don't need their listings databases anymore and I think that this is a very bad idea.

Why is DMO web traffic falling, and why do chatbots not fix it?

Let me start with the numbers, because they are not in dispute. Phocuswright found that 56% of U.S. travelers used generative AI for trip planning in the past year. Sojern surveyed more than 350 DMOs and found over half are concerned about or actively preparing for AI-driven search disruption. Sixteen percent are not using AI at all.

Morgan Bell at Granicus said it plainly in that article: almost every DMO has watched its organic web traffic take a hit since AI search engines went mainstream. His clients keep asking the same question. "How do we continue to be the source of truth, and how do we know if it's working?"

That is exactly the right question. I just think the industry is reaching for the wrong half of the answer.

The industry's response has been to build assistants. NYC Tourism has Libby for leisure travelers and Ellis for meetings planners. Discover Flagstaff launched Tripist. Satisfi Labs is stitching together agent networks across whole cities. All of it lives on the front end. All of it is the thing a visitor talks to once they are already on your website.

But what if that is not where the traffic went?

The traffic went to ChatGPT, Gemini, and Claude. It went to the moment before a traveler ever reaches your site, when they ask an AI "what should I do in your city?" and the AI answers without sending anyone to you at all. A chatbot on your website cannot win a query that never lands on your website.

Let me be clear here, because this is where people misread me. I am not against chatbots. Put one on your site, travelers expect them now, and a good one earns its keep. But a chatbot is a mouth, not a brain, and it repeats whatever your data tells it. Here is the trap nobody warns you about. A chatbot on stale listings fails out loud. It tells a traveler your restaurant is open when it closed last spring, or sends them to a trailhead shut for the season. Now your bad data has a confident voice, and someone is standing at a locked door because of it.

What is your chatbot actually standing on? That database is the thing almost nobody is fixing.

What actually decides whether an AI names your destination?

Here is the part nobody in that article said out loud.

An AI answer engine can only recommend what it can see. When someone asks ChatGPT for the best things to do in your region, the model is not browsing your pretty homepage. It is reaching for structured, machine-readable facts about places: what they are, where they are, what category they fall into, when they are open, what they cost. Clean, current, queryable data.

That data has a name. It is your listings database.

And this is the tell that the Travel Weekly article walked right past. NYC's Libby chatbot recommends across all five boroughs in 68 languages. Ask yourself how. It is not magic and it is not the chatbot. It works because there is a structured database of places sitting behind it. The database is the engine. The chatbot is just the dashboard light telling you the engine is running.

The DMOs winning here made their listings queryable instead of abandoning them.

The DMOs doing the opposite, letting their databases go stale because "nobody clicks through anymore," are making the most expensive mistake in the room. Calling it modernizing doesn't change what it actually is: decommissioning the one asset that makes them citable.

What does "make your database citable" actually mean?

There are three parts, and most DMOs are missing at least one. Here is the whole model in one place.

Layer	What it is	What it does for AI visibility
The database	Your structured first-party listings: hours, location, category, price band, what is actually open	Makes you citable. Gives the AI verifiable facts to pull
The editorial	The context, the "why go," the local narrative around each place	Makes you worth citing. Gives the AI something no aggregator has
The structured data	Schema markup (schema.org TouristAttraction, LocalBusiness) on crawlable pages, not trapped inside a JavaScript widget	Makes you findable. Lets the crawlers that feed AI answers actually read it

The part everyone forgets is the third one. A DMO can have a great database and rich editorial and still be invisible, because it is all locked behind a filterable map widget that AI crawlers cannot read. Structure without exposure is a filing cabinet nobody can open.

Get all three right and you stop being a brochure the AI ignores. You become the source of truth the AI quotes.

But won't the aggregators win anyway?

The argument goes like this. AI models were trained on a web where a handful of aggregators, TripAdvisor, Google's place data, Wikivoyage, Reddit, appear millions of times, cross-linked and repeated. A single DMO appears rarely. So the model's instinct, before it even considers your database, is that a destination answer looks like TripAdvisor. And the live-search layer inside these engines re-fetches those same high-authority aggregators. So maybe your database never makes the shortlist no matter how clean it is, and the effort is better spent feeding Google Business Profiles and TripAdvisor instead.

I'll concede part of it. The aggregators do win the generic head query. "Top 10 things to do in New York" is a saturated, comparative question, and a source that's already a ranked list beats you at it.

Where the argument falls apart is the long tail, and that's where real trip planning happens. "Dog-friendly patios in Charlottetown open on a Monday in the shoulder season." "Accessible beaches near Cavendish with parking." TripAdvisor doesn't have a clean answer to those. An attribute-rich DMO database does.

It also falls apart on time. Being more trusted doesn't mean being more current, and AI answer engines are already getting burned by stale aggregator data: closed venues, wrong hours, restaurants that shut two years ago. First-party data that's demonstrably current is the fix, and the model layer is moving toward rewarding exactly that.

There's also a strategic problem with "spend your effort elsewhere" that has nothing to do with rankings. Feeding your region's facts to TripAdvisor and Google means handing your ground truth to companies that monetize it and own the visitor relationship. Abandon your own structured data and you have nothing to plug in once answer engines start rewarding first-party sources.

Your database is your destination's knowledge graph

So here is the reframe I want DMOs to sit with.

Stop thinking of your listings database as a directory. A directory is a phone book, a thing people used to click through and nobody does anymore, which is exactly why it feels safe to let it rot.

Start thinking of it as your destination's knowledge graph. The structured, authoritative, first-party map of everything in your region worth knowing about. That is not a legacy web feature. That is the single asset an AI needs to name you, and the single asset the aggregators cannot take from you, because it is yours.

The question was never whether to keep your database. The question is whether you will make it citable before the destination down the highway makes theirs citable first.

I did not arrive at this from a whiteboard. Maureen and I talked to more than 100 people across the DMO industry before we wrote a line of code. The same thing came up over and over. Bureaus are sitting on curated, hyperlocal inventory that Google does not have and TripAdvisor cannot match, and it is locked inside legacy systems where no AI can read it. That is not a doom story. That is a fixable problem, and the DMOs who fix it first will own the answer.

What to do next

Build the chatbot if you want one. Just fix the data first, because everything the chatbot says comes from there. Start by answering three questions about the database you already have.

1. Is it current? If your listings have not been reviewed in a year, that is the first thing an AI will get wrong about your destination, and it will get it wrong in front of a traveler.
2. Can a crawler read it? Open one of your listing pages and check whether the content is real HTML or trapped inside an interactive widget. If a crawler cannot read it, no AI can cite it.
3. Is it marked up? Structured data (schema markup) is what turns a listing from prose into a fact an answer engine can lift with confidence.

If the answer to any of those is no, that is your AI-search project. Do it before, or at least alongside, the chatbot. Never after.

This is the exact problem we built trippl to solve. We take a DMO's inventory out of the legacy systems it is buried in and structure it into first-party, LLM-readable data, deployed white-label on the DMO's own site, so the destination stays on the AI map and keeps the visitor relationship instead of renting it out. If you want to see what that looks like for your destination, that is a conversation worth having.

Whether you do it with us or on your own, the DMOs who treat this as a data problem, not just a chatbot problem, will still be the source of truth in three years.

Travel safe, Shelley