Seatext library

SeaText AI and Next.js Incremental Static Regeneration (ISR): Compatibility and Integration Guide

Yes, SeaText AI works with Next.js Incremental Static Regeneration (ISR) because the SeaText script is a client-side snippet that executes on every page load, including regenerated pages. As long as the script is included...

Direct Answer: ISR Compatibility Confirmed

SeaText AI supports Next.js Incremental Static Regeneration (ISR) out of the box. The SeaText integration is a lightweight client-side JavaScript snippet (under 15 KB) that runs in the browser after the page hydrates. Because ISR serves static HTML that includes your embedded script, the SeaText code executes on every page view — whether the page was pre-rendered at build time, generated on-demand, or regenerated in the background. No server-side changes or special ISR configuration are required.

How ISR Works in Next.js

Incremental Static Regeneration lets you create or update static pages after deployment without rebuilding the entire site. You define a revalidate period (in seconds) on a page-by-page basis. When a request arrives for a page that is older than the revalidate window, Next.js serves the cached HTML immediately and triggers an asynchronous regeneration in the background. The next visitor receives the freshly generated static page.

This model preserves the performance benefits of static sites — CDN caching, fast TTFB, low server load — while allowing content updates on a schedule or on-demand via revalidatePath or revalidateTag. The critical point for third-party scripts: the HTML served from the CDN (stale or fresh) is exactly what you built. Any script tags you placed in <body> or via next/script travel with that HTML.

SeaText AI Integration Model

SeaText AI provides a single JavaScript snippet that you embed in your site. According to the general integration guide, the snippet:

Loads asynchronously via the async attribute, so it never blocks page rendering.
Stores a visitor identifier in localStorage for session continuity.
Runs after the DOM is available, scanning and translating text nodes, rewriting headlines, adapting CTAs, and activating other agents (translation, personalization, bot detection, A/B testing).
Requires no server-side runtime, API keys in frontend code, or build-time compilation steps.

Because the snippet is pure client-side JavaScript, it behaves identically whether the HTML came from a static export, a server-rendered response, or an ISR-regenerated page. The script does not depend on Next.js internals, getStaticProps, getServerSideProps, or the App Router's generateStaticParams.

Adding the Snippet in a Next.js Project

Pages Router (`pages/_document.js`)

In the Pages Router, the canonical place to inject a third-party script that must appear on every page is a custom _document.js. Extend Document and override render() to insert the SeaText snippet just before the closing </body> tag. This ensures the script is present in every static page ISR generates.

App Router (`app/layout.tsx` or `next/script`)

In the App Router, you have two clean options:

Place the snippet in the root layout.tsx inside a <Script strategy="afterInteractive" /> component. The afterInteractive strategy loads the script after hydration, matching SeaText's requirement to run on a fully rendered DOM.
Use a client-side component that mounts the script in a useEffect with an empty dependency array, guaranteeing execution after the first paint.

Both approaches embed the script into the static HTML that ISR caches and serves. When ISR regenerates a page, the new HTML includes the same script tag, so the next visitor loads SeaText automatically.

Key Facts

Aspect	Detail	Source
Script size	Under 15 KB, loads asynchronously	S1
Execution timing	Runs after DOM hydration, before visual paint (~15 ms)	S2
Storage requirement	Uses `localStorage` for visitor ID	S1
Framework support	Documented for React, Vue, Angular SPAs	S1
Translation coverage	Up to 125 languages	S3, S4
Personalization agents	Google Ads intent matching, visitor source rewrite, A/B testing, bot protection	S4, S7
ISR requirement	Script must be present in the HTML served by ISR (stale or fresh)	S1 (implied)

Why ISR Compatibility Matters

Teams choose ISR to balance freshness and performance. If a personalization or translation layer broke on regenerated pages, you would lose the very conversions SeaText is designed to lift — especially on high-traffic landing pages that revalidate frequently (e.g., every 60 seconds for campaign-driven content). Because SeaText runs client-side, it is immune to the server-side regeneration cycle. The only failure mode is omitting the script from the page template, which would affect all rendering modes equally.

Common Integration Mistakes

