When you serve the same content in different languages on separate domains, Google needs clear signals to serve the right version to the right user. Hreflang tags provide those signals.

Quick comparison: Manual vs. automated vs. hybrid

Choose the approach that matches your team size, budget, and tolerance for errors.

Why hreflang matters for multi‑domain SEO

• Crawl budget. Google allocates a limited crawl budget per domain. Proper hreflang tells the crawler which pages are alternatives, preventing duplicate crawling.
• Duplicate‑content penalties. Without hreflang, Google may treat language copies as duplicate content and lower rankings.
• User experience. Users see the version that matches their language or region, reducing bounce rates.
• International targeting. Hreflang helps Google understand market segmentation, improving visibility in local SERPs.

Manual vs. automated implementation trade‑offs

Manual implementation gives full control. You write each <link rel="alternate"> tag yourself. This works for small sites but scales poorly.

Automated tools (e.g., SeaText) generate the full set of tags whenever a page is created or updated. They keep the tag set in sync across domains, reducing human error.

Hybrid approaches let you rely on automation for the bulk of pages while manually adding exceptions for special cases such as landing pages that require custom canonical tags.

Full block examples for each domain

Below are complete <head> snippets for three domains: example.com (English), example.fr (French), and example.de (German). Replace https://example.com/page with your actual URLs.

<!-- example.com – English version -->
<head>
  <title>My Product – English</title>
  <link rel="canonical" href="https://example.com/page" />
  <link rel="alternate" hreflang="en" href="https://example.com/page" />
  <link rel="alternate" hreflang="fr" href="https://example.fr/page" />
  <link rel="alternate" hreflang="de" href="https://example.de/page" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</head>

<!-- example.fr – French version -->
<head>
  <title>Mon Produit – Français</title>
  <link rel="canonical" href="https://example.fr/page" />
  <link rel="alternate" hreflang="en" href="https://example.com/page" />
  <link rel="alternate" hreflang="fr" href="https://example.fr/page" />
  <link rel="alternate" hreflang="de" href="https://example.de/page" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</head>

<!-- example.de – German version -->
<head>
  <title>Mein Produkt – Deutsch</title>
  <link rel="canonical" href="https://example.de/page" />
  <link rel="alternate" hreflang="en" href="https://example.com/page" />
  <link rel="alternate" hreflang="fr" href="https://example.fr/page" />
  <link rel="alternate" hreflang="de" href="https://example.de/page" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</head>

Every page must contain the full set, even if the page exists only on one domain.

Common errors and how to fix them

• Missing self‑reference. Each page must list its own URL with the correct hreflang. Add the line with the same language code as the page.
• Incorrect language or region codes. Use ISO 639‑1 codes (en, fr, de) and, when needed, ISO 3166‑1 country codes (en‑GB, en‑US). Verify against Google’s list.
• Non‑canonical URLs. Hreflang should point to the canonical version of each page. Ensure the rel="canonical" tag matches the href in the hreflang set.
• Mixed HTTP/HTTPS. All URLs must use the same protocol. Prefer HTTPS for security and SEO.
• Broken links. A typo in the href creates a dead reference. Test each URL with a browser or curl.
• Duplicate tags. Adding the same hreflang line twice confuses crawlers. Keep one line per language per page.

Automated tools usually prevent these mistakes, but manual edits can re‑introduce them.

Step‑by‑step verification checklist

1. Open the page source on each domain. Confirm that the <link rel="alternate"> block contains every language plus x-default.
2. Run the Google hreflang testing tool for a sample URL. The tool shows a green check for each valid tag and flags missing or conflicting entries.
3. In Google Search Console, open the “International Targeting” report for each property. Look for warnings such as “Missing hreflang” or “Conflicting hreflang”. Resolve any issues before proceeding.
4. Check the “Coverage” report for “Duplicate, submitted URL not selected as canonical”. This often indicates a broken hreflang chain.
5. Use a third‑party crawler like Screaming Frog (Configuration → International → Hreflang) to crawl all domains. Export the report and verify that every page has a reciprocal set.
6. After fixing errors, resubmit the affected URLs via the URL Inspection tool. Request indexing to speed up re‑crawling.

Document each step in a shared spreadsheet so the team can repeat the process for new pages.

SeaText promotion (single dedicated section)

