SeaText cost for local Tilda testing – free, no extra charges

Learn more about this service

See how this page can help with your next step.

SeaText cost for local Tilda testing – free, no extra charges

Direct Answer: SeaText pricing is based on live traffic volume, so running the script on a localhost or other development URL does not generate any billable traffic. Local testing on Tilda is therefore free.

SeaText charges you only for the real visitors that reach your live site. When you run the script on a local Tilda preview (localhost), no live traffic is recorded, so there is no additional cost.

What is SeaText?

SeaText is an AI platform that rewrites website copy in real time, runs A/B tests, and personalizes content based on visitor intent. It works by adding a small JavaScript snippet to your site’s <head> section.

How SeaText pricing works

The service measures the number of unique visitors that load the script on a publicly reachable domain. Pricing tiers are tied to that traffic count. If the script never sees live traffic, the usage counter stays at zero.

Cost model details

SeaText uses a traffic‑based model. You pay for the volume of live visitors that actually load the page. Development traffic on localhost or any non‑public address is excluded from the count. There are no hidden fees for testing.

Localhost and staging behavior

SeaText deliberately blocks development URLs such as localhost. Each SeaText account is linked to a single primary URL, and the script requires a valid, public domain to associate traffic with your account.
Excerpt: "Development URLs, such as localhost, are restricted for security reasons. Ensure you use a valid, real domain for these cases." (S1)

Account‑per‑domain requirements

If you need to use SeaText on multiple domains — for example a development domain and a production domain — you must create separate accounts for each domain. Each account can only be linked to one primary URL (S1).

Activation steps

Log in to your SeaText account and copy the JavaScript code snippet.
In Tilda, open Site Settings → More → HTML code for the head section → Edit code and paste the snippet.
Publish the site to a real domain to activate the AI. The script remains inert on localhost.
For local testing, add the same block (T123 → Other) on a preview page, paste the code, and view the page in your browser. No traffic is recorded.

Limitations and troubleshooting

The script will not activate on localhost; you will not see AI‑generated changes there.
Dynamic development domains may not function properly because SeaText cannot reliably associate traffic with your account (S1).
If you need a staging environment that behaves like production, register a separate public domain and create a second SeaText account.

Expert perspective

Local development traffic is not billable because SeaText’s metering only counts hits on a verified, public primary URL. The platform ties each account to one domain for security and attribution reasons. Developers should treat localhost as a free sandbox: install the snippet, verify it loads, but expect no AI activity until the site is published to a real domain. For staging, spin up a distinct public hostname and a matching SeaText account; this keeps analytics clean and avoids accidental charges.

Practical follow‑up questions

Do I need a separate SeaText account for a staging domain? Yes. Each account is tied to one primary URL; a staging domain counts as a separate site.
Can I test SeaText on a local Tilda preview? You can load the script, but it will not activate or incur charges because no live traffic is recorded.
When should I switch to a public domain? As soon as you need real analytics, A/B‑test results, or personalization that depends on visitor data.
Will SeaText block my localhost? The script is designed to ignore development URLs for security reasons (S1).
Is there any hidden fee for local testing? No. All fees are tied to live traffic; local testing is free.

Key facts

Aspect	Detail
Pricing model	Based on live visitor volume
Local (localhost) usage	Not counted, no cost
Domain requirement	Public, primary URL per account
Installation step	Paste JS into Tilda head section (S1)

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 (or C:\Windows\System32\drivers\etc\hosts on Windows) to map a real domain you control (e.g., dev.example.com) to 127.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, or localhost.run to 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.com or 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.

Console screenshot showing a green informational log: 'SeaText initialized' with no errors. — Example of a successful initialization on an allowed public domain

Console screenshot showing a red error: 'SeaText: domain mismatch' or 'SeaText: blocked on development URL'. — Example of a domain error on localhost

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:3000 or 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, not 403 or 404.
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.

What triggers the first data capture

SeaText links each account to one primary URL. Development addresses such as localhost or Tilda's local preview are explicitly restricted for security reasons. When you move a Tilda project to a production domain, you must create a new SeaText account for that domain, add the script to the site's <head> via Tilda's Site Settings, publish the site, and then visit the live page yourself. The system activates after you stay on the page for at least 40 seconds and the dashboard shows your website name next to the SeaText logo — usually within five minutes.

This means data collection does not begin at publish time. It begins at the moment of the first qualifying visit after the script is live. The 40-second dwell time is the activation signal that ties the domain to your account. Until that signal happens, SeaText remains inert even if the script is present on the page.

Pre-launch readiness checklist

Use this checklist before you publish your Tilda site. It prevents the most common activation failures.

Create a production-specific SeaText account. Each domain needs its own account. You cannot reuse a localhost account.
Copy the JavaScript snippet from the new account. In the SeaText dashboard, copy the code shown for that domain.
Paste the snippet into Tilda's global head field. Go to Site Settings → More → HTML code for the head section → Edit code, paste, save, and publish the entire site. Use the field labeled "Edit code inside HEAD tag".
Verify the script loads on the live URL. Open the production site in a browser, view source, and confirm the SeaText script appears in the <head>.
Trigger activation. Visit several pages on the live site and remain on each for at least 40 seconds. This signals the AI to link the domain to your account.
Confirm connection in the dashboard. Wait up to five minutes. Your website name should appear next to the SeaText logo at the top of the dashboard.

Step-by-step: moving from localhost to production

1. Set up the production domain in SeaText

Log in to SeaText and create a new account using the exact production domain, for example example.com. The platform will generate a unique JavaScript snippet for that domain. If you also need a staging domain, create a separate account for it if it is a real public domain.

2. Install the snippet on Tilda

Open your Tilda dashboard and go to Site Settings. Choose "More" → "HTML code for the head section" → "Edit code." Paste the SeaText snippet into the field labeled "Edit code inside HEAD tag." Save and publish the site. This places the script on all pages.

If you only need the script on specific pages, add a T123 block to those pages instead. Click the "+" icon, choose the T123 block under "Other", click "Content", paste the snippet into the HTML editor, save and close, then publish.

3. Publish and test

After publishing, open the live site in an incognito window. Check the page source to ensure the script is present. Then browse a few pages, staying on each for 40 seconds or more. This manual visit is required to activate the AI for that domain.

4. Verify dashboard connection

Return to the SeaText dashboard for the production account. Within five minutes you should see the domain name next to the SeaText logo. Once it appears, data collection is active for all subsequent visitors. Check with the vendor if you do not see the domain after five minutes.

Key facts about the activation moment

Item	Details
Domain binding	One SeaText account per primary URL; localhost and dynamic dev domains are restricted.
Script placement	Global head via Site Settings → More → HTML code for head section, or per-page via T123 block.
Activation requirement	Visit live pages and stay ≥40 seconds; dashboard shows domain name within 5 minutes.
Data collection start	Immediately after activation, for every new visitor session on the production domain.
Localhost behavior	No tracking, no A/B tests, no personalization — script remains inert on restricted URLs.

Common mistakes and how to avoid them

Reusing a localhost account. SeaText does not allow whitelisting localhost or any development URL. A separate account is mandatory for each public domain.
Skipping the 40-second visit. Without this step the AI stays inactive and the dashboard will not show the domain as connected.
Using a dynamic staging subdomain. Dynamic development domains such as staging-123.example.com may fail to associate traffic reliably. Use a stable, real domain.
Forgetting to publish after pasting the script. Tilda requires a full site publish for global head changes to take effect.
Placing the script in the wrong field. Use the head section field. A T123 block is for per-page use only.

Why the 40-second activation visit matters

The 40-second rule is not a random delay. It is the signal SeaText uses to confirm that the domain is live and that a real person can reach the page. Short visits or bot traffic do not trigger activation. This protects the account from junk data and confirms that the script can load correctly in a normal browser.

After activation, data collection is continuous. Every new visitor session on the production domain is recorded. The exact collection methods depend on the agents you activate, such as conversion tracking or bot detection. The activation itself only links the domain; it does not turn on every agent.

What is excluded while the site is on localhost

SeaText blocks development URLs for security. While your Tilda project is on localhost or a dynamic development domain, the script will not send data. It also will not run A/B tests or personalization. The AI remains inert until the correct production domain is connected.

This restriction matters for planning. You cannot fully test SeaText behavior before launch unless you use a real public domain. A password-protected staging URL may also fail domain validation. Plan your launch test on the live domain or a stable public staging subdomain with its own account.

FAQ

Can I test SeaText on a Tilda staging subdomain before launch?

Only if the staging subdomain is a real, publicly reachable domain that you add as a separate SeaText account. Dynamic or password-protected staging URLs often fail domain validation.

What happens if I paste the production script on localhost?

The script will load but remain inert. SeaText blocks development URLs, so no data is sent and no agents activate.

How long until I see analytics in the dashboard?

After the 40-second activation visit, the domain appears in the dashboard within five minutes. Visitor data from that point forward populates reports in near real time.

Do I need to re-activate after a Tilda redesign?

No. As long as the same production domain and SeaText account are used, the script continues collecting data. Just ensure the snippet remains in the head after redesign.

Can one SeaText account cover both www and non-www versions?

Yes, the primary URL covers the domain you register. Ensure your Tilda publishing settings match that domain, with or without www, so the script loads consistently.

What if my production domain changes later?

Create a new SeaText account for the new domain, install its snippet, and run the activation visit again. The old account can be kept for historical data.

Does data collection start for everyone at once?

Yes. After the activation visit, SeaText starts collecting data for every subsequent visitor who loads a page with the script. There is no per-visitor activation step.

How Seatext's Translation Agent Works

Seatext's Translation Agent is a JavaScript snippet that runs on your site. It detects the visitor's language and automatically translates your page content into up to 125 languages. The agent does not change your original Tilda content. Instead, it overlays translated text on top of the page. This means you can edit the translated text directly in the HTML of your Tilda blocks without touching the original language.

The agent activates only after you have a Seatext AI account and paste the script into your site. Each domain requires a separate account. You cannot use a development URL like localhost because the agent cannot reliably associate traffic with your account. Use a real domain.

Where the Translation Snippet Lives in Tilda

The translation snippet is a piece of JavaScript code. You can place it in two locations:

Site-wide HEAD tag: Go to Site Settings → More → HTML code for the head section → Edit code. Paste the code into the field labeled "Edit code inside HEAD tag". This applies to every page on your site.
Page-specific T123 block: On a single page, click the + icon, add a T123 block, select Other, then paste the code into the Content editor. This only affects that page.

Most users choose the site-wide approach for simplicity. But if you want translation only on certain pages, use the T123 block.

