The runbook
01Step 1: date the drop to the day
Open Search Console performance and find the first day impressions fell, not the day you noticed. Compare desktop and mobile separately. Stop condition: if the drop predates the batch, the batch did not cause it.
02Step 2: line the date up with known updates
Google confirmed core updates such as March 2024, and a link spam update in December 2022. If your date sits inside an update window, the link batch is only one suspect among several.
03Step 3: look for a manual action
Search Console shows manual actions in its own report. No message means no manual action. Algorithmic effects send no notice, which is why dating matters.
04Step 4: scope the damage
Is the loss spread over the site or concentrated on the pages you pointed links at? A concentrated drop on targeted pages implicates the links. A uniform drop points elsewhere.
05Step 5: audit the batch with the standard checks
Run the five assertions: live page, rel attribute, noindex, redirect, rating. Pull source ratings with bulk_dr; a batch of 100 domains costs 1 credit.
06Step 6: decide, then wait
Remove or ask the vendor to remove what you can. Disavow only what you cannot. Then wait for a full crawl cycle before judging. Patience is part of the procedure, and it is the step people skip when a client is calling every morning.
Disavow, honestly
Google launched the disavow tool in October 2012. Google has also said that for most sites it is not needed, because its systems ignore many spammy links on their own.
Does that mean never? No. If you bought links on networks that look manufactured and you worry about a manual action, a disavow file is a reasonable belt to go with the braces. It is not a recovery spell.
Expect no instant reversal. None. Recovery from an algorithmic drop usually waits for a later core update or the next recrawl, and nobody outside Google can give you a date. Write it down. Record the day you filed the file and judge after several weeks, not several days.
A caution about timingLinks bought in the same week as a core update are the classic false positive. Both get blamed, and only the date can separate them. Write the date down before you write the theory.
What to log at each step
| Step | Evidence to save | Tool |
|---|
| 1 | Performance export, daily rows | Search Console |
|---|
| 2 | Update name and date next to the chart | Your notes |
|---|
| 3 | Screenshot of the manual-actions report | Search Console |
|---|
| 4 | Per-URL clicks before and after | Search Console |
|---|
| 5 | Fetched HTML, header dumps, rating list | curl, bulk_dr |
|---|
| 6 | Removal requests and the disavow file with date | Vendor emails |
|---|
What this runbook cannot decide
We cannot tell you the cause. Anyone who says they can, from a chart alone, is guessing, and anyone who claims to from a chart alone is guessing. A QA process rules causes out; it rarely rules one in. Sometimes the answer is an unrelated change, such as a redesign or a broken canonical.
If the batch is clean and the dates do not line up, stop blaming the links, because every hour spent on them is an hour not spent on the real regression. Look at your own release log from the same week.
For terms used above, see the glossary. For the cost of repeating the audit monthly, see the cost table.