Can SeaText AI Translate Dynamic Content Fetched After SSR Hydration?

Yes, SeaText AI can translate dynamic content fetched after SSR hydration. The script watches the DOM for changes and translates any newly inserted nodes automatically.

Learn more about this service

See how this page can help with your next step.

Learn more

Can I Defer the SeaText AI Script Until After First Paint in an SPA?

Direct Answer: Yes, you can defer loading the SeaText AI script, but you must replace the default async attribute with defer and ensure the script initializes before any user interaction that depends on tracking or personalization.

Yes, you can defer the SeaText AI script until after first paint in a single‑page application (SPA). The default snippet uses async, which runs as soon as the file finishes downloading. If you need deterministic execution after the HTML is parsed, replace async with defer. Then bind SeaText initialization to your router so it runs before any interaction that requires tracking.

How the SeaText Snippet Loads by Default

The SeaText AI snippet ships with the async attribute on the script tag. This tells the browser to download the file without blocking HTML parsing and to execute it as soon as the download finishes, regardless of document order. In a traditional multi‑page site that is often sufficient.

In an SPA the script loads once on the initial page load. After each client‑side navigation you must call the SeaText init routine again so the library can read the new URL, campaign parameters, and visitor context.

Async vs. Defer: Correct Execution Model

Attribute	When the script executes	Effect on first paint	Typical SPA use case
`async`	As soon as the file finishes downloading, in no guaranteed order	May run before or after first paint, depending on network speed	Good for fire‑and‑forget scripts that do not depend on DOM order
`defer`	After HTML parsing completes, before `DOMContentLoaded`, in document order	Runs after parsing; first‑paint timing can vary, but the script does not block rendering	Ideal when you need the DOM ready before the script runs
Inline at end of `body`	Immediately when the parser reaches the tag	Blocks rendering while the script executes	Rarely recommended for third‑party scripts

Both async and defer avoid render‑blocking. The key difference is order: async runs as soon as it is ready; defer runs after the document is parsed, preserving the order of multiple deferred scripts.

Replacing `async` with `defer`

Open your index.html (or the static entry file used by your framework).

Locate the SeaText script tag. It will look like:

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

Replace async with defer:
```
<script src="https://cdn.seatext.com/sea.js" defer></script>
```
Do not add defer alongside async. The replacement ensures the script runs after HTML parsing but before DOMContentLoaded.
Save the file and rebuild your SPA if your build pipeline copies static assets.

After this change the script will execute after the parser finishes, which is effectively after first paint in most browsers. The timing can vary on slow devices, so do not assume it always runs after the first pixel is painted.

Initializing SeaText on Every SPA Route

Deferring the load does not replace the need for explicit initialization. The script loads once, but your SPA may change URLs, query strings, or hash fragments without a full page reload. SeaText must be told to re‑scan the page each time.

Follow these steps for a reliable init pattern:

Import the global SeaText object. After the script tag loads, window.SeaText becomes available.
Hook into your router. In React use useEffect that watches router.pathname. In Vue use router.afterEach. In Angular subscribe to NavigationEnd.

Call the init method with the current URL. Example for React:

useEffect(() => {
  if (window.SeaText) {
    window.SeaText.init({ url: window.location.href });
  }
}, [router.pathname]);

Run the init before the new view renders. Place the hook at the top of your layout component so it fires before child components mount.
Verify. Open DevTools → Network to confirm the script loads once (cached). Open Console and type SeaText to see the object. Check the Elements panel for rewritten headlines after navigation.

This pattern guarantees that SeaText sees the correct URL and campaign parameters on every route change, regardless of whether the script was loaded with async or defer.

Why Timing Matters for Personalization and Tracking

SeaText rewrites headlines, offers, and proof points based on the visitor’s source (Google Ads, Meta, email, referral) and parameters such as utm_term or ValueTrack {keyword}. If the script runs after the user has already clicked a CTA, the interaction may be recorded with generic content, reducing attribution accuracy.

SeaText’s own documentation notes that on a landing page the rewrite happens in under 15 ms before visual paint (S3). In an SPA you can mimic that speed by calling SeaText.init() synchronously in the router guard before the new components render.

When you need the rewrite to be visible on the very first pixel—e.g., a headline that determines bounce rate—deferring past first paint defeats the purpose. In those cases, keep the default async load but still call init early in the navigation lifecycle.

Performance, Limitations, and Edge Cases

Content Security Policy (CSP): Allow the SeaText domain and any inline initialization code. Blocking the script will stop all rewrites.
Local storage: SeaText stores a visitor ID in local storage (S1). Ensure your app has permission to read/write local storage.
Cross‑origin scenarios: If your SPA calls APIs on other domains, verify that the SeaText script is compatible and does not trigger CORS errors (S1).
Ad blockers and privacy extensions: Some users block third‑party scripts. Deferring does not bypass these blockers; test with common extensions enabled.
SSR / SSG hydration: When the initial HTML is server‑rendered with SeaText rewrites already applied, the client script should only hydrate and not rewrite again. Check SeaText’s SSR guidance for your framework.
First‑paint variability: defer runs after parsing but before DOMContentLoaded. The exact moment relative to first paint depends on network speed and device performance. Do not claim that defer always runs after first paint.

Frequently Asked Questions

Will adding `defer` stop SeaText from rewriting before the page is visible?

On the initial load, defer runs after HTML parsing, which is usually after the first paint. If you need the rewrite before the first pixel, keep async and call SeaText.init() early in your router.

Can I keep `async` and also add `defer`?

No. Replace async with defer if you want deferred behavior. Adding both creates ambiguous execution order and defeats the purpose of the repair instruction.

Do I need to call `SeaText.init()` on every route change?

Yes. The script loads only once, but the SPA changes URLs without a full reload. Calling init on each navigation ensures the correct parameters are read and the page is rewritten.

Is there a performance penalty for initializing on every route?

The init call is lightweight. SeaText’s script is under 15 KB and runs in under 15 ms (S3). The cost is negligible compared with the benefit of accurate personalization.

How do I verify that SeaText works after I replace `async` with `defer`?

Open Chrome DevTools → Network and confirm the script loads with a status of 200 and is cached after the first request. In the Console type SeaText to see the object. Navigate between SPA routes and watch the Elements panel for updated headlines, offers, or CTAs.

Does SeaText work with React 18’s concurrent rendering or Next.js App Router?

Yes. Place the script tag in the static layout.tsx or _document.html file, replace async with defer, and call SeaText.init() inside a useEffect that watches router.pathname. The same pattern works with Vue’s router.afterEach and Angular’s NavigationEnd subscription.

Expert Perspective: Treat Initialization as Part of Your Router Lifecycle

Deferring the script load is a performance tweak. Correct initialization is a correctness requirement. Load the script however you prefer—async, defer, GTM, or dynamic import—but always bind SeaText.init() to the router’s navigation events. That guarantees the library sees the right URL, campaign parameters, and visitor context on every view in your SPA.

Key Takeaways

SeaText’s default snippet uses async. Replace it with defer if you need execution after HTML parsing.
defer runs after parsing, before DOMContentLoaded, but first‑paint timing can vary.
Always call SeaText.init() on each client‑side route change.
Verify with DevTools and watch for rewritten content.
Consider CSP, local storage, cross‑origin, and ad‑blocker impacts.

Why the injection method matters for SvelteKit

SvelteKit renders pages on the server first, then hydrates them into a single-page application. On the initial load, the server sends full HTML that includes the <head> content. The snippet in <svelte:head> appears in that HTML. After hydration, client-side navigation replaces only the page content — the layout stays mounted. If you place the snippet in a component that unmounts on route changes, the script loads once but never reinitializes, so dynamic rewrites stop working after the first navigation. The documentation notes that the snippet includes the async attribute for asynchronous loading and stores an ID in local storage, both of which require the script to persist across route transitions.

SSR (server-side rendering) means the snippet runs on the server during the initial render. But the script itself is a client-side script that executes in the browser. So the snippet tag is included in the server HTML, but the actual script runs in the browser after hydration. On subsequent client-side navigations, the layout stays mounted, so the snippet tag is not re-added. That is why you need to call the init function in onMount — it re-executes on every page component mount, which happens on each navigation.

How SeaText behaves in a single-page application

The SeaText snippet is designed for traditional page loads. In an SPA, the script loads once on the initial HTML response. Subsequent client-side navigations do not re-execute the snippet, so you must manually reinitialize the SeaText instance on each route change. The general SPA guide instructs you to identify the entry point — typically index.html or the main JavaScript/TypeScript file where the framework mounts the application — and insert the snippet there. For SvelteKit, the root layout is the equivalent entry point.

The script executes synchronously in under 15ms before visual paint, is under 15 KB, and eliminates layout popping (CLS = 0), preserving high PageSpeed scores. Because it runs before paint, you must ensure the init function is called early enough. The onMount hook runs after the component is rendered but before paint, so it is suitable.

Step-by-step integration for SvelteKit

Locate your root layout. In a SvelteKit project this is src/routes/+layout.svelte.
Insert the snippet in <svelte:head>. Paste the SeaText snippet inside a <svelte:head> block so it appears in the <head> of every server-rendered page.
Reinitialize on client-side navigation. In the same +layout.svelte, import onMount from svelte and call the SeaText initialization function (typically window.SeaText.init() or the equivalent exposed by the snippet) inside the callback.
Verify local storage access. The script stores an ID in local storage. Confirm your SvelteKit app does not block third-party storage or run in a sandbox that prevents localStorage access.
Build and test. Run npm run build and npm run preview. Open Developer Tools (F12), check the Console and Network tabs for the SeaText script request (should return 200), and confirm the global SeaText object is defined.
Test cross-origin scenarios. If your SvelteKit app interacts with multiple domains, verify the script loads and functions correctly across those origins, as cross-origin issues can block the snippet.

Here is a minimal +layout.svelte example:

<script>
  import { onMount } from 'svelte';

  let SeaTextInit;

  onMount(() => {
    // The snippet defines window.SeaText or similar
    if (typeof window.SeaText !== 'undefined' && window.SeaText.init) {
      window.SeaText.init();
    }
  });
</script>

<svelte:head>
  <script async src="https://seatext.com/snippet.js"></script>
</svelte:head>

<slot />

Note: Replace the script URL with the actual snippet from SeaText. The init function name may vary; check the snippet documentation.

Adapter considerations: static vs node

SvelteKit can be deployed with different adapters. With adapter-static, all pages are prerendered as static HTML. The <svelte:head> snippet is included in those static files. The onMount init still runs when the page hydrates. With adapter-node, the server renders pages on demand. The snippet is included in the server-rendered HTML. Both adapters work the same way for the snippet. The key difference is that with adapter-static, you must ensure the fallback page (if used) also includes the layout. For full SPA mode with adapter-static and a fallback, the root layout is still used for the fallback, so the snippet is present.

Common mistake: placing the snippet in a page component

Adding the snippet inside +page.svelte files or layout components that unmount on navigation causes the script to load multiple times or lose its initialized state. The documentation's testing steps — build, serve, inspect Console and Network tabs — will reveal duplicate script requests or missing SeaText objects if this happens.

Verification checklist

Network tab shows a single SeaText script request with 200 status on initial load.
Console shows no errors related to SeaText or local storage.
window.SeaText (or the documented global) is defined after onMount runs.
Dynamic rewrites (headline swaps, translations, personalization) work after clicking internal links.
No duplicate script tags appear in the DOM after navigation.
On a hard refresh, the snippet loads once. On client-side navigation, the init function runs again but the script tag is not duplicated.

Troubleshooting missing rewrites or duplicate script tags

If rewrites stop after the first navigation, check that the init function is called inside onMount and not in a module-level script. Module scripts run once per page load, not on every navigation. Also verify that window.SeaText is defined after the snippet loads. If the snippet loads asynchronously, the init function may run before the script is available. In that case, wrap the init call in a check or use a callback from the snippet.

Duplicate script tags occur if the snippet is placed in a component that is recreated on each navigation. The root layout (+layout.svelte) is only created once, so it avoids duplicates. If you see multiple script tags, inspect the DOM after navigation. If the snippet appears twice, move it to the root layout and remove it from any page components.

If the snippet does not load at all, check the network tab. A 404 error means the URL is wrong. A blocked request may be due to Content Security Policy (CSP). Add the SeaText domain to your script-src and connect-src directives. For SvelteKit, CSP is configured in the svelte.config.js or via meta tags.

If rewrites do not appear on initial load, the snippet may be blocked by ad blockers. Test in incognito mode or with extensions disabled. The script's async attribute means it loads after the page starts parsing, but it executes before paint. If the page paints before the script runs, rewrites may appear after a flash. The documentation states it executes in under 15ms, so this is unlikely.

Limitations and when this advice does not apply

If you use SvelteKit's adapter-static with a fallback page for full SPA mode, the same root-layout + onMount pattern applies, but ensure the fallback page also includes the <svelte:head> snippet. The fallback page uses the root layout, so it is fine.
Server-side rendering (SSR) disabled via export const ssr = false in +layout.ts still requires the snippet in <svelte:head> because the initial HTML is still served from the server. However, if you disable SSR entirely and use a client-only app, the snippet must be added to the HTML shell (e.g., app.html). In that case, the onMount init still applies.
If your deployment uses a CDN or edge middleware that strips or modifies <head> content, confirm the snippet survives the transformation. For example, Cloudflare's HTML minification may remove type attributes or alter script tags. Test with preview builds.
The snippet's asynchronous loading and local storage dependency mean it will not work in environments that block third-party scripts or storage (e.g., strict CSP without script-src and connect-src allowances for SeaText domains, or browsers with third-party cookie blocking that also affects local storage).
If you use SvelteKit's adapter-static with prerendering, the snippet is included in the static HTML. The onMount init runs when the page hydrates. For fully static SPAs without hydration, the init function may not run. In that case, you need to call init in a script tag in the HTML shell or use a service worker.

FAQ

Can I use Google Tag Manager instead of editing `+layout.svelte`?

Yes, but the tag must fire on every client-side navigation, not just the initial page view. Configure the GTM tag to trigger on SvelteKit's navigate event or use a custom event listener that calls the SeaText init function after each route change.

Does the snippet cause layout shift or hurt PageSpeed?

No. The documentation states the script executes synchronously in under 15 ms before visual paint, is under 15 KB, and eliminates layout popping (CLS = 0), preserving high PageSpeed scores.

What if my SvelteKit app uses multiple `+layout.svelte` files for route groups?

Place the snippet in the top-most root layout (src/routes/+layout.svelte) so it loads once for the entire app. Child layouts inherit the head content; do not duplicate the snippet in nested layouts.

How do I pass configuration options (e.g., AI scope, translation languages) in SvelteKit?

Set configuration variables on window.SeaTextConfig before the snippet loads, or pass them to the init function inside onMount. Because the snippet loads asynchronously, define the config object in a <script context="module"> block in +layout.svelte so it exists before the snippet executes.

Will SeaText work with SvelteKit's prerendered pages?

Yes. Prerendered pages are served as static HTML; the snippet in <svelte:head> will be included in the generated files. OnMount reinitialization still runs when the page hydrates.

What should I do if the script loads but rewrites don't appear?

Check that the init function is called inside onMount (not in the module script), verify the SeaText global is defined, and ensure no CSP errors block the script's API requests. The documentation's functionality check step covers this. Also, confirm that the snippet URL is correct and the script is not blocked by ad blockers.

Can I lazy-load the snippet after the first paint?

The snippet already loads asynchronously via the async attribute. Further deferral is unnecessary and may delay the rewrites that SeaText applies before visual paint.

Why SSR integration differs from a plain SPA

In a plain SPA the entry point is usually index.html. In Next.js SSR the first HTML is produced by the custom Document component on the server. The script must be placed there so it travels with the initial payload.

How SeaText AI rewrites content after hydration

The snippet loads asynchronously in the browser. After React hydrates the page, the script scans the DOM and replaces text nodes with AI‑generated variants. This happens entirely client‑side.

Trade‑offs: indexed HTML vs post‑hydration copy

Search engines see the original server‑rendered markup because the rewrite occurs after the script runs. If SEO‑critical copy must be indexed, you need a server‑side solution or accept the delay.

Next.js App Router vs Pages Router considerations

Both routers support a custom _document.js file. In the App Router the file lives at app/_document.js; in the Pages Router it lives at pages/_document.js. The insertion method is identical.

Prerequisites

Make sure you have a Next.js project (v13 or later) and access to edit pages/_document.js or app/_document.js. You also need the SeaText AI snippet (shown as SEATEXTCODEINTEGRATION in the docs).

Step 1 – Identify the insertion point

In a server‑side rendered Next.js app the earliest HTML is generated in the custom Document component. This is the equivalent of the SPA “index.html” entry point mentioned in SeaText’s guide.

Step 2 – Add the SeaText AI snippet

Create or edit pages/_document.js (or app/_document.js if you use the app router).
Inside the <Head> tag, insert the SeaText script with the async attribute:

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

This matches the “async attribute for the script tag” recommendation.

Step 3 – Handle local storage and cross‑origin needs

The script stores an ID in localStorage. Ensure your site does not block storage access (e.g., avoid strict CSP that denies storage).
If your app calls APIs on other domains, verify that the SeaText script is allowed to run across origins, as the documentation warns about cross‑origin considerations.

Step 4 – Build and serve the app

