Working Together

An ongoing technical SEO engineering retainer

A retainer is not a project with a longer calendar. It is capacity, a queue and a cadence — and the useful thing to establish before buying one is how the work is chosen, and what it is not.

The problem

Technical SEO is not a project, and buying it as one is why it decays

An audit produces a backlog, the backlog gets worked through, and the site is in good shape. Then the platform is upgraded, a template is redesigned, a page type is added, the crawl rate drops, a migration is planned. Every one of those has a search consequence and none of them arrives with an SEO ticket attached. A one-off engagement cannot catch them because at the moment they occur there is nobody looking.

An audit was done and its recommendations are partly implemented
The site's search position was good after the last engagement and has drifted
Nobody reviews the search consequence of template, platform or URL changes
Technical search work competes for engineering time and loses
Issues are found late, after they have affected traffic
The team can implement but not diagnose, or the reverse
Changes ship without anyone checking what a crawler will receive
Seasonal or release-driven work arrives faster than it can be absorbed internally

Who this is for

The people who usually bring us this problem

A team with an SEO function and no engineering capacity for it

Diagnosis is possible internally and the fixes never reach the top of a sprint.

A site whose search position drifts between engagements

The work was done, and the platform kept changing underneath it.

A team planning a period of change

Migrations, replatforms or redesigns are coming and each needs the search consequence handled.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

The value is in the timing, not in the volume

Most of the search damage in a year happens in a handful of moments: a migration, a template release, a URL change, a performance regression. A retainer's value is that someone is looking when those happen, rather than that a fixed number of hours are consumed. Capacity that is not used in a quiet month is not waste — it is the reason the quiet month was quiet.

A queue without a priority rule becomes a queue of requests

Anyone can add to a backlog. Without an agreed way of ordering it — by evidence of impact, by whether it blocks something else, by whether a change is about to make it harder — the retainer becomes reactive and the work that matters is deferred by the work that is loudest.

A retainer is not an emergency service

It is worth stating plainly because it is a common expectation. Response to an incident is not covered by a monthly capacity arrangement; an outage has its own page and its own engagement, because incident response is a different kind of work with a different commitment attached. Anyone buying a retainer expecting a response time has bought the wrong thing.

The relationship should be able to end

A retainer that cannot conclude is one that has either become a dependency or stopped producing. The terms say how it ends, what is handed over and what the site is left with — including the diagnosis capability, so the position can be maintained without us if that is what you want.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Recurring diagnosis as changes happen

Reviewing the search consequence of platform, template, URL and content changes as they are planned rather than after they ship. This is the work that a one-off engagement cannot do and the main reason a retainer exists.

A prioritised queue with an agreed ordering rule

A single backlog, ordered by an explicit rule agreed at the start — evidence of impact, blocking relationships, and whether an upcoming change will make the work harder. Visible to you, so what is being deferred and why is never a mystery.

Hands-on engineering, not only recommendations

The fixes implemented rather than described, where the codebase and access allow. A recommendation that has to be implemented by someone with other priorities is how a backlog stalls, and it is the specific failure mode a retainer is meant to remove.

Instrumentation and early warning

Measurement that catches a problem while it is small: coverage and indexation tracking, crawl behaviour, error rates on the paths that matter, and alerts on the thresholds that indicate a search-affecting failure rather than a general one.

Release and migration review

A check before a release or a migration that covers what a crawler will receive: status codes, redirects, canonicals, rendering, structured data and sitemaps. Cheap to run against a plan and expensive to discover afterwards.

Working with the teams involved

The search consequence of a change is usually owned by nobody, and it crosses engineering, editorial and product. Part of the retainer is being present in those conversations so the question gets asked while it can still be answered cheaply.

Documented decisions and their reasons

Why a class was excluded, why a canonical resolves where it does, why a redirect exists. Written down as it happens, so the site's search behaviour is explicable to the next person rather than a set of unexplained rules.

A defined end, with a handover