Tilda Page Editor vs Site-Wide Installation

Here is a comparison of both methods:

Criteria	Site-Wide HEAD	Page-Specific T123
Scope	All pages	Only the page where you add the block
Ease of management	One place to update	Must edit each page separately
Performance	Loaded on every page	Loaded only on that page
Best for	Whole-site translation	Testing or translating specific landing pages

Use the site-wide method if you want all pages translated. Use the T123 method if you only need translation on a few pages or want to test before going global.

What Happens After You Paste the Script

After you paste the script and publish your site, the Translation Agent does not start immediately. You must first visit your live site and stay on the page for at least 40 seconds. This visit activates the AI and links it to your account. Then wait at least five minutes. After that, the Seatext logo should appear at the top of this page (your Seatext dashboard) next to your website name. This confirms the connection is active.

If you do not see the logo after five minutes, revisit your site for another 40 seconds and wait again. The agent may need a few tries to activate.

Editing the Translation Snippet Directly

Once the agent is active, you can edit the translated text directly in Tilda. Here is the practical workflow:

Open the page in Tilda's page editor.
Find the T123 block that contains the Seatext snippet. If you used the site-wide method, the snippet is not visible per block. You must add a T123 block to the page and paste the snippet again to have a block you can edit. Alternatively, you can edit the snippet in the HEAD tag, but that is not recommended because you can break the JavaScript.
Click on the T123 block's Content area. You will see the Seatext JavaScript code. Inside that code, there is a section with language key-value pairs. For example: "en": "Welcome", "fr": "Bienvenue". You can change the translated text directly inside the code.
Make your changes, but do not change the JavaScript structure. Only edit the text inside quotes. Save and close the block.
Publish the page. The changes appear immediately on the live site.

Be careful. If you delete or modify the JavaScript outside the text strings, the agent may stop working. Always keep a backup of the original snippet.

Troubleshooting the Seatext Logo or Language Selector

If the Seatext logo does not appear in your dashboard after activation, check these points:

Did you visit the site for at least 40 seconds? The agent needs a real visit from a browser.
Did you wait at least five minutes? The logo appears only after a delay.
Is your domain correct? If you are using a www vs non-www version, the domain must match the one in your Seatext account.
Is the script pasted correctly? Open the page source and verify the script is present.

If the language selector does not appear on your site, the agent may not be active. First ensure the logo appears in your dashboard. Then refresh your site a few times. The selector appears automatically once the agent is active.

If changes you made to the translated text do not appear after publishing, you may have edited the wrong block. Make sure you are editing the same T123 block that contains the Seatext script. Also, clear your browser cache and reload the page.

Limitations Every Tilda User Should Know

One account per domain. You cannot use the same Seatext account on two different domains. Create a separate account for each website.
No localhost. Development URLs like localhost or dynamic development domains are blocked. Use a real domain.
Activation is not instant. You must visit the site for 40 seconds and wait five minutes. This can be frustrating during testing, but it is a security measure.
Editing the script requires care. One wrong character can break the translation. Always test changes on a staging page first.
The agent translates only visible text. It does not translate images, alt text, or meta tags. Those must be done manually.

FAQ

Do I need to reinstall the script for each new page? No. If you added the script to the site-wide HEAD, it covers all pages. Use a T123 block only if you want to override the translation on a specific page or add page-specific script.
Can I edit translations after publishing? Yes. Return to the T123 block, modify the text inside the snippet, save, and republish. The changes take effect immediately.
What if the language selector doesn’t appear? First, ensure the Seatext logo appears in your dashboard. If not, revisit your site for 40 seconds and wait five minutes. If the logo is there but the selector is missing, refresh your site a few times. If it still doesn't appear, check that the script is correctly placed in the HEAD or T123 block.
Is there a cost to use the Translation Agent? Yes, activation requires a Seatext subscription. See the pricing page on Seatext's website for details.
Can I edit the translated text without re-pasting the script? Yes, as long as you edit the text inside the existing snippet. Do not remove or break the JavaScript code. If you remove the snippet, you must paste it again.

Readiness Checklist for Editing Translations

Before you attempt to edit, verify each of these items:

Seatext account created – You need an account at seatext.com. If you don’t have one, create it first.
Script installed correctly – The JavaScript code from Seatext must be pasted into the Tilda HEAD (for all pages) or into a T123 block (for a single page). Follow the steps in the Tilda integration guide.
Site published – After adding the code, publish the site. Unpublished changes won’t activate the AI.
Site visited and AI activated – Visit or refresh your website several times and stay on the page for at least 40 seconds. This triggers the AI to link to your account.
Account connected – Wait at least five minutes after the first visit. You should see your website name displayed next to the SEATEXT logo at the top of your Seatext dashboard. This confirms the connection.
Project active – In your Seatext dashboard, ensure the Translation Agent (or the project containing translations) is active. If it’s paused, you won’t be able to edit.

Why Timing Matters for Translation Edits

The Seatext system works by embedding translation data directly into your page code. This design means edits take effect instantly on publish, but it also means the system must be fully initialized before your changes will be served to visitors. If you edit before the AI activates, the translation object may not exist yet, or the connection to your account may not be established. The result: your edits either disappear on the next sync or never reach visitors.

Understanding this timing prevents wasted effort. Many users try to edit translations immediately after pasting the script, only to find their changes don’t appear. The 40-second visit and five-minute wait are not arbitrary—they are the handshake between your Tilda site and the Seatext servers. Until that handshake completes, the translation layer is dormant.

Signs You Should Wait Before Editing

If any of these are true, hold off on editing:

Script not yet installed – You can only edit translations after the code is placed. Editing before installation has no effect.
Site not published – Draft changes are not served to visitors, so the AI won’t activate. Publish first.
Account not connected – If the dashboard shows no website name, the AI hasn’t linked. Wait the five minutes and revisit the site.
Project is paused – An inactive translation project won’t process edits. Check the agent status in Seatext.
Multiple domains without separate accounts – Each domain (production, development) needs its own Seatext account. If you use the same account on two domains, the translation might not sync correctly.

The Exception: When Edits Might Not Stick

There are a few situations where your edits may not persist:

Re-sync overwrites – If you use Seatext’s automatic translation sync (e.g., after adding new content), it may overwrite manual edits. To avoid this, make your edits after the sync is complete and avoid triggering a re-sync until you’re done.
Script removed or changed – If you delete the T123 block or modify the HEAD code without preserving the translation snippet, the edits are lost.
Account cancelled – If your Seatext subscription expires, translations will stop being served, and editing becomes unavailable.

Diagnostic Sequence: How to Confirm You Can Edit Right Now

Run through this diagnostic sequence to verify readiness:

Open your Seatext dashboard and check that your website name appears next to the SEATEXT logo.
Go to Tilda and open the page you want to edit.
If you used a T123 block, click on the block and check that the JavaScript snippet contains a translation object.
If you used site-wide HEAD, go to Site Settings → Edit code inside HEAD tag and verify the snippet is present.
Make a small test edit (e.g., change one word) in the translation object.
Save and publish the page.
Visit the live site in a browser and check that the change appears.
If the change shows, you are ready to edit all translations. If not, revisit the checklist above.

Key Facts About Seatext and Tilda Integration

Fact	Detail
Installation method	Paste JavaScript code into Tilda’s HEAD (site-wide) or a T123 block (per page).
AI activation	Visit site for at least 40 seconds; wait 5 minutes for account linking.
Editing location	Directly within the translation snippet in the T123 block or HEAD code.
Languages supported	Up to 125 languages, controlled via Seatext Translation Agent.
Multiple domains	Each domain needs a separate Seatext account.
Security	AI remains inert until activated; script is safe to use.
Limitations	Dynamic development domains (e.g., localhost) are restricted; production domains only.

Practical Scenarios: When to Edit vs. When to Use Dashboard

Editing directly in Tilda is ideal for quick fixes: correcting a mistranslated button label, adjusting a headline for a specific campaign, or updating a single phrase across languages. You don’t need to log into Seatext for these. The changes are immediate and require no sync.

Use the Seatext dashboard when you need to add new languages, change translation settings, or regenerate translations for new content. Dashboard changes propagate to all connected sites but require a re-sync. If you edit in Tilda and then trigger a dashboard sync, your manual edits will be overwritten. Plan your workflow: edit in Tilda for one-off tweaks; use the dashboard for structural changes.

Decision Criteria: Choose the Right Editing Method

Ask yourself three questions before editing:

Is the change a small text correction or a large-scale update? Small corrections → Tilda. Large updates → Dashboard.
Do you need the change to survive a future sync? If yes, make the change in the dashboard. Tilda edits are local and will be lost on sync.
Are you editing a page-specific block (T123) or the site-wide HEAD? Page-specific overrides site-wide. Edit the one that actually controls the page you’re viewing.

Common Mistakes and How to Avoid Them

Editing before activation – You modify the snippet but the site hasn’t been visited. The AI won’t serve the new translation. Always activate first.
Forgetting to publish – Tilda requires a publish step for changes to go live. Without it, edits exist only in the editor.
Using the same account for multiple domains – This causes sync issues. Create separate accounts for development and production.
Editing the wrong snippet – If you have both a site-wide HEAD and a page-specific T123 block, the page-specific block overrides. Make sure you edit the correct one.
Changing the script structure – The translation object is part of the Seatext script. Accidentally removing or breaking it will stop translations. Only edit the translation values, not the surrounding code.

Limitations You Should Know

Direct editing in Tilda has constraints. You cannot add new languages from Tilda—you must do that in the Seatext dashboard. You cannot change the translation engine settings (e.g., formality level, glossary terms) from Tilda. The translation object in the snippet is a snapshot; it does not update automatically when you add new content to the page. New content will appear untranslated until a dashboard sync runs.

Also, development environments like localhost or dynamic preview URLs are restricted. Seatext requires a valid, public domain to associate traffic with your account. If you’re building on a staging subdomain, you need a separate Seatext account for that subdomain. Using the production account on staging will break the connection.

Frequently Asked Questions

Can I edit translations without visiting the Seatext dashboard?

Yes, you can edit the translation snippet directly in Tilda’s code editor. However, to add new languages or change agent settings, you need the Seatext dashboard.

How long does it take for an edit to appear on the live site?

After you save and publish the Tilda page, the change is immediate. The translation is served from the code on the page, so there is no server delay.

What if I accidentally delete the translation snippet?

You will need to reinstall the Seatext script from your dashboard. The translations are stored in your Seatext account, so you can generate a fresh snippet and paste it again.

