How SEO spam hacks hide on WordPress sites, and how to find them

What Google calls hacked content

Google’s spam policies define hacked content as “any content placed on a site without permission, due to vulnerabilities in a site’s security”, and list four kinds. They are a useful map of where to look:

• Code injection. Malicious code inserted into pages that already exist, often JavaScript added to the site or inside iframes.
• Page injection. Whole new pages added, often to manipulate search rankings or for phishing. The owner may see nothing wrong with the original pages.
• Content injection. Subtle changes to existing pages so that search engines see material that visitors and owners hardly notice, such as “adding hidden links or hidden text to a page by using CSS or HTML”, or more complex changes such as cloaking.
• Redirects. Injected code sends some visitors to spam or harmful pages. “The kind of redirect sometimes depends on the referrer, user agent, or device”, so a link clicked in search results can redirect where a direct visit does not.

The consequence is stated plainly: “Sites that violate our policies may rank lower in results or not appear in results at all.” The client’s rankings suffer for what an attacker did, and the agency is the one asked why.

Why the owner does not see it

Cloaking is the common thread. Google defines it as “presenting different content to users and search engines”, with the example of “inserting text or keywords into a page only when the user agent that is requesting the page is a search engine”. Google’s Security issues report help adds that hackers may use cloaking to avoid detection by site owners, that many hackers make changes visible only to Google’s machines, and that the URL Inspection tool is the way to see what Google sees.

On WordPress the spam can live in several places: a plugin or theme file, the .htaccess file, a database option or a user account added by the attacker. WordPress’s own FAQ on hacked sites says the .htaccess file deserves the closest look and that the first step is to write down the specific signs you can see, because “a hack” is vague.

Check a client site in five steps

1. Search the site for words it should never contain. In Google, search site:www.example.com followed by terms such as pharmacy brands, casino, replica or loan. Google suggests site: searches to find other affected pages once you have found one. Also scan the first pages of plain site:www.example.com for titles you do not recognise.
2. Ask Google what it sees. Open the page in Search Console’s URL Inspection and look at the crawled page, then read the Security issues report. Google calls that report the source of truth for whether issues exist or have been fixed.
3. Request the page like a crawler, and like a searcher. Compare what the server sends to different visitors:

curl -s https://www.example.com/ -o plain.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.example.com/ -o crawler.html
curl -s -L -e "https://www.google.com/" https://www.example.com/ -o from-search.html
diff plain.html crawler.html
diff plain.html from-search.html

Google’s guidance is to use cURL or Wget with a custom referrer or user agent to mimic a target. A difference is a finding. No difference is not proof: a hacker can key on the visitor’s address, and your machine is not Google’s. That is why step 2 matters.

1. Look at the files and the users. In WordPress, check .htaccess, wp-config.php, the theme’s functions.php, the plugin list, and the user list for accounts nobody remembers. Compare the core files with a clean download of the same version.
2. Check the other hosts. Spam is often placed on subdomains and old staging copies. Add them to the search and the requests above.

If you find it

Follow the order WordPress’s FAQ gives: record what you see, scan the site, change every credential (FTP or SFTP, wp-admin, the hosting panel, the database), force a password reset for all users, replace the secret keys in wp-config.php so that signed-in sessions end, take a snapshot of the infected site before cleaning, then reinstall /wp-admin and /wp-includes from clean files of the same version and review wp-content. Google adds that fixes must cover the whole site, since fixing some pages earns no partial return to search, and that after you request a review in the Security issues report, spam-hacked sites may wait up to several weeks. Tell the client early and plainly; see Incident communication to clients.

What outside monitoring can and cannot see

Be exact about this. Beamfar’s Security checks read a site the way a visitor does and, for a site whose domain you proved with a DNS record, the way a search engine and an AI crawler do, and report possible problems with the evidence that was seen. They read the home page, the pages your own checks monitor and some internal links (how many depends on the plan). They look for scripts and frames from a host the site did not use before, links and text a visitor cannot see, spam vocabulary, redirects to another site (including one only for visitors who arrive from a search result), and, after that proof, pages that differ when they are requested with Googlebot’s or an AI crawler’s user agent. Each one is a lead, not a verdict that the site was hacked: a new analytics script looks the same from outside, and you can mark a finding as expected. The first scan of a site only sets the starting point, so it sends no alert.

The checks do not see inside the server: not the files, the database or the user list, so step 4 above stays yours. A request that only changes the user agent does not catch a hacker who checks Google’s real addresses, which is why the URL Inspection step matters, and a firewall that refuses crawler-like requests is reported as a notice, not as a problem on the site. Beamfar is not a firewall and does not block anything or clean anything. It has been tried on test pages only and has no customers yet.

Two things outside the Security checks help to date a problem. The page check keeps the final address of the page, so a redirect that starts to send every visitor somewhere new is recorded with its time, and it alerts when a page becomes noindex, when robots.txt starts to block it or when its canonical moves to another host. For the rest, rely on the checks above, the host’s scanner and a monthly maintenance routine. The WordPress-specific checks are in Website monitoring for WordPress sites.

Questions

Sources

Read on 28 October 2026. Standards and vendor pages change; confirm the current text before you rely on it.

• Google Search Central, Spam policies for Google web search (hacked content, cloaking) (developers.google.com)
• Google Search Console Help, Security issues report (read through a search summary of the page) (support.google.com)
• WordPress documentation, FAQ My site was hacked (read through a search summary of the page) (wordpress.org)
• Google Search Central, Google’s common crawlers (the Googlebot user agent and how to verify it) (developers.google.com)