¿Qué es el directorio `www` y `public_html` en tu cuenta de hosting?

El directorio `public_html` es la raíz de documentos de su sitio web — la carpeta del lado del servidor desde la cual su servidor web (Apache, Nginx, LiteSpeed) lee y sirve todos los archivos de acceso público cuando un visitante carga su dominio. El directorio `www`, en la mayoría de los entornos compartidos y basados en cPanel, es simplemente un enlace simbólico (symlink) que apunta a `public_html`, existiendo por compatibilidad histórica en lugar de ser una ubicación de almacenamiento independiente.

Comprender esta distinción no es meramente cosmético. Colocar archivos fuera de `public_html`, configurar incorrectamente la raíz de documentos o malinterpretar la relación del symlink puede resultar en implementaciones fallidas, errores 403 Forbidden o exposición pública no intencional de archivos de configuración sensibles.

El Rol de `public_html` como Raíz de Documentos

Cuando una solicitud HTTP llega a su servidor, el daemon del servidor web consulta su configuración para determinar qué directorio corresponde al dominio solicitado. Ese directorio se denomina raíz de documentos. En prácticamente todos los entornos de alojamiento compartido y en la mayoría de las configuraciones de VPS Hosting que ejecutan cPanel o paneles de control similares, esa raíz de documentos es `public_html`.

La ruta absoluta en un servidor cPanel típico tiene este aspecto:

“`

/home/username/public_html/

“`

Cualquier archivo colocado dentro de este directorio se vuelve accesible públicamente a través de su dominio. La correspondencia es directa:

Esa última fila es fundamental. Los archivos colocados por encima de `public_html` en el árbol de directorios — directamente en `/home/username/` — son invisibles para el servidor web y no pueden ser recuperados mediante HTTP. Esta es la ubicación correcta para archivos sensibles como credenciales de bases de datos, archivos `.env` y claves API que su aplicación lee en tiempo de ejecución pero que nunca deben ser servidos públicamente.

Archivos de Índice Predeterminados y Resolución de Directorios

Cuando un visitante solicita una URL de directorio (p. ej., `https://example.com/`), el servidor web busca un archivo de índice predeterminado en ese directorio. El orden de resolución estándar en la directiva `DirectoryIndex` de Apache es típicamente:

“`

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

“`

Si ninguno de estos archivos existe y el listado de directorios no está explícitamente deshabilitado, el servidor puede devolver un 403 Forbidden o exponer un listado de directorios — un riesgo de seguridad significativo. Asegúrese siempre de que exista un archivo de índice válido o de que `Options -Indexes` esté configurado en su `.htaccess`.

Qué es Realmente el Directorio `www`

El directorio `www` es un enlace simbólico POSIX, no un directorio real con su propio inodo y asignación de almacenamiento. Puede verificarlo en cualquier servidor basado en Linux:

“`bash

ls -la ~/

“`

La salida mostrará algo como:

“`

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

“`

El `l` al inicio de la cadena de permisos y la flecha `-> public_html` confirman que es un symlink. Esto significa:

• `www` y `public_html` comparten exactamente los mismos datos de inodo
• Escribir un archivo en `~/www/contact.html` es idéntico a escribirlo en `~/public_html/contact.html`
• Eliminar `www` no elimina `public_html` ni ninguno de sus contenidos
• Recrear el symlink es trivial: `ln -s ~/public_html ~/www`

Por Qué Existe el Symlink `www`

El symlink `www` es un artefacto heredado con raíces prácticas. En los primeros entornos de alojamiento basados en Unix, la convención era almacenar el contenido web en un directorio literalmente llamado `www` — reflejando el prefijo de subdominio `www.` que se volvió omnipresente en los años 90. A medida que cPanel estandarizó `public_html` como nombre de la raíz de documentos, el symlink `www` se mantuvo para evitar romper:

• Scripts de implementación más antiguos codificados para escribir en `~/www/`
• Clientes FTP y gestores de archivos que esperaban una carpeta `www`
• Documentación y tutoriales que referenciaban `www` como destino de carga

