WordPress Security Checklist: How to Protect Your Website (2026)

A restaurant website can look perfectly healthy while an old contractor account, an abandoned plugin, or a stolen password leaves the back door open. The menu loads. Orders arrive. Nobody notices the problem until customers report strange redirects—or checkout stops working during the dinner rush.

Good WordPress security isn’t about installing the most intimidating dashboard. It’s about reducing unnecessary access, keeping software maintained, and making sure you can recover when something goes wrong. This 2026 checklist follows that order, with extra attention to WooCommerce stores and restaurant ordering websites where downtime has immediate consequences.

Start Here: Check Your WordPress Site’s Security Basics

Most everyday WordPress risks fall into a few understandable categories: someone gets valid login credentials, vulnerable software lets them bypass normal controls, or a configuration exposes something private. Another common problem is discovering that the backup you were counting on doesn’t actually restore.

Start with an inventory rather than a settings spree. You need to know what exists before deciding what to lock down.

• Hosting and ownership: Record your hosting provider, domain registrar, account owners, renewal contacts, and recovery methods. Confirm that the business—not a former developer—controls these accounts.
• Administrator accounts: Open Users → All Users and identify everyone with Administrator access. On a multisite installation, review Super Admin access too.
• Installed software: List your WordPress version, active and inactive plugins, themes, and any custom integrations. Include must-use plugins supplied by your host or developer.
• HTTPS: Check the homepage, login screen, menu, cart, and checkout. Confirm that HTTP redirects to HTTPS and that the browser reports no certificate or mixed-content warnings.
• Recovery: Find your latest database and file backups, where they’re stored, and who can restore them.

WordPress’s official hardening guidance treats security as layers of protection, not one magic setting. That’s the right mindset: HTTPS protects information in transit, but it doesn’t repair a vulnerable plugin or prevent an authorized account from exporting customer data.

Also separate prevention from incident response. Unexpected administrators, unauthorized payment-setting changes, or injected advertising may indicate an existing compromise. Don’t assume completing this checklist will remove an attacker. Preserve evidence and involve your host or a qualified incident-response specialist before treating the site as clean.

Protect Your Login with Strong Passwords, Two-Factor Authentication, and User Roles

Your administrator account can install executable code and change almost everything on a standard WordPress site. Treat it more like a master key than an ordinary staff login.

Secure the accounts that control everything else

Give every administrator a unique, randomly generated password stored in a password manager. Don’t reuse the password for your email, hosting panel, or domain registrar. Those accounts need their own strong passwords and two-factor authentication too; someone who controls your recovery email may be able to reset other credentials.

Enable two-factor authentication for privileged WordPress users. An authenticator app adds a second requirement beyond the password, although manually entered codes can still be phished. Where your authentication setup supports security keys or passkeys, those can provide phishing-resistant protection.

Store recovery codes somewhere protected and separate from the device generating your codes. Then test recovery before an owner loses their phone on a Saturday night. Security that locks out the legitimate operator during service needs a better recovery plan.

Give each person only the access their work requires

Use individual accounts, not one shared “restaurantadmin” login. Separate accounts make it easier to revoke access and understand who changed a setting.

A restaurant owner might retain an Administrator account for maintenance while using a less-privileged account for routine work. Order-management staff generally need access to orders and fulfillment information—not plugin installation, user management, or payment credentials.

WooCommerce’s Shop Manager role is useful, but it grants substantial store-management permissions. Don’t assume it’s a narrowly restricted kitchen role. If employees only need tickets and order-status controls, use an appropriately restricted interface or a carefully configured custom role, then test what that user can actually see.

Developers should receive named accounts with the permissions their assignment requires. Set an access-removal date, use staging when possible, and revoke unused hosting, SFTP, and WordPress application-password access when the work ends.

Investigate unfamiliar users before deleting them; you may need to preserve evidence or reassign legitimate content. Changing the login URL can reduce some automated noise, but it isn’t a substitute for strong authentication. Bots don’t need to politely enter through the front door.

[IMAGE: WordPress account-access checklist showing separate roles for restaurant owner, order-management employee, and developer, with two-factor authentication and access-expiry reminders]

Close Security Gaps in Plugins, Themes, and Hosting

Every plugin adds code that needs ongoing maintenance. That doesn’t mean “fewer plugins” automatically equals “secure,” but unnecessary software creates unnecessary work and potential exposure.

