Skip to content

Web designBy Federico Noya · 10 min read

Bilingual website for a US small business (English + Spanish): how to do it right

A single browser window on a café table split into two identical, equally detailed versions of a small café storefront website, each with its own speech bubble, joined in the middle by a small arch with a plant

If you run a small business in the US, there's a good chance some of your customers would rather read about you in Spanish. According to the Census Bureau's American Community Survey, about 44.9 million people age 5 and up spoke Spanish at home in 2024, roughly 1 in 7. About four in ten of them say they speak English less than "very well".

The usual answer is a translate button in the corner of the site. It takes an afternoon, it looks like a Spanish version, and it mostly isn't one: Google can't find it, the words that sell come out wrong, and nobody checks what happens when a customer fills in the form in Spanish. This guide covers what a real English + Spanish website involves, and when you can skip it.

Full disclosure: we're a web studio based in Buenos Aires, and Spanish is our first language. That helps, but it doesn't make us the voice of your customers, and we'll come back to why.

Key takeaways

  • Check the language of your real inquiries before you build anything. Most US Latinos are comfortable in English; the ones who aren't are often exactly the customers a Spanish version brings in.
  • A translation widget is not a Spanish version. It translates in the visitor's browser, so there's no Spanish URL for Google or AI assistants to read.
  • Google recommends a separate URL for each language, hreflang annotations that point both ways, and no automatic redirects by language. Use es or es-US, never es-419: Google doesn't support it.
  • Write the Spanish for your customers, not for a dictionary. The pages that sell need a human writer or reviewer; the rest can start from a machine translation that a person checks.
  • The real cost of a bilingual site isn't the build. It's that every new page, price change and promotion now happens twice, and someone has to answer in Spanish.

First, who you're actually writing for

"Hispanic customers" is not one audience. In Pew Research Center's 2023 National Survey of Latinos, 51% of Hispanic adults said they prefer to get their news in English, 24% in Spanish and 23% had no preference. Among Latino immigrants the picture flips: 47% prefer Spanish and only 22% English.

So a Spanish version doesn't reach "Latinos" in general; many of them will happily use your English site. It reaches the people who would otherwise call a competitor who speaks their language, or who are buying for a parent who doesn't speak English. That's usually a narrower and more valuable group than the headline number suggests.

Before you build, spend twenty minutes on your own data:

  • Your last fifty inquiries, calls or WhatsApp messages: how many were in Spanish, or came from someone who asked whether anyone speaks Spanish?
  • Search Console, if you have it: queries in Spanish, even a handful, with impressions and no page to land on.
  • Your front desk: how often does someone switch to Spanish to close a sale, explain a price or book an appointment?
  • Your area: the Census data is public by state and county. In California and Texas, more than a quarter of residents age 5 and up speak Spanish at home.

Translate button vs. a real Spanish version

There are three ways a site can "have Spanish", and they aren't the same thing.

Three ways to add Spanish to a website
OptionWhat Google and AI assistants seeWho controls the wordsFits when
Translation widget (translates in the browser)Only the English page: there's no Spanish URL to indexNobody: the tool decides every sentenceYou want visitors to get the gist and don't need to be found in Spanish
Plugin that auto-publishes machine-translated pagesSpanish URLs, often with odd phrasing and English left in menus, forms and emailsThe plugin, unless someone reviews every pageA stopgap for long informational pages, as long as a person checks them
A real Spanish versionSpanish pages with their own URLs, titles and descriptions, linked to their English twinsYou, with a writer or reviewer who knows your customersSpanish speakers are customers you want, not visitors you tolerate

Google is explicit about the first option: it recommends different URLs for each language version rather than using cookies or browser settings to adjust the content language, and notes that Googlebot usually crawls from the US without asking for a language. A widget that switches the text in place gives it nothing to crawl.

The second option is where most bilingual sites live, and it's not automatically wrong. But Google's spam policies list translating content at scale "where little value is provided to users" as scaled content abuse. A reviewed Spanish version of your own pages isn't that. Two hundred unreviewed pages published overnight by a plugin is closer to it than you'd want.

The technical checklist

None of this is exotic, but it all has to be done together. If you're hiring someone, this is what to ask for.

1. One URL per language, in a subfolder

Put the Spanish pages under the same domain, for example yourbusiness.com/es/. Google describes subdirectories as easy to set up and low maintenance; subdomains (es.yourbusiness.com) also work, and a separate domain is rarely worth it for a small business. What doesn't work well is a URL parameter like ?lang=es, which Google doesn't recommend. Spanish slugs (/es/servicios instead of /es/services) are a nice touch for people, not a requirement.

2. hreflang in both directions

Each English page lists itself and its Spanish twin with hreflang annotations, and the Spanish page does the same. Google requires them to be reciprocal: if page A points to page B and B doesn't point back, the annotations may be ignored. Add x-default for visitors whose language you don't serve, usually pointing to English.

For codes, use en-US and es-US, or simply en and es. Don't use es-419, the code for Latin American Spanish you'll see in some translation tools: Google only supports ISO 639-1 language codes and ISO 3166-1 region codes, and names es-419 as an example of a code it doesn't support.

3. No automatic redirects by language

It's tempting to send anyone whose browser is set to Spanish straight to /es/. Google advises against automatically redirecting users from one language version to another, because it can stop both people and crawlers from reaching every version. Plenty of bilingual people browse with English settings and want Spanish, or the other way around. Offer the choice; don't make it for them.

4. A language switch that goes to the same page

The switch should take someone from the English services page to the Spanish services page, not dump them on the Spanish homepage. It sounds obvious, and it's easy to get wrong. Label it with the language's own name, Español, not a flag: a Mexican flag says nothing to a customer from Puerto Rico or Venezuela.

5. lang on every page, and on the mixed bits

