How to prioritise an SEO backlog when you can only do four things this month

Sixty findings, capacity for four

Every engagement starts the same way. An audit produces between forty and three hundred findings, each with a severity colour attached, and the client's marketing lead asks the reasonable question: which of these do we do first?

The honest answer is that they will do about four things a month, forever. That's not pessimism about anyone's work ethic — it's what a team with one SEO, a writer and a share of a developer ships once meetings, approvals and the two urgent things that arrive every week are accounted for. On a ₹75,000/month retainer with us the number is similar.

So a backlog isn't a to-do list. It's a queue permanently longer than the year, which makes the ordering decision worth more than any item on it. Most of the harm is done by the audit's own severity colouring, which is a crawler's opinion about standards compliance and has no view about your revenue. We've argued that a good audit ends with five findings, not three hundred. If yours didn't, prioritisation is the work of turning three hundred back into five.

Why impact scores get reverse-engineered

Every framework you'll be handed — ICE, RICE, PIE, whatever the current initialism is — asks for an impact estimate on a numeric scale, and they all break in the same place, because nobody can honestly produce that number for an SEO task.

Try it on a real item. What is the impact, on a scale of one to ten, of adding FAQ schema to your twelve service pages? You don't know and you can't. It depends on whether Google shows the enhancement, on what competitors do in the same window, on whether those pages rank well enough for a rich result to matter. Google's own starter guide says plainly that not all changes you make to your website will result in noticeable impact in search results.

What happens next is predictable and almost never deliberate. Someone has already decided, on judgement, which item should be first, then fills in scores that produce that ordering. The framework runs, the chosen item comes out on top, and the spreadsheet gets presented as analysis. It's a judgement call wearing a number, now harder to argue with — a judgement stated plainly invites "why do you think that?", which improves the decision, while a scoring model invites an argument about weights, which never has.

• The tell that a model is fitted: the top three items are the ones the person who built it wanted to do, their scores are all 8 or 9, and everything else clusters at 4.
• Reach isn't much better. "How many users does this affect" gets proxied by current traffic, which demotes every page with no traffic yet — including all the ones you're trying to create.
• Confidence multipliers hide the problem. An invented number times another invented number gives you a decimal point and no new information.
• None of this makes judgement bad. Judgement is the whole job. It just has to be argued in words, then constrained by the one input you can measure.

The model we actually use

Two fields, one flag, one rule. It fits in a spreadsheet and takes about ninety seconds per item once you've done twenty of them.

Effort goes in four bands, not hours. Impact goes in one of three named categories, not a score. A dependency flag marks anything needing someone outside marketing. The rule: take the highest category, sort by ascending effort, work down.

Developer-dependent work needs its own queue

This is the change that makes the biggest practical difference, and it's structural rather than clever. Anything requiring a developer comes out of your monthly list entirely and goes into a second queue with its own cadence, format and owner.

The two kinds of work have nothing in common operationally. You control the first: start an item Tuesday, finish it Wednesday. The second you don't control — you petition it. It moves at sprint speed, competes with product items that have revenue attached and a PM defending them, and its lead time is weeks regardless of how small the request is.

Mixing them produces a recognisable failure. The roadmap looks full, three of five items are blocked on engineering, none move, and at the quarterly review the SEO has shipped two things and can't explain why. The work wasn't badly prioritised — it was prioritised into a queue that was never theirs.

1. Write it as a ticket, not a finding. Problem, affected URLs with examples, testable acceptance criteria, and why it matters in a sentence a developer can repeat to their PM. "Fix canonicals" is not a ticket. "Filtered URLs under /shop/ must emit a canonical to the unfiltered category URL; see these three examples" is.
2. Put exactly one SEO item in per sprint. A queue of nine requests gets triaged to zero. One well-written request with a plausible revenue mechanism gets done — and the next gets done more easily because the first worked.
3. Attach it to work already scheduled. The cheapest engineering time in the year is the sprint where they're already touching that template.
4. Track lead time and use it. Once you know your average SEO ticket takes five weeks to production, anything you need live in eight weeks has to be requested now.
5. Escalate on evidence, not urgency. "These four pages produce 30% of our organic leads and this bug is why they aren't indexed" gets scheduled. "This is important for SEO" doesn't.

Four a month: what the constraint forces you to refuse

Once you accept that four is the real number, the backlog becomes a series of refusals rather than a series of plans. The same five categories lose every time, and all five are things people feel guilty about cutting.

This is the arithmetic behind our own three-clients-a-month limit. You can't carry a real commitment to an outcome and also take on more work than you can do; one of the two gives, and in most agencies it's quietly the commitment.

• Anything on a page with no commercial path. The 2021 blog post that gets 200 visits a month and links to nothing.
• Broad technical cleanup on a healthy site. If the Page indexing report shows your pages indexed and new ones appearing within days of publishing, crawl-efficiency work is Hygiene however satisfying it would be.
• Competitor-driven items. "They have a glossary, we should have a glossary" is not a mechanism. It becomes one when you can name the queries and the intent.
• Anything that can't be finished this month. An L item started on the 25th is next month's item pretending to be this month's.
• Second and third versions of something you haven't measured. Ship the first cluster, wait for the read, then decide.

Re-scoring: what should change, and what shouldn't

A backlog re-ordered every week produces nothing, because nothing in SEO completes and reports back inside a week. A backlog never re-ordered becomes a document from a world that no longer exists.

The governing fact is measurement lag. Google's guidance is that changes can take anywhere from a few hours to several months to be reflected, and that you should generally wait a few weeks before assessing whether work helped. Any rhythm faster than that is re-scoring against noise.

1. Monthly, re-score only the top ten. Twenty minutes. Has anything shipped? Did it move? Has a new Direct item appeared in last month's Search Console data? Re-scoring items you won't reach for six months is theatre.
2. Quarterly, re-score everything and delete aggressively. Anything that has sat two quarters without reaching the top ten gets deleted rather than carried. If it mattered, it would have surfaced.
3. Out of cycle, for four events only: a migration, a confirmed core update that moved you, a page that starts earning impressions it never had, and a regression you caused.
4. Never re-score in the meeting where results are presented. That's how a flat month produces a brand new roadmap that gets abandoned six weeks later.
5. Re-calibrate the effort bands quarterly, not the categories. If your M items consistently take four days, your M band is wrong and every plan built on it is wrong by the same factor.

The backlog document itself

One sheet. Not a project tool with a custom workflow, not a slide, not the PDF from an audit — a sheet someone can sort, filter and argue with in a meeting.

Columns: item, the page or template it affects, category, effort band, dependency flag, the one-sentence mechanism, date added, date shipped, and what happened. That last one is the column everybody omits and the only one that makes you better at this. Three months of "what happened" teaches you that your rewrites work and your schema work doesn't, on your site, in your market.

Two ownership rules keep it usable: one named person owns the order, and anyone can add a row. A backlog people can't contribute to becomes a second, informal backlog in someone's notes app.

Working from an audit you've already paid for: delete everything that fails the mechanism question, tag what's left with a category, band the effort, split out anything needing a developer, then take the four cheapest Direct items and start on Monday. That's an afternoon, and it's the difference between a document and a plan.