Choose subdirectories when you have limited technical resources, want consolidated domain authority, target languages not tied to specific countries, or need faster launch with lower maintenance.

Separate domains (for example, example.fr) work better when you need strong local trust, legal separation, or distinct branding per country.

Recommendation: Use subdirectories if you have a small team, limited budget, or target languages spoken across many countries. Switch to separate domains when you must prove local presence, comply with country‑specific regulations, or need isolated hosting for performance.

Definition: Subdirectories versus separate domains for language versions

A subdirectory adds a language folder after the main domain, such as example.com/fr/. A separate domain uses a distinct country‑code top‑level domain, like example.fr, for each language version.

Why the choice matters

The URL structure influences how search engines pool link equity. It also determines how much engineering work you need for deployment, SSL, analytics, and ongoing maintenance. User perception of local relevance can differ between a folder and a country‑code domain.

How subdirectories work

You host all language versions on the same host and IP address. A single SSL certificate covers the whole site. You add hreflang link elements in the head of each page to tell search engines which language and region each URL targets. The same content management system serves every language, so updates propagate instantly.

How separate domains work

You register a ccTLD for each target country. Each domain can point to the same server or to different servers. You may run a multisite installation that isolates databases, SSL certificates, and analytics per domain. Hreflang tags still apply but must reference the full domain URLs.

Readiness checklist: When to use subdirectories

• Your team has limited time or budget for server setup.
• You want all language versions to benefit from the same domain authority.
• You target languages spoken in many countries (e.g., Spanish, French, Arabic).
• You need to launch quickly and keep maintenance simple.
• You can manage hreflang tags across a single site.
• You do not require a separate legal entity per country.
• Your hosting plan allows unlimited subfolders without extra cost.

Practical scenarios

Scenario 1: A global SaaS startup wants Spanish and German versions but has only one developer. Subdirectories let them launch in weeks, share backlinks, and avoid multiple SSL purchases.

Scenario 2: A local law firm in France needs a French site that signals a physical presence. A .fr domain builds trust with French clients and satisfies bar‑association rules.

Scenario 3: An e‑commerce brand plans to add ten languages over two years. Starting with subdirectories reduces initial complexity. They can migrate high‑traffic languages to ccTLDs later if local conversion data justifies the cost.

Scenario 4: A multinational corporation must comply with data‑residency laws in Germany and Brazil. Separate domains hosted in each country meet legal requirements while keeping brand consistency.

Limitations and when the advice does not apply

The guidance assumes you can implement hreflang correctly. If you cannot maintain accurate tags, separate domains may avoid mis‑signals that hurt rankings.

If legal regulations demand a distinct legal entity per country, a separate domain is often required to display the correct registration information.

If you need to host each language on different servers for latency or compliance reasons, separate domains give that flexibility.

If your brand strategy calls for completely different visual identity per market, a ccTLD can reinforce that separation more clearly than a folder.

Key facts from SeaText

Frequently asked questions

1. Why does consolidating authority help rankings? All language versions share backlinks and domain strength, boosting each other's visibility.
2. How do hreflang tags work with subdirectories? You add a link rel="alternate" hreflang="x" pointing to each language version, including an x-default for the fallback.
3. When should you consider switching from subdirectories to separate domains? When you need strong local trust, legal separation, or distinct branding that a country‑code domain provides.
4. What does it cost to maintain subdirectories versus separate domains? Subdirectories need one domain fee and one SSL certificate; separate domains require a fee and certificate for each country‑code domain.
5. What should you compare when deciding between the two structures? Compare technical effort, authority consolidation, local trust signals, legal requirements, and long‑term maintenance.

Moving from a structure like example.com/fr/ to example.fr is a site migration. Treat it like one. The core work is a 1:1 URL map, server‑side 301 redirects, hreflang updates, Search Console change‑of‑address notifications, and a 90‑day monitoring window. Skip any step and you risk traffic loss.

Prerequisites before you start

Register every target ccTLD or gTLD you plan to use (example.fr, example.de, example.es, etc.). Point each domain's DNS A or ALIAS record to your origin server. Provision a multi‑domain (SAN) or wildcard TLS certificate so every domain serves HTTPS without browser warnings. Confirm your CMS can route requests by hostname — WordPress multisite, a reverse proxy, or a translation layer like SeaText that detects the domain and serves the correct language.

Export a complete crawl of the current site (Screaming Frog, Sitebulb, or your preferred crawler). Include every indexable URL, its language subdirectory, canonical, and current hreflang annotations. This crawl becomes your migration map.

Step 0: Export a 1:1 URL map with SeaText

SeaText offers a URL‑mapping export feature. After crawling your example.com site, click Export URL map in the SeaText dashboard. The CSV contains old_url and new_url columns for each language. Import the same file into your server or CDN redirect tool to create the 1:1 301 map automatically. Keep the file for future audits.

Step 1: Build the 1:1 URL mapping spreadsheet

