How to choose a multi-language strategy for your SGEN site

The short answer

Three patterns. Pick by team structure + content variance, not by translation tooling:

Default to subdirectory. Switch to subdomain when one team can't manage all languages. Switch to separate sites only when content + brand + governance genuinely differ per market.

What is this for?

SGEN doesn't ship a single "multi-language" toggle — because there's no single answer. The right pattern depends on whether you have one team that owns all languages, separate teams per language, or genuinely different sites per market.

This page is the decision rule + the tradeoffs.

Good use cases

• You're planning a multi-language launch and need to pick a pattern.
• You're running one language and want to add a second.
• You're consolidating multiple per-language sites into one SGEN install.
• You're auditing a multi-language setup that "isn't working" — usually a sign the pattern doesn't match the team.

What NOT to use this for

• Don't use this to pick a translation tool. That's downstream. Pick the pattern first; translation tooling slots in after.
• Don't use machine translation for legal pages. Privacy policy, terms — these need a native legal review. Machine output is a starting point, not a publish-ready output.

How this connects to other features

• SG-Dashboard → Site Manager — where multi-site setups (subdomain or separate sites) are created and managed
• SG-Core → Pages & Posts — where language-prefixed slugs are set per page
• SG-Builder → Page Settings — the Language field that drives hreflang tag generation
• URL slug strategy — language-prefixed slug conventions (/en/about, /es/about)

Before you start

• Know your team structure: one editor for all languages, or separate teams per language? This is the primary decision driver.
• Know whether content is a 1:1 translation or genuinely different per market (different products, pricing, campaigns).
• Have your target languages and ISO codes ready: en, es, fr, de, ja — or regional variants like en-us, es-mx.
• If using subdomain or separate sites, confirm your SG-Dashboard account supports the number of sites you need.

Where to find it

• Single-site multi-language: the admin → Pages → create page with language-prefixed slug (e.g., /en/about)
• Multi-site (subdomain or separate domains): SG-Dashboard → create new site → connect domain → set primary language
• Language metadata per page: SG-Builder → page settings → Language field

Pattern 1 — Subdirectory (recommended for most)

URL: yourbrand.com/en/about and yourbrand.com/es/about

Setup: one SGEN site. Each page exists in N language variants (/en/about, /es/about, /fr/about). Language is part of the URL path. Hreflang tags tell search engines which version belongs to which audience.

Pros:

• Single CMS install — one place to manage settings, redirects, integrations
• Shared media library — one image, used across languages
• SEO authority concentrates on one domain
• Cross-language linking is trivial

Cons:

• All content must live in one CMS — slower if multiple teams update simultaneously
• Translation workflow must be tight; "out-of-sync" languages create stale content
• Backups + migrations move all languages together (usually a feature, occasionally a constraint)

When to use: most cases. Single team, central editorial calendar, content that translates roughly 1:1 across languages.

Pattern 2 — Subdomain

URL: en.yourbrand.com/about and es.yourbrand.com/about

Setup: Often two separate SGEN sites under the same SG-Dashboard account, each scoped to one language. Cross-links use full URLs.

Pros:

• Each language can have its own team, editorial cadence, design tweaks
• Independent release timing — Spanish team ships without waiting for English
• Different backup / restore / migration cycles per language
• Failure isolation — staging issue on one language doesn't block another

Cons:

• SEO authority splits across subdomains (less consolidated)
• Shared assets (logo, blog images) must be uploaded per site or referenced via absolute URLs
• Settings + integrations duplicated per site
• More admin overhead per release

When to use: when language teams genuinely operate independently. Common for global brands with regional marketing leads.

Pattern 3 — Separate sites (different TLDs or domains)

URL: yourbrand.com (English) and yoursite.es (Spanish)

Setup: Two separate SGEN sites with completely different domains. Connected only by brand convention + cross-domain navigation.

Pros:

