Was ist das `www`- und `public_html`-Verzeichnis in Ihrem Hosting-Account?

Das `public_html` Verzeichnis ist das Document Root Ihrer Website — der serverseitige Ordner, aus dem Ihr Webserver (Apache, Nginx, LiteSpeed) alle öffentlich zugänglichen Dateien liest und bereitstellt, wenn ein Besucher Ihre Domain aufruft. Das `www` Verzeichnis ist in den meisten Shared- und cPanel-basierten Umgebungen lediglich ein symbolischer Link (Symlink), der auf `public_html` zeigt und aus Gründen der historischen Kompatibilität existiert, nicht als eigenständiger Speicherort.

Das Verständnis dieses Unterschieds ist nicht nur kosmetischer Natur. Das Fehlplatzieren von Dateien außerhalb von `public_html`, eine fehlerhafte Konfiguration des Document Root oder ein Missverständnis der Symlink-Beziehung kann zu fehlgeschlagenen Deployments, 403 Forbidden-Fehlern oder der unbeabsichtigten öffentlichen Exposition sensibler Konfigurationsdateien führen.

Die Rolle von `public_html` als Document Root

Wenn eine HTTP-Anfrage Ihren Server erreicht, konsultiert der Webserver-Daemon seine Konfiguration, um zu bestimmen, welches Verzeichnis der angeforderten Domain zugeordnet ist. Dieses Verzeichnis wird als Document Root bezeichnet. In praktisch allen Shared-Hosting-Umgebungen und den meisten VPS Hosting-Konfigurationen, die cPanel oder ähnliche Kontrollpanels verwenden, ist dieses Document Root `public_html`.

Der absolute Pfad auf einem typischen cPanel-Server sieht folgendermaßen aus:

“`

/home/username/public_html/

“`

Jede Datei, die in diesem Verzeichnis abgelegt wird, ist über Ihre Domain öffentlich erreichbar. Die Zuordnung ist direkt:

Die letzte Zeile ist entscheidend. Dateien, die oberhalb von `public_html` im Verzeichnisbaum abgelegt werden — direkt in `/home/username/` — sind für den Webserver unsichtbar und können nicht per HTTP abgerufen werden. Dies ist der richtige Speicherort für sensible Dateien wie Datenbankzugangsdaten, `.env`-Dateien und API-Schlüssel, die Ihre Anwendung zur Laufzeit liest, aber niemals öffentlich bereitgestellt werden dürfen.

Standard-Indexdateien und Verzeichnisauflösung

Wenn ein Besucher eine Verzeichnis-URL aufruft (z. B. `https://example.com/`), sucht der Webserver in diesem Verzeichnis nach einer Standard-Indexdatei. Die übliche Auflösungsreihenfolge in der `DirectoryIndex`-Direktive von Apache ist typischerweise:

“`

index.html > index.htm > index.php > index.cgi

“`

Wenn keine dieser Dateien vorhanden ist und das Verzeichnis-Listing nicht explizit deaktiviert wurde, gibt der Server möglicherweise einen 403 Forbidden-Fehler zurück oder zeigt ein Verzeichnis-Listing an — ein erhebliches Sicherheitsrisiko. Stellen Sie immer sicher, dass entweder eine gültige Indexdatei vorhanden ist oder `Options -Indexes` in Ihrer `.htaccess` gesetzt ist.

Was das `www`-Verzeichnis tatsächlich ist

Das `www`-Verzeichnis ist ein POSIX-Symlink, kein echtes Verzeichnis mit eigenem Inode und eigener Speicherzuweisung. Sie können dies auf jedem Linux-basierten Server überprüfen:

“`bash

ls -la ~/

“`

Die Ausgabe zeigt etwas wie:

“`

lrwxrwxrwx 1 user user 10 Jan 15 09:22 www -> public_html

drwxr-xr-x 12 user user 4096 Jan 15 09:22 public_html

“`

