To secure several country‑code domains (example.fr, example.de, example.es, etc.) you can either use a single multi‑domain (SAN) certificate, a wildcard certificate that covers subdomains, or rely on your hosting provider’s automatic SSL service. All three options let you avoid renewing each certificate individually.

Why SSL Matters for Multilingual Sites

An SSL/TLS certificate encrypts traffic between a visitor’s browser and your server. Without it, data travels in plain text and browsers show a “Not Secure” warning, which hurts trust, conversion rates, and SEO rankings across every language version of your site.

Certificate Strategies: Wildcard vs SAN vs Auto‑SSL

• Wildcard certificate – Secures all subdomains of one parent domain (e.g., *.example.com). It cannot cover separate ccTLDs such as .fr or .de.
• Multi‑domain (SAN/UCC) certificate – Lists each domain or subdomain in the Subject Alternative Name field. One certificate can protect example.com, example.fr, example.de, and example.es simultaneously.
• Auto‑SSL from your host or Let’s Encrypt – The provider automatically issues and renews certificates for every domain that points to your server. This removes manual CSR generation and installation steps.

Trade‑offs: Wildcards are simplest for many subdomains but fail for distinct ccTLDs. SAN certificates give full control over the exact domain list but require re‑issuance when you add or remove a domain. Auto‑SSL is the least hands‑on, yet you depend on the host’s feature set and rate limits (e.g., Let’s Encrypt allows 100 SAN entries per certificate).

Choosing the Right Approach for ccTLDs

If all language sites live on subdomains (fr.example.com, de.example.com) a wildcard works. For separate ccTLDs you need a SAN certificate or a host that provisions multi‑domain auto‑SSL. Evaluate the number of domains, validation method (DNS vs HTTP), and whether you need extended validation (EV) – only commercial CAs offer EV.

Prerequisites and DNS Setup

1. All language domains must resolve to the same IP address or load balancer.
2. Access to your DNS provider to add or update A or CNAME records for each domain.
3. Control‑panel or SSH access to the web server where the certificate will be installed.

Step‑by‑Step: Provisioning a Multi‑Domain (SAN) Certificate with Let’s Encrypt

1. Gather domain list: Write down every language domain you need (example.com, example.fr, example.de, example.es).
2. Install Certbot on your server (or use your host’s built‑in Let’s Encrypt integration).
3. Run Certbot with the domain list:

   certbot certonly --webroot -w /var/www/html -d example.com -d example.fr -d example.de -d example.es

   Certbot will perform HTTP‑01 challenges for each domain.
4. Install the issued certificate: Point your web server to the generated files. For Apache set SSLCertificateFile and SSLCertificateKeyFile. For Nginx set ssl_certificate and ssl_certificate_key.
5. Test the configuration: Run openssl s_client -connect example.fr:443 -servername example.fr and verify the certificate chain lists all SAN entries.

Automating Renewal and Monitoring

Let’s Encrypt certificates expire every 90 days. Certbot installs a systemd timer or cron job that runs certbot renew --quiet twice daily. For commercial CAs, enable their renewal reminders and script the re‑install using their API. Monitor renewal logs and set up alerts (e.g., via Prometheus or a simple email) so you catch failures before a certificate expires.

Hosting Partner Integrations for Automated SSL

SeaText partners with hosting providers that offer automatic multi‑domain SSL provisioning, so when you activate SeaText on WordPress the host can issue and renew SAN certificates for every language domain without extra steps [S1]. This integration means you can launch new ccTLDs, add them to SeaText’s translation pipeline, and have HTTPS ready instantly.

Troubleshooting Checklist

• Confirm each domain resolves to the correct IP (use dig +short example.fr).
• Verify the web server serves the challenge file at /.well-known/acme-challenge/ for HTTP‑01 validation.
• Check that the certificate’s SAN list includes every language domain (openssl x509 -in cert.pem -text -noout | grep DNS).
• Ensure the private key matches the certificate (openssl rsa -in key.pem -pubout | openssl x509 -in cert.pem -pubkey | diff -).
• Review renewal logs for errors; common causes are firewall blocks on port 80 or DNS propagation delays.

Common Mistake to Avoid

Leaving a domain out of the SAN list. If you add a new language domain later but forget to include it in the certificate, visitors will see a security warning until you re‑issue the cert. Always keep a master list and re‑run Certbot (or your host’s auto‑SSL) whenever you add or drop a domain.

FAQ