What the engagement leaves behind: the queue, the documentation, the instrumentation, and an explanation of what is being watched and why. Ending well is part of the arrangement rather than a separate negotiation.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Agree the ordering rule before the first request
How work will be chosen, written down and shared. Without it the queue is ordered by whoever asked most recently, which is how the consequential work gets deferred behind the visible work.
Keep the queue visible
You can see what is in it, what is being worked on and what is deferred, at any point. A retainer whose output cannot be inspected is one that is bought on trust, and trust is a poor substitute for a list.
Attach the review to the change, not to the calendar
Where reviews are needed for releases and migrations, they are tied to those events rather than to a monthly slot. The search consequence of a change is knowable before it ships and hard to reverse after.
Do the work rather than describing it
Where the codebase and access allow, fixes are implemented. A monthly report of recommendations is a different and cheaper product, and one that assumes someone with spare capacity is waiting to act on it.
Report on what was done, including what was rejected
Work completed, work deferred with the reason, and any finding that turned out not to warrant action. A report that only lists completed items hides the judgements, which are the part worth reviewing.
Hand over the capability, not only the work
Documentation, instrumentation and the reasons behind decisions, maintained as the engagement proceeds. The measure of a good retainer is that the site can be maintained without it, if that is what you choose.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

At the start

A baseline: current coverage, crawl behaviour, position by page type
The initial queue, populated from the site as it is now
The ordering rule, agreed and written down
What is included, what is not, and where incidents go
How the arrangement ends and what is handed over

During

Recurring diagnosis as platform, template and URL changes occur
Fixes implemented rather than recommended, where access allows
Release and migration reviews against what a crawler will receive
Instrumentation and thresholds for the failures that affect search
Documentation of decisions and their reasons, as they are made

Each period

What was done, and what it changed where it is measurable
What was deferred, and the reason
What was found and deliberately not acted on
The queue as it now stands
What is worth watching over the coming period

Under the hood

Architecture and technology

What the retainer covers

Diagnosis of search-affecting problems as they appear
Implementation of fixes, where the codebase and access allow
Review of releases, migrations and URL changes before they ship
Measurement and thresholds that catch a problem while it is small
Presence in the conversations where the search consequence would otherwise be unowned
Documentation of decisions, maintained as the work proceeds

What it does not cover

Incident response and emergency availability — that is a separate engagement
Content writing, editorial output or link acquisition
Paid media, social or any channel other than organic search
A guaranteed position, ranking or traffic outcome, in any form
Response-time commitments of any kind — none are offered with a retainer

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

You want the position established once

A technical audit delivered as a prioritised engineering backlog.

Technical SEO audit

You have several teams and one technical problem

A programme with governance, rather than ongoing capacity.

Enterprise technical SEO

The site has an incident rather than a queue

Diagnosing and recovering an availability failure, which is not covered by a retainer.

Server outage recovery

The infrastructure is the recurring constraint

Servers, reliability and capacity as an ongoing arrangement.

Server management

Questions

Frequently asked

What are your response times?

We do not offer response-time commitments with a retainer, and it is better to say that than to publish a table we would not honour. A monthly capacity arrangement is not an emergency service: if the site goes down, that is an incident and it has its own engagement, because incident response is a different kind of work with a different commitment attached. What the retainer does offer is that problems get found early, because someone is reviewing changes as they happen. That is a different and more useful guarantee than a response time, and it is the one we can actually make.

How many hours do we get, and what happens if we do not use them?

That is agreed per arrangement, because the honest answer depends on the site and on how much change it goes through. On unused capacity, the position is that it is not carried over indefinitely and it is not wasted — the quiet period is usually the result of the work done in the busy one, and a retainer that converts unused time into a backlog of speculative changes is producing activity rather than value. Where a period is quiet we will say so and we will say what we think is worth doing with the time, including nothing much.

Do you implement, or do you hand us recommendations?

We implement where the codebase and access allow, and that is the default rather than an extra. A recommendation that has to be picked up by a team with other priorities is how an audit's backlog stalls — the diagnosis was correct and the work never shipped. Where implementing is not possible, because access is restricted or the change belongs to another vendor, that is established at the start rather than discovered later, and the arrangement is priced against what we can actually change.

How is this different from your audit?

The audit is bought once and produces an artefact: findings, a prioritised backlog, and an explanation. It ends when it is delivered, and most of what it finds stays valid for a while. The retainer is bought when you do not want that cycle repeated — it is capacity and a queue, and its subject is what happens between engagements, when the platform changes and the backlog does not cover it. Plenty of sites only need the audit. If we think that is the case for you, we will say so, because a retainer bought for a one-off problem is an expensive way to solve it.

How does it end?

With notice, and with a handover: the queue as it stands, the documentation of what was decided and why, the instrumentation and the thresholds it alerts on, and an explanation of what should be watched. The intention is that the site can be maintained without us, which is why the diagnosis capability is handed over rather than held back. A retainer that cannot conclude has usually either become a dependency or stopped producing, and neither is a good place for the arrangement to sit.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work