Multilingual Websites: What Most Businesses Get Wrong Before They Start
The moment a company decides to go multilingual, it usually does one of two things: it dumps its existing content into Google Translate and publishes, or it hires a translation agency, gets back a folder of Word documents, and pastes them into the CMS one by one.
Both approaches get the site live. Neither produces a multilingual website that actually works.
What they produce is a translation layer on top of an architecture that was never designed for multiple languages, and that gap surfaces almost immediately, in broken URL structures, in SEO that cannibalizes itself, in language switchers that drop users on the homepage instead of the equivalent page, and in content teams that dread publishing anything because it means touching twelve files instead of two.
We've rebuilt multilingual websites that were built this way. The diagnosis is almost always the same: the company treated localization as a content problem when it was an architecture decision all along.
The misconception that costs the most
Most decision-makers frame going multilingual as: "We have a website. We need it in Spanish and English. How long does the translation take?"
This is the wrong question, and asking it first shapes every decision that follows, usually toward the path of least initial resistance and highest long-term cost.
The right question is: "How do we want to structure URLs, content relationships, and routing so that each language version is a first-class citizen of the site, not an afterthought?"
The difference matters enormously in practice. A site where each language version has its own clean URL structure (/es/servicios/ not /?lang=es) can be indexed by Google as a distinct, relevant result for Spanish-language searches. A site where language is a query parameter or a cookie is, from Google's perspective, one page with inconsistent content. You're not building two audiences; you're confusing one.
Hreflang annotations are the mechanism that ties it together at the SEO level, they tell search engines that /en/services/ and /es/servicios/ are the same content in different languages, and that the Spanish version should rank for Spanish-speaking users in Colombia or Spain, not the English one. Implementing them incorrectly (wrong locale codes, missing self-referencing tags, asymmetric pairs) effectively erases the SEO value of the translation investment. We see this in roughly 60% of multilingual sites that come to us for audits.
Three architecture patterns, and which one to choose
There are three standard approaches to multilingual URL structure, and they have meaningfully different implications:
Subfolders (pixelamos.co/es/, pixelamos.co/en/) keep everything under one domain. Domain authority is consolidated. It's the easiest to set up correctly, the easiest to maintain, and the approach Google explicitly recommends for most cases. This is what we use for the majority of projects.
Subdomains (es.pixelamos.co, en.pixelamos.co) offer more isolation, useful when the regional teams managing each version are independent and need separate hosting or CMS environments. The tradeoff is that subdomains are treated more like separate sites by Google, so authority doesn't flow between them as cleanly. For most businesses, this is more complexity than it's worth.
Separate domains (pixelamos.com.co, pixelamos.co) make sense when the target markets are genuinely distinct brands, different products, different positioning, different audiences who should never see each other's content. This is the most expensive to maintain and should only be chosen when the brand separation is intentional and permanent.
The decision should be made before a single line of code is written. Migrating between these structures after the site is live is disruptive, requires redirect planning, and temporarily disrupts SEO rankings. We've seen companies spend more fixing the migration than they would have spent building it right the first time.
What "translation" actually means (and where it ends)
When we scope a multilingual project, we distinguish between three distinct activities that people routinely collapse into one word:
Translation is converting text from one language to another. It's the part that's actually table stakes, necessary but nowhere near sufficient. Machine translation (DeepL, GPT-based tools) has gotten good enough that it handles routine product descriptions, legal disclaimers, and help content competently. Using it as a first pass and then having a human reviewer clean it up is a defensible workflow for high-volume, low-stakes content.
Localization is adapting content to the cultural context of the target market. A Colombian B2B buyer doesn't just want text in Spanish, they want copy that reflects how business is discussed in their market. Pricing should be in COP when appropriate. References should be local. Urgency cues, formality levels, and even which pain points are foregrounded vary significantly between markets. A site that's been translated but not localized tends to feel slightly foreign even to the audience it's targeting, and that friction costs conversions.
Transcreation is what you do when localization isn't enough, when the concept itself doesn't map across cultures and needs to be rethought, not rephrased. Marketing taglines, campaign slogans, and emotionally loaded content often require transcreation. It's the most expensive per word and the most valuable for brand-critical copy.
Knowing which approach applies to which part of your site is a strategic decision, not a translation one. We help clients map this before any content is written, because getting it right at the planning stage is dramatically cheaper than fixing it after publication.
The CMS question that determines everything downstream
The choice of content management system for a multilingual site is not a technical preference, it's a decision with compounding consequences for the content team that will live with it for years.
Some CMS platforms handle multilingual content as a core architectural feature. Others treat it as a plugin, an add-on, or a workaround. The difference shows up in concrete, daily-friction ways:
- Can an editor create a new blog post and have the system automatically create a corresponding draft in each language, linked to the original?
- When a page is updated in one language, does the system flag the other language versions as potentially out of date?
- Can translation status be tracked at the field level, so that a partially translated page doesn't accidentally go live?
- Does the URL generation respect each language's slug separately, or does it just translate the English slug with a query parameter?
A CMS that doesn't handle these workflows natively means a content team building manual workarounds, spreadsheets tracking translation status, copy-pasted URL structures, ad-hoc review processes. That overhead compounds every time content is published.
The platforms we've found most capable for serious multilingual builds are those built with content relationships as a first-class concept. The specific tool matters less than whether it was designed for this use case or retrofitted to support it.
Performance: the part multilingual teams forget until it's too late
Adding multiple language versions of a site reliably increases its complexity in ways that degrade performance if not managed explicitly.
The most common offenders:
Language detection logic on the server can add meaningful latency if it involves a database lookup or a complex set of redirect rules. The right approach is to resolve language preference at the CDN edge based on Accept-Language headers and URL structure, not in application code on every request.
Font loading for non-Latin scripts is frequently overlooked until the site is in QA with the actual translated content. If your design uses a custom typeface that doesn't include the character sets needed for your target languages, you'll either fall back to system fonts inconsistently or load a bloated font file that covers every possible character. Plan this in the design phase.
Duplicate content flags from unintentional indexing of staging versions, sitemap misconfiguration, or missing canonical tags can undermine the SEO benefit of the entire multilingual investment. A multilingual sitemap must explicitly list each language URL and its hreflang relationship. We audit this before any multilingual site goes live.
What "going multilingual" actually looks like in practice
To make this concrete: when a client comes to us wanting to expand from a single-language site to two or more languages, the work typically breaks down like this.
The first conversation is about markets, not languages. Which countries or regions are you targeting, and what does a qualified buyer in those markets actually look like? The answer shapes whether localization depth is critical (yes, if it's a sales-driven B2B site; less so, if it's a product catalog with price tables).
The second conversation is about architecture, the URL structure, routing strategy, and CMS choice. This is the longest conversation and the one most clients want to skip to get to the "real work." We don't let them skip it, because every decision downstream depends on it.
The third stage is content strategy: which pages are in scope for launch, what's the localization depth for each, and who owns ongoing maintenance. A multilingual site isn't a project you finish, it's an ongoing editorial commitment. If there's no plan for who updates the Spanish version when the English homepage copy changes, the site will drift out of sync within months.
Then development, QA in each locale, SEO configuration, performance testing, and launch.
Most serious multilingual projects take longer than clients expect, not because the development is especially complex, but because the content and strategic phases are routinely underestimated. The companies that do this well treat the architecture conversation as the core of the project, not the preamble to it.
The case for doing it right the first time
Going multilingual is an investment that compounds, but only if the foundation is sound.
A well-structured multilingual site builds authority in each target market independently. Over 12 to 24 months, a correctly hreflang'd Spanish-language section ranks for Spanish-language queries, earns Spanish-language links, and converts Spanish-speaking visitors without diluting the English-language performance. The two versions reinforce each other rather than cannibalizing.
A poorly structured multilingual site does the opposite: it introduces indexation confusion, fragments authority across duplicate URLs, and creates a content maintenance burden that eventually leads teams to deprioritize one language version until it becomes effectively abandoned.
We've seen both outcomes. The difference between them isn't the quality of the translation, it's whether the architecture decision was made deliberately at the start.
At Pixelamos, we've handled multilingual builds for clients operating across Latin America and internationally, including navigating the specific nuances of Colombian Spanish for regional audiences. If you're planning to expand your site to new markets and want to structure it in a way that compounds over time rather than creating technical debt, let's talk about your project.
