Web Hosting for Developers: 12 Pre-Launch Checks

A website can work perfectly in staging and still fail after launch. The DNS record may point to the wrong server. The certificate may omit the www hostname. A cache that looks fast during testing may accidentally store private pages. Transactional email may never leave the server. Backups may exist but be impossible to restore under pressure.

These failures are often blamed on “the hosting,” but hosting quality is only one part of production readiness. The real question is whether the complete system DNS, network, server, runtime, application, database, cache, security, email, monitoring, and recovery behaves correctly under realistic conditions.

This guide provides a repeatable pre-launch workflow for developers deploying WordPress, WooCommerce, PHP applications, or other database-driven websites. It is intentionally provider-neutral. You can use it when evaluating a shared plan, a managed platform, a VPS, or infrastructure you operate yourself.

The goal is not to chase a perfect benchmark score. The goal is to collect enough evidence to answer three practical questions:

1. Will real visitors receive the correct site quickly and securely?

2. Can the application remain reliable when traffic or workload changes?

3. Can the team detect, contain, and recover from a failure?

If any answer is uncertain, the deployment is not finished.

1. Define the workload before comparing hosting plans

Start with the application, not the hosting product page. Two sites with the same monthly visitor count can require very different resources.

A mostly static company website may serve the same cached page thousands of times with little PHP or database work. A WooCommerce store may create unique sessions, update carts, run background jobs, process webhooks, and send transactional email. A membership site may have many authenticated requests that cannot use full-page caching. An agency may care less about one site's peak traffic and more about account isolation, client access, and the combined load of dozens of installations.

Write down the expected workload:

• application and runtime versions;

• average and peak requests per minute;

• percentage of anonymous versus authenticated traffic;

• database size and rate of change;

• storage required for media, logs, and backups;

• scheduled jobs, imports, webhooks, and queues;

• target visitor locations;

• recovery-time and recovery-point expectations;

• people responsible for updates, monitoring, and incidents.

This prevents a common mistake: choosing a plan based on storage alone. Storage capacity says little about CPU scheduling, memory, process limits, database concurrency, I/O, or operational support.

It also clarifies which service model fits. The categories presented by United Web Host including web hosting, managed WordPress, agency, reseller, and VPS options illustrate why “hosting” is not one operational model. Each category shifts a different amount of control and maintenance responsibility between the customer and provider.

2. Verify DNS from outside your own network

DNS is the first dependency in every request. Check it from a terminal and, ideally, from more than one network or public resolver.

dig +short example.com A
dig +short www.example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short example.com TXT

Confirm that:

• the apex and www hostnames resolve to the intended destination;

• an IPv6 record is present only if the server is correctly configured for IPv6;

• mail records still point to the active mail provider;

• SPF, DKIM, and DMARC records were not lost during a DNS migration;

• the time to live, or TTL, matches the migration plan;

• old staging, temporary, and verification records are removed when no longer needed.

An incorrect AAAA record is particularly deceptive. Some visitors may use IPv4 and see the correct site, while others prefer IPv6 and reach an old server or a timeout.

Before changing nameservers, export or capture the existing zone. Lowering TTL ahead of a planned migration can shorten the period during which resolvers retain the old answer, but it does not make propagation instantaneous. After the move, query the authoritative nameservers as well as public resolvers before declaring success.

3. Inspect the HTTP and TLS path

The browser's padlock does not prove that every hostname, redirect, and protocol path is correct. Test the important URL variants explicitly.

curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com

Choose one canonical hostname and confirm that every other version reaches it through a small, intentional redirect chain. Avoid loops and unnecessary hops such as HTTP apex → HTTPS apex → HTTPS www → another application redirect.

Inspect the certificate from the command line:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Check the certificate's validity period and Subject Alternative Names. Make sure automatic renewal is configured and monitored. A certificate that renews automatically is useful only if failed renewals generate an alert before expiration.

HTTPS protects data in transit, but it does not make the application itself secure. The distinction matters: TLS can be configured correctly while the site still contains vulnerable plugins, weak credentials, exposed backups, or unsafe code.

4. Measure DNS, connection, TLS, TTFB, and total time separately

A single “load time” number hides the layer causing the delay. Use curl to split the request into phases:

curl -o /dev/null -s -w \
'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
https://example.com/

Time to First Byte, or TTFB, includes more than server hardware. Network distance, redirects, application bootstrapping, PHP work, database queries, external API calls, and cache state can all contribute. Google's web.dev guidance on TTFB explains why it is best treated as a diagnostic signal rather than a complete user-experience metric.

Run several tests instead of trusting one request. Compare:

• the first request after a cache purge;

• a repeated request that should be cached;

• a public page;

• an authenticated or deliberately uncached page;

• tests from a region near the server;

• tests from a region where actual visitors live.

Record median and slow-tail results. An occasional fast response cannot compensate for frequent multi-second outliers. Conversely, a slow first uncached request and fast subsequent responses may point to expensive application generation hidden by full-page caching.

5. Confirm that caching is correct, not merely enabled

