Table of Contents
Run every item below before you point DNS at a new WordPress build. Verify by loading the live domain in a clean incognito window, checking that pretty permalinks return 200, that the contact form delivers mail, that a test restore works, and that search engines are either blocked or correctly indexed. If all 26 checks pass and staging equals production, you are safe to launch.
Permalinks and Robots
Go to Settings > Permalinks and pick Post name (/%postname%/) so URLs are readable and stable. On Apache ensure mod_rewrite is enabled and the site root has an .htaccess file WordPress can write. On Nginx add the try_files rule inside your server block. Then open https://example.com/robots.txt and confirm it is served.
Why it matters
Default ?p=123 links hurt click-through and migrate badly. A missing or wrong robots.txt can either block your whole site or expose staging paths.
How to do it
For Nginx use:
location / {
try_files $uri $uri/ /index.php?$args;
}
Flush rules in PHP with flush_rewrite_rules(); once via a mu-plugin, then delete it. For robots, place a physical robots.txt in the web root or use the robots_txt filter.
Verify and roll back
Visit a single post; it must return HTTP 200 with no query string. curl -I https://example.com/sample-post/. If you get 404, restore the old .htaccess from your pre-change copy and re-save permalinks. For a deeper look at server-level rewrites see Deploy WordPress on Baota LNMP: Root, Perms, Rewrites.
Cache and CDN
Install a page-cache layer and put static assets behind a CDN before launch. On the server use Nginx FastCGI cache or Redis object cache (plugin Redis Object Cache 2.5+ in 2026). Set browser caching for wp-content/uploads and confirm the CDN pull zone serves CSS and JS.
Why it matters
Uncached PHP execution on every request will time out during traffic spikes; a misconfigured CDN can serve stale HTML to logged-in users.
How to do it
Get a Quote
Email + requirement + budget range — we reply with a quote within 24 hours.
In wp-config.php enable:
define( 'WP_CACHE', true );
define( 'WP_REDIS_HOST', '127.0.0.1' );
Exclude /wp-admin/, /cart/, /checkout/ and any page with a unique nonce from full-page cache.
Verify and roll back
Load the homepage twice; the second response header should show X-Cache: HIT or x-proxy-cache: HIT. If admins see other users’ data, purge cache and disable the page-cache plugin; keep Redis for objects only. Our WordPress CDN Setup Tutorial: Vendor Guide 2026 covers vendor specifics.
Forms and 404s
Test every contact, quote and newsletter form on the live domain. Use SMTP (not PHP mail()) via a plugin like WP Mail SMTP 4.x with an API transport. Submit a real entry and confirm delivery in the inbox, not just the “sent” message.
Why it matters
Forms silently fail when DNS lacks SPF/DKIM or when the host blocks outbound port 25. Broken 404s lose leads and crawl budget.
How to do it
Add a DNS TXT record for SPF and check with dig TXT example.com. Then browse to a nonsense URL like /does-not-exist; the theme’s 404.php must render with navigation and a search field.
Verify and roll back
Send a test with a unique string (e.g. launch-test-2026) and grep the mailbox. If mail fails, switch the plugin transport to a different provider API key; never leave mail() as fallback in production. For spam-proof patterns read Building a Foreign-Trade Inquiry Form in WordPress.
Backups and Monitoring
Take a full file+database backup immediately before DNS cutover and schedule automatic ones. Store copies off-server (S3, Backblaze B2). Enable uptime monitoring (UptimeRobot or Better Stack) on the homepage and /wp-login.php.
Why it matters
Post-launch edits and plugin updates are the top cause of fatal errors; without a verified restore you have no safety net.
How to do it
From shell:
mysqldump -u user -p dbname > site-$(date +%F).sql
tar czf wp-$(date +%F).tar.gz /var/www/html
Store the tarball in object storage with a 30-day lifecycle.
Verify and roll back
Restore the dump into a scratch database and run wp search-replace to confirm URLs swap cleanly. If the live site white-screens after launch, restore files and DB from the pre-cutover set and lower DNS TTL beforehand to 300s for fast rollback. Details in WordPress Site Backup and Restore: Vendor Guide 2026.
Search Engine Visibility
In Settings > Reading uncheck Discourage search engines from indexing this site for production. Confirm robots.txt does not contain Disallow: / for the live host, and submit the XML sitemap from your SEO plugin (Yoast 24.x or Rank Math 1.0.2xx in 2026) to Google Search Console.
Why it matters
A leftover staging block hides the site from Google for months; a missing sitemap delays discovery of new pages.
How to do it
Check the meta tag:
<meta name='robots' content='index, follow' />
Then curl https://example.com/sitemap_index.xml must return XML with 200.
Verify and roll back
Use Search Console URL Inspection → “Test live URL”; it should say “Indexing allowed”. If you accidentally left blocking on, uncheck it, purge cache, and request re-indexing; there is no rollback needed beyond that flip.
Step-by-Step Launch Process
- Finalize permalinks and serve robots.txt on the live domain.
- Enable page cache, object cache and CDN; purge and verify HIT headers.
- Submit every form with SMTP and fix 404 template rendering.
- Take a verified restorable backup, then lower DNS TTL and cut over.
- Remove search-engine block, validate sitemap, and monitor uptime for 24h.
Action Checklist
- Pretty permalinks return 200 with no query string.
- Cache HIT on second anonymous load; admin excluded.
- One real form email received with SMTP.
- Off-server backup restored successfully in a scratch DB.
- Search Console reports “Indexing allowed”.
Need expert help executing this checklist? Our Custom WordPress Development team ships launch-ready builds. See more guides at our technical articles index.
Frequently asked questions
How early should I set up backups?
Set them up before any content edit on production and always take one right before DNS change, then test the restore.
Why is my CDN serving stale pages?
Full-page cache is being applied to logged-in or nonce URLs; purge and exclude those paths from the CDN cache rule.
What if permalinks break after launch?
Restore the previous .htaccess or Nginx config, re-save Settings > Permalinks, and flush rewrite rules once.
