Unsere Brand-Domain ist alexsdev.io — eine internationale, englischsprachige Website für Softwareentwicklung und Infrastruktur. Die Herausforderung: Wir wollten zusätzlich in Deutschland, Österreich und der Schweiz bei Google sichtbar werden, ohne die bestehende Domain aufzugeben oder SEO-Konflikte zu erzeugen. In diesem Artikel zeigen wir, wie wir das tatsächlich umgesetzt haben — mit konkretem Code und den Entscheidungen dahinter.

Das Grundproblem: .io-Domain und deutsches Ranking

Eine .io-Domain wird von Google als generische Top-Level-Domain behandelt — sie ist keinem bestimmten Land zugeordnet. Das ist ein Vorteil für internationale Projekte, aber ein Nachteil, wenn Sie gezielt in Deutschland ranken möchten. Google muss explizit erfahren, dass ein Teil Ihrer Website deutschsprachig ist und sich an den DACH-Markt richtet.

Drei gängige Strategien standen zur Wahl:

Wir haben uns für die Subdirectory-Strategie entschieden. Der wichtigste Grund: Die Domain Authority von alexsdev.io wird auf /de/ vererbt. Jeder Backlink auf die Hauptdomain stärkt auch die deutschen Inhalte.

Subdirectory-Struktur mit Nginx aufsetzen

Unsere Website wird als statisches HTML von Nginx ausgeliefert. Die deutschen Seiten liegen physisch im Verzeichnis demos/de/ und spiegeln die englische Struktur:

demos/
  index.html          # EN Startseite
  services/           # EN Services
  blog/               # EN Blog
  de/
    index.html        # DE Startseite
    services/         # DE Leistungen
    blog/             # DE Blog

In der Nginx-Konfiguration brauchen wir keine speziellen Location-Blöcke für /de/ — Nginx liefert die Dateien direkt aus dem Dateisystem aus. Entscheidend ist die try_files-Direktive:

location / {
    try_files $uri $uri/ $uri/index.html =404;
}

Ein Request an /de/services/ wird damit automatisch zu demos/de/services/index.html aufgelöst. Kein Rewrite, kein Proxy — einfach statische Dateien.

hreflang-Tags: Google die Sprachversionen mitteilen

Das wichtigste SEO-Signal für mehrsprachige Websites sind hreflang-Tags. Sie teilen Google mit, welche Seite für welche Sprache gedacht ist. Ohne diese Tags riskieren Sie, dass Google die deutsche Seite als Duplicate Content der englischen wertet.

Jede englische Seite, die ein deutsches Pendant hat, enthält diese Tags im <head>:

<!-- Auf der englischen Seite (z.B. /services/) -->
<link rel="alternate" hreflang="en"
      href="https://alexsdev.io/services/">
<link rel="alternate" hreflang="de"
      href="https://alexsdev.io/de/services/">
<link rel="alternate" hreflang="x-default"
      href="https://alexsdev.io/services/">

Und die deutsche Seite enthält dieselben Tags — das ist wichtig, die Verweise müssen bidirektional sein:

<!-- Auf der deutschen Seite (z.B. /de/services/) -->
<link rel="alternate" hreflang="en"
      href="https://alexsdev.io/services/">
<link rel="alternate" hreflang="de"
      href="https://alexsdev.io/de/services/">
<link rel="alternate" hreflang="x-default"
      href="https://alexsdev.io/services/">

Der x-default-Tag zeigt auf die englische Version und signalisiert Google: „Wenn keine passende Sprache gefunden wird, zeige diese Seite.“

Seiten ohne Pendant

Nicht jede Seite existiert in beiden Sprachen. Unsere englischen Blog-Artikel haben beispielsweise keine deutsche Übersetzung — und sollen auch keine bekommen. Für solche Seiten setzen wir nur:

<link rel="alternate" hreflang="en"
      href="https://alexsdev.io/blog/secure-vps-server/">
<link rel="alternate" hreflang="x-default"
      href="https://alexsdev.io/blog/secure-vps-server/">

Kein hreflang="de", weil es keine deutsche Version gibt. Google versteht das korrekt.

Canonical URLs: Jede Seite hat genau eine

Ein häufiger Fehler bei mehrsprachigen Websites: Alle Sprachversionen verweisen per Canonical auf die englische Hauptseite. Das wäre falsch — damit würde Google die deutsche Seite als Duplikat ignorieren.

Die Regel ist einfach: Jede Seite verweist auf sich selbst.

<!-- Auf /de/services/ -->
<link rel="canonical"
      href="https://alexsdev.io/de/services/">

<!-- Auf /services/ -->
<link rel="canonical"
      href="https://alexsdev.io/services/">

Zusätzlich setzen wir og:locale korrekt. Die deutsche Seite bekommt de_DE, die englische en_US, und beide verweisen per og:locale:alternate auf die jeweils andere Sprache.

Sitemap mit Sprachversionen

