Bilingual SEO: How to Rank in Both English and Spanish Without Hurting Either

The most common "bilingual" website in the Dominican Republic is not actually bilingual. It is a Spanish website with a Google Translate button in the corner.

The distinction matters enormously — not just for the quality of the user experience, but for how Google indexes and ranks the site. A website with machine-translated content and no proper international SEO architecture does not rank in two languages. It competes against itself, confuses search engines about who the content is for, and in the worst cases generates duplicate content signals that suppress both language versions simultaneously.

True bilingual SEO — the kind that ranks independently in English for international tourists and in Spanish for Dominican and Latin American visitors — requires getting three technical layers right at the same time: URL structure, hreflang implementation, and genuinely localized content. According to research, 75% of international sites have hreflang errors that fragment their rankings. And most multilingual SEO implementations only get one of the three layers right.

For Dominican tourism businesses competing for both markets simultaneously, this matters in direct revenue terms. A dive center in Punta Cana that ranks for "buceo Punta Cana" in Spanish but is invisible to English searchers looking for "scuba diving Punta Cana" is capturing the domestic and Latin American market while leaving the international tourist market — the highest-spending segment of Punta Cana's visitors — entirely to competitors with better bilingual implementations.

This article explains exactly what each layer requires, what the most common mistakes are, and how the DR Web Studio portfolio addresses this from the ground up.

Layer 1: URL Structure — How You Separate the Two Languages

The first architectural decision for a bilingual website is how to structure the URLs for each language version. There are three main options, each with distinct SEO implications.

Country code top-level domains (ccTLDs): Separate domains for each language — example.com for English, example.es for Spanish. This provides the strongest geographic targeting signal to Google and feels the most locally native for each market. The significant disadvantage: each domain builds link authority separately. Every backlink to example.com does nothing for example.es, and vice versa. For a Dominican business starting from zero domain authority, building two separate authority profiles simultaneously is extremely difficult.

Subdomains: en.example.com and es.example.com. Google treats subdomains as separate sites for ranking purposes — they do not share link authority. This approach has the disadvantages of ccTLDs without the geographic targeting advantage. It is the weakest option for most businesses and is generally not recommended.

Subdirectories: example.com/en/ and example.com/es/. This is the recommended structure for most Dominican tourism businesses building bilingual SEO from scratch. All language versions share the domain's link authority — every backlink earned by any page benefits the entire site. The URL structure is clean, clearly communicates language to both users and search engines, and integrates naturally with modern frameworks.

The DR Web Studio portfolio uses subdirectory structure across all bilingual builds, with one important variation: the localePrefix: "as-needed" configuration in next-intl places the default language (English) at the root path / rather than /en/, while Spanish lives at /es/. This means:

• English: puntacanatoursite.com/scuba-diving/
• Spanish: puntacanatoursite.com/es/buceo/

This approach is optimal for international tourism businesses whose primary organic market is English-speaking — the default experience requires no URL prefix, matching how most English-speaking tourists will naturally encounter the site. Every other language gets a clean, prefixed path.

The critical rule: once you have chosen a URL structure, it is permanent. Changing your URL structure after building significant ranking authority requires a complete redirect migration — a technically complex process that temporarily suppresses rankings and requires months to fully recover. Choose the right structure before building content, not after.

Layer 2: Hreflang — Telling Google Which Page Is for Whom

Hreflang tags are the technical mechanism by which you tell search engines which language version of a page to serve to which audience. Without them, Google must guess — and its guesses are often wrong, serving Spanish content to English searchers or displaying the wrong page version in the wrong country's search results.

The anatomy of a hreflang implementation requires three elements for every page pair:

Self-referencing tag: Each language version must include a tag pointing to itself. The English page includes a tag declaring its own URL as the English version; the Spanish page includes a tag declaring its own URL as the Spanish version.

Reciprocal tags: Each language version must reference every other language version. The English page must include a tag pointing to the Spanish version; the Spanish page must include a tag pointing to the English version. Google requires this mutual acknowledgment to verify the relationship is legitimate. A one-way hreflang declaration is treated as invalid.

x-default tag: This optional but recommended tag specifies which URL to serve to users who do not match any of the specified languages. For most Dominican tourism sites, this points to the English (default) version.

A correct hreflang implementation for a bilingual Punta Cana tour operator page looks like this in the HTML <head>:

<link rel="alternate" hreflang="en" href="https://example.com/scuba-diving/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/buceo/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/scuba-diving/" />

And on the Spanish page:

<link rel="alternate" hreflang="en" href="https://example.com/scuba-diving/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/buceo/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/scuba-diving/" />

Note that both pages carry identical hreflang annotations — the full set of all language versions, including self-references. This is what "reciprocal" means in practice.

