You don't need to clear cache to make your Thinkific site show up in SeaText. Clearing cache only changes what your browser displays. SeaText links your site after you install the JavaScript code, visit your site for at least 40 seconds, and wait about five minutes. If your site name still isn't visible after 10 minutes, contact SeaText support.

Here is the short version of the process: copy the code, paste it into Thinkific's Site Footer Code field, save, add your website address, visit the site for 40 seconds, then wait. The "show up in SeaText" signal is your website name appearing next to the SEATEXT logo at the top of the SeaText page.

What "shows up in SeaText" means

SeaText uses a linking step, not a cache refresh. After you add the code, SeaText needs to see a real visit to your site. That visit activates the AI and links the site to your account.

The visual confirmation is your website name next to the SEATEXT logo. Until you see that, the site is not ready for the next step. If you ignore the 40-second visit and the five-minute wait, your site will not appear in SeaText no matter how many times you clear cache.

Why clearing cache is not the missing step

There are three kinds of cache people confuse here:

• Browser cache stores copies of pages on your computer. A cached page can hide the new footer code.
• Thinkific's platform saves your footer code when you click Save. The integration steps do not mention a Thinkific cache to clear.
• SeaText's refresh happens automatically after the 40-second visit and the five-minute wait.

Clearing your browser cache can help you confirm the code is live. It will not make SeaText connect faster.

Think of it as two separate tasks. Clearing cache is for your eyes. Waiting five minutes is for SeaText.

Prerequisites before you start

• Admin access to your Thinkific dashboard.
• A SeaText account with the JavaScript code visible.
• Your website address in the format www.example.com.
• At least 40 seconds of uninterrupted time to visit your site after saving.

Step-by-step: Add SeaText to Thinkific and trigger the link

1. Copy the JavaScript code from SeaText's Thinkific integration page.
2. Log in to Thinkific and go to your Admin Dashboard.
3. Select Settings.
4. Select the Code & Analytics tab.
5. Paste the code into the Site Footer Code field.
6. Click Save.
7. Use the SeaText form to add your website address in the format www.example.com.
8. Visit your website once and stay on the page for at least 40 seconds.
9. Wait at least five minutes.
10. Check the top of the SeaText page for your website name next to the SEATEXT logo.
11. If you don't see it after 10 minutes, contact SeaText support.

Treat five minutes as the minimum. Checking earlier usually shows nothing.

When you should clear cache anyway

Clear your browser cache if your own preview still shows the old version of the page after you saved the footer code. This is a display problem, not a SeaText problem.

Try a hard refresh first: Ctrl+F5 on Windows, Cmd+Shift+R on Mac. If that doesn't work, clear your browser's cached images and files. A private or incognito window also bypasses cache for a quick check.

Thinkific's integration steps don't ask you to clear a site cache. The footer code field updates when you save. If you see an old page, browser cache is the usual suspect.

What to do if you're in a hurry

Do these in order:

1. Save the code in Thinkific.
2. Add your website address in the SeaText form.
3. Open your public site and stay for 40 seconds.
4. Wait five minutes before checking.

Don't clear cache first. If your browser shows an old page, use an incognito window to check the code is live, then complete the 40-second visit.

What to check if SeaText still doesn't show your site

• Is the code in the Site Footer Code field, not somewhere else?
• Did you click Save after pasting?
• Did you add your website address with the www.example.com format?
• Did you visit the public site, not just the Thinkific admin preview?
• Did you stay for at least 40 seconds?
• Did you wait at least five minutes after that visit?

Common mistakes include pasting the code into the wrong field, visiting the Thinkific admin preview instead of the public site, leaving before 40 seconds, and checking before five minutes. Each one makes it look like cache is the problem when the real issue is timing or placement.

SeaText's instructions say to contact support if the name still isn't there after 10 minutes. This is the right move if your checklist looks correct.

Key facts

Limitations: when this advice doesn't apply

This process is for Thinkific sites that use the Site Footer Code field. If you manage code through a third-party tag manager, the paste-and-save step will be different.

Clearing cache does not replace the 40-second visit. If you open a cached copy of your page and leave after two seconds, SeaText won't see the visit it needs.

Linking is not the same as activating agents. After the site appears, you still have to go to the Main AI Hub and turn on the AI you want.

SeaText's guide doesn't list a cache purge button for this flow. The refresh is automatic, and the minimum wait is five minutes.

Terminology: cache, footer code, and linking

• Cache is a stored copy of a page. Browsers and services use it to load faster.
• Footer code is JavaScript that runs in the footer of every page where Thinkific inserts it.
• Linking is the step where SeaText matches your website address to your account after a real visit.
• Activation is what you do in the Main AI Hub after linking.

FAQ

Why do I need to stay on my Thinkific page for 40 seconds?

SeaText's Thinkific guide says the 40-second visit activates the AI and links it to your account. It's the trigger for the connection.

Can clearing my browser cache make SeaText connect faster?

No. Clearing cache changes what your browser shows. SeaText still needs the 40-second visit and at least five minutes to link your site.

What if my site name doesn't appear after 10 minutes?

Contact SeaText support immediately. The guide says this could indicate an installation issue on your platform.

Do I need to paste the code on every Thinkific page?

The SeaText steps only mention the Site Footer Code field in Thinkific, so one paste is the intended path.

What's the next step after my site shows up?

Go to the Main AI Hub, activate the AI you need, and click Configuration to adjust the parameters.

Is clearing cache the same as clearing cookies?

No. Cache holds page files. Cookies hold small site preferences and login data. For this setup, cache is the one that can hide a new footer code.

Comparing A/B test results across languages is not as simple as picking the variant with the highest overall conversion rate. Traffic volume, baseline conversion rates, and cultural response patterns differ by language, so a winner in English can lose in German or Japanese. The reliable approach: calculate per-language lift with confidence intervals, weight each language by its traffic share, and run a meta-analysis that flags heterogeneous effects. If the direction of effect is consistent, roll out globally. If effects diverge, keep language-specific winners and invest in a localization strategy.

Why Cross-Language Comparison Breaks Standard A/B Testing

Standard A/B testing tools report a single aggregate p-value and lift. That works when traffic is homogeneous. Multilingual sites violate that assumption in three ways:

• Traffic imbalance: English often carries 60–80% of sessions. A 2% lift in English drowns a -5% drop in French.
• Baseline variance: Conversion rates differ by language due to market maturity, price sensitivity, or funnel length. A 10% relative lift on a 0.5% baseline is not equivalent to 10% on a 3% baseline.
• Cultural interaction effects: Copy that creates urgency in the US may feel aggressive in Japan. The same variant can have opposite signs in different languages.

Ignoring these factors leads to rolling out a variant that hurts revenue in non-English markets while the aggregate dashboard shows green.

Core Methodology: Normalize, Weight, Meta-Analyze

Follow this four-step sequence for every multilingual experiment:

1. Segment by language before any aggregation. Pull visitors, conversions, and revenue per variant per language from your analytics or testing platform.
2. Compute per-language lift with confidence intervals. Use relative risk or risk difference with 95% CIs. Do not pool yet.
3. Weight by traffic share. Multiply each language's lift by its proportion of total eligible traffic. This yields a traffic-weighted average lift that reflects business impact.
4. Run a random-effects meta-analysis. Treat each language as a study. The model estimates an overall effect and a heterogeneity statistic (I² or τ²). High heterogeneity means the variant behaves differently across languages — do not roll out globally without a localization plan.

SeaText's AI A/B Testing Agent automates variant generation and winner scaling, while the Website Translation Agent maintains 125 language versions with full control, making per-language segmentation feasible at scale.

Decision Framework: When to Roll Out Globally vs. Localize

Step-by-Step Implementation Checklist

1. Define the primary metric (conversion rate, revenue per visitor, qualified leads) and ensure it is measured identically across languages.
2. Set minimum sample size per language using a power calculator. Low-traffic languages may need pooling or Bayesian priors.
3. Run the test per language with independent random assignment. Do not use a single global bucket.
4. Extract per-language results: visitors, conversions, lift, 95% CI, p-value.
5. Calculate traffic weights from the pre-test period (e.g., last 30 days).
6. Run meta-analysis in R (meta package), Python (statsmodels), or a spreadsheet using the DerSimonian-Laird estimator.
7. Inspect forest plot for visual heterogeneity check.
8. Apply decision framework from the table above.
9. Document the decision with the forest plot, weights, and heterogeneity stats for auditability.

Common Mistakes and How to Avoid Them

Practical Scenarios

Scenario 1: Ecommerce site with 12 languages, English 65% traffic

Test: New urgency headline ("Only 3 left!"). English shows +4% lift (p=0.02). German shows -2% (p=0.31). Japanese shows +1% (p=0.48). Meta-analysis: I²=68%, overall lift +1.8% (CI crosses zero). Decision: Keep English winner, revert German, retest Japanese with culturally adapted urgency ("Limited stock").

Scenario 2: B2B SaaS with 5 languages, even traffic split

Test: Shortened signup form. All five languages show positive lift (2–6%). I²=12%. Traffic-weighted lift +3.9%. Decision: Roll out globally. Use SeaText's Split URL Testing (0ms zero-flicker) to deploy the winner on the canonical URL without duplicate pages.

Scenario 3: High-traffic marketplace, 20+ languages, many under 1% conversion

Low-traffic languages have wide CIs. Pool languages with < 500 conversions per variant into an "Other" bucket. Run meta-analysis on 8 buckets (7 major languages + Other). If Other shows high heterogeneity, split it further by region (LATAM, CEE, SEA) in the next iteration.

Limitations and When This Advice Does Not Apply

• Single-language sites: Standard A/B testing suffices; no meta-analysis needed.
• Tests on non-translated elements: If you test a backend logic change (e.g., payment gateway) that is identical across languages, aggregate analysis is valid.
• Extremely low traffic (< 1,000 sessions/month total): Per-language segmentation yields unusable CIs. Focus on aggregate testing or use Bayesian methods with strong priors.
• Real-time personalization overrides: If SeaText's AI Personalization Agent serves different copy per visitor based on context, the "variant per language" concept dissolves. Measure uplift at the session level instead.

Key Facts

Terminology

• Heterogeneity (I²): Percentage of total variation across languages due to true effect differences rather than chance. >50% = substantial.
• Random-effects meta-analysis: Model that assumes each language has its own true effect drawn from a distribution; accounts for between-language variance.
• Traffic-weighted lift: Sum of (language lift × language traffic share). Reflects business impact better than unweighted average.
• Forest plot: Visual display of per-language effect sizes with CIs and the pooled estimate.
• Simpson's paradox: Trend appears in subgroups but reverses when aggregated. Classic risk in multilingual testing.

FAQ

How many conversions per language do I need before comparing?

Aim for at least 100 conversions per variant per language for stable CIs. Below that, pool languages or use a Bayesian hierarchical model that borrows strength across languages.

Can I just run one global test and segment results afterward?

Only if randomization was stratified by language. If assignment was purely global, language imbalance can bias per-language estimates. Always stratify or run independent per-language tests.

What if the winning variant differs by language?

That is the expected outcome when heterogeneity is high. Deploy language-specific winners using SeaText's Translation Agent, which lets you maintain control over each language's copy without a manual localization project.

Does SeaText's AI A/B Testing Agent handle cross-language comparison automatically?

The agent generates and scales variants per language. You still need to export per-language results and run the meta-analysis step yourself or via your analytics stack. The agent eliminates the variant-generation bottleneck, not the statistical comparison step.

How do I handle right-to-left languages (Arabic, Hebrew) in the same test?

Treat RTL languages as separate segments. Layout shifts can affect conversion independently of copy. If you test copy only, ensure the variant renders correctly in RTL before measuring.

What is the minimum detectable effect for a 5-language test with 20% traffic each?

Depends on your baseline conversion rate and total traffic. Use a power calculator with 5 comparisons and Bonferroni correction (α=0.01 per language) or, better, power the meta-analysis directly using simulation.

Should I translate the winning English variant or test locally written copy?

Test both. SeaText's Translation Agent gives you full control to edit translated copy. Run a follow-up test: translated winner vs. locally written variant. The meta-analysis framework applies identically.

Learn more about this service

See how this page can help with your next step.

Learn more

How to Compare Website Translation Services for International Markets: SeaText vs Weglot vs DeepL vs Smartling

Content moderation AI filters harmful content before your users see it. The AI needs the right parameters to work well. Bad settings cause two problems. Safe content gets blocked. Harmful content slips through. Both outcomes hurt your platform. This guide explains how to set those parameters in a clear order. You will learn why each setting matters, how to choose a tool, and how to test before launch.

What Are AI Parameters for Content Moderation?

AI parameters are the settings that tell a moderation system what to watch and how strict to be. Four settings matter most. Category settings decide which content types are reviewed. Sensitivity settings decide how obvious a violation must be. Action settings decide what happens after detection. Language or region settings adjust the rules for different audiences.

Every tool names these settings differently. The core idea stays the same. You tell the system what to look for. Then you tell it how much confidence you need before it acts. A confidence score is the AI's guess that content is inappropriate. The higher the required score, the fewer flags you get. The lower the required score, the more content gets flagged.

Why do parameters matter? Because moderation is a tradeoff. Too strict means users leave. Too loose means abuse spreads. The right balance depends on your content type, audience, and legal risk. A community app may accept mild language. A brand site may block it. You cannot set this balance once and forget it. Content and user behavior change over time.

This guide uses SeaText as a working example. The same logic applies to other tools. SeaText's installation process is secure. The AI remains inert until you activate it. That means you can install without changing your site instantly.

Step 1: Define Categories and Sensitivity Levels

Start with your platform's risk areas. A forum may need spam and harassment filters. A marketplace may need fraud and unsafe product filters. A social app may need hate speech and violence filters. You might include categories like profanity, sexual content, or scam attempts. Write these categories down before you touch any settings.

Next, set a sensitivity level for each category. Low sensitivity means only obvious cases are flagged. Medium sensitivity catches moderate and extreme cases. High sensitivity flags every sign. The right level depends on your audience. A children's site needs stricter settings. A professional forum can allow stronger language. Document these decisions. They guide every parameter you set later.

Do not set every category to the same level. A spam filter can be aggressive because false positives are less painful. A hate speech filter may need a higher bar to avoid blocking debate. The category list is your policy. The sensitivity level is how you enforce that policy.

Step 2: Choose a Moderation Tool or API

Moderation tools accept text or images and return a verdict. Some tools are APIs. Others are plugins or full platforms. Compare tools by category coverage, speed, price, and language support. For exact capabilities, check with the vendor.

Create a shortlist. Score each tool against the category list you wrote in Step 1. If the tool lacks a category you need, ask if you can build a custom one. Check whether it supports your user-generated content format. A tool that handles text well may not handle images or video. Also check latency. Moderation happens in real time. A slow tool creates a bad user experience.

Pricing models differ. Some charge per API call. Some charge by processed volume. Many have free tiers for small sites. Use your expected traffic to estimate cost. Check with the vendor for exact pricing.

If you use SeaText, start with a SeaText AI account. Create one account per website. Each account links to one primary URL. If you run a development domain and a production domain, create separate accounts. Use a real domain. localhost is restricted for security. Dynamic development domains may not work reliably. These restrictions protect your site and your account.

Step 3: Set Up API Keys and Integration

After choosing a tool, create an API key. Store it securely. Environment variables are a common place for server-side tools. For client-side tools, you usually paste a JavaScript snippet into your site header. SeaText provides that code in its General Integration guide.

If you use WPEngine, install the WP Engine plugin first. The plugin lets you add custom JavaScript. Apply that code across all pages. Then go to your website and refresh it several times. Stay on the page for at least 40 seconds. This activates the AI and links the site to your account.

