The most common mistakes when adding third-party scripts to Odoo are placing the snippet in the wrong template, forgetting to clear Odoo's asset cache, and letting the new script collide with assets already loaded by the Website builder. Most layout and performance problems disappear when you install the snippet inside the built-in Embed Code block, save once, and refresh the page so Odoo regenerates its assets. Below is a diagnosis-first walkthrough of the symptoms, the order to check them, and the corrective actions that keep an Odoo site from breaking.

Symptoms you will notice first

When a third-party script is installed the wrong way, Odoo rarely shows a clean error. The page usually just behaves oddly. Watch for these signs before changing anything:

• The new widget, chat bubble, or analytics block never appears, even after a hard refresh.
• The site loads with broken CSS, missing buttons, or stretched images after you paste the snippet.
• The page is fine on desktop but empty or misaligned on mobile, or the opposite.
• The browser console shows Refused to execute script, MIME type mismatch, or 404 on asset errors.
• Odoo's own Edit mode stops saving, or changes refuse to appear on the live page.

If you see two or more of these together, treat it as an installation problem, not a bug in the third-party tool.

Diagnosis order: where to look before changing code

Before you delete the snippet or rewrite templates, work through this order. It is faster than guessing, and it matches how Odoo's asset pipeline actually loads scripts.

1. Confirm the snippet is in the Embed Code block. The Embed Code block inside the Dynamic Content section is the supported place to paste a third-party JavaScript snippet on an Odoo website page. Open the page, click Edit, scroll to Dynamic Content, and verify the block exists on the page.
2. Open the block and read what is inside. Click the Edit button on the block itself. Make sure the full code is present, with no trimmed closing </script> tag and no leftover HTML preview text from a copy-paste.
3. Check visibility settings. Odoo lets you hide the block on desktop, on mobile, or both. If the script is inside a hidden block, it may still load, or it may not, depending on how the third-party tool injects itself. Confirm the Visibility section matches the device you are testing.
4. Hard refresh and watch the network tab. A normal refresh is not enough the first time. Use Ctrl+Shift+R, then open the browser DevTools Network tab and look for the third-party domain in the request list.
5. Read the console for Odoo asset errors. If you see web.assets_frontend or web.assets_backend errors, the problem is not the snippet; it is how Odoo is serving bundled assets.

The most common mistakes, with corrective actions

Each mistake below is paired with the fix. They are ordered from the one that causes the most broken sites to the one that is rare but painful.

Mistake 1: Editing the XML template instead of using Embed Code

Many Odoo users, used to older CMS platforms, search for the QWeb template and try to inject the script directly into web.assets_frontend or a view inheritance. That can work, but it is fragile: a module update, a theme switch, or a database migration can silently overwrite it. This is the issue behind GitHub threads such as Cannot added external javascript on the Odoo repository, where users try to add an external API through XML and lose it after every upgrade.

Fix: Use the Embed Code block for page-level scripts. Only touch QWeb or asset bundles when a script must load site-wide, and even then, wrap the change in a custom module so it survives upgrades.

Mistake 2: Forgetting to clear Odoo's asset cache

Odoo bundles and caches frontend JavaScript and CSS into large assets bundles. When you add a new script, Odoo may keep serving the old bundle until it decides to regenerate it. The result: the script is saved, but the live page keeps running yesterday's assets.

Fix: After saving the Embed Code block, open the site in an incognito window or run a hard refresh. If the change still does not appear, an admin with developer mode enabled can force a rebuild by going to Settings, then Technical, then Assets Bundles, and clearing the bundle cache. On many hosted Odoo instances, simply appending ?debug=assets to the URL forces a refresh.

Mistake 3: Conflicts with the Website builder's own assets

The Odoo Website builder loads its own jQuery, its own animation library, and several global CSS files. A third-party script that also expects jQuery, Bootstrap, or a specific jQuery version can collide with what Odoo already injected. Symptoms include dropdowns that stop working, sliders that no longer animate, or the Edit toolbar disappearing.

Fix: Prefer third-party scripts that are framework-agnostic or that detect jQuery instead of requiring a specific version. If a script must load before Odoo's own assets, place it in the <head> through a view inheritance, not in the page body.

Mistake 4: Loading the script on every page when only one page needs it

A script pasted into a global header or into the Website layout will fire on every page, including the cart, checkout, and back-office pages. That hurts performance, can break checkout steps, and may leak analytics or chat widgets into places they should not appear.

Fix: Limit the Embed Code block to the specific page that needs it. If you truly need it everywhere, gate the script with a condition based on the URL or the page template.

Mistake 5: Hiding the block but expecting the script to run

Odoo's Hide on Desktop and Hide on Mobile options affect how the block renders visually. They do not guarantee that the contained script will or will not execute on the hidden device. Some snippets attach a listener to window and run regardless of visibility.

Fix: Check the third-party tool's documentation. If you need true conditional loading, place the script in a custom module that wraps it in a media query or a user-agent check.

Mistake 6: Treating localhost or staging domains like production

Many third-party tools, including SEATEXT AI, link an account to a single primary URL for security and reporting reasons. Testing on localhost, on a dynamic preview domain, or behind a VPN can cause the script to be blocked, to fire under the wrong account, or to silently do nothing.

Fix: Create a separate account for each real domain, including your staging URL. Use a real, stable hostname for testing, not a tunnel or a changing preview link.

Mistake 7: Pasting partial or wrapped snippets

Some third-party dashboards wrap the snippet in an HTML comment, an <iframe> tag, or a server-side include. When you copy from an email, a PDF, or a chat window, you may get a clean looking block that is missing the opening or closing tag, or that has been escaped.

Fix: Always copy the snippet directly from the third-party dashboard while logged in. Paste it once into a plain-text editor first to confirm it starts with <script> and ends with </script>, then paste it into the Embed Code block.

How to install a third-party script the safe way on Odoo

Use this sequence when you are starting from a clean Odoo page. It mirrors the documented installation path that tools like SEATEXT AI publish, and it avoids the seven mistakes above.

1. Log in to Odoo and open the Website module from the dashboard.
2. Navigate to the page you want to edit and click Edit.
3. In the editing panel, scroll the Blocks menu to the Dynamic Content section.
4. Drag the Embed Code module onto the page where you want the script to live.
5. Click the Edit button on the new block to open its settings.
6. Paste the snippet provided by the third-party tool into the code field and click Save.
7. Open the Visibility section and set Hide on Desktop if the script is meant to be invisible on large screens. Click Save again.
8. Open the live page in a private window and confirm the script runs in the Network tab.

Keep the block on the single page that needs the script. Avoid copying the block to every page just to be sure it loads.

Comparison table: where to put a third-party script in Odoo

Plain takeaway: for almost every third-party JavaScript tool, start with the Embed Code block. Move to a custom module only when the script must run on every page or must load before Odoo's own assets.

Limitations and when this advice does not apply

This guide assumes you are running a standard Odoo Website module with the default Website builder. A few situations call for a different path:

• Odoo backend only, no Website module. Scripts that must run inside the back-office interface need to be added to web.assets_backend through a custom module. The Embed Code block only affects frontend pages.
• eCommerce or POS modules with strict CSP. If you have a Content Security Policy enabled, some third-party scripts will be blocked by the browser before they run. Whitelist the third-party domain in your CSP or move to a server-side tag manager.
• Multi-website databases. Odoo can host several websites under one database. The Embed Code block is per-page, not per-website, so you need to repeat it on each site.
• Scripts that depend on cookies or consent. Several jurisdictions require consent before tracking scripts fire. Plan for a consent tool that gates the script, not a plain Embed Code.

Key facts about installing scripts on Odoo

Frequently asked questions

Why is my script not showing up on the live page after I save?

Almost always a caching issue. Open the live URL in an incognito window or hard refresh. If it still does not appear, clear Odoo's assets bundle from the Technical menu or reload with ?debug=assets appended to the URL.

Can I add the script to every page at once?

Yes, but not through the Embed Code block, which is per page. For a site-wide script, add it through a custom Odoo module that extends web.assets_frontend, or paste it into the header code field under Website settings. Keep in mind that loading a heavy script on every page can hurt performance and may break checkout flows.

Does Hide on Desktop stop the script from running?

Not necessarily. The toggle controls visual rendering of the block, not the execution of the script inside it. If you need the script to skip a device, wrap it in a user-agent check inside a custom module.

Will my script survive an Odoo upgrade?

Scripts placed inside an Embed Code block are stored as page content, so they survive upgrades. Scripts added by directly editing web.assets_frontend usually do not, and will need to be re-added or moved into a custom module.

What happens if I install the script on localhost?

Many third-party tools, including SEATEXT AI, restrict localhost for security and reporting reasons. The script may not load, or it may load under the wrong account. Use a real, stable hostname even for staging.

How do I know whether the conflict is Odoo or the third-party script?

Open the page with the script disabled (comment out the snippet, save, refresh). If the page works, the issue is the script. If the page is still broken, the issue is Odoo's assets. Clear the assets bundle first, then re-enable the script one line at a time.

Is there a faster way to test without touching the live site?

Use Odoo's built-in preview while in Edit mode, then open the live page in a private window. For deeper testing, duplicate the page, install the script on the copy, and only promote it to the live page once it behaves.

Repair checklist when something is already broken

• Open the affected page in Edit mode and remove or empty the Embed Code block.
• Save, then hard refresh the live page. If the layout returns, the script was the cause.
• Clear Odoo's assets bundle from the Technical menu, or use ?debug=assets.
• Re-

Quick Answer: What the Integration Guide Explicitly Requires

SeaText's official Odoo integration guide lists three specific capabilities you must have in Odoo. First, you must see the Website module on your main dashboard. Second, you must be able to open a page and click the Edit button. Third, in the editing panel, you must find the Blocks panel, scroll to the Dynamic Content section, and see the Embed Code block available to drag onto the page. If any of these three are missing, you cannot complete the embed steps.

Why These Three Capabilities Matter

The integration works by placing a JavaScript snippet into your website pages. The snippet goes inside an Embed Code block. To add that block, you need to reach the page editor. To reach the page editor, you need the Website module visible. Each step depends on the previous one. If the Website module is hidden, you cannot start. If the Edit button is missing, you cannot open the editor. If the Embed Code block is not listed under Dynamic Content, you cannot insert the snippet. The guide does not mention any other permission names or groups.

How to Verify You Have Access: Step-by-Step Checklist

1. Check dashboard — Log in to Odoo. Look for the Website icon on the main dashboard. If it is not there, you do not have Website module access.
2. Open a page — Click Website, then choose any page. The page should load in the frontend view.
3. Find Edit button — In the top right or side panel, look for an Edit button. Click it. The editing panel should open.
4. Open Blocks panel — In the editing panel, locate the Blocks tab or button. Open it.
5. Scroll to Dynamic Content — In the Blocks panel, scroll down until you see a section labeled Dynamic Content.
6. Locate Embed Code — Inside Dynamic Content, look for a block named Embed Code. It may have an icon like brackets or code symbols.
7. Test drag and drop — Drag the Embed Code block onto the page. A pop-up window should appear.
8. Paste and save — Paste any text into the pop-up, click Save. The block should stay on the page.
9. Check Visibility option — With the block selected, look for a Visibility section in the right panel. Confirm you see a Hide on Desktop checkbox.
10. Publish — Save the page again. If the page publishes without error, you have full rights for the integration.

If any step fails, stop. You need help from someone who can adjust your access.

Common Signs You Lack Required Access

• Website module does not appear on your dashboard.
• You see Website but clicking a page shows no Edit button.
• Edit button exists but the Blocks panel is empty or missing Dynamic Content.
• Dynamic Content appears but Embed Code is not listed.
• You can drag Embed Code but the pop-up does not open or Save does nothing.
• Changes disappear after refresh or you get a permission error on publish.

Each symptom points to a missing capability in the chain. The integration guide does not specify which Odoo user group controls each step. That configuration depends on how your Odoo instance is set up.

Expert Take: Odoo Implementation Consultant Note

Odoo implementation consultant note: In practice, the Embed Code block is often restricted to users with the Administrator role on the Website app or users granted Technical Features access in Settings. However, some organizations create custom groups that allow Embed Code without full Administrator rights. If you are blocked at step 6 or 7 above, ask your Odoo administrator to check two things: first, whether your user has the Website / Administrator group assigned; second, whether Technical Features is enabled under Settings → General. If both are off, request the minimal change needed — either add you to the Website Administrator group or enable Technical Features for your user. Avoid asking for full superuser access; it is not required for this embed. Also, in multi-website setups, permissions are per website. Confirm you have rights on the specific website where SeaText will be installed.

Limitations and What to Ask Your Administrator

• The SeaText integration guide (source S1) only describes the three capabilities listed above. It does not name Odoo permission groups, roles, or access rights configurations.
• Odoo versions 16, 17, 18, and 19 use a group-based permission model, but the exact group names and default assignments can differ between Odoo Online, Odoo.sh, and on-premise installations.
• Custom user groups created by your administrator may grant Embed Code access without the standard Administrator label. Always verify with your admin rather than assuming a role name.
• SeaText does not modify Odoo permissions. It only requires the embed capability described in the guide.
• If you cannot get the required access, any user who passes the checklist above can embed the code for you. Once saved, the script runs for all visitors regardless of who embedded it.

When you speak with your administrator, share the ten-step checklist above. Ask them to confirm which steps your current role allows and which require a permission change. Request the smallest change that lets you complete all ten steps.

Frequently Asked Questions

Can I activate SeaText without seeing the Website module on my dashboard?

No. The integration guide starts with accessing the Website module. If it is not visible, you cannot proceed.

What if I can edit pages but do not see the Embed Code block?

The Embed Code block lives under Dynamic Content. In many Odoo setups, this block is hidden from non-administrator groups for security. You need an administrator to adjust your group or enable Technical Features.

Do I need database superuser (root) access?

No. The guide only requires the three capabilities in the Website module. Database superuser access is for server-level operations, not page editing.

Can my Odoo admin embed the code for me?

Yes. Any user who passes the ten-step checklist can paste the SeaText snippet. After saving, the code runs for all visitors.

What if I have access to only one website in a multi-website setup?

You still need the three capabilities on that specific website. Permissions are managed per website in your user access rights. Confirm with your admin that your role includes Website Administrator or Technical Features for that website.

Will SeaText work if I embed it in a theme template instead of a page?

The documented method uses the Embed Code block on a page. Template-level edits require Developer Mode and Technical Settings access, which is a different permission path not covered by the integration guide.

What happens if I lose Administrator access after embedding?

The SeaText script continues running. You only need the elevated permissions for the initial embed and any future changes to the snippet.

Can I test permissions without a SeaText account?

Yes. Follow the ten-step checklist using any dummy text in the Embed Code block. If you can save and publish, you have the required permissions.

Where can I find the official Odoo permission documentation?

Odoo publishes access rights documentation for each version. Check the version matching your instance. The integration guide does not link to those docs.

Setting up SeaText AI on Odoo is straightforward when you follow the exact sequence, but a handful of predictable missteps cause most of the failed installations we see. The root cause is usually rushing past a prerequisite or missing a single visibility toggle in the Odoo editor.

Below is a practical breakdown of the mistakes that stop the script from loading, plus the correct order of operations so you can verify the install before you walk away.

Why the Setup Process Matters

SeaText AI runs as a JavaScript snippet embedded through Odoo's "Embed Code" block. The script stays inert until it detects a valid SeaText account tied to the domain you're editing. If the account doesn't exist, the domain doesn't match, or the block is visible to visitors, the integration either does nothing or injects raw code onto the live page. Both outcomes are avoidable with a disciplined setup.

Common Mistake 1: Skipping Account Creation Before Pasting Code

