Search recovery: decide what earns the next week of work

An investigation produces more possible fixes than a team can deliver. Build a recovery queue around evidence, commercial exposure and dependencies, with clear limits on what success means.

The search investigation has produced twenty recommendations. Some are urgent repairs, some are worthwhile improvements, and several are educated guesses. Putting them all into a recovery plan with the same deadline hides the choices management needs to make.

The CMO’s job is to turn that list into a sequence. Each item should have a reason to happen now, a defined owner and an observable result. The sequence should also protect the parts of the website that still work.

Separate repair from improvement

A confirmed failure that blocks an important page requires a different response from a proposal to expand its editorial coverage. Both may deserve attention, but they have different evidence and different definitions of completion.

For a repair, completion might mean that affected pages are accessible again and the fault no longer appears in a diagnostic check. That does not automatically mean their previous search performance will return on schedule.

For an improvement, completion means delivering a better answer or experience for a defined user need. Its commercial effect still needs observation. Avoid describing every content change as a technical correction with a predictable recovery date.

Google’s diagnostic guidance identifies technical faults as one possible source of lost traffic. It supports investigating those faults; it does not establish that a particular fault explains all of your decline.

Make each recommendation earn its place

Write a decision card containing the affected users or pages, evidence of the problem, proposed intervention, expected mechanism, effort and dependencies. Add the cost of delay and the risk of making the change.

For a hypothetical service company, fixing an unavailable quotation page may protect an immediate customer task. Rewriting fifty healthy articles because their introductions are short has a weaker claim on the same engineering and editorial time.

This comparison does not require pretending to know an exact return for every task. A clear explanation of commercial exposure, uncertainty and effort can be more honest than a spreadsheet full of invented precision.

Use rough estimates consistently and label them as estimates. If several people score impact, ask what evidence would move their scores. Disagreement can reveal a missing fact that is cheaper to resolve than a major implementation.

Respect dependencies

Some improvements cannot produce useful learning until another issue is resolved. Evaluating a new landing page while its form intermittently fails creates an ambiguous result. Publishing additional pages before a template problem is repaired may multiply the same fault.

Draw the smallest dependency chain needed for the next decision. Avoid a giant roadmap that postpones every action until a complete transformation is ready.

Assign one accountable owner to each dependency. A task shared vaguely between marketing, engineering and an agency often has no practical route to completion. Name who accepts the finished work as well as who delivers it.

Change in interpretable groups

When feasible, group comparable pages and document exactly what changes. Preserve the baseline and the implementation date. A broad rewrite, navigation change, migration and new promotion launched together make later attribution difficult.

This does not mean every repair must become an experiment. Urgent customer failures should be repaired. It means that discretionary changes should be organised so the team can learn more than whether the overall traffic line eventually moved.

Record other events that could affect the result. A category promotion or competitor withdrawal can improve performance even if your intervention contributed little. A seasonal downturn can conceal a useful improvement.

Define two forms of success

First define delivery success: the fault is removed, the page serves the intended task, the source is corrected, or the required information is accessible. These are things the team can directly inspect.

Then define outcome signals: relevant impressions, qualified enquiries, successful task completion or another metric suited to the hypothesis. Choose an observation period that fits the mechanism and the available volume.

Google’s core-update guidance notes that meaningful improvements may take time and do not guarantee a visible ranking gain. Keep that uncertainty explicit when presenting a recovery forecast.

A forecast can still contain scenarios. Explain what stronger, unchanged and weaker outcomes would cause the team to do next. Avoid an open-ended programme whose only response to disappointing results is to request another month.

Keep a protected list

Alongside the work queue, identify valuable pages and customer journeys that should not be changed without a specific reason. Recovery pressure can encourage widespread edits that introduce new problems into healthy areas.

Review the queue weekly using completed work, new evidence and remaining exposure. Remove recommendations whose rationale no longer holds. Reprioritisation is useful when it follows evidence rather than executive impatience.

Close each item with a short account of what was delivered and what remains unknown. The resulting record gives future teams a clearer starting point than a list of completed tickets labelled “SEO improvements.”

The strongest recovery plan is not the longest. It concentrates scarce time on justified interventions, makes dependencies visible and leaves the business better able to explain the next result.