Does editing in Tilda affect the Seatext dashboard translations?

No, edits made directly in the Tilda code are local to that site. They do not sync back to the Seatext dashboard. If you use the dashboard to regenerate translations, those will overwrite your manual edits on the next publish.

Can I edit translations for multiple languages in the same snippet?

Yes, the translation object typically contains all language pairs. You can edit any language value within that object.

Is there a limit to how many times I can edit?

No, you can edit as often as you like. Each edit takes effect after you publish the page.

What happens if I edit a translation and then add new content to the page?

The new content will not be translated automatically. You would need to either edit the snippet again to add translations for the new content, or run a sync from the Seatext dashboard (which will overwrite your manual edits).

Can I use the same Seatext account for a Tilda site and a WordPress site?

No. Each domain requires its own Seatext account. A Tilda site on yourdomain.com and a WordPress site on blog.yourdomain.com are different domains and need separate accounts.

Why this issue matters

Translation edits should be simple to spot. You change a word in Seatext, then open your Tilda page and expect the new word to appear. When it does not, the problem is usually in the connection, not in the translation.

Seatext can translate content across 125 languages. One missing publish step can make every language version look untouched. A broken connection also confuses visitors who see one language in navigation and another in the main content. Finding the cause quickly protects the user experience and restores trust in the page.

This guide explains how the integration works, why edits get stuck, and how to fix the problem step by step.

How Seatext and Tilda connect

The connection starts with a JavaScript snippet. Seatext gives you this snippet inside your Seatext account. You paste it into Tilda. Tilda stores the snippet in the code that runs on your site.

The snippet is not active the moment you paste it. Seatext says the AI remains inert until it is activated. Activation happens when a real visitor loads the live page and stays there for at least 40 seconds. During that visit, Seatext links your domain to your account.

After the 40-second visit, wait at least five minutes. When the connection is ready, your website name appears next to the Seatext logo at the top of the Seatext dashboard. That signal means you can start editing translations and expect them to reach the live site.

If any step in that chain is missing, edits stay in the dashboard and the live page keeps the old text.

The common mistake: saving without publishing

The most common reason edits do not show is simple. You saved the Tilda code but never published the page.

Tilda has two separate actions. Save stores your work inside Tilda. Publish sends that work to the live site. The Seatext snippet can only run after the page is published. If you only save, the live page has no snippet. Seatext never loads, and no translation edits can appear.

After you paste the snippet into the HEAD field or a T123 block, always click Publish. For the global HEAD field, publish the site. For a T123 block, publish the page. Many users save, close the editor, and call support. The fix is often one click on Publish.

Correct installation paths

Seatext’s Tilda integration page describes two paths. Use the first path when you want the script on all pages. Use the second path when you want the script on one page.

Install for all pages

Open Tilda Site Settings.
Click More.
Choose HTML code for the head section.
Click Edit code.
Paste the Seatext JavaScript code.
Save the field.
Publish the site.

Install for one page

Open the page in Tilda.
Click the plus icon to add a block.
Scroll down and choose Other.
Select the T123 block.
Add the block to the page.
Click Content.
Paste the Seatext code into the HTML editor.
Click Save and Close.
Confirm the code appears on the page.
Click Publish.

A T123 block only affects that single page. For site-wide translations, use the global HEAD field. If you want translations on every page, check that the snippet exists in the global field, not only in a T123 block.

Other reasons edits stay invisible

The live visit was too short. Seatext needs at least 40 seconds on the page to activate. A quick visit may not link the domain.
The five-minute wait was skipped. Even after activation, Seatext needs about five minutes to show your site name next to the logo. Until that appears, the connection may not be ready.
The website name does not appear in the dashboard. If it never appears, the script is not running on the live page or the wrong account is being used.
The domain does not match the account. Each Seatext account is linked to a single primary URL. A staging domain or a second production domain needs its own account.
The snippet uses localhost or a dynamic development URL. These are restricted or may not connect reliably. Use a real, valid domain.
The script is only on one page. If you used T123, other pages cannot receive translations.
The browser is showing an old page. Refresh the live page or open it in a private window to see the newest version.

Diagnostic checklist

Open the live URL in a private or incognito window.
View the page source and search for Seatext code in the head section. If the code is missing, the page was not saved or not published.
Stay on the page for 45 to 60 seconds. Do not close the tab early.
Refresh the page several times so Seatext can link the domain to your account. The source says to visit or refresh several times.
Wait at least five minutes.
Open the Seatext dashboard and check whether your website name appears next to the Seatext logo. If it appears, the connection is ready.
Make one test translation and save it.
Return to the live page and refresh it again.

If the test edit appears after this checklist, the original issue was almost certainly an unfinished connection step. If it still does not appear, review the account and domain settings.

Key facts

Item	Detail
Script location for all pages	Site Settings → More → HTML code for the head section → Edit code
Script location for one page	T123 block
Required action after adding code	Save and publish
Activation visit	At least 40 seconds on the live page
Wait time after activation	At least five minutes
Connection signal	Website name next to Seatext logo in the dashboard
Domain rule	One Seatext account per primary URL
Restricted URLs	localhost and dynamic development domains

How translation edits reach your Tilda page

When you save a translation in Seatext, that text is stored in Seatext. The JavaScript snippet is the delivery system. On the next page visit, the snippet asks Seatext for the latest translations and applies them to the visible page.

This explains why you do not need to republish Tilda after every translation edit. The snippet stays the same. Only the translation data changes. The next request picks up the new data.

The exception is new page content. If you add a brand-new text block in Tilda, Seatext may not know about it yet. Visit the updated page and stay on it for 40 seconds or more. This gives Seatext a chance to see the new content and add it to the translatable set.

Multi-domain, staging, and multiple websites

Seatext ties each account to one primary URL. This rule affects development teams more than anyone else.

Suppose your site has three URLs: staging.example.com, preview.example.com, and www.example.com. Each URL needs a separate Seatext account. If you paste the production snippet into a staging page, the dashboard will connect the production domain, not the staging domain. The staging page will keep the original text.

For multiple websites, create one account per website. For local development, remember that localhost is restricted. Dynamic development domains may not function properly because Seatext cannot reliably link their traffic to your account. Use a real domain when you need to test translations.

Limitations

The source pack covers Seatext’s JavaScript integration path in Tilda. Other Tilda translation features are separate.
Development URLs and localhost may be restricted. Use a real domain for testing.
Seatext links one account to one primary URL. Plan separate accounts for each domain.
If the Tilda page or site is not published, the snippet cannot run.

FAQ

I saved my translation in Seatext but the Tilda page still shows old text. What should I check?

Start with the diagnostic checklist. The most common cause is that the Tilda site was not published, so the Seatext snippet never loaded on the live page.

Does every translation edit require republishing Tilda?

No. The snippet is already on the site. Translation edits are delivered when the page loads. Republish Tilda when you add or change the snippet itself.

How long does the connection take?

Visit the page for at least 40 seconds. Then wait at least five minutes. Your website name will appear next to the Seatext logo when ready.

Can I use Seatext on my staging site?

Yes, but staging needs its own Seatext account because each account is linked to one primary URL. Use a real domain. localhost is restricted.

Why does the dashboard still say waiting for connection?

The most common causes are a missing snippet in the live page, a visit shorter than 40 seconds, or an account for the wrong domain. Check the live page source first.

What if I only pasted the snippet into a T123 block?

Then only that page can receive translations. For the whole site, put the snippet in the global HEAD field.

Understanding "editing permissions" for Seatext in Tilda

Seatext does not create a separate role inside Tilda. The permission you need is two‑fold:

Technical permission to place the Seatext JavaScript on the page.
Dashboard permission – the Allow inline editing toggle that activates inline translation edits.

The technical part belongs to anyone who can edit Site Settings or add custom HTML blocks. In practice that means the project Owner or a collaborator with Full Access.

How the "Allow inline editing" toggle works

Within the Seatext dashboard, there is a single switch labeled Allow inline editing. When turned on, the dashboard shows edit icons next to each translatable element on the live Tilda site. Clicking an icon opens a small overlay where you can modify the translation and save it instantly. The toggle does not appear in Tilda itself; it lives only in Seatext.

Because the toggle is part of Seatext’s own UI, the exact label may vary. If you cannot locate it, check with the vendor for the current naming.

Technical installation paths and required Tilda rights

Seatext’s integration guide describes two ways to add the script. Both achieve the same result – the script loads, detects translatable text, and later enables inline editing once the dashboard toggle is on.

Site‑wide installation (HEAD tag) – Requires access to Site Settings → More → HTML code for the head section → Edit code. Paste the snippet, save, and publish the whole site. This method gives every page the translation layer.
Per‑page installation (T123 block) – Requires page‑level edit rights. Add a block, choose Other → T123, paste the snippet, save, and publish that page only.

Both methods are documented in source S1.

Step‑by‑step: Site‑wide installation

Log in to Tilda and open the project.
Navigate to Site Settings → More → HTML code for the head section.
Click Edit code and paste the JavaScript snippet provided by Seatext.
Save the changes and click Publish (or Publish all pages).

Step‑by‑step: Per‑page installation

Open the target page in the Tilda editor.
Click the + icon to add a new block.
Select Other → T123 (embedded HTML).
In the block’s Content editor, paste the Seatext snippet.
Save, close, and publish the page.

Activation: making the script live

After publishing, the script is inert until you perform two actions described in source S1:

Visit the live site and stay for at least 40 seconds. This dwell time lets Seatext associate the domain with your account.
Wait about five minutes. The dashboard will then display your site name next to the Seatext logo, indicating a successful connection.

If either step is skipped, the translation layer remains dormant and the inline‑editing toggle will not show any edit icons.

Why inline editing matters

Inline editing lets content managers adjust translations without leaving the live site view. This reduces context switching, speeds up iteration, and ensures that changes are immediately visible to visitors. It also avoids the need to re‑publish the entire Tilda project after each translation tweak.

When the toggle is off, all translation changes must be made inside the Seatext dashboard’s list view, which can be slower for large sites.

Security and domain considerations

Seatext only works on public, fully qualified domains. Development URLs such as localhost or dynamic preview links are blocked (source S1). Each primary domain requires its own Seatext account. If you move your Tilda site to a new domain, you must create a new Seatext account and repeat the installation steps.

Because the script runs client‑side, it does not expose your translation data to third parties. However, anyone who can edit the HEAD code or add a T123 block can also replace the script with malicious code. Keep full‑access rights limited to trusted team members.

Decision criteria for choosing an installation method

