How to Check if Your Site Has a Google Penalty
The definitive check takes about a minute and it comes first on this page rather than last. If it comes back clear, you have ruled out the only thing that can be established with certainty. The rest of this works through the far more likely explanations in order. Stop reading whenever you have your answer.
Check This First, It Takes A Minute
Open the manual actions report in Search Console. If nothing is listed there, you do not have a manual action. That is not a probability, it is the whole answer to that question.
Why this is certain rather than likely. These are announced.
Google's Search Console documentation states that where a site is affected by a manual action, the owner is notified in the manual actions report and in the Search Console message centre. A site cannot have one quietly.
Where the report lives. Named rather than walked through.
It sits in Search Console under security and manual actions. We do not publish interface walkthroughs here. Our Search Console material covers finding and reading it if you need that.
What you are looking for. Presence or absence.
Either an issue is listed with a description and affected pages, else the report says nothing was found. There is no ambiguous middle state to interpret.
Check the message centre too. The commonly missed half.
Notifications arrive there as well. Businesses frequently monitor one and not the other. A message sent to an address nobody reads is the usual reason somebody finds out late.
If something is listed. Go straight past the rest of this page.
You have a specific problem with a stated reason, which is covered in what is a Google manual action.
Nothing There. Now What
An empty report is what most people find. It is genuinely useful information rather than a dead end. You now know something specific about your situation.
What you have established. One category eliminated.
Nobody reviewed your site and decided something. Whatever caused this, it was not a person applying an action, which removes the only explanation carrying a stated reason and a formal route to respond.
What that rules out. A whole kind of work.
Nothing to appeal, nothing to submit, no reviewer to satisfy. Businesses spend real money here trying to communicate with somebody who does not exist, which is covered in what is an algorithmic penalty.
Why people find this unsatisfying. It removes the villain.
An empty report means the cause is ordinary rather than dramatic. Ordinary causes are harder to feel decisive about. That reaction is normal and it is worth noticing before it drives a decision.
What the rest of this page does. Works through likelihood.
Five questions, commonest first. Most readers recognise their situation within the next two blocks.
Was It Even A Drop
A substantial share of reported falls turn out not to be falls. This is the first thing to establish and the last thing anybody checks.
Comparison errors. The commonest by far.
A shorter month against a longer one. A period containing a bank holiday against one that did not. The numbers are accurate and the comparison is not.
Seasonality. Mistaken for decline every year.
A quiet period following a busy one produces exactly the shape of a fall. Businesses in seasonal trades know their own patterns and still misread them in a report.
Tracking faults. Where the data changed rather than the traffic.
Code removed during a rebuild, a filter somebody added, a property reconfigured. The site is performing as it was. The measurement is not.
What we will not give you. A threshold.
No percentage makes a drop real or unreal. Anybody offering one has invented it. What matters is whether the comparison is sound and whether the measurement is intact.
Where this is covered properly. Its own material.
Establishing whether a fall is genuine belongs in our measuring performance guidance rather than here. It is worth doing before anything else on this page.
Did It Coincide With An Update
If the fall lines up with a widely reported update, that points away from anything your site did. This is the second question because it is both common and quick to answer.
How to establish the timing. Precisely.
Find the date performance began to change rather than the date somebody noticed. Those are frequently weeks apart. Using the second produces a false result.
What a match looks like. Days rather than months.
Updates roll out over a period, so an exact day is not expected. A fall beginning within the window of a reported update is a meaningful match. A fall six weeks later is not, however much you would like it to be.
What a match tells you. The nature of the work ahead.
An assessment change means there is nothing to remove and the route is improvement. That is a completely different project from removing something. Confusing the two is the most expensive error in this subject.
What it does not tell you. That you can do nothing.
An update is an explanation rather than an excuse. Sites do recover by becoming genuinely better. Our algorithm updates material covers what that involves.
Did Something On The Site Change
A rebuild, a migration, a plugin, a template change, content somebody removed. These are frequently invisible to the person investigating, because somebody else made them.
Why this gets missed. Different people, different calendars.
The person asking why traffic fell is rarely the person who updated the site three weeks earlier. Neither has reason to connect the two events, so nobody does.
The question that finds it. Ask everybody.
What changed on the site in the eight weeks before this started. Ask the developer, whoever edits content, whoever manages hosting and anybody with access. The answer is frequently something nobody considered significant.
What tends to turn up. Ordinary maintenance.
Pages tidied away, a menu simplified, a plugin replaced, a redirect removed during a clear-out. None of these was done carelessly and any of them can produce this.
The version that matters most. A rebuild or a move.
If the site was rebuilt or migrated in that period, that is the likeliest explanation here. Our site migrations guidance covers diagnosing a fall following a move.
Is It Concentrated Or General
Where the fall sits tells you more than how far it fell. This question divides the remaining possibilities roughly in half.
Concentrated. One section, one page type, one group of queries.
Something specific happened to something specific. That points at a change, a fault or a detection affecting a defined part of the site. It also gives the investigation somewhere to go.
General. Everything moved together.
An even fall across unrelated parts points at something applying to the whole site, usually an assessment change or a site-wide technical issue.
The pattern worth looking for inside a concentrated fall. A shared property.
Whether the affected pages share a template, a section, an address type or a publication date. A shared property is a cause you can find.
Why totals hide this. Averaging destroys it.
A site total can look like a modest general decline while actually being one section collapsing and another rising. Look at the parts first.
Did Somebody Else Improve
A competitor doing better produces exactly the same numbers as your site doing worse. Those need distinguishing before anything gets changed. Almost nobody checks.
Why the numbers are identical. Position is relative.
Nothing about your site has to change for you to move down. Somebody above you improved, else somebody new arrived. The report shows a decline either way.
How to check it. Look at the results, not at your data.
For the queries that matter, look at who appears above you and whether they were there before. A new name, else somebody who has clearly rebuilt, answers it quickly.
What it means if that is the cause. A different kind of problem.
Nothing is broken and nothing needs removing. You have a competitive problem rather than a technical one, which is worked on rather than fixed.
Why this matters before acting. It prevents pointless work.
A business stripping things out of a sound site because somebody else got better ends up with a worse site and the same position.
What Not To Do While You Are Checking
Changing things during an unexplained drop removes your ability to work out what caused it. This is the most useful instruction on the page and the hardest to follow, because doing nothing feels like negligence.
Why it destroys the diagnosis. Variables.
One unexplained change is difficult to interpret. That change plus four things you did in response is impossible, because nothing afterwards can be attributed to anything.
Panic disavowing. The classic reaction.
Submitting a disavowal in response to a fall nobody has diagnosed can remove links that were helping. It does nothing at all where the cause was an assessment change. The position on that sits in our link risk material.
Mass rewriting. The expensive one.
Rewriting pages that were performing removes the only things known to have worked. If the content was fine last month, the content is not the finding.
Large deletions. The irreversible one.
Removing pages in bulk on the theory that something must be wrong with them. Recovering deleted content and its addresses afterwards is far harder than not deleting it.
What to do instead. Write it down.
Keep a list of what you intend to change and act on it once the cause is established. Having the list is itself a form of doing something.
When To Get Somebody Else To Look
Three situations justify bringing somebody in. Outside those, an outside view usually tells you what this page already has.
When the report showed something. A manual action.
A stated issue with a scope and a review process is specialist work. Getting it wrong costs a rejected review and another cycle of waiting.
When you have worked through this page and found nothing. No candidate at all.
If the report is clear, the drop is real, the timing matches nothing, nothing changed and competitors have not moved, something less obvious is happening.
When the commercial stakes justify the speed. A judgement.
If the fall is costing enough that weeks of your own time exceeds a fortnight of somebody else's, that is a straightforward calculation.
What that person should be able to tell you. Four things.
What changed and when. Whether it was the site, an update or a competitor. What evidence supports that. What they would do first, with a reason.
What should make you cautious. Certainty before investigation.
Anybody diagnosing this before looking, else quoting for recovery before establishing there is anything to recover from, is selling rather than diagnosing. That distinction is set out in how to recover from a Google penalty. The full series is on the dangerous SEO practices guide.
Worked through
it and found
nothing?
If the report is clear, the drop is real, the timing matches nothing and competitors have not moved, something less obvious is happening. A review that establishes what changed and when, before anybody removes anything. We will tell you plainly if we find nothing wrong.
What a risk review covers:
A risk review is a one-off piece of work rather than a monthly service, so it is scoped against the size of the site and how much history it carries.
Every guide.
One practice.
Black hat, grey hat, link risk, thin content, the spam policies, negative SEO, manual actions, algorithmic penalties, how to check for one and how to recover from one.
