Website launch checklist: what to test before going live

1. Confirm who controls the website

List the domain registrar, DNS provider, host or builder, business mailbox and WordPress administrator. They may be different services. Record who is responsible, where renewal notifications arrive and whether recovery works if a contractor leaves. Keep passwords and recovery codes in an appropriate private store, never in a public launch checklist.

Give collaborators their own appropriate access rather than sharing the owner’s login. Check that the person responsible for the website can remove temporary access later. If the business cannot recover its domain or hosting account, resolve that dependency before investing in a launch campaign.

Our guide to keeping the domain account under business control explains this ownership problem in more detail. This check concerns control, not a recommendation to transfer every service to one supplier.

2. Test the final domain, HTTPS and email together

Open the intended public address as a logged-out visitor. Try the address with and without www, then follow an old link if the site replaces an existing one. Record whether visitors reach the intended destination without a warning or a loop. Test important internal links rather than assuming a successful homepage proves every address works.

WordPress documents HTTPS as encrypted browser-to-server communication. Ask the host or builder to confirm the certificate and secure setup for the actual production address. Then check images, downloads, forms and login pages at that address. A certificate is not a substitute for trustworthy content or secure account management. Avoid pasting server rewrite rules from a tutorial without understanding your host’s configuration.

A website move can also affect business email. Identify the active DNS provider and preserve the records needed by the existing mailbox. Verify inbound and outbound email using addresses you control. Follow the domain connection guide before changing DNS, and the WordPress migration guide if this is a replacement website. Do not cancel the old service until its remaining responsibilities are understood.

3. Review the pages people need to trust you

Read the homepage, main service or product pages, About page, contact information and footer as a new visitor. Within a short scan, a reader should understand what the site offers, who it serves and the next useful step. Replace draft text, broken images, sample addresses and claims that nobody can substantiate.

Follow a complete route from a guide to its recommended next step. A button saying “See this plan” should reach that plan or a clearly relevant destination. Describe commercial relationships where they exist, and keep editorial recommendations separate from payment. Do not show partner badges, review scores or customer counts that have not been earned and verified.

Prepare privacy information for the services and data the site actually uses. Check ownership and permission for images, logos and other assets. Requirements vary with the business and its audience; a copied policy cannot confirm that your real arrangement has been covered.

4. Walk through the site without the editor

Use a normal logged-out browser on a phone and a larger screen. Start at the homepage, open a category or service, read one article, use search if available, and return using the main navigation. Check the footer, menu expansion, pagination and one address that does not exist. A missing page should help the visitor recover.

Navigate with the keyboard as well. Check that focus remains visible, the menu can be used, headings make sense, links describe their destinations and form fields have visible labels. Enlarge text and check whether the reading order and controls remain usable. Review meaningful image alternatives and contrast in the actual design.

W3C’s accessibility evaluation overview explains why automated tools need human judgment. Treat these checks as a first review and record problems; a good automated score alone does not establish accessibility conformance. If important journeys remain difficult for some visitors, fix them before launch and seek a deeper evaluation where appropriate.

5. Complete every form and confirmation path

For an inquiry form, submit a realistic test using an inbox you control. Check the validation, success message, destination mailbox and reply process. Confirm that the message contains enough information to respond, but does not expose data unnecessarily. A green success notice on the webpage is not evidence that the recipient received the email.

If delivery fails, use the contact-form email troubleshooting guide. Test the error path too: an empty required field, an invalid address and a submission that cannot be completed should produce understandable feedback. Do not send repeated test inquiries to real customers or unrelated recipients.

If the site has a newsletter, verify signup, any confirmation step, welcome delivery and opt-out separately. The first newsletter walkthrough distinguishes an editor preview from the subscriber journey. Keep any untested or unapproved collection path disabled until it has been checked.

6. Make recovery practical

A typical WordPress backup needs both files and the database. Confirm what your chosen backup actually includes, where it is stored and how it can be retrieved if the live site or hosting account is unavailable. Match the backup schedule to how much recent work the business can afford to lose.

Rehearse restoration in a separate appropriate test environment and record the result. Do not overwrite the live site merely to tick a box. Check that the restored pages, media and required settings are present; then document the steps and person responsible. A backup timestamp proves that a job ran, not that recovery succeeded.

Read how to make a WordPress backup you can restore for the detailed workflow. Review included host backups before buying another service, but assess retention, separate access and restoration needs rather than treating “backup included” as sufficient on its own.

7. Check WordPress health and realistic loading

In WordPress, review Tools → Site Health. Investigate critical issues and identify who will handle recommended improvements. Its technical information can help an authorized maintainer troubleshoot, but review what you share and avoid posting private diagnostic details publicly.

Check representative pages, not just an empty homepage: an image-heavy article, a comparison table and the contact page. Use a phone and an ordinary connection where possible. Look for images that delay reading, controls that jump as the page loads, menus that fail and overlays that cover the main task. Record the page and condition for each problem so a fix can be retested.

Site Health, a speed score and one successful load answer different questions. None alone establishes that the website is secure, fast for every audience or ready for its main business journey. Keep the launch evidence tied to the checks actually performed.

8. Separate private testing from public discovery

While the site is being built, keep access restrictions appropriate to its private status. WordPress’s Reading settings include an option to discourage search engines, but WordPress explicitly notes that this does not block normal visitors. Private previews require access protection, not merely a request about indexing.

When public launch is authorized, review the production site’s intended search visibility. Check the homepage choice, important public URLs, page titles and any remaining staging addresses. Ask the maintainer to review the actual noindex and crawl configuration rather than relying on one checkbox. Keep genuinely private or unfinished material out of the public release.

Google’s SEO Starter Guide emphasizes useful content, understandable organization and relevant links. A sitemap and Search Console can support discovery and diagnosis; they do not buy a ranking or guarantee index inclusion. Give each public page a distinct purpose instead of launching many nearly identical pages.

Common launch questions

Do I need every planned article before going live?

No fixed article count makes a site ready. Launch a coherent set that answers its visitors’ main questions, remove empty destinations and keep additional articles in draft until reviewed. Expand from real gaps and later search data, not an arbitrary publishing target.

Must analytics be active on day one?

No. Plan what you need to learn, confirm account ownership and review the collection and privacy setup before activation. A functioning site with measurement still pending is preferable to unreviewed tracking. The companion measurement guide explains the options.

Should I buy a new tool for every checklist item?

First identify what the host, builder and existing tools already provide. Check their actual limits and the recovery or support process. Our domain, email and hosting bundle comparison helps avoid paying twice for overlapping services.

Your next step

Choose one complete visitor journey and test it from entry page to outcome. Resolve any stop condition, record the evidence, then repeat on the final production address when release is authorized. Keep the detailed guides linked above for the areas that need work. Use the visitor measurement and Search Console guide to prepare the next stage without enabling services prematurely.