Criterion	Site‑wide (HEAD)	Per‑page (T123)
Scope of translation	All pages automatically covered	Only selected pages receive translation
Required Tilda rights	Access to Site Settings (Owner or Full Access)	Page‑level edit rights (Owner, Full Access, or Page Editor)
Complexity	One‑time code paste	Repeat for each page you want translated
Future domain changes	Re‑install needed if domain changes	Same as site‑wide; each page must be updated
Control granularity	Less granular – all pages share same script	More granular – you can mix translated and non‑translated pages

Choose the method that matches your project’s size and your team’s permission structure.

Troubleshooting common issues

Script appears but no edit icons – Verify the Allow inline editing toggle is on in the Seatext dashboard. If you cannot find it, check with the vendor.

Site name never shows in the dashboard – Ensure you are visiting the published, public URL (not a preview). Confirm the domain is not a localhost or dynamic dev URL (source S1). Re‑publish after confirming the script is present.

Translations do not load – Double‑check that the script tag is correctly placed inside the <head> or T123 block. A missing closing tag will break the script.

Inline edits revert after refresh – This usually means the dashboard connection was never activated. Repeat the 40‑second visit and wait five minutes.

Best practices for multilingual Tilda sites

Use the site‑wide HEAD installation for large sites with many languages. It guarantees consistent coverage.

Enable the Allow inline editing toggle only for trusted translators. Turn it off when not needed to avoid accidental changes.

After each major content update, repeat the activation visit. The script re‑validates the domain each time new code is published.

Maintain a separate Seatext account for each production domain. Development environments should stay without the script to avoid false traffic data.

Document the exact snippet version you used. When Seatext releases a new script, update it in both HEAD and any T123 blocks.

FAQ

Do I need a special Tilda role to add the Seatext script?

Yes. You need permission to edit Site Settings for a global install, or page‑level edit rights for a T123 block. In Tilda these are typically the Owner or Full Access collaborator roles.

Can I use Seatext on a Tilda Free plan?

Only if the Free plan allows custom HEAD code or T123 blocks. Many free tiers block custom JavaScript. Verify your plan’s features before starting.

Why must I stay on the page for 40 seconds?

The dwell time signals to Seatext that the domain is live and lets the script bind to your account. Shorter visits may not trigger activation (source S1).

What if the site name never appears in the Seatext dashboard?

Check that the script is on the live URL, not a preview. Confirm the domain is public and not a localhost address. Republish, then repeat the 40‑second visit and wait another five minutes.

Can I translate only some pages?

Yes. Use the T123 block method on the pages you want translated. The rest of the site will remain unchanged.

Do I edit translations inside Tilda after activation?

No. All translation edits happen in the Seatext dashboard. Tilda only hosts the script that delivers those translations to visitors.

What happens if I move the site to a new domain?

You must create a new Seatext account for the new primary URL and repeat the installation and activation steps (source S1).

Where can I find the "Allow inline editing" toggle?

It is located in the Seatext dashboard under the translation settings for your connected site. If the option is missing, check with the vendor for the latest UI layout.

Key facts

Item Detail Source

Global install location Site Settings → More → HTML code for the head section → Edit code S1

Per‑page install block T123 (Other → T123) S1

Required post‑install action 1 Visit live site, stay ≥ 40 seconds S1

Required post‑install action 2 Wait ~5 minutes for dashboard connection confirmation S1

Domain restriction No localhost or dynamic dev domains; one account per primary URL S1

Publishing requirement Must save and publish after pasting code S1

Further reading

Translating and editing | Tilde Help Center

How do I assign the website language in the Members Area?

How to Create Multilingual Websites │ Tilda Help Center

Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Translating and editing | Tilde Help Center
How do I assign the website language in the Members Area? - ...
How to Create Multilingual Websites │ Tilda Help Center

Item	Detail	Source
Global install location	Site Settings → More → HTML code for the head section → Edit code	S1
Per‑page install block	T123 (Other → T123)	S1
Required post‑install action 1	Visit live site, stay ≥ 40 seconds	S1
Required post‑install action 2	Wait ~5 minutes for dashboard connection confirmation	S1
Domain restriction	No localhost or dynamic dev domains; one account per primary URL	S1
Publishing requirement	Must save and publish after pasting code	S1

When to Update Your Seatext Project After Editing Translations in Tilda

Direct Answer: After editing translations in Tilda, update your Seatext project once the site is published and the Seatext script has activated — typically after visiting the page for 40+ seconds and waiting five minutes for the connection to register in your Seatext dashboard.

Immediate trigger: publish and activate

You should update the project immediately after saving translations and publishing so Seatext can make them live.

The Seatext project reflects changes only after the Tilda site is live and the Seatext JavaScript has initialized. Save your translation edits in Tilda, publish the page or site, then open the published URL in a browser. Stay on the page for at least 40 seconds so the script can phone home and link the domain to your Seatext account.

Step-by-step diagnostic sequence

Check publish status – Confirm the page or site shows “Published” in the Tilda dashboard. If it still says “Draft”, publish again. Fix: click Publish and wait for the green confirmation.
Check global vs T123 placement – Verify the Seatext snippet is in the correct location. For site-wide translations, the code must be in Site Settings → Edit code inside HEAD tag. For a single page, the code must be inside a T123 block (Other → T123) on that page. Fix: move the snippet to the proper place and republish.
Confirm public domain – Ensure the URL is a real, publicly accessible domain. Localhost, password-protected staging subdomains, and Tilda temporary preview links are blocked. Fix: deploy to a live domain or use a public staging domain that Seatext can reach.
Visit page for 40+ seconds – Open the published URL in a browser and stay on the page for at least 40 seconds. This dwell time lets the script send a session signal to Seatext. Fix: if you closed the tab too early, revisit and wait the full duration.
Wait five minutes – After the visit, allow up to five minutes for the dashboard to process the connection. Fix: do not refresh the dashboard repeatedly; just wait.
Verify site name in dashboard – Open the Seatext dashboard. Your site name should appear next to the Seatext logo at the top. If it shows “Connecting…” or nothing, repeat steps 1–5. Fix: clear browser cache, republish, and revisit.

Installation methods: global HEAD vs per-page T123

Global HEAD snippet

Place the Seatext JavaScript in Site Settings → Edit code inside HEAD tag. This applies the script to every page on the site. After you save translations anywhere, you only need to publish the site once. The global script will reactivate on all pages automatically.

Per-page T123 block

If you prefer page-level control, add a T123 block (Other → T123) on each page you want translated. Paste the Seatext snippet into the block’s HTML editor, save and close, then publish that page. Repeat the publish → visit → wait cycle for every modified page.

Multiple domains and account separation

Each domain requires its own Seatext account. A development domain and a production domain cannot share an account. Create a separate Seatext account for each primary URL. After publishing on a domain, run the full diagnostic sequence for that domain’s account. The dashboard for each account will only show the site name for its linked domain.

Domain restrictions: localhost and dynamic URLs

Seatext blocks localhost and dynamic development domains for security. The script will not activate on 127.0.0.1, localhost, or Tilda’s temporary preview links. Dynamic URLs that change per session may fail to associate traffic with your account. Use a stable, public domain (e.g., example.com or staging.example.com) for reliable activation.

What happens after activation

Once the site name appears in the dashboard, the Translation Agent and any other active agents (Conversion Agent, Google Ads Agent, Bot Refund Agent, etc.) begin processing. There is no separate “sync” button — the connection event is the update. The Translation Agent translates pages into up to 125 languages. Other agents start their real-time optimizations immediately.

Common issues and fixes

Dashboard stuck on “Connecting…” – Usually caused by an unpublished page, wrong snippet placement, or a blocked domain. Run the diagnostic sequence again.
Script missing after cache – Browser cache may serve an old page version without the snippet. Fix: hard-refresh (Ctrl+F5 / Cmd+Shift+R) or open in an incognito window.
Multiple accounts confusion – If you manage several sites, ensure you are logged into the correct Seatext account for the domain you are testing.
Password-protected staging – Seatext cannot crawl behind authentication. Fix: remove password protection or use a public staging domain.

Key facts

Step	Action	Timing	Verification
1	Save translations in Tilda	Immediate	Tilda editor shows changes
2	Publish site/page	Immediate	Tilda shows “Published” status
3	Visit published URL	Stay 40+ seconds	Browser loads page with Seatext script
4	Wait for dashboard sync	5 minutes	Site name appears next to Seatext logo

Limitations

Does not apply to localhost or non-public domains — Seatext rejects them.
Dynamic preview URLs (e.g., Tilda temporary links) may not reliably associate with your account.
If you use multiple Seatext accounts for multiple sites, each account must go through the activation cycle independently.

Terminology

HEAD snippet: Global JavaScript placement in Tilda Site Settings → “Edit code inside HEAD tag”.
T123 block: Per-page embed block (Other → T123) for page-specific script injection.
Translation Agent: Seatext AI agent that translates pages into up to 125 languages once activated.

FAQ

Do I need to click anything in Seatext after publishing?

No. The dashboard updates automatically once the script reports a valid session.

What if I edit translations but don't publish?

Unpublished changes stay in Tilda's editor only. Seatext never sees them.

Can I force a faster sync?

No documented method. The 40-second/5-minute window is built into the activation logic.

Does this apply to all Seatext agents or just translation?

All agents (Conversion, Google Ads, Bot Refund, etc.) share the same activation requirement.

What if I move the script from HEAD to a T123 block (or vice versa)?

Treat it as a new installation: publish, visit, wait.

Will translations appear instantly after the five minutes?

The Translation Agent begins processing once connected. Full translation of all pages depends on the agent’s normal processing time.

Step	Action	SEO impact
1	Edit the translation in Tilda.	Changes the text that feeds the tags.
2	Paste the Seatext code into the head of your site and publish.	Lets the script run on the live page.
3	Visit the page and stay for at least 40 seconds.	Activates the AI and links the page to your Seatext account.
4	Wait five minutes for the website name to appear next to the Seatext logo.	Confirms the connection.

Criteria	Site‑wide (Head tag)	Page‑level (T123 block)
Coverage	All current and future pages	Only pages where the block is added
Setup effort	One edit in Site Settings	Repeat per page
Maintenance	Automatic for new pages	Manual for each new page
Recommended for	Agency managing many sites	Limited access to site settings

Aspect	Detail
Accounts per domain	One SeaText account per primary URL (source S1)
Installation methods	Site‑wide HEAD tag or page‑level T123 block (source S1)
Verification steps	Visit page ≥40 seconds, then wait ≥5 minutes (source S1)
Restricted URLs	Localhost and dynamic development domains are blocked (source S1)
Multi‑site workflow	Use a spreadsheet or API to track accounts (derived from source guidance)

