How to read your Search Console manual action notice
When Google issues a manual action against your site, you receive a notice in Search Console that identifies the action type. The notice tells you the category of the violation, the scope (sitewide or partial), and in some cases which specific URLs are affected. What it doesn't tell you is the exact issue Google's reviewer found.
The most common manual action categories are: unnatural links to your site, unnatural links from your site, thin content with little or no added value, cloaking or sneaky redirects, pure spam, user-generated spam, and structured data issues. Each category requires a different remediation approach.
Unnatural links to your site
This action means Google found a pattern of links pointing to your site that appears to have been built to manipulate PageRank. The key word is "pattern." Individual bad links rarely trigger this action. What triggers it is a pattern that looks deliberate: similar anchor text across many domains, links from networks of sites with no organic traffic, sudden link acquisition spikes.
Remediation requires identifying the links that contribute to the unnatural pattern, attempting manual removal where possible, building a disavow file for links you can't remove, and documenting all of that work for the reconsideration request.
Thin content with little or no added value
This action targets content that exists primarily to target keywords rather than to serve reader needs. Auto-generated content, doorway pages, scraped content, and affiliate pages with no original content all fall into this category. The action can be partial (affecting specific URLs or sections) or sitewide.
Remediation requires honestly assessing which pages provide genuine value to readers and which don't. Pages that don't provide value need to be substantially improved, consolidated with other content, or removed.
Writing the reconsideration request
A reconsideration request needs to demonstrate three things: that you understand what the violation was, that you have fixed it, and that you have taken steps to prevent recurrence. Vague language fails. Specific documentation of what you found, what you changed, and how you've changed your processes going forward gives the reviewer what they need to approve the request.
Core update vs. helpful content: what's actually different
Google's core updates and its helpful content system are both capable of reducing a site's organic visibility, but they work differently and require different responses. Confusing the two leads to remediation work that doesn't address the actual problem.
Core updates
Core updates are broad reassessments of how well pages serve search intent across categories of queries. They don't target specific violations. They change how Google weighs quality signals across the board, which means sites that were borderline on certain signals can move up or down significantly when the weighting changes.
Core update losses are characterized by broad ranking drops across many query categories, often affecting your highest-traffic pages. Recovery requires improving the quality signals that matter most for your specific content category, which varies by topic. There's no universal fix.
Helpful content system
The helpful content system evaluates whether content was written primarily for people or primarily for search engines. It creates a sitewide signal based on the proportion of content on your site that it classifies as unhelpful. A high proportion of search-engine-first content suppresses the entire domain, including pages that would otherwise rank well.
The key distinction: core updates evaluate individual page quality. The helpful content system creates a sitewide quality signal. A site can have some excellent pages and still be suppressed if it also has a large volume of low-quality content that drags down the sitewide signal.
How to tell which one affected you
Timing is the first indicator. Both systems update periodically, but on different schedules. Mapping your traffic drop against Google's documented update history is the starting point. The pattern of which pages lost traffic matters too: a core update often affects specific query types, while helpful content suppression tends to be broader and more uniform across the site.
Before you submit a reconsideration request
Reconsideration requests fail most often because they're submitted before the underlying issue is fully resolved, or because the documentation doesn't clearly show what was done. This checklist covers what needs to be in place before you submit.
On the violation itself
- You can state specifically what the violation was, not just the category name
- You have identified all instances of the violation, not just the obvious ones
- You understand how the violation occurred (deliberate action, third-party activity, past practice)
On the remediation work
- Every instance of the violation has been addressed, not just a representative sample
- You have documentation of what was changed and when
- For link violations: removal attempts are documented and a disavow file is prepared
- For content violations: affected pages are substantially revised or removed
On the request itself
- The request uses specific language, not category names
- The request explains what caused the violation, not just what was fixed
- Process changes are documented to show recurrence prevention
- The request is written in a tone that accepts responsibility rather than disputes the finding
