Secure WordPress hosting is mostly unglamorous hygiene on a maintained runtime. TLS certificates, current PHP, and a vendor who patches the platform matter. They do not replace updates you skip, plugins you collect like souvenirs, or an admin user with a reused password.

WPHost manages infrastructure security basics: PHP 8.4, HTTPS (preview immediately; custom-domain certs after DNS), isolated site workflows, deploy history for file rollback. We do not auto-update WordPress core or plugins. That is not a security hole in the brochure sense — it is a control choice. Unowned auto-updates break sites; owned manual updates require discipline. Pick discipline.

The threat model that actually hits small sites

Most WordPress compromises are boring:

  • Outdated plugin with a known exploit
  • Weak or shared admin credentials
  • Infected theme “nulled” from a random mirror
  • Exposed XML-RPC used for amplification or brute force
  • Backup files left web-readable
  • Admin AJAX endpoints abused by spam bots

Nation-state drama is rare. Scripted scans are constant. Your job is raising the cost of the script.

What the host secures for you

  • Transport encryption via HTTPS
  • A current PHP language runtime (old PHP is a CVE farm)
  • Operational boundaries between sites on the platform
  • Logs when you need to investigate
  • No requirement to expose SSH to the world just to run WordPress

What the host does not secure for you: your editorial decisions inside wp-admin. See managed hosting for the split.

Updates: the main event

Check for core, theme, and plugin updates regularly. Backup first (database-aware plugin — deploy history alone is insufficient). Apply updates. If you fear page builders, use staging on Pro+, copy the DB if needed, update there, then production.

Abandoned plugins with last updates from years ago are liabilities. Delete them. “But it still works” is how quiet holes stay open.

Fewer plugins, fewer doors

Every plugin is executable PHP on your origin. Prefer one good plugin over three overlapping ones. Remove demo plugins from theme bundles. Do not install random “security suite” monsters that rewrite .htaccess into knots unless you understand them — sometimes they help; sometimes they become the vulnerability.

Accounts, 2FA, and usernames

  • Do not use admin as a username on new installs.
  • Store passwords in a password manager.
  • Install a reputable two-factor authentication plugin for administrator (and ideally editor) roles.
  • Use least privilege: authors do not need administrator.
  • Offboard contractors by resetting credentials, not by hoping they forget.

Agencies: team seats on Business beat shared passwords in Notion — agencies.

XML-RPC and application surface

xmlrpc.php still exists for legacy remote publishing and some integrations. It is also a classic abuse target. If you do not need it, disable it via plugin or server rule appropriate to your stack. If you need Jetpack-style features that depend on it, leave it and harden elsewhere (rate limits, strong auth). Blindly copying “disable XML-RPC” from a blog without checking dependencies causes mysterious breakages — test on staging.

Disable file editing in wp-admin on production:

define( 'DISALLOW_FILE_EDIT', true );

in wp-config.php — covered in setup. It will not stop a determined attacker with file write via a plugin hole, but it removes a convenient abuse path for stolen admin sessions.

HTTPS is necessary, not sufficient

Certificates prevent passive network snooping and many mixed-content problems. Attackers who steal wp-admin via phishing still win. Set WordPress Address and Site Address to HTTPS after DNS — custom domain. Never run a public login form over HTTP.

Backups are part of security

Ransomware and defacement recovery is a restore problem. Deploy history restores files, not MySQL content. Use UpdraftPlus or similar to off-site storage. Test a restore once — SSL and backups. A backup you never tested is a story you tell yourself.

WooCommerce and membership notes

Stores and members areas raise value per breach. Use gateway-hosted payment fields where possible; we are not a PCI product — Woo. Keep membership plugins updated; cache carefully so private content is not served publicly — membership.

What we refuse to pretend

  • No built-in CDN WAF product as a silver bullet
  • No concierge malware cleanup SKU in this doc
  • No auto plugin patching
  • No cPanel “security” icons
  • No nonprofit-only hardening package — same public plans ($9 / $30 / $65 / $130)

If you need a vendor who patches plugins under contract, hire that maintenance firm or a concierge host. We will still recommend current PHP and HTTPS.

A monthly security hour

  1. Backup (files + DB) off-host.
  2. Apply updates (staging first if available).
  3. Delete unused plugins/themes.
  4. Review users list for strangers.
  5. Skim access logs for weird peaks.
  6. Confirm 2FA still enabled.
  7. Confirm certificates valid on the custom domain.
  8. Confirm backup destination still authenticates.

Beginners: start simpler with hosting for beginners. Pillar context: WordPress hosting guide.

Principle of least plugin

Before installing a new plugin, write the problem in one sentence. If a snippet in the child theme or a block pattern solves it, skip the plugin. Every dependency is a future CVE inbox message. Agencies should maintain an allowlist of plugins they will support — agencies.

Incident basics if you are compromised

  1. Take the site out of public serving if possible; keep backups offline copies.
  2. Reset all salts and passwords; force logouts.
  3. Restore from a known-good backup, not from the infected tree.
  4. Update everything on a clean rebuild.
  5. Review how they got in (old plugin, weak admin, nulled theme).

Deploy history may help if the infection was a bad file deploy you can roll back — it will not help if malware lived only in MySQL. That is why DB backups matter — SSL and backups.

Salts, prefixes, and stolen sessions

WordPress authentication cookies depend on the salt keys in wp-config.php. After a staff laptop is compromised, rotate all eight salts from the official generator and deploy the new config. Everyone signs in again; stolen cookies die. That is cheaper than pretending a logo on a security plugin replaced key management — setup.

Changing $table_prefix after install is not a weekend hardening project; do it only on greenfield installs if you bother at all. Obscurity is mild. Updates and 2FA are not.

DNS and certificate hygiene as security

Phishing pages love lookalike domains. Keep your real custom domain on HTTPS after DNS verifies; do not leave an old host serving a clone with a valid-looking theme. Preview URLs are fine for builds; production marketing should use the domain you own. Mixed content after a domain move trains users to ignore browser warnings — fix siteurl/home properly — custom domain.

WPHost plans ($9 / $30 / $65 / $130) do not include a magic WAF SKU or email-hosted security alerts inbox. Pair HTTPS and current PHP with your own update ritual. Trial ~1 day exists to prove the runtime, not to outsource vigilance.

Vendor plugins and supply chain

Premium plugins from reputable vendors beat random GitHub zips emailed by strangers. Verify download sources. Nuke nulled themes. Supply-chain hygiene is security work that hosting badges cannot skip.

FAQ

Does WPHost scan my plugins for CVEs?

We do not market an automated plugin CVE concierge. Keep plugins updated yourself; subscribe to project release notes for critical sites.

Is disabling XML-RPC required?

No. It is risk reduction if unused. Verify dependencies before disabling.

Are nullam / pirated themes a big deal?

Yes. They often ship backdoors. Buy or use legitimate themes.

Will DISALLOW_FILE_EDIT stop all hacks?

No. It is one layer. Defense in depth: updates, 2FA, backups, least privilege.

Does a firewall logo mean I’m safe?

Not by itself. Application hygiene dominates small-site outcomes.