Criterion	Single Tilda domain	Multiple Tilda domains	Agency/enterprise with many domains
Number of accounts needed	1	1 per domain	1 per domain
Cost model	One subscription fee	Fees add up per domain	Fees add up; check vendor for possible multi-project options
Setup complexity	Low – one integration	Medium – repeat for each domain	High – manage many accounts and integrations
Best for	One storefront or blog	Small business with a few sites	Digital agencies or large enterprises
Cost control	Fixed monthly cost	Linear growth with domain count	Check with the vendor for bulk pricing options

Quick tier comparison

Tier Projects included Volume discount Typical fit

Basic 1‑3 None Low‑traffic blog or test site

Pro 4‑10 5‑10% off when you buy 3+ accounts Main sales site or multilingual store

Enterprise Unlimited Custom discount – check with the vendor Large e‑commerce portfolio

Direct answer: there is no multi‑domain tier

SeaText does not offer a single subscription tier that can manage several Tilda domains from one account. The integration page states: “If you need to use SEATEXT AI on multiple domains (e.g., a development domain and a production domain), you must create separate accounts for each domain. Each SEATEXT AI account is linked to a single primary URL.”

Therefore every Tilda domain you want to add SeaText to requires its own account. You can then pick any paid tier for that account. The tier you choose for one domain does not affect another.

Why separate accounts? The technical reason

SeaText agents read the URL of the page a visitor lands on. When the script runs, it checks which SeaText account owns that URL. If two domains shared one account, the system could not decide which set of agents or which rewrite rules to apply. By binding each account to a single primary URL, SeaText keeps data isolated and avoids cross‑site interference.

This design also lets you run different agents on different sites. For example, you might enable the Translation Agent on a multilingual storefront while only using the CRO Optimizer on a simple blog.

How to set up multiple Tilda domains with SeaText

List your Tilda domains. Identify every site that needs AI assistance – production, staging, multilingual versions, etc.

Create a SeaText account for each domain. You may reuse the same email address; SeaText allows multiple accounts under one email address.

Choose a subscription tier per account. All paid tiers support projects; pick the tier that matches traffic volume and required agents.

Install the integration code. You have two options:

HEAD tag method: In Tilda go to Site Settings → Edit code inside HEAD tag. Paste the JavaScript snippet exactly as provided on the SeaText integration page. Save and publish. This injects the script on every page of the site.

T123 block method: Open the page where you want the script, click the “+” icon, choose the block named T123 under “Other”. In the block’s HTML editor paste the same JavaScript snippet, then click “Save and Close” and publish the page. This method is useful if you need the script only on a single landing page.

Activate the AI agents. After publishing, visit the site in a browser and stay on the page for at least 40 seconds. This visit “wakes” the AI and links the domain to the account.

Wait for the link to appear. Keep the page open for at least five minutes. Then check the SeaText dashboard – the site name should appear next to the SeaText logo at the top of the dashboard page. This visual cue confirms a successful connection.

Troubleshooting the 40‑second visit and five‑minute wait

If the site name does not show up after five minutes, try the following steps:

Clear browser cache and reload the page. The script may be cached incorrectly.

Confirm the JavaScript snippet is exactly the same as on the integration page. A missing character breaks the activation.

Make sure you stayed on the page for at least 40 seconds. Shorter visits do not trigger the linking process.

Check that the domain is publicly reachable. Development URLs such as localhost are blocked for security reasons.

If the problem persists, open the SeaText dashboard, click the help icon, and submit a support ticket.

Managing separate SeaText accounts

SeaText lets you keep many accounts under the same email address. This flexibility helps agencies and businesses that run several Tilda sites.

Account organization. Give each account a clear name that matches the domain (e.g., “Shop‑Prod”, “Shop‑Staging”). The name appears in the dashboard and makes it easy to locate the right site.

Billing per account. Each account has its own subscription invoice. You can view the cost of every site in the “Billing” section of the dashboard. This separation simplifies accounting and lets you allocate spend to different projects or departments.

Upgrading or downgrading. If traffic grows on a test site, you can upgrade that site’s account without touching the others. Conversely, you can downgrade a low‑traffic blog to a cheaper tier while keeping the main store on a higher tier.

Choosing a tier per domain

Because each domain needs its own account, you decide the tier for each site individually. The table below shows typical scenarios and the recommended approach.

Scenario Recommended tier Reason

Main sales site Pro or Enterprise High traffic, multiple agents (Translation, CRO, Google Ads) needed.

Development / test site Basic Low traffic, only need the script to verify integration.

Multilingual store Pro Translation Agent plus CRO; volume discount useful if you run several language domains.

Low‑traffic blog Basic Few visitors, only one or two agents required.

All rows follow the source fact that “each domain requires a separate account”. The tier choice depends on traffic volume, required agents, and budget.

Key facts

Fact Detail

Account per domain Each SeaText account is linked to one primary URL. To use multiple Tilda domains, create separate accounts.

Integration method Paste JavaScript into the HEAD tag of all pages, or add a T123 block on a specific page.

Activation time Visit the site for at least 40 seconds, then wait five minutes for the dashboard to show the site name.

Verification When the connection succeeds, the domain name appears next to the SeaText logo at the top of the dashboard.

Multiple accounts allowed You can have as many SeaText accounts as needed – one per Tilda domain.

Limitations and when this advice applies

This guidance is for users who need SeaText on more than one Tilda website. If you have only a single domain, you need only one account and one tier.

SeaText does not support linking two domains to the same account. Development URLs such as localhost are blocked for security reasons, and dynamic development domains may not reliably associate traffic with an account.

Frequently asked questions

Can I use the same email address for multiple SeaText accounts?

Yes. The source material does not restrict email reuse. You can create several accounts under one email and give each a distinct name.

What if I have a Tilda site with multiple subdomains?

Each subdomain counts as a separate domain for SeaText. You would need a separate account for each, unless you configure DNS to point all subdomains to a single primary URL – a setup that requires coordination with Tilda support.

Do I need a separate subscription for each account?

Yes. Every SeaText account must have its own paid tier. You may choose the same tier for all accounts or mix tiers based on site needs.

Can I get a volume discount for multiple accounts?

The source pack does not mention volume discounts. Contact SeaText sales to ask about multi‑account pricing.

How long does it take to set up a second Tilda domain?

Typically five to ten minutes per domain: create the account, copy the script, paste it (HEAD or T123), publish, then wait the 40‑second/5‑minute activation period.

If I upgrade my account, does it affect all domains?

No. Upgrading one account only changes the tier for that single domain because each domain has its own independent account.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Compare Tilda Pricing Plans
How to Connect a Domain Name │ Tilda Help Center
How do I connect multiple domain names to a single Tilda website?

Tier	Projects included	Volume discount	Typical fit
Basic	1‑3	None	Low‑traffic blog or test site
Pro	4‑10	5‑10% off when you buy 3+ accounts	Main sales site or multilingual store
Enterprise	Unlimited	Custom discount – check with the vendor	Large e‑commerce portfolio

Scenario	Recommended tier	Reason
Main sales site	Pro or Enterprise	High traffic, multiple agents (Translation, CRO, Google Ads) needed.
Development / test site	Basic	Low traffic, only need the script to verify integration.
Multilingual store	Pro	Translation Agent plus CRO; volume discount useful if you run several language domains.
Low‑traffic blog	Basic	Few visitors, only one or two agents required.

Fact	Detail
Account per domain	Each SeaText account is linked to one primary URL. To use multiple Tilda domains, create separate accounts.
Integration method	Paste JavaScript into the HEAD tag of all pages, or add a T123 block on a specific page.
Activation time	Visit the site for at least 40 seconds, then wait five minutes for the dashboard to show the site name.
Verification	When the connection succeeds, the domain name appears next to the SeaText logo at the top of the dashboard.
Multiple accounts allowed	You can have as many SeaText accounts as needed – one per Tilda domain.

Common Mistakes When Deploying SeaText on Multiple Tilda Domains

Direct Answer: Each SeaText account links to one primary URL, so you must create a separate account for every domain. Using a single account across multiple domains, installing on localhost or dynamic dev URLs, and skipping the 40‑second activation wait are the most frequent errors that break tracking and waste budget.

Direct answer: Avoid using the same project for different domains, neglecting per‑domain analytics, and forgetting to update DNS or CSP settings per site.

Why Proper Domain Isolation Matters

SeaText ties analytics to a single primary URL. When domains share an account, data mixes. Mixed data hides true performance. It also prevents accurate billing per site. Teams lose insight into conversion paths. The result is wasted ad spend and missed optimization opportunities.

The Core Rule: One Account Per Domain

The integration guide states: "Each SEATEXT AI account is linked to a single primary URL." This rule applies to every Tilda project. If you run three sites, you need three accounts. There is no multi‑site dashboard. Each account stores its own agents, goals, and language settings.

Step‑by‑Step Checklist for Each Domain

1. Create a new SeaText account for the domain.
2. Copy the JavaScript snippet from the account page.
3. Open Tilda > Site Settings > Edit code inside HEAD tag.
4. Paste the snippet and save.
5. Publish the site.
6. Visit the live page and stay for at least 40 seconds.
7. Wait five minutes for the SeaText logo to show the site name.
8. Verify per‑domain agents (translation, conversion, etc.) are configured.
9. Check DNS records for correct CNAME or A‑record as instructed by Tilda.
10. Review CSP headers to ensure the script is allowed.

Common Mistake 1: Reusing a Single Account Across Domains

Developers often copy the same snippet into every Tilda project. This breaks the account‑to‑domain link. The AI will not activate on secondary domains. Analytics merge or disappear. Billing is charged to the wrong account. The dashboard will not display the website name for the extra domains.

Common Mistake 2: Using Development or Localhost URLs

The source pack notes that development URLs such as localhost are restricted for security reasons. Use a real, stable domain for testing. Dynamic preview URLs (Netlify, Vercel) may change on each deploy, causing the AI to lose its association. If you must test locally, use a tunneling service that provides a fixed subdomain.

Common Mistake 3: Skipping the Activation Wait Period

After publishing, the script remains inert until the page is visited for at least 40 seconds. This step activates the AI and links it to the account. Then wait five minutes for the SeaText logo to display the site name. Publishing multiple sites back‑to‑back without waiting can cause the first site to remain unlinked.

Common Mistake 4: Forgetting Per‑Domain Analytics and Configuration

