By Garrett Kohlrusch | GK Data LLC
A website can load quickly, look current, and still be difficult to maintain or recover. For a small business, website security starts with knowing who owns the domain, who can administer the site, what is being updated, and whether a clean restore is actually possible.
The practical goal is not to make a brochure site operate like a bank. It is to reduce avoidable risk, keep the business reachable, and make sure one expired account or failed plugin does not become a prolonged outage.
A small business website security checklist
1. Confirm ownership before changing technology
The business should control the domain registrar, DNS, hosting, WordPress administrator, analytics, Search Console, Google Business Profile, premium licenses, and recovery email addresses. Agency or former-employee accounts may assist, but they should not be the only path to critical assets.
2. Inventory WordPress, themes, plugins, PHP, and hosting
Record what is installed, why it exists, who maintains it, and whether it still receives security updates. Remove abandoned and unused components after confirming they are not required. More plugins are not automatically less secure, but every component adds code, configuration, and an update obligation.
3. Apply updates with a recovery plan
WordPress core, themes, plugins, PHP, and the hosting environment need routine maintenance. Test higher-risk changes when practical, take a current backup, and verify the public site, forms, checkout, and administration after deployment. WordPress’s own guidance recommends current software and recoverable backups.
4. Protect administrator access
Use unique accounts, password-manager-generated credentials, and MFA for administrators. Remove former staff and vendors, avoid routine work from a shared administrator account, and limit roles to the access each person needs. Review recovery addresses and hosting accounts too; protecting WordPress while leaving the registrar or mailbox weak solves the wrong problem.
5. Keep backups outside the website account
A backup stored only inside the same hosting account may disappear with the site. Keep protected copies in a separate system, define retention, monitor failures, and test a restore. The test should include both files and the database, plus any DNS, email, license, or integration details needed to return the business to service.
6. Monitor what customers experience
Monitor uptime, TLS certificate health, form delivery, unusual redirects, visible defacement, indexing changes, and security alerts from the host or application. A form that silently stops sending mail is an operational incident even if no attacker is involved.
7. Review forms and integrations
Contact forms, payment providers, analytics, marketing tags, maps, chat widgets, SMTP services, and embedded scheduling tools all handle data or add third-party code. Collect only what is needed, keep spam controls usable, document where submissions go, and remove integrations the business no longer uses.
8. Check headers, permissions, and exposed files
Use HTTPS consistently, appropriate security headers, restrictive file permissions, and a production configuration that does not expose debug output, backups, staging copies, directory listings, or credentials. These checks support a secure baseline but do not replace application testing.
Warning signs that need prompt investigation
- unexpected administrator accounts, plugins, scheduled tasks, or file changes;
- search results showing pages the business did not create;
- redirects that appear only on mobile, from search engines, or for first-time visitors;
- hosting notices, malware warnings, or sudden outbound email activity;
- forms no longer delivering, certificate errors, or unexplained traffic loss; and
- no one can identify the registrar, host, backup location, or account owner.
Maintenance review or penetration test?
A website operations review asks whether the site is owned, maintained, backed up, monitored, and supportable. It is the right starting point for an outdated WordPress site, ownership confusion, failed updates, unreliable forms, or an unclear recovery plan.
A penetration test asks how an authorized attacker can abuse the application’s code, roles, data, and workflows. It is more appropriate for custom applications, authenticated portals, APIs, sensitive integrations, or a site with meaningful user and business logic. Some environments need both, but they are different engagements with different evidence and deliverables.
For the platform baseline, review the official WordPress hardening guidance. For hands-on help, see Website Services and Small Business Website Security Management. Custom application concerns belong under Web Application and API Penetration Testing.
Request a website review with the domain, current concern, and any known ownership or hosting details. Do not send passwords or sensitive customer data through the form.