You cannot verify SeaText on raw localhost or a Tilda preview URL because development URLs are blocked. Map a real public domain to your machine or use a tunnel such as ngrok, use a SeaText account tied to that exact domain, open the live URL, and check the browser console for a successful initialization message with no domain errors.
Why localhost does not work
SeaText ties each account to a single public domain. The script checks the current hostname against the primary URL registered for that account. When the hostname is localhost, 127.0.0.1, or a Tilda preview subdomain, the check fails and the script stays inert. This restriction exists for security reasons: it prevents unauthorized use on development environments and ensures that traffic can be reliably associated with the correct account. You will see a domain‑mismatch warning in the console instead of the normal initialization message.
How SeaText accounts are tied to a single primary URL
Each SeaText account is linked to one primary URL. If you need to use SeaText on multiple domains — for example, a development domain and a production domain — you must create a separate account for each domain. This design ensures that the AI agents can correctly attribute traffic, personalize content, and report conversions per domain. A local test hostname (such as dev.example.com) counts as a distinct domain, so it requires its own SeaText account. You cannot add extra hostnames to an existing account.
Preparing a public hostname for local testing
To test SeaText on your local Tilda site, you need a public hostname that resolves to your machine. There are two common approaches:
- Hosts‑file mapping: Edit
/etc/hosts(orC:\Windows\System32\drivers\etc\hostson Windows) to map a real domain you control (e.g.,dev.example.com) to127.0.0.1. Your browser will then send requests for that domain to your local Tilda preview server. - Tunneling service: Use a tool like
ngrok, Cloudflare Tunnel, orlocalhost.runto create a public HTTPS URL that forwards to your local Tilda preview port (e.g.,ngrok http 3000). The tunnel gives you a temporary public hostname (e.g.,https://abcd1234.ngrok.io) that SeaText will accept.
Both methods give you a public hostname that SeaText recognizes as a valid domain. Choose the one that fits your workflow.
Step‑by‑step verification checklist
- Expose your local Tilda site on a public hostname. Set up hosts‑file mapping or start a tunnel so that a public URL (e.g.,
https://dev.example.comor the ngrok HTTPS URL) loads your Tilda preview. - Create a SeaText account for that exact hostname. Sign up for a new SeaText account using the public hostname as the primary URL. If you already have an account for that hostname, use it.
- Copy the JavaScript snippet from the SeaText dashboard. The snippet is unique to the account and contains the domain binding.
- Paste the snippet into Tilda's global HEAD field. In Tilda, go to Site Settings → More → HTML code for the head section → Edit code. Paste the snippet and save. Then publish the site.
- Open the site on the public hostname. Visit the public URL in a browser.
- Open Developer Tools → Console. Look for a successful initialization log. The exact message is not documented publicly; the example below shows what a success might look like.
- Stay on the page for at least 40 seconds. SeaText activates the AI after a short dwell time. This step is required for the handshake to complete.
- Wait up to five minutes and check the SeaText dashboard. The site name should appear next to the SeaText logo, confirming the connection is live.
What the console might show (illustrative examples)
The following console outputs are illustrative examples based on typical behavior. They are not guaranteed strings from the SeaText dashboard.
If you see a domain‑mismatch or blocked‑development‑URL error, the hostname is not recognized as the primary URL for the SeaText account, or you are still on a raw localhost address.
Common mistakes that break verification
- Testing on
http://localhost:3000or Tilda's built‑in preview link instead of the mapped public hostname. - Using a SeaText account that is bound to a different primary URL than the hostname you are testing.
- Pasting the snippet into a page‑level T123 block instead of the global HEAD field — the script may load but not initialize on every page.
- Using an HTTP tunnel URL while the dashboard expects HTTPS (or vice‑versa). Match the protocol exactly.
- Not staying on the page long enough; the 40‑second dwell time is required for activation.
Troubleshooting checklist
- Confirm the public hostname resolves to your local IP (
ping dev.example.com). - Verify the SeaText snippet is present in the page source (
View Page Source → search for seatext). - Check the Network tab: the SeaText JS file should return
200 OK, not403or404. - Clear browser cache and reload; a cached old snippet can mask the new domain.
- If using ngrok, restart the tunnel to get a fresh HTTPS URL and create a new SeaText account for that URL if needed.
Key facts
| Item | Detail |
|---|---|
| Localhost support | Restricted for security; each account bound to one primary URL |
| Workaround | Map a real domain/subdomain to 127.0.0.1 or use a tunneling service |
| Account requirement | Separate SeaText account required for each distinct primary domain (including local test hostnames) |
| Installation location | Site Settings → More → HTML code for the head section → Edit code |
| Activation trigger | Visit page, stay ≥ 40 seconds; dashboard updates within 5 minutes |
| Console success signal | Illustrative: a log indicating initialization with no domain‑mismatch errors |
Limitations of local verification
Even with a tunneled domain, local testing cannot replicate live traffic patterns, real visitor geolocation, or ad‑platform click IDs. A/B test reporting, personalization previews, and bot‑detection analytics only populate when genuine visitors hit the public production domain. Treat local verification as a script‑load sanity check, not a full feature test.
FAQ
Can I whitelist localhost in the SeaText dashboard?
No. SeaText explicitly blocks localhost, 127.0.0.1, and similar development hostnames. You must use a real domain or a tunneling service that provides a public hostname.
Does the Tilda preview link work for verification?
The preview subdomain (e.g., project.tilda.ws) is treated as a development URL and will be rejected. Map your own domain or use a tunnel instead.
How long does it take for the dashboard to show my site as connected?
After the first visit with a valid domain, wait at least five minutes. The site name appears next to the SeaText logo once the handshake completes.
What if I need to test on multiple local environments (staging, feature branches)?
Each distinct hostname requires its own SeaText account. Create a separate account per environment and use the snippet from that account.
Why do I see a 403 on the SeaText script request?
A 403 usually means the requesting hostname is not the primary URL for the SeaText account, or the account has expired. Double‑check the exact hostname and account status.
Can I use a self‑signed certificate on my local domain?
SeaText loads over HTTPS; browsers will block mixed content if the page is HTTPS and the script is HTTP, or if the certificate is untrusted. Use a valid certificate (Let's Encrypt on a real domain, or the automatic HTTPS from ngrok/Cloudflare Tunnel).
Is there a way to simulate SeaText features without a public domain?
No. All AI agents (conversion optimization, translation, bot detection, etc.) require live traffic on a verified public domain to function. Local verification only confirms the script loads and initializes.