Das `l` am Anfang der Berechtigungszeichenkette und der `-> public_html`-Pfeil bestätigen, dass es sich um einen Symlink handelt. Das bedeutet:

• `www` und `public_html` teilen exakt dieselben Inode-Daten
• Eine Datei in `~/www/contact.html` zu schreiben ist identisch damit, sie in `~/public_html/contact.html` zu schreiben
• Das Löschen von `www` löscht nicht `public_html` oder dessen Inhalte
• Den Symlink neu zu erstellen ist trivial: `ln -s ~/public_html ~/www`

Warum der `www`-Symlink existiert

Der `www`-Symlink ist ein Legacy-Artefakt mit praktischen Wurzeln. In frühen Unix-basierten Hosting-Umgebungen war es Konvention, Webinhalte in einem Verzeichnis namens `www` zu speichern — in Anlehnung an das `www.`-Subdomain-Präfix, das in den 1990er Jahren allgegenwärtig wurde. Als cPanel `public_html` als Document-Root-Namen standardisierte, wurde der `www`-Symlink beibehalten, um Folgendes nicht zu beschädigen:

• Ältere Deployment-Skripte, die fest auf `~/www/` kodiert waren
• FTP-Clients und Dateimanager, die einen `www`-Ordner erwarteten
• Dokumentationen und Tutorials, die `www` als Upload-Ziel referenzierten

Für alle praktischen Zwecke in einer modernen Umgebung sollten Sie `public_html` als kanonischen Speicherort behandeln und `www` vollständig ignorieren.

`public_html` vs `www`: Direkter Vergleich

Verzeichnisstruktur innerhalb von `public_html`

Ein gut organisiertes `public_html`-Verzeichnis trennt Zuständigkeiten klar. Hier ist eine produktionsnahe Struktur für eine PHP-basierte Website oder WordPress-Installation:

“`

public_html/

├── index.php

├── .htaccess

├── wp-config.php ← WordPress config (ideally moved one level up)

├── wp-content/

│ ├── themes/

│ ├── plugins/

│ └── uploads/

├── assets/

│ ├── css/

│ ├── js/

│ └── images/

└── sitemap.xml

“`

Kritischer Sicherheitshinweis: `wp-config.php` enthält Datenbankzugangsdaten. WordPress unterstützt das Ablegen dieser Datei ein Verzeichnis oberhalb von `public_html` (`/home/username/wp-config.php`), wo sie per HTTP nicht erreichbar, aber von PHP noch lesbar ist. Dies ist eine Härtungs-Best-Practice, die viele Administratoren übersehen.

Wie Subdomains und Add-on-Domains diese Struktur erweitern

Wenn Sie eine Subdomain oder Add-on-Domain über VPS Control Panels oder cPanel erstellen, legt das Hosting-System ein neues Document Root an — entweder innerhalb von `public_html` oder als paralleles Verzeichnis auf derselben Ebene.

Subdomain-Document-Roots

“`

/home/username/public_html/blog/ → blog.example.com

/home/username/public_html/shop/ → shop.example.com

“`

Oder in einigen cPanel-Konfigurationen:

“`

/home/username/blog.example.com/ → blog.example.com

“`

Add-on-Domain-Document-Roots

“`

/home/username/public_html/newdomain/ → newdomain.com

“`

Oder als übergeordnetes Geschwisterverzeichnis:

“`

/home/username/newdomain.com/ → newdomain.com

“`

Der genaue Pfad hängt von Ihrer Hosting-Panel-Konfiguration ab. Überprüfen Sie immer das Document Root in cPanel unter Domains > Subdomains oder Addon Domains, um zu vermeiden, dass Dateien am falschen Ort hochgeladen werden.

Verhaltensunterschiede in verschiedenen Hosting-Umgebungen

Shared Hosting (cPanel)

Bei Shared Web Hosting mit cPanel ist die Struktur standardisiert:

• Document Root: `/home/username/public_html/`
• `www`-Symlink: standardmäßig vorhanden
• Apache mit `.htaccess`-Unterstützung: aktiviert
• Mehrere Domains: jede erhält ihr eigenes Unterverzeichnis oder einen parallelen Ordner

VPS und Dedicated Server

Auf einem Dedicated Server oder selbst verwaltetem VPS wird das Document Root vollständig vom Administrator in der Webserver-Konfiguration definiert. Gängige Konventionen:

Apache Virtual Host (`/etc/apache2/sites-available/example.com.conf`):

“`apache

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot /var/www/example.com/public_html

</VirtualHost>

“`

Nginx Server Block (`/etc/nginx/sites-available/example.com`):

“`nginx

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html;

}

“`

In diesen Umgebungen ist `public_html` eine Namenskonvention, keine technische Anforderung. Das Document Root kann beliebig benannt werden — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — solange die Webserver-Konfiguration darauf verweist. Der `www`-Symlink existiert in der Regel nicht, es sei denn, Sie erstellen ihn manuell.

cPanel VPS

Ein VPS mit cPanel kombiniert die Flexibilität eines VPS mit der standardisierten `public_html`-Struktur des Shared Hostings und ist damit die häufigste Umgebung, in der sowohl `www` als auch `public_html` genau so koexistieren, wie in diesem Artikel beschrieben.

Dateiberechtigungen: Eine häufig übersehene Anforderung

Falsche Berechtigungen sind eine der häufigsten Ursachen für 403 Forbidden-Fehler und fehlgeschlagene Deployments. Das Standard-Berechtigungsmodell für webzugängliche Dateien:

Berechtigungen rekursiv setzen mit:

“`bash

find ~/public_html -type d -exec chmod 755 {} ;

find ~/public_html -type f -exec chmod 644 {} ;

“`

Setzen Sie niemals `777` auf eine Datei oder ein Verzeichnis in einer Produktionsumgebung. Dies gewährt allen Systembenutzern Schreibzugriff und ist ein direkter Angriffsvektor für eine Server-Kompromittierung.

SSL, HTTPS und das Document Root

Wenn Sie ein SSL-Zertifikat auf Ihrer Domain installieren, bindet sich das Zertifikat an den Domain-Namen, nicht an ein bestimmtes Verzeichnis. Die HTTPS-Virtual-Host-Konfiguration muss jedoch auf dasselbe `public_html`-Document-Root wie die HTTP-Konfiguration verweisen. Eine Diskrepanz — bei der HTTP aus einem Verzeichnis und HTTPS aus einem anderen bereitstellt — führt zu inkonsistentem Verhalten, das notorisch schwer zu diagnostizieren ist.

Wenn Sie Let’s Encrypt über Certbot verwenden, legt der ACME-Challenge-Verifizierungsprozess temporäre Dateien in `public_html/.well-known/acme-challenge/` ab. Stellen Sie sicher, dass dieser Pfad nicht durch `.htaccess`-Regeln oder Nginx-`location`-Blöcke blockiert wird, die den Zugriff auf versteckte Verzeichnisse (solche, die mit `.` beginnen) verweigern.

Praktische Checkliste der wichtigsten Erkenntnisse

Vor dem Hochladen Ihrer Website:

• Bestätigen Sie den genauen Document-Root-Pfad in Ihrem Hosting-Panel — nehmen Sie nicht an, dass es immer `/home/username/public_html/` ist
• Überprüfen Sie, ob `www` ein Symlink und kein separates Verzeichnis ist, um doppeltes Dateimanagement zu vermeiden
• Verschieben Sie sensible Konfigurationsdateien (`.env`, Datenbankzugangsdaten) oberhalb von `public_html`

Während des Deployments:

• Setzen Sie Verzeichnisberechtigungen auf `755` und Dateiberechtigungen auf `644`
• Stellen Sie sicher, dass eine `index.html` oder `index.php` im Document Root vorhanden ist, um Verzeichnis-Listings zu verhindern
• Deaktivieren Sie `Options Indexes` in `.htaccess` als Defense-in-Depth-Maßnahme

Für Multi-Domain-Setups:

• Bestätigen Sie das Document Root für jede Subdomain und Add-on-Domain individuell
• Nehmen Sie nicht an, dass alle Domains dasselbe `public_html` teilen

In VPS- und Dedicated-Umgebungen:

• Definieren Sie das Document Root explizit in Ihrer Virtual-Host- oder Server-Block-Konfiguration
• Der `www`-Symlink existiert standardmäßig nicht — erstellen Sie ihn nur, wenn Legacy-Skripte ihn erfordern
• Starten Sie den Webserver nach jeder Konfigurationsänderung neu: `systemctl reload apache2` oder `systemctl reload nginx`

Zur Sicherheitshärtung:

• Speichern Sie niemals API-Schlüssel, `.env`-Dateien oder Datenbankkonfigurationen innerhalb von `public_html`
• Überprüfen Sie `public_html` regelmäßig auf unerwartete Dateien, insbesondere in `uploads/`-Verzeichnissen
• Stellen Sie sicher, dass Ihr SSL-Virtual-Host auf dasselbe Document Root wie die HTTP-Konfiguration verweist

Häufig gestellte Fragen

Was passiert, wenn ich das `www`-Verzeichnis lösche?

Wenn `www` ein symbolischer Link ist (was in praktisch allen cPanel-Umgebungen der Fall ist), hat das Löschen keine Auswirkungen auf Ihre Website oder deren Dateien. Ihre Website funktioniert weiterhin normal, da der eigentliche Inhalt in `public_html` gespeichert ist. Sie können den Symlink jederzeit mit `ln -s ~/public_html ~/www` neu erstellen.

Kann ich `public_html` in etwas anderes umbenennen?

Bei Shared Hosting nein — das Kontrollpanel ist fest auf `public_html` als Document Root kodiert. Auf einem selbst verwalteten VPS oder Dedicated Server können Sie das Document Root beliebig benennen, sofern Sie die Webserver-Konfiguration (`DocumentRoot` in Apache, `root` in Nginx) entsprechend aktualisieren.

Warum erhalte ich einen 403 Forbidden-Fehler, obwohl meine Dateien in `public_html` liegen?

Die häufigsten Ursachen sind falsche Dateiberechtigungen (Dateien benötigen mindestens `644`, Verzeichnisse benötigen `755`), eine fehlende Indexdatei bei deaktiviertem Verzeichnis-Listing oder eine `.htaccess`-Regel, die den Zugriff blockiert. Überprüfen Sie das Webserver-Fehlerprotokoll (`/var/log/apache2/error.log` oder `/var/log/nginx/error.log`) für den spezifischen Grund.

Wo sollte ich Dateien speichern, die PHP lesen muss, die aber nicht öffentlich zugänglich sein sollen?

Legen Sie sie in einem Verzeichnis oberhalb von `public_html` ab, beispielsweise in `/home/username/private/` oder direkt in `/home/username/`. PHP kann Dateien überall im Dateisystem lesen, auf die der Webserver-Benutzer Zugriffsrechte hat, aber der Webserver stellt keine Dateien außerhalb des Document Root per HTTP bereit.

Verhält sich die `www`-Subdomain auf Serverebene anders als die Non-www-Domain?

Nein. Sowohl `www.example.com` als auch `example.com` werden über DNS-Konfiguration und Virtual-Host-Einstellungen auf dasselbe Document Root aufgelöst. Das `www`-Verzeichnis-Symlink im Dateisystem ist unabhängig von der `www.`-DNS-Subdomain — es sind separate Konzepte, die zufällig dieselben drei Buchstaben teilen.