Google erkennt hreflang nicht nur aus dem HTML, sondern auch aus der Sitemap. Wir nutzen den xhtml:link-Namespace in unserer sitemap.xml, um die Sprachpaare zu deklarieren:

<url>
  <loc>https://alexsdev.io/services/</loc>
  <lastmod>2026-03-09</lastmod>
  <xhtml:link rel="alternate" hreflang="en"
    href="https://alexsdev.io/services/" />
  <xhtml:link rel="alternate" hreflang="de"
    href="https://alexsdev.io/de/services/" />
  <xhtml:link rel="alternate" hreflang="x-default"
    href="https://alexsdev.io/services/" />
</url>

<url>
  <loc>https://alexsdev.io/de/services/</loc>
  <lastmod>2026-03-09</lastmod>
  <xhtml:link rel="alternate" hreflang="en"
    href="https://alexsdev.io/services/" />
  <xhtml:link rel="alternate" hreflang="de"
    href="https://alexsdev.io/de/services/" />
  <xhtml:link rel="alternate" hreflang="x-default"
    href="https://alexsdev.io/services/" />
</url>

Beide Einträge — EN und DE — enthalten jeweils alle drei Links. Das ist Pflicht: Unvollständige Sitemap-hreflang-Paare werden von Google ignoriert.

Domain-Redirect: alexsdev.de als Eingang

Wir haben zusätzlich alexsdev.de registriert. Diese Domain dient nicht als eigenständige Website, sondern leitet per 301-Redirect direkt auf alexsdev.io/de/ weiter:

# Nginx-Konfiguration für alexsdev.de
server {
    listen 443 ssl;
    server_name alexsdev.de www.alexsdev.de;

    ssl_certificate     /etc/nginx/ssl/origin-de.crt;
    ssl_certificate_key /etc/nginx/ssl/origin-de.key;

    return 301 https://alexsdev.io/de$request_uri;
}

Der Vorteil: Wer alexsdev.de in die Adressleiste tippt, landet automatisch auf der deutschen Version. Gleichzeitig gibt es keine Duplicate-Content-Probleme, weil der 301-Redirect Google klar signalisiert: „Die kanonische Adresse ist alexsdev.io/de/.“

Die DNS für alexsdev.de läuft über Cloudflare mit einem Cloudflare Origin Certificate auf dem Server. Keine zusätzliche Infrastruktur notwendig.

Automatische Spracherkennung für den ersten Besuch

Wenn ein Besucher zum ersten Mal auf alexsdev.io landet, prüfen wir serverseitig den Accept-Language-Header. Enthält er de (typisch für Browser in Deutschland, Österreich und der Schweiz), wird der Nutzer per 302-Redirect auf /de/ weitergeleitet:

# Nginx: Accept-Language Erkennung
map $http_accept_language $browser_lang {
    default  "";
    "~*^de"  "de";
}

map $cookie_lang_pref $lang_pref {
    default  "";
    "en"     "en";
    "de"     "de";
}

location = / {
    if ($lang_pref = "") {
        set $lang_pref $browser_lang;
    }
    if ($lang_pref = "de") {
        return 302 /de/;
    }
    # Sonst: englische Startseite
}

Sobald der Nutzer über den Sprachumschalter (ein kleines DE/EN-Icon in der Statusleiste) die Sprache manuell wählt, wird ein Cookie gesetzt. Beim nächsten Besuch hat der Cookie Vorrang vor dem Browser-Header. So wird niemand gegen seinen Willen umgeleitet.

Deutsche Inhalte sind keine Übersetzungen

Ein wichtiger strategischer Punkt: Die deutschen Seiten sind keine 1:1-Übersetzungen der englischen. Die Service-Beschreibungen sind für den deutschen Markt angepasst — andere Keywords, andere Tonalität, andere Beispiele. Deutsche Blog-Artikel sind eigenständige Inhalte, die auf Keywords und Themen abzielen, die im DACH-Raum gesucht werden.

Google bewertet eigenständigen Content deutlich besser als maschinelle Übersetzungen. Außerdem können Sie so gezielt auf Suchbegriffe optimieren, die in der jeweiligen Sprache unterschiedlich formuliert werden — „Server absichern“ ist nicht dasselbe Keyword wie „secure a server“.

Was wir gelernt haben

Nach der Umsetzung können wir folgende Learnings teilen:

Ergebnis

Innerhalb weniger Tage nach dem Launch der deutschen Inhalte erscheinen die /de/-Seiten bereits in der Google Search Console. Die bestehende Domain Authority von alexsdev.io sorgt dafür, dass neue Seiten schneller indexiert werden als auf einer frischen Domain. Gleichzeitig bleibt die internationale Marke vollständig erhalten — englischsprachige Besucher sehen weiterhin die englische Website, ohne jemals mit der deutschen Version in Berührung zu kommen.

Die Kombination aus Subdirectory, sauberen hreflang-Tags und einer separaten Content-Strategie für jede Sprache ist aus unserer Sicht der effektivste Weg, eine internationale Website für den deutschen Markt zu öffnen — ohne Kompromisse bei der bestehenden SEO-Performance.