Para todos los propósitos prácticos en un entorno moderno, debe tratar `public_html` como la ubicación canónica e ignorar `www` por completo.

`public_html` vs `www`: Comparación Directa

Estructura de Directorios Dentro de `public_html`

Un directorio `public_html` bien organizado separa las responsabilidades claramente. Aquí hay una estructura realista para producción de un sitio basado en PHP o una instalación de WordPress:

“`

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

“`

Nota crítica de seguridad: `wp-config.php` contiene credenciales de base de datos. WordPress permite colocar este archivo un directorio por encima de `public_html` (`/home/username/wp-config.php`), donde es inaccesible mediante HTTP pero aún legible por PHP. Esta es una práctica recomendada de seguridad que muchos administradores pasan por alto.

Cómo los Subdominios y Dominios Adicionales Extienden Esta Estructura

Cuando crea un subdominio o dominio adicional a través de Paneles de Control VPS o cPanel, el sistema de alojamiento crea una nueva raíz de documentos — ya sea dentro de `public_html` o como un directorio paralelo al mismo nivel.

Raíces de Documentos de Subdominios

“`

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

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

“`

O, en algunas configuraciones de cPanel:

“`

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

“`

Raíces de Documentos de Dominios Adicionales

“`

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

“`

O como un directorio hermano de nivel superior:

“`

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

“`

La ruta exacta depende de la configuración de su panel de alojamiento. Verifique siempre la raíz de documentos en cPanel en Dominios > Subdominios o Dominios Adicionales para evitar cargar archivos en la ubicación incorrecta.

Diferencias de Comportamiento Entre Entornos de Alojamiento

Alojamiento Compartido (cPanel)

En Alojamiento Web Compartido con cPanel, la estructura está estandarizada:

• Raíz de documentos: `/home/username/public_html/`
• Symlink `www`: presente por defecto
• Apache con soporte `.htaccess`: habilitado
• Múltiples dominios: cada uno obtiene su propio subdirectorio o carpeta paralela

VPS y Servidores Dedicados

En un Servidor Dedicado o VPS autogestionado, la raíz de documentos está completamente definida por el administrador en la configuración del servidor web. Convenciones comunes:

