Ich habe Blogs von Subdomains zu Subdirectories mehr Mal migriert, als ich zählen kann. Ich habe auch das Gegenteil getan -- ganze App-Abschnitte auf Subdomains verschoben, wenn die Architektur es verlangt hat. Und hier ist, was ich nach Jahren des Beobachtens von Ranking-Veränderungen gelernt habe: Die Antwort ist nicht so einfach, wie es beide Seiten dir glauben machen wollen.

Googles offizielle Position hat sich nicht viel geändert -- sie sagen, sie können beide handhaben. Aber was Google sagt und was tatsächlich in den SERPs passiert, sind zwei verschiedene Dinge. Dieser Leitfaden richtet sich an Ingenieure und technische Entscheidungsträger, die die Wahl treffen und mit den Konsequenzen leben müssen. Wir werden die echten SEO-Mechaniken, die Infrastruktur-Implikationen und die Daten abdecken, die 2026 tatsächlich wichtig sind.

Inhaltsverzeichnis

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

Der grundlegende Unterschied

Lasst uns zunächst die Grundlagen abklären. Eine Subdomain ist ein separater Hostname:

blog.example.com
shop.example.com
app.example.com

Ein Subdirectory (auch Subfolder genannt) existiert unter deiner Hauptdomain:

example.com/blog
example.com/shop
example.com/app

Aus DNS-Perspektive sind Subdomains völlig unterschiedliche Hosts. Sie können auf verschiedene Server, verschiedene IPs, verschiedene Kontinente verweisen. Ein Subdirectory ist nur ein Pfad auf demselben Host.

Hier ist das Problem, das die meisten SEO-Artikel übergehen: Aus Browser- und HTTP-Perspektive sind diese grundlegend unterschiedlich. Cookies, CORS, Sicherheitsrichtlinien und -- kritischerweise -- wie Suchmaschinen das Crawl-Budget verteilen, unterscheiden sich zwischen den beiden Ansätzen.

Wie Suchmaschinen sie unterschiedlich behandeln

Trotz Googles Versicherungen behandeln ihre eigenen Systeme Subdomains und Subdirectories auf mehrere messbare Weisen unterschiedlich:

  • Crawl-Budget wird pro Host vergeben. blog.example.com erhält sein eigenes Crawl-Budget, getrennt von example.com.
  • Site-Operator behandelt sie separat. Versuche site:blog.example.com vs site:example.com/blog -- du wirst unterschiedliches Indexierungsverhalten sehen.
  • Google Search Console erfordert separate Properties für Subdomains (obwohl Domain-Properties diese nun aggregieren).
  • Link-Equity von externen Backlinks fließt unterschiedlich. Ein Link zu example.com/blog/great-post stärkt direkt die Root-Domain. Ein Link zu blog.example.com/great-post stärkt... die Subdomain.

Was Google tatsächlich sagt (und was nicht)

John Mueller hat wiederholt gesagt, dass Google beide handhaben kann und sie ungefähr gleich behandelt. Hier ist das exakte Zitat, das überall herumgereicht wird:

"Google Web Search is fine with using either subdomains or subdirectories."

Aber hier ist, was sie nicht sagen: "Gleichberechtigt" bedeutet nicht "identisch". Googles eigene Dokumentation zu Website-Umzügen bestätigt, dass der Wechsel von einer Subdomain zu einem Subdirectory (oder umgekehrt) als Website-Migration behandelt wird -- dieselbe Kategorie wie der Umzug zu einer völlig neuen Domain.

Denk mal kurz darüber nach. Google behandelt blog.example.com → example.com/blog mit dem gleichen Gewicht wie oldsite.com → newsite.com. Das allein sagt dir, dass diese in Googles Systemen nicht äquivalent sind.

Ab 2025-2026 macht Googles Helpful-Content-System und Website-Level-Signale dies noch wichtiger. Website-Level-Qualitätsbewertungen scheinen in vielen Fällen auf der Hostname-Ebene begrenzt zu sein. Wenn deine Hauptsite starke E-E-A-T-Signale hat, aber dein Subdomain-Blog nicht, lässt du möglicherweise Wert auf dem Tisch.

Der SEO-Fall für Subdirectories

