How to run a website or blog on Airtable

Using Airtable as the content store behind a public website is one of its most natural jobs. Someone who is not a developer edits rows, and the site changes. There are no logins to design and nothing on the page is private, so the security question that dominates most Airtable builds matters less here. This is the build where a different problem takes over: Airtable was never designed to be read by everybody at once.

The rate limit is the whole story

Airtable answers roughly five requests per second per base. That number is fine for a team clicking around a base. It is not a traffic budget for a public website.

Work out what a naive build actually asks for. One visitor lands on an article. The page fetches the article, then the author, then the related posts, then the navigation. That is four requests for one page view. Barely more than one visitor a second puts you at the ceiling. Past it, Airtable returns 429 responses, and your site serves errors or blank pages to the people arriving right now.

The cruel part is the timing. Traffic on a content site is not smooth — it comes in spikes when a post gets shared or ranks. The failure lands precisely at the moment attention arrives, which is the one moment you cannot afford it.

Crawlers read more than humans do

Human traffic is only part of the load. Search engines, social preview fetchers, uptime monitors and assorted bots crawl public pages constantly, and they do not pace themselves out of politeness. A crawler working through a few hundred article pages can saturate your rate limit on its own, on a quiet Tuesday, with nobody watching.

If Googlebot hits 429s while indexing, it backs off and comes back later, and your pages take longer to appear in search — the site is slow to rank for reasons that have nothing to do with the writing. A public site on Airtable that has not been sized for machine traffic has been sized for roughly none of its real traffic.

The fix is to stop reading Airtable

The answer is to touch Airtable rarely, and to serve visitors from something else.

Two shapes do this. You can pre-render: read the base at build time, generate the pages as files, and deploy them. Visitors hit static files; Airtable sees a handful of requests per deploy and nothing at all in between. Or you can cache: keep a copy of each page's data close to the visitor for a set period, so the first request in that window reaches Airtable and the next ten thousand do not.

Both shapes keep your API key on a server rather than in the browser. That still matters on a public site: the Airtable API has no per-user permissions, so one key reaches every table in the base, not only the one holding your posts.

Either way the mental model changes. Airtable becomes the source your site is built from, consulted on a schedule rather than read on demand. Nobody notices a blog post that is five minutes stale. Everybody notices a blog that returns 429s.

The cost is freshness. Publishing a correction means either waiting for the cache window or triggering a rebuild, and it is worth deciding early which of those you want, because retrofitting a rebuild trigger onto a site that assumed live reads means revisiting every page.

Images are a separate trap

Attachments behave differently from the rest of your data, and this catches people out after everything else works.

Airtable gives you a URL for each attachment, and those URLs expire. They are not permanent addresses for your images. If your pages point at them directly, the site looks correct on launch and then, hours later, the images break — every one of them, all at once, with no code change to blame. The cause is invisible in your own code, which is why it burns an afternoon.

The rule is that images must be re-hosted, not hot-linked. When content comes out of Airtable, the file goes with it: copied to storage you control, or to whatever your hosting provides, and your pages point at that copy. The same pass that pre-renders or caches your content is the natural place to do it.

Where this leaves you

A public site on Airtable is not a demanding build, but it has one non-negotiable shape: something sits between Airtable and the internet, holding a copy. Decide that first and the rest is ordinary content work. Skip it and the site is fine right up until the moment it matters.