Wer als deutsches Unternehmen auch den polnischen Markt ansprechen will, oder umgekehrt als polnischer Anbieter nach Deutschland expandiert, steht vor einer technischen Grundsatzfrage: Wie baut man eine zweisprachige Website so, dass Google beide Versionen korrekt indexiert, die richtige Version den richtigen Nutzern ausspielt und kein Duplicate-Content-Problem entsteht?

Ich betreue solche Setups seit Jahren - zuletzt für einen Möbelshop, der von Polen aus nach Deutschland verkauft, und für eine Hamburger Dienstleistungsfirma mit Zweigstelle in Posen. Die technischen Fehler sind dabei immer ähnlich: falsche Canonical-Tags, fehlende Rücklinks in den hreflang-Paaren oder eine einzige Sitemap für beide Sprachen. Dieser Artikel zeigt, wie Sie das von Anfang an richtig aufbauen.

URL-Struktur: Ordner, Subdomain oder ccTLD?

Die erste Entscheidung fällt schon vor dem ersten hreflang-Tag: Welche URL-Architektur verwenden Sie?

Drei Varianten stehen zur Wahl:

  • Unterordner: example.com/de/ und example.com/pl/
  • Subdomain: de.example.com und pl.example.com
  • ccTLD: example.de und example.pl

URL-Strukturen im Vergleich

KriteriumUnterordnerSubdomainccTLD
Domain-Autorität geteiltJa, vollNein, getrenntNein, getrennt
Geo-Signal für GoogleMittel (hreflang)Mittel (hreflang)Stark (TLD)
EinrichtungsaufwandGeringMittelHoch
WartungsaufwandGeringMittelHoch
Empfehlung für KMUErste WahlAkzeptabelNur bei echten Marken

Für die meisten kleinen und mittleren Unternehmen ist die Unterordner-Struktur die richtige Wahl. Alle Unterseiten profitieren von der gemeinsamen Domain-Autorität, die Verwaltung läuft auf einer einzigen WordPress-Installation, und die hreflang-Implementierung ist unkomplizierter als bei getrennten Domains.

ccTLDs machen nur Sinn, wenn Sie zwei echte Markenidentitäten führen - etwa ein deutsches .de-Unternehmen, das unter eigenem polnischem Namen am PL-Markt auftritt. Dann spart das Geo-Signal den halben SEO-Aufwand, aber Sie pflegen faktisch zwei separate Websites.

Subdomains gelten bei Google seit Jahren als separate Entitäten. Die Link-Autorität, die Ihre Hauptdomain aufgebaut hat, nützt der Subdomain kaum. Für ein KMU, das gerade erst mit internationalem SEO beginnt, ist das ein unnötiger Startnachteil.

hreflang-Paare korrekt setzen

Der hreflang-Tag sagt Google: "Diese Seite existiert in diesen Sprachversionen, und hier sind die URLs." Das klingt einfach, aber über 65 % der internationalen Websites haben laut einer Analyse von LinkGraph signifikante Implementierungsfehler.

Die Grundstruktur für eine deutsch-polnische Website sieht im <head>-Bereich so aus:

<link rel="alternate" hreflang="de-DE" href="https://example.com/de/seite/" />
<link rel="alternate" hreflang="pl-PL" href="https://example.com/pl/strona/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/de/seite/" />

Dieser Block steht auf beiden Sprachversionen der Seite. Das ist der Punkt, an dem die meisten Fehler passieren: Nur die deutsche Seite bekommt die Tags, die polnische nicht. Google ignoriert dann das gesamte hreflang-Setup, weil es nicht bidirektional ist.

