Website launch checklist: hosting, DNS, email, SSL, backups and monitoring

Website launch checklist

1. Match hosting to the actual project

   Choose hosting from the application's requirements rather than from a feature count. A managed web-hosting plan can suit a conventional site or CMS, while cloud hosting may be more appropriate when the project needs additional resources, isolation or room to grow.

   • Confirm support for the runtime, framework, database and deployment workflow you will use.
   • Check who is responsible for operating-system, runtime and application updates.
   • Document access, ownership, export options and the process for moving the site later.
   • Set resource and spending alerts before opening the site to public traffic.

   Website Infrastructure Checker

2. Secure domain ownership and plan DNS changes

   Keep the domain in an account controlled by the responsible organization, protect registrar access and record every DNS entry before changing nameservers. Lowering TTL in advance can make a planned migration easier, but old records should only be removed after the new destination has been verified.

   • Inventory A, AAAA, CNAME, MX, TXT and CAA records and identify who owns each dependency.
   • Decide the canonical host and make the www/non-www redirect consistent with it.
   • Keep recovery details and registrar access separate from a single employee or agency account.

   DNS and Email Signal Checker

3. Enable HTTPS and verify certificate renewal

   The public hostname and every production subdomain should present a valid certificate. Prefer an automated issuance and renewal process, then test HTTP-to-HTTPS redirects, certificate names and expiry monitoring instead of treating the first successful certificate as the end of the task.

   • Verify the final production hostname after DNS has propagated.
   • Test renewal and alerting responsibilities before the certificate approaches expiry.
   • Add HSTS and other security headers only after checking their effect across the real application.

   SSL Certificate Checker · What is HSTS?

4. Configure business email, SPF, DKIM and DMARC deliberately

   Mail delivery and website hosting are separate systems even when one provider offers both. Publish only the MX records required by the selected mail service, maintain one valid SPF policy, enable DKIM with the mail provider and introduce DMARC with reporting appropriate to the sending setup.

   • List every service that is allowed to send mail for the domain before editing SPF.
   • Do not create multiple competing SPF records; combine authorized senders in one policy.
   • Start DMARC enforcement only after reviewing legitimate senders and reports.
   • Test transactional messages, contact forms and password-reset delivery separately.

   DNS and Email Signal Checker

5. Make backups independent and test restores

   A provider snapshot is useful, but it is not a complete backup strategy by itself. Define what must be recoverable, keep at least one copy outside the production environment and perform a real restore test before relying on the process.

   • Back up files, databases, configuration and any user-generated uploads.
   • Set retention periods that cover accidental deletion discovered days or weeks later.
   • Document recovery time and acceptable data loss for the people responsible for incidents.

6. Add monitoring from outside the hosting environment

   Uptime checks should run from outside the system they monitor. Start with the public homepage or a lightweight health endpoint, then add alerts for DNS resolution, TLS expiry and critical user flows without collecting more visitor data than necessary.

   • Send alerts to a channel that is monitored outside normal working hours when appropriate.
   • Define who investigates an alert and how false positives are recorded.
   • Review response time and error trends after launch instead of relying on a single check.

7. Inventory third parties, cookies and consent requirements

   List analytics, advertising, chat, video, payment and support services before launch. Determine which resources are essential, which require a user choice in the relevant jurisdictions and whether the privacy information accurately names the active providers and purposes.

   • Do not load optional marketing or analytics integrations before the required choice has been made.
   • Test consent withdrawal and verify that rejected services remain inactive.
   • Re-run the inventory whenever tag-manager or marketing configurations change.

   Ads and Tracking Signal Checker · What are third-party scripts?

8. Run a neutral pre-launch and post-launch check

   Use SiteTraceKit after the production domain is connected and again after DNS has settled. Review the final URL, TLS signal, public DNS, security headers, third-party resources and visible privacy links, then verify important findings manually in the real application.

   • Run the check before launch to establish a baseline and after launch to catch migration differences.
   • Treat unavailable signals as prompts for manual review, not as proof of a fault.
   • Keep the report with the launch notes so later changes have context.

   Website Infrastructure Checker