WordPress Pre-launch Checklist

By Wangdada Labs Editorial Published July 27, 2026 Reviewed July 27, 2026

Use this checklist before a new WordPress site or migration begins receiving production traffic. It is a verification aid, not a guarantee of availability, security, accessibility, search visibility, legal compliance, or business results.

The checkboxes run only in this browser tab. They are not submitted, stored, tracked, or restored after a refresh. Use the print button to create a paper copy or save a local PDF without providing an email address.

Scope note: the Wangdada Labs local non-production rehearsal did not test real DNS delegation, public TLS issuance, production email delivery, CDN behavior, payment processing, or live traffic. Those items must be verified in the actual production environment.

Benchmark & Verification Baseline - Audit Reference: WordPress 6.6+ production stack, PHP 8.2/8.3 official runtime requirements (WordPress Hosting Requirements). - Evaluation Date: Updated 2026-09-04 with multi-region DNS cutover and TLS termination protocols. - Primary Focus: Minimizing post-migration downtime, avoiding mixed content lockouts, and securing rollback capability.

1. Backup and restore readiness

Create a fresh backup of both the WordPress database and site files.
Store at least one usable copy outside the production hosting account.
Record the backup time, timezone, scope, location, and person responsible.
Confirm the backup includes uploads, themes, plugins, configuration, and any custom directories.
Confirm database exports include every required WordPress and application table.
Test a restore in a non-production destination or document why a test is not possible.
Record the exact rollback trigger, decision owner, and restore procedure.
Keep the old environment unchanged until the acceptance window has passed.

WordPress treats files and database as separate parts of a complete backup. Review the official WordPress backup guidance and use the hosting backup, migration, and support evaluation guide to verify the provider's restore boundary.

2. HTTPS and transport security

Verify the production hostname has a valid certificate with the expected names.
Confirm HTTP requests redirect once to the preferred HTTPS canonical URL.
Check representative pages for mixed-content warnings.
Verify WordPress Address and Site Address use the intended HTTPS URL.
Confirm certificate renewal ownership and the alert path for renewal failure.
Check that security headers do not block required first-party assets or forms.
Avoid enabling HSTS for broader subdomains unless every affected host is ready.

3. Canonical URLs and redirects

Choose one preferred hostname and URL form.
Confirm each indexable page has one self-referencing canonical URL.
Map every important old URL to one relevant new URL with a permanent redirect.
Remove redirect chains, loops, and redirects to unrelated pages.
Verify media, internal links, menus, structured data, feeds, and sitemaps use production URLs.
Check that staging hostnames and temporary paths do not appear in source HTML or the database.
Crawl a representative set of old and new URLs before changing traffic.

Follow the full website migration checklist when a launch changes hosting, domain, path, or URL structure.

4. Robots, sitemap, and Search Console

Remove temporary noindex directives from pages intended for search.
Keep private, duplicate, administrative, and non-public environments excluded as intended.
Confirm robots.txt returns 200 and does not block required CSS, JavaScript, or indexable content.
Confirm the XML sitemap returns 200 and lists only canonical, indexable URLs.
Add the sitemap URL to robots.txt.
Verify the production property in Google Search Console using an approved method.
Submit the sitemap once and record the submission time and actual processing state.
Use URL Inspection for a small set of critical pages and distinguish Requested, Discovered, Crawled, and Indexed.

Google documents canonical signals, redirects, robots controls, and sitemap submission in its official Search documentation.

5. Forms and transactional email

Submit every public form with valid data and confirm the success state.
Test required fields, invalid data, duplicate submission behavior, and error messages.
Confirm the intended recipient receives the message from an independent external mailbox.
Verify the visible sender, reply-to address, subject, and body are correct.
Check spam or quarantine folders and review provider delivery logs when available.
Test password reset, account notices, order messages, and other transactional email in scope.
Confirm sensitive form data is not exposed in URLs, analytics, logs, or notification subjects.
Document who monitors failed delivery after launch.