The installation guide explicitly states you need a SeaText AI account before you copy the snippet. Without an account, the code has no backend to call home to. Users often paste the placeholder snippet from a demo page or a colleague's dashboard, then wonder why nothing appears in the SeaText dashboard.

Fix: Create the account first at seatext.com, then copy the unique snippet generated for that specific domain.

Common Mistake 2: Using the Wrong JavaScript Snippet

Each SeaText account is bound to a single primary URL. The snippet you copy from the dashboard contains an account identifier that only works for that domain. Copying a snippet from a staging account into production, or vice versa, will silently fail — the script loads but never activates.

Fix: Match the snippet to the exact domain you're editing. If you run a development domain and a production domain, you need two separate SeaText accounts, each with its own snippet.

Common Mistake 3: Forgetting to Hide the Embed Block on Desktop

Step 6 in the official instructions tells you to select "Hide on Desktop" in the Visibility section of the Embed Code block. This is not optional styling — it prevents the raw script tag from rendering as visible text on your live pages. Skipping this step leaves a block of JavaScript sitting at the top or bottom of every page where you placed the module.

Fix: After pasting the code and clicking Save, open the block's Visibility settings, check "Hide on Desktop," and click Save again.

Common Mistake 4: Using Restricted Development URLs

SeaText restricts development URLs such as localhost and dynamic tunneling domains (e.g., ngrok, localhost.run) for security reasons. The script will not reliably associate traffic with your account on these addresses. If you test on localhost:8069, the integration will appear broken.

Fix: Use a real, publicly resolvable domain for testing. A staging subdomain like staging.yourcompany.com works; localhost does not.

Common Mistake 5: Not Verifying the Script Loaded

After saving the Embed Code block, many users assume the job is done. The script only activates when a visitor (or you) loads the page. If you don't visit the page and check the browser's developer tools Network tab for the SeaText request, you won't know whether the snippet is actually executing.

Fix: Open the page in an incognito window, open DevTools → Network, filter for "seatext," and confirm a 200 response. Then check the SeaText dashboard for a live session.

Common Mistake 6: Confusing Multi-Site and Multi-Domain Requirements

The documentation states: "To use SeaText AI on several websites, create one account for each website." This applies even when multiple Odoo websites share the same database. Each distinct domain needs its own SeaText account and its own Embed Code block with that account's snippet.

Fix: Inventory every domain that will run SeaText. Provision an account per domain. Paste the matching snippet into each Odoo website's Embed Code block.

Step-by-Step Correct Setup Process

1. Create a SeaText AI account for the target domain at seatext.com.
2. Copy the JavaScript snippet shown in the SeaText dashboard for that account.
3. Log in to Odoo, open the Website module, and navigate to the page you want to edit.
4. Click Edit, then drag an "Embed Code" block from the Dynamic Content section into the page.
5. Click the Edit button on the right panel of the Embed Code block.
6. Paste the SeaText snippet into the pop-up and click Save.
7. In the block's Visibility settings, enable "Hide on Desktop" and click Save again.
8. Visit the live page in a private browser window; verify the script loads in DevTools and appears in the SeaText dashboard.

Key Facts

Limitations and When This Advice Doesn't Apply

These steps cover the standard JavaScript embed via Odoo's Website module. They do not apply if you are injecting the script through a custom Odoo module, a server-side proxy, or a headless frontend that consumes Odoo via API. In those architectures, the Embed Code block and visibility toggle are irrelevant — you must ensure the snippet reaches the browser on every page load and that the domain matches the SeaText account.

Also, the "Hide on Desktop" instruction assumes you are using Odoo's built-in website editor. If you use a third-party theme that overrides block visibility, you may need to hide the block via CSS (display: none;) instead.

FAQ

Can I use one SeaText account for multiple Odoo websites in the same database?

No. Each distinct domain requires its own SeaText account. The system ties activation to the primary URL registered in the account.

What happens if I paste the snippet but don't enable "Hide on Desktop"?

The raw JavaScript will render as visible text on the page for every visitor. It looks broken and exposes your snippet publicly.

Why does my staging site on ngrok not show data in the SeaText dashboard?

Dynamic development domains are restricted. Use a real subdomain (e.g., staging.example.com) with a valid SSL certificate.

Do I need to reinstall the snippet after an Odoo version upgrade?

Not typically. The Embed Code block persists across Odoo updates. However, if a major upgrade changes the Website module's block system, verify the block still exists and the snippet is intact.

How do I know the script is actually working?

Open the page in an incognito window, check the Network tab for a request to SeaText's domain returning 200, then confirm a live session appears in your SeaText dashboard within a minute.

Can I place the Embed Code block in the website footer instead of a specific page?

Yes. Placing it in a global footer or header block ensures the script loads on every page. Just remember to hide it on desktop there as well.

Is there a way to test without a live domain?

No. SeaText requires a real, resolvable domain to associate traffic. Localhost and tunneling services are explicitly blocked.

Yes, you can install SeaText AI on an Odoo staging or development environment to test functionality, configuration, and AI output quality without impacting your live customers. Each domain requires its own SeaText account, and localhost or dynamic development domains are restricted for security reasons.

Why Testing on Staging Matters for Odoo Stores

Odoo store owners often run staging sites to validate theme changes, module updates, and third-party integrations before pushing to production. SeaText AI injects JavaScript that rewrites copy, runs A/B tests, and translates content in real time. Testing on staging lets you verify that the script loads correctly, that AI-generated variants match your brand voice, and that translation or personalization rules behave as expected — all without exposing live shoppers to experimental changes.

The SeaText integration uses an Embed Code block inside Odoo's Website module. Because the script is inert until activated in your SeaText dashboard, you can place the snippet on staging, preview the changes in Odoo's editor, and only activate the account when you are satisfied.

How SeaText Licensing Works with Multiple Domains

SeaText ties each account to a single primary URL. If you run a staging domain (for example, staging.mystore.com) and a production domain (mystore.com), you need two separate SeaText accounts. The staging account will have its own dashboard, its own AI agents, and its own usage limits. This separation keeps staging experiments from polluting production analytics and prevents accidental activation of test variants on the live site.

Creating the second account is straightforward: sign up again with the staging URL, copy the new JavaScript snippet, and paste it into the Embed Code block on your staging Odoo instance. The two accounts operate independently.

Step-by-Step: Installing SeaText on an Odoo Staging Site

1. Log in to your Odoo staging instance and open the Website module.
2. Navigate to the page where you want the SeaText script to load (typically the homepage or a global layout). Click Edit.
3. In the Blocks panel, scroll to Dynamic Content and drag an Embed Code block onto the page.
4. Click the Edit button on the block's right panel.
5. Paste the JavaScript snippet from your staging SeaText account into the pop-up window and click Save.
6. Optional: In the block's Visibility section, enable Hide on Desktop if you only want the script active on mobile preview, then save again.
7. Refresh the staging page. Open your browser's developer tools and confirm the SeaText script appears in the network tab.
8. Log in to the staging SeaText dashboard and activate the agents you want to test (translation, CRO, SEO, etc.).

Because the script is loaded via Odoo's standard Embed Code block, it survives theme updates and cache clears just like any other custom code snippet.

Key Restrictions: Localhost and Dynamic Domains

SeaText explicitly restricts localhost and dynamic development domains (such as those generated by ngrok, temporary tunnel services, or ephemeral CI/CD preview URLs). The system cannot reliably associate traffic with your account on those addresses. For staging to work, you must use a valid, real domain name with a proper DNS record — for example, staging.yourdomain.com or a dedicated subdomain like test.yourdomain.com.

If your team currently tests on localhost:8069 or a temporary tunnel, you will need to provision a real subdomain pointing to the staging server before SeaText will function. This is a security measure to prevent abuse and ensure accurate analytics attribution.

Practical Scenarios: When Staging Testing Works and When It Doesn't

Scenario A: Dedicated Staging Subdomain (Recommended)

You own mystore.com and create staging.mystore.com on a separate Odoo database or a duplicated filestore. You register a second SeaText account for staging.mystore.com. Everything works: translation previews, A/B test variants, personalization rules, and bot-protection agents all run on staging traffic only.

Scenario B: Localhost or Docker Desktop (Not Supported)

Developers running Odoo locally on http://localhost:8069 or http://host.docker.internal:8069 cannot use SeaText. The script will load but the dashboard will show no traffic and agents will not activate. Workaround: use a real subdomain pointed to a cloud staging server, or use a VPN-accessible VM with a proper hostname.

Scenario C: Ephemeral Preview URLs (Not Supported)

CI/CD pipelines that spin up temporary preview deployments (e.g., pr-42-myapp.example.com) will not work reliably because the domain changes per deployment. SeaText expects a stable primary URL per account. Workaround: maintain a single long-lived staging domain and deploy preview builds there, or accept that SeaText testing only happens on that stable staging domain.

Key Facts

Limitations and When This Advice Does Not Apply

• If your staging environment is only accessible via localhost, a VPN without a real domain, or a constantly changing preview URL, SeaText will not work there.
• Each staging account incurs its own subscription cost; budget for two accounts if you maintain a permanent staging domain.
• AI agents trained on staging traffic (e.g., reading telemetry, conversion models) will not transfer to the production account. You will re-train or re-configure agents on the live domain after go-live.
• This guidance covers the JavaScript snippet installation via Odoo's Embed Code block. If you use a custom Odoo module or Cloudflare Workers edge deployment (available for enterprise plans), the domain restrictions still apply but the installation steps differ.

Terminology Quick Reference

• Primary URL — The single domain name associated with a SeaText account; used for traffic attribution and security.
• Embed Code block — An Odoo Website building block that allows raw HTML/JavaScript injection.
• Inert script — The SeaText JavaScript loads but performs no actions until you activate agents in the dashboard.
• Dynamic development domain — Temporary, auto-generated hostnames (e.g., ngrok tunnels, CI preview URLs) that change per session or deploy.

FAQ

Do I need a paid SeaText plan for the staging account?

Yes. Each account is billed separately. You can start with a trial on staging, but ongoing testing requires a subscription for that domain.

Can I copy the production SeaText configuration to staging?

There is no one-click configuration clone. You will need to recreate translation rules, A/B test variants, and agent settings in the staging dashboard manually or via API if your plan includes it.

Will staging traffic affect my production analytics?

No. Separate accounts mean completely separate dashboards, conversion funnels, and bot-detection logs.

What if my staging site is behind basic auth or a VPN?

SeaText's crawlers and edge scripts need public access to the domain to analyze content and serve variants. If the staging site is not publicly reachable, AI SEO agents and translation indexing will not work. CRO and personalization agents will still function for authenticated users who load the page.

Can I use the same SeaText account for staging and production by switching the primary URL?

No. The primary URL is fixed per account. Changing it would break attribution and require re-verification. Use two accounts.

How long does it take to set up SeaText on a new staging domain?

About 5 minutes: create account, copy snippet, paste into Odoo Embed Code block, save, activate agents.

Does SeaText work on Odoo.sh staging branches?

Odoo.sh provides stable branch URLs (e.g., staging-myproject.odoo.com). Those are real domains and will work, provided you register a SeaText account for that exact hostname.

How SeaText Can Help

SeaText provides 20 autonomous AI agents that handle conversion optimization, multilingual translation across 125 languages, AI SEO content generation, bot-click refunds, and ChatGPT brand visibility. On Odoo, the integration is a single JavaScript snippet placed via the standard Embed Code block. The script remains inert until you activate agents in the dashboard, so you can safely install it on staging, preview changes in Odoo's editor, and only go live when ready. Each domain needs its own account; localhost and dynamic preview URLs are not supported.

SeaText AI lets you translate your Odoo website without a manual localization project. After you embed a small JavaScript snippet, you sign in to the SeaText dashboard, sync your Odoo pages, pick the languages you need, and publish the translated versions. The whole process is designed to be self‑service and reversible at any time.

What You Need Before You Start

You need a SeaText AI account. Each account is tied to one primary URL. If you plan to use SeaText on a development domain and a production domain, create a separate account for each.

You also need admin access to your Odoo backend. The installation does not modify your database; the AI stays inactive until you activate it from the dashboard.

Step‑by‑Step Integration Process

Step 1: Log into Odoo

Sign in to your Odoo instance and open the Website module. This module contains all pages and themes you manage.

Step 2: Choose a Page

Browse to the page you want to translate. Click the “Edit” button to open the page builder.

Step 3: Find the Embed Code Module

In the left‑hand Blocks panel, scroll to the Dynamic Content section. Locate the Embed Code module inside that section.

Step 4: Place the Module

Drag the Embed Code module onto the page. A good spot is near the bottom of the content area, so it does not disturb your layout.

Step 5: Open the Module Settings

Click the “Edit” button that appears in the right‑hand panel. A pop‑up window will appear where you can insert code.

Step 6: Paste the SeaText Snippet

Copy the JavaScript snippet from your SeaText dashboard. Paste it into the pop‑up field, then click “Save”.

Step 7: Hide the Block on Desktop (Optional)

In the Visibility tab, enable “Hide on Desktop”. This prevents an empty block from showing on large screens. Save again to apply.

Step 8: Verify the Script

Refresh your site. If the script is active, you will see a small SeaText icon in the corner of the page. If not, double‑check the domain in your SeaText account matches the domain you installed the script on.

How SeaText Translation Works on Odoo

SeaText uses a client‑side AI agent. When a visitor loads a page, the agent detects the browser language and swaps the text with a translation generated by the AI. The original content remains in the source, so you can revert changes at any time.

The agent supports 125 languages. It runs entirely in the browser, so no server‑side configuration is required. You retain full control over which languages appear and when they go live.

Managing Translations from the SeaText Dashboard

After the snippet is installed, open the SeaText dashboard. Click the “Sync Odoo Content” button. SeaText will crawl your site and store the text strings in its translation memory.

Next, choose the target languages. You can select all 125 languages or only the ones relevant to your markets. The dashboard shows a list of supported languages with checkboxes.

Once languages are selected, click “Generate Translations”. The AI creates a draft version for each language. You can preview each translation directly in the dashboard.

If a translation needs adjustment, use the inline editor. You can change a single phrase or replace an entire block. When you are satisfied, click “Publish”. The updated text is pushed to your site instantly.

The dashboard also provides a version history. You can roll back to a previous translation set if needed.

Limitations and Trade‑offs of AI Translation on Odoo

AI translation is fast and free, but it is not perfect. The quality depends on the complexity of your sentences. Short product names usually translate well. Long paragraphs with idioms may require human review.

For SEO, AI‑generated pages can rank, but they may lack the nuance that a human writer provides. Search engines reward unique, high‑quality content. If you rely solely on AI, monitor your search rankings and consider adding a human‑reviewed glossary for key terms.

The JavaScript snippet adds a small overhead to each page load. On most sites the impact is under 50 ms. On very large pages with many scripts, the delay can increase. Test on a staging environment to measure the effect.

Dynamic content that loads after the page render, such as AJAX‑loaded product details, may not be captured automatically. You can trigger a re‑scan by calling a SeaText function, but this requires custom code.

Development domains (e.g., localhost) are blocked for security. Use a real domain that points to your server. If you need to test on a temporary subdomain, add it to your account first.

Key Facts About SeaText Odoo Integration

Important Restrictions and Security Considerations

Each SeaText account is linked to a single primary URL. To use the service on multiple domains, create a separate account for each. Do not share credentials across sites.

Dynamic development domains may not function correctly. The system needs a stable, resolvable domain to associate traffic with your account.

The script is loaded from SeaText servers. Ensure your firewall allows connections to the SeaText domain. If you use a content‑delivery network, verify that the script can execute.

Common Mistakes to Avoid

