Add a LoopReply AI Agent to a website by publishing its reviewed configuration, copying the generated script from Website Embed, and installing that script once on the site. Then test an actual visitor conversation. The instructions below show the interface and the shape of the embed, with example identifiers instead of a live widget key.
1. Prepare the Agent and one source
Open the Agent you want visitors to use. Give it a narrow job and attach approved business information in Knowledge. Wait for the source to become ready before testing answers. If you need a first configuration, use the no-code bakery walkthrough.
Ask a question answered by the source and another it cannot answer. Correct unsupported answers before installation. The missing-knowledge test provides sample expectations.
2. Review and publish the draft
In Architect Studio, check Settings and Workflow, then inspect Versions. Instructions, appearance, and workflow changes remain drafts until Publish. Knowledge and model-context settings such as language and response style are live settings, so check these separately.
This real interface uses illustrative data. Versions displays stored draft and published states and saved changes; it is not a historical rollback system. After publishing, confirm the Agent is active.
3. Copy the generated website script
Open Website Embed for that same Agent. The page displays its generated code and platform instructions.
The screenshot's identifiers are examples. Copy your own generated values from the dashboard. The HTML has this structure:
<script
src="https://widget.loopreply.com/loader.js"
data-agent-id="YOUR_AGENT_ID"
data-api-key="YOUR_PUBLIC_WIDGET_KEY"
defer
></script>Replace both example values. The widget key is intended for the public embed; a database password, model-provider key, or private store API key does not belong here. Configure the allowed website domains in the dashboard and include the domain you are testing.
4. Install it in one place
For an HTML site, paste the generated script before the closing body tag. For a managed website builder, use its supported footer or custom-code area and publish the site. Confirm your plan permits JavaScript embeds.
For WordPress, use a maintained footer-script integration or your site's established code-insertion process. Avoid changing a parent theme file that an update will overwrite. WordPress.com and self-hosted installations can have different code permissions; use the WordPress-specific guide.
For Next.js, the Deploy page offers a Next.js snippet using the framework's Script component. Add it to the relevant layout once. Remove any old installation of the same widget before testing, including a duplicate installed through a tag manager.
A store embed displays the conversation. It does not itself provide order access. See the WooCommerce buyer and integration guide or Shopify shortlist if that is your next requirement.
5. Verify the published page
Open a fresh browser session on desktop and a phone. Open the launcher, type a source-backed question, send it, and check the reply. Reload and revisit the conversation. If you configured human support, request a person and verify the receiving inbox.
Check that the widget does not cover navigation, checkout, or the cookie controls. Run the test with your site's real caching, consent, and script-optimization configuration enabled. A test on an otherwise blank page cannot establish compatibility with your production theme.
If the launcher or answer is missing
| Symptom | First check |
|---|---|
| No launcher | Confirm loader.js loaded and the script is present only once |
| Loader blocked | Review consent rules, browser blocking, and the site's content security policy |
| Wrong Agent appears | Compare data-agent-id with the selected Agent's generated snippet |
| Access rejected | Check the generated widget key, active state, and allowed domain |
| Old greeting appears | Review the published workflow message and appearance fallback |
| Source-backed answer is missing | Check that the source is ready and attached to this Agent |
Use browser developer tools or ask your website maintainer to inspect failed network requests. Do not disable the entire content security policy to make the widget appear; authorize only the resources the installation needs.
Keep a short launch record containing the tested URL, device, Agent, publish time, question, and result. It gives the next person a concrete starting point if the site changes.