Google penalty checker: use Google's own reports

People call any sharp fall a Google penalty. Of all the things called SEO penalties, one mechanism fits the word: a manual action, issued after human review and named in Search Console with its scope and a review path once the violation is fixed. Automated ranking and spam systems evaluate pages without any notice, and measurement failures, deindexing, migrations, weaker demand and stronger competitors produce the same falling graph without either.

A crawler can find broken pages, model backlinks and estimate visibility, but it cannot see a manual action that Search Console says does not exist, and its toxicity or health score is not a Google status. The checks below establish which of these you are looking at.

Open the Security Issues report in the same property. The report covers Google-detected hacked content and behavior such as phishing, malware, or unwanted software. It is not the Manual Actions report, and its review process is separate.

If an issue appears, preserve the examples, secure the underlying vulnerability, clean every affected page or file, and request a security review after the fix. Google advises against opening a suspected malware page directly in a browser; use the report and URL Inspection to confirm what Google saw. If the report is clean, record “no Google-reported security issue.” That result does not certify the entire server as secure.

Open the Search Console Performance report. Use the same property and Search type throughout. Compare the first complete affected period with an equal preceding period; add the same period a year earlier when seasonality is plausible. Then separate clicks, impressions, average position, pages, queries, countries, devices, and search appearances. The useful result is not “the site is down.” It is a dated group such as “non-brand mobile queries to the product directory lost impressions on 12 May.”

Compare the trend with Google Analytics rather than expecting the totals to match. Google's own guidance treats Search Console as the source for Google Search performance and Analytics as the source for behavior on the site. Cookies, tagging, time zones, attribution, and canonical URL reporting can make clicks and sessions differ.

• Search Console clicks are stable while Analytics sessions fall: investigate consent, tags, channel rules, landing-page coverage, and reporting. That is not evidence of a Google penalty.
• Impressions are stable while clicks fall: examine position, title and snippet, search appearance, and the results now competing for the click. The page is still being shown.
• Impressions and clicks fall for the same page or query group: the selected export records a search-performance drop. Check Google's documented data anomalies and whether the newest data is still preliminary before treating its size as settled. Keep that group fixed for the indexing and timeline checks below.
• Impressions fall alongside lower search interest: compare the affected queries in Google Trends. A smaller market cannot be repaired with a reconsideration request.

For a sitewide loss, check whether the Page indexing report shows a matching increase in affected not-indexed URLs or technical errors. For a smaller loss, choose two or three affected URLs and one stable URL from the same template. Inspect each with URL Inspection.

Read the indexed result before running the live test. Record whether the URL is indexed, the Google-selected canonical, the last crawl, whether crawling and indexing are allowed, and the fetched response. The live test shows whether the current version may be indexable; Google notes that it does not test every issue in the Page indexing report, including every duplicate or canonical condition.

• The losing URLs are not on Google: use the reported reason. Remove an accidental noindex, fix the robots rule, server response, redirect, or canonical at the shared source, validate the repair, and then request indexing where appropriate.
• The losing URLs share a changed canonical, response, or rendered template while the control does not: the site change is a stronger lead than a coincident public update. Repair or reverse it first.
• The URLs are on Google: indexing is confirmed for those URLs. Google explicitly says that indexed status does not guarantee appearance or ranking, so continue without relabeling the result as a clean bill of health.

Put the first complete affected date beside the site's own releases: migrations, template changes, robots and canonical rules, server failures, content removals, and analytics deployments. A release that changed only the losing group supplies a mechanism. Reverse or test that dependency before making sitewide content changes.

Then check Google's Search Status Dashboard for a Search incident or ranking update. If a core update overlaps the loss, wait until the rollout has finished and compare the week after it ended with a week before it began. A matching broad position loss makes the update relevant to the investigation; the date alone does not show what the site should change. The update history continues that comparison.

If Manual Actions and Security Issues are clean, measurement agrees, and the affected URLs remain indexed, the check has still done useful work: it has ruled out a current manual action, a Google-reported security issue, and the indexing failures tested, while making a reporting-only loss less likely. It has not produced an “algorithmic penalty percentage.” None of the first-party reports above produces one.

The remaining work is a ranking-loss investigation across the affected pages and queries: site changes, demand, competition, relevance, content quality, links, and current ranking systems. Keep the clean reports as evidence. Do not pay another tool to rename the graph.