A bilingual website is one where every page exists in two languages at separate, indexable URLs, with the site telling both visitors and search engines which version is which. In New Mexico that second language is almost always Spanish. About a quarter of households in the state speak Spanish at home, the highest share of any state in the country, and in Santa Fe nearly half the population is Hispanic.
So the question I get from clients is rarely whether a Spanish version would be useful. It is how much work this actually is. The honest answer: the plugin is the cheap part, the translation is the expensive part, and the maintenance is the part nobody budgets for.
Three different things people mean by “bilingual”
Before pricing anything, pin down which of these you are asking for. They differ by roughly an order of magnitude.
- A fully translated site. Every page, post, form, and menu item exists in both languages. Cleanest for the visitor, most expensive to build and to keep current.
- A partial translation. The pages a Spanish-speaking visitor needs in order to act — services, eligibility, hours, location, contact — exist in Spanish. The 2019 blog archive does not. This is what most small businesses should actually build.
- A dual-audience site. The Spanish side is not a translation at all; it is different content for a different audience, with its own pages and its own emphasis. Real, occasionally correct, and effectively two websites.
Most projects that go badly went badly because the client was picturing the second option and the estimate was written for the first.
The plugin is the cheap part
WordPress has no multilingual capability in core, so this comes down to which plugin manages the second set of content. Three are worth your attention, and current pricing is modest:
- Polylang. The free version runs on more than 800,000 sites and is genuinely sufficient for a two-language site translated by hand. Polylang Pro is about €99 per year for one site; WooCommerce support costs extra.
- WPML. The Multilingual CMS tier is about €99 per year covering three sites, and it bundles the pieces that usually turn into a problem later — string translation, custom field translation, and WooCommerce.
- TranslatePress. Roughly $89–$199 per year. Its distinguishing feature is front-end visual editing: you translate on the live page rather than in a back-end table, which non-technical staff find far easier.
All three create real URLs for the second language, usually under a /es/ prefix. That matters, and it is the single dividing line between a bilingual site and a translation widget. A widget that swaps the text in the browser creates no page for Google to index, which means it earns you nothing in Spanish-language search.
One warning worth its own sentence: translations live inside whichever plugin you chose, in that plugin’s own data structures. Switching later is a migration, not a settings change. Pick once, deliberately.
What the translation actually costs
This is the number that decides the project. Professional human translation for English to Spanish generally runs $0.15–$0.30 per word. Machine translation with human post-editing — a translator cleaning up an AI first pass — typically runs $0.05–$0.15 per word, commonly cited as 15–30 percent cheaper than full human translation.
Put that against a real site. A twelve-page small-business site averaging 500 words a page is about 6,000 words. At those rates, that is roughly $900–$1,800 fully human, or $300–$900 post-edited. Not nothing, and not the five figures people brace for.
The recurring cost is the one that surprises people. Every new service page, every blog post, every price change is now a second small invoice and a second publishing step. Sites that go stale in one language and current in the other are worse than sites that were only ever in English, because the Spanish version quietly becomes wrong.
Can I just run my site through Google Translate?
No, not as your finished product, for three separate reasons. First, Google’s own spam policies list automated transformations, translation among them, as an example of scaled content abuse when little value is added for users. Second, Google determines a page’s language from its visible content rather than from a language attribute or a URL, and advises keeping each page in a single language rather than showing translations side by side — so a widget-translated page is not reliably understood as a Spanish page at all. Third, and most practically, an unreviewed machine translation of an intake form, a fee schedule, or a legal disclosure is a liability rather than a shortcut.
Machine translation as a first draft, reviewed by a fluent human before it publishes, is a different thing entirely and is now how most of this work gets done. The dividing line is the review, not the tool.
Which pages actually need to be translated
Nonprofits and agencies that receive federal financial assistance already have a framework here. Under Title VI, recipients must take reasonable steps to give people with limited English proficiency meaningful access to their programs, which in practice means translating “vital documents.” A widely used benchmark is any language spoken by 5 percent of the population served, or 1,000 people, whichever is smaller.
If you have no such obligation, borrow the logic anyway. Translate what someone needs in order to do something: what you offer, who qualifies, where you are, when you are open, how to reach you, and every form. Leave the archive alone until the rest is working.
When I built the site for St. Elizabeth Shelter & Supportive Housing here in Santa Fe, the Spanish translation was one piece of a set of decisions that all pointed the same direction: a mobile-first layout, an interactive facility map, and contact forms routed to the right program rather than a single catch-all address. Someone looking for shelter is doing it on a phone, quickly, under stress, and often not in English. Every one of those constraints argues for the same thing — fewer words, clearer paths, and the language handled without the visitor having to hunt for it.
The parts people forget
A site is not bilingual because the body copy is. These are the pieces that get missed, in roughly the order I find them:
- Forms and everything downstream of them. Field labels, validation errors, the confirmation screen, and the auto-response email. A Spanish form that sends an English receipt undoes itself.
- The language switcher. It belongs on every page, visible without scrolling, and it should keep the visitor on the page they were reading rather than dumping them on the Spanish homepage.
- hreflang annotations. These tell Google which pages are language variants of each other. Without them, the two versions compete instead of cooperating.
- Titles and meta descriptions. If these stay in English, the Spanish pages rank for nothing, because that is the text the search result displays.
- Alt text, and any words baked into an image. Text inside a graphic cannot be translated by any plugin. It has to be a second graphic.
- PDFs, menus, footers, cookie notices, and plugin strings. The unglamorous 20 percent that is half the work.
- Your typeface. Spanish needs á é í ó ú ñ ü and the inverted ¿ and ¡. Most text faces have all of them. Display and script faces frequently do not, and you find out when a headline renders with a hole in it. Check the character set before the launch, not after.
Where to start
Before you buy anything, spend an hour on evidence. Look in Google Search Console and your analytics for Spanish-language queries and for visitors whose browser language is set to Spanish. Ask whoever answers your phone how often the call comes in Spanish. Then pick the five pages that would let one of those callers get what they need without speaking to you at all.
Five pages translated well and kept current will do more than forty pages translated once and left to drift. Start there and expand when the traffic tells you to.
Patrick Iverson is a brand strategist and custom WordPress developer in Santa Fe, New Mexico, running an independent practice here since 2001 and building on WordPress since 2003. If a second language is on the table for your site and you want a straight answer about scope before you commit to it, that is a conversation worth having early.
