What Is the Work of SEO? The Six Tickets That Fill the Queue
The work of SEO is a queue of small, checkable jobs: fix what blocks crawling, rewrite what misses intent, publish what answers a question, connect related pages, earn a citation, and report what actually moved. Each ticket has an owner, an hour estimate and a pass mark. That is why the job feels closer to operations than to marketing, and why vague promises are the first sign a team has no queue at all.
Scoped in hours and acceptance checks, not in "we will optimise your site".
So what is the work of SEO, in one sentence?
The work of SEO is six recurring tasks: technical repair, on-page editing, content production, internal linking, external citation and measurement. Each is small, repeatable and verifiable. None of them is "ranking a site" — ranking is the outcome the tickets add up to, not a task anyone can pick up and finish.
Why the job looks vague from the outside
Ask three people what an SEO specialist does and you get three answers: someone thinks it is writing blogs, someone thinks it is buying links, someone thinks it is editing meta tags. All three are describing a single ticket from a much longer queue, which is exactly why the role reads as mysterious on a job board.
The queue framing fixes that. Once the work is split into tickets, you can see who picks each one up, how many hours it takes, and what evidence proves it was done. That is ordinary operations language, and it is what procurement teams ask for anyway.
It also explains why the role sits awkwardly between departments. Technical tickets belong to developers, content tickets belong to writers, and reporting belongs to whoever owns the dashboard. The SEO lead does not do all of the work; the lead writes the tickets, sets the pass mark and refuses to close one that did not meet it.
If you remember only one line from this page, make it this: SEO is a queue with acceptance criteria, and every hour of it should be traceable to a ticket number.
The six ticket types
Every engagement we run fits into these six rows. The hour ranges are typical for a mid-size site with 200 to 2,000 indexable pages.
| Ticket | Type | Typical action | Owner | Pass mark | Hours |
|---|---|---|---|---|---|
| T1 | Technical | Fix status codes, canonicals, robots rules, sitemap coverage | Dev | Index count matches canonical set | 4–12 |
| T2 | On-page | Align title, H1 and opening answer with search intent | SEO | Page answers the query in the first screen | 1–3 |
| T3 | Content | Draft or expand a page that closes an information gap | Writer | Editor approves, one job per page | 6–20 |
| T4 | Internal links | Connect cluster pages to the hub with descriptive anchors | SEO | Every new page has 3 inbound links | 2–6 |
| T5 | External | Pitch a citable asset to relevant publishers | Outreach | Live mention on a page that ranks | 8–30 |
| T6 | Reporting | Read logs and Search Console, log what changed | SEO | Decision recorded for every movement | 3–8 |
Notice the shape: two columns decide whether a ticket is finished, and neither of them is a ranking position. Ranking is a downstream effect, and it moves weeks after the ticket closes.
Acceptance criteria that hold up in a review
An acceptance criterion is a sentence you can check without arguing. These four cover most of the queue.
1. It is crawlable
The URL returns 200, appears in the sitemap, and has exactly one canonical. If a page fails this, every other criterion is decoration.
2. It matches the query
Read the target query and the first screen of the page side by side. A stranger should be able to confirm the match in ten seconds. If they cannot, the ticket is open.
3. It is measurably better
Name the page currently ranking above you and list what yours does better: clearer answer, fresher data, a tool, a table. "We wrote more words" is not a difference.
4. It can be reported
Before closing, note the impression and click baseline for the URL. Without a baseline, nobody can tell whether the ticket helped or the season did.
Who picks up which ticket
Owns T1 and the technical half of T4. Needs a reproduction step in every ticket: URL, expected result, actual result. Without that, the ticket bounces back.
Owns T3, and co-owns T2 on pages that need a rewrite rather than a tweak. The editor, not the writer, closes the ticket, because self-review is how thin pages ship.
Owns T2, T6 and the queue itself. Writes tickets, sets pass marks, keeps the backlog ordered by expected impact per hour. This is the role most job ads describe badly.
Owns T5, but only after the asset exists. Pitching a page that is not worth citing is the most expensive way to spend forty hours.
A normal Tuesday on the desk
The job is not a project with an end date. It is a recurring week, and seeing one week makes the workload concrete.
Queue review
Re-sort the backlog by impact per hour. Kill two tickets that were really wishes.
Technical checks
Look at new 404s, canonical drift and sitemap coverage from yesterday's deploy.
Writing tickets
Turn three keyword findings into tickets with URLs, expected result and pass mark.
Acceptance
Close what passed, return what did not. Nothing closes on a promise.
Two of those four blocks are paperwork, and that is the honest split. The visible part of the job — the part people picture — is a small fraction of the hours, which is another reason the role is misunderstood.
Where tickets get stuck
- No owner named. A ticket assigned to "the team" is assigned to nobody. Every row needs one name, even if the name is wrong at first.
- No reproduction steps. Developers cannot fix a URL that returns the wrong canonical if the ticket does not say which URL, at what time, with what expected result.
- Acceptance defined as a ranking. Rankings take weeks to respond. If the pass mark is a position, tickets stay open forever and the queue becomes a mood.
- Content tickets with two jobs. A page that must both explain a concept and sell a service does neither. Split it into two tickets.
- Outreach before the asset. Pitching a page nobody would cite burns the only thing outreach spends, which is attention.
How we open your queue
We start with a crawl and a log read, then write the first twenty tickets. The pass marks come from your site, not from a template, which is why the first deliverable is a list and not a slide deck.
If you are still deciding what the discipline covers at all, read Whats Is SEO? first. It sets the vocabulary that the tickets assume.
Before any ticket is written, we run a structured audit. Our SEO Audit Checklist is the same order we use internally: crawlability, duplication, templates, content gaps, then links. Fixing the rows in a different order usually means doing them twice.
From there the queue runs weekly. You get a board with six columns, a named owner per row, and a Friday note that says what closed, what slipped and why. No quarterly theatre.
Teams that already have a board can hire us for one lane: technical, content or reporting. The framing stays the same either way, because a ticket that cannot be accepted is not work, it is activity.
One queue, twelve weeks
A lighting retailer had 1,400 URLs in the index and 380 products. Filter combinations were eating most of the crawl budget, and the product pages were competing with their own category pages.
Week one produced a single ticket: canonicalise filter URLs. Week two added sitemap coverage. Only in week four did content work start, because the pages had room to rank by then.
By week twelve, 62% of the indexed URLs were product or category pages, and non-brand impressions on product terms had roughly doubled from a low base. No links were bought in that window.
The lesson is boring and reliable: reduce the queue to tickets with pass marks, close them in order, and the site stops arguing with itself.
Want your first twenty tickets?
Send your domain. We will show you what the queue looks like for your site, which rows to close first, and how many hours each one takes.
Frequently asked questions
Is SEO one job or several?
Several, bundled. Technical repair, on-page editing, content, internal links, outreach and reporting are distinct skills. Small teams ask one person to run the queue; larger teams split the lanes and keep one owner for the pass marks.
How many hours a month does the work take?
For a 200 to 2,000 page site, a steady queue runs 40 to 90 hours a month. The first month is heavier because technical tickets are front-loaded. Content months are lighter on technical hours, and vice versa.
Can one person do all six ticket types?
They can, but the quality drops at the edges. Most single-person teams are strong on two lanes and weak on outreach. Knowing which lane is weak tells you what to hire for before you spend on tools.
What does "acceptance criteria" mean here?
A checkable condition that closes the ticket: the URL returns 200 with one canonical, the page answers the query on the first screen, the new page has three inbound links, the baseline is recorded. No criteria, no closure.
Do you need access to our codebase?
Rarely. Clean tickets with reproduction steps let your developers work in their own process. We ask for read access to analytics, Search Console and the CMS, plus a staging URL for verification.
How do you report on the queue?
A weekly board update and a monthly page: tickets closed, hours used, what moved, what did not, and which row comes next. If a ticket failed acceptance twice, it gets rewritten, not repeated.
What happens after the queue is empty?
It never is. Sites change, templates drift, competitors publish. The queue refills from reporting: every movement in the data is either explained by a closed ticket or becomes a new one.