The Three Most Common Hreflang Mistakes for Dominican Websites

Mistake 1 — Wrong canonical tags: This is the most damaging technical error in bilingual SEO, and it is extremely common. Each language version of a page must canonicalize to itself — the Spanish page's canonical URL must point to the Spanish page, and the English page's canonical URL must point to the English page.

When a Spanish page has its canonical set to the English URL (a common mistake on WordPress sites where canonical settings are applied globally), Google receives two contradictory signals: the hreflang says "this Spanish page serves Spanish users," but the canonical says "treat this as a duplicate of the English page." Google must choose which signal to trust — and often ignores both, removing the Spanish page from Spanish search results entirely.

Mistake 2 — Missing self-referencing tags: Hreflang requires each page to include a tag pointing to itself. This sounds redundant but is technically required by Google's implementation specification. The absence of self-referencing tags is one of the most common validation errors found in hreflang audits.

Mistake 3 — JavaScript-rendered hreflang in client-side applications: For websites built with client-side rendering frameworks (standard React, some Vue configurations), hreflang tags rendered by JavaScript may not be present when Googlebot processes the page — because Googlebot often processes the HTML before JavaScript executes. The solution is server-side rendering (which Next.js provides by default) or sitemap-based hreflang delivery.

Sitemap-Based Hreflang: The Most Reliable Delivery Method for Next.js

For websites built with modern frameworks like Next.js, the most reliable way to deliver hreflang to Google is through the XML sitemap rather than (or in addition to) HTML head tags. The sitemap is a static file that Google reads independently of JavaScript execution, making it immune to the rendering timing issues that affect client-side hreflang.

The Next.js sitemap.ts file generates a dynamic sitemap that includes hreflang entries for every language pair automatically. When a new page is added to the site — a new blog post, a new tour description, a new case study — the sitemap immediately includes the correct hreflang annotations for both the English and Spanish versions. No manual updates required.

This is how every bilingual DR Web Studio build handles hreflang — sitemap delivery for reliability, supplemented by HTML head tags for redundancy.

Layer 3: Genuinely Localized Content — Why Translation Is Not Enough

The technical implementation of URL structure and hreflang can be perfect and still fail to produce bilingual rankings if the content itself is not genuinely localized.

There are two dimensions to this problem.

Machine Translation and AI Translation Do Not Rank as Well as Native Content

Google's quality signals for ranking — E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness), user engagement, and content depth — all apply independently to each language version of a page. Machine-translated content, even high-quality AI translation, typically produces text that native speakers recognize as unnatural, which produces behavioral signals (lower time-on-page, higher bounce rates, lower engagement) that negatively affect the Spanish page's ranking even when the English version ranks well.

More critically: as of 2026, Google AI Overviews source answers from language-matched content pools — the actual text of the page — not from hreflang declarations. A Spanish-language AI Overview about scuba diving in Punta Cana will cite pages with naturally written Spanish content over pages with machine-translated Spanish, regardless of hreflang annotations. Native-language content creation is no longer optional for businesses that want AI Overview visibility.

For Dominican tourism businesses, this means the Spanish content should read as naturally and professionally as the English content — not as a translation of it. The Sertuin Events case study on the DR Web Studio blog, for example, exists in genuinely written Spanish, not translated English. Each language version speaks directly to its audience in that audience's natural register.

Keyword Localization: Spanish Searches Are Not Translated English Searches

The second dimension of content localization is keyword research. Dominican and Latin American tourists do not search for the same phrases as North American and European tourists — even when they are searching for the same service.

An English-speaking tourist planning a Punta Cana trip might search "scuba diving Punta Cana," "PADI certification Punta Cana," or "underwater photography Dominican Republic." A Spanish-speaking Dominican resident looking for the same service might search "buceo Punta Cana," "cursos de buceo principiantes Bávaro," or "inmersiones de buceo precio Punta Cana."

These are different keywords. They require different page content, different on-page optimization, and different internal linking — not just translated versions of the English keywords. A bilingual site that translates its English keyword targets directly into Spanish is leaving significant Spanish-language search traffic uncaptured.

The correct approach for a bilingual Dominican tourism website: conduct keyword research independently for each language market, identify the natural search terms that Spanish-speaking and English-speaking tourists actually use, and optimize each language version's content for its own keyword set. The resulting pages will cover different angles of the same topic — which is not only better for SEO but also better for the reader, since it means each page speaks naturally to its specific audience.

Meta Tags, Structured Data, and Alt Text Must Be Localized

A partial bilingual implementation that many Dominican websites have: translated body content but English meta titles, meta descriptions, and structured data on the Spanish pages. This is a meaningful oversight.

