WordPress Launch Checklist: Set Up and Launch a Website

1. Prepare a recoverable launch

Before a domain switch or migration, keep a backup of the database and files and confirm how to restore it. Record the current URLs, the intended launch URL, who owns the domain and who can resolve hosting problems. Keep the staging copy available until the live site has passed its checks.

Example: A local business is replacing its old services website. List the old service URLs before changing anything, then map each one to its relevant replacement. A redirect to the homepage is rarely a helpful substitute for a specific service page.

2. Review the WordPress setup

You can do the setup manually or use the Launch Setup & Checklist WordPress plugin. Install its ZIP through Plugins → Add New → Upload Plugin, activate it, then open Tools → Launch Setup & Checklist.

1. Select the starter pages you need: Home, About, Services, Contact and Blog. Existing pages with those slugs are reused without replacing their content. New pages default to drafts.
2. Review the site title, tagline and timezone. Choose whether to create a WordPress navigation menu. Keep existing permalinks on an established site unless you have a migration plan.
3. Select Preview setup and inspect the proposed changes. Apply this setup performs only that reviewed plan. If relevant pages or settings change before applying, generate a fresh preview.
4. Edit the draft starter pages and build their layouts in your theme or Oxygen interface. Publish them when their content is ready. Then preview a setup assigning a published Home page as the homepage and a published Blog page as the posts page.
5. Use the plugin’s shared checklist to record verified checks, custom tasks and notes. Save before exporting CSV.

Activation does not run setup. The plugin provides a starter structure, not finished copy, forms, legal documents or Oxygen layouts. Its checklist is saved in the WordPress database and shared between administrators; the browser tool stores a separate project in your browser.

In Settings → General, review the site title, tagline, timezone and administrator email. Treat the WordPress Address and Site Address as migration settings: do not change them merely to complete a checklist.

For a business site with a dedicated homepage, use Settings → Reading to select the homepage and, if needed, a separate posts page. Verify the actual frontend because a theme or builder template can affect the result.

Review Settings → Permalinks. Choose the URL structure early on a new site. On an existing site, changing it is a migration task requiring a plan for old URLs and redirects; avoid changing a working structure at launch simply because another option looks cleaner.

References: WordPress: create a static front page and WordPress: permalink settings.

3. Check discovery and URL consistency

On the public site, review Settings → Reading → Search engine visibility. The production site should allow discovery when it is ready; a staging site needs its own access and indexing policy. Allowing indexing does not confirm that a search engine has indexed a page.

• Inspect a real page’s robots meta tag and canonical URL.
• Open the sitemap and check that important published pages appear.
• Test the preferred HTTPS domain and any alternative domain redirects.
• Open an old URL and verify its destination. Also test a deliberately missing URL and the 404 page.

Use the WordPress Internal Link Checker to inspect stored same-site links. Its report complements these checks; it does not evaluate every dynamic link or prove indexing.

Reference: WordPress: managing Reading settings.

4. Test the tasks visitors need to complete

Submit a genuine test contact request. Confirm validation, the success message, inbox delivery and any connected service. Test downloads, phone links and booking actions on the devices visitors use.

If analytics is configured, verify the events you need using its testing tools. Where consent applies, test acceptance, rejection and changed preferences. A tracking script appearing in the source is not proof that the right event reaches your reports.

Add project-specific tasks to the checklist rather than forcing them into a generic item. For the business example, “receive a booking confirmation email” and “test the map destination” are useful additions.

5. Check Oxygen through its interface

Open representative pages in Oxygen and check the layout at the available responsive breakpoints. Use the builder’s controls to adjust spacing, typography, image sizing and link destinations. Then test the published frontend with actual content.

• Operate menus, buttons and forms with a keyboard and check visible focus.
• Use a narrow screen to find overflowing images, cramped columns and long labels.
• Select suitable image dimensions and inspect the result at the intended display size.
• Check a second post or page that uses each shared template; one successful preview can hide missing dynamic data.

The Image Optimizer plugin can create smaller image copies. After saving, select the new attachment in the Oxygen Image element’s media control and recheck cropping. The plugin preserves existing references, so saving a copy does not replace the image on a page.

6. Launch, retest and hand over

After the site moves to its final domain, repeat the form, redirect, indexing-setting and navigation checks there. Clear relevant caches and use a logged-out session to see what visitors receive. Keep any unresolved issue visible in the project notes.

Export the checklist project as a reusable backup or export CSV for the handover. Assign an owner for updates, backups and ongoing link checks. A completed checklist records the work you verified; it does not automatically certify accessibility, legal compliance or search rankings.

Open the launch checklist tool and start with the project you are preparing to publish.