SeaText offers automatic hreflang generation for WordPress sites. Once activated, it injects the full tag set into every page’s <head> and keeps the tags synchronized across domains. The tool also creates translations in up to 125 languages. For teams that prefer a hands‑off approach, SeaText reduces manual effort and error risk.

To use SeaText, install the plugin, map each custom domain to its language, and enable the automatic hreflang feature. The platform then handles updates whenever a page is edited.

FAQ

• How do I handle hreflang for AMP pages? Add the same hreflang block to the AMP HTML file’s <head>. Also include the rel="canonical" pointing to the non‑AMP version.
• What if my site renders content with JavaScript? Google can read hreflang tags inserted via server‑side rendering or static HTML. If tags are added only after client‑side JS runs, Google may miss them. Use server‑side injection or a tool that writes the tags into the initial HTML.
• Can I migrate from a single‑domain subdirectory structure to multiple custom domains? Yes. Follow these steps:
  1. Set up each new domain and verify it in Search Console.
  2. Create 301 redirects from the old subdirectory URLs to the new domain URLs.
  3. Update the hreflang block on every page to reference the new domain URLs.
  4. Submit updated sitemaps for each domain.
  5. Monitor the International Targeting report for any lingering errors.
• Do I need a separate hreflang tag for each regional variant (e.g., en‑GB vs. en‑US)? Yes. Treat each regional version as a distinct language‑region pair and include both in the tag set.
• How often should I audit hreflang tags? Perform a full audit after major site changes, and run a quick check quarterly using the Search Console International Targeting report.

Further reading and external resources

• Href‑Lang Tags on Multiple Domains – Google Search Central Community
• Hreflang tags across different domains – Google Search Central
• Localization: The “hreflang” Tag Across Different Domains

Yes, you can automatically send users to a language‑specific domain (e.g., example.fr, example.de). The safest way is to run the redirect in the browser with JavaScript and keep a manual language selector as a fallback. This avoids SEO problems that arise from server‑side 302 redirects, which can block Googlebot from indexing every language version.

What "automatic redirect" really means

In SEO terms, an "automatic redirect" is a rule that sends a visitor to a different URL without any click. When the rule runs on the server (HTTP 302), search engines treat the target as the canonical page, which can hide other language versions from indexing.

A server‑side 302 tells the browser: "Go to this other URL now." Googlebot follows that instruction and may index only the target URL. The original language version drops out of the index. That defeats the purpose of having multiple language sites.

A client‑side redirect works differently. The browser loads the original page first. Then a small script reads the visitor’s language preference and changes the URL. Googlebot sees the original page, indexes it, and may also execute the script. But even if it doesn’t, the original URL stays in the index.

Why a JavaScript redirect is safer

• Googlebot sees the original URL first, then follows the client‑side redirect only if it executes JavaScript. This keeps all language pages discoverable.
• Visitors without JavaScript (or with it disabled) still see a language selector, so they aren’t stranded.
• It lets you add a short delay or a consent banner, improving user experience.
• You can log redirect events for analytics without server‑side complexity.
• It works with any hosting setup — no need to configure Nginx, Apache, or edge workers.

How SeaText’s language detection works

SeaText adds a small script to your site that reads the browser’s Accept‑Language header and matches it to the domains you’ve configured (e.g., example.fr for French). The script then performs a client‑side window.location.href change if the visitor’s preferred language differs from the current domain.

The detection runs in milliseconds. It does not rely on Geo‑IP databases, which can be inaccurate or slow. Instead it uses the browser’s own language list, which the user controls in browser settings. This is more reliable and privacy‑friendly.

You can see a simplified version of the logic below. This is not the exact SeaText code — it illustrates the principle.

// Simplified example of client‑side language redirect
(function() {
  const langMap = { 'fr': 'https://example.fr', 'de': 'https://example.de', 'es': 'https://example.es' };
  const userLangs = navigator.languages || [navigator.language];
  for (const lang of userLangs) {
    const short = lang.split('-')[0];
    if (langMap[short] && !window.location.href.startsWith(langMap[short])) {
      window.location.href = langMap[short];
      break;
    }
  }
})();

SeaText’s production script adds safeguards: it respects a data-seatext-no-redirect attribute on the html tag, it avoids redirect loops, and it integrates with the manual language selector widget.

