1. Confirm ownership and access before changing DNS.
Identify who controls the domain registrar, DNS zone, hosting account, content management system, email routing, analytics, and Search Console property. Use owner-approved accounts and document the responsible person for each system. A launch can stall when a required setting belongs to an unknown account or an inaccessible former provider.
Check the exact production domain and document root before uploading. Keep staging, sister sites, and unrelated domains outside the release. Record the current DNS values and lower the time to live only when a planned DNS change requires it. Do not change mail records unless email migration is explicitly part of the approved work.
2. Prepare HTTPS and one canonical hostname.
The certificate should cover the canonical domain and any hostname that must redirect to it, such as the www version. Test the certificate chain and renewal method. Every HTTP and alternate-host request should reach the preferred HTTPS URL through one permanent redirect whenever the hosting layer allows it.
Keep internal links, canonical tags, sitemap URLs, social metadata, and structured data on the same hostname and protocol. Watch for redirect loops, mixed content, and unnecessary chains. Test representative deep links as well as the homepage because a rule that works at the root can still mishandle nested routes or query strings.
3. Create a backup and prove the restore path.
Take a dated backup of every file, database, configuration, and setting the launch will change. Store it outside the directory being replaced and keep a second copy when the site is business-critical. A backup is useful only when the team knows what it contains and how to restore it.
Record the rollback trigger, responsible person, and exact recovery steps. For a narrow static release, backing up the affected files may be sufficient. For a database or application migration, include the database type, schema state, uploads, environment configuration, scheduled tasks, and a tested restore procedure. Avoid placing credentials or session data into handoff archives.
4. Configure compression, caching, and image delivery.
Enable gzip or Brotli for HTML, CSS, JavaScript, JSON, XML, and SVG responses. Give stable static assets an explicit cache lifetime and use versioned URLs when files may change. Keep HTML revalidatable so urgent content and metadata corrections are not trapped behind a long browser cache.
Resize images for their rendered use, prefer efficient formats, provide responsive candidates where sizes vary, and add width and height attributes so the browser can reserve space. Prioritize the image that becomes the largest contentful paint and lazy-load below-the-fold media. The goal is a smaller, more stable page without hiding important visual information.
5. Test forms, notifications, and email routing.
Submit every public form with realistic data and verify the complete path: browser response, server acceptance, spam protection, notification delivery, stored record, confirmation message, and team ownership. Check required fields, validation, keyboard use, mobile layout, error handling, and duplicate submission behavior.
Use an approved sending domain and configuration when email delivery is involved. Do not assume a successful browser message proves that the lead reached the team. Confirm the destination and response process, then remove test records when appropriate. If analytics is approved, fire the conversion event only after a genuinely successful submission.
6. Review security and update responsibilities.
Remove unused accounts, limit privileges, protect configuration files, and keep administrative paths separate from the public experience. Confirm the supported software and PHP versions, update policy, malware controls, and certificate renewal. Do not install unapproved plugins or tools merely to solve a narrow delivery problem.
Decide who owns WordPress core, theme, plugin, server, and application updates after launch. Schedule updates with backups and verification rather than leaving them unattended. Public error pages should not expose stack traces, paths, secrets, database details, or private configuration.
7. Add monitoring and inspect server behavior.
Monitor uptime, certificate expiration, storage, failed form requests, server errors, and unusual traffic at a level appropriate for the site. Review access and error logs after launch. A clean visual check can miss repeated 404s, blocked assets, PHP warnings, or redirect patterns that only appear under real requests.
Verify response status, content type, cache policy, compression, canonical URL, robots directives, and sitemap inclusion for every important route. Use both desktop and mobile testing. The homepage essentials guide can help confirm that the first screen still communicates the offer after technical launch changes.
8. Run a controlled release and final crawl.
Publish the smallest coherent release, clear only the caches that need clearing, and test the canonical URLs immediately. Check navigation, internal links, images, forms, metadata, structured data, robots.txt, sitemap.xml, 404 behavior, redirects, and any route that was intentionally removed.
Compare the live files or checksums with the tested release, record the deployment time, and keep the backup until the site has remained stable. Submit or recheck the existing sitemap in Search Console when the URL set changes. A launch is complete when the public site verifies, the team can receive customer actions, and the rollback remains available.