• Wrong domain: The domain in your SeaText account must match the site where the snippet is installed.
• Forgetting to hide the block: Without “Hide on Desktop”, an empty placeholder may appear.
• Pasting code in the wrong module: Use only the Embed Code module under Dynamic Content.
• Saving after paste: Always click “Save” to apply the snippet.
• Skipping language selection: Not choosing languages results in no translations.

What to Do After Installation

Open the SeaText dashboard. Click “Sync Odoo Content” to import your pages. Select the languages you want, then generate translations. Review the drafts and publish when ready.

If you need to expand to additional domains, create a new account for each. The dashboard will show separate projects for each domain.

Frequently Asked Questions

Do I need coding skills to install SeaText on Odoo?

No. You only need to drag a module and paste a snippet. No custom code is required.

How many languages can I translate into?

SeaText supports 125 languages, covering most global markets.

Can I use one account for multiple Odoo sites?

No. Each account is tied to one primary URL. Create separate accounts for each site.

Will translations appear automatically?

Yes. After you publish from the dashboard, the AI agent serves the translated text to visitors in real time.

Is the installation safe for my site?

Yes. The script is inert until you activate it. Your original content remains untouched.

What if I use a localhost domain?

Development URLs are restricted. Use a valid, real domain instead.

How do I get the JavaScript snippet?

After creating an account, the snippet appears in the SeaText dashboard. Copy it from there.

Can I review translations before they go live?

Yes. The dashboard provides a preview mode for each language. You can edit any string before publishing.

What happens if I need to revert changes?

The dashboard keeps a version history. You can restore a previous translation set with one click.

How SeaText Matches Your Google Ads Keywords to Landing Pages

When someone clicks your Google ad, SeaText detects the exact keyword that triggered the click. Before the landing page loads, the AI rewrites the headline, key copy, offers, and calls-to-action to mirror that search term. The result is a landing page that feels like it was written specifically for that visitor.

For example, if you run ads for "office space" and "short-term stay," SeaText will show different headlines and descriptions to each audience — even though you only have one page. This means you don't need to build dozens of separate landing pages. One page adapts to every keyword.

The system reads the keyword from URL parameters that Google Ads appends when a user clicks. Common parameters include gclid and keyword insertion values. SeaText's script executes in the browser before the page renders, so there is no visible flicker. The source describes this as "0ms zero-flicker" technology. The original HTML remains unchanged for search crawlers, so SEO is not affected.

Each keyword reflects a unique visitor intent. A generic landing page fails to meet that specific intent. SeaText automatically fine-tunes your website text in real time to perfectly match each visitor's search term. This happens for every click, even for keywords with only 1–2 clicks per month.

The Key Benefits for Google Ads Campaigns

SeaText reports a +35% increase in conversion rate from keyword-level matching. One client saw a 35% conversion lift within days of activation. The biggest gains came from message relevance — the AI automatically adapts text to each keyword, driving a 20% increase in sales.

Higher relevance also improves your Google Ads Quality Score. When your landing page content closely matches the user's search, Google rewards you with lower cost-per-click and better ad positions. SeaText makes this automatic. The source states: "SEATEXT AI rewrites your pages to perfectly match search intent. These optimized pages keep visitors engaged and improve your Quality Scores, helping you get clicks cheaper."

Additionally, SeaText includes a Bot Protection Agent that detects invalid clicks from bots. It automatically generates forensic reports you can submit to Google to claim refunds for wasted ad spend. Clients have reported recovering up to 20% of ad spend this way. The source mentions $1.2M recovered across clients.

The platform also offers a Conversion Relay (CAPI) that forwards 100% of real purchases to Meta and Google CAPI, an Intent Amplifier that sends high-intent buyer signals to ad algorithms, and a Visitor Source Rewrite Agent that matches landing pages to Google, Meta, email, and referral campaigns for up to +30% conversion lift.

Step-by-Step: How to Set Up SeaText for Your Ads

Getting started with SeaText for your Google Ads campaigns takes a few minutes. Here is the process:

1. Add SeaText to your website. You install a small script — the source says it takes under 1 minute. No developer needed.
2. Connect your Google Ads account. SeaText automatically detects keywords from your ad URL parameters. It lists them in a dashboard.
3. Choose which keywords to personalize. You select the keywords you want the AI to rewrite. You can also set instructions or manually edit the new copy.
4. Review the rewritten pages. SeaText shows you how each version will look. You can approve, edit, or turn off optimization for specific keywords.
5. Let the AI run. Once active, every new ad click triggers a real-time rewrite. The system works even for keywords with very low traffic — just 1–2 clicks per month.

You remain in control. You can pause the optimization for any keyword at any time. The dashboard lets you see each keyword's rewritten version, conversion rate, and performance metrics.

A free 1-month pilot trial is available. The source mentions "Free 1-Month Pilot Trial" on the Google Ads landing page. Over 2,500 frontier marketing teams use the platform.

How the AI Rewrites Content in Real Time

SeaText uses a combination of keyword detection, intent classification, and generative AI to rewrite page elements. When a visitor arrives via a Google ad, the script reads the keyword from the URL. It then classifies the intent — for example, "office space" suggests commercial leasing intent, while "short-term stay" suggests temporary housing.

The AI selects or generates headline variations, body copy adjustments, offer phrasing, and CTA text that align with that intent. It can also swap product blocks, pricing displays, and testimonials. The source notes it rewrites "headlines, offers, and CTAs" and "product blocks" to continue the exact promise in the ad.

You can give the AI instructions for specific keywords. For instance, you might tell it to emphasize "flexible terms" for "short-term stay" searches. You can also manually edit any rewrite before it goes live. The system supports 125 languages, so international campaigns get localized copy automatically.

Auto A/B testing runs in the background. The AI generates multiple copy variants, measures performance, and scales the winners. This happens without manual test setup. The source lists "Auto A/B text testing" as a feature.

Bot Detection and Ad Spend Recovery

Invalid traffic from bots, VPNs, and click farms wastes budget and pollutes conversion data. SeaText's Bot Protection Agent analyzes each click for signals of non-human behavior — such as mouse movement patterns, scroll depth, session duration, and IP reputation.

When bot traffic is detected, the system compiles a forensic report with timestamps, IP addresses, behavioral anomalies, and other evidence formatted for Google's refund request process. You submit this report to Google Ads support to claim a refund. The source states clients see up to 20% return on ad spend from this feature, with $1.2M recovered in total.

A related agent, Detect VPN Ad Clicks, specifically targets overseas VPN traffic that masks bot origins. The Shielded Buyers & Ad Firewall protects high-intent leads from competitor retargeting after they visit your site.

Note: SeaText provides the evidence, but you must file the claim yourself. Google's refund approval is not guaranteed.

Beyond Google Ads: Multi-Channel Personalization

While the core use case is Google Ads, SeaText applies the same keyword-matching logic to other traffic sources. The Visitor Source Rewrite Agent adapts landing pages for Meta (Facebook/Instagram) ads, email campaigns, referral links, and organic search referrers.

For Meta campaigns, the Conversion Relay (CAPI) forwards verified purchase events to Meta's Conversions API, improving attribution and algorithm optimization. The Intent Amplifier sends high-intent signals — such as scroll depth on pricing sections or time on product pages — to both Google and Meta ad algorithms.

The ChatGPT Brand Visibility Agent shapes how your brand appears when buyers ask AI assistants for recommendations. The source notes 52% of buyers compare brands in ChatGPT. This agent publishes structured Q&A content that AI models cite.

Website Translation Agent translates your entire site into 125 languages with zero code and full editorial control. This opens new markets — the source reports +60% more international customers.

What SeaText Cannot Do (Limitations)

SeaText is not a replacement for good ad copy, keyword research, or bid management. It only optimizes the landing page experience after the click. Your ad headlines, targeting, and budget still need your attention.

Also, SeaText works best for websites that have a single landing page per campaign or ad group. If you already have highly specific, unique landing pages for each keyword, the benefit may be smaller. The tool is designed for cases where many keywords land on the same generic page.

SeaText does not automatically create new landing pages from scratch. It rewrites the existing content on your page. So you need to have a page with relevant copy to begin with.

The bot refund feature depends on your ability to submit reports to Google. SeaText provides the evidence, but you must file the claim yourself. Google's approval is not guaranteed.

The AI rewrites are limited to text content — headlines, body copy, CTAs, offers. It does not redesign page layout, change images, or modify functionality. For complex product pages, you may need to structure content so the AI can meaningfully adapt sections.

Pricing details are not fully public. The source shows a "Click here for pricing" link and mentions "Get up to 5 keywords free." Enterprise features like WebMCP (turning your site into an MCP server for Claude and ChatGPT) may require custom agreements.

Frequently Asked Questions

Does SeaText work with all Google Ads account types?

Yes, SeaText works with any Google Ads account that sends traffic to a website. It detects the keyword from the URL parameter and rewrites the page regardless of campaign type (Search, Display, Shopping, etc.).

How long does it take to see results?

Some users report conversion improvements within days. The source mentions a 35% increase in conversion rate within days of activation. However, results depend on your current page relevance and traffic volume.

Can I use SeaText for multiple campaigns with different landing pages?

Yes. SeaText can apply different rewrites based on the keyword. You can manage which keywords trigger which rewrites from the dashboard. Each landing page gets its own set of keyword-matched versions.

Does SeaText affect my website speed or SEO?

SeaText rewrites happen in real time with zero flicker (0ms). The source says it uses "0ms zero-flicker" technology. This does not affect your site's load time or search engine rankings because the original page remains unchanged for crawlers.

What if I don't like the rewritten version?

You can review every rewrite before it goes live. You can manually edit the text, give the AI instructions on how to improve, or simply turn off the optimization for that keyword. Full control is built in.

Does SeaText work with Meta (Facebook/Instagram) ads?

Yes. The Visitor Source Rewrite Agent matches landing pages to Meta campaigns, and the Conversion Relay forwards purchases to Meta CAPI. The Intent Amplifier sends signals to Meta's algorithm.

Can SeaText translate my landing pages for international campaigns?

Yes. The Website Translation Agent translates your site into 125 languages with zero code. You retain full editorial control over translations.

Is there a free trial?

The source mentions a "Free 1-Month Pilot Trial" and "Get up to 5 keywords free." Check the pricing page for current terms.

Final Thoughts

SeaText is a practical tool for anyone running Google Ads campaigns who wants to improve conversion rates without building multiple landing pages. It addresses the common problem of a single generic page serving many different search intents. By dynamically matching your landing page to each keyword, you increase relevance and can lower your ad costs over time.

The bot refund feature is an added bonus that helps recover budget from invalid clicks. If you have a high volume of ad traffic and limited resources to personalize landing pages, SeaText is worth testing.

Beyond Google Ads, the platform's multi-agent architecture — covering conversion optimization, bot defense, translation, AI visibility, and cross-channel attribution — makes it a comprehensive conversion infrastructure for growth teams. The 2,500+ brands using it include enterprise clients like Visa and P&G Mexico, per the source testimonials.

Hiding an Odoo website block seems simple, but the common mistakes are easy to make. You might hide the block for every device when you only meant to hide it on desktop. You might use a CSS selector that hits the whole page. Or you might forget a media query and end up with a layout shift. The good news: Odoo gives you a built-in Visibility section, and the Seatext integration uses it to hide a block on desktop safely. If you use the wrong approach, you risk a broken page that repels visitors.

Why Hidden Odoo Blocks Break Your Layout

Before you fix a mistake, you need to recognize what it does. On the surface, "hide this block" sounds final. In practice, the method decides whether the block leaves a gap, overlaps other content, or still appears on one device.

The most common symptom is a blank area where the block used to be. Another symptom is text jumping when the page loads. Sometimes the block never hides at all, because a later CSS rule overrides yours.

The root cause is almost always a mismatch between your intent and the CSS or Odoo setting you used. Knowing that makes the next sections easier to follow.

Mistake 1: Hiding a Block That Odoo Can Hide for You

Odoo's Website Builder gives each block an Edit button. Inside that panel, you will find a Visibility section. The Seatext integration guide shows one option: "Hide on Desktop". That option does what it says and takes care of the responsive behavior for you.

If you ignore that and write custom CSS, you have to write the exact selector and the right media query. One typo and the block stays visible. So whenever the block has a visibility option, use it first.

Custom CSS still has a place, but only for cases Odoo does not cover. For example, if you need to hide a block for a specific page or after a certain scroll position, you need CSS.

Mistake 2: Using a Selector That Catches More Than the Block

Odoo blocks come with generated classes like .s_text_image or .o_footer. If you write "section { display: none; }", you hide every section on the page. That is the mistake.

Always use a specific class or ID for the block you want to hide. Right-click the block in your browser and choose Inspect. Look for a class that appears only on that block. Test the selector in the browser console before adding it to your theme.

Also avoid using inline styles in the block's HTML. They are hard to maintain and override the same element's responsive rules.

Mistake 3: Missing or Reversing Media Queries

Media queries let you apply CSS only at certain screen sizes. To hide a block on mobile, use "@media (max-width: 767px)". To hide on desktop, use "@media (min-width: 768px)". Mixing them up is the classic mistake.

People also forget the closing brace or write the media query inside the CSS rule. Put the media query outside your normal rule and keep the braces balanced.

Use the same breakpoints as your theme, usually 576, 768, 992, and 1200 pixels. Don't invent a breakpoint that lands in the middle of a common device width.

Mistake 4: Not Testing on Real Screens

The Odoo editor shows the page inside a preview area, but it doesn't always match every phone. You test on a desktop and the block disappears, but on a phone it stays visible because the media query didn't fire.

Use your browser's device toolbar to simulate a phone and tablet. Then send the test link to a real phone. Check both portrait and landscape. Also refresh the page after hiding the block to make sure no cache or optimizer brings it back.

Mistake 5: Editing Odoo's Core Files

Odoo stores its styles in SCSS files that get compiled on upgrade. If you edit those files directly, your changes will be overwritten and can break other parts of the site.

Instead, put your custom CSS in the theme's custom CSS field. In Odoo, go to Website > Configuration > Settings, or use the Theme editor's custom code area. That keeps your hiding rules separate and safe.

If you use a third-party module that embeds code, like the Seatext integration, follow its instructions and place the code in the provided block. Do not patch the module file.

How to Diagnose and Fix a Hiding Problem

Here is a quick order to follow when a block looks wrong after hiding.

1. Write down the exact symptom. Does the block show on all devices, or only on one? Is there a gap?
2. Open your browser's developer tools and select the block. Look for a rule that sets display:none or visibility:hidden. Note the selector and the media query.
3. Check the block's Visibility section in Odoo's editor. If it has a "Hide on Desktop" option and you meant to hide it on mobile, change the setting or write a mobile media query.
4. If you used a selector, make it more specific. Add a class to the block if needed.
5. Put your custom CSS in the theme's custom CSS field, not in the HTML.
6. Test on desktop, tablet, and mobile. Use your browser's device toolbar and a real device.

When Hiding a Block Is the Wrong Move

Hiding blocks is not always a good idea. If you hide a section that contains a key message or a call-to-action, desktop visitors may never see an important offer. If you hide a menu link for mobile, users lose a main way to navigate.

Also consider SEO. A block hidden with CSS is still in the page source. That is fine. But if you use Odoo's "Hide on Desktop" option, the text is still indexed. That is good. The risk is hiding content that search engines should weigh higher, like a unique FAQ or a product description.

If a block serves no purpose, delete it instead of hiding it. That reduces clutter and avoids confusion for future editors.

Key Facts: The Built-in Visibility Option

Hiding an Odoo website block means making it invisible on some or all devices while keeping it in the page structure. The safest way is to use Odoo's built-in visibility options; custom CSS is for cases where those options are not enough.

Frequently Asked Questions

Why does my hidden block still take up space?

