The SeaText content sitemap is a structural overview of all your URLs, whereas version history tracks changes to individual content pieces over time.

Choose the Content Sitemap if you want a clear map for SEO, site audits, or linking strategy.

Choose Version History if you need granular control over edits, the ability to revert, or an audit trail for compliance.

What is a SeaText Content Sitemap?

The sitemap is automatically generated by SeaText and lists every URL that belongs to your active project. It helps search engines discover and index your pages efficiently.

How the Sitemap Is Generated

SeaText scans your project structure each time a page is published, updated, or deleted. The system collects the canonical URL, the last modification timestamp, and optional metadata such as change frequency and priority. This data is assembled into an XML file that follows the sitemaps.org protocol. The file is served at a predictable path (typically /sitemap.xml) so crawlers can fetch it without guesswork.

According to SeaText's integration documentation, the sitemap feature is listed alongside content versions as a core capability of the platform (source S1). The generation process runs in the background and does not require manual triggers. New pages appear in the sitemap shortly after they go live. Removed pages are excluded on the next regeneration cycle.

What the Sitemap Contains

• URL set: Every indexable page in the project.
• Lastmod: Date the page was last published.
• Changefreq (optional): Hint to crawlers about update cadence.
• Priority (optional): Relative importance within the site.

These fields are standard across the industry. SeaText populates them automatically based on publish events. You can submit the resulting XML to Google Search Console, Bing Webmaster Tools, or any other crawler that accepts sitemaps.

What is SeaText Version History?

Every time you edit a page, SeaText saves a new version. The version history lets you view past edits, compare changes, and restore an earlier version if needed.

How Version History Captures Edits

When a user clicks "Save" or "Publish" in the SeaText editor, the platform creates an immutable snapshot of that content item. The snapshot stores the full HTML or structured content, the author's identifier, a timestamp, and a diff against the previous version. This approach is similar to git commits but scoped to a single content block or page.

SeaText's general integration page references "Seatext content versions" as a distinct feature (source S1), indicating that versioning is built into the content management layer. The history is retained indefinitely unless a user with appropriate permissions manually deletes specific versions.

What Version History Provides

• Chronological list: All saved versions, newest first.
• Diff view: Side‑by‑side comparison of any two versions.
• Restore action: One‑click revert to a selected snapshot.
• Audit trail: Who changed what and when.

This is an internal tool. Search engines never see version history. It exists to protect content integrity and support collaboration.

Key Facts

How They Work Together

You can use the sitemap to ensure all pages are indexed, then rely on version history to keep each page's content accurate and recoverable. Together they give you both discoverability and control.

Practical Workflow: Launching a New Section

1. Create and publish the new pages in SeaText.
2. Verify the sitemap updates automatically (check /sitemap.xml).
3. Submit the sitemap to Google Search Console for faster indexing.
4. As the team edits those pages over the following weeks, version history records every change.
5. If a mistake slips through, open version history, compare the bad version with the prior one, and restore.
6. Re‑submit the sitemap only if URLs changed; otherwise the existing sitemap remains valid.

Practical Workflow: Content Audit

1. Export the sitemap to get a complete URL inventory.
2. Cross‑reference with analytics to find low‑traffic pages.
3. For each candidate page, open version history to see when it was last substantively updated.
4. Decide: refresh content (creates new version), redirect (update sitemap), or remove (sitemap drops it automatically).

When to Use Each Feature

• Sitemap: Before launching a site, after major structural changes, or when submitting to search engines.
• Version History: After any content edit, during copy testing, or when compliance requires an edit trail.

Common Misconceptions and Migration Scenarios

Misconception: The Sitemap Stores Content Changes

False. The sitemap only lists URLs and metadata. It does not store the actual page content, nor does it keep previous versions. If you need to see what a page looked like last month, use version history.

Misconception: Version History Helps SEO Directly

False. Version history is invisible to crawlers. It does not affect indexing, rankings, or crawl budget. Its value is operational: preventing content loss and supporting governance.

Misconception: You Must Manually Regenerate the Sitemap

False for SeaText. The platform regenerates the sitemap automatically on publish events. Manual regeneration is only needed if you suspect a bug or caching issue.

Migration Scenario: Moving from Another CMS

When importing content into SeaText, the sitemap will reflect the new URL structure once pages are published. Version history starts fresh; imported content does not bring its old revision log. Plan for this by archiving the previous CMS's history externally if compliance requires it.

Migration Scenario: Restructuring URLs

If you change URL patterns (e.g., /blog/post-1 → /articles/post-1), publish the new URLs. The sitemap will update. Set up 301 redirects for the old URLs. Version history on each page remains intact because the content item ID stays the same.

Limitations

The sitemap does not store content changes, and version history does not affect search‑engine indexing directly. Use both tools in tandem for full coverage.

Sitemap Limitations

• Maximum 50,000 URLs per sitemap file (protocol limit). Large sites may need a sitemap index.
• No content diff capability.
• Cannot enforce crawl behavior; it's a hint, not a command.

Version History Limitations

• No cross‑page search; history is scoped to a single content item.
• Bulk restore not supported; each page must be reverted individually.
• Deleting a version is permanent; no recycle bin for history entries.
• Storage grows over time; very large projects may hit retention limits (check with vendor for current quotas).

FAQ

Do I need both the sitemap and version history?

Yes. The sitemap helps crawlers find pages, while version history protects your content edits.

Can I export the sitemap?

SeaText provides an export option in the Content section; the file can be submitted to search engines.

How far back does version history go?

SeaText retains every saved version indefinitely, unless you manually delete them.

Is version history visible to search engines?

No. It is an internal audit tool and does not affect indexing.

Will the sitemap update automatically?

Yes. New pages appear in the sitemap after they are published.

Can I compare two non‑consecutive versions?

Yes. The diff view lets you select any two versions in the history list.

Does the sitemap include draft or unpublished pages?

No. Only published, indexable pages are listed.

What happens to version history if I duplicate a page?

The duplicate starts with a clean history; the original's history stays with the original.

Start with pages that receive paid traffic from Google Ads or Meta, because the Google Ads Optimization Agent rewrites headlines, offers, and product blocks to match each keyword in real time. Next, activate on high-traffic product and pricing pages where the CRO Optimizer and Personalization Agent can test headlines, CTAs, and copy variants automatically. Add blog posts that rank for commercial-intent keywords so the AI SEO Content Factory can publish indexed Q&A expansions. Finally, enable translation on any page serving international visitors — the Translation Agent handles 125 languages without a manual localization project.

How SeaText Activation Works

You paste one JavaScript snippet across your entire site. The AI stays inert until you open the Main AI Hub and toggle agents on for specific URLs. Each agent — CRO Optimizer, Google Ads Agent, Translation, Bot Protection, Personalization, A/B Testing, and 14 others — runs only on the pages you select. This keeps costs predictable and avoids unwanted changes on legal, compliance, or low-value pages.

Decision Criteria: Score Each Page Type

Why Page Selection Matters

Activating agents everywhere wastes budget on pages that don't convert and risks compliance issues on legal content. The snippet loads on every page, but agents only execute where you enable them. This design lets you test on a handful of URLs, measure lift, then expand. If you skip selection and turn everything on, you'll pay for compute on thank-you pages, login screens, and admin routes that never see a prospect.

Step-by-Step Selection Process

1. Export your top 100 URLs by traffic from Analytics or Search Console.
2. Tag each URL with: paid traffic source (Google Ads, Meta, none), primary conversion event (purchase, lead, signup, none), content update cadence (static, quarterly, monthly, weekly), and international traffic share.
3. Apply the scoring table above. Pages scoring High on two or more columns go in the first activation batch.
4. Create a staging list of 10–20 URLs. Include at least one Google Ads landing page, one product page, one pricing page, and one high-traffic blog post.
5. Activate in Main AI Hub: choose agents per URL. For Ads landing pages, enable Google Ads Optimization Agent + CRO Optimizer. For product pages, add Translation + Personalization. For blog posts, add AI SEO Content Factory.
6. Wait 5 minutes after first visit to confirm the site name appears next to the SeaText logo — this verifies the snippet is live and linked to your account.
7. Monitor for 14 days. Check variant performance in the dashboard. Expand to the next batch of URLs once you see statistically significant lift.

Agent-to-Page Matching Guide

Common Mistakes

• Activating on thank-you / confirmation pages. No conversion to optimize; wastes agent cycles.
• Enabling Translation on pages with zero international traffic. Adds latency for no benefit.
• Turning on Google Ads Agent for organic-only URLs. The agent looks for keyword parameters that never arrive.
• Skipping the 40-second dwell after install. The account linking fails; agents won't activate.
• Using one account across multiple domains. Each domain needs its own SeaText account per the integration docs.

Limitations & When This Advice Doesn't Apply

• Development environments (localhost, dynamic preview URLs) are blocked for security — you need a real domain.
• If your CMS strips or defers JavaScript, the snippet may not execute; test with a hard refresh and 40-second stay.
• Pages behind authentication (dashboards, portals) rarely benefit from conversion agents; keep AI off.
• Regulated industries (finance, healthcare) may require legal review before any automated copy changes go live.
• The framework assumes you have at least 500 monthly sessions on target pages; below that, statistical significance takes months.

Key Facts

Terminology

• Main AI Hub — the dashboard where you enable/disable agents on specific URLs and adjust parameters.
• Variant — an AI-generated alternative version of a headline, paragraph, CTA, or full page section that SeaText tests against the original.
• Keyword-matched rewrite — real-time substitution of page copy to mirror the exact search term a visitor clicked on in a paid ad.
• Bot Protection Agent — detects invalid/non-human clicks in paid traffic and compiles evidence for ad-platform refund claims.
• Visitor Source Rewrite Agent — adapts page messaging based on whether the visitor came from Google, Meta, email, referral, or direct.

Practical Scenarios

Scenario A: E-commerce site running Google Shopping + Search campaigns

Activate Google Ads Optimization Agent + CRO Optimizer on all product landing pages. Add Translation Agent on top 50 SKUs with international traffic. Enable Bot Protection Agent on the same URLs to recover wasted spend. Skip blog, about, and policy pages.

Scenario B: B2B SaaS with high-value demo requests

Activate Enterprise Webchat Agent on pricing and demo pages for 24/7 qualification. Add Personalization Agent on homepage and feature pages to show industry-specific proof points. Enable Visitor Source Rewrite Agent on homepage to match messaging to LinkedIn Ads vs. organic. Keep AI off legal, security, and docs subdomains.

Scenario C: Content publisher monetizing via affiliate + display

Activate AI SEO Content Factory on top 200 commercial-intent articles to generate Q&A expansions. Add Translation Agent on high-traffic evergreen posts. Enable CRO Optimizer on "best X" comparison pages to test CTA placement. Skip news, author, and category archive pages.

FAQ

Do I need to install the snippet on every page before activating?

Yes. The snippet must load site-wide. Agents remain inert until you toggle them on per URL in the Main AI Hub. This architecture lets you activate instantly without code changes.

Can I activate different agents on different URLs?

Exactly. The Main AI Hub lets you choose which of the 20+ agents run on each URL. A product page might run CRO, Translation, and Personalization; a blog post might run only AI SEO Content Factory.

How long before I see results after activation?

Account linking takes ~5 minutes after your first 40-second visit. Agent execution starts immediately on enabled URLs. Statistical significance for CRO tests typically requires 2–4 weeks depending on traffic volume.

What if I have a staging environment?

Development domains (localhost, dynamic preview URLs) are restricted. Use a real domain (e.g., staging.yourdomain.com) with its own SeaText account for testing.

Does SeaText change my page HTML permanently?

No. Changes are served client-side via the JavaScript snippet. Your source CMS content stays untouched. You can review and edit every variant in the Variants Edit panel.

Can I pause an agent on one page without affecting others?

Yes. Toggle any agent off for any URL in the Main AI Hub. Other pages and agents continue running.

What happens if I exceed my plan's page or agent limits?

The dashboard will show a limit warning. You can upgrade or reduce active URLs/agents. No automatic overage charges — agents simply stop on the excess pages.

ccTLDs (example.fr) send the strongest geo-targeting signal but require most resources; subdomains (fr.example.com) are easier to set up but weaker for local trust; subdirectories (example.com/fr/) consolidate authority but need explicit hreflang and Search Console geo-targeting.

What is an international URL structure?

An international URL structure organizes web addresses so search engines and users can identify the target country or language. The three common patterns are country‑code top‑level domains (ccTLD), subdomains, and subdirectories.

Decision criteria

Evaluate five factors before choosing: geo‑targeting strength, setup effort, ongoing maintenance cost, authority pooling, and technical requirements such as hreflang and Search Console configuration.

How ccTLDs work

Each target country gets its own domain, for example example.de for Germany. The domain extension tells Google the content is intended for that country. Setup steps: register the ccTLD, set up DNS, provision hosting or a CDN, install SSL, create a separate Search Console property, add hreflang tags linking each language version. Common pitfalls: forgetting to renew each domain, missing hreflang on cross‑domain pages, duplicate content across ccTLDs. Cost estimate: $10‑$30 per domain per year plus hosting. Real‑world scenario: a global brand with local legal entities in France, Germany, and Japan uses example.fr, example.de, example.jp to meet compliance and gain maximum local trust.

How subdomains work

A subdomain places the language or country code before the root domain, like fr.example.com. The root domain retains most authority, but Google treats each subdomain as a separate host. Setup steps: create a DNS A or CNAME record for each subdomain, point to the same or different server, configure virtual hosts, add a Search Console property for each subdomain, implement hreflang across subdomains. Common pitfalls: treating subdomains as fully independent sites, neglecting hreflang, inconsistent internal linking. Cost estimate: minimal extra DNS cost; hosting shared. Real‑world scenario: a startup launches a French version quickly at fr.example.com while keeping the main site on example.com.

How subdirectories work

A subdirectory adds a path after the root domain, such as example.com/fr/. All content shares one domain authority. Setup steps: create language folders in the CMS, configure URL rewriting, add hreflang tags in the head of each page, set geo‑targeting in a single Search Console property for each language folder. Common pitfalls: missing hreflang, incorrect language codes, failing to set geo‑targeting in Search Console. Cost estimate: no extra domain cost; only development time. Real‑world scenario: an e‑commerce site serves 12 languages under example.com/en/, example.com/de/, example.com/ja/ to keep link equity consolidated.

Implementation checklist

• Define target markets and required languages.
• Choose URL structure based on criteria table.
• Register domains or create subdomains/subdirectories.
• Set up DNS and hosting for each property.
• Install SSL certificates for every hostname.
• Add each property to Google Search Console.
• Implement hreflang tags on every page (self‑referencing and alternates).
• Configure geo‑targeting in Search Console for ccTLDs and subdirectories.
• Test with the International Targeting report and hreflang validation tools.
• Monitor indexation and traffic per language for 30 days.

Migration from one structure to another

