September 10, 2026

Airtable and Notion Directories: When to Move to a Real Platform

Airtable and Notion make excellent directory prototypes and mediocre published sites. What the stack does well, where it caps out on HTML control, speed and cost, the signals it is time to migrate, and when staying put is the right call.

Your AI chat can build this directory.

Describe the niche, watch the agent design the fields and fill the catalogue. Free plan, no card.

Start free

A large share of working directories start life as a spreadsheet. Someone opens an Airtable base or a Notion database, adds fifty rows, points Softr or Super or a similar front end at it, and has something live by the weekend. That is not a mistake to apologise for. It is the cheapest way ever invented to find out whether anyone wants your directory.

The question is not whether that stack is legitimate. It is when it stops paying for itself, and how to tell the difference between an annoyance and a ceiling.

What the base-plus-renderer stack does genuinely well

Entry and editing. A grid is the best listing-entry interface there is. Multi-select, paste a column from a spreadsheet, filter, sort, bulk edit — no directory platform's admin panel beats a well-built base for getting 200 rows in quickly.

Zero commitment. You can restructure your fields on Tuesday because you learned something on Monday. Early on, that flexibility is worth more than any feature.

Cost at the start. A free base and a cheap renderer will run a small directory for the price of a coffee. If the directory turns out to be a bad idea, you lost the coffee.

Collaboration. Handing a base to a freelance researcher is one invite. Handing them a CMS is a training session.

None of this stops being true when you outgrow the stack. Plenty of people who move their public site still research and stage listings in a spreadsheet and import from there.

The first real ceiling: you do not control the HTML

This is the one that matters, and it is easy to miss because the site looks fine.

A directory earns organic traffic through listing pages and category pages. Those pages compete on details a rendering layer usually abstracts away from you:

Title and meta control per page type. Better renderers let you template these. Weaker ones give you one pattern for every page, or none.
Heading structure. If your listing name renders as a div and a random sidebar label renders as the h1, you are fighting your own markup.
Canonical tags and pagination. Category pages with filters generate a lot of near-duplicate URLs. Without canonical control, you get them indexed, or you get nothing indexed.
JSON-LD. Structured data is the part of a directory a machine reads most reliably. Most no-code renderers do not let you emit arbitrary JSON-LD per listing, and the ones that do usually make it a per-page manual field rather than something templated across ten thousand pages.
Server-rendered content. If listings arrive by client-side fetch, you are trusting that every crawler executes your JavaScript and waits for it. Some do. Not all, not always.

Check before assuming the worst: view source on a listing page — the raw source, not the inspector — and look for the listing name, the description and any structured data. If the body is nearly empty, that is your answer.

Speed, rate limits, row caps and seats

The round trip. Visitor requests a page, the renderer requests the base's API, the base responds, the renderer builds the page. Caching hides much of this and static generation hides more — but static generation trades latency for build time, and build time is what turns a two-second data fix into a ten-minute wait.

API rate limits. Notion's public API is limited to a small number of requests per second on average, and Airtable's is similar in spirit. For a cached front end this rarely bites. For a bulk update across thousands of rows, it absolutely does.

Row and record caps. Both platforms cap records per base or database by plan, and the caps have moved over the years, so check current numbers rather than trusting a blog post. The shape is stable: the entry tiers are sized for a small base, and the plan that comfortably holds tens of thousands of records is not the cheap one.

Seats. The cost that surprises people. Base pricing is per user per month. Add a researcher, a moderator and a co-founder, add the renderer's own plan, add a sync tool, and a stack that started at nothing becomes a real monthly line. Compare the total, not the base subscription.

Category and collection pages are where the stack usually gives up

A directory's SEO surface is not its listings. It is its category pages, and the pages that group listings by a shared trait — free tools, open-source options, providers in one city, products for one use case.

Those pages need three things: a stable URL, real introductory copy of 150 to 300 words, and internal links in both directions. Rendering layers are good at generating filtered views and bad at making them into indexable pages with their own editorial content. You end up hand-building landing pages outside the system, where they drift out of sync with the data, or accepting one indexable page type and nothing else.

Directory platforms treat this as the core object rather than a workaround. DirectoryFast has categories and collections as first-class things you create in conversation, each with its own page and intro. That is a difference in what the system is for, not a feature difference.

