Yes, you can use SEATEXT on both development and production domains — here’s how

Direct answer: use separate SEATEXT accounts

Yes, SEATEXT works on both development and production domains, but not with the same account. Each SEATEXT account is tied to one primary URL. So if you run a staging site and a live site, create a separate account for each domain and install a different snippet on each.

This is clearly stated in SEATEXT’s WP Engine integration guide: “If you want to use SEATEXT on both a staging domain and a production domain, create a separate SEATEXT account for each site.” It also warns that development URLs such as localhost are restricted for security reasons, and recommends using a real domain whenever possible.

Why does this matter? Because SEATEXT optimizes your page based on real visitor behavior and conversions. If you mixed staging and production traffic, the AI would treat them as one site. Test clicks from your staging environment would pollute the production data. That would make your reports unreliable and the optimization decisions less accurate.

Why the one-account-per-domain rule exists

SEATEXT works by installing a JavaScript snippet in your site's header. That snippet connects the page to your SEATEXT account. The account stores the settings, optimization data, and reports for that specific domain.

If you used the same snippet on two domains, the account would receive signals from both. That would mix staging and production data. The source says “Each account is linked to a single primary URL.” So SEATEXT is designed to track one site per account.

This rule exists for practical reasons. Staging sites often have test content, dummy purchases, and low traffic. Production sites have real users and real conversions. Mixing these would make your optimization reports meaningless. The separation also lets you test changes on staging without affecting the live site’s optimization.

How SEATEXT associates with a domain

When you add the SEATEXT JavaScript snippet to your site, it connects that page to your account. The snippet is site-specific — copy it from your account, paste it into your site’s header, and SEATEXT will recognize the domain and start tracking and optimizing.

Because each account is linked to a single primary URL, you can’t use the same snippet on two different domains and expect both to sync properly. The easiest way around this is to create two accounts: one for staging, one for production.

The association happens at the domain level. SEATEXT reads the domain from the page URL. It then matches that domain to the account that holds the corresponding snippet. If you put the production snippet on a staging site, SEATEXT will not recognize it because the staging domain is different from the production domain recorded in that account. That is why you need a different snippet for each environment.

What counts as a valid domain: localhost, dynamic URLs, and subdomains

SEATEXT restricts development URLs like localhost for security reasons. The source says “Development URLs such as localhost are restricted for security reasons.” So you cannot use http://localhost or 127.0.0.1.

Temporary dynamic URLs — like those from some cloud development environments that change each time you start a session — are also discouraged. The guide says to “avoid relying on temporary dynamic development URLs if you can.” These URLs are unreliable because they change often. SEATEXT cannot maintain a stable connection to a URL that changes every time.

What works? A real domain. This includes a subdomain like staging.example.com. As long as it's a publicly accessible domain that SEATEXT can reach, it works. For production, use your main domain like www.example.com or example.com.

The decision criteria are simple: Does the URL stay constant? Is it publicly reachable? If yes, it is valid. If it is localhost or changes, it is not.

Many teams already have a subdomain like staging.example.com for their staging environment. That works perfectly. If you do not have a staging subdomain, consider creating one. It is often easier than dealing with a dynamic local development URL.

Step-by-step: setting up staging and production accounts

Here is the process you need to follow:

1. Create a SEATEXT account for your production domain (for example, www.example.com). Note the snippet that appears in your dashboard.
2. Create a second SEATEXT account for your staging domain (for example, staging.example.com). You’ll get a different snippet.
3. Install the production snippet on your live site’s header, using your CMS’s custom code area or a header-injection plugin.
4. Install the staging snippet on your staging site’s header, using the same method.
5. Clear any caching or minification settings on both sites so the scripts load without interference.
6. Visit each site a few times, stay on the page for about 40 seconds, then check your SEATEXT account to confirm the website name appears.

This process is the same regardless of your platform. SEATEXT no longer offers a WordPress plugin, so on WordPress sites you’ll add the snippet manually or via a plugin like WPCode or Insert Headers and Footers.

If you are using WP Engine, the guide recommends using the custom code area or a header-injection plugin. After adding the snippet, clear the cache. This ensures the script loads on the next visit.

For other platforms like Shopify, Wix, or Webflow, the header insertion method is different, but the core idea is the same: place the correct snippet in the site-wide header. Check the SEATEXT installation documentation for platform-specific details.

Common mistakes and how to avoid them

• Using the same account for both domains. This won’t work because each account is locked to one URL. Create two accounts.
• Trying to use localhost. SEATEXT blocks development URLs like localhost. Use a real domain or a public staging URL.
• Using a temporary dynamic URL. If your development environment gives you a new URL each session, SEATEXT will not stay connected. Set up a stable subdomain instead.
• Putting the snippet in the footer. The snippet must be in the header. Re-check your setup if the site doesn’t appear in your account.
• Caching plugins stripping or combining the script. Clear your cache and exclude SEATEXT from minification or script combination rules.
• Expecting immediate sync. After installing, refresh the page and stay for about 40 seconds. It may take a few minutes for the site name to show up in your account.

Another mistake is forgetting to verify each environment separately. If you install both snippets, you must verify that each one loads on the correct domain. A common error is accidentally copying the production snippet to the staging site. Double-check the domain in your account settings.

Limitations and when this advice doesn’t apply

The main limitation is the one-account-per-domain rule. If you try to run SEATEXT on a subdomain that is just a different path of the same site, you still need a separate account if it’s a distinct URL. The restriction on localhost means you can’t test locally for free — you need a publicly accessible domain.

If your development environment uses a fixed IP or a real domain that SEATEXT can crawl, it will work. If it uses a temporary URL that changes with each build, it won’t be reliable — the guide suggests avoiding those altogether. In short, the advice applies to any setup where you have a real, stable URL for each environment.

There is also a practical limit on the number of accounts you might need. If you have multiple staging environments (e.g., separate branches for different features), you will need an account for each distinct URL. This could get expensive, but it is the only way to keep the data clean.

Finally, this advice is specific to the SEATEXT JavaScript snippet. If you use a different integration method (like a server-side API), the rules might differ. Check the official documentation for the latest guidance.

Frequently asked questions

Can I use the same SEATEXT account for both my development and production sites?

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

Why is localhost restricted?

SEATEXT blocks development URLs like localhost for security reasons. The source says “Development URLs such as localhost are restricted for security reasons.”

What should I use instead of localhost?

Use a real domain whenever possible. A stable subdomain for staging (e.g., staging.example.com) is acceptable. Avoid temporary dynamic development URLs that change.

How do I install the snippet on a WordPress site?

SEATEXT no longer offers a WordPress plugin. Copy your site-specific JavaScript snippet from your SEATEXT account, paste it into the site-wide header via your theme’s custom code area or a plugin like WPCode, then clear cache and test.

How long does it take for my site to appear in my SEATEXT account?

After installing the snippet, refresh the site and stay on the page for about 40 seconds. Within a few minutes, your website name should appear in your SEATEXT account.

Can I use a subdomain like dev.example.com for staging?

Yes, as long as it’s a real, publicly accessible domain. The restriction applies to localhost and temporary dynamic URLs, not to proper subdomains.