How to build a searchable directory on Airtable

A directory is a filterable list of things — people, products, listings, venues — where every entry also has a page of its own. It is the most forgiving Airtable build there is, because the data is meant to be seen and the privacy problem that dominates a members-only portal mostly disappears. What takes its place is volume. A directory that works fine with eighty records behaves very differently at eight thousand, and the difference is decided by choices you make in the first hour.

The stakes swap places

Public data lowers the worst case a mistake can produce. It does not remove it. One Airtable key reaches the whole base: every table, including the ones you never intended to publish. "Public directory" describes the records you chose to show, not the credential that fetches them. The key still belongs on a server, for a duller reason than in a portal. It is scoped to the base, never to the listings.

The same applies inside a record. Most directory rows carry fields nobody outside should see — an internal note, a contact number, a moderation flag. If your front end receives whole records and simply doesn't render some of them, that data still arrived in the browser and sits in the network tab. Decide which fields leave your server, rather than hiding them once they land.

The query belongs on your side

The shortcut every directory reaches for is to fetch all the records once, hold them in memory, and filter in JavaScript. It feels clean and it is instant on a small table. It also means every visitor downloads the entire directory before they can see the first card — on a phone, on mobile data, before a single search has been typed.

It costs more than bandwidth. Airtable returns records a page at a time, so "fetch everything" is a loop of requests rather than one, and the base allows roughly five requests per second. A few visitors arriving together, each running that loop, will exhaust the budget and everyone gets errors at once.

Do the narrowing before the data crosses the wire. Filter and sort in the request, ask for one page at a time, and put a cache in front of it. Directory content changes slowly. A cache measured in minutes costs nothing to reason about and takes almost all traffic off the base.

Photos are the one detail that catches people out later. Airtable attachment URLs expire, so anything you cache or copy into your own database will quietly turn into broken images. Fetch them fresh, or move the files somewhere you control.

Filtering and search are different jobs

Filtering by category or region is exact matching, cheap wherever you do it. Free-text search across names and descriptions is another thing entirely. Airtable can match substrings for you, but it is not a search engine: no ranking, no tolerance for typos, no sense that "bakeries" and "bakery" are the same word, and it slows down as the table grows.

There are two honest positions. Keep search deliberately narrow — a couple of fields, exact matching, no pretence of relevance — or copy the directory into something built for search and let Airtable stay the place where editors work. Choosing late is what hurts, because it changes where the data lives.

A URL that survives an edit

Every entry needs an address, and the record ID is sitting right there being unique. Use it and you get URLs that nobody can read, that tell a search engine nothing, and that are tied to a specific row in a specific table. Rebuild the base, re-import the data, migrate to a fresh table, and every ID changes, so every link anyone has shared now points at nothing.

Give each entry a readable slug of your own instead, generated once from its name. Generated once is the load-bearing part. If the slug regenerates whenever the name is edited, then correcting a typo in a listing silently breaks every link to it, including the ones search engines have already indexed. Names should be free to change; the address should not. You also need a rule for the two entries with the same name, because in a directory of any size there will be two.

Where the work actually is

A directory is not a difficult build, and almost every way it fails has the same shape: work that belongs on your side happening in the browser instead — the filtering, the paging, the field selection, the search. Keep that line in the right place and the same code that felt fast at a hundred records still feels fast at fifty thousand.