• Do I need a separate certificate for each ccTLD? No. A SAN certificate can cover all ccTLDs in one file.
• Can Let’s Encrypt handle dozens of domains? Yes, up to 100 SAN entries per certificate.
• What if my host only offers auto‑SSL for subdomains? Use a wildcard for subdomains and a separate SAN cert for the ccTLDs, or switch to a host that supports multi‑domain auto‑SSL.
• How much does a commercial multi‑domain cert cost? Prices vary; many providers start around $100 per year for up to 5 domains.
• Does SeaText manage SSL for me? SeaText does not issue certificates, but its hosting partners provide automatic multi‑domain SSL that works alongside SeaText’s translation agents [S1].
• What happens when a certificate expires? Browsers show a warning and traffic drops. Automated renewal (Certbot timer or host auto‑SSL) prevents this.

WPML (with the domain‑per‑language add‑on), Polylang Pro, TranslatePress (premium) and SeaText can handle custom domains per language on a single WordPress install.

Conditional recommendation: If you need full control and are comfortable editing code, choose WPML; for a simpler setup with sub‑domains, pick Polylang Pro; for a visual editor and low effort, go with TranslatePress Premium; if you prefer AI‑driven translation and want an all‑in‑one solution, consider SeaText (once domain support is confirmed).

What does “custom domain per language” mean?

Each language version lives on its own top‑level domain, such as example.com (English), example.fr (French) and example.de (German). The site shares a single WordPress codebase, but the web server routes requests based on the domain name.

Search engines treat each domain as a separate geographic signal, which can improve local relevance and trust.

Why using separate domains matters

Separate domains let you use country‑code top‑level domains (ccTLDs). Users often trust a .fr address more for French content. Google also uses the domain as a strong geo‑targeting cue.

Benefits include clearer hreflang signals, better local backlink profiles, and the ability to host language‑specific legal pages (privacy policies, terms).

Decision criteria for choosing a plugin

• Native domain support – Does the plugin map domains without custom code?
• Setup effort – Number of steps, need for files like sunrise.php, DNS changes.
• Pricing model – One‑time, annual, or subscription.
• Control & customization – Hooks, visual editors, AI overrides.
• SEO features – Automatic hreflang, sitemap integration, canonical handling.
• Support quality – Dedicated help vs community forums.

How each plugin implements custom domains

WPML

1. Purchase the “Domain per language” add‑on.
2. Upload sunrise.php to the wp-content folder.
3. In WPML → Languages, assign each domain to a language.
4. Update DNS to point each domain to the same server IP.

WPML then rewrites URLs early in the load process, ensuring the correct language files load.

Polylang Pro

1. Enable “Domain mapping” in Polylang settings.
2. Add each domain under Languages → Settings.
3. Map the domain to the corresponding language.
4. Ensure the web server’s virtual host points all domains to the same WordPress root.

Polylang automatically generates hreflang tags for each domain.

TranslatePress (Premium)

1. Install the “Multiple Domains” add‑on.
2. In TranslatePress → Settings, add each domain and select the target language.
3. Point DNS records to the WordPress site.
4. The plugin injects the correct hreflang tags and redirects visitors based on the domain.

SeaText

SeaText automatically detects visitor language and translates content on the fly. The official WordPress page describes instant translation, language detection and AI control, but it does not mention any native ability to map separate domains to languages. As of the latest documentation (see source S1), SeaText focuses on in‑page translation rather than domain‑level routing. Therefore, custom domain mapping would require additional server‑side configuration outside of SeaText’s built‑in features.

Implementation steps and SEO impact

Regardless of the plugin, follow these common steps:

1. Register each domain (or sub‑domain) you plan to use.
2. Configure DNS A or CNAME records to point to your WordPress host.
3. Install the chosen multilingual plugin and enable domain mapping.
4. Map each domain to its language inside the plugin UI.
5. Verify that hreflang tags appear correctly in the page source.
6. Submit an updated XML sitemap to Google Search Console for each domain.

Correct implementation improves organic visibility in each target market. Google can index each domain separately, allowing you to rank for country‑specific queries. Improper hreflang or canonical tags can cause duplicate‑content penalties.

Limitations and when the advice doesn’t apply

If you run a WordPress multisite network, some plugins (WPML, Polylang) need extra configuration and may conflict with caching layers like Varnish. SeaText’s free tier limits translation to 125 languages but does not guarantee separate domain handling, so you would need a custom solution for that use case.

SSL certificates must be installed for each domain. Without HTTPS, browsers will block mixed‑content resources and SEO rankings will suffer.

Practical scenarios

• E‑commerce expansion: A shop in the US wants a .ca domain for Canadian French customers. WPML’s domain add‑on lets the store keep a single product catalog while serving localized URLs.
• Corporate branding: A multinational corporation prefers ccTLDs for legal compliance. Polylang Pro’s domain mapping works without extra PHP files.
• Rapid launch: A startup needs a quick multilingual site. TranslatePress Premium offers a visual editor and one‑click domain activation.
• AI‑first translation: A content publisher wants AI‑generated translations with minimal manual effort. SeaText provides instant translation, but the publisher must handle domain routing separately.

Key terminology

