Subdomains oder Unterordner? Wie ich ein Dutzend Websites neu geordnet habe

Jahrelang habe ich jedem Projekt seine eigene Subdomain gegeben: quiz.portale3d.it, varco.portale3d.it, intercity.portale3d.it und so weiter. Das ist die natürlichste Wahl, wenn ein Projekt entsteht: neuer Ordner, neue Adresse, kein Konflikt mit dem Rest. Dann hat mir eines Tages das Hosting-Panel mitgeteilt, dass meine Plätze für Subdomains aufgebraucht sind. Ich musste mich entscheiden: einen größeren Tarif kaufen oder die Struktur ändern.

Ich habe die Struktur geändert. In diesem Guide erkläre ich dir die Überlegungen und die praktischen Schritte, damit du sie auf deine eigenen Websites übertragen kannst.

Das Dilemma in Kürze

Die zwei Wege sind:

• Subdomains: projekt.meineseite.de, jede fast wie eine eigene Website behandelt;
• Unterordner: meineseite.de/projekt/, alles unter derselben Domain.

Technisch funktionieren beide. Der Unterschied liegt in drei Bereichen: wie Google sie sieht, wie du das Login der Nutzer handhabst und wie viel Aufwand ihre Pflege kostet.

SEO: Was sich wirklich ändert

Google hat mehrfach betont, dass es Subdomains und Unterordner gleichermaßen gut verarbeitet. In der Praxis wird eine Subdomain aber oft als eigene Property behandelt: Links auf quiz.meineseite.de helfen der Hauptdomain weniger, und umgekehrt.

Für eine persönliche Website mit vielen kleinen Projekten zählt das. Keines meiner Spiele hatte genug Links, um allein zu bestehen; unter einer gemeinsamen Domain stärken sie sich dagegen gegenseitig.

Bevor ich mich entschieden habe, habe ich mir die echten Daten angesehen: die Besucherstatistik und die Google Search Console. Der organische Traffic auf die alten Subdomains war nahezu null. Deshalb musste ich mir keine Gedanken um Weiterleitungen von jeder alten Adresse machen: Es reichte, die internen Links zu aktualisieren und auf jeder Seite die richtige kanonische URL anzugeben.

Prüfe vor dem Umbau die Daten. Bekommt eine alte Adresse Traffic von Google oder über externe Links, braucht sie eine 301-Weiterleitung. Wenn nicht, kannst du dir die Mühe sparen.

Die Struktur, die ich gewählt habe

Ich habe alles nach Art des Inhalts in drei Gruppen aufgeteilt:

Die Spiele sind die einzige Ausnahme: Sie behalten eine Subdomain, aber nur eine für alle. Sie haben andere Anforderungen (getrennte Sessions, gemeinsame Bestenlisten, großzügigere Sicherheits-Header für iframes), und unter einer gemeinsamen Adresse bilden sie trotzdem eine stimmige Website.

Ein Login für alles

Der konkreteste Vorteil von Unterordnern ist nicht SEO, sondern das Login. Mit einer Subdomain pro Projekt hatte jedes sein eigenes Anmeldesystem, seine eigene Nutzertabelle, sein eigenes Cookie. Unter derselben Domain gilt ein Session-Cookie dagegen für alle Ordner.

Ich habe eine kleine gemeinsame Bibliothek geschrieben, die drei Dinge tut: Sie startet die Session, liest den Nutzer aus einer zentralen Tabelle und zeigt überall dasselbe Menü. Jede App bindet sie mit einer Zeile ein:

require_once $_SERVER['DOCUMENT_ROOT'] . '/core/auth.php';
$nutzer = p3d_user();   // angemeldeter Nutzer oder null

Die alten Apps habe ich nicht neu geschrieben. Jede prüft, ob die gemeinsame Bibliothek vorhanden ist: Wenn ja, nutzt sie sie, sonst macht sie mit ihrem bisherigen Login weiter. So verlief der Umstieg schrittweise, ein Projekt nach dem anderen.

Aber Vorsicht: Gleicher Ursprung heißt auch gleiche Risiken. Wenn alle Apps auf meineseite.de laufen, kann eine Schwachstelle in einer App auch die anderen treffen. Deshalb werden die Regeln strenger: HttpOnly- und Secure-Cookies, CSRF-Token in Formularen, keine Zugriffstoken im localStorage und localStorage-Schlüssel immer mit einem Präfix pro App.

Verschieben ohne Kopieren: symbolische Links

Viele Apps lagen in Ordnern außerhalb der Hauptseite, mit eigener Konfiguration. Sie physisch zu verschieben hieß, kaputte Pfade und Berechtigungen zu riskieren. Auf einem Shared Hosting, das sie unterstützt, ist die Lösung ein symbolischer Link: Der Ordner bleibt, wo er ist, und die Hauptseite „sieht“ ihn unter einer neuen Adresse.

Ein Detail sollte man kennen: Innerhalb der App liefert PHP mit __DIR__ den echten Pfad, nicht den des Links. Braucht die App Dateien der Hauptseite, muss sie über das Wurzelverzeichnis der Website gehen ($_SERVER['DOCUMENT_ROOT']) und nicht über Pfade relativ zum eigenen Ordner.

Der versteckte Feind: absolute Pfade

Eine App, die auf einer Subdomain entstanden ist, geht davon aus, im Wurzelverzeichnis zu liegen. Im Code findest du überall Dinge wie /assets/style.css oder fetch('/api/speichern.php'). In einen Unterordner wie /varco/ verschoben, zeigt dieser führende Schrägstrich auf die Wurzel der Domain, also an die falsche Stelle.

Bei der Migration des Kartenspiels Varco habe ich über neunzig solcher Verweise gefunden, verteilt auf PHP-Seiten, JavaScript und CSS. Und nicht nur im Code: auch in der Datenbank, in der jede Karte den Pfad ihres Bildes mit führendem Schrägstrich gespeichert hatte.

Die Regel, die funktioniert: überall relative Pfade. Entferne den führenden Schrägstrich und lass den Browser die Adresse relativ zur Seite auflösen. Denk daran, dass Pfade im CSS relativ zur .css-Datei sind, nicht zur Seite. Bevor du Daten in der Datenbank änderst, sichere immer zuerst die Tabelle.

Die Checkliste, die ich wieder verwenden würde

1. Sieh dir die Traffic-Daten an und entscheide, welche alten Adressen eine Weiterleitung verdienen.
2. Lege die Ordnerstruktur fest, bevor du irgendetwas verschiebst.
3. Baue die gemeinsame Bibliothek (Login, Menü) und führe sie allein zusammen, vor den Apps.
4. Migriere ein Projekt nach dem anderen und prüfe es im Browser: Seiten, API-Aufrufe, Bilder, eine Konsole ohne Fehler.
5. Suche nach absoluten Pfaden im Code und in der Datenbank.
6. Aktualisiere die kanonische URL jeder Seite und die internen Links.
7. Entferne die alten Subdomains erst, wenn die neue Adresse ein paar Tage lang funktioniert hat.

Fazit

Unterordner sind keine Zauberei, aber für eine persönliche Website mit vielen kleinen Projekten haben sie auf ganzer Linie gewonnen: eine Domain, die wächst, ein Login, das gepflegt werden muss, ein Menü, das alles verbindet. Und der aufgebrauchte Platz beim Hosting war am Ende die Gelegenheit, aufzuräumen.

Veröffentlicht am 7. Oktober 2026.