“Social engineering content detected” means your site was used to deceive its visitors.

Google uses “social engineering” for pages that deceive the visitor into doing something harmful themselves: typing credentials into a fake login that imitates a bank or a mail provider, calling a fake technical-support number, downloading software that pretends to be an update, or following instructions on a fake verification screen. The common factor is that the victim performs the damaging action.

On a legitimate business site, that content is nearly always there because the site is compromised. Typical shapes are a phishing kit unpacked into a folder under wp-content/uploads, a set of pages imitating a well-known brand, or a script injected into every page that overlays a fake prompt on top of your real content.

The ClickFix lure belongs in this class: a fake CAPTCHA or “verify you are human” panel that tells the visitor to paste a command into their own computer. It is documented on this site from an incident across more than 30 WordPress sites, where the lure was fed from several layers at once.

Figure 1 · From notice to review

A review request is the last step, not the first.

Find it

1. Security IssuesIssue type and sample URLs
2. Reproduce as a victimClean profile, from search, on a phone
3. Trace the sourceLogs, files, database, rules

Fix it, then ask

1. Remove every layerNot just the lure page
2. Close the entry pathThen rotate credentials
3. VerifyVisitor view and URL Inspection
4. Request reviewWhat was found, removed, fixed

1. 01

   Read the issue in Search Console

   The Security Issues report states the issue type and, where Google provides them, sample URLs. Start with those exact URLs, not with the home page.

2. 02

   Reproduce as a victim would

   Open each sample in a private window on a phone or a clean browser profile, ideally by searching for the site and clicking the result. URL Inspection’s live test shows what Google itself receives.

3. 03

   Look for unfamiliar folders and pages in uploads

   Phishing kits are HTML and PHP files sitting where only images should be. List them with their timestamps:

   shell

   $ find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.html' -o -iname '*.htm' \) -ls 2>/dev/null

   A folder named after a bank, a mail provider or a delivery company, or an index.html in a dated uploads folder, is the usual shape.

4. 04

   Search the database for injected scripts

   Overlays injected into every page usually arrive through a script tag stored in posts or options. A read-only query finds candidates:

   WP-CLI

   $ wp db query "SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_value LIKE '%<script%' ORDER BY 2 DESC LIMIT 20"

   Adjust the wp_ prefix to your own. Widget and theme options legitimately hold some scripts; long, encoded or external-domain scripts are the ones to read.

5. 05

   Check the access logs for the sample paths

   Who requested them, from where, and what the server answered. A form that receives POST requests on a page you never built is a phishing kit collecting credentials:

   shell

   $ grep -E 'POST .*(/wp-content/uploads/|\.html)' /path/to/access.log | awk '{print $1, $4, $7}' | tail -50

1. 01

   Preserve first

   Copy the deceptive pages, any kit archive, the injected scripts and the access logs before deleting anything. If credentials were harvested, the logs are what tells you whose.

2. 02

   Remove every layer

   The kit or lure pages, the loader that injects them, and the persistence that would restore them: rewrite rules, drop-ins, mu-plugins, scheduled tasks, startup directives and rogue administrators.

3. 03

   Close the entry path and rotate access

   Update or remove the vulnerable component, and change control-panel, SFTP, database and WordPress credentials from a clean device.

4. 04

   Verify from the visitor’s side

   Every sample URL should now return 404 or legitimate content to every kind of visitor — from search, on a phone, logged out — and to URL Inspection’s live test.

Request the review from the Security Issues report only when the verification step is complete. The request is read by people who are checking whether the deceptive content is gone; a short, specific account helps them do that.

Say what was found and where (for example, a phishing kit in a folder under uploads, and a script in an options row that loaded an overlay), what was removed, how the attacker got in and how that was closed, and that credentials were rotated. Do not claim the site was never compromised if it was, and do not request a review “to check” whether it is clean.

If the review fails, Google’s response will indicate that deceptive content is still being served. Treat that as information: something survived, and a second request without new cleanup work will fail the same way.