Choose the domain visitors use#
In Websites, use the public hostname customers visit, such as shop.example.com. Enter a domain without a page path, administration path, port or IP address. A protocol and trailing slash can be normalised, but a bare hostname is the clearest input.
example.com and www.example.com are different hostnames. Choose the one where the public website actually serves its pages. The crawler follows same-host links; a redirect to a different hostname can prevent collection. There is no self-service alias-domain editor in the portal. Contact Reesponder before expecting an installation to work on an additional hostname.
Add the website#
- Confirm the selected workspace and active access.
- Open Websites and enter Website name and Domain.
- Select Start automatic setup.
- Open the website from the list to see its status and tools.
Adding a website queues its first crawl and prepares its installation record. Core allows one non-removed website; Business and Scale allow multiple. A site_limit_reached error means the workspace cannot add another website on that plan.
Separate installation from Knowledge#
Widget detected means a valid installation check was received from the configured domain. Installation pending means that check has not yet been received. Last seen records the last verified installation check.
The Knowledge state comes from website processing. Its crawl can be queued, running, completed or failed while installation has a different state. A detected widget is not proof that its Knowledge is complete; a successful crawl is not proof that the widget was published.
Use the website's tools#
- Installation: follow the recognised platform's instructions or the manual snippet flow.
- Knowledge: review the crawl, inspect site and shared sources, add entries and choose Crawl again.
- Private test: create the five-question Knowledge preview.
- Appearance: configure feedback and any appearance options included by the plan.
- Journey events: available on Scale for defining real server-sent outcomes.
- Settings: remove the website with explicit domain confirmation.
If the website does not become ready#
Open the public website after publishing the installation, clear its page cache and refresh the status in Reesponder. If Knowledge failed, inspect the error in the Knowledge tab and verify that the homepage is public, reachable and on the selected hostname.
Do not repeatedly replace installation code to refresh status. Replacement changes the installation token and requires every manual snippet to be updated. Existing WordPress or connected Shopify installations use their own guarded connection flow. See the installation guide for platform-specific instructions and Knowledge troubleshooting for source failures.
Worked example: a platform preview differs from production#
A developer edits the storefront in a platform preview that uses a different hostname from the published shop. Chat appears in that preview, but the business's registered website is the public production domain. The developer publishes the intended integration and tests the final customer-facing hostname before reporting the release complete.
If the platform serves a preview through a different origin, do not assume that registering one brand domain authorises every preview and alias automatically. Keep preview and production evidence labelled. The connected source, installation record and intended domain should all refer to the actual website being launched. Ask support about a legitimate additional hostname rather than placing another store's credentials into the preview.
Keep the website inventory usable during a release#
For each active site, record its final public hostname, installation method, source owner and intended connected capabilities. Confirm the selected record before copying a snippet or saving an appearance change. A meaningful website name makes this easier when several stores share one workspace.
After a theme or routing release, revisit important public routes and update the inventory with the observed result. A Last seen value establishes a valid installation check, but it is not an audit of every page on the domain. The worked readiness cases below explain how to separate a missing loader, incomplete content and an unavailable connected operation.
Plan the domain and source scope before setup#
Open the final customer-facing address before registering the website. An apex address can redirect to its www host; a theme editor can run on a platform preview domain; an administrator address can be entirely different from the storefront. Observe where the public browser ends after redirects. There is no customer alias-domain editor that silently authorizes every variation, so choose the actual host deliberately rather than assuming all versions of a brand name are interchangeable.
For two stores, decide which information is common and which is different. A shared company description or general contact route may apply to both. A returns policy with different regional conditions often belongs to the individual website. Do not put conflicting policies into a single unqualified shared entry and expect the assistant to guess which applies. If an entry is deliberately shared, write its applicability clearly and test representative questions from both websites after a change.
Keep a small website inventory: meaningful name, final public hostname, installation method, source owner and intended connected capability. A second website does not receive a separate workspace usage pool. An order integration is not automatically copied from another store, either. The inventory gives colleagues enough information to select the right site before editing sources, appearance or Actions. It also prevents a future theme release from copying the installation code of a similarly named but different store.
A worked example of partial readiness#
Imagine automatic setup has collected 25 policy and product documents, but Installation still says pending. The next action is to publish the integration on the registered host and visit it; re-crawling will not add the missing script to your template. Conversely, imagine Widget detected is shown but the delivery policy is missing. The valid load proves installation evidence, not source coverage. Open Knowledge and review what was actually collected.
A third case is a detected widget with a correct public-policy answer but a failed private order request. Investigate the website-specific Action, its current tested revision, connection permissions and ownership checks. Replacing the installation token is not a remedy for an endpoint that refuses an unauthorized order. If the business has not enabled that connection, present the supported contact or explanation route instead of claiming a live lookup is already available.
Last seen is installation evidence from a valid load, not a visitor count or a full-route audit. Test the homepage and a second important route after a router or template change. If only the homepage contains the snippet, a detected website can still leave product pages without the launcher. Record readiness by capability: installation, relevant content, representative answer and each intended connected workflow. This is a more useful launch record than one blanket statement that the website is green.
Maintain a multi-site workspace without accidental copying#
When updating a shared source, choose test questions from every affected business context. For example, a shared delivery entry should not accidentally promise a destination offered by only one regional store. Compare the source's scope and explicit conditions with the websites it serves. Do not rely solely on the title; read the text available to the assistant. Site-specific sources help keep distinct policies and product information appropriately separated.
Maintain each site's connection independently. A provider token or endpoint may be authorized for one store, and the website's enabled Action must be tested for its own intended operation. Appearance belongs to the selected website as well. If a colleague sees an unexpected avatar or policy, check the workspace and site selected before assuming a save failed. Source corrections should be performed in the library; presentation changes in Appearance; installation changes in the relevant platform or template.
For a retired site, remove its active record and its frontend integration deliberately. Re-adding the same hostname creates a fresh identity with new installation credentials rather than restoring the old one. Historical retained conversations and billing records have their own lifecycles. Keep retired configuration notes clearly marked and remove usable old credentials from shared handover material. If a site is unexpectedly absent, first confirm workspace selection and retirement history before creating a near-duplicate record that makes the maintenance problem harder to understand.
Need help with this?
Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.