Google uses meta titles and descriptions in ranking assessment and in what it displays in search results for each language version. A Spanish page with an English meta title signals to Google that the page may not be fully localized — reducing its relevance score for Spanish queries. A Spanish visitor seeing an English meta description in Google's search results is less likely to click.

Every element of each page's on-page SEO — title tag, meta description, Open Graph tags, JSON-LD structured data, image alt text, URL slug — should be in the language of that page. The URL /es/buceo/ is better than /es/scuba-diving/ for the Spanish version. The meta description for the Spanish page should be written in natural Spanish, not translated.

This is part of what makes building a genuinely bilingual site from a headless CMS like Sanity so effective: the bilingual field structure stores { en: "...", es: "..." } for every content field, including meta tags and structured data values, ensuring the complete SEO layer is localized for each language — not just the body text.

How Google Handles Bilingual Content When Everything Is Done Right

When URL structure, hreflang, and genuinely localized content are all correctly implemented, Google's behavior becomes predictable and beneficial.

A searcher in Canada typing "wedding photographer Punta Cana" in English sees the English version of your photography page. A searcher in Colombia typing "fotógrafo de bodas Punta Cana" in Spanish sees the Spanish version. Each version has accumulated its own ranking authority for its own language's keyword set. Each version's on-page signals (title, meta, body, alt text, structured data) align with the language of the searcher. Neither version is cannibalizing the other.

The combined organic traffic is substantially higher than either single-language version would generate alone — because the site is effectively running two parallel SEO campaigns, each targeting different markets, from a single domain that accumulates shared authority.

This is the structural advantage that the DR Web Studio portfolio builds in for every client serving international tourists: the Punta Cana Proposal Packages platform ranks in nine languages independently because each language version has its own indexed URLs, its own on-page optimization, and content written to resonate with that language's speakers. The Punta Cana Photo Edition site captures both English and Spanish organic traffic because both versions are genuinely optimized, not one translated into the other.

How to Audit Your Current Bilingual Implementation

If your website already has Spanish and English versions, here are the steps to check whether your bilingual SEO is working correctly.

Step 1 — Check your URL structure: Do your Spanish pages have separate URLs from your English pages? (/es/ or similar prefix) If all your content shares the same URLs and switches language via JavaScript, your Spanish content is probably not independently indexed.

Step 2 — Check hreflang: Use Google Search Console's International Targeting report (Settings → International Targeting) to see if hreflang errors are detected. Alternatively, use Ahrefs, Screaming Frog, or a free hreflang validator tool to audit whether your tags are correctly implemented with self-references and reciprocal annotations.

Step 3 — Check canonical tags: On your Spanish pages, right-click and view the page source (Ctrl+U). Search for canonical. The canonical URL should match the Spanish page's URL — not redirect to the English version.

Step 4 — Check what Google has indexed: In Google, search site:yourdomain.com/es/ to see how many Spanish pages are indexed. Compare this to your total Spanish page count. A large gap means either hreflang errors or canonical tag problems are preventing indexing.

Step 5 — Check Search Console language data: In Google Search Console, filter Performance data by country to see whether you are receiving organic traffic from Spanish-speaking countries (Dominican Republic, Colombia, Mexico, Spain, Argentina) as well as English-speaking countries (USA, Canada, UK). If Spanish-country traffic is near zero, your bilingual implementation is not producing organic Spanish rankings.

The Financial Argument for Getting This Right

For Dominican tourism businesses, the bilingual SEO opportunity is a market size argument.

Punta Cana Airport receives visitors from the United States, Canada, and Europe (English-speaking international tourists) and from the Dominican Republic, Colombia, Argentina, Mexico, and other Latin American countries (Spanish-speaking regional tourists). Both markets are substantial. Both search in their native language. Both are accessible through organic search — but only if the website correctly serves each language version to each market.

A website that only ranks in English captures the international tourist market while leaving regional Latin American visitors to competitors with Spanish-optimized sites. A website that only ranks in Spanish captures the regional market while leaving international tourists to competitors with English-optimized sites. A correctly built bilingual site captures both — at no additional ongoing cost, from the same domain, through the same content investment.

At DR Web Studio, bilingual architecture is not an add-on. It is the default. Every site we build includes separate indexed URLs for each language, correct hreflang configuration in both the sitemap and HTML head, fully localized meta tags and structured data, and content built to resonate with each language's audience natively — not translated from one to the other.

If you want to know whether your current bilingual implementation is working correctly — or if it is actually suppressing both language versions through hreflang errors — request a free consultation. We will audit your current setup, show you exactly what Google has indexed in each language, and tell you what is preventing your Spanish pages from ranking for the Spanish searches your potential clients are making.

Both markets are searching. Both markets are ready to book. The question is whether your website speaks to both — technically as well as linguistically.