Ein Hostname unter einer übergeordneten Domain, etwa docs.example.com, der einen eigenen technischen oder inhaltlichen Zweck erfüllen kann und als Teil der gesamten Website-Architektur geplant werden muss.
Die Entscheidung und ihre Grenze
Eine Subdomain ist ein Hostname unterhalb eines anderen Domainnamens, zum Beispiel docs.example.com unter example.com. Technisch kann sie eine eigene Anwendung, eigenes Routing, eigene Cookies, eine eigene DNS-Konfiguration und eine eigene Präsenz in Suchergebnissen haben. Diese Flexibilität entscheidet die Frage der Informationsarchitektur aber nicht. Die Wahl zwischen Subdomain und Unterverzeichnis sollte sich an der betrieblichen Zuständigkeit, den Produktgrenzen, Anforderungen an Lokalisierung oder Plattform und dem Nutzerweg richten, nicht an einem angenommenen SEO-Bonus.
Was Sie prüfen sollten
Erfassen Sie jeden Hostnamen mit Zweck, Verantwortlichem, kanonischem Host, TLS-Status, robots-Regeln, Sitemap, Analytics-Zuordnung und den Pfaden der internen Verlinkung. Crawlen Sie repräsentative Seiten über die Grenze hinweg und prüfen Sie, ob Links direkt auf die vorgesehenen kanonischen Routen zeigen. Bei einer Migration behalten Sie eine URL-genaue Zuordnung bei und testen jedes Ziel, statt anzunehmen, dass ein hostweites Routing ausreicht.
Ein praktischer Umsetzungsweg
Verwenden Sie eine Subdomain, wenn sie eine stabile, nachvollziehbare Grenze schafft, etwa für Dokumentation, eine Anwendung oder eine regional getrennte Plattform. Geben Sie ihr eine klare eigene Navigation und Indexierungsregel und bewahren Sie zugleich kontextuelle Links zur übergeordneten Website. Wenn Sie Inhalte zwischen Hostnamen verschieben, richten Sie wo sinnvoll direkte permanente Weiterleitungen (301) ein, aktualisieren Sie Verweise auf kanonische URLs und in Sitemaps und prüfen Sie Rendering und Tracking auf beiden Seiten.
Fehler und Grenzen der Messung
Der riskante Abkürzungsweg ist, eine Subdomain nur anzulegen, um SEO-Arbeit zu isolieren oder Duplicate Content auszulagern. Das kann die Zuständigkeit zersplittern und seitenweite Korrekturen erschweren. Behaupten Sie nicht, dass eine Subdomain Autorität automatisch erbt oder verliert; bewerten Sie die tatsächlichen Links, Inhalte, Erreichbarkeit und Umsetzung der Migration.
Praxisbeispiel zur Architektur. Ein Unternehmen legt Produktdokumentation auf docs.example.com, weil ein eigenes Dokumentationssystem und ein eigenes Team sie verantworten; eine kundenseitige Anwendung liegt auf app.example.com. Das kann eine stimmige Grenze sein, wenn Navigation, Erwartungen an Konten, Suchrichtlinie und Zuständigkeit klar sind. Einen Marketing-Ordner nur auf eine Subdomain zu verschieben, weil er ein anderes Template hat, ist ein deutlich schwächerer Grund. Dokumentieren Sie den Nutzerweg über die Hosts hinweg, bevor Sie den Hostnamen festlegen.
Prüfkriterien. Führen Sie ein Host-Inventar mit Zweck, Hauptverantwortlichem, öffentlichem kanonischem Host, Sitemap, robots-Richtlinie, TLS-Abdeckung, Analytics-Umfang und den wichtigsten Einstiegsrouten. Crawlen Sie repräsentative Seiten vom übergeordneten Host zur Subdomain und zurück und prüfen Sie direkte interne Links, das Weiterleitungsverhalten sowie Footer- oder Navigationspfade. Bei einem Umzug testen Sie die alten und neuen URL-Paare, nicht nur die Startseite des Hostnamens. Prüfen Sie Browser- und Mobil-Nutzerwege, wenn Cookies, Login oder die Übergabe an eine Anwendung betroffen sind.
Häufige Fehler. Duplizieren Sie denselben Inhalt nicht über Root-Host und Subdomain, ohne eine explizite Entscheidung zur kanonischen URL oder zur Migration. Gehen Sie nicht davon aus, dass Suchsysteme alle Hostnamen als eine Website oder als völlig unabhängig behandeln; prüfen Sie die tatsächliche Link- und URL-Struktur. Eine Änderung des Hostnamens betrifft Betrieb, Analyse und Nutzervertrauen ebenso wie SEO und braucht deshalb einen Rollback-Plan auf Routenebene.