Because you likely used visibility: hidden instead of display: none. The first keeps the space, the second removes it. If you used Odoo's "Hide on Desktop" option, it should remove the block from view properly.

How do I hide a block on mobile only in Odoo?

Use a media query with a max-width. For example, "@media (max-width: 767px) { .my-block { display: none; } }". Make sure the selector targets only that block.

Is there a difference between "Hide on Desktop" and custom CSS?

Yes. The built-in option is easier and less error-prone. It does not require you to know CSS or manage media queries. Custom CSS gives you more control when the built-in option doesn't cover your case.

Can hiding a block hurt my SEO?

Not by itself. Hidden content is still in the HTML and can be indexed. The risk is hiding important content that users and search engines should see. Use hiding for design clarity, not for hiding content you don't want indexed.

What if my CSS override still doesn't hide the block?

Check the order of your styles. A rule later in the file wins if it has the same specificity. You might need a more specific selector or add !important as a last resort. Also check that the media query is matching the width.

Hiding the SeaText block on desktop is a deliberate UX choice. On larger screens, you often have more space for navigation, sidebars, and multiple conversion elements. A persistent widget that works well on mobile can overlap with desktop menus, cover important content, or simply add noise when visitors are already engaged with a richer layout. The SeaText Odoo integration includes a "Hide on Desktop" toggle in the Visibility section precisely for this reason — so you can show the widget where it helps most (mobile) and remove it where it might hurt (desktop).

What changes if you don't hide it

Leaving the block visible on desktop can create three problems. First, visual clutter: desktop users scan pages differently than mobile users, and an extra fixed element competes with headlines, product images, and primary CTAs. Second, overlap risk: the widget may sit on top of sticky headers, cookie banners, or chat launchers, making those elements hard to reach. Third, diluted focus: if you already run a desktop-specific chat, quiz, or calculator, two simultaneous prompts confuse the visitor and split attribution data.

How the visibility toggle works in Odoo

In the Odoo Website editor, after you drag the "Embed Code" module into a page, you open the right-panel editor, paste the SeaText snippet, and then open the Visibility section. There you'll find a checkbox labeled "Hide on Desktop." Checking it adds a CSS media query that sets display: none for viewports above the tablet breakpoint. The block still loads in the DOM — so the script initializes — but it never renders on desktop. This means SeaText's reading telemetry and personalization agents still collect data; only the UI element is suppressed.

When to show vs. hide: a decision framework

1. Audit desktop layout. Open the page at 1440px width. Note every fixed or sticky element (header, chat, cookie bar, side rail).
2. Map conversion goals. List the primary action you want on desktop (demo request, add to cart, newsletter sign-up).
3. Check for conflict. Does the SeaText block occupy the same visual zone as any primary CTA? If yes, hide it.
4. Test mobile-only hypothesis. Run a two-week test: widget on mobile only. Compare mobile conversion rate and engagement metrics against the prior period.
5. Re-evaluate. If mobile lifts but desktop drops, keep the hide. If desktop also benefits from the widget (rare), consider a desktop-specific variant instead.

Trade-offs: mobile-first widget vs. desktop parity

Takeaway: Choose "Hide on Desktop" when desktop already has a strong conversion path. Choose "Show on Both" only if the widget is the primary conversion mechanism on every device.

Practical scenarios where hiding helps

• Sticky header + chat launcher: The SeaText block sits bottom-right; the chat launcher sits bottom-right. On desktop they collide. Hide the block; keep the launcher.
• Side-rail navigation: B2B sites often use a left rail. A right-side widget narrows the content column, pushing copy below the fold. Hide on desktop; let mobile users get the full-width experience.
• Multi-step form wizard: Desktop visitors are in a guided flow. An extra prompt breaks momentum. Hide the block until the thank-you page.
• High-density product grids: Category pages with 4-column grids leave little whitespace. A floating block covers product cards on hover. Hide it.

Limitations and when this advice doesn't apply

• Single-page apps with client-side routing: The Odoo visibility toggle relies on server-rendered CSS classes. If your desktop view is hydrated after initial load, the media query may not apply until a re-render. Test in your framework.
• Custom breakpoints: Odoo's "Hide on Desktop" uses its default breakpoint (~992px). If your design system uses 1200px or 1024px, the widget may appear on devices you consider desktop. You'll need custom CSS.
• Accessibility requirements: If the widget provides critical functionality (e.g., language selector for non-English visitors), hiding it on desktop may violate WCAG 2.1 AA. Provide an alternative access path.
• A/B testing the widget itself: If you're testing widget copy or position on desktop, you must show it. Use SeaText's split-URL agent instead of the visibility toggle.

Key facts

Terminology

• Embed Code module: Odoo's block for inserting raw HTML/JS snippets.
• Visibility section: Odoo's responsive display controls (Hide on Desktop, Hide on Mobile, etc.).
• Reading telemetry: SeaText's millisecond-level tracking of scroll, dwell, and re-read behavior.
• Breakpoint: The viewport width at which CSS media queries switch layouts.

FAQ

Does hiding the block on desktop stop SeaText from collecting data?

No. The JavaScript snippet still loads and runs; only the visual element is hidden via CSS. Reading telemetry, personalization signals, and conversion relay continue to function.

Can I hide the block on tablet but show on mobile and desktop?

Odoo's native toggle only offers "Hide on Desktop" and "Hide on Mobile." For tablet-specific control, add custom CSS targeting your tablet breakpoint (e.g., @media (min-width: 768px) and (max-width: 1024px)).

What if my desktop conversion rate drops after hiding the widget?

Run a controlled A/B test: 50% of desktop traffic sees the widget, 50% doesn't. Measure primary conversion (not just clicks on the widget). If the no-widget variant wins, keep it hidden.

Is there a performance cost to loading the script but hiding the UI?

Negligible. The script is ~30 KB gzipped and loads asynchronously. The DOM node exists but remains display: none, so no layout or paint cost occurs on desktop.

Can I show a different widget variant on desktop instead of hiding?

Yes. Create a second SeaText account for the desktop variant, generate its snippet, and place it in a separate Embed Code module with "Hide on Mobile" checked. This gives you independent copy, positioning, and testing on each device class.

How do I verify the hide is working?

Open the page in Chrome DevTools, toggle the device toolbar to a desktop viewport (e.g., 1440×900), and inspect the widget container. It should have display: none or be absent from the rendered tree. Then switch to a mobile viewport (e.g., 375×667) and confirm it appears.

Does SeaText charge extra for multi-device visibility rules?

No. The visibility toggle is part of the Odoo module and SeaText's standard script. Pricing is per domain/account, not per visibility configuration.

SeaText variants are the AI-generated copy alternatives — headlines, product descriptions, CTAs, translated versions — that the platform creates and tests on your Odoo pages. You should update them whenever the underlying product data changes: a price adjustment, a stock-level shift, a new attribute (size, color, material), or a revised translation. If the source-of-truth in Odoo moves but the variant pool stays stale, visitors see mismatched offers and the AI optimizes against outdated signals.

What SeaText Variants Are in an Odoo Context

SeaText connects to Odoo through a JavaScript snippet you embed via the Website module's "Embed Code" block (see the Odoo Integration guide). Once active, SeaText's AI agents — notably the AI Copy A/B Testing agent, the Ecommerce Product Copy agent, and the Website Translation (125 Langs) agent — read the page content, generate multiple copy variants, and serve them to visitors in real time. Variants can include:

• Alternative product titles and descriptions
• Different CTA phrasing ("Buy now" vs "Add to cart" vs "Get yours")
• Translated versions for each of the 125 supported languages
• Personalized copy based on visitor context (referrer, geo, device)

These variants live in SeaText's cloud; the Odoo page remains the canonical source for product data (price, SKU, stock, attributes). When that canonical data changes, the variant pool must be refreshed so the AI isn't testing against yesterday's catalog.

Readiness Checklist: Update Variants When…

Signs You Can Wait

• Only cosmetic Odoo theme changes — moving blocks, adjusting fonts, hiding the Embed Code block on desktop (via "Hide on Desktop" visibility) — don't alter product data, so variants stay valid.
• Traffic-source shifts without offer changes — if you launch a new ad campaign but the landing product and price are identical, the AI Personalization Agent adapts copy to the referrer automatically; no manual variant update required.
• Scheduled crawl hasn't run yet — SeaText re-crawls on a regular cadence. If you just saved a price change in Odoo, wait for the next crawl (typically under 30 minutes) before forcing a refresh.

Exception: Multi-Domain Setups Need Separate Updates

If you run SeaText on multiple domains — say a staging Odoo instance and a production instance — each domain requires its own SeaText account (the integration docs state "Each SEATEXT AI account is linked to a single primary URL"). Updating variants on production does not propagate to staging. You must repeat the readiness checklist for each domain's account. Development URLs like localhost are restricted for security, so use a real domain (e.g., staging.yourbrand.com) for testing.

How the Update Flow Works

1. You edit product data in Odoo (price, stock, attributes, description, translations).
2. Odoo serves the updated page HTML to visitors and to SeaText's crawler.
3. SeaText's crawler detects content changes on the next scheduled visit.
4. The AI agents (Copy A/B Testing, Product Copy, Translation) regenerate variant pools based on the fresh source text.
5. New variants enter the multi-armed bandit rotation; underperforming old variants are retired automatically.

No manual "push" from Odoo to SeaText is needed if the embed code remains on the page and the domain is verified in your SeaText account.

Key Facts

Limitations & When This Advice Doesn't Apply

• Headless Odoo / API-only catalogs — if your frontend doesn't render the Embed Code block, SeaText can't see product data. You'd need a server-side feed or the WebMCP agent (turns your site into an MCP server for Claude/ChatGPT).
• Static site generators pulling from Odoo — variants update only when the static build re-runs and the SeaText snippet is present on the deployed pages.
• Custom Odoo modules that override product templates — if the rendered HTML structure changes drastically, SeaText's selectors may miss the product data. Test after major template changes.
• Price rules computed at checkout only — if the PDP shows a list price but the real price depends on a pricelist rule applied in cart, SeaText variants will optimize for the list price. Consider exposing the computed price in the page meta for the crawler.

Terminology Quick Reference

• Variant — an AI-generated alternative version of a text element (headline, description, CTA, translation).
• Multi-armed bandit — an algorithm that allocates more traffic to better-performing variants in real time, instead of a fixed 50/50 split.
• Embed Code block — Odoo Website module block (under Dynamic Content) used to paste third-party JavaScript.
• Primary URL — the single domain linked to a SeaText account; each domain needs its own account.
• Crawl — SeaText's automated visit to your pages to read current content and refresh variant pools.

FAQ

How often does SeaText re-crawl my Odoo pages?

On a regular automated schedule; changes typically appear in the variant pool within 30 minutes. You can trigger a manual re-crawl from the SeaText dashboard if you need it faster.

Do I need to update variants after changing only the Odoo theme?

No. Theme-only changes (layout, colors, hiding the Embed Code block on desktop) don't alter product data, so existing variants remain valid.

What happens if I change a product price but forget to update variants?

SeaText will eventually re-crawl and refresh variants automatically. Until then, visitors may see copy referencing the old price, which can cause confusion and distort test results.

Can I use one SeaText account for my staging and production Odoo sites?

No. Each primary URL requires its own SeaText account. Create a separate account for staging (use a real domain like staging.yourbrand.com; localhost is blocked).

Does SeaText update translated variants when I edit the source language in Odoo?

Yes. The Website Translation agent re-generates translations for all 125 enabled languages when it detects source-text changes on re-crawl.

What if my Odoo product uses dynamic pricelists that only apply at checkout?

SeaText reads the rendered PDP. If the page shows a list price but the real price is computed later, variants will optimize for the list price. Expose the computed price in page meta or a data attribute for accurate variants.

How do I know variants have actually updated?

Open the SeaText dashboard → Variants panel → check the "Last updated" timestamp per variant group, or use the preview mode to see live variants on your Odoo page.

To improve Google Ads landing page relevance, make the page headline, copy, offer, and CTA match the exact keyword and promise in the ad. Use automation to do this dynamically at scale. This ensures every visitor sees a page built for their search.

How Google Measures Landing Page Relevance

Google uses Quality Score to judge landing page relevance. The score is based on how well your page matches the ad and the keyword. Google looks at the headline, the main copy, and the call-to-action. If the page does not match the ad, the Quality Score drops.

A low Quality Score means you pay more per click. Google also checks bounce rate and time on site. If visitors leave quickly, Google sees low relevance. This is not just about keywords. It is about the full experience. The offer must match the ad promise. The page must load fast. The layout must work on mobile.

Google also considers historical performance. A page that has always matched well will get a better score. New pages take time to build trust. The key is to align every element of the page with the search intent behind the ad.

Step-by-Step Optimization Checklist

1. Identify the keyword intent. Is the user looking to buy, compare, or learn? Your page must match that intent.
2. Write a headline that includes the exact keyword. The headline should be the first thing the visitor sees. It must confirm they are in the right place.
3. Mirror the ad copy. If the ad says “30% off”, the page must say “30% off” in the same place. Do not change the offer.
4. Use the same CTA language. If the ad says “Get Started Now”, the page CTA should say “Get Started Now”.
5. Remove distractions. Do not show unrelated links or offers. Keep the page focused on the single goal.
6. Match the offer to the keyword. If the keyword is “blue running shoes”, show blue running shoes on the page. Do not show a general shoe category.
7. Optimize for mobile. Test the page on a phone. The headline and CTA must be visible without scrolling.
8. Check page speed. Use Google PageSpeed Insights. Aim for under 3 seconds load time.
9. Add social proof. Include reviews or testimonials that mention the specific product or service.
10. Track conversions by keyword. Use Google Ads conversion tracking to see which keywords drive sales. This data helps you refine your pages.

How to Test Relevance Improvements

Testing is essential to know if your changes work. Start with a simple A/B test. Create two versions of the same landing page. Change only the headline or the offer. Run both versions at the same time. Split traffic evenly between them.

Measure bounce rate, time on page, and conversion rate. Use Google Optimize or a similar tool. If you have low traffic, use a multi-armed bandit approach. This allocates more traffic to the winning variant faster.

You can also test with dynamic rewriting tools. These tools test multiple variants on live traffic automatically. They report which keyword-variant combination performs best. Look for a tool that provides conversion data by keyword. This lets you see which pages work for each search term.

Another way to test is to use reading telemetry. This measures how people read your page. It shows where they pause or get confused. Use that data to improve the copy. The goal is to reduce friction and increase relevance.

The Process of Dynamic Adaptation

Dynamic rewriting is the fastest way to scale relevance. It works by detecting the keyword that triggered the ad click. Before the page loads, the system swaps the headline, copy, offer, and CTA to match that keyword. The page becomes a custom landing page for every visitor.

Here is how it works step by step:

1. Keyword detection: The system reads the Google Ads click data. It identifies the exact search term used.
2. Real-time rewrite: The page elements are replaced with content that matches the keyword. The original page structure stays the same, but the text changes.
3. Contextual continuity: The new content continues the promise from the ad. If the ad promised a free trial, the page leads with that offer.
4. Conversion tracking: The system logs the variant shown and the conversion result. This data is reported by keyword, page, and variant.

This approach works for thousands of keywords. One page can serve many searches. The key is to have a library of headlines, offers, and CTAs ready. The system chooses the best match based on the visitor's intent.

Some tools also allow you to change product blocks and images. This creates a fully personalized experience. But be careful not to change too much. The brand identity should remain consistent.

Limitations and Trade-offs

Dynamic rewriting is not perfect. It has several limitations you should know.

Brand consistency: If you change too many elements, the page can look disjointed. Visitors may lose trust. Keep the design and layout the same. Only change the text that matters.

Over-personalization: Matching every keyword too closely can hurt. Some keywords are very similar. The page might end up with dozens of nearly identical versions. This confuses the user and the analytics.