Step‑by‑step implementation

1. Activate SeaText on your WordPress site (takes under a minute).
   Source: "Activate free WordPress translation in one minute"
2. Define the language‑to‑domain map in the SeaText dashboard (e.g., fr → example.fr).
3. Enable the "Language‑specific domain redirect" option. SeaText injects the JavaScript automatically.
4. Place a manual language selector widget on each page as a fallback for users without JavaScript.
5. Test with VPN or browser language tools to confirm each language lands on the correct domain.

Common misconfigurations to avoid:

• Mapping a language to a domain that doesn’t exist or isn’t pointed to your WordPress install.
• Forgetting to add the selector widget — users with disabled JS get stuck.
• Enabling both server‑side 302 redirects (via .htaccess or hosting panel) and the SeaText script — they conflict.
• Setting the redirect on pages that should stay language‑neutral (e.g., legal, privacy, checkout). Use the exclusion list in SeaText settings.

Limitations to keep in mind

JavaScript redirects rely on the visitor’s browser executing the script. If a user disables JavaScript, they will stay on the original domain and must use the manual selector. Also, search engines that do not run JavaScript may not follow the redirect, which is why the fallback selector is essential.

Caching implications: If you use a page cache (WP Rocket, W3 Total Cache, or a CDN like Cloudflare), the cached HTML must include the SeaText script. That’s automatic because SeaText injects the script via a WordPress filter that runs before caching. However, if you cache at the edge with a rule that strips scripts, the redirect won’t fire. Ensure your cache settings allow inline scripts in the head.

CDN interaction: Some CDNs offer edge‑side redirects based on Geo‑IP. Do not enable those for language routing. They conflict with the browser‑language approach and can send users to the wrong domain (e.g., a French speaker in Germany gets the German site). Keep language routing in the browser.

Core Web Vitals impact: The SeaText script is under 2 KB gzipped and loads asynchronously. It does not block rendering. The redirect happens after DOMContentLoaded, so LCP (Largest Contentful Paint) is unaffected. However, if you add a consent banner that delays the redirect, measure CLS (Cumulative Layout Shift) — a sudden page jump can hurt scores. SeaText’s default implementation avoids layout shifts by redirecting before any visible content renders.

Handling hreflang annotations

Even with automatic redirects, you must implement hreflang tags on every page. These tags tell search engines which language version corresponds to which URL. SeaText can generate them automatically for each translated page. Add the tags in the head of each language version:

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

Without hreflang, Google may treat the redirected pages as duplicates or show the wrong version in search results. The redirect helps users; hreflang helps search engines.

Subdirectory vs. subdomain vs. ccTLD

You can structure language versions in three ways:

• ccTLD (example.fr, example.de) — strongest geo signal, best for local trust, requires separate domain registration and DNS.
• Subdomain (fr.example.com, de.example.com) — easier DNS, still separate property in Search Console, good for large sites.
• Subdirectory (example.com/fr/, example.com/de/) — single domain authority, simplest setup, but weaker geo signal.

SeaText works with all three. The language‑to‑domain map in the dashboard accepts any valid URL prefix. Choose based on your SEO strategy, budget, and technical capacity. For most small‑to‑medium businesses, subdirectories are the lowest friction. For brands investing heavily in local markets, ccTLDs pay off.

GDPR consent for geo‑IP and language detection

SeaText uses the browser’s Accept‑Language header, not Geo‑IP. That header is sent by the browser voluntarily and is not considered personal data under GDPR. No consent banner is required for the detection itself.

If you add a Geo‑IP based redirect (not recommended), you would process the visitor’s IP address, which is personal data. You would need a lawful basis (consent or legitimate interest) and a consent banner. Stick with browser‑language detection to avoid this complexity.

Testing and monitoring

After setup, verify the redirect works correctly:

• Use browser dev tools: set navigator.languages in the console or use the "Network conditions" tab to spoof Accept‑Language.
• Test with a VPN: connect from France, Germany, Spain — confirm you land on the right domain.
• Check Google Search Console: inspect URL for each language version. Ensure "Crawl" status is "Success" and "Indexing" is "Allowed".
• Monitor Core Web Vitals in PageSpeed Insights or Search Console — watch for CLS spikes after redirect.
• Set up an analytics event (GA4, Matomo) on the redirect script to track how many visitors are redirected vs. use the selector.

