Subdomain oder Unterverzeichnis: wo Blog und Shop hingehören

Für die meisten Websites lautet die kurze Antwort: Der Blog gehört ins Unterverzeichnis, der Rest hängt vom Anwendungsfall ab. Wer blog.beispiel.de und beispiel.de/blog nebeneinanderstellt, vergleicht nicht zwei gleichwertige Varianten derselben Struktur, sondern zwei technisch unterschiedliche Hosts – mit Folgen für drei Bereiche, die selten zusammen gedacht werden: wie viel Autorität von einem Bereich in den anderen fließt, ob Analytics-Tools eine durchgehende Nutzerreise sehen, und wer die Infrastruktur dahinter warten muss.

Diese Entscheidung wird oft nebenbei getroffen – meist weil ein Tool, ein Helpdesk, ein Shopsystem oder ein Docs-Generator, eine Subdomain als Standard vorschlägt und niemand die Konsequenzen durchdenkt. Sie lässt sich später nicht beliebig rückgängig machen, ohne eine vollständige URL-Migration zu durchlaufen. Die folgenden Abschnitte ordnen die Entscheidung für Blog, Shop und Hilfe-Center einzeln ein – nicht als eine Frage, sondern als drei getrennte mit drei unterschiedlichen Antworten.

Was technisch wirklich passiert: zwei Hosts, eine Domain

Eine Subdomain wie blog.beispiel.de ist aus Sicht von DNS, Webserver und Browser ein eigener Host. Sie kann auf einem anderen Server liegen, ein anderes SSL-Zertifikat verwenden, eine andere robots.txt ausliefern und, das ist der Punkt, der die meisten Probleme verursacht, Cookies bekommen, die standardmäßig nur für genau diesen Host gültig sind. beispiel.de/blog dagegen ist einfach ein Pfad auf demselben Host: gleicher Server, gleiches Zertifikat, gleiche robots.txt, gleiche Cookies, ohne dass irgendjemand das konfigurieren muss.

Für Google ist die Unterscheidung nicht ganz so hart. Moderne Crawling- und Indexierungssysteme sind in der Lage, eine Subdomain einer erkennbaren Marke zuzuordnen und Signale weitgehend zusammenzuführen. Das ist aber kein Freibrief: Es bedeutet, dass Google in vielen Fällen kompensiert, nicht, dass die Struktur irrelevant wird. Wo die Suchergebnisse hart umkämpft sind, zählt jedes bisschen zusätzliche Sicherheit, und ein Unterverzeichnis lässt weniger Interpretationsspielraum, wie Autorität zugeordnet wird, als eine Subdomain.

Ein weiterer, oft übersehener Punkt: Crawl-Budget wird von Google pro Host zugeteilt, nicht pro Marke. Eine zusätzliche Subdomain bedeutet einen zusätzlichen Host, den der Crawler unabhängig priorisieren muss. Für die meisten mittelständischen Websites ist das kein entscheidender Faktor, aber bei sehr großen Katalogen oder vielen parallelen Subdomains addiert sich dieser Effekt.

Autorität und Linkkraft: warum die URL-Struktur die Grenze zieht

Backlinks, interne Verlinkung und thematische Relevanz akkumulieren sich primär auf Host-Ebene. Ein Link von einer externen Seite auf blog.beispiel.de stärkt zuerst diesen Host; dass ein Teil dieser Stärke auf beispiel.de durchschlägt, ist wahrscheinlich, aber nicht mit derselben Sicherheit messbar wie bei einem Link auf beispiel.de/blog, der ohne Umweg denselben Host stärkt, auf dem auch die Produktseiten liegen.

Das wird besonders sichtbar, wenn ein Content-Bereich genau die Funktion hat, Links und Zitierungen einzusammeln, was für einen Firmenblog der Normalfall ist. Ein Blogartikel, der zitiert, verlinkt oder in einer Presseerwähnung referenziert wird, soll diese Stärke idealerweise an die Seiten weitergeben, die tatsächlich konvertieren sollen. Liegt der Blog auf einer Subdomain, ist dieser Übertrag ein zusätzlicher, unsicherer Schritt. Liegt er im Unterverzeichnis, ist er der Normalfall der internen Verlinkung, keine Extraleistung, die man sich erst verdienen muss.