Virtual Host de Apache (`/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>

“`

Bloque de Servidor Nginx (`/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;

}

“`

En estos entornos, `public_html` es una convención de nomenclatura, no un requisito técnico. La raíz de documentos puede llamarse de cualquier manera — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — siempre que la configuración del servidor web apunte a ella. El symlink `www` típicamente no existe a menos que lo cree manualmente.

VPS con cPanel

Un VPS con cPanel combina la flexibilidad de un VPS con la estructura estandarizada `public_html` del alojamiento compartido, convirtiéndolo en el entorno más común donde tanto `www` como `public_html` coexisten exactamente como se describe en este artículo.

Permisos de Archivos: Un Requisito Frecuentemente Ignorado

Los permisos incorrectos son una de las causas más comunes de errores 403 Forbidden e implementaciones fallidas. El modelo de permisos estándar para archivos accesibles desde la web:

Establezca permisos de forma recursiva con:

“`bash

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

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

“`

Nunca establezca `777` en ningún archivo o directorio en un entorno de producción. Esto otorga acceso de escritura a todos los usuarios del sistema y es un vector directo para el compromiso del servidor.

SSL, HTTPS y la Raíz de Documentos

Cuando instala un Certificado SSL en su dominio, el certificado se vincula al nombre de dominio, no a un directorio específico. Sin embargo, la configuración del virtual host HTTPS debe apuntar a la misma raíz de documentos `public_html` que la configuración HTTP. Una discrepancia — donde HTTP sirve desde un directorio y HTTPS desde otro — produce un comportamiento inconsistente que es notoriamente difícil de diagnosticar.

Si utiliza Let's Encrypt mediante Certbot, el proceso de verificación del desafío ACME coloca archivos temporales en `public_html/.well-known/acme-challenge/`. Asegúrese de que esta ruta no esté bloqueada por reglas `.htaccess` o bloques `location` de Nginx que denieguen el acceso a directorios ocultos (aquellos que comienzan con `.`).

Lista de Verificación de Puntos Clave Prácticos

Antes de cargar su sitio:

• Confirme la ruta exacta de la raíz de documentos en su panel de alojamiento — no asuma que siempre es `/home/username/public_html/`
• Verifique que `www` es un symlink, no un directorio separado, para evitar la gestión duplicada de archivos
• Mueva los archivos de configuración sensibles (`.env`, credenciales de base de datos) por encima de `public_html`

Durante la implementación:

• Establezca los permisos de directorio en `755` y los permisos de archivo en `644`
• Asegúrese de que exista un `index.html` o `index.php` en la raíz de documentos para evitar el listado de directorios
• Deshabilite `Options Indexes` en `.htaccess` como medida de defensa en profundidad

Para configuraciones de múltiples dominios:

• Confirme la raíz de documentos para cada subdominio y dominio adicional individualmente
• No asuma que todos los dominios comparten el mismo `public_html`

En entornos VPS y dedicados:

• Defina la raíz de documentos explícitamente en la configuración de su virtual host o bloque de servidor
• El symlink `www` no existe por defecto — créelo solo si los scripts heredados lo requieren
• Reinicie el servidor web después de cualquier cambio de configuración: `systemctl reload apache2` o `systemctl reload nginx`

Para el fortalecimiento de la seguridad:

• Nunca almacene claves API, archivos `.env` o configuraciones de base de datos dentro de `public_html`
• Audite `public_html` periódicamente en busca de archivos inesperados, particularmente en directorios `uploads/`
• Asegúrese de que su virtual host SSL apunte a la misma raíz de documentos que la configuración HTTP

Preguntas Frecuentes

¿Qué sucede si elimino el directorio `www`?

Si `www` es un enlace simbólico (que lo es en prácticamente todos los entornos cPanel), eliminarlo no tiene ningún efecto en su sitio web ni en sus archivos. Su sitio continúa funcionando normalmente porque el contenido real reside en `public_html`. Puede recrear el symlink en cualquier momento con `ln -s ~/public_html ~/www`.

¿Puedo renombrar `public_html` a otra cosa?

En alojamiento compartido, no — el panel de control está codificado para usar `public_html` como raíz de documentos. En un VPS autogestionado o servidor dedicado, puede nombrar la raíz de documentos como desee, siempre que actualice la configuración del servidor web (`DocumentRoot` en Apache, `root` en Nginx) para que coincida.

¿Por qué obtengo un error 403 Forbidden aunque mis archivos están en `public_html`?

Las causas más comunes son permisos de archivo incorrectos (los archivos necesitan al menos `644`, los directorios necesitan `755`), un archivo de índice faltante con el listado de directorios deshabilitado, o una regla `.htaccess` que bloquea el acceso. Consulte el registro de errores del servidor web (`/var/log/apache2/error.log` o `/var/log/nginx/error.log`) para conocer el motivo específico.

¿Dónde debo almacenar archivos que PHP necesita leer pero que no deben ser accesibles públicamente?

Colóquelos en un directorio por encima de `public_html`, como `/home/username/private/` o directamente en `/home/username/`. PHP puede leer archivos en cualquier lugar del sistema de archivos al que el usuario del servidor web tenga permiso de acceso, pero el servidor web no servirá archivos fuera de la raíz de documentos mediante HTTP.

¿El subdominio `www` funciona de manera diferente al dominio sin www a nivel del servidor?

No. Tanto `www.example.com` como `example.com` se resuelven a la misma raíz de documentos a través de la configuración DNS y los ajustes del virtual host. El directorio symlink `www` en el sistema de archivos no está relacionado con el subdominio DNS `www.` — son conceptos separados que comparten las mismas tres letras.