An email from Google Search Console lands in your inbox with a subject line about security issues or a manual action on your site. You open Search Console, find a report you have never looked at before, and it is full of terms like “code injection”, “social engineering” and “sample URLs”. It reads as though it was written for someone else.
It was written for site owners, but it assumes you already know the vocabulary. This post is a guided read of the two reports Google keeps under “Security & Manual Actions”: what each section is telling you, how the two reports differ, and what each kind of finding usually means for a small business website.
Two reports, two different kinds of problem
In the Search Console menu, “Security & Manual Actions” opens into two items. They sit side by side, but they come from different parts of Google and they are about different things.
| Security Issues | Manual Actions | |
|---|---|---|
| What it reports | Evidence that the site has been hacked or is harming visitors | A penalty applied by a human reviewer for breaking Google’s spam policies |
| Who is usually at fault | An attacker, most of the time | Often the site’s own practices, though hacking can be the cause |
| What it affects | Warnings in search and, for some types, in browsers | Ranking of some pages or the whole site, or removal from results |
| How you clear it | Fix the site, then request a review | Fix the cause, then file a reconsideration request |
The practical point: a hacked site normally shows up in Security Issues. If you see an entry in Manual Actions instead, read it carefully, because the remedy can be quite different.
Reading the Security Issues report
When nothing is wrong, the report shows a short message saying no issues were detected. When something is wrong, you see one or more issue types, each with a short explanation, a link to Google’s help page for that type, and a list of example URLs.
The issue types you are likely to meet
Google groups findings into a handful of families. The names are precise once you know what they mean.
- Hacked: content injection. Someone has added pages or text to your site. Typically spam pages about drugs, gambling or counterfeit goods, sometimes in a language you do not use. Our article on the Japanese keyword hack and other SEO spam describes the most common form.
- Hacked: code injection. Code has been added to existing pages, usually JavaScript that redirects visitors or loads something from another domain. The page looks the same, but it behaves differently.
- Hacked: URL injection. New URLs have been created on your domain, often in odd folders, that you did not make. This often overlaps with content injection.
- Malware and unwanted software. The site is serving, or linking to, software that can damage visitors’ devices or change their settings without consent.
- Social engineering. Pages designed to trick people, such as fake login forms or false virus alerts. This is the type behind the red browser screen we explain in the “Deceptive site ahead” warning.
- Harmful or uncommon downloads. Files on the site, or linked from it, that Google’s systems consider risky. These can be raised against legitimate files that few people download, so check before assuming a hack.
A site can have several types listed at once. An attacker who gets in usually does more than one thing, and each behaviour shows up as its own entry.
What the sample URLs are, and are not
Each issue lists example addresses. These are the pages where Google observed the problem. They are not a complete inventory, and the report says as much. On a site with a few thousand injected spam pages, you might see only a handful listed.
Use the samples as fingerprints. Look at what they have in common: a folder name, a pattern of random characters, a query string, a file extension that WordPress does not normally produce. That pattern is what you search for on the server. If every sample sits under something like /wp-content/uploads/2023/ with an .html ending, the problem is files. If the samples are ordinary pages of your site, the problem is more likely code that runs on every page, in a theme file, a plugin or the database.
The detection date
Each issue shows when Google first detected it. That date is when Google noticed, not when you were hacked. The real compromise may be weeks older. When you look through backups or logs, start well before the date in the report.
Who sees the report
Anyone with owner or full access to the Search Console property can see the report and receives the email alerts, depending on their notification settings. If the alert went to a developer who left years ago, or to an inbox nobody reads, you may have had a problem for some time. Check who has access under Settings, then Users and permissions, and make sure at least one person who still works with you gets the messages.
Reading the Manual Actions report
Manual actions are less common on small business sites, but they hit harder. A Google reviewer has looked at the site and decided it breaks a spam policy. The report names the action, says whether it affects the whole site or only part of it, and links to help on what to fix.
Names you might see include “Pure spam”, “User-generated spam”, “Unnatural links to your site”, “Cloaking and/or sneaky redirects” and “Thin content with little or no added value”. The wording Google uses can change over time, so read the exact title on your report rather than relying on any list.
When a manual action is really a hack
Some manual actions describe behaviour the owner never chose. “Cloaking and/or sneaky redirects” is the obvious one: injected code that shows Google one thing and visitors another is exactly what many hacks do. “User-generated spam” can come from a forum, a comment section or a profile area that bots filled with links. A sudden “Pure spam” action on a site that has always been a plain business brochure is worth treating as a sign of an infection until you have checked.
Others are usually self-inflicted: paid link schemes, pages copied from elsewhere, doorway pages built for a list of towns. A cleanup will not remove those, because there is nothing malicious to remove. They need a change to the content or the link profile.
Partial matches and whole-site matches
The report tells you whether the action affects specific pages or sections, or the entire site. A partial match on a folder of spam pages is a narrower problem than a site-wide match. Note which one you have before you plan the work.
Review requests and reconsideration requests
The two reports have their own “I have fixed this” buttons, and they behave differently.
In Security Issues, you request a review once every listed issue is fixed. It covers the site as a whole, so fixing one issue type and leaving another is not enough. We cover what to write in the request, and how to check the site the way Google sees it before you send it, in our guide to clearing “This site may be hacked”. Rather than repeat it here, the short version is: be specific about what you found and what you changed.
In Manual Actions, each action has its own reconsideration request. The reviewer wants to know what you changed and, for things like unnatural links, what you did about the links you could not remove. A request that only says “the site is clean” is weaker than one that lists the exact steps and the dates you took them.
For both, Google’s review time is not fixed, and you will get a message in Search Console when the result is in. If a request is turned down, the message usually points to what is still wrong.
Things the reports do not tell you
The reports are useful, but they have limits that catch owners out.
- A clean report does not mean a clean site. Google only reports what it has detected. A backdoor that has not been used yet, or a skimmer on a checkout page Google does not crawl, will not appear.
- The report does not say how the attacker got in. It describes symptoms. The entry point, whether an outdated plugin, a stolen password or something else, is yours to find.
- Other services keep their own lists. Clearing the issue in Search Console does not automatically clear warnings from antivirus products or other browser vendors, which run separate checks.
- Cleared does not mean de-indexed. Spam URLs can stay in search results for a while after the issue is lifted, until Google recrawls them. Our page on removing hacked pages from Google covers that clean-up stage.
A sensible way to work from the report
When you first open a report with findings, it helps to work in this order rather than jumping straight into files.
- Screenshot the report, including every issue type, the sample URLs and the detection dates. The report changes once you request a review, and you will want the original later.
- Group the samples by pattern so you know whether you are looking for planted files, injected code or database content.
- Check the property’s users and sitemaps while you are in Search Console, since attackers sometimes add themselves there too.
- Take a backup of the infected site before you start cleaning, so nothing you remove is lost as evidence.
- Clean the site and close the entry point, then confirm the sample URLs either return a not-found response or show your normal content.
- Only then request a review, with a plain list of what you did.
If what you read in the report is more than you want to untangle yourself, our Google blacklist removal service handles the clean-up and the review request together. For wider help with a compromised site, the hacked website repair page explains how to reach us. Send a screenshot of the report on WhatsApp, start the message with the word HACKED, and we will tell you plainly what it shows and what we would check first.
Next in this series: Website Hacker Extortion Email: Real Threat or Bluff?
