Content production rarely gets lost for lack of ideas. It gets lost in a forty-column spreadsheet where nobody knows any more whether Tuesday's article is waiting for a review, an image or a decision. Airtable for content has a good reputation for fixing that: one base, linked lists, views by status. You still need to know what to put in it.
I run content machines that publish every day. Their calendar is the source of truth: each topic carries its keyword, a note, a planned date and a status. Mine is a versioned file; for a client, a spreadsheet mirrors it. Here is how I would carry those fields over into an Airtable editorial base, and what I would not leave to it.
01What a content base should tell you at any moment
Before creating the first table, I ask four questions. Which topics are planned, and for when? Where does each one stand? What does it rely on (sources read, real questions)? Which ones are waiting for a human decision? If your base cannot answer those four questions at a glance, it is just a list.
The Nielsen Norman Group separates two things in its guide to content inventory and auditing: the inventory lists every piece of content with its attributes (title, URL, author or owner, topic, format, date, metadata), and the audit judges its quality. The same guide recommends a tool people already know, with a low learning curve, and points out that the audit is done by people looking at each piece. A content base serves both, but it audits nothing on its own.
02Three tables rather than one big sheet
Airtable's documentation is clear on this: good practice is to put each list in its own table, then connect the records with a link field. That is exactly what a spreadsheet lacks. A source cited by three articles gets copied three times, spelt three different ways.
I would start with three tables.
The Topics table
One row per planned article, with these fields:
- a working title and the main keyword;
- the secondary keywords, as plain text;
- an anchor note: which service or real practice the topic connects to, and the traps to avoid;
- the planned date;
- the status;
- the published URL and the result of the last check, once the article is live;
- links to the sources and questions.
The anchor note is the field people forget most often. In my machines, it says where the topic comes from and what must not be written. Without it, a topic is just a keyword, and a keyword on its own pushes the writing towards generalities.
The Sources table
One row per page read: the exact URL (the page that carries the claim, never a home page), a title in the form "Organisation, page title", the contribution (the precise claim the source supports), a "read" checkbox and the date it was read. The contribution is the field that counts. A source with no written contribution is a source that ends up cited for a sentence it does not contain.
The Questions table
One row per question people actually ask, written down as it was asked, with where it came from: Google's "People also ask", Semrush's Questions tab, a forum. In my briefs, a question with no origin is rejected. An invented FAQ answers questions nobody asks.
03Statuses that mean something
I use five statuses: to do, in progress, draft (to review), published, on hold. The last one is the most useful. "On hold" means a human decision is needed: a fact to confirm, missing first-hand experience needed to write honestly. My machine never touches a topic on hold. In a team, it is the column the editorial lead should look at first.
In Airtable, the status goes into a single select field, with "to do" as the default value for new rows. One limit to know about: Airtable does not keep a history of changes to that field. Its documentation points to an automation that timestamps each status change. I would add it on day one, because the question "how long has this topic been in review?" always comes up.
Another rule I apply: only one topic "in progress" per person. Two articles worked on side by side contaminate each other (mixed-up sources, crossed links, forgotten statuses). My tools set a lock; in Airtable, a view filtered on "in progress" by author shows it straight away.
04The views and automations worth having
An Airtable view is a way of looking at the same table: grid, calendar, kanban, gallery, form. The data does not change, only the way you look at it. Four views would be enough for me: a kanban by status, a calendar on the planned date, a "sources not read" view and a "to review" view. On paid plans, a locked view stops a collaborator from changing its filters by accident.
Airtable's official demo of a marketing calendar shows the same logic: campaigns and content items live in two linked tables, so that a campaign's details do not clutter the content table, and the calendar view colours each date by status. What the video does not show is the work that comes first: defining what each status means. Without that definition, the colours lie.
Automations, and their traps
An Airtable automation has a trigger (a record created, updated, entering a view, a scheduled time, a webhook) and one or more actions. Three points in the documentation made me change my settings before I had even started:
- a run is counted every time a trigger fires, whether the action succeeds or not: 100 a month on the Free plan, 25,000 on the Team plan, per workspace;
- the "Run a script" action is not available on the Free plan;
- a record that leaves a view and comes back triggers the automation again, and existing rows do not trigger a newly created automation.
The third point is the one that hurts. If "enters the To publish view" starts a publication, a topic that passes through that view twice goes out twice. So I would add a guard condition: the action only runs if the "Published URL" field is empty.
Here is the set-up I would build first:
- Status changed: write the date and the new status into a history field.
- Enters the "to review" view: notify the reviewer, with a link to the row.
- Every Monday morning: send the list of topics on hold to the person who decides.
The publishing itself I leave to the script that writes to the CMS, as I described in my article on automating publishing before producing more. Airtable triggers, it does not publish.
05What Airtable will not do for you
A ticked "read" box is only a statement. In content production, the classic failure is URLs written from memory, or a source cited for something it does not say. That is why the checks I have built open every link themselves and reject a source without a contribution, as I explain in the article on checking sources in content written with AI. A base does not do that work.
Google makes the point in its guidance on AI-generated content: a generative model does not retrieve facts, it predicts a likely sequence of words, and all generated text should be checked by hand before publication. An Airtable base can show who needs to review and since when. It does not review. The principle behind my machines is simple: the tool carries what can be verified, the writing keeps what has to be judged.
Two honest limits. If you work alone and publish a few articles a month, Airtable is probably too much: a spreadsheet with the right columns does the job. And I would not use the base as a CMS: published text is better off in a tool built for it, with drafts, previews and cache, such as Sanity, which I use for this site. My own calendar is a versioned file precisely so that every change keeps its history, something no base gives me as simply.
06Where to start on Monday
I would not start with Airtable. I would start by writing down, on one page, the four questions from the first section and the five statuses, with a sentence defining each. Only then:
- Create the three tables and link them.
- Import your current topics, even incomplete ones, and mark as "on hold" the ones nobody knows what to do with.
- Add the kanban view and the "sources not read" view.
- Add a single automation, the status timestamp, and watch it run for a week before adding another.
If your production is past that stage, the next step is the content machine with human review that I run, and tracking can run on its own with automated SEO reporting. My services and portfolio show how I work. If you would like us to look at your base together, we can talk about it.