The signals it is time to move

Not a mood. Specific conditions:

Your listing pages are thin in view-source, or your structured data cannot be templated.
Publishing a correction takes more than a few minutes because of a rebuild or a sync interval.
You want indexable category or collection pages and are building them by hand.
Your stack cost has passed roughly $60-100 a month across base, renderer, sync and seats — the point where directory platforms are directly comparable.
You are past about 1,000 listings and each schema change is now a migration project.
You are selling something — featured placement, sponsorship, job posts. Payments, moderation and expiry dates are where glue stacks turn into part-time jobs.

One signal is not enough. Three is a decision.

What migrating actually costs

Honestly: less than people fear on data, more than they expect on URLs.

The data is the easy part. Export a CSV, map your columns to the target schema, import. Platforms that match on slug — DirectoryFast does — let you re-import repeatedly while you get the mapping right, updating rows instead of duplicating them. Budget an afternoon for a few thousand listings, most of it spent tidying inconsistent values rather than importing.

The schema deserves a real pass. Do not port your columns as-is. A base accumulates fields nobody uses and text fields holding things that should be typed. Migration is the cheapest moment you will get to fix that: aim for five to eight typed attributes that are genuinely useful for filtering, and drop the rest.

URLs are the expensive part. If your slugs change, you need a 301 for every old URL. Match the old structure if you can; if you cannot, map them one to one and keep the redirects permanently.

Watch indexation on the new host. On DirectoryFast the free subdomain is noindex by design — a deliberate anti-spam choice, because shared subdomains get farmed — so organic traffic requires the Pro plan and a verified custom domain. Whatever platform you pick, confirm the new site is indexable before you point the domain at it.

Total realistic cost: a weekend for a small directory, a week for a large one with a URL change.

When staying on Airtable is the right call

Plenty of directories should never migrate.

Under a few hundred listings with no SEO ambition. An internal directory, a community list, a resource page shared in a newsletter. Organic search is not the channel, so the SEO ceiling is irrelevant.

Directories whose traffic comes from elsewhere. If visitors arrive from a newsletter, a Slack community or a social account, the rendered HTML barely matters.

A directory still finding its shape. If you are changing the schema weekly, do that in a grid. Migrate when the model settles.

A team that already lives in the base. If the whole operation runs on Airtable automations, moving the public site costs coordination you may not want to spend.

The stack is not a beginner's mistake. It is a stage, and staying in it deliberately is different from being stuck in it.

Where this goes wrong

Migrating because of a feature list rather than a ceiling. If you cannot name the specific thing that is blocked, you are rebuilding for the pleasure of rebuilding.

Changing URLs and platforms in the same week. Do one, confirm it is stable, then do the other. Debugging both at once is miserable.

Porting the schema unchanged. You carry every bad field decision into the new system, and it is harder to fix there.

Assuming a renderer's SEO settings are enough because they exist. A meta description field is not the same as canonical control, templated JSON-LD and server-rendered content.

Forgetting the base was also your workflow. Research pipeline, moderation status, outreach notes — decide where each of those lives after the move, before the move.

Leaving the old site live. Two versions of the same directory competing in the index helps neither. Redirect and shut it down.

FAQ

Is an Airtable-based directory bad for SEO?

Not inherently. It depends entirely on what the rendering layer emits. Check view-source on a listing page: if the content is in the HTML and you can template titles, meta and structured data, you are fine. If not, that is your ceiling.

How many listings can this stack handle?

Technically, more than most people reach. Practically, the pain starts somewhere in the low thousands, driven by rebuild times, rate limits and record caps rather than by rendering.

Can I keep Airtable as my editing interface after migrating?

Often, yes, as a staging ground. Research and clean listings in the base, export, import with slug matching. What you give up is the live sync; what you gain is control of the published pages.

What breaks first, usually?

Category pages. People discover they cannot create indexable, editorially-written groupings without building them by hand outside the system.

Is Notion worse than Airtable for this?

For a public directory, generally yes. Its data model is looser, its API is more rate-limited in practice, and the renderers built on it lean towards documents rather than catalogues. For a small internal list it is fine.

See what a purpose-built directory platform does differently →