Declare lang="es" on the html element of Spanish pages and lang="en" on English ones. Google doesn't use it to detect language, it reads the visible content, so don't expect rankings to move. It matters for accessibility: WCAG asks for the page's language (level A) and for passages in another language (level AA) to be marked up, so a screen reader doesn't read Spanish with English pronunciation.

6. Everything behind the page, in Spanish too

This is where most bilingual sites fall apart. Check the form labels and error messages, the confirmation email, the booking confirmation and reminder, the WhatsApp greeting, the cookie banner and the 404 page. A customer who fills in a Spanish form and gets an English confirmation email learns that the Spanish was a facade.

7. Tell machines you speak Spanish

In your structured data, a ContactPoint can list availableLanguage with English and Spanish, and schema.org recommends BCP 47 codes for it. Say it in plain text too, on the contact page and in the footer: "Hablamos español" next to the phone number. AI assistants quote text more readily than they infer it from markup.

Which Spanish to write in

Spanish in the US is mostly Mexican in origin, with large Puerto Rican, Cuban, Salvadoran, Dominican, Colombian and Venezuelan communities, and how many of each depends heavily on your city. The safe default for a website is a neutral US Spanish: plain, warm, using usted or tú consistently (tú is common for retail and food, usted for health, legal and finance).

This is where being native Spanish speakers from Argentina cuts both ways. We know the language; we also know our own Spanish isn't your customers' Spanish. In Buenos Aires you book a turno at the dentist; in Houston it's a cita. We'd say auto where most of your customers say carro. That's why we write in neutral Spanish and want the selling pages reviewed by someone who talks to your customers every day, ideally someone on your team.

  • Use the words your customers use, even when a dictionary disagrees. If they call it aseguranza, decide consciously whether your page says seguro, aseguranza or both.
  • Keep your brand name, product names and service names consistent with the English site, or customers won't know it's the same thing.
  • Spell out dates (8 de octubre) instead of 10/8, which half your Spanish-speaking readers will read as August 10.
  • Don't translate your prices into something new: same dollars, same terms, same fine print. If the Spanish page promises something the English page doesn't, you've made a promise.
  • Write titles and meta descriptions in Spanish from scratch. A translated title is usually too long and loses the keyword people actually type.

A practical split: write or carefully review the homepage, the service pages, the pricing page and the contact page by hand. Longer informational pages can start from a machine translation as long as a person reads every one before it goes live. If your sector has rules about what you tell customers, such as health, insurance, lending or legal services, ask your lawyer which documents need to exist in Spanish once you advertise in Spanish.

What it costs (and the cost nobody quotes)

Our published prices start at USD 800 for a landing page, USD 1,500 for a business website, USD 1,200 for a WordPress site and USD 3,000 for an online store. A second language adds scope, so we quote a bilingual build as part of the project instead of publishing a separate number. Adding Spanish to an existing English site is a different scope from building both at once, so tell us which one you have.

The cost that matters more comes afterward. Every new page, seasonal offer, price change and blog post now has two versions, and the Spanish one is the one that quietly falls behind. Six months later the Spanish site lists last year's prices and a phone extension nobody answers. Before you launch, decide who updates the Spanish and who answers when someone writes in Spanish. If the honest answer is nobody, start smaller.

When Spanish can wait (or start small)

If your last fifty inquiries were all in English and nobody on your team speaks Spanish, a full Spanish site can wait. A Spanish version that leads to a phone nobody can answer in Spanish does more harm than none.

There's a middle step that works well for many local businesses: one solid Spanish landing page for your main service, with its own URL, a real title, a Spanish form that sends a Spanish confirmation, and a clear note about when someone who speaks Spanish is available. It's cheap to build, easy to keep current, and it tells you within a few months whether a full version is worth it.

Frequently asked questions

Does my small business website need a Spanish version?

Only if Spanish speakers are customers you want and can serve. Look at the language of your recent inquiries and calls, and at Spanish queries in Search Console if you have it. Most US Latinos are comfortable in English, so the case for Spanish rests on the customers who aren't, and on whether someone on your side can answer them in Spanish.

Is Google Translate or a translation plugin enough?

A widget that translates in the browser isn't a Spanish version: there's no Spanish URL for Google or AI assistants to read, and you don't control the words. A plugin that publishes machine-translated pages does create URLs, but Google's spam policies count unreviewed translation at scale with little value to users as scaled content abuse. Machine translation is fine as a first draft if a person reviews every page.

Should I use a subfolder, a subdomain or a separate domain for Spanish?

For most small businesses, a subfolder such as /es/ on the same domain. Google describes subdirectories as easy to set up and low maintenance, and the Spanish pages share the authority of your main site. Subdomains work too. Avoid URL parameters like ?lang=es, which Google doesn't recommend.

Which hreflang code should I use for Spanish in the US?

es-US, or simply es. Don't use es-419: Google only supports ISO 639-1 language codes with ISO 3166-1 region codes, and lists es-419 as unsupported. Whatever you choose, every English page must point to its Spanish twin and back, and an x-default should cover everyone else.

Should I redirect visitors to Spanish automatically if their browser is in Spanish?

No. Google advises against automatic redirects between language versions, because they can keep people and crawlers from reaching every version. Many bilingual people browse with English settings. Show a clear language switch, labeled Español, that leads to the same page in the other language.

Can an agency outside the US write my Spanish content?

Yes, if they write for your customers and not for a textbook. Ask which variety of Spanish they'll use, whether usted or tú, and who reviews the pages that sell. We're native Spanish speakers in Buenos Aires and we say so up front: we write neutral US Spanish and want someone who talks to your customers to review the key pages.

ShareXLinkedInWhatsApp

Found this useful? Add us as a preferred source in Google.

(Keep reading)