Building a multilingual portfolio without maintaining two sites

Why one site beats three

The instinct when you serve multiple language audiences is to launch separate sites: yourname.com in English, yournombre.com.ar in Spanish, yourname.cn in Chinese. It feels logical. It is also the fastest way to end up with one updated site and two abandoned ones.

A single site with a locale switch is materially less work. One domain, one analytics property, one set of SEO signals. The version a visitor sees is decided by their browser language or a manual switch, but underneath it's the same content graph translated into N languages.

The catch is that not all CMSes handle this well. Many bolt translation on as a plugin and let the data drift. Look for a platform where multi-locale is native to each field — bio, project description, role title — not a separate "translation" copy that goes stale. Mycvify works this way; some other modern personal-site builders do too. The rest of this guide assumes that pattern.

Pick your locales on purpose

More languages is not better. Each one is a maintenance cost forever. Pick locales for two reasons only: a meaningful share of your real audience reads that language, or a meaningful share of opportunities you want comes from a market that does. Vanity locales — "my grandfather was Italian, let me add IT" — eventually go stale and signal carelessness.

Two or three locales covers most professionals. English is the default global business language and almost always one of them. Spanish adds Latin America and Spain; Mandarin Chinese adds mainland China and meaningful diaspora. French, Portuguese, German, Japanese each open specific markets. Pick the ones that match where your work actually goes.

Be honest about your fluency for content you'll write yourself. If you can't proofread the result, you can't ship it confidently. That doesn't mean don't include the language; it means budget for review (next section).

Machine translation: when yes, when no

Modern machine translation in 2026 is good enough that the question isn't "does it work" but "where does it fail." It fails on register — sounding too formal or too breezy for the context — and on idioms. The closer the text is to neutral business English, the safer the translation. The closer it is to your personality, the riskier.

A practical rule of thumb. Project descriptions, role titles, skills lists, tool names: machine-translate confidently, glance once. Bios, taglines, anything with voice: machine-translate as a starting point, then have a fluent speaker rewrite. Captions for visual work that say "client logo" and nothing else: machine-translate and forget.

Mycvify ships an AI translate-this-field button on Pro and Max plans, which is exactly the workflow that works: the machine gets you 80%, you or a reviewer cleans up the last 20%. Don't auto-translate at runtime — that produces inconsistent results and the visitor never knows what they're reading.

URLs, hreflang, and not confusing Google

Search engines need to know which language a given page is in and which other pages are translations of it. The mechanism is the hreflang tag. A modern multi-locale platform handles this for you; you don't have to write tags yourself. But it helps to know the mental model.

URL pattern matters. Most platforms use a path prefix (/en, /es, /zh) on a single domain. That's the cleanest setup for personal sites: SEO authority concentrates on one domain, and the locale is obvious in the URL. Subdomains (es.yourname.com) and country TLDs (yourname.es) work but are heavier — they fragment authority and only make sense if your locales correspond to genuinely different content, not translations of the same content.

Don't translate URL slugs aggressively unless you serve a market that strongly expects it. /projects works fine in three languages; /proyectos and /项目 add overhead with little benefit on a personal site.

• One domain with /en, /es, /zh path prefixes — recommended.
• Hreflang tags on every page pointing to siblings — your platform should do this automatically.
• A visible locale switch in the header.
• Honour browser language on first visit, remember the user's choice afterwards.
• Same slugs across locales unless you have a strong reason.

Maintenance: the only test that matters

The only honest test for whether your multilingual setup is working is whether you keep it updated. If a project ships and you only add it in English, the architecture is too heavy. Reduce locales until updating all of them feels like one task, not three.

A useful trick: when you write a new field, write all locales the same day, in the same sitting. Switching languages within a fifteen-minute block is cheap; coming back next month to "add the Spanish version" almost never happens. Mycvify's per-field locale tabs are designed for exactly that flow, but the discipline is independent of the tool.