Tracking setup: You need proper conversion tracking to measure success. Without it, you cannot know which variants work. Set up Google Ads conversion tracking and use a tool that reports by keyword.

Manual pages are sometimes better: For high-value keywords, a custom-built page may outperform a dynamically rewritten one. Manual pages allow full control over design and content. Use dynamic rewriting for long-tail keywords and low-traffic terms. Use manual pages for your top 10% of keywords.

Bot detection: Some clicks come from bots. These clicks inflate your metrics. Use a tool that filters out bot traffic. Only measure real visitor behavior to gauge relevance.

Testing required: Dynamic rewriting is not set-and-forget. You need to test variants continuously. What works today may not work tomorrow. Review your data weekly.

Common Mistakes with Examples

Mismatched headline: You run an ad for “affordable web hosting” but the landing page headline says “Premium Web Hosting”. The visitor leaves because they think the page is too expensive. Fix: Use the exact keyword in the headline.

Wrong offer: Your ad promises a free ebook. The landing page asks for a credit card to download. The visitor feels tricked. Fix: Deliver exactly what the ad promised.

Generic page: You send all ad traffic to the homepage. The homepage does not mention the specific product from the ad. Bounce rate jumps. Fix: Create a dedicated landing page for each ad group, or use dynamic rewriting.

Ignoring mobile: Your page looks great on desktop but loads slowly on mobile. The headline is cut off on a small screen. Visitors leave before the page fully loads. Fix: Test every page on a real phone. Use responsive design.

Too many distractions: Your page has a navigation bar, multiple offers, and pop-ups. The visitor cannot find the main CTA. They leave confused. Fix: Strip the page down to one goal. Remove all links that lead away from the conversion.

Not tracking conversions: You change the page but do not track which keyword drove the sale. You cannot tell if the change helped. Fix: Set up conversion tracking by keyword. Use a tool that reports data at the keyword level.

Frequently Asked Questions

How do I know if my landing page is relevant enough?

Check your bounce rate and conversion rate by traffic source. If visitors from specific ads leave quickly, your page likely fails to meet expectations. Also check your Quality Score in Google Ads. A score below 5 means you need to improve relevance.

Does changing my landing page content hurt SEO?

Not if done correctly. Dynamic rewriting changes the page content for individual visitors. It does not affect the cached version that search engines see. Use a tool that serves the original HTML to crawlers and the rewritten version to ad traffic.

What should I look for in a dynamic rewriting tool?

Look for real-time keyword detection, zero-flicker swapping, conversion tracking by keyword, and bot detection. The tool should also allow you to set rules for when to rewrite and when to show the original page.

How much does it cost to improve relevance?

Manual optimization costs time and resources. A/B testing tools are free or low-cost. Dynamic rewriting tools are usually subscription-based. The cost is often offset by lower CPC and higher conversion rates. Many tools offer a free trial.

Short answer: yes, with a script condition

Seatext can personalize based on referral source. Its Visitor Source Rewrite Agent, also listed as the Visitor Source Adaptation Agent, matches landing page content to the traffic source. Seatext's homepage states that visitors from Google, Meta, email, articles, and referrals see the page and offer that match where they came from.

For Notion, the answer is still yes, but the condition is technical. The personalization logic runs through Seatext's script, so your Notion site needs to be able to load that script. If it can, the agent can rewrite the page for each source. If it cannot, you will need to host the personalized page somewhere Seatext can control.

What referral-source personalization means

Referral-source personalization means the page changes based on where the visitor came from. It does not mean the page changes based on who the visitor is.

Seatext names five sources in its own materials: Google, Meta, email, articles, and referrals. Each source carries a different expectation. A visitor from a Google ad searched for something specific. A visitor from an email campaign already knows your offer. A visitor from a referral article is still learning about options.

When the page matches that expectation, the visitor is more likely to stay and act. When it does not, they often leave.

Why this matters for Notion sites

If you publish a website with Notion, you probably care about the same outcome: turning visitors into customers. A generic Notion page treats every visitor the same. Referral-source personalization treats a Google Ads visitor differently from a newsletter reader.

Seatext's own materials describe the problem as every keyword landing on the same generic page, so visitors do not see what they searched for and leave. The fix is to make the landing page reflect the source and the promise that brought the visitor there.

For Notion specifically, the practical question is not whether personalization is useful. It is whether the Notion page can run Seatext. Not every Notion publishing setup accepts third-party scripts the same way. Check that before you plan the personalization rules.

How the Visitor Source Rewrite Agent works

1. A visitor clicks a link from Google, Meta, email, an article, or a referral.
2. Seatext identifies the source and, for paid search, the keyword that triggered the ad.
3. Before the landing page appears, Seatext swaps the headline, key copy, offer, product blocks, and CTA.
4. The visitor sees a page that matches the promise from the ad, email, or article.
5. Seatext tracks results by page, keyword, and version.

Seatext rewrites the pages you already have. You do not need to build a separate landing page for every source. One page becomes a keyword-matched landing page for each paid click.

Hypothetical example: A referral article titled Best AI tools for Shopify stores sends a visitor to your page. With the Visitor Source Adaptation Agent, the page can adapt its headline and examples to that article's context. Without it, the visitor sees the same page as someone who arrived from a Google ad for a specific product.

Notion compatibility: script loading comes first

Seatext's public materials focus on the agent itself, not on every host. Notion publishing setups vary, and third-party scripts do not load the same way everywhere. Treat script compatibility as the first checkpoint.

Ask Seatext these questions:

• Can the Seatext script load on a Notion page?
• Do I need a custom domain or a specific Notion plan?
• Where should the script be placed?
• Which referral sources can I test first?

If a Notion page cannot load the script, a workable alternative is to run Seatext on a separate page you control and route referral traffic to that page. The personalization still happens, but the page is not hosted inside Notion.

What changes on the page

Seatext swaps the headline, key copy, offer, product blocks, and CTA. These are the same elements that usually decide whether a visitor converts.

The headline must continue the promise from the source. The offer must match the context. The CTA must feel like the next logical step. When these elements match, the page feels coherent. When they do not, the visitor sees a mismatch and leaves.

Seatext also tracks results by page, keyword, and version, so you can see which source-matched versions perform best and refine them over time.

Key facts at a glance

Use these facts as a checklist, not a promise. Your results depend on your traffic, your offers, and whether your Notion setup can run the agent.

How to evaluate Seatext for a Notion site

Use this decision path instead of guessing.

1. Confirm script access. Check whether your Notion page can load third-party JavaScript. If you are unsure, ask Seatext or test it with a staging page.
2. List your referral sources. Start with the sources you can name: Google Ads, Meta campaigns, email lists, partner articles, and direct referrals.
3. Define the promise for each source. Write the headline, offer, and CTA that match each source. This is your input, not Seatext's.
4. Activate the Visitor Source Rewrite Agent. Seatext then swaps those elements before the page appears.
5. Measure by source. Use page, keyword, and version tracking to see which source-matched versions perform best.

The common mistake is activating the agent before defining source-specific messages. The tool can rewrite the page, but you still need to tell it what each source should see.

Limitations and when this advice does not apply

• Referral-source personalization answers where someone came from, not who they are. It does not use a visitor's past purchases, CRM data, or account history unless another system supplies that context.
• It works best when you have distinct offers or messages for different sources. If every source should see the same page, this agent adds little.
• If your Notion page cannot load the Seatext script, the agent cannot run on that page. Use a separate Seatext-powered page instead.
• Bot clicks and invalid traffic are handled by a different agent, the Bot Refund Agent. Source rewrites improve the page; they do not clean your ad traffic.
• Translation is a separate capability. You can combine it with source rewrites, but the two agents solve different problems.

FAQ

Does Seatext personalize only Google Ads traffic?

No. Seatext names Google, Meta, email, articles, and referrals as sources it can match.

What exactly changes on the page?

Seatext swaps the headline, key copy, offer, product blocks, and CTA so the page continues the promise from the source.

Can Seatext work on a Notion site?

It can if your Notion setup can load the Seatext script. Confirm that first, because Notion publishing setups vary.

Do I need to create new pages for each source?

No. Seatext rewrites the pages you already have for each visit.

Does Seatext track which version worked?

Yes. Results are tracked by page, keyword, and version.

Is referral-source personalization the same as A/B testing?

No. A/B testing compares variants to find a winner. Source rewrites match the visitor's context before they land.

Can Seatext also translate my Notion pages?

Seatext can translate pages, headlines, buttons, and offers into up to 125 languages. Use that alongside source rewrites if your markets need it.

To reset your SeaText configuration in Odoo, go to the SeaText settings page and look for a "Reset Configuration" or "Reset Defaults" button. That action restores the integration to its initial state. If your version of SeaText does not have that button, the reliable alternative is to remove the SeaText embed code from your Odoo page and then re-add it from your SEATEXT AI account.

What counts as a SeaText configuration in Odoo?

SeaText works in Odoo through a JavaScript snippet that you place inside a page using the "Embed Code" module. That snippet connects your website to the SeaText AI agent that you activated from your SEATEXT AI account. The configuration includes which page the code is on, whether the block is hidden on desktop, and any custom settings you selected in the SeaText dashboard.

Resetting it means returning those pieces to their default state. You do not need to rebuild your Odoo site or touch your other content. You only need to correct the SeaText integration itself.

Before you reset: prerequisites

You need two things before you start:

• Administrator access to the Odoo page where the SeaText code is embedded. You must be able to open the website editor and drag modules.
• Access to your SEATEXT AI account. The account is what lets you generate a fresh code snippet and manage the agents.

If you have lost your SeaText login, recover it first. You cannot reset the configuration without it because the code snippet is tied to your account's primary URL.

Step-by-step reset process

Follow these steps in order. The exact names and locations can vary slightly by SeaText version and Odoo version, but the workflow is the same.

1. Log in to your SEATEXT AI account.
2. Open the SeaText settings page. Look for a section that mentions "Configuration," "Defaults," or "Reset."
3. If you see a "Reset Configuration" or "Reset Defaults" button, click it. Confirm the action when asked.
4. If there is no reset button, move to the manual reset method.
5. Log in to Odoo and open the Website module.
6. Navigate to the page that contains your SeaText embed code.
7. Click the "Edit" button to open the website editor.
8. Scroll through the "Blocks" panel to the "Dynamic Content" section.
9. Locate the "Embed Code" module that contains your SeaText snippet.
10. Copy the current code somewhere as a backup, then delete it from the module.
11. Click "Save" to remove the old configuration from the page.
12. Go back to your SEATEXT AI account and open the section that contains your JavaScript code. Copy the new snippet.
13. Return to Odoo and drag a new "Embed Code" module into the same spot on the page.
14. Paste the fresh snippet into the pop-up window and click "Save."
15. If you do not want the block to be visible on desktop, select "Hide on Desktop" in the "Visibility" section, then save again.
16. Check your page on the live site to confirm the SeaText code loads with no errors.

This process gives you a clean install. The AI agent remains inert until you activate it, so you can safely preview the page before turning it on.

How resetting relates to your SeaText account and domain

SeaText links each account to a single primary URL. If you use SeaText on a development domain and a production domain, you must have separate accounts for each domain. Resetting the configuration only affects the account and domain you are working on. It does not touch your other websites. This is especially important when you have multiple Odoo pages or a staging site.

The source also notes that development URLs like localhost are restricted for security reasons. If you try to test after a reset on a development domain, the integration may not work. Use a real, valid domain to verify the reset.

Key facts about SeaText in Odoo

Common mistakes to avoid

Many reset problems come from tiny oversights. Here are the most common ones.

• Forgetting to save the page after removing the old embed code. If you do not save, the old code stays active.
• Using a development domain to test the reset. SeaText restricts localhost and dynamic development domains, so use a real domain.
• Pasting the new code into the wrong module or the wrong page. Double-check that you are editing the same page that had the original code.
• Leaving the block visible on desktop when you intended it to be hidden. Use the "Hide on Desktop" option if necessary.
• Not generating a fresh code snippet. Reusing an old snippet may bring back the same issues.

When a full reset is not needed

A reset is not always the answer. Sometimes you only need to fix one setting, like a copy variant or a translation. In those cases, change the specific option in the SeaText dashboard and test that single item. This saves time and avoids disconnecting your analytics or AI agents.

If the problem is that a page is not showing SeaText at all, first check that the embed code is still present. If it is, the issue may be with the SEATEXT AI account rather than the Odoo configuration. Verify that your subscription is active and that the domain in the account matches the page URL.

Limitations of the reset process

Not every SeaText screen includes a one-click reset button. The manual reinstall method always works, but it takes a few extra minutes.

Resetting the configuration does not delete your SEATEXT AI account, cancel your subscription, or remove your historical data. It only returns the integration settings to their default state. If you want to completely disconnect SeaText from Odoo, you need to remove the embed code and also deactivate or delete the account through your SeaText dashboard.

Because each account is bound to a single primary URL, you cannot use one reset to fix multiple websites. You must repeat the process for each domain.

Frequently asked questions

What exactly gets reset when I use "Reset Configuration"?

It returns the SeaText integration to the state right after installation. That means any custom settings you changed, such as agent behavior or page targeting, revert to their defaults. Your account data and billing stay intact.

Will resetting remove SeaText from my Odoo website?

If you use a reset button, the integration may stay on the page and simply revert settings. If you manually remove the embed code, the integration will no longer be active on that page. Choose the method that matches what you need.

Do I need to reset each domain separately?

Yes. Each SEATEXT AI account is linked to one primary URL. If you have multiple domains, create separate accounts and reset them one at a time.

Can I test the reset on localhost?

No. SeaText restricts development URLs such as localhost for security reasons. Use a real, valid domain to verify the reset worked.

How do I know the reset was successful?

Check that the SeaText embed code is present on the page and that the block appears where you placed it. Then open your SeaText dashboard and confirm that the agent status matches your chosen defaults.

What if I still have problems after resetting?

Re-generate the code snippet from your SEATEXT AI account and re-install it one more time. If the issue continues, the problem may be with your Odoo theme or another script that conflicts with SeaText.

Resetting your SeaText configuration in Odoo is a straightforward path if you follow a clear process. Start with the reset button in your SeaText settings. If that fails, reinstall the embed code using the Odoo editor. With these steps, you can get back to a clean working state without rebuilding your website.

SeaText does not place a configuration menu inside Odoo. If you are looking for a new menu item labeled “SeaText” in Odoo’s dashboard or Settings app, you won’t find one. Instead, SeaText is configured from your SEATEXT AI account, and you connect it to Odoo by embedding a JavaScript snippet into a page built with Odoo’s Website module.

The practical answer: the “configuration menu” is your SEATEXT AI dashboard, and the installation point is Odoo’s Website module. Specifically, you use the Embed Code block under Dynamic Content in the Odoo page editor.

What People Usually Mean by “SeaText Configuration Menu”

In Odoo, many modules add a “Configuration” menu under Settings. A user familiar with that pattern might expect SeaText to appear there. It does not, because SeaText is not an Odoo module in the traditional sense.

SeaText is an external AI service. You create an account, copy a JavaScript snippet, and paste that snippet into your Odoo page. The snippet loads SeaText’s agents on your website. All the actual configuration — which agents run, how they behave, what gets translated, what gets rewritten — happens inside your SEATEXT AI account.

Where to Actually Install SeaText in Odoo

SeaText’s Odoo integration uses the built-in Website module. Follow these steps:

1. Log in to your Odoo account and access the Website module from the dashboard.
2. Navigate to the page you want to edit and click the Edit button to open the editing panel.
3. In the editing panel, scroll through the Blocks panel until you reach Dynamic Content.
4. Locate the Embed Code module and drag it into the desired location on your page.
5. Click the Edit button in the right panel to input the code.
6. In the pop-up window, paste the JavaScript snippet provided by SEATEXT AI, then click Save.
7. To keep the block from appearing on desktop, select Hide on Desktop in the Visibility section, then click Save again.

