Test your website chat widget from first message to team reply, including mobile layouts, keyboard access, domain setup, and performance regressions.
A chat widget is ready for launch when a visitor can find it, send a message, and receive the right team's reply without losing access to the rest of the website. Seeing the launcher in a browser is only the first check.
Use the checklist below on a staging page or another controlled test environment before a wider rollout. Keep a visitor browser and a team inbox open separately. Use fictional test messages, and record the page URL, browser, device, expected result, and actual result for any failure.
These are checks to perform, not a statement that any particular widget passes them. Test the version and configuration you intend to use.
1. Verify the installation and destination
Copy the generated snippet from the intended workspace. Check the widget ID and domain configuration against that workspace, especially if you operate multiple products. For tkit.ai, the installation guide explains the snippet and initial setup.
Send a message with a unique label such as “Staging pricing-page test.” Confirm that it arrives in the expected inbox and that a reply appears in the visitor's browser. If you have multiple workspaces, verify that the message did not land in a different product's inbox.
Repeat on an ordinary internal page, not just the homepage. In an app with client-side navigation, move between routes without reloading. Check for a missing launcher, duplicate widgets, or an unexpected reset of the conversation.
2. Test a complete conversation
Send more than a greeting. Use a short question, a longer message, punctuation, and a link. Reply from the inbox, send a follow-up from the visitor, then close and reopen the widget. Check that message order and visible text make sense.
Refresh the page and navigate elsewhere on the same site. Record which parts of the conversation persist. Then close the visitor tab before the team replies and test the return journey. Do not assume cross-device history or email notifications are available.
If the result differs from your support promise, fix the promise or the setup before launch. “Leave us a message” needs a workable way for the customer to receive the answer.
3. Check small screens and competing controls
Test on an actual phone as well as a resized desktop window. Open the keyboard and type a multi-line message. Check that the input, send button, and close control remain reachable. Rotate the device and zoom the page.
Look for conflicts with cookie notices, sticky navigation, checkout buttons, and other floating controls. The launcher should not cover the action the customer came to complete. After closing chat, confirm that scrolling and the underlying page still work.
Try both a short page and a long page. A position that works at the top of a landing page may obscure a footer link or mobile purchase button elsewhere.
4. Use the widget without a mouse
Starting on the page, use the keyboard to reach the launcher, open chat, enter text, send a message, and close the panel. Track focus throughout. You should be able to tell which control is active and continue using the page afterward.
W3C's keyboard accessibility guidance explains why functionality needs a keyboard-operable route. Include a check that focus does not become trapped in the widget.
Test with a screen reader where possible. Listen for meaningful names for the launcher, text field, send button, and close control. Check how incoming replies and submission errors are communicated. A visual inspection or automated scan alone is not a complete accessibility assessment.
5. Exercise failures and recovery
Use browser developer tools to simulate a slow connection, then temporarily disconnect the test browser. Try sending a message and restoring connectivity. Check whether the interface distinguishes a pending message from a delivered one and whether retrying creates duplicates.
Also load the page when the widget script cannot load. The website's main navigation, forms, and purchase or signup flow should still be usable. Keep an appropriate alternative contact route visible if chat is unavailable.
Record failures precisely. “Message appeared locally but never reached the inbox after reconnecting” gives the developer a better starting point than “chat is broken.” Avoid entering real customer details in diagnostic captures.
6. Compare performance before and after
Measure the same representative pages with and without the widget under similar conditions. Check initial loading and the experience after opening chat, typing, and receiving a reply. Repeat measurements so one unusually slow run does not become your conclusion.
Google's Web Vitals guidance distinguishes loading, interactivity, and visual stability. It also explains why lab testing and real-user measurements serve different purposes. A standard Lighthouse page-load run does not measure Interaction to Next Paint because it contains no user interaction; use suitable interaction testing and field data as available.
Treat loading strategies as implementation choices to verify. An asynchronous script can still consume network and main-thread resources once it runs.
7. Write down the launch decision
Keep a short record of the tested pages and devices, successful message round trips, known limitations, and unresolved failures. Give each blocking issue an owner in your team's existing task tool. This record can be a simple document; it does not require built-in chat analytics or assignment features.
Before expanding the rollout, confirm that someone knows how to remove or disable the integration if it interferes with the site. Repeat the critical checks after changing the snippet, workspace, domain, or major page layout.
For tkit.ai, start with the widget setup guide and use separate workspaces where products need separate conversations. Then test the deployed experience from both sides. The launch decision should rest on a working conversation and a usable website.