Why Your Agency's Spanish Page Never Gets Cited by AI

The gap: how big the Spanish-speaking market already is

Start with the plainest number available: who is actually enrolling in ACA coverage right now. The Office of the Assistant Secretary for Planning and Evaluation, the research arm of HHS, publishes an annual breakdown of HealthCare.gov plan selections by race and ethnicity. The October 2024 edition, covering Open Enrollment Periods from 2015 through 2024, states plainly that Latino consumers' share of plan selections increased by nine percentage points, from 20.4 percent in 2020 to 29.4 percent in 2024¹. In raw numbers, Latino consumers selecting a HealthCare.gov plan grew from 3.4 million in 2023 to 4.8 million in 2024, a 40.1 percent jump in one year, and a 185 percent increase since 2020¹. Total HealthCare.gov plan selections hit a record 16.4 million in 2024¹. Read those together and the takeaway is simple: almost three out of every ten people choosing a Marketplace plan on the federal platform right now are Latino, and that share is still growing.

Layer in where those people live. The Census Bureau's own 2024 population release, using Vintage 2023 estimates as of July 1, 2023, put the U.S. Hispanic population at 65,219,145, a gain of nearly 1.2 million people in a single year². Among states, Texas held the second-largest Hispanic population in the country at 12,135,690, and Florida held the third-largest at 6,197,465, trailing only California's 15,760,437². Texas and Florida also posted the largest raw numeric increases of any state that year, adding 242,306 and 191,373 Hispanic residents respectively². If your book of business touches either state, or any state with a sizable Hispanic population, this is not a niche audience. It is a fast-growing share of the exact market you're already licensed to serve.

None of this reads like a one-year blip that reverses on its own. The Latino share of HealthCare.gov plan selections climbed every single year from 2020 through 2024, and the state population figures behind it moved the same direction over the same stretch^1,2. A trend that consistent, running that long, is the kind of thing worth building for rather than waiting out. An agency that treats this as next year's project is choosing to sit out several more years of a market that keeps getting bigger while it waits.

What most agency sites actually publish

Even the federal government treats this seriously enough to run a fully separate site. HealthCare.gov's Spanish-language counterpart lives at its own domain, CuidadoDeSalud.gov, which we confirmed live this session resolves to its own Spanish-language homepage, not a translated overlay on the English site⁵. CMS also publishes its Marketplace eligibility notices, redetermination letters, and special enrollment period notices in dedicated Spanish-language document sets, not machine-translated on demand⁶. That's the standard the agency serving this market set for itself.

Most agency sites don't come close. The common pattern is a language toggle in the header that runs the whole page through an automatic translation script, or a single "Hablamos Espanol" page that states the agent speaks Spanish without a single Spanish sentence of actual content behind it. Neither one gives a search engine or an AI assistant a real, separate, indexable Spanish-language page to find. A translation widget renders different text to the browser after the page loads, but the underlying HTML a crawler reads is still the English page at the same URL with the same language tag. There is nothing new to index, and nothing new to cite.

The rarer but still common failure is a real, separate Spanish URL that exists purely as a literal, word for word rendering of the English page, produced by a translation tool and never reviewed by a bilingual person. It clears the bar of "technically a different page," but it often reads stiffly enough that a native Spanish speaker notices immediately, and it carries almost no information that isn't already sitting on the English version at a different address. That distinction, a separate URL versus a genuinely distinct page, turns out to matter more than most agencies assume once you look at how the assistants actually decide what to cite.

How AI assistants actually handle a Spanish-language question

The assumption behind most "add a Spanish version" projects is that the language is a wrapper around the same underlying answer, so getting the translation right is most of the job. The research on how AI systems actually behave says something more specific and more useful: the language of the query changes which sources get pulled into the answer at all, not just which language the final sentence is written in.

Profound, an AI search analytics firm, published a study on April 21, 2026 analyzing 3.25 billion AI citations across ChatGPT, Claude, Google AI Mode, Google AI Overviews, Gemini, Microsoft Copilot, and Perplexity, filtered across 14 countries to native-language prompts only³. Its finding, in the researchers' own words, is that "the language of the query can rewire the entire citation graph: which domains appear, how often they're cited, and even whether the social web shows up at all"³. One concrete example from the study: Spanish-language prompts surface social media content at roughly 1.4 times the English rate inside Google AI Overviews, but at roughly half the English rate inside ChatGPT³. Same question, same underlying topic, two different assistants pulling from meaningfully different pools of sources purely because of the language it was asked in.