• hreflang – HTML tags that tell search engines the language and regional targeting of each page.
• sunrise.php – A WordPress drop‑in used by WPML to match domains to languages early in the load process.
• CC‑TLD – Country‑code top‑level domain (e.g., .fr, .de).

FAQ

• Do I need a separate WordPress install for each domain? No. All four plugins can run on a single install and map domains to languages.
• Will SEO suffer if I use subfolders instead? Subfolders work, but separate domains give stronger local signals and can improve click‑through rates.
• How much does each plugin cost? WPML and TranslatePress use annual subscriptions; Polylang Pro offers a one‑time fee or yearly renewal; SeaText has a free tier with paid upgrades.
• Can I edit translations after they’re generated? All four plugins let you manually edit or override AI‑generated content.
• Is SSL required for each domain? Yes – each custom domain needs its own SSL certificate or a multi‑domain certificate.
• Does SeaText support custom domains per language? The official documentation focuses on automatic page translation and does not mention domain‑per‑language mapping, so this feature is not currently advertised.

Key facts about SeaText

When you launch a separate domain for each language, the most frequent errors are technical rather than content‑related. Missing or incorrect hreflang annotations, canonicals that point to the wrong domain, and internal links that stay hard‑coded to the primary site all confuse search engines and dilute ranking signals.

Other common oversights include forgetting an x-default tag, using a robots.txt that blocks crawlers on one domain, and offering language switchers that don’t stay consistent across the network. These mistakes can cause duplicate‑content penalties, lower visibility, and a fragmented user experience.

1. Symptom Checklist

Before you go live, look for these warning signs:

• Search console reports “Missing hreflang” or “Invalid canonical”.
• Internal links still point to example.com instead of example.fr or example.de.
• Language switcher redirects to the wrong domain or loses the selected language.
• Robots.txt blocks / on any of the language domains.

These symptoms show up in different ways. For example, a missing hreflang tag often appears as a warning in Google Search Console under “International Targeting”. A self‑referencing canonical that points to the wrong domain can cause the wrong language version to rank. Hard‑coded internal links make it impossible for crawlers to navigate all domains properly. An inconsistent language switcher frustrates users and increases bounce rates.

2. Diagnosis Order

Check the issues in this logical sequence:

1. Verify DNS and SSL are correctly configured for each domain.
2. Run a crawl (e.g., Screaming Frog) to capture hreflang and canonical tags.
3. Inspect the HTML of a few pages on each domain for self‑referencing canonicals.
4. Test the language switcher on desktop and mobile.
5. Review robots.txt files for accidental blocks.

Why this order? DNS and SSL issues break everything else. If the domain doesn’t resolve or SSL is missing, crawlers can’t even access the site. After that, a crawl gives you a complete picture of tags and links. Manual inspection of a few pages catches obvious mistakes. Then test the switcher across devices — mobile often has different behavior. Finally, check robots.txt because a single disallow for all bots can block indexing entirely.

3. Root Causes Explained

Missing hreflang usually happens when tags are added manually and the developer forgets to duplicate them on every domain. Wrong canonicals occur when the CMS defaults to the primary domain’s URL structure. Hard‑coded links are a relic of a single‑domain setup that wasn’t refactored for a multi‑domain environment.

Let’s go deeper. A missing hreflang tag means search engines cannot confidently map a page to a specific language and region. They might treat all versions as duplicates, leading to keyword cannibalization. Wrong canonicals — for example, example.fr/page canonical points to example.com/page — tell Google that the French version is not the original, so it may not rank. Hard‑coded links force users to stay on the default domain, breaking the language separation. The root cause is often a lack of automation. Manual processes are error‑prone. Using a tool like SeaText that automatically generates hreflang tags and updates internal links eliminates these root causes.

4. Corrective Actions

• Use SeaText’s automatic hreflang generation to insert correct tags on every translated page. Source: S1 – “SEATEXT detects each visitor's language, translates WordPress pages instantly”
• Set canonicals to point to the exact URL of the current language domain, not the default domain.
• Replace hard‑coded URLs with relative links or dynamic functions that respect the current domain.
• Add an x-default hreflang entry for users without a matching language.
• Ensure each domain’s robots.txt allows crawling of the main content folders.
• Make the language switcher read the current domain and preserve the path when switching.

These actions are not one‑time fixes. You need to enforce them in your development workflow. For example, when you publish a new page in English, the system should automatically create the French version with correct hreflang and canonical tags. SeaText does this automatically — it detects new content and translates it, adding the right tags without manual intervention. This prevents the mistakes from happening again.

5. Pre‑Launch Audit Checklist

Run this list before you publish:

1. All hreflang tags present and correct for every language version.
2. Canonical tags reference the same‑language URL.
3. Internal navigation uses relative URLs.
4. Robots.txt files are identical across domains (or intentionally different).
5. Language switcher retains the page path and updates the domain.
6. SSL certificates cover all domains (wildcard or multi‑domain).