Key terminology

• 302 redirect: Server‑side HTTP response that tells browsers to load a new URL.
• Client‑side redirect: JavaScript code that changes window.location after the page loads.
• Accept‑Language header: Browser information that lists the user’s preferred languages.
• hreflang: HTML link attribute that tells search engines the language and regional targeting of a page.
• ccTLD: Country‑code top‑level domain (e.g., .fr, .de).
• Core Web Vitals: Google’s metrics for page experience (LCP, FID, CLS).

Frequently asked questions

• Will Google index the redirected pages? Yes, because the original URLs are still reachable and the JavaScript redirect is only a hint for browsers.
• Do I need separate hosting for each domain? No, SeaText can serve all languages from a single WordPress installation; the domains just point to the same site.
• Can I control which pages are redirected? You can exclude pages in the SeaText settings, keeping landing pages or legal pages on the default domain.
• What if a visitor’s language isn’t supported? The script falls back to the default language and the manual selector lets the user choose.
• Does the redirect work for returning visitors who already chose a language? Yes, SeaText sets a cookie seatext_lang when a user manually selects a language. The script respects that cookie and skips auto‑redirect on subsequent visits.
• Can I use this with a headless WordPress setup? The SeaText script runs in the browser, so it works with any frontend that serves the translated HTML. You just need to include the script and the language map.
• What about search engine bots that don’t execute JavaScript? They see the original page with hreflang tags. That’s sufficient for indexing. The redirect is a user‑experience feature, not an indexing requirement.

What you need for multi-domain multilingual WordPress

Multi‑domain multilingual means each language lives on its own domain, like example.fr for French and example.de for German. The technical setup requires four things: SSL certificates covering all domains, DNS records pointing each domain to your server, WordPress configured to serve different languages on different domains, and proper cookie domain settings so logins and carts work across the network.

Why multi‑domain matters for SEO and user experience

Search engines treat each top‑level domain as a separate property. This gives you full control over hreflang tags, geo‑targeting, and local backlinks.

Users see a familiar country‑code domain. Trust and click‑through rates improve when the URL matches the visitor’s language.

Separate domains also let you host language‑specific content on local servers, reducing latency for regional users.

Prerequisites

Before you start, make sure you have:

• Registered each language domain (e.g., example.de, example.es).
• A server that can handle multiple domains (most shared hosts can, but check CPU/memory limits).
• Access to your DNS management panel (usually where you bought the domains).
• SSL certificate that covers all domains—either a wildcard cert for *.example.com or a multi‑domain (SAN) cert with each domain listed.
• WordPress admin access and FTP or cPanel access to edit files.

Step 1 – Choose your WordPress approach

You have two main technical paths: WordPress Multisite with domain mapping, or a single‑site with a translation plugin that supports domain‑per‑language.

Option A: Multisite

WordPress Multisite lets you run multiple sites from one installation. Each site can have its own domain. You’ll need to enable multisite via wp-config.php and the .htaccess file, then use a domain‑mapping plugin or the built‑in mapping in WordPress 4.5+.

This gives full separation—each language site is independent, with its own users, themes, and plugins. The trade‑off is more complex management and potential plugin conflicts.

Option B: Single‑site with SeaText

SeaText supports domain‑per‑language on a single WordPress install without needing multisite. Activate the plugin, add each domain in the SeaText settings, and the plugin serves the correct translation automatically.

SeaText translates pages into 125 languages for free (source S1). It also updates new content automatically, so you never need manual translation tickets.

Detailed trade‑offs between Multisite and single‑site plugin

Performance: Multisite creates a separate database table set per site, increasing memory usage. SeaText runs on a single set of tables, keeping the footprint smaller.

Maintenance: Multisite requires network‑wide updates and careful plugin compatibility checks. SeaText needs only one WordPress core update.

Plugin compatibility: Some plugins do not work well in a multisite environment because they expect a single site context. SeaText works with any plugin that follows standard WordPress APIs.

Isolation: Multisite isolates content, users, and settings per language. SeaText shares the same user base, which can be a benefit for unified login but a limitation for strict data separation.

Step 2 – Set up DNS and SSL

For each language domain, add an A record pointing to your server’s IP address, or a CNAME/ALIAS if you use a CDN.