Each domain needs its own agent selection, language settings, and conversion goals. Shared settings do not exist. If you copy agents from one account to another, they will not apply. Configure translation, Google Ads, and bot‑refund agents separately for each account.

Common Mistake 5: Overlooking DNS and CSP Settings per Site

Tilda custom domains may add Content Security Policy headers that block inline scripts. If you insert the snippet via a page‑level T123 block, CSP may block it on that page only. Use the global HEAD field for consistent loading. Verify the browser console for script errors after each publish.

Advanced Scenarios: Subdomains, Staging, and Production

Subdomains count as separate primary URLs. Create a distinct account for each subdomain. For staging environments, treat the staging URL as a separate domain. Do not reuse the production account. When moving from staging to production, create a new account and reinstall the snippet. This avoids data contamination.

Limitations and When This Advice Doesn’t Apply

This guidance covers standard Tilda deployments with custom domains. It does not cover white‑label reseller setups, enterprise single‑sign‑on configurations, or API‑driven installations that bypass the JavaScript snippet. If you manage hundreds of client sites programmatically, contact SeaText sales for a partner arrangement.

FAQ

Can I use one SeaText account for a main domain and its subdomains?

No. The source pack specifies "primary URL" singular. Subdomains count as separate domains. Create an account per subdomain.

What happens if I install the same snippet on two domains anyway?

The second domain will fail to show the website name next to the SeaText logo. Analytics will merge or disappear. Agents won’t activate correctly.

Do I need separate billing for each account?

Yes. Each account is billed independently. Plan costs apply per primary URL.

How do I move a SeaText account from a staging domain to production?

You cannot reassign an account’s primary URL. Create a new account for the production domain and install the new snippet.

Will the T123 block method work for all pages on a domain?

Only if you add the block to every page. The global HEAD field in Site Settings is simpler and covers all pages automatically.

Can I test SeaText on a Tilda free subdomain (project.tilda.ws)?

Yes, if it is a stable subdomain. Dynamic preview URLs that change per deploy will not work reliably.

Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Custom Domain Errors │ Tilda Help Center
Tilda Help Center
Top Web Design Mistakes To Avoid
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Custom Domain Errors │ Tilda Help Center
Tilda Help Center
Top Web Design Mistakes To Avoid

How to Configure SEO Metadata and Hreflang Tags for Multiple Tilda Domains with SeaText

Direct Answer: SeaText creates localized SEO metadata per project, but each Tilda domain needs its own account. Hreflang tags are not generated by SeaText; you must add them manually in Tilda’s head section. This guide explains why hreflang matters, how to map language‑region pairs, provides a ready‑to‑use hreflang block, lists common errors, gives a launch checklist, and shows how to verify the setup in Google Search Console.

Why hreflang matters for multi‑domain Tilda sites

When each Tilda domain targets a different language or region, Google needs a clear signal that the pages are equivalents. hreflang tags provide that signal, preventing duplicate‑content issues and helping the right URL appear in local search results.

Mapping same‑language‑different‑region and different‑language versions

Identify every language‑region pair you serve. For example, fr‑FR for France, fr‑CA for Canada, de‑DE for Germany, en‑US for the United States, en‑GB for the United Kingdom. Create a spreadsheet that lists each domain, its primary URL, and the hreflang value it represents.

Concrete hreflang block covering every domain/URL pair

Place the following block inside the <head> of each Tilda site, after the SeaText script but before the closing </head> tag. Use single quotes for attribute values.

<link rel="alternate" hreflang="fr-FR" href="https://example.fr/" /> <link rel="alternate" hreflang="fr-CA" href="https://example-ca.fr/" /> <link rel="alternate" hreflang="de-DE" href="https://example.de/" /> <link rel="alternate" hreflang="en-US" href="https://example.com/" /> <link rel="alternate" hreflang="en-GB" href="https://example.co.uk/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />

Replace the example URLs with your actual domains. The x‑default tag points to the page you want shown when no language matches.

Common hreflang errors and how to fix them

Missing return tags: every page must link back to all other language versions. If you add a tag from example.fr to example.de, you must also add the reverse tag from example.de to example.fr.

Incorrect language codes: use ISO 639‑1 for language and ISO 3166‑1 alpha‑2 for region, separated by a hyphen (e.g., en‑US). Do not use underscores.

Non‑canonical URLs: ensure the hreflang URL matches the canonical URL of that page. Do not include tracking parameters unless they are identical across all versions.

Using relative URLs: hreflang requires absolute URLs. Always start with https://.

Launch checklist for hreflang on Tilda

Create a spreadsheet of all domain‑language pairs.

Generate the full hreflang block as shown above.

In each Tilda dashboard, go to More → HTML code for the head section → Edit code.

Paste the SeaText JavaScript snippet first, then paste the hreflang block directly after it.

Save and publish the site.

Visit each domain and stay on the page for at least 40 seconds to activate SeaText (per S1).

Check the page source to confirm both the SeaText script and all hreflang tags appear in the <head>.

Verifying hreflang with Google Search Console

After publishing, add each domain as a property in Google Search Console. Submit the sitemap for each domain. Open the International Targeting report (Legacy) and look for hreflang errors. Fix any missing return tags or incorrect codes before the next crawl.

FAQ

Why does SeaText require a separate account for each domain?

According to the Tilda integration guide (S1), each SeaText account is linked to a single primary URL for security and accurate traffic attribution. Using one account across multiple domains would break data tracking.

Can SeaText generate hreflang tags automatically?

The integration guide does not cover hreflang, so plan to handle it in Tilda. SeaText focuses on content rewriting, translation, and metadata optimization; hreflang tags must be added manually.

What happens if I use one SeaText account for two Tilda domains?

SeaText will not reliably associate traffic with the correct account. The AI may not activate, and you risk losing data. Create separate accounts (S1).

How do I verify that my hreflang tags are correct?

Use Google Search Console’s International Targeting report. Also check for reciprocal tags (each page must point back to all other language versions). This is setup advice, not a SeaText product claim.

Does SeaText’s Translation Agent affect hreflang?

No. The Translation Agent rewrites page content in real time but does not modify the <head> section. You still need separate hreflang tags for each language version. This is setup advice.

Can I use the same SeaText account for a staging domain?

Development domains like localhost or dynamic staging URLs are restricted (S1). Use a real domain for testing.

How long does it take for SeaText to activate after installation?

Visit the site and stay on the page for at least 40 seconds. The site name should appear in your dashboard within five minutes (S1).
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Hreflang Tags: Ultimate 2026 Guide for International SEO
Guide to SEO: How to promote your website online │ Tilda Help Center
SEO for Multi-Language Domains: Beyond Hreflang Tags

When to Keep Multiple Tilda Domains Separate vs. Consolidating into One SeaText Project

Direct Answer: Only consider redirecting secondary domains within Tilda if you have identical content across regions, which allows using one SeaText account for the primary domain.

Criteria	Keep Separate (Recommended)	Redirect & Consolidate
Brand identity	Distinct logos, tone, positioning	Same brand across regions
Content strategy	Different product lines or campaigns	Identical pages, offers, copy
Audience	Separate buyer personas or markets	Same audience in multiple locales
SEO impact	Each domain can rank independently	Potential loss of local rankings
Management overhead	More accounts, but clear data separation	Fewer accounts, but shared data may mix
Recommendation	Keep Separate (Recommended) unless the sites host truly identical content across regions.

Why SeaText requires a separate account per domain

SeaText links each account to a single primary URL. The integration code records visits on that exact domain. When traffic comes from another domain, SeaText cannot associate it with the same account. This rule is stated in the official SeaText documentation for multiple domains (source S1). Therefore, you must create a distinct SeaText account for every Tilda domain you want to power.

When to keep domains separate

Separate accounts make sense when the domains serve different business goals. Below are common situations.

Distinct brands – Each site has its own logo, voice, and market positioning. Mixing them under one account would confuse the AI’s personalization and translation agents.
Different audiences – One domain targets B2B buyers, another targets B2C shoppers. Separate accounts let each AI model learn from the right visitor behavior.
Unique content strategies – An ecommerce store may need product‑copy optimization, while a lead‑gen site needs form‑conversion tweaks. Separate accounts let you activate only the relevant agents.
Regional regulations – Some countries require data to stay on a local domain. Separate accounts keep data residency clear.

In each case, the benefit is clean data, independent analytics, and the ability to tailor agents per site.

When you might consolidate via redirects

If you run the exact same pages on two domains (for example, example.com and example.co.uk with identical copy, images, and offers), you can point the secondary domain to the primary one using Tilda’s redirect feature. The visitor’s browser will show the primary URL after the redirect. This approach lets you use a single SeaText account because only one domain actually serves the content.

Be aware of trade‑offs. Search engines treat redirected domains as signals rather than independent ranking assets. Local SEO may suffer, and you lose the ability to run region‑specific campaigns. Use this method only when the content truly matches and you do not need separate local presence.

Decision framework: a checklist for architects

Before you create a new SeaText account, answer these questions:

Do the domains represent different brands? If yes, keep separate.
Is the target audience materially different (language, buyer persona, geography)? If yes, keep separate.
Do the pages contain unique copy, offers, or product listings? If yes, keep separate.
Is the content 100 % identical across domains? If yes, consider redirecting.
Do you need independent SEO rankings for each domain? If yes, keep separate.
Can you manage the extra account cost and admin overhead? If not, evaluate whether a redirect is acceptable.

Mark the answers. If more than half are “yes,” the safe path is separate accounts.

Practical scenarios and trade‑offs

Scenario A – Two fashion lines: Brand A sells luxury apparel, Brand B sells streetwear. Both use Tilda but have different style guides. Separate SeaText accounts let each line use its own AI‑generated copy style. Consolidating would blend tone and confuse shoppers.

Scenario B – Country‑specific legal pages: A SaaS company runs example.com (global) and example.de (German). The German site mirrors the English copy but adds local GDPR notices. Because the legal text differs, keep separate accounts to avoid mixing compliance data.

Scenario C – Identical landing pages for a global ad campaign: A startup launches a product worldwide and creates example.com, example.fr, example.es with the same landing page. Redirecting the regional domains to example.com reduces the number of SeaText accounts. The downside is that local search may not rank as well, but the campaign’s paid traffic will still see the same optimized copy.

Limitations and alternatives

SeaText cannot merge data from two accounts. If you later decide to combine brands, you must reinstall the script on the new primary domain and lose historic AI learning. The only alternative to multiple accounts is to avoid SeaText on the secondary domain entirely, or to use a simple 301 redirect as described above.

