A complete website security checklist covering HTTPS, security headers, CMS hardening, password policies, Web Application Firewall setup, regular backups, and continuous monitoring. Protect your site and your visitors' data in 2026.
Check your website's security health free — results in ~30 seconds:
HTTPS is the foundation of website security. It encrypts all traffic between your server and visitors, preventing eavesdropping and data tampering. Without it, passwords, form submissions, and personal data travel in plain text.
Every website must use HTTPS with a valid SSL/TLS certificate. In 2026, free certificates from Let's Encrypt are automatically provisioned by most hosting platforms (Cloudflare, Netlify, Vercel, most shared hosts). If your certificate is expired or misconfigured, visitors see a security warning and most will leave immediately. Verify your certificate is valid, covers your domain and www subdomain, and auto-renews before expiration.
Check: PageGuard's security scan verifies your SSL certificate validity and expiration date.
All HTTP requests should automatically redirect to HTTPS. Without this redirect, visitors who type your URL without "https://" or follow an old HTTP link may inadvertently use an unencrypted connection. Configure a 301 permanent redirect from http:// to https:// at the server or hosting level (not in JavaScript). This protects all pages, not just those with forms.
HSTS tells browsers to always use HTTPS for your domain, even if a visitor types "http://" or clicks an HTTP link. Add the header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. This eliminates "SSL stripping" attacks where attackers downgrade HTTPS to HTTP. After verifying HTTPS works correctly, submit your domain to the HSTS preload list (hstspreload.org) so browsers know before the first visit.
SSL 3.0, TLS 1.0, and TLS 1.1 have known vulnerabilities and are deprecated. Configure your server to use TLS 1.2 or TLS 1.3 only. TLS 1.3 is faster and more secure. Most modern hosting platforms handle this automatically, but if you manage your own server, verify the TLS configuration with tools like SSL Labs' SSL Test (ssllabs.com/ssltest/).
HTTP security headers instruct browsers on how to behave when handling your site's content. They're free to implement and prevent entire categories of attacks including XSS, clickjacking, and MIME-type attacks.
CSP is the most powerful security header — it defines which sources browsers may load scripts, styles, images, and other resources from. A properly configured CSP prevents XSS attacks by blocking unauthorized script execution. Start with Content-Security-Policy-Report-Only to audit without breaking things, then enforce it. Example: default-src 'self'; script-src 'self' https://cdn.example.com;
Check: PageGuard's Best Practices audit checks for the presence of a CSP header.
Prevents your pages from being embedded in iframes on other domains — the basis of clickjacking attacks where attackers overlay invisible buttons over your page to trick users into unintended actions. Use X-Frame-Options: SAMEORIGIN or the modern CSP equivalent frame-ancestors 'self'. If you use the CSP directive, you can omit the X-Frame-Options header.
Prevents browsers from MIME-sniffing a response away from the declared content type. Without this header, browsers may execute uploaded files (like images) as scripts if they contain JavaScript. Add X-Content-Type-Options: nosniff to all responses. This is a quick one-line fix with high security value.
Controls how much referrer information is included when navigating from your site to other sites. Without this header, the full URL (including query parameters that may contain user data) is sent to third parties. Recommended: Referrer-Policy: strict-origin-when-cross-origin — sends the full URL for same-origin requests but only the origin for cross-origin requests, and nothing for downgrades from HTTPS to HTTP.
Restricts which browser APIs and features embedded iframes and your own code can use. For example, disable camera, microphone, geolocation, and payment APIs unless your site explicitly needs them: Permissions-Policy: camera=(), microphone=(), geolocation=(). This limits the potential damage if an attacker injects a malicious script.
Outdated CMS software, plugins, and themes are the #1 cause of website hacks. Every unpatched vulnerability is a door hackers can walk through. Keeping software updated is the single highest-impact security action for most sites.
For WordPress, Drupal, Joomla, and similar CMS platforms: enable automatic minor security updates and manually update major versions within 2 weeks of release. The time between a vulnerability being disclosed and attackers exploiting it is often measured in hours. WPScan maintains a database of WordPress vulnerabilities — check it regularly. For Drupal, security advisories are released every Wednesday.
Every installed plugin — even inactive ones — is potential attack surface. Deactivated plugins still have their files on your server and can be exploited. Quarterly: review all installed plugins, remove any that are (1) no longer used, (2) abandoned by their developers (no updates in 12+ months), (3) have low ratings or suspicious reviews, or (4) request excessive permissions. Fewer plugins = smaller attack surface.
WordPress's default admin URL is /wp-admin — every bot and scanner knows this. Move it to a custom URL using a plugin like WPS Hide Login. For WordPress, also disable user enumeration: block /?author=1 requests that expose your admin username, which attackers then brute-force with targeted password attacks. For other CMS platforms, review their security hardening guides for equivalent steps.
Web server files should have the minimum permissions necessary. Directories: 755 (rwxr-xr-x). Files: 644 (rw-r--r--). Configuration files like wp-config.php: 600 (rw-------). World-writable files (777) are a critical security risk — any script running on the server can modify them. Audit file permissions quarterly, especially after installing plugins or themes that may change them.
Weak authentication is the second most common cause of breaches. Strong password policies, multi-factor authentication, and proper access control limit the damage of any single compromised credential.
MFA requires a second factor (authenticator app, SMS, hardware key) in addition to a password. Even if an attacker obtains your password through phishing or a data breach, they cannot log in without the second factor. Enable MFA for: CMS admin accounts, hosting control panel, domain registrar, DNS provider, and any third-party service with access to your site. Use an authenticator app (Google Authenticator, Authy) rather than SMS — SMS is vulnerable to SIM swapping attacks.
Require passwords of at least 12 characters with a mix of uppercase, lowercase, numbers, and symbols. Better: require passwords from a password manager (randomly generated, unique per service). Implement login rate limiting — lock accounts or require CAPTCHA after 5–10 failed attempts. This stops brute-force attacks. For WordPress, plugins like Limit Login Attempts Reloaded add this protection.
Give each user account only the permissions they need — nothing more. A content editor doesn't need admin access. A contractor building a landing page doesn't need database credentials. Create separate accounts for different roles and revoke access immediately when someone leaves your organization. Audit user accounts quarterly and remove any that are unused or belong to former employees.
Session tokens should be: long and randomly generated (at least 128 bits of entropy), invalidated on logout, expired after a reasonable idle time (e.g., 30 minutes for admin areas), transmitted only over HTTPS, set with Secure, HttpOnly, and SameSite=Strict cookie flags. The Secure flag prevents transmission over HTTP. HttpOnly prevents JavaScript access (preventing XSS token theft). SameSite=Strict prevents CSRF attacks.
Every input field — contact forms, search boxes, URL parameters, file uploads — is a potential attack vector. Proper validation and sanitization at both the client and server side is essential.
SQL injection occurs when user input is concatenated directly into SQL queries. An attacker can input '; DROP TABLE users; -- and destroy your database. Parameterized queries (prepared statements) treat user input as data — never as executable SQL. This is the single most important defense against SQL injection. Every database interaction that includes user-supplied data must use parameterized queries or an ORM that handles this automatically.
Validate input on the server side — never trust client-side validation alone. Validate type (string, number, email), format (regex for emails, URLs), length limits, and allowed characters. For HTML fields (rich text editors), use a well-maintained HTML sanitization library (DOMPurify for JavaScript, bleach for Python) to strip dangerous tags while preserving safe formatting. Never render raw user input as HTML.
If your site accepts file uploads: whitelist allowed MIME types (e.g., image/jpeg, image/png — not application/php), validate both the MIME type and the file extension, store uploaded files outside the web root or on a separate CDN with no execute permission, rename files to random names (eliminating predictable paths), and scan uploads for malware using antivirus APIs. Uploaded files with PHP, Python, or other executable extensions that reach the web server are a critical vulnerability.
A WAF sits between your website and the internet, filtering malicious traffic before it reaches your server. It blocks common attack patterns including SQL injection, XSS, and DDoS at scale, without you needing to handle each pattern individually in your code.
Cloudflare's free plan includes a WAF with managed rules covering the OWASP Top 10. Simply add your domain to Cloudflare and update your DNS nameservers — all traffic passes through Cloudflare's network, which blocks known attack signatures before they reach your server. Cloudflare's network also absorbs DDoS attacks at scale. For small businesses, Cloudflare Free provides enterprise-grade WAF protection at zero cost.
Bots account for over 40% of web traffic, and malicious bots attempt credential stuffing, scraping, and vulnerability scanning 24/7. Enable bot protection at the CDN/WAF layer to block clearly malicious bots while allowing legitimate crawlers (Googlebot, Bingbot). Add rate limiting to login endpoints, contact forms, and APIs — limit requests per IP to reasonable thresholds (e.g., 10 login attempts per minute).
Certain files should never be publicly accessible: .env files (contain API keys and database credentials), .git directories (expose your entire codebase history), wp-config.php, composer.json, package.json with dependencies, and server configuration files. Configure your web server or CDN to return 403 Forbidden for these paths. Cloudflare WAF rules can block access to /.env, /.git/, and common sensitive paths.
Even with perfect security, breaches happen. Regular backups are your last line of defense — they let you restore your site quickly without paying ransomware or starting from scratch. The 3-2-1 rule: 3 copies, 2 different storage types, 1 offsite.
Manual backups get forgotten. Automate daily backups of both your database (all user data, content, settings) and your file system (CMS files, uploads, themes, plugins). Most hosting providers offer built-in backup tools — verify they're enabled and running. For WordPress, plugins like UpdraftPlus or BackupBuddy automate this. Store backups with at least 30 days of history to recover from slow-developing incidents.
Backups stored on the same server as your website are useless if the server is compromised, deleted, or the hosting provider has an outage. Store backups in a separate location: Amazon S3, Google Cloud Storage, Backblaze B2, or even Google Drive. Most backup plugins support remote storage destinations. Test that you can actually download and restore from these offsite backups — don't discover they're corrupted during a crisis.
A backup you've never tested is potentially useless. Quarterly: do a practice restore to a staging environment. Verify the database restores correctly, all files are present, and the site functions as expected. Time how long a full restore takes — this tells you your actual Recovery Time Objective (RTO) in a real incident. Untested backups have a significant failure rate during actual recovery scenarios.
You can't respond to a breach you don't know about. Continuous monitoring detects attacks in progress, unauthorized access, and anomalous behavior — reducing the time attackers spend in your system before discovery (the "dwell time").
Google Search Console alerts you to security issues detected by Googlebot: malware, hacked content, phishing pages, harmful downloads. These warnings appear in the Security Issues report. Enable email notifications in Search Console so you're alerted immediately. Respond to security issues within 24 hours — Google will suppress your rankings until the issue is resolved and you've submitted a review request.
Next step: PageGuard vs Google Search Console — compare their complementary monitoring capabilities.
DDoS attacks, server compromises, and malware injections often cause downtime. Uptime monitoring services (PageGuard, UptimeRobot, Pingdom) check your site every few minutes and alert you immediately when it goes down. Rapid detection lets you respond within minutes rather than discovering a 6-hour outage through a customer complaint. Configure alerts to your phone via SMS or push notification for critical downtime.
Related: PageGuard automated website monitoring — monitor security, SEO, and performance from a single dashboard.
Server access logs record every request to your site. Application logs capture errors and unusual behavior. Review logs weekly for: failed login attempts (bursts indicate brute force), 404 spikes (scanners probing for vulnerabilities), unusual request patterns (scanning for admin panels, configuration files), and unexpected geographic traffic spikes. Many hosting control panels provide log viewers. For WordPress, security plugins like Wordfence log suspicious activity in an accessible dashboard.
Data protection is both a security practice and a legal requirement. GDPR, CCPA, and other privacy regulations require you to collect only what you need, protect what you collect, and notify users of breaches. Non-compliance carries significant fines.
Passwords must never be stored in plain text — use bcrypt, scrypt, or Argon2 hashing with a unique salt per password. For other sensitive data (payment tokens, SSNs, API keys): encrypt using AES-256 before storing in the database. Encryption keys should be stored separately from the encrypted data (in environment variables or a secrets manager, not in the database or version control). If your database is stolen, encrypted data is useless without the keys.
Every piece of data you collect is a liability — you have to protect it, and it can be stolen. Audit your data collection: does your contact form need a phone number? Does your analytics need precise location? Does your store need to store full credit card numbers (use Stripe/payment processors that handle PCI compliance instead)? Minimize collection to what's strictly necessary for your service. Less data = less risk = simpler GDPR compliance.
API keys, database passwords, OAuth secrets, and other credentials must never be in your source code or version control. Use environment variables (set in your hosting platform's settings) or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Cloudflare Workers Secrets). Accidentally committing a secret to a public GitHub repository can result in exploitation within minutes — GitHub scanners and bots monitor for exposed credentials 24/7.
Regular vulnerability scans proactively identify security weaknesses before attackers do. Automated scanners can identify misconfigured headers, outdated software versions, exposed sensitive files, and insecure SSL configurations in minutes.
Security header scanners (SecurityHeaders.com, Mozilla Observatory) analyze your HTTP response headers and flag missing or misconfigured headers. Scan monthly and after any major configuration changes. PageGuard's Best Practices audit checks for critical security headers as part of the overall website health score — run a free scan to see your current security header configuration.
Check your headers free: Run a PageGuard security scan to see your Best Practices score.
SSL Labs' SSL Server Test (ssllabs.com/ssltest/) grades your SSL/TLS configuration from A+ to F, checking: certificate validity, protocol support (TLS 1.0/1.1 should be disabled), cipher strength, vulnerability to known attacks (BEAST, POODLE, Heartbleed, DROWN), and HSTS configuration. Run a test after any SSL-related changes and aim for an A+ grade. Most modern hosting platforms achieve A+ without any manual configuration.
Google Safe Browsing checks billions of URLs daily for malware, phishing, and harmful content. If your site is flagged, Chrome shows a red warning page to all visitors — catastrophic for traffic and trust. Check your domain at transparencyreport.google.com/safe-browsing/search. If flagged, clean the malware, verify via Google Search Console, and request a review. Recheck monthly as part of routine maintenance.
Having a plan before an incident occurs dramatically reduces response time and damage. Know exactly what to do in the first 24 hours of discovering a breach — before panic sets in.
Write a one-page incident response procedure covering: (1) Who gets notified first (security team, management, legal), (2) How to take the site offline or into maintenance mode quickly, (3) How to preserve logs before cleaning up, (4) How to restore from backup, (5) When and how to notify affected users (required under GDPR/CCPA within 72 hours of discovering a breach). Store this document outside your website (Google Docs, printed copy) so it's accessible when your site is down.
If you suspect your site has been compromised: immediately change all admin passwords, API keys, database credentials, SMTP passwords, and any other secrets that may have been exposed. Revoke all active sessions. Check for unauthorized admin users and remove them. Contact your hosting provider — they may have additional logs or can isolate the compromised server. Do not use the same credentials on any other service.
PageGuard automatically scans your website's security headers, SSL certificate, and best practices. Get alerted when your security score drops — before visitors or Google flag an issue.
The most common include SQL injection, cross-site scripting (XSS), broken authentication, security misconfigurations (default credentials, exposed admin panels), outdated software with known vulnerabilities, and sensitive data exposure. Keeping software updated and implementing security headers addresses most of these for small business websites.
Yes — HTTPS is essential for every website in 2026, not just e-commerce sites. HTTPS encrypts data, prevents man-in-the-middle attacks, is a Google ranking signal, and prevents Chrome's "Not Secure" warning. Free SSL certificates are available from Let's Encrypt and are automatically provisioned by most hosting platforms.
Signs of a hack: unexpected pages in Google search results (search site:yourdomain.com), visitor reports of redirects to spam sites, new admin accounts you didn't create, Google Search Console security warnings, or your hosting provider suspending your account for malware. Check Google's Transparency Report for your domain and review Google Search Console for manual actions or security issues.
Update as soon as security patches are released — ideally within 24–48 hours. Outdated WordPress plugins are the #1 cause of WordPress hacks. Enable automatic minor security updates and manually review major version updates. Remove unused plugins entirely — even inactive plugins are attack surface.
A CSP is an HTTP header that tells browsers which content sources are allowed, preventing XSS attacks. Every website should have one. Start with Content-Security-Policy-Report-Only to audit without breaking functionality, then enforce it. A basic CSP restricting script-src to your own domain eliminates most XSS attack surface. PageGuard's Best Practices scan checks for your CSP header.