The architecture decisions that make a trilingual site actually work.

URL structure has to be decided before a single page is built

Subdirectories by language, site.com/es/ and site.com/pt/, are generally the strongest default for a trilingual site because they consolidate domain authority under one root domain while still giving search engines a clean, crawlable signal about which pages serve which language. Separate ccTLD domains or subdomains introduce SEO fragmentation that rarely pays for itself unless there is a specific regional hosting or legal reason to split them.

Whatever structure is chosen, it needs to be consistent across every single page, including ones added a year later by a different team member. Inconsistent URL patterns are one of the most common technical debt items on multilingual sites, and they are expensive to fix retroactively because every fix risks breaking existing rankings.

hreflang tags are not optional and are frequently implemented wrong

Every page needs hreflang tags pointing to its equivalents in the other languages, including a self-referencing tag pointing to itself. Missing the self-reference, or forgetting to update hreflang tags when a page is renamed, causes search engines to serve the wrong language version to users, which quietly damages both rankings and user experience.

For Portuguese specifically, decide early whether the target is pt-BR only or a broader pt tag, since Brazilian Portuguese and European Portuguese diverge enough in vocabulary and convention that treating them as identical will read as foreign to at least one audience.

The content model needs a single source of truth per piece of content

Every article, page or product needs one canonical content object with localised fields inside it, not three separate documents that drift out of sync the moment someone edits the English version and forgets the other two. A CMS structure where each locale is a field on a shared record, rather than a duplicate page, is what keeps a trilingual site maintainable past the first year.

This also matters for navigation and metadata. If the site's category taxonomy, tags or filters are not tied to the same shared structure across languages, search functionality and internal linking silently diverge between languages over time, and nobody notices until a user reports a broken filter in the Spanish version that works fine in English.

Not every page needs to exist in all three languages

Forcing full parity across every single page regardless of relevance wastes translation budget on pages that will get no traffic in a given market. A regional case study relevant mainly to a Brazilian audience does not need a forced English or Spanish version if there is no realistic search demand for it in those languages. Decide parity requirements by page type and expected demand, not as a blanket rule.

Language switching needs to preserve context, not just swap the homepage

A language switcher that always drops the visitor back on the homepage of the other language is a common and avoidable failure. If a visitor is reading a specific article in English, the Portuguese switcher should take them to the Portuguese version of that same article whenever it exists, falling back gracefully only when no equivalent page has been built yet.