I've built bilingual sites my whole career — I work in both languages, across Los Angeles and Mexico — and the single biggest lesson contradicts how most bilingual sites get made: a Spanish version is not a translation project. It's a second audience project.
Run your English site through a translation tool and you get grammatically passable Spanish that persuades no one, because Spanish-speaking customers don't just use different words — they ask different questions, trust different signals, and often reach for different contact channels. A translated page answers the English audience's questions in Spanish, which is a subtle way of talking past the person actually reading. I write the two versions separately, for each audience, every time. It costs more than clicking "translate." It's also the entire difference between a checkbox and a channel that produces customers.
The default assumption — English primary, Spanish secondary — deserves scrutiny. When I built the site for Arévalo & Romero, an immigration law firm with thirty-five years of practice and a presence on Spanish-language radio and TV, we made Spanish the primary experience with English as the alternate, because that's who was actually calling. Match the architecture to the audience, not to convention.
This is the detail that surprises English-first businesses most. For Dra. Marisol Ceja, a rhinoplasty practice in Guadalajara, we built the contact model around WhatsApp — because in Mexico, WhatsApp is the phone, and a traditional contact form reads as a wall. In LA, Spanish-speaking customers lean on calls and texting. A bilingual site that translates the words but keeps English-market contact patterns has only done half the job. It's also why the chat assistant I install runs fully in both languages, including the legal consent line — a Spanish speaker shouldn't hit English exactly at the moment you're asking for their trust and their phone number.
Signal the language pairing to search engines with hreflang tags so each version ranks for its own audience's searches. Keep Spanish URLs human (/servicios, not /es/services-page-2). And never auto-redirect by browser language or IP — bilingual households and shared devices are the norm in this market, so offer the switch, visibly, and let people choose.
Nearly half of Los Angeles County speaks a language other than English at home, overwhelmingly Spanish. For a local service business, a real Spanish experience is routinely the difference between being an option and being invisible for half the market — while most of your competitors still have a broken "Español" link they've never tested. It's the least crowded high-value channel in local marketing right now.
Done properly — written for each audience, not machine-translated — expect roughly 30–40% on top of the base project, mostly writing and structure work. Done as an auto-translate plugin, nearly free and worth about what it costs.
A folder (/es/ or Spanish-named paths) on the same domain, in almost every case. It consolidates your site's authority instead of splitting it, and it's simpler to maintain. Separate domains only make sense for genuinely separate businesses.
As a courtesy layer for incidental pages, fine. As your Spanish strategy, no — the output doesn't rank as your content, reads as machine output to the people you're trying to win, and handles industry vocabulary badly. If Spanish speakers matter to the business, write for them.
Yes, in an underpriced way: Spanish-language search in US local markets is meaningfully less competitive than English for the same services. A well-written Spanish page frequently ranks faster for 'plomero cerca de mí' than its English sibling does for 'plumber near me'.
Have a question these pages don’t answer? Ask me directly — or ask my assistant right now.
Start a Conversation