Bilingual website: one site or two?

Once a Wichita business owner decides they want to reach Spanish-speaking customers, the next question is always the same. Do I build one website with both languages, or two separate websites, one in English and one in Spanish?

It's a fair question, and the internet gives terrible answers to it. Most of what you find is either written for giant global brands or is trying to sell you a plugin. So here's the plain version, built for a local business, with the parts that actually affect whether you get found on Google.

Short answer first. For almost every local business, one website that handles both languages is the right call. Two separate sites usually creates more work, more cost, and more ways to hurt your search rankings. The catch is that one site has to be built correctly, and most aren't.

Why one site usually beats two

Two separate websites means two of everything. Two sets of hosting, two things to update every time your hours or prices change, and two properties fighting for the same authority in Google's eyes. Split your effort across two sites and each one is weaker than a single strong site would have been.

One website, built the right way, keeps all your authority in one place. English pages and Spanish pages support each other. When someone links to your site or leaves a review, the whole thing benefits, not just half of it. You update once. You pay for one setup. And Google gets a clean, clear picture of who you are and who you serve.

The people who tell you to build two separate sites are usually solving a problem you don't have. Unless you're running two genuinely different businesses in two different countries, one bilingual site is simpler and stronger.

The real issue is structure, not translation

Here's the mistake that trips people up. They think a bilingual website is an English website with a translate button slapped on top. It's not.

A translate button, the kind that page builders and free plugins offer, generates Spanish on the fly and doesn't create real pages that Google can find and rank. To a search engine, that content might as well not exist. You get the cost of looking bilingual with none of the search benefit.

A bilingual website done right gives every page a real, permanent home in both languages. Your English service page lives at one address, and its Spanish twin lives at its own address. Both are real pages Google can crawl, index, and show to the right person. That's the whole difference between a site that quietly pulls in Spanish searchers and one that just looks the part.

Meet hreflang, your quiet traffic cop

This is the one piece of technical vocabulary worth knowing, and it isn't complicated.

Hreflang is a small tag you add to each page that tells Google, in plain terms, which language a page is for and which pages are its equivalents in other languages. Think of it as a note to Google that says, this is the English version, and over here is the matching Spanish version, please show each person the right one.

Get it right and Google serves your English page to English searchers and your Spanish page to Spanish searchers, automatically. Skip it or botch it and Google gets confused, sometimes showing the wrong language to the wrong person, sometimes treating your two versions as duplicate content and trusting neither.

One more small but important piece goes with it, called a self-referencing canonical. In plain terms, each page also needs to clearly claim itself as the real version, so Google doesn't mistake your Spanish page for a copy of the English one. You don't need to memorize this. You just need whoever builds your site to actually do it.

Done properly, Google doesn't penalize you for having two languages at all. There's no duplicate-content problem when the tags are correct. The only businesses that get burned are the ones whose sites were built without this plumbing.

Subdirectory or subdomain: keep it simple

You may hear about where the Spanish version should live. The two common options are a subdirectory, which looks like yoursite.com/es/, or a subdomain, which looks like es.yoursite.com.

For nearly every local business, the subdirectory is the better choice. It keeps everything under one roof, which means all your search authority stays together and the setup is simpler. Subdomains and separate country domains have their place for large international companies, but they add complexity a Wichita business doesn't need. Keep it under one domain and move on.

The maintenance cost nobody budgets for

The ranking argument gets all the attention, but the reason two sites really fall apart is duller than that: keeping both current is twice the work, forever.

Your hours change. Your prices change. You add a service, drop another, change your phone number, get a new logo. With one properly built bilingual site, that's one edit. With two separate sites, it's two edits every single time, and the second one is the one that gets skipped when you're busy.

I've seen the result more than once: the English site is current and the Spanish site is quietly eighteen months out of date, still advertising a service that ended and a price that went up. That's worse than having no Spanish site, because a customer acted on wrong information and now has a genuine reason to be annoyed with you.