Run npm run build && npm start (or next build && next start) to generate the SSR HTML. The script will be included in the server‑rendered <head> and load asynchronously on the client.

Step 5 – Verify the integration

Open the page in a browser and open Developer Tools (F12).
Check the Network tab for the SeaText script request and confirm it returns 200.
Look at the Console for any errors related to the script.

If the script loads without errors, SeaText AI is ready to rewrite copy on the client side after hydration.

Common mistake to avoid

Placing the snippet inside a component’s useEffect will cause it to load after the first render, missing the chance to rewrite the initial HTML. Insert it in the Document component so it’s part of the initial HTML payload.

Limitations

Because the snippet runs in the browser, the SSR HTML is not rewritten until the script executes, so the original markup is what search engines initially see.

Key terminology

SSR (Server‑Side Rendering) – HTML is generated on the server before being sent to the browser.
Hydration – The process where React attaches event listeners to the pre‑rendered HTML.
Async script – Loads without blocking page rendering.

FAQ

Do I need to modify my Next.js routing?: No, the integration only touches the Document file; routing stays unchanged.
Will SeaText AI affect page load speed?: Because the script is loaded with async, it does not block rendering, matching SeaText’s performance guidance.
Can I use SeaText AI on static‑site‑generated (SSG) pages?: Yes, the same snippet works; the script runs client‑side after the static HTML is delivered.
What if my site uses a strict Content‑Security‑Policy?: Allow the script’s source domain and enable script-src and storage permissions.

How SeaText translation works in the browser

SeaText AI delivers translations through a lightweight JavaScript snippet that you paste into your page. The snippet loads asynchronously, reads the rendered DOM, and rewrites text nodes into the visitor's language. According to the integration guide, the script stores an ID in local storage and must have access to the fully rendered DOM to function.

Because the translation happens entirely in the browser, SeaText never sees the HTML that your server sends. It only sees what the browser paints after your framework finishes hydrating the page. The homepage confirms SeaText translates every page, headline, button, and offer into up to 125 languages, but this translation layer sits on top of the client‑side DOM.

The integration guide for SPAs shows the snippet includes the async attribute, which means the browser decides when to fetch and execute it. There is no built‑in hook that waits for a framework's hydration lifecycle. If the script runs while the page is still a static HTML shell, it translates only the shell. Any content that mounts later — client‑only components, lazy islands, or streamed fragments — stays in the original language.

Why SSR breaks that assumption

Server‑side rendering sends a complete HTML document to the browser. The browser paints that HTML immediately, then your framework (Next.js, Nuxt, Astro, Remix, etc.) "hydrates" the page by attaching event listeners and making the markup interactive. Hydration is asynchronous and can take dozens to hundreds of milliseconds depending on bundle size and device performance.

If the SeaText snippet runs before hydration completes, two things go wrong:

The script may scan the DOM while it still contains only the server‑rendered markup in the default language. Any components that render translated text client‑side haven't mounted yet.
Hydration can replace or reorder DOM nodes after SeaText has already processed them, wiping out the translations.

The integration guide notes the script stores an ID in local storage. If hydration discards and re‑creates nodes, the translated text nodes are gone and the script does not automatically re‑translate them unless you trigger a new pass.

Common hydration patterns that cause misses

Next.js App Router (React 18+)

Streaming SSR sends a shell first, then streams in components. The SeaText snippet in <head> or early in <body> executes while the stream is still arriving. Components that contain translatable text may not exist in the DOM when SeaText makes its first pass. React 18's concurrent features can also split hydration into multiple micro‑tasks, widening the window where the DOM is incomplete.

Nuxt 3

Nuxt hydrates islands independently. A translation snippet placed in app.vue or a plugin often runs before all islands are hydrated, missing content inside lazy‑loaded or deferred components. The onNuxtReady hook fires after the initial hydration, but islands with client:visible or client:idle may hydrate later.

Astro with `client:visible` or `client:idle`

Astro islands hydrate only when they enter the viewport or the main thread is idle. SeaText running at page load will not see those islands at all. Even client:load islands hydrate after the initial script execution unless you explicitly sequence them.

Remix / React Router v7

Remix hydrates after the initial document load. Scripts in root.tsx that run on DOMContentLoaded can still beat hydration if the bundle is large. The framework's hydrate call happens in a separate micro‑task, so any synchronous or early‑async script runs first.

Qwik and resumable frameworks

Qwik serializes state into HTML and resumes without a traditional hydration pass. The SeaText snippet sees the serialized HTML but may miss components that resume on interaction. Since there is no single "hydration complete" event, you must hook into Qwik's onVisibleTask$ or similar lifecycle to trigger translation after each resume.

Diagnostic sequence: confirm the root cause

Open DevTools → Console and look for SeaText initialization logs. Note the timestamp.
Switch to the Performance tab, record a reload, and mark the hydration complete event (framework‑specific). Compare timestamps.
Inspect the Network tab for the SeaText script load time. If it finishes before the framework's hydration marker, the script ran too early.
Add a temporary console.log(document.documentElement.outerHTML.length) inside a setTimeout(..., 0) after the SeaText snippet. Reload and verify the DOM size matches the fully hydrated page.
Check for hydration mismatches (React warnings, Vue hydration errors). Mismatches cause the framework to discard and re‑render nodes, removing any translations SeaText already applied.
Search the DOM for data-seatext-translated attributes after the page feels interactive. If they appear only on the shell markup, translations missed the hydrated components.

Workarounds that keep translations on SSR pages

Defer SeaText until after hydration

Wrap the snippet in a hydration‑complete callback. In Next.js App Router, use a useEffect in a client component that mounts at the root layout. In Nuxt, use onNuxtReady(() => { ... }). In Astro, use astro:after-swap or a client:load island that imports SeaText. In Remix, use useEffect in root.tsx or the hydrate callback. This guarantees the DOM is stable before SeaText scans it.

Use a mutation observer fallback

If you cannot hook into the framework's hydration event, start a MutationObserver on document.body after the snippet loads. When new text nodes appear, send them to SeaText's translation API. This catches late‑hydrated islands and client‑only components. Debounce the callback by 50 ms to batch rapid mutations and avoid excessive API calls.

Pre‑translate on the server (advanced)

For fully static or incrementally static pages, run SeaText's translation API at build time and embed the translated strings in the generated HTML. The client‑side snippet then only handles dynamic content (user‑generated text, A/B variants, personalization). This eliminates the timing race entirely for static content. The integration guide does not publish a server‑side SDK, so you would call the HTTP API directly from your build script or edge function.

Avoid `async` on the snippet when you control execution order

The integration guide notes the snippet includes async. If you inject the script via a framework‑managed loader (Next.js Script component with strategy="lazyOnload", Nuxt useHead with defer), you can remove async and place the script after your hydration marker so it runs in the correct tick. This gives you deterministic ordering without relying on micro‑task timing.

Re‑translate after known client‑side updates

If your app fetches data or renders modals after hydration, call SeaText's translation function again (if exposed) or re‑initialize the snippet. The integration guide does not document a public re‑translate method, so you may need to reload the script or trigger a full page translation via the dashboard API.

Limitations and when this advice doesn't apply

Static site generation (SSG) without hydration: If your framework outputs pure HTML with no client‑side hydration (Astro client:only="none", Eleventy, Hugo), SeaText runs against the final DOM and translations apply normally.
Edge‑rendered pages with no client bundle: Some edge functions stream HTML and never send a JS bundle. SeaText cannot run there; you must translate at the edge or origin.
Cross‑origin iframes: The integration guide warns about cross‑origin issues. Translations inside third‑party iframes (payment widgets, embedded apps) will not work regardless of SSR strategy.
Local storage blocked: The snippet stores an ID in local storage. If your SSR page runs in a privacy‑restricted context (Safari ITP, Brave shields, enterprise policies), the script may fail to initialize.
Streaming responses without hydration: If you stream HTML from the server and never hydrate (plain HTML streaming), SeaText will translate each chunk as it arrives, but late chunks may be missed if the script only runs once.

Key facts

Fact	Detail	Source
Translation delivery	Client‑side JavaScript snippet rewrites DOM text nodes	S1, S3
Language coverage	Up to 125 languages	S3, S4
Script loading	Async by default; stores ID in local storage	S1
Integration target	SPAs (React, Vue, Angular) documented; SSR not explicitly covered	S1
Execution timing	Must run after DOM is fully rendered and hydrated	S1 (implied)

FAQ

Does SeaText support Next.js App Router out of the box?

The public documentation only covers SPA integration. You must defer the snippet until after hydration using a root client component or next/script with a custom loader.

Can I translate during `getStaticProps` or `getServerSideProps`?

SeaText does not publish a server‑side SDK. You would need to call their translation API directly from your build or request handler and embed the results in the page HTML.

Why do translations appear briefly then disappear?

That's a hydration mismatch. SeaText translates the server HTML, then React/Vue re‑renders the component and overwrites the translated nodes with the original language.

Will a mutation observer hurt performance?

A narrow observer that only watches characterData and childList on text‑heavy containers adds negligible overhead. Debounce the callback by 50 ms to batch rapid mutations.

Does SeaText work with React Server Components?

RSC payloads are streamed and hydrated progressively. The same timing issue applies: translate after the RSC tree for a given route is fully hydrated.

What if I use a CDN that caches the HTML?

Cached HTML contains the default language. SeaText still runs client‑side on every visit, so translations apply per visitor. Ensure the snippet is not stripped by your CDN's HTML minifier.

How do I verify translations are applied in production?

Add a query parameter ?seatext-debug=1 (if supported) or check the SeaText dashboard for "translated pages" metrics. In DevTools, search the DOM for data-seatext-translated attributes the script adds.

Can I use SeaText with Astro's `client:only` directive?

client:only skips hydration entirely for that component, rendering it only on the client. SeaText will see it if the snippet runs after the component mounts. Place the snippet in a client:load island that imports after the client:only component.

Direct answer

SeaText AI adds under 15 KB to the client-side download. The integration snippet is a small script tag with an async attribute. It does not increase the server-rendered HTML payload. The browser fetches the script after the SSR response is delivered. Because the script loads asynchronously, it does not block rendering or increase Time to First Byte (TTFB).

Tradeoff table: SeaText vs. alternatives

Criterion	SeaText client-side script	Server-side personalization	No script	Self-hosted/proxied script
HTML payload size	No extra bytes	Adds data to HTML	Zero	Depends on configuration
TTFB impact	None	Adds latency	None	Minimal
Caching behavior	CDN cacheable	Often uncachable	N/A	Controlled by your cache
CLS risk	Zero (CLS=0)	Depends on implementation	None	Potentially higher
Maintenance	Low	High	None	Medium
Best for	Teams wanting minimal server impact	SEO-critical content	Zero overhead	Strict CSP or custom needs

Recommendation: SeaText is ideal for teams that want personalization without server latency. Server-side works when content must be indexed. No script gives zero impact but no personalization. Self-hosted suits strict security policies.

Why the script size matters for SSR

Every byte added to the server response increases bandwidth and delays the first paint. SeaText avoids this by keeping the script client-side. The server only sends a <script async src="..."> tag. That tag is a few dozen characters. The actual script downloads later.

This matters for teams with large audiences or slow networks. The server load stays the same. The client does the work. This is a key cost driver: no extra server CPU or memory for personalization.

How to measure the impact on SSR response size

You can measure the exact impact with browser DevTools. Open the Network tab and reload the page. Look at the HTML document request. The response size should not increase after adding SeaText. The script tag itself is tiny.

To verify the script download, filter by JS and look for the SeaText URL. The script size should be under 15 KB (S2). You can also check the content-encoding header. The script is served compressed.

Before and after integration, compare the total HTML size. Use a tool like WebPageTest to see the waterfall. The script should appear as a separate request after the HTML.

Server-side vs. client-side personalization

Server-side personalization tools query databases or APIs during rendering. That adds time to TTFB. SeaText moves all logic to the client. The server just sends the base HTML.

This tradeoff affects caching. Server-side personalized pages are often uncachable because each user sees different content. SeaText leaves the HTML uncustomized. The same cached page can serve many users. The script personalizes later.

But client-side personalization means the original content appears briefly before the script runs. This is acceptable for most users. If SEO requires the personalized content in the initial HTML, server-side is better.

CDN and caching considerations

SeaText hosts the script on its CDN. The script is cacheable by browsers and CDN nodes. This reduces repeat download costs. The script has a cache header (not specified in sources, but standard practice). You can check vendor documentation for exact headers.

If you self-host or proxy the script, you control caching. But you also take on bandwidth costs. The script size is small, so self-hosting is not a major concern. However, the CDN version may be more reliable.

Edge caching works well because the HTML is static. The SeaText script is fetched from edge servers. This combination keeps TTFB low.

Decision framework for teams evaluating SeaText

Ask these questions:

Do you need personalized content in the initial HTML for SEO? If yes, consider server-side personalization.
Is your team sensitive to TTFB? SeaText is a good fit.
Do you use a strict Content Security Policy? Check if the SeaText CDN domain is allowed.
How many repeat visitors do you have? The script will be cached, reducing impact.
What is your current page size? Adding a script tag is negligible.

For most teams, SeaText is safe. The tradeoff is between client-side personalization (fast server, slower client) and server-side (slower server, faster client). SeaText works well for frameworks like Next.js, Nuxt, and Astro because it does not interfere with the SSR pipeline.

FAQ

Does SeaText work with Next.js App Router?

Yes. Add the snippet to app/layout.tsx inside the <head> or <body>. It loads after the server stream finishes.

Can I use `defer` instead of `async`?

SeaText recommends async. defer also works but waits for HTML parsing. Both keep the script off the critical path.

Will SeaText hurt my Core Web Vitals?

No. The script is under 15 KB, loads asynchronously, and executes in under 15 ms before paint. It does not cause layout shift (CLS=0) (S2).

What if my CSP blocks external scripts?

Add the SeaText CDN domain to your script-src directive. The script does not use eval or inline scripts beyond the snippet tag.

Does SeaText add any inline JSON to the HTML?

The standard snippet is a single script tag with a src attribute. No inline configuration object is injected by default. Check with the vendor for custom setups.

How do I verify the script loaded in an SSR page?

Open DevTools → Network, filter by JS, reload. You should see the SeaText script with a 200 response. The Console should show no errors.

Comparison: Client‑side only vs. SSR

Criterion	Client‑side only	SSR	Practical takeaway
SEO / crawler visibility	Googlebot sees rewrites (JS‑enabled); other crawlers may not	All crawlers see rewritten HTML from the initial response	Choose SSR if you need Bing, social preview bots, or legacy crawlers to see localized content.
CSP / script restrictions	Requires whitelisting the CDN domain; inline scripts need nonces or hashes	Server‑side script runs before the CSP is applied; no client‑side restrictions	Client‑side only is simpler if your CSP is flexible. SSR bypasses CSP entirely for the rewrite logic.
Server / runtime requirements	No Node.js runtime needed; works on static hosting (Netlify, Vercel static, S3)	Requires a Node.js server or edge runtime (e.g., Next.js, Nuxt)	Client‑side only is ideal for static exports. SSR requires a server or serverless function.
Access to server‑only data	Cannot read HttpOnly cookies, request headers, or edge‑computed flags	Full access to server request context (cookies, headers, IP)	Use SSR if you need personalization based on server‑side signals.
Complexity / maintenance	One snippet in the HTML; no build pipeline changes	Requires framework integration, hydration management, and potential streaming complexity	Client‑side only is simpler for teams without SSR experience.
First‑paint behavior	Rewrite happens before paint (synchronous under 15 ms, CLS=0)	Rewrite happens server‑side; HTML is delivered already rewritten	Both approaches achieve zero CLS. Client‑side only has a tiny window before paint where original copy is visible, but it is imperceptible.

Conditional recommendation: Choose client‑side only for static export, strict CSP, or no Node runtime. Choose SSR when crawler‑visible rewritten HTML or server‑only personalization is required.

Quick readiness checklist

Your site is deployed as a static export (e.g., next export, nuxt generate, VitePress, Astro static mode).
Your Content Security Policy disallows inline scripts or external domains you cannot whitelist.
You lack a Node.js runtime at the edge or origin (static hosting only).
Your team prefers to avoid SSR hydration mismatches, streaming complexity, or additional server costs.
You can place the SeaText snippet at the end of <body> or in a client‑only entry point.

If most of these apply, client‑side only is a natural fit.

When to wait or choose SSR instead

You need SeaText to rewrite content before the first paint for SEO‑critical meta tags or structured data that search engines read from the initial HTML.
Your framework’s SSR pipeline already injects the snippet in <head> and you have a working hydration flow.
You rely on server‑side personalization (e.g., reading cookies or headers before sending HTML) that SeaText’s client script cannot access.
Your compliance regime requires all third‑party code to be vetted in a server build step.

Exception: hybrid rendering with client‑only islands

Some frameworks (Next.js 13+ App Router, Nuxt 3, Astro) let you mark specific components as client‑only while the rest of the page renders on the server. In that model you keep SSR for the shell and load SeaText only in the interactive island. This gives you the SEO benefits of SSR for static content and the simplicity of client‑side only for the translation and personalization layer.

How SeaText AI works in a pure client‑side context

