A scan is not automatically a breach

Requests for `/wp-login.php`, `xmlrpc.php`, `.env`, repository metadata and old package paths happen to almost every public domain. Most are opportunistic probes rather than evidence that the scanner knows what the site runs.

The right response is not panic or an endless collection of deny rules. It is defense in depth: expose less, isolate each workload, bound traffic, patch real software, retain useful logs and make recovery routine.

Treat every client as its own failure domain

One agency account must not become one shared runtime. A compromised CMS, leaked credential or runaway process should be contained to that client’s site and data.

  • Separate namespace or equivalent tenant boundary per client environment
  • Default-deny network policy and no access to platform or other client networks
  • Non-root containers, dropped capabilities and restricted pod security
  • Per-client CPU, memory, storage and replica limits
  • Separate secrets, domains, certificates, backups and audit trails
  • Explicit owner and operator permissions for every site

Static sites and WordPress need different policies

A static site has no reason to accept WordPress administration or XML-RPC traffic, so those probes can be rejected before they reach the container. A real WordPress site cannot use the same blanket rule because `/wp-admin` and `/wp-login.php` are legitimate application paths.

WordPress needs a dedicated profile: tightly rate-limited login routes, MFA for administrators, controlled plugin and theme updates, protected database credentials, file-integrity monitoring, malware scanning and tested off-site backups. Pretending one ingress snippet fits both workloads creates either broken sites or weak security.

Put recovery beside prevention

Rate limits, TLS, security headers and sensitive-file blocking reduce exposure, but they do not replace a recovery path. Every client site needs an immutable release identity, health verification, a known rollback and a backup policy appropriate to its data.

AnchorScape already uses isolated environments, restricted Kubernetes workloads, network policy, release evidence and rollback controls. Agency hosting is being evaluated inside its private pilot. WordPress-specific hosting is not presented as generally available until its runtime, update, backup and malware-response profile has been proven.