Separately, SEO consultant Glenn Gabe published hands-on testing in December 2025 checking how several AI Search platforms handle a query typed in a non-English language with the user's language preference set accordingly⁴. His finding: ChatGPT, Perplexity, and Claude frequently returned the U.S. English version of a page or answer anyway, effectively translating the English source on the fly rather than surfacing the real, native-language page. Microsoft Copilot, which leans on Bing's own language detection, was noticeably more consistent at returning the correct language version. Gemini's behavior was inconsistent across his tests. This is one named practitioner's own testing, not a peer-reviewed study, and we're citing it as exactly that: a documented, dated, first-hand account, not a statistic.

Google's own documentation adds the last piece. Hreflang, the tag most technical SEO advice treats as the whole solution to multilingual sites, is described by Google as a way to "point users to the most appropriate version of your page by language or region," meaning it tells Google which URL to surface for a given searcher, not a ranking signal, and Google's documentation makes no mention of hreflang affecting AI Overviews or AI Mode specifically⁷. Any effect it has on those AI features would be indirect, flowing through which page Google's classic index and ranking system chooses to surface in the first place, which AI Overviews then draws from.

Read the Profound finding again and the practical implication gets sharper. If Google AI Overviews leans more heavily on social content for a Spanish prompt while ChatGPT leans away from it for that same prompt, then optimizing your Spanish content for one assistant's citation habits doesn't automatically carry over to the next one. A page built purely to rank in classic Google search, then pointed at with an hreflang tag and left alone, is optimizing for exactly one of several systems that don't share a playbook. That's not a reason to give up on any of them. It's a reason to check more than one, and to stop treating "we did hreflang" as a finished project.

Why a machine-translated page rarely clears the bar

Set the AI-specific mechanics aside for a moment and look at the more basic problem: a literal, unreviewed machine translation often doesn't even earn a place in the index it needs to be eligible for citation in the first place. Search engines have spent years building quality systems aimed at exactly this pattern, a page that exists mainly as a mechanical variant of another page rather than a genuinely useful piece of content in its own right. A translated page that adds no new examples, no locally relevant detail, and no independent value reads to those systems the same way a spun or duplicated page does, regardless of the language it's written in.

There's a compliance angle here too, and it cuts the other way from what most agencies assume. The risk isn't that Spanish content triggers extra scrutiny. It's that a literal, unreviewed translation of a regulated disclaimer or a plan-mechanics explanation can quietly shift its meaning without anyone noticing, because nobody who reads Spanish fluently ever checked it. The fix isn't avoiding Spanish content. It's having a bilingual human review anything regulated before it publishes, the same review discipline you'd expect for the English version.

Put the two problems together and the practical rule is straightforward: a Spanish page needs to be different enough to be worth indexing on its own terms, and accurate enough that a bilingual reader wouldn't wince at it. A translation tool alone gets you neither.

Spanish isn't one dialect, and your hreflang tag should say so

Most agencies that get as far as building a real Spanish page stop at a single generic tag, lang="es", and call it finished. Hreflang was built to be more specific than that on purpose. The tag pairs a language code with an optional region code, so es-US, es-MX, and the broader Latin American code es-419 are all valid, distinct values Google's documentation supports for exactly this reason, distinguishing Spanish written for a U.S. audience from Spanish written for readers elsewhere in Latin America⁷. A Cuban-American client in Miami, a Mexican-American client in Houston, and a Puerto Rican client in Orlando don't all reach for identical vocabulary when they talk about insurance, and a page that guesses wrong reads as slightly foreign to all three instead of natural to any of them.

You don't need three separate pages to handle this well. Picking es-US as your default region code is the right call for most agencies serving Spanish-speaking clients inside the United States, because it signals general U.S. Spanish rather than one specific country's dialect. What matters is making that choice on purpose and tagging it correctly, rather than leaving the region code off entirely and letting every search engine and assistant guess.

What the gap actually costs

The clearest way to see the cost is the trend line itself. Latino consumers' share of HealthCare.gov plan selections has risen every single year on record: 20.4 percent in 2020, 22.6 percent in 2021, 25.3 percent in 2022, 28.2 percent in 2023, and 29.4 percent in 2024¹. That's not a one-time spike. It's a five-year climb, and nothing in the underlying demographics suggests it reverses.

Layer the geography on top and the cost concentrates further. The four states with the largest Hispanic populations account for a large share of the country's total Hispanic residents, and Texas and Florida are both states with heavy ACA Marketplace enrollment and heavy independent agent activity.

Texas added more Hispanic residents in one year than the total Hispanic population of most individual counties an agency serves². An agency writing ACA or Medicare business anywhere near that growth and publishing nothing a Spanish-speaking prospect's AI assistant can actually find is leaving a fast-growing, already-large share of its addressable market to whichever source, a large publisher, a competitor, or nothing specific at all, the assistant decides to trust instead.

