Why use a WordPress launch checklist?
Launch day is when small oversights become expensive. A forgotten “Discourage search engines” checkbox keeps a site out of Google for weeks, a missing redirect map throws away years of rankings after a redesign, and a contact form that cannot send email loses leads silently. None of these are hard to fix — they are just easy to forget when everyone is focused on the design.
This checklist collects 44 pre-launch checks in the order most teams work through them: WordPress settings, security, SEO, performance, content, legal pages, analytics and backups, and finally cross-browser, mobile and accessibility testing. Each item explains why it matters and how to do it, and links to the generator on this site that handles the task when there is one.
Items are tagged Essential (do not launch without it) or Recommended (do it at launch or in the first week). Progress is saved in your browser, and the exported Markdown report doubles as a sign-off document for clients.
How to use the WordPress Launch Checklist
- Start a few days before launch on the staging site — most items can be completed there. Filter by Essential if time is short.
- Tick items as you go; groups show their own progress and can be collapsed when finished.
- On launch day, re-check the items that change when the domain changes: search engine visibility, URLs in the database, SSL, redirects, robots.txt and the sitemap.
- Add the site name, launch date and notes, then copy or download the Markdown report as a record of what was verified.
Example
Typical wp-config.php constants for a production launch:
define( 'WP_DEBUG', false );
define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_POST_REVISIONS', 10 );
define( 'WP_ENVIRONMENT_TYPE', 'production' );Launch-day order of operations
- Take a final backup of staging and put the old site (if any) into maintenance mode.
- Migrate files and database, then run a serialisation-safe search-replace of the staging URL.
- Install SSL, force HTTPS and the canonical host, and deploy the redirect map from old URLs — see the WordPress Redirect Generator.
- Uncheck “Discourage search engines”, check robots.txt and submit the sitemap in Search Console.
- Purge all caches, test forms and checkout, and watch the error log and analytics for the first 48 hours.
Frequently Asked Questions
What is the most common WordPress launch mistake?
Leaving Settings → Reading → Discourage search engines from indexing this site checked after moving from staging. It adds a noindex robots meta tag to every page, so Google drops or never indexes the site.
Do I need redirects if I am launching a redesign on the same domain?
Yes, whenever any URL changes — new slugs, a different permalink structure, merged pages or a new shop structure. Map every old URL that has traffic or backlinks to its new equivalent with a 301 redirect.
Is the progress shared with my team?
No. Progress is stored in your browser only. To share it, export the Markdown report and paste it into your project tool or send it to the client.
Which items can be done on staging before launch?
Nearly all of them: content, forms (with a test mail catcher), security hardening, caching rules, image optimisation, accessibility and browser testing. Domain-dependent items — SSL, search engine visibility, sitemap submission and redirects — must be re-checked on the live domain.
What should I do after launch?
Switch to a regular maintenance routine: backups, updates, security and performance checks. The WordPress Maintenance Checklist organises them by weekly, monthly and quarterly frequency.