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 usually 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

Administrative access is one of the most common places where a website becomes exposed. 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.
• 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. A secure WordPress dashboard is not enough if the hosting account, database panel or domain registrar is still 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.

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.
• Limit upload types and store uploaded files away from executable paths.
• Return clear user messages without leaking stack traces or server details.
• 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.

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. For WordPress malware removal and website cleanup work, recovery planning is especially important because attackers often leave more than one entry point behind.

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. A backup that cannot be restored under pressure is not a recovery plan.

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 need an independent review, MaxMindSecurity can scope website security services around the site you already run, including WordPress malware removal, form protection, access review, dependency review, hosting exposure and practical remediation guidance.