WordPress Security Guide for Beginners

The short answer: protect administrator accounts with unique passwords and multi-factor authentication (2FA), update WordPress, plugins and themes, enable HTTPS, back up both the database and website files to an independent location, remove unused software and check regularly for suspicious activity. No configuration eliminates risk completely; the practical goal is to reduce the likelihood of compromise and make it possible to restore the website after an incident.

The process below is intended for an active or newly installed WordPress website. You need WordPress administrator access, hosting access and an independent location for storing backups. If you use managed hosting, you can skip the VPS section; if you manage the server yourself, read the server-check section before changing its configuration.

1. Review and Restrict Administrator Account Access

Administrator accounts can change content, install plugins, edit themes and create users. They are therefore the first area to protect before adding security tools.

In WordPress, go to Users → All Users and review every account, its role, recovery email address and most recent activity, if the system or a plugin displays that information.
Delete accounts that are no longer needed or reduce their roles to the appropriate level. Before deleting an author account, select the correct user to receive that account’s posts if WordPress prompts you to do so.
Create a separate account for each person; do not share an administrator account. This makes it easier to revoke access and trace changes.
Use a long, random and unique password for WordPress. Do not reuse your email, hosting or payment-service password.
Do not set the new username to admin or use an easily guessed name. Changing the username does not replace a strong password and 2FA.

Store the password in a password manager. If the website processes payments or customer data, also secure the hosting account, administrative email, domain registrar and DNS provider; securing WordPress alone is not enough.

2. Enable 2FA and Prepare a Recovery Method

Multi-factor authentication (MFA/2FA) requires an additional factor beyond a password, such as a code from an authenticator app or a security key. WordPress core does not provide one standard 2FA screen for every website, so you will generally need a plugin from a clearly identified publisher or a feature provided by your login provider (according to WordPress.org).

Choose a 2FA plugin from a clearly identified publisher that is actively maintained and compatible with your current WordPress version.
In WordPress, open Plugins → Add New Plugin, then check the publisher’s name, update history and compatibility before installing it.
Enable 2FA for your administrator account first, then log out and back in to test it.
Store the recovery codes in a secure location separate from the website, and do not keep them on only one device.
After testing successfully, require other accounts with elevated privileges to enable 2FA.

If you are locked out: use a recovery code or the plugin’s support process. Do not delete plugin files from the server based on guesswork; if you must intervene through the hosting panel, create a backup and record the changes first.

3. Update Software in a Reversible Way

Older versions may contain publicly disclosed vulnerabilities. WordPress recommends using the latest official version suitable for your website; older branches do not have a fixed security-support period (according to WordPress.org).

Go to Dashboard → Updates and record the WordPress core, plugins and themes scheduled for update.
Create and verify a backup before updating, especially when updating plugins that handle payments, forms, caching or important data.
Update small groups at a time rather than updating everything in bulk. After each group, check the website before continuing.
Open the homepage, a post, the contact form, the login page, the Media Library and the payment area, if applicable.
Go to Tools → Site Health to review critical warnings and configuration errors.

Remove unused plugins or themes and replace software that is no longer maintained; do not leave them installed indefinitely in a deactivated state. You can consult the plugin review process before updating and apply it in a staging environment.

If a white screen or 500 error appears: record the component that was updated, check the hosting error log, disable that component using an appropriate method if you still have access, and restore a verified backup if you cannot yet determine the cause. Do not continue with bulk updates while the website is experiencing errors.

4. Enable HTTPS and check every URL

HTTPS encrypts the connection between the browser and the server, helping protect login credentials and session cookies. HTTPS does not patch plugin vulnerabilities or prevent every attack, but it is a foundational layer for the administration area (according to WordPress.org).

In your hosting control panel, confirm that a valid TLS certificate is installed for the correct domain. If the website uses both www and a domain without www, check which name is actually configured.
In WordPress, go to Settings → General and check that WordPress Address (URL) and Site Address (URL) both use https://.
Open a private browsing window and visit https://tenmiencuaban.com/wp-admin/. Replace tenmiencuaban.com with your actual domain name.
Check that the browser reports no certificate errors, insecure-connection warnings, or mixed content.
Log in, open the post editor, and load the Media Library. If a redirect loop occurs, stop making further changes and contact your hosting provider.

Do not edit URLs directly in the database unless you have a backup and understand how to restore it. If the website runs on a VPS, refer to the guide to running WordPress over HTTPS to keep the certificate, web server, and WordPress configuration steps separate.

5. Set up restorable backups

Backups do not prevent attacks; they provide a recovery option. A backup is useful only when it contains the right data, is stored outside the primary website, and has been tested through a restore. WordPress recommends backing up both the website database and its files (according to WordPress.org).

Database: posts, pages, user accounts, settings, and data from many plugins.
Website files: themes, plugins, uploaded media, and required configuration files.
Independent location: at least one copy outside the primary hosting environment, protected by a separate account and strong authentication.

