SEO Project Template
Two tracks on one board: a content pipeline for pages being written, and a technical-fix backlog running alongside it, because SEO work is rarely just one or the other.
Content and technical fixes move at different speeds: one board, two lanes, so neither one blocks the other.
Why SEO boards drift into a list nobody works from
SEO work is unusual because it's really two kinds of work at once: writing and publishing pages, and fixing the technical issues that stop those pages from being found. Most trackers treat it as one list, and that's where they go wrong.
Content and technical fixes get mixed into one queue. A page draft and a duplicate-title-tag fix don't take the same skills, the same time, or the same person, but on a single undifferentiated list they compete for the same slot. The technical fixes, less visible and less satisfying to close, lose almost every time.
Technical fixes have no owner once they're found. An audit turns up forty issues, they get pasted into a doc, and the doc is never opened again because nothing on it looks like a task with a person attached.
Nobody tracks whether a published page actually improved. A page ships, the writer moves on, and six months later nobody remembers whether it was worth the time, because there was never a card asking that question.
A fix gets deployed but never verified. A redirect goes live, the card moves to done, and nobody checks a week later whether it actually resolved correctly. The difference between a fix that's shipped and a fix that's confirmed working is easy to lose without a step that asks for it.
The underlying issue is that SEO work doesn't fit neatly into either a pure content calendar or a pure engineering bug tracker, and forcing it into one or the other loses whichever half doesn't fit. A board built for both tracks at once, with its own WIP limit on each, avoids the trade-off entirely: the writers stop competing with the fixes for the same column, and both get finished instead of just one of them looking busy.
The structure, and why each part is there
Pages move through three stages with a WIP limit on drafting, so the team isn't starting a fifth page while four sit half-finished.
Crawl errors, duplicate tags, broken redirects and slow pages live in their own column, with their own owner, instead of competing with content drafts for attention.
A new keyword idea and a newly discovered 404 both land in one triage column first, so nothing gets started just because someone happened to notice it that day.
Planning accounts for how much of the team's real, leave-adjusted capacity goes to writing versus fixes, so one track doesn't quietly consume all the available hours.
Why a page targets one keyword over another, or why a redirect was set up a certain way, gets written into the wiki next to the work, with page history intact.
"Done" for a page means published and internally linked; "done" for a fix means verified, not just deployed. Writing both down stops the two tracks from being graded by the same loose standard.
When a fix needs a decision from whoever owns the content plan, or a page draft is stuck waiting on a technical prerequisite, a one-tap blocked flag raises it with context attached instead of it sitting quietly in whichever column it's parked in.
Whoever splits their week between writing and fixing sees both in one place: today's draft and today's assigned fix, instead of switching between a content tool and an issue tracker to know what's next.
Planning shows how much of the week is going to drafting versus fixes, against real, leave-adjusted hours, so a heavy audit week doesn't quietly consume the time that was meant for the next batch of pages.
How to use it
- 01Start a workspace. A sample SEO project loads with both tracks already on the board, so the split is visible from the first login. Free for up to five people, permanently.
- 02Keep the technical-fix column separate even when it's tempting to merge it. The moment fixes and drafts share a column, fixes stop getting picked up.
- 03Assign an owner to every technical fix the day it's found, not after the audit doc is finished. An unassigned fix is a fix that won't happen.
- 04Cap drafting at two or three pages per writer. More than that in progress at once usually means none of them ship on schedule.
- 05Route new keyword ideas through triage before they become briefs. Not every idea deserves a page, and triage is where that gets decided deliberately.
- 06Add a verification step after a fix is deployed, not just a "done" column. A redirect or a canonical tag is worth checking again once it's live, not just marking as shipped.
- 07Revisit the split between the two tracks monthly. Some months need more writing, some need more fixing; deciding that on purpose beats letting whichever track is louder win by default.
You could run two separate lists for this, one for content and one for fixes, but a single board with two visible tracks makes the trade-off between them a decision the team makes on purpose, instead of one that happens by default. The tracks move at different speeds and that's expected; the point of the shared board is that both are visible at once.
- Content and technical fixes are different kinds of work and deserve different columns, not one shared queue
- An unassigned technical fix, found in an audit and left in a doc, is a fix that won't get done
- A WIP limit on drafting produces more finished pages than an open queue does
Common questions
No, ShipSprint doesn't integrate with any external SEO or analytics tool. It's a board for planning and tracking the work: what to write, what to fix, and who owns each. Rankings and traffic are checked wherever you already check them.
Yes. The two-track structure still helps a team of one, because it forces a visible choice about whether this week is a writing week or a fixing week, rather than letting the more urgent-feeling track always win by default.
Yes. All templates, including this one, are included on the Free plan: up to 5 users and 2 projects, permanently, no card required. Paid plans start at ₹299 per user per month for larger teams. See pricing.
The template includes a verification step after "deployed," separate from marking a card done. Whoever raised the fix confirms it resolved as expected before the card closes. It's a small extra step, and it's the one that catches the fixes that looked shipped but weren't.
As a rough rule, anything that changes how a page is built, served or structured belongs in the technical backlog; anything that changes what a page says belongs in the content pipeline. A card that touches both (say, a page that needs both a rewrite and a fixed canonical tag) is worth splitting into two linked cards rather than one that quietly lives in only one track.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required