$ cat Detection & Defense

A visibility loss, a suspicious link and a changed file are observations, not diagnoses. This chapter explains how to collect evidence, separate search-quality issues from a security incident, and choose a response that matches the cause. The local exercises are reproducible; Google’s internal classifiers and recovery timetable are not.

1 · What the platform tells us—and what it does not

Google documents automated spam detection and human manual actions, but does not publish a complete detector, thresholds or comparative accuracy. Its spam policies describe prohibited behavior; they are not an implementation manual for SpamBrain. Helpful-content evaluation became part of core ranking systems in March 2024. None of this proves that a specific site’s decline was a spam decision. [1] [2]

A manual action is a documented review outcome in the Search Console Manual Actions report. An algorithmic visibility change need not produce that notice. Also inspect the separate Security Issues report: hacked content and unsafe downloads require an incident response, and the relevant review process differs from a ranking investigation. Follow the report’s instructions for the affected property. [3] [4]

New symptom → preserve dates, URLs, reports and deployment history
            ├─ security evidence → contain access → investigate → remediate → review
            ├─ manual action    → read scope → fix violation → request reconsideration
            └─ neither          → test technical, demand and content explanations
All branches → record uncertainty → validate the fix → monitor recurrence

2 · Collect evidence before assigning a cause

Minimum setup: authorized read access to Search Console, hosting or application logs, deployment history and a known-good file inventory. Use a spreadsheet or CSV for the incident record; no paid backlink subscription is required for an initial investigation. Keep raw exports with collection time and timezone. Restrict access to logs because they can contain personal information and credentials. The following is a proposed investigation workflow, not a measured detector.

1. Define the change. Record the first affected date, URL groups, country, device and search type. Compare equal reporting windows and account for weekday patterns, campaigns, seasonality and incomplete recent data. A change in clicks can reflect impressions or click-through rate; average position is an aggregate, not one universal rank.
2. Check known changes. Compare releases, redirects, canonicals, robots directives, indexing settings, outages and tracking changes. Select affected and apparently unaffected URLs. Inspect HTTP status and the current page before attributing a drop to an update.
3. Inspect platform evidence. Export the actual notice and affected examples if a manual action or security issue exists. URL Inspection can help examine indexing and fetched content, but one inspected URL does not represent an entire site. A site: query is an exploratory sample, not an index census.
4. Correlate independent artifacts. Match suspicious URLs with file changes, deployment approval, administrator activity and request logs. Write down an alternative explanation for each signal. Escalate an unexplained cluster; do not label an owner or reviewer malicious from a single shared attribute.

3 · Run the supplied detection exercises

Download the offline kit, extract it and open a terminal in the offline-defense folder. Python 3.10 or newer is the only prerequisite. Run:

python3 run_labs.py --output-dir run-output

Lab 2 compares invented file snapshots: one addition, one deletion and two modifications. One modified CSS file has an approved deployment; three changes still need review. Lab 3 distinguishes a formatting difference, a material text difference and an access-control mismatch. Lab 6 escalates a synthetic combination of an unapproved page, a content mismatch and a download lure. Inspect fixtures.json, then compare run-output/results.json with expected-results.json.

The committed run transcript records 33 passing assertions across six demonstrations. These observations establish the behavior of the supplied parsers, arithmetic and rules on invented inputs. They do not establish a production detection rate, live cloaking diagnosis, malware-scanner efficacy or ranking effect. No WordPress installation or browser emulator is included. The lab library explains each input and limitation.

4 · Match the remedy to the evidence

5 · Monitoring that produces an actionable record

Choose a review cadence based on how frequently the site changes and the cost of missing an incident; this guide does not prescribe a universal frequency. Review deployment diffs when deploying, route/security alerts when they fire, and search trends over comparable reporting windows. Maintain a record with: observation time; affected URLs; symptom; raw evidence path; approved-change reference; alternative explanations; owner; action; follow-up date; and outcome. Separate confirmed findings from open hypotheses.

For a worked hypothetical example, a new /support/update page appears after a release. A hash diff alone could be legitimate. The release manifest has no such page, the served text differs by access condition, and a lure asks for a download. Preserve these artifacts and escalate to security review. The same URL added by an approved documentation release with matching responses remains a routine change. This comparison is encoded in Lab 6; it is not an external incident report. For documented incidents and source limits, read the case database.

6 · Common diagnostic mistakes

• “No manual action means no problem.” Technical failures, security incidents and algorithmic changes can exist without that notice.
• “A traffic drop proves a penalty.” The symptom alone cannot separate demand, measurement, ranking and search-result presentation changes.
• “Every mismatch is cloaking.” Compare purpose and access conditions before attributing deceptive intent.
• “Disavowing every odd link is routine maintenance.” Follow the documented two-part threshold; the tool is an advanced remedy.
• “The simulator validates our defense.” Passing fixtures demonstrates specific expected behavior. Evaluation against independent realistic cases, including benign cases, is separate work.

7 · Sources and review scope

These primary documents support the platform rules above. The investigation sequence and synthetic scenario are editorial guidance, not claims about Google’s undisclosed implementation or measured operational performance.

1. Google Search spam policies. Google, living documentation. Primary platform policy.
2. A guide to Google Search ranking systems. Google, living documentation. Primary platform explanation.
3. Manual Actions report. Google Search Console Help. Primary procedure.
4. Security Issues report. Google Search Console Help. Primary procedure.
5. Verifying Googlebot and other Google crawlers. Google, living documentation. Primary technical instructions.
6. Disavow links to your site. Google Search Console Help. Primary procedure and limitations.