There's a paid-traffic version of the same cost, not just an organic one. An agency running Spanish-language ads and sending that traffic to a page with no real Spanish content behind it, or to an English page a visitor has to work to read, is paying to acquire a click that then has nowhere good to land. The same logic that makes a slow English landing page raise cost per lead applies here: a mismatch between the language a prospect was reached in and the language of the page they arrive on is friction, and friction on a paid click is money spent for a worse chance of a conversion.

How to fix it yourself

None of this requires a rebuild of your entire site to start. It requires treating the Spanish version of your highest-value pages as real pages, not as a setting.

Start with your highest-traffic English answer page. Pick the one page that already answers a question your Spanish-speaking prospects are most likely to ask, a subsidy eligibility explainer, an enrollment period page, a plan comparison, and give that one a genuine Spanish counterpart before touching anything else.

Write it, don't just translate it. Have a bilingual person write or substantially rework the Spanish version so it reads naturally, with its own examples where useful, rather than running the English draft through a translation tool and publishing the output untouched.

Give it its own URL and its own schema. A real subfolder or subdomain, not a query parameter or a client-side toggle, with its own BlogPosting or Article schema, its own FAQPage schema if the page has one, and its own inLanguage value. Link the two versions together with hreflang tags in both directions, English pointing to Spanish and Spanish pointing to English, which is the mechanism Google's documentation actually describes⁷.

List both URLs in your sitemap and your llms.txt. Neither file is useful if it only contains the English side of a bilingual site.

Test the assistants directly, in Spanish, every month. Don't rely on hreflang alone to do the work with ChatGPT, Perplexity, or Claude. Open each one, ask your top five Spanish-language questions the way a real prospect would phrase them, and note whether it names your agency, translates a competitor's English page, or names nothing specific. That's the only way to know whether the fix is actually working, because the documentation and the testing cited in this guide both say the assistants don't behave consistently with each other.

What a citable bilingual page looks like

Take a subsidy eligibility page as the example, because it's one of the most-asked questions in both languages. A non-citable Spanish version reads like a translated brochure: "Puede calificar para asistencia financiera para su seguro de salud," with no number, no threshold, and a contact form as the only next step. There's no fact in that sentence for an assistant to lift, in either language.

A citable version states the mechanic directly, in Spanish, with its own worked number rather than a copy of the English example: it names the income thresholds tied to the federal poverty level that determine subsidy eligibility, states them in the reader's own currency and terms, and gives one concrete example household. It carries its own dateline, its own named source citation the way the English page does, and its own FAQPage schema answering the Spanish-language phrasing of the same question, not a copy of the English FAQ schema with translated question text pasted over the same answers. That last detail matters more than it sounds like it should: several of the AI platforms reviewed in this guide are, per the evidence cited above, inconsistent about following a language pointer, but none of them can cite a page that was never built as a real, independently structured document in the first place.

Who this fits, and who it doesn't

This is worth building for any agency writing ACA, Medicare, or life business in a market with a meaningful Hispanic population, and especially in Texas, Florida, or any state posting the kind of year over year growth described above. It's a real commitment, not a checkbox: a genuinely separate Spanish page, reviewed by a bilingual person, is more work than flipping a translation widget on.

It fits less well for an agency with no bilingual staff, no plan to serve Spanish-speaking clients directly, and no realistic path to answering the phone in Spanish once a Spanish-language page generates a call. Building the page without the service behind it creates the same problem as any other citable content that dead-ends at a contact form nobody can actually help. If that's your situation today, the honest first step is deciding whether to build that capacity, not whether to build the page.

How we build this

Every site we build treats a second language as a first-class version of the site, not an add-on: its own URL structure, its own schema stack, correct bidirectional hreflang, and its own entries in the sitemap and llms.txt the moment it publishes. Digital Foundation runs $247 a month for a complete, AEO-optimized site with Google Business Profile management and an AI chat widget, $497 a month for that plus a new blog post and location page every week and a 24/7 AI receptionist, and $997 a month for a blog post nearly every business day, and all three tiers include a 14-day free trial and month-to-month billing⁸. For an agency that wants original Spanish-language content written and published on a real cadence rather than translated after the fact, that's exactly the blog cadence service handles, in both languages, on the same schedule.

For a larger book with its own bilingual quoting needs, a custom build scoped on a call can wire a real subsidy or premium calculator to serve both languages directly from the same live federal data, rather than maintaining two separate, drifting versions of the same tool⁹.

Questions agents ask about Spanish-language AEO