WordPress Security Best Practices: Owner’s Checklist

Updated October 2026. WordPress security best practices are not a list of plugins to install once and forget. A safer website depends on who controls the accounts, how quickly vulnerable software is updated, whether backups can actually be restored, which customer data is collected and who responds when something goes wrong.

Quick answer: protect administrator and hosting accounts, enable suitable multifactor authentication, keep WordPress core, themes and plugins supported and updated, remove unused software, maintain independent tested backups and monitor for unexpected changes. Assign a named person to each responsibility.

This guide is a practical WordPress security checklist for website owners, agencies and small business teams. It covers roles, updates, hosting, backups, contact forms, ecommerce, incident response and a realistic maintenance schedule. These controls reduce risk; they cannot make a site completely secure or certify compliance with laws that depend on the website’s actual business and data.

1. Understand what you need to protect

Begin with a short inventory rather than a “security score”. A simple brochure website needs reliable publishing and contact forms. A WooCommerce shop also handles order records, customer accounts and payment-provider connections. Membership and course websites add further identity and access concerns.

Write down the actual provider, account owner, emergency contact and recovery method for each critical system. Keep this inventory somewhere authorised staff can reach even when the WordPress dashboard is unavailable.

2. Keep domain, hosting and administrator ownership with the business

The company should control its registered domain, hosting subscription, primary billing account and recovery contact. A freelancer or agency can operate the website with delegated access, but shouldn’t become the only person able to recover a business’s online presence.

Use separate named accounts for staff and developers. Avoid sharing one permanent administrator password in a messaging group. Remove former workers and unused integrations when their assignment ends. Review the recovery email too; it can be a path to take over other accounts.

WordPress’s Roles and Capabilities documentation distinguishes Administrator, Editor, Author and other permissions. An employee who only updates blog posts generally does not need rights to install plugins or modify site-wide settings.

Actual capabilities can be changed by plugins, custom roles and multisite settings, so verify the effective permissions on the live installation rather than relying solely on a role label.

3. Secure passwords, recovery accounts and multifactor authentication

Use a unique strong password for each account, ideally generated and stored in a reputable password manager. Protect hosting, domain registrar, WordPress and associated business email accounts as a connected system. Reusing one password across them increases the damage a single credential leak can cause.

Multifactor authentication (MFA) adds a separate factor beyond a password. The OWASP MFA Cheat Sheet explains why factors should be independent and why changing or recovering an MFA factor needs special protection. Use authenticator applications or phishing-resistant methods where the platform supports them, and store recovery codes securely outside the website.

• Require MFA for critical administrator, hosting, registrar and email accounts when available.
• Give each person their own login, not a shared OTP or permanent account.
• Review how an administrator will regain access if a device is lost.
• Protect recovery and account-change procedures from social engineering.
• Check existing access before adding a social-login or one-time-password plugin; extra login methods can increase the attack surface when poorly maintained.

A login page with a different URL can reduce nuisance traffic, but hiding or renaming a path is not a substitute for strong authentication, authorisation and software maintenance.

4. Keep WordPress, plugins and themes supported and updated

Outdated components can contain publicly known vulnerabilities. WordPress’s official hardening handbook emphasises staying current and downloading WordPress from legitimate sources. The auto-updates documentation explains how a website owner can enable plugin and theme auto-updates individually.

First maintain an inventory: core version, theme, child theme, active plugins, inactive plugins, premium licences, external scripts and custom code. Identify which provider releases updates and which person checks for compatibility.

For a high-impact update, create a safe restore point and test representative customer actions. Auto-updates can be useful but need monitoring for failed installations and regressions. Do not postpone a known critical security fix indefinitely in the name of perfect staging tests; plan a rapid controlled response.

5. Reduce unnecessary plugins and assess new dependencies

Every extension changes the software and permission footprint. More plugins do not automatically mean a less secure site, and fewer plugins do not automatically make it safe. The real questions are whether the code is maintained, necessary, correctly configured and operating with appropriate privileges.

Before adding a form builder, SEO tool, social-login plugin or marketing widget, verify what data it processes, who can configure it, whether the vendor maintains it and what happens if updates stop. Avoid pirated or “nulled” premium plugins and unofficial software archives. Remove redundant plugins through the appropriate WordPress administration process after confirming that none owns data or a workflow the business still needs.

For choosing a manageable stack, read VYLINO’s guide to selecting free WordPress plugins. A useful setup favours a small number of well-maintained components with clear support responsibilities.

6. Configure hosting, HTTPS and file permissions carefully

The web server, database, PHP runtime, hosting panel and WordPress application all affect the security of the final website. HTTPS is necessary for protecting traffic in transit, but it does not stop unsafe plugins, stolen administrator sessions or a compromised hosting account.

Use supported server software, restrict unnecessary remote services and require secure administration methods provided by the host. Follow the hosting provider’s implementation guidance before changing file ownership, PHP settings or web server rules. Incorrect hardening can break updates or unintentionally expose files.