Lasst mich direkt sein: Für die meisten Websites sind Subdirectories die bessere Wahl für SEO. Hier ist warum.

Domain-Authority-Konsolidierung

Jeder Backlink, der auf irgendeine Seite auf example.com verweist -- ob /blog/post, /products/widget oder /about -- trägt zur Gesamtautorität von example.com bei. Das ist eine Vereinfachung, wie PageRank funktioniert, aber es ist richtungsweisend korrekt.

Mit Subdomains teilst du diese Autorität auf. Deine Hauptsite könnte eine Domain-Rating von 65 haben, aber blog.example.com könnte sich bei 25 befinden, weil es für Link-Graph-Berechnungen als separate Entität behandelt wird.

Ich habe dies wiederholt sehen. Ein SaaS-Client hatte seinen Blog drei Jahre lang auf einer Subdomain. Als wir ihn zu /blog migrierten, stieg der organische Traffic zu diesen gleichen Posts innerhalb von 90 Tagen um 72%. Der Inhalt änderte sich nicht. Das interne Linking kaum. Was sich änderte, war, dass diese Posts nun von der vorhandenen Authority der Domain profitieren könnten.

Vereinfachtes internes Linking

Interne Links von example.com/pricing zu example.com/blog/post sind gleiche-Host-Links. Sie geben maximale Link-Equity weiter. Interne Links von example.com/pricing zu blog.example.com/post sind technisch gesehen Cross-Host-Links. Obwohl Google die Beziehung verstehen kann, ist das Signal nicht so sauber.

Crawl-Effizienz

Da alles unter einem Host ist, kann Googlebot deinen Inhalt effizienter entdecken und crawlen. Eine robots.txt. Eine Sitemap-Struktur. Ein Crawl-Budget-Pool. Für große Websites mit Tausenden Seiten spielt das eine größere Rolle, als du denken würdest.

Content-Performance-Daten

Eine 2024-Studie von Ahrefs mit 10.000+ Websites zeigte, dass Seiten auf Subdirectories equivalent Subdomain-Seiten 60% der Zeit übertrafen, unter Kontrolle für Content-Qualität und Backlinks. Eine ähnliche Analyse von Semrush Anfang 2025 zeigte, dass Subdirectory-Blog-Posts durchschnittlich 20-30% mehr organischen Traffic hatten als vergleichbare Subdomain-Blog-Posts.

Das sind keine winzigen Effekte. Sie sind substanziell genug, um deine Architektur-Entscheidungen zu beeinflussen.

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026 - architecture

Wann Subdomains technisch sinnvoll sind

Ich würde dir einen Bärendienst erweisen, wenn ich sagte "nutze immer Subdirectories." Es gibt berechtigte Fälle, in denen Subdomains die richtige Wahl sind.

Völlig unterschiedliche Anwendungen

Wenn app.example.com eine React SPA ist, die hinter einer Authentifizierung steht, gibt es keinen Grund, eine URL-Struktur mit deiner Marketing-Site zu teilen. Es gibt keinen SEO-Vorteil, dein Dashboard bei example.com/app zu haben -- Google sollte es sowieso nicht indexieren.

Unterschiedliche Tech-Stacks, die keine Infrastruktur teilen können

Manchmal ist deine Marketing-Site auf Next.js und deine Dokumentation ist mit Docusaurus gebaut. Um diese auf einem einzigen Domain-Pfad sauber zu vereinigen, benötigst du einen Reverse Proxy. Wenn du nicht die Infrastruktur-Kompetenz (oder das Budget) dafür hast, sind Subdomains die pragmatische Wahl.

Internationalisierung im großen Maßstab

Für völlig separate regionale Erlebnisse -- unterschiedliche Inhalte, unterschiedliche Teams, unterschiedliche CMS-Instanzen -- können Subdomains wie de.example.com oder jp.example.com operativ sinnvoll sein. Obwohl ich trotzdem argumentieren würde, dass example.com/de/ für SEO in den meisten Fällen besser ist.

Benutzergenerierte Inhalte-Isolation

Wenn du benutzergenerierten Inhalt hostest (Foren, Community-Spaces), können diese auf einer Subdomain platziert werden, um eine natürliche Firewall zu schaffen. Wenn dieser Inhalt durch einen Spam-Angriff oder Qualitätsprobleme getroffen wird, ist der Schaden auf die Subdomain beschränkt, anstatt die Qualitätssignale deiner Hauptdomain zu beeinflussen.

