Pre-Launch Website Checklist: 18 Tools for DNS, SSL, CDN, and Security Testing

Few things are more frustrating after launching a website than finding that it works on your computer but fails for everyone else. A DNS change may still not have propagated, an apparently valid HTTPS certificate may be close to expiring, or traffic may not actually be passing through the CDN and WAF you configured.

These issues rarely come from a single source. After a user enters a URL, the request passes through DNS resolution, the network connection, CDN, WAF, web server, and HTTPS encryption. A configuration problem at any point can make the website unavailable, slow, or appear unsafe in the browser.

Below are 18 browser-based website testing tools, organized into five groups in a practical troubleshooting order. Use this checklist when launching a new website, migrating servers, changing domains, moving to HTTPS, or performing routine maintenance.

Note: These tools include a limited number of free guest uses. Sign in for higher usage limits, or upgrade to a Pro membership for additional uses. Current limits are shown on each tool page.

1. Verify the Domain and DNS Configuration

When a website becomes unavailable, do not start by changing server settings. First, confirm that the domain is active and DNS is returning the correct records.

1. DIG Lookup: View Complete DNS Records

DIG Lookup is ideal for troubleshooting complex DNS issues. It can query A, AAAA, CNAME, MX, NS, and other records, with the option to use a specific DNS server.

Common uses include:

• Checking whether the domain points to the new server IP;
• Comparing results from different DNS servers;
• Troubleshooting MX records when email delivery fails;
• Confirming that an NS migration is complete.

After changing DNS records, query both the authoritative nameserver and popular public DNS resolvers. This makes it easier to distinguish a configuration error from cached records that have not yet expired.

2. NSLOOKUP: Quickly Check DNS Resolution

NSLOOKUP is better suited to quick, everyday checks. Enter a domain to view its A, AAAA, CNAME, MX, NS, and other DNS records.

DIG and NSLOOKUP serve similar purposes, but DIG usually provides more detailed output for deeper analysis. NSLOOKUP offers a simpler way to answer, “Where does this domain currently point?”

3. WHOIS Lookup: Check Registration and Expiration Details

WHOIS Lookup displays a domain’s registrar, registration date, expiration date, status, and related details.

If a domain suddenly becomes unavailable, check more than its DNS settings:

• Has the domain expired?
• Is it in a non-resolving status such as clientHold?
• Has the registrar or registry locked it?
• Were its nameservers changed unexpectedly?

4. Domain Checker: Test DNS and HTTP Status Together

Domain Checker tests DNS records and HTTP status codes together, making it useful for an initial diagnosis.

If the tool resolves an IP address but the HTTP request fails, the likely cause is the server, port, firewall, or web service. If the domain does not resolve to an IP at all, investigate DNS first.

5. Subdomain Scanner: Inventory Public-Facing Assets

Subdomain Scanner discovers active subdomains associated with a target domain, helping you inventory assets and identify security risks before launch.

Many security issues occur outside the main website—in old admin panels, staging environments, temporary campaign pages, or forgotten subdomains. Confirm whether each subdomain still serves a business purpose, and retire unused services to reduce your attack surface.

2. Verify the CDN, WAF, and Redirect Path

Once DNS is working, confirm that traffic passes through the expected CDN and security layers.

6. CDN Provider Detector: Confirm Edge Delivery Is Active

CDN Provider Detector identifies whether a website uses a CDN and which provider may be serving it.

Use it to check whether:

• The CNAME points to the CDN;
• Website traffic is passing through edge nodes;
• Old settings remain after switching CDN providers;
• A competitor or third-party website uses a particular type of acceleration service.

Some websites obscure their underlying infrastructure. Evaluate the result alongside DNS records, response headers, and the nodes observed during real requests.

7. Website WAF Detector: Identify Web Application Firewalls

Website WAF Detector checks whether a website is protected by a web application firewall and attempts to identify its type or vendor.

A WAF does not make a website completely secure, but it can block common malicious requests, scans, and attacks. Before launching an admin system, API, or website that handles user data, verify that its WAF rules are active without being so strict that they block legitimate traffic.

8. URL Redirect Checker: Trace 301 and 302 Redirect Chains

URL Redirect Checker shows the complete redirect path for a URL, including the HTTP status code at each step.

It is especially useful for checking whether:

• HTTP correctly redirects to HTTPS;
• The root domain and www version resolve consistently;
• Old URLs use 301 permanent redirects after a migration;
• There are redirect loops or unnecessarily long chains;
• A third-party link adds another redirect before the landing page.

Longer redirect chains generally increase latency and can create crawling, attribution, and SEO issues. Whenever possible, redirect an old URL directly to its final destination in one step.

3. Check SSL Certificates and HTTPS Security

A website loading over HTTPS only confirms that the basic connection works. It does not guarantee that its certificate, HSTS policy, and TLS configuration are correct.

9. SSL Certificate Checker: Catch Expiration and Hostname Errors

SSL Certificate Checker verifies certificate validity and displays the issuer, validity period, encryption algorithm, and hostname coverage.

Before launch, confirm that:

• The certificate covers the domain being accessed;
• The intermediate certificate chain is complete;
• The certificate has not expired and has enough time left for renewal;
• Both old and new servers have the correct certificate installed;
• Automated renewal jobs can complete successfully.

Certificate problems often go unnoticed until browsers begin showing widespread security warnings. Include expiration monitoring in routine maintenance.