Two sites also means two hosting bills, two SSL certificates, two sets of updates, two things that can break at 7pm. For a one-location local business, that overhead buys you nothing you couldn't get from a single site built properly in the first place.

Not every page needs to exist in both languages

This is the practical release valve, and it's the thing that makes bilingual affordable for a small business.

Translate the pages that earn money and build trust: your homepage, every service page, your main location pages, contact, and about. Those are what a Spanish-speaking customer needs in order to understand you, trust you, and reach you. That's usually a manageable number, not an infinite project.

What doesn't need translating on day one is the long tail. Blog posts, case studies, and detailed resource pages can be added over time as they prove useful, and some may reasonably exist in only one language forever. A post about a topic only your English-speaking buyers search for doesn't need a Spanish twin sitting there empty.

The important part is that hreflang only points between pages that actually exist. A page with no counterpart simply doesn't carry the tag, and nothing breaks. What breaks things is pointing at a translated version that isn't really there, or creating half-empty Spanish pages just to have matching URLs. Fewer, genuinely useful Spanish pages beat a complete set of thin ones.

Three mistakes that quietly hurt your rankings

Most bilingual sites aren't sabotaged by one big error. They're held back by a few small ones that add up.

The first is auto-translate plugins. They feel easy and cost nothing, and they give you Spanish that reads like a machine wrote it while creating no real pages to rank. Easy to start, expensive in lost leads. It's the same trap page builders fall into with speed, which I cover in Elementor vs. a hand-built site.

The second is missing or broken hreflang. Without it, Google guesses, and it often guesses wrong. This is the single most common reason a bilingual site fails to show up in Spanish search.

The third is half-translated sites. The homepage is in Spanish but the contact page, the forms, and the fine print are still in English. Nothing breaks trust faster than a site that switches back to English the moment a customer tries to actually do business with you. If you commit to Spanish, carry it all the way through checkout, forms, and follow-up.

What "done right" looks like

A bilingual website that works has a few things in common:

• Every page exists in both languages at its own real address.
• The translation was done by a person, not a machine, so it reads like a neighbor wrote it.
• Hreflang and canonicals are in place so Google shows the right version to the right person.
• Everything lives under one domain, usually with the Spanish version in a /es/ subdirectory.
• The whole experience, from the first click to the thank-you page, stays in the visitor's language.

That's not a longer list of features. It's a difference in how the thing is built. It's also the difference between web design and web development, which I explain in web design vs web development, because a bilingual site that ranks needs both done well.

What this looks like in practice

3 Keys & Co is the clearest example I have. A family real estate team in Wichita whose entire online presence used to be three profile pages on their brokerage's agent directory. They now have a 27-page site they own outright, bilingual throughout, with six suburb pages for the areas they actually work, and a perfect 100 on Google PageSpeed.

Notice that the bilingual part didn't come at the cost of the speed part. That's the payoff of building it as one properly structured site rather than bolting a second language on later, or running a duplicate site alongside the first. Twenty-seven pages in two languages is a lot of content, and it still arrives instantly because the structure was decided at the beginning.

The site you're reading right now works the same way. Every page exists in English and Spanish with its own Spanish URL, connected by hreflang, under one domain. I'd rather show you the thing working than describe it, and you can check any of it yourself.

Getting this wrong later is expensive

One reason to decide this early: retrofitting is genuinely painful. Adding a second language to a site that wasn't designed for it usually means new URLs for the translated pages, hreflang added after the fact, redirects to keep from losing what you've earned, and a navigation system that has to learn how to switch languages without dumping people on the homepage.

None of that is impossible, and I've done it. It's just more work than doing it right the first time, and it carries risk that building it correctly from the start doesn't. If you're getting a new site anyway and there's any chance you'll want Spanish within a couple of years, say so at the beginning. The structural decisions cost almost nothing to make early and quite a lot to unwind later.

If you're still deciding whether a bilingual site is worth it in the first place, start with do you need a bilingual website in Wichita. If you already know you want one and want it to actually get found, read how Spanish-speaking customers find you on Google next.

Frequently asked questions