A website launch is more than publishing pages: it is the point when customers, search engines and your team begin relying on the site. A page can look finished while a contact form fails, a mobile menu hides key links or a change made just before launch breaks something elsewhere. A deliberate pre-launch check helps catch these issues while there is still time to fix them. Start by confirming who approves the launch, which version is final and how you will restore the previous site if a critical problem appears. Then test the complete customer journey on the devices and browsers your audience uses, not just the homepage on your own computer. Check that forms reach the right inbox, links lead to the intended destination and important business details are accurate. Review search visibility, privacy and security basics, backups, analytics and post-launch monitoring as well. This checklist is designed for small businesses preparing a new website or major redesign. Adapt it to your platform and features: an online shop, booking system or membership site needs additional end-to-end checks before accepting real customers.
Content
Confirm launch readiness
Set a clear go-live decision
Before changing the live site, make sure everyone is referring to the same finished version. Record the site or staging address, the date it was reviewed and any agreed changes still to be made. Ask the person responsible for approving the website to confirm in writing that this is the version to launch. If changes are made after approval, note them and agree whether they need another review; otherwise, a last-minute edit can leave the launch team working from different versions.
Define what “ready” means for your business. List any tasks that must be complete before launch, such as receiving approval for the site content or confirming who can access the systems needed for the change. Separate these launch blockers from improvements that can safely wait. Give each remaining task an owner and a due date, and record who can make the final go/no-go decision. This helps prevent an unresolved issue from being mistaken for a minor follow-up.
Agree on people, timing and recovery
Write down who is responsible for each part of the launch. For example, one person might approve the site, another might coordinate the technical change, and a business contact might be available to check that the site is operating as expected. Name a point of contact for questions and confirm how the people involved will communicate during the change. If a developer, hosting provider or domain registrar needs to be involved, confirm their role and availability in advance rather than assuming they can respond at short notice.
Choose a launch window when the relevant people can pay attention and respond if something goes wrong. Consider your normal operating hours, planned promotions or busy periods, and any third-party support hours that matter to the change. Allow time for the work and post-launch checks; do not schedule it so tightly that there is no opportunity to investigate an unexpected issue. If the domain’s DNS settings will change, remember that the update may not appear everywhere immediately, so agree how you will check the site during that period.
Before launch, confirm what can be restored and who would carry out the recovery. Identify the current live site, its files and database, and any settings or content that could change during the launch. Check when the backup was made, where it is stored, who can access it and whether it covers the items needed to restore the site. A backup is not a rollback plan unless the team knows how to use it: where practical, verify the restoration process in a safe test environment, or have the responsible technical person confirm the steps and dependencies. Do not assume that restoring the website alone will reverse separate changes to domain settings, email or external services.
Record the recovery decision in advance: who can call for a rollback, what signs would trigger that decision, and who will tell the business and its customers if service is affected. Keep the final approved version, launch contacts, planned timing and recovery instructions together where the people involved can find them. With these decisions agreed, the team can start the launch with a shared plan rather than relying on memory or rushed messages.
Test pages and key journeys
Follow each path as a real visitor would
Start from the pages people are likely to enter through, not just the homepage. Click every important navigation link, button and text link, including links in the footer. Check that each goes to the intended page, opens correctly and does not lead to an error or an old version of the site. For external links, make sure the destination is still relevant. If a link is meant to jump to a section on the same page, confirm it lands in the right place. Give extra attention to calls to action: a “Get a quote” button, for instance, should take visitors to the correct form or contact details, rather than simply looking clickable.
Then complete the actions yourself, from the visitor’s first click through to the confirmation. Test forms with a normal submission and with common mistakes, such as leaving a required field empty or entering an invalid email address. Check that the form explains what needs fixing and retains any information already entered where appropriate. Confirm the submitted details reach the intended inbox or system, arrive in a readable format and include enough information to respond. Check any automatic reply and the on-screen confirmation as well; they should set a clear expectation about what happens next without promising an unconfirmed response time.
Use a dedicated test email address and clearly identifiable test details, so you can recognise and remove test submissions without confusing them with genuine enquiries. Check spam and junk folders if a message does not appear, and confirm the sender and reply-to details make sense. If the form collects personal information, verify that its fields and consent wording match what the business actually needs and how it handles enquiries. Avoid sending sensitive real customer information through a test.
Check bookings and checkout through to confirmation
Where the site accepts bookings or orders, test the whole sequence: select a service or product, choose an available option, enter the required details and proceed to the final confirmation. Check that displayed dates, prices, quantities and other conditions match the business’s actual settings. Try a realistic error path too, such as an unavailable time or an incomplete delivery field, and make sure the next step is clear. Confirm that a completed booking or order appears in the relevant business system, if one is used, and that the customer receives the expected confirmation with accurate details. Test any cancellation, rescheduling or refund steps that are important to the journey.
For payments, use the provider’s test mode or another controlled procedure where available. Do not make a real charge just to check a flow unless the business has agreed how it will be handled and reversed. Verify that failed or abandoned payments do not appear as completed orders, and that customers can see a clear outcome if payment is declined. Never assume a payment is successful based only on the browser returning to a confirmation page; check the relevant order or booking record as well.
Record each test, its result and any issue that needs fixing. Retest the complete journey after a change, because adjusting a form, button or payment setting can affect steps that previously worked. Treat broken routes, missing submissions, incorrect confirmations and unclear payment outcomes as launch blockers. Once these are resolved, keep a note of any lower-priority improvements to review after launch, rather than leaving visitors to discover avoidable problems for you.
Check mobile and accessibility
Test the experience on small screens and without a mouse
A page that looks tidy on a desktop can become difficult to use on a phone. Check the site at common narrow, medium and wide screen sizes, including a phone and tablet if available. Use both a browser’s responsive preview and real devices where possible: previews help you inspect dimensions quickly, while a physical device can reveal awkward scrolling, slow-to-use controls or text that is hard to read. Check key page types, not just the homepage, and look for clipped text, overlapping elements, unexpected horizontal scrolling and images that push important content out of view.
Follow the main navigation on each size. Confirm that menus open and close as expected, the menu button is easy to identify and use, and links remain visible without requiring precise tapping. Try the site in portrait and landscape orientation. Make sure important actions, such as contacting the business or requesting a quote, are easy to find and that visitors can return to the main navigation without repeatedly scrolling to the top. Check that buttons and links have enough space around them to select comfortably, especially when several controls sit close together.
Read through headings, paragraphs, labels and button text on a phone. Body text should be comfortably legible without pinching to zoom, and line lengths and spacing should make longer passages easy to follow. Check that visitors can enlarge text using browser zoom or their device’s text settings without content being cut off or controls becoming unusable. Images should scale appropriately; where an image conveys information, provide a useful text alternative, and avoid relying on colour alone to communicate a status or instruction.
Then put the mouse aside and navigate with the keyboard, using Tab and Shift+Tab to move through links, buttons and form fields, and Enter or Space to activate controls. The focus indicator should remain visible so users can tell where they are. Check that focus follows a logical order, does not get trapped in a menu or other component, and can reach every interactive element. If a menu, dialog or expandable section is present, test opening it, moving through its controls and closing it using the keyboard as well as touch.
Give forms particular attention on both mobile and desktop. Each field should have a clear, persistent label rather than relying only on placeholder text. Test selecting options, entering text, moving between fields and submitting the form with a keyboard. Check that required fields and errors are explained in words, are easy to locate, and do not disappear before a visitor can correct them. Confirm that the page identifies which field needs attention and preserves information already entered where practical. Try the form with enlarged text, and ensure the on-screen keyboard does not obscure the field or submission control.
Automated accessibility checkers can flag some issues, but they cannot judge every part of the experience. Combine them with hands-on checks and, where possible, feedback from people who use assistive technology. Record problems by page, screen size and steps to reproduce them, then fix barriers that prevent visitors from reading content or completing essential tasks before launch.
Review search and measurement
Review search and measurement before launch
Check that search engines can find the pages you want people to discover, and that important pages have clear, accurate titles. Review each page title and meta description for relevance and duplication; describe the page honestly rather than repeating keywords. Also check headings and page content so they reflect what the page offers. These details help present useful information in search results, but they do not guarantee a particular ranking or display.
Confirm that the live site is not accidentally carrying over a setting that tells search engines to exclude it. During development, a site or page may be marked as not to be indexed. Check the relevant WordPress settings and any SEO plugin settings, then review the site’s robots.txt file and sitemap. Make sure the sitemap points to the preferred live domain and contains pages you want indexed, not private, duplicate or unfinished pages. If you use a search engine’s webmaster tools, verify the live site there and submit or check its sitemap as appropriate.
If the new site replaces an existing one, compare its URLs with the old site before switching over. Create a redirect for each old address that has moved, sending visitors to the closest relevant new page. Permanent moves generally call for a permanent redirect, such as a 301. Test redirects in a browser and check that they reach the intended destination without looping or passing through unnecessary extra redirects. Look for broken internal links and make sure any old URLs that should no longer exist return a deliberate not-found page rather than an unrelated page. Keep the redirect record so it can be updated if a problem appears.
Decide what you need to learn from measurement before configuring analytics. For example, a business might want to count completed enquiry-form submissions, phone-number link clicks or visits to a booking confirmation page. These are hypothetical examples; choose actions that match your actual goals. Define what counts as a completed action and where it should be recorded, then test it on the live site. Check that ordinary page views and the chosen events are being recorded once, not missed or duplicated. Avoid treating a button click as a completed enquiry if the form can still fail or be abandoned.
Review any consent and privacy requirements that apply to the tools you use, including what data is collected and how visitors are informed. Confirm that analytics works with your consent settings, where relevant, and that your privacy information accurately describes the tools in use. Don’t assume that a tracking script is working simply because it has been added to the site: use the tool’s available testing or real-time reports, and check the result from a separate browser session where practical.
Record the settings and results you check, including the intended titles, indexing status, redirect destinations and measured actions. This gives whoever manages the site a clear reference if search visibility or reporting looks different after launch. If a key page is blocked from indexing, a redirect leads to the wrong place or an important action is not recorded, resolve it before launch where possible. Otherwise, document the issue, its owner and the next check so it is not forgotten once the site is live.
Secure the launch
Check security and ongoing care
Before launch, confirm that visitors reach the site over HTTPS and that the browser shows a valid security connection. Check the certificate is current, and test that the HTTP version redirects to HTTPS so visitors and search engines are directed to the secure address. Review key pages and forms for browser warnings or content that still loads over an insecure connection. If anything looks wrong, ask your hosting provider or developer to investigate before launch rather than dismissing the warning.
Review who can sign in to WordPress and what each account can do. Give people only the access they need for their work, remove accounts that are no longer required, and check that administrator accounts belong to trusted people. Use unique, strong passwords and enable multi-factor authentication where it is available. Make sure someone responsible for the site knows how to access the WordPress dashboard and hosting account if urgent action is needed.
Check that WordPress, its theme and its plugins are up to date. Remove software the site does not use, and avoid installing updates blindly just before launch: check the site afterwards, especially navigation, forms and other important functions. If you can test updates on a staging copy first, do so. Keep a record of what was changed and who is responsible for handling future updates. Do not assume that an update has been applied correctly just because the dashboard reports it is complete; verify the site still works.
Confirm that a recent backup exists and that you know how to restore it. Find out what the backup includes, where it is stored and who can access it. A backup held only in the same place as the live website may not be enough if that environment becomes unavailable. If possible, verify the restore process in a safe test environment. Agree who will initiate a restore and how the team will decide whether to roll back after a serious launch problem.
Review the site’s privacy information against what it actually does. Check that it explains the personal information collected through forms, bookings or purchases, why it is collected and how people can contact the business about it. Confirm that forms ask only for details the business needs, and check any relevant cookie or third-party service disclosures. Keep the wording accurate and seek appropriate advice if you are unsure about your privacy obligations; a copied policy may not reflect your site or business.
Finally, make a simple post-launch monitoring plan. Name the person who will check the site, specify when checks will happen during the first few days, and decide where issues should be reported. Check that the homepage and key pages load, forms reach the right destination, and important visitor journeys still work. Watch for reports of errors, broken links, unusual sign-in activity or missing enquiries. Note how to contact your developer or host, and record unresolved issues with an owner and next action. This makes it easier to respond promptly without assuming every problem will be spotted automatically.
Conclusion: launch with confidence
Once testing is complete, review the findings with the people responsible for the website. Classify issues by impact: a broken enquiry form or checkout may stop customers completing an essential task, while a minor spacing issue may not prevent launch. Agree which problems must be fixed before going live, who will fix them and how you will confirm the correction. If a critical issue remains, delay the launch or agree on a safe, practical workaround rather than assuming it will resolve itself.
Record outstanding lower-priority tasks in a shared list, with an owner and a date to review each one. Note any temporary workaround so staff know what to tell customers and how to report a problem. Before launch, confirm who has authority to proceed and who will take action if the site needs to be reverted.
After the site goes live, check key pages and customer journeys again using a phone and a computer. Test important forms, review any available error or uptime reports, and confirm that the intended measurement tools are recording activity. Keep a clear route for staff and customers to report issues, then triage and document them promptly. A launch is a checkpoint, not the end of website testing.
Explore related information: Booking Website Design & Development; Web Design Sunshine Coast.