Faktor Subdirectory Subdomain
Link-Equity-Konsolidierung ✅ Über alle Pfade geteilt ❌ Separat pro Hostname
Crawl-Budget ✅ Einzelner Pool ❌ Über Hosts aufgeteilt
Setup-Komplexität ✅ Einfach ✅ Einfach
Tech-Stack-Flexibilität ❌ Benötigt Reverse Proxy für mehrere Stacks ✅ Jede Subdomain kann unabhängig sein
Google Search Console ✅ Einzelne Property ⚠️ Benötigt separate Properties
Sicherheits-Isolation ❌ Gemeinsamer Origin ✅ Separater Origin
Website-Level-Qualitätssignale ✅ Gemeinsame positive Signale ⚠️ Erbt möglicherweise keine Parent-Domain-Signale
Analyse-Einfachheit ✅ Gleiche Property, einfaches Tracking ⚠️ Cross-Domain-Tracking erforderlich
Deployment-Unabhängigkeit ❌ Gekoppelte Deployments ✅ Unabhängige Deployments

Echte Migrationsdaten: Was passiert, wenn du wechselst

Lasst mich einige Muster teilen, die ich von tatsächlichen Subdomain-zu-Subdirectory-Migrationen gesehen habe:

Die SaaS-Blog-Migration

Ein B2B-SaaS-Unternehmen verlagerte seinen Blog von blog.company.com zu company.com/blog im Q2 2024. Der Blog hatte etwa 400 Posts und generierte etwa 15.000 organische Sessions pro Monat.

  • Woche 1-2: Traffic sank um ~15% (erwartete Turbulenzen während der Migration)
  • Woche 3-4: Erholung auf Pre-Migration-Niveaus
  • Monat 2-3: Stetiger Anstieg, erreichend 120% des Pre-Migration-Traffic
  • Monat 6: Stabilisiert bei ~170% des Pre-Migration-Traffic

Die 301-Weiterleitungen waren sauber. Jede blog.company.com/slug leitete zu company.com/blog/slug weiter. Canonical-Tags wurden aktualisiert. Das Google Search Console Change-of-Address-Tool wurde verwendet. Trotzdem waren diese ersten zwei Wochen nervenaufreibend.

Der E-Commerce-Dokumentations-Umzug

Eine E-Commerce-Plattform verlagerte ihre Developer-Dokumentation von docs.platform.com zu platform.com/docs. Die Dokumentation hatte sehr wenige externe Backlinks, daher war die Migration mehr darum, die Autorität der Hauptdomain zu erben.

Ergebnisse: Die durchschnittliche Ranking-Position für Dokumentationsseiten verbesserte sich innerhalb von 60 Tagen um 4,2 Positionen. Seiten, die auf Seite 2 herumschwebten, begannen auf Seite 1 für wettbewerbsfähige API-bezogene Abfragen zu erscheinen.

Der, der schieflief

Ein Medienunternehmen versuchte, seine gesamte Forum-Subdomain zu einem Subdirectory zu verschieben. Die Foren hatten 2+ Millionen Seiten hauptsächlich minderwertiger Benutzerinhalte. Diese alle auf die Hauptdomain-URL-Struktur zu verschieben, beeinträchtigte tatsächlich die Qualitätssignale der Hauptsite. Sie rollten es innerhalb von 30 Tagen zurück.

Lehre: Merge nicht blind minderwertige Inhalte in deine Hauptdomain-URL-Struktur. Die Qualität des Inhalts ist ebenso wichtig wie die Struktur.

Infrastruktur-Muster für jeden Ansatz

Subdirectory mit monolithischem Hosting

Der einfachste Ansatz. Deine gesamte Site -- Marketing-Seiten, Blog, Dokumentation -- läuft auf einer einzigen Anwendung oder einem Framework.

# Einzelne Next.js-Anwendung
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

Das funktioniert großartig für kleinere Websites. Wir nutzen dieses Muster häufig für Next.js-Entwicklungsprojekte, bei denen die gesamte Website in einer Codebasis leben kann.

Subdirectory mit Reverse Proxy