Choose a backup schedule based on the amount of data loss you can accept. For example, if you cannot afford to lose more than one day of content, the backup schedule must be frequent enough to meet that requirement; this is not a mandatory frequency for every website.

Initial test: download a copy to your computer, record its creation date, and restore it on a staging environment or an isolated temporary website. Check logins, posts, images, forms, and important functions. Do not attempt to restore directly to the live website unless you have a fallback backup.

6. Reduce the attack surface and check the server layer when you manage it yourself

Every unnecessary plugin, theme, account, and service increases the number of points that must be protected. Prioritize changes that are easy to verify:

Remove unused plugins, themes, and accounts; install software only from WordPress.org or a trusted publisher.
Apply the principle of least privilege: content authors do not need administrative privileges.
Do not block all /wp-admin/, xmlrpc.php or other endpoints without first checking the impact on mobile apps, plugins, WooCommerce, Jetpack, and integrated services.
If you are instructed to modify wp-config.php or server configuration, back up the file, record the line you changed, and prepare a way to undo the change.

Checklist for VPS or self-managed servers

Perform this section only if you have server administration or SSH access. If you use managed hosting, ask the provider to confirm the corresponding items instead of changing them yourself.

DNS: check that the domain records point to the correct server; review both the A and AAAA records if IPv6 is enabled, to prevent one access path from pointing to the wrong server.
Firewall: open only the ports and services that are required; ensure that you still have a valid administration path before closing a port or restricting IP addresses.
Web server: confirm that the web server is serving the correct website directory, intentionally redirecting HTTP to HTTPS, and not exposing backup or configuration files.
Database: the WordPress account should have only the permissions it needs on the correct database; do not expose the database port to the Internet if the application does not require it.
PHP/PHP-FPM: use a PHP version that remains compatible with your WordPress version, plugins, and themes; check which extensions the website actually requires before disabling any.
PHP limits: check upload_max_filesize, post_max_size, memory_limit and max_execution_time in php.ini or the PHP-FPM configuration when you encounter file-upload failures, out-of-memory errors, or execution timeouts. Do not increase these limits arbitrarily; after making changes, reload or restart the service according to the provider’s instructions, then retry the relevant function.
OPcache: if PHP uses OPcache, after changing code or configuration, confirm that the cache has been reloaded through the appropriate server-administration procedure; do not disable OPcache merely because an undiagnosed error has occurred.
WordPress and file permissions: check wp-config.php, the uploads directory, and core files to ensure they cannot be modified arbitrarily by accounts that do not need such access. Do not apply a file-permission template found online without first understanding which user runs the web server.

After any change to DNS, the firewall, the web server, PHP-FPM, or HTTPS, check the homepage, administrator login, Media uploads, forms, and error logs. If you cannot determine which service is running or how to reload it safely, stop making changes and ask your hosting provider for assistance; a security configuration that takes the website offline is not a good outcome.

7. Monitor for and respond to unusual activity

Security does not end after you enable 2FA. Check the following weekly or at an appropriate frequency:

Users → All Users: unfamiliar accounts, elevated roles, or unusual recovery email addresses.
Dashboard → Updates: security updates and outdated software.
Tools → Site Health: new critical issues; the official documentation explains the categories of checks on this screen (according to WordPress.org).
Notifications from your hosting provider, CDN/WAF, and monitoring tools: unusual login attempts, modified files, or sudden traffic spikes.
Public website: unexpected redirects, advertisements from unknown sources, altered content, or browser warnings.

If you suspect that the website has been compromised: record when you detected the issue and its symptoms; use a clean device to change the passwords for WordPress, hosting, email, and related services; revoke unfamiliar accounts; contact your hosting provider; and retain logs and a snapshot of the current state if possible. Do not simply install another plugin and continue operating the website. After determining the scope, consider restoring from a backup created before the incident and replacing all related credentials. If the website processes customer data, payments, or sensitive information, meet the notification and response obligations required by the regulations applicable to your organization.

Priority order if you have only one session

Create and verify a backup.
Change the administrator-account password and enable 2FA.
Remove unnecessary accounts, plugins, and themes.
Update WordPress, plugins, and themes in small batches.
Enable HTTPS and check all administrator-area URLs.
Check Site Health, hosting logs, and the user list.
Record your hosting provider’s contact details, review schedule, and recovery procedure.

Completion checklist

No unfamiliar administrator accounts or software from unknown sources remain.
Administrator accounts use unique passwords and have 2FA enabled.
WordPress, plugins, and themes are updated in a controlled manner.
The website and the /wp-admin/ area operate over HTTPS.
Backups of the database and files are stored in an independent location.
A restore has been tested in an isolated environment, or a specific recovery procedure is in place.
You have checked the DNS, firewall, web-server, PHP, and file-permission layers if you manage your own VPS.
You know whom to contact and what to do if you discover an unfamiliar account, an unexpected redirect, or loss of access.

This is a security foundation, not a certification that the website is absolutely secure. For beginners, prioritize access control, updates, backups, and recoverability before turning to advanced server configurations.

WordPress Security for Beginners: Protect Accounts, Data, and Access