Placing the script in <head> without defer or afterInteractive. The script may execute before the DOM exists, causing it to miss translatable nodes.
Adding the script only in a layout that wraps some routes. ISR pages outside that layout (e.g., a separate marketing sub-app) would load without SeaText.
Blocking the SeaText CDN via Content Security Policy. The script loads from SeaText's domain; a restrictive script-src directive will prevent it from running on any page, ISR or not.
Assuming server-side translation. SeaText does not modify HTML at build time or during ISR regeneration. All rewrites happen in the visitor's browser.

Limitations and When This Advice Does Not Apply

Static Export (output: 'export'). ISR is unavailable in pure static export. SeaText still works because the script is baked into every HTML file at build time.
Edge Middleware rewrites. If you use middleware to rewrite URLs before ISR serves the page, ensure the rewritten page still includes the SeaText snippet in its layout.
Cross-origin iframes. If an ISR page embeds content from another domain in an iframe, SeaText inside the parent page cannot translate the iframe's content due to browser same-origin policy.
LocalStorage blocked. In private browsing modes or when users disable third-party storage, SeaText cannot persist the visitor ID across page views, but translation still functions per session.

Terminology Quick Reference

ISR (Incremental Static Regeneration): Next.js feature that serves stale static HTML while regenerating a fresh version in the background.
Revalidate period: Time window (seconds) after which a cached page becomes eligible for background regeneration.
Hydration: Process where React attaches event listeners to server-rendered HTML, making it interactive.
Client-side snippet: JavaScript that runs entirely in the browser, with no server component.
localStorage: Browser key-value store persisted across sessions, used by SeaText for visitor identification.

FAQ

Does SeaText increase the size of the static HTML that ISR caches?

Only by the size of the script tag itself (~200 bytes). The 15 KB script is fetched asynchronously from SeaText's CDN, not inlined in the HTML.

Can I use `next/script` with `strategy="lazyOnload"`?

Yes, but afterInteractive is preferred. lazyOnload defers loading until the browser is idle, which may delay translation on fast connections. SeaText's own benchmark shows it completes in ~15 ms when loaded after hydration.

What happens if ISR regenerates a page while a visitor is on it?

Nothing. The visitor continues using the HTML they already downloaded. The next visitor receives the new HTML — which still contains the SeaText script tag — so SeaText loads normally.

Do I need to call any SeaText API after `revalidatePath`?

No. revalidatePath triggers a background rebuild. The resulting HTML includes your layout (and thus the script) automatically.

Can SeaText translate content that is fetched client-side after ISR serves the page (e.g., SWR data)?

Yes. SeaText observes DOM mutations and translates new nodes as they appear, so data fetched via SWR, React Query, or fetch in useEffect will be translated.

Is there a way to preview SeaText changes on an ISR page before the revalidate window expires?

Use Next.js on-demand revalidation (revalidatePath or revalidateTag) from a preview webhook or admin action. The regenerated page will include SeaText and reflect the latest translation rules.

Does SeaText work with Next.js App Router Server Components?

Yes. Server Components render to HTML on the server (or at build time for static pages). The SeaText script, included in the root layout, runs in the browser after that HTML streams to the client and hydrates.

Verification Checklist

Build the Next.js project (next build).
Start the production server (next start).
Request an ISR page with a short revalidate (e.g., 10 seconds).
Wait past the revalidate window and request again — confirm the new HTML still contains the SeaText script tag.
Open DevTools Console and Network tabs; verify the SeaText script loads without errors and the SeaText badge appears.
Switch language via the SeaText widget; confirm translation applies to static and client-fetched content.

How SeaText AI helps with Next.js ISR

SeaText AI adds a single async script tag to your Next.js layout. That script survives every ISR regeneration because it lives in the static HTML template, not in server-side logic. You get real-time translation, Google Ads intent matching, bot detection, and autonomous A/B testing on every page view — stale or fresh — without touching getStaticProps, revalidate, or middleware. The only requirement: keep the script in your root layout (Pages Router _document.js or App Router layout.tsx) so every ISR page includes it.

Limitation: SeaText cannot translate content inside cross-origin iframes or when the browser blocks localStorage. It also does not modify HTML at build time; all rewrites happen client-side after hydration.

View the general integration guide