Algorithm Recovery

We can usually show what changed and when, which is more useful to you than apportioning blame. The diagnostic compares your templates, redirect map, canonical behaviour, structured data and link profile against archived versions and against your own release history, and lines that up against the dates traffic moved. That gives you dated evidence. Sometimes it shows the inherited work was not the cause at all. We report that outcome too, because building a recovery plan on the wrong story wastes months.

We read it before we touch it. Disavow files are frequently over broad, and removing genuinely useful links is a common cause of a drop that gets blamed on an update. We review what was disavowed, check which of those domains were actually harmful, and where the file looks like the problem we recommend narrowing or withdrawing it. We do not submit changes to a disavow file without your explicit sign off, and we keep the original so any change is reversible.

That is the first question the diagnostic answers, and the answer is often not the algorithm. We rule out tracking changes, seasonality, a site release, a redirect that broke, a robots or canonical change, and a shift in the search results themselves before concluding anything about an update. A drop that starts on a deploy date rather than an update date is a different problem with a much faster fix. You get the dated evidence for whichever conclusion we reach.

Give them the diagnostic first, because a recovery estimate before the cause is known is guesswork. Once the cause is confirmed we can say which of three situations you are in and roughly what each implies. A technical fault or a broken redirect usually recovers within weeks of the fix being crawled. A core update or a quality problem is typically three to six months. A market shift may not reverse at all. We report against the leading indicators monthly so the board sees movement before revenue confirms it.

It makes attribution much harder, which is the real cost. If three things change in the same week you cannot tell which one moved the needle, and a recovery that stalls becomes impossible to diagnose. We do not ask anyone to freeze development. We ask for visibility of the release schedule so we can time our own changes around it and annotate the reporting with what shipped when. Where a release undoes a fix we flag it within days rather than at the next crawl.

Check Search Console’s Manual Actions report first. A manual action is explicitly listed there with a stated reason. If it is empty, you are looking at a core update, a technical fault, or something outside the algorithm entirely, and the distinction needs the fuller diagnostic.

It depends which of the three situations you are in. A manual action can resolve within weeks of a successful reconsideration request. A core-update recovery has no fixed timeline. It depends on the next relevant update, which Google does not schedule around individual sites. A technical regression can resolve within days of the fix being crawled.

No. Nobody can, including anyone claiming otherwise. We commit to an accurate diagnosis and a plan built on the evidence, not a guaranteed outcome.

Only if the underlying violation has genuinely been fixed and documented. A request filed without properly addressing the cause is usually rejected, which costs you time you cannot easily get back.

That happens more often than people expect, a broken tracking tag, a paused campaign, or a genuine change in demand can all mimic an algorithmic hit. Our diagnostic rules these out early, and if that is the answer, we tell you plainly rather than sell you a recovery programme you do not need.

No. Core updates re-assess the whole index against updated criteria. If your site drops, it is because the new criteria weight something you are weaker on relative to competitors, not because you were singled out.

Only if the diagnostic points to a manipulative link profile as a genuine contributing factor. Disavowing broadly and speculatively is more likely to remove value than restore it. We do not recommend it as a default reflex.

Yes. Diagnosis and strategy are what we lead; implementation of technical fixes often sits fastest with a team that already knows the codebase, and we are glad to hand off a scoped fix list rather than insist on doing every line of the work ourselves.