That is the whole process. There is no separate configuration menu to open inside Odoo.

Why There Is No Configuration Menu in Odoo’s Settings

Odoo’s settings menus are designed for Odoo modules that store data in Odoo’s database. SeaText works differently.

SeaText gives you a snippet of JavaScript. That snippet communicates with SeaText’s servers. When someone visits your Odoo page, the browser loads the snippet and SeaText can then run its AI agents. This is why:

• No Odoo database tables are needed.
• No new Odoo menu item appears.
• No Odoo “Settings” page is modified.
• You control behavior from your SeaText account, not from Odoo.

If you spend time looking for a menu inside Odoo, you will miss the actual integration point. The integration point is the page editor’s Dynamic Content section.

What You Configure in Your SEATEXT AI Account Instead

Before you can install the script, you need a SEATEXT AI account. The account is where you manage everything SeaText does for your website.

From that account you can copy the JavaScript code. SeaText’s integration page explains: “Copy the Javascript code from SEATEXT AI which appear in this section below.” That code is unique to your account and your domain.

The account link matters. Each SEATEXT AI account is linked to a single primary URL. If you need to use SeaText on multiple domains — for example, a development domain and a production domain — you must create separate accounts for each domain.

This also means the “configuration menu” follows the account, not the Odoo instance. You configure SeaText once per domain, and then the snippet delivers that configuration to your Odoo page.

Key Facts at a Glance

Common Mistakes and Limitations

The most common mistake is looking for a SeaText menu in Odoo instead of looking for the Embed Code block. If you cannot find the menu, you are looking in the wrong place.

Another common mistake is using the same account for two domains. Because each account is tied to one primary URL, one account will not reliably work on another domain. Create a separate account for each website.

Development URLs are another limit. If you try to test on localhost, SeaText may not function. The source documentation explicitly says development URLs such as localhost are restricted for security reasons. Use a valid, real domain.

Dynamic development domains may also fail. SeaText may not be able to associate traffic with your account when the domain changes frequently. Stick to a stable, real domain.

Finally, remember that the visible embed block can interfere with your design. Odoo’s editor gives you a “Hide on Desktop” option so you can place the snippet without changing what visitors see on desktop. Use that option after pasting the code.

What to Do After You Paste the Code

After you save the Embed Code block, visit your website or refresh the page. This loads the snippet and lets you confirm that SeaText is active.

If you are using multiple domains, check that you have the correct snippet from the correct SeaText account on each domain. The snippet and the domain need to match.

Because the AI remains inert until activated, the installation does not change your content by itself. You have time to review your SeaText account settings and choose which agents to enable.

Frequently Asked Questions

Does SeaText appear in Odoo’s Settings menu?

No. SeaText does not create a Settings menu item inside Odoo. You connect SeaText by pasting a JavaScript snippet into an Embed Code block in Odoo’s Website module.

Where do I get the SeaText JavaScript code?

From your SEATEXT AI account. The Odoo Integration page includes the code snippet and shows you exactly where to paste it in Odoo.

Can I use localhost while testing SeaText on Odoo?

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

Can I use one SeaText account on two Odoo websites?

No. Each SeaText account is linked to a single primary URL. For multiple websites or domains, create one account per website.

Do I need to keep the Embed Code block visible on desktop?

No. In the block’s Visibility settings, choose “Hide on Desktop” so the block does not change what desktop visitors see.

What happens after I paste the snippet into Odoo?

Save the page, then visit or refresh your website so the script can load. After that, manage SeaText’s features from your SeaText account.

Final Takeaway

SeaText’s Odoo configuration is not a menu. It is a two-part setup: your SeaText account holds the settings, and Odoo’s Website module holds the embed code.

When someone asks “Where is the SeaText configuration menu in Odoo?”, the correct answer is: open the Website module, edit your page, and use the Embed Code block under Dynamic Content. Then configure everything else in your SEATEXT AI account.

No. You should not use the same SeaText API key or account for multiple Odoo domains. SeaText links each account to a single primary URL. The correct setup is one SeaText account per domain, with that account's own code snippet installed on the matching website.

The good news is that adding a second domain is not a complex development project. You create a separate SeaText account for the new domain, copy its code, and paste it into Odoo's Embed Code module. The steps below show the exact process and how to verify it.

What changes if you reuse one SeaText key on multiple Odoo domains

If you paste the same integration code into two Odoo sites, SeaText cannot reliably know which site should count as the primary URL. Data from both sites can be mixed, and you may not be able to tell which page changes produced which result.

That is why the SeaText Odoo integration page says each account is linked to a single primary URL. The page also says dynamic development domains may not function properly because SeaText might be unable to reliably associate traffic with your account.

In practical terms, sharing a key across domains makes your reporting less trustworthy. You may think a change on one site caused a lift, but the traffic and reading data could actually be coming from the other site.

Before you start: prerequisites

• List every domain where you need SeaText. Treat production, staging, and separate brand or country sites as separate domains.
• Have access to your Odoo account and the Website module.
• Create a SeaText account for each domain. Each account is linked to one primary URL.
• Use a valid, real domain for each account. Development URLs such as localhost are restricted for security reasons.
• Keep each account's code snippet labeled by domain so you do not paste the wrong script.

How to install SeaText on multiple Odoo domains, step by step

1. Create a SeaText account for domain A and set its primary URL to domain A.
2. Copy the JavaScript code from that SeaText account.
3. Log in to Odoo and access the Website module from the dashboard.
4. Navigate to the page you want to edit and click the Edit button.
5. Scroll to the Dynamic Content section in the Blocks panel.
6. Find the Embed Code module and drag it into the desired location on the page.
7. Click Edit in the right panel to open the code input.
8. In the pop-up window, paste the SeaText code snippet and click Save.
9. If the block should not appear on desktop, select Hide on Desktop in the Visibility section, then click Save again.
10. Repeat the process for domain B using a separate SeaText account. Do not copy domain A's code into domain B.

How to verify the setup

Visit or refresh the page after saving the Embed Code module. Confirm the page still loads normally and the block is hidden on desktop if you selected that option.

Then confirm that the code pasted on each Odoo domain came from the account whose primary URL matches that domain. That is the main check. If you used a dynamic development domain, switch to a stable, valid real domain because dynamic development domains may not work reliably.

Your realistic options for multiple Odoo domains

Option 1: One SeaText account per domain

This is the setup SeaText describes. It keeps data separated and makes it easy to see which domain is sending traffic. The trade-off is that you have more accounts to manage.

Option 2: Use SeaText on only one domain

If a second domain does not need SeaText, do not install the code there. This avoids extra accounts and keeps reporting simple. The other domain simply does not get the same optimization.

Option 3: Confirm a special multi-domain setup with SeaText

The public Odoo integration page does not describe a way to link one account to multiple primary URLs. If you are told otherwise, ask how traffic is assigned before relying on it.

Scope: your SeaText account is not Odoo's external API key

The SeaText Odoo integration uses a JavaScript code snippet from your SeaText account. You paste that snippet into Odoo's Embed Code module. The same rule applies whether you call it an API key, an account, or a code snippet: one account per primary URL.

This is separate from Odoo's own external API, which developers use to connect other software to Odoo data through JSON-RPC or XML-RPC. Those are different credentials for a different purpose.

Key facts about SeaText and multiple domains

Common mistakes and how to avoid them

Limitations and when this guidance does not apply

SeaText's public documentation does not describe a way to merge accounts or share one API key across multiple primary URLs. If you believe you have a special case, check with SeaText before assuming a workaround exists.

Subdomains are not covered in the source material. If two Odoo sites share the same root domain but use different subdomains, ask SeaText whether one account is enough.

If you only need SeaText on your production site, leave staging without SeaText or create a separate staging account. The source explicitly lists a development domain and a production domain as an example of when separate accounts are required.

Frequently asked questions

Can I use the same SeaText API key in Odoo and another website?

No. SeaText links each account to a single primary URL. Create one account for each website.

What happens if I paste the same code into two Odoo domains?

Data can be mixed or associated with the wrong URL. Use a separate account for each domain to keep reporting clean.

Is localhost allowed as an Odoo test domain?

No. Development URLs such as localhost are restricted for security reasons.

Do I need a separate SeaText account for staging?

If staging is a separate domain, yes. The SeaText documentation names development and production domains as a case where separate accounts are required.

Can a dynamic development domain work?

It may not. SeaText might be unable to reliably associate traffic with your account on a dynamic development domain.

Can I merge two SeaText accounts later?

The source documentation does not mention account merging. Contact SeaText to check your specific situation.

Does Odoo's external API matter here?

No. Odoo's external JSON-RPC or XML-RPC API is for connecting software to Odoo data. It is separate from the SeaText integration code you paste into a page.

Symptoms of a Failed Activation

You might see the SeaText script in your Odoo page editor but nothing changes on the live site. The AI agents do not appear, content does not rewrite, and the dashboard shows no activity. Sometimes the embed block itself is missing or greyed out.

Step-by-Step Diagnostic Sequence

