How to make a bilingual website in English and Spanish

To make a bilingual website that works, publish each language as its own set of pages at its own URLs, write each one for the people who read that language, and connect every English page to its Spanish twin with hreflang so Google shows each searcher the right one. A translate widget skips all of that: the Spanish only exists inside the visitor’s browser, so there is no Spanish page for Google to find.

This guide shows how to make a bilingual website for businesses in El Paso, Las Cruces and Juárez that sell in both languages: why a widget falls short, how hreflang works according to Google Search Central, and what to check before you launch.

Who reads your Spanish pages here

The numbers decide how much Spanish matters to your business, and they differ a lot within a hundred miles.

• El Paso. 63% of city residents age 5 and up speak Spanish at home, about 406,000 people. About 155,000 of them, 24% of the city, speak English less than “very well” (Census Bureau, 2024 American Community Survey).
• Las Cruces. About 29% speak Spanish at home and about 7% speak English less than “very well” (ACS 2020-2024 five-year estimates).
• Juárez. Mexican consumer law requires product information and advertising in Spanish, with prices in pesos. Another language can be added on top. For a Juárez business the English pages are the addition, as our guide to reaching El Paso customers from Juárez explains.

For a plumber in the Lower Valley, the Spanish pages may be the ones that get the call. For a law office in Las Cruces, a Spanish page or two can be enough. Count before you build.

What a translate widget does, and what it doesn’t

A translate widget is a script that swaps your page’s text for a machine translation in the visitor’s browser, usually after they click a flag or a language menu. Most of them work that way. It looks like a bilingual site, but it falls short in three places.

Google has no Spanish page to show

Google says it determines a page’s language from the visible content, not from code such as the lang attribute and not from the URL. It recommends a different URL for each language version rather than cookies or browser settings. A widget leaves you with one URL whose HTML is in English. When someone in Socorro searches in Spanish for what you sell, a competitor’s Spanish page is a candidate for that search and your widget is not.

Some translation plugins are different: they publish each translation at its own URL. That solves the URL problem. It doesn’t solve the next two.

The visitor’s browser already does it

Chrome shows a Translate button in the address bar when a page is in a language the user doesn’t read. A widget repeats what the browser offers, at the same machine quality. Google’s own Website Translator is now offered only to academic, government, nonprofit and non-commercial sites, according to Google Translate Help, so a business that wants a button ends up with a third-party script on every page.

Machine translation doesn’t know your customers

A translator picks the dictionary word. Your customers may use another one. A machine turns “evaporative cooler” into “enfriador evaporativo”; plenty of people here just say “el cooler”. It turns “auto parts store” into “tienda de autopartes”, while a Juárez customer looks for a refaccionaria. It mixes tú and usted on the same page, when business copy for this region usually holds to usted. And it can’t know that a Juárez customer needs your number with +52 in front, or that your El Paso customer wants to know which bridge is closest.

Google’s spam policies list content scraped and put through “automated transformations”, translation included, as scaled content abuse when the pages add little value. Machine-translating your own pages isn’t scraping, but the lesson carries over: a Spanish page has to be worth reading on its own.

How hreflang works

Hreflang tells Google that two or more pages are versions of each other in different languages, so it can show the Spanish one to Spanish searchers and the English one to English searchers. Google Search Central documents three ways to declare it: link tags in the HTML head, HTTP headers, or your sitemap. They are equivalent. For most small sites the HTML tags are the easiest to check.

On an English plumbing page, the head would include:

<link rel="alternate" hreflang="en" href="https://example.com/services/plumbing/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/servicios/plomeria/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/plumbing/" />

The Spanish page carries the same three lines. The rules that trip people up:

1. Each version lists itself and every other version. The English page names the English URL too.
2. Return links are required. In Google’s words, if two pages don’t both point to each other, the tags are ignored. A Spanish page that forgets to link back cancels the pair.
3. Codes follow standards. The language is ISO 639-1 (en, es). A region is optional and uses ISO 3166-1 Alpha 2 (es-MX, en-US). A region on its own, like “mx”, is invalid.
4. x-default is the fallback. Google uses it when no other version matches the visitor’s browser setting.
5. Use full, final URLs. Point to the live page with https, not a redirect or a staging copy.

es or es-MX?

If one Spanish version serves El Paso, Las Cruces and Juárez, use es. That covers every Spanish searcher. Add region codes only when you publish genuinely different versions, for example Spanish pages with peso prices for Mexico and others with dollar prices for the US. Two copies of the same Spanish page with different region codes are just more tags to keep in sync.

Set the lang attribute anyway

Google ignores lang for language detection, but screen readers don’t. The W3C’s guidance for WCAG 2.2 Success Criterion 3.1.1, Level A, explains that a declared language lets screen readers load the right pronunciation rules. Put lang=“es” on the html element of every Spanish page, and mark any Spanish phrase inside an English page with its own lang attribute.

Don’t redirect people by language

Google advises against automatically redirecting visitors from one language version to another, because it can keep both people and search engines from reaching every version. A bilingual customer with an English phone may still want your Spanish page. Give them a visible link instead, and make it go to the matching page, not to the Spanish home page.

How to organize the URLs

Keep English and Spanish in the same domain, with Spanish in its own folder. This site uses that pattern: /services/website-design/ in English and /es/servicios/diseno-de-paginas-web/ in Spanish. Translate the slug as well as the page, without accents, so a Spanish speaker can read the address.

Then match the pages one to one. Every English service page gets a Spanish page with its own title tag, meta description and headings written in Spanish. If a page only makes sense in one language, publish it in that language and leave it out of the hreflang pairs.

What else needs a Spanish version

The pages are the obvious part. These are the pieces that usually stay in English by accident:

• Form labels, error messages and the thank-you page.
• The confirmation text or email a customer gets after booking.
• Menus and price lists posted as PDFs or images.
• Your voicemail greeting and the first reply on WhatsApp.
• The privacy notice. If you collect personal data from customers in Mexico, the Mexican data protection law published on March 20, 2025 requires an aviso de privacidad.
• Prices, if you sell to customers in Mexico: the consumer law asks for pesos.

A checklist before you launch

1. Every Spanish page has its own URL and is linked from its English twin.
2. The hreflang tags list both versions, each page lists itself, and every pair links both ways.
3. x-default points to the English page or to a language-choice page.
4. The html element says lang=“es” on Spanish pages.
5. Spanish title tags and meta descriptions are written, not copied from English.
6. The language switch goes to the matching page.
7. No automatic redirect by browser language or location.
8. Forms, error messages and confirmations work in Spanish.
9. Someone who writes Spanish for your customers has read every page.
10. Spanish pages are in your sitemap, and Search Console shows them indexed after launch.

How Rodco Systems builds bilingual sites

We build every bilingual site the way this guide describes, and this site is built the same way. Each language is written separately, every pair of pages carries hreflang with return links and x-default, the Spanish pages are set to lang=“es”, and the language switch goes to the matching page. Forms and confirmations work in both languages. For clients in Mexico, we draft the aviso de privacidad for you or your lawyer to review, and quote in pesos or dollars.

You see your home page before you pay: a free sample, ready in one business day. Approve it and send your logo, photos and business details, and the site can be live in as little as 48 hours. Rodco Systems consistently undercuts local competition, with higher quality, and you get the choice to own your website instead of renting it: no monthly website fee, and the domain, files and accounts stay in your name.

Sources and date

The hreflang rules come from Google Search Central’s pages on localized versions and on multilingual sites, checked on October 2, 2026; Google updated the localized-versions page on September 21, 2026. Language figures are from the Census Bureau’s American Community Survey. We review this guide every quarter and change the date when something changes.

Rodco Systems, El Paso, Texas.