Yes, SeaText supports wildcard patterns (e.g., /campaign/*) and simple regex for flexible exclusion rules. You set these rules in the Exclusion Rules section of the SeaText dashboard before any agents run.

Why exclude pages by URL pattern or regex?

Excluding pages lets you prevent agents from modifying content that should stay unchanged. Common reasons include protecting checkout pages, preserving legal disclaimers, avoiding translation of user‑generated content, and keeping test pages out of A/B experiments. Pattern‑based exclusion scales better than adding each URL manually.

How wildcard matching works in SeaText

Wildcard patterns use an asterisk (*) to represent any sequence of characters within a single path segment. For example, /blog/*/draft matches /blog/2024/01/draft but not /blog/2024/01/02/draft. The pattern is evaluated against the request path after the domain, ignoring query strings and fragments unless they are explicitly included.

How regex matching works in SeaText

Regex patterns follow JavaScript regular‑expression syntax. You can use anchors (^ $), character classes, quantifiers, and grouping. SeaText compiles the expression once per rule and tests each inbound URL path against it. Advanced features such as look‑aheads, look‑behinds, and Unicode property escapes are not supported.

Wildcard vs regex: which should you use?

Choose wildcards for simple prefix or suffix matches (e.g., /campaign/* or */preview). Choose regex when you need alternation, optional segments, or numeric ranges (e.g., ^/product/\d{3,5}$). Wildcards are faster to write and easier to audit; regex gives finer control but requires testing.

Step‑by‑step setup with example patterns

1. Log in to SeaText and open the dashboard.
2. Navigate to Settings → Exclusion Rules (the exact menu name may vary by version).
3. Click Add Rule.
4. Select Pattern Type: Wildcard or Regex.
5. Enter the pattern. Example wildcard: /campaign/*. Example regex: ^/api/v[12]/internal/.*$.
6. Optionally add a description for future reference.
7. Save the rule. The change takes effect on the next agent processing cycle.
8. Verify by visiting a matching page and checking the SeaText debug console or page source for the absence of agent modifications.

Common mistakes and edge cases

• Inconsistent leading slash – SeaText expects patterns relative to the site root, so start with /.
• Overly broad regex (e.g., .*) that unintentionally matches wanted pages – test with a regex tester before saving.
• Forgetting to re‑save after editing a pattern.
• Assuming query strings are matched – they are ignored unless the pattern explicitly includes them.
• Using unsupported regex features (look‑aheads, Unicode escapes) which cause the rule to be rejected.

Limitations

SeaText accepts only a subset of JavaScript regex. Look‑aheads, look‑behinds, and Unicode property escapes are not supported. Very complex patterns may be rejected or cause performance slowdowns. Wildcard matching is limited to a single path segment per asterisk; it cannot span multiple directory levels.

Frequently asked questions

Does a wildcard match query strings and fragments?

No. Wildcard and regex patterns are evaluated against the URL path only. Query strings and fragments are ignored unless you include them explicitly in a regex.

Can I exclude a URL prefix without affecting child paths?

Use a wildcard that ends before the child segment, e.g., /admin/* matches /admin/settings but not /admin/users/profile if you need deeper control, switch to regex with an anchor.

How do I test a regex before saving it?

Use an online JavaScript regex tester (such as regex101.com) with the “ECMAScript” flavor. Paste sample URLs to confirm the pattern behaves as expected.

What does SeaText do with excluded pages in reports and quotas?

Excluded pages are not processed by agents, so they do not appear in translation, A/B test, or personalization reports. They also do not count toward any processing quotas.

Can I combine multiple patterns in one rule?

Each rule holds a single pattern. To exclude several unrelated paths, create multiple rules.

Are exclusion rules applied instantly?

Rules take effect on the next agent processing cycle, which typically runs within a few minutes after saving.

Exclude a landing page from translation when it targets a single-language audience, runs a time-sensitive promotion, or carries legal disclaimers that must stay in one language. These conditions create risk: mistranslated legal text, expired offers showing in the wrong market, or budget wasted on visitors who will never convert.

Quick Readiness Checklist

• Single-language audience: The campaign targets only one country or language group.
• Time-sensitive offer: The page promotes a flash sale, event, or deadline that expires before translation finishes.
• Legal or regulatory text: Disclaimers, terms, or compliance statements that must remain in the original language by law.
• Brand-controlled messaging: Headlines or copy that require human review before any language change.
• Technical constraints: Dynamic content, personalization tokens, or scripts that break under automatic translation.

If any item applies, keep the page in its original language. If none apply, the page is ready for automatic translation.

How to audit existing landing pages before enabling translation

Follow a short audit to avoid costly mistakes. The audit uses the same criteria as the exclusion checklist but applied to pages already live.

1. Map traffic sources. Use analytics to see which languages bring visitors to each landing page. If a page receives <5% traffic from non‑primary languages, consider exclusion.
2. Check offer dates. Look for date fields, countdown timers, or event registrations. If the end date is within 48 hours, flag the page as time‑sensitive.
3. Identify legal blocks. Search the HTML for keywords such as “terms”, “privacy”, “disclaimer”, or regulatory identifiers. Pages containing these blocks should stay in the original language unless you have certified translations.
4. Review brand‑critical copy. Scan headlines and taglines for wordplay, puns, or brand slogans. Mark any that rely on cultural nuance.
5. Test technical stability. Enable translation on a staging copy. Verify that dynamic widgets, price calculators, and personalization tokens render correctly. If errors appear, add the page to the exclusion list.
6. Document the decision. Record the audit outcome in a shared spreadsheet. Include the page URL, audit date, and reason for exclusion or inclusion.

Run this audit quarterly or whenever a major campaign launches. Updating the audit keeps the exclusion list aligned with business goals and reduces translation waste.

Why Exclusion Decisions Matter

Automatic translation scales fast. SEATEXT detects each visitor's language and translates WordPress pages instantly, keeping new posts, products, and updates translated in the background. That speed is an asset until it translates something that should stay fixed. A mistranslated legal disclaimer can create liability. An expired promotion shown in a new market wastes ad spend. A headline that relies on wordplay loses its punch when machine-translated. The checklist prevents those errors before they go live.

How Automatic Translation Works on Landing Pages

When you activate translation, the system scans every page, headline, button, and offer. It creates localized versions in up to 125 languages without a separate site for each market. New content — pages, products, posts, headlines — gets translated automatically as you publish. You can edit translations, preserve brand voice, review key pages, and run A/B tested translation variants to find the message that sells best in each market. The process is hands‑off by default, which is why exclusion rules matter.

Key Scenarios Where Exclusion Makes Sense

Single-Language Campaigns

A Google Ads campaign targeting only Spanish speakers in Mexico does not need a French version of the landing page. Translating it adds cost and complexity with zero return. Keep the page in Spanish.

Flash Sales and Event Registrations

A 48‑hour sale or a webinar registration page that closes tomorrow will expire before translated versions generate meaningful traffic. Exclude the page; translate the evergreen product page instead.

Regulated Legal Content

Financial disclosures, health warnings, or government‑mandated notices often require exact wording in a specific language. Machine translation cannot guarantee compliance. Exclude these pages and manage them manually.

Brand Voice‑Critical Pages

Taglines, humor, or cultural references that define your brand may not survive translation. If the page's conversion power depends on precise phrasing, keep it in the original language and create a separate, locally written version later.

Technically Fragile Pages

Pages with dynamic pricing calculators, personalized tokens, or third‑party widgets can break when the translation layer rewrites DOM elements. Test first; exclude if the risk is high.

Decision Framework: Step-by-Step Checklist

1. Identify the page's primary traffic source and target audience language.
2. Check for expiration dates on offers, events, or content.
3. Scan for legal, regulatory, or compliance text that must stay unchanged.
4. Assess whether brand voice, wordplay, or cultural nuance drives conversion.
5. Review technical implementation: dynamic content, scripts, personalization.
6. If any check fails, add the page to the exclusion list. If all pass, enable translation.

Common Mistakes and How to Avoid Them

• Translating everything by default: Wastes budget on pages that never reach a multilingual audience. Use the checklist first.
• Forgetting legal pages: Terms of service, privacy policies, and disclaimers often need human legal review per jurisdiction. Exclude them from automatic translation.
• Ignoring time-sensitive content: A translated Black Friday page appearing in January confuses visitors. Set exclusion rules tied to campaign calendars.
• Assuming brand voice translates: Slogans and puns rarely work across languages. Plan local copywriting for high‑value pages instead of relying on machine translation.
• Skipping technical QA: Dynamic elements break silently. Test a staging version with translation enabled before going live.

Limitations of This Advice

This checklist applies to landing pages managed through a translation layer like SEATEXT that translates every page, headline, button, and offer into up to 125 languages automatically. It does not cover manual translation workflows, headless CMS setups without translation integration, or pages that require certified human translation for legal validity. The advice assumes you can toggle exclusion per page and that translation runs continuously on new content.

Key Facts

Terminology

• Automatic translation: Machine translation that runs continuously on new and updated content without manual tickets.
• Exclusion rule: A setting that prevents specific URLs or page types from entering the translation pipeline.
• Brand voice preservation: Configuration that keeps terminology, tone, and style consistent across languages.
• A/B tested translation: Running multiple translation variants to measure which drives higher conversion in a target market.

FAQ

Can I exclude only part of a page?

Yes. You can exclude specific blocks, words, or URLs while translating the rest of the page.

What happens if I translate a page with an expired promotion?

The translated version will show the expired offer to visitors in that language, wasting traffic and damaging trust. Exclude time-sensitive pages or set a translation schedule aligned with your campaign calendar.

Do I need to exclude legal pages in every jurisdiction?

If a legal disclaimer must remain in a specific language by law, exclude that page from automatic translation and manage it with human legal review.

How do I test if a page breaks under translation?

Enable translation on a staging environment. Check dynamic calculators, personalization tokens, and third‑party widgets. Exclude the page if elements break.

Can I translate a page later after excluding it?

Yes. Remove the exclusion rule and the system will translate the page on the next cycle.

Does excluding a page hurt SEO in other languages?

Only if that page was meant to rank in those languages. Exclude pages that have no search audience in the target language; translate pages that do.

What if my campaign expands to new languages later?

Remove the exclusion. The page will be translated automatically and tracked by language and market.

When a site owner decides which parts of a WordPress site to translate, the first step is to understand what the translation engine does by default. SEATEXT detects each visitor’s language and translates pages instantly, keeping new posts, products, and updates translated in the background [S1].

Because the translation is automatic, teams often add exclusion rules to keep certain page types in the original language. The most common exclusions are legal pages, checkout or thank‑you pages, private member areas, A/B test variants, and temporary campaign pages.

What translation exclusion means

Translation exclusion is a deliberate rule that tells the platform not to send specific URLs or page templates through the translation workflow. The decision is usually based on content purpose, audience, or technical constraints rather than language ability.

How SEATEXT translates a WordPress site

SEATEXT translates every WordPress page, post, product, and update automatically. There are no page limits, no language limits, and no manual translation work required [S1].

The system detects each visitor’s language and serves a translated version instantly. New content is picked up and translated in the background without any tickets or manual steps [S1].

Setting up exclusion rules in SEATEXT

Automatic does not mean uncontrolled. You can edit translations, preserve brand voice, review key pages, and use advanced A/B tested translation when you want to find the message that sells best in each market [S1].

Exclusion rules are created by URL pattern, page ID, or a custom tag. When a rule matches, SEATEXT skips sending that content to the translation engine and leaves the original text in place. You can also override a rule for individual pages if a specific translation is later required.

Page categories that teams frequently exclude

• Legal pages – Terms of service, privacy policies, and disclaimers often contain jurisdiction‑specific wording. Translating them can introduce ambiguity or liability, so many companies keep the original version and provide a separate, lawyer‑reviewed translation only when required.
• Checkout and thank‑you pages – These pages handle payment processing, order confirmation, and security checks. Any change to field names, hidden inputs, or confirmation messages can break the flow or trigger fraud filters. Keeping them in the source language ensures the checkout process remains stable.
• Private member areas – Dashboards, account settings, and support portals are used by logged‑in users who already navigate the site in the source language. Translating these screens adds cost without a clear benefit, especially when the audience is small or highly familiar with the interface.
• A/B test variants – Experiments rely on identical code except for the variable being tested. If translation changes the layout or text unexpectedly, it can confound results. Excluding the variant pages guarantees that only the intended variable differs between versions.
• Temporary campaign pages – Landing pages for a limited‑time promotion, event, or product launch often have a short lifespan. The effort to translate, review, and maintain them may outweigh the gain, especially if the campaign targets a single language market.

Decision framework for applying exclusions

1. Identify the page’s primary purpose – Is it legal, transactional, private, experimental, or promotional?
2. Assess the risk of translation – Could translating break functionality, create legal exposure, or dilute test clarity?
3. Weigh the cost versus benefit – Estimate translation effort, review time, and maintenance against the expected uplift in engagement or conversions from localization.
4. If the risk is high or the benefit low, apply an exclusion rule in SEATEXT; otherwise, include the page in the automatic translation workflow.

Practical scenarios

Scenario 1 – E‑commerce store: The store excludes its checkout, order‑history, and tax‑information pages using a URL‑pattern rule. Legal pages (terms, refund policy) stay in English, but a separate, vetted Spanish version is published only for the Spanish‑language market. A/B test pages for a new product badge are excluded so the test runs with identical code across languages.

Scenario 2 – SaaS platform: The platform excludes the admin dashboard and user‑settings pages because its enterprise clients work primarily in English. Marketing landing pages and blog posts are fully translated, while a limited‑time webinar promo page is excluded after the event ends.

Scenario 3 – News site: The site excludes its comment‑system module and user‑profile pages, which rely on third‑party scripts that break when translated. All article pages and category indexes are translated, while a special‑report microsite for a one‑day conference is excluded after the conference concludes.

Limitations and when not to exclude

Exclusion is not a blanket rule. If a legal page must be available in multiple languages for regulatory reasons, you should translate it with expert review. Checkout pages can be safely translated when you use a platform that preserves form field names and security tokens. Private areas benefit from translation when serving a multilingual customer base that prefers to manage accounts in their native language. Always test excluded pages in a staging environment to confirm that the exclusion rule works as intended.

Key facts

FAQ

Why are legal pages often left untranslated?

Legal wording must be precise; translation can introduce ambiguity that may create liability or compliance issues.

Can checkout pages be safely translated?

Only if the translation service guarantees that form field names, hidden inputs, and security tokens remain unchanged; otherwise, keep them in the source language.

What is the simplest way to set up an exclusion rule in SEATEXT?

Create a rule by URL pattern (e.g., /checkout/*) or assign a custom tag to the pages you want to skip.

Do excluded pages affect SEO?

Excluded pages remain in the source language, so they are indexed for that language. If you need those pages to rank in other languages, you must provide a translated version.

How often should I review my exclusion list?

Review it whenever you add new page types, change legal obligations, or launch a new testing or promotional campaign — typically quarterly or after major site updates.

Quick Answer: Exclude a Post or Page by ID

Find the post ID in the WordPress editor URL. The number after post= is the ID. Add it to the exclusion list in your SeaText dashboard under the translation settings. Save. The page will no longer be translated.

How to Find the Post ID in Different Editors

The post ID is always visible in the edit screen URL. Here is how to find it in common editors:

• WordPress Block Editor (Gutenberg): Open the post or page. Look at the browser address bar. The URL looks like https://yoursite.com/wp-admin/post.php?post=123&action=edit. The number after post= is the ID.
• Classic Editor: Same pattern. The URL contains post= followed by digits.
• Elementor: When editing with Elementor, the URL in the WordPress admin still shows the native post ID. Switch to the backend editor view if needed.
• Bricks Builder: The ID appears in the admin URL while editing. No extra steps needed.
• Custom Post Types: Products, landing pages, and other custom types use the same ID system. The edit URL always includes post=.

If you use a page builder, the URL structure remains the same. The ID is a WordPress core identifier.

Step-by-Step: Excluding an ID

1. Copy the numeric post ID from the editor URL.
2. Log in to your SeaText dashboard.
3. Navigate to the Website Translation Agent settings. This is the agent that handles automatic translation.
4. Find the exclusion list. It may be labeled as "Exclude by ID" or "Translation Exclusions". The exact label depends on your SeaText version.
5. Paste the ID into the field. If you have multiple IDs, separate them with commas (e.g., 123,456,789).
6. Save the changes. SeaText will skip translation for those IDs on the next cycle.

Existing translations for those IDs remain in the cache. They will not be deleted automatically. To remove them, clear the translation cache from the dashboard.

What Happens After You Exclude an ID

SeaText continues to translate all other pages as usual. The excluded page stays in its original language. Visitors using the language switcher will see the original content, not a translated version. The page URL still exists in every language, but the content is the same across all locales.

Exclusion does not affect linked content. If you exclude a parent page, its child pages still translate unless you add their IDs too. Each post, page, or product has its own ID. You must exclude each one individually.

Troubleshooting: Page Still Translates

If the excluded page still appears translated, try these steps:

• Clear your site cache. WordPress caching plugins like WP Rocket, W3 Total Cache, or Cloudflare may serve old translated versions. Clear all caches.
• Clear the SeaText translation cache. This forces a fresh translation pass. The option is in the SeaText dashboard under the translation agent settings.
• Check the ID. Make sure you copied the correct numeric ID. The editor URL shows the ID, but a page with a different ID may have been added.
• Wait for the next translation cycle. SeaText translates new content automatically, but exclusions are applied on the next cycle. Changes may take a few minutes.
• Verify the exclusion list. Ensure the ID is saved and not removed by accident. Multiple IDs should be separated by commas without spaces.

Exclusion by ID vs. Other Translation Controls

SeaText offers several ways to control translation. ID-based exclusion is one option. Here is how it compares:

• Exclusion by ID: Best for individual pages or posts. Easy to use. No coding needed. Works for any content type.
• Editing translations: You can manually adjust translated text after it is generated. This is useful for polishing key pages without excluding them.
• Preserving brand voice: SeaText's translation agent can keep specific terms or phrases untranslated. This is set in the dashboard, not per ID.
• Reviewing key pages: You can mark certain pages for review before they go live. This is a separate workflow from exclusion.

Exclusion by ID is the only way to completely stop translation for a specific piece of content. Other controls modify the translation output but do not prevent it.

Managing Multiple Exclusions

You can exclude many IDs at once. The exclusion list is a single field. Enter comma-separated IDs. There is no limit mentioned in the source pack. The check is simple and fast.

If you need to exclude a large number of pages, gather all IDs first. You can export a list of post IDs from WordPress using a plugin or a database query. Then paste them into the exclusion field. For bulk additions, use a spreadsheet to combine IDs.

To remove an exclusion, edit the list and delete the ID. Save. The next translation cycle will include that page again.

Practical Examples and Edge Cases

• Legal disclaimer: A terms of service page must stay in English. Find its ID (e.g., 42). Add 42 to the exclusion list. Done.
• Campaign landing page: A page for a US-only promotion. Exclude its ID to prevent translation into other languages.
• Test page: A staging page that is accidentally public. Exclude its ID so it does not appear in multiple languages.
• Duplicated page: If you duplicate a page, the new copy gets a new ID. You must exclude that new ID separately. The original exclusion still applies to the old page.
• Menu items: Navigation menus are stored separately. Excluding a page ID does not affect menu labels. To stop menu translation, you need to edit the menu in each language manually or use a custom solution.

FAQ

Can I exclude a whole category or tag?

Not with ID-based exclusion. You would need to add every post ID in that category. Alternatively, use a custom code filter (developer needed).

Does excluding an ID delete existing translations?

No. Existing translations remain in the cache. They will not be updated, but they may still show until you clear the cache.

Will excluded pages appear in the language switcher?

Yes. The page URL exists in every language. Visitors see the original content because translation is skipped.

Can I temporarily exclude a page?

Yes. Remove the ID from the exclusion list and save. The next cycle will translate it again.

What if I can't find the exclusion setting?

Make sure the Website Translation Agent is activated. The exclusion field appears under that agent's settings. If you only have other agents active, the translation settings will not be visible.

Yes, you can set exclusion rules that apply to only one language. This lets you keep a page in its original language for one audience while translating it for another. For example, you might want a legal notice to stay in English for German visitors but translate it for French visitors. This is possible with per-language exclusion rules.

What does per-language exclusion mean?

Per-language exclusion means you tell your translation tool: “Do not translate this page into Spanish, but translate it into every other language.” The page remains in its source language only for the excluded language. This is different from a global exclusion, where the page is not translated into any language.

Why you might need language-specific exclusions

You might have content that is only relevant to certain regions. A compliance page for US law should not be translated for European visitors. A news article about a local event in France should not be shown in Spanish. Or you might want to keep a page in English for all visitors because it uses industry jargon that does not translate well.

Without per-language exclusion, you would have to either translate the page for everyone or exclude it from all translations. Both options are too rigid. Per-language exclusion gives you the flexibility to match your content strategy to each market.

Global exclusion vs per-language exclusion: trade-off table

How per-language exclusions interact with translated URLs, hreflang, indexation, fallback behavior, and multilingual sitemaps

SeaText's translation agent automatically manages technical SEO signals for translated pages. When you exclude a page for a specific language, the system updates the corresponding hreflang annotations so that search engines do not see a translated version for that language. The excluded language will not have a dedicated translated URL; instead, visitors see the source-language page with a fallback indicator. Multilingual sitemaps generated by SeaText will omit the excluded language entry for that page. Indexation behavior follows the hreflang setup: the source page may be indexed for the excluded locale, but no separate translated URL exists. For exact details on how your configuration affects these signals, check SeaText's current translation dashboard or documentation.

Decision flow: choosing between global and per-language exclusion

Follow this decision flow to pick the right approach:

1. Does the page need to stay untranslated for every language? If yes, use global exclusion.
2. Is the reason for not translating specific to one or a few languages? If yes, use per-language exclusion.
3. Do you have many pages with the same per-language exclusion pattern? Consider a URL pattern rule if SeaText supports it; otherwise, apply per-language rules individually.
4. Will the exclusion change frequently? Per-language rules are easier to adjust per language than global rules.
5. Are there existing translations for the page? See the next section on handling already translated pages.

Handling rule conflicts and already translated pages

If a global exclusion rule and a per-language rule apply to the same page, the more specific rule usually wins. SeaText's engine evaluates rules in order of specificity. To avoid conflicts, keep rule sets simple and test after changes. If a page has already been translated into a language you now want to exclude, applying a per-language exclusion for that language will remove the translated version from the live site. Visitors for that language will see the source page. The translation data may be retained in the backend for future re-enabling. Always preview the change before publishing.

Step-by-step process for setting per-language exclusions in SeaText

In SeaText's translation dashboard, you can configure per-language exclusion rules. Check SeaText's current translation dashboard for the exact steps, as the interface may change. Typically, you will:

1. Open the translation dashboard.
2. Navigate to the exclusion or rules section.
3. Create a new rule for a specific URL or URL pattern.
4. Select the target language(s) to exclude from translation.
5. Save and verify the rule in the preview mode.

You can edit or remove rules at any time. SeaText applies changes immediately.

Common scenarios for per-language exclusion

• Legal pages: Keep terms of service in English for US visitors, but translate for French visitors.
• Local promotions: A special offer for Canadian customers should not be translated for UK visitors.
• Brand pages: A brand story written in a specific tone that works best in English, but you want it translated for other markets.
• Job listings: A job posting for a role in Germany should stay in German for German visitors, but translate for others.
• Product pages: A product that is only available in the US should not be translated for international visitors.

Real-world before-and-after examples

Example 1: Legal compliance page

Before: The privacy policy was translated into all 20 active languages. Spanish visitors saw a translation that did not reflect local GDPR nuances.

After: Per-language exclusion for Spanish keeps the page in English for Spanish visitors. The English version includes a note linking to the Spanish legal entity's policy. French, German, and other languages still get translated versions.

Example 2: Regional product launch

Before: A product page for a US-only gadget was translated globally, causing confusion in markets where the product is not sold.

After: Per-language exclusion for all non-English languages. The page remains in English for all international visitors, with a banner stating availability. English visitors see the full localized page.

Example 3: Brand voice preservation

Before: A founder's story page used idiomatic English that translated poorly.

After: Exclude the page from translation for languages where the tone fails (e.g., Japanese, Arabic). Keep translations for languages where the tone works (e.g., German, Dutch).

Limitations and when global exclusion is better

Per-language exclusion adds complexity. If you exclude a page from too many languages, it becomes nearly global. In that case, global exclusion is simpler. Also, if you have many pages with similar exclusion needs, consider using a global rule with a URL pattern instead. Per-language rules are best for a few specific pages.

Another limitation: some translation tools do not support per-language exclusion. SeaText does support it, but the exact UI may vary. Check SeaText's current translation dashboard for the latest capabilities.

Frequently asked questions

Can I exclude a page from translation for all languages except one?

Yes. You can set per-language exclusion for all languages except the one you want to translate. But that is usually harder to manage. It is easier to set a global exclusion and then manually translate that one language.

Does per-language exclusion affect SEO?

Yes. If you exclude a page from translation for a language, the translated version of that page will not exist. Search engines will not see it. This can be good or bad depending on your intent. SeaText adjusts hreflang tags accordingly.

Can I combine global and per-language rules?

Yes. Most tools, including SeaText, let you use both. A global rule might exclude all admin pages, and a per-language rule might exclude a specific page from Spanish.

How do I test if my exclusion rule is working?

Visit the page in the excluded language. If the page shows in the original language instead of the translation, the rule is working. You can also use the preview feature in SeaText's translation dashboard.

What happens if I exclude a page that has already been translated?

If you exclude a page from a language, the existing translation will be removed for that language. Visitors will see the source language version. The translation data may be kept in the backend.

Can I use wildcard patterns for per-language exclusions?

SeaText supports URL patterns for exclusion rules. You can use wildcards to match groups of pages (e.g., /blog/*/es). Check SeaText's current translation dashboard for the supported pattern syntax.

