Website Security Checklist Before Going Live: A Practical Guide

Before launching a business website, a structured security review catches problems that are far easier to fix before the site goes live. A small UK business that discovers an exposed admin panel, an outdated plugin with a known vulnerability, or a missing SSL certificate after receiving their first customer complaint will spend far more time and money on the fix than if they had reviewed these items beforehand.

This checklist covers the most common security concerns that appear during a website launch review. It applies whether the site runs on WordPress, a custom PHP application, or another platform. Each section explains what to check, why it matters, and what to do if you find a problem.

Admin access and authentication controls

Weak admin access is one of the most common ways an unsecured website gets compromised. Before going live, verify every administrative account follows current password standards and that unnecessary accounts have been removed.

Check the following for admin accounts:

• Strong passwords: All admin accounts should use passwords of at least 12 characters with a mix of types. Avoid dictionary words, names, or patterns.
• Unique accounts: Each person who manages the site should have their own login. Shared credentials make accountability impossible and create unnecessary risk when someone leaves.
• Two-factor authentication: Where the platform supports it, enforce 2FA for all admin accounts. This single measure prevents most credential-based attacks.
• Default username removal: Many platforms create a default admin account during installation. If the site still has an account named "admin", "administrator", or the platform default, change it or remove it.
• Account lockout thresholds: Ensure repeated failed login attempts trigger a temporary lockout or increasing delay. This slows down automated password attacks.

A practical way to audit admin accounts is to export the list and cross-reference against active team members. Any account that does not correspond to a current team member should be deactivated or deleted.

Software updates and patch management

Outdated software is a primary entry point for attacks. Before launch, confirm that the core platform, all plugins, themes, and server-side components are on current stable versions.

For a typical small business website, the update review should cover:

• Core platform: WordPress, Drupal, or custom PHP framework on the latest stable release.
• Plugins and themes: Every installed plugin and theme. Remove any that are not actively used. Each unused plugin is a potential vulnerability with no benefit.
• Server operating system: For VPS or dedicated hosting, confirm the OS receives security patches. Managed hosting typically handles this, but it is worth confirming.
• Database software: MySQL, MariaDB, PostgreSQL, or SQLite versions should be current.
• PHP version: If the site runs on PHP, use a version that still receives active security support. PHP 8.1 and above receive security fixes, while older versions have reached end-of-life.

For WordPress sites, a monthly update routine prevents accumulation of pending patches. A business launching a new site should document the update schedule before going live, not after.

TLS certificate and HTTPS configuration

Every business website should use HTTPS. Without a valid TLS certificate, browsers display a security warning that immediately undermines trust. For UK businesses handling enquiries, bookings, or any form submissions, this is not optional.

When reviewing TLS before launch:

• Valid certificate: Confirm the certificate covers the correct domain and has not expired. Tools like the Mozilla HTTP Observatory can test this and other HTTP security headers.
• Certificate chain: The server must serve the full certificate chain. An incomplete chain causes errors on some browsers and devices.
• HSTS header: Enable HTTP Strict Transport Security to force browsers to use HTTPS for future visits. Set a reasonable max-age value and include subdomains if applicable.
• Redirect configuration: All HTTP requests should redirect to HTTPS. Test this directly by requesting http://yourdomain.com and confirming a 301 redirect to the HTTPS version.
• Mixed content: Verify no resources on HTTPS pages load over HTTP. Mixed content warnings can break site functionality or display security indicators in the browser.

Free certificates from Let's Encrypt work well for most small business sites. The renewal process should be automated to avoid accidental expiration.

Form handling and input validation

Contact forms, enquiry forms, login fields, and any other input mechanism are frequent targets for abuse. Before launch, review how the site handles user input on both the client and server side.

Key form security checks:

• Server-side validation: Never rely on client-side JavaScript validation alone. Every piece of data submitted must be validated and sanitised on the server before use or storage.
• SQL injection prevention: If the site uses a database, confirm that user input is not directly interpolated into SQL queries. Parameterised queries or prepared statements prevent most SQL injection attacks.
• XSS protection: Output encoding prevents cross-site scripting. Any user-supplied content displayed back to visitors must be escaped appropriately for the context, whether HTML, URL, or JavaScript.
• CSRF tokens: Forms that perform actions should include cross-site request forgery tokens. This prevents external sites from tricking a logged-in user into submitting unintended requests.
• Rate limiting: Forms should have reasonable submission limits. Without rate limiting, contact forms are a common vector for spam or denial-of-service.
• Honeypot fields: A hidden form field that bots fill in but humans cannot see can reduce automated spam submissions without user friction.

For more detail on input handling for PHP-based sites, the PHP security checklist for business websites covers session handling, SQL injection prevention, and XSS mitigation with code-level examples.

Logging and error handling

Error messages that display too much information help attackers understand the site's structure and weaknesses. At the same time, logs are essential for diagnosing issues and detecting suspicious activity after launch.

Review logging and error handling before going live:

• Error display: Production sites should not show detailed PHP errors, stack traces, or database errors to visitors. Log these errors to a file instead.
• Log storage: Server logs, application logs, and access logs should be stored securely. They should not be publicly accessible via the web.
• Log rotation: Configure log rotation to prevent disk space issues from accumulating log files over months or years.
• Failed login logging: Track failed login attempts. A sudden spike in failures on admin accounts is a clear warning sign.
• 404 monitoring: Unusual 404 errors can indicate someone probing the site for known vulnerabilities or files from previous sites hosted on the same server.

Backup and recovery procedures

No security measure is absolute. A backup that works when needed is the last line of defence when something goes wrong, whether through an attack, a failed update, or accidental data loss.

Before launch, confirm backup procedures are in place:

• Automated daily backups: Where possible, use automated daily backups for both files and the database. Manual backups are easily forgotten.
• Off-site storage: Backups stored on the same server as the website offer limited protection if the server itself is compromised. Store copies in a separate location.
• Backup integrity checks: Test restoring from a backup periodically. A backup that cannot be restored is not a backup.
• Recovery time: Document how long a full restore takes. This matters when the site is down and an outage is costing business.
• Version retention: Retain several days or weeks of backups. A problem may not be discovered immediately, and an older backup may be cleaner.

For WordPress sites specifically, the small business website maintenance checklist for UK SMEs covers backup scheduling, update routines, and the maintenance tasks worth doing on a regular basis.

File and directory permissions

File system permissions control who can read, write, and execute files. Incorrect permissions are a common vulnerability, especially on shared hosting or misconfigured servers.

Permission guidelines for most web servers:

• Configuration files: Files containing database credentials, API keys, or other secrets should not be publicly readable. Permissions of 600 or 640 are typical.
• Directories: Most directories should be 755 or 750. Avoid 777, which gives everyone write access.
• Uploaded files: Any directory where users can upload files should have strict write permissions. Upload directories should never be executable.
• Core platform files: WordPress core files should generally be owned by the web server user and not writable by the group or world.

Review the file permissions across the entire public web directory. Use an SSH command like this to identify world-writable files:

find /var/www/html -type f -perm -002

Files returned by this command warrant a closer look to confirm they genuinely need to be world-writable.

Security headers

HTTP security headers instruct browsers to apply protective behaviours. They are often overlooked but add meaningful defence against common attack techniques.

The most important security headers to configure before launch:

• Content-Security-Policy: Controls which resources the browser will load. A restrictive CSP can prevent XSS attacks by blocking inline scripts from executing.
• X-Content-Type-Options: Set to "nosniff" to prevent browsers from guessing content types. This stops some file upload exploits.
• X-Frame-Options: Prevents the site from being embedded in an iframe, protecting against clickjacking.
• Referrer-Policy: Controls how much referrer information is sent with requests. The default may leak more information than intended.
• Permissions-Policy: Restricts access to browser features like the camera, microphone, or geolocation if the site does not use them.

The Mozilla HTTP Observatory tests these headers and provides a score with recommendations for improvement. Running a site through it before launch gives a baseline security posture to improve over time.

Redirect integrity

Redirect chains, loops, and incorrect redirects create problems for search engines and users. They can also cause security issues if a redirect passes through an unencrypted page before arriving at the secure destination.

Review redirects before launch:

• Single redirect chains: Avoid redirecting A to B to C. Each hop adds latency and can cause issues with some browsers or crawlers.
• HTTPS redirect loop: Ensure the HTTPS redirect does not cause the server to loop back. This usually indicates a misconfigured redirect rule.
• Non-existent pages: Set a 404 page for pages that do not exist and ensure it is styled usefully. Do not redirect 404s silently to the homepage without good reason.
• WWW and non-WWW canonical redirect: Choose one version of the domain and redirect the other consistently. Search engines treat www and non-www as separate sites if not redirected.

Test all redirect paths manually and with a tool that follows redirect chains to confirm the final destination is correct.

Monitoring and maintenance planning

A website that passes every check at launch will gradually accumulate risk as software ages, configurations change, and new vulnerabilities are discovered. A monitoring and maintenance plan keeps the site secure over time.

Establish these monitoring practices before or shortly after launch:

• Uptime monitoring: Use a service that checks the site periodically and alerts when it becomes unavailable. Response time matters; a site that is down for hours may lose enquiries before anyone notices.
• SSL certificate expiry alerts: Set alerts before certificates expire. A certificate expiring silently causes an outage that is embarrassing and avoidable.
• Security advisory monitoring: Subscribe to security mailing lists for the platform, plugins, and server software in use. New vulnerabilities are announced regularly.
• Log review: Reviewing logs weekly or monthly catches suspicious patterns that real-time alerts may miss.
• Scheduled updates: Set a regular schedule for applying updates. The small business website maintenance checklist for UK SMEs covers the practical frequency for common maintenance tasks.

For businesses that do not have internal capacity to maintain this schedule, monthly or quarterly website maintenance support keeps security posture current without requiring deep technical knowledge in-house.

Common security review mistakes before launch

These mistakes appear repeatedly on sites that skip or rush the pre-launch review:

• Assuming the hosting provider covers everything: Managed hosting reduces server-side risk, but application-level issues remain the site owner's responsibility.
• Testing only in development: Security settings can behave differently in production. Test key checks in the live environment, particularly redirects, TLS configuration, and header settings.
• Ignoring staging environments: If the site launches with a new domain or changed DNS, a staging environment that is not accessible publicly may not reveal the same security configuration problems.
• Skipping the review after major changes: Any significant update, new plugin, or server configuration change should trigger a partial security review, not just a functional check.
• Relying on a single scan tool: Automated scanners catch many issues but miss logic flaws, access control problems, and configuration issues that require manual review.

When to carry out this review yourself and when to ask for help

For technical decision-makers comfortable with server configuration, PHP, and web hosting panels, most of the checks in this article can be performed using hosting dashboards, SSH access, and browser tools. The Mozilla HTTP Observatory and OWASP testing guides provide structured approaches.

Consider asking for external help when the site involves custom code, complex server configurations, or when the person responsible for launch does not have time to work through a systematic checklist. A short security review before launch often costs far less than incident response after a compromise.

For UK small businesses, the risk is not only technical. A compromised site can damage customer trust, affect search visibility, and create obligations around personal data handling under UK GDPR. A proportionate review before launch is a practical business decision, not an overcautious one.