WordPress Security Services

What Our Traffic Sample Actually Shows

We reviewed three days of CloudFront access logs from three properties we operate, filtered to each property's exact hostname. The sample contains 863,802 requests. The review rules flagged known attack tools, suspicious file probes, and requests with no user agent. Those are useful leads for investigation, but they are not a reliable count of confirmed attacks: an absent user agent alone does not establish intent.

These percentages describe this sample and this classifier. They are not a controlled comparison of platforms, and they do not mean that one in five requests to every WordPress site is hostile. The sites have different audiences, request volumes, and exposed endpoints; a ratio between percentages is also not a ratio between request counts. What the logs do establish is that routine internet traffic includes probes your application should be prepared to reject.

How They Actually Do It

Across the three-day sample, the WordPress login endpoint received more than 4,300 requests and the XML-RPC interface another 2,179. That volume explains why authentication endpoints need monitoring and rate controls, but access logs alone do not prove that every request was a failed login or an exploit attempt. Requests without a user agent also need context before classification; they are still visible in the logs.

The clearest reconnaissance asked for environment files, source-control metadata, backup copies, and cloud credential files. Keep those materials outside the publicly served tree and deny access to sensitive paths at the web server. A request for a secret is evidence of a probe; its response status and body determine whether anything was exposed. Review the response as well as the request, and investigate an unexpected success instead of treating a large scanner count as the incident itself.

If You Have Just Been Hacked: The First Hour

Contain the affected service and preserve evidence before rebuilding it. Restrict access or serve a clean maintenance response outside the compromised application, capture relevant logs and snapshots, and record the time and scope of the incident. Avoid destructive cleanup that removes the evidence needed to identify the entry point.

Revoke exposed access and rotate affected credentials from a trusted environment. Do not put replacement secrets back onto a system an attacker still controls. Restore a known-good backup into clean, isolated infrastructure, then investigate and close the entry point before returning traffic. A backup taken before discovery is not automatically a backup taken before compromise.

Validate the database, media, users, scheduled jobs, and external integrations as well as the application files. Chapter 10 describes the recovery checks. If you need an engineer to coordinate containment and recovery, call (919) 459-7857 or use the form below.

What Professional WordPress Security Looks Like

Real security work is mostly unglamorous engineering, applied consistently. On the infrastructure we operate, WordPress runs in hardened containers that execute as non-root users with privilege escalation blocked at the cluster level, which limits some post-compromise actions. Those controls do not prevent a compromised application from abusing its own database permissions or exposed credentials. Images rebuild from source and redeploy from Git, which makes application code reproducible. Full recovery also requires trustworthy database and media state, secret rotation where needed, and verification of the original entry point. Operating systems patch on a monthly managed cadence, dependency updates flow through automated pull requests, and our own hardened worker images carry the security tooling with them.

Around the application, the edge does quiet, constant work: cache hits reduce origin work, and rate limits and firewall rules can reject unwanted requests. Robots.txt expresses preferences to cooperating crawlers; it neither enforces access control nor stops an attacker. Use managed secret storage and workload identity where supported, restrict each workload to the access it needs, and retain deployment and administrative audit logs. Verify the exceptions: an integration that still needs a long-lived key needs an owner, a rotation policy, and a limited scope. The WordPress hardening guide treats security as risk reduction, not a guarantee. It is the discipline of doing it every time, which is precisely what a business owner should be buying.

What You Can Honestly Do Yourself

Not every site needs an engineering firm, and we would rather tell you that than sell you a retainer you do not need. If you run a brochure site on a reputable managed host, you can get most of the way there on your own: turn on two-factor authentication for every admin account, delete the plugins you are not using rather than merely deactivating them, keep automatic updates on for everything you can tolerate, confirm your host takes backups you have actually test-restored once, and use a password manager so your credentials are not a pattern.

The moment to bring in an expert is when the stakes change: you take payments, you hold customer data with regulatory strings attached, your revenue depends on uptime, or you have been compromised once already. At that point security stops being a plugin choice and becomes an architecture question, and architecture is an engineering conversation.