Moving from ccTLD to subdirectory: 301‑redirect each ccTLD page to the new subdirectory URL, update hreflang to point to new paths, submit change of address in Search Console for each ccTLD, keep old domains alive for at least 6 months. Moving from subdomain to subdirectory: 301‑redirect subdomain URLs to subdirectory paths, consolidate Search Console properties, update internal links and sitemaps. Moving from subdirectory to ccTLD: register new ccTLDs, 301‑redirect each subdirectory page, set up separate Search Console properties, add hreflang across new domains. Common pitfalls: missing redirects, losing hreflang consistency, not updating sitemaps. Cost estimate: developer time plus possible temporary traffic dip of 5‑15%.

When each option fits

Choose a ccTLD if you have the budget to manage multiple domains and want the strongest local signal. Choose a subdomain if you need a quick launch and can accept a weaker geo cue. Choose a subdirectory if you prefer to keep all authority in one domain and can implement hreflang correctly.

Limitations and when advice does not apply

This guidance assumes Google is the primary search engine and that you can edit DNS or server configuration. It does not cover cases where legal restrictions require a specific domain type, or where non‑Google search engines dominate.

Terminology

• ccTLD – country‑code top‑level domain, such as .fr or .jp.
• Subdomain – a prefix before the root domain, like fr.example.com.
• Subdirectory – a path after the root domain, like example.com/fr/.
• hreflang – HTML attribute that tells search engines the language and regional targeting of a page.

FAQ

How do I implement hreflang for subdirectories?

1. Add a <link rel="alternate" hreflang="x-default" href="https://example.com/" /> tag on every page.
2. For each language version, add <link rel="alternate" hreflang="fr" href="https://example.com/fr/page" /> and the reciprocal tags on the French page.
3. Include self‑referencing hreflang on each page.
4. Validate with Google Search Console International Targeting report.

What Search Console settings are required for each structure?

