International SEO for a small product: structure, language, and when to start

You can reach buyers in another country without breaking your site. This page shows you how to pick a structure, set languages, and ship. It also helps you decide when to start and what it costs to run.

By , founder of Porteur · Updated 14 September 2026 · Markdown

When to expand beyond one language

Add a second language when three signals line up. First, Search Console shows impressions from that country on your one-language site. Second, you can sell there today, payments and shipping or delivery included. Third, support can answer in that language.

Do not translate because a blog ranked once abroad. Wait until you see steady queries like “pricing” and “signup” from that market. A language without support will leak trials and create churn.

Be blunt about cost. A second language is a second site’s worth of maintenance. Every edit needs a twin. Plan owners and a release path before you start.

The three structures and how to choose

You have three viable structures. A country-code top-level domain, a subdirectory, or a subdomain. Google says all three work. The choice is about operations and links, as of 2026.

StructureExampleHow Google sees itWhy choose itTrade-offs
Country-code domainexample.frStrongest geographic signal, separate siteYou want a clear country brand, separate operations, local press and linksNew domain needs its own links and trust, separate hosting and certs
Subdirectoryexample.com/fr/Same host and link profileFast to ship, all authority stays on one site, simplest trackingWeaker country signal than a ccTLD, shared templates and constraints
Subdomainfr.example.comUsually part of the site, can be seen as separateOps want isolation from the app or blog, or a CDN rule needs itMay split signals in some cases, more setup than a folder

Do not use a URL parameter like ?lang=fr. It is discouraged. You will fight crawling, duplicates and analytics from day one.

A small product often starts with subdirectories. example.com/fr/, example.com/de/. You keep one host, one sitemap index, and your existing links help new pages. If France grows into its own operation later, you can migrate to example.fr with a redirect map.

One language per URL, no IP redirects

Set one language per URL. Do not mix languages on the same page. Keep the UI, headings and body in the same language as the title and metadata.

Add a language switcher that renders anchors, not a script. Link each language to the matching URL. On /pricing, the switch shows /fr/pricing and /de/pricing. It should not submit a form or rely on cookies to change content.

Hreflang in one paragraph

Use hreflang to declare language and region versions of the same page, so Google can pick the right one to show. Put link rel="alternate" hreflang="…" tags in the head, in your sitemap, or in HTTP headers. Use ISO codes, make them reciprocal, and include an x-default to cover a selector or a global page. Hreflang does not merge ranking signals, it only helps choose the right version in search results.

Translate for how people search, not word for word

People do not search literal translations. They search their own phrasing. “Facturation” beats a formal “émission de facture” for a billing page in French. Your /fr/facturation should use the term buyers type, across title, slug, headings and copy.

Localise currency, dates, examples and screenshots. Prices in euros. Day-month-year dates. Screens with French labels. If your app stays English, say so in the copy and support pages.

Translate titles, meta descriptions, URL slugs, alt text and structured data fields. A French product page with an English slug and English Product schema looks careless. Fix it in code templates once so every page inherits it.

Google’s spam policies name content translated automatically without human review as an example of scaled content abuse, as of March 2024. You can use AI to draft, but you need a fluent editor to check meaning, terms and tone. Keep a term base per market so future pages stay consistent.

Choosing a structure for a small team: worked examples

Case 1, SaaS with one engineering team. Choose subdirectories. example.com/fr/. You will ship pages faster and reuse your link equity. You can move France to example.fr later if it becomes its own business unit.

Case 2, ecommerce with local fulfilment and PR in one market. Consider a ccTLD. example.fr with a French legal entity, French customer service, and local press that links to .fr. Budget time for a full domain launch and a link programme in that market.

Case 3, you must isolate content from the app for build reasons. A subdomain can be acceptable. fr.example.com for the marketing site, app.example.com for the app. Expect to work a bit harder on internal links and tracking across subdomains. Google usually treats it as part of your site, but it can be seen as separate in some cases.

Rollout plan: from first signal to live pages

  1. Confirm demand and readiness

    In Search Console, filter Performance by Country to see steady impressions. Confirm payments, tax, and support cover the country and language.

  2. Pick structure and URL map

    Choose ccTLD, subdirectory or subdomain. Draft the folder map: /fr/, /de/. List all core pages to translate: /, /pricing, /guides/getting-started, /signup, /privacy.

  3. Build templates and navigation

    Add language-aware layouts, translated menus, and a visible language switcher with real links. Keep one language per URL.

  4. Implement hreflang and sitemaps

    Add hreflang in the head or sitemap with reciprocal links and x-default. Ship a language sitemap or add hreflang entries to one sitemap index.

  5. Translate for the market

    Localise titles, descriptions, slugs, alt text, schema, currency, dates and examples. Have a fluent editor review. Keep a term base.

  6. Ship and monitor

    Deploy. Submit sitemaps. Monitor impressions and clicks by Country and Page in Search Console. Track conversions by language in your product analytics.

A fixed page looks like /fr/pricing with a French title, a French meta description, euros on the plan cards, a French FAQ, hreflang pointing to /pricing and /de/pricing, and a footer menu linking to other /fr/ pages.

Ongoing maintenance and quality bar

Every new English page needs translations. Budget the same review time again. Keep a checklist in your PR template: copy, metadata, slug, schema, screenshots, currency, dates, links, hreflang, sitemap.

Avoid thin clones. Each page should hold data or an answer of its own that a reader in that market would want. That includes local support articles, delivery times, and legal terms where they differ. Helpful content signals were folded into core ranking in March 2024, so quality ties to the site as a whole.

Watch for drift. If /pricing changed last month, check /fr/pricing matches. Run a monthly diff on key pages so translated UIs do not lag the product. Tie translation review to your release cadence.

Common pitfalls to avoid

  • Redirecting users by IP or browser language instead of linking to versions
  • Serving mixed-language pages or images with English text baked in
  • Using ?lang parameters instead of clean paths
  • Forgetting to translate schema, alt text or the URL slug
  • Missing reciprocal hreflang links, or wrong ISO codes
  • Linking French pages to English help docs
  • Deploying 200 pages of machine translation with no human review

Questions

Sources

Check my site, free

Paste your URL to see where demand already exists by country and which pages to localise first, in about thirty seconds, free, with three findings shown whole by Porteur.

  • Free check, no card
  • Read-only, your own accounts
  • Readable by your agent

Read next