The official WordPress file-permissions guidance describes how writable access depends on the server’s ownership model. Do not blindly apply public commands or make all directories writable simply to resolve an upload error.

WordPress’s hardening handbook also describes disabling the built-in plugin/theme file editors where appropriate. Such configuration may reduce one avenue of code changes by an attacker with administrative access, but it does not replace account security and will not stop every malicious upload.

7. Treat backups as a tested recovery system

A dashboard message saying “backup completed” is not the same as successfully restoring the site. The official WordPress backup guidance distinguishes application files and the database and recommends treating them as a consistent backup set.

Agree two business measures: recovery point objective (RPO), the maximum data the organisation can accept losing, and recovery time objective (RTO), the acceptable duration for restoring a service. These are planning objectives, not guarantees from a backup plugin.

Keep suitable backups outside the production site’s failure boundary, protect access to them, define retention and test restoration in an isolated environment. Note that restoring an older database may remove newer orders, form submissions or membership activity, so the business must understand the practical impact before recovery.

Test not only whether the front page displays, but whether users can log in, forms are delivered, images load, and store or booking records are intact.

8. Protect forms, uploads, third-party integrations and personal data

Forms should collect only what the business needs. A generic contact form typically should not invite passwords, government identification numbers, card details or confidential documents. Clearly identify where enquiries are delivered and who is authorised to access them.

File uploads deserve separate consideration. The OWASP File Upload Cheat Sheet recommends controlling accepted types and sizes, validating content on the server, controlling storage/access and using additional scanning where appropriate. Merely checking a filename extension in the browser is not enough.

• Confirm the legitimate purpose of each form field and attached document.
• Use secure transport and restrict who can view or export submissions.
• Check what marketing, CRM, analytics and email tools receive.
• For uploads, define allowlisted file types, size limits, private storage and retention rules.
• Protect integrations using scoped credentials; rotate or revoke credentials when staff or providers change.
• Do not record personal form content inside ordinary page URLs or analytics event labels.
• Review applicable privacy obligations based on the actual business rather than using a generic policy as proof of compliance.

9. WordPress REST API and XML-RPC: avoid blanket fixes

WordPress includes interfaces that themes, editors, applications and plugins can use. Some online guides advise switching off the REST API or XML-RPC in every installation. That can disable legitimate functionality and does not automatically fix access-control weaknesses in installed software.

Review which interfaces the site actually uses and whether the host or security configuration properly enforces authentication, authorisation and rate controls. Unused endpoints can be assessed for restriction, but a site-wide change must be tested against the block editor, integrations, mobile applications and relevant plugins.

A developer should be able to explain the specific risk being addressed and the rollback plan. Avoid copying opaque code snippets into a production website without understanding their effect.

10. Test WooCommerce and authenticated workflows after changes

Ecommerce has security requirements beyond a basic content site. A WooCommerce store must keep customer-specific cart and account information separate, handle payment-provider connections reliably and preserve order integrity. Wrong cache rules or aggressive script changes can break customer journeys even if the homepage appears faster.

Run controlled test orders and verify payment success, failure and cancellation states when relevant. Preserve actual customer records, and use an approved staging setup for risky changes. For technical performance considerations alongside checkout testing, see VYLINO’s WordPress speed optimisation guide.

11. Monitor availability, unexpected changes and alerts

Security monitoring should produce actionable notifications to a person who can respond. Depending on the website and hosting provider, monitor uptime, changes to administrator accounts, failed logins, unexpected plugin installations, malware or integrity warnings, backup failures and hosting errors.

Logging must balance usefulness and privacy. Avoid placing passwords, payment data or sensitive form content in ordinary logs. Define who reads alerts and where the records are kept; a dashboard full of warnings that nobody checks is not an incident response capability.

Some automated detection tools can produce false positives, while a clean scan cannot prove that a site is uncompromised. Confirm suspicious findings before destructive fixes, keep evidence and investigate root causes.

12. Prepare a WordPress incident-response plan

If the site is suspected of compromise, avoid making uncontrolled changes that destroy useful evidence. Contact the authorised administrator, host or incident specialist and agree how to protect customers and preserve records.

1. Identify: Record affected pages, unexpected redirects, account changes, reported symptoms and the time they were observed.
2. Escalate: Notify the named business decision-maker and responsible technical or hosting contact.
3. Contain: Restrict the affected service or account where appropriate, using a controlled process.
4. Preserve evidence: Keep relevant logs, screenshots and backup copies according to the response plan.
5. Investigate: Check vulnerable components, credentials, uploaded files and unexpected changes with suitable expertise.
6. Recover: Restore a verified clean state, patch the entry point and rotate compromised access credentials.
7. Verify: Test site content, login, forms, customer accounts, payments and monitoring before reopening affected workflows.
8. Improve: Record lessons, assign preventive actions and assess any applicable breach-notification duties.