10. HSTS Test: Confirm Browsers Enforce HTTPS

HSTS Test checks the Strict-Transport-Security response header and analyzes max-age, includeSubDomains, and preload-related settings.

HSTS reduces the risk of HTTPS downgrade and SSL stripping attacks, but every affected domain must support HTTPS before you enable it. Before adding includeSubDomains or submitting a domain to the HSTS Preload list, audit legacy subdomains to avoid making older services inaccessible when browsers force them to use HTTPS.

11. TLS LOGJAM Vulnerability Test

TLS LOGJAM Vulnerability Test evaluates the server’s Diffie-Hellman key exchange configuration for weak parameters that could enable downgrade attacks.

If a risk is detected, update the TLS configuration and server software, disable insecure legacy cipher suites, and use sufficiently strong parameters.

12. SSL Heartbleed Vulnerability Test

SSL Heartbleed Vulnerability Test checks whether a target SSL/TLS service may be affected by CVE-2014-0160.

Although Heartbleed is an older vulnerability, neglected devices, legacy systems, and outdated services may still be exposed. If you detect a risk, replacing the certificate alone is not enough. Update the affected software and assess whether old private keys or sensitive data may have been compromised.

13. TLS Ticketbleed Vulnerability Test

TLS Ticketbleed Vulnerability Test checks for the CVE-2016-9244 memory disclosure vulnerability associated with TLS session tickets.

This specialized test is most useful for server maintenance, security reviews, and legacy device audits. If it reports a possible issue, verify the finding against vendor advisories, software versions, and server settings.

Only run security tests against websites and servers you own or have explicit permission to assess. Never scan or test a target without authorization.

4. Check Web Compression and Server Response Time

After completing the security checks, make sure pages are transferred efficiently. A page that loads is not necessarily a page that loads quickly.

14. GZIP Compression Test

GZIP Compression Test checks whether a web response uses GZIP and estimates its size before and after compression.

Text-based assets such as HTML, CSS, JavaScript, JSON, and SVG generally compress well. Serving large text responses without compression increases bandwidth usage and download time.

15. Brotli Compression Test

Brotli Compression Test examines response headers to determine whether a web page uses Brotli compression.

Brotli often provides strong compression for text assets delivered over HTTPS to modern browsers. You can keep GZIP enabled as a fallback and let the server choose the appropriate format based on the browser’s Accept-Encoding header.

16. TTFB Test: Find Slow Initial Server Responses

TTFB Test measures the time from sending a request to receiving the first byte, helping you analyze time spent on DNS, TCP, SSL, and server processing.

A high Time to First Byte may be caused by:

• Slow DNS resolution or network connections;
• A server located too far from the user;
• Slow database queries or dynamic page rendering;
• Cache misses;
• Blocked or slow upstream APIs;
• Slow CDN origin fetches.

TTFB is only a starting point for performance diagnostics. Review it alongside page weight, caching policies, and frontend rendering time.

5. Test Network Connectivity and Ports

If DNS and HTTPS appear correct but the service is still unavailable, test whether the host and required ports can be reached.

17. Ping Test: Check Latency and Packet Loss

Ping Test measures host reachability, network latency, and packet loss.

Some servers and cloud firewalls intentionally block ICMP, so a failed Ping does not necessarily mean the website is down. Confirm the result with an HTTP request and a port check.

18. Port Checker: Confirm Services Are Publicly Reachable

Port Checker determines whether a TCP port on a domain or IP address is open, closed, or filtered.

Common targets include port 80 for HTTP, port 443 for HTTPS, and any application-specific service ports. If a website port cannot be reached, check the cloud security group, operating system firewall, container port mapping, reverse proxy listening address, and service process.

Databases, caches, admin panels, and other services that do not require public access should be restricted to approved IP addresses or private networks.

A Practical Pre-Launch Website Testing Order

If you are unsure where to begin, follow these steps:

1. Use WHOIS to confirm that the domain is active and in good standing;
2. Use DIG and NSLOOKUP to check A, AAAA, CNAME, MX, and NS records;
3. Use Domain Checker to verify the resolved IP and HTTP status;
4. Use the CDN and WAF detectors to confirm the traffic path and security coverage;
5. Use URL Redirect Checker to standardize HTTP/HTTPS and the preferred domain;
6. Use SSL Certificate Checker to verify the certificate, hostname coverage, and expiration date;
7. Use the HSTS and TLS vulnerability tools to review the HTTPS security configuration;
8. Use the GZIP and Brotli tests to verify compression for text assets;
9. Use the TTFB test to identify slow server or CDN origin responses;
10. Use Ping Test and Port Checker to troubleshoot remaining connectivity issues;
11. Use Subdomain Scanner to remove abandoned staging sites and unused services.

Final Thoughts

Website failures rarely tell you which layer is responsible. A simple “site can’t be reached” message could point to an expired domain, stale DNS cache, a slow CDN origin, an overly aggressive WAF rule, an incomplete certificate chain, a closed port, or even a slow Time to First Byte.

Instead of repeatedly changing settings after something breaks, standardize your testing process. Run a complete check before launch, repeat it after migrations and redesigns, and continuously monitor domains, certificates, and critical endpoints. Bookmark these 18 tools so the next time a website goes down, HTTPS fails, or performance drops, you can troubleshoot each layer systematically instead of starting from guesswork.