Case study: one partner website, three countries – Next.js, hreflang and ccTLDs in practice

The starting point

Angela is an independent partner of RINGANA, an Austrian manufacturer of fresh cosmetics. Her goal: a personal website where prospects can find her, get to know her and reach out easily – not just in Germany, but equally in Austria and Switzerland.

Sounds like a classic one-pager? It wasn't. Three constraints made the project technically and conceptually interesting:

• Strict brand guidelines. The protected manufacturer name must not appear in the domain, official product imagery and logos are off-limits, and all content has to be written from a personal first-person perspective. The finished site was reviewed and approved by the manufacturer before launch.
• Three target countries, one language. Germany, Austria and Switzerland speak (almost) the same German – for search engines, that's a textbook duplicate-content trap.
• SEO from absolute zero. New brand, new domain, no backlinks. Every technical decision had to help the site get indexed and ranked anyway.

The result is glow-with-angy.de – and this post covers what's under the hood.

A brand without the brand name

Since the manufacturer's name couldn't appear in the address, the project started with naming. The answer was a personal brand built around the client's nickname: glow-with-angy – short, memorable, trademark-safe, and available as a domain in all three target countries: .de, .at and .ch.

This step often gets skipped in projects like this, yet it decides everything downstream: a domain you can spell out over the phone is marketing. And three country domains are – as we'll see – the strongest geo signal you can hand to Google.

One repository, three country domains

In our experience a .de domain struggles to rank in Austria and Switzerland – Google favors local results and treats the country-code top-level domain (ccTLD) as an unambiguous signal of belonging. So instead of a single domain with language paths (/at/, /ch/), we went with three real ccTLDs.

The interesting part is the deployment model: there is exactly one Next.js repository (App Router, statically prerendered) deployed as three separate Vercel projects. Each project receives its identity via environment variables:

• NEXT_PUBLIC_BASE_URL sets the canonical domain of that project,
• NEXT_PUBLIC_SITE_COUNTRY (DE/AT/CH) drives country-specific content.

A single git push to main builds and publishes all three country sites at once. No content syncing, no triple maintenance, no drift – the infrastructure does the internationalization.

hreflang, canonicals and the duplicate-content trap

Three domains with similar content initially pose a problem for search engines: which version belongs in which country index? The technical answer has two parts:

• Self-referencing canonicals. Each domain declares itself the canonical version – possible because metadataBase is fed from the per-project environment variable.
• Cross-domain hreflang. Every page points to its sibling URLs via hreflang: de-DE to .de, de-AT to .at, de-CH to .ch, plus x-default. That way Google understands the three domains as country variants of one entity rather than copies.

In practice we still hit the moment familiar to most internationalization projects: for .at and .ch, Search Console initially reported "Duplicate – Google chose a different canonical". The content was simply too identical; hreflang alone didn't change Google's mind.

The fix was editorial rather than technical: country-specific copy per domain. Titles, descriptions, headings, intros and FAQ answers now vary with NEXT_PUBLIC_SITE_COUNTRY – the Austrian site talks about starting "in Österreich", the Swiss site "in der Schweiz". A charming detail: Swiss Standard German doesn't use the "ß" character, so a small helper automatically replaces every "ß" with "ss" on the .ch domain. Since then, Google picks each domain's own URL as canonical – exactly as intended.

Content architecture: landing pages and topic clusters

Rather than piling everything onto the homepage, each search intent got its own focused landing page, complemented by a blog organized in topic clusters whose posts deliberately link back to the landing pages. You can see it live – for example the landing page for prospective partners with its FAQ section and structured data.

Speaking of structured data – the site ships a complete JSON-LD set:

• FAQPage on the landing pages (the basis for FAQ rich results),
• BreadcrumbList for clean snippet paths,
• Person with sameAs references to social profiles – important because for a personal brand, the identity behind the site is the real trust signal,
• WebSite with a publisher reference.

Performance and privacy

The entire site is statically prerendered – there's simply no reason to render a marketing site at request time. Images run through Next.js image optimization with AVIF/WebP and fixed dimensions; JavaScript stays minimal. The result: consistently green Core Web Vitals, the standard we describe in our Core Web Vitals article.

The contact form avoids third-party services: inquiries are sent server-side via SMTP straight to the client's own mailbox – GDPR-friendly, with no external form service data leaves to.

Lessons from the trenches

Two takeaways from this project that may save other teams some time:

• Vercel projects created via CLI have no framework preset. Two of the three projects were created through the Vercel CLI – and sat at framework: null. The consequence: the Next.js build passed green but was served as static files, and every route answered 404. The fix is a repo-wide vercel.json with an explicit "framework": "nextjs", which enforces the preset for all connected projects.
• Preview deployments belong on noindex. With three production domains plus previews, you quickly breed a zoo of crawlable URLs. Indexing is therefore strictly tied to the production environment – previews stay invisible to search engines.

The result

Three country sites are live today from a single codebase: glow-with-angy.de, glow-with-angy.at and glow-with-angy.ch – each with its own canonical identity, country-specific content, complete structured data, and a deployment that updates with a single push. The manufacturer's brand-compliance review approved the site without requesting any technical changes.

For us, this project is a nice reminder that "small" websites can demand more interesting engineering decisions than many a large portal: internationalization, trademark constraints, SEO architecture and deployment design – all in a project that, to visitors, simply feels light and personal.

Planning something similar?

Whether it's a personal brand, a multi-country presence or a website with a real SEO foundation: these are exactly the projects we love to build. Have a look at how we approach web projects, or get in touch directly – we think about naming, engineering and visibility as one thing from day one.