Restoring an old backup alone may not be enough: if a vulnerable plugin or stolen password is still in place, the same incident can recur. An infection-removal quote should explain investigation, cleanup, remediation, testing and ongoing protection as distinct work.

13. How often should a small business review WordPress security?

There is no universal safe interval for every site. Emergency vulnerabilities need prompt attention, while routine audits can be scheduled. Use the following as an illustrative maintenance calendar adjusted to the actual site’s risk and resources.

For a high-transaction site, a once-a-month check may be far too infrequent for backup failures or urgent security alerts. Match monitoring and response expectations to the impact an outage or compromise would have.

14. Decide what a WordPress maintenance agreement actually covers

A contract offering “100% website security” is not a realistic substitute for defined work. Ask the provider to describe update scope, backup ownership, supported response windows, restoration assistance and what happens when a major vulnerability or compromise is identified.

Read VYLINO’s website maintenance services guide for further scope-planning questions. Clarify whether ordinary content updates, ecommerce support, emergency recovery and third-party licence fees are covered separately.

WordPress security launch and audit checklist

1. Confirm the business owns domain, DNS, hosting and recovery email access.
2. Identify all WordPress administrators and remove former or unknown accounts.
3. Review each user’s effective permissions and reduce unnecessary administrator roles.
4. Use unique strong passwords and enable MFA for key accounts where supported.
5. Inventory WordPress core, theme, plugins, custom code and licence owners.
6. Apply supported security updates using a controlled testing and rollback process.
7. Remove inactive and unused components after verifying dependencies.
8. Confirm HTTPS and secure hosting administration without relying on them as complete protection.
9. Review file permissions and configuration changes with the hosting architecture.
10. Test a consistent files-and-database backup restoration outside production.
11. Document acceptable recovery time and data-loss limits with the business.
12. Confirm forms collect minimal data and reach only authorised staff.
13. Validate supported file uploads, storage permissions and deletion procedures.
14. Check third-party credentials, CRM/analytics data sharing and old integrations.
15. Test carts, checkout, booking, logins and order notifications where applicable.
16. Set up useful security and availability monitoring with a named recipient.
17. Keep incident contacts, response steps and account recovery details accessible.
18. Document maintenance scope, support exclusions and final ownership handover.

Use representative test records, not genuine customer secrets, when assessing workflows. A checklist is complete only when responsible people can demonstrate the controls and understand the limitations.

Frequently asked questions

Can a security plugin make WordPress completely secure?

No. It may contribute useful monitoring or protections, but software maintenance, access control, hosting configuration, backup recovery and incident response are still required. No single plugin eliminates all risk.

Is WordPress safe for business websites and WooCommerce stores?

WordPress can support business and ecommerce sites when installed, configured and maintained appropriately. The required security measures depend on the site’s integrations, access roles, customer data and operational risk.

How often should I update WordPress plugins?

Review updates routinely and respond promptly to important security issues. Test compatibility where the change can affect checkout, forms or other critical functions, and keep recovery options available.

Are automatic WordPress updates a good idea?

They can reduce the delay in receiving fixes, but they need alert monitoring, backups and a plan for compatibility problems. Choose which plugins and themes use auto-updates based on their role and the host’s setup.

How often should a WordPress website be backed up?

Match backup frequency to how quickly valuable data changes and the maximum loss the business can accept. Verify file and database completeness, separate storage and real restoration rather than relying on the frequency alone.

Should every employee have administrator permissions?

No. Give people only the capabilities required for their jobs and review access after role changes. A content editor rarely needs permission to install plugins or modify system settings.

Does an SSL certificate prevent a WordPress website from being hacked?

No. HTTPS helps secure network traffic, but cannot fix a vulnerable plugin, exposed account credentials or unsafe application code.

What should I do if my WordPress site is hacked?

Follow a documented response process: involve the authorised owner and specialist, preserve useful evidence, contain the issue, fix its cause, restore a verified clean state and test critical functions. Assess any customer notification or legal obligations relevant to the incident.

Can a backup restore all WooCommerce orders after an incident?

Only the data preserved by the backup and other verified systems can be recovered. Older backups may miss recent orders or account changes. Plan a suitable recovery point and reconcile transaction records carefully.

Next steps: make WordPress security a named responsibility

Prepare the website URL, host and domain ownership details, a list of critical plugins, the real business workflows, the existing backup arrangement and any recent security or availability alerts. Ask the technical provider to produce a prioritised plan with responsible owners and measurable checks rather than a generic promise of complete protection.

Review VYLINO’s maintenance planning guide, WordPress performance guide and plugin selection checklist. To discuss website maintenance or security improvements, email contact@vylino.com with your website and a brief description of the issue. Any actual security audit must assess the specific installation rather than relying on generic article recommendations.