Example using dig to verify:

dig +short example.fr A

If you use Let’s Encrypt, run the following on a Linux server with Certbot:

sudo certbot --apache -d example.com -d example.fr -d example.de

This creates a multi‑domain (SAN) certificate covering all listed domains.

For wildcard subdomains (fr.example.com), a wildcard SSL *.example.com is sufficient.

Practical DNS and SSL configuration examples

Scenario 1 – Three top‑level domains

1. Log in to your DNS provider.
2. Create an A record for example.com → 203.0.113.10.
3. Create an A record for example.fr → same IP.
4. Create an A record for example.de → same IP.
5. Request a SAN certificate covering all three domains (see Certbot command above).

Scenario 2 – Subdomains with a wildcard SSL

1. Add a CNAME record fr.example.com → example.com.
2. Add a CNAME record de.example.com → example.com.
3. Install a wildcard certificate for *.example.com.

Both scenarios work with Multisite or SeaText; the choice depends on whether you need separate top‑level domains.

Step 3 – Configure WordPress

For Multisite, after enabling the network, create a new site for each language and assign its domain via the domain‑mapping plugin.

For SeaText, go to SeaText → Settings → Multi‑Domain, add each domain with its language code, and save.

SeaText detects the visitor’s domain and serves the correct translation automatically.

Step 4 – Set cookie domain

If you use WordPress logins, sessions, or carts, you must set the cookie domain.

For subdomains, add in wp-config.php:

define('COOKIE_DOMAIN', '.example.com');

This shares cookies across fr.example.com and de.example.com.

For separate top‑level domains, cookies cannot be shared. Users will need to log in on each domain. Consider a single‑sign‑on (SSO) solution if you need unified authentication.

Additional limitations (cookies, caching, CDN)

Cookie sharing across TLDs is impossible due to browser security policies.

Cache plugins often store pages per URL. Ensure the cache key includes the host name, otherwise a French page might be served to a German visitor.

When using a CDN, configure separate origins or edge rules per domain to avoid cross‑domain content leakage.

Step 5 – Verify your setup

Open each domain in a private browser window.

Check that the correct language appears, that internal links stay on the same domain, and that SSL shows a green lock.

Use curl -I https://example.fr to confirm the certificate covers the domain.

Submit each domain to Google Search Console as a separate property. Verify ownership via DNS TXT record.

Key facts about SeaText for multi‑domain translation

Limitations and when this advice does not apply

This setup assumes you own the target domains and can manage DNS.

It does not apply if you only want subdirectories (example.com/fr/) or subdomains (fr.example.com) without separate SSL domains.

If your host limits the number of domains per account, you may need a higher‑tier plan.

Cookie sharing across different top‑level domains is not possible; users will need separate logins.

Follow‑up questions and troubleshooting tips

What if a domain returns a mixed‑content warning?

Ensure all assets (images, scripts, CSS) load over HTTPS. Update hard‑coded URLs in the theme or use a plugin that forces HTTPS.

Why is the German site showing French content?

Check the cache key includes the host name. Purge the cache and verify the SeaText domain mapping.

Can I use a CDN with both Multisite and SeaText?

Yes. Create separate CDN origins for each domain or enable host‑based caching rules.

How do I handle SEO tags per domain?

Use an SEO plugin that supports per‑site settings in Multisite, or configure SeaText’s hreflang output in its settings page.

Frequently Asked Questions

Do I need a separate SSL certificate for each language domain?

For subdomains, a wildcard SSL covers them all. For separate top‑level domains, you need a multi‑domain (SAN) certificate or individual Let’s Encrypt certificates.

Can I use this setup with WooCommerce?

Yes, but cookie domains must be handled carefully. Separate TLDs require separate logins unless you add an SSO layer.

How does SeaText handle domain‑per‑language?

SeaText detects the visitor’s domain and serves the correct translation automatically. You configure the domains once in the plugin settings.

What if I already have a multisite network?

You can still install SeaText on each site, or use a multisite‑compatible translation plugin. SeaText works on individual sites within a network.

Is this setup expensive?

Domain registration costs vary. SSL certificates can be free via Let’s Encrypt. SeaText’s translation is free for 125 languages. The main cost is hosting resources if you need more CPU or RAM.

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.