WordPress launch checklist
A WordPress site is ready to launch when it can be restored, updated and monitored. Finished pages alone do not make it ready. Before opening it to visitors and search engines, verify administrative access, backups, software versions, HTTPS, indexing settings, forms, analytics, performance and the rollback path.
Scope and limitations
This checklist covers a conventional public WordPress site. WooCommerce, memberships, multilingual workflows, learning systems, custom plugins, external identity providers and regulated data need additional application-specific tests. The checklist does not certify security, accessibility, privacy or legal compliance.
Use a staging copy for changes where possible. Never test email, payment or destructive maintenance actions against real customer data without an approved plan.
Phased WordPress launch checklist
1. Recovery and ownership
- Create a fresh database and file backup and restore it to a separate environment.
- Confirm who controls the domain, DNS, hosting, WordPress administrator accounts and recovery email.
- Remove temporary administrator accounts and assign the least privilege needed for each role.
- Record the active theme, plugins, PHP version, scheduled tasks and external integrations.
- Write a rollback trigger and identify the person authorised to use it.
2. Security and software state
- Update WordPress core, the active theme and required plugins after testing compatibility.
- Remove unused themes and plugins instead of leaving inactive code behind.
- Use unique administrator accounts, strong passwords and multi-factor authentication where supported.
- Confirm HTTPS works without mixed content and that sensitive pages are not cached publicly.
- Review Site Health and investigate warnings rather than hiding them.
3. Content, search and functionality
- Check that the site is allowed to be indexed at launch and that staging restrictions are absent.
- Set the preferred permalink structure before URLs are promoted or indexed.
- Verify one clear H1, titles, descriptions, canonical URLs, sitemap output and meaningful image alt text.
- Submit every public form and confirm delivery, validation, consent text and error handling.
- Test navigation, search, 404 pages, redirects, social previews and important mobile layouts.
4. Performance and operations
- Measure representative pages on mobile and desktop before enabling additional optimisation layers.
- Optimise oversized images and reserve intrinsic image dimensions to reduce layout shifts.
- Enable caching carefully and exclude dynamic or personalised pages where required.
- Configure uptime, error and security-event monitoring appropriate to the site.
- After launch, recheck backups, logs, analytics, Search Console and real form delivery.
WordPress launch FAQ
Should “Discourage search engines” remain enabled?
No for a public launch. The setting is a request rather than an access control, so staging should also be protected separately. Verify the rendered production robots directives after changing it.
Is an available backup enough?
No. A useful backup must be recent, protected and restorable. A test restoration is the strongest practical check that the files, database and instructions work together.
Should every optimisation plugin be enabled before launch?
No. Establish a functioning baseline first, then add and measure one layer at a time. Multiple overlapping cache, image or script optimisers can make failures harder to diagnose.