toolkit

Scenario · Something looks broken

The site's been compromised

Injected content confirmed, a host suspension, or a browser warning on the client's domain.

Finding injected spam on a site is a detection; what happens next is the actual emergency, because cleaning up the visible mess while the door that let it in is still open just means the same content comes back within days. This preserves evidence of exactly what was publicly visible before anything gets touched, and scopes the injected content across the whole site rather than just the one page someone noticed — the actual containment, credential rotation and cleanup all still happen by hand, in that order, because cleaning before securing is the single most common reason this recurs.

What to ask for

Injected-content scanInjected-content scan — finds content on a site that should not be there.Pre-cutover site archiveArchives the old site before it stops existing, hash-bound and content-addressed.WordPress inspectorRead-only WordPress site inspector — fetches a URL and reports what the site is running before you touch it: whether it is WordPress at all, the WP and PHP versions, web server and managed host, active theme and child theme, the page builder (Divi 4 vs 5, Elementor, Beaver Builder, WPBakery, Bricks, Oxygen, Gutenberg), the plugins visible from outside, the caching and CDN layer, and externally-visible security notes — into a DETECTED / LIKELY / NOT WORDPRESS verdict plus an HTML report.WP plugins & themeWordPress plugin and theme audit — takes the plugins and active theme a site exposes and checks each against the WordPress.org directory for freshness: outdated (behind latest), abandoned (long since updated), and lagging the current WordPress version.Search Console seriesOptional integration — reads Search Console's Search Analytics API and writes the data series nothing else has.

See it work

A real run of Injected-content scan:

FAIL
      [error] Pharmacy spam: "Buy cheap viagra"

  report: ./out/injected-content-scan-injected-content-scan.html
  text:   ./out/injected-content-scan-injected-content-scan.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The scan finding injected content is a detection; this is the response. The difference matters because cleanup without containment produces a site that gets reinfected within days, and everyone involved concludes the cleanup failed.

  1. [manual] Escalate before investigating. The site owner and whoever holds the hosting need to know now. If there is any possibility patient data was exposed, the practice’s breach obligations start at this moment and are not ours to defer.
  2. Preserve the evidence first, before anything is cleaned. The archive captures every page’s HTML, headers and screenshots, hash-bound. Cleanup destroys the only record of what was public and for how long — and that record is what any later question about exposure depends on.
  3. Scope what is publicly visible. The injected-content scan across the whole URL list, not one page: pharmacy and casino spam, phishing pages, foreign-script keyword blocks, hidden link stuffing, and injected page clusters in the declared sitemap. The sitemap clusters are how you find the hundreds of pages nobody linked from the site.
  4. Read the stack and its known weaknesses. The WordPress inspection reports versions, theme and plugins; the plugin audit flags the abandoned and known-vulnerable ones. This is not the entry point — it is the candidate list, and it is what the host’s logs get checked against.
  5. Check what search engines have already seen. Search Console will report security issues and manual actions, and the index will contain the injected pages. This is also where the recovery request eventually goes.
  6. [manual] Contain, then clean, in that order. Rotate credentials, revoke sessions and keys, patch or remove the vulnerable component — then remove the injected content. Cleaning first with the door still open is the single most common reason this recurs.
  7. [manual] Remove the injected pages properly. They are indexed: they need removing and returning 410 or 404, not silently deleting. Then request review in Search Console.
  8. Re-scan, and keep re-scanning. Clean once proves nothing. Run the scan daily for a week — reinfection shows up fast and is the signal that containment failed.

Containment before cleanup

Steps 6 and 7 are in that order deliberately, and it is the order people reverse under pressure, because removing visible spam feels like progress. A cleaned site with the vulnerability still open is indistinguishable from a fixed one for about three days.

What this does not cover

Incident response, forensics and the entry point. Everything here reads the site from the outside: it confirms and scopes what is publicly visible and preserves evidence, and it cannot tell you how they got in, what else they touched, or whether they still have access. Server-side cleanup, log analysis and credential rotation are the actual remediation and none of them happen from here. If patient data may be involved, that is a breach-notification question and it starts immediately, not after cleanup.

← All scenarios