SEO workflow management

SEO workflow management without another board to update

Most tools for this are a board that someone has to keep current. This works the other way round: the content plan's status column is the board, and the automations move the cards themselves. Each workflow picks up only the rows at its stage, does its work and writes the next status. Where a person needs to decide, the row simply waits.

The plan lives in a Google Sheet or an Airtable base, and the workers are a mix of n8n workflows, Claude Code scripts and people. The stages below come from the plan built for Eleken, and the ledger at the end from the pipeline behind this site's own articles.

Why content boards drift

A content board is only as accurate as the last time someone dragged a card. When research, briefing, writing and publishing are handled by different people, or by automations that never touch the board, it stops describing reality within weeks.

The fix isn't more discipline. An SEO workflow holds together when the status is what triggers the work, so a row can't be researched without also being marked as researched.

The stages a keyword row moves through

Each keyword row passes through four statuses, and two of them belong to people:

The person sits between research and brief on purpose. Research is cheap to run again, while a brief built on bad research wastes all the writing time that follows it. The research stage itself is SEO competitor research.

An SEO workflow process any worker can follow

The pattern doesn't care what does the work. The same plan can be read by n8n workflows, Claude Code scripts and people, as long as each one follows three rules:

1. Select only the rows at your stage, and take a small batch, often one row at a time.
2. Write your output and the next status back to the same row in the same run.
3. Never set a status that belongs to a person's decision.

The second rule is the one that bites. One early page-building workflow never wrote its status back, so the same row stayed marked as planned and would have been built again on the next run.

The lighter content brief automation follows the same rules on a simpler plan: it reads rows marked Planned and writes the brief and the next status back to the same row in one run.

The ledger at the end of the plan

Once an article exists, the plan still needs to know about it. After the draft is created, a script writes its document or page URL and status back to the content plan in Airtable, matched on the row's primary keyword.

That is what lets anyone answer "where is this keyword?" from one table months later. The step that creates the draft is automated content publishing.

SEO workflow and task management in one table

A separate task tracker duplicates what the plan already knows. Keeping the tasks in the same table means a filter on status is the to-do list: every row at Approving is someone's review queue, and every row at Planned is a writer's backlog.

It doesn't do everything a project management tool does. There are no due dates, reminders or workload views unless you add them as columns, and for a large team with many writers that can be reason enough to keep one alongside.

Naming statuses so they can't collide

Most breakages in a status-driven plan come from the names, not the automations. A few rules keep them apart:

• One status per stage, and one stage per status, so two workflows never read the same rows
• Separate sheets or bases for separate chains, like a design research agent that reads rows marked Ready on its own sheet and marks them Done
• A status gets renamed in the plan and in every workflow that reads it on the same day, or rows stop moving without an error
• Statuses a person sets read like decisions, such as Approved, so nobody wires an automation to set one by accident

None of this needs a tool. It needs someone to own the list of statuses the way they would own a database schema.

SEO workflow automation, and where it stops

The automation moves work between stages. It does not decide what the stages are, who approves, or when research is good enough. Those are agreed during setup and written into the plan as statuses and rules, which is the part that takes real thinking.

When a status-driven plan fits

It fits a team already running more than one automation against a content plan, where rows get lost between them. It also fits whenever approvals matter, because a status no workflow is allowed to set is a simple gate that everyone can see.

It is more than you need for one writer and a spreadsheet of ten keywords, where a shared doc and a weekly check-in do the same job.

No new software to pay for

There's no new software to buy. The plan lives in a sheet or base you already have, and the workflows that read it carry their own running costs.

Setting up the statuses and wiring your existing automations to them is part of execution capacity, the $2,000-a-month agents route taken with a fractional Head of Content retainer. It usually takes a few days, because most of the work is agreeing on the stages.

Start with the plan you already run

Share the sheet or base your content plan lives in. On a call we'll map your real stages onto statuses and mark which hand-offs should wait for a person.