hreflang-Pflichten pro Seite

  • Jede Sprachversion listet alle Sprachversionen auf (also DE listet DE + PL, PL listet PL + DE)
  • Jede Version enthält einen Self-Link auf sich selbst
  • Der hreflang-Code entspricht dem BCP-47-Standard (de-DE, pl-PL - kein "german" oder "polish")
  • x-default ist gesetzt
  • URLs sind absolut (mit https://), nicht relativ

Die Canonical-Falle

Der häufigste Fehler, den ich in Audits sehe, ist der falsche Canonical. Viele Themes oder Plugin-Konfigurationen setzen auf der polnischen Version den Canonical auf die deutsche Hauptversion - in der Annahme, das sei die "originale" Seite. Das ist technisch falsch und kontraproduktiv.

Gilt auf example.com/pl/strona/ der Canonical example.com/de/seite/, signalisiert das Google: Die polnische Seite ist ein Duplikat der deutschen. Google ignoriert dann die polnische Version im Index, und Ihre hreflang-Tags werden wirkungslos.

Die Regel ist einfach: Jede Sprachversion zeigt mit dem Canonical auf sich selbst. Die deutsche Seite canonical auf die deutsche URL, die polnische Seite canonical auf die polnische URL.

Vorteile

  • Self-Canonical verhindert, dass Sprachversionen als Duplikate gewertet werden
  • Klare Signalkette: hreflang zeigt Alternativen, Canonical zeigt die kanonische Version der jeweiligen Sprache
  • Google kann beide Versionen eigenständig indexieren

Nachteile

  • Zwei separate Seiten mit ähnlichem (übersetztem) Inhalt können bei schlechter Übersetzungsqualität noch immer Duplicate-Content-Signale auslösen
  • Pflege ist aufwändiger als eine monolithische Website

Bei WordPress mit WPML oder Polylang setzt das Plugin den Self-Canonical automatisch, sofern Sie keine SEO-Plugin-Einstellungen manuell überschrieben haben. Prüfen Sie das trotzdem mit dem "URL Inspection"-Tool der Google Search Console für mindestens eine DE- und eine PL-Seite.

Getrennte Sitemaps: Warum und wie

Eine einzige sitemap.xml für alle Sprachen ist technisch möglich, aber unpraktisch. Wenn Sie zwei getrennte Sitemaps einreichen - sitemap-de.xml und sitemap-pl.xml - haben Sie in der Google Search Console sofort eine saubere Übersicht darüber, wie viele DE-Seiten und wie viele PL-Seiten indexiert sind, und welche Fehler es gibt.

Bei WPML erstellt das Plugin standardmäßig eine Sitemap pro Sprache und verlinkt diese in der zentralen sitemap_index.xml. Bei Polylang übernimmt das Rank Math oder Yoast SEO, sofern das Plugin korrekt konfiguriert ist.

2Sitemaps empfohlen (je eine pro Sprache)
65%internationale Websites mit hreflang-Fehlern (LinkGraph, 2026)
3valide Implementierungswege für hreflang (Head, HTTP-Header, Sitemap)
45%durchschnittlicher Anstieg organischer Sichtbarkeit nach korrekter hreflang-Implementierung (Fallstudie Kiran Kumar, 2026)

Fügen Sie beide Sitemaps in der Google Search Console unter "Sitemaps" hinzu. So sehen Sie auf einen Blick: Wie viele PL-Seiten sind indexiert? Gibt es hreflang-Fehler für die polnischen URLs? Das ist der schnellste Weg, Implementierungsprobleme zu erkennen.

x-default: Die unterschätzte Zeile

x-default ist kein Pflichtfeld, aber ich setze es immer. Es teilt Google mit, welche Seite ausgespielt werden soll, wenn kein hreflang-Wert auf die Nutzersprache passt - also etwa für Nutzer aus Großbritannien oder den USA, die weder Deutsch noch Polnisch als Browsersprache eingestellt haben.

Für eine typische deutsch-polnische Unternehmenswebsite gibt es drei sinnvolle Optionen:

1. x-default zeigt auf die stärkere Marktversion (meist DE)
2. x-default zeigt auf eine neutrale Startseite mit Sprachauswahl
3. x-default zeigt auf die DE-Version, weil Deutschland der Hauptmarkt ist

Ich empfehle Option 3 für die meisten meiner Kunden, weil es einfach zu pflegen ist und Google eine klare Anweisung bekommt.

Setzen Sie x-default nie auf eine Weiterleitungs-URL oder eine Seite, die ihrerseits einen Canonical auf eine andere Seite trägt. Das erzeugt eine Signalkette, die Google verwirrt.

WPML-Setup vs. manuelles Setup: Wo der Unterschied liegt

WPML ist das meistgenutzte Plugin für mehrsprachige WordPress-Websites, und es funktioniert gut, wenn man es richtig konfiguriert. Aber es gibt Punkte, bei denen ein manuelles Setup oder ein schlankes Plugin wie Polylang die bessere Wahl ist.

Das Hauptproblem bei WPML: Wenn eine Übersetzung nicht im Übersetzungsmanager verknüpft ist, generiert WPML den hreflang-Tag nur einseitig. Die deutsche Seite verlinkt auf die polnische, aber die polnische verlinkt nicht zurück. Google ignoriert den gesamten hreflang-Block.

Dazu kommt, dass WPML bei komplexen Setups mit mehreren SEO-Plugins (Rank Math + WPML + ACF) manchmal doppelte Canonical-Tags erzeugt. Ich habe das in einem Projekt für einen Hamburger Großhändler gesehen: Rank Math setzte den Self-Canonical, WPML schrieb einen zweiten Canonical drüber, der auf die DE-Version zeigte. Die polnischen Seiten verschwanden aus dem Google-Index.

Bei einem manuellen Setup über functions.php oder ein eigenes Mu-Plugin haben Sie die volle Kontrolle, aber Sie müssen jeden hreflang-Tag selbst pflegen. Das skaliert nicht für Sites mit Hunderten von Seiten. Meine Empfehlung: WPML oder Polylang für die Automatisierung, aber nach jeder größeren Änderung manuelle Prüfung über das URL-Inspection-Tool.

Wenn Sie weiter wissen wollen, wie Sie ein mehrsprachiges WooCommerce-Setup für den deutschen Markt aufbauen, lesen Sie meinen Artikel über den vollständigen Einstieg als deutscher Händler nach Polen und was über eine reine Übersetzung hinaus zur echten polnischen Lokalisierung gehört.

Der Prüf-Workflow nach dem Go-live

Nach dem Launch einer deutsch-polnischen Website läuft die Prüfung bei mir immer in derselben Reihenfolge ab:

Post-Launch hreflang-Prüfung

  • URL Inspection in Google Search Console für mindestens 3 DE- und 3 PL-URLs durchführen
  • Im GSC-Bericht "Internationales Targeting" prüfen, ob Fehler unter "Sprache" gemeldet sind
  • Beide Sitemaps in GSC einreichen und Indexierungsrate nach 7 Tagen kontrollieren
  • Mit dem Hreflang-Checker von SISTRIX oder ahrefs.com zwei bis drei Seiten auf korrekte Bidirektionalität prüfen
  • Canonical-Tags mit dem "Inspect URL"-Ergebnis im Rendered HTML abgleichen
  • In der GSC-Suche nach "alternate" filtern, um doppelte hreflang-Deklarationen zu finden

Diesen Workflow führe ich auch bei bestehenden Websites durch, die ich übernehme. In 70 % der Fälle finde ich dabei mindestens einen kritischen Fehler - fehlende Rücklinks, falsche Canonicals oder x-default, das auf eine 301-Weiterleitung zeigt.

Weitere Informationen zu steuerlichen Aspekten beim deutsch-polnischen E-Commerce finden Sie im Artikel über VAT OSS und KSeF für deutsche Shops nach Polen. Steuer- und rechtliche Fragen beantworte ich als Webentwickler nicht abschließend - dafür empfehle ich einen Steuerberater oder Rechtsanwalt mit Erfahrung im EU-grenzüberschreitenden Handel.

Checkliste für das Erstsetup

Deutsch-polnische Website: Technisches SEO Erstsetup

  • URL-Struktur festlegen (Unterordner empfohlen für KMU)
  • WordPress-Sprachplugin wählen und Übersetzungen vollständig verknüpfen (WPML oder Polylang)
  • hreflang-Tags auf jeder Seite bidirektional prüfen (DE verlinkt PL, PL verlinkt DE)
  • Self-Canonical auf jeder Sprachversion einrichten
  • x-default setzen (empfohlen: auf DE-Version oder neutrale Startseite)
  • Zwei getrennte Sitemaps generieren und in GSC einreichen
  • Google Search Console getrennte Properties je Sprache oder gemeinsame Domain-Property einrichten
  • Nach 7-14 Tagen ersten Indexierungscheck durchführen

Die technische Grundlage für eine mehrsprachige Website ist in wenigen Stunden sauber aufgesetzt, wenn man weiß, worauf es ankommt. Die häufigsten Fehler entstehen nicht bei der Ersteinrichtung, sondern später: wenn Seiten hinzukommen, Übersetzungen nicht verknüpft werden oder ein Plugin-Update die Canonical-Logik überschreibt. Bauen Sie deshalb den Post-Launch-Prüf-Workflow von Anfang an in Ihren Redaktionsprozess ein.


, , , ,