Spanish-Language Pages and Hreflang: Reaching Customers Who Search in Another Language

# Spanish-Language Pages and Hreflang: Reaching Customers Who Search in Another Language Plenty of service businesses serve customers whose first language is not English, and almost none of them build a website those customers can actually find. The work happens in Spanish or Vietnamese or Arabic on the phone, but online the business publishes one English site and hopes. Meanwhile, real searches are happening every day in the customer's own language — and in many markets there is far less competition for those searches than for the English equivalents. This guide covers how multilingual pages work on a service-business site: when adding them makes sense, how the technical pieces (hreflang, translated metadata, separate URLs) fit together, the mistakes that get multilingual pages ignored, and a sensible order of operations for a small business doing this for the first time. ## Start with demand, not with the idea of translation The first question is not technical. It is whether customers in your service area actually search in another language. You likely already know the answer from your own operation: the languages your office uses on the phone, the neighborhoods your crews serve, the languages on intake paperwork. Confirm it with search data: Google Keyword Planner and Google Search Console both break results out by language, and typing seed phrases — "plumber," "shuttle to the airport," "divorce lawyer" — into Keyword Planner with Spanish selected will show you whether meaningful volume exists for your markets. If the volume is there, you have found something valuable. English-language local search in most metro areas is brutally competitive; the same queries in Spanish often return thin results, auto-translated pages, or nothing local at all. A service business that publishes genuinely useful Spanish-language service pages is frequently the best result available for that query — and search engines have no bias against rewarding it. If the volume is not there, stop. A translated site nobody searches for creates maintenance burden and thin content, and thin content is a burden on the rest of the site. Multilingual SEO is an expansion into proven demand, not a checkbox. ## How multilingual pages are structured When you decide to add a second language, every translated page needs its own URL. You never swap content back and forth on one address based on browser settings — crawlers see one version, users see the wrong one half the time, and neither can share or link to the page reliably. The two common patterns for a small site are a language folder, such as yourcompany.com/es/services/, and a language subdomain, such as es.yourcompany.com. For a service business, the folder approach is usually the better default: it keeps everything in one property, one analytics view, and one crawl, and it lets the new pages sit inside the site structure you have already built. Each page gets translated — genuinely translated, not machine-pasted. This is the point where many multilingual projects fail before the technical work even starts. A raw machine translation of a service page reads as exactly what it is: word-for-word text with none of the phrasing a native speaker uses. Customers notice, and the page quietly fails to convert even if it ranks. Budget for a human pass by a native speaker who knows your trade's vocabulary, or use machine translation as a first draft only. The difference shows up in details an outsider would never catch: the common regional word for a water heater, the way a price quote is usually described, the formality level customers expect. While translating, do not translate the things that identify you. Business names stay as they are. Location names generally stay in their standard local form. And keep the translated page aligned page-for-page with the English original — the Spanish version of your drain-cleaning page should cover the same service, not a merged or shortened variant. ## Hreflang: telling search engines which page speaks to whom Once two language versions of the same page exist, search engines need help understanding their relationship. Without it, Google may guess, show the English page to a Spanish-speaking searcher, or treat the two pages as duplicates competing with each other. Hreflang is the annotation that solves this: a small piece of markup on each page that says, in effect, "this page serves Spanish speakers, and here is its English twin." The implementation has a few rules that must be followed exactly or the annotation does nothing: **Hreflang is always reciprocal.** If the Spanish page declares an English alternate, the English page must declare the Spanish alternate back. One-directional annotations are ignored. **Every page annotates itself.** A page includes a hreflang entry pointing to its own language as well as to the others in the set. **Language codes follow the standard.** The values are ISO codes — "es" for Spanish, "en" for English — optionally combined with a region, such as "es-mx" or "es-us," when you need to target a country. For a service business, the bare language code is usually right: you want Spanish speakers in your metro, wherever their country of origin. **There is an English-default fallback** — a special annotation marking which page to show when a visitor's language matches none of the set. You can add hreflang in the page's HTML head, in XML sitemaps, or in HTTP headers. On a small WordPress or standard HTML site, tags in the head are simplest; on a larger site, sitemap annotations scale better. If you use a mainstream SEO plugin, it can generate the tags for you — but generate, then verify. Hreflang errors are famously silent: the tags sit in the source code looking correct while a wrong code or a missing reciprocal entry quietly disables the whole set. Search Console's international targeting reports and any hreflang validator will check a page pair in seconds. One more thing to translate while you are in the head of the page: the title tag and meta description. Leaving English titles on Spanish pages is one of the most common multilingual mistakes, and it wastes the single strongest on-page element. The translated title should target the actual Spanish search phrase, which is often not a word-for-word translation of the English keyword — keyword research in the target language finds the phrase people really type. ## The mistakes that get multilingual pages ignored Beyond untranslated metadata, a handful of failure modes account for most disappointing multilingual launches: **Machine-only translation shipped as final.** Covered above, and worth the emphasis: it fails both readers and rankings, because search systems are increasingly good at recognizing low-value translated text. **One switcher link, buried.** A language switcher hidden in the footer does almost nothing. The pages need to be reachable like any other page — linked from the navigation, cross-linked between language versions, and present in the XML sitemap. Internal links carry both crawlers and authority to the new pages; without them, the Spanish section is an island. **Mixed-language pages.** A Spanish page whose headings are Spanish but whose service list, form labels, and error messages are still English serves nobody well. Translate the whole experience, including the form the customer actually submits. **Assuming Google only.** Spanish speakers in the United States search Google overwhelmingly, but the general rule for multilingual work holds: verify how the pages render and index everywhere you want to appear, including Bing, which has real usage in some language communities. **No conversion path.** If your Spanish pages rank and then funnel visitors to an English-only phone tree or contact form, you have built a leaky pipeline. Decide how a Spanish-speaking lead gets served — a bilingual staff member, a translated contact form with Spanish confirmation, at minimum a clear statement of which languages your team handles. ## A sane order of operations For a first multilingual page set, this sequence works: 1. **Confirm demand** with keyword research in the target language for your market. 2. **Pick two to five pages to start** — the homepage, your top service, your contact or booking page. Not the whole site. Learn on a small set. 3. **Translate properly**, with a native speaker reviewing the final text. 4. **Build the pages in a language folder**, page-for-page against the English originals. 5. **Add reciprocal hreflang, translated titles and descriptions, and a visible language switcher.** 6. **Submit the sitemap**, then watch Search Console for indexing and hreflang errors over the following weeks. 7. **Expand only what earns its place.** If the Spanish drain-cleaning page picks up impressions and calls, translate the next tier of services. If a page sits invisible for months, fix it before adding more. Multilingual SEO rewards the same patience as everything else in organic search: the pages need to be crawled, evaluated, and trusted, which takes time even when the execution is right. But the payoff is a durable one — you become the best answer for a whole audience your competitors are ignoring, in a language your customers actually think in. ## Helpful Resources - Learn more about [how SEO Done works](https://seodone.ai) and what it does. - Browse the full [feature overview](https://seodone.ai/features) for details. - Read more guides on the [SEO Done blog](https://seodone.ai/blog).