• ccTLD: add each domain as a separate property, set International Targeting → Country to the target country.
• Subdomain: add each subdomain as a separate property, set country targeting per property.
• Subdirectory: use a single domain property, then use the URL‑prefix property for each language folder (e.g., https://example.com/fr/) and set country targeting there.

How much does it cost to maintain each structure?

ccTLDs need separate domain renewals ($10‑$30/year each), separate SSL certificates, and possibly separate hosting. Subdomains share hosting and SSL but may need separate DNS records. Subdirectories need no extra domains or SSL beyond the root domain; cost is mainly development time for hreflang and content management.

When should I reconsider my choice?

Re‑evaluate if you enter a market with legal domain requirements, if analytics show users landing on the wrong language version, or if maintenance overhead exceeds budget.

SeaText integration

Implementing hreflang tags and managing multilingual content across any of these structures is simplified with SeaText's WordPress translation agent, which automatically translates pages into 125 languages and keeps new content synchronized.

Further reading and comparison sources

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

• ccTLD vs Subfolder vs Subdomain: International SEO Guide
• ccTLD vs. Subdirectory vs. Subdomain for international SEO
• Subdomain vs. Subdirectory vs. ccTLD: Which Is Best

Note: Core SEO claims in this article are based on industry‑standard knowledge and the external references above; the source pack does not contain specific technical guidance on URL structures.

Quick verdict: use a tunnel for real testing

SeaText explicitly restricts localhost and similar development URLs for security reasons. Each SeaText account is tied to a single primary domain, and the script cannot reliably associate traffic with your account on a local address. A tunneling service such as ngrok, Cloudflare Tunnel, or localhost.run gives you a public HTTPS endpoint that SeaText accepts, unlocking the full feature set — analytics, A/B reporting, personalization, and bot detection — while you develop on Tilda.

Takeaway: If you need to verify SeaText's AI agents, A/B tests, or analytics while building on Tilda, spin up a tunnel. If you only care about static layout checks, localhost is fine — but you won't see SeaText in action.

Why SeaText blocks localhost

SeaText ties each account to a single primary URL for security and billing integrity. The platform uses the domain to associate traffic, run A/B tests, attribute conversions, and generate bot-refund evidence. A local address cannot be verified as yours, so SeaText keeps the script inert on localhost, 127.0.0.1, or any non-public Tilda preview URL. This is not a bug — it's a deliberate restriction documented in the integration guide.

The restriction prevents account sharing across unrelated domains. It also ensures that conversion attribution, keyword matching, and bot detection work on real, verifiable traffic. Without a public domain, SeaText cannot distinguish your development traffic from another user's, so it disables all agents by default.

How a tunnel satisfies SeaText

When you run ngrok http 3000 (or your Tilda local port), ngrok provisions a public https://random-name.ngrok.io hostname that forwards to your machine. You add that hostname to the Allowed Domains field in your SeaText dashboard. SeaText now sees a valid, reachable domain, activates the script, and begins recording visits, running personalization, and populating your analytics. The same principle applies to Cloudflare Tunnel, localhost.run, or any tool that exposes a public HTTPS endpoint.

The tunnel acts as a bridge. Your local Tilda server stays on localhost:3000. The tunnel gives it a public face. SeaText's JavaScript snippet loads on the tunnel URL, reads the domain, matches it to your Allowed Domains list, and enables the full agent stack. No code changes required on your Tilda project.

Step-by-step: test SeaText on Tilda with ngrok

1. Install ngrok (brew install ngrok or download from ngrok.com).
2. Start your Tilda local preview (usually http://localhost:3000 or the port Tilda CLI uses).
3. Run ngrok http 3000 — note the https:// forwarding URL.
4. Log into SeaText, open your account settings, and add the ngrok hostname to Allowed Domains.
5. Paste the SeaText JavaScript snippet into Tilda's Site Settings → Edit code inside HEAD tag (or the T123 block for a single page).
6. Publish the Tilda page, then visit the ngrok URL. Stay on the page for at least 40 seconds to activate the AI.
7. Wait ~5 minutes; your site name should appear next to the SeaText logo in the dashboard, confirming the connection.

If you use the T123 block method, add the block to each page you want to test. The HEAD tag method applies site-wide. Both work with the tunnel URL.

Common tunnel options and trade-offs

• ngrok: Mature, free tier with rotating URLs, paid plans for custom/reserved domains and team features.
• Cloudflare Tunnel: Free, stable hostnames under your own domain, requires Cloudflare account and DNS setup.
• localhost.run / localtunnel: Zero-config, free, but URLs rotate each session — update Allowed Domains each time.
• Tailscale Funnel / VS Code Port Forwarding: Good if you already use those ecosystems; similar HTTPS exposure.

Pick based on whether you need a stable URL for team sharing (ngrok paid, Cloudflare) or quick solo tests (free ngrok, localhost.run). Cloudflare Tunnel is best if you own a domain and want a permanent subdomain like dev.yourdomain.com.

Key facts from SeaText documentation

What each SeaText agent does on a tunnel URL

Once the tunnel is active, every SeaText agent treats the tunnel hostname like a production domain. Here is what you can verify locally:

• Conversion Agent: Rewrites headlines, offers, and CTAs in real time. You see variant A vs B in the dashboard.
• Google Ads Agent: Matches landing page copy to the keyword that triggered the ad click. Test by appending ?utm_source=google&utm_term=your+keyword to the tunnel URL.
• Translation Agent: Serves content in up to 125 languages. Change your browser language or add ?lang=es to test.
• Bot Protection Agent: Detects suspicious paid traffic and builds refund-ready reports. Requires real ad clicks through the tunnel.
• Visitor Source Adaptation Agent: Adjusts page content for Meta, email, referral, and organic sources. Simulate with UTM parameters.
• AI A/B Testing Agent: Generates copy variants and scales winners. View results in the SeaText dashboard after sufficient traffic.
• ChatGPT Brand Visibility Agent: Shapes what AI assistants say about your brand. Hard to test locally but the agent activates.

All agents need real visits. The 40-second dwell time triggers activation. The 5-minute wait confirms domain linkage.

Practical scenarios: when to use which approach

Solo developer, quick layout check

Use localhost. You only need to verify CSS, HTML structure, or Tilda block placement. SeaText stays dormant. No tunnel needed.

Solo developer, feature validation

Use free ngrok or localhost.run. Spin up tunnel, add to Allowed Domains, test personalization, translation, A/B variants. Update Allowed Domains when URL rotates.

Team sharing for QA or client demo

Use ngrok paid plan (reserved domain) or Cloudflare Tunnel. Stable URL lets teammates and stakeholders test SeaText features without re-configuring Allowed Domains each session.

Multi-day A/B test before production

Use Cloudflare Tunnel with your own subdomain. Stable, free, and looks professional. Run real ad traffic through it to validate Bot Protection Agent and Google Ads Agent.

Enterprise environment with firewall

Check if outbound tunnel connections are allowed. ngrok and Cloudflare Tunnel use standard HTTPS (port 443). If blocked, ask IT to allowlist tunnel endpoints or use a staging domain instead.

Limitations & when this advice doesn't apply

• Free tunnel URLs rotate on restart — you must re-add the new hostname to Allowed Domains each session unless you pay for a reserved domain.
• SeaText requires a separate account for each distinct domain (including each tunnel hostname if you treat them as separate).
• Tilda's own preview URLs (e.g., *.tildacdn.com) may work if public and HTTPS, but they are not guaranteed stable for testing.
• Enterprise firewalls or corporate networks may block outbound tunnel connections — check with IT if ngrok fails to connect.
• Some ad platforms treat tunnel domains as low-trust. For accurate Bot Refund Agent testing, use a custom domain via Cloudflare Tunnel or a reserved ngrok domain that matches your brand.
• The tunnel adds ~20-50 ms round-trip latency. Negligible for copy/personalization tests but measurable in high-precision timing scenarios.
• SeaText's AI SEO Agent and AI SEO Content Factory publish indexed pages. These need a crawlable, stable URL — free rotating tunnels won't work for long-term SEO testing.

Decision checklist: tunnel vs localhost

FAQ

Can I use Tilda's built-in preview URL instead of a tunnel?

Only if the preview URL is a public HTTPS address that you can add to SeaText's Allowed Domains. Many Tilda preview links are temporary or restricted, so a tunnel is more reliable.

Do I need a paid ngrok plan?

Not for solo testing. The free tier works; just update Allowed Domains when the URL changes. Pay for a reserved domain if you share the link with teammates or run multi-day tests.

Will SeaText charge me for a tunnel hostname?

SeaText charges per account/domain. If you add the tunnel hostname to an existing account's Allowed Domains, no extra cost. If you create a new SeaText account for the tunnel, that's a second subscription.

Can I test the Bot Refund Agent locally via tunnel?

Yes. The Bot Protection Agent detects suspicious paid traffic and builds refund-ready reports. It needs real ad clicks coming through the tunnel URL to generate evidence.

What if my tunnel URL gets flagged as suspicious?

Some ad platforms treat tunnel domains as low-trust. For accurate Bot Refund Agent testing, use a custom domain via Cloudflare Tunnel or a reserved ngrok domain that matches your brand.

Does the tunnel add latency that skews A/B results?

Negligible for copy/personalization tests. The tunnel adds ~20-50 ms round-trip — far below the threshold that would affect SeaText's variant scoring.

Can I run multiple tunnel hostnames on one SeaText account?

Yes, add each hostname to Allowed Domains. But SeaText ties billing and reporting to the primary domain. For clean separation, use separate accounts per tunnel hostname.

Does SeaText work with Tilda's Zero Block or custom code blocks?

Yes. The SeaText snippet runs in the page head. It rewrites text nodes regardless of how the block was built. T123 block or HEAD tag injection both work.

How do I know SeaText is actually working on the tunnel?

Visit the tunnel URL, stay 40+ seconds. Wait 5 minutes. Check SeaText dashboard — your site name appears next to the logo. Then open the page, inspect network requests, look for SeaText API calls returning variant data.

Choose a tunnel if…

• You need to see SeaText's AI agents rewrite headlines, translate content, or run A/B tests while developing on Tilda.
• You want real analytics and conversion attribution before pushing to production.
• You're validating the Bot Refund Agent with live ad traffic.
• You need to share a functional demo with teammates, clients, or stakeholders.
• You're testing multi-language personalization or source-based adaptation.

Stick with localhost only if…

• You're only checking layout, CSS, or static HTML — no SeaText features required.
• You have a staging domain already configured in SeaText and prefer to test there.
• You cannot install tunnel software due to IT policy and have no alternative.

Conditional recommendation

For any meaningful SeaText evaluation on Tilda, spin up a tunnel. It takes 30 seconds, costs nothing on the free tier, and unlocks the entire platform. Treat localhost as a layout-only preview; treat the tunnel as your functional test

SeaText AI connects to your website through a JavaScript snippet tied to your account. When it fails to connect, the cause is usually one of a few common mistakes. Here are the most frequent issues and how to resolve them.

Why Getting the Connection Right Matters

Without a working connection, SeaText AI cannot activate any of its agents—CRO optimization, ad matching, translation, bot protection, and more. Every minute without a connection is lost opportunity for conversions and ad spend recovery. A correct setup ensures the AI can read your visitors, match keywords, and rewrite content in real time.

Mistake #1: Using an Incorrect or Expired API Key

Every SeaText account generates a unique JavaScript snippet. Copying the snippet from a different account or using an expired key will break the connection. Fix: Log in to your SeaText account, go to the General Integration page, and copy the exact code shown there. Never reuse a snippet from another account or domain.

Mistake #2: Placing the Script in the Wrong Location

The script must be added to every page of your website, typically in the <head> section. If you put it only on the homepage or in a footer that doesn't load on all pages, the AI won't activate site-wide. Fix: Use your CMS's custom code area (e.g., header injection in WordPress) or a plugin like the WP Engine plugin for WPEngine customers. The source pack notes: "If you are using WPEngine please download the WP Engine plugin that enables you to add custom JavaScript code to your pages."

Mistake #3: Forgetting to Activate the Integration

Installing the script is only half the step. You must also visit your website several times and stay on a page for at least 40 seconds to trigger activation. The source pack states: "Important: Visit or refresh your website several times and stay on your page for at least 40 seconds—this will activate the AI and link it to your account." Fix: After installing the script, open your site in a browser, refresh it a few times, and wait at least 40 seconds on one page. Then check your account dashboard for the website name.

Mistake #4: Using Unsupported Domains (localhost, Dynamic URLs)

SeaText restricts development URLs like localhost for security reasons. Dynamic development domains may not work because the AI cannot reliably associate traffic with your account. The source pack says: "Development URLs, such as localhost, are restricted for security reasons. Ensure you use a valid, real domain for these cases." Fix: Use a real domain for testing (e.g., staging.yoursite.com) or a subdomain that resolves publicly.

Mistake #5: Conflicting Plugins or CMS Issues

Some CMS plugins, especially caching or security plugins, can block or delay the SeaText script. If your site uses a caching plugin, the script might not load on every visit. Fix: Temporarily disable caching plugins to test, or whitelist the SeaText script in your caching settings. Also check for JavaScript errors in your browser console that might indicate a conflict.

Mistake #6: Not Waiting Long Enough After Installation

The source pack warns: "Important: Wait at least five minutes until you see your website name displayed next to the SEATEXT logo at the top of this page. This indicates that your website is connected and ready to proceed to the next step. If you do not see it at the top of the page after 10 minutes, please contact our support team immediately." Many users give up too early. Fix: After installing and activating, wait a full 5 minutes before checking. If the name doesn't appear after 10 minutes, contact support.

Mistake #7: Using One Account for Multiple Domains

Each SeaText account is linked to a single primary URL. If you try to use the same script on a development domain and a production domain, it will not work. The source pack 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." Fix: Create a separate account for each domain you want to connect.

Quick Diagnostic Checklist

• Did you copy the exact script from your SeaText account?
• Is the script placed in the <head> of every page?
• Did you visit your site and stay for at least 40 seconds?
• Have you waited 5 minutes before checking the dashboard?
• Is your domain a real, public URL (not localhost)?
• Are you using a separate account for each domain?
• Do you have any caching or security plugins that might block the script?

Key Facts at a Glance

Limitations and When This Advice Doesn't Apply

These troubleshooting steps cover the most common connection failures. However, if your website uses a custom-built CMS, a firewall that blocks external scripts, or a CDN with aggressive caching, the problem may be more specific. In such cases, the source pack recommends contacting SeaText support directly. Also, note that the connection process does not require any server-side changes—only the client-side script—so server configuration issues are unlikely.

Frequently Asked Questions

Why doesn't my website name appear after I install the script?

Most likely because you haven't visited your site and stayed on it for 40 seconds after installation. Also check that you are using the correct script for your account and that you waited at least 5 minutes.

Can I use SeaText on a staging site with a subdomain like staging.example.com?

Yes, as long as it is a real, public domain. You must create a separate account for the staging subdomain because each account is tied to one primary URL.

What if I accidentally delete the script from my site?

Reinstall it by copying the script again from your SeaText account and following the same activation steps. The connection will resume after you visit the site again.

Does SeaText work with all CMS platforms?

It works with any platform that allows you to add custom JavaScript to the page head. For WordPress, most users can use a plugin or a theme's custom code section. For WPEngine, a specific plugin is recommended.

How long does it take for the connection to be established?

After proper installation and activation, the website name appears in your dashboard within about 5 minutes. If it doesn't appear after 10 minutes, contact support.

Can I use the same script on my mobile app?

No, SeaText is designed for web pages. The script must be embedded in HTML pages that load in a browser.

What should I do if I've tried everything and still can't connect?

Contact SeaText support via the link in your account dashboard. Have your domain name and the script snippet ready. The source pack notes this is the next step if the dashboard doesn't show your site after 10 minutes.

You can use SeaText AI on a staging or development domain by connecting that domain to its own SeaText account. Install the JavaScript snippet, verify the connection, then activate the AI on the pages you want to test. The important rule: use a valid, real domain, not localhost, because each SeaText account is linked to a single primary URL.

If you already use SeaText AI on a live site, keep that account for production. Create a separate account for staging or development, and test there without changing your live site.

What this setup does

SeaText AI works on a staging or development domain the same way it works on a live site: the JavaScript code loads on your pages, the domain is linked to your account, and you activate the AI from the Main AI Hub. The difference is that a test domain needs its own account and its own real domain name.

The installation process is secure, and the AI remains inert until activated. That means you can install the code on a staging site without changing what visitors see until you turn the AI on.

Prerequisites before you start

• A SeaText AI account. If you do not have one, create it before installing the script.
• A valid, real domain for the staging or development site. localhost is restricted for security reasons.
• Access to edit the site's HTML or add custom JavaScript. On WPEngine, install the WP Engine plugin that enables you to add custom JavaScript across all pages.
• The JavaScript code provided by SeaText AI from the General Integration page.
• At least 10 minutes for setup and verification, plus time to stay on the page for 40 seconds during activation.

Step-by-step: Install SeaText AI on a staging or development domain

Follow these steps in order. Use a separate account for each domain, and use a real domain rather than localhost.

Step 1: Create a separate account for the staging domain

If you need SeaText AI on multiple domains, create separate accounts for each domain. Each SeaText AI account is linked to a single primary URL. In other words, your production domain gets one account and your staging or development domain gets another.

Step 2: Copy the JavaScript code

Log in to your SeaText AI account and copy the JavaScript code provided by SEATEXT AI. You can find it on the General Integration page.

Step 3: Add the code to your staging or development site

Add the script to every page where you want SeaText AI to work. If you are using WPEngine, download the WP Engine plugin that enables you to add custom JavaScript code to your pages. Install it and apply it across all your pages.

For other platforms, add the snippet through your usual integration method. The goal is the same: the code needs to load on the staging or development domain.

Step 4: Use a valid, real domain

Do not try to use localhost. Development URLs such as localhost are restricted for security reasons. Dynamic development domains may also fail, because SeaText AI might not reliably associate traffic with your account.

Use a stable domain you control, such as staging.example.com or dev.example.com. That gives SeaText AI a consistent URL to connect to your account.

Step 5: Activate the connection

Visit or refresh your website several times and stay on your page for at least 40 seconds. This activates the AI and links it to your account.

Then wait at least five minutes. Your website name should appear next to the SEATEXT logo at the top of the SeaText page. That is the signal that the domain is connected and ready for the next step.

Step 6: Verify before moving on

After five minutes, check that your website name appears next to the SEATEXT logo. If it does not appear at the top of the page after 10 minutes, contact support. This could indicate an issue during installation on your platform.

Verify the connection and activate the AI

Verification is not optional. The connection check tells you whether SeaText AI can reliably associate traffic with your account. Without it, the AI may not know which domain to work on.

Once the site name is visible, proceed to the Main AI Hub to activate the AI on the pages you want. Click Configuration to adjust the AI parameters. SeaText AI also provides an initial round of automatic translations and variants for testing. You can review or edit them in Variants Edit in the left panel: select the URL and language, then make manual changes.

What to test on the staging domain

• Activate one agent in the Main AI Hub and check how the page behaves.
• Use Configuration to adjust parameters for that agent.
• Review the automatic translations and variants in Variants Edit by selecting the staging URL and language.
• Make manual edits and confirm they apply to the staging account.

Staging vs. production setup

Use the table below to keep the two environments separate.

Keep the accounts separate. Since each account is linked to a single primary URL, reusing one account for both environments can prevent traffic from being associated with the right domain.

Key facts at a glance

Limitations and restrictions to plan around

• localhost is not allowed. Use a valid, real domain.
• Dynamic development domains may not function properly because SeaText AI might not reliably associate traffic with your account.
• One account is linked to one primary URL. To use SeaText AI on multiple websites, create one account for each website.
• The AI is inert until activated. Installation alone does not start rewriting content.
• If the site name does not appear after 10 minutes, contact support instead of continuing to wait.

These restrictions matter for staging work because a test domain that changes URL frequently will look unreliable to the system. Give your staging environment a stable domain name before installing the code.

Common mistakes and how to avoid them

Frequently asked questions

Can I use localhost as my development domain?

No. Development URLs such as localhost are restricted for security reasons. Use a valid, real domain instead.

Do I need a separate SeaText account for staging and production?

Yes. Each SeaText AI account is linked to a single primary URL, so multiple domains require separate accounts.

What happens if I use the same account on two domains?

The account is tied to one primary URL, so the second domain cannot be linked reliably. Create another account for the additional domain.

How long does activation take?

Visit or refresh the site several times and stay for at least 40 seconds. Check after five minutes. If the site name does not appear after 10 minutes, contact support.

Will installing the script change my staging site immediately?

No. The installation process is secure, and the AI remains inert until you activate it in the Main AI Hub.

Can I edit the content SeaText AI generates on the staging domain?

Yes. Log in to your account, go to Variants Edit, select the URL and language, and review or edit translations and variants.

Terminology used in this guide

• Primary URL: The single domain linked to a SeaText AI account.
• Staging or development domain: A separate site used to test changes before they reach production.
• Dynamic development domain: A URL that changes or is generated per session. It may prevent SeaText AI from associating traffic with your account.
• Main AI Hub: The SeaText area where you activate the AI on pages and adjust configuration.
• Variants Edit: The SeaText panel where you can review, create, or edit translations and variants by URL and language.

The best tools for manually editing AI translations are the ones that put the source text and the machine output next to each other, remember every approved phrase, and let you lock in the words your brand must use. A plain text editor can do the job for one-off fixes, but it breaks down the moment you have more than a handful of pages or more than one editor. A real post-editing tool gives you a side-by-side view, a translation memory that fills in repeated sentences, and a glossary that stops the AI from re-translating your product names. SeaText is built around this workflow: it generates the first round of translations automatically, then opens a Variants Edit panel where you can review and manually edit each variant per URL and language before the AI keeps optimizing the live page.

What "manually editing AI translations" actually means

Post-editing is the step where a human fixes machine-translated text. There are two common levels. Light post-editing means correcting only what is factually wrong or unreadable, so the text is understandable. Full post-editing means rewriting until the text reads like a human wrote it for your brand. The tool you pick should match the level you need, because a heavy CAT (computer-assisted translation) suite is overkill for light fixes, and a simple text box is not enough for full post-editing.

The decision criteria that matter

Before you compare products, write down what your editing workflow actually needs. The criteria below are the ones that change your daily experience, not the ones that look good on a feature list.

• Side-by-side comparison view. You need the source sentence and the AI output on the same screen, with the cursor moving in sync.
• Translation memory (TM). A TM stores every sentence you approve and suggests it the next time the same sentence appears, so you stop fixing the same phrase twice.
• Glossary and terminology control. A glossary locks product names, feature names, and forbidden terms so the AI cannot drift.
• Versioning and audit trail. You need to see who changed what, and roll back if an editor makes a mistake.
• Live page connection. If the AI is also serving the translated page to visitors, your edits should feed back into what visitors see, not sit in a separate file.
• Collaboration. Multiple editors, comments, and review states matter once you have more than one person touching the text.

Tradeoff table: how the main tool categories compare

Most "AI translation editors" fall into a few categories. Each one makes a different bet about who is editing and how much control they need.

How to choose the right category for your situation

Use the rules below to pick fast. They are written for a buyer, not a translator.

• Pick a standalone CAT tool if you are a translator billing by the word, you work in long documents, and you need maximum control over every segment.
• Pick a localization platform if your developers already ship strings through a repo or a TMS, and you need translators, reviewers, and engineers working in the same system.
• Pick an AI service with human review if you only need a polished file a few times a month and you do not mind waiting two business days per language.
• Pick an AI website agent with built-in editing if your translated text lives on a live marketing or ecommerce site, and you want your edits to keep improving what visitors actually see.
• Pick a plain text editor only for a one-page emergency fix. It will not survive a second page.

A practical post-editing workflow

Once you have a tool, the workflow below keeps quality high without burning editor hours.

1. Let the AI draft first. Start from the machine output. Do not translate from scratch unless the AI output is unusable.
2. Fix meaning, not style. Correct factual errors, wrong numbers, broken UI strings, and anything that misrepresents your product.
3. Apply your glossary. Replace any term the AI got wrong, and add it to the glossary so it stops happening.
4. Read aloud for the target market. A sentence can be correct and still sound foreign. Read it as a native reader would.
5. Save and let the AI learn. In tools that connect edits back to the live page, your approved text becomes the new baseline for the next visitor.
6. Spot-check after deployment. Open the live page in the target language and confirm the edits actually shipped.

Key facts about SeaText's editing surface

The table below is grounded only in what SeaText's own documentation states. Use it to check fit before you commit.

Limitations and when this advice does not fit

No single tool covers every case. Be honest about the edges before you buy.

• Regulated content. Legal, medical, and financial text usually needs a certified human translator and an audit trail that goes beyond a marketing editor.
• Long documents. If you are translating a 200-page manual, a CAT tool with a real TM will beat any website agent.
• App strings inside a repo. Developers shipping JSON or XML strings need a localization platform with a CI integration, not a page-level editor.
• One-off personal projects. A spreadsheet is fine if you will never touch the file again.

Frequently asked questions

Do I still need a human editor if the AI is good?

Yes, for anything customer-facing. AI translation is fast and usually understandable, but it still mistranslates product names, breaks UI strings, and misses brand tone. A human editor catches the errors that cost you trust.

What is the difference between a translation memory and a glossary?

A translation memory stores full sentences you have already approved and suggests them again. A glossary stores individual terms, like product names, and forces the AI to use a specific translation every time. You need both for consistent output.

How long should post-editing take?

Light post-editing usually runs at about half the speed of translating from scratch. Full post-editing is closer to the speed of normal translation. If your editor is slower than that, the AI output probably needs more than a polish.

Can I edit translations without breaking the AI optimization?

In tools that connect edits back to the live page, your edits become the new baseline and the AI keeps testing against them. In tools that export files, your edits sit in a separate file and the AI never sees them. Pick the first kind if your site is live.

What is the cheapest way to start?

Start with the AI output and a single editor using a side-by-side view. Add a glossary on day one. Add a translation memory once you have more than a few hundred repeated sentences. Skip the enterprise CAT license until you can prove you need it.

Should I edit in the target language or in English?

Always edit in the target language. Editing in English and re-translating lets the AI undo your work on the next pass.

How do I know if my edits are actually live?

Open the live page in a private window, switch to the target language, and read the sentence you changed. If it does not match, your edit did not reach the live variant and you need to check the tool's deployment step.

Raw AI translations often read well but miss the context that controls meaning. A model can translate every word correctly and still produce a phrase that is wrong for your audience, your product, or your market. Manual editing fixes those context errors: cultural idioms, technical terms, tone, and brand voice.

The reason is not that AI translation is weak. It is that AI translation is a prediction, not an understanding. The model chooses the most likely next word from billions of examples. A human editor supplies what the model cannot see: what your sentence means, who will read it, and what response you want from that reader.

What goes wrong when AI translates without context

A machine translation engine is trained to find statistical patterns. It sees a word like "conversion" and must choose an equivalent, but it does not know if you are talking about a sale, a religious change, or a unit of measurement. The result can be grammatically correct and semantically wrong.

• Idioms and culture. "Out of the box" can become "outside the box," which changes the meaning. A translator who knows the product will fix that.
• Technical terms. "Bounce rate," "trial period," and "refund policy" have standard translations in some languages and dangerous false friends in others.
• Tone and politeness. Some languages require a different level of formality for a customer than for a boss. The model has no idea which one you want.
• Brand names and slogans. A slogan that works in English may sound odd or offensive when translated literally. You need a human decision, not a prediction.
• Search terms. A page that ranks in English may not rank in another language until someone checks the words real buyers use.

What happens if you publish a raw AI translation

The first consequence is confusion. A sentence may be understandable but strange, so the reader stops trusting it. If the reader cannot tell what you sell, how much it costs, or what happens next, they leave.

The second consequence is cost. You pay support agents to answer questions a clean translation would not have caused. You lose orders. You may even create a compliance problem if contracts, safety instructions, or financial disclaimers are wrong.

The third consequence is silence. Nobody complains about a bad translation. They just choose a competitor. A raw translation can look fine to the person who published it and still fail with the person who reads it.

Where AI translation is strong and where it is weak

AI translation is excellent at some jobs and poor at others. Knowing which is which helps you spend editing time where it matters.

Strong enough with light review

• Simple product descriptions
• Short technical documentation with approved terms
• Internal messages and draft content
• Repetitive text like menu labels and buttons

Needs real editing

• Marketing pages and landing pages
• Legal, medical, and financial copy
• Anything with humor, puns, or cultural references
• High-traffic pages that explain your main offer

One more factor matters: the source text. AI translation quality usually starts with what you feed it. If the English sentence is unclear, the translation will be unclear too. Clean up the source before you translate, and you will have less to edit afterward.

Most professional workflows treat machine translation as the first draft. The human editor checks meaning, style, and fit before anything goes live.

What a human editor adds that the model cannot

Think of AI translation as a fast, confident intern. The intern can draft a whole page, but still needs a senior colleague to check the logic before it is sent.

That senior colleague asks three questions:

1. Does this translation mean what the source means?
2. Would a customer say it this way?
3. Does it sound like our brand?

The model answers none of them. It answers a different question: which phrase is statistically likely next. That is why human editing matters even when the output looks clean.

A practical editing workflow for AI translations

You do not need to edit every sentence the same way. You need a diagnostic order that finds real errors fast.

1. Start with your most important pages. Homepage, pricing, checkout, and product pages do more work than a blog post. Edit those first.
2. Give the model context before you translate. The source text should be clear, and any abbreviation or product name should be written out once.
3. Compare against the source. If you read both languages, check numbers, names, dates, promises, and warnings line by line.
4. Check terms and phrases. Search the translation for your product names, slogans, and technical terms. Make sure they appear everywhere they should.
5. Read the translation aloud. Odd phrasing becomes obvious when you say it. If you cannot judge the language, ask a native speaker to read it.
6. Store the approved terms. Save your corrected words and phrases so the next AI translation starts from a better position.

You can skip the slow steps for low-risk content. The biggest risk is treating a landing page like a low-risk page.

When can you skip manual editing?

There are real exceptions. Raw AI translation is fine for:

• Internal notes that only your team will see
• Temporary content, such as a banner that changes weekly
• Draft versions that a writer will rewrite anyway
• Content you can quickly delete if it is wrong

There are also cases where you should never skip it. Press releases, legal terms, pricing, health and safety text, and any page that collects money or personal data deserve at least one human pass.

When in doubt, imagine the customer reading the translation in a hurry. If one wrong word would stop them from buying or trusting you, edit it.

Definition and scope

Raw AI translation is machine output that has not been reviewed by a person. It can be accurate, but no one has verified it.

Post-editing is the human revision of that output. Light post-editing makes the text understandable. Full post-editing makes it natural, accurate, and on-brand.

This article is about that review step. It is not about whether a company should translate at all. If you are translating for public customers, the question is not "AI or human?" but "AI first, then who reviews?"

Key facts about a translation workflow with built-in editing

If the translation tool you choose includes manual review, you still need to use it. The table below describes the workflow in one such platform and shows where the human step sits.

Notice the order: automatic output first, then human review. The editing step should not be an afterthought.

Useful terms to know

Raw machine translation

Output created by software with no human review. Fast, cheap, and often wrong in context.

Post-editing

The process of changing machine output to meet a required level of quality. This is the manual editing described in this article.

Light post-editing

Fixing the worst errors so the meaning is clear. The result is usable but not polished.

Full post-editing

Making the text natural, consistent, and appropriate for the audience. This is what marketing copy usually needs.

Translation variant

One version of a translated page. Some platforms, including SEATEXT, use the word variants in their editing area.

Translation memory

A database of approved sentences and terms. It helps keep past translations consistent, but it does not replace a final human review.

Frequently asked questions

Is raw AI translation ever okay?

Yes, for low-risk or temporary content. For public pages, it is safer to treat raw output as a draft and review it before launch.

How much does manual editing cost?

There is no single rate. It depends on the language pair, the difficulty of the text, and the quality you need. A light review costs less than a full rewrite, but a page that harms trust costs more.

How long does it take to edit an AI translation?

For a short, simple page, a focused review can take a few minutes. For a marketing page, plan for longer. The point is to spend time where readers will notice.

What should I check first?

Check numbers, names, dates, product terms, and promises. Then check the overall tone. Those errors cause the most harm and are the easiest to miss.

Do I need a professional translator?

For high-stakes content, yes. For content that is mostly factual, a careful bilingual reviewer may be enough. If no one reads both languages well, find someone who does before publishing.

Does editing remove the speed benefit of AI translation?

No. AI gives you a complete draft in seconds. You use review time only on the pages that matter. That is usually much faster than translating everything from scratch.

Most SeaText-on-Tilda failures come from six mistakes: head placement, publishing, stale snippets, preview-only testing, activation, and development domains. Fix those six and the integration usually works. This guide covers each mistake, explains why it happens, and gives a step-by-step repair.

How the SeaText/Tilda integration works

SeaText runs on JavaScript. You copy a snippet from your SeaText account and place it in Tilda. Tilda then sends that snippet to visitors in the HTML head. That lets SeaText connect the page to your account and run the AI agents you activate.

For a site-wide install, open Site Settings in Tilda. Go to More → HTML code for the head section → Edit code. Paste the code into the field labeled "Edit code inside HEAD tag". The integration guide says you need to save and publish after pasting.

For one page:

1. Open the page in Tilda.
2. Click the + icon to add a block.
3. Choose T123 under Other.
4. Open the block's Content tab.
5. Paste the snippet into the HTML editor.
6. Click Save and Close.
7. Click Publish.

Installation alone does not start the AI. SeaText is inert until activated. After publishing, visit the site and refresh it several times. Stay on the page for at least 40 seconds. Then wait at least five minutes. When your website name appears next to the SeaText logo, the site is connected.

The account-to-domain pairing is central. Each SeaText account is linked to one primary URL. A separate account is required for each domain. Development and production need separate accounts.

Mistake #1 – Pasting the code into the body instead of the head

Symptom: No SeaText logo or effect appears. The page loads, but the AI never runs.

Root cause: The snippet was dropped into a page block or body area. Tilda has a dedicated head-code field. SeaText specifically tells you to paste the code into "Edit code inside HEAD tag".

Repair: Go to Site Settings. Choose More → HTML code for the head section → Edit code. Paste the correct snippet there. Remove any old copy from body blocks. Save and publish.

Verify: Open the live URL and view source. SeaText must appear inside the <head> element, not the body.

Mistake #2 – Forgetting to publish

Symptom: The code is saved, but the live site still shows the old version. Visitors and SeaText never receive the script.

Root cause: Tilda keeps unpublished changes in draft mode. Saving is not publishing. SeaText's integration guide says to "save and publish your site" after pasting the code.

Repair: After you paste the code, click Save and Close where needed. Then click Publish in Tilda. Wait until publishing finishes.

Verify: Open the live URL in an incognito window. Check that the SeaText script is present. Then visit the page again while logged into SeaText and wait for the connection to appear.

Mistake #3 – Using an old or wrong snippet

Symptom: SeaText does not connect to this site. The dashboard may show no matching website. Sometimes the snippet URL returns a 404.

Root cause: Every SeaText account and domain has its own snippet. Reusing a snippet from an old project or another domain breaks the account-to-domain pairing.

Repair: Log into the correct SeaText account. Copy the JavaScript code that SeaText provides for this account. Replace the old code in Tilda with the fresh snippet. Save and publish.

Verify: Compare the snippet on your Tilda page with the one shown in your SeaText dashboard. If the snippet URL differs, replace it. A 404 is a clear signal to check the dashboard for the correct snippet.

Mistake #4 – Testing only in Tilda preview mode

Symptom: The integration looks broken in the Tilda editor. The published site may be fine, but you cannot see SeaText's effects in preview.

Root cause: Tilda preview mode runs inside the editor environment. External scripts are often isolated or blocked there. The preview is not the real production page.

Repair: Finish the install steps. Publish the site. Open the published URL in a normal browser tab, not inside Tilda.

Verify: Test the live domain. Refresh it several times and stay on the page for at least 40 seconds. Then check SeaText for the website name.

Mistake #5 – Not activating the AI after install

Symptom: The script loads, but SeaText does nothing. No rewriting, no logo, no activity in the dashboard.

Root cause: SeaText is intentionally inert until you activate it. The integration guide says the AI remains inert until activated. Publishing the code alone is not enough.

Repair: Log into your SeaText account. Activate the AI or the agents you need for the site. Then visit the live page several times and stay for at least 40 seconds.

Verify: Wait at least five minutes. Your website name should appear next to the SeaText logo. When it does, the AI is linked to your account and ready.

Mistake #6 – Using a development or localhost domain

Symptom: SeaText cannot connect. Traffic from the URL is not attributed to your account. The dashboard stays empty.

Root cause: SeaText restricts development URLs for security. The integration page says "Development URLs, such as localhost, are restricted." Dynamic development domains may not work because SeaText cannot reliably associate traffic with your account.

Repair: Use a valid, real domain. If you still need a development environment, create a separate SeaText account for the development domain and another for the production domain.

Verify: Confirm that the domain on the live page exactly matches the primary URL in your SeaText account. If they differ, set up the correct account for that domain.

Limitations: development domains and account pairing

SeaText is designed around one account per primary URL. This keeps traffic, settings, and agent activity attached to the right website. It also prevents one snippet from firing on unrelated domains.

Localhost and similar development URLs are blocked for security. A dynamic development domain can also break the connection. When the domain changes, SeaText may not know which account should receive the traffic.

If you manage multiple websites, create one account for each website. If you use both a staging domain and a live domain, create separate accounts for each. Then install the matching snippet on each site.

This limitation is not a bug. It is how SeaText tracks which site the AI should optimize. Without the pairing, the dashboard would not know where the traffic came from.

FAQ

• The logo doesn't appear after five minutes. What should I do? First check that the site is published and the code is in the head. Use the live URL, not preview mode. Refresh the page several times and stay on it for at least 40 seconds. Then wait five more minutes. If nothing changes, compare the snippet in your dashboard with the one on the page. Contact SeaText support with the page URL if it still fails.
• How do I install SeaText on one Tilda page using the T123 block? Open the page in Tilda. Click the + icon to add a block. Choose T123 under Other. In the block's Content tab, paste the SeaText snippet into the HTML editor. Click Save and Close. Then click Publish.
• Why does the snippet URL give a 404 error? A 404 usually means the snippet URL does not match the one in your SeaText dashboard. You may have copied an old snippet or code from a different account. Log in to SeaText, copy the current snippet, replace the old one, and republish.
• Can I use the same snippet on multiple Tilda sites? No. Each website needs its own SeaText account and its own snippet. The account is linked to a single primary URL.
• Do I need to reinstall SeaText after changing the domain? Yes. Create a new SeaText account for the new domain. Copy the new snippet and install it in Tilda. The old snippet will not carry the connection over.
• Why must the code go in the head? The head loads before the page body is ready. This lets SeaText connect early. A body placement may load too late for SeaText to hook into the page lifecycle.
• I did everything, but it still does not work. What now? Check browser extensions such as ad-blockers. Look at the browser console for script errors. Make sure you are testing the published domain. Then use the error details when you contact SeaText support.

Further reading and integration sources

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

• SeaText Tilda Integration

You can verify the SeaText script's integrity by inspecting the source code in your browser's developer tools or by using standard web security scanners to monitor outgoing network requests. The script is a standard JavaScript file that loads from SeaText's servers, so the same checks you would use for any third-party tag apply here: read the code, hash it, and watch what it does at runtime.

This guide walks through the practical steps: what to look for in the script, how to use Subresource Integrity (SRI) and Content Security Policy (CSP) to lock down loading, how to audit network behavior, and how to confirm the script is the one SeaText actually published.

What "script integrity" means in this context

Script integrity is the assurance that the JavaScript running on your page is exactly the code the vendor published, that it has not been tampered with in transit or at rest, and that it only does what its documentation says. For a third-party script like SeaText, three things matter:

• Authenticity: the file came from SeaText's servers and was not swapped by an attacker.
• Unchanged content: the bytes match the expected file, byte for byte.
• Expected behavior: at runtime, the script only contacts endpoints you have approved and only modifies the parts of the page SeaText documents.

SeaText describes its installation as secure and notes that the AI remains inert until activated, which keeps the script from changing your content before you turn features on. That is a useful baseline, but it does not replace your own checks.

Prerequisites before you start auditing

Before you inspect anything, gather a few basics so your checks are repeatable:

1. A modern browser with developer tools (Chrome, Firefox, Edge, or Safari).
2. Access to the page where the SeaText script is installed, loaded over HTTPS.
3. The exact SeaText script URL and account details, so you can compare what you see against what SeaText published.
4. Optional but recommended: a staging or development copy of your site, so you can test changes without affecting live visitors.

If you are on a managed host such as WPEngine, SeaText's general integration guide notes that you may need a plugin to add custom JavaScript across all pages. Knowing how the script was injected (directly in HTML, via a tag manager, or through a host plugin) matters because each method changes where you look for the code.

Step-by-step: verify the SeaText script on your site

Step 1. Locate the script in your page source

Open the page in your browser, right-click, and choose "View Page Source." Search for "seatext" or for the script tag you added during installation. You should see a <script> tag that loads a JavaScript file from a SeaText domain. Note the full URL, the async or defer attributes, and whether the tag includes an integrity attribute.

Step 2. Open the Network panel and reload

In developer tools, switch to the Network tab and reload the page. Filter by "JS" to see only JavaScript requests. Find the SeaText request and check:

• The exact URL it loaded from.
• The HTTP status (should be 200).
• The response size, which gives you a rough fingerprint.
• The initiator, which tells you whether your HTML, a tag manager, or a plugin loaded it.

Step 3. Read the script content

Click the SeaText request in the Network panel and open the Response tab. Skim the code. You are looking for obvious red flags: obfuscated payloads that fetch further code from random domains, hard-coded credentials, or calls to endpoints unrelated to conversion optimization and translation. A legitimate analytics or optimization script will read DOM elements, send events, and apply variants; it will not try to exfiltrate form data or redirect users.

Step 4. Compute a hash and compare

Subresource Integrity (SRI) lets the browser refuse to run a script whose hash does not match a value you declare. To use it, generate a SHA-384 hash of the script file and add an integrity attribute to the tag:

<script src="https://cdn.seatext.com/your-script.js" integrity="sha384-HASHVALUE" crossorigin="anonymous"></script>

You can generate the hash with OpenSSL: openssl dgst -sha384 -binary script.js | openssl base64 -A. If SeaText updates the script, you will need to refresh the hash, so treat SRI as a deliberate choice rather than a set-and-forget control.

Step 5. Watch runtime behavior with the Console and Network panels

With the Console open, interact with the page: scroll, click a call to action, switch languages if translation is active. Watch for:

• Network requests only to SeaText-owned domains.
• No unexpected document.write calls or redirects.
• No errors in the Console that suggest the script is failing closed or throwing exceptions.

Step 6. Confirm the script is connected to your account

SeaText's integration guide says that after installation you should refresh your website several times and stay on a page for at least 40 seconds, then wait up to five minutes for your website name to appear next to the SeaText logo in your dashboard. If the name shows up, the script is talking to your account as expected. If it does not appear after 10 minutes, SeaText recommends contacting support, because that can indicate an installation issue.

Add a Content Security Policy as a second layer

A Content Security Policy (CSP) is an HTTP header that tells the browser which sources of script are allowed. Even if an attacker managed to swap the SeaText script, a strict CSP can block the bad code from running. A minimal policy that allows SeaText might look like:

Content-Security-Policy: script-src 'self' https://cdn.seatext.com; connect-src 'self' https://*.seatext.com;

Start in report-only mode so you can see what would be blocked without breaking your site, then move to enforcement once you are confident nothing legitimate is being denied.

Use a web security scanner for an outside view

Browser-based checks tell you what your visitors experience. A web security scanner gives you an external perspective. Tools like Mozilla Observatory, SecurityHeaders.com, and commercial Dynamic Application Security Testing (DAST) platforms will:

• Confirm your page is served over HTTPS.
• Check for mixed content that could let an attacker rewrite script tags.
• Flag missing security headers, including CSP and HTTP Strict Transport Security (HSTS).
• Detect any injected scripts that do not belong on the page.

Run a scan before you install SeaText, then again after, and compare the diff. Any new third-party domain that appears in the post-install scan deserves a closer look.

Common mistakes to avoid

• Trusting the tag manager blindly. If SeaText is loaded through Google Tag Manager or a similar tool, audit the container too. A compromised container can swap any tag.
• Skipping SRI because the script "looks fine." Visual inspection is not integrity verification. A hash is.
• Allowing unsafe-inline or unsafe-eval in your CSP. These directives disable most of the protection CSP offers.
• Forgetting subdomains and staging environments. A script loaded on staging.example.com but not on example.com still ships code to real visitors.
• Ignoring updates. If SeaText changes its script, your SRI hash will break the page. Subscribe to SeaText's release notes so you can refresh hashes on purpose, not in a panic.

Limitations of these checks

None of these methods prove that the script is benign in a legal or ethical sense; they only prove that it matches what was published and behaves as observed. A vendor could ship a script that is technically intact but still collects more data than you expected. Read SeaText's privacy and data handling documentation, and confirm that the data flows you see in the Network panel match what the vendor describes.

SRI also does not protect against a compromised vendor. If SeaText's own servers were breached and the script was modified, the hash you pinned would no longer match and the script would simply stop loading. That is safer than running tampered code, but it does mean you need a process for updating hashes when legitimate releases ship.

Key facts about the SeaText installation

Frequently asked questions

Does SeaText publish an SRI hash I can use?

Check the SeaText dashboard and developer documentation for a published hash. If none is provided, you can generate one yourself from the file you receive, but you will need to refresh it whenever SeaText updates the script.

How do I know the script is not reading sensitive form fields?

Open the script source in your browser's developer tools and search for selectors that target form inputs, password fields, or credit card fields. A conversion optimization script should focus on headlines, offers, and calls to action, not on capturing input values.

What should I do if the script fails the SRI check?

The browser will refuse to run it. That is the desired behavior. Contact SeaText support to confirm whether the file changed, then update your integrity attribute with the new hash once you have verified the new file is legitimate.

Can I run SeaText on a staging domain?

SeaText restricts localhost and dynamic development domains for security reasons. Use a real, stable staging domain and create a separate SeaText account for it, since each account is tied to a single primary URL.

How often should I re-audit the script?

Re-audit after any SeaText release, after any change to your tag manager or hosting setup, and on a regular cadence (for example, quarterly) even when nothing has changed. Scheduled scans catch drift you might otherwise miss.

Will a Content Security Policy break SeaText?

It can, if you do not allow the domains SeaText needs. Start in report-only mode, review the violations, and add the required hosts to your script-src and connect-src directives before enforcing the policy.

Is inspecting the script enough to call it secure?

No. Inspection confirms what the code looks like at one moment in time. Pair it with SRI for transport integrity, CSP for runtime control, and ongoing monitoring for behavior you did not expect.

How SeaText can help

SeaText's general integration guide describes a secure installation flow: the script is inert until you activate AI features, each account is tied to a single primary URL, and the dashboard shows your website name once the script is connected. That gives you a built-in signal that the script is talking to your account as expected. The limitation is that SeaText does not, in the materials provided, publish a standing SRI hash for its script, so you will need to generate and maintain your own if you want browser-enforced integrity checks. You will also need to keep your CSP and tag manager configuration in sync with any new endpoints SeaText introduces.

Two free WordPress translation plugins can detect a visitor's preferred language automatically: Polylang and TranslatePress. SEATEXT also detects visitor language and translates pages into 125 languages without manual work. This guide compares detection, setup, limits, and the best fit for different site types.

How automatic language detection works in WordPress

Browser language detection starts with the Accept-Language header. Every major browser sends this header with each page request. It lists language codes in order of preference. A typical value looks like en-US,en;q=0.9,fr;q=0.8.

The plugin reads that list and looks for the first language your site supports. If it finds a match, it serves that language version. If no match exists, it falls back to your site's default language.

This process happens before the page renders. Some plugins redirect the visitor to a language-specific URL. Others keep the same URL and switch the content. Both approaches can work, but search engines see them differently.

Detection is not the same as memory. After the first visit, the plugin may store the visitor's choice in a cookie, a session, or the URL itself. On the next visit, that saved choice usually overrides the header. This matters for returning visitors.

If a visitor clears cookies or arrives in a new browser, detection runs again. You should test both paths: a new visitor and a returning visitor.

IP detection works differently. It guesses language from geographic location. That can help when the browser header is missing or set to a generic value. But IP detection is often inaccurate for visitors using VPNs, traveling users, or shared office networks. It also cannot tell which language a bilingual user prefers. Treat IP detection as a fallback, not the primary signal.

Server-side detection is more reliable than client-side detection. Server-side checks happen before WordPress sends content. Client-side scripts can cause flicker or delay. Many plugins mix both: server reads the header, then a cookie keeps the choice.

Why automatic detection matters

Automatic detection removes one barrier between a visitor and your content. A visitor should not have to hunt for a language switcher. If they land on a page in the wrong language, many will leave quickly.

For international markets, the first language you serve shapes trust. A French visitor who sees French content is more likely to stay and explore. SEATEXT reports that its translation agent can help sites gain up to 60% more international customers. That result depends on the site, market, and offer, but it shows the upside.

Beyond trust, detection helps with SEO. When a plugin serves language-specific URLs and adds hreflang tags, search engines can index each version properly. Without that, translated content may be ignored or treated as duplicate content.

Buyer scenarios: which plugin fits which site

Large ecommerce catalog. A big store may have thousands of products and frequent stock updates. Manual translation does not scale. In this scenario, SEATEXT is the strongest fit because it translates new pages, products, and updates automatically. It also tracks results by language and market. Polylang and TranslatePress free would require manual translation for every new product. GTranslate's free widget can translate text on the fly but does not create indexable pages, so it is a poor fit for a store that relies on organic traffic.

Small marketing site. A few pages and a small team can handle manual translation. Polylang gives full control over every string. TranslatePress lets you translate while looking at the page. Choose Polylang if you prefer familiar dashboard editing. Choose TranslatePress if you want a live preview. Both are reasonable for a small site. SEATEXT works too, but automatic translations may require review if your brand has strict language rules.

SEO-critical blog. A blog earns traffic from search engines. It needs crawlable language URLs and hreflang support. SEATEXT provides automatic multilingual SEO for every translated page. Polylang and TranslatePress can create language URLs; check with the vendor for the exact hreflang behavior. GTranslate's free widget is not a good fit because the free version does not create SEO-friendly URLs.

Low-traffic internal page. An internal tool, a login note, or a temporary campaign page may not need SEO at all. GTranslate's free widget is the fastest way to offer a language choice. It adds a small widget and translates visible text in the browser. No server setup. If you need detection too, use one of the automatic plugins. For non-indexed pages, GTranslate is enough.

Polylang: setup and verification

Install and activate Polylang from the WordPress repository. Add languages under Languages > Languages. Set a default language and choose URL modifications. Then enable browser detection in Settings > Languages. The exact checkbox label can change; check with the vendor.

After enabling, review these settings:

• The list of enabled languages and their order.
• Your default language fallback.
• URL structure: subdirectory, subdomain, or pretty links.
• Whether the language switcher shows a list, dropdown, or flags.
• Options for excluding specific pages from detection, if available.

Verification steps:

1. Open the site in a private browser window.
2. Set the browser language to a language your site supports.
3. Check that you land on the correct language version.
4. Inspect the page source for hreflang tags.
5. Switch languages manually and confirm the new choice is saved.

Common troubleshooting:

• Browser detection may not run if a cache plugin serves a cached version. Clear the cache first.
• Redirect loops often come from bad URL settings. Recheck the language URL mode.
• If a visitor lands on the default language, their browser language may not be in your enabled list.
• Privacy plugins may block cookies. Test with cookie consent enabled.

TranslatePress: setup and verification

Install TranslatePress and add your languages under Settings > TranslatePress. Enable automatic user language detection in the General tab. Adjust the default language and the language slug for each installed language.

Configuration options to verify:

• The order of languages shown to visitors.
• The language name and slug.
• Whether translation is manual or uses Google Translate API. Free tier does not include automatic machine translation; check with the vendor.
• The language switcher position.
• Whether specific pages can be excluded from detection or translation.

Verification steps:

1. Use the front-end editor to translate at least one page.
2. Visit the site with a browser set to another language.
3. Confirm the page redirects or shows the right language.
4. Check hreflang tags and language URLs in the page source.
5. Switch languages and confirm the saved choice is remembered.

Common troubleshooting:

• A caching plugin can block detection; exclude translated URLs or clear cache.
• If the translator does not show, confirm your user role and edit permissions.
• If machine translation is missing, check whether your free tier includes it or requires a paid API key.
• If redirects loop, disable extra cache and recheck your language URL settings.

SEATEXT: setup and verification

SEATEXT is the most automated option in this comparison. Install it from the WordPress repository or use the activation page on its site. Connect a free SEATEXT account, then choose the languages you need. The plugin can translate up to 125 languages.

After activation, the plugin detects each visitor's language and translates pages instantly. New posts, products, pages, and updates are translated in the background. No page limits. No language limits. No manual translation project.

Configuration options:

• The target languages you want to expose.
• Whether you review translations before publishing.
• Brand voice controls, if available, when you edit translations.
• Ability to track results by language and market.
• Per-page disable controls, if available; check with the vendor.

Verification steps:

1. Add a new test page and publish it.
2. Check that the plugin creates a translated version.
3. Open the test page in a browser set to a target language.
4. Confirm the content switches and the URL works.
5. Inspect the page for hreflang tags or language-specific URLs.

Common troubleshooting:

• If a translation is missing, wait for the background job; large tasks can take time.
• If your language choice is not honored, confirm the language is selected in the plugin.
• If you need to adjust copy, edit the translation in the SEATEXT dashboard.
• For per-page controls, check with the vendor.

GTranslate: setup and verification

GTranslate is a simpler option. Install it and add the widget to your site. Choose the languages you want to offer. The free version translates text in the browser using Google Translate.

It is not designed for multilingual SEO in the free tier. The free widget does not create indexable language URLs. Use it only for pages you do not need in search results.

Configuration options:

• The widget layout and language list.
• Excluded languages, if the free version supports them; check with the vendor.
• Whether to show a floating button or a fixed menu.
• Whether specific pages can skip the widget.

Verification:

1. Load a page and switch languages.
2. Confirm the translation appears without errors.
3. Check whether the URL changes. In the free version, it usually does not.
4. Confirm the widget does not slow down the page.

Common troubleshooting:

• If Google Translate does not load, check for script blockers.
• If the widget overlaps the site, adjust the layout settings.
• If a language is missing, add it in the widget settings.

Limitations and edge cases

Automatic detection is not perfect. A visitor may use a browser in English but prefer Spanish. No plugin can know that. The best plugins offer a visible language switcher as a fallback.

Headers can be empty. Some browsers, email clients, and bots do not send Accept-Language. In that case, the plugin falls back to the default language.

IP detection has privacy limits. It can also send a visitor to the wrong language if they use a VPN.

Free tiers have constraints. Manual plugins require human translation. Machine-translation plugins may not match your brand voice. Review key pages before publishing.

Avoid running two translation plugins at the same time. They can conflict over URL rewriting, cookies, and language storage. Pick one primary plugin.

FAQ

Does a visitor's saved language choice override detection?

Usually yes. Once a visitor selects a language, the plugin stores that choice in a cookie or URL. On the next visit, that saved choice typically wins over the Accept-Language header. Verify the exact behavior in each plugin's docs.

How are new posts and products handled in free tiers?

SEATEXT translates new posts, products, pages, and updates automatically in the background. Polylang and TranslatePress free require manual translation. GTranslate's widget reads the live page, so new text appears when the visitor switches, but it is not stored as separate SEO-friendly content.

What happens if the visitor's browser language is not offered?

The plugin falls back to the default language. It may also show a language switcher so the visitor can choose manually. No plugin can force a language you have not enabled.

Can language detection be disabled per page?

That depends on the plugin. Some offer per-page settings or language exclusions. Others detect on every page. Check with the vendor for the current option.

Does browser language detection require a cookie?

No. Detection itself uses the HTTP header. Cookies are used to remember the choice after the first visit. If cookies are blocked, detection may run on every page load.

Is IP detection available in free versions?

Not broadly. Most free plugins rely on browser detection. If you need IP-based detection, check the vendor's current free tier. Do not assume it is included.

Can I use Polylang and TranslatePress together?

Not recommended. They both change URL structure and language storage. Running them at once can create redirect loops and broken translations.

Which plugin gives the best multilingual SEO for free?

SEATEXT says it adds automatic multilingual SEO to every translated page. Polylang and TranslatePress can build language URLs and hreflang tags, but verify current support. GTranslate's free widget is not ideal for SEO.

Final recommendation

Start with your site's workload. If you cannot maintain manual translations, choose SEATEXT. If you need a handful of languages and full control, choose Polylang or TranslatePress. If you only need a quick non-indexed transl

The SeaText integration adds a single JavaScript file to your pages. That file runs in the browser sandbox like any analytics or chat widget. It cannot reach your server filesystem, database, or backend APIs unless you explicitly connect those systems through SeaText's own dashboard. The script stays dormant until you complete a domain-verification step that ties the code to a specific, live hostname. Until that handshake finishes, no AI rewrites, personalization, or bot-detection logic executes.

How the script loads and where it runs

You paste one <script> tag into your site's <head> or via a tag manager. The file is served from SeaText's CDN over HTTPS. Browsers enforce the same-origin policy, so the script only sees the DOM of the page it sits on. It cannot read cookies set with the HttpOnly flag, cannot access localStorage keys it didn't create, and cannot make cross-origin requests to your API endpoints unless your server responds with permissive CORS headers.

SeaText's integration guide notes: "The installation process is secure, and the AI remains inert until activated, ensuring the integrity of your website's content." This means the payload downloads but does nothing until the activation handshake succeeds.

Sandboxing and isolation from your backend

Third-party scripts are a known attack vector when they request excessive permissions. SeaText's script does not request eval(), Function() constructors, or dynamic script injection. It communicates with SeaText's servers over HTTPS using fetch or XMLHttpRequest to send anonymized interaction events and receive variant instructions. Those network calls go to SeaText's domain, not yours. Your server never receives traffic from the script directly.

Because the script cannot write to your origin's storage or cookies without explicit page cooperation, a compromise of SeaText's CDN would not automatically grant an attacker persistence on your domain. The blast radius stays limited to the current browser session and the DOM mutations SeaText applies.

Domain verification and activation gate

SeaText ties each account to one primary URL. The integration docs state: "Each SEATEXT AI account is linked to a single primary URL. Development URLs, such as localhost, are restricted for security reasons." This prevents staging or localhost environments from accidentally activating production agents or polluting analytics.

The activation flow requires you to visit the live site, stay for at least 40 seconds, and wait up to ten minutes for the dashboard to show the connected domain name. Until that confirmation appears, the script logs no events and rewrites no content. This deliberate delay gives you a window to remove the code if something looks wrong.

Content Security Policy compatibility

If you enforce a strict CSP, you will need to allow SeaText's script origin in script-src and its API endpoint in connect-src. Because the script does not use inline scripts, unsafe-inline is not required. It also does not inject stylesheets dynamically, so style-src can stay tight. The exact hostnames to whitelist are provided in your SeaText dashboard after account creation.

WP Engine users are directed to a dedicated plugin that injects the script through WordPress's approved JavaScript pathway, which respects the host's CSP defaults.

Data the script sees and what it never touches

• Sees: Page URL, referrer, viewport size, scroll depth, click coordinates on elements it manages, and the text content of DOM nodes it is configured to rewrite.
• Does not see: Password fields (browsers exclude them from DOM reads), HttpOnly cookies, server-side session IDs, database records, or any API responses unless your frontend code passes them into the DOM.
• Sends to SeaText: Anonymized interaction events and the current page's text candidates for variant generation. No form submissions, payment data, or authentication tokens are transmitted.

The Bot Protection Agent runs heuristic checks on the client side (mouse movement patterns, timing, fingerprint signals) and sends a risk score to SeaText. That score is returned to your dashboard for refund-claim reports. It does not block the visitor or modify your server logs.

What changes if you skip the verification step

If you add the script but never complete the 40-second visit and five-minute wait, the script stays inert. No variants are generated, no bot scores are calculated, and no data leaves the browser. This is a safety feature, not a bug. The integration guide warns: "If you do not see it at the top of the page after 10 minutes, please contact our support team immediately. This could indicate an issue during the installation on your platform."

Limitations and when this guidance does not apply

• If you self-host the SeaText file instead of using the CDN, you inherit responsibility for file integrity and HTTPS delivery.
• If you extend SeaText with custom JavaScript callbacks that read sensitive DOM nodes, you expand the trust boundary beyond SeaText's control.
• Organizations with regulatory requirements (HIPAA, PCI-DSS, GDPR special-category data) should run their own penetration test on the integrated page, because SeaText's general security posture does not replace a scope-specific audit.
• The script runs in the visitor's browser. A compromised browser extension or malicious browser build can still read everything SeaText reads. That risk exists for every client-side script.

Key facts

FAQ

Can SeaText read my users' passwords or payment fields?

No. Browsers exclude type="password" fields from normal DOM reads, and SeaText's variant engine targets visible text nodes like headlines, buttons, and product copy. It does not attach listeners to payment iframes or form submissions.

Does the script set cookies on my domain?

SeaText sets first-party cookies only if you enable the optional visitor-ID cookie in the dashboard. Those cookies carry an anonymous session identifier, not personal data. You can disable them and rely solely on fingerprinting for variant consistency.

What happens if SeaText's CDN is compromised?

An attacker could push a malicious script version to your visitors' browsers. The impact would be limited to what the script can do in the browser sandbox: DOM reads, network requests to SeaText's API, and DOM writes on your page. Your server, database, and HttpOnly cookies remain out of reach. Mitigate by pinning the script hash in CSP or self-hosting after security review.

Can I run SeaText on a staging subdomain without a separate account?

No. The integration guide explicitly blocks dynamic development domains and localhost. You must create a separate SeaText account for each distinct hostname, including staging environments.

Does SeaText help with click-fraud refunds?

Yes. The Bot Protection Agent detects suspicious paid clicks, records evidence, and generates refund-ready reports for Google, Meta, TikTok, and Reddit. This runs client-side and does not modify your ad-platform pixels.

How do I verify the script is inactive before activation?

Open DevTools Network tab, filter for the SeaText domain. You should see the script download but no subsequent fetch or XHR calls to the API endpoint until the 40-second visit and dashboard confirmation complete.

Where do I get the exact CSP hostnames for my account?

Log into your SeaText dashboard after account creation. The integration page lists the CDN hostname and API hostname to whitelist in script-src and connect-src.

Quick Answer: The Five Core Steps

To integrate SeaText JavaScript into a Tilda project, follow this sequence:

1. Copy the JavaScript snippet from your SeaText dashboard.
2. Open your Tilda project and go to Site Settings → Custom Code → Header (labeled "Edit code inside HEAD tag").
3. Paste the snippet into that field.
4. Click Save and then Publish the entire site.
5. Visit the live site, stay on a page for at least 40 seconds, and wait about five minutes for the SeaText logo to show your site name — this confirms the connection.

If you only need SeaText on a single page instead of site-wide, use the T123 block method described later in this guide.

Why This Integration Matters

SeaText deploys autonomous AI agents that rewrite headlines, translate content into 125 languages, detect bot traffic in paid campaigns, and adapt pages to each visitor's source. The JavaScript snippet is the bridge that lets those agents read your page, make changes, and report results. Without the snippet, none of the agents — conversion optimization, translation, bot refund, or ChatGPT visibility — can function.

Tilda stores the snippet in the global <head> so it loads on every page before the body renders. That placement ensures the AI can modify any element, including meta tags and structured data, before search engines or ad platforms crawl the page.

Prerequisites Before You Start

• Active SeaText account. Each domain requires its own account; development URLs such as localhost are blocked for security.
• Admin access to the Tilda project. You need permission to edit Site Settings and publish.
• A valid, live domain. Dynamic preview domains may not associate traffic reliably with your SeaText account.

If you manage multiple websites, create a separate SeaText account for each one. The system ties one primary URL to one account.

Method 1: Site-Wide Installation (Recommended)

This method places the snippet in the <head> of every page automatically.

1. Log in to SeaText and open your project dashboard.
2. Locate the JavaScript integration code — it appears in a box labeled SEATEXTCODEINTEGRATION.
3. Copy the entire snippet (including the opening <script> and closing </script> tags).
4. In Tilda, open the project and click Site Settings (gear icon).
5. Choose Custom Code → Header. The field is labeled "Edit code inside HEAD tag".
6. Paste the snippet into that field.
7. Click Save, then return to the page list and click Publish all pages.

After publishing, open the live site in a new browser tab. Stay on any page for at least 40 seconds. This visit activates the AI and links the domain to your SeaText account. Wait roughly five minutes, then refresh the SeaText dashboard — your site name should appear next to the SeaText logo at the top.

Method 2: Single-Page Installation (T123 Block)

Use this when you only want SeaText on a specific landing page, not the entire site.

1. In Tilda, open the target page in the editor.
2. Click the + icon to add a new block.
3. Scroll to the Other category and select block T123 ("HTML code for the head section").
4. Click Content on the block to open the HTML editor.
5. Paste the SeaText JavaScript snippet.
6. Click Save and Close.
7. Publish the page.

The T123 block injects the script into the <head> of that page only. Verify activation the same way: visit the live page, stay 40+ seconds, wait five minutes, check the SeaText dashboard.

Key Facts at a Glance

Common Mistakes and How to Avoid Them

• Pasting into the wrong field. Tilda has separate fields for <head>, <body> start, and <body> end. SeaText must go in the <head> field ("Edit code inside HEAD tag").
• Forgetting to publish. Saving Site Settings is not enough; you must click Publish all pages (or publish the single page if using T123).
• Testing on a preview domain. Dynamic Tilda preview URLs often fail to register with SeaText. Use the real, published domain.
• Using one account for multiple domains. Each domain needs its own SeaText account; otherwise traffic attribution breaks.
• Closing the tab too soon. The 40-second visit is required to handshake the AI with your account. Shorter visits may not register.

Verification Checklist

1. Open browser dev tools (F12) → Console. Look for a SeaText initialization log — no errors should appear.
2. In the SeaText dashboard, confirm the site name shows next to the logo.
3. Navigate a few pages on the live site; the SeaText badge (if enabled) should appear.
4. Check that the agents you plan to use (Translation, Google Ads, Bot Refund, etc.) show "Active" status in the dashboard.

If the site name does not appear after 10 minutes, re-check the snippet for extra whitespace or missing tags, republish, and repeat the 40-second visit.

Limitations and Scope

• SeaText does not support localhost or staging subdomains that change frequently.
• One SeaText account = one primary URL. Subdomains count as separate domains unless configured otherwise in the dashboard.
• The snippet loads asynchronously; it will not block page render, but agents only start working after the activation visit.
• Tilda's own caching or CDN may delay script propagation by a few minutes after publish.
• This guide covers JavaScript integration only. Server-side or API integrations are not available for Tilda.

Terminology

SeaText Dashboard

The web interface at seatext.com where you manage accounts, view agents, and copy the integration snippet.

T123 Block

A Tilda block type (under Other → HTML code for the head section) that injects custom code into a single page's <head>.

Activation Visit

A real user session of at least 40 seconds on the live domain that registers the domain with the SeaText account.

Agent

An autonomous AI module (e.g., Conversion Agent, Translation Agent, Bot Refund Agent) that you enable in the dashboard after integration.

Frequently Asked Questions

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

No. Each primary domain requires its own SeaText account. Create a separate account for each website.

Does the snippet slow down my Tilda page?

The script loads asynchronously and is designed to be non-blocking. SeaText states the AI remains inert until activated, so there is no runtime cost before the first qualifying visit.

What if I change my domain later?

You will need a new SeaText account for the new domain. The old account stays tied to the original URL.

Can I install SeaText via Google Tag Manager instead?

The official documentation only describes direct <head> placement (Site Settings or T123). GTM deployment is not covered in the current integration guide.

How do I know which agents are active?

After the connection confirms (site name appears next to the logo), open the SeaText dashboard. Each agent shows an "Active" toggle. Enable the ones you need — Translation, Google Ads, Bot Refund, etc.

Is there a way to test before going live?

Because development URLs are restricted, the only reliable test is on the real published domain. You can publish to a low-traffic subdomain first, complete the activation visit, verify in the dashboard, then point your primary domain.

Next Steps After Integration

Once the snippet is live and the dashboard shows your site name, log in to SeaText and activate the agents that match your goals:

• Conversion Agent — rewrites headlines, offers, and CTAs per visitor source.
• Translation Agent — serves 125 languages with manual override controls.
• Google Ads Agent — matches landing-page copy to the exact keyword clicked.
• Bot Refund Agent — detects invalid clicks and builds refund-ready reports for Google, Meta, TikTok, Reddit.
• ChatGPT Visibility Agent — structures brand data so AI assistants recommend you.

Each agent is a one-click toggle; no further code changes are required.

How SeaText JavaScript Affects Tilda Page Load

Adding SeaText JavaScript to your Tilda site can slow down page load if inserted incorrectly. The script is small, but how and where you add it determines whether it blocks the page from rendering. The key is to avoid render-blocking by choosing the right placement and loading method.

Trade-Off Table: Placement Options for SeaText in Tilda

Choose footer placement if you want zero impact on initial load. Choose head with async/defer if you need the script ready early but don’t want to block content. Avoid synchronous head placement unless you have a specific reason.

How JavaScript Affects Page Load Time

When a browser loads a page, it parses HTML and builds the DOM. If it encounters a <script> tag without async or defer, it stops parsing, downloads the script, and executes it before continuing. This delay is called render-blocking. The longer the script download or execution, the slower the page appears to load.

SeaText JavaScript is lightweight – the source pack confirms it “remains inert until activated.” But even a small script can block rendering if placed in the head without async or defer. Network latency (e.g., a slow CDN) adds to the delay.

SeaText Script Placement Options in Tilda

From the Tilda integration guide (source S1), you have two official ways to add SeaText:

• Site-wide head code: Go to Site Settings → More → HTML code for the head section → paste the code. This places the script in the <head> of every page. By default, it’s synchronous.
• Per-page head code: Edit a page, add a T123 block, and paste the code into the HTML editor. You can then place the T123 block anywhere, including the footer area.

To avoid render-blocking, use the per-page method and place the T123 block near the end of the page (footer). Or, if you must use the head section, wrap the script with async or defer attributes. For example: <script src="your-seatext-code.js" async></script>.

Step-by-Step: Adding SeaText to Tilda with Minimal Impact

1. Copy the SeaText script from your account dashboard.
2. Choose a placement method: For minimal load time impact, use a T123 block in the footer.
3. Add the T123 block: In Tilda page editor, click “+” → “Other” → “T123”. Paste the script into the Content field.
4. Move the block to the footer: Drag the T123 block to the bottom of the page, after all other content.
5. Save and publish the page.
6. Verify: Open the page in a browser and check the Network tab in DevTools. Look for the SeaText script – it should load after the page content, not before.

Common Mistakes That Slow Down Your Tilda Site

• Placing the script in the head without async/defer. This is the most common cause of unnecessary delay.
• Adding multiple SeaText scripts. Each account is linked to one domain. Using scripts from different accounts on the same page causes duplicate requests.
• Not waiting for activation. The source pack says “Visit or refresh your website several times and stay on your page for at least 40 seconds – this will activate the AI.” This does not affect initial load time but is required for functionality.

How to Verify Load Time Impact

Use your browser’s Developer Tools (F12) to check:

• Network tab: See when the SeaText script loads relative to the page’s HTML and other resources. A synchronous script in the head will appear before the page’s content finishes.
• Performance tab: Record a load and look for “Long Tasks” or delays. If the SeaText script is not render-blocking, it should appear after the First Contentful Paint.
• Lighthouse: Run a performance audit. If the script is render-blocking, it will flag “Eliminate render-blocking resources.”

Key Facts Table

Limitations and When This Advice Doesn’t Apply

If your Tilda page already has many third-party scripts (e.g., analytics, chat widgets, tracking pixels), adding SeaText may contribute to cumulative latency. The advice to use footer placement helps, but total page weight matters. For pages with heavy images or custom fonts, the script’s impact is negligible.

If you use SeaText agents that rewrite content in real-time (e.g., Google Ads Agent), the script must run before the page is fully interactive. In that case, use async in the head to balance speed and functionality.

Frequently Asked Questions

What is the best placement for SeaText in Tilda to avoid slow load times?

Place the script in a T123 block at the bottom of the page (footer). This ensures all content loads first.

Does SeaText add extra HTTP requests that slow down the page?

Yes, it adds one HTTP request. But the script is small, and with async/defer or footer placement, the request does not block rendering.

Can I use the async or defer attribute on the SeaText script in Tilda?

Yes, if you paste the script into the head section, wrap it with <script> tags and add the attribute. However, Tilda’s head code editor does not allow custom attributes; you may need to use the T123 block method and add the attribute manually.

Will SeaText slow down my Tilda site on mobile?

Mobile networks have higher latency. Using footer placement or async/defer minimizes the impact. The script itself is lightweight, so the effect is small.

How long does it take for SeaText to activate after adding the script?

After you paste the code and publish, you must visit the page and stay for at least 40 seconds. The AI then activates. This does not affect initial page load times.

Does SeaText affect Tilda’s built-in performance optimizations?

No, Tilda’s optimizations (like lazy loading, CSS minification) still work. SeaText adds a single script that can be loaded without blocking those optimizations if placed correctly.

The short answer is no. A SeaText API key belongs to one account. Each SeaText account is linked to one primary URL. You cannot use that key on another Tilda domain.

This is not a limit you can bypass. The key is tied to the domain you enter when you create the account. To run SeaText on multiple Tilda sites, you need one account per site and the correct key on each site.

This article explains the authentication model, the common mistake of reusing keys, installation steps, activation behavior, and how to manage many SeaText accounts cleanly.

How SeaText Authentication Works

SeaText identifies websites with API keys. When you create an account, you provide a primary URL. SeaText then gives you a JavaScript snippet with a unique key for that account.

Why is one key required for each domain? Because the key is the link between visitor traffic and your dashboard. If two domains used the same key, SeaText could not tell which domain created the data.

Data isolation is another reason. A company with several sites needs separate reports, agent settings, and bot evidence. Separate keys keep those records clean.

Security also matters. A unique key limits the damage if a key is exposed. One leaked key affects one domain, not your entire portfolio.

The validation process is simple. The JavaScript snippet sends the key with page requests. SeaText compares the requesting domain with the primary URL stored on the account. If they match, the site can connect. If they do not match, the request is ignored.

You do not need to run a server or configure DNS for this check. The snippet handles the request, and SeaText does the comparison automatically.

Think of the key as a door key. A key made for one front door will not open another door. The same idea applies here.

The Common Mistake: Reusing a Key Across Domains

The most common mistake is copying one SeaText snippet to multiple Tilda sites. The code loads on every page, so it looks like SeaText is installed. But the key still belongs to the original primary URL.

Here is a typical scenario. Your primary URL is www.example.com. You copy that snippet to www.second-example.com. When someone visits the second site, the snippet sends the key. SeaText checks the domain, sees a mismatch, and does not activate the AI.

Another common scenario involves staging. A developer takes the production key and puts it on a staging domain. The staging site never activates because its URL does not match the production primary URL.

What does that look like? The dashboard still shows only the original domain. The second site appears to have no data. Refresh, cache clearing, and repeated visits will not fix it.

The fix is always the same: create a new account for each new domain. Install the new account's snippet on that domain only.

Setting Up SeaText on Multiple Tilda Sites

Each Tilda domain needs the same setup process. Follow these steps for every domain:

1. Go to the SeaText integration page and create an account for the domain.
2. Enter the domain as the primary URL when you create the account.
3. Copy the JavaScript snippet from the SeaText page.
4. Open the Tilda dashboard for that site.
5. Go to Site Settings.
6. Click More, then HTML code for the head section, then Edit code.
7. Paste the snippet into the field labeled Edit code inside HEAD tag.
8. Save and publish the site.
9. Visit or refresh the site several times.
10. Stay on the page for at least 40 seconds.
11. Wait at least five minutes.
12. Check the integration page for your website name next to the SeaText logo.

If you only need the code on one page, use the T123 block method. Add the T123 block to the page, open Content, paste the snippet into the HTML editor, save, and publish.

Managing multiple Tilda accounts efficiently starts with a simple system. Do not rely on memory.

• Use an account name that clearly matches the domain, such as example-com.
• Use an email address you control for each account, or use aliases.
• Store each key in a password manager with the domain name.
• Keep a spreadsheet with domain, account email, key, install date, and status.
• Verify each domain in the SeaText dashboard before you start the next one.
• Use a separate browser profile for each account so you do not copy the wrong key.
• Mark the domain as connected after the website name appears next to the logo.

This routine takes a few minutes. It saves hours of debugging if something goes wrong later.

Key Facts at a Glance

Use this table as a quick checklist before you install SeaText on a new Tilda domain.

Limitations and Exceptions

SeaText does not support one key on multiple primary URLs. There is no shared-key mode or team project that changes that rule.

Staging and production sites are separate. If you run a development domain and a production domain, create one SeaText account for each.

Development URLs are restricted for security. localhost is blocked. Dynamic development domains, such as temporary URLs from cloud tools, may not work because SeaText cannot reliably connect their traffic to your account.

Use a real, valid domain for testing. This avoids a confusing setup where the code is present but no data appears.

A permanent domain change also creates a limitation. Your account was created with one primary URL, so the old key is unlikely to work on the new domain. Create a new account for the new URL. If you have a complex migration, check with the vendor.

Subdomains are separate primary URLs. For example, blog.example.com and www.example.com are different domains. Each one needs its own SeaText account.

Wildcard domain support is not mentioned in the source documentation. Treat each domain as an individual account.

Frequently Asked Questions

Can I use one SeaText account for two Tilda websites?

No. One account is linked to one primary URL. You need a separate account for each website.

What is a primary URL?

It is the domain you enter when you create the SeaText account. SeaText uses it to validate the API key.

Can I use the same account for a subdomain, like blog.mysite.com?

No. A subdomain is a different primary URL. Create a separate account for that subdomain.

What if I have a staging and a production domain?

Create one account for staging and another for production. Each account gets its own API key.

How does SeaText know the key is installed correctly?

After installation, visit or refresh the site and stay for at least 40 seconds. Wait five minutes. If your website name appears next to the SeaText logo, the key is working.

Can SeaText activate without visitor traffic?

No. The source instructions say you need to visit or refresh the site several times and stay on the page for at least 40 seconds. This triggers activation.

Is there a limit on the number of SeaText accounts I can create?

The source documentation does not mention a limit. You can create as many accounts as you need, one for each Tilda domain.

What if I accidentally reuse a key on another domain?

The second domain will not activate. Create a new account for that domain, install its unique key, and remove the old snippet.

Does SeaText support wildcard domains?

No. Each account is tied to a single primary URL.

Can I use localhost for testing?

No. localhost is restricted for security reasons.

Can I use a dynamic development domain for testing?

It may not work. SeaText might not be able to reliably associate traffic from dynamic development domains with your account. Use a real, valid domain instead.

How long does activation take after installation?

The source instructions say to wait at least five minutes. The website name should then appear next to the SeaText logo on the integration page.

To add third‑party JavaScript like SeaText on Tilda, you have two main options. For code that must run on every page, open Site Settings, go to the Custom Code section, and paste the script into the field labeled "Edit code inside HEAD tag", then save and publish. For code that should only run on a specific page, add a T123 block (Embed HTML Code) from the Block Library → Other, paste the snippet into the block's HTML editor, save, and publish that page.

Why the placement choice matters

Where you place the script determines which pages load it and when it executes. Site‑wide placement in the <head> ensures the SeaText agent is available before any page content renders, which is required for real‑time rewrites and bot detection. Page‑specific placement via a T123 block loads the script only on that page, useful for testing or for landing pages that need a different configuration.

SeaText's integration guide states: "Paste the code into the field labeled 'Edit code inside HEAD tag', then save and publish your site." (S1) This confirms the site‑wide method is the primary supported path.

How the two methods work

Site‑wide via Site Settings → Custom Code

1. Log in to your Tilda dashboard and open the project.
2. Click Site Settings in the left sidebar.
3. Scroll to the Custom Code section.
4. Find the field labeled "Edit code inside HEAD tag".
5. Paste the SeaText JavaScript snippet provided in your SeaText account.
6. Click Save, then Publish all pages.

This injects the script into the <head> of every page on the domain. The SeaText guide also notes: "Click on More → HTML code for the head section → Edit code." (S1) This is an alternative path to the same field.

Page‑specific via T123 block

1. Open the page you want to modify in the Tilda editor.
2. Click the + icon to add a new block.
3. Choose Other from the block categories.
4. Select the T123 block (Embed HTML Code).
5. Click Content on the block to open the HTML editor.
6. Paste the SeaText snippet.
7. Click Save and Close, then Publish the page.

The guide describes this flow: "Access your Tilda dashboard and navigate to the page that you wish to translate. Click on the '+' icon to add a new block to the page. Choose the block named T123 from the options provided. Scroll down and select 'Other' from the block options. Locate and select the block named T123, which enables the addition of embedded HTML code." (S1)

Trade‑offs between site‑wide and page‑specific placement

Choose site‑wide placement for production deployments. Choose page‑specific placement when you are testing on a staging page or when a single landing page needs a different SeaText configuration.

Step‑by‑step decision framework

1. Is this a production domain? → Use Site Settings → Custom Code → HEAD.
2. Do you need the script on every page? → Use site‑wide method.
3. Are you testing on a single page or a staging subdomain? → Use a T123 block on that page.
4. Does the page use Zero Block? → You can also embed the script via an HTML element inside Zero Block (Tilda Help Center confirms this works identically to T123).
5. After pasting, verify: Visit the page, wait 40+ seconds, then check your SeaText dashboard — the site name should appear next to the SeaText logo within five minutes. (S1)

Common mistakes and how to avoid them

• Pasting into the wrong field. Tilda has separate fields for HEAD, BODY start, and BODY end. SeaText must go in HEAD. The label is exactly "Edit code inside HEAD tag".
• Forgetting to publish. Saving the settings is not enough; you must click Publish all pages (site‑wide) or Publish the specific page (T123).
• Using a development URL like localhost. SeaText restricts localhost and dynamic dev domains. Use a real domain or a valid staging subdomain. (S1)
• Adding multiple SeaText accounts on one domain. Each SeaText account is linked to a single primary URL. For multiple domains, create separate accounts. (S1)
• Not waiting for activation. After publishing, visit the site, stay 40+ seconds, and wait up to five minutes for the connection to register in the SeaText dashboard.

Limitations and when this advice does not apply

• Tilda Free plan. Custom Code access may be restricted on the free tier; check your plan's features.
• AMP pages. If you enable AMP on Tilda, custom HEAD scripts may be stripped. SeaText does not run on AMP versions.
• Content Security Policy (CSP). If your site or hosting adds a restrictive CSP, the SeaText script may be blocked. Adjust CSP to allow https://cdn.seatext.com (or the domain shown in your snippet).
• Multiple domains. Each domain needs its own SeaText account and its own Tilda project with the script installed.
• Non‑Tilda sites. These instructions apply only to Tilda. Other platforms (WordPress, Webflow, Shopify) have different integration paths.

Key facts

Terminology

• Site Settings — Project‑level configuration in Tilda dashboard (gear icon or left sidebar).
• Custom Code — Section in Site Settings for injecting scripts/styles into <head>, <body> start, or <body> end.
• T123 block — Tilda's "Embed HTML Code" block, found under Block Library → Other.
• Zero Block — Tilda's advanced visual editor; can also host an HTML element for scripts.
• Publish — Tilda's deploy action that pushes changes to the live domain.

FAQ

Can I add SeaText to only my homepage?

Yes. Add a T123 block on the homepage only, paste the snippet, and publish that page. The script will not load on other pages.

What if I don't see "Edit code inside HEAD tag" in Site Settings?

Your Tilda plan may not include Custom Code access. Upgrade to a plan that supports it, or use the T123 block method on each page you need.

Does the T123 block work in Zero Block?

Tilda's help center states you can embed HTML as a separate element in Zero Block, and it works on the same principle as the T123 block. Use whichever fits your workflow.

Why does SeaText require a real domain, not localhost?

SeaText associates traffic with your account via the domain. Localhost and dynamic development domains cannot be reliably linked, so they are restricted for security. (S1)

How do I verify the script is working?

After publishing, visit the page and stay for at least 40 seconds. In your SeaText dashboard, the site name should appear next to the SeaText logo within five minutes. (S1)

Can I use the same SeaText account on a staging subdomain and production domain?

No. Each SeaText account is linked to a single primary URL. Create a separate account for staging if you need full functionality there. (S1)

What happens if I paste the script in the BODY field instead of HEAD?

The script will still load but later in the page lifecycle. SeaText's real‑time rewrites and bot detection work best when the script is in HEAD. Use the HEAD field for production.

Add the SeaText JavaScript to your Tilda site during initial site setup or the moment you create your SeaText account and choose a plan. The script must be present on every page you want optimized before you activate any AI agents — otherwise the agents have no way to rewrite content, detect bots, or translate pages. If you already have a live Tilda site, add the script as soon as you decide to use SeaText; delaying only postpones the 40‑second activation visit and the five‑minute connection check that confirm the integration works.

Why timing matters for SeaText on Tilda

SeaText’s autonomous agents — conversion optimizer, Google Ads matcher, bot‑refund detector, translation engine, and others — run entirely in the browser after the script loads. No script means no agent activity, no keyword‑aware rewrites, no bot evidence collection, and no multilingual rendering. The integration guide states: "Paste the Javascript code from Seatext on your website To insert code in the head of all website pages, go to the Site Settings. Paste the code into the field labeled 'Edit code inside HEAD tag' , then save and publish your site." Until that step is complete, the AI remains inert.

Readiness checklist: before you add the script

• SeaText account created. You need a valid SeaText account; each account is tied to a single primary domain.
• Primary domain is live and not a development URL. Localhost and dynamic staging domains are restricted for security reasons.
• Tilda Site Settings accessible. You must have permission to edit the global HEAD code field or add a T123 block on specific pages.
• Plan selected or trial started. Agent activation requires an active subscription or the free one‑month pilot.
• Time reserved for verification. After publishing, you’ll need to visit the site, stay at least 40 seconds, and wait five minutes for the dashboard to show the site name next to the SeaText logo.

When to add during site setup vs. later

New Tilda project: Insert the script in Site Settings → HEAD before you publish the first version. That way every page — including future pages — inherits the script automatically. Existing live site: Add the script immediately after you create the SeaText account. Use the global HEAD field for site‑wide coverage; only use a per‑page T123 block if you intentionally want SeaText on a subset of pages. Redesign or migration: Re‑add the script in the new environment before you switch DNS. The script is tied to the domain, not the Tilda project ID.

How the activation process works

1. Copy the JavaScript snippet from your SeaText dashboard (the code appears under the integration section).
2. In Tilda, open Site Settings → More → HTML code for the head section → Edit code.
3. Paste the snippet into the "Edit code inside HEAD tag" field.
4. Save and publish the site.
5. Visit the published site, refresh a few times, and remain on a page for at least 40 seconds.
6. Wait at least five minutes. The SeaText dashboard will then display your website name next to the logo, confirming the connection.

The guide emphasizes: "Important: Visit or refresh your website several times and stay on your page for at least 40 seconds—this will activate the AI and link it to your account. Important: Wait at least five minutes until you see your website name displayed next to the SEATEXT logo at the top of this page. This indicates that your website is connected and ready to proceed to the next step."

Common timing mistakes and exceptions

• Adding the script but not publishing. The script only runs on the published version; draft changes don’t count.
• Using a staging subdomain (e.g., staging.mysite.tilda.ws) for the primary account. Each domain needs its own SeaText account; staging domains count as separate domains.
• Skipping the 40‑second visit. Without real browser traffic, the AI never activates and agents stay dormant.
• Exception — per‑page testing. If you only want to test SeaText on a single landing page, add a T123 block ("Embed HTML Code") to that page instead of the global HEAD. This limits activation to that page only.

Key facts

Limitations and when this advice does not apply

• If you manage multiple brands on subdirectories (e.g., example.com/brandA, example.com/brandB) under one Tilda project, a single script covers all — but each brand may need its own SeaText account if they use different primary domains.
• Tilda’s Zero Block HTML element can also hold the script, but the global HEAD field is simpler for site‑wide coverage.
• This checklist assumes you control the Tilda Site Settings. Agency or client‑side permission constraints may shift the timing to a hand‑off meeting.
• SeaText does not support localhost or ephemeral preview URLs; you must use a real, publicly resolvable domain.

FAQ

Can I add the script after I’ve already launched my Tilda site?

Yes. Add it in Site Settings → HEAD, publish, then complete the 40‑second visit and five‑minute wait. All existing pages will start receiving agent activity immediately.

Do I need to re‑add the script if I change Tilda templates?

No. The global HEAD code persists across template changes. Only a full project reset or domain change would require re‑entry.

What happens if I add the script but never activate agents in the dashboard?

The script loads but stays inert. No rewrites, translations, or bot detection occur until you toggle agents on in your SeaText account.

Can I use the same SeaText account for a Tilda site and a WordPress site on the same domain?

No. Each primary domain requires its own SeaText account. If both sites share the exact same domain (e.g., subdirectory vs. subdomain), you’d still need separate accounts per SeaText’s one‑account‑per‑domain rule.

How do I verify the script is working before activating agents?

After publishing, open the browser dev tools → Network tab, filter for "seatext", and confirm the script loads. Then complete the 40‑second visit; the dashboard connection status is the final proof.

Is there a downside to adding the script early, before I’m ready to pay?

No downside. The script is lightweight and inert until you activate agents. Adding it early lets you verify the connection while you finalize agent selection.

What if my Tilda site uses a custom domain that isn’t live yet?

Wait until the custom domain resolves and serves the published Tilda site. SeaText cannot connect to a domain that doesn’t serve content.

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

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

How SeaText Data Collection Works on Tilda

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

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

Common Reasons the Dashboard Stays Empty

1. Content Security Policy Blocks the Script

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

2. You Saved but Didn't Publish

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

3. Traffic Below the Reporting Threshold

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

4. Development or Localhost Domains Are Restricted

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

5. Wrong Account or Multiple Domains on One Account

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

Diagnostic Sequence: Find the Root Cause in Order

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

Key Facts

Limitations and When This Advice Doesn't Apply

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

Terminology

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

FAQ

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

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

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

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

How do I fix a CSP block on Tilda?

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

Does SeaText work on Tilda's free plan?

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

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

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

How long until I see variant impressions after the handshake?

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

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

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

Removing the SeaText code from Tilda stops SeaText from running on your site. Active experiments, real-time rewrites, and agent-driven changes stop because the JavaScript code is no longer loaded by your pages. Your historical data stays in the SeaText dashboard for reporting, so you do not lose past results by deleting the snippet.

The code is a small JavaScript snippet. It lives in your Tilda page or site settings and connects the page to SeaText. When it is gone, the page loads as normal Tilda content with no SeaText layer.

What stops when the code is removed

SeaText works by reading visitor behavior and adjusting what the page shows. The script has to run for that to happen. Remove the script, and the connection disappears.

• Any active A/B tests stop serving new variants.
• Keyword-matched Google Ads page rewrites stop.
• Translation of page content stops appearing in real time.
• Bot detection stops scanning new paid traffic.
• Personalization and visitor-source adaptation stop.

The published Tilda page stays intact. SeaText does not delete your site or change its source files in Tilda. It only stops applying changes on new page loads.

What stays in the dashboard

Removing the code does not erase your SeaText dashboard. You can still open reports and see conversion reporting by page, keyword, and variant. That matters if you need to review performance after a campaign ends or decide whether to come back later.

If you need the numbers outside SeaText, save a copy before you remove the code. The dashboard keeps historical data, but it is not a substitute for exporting what you plan to share with a team or client.

Why the distinction matters

Removing the code is not a pause button. It is a stop button for new activity. Old data stays, but no new data is collected. That is useful when you are ending a test or switching platforms. It is a problem if you think the dashboard will keep showing new visitor sessions after removal.

If your goal is to keep optimizing, keep the code installed. If your goal is to stop using SeaText, remove the code and then use the dashboard to review what already happened.

How to remove the SeaText code from Tilda

Removal depends on how you installed the code. SeaText can be installed site-wide through Site Settings or on one page through a T123 block.

Site-wide removal

1. Go to Tilda Site Settings.
2. Click More, then HTML code for the head section, then Edit code.
3. Find the SeaText JavaScript snippet.
4. Delete the snippet.
5. Save and publish your site.

Page-specific removal

1. Open the page in your Tilda dashboard.
2. Find the T123 block that contains the SeaText code.
3. Click Content to open the HTML editor.
4. Delete the snippet.
5. Click Save and Close, then Publish the page.

If you are not sure which method you used, check both places. Code in Site Settings affects every page. Code in a T123 block affects only that page.

How to reinstall SeaText on the same Tilda site

You can reinstall later. Use the same SeaText account when the primary URL has not changed. If you switch to a new domain, create a separate account for that domain.

1. Log in to SeaText and copy the JavaScript code from the integration section.
2. In Tilda, go to Site Settings.
3. Click More, then HTML code for the head section, then Edit code.
4. Paste the snippet into the field labeled Edit code inside HEAD tag.
5. Save and publish the site.
6. Visit or refresh your website several times and stay for at least 40 seconds. This activates the AI and links it to your account.
7. Wait at least five minutes. When the website name appears next to the SEATEXT logo at the top of the page, the connection is ready.

Key facts

Limitations and exceptions

The biggest limitation is that historic data staying in the dashboard does not mean new data keeps flowing. Once the code is gone, SeaText cannot record new visitor sessions, run experiments, or protect new ad clicks from bots.

Another limitation involves domains. Each SeaText account is linked to one primary URL. If you remove code from an old domain and add it to a new domain, the old account does not follow automatically. Create a new account for the new domain.

Development URLs are also restricted. Localhost and dynamic development domains may not connect reliably. Use a real domain if you need to test removal or reinstallation.

If the code was installed only on one page, removing that page's T123 block stops agents on that page only. Site-wide code in Site Settings continues on other pages until you remove it too.

If you use multiple SeaText accounts for multiple domains, removing code from one site does not change other sites. Each site needs its own code and its own account.

Terminology

• SeaText code: the JavaScript snippet that connects your Tilda page to SeaText.
• HEAD tag: the part of the page where Tilda lets you insert site-wide HTML.
• Agent: one of the SeaText tools, such as the Conversion Agent or Bot Refund Agent.
• Primary URL: the single domain linked to a SeaText account.
• T123 block: a Tilda block used for custom HTML, which is one way to install SeaText on a single page.

Frequently asked questions

Will my Tilda page break if I remove the SeaText code?

No. The snippet only runs SeaText. Tilda keeps the content you published. If SeaText had been rewriting content in real time, visitors will now see the original published page.

Do I lose my SeaText reports?

No. Historical data remains in the dashboard. Save a copy before removal if you need the numbers outside SeaText.

Can I reinstall SeaText on the same Tilda site later?

Yes. Paste the code back into the HEAD tag, publish, then visit or refresh the site for at least 40 seconds. Wait about five minutes for the connection to appear.

What if I only remove SeaText from one page?

Only that page stops using SeaText. Site-wide code continues on other pages until you remove it from Site Settings.

What if I move to a new domain after removing the code?

Create a separate SeaText account for the new domain. Each account is linked to a single primary URL.

Does bot detection keep working after removal?

No. Bot detection runs through the script. Without the script, SeaText cannot see new bot clicks on your site.

After enabling SeaText AI on your Elementor or Divi site, the content is translated automatically—but that alone doesn't guarantee search engines will treat each language version correctly. You need to verify a handful of SEO settings to make sure translated pages rank, avoid duplicate content penalties, and appear in the right regional search results. This checklist covers the most important settings to review.

1. Check Hreflang Tags

Hreflang tags tell Google which language and region a page is for. Without them, a Spanish version might compete with the English version, or Google might serve the wrong language to searchers. SeaText AI should generate hreflang tags automatically, but you still need to confirm they exist and point to the correct URLs.

What to do: View the page source of a translated page. Look for link rel="alternate" hreflang="es" (or your target language). Check that the href points to the correct translated URL and that the self-referencing hreflang tag is also there. Use Google Search Console's URL Inspection tool to see the detected hreflang.

Common mistake: Missing hreflang for the default language (e.g., hreflang="x-default"). Add it if SeaText doesn't include it automatically.

Why it matters: Correct hreflang implementation prevents duplicate content issues and ensures users see the right language in search results. It also helps Google understand the relationship between language versions.

2. Verify Translated Meta Titles and Descriptions

SeaText AI translates the visible text on your page, but meta titles and descriptions are often stored in separate fields. If your Elementor or Divi theme uses custom meta boxes, the translation might not apply to them. Search engines use these for rankings and click-through rates, so each language must have its own unique title and description.

What to do: Check a few translated pages. Look at the HTML <title> tag and the meta name="description" content. If they still show the original language, you may need to enable translation for these fields in SeaText settings or use a plugin like Yoast SEO with SeaText's integration.

Practical tip: Use an SEO browser extension to quickly view meta tags across multiple pages. Compare the original and translated versions side by side.

3. Confirm Canonical URLs

Canonical tags tell search engines which version of a page is the primary one. On a multilingual site, each language version should have a canonical pointing to itself—not to the original page. If the canonical stays on the English page, the translated version might not be indexed.

What to do: View the page source of a translated page. Look for rel="canonical". Ensure it points to the same URL as the page you're on. For example, if the Spanish URL is /es/producto, the canonical should be /es/producto, not /product.

Why it matters: Self-referencing canonicals signal to Google that each language version is a distinct page worthy of indexing. This avoids consolidation of ranking signals to a single language.

4. Inspect the XML Sitemap

Translations need to be included in your XML sitemap so search engines can find them. A sitemap should list every language version of every page. SeaText AI may automatically add translated pages to your sitemap, but you should verify this.

What to do: Go to /sitemap.xml on your site. Look for entries with language-specific URLs. If you use a plugin like Yoast or Rank Math, check that it includes the translated pages. If not, you may need to submit the sitemap to Search Console again after SeaText creates the translations.

Practical tip: Use the Sitemaps report in Google Search Console to see how many URLs were discovered and indexed per language.

5. Review Language-Specific URL Structure

How your translated URLs are structured matters for SEO. Common patterns include subdirectories (/es/), subdomains (es.example.com), or query parameters (?lang=es). SeaText AI typically uses subdirectories, which is the recommended approach because it's easy to manage and retains link equity.

What to do: Check that all translated pages use a consistent URL structure. Avoid mixing subdirectories with subdomains, as that can confuse search engines. Also verify that the default language (e.g., English) does not have a prefix—or if it does, it's consistent.

Decision criteria: Subdirectories are best for most sites. Subdomains can be used for separate teams or distinct branding. Query parameters are not recommended for SEO.

6. Validate Open Graph and Social Meta Tags

Open Graph tags control how your pages appear when shared on social media. Each language version should have its own OG title, description, and image. If these tags remain in the original language, social shares will show mismatched content.

What to do: Use a social media preview tool (like the Facebook Sharing Debugger) on a translated page. Check that the OG title and description are in the correct language. If not, you may need to enable translation for these meta fields in SeaText's settings or adjust your theme.

Why it matters: Social shares drive traffic. Correct OG tags improve click-through rates from social platforms for each language audience.

7. How SeaText AI Automates Multilingual SEO

SeaText AI provides free automatic multilingual SEO for every translated page. It translates content into 125 languages, with new content translated automatically as you publish. The system works with Elementor and Divi without breaking layouts, translating visible text while preserving structure. Activation is a one-time step on your WordPress site; translation runs by itself in the background.

Mechanics: When you publish a new page, SeaText detects it, translates all visible text, and generates the necessary SEO tags (hreflang, canonical, meta tags) for each language. It also adds translated URLs to your sitemap. You can edit translations directly in the WordPress editor, and SeaText preserves your edits on subsequent updates.

Source: SeaText documentation confirms automatic multilingual SEO, 125-language coverage, and background translation (source: S1).

8. Monitoring Indexation and Performance

After verifying the settings above, monitor how search engines handle your translated pages. Use Google Search Console to track index coverage per language. Check the Performance report filtered by country or language to see impressions and clicks.

What to do: In Search Console, go to Index > Coverage. Filter by URL pattern (e.g., /es/) to see indexed vs. excluded pages. Submit any missing URLs via the URL Inspection tool. Set up International Targeting report (legacy) or use the new International targeting settings to monitor hreflang errors.

Practical scenario: If you notice a language version has low indexation, check for crawl errors, robots.txt blocks, or missing internal links to that language version.

Limitations and When to Adjust

The checklist above covers the most common settings, but some situations require extra steps:

• Custom meta fields: If your Elementor or Divi site uses custom fields for titles or descriptions, SeaText may not translate them automatically. You may need to map those fields in SeaText's settings or use a plugin that supports translation of custom fields.
• Dynamic content from plugins: Content loaded via AJAX or injected by third-party plugins may not be picked up by SeaText. Check these pages manually.
• Cache plugins: Caching can serve old versions of translated pages. Clear your cache after translations are generated and ensure your caching plugin is configured to serve the correct language version.
• SEO plugin conflicts: Some SEO plugins (like Yoast) may override hreflang tags or sitemaps. Test with your specific setup.

Frequently Asked Questions

Does SeaText AI automatically add hreflang tags?

Yes, SeaText AI generates hreflang tags for each translated page as part of its automatic multilingual SEO. However, you should verify that they are correct and include the x-default tag.

Will my translated pages appear in the sitemap automatically?

SeaText AI adds translated pages to your WordPress sitemap if your site uses a standard sitemap structure. You may need to resubmit the sitemap to Google Search Console to trigger re-crawling.

How do I check if my meta titles are translated?

View the page source of a translated page and look for the <title> tag. Alternatively, use an SEO browser extension or the URL Inspection tool in Google Search Console.

What if my canonical URLs are not self-referencing?

Check your SEO plugin settings. Some plugins set canonical URLs based on the original language. You may need to disable that or use a filter to override for translated pages.

Can I edit translations after SeaText generates them?

Yes, you can edit the translated text directly from the WordPress editor. SeaText preserves your edits and does not overwrite them on subsequent updates (source: S1).

How long does it take for translations to be indexed?

Indexing speed depends on your site's crawl budget and how often search engines check your sitemap. Submitting the sitemap and requesting indexing via Search Console can speed it up.

Do I need to set up language-specific URLs manually?

No, SeaText AI automatically configures language-specific URLs (typically subdirectories like /es/). You can change the pattern in your settings if needed.

What happens if I use a caching plugin?

Caching plugins may serve stale translations. Configure your cache to vary by language cookie or URL path, and purge cache after new translations are published.

Can SeaText translate images and alt text?

SeaText translates visible text including alt attributes for images. For image files themselves, you may need to provide localized versions manually.