Small business websites are rarely attacked because someone chose them. They are attacked because automated tools scan the whole internet for outdated plugins, weak admin passwords and exposed services, and hit whatever they find. The good news is that the same automation means most attacks rely on a short list of basic weaknesses. This website security checklist covers those basics in the order that usually gives the most protection for the least effort. Work through it once, then revisit it every few months.
1. Accounts and access
Compromised logins are behind a large share of website incidents, so start here.
- Turn on two-factor authentication for the website admin panel, hosting control panel, domain registrar, DNS provider and any CDN account.
- Give every person their own login. Shared "admin" accounts make it impossible to see who did what or to remove one person's access.
- Apply least privilege. Content editors do not need administrator rights. Agencies and freelancers should get accounts that you can disable when the project ends.
- Use unique, long passwords stored in a password manager.
- Review accounts quarterly and remove anyone who has left.
- Lock down your domain. Enable registrar lock (transfer lock) and keep the registrar contact email on a mailbox you control. A WHOIS lookup confirms the registrar, lock status and expiry date.
2. HTTPS and certificates
- Serve the whole site over HTTPS and redirect all HTTP requests with a 301.
- Automate certificate renewal and monitor expiry independently.
- Check the certificate configuration: correct hostnames, complete chain, and only TLS 1.2 and 1.3 enabled. An SSL checker shows all three in one test.
- Fix mixed content so no images or scripts load over plain HTTP.
3. Software updates
Outdated software is the classic way in. Content management systems (CMS) like WordPress, Joomla and Drupal are safe when maintained; the risk is usually an abandoned plugin or theme.
- Update the CMS core, plugins and themes promptly, especially when an update is labelled as a security release.
- Remove unused plugins and themes. Deactivated code can still be exploitable if its files remain on the server.
- Prefer well-maintained extensions with recent updates and an active developer.
- Keep the server stack patched: operating system, web server, PHP or other runtime, and database. On managed hosting, confirm what the provider patches and what is your responsibility.
- Use supported versions. Running a PHP or database release that no longer receives security fixes leaves known holes permanently open.
4. Backups you have actually tested
- Back up files and databases automatically, at a frequency that matches how often content changes.
- Store copies off the server, ideally with a separate provider or account. Backups on the same server disappear along with it.
- Keep several versions, so you can restore from before an infection that went unnoticed for weeks.
- Test a restore at least twice a year. A backup you have never restored is a hope, not a plan.
5. Server and hosting hardening
- Close unnecessary ports. A typical web server only needs 80 and 443 open to the public. SSH (22), databases such as MySQL (3306) and remote desktop (3389) should be restricted to specific IP addresses or a VPN. Check from outside with a port checker.
- Use SSH keys instead of passwords for server logins, and disable direct root login.
- Replace FTP with SFTP. Plain FTP sends passwords unencrypted.
- Set sensible file permissions, so the web server cannot write to its own code except where uploads are needed.
- Hide version banners and disable directory listing.
- Consider a web application firewall (WAF), available from many CDNs and hosts, to filter common attack traffic.
6. Application-level protections
- Add HTTP security headers: HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and frame protection. Verify them with an HTTP header checker.
- Rate-limit login pages and use CAPTCHA or similar on public forms to slow down bots.
- Validate file uploads by type and size, and store them where they cannot be executed.
- Keep secrets out of public files. Configuration files,
.envfiles, backups and.gitfolders must never be downloadable from the web root. - For custom applications, review the code against the OWASP Top 10 before launch and after major changes.
7. Email and domain protection
Attackers often impersonate a business by email rather than hacking its website.
- Publish SPF, DKIM and DMARC records for your domain so receiving servers can reject forged mail. Start DMARC at
p=noneto monitor, then move toquarantineorreject. Check your records with the SPF, DKIM and DMARC checker. - Protect parked or unused domains with a DMARC reject policy and an SPF record of
v=spf1 -all. - Renew domains early and turn on auto-renew. An expired domain can be re-registered by someone else.
8. Monitoring and response
- Set up uptime monitoring with alerts that reach more than one person.
- Watch for unexpected changes: new admin users, modified core files, unfamiliar scheduled tasks.
- Keep logs for long enough to investigate an incident.
- Write down a short incident plan: who to call, how to take the site offline, where backups live and how to reset all credentials.
Key takeaways
- Most attacks on small business sites are automated and exploit basic gaps.
- Prioritize two-factor authentication, updates, tested off-site backups and closed ports.
- Add HTTPS done properly, security headers and email authentication for broader protection.
- Repeat the checklist every few months; security is maintenance, not a one-time project.