• Each market gets a fully local-feeling URL
• Content + design + governance can diverge as much as needed
• Compliance (e.g., GDPR in EU vs CCPA in CA) handled per site
• Different pricing, products, legal terms naturally fit different sites

Cons:

• No shared authority — SEO starts from zero on each new TLD
• Most duplication overhead — two of everything
• Operational complexity highest — multiple billing, multiple staging, multiple teams
• Brand drift risk — sites can diverge in tone, visual style, structure over time

When to use: large multinationals with market-specific products, prices, or legal regimes. Not the right call for "we have an English site, let's add Spanish."

Pattern selection guide

Ask yourself:

1. Who owns the Spanish content? Same person as English? → subdirectory. Different team? → subdomain.
2. Is Spanish content a 1:1 translation, or a different campaign? 1:1 → subdirectory. Different campaign → subdomain or separate sites.
3. Is the Spanish market legally different (pricing, terms, products)? Yes → separate sites. No → subdirectory or subdomain.
4. Can you ship Spanish in lockstep with English releases? Yes → subdirectory. No → subdomain.
5. Will you ever need to retire the Spanish site without touching English? Yes → subdomain or separate sites.

Translation tooling — separate decision

Once the pattern is picked, choose translation tooling:

• Manual translation — translators write in the SGEN admin directly. Simplest. Works at small scale.
• Translation memory / TMS integration — Phrase, Lokalise, Smartling. Translators work in their tool; content syncs to SGEN. Best for ≥3 languages or ≥100 pages per language.
• AI translation as a starting draft — generate baseline, human editor refines. Cuts translator time 40-60% but quality varies by language pair.

SGEN doesn't currently ship a native TMS integration. Use webhooks to push content to a TMS and re-import the translated version.

Example — adding Spanish to an existing site: The team has one editor who writes in English and manages Spanish translation personally. They chose subdirectory (yoursite.com/en/, yoursite.com/es/). The Spanish pages are 1:1 translations; the editor uses AI translation as a first draft and edits for brand voice. Total pages: 18 English, 14 Spanish (top 80% by traffic). Launch time: 3 weeks.

Worked examples

Example 1 — Subdirectory (single team, two languages)

Scenario: One team, one editor. English is primary, Spanish is secondary. Content 1:1 translates.

Chosen pattern: Subdirectory. yoursite.com/en/ and yoursite.com/es/.

Setup steps taken: Created pages with /en/ and /es/ slug prefixes. Set Language field on each page in SG-Builder. Confirmed hreflang tags appeared in page source. Added a language toggle to the header (Custom Codes implementation).

Result: Search Console shows Spanish pages indexed under Spain + Mexico search results. Language switcher preserves the current page.

Example 2 — Subdomain (regional teams)

Scenario: English team in USA, French team in France. Different editorial calendars, different campaigns, different publishing cadences.

Chosen pattern: Subdomain. yoursite.com (English) and fr.yoursite.com (French).

Setup steps taken: Created second SGEN site in SG-Dashboard. Connected fr.yoursite.com domain. Set primary language to French. Duplicated essential pages; French team manages their own content cadence.

Result: French team can publish without coordinating with English team. SEO authority split between domains — accepted as the cost of team independence.

Example 3 — Separate sites (market divergence)

Scenario: A global brand opens a separate e-commerce operation in Japan with different products, JPY pricing, and local legal requirements.

Chosen pattern: Separate sites. yoursite.com (global, English) and yoursite.jp (Japan, Japanese).

Result: Each site operates independently. Different product catalog, different pricing, different privacy policy. No shared authority, but full market independence.

Anti-patterns

| No language switcher | Users can't navigate between languages | Implement header language toggle (Custom Codes or nav component)

Steps for a subdirectory rollout (most common path)

Steps

1. Pick supported languages

Start with 1-2 additional languages. Don't launch 7 languages at once — stale translated pages hurt more than no translated pages.

2. Decide URL convention

/en/, /es/, /fr/ — or use ISO regional variants (/en-us/, /es-mx/) if regional variants matter for your market. Pick one convention and stick to it across all content.

