WordPress launch checklist
WordPress Go-Live Checklist
Launch a WordPress site that works for visitors, can be found in Google, and can be restored fast.
Checked against current WordPress guidance · Updated August 2026
Catch failures before users do
Finish with a public site that a stranger can use, Google can read, and you can restore without guessing.
Get these ready first
- WordPress admin and hosting access
- The production domain or a final staging copy
- A real test email and sandbox payment method when needed
Run the WordPress go-live checks
Ticking steps needs JavaScript. Every step is readable without it.
Publish the right WordPress site
One HTTPS address shows the final content and no launch leftovers.
Step 1Use one HTTPS WordPress address
How to do it- Open Settings → General. Confirm WordPress Address and Site Address use the intended HTTPS host.
- Open the bare domain, www domain, HTTP URL, and old staging URL in a private browser.
- Redirect every public variant to one production URL. Keep staging password-protected or noindex.
Pass when: One HTTPS host remains in the address bar, and the old public variants cannot serve a duplicate site.
Avoid the common failure
Mixed hosts can break logins, cookies, media, redirects, and canonical URLs.
If it goes wrong: Changing DNS while WordPress Address still points to staging or HTTP.
Step 2Remove every launch leftover
How to do it- Search pages, posts, reusable blocks, menus, widgets, footer, media alt text, and SEO fields for lorem ipsum, TODO, demo, sample, and coming soon.
- Delete unused sample pages, posts, comments, users, and media. Do not only remove them from the menu.
- Open every public URL from the navigation and sitemap, including the 404 page and empty search results.
Pass when: No public route shows filler copy, demo records, fake proof, dead controls, or a coming-soon screen.
Avoid the common failure
WordPress themes and imports often leave sample posts, fake comments, disabled buttons, and coming-soon settings behind.
If it goes wrong: The homepage is clean while an imported sample post remains public and indexable.
Protect the WordPress control room
Core code is current, admin access is intentional, and a restore path works.
Step 3Clear updates and Site Health
How to do it- Create a fresh backup, then open Dashboard → Updates and update WordPress core, the active theme, plugins, and translations.
- Delete plugins and themes the site does not use. Deactivated code still remains on the server.
- Open Tools → Site Health. Fix every Critical issue and record any recommended item you defer.
Pass when: Dashboard → Updates is clear, unused code is removed, and Site Health shows no Critical issue.
Avoid the common failure
Old core, theme, plugin, PHP, or HTTPS problems can turn into launch-day failures or security holes.
If it goes wrong: Updating the active plugins but leaving an old inactive plugin installed.
Step 4Lock down every admin account
How to do it- Open Users → All Users. Remove old accounts and give each person the lowest role that fits their job.
- Give each administrator a unique password and enable two-factor login through the host or a maintained security plugin.
- Revoke unused Application Passwords and integrations. Never share the main admin password with a service.
Pass when: Every Administrator has a named owner, a current reason for access, a unique password, and two-factor login where available.
Avoid the common failure
One reused password or forgotten contractor account can bypass every public-site safeguard.
If it goes wrong: Changing the shared admin password while leaving the shared account and old application credentials active.
Step 5Prove the backup can restore
How to do it- Create a fresh backup that includes the database and wp-content files.
- Store a copy outside the live host and record its date, size, retention, and encryption or access owner.
- Restore it to staging, or walk through the host restore screen and record the exact first three recovery steps.
Pass when: A fresh off-server backup exists and a named person has completed a staging restore or a verified restore drill.
Avoid the common failure
A backup receipt does not prove the database, uploads, theme, plugins, and configuration can return together.
If it goes wrong: The host saves only the database or keeps every backup on the same server as the live site.
Step 6Test the contact form end to end
How to do it- Submit the public form while signed out with a real test email.
- Check the success state, saved entry, owner notification, visitor confirmation, and spam folder.
- Try invalid input and a fast double-click. Show a useful error and do not save a duplicate.
Pass when: One valid message reaches the owner and visitor once, while invalid input cannot create a false success.
Avoid the common failure
A green form message means nothing if WordPress never stores the lead or sends the email.
If it goes wrong: The form works for an administrator but mail from the production domain fails for a real visitor.
Help Google find the right pages
Production pages are crawlable, and one useful visitor action is counted once.
Step 7Open the site to Google
How to do it- Open Settings → Reading and clear Discourage search engines from indexing this site.
- Open Settings → Permalinks, choose the final URL pattern, and save it before links are promoted.
- Give each key page one clear title, description, H1, and canonical. Open robots.txt and the XML sitemap on the production domain.
Pass when: Public pages are indexable, use permanent URLs, and appear under the production host in a working sitemap.
Avoid the common failure
A single staging checkbox can ask search engines to ignore the entire production site.
If it goes wrong: The SEO plugin looks green while WordPress still has the sitewide discourage setting enabled.
Step 8Connect Google and count one lead
How to do it- Verify the production property in Google Search Console, submit the XML sitemap, and inspect the homepage plus one key page.
- Install one analytics tag through one plugin or theme method. Remove duplicate copies.
- Name the main action as a conversion, trigger it from a private browser, and add the required privacy or consent notice for the audience you serve.
Pass when: Search Console accepts the sitemap and one real test action appears once in analytics.
Avoid the common failure
You need proof that Google can inspect the site and that the main visitor action reaches analytics once.
If it goes wrong: The same tag is installed through the theme and a plugin, so every action is counted twice.
Make launch day recoverable
The site works without a mouse or wide screen, and the owner can reverse a bad change.
Step 9Fix phone and keyboard blockers
How to do it- On a real phone, open the homepage, key landing page, menu, form, and checkout or account page.
- Use only the keyboard to reach every link, control, and form field. Keep focus visible and labels clear.
- Fix horizontal scroll, clipped text, blocked taps, missing image text, unreadable contrast, and large images that stall the first screen.
Pass when: A phone and keyboard user can read the key pages and finish the main action without a blocking issue.
Avoid the common failure
A mobile menu, cookie bar, form, or checkout can block the whole visitor path even when the desktop homepage looks fine.
If it goes wrong: Testing the homepage at mobile width but never opening the menu, validation errors, or checkout.
Step 10Write the launch and rollback note
How to do it- Record the production URL, launch date, WordPress and PHP versions, active theme, critical plugins, and any deferred issue.
- Add the backup location, first restore step, analytics property, Search Console property, support owner, and hosting contact.
- Schedule a seven-day check for form mail, orders, Site Health, analytics, crawl errors, and real visitor questions.
Pass when: A second person can identify the live release, find the backup, and start rollback from one short note.
Avoid the common failure
When a plugin update breaks production, chat history and memory are too slow.
If it goes wrong: The only recovery instructions live inside the WordPress site that is currently broken.
Questions before you publish
What should I check before WordPress goes live?
Check the final HTTPS address, remove sample content, clear updates and Site Health, lock admin access, prove the backup restores, test the real form or checkout, open the site to Google, and record the rollback path.
How do I let Google index WordPress?
Open Settings → Reading and clear Discourage search engines from indexing this site. Then verify the production sitemap and key pages in Google Search Console.
Is a WordPress backup plugin enough?
Only if the backup includes the database and files, stays outside the live server, and can be restored. Run a staging restore or a documented restore drill before launch.
What this checklist cannot prove
- A clean Site Health screen is not a security audit.
- A submitted sitemap does not guarantee Google will index or rank a page.
- A backup does not help until someone can restore it.
See the platform sources
- WordPress Site Health reports critical configuration, security, HTTPS, update, and server issues under Tools → Site Health. Read the source
- WordPress recommends current core, plugin, and theme versions and a backup before updates. Read the source
- WordPress roles limit what each account can do, and Administrator access covers the whole single site. Read the source
- WordPress documents separate database and file backups, which must stay together for a full restore. Read the source
Spot something outdated? Send a correction.