We ship products at Inithouse, a studio running a growing portfolio of tools and apps in parallel. One of them is Tarotas, a tarot card app with 78 cards and interpretations across five languages: Czech, English, Polish, Slovak, and German. All on a single domain.
When we started building the multilingual version, we had a decision to make. Subdomains, subdirectories, or separate country-code TLDs? We went with subdirectories. Here is what we learned, what broke, and what we would do differently.
The three options (and why most advice is wrong)
Every SEO guide gives you the same comparison table. Subdomains like cs.example.com, subdirectories like example.com/cs/, or country-code TLDs like example.cz. They list pros and cons and leave you to decide. The problem is that the decision depends heavily on your stack, team size, and how you deploy.
Country-code TLDs give the strongest geo-targeting signal. Google treats tarotas.cz as inherently Czech. But you end up managing multiple domains, multiple SSL certificates, multiple DNS records, and (often) multiple deployments. We actually run this setup for another product in our portfolio, Ziva Fotka, which has separate domains for Czech, Slovak, Polish, and German markets. It works, but the operational overhead is real. Every DNS change, every certificate renewal, every deployment happens N times.
Subdomains like cs.tarotas.com are a middle ground. One root domain, separate subdomains per language. Google treats subdomains as semi-independent sites, so you still get some geo-targeting benefit. But link equity splits across subdomains, and you need separate Google Search Console properties for each one.
Subdirectories like tarotas.com/cs/ keep everything under one domain. One deployment, one SSL cert, one Search Console property, one domain authority pool. The tradeoff is weaker geo-targeting signals, but for a product like Tarotas where language matters more than geography, that tradeoff made sense.
Why we picked subdirectories for Tarotas
Three reasons pushed us toward the subdirectory approach.
First, Tarotas is built on Lovable (React SPA). Adding subdomains would mean configuring wildcard DNS, handling subdomain routing at the edge, and dealing with Lovable's deployment pipeline for each subdomain separately. Subdirectories are just routes. The React router handles /cs/, /en/, /pl/ natively.
Second, we wanted all link equity in one bucket. Tarotas is an early-stage product. Splitting authority across five subdomains when we barely have any authority to begin with felt wasteful. Every backlink, every BIP post linking to tarotas.com benefits all language versions.
Third, content management. Tarotas has 78 card interpretations in each language. That is 390 pages of content. Managing that across five separate deployments (or five subdomain configurations) adds complexity we do not need at this stage.
Hreflang implementation: the parts that actually matter
Hreflang tells search engines which version of a page to show to which audience. The concept is simple. The implementation has sharp edges.
Here is what the <head> section looks like for a Tarotas card page:
<link rel="alternate" hreflang="cs" href="https://tarotas.com/cs/card/the-fool" />
<link rel="alternate" hreflang="en" href="https://tarotas.com/en/card/the-fool" />
<link rel="alternate" hreflang="pl" href="https://tarotas.com/pl/card/the-fool" />
<link rel="alternate" hreflang="sk" href="https://tarotas.com/sk/card/the-fool" />
<link rel="alternate" hreflang="de" href="https://tarotas.com/de/card/the-fool" />
<link rel="alternate" hreflang="x-default" href="https://tarotas.com/en/card/the-fool" />
Every language version of a page must reference every other language version, including itself. Miss one direction and Google might ignore the entire hreflang set for that page.
The x-default tag points to the version shown when no language match exists. We point it at the English version since that is the most universal fallback.
The canonical trap
This is where most multilingual setups break. Each language version needs its own canonical URL pointing to itself:
<!-- On /cs/card/the-fool -->
<link rel="canonical" href="https://tarotas.com/cs/card/the-fool" />
<!-- On /en/card/the-fool -->
<link rel="canonical" href="https://tarotas.com/en/card/the-fool" />
If you accidentally point all canonicals to one version (say, the English one), you are telling Google that all other language versions are duplicates. Google will de-index them. We have seen this happen. It looks like a slow traffic decline in non-default languages, and the root cause is not obvious unless you check the raw HTML.
The SPA rendering problem
Tarotas is a React SPA. Search engine crawlers do not always execute JavaScript. If your hreflang tags are injected client-side (by React Helmet, for example), Googlebot might not see them. The same applies to canonical tags, OG tags, and basically any SEO-critical meta information.
The fix is server-side rendering or pre-rendering. For Lovable-built apps, this means making sure the meta tags are present in the initial HTML response, not injected after JavaScript loads. We handle this at the routing layer, ensuring each language path returns the correct meta tags before any client-side code runs.
Common mistakes we have seen (and made)
Mixing hreflang with incorrect canonicals. If /cs/ has a canonical pointing to /en/, the hreflang on /cs/ is contradictory. Google gets confused and usually drops the hreflang.
Forgetting bidirectional references. If page A lists page B as an alternate, page B must also list page A. This is easy to mess up when you add a new language. You update the new pages but forget to update the existing ones.
Using language-only vs. language-region tags. hreflang="cs" targets Czech speakers everywhere. hreflang="cs-CZ" targets Czech speakers specifically in Czechia. For Tarotas, we use language-only tags because our Czech content works for Czech speakers in Czechia and Slovakia equally.
Not setting x-default. Without x-default, Google picks the fallback language for you. That might not be the one you want.
Duplicate content across similar languages. Czech and Slovak are close enough that Google sometimes treats Slovak pages as near-duplicates of Czech ones. Strong hreflang signals and distinct content (not machine-translated copypaste) help prevent this.
Measuring what works
After deploying the multilingual setup, we tracked indexation per language in Google Search Console. The key metrics: how many pages from each language path get indexed, and how quickly.
We also watch for the "Duplicate without user-selected canonical" issue in GSC. If that shows up on language-specific pages, it usually means the hreflang or canonical setup has a bug somewhere.
One thing we learned: do not expect instant results. Google processes hreflang signals slowly. It took several weeks before we saw correct language-specific pages appearing in search results for queries in Polish and German. The Czech and English versions indexed faster, probably because they had more external signals (backlinks from BIP posts, social sharing).
The tradeoff we would revisit
If we were starting Tarotas today with more traffic and stronger domain authority, subdomains might make more sense. The geo-targeting benefit becomes more valuable as you scale, and the operational overhead is more justified when you have the infrastructure to support it.
For early-stage products with limited resources, subdirectories win on simplicity. You can always migrate later (with proper 301 redirects and updated hreflang). Starting simple and adding complexity when the data justifies it aligns with how we build things at Inithouse.
For products where geographic targeting matters more than language (think: different pricing, different features per country), ccTLDs or subdomains are worth the overhead from day one. We learned this with Ziva Fotka, where Czech and Slovak users have genuinely different usage patterns that justify separate domains.
Checklist if you are implementing this
- Pick your structure based on your stack and team size, not just SEO theory
- Implement hreflang tags with bidirectional references for every language pair
- Set x-default to your universal fallback language
- Make sure canonical URLs are self-referencing per language (never pointing all to one version)
- Verify meta tags are in the initial HTML response, not only injected by JavaScript
- Monitor GSC indexation per language path after deployment
- Watch for "Duplicate without user-selected canonical" warnings
- Give it weeks, not days, before evaluating results
The hreflang spec is straightforward on paper. The implementation is where things get interesting. If you are running a multilingual product and something feels off with your international search traffic, check your canonicals first. That is where the bug usually lives.