Most WordPress launch checklists stop at “install an SSL certificate” and “submit your sitemap.” Those are right, but they are the business owner’s checklist. This one is for developers — the person responsible for what happens in wp-config.php, at the database level, and in the server configuration before DNS changes hands.
For the non-technical post-launch tasks a site owner should handle, see the essential post-launch WordPress checklist. This guide covers what that one doesn’t.
wp-config.php: constants to set before DNS cutover
wp-config.php is the first place to audit on a handover or self-launch. Several constants that are correct in development become liabilities in production.
WP_DEBUG must be off. define('WP_DEBUG', false); is the production default. If WP_DEBUG is still true, PHP notices and warnings are written to the HTML output — visible to users, visible to scanners. WP_DEBUG_LOG should also be false, or at minimum redirected to a path outside the web root. A debug.log file in wp-content/ is publicly accessible by default and leaks path information.
Disable file editing. define('DISALLOW_FILE_EDIT', true); removes the Appearance → Theme Editor and Plugins → Plugin Editor menus from wp-admin. This is not primarily a UX decision — it prevents an attacker who gains wp-admin access from using the editor as a code execution path. It takes one line and there is no reason to skip it.
Force HTTPS. If your site runs entirely over HTTPS (it should), add both of these:
define('FORCE_SSL_ADMIN', true);
$_SERVER['HTTPS'] = 'on';The second line is necessary if you are behind a reverse proxy or load balancer that terminates SSL — without it, WordPress may generate HTTP URLs internally even though the browser sees HTTPS.
Limit post revisions. define('WP_POST_REVISIONS', 5); caps revision storage at 5 per post. The default is unlimited. A site with 200 posts and two years of active editing can have 30,000+ revision rows in wp_posts before anyone notices. Set this before launch rather than cleaning up later.
Set memory limit explicitly. define('WP_MEMORY_LIMIT', '256M'); overrides the PHP memory limit for the WordPress process. The default 40M is too low for most sites running ACF, WooCommerce, or any plugin with large admin screens.
Change the table prefix. If you didn’t change the default wp_ prefix during installation, automated SQL injection tools targeting the default prefix will still work against your site. Changing it after installation requires a search-replace across every table name and a wp-config.php update, but it’s worth doing on any site that will store sensitive data.
Database: InnoDB, indexing, and pre-launch cleanup
The default database engine for WordPress tables should be InnoDB, not MyISAM. InnoDB supports row-level locking (better for concurrent writes), foreign key constraints, and crash recovery. Check your table engines in phpMyAdmin or via WP-CLI:
wp db query "SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND ENGINE != 'InnoDB';"If any tables come back as MyISAM, convert them:
wp db query "ALTER TABLE wp_options ENGINE=InnoDB;"Run this for each returned table. On managed hosts like Kinsta and WP Engine, InnoDB is enforced already — but on shared hosting or a custom VPS setup, check it manually.
Before launch, run a database cleanup with WP-Optimize or via WP-CLI to remove transients, spam comments, trashed posts, and orphaned post meta. An inherited site can have thousands of leftover rows from deactivated plugins that stored option data but never cleaned it up on deactivation. Check the wp_options table size specifically — autoloaded options are loaded on every page request, and a bloated autoload set affects every page, not just the ones querying those options.
Check autoload data size:
wp db query "SELECT SUM(LENGTH(option_value)) as total FROM wp_options WHERE autoload='yes';"If this returns more than 1MB, find what’s in there before going live. Common culprits are transients that should have been stored with expiry but weren’t, and plugin settings that accumulate without cleanup.
Staging-to-production migration
The most common place a launch breaks is the URL migration. WordPress stores the site URL in wp_options and bakes it into serialised data throughout the database. A search-replace that misses serialised structures corrupts those structures silently — the site loads but widgets, menus, ACF fields, and widget data disappear or render incorrectly.
Use WP-CLI’s built-in search-replace, which handles serialisation correctly:
wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tables --preciseRun with --dry-run first to see what would change. Run without it only when you have a database backup taken within the last 10 minutes.
After search-replace: flush rewrite rules (wp rewrite flush), clear all caches (WP Rocket, object cache, server-level), and verify the siteurl and home values in wp_options are correct.
File permissions on the production server should be 644 for files and 755 for directories. The wp-config.php file should be 600 (owner read/write only). Check that wp-content/uploads is writable (WordPress needs to write media files) but that PHP execution is disabled in that directory — add an .htaccess file to wp-content/uploads with php_flag engine off if your server supports it.
Object caching: Redis vs Memcached
WordPress without object cache persistence re-runs every database query on every page load. On a site with ACF fields, a custom theme making multiple get_field() calls, and WooCommerce session data, the query count per page load is substantial. A persistent object cache stores the results of expensive queries in memory and serves them from RAM on subsequent requests.
Redis is the better choice in almost all cases. It supports data structures beyond simple key-value pairs, persists to disk (meaning the cache survives a restart), and supports clustering. Memcached is simpler and marginally faster for pure cache-hit scenarios, but its lack of persistence means a server restart costs you the full cache warm-up period.
To enable Redis with WordPress, install the Redis Object Cache plugin and add to wp-config.php:
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);Verify it’s connecting: in the plugin dashboard it shows connection status and cache hit ratio. A hit ratio below 60% on a warm cache suggests either the cache is being invalidated too frequently or the cache keys are too granular.
Managed hosts (Kinsta, WP Engine, Cloudways) include Redis as a one-click toggle — enable it before launch rather than after, so the first load after go-live benefits from the cache rather than warming it.
Caching and CDN: pre-launch configuration review
Page caching and CDN configuration both have launch-specific gotchas that don’t surface in staging.
WP Rocket, LiteSpeed Cache, and W3 Total Cache all need cache exclusion rules for logged-in users, WooCommerce cart and checkout pages, and any URL with query parameters that affect output. Staging environments often have these configured loosely — verify the exclusion rules in the production environment explicitly rather than assuming the staging config transferred correctly. See the WP Rocket vs LiteSpeed Cache comparison for how these handle exclusions differently.
Cloudflare proxy (orange cloud, not grey): confirm the DNS record is proxied after cutover. With Cloudflare active, clear the Cloudflare cache immediately after any wp-config.php or theme change — Cloudflare caches at the edge, independently of WordPress page cache, so a stale edge cache can persist even after WordPress cache is cleared.
If you are using Cloudflare, also verify that Cloudflare’s Rocket Loader is not deferring scripts that need to run in a specific order. It’s a common source of JavaScript errors on production that don’t appear in staging (where Cloudflare is often not proxying).
Security headers and server hardening
WordPress handles application-level security; the web server handles transport-level. Both need to be right before launch.
HTTP security headers to verify are in place — check via securityheaders.com after DNS is live, or via curl locally on staging:
- Strict-Transport-Security (HSTS):
max-age=31536000; includeSubDomains— tells browsers to only connect over HTTPS for the next year. Only add after you’re certain the site will never need to serve HTTP. - X-Frame-Options: SAMEORIGIN — prevents the site from being loaded in an iframe on external domains (clickjacking protection).
- X-Content-Type-Options: nosniff — stops browsers from MIME-type sniffing responses.
- Referrer-Policy: strict-origin-when-cross-origin — controls what referrer information is sent with outbound requests.
These go in your .htaccess (Apache) or nginx server block. Wordfence does not add security headers — that is the web server’s responsibility.
Hide the WordPress version: remove the generator meta tag by adding remove_action('wp_head', 'wp_generator'); to functions.php. This does not make an unpatched site safe, but it removes the version signal from automated scanners.
Disable XML-RPC if you are not using Jetpack or any tool that requires it. Add to .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>For a comprehensive look at the attack vectors hitting WordPress sites in 2026, the essential WordPress security practices guide covers credential stuffing, plugin supply-chain attacks, and the specific configuration changes that address them.
WP-CLI verification pass
A WP-CLI pass before or immediately after cutover catches configuration drift between staging and production that manual review misses.
# Confirm plugin versions match staging
wp plugin list --format=csv
# Check scheduled cron jobs for staging URLs baked in
wp cron event list
# Verify siteurl and home are set correctly
wp option get siteurl
wp option get home
# Confirm no users with 'admin' username remain
wp user list --field=user_login | grep -i admin
# Check autoloaded option size
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';"
# Flush rewrite rules
wp rewrite flush --hardThe cron event check is easy to forget. If a staging cron job was registered with the staging URL in its arguments (common with WooCommerce email jobs or backup plugins that store the site URL in the scheduled event), it will either fail silently or — worse — fire correctly but send emails or process data against the staging URL on the production server.
Core Web Vitals: what to measure before launch
PageSpeed Insights lab data is available immediately on a staging URL. Real-user field data (Core Web Vitals from the Chrome User Experience Report) takes 28 days to populate for a new URL and requires minimum traffic thresholds. Plan for this gap.
Run PageSpeed Insights on your staging URL before DNS cutover and record your LCP, INP, CLS, and TTFB scores as a pre-launch baseline. The first thing to check after launch is whether the production scores match staging — a score that drops more than 10 points between staging and production usually means Cloudflare Rocket Loader, a third-party script that only fires on the production domain, or a caching configuration that differs from staging.
LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1 are Google’s passing thresholds. If you are not passing on staging, you will not pass in production — and the field data that populates in Search Console over the following 28 days will confirm it. Fix performance issues on staging before cutover, not after. The WordPress performance guide covers the specific changes that move each CWV metric.
DNS cutover: the sequence that avoids problems
DNS changes are the point of no return. The sequence that minimises risk:
24-48 hours before: Lower your DNS TTL to 300 seconds (5 minutes). This reduces propagation time when you make the actual change, so a rollback can be effective within minutes rather than hours. Most DNS providers allow TTL changes independently of A record changes.
Immediately before cutover: Take a full database backup on staging. Confirm the production server is fully configured — SSL certificate installed, server software confirmed, caching active, security headers in place. Do not make configuration changes after the DNS change is live.
After DNS propagates: Flush Cloudflare cache if applicable. Run your WP-CLI verification pass. Submit the production sitemap to Google Search Console (add the property if you haven’t already). Run PageSpeed Insights on the production URL. Test all forms end-to-end from a real email address.
Rollback plan: Keep the staging server running and pointing to the old database for at least 72 hours after cutover. If something breaks in production that cannot be fixed immediately, reverting the DNS A record to the staging IP brings the old site back within 5 minutes (given the lowered TTL). After 72 hours with no issues, decommission staging.
Staging cleanup checklist
Before or immediately after launch, remove the development artifacts that should never be in production:
- Delete all test user accounts and any account with username “admin” or “test”
- Remove any development or staging plugins (Query Monitor, Debug Bar, WP Migrate DB, staging-specific backup configurations)
- Confirm WP_DEBUG, WP_DEBUG_LOG, and SCRIPT_DEBUG are all false in wp-config.php
- Remove any .htpasswd basic auth that was protecting the staging environment
- If the staging URL was previously submitted to Google Search Console, block it in robots.txt or remove the property to prevent it from being indexed alongside production
- Delete sample pages, sample posts, and “Hello World” if they still exist
- Verify the default WordPress favicon has been replaced
After launch, ongoing maintenance — plugin updates, backup verification, security scan reviews, and Search Console monitoring — is the job that continues indefinitely. The complete WordPress maintenance guide covers the recurring tasks and their correct frequency. If you are handing the site to a client, a maintenance care plan transfers that responsibility without the client needing to manage it themselves.
If something breaks in the first 48 hours after launch and a restore is not straightforward, emergency rescue with same-day response is available. For sites that need performance work after the initial launch — LCP failing, slow WooCommerce checkout, Lighthouse below 80 — WordPress speed optimisation covers the full audit and fix at a fixed price.