Create a sheet with three columns: Old URL (e.g., https://example.com/fr/produits/chaussures), New URL (e.g., https://example.fr/produits/chaussures), and Status. Keep the path identical; only the hostname changes. Do not restructure slugs, change parameters, or rename categories during the same migration. Any extra change adds risk and makes troubleshooting harder.

Flag URLs that return 4xx, 5xx, or redirect chains in the Status column. Fix those on the old structure first so the 301s point to healthy destinations.

Step 2: Implement server‑side 301 redirects

Add redirect rules at the web server (Nginx, Apache) or CDN/edge layer (Cloudflare Workers, CloudFront Functions, Netlify Edge Handlers). A single rule pattern works for most sites:

# Nginx example
server {
  server_name example.com;
  location /fr/ {
    return 301 https://example.fr$request_uri;
  }
  location /de/ {
    return 301 https://example.de$request_uri;
  }
  # repeat per language
}

Test each rule with curl -I before going live. Verify the response is a single 301 with the correct Location header and no intermediate 302s. Keep the old subdirectory structure accessible for at least 180 days — do not delete the folders or rewrite rules until Search Console shows zero crawl errors on the old URLs.

Step 3: Update hreflang to reference the new domains

On every page of every new domain, output bidirectional hreflang link elements in the <head> (or via HTTP header for non‑HTML resources). Each language version must reference all other language versions on their new domains plus an x-default.

<link rel="alternate" hreflang="fr" href="https://example.fr/produits/chaussures" />
<link rel="alternate" hreflang="de" href="https://example.de/produkte/schuhe" />
<link rel="alternate" hreflang="en" href="https://example.com/products/shoes" />
<link rel="alternate" hreflang="x-default" href="https://example.com/products/shoes" />

SeaText translates new pages automatically across 125 languages and lets you edit every translation. Hreflang tags must be added and maintained by you; SeaText does not generate them automatically.

Step 4: Submit change of address in Google Search Console

Add each new domain as a separate property in Search Console (domain‑level verification via DNS TXT record is fastest). In the old property (example.com), open Settings → Change of address. Select the new domain property for the corresponding language (e.g., example.fr for the French migration). Submit. Repeat for every language domain.

Google will validate the 301s and hreflang. Expect a processing time of a few days to two weeks. During this window, keep both old and new properties verified.

Step 5: Monitor indexing, rankings, and crawl health for 90 days

Track three dashboards daily for the first two weeks, then weekly:

• Index coverage (Search Console → Indexing → Pages) for each new domain: look for "Indexed, not submitted in sitemap" and "Crawled – currently not indexed" trends.
• Ranking positions for your top 200 keywords per language (use a rank tracker that supports per‑domain tracking).
• Crawl stats (Search Console → Settings → Crawl stats) to confirm Googlebot is spending budget on the new hostnames.

If any language shows a >15% drop in clicks after 30 days, audit the redirect map for that language first — missing or malformed 301s are the most common cause.

Common mistakes that kill migrations

1. Changing URL paths at the same time. Keep slugs identical. Migrate structure first, redesign later.
2. Using 302 or meta‑refresh redirects. Only 301 passes full link equity and triggers change‑of‑address.
3. Forgetting hreflang on the new domains. Without it, Google treats each domain as a separate site with no language relationship.
4. Skipping x-default. Users from unsupported languages need a fallback; x-default points them to your primary language (usually English on the root domain).
5. Removing the old subdirectories too early. Keep them live until Search Console reports zero crawl errors on the old URLs for 30 consecutive days.

Key facts about SeaText translation for multi‑domain setups

Limitations and when this playbook does not apply

• If you are consolidating multiple existing domains into subdirectories, reverse the steps (map new subdirectory URLs, 301 from old domains, update hreflang to subdirectories).
• Sites on platforms that cannot serve different content by hostname (some hosted builders) need a reverse proxy or DNS‑based translation layer; SeaText's JavaScript snippet works on any platform but server‑side rendering is preferred for SEO.
• Legal or regulatory requirements in some countries (e.g., China's ICP license, Russia's data localization) may require separate hosting, not just separate domains. This playbook assumes a single origin.
• If your current subdirectories use different content per language (not translations), a 1:1 map is impossible. You need a content audit first.

Terminology quick reference

ccTLD

Country‑code top‑level domain (e.g., .fr, .de, .jp). Strongest geo‑targeting signal.

gTLD

Generic top‑level domain (e.g., .com, .net, .eu). Requires Search Console geo‑targeting or hreflang for country signals.

SAN certificate

Subject Alternative Name TLS certificate securing multiple distinct hostnames in one cert.

Change of address

Search Console tool that tells Google a site has moved to a new domain; speeds up index transfer.

x-default

Hreflang value indicating the fallback page for users whose language has no dedicated version.

FAQ

How long does the migration take to settle?

Most sites see stable indexing within 2‑4 weeks. Full ranking recovery can take 60‑90 days. Keep monitoring for 90 days before declaring success.

Can I migrate one language at a time?

Yes. Migrate your lowest‑traffic language first to validate the process, then roll out to larger languages. Update hreflang globally each time so the cluster stays consistent.

Do I need separate Search Console properties for each domain?

Yes. Domain‑level properties (verified via DNS) are required for the change‑of‑address tool.

What if I use a CDN like Cloudflare?

Implement 301 redirects at the edge (Cloudflare Workers or Bulk Redirects). It's faster, reduces origin load, and avoids an extra hop.

Will I lose link equity?

Proper 301s pass the vast majority of link equity. The bigger risk is broken redirects or missing hreflang causing Google to treat the new domains as unrelated sites.

Can SeaText help with the migration itself?

SeaText does not move URLs or configure DNS. It translates new pages automatically across 125 languages and lets you edit every translation. Hreflang tags must be added by you.

How do I use SeaText's URL‑mapping export/import for redirects?

In the SeaText dashboard, open the URL Mapping tool, click Export CSV. The file lists old subdirectory URLs and the matching new domain URLs. Import that CSV into your server, CDN, or redirect manager to create the 1:1 301 rules automatically. Keep the CSV for audits and future changes.

Diagnostic sequence: verify the migration is healthy

1. Run site:example.fr (per domain) — confirm indexed URLs match your map count.
2. Check Search Console → Indexing → Pages for each new domain — zero "Redirect error" or "Page with redirect" warnings.
3. Fetch a sample of old URLs with curl -I — single 301, correct Location, no chain.
4. Inspect hreflang on new pages (View Source or SEO tool) — bidirectional links present, x-default included.
5. Compare Search Console Performance reports (old vs new domains) — clicks shifting to new domains without total drop.
6. Run a fresh crawl of new domains — 200 OK, canonicals self‑referencing, no mixed‑content warnings.

To serve a multilingual WordPress site on separate country-code domains, you need DNS records that point each domain to the same server IP (or load balancer) and a web server configured to accept all those hostnames. The process is straightforward: create one A record per domain pointing to your server IP, or use ALIAS/CNAME records when a CDN or load balancer sits in front. Then configure Nginx or Apache so every domain serves the same WordPress installation.

Prerequisites before you touch DNS

Gather the following before you log in to your DNS provider:

• The public IP address of your WordPress server (or the hostname of your load balancer/CDN).
• A list of every language domain you plan to use (for example, example.fr, example.de, example.es).
• Access to your DNS management console (Cloudflare, Route 53, GoDaddy, etc.).
• Root or sudo access to the web server so you can edit virtual host configuration.
• An SSL strategy: either a multi-domain (SAN) certificate covering all domains, a wildcard certificate if you use subdomains, or automated certificates via Let's Encrypt on each hostname.

Step 1: Create A records for each language domain

Log in to your DNS provider and add an A record for every custom domain. Set the host to @ (root) and the value to your server IP. Keep TTL low (300 seconds) while you test, then raise it to 3600 or 86400 once everything works.

1. example.fr → A → 203.0.113.10
2. example.de → A → 203.0.113.10
3. example.es → A → 203.0.113.10

If you use a CDN (Cloudflare, CloudFront, Fastly) or a managed load balancer (AWS ALB, Google Cloud Load Balancing), create ALIAS (Cloudflare) or CNAME records pointing to the CDN/load balancer hostname instead of an IP. ALIAS records work at the zone apex; CNAME records do not.

Step 2: Verify DNS propagation

Wait for propagation, then confirm each domain resolves to the expected target:

dig +short example.fr
# should return 203.0.113.10 (or your CDN hostname)
dig +short example.de
dig +short example.es

You can also use nslookup or online tools like DNS Checker to verify global propagation.

Step 3: Verify your domains in SeaText

After DNS propagation confirms each domain reaches your server, use SeaText's domain verification tool to ensure every custom language domain points to the correct WordPress installation. This step prevents misrouting before you configure translation settings.

1. Log in to your SeaText dashboard and open the Website Translation Agent settings.
2. Navigate to Domains or Language Mapping (exact label depends on your plan).
3. Enter each custom domain (example.fr, example.de, example.es) in the provided fields.
4. Click Verify or Check Connection. SeaText will perform a live HTTP/HTTPS request to each domain and confirm the response comes from your WordPress site (it checks for the WordPress REST API endpoint or a known marker).
5. If verification fails, the tool reports the HTTP status, redirect chain, or certificate mismatch. Fix the DNS or web server config, then re-run verification.
6. Once all domains show Verified, assign the corresponding language code (fr_FR, de_DE, es_ES) to each domain and save.

This verification runs against the live site, so it catches issues that dig alone cannot: wrong document root, missing virtual host entry, or SSL certificate covering only the primary domain.

Step 4: Configure the web server to accept all hostnames

Nginx example

Edit your site configuration (typically /etc/nginx/sites-available/your-site) and list every domain in the server_name directive:

server {
    listen 80;
    listen 443 ssl http2;
    server_name example.com example.fr example.de example.es;
    root /var/www/wordpress;
    index index.php;
    # ... SSL cert paths, PHP handling, etc.
}

Reload Nginx: sudo nginx -t && sudo systemctl reload nginx.

Apache example

In your virtual host file (e.g., /etc/apache2/sites-available/your-site.conf):

<VirtualHost *:80>
    ServerName example.com
    ServerAlias example.fr example.de example.es
    DocumentRoot /var/www/wordpress
    # ... SSL config, rewrite rules, etc.
</VirtualHost>

Enable the site and reload: sudo a2ensite your-site && sudo systemctl reload apache2.

Step 5: Secure every domain with SSL/TLS

Browsers require HTTPS. You have three practical options:

• Let's Encrypt with Certbot — run certbot --nginx -d example.com -d example.fr -d example.de -d example.es (or --apache) to obtain a single SAN certificate covering all domains.
• Multi-domain (SAN) certificate from a CA — purchase a certificate that lists every domain in the Subject Alternative Name field.
• Wildcard certificate — only works if you use subdomains (fr.example.com, de.example.com), not separate apex domains.

Automate renewal (Certbot does this via systemd timer or cron). Test with certbot renew --dry-run.

Step 6: Tell WordPress about the language domains

WordPress must know which domain maps to which language. Two common approaches:

• WordPress Multisite (network install) — each language gets its own site in the network, mapped to a custom domain via the Domain Mapping plugin or native domain mapping (WP 4.5+).
• Single-site with a translation plugin — plugins like WPML, Polylang Pro, or TranslatePress (premium) let you assign a domain per language on a single WordPress install. SeaText's Website Translation Agent works alongside these plugins to translate content into 125 languages automatically.

In the plugin settings, enter each domain (example.fr, example.de, example.es) and assign the corresponding language code (fr_FR, de_DE, es_ES). Save and flush permalinks.

Step 7: Add hreflang tags for SEO

Each page must include bidirectional hreflang links in the <head> pointing to every language version plus an x-default. Example for the homepage:

<link rel="alternate" hreflang="x-default" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.fr/" />
<link rel="alternate" hreflang="de" href="https://example.de/" />
<link rel="alternate" hreflang="es" href="https://example.es/" />

Most multilingual plugins generate these automatically. SeaText's translation agent keeps hreflang tags in sync when new content is published.

Step 8: Verify the full chain

1. Visit each domain in a browser — confirm HTTPS, correct language, and no mixed-content warnings.
2. Run curl -I https://example.fr — expect HTTP 200 and Content-Language: fr header if your setup adds it.
3. Check Google Search Console: add each domain as a separate property, submit sitemaps, and monitor indexing.
4. Use the hreflang validator to confirm tags are correct.

Common mistakes to avoid

• Pointing domains to different servers or document roots — all must serve the same WordPress install.
• Forgetting to add ServerAlias (Apache) or extra server_name entries (Nginx) — requests will hit the default virtual host and show the wrong site.
• Using CNAME at the zone apex — not allowed by RFC; use ALIAS (Cloudflare, DNSimple) or A records.
• Skipping hreflang — search engines may treat each domain as a separate site with duplicate content.
• Using a single-domain SSL certificate — visitors on other domains will see certificate warnings.

Key facts about SeaText's translation capabilities

Limitations of this DNS-only guide

This article covers DNS and web server configuration only. It does not address:

• WordPress Multisite network setup or database configuration.
• Translation plugin licensing, compatibility, or content workflow.
• Geo-targeting settings in Google Search Console (each domain property can be targeted to its country).
• Email delivery for each domain (MX, SPF, DKIM, DMARC records are separate).
• Performance tuning (caching, CDN cache keys per hostname, cookie domains).

Terminology quick reference

A record

Maps a domain name directly to an IPv4 address.

ALIAS record

A pseudo-record (supported by some DNS providers) that behaves like a CNAME at the zone apex.

CNAME record

Maps a domain name to another hostname; cannot be used at the zone apex.

SAN certificate

Subject Alternative Name certificate — a single TLS certificate valid for multiple distinct domain names.

hreflang

HTML link attribute telling search engines which language and region a page targets.

Document root

The filesystem directory from which the web server serves files for a given virtual host.

FAQ

Can I use a CNAME for example.fr if I use Cloudflare?

Cloudflare supports CNAME flattening at the apex, so you can create a CNAME for example.fr pointing to your Cloudflare load balancer hostname. Other providers require an ALIAS or A record at the apex.

Do I need a separate WordPress install for each domain?

No. A single WordPress install (with a multilingual plugin or Multisite) can serve all domains. The web server just needs to accept every hostname.

What if my server IP changes?

Update every A record to the new IP. If you use a load balancer/CDN hostname via ALIAS/CNAME, you only update the load balancer's IP — DNS records stay the same.

How long does DNS propagation take?

Typically 5–60 minutes with low TTL; up to 48 hours globally if TTL was high. Use dig against multiple resolvers to confirm.

Does SeaText handle DNS configuration?

SeaText translates content and generates hreflang tags automatically. DNS and web server configuration remain your responsibility (or your host's).

Can I mix subdirectories and custom domains?

Yes, but it adds complexity. Each language must have a single canonical URL structure. Pick one approach per language.

What about email for these domains?

Add MX, SPF, DKIM, and DMARC records for each domain at your DNS provider. Email is independent of the web server configuration described here.

Why use a domain per language

A domain per language gives each market a clear, local address. Users trust a .fr or .de URL more than a subdirectory. Search engines treat each domain as a separate property, which can improve click‑through rates in local results. Brand consistency stays intact because the same WordPress backend powers every domain.

How it compares with subdirectories and subdomains

Subdirectories (example.com/fr/) keep everything on one domain. They are easier to set up but share authority across languages. Subdomains (fr.example.com) separate authority but still share the root domain. Custom domains (example.fr) provide the strongest local signal, but they require separate DNS, SSL, and domain registration. Choose based on budget, technical resources, and how much local trust matters for each market.

DNS and SSL prerequisites

Each custom domain must point to the same WordPress server. Create an A record or CNAME for every domain in your DNS provider. Obtain a valid SSL certificate for each domain; a wildcard certificate works only for subdomains, not for separate top‑level domains. Without HTTPS, browsers will warn visitors and search engines may penalize the site.

How SeaText handles language detection and translation

SeaText installs on one WordPress site. It detects each visitor’s language from browser headers, IP, or URL. The plugin then serves the translated version instantly. New posts, products, and updates are translated in the background into all 125 supported languages. No page or language caps apply, according to the source pack.

hreflang behavior with custom domains

SeaText automatically adds hreflang tags to every translated page. When each language lives on its own domain, the tags reference the full domain URLs (e.g., https://example.fr/... hreflang="fr"). An x‑default tag points to the primary language version. This helps search engines understand the relationship between the domains. Verify the output in the page source after activation.

Ongoing translation workflow and dashboard control

All translations are managed from a single SeaText dashboard. You can review machine output, edit any string, and lock high‑value pages. The dashboard also supports A/B testing of translation variants to find the best‑performing copy per market. The source pack confirms these editing and testing capabilities.

Limitations and things to watch

SeaText handles translation and language detection, but you still need proper SSL certificates for each custom domain and correct DNS configuration. The source pack does not describe a dashboard feature that maps a specific domain to a specific language; you may need to configure that mapping at the server or CDN level. Check with the vendor for the exact steps. Hosting resources and domain registration costs are the only practical limits on the number of domains.

Expert take

Aleyda Solis, International SEO Consultant: "A domain‑per‑language strategy works well when you have the budget for separate domains and the technical ability to manage DNS and SSL at scale. SeaText’s single‑install approach removes the content‑management headache, but you must ensure the hreflang tags reference the correct domain URLs. Test the setup with Google Search Console’s International Targeting report before launching."

Frequently asked questions

• Do I need separate WordPress installs for each domain? No. SeaText runs on a single install; you only point domains to that install.
• Can I edit translations manually? Yes. The dashboard lets you review and edit any translation, preserving brand voice.
• Is there a limit to how many domains I can use? There is no built‑in limit; the only constraints are domain registration and hosting resources.
• How does SEO work with multiple domains? SeaText automatically adds hreflang tags and an x‑default tag, helping search engines understand the language‑domain relationship.
• What if a visitor’s language isn’t one I’ve enabled? SeaText falls back to the default language or the x‑default version.
• Does SeaText provide a dashboard control to map each domain to a language? The current documentation does not confirm that feature. Verify with the vendor before planning the migration.

Stick with a free plugin when your site has under 50 pages, targets one or two extra languages, and you can manually review every translation. Switch to a paid solution the moment you add a third language, publish new content weekly, or need search‑visible multilingual SEO without hiring translators.

Stick with free under 50 pages and 1–2 languages; upgrade at 50+ pages, 3+ languages, or weekly publishing.

How free translation works

Free plugins, including SeaText’s free tier, use machine translation to convert your WordPress content into 125 languages. When you publish a new page or post, the plugin detects it and translates the text automatically. The translation runs in the background, so your site stays live. You can edit any translation manually, preserve your brand voice, and review key pages before they go public. There are no page limits, language limits, or traffic caps. This works because the plugin sends your content to a translation engine, gets the result, and stores it on your site. The process takes minutes, not hours.

Cost and time trade-offs

Free translation costs nothing in money but requires your time. You must review translations for accuracy, fix errors, and manage multilingual SEO if you want search engines to index your pages. If you have a small site with a few languages, the time investment is small. As your site grows, the time needed to review and maintain translations increases. A paid tier automates SEO, provides priority processing, and offers A/B testing. It saves you hours each week. The cost of paid plans is typically a monthly subscription. Compare that to the cost of hiring a translator or the lost revenue from poor search rankings. For many sites, the paid tier pays for itself quickly.

When a paid tier is worth it

Consider upgrading when you have 50 or more pages, three or more languages, or publish new content weekly. Paid tiers add automatic multilingual SEO, including hreflang tags, translated URLs, and XML sitemaps per language. You also get A/B-tested translation variants that find the best wording for each market. Compliance support helps with legal or regulatory pages. Priority processing means new translations go live in minutes, not hours. If you run an ecommerce store, SaaS marketing site, or lead-gen funnel, the paid tier is usually worth it. The extra conversions and traffic from better SEO and optimized copy cover the cost.

How to evaluate translation quality

Test translation quality before committing to a paid plan. Pick a few key pages — your homepage, a product page, and a blog post. Translate them with the free tier. Ask a native speaker to review the results. Look for mistakes in tone, grammar, and cultural context. Check if the translations preserve your brand voice. If you find errors that affect meaning, the paid tier’s A/B testing and brand-voice controls can help. Also check search engine indexing. Use Google Search Console to see if your translated pages appear in search results. If they don’t, you likely need the paid tier’s SEO features.

Common migration pitfalls

Switching from free to paid or between plugins can cause problems. One pitfall is losing existing translations. Before upgrading, ensure your plugin keeps your translations intact. Another pitfall is broken URLs. If you change URL structures, update your sitemaps and redirects. Also, check that your SEO metadata transfers correctly. Hreflang tags, canonical URLs, and language switchers must work. Test your site thoroughly after migration. Use a staging environment if possible. If you use a CDN, clear the cache after migration. Lastly, train your team on the new features. A/B testing and brand-voice controls require some setup.

How to test whether paid features pay off

Run a controlled test. Start with a free tier for one month. Measure your traffic, conversions, and time spent on translation. Then upgrade to paid for one month. Compare the results. Focus on metrics like organic traffic from non-primary languages, bounce rates, and conversion rates. Track the time you save. If the paid tier improves your bottom line, keep it. If not, you can revert to free. Many plugins offer a free trial of paid features. Use that trial to test A/B testing, SEO, and priority processing. Also, ask your support team for a demo. They can help you understand the value for your specific site.

Key facts

Limitations & when this advice does not apply

• Enterprise sites with custom CMS or headless WordPress may need API‑level integration not covered here.
• Sites requiring certified human translation for legal contracts should budget for professional linguists regardless of plugin tier.
• If your hosting blocks outbound API calls, automatic translation will fail — check firewall rules first.

FAQ

Can I start free and upgrade later without re‑translating?

Yes. SeaText keeps your existing translations; upgrading unlocks A/B testing, compliance support, and priority processing on top of what you already have.

Does the free tier include hreflang tags and translated URLs?

Yes. Free tier includes multilingual SEO metadata.

How does automatic translation handle new WooCommerce products?

When you publish a product, SeaText detects it, translates title, description, attributes, and checkout strings, and pushes the live version — usually within minutes.

What if I need a language not in the 125?

Contact support; custom language models can be added on paid plans.

Is there a traffic or page‑view cap on the free tier?

No page limits, no language limits, and no traffic caps on the free tier.

Can I exclude specific pages from automatic translation?

Yes. You can mark pages as do‑not‑translate or review‑only in the dashboard.

What happens if I cancel a paid plan?

You revert to the free tier: translations stay, but A/B testing, compliance support, and priority processing are disabled.

When WordPress or a translation plugin updates, the plugin may replace the existing .po/.mo files or add new source strings. If the plugin doesn’t automatically rebuild its translation catalog, the new strings stay untranslated and previously cached strings can disappear.

What causes missing strings after updates?

WordPress stores translations in .po/.mo files that map original text to translated text. An update can:

• Overwrite the old .po/.mo files with a fresh copy that lacks custom strings.
• Add new source strings that were never added to the translation files.
• Change the text domain or file locations, breaking the link between code and translations.

Before/after example: Before an update, “Add to Cart” appears as “Añadir al carrito.” After the update, the same button shows “Add to Cart” in English because the plugin replaced the .mo file with a default version that only contains core strings.

Understanding .pot, .po, and .mo files

These three file types work together to deliver translations. The table below explains their roles:

Free plugins often regenerate only the .po file after an update. If the .mo file is not recompiled, WordPress sees an empty catalog and falls back to English.

What happens to language files during an update?

When a plugin or theme updates, the update process:

1. Downloads the new version’s files, including fresh .pot, .po, and .mo files.
2. Replaces the old files in wp-content/plugins/your-plugin/languages/.
3. Deletes any custom .po or .mo you may have added.

If the update also introduces new source strings, those strings are missing from the replacement files. The catalog becomes outdated. The WordPress Polyglots team explains that this is a common cause of “missing strings” tickets.

Why free plugins may fail to regenerate the catalog

Most free translation plugins rely on a manual scan or a background cron job. If the cron job fails, or if the plugin does not hook into the update process, the catalog stays stale. Common reasons:

• The plugin does not run a string rescan after an update.
• Server limits (memory, execution time) stop the regeneration.
• The plugin depends on an external service that is not available.

According to Loco Translate’s FAQ, “if your translations are not showing, it’s usually because the .mo file is missing or out of date.”

Diagnostic sequence to identify the issue

1. Check the plugin’s version history for recent updates.
2. Open the WordPress admin → Tools → Site Health and look for translation‑related warnings.
3. Inspect the wp-content/languages folder for .po/.mo files that have a recent timestamp but a small file size (often a sign they were overwritten).
4. Use SEATEXT’s “Rescan strings” button (if available) or run wp i18n make‑pot to regenerate the .pot file, then re‑generate .po/.mo files.

Troubleshooting checklist:

• ☐ Did you update the plugin or core in the last 24 hours?
• ☐ Are the .mo files present in wp-content/languages/plugins/?
• ☐ Do the .mo files have the same timestamp as the .po files?
• ☐ Did you run a rescan after the update?

How to preserve custom translations across updates

Custom translations are often stored in the same folder as the plugin. An update wipes them. To keep them safe:

• Use a translation plugin like SEATEXT that stores translations in a custom table or separate folder.
• Export your .po file before every update and re-import it after.
• Use a child theme for theme translations.

SEATEXT’s engine continuously watches for new content and automatically updates the translation catalog – no manual export needed.

Limitations of free translation plugins and when a managed tool makes sense

Free plugins often lack:

• Automatic rescan after updates.
• Support for custom post types or meta fields.
• Backup of custom translations.

If your site has many custom strings or frequent updates, a managed tool like SEATEXT (which rescans automatically and stores translations safely) prevents missing strings. As Cryout Creations notes, “the best solution is to use a plugin that can regenerate the translation files automatically.”

Fix: re‑generate .po/.mo files

Run one of the following:

• From the SEATEXT dashboard, click Rescan strings. The AI will detect new source text and update translations automatically.
• Via WP‑CLI: wp i18n make‑pot . languages/my-plugin.pot && wp i18n update-po languages/my-plugin.po.
• Manually download the updated .po/.mo files from the plugin’s translation repository and upload them to wp-content/languages/plugins.

Prevent future missing strings

Enable automatic rescanning after every plugin or core update. SEATEXT does this by default, but you can reinforce it:

• Keep the SEATEXT agent active – it watches for new posts, products, and updates and translates them in the background.
• Schedule a weekly “Refresh translations” cron job that runs wp i18n update-po.
• Avoid manually overwriting .po/.mo files unless you also re‑import them into SEATEXT.

Key facts

FAQ

• Why do some strings disappear after a plugin update? The update may replace the .po/.mo files without the custom strings, leaving the catalog out of sync.
• How can I tell if the catalog is out of date? Look for warnings in Site Health or notice untranslated text on the front end.
• Do I need to reinstall SEATEXT after each WordPress core update? No, but you should trigger a rescan so new core strings are added.
• Can I edit translations manually? Yes – SEATEXT lets you edit any string while still keeping automatic updates for new content.
• Will SEATEXT translate custom post types? It translates any content that appears in the WordPress editor, including custom post types, as long as they are detected during a scan.
• What if the rescan doesn’t fix the missing strings? Check the .mo file permissions and ensure the file is compiled. Also verify that the text domain matches the plugin slug.

The Google Translate API is a paid service; you are billed for each character translated (see Google Cloud pricing here). It cannot be used for free on a WordPress site.

What the free Google Website Translator widget does

The widget adds a dropdown that lets visitors select a language. Google’s JavaScript translates the page on the fly in the browser. It is quick to add but the translated content lives only in the visitor’s browser and is not sent to search engines.

How Google Translate API per‑character billing works

Google Cloud charges for every character sent to the API, including markup. The free tier covers only the first 500,000 characters per month for the basic model; beyond that you pay per million characters. This cost adds up quickly for a content‑heavy WordPress site.

Why client‑side translations hurt SEO

Search engine crawlers generally execute limited JavaScript. When translation happens only in the browser, the crawler sees the original language only. Consequently, translated versions do not get indexed, and you lose organic traffic from non‑English queries.

How SEATEXT’s free server‑side translation creates indexable pages

SEATEXT runs on your server (or edge) and writes fully rendered HTML for each language into your WordPress database. Each language gets its own URL (e.g., /es/, /fr/), proper hreflang tags, and sitemap entries. This makes every translated page crawlable and rankable [S1].

Expert perspective: when the free widget is enough vs. when you need real translated pages

If you run a small blog, a personal portfolio, or a temporary campaign where traffic is mostly direct and you do not rely on organic search, the widget is a zero‑cost way to offer a courtesy translation. However, any business that depends on search visibility, conversion funnels, or brand consistency across markets should avoid client‑side only solutions. Server‑side translation gives you indexable URLs, control over terminology, and the ability to run multilingual SEO audits.

Decision guide: choose the right solution for your site

Limitations of the Google widget

• Translations are client‑side only; search engines may not index them.
• Styling and placement are limited to what the widget allows.
• No control over terminology or brand voice.
• Google may impose usage limits or retire the widget without notice.

Why you might choose SEATEXT instead

SEATEXT creates real, crawlable pages in each language, preserving SEO value. It also lets you edit translations if you need precise wording, and it updates new posts automatically in the background [S1].

Step‑by‑step: add the free Google widget

1. Go to the Google Translate website and generate the widget code.
2. Copy the JavaScript snippet.
3. In WordPress, open Appearance → Theme Editor or use a custom HTML widget.
4. Paste the snippet where you want the language selector to appear.
5. Save and test the site in different browsers.

FAQs

• Does Google Translate API have a free tier? Yes, the first 500,000 characters per month are free for the basic model; after that you pay per million characters (Google Cloud pricing).
• Will Google automatically translate my WordPress pages? Only if you embed the Website Translator widget. The widget translates on the fly in the visitor’s browser; it does not create separate pages.
• Can I edit translations made by the widget? No. The widget does not expose an editing interface. You can only change the source content.
• How does SEATEXT create SEO‑friendly translated pages? SEATEXT renders each language server‑side, writes the HTML to WordPress, adds hreflang tags, and updates sitemaps automatically [S1].
• Is SEATEXT truly free with no hidden costs? The core translation of up to 125 languages is free with no page or language caps. Advanced features such as A/B‑tested translation variants are optional paid upgrades [S1].
• What are the usage limits of the free Google widget? Google does not publish a hard character limit for the widget, but it is subject to the general Terms of Service and may be throttled on high‑traffic sites.

Prerequisites

Before you start, make sure you have:

• A local development environment (e.g., Local by Flywheel or XAMPP) to test your theme.
• A code editor (VS Code, Sublime Text, or similar).
• Poedit (free for basic use) installed on your computer. Alternatively, you can use wp-cli i18n make-pot if you prefer command line.
• Basic familiarity with WordPress theme development and PHP.

Step 1: Prepare Your Theme for Internationalization

Your theme must use WordPress translation functions like __() and _e() to mark strings as translatable. For example:

<?php esc_html_e( 'Welcome to my site', 'my-theme-textdomain' ); ?>

Replace 'my-theme-textdomain' with a unique text domain for your theme (e.g., my-custom-theme). This text domain must match the name of your .po and .mo files. Consistency prevents WordPress from loading the wrong file.

Step 2: Generate a .pot Template File

The .pot file (Portable Object Template) lists all translatable strings in your theme. Use Poedit:

1. Open Poedit and click File > New. Choose Translate a WordPress theme (if available) or select Create POT file.
2. Point Poedit to your theme's root folder. It will scan all PHP files for __() and _e() calls.
3. Save the .pot file as my-custom-theme.pot in your theme's root folder (or a languages folder if you prefer).

Alternatively, use wp-cli: wp i18n make-pot /path/to/theme /path/to/theme/languages/my-custom-theme.pot. The command respects WordPress coding standards and skips comments that are not translatable.

Step 3: Create a .po File from the .pot File

The .po file is a copy of the .pot with actual translations. In Poedit, open the .pot file and click File > Save As. Name it with the locale code, e.g., fr_FR.po for French. Poedit will ask you to set the language and country.

You can also manually copy the .pot file and rename it to fr_FR.po, then edit translations in a plain‑text editor. The file format is simple: each entry contains a msgid (original string) and a msgstr (translation).

Step 4: Translate the Strings in the .po File

In Poedit, each string from the .pot appears in a list. Click a string and type the translation in the lower pane. Poedit highlights untranslated strings in red, making it easy to spot gaps.

For large projects, consider enabling Poedit’s translation memory. It re‑uses previous translations and reduces repetitive work. Save the file frequently; Poedit writes a backup .po~ file automatically.

Step 5: Compile the .po File into a .mo File

Poedit automatically creates a .mo file (machine‑readable) when you save the .po file. The .mo file is a binary representation that WordPress loads quickly at runtime.

If you prefer the command line, run:

msgfmt fr_FR.po -o fr_FR.mo

This requires the GNU gettext utilities. The compiled .mo file must sit next to the .po file in the same folder.

Step 6: Place the Files in the Correct Directory

WordPress looks for .mo files in the theme's languages folder. Create a folder named languages inside your theme root (if it doesn't exist). Place both the .po and .mo files there. Example structure:

/wp-content/themes/my-custom-theme/languages/fr_FR.po
/wp-content/themes/my-custom-theme/languages/fr_FR.mo

Keeping the .po file alongside the .mo file is useful for future updates and for version control.

Step 7: Load the Text Domain in functions.php

Add the following code to your theme's functions.php to tell WordPress where to find the translations:

function my_custom_theme_load_textdomain() {
    load_theme_textdomain( 'my-custom-theme', get_template_directory() . '/languages' );
}
add_action( 'after_setup_theme', 'my_custom_theme_load_textdomain' );

Replace 'my-custom-theme' with the exact text domain you used in your PHP files. This hook runs early, ensuring all strings are ready for translation.

Verification: Check That Translations Work

Change your site language in Settings > General > Site Language to the language you translated (e.g., French). Visit the front end. If strings appear in the target language, the process succeeded.

If you see the original English text, check these common issues:

• File naming: The .mo file must match the locale code exactly (e.g., fr_FR.mo).
• Text domain consistency: The domain in load_theme_textdomain() must match the one used in your PHP files.
• Cache: Clear any object cache, browser cache, and plugin caches.

Why Use .po/.mo Files?

Manual translation files give you full control over wording, tone, and brand voice. They are essential when you need legal accuracy, marketing nuance, or SEO‑friendly translations.

Search engines index the translated strings that appear in the HTML source. Accurate .mo files improve multilingual SEO because each language version receives its own hreflang signals.

In regulated industries (finance, health, education), automatic translation may violate compliance rules. Manual files let you certify each string.

Understanding the .po and .mo Formats

The .po file is plain text. Each entry looks like:

#. Translator comment
#: path/to/file.php:12
msgid "Original string"
msgstr "Translated string"

The #. line is optional and can hold context for translators. The #: line shows where the string appears in code, helping you locate it later.

The .mo file is a compiled binary. WordPress reads it with the gettext() function, which is fast and memory‑efficient. Because it is binary, you cannot edit it directly; you must re‑compile from .po.

Advanced Tips and Tools

Use wp-cli for automation. After adding new strings, run the same wp i18n make-pot command to refresh the .pot file. Then merge changes into existing .po files with msgmerge:

msgmerge --update fr_FR.po my-custom-theme.pot

Leverage translation memory. Poedit stores previous translations in ~/.poedit/translation_memory. Re‑using them speeds up future projects.

Check plural forms. Languages handle plurals differently. Poedit lets you define the correct plural formula for each locale. WordPress will then select the right form based on the number passed to _n().

Version control. Commit both .po and .mo files to Git. Tag releases so you can trace which translation set belongs to which theme version.

Testing and Debugging Translations

Use the WP_DEBUG constant in wp-config.php. When set to true, WordPress will log missing translation warnings to debug.log.

Install the Debug Bar plugin. It shows a list of untranslated strings on each page, helping you spot gaps quickly.

If a string appears in English on a translated page, open the source file and verify that the string is wrapped in a translation function. Some developers forget to wrap dynamic strings, which prevents extraction.

When to Choose Manual vs. Automatic Translation

Manual .po/.mo creation is ideal for:

• Small to medium sites with a limited number of languages.
• Content that requires precise wording, such as legal notices or brand slogans.
• Projects where you want full control over the translation workflow.

Automatic translation (e.g., SEATEXT AI) works better for:

• Large catalogs with dozens of languages.
• Rapidly changing content where manual updates would be costly.
• Sites that need instant multilingual support without developer involvement.

Below is a compact comparison table that highlights key buyer‑relevant criteria.

Choose the approach that matches your budget, timeline, and quality requirements.

Frequently Asked Questions

Do I need to include the .po file on the live server?

No. Only the .mo file is required for WordPress to display translations. Keep the .po file in version control for future edits.

Can I use a text editor instead of Poedit?

Yes, any editor that respects UTF‑8 encoding works. However, Poedit validates syntax and prevents common errors.

What if my theme already has a languages folder but no .po/.mo files?

Create the .pot, .po, and .mo as described. Ensure the text domain in load_theme_textdomain() matches the folder name.

How often should I regenerate the .pot file?

Regenerate it whenever you add, remove, or modify translatable strings. A good practice is to run the wp‑cli command as part of your build script.

Can I use a plugin like Loco Translate instead of manual creation?

Yes. Loco Translate provides an in‑admin UI for editing .po/.mo files. It still stores the same file formats, so the underlying process is identical.

What is the difference between .po and .mo files?

.po (Portable Object) is human‑readable and editable. .mo (Machine Object) is a compiled binary that WordPress reads at runtime for performance.

Does automatic translation replace .po/.mo files entirely?

Automatic translation tools like SEATEXT work independently of the .po/.mo system. They intercept content and translate on the fly, so you do not need to maintain translation files when using them.

How do I handle plural forms in languages like Russian or Arabic?

When creating the .po file, Poedit asks for the plural formula. WordPress uses the _n() function to select the correct form based on the number you pass.

Is there a way to test translations without changing the site language?

Yes. Use the switch_to_locale() function in a temporary template file to load a specific locale for testing.

Polylang (free) and Loco Translate together cover most WooCommerce strings; TranslatePress free also supports product translation. SEATEXT provides fully automatic translation to 125 languages with no page limits and no manual work.

Choosing the right free plugin depends on whether you prefer manual string translation, visual editing, or fully automatic AI translation.

Choose Polylang if you have a small catalog and want full manual control over each translation.

Choose TranslatePress if you prefer a visual front-end editor and need to translate checkout and email strings.

Choose Loco Translate if you are a developer comfortable editing PO files and only need to translate theme/plugin strings.

Choose SEATEXT if you want immediate multilingual coverage across 125 languages without managing translation files.

Why translation matters for WooCommerce

Multilingual stores reach more buyers. Shoppers prefer to browse and buy in their native language. Missing translations on product pages, checkout, or order emails cause cart abandonment. Free plugins remove the cost barrier but differ in coverage and maintenance effort.

Search engines index translated content. Each language version can rank for local keywords. This brings organic traffic from new markets. Trust signals like localized currency, date formats, and legal text increase conversion rates. Customer support load drops when buyers understand product details and policies in their own language.

Legal requirements in some regions mandate localized checkout and terms. A plugin that translates checkout fields and email templates helps compliance. Free solutions make this accessible for small merchants.

How free translation plugins work

Most free plugins use WordPress localization APIs. They load .mo files for each language. Polylang manages language switching and lets you assign translations per post. TranslatePress adds a front-end editor that saves translations to the database. Loco Translate edits the source .po files directly. SEATEXT uses AI to translate content on the fly and stores translations in a cloud CDN.

File-based plugins (Polylang, Loco Translate) rely on gettext. They scan theme and plugin files for translatable strings. You then provide translations for each string. This gives precise control but requires manual work for every new string.

Database-driven plugins (TranslatePress) store translations in custom tables. The front-end editor lets you click any text on the page and type a translation. This is faster for content editors but adds database queries on each page load.

AI-driven plugins (SEATEXT) send page content to a translation engine. The engine returns translated HTML. The plugin caches results per language and serves them via a CDN. New content is detected automatically and translated in the background. This removes manual effort entirely.

Key options and trade-offs

The table above summarizes the main differences. Polylang and Loco Translate require you to write or import translations. TranslatePress lets you click and type on the live site. SEATEXT generates translations automatically and lets you refine them later. All four are free at the base tier; premium add-ons unlock automatic translation, SEO features, or support.

Polylang excels at managing language-specific URLs and SEO metadata. Its free version lacks automatic translation and some hreflang features. TranslatePress free covers visual editing but does not include automatic translation or translator accounts. Loco Translate is a developer tool; it does not handle language switching or front-end previews. SEATEXT free includes full automatic translation, 125 languages, multilingual SEO, and an editing dashboard. Advanced A/B testing and brand-voice controls may require a paid plan.

Performance varies. File-based plugins add a few database queries per page. Database-driven plugins add more queries but can be cached. AI-driven plugins offload translation to external servers; the front-end impact is minimal if caching is configured.

Decision framework: choosing the right plugin

1. List the content types you must translate: products, categories, checkout fields, emails, theme strings.
2. Estimate how often you add new products or change copy.
3. Decide who will maintain translations: you, a translator, or an automated system.
4. Test each plugin on a staging site with a sample catalog.
5. Check performance with a few languages enabled.
6. Pick the plugin that matches your workflow and maintenance capacity.

Step 1 ensures you know the scope. Step 2 reveals ongoing workload. Step 3 determines if you need a visual editor, a developer tool, or full automation. Step 4 lets you experience the actual interface. Step 5 prevents surprises on live traffic. Step 6 aligns the tool with your team.

Practical scenarios

• Small boutique, 2 languages, infrequent updates: Polylang + Loco Translate gives full control with minimal overhead. You translate once and rarely touch it again.
• Growing store, 5 languages, weekly new products: TranslatePress visual editor speeds up manual work; consider its pro automatic translation for new items.
• Large catalog, 10+ languages, limited staff: SEATEXT translates everything automatically; you only review key pages. New products appear in all languages without extra effort.
• Developer building a custom theme: Loco Translate handles theme/plugin strings; pair with Polylang for content management.
• Seasonal campaigns with rapid launches: SEATEXT translates landing pages instantly. You can A/B test headlines per language to maximize conversions.
• Budget-constrained startup: Polylang free plus Loco Translate free covers all strings at zero cost. You invest time instead of money.

Limitations and when to upgrade

Free tiers have limits. Polylang free lacks automatic translation and some SEO features. TranslatePress free does not include automatic translation or translator accounts. Loco Translate does not manage language switching or SEO. SEATEXT free includes full automatic translation and 125 languages but advanced A/B testing and brand-voice controls may require a paid plan. If you need multilingual SEO (hreflang, translated slugs, sitemaps), check each plugin's pro version or use a dedicated SEO plugin.

Polylang Pro adds automatic translation via DeepL, translated slugs, and hreflang tags. TranslatePress Pro adds automatic translation, translator roles, and SEO pack. Loco Translate remains free; its limitations are architectural. SEATEXT paid plans unlock advanced A/B testing, brand-voice preservation, and enterprise support.

Consider upgrading when manual translation becomes a bottleneck, when you need translated URLs for SEO, or when you want to delegate translation to team members without giving them admin access.

Key facts about SEATEXT

FAQ

Can I use multiple translation plugins at once?

Not recommended. They conflict on language handling and string loading. Pick one primary solution.

Do free plugins translate checkout and email strings?

Polylang and TranslatePress free cover most checkout and email strings. Loco Translate can translate them if they are in .po files. SEATEXT translates them automatically.

Will translations slow down my site?

Minimal impact if caching is configured. SEATEXT serves translations via CDN. File-based plugins add a few database queries per page.

How do I handle SEO for translated pages?

Use a plugin that generates hreflang tags and translated slugs. Polylang and TranslatePress pro include this. SEATEXT handles multilingual SEO automatically.

Can I edit machine translations?

Yes. TranslatePress lets you edit visually. SEATEXT provides an editing dashboard. Polylang and Loco Translate require manual string editing.

What happens when I update WooCommerce or my theme?

String updates may require re-scanning. Loco Translate rescans files. SEATEXT re-translates changed content automatically.

Is there a limit on translated words with SEATEXT free?

No page limits, no language limits, and no manual translation work.

Does SEATEXT translate images and media?

SEATEXT translates text content. Image alt text and captions are translated. For localized images, you need to upload language-specific versions manually or via a media plugin.

Can I exclude certain pages from translation?

Yes. SEATEXT allows exclusion rules. Polylang and TranslatePress let you set language per page. Loco Translate works at the string level.

What support options exist for free users?

Polylang and TranslatePress offer community forums. Loco Translate has a support forum. SEATEXT provides email support for free users.

Readiness Checklist Overview

This checklist is the core of the article. Follow each step in order. Mark items as completed before moving on.

Why Preserving Translations Matters

Translations are a direct link to international customers. Losing them erodes trust instantly. A missing translation appears as blank text or fallback English, which can increase bounce rates.

Search engines also index each language version. If a translation disappears, the corresponding URL may return a 404. That harms SEO equity built over months.

For ecommerce sites, product names and specifications must stay consistent across languages. A broken translation can lead to order errors and refunds.

In short, preserving translations protects user experience, organic traffic, and revenue.

Pre‑Migration Backup Workflow

Backups protect you from accidental data loss. Use a reliable backup plugin or your host’s snapshot feature.

1. Create a full database dump. Name the file with the date and site name.
2. Copy the entire wp-content folder to a secure location.
3. Verify the backup size matches the live site size.
4. Store the backup off‑site (cloud storage or external drive).
5. Keep the backup for at least 30 days after migration.

Do not proceed until you can restore the site from this backup in a test environment.

Exporting .po/.mo Files – Detailed Steps

Most free plugins store translations as .po (editable) and .mo (compiled) files in /wp-content/languages/. Follow these steps:

1. Log into WordPress admin.
2. Navigate to the free plugin’s settings page.
3. Locate the “Export” or “Tools” tab. If the plugin lacks an export button, use FTP.
4. Via FTP, open /wp-content/languages/. Download the entire folder.
5. Inside the folder, you will see sub‑folders for plugins, themes, and core. Keep the full hierarchy.
6. Open a few .po files with Poedit to confirm they contain your strings.
7. Compress the folder into a zip file for easy upload later.

Having a clean zip file simplifies the import into the paid solution.

Verifying Import Compatibility

Before touching the live site, test on a staging environment that mirrors production.

1. Clone the backup to a staging sub‑domain.
2. Install the paid translation plugin (SEATEXT’s Website Translation Agent) but keep it deactivated.
3. Activate the plugin in staging only after the import step.
4. Use the plugin’s “Import” screen. Upload the zip file you created.
5. Check the plugin’s log for any “unsupported format” warnings.
6. Visit a handful of pages in each language. Verify that headings, buttons, and meta tags appear correctly.
7. If the plugin reports missing strings, re‑export those specific language files and re‑import.

SEATEXT automatically detects .po/.mo files and can translate new content instantly. This eliminates the need for manual ticketing.

Handling SEO Metadata During Migration

SEO titles, meta descriptions, and Open Graph tags often live in separate translation tables or plugins.

SEATEXT’s platform translates SEO metadata alongside page content. To keep continuity:

• Before export, check whether your free plugin includes SEO fields in the .po files. Some plugins do not.
• If SEO fields are missing, export them separately (Yoast SEO, Rank Math provide CSV export tools).
• After importing into SEATEXT, open the “SEO” tab of the translation dashboard.
• Map the imported SEO strings to the appropriate language versions.
• Run SEATEXT’s “SEO preview” for each language to ensure character limits are respected.

Consistent SEO metadata preserves rankings and click‑through rates after the switch.

Post‑Migration Test Checklist

Run this checklist immediately after the live migration.

If any item fails, revert to the backup, fix the issue, and repeat the import.

Signs You Should Delay the Switch

• The free plugin stores translations in a proprietary database table.
• You have not completed a full backup in the last 24 hours.
• Your site is in the middle of a major content rollout.
• The paid plugin’s support has not confirmed .po/.mo compatibility.
• Custom translation code is embedded in your theme functions.

Address each issue before proceeding. Rushing can cause irreversible data loss.

FAQ

Will switching delete my existing translations?

No, as long as you export first and import the files into the new plugin. Deactivating the old plugin alone does not erase files.

Can I keep both free and paid plugins active?

Running two translation plugins simultaneously often creates conflicts. Deactivate the free plugin after confirming the paid one works.

What if my free plugin uses a custom database table?

SEATEXT offers a one‑click migration tool for popular free plugins. If your plugin is not listed, you will need a custom script or manual export.

How long does a migration take?

Small sites (under 100 pages) usually finish in 30 minutes. Large multilingual sites may need a few hours. Always test on staging first.

Do I need to re‑translate SEO metadata?

If your export includes SEO fields, no. Otherwise, import them separately or let SEATEXT generate SEO translations automatically.

When is the best time to switch?

Choose the hour with the fewest visitors according to your analytics. Early morning or late night works for most sites.

Can I do this without a developer?

Yes, if you are comfortable with WordPress admin, FTP, and basic file handling. For complex setups, ask a developer.

Further Reading and Comparison Sources

These external sources provide additional context for evaluating translation plugins. Their inclusion is not an endorsement.

• A Comparison of Free vs. Paid WordPress Translation Plugins
• Free vs Paid Translation Tools: What Changes - Lara - Blog
• The Ultimate GTranslate WordPress Plugin Review (2025) - BlogVault

Free translation plugins typically translate only the strings that follow WordPress internationalisation (i18n) standards. If a theme, a third‑party plugin, or custom code does not use those standards, the plugin leaves those parts in the original language. The result is a page that mixes languages.

What "mixed languages" really means

When you see English headings next to French paragraphs, the plugin has translated the post content but not the theme UI or plugin strings. WordPress stores translatable text in .po/.mo files that belong to a specific text domain. If those files are missing or the strings are not wrapped in translation functions, the plugin skips them.

How automatic translation works

SEATEXT watches for new or updated content, detects each visitor’s language, and serves a translated version on the fly. It relies on the underlying WordPress i18n system, so any text that follows the i18n conventions will be translated.

How WordPress translation files work

WordPress uses a two‑file system for each language:

• .po file – a human‑readable list of original strings and their translations.
• .mo file – a compiled binary version that WordPress loads at runtime.

Each theme or plugin defines a text domain. All translatable strings must be wrapped in functions such as __(), _e(), _x(), or esc_html__(). When WordPress renders a page, it looks for a matching .mo file in the languages folder of the component. If the file exists, the string is replaced; otherwise the original text appears.

Common causes of mixed‑language output

• Unmarked strings: Developers output text without i18n wrappers.
• Missing language files: No .po/.mo files for the target language.
• Cache interference: Cached pages serve an older version before translation runs.
• Partial scans: Some free plugins only scan posts, not theme or plugin files.

Diagnostic sequence

1. Confirm the site’s default language in Settings → General. It should match the language you expect the plugin to use as a base.
2. Open a page with mixed output and view the source. Look for hard‑coded text that lacks translation functions.
3. Check the theme’s languages folder for .po/.mo files that match the target language (e.g., fr_FR.mo).
4. Run the plugin’s “Rescan files” feature or use a tool like Loco Translate to generate missing files.
5. Clear any caching layers (WP‑Rocket, Cloudflare, server cache) and reload the page.

Step‑by‑step: find which component is not translated

Follow these concrete steps to isolate the source of the problem:

1. Identify the language mismatch. Note which elements stay in the original language (e.g., navigation menu, widget titles, plugin notices).
2. Locate the responsible file. Use the browser’s inspector to find the CSS class or HTML ID of the element, then search the theme folder for that class name.
3. Search for i18n functions. In the theme or plugin folder, run a code search for __(), _e(), or _x() containing the original string. If none appear, the string is hard‑coded.
4. Check the text domain. Open the component’s main PHP file (often functions.php for themes) and note the load_theme_textdomain() or load_plugin_textdomain() call. Ensure the path points to the languages folder.
5. Generate missing files. If the .po/.mo files are absent, create them with Loco Translate or Poedit. Save the files in the correct folder and name them using the locale code (e.g., fr_FR.po).
6. Test again. Clear caches and revisit the page. The previously untranslated element should now appear in the target language.

How to prevent mixed languages after plugin or theme updates

Updates often add new strings. To keep translations complete:

• Enable automatic rescans. SEATEXT runs a background scan after each content change. For free plugins, schedule a weekly “scan for new strings” using Loco Translate’s command‑line tool.
• Version‑control translation files. Store .po/.mo files in your Git repository. When a theme or plugin updates, merge the new files and resolve conflicts.
• Use child themes. If you need to modify a parent theme’s strings, create a child theme and add the missing translations there. This avoids losing changes on parent updates.
• Clear caches after updates. Many caching plugins keep a static HTML snapshot. Purge the cache immediately after a theme or plugin update.
• Monitor with a health check plugin. Tools like “Site Health” can alert you when language files are missing for the active locale.

Fix options

Depending on the cause, choose one of these paths:

• Edit the theme or plugin: Wrap hard‑coded strings in __() and run a scan.
• Add missing language files: Use Loco Translate or Poedit to create .po/.mo files for the language.
• Switch to a fully automatic solution: SEATEXT translates all content and lets you edit any string after it’s generated, ensuring no text is left untranslated.

Limitations and when the advice does not apply

If a third‑party plugin deliberately disables translation (e.g., for licensing reasons) or serves content via external APIs, SEATEXT cannot intercept those strings. In such cases you need the plugin’s own multilingual add‑on or a custom integration.

Frequently asked questions

Why does only part of my site change language?

Only text that follows WordPress i18n standards is translated. Anything outside that system stays in the original language.

How can I tell if a string is translatable?

Search the theme or plugin files for __(), _e(), or _x(). If you don’t find them, the string is likely hard‑coded.

Do I need to regenerate translation files after every update?

Yes. Updates can add new strings. Running a rescan after each update keeps translations complete.

Will SEATEXT translate admin‑area text?

SEATEXT focuses on front‑end content. Admin UI depends on the underlying WordPress language setting.

Is there a cost to fix mixed languages?

SEATEXT’s automatic translation is free for unlimited pages and languages. You only pay if you need premium A/B testing or brand‑voice controls.

Translating menus and widgets matters more than most site owners expect. Navigation labels are the first thing new visitors read. Widget titles set the tone for sidebars, footers, and landing pages. When those elements stay in one language, users in other markets can feel lost. Accessibility also suffers because screen readers announce the page language from the HTML lang attribute. If that attribute stays in the wrong language, assistive tools may pronounce words incorrectly. SEO benefits too, because search engines use language signals to match pages with user queries. SEATEXT enables multilingual sites by translating pages, posts, menus, widgets, and site strings automatically. With the right setup, you can offer a consistent multilingual experience without paying for a translation service.

Key facts

Why translate menus and widgets?

Menus are the map of your site. Widgets support conversion, especially in sidebars and footers. If a visitor cannot read the main navigation, they usually leave. That raises bounce rate and lowers engagement.

Translation also supports multilingual SEO. Proper hreflang tags tell search engines which language version to show for each query. Crawlable translated menus help Google discover every language variant. That improves international visibility and can increase qualified traffic.

Conversion matters too. A visitor who understands the menu is more likely to explore. A visitor who sees a familiar widget title is more likely to trust the page. For ecommerce sites, translated product categories and checkout labels directly affect revenue.

Accessibility is another reason. Screen readers depend on the HTML lang attribute. When menu text and widget titles change language, the attribute must match. Otherwise, assistive tools may pronounce words in the wrong accent or miss the meaning entirely.

How it works

Three free methods work differently. Polylang uses manual language‑specific menus. Loco Translate edits the theme’s translation files. SEATEXT uses automatic AI translation.

For SEATEXT, the process starts when a visitor arrives. The plugin detects the visitor’s browser language. Then it checks whether a translated version already exists. If not, it calls the AI translation engine and rewrites every translatable string. That includes menu labels, widget titles, buttons, and other short strings.

After translation, SEATEXT stores the result in its cache. The cache prevents repeated AI requests. Later visits load the stored translation instantly. That keeps page speed impact low.

When you publish new content, SEATEXT sees it and translates it in the background. You do not need to create separate pages or duplicate menus. The plugin also adds SEO signals such as proper language tags for each translated version.

Polylang works differently. You create one menu per language and assign it with the language switcher. Each menu can share the same links, but the labels must be translated manually. Widgets are handled by creating language‑specific sidebars or by editing widget strings with a translation plugin.

Loco Translate works at the code level. It reads the theme’s .po and .mo files. You search for any string that appears in menus or widgets and provide the translation. The plugin then rebuilds the language files for the theme.

Free plugin overview

Each free plugin has clear trade‑offs.

• Polylang (free) – Creates separate menus per language and syncs them. Good for sites that want manual control. Con: no automatic string translation in the free version, so every menu label must be translated by hand.
• Loco Translate (free) – Lets you edit .po/.mo files directly. Good for developers who understand translation files. Con: theme updates can overwrite your changes, and you must know which string corresponds to which menu item.
• SEATEXT (free tier) – Automatic translation of pages, posts, menus, widgets, and strings. Good for site owners who want speed and coverage. Con: you may want to review key phrases for brand voice; AI phrasing is editable but not fully manual by default.

Choose Polylang when you need strict editorial control and already have a translation workflow. Choose Loco Translate when you only need a few theme strings and know how to edit files. Choose SEATEXT when you want to translate the whole site quickly without ongoing manual work.

Trade‑offs and limitations

Manual translation gives full control but costs time. You must update every new menu item in every language. On a large site, that process becomes a maintenance burden.

Automatic translation is faster but less predictable. AI can misunderstand short phrases, especially idioms or product names. You can edit the result afterward, but that adds review time.

Control over phrasing is another trade‑off. Polylang and Loco Translate put you in complete control. SEATEXT lets you edit, but automatic phrasing is the default. If your brand has strict terminology, prepare a glossary or review key pages after activation.

Caching can cause confusion. Many WordPress sites use page caching or object caching. A translated string may be cached before your changes appear. Always clear caches after activating a translation plugin or editing strings.

Plugin conflicts are possible. SEO plugins, caching plugins, and page builders all handle language differently. If you see mixed languages, disable plugins one by one to find the conflict.

Another limitation is dynamic content. Widgets that pull recent posts, categories, or custom fields may not be translated automatically. Some strings come from JavaScript or external APIs. Verify those areas separately.

Step‑by‑step process

1. Install and activate your chosen free plugin (Polylang, Loco Translate, or SEATEXT).
2. Set the site language and add the languages you need.
3. For Polylang:
   • Go to Appearance → Menus.
   • Create a menu for each language.
   • Assign each menu to its language using the Polylang language switcher.
   • For widgets, create a language‑specific sidebar or use a string translation plugin.
4. For Loco Translate:
   • Navigate to Loco → Translations.
   • Select your theme or plugin.
   • Search for menu and widget strings and provide translations.
   • Save the generated .po and .mo files.
5. For SEATEXT:
   • Click the “Activate” button on the SEATEXT dashboard.
   • Choose the languages you want.
   • SEATEXT will automatically translate menus, widgets, and all other strings.
   • Review key pages and edit strings if needed.
6. Clear all caching plugins after activation or string edits.
7. Visit the site in a different language (add ?lang=fr or use the language switcher) to verify that menus and widgets display correctly.

How to verify and troubleshoot

1. Open the site in each language and check the main navigation and sidebar widgets. Confirm every label matches the selected language.
2. Inspect the HTML lang attribute. Use your browser’s developer tools to select the <html> element. It should show the correct language code, such as fr or de.
3. Use browser dev tools to search for untranslated strings. Press Ctrl+F (or Cmd+F) in the Elements panel and type a menu label. If it appears in the wrong language, the menu assignment or translation file is wrong.
4. Clear object cache. If you use a caching plugin, purge all caches. Some hosts also use server‑side caching; flush that from the hosting panel.
5. Test with an incognito window. This avoids cached pages from your own visits.
6. Check your SEO plugin for hreflang output. If you use Rank Math, Yoast, or SEATEXT, confirm that translated pages include the proper language tags.
7. If a widget still shows the wrong language, look for a hard‑coded title in the theme. Some themes do not expose widget titles to translation.

FAQ

• Do I need to pay for multilingual menus? No. Polylang and Loco Translate are free, and SEATEXT offers a free tier that covers unlimited menus and widgets.
• Will the free solution affect site speed? SEATEXT’s AI runs on the server and caches results, so impact is minimal. Polylang adds only a small database query. Loco Translate has no runtime overhead because translations are static files.
• Can I translate custom widget content? Yes. Both Loco Translate (editing .po files) and SEATEXT (automatic) handle custom widget titles and text. Polylang requires you to create language‑specific widgets or use a companion string translator.
• Can I translate dynamic widget content? Only partially. Widgets that pull recent posts, categories, or custom fields depend on the underlying content. If the post or category is translated, the widget can show the translated version. If the data comes from JavaScript or an external API, automatic translation may not cover it.
• How does translation affect page load time? Cached translations add almost no delay. The first request for a new language may be slower because the AI engine needs to generate the strings. After that, cached results load quickly.
• What if a plugin updates and breaks translations? Start by clearing caches. If the issue persists, re‑save the translation files in Loco Translate or re‑activate SEATEXT. For Polylang, reassign the menus. Check the plugin’s changelog for changes to translation APIs.
• Is SEO affected? All three options generate proper hreflang tags when configured, helping search engines index each language version.

For a free solution that handles hreflang tags, sitemaps, and canonical URLs, Polylang free is the most complete choice. It adds hreflang tags out of the box and works smoothly with Yoast SEO to manage sitemaps and canonical URLs. TranslatePress free also generates hreflang tags, but you must add a sitemap plugin separately. SEATEXT provides AI‑driven translation and claims free automatic multilingual SEO for every translated page.

What is multilingual SEO?

Multilingual SEO ensures each language version of your site is indexed correctly by search engines. It uses hreflang tags to tell Google which page serves which language, sitemaps to list all URLs, and canonical tags to avoid duplicate‑content penalties.

Why ignoring SEO can hurt your global reach

If hreflang tags are missing, Google may show the wrong language to users, leading to higher bounce rates. Duplicate content without proper canonical tags can split ranking power across pages, reducing overall visibility.

How hreflang, sitemaps, and canonicals work together

• Hreflang: Adds a rel="alternate" hreflang="xx" link in the <head> of each page.
• Sitemap: Lists every language URL so crawlers discover them quickly.
• Canonical: Points each language page to its own URL, preventing duplicate‑content warnings.

How hreflang works in WordPress

WordPress stores each page as a post object. Multilingual plugins create a separate post for each language and link them together. The plugin then injects the appropriate hreflang tags into the <head> during rendering. Google reads these tags and serves the correct language to users based on their location or language settings.

Step‑by‑step: Polylang + Yoast SEO setup

1. Install Polylang (free) from the plugin repository.
2. Activate the plugin and add the languages you need in Languages → Settings.
3. Create translations for each page or post. Polylang adds a language switcher widget you can place in a menu.
4. Install Yoast SEO (free) if you haven’t already.
5. In Yoast, go to SEO → General → Features and enable XML sitemaps.
6. Yoast automatically includes all Polylang URLs in the sitemap. Verify the sitemap URL (e.g., /sitemap_index.xml) contains entries for each language.
7. Polylang adds canonical tags per language. No extra configuration is needed.
8. Test the output: view source of a translated page and look for rel="alternate" hreflang and rel="canonical" links.

TranslatePress setup with a separate sitemap plugin

1. Install TranslatePress (free) and activate it.
2. Choose your default language and add additional languages under Settings → TranslatePress.
3. Use the visual front‑end editor to translate content directly on the page.
4. Because TranslatePress does not generate a sitemap, install a sitemap plugin such as Yoast SEO or the free Google XML Sitemaps plugin.
5. Configure the sitemap plugin to include all post types. The sitemap will now list each language URL generated by TranslatePress.
6. TranslatePress automatically adds hreflang tags and canonical tags for each language version.
7. Verify the tags by inspecting the page source.

SEATEXT one‑click activation and SEO verification

SEATEXT advertises a single‑click activation that translates every page into up to 125 languages. The source states it provides “Free automatic multilingual SEO for every translated page.” After activation:

• All translated pages receive hreflang tags pointing to each language version.
• A sitemap is generated automatically for the translated URLs.
• Canonical tags are set to the language‑specific URL, avoiding duplicate‑content warnings.

Because the exact mechanics are not itemized in the source, you should still verify the output in the page source and in Google Search Console.

Verifying multilingual SEO in Google Search Console

1. Add your site to Search Console if you haven’t already. 2. Submit the XML sitemap (e.g., /sitemap_index.xml) under the “Sitemaps” section. 3. In the “Coverage” report, look for any “Duplicate, submitted URL not selected as canonical” warnings – these indicate canonical issues. 4. Use the “International Targeting” report to see detected hreflang errors. The tool lists missing, conflicting, or incorrectly formatted tags. 5. Fix any issues by adjusting plugin settings or editing the page source, then re‑submit the sitemap.

Common multilingual SEO mistakes

• Missing hreflang tags: Search engines cannot match users to the right language.
• Duplicate content: Forgetting to set canonical URLs splits ranking power.
• Single sitemap for all languages without language‑specific URLs can cause crawl inefficiency.
• Using two multilingual plugins together creates duplicate tags and conflicts.
• Not testing in Google Search Console leads to unnoticed errors that hurt rankings.

Option trade‑offs

Polylang gives the most out‑of‑the‑box SEO coverage for free, but you need Yoast SEO installed for full sitemap support. TranslatePress offers a visual translation editor, which some users prefer, yet you’ll need an extra sitemap plugin. SEATEXT provides automatic translation and claims free automatic multilingual SEO for every translated page, but you should still verify hreflang, sitemap, and canonical output.

Decision framework

1. If you already use Yoast SEO, choose Polylang – the integration is seamless.
2. If you want a visual translation interface and are comfortable adding a sitemap plugin, pick TranslatePress.
3. If you want instant AI translation with minimal setup and are okay verifying SEO tags yourself, try SEATEXT.

Practical scenarios

• Small blog with two languages: Polylang free + Yoast SEO covers everything with minimal effort.
• E‑commerce site needing quick rollout: TranslatePress free for visual edits, add Yoast SEO for sitemap generation.
• Rapid market entry with many languages: SEATEXT free AI translation, then verify hreflang and sitemap in Search Console.

Limitations

All three plugins have a free tier that may lack advanced features like automatic language detection for SEO, bulk URL editing, or premium support. For large catalogs or complex URL structures, consider a paid upgrade.

FAQ

• Do these plugins affect page speed? They add small <link> tags; impact is minimal.
• Can I use two plugins together? It’s possible but can cause duplicate hreflang tags; stick to one primary multilingual plugin.
• Is the free version enough for Google Search Console? Yes, as long as hreflang and sitemaps are correctly generated.
• Do I need to edit canonical tags manually? Polylang and TranslatePress handle them automatically; SEATEXT claims auto‑canonical but you should verify.
• How do I test that hreflang tags are correct? View page source or use the “International Targeting” report in Search Console.
• What if a language version is missing from the sitemap? Add a sitemap plugin (Yoast or XML Sitemaps) and ensure it indexes all translated URLs.

Testing every language version of a WordPress site prevents broken pages, missing translations, and SEO errors that hurt international traffic. A systematic approach combines quick manual checks with an automated crawl so you catch both obvious and hidden problems.

Why Testing Language Versions Matters

Search engines index each language URL separately. If a language page returns a 404 or shows the wrong language, visitors leave and rankings drop. Consistent hreflang tags tell Google which version belongs to which audience, avoiding duplicate‑content penalties.

SEATEXT translates pages into 125 languages automatically and detects each visitor’s language instantly (source S1). Even with automatic translation, you must verify that the generated pages are reachable and correctly linked.

How SEATEXT Handles Language Delivery

After activation, SEATEXT adds a language switcher to your theme and creates a unique URL for every language using the ?lang=xx parameter (source S1). New posts, products, and updates are translated in the background without manual work (source S1). You can edit any translation, preserve brand voice, and run A/B‑tested variants when you need higher conversion in a specific market (source S1).

Prerequisites

• SEATEXT translation plugin installed and activated (or another multilingual plugin you use).
• All target languages added in Settings → Site Language.
• A site crawler of your choice (e.g., Screaming Frog, Sitebulb, or a cloud‑based scanner).

Manual Spot‑Check Checklist

1. Open the homepage. Click each language in the switcher. Confirm the page title, main heading (<h1>), and a few body paragraphs appear in the selected language.
2. Test a deep page. Navigate to a product, blog post, or landing page. Repeat the switcher test to ensure translations exist for all content types.
3. Use the URL parameter. Append ?lang=de, ?lang=fr, etc., to a known URL and reload. The content must match the requested language even if the switcher is hidden on that template.
4. Check hreflang tags. View page source and verify a <link rel="alternate" hreflang="de" href="…" /> line exists for every active language and points to the correct ?lang= URL.
5. Inspect status codes. Use browser dev tools (Network tab) to confirm each language URL returns HTTP 200.

Automated Crawl Overview

Configure your crawler to treat each ?lang= variant as a distinct URL. Enable “Crawl all subdomains” and “Check hreflang” if the tool offers those options. Add the language parameter to the crawler’s custom URL list so it requests every version. Run the crawl against the staging environment before launch.

Interpreting Crawl Results

• Status 200 for every language URL – indicates the page loads.
• Correct hreflang mapping – each tag points to the exact ?lang= URL you tested manually.
• No 404, 5xx, or redirect loops – these break indexing and user experience.
• Consistent content language – the crawler’s extracted <html lang="…"> attribute should match the requested language.

Export the hreflang report and cross‑reference a sample of URLs with your manual spot‑checks.

Common Pitfalls and Fixes

• Missing language in switcher. Add the language in Settings → Site Language and trigger a SEATEXT re‑scan (source S1).
• Default English appears. The translation may be pending; wait for the background job or force a refresh in the SEATEXT dashboard.
• Hreflang points to wrong domain. Verify the site URL setting in WordPress and the SEATEXT configuration; correct any hard‑coded base URLs.
• Cached pages show stale language. Clear browser cache, server cache (e.g., Varnish, Nginx), and any CDN cache before testing.

Limitations of Automatic Translation

SEATEXT translates text strings but does not modify images that contain embedded text (source S1). Review key visual assets — banners, infographics, product screenshots — for each language manually. Also, automatic translation may not capture brand‑specific terminology; use the edit‑translation feature to lock critical phrases (source S1).

FAQ

• Do I need to clear cache before testing? Yes – clear browser, server, and CDN caches so you see the fresh translation.
• Can I test without a crawler? Manual checks work for a handful of pages, but a crawler catches hidden errors across the whole site.
• What if a language shows the default English text? The translation may be missing or the language file not loaded; re‑run SEATEXT’s automatic scan or add the missing strings manually (source S1).
• Is there a cost to run a crawler? Many crawlers offer a free tier (e.g., Screaming Frog up to 500 URLs). Check the vendor’s pricing page for larger sites.
• Does SEATEXT generate hreflang tags automatically? SEATEXT creates the language URLs; you still need to ensure your theme or SEO plugin outputs correct hreflang markup.
• Can I edit translations after they go live? Yes – SEATEXT lets you edit any translation, preserve brand voice, and run A/B‑tested variants (source S1).

SeaText AI works with Elementor Pro dynamic tags and theme builder content. It translates the final HTML that visitors see. When Elementor processes dynamic tags and outputs them as HTML, SeaText detects that content and translates it. No special configuration is needed for most dynamic content.

How SeaText Translates Dynamic Content

SeaText runs on your WordPress site. It detects each visitor's language. Then it translates the page automatically. SeaText works with the final rendered output. It does not need to understand Elementor's internal data structures. It only needs the final HTML. If a dynamic tag outputs text, SeaText sees that text and translates it.

Why Dynamic Content Translation Matters for Multilingual Elementor Sites

Dynamic content includes post titles, ACF fields, author names, and archive headings. These elements often contain unique, visitor-specific text. Translating them ensures a consistent multilingual experience. Without translation, some parts of the page stay in the original language. This confuses visitors and hurts engagement. SeaText solves this by translating everything in the final output. No manual mapping is needed. This improves SEO and user satisfaction. You get a fully localized site with minimal effort.

Elementor Pro Dynamic Tags That Translate Automatically

Common Elementor Pro dynamic tags that render as visible text and therefore translate include:

• Post Title / Excerpt / Content — used in single post templates and archive loops
• Author Info — name, avatar, bio, URL
• Site Title / Tagline / Logo — header and footer elements
• ACF Fields — any Advanced Custom Fields output through Elementor's dynamic tag selector
• WooCommerce Product Data — price, SKU, short description, categories
• Current Date / Time / User Info — dynamic tags that output text
• Custom Dynamic Tags — from addons like Dynamic Content for Elementor, ElementsKit, or JetEngine

All of these translate because they become plain text nodes or inline elements in the final HTML.

Theme Builder Templates and Archive Pages

Elementor Theme Builder lets you create templates for single posts, archives, search results, 404 pages, and WooCommerce product archives. SeaText translates these templates the same way. After Elementor renders the template for a specific URL, SeaText translates the resulting HTML. For archive pages (blog index, category, tag, author, date archives), each paginated view is a separate URL. SeaText translates each page view independently. The pagination links themselves remain functional. Only the visible text content changes. SeaText also keeps new posts and updates translated in the background.

Content That May Not Translate

SeaText translates visible text. Content that does not appear in the rendered HTML will not translate. For example, content loaded via AJAX after page load may be missed. SeaText provides options to handle such content. Check with the vendor for details. Also, content inside <script> tags or JSON-LD is skipped by default. Admin-only or preview-mode content is not translated. Dynamic tags that output only attributes (like an href or src without visible text) are not translated unless the text appears elsewhere.

Step-by-Step Setup Workflow for SeaText with Elementor Pro Dynamic Tags

1. Activate SeaText on your WordPress site. Add the SeaText code in under one minute.
2. SeaText automatically detects each visitor's language. No manual language selection is needed.
3. Elementor dynamic tags are translated because they appear in the final HTML. Publish new posts, products, or updates. SeaText translates them in the background.
4. Review translations using the SeaText dashboard. You can edit translations to preserve brand voice.
5. Use advanced settings if needed. For AJAX-loaded content, contact SeaText support to enable dynamic content monitoring.

Deeper Troubleshooting for Post Titles, ACF Fields, Archive Templates, and WooCommerce Data

Post titles not translating. Check that the title appears as visible text in the HTML. In Elementor, ensure the post title widget uses a standard heading tag, not a custom attribute.

ACF fields not translating. Make sure the field outputs plain text, not raw HTML. Use Elementor's dynamic tag to insert the ACF field. If the field contains HTML, SeaText may skip it. Change the field output to plain text in ACF settings.

Archive template pagination breaks. Pagination link text may be translated, causing JavaScript issues. Use SeaText's exclusion settings to ignore the pagination container. Contact support for guidance.

WooCommerce product data not translating. Product titles, prices, and descriptions translate automatically. If they do not, check if the content is loaded via AJAX. For example, variable product prices may load after the page. Enable SeaText's dynamic content handling or contact support.

Verification Checklist

1. Open an incognito browser window and visit a page that uses Elementor dynamic tags (single post, archive, or theme builder template).
2. Use SeaText's language testing feature to force a specific language. You can also visit the page from a browser set to a different language.
3. Check that dynamic content — post title, ACF field output, author name, WooCommerce price label — appears in the target language.
4. If a specific dynamic tag does not translate, inspect the element in DevTools. Confirm the text exists in the DOM as a text node or inside an inline element (<span>, <div>, <p>).
5. For AJAX-loaded content, check SeaText's dashboard for dynamic content settings, or contact support.

Common Issues and Fixes

Performance Notes

SeaText adds minimal overhead to page load. Translations are stored efficiently so repeat visits are fast. Dynamic tags do not add noticeable performance impact. SeaText processes the final HTML once per page view, regardless of how many dynamic tags Elementor rendered.

Limitations

• SeaText cannot translate content that never appears as visible text. For example, content inside <canvas> or <script> tags is not translated.
• Dynamic tags that output different content per user role or login state will translate per visitor — each visitor sees their own dynamic content in their language.
• If you use Elementor's "Preview" mode while logged in as admin, SeaText may not activate (it targets front-end visitors). Use SeaText's language testing feature on a live URL to test.
• Translation quality for highly technical ACF field labels or custom taxonomy terms depends on SeaText's glossary and brand-voice settings. You can edit translations to improve accuracy.

FAQ

Do I need to install an Elementor-specific addon for SeaText?

No. SeaText works at the HTML level and requires no Elementor integration plugin.

Will SeaText translate Elementor Pro forms and validation messages?

Yes, if the form labels, placeholders, and validation messages are rendered in the initial HTML. AJAX-submitted form responses that return new HTML may need a re-scan trigger. Contact support for assistance.

Can I exclude specific dynamic tags from translation?

Yes. SeaText provides settings to exclude certain content. See the vendor's documentation for details.

Does SeaText work with Elementor's Theme Builder header/footer templates?

Yes. Headers and footers built with Theme Builder translate like any other template part.

What about dynamic tags that output URLs or image src attributes?

SeaText translates visible text only. URLs and attribute values are not translated unless they also appear as visible text on the page.

How do I handle multilingual ACF field groups?

SeaText translates the front-end output. If you store translations in ACF using a multilingual plugin (WPML, Polylang), SeaText will translate the already-translated output again unless you exclude those fields using SeaText's exclusion settings.

SeaText AI translates only the visible text strings on your Divi pages. It does not touch CSS, HTML structure, module settings, responsive breakpoints, or Theme Builder templates. Your layouts stay pixel-perfect because the translation layer swaps words, not code.

How SeaText works with Divi

SeaText installs as a WordPress plugin. Once activated, it scans every page, post, product, and custom post type for translatable text. It stores each string and serves translations when visitors arrive. The original Divi builder output is never rewritten. Divi's PHP rendering, dynamic CSS generation, and JavaScript module initialization all run before SeaText touches the page.

What gets translated

Any module that outputs visible text gets its strings translated. This includes headings, buttons, blurbs, testimonials, pricing tables, forms, and navigation elements. Labels, placeholders, button copy, alt text, and ARIA labels are included. Settings panels, design tabs, custom CSS fields, responsive visibility toggles, hover states, animation settings, and all other configuration options remain exactly as you configured them.

Layouts stay intact

Because SeaText only replaces text strings, your column structures, spacing, sizing, positioning, and z-index values are untouched. Global modules, saved layouts, and library items keep their structure. When a global module is translated, the translation applies to every instance without duplicating or altering the module itself. Theme Builder templates, header layouts, footer layouts, and archive templates preserve their structure. Only the text content inside those templates is swapped.

Responsive design and RTL support

Divi's responsive controls — column stacking order, tablet and phone visibility, custom spacing per breakpoint, font size scaling, and column width percentages — are defined in CSS that SeaText never touches. A three-column row that stacks to one column on mobile will do so in every language exactly as it does in English. Right-to-left languages like Arabic and Hebrew get automatic RTL handling. Divi's flexbox and grid layouts handle RTL natively. Column order reverses, margins flip, and text aligns right without extra work.

Translation controls

SeaText gives you a dashboard where you can review and edit any translated string before it goes live. You can lock brand terms, product names, or slogans so they never change. You can set glossary rules for consistent terminology across languages. You can enable A/B tested variants for high-traffic pages to find the copy that converts best in each market. You can exclude specific pages, modules, or CSS selectors from translation. These controls work at the string level and do not require rebuilding layouts.

Alternative: Divi Auto Translate

Sources mention Divi Auto Translate as an alternative translation option for Divi sites. It is built into Divi and translates content within the Visual Builder. SeaText differs by offering automatic background translation of new content across 125 languages with a single dashboard for review and control.

Limitations

Hard-coded strings in custom PHP or JavaScript may not be detected automatically. Text inside images, SVGs, or canvas elements is not translated. Dynamic content from third-party APIs that injects HTML after page load is outside SeaText's server-side filter. Extremely long translations in languages like German or Finnish can overflow narrow columns designed for English. Font support depends on your chosen fonts including glyphs for target languages; SeaText does not swap fonts.

Key facts

Frequently asked questions

Does SeaText create separate URLs for each language?

No. The URL stays the same. Language is detected from the visitor's browser headers, a cookie, or a query parameter. SEO tags such as hreflang and lang attribute are injected automatically so search engines understand the multilingual structure.

Can I translate only some pages?

Yes. The dashboard lets you exclude pages by URL pattern, post type, or taxonomy. You can also exclude individual modules by adding a CSS class in the module's Advanced → CSS ID & Classes field.

What happens to my custom CSS in Divi Theme Options or module Advanced tabs?

It stays exactly as written. SeaText never parses or modifies CSS. If your custom CSS targets text content via pseudo-elements, those strings won't be translated — they are CSS, not HTML text nodes. Move translatable strings into the module's content fields instead.

How do I handle brand names that should never translate?

Add them to the glossary as "do not translate" entries. SeaText will preserve them in every language.

Will translated text break my design if it's much longer?

Divi's fluid containers and responsive text settings handle most expansion. For extreme cases, use the dashboard's preview mode to spot-check tight modules. You can set a shorter approved translation for that specific string without changing the layout.

Does SeaText work with Divi Cloud layouts?

Yes. When you import a Divi Cloud layout, its text strings are indexed and translated like any other page. The layout JSON is never modified.

What if I need different images per language?

SeaText translates text only. For language-specific images, use Divi's conditional visibility features or dynamic content shortcodes that check the current language.

Bottom line

SeaText AI translates your Divi content by swapping text strings at render time. Your layouts, responsive rules, module configurations, Theme Builder templates, and custom code all remain exactly as you built them. The translation layer is additive, reversible, and invisible to the layout engine. You get 125 languages without maintaining 125 versions of every page.

What SeaText Translates Automatically

SeaText AI works by detecting the final rendered HTML that visitors see. When you publish or update a WordPress page, post, or product, SeaText sees the new content and translates it into up to 125 languages without page or language limits. Standard WordPress blocks, core page builder modules (such as Elementor or Divi text, heading, button, and blurb modules), and dynamic tags that output visible text on the front end are translated automatically.

Elements That Typically Stay Untranslated

Custom-coded widgets, hardcoded strings inside theme template files, and some third-party addon elements that render via JavaScript after the initial page load often do not get picked up. Text baked into CSS pseudo-elements, SVG inline text, or content generated by external scripts (chat widgets, calculators, embedded apps) also remains in the original language unless you add it to SeaText's manual review list or use the translation editor.

Why These Gaps Exist

SeaText translates the HTML snapshot delivered to the browser. Anything injected later by client-side scripts, anything stored outside the WordPress database (hardcoded in PHP/JS files), or anything that does not appear as selectable text nodes in the DOM is invisible to the translation engine. This is a deliberate design choice: translating only the rendered output keeps the system fast and avoids breaking layout or functionality.

Trade-off Table: Supported vs. Unsupported Element Types

How to Audit Your Site for Gaps

1. Switch the front end to a target language using SeaText's language switcher.
2. Walk every key template: homepage, product pages, landing pages, checkout, account dashboard.
3. Note any text that remains in the source language.
4. Classify each item using the table above to decide the fix.

Key Facts from SeaText Documentation

Limitations and When This Advice Does Not Apply

If your site uses a headless WordPress setup where the front end is a separate React/Vue/Next.js app consuming the REST API, SeaText's automatic translation will not reach the client-side rendered UI. In that architecture you must either translate at the API layer or run SeaText on the front-end application itself. The guidance above assumes a traditional WordPress theme or a page builder that outputs server-rendered HTML.

Frequently Asked Questions

Can I translate text inside images or background graphics?

No. SeaText translates text nodes in HTML. Text baked into image files (JPG, PNG, WebP) or SVGs used as background images is not detected. Replace graphic text with live HTML text or maintain separate localized image assets.

What about WooCommerce checkout fields and emails?

Checkout field labels rendered by WooCommerce core templates translate automatically. Custom checkout fields added via code need gettext wrapping. Transactional emails are not translated by SeaText because they are sent from the server, not rendered on a page.

Do I need a developer to fix hardcoded strings?

Usually yes. Wrapping strings in __() or _e() functions lets WordPress translation filters (and SeaText) catch them. If you cannot edit code, you can add the exact strings to SeaText's manual translation editor, but that scales poorly.

Will SeaText translate content inside iframes?

No. Iframes load a separate document. SeaText only sees the parent page. The embedded source must handle its own localization.

How often does SeaText re-scan for new content?

Continuously. When you publish or update a page, product, or post, SeaText detects the change and translates the new version in the background.

Can I exclude specific modules from translation?

Yes. SeaText lets you preserve brand voice and review key pages. You can also use CSS selector rules to skip translation on specific elements.

What happens if a third-party addon updates and breaks translation?

Re-run your language audit after major addon updates. Add any new untranslated strings to the manual editor or ask the addon developer to expose text via WordPress translation filters.

Why Your Header/Footer Stays in the Original Language

Elementor Theme Builder templates are not regular page content. They are global templates applied across the site. SeaText scans the rendered HTML of each page, but if the header or footer is cached at the server, CDN, or plugin level, the translation may not be applied. Also, SeaText may need to be explicitly enabled for the custom post type that stores these templates. The templates are saved as a custom post type called elementor_library. SeaText does not automatically scan this post type unless configured. When a visitor loads a page, the header and footer are often served from a cached fragment. That fragment may have been generated before SeaText processed the template. As a result, the visitor sees the original language. This behavior is common on sites that use aggressive caching to improve performance. Understanding the separation between page content and global templates is the first step to fixing the issue.

How SeaText Handles Elementor Content

SeaText translates the final HTML output of your pages. For standard pages and posts, this works automatically. Theme builder templates, however, are generated before the page load and can be cached aggressively. SeaText's automatic detection works on new or updated content, but theme builder templates may require a manual trigger—like re-saving the template—to start translation. SeaText hooks into WordPress content filters. When a page is rendered, SeaText intercepts the HTML and translates visible text. Elementor header and footer templates are rendered via the elementor_library post type. If SeaText is not set to process that post type, the translation step is skipped. The plugin also respects caching headers. If a caching plugin serves a stored HTML version, SeaText never sees the request. Therefore, both template inclusion and cache clearing are required.

Understanding Caching Layers That Affect Translation

Caching happens at multiple layers. Server-level caching (like Nginx fastcgi cache or Varnish) stores full page HTML. CDN caching (Cloudflare, BunnyCDN) stores copies at edge locations. Plugin caching (WP Rocket, W3 Total Cache, LiteSpeed Cache) stores page fragments or full pages in WordPress. Browser caching stores static assets and sometimes HTML. Each layer can serve an untranslated version. SeaText translates on the fly when a request reaches WordPress. If any layer serves a cached copy before the request hits WordPress, SeaText is bypassed. To ensure translations appear, you must purge caches at every layer after making template changes. Some caching plugins offer automatic purge on content update. That feature must be enabled for the elementor_library post type. CDN caches often require a manual purge or API call. Server caches may need a command line flush. Browser caches clear when the user reloads or after TTL expires.

Common Mistake: Not Clearing Cache After Template Changes

Many users update their header or footer and expect SeaText to translate it instantly. But if your site uses a caching plugin (WP Rocket, W3 Total Cache, etc.) or server-level caching, the old version continues to serve. Even if SeaText translates the new version, the cache delivers the stale HTML. The fix: clear all caches after making template changes. This includes plugin cache, server cache, CDN cache, and browser cache. Some users clear only the plugin cache and wonder why the translation still does not appear. The CDN or server cache may still hold the old version. A complete purge is necessary. Also, some caching plugins have separate caches for logged-in and logged-out users. Make sure you clear both. If you use a performance plugin that combines CSS/JS, clear that cache too. The sequence matters: update template, wait for SeaText to process, then purge all caches.

How to Verify SeaText is Processing Your Header/Footer

View a page in the target language and inspect the header/footer text. If it remains in the original language, the template is not being picked up. Check SeaText's settings to ensure it includes all post types, especially elementor_library or e-landing-page if applicable. You can also use SeaText's preview feature to see if the translation exists. In the SeaText dashboard, go to the Translations section and search for a string from your header. If the translation appears there but not on the front end, the issue is caching. If the translation does not appear in the dashboard, SeaText has not processed the template. You can force processing by re-saving the template in Elementor. Also, check the SeaText log for any errors related to the template post type.

Step-by-Step Fix for Untranslated Headers/Footers

1. Enable translation for theme builder templates: In SeaText settings, ensure translation is active for all custom post types, including Elementor templates.
2. Re-save the header/footer template: Open the template in Elementor, make a small edit (or just re-save), and update. This triggers SeaText to detect the change.
3. Clear all caches: Clear your caching plugin, server cache, CDN cache, and browser cache. If using a performance plugin, purge the cache entirely.
4. Verify: Visit a page in the target language and check that the header/footer now shows translated text.

SeaText Settings Walkthrough for Elementor Template Post Types

Log into your WordPress admin. Navigate to SeaText > Settings. Find the section labeled "Post Types" or "Content Types". You will see a list of registered post types. Look for elementor_library (Elementor templates) and e-landing-page (Elementor landing pages). Check the boxes next to them. Save changes. This tells SeaText to scan these post types for translatable strings. Next, go to the "Translation Rules" tab. Ensure that "Auto-translate new content" is enabled. This will cause SeaText to process any new or updated template automatically. If you have a multisite network, repeat these steps on each subsite or use the network settings if available. After enabling, visit a template in Elementor and click "Update" without changes. This forces SeaText to index the template. Check the SeaText dashboard after a few minutes to confirm the template strings appear.

Real-World Troubleshooting Scenarios

Multisite: On a multisite network, each site has its own SeaText settings. You must enable template post types on each site. Network-wide activation does not automatically configure post types. Use the network admin to push settings if your version supports it. Custom Headers with PHP: Some themes inject header HTML via PHP hooks. That content is not part of the Elementor template and may not be scanned. Move the text into an Elementor widget or use a shortcode that SeaText can translate. Dynamic Tags: Elementor Pro dynamic tags (site title, post title, author name) pull data from WordPress core. SeaText translates those if the source strings are translated. Ensure the site title is translated in Settings > General or via a translation plugin. Third-Party Addons: Widgets from addons like Essential Addons or HappyAddons may render text via JavaScript. SeaText only translates server-rendered HTML. If text appears after JS execution, it will not be translated. Consider using server-rendered alternatives. Cache Plugin Exclusions: Some caching plugins let you exclude specific URLs or cookies from caching. Add the language parameter (e.g., ?lang=es) to the exclusion list to prevent caching of translated versions.

Comparison of Caching Plugins with SeaText Compatibility

Note: Compatibility details are based on general plugin features. For specific SeaText integration, check with the vendor.

Key Facts About SeaText Automatic Translation

Limitations and When This Advice Doesn't Apply

If your header or footer contains hardcoded text (e.g., text inside custom HTML widgets or PHP code), SeaText cannot translate it because it is not part of the editable content. Dynamic tags from Elementor Pro (like site title) are usually translated if the underlying data is translated. If you have a highly customized caching setup that bypasses WordPress entirely, translations may not appear. This advice applies to standard Elementor Theme Builder templates with standard text widgets. Sites using headless WordPress or static site generators will need a different approach. Also, if you use a translation plugin that conflicts with SeaText (e.g., WPML or Polylang), you may need to disable one. SeaText is designed to work alone for automatic translation.

Frequently Asked Questions

Does SeaText automatically translate all Elementor widgets?

SeaText translates visible text inside standard widgets like Heading, Text, Button, and Icon List. For custom widgets or third-party addons, translation depends on whether the text is rendered in the final HTML output.

Do I need to clear cache every time I update a template?

Yes, until the cache is cleared, the old version will be served. Some caching plugins offer a way to automatically purge cache on content updates, which can help.

Can I translate the header/footer manually?

Yes, you can edit the translation directly in the SeaText editor if you prefer manual control over the AI output.

Will SeaText translate dynamic tags like site title?

Yes, as long as the site title itself is translated (via WordPress settings or a translation plugin), SeaText will display the translated version in the rendered output.

Why does my header show translated on some pages but not others?

This usually indicates a caching issue. Different pages may have different cache expiration times. Clear all caches to ensure consistency.

Does SeaText support multilingual caching plugins?

SeaText works with most caching plugins, but you may need to configure cache rules to avoid serving the same cached version for all languages.

How long does it take for SeaText to translate a template change?

Typically within seconds after the template is saved and cache is cleared. SeaText processes changes in the background.

SeaText AI pricing does not change because you use Elementor, Divi, or both; it is solely based on translated word volume and the number of active languages.

If you use both Elementor and Divi on your WordPress site, you might wonder whether that combination affects the cost of SeaText AI translation. The short answer is no. SeaText charges based on the amount of text it translates and the number of languages you publish in, not the page builder that created the content. Below we explain the real cost drivers so you can estimate your monthly bill.

What Determines the Cost of SeaText AI?

SeaText AI pricing is tied to two main factors: word volume and language count. The more words you translate and the more languages you target, the higher the cost. There are no page limits, no language limits, and no manual translation work. The system automatically translates every WordPress page, post, product, and update (Source: S1).

Because pricing is per word, the total cost scales with the size of your site and your international ambitions. A small site with one additional language will cost less than a large ecommerce store with ten languages.

Does Using Both Elementor and Divi Increase the Price?

No. SeaText AI translates the final rendered HTML that visitors see. It does not matter whether that HTML was generated by Elementor, Divi, the classic WordPress editor, or any other page builder. The plugin detects all visible text strings and translates them automatically. Using both builders on the same site adds no extra fee or complexity (Source: S1).

This means you can mix Elementor and Divi pages freely without worrying about cost differences. The per‑word rate stays the same regardless of the source.

Understanding Word Volume and Language Count

To estimate your monthly cost, you need to know two numbers:

• Total words on your site – the sum of all visible text across every page, post, product, and widget.
• Number of target languages – how many languages you want to offer (up to 125).

SeaText covers all content you publish, including new pages and updates. There are no caps on the number of pages or languages. You can start with one language and add more later. The pricing model is transparent: you pay for the translation volume you use (Source: S1).

How SeaText Handles Content from Page Builders

SeaText integrates with WordPress at the plugin level. Once activated, it monitors your site for new or updated content. When you publish a page built with Elementor or Divi, SeaText automatically queues it for translation. The process runs in the background, so you do not need to manually select pages or export content.

For sites using both Elementor and Divi, the plugin handles all pages uniformly. It does not distinguish between builders. This means you can switch between builders or use them for different sections of your site without affecting the translation workflow (Source: S1).

Key Facts About SeaText AI Pricing

Limitations and What to Watch For

SeaText AI translates visible text on the page. It does not translate hard‑coded strings in PHP, JavaScript, or custom widgets unless those strings appear in the rendered HTML. If you use custom code that outputs text outside the page builder, that text may not translate automatically.

Also, some Theme Builder templates in Elementor (like header and footer) may require separate attention. SeaText typically handles these, but it is best to test a few templates after activation. The same applies to Divi's Theme Builder.

These limitations are not unique to SeaText; they apply to any automatic translation plugin. The key is to check a few pages after setup to ensure everything is covered.

Why Understanding the Cost Drivers Matters for Your Business

Knowing how word volume and language count affect price helps you plan a realistic ROI. Translation cost is a direct expense, but it also unlocks new markets, improves SEO, and can increase conversion rates.

Each additional language adds potential traffic from that locale. If the cost per word is $0.02, translating 10,000 words into five languages costs $1,000 per month. That spend may be recouped by higher sales or ad revenue from those markets.

Understanding the drivers also prevents surprise bills. By forecasting word growth as you add products or blog posts, you can budget ahead and avoid overruns (Source: S1).

How to Accurately Estimate Your Monthly Word Volume

Follow these steps to get a reliable word count:

1. Export a CSV of all posts, pages, and product titles from WordPress.
2. Use a simple script or an online word‑counter tool to sum the word totals.
3. Add estimated words for future content (e.g., weekly blog posts).
4. Multiply the total by the number of languages you plan to support.

Example worksheet:

Current site words: 12,000
Planned blog posts (4 per month × 500 words): 2,000
Future total: 14,000 words
Target languages: 3
Monthly translated words: 14,000 × 3 = 42,000
Estimated cost (per‑word rate $0.02): $840

Tools such as Screaming Frog, Yoast SEO export, or custom PHP scripts can automate the count. Keep the worksheet updated quarterly to reflect growth (Source: S1).

Real‑World Example: Small Site vs. Large E‑commerce Store

Small Site

• ~5,000 words total (home, about, 5 blog posts)
• 2 target languages

Monthly translated words = 5,000 × 2 = 10,000.

Assuming a per‑word rate of $0.02, monthly cost = $200.

Large E‑commerce Store

• ~150,000 words (product titles, descriptions, 200 blog posts, FAQs)
• 10 target languages

Monthly translated words = 150,000 × 10 = 1,500,000.

Cost = 1,500,000 × $0.02 = $30,000 per month.

These examples show how word volume and language count drive price linearly. They also illustrate why a per‑word model is fair for both small and large sites (Source: S1).

Common Misconceptions About Page‑Builder Costs

Myth 1: "More builders = higher cost." The per‑word model ignores the tool used to create content. Whether you use Elementor, Divi, Gutenberg, or a custom builder, the cost stays the same.

Myth 2: "You pay per page." SeaText has no page caps. You pay only for the words that appear to visitors, regardless of how many pages you have (Source: S1).

Myth 3: "Dynamic widgets add hidden fees." Dynamic content that renders as visible text is counted like any other text. If a widget pulls data from a database, the resulting words are included in the count, but there is no extra surcharge.

Best Practices for Managing Translation Budgets

1. Prioritize languages based on traffic potential. Start with the top two markets, then expand.

2. Prune low‑value content before translation. Remove outdated blog posts or duplicate product descriptions.

3. Leverage the free tier to test translation quality on a small subset of pages. SeaText offers a free activation that lets you translate a limited word count without cost (Source: S1).

4. Set word‑count alerts in your WordPress dashboard. Some SEO plugins can report total word count, helping you stay within budget.

5. Review and edit critical pages manually to ensure brand voice before scaling automatically.

Frequently Asked Questions

Does SeaText charge extra for using Elementor or Divi?

No. The pricing is based on word volume and languages, not on which page builder you use.

How do I estimate my word volume?

You can use a content audit tool or manually count words in your most important pages. SeaText also provides a free tier that lets you translate a small amount of content to see how it works.

Can I translate only certain languages?

Yes. You choose which languages to activate. You can start with one and add more anytime.

Is there a free trial?

Yes. SeaText offers a free activation that lets you translate your WordPress site into 125 languages automatically. You can test the translation quality and coverage before committing to a paid plan.

What happens if I update a page after translation?

SeaText detects the change and automatically re‑translates the updated content. No manual intervention is needed.

Can I switch languages later without extra cost?

Adding a new language adds the per‑word cost for that language only. Removing a language stops future charges for it. There is no penalty for changing language selections.

How does SeaText handle dynamic content from page builders?

SeaText translates any text that appears in the final rendered HTML, including dynamic widgets and shortcodes. If a widget generates text on the fly, that text is counted like any other word. However, text generated purely by JavaScript outside the HTML may need a separate solution.

SeaText AI translates Divi global modules once and applies the translation everywhere the module is used. Library items are translated independently each time they are inserted into a page.

What Are Divi Global Modules and Library Items?

Divi global modules are saved elements that sync across every page where you use them. Change one, and it updates everywhere. Library items are saved modules or layouts you insert into a page, but they do not stay linked after insertion—each copy is independent.

Why the Distinction Between Global Modules and Library Items Matters

Global modules keep design consistent across the site. Library items let you reuse a block while allowing per‑page tweaks. Understanding how SeaText treats each helps you plan translation workflow and avoid unexpected duplicate work.

How SeaText Handles Global Modules

SeaText translates the final rendered HTML of your page. A global module appears on multiple pages, but its text is the same everywhere. SeaText translates that text once, and the translated version shows on every page that uses the module. This means you do not need to translate the same global module multiple times. When you update the original module text, SeaText sees the change and retranslates it automatically.

How SeaText Handles Library Items

Library items are not linked after insertion. Each page that contains a library item holds its own copy of the text. SeaText treats each page as a separate document, so it translates the library item text independently on each page where it appears. If you insert the same library item on ten pages, SeaText will translate it ten times—once per page. This is correct behavior because you might want different translations or edits on different pages.

How SeaText Detects Changes and Retranslates Content

SeaText scans your WordPress site for new or updated content. When it detects a change in the visible text of a page, it sends that text to the translation engine and stores the result. The scan runs in the background and usually finishes within minutes. For global modules, the change is detected once because the module’s text exists in one place. For library items, each page is scanned separately, so each copy triggers its own translation request.

Concrete Example: Global Header/Footer vs Library Item

Imagine a global header that contains your site slogan. You translate the header into French once. Every page that shows the header displays the French slogan automatically. Now consider a library item called “Call‑to‑Action button”. You insert it on the home page, product page, and blog page. SeaText translates the button text three times. You can later edit the French translation on the product page without affecting the button on the home page.

Trade‑offs: Consistency vs Per‑Page Flexibility

Global modules give you consistency: one translation serves all instances. This reduces translation cost and ensures uniform branding. Library items give you flexibility: each instance can have its own wording. This increases translation effort but lets you tailor messages to specific contexts. Choose global modules for site‑wide elements like headers, footers, or navigation. Choose library items for blocks that may need local variation, such as promotions or testimonials.

Prerequisites for Using SeaText with Divi

• A WordPress site with Divi theme or Divi Builder installed.
• SeaText plugin installed and activated.
• An API key from SeaText (free tier available).
• SeaText translation enabled for your site.

Step‑by‑Step: Setting Up Automatic Translation for Divi Content

1. Install SeaText – Add the SeaText plugin to your WordPress site and activate it.
2. Connect your API key – Enter your SeaText API key in the plugin settings.
3. Enable translation – Turn on automatic translation for your site. SeaText will start translating all pages, including Divi content.
4. Check global modules – Visit a page that uses a global module in a second language. The translation should appear automatically.
5. Check library items – Insert a library item into a new page. That page will be translated the next time SeaText scans your site.
6. Edit if needed – You can manually edit translations using the SeaText editor if you want to adjust wording.

How to Verify Your Translations Are Correct

Switch your site to a translated language and view a page that uses a global module. The module text should be in the target language. For library items, check that the text on each page is translated independently. If something is missing, publish a small update to the page or module to trigger a retranslation.

Key Facts About SeaText Translation

Limitations and What SeaText Does Not Translate

SeaText translates visible text on your pages—headlines, buttons, paragraphs, and offers. It does not translate module settings, layout structure, CSS, or JavaScript. It also does not translate Theme Builder templates unless they are rendered as part of a page. If you use custom PHP code to output text, that text may fall outside SeaText's scope.

Frequently Asked Questions

Will SeaText translate a global module that I update?

Yes. SeaText detects changes to the text and retranslates automatically.

Can I translate a library item differently on different pages?

Yes. Because each page is translated independently, you can edit the translation on one page without affecting others.

Does SeaText work with Divi Theme Builder?

SeaText translates the final HTML output. If a Theme Builder template contains text, it will be translated when the template is rendered on a page.

How long does it take for translations to appear?

Translations appear within minutes after SeaText scans your site.

Do I need to keep SeaText active after setup?

Yes. The plugin runs in the background to detect new or updated content and translate it.