I have audited over 50 tourism websites with multiple language versions. The pattern is consistent: 80% of them have broken hreflang implementations. The remaining 20% usually have it technically correct but strategically wrong. Both scenarios cost money.
Hreflang looks simple on paper. Add a few tags, tell Google which page serves which language or region, and you are done. In practice, tourism sites face unique challenges that make implementation surprisingly complex. You have seasonal content in some languages but not others. You have destination pages that exist in Spanish but not German. You have booking engines that ignore everything you configured.
This guide covers the practical side of hreflang for travel and hospitality sites, based on implementations I have done for DMOs, hotel groups, and tour operators across Europe, Latin America, and Southeast Asia.
What Hreflang Actually Does (And What It Does Not)
Hreflang is a signal, not a directive. Google uses it to understand the relationship between different language or regional versions of the same content. When someone in France searches for your Maldives resort, Google should serve your French page instead of your English one.
Here is what hreflang does not do
It does not prevent duplicate content penalties, it does not guarantee rankings in specific countries, and it does not automatically redirect users. These are common misconceptions I encounter constantly when working with tourism clients.
The duplicate content fear is particularly widespread. Tourism sites often have English pages for the UK, US, Australia, and a default international version. Content managers worry Google will penalize them for having similar content. Hreflang does not solve this because there was never a penalty to solve. Google handles similar content across language versions without issues. Hreflang just helps Google serve the right version to the right user.
When Tourism Sites Actually Need Hreflang
Not every multilingual tourism site needs hreflang. I worked with a boutique hotel that had their site in Spanish, English, and French. Same content structure, same URLs except for the language subfolder. They asked me to implement hreflang as part of an SEO package.
After reviewing their analytics, I told them it was unnecessary. Their traffic came 95% from brand searches and direct referrals. The minimal organic traffic they received was not being served wrong language versions. Implementing hreflang would have been technical busywork with zero business impact.
You need hreflang when:
- You receive significant organic search traffic from multiple countries or language groups
- Google Search Console shows your German pages ranking for French queries or similar mismatches
- You have regional pricing, availability, or legal requirements that differ between versions
- Your analytics show users bouncing because they land on wrong language pages
If none of these apply, focus your technical SEO efforts elsewhere first.
The Three Implementation Methods for Tourism Sites
You can implement hreflang through HTML link elements in the head, HTTP headers, or XML sitemaps. Tourism sites almost always end up using a combination, and that combination often causes problems.
HTML Link Elements
This is the most common method. You add link elements in the head section of each page, pointing to all language versions including the page itself.
For a destination page about Costa Rica diving, your English page would include:
<link rel="alternate" hreflang="en" href="https://example.com/en/costa-rica-diving/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/buceo-costa-rica/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/tauchen-costa-rica/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/costa-rica-diving/" />
The x-default tag tells Google which page to show when no other hreflang matches the user. Tourism sites often forget this, and it creates problems for traffic from countries you do not specifically target.
When I built CostaRicaDivers.com, I kept it simple with English and Spanish. The English version served as x-default because most international diving tourists spoke English even if it was not their first language. This decision came from understanding the actual customer base, not from following generic SEO advice.
XML Sitemap Method
For tourism sites with thousands of destination pages, hotel listings, or tour products, managing hreflang in HTML becomes unwieldy. The sitemap method scales better.
Instead of adding link elements to every page, you create a sitemap that groups all language versions together:
<url>
<loc>https://example.com/en/maldives-resorts/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/maldives-resorts/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/malediven-resorts/" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/maldives-hotels/" />
</url>
I recommend this method for DMO websites and large hotel booking platforms. One client had 12 language versions and 8,000 destination pages. HTML implementation would have added 96,000 link elements across the site. The sitemap approach kept things manageable and easier to audit.
HTTP Headers
This method works for non-HTML content like PDFs. Tourism sites use it for downloadable brochures, travel guides, and visa requirement documents. If you have a PDF cruise itinerary in multiple languages, HTTP headers are your only option.
Most tourism sites do not need this method for their main pages. I mention it because clients sometimes ask about it after reading outdated SEO guides.
Common Hreflang Errors on Tourism Websites
After years of auditing travel sites, I have seen the same mistakes repeated across different CMS platforms, development teams, and website sizes. These errors consistently appear regardless of budget or technical sophistication.
Missing Return Links
This is the most common error. Hreflang must be reciprocal. If your English page points to your Spanish page, your Spanish page must point back to your English page. Both pages must also include self-referential hreflang tags.
Tourism sites break this rule when:
- Content exists in one language but not another (seasonal promotions, regional offers)
- Development teams launch language versions at different times
- URL structures differ between languages and someone forgets to update all versions
- CMS plugins malfunction after updates
When I audit sites, I use Screaming Frog’s hreflang report to identify missing return links. A site with proper implementation shows zero errors in this report. Most tourism sites I audit show error rates between 15% and 40%.
Wrong Language or Region Codes
Hreflang uses ISO 639-1 language codes and optionally ISO 3166-1 Alpha 2 region codes. Tourism sites frequently get these wrong.
Common mistakes I encounter:
- Using “uk” for English (should be “en-GB” for British English, “uk” is not a valid language code)
- Using “br” for Brazilian Portuguese (should be “pt-BR”)
- Using full country names like “english” or “spanish”
- Using three-letter codes when two-letter codes are required
A DMO client once had “en-EU” as their European English hreflang. EU is not a valid region code. Google ignored the entire implementation because of this single error.
Pointing to Non-Indexable Pages
Hreflang tags must point to pages that Google can index. If your French page has a noindex tag, canonical pointing elsewhere, or returns a 404, the hreflang relationship breaks.
Tourism sites create this problem through:
- Seasonal pages that get noindexed during off-season
- Booking pages with noindex tags that still receive hreflang
- Soft 404s from CMS misconfigurations
- Pages canonicalized to different language versions during site migrations
Mixed Implementation Methods
Using both HTML and sitemap implementation simultaneously is technically allowed but creates maintenance nightmares. When they conflict, Google picks one arbitrarily.
I worked with a hotel chain that had their CMS generating HTML hreflang tags while their SEO agency maintained separate sitemap-based hreflang. The two systems drifted apart over 18 months. By the time I audited the site, they had three different versions of hreflang truth: what the CMS generated, what the sitemap declared, and what Google actually understood.
Pick one method and stick with it. For most tourism sites, I recommend sitemap-based implementation managed through a CMS plugin or custom build, with regular automated auditing.
Testing Tools That Actually Work
Google’s own hreflang testing tool disappeared years ago. Third-party tools fill the gap, though quality varies significantly.
Screaming Frog
This is my primary tool for hreflang audits. The desktop crawler checks all hreflang relationships and flags missing return links, invalid codes, and indexability conflicts. For tourism sites under 50,000 pages, Screaming Frog handles everything.
Configuration matters. Set the crawler to respect robots.txt but also enable rendering to catch JavaScript-generated hreflang tags. Some booking platforms inject hreflang through client-side scripts that Screaming Frog misses in default mode.
Ahrefs Site Audit
For ongoing monitoring rather than one-time audits, Ahrefs catches hreflang issues during regular crawls. I set up alerts for hreflang errors so clients know immediately when something breaks.
The limitation: Ahrefs crawls less frequently than issues appear. A promotional landing page with broken hreflang might run for two weeks before the next scheduled crawl catches it.
Hreflang Tags Testing Tool by Merkle
This free online tool checks individual pages quickly. I use it for spot-checking after deployments. Enter a URL, and it shows all hreflang declarations and validates return links.
It does not crawl your entire site, so use it alongside a comprehensive crawler rather than as your only tool.
Google Search Console
GSC does not report hreflang errors directly anymore. However, the International Targeting report shows which countries and languages Google associates with your site. If you implemented hreflang for German speakers but GSC shows no German language association, something is wrong.
The Coverage report also helps. Pages excluded as duplicates with user-selected canonical might indicate hreflang being ignored because Google chose a different canonical than you specified.
Google Search Console Monitoring for Multilingual Sites
Monitoring hreflang effectiveness requires checking multiple GSC properties. If you have language subfolders or subdomains, set up separate properties for each alongside your domain-level property.
Performance Filtering by Country
In GSC Performance reports, filter by country to check if the right language version ranks. If your Spanish pages rank heavily in Germany while your German pages receive minimal impressions there, hreflang is not working as intended.
This analysis requires manual work. Export performance data for each language version, compare country distributions, and identify mismatches. I typically do this quarterly for tourism clients because seasonal patterns affect results.
Index Coverage Discrepancies
Compare indexed page counts between language versions. If your English site has 500 pages indexed but your French equivalent shows 200, investigate why 300 French pages are not indexed. Common causes include:
- Crawl budget issues from inefficient internal linking
- Hreflang pointing to noindexed or canonicalized pages
- Google consolidating similar pages across languages
For a client in Southeast Asia, index coverage analysis revealed their Thai language pages were systematically deprioritized by Google. The issue traced back to thin content on Thai pages compared to English equivalents. Google was not ignoring hreflang; it was choosing not to index low-quality pages regardless of hreflang signals.
URL Inspection for Specific Pages
When troubleshooting specific hreflang issues, use URL Inspection to see how Google actually interprets each page. Check the canonical URL Google selected and whether it matches your hreflang configuration.
If Google selects a different canonical than you specified, hreflang relationships based on your intended canonical will fail. Fix the canonical issue first before debugging hreflang further.
CMS-Specific Considerations for Tourism Sites
Different CMS platforms handle hreflang differently. Tourism sites commonly use WordPress with translation plugins, or enterprise platforms like Sitecore or Adobe Experience Manager.
WordPress with WPML or Polylang
Both plugins generate hreflang automatically based on your translation connections. The common failure point: manually duplicating pages instead of using the plugin’s translation feature. Duplicated pages look identical to the CMS but have no hreflang relationship because the plugin does not know they are connected.
I audit WordPress multilingual sites by checking whether each page was created through the proper translation workflow. Pages created outside the workflow lack hreflang even though they appear in the correct language subfolder.
Headless CMS and JAMstack Sites
Modern tourism sites increasingly use headless architectures with Next.js, Gatsby, or similar frameworks. These require manual hreflang implementation because there is no plugin to handle it automatically.
The benefit: complete control over implementation.
The risk: developers unfamiliar with SEO requirements make mistakes that persist until an audit catches them.
For headless implementations, I document hreflang requirements as part of technical specifications before development begins. Retrofitting hreflang into a launched headless site costs significantly more than building it correctly from the start.
Booking Engine Integrations
Hotel and tour operator sites often embed third-party booking engines. These iframes or widgets typically ignore your site’s hreflang configuration. The booking engine serves whatever language it detects, regardless of what your wrapper page declares.
Solutions vary by booking provider. Some allow language parameters in embed URLs. Others require API-level integration to respect the parent page language. Document these requirements when selecting booking technology because retrofitting language handling is expensive.
Regional Targeting vs. Language Targeting
Tourism sites must decide whether to target languages, regions, or both. The choice affects hreflang implementation and overall content strategy.
Language-Only Targeting
Use simple language codes (en, es, de) when your content does not vary by region. A diving site targeting all Spanish speakers worldwide needs only one Spanish version.
This approach works when:
- Pricing displays in a neutral currency or localizes client-side
- Content applies universally across regions
- You lack resources to maintain regional variations
Language-Region Targeting
Use combined codes (en-US, en-GB, es-MX, es-ES) when regional differences matter. A hotel booking site might need different versions for US and UK travelers because of date formats, spelling, and cultural references.
Tourism sites commonly need regional targeting when:
- Pricing varies by market
- Legal requirements differ (GDPR notices for EU, specific disclosures for US)
- Seasonal content differs (Northern vs. Southern Hemisphere)
- Booking availability varies by departure country
Avoiding Over-Segmentation
I have seen tourism sites create separate versions for en-US, en-GB, en-AU, en-CA, en-NZ, en-IE, and more. Unless you have genuinely different content for each market, this creates maintenance burden without SEO benefit.
Start with major markets where you have actual business presence or traffic. Add regional variants only when data supports the investment.
FAQ on Hreflang Implementation
Does hreflang affect rankings directly?
No. Hreflang is a signal for serving the right version to the right user, not a ranking factor. Your German page will not rank higher in Germany just because you added hreflang. It will be shown instead of your English page when Google determines the German version better matches the user’s language preference. Rankings depend on your content quality, backlinks, and technical health, not hreflang presence.
Should I use subdomains or subfolders for language versions?
I recommend subfolders for most tourism sites. They consolidate domain authority, simplify SSL management, and reduce infrastructure complexity. Subdomains make sense only when language versions operate as genuinely separate businesses with different teams and link building efforts. The subfolder structure (example.com/en/, example.com/es/) works well with hreflang and requires less ongoing maintenance than subdomains or ccTLDs.
What happens if my hreflang is wrong?
Google ignores invalid hreflang rather than penalizing you. Your pages still get indexed and can still rank. The consequence is suboptimal user experience: French users landing on English pages and bouncing, or Google arbitrarily choosing which version to show. Invalid hreflang wastes the technical effort you invested without providing the intended benefit. Fix errors when you find them, but do not panic about historical mistakes causing lasting damage.
How long does it take for Google to recognize hreflang changes?
Expect 2-4 weeks minimum for Google to recrawl all affected pages and update its understanding. Large sites with thousands of pages may take longer. After implementing or fixing hreflang, submit updated sitemaps through GSC and use URL Inspection to request indexing of priority pages. Monitor country-level performance reports starting about a month after changes to assess impact.
Can I use hreflang for pages that are not direct translations?
Technically yes, but carefully. Hreflang indicates equivalent content for different language audiences, not identical content. Your German page about Alpine skiing can hreflang to your English skiing page even if emphasis differs. However, linking completely different topics (German page about skiing to English page about beaches) confuses Google and wastes the relationship. The pages should serve the same user intent in different languages.
Do I need hreflang if I use automatic translation?
Automatic translation does not exempt you from hreflang implementation. You still need to tell Google the relationship between versions. However, I caution against relying on automatic translation for tourism content. Machine translation of destination descriptions, cultural information, and booking details creates poor user experiences. If you cannot invest in proper translation, consider maintaining fewer language versions at higher quality rather than many versions of questionable accuracy.
Get Your Hreflang Implementation Audited
Hreflang mistakes on tourism sites directly affect revenue. When German travelers land on your English booking page, conversion rates drop. When Google shows your UK pricing to Australian users, trust erodes.
I conduct comprehensive multilingual SEO audits for DMOs, hotel groups, and tour operators. This includes hreflang validation, indexability analysis across all language versions, and specific recommendations prioritized by business impact. Reach out to me so we can talk about your digital presence.
About the Author
I’m Peter Sawicki, a Destination SEO Strategist helping tourism brands and DMOs grow their online presence through SEO, technical audits, and creative digital strategies. Over the years I’ve worked across multiple countries and markets, which gives me a global perspective on every project I take on. When I’m not optimizing websites, you’ll most likely find me underwater. Scuba diving is where my two biggest passions meet.
