WordPress security is ongoing maintenance: know what is installed, control access and keep a recovery path that works. No plugin, hidden login address or certificate makes a site immune to compromise.
Protect recovery before changing the site
Keep backups of both the database and the files the site needs, including uploads. Choose a schedule based on how much new work you can afford to lose. A busy shop and a rarely edited brochure site have different recovery needs. Store a separate copy and periodically test restoration somewhere safe.
Maintain a small software inventory
- Use supported WordPress, PHP, themes and plugins.
- Remove unused components after checking dependencies and preserving rollback copies outside the public web directory.
- Keep the active theme and a maintained default recovery theme.
- Enable suitable automatic updates and review failures or compatibility notices.
WordPress’s hardening handbook explains the roles of updates, trusted software, access controls and file permissions. Apply server-specific rules with the hosting administrator; a copied permissions command can break a site.
Make account access deliberate
Give each person the role they need. Use unique passwords, protect recovery accounts and enroll privileged users in supported multi-factor authentication. Configure reasonable login-attempt limits and keep recovery methods available before enforcing a new login policy.
Changing the login URL can reduce some automated noise, but it is not a replacement for authentication controls. There is no justified universal percentage by which it makes a website safer.
Separate public content from executable code
Serve the site over HTTPS, restrict access to configuration and backup files, and prevent script execution in upload directories where the application does not require it. Disable dashboard code editing when it is unnecessary. Keep required publishing integrations working with narrowly assigned access.
Verify after maintenance
Open the homepage and an article, then use the menu, search, login and any business-critical forms. Check mobile layout, images and new errors. For speed changes, follow the separate performance checklist rather than enabling every cache option at once.
If a scan finds suspicious files or visitors report redirects, preserve evidence and investigate the cause. Removing one file or obtaining a clean scanner result does not by itself prove a complete recovery. Start with our website malware response guide.
Hosting protection and your WordPress responsibilities
MyLightHost’s shared-hosting page names CageFS and Imunify360 among its security features. Its security summary describes layered filtering, malware controls and restricted administrative access. Confirm the controls included with your actual plan rather than assuming identical protection on every hosting product.
Provider-side isolation and malware controls are useful layers, not proof that a website cannot be compromised. They do not replace supported plugins and themes, careful account permissions, secure recovery methods or maintaining your own usable recovery copy. An SSL certificate protects a connection; it does not establish that a site’s software or accounts are safe.
For suspected compromise, record the affected URL, symptoms and discovery time. Avoid repeatedly reinstalling or restoring over evidence. Open a Technical Support ticket from the affected service’s account and ask which checks or containment steps are appropriate. Share redacted evidence, never passwords or private keys.
Before restoring, establish a suitable recovery point and consider changes made since it. The website backup and restore guide explains questions to ask about included coverage and recovery scope. A clean scan or completed restore alone should not be presented as proof that every cause of an incident has been removed.
MyLightHost-specific section reviewed 14 September 2026 against the linked service and legal pages. No security tool or plan is represented as preventing every attack.