Website Security Checklist Before Launch or Relaunch

A website launch can look ready from the outside while important security work is still unfinished. The design may be approved, the forms may submit correctly, and the pages may load quickly, but attackers look for quieter gaps: exposed admin areas, weak login controls, forgotten plugins, old dependencies, unprotected forms, permissive file uploads and missing recovery plans.

This checklist is written for business owners, marketing teams and technical leads who want a practical website security review before a new site goes live or an existing site is relaunched. It is not a promise that any website can be made risk-free. It is a way to reduce avoidable exposure, document the decisions that matter and make sure someone owns the follow-up work.

Start with what the website actually does

The first security question is not which tool to install. It is what the website handles. A brochure site, a WordPress site with contact forms, an ecommerce storefront and a Laravel customer portal do not carry the same risk. The review should identify what data is collected, where it is stored, who receives it, which third-party services process it and which accounts can change the site.

For most small and mid-sized businesses, the most important assets are simple: customer enquiries, administrator accounts, payment redirects, analytics tags, DNS records, hosting access and backups. Write these down before testing begins. If nobody can explain what the site depends on, it becomes difficult to protect it consistently.

Review login and administrator access

Administrator access deserves attention first because the login page is public by design. Every admin account should belong to a real person, use a strong unique password and be protected with multi-factor authentication where the platform supports it. Shared admin accounts should be removed or replaced with named users so activity can be traced.

• Remove old users, contractors and test accounts that no longer need access.
• Limit administrator roles to people who genuinely maintain the website.
• Check whether login pages are protected against repeated password guessing. The WordPress handbook on brute force attacks lists the usual defenses: rate limiting, a CAPTCHA on the login form and two-factor authentication through a plugin.
• Store recovery codes and registrar access in a controlled business process.

For WordPress websites, this step should include plugin and theme administrators as well as hosting panel users. MaxMindSecurity Pro covers the login side with a web application firewall, two-factor authentication, a custom login URL and reCAPTCHA on the login and registration forms. A secure WordPress dashboard is still not enough if the hosting account, database panel or domain registrar is easy to access.

Check updates, plugins and dependencies

Outdated software is not automatically compromised, but it increases the chance that a known weakness is reachable. WordPress plugins, commercial themes, Laravel packages, JavaScript libraries and server packages should be reviewed before launch. Remove anything unused. Update what can be updated safely. Record any item that cannot be updated and why. The WordPress hardening handbook is blunt on this point: older versions are not maintained with security updates.

Do not treat plugin count as the only risk signal. A single abandoned plugin that handles file uploads or form submissions can matter more than several simple display plugins. The same principle applies to custom applications: the important question is whether a dependency is exposed to user input, authentication, file handling, payment flows or sensitive data.

Protect forms, uploads and public endpoints

Contact forms, quote requests, newsletter forms and login forms deserve special attention because they are intentionally public. They should validate input, rate-limit repeated submissions and avoid exposing detailed internal errors. If the site receives spam or abuse, reCAPTCHA or another challenge can help, but it should support a wider plan rather than replace server-side controls.

• Use server-side validation for every public form. OWASP's input validation guidance is to check both the format of a value and whether it makes sense for the request.
• Limit upload types and store uploaded files outside the web root where possible, as the OWASP file upload cheat sheet describes.
• Return clear user messages without leaking stack traces or server details. OWASP's error handling guidance is to log the detail on the server and show visitors a generic response.
• Send notifications to a monitored inbox so enquiries are not missed.

A good website security review does not only ask whether a form works. It asks what happens when the form is abused.

Confirm DNS, HTTPS and security headers

DNS and HTTPS settings shape how visitors reach the website. The domain should resolve only to the intended services, old staging records should be removed, and HTTPS should be enforced across the site. Security headers such as Content Security Policy, HSTS, X-Frame-Options and Referrer-Policy can reduce common browser-side risks when configured carefully. Our security headers guide explains what each one does and how to test a change without breaking the site.

These controls should be tested in context. A strict Content Security Policy can break analytics, chat tools or payment redirects if it is copied blindly. A practical review starts with observation, then tightens settings in a way that fits the scripts and services the website actually uses.

Backups and recovery matter as much as prevention

No checklist should pretend that prevention is perfect. Backups should exist, restoration should be tested, and the business should know who can make DNS, hosting and application changes during an incident. Recovery planning matters just as much after a compromise, because a backup taken after the break-in can carry the same injected files back onto the site.

Before launch, confirm where backups are stored, how often they run, who can restore them and whether a clean copy exists outside the live hosting account. WordPress's backup guide notes that a full restore needs both the files and the database. A backup that cannot be restored under pressure is not a recovery plan; our backup and restore guide covers how to test one before you need it.

What to do before publishing

Before a launch or relaunch, review the site against the areas above and document the result. Mark which items are complete, which risks have been accepted temporarily and which items need owner follow-up after launch. This creates a more honest security baseline than a vague statement that the site is secure.

If you want a second pair of eyes before the launch date, a scoped security assessment works through the same areas against the site you have actually built. Send the site address and the planned launch date through the contact form, and keep passwords out of the first message.