Mehrere Unternehmen, die ihren Blog von einer Subdomain in ein Unterverzeichnis der Hauptseite verschoben haben, haben danach ein organisches Wachstum dokumentiert, ein Muster, das sich mit dem oben beschriebenen Mechanismus deckt, auch wenn die Größenordnung von Fall zu Fall stark variiert und sich nicht verallgemeinern lässt. Der Mechanismus dahinter ist immer derselbe: vorher getrennte Signale werden auf einem einzigen Host gebündelt, statt sich zwischen zwei Hosts aufzuteilen.

Umgekehrt gilt: Wer aus organisatorischen Gründen an der Subdomain festhalten muss, kann diesen Nachteil abmildern, indem er konsequent und häufig von den starken Seiten der Hauptdomain auf die relevanten Blogartikel verlinkt und umgekehrt. Vollständig ausgleichen lässt sich der Unterschied dadurch nicht, aber die thematische Verbindung wird für Crawler wie für Nutzer deutlich klarer sichtbar.

Tracking und Analytics: wenn eine Sitzung mitten im Trichter abreißt

Cookies sind an eine Domain gebunden. Ein Cookie, das für beispiel.de gesetzt wird, ist für blog.beispiel.de nur lesbar, wenn es explizit mit dem Attribut Domain=beispiel.de gesetzt wurde. Viele CMS- und Analytics-Implementierungen tun das nicht automatisch, besonders wenn Blog und Hauptseite auf unterschiedlicher Infrastruktur laufen oder unterschiedliche Tracking-Container verwenden.

Die praktische Folge: Ein Nutzer liest einen Blogartikel auf blog.beispiel.de, klickt auf einen internen Link zu beispiel.de und wechselt dabei technisch den Host. Ohne korrekt geteilte Cookies beginnt an dieser Stelle eine neue Sitzung, und das Analytics-Tool zeichnet den Wechsel als eigene Zuweisung auf, typischerweise als Verweis von blog.beispiel.de. Der ursprüngliche Kanal, über den der Nutzer eigentlich gekommen ist, Suche, Social oder E-Mail, geht in der Berichterstattung verloren. Conversion-Reports schreiben den Umsatz dann dem eigenen Blog als Quelle zu, was die tatsächliche Marketingleistung verzerrt und Budgetentscheidungen auf falsche Zahlen stützt.

Bei einem Unterverzeichnis existiert diese Host-Grenze gar nicht: gleiche Domain, gleiche Cookies, eine durchgehende Sitzung vom ersten Blogartikel bis zum Checkout, ohne dass jemand eine Cross-Domain-Konfiguration einrichten muss. Für einen Shop auf einer eigenen Subdomain gilt dasselbe Problem in verschärfter Form, weil dort tatsächlich Umsatz an der Bruchstelle hängt: Wer den Weg von einem informierenden Artikel bis zum Kauf sauber messen will, muss Cross-Domain-Tracking bewusst einrichten und regelmäßig prüfen, ob es nach jedem Plattform-Update noch funktioniert.

Ein Hilfe-Center auf einer Subdomain hat dasselbe Problem in abgeschwächter Form: Wenn ein Nutzer von einem Hilfeartikel zurück zur Hauptseite wechselt, um dort ein Formular auszufüllen oder ein Konto zu öffnen, verliert auch dieser Übergang ohne saubere Cookie-Konfiguration seinen ursprünglichen Kontext.

Vor jedem Umzug oder jeder neuen Integration lohnt sich eine kurze Prüfung:

• Cookie-Domain-Attribut kontrollieren: Ist es auf die Root-Domain gesetzt oder nur auf den einzelnen Host?
• Prüfen, ob das Analytics-Tool Subdomains derselben Domain als eine Website misst, und Cross-Domain-Messung einrichten, sobald eine fremde Domain beteiligt ist
• Checkout- oder Formular-Funnel testen: Bleibt die Sitzungs-ID über den Hostwechsel hinweg erhalten?
• Nach jedem größeren Plattform-Update erneut prüfen, ob die Konfiguration noch greift

Wartung und Technik: wer diesen Teil der Website betreibt

Eine Subdomain ist operativ ein eigenständiges Projekt. Sie kann auf einem komplett anderen Server, mit einem anderen CMS, einer anderen Deployment-Pipeline und einem eigenen SSL-Zertifikat laufen, ohne die Hauptseite in irgendeiner Form zu berühren. Genau deshalb bieten Helpdesk-Software, Dokumentations-Plattformen und viele Shop-Systeme eine Subdomain per CNAME-Eintrag als Standardintegration an: Das lässt sich in wenigen Minuten einrichten, ganz ohne Zugriff auf den Code oder die Infrastruktur der Hauptseite.

