Traffic drops in the first week and the same three moves appear in every meeting. Delete pages, rewrite titles, audit backlinks. Each one can be the wrong move, because all three skip the same step, working out which kind of problem this is.
Algorithm updates, manual actions, content governance failures, and migration accidents are discovered differently, fixed differently, and take different amounts of time. Treat them as one problem and a team either acts too early or waits too long. Migrations make the cost obvious. One bad redirect rule and every optimization for the next quarter sits on a broken foundation.
This article lays out a governance framework that works across updates. For how to watch a single spam update and run a self-check, the September update piece covers it in detail, and this one will not repeat it. For search fundamentals and metric layering, see the pillar guide.
Diagnose First, Fix Second
Diagnosis needs three sets of evidence. Miss one and the conclusion usually bends the wrong way.
The first comes from Search Console. A record in the Manual actions report means a person at Google reviewed the site. A record in Security issues means treat it as a security incident before discussing rankings. Empty reports do not clear the site. Algorithmic shifts never appear there in the first place.
The second is the traffic curve against the update timeline. Split organic impressions, clicks, and conversions by page type, query type, and country, then compare against Google's announced core and spam updates. Broad declines across many page types point to an algorithm change. A handful of pages falling to zero overnight points at the pages themselves or at indexing.
The third is your own change log. Publishing, template work, tracking code, CDN rules, robots directives, redirect rules. Any of these can draw a curve that looks exactly like an update. A team without a change log is guessing at this step.
Once the three line up, separate the people, content, and technical tracks. The four categories below take different routes.
| Type | How to spot it | How to classify it | How to recover | Time horizon |
|---|---|---|---|---|
| Algorithm update | Traffic curve matches an announced update, no Manual actions record | Broad, moving in blocks by page type and query type | Improve content and site purpose, let systems reassess | Google says days to months, possibly the next core update |
| Manual action | Manual actions report lists affected page patterns | A human decision, affecting some pages or the whole site | Fix every affected page, then request review | Reviews usually take days to weeks, longer for links |
| Content governance | Index bloat, high share of low-value pages, traffic concentrated in a few pages | Self-inflicted scale or quality problem, not always a penalty | Merge, improve, retire, keep pages that earn their place | No fixed cycle, depends on the scale of change |
| Migration accident | Indexing, traffic, and conversions all break after cutover | Work through the migration checklist item by item | Fix mapping and sync items, roll back if needed | Signal transfer takes weeks, redirects stay for the long run |
Algorithm Updates Are Not Penalties
Google's core updates are broad quality adjustments. The documentation is explicit that these changes do not target specific sites or individual pages. Spam updates target practices that violate the spam policies, and those judgments are also made by systems. Both sit at the algorithmic layer, with no human review and no appeal channel.
Start by ruling out your own changes, then compare against the announced dates. Core update effects often distribute by page type. News pages fall while product pages hold, or the reverse. Group affected pages by intent, template, and publish date. That tells you more than staring at the sitewide total.
Recovery work sits with the content. Check whether these pages answer the question they promise to answer, whether they carry first-hand information, whether they simply reorganize what others published. Google offers content teams a self-assessment frame built on Who, How, and Why. Who made it, how it was made, why it exists. A page that fails all three was already a risk.
Keep expectations level. Google says some changes take effect within days, while others take several months for systems to learn and confirm that the site as a whole now produces helpful, reliable, people-first content. Some cases wait for the next core update. There is no guarantee and no fast lane. Anyone offering an exact recovery date is guessing.
Manual Actions Need Every Affected Page Fixed
A manual action is the result of human review. It appears in the Manual actions report in Search Console and in the message center. It may affect a subset of pages or the entire site. The report lists patterns of affected pages, and expanding the description shows the scope.
One requirement is absolute. Fix all affected pages. Google's wording is direct, fixing only some pages will not earn a partial return to search results. The affected pages also have to stay reachable. No login wall, no paywall, no robots.txt block, no noindex directive.
A reconsideration request covers three things. The exact quality issue, the steps taken to fix it, and the evidence that the fix worked. Reviews usually take several days or weeks, and link-related cases take longer. Do not resubmit while a decision is pending.
Keep this separate from algorithm work. Algorithmic shifts have no review queue, so repeated requests only burn time. A manual action will not lift because of a well-written appeal alone.
Content Governance Means Managing Scale and Purpose
The spam policies include a category called scaled content abuse. It describes generating many pages primarily to manipulate search rankings, whether people, tools, or a mix produced them. The policy text is clear that the judgment turns on purpose and outcome, not on the production method. AI-assisted writing is not a violation by itself. Using it as a page factory is.
Site reputation abuse is the next one teams miss, lending your domain to third-party content so it can borrow the trust the main site built. The same policy list also names thin affiliation and expired domain abuse. Cross-brand partnerships, aggregator pages, and city subfolders are where outbound teams run into the boundary. The test stays the same, does the page give users independent value. Buying and selling links belongs to a different track. Types and remedies live in the backlinks piece, and this checklist gives it one line, a monthly review of abnormal link growth.
Prevention runs through the publishing gate, not through cleanup. Before a new page or section ships, it should answer three questions. Who needs it, what does it add beyond existing pages, and what would users lose if it did not exist. If none of the answers hold, do not publish. Cap the scale as well. Count new URLs and useful pages every month. When indexed pages grow faster than demand, that is usually a warning.
Discovery comes from an inventory. Group the Search Console page report by directory, template, and publish date. Count pages with zero clicks over a year, pages that only earn brand impressions, and pages that closely duplicate others. When those groups dominate, scale has outrun quality.
Recovery is a set of trade-offs. Merge what can merge, add first-hand information where it is missing, retire what has no reason to exist. Retired pages should return 404 or 410, not sit behind noindex or redirect to the homepage. Removing low-value pages does not guarantee a ranking recovery. Say that to leadership early, before cleanup turns into a promise.
Migration Accidents Yield to a Checklist
Migrations are the category where risk can be pushed down the most, provided the work happens before the switch.
Take a baseline thirty days before the move, covering four blocks. Search Console impressions and clicks split by page, query, country, and device, plus index status and indexed page counts. Core Web Vitals. Organic conversions in GA4. Organic revenue in orders or the CRM. Keep the baseline for ninety days after the move so comparisons use one definition. Export a full URL list as well, recording status code, canonical, title, and main internal links for each page. That list becomes the rollback reference.
URL mapping has to be one to one. An old page points to the new page with the same content. Do not send every old URL to the homepage, and do not route unrelated pages into one destination. Prefer server-side 301 or 308 redirects that point straight at the final address. Avoid chains. Google recommends redirecting to the final destination directly, and where that is impossible, keeping a chain to no more than three hops, and fewer than five at the outside.
Handle the sync items in one table. New pages carry self-referencing canonicals, hreflang annotations point at the new URLs, the sitemap lists only new addresses, robots.txt drops any development blocks, and URLs inside structured data are replaced. The engineering piece covers structured data and performance conventions, and the migration table should check both. Internal links need a batch replacement, and the on-page guide covers the method. Content that was deleted or merged should return 404 or 410, not a 200 page with nothing on it.
Move in batches and keep a rollback. Migrate one subfolder or one product line first, watch for a week, then move the rest. Cut over during low traffic, keep the old site reachable, and prepare a one-step rollback for DNS and redirect rules. On launch day, watch the 5xx rate, status codes on core pages, and index submissions. Widespread 5xx errors or core pages returning 404 mean roll back first and investigate second.
Run the monitoring window at three, seven, and twenty-eight days. Day three covers technical signals such as crawl errors, status codes, and index submissions. Day seven covers indexing and impressions, confirming that new URLs are picking up queries the old pages served. Day twenty-eight covers clicks and conversions against the baseline on the same definitions. For how to design the monitoring table and which metrics to split, the data and tools piece has the full framework. Write the rollback triggers in advance. Core pages above the baseline 5xx rate, indexed pages down by more than twenty percent within a week, or organic revenue below half the baseline for two straight weeks.
Three closing tasks. For a domain or subdomain change, submit Change of Address. Path moves do not need the tool. Keep redirects for at least a year, and longer where possible. Keep paying for the old domain for at least a year so nobody buys it and turns it into a spam site. After the move, check crawling and indexing first. The crawl and index piece gives the order, and it comes before touching content.
Recovery Needs Evidence Before Timelines
All four categories need an observation period after the work. The most useful habit during that period is recording. Write down the time, scope, expectation, and result of every change as one timeline. When the next fluctuation arrives, that timeline is the first piece of evidence.
Report facts and next steps to leadership, not forecasts. Say what has been ruled out, what is being tested, and when the next checkpoint lands. Do not promise a recovery date. Algorithm changes and content governance have no official timetable, and migration signals transfer over weeks. Naming the uncertainty is more responsible than producing a clean number.
Common Misconceptions
Deleting content the moment traffic drops. Deletion is irreversible, and plenty of declines have nothing to do with content quality.
Treating a core update as a manual action. Teams hunt for an appeal channel when the issue sits at the algorithmic layer, where no review exists.
Doing only the 301s in a migration. Miss internal links, canonicals, sitemaps, or hreflang and the new URLs never inherit the signals.
Rewriting content right after a migration. Two variables change at once, and nobody can tell which one caused the drop.
Assuming cleanup guarantees recovery. Removing low-value pages lowers risk. It does not create a recovery promise, and the timeline does not follow the cleanup.
Related Reading
- The SEO guide, fundamentals, metric layering, and how search works.
- The September spam update, one update's window and self-check list.
- Crawling and indexing, what to check first after a migration.
- SEO data and tools, baselines, monitoring windows, and reading anomalies.