Obtain plugins and themes from the official WordPress directory or the legitimate developer’s distribution channel. Avoid “nulled” premium downloads. Besides licensing problems, you have no reliable reason to trust what someone has added to that package.

Remove unused plugins rather than simply deactivating them. Inactive files remain on the server, and some vulnerabilities involve directly accessible files. Delete unnecessary themes too, while retaining a maintained fallback theme if that’s part of your recovery procedure.

Check maintenance, not just installation counts

Review release history, compatibility notes, support activity, and known vulnerability notices. An old release date alone doesn’t prove software is unsafe, but abandoned software handling checkout or customer data deserves particular scrutiny. Keep premium licenses current where they’re needed to receive security updates.

Ask your host which PHP version the site runs and whether that branch still receives security fixes. A version can meet an application’s minimum requirement while no longer receiving upstream security support. Confirm compatibility before moving to a supported branch.

Apply security updates promptly, especially fixes for vulnerabilities being actively exploited. Use WPSlash’s staging tutorial resources and WordPress backup guides to prepare your workflow rather than improvising on the live store. Don’t let an elaborate testing process become an excuse to leave a critical vulnerability exposed; ask your host about temporary mitigation if an immediate update isn’t possible.

For routine updates, test a representative order on staging: choose modifiers, enter a delivery address, select pickup or delivery, apply a coupon, and complete a sandbox payment. Verify the resulting order, stock changes, and notifications.

Keep staging disconnected from live customer emails, production kitchen printers, and fulfillment services unless you’ve deliberately arranged a controlled test. After deployment, check live checkout and payment callbacks as well. A successful update screen only tells you that files were updated—not that dinner will reach the kitchen.

Configure a Security Plugin, Firewall, and Login Protection

A security plugin can bring several controls into one place, but it still needs configuration and somebody reading its alerts. One primary security suite is usually easier to manage than several overlapping tools competing to block logins and scan files.

For a concrete configuration example, Wordfence Security provides a WordPress endpoint firewall, malware scanning, login-security controls, and two-factor authentication. Its free edition includes core firewall and scanning functionality; Premium provides real-time firewall-rule and malware-signature updates that ordinarily reach free users after a 30-day delay. Plan details can change, so verify the edition installed before relying on a particular feature.

Configure a small set of useful controls

1. Check firewall status. In Wordfence, review the firewall dashboard and its protection mode. Extended protection loads the firewall before WordPress, but server configuration changes may be involved. Follow the displayed precautions and keep a recovery path available.
2. Enable privileged-user 2FA. Enroll administrators, save recovery codes, and test the login flow before enforcing it across the team.
3. Configure login throttling. Limit repeated failures without making ordinary password mistakes a service outage. For a small staff site, a starting policy might block after 10 failures within five minutes for 15 minutes; adjust it to your traffic and available settings.
4. Run a baseline scan. Investigate modified core files, unexpected executable files, and vulnerability warnings. A reported change isn’t automatically malware, and a clean scan isn’t proof that no compromise exists.
5. Route actionable alerts. Send critical findings to a monitored address, with a named person responsible for responding. Review successful privileged logins and configuration changes through suitable logging where available.

The firewall’s location matters. A WordPress-level firewall inspects requests within your hosting environment. An upstream hosting or CDN firewall may reject traffic before it reaches PHP, depending on its architecture. These layers can complement each other, but neither replaces application updates.

Test the rules from a logged-out phone using mobile data. Browse the menu, submit a normal login, place a guest order, and verify payment notifications and integrations. Shared restaurant Wi-Fi can put many people behind one public IP address, so aggressive IP limits may block innocent users together.

If something breaks, inspect the blocked request and create the narrowest justified exception. Don’t disable the firewall globally or allow every request to checkout simply to make an error disappear.

[IMAGE: Diagram of restaurant website security layers showing an upstream firewall, WordPress login protection, WooCommerce checkout, and verified payment callbacks, with legitimate customer traffic passing through]

Secure WooCommerce Checkout and Limit Access to Customer Data

Checkout security covers more than card entry. Customer names, telephone numbers, addresses, delivery notes, and order histories all deserve protection. A delivery instruction containing an entry code is particularly sensitive—even if nobody considers it “payment data.”

Verify the entire payment journey