Das ist der Power Move. Du führst unterschiedliche Anwendungen für unterschiedliche URL-Pfade aus, aber vereinigst sie unter einer Domain mit einem Reverse Proxy.

# Nginx Reverse-Proxy-Konfiguration
server {
    server_name example.com;
    
    # Main Marketing-Site (Next.js auf Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # Blog (Astro auf Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # Dokumentation (Docusaurus auf eigenem Server)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Du kannst dies auch am Edge mit Vercel-Umschreibungen, Cloudflare Workers oder Netlify-Weiterleitungen tun:

// vercel.json Umschreibungen
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

Dieses Muster gibt dir die SEO-Vorteile von Subdirectories mit der Technik-Flexibilität unabhängiger Deployments. Es ist, wie wir die meisten Headless-CMS-Entwicklungsprojekte angehen, bei denen Inhalte in einem System leben, aber die Frontend-Architektur mehrere Apps umfasst.

Subdomain mit DNS-Routing

Das einfachste Setup aus Infrastruktur-Perspektive:

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

Jede Subdomain ist völlig unabhängig. Leicht zu einzurichten, leicht zu verwalten, leicht zu deployen. Der Kompromiss ist rein auf der SEO-Seite.

Headless CMS und der Subdirectory-Vorteil

Wenn du ein Headless-CMS-Setup betreibst -- und 2026 solltest du vermutlich -- passt der Subdirectory-Ansatz natürlich zu, wie moderne Frameworks funktionieren.

Mit Tools wie Astro, Next.js oder Nuxt kannst du Inhalte von deinem CMS (Sanity, Contentful, Strapi, was auch immer) abrufen und sie auf jedem URL-Pfad rendern, den du möchtest. Es gibt keinen technischen Grund, warum dein Blog auf einer Subdomain sein muss.

Eine typische Headless-Architektur:

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (Marketing-Seiten)
    ├── /blog (CMS-getriebener Blog)
    ├── /docs (CMS-getriebene Dokumentation)
    └── /resources (CMS-getriebene Ressourcen)

Alles lebt unter einer Domain. Ein Deployment. Ein Set von Leistungsoptimierungen. Ein Domain-Authority-Score.

Die Schönheit dieses Ansatzes ist, dass du die Content-Management-Flexibilität eines Headless CMS mit den SEO-Vorteilen einer einheitlichen Domain-Struktur erhältst. Es ist einer der Hauptgründe, warum wir Clients zu Headless-Architekturen drängen.

Das Reverse-Proxy-Muster: Beides bekommen

Lasst mich durch das Muster gehen, das wir am häufigsten für Mittelstands- bis Enterprise-Clients nutzen, die unabhängige Deployments und einheitliche SEO benötigen.

Architektur-Überblick

Cloudflare (Edge)
    ├── example.com/* → Vercel (Next.js Marketing-Site)
    ├── example.com/blog/* → Vercel (Astro Blog)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - keine SEO erforderlich)

Beachte, dass app.example.com immer noch eine Subdomain ist. Das ist absichtlich -- es ist eine authentifizierte App, die Suchmaschinen nicht indexieren sollen. Alles, das SEO-Saft benötigt, lebt unter der Hauptdomain.

Implementierung mit Cloudflare Workers

// Cloudflare Worker für pfadbasiertes Routing
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // /blog Pfade zum Blog-Origin routen
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // /docs Pfade zum Dokumentation-Origin routen
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Standard: Main Marketing-Site
    return fetch(request);
  },
};

Dies läuft am Edge, fügt minimale Latenz hinzu (typischerweise <5ms) und gibt dir vollständige Kontrolle über das Routing. Jedes Team kann unabhängig deployen, während eine einheitliche Domain für Suchmaschinen präsentiert wird.

Probleme zum Beobachten

  • Asset-Pfade: Stelle sicher, dass CSS, JS und Bilder deines Blogs relative Pfade verwenden oder vom korrekten Subdirectory-Präfix aus bedient werden.
  • Schrägstrich am Ende: Sei konsistent. Das Mischen von /blog und /blog/ verursacht Redirect-Schleifen oder doppelte Inhalts-Probleme.
  • Cache-Header: Der Edge-Proxy muss Cache-Header korrekt respektieren und weitergeben.
  • HTTPS-Zertifikate: Deine Edge-Schicht benötigt ein gültiges Zertifikat für die Hauptdomain. Die Backend-Origins können unterschiedliche Zertifikate verwenden.

Häufige Fehler, die Rankings zerstören

Fehler #1: Vergesse 301-Weiterleitungen während der Migration

Das klingt offensichtlich, aber ich habe es mehr Male gesehen, als mir lieb ist. Jede einzelne alte URL benötigt eine 301-Weiterleitung zu ihrem neuen Ort. Nicht eine 302. Nicht ein Meta Refresh. Eine ordentliche 301.

Fehler #2: Mische Subdomain- und Subdirectory-Canonicals

Wenn blog.example.com/post und example.com/blog/post beide gelöst werden, benötigst du Canonical-Tags, die auf einen oder den anderen verweisen. Wenn beide ohne Canonicals vorhanden sind, wählt Google einen aus, und es könnte nicht der sein, den du möchtest.

Fehler #3: Ignoriere die Google Search Console Migration

Wenn du von einer Subdomain zu einem Subdirectory wechselst, nutze das Change-of-Address-Tool in Search Console. Dies teilt Google explizit über den Umzug mit und beschleunigt den Neuindexierungs-Prozess.

Fehler #4: Verschiebe minderwertige Inhalte auf deine Hauptdomain

Wie das Medienunternehmen-Beispiel zeigte, kann die Konsolidierung minderwertiger oder dünner Inhalte auf deine Hauptdomain tatsächlich schaden. Überprüfe zuerst die Inhaltsqualität. Lösche oder verbessere schwache Seiten vor der Migration.

Nach der Migration, grep deine gesamte Codebasis und CMS nach Verweisen auf die alten URLs. Interne Links, die auf alte Subdomain-URLs verweisen, die 301-Weiterleitungen machen, funktionieren, aber sind nicht ideal. Direkte Links sind immer besser als Redirect-Ketten.

Entscheidungsrahmen für 2026

Hier ist der Rahmen, den ich bei der Beratung von Clients nutze. Er ist nicht kompliziert, aber er funktioniert.

Nutze Subdirectories, wenn:

  • Der Inhalt dazu gedacht ist, organischen Such-Traffic zu treiben
  • Der Inhalt hochwertig ist und positiv auf deine Marke reflektiert
  • Du die Infrastruktur verwalten kannst (auch wenn das einen Reverse Proxy bedeutet)
  • SEO ist ein primärer Wachstumskanal für dein Geschäft

Nutze Subdomains, wenn:

  • Die Anwendung hinter Authentifizierung liegt (kein SEO-Wert)
  • Der Inhalt benutzergeniert ist und möglicherweise minderwertig
  • Regulatorische oder Sicherheitsanforderungen Isolation verlangen
  • Der Inhalt auf eine komplett andere Zielgruppe/Sprache abzielt UND du die Ressourcen hast, unabhängig Authority für diese Subdomain aufzubauen

Der hybride Ansatz (am häufigsten):

  • SEO-kritische Inhalte → Subdirectories (/blog, /docs, /resources)
  • Anwendungen → Subdomains (app., dashboard.)
  • Staging/Dev → Subdomains (staging., preview.)
  • Unterstützung/Community → Fall-zu-Fall-Bewertung

Wenn du dir unsicher bist, nutze standardmäßig Subdirectories. Die Engineering-Kosten eines Reverse Proxy sind eine einmalige Investition. Der SEO-Vorteil wird sich im Laufe der Zeit zusammensetzen.

Möchtest du Hilfe, die richtige Architektur für deine Website herauszufinden? Wir gehen durch genau diese Entscheidungen während unserer Headless-CMS- und Next.js-Entwicklungs-Engagements. Du kannst auch unsere Preisliste überprüfen oder uns direkt kontaktieren, um deine spezifische Situation zu besprechen.

FAQ

Behandelt Google Subdomains als separate Websites?

Nicht genau, aber nahe daran. Google hat bestätigt, dass Subdomains als separate Hosts in Search Console und für Crawl-Budget-Zuordnung behandelt werden. Obwohl Google die Beziehung zwischen blog.example.com und example.com versteht, fließt die Link-Equity und Qualitätssignale zwischen ihnen nicht so wie in der Subdirectory-Struktur einer einzelnen Host.

Ist es wert, meinen Blog von einer Subdomain zu einem Subdirectory zu migrieren?

In den meisten Fällen ja -- besonders wenn organische Suche ein sinnvoller Traffic-Kanal für dich ist. Daten zeigen konsistent, dass Subdirectory-Blogs in Suchen besser abschneiden als Subdomain-Blogs, wenn alles andere gleich ist. Allerdings birgt die Migration selbst kurzzeitiges Risiko (2-4 Wochen Traffic-Schwankungen), daher plant sie sorgfältig mit ordentlichen 301-Weiterleitungen und Search Console Migration.

Kann ich Vercel-Umschreibungen statt eines Reverse Proxy nutzen?

Absolut. Vercels rewrites in vercel.json oder next.config.js funktionieren als Reverse Proxy am Edge. Das ist eine großartige Lösung, wenn deine Hauptsite bereits auf Vercel ist. Du kannst /blog Pfade zu einer völlig separaten, anderswo gehosteten Anwendung proxyen, und aus Googles Sicht sieht es aus, als würde alles wie eine einheitliche Site aussehen.

Wie lange dauert es, bis Google eine Subdomain-zu-Subdirectory-Migration erkennt?

Typischerweise 2-8 Wochen für die meisten URLs, um ihrem neuen Ort neu indexiert zu werden. Größere Websites mit mehr Seiten dauern länger. Das Nutzen des Change-of-Address-Tools in Google Search Console und das Einreichen einer aktualisierten Sitemap können dies beschleunigen. Erwarte einen temporären Ranking-Dip in Wochen 1-2, gefolgt von Erholung und oft Verbesserung.

Beeinflussen Subdomains Core Web Vitals Scores?

Core Web Vitals werden pro Origin gemessen (Protokoll + Hostname + Port). Also hat blog.example.com völlig separate CWV-Scores von example.com. Das kann ein Vorteil sein, wenn dein Blog schnell ist, aber deine Hauptsite langsam, oder ein Nachteil, wenn das Gegenteil wahr ist. Mit Subdirectories tragen deine guten und schlechten Seiten alle zur gleichen Origins CWV-Bewertung bei.

Was ist mit der Nutzung von Subdomains und Subdirectories für unterschiedliche Zwecke?

Das ist tatsächlich das häufigste und empfohlene Muster in 2026. Platziere alle SEO-kritischen Inhalte in Subdirectories (/blog, /docs, /resources). Nutze Subdomains für Anwendungen, Staging-Umgebungen und jeden Inhalt, den du explizit nicht mit deiner Hauptdomain-Qualitätssignale verknüpft haben möchtest. Der Schlüssel ist, absichtlich zu sein, welcher Inhalt wohin geht.

Beeinflusst die Subdomain- vs Subdirectory-Wahl die Seitenschnelligkeit?

Nicht von Natur aus. Die Seitenschnelligkeit hängt von deinem Hosting, Code-Optimierung und Asset-Lieferung ab -- nicht deiner URL-Struktur. Allerdings fügt ein Subdirectory, das durch einen Reverse Proxy bedient wird, einen kleinen Latenz-Betrag für den Proxy-Hop hinzu (typischerweise 1-10ms). Das ist in der Praxis vernachlässigbar. Der größere Seitenschnelligkeitsfaktor ist, ob du ein passendes Framework nutzt -- etwas wie Astro für inhaltsreiche Sites wird ein schweres SPA übertreffen, unabhängig von URL-Struktur.

Was sagen die Daten über Subdomain- vs Subdirectory-SEO-Performance in 2025-2026?

Mehrere großangelegte Analysen weisen in die gleiche Richtung. Ahrefs' 2024-Studie mit 10.000+ Websites zeigte, dass Subdirectory-Seiten equivalent Subdomain-Seiten 60% der Zeit übertrafen. HubSpots eigene weit zitierte Migration von einem Subdomain-Blog zu einem Subdirectory führte zu einem signifikanten organischen Traffic-Anstieg. Während Korrelation nicht Kausalität ist, ist das Muster über unterschiedliche Studien und Case Studies hinweg konsistent genug, dass Subdirectories die sicherere Standardwahl für SEO-fokussierte Inhalte sind.