Dasselbe Tool unter einem Unterverzeichnis zu betreiben, ist möglich, aber nicht kostenlos: Es braucht einen Reverse Proxy, eine Konfiguration im Webserver oder ein Edge-Skript, das Anfragen an beispiel.de/hilfe abfängt und an die Server des Drittanbieters weiterleitet, während Antwort-Header und interne Pfade passend umgeschrieben werden. Das funktioniert zuverlässig, solange jemand diese Konfiguration aktiv pflegt: Ändert der Anbieter seine internen Pfade oder Asset-URLs, muss die Proxy-Regel mitziehen, sonst brechen Bilder, Stylesheets oder ganze Unterseiten, oft ohne sofortige Fehlermeldung.

Diese Abwägung ist auch eine Frage der Teamstruktur. Eine Subdomain erlaubt es einem Support-Team oder einer Entwicklerabteilung, ihren Teil der Website unabhängig von der Marketing-Pipeline zu deployen, ohne Merge-Konflikte, ohne gemeinsame Freigabeprozesse und ohne Abstimmung über Release-Zeitpunkte. Ein Unterverzeichnis zwingt alle Bereiche auf eine gemeinsame Infrastruktur, was Koordination kostet, aber dafür nur ein Zertifikat, eine robots.txt und einen Satz Security-Header zu pflegen übrig lässt, statt mehrerer paralleler Konfigurationen, die mit der Zeit auseinanderlaufen können.

Bei der Wahl eines Drittanbieter-Tools lohnt sich deshalb ein Blick in dessen Dokumentation, bevor eine Entscheidung getroffen wird: Manche Plattformen unterstützen einen Pfad-basierten Betrieb offiziell und liefern eine fertige Proxy-Konfiguration mit, andere setzen eine eigene Subdomain zwingend voraus und lassen keinen anderen Betrieb zu.

Auch Sicherheits-Header wie Content-Security-Policy oder HSTS werden pro Host ausgeliefert, nicht pro Marke. Eine zusätzliche Subdomain bedeutet also einen zusätzlichen Satz an Header-Regeln, der gepflegt und bei jedem Sicherheitsaudit einzeln geprüft werden muss. Wer mehrere Subdomains betreibt, verliert leicht den Überblick, welche Konfiguration wo aktuell ist, gerade wenn verschiedene Teams für verschiedene Hosts verantwortlich sind und Änderungen nicht zentral dokumentiert werden.

Die Entscheidung nach Anwendungsfall: Blog, Shop und Hilfe-Center

Für den Blog ist der Fall am klarsten: Er existiert, um Themenautorität aufzubauen und Links einzusammeln, die in Umsatz übersetzt werden sollen. Beides funktioniert am direktesten, wenn der Blog im Unterverzeichnis der Domain liegt, die auch verkauft. Wenn in einem Projekt nur eine dieser drei Entscheidungen bewusst getroffen werden kann, ist es diese.

Beim Shop ist die Lage differenzierter. Läuft das Bezahlsystem auf einer technisch komplett getrennten Plattform, etwa aus Gründen der PCI-Compliance oder weil eine Headless-Commerce-Lösung eingesetzt wird, die nicht nativ unter einem Pfad läuft, kann eine Subdomain den sensiblen Checkout-Teil sauber isolieren. Der Nachteil: Produkt- und Kategorieseiten, die eigentlich für informationsnahe Suchanfragen ranken könnten, verlieren den direkten Autoritätsanschluss an die Hauptseite. Viele moderne Headless-Setups lösen das, indem die Produktseiten selbst im Unterverzeichnis liegen und nur der eigentliche Bezahlvorgang kurz auf eine gesicherte Subdomain wechselt, sodass der ranking-relevante Teil auf dem Haupthost bleibt.