Remove unused administrator accounts and shared credentials.
Give each user the minimum role required for current work.
Enable multifactor authentication where the chosen system supports it.
Rotate temporary migration, developer, SFTP, database, API, and registrar credentials.
Verify recovery email addresses and account ownership.
Update WordPress core, themes, and plugins after confirming compatibility and rollback.
Remove inactive software that is not needed for launch.
Confirm automatic-update policy, maintenance owner, and emergency patch process.
Review the official WordPress hardening guidance without treating any single control as complete security.

7. Performance and accessibility

Test representative pages on a mobile connection and a desktop connection.
Check the largest images, fonts, scripts, third-party embeds, and cache behavior.
Verify navigation, dialogs, forms, and interactive controls work with a keyboard.
Confirm visible focus styles and a logical heading structure.
Check text contrast, zoom, reflow, alternative text, labels, and error identification.
Test at 375px, 768px, and a desktop width for page-level horizontal scrolling.
Run Lighthouse or equivalent diagnostics and investigate failures rather than chasing a score alone.
Include people and assistive technologies in testing when the site's risk and audience require it.

The W3C Web Accessibility Initiative explains that automated checks cover only part of accessibility evaluation. Use its official evaluation resources as a starting point.

8. Privacy and cookies

List every form, account feature, cookie, analytics tool, advertising tag, embedded service, and log source.
Remove tools that are not necessary for launch.
Confirm the public privacy notice matches actual production behavior.
Verify consent behavior where consent is required for the site's audience and jurisdiction.
Confirm retention, deletion, access, and incident contacts.
Avoid collecting sensitive data unless the business process and safeguards require it.
Check that staging or test data is not exposed in production.
Obtain qualified legal advice for legal obligations; do not treat this checklist as legal advice.

9. Logs, monitoring, and rollback

Confirm application, web server, security, and provider logs are available to the responsible operator.
Remove debug output and prevent sensitive values from being written to public logs.
Configure availability, certificate, domain-expiry, backup-failure, and error alerts as appropriate.
Name the person who receives each alert and the escalation contact.
Define the launch monitoring window and the metrics or user actions to watch.
Record the previous known-good deployment, database backup, DNS values, and rollback commands.
Confirm rollback does not destroy new production data without an explicit decision.
Schedule the first post-launch backup and review.

10. DNS and traffic cutover

Export or screenshot the current DNS zone before changes.
Confirm access to the authoritative DNS provider and registrar.
Review A, AAAA, CNAME, MX, TXT, CAA, verification, and service-specific records.
Lower TTL in advance only when the timing and provider behavior justify it.
Confirm the destination responds correctly before changing public traffic.
Change only the records required for the cutover.
Resolve the production hostname from multiple networks or resolvers.
Verify the old destination remains available during the rollback window.
Check email and third-party verification records were not lost during a nameserver change.

11. Launch ownership and final sign-off

Name the person authorized to approve launch.
Name the person authorized to trigger rollback.
Record the change window, expected user impact, and communication channel.
Freeze content or document how changes will be synchronized during migration.
Confirm business-critical paths: contact, login, checkout, payment, booking, download, or API actions in scope.
Record unresolved risks and the person accepting each risk.
Save the completed checklist with the deployment, backup, and source revision identifiers.
Recheck the site after DNS caches, scheduled jobs, email delivery, and monitoring have had time to operate.

12. Frequently Asked Questions

What are the most critical technical checks before taking WordPress live?

The three non-negotiable verification gates are: (1) an off-server database and uploads backup with tested restore capability, (2) automated HTTPS redirect without mixed content errors, and (3) a verified robots.txt and XML sitemap that do not accidentally block search engines.

Why is an off-site backup required if the host provides daily backups?

Hosting-managed backups frequently share the same physical server or user account. If the account is suspended for resource overuse, hacked, or suffers filesystem corruption, local backups are inaccessible. An off-site export (e.g. to Amazon S3, Cloudflare R2, or remote SFTP) guarantees business continuity.

How do I verify DNS cutover without experiencing cached records?

Use external multi-location DNS resolvers (such as Google 8.8.8.8, Cloudflare 1.1.1.1, or dig +trace) rather than local browser cache. Lowering the TTL to 300 seconds (5 minutes) 24 hours prior to cutover ensures global resolvers refresh rapidly once new IPs are published.

If the launch changes your operating model, use the Small Website Hosting Total Cost Calculator to include maintenance time, backup services, support, and migration work in the decision.