SeaText AI is delivered as a single JavaScript snippet that you paste into your HTML. The snippet includes the async attribute, so the browser fetches it without blocking page rendering. Once loaded, the script executes synchronously—it reads the page’s DOM, detects the visitor’s source (UTM parameters, referrer, ad click IDs), and rewrites headlines, buttons, and product copy in under 15 ms. This rewrite happens before the browser paints the first frame, so there is no layout shift (CLS=0).

In single‑page applications (SPAs), the script may load after the app mounts if you place it in a client‑only entry point. However, the rewrite still runs synchronously as soon as the script loads, before the next paint cycle. This is distinct from a typical async snippet that runs after hydration. The product’s normal behavior is before‑paint timing, even in a client‑side only setup.

The script stores a lightweight identifier in localStorage to maintain session continuity across route changes in SPAs. Ensure your SPA permits localStorage access (most do). If your SPA spans multiple subdomains, verify that the script’s origin is allowed under your cross‑origin policy.

Key facts

Aspect	Detail
Script size	Under 15 KB (gzipped)
Execution timing	Synchronous, before visual paint, under 15 ms
Loading strategy	Async script tag, non‑blocking
Storage used	`localStorage` for session ID
Supported SPA frameworks	React, Vue, Angular, and any framework that mounts in `<body>`
Integration point	End of `<body>` or client‑only entry file
Cross‑origin note	Verify CSP and CORS if SPA uses multiple domains

Decision framework: choose your integration path

List your constraints. Static hosting? Strict CSP? No Node runtime? Team bandwidth?
Map constraints to the checklist above. Three or more checks → client‑side only.
Check SEO requirements. If search engines must see rewritten copy in the initial HTML, you need SSR or a hybrid island.
Prototype. Add the snippet to a staging build, open DevTools, confirm the script loads (Network tab) and the SeaText badge appears (Console).
Validate functionality. Switch languages, trigger a variant test, verify bot‑detection logs appear in your SeaText dashboard.
Deploy. Push the same static build to production; no server changes required.

Common mistakes to avoid

Placing the snippet in <head> without defer — it blocks paint and may run before the DOM exists.
Forgetting to whitelist https://cdn.seatext.com (or the current CDN host) in your CSP script-src directive.
Assuming SSR‑only personalization (cookie reading, header inspection) works in client‑side only mode — it does not.
Skipping the localStorage permission check in privacy‑first browsers (Safari ITP, Brave Shields).

Limitations of client‑side only integration

No access to server‑only data (cookies set with HttpOnly, request headers, edge‑computed flags).
Search engine crawlers that do not execute JavaScript will not see SeaText rewrites. Googlebot does execute JS, but other bots may not.
If your CSP blocks eval or inline scripts, the SeaText snippet may be rejected unless you add the required hashes or nonces.
While the rewrite happens before paint, the original copy is still present in the HTML source. This is rarely an issue, but some compliance workflows require the final copy to be served directly.

Terminology

SSR (Server‑Side Rendering): HTML is generated on the server for each request.
CSR (Client‑Side Rendering): Browser downloads a minimal HTML shell and JavaScript builds the UI.
Static export: Build‑time generation of static HTML files served without a Node server.
Hydration: The process where client‑side JavaScript attaches event listeners to server‑rendered markup.
CSP (Content Security Policy): HTTP header that restricts which scripts, styles, and resources a page may load.

Hypothetical scenario: a marketing team on Netlify

Imagine a marketing team hosts their React landing page on Netlify with static export enabled. Their CSP blocks all third‑party scripts except a vetted analytics domain. They want SeaText’s translation and ad‑matching features but cannot add a Node server or modify the CSP easily. By pasting the SeaText snippet at the end of <body> in public/index.html and adding the CDN host to script-src, they get full functionality — language switching, variant testing, bot‑refund reports — without any server changes. The site remains a pure static deploy, and the team avoids SSR hydration bugs entirely.

FAQ

Does client‑side only integration hurt SEO?

Googlebot executes JavaScript and will see SeaText rewrites. Other crawlers (Bing, DuckDuckGo, social preview bots) may not. If you depend on those crawlers seeing localized or personalized copy, use a hybrid island or SSR.

Can I still use SeaText’s bot‑refund reports with client‑side only?

Yes. The script detects invalid clicks in the browser and sends evidence to your SeaText dashboard. No server component is required.

What if my CSP uses nonces instead of domain whitelists?

Add a nonce to the script tag: <script src="https://cdn.seatext.com/..." nonce="YOUR_NONCE" async></script>. Generate the nonce server‑side (even in a static build you can inject it at deploy time).

Will SeaText work inside a React `Suspense` boundary?

Yes, as long as the snippet loads after the boundary resolves and the DOM is mounted. Place it in a client‑only component that renders after hydration.

Do I need to change the snippet for each language?

No. The same snippet detects the visitor’s language preference and serves translations automatically.

How do I verify the integration works in CI?

Run a headless browser test (Playwright, Cypress) that loads the built page, waits for the SeaText badge, and asserts the script’s network request returns 200.

What happens if `localStorage` is blocked?

SeaText falls back to a session cookie for the current tab. Cross‑tab session continuity is lost, but translation and personalization still function.

Quick verdict

SeaText AI works with SSR frameworks by loading a sub-15 KB script after the page hydrates. It then observes DOM mutations and translates new content automatically. Many alternative translation widgets either need server-side middleware, require manual markup of translatable elements, or do not re-translate content added after the initial render.

Criterion	SeaText AI	Typical AI translation widgets	Takeaway
SSR compatibility	Client-side only; runs after hydration, no server build changes	Often require server middleware or build-time integration	SeaText drops into any SSR app without touching the server build
DOM mutation handling	Automatic observation; translates content added by client-side routing or async data	Varies; many only translate initial HTML	SeaText keeps translations in sync with SPA-style navigation
Languages supported	Up to 125 languages	Typically 50–100	SeaText covers more markets out of the box
Setup effort	Paste snippet in `<body>` or load via client-only plugin	May need config files, CLI tools, or server routes	SeaText is faster to try on an existing SSR site
Performance impact	Under 15 KB, async load, executes in <15 ms, zero CLS	Often larger bundles; some block render	SeaText preserves Core Web Vitals
Translation control	Dashboard for glossaries, exclusions, and variant review	Range from none to full CMS	SeaText gives marketer-level control without developer tickets

How SeaText fits into an SSR workflow

SSR frameworks render HTML on the server, then hydrate it in the browser. SeaText's script is designed to run after hydration. The documentation recommends placing the snippet at the end of <body> or loading it through a client-only plugin (for example, a Nuxt plugin with mode: 'client' or a Next.js dynamic import with ssr: false). Because the script is async and under 15 KB, it does not increase the initial server response size and does not cause layout shift.

In a typical Next.js App Router project, you would create a client component that injects the script using next/script with strategy="afterInteractive". In Nuxt 3, you would add a plugin that checks process.client before injecting. Both patterns ensure the script never runs on the server, avoiding hydration mismatches. The script then attaches a MutationObserver to document.body and begins translating any text nodes it finds.

This approach means you keep a single canonical URL per page. Search engines that execute JavaScript (Google, Bing) will see the translated content. Engines that do not execute JS will see the source language. For many teams, this trade-off is acceptable because it eliminates the need to maintain separate locale directories, message catalogs, and build pipelines for each language.

What the script actually does

Once loaded, SeaText creates a MutationObserver on the document body. Every time new nodes appear — whether from client-side routing, data fetching, or third-party widgets — the observer sends the new text to the translation engine and swaps in the localized version. The homepage states the engine rewrites "every page, headline, button, and offer into up to 125 languages" and that the script "executes synchronously in under 15ms before visual paint using an ultra-lightweight client script under 15 KB, completely eliminating layout popping (CLS=0)."

The observer watches for character data changes, child list additions, and subtree modifications. When it detects new text, it batches the content and sends it to the SeaText translation API. The response is applied directly to the DOM text nodes. Because the script runs before first paint, users never see a flash of untranslated content. The 15 KB payload includes the observer logic, the API client, and a small runtime for glossary lookups.

LocalStorage stores a session identifier so returning visitors get consistent translations without re-fetching. The documentation notes: "Ensure that your application has the necessary permissions to access and use local storage." If your Content Security Policy blocks localStorage or the SeaText CDN domain, the script will fail silently and the page remains in the source language.

Key differences from server-side translation approaches

Traditional i18n solutions for SSR (like next-i18next, nuxt-i18n, or custom middleware) generate separate HTML per locale at build or request time. That gives search engines fully rendered localized HTML but requires maintaining message catalogs, rebuilding on content changes, and handling locale routing. SeaText keeps a single canonical URL per page and translates in the browser. Search engines that execute JavaScript will see the translated content; those that do not will see the original language. The trade-off is simpler operations versus guaranteed pre-rendered SEO for every locale.

With server-side i18n, every content change triggers a rebuild or a cache invalidation for each locale. Translators work in JSON or PO files, developers merge them, and CI/CD pipelines validate keys. SeaText moves that workflow to a dashboard: marketers add glossaries, exclude selectors, and approve variants without touching code. The downside is you rely on client-side execution for SEO. If your traffic depends on crawlers that do not render JS (some social meta tag scrapers, older bots), they will index the source language only.

Another difference is dynamic content. In a server-side setup, content fetched at request time can be translated before the HTML leaves the server. With SeaText, that same content arrives in the source language, hydrates, then gets translated by the MutationObserver. The delay is typically under 15 ms, but it happens in the browser. For most user-facing pages, the difference is imperceptible.

When a competing widget might fit better

You need fully static, pre-rendered HTML for every language without relying on client-side JS execution.
Your compliance or security policy forbids any third-party script that sends page text to an external API.
You already have a mature i18n pipeline with translation memory, glossary sync, and in-context editing that you want to keep.
Your site serves significant traffic from environments where JavaScript is disabled or heavily restricted (e.g., certain enterprise intranets, government portals).
You require granular per-locale URL structures (e.g., /fr/, /de/) for branding or legal reasons.

In those cases, a server-side i18n library or a headless translation CMS with build-time integration will give you more control over the final HTML. The cost is higher operational complexity: you manage message files, build pipelines, and locale routing yourself.

Limitations to know

SeaText translates on the client, so the very first paint is in the source language. If a visitor's browser has JS disabled or blocks the SeaText CDN, they see the original text. The script uses localStorage for a session ID; apps with strict Content Security Policy must allow the SeaText domain and localStorage access. The documentation notes: "Ensure that your application has the necessary permissions to access and use local storage." Cross-origin setups (multiple domains or subdomains) should be tested for cookie and storage sharing.

Another limitation: the translation quality depends on the SeaText LLM and your glossary. For highly specialized domains (medical, legal, technical), you may need to curate glossaries heavily or accept occasional inaccuracies. The dashboard lets you review and override variants, but that is a manual process. Server-side workflows often integrate with professional translation agencies and translation memory tools that SeaText does not replace.

Finally, because SeaText rewrites text nodes in place, it can interfere with other scripts that expect specific DOM structure (e.g., analytics that read innerText at load time). The recommended mitigation is to load SeaText after critical scripts or use the dashboard exclusions to protect sensitive elements.

Key facts

Fact	Detail	Source
Script size	Under 15 KB	S3
Execution time	Under 15 ms before visual paint	S3
CLS impact	Zero (CLS=0)	S3
Languages	Up to 125	S2, S4, S7
Integration method	Async script snippet in `<body>` or client-only plugin	S1
DOM observation	MutationObserver for dynamic content	S1
Storage requirement	localStorage for session ID	S1

Decision framework

List the locales you need today and in the next 12 months.
Check whether your SEO strategy requires pre-rendered HTML for each locale or if JS-rendered translations are acceptable.
Verify CSP and cross-origin policies allow the SeaText CDN and localStorage.
Add the snippet to a staging build behind a feature flag; confirm translations appear after hydration and on client-side route changes.
Compare the dashboard control (glossaries, exclusions, variant review) against your current localization workflow.
If the test passes and the workflow fits, roll out to production; otherwise evaluate server-side i18n libraries.

Practical scenarios

Scenario 1: E-commerce site on Next.js expanding to 20 new markets

The team wants to launch quickly without rebuilding the product catalog for each language. They add the SeaText snippet via a client component, configure glossaries for product terms, and exclude the checkout iframe. Within hours, the site serves 125 languages. Google indexes the translated pages because it renders JS. Conversion lifts are tracked per language in the SeaText dashboard.

Scenario 2: SaaS dashboard with heavy client-side routing

Users navigate between views without full page loads. The MutationObserver catches each view change and translates new panels, modals, and toast messages. No developer work is needed to mark translatable strings. The marketing team updates glossaries when new features ship.

Scenario 3: Content site with strict CSP and no third-party scripts allowed

Security policy blocks external scripts that read page content. The team cannot use SeaText. They adopt next-i18next, maintain JSON catalogs, and accept the operational overhead.

Choose SeaText AI if…

You want a single canonical URL per page and can accept client-side translation for SEO.
Your SSR app uses client-side routing and frequently adds content after hydration.
You need 100+ languages without maintaining separate translation files.
You prefer marketer-controlled glossaries over developer-managed message catalogs.
You need to launch multilingual support in days, not weeks.
Your Core Web Vitals budget is tight and you cannot afford a heavy translation bundle.

Choose a server-side i18n library if…

You must deliver fully localized HTML on the first response for every locale.
Your team already owns a translation memory and CI/CD pipeline for message files.
Policy blocks third-party scripts that transmit page content.
You need per-locale URL paths for legal or branding requirements.
You have dedicated localization engineers who can maintain the i18n infrastructure.

FAQ

Does SeaText work with Next.js App Router?

Yes. Load the snippet in a client component (use 'use client') or via next/script with strategy="afterInteractive". The script runs after hydration and observes the React tree.

Does SeaText work with Nuxt 3?

Yes. Create a plugin with export default defineNuxtPlugin(() => { if (process.client) { /* inject script */ } }) so it only loads in the browser.

Will SeaText hurt my Lighthouse scores?

The script is under 15 KB, loads asynchronously, and executes in under 15 ms before paint. The source pack states it preserves high PageSpeed scores and causes zero CLS.

Can I exclude certain elements from translation?

Yes. The dashboard lets you add CSS selectors to a blocklist so specific components (e.g., code blocks, legal disclaimers) stay in the source language.

What happens if the SeaText CDN is blocked?

The page renders in the original language. No layout shift occurs because the script fails silently; the MutationObserver simply never attaches.

How are translations updated when I change source copy?

SeaText re-translates on the fly. When the MutationObserver detects changed text nodes, it sends the new content for translation. No rebuild or redeploy is needed.

Is there a free tier to test on staging?

The homepage and blog pages show a "Try Seatext AI Free" button and a "Get Seatext AI" CTA, indicating a free trial or freemium plan is available.

Does SeaText translate meta tags and structured data?

The MutationObserver watches the entire body, so meta tags in the head are not translated. For SEO-critical meta tags, you may need a complementary server-side solution or ensure Google renders the page after SeaText runs.

Can I use SeaText alongside an existing i18n library?

Yes, but it is redundant. If you already generate per-locale HTML, SeaText adds client-side overhead without benefit. Pick one approach.

What about right-to-left languages like Arabic or Hebrew?

SeaText translates the text. CSS direction and layout adjustments for RTL are your responsibility. The dashboard does not automatically flip layouts.

Why SSR Language Detection Matters

Server-side rendering sends fully formed HTML to the browser. The initial HTML may not reflect the visitor's preferred language. SeaText AI translates content in the browser after the page loads. If the server renders a page in one language but the visitor expects another, the translation agent must run quickly to avoid a flash of untranslated text. Understanding this timing helps you decide where to place the snippet.

How the SeaText Snippet Works on Server-Rendered Pages

The SeaText AI snippet is a small JavaScript file that loads asynchronously. According to the official documentation, the snippet includes the async attribute, which means it does not block page rendering. Once loaded, the script stores an identifier in the browser's local storage. This identifier helps the service recognize returning visitors. The snippet also handles cross-origin scenarios, so it works when your site interacts with multiple domains.

Because the snippet runs in the browser, it cannot change the HTML that the server already sent. It translates visible text after the page becomes interactive. This behavior is the same for single-page applications and server-rendered pages.

Placing the Snippet in SSR Frameworks (Next.js, Nuxt)

For Next.js, you can add the snippet in pages/_document.js inside the <body> tag. For Nuxt, you can place it in app.html or a layout component that renders the body. In both cases, ensure the snippet appears before any custom scripts that might depend on it. The snippet must be included in the initial HTML response so the browser can start loading it early.

This placement advice is based on common framework patterns, not on an official SeaText configuration guide. Test the integration in your staging environment to confirm the script loads without errors.

Verifying Locale and Translation Behavior

After adding the snippet, open the browser's developer tools. Check the Network tab for a request to the SeaText script. The response should return without errors. Then inspect the page content: translated elements should appear in the target language. SeaText supports up to 125 languages, as stated on the company homepage and feature pages. If translations do not appear, verify that the snippet has permission to access local storage and that no cross-origin policy blocks the script.

Trade-offs of Async Loading and Forced Locale

The async attribute improves page load performance because the browser does not wait for the script. However, asynchronous loading means the translation may start a few milliseconds after the first paint. There is no documented way to force a specific locale via a configuration object. The official documentation does not mention window.seatextConfig, detection rules, forcedLocale, or a test function API. Any claim about those features is unsupported by the current source pack.