3. Set the default language

Usually English at /en/ or as the root. Decide whether the root URL (/) serves the default language or a language-picker page.

4. Add hreflang tags

Tell search engines which page version belongs to which audience. SGEN adds hreflang tags automatically when the Language field is set on each page (SG-Builder → page settings → Language).

5. Translate navigation + footer first

Every reader sees these on every page. Getting navigation and footer right first means the translation feels complete even before all pages are done.

6. Translate the homepage + top 5 pages

Validate the URL pattern with real content. Confirm hreflang tags are present (check the page source for <link rel="alternate" hreflang=...>).

7. Set up the language switcher

Usually a flag dropdown in the header. Confirms users can move between language versions.

8. Add language-detection redirect (optional)

Detect browser language, redirect first-time visitors to their language version. This is a Custom Codes implementation or a server-level rule — SGEN doesn't ship this natively.

9. Translate progressively

Cover the top 80% of traffic pages before launching to public. The long tail can roll out over weeks.

1. Decide URL convention. /en/, /es/, /fr/ — or use ISO codes (/en-us/, /es-mx/) if regional variants matter.
2. Set the default language. Usually English at /en/ or as the root. Decide whether root URL (/) is the default language or a language-picker.
3. Add hreflang tags. Tell search engines which page version belongs to which audience. SGEN adds them automatically when language metadata is set.
4. Translate the navigation + footer first. That's what every reader sees on every page.
5. Translate the homepage + top 5 pages. Validate the URL pattern with real content.
6. Set up the language switcher. Usually a flag dropdown in the header. Confirms users can move between languages.
7. Add a language-detection redirect (optional). Detect browser language, redirect first-time visitors to their language.
8. Translate progressively. Cover the top 80% of traffic before launching to public; the long tail can land over weeks.

What success looks like

• Every page in your primary language has a counterpart in each supported language.
• Hreflang tags are present and correct (verify with Google Search Console → International Targeting).
• Language switcher works on every page, preserving the user's current page when switching language.
• Search Console shows each language being indexed in its target market.
• No broken cross-language links.
• Translation workflow is defined: who owns each language, what the publication cadence is, how out-of-date content is flagged.

What to do if it does not work

"Google indexes my Spanish pages under English search results." Hreflang missing or incorrect. Check Search Console → International Targeting.

"My language switcher takes users to the homepage, not the equivalent page." Page-equivalent mapping is missing. Each page needs translations: frontmatter mapping language→slug.

"My Spanish content is months out of date." Translation workflow not tight enough. Either consolidate ownership to one team (subdirectory), or split to separate teams with explicit release cadences (subdomain).

"My Spanish team can't release without blocking English." You're on subdirectory but team structure says subdomain. Migrate.

"Hreflang tags aren't appearing in the page source." Language field not set in SG-Builder → page settings. Set it on every language variant of every page.

Pattern comparison table

Decision flowchart

Answer these questions in order to pick the right pattern:

1. Does one team manage all languages?

• Yes → subdirectory
• No → go to 2

1. Is the content genuinely different per market (not only translated)?

• Yes → go to 3
• No (1:1 translation, different teams) → subdomain

1. Are there market-specific legal requirements, products, or pricing?

• Yes → separate sites
• No → subdomain

This covers 95% of cases. If your situation doesn't fit this tree, describe it to your SGEN account team.

Starting small — the 1+1 rule

If you're adding your first additional language, apply the 1+1 rule:

• Translate 1 language (not 3 or 5)
• Cover 1 site section at a time (not the whole site at once)

Launch with English + Spanish on your top 10 pages. Validate the workflow (translation, review, publish, hreflang). Then expand. Teams that try to launch 5 languages at once end up with 4 stale ones within a year.

Related reading

• SG-Dashboard → Site Manager — multi-site setup
• URL slug strategy — language-prefixed slug conventions
• Switch SGEN theme safely — when each language has its own theme