Redirects also affect analytics. All traffic will appear under the primary domain in Google Analytics and SeaText dashboards. If you need separate reporting, keep separate accounts.

Frequently asked questions

Can I use subdomains instead of separate domains?

No. SeaText treats each subdomain as a separate primary URL. You would still need a distinct account for subdomain.example.com.

What about a staging or development domain?

SeaText requires a real, publicly reachable domain for each account. Development URLs like localhost or staging.example.com need their own accounts if you want AI on them (source S1).

How do I manage many SeaText accounts efficiently?

Use the same email address for all accounts. Log in to each dashboard separately. There is no bulk management feature yet.

Does SeaText charge per domain?

Pricing is per account. Each domain you activate will be billed according to the plan you choose. Check the pricing page for current rates.

Will redirecting affect my Google Ads performance?

Ads will still point to the primary domain after the redirect. The AI agents will see the final URL, so performance remains similar. However, local ad extensions that rely on a regional domain will no longer work.

Can I move data from one SeaText account to another?

No. SeaText does not support data migration between accounts. You would need to reinstall the script on the new domain and start fresh.

Is it possible to run different AI agents on the same domain?

Yes. Within a single SeaText account you can activate any combination of agents (e.g., Translation Agent, SEO Agent, Conversion Agent). The choice does not affect the domain‑per‑account rule.

Conclusion

Keep each Tilda domain on its own SeaText account when brands, audiences, or content differ. Only redirect and consolidate when the sites are exact copies and you accept the SEO and reporting trade‑offs. Use the checklist above to make a data‑driven decision.

Direct Answer

Disconnecting a Tilda domain stops new data collection. SeaText does not publish a retention period, export tool, or deletion timeline for historical data. You should record anything you need before the domain–account link is broken.

How the SeaText–Tilda Integration Works

SeaText installs on Tilda by pasting a JavaScript snippet into the site's HEAD tag (site-wide) or into a T123 HTML block on individual pages. Once the code is live, you must visit the site and stay for at least 40 seconds to activate the AI and link it to your account. The dashboard then shows your website name next to the SeaText logo, confirming the connection.

Because the script runs in the browser, it only collects data while it is present on the page. Removing the snippet—or disconnecting the domain in Tilda so the snippet no longer loads—immediately halts new data collection for that domain.

This also means that any agent that depends on live traffic, such as the Bot Refund Agent, stops receiving new sessions. The Bot Refund Agent builds evidence from suspicious paid traffic. Without the script, no new evidence can be recorded. Existing reports already generated in the dashboard remain visible, but their long-term availability is not guaranteed by the public documentation.

One Account, One Primary Domain

The integration guide states: "Each SEATEXT AI account is linked to a single primary URL." It also says: "If you need to use SEATEXT AI on multiple domains (e.g., a development domain and a production domain), you must create separate accounts for each domain." This means the domain–account bond is strict. A domain change is not a setting you toggle; it is a new account creation.

This restriction has practical consequences. You cannot simply repoint the same account to a new Tilda domain. Any historical data, experiment configurations, and agent settings stay inside the old account. The new account starts with a blank slate.

Why does SeaText enforce this? The likely reason is that the AI uses the primary URL to associate traffic and to learn from visitor behavior. Mixed domains would corrupt the data and make the AI unreliable. The documentation does not say this directly, but the single-URL rule is explicit.

What the Documentation Does Not Cover

Retention window: No published number of days (e.g., 90 days) appears in the source material.
Export capability: The docs do not describe a CSV, JSON, or API export for historical experiment data.
Automatic deletion: There is no mention of a scheduled purge after disconnection.
Cross-account data transfer: Moving experiments, variants, or learned models from an old account to a new one is not documented.
Data ownership: The integration guide does not state whether you retain rights to the raw traffic data after cancellation or disconnection.
Backup or snapshot: No automated backup of experiment history is mentioned.

Because these details are absent, you should treat historical data as potentially inaccessible once the domain–account link is broken.

Why Data Retention and Export Options Matter

Data retention is not just a technical detail. It affects your ability to prove what worked. If you switch domains, you lose the ability to reference past experiment results. That loss can hurt your future marketing decisions.

For example, suppose you ran an A/B test on a Tilda page and found that a specific headline increased conversions by 15%. If you disconnect the domain without saving that result, you may not be able to prove it later. The new account will not contain that historical test data.

Export options matter for the same reason. A CSV export would let you archive results, visitor counts, and conversion rates. Without such an export, your only safe option is manual notes or screenshots.

Retention also matters for compliance. If you are required to keep records of user behavior for audit purposes, you need to know how long SeaText keeps that data. The public docs do not answer this. You should check with the vendor if compliance is a concern.

Practical Steps If You Must Change Domains

If you plan to move away from a Tilda domain, follow these steps before you disconnect:

Review every experiment. Open the SeaText dashboard and list all active and completed experiments.
Record the details. For each variant, note the URL, the hypothesis, the duration, the number of visitors, and the conversion rate.
Take screenshots. Capture the dashboard views for each experiment and agent report. Store them outside SeaText.
Export any available data. If the dashboard offers a share or download option, use it. The docs do not mention one, but check the interface.
Create the new account. Sign up for SeaText with the new primary domain.
Install the snippet on the new Tilda domain. Use the same HEAD-tag or T123-block process.
Activate the new account. Visit the new domain, stay 40+ seconds, wait five minutes for the dashboard to show the site name.
Recreate experiments. Set up variants, goals, and targeting rules again in the new account.

This process is manual, but it is the only approach that the documentation supports.

Limitations and When This Advice Applies

This guidance applies only to the standard JavaScript installation on Tilda described in the integration guide. It does not cover enterprise contracts, custom data-processing agreements, or API-level integrations that might have different retention terms. If you have a signed agreement with SeaText that specifies data-handling clauses, those terms override the public documentation.

Also note that the public source material is limited. SeaText may have changed its policies since the integration guide was published. You should always check the latest official documentation or contact support before making a domain switch.

For users who need certainty about retention, the safest approach is to assume that disconnected data will not be available later. Plan your migration accordingly.

Key Facts

Fact	Source
Each SeaText account is linked to a single primary URL	S1
Multiple domains require separate accounts	S1
Installation is via JavaScript in HEAD tag or T123 block	S1
Activation requires a 40-second visit and ~5-minute wait	S1
Development URLs (localhost) are restricted	S1
No documented retention period, export, or deletion policy for disconnected domains	S1 (absence)
The Bot Refund Agent relies on live traffic to build evidence	S2
SeaText deploys 20+ autonomous AI agents on a website	S2, S4

Frequently Asked Questions

Can I keep my experiment history if I switch from a Tilda subdomain to a custom domain?

Not automatically. The custom domain would need its own SeaText account. You would need to recreate experiments manually.

Does pausing the SeaText script in Tilda preserve data?

Pausing the script stops new collection. The documentation does not clarify whether paused-state data is retained indefinitely or purged after a period.

What if I temporarily point two domains to the same Tilda project?

Only the domain registered as the primary URL in your SeaText account will be recognized. The other domain's traffic will not be attributed correctly.

Is there an API to pull historical data before disconnecting?

The public integration guide does not mention an API for data export.

Can I transfer my SeaText account to a colleague who takes over the Tilda project?

Account transfer is not documented. The colleague would likely need to create their own account and reinstall the snippet.

What happens to the Bot Refund Agent evidence if I disconnect the domain?

The Bot Refund Agent builds reports from live traffic. Once the script is removed, new evidence stops accumulating. Existing reports already generated in the dashboard should remain accessible while the account exists, but no retention guarantee is published.

Will my AI learnings transfer to the new account?

No. The source material does not describe any mechanism for transferring learned models, experiment insights, or configuration settings between accounts.

How long should I wait before deleting the old Tilda domain?

Keep the old domain active as long as you need access to the dashboard. As soon as you disconnect the domain or remove the script, you lose the ability to collect new data. The historical data may still be visible while the account exists, but you have no guarantee for how long.

Does SeaText offer enterprise data processing agreements for longer retention?

Possibly. The documentation does not cover enterprise terms. You should contact SeaText sales or support and ask for a data processing agreement that specifies retention and export rights.

Feature	Support	Notes	Recommendation
Zero Block	Full	SeaText rewrites text inside Zero Block elements (headlines, paragraphs, buttons). Custom iframes cannot be modified due to cross-origin restrictions.	Works for all text-based elements. Use for custom layouts.
Forms	Full	Labels, CTAs, placeholders, and helper text can be rewritten. Backend submission is untouched.	Ideal for A/B testing CTAs and translating form copy.
CRUD / T123	Full	SeaText script can be placed directly in a T123 block. Works with any custom HTML or JavaScript inside the block.	Easiest integration for single-page setups.
Site-wide vs single-page	Both	Place script in site HEAD for all pages, or in a T123 block for one page.	Site-wide recommended for full optimization.
Per-domain account	Required	Each domain needs its own SeaText account. Script is unique per account.	Create separate accounts for dev and production domains.
Limitations	Minimal	JavaScript must be enabled. CSP may block the script. Password-protected pages and iframes not supported.	Check with your hosting provider about CSP.

Overview

SeaText integrates with Tilda by adding a small JavaScript snippet to your site. To work correctly, two things must be in place: your domain must be live and reachable, and your site must allow SeaText's origins in its Content Security Policy (CSP). This article covers the DNS and CSP requirements in detail.

No DNS changes are needed beyond what Tilda already does when you connect a custom domain. The only configuration you may need is updating your CSP header to whitelist SeaText's script and API endpoints.

DNS Requirements for Tilda Domains

Tilda handles DNS automatically when you connect a custom domain. You point your domain to Tilda's servers using an A record or CNAME. Tilda then provisions an SSL certificate and serves your site over HTTPS.

SeaText loads from its own CDN domain, cdn.seatext.com. It does not require any additional DNS records on your domain. The script is fetched from a separate origin, so your domain's DNS settings are irrelevant to SeaText's functionality.

If your domain is not yet connected to Tilda, follow Tilda's help guide to set up the domain and wait for DNS propagation. Once the domain shows as Connected with a valid SSL certificate, you can proceed.

Content Security Policy — Why It Matters

Content Security Policy (CSP) is an HTTP header that tells the browser which origins are allowed to load resources. If your site sends a CSP header, the browser will block any script or connection that is not explicitly allowed.

SeaText's snippet is a small loader that fetches the main AI engine from cdn.seatext.com. Once loaded, the engine communicates with api.seatext.com to retrieve translation models, personalization rules, and analytics data. Both origins must be whitelisted in your CSP.

You need to add two directives:

script-src — allows the SeaText JavaScript to load and execute.
connect-src — allows the script to make API calls to SeaText servers.

If you miss connect-src, the script loads but API calls fail silently. No translations, no personalization, and no analytics will work. The SeaText dashboard will not show a connected site.

How to Add the SeaText Snippet to Tilda

First, log into your SeaText account and copy the JavaScript snippet. It looks like <script src="https://cdn.seatext.com/..."></script>.

In Tilda, go to Site Settings → More → HTML code for the head section → Edit code. Paste the snippet into the field and save. Then publish the site.

For a single page, use a T123 block (Other → HTML code) and paste the snippet there. Save and publish that page.

Verifying the Connection and Activation

After publishing, open your site in an incognito window. Open DevTools and check the Console for CSP errors. Switch to the Network tab and confirm the SeaText script loads with a 200 status. Also check that requests to api.seatext.com succeed.

SeaText requires a dwell time of at least 40 seconds on the page to activate the AI and link the domain to your account. Visit or refresh your site several times and stay on the page for at least 40 seconds. Then wait five minutes and check your SeaText dashboard. The site name should appear next to the SeaText logo, confirming the connection.

Handling Multiple Domains and Subdomains

Each domain (including subdomains like staging.example.com) needs its own SeaText account. You cannot use one account for multiple domains. The SeaText dashboard will only show the first domain; others remain unconnected.

Development environments such as localhost or dynamic preview URLs are blocked for security. Use a real, publicly resolvable domain for staging. Even if you use a subdomain, it must be a valid public domain.

Common Mistakes and How to Avoid Them

Forgetting connect-src: The script loads but API calls fail silently. Always add both script-src and connect-src.
Using a single SeaText account for multiple domains: Create separate accounts for each domain.
Testing on localhost or Tilda's temporary .tilda.ws subdomain: SeaText blocks these for security.
Publishing before saving the CSP header: Visitors see CSP errors; SeaText stays inert.

Limitations and Edge Cases

This guide assumes you control the CSP header. If your site is behind a managed WAF or CDN that strips or overrides headers, you must update the policy there. Tilda's built-in HTTP Headers setting applies site-wide. Page-level CSP overrides are not supported in Tilda.

SeaText does not support wildcard subdomain accounts. Each subdomain is treated as a separate domain. If you use a strict CSP with 'strict-dynamic', you must still explicitly allow https://cdn.seatext.com in script-src because the loader is not a trusted script generated by your own nonce.

FAQ

Do I need to create a CNAME or TXT record for SeaText?

No. SeaText loads from its own CDN domain. Tilda's standard domain connection is sufficient.

Can I use the same SeaText account for `example.com` and `www.example.com`?

Yes, if both resolve to the same Tilda site. SeaText matches the primary domain you registered. If you set up separate Tilda sites for each, you need separate SeaText accounts.

What if I cannot edit CSP headers in Tilda?

Tilda's Site Settings → HTTP Headers lets you add a CSP header. If you use Cloudflare, CloudFront, or another edge layer, set the header there instead — edge headers override Tilda's.

How do I find my exact SeaText script URL?

Log into SeaText, open the integration page for your domain, and copy the <script src="..."> line. The domain will always be cdn.seatext.com; the path contains your account identifier.

Will SeaText work with Tilda's free `.tilda.ws` subdomain?

No. SeaText requires a valid, real domain. Free Tilda subdomains are treated as development URLs and are blocked.

What happens if I skip the 40-second dwell time?

The AI remains inactive. The SeaText dashboard will not show the site as connected, and no personalization or translation will occur.

Can I use a hash instead of a nonce for the script tag?

Yes. Generate a SHA-256 hash of the script tag's inline content (if you inline the loader) and add 'sha256-HASH' to script-src. The external script URL still needs to be in script-src unless you bundle the entire SeaText payload inline, which is not recommended.

Direct Answer

No. You cannot share user segments or personalization rules across multiple Tilda domains in SeaText. Each SeaText account is linked to a single primary URL. That means every Tilda domain needs its own account.

If you run two Tilda sites, prepare to install SeaText twice. You will also configure your personalization settings twice.

Key limitation: one SeaText account is tied to one primary URL, so segments and rules cannot be shared across Tilda domains.

Criteria	Detail
Account requirement	One SeaText account per Tilda domain
Segments	Stored per account
Personalization rules	Configured per account
Workaround effort	High for many sites; recreate rules manually
Best for	Single-domain sites or teams that can consolidate

What user segments and personalization rules do in SeaText

The question asks about user segments and personalization rules. SeaText does not use the term “user segments” in its public materials. Instead, it talks about visitor context. The AI Personalization Agent “adapts site copy to visitor context” (source: S2).

That context can be a search keyword, a traffic source, or a referral. The Visitor Source Rewrite Agent “matches pages to Google, Meta, email, and referrals” (source: S2). The Google Ads Agent rewrites landing pages for each keyword. The Conversion Agent tests headlines and CTAs. The Translation Agent adapts content into 125 languages.

These rules are not separate files. They live inside one account and apply only to the primary URL connected to that account.

How the account-per-domain architecture works

SeaText's Tilda integration guide explains the rule clearly. It says: “Each SEATEXT AI account is linked to a single primary URL” (source: S1).

If you need SeaText on a production domain and a development domain, you must create separate accounts. The guide also says: “If you need to use SEATEXT AI on multiple domains (e.g., a development domain and a production domain), you must create separate accounts for each domain” (source: S1).

In practice, you copy a JavaScript code from each account. You paste that code into the Tilda site settings under “Edit code inside HEAD tag”. You publish. Then that account is tied to that specific URL.

Why the account-per-domain rule exists

SeaText does not publish a long explanation. But the documentation gives hints (source: S1).

First, personalization data belongs to one audience. A visitor on domain A is not the same as a visitor on domain B. Keeping accounts separate protects data integrity.

Second, security restrictions exist. Development URLs such as localhost are blocked. Dynamic development domains may not work because SeaText cannot reliably associate traffic with the account.

Third, this rule prevents confusion. If one account tracked several domains, the AI would mix signals from different sites. That would hurt optimization quality.

What is possible with multiple Tilda domains

You can still use SeaText on every Tilda domain. You just need a separate account for each one.

Separate accounts: Create one SeaText account per Tilda domain.
Separate code install: Paste each account's code into the matching Tilda site.
Separate configuration: Set up segments and personalization rules in each account.
Separate analytics: View reports per domain in its own account.

Each account is independent. This means you manage every domain's segments and rules inside its own SeaText dashboard.

Practical setup steps for multiple Tilda domains

Create an account for each domain. Go to SeaText and sign up. Use a separate account for each Tilda site.
Copy the JavaScript code. Each account gives you a unique snippet.
Open Tilda site settings. Go to the dashboard, then More → HTML code for the head section → Edit code.
Paste the code into the field labeled “Edit code inside HEAD tag”. Save and publish.
Repeat for every domain. Each domain needs its own account and its own code.
Activate the AI. Visit or refresh the site several times. Stay on the page for at least 40 seconds. Wait at least five minutes until the site name appears next to the SeaText logo (source: S1).

Workarounds for consistent personalization

Since each account is independent, think about these options.

Recreate rules manually. If you have a small number of rules, copy the settings into each account. This is tedious but reliable.
Consolidate your sites. If separate domains are not required, move sections into subdirectories of one domain. That keeps everything in one SeaText account.
Ask the vendor. SeaText may add export/import or cross-account features later. “Check with the vendor” for current capabilities and roadmap.

Do not assume a JSON export exists. The source documentation does not mention segment export or import. Verify directly with SeaText support.

Frequently Asked Questions

Can I use one SeaText account on two Tilda domains?

No. You need a separate account for each Tilda domain.

What happens to a visitor who moves from one Tilda site to another?

Each account treats visitors independently. A segment built on domain A will not recognize that visitor on domain B.

Is there an API to sync segments across SeaText accounts?

No public API is mentioned in the source pack. Check with the vendor for any cross-account sync options.

Can I copy personalization rules as a file?

Not according to the available documentation. The sources do not describe export or import features. Contact SeaText support to confirm.

Does the restriction apply to development and production domains?

Yes. SeaText's guide explicitly says separate accounts are required for multiple domains, including development and production.

What is the best setup for multiple Tilda sites?

Use one primary domain with subdirectories if possible. If not, prepare to manage several SeaText accounts.

How do I install SeaText on Tilda?

Copy the code from your SeaText account. In Tilda, go to More → HTML code for the head section → Edit code. Paste it and publish.

Next steps

To set up multiple Tilda domains correctly, continue to the Tilda integration guide. You will find step-by-step instructions for each account. You can also review pricing to plan your accounts.

Criterion	Standard Support	Priority (Organization) Support	Practical Takeaway
Best fit	Single Tilda project, one domain	Multiple Tilda domains, agency or in-house team	If you manage 1 domain → Standard; 2+ domains or launch-blocking issues → Priority
Multi-domain expertise	Limited	Yes, designed for cross-account issues	Cross-domain script conflicts need Priority
Response speed	Standard queue	Faster, prioritized queue	Launch deadlines favor Priority
Escalation path	Standard	Dedicated escalation for launch-blocking issues	Use Priority when a launch is at risk
Scope of view	One account at a time	Can coordinate across accounts	Multi-account tickets need Priority
Limitation	Cannot resolve cross-account conflicts	Requires organization plan	Check plan eligibility before escalating

Topic	Detail
Account-to-domain link	Each SeaText account is linked to a single primary URL.
Multi-domain rule	Create a separate account for each domain (e.g., dev and production).
Localhost restriction	Development URLs like localhost are restricted for security reasons.
Dynamic dev domains	May not function properly because SeaText cannot reliably associate traffic with the account.
Activation step	Visit or refresh the site several times and stay on the page for at least 40 seconds.
Connection check	Wait at least five minutes until the website name appears next to the SeaText logo.
Tilda install path (site-wide)	Site Settings → paste code in "Edit code inside HEAD tag" → save and publish.
Tilda install path (single page)	Add T123 block → Other → T123 → Content → paste code → Save and Close → Publish.

Criterion	Standard support	Priority (organization) support
Best fit	Single Tilda project, one domain	Multiple Tilda domains, agency or in-house team
Multi-domain expertise	Limited	Yes, designed for cross-account issues
Response speed	Standard queue	Faster, prioritized queue
Escalation path	Standard	Dedicated escalation for launch-blocking issues
Scope of view	One account at a time	Can coordinate across accounts
Limitation	Cannot resolve cross-account conflicts	Requires organization plan

Learn more about this service