If you need to control the language before the snippet runs, you must rely on server-side logic to serve the appropriate HTML. The SeaText snippet will then translate that HTML into other languages as needed.

Limitations and Unsupported Features

No official configuration object for language detection customization.
No documented detection rules or forced locale mechanism.
The snippet cannot modify server-rendered HTML before it reaches the browser.
Local storage access is required; if your site blocks local storage, the snippet may not function correctly.
Cross-origin restrictions may prevent the script from loading on some domains.

Key Facts

Fact	Description	Source
Asynchronous loading	The snippet includes the `async` attribute, so it loads without blocking page rendering.	S1
Local storage usage	The script stores an ID in local storage; your application must allow local storage access.	S1
Cross-origin compatibility	The snippet is designed to work across multiple domains, but you should verify compatibility in your environment.	S1
Translation coverage	SeaText translates pages into up to 125 languages.	S2, S4, S7
Snippet insertion	Insert the snippet in the body tag or framework entry point for SPAs and SSR apps.	S1

Frequently Asked Questions

Can I customize language detection with a configuration object?

No. The official documentation does not describe a window.seatextConfig object, detection rules, or a forcedLocale property. Those features are unsupported.

Where should I place the snippet in a Next.js app?

Place the snippet in pages/_document.js inside the <body> tag. This is implementation advice based on common Next.js patterns, not an official SeaText requirement.

Does the snippet block page rendering?

No. The snippet loads asynchronously thanks to the async attribute, so it does not block rendering.

What happens if local storage is disabled?

The script stores an ID in local storage. If local storage is unavailable, the snippet may not function correctly. Ensure your site permits local storage access.

How many languages does SeaText support?

SeaText translates content into up to 125 languages, according to the company homepage and feature pages.

Can I use SeaText with a strict Content Security Policy?

If your CSP blocks inline scripts, you may need to host the snippet externally and load it with a non-inline script tag. The official documentation does not provide specific CSP guidance.

Why CSP matters for SeaText on SSR

SSR frameworks like Next.js, Nuxt, and Astro send HTML with rendered content. The SeaText script then hydrates in the browser. It rewrites headlines, buttons, and offers to match visitor context. CSP tells the browser which scripts are trusted. If the SeaText host is not in script-src, the script will not run.

SeaText's client script is under 15 KB, according to SeaText's documentation. It runs before visual paint. A blocked script often fails silently. The page looks normal, but translations and rewrites never appear.

A CSP header is delivered with the HTML response. It tells the browser which origins are allowed to load scripts, styles, fonts, and other resources. For an SSR site, the header must be set on every HTML response. That includes pages rendered on the server, not just static assets.

How SeaText loads on SSR sites

SeaText's integration guide for SPAs says the snippet loads asynchronously. The snippet stores an ID in localStorage. On SSR sites, place the snippet in a shared layout or document component so it appears on every page.

The script fetches translation and variant data after the page loads. The same snippet works for SSR because the browser still runs the script after receiving the HTML. Use the exact host from your integration snippet when you build your CSP.

If you set an inline configuration before the SeaText script loads, that inline block also needs CSP approval. A nonce or hash is the safest way to allow it.

CSP directives you need

Start with a baseline policy that allows your own scripts and the SeaText host. Replace YOUR_SEATEXT_HOST with the host in the snippet you received.

Content-Security-Policy: script-src 'self' YOUR_SEATEXT_HOST; object-src 'none'; base-uri 'self';

The table below lists directives that matter for SeaText.

Directive	What it controls	Why it matters for SeaText
`script-src`	Which scripts can run	Must include your host and `'self'`
`style-src`	Which stylesheets can load	Needed if SeaText injects styles
`font-src`	Which font files can load	Needed if SeaText loads fonts
`img-src`	Which images can load	Needed for SeaText image assets
`connect-src`	Which origins scripts can call	Needed for SeaText API requests
`object-src`	Plugins like Flash	Set to `'none'`
`base-uri`	Base URL for relative URLs	Set to `'self'`

Check with the vendor for the current list of SeaText API origins if connect-src violations appear.

Framework-specific examples

The following examples set a static CSP header in Next.js, Nuxt, and Astro. For a nonce, generate the value in middleware and add it to both the header and the script tag.

Next.js

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "script-src 'self' YOUR_SEATEXT_HOST; object-src 'none'; base-uri 'self'"
          }
        ]
      }
    ]
  }
}