Ein Hilfe-Center ist meist der unkritischste Fall für eine Subdomain, weil Supportartikel selten mit denselben kommerziellen Suchbegriffen konkurrieren wie Blog oder Shop, und der praktische Vorteil einer vorkonfigurierten Helpdesk-Integration meist schwerer wiegt als der SEO-Nachteil. Die Ausnahme: Wenn einzelne Hilfeartikel tatsächlich für kommerziell relevante Anfragen ranken, etwa Vergleichs- oder Kündigungsseiten, lohnt es sich, gezielt diese einzelnen Seiten ins Unterverzeichnis zu holen, statt das komplette Hilfe-Center umzuziehen. Ein hybrides Modell, in dem die Mehrheit der Artikel auf der Subdomain bleibt und nur eine Handvoll kommerziell relevanter Seiten dupliziert oder verschoben wird, ist in der Praxis oft der pragmatischste Kompromiss.

Migration: von Subdomain zu Unterverzeichnis wechseln

Der Wechsel ist technisch eine vollständige URL-Migration, kein einfaches Umschreiben von Links. Vor dem Umzug braucht es eine vollständige Liste aller indexierten URLs der Subdomain und eine eindeutige Zuordnung zu ihrer künftigen Adresse im Unterverzeichnis. Jede alte URL bekommt eine 301-Weiterleitung auf ihr neues Ziel, nicht pauschal auf die neue Startseite, sondern konkret auf die inhaltlich passende Seite.

Interne Links sollten spätestens beim Go-Live direkt auf die neuen Adressen zeigen, statt sich allein auf die Weiterleitungen zu verlassen: Jede Weiterleitung kostet ein wenig Signalklarheit, und bei tausenden internen Links summiert sich dieser Effekt. Parallel dazu müssen XML-Sitemap, Canonical-Tags und die robots.txt beider Hosts aktualisiert werden, und die alte Search-Console-Property sollte trotz Umzug aktiv bleiben, denn dort lässt sich noch über Wochen verfolgen, wie Google die Weiterleitungen verarbeitet.

Wichtige Schritte vor dem Go-Live:

• Vollständiges URL-Inventar der Subdomain erstellen, inklusive selten besuchter Altseiten
• 301-Weiterleitungen einzeln auf die inhaltlich passende neue URL setzen, nicht pauschal auf die Startseite
• Interne Links im gesamten System direkt auf die neuen Adressen umstellen
• Beide Search-Console-Properties nach dem Umzug parallel weiter beobachten

Wann eine Subdomain trotzdem die richtige Wahl bleibt

Ein Umzug sollte in einem Schritt erfolgen, nicht inhaltsweise über Wochen verteilt: Laufen alte und neue Version parallel und sind beide indexierbar, entsteht ein Duplicate-Content-Fenster, in dem die Suchmaschine selbst entscheiden muss, welche Version die relevante ist. Nach einem korrekt ausgeführten Umzug ist eine vorübergehende Ranking-Schwankung normal; erfahrungsgemäß erholen sich die Seiten mit der bisher stärksten Autorität zuerst, während frisch veröffentlichte oder schwach verlinkte Seiten länger brauchen, um ihren alten Stand wieder zu erreichen. Das heißt aber nicht, dass eine Subdomain grundsätzlich die falsche Wahl ist. Ein eingeloggter Anwendungsbereich, etwa app.beispiel.de als das eigentliche Produkt hinter einem Login, muss in aller Regel gar nicht ranken, weil er ohnehin nicht öffentlich crawlbar ist. Hier kostet eine Subdomain nichts, weil es keine Autorität gibt, die verloren gehen könnte.

Ähnlich verhält es sich mit einer Staging- oder Sandbox-Umgebung, die absichtlich von der Suche ausgeschlossen bleibt, oder mit einem internen Portal, das nur für Mitarbeiter zugänglich ist und ohnehin per robots.txt und Zugriffsschutz gesperrt wird. In all diesen Fällen ist die entscheidende Frage nicht Subdomain gegen Unterverzeichnis, sondern ob der Bereich überhaupt öffentlich indexiert werden soll, und wenn nicht, verliert die ganze Debatte um Autorität und Ranking ihre Grundlage, während Tracking und Wartung trotzdem eigene Überlegungen bleiben.

Am Ende lohnt sich deshalb, jede der drei Fragen einzeln zu stellen: Soll dieser Bereich in Suchmaschinen ranken? Muss ein Nutzer nahtlos zwischen ihm und der Hauptseite wechseln können? Und wer wird ihn technisch betreiben? Aus den Antworten ergibt sich die Struktur fast von selbst, statt aus der Standardeinstellung eines Tools übernommen zu werden.