Use HTTPS throughout the website, not only on checkout. Check certificate validity, HTTP redirects, insecure embedded resources, and generated links in emails. Behind a reverse proxy or CDN, ask your host to confirm that WordPress correctly recognizes secure requests and that the origin connection is appropriately protected.

Use your payment provider’s maintained WooCommerce integration and its supported hosted or tokenized payment flow. Keep raw card numbers and card security codes out of WordPress forms, order notes, emails, and troubleshooting logs. Never ask a customer to send their card details to “finish the order manually.”

HTTPS and a security plugin do not establish PCI DSS compliance. Your responsibilities depend on the payment architecture and your merchant arrangements; outsourced payment handling can reduce scope, but it doesn’t erase every obligation. Consult your payment provider or acquiring bank and the PCI Security Standards Council’s official documentation for the applicable validation requirements.

You don’t need to repeat your entire gateway setup to check it. Use WPSlash’s Stripe setup resources for configuration background, then test successful, declined, and additional-authentication payments using the provider’s supported test methods.

Protect secrets and operational integrations

Treat WooCommerce API keys and webhook signing secrets like passwords. Give each integration separate credentials with the least required access, keep secrets out of screenshots and source repositories, and revoke unused keys. Use provider-supported webhook-signature verification; an order number in an incoming request is not proof that payment occurred.

For restaurant ordering, FoodMaster’s WooCommerce restaurant ordering system connects delivery, pickup, and dine-in ordering with POS, kitchen display, QR table ordering, and automatic printing capabilities. That makes the operational security checklist broader than checkout alone: review the accounts, devices, and credentials involved in each workflow you enable.

Test guest checkout, asynchronous payment callbacks, order-status changes, kitchen delivery, and printing. Where supported, test webhook retries to verify that a repeated notification doesn’t trigger duplicate fulfillment. Never make private order data public to fix an integration issue.

Finally, restrict order exports and customer-data access. Avoid shared downloads folders on counter computers, lock kitchen devices, and remove temporary exports when their purpose is complete. Set retention periods around genuine operational and legal needs, rather than keeping every delivery instruction forever.

Build a Simple Security Routine and Know When to Get Help

The best security routine is one someone actually owns. Assign a primary person and a backup, record where alerts arrive, and keep emergency hosting contacts outside WordPress. If the site is unavailable, your recovery instructions shouldn’t be trapped inside it.

Prioritize immediate, weekly, and monthly work

• Immediately: Secure administrator, email, hosting, and registrar accounts; enable 2FA where available; address critical vulnerable software; verify HTTPS; and confirm that recoverable backups exist outside the production server.
• Weekly: Review security updates and vulnerability alerts, investigate unfamiliar privileged activity, check scan results, and confirm backup jobs completed. Also look for unexplained changes to payment settings, order behavior, or integration credentials.
• Monthly: Review users and permissions, remove obsolete software and integrations, check PHP and hosting support status, and run a checkout test. Test restoration on an isolated environment on a schedule matched to the business’s risk.
• Whenever staff or suppliers change: Revoke unnecessary access promptly. Don’t wait for the next monthly review to remove a departing contractor’s administrator account.

Choose backup frequency around how many orders you can afford to lose. A nightly database backup may leave a busy restaurant with many hours of missing transactions. Files and databases both matter, and backup copies need their own access controls because they can contain customer records and secrets.

Use WPSlash’s backup restoration tutorial resources to rehearse recovery. For WooCommerce, restoring an older database can remove newer orders while the associated payments still exist at the provider. Plan reconciliation before replacing production data.

If you suspect a compromise, change priorities

Contact your host promptly and describe what you observed, including timestamps and affected pages. Preserve relevant access logs, security alerts, suspicious account details, and snapshots where available. Don’t publish logs containing customer information or secrets.

Restrict access or pause affected checkout functionality if customers or payment details may be at risk. Coordinate containment with your host so that you don’t destroy useful evidence or accidentally leave another entry point open.

From a trusted device, revoke exposed access and rotate affected passwords, API keys, and webhook secrets. Cleanup may require another credential rotation afterward if an attacker retained access during the first one. A specialist should identify the entry point, remove persistence, and help verify recovery—not merely delete the first suspicious file.

If personal data may have been exposed, seek appropriate legal or privacy advice about notification duties. Then turn the findings into changes to your routine. A protected WordPress site isn’t one that never needs attention; it’s one where access is controlled, warning signs reach a human, and recovery has been practiced before the orders stop.