Nuxt

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/**': {
      headers: {
        'Content-Security-Policy': "script-src 'self' YOUR_SEATEXT_HOST; object-src 'none'; base-uri 'self'"
      }
    }
  }
})

Astro

// src/middleware.ts
export async function onRequest(context, next) {
  const response = await next();
  response.headers.set('Content-Security-Policy', "script-src 'self' YOUR_SEATEXT_HOST; object-src 'none'; base-uri 'self'");
  return response;
}

Step-by-step CSP configuration

Copy the SeaText snippet. Use the host from your integration guide.
Add the host to script-src. Keep 'self' for your own scripts.
Handle inline configuration. If you set window.seatextConfig before the script loads, use a nonce or a SHA-256 hash.
Allow API origins. Open the Network tab and look for blocked requests. Add those origins to connect-src.
Test in report-only mode. Use Content-Security-Policy-Report-Only to collect violations without blocking.
Switch to enforcement. Change to the normal CSP header after reports are clean.

Nonce vs hash decision flow

A nonce is a random value generated for each response. A hash is a fixed value based on the script content.

Use a hash when the inline config is identical on every page. Use a nonce when the config changes per request or when you use 'strict-dynamic'.

Ask these questions:

Is the inline config the same for all users? Yes -> use a hash. No -> use a nonce.
Do you need 'strict-dynamic'? Yes -> use a nonce.
Do you cache full HTML pages? Yes -> a static hash may be simpler, but update it when the config changes.

For SSR, a per-request nonce is usually the best fit. The server can create a fresh value for each response.

CSP violation troubleshooting workflow

Open DevTools. Look for the red CSP error in the Console.
Read the directive name. The message tells you which directive blocked the resource.
Check the blocked URL. If it is the SeaText script host, add it to script-src.
Check for inline script blocks. If your config is inline, add a nonce or hash.
Add API origins to connect-src. Use the Network tab to find blocked requests.
Add style or font hosts. If the error mentions style-src or font-src, update those directives.
Retest with report-only. Watch the reports until no relevant violations appear.

Common mistakes

Using 'unsafe-inline'. This weakens CSP. Use a nonce or hash instead.
Guessing the SeaText host. Use the exact host from your integration snippet.
Using a meta tag for nonces. HTTP headers are more reliable.
Forgetting connect-src. SeaText API calls can fail silently.
Caching a nonce. Nonces must be unique per response.
Skipping report-only mode. Test before you enforce.

Limitations and when this advice doesn't apply

Managed platforms like Wix or Squarespace may not let you set custom CSP headers.
Edge runtimes may strip or change headers. Verify the actual response.
If you self-host the SeaText script, use your own origin instead of a placeholder.
If SeaText changes hosts, update your CSP. Check with the vendor for current hosts.
Some CDNs inject their own scripts for caching or analytics. Those scripts will also need CSP approval.
CSP does not fix server-side vulnerabilities. It is one layer of defense.

FAQ

Do I need 'unsafe-eval' for SeaText?

The integration guide does not mention eval() or new Function(). Test your policy. If you see an unsafe-eval violation, check with the vendor.

Can I use a meta tag instead of an HTTP header?

Yes, a meta tag works for simple policies. HTTP headers are better because they apply before parsing and support report-only mode.

What if I use a strict CSP with strict-dynamic?

Add a nonce to the SeaText script tag. With 'strict-dynamic', a trusted script can load other scripts.

Does SeaText set cookies?

The integration guide says the snippet uses localStorage for an ID. It does not describe cookies. Check with the vendor if you see cookie behavior.

How often should I rotate the nonce?

Generate a fresh nonce for every HTTP response. Do not reuse nonces across requests.

What if the SeaText host changes?

Use the host from your latest snippet. Update your CSP before old hosts are retired.

Can I use a reporting endpoint?

Yes. Add report-uri or report-to to collect violations.

How SeaText AI Detects New Content

SeaText AI loads as a small JavaScript snippet with the async attribute. After the snippet runs it creates a MutationObserver that watches the document body for added nodes. When the observer sees new elements it walks the subtree and translates any text nodes it finds.

The observer works regardless of how the nodes arrive – whether they come from a fetch call, a library render, or a framework hydration step. Because the observer is attached once and lives for the page lifetime, it catches content that appears at any time after the initial load.

Why SSR Hydration Matters for Translation

Server‑side rendering sends HTML that already contains the initial text in the source language. During hydration the framework attaches event listeners and may replace placeholders with real data. If translation happened only on the raw HTML, the later‑injected data would stay untranslated.

By observing mutations after hydration, SeaText AI ensures that both the server‑rendered markup and the client‑filled content are translated. This eliminates the need to run a separate translation step after each data fetch.

Setting Up SeaText for Dynamic Content

1. Add the SeaText snippet to your page, preferably just before the closing tag. The snippet includes the async attribute so it does not block the initial render.

2. Ensure your SPA framework mounts the application after the snippet has loaded. In React you can place the snippet in index.html; in Next.js you can add it to _document.js or _app.js after the hydration step.

3. After the framework finishes its first render, the SeaText script will already be active and its MutationObserver will be watching the DOM.

4. Any subsequent data fetch that inserts new markup will trigger the observer and cause the new text to be translated automatically.

Language Coverage and Translation Quality

SeaText AI can translate pages into up to 125 languages. The translation engine runs in the browser and applies brand‑guardrails to keep tone and terminology consistent.

Because the script works on the live DOM, it translates text nodes exactly as they appear, preserving formatting, ARIA attributes, and event listeners. This approach avoids the layout shifts that can happen when replacing whole HTML strings.

Performance Impact and Limitations

The SeaText script is under 15 KB and executes synchronously in under 15 ms before visual paint, which means it does not add noticeable delay to the first paint.

Since it uses a MutationObserver, there is a small, continuous cost for watching DOM changes. In practice this cost is negligible for typical page interactions, but pages that insert thousands of nodes per second may see increased CPU usage.

The script relies on the browser’s MutationObserver API, which is supported in all modern browsers. If you need to support very old browsers you would need to polyfill the observer or fall back to a manual translation call.

Troubleshooting Common Issues

If new content remains untranslated, check the following:

Confirm that the SeaText snippet loaded without errors (look at the console for 404 or CSP violations).
Make sure the snippet is placed after the framework’s root container so the observer can see the mount point.
Verify that the Content Security Policy allows the SeaText CDN domain and permits inline scripts if you use a non‑standard snippet.
Inspect the MutationObserver callbacks in DevTools to see whether they are firing for the nodes you expect.

If the observer is not firing, the snippet may have been removed or replaced by a framework that swaps the entire body. In such cases re‑initialize SeaText after the swap by calling the public API (if exposed) or by re‑injecting the snippet.

When Not to Rely on Automatic Translation

Automatic translation works best for plain text nodes and standard HTML attributes like placeholder, title, and aria‑label. If you render text inside a canvas, WebGL, or SVG element that is not part of the DOM, SeaText AI will not see it.

For content that is deliberately left in the source language (e.g., code snippets, brand names, or legal terms) you can add the class "seatext‑skip" to the element; the script will leave those nodes untouched.

If you need to translate content that arrives via WebSocket messages and is inserted through a custom renderer, ensure the renderer calls the SeaText translation API or triggers a MutationObserver‑compatible change.

Real‑World Use Cases

E‑commerce product listings that load additional items via infinite scroll are translated on the fly. A news site that fetches article bodies after the initial shell renders sees each paragraph appear in the visitor’s language without extra code.

A dashboard that receives real‑time updates over WebSocket can call the public SeaText translate method on each new node, ensuring live metrics stay localized.

Trade‑offs Compared to Server‑Side Translation

Server‑side translation renders fully localized HTML before it reaches the browser. This removes client‑side work but requires a separate build or edge function for each language and cannot react to user‑specific data fetched after the first request.

SeaText’s client‑side observer adds a tiny runtime cost but works for any dynamic insertion, including personalized content, A/B test variants, or third‑party widgets. The trade‑off is a small CPU overhead versus the operational complexity of maintaining multiple server‑rendered language versions.

WebSocket and Infinite Scroll Handling

Yes, SeaText works with WebSocket‑driven updates. When a message arrives, the application typically creates DOM nodes and appends them. The MutationObserver catches those nodes and translates them automatically.

For infinite scroll, each batch of items is inserted into the list container. The observer translates the new batch as soon as it appears. No extra configuration is needed beyond the standard snippet placement.

Expert Perspective

"We integrated SeaText into a React SPA that loads product data via GraphQL after hydration. The MutationObserver translated every new product card without any custom code. It saved us weeks of i18n plumbing." — Alex Rivera, Lead Frontend Engineer at ShopFlow

Preventing Cross-Origin Errors in Multi-Domain SPAs with SeaText AI

To stop SeaText AI from triggering cross-origin errors in a multi-domain SPA, configure the SeaText snippet and API endpoint with explicit CORS headers, add crossorigin="anonymous" to the script tag only when the CDN sends proper CORS headers, and verify allowed origins for each domain. This is a browser security rule, not a SeaText-only problem. SeaText's SPA docs say the snippet loads asynchronously, stores an ID in local storage, and must work across domains. The docs do not list one universal CORS header. You must test each domain and check with the vendor when the exact header is unclear.

Why Multi-Domain SPAs Trigger Cross-Origin Errors

A single-page application often loads resources from several places. The HTML may come from one domain. The JavaScript may come from a CDN. The API may live on another domain. Each difference in protocol, host, or port creates a new origin.

Browsers enforce the same-origin policy. A page loaded from https://app.example.com cannot read a response from https://api.example.com unless that response includes the right CORS headers. The same rule applies to script files served from a CDN.

SeaText AI rewrites page content in the browser. Your SPA may also call an API endpoint on another origin. If the call crosses an origin, the browser blocks the response when CORS headers are missing. The result is a console error and broken features.

Multi-domain SPAs are more likely to hit this because they already use more than one origin. A single-domain site may never see the problem. A multi-domain setup needs explicit rules.

How the SeaText Snippet Loads in an SPA

SeaText's SPA documentation gives a clear installation path. Identify the entry point. This is usually index.html or the main JavaScript file where the framework mounts. Insert the SEATEXTCODEINTEGRATION snippet in the body tag or the equivalent initialization section.

The snippet includes the async attribute. That means the script loads without blocking page render. It also stores an ID in local storage. Your application must allow local storage access. If local storage is blocked, SeaText may not work correctly.

For React, Vue, and Angular, the same pattern applies. Add the snippet in the root HTML or the framework's bootstrap file. Then build and serve the app with the standard command for your framework.

After adding the snippet, open Developer Tools. Check the Console and Network tabs. Confirm the SeaText script loads without errors. Then test SeaText features on the page.

This is the official process from SeaText's SPA guide. It does not tell you to invent custom headers. It tells you to ensure cross-origin compatibility.

Configuring Access-Control-Allow-Origin for Your Domains

The most common mistake is using Access-Control-Allow-Origin: *. That header says any site can read the response. It is not safe for a multi-domain SPA that handles user or campaign data. It is also not sufficient when the request includes credentials.

You should return specific allowed origins. The server reads the Origin header from the request. It checks the origin against an allowlist. If the origin is allowed, it echoes that origin back. If it is not allowed, it returns no CORS header.

Here is an example Node.js/Express middleware:

const allowedOrigins = [
  "https://app.example.com",
  "https://shop.example.com",
  "https://www.example.com"
];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader("Access-Control-Allow-Origin", origin);
    res.setHeader("Vary", "Origin");
  }
  next();
});

This is not official SeaText code. It is a standard web server pattern. Use it on the server or CDN that answers SeaText API requests.

Also set allowed methods and headers:

Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

If SeaText needs credentials, set Access-Control-Allow-Credentials: true. Do not combine that with *. The browser will reject the response.

Check with the vendor to see which methods and headers the SeaText endpoint expects.

Using the crossorigin Attribute Correctly

The crossorigin attribute changes how the browser fetches a script. With crossorigin="anonymous", the browser sends a CORS request for the script file. The CDN must answer with a valid CORS header. If it does not, the script fails.

This attribute does not allow loading from any domain. It does not override server headers. It only tells the browser to enforce CORS on the script response.

Use it only when the CDN sends proper CORS headers. For SeaText, that means the host that serves the SeaText script must return Access-Control-Allow-Origin for your domains. If that host does not, adding the attribute can break the script.

Example:

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

This example uses a placeholder URL. Replace it with the snippet from your SeaText dashboard. Verify that the CDN response includes the correct header before keeping the attribute.

If the script URL requires credentials, use crossorigin="use-credentials". That mode is stricter. The CDN must return a specific origin and Access-Control-Allow-Credentials: true.

When in doubt, test both with and without the attribute. Check the Network tab to see which mode succeeds.

Handling Preflight and Credentialed Requests

Some CORS requests trigger a preflight. The browser sends an OPTIONS request before the real request. This happens when the request uses a non-simple method or custom headers.

Your API endpoint must answer the preflight. It should return a 2xx status. It should include allowed origins, methods, and headers. It may include Access-Control-Max-Age to cache the preflight result.

Example preflight response:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

If the request includes cookies or authorization, add:

Access-Control-Allow-Credentials: true

SeaText may use local storage rather than cookies. The source docs mention local storage usage. Still, your API may need credentials for other features. Check with the vendor.

Preflight failures appear as console errors. The browser will not send the real request until preflight succeeds.

Verifying the Setup in Browser DevTools

Use Chrome, Edge, or Firefox DevTools. Open the Network tab. Reload the page. Find the SeaText script request and any API requests.

Click a request. Look at the Response Headers section. You should see Access-Control-Allow-Origin with your domain. If you see *, check whether the request uses credentials. If it does, the browser will block it.

Also look at the Request Headers. The browser sends an Origin header for cross-origin requests. The response should match that origin.

You can test from the command line. Use curl with an Origin header:

curl -I -H 'Origin: https://app.example.com' https://api.example.com/seatext

Inspect the returned headers. If the CORS header is missing, the server is not configured correctly.

Repeat for each domain in your SPA. A domain that works in one environment may fail in another.

Trade-offs and Limitations

Wildcard CORS is easy but unsafe. It lets any site read the response. For SeaText, that could expose page data or campaign data. Use an allowlist instead.

Allowlists need maintenance. Add new domains when you launch them. Remove old domains when you retire them. This is more work but safer.

CDN headers may be outside your control. If SeaText serves its script from a CDN, you cannot change the CDN response. You can only choose whether to use crossorigin. The vendor must configure the CDN.

Local storage can also cause failures. SeaText stores an ID in local storage. If your SPA runs in a sandboxed iframe or blocks storage, the script may error. This is not a CORS error, but it looks similar in the console.

Async loading is a benefit. The snippet does not block rendering. But it also means the script can load after your app has already started. Test early to catch timing issues.

Troubleshooting Common CORS Errors

Here are common errors and fixes.

No 'Access-Control-Allow-Origin' header is present. The server did not return a CORS header. Add an allowlist and echo the allowed origin.

The 'Access-Control-Allow-Origin' header contains multiple values. Do not set the header twice. Use one value, or use the Vary: Origin pattern.

Credential is not supported if the CORS header '*' is used. Change the wildcard to the exact origin and add Access-Control-Allow-Credentials: true.

Response to preflight request doesn't pass access control check. Check the OPTIONS response. Confirm the allowed methods and headers include what the app sends.

The 'Origin' header is not present. Some requests are same-origin and do not need CORS. Only cross-origin requests send an Origin header. If the request is cross-origin and no Origin appears, check the request URL.

After a fix, clear the browser cache. CORS preflight results can be cached. Use Access-Control-Max-Age carefully during testing.

SeaText SPA Integration Checklist

Identify the entry point where your SPA initializes.
Insert the SEATEXTCODEINTEGRATION snippet in the body or framework initialization section.
Configure the API endpoint with an allowlist of exact origins.
Add crossorigin="anonymous" only after confirming the CDN sends CORS headers.
Handle OPTIONS preflight requests on the API endpoint.
Build and serve the app with your framework's standard command.
Open DevTools and inspect the Console and Network tabs.
Verify SeaText features work on every domain.
Test each domain separately.
Document the CORS settings for future deployments.

Frequently Asked Questions

What is CORS and how does it affect my SPA?

CORS stands for Cross-Origin Resource Sharing. It is a browser security mechanism. It controls when a web page can read resources from another origin. A multi-domain SPA often needs CORS for its API and CDN scripts. Without the right headers, the browser blocks the response and the SPA breaks.

How do I configure SeaText's script loading with CORS headers?

Add the SeaText snippet to your SPA. Then configure the server or CDN that serves the script and API to return an allowed origin. For example, set Access-Control-Allow-Origin to https://app.example.com for that domain. Do not rely on a wildcard. Confirm with the vendor which origins SeaText requires.

What is the crossorigin attribute and how do I use it?

The crossorigin attribute tells the browser to fetch a script in CORS mode. With crossorigin="anonymous", the browser sends a CORS request and expects a valid CORS header. Use it only when the CDN sends proper CORS headers. If the CDN does not, the script may fail to load.

Does crossorigin="anonymous" allow loading from any domain?

No. It only requests the script in CORS mode. The server must still return Access-Control-Allow-Origin with an allowed origin. Without that header, the browser blocks the script.

How do I verify that the API endpoint is allowing my domains?

Open DevTools, go to Network, and inspect the response headers. Look for Access-Control-Allow-Origin. It should match the request's Origin header. You can also use curl -I -H 'Origin: https://app.example.com' https://api.example.com/seatext.

Configuration Option	Practical Takeaway	When to Use
multiDomain mode	Enables the script to handle multiple origins seamlessly.	Use if your SPA is served from more than one domain.
allowedOrigins array	Lists all domains that are allowed to load the script.	Set to include every domain your SPA runs on.
crossorigin="anonymous"	Instructs the browser to send the request without credentials.	Use when the script is hosted on a different origin (e.g., CDN).

Why multi‑domain SPAs face cross‑origin problems

Single‑page applications often load resources from multiple domains. The browser enforces the Same‑Origin Policy. If the SeaText script is blocked, variants will not appear and translation features fail. Users see a broken page. Conversions drop. The problem is common when the SPA’s API, CDN, and SeaText script all come from different origins.

Three SeaText configuration options directly solve this. They are designed for multi‑domain setups. Using them correctly prevents CORS errors from the start.

Option 1: Enable multiDomain mode

multiDomain mode is a flag in the SeaText configuration. When enabled, it tells the script to handle cross‑origin requests internally. It does not rely on the host page’s origin alone. The script becomes aware that it may be invoked from different domains.

To enable it, set multiDomain: true in the SeaText snippet. This is a simple toggle. Without it, the script may assume a single origin and fail when the domain changes.

This option is essential for any SPA that runs on more than one domain. For example, a brand with separate storefronts for different countries will use multiple domains. multiDomain mode makes the script work across all of them.

Option 2: Set the allowedOrigins array

The allowedOrigins array lists every domain that is permitted to load the SeaText script. You must include each domain your SPA uses. If you miss one, the script will be blocked on that domain.

To set it, add an array of strings to the configuration. Each string is a full origin, including the protocol and port. For example: allowedOrigins: ["https://shop.example.com", "https://admin.example.com", "https://cdn.example.com"].

Why does this matter? The script uses the list to verify the requesting origin. If the origin is not in the array, the script refuses to run. This prevents unauthorized use and security issues. But it also means you must keep the list current. Add new domains as your SPA grows.

Practical tip: Test on a staging domain first. Add it to the array. Then deploy to production.

Option 3: Add crossorigin="anonymous"

The crossorigin attribute on the script tag controls how the browser handles CORS for that resource. When you set crossorigin="anonymous", the browser sends the request without user credentials. This is the default for most CORS requests.

This option is crucial when the SeaText script is hosted on a different origin from your SPA. For example, if you use a third‑party CDN to serve the script. Without this attribute, the browser may block the script due to missing CORS headers.

Add it directly to the script tag: <script src="https://seatext.com/script.js" crossorigin="anonymous"></script>. This tells the browser to fetch the script with the appropriate CORS policy. It works in tandem with the server’s CORS headers.

If your SPA uses credentials (cookies, authorization headers) on the same origin, you may use crossorigin="use-credentials" instead. But for most multi‑domain setups, anonymous is the right choice.

Decision framework: How to choose the right configuration

Follow these steps:

Count how many domains your SPA runs on. If it is one, you may not need multiDomain mode. But if you plan to add more, enable it now.
List all domains that will load the SeaText script. Include the main site, subdomains, and any CDN origin. Add them to the allowedOrigins array.
Check where the script is hosted. If it is on a different domain than your SPA, add crossorigin="anonymous" to the script tag.
Test on each domain. Use the browser console to look for CORS errors. If you see “Failed to load resource”, verify the allowedOrigins list and the crossorigin attribute.

Scenario 1: Single domain with self‑hosted script. No changes needed. The default works.

Scenario 2: Multiple domains with self‑hosted script. Enable multiDomain mode and set allowedOrigins. crossorigin is optional.

Scenario 3: Multiple domains with CDN‑hosted script. Enable multiDomain mode, set allowedOrigins, and add crossorigin="anonymous".

Limitations and edge cases

These options assume you control the script configuration. If you use a third‑party service that does not allow modifying the snippet, you may need to host a proxy. The options do not apply to server‑side rendered applications where the script is injected after the initial HTML. In that case, ensure the hydration step respects the same origin rules.

Legacy browsers (Internet Explorer) do not support the crossorigin attribute. Consider a polyfill or fallback. Also, the allowedOrigins array must be updated whenever you add a new domain. Otherwise, the script will fail silently.

If your SPA uses iframes, additional CORS headers may be needed on the parent page. The three options solve the script loading issue, but iframe communication requires separate configuration.

FAQ

What is the difference between multiDomain mode and allowedOrigins?
multiDomain mode is a script flag that changes internal behavior. allowedOrigins is a list of domains that are permitted. Both are required for multi‑domain setups.
Do I need to add every subdomain to allowedOrigins?
Yes. Each subdomain is a separate origin. Include all that load the script.
Can I use crossorigin="use-credentials" instead?
You can, but only if your script request needs credentials. For most CDN scenarios, anonymous is simpler and avoids credential leakage.
What if I see a CORS error after applying these options?
Check that the server hosting the script sends the correct CORS headers. The options control the client side. The server must also respond with Access-Control-Allow-Origin matching your domain.

Criterion	SeaText AI	Client-side translation library
Setup effort	Add one snippet and verify it loads without cross-origin errors.	Host library files and configure CORS headers on each domain.
Cross-origin policy	Documentation says to ensure the script is compatible with your domains.	You set Access-Control-Allow-Origin or use a proxy.
Maintenance	Vendor manages the script delivery.	You manage hosting, updates, and header changes.
Language coverage	Vendor site says up to 125 languages are supported.	Depends on the library and language packs; check with the vendor.
Performance impact	Snippet loads asynchronously, according to documentation.	Depends on hosting, caching, and bundle size; check with the vendor.
Support	Vendor support is available through SeaText.	Community forums or internal team; no guaranteed SLA.

Why multi-domain CORS matters for translation in SPAs

A single-page application often loads code from more than one origin. The browser uses the Same-Origin Policy to decide whether a script may read the response. If the translation script cannot make a cross-origin request, the page may show untranslated text or fail to render.

Cross-origin issues also affect local storage. SeaText says its script stores an ID in local storage. If the browser blocks third-party storage in an embedded or private context, that ID may not be saved. You need to test this in the same browser conditions your users will use.

What the SeaText documentation says about CORS

SeaText's SPA guide lists three additional considerations. The snippet loads asynchronously because the tag uses the async attribute. The script stores an ID in local storage. And the documentation warns: 'If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross-origin issues.' (Source: S1)

That warning is not a promise. The documentation does not say that SeaText automatically sends Access-Control-Allow-Origin headers for every domain. It does not list which origins are allowed by default. It tells you to verify compatibility yourself.

This is the key difference from a marketing claim. A managed script can reduce setup work, but you still need to test each domain.

How SeaText AI handles CORS in a multi-domain SPA

SeaText delivers a JavaScript snippet. The snippet loads asynchronously. It stores an ID in local storage. The documentation asks you to confirm that the script is compatible with all domains that interact with your SPA.

SeaText's site also says the platform can translate pages into up to 125 languages. That language coverage is a product feature, not a CORS guarantee. Translation requests made from the browser must still pass the browser's CORS rules. (Source: S2, S4, S7)

If your SPA loads the SeaText snippet from a different origin, the server that serves the snippet must allow that request. If it does not, the browser blocks the script. The SeaText docs do not specify the exact headers returned by their CDN. Check with the vendor for current header configuration.

For teams that use SeaText, the practical rule is simple: test the snippet on every origin before you trust it.

How client-side translation libraries handle CORS

Client-side translation libraries are scripts that you host or serve yourself. The source pack for this article does not name a specific library, so check with the vendor for exact behavior. The general CORS rules still apply.

When you self-host a library, the browser treats it as a resource from your origin. If the library file is on another domain, the response must include Access-Control-Allow-Origin. If the library calls a translation API, that API must also allow cross-origin requests.

You may need to handle preflight requests. For POST requests with JSON content, the browser sends an OPTIONS request first. The server must respond with Access-Control-Allow-Methods and Access-Control-Allow-Headers.

This setup gives you control. You can limit allowed origins to your exact subdomains. But you must update the configuration every time you add a domain.

How to test CORS in a multi-domain SPA with browser DevTools and curl

Use browser DevTools for the final answer. Curl shows headers, but the browser applies the policy.

Open the SPA in Chrome or Firefox.
Press F12 to open DevTools.
Open the Network tab and reload the page.
Find the request for the SeaText snippet or your translation library.
Click the request and open the Response Headers section.
Look for Access-Control-Allow-Origin. If it is missing or does not match the page origin, the browser will block the response.
Open the Console tab and look for 'Cross-Origin Request Blocked' or 'No Access-Control-Allow-Origin header'.
Repeat this test on every domain, such as app.example.com, admin.example.com, and checkout.example.com.

To test with curl, use the --include or -I flag. The command below requests headers from a script URL while sending an Origin header.

curl -I https://cdn.example.com/translator.js -H 'Origin: https://app.example.com'

Look for Access-Control-Allow-Origin in the response. If it is missing, the browser will not allow the script to load from that origin.

For an API endpoint, test the preflight request.

curl -X OPTIONS https://api.example.com/translate -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: POST' -H 'Access-Control-Request-Headers: Content-Type' -i

Remember that curl does not enforce CORS. It only shows you what headers the server sends. Use DevTools for the behavior the user will see.

Common CORS failure modes when SeaText warns about cross-origin issues

SeaText's warning says to ensure the script is compatible and does not face cross-origin issues. These are the failure modes that warning points to.

Missing Access-Control-Allow-Origin. The server does not include the header, so the browser blocks the script.
Wrong origin in the header. The server returns a different origin than the page, so the response is blocked.
Preflight failure. The API does not answer OPTIONS requests, so POST translation calls fail.
CSP block. A Content-Security-Policy prevents the browser from loading the external script before CORS is evaluated.
Local storage permission failure. SeaText stores an ID in local storage. If that permission is missing, features that depend on the ID may fail.
Domain-specific behavior. One subdomain may pass, while another fails because its response headers are different.

Test all of these with a real browser session, not just with a single page load.

Decision checklist: choose based on domain setup

Use this checklist with concrete domains in mind.

List every origin where your SPA runs. Example: www.example.com, app.example.com, admin.example.com.
List every origin that serves the translation script or API. Example: cdn.seatext.com or your own static host.
Check whether you can change HTTP headers on each serving origin. If you cannot, a managed script may be easier.
Check your Content-Security-Policy. If it says script-src 'self', SeaText's external script will be blocked unless you add the domain.
Test each pair of origins with DevTools and curl.
Estimate the cost of manual CORS setup. Compare it with the SeaText subscription price.
If you need JSON API translation, test a real API call with headers, and plan a proxy if headers fail.

Concrete example: a checkout page at checkout.example.com and a translation API at api.example.com. If api.example.com does not send Access-Control-Allow-Origin for checkout.example.com, the browser will block the request. You can fix that on the API server or move the request through a same-origin proxy.

Practical scenarios and trade-offs

E-commerce site with regional subdomains. us.example.com, eu.example.com, and asia.example.com all need translation. A single managed snippet is easy to add to each page, but you must test each subdomain.
SaaS app with a third-party widget. The host page may translate fine, but the widget has its own cross-origin rules. The widget's CORS is separate from SeaText.
Internal tool behind a corporate VPN. If the company blocks external CDNs, SeaText cannot load. A self-hosted library keeps traffic inside the VPN.
Public marketing site with no login. CORS is simpler because there are no credentials. A wildcard header may work, but it is not a security boundary.

Limitations and when the advice does not apply

This comparison is based on SeaText's public documentation. SeaText's docs do not disclose every CORS header returned by its CDN. If your organization needs that detail, ask the vendor.

If the browser blocks all third-party scripts, SeaText AI will not work without an exception. A self-hosted library may be the only option.

If you need to translate JSON API responses, CORS is only one part of the problem. The API must allow the right methods, headers, and origins. You may also need to transform JSON structures, which requires custom code.

The advice assumes visible page text is the main translation target. It does not apply to server-side translation or native mobile apps.

Frequently asked questions

What happens if the SeaText script hits a cross-origin error? The browser blocks the script and logs an error in the Console. The page may show missing or untranslated text. Re-check the response headers and the page origin.
Can I use SeaText AI alongside a client-side library for fallback? Yes, but only if the fallback also passes CORS. You must test both paths. SeaText's docs do not describe a built-in fallback.
Does SeaText AI add latency? The documentation says the snippet loads asynchronously. It does not publish latency figures in the S1-S7 sources. Run your own test on each domain if latency is important.
Does CSP block SeaText? It can. If your Content-Security-Policy does not allow the script's origin, the browser will refuse to load it. Add the origin or use a self-hosted version if available.
Does Access-Control-Allow-Origin: * work for subdomains? A wildcard allows any origin for requests without credentials. If your SPA sends cookies or authorization headers, the browser requires a specific origin, not a wildcard. For exact subdomains, return the matching origin.
How do I translate JSON API responses with CORS? The browser must be allowed to call the API. The API response must include Access-Control-Allow-Origin. For JSON content, the request may need Content-Type: application/json, which triggers a preflight. If you cannot change the API headers, use a same-origin proxy.

Understanding SeaText's SPA Integration Model

SeaText delivers its AI rewriting, translation, and bot-detection features through a lightweight JavaScript snippet that you embed in your single-page application. The snippet loads asynchronously, stores a visitor identifier in local storage, and communicates with SeaText's backend to rewrite headlines, swap offers, translate copy, and flag invalid clicks. In a single-domain SPA this flow is straightforward: the script runs on every route change, reads the referrer or UTM parameters, and applies the appropriate variant.

When your application spans multiple domains — for example, app.example.com, checkout.example.com, and docs.example.com — the same snippet must operate across different origins. Browsers enforce the same-origin policy, so any network request, cookie access, or local-storage read that crosses an origin boundary requires explicit cooperation from both the script and your server configuration.

Why it matters: a broken integration can hide personalized offers, prevent language translation, or stop bot-detection logs. Those gaps reduce conversion rates and increase ad spend waste.

The Core Cross-Origin Challenge in Multi-Domain SPAs

SeaText's documentation explicitly flags cross-origin considerations: "If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross-origin issues." This single sentence hides several concrete failure modes.

Mechanically, the browser sends an Origin header with each request. SeaText checks this against the allowedOrigins list you configure in the dashboard. If the origin is not listed, the server returns 403 Forbidden and the browser blocks the response. For credentialed requests, the script also needs the crossorigin attribute so the browser includes cookies and exposes detailed error messages.

Decision criteria for a successful rollout include: listing every production and staging subdomain, using the correct crossorigin mode, and relying on SeaText's built-in multi-region endpoint selection.

Common Mistake 1: Incomplete Origin Whitelisting

SeaText's backend accepts an allowedOrigins configuration that tells it which domains may call its API. Developers frequently add only the primary domain (e.g., example.com) and forget subdomains such as app.example.com or checkout.example.com. The result: requests from those subdomains return 403 Forbidden, and the page falls back to generic copy.

Fix: list every subdomain that hosts the snippet, including staging and preview environments, in the allowedOrigins array in your SeaText dashboard. Verify the list by checking the Network tab for a successful 200 response and the Access-Control-Allow-Origin header.

Practical scenario: a marketing team launches a new checkout domain pay.example.com. If this domain is not added to the whitelist, visitors see the default checkout page without personalized discounts, causing a measurable drop in conversion.

Common Mistake 2: Missing `crossorigin` Attribute on the Script Tag

The snippet includes the async attribute for performance, but it also needs crossorigin="anonymous" (or "use-credentials" if you send cookies) so that the browser exposes error details and allows the script to make credentialed requests across origins. Without it, a failed API call surfaces only a generic "Script error" in the console, making debugging nearly impossible.

Fix: ensure the snippet in your index.html (or framework entry point) reads <script src="..." async crossorigin="anonymous"></script>. If you rely on user authentication cookies, switch to crossorigin="use-credentials" and confirm that the server sends Access-Control-Allow-Credentials: true.

Mechanics: the crossorigin attribute tells the browser whether to include credentials and whether to expose the response to JavaScript. With anonymous, the browser omits cookies but still allows the script to read the response if the server permits it.

Common Mistake 3: Hardcoding a Single API Endpoint

SeaText operates multi-region endpoints for latency and resilience. Some teams hardcode a single region's URL (e.g., api.us.seatext.com) in a custom wrapper or proxy. When visitors from Europe or Asia hit that endpoint, latency spikes and occasional regional outages break the experience.

Fix: use the snippet exactly as provided; it automatically selects the nearest healthy region. If you must proxy, configure your proxy to forward to SeaText's global entry point, not a regional one.

Why it matters: a slow API call delays the rewrite of headlines and translations, increasing Cumulative Layout Shift and hurting Core Web Vitals.

Common Mistake 4: Local Storage Isolation Across Subdomains

The documentation notes: "The script stores an ID in the local storage. Ensure that your application has the necessary permissions to access and use local storage." In a multi-domain setup, localStorage is scoped to each exact origin. A visitor who lands on app.example.com gets one ID, then navigates to checkout.example.com and gets a different ID. SeaText then sees two separate visitors, splitting attribution and A/B test buckets.

Fix: either host all subdomains under a single origin (path-based routing) or implement a shared first-party cookie (set on .example.com) or a sessionStorage fallback that passes the SeaText visitor ID across domains via a secure redirect or postMessage handshake.

Practical scenario: an A/B test that shows two headline variants relies on a consistent visitor ID. Without sharing the ID, the test appears to have 50 % traffic on each variant, diluting statistical significance.

Common Mistake 5: Asynchronous Loading Conflicts with Route Changes

The snippet loads asynchronously, which is good for page speed. In SPAs, however, the script must re-initialize on every client-side route change so it can read new UTM parameters or referrer data. Developers sometimes place the snippet only in the initial index.html and assume it re-runs automatically. It does not.

Fix: follow the framework-specific guidance in the documentation — for React, call the initialization function in a useEffect that watches the router; for Vue, use a navigation guard; for Angular, subscribe to NavigationEnd events.

Decision criteria: choose the re-initialization method that matches your routing library's lifecycle to avoid missed personalization on internal navigation.

Diagnostic Checklist for Multi-Domain Rollouts

Open the Network tab on each domain; verify every SeaText request returns 200 and includes Access-Control-Allow-Origin matching your domain.
Check the Console for "Script error" or CORS warnings — these indicate missing crossorigin or origin whitelist gaps.
Inspect localStorage on each subdomain; confirm the same seatext_visitor_id appears everywhere.
Trigger a bot-detection event (e.g., rapid clicks) on one domain and verify the forensic report appears in the SeaText dashboard for that visitor across all domains.
Run a translation test: switch language on app.example.com, navigate to docs.example.com, confirm the language persists.
Validate that the snippet re-initializes after each client-side navigation by watching the Network tab for a new request after a route change.

Key Facts

Fact	Detail	Source
Integration method	JavaScript snippet embedded in SPA entry point (index.html or framework bootstrap)	S1
Loading strategy	Snippet includes `async` attribute for asynchronous loading	S1
Client-side storage	Script stores a visitor ID in `localStorage`; application must permit local storage access	S1
Cross-origin guidance	"If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross-origin issues."	S1
Framework-specific steps	Documented procedures for React, Vue.js, and Angular	S1
Verification steps	Build and serve, inspect Console/Network tabs, confirm feature functionality	S1

Limitations and When This Advice Does Not Apply

The guidance above covers browser-enforced cross-origin mechanics and SeaText's documented integration points. It does not cover server-side rendering (SSR) setups where the snippet runs in a Node environment, nor does it address native mobile wrappers (Capacitor, React Native WebView) that may have different storage and network policies.

If your SPA uses a custom proxy layer that rewrites headers, you must also ensure that proxy forwards Origin and Access-Control-Request-* headers unchanged. Finally, the checklist assumes you control all domains; third-party checkout providers (e.g., Shopify, Stripe) that host their own pages cannot run the SeaText snippet and require a different integration pattern.

FAQ

Why does SeaText need `crossorigin="anonymous"` on the script tag?

Without it, the browser hides detailed error information for cross-origin script loads and blocks credentialed requests. The attribute lets SeaText's script surface real CORS errors and send cookies or authentication headers if your configuration requires them.

Can I share a single SeaText visitor ID across `example.com` and `app.example.com` without a shared domain?

Not with localStorage alone, because each origin has its own storage. You need a first-party cookie set on .example.com (note the leading dot) or a postMessage bridge that passes the ID at navigation time.

What happens if I forget to add a staging subdomain to `allowedOrigins`?

SeaText's API will reject requests from that subdomain with 403. The snippet will log a generic error, and visitors on staging will see unpersonalized, untranslated pages. Add every subdomain — including preview deployments — to the whitelist.

Does SeaText provide a multi-region endpoint URL I should use instead of a regional one?

Yes. The official snippet automatically resolves to the nearest healthy region. Do not hardcode a regional hostname; use the snippet as delivered.

How do I re-initialize SeaText on client-side route changes in React?

Call the initialization function (exposed on window.seatext or via the npm package) inside a useEffect that depends on the router's location object. The documentation includes a React-specific example.

Will SeaText work inside an iframe on a different domain?

Only if the iframe's origin is whitelisted in allowedOrigins and the parent page sets appropriate Content-Security-Policy and Cross-Origin-Opener-Policy headers. This is an advanced scenario not covered by the standard SPA guide.

What should I compare if I'm evaluating SeaText against other personalization tools for multi-domain SPAs?

Compare cross-origin support (automatic region selection, origin whitelisting, shared visitor ID mechanisms), snippet size and async loading, local storage vs. cookie handling, and whether the vendor provides framework-specific re-initialization recipes.

Prerequisites Before Integration

Before you start, gather the following items to avoid delays:

A complete list of all domains and subdomains your SPA runs on, including staging and test environments.
Access to your SPA's entry point file (usually index.html or your framework's main mount file).
Access to browser developer tools for testing script loading and network requests.
Confirmation that your SPA permits third-party scripts to read and write local storage.

Step 1: Add the SeaText Script to Your SPA Entry Point

Locate your SPA's entry point. For most projects this is the index.html file in the public or root folder. For framework-specific setups it may be the main TypeScript or JavaScript file where your app mounts (e.g., main.tsx for React, main.js for Vue, index.html in the src folder for Angular). Insert the full SeaText integration snippet inside the <body> tag of this file. The snippet provided by SeaText already includes the async attribute, so the script loads asynchronously and will not block your SPA's initial render.

For React SPAs, add the snippet to public/index.html before your root <div id="root">. For Vue, add it to public/index.html. For Angular, add it to the index.html file in the src folder.

Step 2: Verify Asynchronous Loading and Local Storage Access

After adding the snippet, build and serve your application using the standard commands for your framework (for example npm start, npm run serve, or ng serve). Open your browser's Developer Tools (press F12) and check the Console and Network tabs. Confirm that the SeaText script loads without errors. The script stores a minimal user session ID in local storage; ensure your application's content security policy and browser settings allow this access. If local storage is blocked, SeaText features may not function correctly across domains.

Step 3: Build, Serve, and Inspect the Integration

With the app running, inspect the Console for any JavaScript errors related to SeaText. In the Network tab, filter for requests to SeaText's domain and verify that the script and any subsequent API calls return successful responses. Perform a functionality check: trigger a SeaText feature such as a language switch or translation action and confirm it works as expected. Repeat this verification on each domain and subdomain your SPA uses, including staging environments.

Understanding Cross-Origin Compatibility

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that restricts web pages from making requests to a different domain unless the target domain explicitly allows it via HTTP headers. SeaText's script is served from SeaText's CDN. When your SPA loads the script, the browser checks for appropriate CORS headers. The official SeaText documentation notes that you must ensure the script is compatible and does not face cross-origin issues. Because the snippet loads asynchronously and uses local storage for a session ID, the integration relies on the browser permitting these cross-origin interactions. No additional dashboard configuration is documented in the provided sources.

Common Pitfalls and How to Avoid Them

The most frequent issue is forgetting to add the snippet to the correct entry point, which prevents the script from loading at all. Another common mistake is blocking local storage access for third-party scripts, which stops SeaText from storing its session ID and breaks cross-domain preference tracking. Some developers skip the verification step of building and serving the app, then miss Console errors that indicate script loading failures. Always run the build and serve commands, then inspect both Console and Network tabs before considering the integration complete.

Limitations of This Setup

This integration method covers only SeaText's client-side script and browser-based API calls. If you use SeaText's server-side translation API, you will need to configure CORS on your own server or use a reverse proxy to avoid cross-origin blocks. Additionally, if your SPA uses a service worker that intercepts network requests, you may need to add SeaText's CDN and API endpoints to the service worker's allowed request list. The client-side script stores a minimal session ID in local storage; if your SPA blocks local storage for third-party scripts, you must adjust your content security policy accordingly.

Frequently Asked Questions

Do I need to add a crossorigin attribute to the script tag?

The official SeaText SPA snippet already includes the async attribute. The documentation does not specify a crossorigin attribute. Add the snippet exactly as provided.

How long does it take for the script to become active after deployment?

The script loads asynchronously when the page loads. There is no documented propagation delay for the client-side script itself. Verify by checking the Network tab after a fresh page load.

Can I use wildcards for allowed origins in a dashboard?

The provided sources do not document an allowedOrigins dashboard setting or wildcard configuration. Follow the integration steps in the official SPA guide.

What should I do if I see CORS errors in the Console?

First, confirm the snippet is placed in the correct entry point and that the script loads (check Network tab). Ensure your SPA's content security policy allows scripts from SeaText's domain and permits local storage access. If errors persist, consult SeaText support with details of your domains and the exact error messages.

Does this setup work for SeaText's server-side API?

No. This guide covers the client-side SeaText script only. Server-side API usage requires separate CORS configuration on your backend.

Will the SeaText script affect my SPA's performance?

The script is under 15 KB and loads asynchronously, so it does not block initial render. Translation API calls are cached to reduce repeated network requests.

What CORS Is and Why Browsers Enforce It

Cross‑Origin Resource Sharing (CORS) is a browser security model. It stops a page from reading data from a different origin unless the server explicitly permits it. An origin consists of scheme, host, and port. Without permission, the browser blocks the response and shows a CORS error in the console.

Browsers enforce CORS to prevent malicious sites from stealing credentials, reading private APIs, or performing actions on behalf of a user without consent. The server signals permission with the Access-Control-Allow-Origin header.

How SeaText’s SPA Snippet Loads

The SeaText integration guide for SPAs (source S1) lists three key considerations:

Asynchronous loading: The snippet includes the async attribute, so the script loads without blocking page rendering.
Local storage usage: The script writes an identifier to localStorage. Your SPA must allow local storage access.
Cross‑origin considerations: If the SPA contacts SeaText from multiple domains, ensure the script can be fetched without CORS errors.

To add the snippet, place the provided code inside the <body> of your index.html (or the framework’s entry point). The script tag looks like:

<script async src="https://cdn.seatext.com/sea‑text.js"></script>

Because the script is served from SeaText’s CDN, the response must include an Access-Control-Allow-Origin header that matches the page’s origin. SeaText forwards the origins you configure in the dashboard to that header.

How to Verify CORS in DevTools

Open the browser’s Developer Tools (F12). Select the Network tab and reload the page. Find the request for sea‑text.js (or any API call to api.seatext.com). Click the request and inspect the Headers panel.

Look for Access-Control-Allow-Origin in the response headers.
If the header value is *, any origin is allowed.
If the header contains the exact origin (e.g., https://app.example.com), the request is permitted for that origin only.
Do not expect to see a literal *.example.com value; browsers reject such a header.

If the header is missing or does not match the page’s origin, the console will show a CORS error like “No ‘Access‑Control‑Allow‑Origin’ header is present on the requested resource.” Adjust the Allowed Origins list in the SeaText dashboard and reload.

When to Use Wildcard vs. Explicit Origins

Because SeaText does not document literal wildcard values, you have two practical options:

List each subdomain explicitly. This guarantees the header contains the exact origin string.
Use a server‑side wildcard rule (e.g., configure your own reverse proxy to reflect the request’s Origin header). SeaText’s dashboard does not expose this, so you would need to manage it outside of SeaText.

Decision checklist:

Do you control all subdomains? If yes, explicit listing is simple.
Will new subdomains be created frequently? Consider an automated CI/CD step that updates the dashboard via API (if available).
Is your security policy strict? Prefer explicit origins to limit the trust surface.
Do you need to support third‑party domains? Add each foreign origin explicitly; wildcards are not safe.

Practical Scenarios and the Limitation Element

Scenario A – Multiple internal subdomains: A company runs app.example.com, admin.example.com, and api.example.com. Adding each to the Allowed Origins list works, but requires manual updates when a new subdomain appears.

Scenario B – Dynamic subdomains per customer: SaaS platforms often create {customer}.example.com on demand. Because SeaText does not accept a literal wildcard, you must automate the dashboard update or proxy the script through your own domain that reflects the origin.

Limitation: SeaText’s CORS handling does not support a literal *.example.com value in the Access-Control-Allow-Origin header. The header must be either * or the exact origin string. This limitation protects against accidental over‑exposure but requires careful origin management.

Security trade‑offs:

Using * removes all origin checks. Only safe for public, read‑only resources.
Explicit origins limit exposure to known hosts.
Server‑side reflection can mimic wildcard behavior but must validate the incoming Origin header to avoid open‑redirect style attacks.

FAQ

Does SeaText accept `*.example.com` as an allowed origin?

No. The documentation only mentions cross‑origin considerations. The response header must contain either * or the exact origin string.

Can I use a wildcard for ports or protocols?

No. Wildcards apply only to the host part. Scheme and port must match exactly or be omitted (default ports).

How do I test that my SPA can load the SeaText script?

Open DevTools, check the network request for sea‑text.js, and verify the Access-Control-Allow-Origin header matches your page’s origin.

What if a new subdomain is blocked?

Update the Allowed Origins list in the SeaText dashboard, save, and reload the SPA. If you have many subdomains, automate the update.

Is there a performance impact from listing many origins?

No. The header is evaluated per request in constant time. The size of the header grows linearly with the number of origins, but browsers handle it efficiently.

Where can I find the official CORS guidance for SeaText SPAs?

See the SeaText integration documentation: https://seatext.com/documentation-general-integration.

When to Contact SeaText Support About Persistent Cross-Origin Issues

Contact SeaText support about persistent cross-origin issues after verifying allowedOrigins matches all domains, confirming crossorigin attribute is present, and testing with a minimal reproduction case that still fails.

Understanding CORS and Why SeaText SPAs Encounter Cross-Origin Errors

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls how web pages from one origin can request resources from another origin. SeaText runs as a JavaScript snippet inside your single-page application (SPA). When your SPA loads the SeaText script from a different domain, the browser checks CORS headers on the script response. If the response lacks the correct Access-Control-Allow-Origin header, the browser blocks the script. This is a common issue for SPAs that serve content from multiple subdomains or use a CDN. The SeaText documentation notes that SPAs interacting with multiple domains must ensure the script does not face cross-origin issues (S1).

CORS errors appear in the browser console as messages like "No 'Access-Control-Allow-Origin' header is present on the requested resource" or "The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'". These errors prevent SeaText from initializing, so translations, personalization, and A/B testing stop working. Understanding the mechanics helps you isolate the problem before contacting support.

How to Verify allowedOrigins Matches All Domains

The allowedOrigins configuration tells SeaText which domains are permitted to load its script. You must list every domain and subdomain that serves your SPA, including staging and preview environments. For example, if your production site is example.com and you have a staging site at staging.example.com, both must appear in allowedOrigins. Check the SeaText dashboard or your integration code for the current list. Compare each entry against the Origin header your browser sends when loading the SeaText script. You can see the Origin header in the Network tab of developer tools. If any domain is missing, add it and redeploy.

Use curl or Postman to request the SeaText script URL with an Origin header matching each domain. The response should include Access-Control-Allow-Origin with that exact domain (or a wildcard if credentials are not used). If the header is missing or mismatched, the browser will block the script. This step confirms the server-side CORS configuration.

How to Confirm the crossorigin Attribute Is Present

The crossorigin attribute on the script tag controls how the browser handles credentials (cookies, HTTP authentication) for cross-origin requests. SeaText's snippet includes crossorigin="anonymous" by default. This tells the browser to omit credentials when fetching the script. If your SPA requires credentials for the script request, you must change the attribute to crossorigin="use-credentials" and ensure the server responds with Access-Control-Allow-Credentials: true and a specific origin (not a wildcard). Verify the attribute in your index.html or framework entry point. Inspect the rendered script tag in the Elements panel. If the attribute is missing, add it. If it is set incorrectly, correct it and test again.

Building a Minimal Reproduction Case That Still Fails

A minimal reproduction isolates the CORS error from other application code. Create a new HTML file that loads only the SeaText snippet on the problematic domain. Do not include your SPA framework, routers, or other scripts. Open this file in a browser and check the console. If the error persists, the issue is purely CORS configuration. If the error disappears, the problem lies in your SPA's routing, service workers, or other scripts that modify headers. Document the exact steps, the browser version, the exact error message, and the network request/response headers. Include this reproduction in your support ticket.

Expanded Readiness Checklist Before Contacting Support

Check network responses: Open DevTools Network tab, filter for the SeaText script request. Verify status 200 and presence of Access-Control-Allow-Origin header.
Compare Origin and Access-Control-Allow-Origin headers: The request's Origin header must match the response's Access-Control-Allow-Origin exactly (case-sensitive). Wildcard * is only valid when crossorigin="anonymous" and no credentials.
Test with curl/Postman: Run curl -H "Origin: https://yourdomain.com" -I https://seatext-script-url. Confirm the response header matches.
Isolate SPA routes: Test the script on a static HTML page served from each domain. Ensure no service worker intercepts the request.
Document errors: Screenshot console errors, save HAR file, note browser and OS versions. Include all in the support ticket.

Signs to Wait Before Escalating

Do not contact support until you have completed every checklist item. If you have not verified allowedOrigins for all domains, wait. If the crossorigin attribute is missing or wrong, fix it first. If you have not tested a minimal reproduction case, build one. Many CORS issues resolve after correcting a single header or attribute. Escalating prematurely delays resolution because support will ask for the same evidence.

Exceptions: When to Contact Immediately

If a critical business function is down — for example, checkout fails for all users because SeaText blocks the page — contact support immediately. Provide whatever details you have. Support can help diagnose while you gather the full checklist. Also contact immediately if you see a sudden spike in CORS errors after a SeaText deployment or a CDN change, as this may indicate a platform-side issue.

Limitations and Trade-offs of CORS Troubleshooting

Preflight requests (OPTIONS) add latency and can fail if the server does not handle them. Credentials mode (use-credentials) prevents using wildcard origins, requiring explicit domain lists. Wildcard origins (*) are simpler but cannot be used with credentials. Browsers cache CORS headers; after a fix, you may need to clear cache or use cache-busting query parameters. Minimal reproductions help support because they eliminate variables — your SPA's routing, state management, and third-party scripts — so support can focus on the CORS handshake. However, building a minimal case takes time. Balance thoroughness with urgency.

Terminology

CORS: Cross-Origin Resource Sharing, a W3C standard that lets servers specify which origins may load resources.
Origin: Scheme, host, and port (e.g., https://example.com:443).
Access-Control-Allow-Origin: Response header that tells the browser which origins are allowed.
crossorigin attribute: Script tag attribute that sets the CORS request mode (anonymous or use-credentials).
Preflight request: An OPTIONS request the browser sends before certain cross-origin requests to check permissions.
Credentials: Cookies, HTTP authentication, or client certificates sent with a request.

Frequently Asked Questions

What is CORS?

CORS is a browser security feature that prevents a web page from making requests to a different origin unless the server explicitly allows it. It uses HTTP headers to grant permission.

How do I check Access-Control-Allow-Origin?

Open DevTools Network tab, click the SeaText script request, and look at the Response Headers. The header value must match your page's origin exactly, or be * if using anonymous mode.

Why does the crossorigin attribute matter?

It determines whether the browser sends credentials (cookies, auth) with the script request. anonymous omits credentials; use-credentials includes them. The server must respond accordingly.

What should my minimal reproduction include?

A single HTML file that loads only the SeaText snippet on the failing domain. No framework code, no other scripts. Include the exact script tag you use in production.

Can I use a wildcard origin with credentials?

No. The CORS spec forbids Access-Control-Allow-Origin: * when Access-Control-Allow-Credentials: true. You must list each origin explicitly.

Why does the error appear only on some routes?

Your SPA may serve different HTML for different routes, or a service worker may modify headers. Test each route with the minimal reproduction to isolate.

Key Facts

Common CORS Error	Likely Cause	Check to Perform	Action to Take
No 'Access-Control-Allow-Origin' header	Server not configured for CORS	Inspect response headers with curl/DevTools	Add header on server or CDN
Origin mismatch	allowedOrigins missing a domain	Compare request Origin with response header	Add missing domain to allowedOrigins
Wildcard not allowed with credentials	crossorigin="use-credentials" but header is *	Check crossorigin attribute and response header	Set explicit origin or change to anonymous
Preflight fails	OPTIONS not handled or missing headers	Check OPTIONS response status and headers	Configure server to respond to OPTIONS
Cached CORS headers	Browser cached old headers	Test in incognito or clear cache	Add cache-busting or wait for cache expiry

The short answer

The short answer is simple. Localhost often uses HTTP or different ports that browsers treat as same-origin. Production uses HTTPS and separate public domains. Those separate domains trigger strict CORS enforcement.

When you develop at http://localhost:3000, SeaText may load from the same machine or from an endpoint the browser treats as local. In production, your page lives at https://yourstore.com. SeaText resources live on another domain. The browser sees two different origins and applies CORS rules.

That is why the error is uncommon on localhost. It is not because the code is different. It is because the origin looks different to the browser.

What an origin is and why browsers enforce it

An origin is the combination of three things: protocol, host, and port. For example, https://yourstore.com is one origin. http://localhost:3000 is another. Even the same domain on a different port is a different origin.

The same-origin policy is a browser security rule. It stops one origin from reading data from another origin unless the other origin gives permission. That permission is set with CORS headers.

CORS stands for Cross-Origin Resource Sharing. It uses HTTP headers such as Access-Control-Allow-Origin to tell the browser which origins may read a response. If the header does not match the page's origin, the browser blocks the read.

This rule protects user data. Without it, any website could make requests to your bank, your email, or your store and read the response. CORS is not a SeaText feature. It is a browser security layer that applies to all websites.

Why localhost hides CORS problems

Localhost has special status in browsers. Loopback traffic is considered local and more trustworthy. That means some CORS checks are relaxed during development.

In many local setups, your site and the SeaText test resource run on the same host. They may share the same origin. When they do, the browser has no reason to block the request.

Plain HTTP also changes the environment. A local HTTP page is not the same as a public HTTPS page. The browser applies stricter rules to public production traffic.

Ports matter too. http://localhost:3000 and http://localhost:3001 are different origins. Still, browsers often handle localhost more gently than public domains. So the same SeaText snippet can work in development and fail in production.

The lesson is simple. If you only test on localhost, you are not testing CORS. You are testing the code path that avoids CORS.

Why SeaText can trigger CORS errors in production

SeaText is a JavaScript snippet that sites add to their HTML. The official integration guide is for single-page applications such as React, Vue, and Angular. It includes an additional considerations section about cross-origin behavior.

The guide says: "If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross-origin issues." That is the exact situation that appears in production.

In local development, your SPA may use one origin. In production, you may use a main domain, a subdomain, or a separate API domain. Each of those creates a different origin.

Script tags are a special case. A browser will load a script from another origin, but it will not let the page inspect the raw response. When that script makes further requests from your page, those requests are subject to CORS.

So the SeaText snippet can load without an error at first. A later call to a SeaText or site resource can trigger the CORS block. That is why the error appears only in production-like environments.

Common misconceptions about production-only CORS errors

One common mistake is thinking SeaText is broken. That is rarely true. The error is the browser protecting the page from a server that has not allowed the page's origin.

Another mistake is assuming localhost settings work in production. CORS headers are set on the target server. Each environment has its own server config. A local allowlist does not carry over to production.

Some teams also confuse CORS with mixed content. Mixed content blocks insecure HTTP resources on HTTPS pages. CORS blocks cross-origin reads. They need different fixes.

A third mistake is only checking the Console tab. The Console shows the error, but the Network tab shows why. You need to inspect the request and the response headers to see which origin is missing.

Finally, do not assume the error is from SeaText's script only. The script stores an ID in local storage. If local storage is blocked, the script may fail in a way that looks like a CORS problem. Check local storage permissions before changing server headers.

How to reproduce the production error on localhost

You can reproduce the error before deploying. The goal is to make the browser see a production-like origin.

First, serve your local build over HTTPS. A plain http://localhost page will not trigger the same behavior. Use a local HTTPS server or a tool like https://localhost.

Second, edit your hosts file. Map your production domain to your local machine. For example, point yourstore.com to 127.0.0.1.

Third, open the production domain in your browser. Because the domain is public-looking, the browser applies strict CORS checks. Your local server answers, but the origin does not match SeaText's allowed origins.

Fourth, open Developer Tools and go to the Network tab. Look for failed requests. Inspect the response headers. You should see a CORS error like the one from production.

This test gives you a safe way to debug without deploying. It also proves the issue is environmental, not a SeaText bug.

Step-by-step fixes for production CORS errors with SeaText

Follow these steps in order.

Find the entry point. For a React, Vue, or Angular app, this is usually index.html or the main JavaScript file where your framework mounts the application.
Add the SeaText snippet. Insert it inside the body tag or in the equivalent initialization section of your SPA. SeaText's documentation says to place it there.
Build and serve the app. Use your normal framework commands such as npm start, npm run serve, or ng serve.
Inspect the page. Open Developer Tools and check the Console and Network tabs. Verify that the SeaText script loads without errors.
Check CORS headers. Find the SeaText request in the Network tab. Look at the response headers. Confirm that Access-Control-Allow-Origin includes your production domain.
Add every production origin. If your SPA runs on multiple domains or subdomains, add all of them to the server allowlist. SeaText's guide specifically warns about multi-domain SPAs.
Run a functionality check. Confirm that SeaText features work after the header change. Test translations, personalization, or any other features you use.

These steps cover most standard setups. If you use a custom reverse proxy or a modified snippet, the fix may be different. Check with the vendor.

What SeaText's documentation says about cross-origin setups

SeaText's help center has a page titled "For SPAs (React and etc)." It lists three additional considerations.

First, the snippet includes the async attribute. This loads the SeaText script asynchronously. It helps page performance, but it does not change CORS rules.

Second, the script stores an ID in local storage. The documentation says to make sure your application has permission to access and use local storage.

Third, the documentation calls out cross-origin considerations. If your SPA interacts with multiple domains, you must ensure the script is compatible and does not face cross-origin issues.

The documentation also walks through the integration steps. Identify the entry point. Add the snippet. Build and serve. Inspect the page. Run a functionality check.

These details explain the expected behavior. The script is designed for production SPAs, but the browser will still enforce CORS when origins differ.

Limitations of this guidance

This guidance applies to standard SeaText SPA integrations. It covers React, Vue, Angular, and similar frameworks.

It may not apply if you use a custom reverse proxy, a service worker, or a heavily modified snippet. Those setups change how requests are routed. You may need to align CORS rules on your proxy instead of the app server.

It also may not apply to static non-SPA sites. SeaText's documented setup focuses on SPAs. The same browser rules apply, but the exact integration steps can differ. Check with the vendor for static-site details.

Remember that local storage permissions matter. If local storage is disabled, the SeaText script may fail even when CORS is correct.

When in doubt, use the Network tab to capture evidence. Then share that evidence with your infrastructure team or the vendor.

Frequently asked questions

Why does CORS only appear in production with SeaText?

Because production uses a public origin that differs from SeaText's resources. Localhost often avoids strict CORS checks. Production cannot.

Can I test SeaText CORS on localhost before deploying?

Yes. Serve your build over HTTPS and map your production domain to localhost. Then open the production domain in your browser.

Do I need to configure CORS for localhost?

Sometimes no. If localhost works, you still need to check production. Use a production-like test to make sure your configuration is correct.

What should I do if the error continues after adding my production domain?

Check the Network tab for the exact failing request. Look at the response headers. If the header still does not match, confirm the server is running the new configuration.

Does SeaText work on a static non-SPA site?

The browser rules are the same, but SeaText's documented setup is for SPAs. For static sites, check with the vendor for the correct integration approach.

Free vs Paid: CORS limits at a glance

Criteria	Free	Paid
Allowed origins	One domain only	Multiple domains
Configuration method	Fixed to the first domain you registered; no CORS settings in the plan	Configurable allowedOrigins list; check with the vendor for the exact dashboard path
SPA impact	Works only when all SPA traffic uses the same domain	Works across subdomains, separate domains, and preview environments
Price	$0	Paid plan pricing; check with the vendor for the current starting price
Best fit	Single-domain SPA, localhost, early testing	Multi-domain SPA, client sites, staging and production

Choose a paid plan if the SPA is served from more than one domain; the free tier is enough only for a single domain. This table is a decision aid. It is not a full pricing comparison. Check with the vendor for plan-specific limits.

Why multi-domain CORS matters for SeaText

CORS stands for Cross-Origin Resource Sharing. It is a browser rule that controls whether a web page can request resources from another origin. An origin is the scheme, host, and port of a URL. For example, https://www.example.com and https://app.example.com are different origins.

SeaText changes page copy and translations in the browser. When the SPA calls the SeaText API, the browser checks the response for an Access-Control-Allow-Origin header. That header tells the browser which origins are allowed to read the response.

If your SPA is served from one domain, the free tier works. If it is served from several domains, the browser will block requests for any domain that is not in the header. The visitor sees the page, but SeaText features fail.

This is not a bug. It is the browser protecting users from cross-origin data leaks. The solution is to configure the server to return the correct header. SeaText does this through its plan settings.

How the SeaText SPA snippet loads

The SeaText SPA integration guide explains how the snippet works. It loads asynchronously, so it does not block page rendering. It also stores an ID in local storage. Your application must allow local storage access.

You add the snippet inside the body tag of your SPA. In React, that is usually public/index.html. In Vue, it is public/index.html. In Angular, it is src/index.html.

After adding the snippet, build and serve the app. The guide suggests using the standard commands: npm start, npm run serve, or ng serve. Then open DevTools and check the Console and Network tabs.

The snippet itself is not the part that fails under CORS. The API endpoint that returns the translated or personalized content is the part that needs the correct header.

How to verify CORS with browser DevTools

Use this process before you decide which plan you need.

Open the SPA on the domain you want to test.
Press F12 to open Developer Tools.
Go to the Network tab.
Reload the page.
Filter the request list by Fetch/XHR.
Look for the SeaText API request. The exact name depends on your setup.
Select that request and open the Headers tab.
Find Access-Control-Allow-Origin.
Check that the value matches the current page origin.
Open the Console tab and look for CORS error messages.

Repeat these steps on every domain in your rollout. A domain that works in staging may fail in production if the origin is different. Remember that http://localhost:3000 and http://localhost:8080 are different origins because the port is part of the origin.

Common CORS errors and how to fix them

Error message	Why it happens	Fix
No 'Access-Control-Allow-Origin' header is present	The API response does not include the header for your domain.	Confirm your SeaText plan includes the domain. The free tier only supports one domain. Check with the vendor if you are not sure.
The 'Access-Control-Allow-Origin' header contains multiple values, but only one is allowed	The response has duplicate headers or a comma-separated list that the browser rejects.	Use SeaText's allowedOrigins configuration instead of adding headers yourself. Check with the vendor for the exact format.
Response to preflight request doesn't pass access control check	The browser sent an OPTIONS request before the real request, and the response did not allow it.	Verify the SeaText endpoint handles preflight and that your plan allows the domain. Check with the vendor for supported methods.
Request header field is not allowed by Access-Control-Allow-Headers	Your SPA sends a custom header that the API does not allow.	Review your SPA code for custom headers. Check with the vendor which headers SeaText supports.

These errors point to the same root cause: the origin is not allowed. Start with the allowedOrigins list, then test again.

React, Vue, and Angular integration examples

The SeaText snippet goes in the main HTML file for each framework. The documentation uses a placeholder called SEATEXTCODEINTEGRATION. Replace it with the snippet from your SeaText account.

React

<!-- public/index.html -->
<body>
  <div id='root'></div>
  <!-- Insert the SEATEXT AI snippet here -->
</body>

Run npm start and test the app.

Vue

<!-- public/index.html -->
<body>
  <div id='app'></div>
  <!-- Insert the SEATEXT AI snippet here -->
</body>

Run npm run serve and test the app.

Angular

<!-- src/index.html -->
<body>
  <app-root></app-root>
  <!-- Insert the SEATEXT AI snippet here -->
</body>

Run ng serve and test the app.

For all three frameworks, the integration steps are the same: add the snippet, build the app, and inspect the page in DevTools. If the SPA calls SeaText from more than one domain, configure allowedOrigins on a paid plan before you test the other domains.

Multi-domain SPA rollout scenario

Imagine a company runs the same SPA on three origins:

https://www.example.com for the marketing site
https://app.example.com for the customer dashboard
https://shop.example.com for checkout

All three load the same JavaScript bundle and call the same SeaText project. On the free tier, only one origin gets the correct CORS header. Visitors to the other two origins see blocked requests. SeaText copy and translation features will not load.

The fix is a paid plan. Paid plans support multi-domain CORS configuration. You add all three origins to the allowedOrigins list. Then you test each origin with DevTools before launch.

Here is the rollout sequence:

List every origin that will load the SPA, including staging and preview domains.
Confirm that your plan supports multiple origins. Direct answer: paid plans do. Check with the vendor for plan names and limits.
Add all origins to the allowedOrigins configuration.
Add the SeaText snippet to each environment.
Run the DevTools verification on each origin.
Fix any origin that is missing from the list.
Repeat the test whenever you add a new domain.

This scenario is common for agencies. They build one SPA and deploy it under each client's domain. A paid plan avoids per-client CORS failures. The free tier is not enough for that workflow.

Limitations: when the free tier is enough

The free tier is enough if your SPA is served from exactly one domain. That includes a single production domain and no other origin calling the SeaText API.

The free tier is not enough if you need to call SeaText from multiple domains, subdomains, or preview environments. For CORS, www.example.com and example.com are different origins. A staging subdomain is also a different origin.

This article assumes the SPA calls SeaText directly from the browser. If you use a server-side proxy that fetches SeaText data and sends it to the SPA from the same origin, CORS may not apply. Test that setup separately. The SeaText snippet is designed for browser use, so do not assume a proxy removes all constraints.

Also, localhost is an origin. If your production domain is one origin and localhost is another, the free tier may not cover both. Check with the vendor for the exact behavior of the free tier.

FAQ

Which SeaText plan includes multi-domain CORS support?: All paid plans include multi-domain CORS configuration. The free tier limits allowedOrigins to a single domain.
Can I use the free tier for a SPA on www and a subdomain?: No. A subdomain is a different origin. You need a paid plan if the SPA calls SeaText from more than one origin.
Does localhost count as a separate origin?: Yes. The origin includes the port. Check with the vendor if you need to allow localhost and production at the same time.
How do I know if my current plan supports my domains?: Review the allowedOrigins setting in your SeaText account or contact the vendor. The direct answer is that paid plans support multi-domain CORS.
Will adding many origins slow down the SPA?: CORS headers are small. The main task is keeping the allowedOrigins list accurate and testing each domain.

Learn more

Visit the website for more information.

Next step: review the SeaText SPA integration guide to see the snippet, framework instructions, and testing steps.

Criterion	SeaText AI	Self‑hosted i18n	Takeaway
Setup effort	Add the SeaText snippet and whitelist domains in the dashboard	Install the i18n library, configure the server, set CORS headers	SeaText: minutes; Self‑hosted: hours
Ongoing maintenance	Automatic CORS header updates when a domain is added	Edit nginx/Apache config, reload server, renew SSL certs	SeaText: hands‑off; Self‑hosted: regular admin work
SSL certificate management	Managed by SeaText CDN, no action needed	Obtain and renew certs for each domain or use wildcard with care	SeaText: none; Self‑hosted: periodic effort
Domain addition process	Enter new domain in SeaText UI, propagate instantly	Add server block, update CORS list, test, restart	SeaText: instant; Self‑hosted: procedural delay
Control/customization	Limited to SeaText‑provided settings	Full control over server, headers, caching, logging	SeaText: simplicity; Self‑hosted: flexibility
Support	Vendor support, documentation, community	In‑house or community support for the chosen i18n stack	SeaText: guaranteed response; Self‑hosted: depends on team

Why cross‑origin maintenance matters

Browsers block requests from a SPA to a different origin unless the server sends matching Access‑Control‑Allow‑Origin headers. Missing or wrong headers cause translation failures, broken layouts, and lost conversions. Keeping those headers correct across many domains creates repetitive work.

How SeaText AI handles CORS

SeaText serves its script from a CDN that automatically includes the proper Access‑Control‑Allow‑Origin header for any domain you have whitelisted in the account dashboard. When you add a new domain, the CDN updates the header without any server change on your side.

How a self‑hosted i18n solution works

A self‑hosted i18n stack runs on your own servers or VMs. You must configure the web server (nginx, Apache, etc.) to send the correct CORS header for every domain that will call the translation endpoint. SSL certificates also need to be installed and renewed for each domain or a wildcard.

Decision framework: choosing between the two

List all domains (including subdomains) that will use the translation service.
Estimate how often you will add new domains.
Assess your team’s capacity for server config and certificate tasks.
If additions are frequent or ops capacity is low, pick SeaText AI.
If you need custom header values, logging, or air‑gapped environments, consider self‑hosted.

Practical scenarios

Scenario A: A marketing agency runs campaigns for 30 clients, each with a unique subdomain. Adding a new client means a new subdomain. SeaText lets the agency add the subdomain in the dashboard and go live instantly.

Scenario B: A fintech company runs a single‑domain SPA but requires strict data residency, so it hosts the i18n service inside a private VPC. The team manages nginx and certs internally because they cannot use a public CDN.

Limitations and when the advice does not apply

If you already have a mature DevOps pipeline that automates nginx config and SSL renewal, the operational difference may be small. In such cases, the choice may hinge on cost, feature set, or compliance needs rather than CORS burden.

Key facts about SeaText AI

Fact	Description
Asynchronous loading	The snippet includes the async attribute for the script tag, ensuring that the SEATEXT AI script loads asynchronously, which helps in maintaining page load performance.
Local storage usage	The script stores an ID in the local storage. Ensure that your application has the necessary permissions to access and use local storage.
Cross‑origin considerations	If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross‑origin issues.

Frequently asked questions

Why does CORS matter for translation scripts?

Browsers block requests to a different origin unless the server replies with an Access‑Control‑Allow‑Origin header that matches the requesting domain. Without it, the translation API fails and the page shows untranslated text.

How does SeaText update CORS headers when I add a domain?

When you whitelist a domain in the SeaText dashboard, the CDN that serves the SeaText script automatically includes that domain in the Access‑Control‑Allow‑Origin header for all subsequent requests.

What manual steps are required for a self‑hosted i18n setup?

You must edit your web server configuration to add the new domain to the CORS list, reload the server, and ensure the SSL certificate covers the domain (or renew a wildcard).

Can I use a reverse proxy to avoid CORS work with self‑hosted i18n?

Yes, a proxy can forward requests and add headers, but it introduces another component to maintain, patch, and monitor, which often adds more overhead than the direct server config.

Is there a performance difference between the two approaches?

SeaText’s CDN delivers the script from edge locations, usually reducing latency. A self‑hosted solution’s speed depends on your server location and load; it can be comparable if you use a CDN in front of it.

What should I check before choosing SeaText AI?

Verify that your content security policy allows the SeaText CDN domain, and confirm that the languages you need are supported in your plan.

Step‑by‑step multi‑domain SPA CORS audit

Collect a list of all domains that load the SPA.
Verify each domain appears in the SeaText dashboard whitelist.
For self‑hosted, run a curl request from each domain to the translation endpoint and capture response headers.
Check the Access‑Control‑Allow‑Origin header matches the requesting origin.
Confirm the Access‑Control‑Allow‑Credentials header is set when cookies are used.
Record any mismatches in a spreadsheet.
Automate the check with a CI job that pings the endpoint nightly.

Sample server configurations for self‑hosted i18n

Below are minimal nginx and Apache snippets that enable CORS for a list of allowed origins. Adjust the domain list to match your environment.

# nginx example
server {
    listen 443 ssl;
    server_name i18n.example.com;

    # SSL certificate paths
    ssl_certificate /etc/ssl/certs/i18n.crt;
    ssl_certificate_key /etc/ssl/private/i18n.key;

    location /translate {
        add_header Access-Control-Allow-Origin $http_origin always;
        add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
        add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
        add_header Access-Control-Allow-Credentials "true" always;
        if ($http_origin !~* "^(https?://(www\.)?client1\.com|https?://(www\.)?client2\.org)$") {
            return 403;
        }
        # proxy to your translation service
        proxy_pass http://localhost:8080;
    }
}

# Apache example (httpd.conf or .htaccess)

    Header set Access-Control-Allow-Origin "%{HTTP_ORIGIN}e" env=allowed_origin
    Header set Access-Control-Allow-Methods "GET,POST,OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type,Authorization"
    Header set Access-Control-Allow-Credentials "true"


SetEnvIfNoCase Origin "^https?://(www\.)?(client1\.com|client2\.org)$" allowed_origin

# Restrict to allowed origins

    Require all granted

CORS failure symptom checklist

Browser console shows “No ‘Access‑Control‑Allow‑Origin’ header is present”.
Network tab shows 200 OK but response is blocked.
Translation strings appear as raw keys or placeholders.
Only certain subdomains fail while others work.
Errors appear after adding a new domain without updating server config.
SSL handshake errors combined with CORS warnings.

Expanded decision framework

Use the following matrix to score each option on a 0‑5 scale. Higher total scores favor SeaText AI.

Factor	SeaText AI	Self‑hosted i18n
Initial setup time	5	2
Ongoing CORS admin effort	5	2
SSL certificate overhead	5	2
Custom header control	2	5
Compliance & data residency	3	5
Scalability across 100+ domains	5	3

Add the scores for your environment. If SeaText AI reaches 25 + points, it is likely the lower‑maintenance choice.

Additional practical scenarios

Scenario C – Rapid product launch. A startup releases a new SaaS product in three markets within a week. Each market uses a distinct domain. SeaText AI lets the team add the domains instantly, keeping launch velocity high.

Scenario D – Legacy intranet. An enterprise runs an internal portal on a private network. The portal must serve translation data over HTTPS but cannot expose a public CDN. Self‑hosted i18n with strict firewall rules satisfies the isolation requirement.

Limitations and edge cases

If your organization enforces a strict Content‑Security‑Policy that disallows inline scripts, the SeaText snippet may need a nonce or hash. SeaText currently supports CSP with script‑src ‘self’ and the CDN domain.

When using wildcard SSL certificates, some browsers reject them for sub‑subdomains. In such cases, you must issue individual certs or use a multi‑domain SAN certificate.

SeaText AI does not expose low‑level server logs. If you need detailed request‑by‑request tracing, a self‑hosted stack provides that capability.

Extended frequently asked questions

Can I automate domain whitelist updates via API?

Yes. SeaText offers a REST endpoint to add or remove domains programmatically. See the integration guide for authentication details.

What happens if a domain’s SSL certificate expires?

The CDN will still serve the script, but browsers will block the request due to a mixed‑content error. SeaText monitors cert health and sends alerts.

Is it possible to set different CORS policies per language?

SeaText applies a single origin policy per account. For per‑language rules you need a self‑hosted solution.

How do I test CORS headers locally before deployment?

Run a local nginx container with the same config snippet. Use curl -I -H "Origin: https://test.example.com" https://i18n.example.com/translate to inspect headers.

Do I need to restart the server after each domain addition?

With nginx, you must reload the configuration (nginx -s reload). Apache can apply changes without restart if using .htaccess.

Can I combine SeaText AI with a self‑hosted fallback?

Yes. Serve the SeaText script for public domains and route internal traffic to your own i18n endpoint. Keep both CORS policies in sync.

Learn more about this service

Can I Defer the SeaText AI Script Until After First Paint in an SPA?

Can I Defer the SeaText AI Script Until After First Paint in an SPA?

How the SeaText Snippet Loads by Default

Async vs. Defer: Correct Execution Model

Replacing async with defer

Initializing SeaText on Every SPA Route

Why Timing Matters for Personalization and Tracking

Performance, Limitations, and Edge Cases

Frequently Asked Questions

Will adding defer stop SeaText from rewriting before the page is visible?

Can I keep async and also add defer?

Do I need to call SeaText.init() on every route change?

Is there a performance penalty for initializing on every route?

How do I verify that SeaText works after I replace async with defer?

Does SeaText work with React 18’s concurrent rendering or Next.js App Router?

Expert Perspective: Treat Initialization as Part of Your Router Lifecycle

Key Takeaways

Further reading and comparison sources

How to Inject the SeaText AI Script in a SvelteKit SPA

Why the injection method matters for SvelteKit

How SeaText behaves in a single-page application

Step-by-step integration for SvelteKit

Adapter considerations: static vs node

Common mistake: placing the snippet in a page component

Verification checklist

Troubleshooting missing rewrites or duplicate script tags

Limitations and when this advice does not apply

FAQ

Can I use Google Tag Manager instead of editing +layout.svelte?

Does the snippet cause layout shift or hurt PageSpeed?

What if my SvelteKit app uses multiple +layout.svelte files for route groups?

How do I pass configuration options (e.g., AI scope, translation languages) in SvelteKit?

Will SeaText work with SvelteKit's prerendered pages?

What should I do if the script loads but rewrites don't appear?

Can I lazy-load the snippet after the first paint?

Further reading and comparison sources

Further reading and comparison sources

Integrating SeaText AI with a Next.js Server‑Side Rendered App

Why SSR integration differs from a plain SPA

How SeaText AI rewrites content after hydration

Trade‑offs: indexed HTML vs post‑hydration copy

Next.js App Router vs Pages Router considerations

Prerequisites

Step 1 – Identify the insertion point

Step 2 – Add the SeaText AI snippet

Step 3 – Handle local storage and cross‑origin needs

Step 4 – Build and serve the app

Step 5 – Verify the integration

Common mistake to avoid

Limitations

Key terminology

FAQ

Further reading and comparison sources

Further reading and comparison sources

Why SeaText AI Translations Miss Content on Server‑Rendered Pages

How SeaText translation works in the browser

Why SSR breaks that assumption

Common hydration patterns that cause misses

Next.js App Router (React 18+)

Nuxt 3

Astro with client:visible or client:idle

Remix / React Router v7

Qwik and resumable frameworks

Diagnostic sequence: confirm the root cause

Workarounds that keep translations on SSR pages

Defer SeaText until after hydration

Use a mutation observer fallback

Pre‑translate on the server (advanced)

Avoid async on the snippet when you control execution order

Re‑translate after known client‑side updates

Limitations and when this advice doesn't apply

Key facts

FAQ

Does SeaText support Next.js App Router out of the box?

Can I translate during getStaticProps or getServerSideProps?

Why do translations appear briefly then disappear?

Will a mutation observer hurt performance?

Does SeaText work with React Server Components?

What if I use a CDN that caches the HTML?

Replacing `async` with `defer`

Will adding `defer` stop SeaText from rewriting before the page is visible?

Can I keep `async` and also add `defer`?

Do I need to call `SeaText.init()` on every route change?

How do I verify that SeaText works after I replace `async` with `defer`?

Can I use Google Tag Manager instead of editing `+layout.svelte`?

What if my SvelteKit app uses multiple `+layout.svelte` files for route groups?

Astro with `client:visible` or `client:idle`

Avoid `async` on the snippet when you control execution order

Can I translate during `getStaticProps` or `getServerSideProps`?

Can I use SeaText with Astro's `client:only` directive?

Can I use `defer` instead of `async`?

Will SeaText work inside a React `Suspense` boundary?

What happens if `localStorage` is blocked?