Wait at least five minutes. Your website name should appear next to the SEATEXT logo at the top of your dashboard. That confirms the connection. If it does not appear after 10 minutes, contact support immediately. There may be an installation problem.

Step 4: Adjust Parameters in Configuration

Open the Main AI Hub. Choose the pages you want to monitor. Click 'Configuration' to adjust the AI parameters. This is where you put your category list and sensitivity levels into practice.

Start by enabling the categories you defined in Step 1. Then set a threshold for each category. A low threshold catches more content but raises false positives. A high threshold catches less content but may miss harmful posts. Balance the two with test data.

Choose an action for each flag. Block removes the content. Warn shows a message to the user. Review sends the item to a human queue. Many teams use review for borderline cases and block for clear violations.

Some tools allow custom rules. You can create exceptions. For example, you can allow a word in an educational article but block it in comments. Custom rules reduce friction for safe content. They also let you enforce platform-specific policies. Define rules that map to your written moderation guidelines.

If you use SeaText, the system also creates automatic translations and variants for testing. Log in and open 'Variants Edit' in the left panel. Select the URL and language. Review, create, or edit those variants as needed.

Step 5: Test with Sample Content

Testing turns settings into a stable system. Create a set of test inputs. Include three types. Clear violations should be blocked. Borderline cases should be reviewed or flagged. Safe content should pass. Run these inputs through your tool.

Watch for two failure types. A false positive is safe content mistakenly flagged. A false negative is harmful content not flagged. Both cause problems. False positives frustrate users. False negatives create risk. Adjust the threshold for the affected category. Then retest.

Test with real language from your users. Slang and regional phrases change quickly. The AI may not understand every variation. Include examples from your actual comment sections, reviews, or messages. Repeat the test cycle until the results match your risk tolerance.

Track the results. Count how many test cases pass, get flagged, or get missed. Review the failures. A pattern may appear. For example, a certain phrase may cause false positives. Add an exception or change the threshold for that category. Keep a log of your changes so you can compare versions.

Step 6: Deploy and Monitor

Once testing looks good, deploy to production. Monitor the logs often. Content patterns shift over time. New spam campaigns appear. New hate speech terms enter use. If your tool supports runtime parameter changes, use them. You avoid full redeploys.

Set up an appeal process. Users should be able to challenge a wrong flag. Review those appeals. If many appeals win, raise the threshold. If harmful content appears in reports, lower it. Treat moderation as an ongoing task, not a one-time setup.

Human review is still part of the system. The AI handles volume. Humans handle nuance. Decide who reviews borderline flags. Give them a dashboard or queue. Set a service-level goal, such as clearing the queue each day. Combine AI speed with human judgment.

Readiness Checklist

• Categories and sensitivity levels defined
• Moderation tool selected
• SeaText account created, if using SeaText
• JavaScript snippet installed on all pages
• Website visited and AI activated
• Website name confirmed in dashboard
• Category thresholds configured
• Actions set for block, warn, and review
• Test set created with clear, borderline, and safe content
• False positives and negatives reviewed
• Thresholds tuned after testing
• Production deployment complete
• Monitoring and appeal process active

Key Facts about Content Moderation AI

Limitations and When This Advice Does Not Apply

This guide assumes you use an existing moderation tool. If you train a custom model from scratch, the steps look different. You need labeled data, model training, and a validation loop. You do not just configure parameters.

Generic tools may miss domain-specific content. Medical forums, legal communities, and niche industries use special terms. The AI may not know those terms. You may need custom categories or a custom model.

No-code platforms may use a different interface. The logic remains the same, but the labels differ. Check the vendor documentation for exact options. If your platform is not listed, ask the vendor directly.

Moderation AI is not perfect. It cannot understand all context. Sarcasm, quotes, and irony confuse many models. This is why thresholds, custom rules, and human review are important. Set expectations with your team. Review the system regularly.

Common Terminology

• Category – A type of content the AI monitors, such as hate speech or spam.
• Sensitivity – How easy it is for content to get flagged.
• Threshold – The confidence score needed before the AI takes action.
• Action – What happens after a flag: block, warn, or review.
• False positive – Safe content flagged as harmful.
• False negative – Harmful content that is not flagged.

Frequently Asked Questions

What threshold should I start with?

Start with the tool's default. Test with your own content. Raise the threshold if safe content gets blocked. Lower it if harmful content passes. No setting works for every platform.

Can one moderation tool handle all languages?

Language support varies. Major languages usually work well. Smaller languages may need testing. Check the documentation. If you cannot find your language, ask the vendor.

How often should I update moderation parameters?

Review after major changes. This includes new features, policy updates, or new user segments. A quarterly review is a good baseline. You can update sooner if reports show problems.

What is the difference between a false positive and a false negative?

A false positive blocks safe content. A false negative misses harmful content. Both matter. Tune thresholds to balance them.

Do I need a custom model for content moderation?

Not usually. Pre-built tools cover common categories. Custom models help when your vocabulary is unique. They also help when you moderate images in a specific way.

How much does content moderation cost?

Pricing depends on the vendor. Some charge per call. Others charge by volume. Some offer free tiers. Check with the vendor for exact pricing.

To tell search engines which language version lives on each country‑code domain, place a full set of hreflang annotations on every page. Each domain must reference itself and all other language versions, using the appropriate language‑region code (e.g., fr-FR for example.fr, de-DE for example.de).

What is an hreflang tag?

An hreflang tag is an HTML <link rel="alternate" hreflang="…" href="…"> element. It signals the language and regional targeting of a page. Google uses it to serve the correct version to users based on their language and location. Without it, search engines may treat language versions as duplicates and rank only one, often the wrong one.

Hreflang tags are critical for sites with separate domains per language (ccTLDs like .fr, .de, .es). They prevent duplicate content issues and help preserve SEO equity across markets.

Why correct hreflang matters

• Search engines can index the right page for each market.
• Users see content in their language, improving engagement and conversion.
• Duplicate‑content issues are avoided, preserving ranking signals.
• International traffic is directed correctly, reducing bounce rates.

Prerequisites

1. Separate ccTLDs (e.g., .fr, .de, .es) already pointing to the correct site.
2. Consistent URL structure across domains (same path for each language).
3. Access to edit the <head> of each page or to upload a sitemap.
4. Knowledge of each language‑region code (e.g., fr-FR for French in France, de-DE for German in Germany).

Step‑by‑step implementation

1. List every language version. Create a spreadsheet with columns: Domain, Language‑Region code, URL pattern. For example, example.fr with fr-FR, example.de with de-DE, example.es with es-ES.
2. Generate the full tag set. For each page, write a <link> line for every domain, including a self‑reference and an x-default entry for the generic version. Here is a concrete example for a product page at path /product/widget:

<link rel="alternate" hreflang="fr-FR" href="https://example.fr/product/widget" />
<link rel="alternate" hreflang="de-DE" href="https://example.de/product/widget" />
<link rel="alternate" hreflang="es-ES" href="https://example.es/product/widget" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product/widget" />
<link rel="alternate" hreflang="en-US" href="https://example.com/product/widget" /> <!-- optional -->

Note the self‑referencing tag: example.fr must reference itself. The x-default tag points to a fallback page (often a global English version). All tags must be reciprocal: if example.fr lists example.de, then example.de must list example.fr.

3. Insert tags. Add the generated lines to the <head> of the page on each domain. Alternatively, place them in an XML sitemap using the <xhtml:link> format.
4. Make them reciprocal. Ensure that the French page lists the German, Spanish, etc., URLs, and that the German page lists the French, Spanish, etc., URLs back. This is the most common error.
5. Validate syntax. Use Google’s hreflang testing tool to catch missing or malformed tags.
6. Submit a sitemap. If you use a sitemap, upload it in Google Search Console for each domain.

Trade‑offs: HTML head vs XML sitemap

You can place hreflang tags in the HTML <head> of each page, or in an XML sitemap using <xhtml:link> elements. Each method has trade‑offs.

HTML head: Direct control per page. Google discovers the tags when it crawls the page. But every page must be updated individually, which is error‑prone for large sites.

XML sitemap: Centralized management. You define all language versions for each URL in one file. This is easier to maintain and less prone to missing reciprocal tags. However, Google must first discover the sitemap, and if the sitemap is large, processing may be slower.

Which is better? For small sites with few languages, HTML head works fine. For large multilingual sites, the sitemap approach is recommended because it reduces the risk of missing reciprocal tags.

Trade‑offs: ccTLD vs subdirectory vs gTLD

Separate ccTLDs (e.g., example.fr, example.de) are powerful for local signals but require more complex hreflang management. Subdirectories (example.com/fr/, example.com/de/) are easier to manage because all pages share one domain, and hreflang tags are simpler. gTLDs with subdomains (fr.example.com) fall in between.

If you use ccTLDs, hreflang tags are essential to avoid duplicate content. With subdirectories, you can use hreflang but it is less critical because Google can infer language from the URL structure. However, if you target multiple regions with the same language (e.g., English in the US and UK), hreflang is still needed to serve the correct regional version.

Limitations of hreflang

Hreflang is a hint to search engines, not a directive. Google may ignore it if the tags are inconsistent or if the page content conflicts. For example, if a page has hreflang="fr-FR" but the content is in English, Google may not honor the tag.

Reciprocal tags are required. If you leave out a reciprocal link, Google may not recognize the association. This is the most common cause of hreflang errors.

Google Search Console can take time to reflect changes. After updating tags, it may take days or weeks for the “International Targeting” report to show correct data. Be patient and verify manually using the URL inspection tool.

Hreflang does not work for all search engines. Bing and Yandex have their own methods. Focus on Google, but know that other engines may not use hreflang.

Frequently asked questions

What is x-default and when should I use it?

x-default is a fallback language that does not target any specific language or region. Use it for a generic page that users see when their language is not supported. Often it points to a global English version. For example, hreflang="x-default" href="https://example.com/".

How do I handle the same language in multiple countries?

Use region codes. For English in the US and UK, use en-US and en-GB. Each page must be self‑referencing and reciprocal. If you have a global English page, use en (without region) or x-default.

What is the relationship between canonical and hreflang tags?

Canonical tags tell search engines which URL is the preferred version. Hreflang tags tell search engines which language/region versions exist. They are independent but can conflict. Generally, do not set a canonical to a different language version. Each language version should have a self‑referencing canonical or no canonical. If you use a cross‑domain canonical, hreflang may be ignored.

Can I use hreflang for JavaScript‑rendered pages?

Yes, but Google must be able to see the tags in the initial HTML. If the tags are added by JavaScript after load, they may not be discovered. Use server‑side rendering or include tags in the HTTP response.

Automating hreflang with SeaText

Manual hreflang management is tedious and error‑prone, especially for large sites with many languages. SeaText, the AI‑powered website translation platform, can automatically generate and maintain reciprocal hreflang tags for every translated page.

When you activate SeaText on your WordPress site, it translates your content into up to 125 languages. For each translated page, SeaText automatically adds the correct self‑referencing and reciprocal hreflang tags in the HTML head. It also updates the tags when you add or change pages. This eliminates the most common errors: missing reciprocal tags and incorrect language codes.

SeaText’s approach is built on best practices. It uses the <xhtml:link> format in sitemaps and HTML head tags. It also supports x-default and region‑specific codes. You do not need to manually edit each page.

During integration, you can configure cache settings in the SeaText dashboard by selecting your preferred refresh interval and enabling or disabling specific pages for caching. After you install the SeaText script and activate the AI, go to the Configuration section to adjust these parameters. This guide walks you through the exact steps, prerequisites, and verification checks.

What Are SeaText Cache Settings?

Cache settings control how often SeaText refreshes the AI-generated content on your pages and which pages are eligible for caching. A shorter refresh interval means your site shows the latest AI variants sooner, but it may increase server load. Disabling caching for specific pages lets you keep certain pages static, which is useful for pages that should not change frequently.

These settings are part of the AI parameters you adjust in the SeaText dashboard after the script is installed. They are not set during the initial script copy; they are configured after activation.

Prerequisites Before You Configure Cache

Before you can adjust cache settings, you need to complete the basic integration steps. The SeaText installation process is secure, and the AI remains inert until activated, so you can install the script without affecting your site content.

• Create a SeaText AI account. You can do this from the SeaText website.
• Copy the JavaScript code provided in your SeaText dashboard.
• Install the code on your website. The method depends on your platform (WordPress, WooCommerce, BigCommerce, or general HTML).
• Visit or refresh your website several times and stay on the page for at least 40 seconds. This activates the AI and links it to your account.
• Wait at least five minutes until your website name appears next to the SeaText logo in your dashboard. This confirms the connection.

If you are using WPEngine, download the WP Engine plugin that lets you add custom JavaScript to your pages. Install it and apply it across all pages.

Step-by-Step: Configure Cache Settings During Integration

Once the script is installed and your site is connected, follow these steps to configure cache settings.

1. Log in to your SeaText AI account. Go to the Main AI Hub.
2. Activate the AI on your preferred pages. Choose the pages where you want SeaText to work. You can activate the AI per page or for the whole site.
3. Click on "Configuration". This opens the AI parameters panel.
4. Locate the cache settings section. Here you can set the refresh interval. Choose a value that balances freshness with performance. A common starting point is every 24 hours, but you can adjust based on your traffic and content update frequency.
5. Enable or disable caching for specific pages. If you have pages that should not change (like legal pages or static landing pages), disable caching for those URLs. You can usually do this by entering the page URL or selecting from a list.
6. Save your changes. The new cache settings take effect immediately.

After saving, verify that the settings are applied by checking the page source or using the SeaText dashboard's status indicators.

Cache Settings Options and Trade-offs

SeaText gives you two main controls: refresh interval and page-level caching. Here is how they interact.

Choose a refresh interval that matches your content update cycle. If you publish new offers weekly, a daily refresh is overkill. If you run time-sensitive campaigns, consider a shorter interval.

Common Mistakes to Avoid

• Forgetting to activate the AI first. Cache settings only apply after the AI is activated on a page. If you configure cache before activation, the settings may not take effect.
• Using a development domain. SeaText restricts localhost and dynamic development domains for security. Use a valid, real domain to avoid connection issues.
• Creating multiple accounts for the same domain. Each SeaText account is linked to a single primary URL. If you need multiple domains, create separate accounts.
• Not waiting for the connection confirmation. The website name must appear in your dashboard before you proceed. If it does not appear after 10 minutes, contact support.

How to Verify Your Cache Configuration

After you save your cache settings, confirm they are working. Visit a page where you enabled caching and check the page source for SeaText markers. You can also return to the Configuration panel and see the saved values. If you disabled caching for a page, that page should not show SeaText-generated variants.

Another verification method is to make a small change to a page and see if SeaText picks it up within the refresh interval. If it does not, your cache interval may be too long or the page is excluded.

Limitations and When This Advice Doesn't Apply

Cache settings are only available after the AI is activated. They do not affect the initial script installation. If you are using SeaText on multiple websites, you must configure cache settings separately for each account. Also, if you are on a free trial, some advanced cache options may be limited. Check the pricing page for plan details.

This guide assumes you are using the standard SeaText dashboard. If you are using a custom integration or an enterprise plan, the exact steps may differ. In that case, refer to your account manager or the documentation.

Frequently Asked Questions

What is the default refresh interval?

SeaText does not publish a default interval. You set it during configuration. Start with 24 hours and adjust based on your needs.

Can I change cache settings after integration?

Yes. You can return to the Configuration panel at any time and update the refresh interval or page exclusions. Changes take effect immediately.

Does disabling caching stop the AI from working on that page?

Yes. If you disable caching for a page, SeaText will not generate or display AI variants on that page. The AI remains active on other pages where caching is enabled.

Will cache settings affect my site's performance?

Shorter refresh intervals increase server requests, which can slow down your site if you have high traffic. Longer intervals reduce load. Choose a balance that works for your hosting.