1. Check your SeaText account. Log in at seatext.com and copy the JavaScript snippet from the integration section. Make sure you are using the correct snippet for the domain you are testing.
2. Verify the Odoo module. Go to the Apps module in Odoo and search for "Website". The Website module must be installed and activated. If you are using a custom theme, ensure it supports the Embed Code block.
3. Inspect the page editor. Open the page you want to edit. Click Edit and scroll to the "Dynamic Content" section in the Blocks panel. Drag the Embed Code block into the desired location.
4. Paste the code correctly. Click the Edit button on the block, paste the SeaText snippet, and save. Then check the "Hide on Desktop" option if needed (SeaText recommends hiding the block on desktop so it doesn't appear as a visible element).
5. Test in your browser. Open the browser's developer console (F12) and reload the page. Look for any red JavaScript errors. If you see a message like "SEATEXT is not defined" or a network error, the snippet may be blocked by an ad blocker or a Content Security Policy.
6. Clear caches. Flush Odoo's website cache and your browser cache. SeaText's script runs client-side, so stale cached versions of the page can prevent activation.

Why SeaText Activation Matters for Your Odoo Site

SeaText deploys autonomous AI agents that rewrite content in real time to match visitor intent, translate pages into 125 languages, and optimize conversion rates. When activation fails, you lose these capabilities: personalized landing pages for each ad keyword, automated A/B testing of copy variants, bot detection that can recover wasted ad spend, and real-time translation for international visitors. For Odoo users, this means missed revenue opportunities and a static website that cannot adapt to each visitor.

Common Trade-offs: Client-Side Script vs. Server-Side Integration

SeaText uses a client-side JavaScript snippet placed in Odoo's Embed Code block. This approach requires no Python or XML changes, so deployment is fast and reversible. However, client-side scripts depend on the browser environment: ad blockers, Content Security Policies, or browser caching can block execution. A server-side integration would avoid these issues but would require custom Odoo module development and ongoing maintenance. The trade-off is simplicity and speed versus control and reliability.

Practical Use Cases for SeaText on Odoo

• Google Ads landing pages: The script rewrites headlines and offers to match the exact keyword a visitor searched, increasing relevance and conversion rates.
• Multilingual ecommerce: Automatic translation into 125 languages lets you serve global customers without manual localization projects.
• Bot protection: The agent detects bot traffic in paid campaigns and builds evidence for refund requests to Google and Meta.
• AI chat: A free autonomous sales chat agent can book meetings and close deals directly on your Odoo site.

Limitations and Trade-offs of the Odoo Integration

• One account per domain: Each SeaText account is linked to a single primary URL. You must create separate accounts for development, staging, and production domains. Localhost and dynamic development domains are restricted.
• Client-side dependency: The script loads in the visitor's browser. If the browser blocks third-party scripts, SeaText cannot run.
• No server-side fallback: There is no server-side rendering option; all AI processing happens client-side or via SeaText's CDN.
• Theme compatibility: Custom Odoo themes may move or hide the Embed Code block, requiring manual adjustment.

Likely Causes and Fixes

Incorrect API Key or Snippet

Each SeaText account is linked to a single primary URL. If you copied the snippet from a different domain, it will not work. Create a separate account for each domain (including development and production). Development URLs like localhost are restricted — use a real domain.

Module Not Installed or Outdated

Odoo's Website module must be active. If you recently updated Odoo, the Embed Code block might be moved. Check the Odoo changelog for your version. Also ensure the SeaText script is compatible with your Odoo version (the JavaScript snippet is version-agnostic, but the block placement differs between Odoo 16 and 17).

JavaScript Conflicts

Some Odoo themes or third-party modules block external scripts. Test on a clean Odoo instance or disable other customizations temporarily. If the conflict disappears, contact the theme developer.

Verifying Your SeaText Installation

After pasting the code, save the page and view it in a private browser window. Right-click and select "Inspect", then go to the Console tab. Type window.SEATEXT and press Enter. If the object is defined, the script loaded. If it returns undefined, go back to the diagnostic steps.

You can also check the Network tab for a file named seatext.js or similar. If it does not appear, the snippet was not inserted correctly.

Additional Troubleshooting Scenarios

• Content Security Policy (CSP) blocks script: If your Odoo instance uses a CSP header, add the SeaText CDN domain to the script-src directive.
• Embed Code block not visible: Ensure you are editing a page in the Website app, not the backend. The block appears under "Dynamic Content" only in the website editor.
• Multiple SeaText snippets on one page: Only one snippet should be present. Duplicate snippets cause conflicts and prevent activation.
• Odoo caching layers: Odoo's website cache, Varnish, or Cloudflare can serve stale HTML without the snippet. Purge all caches after adding the code.

What to Do If the Problem Persists

If you have followed all steps and SeaText still does not activate, consider these edge cases:

• Multiple domains: You need a separate SeaText account per domain. Using the same account on two domains will cause activation failure on one.
• Ad blockers: Disable ad blockers for your site. SeaText's script can be blocked by strict privacy extensions.
• Odoo hosting: If your Odoo is behind a firewall or proxy, the CDN that serves the SeaText script may be blocked. Whitelist the SeaText domain.
• Contact support: SeaText offers a free demo and a 1-month pilot trial (S5). Reach out with your account details and the browser console output.

Key Facts About SeaText Odoo Integration

Frequently Asked Questions

Why does the SeaText block not appear in my Odoo editor?

Make sure the Website module is installed and you are editing a page in the Website app. The Embed Code block is under the "Dynamic Content" section in the blocks panel.

Can I use SeaText on my Odoo staging site?

Yes, but you need a separate SeaText account for the staging domain. Dynamic development domains like staging.example.com may work if they are real domains. localhost is blocked.

Do I need to modify Odoo code?

No. SeaText is installed via a drag-and-drop block and a code snippet. No Python or XML changes are required.

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

The script activates immediately on page load. If you see no changes, refresh the page and check the console for errors.

Will SeaText slow down my Odoo site?

SeaText's script runs client-side. If you notice slowdowns, check your browser console for network issues.

What if I accidentally delete the embed block?

Simply re-add the block and paste the snippet again. The code is tied to your account, not the block instance.

Yes. You can manually refresh website data in SeaText. Open Integrations settings, find your Odoo connection, and click Sync Now. SeaText then pulls the latest data from your website.

This is different from refreshing your browser. Pressing F5 only reloads the page you are viewing. A manual refresh in SeaText updates the data that SeaText stores for your connected site.

What "website data" means in SeaText

SeaText reads content from your site so its agents can work with current copy. When you connect Odoo, the embed code placed in Odoo's Dynamic Content section is what lets SeaText see the page content.

Think of it as a working copy. Odoo holds the source, and SeaText holds the version it uses for AI agents. If you change a headline or product description in Odoo, SeaText can keep the old version until a sync happens. A manual refresh is the direct way to force an update.

The embed code is a JavaScript snippet. Odoo's Dynamic Content section can hold this snippet. The code should stay hidden on desktop. The integration guide says to select "Hide on Desktop" in the visibility settings. This keeps the module from changing what visitors see.

If you skip this, your agents may keep working from old website data until another sync runs.

Why a manual refresh matters

SeaText does not edit Odoo. It only reads the content that Odoo serves. When you save an edit in Odoo, SeaText does not know about it yet. The next sync brings that edit into SeaText.

Some changes are time-sensitive. Prices, stock messages, campaign headlines, and product names all matter. If an AI agent rewrites copy from old data, the output may be wrong. For example, a translation agent could translate an outdated product description.

Automatic sync may happen, but the guide does not state a fixed interval. You should not assume that every Odoo save triggers an instant SeaText update. When you need current data right away, manual refresh is the reliable option.

A manual refresh also helps after you install or update the embed code. Once the code is in place, refresh to pull data for the first time.

Prerequisites before you refresh

Before you click Sync Now, check these basics:

• You have a SeaText account. The integration guide says you need an account before you can install the script.
• The Odoo embed code is installed in the Dynamic Content section.
• You saved the change in Odoo after pasting the code.
• The account's primary URL matches the live domain you want to refresh.
• You are not using localhost or a dynamic development domain. SeaText restricts development URLs for security reasons.

If any of these are missing, a manual refresh will not fix the data. It only pulls data from a source that is already connected correctly.

Confirm the embed code in Odoo

The most important requirement is the embed code. Here is how to confirm it is installed correctly.

1. Log in to your Odoo account.
2. Open the Website module.
3. Select the page you want SeaText to read.
4. Click the Edit button.
5. Scroll to the Dynamic Content section in the Blocks panel.
6. Look for the Embed Code module.
7. If it is missing, drag it onto the page.
8. Click the module and choose Edit.
9. Paste the SeaText JavaScript code.
10. Click Save.
11. If you do not want the module visible, select Hide on Desktop and save again.

These steps come from the public Odoo integration guide. After you save, the code becomes active. The AI stays inert until you activate it. A manual refresh only updates the content copy; it does not activate agents.

How to manually refresh your website data

Once the prerequisites are met, the refresh is simple.

1. Log in to your SeaText account.
2. Go to Settings and open Integrations.
3. Find the Odoo connection you want to update.
4. Click Sync Now next to that connection.
5. Wait until the sync finishes. Do not close the page while it is running.
6. Return to your SeaText content area and confirm the updated data appears.

Sync Now is the button that triggers the refresh. It asks SeaText to pull current content from the connected website. The exact amount of time depends on the size of the site and the speed of the connection.

If Sync Now is not visible, check that the integration is active and that the account is linked to the correct domain. The refresh can only work when SeaText recognizes the connection.

What to check after the sync

After the sync finishes, verify that the new data actually reached SeaText. Otherwise, you won't know whether the refresh worked.

• Check the integration status. An active connection should show no error.
• Open the SeaText content list and look for the page you edited in Odoo.
• Look at the saved text in SeaText, not just the live page in your browser.
• If the live page still looks old, hard-refresh your browser or open it in a private window. This avoids browser cache.

If the content is still old after a successful sync, go back to Odoo and confirm the edit was saved. Then check that the embed code is still on the page.

Sometimes a sync finishes quickly but the data looks unchanged. That can happen when the edit was not saved in Odoo, or when the SeaText account is linked to a different domain. Confirm both before you refresh again.

Key facts about SeaText and Odoo data

These facts come from the public Odoo integration guide.

Limitations and exceptions

A manual refresh has limits. It cannot fix a broken integration.

• If the embed code is missing, SeaText has nothing to sync.
• If the account URL does not match the domain, SeaText may not associate the data correctly.
• If you use a development domain, the sync may not work. Use a valid, real domain.
• If you manage multiple websites, refreshing one account only refreshes that account. Separate domains need separate accounts.
• A manual refresh does not replace saving changes in Odoo. Odoo's own Save button is the first step.

Each SeaText account is bound to one primary URL. This means you cannot use one account to refresh two unrelated domains. The integration guide is clear: create one account for each domain. This rule also covers development and production domains. Do not mix them.

Common mistakes to avoid

• Using a browser refresh and expecting SeaText to update.
• Changing Odoo content but not clicking Save.
• Clicking Sync Now before the embed code is placed.
• Using a localhost domain in the SeaText account.

Terminology: sync, refresh, and embed code

• Sync means pulling current data from a connected source into SeaText.
• Browser refresh means reloading a page in your browser.
• Embed code is the JavaScript snippet from SeaText placed in Odoo's Dynamic Content section.
• Primary URL is the real domain linked to a SeaText account.

Understanding these terms helps you diagnose problems. If you say "refresh my website" in a browser, that is not the same as a SeaText sync. Knowing the difference saves time.

Frequently asked questions

How often does SeaText sync automatically?

The public integration guide does not state a fixed automatic interval. When you need current data right away, use Sync Now.

Why did my manual refresh finish but the site still shows old text?

Check three things: the Odoo edit was saved, the embed code is still in the page, and the SeaText account domain matches the live site. Also clear browser cache or use a private window.

Can I use localhost or a staging domain?

Development URLs such as localhost are restricted. Dynamic development domains may not work because SeaText cannot reliably associate traffic with your account. Use a valid real domain.

Do I need one SeaText account for each website?

Yes. Each account is linked to one primary URL. For multiple domains, create separate accounts.

Does a manual refresh edit my Odoo site?

No. It pulls website data into SeaText. It does not replace the edit and save workflow in Odoo.

What is the difference between a browser refresh and a SeaText refresh?

A browser refresh reloads the page for you. A SeaText refresh syncs data from the connected website into SeaText so agents and content features use current information.

How do I know if the embed code is installed?

Open the Odoo page editor and look for the Embed Code module in the Dynamic Content section. The integration guide shows the same area. If you see the module with the SeaText code pasted in, the installation is done.

Can I refresh data for multiple pages at once?

Sync Now targets the connected Odoo connection. The guide does not describe a page-by-page refresh option. A sync updates the data SeaText can access for that connection.

Does the refresh activate the AI agents?

No. The AI remains inert until you activate it. A manual refresh only updates the website data that SeaText stores.

Why SeaText and Odoo Connections Fail

Connecting SeaText to Odoo fails most often because users skip steps in the official integration process. The source pack lists a clear sequence: open the Website module, drag the Embed Code block, paste the snippet, save, hide the block on desktop, and save again. If you miss any of these, the script may not load or may show visible artifacts.

Another major cause is the account-to-domain rule. The SeaText Odoo integration guide states that each account is linked to a single primary URL. If you try to reuse one account across staging, production, or development domains, the connection can behave unpredictably. This often shows up as missing data or broken personalization.

The good news is that most problems come from a few repeatable mistakes. Below are the most common ones, why they happen, and how to fix them.

Mistake #1: Using One SeaText Account for Multiple Domains

SeaText accounts are not portable across domains. The official guide says: “Each SEATEXT AI account is linked to a single primary URL.” If you have a staging site and a production site, you need a separate account for each.

Why this matters: SeaText associates traffic with your account by domain. If you use the same code on two domains, the AI cannot reliably attribute visitors. Your data becomes mixed, and sync errors appear.

How to fix it: Create a separate SeaText account for every domain you use. Copy the JavaScript snippet from each account individually. Then paste the correct snippet into the matching Odoo website.

Practical scenario: You run a development copy at dev.example.com and the live site at example.com. You must create two SeaText accounts—one for each URL. Never share a snippet between them.

Mistake #2: Pasting the Code in the Wrong Odoo Module

The integration guide says to log in to Odoo and access the “Website” module. Some users paste the code into backend settings, a custom module, or an HTML block outside the Website module. The script then never runs.

Why this matters: SeaText's embed code is designed to load on the frontend of your website. Odoo's backend pages do not process visitor behavior, so the AI stays inactive.

How to fix it: Open the Website module, navigate to the page you want to edit, and click “Edit.” Scroll through the “Blocks” panel to the “Dynamic Content” section. Drag the “Embed Code” module into the page. Then click “Edit” on that module and paste the SeaText code.

Check the exact location: the guide repeats this step to emphasize it. Do not place the snippet in a custom HTML block outside Dynamic Content.

Mistake #3: Forgetting the "Hide on Desktop" Setting

After pasting the code, the guide says to select “Hide on Desktop” in the “Visibility” section. If you skip this, the empty embed block may appear as a blank or broken element on desktop screens.

Why this matters: The block is only there to load the script. Visitors should never see it. An empty box can make your site look unprofessional and confuse users.

How to fix it: After pasting the code and clicking “Save,” go to the right panel. Find the “Visibility” section and check “Hide on Desktop.” Then click “Save” once more.

Note: The guide lists this as Step 6. It is easy to forget, but the two-step save is essential for a clean page.

Mistake #4: Not Saving After Each Step

Odoo's editor requires two saves for this integration. The first save applies the pasted code. The second save applies the visibility change. If you skip the second save, your visibility setting may not persist, and the script may still load in a visible block.

Why this matters: A missing save means your configuration is incomplete. The SeaText script may load, but the page will show an empty element.

How to fix it: Always click “Save” after pasting the code. Then adjust the visibility setting and click “Save” again. Do not combine these steps into one quick save.

Practical tip: After the second save, refresh the page in your browser to confirm the script activates.

Mistake #5: Testing on Localhost or Dynamic Development Domains

The guide says: “Development URLs, such as localhost, are restricted for security reasons. Ensure you use a valid, real domain for these cases.” Dynamic development domains may also fail because SeaText cannot reliably associate traffic with your account.

Why this matters: Localhost is not a public domain. SeaText blocks it to prevent abuse and misattribution. If you test on localhost, skip this and test on a real domain instead.

How to fix it: Use a valid, real domain for testing. If you need a staging environment, use a subdomain like staging.example.com and create a separate SeaText account for it.

Decision criteria: Always ask, “Is this a domain that real visitors can reach?” If not, create a new account for a real domain before integrating.

Mistake #6: Skipping the Page Refresh After Installation

The source pack ends with an important note: “Visit or refresh y…”—the full instruction is to visit or refresh your page after installation. This activates the AI. If you don't, the script loads but remains inert.

Why this matters: SeaText's integration is secure by design. The AI stays inactive until the page is visited or refreshed. That step is part of the official process, not an optional extra.

How to fix it: After completing both saves, refresh the page in your browser. You should see no visible block, and the script will start collecting data.

Limitations: If you refresh once and nothing changes, double-check the earlier steps. Verify the correct snippet is pasted and the hide-on-desktop setting is saved.

Key Facts About SeaText and Odoo Integration

Step-by-Step: The Correct Connection Process

1. Create a SeaText account for your production domain.
2. Copy the JavaScript code snippet from your SeaText dashboard.
3. Log in to Odoo and open the Website module.
4. Navigate to the page you want to edit and click Edit.
5. Scroll to Dynamic Content in the Blocks panel.
6. Drag the Embed Code module into the page.
7. Click Edit on the module and paste the SeaText code.
8. Click Save.
9. In the Visibility section, select "Hide on Desktop".
10. Click Save again.
11. Refresh the page to activate the AI.

FAQ: Common Questions About SeaText + Odoo

Why is my SeaText script not working in Odoo?

Most likely you skipped a save or used a development domain. Check that you placed the code in the Website module, saved twice, and refreshed the page.

Can I use one SeaText account for both staging and production sites?

No. Each SeaText account is linked to a single primary URL. Create separate accounts for each domain.

Do I need to hide the embed block on desktop?

Yes. The official guide says to select "Hide on Desktop" to prevent display issues.

What happens if I paste the code in the wrong Odoo module?

The script will not load. Move the embed code to the Website module's Dynamic Content section.

How do I avoid data duplication in Odoo?

Data duplication usually comes from using the same account on multiple domains. Use a dedicated account per domain and follow the integration steps exactly.

Can I test on localhost?

No. Development URLs like localhost are restricted for security reasons. Use a real domain.

What should I do after installing the script?

Visit or refresh the page. The AI activates only after that step.

Where can I find the official Odoo integration guide?

It is available at seatext.com/odoo-integration.

To embed a Google Map in Odoo using the built-in Embed Code module, first get the iframe snippet from Google Maps, then add the Embed Code block to your page in the Website editor and paste the code. The map renders on the live site without any custom development.

How the Embed Code Block Works

The Embed Code block is a core Odoo Website feature. It stores any HTML snippet you paste into it. When a visitor loads the page, Odoo renders that snippet directly in the page layout. No server-side processing happens. The block acts as a container for raw HTML, including iframes, scripts, or custom styles.

This block is perfect for third-party integrations like Google Maps, YouTube videos, or booking widgets. You do not need to edit template files or write Python code. The block respects the page's responsive grid. You can place it inside columns, sections, or any container.

Odoo does not sanitize the snippet. So you can paste any valid HTML. But be careful. Malicious code could break your site. Always paste code from trusted sources like Google Maps.

Prerequisites

• An Odoo instance with the Website app installed (standard in Odoo Online, Odoo.sh, and on-premise).
• Editor access to the page where you want the map.
• A Google Maps embed link — no API key is required for the basic "Embed a map" iframe.

Step-by-Step Walkthrough (with Source Pack Details)

1. Get the Google Maps embed code. Open Google Maps in a browser, search for the address or place, click Share → Embed a map, choose a size (small, medium, large, or custom), then click Copy HTML. The clipboard now holds an <iframe> tag.
2. Log in to your Odoo account and access the "Website" module. From the dashboard, click Website. Then navigate to the page you wish to edit and click the Edit button to open the editing panel.
3. Locate the Embed Code module. In the editing panel, scroll through the Blocks panel until you reach the Dynamic Content section. The block is labeled Embed Code.
4. Drag the block onto the page. Drop it where you want the map to appear — inside a column, a section, or directly on the grid.
5. Once the module is placed, click on the "Edit" button located in the right panel to input the code. A pop-up window appears.
6. In the pop-up window that appears, paste the code snippet provided by Google Maps into the designated area, then click "Save" to apply the changes. The block now contains the iframe.
7. Optional: Adjust visibility. Still in the right panel, open the Visibility section. You can enable Hide on Desktop or Hide on Mobile if the map should only show on certain devices. Click Save again.
8. Publish. Exit the editor and click Publish (or Save if the page is already live). Visit the front-end URL to confirm the map loads.

Getting a Clean Google Maps Iframe

The "Embed a map" dialog produces an iframe with a fixed width and height. For responsive layouts, replace the pixel dimensions with width="100%" and a reasonable height (e.g., height="400"). Example:

<iframe
  src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3..."
  width="100%"
  height="400"
  style="border:0;"
  allowfullscreen=""
  loading="lazy"
  referrerpolicy="no-referrer-when-downgrade"></iframe>

Adding loading="lazy" defers the map until the visitor scrolls near it, improving page-speed scores.

Common Issues and Quick Fixes

• Map shows "This page can't load Google Maps correctly." The iframe src may be truncated. Recopy the full embed code from Google Maps; the URL is long and easy to cut off.
• Map is too small or overflows on mobile. Ensure the iframe has width="100%" and the parent column/section has no fixed pixel width that forces overflow.
• Block not found in Dynamic Content. In Odoo 17+, the block is still called Embed Code. If you use a custom theme that hides core blocks, check the theme's block list or temporarily switch to the default theme to verify.
• HTTPS mixed-content warning. Google Maps embed URLs are HTTPS. If your Odoo site runs HTTP locally (e.g., localhost), the browser may block the iframe. Use a valid domain with SSL for testing.

Practical Scenarios for Using the Embed Code Block

Contact page – Show your office location. Drop the map near the contact form. Visitors can see exactly where you are.

Event page – Embed a map of the venue. Attendees can get directions without leaving your site.

Store locator – If you have one location, a static embed works fine. For multiple locations, you need a custom solution.

Real estate listing – Place a map of the property. Use Street View if available.

Tourist info page – Show points of interest. Use multiple embed blocks for different places.

Limitations and When to Use a Custom Module

• No dynamic markers or routes. The static iframe shows one location. For multiple markers, directions, or custom styling you need the Maps JavaScript API and a custom module.
• No server-side control. The iframe loads entirely from Google; you cannot filter map layers or restrict zoom from Odoo.
• Cookie consent. The iframe sets Google cookies. If you run a strict GDPR banner, the map may not load until the visitor accepts marketing/analytics cookies.
• Rate limits. The free embed endpoint is generous but not unlimited. High-traffic sites (millions of map loads/month) should migrate to the Maps JavaScript API with a billing account.

Key Facts

Frequently Asked Questions

Do I need a Google Cloud API key for the basic embed?

No. The "Embed a map" iframe works without an API key. Keys are only required for the Maps JavaScript API, Geocoding API, or Places API.

Can I embed a Street View panorama instead of a map?

Yes. In Google Maps, open Street View, click Share → Embed a map, and copy that iframe. The same Embed Code block handles it.

Why does the map not appear in the backend editor preview?

Odoo's editor sometimes sanitizes iframes in the live preview. Publish the page and view the front-end URL; the map will render there.

How do I center the map on a coordinate instead of an address?

In Google Maps, right-click the exact spot → "What's here?" → copy the latitude/longitude from the bottom card → search for those coordinates → Share → Embed a map.

Can I restrict the map to certain zoom levels?

Not with the embed iframe. The Maps JavaScript API supports minZoom and maxZoom options, which require a custom module.

Will the embed code survive Odoo upgrades?

Yes. The Embed Code block is a core Website feature. Your pasted iframe is stored in the page content (ir.ui.view) and is preserved across version upgrades.

What if I need the map inside a product page or contact form template?

Edit the relevant QWeb template (e.g., website_sale.product or website.contact) in Developer Mode, drop an <iframe> directly in the XML, or create a computed field that returns the iframe HTML and render it with t-out="0". That goes beyond the no-code Embed Code block.

Can I embed multiple maps on one page?

Yes. Drag multiple Embed Code blocks onto the page. Each block holds one iframe. Make sure the iframe src includes unique place IDs to avoid duplicates.

Does the map work on mobile devices?

Yes. The iframe is responsive if you set width="100%". Google Maps adjusts the view automatically for small screens.

How do I make the map load faster?

Add loading="lazy" to the iframe. Also, set a low-res placeholder image until the map loads. But the embed code does not support custom placeholders.

Why location-based personalization matters

Location-based personalization changes page content, offers, or language based on where a visitor appears to be. Done well, it reduces friction: a shopper sees local inventory, a service business shows nearby technicians, and a global brand displays the right currency and compliance notices. Done poorly, it creates confusion, feels creepy, or breaks entirely for visitors using VPNs, corporate proxies, or privacy-focused browsers.

The stakes are real. When a visitor lands on a page that claims "Available in Chicago" but they are in Miami, trust evaporates. When a popup demands location permission before showing any value, the back button wins. The goal is relevance without fragility.

How location detection works and where it fails

Most implementations start with an IP-to-location database. The server or edge worker reads the incoming IP, queries a geolocation service, and injects the result into the page template. Three common failure points exist:

• Database accuracy: Consumer IP databases are typically accurate to the city level in major metros but degrade to region or country for mobile carriers, corporate networks, and rural areas.
• Client-side vs server-side: Server-side detection runs before the page renders, enabling SEO-friendly personalized HTML. Client-side detection adds a round-trip, causes layout shift, and is blocked by ad blockers or privacy extensions.
• Consent and privacy: GDPR, CCPA, and ePrivacy require consent for precise geolocation. Many sites skip the consent step, exposing themselves to regulatory risk and user backlash.

Common mistake 1: Treating IP location as ground truth

IP-based location is a probabilistic guess, not a fact. A visitor on a corporate VPN in New York may show a London IP. A mobile user tethering through a phone in Austin may resolve to a Dallas data center. If your personalization logic assumes the IP location is exact, you will serve wrong content to a measurable slice of traffic.

Fix: Treat the detected location as a hypothesis. Show a subtle confirmation banner ("We think you're in Chicago — change") and store the visitor's explicit choice in a first-party cookie. Use that choice for subsequent visits.

Common mistake 2: No fallback for unknown or masked locations

VPNs, Tor, enterprise proxies, and privacy browsers (Brave, Safari with ITP) routinely mask or randomize IPs. If your personalization engine throws an error or serves a blank slot when location cannot be resolved, those visitors see a broken page.

Fix: Define a default experience that works everywhere. For a multi-location retailer, show a store locator with a "Use my location" button. For a service business, show the national headline and a zip-code search. The fallback must be functional, not a generic "We serve the whole country" paragraph.

Common mistake 3: Over-personalizing too early in the funnel

Swapping headlines, hero images, and CTAs based on location before the visitor has signaled intent creates a "creepy" feeling. A first-time visitor from Denver who sees "Denver's #1 Plumber" in the H1 may wonder how you knew, especially if they never shared location.

Fix: Reserve aggressive personalization for return visitors or for sessions where the visitor has taken a high-intent action (clicked a "Find a dealer" link, started a quote flow). For cold traffic, use location subtly: adjust shipping messaging, show local phone number format, or pre-select the region in a dropdown.

Common mistake 4: Ignoring language and currency mismatches

Location does not equal language preference. A Spanish-speaking visitor in Miami, a French-speaking visitor in Toronto, or an English-speaking expat in Berlin all break the "location = language" assumption. Currency is similar: a Canadian shopper on a US site sees USD prices but pays in CAD with foreign-transaction fees.

Fix: Decouple language and currency from IP location. Use browser Accept-Language header for language hints. Offer a persistent language/currency selector in the header. Store the choice. For logged-in users, use their profile settings.

Common mistake 5: Caching personalized pages incorrectly

If your CDN caches the personalized HTML at the edge without varying on the location cookie or header, visitors in different cities receive each other's content. This is the most common technical regression after a personalization launch.

Fix: Configure cache keys to include the personalization variant identifier (e.g., X-Personalization-Variant: us-co-denver). Use edge-side includes (ESI) or edge workers to assemble the personalized fragments while keeping the page shell cacheable. Test with a multi-region load test before go-live.

Common mistake 6: Measuring the wrong metrics

Teams often track "personalization impressions" or "variant views" instead of downstream outcomes. A location-specific hero banner may get more clicks but fewer form completions if the offer doesn't match the local market.

Fix: Define a primary conversion metric per page type (lead form submit, add-to-cart, phone click). Run an A/B test with a holdout group that sees the non-personalized control. Require statistical significance before rolling out. Track guardrail metrics: bounce rate, time to interactive, and consent opt-out rate.

Decision framework: Choose the right personalization depth

Start with passive. Measure uplift. Add depth only when the data supports it.

Practical scenarios

Scenario A: Multi-location service business

Goal: Show the nearest technician's photo, phone, and review snippet.

Implementation: Detect region on first visit. Show a "Find your local pro" CTA that opens a zip-code search. On zip submit, set a cookie and render the personalized hero. Cache the hero fragment per zip at the edge. Fallback: national 800 number and a "Enter zip code" field.

Scenario B: Ecommerce with regional inventory

Goal: Show "In stock at your local store" badges.

Implementation: Sync store inventory feed to edge KV store keyed by postal code prefix. On request, read visitor's postal code from cookie (set via zip selector or account profile). Render badge via edge-side include. If no cookie, show "Check store availability" link. Never rely solely on IP for inventory accuracy.

Scenario C: Global SaaS with data residency messaging

Goal: Reassure EU visitors about GDPR compliance and EU data centers.

Implementation: Detect country at edge. If EU, inject a trust badge and link to DPA. Do not gate content behind consent — the badge is informational, not tracking. Cache two page variants (EU / non-EU) at the edge. Test that the badge does not increase CLS.

Limitations and when this advice does not apply

• Native mobile apps: They have access to precise GPS with user permission. The web constraints (IP accuracy, caching, consent) differ.
• Regulated industries (healthcare, finance): Personalization may conflict with fair-lending, HIPAA, or state privacy laws. Legal review required.
• Single-location businesses: Location personalization adds complexity without value. Invest in source-based personalization (matching ad keyword to landing page) instead.
• High-traffic, low-margin sites: The engineering cost of robust edge personalization may exceed the revenue uplift. Run a cost model first.

Key facts

Terminology

Edge worker

Code that runs at the CDN edge (Cloudflare Workers, Fastly Compute@Edge, Vercel Edge Functions) before the response reaches the browser. Enables personalization without origin round-trips.

Cache key

The set of request attributes (URL, headers, cookies) that determine whether a cached response can be reused. Personalization requires varying the cache key on the variant identifier.

First-party cookie

A cookie set by the site's own domain. Survives ITP and most ad blockers. Used to store the visitor's confirmed location choice.

ESI (Edge Side Includes)

A markup language that tells the edge cache to assemble a page from cached fragments. Allows the page shell to stay cached while personalized fragments are fetched separately.

Holdout group

A random sample of visitors who see the non-personalized control experience. Required for valid A/B measurement.

FAQ

How accurate is IP-based geolocation really?

Country-level: 99%+. Region/state: 85-95% in major markets. City: 70-85% for fixed broadband, 50-70% for mobile. Expect 10-20% of traffic to be wrong at city level. Always confirm.

Do I need a consent banner for IP-based personalization?

Under GDPR and ePrivacy, IP address is personal data. If you process it for personalization without a legitimate interest assessment, you need consent. Many sites use a legitimate interest basis for coarse country detection but require consent for city-level or persistent profiling. Consult counsel.

Can I personalize for SEO traffic without cloaking?

Yes, if the personalized content is rendered server-side or at the edge and Googlebot sees the same variant a user from that location would see. Do not serve different content to Googlebot based on its IP. Use the same edge logic for all requests.

What is the minimum viable personalization for a small team?

Passive depth: detect country at edge, set currency and phone format, cache two variants (domestic / international). Add a header selector. Measure conversion lift. That's one sprint.

How do I test personalization across regions without traveling?

Use a VPN or proxy service with exit nodes in target cities. Configure your browser to send a custom X-Forwarded-For header (if your edge logic respects it). Better: use a testing tool like WebPageTest with location agents or a cloud browser grid (BrowserStack, Sauce Labs).

Does personalization hurt Core Web Vitals?

It can. Client-side personalization adds JavaScript execution time and layout shift. Server-side or edge-side personalization adds negligible overhead if the cache hit rate stays high. Monitor LCP, CLS, and INP per variant.

When should I use browser Geolocation API instead of IP?

Only when the user explicitly requests "Find near me" and grants permission. The API prompts the user, works on HTTPS only, and fails in many enterprise environments. Use it as an enhancement, not the primary detection method.

Your Decision Trigger: Separate Accounts Are the Default

If you run Odoo on both a staging domain and a production domain, create a separate SeaText account for each. SeaText links every account to one primary URL. That means one account cannot correctly serve two domains. Using one account for both will mix test data with live data, distort your analytics, and may violate your plan terms.

So the real question is not whether to separate — it is when you can safely skip it. The answer: almost never, unless you are only testing on a temporary domain that you will delete before launch.

Readiness Checklist: Are You Ready to Separate?

Use this checklist before you set up your second SeaText account. If you can tick every box, you are ready.

• You have a real, valid production domain. SeaText restricts development URLs like localhost for security. Use a live domain for both accounts.
• You know which domain is your primary URL for each account. Each account binds to exactly one domain.
• You have a separate email or access path for each account. This keeps logins and billing clear.
• You have a plan that covers two accounts. Check your pricing tier. Some plans may not include multiple accounts.
• You can paste a different code snippet on each site. The Odoo integration uses an embed code per account. Do not reuse the same snippet.
• You have a naming convention. For example, staging-yourbrand and prod-yourbrand.

Signs You Should Wait Before Separating

Do not create a second account yet if any of these apply:

• Your staging domain is temporary. If you use a throwaway subdomain for a one-off test, you may not need a permanent account. But remember: SeaText may not work reliably on dynamic development domains.
• You are still deciding on your production domain. Wait until the final URL is locked. Creating an account for a domain you will change later wastes setup effort.
• You have not confirmed your plan allows multiple accounts. Check pricing first. If it does not, you may need to upgrade or choose which environment gets the account.
• You are not yet running real traffic on staging. If staging is only for internal QA with no visitors, you might not need SeaText there at all.

How SeaText Handles Multiple Domains

SeaText explicitly states: if you need to use it on multiple domains — for example, a development domain and a production domain — you must create separate accounts for each domain. Each account is linked to a single primary URL.

This is not a limitation you can work around with clever configuration. The code snippet you paste into Odoo is tied to your account. When you paste the same snippet on two domains, SeaText cannot reliably associate traffic with the correct account. That breaks attribution and can pollute your conversion data.

Main Options and Trade-Offs

Choose Separate Accounts If...

Choose separate accounts if you answer yes to any of these:

• You run A/B tests or CRO experiments on staging before pushing to production.
• You need to compare conversion data between environments.
• You have different team members responsible for staging versus production.
• You want to avoid any risk of test data contaminating your live analytics.

Choose One Account If...

Choose one account if:

• You only need SeaText on production.
• Your staging domain is a temporary test that you will delete.
• Your plan does not support multiple accounts and you cannot upgrade.

Practical Scenarios

Scenario 1: Ecommerce Store with Active Staging

You run a Shopify-like store on Odoo. Your staging domain is staging.yourstore.com and production is yourstore.com. You test new product copy on staging. You need separate accounts. Otherwise, your staging tests will show up in production analytics.

Scenario 2: Agency Managing Multiple Client Sites

You manage Odoo for several clients. Each client has a staging and production domain. You need a separate SeaText account for each domain — not just per client. That means two accounts per client if you want both environments covered.

Scenario 3: Pre-Launch Startup

You are still building your Odoo site. You have not launched. You only need SeaText on your staging domain for now. Create one account for staging. When you launch, create a second account for production. Do not try to reuse the staging account.

Limitations and When This Advice Does Not Apply

This guidance assumes you are using SeaText on Odoo websites. If you are not using Odoo, the same rule applies: one account per domain.

There is one exception: if you only need SeaText on one environment and you never plan to use it on the other, you do not need two accounts. But if you think you might later, create both now to avoid rework.

Also note: SeaText restricts development URLs such as localhost. Dynamic development domains may not work properly. Use a real, valid domain for each account.

Key Facts

Frequently Asked Questions

Can I use one SeaText account for both staging and production?

No. Each SeaText account is linked to a single primary URL. You need a separate account for each domain.

What happens if I use the same snippet on both domains?

SeaText may not reliably associate traffic with your account. Your data will be mixed and inaccurate.

Does it cost more to have two accounts?

It depends on your plan. Check the pricing page to see if multiple accounts are included or if you need to pay per account.

Can I use localhost for staging?

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

What if my staging domain changes frequently?

Dynamic development domains may not work properly. Use a stable, real domain for your staging account.

Do I need separate accounts for separate business units?

Yes. If each business unit runs on a different domain, each domain needs its own SeaText account.

How do I set up the second account?

Create a new SeaText account, copy the code snippet for that account, and paste it into the Embed Code module on your Odoo staging site. Repeat for production with a different account.