A site that ranks in every market you actually sell in.
Proper i18n, hreflang, locale-aware SEO, CMS-driven translations. Not a Google Translate widget. Built for US, UK, EU, and Latin American markets.
Who this is for
Cross-border B2B or LATAM-to-US founder who needs a site that ranks and converts in English plus Portuguese or Spanish — not a translate widget.
The pain today
- Google Translate widgets that tank on-page SEO
- hreflang set up wrong, leading to duplicate-content issues
- Content managers editing five language versions in spreadsheets
- Currency and pricing logic hardcoded to one market
- Developer handoff that breaks on the second translation cycle
The outcome you get
- Next.js i18n routing with clean /en, /pt, /es URL structure
- Correct hreflang pairs — no duplicate content, no missed markets
- CMS translation workflow editors can maintain without a developer
- Locale-aware currency, date formats, and legal copy
- Structured data and sitemaps scoped per locale
i18n pitfalls I see most often
Most multilingual sites go wrong in one of five ways. A Translate widget — Google penalizes it because the translated text isn't indexable. A subdomain-per-language setup (en.example.com) without proper hreflang, which splits backlink equity. One sitemap covering every locale, so Google never understands the relationship. Currency hardcoded in hero sections. And the worst: translations stored in a spreadsheet that a marketing person pastes into the CMS, with typos drifting across versions. I walk through each of these on the kickoff call and we pick the architecture before design starts, not after.
hreflang, locale routing, and currency
The clean setup for most projects: path-based locales (/en/, /pt/, /es/) on a single domain, one sitemap with locale-scoped entries, hreflang tags on every page pointing to all language counterparts plus x-default. Currency and date formatting driven by the active locale, not the user's browser — so a US visitor on /pt sees Brazilian real, not dollars. Legal copy (terms, privacy) stored per locale in the CMS with explicit review, because an auto-translated privacy policy is a legal risk. Robots and canonical tags verified before DNS flip.
CMS strategies for translation workflow
Three common setups, chosen based on team size. One: a single CMS entry with translation fields per locale — clean, editors see all languages side-by-side, good for small teams. Two: separate entries per locale linked through a reference field — better when translations are outsourced and arrive asynchronously. Three: integration with a TMS (Lokalise, Phrase, Crowdin) for teams doing continuous translation at scale. Sanity, Contentful, and Strapi all handle all three patterns; I pick based on your actual translation process. No solution works if editors can't maintain it after launch.
Case study: Imohub and bolttech scale
Imohub was built Brazil-first with an architecture ready for English. Clean URL structure, CMS schemas designed for translation fields, hreflang-aware sitemap. When the team decided to evaluate new markets, adding English was content work — not a rebuild. At bolttech, I worked on a payment platform that launched across 15+ international markets with 40+ payment providers integrated. The lesson from both projects is the same: locale is a data concern, not a presentation concern. Design the data model right and the front end handles every language you add later.
Pricing and timeline
Multilingual builds usually fit the Websites Business or Corporate tier depending on page count and locale count. Base starts at $5,000 for 2 locales on a standard 8–12 page site and scales from there — each additional locale adds translation workflow work but not a full rebuild. Timeline is 4–6 weeks for 2-locale sites, longer for 3+ locales if translations need to be outsourced. 14-day money-back, 1-year bug warranty, Work Made for Hire. Translation work itself (actual linguistic translation) is outside my scope — I wire the system; human translators or an agency provide the words.
Service coverage note
My practice operates as a US LLC and I serve clients across the US, UK, EU, and Latin America. That matters for multilingual work because I've shipped in English, Portuguese (native), and Spanish (conversational) across those regions. Legal frameworks differ — GDPR for EU, LGPD for Brazil, state-level privacy laws for the US — and the multilingual site has to reflect that in its cookie banner, privacy policy, and terms. I structure the content model so legal counsel can maintain per-locale terms without engineering intervention. Same code, different legal realities, one maintainable system.
Recent proof
A comparable engagement, delivered and documented.
Rebuilt a real estate portal at a fraction of the cost
Rebuilt Imóveis SC's real estate portal as ImoHub — a faster, more scalable successor — handling 120k+ properties with sub-second search and drastically reduced AWS costs.
Frequently asked questions
The questions prospects ask before they book.
- Do you provide translations or just the framework?
- Just the framework and the CMS workflow. The actual translation is human work — either your team, a bilingual marketer, or an outsourced agency. I can recommend translators I've worked with, and the CMS is set up so translations can be pasted in without engineering involvement.
- How do I handle SEO across languages?
- Path-based locales (/en/, /pt/, /es/), one sitemap with locale-scoped entries, hreflang tags on every page pointing to every locale counterpart plus x-default, canonical tags per language. That's the setup Google recommends; duplicate content issues go away when hreflang is correct.
- Can visitors switch language on the fly?
- Yes — I add a language switcher (usually in the header) that preserves the current page when switching. Automatic locale detection from Accept-Language headers is optional — I usually leave it off by default because forced redirects hurt SEO and annoy users. You get a choice, not a forced guess.
- Does the CMS let editors preview translations?
- Yes. Every CMS I set up (Sanity, Contentful, Strapi) has preview URLs per locale. Editors can see exactly how the Portuguese version of a page will render before publishing. The preview pipeline uses the same Next.js ISR/Draft Mode that production uses — no surprises on go-live.
- What about RTL languages like Arabic or Hebrew?
- Fully supported with Tailwind CSS logical properties (ps-4 vs pl-4, me-2 vs mr-2). I've built the site with RTL-ready patterns whether you need it now or later. Adding an RTL locale later is a CMS configuration change plus a QA pass, not a rebuild.
Ready to start?
Tell me what you need in 60 seconds. Tailored proposal in your inbox within 6 hours.