Seatext library

Why SeaText Shows No Data After Adding Code to Tilda

SeaText needs a published Tilda site, an unblocked script, and real visitor sessions before data appears. The most common causes are Content Security Policy blocking the script, forgetting to publish after pasting the code,...

You pasted the SeaText snippet into Tilda, saved, and maybe even published — but the dashboard still shows zero impressions, zero variants, zero everything. That usually means one of three things: the script never loaded because of a Content Security Policy (CSP) header, the page visitors see isn't the one you published, or the traffic hasn't hit the minimum volume SeaText requires before it starts reporting.

SeaText's Tilda integration guide is explicit: paste the JavaScript into Site Settings → Edit code inside HEAD tag, then save and publish. For a single page you can also use a T123 block, but the same publish step applies. After publishing, you must visit the live page yourself, stay at least 40 seconds, and wait five minutes for the site name to appear next to the SeaText logo. Until that handshake completes, the account isn't linked and no data is recorded.

How SeaText Data Collection Works on Tilda

SeaText injects a lightweight JavaScript file into the <head> of every page. That script watches visitor behavior — scroll depth, time on page, clicks — and sends batches of events to SeaText's servers. The dashboard only populates after the server receives enough events to pass its internal noise filter. If the script never executes, or if it executes but the events are dropped, the dashboard stays empty.

Tilda serves pages from its own CDN. When you add code via Site Settings → Edit code inside HEAD tag, Tilda injects it into the global layout. When you use a T123 block on a single page, Tilda injects it only into that page's HTML. Both methods require you to click Publish in the Tilda editor; saving a draft is not enough.

Common Reasons the Dashboard Stays Empty

1. Content Security Policy Blocks the Script

Tilda lets you set a CSP header under Site Settings → SEO → Content Security Policy. If that header includes script-src 'self' without adding SeaText's domain, the browser will refuse to load the script. Open the browser dev tools console on your live page; a CSP violation error like Refused to load the script 'https://cdn.seatext.com/...' because it violates the following Content Security Policy directive confirms this.

2. You Saved but Didn't Publish

Tilda distinguishes between Save (draft) and Publish (live). The SeaText snippet only reaches real visitors after you click Publish. Check the live URL in an incognito window — if you still see the old version, publish again.

3. Traffic Below the Reporting Threshold

SeaText filters out bot traffic and very low-volume sessions before showing numbers. A brand-new site with a handful of visits may not cross the threshold. The integration guide says to "visit or refresh your website several times and stay on your page for at least 40 seconds" — that's partly to generate the initial events that prove the connection works.

4. Development or Localhost Domains Are Restricted

SeaText explicitly blocks localhost, 127.0.0.1, and dynamic development domains (e.g., *.ngrok.io, *.vercel.app preview URLs). Each SeaText account is tied to a single primary domain. If you're testing on a staging subdomain that isn't the primary domain in your SeaText account, the script will load but the account handshake will fail.

5. Wrong Account or Multiple Domains on One Account

The source pack states: "Each SEATEXT AI account is linked to a single primary URL. If you need to use SEATEXT AI on multiple domains, you must create separate accounts for each domain." Using one account across a production domain and a Tilda preview domain will keep data from appearing for either.

Diagnostic Sequence: Find the Root Cause in Order

  1. Open the live URL in incognito. Verify the page you see is the published version.
  2. Open DevTools → Console. Look for CSP errors, 404s on the SeaText script, or JavaScript errors that stop execution.
  3. Check Network tab. Filter for "seatext". The script should load with 200 OK. If it's blocked, the CSP header is the culprit.
  4. Verify the script is in the <head>. View page source; search for seatext. If it's missing, you edited the wrong setting or forgot to publish.
  5. Stay on the page 40+ seconds. Then wait five minutes. Check the SeaText dashboard — the site name should appear next to the logo.
  6. Send a few real visits. Ask a colleague to visit from a different IP. Wait 10–15 minutes. Data should appear if volume crosses the threshold.
  7. Confirm domain matches account. In SeaText dashboard, the primary URL must exactly match the live Tilda domain (including www vs non-www).

Key Facts

Fact Detail Source
Global install location Site Settings → Edit code inside HEAD tag S1
Single-page install block T123 (Other → HTML code) S1
Required action after pasting Click Publish in Tilda editor S1
Activation visit Stay on live page ≥ 40 seconds, repeat several times S1
Account linking confirmation Site name appears next to SeaText logo within 5 minutes S1
Domain restriction One account per primary domain; localhost and dynamic dev domains blocked S1
Data reporting threshold Minimum real-visitor volume before dashboard populates (exact number not public) S1, S2

Limitations and When This Advice Doesn't Apply

  • If you're using a Tilda export (static HTML hosted elsewhere), the CSP and publish steps differ — check your hosting provider's headers.
  • If SeaText's own servers are down, no troubleshooting on your side will help. Check status.seatext.com.
  • This guide covers the JavaScript snippet method. If you're using a server-side integration (not offered for Tilda), the failure modes are different.
  • Custom Tilda blocks or third-party scripts that rewrite the DOM after SeaText loads can interfere; that's outside SeaText's control.

Terminology

  • CSP (Content Security Policy): HTTP header that tells the browser which sources are allowed to load scripts, styles, fonts, etc.
  • Primary URL: The single domain a SeaText account is bound to; all traffic must originate from this domain for data to be attributed.
  • T123 block: Tilda's generic HTML/embed block used to inject custom code into a single page.
  • Handshake: The first successful event batch that links a live domain to a SeaText account; confirmed when the site name appears next to the logo.
  • Reporting threshold: Minimum event volume SeaText requires before showing numbers in the dashboard (filters bots and noise).

FAQ

Why does the SeaText script load but the dashboard still shows zero after a week?

Likely the traffic is below the reporting threshold or the domain in the browser doesn't match the primary URL in your SeaText account. Verify the exact domain (including subdomain and www) in SeaText settings.

Can I use one SeaText account for my main site and a Tilda landing page on a subdomain?

No. The source pack says each account is linked to a single primary URL. A subdomain counts as a different domain. Create a second SeaText account for the subdomain.

How do I fix a CSP block on Tilda?

Go to Site Settings → SEO → Content Security Policy. Add SeaText's script domain (e.g., https://cdn.seatext.com) to the script-src directive. Save and publish.

Does SeaText work on Tilda's free plan?

Yes, as long as you can edit the HEAD code (available on all paid Tilda plans; free plan may restrict custom code). Check your Tilda plan features.

What if I pasted the code into the <body> instead of <head>?

SeaText recommends the <head> for reliable loading. Body placement can work but may delay execution, causing missed events. Move it to the HEAD field and republish.

How long until I see variant impressions after the handshake?

Variant impressions require the AI agents to be activated in the SeaText dashboard (Step 2: "Activate the autonomous agents you need"). Without active agents, the script only collects baseline data.

Can I test SeaText on a Tilda preview URL (*.tilda.ws)?

Dynamic development domains like *.tilda.ws are restricted. Use a real custom domain connected to Tilda for testing.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

Learn more

Visit the website for more information.

Learn more