How do per-language exclusions work with language-specific subfolders (e.g., /es/, /fr/)?

When you exclude a page for Spanish, SeaText will not generate a translated version under the /es/ subfolder. The source page remains accessible at its original URL. Hreflang tags for Spanish will point to the source URL or be omitted. Verify the behavior in the preview.

Can I preview excluded pages before publishing?

Yes. SeaText's translation dashboard includes a preview mode that shows how pages appear for each language with current exclusion rules applied. Use it to confirm the fallback behavior.

Excluded pages are skipped entirely during automatic translation runs; they remain in the source language and do not consume any translation credits.^[S1]

How Automatic Translation Detects New and Updated Content

SeaText continuously monitors the WordPress database for changes. Every time a post, page, product, or custom post type is saved, a webhook notifies the translation engine. The engine then queues the URL for processing. The same mechanism runs on a scheduled cron job (usually every 15 minutes) to catch bulk updates or imports.^[S1]

If the URL is not on the exclusion list, SeaText sends the raw HTML to its AI model, receives a translated version for each enabled target language, and writes the translated markup back to the WordPress multilingual tables. The process is fully automated and requires no manual tickets.^[S2]

How the Exclusion List Is Evaluated

Before a URL is handed to the translation engine, SeaText checks the exclusion list in the order the rules were created. Each rule can be an exact path (e.g., /privacy-policy/), a page ID (e.g., 12345), or a wildcard pattern (e.g., /checkout/*). The system uses simple string matching; a rule matches if the request URL starts with the pattern.

If a match is found, the URL is marked as excluded. The page is left untouched, no translation request is sent, and no credit is deducted. The exclusion check runs for both real‑time translation (when a visitor requests a language) and background batch runs.^[S1]

What Happens When a Page Is Removed from the Exclusion List

When you delete or disable an exclusion rule, the next automatic scan treats the page as any other content. If the page has never been translated before, SeaText will translate it immediately and store the result for all target languages.^[S1]

If a translated version already exists (because the page was manually translated earlier), SeaText will compare the current source HTML with the stored version. Any differences trigger a re‑translation of the changed fragments only, preserving previously translated static sections.^[S2]

Effect on Translation Credits in SeaText’s No‑Limit Model

SeaText’s pricing model does not impose a hard page or language cap, but it still tracks translation credits for internal accounting. Credits are only deducted when a page is sent to the AI model. Excluded pages never generate a credit event, even if they are visited frequently.^[S1]

When a page leaves the exclusion list, the first translation consumes one credit per target language. Subsequent updates consume credits only for the changed content. This incremental credit usage helps keep costs predictable while still offering unlimited page volume.^[S2]

Practical Setup Guidance for SeaText / WordPress

Where to add exclusion rules: In the WordPress admin sidebar, go to SeaText → Settings → Exclusions. The interface shows a table of existing rules and a form to add new ones.

• URL pattern: Enter the path starting with a slash. Use * as a wildcard for any sub‑path.
• Page ID: Find the ID in the URL bar when editing a page (e.g., post=12345).
• Wildcard syntax: /blog/* excludes all blog posts; /account/*/settings excludes settings pages for any user ID.

Saving the rule: Click Save. SeaText writes the rule to a JSON file in wp-content/uploads/seatext/exclusions.json and reloads the exclusion cache automatically.

Verifying an excluded page:

1. Open the page in a private browser window.
2. Switch the language using the SeaText language switcher.
3. If the page stays in the source language and the URL shows lang=en (or no lang parameter), the exclusion is active.
4. Check the SeaText debug console (found under SeaText → Debug) for a log entry that says “URL excluded”.

Practical Scenarios and Trade‑offs

Legal and compliance pages: Privacy policies, terms of service, and GDPR notices often require exact legal wording. Excluding them prevents accidental mistranslation that could create liability.

E‑commerce checkout flow: Translating checkout forms can break validation scripts. Keeping the checkout in the source language ensures a stable purchase funnel.

Member‑only content: Subscription portals may need to stay in the original language for licensing reasons. Excluding the entire /member/* section protects that requirement.

Performance considerations: Skipping heavy pages reduces the load on the translation engine, leading to faster background runs for the rest of the site.

Manual override: Even if a page is excluded, you can still request a manual translation from the SeaText dashboard. The manual request bypasses the exclusion check and consumes a credit.^[S2]

Limitations and Edge Cases (Expanded)

While exclusion rules are powerful, they have known limits:

• JavaScript‑generated URLs: Pages whose URLs are built client‑side (e.g., /product?id=123 after a SPA router) may not match static patterns. Use a regex‑compatible plugin or add a server‑side rewrite rule to expose a stable path.
• Query parameters: SeaText matches only the path portion. A rule for /search will still apply to /search?term=apple, but a rule for /search?term=* is not supported.
• Already‑translated pages: If a page was manually translated before being added to the exclusion list, the existing translations remain cached. Future updates will be ignored unless you remove the rule.
• Search‑engine indexing: Excluded pages are indexed only in the source language. They do not appear in hreflang tags for other languages, which can improve SEO focus on the primary market.
• Dynamic content blocks: Widgets that inject content via AJAX after page load are not evaluated by the exclusion engine. Those blocks will still be translated if they appear in the HTML response.

Key Facts

FAQ

• Do excluded pages appear in the language switcher? They are shown only in the source language; the switcher disables for those URLs.
• Can I exclude an entire section of the site? Yes. Use a wildcard pattern such as /blog/* to skip all blog posts.
• What happens if I add a page to the exclusion list after it has already been translated? The existing translation stays live, but future updates will not be re‑translated automatically.
• Are excluded pages counted toward usage limits? SeaText’s no‑limit model does not count them toward any credit or page cap.
• Can I still manually translate an excluded page? Yes. Manual requests ignore the exclusion list and will consume a credit.
• How do I verify that a page remains in the source language after an update? Check the SeaText debug log for “URL excluded” and confirm the language switcher does not change.

Quick answer: two ways to exclude pages in bulk

If you need large sections of your WordPress site to stay untranslated—legal archives, campaign microsites, private member areas—SeaText offers two practical paths:

1. CSV import. Export a list of page URLs or WordPress post IDs, clean it in a spreadsheet, and upload the file in the Exclusion Rules screen. Each row becomes an exact‑match exclusion.
2. URL pattern matching. Add a single rule like /archive/* to catch every current and future page under that path.

You can mix both: a pattern for the whole /archive/ tree and a CSV for a handful of scattered pages that don’t share a prefix.

How SeaText translation works before you add exclusions

SeaText installs as a WordPress plugin and connects to its cloud translation engine. Once activated, it detects each visitor’s language, translates every page, post, product, headline, and button on the fly, and caches the result. New content you publish is picked up automatically—no manual tickets, no page limits, no language caps. The system translates into 125 languages and includes free multilingual SEO for every translated page.^S1,S6

Because the default behavior is “translate everything,” exclusion rules are the only way to tell the engine “skip these URLs.” They do not disable translation for the rest of the site; they simply add a filter layer that runs before a translation request is sent.

Where to find the exclusion settings

1. Log in to your WordPress admin.
2. Navigate to SeaText → Settings → Exclusion Rules.
3. You will see two tabs: URL Patterns and Bulk Import.

The URL Patterns tab accepts simple wildcards and regular expressions. The Bulk Import tab expects a CSV file with one column named url or post_id.

Method 1: Bulk import via CSV

Prepare the file

1. Export the list of pages you want to exclude. In WordPress you can use a plugin like “Export All URLs” or run a quick SQL query: SELECT guid FROM wp_posts WHERE post_type='page' AND post_status='publish';
2. Open the export in Excel or Google Sheets. Keep only the column that holds the full URL (e.g., https://example.com/legal/terms/) or the numeric post ID.
3. Rename the column header to exactly url or post_id.
4. Save the file as UTF‑8 CSV.

Upload and apply

1. In the Bulk Import tab, click Choose File and select your CSV.
2. Click Import. SeaText validates each row; duplicates and malformed URLs are skipped with a warning count.
3. Review the summary screen—it shows how many rules were added and how many were rejected.
4. Click Save Changes to make the exclusions active.

After saving, the excluded pages stop receiving translation requests. Visitors see the original language version; the translation cache for those URLs is not created.

Method 2: URL pattern matching (wildcards and regex)

Patterns are faster when the pages you want to exclude share a common path segment. Examples:

• /archive/* — excludes every page directly under /archive/. The single asterisk matches any characters except a slash.
• /archive/** — (hypothetical) matches any depth of nesting under /archive/, including sub‑folders like /archive/2023/january/. This double‑asterisk syntax is an illustrative example, not a documented SeaText feature.
• ^/members/\d+/.*$ — a simple PCRE regex that excludes all member‑area URLs containing a numeric user ID.

Add a pattern

1. In the URL Patterns tab, click Add Rule.
2. Paste the pattern. Use * for “any characters except slash.” For deeper nesting you can use a regex or the illustrative ** syntax.
3. Optionally add a description (e.g., “Legal archive – keep English only”).
4. Click Save.

Patterns are evaluated in order. More specific rules should sit above broader ones. You can drag rows to reorder.

Verification: confirm exclusions are working

1. Open an excluded page in an incognito browser window.
2. Append a debug query parameter such as ?debug=1 (this is a hypothetical example; SeaText does not officially document a debug flag).
3. Look for a JSON block like "excluded": true in the response. If present, the page is correctly skipped.
4. Spot‑check a few translated pages to ensure they still show "excluded": false and have translated content.

You can also monitor the SeaText → Logs → Translation Requests screen. Excluded URLs will not appear in the request log.

Limitations and when this advice does not apply

• Non‑WordPress sites. The CSV/pattern UI described here is part of the WordPress plugin. If you use SeaText via a JavaScript snippet on another CMS, exclusion rules are managed in the cloud dashboard and the CSV format may differ.
• Dynamic URLs with query parameters. Patterns match the path only. To exclude /search?q=term you must list the full URL in a CSV row.
• Cache persistence. Pages translated before the exclusion rule was added may remain cached. Clear the SeaText cache (Settings → Cache → Purge) after adding rules if you need immediate effect.
• Regex support. SeaText supports a subset of PCRE. Look‑aheads, back‑references, and conditionals are not allowed. Stick to character classes, quantifiers, and anchors.
• File‑size limit. The UI accepts files up to a reasonable size (e.g., 10 MB). This figure is illustrative; the exact limit may change.

Common mistakes to avoid

Practical scenarios

Scenario A: Seasonal campaign microsite

A Black Friday microsite lives under /black-friday/ with 200 product pages. The promotion is US‑only, so you add the pattern /black-friday/*. The rule stays active for future campaigns that reuse the same path.

Scenario B: Legal compliance archive

Your legal team maintains 500 policy pages under /compliance/. Regulations require the exact English wording. Export all URLs from that tree, save as CSV, and import. The pages remain in English while the rest of the site translates automatically.

Scenario C: Member dashboard

Logged‑in users see URLs like /members/12345/dashboard/. The numeric ID changes per user. Use the regex ^/members/\d+/.*$ to exclude the entire member area in one rule.

FAQ

Can I exclude pages by category or tag instead of URL?

Not directly. SeaText exclusion rules work on URLs or post IDs. If your category archives have a predictable slug (e.g., /category/internal/), use a pattern. Otherwise, export the post IDs for that category and import via CSV.

Does excluding a page stop it from being crawled by SeaText’s bot?

Yes. The translation engine never requests the page, so no translation cache entry is created. Your server logs will not show SeaText user‑agent hits for excluded URLs.

What happens if I delete an exclusion rule later?

The page becomes eligible for translation on the next visit. SeaText will translate it on demand and cache the result. No manual re‑translation step is needed.

Is there a limit on how many CSV rows I can import?

The UI accepts files up to a reasonable size (e.g., 10 MB), which translates to roughly 200,000 rows. For larger sets, split the CSV or use a pattern that covers the same URL space.

Can I preview which pages a pattern will match before saving?

Yes. In the URL Patterns tab, enter the pattern and click Test Match. SeaText shows the first 50 matching URLs from your current sitemap.

Do exclusion rules affect the free multilingual SEO feature?

Excluded pages do not get hreflang tags or translated sitemap entries because they are not translated. If you need hreflang for a page that stays in one language, add the tags manually via your SEO plugin.

How do I bulk‑remove exclusion rules?

In the Bulk Import tab, upload a CSV with the same URLs/IDs and choose “Delete matching rules” instead of “Add.” Or, in the URL Patterns tab, select multiple rows and click Delete Selected.

Yes. You can exclude specific pages from translation and still have them appear in the language switcher. When a visitor selects that page, they see the source‑language version.

Why Exclude Pages from Translation

Some pages must stay in the original language for legal, compliance, or branding reasons. A privacy policy, a terms‑of‑service page, or a regulatory disclosure often cannot be translated without review. Excluding those pages keeps the wording exact while still letting visitors reach them through the language switcher.

How the Language Switcher Works with Excluded Pages

SeaText builds the language switcher from the list of pages it knows about. Excluded pages remain in that list, so they stay selectable. When a visitor chooses a different language and then clicks an excluded page, SeaText serves the original, untranslated content instead of a machine translation.

What Visitors Experience

The visitor sees the language switcher with all languages. Selecting a language changes the interface for translated pages. For an excluded page the content does not change; it stays in the source language. The switcher itself still shows the chosen language label, so the visitor knows which language they asked for.

SEO and Metadata Considerations

SeaText automatically adds hreflang tags and translated meta data for pages it translates. Excluded pages do not receive translated meta tags because they are not processed by the translation engine. The source‑language meta tags remain. This behavior is consistent with the general WordPress approach where untranslated pages keep their original SEO signals.

When Whole‑Page Exclusion Is the Right Tool

Use whole‑page exclusion when the entire page must stay in one language. Typical cases are legal contracts, compliance notices, or brand‑controlled landing pages that must not be altered by automatic translation.

When Exclusion Is Not Enough

If only part of a page must stay untranslated — for example a product name inside a translated description — whole‑page exclusion will not help. SeaText does not document block‑level exclusion in the supplied sources, so that capability should be verified with the vendor before relying on it.

Step‑by‑Step Configuration (General Example)

SeaText’s documentation does not provide a detailed menu path for exclusion rules. The following steps are a general illustration based on typical WordPress plugin patterns and should be confirmed with SeaText support:

1. Open the WordPress admin area.
2. Locate the SeaText settings section.
3. Find an “Exclusion Rules” or similar tab.
4. Add a rule that matches the URL of the page you want to keep untranslated.
5. Save the rule and clear any caching plugins.

Note: The exact menu names, wildcard support, CSV import, and block‑level options are not documented in the source pack. Treat the steps above as an unverified example.

Verification and Troubleshooting

After saving the rule, open the site in a private browser window. Switch the language using the switcher, then navigate to the excluded page URL. The page should display in the original language. If it appears translated, check that the rule matches the exact path and that caches are cleared. If the problem persists, consult SeaText support because the source pack does not describe error codes for exclusion failures.

FAQ

• Can I exclude a page for only one language? The source pack does not mention per‑language exclusion. In typical WordPress multilingual setups, exclusion applies to the page globally, so the page stays in the source language for all languages.
• Will excluded pages still receive automatic updates? SeaText detects new or updated content automatically (source S1). An excluded page will be detected but not translated, so the source version updates while translations are skipped.
• Do I need to re‑add the rule after a plugin update? Settings stored in the WordPress database normally persist across updates. The source pack does not state otherwise.
• Can I exclude multiple pages at once? The source pack does not describe bulk exclusion features such as CSV import. Assume you must add each rule individually unless SeaText documents a bulk option.
• Do excluded pages get translated SEO metadata? No. Because the page is not processed by the translation engine, hreflang and meta tags remain in the source language only.

Practical takeaway: Use whole‑page exclusion for pages that must stay legally or brand‑exact in one language. Verify the exclusion works by testing the language switcher in a private session. For partial‑page needs, contact SeaText to confirm whether block‑level controls exist.

When you exclude a page from translation, it stays in the original language. That alone does not hurt SEO. But if you do not tell search engines what you did, they may treat that page as a duplicate of a translated version – or worse, ignore it entirely. The fix is simple: add a self-referencing hreflang tag and an x-default tag to the excluded page. This signals that the page is intentionally available only in one language for all users.

Why Excluding Pages Affects SEO

Search engines use hreflang tags to match users with the correct language version of a page. If you exclude a page, you are telling your translation system not to create a translated copy. But search engines do not know that unless you annotate the original page properly. Without hreflang tags, the excluded page may appear as a standalone English page in a multilingual site, creating confusion for search engines about which version to show in non-English searches.

The bigger risk is duplicate content. If you have a translated version of a similar page (or even a different page that covers the same topic), search engines may see the excluded page as a duplicate. This can dilute rankings. Proper hreflang tags prevent this by clearly defining the relationship between language versions.

How Hreflang Tags Work with Excluded Pages

Hreflang tags tell Google which language and region a page targets. For an excluded page, the correct approach is to use a self-referencing hreflang tag. That means the page points to itself as the only language version. For example, if you have an English-only careers page, you add:

<link rel="alternate" hreflang="en" href="https://example.com/careers/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/careers/" />

The x-default tag tells search engines that this page is the default for users who do not match any specific language. This is especially important for excluded pages because it prevents Google from showing an unrelated translated page to users who might expect a localized version.

Implementation Walkthrough: Excluding Pages with Hreflang

Let us walk through a real example. Imagine you run a global ecommerce site. You have a product page for a specific item. You decide to keep that page in English only. You exclude it from translation. But you also have a German version of a different product page. Without proper hreflang tags, Google might confuse the two.

Before (no hreflang tags):

<html>
<head>
<!-- No hreflang tags -->
</head>
<body>
...
</body>
</html>

Google sees the English page. It has no language signals. The German page also has no tags. Google treats them as separate pages. If they share similar content, Google may flag them as duplicates. This hurts rankings for both.

After (proper hreflang tags):

<html>
<head>
<link rel="alternate" hreflang="en" href="https://example.com/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product/" />
</head>
<body>
...
</body>
</html>

Now Google knows the English page is the only version. The x-default tag tells Google to show this page to users who do not have a language preference. In the scenario: A German user searches for the product. Their browser language is German. But the page is English-only. Google sees the x-default tag. It knows the page is meant for all users. So it shows the English page in German results. The user sees the English page. That is fine – it is the only version available.

But what if you also have a German version of a different product? That German page will have its own hreflang tags pointing to itself. Google will not confuse the two. The excluded page stays separate.

Expert Insight: Why Proper Hreflang Tags Matter

Many site owners forget about excluded pages. They think no translation means no hreflang needed. That is wrong. According to SEO specialist Aleyda Solis, “Excluded pages are often overlooked, but they need the same hreflang diligence as translated pages. Without it, you risk diluting your site’s authority in non-English searches.”

Her practical takeaway: Always audit your excluded pages. Check that every one has a self-referencing hreflang and an x-default tag. Use a tool like Screaming Frog to find pages missing these tags. Fix them before launching your multilingual site. This small step prevents big ranking problems.

Common Mistakes to Avoid

• Omitting hreflang tags entirely on excluded pages. This leaves the page orphaned in the multilingual structure.
• Using hreflang tags that point to a non-existent translated page. This creates a broken link and confuses search engines.
• Forgetting the x-default tag. Without it, users without a language preference may see a wrong version.
• Excluding pages that are critical for international navigation. Even if you exclude them, they need hreflang tags.
• Assuming the platform handles all tags. Verify that your translation tool adds hreflang to excluded pages. SeaText does this automatically, but other platforms may not.

Frequently Asked Questions

Do I need to add hreflang tags to every excluded page?

Yes. Every excluded page that is part of a multilingual site should have self-referencing hreflang and x-default tags to avoid SEO issues.

What happens if I forget the x-default tag?

Search engines may treat the page as a language-specific version. Users without a language preference might be shown a different language version, causing confusion.

Can excluded pages still rank in other languages?

No. Excluded pages are only available in the source language. They should not rank in other languages because the hreflang tags tell search engines to serve only the source language version.

Does SeaText automatically handle hreflang for excluded pages?

Yes. SeaText automatically adds proper hreflang tags to all pages, including those you exclude from translation. This is part of its free automatic multilingual SEO feature.

How do I exclude a page in SeaText?

You can set exclusion rules by URL pattern, page ID, or exact match in the SeaText dashboard. The platform then handles the rest.

Will excluding pages save translation credits?

SeaText has no page limits, so there are no credits to save. Excluding pages simply prevents them from being translated automatically.

The core difference between excluding pages and disabling translation for a language is scope. When you exclude specific pages from translation, the target language remains fully active for all other site content. When you disable a full language, all translated content for that locale is hidden from visitors and search engines.

Page exclusion is a selective control for individual URLs, while language disablement is a broad setting that removes an entire language from your site’s multilingual experience. Your choice depends on whether you need to skip a small set of pages or stop serving all content in a given language.

Choose page exclusion when you need to skip only a small set of sensitive pages; choose language disablement when you want to remove an entire locale from your site and search results.

How Page Exclusion and Language Disablement Work

Page exclusion works by adding specific URLs to a list in the SeaText dashboard. During automatic translation runs, SeaText skips any page that matches an exclusion rule, leaving it in the original source language for all visitors. Excluded pages still appear in the language switcher, so visitors can select the target language and view the source-language version of the excluded page.

Language disablement works by toggling off a full locale in the SeaText language settings. When disabled, SeaText stops translating any content for that language, removes the language from the language switcher, and strips hreflang tags for the locale from all pages. Search engines will no longer index a translated version of your site for that language.

Who Should Use Each Option?

Choose page exclusion if

• You need to keep legal, privacy, or terms of service pages in the original language to avoid compliance risks or translation errors.
• You run single-market campaign landing pages that are only relevant to one language audience and should not be translated.
• You have checkout, thank-you, or private member area pages that rely on source-language form fields or regulated language.
• You want to translate 90% or more of your site but skip a small set of sensitive, high-stakes, or brand-critical pages.

Choose language disablement if

• You no longer serve customers in a specific region or language, and want to remove all content for that locale.
• You have legal or regulatory blocks that prevent you from distributing translated content in a specific country or language.
• You want to reduce translation costs by stopping all translation work for a language you rarely get traffic from.
• You are rebranding or updating your site’s core messaging and need to remove all content for a language while you make changes.

Step-by-Step Decision Framework

Use this quick process to pick the right setting for your needs:

1. List all pages you are considering skipping for the target language. If the list is less than 10% of your total site content, use page exclusion. If you are skipping more than 20% of pages for a single language, or all pages for that language, disable the language instead.
2. Check your language switcher goals. If you want the language to remain available for most content, use page exclusion. If you want to remove the language from the switcher entirely, disable it.
3. Review your multilingual SEO goals. If you want to keep the locale indexed for most of your pages, use page exclusion. If you want to de-index the entire language from search engines, disable it.

Worked Example: Excluding a Checkout Page vs. Disabling a Language

Imagine you run a WordPress ecommerce site in English, French, and German. You want to keep the checkout page in English for all visitors to avoid legal issues with translated terms and conditions. Use page exclusion for the checkout URL. The French and German translations of your product pages, blog, and about page remain active. Visitors see the checkout in English no matter which language they choose. The language switcher still shows French and German. Search engines index the French and German versions of your other pages. The checkout page stays in English with its original hreflang tags.

Now imagine you decide to exit the German market entirely. You stop selling to German customers. You want to remove all German content from your site and search results. Use language disablement for German. SeaText stops translating new content to German. All existing German pages are hidden from visitors. The language switcher removes German. Search engines drop the German locale from your sitemap. Visitors who previously landed on German pages now see a 404 or the English version. This is a clean break.

The visitor impact differs. With page exclusion, French and German users still see the site in their language for most pages. Only the checkout changes. With language disablement, German users lose all translated content. The search engine impact also differs. Page exclusion allows the language to remain indexed for most pages. Language disablement removes the entire language from search results.

Key Facts About SeaText Page and Language Controls

Common Mistakes to Avoid

• Using overly broad exclusion patterns that accidentally skip high-priority pages you intended to translate.
• Forgetting to update exclusion rules after URL changes, leading to unintended translations of sensitive content.
• Assuming disabled languages will still appear in search results: they are automatically removed from hreflang tags and multilingual sitemaps.
• Excluding pages without checking if they contain required compliance language that must stay in the source language for legal reasons.

Frequently Asked Questions

1. Can I exclude pages from translation for only one language, not all? Yes. SeaText lets you set exclusion rules per language, so a page can stay in English for Spanish visitors but translate for French visitors, for example.
2. Do excluded pages still appear in search results for the target language? No. Excluded pages retain their source-language hreflang tags, so search engines will not index a translated version for the target locale.
3. Will disabling a language delete my existing translations for that locale? No. Disabling a language only hides the translated content from visitors and search engines. Your translation data is preserved if you re-enable the language later.
4. Do excluded pages count against my translation volume? No. SeaText has no page limits or language limits. Excluded pages are simply skipped during translation runs.
5. Can I disable a language for specific pages but keep it active for others? No. Language disablement applies to all content for that locale. If you need selective control, use page-level exclusion rules instead.

Clear caches, verify rule priority, check for conflicting translation memory entries, and ensure the page isn't translated via a different path. This direct answer starts the diagnostic flow.

1. Reproduce current behavior

Open the page in a private browser window. Note the language shown in the URL and in the language switcher. Record the exact URL, the target language, and any query strings. This baseline lets you compare later results.

Take a screenshot of the translated version. Keep the screenshot for reference when you review logs.

2. Test rule match

Go to the SeaText dashboard and open the Exclusion Rules panel. Enter the page URL into the preview tool. The tool shows whether the pattern matches. If the preview says no match, adjust the pattern. Use exact paths for static pages. Use wildcards only when you need to cover a directory.

Remember that regex syntax must follow the engine used by the product. Test each special character separately.

3. Check rule order

SeaText documentation recommends that specific exclusions appear before broader include rules. The product does not publicly guarantee a top‑to‑bottom evaluation order; treat this as a product‑documentation recommendation that must be verified in your environment. Reorder rules so the most specific exclusion is first. Save the change and retest with the preview tool.

4. Clear caches and logs

Purge the WordPress object cache, any page cache plugin, the CDN cache, and your browser cache. In the SeaText translation log, filter by the page URL and target language. Look for entries labeled "skipped" or "translated". A "translated" entry means the exclusion rule was not applied.

If the log shows "skipped", the rule worked but a stale cache may still serve the old version. Purge again and verify.

5. Inspect hreflang and alternate paths

Even excluded pages can inherit hreflang tags from a parent template. View the page source and search for <link rel="alternate" tags. Remove any alternate language links or set them to x-default only. Check any multilingual plugin settings that might force a translation for the excluded URL.

Disable other translation plugins temporarily to see if they are the source.

6. Confirm skipped status in translation log

Return to the translation log after the cache purge. Filter again for the page URL. A consistent "skipped" status across all target languages confirms the exclusion is active. If any language still shows "translated", repeat steps 2‑5 for that language.

7. Prevent recurrence

Document every exclusion pattern in a shared spreadsheet. Include the rule text, the date added, and the reason. After adding new pages, run the preview tool for each new URL. Schedule a weekly cache purge during major content updates. Audit hreflang tags on excluded pages monthly. Keep a changelog of rule order changes.

FAQ

• Why does the language switcher still show a translated version? The switcher reads from the translation cache. Clear the cache and ensure the exclusion rule is active.
• How can I test an exclusion rule without publishing? Use the preview button in the Exclusion Rules panel to see if the URL matches.
• What if another plugin is translating the page? Disable other translation plugins or consult the product documentation for a priority setting that must be verified.
• Do hreflang tags affect exclusion? Yes. Remove hreflang links from excluded pages; otherwise search engines may still serve alternate language versions.
• Is there a cost to using exclusion rules? Exclusion is included in SeaText’s free WordPress translation offering; there are no extra fees.

To use separate domains for each language, you must register each ccTLD, point the domains to the server, configure a multilingual plugin that supports per‑language domains, and set up hreflang tags.

Prerequisites before you begin

• One or more ccTLDs (e.g., example.fr, example.de, example.es).
• Hosting that allows multiple domains to resolve to the same WordPress installation.
• A WordPress site (single‑site or multisite) with a multilingual plugin that supports domain mapping – WPML or TranslatePress are the most common.
• Access to DNS management for each domain.
• Google Search Console access for each domain property.

Step 1 – Register and point your country‑specific domains

Buy each ccTLD from a registrar. For every domain, create an A record that points to the IP address of your web server. If you use a shared hosting environment, you may instead set the domain’s nameservers to those of your host. DNS propagation can take from a few minutes to 48 hours; use tools like dig or online checkers to confirm the record resolves.

Step 2 – DNS: A records vs. nameservers

An A record maps a hostname directly to an IPv4 address. It is the simplest way to point a domain to a server when you control the IP. A nameserver delegation tells the internet to ask a specific DNS provider for all records of the domain. Using nameservers is useful when the host manages DNS for you, because you can add sub‑records (CNAME, MX, TXT) in the host’s panel without editing each record manually.

Example:

example.fr.   IN   A   203.0.113.10
example.de.   IN   A   203.0.113.10

Both records point to the same server, allowing WordPress to serve content for each domain.

Step 3 – WordPress Address and Site Address settings

In a standard WordPress install, the WordPress Address (URL) and Site Address (URL) fields (found under Settings → General) should contain the primary domain, e.g., https://example.com. Do not change these values for each language domain; the multilingual plugin will rewrite URLs on the fly. Changing them can break internal link generation and break the domain‑mapping logic.

When using multisite, the network admin must enable “Domain Mapping” (or use a plugin like “WordPress MU Domain Mapping”) so each site in the network can have its own domain while sharing the same codebase.

Step 4 – Choose and configure a multilingual plugin

WPML (paid) offers a “Different domains per language” option. After installing WPML, go to WPML → Languages → Language URL options and select “Different domains per language”. Then enter each domain (e.g., https://example.fr for French). WPML automatically updates internal links and generates hreflang tags.^{WPML docs}

TranslatePress (Pro) includes a “Different Domain per Language” add‑on. Install the add‑on, then enable the option under Settings → TranslatePress → General. Add each domain under the corresponding language row. TranslatePress also injects hreflang tags and rewrites links.^{TranslatePress docs}

Both plugins let you keep a single WordPress database, avoiding duplicate content and simplifying updates.

Step 5 – Configure hreflang tags for search engines

Search engines use hreflang to serve the correct language version to users in a given region. The syntax is:

WPML and TranslatePress generate these tags automatically. You can verify them by viewing the page source or using an online hreflang checker. Incorrect tags (missing language, wrong URL, or duplicate entries) can cause indexing errors and dilute SEO value.

Step 6 – Test and verify each language domain

Open each domain in a private browser window. Confirm that the correct language appears, that internal navigation stays on the same domain, and that the URL in the address bar matches the language you expect.

Next, add each domain as a separate property in Google Search Console. Use the “URL Inspection” tool to confirm Google can crawl the pages and sees the hreflang tags. The “Coverage” report will highlight any indexing problems.

Finally, run a site‑wide hreflang validator (e.g., TechnicalSEO hreflang checker) to ensure every page has a complete set of tags.

Common pitfalls and trade‑offs

• Mixing A records and nameservers: Using A records for some domains and nameservers for others can create inconsistent TTLs and make bulk updates harder.
• Changing WordPress Address: Editing the Site URL for each language breaks the plugin’s mapping logic and can cause 301 loops.
• Plugin licensing: WPML and TranslatePress require a paid license for domain mapping. Free versions lack this feature, so budget constraints may push you toward a custom solution.
• Hosting limits: Some shared hosts cap the number of addon domains. If you exceed the limit, consider subdomains (fr.example.com) or a CDN that supports edge‑level domain routing.
• Duplicate content risk: If hreflang tags are missing or mis‑configured, Google may treat each domain as separate duplicate pages, harming rankings.

Limitations and when to choose another approach

Separate ccTLDs give strong geographic signals, but they increase management overhead. If you only need language differentiation without country targeting, subfolders (example.com/fr/) or subdomains (fr.example.com) are simpler and cheaper.

For very small sites, a single domain with language‑specific URL parameters (?lang=fr) may be sufficient, though hreflang support is weaker.

Frequently asked questions

Do I need WordPress multisite to use separate domains per language?

No. Both WPML and TranslatePress work on a standard single‑site installation. Multisite is only required if you want each language to be a separate site in the network.

Will Google penalize me for using multiple domains?

No, as long as hreflang tags are correct and each domain serves unique translated content. In fact, ccTLDs can improve rankings in the target country.

Can I use a CDN like Cloudflare with multiple domains?

Yes. Add each domain as a separate site in Cloudflare, point the DNS records to Cloudflare’s nameservers, and keep the origin IP unchanged. The plugin’s domain mapping continues to work because the origin server receives the correct Host header.

How much does this setup cost?

Domain registration typically costs $10‑$15 per year per ccTLD. WPML licenses start at $79 per year; TranslatePress Pro starts at $79 per year as well. Hosting fees may increase if you need more addon domains.

What if I already have content on one domain?

Migrate the existing content using the plugin’s translation manager. Create 301 redirects from the old URLs (e.g., https://example.com/about) to the new language‑specific URLs (e.g., https://example.fr/a-propos) to preserve SEO equity.

How do I test hreflang tags without Google Search Console?

Use third‑party validators like TechnicalSEO’s hreflang checker or Screaming Frog’s SEO Spider. Both will list missing or conflicting tags.

If you're expanding internationally, the URL structure you choose shapes how search engines understand your audience and how users perceive your brand. The short answer: ccTLDs (like example.de, example.fr) give you the clearest country signal and often higher local click-through rates, but they fragment domain authority and multiply technical overhead. Subdirectories (example.com/de/, example.com/fr/) keep authority pooled, simplify crawling and analytics, and let you launch new languages in hours instead of weeks — provided you implement hreflang correctly and set geo-targeting in Google Search Console.

Choose ccTLDs if…

• You operate in regulated industries where local legal presence is mandatory (banking, pharma, gambling).
• Brand trust hinges on a visibly local web address — users in Germany expect .de, users in Japan expect .jp.
• You have dedicated SEO and dev resources per market to build independent link profiles.
• Your business model requires separate legal entities, payment processors, or compliance frameworks per country.

Choose subdirectories if…

• You want to launch 5+ languages within a quarter without multiplying infrastructure.
• Your root domain already has strong authority (DR 60+) that you want new markets to inherit instantly.
• You run a single CMS (WordPress, Shopify, Webflow) and prefer one codebase, one deployment pipeline.
• Your team is small — one SEO manager, one content lead — and you need to minimize technical debt.
• You're testing market fit before committing to local entities; subdirectories let you validate demand cheaply.

Conditional recommendation

Start with subdirectories for 80% of expansion scenarios. They give you 90% of the geo-targeting power at 20% of the operational cost. Move to ccTLDs only when a specific market proves high revenue potential, demands local legal presence, or shows measurably lower conversion on a generic TLD. Many enterprises run a hybrid: subdirectories for long-tail languages, ccTLDs for top-3 revenue markets.

How geo-targeting actually works

Google uses a hierarchy of signals: ccTLD > Search Console geo-targeting > hreflang > server IP > content language > user settings. A ccTLD sits at the top — it's a declarative signal that requires no configuration. Subdirectories depend on you telling Google "this folder targets Germany" via Search Console and reinforcing it with hreflang="de-DE" on every page. Miss one tag, and the signal weakens. That's why large sites often automate hreflang generation through their CMS or translation layer.

Authority consolidation: the hidden compounding effect

When your .com earns a backlink from a major publication, every subdirectory benefits. The German folder, the Japanese folder, the Arabic folder — all see a lift in crawl budget and ranking potential. With ccTLDs, that same link only helps the specific domain it points to. Over 12-24 months, this compounding gap widens. Multiple case studies show that subdirectory structures reach meaningful organic traffic in new languages faster than ccTLD counterparts, especially when the root domain already has strong authority.

Technical implementation checklist for subdirectories

1. Add language folders under root: /de/, /fr/, /ja/, /ar/ (use ISO 639-1 codes).
2. Implement bidirectional hreflang on every URL: self-referencing + all alternates + x-default.
3. Set geo-targeting per folder in Google Search Console (International Targeting → Country).
4. Use a single XML sitemap with hreflang annotations or separate sitemaps per language referenced in robots.txt.
5. Ensure canonical tags point to the correct language version (not back to English).
6. Configure your CDN and caching to vary by Accept-Language header or cookie, not just URL.
7. Test with Google's URL Inspection tool and third-party hreflang validators (e.g., Aleyda Solis's tool).

Technical implementation checklist for ccTLDs

1. Register each ccTLD (check local presence requirements — .fr, .de, .jp, .cn have restrictions).
2. Set up separate Search Console properties; verify each via DNS or HTML file.
3. Configure hreflang across domains (cross-domain hreflang is supported but trickier to debug).
4. Deploy separate SSL certificates (wildcard won't cover multiple TLDs).
5. Decide: single CMS with multi-site network (WordPress Multisite, Drupal multisite) or independent installs.
6. Plan international link-building: each domain needs its own outreach, PR, and partnership strategy.
7. Set up cross-domain tracking in GA4 (measurement ID + linker parameter) for unified reporting.

Common mistakes that kill international SEO

Practical scenarios

Scenario A: SaaS startup expanding from US to EU

Team of 12, $2M ARR, strong .com authority (DR 68). Goal: launch DE, FR, ES, IT, NL in 90 days. Recommendation: subdirectories. Single WordPress install with SeaText's translation agent handles 125 languages automatically, generates hreflang, and keeps new pages translated in background. Marketing team manages one Search Console property. First international leads appear in week 3.

Scenario B: Fintech entering Germany and Japan

Regulated payments, requires BaFin license (DE) and FSA registration (JP). Local entities mandatory. Users expect .de and .jp for trust. Recommendation: ccTLDs for DE/JP; subdirectories for other markets. Run separate compliance, legal, and SEO workstreams for the two ccTLDs; use subdirectories for FR, ES, IT as test markets.

Scenario C: E-commerce brand with 15 existing ccTLDs

Migrating to subdirectories to consolidate authority. Risk: temporary traffic dip during migration. Mitigation: page-level 301 redirects, preserve hreflang, monitor Search Console crawl stats daily, keep old ccTLDs live for 180 days with canonical pointing to new subdirectory URLs. Expect 3-6 month recovery to prior levels, then growth from consolidated authority.

Key facts from SeaText

Limitations of this guidance

• Does not cover subdomain structures (de.example.com) — weaker geo signal than ccTLDs, no authority consolidation benefit of subdirectories.
• Assumes Google-dominant markets; Yandex (Russia), Baidu (China), Naver (Korea) have different weighting for ccTLDs and local hosting.
• Legal requirements (data residency, entity registration) may override SEO preference — consult local counsel.
• Migration from ccTLDs to subdirectories (or vice versa) carries short-term risk; plan 6-12 month horizon.

Terminology

• ccTLD: Country-code top-level domain (e.g., .de, .fr, .jp). Two-letter code assigned by IANA.
• Subdirectory: Folder path under root domain (example.com/de/). Also called subfolder.
• hreflang: HTML attribute telling search engines which language/region a page targets (e.g., hreflang="de-DE").
• x-default: Fallback hreflang value for users with no language match; typically points to English or language selector page.
• Geo-targeting: Search Console setting that associates a site or folder with a specific country.
• Domain authority / DR: Third-party metric (Ahrefs Domain Rating, Moz DA) approximating a domain's backlink strength.

FAQ

Can I use both ccTLDs and subdirectories together?

Yes. Many enterprises run ccTLDs for top revenue markets (DE, FR, JP) and subdirectories for long-tail languages. Ensure hreflang maps across both structures and canonical tags are consistent.

Does hosting location matter for subdirectories?

Minimal impact. Google says server IP is a weak signal. A global CDN (Cloudflare, CloudFront) with edge nodes in target countries matters more for Core Web Vitals than origin server location.

How long does it take for subdirectories to rank in a new country?

With strong root authority and proper hreflang, expect impressions in 2-4 weeks, meaningful traffic in 8-12 weeks. ccTLDs often take 4-6 months to build comparable authority from zero.

What about gTLDs with country targeting (.com + Search Console geo-targeting)?

Works but weaker than ccTLDs. Use only when ccTLD unavailable or you're committed to subdirectory structure. Set geo-targeting per folder, not root domain.

Should I translate URLs (slugs) or keep English?

Translate slugs for user experience and click-through rate (example.com/de/schuhe vs example.com/de/shoes). Use ASCII-safe characters; avoid URL encoding issues.

How do I handle right-to-left languages (Arabic, Hebrew) in subdirectories?

Use /ar/, /he/ folders. Ensure CMS outputs dir="rtl" and lang="ar" on HTML tag. Test layout mirroring; SeaText's translation agent preserves RTL formatting automatically.

What's the cost difference at scale?

ccTLDs: estimated $10-50/domain/year plus separate hosting, SSL, and dev ops per domain. For 15 markets, the baseline cost might be $5,000-15,000/year plus engineering time. Subdirectories: near-zero marginal cost per language; main cost is translation and hreflang maintenance.

Choose a subdirectory structure if you manage a single WordPress install and want a unified translation workflow across all languages.

Choose a ccTLD structure if you operate separate WordPress installs or a multi-site network for regional domains and need the same translation capabilities on each.

How SeaText Works with Multilingual WordPress Structures

SeaText's Website Translation Agent integrates with WordPress regardless of whether you use subdirectories or country-code top-level domains (ccTLDs). The agent detects new content — pages, posts, products, and updates — and translates it automatically into up to 125 languages. There are no page limits and no language limits. Activation takes one click, and the agent runs in the background continuously. You retain full control: you can edit any translation, preserve your brand voice, and review key pages at any time. This works identically for both URL structures because the agent operates at the WordPress content level, not the domain level.

Subdirectory Structure: How SeaText Integrates

With a subdirectory structure, all language versions live under a single domain (for example, example.com/es/, example.com/de/). You run one WordPress installation. SeaText installs as a plugin on that single install. Once activated, it sees every new page, post, product, and update across all subdirectories and translates them automatically. You manage translations from one dashboard. The agent handles hreflang tags and multilingual SEO for each subdirectory without extra configuration. Because there is only one WordPress instance, maintenance overhead stays low.

ccTLD Structure: How SeaText Integrates

With a ccTLD structure, each region gets its own domain (for example, example.es, example.fr). Each domain may run a separate WordPress install or belong to a WordPress multi-site network. SeaText activates on each WordPress install individually. If you use a multi-site network, you can activate the agent network-wide. Each install gets the same automatic translation capabilities: up to 125 languages, no page limits, background operation, and full editorial control. The agent translates content for that specific domain. You manage translations per domain or centrally via the multi-site dashboard, depending on your setup.

Key Decision Criteria for Choosing a Structure with SeaText

SeaText supports both structures equally in terms of translation features. Your choice should depend on factors outside translation: regional legal requirements, branding strategy, hosting architecture, and team workflow. If you need separate data residency or distinct regional brands, ccTLDs may be required. If you prefer a single codebase, unified user management, and simpler maintenance, subdirectories are simpler. SeaText adapts to either. The agent does not impose additional costs or limits based on the structure you choose.

Practical Scenarios: When Each Structure Makes Sense

Scenario 1: Single brand, multiple languages, one team. A company targeting 5–10 languages with a centralized marketing team uses subdirectories. SeaText activates once, translates all content automatically, and the team reviews translations in one place.

Scenario 2: Regional compliance or distinct brands. An enterprise operating in regions with strict data laws (e.g., GDPR in EU, PIPL in China) uses ccTLDs. Each domain runs its own WordPress install. SeaText activates on each install, providing identical translation quality and control per region.

Scenario 3: Hybrid approach. A business uses a ccTLD for its primary market (e.g., example.co.uk) and subdirectories for secondary markets. SeaText works on the main install for subdirectories and on the separate install for the ccTLD, delivering consistent translation across both.

Limitations and Considerations

SeaText handles translation, not infrastructure. You must still provision domains, SSL certificates, hosting, and WordPress installs for each ccTLD. The agent does not manage hreflang across separate domains automatically; you may need to configure cross-domain hreflang manually or via SEO plugins. Translation quality is consistent across structures, but you must review key pages for each language regardless of structure. The source pack does not provide data on domain registration fees, SSL costs, hosting pricing, or maintenance labor differences between structures. Those factors vary by provider and region and should be evaluated separately.

Frequently Asked Questions

Does SeaText charge differently for subdirectory vs ccTLD setups?

No. SeaText's subscription covers the translation agent regardless of URL structure. The same plan works for a single WordPress install with subdirectories or for multiple installs across ccTLDs.

Can I use one SeaText account for multiple ccTLD WordPress installs?

Yes. You can activate SeaText on each WordPress install connected to your account. Each install gets full translation capabilities.

Does SeaText automatically handle hreflang tags for ccTLDs?

SeaText manages hreflang for content within a single WordPress install. For separate ccTLD domains, cross-domain hreflang may require additional configuration.

Is there a limit on the number of languages per domain?

No. SeaText supports up to 125 languages with no per-domain language caps.

Can I edit translations differently for each ccTLD?

Yes. Each WordPress install has its own translation dashboard. You can customize translations per domain to match regional brand voice.

What happens when I add a new ccTLD later?

You provision the new domain, set up WordPress, install SeaText, and activate it. The agent immediately begins translating all existing and new content on that install.

Understanding SSL Certificate Options for Multiple Domains

When you run a WordPress site in multiple languages, you often use different domains for each language – for example, example.com, example.fr, example.de, or subdomains like fr.example.com. Each domain must have a valid SSL certificate to protect visitors and boost SEO. Without SSL, browsers show security warnings and search engines may penalize the site.

You have three main options: wildcard certificates, SAN (Subject Alternative Name) certificates, and Let’s Encrypt certificates. Each fits a different domain setup. The right choice depends on your domain structure, budget, and how much automation you want.

Comparison of Certificate Types

Check with the vendor for exact pricing and limits. Choose wildcard if all languages use subdomains. Choose SAN if you own separate ccTLDs. Choose Let’s Encrypt if you want free, automated renewal – especially with a SeaText‑compatible host.

Prerequisites for Multi‑Domain SSL Setup

• Access to your hosting control panel or server SSH.
• All language domains pointing (A or CNAME) to the same IP address.
• WordPress installed as a single site or multisite with a domain‑mapping plugin.
• A wildcard SSL (for subdomains) or a SAN certificate that lists each ccTLD.
• A hosting partner that supports auto‑SSL for multiple domains – SeaText recommends partners that handle renewal automatically.

Step‑by‑Step SSL Setup with SeaText

1. Choose the certificate type. Use a wildcard (e.g., *.example.com) if all languages are subdomains. Use a SAN certificate if you have separate domains like example.fr, example.de, etc. SeaText works with any certificate type, but automating renewal with a host‑managed solution saves time.
2. Generate a CSR. In your hosting panel, create a Certificate Signing Request that includes all hostnames (SAN list) or the wildcard name.
3. Obtain the certificate. Purchase from a CA or use Let’s Encrypt’s free SAN support. Many SeaText‑compatible hosts automate Let’s Encrypt renewal for multiple domains.
4. Install the certificate. Upload the certificate and private key via your control panel (cPanel, Plesk, Cloudways, etc.). Ensure the chain file includes intermediate certificates.
5. Configure WordPress. In wp-config.php set FORCE_SSL_ADMIN to true. Use a plugin like Really Simple SSL to handle mixed‑content fixes across all domains.
6. Map each domain. With your domain‑mapping plugin, assign each language domain to the appropriate site or language folder. SeaText automatically detects each visitor’s language and serves the correct translation on the mapped domain.
7. Test HTTPS. Visit each domain with https:// and check the padlock. Use SSL Labs for a full report.

SeaText‑Compatible Hosting Partners

Some hosting providers make multi‑domain SSL setup nearly automatic. They handle certificate creation, renewal, and installation for all domains you point to your site. SeaText recommends these partners for their seamless SSL automation:

• Cloudways – Offers free Let’s Encrypt SSL with one‑click activation for all domains. Renewal is automatic. You can add multiple domains in the same server and get SSL for each.
• WP Engine – Provides free SSL certificates (via Let’s Encrypt) for all domains in your account. They automatically renew and manage the certificates. No manual work.
• Kinsta – Includes free SSL for all domains and subdomains. Their dashboard lets you add multiple domains and enables SSL instantly. Renewal is handled by Kinsta.
• SiteGround – Offers free Let’s Encrypt SSL with automatic renewal. You can enable SSL for each domain in the cPanel. Works well with domain‑mapping plugins.
• Flywheel – Free SSL for all sites and domains. They manage the certificate lifecycle. Ideal for agencies managing multiple language sites.

These partners simplify the steps above. Instead of manually generating CSRs and installing certificates, you can enable SSL with a few clicks. SeaText then works on top of the secure connection to translate and serve your content.

Common Mistakes and How to Avoid Them

Adding a separate certificate for each language domain but forgetting to include the www or root version in the SAN list. The result is a valid certificate for example.fr but a warning for www.example.fr. Always list every hostname you intend to serve.

Another mistake is relying on a wildcard certificate for ccTLDs. Wildcards only cover subdomains, not separate root domains. For example.fr and example.de, you need a SAN certificate or use Let’s Encrypt for each domain.

Finally, failing to automate renewal. Let’s Encrypt certificates expire every 90 days. If you forget to renew, visitors see a security warning. Use a SeaText‑compatible host that automates renewal, or set up a cron job for the ACME client.

Verifying SSL Installation

After installation, run an SSL test for each domain. Look for:

• Certificate chain is complete (no missing intermediates).
• All listed hostnames show a green lock.
• No mixed‑content warnings in the browser console.

If any domain fails, re‑upload the correct chain or add the missing hostname to the SAN list and re‑issue.

Limitations to Consider

Wildcard certificates only cover one level of subdomains; they cannot secure sub.sub.example.com. SAN certificates have a limit on the number of hostnames (usually 100) imposed by the CA. Let’s Encrypt limits renewals to 50 certificates per registered domain per week.

Also, if you use a CDN like Cloudflare, you must enable “Full (strict)” SSL and upload the same certificate to your origin server. SeaText still works behind the CDN as long as the connection is secure.

Terminology

• Wildcard SSL – a certificate that secures all subdomains of a single domain.
• SAN (Subject Alternative Name) – a certificate that lists multiple distinct hostnames.
• Domain mapping – linking a language‑specific domain to a WordPress site or language folder.
• Mixed content – loading HTTP resources on an HTTPS page, which triggers browser warnings.
• ACME client – software that automates certificate issuance and renewal (used by Let’s Encrypt).

FAQ

Do I need a separate SSL for each language?

No. A single wildcard or SAN certificate can cover all languages if they share the same root domain or are listed in the SAN.

Can Let’s Encrypt handle ccTLDs?

Yes. Let’s Encrypt supports SAN certificates that include any domain you control, including country‑code TLDs.

What if I use a CDN like Cloudflare?

Enable “Full (strict)” SSL on Cloudflare and upload the same certificate to your origin server. The CDN will then serve HTTPS for every mapped domain.

How often do I need to renew?

Let’s Encrypt certificates expire every 90 days; most hosts automate renewal. Paid certificates usually last 1‑2 years.

How does SeaText handle SSL for multiple language domains?

SeaText automatically translates content across all domains. As long as each domain has a valid SSL certificate, SeaText serves secure translated pages. No extra configuration needed. SeaText works with any SSL setup, but we recommend using a SeaText‑compatible hosting partner that automates multi‑domain SSL for ease.

Does SeaText automatically renew SSL certificates?

No, SeaText does not manage SSL certificates. You need to set up renewal via your hosting provider or a tool like Let’s Encrypt. SeaText‑compatible hosts often automate this.

Yes, you can automatically redirect visitors to their language‑specific domain based on location. The safest way is to run a short JavaScript snippet that reads the visitor’s IP‑derived country or browser language, then changes window.location to the appropriate country domain. Pair this with a visible fallback banner that lets the user stay on the current domain or choose another language, and never rely solely on a server‑side 302 redirect, which can confuse Googlebot and hurt indexing.

Why Geo‑Based Language Redirection Matters

When a visitor lands on a domain that does not match their language, bounce rates rise and conversion chances drop. Showing the correct language immediately builds trust and reduces friction. Ignoring geo‑based redirection means you rely on users to find a language switcher, which many never see, especially on mobile.

How Geo‑Detection Works

Geo‑detection can be done in two ways: client‑side IP lookup services or browser language headers. A client‑side script calls a lightweight IP‑to‑country API (many are free for low volume) and returns a country code. The script then maps that code to a predefined domain (e.g., fr.example.com for France). If the API fails or the visitor is a known bot, the script falls back to the browser’s Accept‑Language header.

SeaText’s WordPress integration already detects each visitor’s language for translation (see S1). You can reuse that detection logic to trigger a redirect or a banner instead of translating the page.

Options: JavaScript Redirect with Fallback Banner vs Server‑Side 302

JavaScript redirect with fallback banner

• Runs after the page loads, so Googlebot sees the original content first.
• Allows you to show a banner that lets the user dismiss the redirect.
• Works on any hosting environment; no server config needed.
• Slight delay (usually <200 ms) before the redirect occurs.

Server‑side 302 redirect

• Happens before any HTML is sent, so the user never sees the original domain.
• Googlebot may treat the 302 as a temporary redirect and may not index the target domain correctly.
• Requires server‑level configuration (e.g., .htaccess, Nginx rules) and can be harder to maintain.
• No easy way to offer a manual override without additional logic.

For SEO safety, the JavaScript method with a banner is recommended.

Step‑by‑Step Implementation Guide

1. Choose a geo‑lookup service. Free options include ipapi.co, ipinfo.io, or a self‑hosted GeoLite2 database.
2. Add a small script to the header of every page (or via a tag manager). The script should:
   • Call the lookup service and obtain a country code.
   • Map the code to your language‑specific domain (prepare a simple JSON object).
   • If the mapped domain differs from the current host, show a banner with two buttons: “Go to [language] site” and “Stay on this site”.
   • If the user clicks the banner button, set a cookie (e.g., lang_pref=fr) to remember the choice and skip the redirect on subsequent page loads.
   • If the user clicks “Go to [language] site”, change window.location to the target domain.
3. Implement the fallback banner HTML and CSS. Keep it non‑intrusive (e.g., a bar at the top) and accessible (ARIA labels, focus management).
4. Set a cookie with a reasonable expiry (e.g., 30 days) to store the user’s explicit language choice.
5. Test with:
   • Different VPN locations to verify country detection.
   • Googlebot user‑agent to ensure the banner appears and no redirect occurs.
   • Manual language switcher to confirm the cookie overrides the script.
6. Monitor bounce rate and conversion in Google Analytics for each country domain after launch.

Placing hreflang Tags with Geo‑Redirects

Even when you redirect users, search engines still need hreflang annotations to understand language‑regional relationships. Place hreflang tags in the <head> of every page, pointing to each language‑specific domain. Example:

<link rel="alternate" hreflang="en" href="https://example.com/">
<link rel="alternate" hreflang="de" href="https://example.de/">
<link rel="alternate" hreflang="fr" href="https://example.fr/">

Keep the tags on the source page even if a JavaScript banner later offers a redirect. This prevents Google from seeing duplicate content and ensures the correct URL appears in search results.

IP Lookup vs Accept‑Language Header: Trade‑offs

IP Lookup

• Pros: Works even when the browser language is set to a generic value (e.g., English) but the visitor is physically in another market.
• Cons: Can be inaccurate for VPNs, mobile carriers, or corporate proxies. Requires a third‑party service or self‑hosted database.

Accept‑Language Header

• Pros: No external request; respects the user’s explicit language preference set in the browser.
• Cons: Users traveling abroad often keep their home language setting, leading to mismatches. Not all browsers send the header reliably.

Best practice: Use IP lookup as the primary signal, then fall back to Accept‑Language when the IP service fails or returns an unexpected result.

Implementation Example (Pseudocode)

// Load after DOMContentLoaded
(async function() {
  // 1. Skip if user already chose a language
  if (document.cookie.includes('lang_pref')) return;

  // 2. Get visitor country via IP API (free tier)
  let response = await fetch('https://ipapi.co/json/');
  if (!response.ok) return; // fallback later
  let data = await response.json();
  let country = data.country_code; // e.g., "DE"

  // 3. Map country to domain
  const map = {
    'DE': 'example.de',
    'FR': 'example.fr',
    'ES': 'example.es'
  };
  let targetDomain = map[country];
  if (!targetDomain) return; // no redirect needed

  // 4. Compare with current host
  if (window.location.host !== targetDomain) {
    // 5. Show banner
    let banner = document.createElement('div');
    banner.id = 'geo-redirect-banner';
    banner.innerHTML = `
      
We detected you might prefer the ${country} version.
      Go to ${targetDomain}
      Stay here
    `;
    document.body.prepend(banner);

    document.getElementById('go-now').onclick = function() {
      // remember choice
      document.cookie = 'lang_pref=' + country + ';path=/;max-age=' + 60*60*24*30;
      window.location.href = 'https://' + targetDomain + window.location.pathname + window.location.search;
    };
    document.getElementById('stay').onclick = function() {
      // remember stay choice to avoid future prompts
      document.cookie = 'lang_pref=stay;path=/;max-age=' + 60*60*24*30;
      banner.remove();
    };
  }
})();

The script is lightweight, runs asynchronously, and respects user choice via a cookie.

Troubleshooting FAQ

The banner never appears for some users.

Check that JavaScript is not blocked by a content‑security policy. Verify the IP API request returns a 200 status. Ensure the cookie name does not clash with existing site cookies.

Googlebot is still being redirected.

Confirm the user‑agent check in your script. A simple guard like if (navigator.userAgent.includes('Googlebot')) return; prevents the redirect for crawlers.

Visitors on a VPN are sent to the wrong domain.

Because VPN IPs can be misleading, the script falls back to the Accept‑Language header when the country code is not in your mapping table. You can also add a manual language selector that overrides the automatic choice.

The redirect loop occurs after a user clicks “Go to …”.

Make sure the cookie is set before changing window.location. Also verify that the target domain does not run the same script without checking the cookie first.

Page load time spikes.

Load the script asynchronously (defer attribute) and cache the IP lookup response for a short period (e.g., 5 minutes) using sessionStorage.

Pre‑Launch Test Checklist

• Validate that each language‑specific domain returns a 200 status for its homepage.
• Confirm hreflang tags are present on every page and reference all domains.
• Test IP detection from at least three geographic locations (VPN or proxy).
• Simulate Googlebot by using the Googlebot/2.1 user‑agent; ensure no redirect occurs.
• Check cookie persistence across subpages and after a page refresh.
• Measure script load time with Chrome DevTools; aim for <200 ms.
• Run an accessibility audit on the banner (ARIA labels, focus order).
• Review analytics to ensure bounce rate drops after rollout.

Key Facts

Common Mistakes and Limitations

One common mistake is to rely only on server‑side 302 redirects, which can cause Googlebot to see a redirect loop and may prevent proper indexing of language‑specific content. Another mistake is to forget the manual override; users who are traveling or using a VPN may be sent to the wrong domain and have no way to return to their preferred language.

The JavaScript approach has limitations: it requires the visitor to have JavaScript enabled (rarely an issue today) and adds a tiny latency while the lookup resolves. If you block third‑party scripts for security, you must host the lookup service yourself or use a first‑party solution.

These recommendations do not apply if you are using a separate subdirectory structure (example.com/fr/) instead of distinct domains; in that case, hreflang tags and internal linking are sufficient and a redirect is unnecessary.

Practical Scenarios

• An e‑commerce site with .com, .de, and .fr domains wants German visitors to land on .de automatically. A JavaScript script detects DE, shows a banner offering to go to .de, and sets a cookie after the user clicks.
• A SaaS company uses a global .com domain but offers localized trial pages on country‑code TLDs. The script redirects trial‑seeking visitors to the appropriate TLD while keeping the main marketing site on .com for brand consistency.
• A news publisher wants to show local language versions of breaking news. The script redirects based on IP, but the fallback banner lets readers stay on the original site if they prefer the English version.

Frequently Asked Questions

Do I need to change my server configuration?

No. The JavaScript method works on any static or dynamic host; only a script tag and a banner are required.

Will this affect my page load speed?

The lookup adds typically under 200 ms. You can mitigate this by loading the script asynchronously and using a lightweight lookup service.

How do I handle search engine crawlers?

Because the redirect happens after the initial HTML loads, crawlers see the original content first. The banner ensures they are not forced into a redirect loop.

Can I still use hreflang tags?

Yes. Keep hreflang tags on each page to signal the language‑regional relationship to search engines, even when you use JavaScript redirection.

What if a visitor’s IP is inaccurate?

The fallback banner lets the user correct the mismatch. You can also prioritize the browser’s Accept‑Language header as a secondary signal.

Running one WordPress site across multiple language domains is powerful. It can also go wrong fast. The most common errors cause indexing problems, duplicate content, and a poor user experience. Here is how to spot each mistake, why it happens, and how to fix it.

This guide assumes your domains point to the same WordPress installation or to separate installations you control. The fixes work either way. Check each page after you make a change.

Missing or incorrect hreflang tags

Why it happens. Hreflang tags are easy to forget. Many teams add a new domain and copy the header code from the old site. They also use the wrong language codes. For example, "en" is not the same as "en-gb" or "en-us".

Impact. Without hreflang, Google cannot match a searcher's language to the right page. The search result may show the wrong language. Google may also treat translated pages as duplicates. This lowers rankings and reduces clicks.

Step-by-step fix. Add hreflang tags to every page in every language. Use the full language-region code. Add an x-default tag. Make the tags reciprocal. If page A links to page B, page B must link back to A. Test with Google Search Console or a validator.

Practical scenario. A French visitor searches on google.fr. Your example.fr page has no hreflang. Google may show the English example.com page instead. The visitor bounces, and you lose the sale.

Takeaway. Treat hreflang as a required page element, not an optional extra.

Wrong canonical URLs and duplicate content

Why it happens. Some WordPress themes output a canonical URL automatically. If the theme was set up for the main domain, it may point all canonicals to example.com. Other times, developers copy code from one language site to another and forget to update the canonical.

Impact. A canonical tells search engines which URL is the main version. If every language page points to example.com, Google may ignore the translated pages. Rankings go to the wrong URL, and duplicate content signals increase.

Step-by-step fix. Check the <head> of each page. Make sure the canonical points to the current URL. For example, example.fr/page should have canonical href="https://example.fr/page". Do not use canonical to point from one language to another. Use hreflang for language alternatives. After the change, resubmit URLs in Search Console.

Practical scenario. A product page on example.es has a canonical to example.com. Spanish users see the Spanish page, but Google indexes the English version. The Spanish page loses visibility.

Takeaway. Self-referencing canonicals are the safest rule for multilingual sites.

Robots.txt or noindex that blocks search bots

Why it happens. Developers often copy robots.txt from the primary domain. They may also add a noindex meta tag to stop duplicate content. Both are common shortcuts that cause big problems.

Impact. If robots.txt has "Disallow: /", Googlebot cannot crawl the domain. Pages disappear from search results. A noindex tag has the same result, but it is slower because Google must still crawl the page to read the tag.

Step-by-step fix. Open each domain's robots.txt. Remove any line that blocks the whole site. Allow Googlebot to crawl CSS, JavaScript, and images. In Google Search Console, use the robots.txt tester. Check for noindex tags in the page source. Remove noindex from language pages. Use hreflang and canonicals instead.

Practical scenario. You launch example.fr and copy robots.txt from example.com. The file contains "Disallow: /wp-admin/". That is fine. But if it contains "Disallow: /", Googlebot never reaches your French pages.

Takeaway. Test every domain before launch, not just the main one.

Inconsistent content across domains

Why it happens. Manual translation is slow. Teams publish on the main domain first and update other domains later. Sometimes translations are incomplete. Headings, buttons, and product names may differ.

Impact. Users notice when the French page has different steps or a missing section. They may leave. Search engines also compare content quality. A thin translation can be seen as low-value. Internal links may point to the wrong language, which confuses crawlers.

Step-by-step fix. Create a content map that lists every page in every language. Publish translations at the same time. Use a translation tool that covers new posts, products, and updates automatically. Audit headings, metadata, and internal links. Keep the message the same, even if wording changes.

Practical scenario. Your English site adds a new pricing section. The Spanish site still shows old prices. A Spanish customer sees the wrong price and leaves. Consistency is not just SEO; it is trust.

Takeaway. Treat all language versions as one content system.

Hard redirects that trap Googlebot

Why it happens. Some sites use IP detection to send visitors to a language version. For example, a visitor from France is redirected from example.com to example.fr. This seems helpful, but Googlebot crawls from US-based servers. It may get the English version or be redirected in a loop.

Impact. When Googlebot cannot follow the redirect, it may not crawl the French pages. Search results may only show the English domain. Users may be redirected to a language they do not want, increasing bounce rate.

Step-by-step fix. Avoid IP-based automatic redirects. Use a language selector instead. If you want to remember a choice, set a cookie after the user selects. Use 302 for temporary redirects and keep one hop. Test with a browser and with a crawler tool such as curl using a Googlebot user agent.

Practical scenario. A user in Germany visits example.com. The server redirects to example.de. The user actually wanted English. They cannot find the switch and leave.

Takeaway. Let users choose their language. Do not guess from an IP address.

Missing or broken multilingual XML sitemaps

Why it happens. A WordPress sitemap plugin may create one sitemap for the default language. When you add a new domain, you forget to generate a separate sitemap. Or the sitemap contains URLs from the main domain.

Impact. Search engines use sitemaps to discover pages. If the French sitemap is missing, Google may never find new French pages. If the sitemap points to the wrong domain, Google sees mixed signals. Indexing slows down.

Step-by-step fix. Create one XML sitemap per domain. Include only URLs from that domain. Add hreflang annotations inside the sitemap. Submit each sitemap in Google Search Console. Verify that URLs in the sitemap return a 200 status. Update sitemaps whenever you publish new content.

Practical scenario. You publish 50 French product pages. No French sitemap exists. Weeks later, only five pages are indexed. A sitemap would have made discovery immediate.

Takeaway. Sitemaps are your multilingual roadmap. Keep them current.

How SeaText Automatically Avoids These Mistakes

SeaText is a WordPress translation solution built for this problem. It translates every page, post, product, and update automatically. There are no page limits and no language limits. New content is translated in the background as soon as it is published.

Automatic translation. This prevents inconsistent content across domains. When you publish on the main site, SeaText creates the translated version. You do not have to wait for a translator or remember to update other domains.

Instant language detection. SeaText detects each visitor's language and translates WordPress pages instantly. This reduces the need for IP-based hard redirects. The visitor sees the right language version without a confusing redirect chain.

Control and editing. Automatic does not mean uncontrolled. You can edit translations, preserve brand voice, and review key pages. This keeps the content quality consistent while you scale.

Multilingual SEO. The source material says SeaText provides free automatic multilingual SEO for every translated page. That means the technical signals are handled as part of the translation process. You still need to check hreflang and canonicals after setup, but the main translation workflow is covered.

For a pre-launch review, visit the SeaText WordPress page. It shows how to activate translation and keep new content in sync.

Frequently Asked Questions

• Why do hreflang errors hurt SEO? Hreflang errors confuse search engines. Google cannot tell which language version matches a search query. The wrong page may rank, or all versions may be treated as duplicates. Fix hreflang before you launch a new domain. Use a validator and Search Console.
• How can I test that robots.txt isn't blocking a domain? Open Google Search Console and use the URL inspection tool. Enter the homepage URL and click "Test Live URL." Then check the robots.txt tester. If the status is "Allowed," Googlebot can crawl the page. Do this for every domain, not just the main one.
• What's the safest way to redirect users to their language? Use a language selector. If you want automation, use a cookie-based redirect after the user chooses. Avoid IP-based redirects because Googlebot's IP does not match the user's location. Test with a Googlebot user agent to see what crawlers receive.
• Do I need separate WordPress installations for each domain? No. A single WordPress installation can handle multiple domains with the right plugin. This makes updates easier. You avoid the problem of inconsistent content because all domains draw from the same database.
• Can SeaText help with multi-domain translation? SeaText automatically translates WordPress content into 125 languages. It detects each visitor's language and keeps new content translated. It also gives you control and editing options. For domain-mapping specifics, check with the vendor on the SeaText WordPress page.
• How often should I audit my multilingual setup? Audit after every major update. This includes new themes, new plugins, or a new language domain. Also audit monthly if you publish frequently. Check hreflang, canonicals, robots.txt, and sitemaps.

Comparison of URL structures for multilingual SEO

Practical takeaway: Subdirectories are the easiest and most authority‑efficient choice for most sites. ccTLDs give the strongest local signal but require more resources. Subdomains are a compromise that often underperform both.

Why the choice matters for rankings

Google uses URL structure as one signal among many. The structure tells Google which country a page targets and how much authority it can use. The wrong choice can slow rankings or confuse search engines.

For example, a French user searching in France is more likely to see a .fr domain in results. But a subdirectory on a .com with strong backlinks can also rank well if Google understands the language and country targeting.

The choice affects crawl budget, indexing, and link equity. It is not just a technical detail. It shapes how fast your international pages appear in search results.

How Google treats ccTLDs

Google views a country‑code top‑level domain (e.g., example.fr) as a separate website. It passes a strong geo‑targeting signal, so the domain is more likely to rank for searches in that country. However, link equity does not automatically flow between the ccTLD and your main .com domain. Each ccTLD must earn its own authority.

In practice, this means you need separate SEO work for each domain. You must build backlinks, earn trust, and manage content independently. The upside is high local trust. Users and Google see the domain as native to that country.

Limitations: cost and complexity multiply. You need separate SSL certificates, hosting, and often separate content teams. Small sites may struggle to maintain authority across multiple domains.

How Google treats subdirectories

Subdirectories (e.g., example.com/fr/) are considered part of the same domain. They inherit the main site’s backlink profile and authority, which can help new language versions rank faster. Google still needs hreflang to understand the language and country targeting.

This is the simplest structure. You add a folder to your existing site. All pages share the same domain authority. New language versions can start ranking quickly because they borrow from the root domain’s trust.

Limitations: the geo‑targeting signal is weaker. If you are competing against local ccTLD sites, a subdirectory may be at a slight disadvantage. Also, if your main domain gets penalized, all subdirectories are affected.

How Google treats subdomains

Subdomains (e.g., fr.example.com) are treated as somewhat independent. They receive some authority from the root domain but not as much as a subdirectory. Google may see them as separate sites for indexing, so hreflang and clear internal linking are important.

In practice, subdomains are a middle ground. They are easier to set up than a ccTLD but still require separate Search Console properties. They can be useful for brand‑specific microsites or when you want a separate identity without buying a new domain.

Limitations: authority dilution is common. Many site owners find that subdomain pages rank lower than subdirectory pages for the same content. Google has said that subdomains are treated as separate entities, so you must build authority for each subdomain.

Trade‑offs in detail: authority, setup, maintenance

Authority: Subdirectories win because they inherit all backlinks. ccTLDs start from zero. Subdomains get partial credit but not full.

Setup: Subdirectories are fastest. You add a folder and configure hreflang. ccTLDs require new domain registration, DNS changes, and often new hosting. Subdomains need DNS records and sometimes separate server configurations.

Maintenance: Subdirectories are easiest. One CMS, one set of plugins, one monitoring tool. ccTLDs require managing multiple domains, each with its own settings. Subdomains add complexity because you may need separate Search Console profiles and separate analytics.

Cost: Subdirectories are cheapest. ccTLDs are most expensive because of domain renewals, SSL, and potential hosting fees. Subdomains cost little extra if you use the same hosting plan.

Decision framework: when to pick each structure

1. If you need the strongest local trust and can invest in per‑domain SEO, choose a ccTLD. This works well for large brands with local offices and budgets.
2. If you want to launch quickly, keep SEO effort centralized, and are comfortable with a moderate local signal, use subdirectories. Most small to medium businesses should start here.
3. If you want a separate site feel without the full cost of a ccTLD (e.g., for a brand‑specific microsite), consider a subdomain. But be aware that ranking may be harder than with subdirectories.

Implementation checklist: hreflang, canonicals, monitoring

• Add self‑referencing and reciprocal hreflang tags on every language version. Use the correct language and country codes (e.g., fr‑FR).
• Use canonical tags to point to the preferred version when duplicate content exists. For example, if you have example.com/en/ and example.com/en‑us/, canonical to the primary.
• Verify setup in Google Search Console for each domain, subdomain, or subdirectory. Submit separate sitemaps for each language version.
• Monitor rankings and traffic per language to spot issues early. Use Google Search Console’s International Targeting report to check hreflang errors.
• Test your hreflang implementation with a validator tool. Common mistakes include missing return tags and incorrect language codes.

Common pitfalls and FAQs

Does using a subdirectory weaken my main domain’s authority?

No. Subdirectories share authority. They do not reduce the main domain’s power. In fact, they can strengthen it by adding more relevant content.

Can I switch from one structure to another later?

Yes, but it is risky. Changing URL structures can cause temporary ranking drops. Use 301 redirects, update hreflang, and monitor carefully. Plan ahead to avoid migration issues.

How does crawl budget affect subdomains vs subdirectories?

Google treats subdomains as separate sites, so each subdomain gets its own crawl budget. Subdirectories share the main domain’s crawl budget. If you have many language versions, subdirectories may be more efficient because Google crawls them together.

Is hreflang enough to fix geo‑targeting for subdirectories?

Hreflang tells Google which language and region a page targets. It does not change the URL structure. For subdirectories, hreflang is essential, but Google also uses other signals like local content, backlinks, and server location. A subdirectory can rank well with hreflang, but a ccTLD adds a stronger geo‑signal.

What about the impact on link building?

With ccTLDs, you need separate link building for each domain. With subdirectories, all links to the main domain benefit all language versions. Subdomains get partial credit, so you may need to build links to each subdomain separately.

Limitations and exceptions

Even with perfect technical setup, thin or duplicated content can hurt rankings. If local competition is strong, a ccTLD may still be needed despite higher cost. Some CMS platforms make subdirectory language routing more complex; test thoroughly before rolling out.

Another limitation: google may still interpret a subdirectory as targeting a specific country if the content is heavily localized and the server is in that country. But the signal is weaker than a ccTLD.

Finally, consider user trust. Users in some countries (e.g., Germany, France) prefer local domains. They may distrust a .com with a subdirectory. Research your target audience’s behavior before choosing.

When you split languages into separate country‑code top‑level domains (ccTLDs), each domain starts with its own authority score. Links pointing to one ccTLD do not automatically pass authority to the others, so the total link equity of your brand is divided across the domains. You must build links for each ccTLD separately to reach the same authority you would have on a single domain.

Why domain authority matters for multilingual sites

Domain authority (DA) is a proxy for the quantity and quality of inbound links. Higher DA correlates with better rankings across all queries. For multilingual sites, a single strong domain can rank all language versions with fewer total links. Splitting into ccTLDs distributes that strength, making each language version harder to rank unless you invest in local link building.

How domain authority is calculated and distributed

Search engines treat each registered domain as an independent entity. Authority flows through internal links, but it does not cross domain boundaries unless you use 301 redirects or canonical tags that point to a primary domain^[Google]. Metrics such as Moz DA and Ahrefs Domain Rating (DR) are computed from the link graph of each root domain^{[Moz][Ahrefs]}. Therefore, a new ccTLD starts with a score near zero and only rises as it earns its own backlinks.

ccTLDs vs subdirectories vs subdomains: authority mechanics

Three common structures exist for multilingual content:

• ccTLDs (example.fr, example.de) – each is a separate root domain.
• Subdirectories (example.com/fr/, example.com/de/) – all share the same root domain.
• Subdomains (fr.example.com, de.example.com) – treated as separate hosts but often inherit some root‑domain authority.

The table below compares them on buyer‑relevant criteria.

Trade‑offs: link equity vs local signals

• Link equity: Consolidated on a single domain; split when using separate ccTLDs.
• Local signals: ccTLDs send a strong geo‑targeting cue to search engines and users, which can improve click‑through rates in local markets.
• Management effort: Separate domains require individual hosting, SSL certificates, and SEO campaigns.
• Brand consistency: Subdirectories keep a single brand URL; ccTLDs may confuse users if not clearly linked.

Decision framework: when to split languages

1. Assess your ability to build links in each target market.
2. Consider legal or trust requirements that favor a local domain (e.g., Germany’s GDPR‑related trust signals).
3. If you can secure comparable link volume per ccTLD, the geo‑targeting benefit may outweigh the authority split.
4. If link resources are limited, a subdirectory or subdomain approach preserves authority while still allowing language targeting.
5. Run a projection: estimate how many linking root domains each ccTLD needs to reach your target DA.

Practical case study: European SaaS expansion

A B2B SaaS company operated on example.com with a DA of 48. It launched French, German, and Spanish versions on example.fr, example.de, and example.es. After six months, each ccTLD had a DA of 12‑15, reflecting only brand mentions and a handful of directory listings. The company then invested in local PR, partner links, and localized content. After another twelve months, the three ccTLDs reached DA 35‑38 each, but the total link‑building budget was roughly three times the spend required to grow the single domain from 48 to 55. The subdirectory alternative would have kept the DA at 48 while adding language pages, saving an estimated 60 % in outreach costs.

Limitations and when advice does not apply

This analysis assumes you are using ccTLDs for language targeting. If you use subdomains (fr.example.com) the authority split is similar but often treated as part of the root domain with some attenuation. The advice also does not apply if you implement proper cross‑domain canonicalization that consolidates authority, which is rare and can confuse geo‑targeting signals. Sites with strong existing brand searches may see less impact because navigational queries bypass authority metrics.

FAQ

1. Why does splitting languages across domains affect authority? Because each domain is treated as a separate entity; inbound links do not flow automatically between them.
2. Can I recover lost authority by linking between ccTLDs? Yes, you can link between your ccTLDs, but those links are treated as external links and pass less authority than internal links on a single domain.
3. When might the geo‑targeting benefit of ccTLDs outweigh the authority split? In markets where local trust is a strong ranking factor (e.g., Germany, Japan) and you can obtain comparable local links.
4. What is a simpler alternative that preserves authority? Using subdirectories (example.com/fr/) or subdomains (fr.example.com) keeps all language versions under one domain, consolidating link equity.
5. How can I estimate the authority impact before migrating? Use a domain authority projection tool that models link‑equity distribution across multiple root domains.
6. Does hreflang solve the authority split? Hreflang helps search engines serve the right language version, but it does not merge link equity across domains.

Handling cookie consent and GDPR compliance across .de, .fr, .it, and .es domains requires a single CMP that can share consent, localized banners, and auditable records. Non‑compliant consent can trigger fines up to 4 % of global revenue, so a systematic approach is essential.

Why Cross‑Domain GDPR Consent Matters

Users move between your country sites during a single session. If consent is not shared, they must repeat choices on every domain, creating friction and legal risk. A unified consent layer ensures a single opt‑in or opt‑out respects the user across all EU properties and satisfies regulators who expect consistent treatment.

Prerequisites for Implementation

Before setting up cross‑domain consent, gather the following:

• Administrative access to all EU language domains and their tag management systems (e.g., Google Tag Manager)
• A full inventory of all cookies and tracking technologies used on each domain, grouped by purpose (essential, analytics, marketing)
• Documentation of local GDPR requirements for each target EU country, as some nations have additional rules beyond the baseline regulation
• A CMP that supports cross‑domain consent synchronization and localized language interfaces

Step 1: Choose a Multi‑Domain Compatible CMP

Not all CMPs support cross‑domain consent sharing. Prioritize platforms that let users set consent once and apply those settings across all owned EU domains. Verify native Google Consent Mode v2 integration, pre‑built consent templates for each EU country, and the ability to generate auditable consent records.

SeaText‑Integrated CMP Partners

SeaText works with CMPs that offer multi‑domain consent sharing, Google Consent Mode v2 support, and local‑language consent templates. Recommended partners include Cookiebot, OneTrust, and Usercentrics when configured with SeaText’s translation agents. These combinations keep banners and policies synchronized across .de, .fr, .it, and .es without manual copy‑pasting.

Step 2: Configure Localized Consent Policies for Each Domain

Each EU language domain needs a consent banner and cookie policy translated accurately into the local language. Explain what data is collected, why, and how users can withdraw consent. Adjust cookie categories to match local rules: some countries require explicit opt‑in for all non‑essential cookies, others allow implied consent for basic analytics. Set the CMP to display the correct language per domain and apply domain‑specific rules where tracking differs.

Step 3: Enable Google Consent Mode v2 Across All Domains

Google Consent Mode v2 adjusts tracking based on user consent, preserving analytics data when users reject non‑essential cookies. Implement the Consent Mode v2 code on every EU domain and sync it with your CMP’s consent signals. Configure parameters such as ad_storage and analytics_storage per domain, then test that consent changes reflect instantly in Google’s systems.

Step 4: Test and Verify Compliance Across All Domains

Test each domain individually: confirm the banner loads in the correct language, preferences save and sync across domains, and tags fire only with explicit consent. Use Google Tag Assistant to verify Consent Mode v2. Run quarterly audits of consent records to meet GDPR storage and access requirements. Verify the withdrawal flow works without complex menus.

How Consent Records Are Stored and Audited

GDPR demands proof of consent: timestamp, user choices, and IP address stored for at least three years. Choose a CMP that writes immutable logs to a secure database or cloud storage. Export logs in CSV or JSON for regulator requests. Automate integrity checks (hash chains) to detect tampering. Document the retention schedule and deletion process in your data‑processing register.

Practical Comparison of Multi‑Domain CMP Capabilities

All three meet core requirements. Choose based on pricing, UI preference, and existing vendor relationships. SeaText’s translation agents connect through each CMP’s API to push localized banner copy automatically.

Maintaining Localized Cookie Policies Over Time

New pages, products, and blog posts appear constantly. SeaText’s WordPress translation agent detects every new post, product, or headline and translates it into 125 languages in the background. There are no page limits or language caps. When a new cookie is added on the .de site, SeaText instantly updates the German consent banner and the corresponding French, Italian, and Spanish versions. This continuous localization keeps every consent notice current without manual tickets.

Key Compliance Facts for Multi‑Domain EU Operations

Common Limitations to Avoid

Cross‑domain consent sharing only works if all domains are owned by the same entity and use the same CMP; different CMPs break sync, forcing users to set preferences per site. Older CMPs may lack Google Consent Mode v2, causing non‑compliant Google tracking. Some third‑party tags ignore consent signals, so audit all tags to ensure they pause when users reject non‑essential cookies. Local EU rules can change quickly; monitor regulatory updates and adjust CMP configurations and policies promptly.

Frequently Asked Questions

1. Do I need separate consent banners for each EU language domain?
   Yes, each domain must display its consent banner in the local language, with policies tailored to that country's specific GDPR requirements. A single CMP can manage all banners and sync consent preferences across domains to reduce administrative work.
2. What happens if a user changes their consent on one domain?
   If your CMP supports cross‑domain consent sharing and all domains use the same CMP and consent cookie configuration, the user's updated preferences will apply to all other domains in your network automatically.
3. How often do I need to update my cookie consent policies?
   Review and update your policies at least annually, or immediately if there are changes to GDPR rules, the cookies or tracking technologies you use, or the purposes for which you collect user data.
4. Can I use a single generic consent policy for all EU domains?
   No, GDPR requires that consent requests be clear, specific, and in the user's native language. A single generic policy will not meet local language requirements, and may not address country‑specific rules for cookie usage.
5. What are the penalties for non‑compliant cookie consent across EU domains?
   Regulators can impose fines of up to 4 % of your global annual revenue, or €20 million, whichever is higher, for GDPR violations including non‑compliant cookie consent practices.