San Antonio business owners ask this question constantly: does the website need a Spanish version? The honest answer depends on who walks through your door and what those customers are trying to do once they land on the site. This guide explains when a bilingual website earns its cost, what the build actually involves, and where owners waste money getting it wrong.
Why bilingual websites matter in San Antonio
San Antonio is one of the most Spanish-speaking large cities in the United States, and a great many households across the city speak Spanish at home. For a bakery on the West Side, a dental clinic near the Medical Center, or an electrician covering Converse and Loop 410, some share of the people searching for that service search and read in Spanish first. A website that exists only in English asks those customers to translate on their own before they can decide whether to call.
San Antonio neighborhoods differ a lot, though. A boutique in Alamo Heights and a tire shop on the West Side do not serve the same mix of customers. First, look at where your walk-in customers actually come from. Then check which language your phone calls and messages arrive in. In practice, a shop that already takes half its calls in Spanish has its answer, while a studio whose customers all email in English probably does not need a second language yet.
What a bilingual website actually means
A bilingual website is not one page with a translate button. A bilingual website is a second complete set of pages, each with its own URL, its own headline, its own buttons, its own forms, and its own title in the search results. Every element a visitor can read needs a Spanish counterpart: the navigation menu, the contact form labels, the error message that appears when a field is blank, and the thank-you page after a submission.
Browser translation widgets are a different thing entirely. Automatic translation tools change text inside the visitor’s browser, but search engines do not index that translated text, so the Spanish version never appears in Spanish search results at all. Finally, remember the parts outside the website: a Spanish landing page that leads to an English-only voicemail breaks the promise the page just made. Good web design matches the site to how the business actually answers the phone.
Three ways to build a bilingual WordPress site
WordPress handles two languages in three common ways, and the right choice depends on how much the two versions will differ from each other.
- A translation plugin pairs each English page with a Spanish twin inside one site. Best fit for most small businesses.
- A multisite network runs the Spanish site as a separate site sharing one installation. Worth it when the two audiences need genuinely different content.
- Hand-built duplicate pages means no plugin at all, just a second set of pages. Cheapest to start, hardest to keep in sync.
Plugin choice carries long-term cost, because a translation plugin touches every page on the site and is painful to remove later. For example, a restaurant with a single menu page and a contact form rarely needs multisite. Our WordPress development work usually starts with the simplest option that fits the page count.
How Google handles two languages
Search engines treat each language version as a separate page, so each version needs its own clear address and a clear signal about which language it holds. The standard signal is an hreflang tag: a line in the page’s head that tells Google this English page has a Spanish equivalent at a specific URL, and the reverse. Without hreflang, Google often picks one version and ignores the other, or shows the wrong one to the wrong searcher.
URL structure matters too. Subfolders like /es/servicios/ keep all the authority on one domain and are the simplest structure for a small business. For example, a plumbing company might run /services/water-heaters/ alongside /es/servicios/calentadores-de-agua/, each listed in the sitemap and each linked to the other. Local SEO work then runs twice, because the Spanish pages need titles, descriptions, and headings written in Spanish rather than translated word for word.
Machine translation versus a human translator
Machine translation has improved enough to be a reasonable starting point, but machine translation still fails on the sentences that sell. Marketing copy carries tone, idiom, and local phrasing that automated tools flatten. A headline that sounds confident in English can land as stiff or faintly robotic in Spanish, and a customer who notices that stiffness loses a little trust in the business behind the page.
Then there is the regional question. Spanish in San Antonio is not the Spanish of Madrid or Buenos Aires, and word choices give that away fast. First, run a machine pass to get full coverage cheaply. Then pay a human who speaks the local Spanish to rewrite the headlines, the service descriptions, and the contact page. In practice, that split keeps the cost reasonable while fixing the pages that actually turn a visitor into a phone call.
What to translate first on a tight budget
A full second site doubles the page count, so translating everything at once is rarely the right first move. Translate in the order a customer moves through the site. The homepage comes first, because the homepage is where most Spanish searches land. Then the one or two services that bring in the most revenue. Then the contact page, including the form fields and the confirmation message.
Pages that can wait include the blog, long About pages, and detailed FAQ content. For example, a dental clinic might publish Spanish versions of the homepage, cleanings, emergency visits, and contact, then leave eleven other procedure pages in English for a later phase. A typical Satxly project runs $5,000 to $20,000 over six to ten weeks, and a staged bilingual rollout fits inside that range far more comfortably than translating every page on day one.
Mistakes that cost San Antonio businesses customers
The most common bilingual mistake is a half-finished second language. A visitor clicks the Spanish link, reads a Spanish homepage, then hits an English contact form with English field labels and an English error message. That visitor now has to switch languages in the middle of a decision, which is exactly the friction the Spanish version was supposed to remove.
- Flag icons instead of language names. Write Español, because a language is not a nationality.
- A language switcher buried in the footer instead of sitting in the header where visitors look for it.
- Sending every Spanish click to the Spanish homepage rather than to the Spanish version of the page the visitor was already reading.
Each of these mistakes is cheap to avoid during a build and expensive to retrofit afterward. Decide the language strategy before the first page is designed, not after the site launches.
Deciding what your business needs
Satxly builds websites only for San Antonio small businesses, so the bilingual question comes up in most project conversations. If you are weighing whether your next site needs a Spanish version, get in touch and we will work through who your customers are, which pages matter, and what a staged bilingual rollout would cost. Projects run on video calls, and we write back within one business day.