Caching can reduce server work dramatically, but the wrong cache rule can create serious functional or privacy failures.

Inspect response headers:

curl -I https://example.com/
curl -I https://example.com/cart/
curl -I https://example.com/my-account/

Depending on the stack, look for headers such as Cache-Control, Age, ETag, Last-Modified, Vary, and provider-specific cache status headers. MDN's HTTP caching documentation is a useful reference for how browser and shared-cache directives behave.

For WordPress and WooCommerce, verify that public anonymous pages can be cached where appropriate, while these areas bypass shared full-page caching:

• cart and checkout;

• customer accounts;

• administrator pages;

• preview URLs;

• password-protected content;

• personalized or session-dependent responses;

• webhook and API endpoints that must remain dynamic.

Test with two separate browser sessions. Add an item to a cart or sign in with one session, then make sure the other session never receives that private state.

Also define cache invalidation. Publishing or updating content should clear the relevant page, archive, feed, and related objects without purging everything more often than necessary. A cache that serves stale content indefinitely is not a performance solution.

6. Check compression, protocol support, and static assets

HTML is only the beginning of the page load. Large images, fonts, CSS, and JavaScript often dominate transfer size and rendering time.

Check compression negotiation:

curl -I -H 'Accept-Encoding: br, gzip' https://example.com/

Then inspect a real page in browser developer tools. Look for:

• Brotli or gzip compression for compressible text resources;

• modern image formats and appropriate dimensions;

• long-lived caching for versioned static assets;

• no-cache or short caching for content that changes frequently;

• HTTP/2 or HTTP/3 where supported;

• fonts that are actually used rather than entire unused families;

• JavaScript that can be deferred without breaking interaction;

• third-party scripts that block rendering or introduce long tasks.

Do not use compression as an excuse to ship unnecessary code. A compressed 500 KB script is still code the browser must download, parse, compile, and execute.

Keep the origin fast even when a CDN is enabled. A CDN can reduce distance for cacheable assets and absorb some traffic, but cache misses and dynamic requests still reach the origin. During testing, compare the CDN path with a controlled origin test so that one layer does not hide a weakness in another.

7. Validate the runtime, database, and resource limits

Applications fail at their limits, not at their marketing labels. Before launch, document the effective runtime configuration.

For PHP workloads, check:

php -v
php -m
php -i | grep -E 'memory_limit|max_execution_time|upload_max_filesize|post_max_size'

In shared or managed environments, the command-line PHP version may differ from the version serving web requests. Confirm the web runtime through the control panel or a temporary protected diagnostic page, then remove that page immediately.

For WordPress, record:

• PHP version and required extensions;

• WordPress core, theme, and plugin versions;

• PHP memory and execution limits;

• maximum upload and request sizes;

• cron implementation;

• database version and table engine;

• object-cache status;

• disk and inode usage;

• worker, process, or entry-process limits.

If WP-CLI is available, run non-destructive checks:

wp core verify-checksums
wp plugin list
wp theme list
wp cron event list
wp db size

Do not increase every limit automatically. A process that requires unlimited memory or execution time may contain a slow query, loop, oversized import, or architectural problem. Limits should fit the expected workload while still containing runaway processes.

Database testing should include representative queries and application actions, not only a connectivity check. Load the pages that build the most complex queries, search a large catalog, run a scheduled import, and test simultaneous cart or account activity when relevant.

8. Test backups by restoring them

“Daily backups included” is not a complete recovery plan. Ask five questions:

1. What is backed up—files, database, email, DNS, configuration, or only part of the account?

2. How often is each component captured?

3. How long are restore points retained?

4. Is a copy stored outside the same failure domain?

5. How long does a full restore take?

Then perform a restoration to an isolated location. Confirm that the restored site has the expected database state, media files, configuration, users, scheduled jobs, and application secrets. Test login and at least one business-critical workflow.

Recovery Point Objective (RPO) describes how much recent data the organization can afford to lose. Recovery Time Objective (RTO) describes how long the service can remain unavailable. A brochure site might accept a daily restore point and several hours of recovery. A busy store may need a much smaller data-loss window and a carefully rehearsed procedure.

Write the restore steps before an incident. Include who has permission, where credentials are stored, how DNS or traffic will be switched, how new writes will be handled, and how the team will validate the recovered system.

9. Review isolation, access, updates, and application security

Security should be layered. No single scanner, firewall, plugin, or certificate can protect every part of the system.

Use the OWASP Application Security Verification Standard as a structured reference, then adapt it to the site's risk. At minimum:

• enable multifactor authentication for administrative accounts;

• avoid shared administrator credentials;

• give each person and service only the access required;

• protect SSH and control-panel access;

• use SFTP or SSH instead of plain FTP where possible;

• rotate temporary migration credentials;

• keep the runtime, CMS, plugins, and themes supported and updated;

• remove unused applications, plugins, themes, users, and database accounts;

• prevent public access to environment files, logs, archives, and backup packages;

• confirm file ownership and permissions;

• rate-limit or otherwise protect sensitive endpoints;

