Most "bilingual websites" are an English site with a Google Translate widget bolted to the header. They technically have Spanish. They don't convert in Spanish.
A bilingual website that actually makes money is built as two connected experiences: one in English, one in Spanish, each with its own offer, proof, call to action and follow-up. This guide covers the decisions that matter, from URL structure and hreflang to WhatsApp, lead routing and per-language tracking in GA4. It ends with a checklist you can hand to your developer.
Translation is not localization
Translation swaps words. Localization changes the pitch. A Spanish-speaking homeowner in Houston and an English-speaking one in the same ZIP code may want the same roof, but they often need different reasons to trust you and a different way to take the next step.
Here's what typically changes between versions:
| Element | English page | Spanish page |
|---|---|---|
| Offer | "Free online quote in 60 seconds" | "Cotización gratis. Te explicamos todo en español, sin compromiso" |
| Proof | Star ratings, review count | Video testimonials from Spanish-speaking customers, named bilingual staff |
| CTA | Book online | Escríbenos por WhatsApp, or call a Spanish-speaking rep |
| Follow-up | Automated email sequence | WhatsApp message plus a call from a bilingual rep |
None of this means Spanish speakers want a "simpler" page. It means the objections are different. Common ones we see: "Will someone actually speak Spanish when I call?", "Is there fine print I'll miss?" and "Do you work with people like me?" Answer those on the page, above the fold, and conversion follows.
URL structure: use a /es/ subfolder
You have three common options for hosting the Spanish version:
| Structure | Example | Best for |
|---|---|---|
| Subfolder | example.com/es/ | Most U.S. businesses serving English and Spanish speakers |
| Subdomain | es.example.com | Separate teams or platforms per language |
| Country domain (ccTLD) | example.com.mx | Targeting a specific country, not a language |
For a U.S. business, we recommend the subfolder almost every time. Three practical reasons:
- One domain builds authority once. Links earned by your English pages help the Spanish pages too, because it's all the same site.
- One setup to maintain. One Search Console property, one GA4 data stream, one SSL certificate, one CMS. Less to break.
- It fits the audience. Your Spanish-speaking customers live in the U.S. A .mx or .co domain signals a different country, which is the wrong message and the wrong search signal.
Translate the slugs too. /es/servicios/reparacion-de-techos/ reads better to a Spanish speaker than /es/services/roof-repair/, and it matches the words they type into Google.
Set up hreflang correctly, including x-default
Hreflang tells Google which URL to show to which language audience. Without it, you risk your English page ranking for Spanish searches (or the reverse), and the wrong version eating your clicks.
According to Google Search Central's documentation on localized versions, you can declare alternates in HTML link tags, HTTP headers or an XML sitemap. The rules that trip people up:
- Each language version must list itself and every other version. If the links aren't reciprocal, Google may ignore them.
- Use ISO 639-1 language codes, optionally with a region (
esores-US). You can't use a country code alone. - Use
x-defaultfor visitors whose language doesn't match any version you offer.
Here's what the <head> of both the English and the Spanish services page should contain:
<!-- On https://example.com/services/ AND https://example.com/es/servicios/ -->
<link rel="alternate" hreflang="en" href="https://example.com/services/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/servicios/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/" />
<!-- Canonical points to itself (this one goes on the Spanish page only) -->
<link rel="canonical" href="https://example.com/es/servicios/" />A few notes from real implementations. If you have only one Spanish version, plain es is usually the right code: it covers Spanish speakers everywhere. Set lang="es" on the Spanish page's <html> tag. And never point the Spanish page's canonical at the English page. That tells Google the Spanish version is a duplicate and it may drop it from results.
Language switcher UX: let people choose
The fastest way to annoy a bilingual visitor is to decide their language for them.
- Don't auto-redirect by IP. An IP address tells you where someone is, not what they read. A Spanish speaker in Chicago and an English speaker in Miami both have U.S. IPs. Forced redirects also make it harder for search engines to reach both versions.
- Suggest, don't force. If the browser language is Spanish and the visitor lands on an English page, show a small banner: "¿Prefieres ver esta página en español?" with a one-click link.
- Remember the choice. Store it in a cookie or local storage so the next visit starts in the right language.
- Switch to the equivalent page. The switcher on
/services/should go to/es/servicios/, not the Spanish homepage. - Label each language in its own language. "English | Español." Skip the flags. A Mexican flag or a Spanish flag both leave someone out, and neither means "Spanish."
Send Spanish ads to Spanish landing pages
This sounds obvious. It's also the most common leak we find in audits. A business runs Spanish ads on Meta or Google, and every click lands on the English homepage. You paid for the click and lost the visitor in the first second.
Build message match per language:
- Split campaigns or ad sets by language so budget and results stay separate.
- Point every Spanish ad to a Spanish landing page with the same offer and the same wording as the ad.
- Add a language parameter to your UTMs (for example
utm_content=es_roofquote) so the lead carries its language into your CRM. - Keep the Spanish landing page focused: one offer, one primary CTA, proof from Spanish-speaking customers.
If you spend $3,000 a month on Spanish ads and send them to an English page, you're buying Spanish-language attention and serving an English-language experience. Fix the destination before you touch the bids.
Make WhatsApp a real conversion channel
For many Hispanic customers, WhatsApp is where conversations with family, friends and businesses already happen. A form asks them to wait. A WhatsApp chat lets them ask a question right now, in their words.
Treat it as a conversion path, not a floating green icon:
- Pre-fill the message per page. A link like
https://wa.me/15551234567?text=Hola%2C%20quiero%20una%20cotizaci%C3%B3nopens the chat with "Hola, quiero una cotización" already typed. Use a different message per service so you know where the lead came from. - Track the click as a GA4 event. Otherwise your best channel looks like zero conversions.
- Answer fast, in both languages. Set a bilingual auto-reply and, if you get volume after hours, an AI assistant that qualifies the lead and books a call.
Add a preferred-language field and route the follow-up
Page language tells you what someone read. It doesn't tell you how they want to be contacted. Remember the daughter who fills the form in English for her dad, who'll be the one taking the call.
Add one required field to every form: Preferred language / Idioma preferido, with options English, Español and Either. Also pass the page language in a hidden field. Then use your CRM to:
- Assign Spanish and "Either" leads to a bilingual rep.
- Trigger the email, SMS or WhatsApp sequence in the chosen language.
- Report close rate by preferred language, not just by page.
Speed matters in both languages. A lead that waits a day for someone who speaks Spanish has usually already called your competitor.
Measure conversion per language in GA4
If you can't see results by language, you can't defend the Spanish budget. Set it up once:
- Read the
langattribute of the page (or the/es/path) in Google Tag Manager and send it as apage_languageparameter on every event. - Register
page_languageas an event-scoped custom dimension in GA4. - Mark form submits, calls and WhatsApp clicks as key events.
- Build an exploration comparing sessions, key events and conversion rate by
page_languageand by source.
GA4's built-in "Language" dimension reports the browser setting, which is useful context but not the same thing. Plenty of bilingual users run English browsers and still convert on your Spanish page. Close the loop by matching GA4 data to CRM close rates per language so you're optimizing for revenue, not form fills.
Bilingual website checklist
- Spanish pages live in a
/es/subfolder with translated slugs - Each Spanish page has a localized offer, proof and CTA, not just translated copy
- Hreflang tags list every version, including itself and
x-default - Each version has a self-referencing canonical and the correct
langattribute - No automatic IP-based redirects; the switcher links to the equivalent page and remembers the choice
- Spanish ads point to Spanish landing pages with matching wording
- WhatsApp links are pre-filled per page and tracked as GA4 events
- Every form has a preferred-language field that routes to bilingual follow-up
- GA4 reports key events by
page_language, matched to CRM close rates - A native speaker has reviewed every Spanish page before launch
Get these right and your Spanish pages stop being a courtesy and start pulling their weight. Build it once, measure it per language, and put the budget where the leads close.
Quick answers
Should a bilingual website use a subfolder, subdomain or separate domain?
For most U.S. businesses, use a subfolder such as example.com/es/. It keeps both languages on one domain, so links earned by English pages also help Spanish pages, and you manage one Search Console property and one GA4 stream. Country domains like .mx target a country, not a language, which is the wrong signal for U.S. Spanish speakers.
How do I implement hreflang for English and Spanish pages?
Add link tags with rel=alternate to the head of every language version, listing the page itself and all alternates, for example hreflang en, es and x-default. Google Search Central says each version must list itself and every other version, or the annotations may be ignored. Each page should also keep a self-referencing canonical and the correct lang attribute.
Should I automatically redirect visitors to Spanish based on their location?
No. An IP address shows where someone is, not which language they read, and many U.S. Spanish speakers browse from U.S. IPs with English browsers. Instead, show a small banner suggesting the other language, let the visitor choose, link the switcher to the equivalent page and remember the choice in a cookie or local storage.
How do I track conversions by language in GA4?
Send a page_language parameter with every event through Google Tag Manager, reading it from the page's lang attribute or the /es/ path. Register it as an event-scoped custom dimension, mark form submits, calls and WhatsApp clicks as key events, then compare conversion rates by page_language. Match the results to CRM close rates per language.