Each item matters. For example, if you have different robots.txt files, one domain might be blocked while others are not. That causes incomplete indexing. The language switcher must retain the path — if a user is on example.fr/produits and switches to English, they should go to example.com/products not the homepage. SSL certificates must be valid for all domains; otherwise, browsers show security warnings, hurting trust and SEO.

6. Limitations & When This Advice Doesn’t Apply

If you use subfolders (e.g., example.com/fr/) instead of separate domains, some of these checks—especially domain‑specific canonicals—are irrelevant. Also, if you rely on a third‑party translation plugin that already manages hreflang, you may skip the manual tag step, but you should still verify the output.

Another limitation: separate domains require more infrastructure. You need to manage multiple DNS records, SSL certificates, and server configurations. For small sites with only two or three languages, subfolders or subdomains might be simpler. The advice here applies specifically to per‑language domains (ccTLDs or custom domains). If you use a different URL structure, adapt the checklist accordingly.

Also, the corrective actions listed here assume you have control over the server and CMS. If you use a hosted platform like Squarespace or Wix, you may not be able to modify robots.txt or implement dynamic internal links. In that case, consider a plugin or service that handles these tasks.

7. Frequently Asked Questions

• Why does a missing hreflang hurt rankings? Search engines can’t tell which language version to show, so they may serve the wrong page or treat each version as duplicate content.
• How often should I audit the domains? Run a quick crawl after any major content update or CMS change.
• Can SeaText handle hreflang automatically? Yes, SeaText adds hreflang tags for every translated page without manual effort.
• What if I need a country‑specific domain (ccTLD) but want to share the same content? Use canonical tags that point to the language‑specific URL on that ccTLD, not the generic domain.
• Does the language switcher need JavaScript? It can be server‑side or client‑side; the key is that it updates the domain correctly.
• What is the most common mistake beginners make? They forget to update the canonical tag. Many CMS platforms default to the primary domain, so every language version points to the English original. That tells Google the English version is the only one to index.
• How do I test if my hreflang tags are correct? Use Google Search Console’s International Targeting report or a tool like Merkle’s Hreflang Tag Checker.
• Will using SeaText fix all these issues? SeaText automates hreflang generation, internal link updates, and translation. It reduces the risk of human error. But you still need to verify DNS, SSL, and robots.txt manually.

Yes. Plugins such as SeaText, WPML, and Polylang Pro let you run a domain‑per‑language setup on a single WordPress install. They map each custom domain to a language code, then serve translated versions of the same pages.

Choose SeaText if you want instant AI translation with no page caps and a quick domain mapping. Choose WPML if you need granular control over every string and are comfortable paying for the add‑on. Choose Polylang Pro if you prefer a one‑time purchase and plan to manage translations manually.

What the single‑install approach does

The WordPress core stores one set of content. A translation plugin creates language versions on the fly and serves them when a visitor lands on the domain assigned to that language. This keeps SEO signals (link equity, crawl budget) in one site while giving each market its own URL.

Key facts

How SeaText enables domain‑per‑language

SeaText detects each visitor’s language, translates WordPress pages instantly, and keeps new posts, products, and updates translated in the background. By adding the target domain to your server’s DNS and pointing it to the same WordPress folder, you then map that domain to a language slug in SeaText’s settings. The plugin serves the translated version whenever the domain is requested.

Limitations to watch

• Each custom domain needs its own DNS A/ALIAS record and a valid SSL certificate.
• Automatic AI translation may need manual review for brand‑specific terminology.
• SEO‑critical pages should have hreflang tags; SeaText can generate them, but you must verify they appear correctly.

Step‑by‑step setup

1. Register the language‑specific domains (e.g., example.fr, example.de).
2. Point each domain’s DNS to your WordPress server and install an SSL certificate.
3. Install the SeaText plugin (or WPML/Polylang Pro) on your WordPress site.
4. In the plugin’s language settings, add each domain and assign it to the appropriate language code.
5. Enable automatic translation and, if needed, review key pages for accuracy.
6. Test by visiting each domain and checking that the correct language appears and hreflang tags are present.

Common mistake

Skipping the SSL step. Browsers block mixed‑content redirects, so visitors may never reach the translated version if the domain lacks a valid certificate.

FAQ

• Do I need WordPress multisite? No. A single‑site install works with the right plugin and domain mapping.
• Can I use subdomains instead of separate domains? Yes; the same plugins support subdomains (fr.example.com) as an alternative.
• Is there a performance impact? Minimal. The translation happens on the server side once per page load; caching plugins can further reduce load.
• How much does it cost? SeaText offers a free tier with unlimited pages and languages; premium features are optional. WPML and Polylang Pro have annual or one‑time fees.

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.