Refleks

Refleks documentation

Install Refleks on your website

The dashboard generates a site-bound widget script, detects common platforms, and checks the published output after you deploy.

Before you begin

A few checks prevent the most common setup dead ends.

  • Create an account and verify its email address. Email verification is required before adding a site or starting a crawl.
  • Use a publicly reachable website URL. The crawler does not sign in to a website or use a customer’s session cookies.
  • Have access to your site’s global layout, footer, theme, custom-code area, or tag manager. The script must load on every page where you want the assistant.

1. Add and index a site

  1. Open the dashboard and choose Add a site.
  2. Enter the published URL and an optional name. The URL becomes the crawl origin; its hostname determines the crawl boundary.
  3. Choose Crawl and index. The initial job is queued after ownership, plan, cooldown, and daily-cap checks.
  4. Watch the site page while the job moves through fetching and indexing. Test the assistant from the dashboard after an active index is ready.

If a site cannot be fetched or should not be crawled, the dashboard also offers a manual text path. It accepts pasted content or .txt, .md, .csv, and .json files within the limit shown in the form. This is an import path, not an authenticated crawler.

2. Add the generated widget script

Copy the exact snippet from the site’s Installation tab. Its stable loader URL automatically receives future widget updates.

<script
  src="https://YOUR_REFLEKS_APP/widget.js?channel=stable"
  data-widget-key="YOUR_SITE_WIDGET_KEY"
  async></script>

The example intentionally uses placeholders. Do not hand-edit the key; copy the current script from the dashboard. Place it before </body> in the global layout and publish the site. The stable bootstrap loads the current integrity-checked release automatically.

Platform paths

The dashboard can identify signals for the platforms below. Detection is a hint for choosing instructions, not a promise that a platform’s current editor has the same menu names.

WordPress

Use a site-wide HTML snippet in a footer plugin. Restricted WordPress.com sites need a plugin-enabled plan and activated hosting features.

Shopify

Back up the theme, then add the script before </body> in Layout → theme.liquid. This covers storefront pages, not checkout or new customer-account pages. Recheck after theme changes.

Wix

On a published site with a connected domain, use Settings → Custom Code → Body end → All pages. Load once per visit. Do not use an Embed HTML/iframe element.

Webflow

Use Site Settings → Custom Code → Footer Code, then publish. An active Site plan or eligible Workspace plan and editing permissions are required.

Squarespace

Use Code Injection → Footer on Core, Plus, Advanced, or an eligible legacy plan. Injected code is not supported on checkout pages.

Framer

Use Project Settings → Custom Code → Add Script, place it at the end of body, apply it site-wide, choose Once, and publish.

Next.js

Select Next.js in the dashboard for a copy-ready next/script component. Put its import at the top and its afterInteractive component inside the existing root layout body, or pages/_app.tsx for the Pages Router.

Custom / unknown

Use the global template, layout, footer, or tag manager and ask a developer if needed.

Selecting a platform changes the instructions, not the website itself. Menu names and plan permissions can vary. The live site must actually load and execute the Refleks script with the correct key on each intended page, and its security and consent settings must permit that execution.

3. Verify the published install

Select Verify installation after publishing. The server fetches the configured site URL and checks executable script tags for the expected loader, site key, Refleks origin, and HTTPS. Comments, inactive script types, and templates do not count as executable tags. Framework references are reported separately. This is a page-source check: it does not run JavaScript, check whether a browser blocks the script, or test an answer.

Conditional

Script found

One executable tag has the expected URL and site key. Open the published website to confirm the widget runs.
Conditional

Framework reference

A framework payload references the URL and key. This is not proof that the widget executed; a browser check is required.
Not supported

Not proof of ownership

This check is an output probe, not DNS, TXT-record, or legal domain ownership verification.

Wix custom code, frameworks, consent tools, and tag managers can insert the script after the initial response. “Not detected automatically” does not mean installation failed. Open the published website, click the chat bubble, send a test question, navigate to another page, and test mobile. If it does not work there, see CSP and origins and installation troubleshooting.

What is not part of installation?

  • There is no separate DNS verification workflow in the current product.
  • The widget loader requires HTTPS in production. HTTP is accepted only for localhost development paths.
  • Adding the script does not crawl a site or make an assistant ready by itself; the site needs an active indexed snapshot first.

Next: read how content is selected or configure the widget.