• verify that malware scanning and firewall alerts reach a real person.

Account isolation matters on multi-tenant systems and agency accounts. A compromise in one site should not provide an easy path to unrelated sites. Ask how users, files, processes, and resources are separated, and make sure agency staff do not reuse credentials across client installations.

For WordPress, avoid installing multiple security plugins that overlap unpredictably. Decide which layer owns login protection, file-change monitoring, malware scanning, firewall rules, backups, and update policy.

10. Make logs and monitoring useful before something breaks

An uptime monitor that requests only the home page every five minutes can miss important failures. The homepage may remain cached while PHP, the database, checkout, email, or background jobs are broken.

Create monitoring around user-visible outcomes:

• public HTTP availability;

• certificate expiration;

• DNS correctness;

• server resource pressure;

• error rate and slow responses;

• disk and inode capacity;

• database connectivity;

• scheduled-job completion;

• backup completion and age;

• a critical application flow, such as login or a safe test checkout;

• mail delivery for transactional messages.

Ensure the application, web server, PHP runtime, database, and security layers retain enough logs for diagnosis. Confirm timestamps and timezone settings so events can be correlated across systems.

Alerts need an owner and an action. A warning sent to an unchecked mailbox is not monitoring. Define which events are urgent, who receives them, what information an alert must contain, and when the issue should be escalated to the hosting provider or application developer.

11. Test forms and email as complete workflows

A form showing “success” in the browser does not prove that the message was delivered. Test every important form with addresses at multiple mail providers.

Verify:

• the submission is stored safely when storage is required;

• the administrator notification arrives;

• the user confirmation arrives;

• the From address belongs to an authenticated domain;

• Reply-To points to the intended address;

• SPF, DKIM, and DMARC align with the sending service;

• failures are logged without exposing private form data;

• rate limits and anti-spam controls do not block legitimate submissions;

• sensitive content is not placed unnecessarily in email.

For WordPress, route production email through a suitable authenticated SMTP or transactional email service rather than assuming the server's default mail function will provide dependable delivery.

Test password resets, order notifications, contact forms, support forms, and administrator alerts separately. They may be generated by different plugins or services and fail for different reasons.

12. Rehearse migration, rollback, and support escalation

A production deployment should have a rollback threshold, not just a launch time.

Before changing DNS or traffic:

• take a final verified backup;

• record the old DNS values and server details;

• reduce TTL in advance when appropriate;

• identify content or orders created during the migration window;

• decide whether the old site must enter maintenance or read-only mode;

• create a post-launch validation checklist;

• define measurable rollback conditions;

• keep access to the old environment until acceptance is complete.

Your validation list should include the homepage, navigation, search, authentication, forms, checkout, payment callbacks, webhooks, cron tasks, redirects, structured data, analytics, robots directives, sitemap, and error pages.

Finally, test the support path before an emergency. Know where to open a ticket, what authentication is required, which issues are within the provider's scope, and what evidence will speed up diagnosis. A useful incident report normally includes the affected URL, UTC timestamp, steps to reproduce, expected and actual results, relevant status code, request ID if available, and a short description of recent changes.

A compact scoring model

You can turn the checklist into a simple decision table. Score each area from 0 to 2:

Score	Meaning
0	Missing, failed, or unknown
1	Partly verified or dependent on manual intervention
2	Verified, documented, monitored, and owned

Apply the score to these categories:

Category	Evidence to retain
DNS and routing	Resolver output, zone copy, canonical redirect results
TLS	Certificate names, expiration, renewal monitoring
Performance	Cold/warm timing samples from relevant regions
Caching	Public/private test results and invalidation rules
Runtime	Versions, extensions, limits, and compatibility checks
Database	Size, representative workload tests, slow-query evidence
Recovery	Backup inventory and successful restore record
Security	Access review, update status, isolation, alert routing
Monitoring	Checks, thresholds, owners, and escalation path
Email	Delivery tests and authentication results
Migration	Cutover plan, validation list, rollback conditions
Support	Contact path, scope, and incident evidence template

A score does not replace engineering judgment. Some failures are launch blockers even if the total score is high. An invalid certificate, untested backup, broken checkout, or exposed private data should not be averaged away by strong results elsewhere.

Final thoughts

Good web hosting is not defined by one benchmark, a long feature list, or an unlimited label. It is a combination of suitable resources, predictable behavior, secure configuration, observable systems, clear responsibility, and tested recovery.

The best time to discover a DNS error is before nameservers change. The best time to learn that a backup is incomplete is during a controlled restore. The best time to define rollback conditions is before the team feels pressure to keep a broken launch online.

Use this checklist as a living deployment document. Save the commands, results, owners, and decisions with the project. Repeat the high-risk tests after major plugin changes, runtime upgrades, infrastructure migrations, and traffic growth.

Production readiness is not the absence of possible failure. It is the ability to prevent common failures, detect the rest quickly, and recover without improvising.

---

Disclosure: This article was prepared with AI assistance and reviewed for technical accuracy and relevance before publication. Readers should adapt commands and thresholds to their own environment.