SEO task management: the intake, the backlog and the definition of done

SEO task management is the system that turns findings into released changes. Four things make it work, and the tool you use matters less than all of them: every finding enters one backlog through one route, each task is written as an instruction with acceptance criteria rather than as an observation, priority is set by the same rule every week, and nothing is closed until somebody has checked the change is live. Most SEO programmes do not fail at analysis. They fail between the audit and the release, which is exactly the gap this system covers.

Last verified: 09 October 2026

Why SEO work stalls

The pattern is the same in a startup and in a large company. An audit produces a long document. The document lists problems in the language of diagnosis: titles are too long, internal linking is weak, there are duplicate pages. Nobody can pick up a line of that and ship it, so the document is read, agreed with, and never executed. Six months later a second audit finds the same list.

Three structural causes sit behind it:

• The findings live outside the system the work happens in. Developers work in a tracker. Anything in a slide deck is invisible to them.
• The tasks are not specified. "Fix the titles" has no scope, no owner, no accepted outcome and no end.
• Nothing verifies the release. A ticket marked done is not a change live on the site. Deployments drop things, caching hides things, and a template edit can be reverted by the next sprint.

One intake, one backlog

SEO findings arrive from at least six places. All of them should land in the same queue, in the same format, before anybody prioritises anything.

• A periodic audit or crawl
• Search Console: coverage changes, query shifts, manual actions, core web vitals
• The content plan, which generates write and update tasks
• Release regression, where a deployment changed something it should not have
• Requests from other teams, such as a new product launch needing pages
• Competitor and market monitoring

Pick one home for the backlog, and let it be the tool your developers already use if any development is involved. A second backlog is the same as no backlog.

Write the task as a change, not a finding

This is the single highest value habit in SEO task management. Every ticket carries these fields, and a ticket missing any of them is not ready to be worked on.

Field	What goes in it
Title	An instruction. "Shorten product page titles to the template" rather than "Titles too long".
Scope	The exact URLs, or the template and the count of pages it governs.
The change	Before and after, written out. For templates, the pattern and one worked example.
Why	One sentence a developer can repeat to their lead.
Acceptance criteria	What has to be true for this to be done. Testable, not aspirational.
Owner	One named person. Not a team.
Effort	The estimate from whoever will do the work, not from whoever raised it.
Dependencies	The content, the design, the access or the decision this is waiting on.
Verification	How it will be checked after release, and by whom.

A priority rule you can apply in a minute

Elaborate scoring models get abandoned. A three band rule survives contact with a busy week:

• Band one, protect revenue. Anything blocking indexing, breaking a template, removing a page that earns traffic, or coming out of a manual action. These jump the queue the day they are found.
• Band two, close to the money. Changes on pages that already rank between positions four and twenty, where a page already has demand and the fix moves it. Also internal linking into those pages.
• Band three, build. New pages, new sections, structured data coverage, and the long technical work. Real value, slower payback, scheduled rather than rushed.

Within each band, order by effort ascending. Shipping four small band two tasks beats starting one large one.

The board columns, including the one everybody drops

• Intake. Raw findings, unspecified. Fine to be messy.
• Specified. The fields above are filled in. This is the only queue a developer should ever pull from.
• Ready. Prioritised, estimated, dependencies cleared.
• In progress.
• In review. Checked on staging against the acceptance criteria.
• Released. Deployed to production.
• Verified. Confirmed live by fetching the real page, and dated. This column is the one that goes missing, and without it the next audit finds the same list.

Definitions of done, by task type

Task type	Done means
Title and meta changes	The rendered HTML of three sample URLs shows the new values, and the template, not just those three pages, was edited.
Redirect	The old URL returns a single 301 to the final destination, with no chain, and internal links point at the new URL directly.
Structured data	The block validates, it reflects what a visitor can see on the page, and it is on every page in the template.
New or rewritten content	Published, internally linked from at least two relevant pages, and in the sitemap.
Internal linking	The named target pages gained the links, confirmed by a crawl after release.
Speed or rendering	Measured on the same template before and after, on the same connection profile, with the figure recorded in the ticket.

Working with developers without friction

Three agreements remove most of the arguments. First, SEO tickets go into their tracker in their format, with your fields inside the description. Second, template changes are specified as templates, so one ticket covers ten thousand pages rather than ten thousand tickets covering one page each. Third, agree a short release checklist that runs on every deployment: robots directives unchanged, canonical tags unchanged, sitemap still generated, key templates still returning 200. That checklist prevents more lost traffic than any audit finds.

Cadence

• Weekly, thirty minutes. Triage intake, specify the top items, check the verified column, unblock dependencies.
• Monthly. Report on what shipped and what it moved, using the same metrics every month.
• Quarterly. Re plan the bands, retire stale tickets, and run a fresh crawl so intake is based on current data.

This page covers the task system. For the role that runs it, the artefacts and the project plan, see SEO project manager, and for the numbers to report once work is shipping, see SEO KPIs.

Asked and answered: SEO task management

Which tool should we use for SEO task management?

Whatever your developers already use, because that is where the work happens. Jira, Linear, Asana, Trello, ClickUp and Monday all hold this workflow comfortably. SEO platforms are excellent at generating findings and reasonable at tracking them; export the findings into the one backlog rather than running a second board inside a reporting tool.

How many SEO tasks should be in progress at once?

As few as your team can finish inside a sprint. A backlog of two hundred specified tickets with four in progress ships more than forty in progress and none verified.

Who should own SEO tickets, the SEO team or the developers?

The SEO owner writes the specification and verifies the result. The developer owns the implementation. Splitting it that way keeps the person who understands the outcome accountable for defining and checking it, and the person who understands the codebase accountable for building it.

How do we stop the same issues coming back after every release?

Add the release checklist above to the deployment process and make one of the acceptance criteria on every template ticket a regression test. Anything that can break silently needs a check that runs without a person remembering.

Do we need a separate backlog for content?

One backlog, with a task type field. Content and technical work compete for the same calendar and the same approvals, so they need to be visible in the same list when you prioritise.

A column for work that starts outside the site

Your board holds tasks that change pages, templates and redirects. It rarely holds a task that begins with the question a buyer now puts to an assistant: "which tool should I use for this?" The reply is not a page you edit, so nobody owns it, and it never reaches the backlog.

Give it a card. Write the question, ask three assistants, paste the names that come back, and review the card monthly like any other. AI Knows Us can keep that record for you, which leaves the team to decide what to ship in response.