A WordPress pharma hack is an SEO-spam compromise, not a content-management mistake. Attackers create or cloak drug-related pages so search engines index URLs that administrators may never see in the normal WordPress post list. The priority is to remove the serving mechanism and the persistence behind it, then clean the search footprint.
Confirm what Google and visitors are actually receiving
Collect several indexed spam URLs from Search Console or a site search, request them logged out and compare the HTML with the WordPress dashboard. Record status codes, canonical tags, redirects and whether the response changes by user agent or referrer. That separates stored spam pages from cloaking or dynamic injection.
Evidence worth preserving before cleanup
- Example spam URLs and cached/search-result titles.
- The response HTML and redirect chain for affected URLs.
- Recently modified PHP, theme and plugin files.
- Unknown administrators, scheduled tasks and unusual database options.
Find the layer generating the pharmaceutical pages
If the URLs are visible to Google but not in WordPress, compare the pattern with SEO spam pages that appear only in search. If executable files have been planted in writable media directories, inspect malicious PHP in wp-content/uploads. The visible pages are evidence; the writer is the incident.
Clean the source before requesting removals
- Preserve suspicious files and access logs.
- Remove the confirmed loader, injected code or compromised component.
- Reinstall affected code from trusted packages and rotate exposed credentials.
- Make spam URLs return the correct 404/410 or canonical response after the origin is clean.
- Use Search Console cleanup/removal tools only as an acceleration step, not as the repair itself.
Do not solve a pharma hack with a blanket robots.txt rule
Blocking crawling can hide evidence from search engines while the compromised site continues serving spam to users. First make the origin trustworthy and deterministic.
How to know the incident is over
Representative spam URLs no longer return injected content, no hidden writer recreates them, legitimate pages remain intact and Google gradually drops the unwanted URLs after recrawling.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Search results can remain polluted after the visible site looks normal. You need to map where the spam is generated, what recreates it and which URLs Google has discovered.
- 1
Export affected URLs and query patterns from Search Console.
- 2
Compare crawler and normal-browser responses for representative URLs.
- 3
Search files, database options, posts, rewrite rules, mu-plugins and cron.
- 4
Record unexpected users, modified files and vulnerable components.
What must be verified
- No new pharma URLs are generated.
- Representative spam URLs return the intended status and are absent from sitemaps.
- File integrity, users and cron remain stable through several cycles.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If the visible site looks completely normal, does that mean the pharma hack is gone?+
No. Cloaking means search crawlers and normal visitors can be shown different content, so a clean-looking browsing session does not rule out an active infection. Comparing crawler responses against normal-browser responses for the same URLs is required to know for sure.
Why do spam pages keep showing up in Google search results after the site files look clean?+
Search results can stay polluted long after the generator is removed, because Google needs to recrawl and drop already-indexed spam URLs. Returning accurate 404 or 410 statuses for the removed pages and cleaning the sitemap speeds up that recovery.
Is it safe to request a Google security review as soon as the spam pages seem to be gone?+
Not yet. A review should only be requested after live inspection is confirmed clean under the same crawler conditions that revealed the spam in the first place, since cloaking can hide a live infection from a casual manual check.
How is a database-injection pharma hack different from one using dynamic cloaking?+
Database injection stores the spam titles, links, or templates directly in posts or options tables, while dynamic cloaking uses PHP code to generate pharma content on the fly, specifically for search referrers or crawler user agents. Exporting affected URLs from Search Console and comparing crawler versus normal responses helps distinguish which pattern is in play.