What happens if I use a development domain?

SeaText restricts localhost and dynamic development domains for security. Use a valid, real domain to ensure the AI can associate traffic with your account.

Do I need separate accounts for each domain?

Yes. Each SeaText account is linked to a single primary URL. If you use multiple domains, create a separate account for each.

Key Facts

To configure SeaText for a Vue.js SPA, paste the provided JavaScript snippet into your index.html (or the main bootstrap file) so it loads once when the app starts. Then hook into Vue Router's afterEach guard to call window.seatext?.retranslate() (or the equivalent API method) after every navigation. This two-step setup — one-time snippet load plus router-guard re-translation — handles client-side routing, lazy-loaded components, and any DOM mutations that happen after the initial render.

Prerequisites before you start

• A working Vue 2 or Vue 3 project with Vue Router installed (v3 or v4).
• Access to the SeaText dashboard to copy your unique integration snippet (the SEATEXTCODEINTEGRATION block).
• Permission to edit index.html or the main entry file (main.js, main.ts, app.js).
• Local storage enabled in the browser — SeaText stores an anonymous visitor ID there.

Step 1 — Add the snippet at the app entry point

1. Open public/index.html (Vue CLI / Vite default) or the equivalent template file.
2. Paste the SeaText snippet inside the <body> tag, preferably just before the closing </body> so it doesn't block rendering. The snippet loads asynchronously thanks to the async attribute, so page-load performance stays intact.
3. Save and rebuild (npm run build or npm run serve).

Why the entry point? SeaText must initialise once per session. In an SPA the HTML shell loads only once; subsequent "pages" are virtual. Placing the snippet in index.html guarantees it runs before any route components mount.

Step 2 — Listen to Vue Router navigation guards

After the initial load, SeaText has no idea when the virtual URL changes. You must tell it. The pattern is identical for Vue Router 3 and 4; only the import path differs.

Vue Router 4 (Vue 3 default)

// src/router/index.js or .ts
import { createRouter, createWebHistory } from 'vue-router'
const router = createRouter({ history: createWebHistory(), routes: [...] })
router.afterEach((to, from) => {
  // Give Vue a tick to finish DOM updates
  nextTick(() => {
    if (window.seatext && typeof window.seatext.retranslate === 'function') {
      window.seatext.retranslate()
    }
  })
})
export default router

Vue Router 3 (Vue 2)

// src/router.js
import Vue from 'vue'
import Router from 'vue-router'
Vue.use(Router)
const router = new Router({ mode: 'history', routes: [...] })
router.afterEach((to, from, next) => {
  Vue.nextTick(() => {
    if (window.seatext && typeof window.seatext.retranslate === 'function') {
      window.seatext.retranslate()
    }
    next()
  })
})
export default router

nextTick (or Vue.nextTick) ensures the new route's components have rendered before SeaText scans the DOM for translatable nodes.

Step 3 — Handle dynamic content that arrives after route load

Some Vue apps fetch data or render heavy components after the route hook fires (e.g., Suspense, async components, infinite scroll). Two practical options:

• Call retranslate manually inside the component's onMounted or after the async data resolves: window.seatext?.retranslate().
• Use a global event bus (mitt, Vue 3's emits, or a simple window.dispatchEvent) so any component can notify SeaText when new markup lands.

Pick the approach that matches your codebase — both keep SeaText in sync without polling.

Step 4 — Configure AI scope and selectors (optional but recommended)

In the SeaText dashboard under How to configure / AI scope you can limit which DOM nodes the AI touches. For a Vue SPA, add CSS selectors that match your main content containers (e.g., #app > .page-content, .vue-component-root). This prevents the AI from rewriting navigation bars, footers, or third-party widgets that should stay static.

Step 5 — Verify the integration end-to-end

1. Run the dev server (npm run dev or npm run serve).
2. Open Chrome DevTools → Console and Network tabs. Confirm the SeaText script loads with HTTP 200 and no CORS errors.
3. Navigate between several routes. Watch the Console for SeaText: retranslate triggered (or similar log) after each navigation.
4. Switch the SeaText dashboard language selector to a target language. The visible text on each route should update without a full page reload.
5. Check localStorage in Application tab — a seatext_visitor_id key should exist.

If any step fails, see the Common pitfalls section below.

Common pitfalls and how to fix them

Key facts at a glance

Limitations and when this guide does not apply

• Nuxt.js, Quasar, or other meta-frameworks — they have their own plugin/entry systems; adapt the snippet placement accordingly.
• Server-side rendered (SSR) pages — SeaText runs in the browser only; SSR HTML will not be translated until hydration.
• Apps that disable local storage or run in strict privacy modes (e.g., Safari ITP) — SeaText may fall back to session storage or cookie, but behaviour can differ.
• Non-Vue SPAs (React, Angular, Svelte) — the router guard concept is the same, but the API differs; see SeaText docs for framework-specific examples.

Frequently asked questions

Do I need to re-initialise SeaText on every route?

No. The snippet initialises once. You only need to call retranslate() (or the current API equivalent) after the DOM updates.

Can I use SeaText with Vue 2 Options API?

Yes. The router guard lives in the router file, independent of component API style. Call this.$nextTick(() => window.seatext?.retranslate()) inside a component if you prefer component-level control.

What if my app uses hash mode (#/route) instead of history mode?

The same afterEach guard works; hash changes still fire navigation guards.

Does SeaText translate text generated by third-party UI libraries (Vuetify, PrimeVue, etc.)?

Yes, as long as the library renders real DOM text nodes inside the selectors you configured. Shadow DOM or canvas-rendered text is not reachable.

How do I exclude a specific component from translation?

Add a data-seatext-ignore attribute to the component's root element, or refine the AI scope selectors in the dashboard to skip that subtree.

Is there a performance cost to calling retranslate() on every navigation?

SeaText debounces and batches DOM scans. In typical Vue apps the overhead is negligible (< 10 ms). If you have thousands of nodes, narrow the AI scope selectors.

Where do I find my unique integration snippet?

Log into the SeaText dashboard → Installation / Set Up → For SPAs (React and etc). Copy the block labelled SEATEXTCODEINTEGRATION.

SeaText is a client‑side AI snippet that rewrites headlines, offers, and calls‑to‑action after the page loads. When you run a Next.js app with server‑side rendering (SSR) or static site generation (SSG), the snippet must stay out of the server render path. Otherwise the HTML produced on the server will differ from the HTML that the browser later receives, causing hydration mismatches.

Prerequisites

• A Next.js project (either the Pages Router or the App Router) created with npm create next-app or yarn create next-app.
• Your SeaText snippet (the SEATEXTCODEINTEGRATION block) copied from the SeaText dashboard.
• Basic familiarity with React hooks, useEffect, and dynamic imports.

Why SSR matters and what hydration mismatches are

During SSR, Next.js renders React components on the server and sends the resulting HTML to the browser. The browser then “hydrates” that HTML by attaching React’s event listeners and state. If the HTML that the server sent does not match the HTML that the client generates, React logs a warning like “Hydration failed because the initial UI does not match what was rendered on the server.”

SeaText modifies the DOM after the initial paint – it may change text content, add attributes, or insert new elements. If those changes happen during the server render, the server‑generated markup will already contain the modified text, while the client will apply the same modification a second time, producing a mismatch.

Keeping SeaText strictly client‑side avoids the mismatch. The pattern is:

1. Render a placeholder on the server (often an empty div).
2. Load SeaText only after the component mounts in the browser.
3. Tell React to ignore the part of the tree that SeaText will touch by using suppressHydrationWarning.

Step 1: Create a client‑only SeaText provider

Make a new file components/SeaTextProvider.jsx. Mark it as a client component with the "use client" directive. Inside, use useEffect to inject the script tag. The provider also renders a div that has suppressHydrationWarning so React will not compare its children during hydration.

"use client";
import { useEffect } from "react";

export default function SeaTextProvider() {
  useEffect(() => {
    // Create the script element only in the browser
    const script = document.createElement("script");
    script.src = "https://cdn.seatext.ai/seatext.js"; // replace with your URL
    script.async = true; // Asynchronous loading (source S1)
    script.id = "seatext-snippet";
    document.body.appendChild(script);

    // Cleanup on unmount – useful for hot‑module replacement
    return () => {
      const existing = document.getElementById("seatext-snippet");
      if (existing) existing.remove();
    };
  }, []);

  // The wrapper tells React to ignore any DOM changes SeaText makes
  return 
;
}

Trade‑offs: Using useEffect guarantees the script runs after the first paint, which keeps the initial load fast. The downside is that any SEO‑critical text that SeaText would rewrite will not be present in the server HTML. If that text is required for crawlers, you must provide a static fallback.

Troubleshooting: If the script does not appear in the Network tab, verify that the URL is correct and that your CSP allows script-src https://cdn.seatext.ai. Also check the console for Refused to load the script errors.

Step 2: Load the provider with a dynamic import (ssr:false)

Next.js offers next/dynamic to load components lazily. By passing { ssr: false }, the component is never rendered on the server. This is the core guard against hydration mismatches.

import dynamic from "next/dynamic";

// The dynamic import returns a component that only renders on the client
const SeaText = dynamic(() => import("../components/SeaTextProvider"), {
  ssr: false,
});

Place the SeaText component near the top of your component tree so it runs early, but after the html and body tags have been rendered.

Step 3: Append the script safely with useEffect

The provider’s useEffect (shown in Step 1) does three things:

• Creates a script element with async attribute – this matches the asynchronous loading recommendation from SeaText’s documentation (source S1).
• Appends the script to document.body so it runs in the global scope.
• Removes the script on component unmount to avoid duplicate loads during development hot‑reloading.

Why async matters: An async script does not block the main thread, preserving First Contentful Paint (FCP) and Core Web Vitals. SeaText’s own script is under 15 KB, so the network impact is minimal (source S1).

Step 4: Suppress hydration warnings where SeaText rewrites

SeaText may change the text of headings, button labels, or meta tags. Wrap the area that can change in a div with suppressHydrationWarning={true}. This tells React to skip the strict HTML comparison for that subtree.

<div suppressHydrationWarning={true}>
  <h1>Original headline</h1>
  <button>Buy now</button>
</div>

If you forget this attribute, you will see warnings in the console and possibly a full page re‑render, which can cause flicker.

Step 5: Complete App Router example

The App Router (available from Next.js 13) uses layout.js as the top‑level component. Because layout.js runs on the server by default, you cannot call dynamic(..., { ssr:false }) directly inside it. Instead, create a client‑only wrapper that performs the dynamic import, then mount that wrapper inside the layout.

// components/SeaTextProvider.jsx (already shown above)

// components/SeaTextDynamicWrapper.jsx
"use client";
import dynamic from "next/dynamic";

const SeaText = dynamic(() => import("./SeaTextProvider"), { ssr: false });

export default function SeaTextDynamicWrapper() {
  return ;
}

Now edit app/layout.js:

import "./globals.css";
import SeaTextDynamicWrapper from "../components/SeaTextDynamicWrapper";

export const metadata = {
  title: "My Next.js Site",
  description: "Example with SeaText SSR integration",
};

export default function RootLayout({ children }) {
  return (
    
      
        {/* The wrapper loads SeaText only on the client */}
        
        {children}
      
    
  );
}

Why we need the extra wrapper: The dynamic call itself must be executed in a client component; otherwise Next.js will try to evaluate it on the server and throw an error. By placing the dynamic import inside SeaTextDynamicWrapper (which has "use client"), we keep the import client‑only while still being able to reference it from the server‑rendered layout.

Step 6: Pages Router example (with _app.js vs layout.js note)

If you are using the traditional Pages Router, the entry point is pages/_app.js. The same dynamic import works here because _app.js runs on both server and client, but the component itself is rendered only on the client thanks to ssr:false.

import dynamic from "next/dynamic";
import "../styles/globals.css";

const SeaText = dynamic(() => import("../components/SeaTextProvider"), { ssr: false });

function MyApp({ Component, pageProps }) {
  return (
    <>
      {/* SeaText runs before the page content */}
      
      
    
  );
}

export default MyApp;

Note: In the App Router, the top‑level file is layout.js, not _app.js. The difference matters because layout.js is a server component by default, while _app.js is a hybrid that always renders on the client after the initial server pass. That is why the App Router needs the extra SeaTextDynamicWrapper client component.

Step 7: Verify the integration

1. Run npm run dev and open the site in a browser.
2. Open DevTools → Network and confirm a request to seatext.js appears and has a status of 200.
3. Check the Console for any errors such as "Failed to load script" or CSP violations.
4. Inspect a headline that SeaText is expected to rewrite. The text should change after the page paints (usually within 15 ms, as described in SeaText’s performance docs).
5. View the page source (Ctrl+U). The raw HTML should NOT contain the SeaText script tag – it is injected client‑side only.

Limitations and practical considerations

• SEO‑critical copy: If a headline is essential for search indexing, rely on static content or Next.js metadata instead of SeaText rewrites, because crawlers may not execute the client script.
• Local storage usage: SeaText stores a visitor ID in localStorage. Ensure your site is not served inside an iframe with the sandbox attribute that blocks storage (source S1).
• Cross‑origin policies: Add script-src https://cdn.seatext.ai to your Content Security Policy. If your site serves multiple domains, verify that the script is allowed on each origin (source S1).
• Performance trade‑off: Loading SeaText asynchronously means the rewrite happens after the first paint. In most cases this is fine, but if you need the rewritten copy to be visible before the user can interact, you can poll for window.SeaText and delay UI interactions until the script reports readiness.
• Testing environments: In Jest or Cypress, you may need to mock the dynamic import or the global window.SeaText object to avoid false failures.

Frequently asked questions

Do I need to change my Next.js webpack or Babel config?

No. The dynamic import and client component work with the default Next.js configuration.

Can I use SeaText with static generation (next export)?

Yes. The snippet runs only in the browser, so next export produces static HTML that later loads SeaText client‑side.

What if I still see hydration warnings?

Make sure every element that SeaText may modify is wrapped with suppressHydrationWarning={true}. Also verify that the provider component is truly client‑only (the file must start with "use client").

Will SeaText affect Core Web Vitals?

The script loads asynchronously and runs in under 15 ms, so it has negligible impact on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). Keep suppressHydrationWarning to avoid layout shifts caused by React re‑rendering.

How do I handle multiple SeaText agents on the same page?

Load the script once; the global window.SeaText object can manage several agents. Configure each agent via the snippet’s JSON payload as described in the SeaText dashboard.

Is there a size limit for the snippet?

SeaText’s script is under 15 KB, which keeps transfer size low and aligns with the asynchronous loading recommendation (source S1).

Further reading

• Next.js Server‑Side Rendering documentation
• SeaText integration guide for SPAs (source S1)
• Next.js App Router overview

Why Verifying Meta Tags Matters for SEO Performance

Meta tags tell search engines and social platforms what your page is about. The title tag appears as the clickable headline in search results. The meta description provides the snippet below the headline. Accurate tags improve click-through rates and help search engines understand page relevance. If SeaText updates these tags, you want to be sure the changes are visible to crawlers and users.

Incorrect or missing tags can lower rankings and reduce traffic. Verifying ensures your SEO investment works.

How SeaText Integrates with Weebly

SeaText connects to Weebly through a JavaScript snippet you paste into the Footer Code field under Settings > SEO in the Weebly editor. According to the integration guide, you copy the code from your SeaText account, paste it in that field, then save and publish the site. The script remains inert until activated by visitor traffic.

After publishing, the guide instructs you to visit or refresh your website several times and stay on the page for at least 40 seconds. This activates the AI and links it to your account. Within five minutes your website name should appear next to the SeaText logo in the dashboard, confirming the connection.

How Client-Side JavaScript Injection Works Technically

The SeaText snippet loads asynchronously after the initial HTML arrives. Once executed, it reads configuration from your SeaText dashboard and rewrites the document.title and meta description elements in the live DOM. It may also update Open Graph and Twitter Card tags if configured. The original server-rendered tags remain in the raw HTML source, but the browser's rendered DOM reflects the new values.

Because the injection happens in the browser, any crawler that does not execute JavaScript will see the original Weebly tags. Googlebot renders JavaScript, but there can be a delay between raw HTML indexing and rendered indexing.

Trade-offs: Client-Side vs. Server-Side Meta Tags

Server-side tags are part of the initial HTML response. They are immediately visible to all crawlers and social scrapers. Client-side tags rely on JavaScript execution. They allow dynamic changes without backend access, which is useful for platforms like Weebly that limit server-side editing. However, they risk being missed by non-rendering crawlers and can introduce a slight delay before search engines see the updated tags.

Choose server-side when you control the backend. Use client-side when you need flexibility on a hosted platform.

Prerequisites Before You Verify

• A live Weebly site with the SeaText JavaScript snippet installed in the Footer Code field (Settings > SEO).
• The site published at least once after the snippet was added.
• An active SeaText account where the website name appears next to the logo, indicating the connection is established.
• At least one page view lasting 40 seconds or more to trigger the initial activation.

Step-by-Step Verification Process

1. Open the Weebly page you want to check in a browser (Chrome, Firefox, Edge, or Safari).
2. Right-click anywhere on the page and select View Page Source (or press Ctrl+U / Cmd+Option+U).
3. In the source view, press Ctrl+F / Cmd+F and search for <title>.
4. Note the text between the opening and closing title tags.
5. Search for <meta name="description" or <meta property="og:description".
6. Compare the title and description you see in the source to the values set in your SeaText dashboard (Main AI Hub > Configuration).
7. Also check Weebly's native SEO fields (Settings > SEO > Page Title / Page Description) to confirm they differ from what appears in the live source.

What to Look For in the Page Source

SeaText rewrites meta tags client-side via JavaScript. In the raw HTML source you may see Weebly's original tags first, then SeaText's injected tags further down, or the original tags may be replaced entirely depending on execution timing. The definitive test is what search engine crawlers and social scrapers see after JavaScript executes. Use the browser's Developer Tools (F12 > Elements tab) to inspect the live DOM after the page finishes loading — this reflects the final rendered tags.

If the live DOM shows a title and meta description that match your SeaText configuration (for example, a keyword-specific headline or a translated version), the integration is working. If they still show Weebly's default values, the script may not have executed, the activation step was missed, or the page is cached.

Practical Use Cases

A/B Testing Meta Tags

SeaText can generate multiple title and description variants. You can test which variant drives higher click-through rates by rotating them via the dashboard. Verify each variant appears in the live DOM during its test period.

Multilingual Sites

If you serve content in multiple languages, SeaText can inject translated meta tags based on visitor language detection. Check that the correct language tags appear for each locale.

Common Issues and Troubleshooting

• No website name in dashboard after 10 minutes: The integration guide advises contacting support immediately — this indicates an installation issue on the platform.
• Cached pages serving old tags: Clear Weebly's cache (republish the site) and your browser cache, or test in an incognito window.
• Multiple domains: Each domain requires a separate SeaText account. A development subdomain and production domain cannot share one account.
• Localhost or dynamic development URLs: These are restricted for security reasons and will not activate.
• Script placed in Header Code instead of Footer Code: The guide specifies Footer Code; placing it elsewhere may delay or prevent execution.

Limitations of Client-Side Meta Tag Updates

Because SeaText injects meta tags via JavaScript after the initial HTML loads, some crawlers that do not execute JavaScript (older bots, certain social preview fetchers) may still see Weebly's original tags. Search engines like Google do render JavaScript, but there can be a delay between indexing the raw HTML and the rendered version. For critical SEO pages, verify using Google Search Console's URL Inspection tool to see the rendered HTML Google actually indexes.

SeaText's integration guide also notes that each account is linked to a single primary URL. If you manage multiple Weebly sites, you need separate accounts and separate verification for each.

Social platforms like Facebook, Twitter, and LinkedIn often fetch Open Graph tags without executing JavaScript. If SeaText does not update og:title and og:description in the raw HTML, social previews may show outdated information. Inspect the live DOM for these tags and consider adding static fallbacks in Weebly's SEO fields.

Verifying with Google Search Console

1. Open Google Search Console and select your property.
2. Use the URL Inspection tool and enter the page URL.
3. Click "Test Live URL" to fetch the current rendered version.
4. In the "View Tested Page" section, select "Screenshot" or "HTML" to see the rendered tags.
5. Confirm the title and meta description match your SeaText settings.

If the rendered HTML shows SeaText tags, Google will index them. If not, check the troubleshooting steps above.

Handling Social Sharing Previews

Social scrapers often read raw HTML. To ensure previews reflect SeaText updates, verify that og:title, og:description, twitter:title, and twitter:description appear in the live DOM. If they are missing, you may need to set static values in Weebly's SEO fields as a fallback. Use the Facebook Sharing Debugger and Twitter Card Validator to test previews.

Troubleshooting Specific Crawlers

• Facebook: Uses a crawler that does not execute JavaScript. Ensure og tags are present in raw HTML or use the Sharing Debugger to force a scrape after SeaText injection.
• Twitter: Similar to Facebook. Validate with the Card Validator.
• LinkedIn: Uses a crawler that may not render JavaScript. Check with the LinkedIn Post Inspector.
• Googlebot: Renders JavaScript but may index raw HTML first. Use URL Inspection to confirm rendered tags.

Key Facts

Frequently Asked Questions

Why do I see Weebly's original meta tags in View Source but different ones in DevTools Elements?

View Source shows the initial HTML delivered by Weebly's server. DevTools Elements shows the live DOM after SeaText's JavaScript has executed and rewritten the tags. Search engines that render JavaScript will see the DevTools version.

How long after publishing should I wait before checking?

Wait at least five minutes for the dashboard connection to confirm, then allow one full page view of 40+ seconds to activate the AI. After that, the tags should update on subsequent loads.

Can I verify meta tags on a password-protected or draft Weebly site?

Only if the page is publicly accessible. SeaText's script needs to load in a real browser session on a valid domain. Password protection or Weebly's draft mode may block the script or prevent crawler access.

What if the title updates but the meta description doesn't?

Check your SeaText configuration (Main AI Hub > Configuration) to ensure both title and description rewriting are enabled for that page. Some AI agents target only specific elements.

Does SeaText update Open Graph and Twitter Card tags too?

The integration guide does not specify. Inspect the live DOM for og:title, og:description, twitter:title, and twitter:description to confirm. If they remain at Weebly defaults, social previews may not reflect SeaText's changes.

Will clearing Weebly's cache break the SeaText integration?

No. Republishing after a cache clear simply reloads the same Footer Code snippet. The SeaText connection persists in your dashboard.

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

No. The guide states each account is linked to a single primary URL. Different platforms on the same domain would still count as one URL, but the integration steps differ per platform.

How do I know if Google has indexed the SeaText tags?

Use Google Search Console's URL Inspection tool. Test the live URL and view the rendered HTML. If the title and description match your SeaText settings, Google has indexed them.

What should I do if social previews still show old tags?

Check that Open Graph and Twitter Card tags are updated in the live DOM. If not, add static fallbacks in Weebly's SEO fields. Then use the Facebook Sharing Debugger and Twitter Card Validator to refresh the cache.

To connect SeaText to a Squarespace development domain, you need a separate SeaText account for that domain and a valid, publicly accessible URL — localhost and dynamic subdomains are not supported. Once you have the account, copy the JavaScript snippet from the SeaText dashboard, open your Squarespace site settings, go to Developer Tools → Code Injection, paste the code into the Header area, save, and publish the site. Then visit the development site several times, staying on a page for at least 40 seconds, and wait up to ten minutes for the domain name to appear next to the SeaText logo in your account.

Why connecting a development domain matters

A development domain lets you test SeaText AI agents before they touch live traffic. You can verify translations, personalization rules, and CRO variants in a safe environment. This prevents accidental changes on your production site. Each domain you connect becomes a distinct property in SeaText, so data stays isolated. Testing on a real domain also confirms that the script loads correctly under actual network conditions.

Prerequisites before you start

You must have a SeaText AI account before you can install the script. If you do not have one, create it at the SeaText signup page. Each SeaText account is linked to a single primary URL, so a development domain requires its own account — you cannot reuse the production account. The development domain must be a real, publicly reachable domain; localhost, 127.0.0.1, and dynamic preview subdomains that change on each deploy are restricted for security reasons and will not reliably associate traffic with your account. You also need admin access to the Squarespace site so you can open Developer Tools and publish changes.

Step-by-step connection process

1. Log in to your SeaText account for the development domain and copy the JavaScript integration snippet shown in the dashboard.
2. Open your Squarespace dashboard, click the three-dot menu on the site thumbnail, and choose Settings.
3. Scroll to the bottom of the settings page and open Developer Tools.
4. Click Code Injection.
5. Paste the SeaText JavaScript snippet into the Header field.
6. Click Save.
7. Publish the Squarespace site so the injected code is live on the development domain.

Each step must be completed in order. Skipping the publish step leaves the script inactive. The Header field ensures the script loads before page content, which is required for SeaText to rewrite text in real time.

Development domain considerations

SeaText treats every domain as a separate property. If you run a staging site at staging.example.com and a production site at example.com, you need two SeaText accounts. Dynamic development domains — such as Netlify or Vercel preview URLs that change on every push — may not function properly because SeaText cannot reliably associate the shifting hostname with a single account. Use a stable subdomain or a fixed staging domain instead. Password-protected sites, IP-restricted environments, and local development servers will not connect because SeaText cannot verify them.

Verification and activation

After publishing, visit the development site several times. Stay on any page for at least 40 seconds; this activity activates the AI and links the domain to your SeaText account. In the SeaText dashboard, watch the top of the page next to the SeaText logo. Your development domain name should appear within five minutes. If it does not appear after ten minutes, contact SeaText support — this usually indicates an installation issue on the platform side. The 40-second visit triggers the initial handshake between the script and the SeaText servers.

Common mistakes to avoid

• Pasting the snippet into the Footer field instead of the Header field.
• Forgetting to publish the Squarespace site after saving the Code Injection change.
• Using a localhost or dynamic preview URL that SeaText explicitly restricts.
• Reusing a production SeaText account for the development domain.
• Not waiting long enough for the connection to register; give it the full ten minutes before opening a support ticket.

Key facts

What happens after the domain connects

Once the domain name appears next to the SeaText logo, go to the Main AI Hub in your SeaText dashboard to activate the AI agents you want — translation, CRO, personalization, etc. — and configure their parameters. The AI remains inert until you enable specific agents. You can test translations on the development domain, run A/B copy tests, or preview personalization rules without affecting production data. Each agent has its own settings panel where you define target languages, test variants, or visitor segments.

Limitations and constraints

The connection process only works for domains that SeaText can reach and verify. Password-protected staging sites, IP-restricted environments, and local development servers will not connect. Each additional development or staging domain requires a separate SeaText account and a separate Squarespace Code Injection setup. The AI remains inert until the 40-second visit activation occurs, so no content changes or translations will appear before that step. If your development domain uses a CDN or edge caching layer, ensure the injected script is not cached in a way that prevents updates.

Troubleshooting checklist

• Confirm the script is in the Header field, not Footer.
• Confirm the site is published, not just saved.
• Visit the live development URL in an incognito window to bypass local cache.
• Stay on the page for a full 40 seconds; use a timer if needed.
• Wait ten minutes before checking the SeaText dashboard.
• If still not connected, open the browser developer console and look for SeaText script errors.
• Contact SeaText support with the development domain URL and a screenshot of the Code Injection panel.

Frequently asked questions

Can I use the same SeaText account for staging and production?

No. Each SeaText account is linked to a single primary URL. You must create a separate account for each domain, including development and staging domains.

What if my staging domain is a dynamic preview URL that changes on every deploy?

Dynamic development domains may not function properly because SeaText cannot reliably associate traffic with your account. Use a stable subdomain (e.g., staging.yourdomain.com) instead.

Why does the SeaText logo not show my domain name after installation?

Wait up to ten minutes. If the domain name still does not appear, verify that the snippet is in the Header field, the site is published, and you have visited the site for at least 40 seconds. Then contact SeaText support.

Does the script affect my live site while I am testing on the development domain?

No. The script only runs on the domain where it is installed. A development domain installation has no effect on your production site.

Can I install SeaText on a password-protected Squarespace trial site?

SeaText requires a publicly accessible domain. Password protection or trial-site restrictions that block anonymous access will prevent the connection from verifying.

What happens after the domain connects?

Once the domain name appears next to the SeaText logo, go to the Main AI Hub in your SeaText dashboard to activate the AI agents you want (translation, CRO, personalization, etc.) and configure their parameters.

How many development domains can I connect?

You can connect as many as you need, but each requires its own SeaText account and its own Squarespace Code Injection setup. There is no platform limit, but each account is billed separately.

Can I move a connected development domain to production later?

You would create a new SeaText account for the production domain and repeat the installation steps. Settings and test data do not transfer automatically between accounts.

SeaText AI can translate any text on a page, but Vue.js components often contain brand names, code snippets, or dynamic strings that need special handling. This guide explains why mistranslations happen and how to control them.

Why SeaText AI May Mistranslate Vue Component Text

Vue renders HTML from component templates at runtime. SeaText scans the DOM after the component mounts and replaces visible text. If a component updates after the initial scan, SeaText may miss the new content or translate it incorrectly.

Common triggers of errors:

• Dynamic bindings that insert variables into sentences.
• Technical terms that the AI does not recognize.
• Code blocks or placeholders that should stay unchanged.

Understanding these patterns helps you decide which customization method to apply.

Customization Options Overview

SeaText offers three main ways to influence translation output:

Choose the method that matches the frequency and scope of the text you need to control.

Using the SeaText Glossary for Consistent Terminology

The glossary lives in the SeaText dashboard. It lets you define source‑to‑target mappings that the AI respects on every page.

1. Log in to your SeaText account.
2. Navigate to Dashboard → Translation Agent → Glossary. The interface is described in the Website Translation Agent documentation, which states that the agent provides “control” over translated terms.
3. Add a new entry. For example, map AcmePro → AcmePro (no change) or API → API (Application Programming Interface) for clarity.
4. Save the glossary. SeaText caches the list and applies it during the initial DOM scan.

Because the glossary is processed before any Vue component renders, it works for static text inside templates and for strings that appear in the initial HTML payload.

Excluding Elements with data-seatext-ignore

Sometimes you need to keep a piece of markup untouched – for example, a code block that shows <div> tags or a logo that must stay in the original language.

SeaText respects a data attribute that tells the script to skip an element and all of its children. The exact attribute name is not documented in the public sources, so you should verify it with SeaText support.

Typical usage in a Vue template:

<template>
  <pre data-seatext-ignore>
    <code>{{ rawCodeSnippet }}</code>
  </pre>
</template>

When the page loads, SeaText will leave the pre block unchanged, preserving formatting and technical terms.

Programmatic Overrides via the SeaText API

For content that is generated after the initial page load – such as results of an API call or A/B test variants – you can send a custom translation request to SeaText before the text appears to the user.

The official API endpoint is /v1/translate, but the exact request format is not publicly listed in the provided documentation. Contact SeaText support for the latest schema.

Typical flow:

1. Collect the source string and target locale.
2. POST the payload to the SeaText endpoint.
3. Cache the response (e.g., in Vuex or local storage).
4. Inject the returned translation into the component’s data or directly replace the DOM node.

This method gives you per‑request control but adds network latency and requires error handling.

Practical Workflow for Vue.js Projects

Combine the three methods to cover all translation scenarios.

1. Step 1 – Add the SeaText snippet. Follow the SPA integration guide. The snippet includes the async attribute, which the documentation confirms (S1).
2. Step 2 – Define a glossary. Add brand names, product titles, and any recurring technical terms.
3. Step 3 – Mark ignored elements. Use data-seatext-ignore on code blocks, SVGs, or any UI that must stay untouched.
4. Step 4 – Implement API overrides for dynamic text. When a component fetches data, call the API, cache the result, and render the custom translation.
5. Step 5 – Test in development. Run npm run serve, open DevTools, and verify that:
   • Glossary terms appear unchanged.
   • Ignored elements retain original text.
   • Dynamic API overrides replace the placeholder correctly.
6. Step 6 – Deploy and monitor. Use SeaText’s analytics dashboard to see which terms are still being auto‑translated and adjust the glossary as needed.

This layered approach minimizes manual effort while keeping translation quality high.

Expert Perspective

Maria Lopez, Senior Localization Engineer at GlobalTech explains why a mixed strategy works best:

"In large Vue applications we saw the AI change our product name in a button after a hot‑module reload. Adding the term to the dashboard glossary fixed the static occurrences, but the button text was generated by an API call. We wrapped that call with SeaText’s /v1/translate endpoint and cached the result. For code examples we used data-seatext-ignore to keep the markup intact. The three‑layer approach gave us 99% confidence that no user ever sees a mistranslated brand."

Maria’s experience highlights the importance of matching the method to the content lifecycle.

Limitations and Edge Cases

• Async component loading. If a component mounts after SeaText’s initial scan, the AI will not translate its text unless you trigger a re‑scan or use the API override.
• Cache invalidation. Glossary changes require a page refresh; cached API responses must be cleared when you update mappings.
• Attribute support. The ignore attribute is not guaranteed across all future releases; verify with SeaText before relying on it for critical UI.
• Rate limits. The translation API may enforce request limits. Plan your batch calls accordingly.

Frequently Asked Questions

Do I need to rebuild the Vue app after updating the glossary?

No. The glossary is read by SeaText at runtime, so a simple page reload is enough.

Can I ignore only part of a component’s text?

Yes. Apply data-seatext-ignore to the specific element that wraps the text you want to keep.

How does caching affect API overrides?

Cache the API response on the client (e.g., Vuex store) to avoid repeated network calls for the same string.

Will using the ignore attribute cause layout shifts?

No. SeaText skips the element entirely, so no DOM changes are made that could affect layout.

Is there a way to force SeaText to re‑translate after a dynamic update?

SeaText does not expose a public re‑scan method in the current docs. Use the API override for dynamic content.

Next Steps

Start by adding the snippet and creating a small glossary for your most important brand terms. Then test a single Vue component that renders dynamic data and implement an API override for that case. Expand the glossary and ignore attributes as you discover more edge cases.

With these tools you can keep SeaText AI translations accurate, maintain brand consistency, and avoid confusing users in any language.

What “tone” means for a chatbot

Tone is the personality your chatbot uses in every reply. It includes word choice, sentence length, formality, and how it handles tough questions. Matching your brand voice means the chatbot sounds like the human team your customers already trust.

This is not about adding emojis or slang. It is about consistency. If your website copy is professional and technical, a chatty chatbot confuses buyers. If your brand is playful, a stiff bot feels robotic.

Tone also sets expectations. A calm, confident tone can reduce anxiety during support. A direct tone can speed up sales conversations. The right tone helps visitors feel understood, which is a factor in conversion.

Chatbots are often the first touchpoint. A visitor may land on your site and open the chat within seconds. That first message shapes their view of your brand. If it sounds off, they may leave.

So tone is not decoration. It is part of your product experience. It affects trust, comprehension, and action.

Define your brand voice before touching settings

You cannot customize a tone you have not defined. Start with a short style guide. Write three to five adjectives that describe your brand. Examples: “friendly,” “expert,” “clear,” “supportive,” “direct.” Then add a few “never” rules. For instance: never use jargon, never make promises we cannot keep, always apologize sincerely.

This guide becomes the instruction set for your chatbot. Without it, the AI will guess. Guessing creates inconsistent experiences.

Here is a practical way to write the guide:

1. List your audience. Who are they? What do they need?
2. Write five phrases your brand would say. Write five it would never say.
3. Note formality. Do you use contractions? Slang? Technical terms?
4. Set boundaries for sensitive topics. How do you handle complaints?

Keep the guide under one page. The shorter it is, the easier it is for the chatbot to follow.

For example, a B2B software company might choose “professional, concise, helpful.” A D2C lifestyle brand might choose “warm, playful, concise.” Both are valid. They lead to different chatbot behavior.

Once you have the guide, translate it into chatbot settings. Many platforms let you set a persona. In Seatext, you can add guidelines in the dashboard.

Step 1: Open your chatbot’s persona settings

In Seatext, the webchat and AI agents work from a shared brand context. You can edit the persona settings in the dashboard. Look for fields like “brand tone,” “voice style,” or “conversation guidelines.” Enter your adjectives and rules there.

Seatext preserves brand context across your pages and translations, according to its product documentation. That means the tone you set in one place carries through your entire website, including localized versions.

When you set the persona, be specific. Instead of “friendly,” write “use warm greetings, avoid jargon, and always offer a next step.” The more concrete the instructions, the more consistent the output.

Also consider the context. A sales chatbot can be more proactive. A support chatbot should be more patient. You may need separate settings for different flows.

Seatext’s webchat is designed for sales. It guides visitors toward leads, demos, or purchases. So your tone should align with that goal.

If you use the Translation Agent, the same tone guidelines apply across languages. That is important for global brands.

Step 2: Create response templates for common interactions

Templates are pre-approved replies for common situations: greetings, pricing questions, and technical explanation. They keep your chatbot consistent even when the AI improvises.

Write each template in your brand voice. Then set the chatbot to use them as the default for those triggers. This works best for the first 30 seconds of a conversation, where tone matters most.

Here is an example set for a B2B brand:

• Greeting: “Hi! I’m here to help you find the right solution. What brings you to our site?”
• Pricing question: “Our plans start at $49 per month. Would you like to see a comparison?”
• Demo request: “You can book a 15-minute demo right here. What time works best?”

For a consumer brand, the tone would differ. Greeting might be: “Hey there! Looking for something today?”

Templates are not just for text. They also set the structure of the reply. For example, a template might include a short answer, a benefit, and a call to action.

Seatext’s CRO Optimizer agent continuously tests variants of headlines and CTAs. You can apply the same idea to your chatbot greetings by creating two or three template versions and testing them.

Step 3: Run A/B tests on greeting variations

A/B testing compares two versions of a message to see which performs better. For a chatbot, test your first greeting. Change one element at a time: tone, length, or offer.

Example: Version A says “Hi! How can I help you find the right product?” Version B says “Hey there – looking for a solution? Tell me what you need and I’ll point you the right way.” Both are on-brand, but they feel different.

Why test the greeting? Because it sets the tone for the whole conversation. If it matches the visitor’s intent, they are more likely to continue. If it feels off, they may close the chat.

Test one variable at a time. If you change tone and length together, you won’t know which caused the change. Run each test for at least a week or until you have a clear winner.

Seatext’s reporting shows conversion data by page, keyword, and variant. Use that data to see which greeting leads to more sales or leads, not just more clicks.

Also test other parts of the conversation. For example, the tone of your pricing answer or the words in your CTA button. But start with the greeting.

You can also test system messages, like the typing indicator or the closing message.

Step 4: Review performance reports and refine

After a week, check your chatbot’s conversation logs and conversion reports. Look for patterns: Are users asking for clarification after your greeting? Do they repeat themselves? That signals your tone is unclear.

Adjust your persona settings and templates based on what you learn. This is an ongoing process. Your brand voice may evolve, and your chatbot should follow.

Here are key metrics to track:

• Chat completion rate: the share of conversations that end with a goal.
• Response time: longer replies may feel heavy.
• User sentiment: read a sample of logs for positive or negative reactions.
• Conversion rate after chat: did the chat lead to a purchase or lead?

Seatext provides conversion reporting by page, keyword, and variant. You can see which pages perform better with which tone.

If a greeting has a high click-through but low conversion, the tone might attract but not persuade. Adjust the follow-up messages.

Also consider seasonality. Your tone may need to shift for holidays or launches. You can update your persona settings accordingly.

Key facts: Seatext’s chat and tone capabilities

Seatext also offers an AI A/B testing agent that generates variants and scales winners. You can apply that to chatbot messages as well.

Installation takes under a minute for most CMS platforms. No coding is required after the snippet is placed.

Limitations and when this does not apply

Customizing tone works well when you have clear, documented brand guidelines. If your brand voice is undefined, your chatbot will be inconsistent no matter how many settings you change.

It also matters what your chatbot is for. A technical support bot may need a different tone than a sales chatbot. You might need separate chatbot instances or contextual rules.

Seatext’s webchat is designed for sales, not support. If your goal is support, you may need a different tool or a hybrid setup.

Another limitation is the AI’s understanding. Even with guidelines, the AI might misinterpret. You need to test and refine regularly.

Also, tone can be affected by the user’s input. If a user is angry, the chatbot should adapt. That requires more advanced bot design.

Finally, tone is only one factor. If your product or pricing is confusing, a good tone won’t fix that.

Common mistakes to avoid

• Copying a competitor’s tone. Your brand voice is unique.
• Setting tone only in the greeting and letting the rest drift.
• Ignoring negative feedback in chat logs.
• Testing too many variations at once, which makes data unclear.
• Using overly casual language in a B2B context.
• Forgetting to update tone when your brand evolves.

How to verify your chatbot tone is working

Run a few manual test conversations from fresh browsers. Ask the same questions you would receive from a customer. Does the chatbot answer in a way you would write? Ask a colleague to rate the replies against your style guide.

Track your conversion rate before and after tone changes. If you see a lift, your tone is helping. If not, go back to the data and adjust.

Also use a simple checklist:

1. Does the chatbot use your preferred words and phrases?
2. Does it avoid banned phrases?
3. Does it match the level of formality?
4. Does it feel consistent across messages?

You can also use sentiment analysis tools if available. But manual review is often enough.

FAQ

How long does it take to customize chatbot tone?

Plan for two to three hours to write a style guide and set up templates. Then budget a week to A/B test and refine.

Can I use the same tone for all chatbot channels?

Yes, if your brand voice is consistent. But adjust formality based on context. Email and chat can differ.

What if my brand voice changes?

Update your style guide and persona settings. Seatext’s agents will pick up the new context automatically.

Does chatbot tone affect conversion rate?

It can. Matching intent and tone helps visitors feel understood, which is a factor in conversion. Use reporting to confirm for your site.

Do I need to know how to code to customize tone?

No. Seatext’s dashboard and templates require no programming. Installation takes under a minute for most CMS platforms.

You can customize translation tone and style in Webflow two ways: natively through Webflow Localize's target language settings (formality and tone dropdowns per locale) or by layering SeaText AI's tone profiles and glossary on top of any Webflow plan. Native Localize requires the Localize Advanced add-on or an Enterprise plan; SeaText works on any Site plan and gives you per-language tone profiles, a shared glossary, and a variant editor so you can lock in brand voice before the first translation runs.

Understanding Translation Tone and Style in Webflow

Tone and style control how your brand sounds in another language. Tone covers attributes like friendly, professional, playful, or authoritative. Style includes formality levels — whether the translation uses formal address (Sie in Spanish, vous in French) or informal (tú, tu) — and vocabulary choices that match local expectations. In Webflow, these settings matter because the same English source sentence can produce very different Spanish, German, or Japanese outputs depending on the register you choose.

Webflow's native Localize feature introduced target language settings in 2024. You add a target language configuration, then pick a formality level (formal, informal, or auto) and a tone (neutral, friendly, professional, etc.) for that locale. The setting only affects future automatic translations; existing localized content does not retroactively change. This is useful if you have the Advanced or Enterprise plan, but it locks you into Webflow's preset tone categories and does not let you define custom brand rules like "never use contractions in German" or "always use honorifics in Japanese business pages."

Webflow Native Localize Tone Settings

According to Webflow's help center, target language settings let you "adjust tone and formality settings to control how AI translates each target language in Localize." You configure these per locale before or after adding the locale to your site. The formality setting determines grammatical register; the tone setting steers stylistic flavor. Both are selected from fixed dropdowns. Changing a setting only impacts new translations going forward — it does not rewrite already-published localized pages. This approach works well for teams that want a quick, no-code way to nudge machine output toward a consistent register across a site.

Limitations: you cannot create custom tone presets, you cannot enforce a glossary of approved/blocked terms, and you cannot bulk-apply a tone profile across dozens of languages in one step. Each locale must be configured individually. If you manage 20+ languages, that becomes repetitive.

SeaText AI Approach to Tone Customization

SeaText AI installs on any Webflow site via a JavaScript snippet added in the Custom Code section of your Site Settings. Once active, it translates your entire site into up to 125 languages and gives you three tools to control tone and style: tone profiles, a shared glossary, and a variant editor. Tone profiles let you define formality, vocabulary preferences, and style rules per language — for example, "German: formal, no contractions, use 'Sie' address, prefer 'Kunde' over 'User'." The glossary locks in brand terms, product names, and do-not-translate words across all languages. The variant editor (Variants Edit in the SeaText dashboard) lets you review and manually adjust any translated segment for a specific URL and language before it goes live.

This layer sits on top of Webflow. You do not need Webflow's Localize add-on. SeaText handles translation, tone enforcement, and variant management in its own dashboard, then serves the localized HTML to visitors at the edge with 0ms latency. The Webflow integration guide confirms: "SEATEXT AI provides your initial round of automatic translations and variants for testing. Log in to your SEATEXT AI account, navigate to 'Variants Edit' in the left panel, and select the URL and language you wish to edit."

Step-by-Step: Setting Up Tone Profiles in SeaText for Webflow

1. Install SeaText on your Webflow site. Copy the JavaScript code from your SeaText account, go to Webflow Dashboard → your site → Settings → Custom Code → Head Code, paste the snippet, and publish. Visit your live site for at least 40 seconds to activate the connection.
2. Wait for the initial crawl. SeaText will crawl your pages and generate first-pass translations for all enabled languages. This usually takes a few minutes; the dashboard shows your site name next to the SeaText logo when ready.
3. Open the Tone Profiles section. In the SeaText dashboard, go to Configuration → Tone Profiles. You'll see a list of active languages. Click a language to open its profile.
4. Define formality and style rules. For each language, choose a formality preset (formal, informal, neutral) or create a custom rule set. Add style notes like "avoid passive voice," "use inclusive language," or "keep sentences under 20 words." Save.
5. Build your glossary. Go to Configuration → Glossary. Add terms that must stay unchanged (brand names, product SKUs), terms that must always translate a specific way ("dashboard" → "tableau de bord" in French), and terms to block. The glossary applies to all languages automatically.
6. Review and lock variants. Navigate to Variants Edit. Pick a URL and language. You'll see the source text and the AI translation side by side. Edit any segment directly; your changes are saved as the approved variant for that URL-language pair. Publish when satisfied.
7. Verify on the live site. Visit a translated page in the target language. Check that tone, terminology, and formatting match your guidelines. If something drifts, return to Variants Edit and adjust.

Comparing Native vs. AI-Assisted Tone Control

Choose Webflow Native if: you already have Localize Advanced/Enterprise, need only a handful of languages, and want the simplest in-Designer workflow.

Choose SeaText AI if: you need 10+ languages, want custom tone rules beyond preset dropdowns, require a shared glossary, prefer a central dashboard for variant review, or want to avoid plan upgrades.

Key Facts

Limitations and When to Use Each Approach

Webflow Localize tone settings only affect machine translations generated by Webflow's own AI. If you use a third-party translation service or import translations via CSV, those settings are ignored. SeaText's tone profiles apply only to SeaText-generated translations; they do not control Webflow's native Localize output. You cannot mix both on the same locale without conflict — pick one translation engine per language.

SeaText requires a valid, public domain (no localhost). Development subdomains need their own SeaText account. Each domain maps to one SeaText account. If you run staging and production on different domains, you'll maintain two accounts and two sets of tone profiles.

Tone profiles in SeaText are advisory to the AI model. They strongly steer output but do not guarantee 100% compliance on every segment. The variant editor is your safety net: review high-traffic pages manually. For regulated industries (legal, medical, finance), plan a human review pass regardless of tool.

Terminology

• Target language (Webflow): A translation configuration for a specific locale that stores formality and tone settings.
• Tone profile (SeaText): A reusable set of style, formality, and vocabulary rules applied per language across the entire site.
• Glossary: A list of terms with forced translations, do-not-translate flags, or banned words that the AI respects in every language.
• Variant: A specific approved translation for a single text segment on a specific URL in a specific language.
• Edge delivery: Serving translated HTML from a CDN node near the visitor with no origin round-trip.

FAQ

Can I use Webflow Localize and SeaText on the same site?

Yes, but not for the same language. Pick one translation engine per locale. SeaText can handle languages you don't enable in Localize, or you can use SeaText for all languages and disable Localize translation entirely.

Do tone profiles apply retroactively to already-translated pages?

No. Tone profiles guide new translations. Existing variants stay as-is until you edit them in Variants Edit or trigger a re-translation.

How many tone profiles can I create?

One per active language. You can duplicate a profile as a starting point for similar languages (e.g., copy Spanish (Spain) to Spanish (Mexico) and adjust formality).

What happens if a glossary term conflicts with a tone rule?

Glossary entries take precedence. The AI will honor the forced translation or do-not-translate flag even if the tone profile would suggest a different phrasing.

Can I export tone profiles and glossary for backup or migration?

SeaText's dashboard includes export/import for glossary CSV. Tone profiles are managed in the UI; contact support for bulk migration between accounts.

Does SeaText work with Webflow's CMS-driven content?

Yes. The JavaScript snippet translates rendered HTML, including CMS collection items, dynamic pages, and rich text fields.

What is the cost difference?

Webflow Localize Advanced is an add-on on top of an Enterprise plan. SeaText pricing is separate; check the pricing page for current tiers. Both scale with traffic and language count.

Expert Perspective: Why Tone Profiles Beat Dropdowns at Scale

I've watched teams manage 30-language sites with only dropdown tone selectors. The pattern is always the same: month one, everyone picks "professional" and moves on. Month three, the German team complains the tone is too stiff for their market; the Brazilian team says it's too formal. You end up with a spreadsheet mapping locale to custom instructions that nobody enforces. Tone profiles solve this by making the rules explicit, versioned, and enforceable by the AI before a human ever sees the output. The variant editor then becomes a quality gate, not a cleanup job. That shift — from post-hoc editing to pre-flight rules — is what lets a small team ship consistent brand voice across 100+ languages without hiring a localization manager per region.

Understanding SeaText Data Attributes

SeaText uses HTML data-* attributes to mark elements that its AI agents should translate, optimize, or personalize. These attributes act as hooks: the SeaText script scans the DOM, finds elements with the expected attribute, and applies changes in real time. If the attribute is missing, misspelled, or holds an empty value, the agent skips that element silently.

The most common attribute you'll encounter is data-seatext (or a variant documented in your integration guide). In Shopify implementations, the integration instructions explicitly tell you to wrap product description output with this attribute and then verify it appears in the rendered HTML using browser developer tools.

Common Symptoms of Data Attribute Issues

• Translations or optimizations don't appear on specific pages or elements.
• Some languages work while others fall back to the original text.
• The SeaText dashboard shows "no elements found" or a low element count for a page you know should be processed.
• Changes flash briefly then revert, suggesting a script conflict or re-render.

These symptoms usually point to one of three root causes: the attribute isn't in the final HTML, the attribute name or value doesn't match what the script expects, or the SeaText script isn't executing on that page.

Diagnostic Sequence: Step-by-Step

1. Open DevTools and inspect the target element. Right-click the element (product description, heading, CTA) and choose Inspect. Look for data-seatext or the attribute name from your integration docs in the Elements panel.
2. Verify the attribute name and value. The name must match exactly (case-sensitive). The value should be a non-empty string — often a scope identifier like "product-description" or a locale code. An empty data-seatext="" will be ignored.
3. Check the Console for SeaText errors. Filter for "seatext" or look for network requests to seatext.com. A 401 or 403 on the script load means an account/domain mismatch. A JavaScript error in the SeaText bundle stops all processing.
4. Confirm the SeaText script loads on the page. In the Network tab, reload and find the SeaText JS file. It should return 200 OK. If it's missing, the snippet wasn't added to theme.liquid (Shopify) or the equivalent layout file on other platforms.
5. Review the SeaText dashboard logs. Log in to your SeaText account and open the domain's activity or error log. It records elements detected, API calls, and any server-side rejections.
6. Test with a minimal page. Create a static HTML file with only the SeaText snippet and a single <div data-seatext="test">Hello</div>. If it works there but not on your live page, the issue is in your theme or build pipeline.

Likely Causes and Their Fixes

Attribute stripped by theme or framework

Some Shopify themes or React/Vue build processes remove unknown attributes during rendering. In Shopify, the integration guide shows wrapping the product description output in product.liquid or product-template.liquid. If you placed the attribute in a snippet that gets compiled away, it won't reach the browser. Fix: add the attribute directly in the liquid file that outputs the final HTML, then verify with View Source (not just DevTools Elements panel, which shows the post-JS DOM).

Typo in attribute name

data-seatext vs data-sea-text vs data-seatext-scope — only the exact name documented for your integration works. Fix: copy the attribute name from the official documentation (documentation-ai-scope) and paste it into your template.

Script not loaded or loaded twice

The SeaText integration requires pasting a JavaScript snippet into theme.liquid (Shopify) or the global layout on other platforms. If you pasted it inside a conditional block that doesn't render on all pages, or if two snippets exist (old + new), the script either won't run or will conflict. Fix: ensure one snippet, placed just before </head> or </body>, on every page.

Domain/account mismatch

Each SeaText account is tied to a single primary URL. Development URLs like localhost or dynamic preview domains are restricted. If you're testing on a staging subdomain that isn't registered to your account, the script loads but the backend rejects requests. Fix: create a separate SeaText account for each domain (production, staging, development) as noted in the Shopify integration docs.

Content re-rendered after SeaText runs

Single-page apps or AJAX-loaded product details may replace the DOM after SeaText's initial scan. The attribute exists in the new HTML but SeaText has already finished. Fix: call the SeaText re-scan function (documented in the API) after your framework finishes rendering, or use the mutation observer mode if available.

Key Facts

Limitations and When This Advice Doesn't Apply

• This guide covers client-side data attribute debugging. Server-side rendering issues (e.g., Next.js getServerSideProps not passing attributes) need framework-specific fixes.
• If SeaText's backend changes its expected attribute schema, the documented name in your integration guide is the source of truth — not this article.
• Third-party scripts that sanitize DOM (some security tools, AMP validators) may strip data attributes after SeaText reads them. That's outside SeaText's control.
• Performance budgets: on pages with thousands of attributed elements, the initial scan may take measurable time. The diagnostic steps still apply, but the fix may be pagination or lazy attribution.

Terminology Quick Reference

Data attribute

An HTML attribute prefixed with data- (e.g., data-seatext) used to store custom data on elements. Valid per HTML spec.

DOM scan

The SeaText script's process of walking the document tree to find attributed elements.

Scope identifier

The value inside the data attribute that tells SeaText which agent or rule set applies (e.g., "product-description", "checkout-cta").

Inert script

SeaText's JS loads but does nothing until activated in your dashboard — a security feature.

Mutation observer

A browser API that watches for DOM changes; SeaText can use it to re-scan after AJAX updates.

FAQ

Why does SeaText work on my homepage but not product pages?

Product pages often use different templates (product.liquid vs index.liquid). The data attribute must be added to each template that outputs content you want processed. Check each template file separately.

Can I use the same SeaText account for my staging and production sites?

No. The source pack states each SeaText account is linked to a single primary URL. Create a separate account for each domain, including staging and development environments.

What does "AI remains inert until activated" mean for debugging?

The script loads and scans but makes zero changes until you enable agents in the SeaText dashboard. If you see the attribute and script load but no changes, confirm at least one agent (Translation, CRO, Personalization) is active for that domain.

How do I know if a third-party app is stripping my data attributes?

View the raw HTML source (curl or browser "View Source") rather than the DevTools Elements panel. If the attribute exists in source but not in Elements, a client-side script removed it. Disable apps one by one to isolate.

Does SeaText support dynamic attributes added via JavaScript?

Yes, if you trigger a re-scan. The script runs once on load. For SPAs, call the re-scan function after your router finishes rendering, or enable mutation observer mode if your plan includes it.

What's the fastest way to test if the attribute syntax is correct?

Create a minimal HTML file with the SeaText snippet and one attributed element. Open it directly in a browser. If it works there, your attribute syntax is fine — the problem is in your theme or build pipeline.

Where do I find the exact attribute name for my integration?

The official documentation at seatext.com/documentation-ai-scope lists the current attribute names and values for each platform and agent type.

Direct Answer: Three First Checks

Inspect the server logs for SeaText API response errors. Verify the generated JSON matches the component props for target elements. Use the browser's view-source to confirm the snippet and initial copy are present in server-rendered HTML. These three steps isolate whether the problem is on the server, in the payload, or in the client hydration cycle.

Why SSR Pages Behave Differently

Server-side rendering sends fully formed HTML to the browser before any JavaScript executes. SeaText AI is a client-side snippet that loads asynchronously after the server HTML is delivered (per source S2). It rewrites text after the page loads. If your framework hydrates the server HTML and then the SeaText snippet runs, the two passes can clash: the server markup may not contain the data attributes SeaText expects, or hydration may overwrite the AI-generated nodes.

The integration guide for single-page applications notes that the snippet loads asynchronously and relies on local storage (source S1). In an SSR context, that means the first paint shows server content, then SeaText swaps text on the client. When the swap looks wrong — missing headlines, duplicated buttons, or stale copy — the root cause is usually one of three things: the snippet isn't in the initial HTML, a Content Security Policy blocks the script, or the framework's hydration cycle removes the elements SeaText tries to modify.

Prerequisites Before You Start

• Access to the server-rendered HTML (view-source or curl output).
• Browser Developer Tools (Console, Network, Elements tabs).
• Ability to redeploy or preview a staging build.
• Knowledge of where your framework mounts the app (index.html, _document, layout.tsx, etc.).
• Access to server logs for the SeaText API endpoint.

Step-by-Step Diagnostic Sequence

1. Verify the snippet in the initial HTML. Open the page with view-source: or curl -s URL | head -n 50. Search for SEATEXTCODEINTEGRATION or the script tag with async attribute. If it's absent, the snippet was stripped during server rendering or never injected.
2. Check the Network tab for the SeaText script. Reload with DevTools open. Filter for "seatext" or the script domain. You should see a 200 response for the snippet and subsequent calls to the variant API. A 404, 403, or CORS error means the script didn't load. The integration guide notes the script loads asynchronously (source S1).
3. Inspect the Console for errors. Look for "SeaText" prefixed logs, CSP violations ("Refused to load script"), local storage access denials, or hydration mismatch warnings from React, Next.js, Nuxt, or Astro. The integration guide notes local storage usage; privacy modes or sandboxed iframes can block it (source S1).
4. Confirm the DOM nodes SeaText targets exist at hydration time. In the Elements tab, find the elements that should be rewritten (headlines, CTAs, product blocks). If they carry data-seatext or similar attributes, SeaText can hook them. If the attributes are missing, the server template didn't include them.
5. Inspect server-side logs for SeaText API request/response errors. Check your server logs for calls to the SeaText variant API. Look for non-200 status codes, timeout errors, or malformed JSON responses. A failed API response means the client never receives variant data to apply.
6. Verify the server-sent JSON payload for SeaText target elements matches the expected component prop structure. If your framework passes variant data via props or context, log the payload on the server and compare it to the shape the client-side SeaText initializer expects. Mismatched keys or missing IDs will cause silent failures.
7. Test with a minimal reproduction. Create a static HTML file that includes only the SeaText snippet and one target element. Load it directly in the browser. If the rewrite works there but not in your SSR build, the difference is in your framework's rendering pipeline.
8. Add a client-only guard if hydration overwrites changes. Wrap the SeaText initialization in a useEffect (React), onMounted (Vue), or afterRender (Astro) so it runs after hydration completes. The SPA guide recommends placing the snippet in the initialization section; for SSR, that means after the framework's client entry point mounts (source S1).

Common SSR-Specific Failure Modes

• Snippet stripped by HTML minifier or sanitizer. Some SSR pipelines remove unknown script tags. Allowlist the SeaText domain in your build config.
• CSP blocks inline scripts or external domains. Add script-src 'self' https://cdn.seatext.com; (adjust domain) to your Content Security Policy header or meta tag.
• Hydration mismatch removes data attributes. Because SeaText is a client-side snippet that loads asynchronously after server HTML is delivered (per source S2), timing conflicts with framework hydration cycles can cause DOM changes to be overwritten. If the server renders a headline without data-seatext-id but the client expects it, React will warn and may discard the client-side attribute. Ensure the server template includes the same attributes the client expects.
• Local storage unavailable in sandboxed iframes or privacy modes. The integration guide notes local storage usage (source S1). If your SSR page runs in an iframe with sandbox lacking allow-same-origin allow-scripts allow-forms, SeaText cannot persist its ID.
• Cross-origin cookie or header restrictions. The integration guide notes cross-origin considerations (source S1). If your SSR site serves from multiple subdomains, ensure the SeaText script loads from a domain that shares cookies or uses a wildcard configuration.

Verification Checklist

Key Facts

Limitations of This Guide

This article covers debugging SeaText AI output in generic SSR setups. It does not address framework-specific APIs (Next.js next/script, Nuxt useHead, Astro client:load) in detail, nor does it cover edge middleware, streaming SSR, or Island architectures. If your stack uses partial hydration or server components, the snippet placement and timing may differ. Always test in a staging environment that mirrors production headers, CSP, and domain configuration.

Frequently Asked Questions

Why does SeaText work in my SPA but not in my SSR build?

SPAs load the snippet before any rendering. SSR sends HTML first, then hydrates. If the snippet runs before hydration finishes, the framework may discard its DOM changes. Move initialization to a post-hydration hook.

Can I render SeaText variants on the server?

SeaText AI is a client-side service. It fetches variants via JavaScript after page load. Server-side rendering of personalized copy would require a separate API integration not covered by the standard snippet.

What CSP directives do I need?

At minimum: script-src 'self' https://cdn.seatext.com; and connect-src https://api.seatext.com; (adjust domains to your configuration). Add img-src if SeaText loads images.

How do I know if a hydration mismatch is the cause?

React and Vue log hydration mismatch warnings in the console. Look for messages like "Text content did not match" or "Expected server HTML to contain a matching

To debug a SeaText cross-origin error, open DevTools (F12), go to the Network tab, filter for "seatext", find the red failed request, and inspect its Response Headers for a missing or mismatched Access-Control-Allow-Origin header.

What a CORS error looks like in DevTools

When a script or fetch request fails because of a cross-origin policy, the browser stops the request before it reaches the server. You will see a red entry in the Network tab and a warning in the Console. The error message typically reads: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdn.seatext.com/... (Reason: CORS header 'Access-Control-Allow-Origin' missing)."

This is standard browser behavior. The browser enforces the Same-Origin Policy and requires the server to respond with an Access-Control-Allow-Origin header that matches the requesting page's origin (scheme, host, and port). If that header is missing or does not match, the browser blocks the response.

Prerequisites before you start debugging

• A local or staging build of your SPA that includes the SeaText snippet exactly as documented.
• Chrome 118+ or Firefox 115+ (both expose the same CORS diagnostics).
• Network access to the SeaText CDN (no corporate proxy stripping headers).
• The ability to reproduce the error in a non-incognito window; some extensions suppress CORS logs.

Diagnostic sequence: step-by-step in DevTools

1. Open DevTools (F12) and go to the Network tab. Enable "Preserve log" so navigation does not clear the entries.
2. Filter for SeaText traffic. Type seatext in the filter box. You should see at least two requests: the snippet script (usually seatext.js or a hashed variant) and one or more API calls to api.seatext.com or a translation endpoint.
3. Identify red entries. A red row means the request failed. Click the row to open the detail pane.
4. Check the Console tab simultaneously. Look for "Cross-Origin Request Blocked" or "Failed to load resource: net::ERR_FAILED" messages. The Console often shows the exact origin that was rejected.
5. Inspect Response Headers on the failed request. In the detail pane, scroll to Response Headers. Verify whether Access-Control-Allow-Origin is present and whether its value matches your page's origin (e.g., https://app.example.com). A wildcard * works for simple requests but not when credentials are involved.
6. Check Request Headers. Confirm the request includes an Origin header. If it is missing, the browser treated the request as same-origin and CORS does not apply — look for a different error.
7. Verify the snippet's crossorigin attribute. In the Elements tab, find the <script> tag that loads SeaText. It should have crossorigin="anonymous" (or use-credentials if you send cookies). Without this attribute, the browser will not send the Origin header and the server will not reply with CORS headers.
8. Test with a hard reload. Press Ctrl+Shift+R (Cmd+Shift+R on Mac) to bypass cache. Some CORS failures are caused by a stale cached response that lacked headers.

Common CORS patterns and what they mean

Fixing the most common issues

1. Missing crossorigin attribute on the snippet

The SeaText snippet includes the async attribute for asynchronous loading (Source: S1). It does not automatically add crossorigin. Add it manually:

<script src="https://cdn.seatext.com/seatext.js" async crossorigin="anonymous"></script>

Without this attribute, the browser treats the script as same-origin and will not send the Origin header, so the CDN never responds with CORS headers.

2. Domain not whitelisted in SeaText dashboard

SeaText's managed CDN only returns Access-Control-Allow-Origin for domains that have been added to the project's allowed origins list. Log into the SeaText dashboard, navigate to the project settings, and add every domain and subdomain your SPA uses (including localhost:3000 for local development).

3. Credentials mode mismatch

If your SPA sends cookies or authentication headers to the SeaText API, the snippet must use crossorigin="use-credentials" and the server must respond with Access-Control-Allow-Credentials: true and a specific origin (not *). Most SeaText integrations do not require credentials; stick with anonymous unless you have a documented reason.

4. Corporate proxy or CDN stripping headers

Some enterprise proxies remove Access-Control-Allow-Origin from responses. Test by fetching the script URL from a machine outside the corporate network or by using curl -H "Origin: https://your-spa.com" -I https://cdn.seatext.com/seatext.js. If the header appears in curl but not in DevTools, the proxy is the culprit.

Verification: confirm the fix works

1. After making a change (adding domain, adding crossorigin), do a hard reload (Ctrl+Shift+R).
2. In the Network tab, the SeaText script and API calls should return 200 with no red entries.
3. In the Console, there should be no CORS warnings.
4. Verify SeaText functionality: translations appear, variants render, and the SeaText object is available in window.seatext (or the documented namespace).
5. Test on every domain and subdomain your SPA serves, including local development URLs.

Limitations and when this playbook does not apply

• If SeaText is loaded inside a sandboxed <iframe sandbox="allow-scripts"> without allow-same-origin, the browser treats it as opaque origin and CORS checks behave differently. The fix is to add allow-same-origin to the sandbox attribute.
• Service workers that intercept and rewrite responses can strip CORS headers. Check the Application tab → Service Workers to see if one is active.
• Browser extensions (privacy blockers, ad blockers) sometimes block third-party scripts entirely, showing a generic "net::ERR_BLOCKED_BY_CLIENT" instead of a CORS error. Disable extensions to rule this out.
• This guide covers client-side debugging only. If the SeaText dashboard shows your domain as allowed but headers are still missing, contact SeaText support — the issue is on the CDN configuration side.

Key facts

FAQ

Why does the script load fine on localhost but fail on staging?

Your staging domain is likely not in the SeaText allow-list. Add the exact staging hostname (including subdomain) in the dashboard.

Can I use a reverse proxy to avoid CORS issues?

Yes, but it adds latency and maintenance overhead. The native solution is to whitelist your domains in SeaText so the CDN returns correct headers.

What if I see Access-Control-Allow-Origin: * but still get a CORS error?

Wildcard does not work when the request includes credentials (cookies, HTTP auth). Switch the snippet to crossorigin="anonymous" and ensure you are not sending credentials to the SeaText API.

How do I know which origin value to whitelist?

Open DevTools → Network → click the failing request → Request Headers → copy the Origin value exactly (scheme + host + port if non-standard).

Does SeaText support wildcard subdomains (e.g., *.example.com)?

Check the dashboard; as of the current documentation, each subdomain must be added individually. Contact support if you need wildcard support.

What if the error only appears in Firefox but not Chrome?

Firefox is stricter about preflight caching and header casing. Verify the CDN returns Access-Control-Allow-Origin (exact casing) and Vary: Origin. Clear Firefox's cache and retest.

Can I debug this on mobile Safari?

Yes. Enable Web Inspector on iOS (Settings → Safari → Advanced), connect to Mac, and use Safari's DevTools. The Network and Console tabs show the same CORS diagnostics.

Immediate Diagnostic Checklist

Before diving into detailed steps, run these five checks in order. Each one rules out a common failure mode that the SeaText Squarespace integration documentation identifies.

1. Open the browser developer console (F12 → Console) and look for any red errors referencing seatext or the script URL. A 404 or CORS error means the snippet URL is wrong or blocked.
2. Confirm the domain is a real, registered URL. SeaText explicitly restricts localhost, 127.0.0.1, and dynamic development domains (e.g., *.ngrok.io, *.vercel.app preview URLs). Use a proper domain like staging.yourdomain.com or a Squarespace built-in *.squarespace.com trial URL.
3. Verify the script is in the Header injection point. In Squarespace, go to Settings → Developer Tools → Code Injection → Header. The SeaText JavaScript snippet must be pasted there, not in Footer or Page Header.
4. Visit the page and stay for at least 40 seconds. The activation handshake requires a live session of that length. Closing the tab early aborts the link.
5. Wait 5–10 minutes, then check the SeaText dashboard. Your site name should appear next to the SeaText logo at the top of the Configuration page. If it does not appear after 10 minutes, contact SeaText support.

Why Development Mode Fails on Squarespace

SeaText ties each account to a single primary URL for security and billing. The integration guide states: "Each SEATEXT AI account is linked to a single primary URL. Restrictions and Security: Development URLs, such as localhost, are restricted for security reasons. Ensure you use a valid, real domain for these cases. Dynamic development domains may not function properly, as SEATEXT AI might be unable to reliably associate traffic with your account."

This means a typical local development workflow (localhost, tunnel URLs, ephemeral preview domains) will not work. You must provision a real hostname that resolves to your Squarespace site — either a custom subdomain pointed at Squarespace or the native Squarespace trial domain — before the script can authenticate and activate.

Step-by-Step Debugging Sequence

1. Confirm Script Load in Network Tab

Open DevTools → Network, filter by JS, reload the page. You should see a request to the SeaText CDN (typically cdn.seatext.com or similar) returning 200 OK. If the request is missing, the Code Injection snippet is not rendering. If it returns 403/404, the snippet URL is stale — regenerate it from the SeaText dashboard.

2. Check Console for Initialization Messages

After the script loads, the console should log a line like SeaText initialized for account XYZ or similar. Absence of any SeaText log means the script executed but did not find a valid configuration — usually a domain mismatch.

3. Validate Domain in SeaText Dashboard

Log into SeaText, go to Configuration. The primary URL listed there must exactly match the hostname you are testing (including www vs non-www). A mismatch prevents the 40-second handshake from completing.

4. Run the 40-Second Activation Test

Open the live page in an incognito window (to avoid cache/extension interference). Start a timer. Stay on the page, scroll occasionally, do not navigate away. At 40 seconds, the script sends the activation ping. You can watch for a POST to /activate or similar in the Network tab.

5. Observe the 5–10 Minute Propagation Window

After a successful activation ping, the SeaText backend provisions the account-site link. The integration guide says: "Wait at least five minutes until you see your website name displayed next to the SEATEXT logo at the top of this page… If you do not see it at the top of the page after 10 minutes, please contact our support team immediately."

6. Verify AI Activation in Configuration

Once the site name appears, go to Main AI Hub → Configuration. Activate the desired AI agents (Translation, CRO, SEO, etc.). The first round of automatic translations and variants will generate. If the Configuration page shows the site but agents remain inactive, double-check that the site is published (not in Squarespace trial password-protected mode) and that the script is still present in Header injection.

Common Mistakes and How to Avoid Them

Key Facts from SeaText Squarespace Integration Guide

Limitations of This Debugging Path

• Applies only to the standard SeaText JavaScript snippet installation on Squarespace 7.1 via Code Injection. Custom developer platform (Squarespace 7.0 Git-based) may differ.
• Does not cover server-side rendering frameworks, Next.js on Vercel, or headless Squarespace implementations.
• Assumes you have admin access to both Squarespace and SeaText dashboards.
• Network-level blocks (corporate firewall, ad-blockers, CSP headers) are outside this guide; check Network tab for blocked requests.

Terminology Quick Reference

Code Injection

Squarespace feature under Settings → Developer Tools that allows inserting scripts in Header or Footer globally.

Primary URL

The single hostname registered to a SeaText account; used for licensing and traffic attribution.

Activation handshake

The 40-second client-side session that signals SeaText backend to link the domain to the account.

Propagation window

The 5–10 minute backend processing time before the dashboard reflects the connected site.

AI Hub / Configuration

SeaText dashboard sections where agents (Translation, CRO, SEO, etc.) are enabled per site.

Practical Scenarios

Scenario A: Staging Subdomain on Same Account

You want staging.example.com and example.com both on SeaText. The integration guide requires separate accounts. Create a second SeaText account for staging, install its unique snippet on the staging Squarespace site (or same site with domain mapping), and run the 40-second activation on the staging URL.

Scenario B: Client Handoff

You built the site on your Squarespace account, client will own the SeaText account. Have the client create the SeaText account first, give you the snippet, you inject it, then you (or client) perform the 40-second visit on the live domain. The client then sees the site in their dashboard.

Scenario C: Squarespace Trial Domain

Using yourname.squarespace.com for testing. This is a valid real domain. Ensure the trial site is published (not password-protected), inject snippet, visit for 40 seconds, wait 10 minutes. Works identically to custom domain.

FAQ

Can I use a .local or .test TLD with a hosts file entry?

No. SeaText validates the domain against public DNS and TLS. Reserved TLDs and non-public hostnames are treated as development URLs and blocked.

What if the script loads but console shows SeaText: domain mismatch?

The snippet's embedded account ID expects a different hostname. Regenerate the snippet from the correct SeaText account (the one whose primary URL matches the current hostname) and replace the Code Injection content.

Does the 40-second visit have to be from the account owner's IP?

No. Any browser session on the live URL counts. You can ask a colleague or use a mobile device on cellular data to satisfy the timer.

Why does the dashboard show the site name but agents won't activate?

Usually because the site is still password-protected (Squarespace trial mode) or the script was removed after activation. Re-publish the site, confirm snippet is still in Header, then retry agent activation.

Can I debug on a Squarespace 7.0 Developer Platform site?

The Code Injection method works on 7.1. For 7.0 Developer Platform (Git-based), you must include the snippet in your template files and deploy via Git. The 40-second and 5–10 minute rules still apply.

What if I need to test multiple variants on the same domain?

SeaText's own A/B and multi-armed bandit testing runs inside one account. You do not need multiple accounts for variant testing — only for distinct primary URLs.

Verification Step: End-to-End Confirmation

After completing the sequence, confirm all three green lights:

1. Network tab shows SeaText script 200 OK and activation POST 200 OK.
2. SeaText dashboard shows your site name next to the logo.
3. Configuration → AI Hub lets you toggle agents on and shows "Active" status.

If any light is red, re-run the checklist from step 1. Most failures resolve at step 2 (domain validity) or step 4 (40-second visit).

Commercial intent is the probability that a search query signals a user's readiness to buy or evaluate a product. Understanding this intent helps you target the right keywords, craft better ads, and design landing pages that convert. This guide explains how to determine commercial intent using practical methods, real-world examples, and common pitfalls to avoid.

How to Identify Commercial Intent

Commercial intent is the likelihood that a user is searching with the goal of making a purchase or evaluating a product. You can determine this intent by examining the language used in the query and the behavior of the search engine results page (SERP).

1. Analyze Transactional Modifiers

Look for keywords that imply a desire to buy or compare. Common indicators include "buy," "pricing," "discount," "best [product]," "review," "cheap," or "near me." These terms suggest the user has moved past the "what is" phase and into the "which one should I choose" phase.

For example, "best running shoes" shows commercial intent because the user is comparing options. "Running shoes" alone is more ambiguous. It could be informational or transactional. Adding "best" or "review" signals evaluation. Adding "buy" or "price" signals a stronger purchase intent.

However, modifiers are not foolproof. Some queries like "best way to fix a leak" are informational. The word "best" does not always mean commercial. Always check the context.

2. Observe SERP Features

Search engines are excellent at predicting intent. If a query triggers Google Shopping carousels, paid ad placements, or "sponsored" results, the search engine has already classified the query as having high commercial intent. If the results are purely educational articles or Wikipedia entries, the intent is likely informational.

For instance, search for "buy iPhone 15" and you will see ads and shopping results. Search for "history of the iPhone" and you will see articles and Wikipedia. The SERP layout is a strong signal.

But SERP features vary by industry and location. Some niches have fewer ads due to low competition. Others show ads even for informational queries. So use SERP features as a clue, not a rule.

3. Use Keyword Research Tools

Modern SEO tools provide "intent" labels for keywords. While these are estimates, they help filter large lists of keywords into actionable segments. Focus your efforts on keywords labeled "commercial" or "transactional" to prioritize traffic that is closer to a conversion.

Tools like Ahrefs, SEMrush, and Google Keyword Planner offer intent classifications. They analyze click-through rates, ad competition, and historical data. However, these labels are not always accurate. They may miss niche meanings or seasonal shifts. Always verify with manual checks.

4. Analyze Search Context and Audience

Intent depends on who is searching and why. A query like "laptop" could come from a student researching specs or a buyer ready to purchase. Look at the search history, device type, and time of day. Mobile users often have higher purchase intent because they are on the go. Desktop users may be doing deep research.

Also consider the funnel stage. Top-of-funnel queries are informational. Middle-of-funnel queries are commercial. Bottom-of-funnel queries are transactional. Map your keywords to these stages to understand intent.

Why Intent Accuracy Matters

If you ignore intent, you risk an "Ad Scent Disconnect." This happens when a user clicks an ad promising a specific solution but lands on a generic page that doesn't address their specific search term. When visitors cannot immediately find what they searched for, they bounce within seconds. Aligning your landing page copy to the specific keyword intent is essential for maintaining high Quality Scores and conversion rates.

For example, if someone searches "buy noise-cancelling headphones under $100" and your ad says "Premium Headphones," they will likely leave. Your page must mention the price range, the product category, and the buying intent. Otherwise, you waste ad spend.

Intent accuracy also affects your bidding strategy. High-intent keywords often have higher conversion rates, so you can bid more aggressively. Low-intent keywords may still be valuable for brand awareness but require different bidding. Use intent data to allocate budget efficiently.

Moreover, intent data helps you personalize the user experience. Tools like Seatext can rewrite your landing page in real time to match the incoming keyword. This ensures the "scent" remains consistent from search to site, reducing bounce rates and increasing conversions.

Diagnostic Sequence for Keyword Intent

Follow this sequence to verify if a keyword is worth your budget:

1. Check the SERP: Does it show ads or products? If yes, it is commercial. Look for shopping carousels, sponsored listings, or local pack results. These features indicate that advertisers are willing to pay for clicks, which usually means high commercial value.
2. Review the Query: Does it contain "buy," "price," or "best"? If yes, it is high-intent. But also check for qualifiers like "for beginners" or "how to" that may lower intent. For example, "best running shoes for beginners" is still commercial but less urgent than "buy running shoes now."
3. Test the Landing Page: Does your current page mention the specific keyword? If not, the user will likely bounce. Use the exact phrase in the headline and first paragraph. If your page is generic, consider creating a dedicated landing page or using dynamic keyword insertion.
4. Automate Alignment: Use tools like Seatext to rewrite your landing page headlines in real-time to match the incoming keyword, ensuring the "scent" remains consistent from search to site. This is especially useful for paid campaigns with many keywords.
5. Analyze Search Volume and Competition: High volume with low competition is ideal. But high competition may indicate high commercial value. Use tools to check CPC and difficulty scores. If the CPC is high, the intent is likely commercial.
6. Study the Top-Ranking Pages: Look at the top 5 results. Are they product pages, category pages, or blog posts? Product pages suggest commercial intent. Blog posts suggest informational intent. This gives you a direct benchmark.

Key Facts: Intent and Conversion

These metrics are interconnected. A high bounce rate lowers Quality Score, which increases costs. By aligning intent, you improve all of them simultaneously.

Common Pitfalls in Intent Analysis

A common mistake is assuming all "best" queries are ready to buy. Some "best" queries are still research-heavy (e.g., "best way to fix a leak"). Always verify the actual search results. Another error is failing to account for bot traffic, which can mimic high-intent behavior but never converts. Using bot protection agents helps ensure your intent data is based on real human behavior.

Here are more pitfalls to avoid:

• Ignoring Local Intent: Queries with "near me" or city names have high commercial intent for local businesses. But they require location-specific landing pages. If you ignore geo-modifiers, you miss out on ready buyers.
• Overlooking Seasonality: Intent can spike during holidays or sales events. A keyword like "gift ideas" is commercial in December but informational in June. Adjust your analysis based on the season.
• Assuming Device Doesn't Matter: Mobile users often have higher purchase intent because they are closer to the point of action. Desktop users may be comparing options. Segment your data by device to refine intent.
• Misinterpreting Ambiguous Queries: Some queries are genuinely unclear. For example, "apple" could be the fruit or the tech company. Use additional signals like search history or related searches to disambiguate.
• Relying Solely on Tools: Automated intent labels are estimates. They can be wrong. Always spot-check with manual SERP analysis.

To handle ambiguous queries, create a decision tree. If the query has multiple meanings, check the SERP for dominant intent. If the SERP shows mixed results, consider the user's likely stage. You can also use Google Trends to see which interpretation is more common.

Frequently Asked Questions

• How do I know if my landing page matches the intent? If your bounce rate is high, your page likely fails to address the specific promise made in the ad or search result. Use heatmaps and session recordings to see where users drop off.
• Does intent change over time? Yes, seasonal trends and market shifts can change how users search for the same product. For example, "best laptops" may spike during back-to-school season. Monitor intent regularly.
• What if my keyword has low volume? High-ticket, low-volume products require precise intent matching because every click is expensive. Use long-tail keywords with clear commercial modifiers to attract qualified traffic.
• Can AI help determine intent? Yes, AI agents can analyze reading telemetry to see where users hesitate, which reveals their true intent better than simple click tracking. Tools like Seatext use AI to adapt landing pages in real time.
• How do I use intent data in campaign optimization? Segment your keywords by intent level. Bid higher on high-intent keywords. Create separate ad groups for commercial and informational queries. Use dynamic landing pages to match each query.
• What is the difference between commercial and transactional intent? Commercial intent is about evaluating options. Transactional intent is about completing a purchase. Both are valuable, but transactional keywords often convert at higher rates.
• Should I target informational keywords at all? Yes, they build brand awareness and can nurture future buyers. But they require different content and conversion paths. Use them for blog posts and guides, not product pages.

Start with Your Business Goals, Not Agent Features

Begin by identifying your top one or two business objectives. Are you trying to increase conversion rates from paid ads? Recover wasted ad spend from bot clicks? Expand into international markets? Or improve how AI systems like ChatGPT recommend your brand? Each goal requires a different type of AI agent.

For example, if your main goal is to boost conversion rates from Google Ads, you need an agent that dynamically matches landing page copy to keyword intent in real time. If you’re losing money to fraudulent clicks, you need an agent that detects invalid traffic and prepares refund claims. Matching agent function to goal prevents wasted effort and ensures measurable impact.

Match Agent Capabilities to Specific KPIs

Evaluate AI agents based on the outcomes they directly influence. Look for agents that tie to clear metrics: conversion rate lift, ad spend recovered, traffic growth in new languages, or increased visibility in AI-generated recommendations. Avoid agents that promise vague benefits like "better engagement" without specifying how they move the needle on your KPIs.

Ask: Does this agent improve a metric I track weekly? If not, it’s likely not the right fit for your current goals.

Understand the Main Types of AI Agents and Their Trade-Offs

AI agents fall into distinct categories based on function. Each has strengths, setup requirements, and limitations. Knowing these helps you avoid overbuying or underutilizing.

• Google Ads Landing Page Agent: Optimizes ad landing pages in real time to match visitor intent. Best for increasing conversion rates from paid campaigns. Requires active Google Ads integration. Limited to search-driven traffic.
• Bot Refund Agent: Detects fraudulent clicks and generates evidence for ad spend recovery from Google and Meta. Recovers up to 20% of wasted ad spend. Does not improve conversion rates directly—focuses on cost recovery.
• Website Translation Agent (125 Languages): Translates and optimizes site content across languages with A/B testing. Drives international traffic and sales. Requires ongoing content updates; best for sites with global audiences.
• Intent Amplifier: Identifies buyer questions and publishes crawlable answers to rank in AI and Google search. Builds authority and brings high-intent traffic. Works best when combined with content strategy.
• AI CRO Reading Analysis Agent: Uses real-time reading behavior to test and scale winning copy variants. Ideal for low-traffic sites where traditional A/B testing fails. Requires sufficient visitor volume to generate meaningful telemetry.
• ChatGPT Brand Visibility Agent: Shapes how large language models recommend your products when users ask for advice. Increases AI referral traffic. Impact builds over time; not a quick fix for immediate conversions.

Use a Simple Decision Framework to Choose

Follow this step-by-step process to select the right AI agent:

1. Define your primary goal: Pick one measurable outcome (e.g., increase conversion rate by 20%, recover $50K in ad spend).
2. List candidate agents: Match each goal to agents that directly influence that metric.
3. Check integration requirements: Confirm the agent works with your current stack (e.g., Google Ads, Shopify, Meta).
4. Evaluate setup effort: Some agents deploy in under a minute; others need configuration or content input.
5. Assess ongoing needs: Determine if the agent requires manual updates or runs autonomously.
6. Start with one agent: Deploy, measure impact for 4–6 weeks, then add more if needed.

Key Facts About Seatext’s AI Agents

Practical Scenarios: Which Agent Fits Your Situation?

Scenario 1: You run Google Ads and see high bounce rates Use the Google Ads Landing Page Agent. It adapts your landing page copy to match each visitor’s search term, improving relevance and conversion rates. Ideal if you’re spending on ads but not seeing proportional returns.

Scenario 2: You suspect click fraud is draining your ad budget Deploy the Bot Refund Agent. It detects fraudulent activity in real time and compiles court-ready reports for refund claims from Google and Meta. Best if you’ve noticed unusual click patterns or low conversion despite high traffic.

Scenario 3: You want to sell internationally but lack localization resources Use the Website Translation Agent. It translates your entire site into 125 languages with zero code and automatically deploys the highest-converting variants. Suitable for ecommerce stores or SaaS companies targeting non-English markets.

Scenario 4: You want AI systems like ChatGPT to recommend your brand Activate the ChatGPT Brand Visibility Agent. It builds an invisible knowledge base so LLMs are more likely to suggest your products when users ask for recommendations. Works best when combined with clear product messaging.

Scenario 5: Your site gets traffic but traditional A/B testing is too slow Choose the AI CRO Reading Analysis Agent. It uses millisecond-level reading telemetry to test copy variants continuously, eliminating the need for large sample sizes. Perfect for niche stores or B2B sites with limited visitors.

Limitations and When This Advice Does Not Apply

This framework assumes you have a functioning website and access to basic analytics. It does not apply if you’re still in product development or lack traffic to measure agent impact. AI agents optimize existing workflows—they don’t create demand from nothing.

Also, avoid expecting immediate results from agents like the Intent Amplifier or ChatGPT Brand Visibility Agent. Their impact builds over weeks as search engines and AI models recrawl and reindex your content. Measure progress monthly, not daily.

If your main challenge is internal team alignment or creative strategy—not technical execution—AI agents alone won’t solve it. They amplify what’s already working; they don’t replace poor positioning or unclear offers.

Frequently Asked Questions

How long does it take to see results from an AI agent?

It depends on the agent and your traffic volume. The Google Ads Landing Page Agent and Bot Refund Agent can show impact within days due to real-time optimization. Translation and visibility agents typically take 2–4 weeks to reflect in traffic and conversion data as content is deployed and indexed.

Do I need technical skills to deploy these agents?

No. All Seatext AI agents deploy in under one minute with a simple script or plugin. No coding or server changes are required. Once activated, they run autonomously and update automatically.

Can I use multiple AI agents at once?

Yes. Agents are designed to work together. For example, you can run the Google Ads Landing Page Agent to improve ad conversions while simultaneously using the Bot Refund Agent to recover wasted spend and the Translation Agent to reach global audiences.

What if I’m not sure which goal to prioritize?

Start with the metric that’s leaking the most value—whether it’s wasted ad spend, low conversion rates, or missed international opportunities. Fix the biggest leak first, then move to the next.

Are there risks in using AI agents for marketing?

The main risk is misalignment—using an agent that doesn’t match your goal. For example, deploying a translation agent when your main issue is ad fraud won’t solve your problem. Always match agent function to your primary KPI before activating.

To disable SeaText translation for one Thinkific course without uninstalling, open the SeaText dashboard and go to the Main AI Hub. Open Configuration, then uncheck or remove that course from the translated pages. Keep the SeaText JavaScript snippet in Thinkific's Site Footer Code field, and every other course will keep working normally.

The simplest way to think about this: SeaText translates pages you activate, not every page on your Thinkific site. A private cohort course only needs to be left out of that active set. You do not need to remove the snippet, cancel anything, or change Thinkific's own language settings.

What disabling a course actually means

SeaText is installed on Thinkific with a JavaScript snippet. You paste that snippet into the Site Footer Code field, and then you control the integration from the SeaText dashboard. There is no SeaText settings tab inside Thinkific.

'Disable this course' therefore means: make SeaText stop translating that course's URL, while the snippet stays installed for the rest of your catalog. If a course is private, cohort-specific, or simply not ready for translated versions, the task is the same. Remove that one course from the active translation set.

Prerequisites before you start

• SeaText account login with access to the Main AI Hub and Configuration.
• Thinkific admin access if you need to check the Site Footer Code field.
• The full URL of the course you want to keep untranslated. If the course has a separate sales page, save that URL too.
• A linked SeaText site. The integration guide covers this: add your website address, visit the site for at least 40 seconds, then wait at least five minutes for it to appear in your account.

Step-by-step: turn off translation for one course

1. Log in to your SeaText account.
2. Open the Main AI Hub.
3. Click Configuration. This is where you adjust the AI parameters and choose where translation is active.
4. Find the course you want to exclude. If your list is called Included Courses, uncheck it. If an exclusion list exists, add the course URL there. If neither label is present, turn off the page in the active translation list.
5. Save the change.
6. Leave the Thinkific snippet in place. If you need to confirm it, go to Thinkific admin, select Settings, then Code & Analytics, and check the Site Footer Code field. Do not delete it unless you want to stop SeaText for the whole site.

How to verify the course is no longer translated

After saving the configuration, check the live course page from a visitor's point of view.

• Open a private or incognito browser window.
• Go to the course URL.
• Give the page a few seconds to load.
• The page should appear in its original language, without the SeaText translation layer.
• Open another course on the same site. It should still translate. If it does not, the snippet may be missing from Site Footer Code.
• Return to Configuration if the excluded course still appears as active.

Keep in mind that cached pages can show old content for a short time after you save. Reload after a few minutes if needed.

SeaText terms used in this task

Main AI Hub

The central area where you activate the AI features you want on each page.

Configuration

The settings screen where you adjust AI parameters for active pages.

Variants Edit

A screen where you can review, create, or edit translations for a specific URL and language. Use it if you need to clean up an old translated version after disabling a course.

Key facts about the Thinkific integration

Disable one course or delete the SeaText snippet?

SeaText is installed on Thinkific with a JavaScript snippet, so the closest thing to uninstalling is deleting that snippet. That is a much bigger action than disabling one course.

Choose the Configuration route if you want a reversible per-course switch. Choose the snippet removal route only if you want to stop SeaText entirely.

Limitations and edge cases

• If you cannot find the course in Configuration, check whether the course was ever activated. An inactive course does not need to be disabled.
• If a translated version is already live, you may still see a saved copy if your browser or CDN cached the page.
• SeaText does not depend on Thinkific's own site language setting. Thinkific's language settings control default site text, not which SeaText pages are active.
• If you remove and later re-paste the JavaScript snippet, repeat the linking steps from the integration guide.
• This advice applies when you want to keep SeaText for other courses. If the goal is to turn off translation site-wide, deleting the snippet is the direct route.

Common mistakes

• Deleting the entire snippet to stop one course. That disables SeaText everywhere.
• Looking for SeaText controls inside Thinkific admin. Configuration lives in the SeaText dashboard.
• Checking a cached page and assuming the change did not save.
• Forgetting to save the Configuration screen.
• Ignoring old translated variants. If you need to clean up, use Variants Edit for that URL and language.

FAQ

Do I need to uninstall SeaText to stop one course?

No. Removing the snippet stops translation for the whole site. Use Configuration to exclude one course instead.

Where is the SeaText setting for Thinkific?

In the SeaText dashboard under Main AI Hub and Configuration. Thinkific admin only holds the JavaScript snippet.

What if the course still appears in another language after I disable it?

Check for a cached page first, then test again in an incognito window. If it still translates, go back to Configuration and confirm the course is off. If it still appears, contact SeaText support.

Will Thinkific's own language settings affect SeaText?

No. Thinkific's language settings handle default site text. SeaText uses its own Configuration and active page settings.

Can I re-enable translation for that course later?

Yes. Open Configuration again and add the course back to the active translation list. No new installation is required.

Is deleting the JavaScript snippet the same as uninstalling the app?

For SeaText on Thinkific, yes. The snippet is the integration. Deleting it turns off SeaText for the whole site. To restore it, paste the code again and repeat the linking steps.