O que é o diretório `www` e `public_html` na sua conta de hospedagem?

O diretório `public_html` é a raiz de documentos do seu website — a pasta do lado do servidor a partir da qual o seu servidor web (Apache, Nginx, LiteSpeed) lê e serve todos os ficheiros acessíveis publicamente quando um visitante carrega o seu domínio. O diretório `www`, na maioria dos ambientes partilhados e baseados em cPanel, é simplesmente um link simbólico (symlink) que aponta para `public_html`, existindo por compatibilidade histórica e não como uma localização de armazenamento independente.

Compreender esta distinção não é meramente cosmético. Colocar ficheiros fora de `public_html`, configurar incorretamente a raiz de documentos, ou não compreender a relação de symlink pode resultar em implementações com erros, erros 403 Forbidden, ou exposição pública não intencional de ficheiros de configuração sensíveis.

O Papel de `public_html` como Raiz de Documentos

Quando um pedido HTTP chega ao seu servidor, o daemon do servidor web consulta a sua configuração para determinar qual diretório corresponde ao domínio solicitado. Esse diretório é chamado de raiz de documentos. Em praticamente todos os ambientes de alojamento partilhado e na maioria das configurações de VPS Hosting que executam cPanel ou painéis de controlo semelhantes, essa raiz de documentos é `public_html`.

O caminho absoluto num servidor cPanel típico é o seguinte:

“`

/home/username/public_html/

“`

Qualquer ficheiro colocado dentro deste diretório torna-se acessível publicamente através do seu domínio. O mapeamento é direto:

Essa última linha é crítica. Os ficheiros colocados acima de `public_html` na árvore de diretórios — diretamente em `/home/username/` — são invisíveis para o servidor web e não podem ser obtidos via HTTP. Esta é a localização correta para ficheiros sensíveis como credenciais de base de dados, ficheiros `.env` e chaves API que a sua aplicação lê em tempo de execução, mas que nunca devem ser servidos publicamente.

Ficheiros de Índice Predefinidos e Resolução de Diretórios

Quando um visitante solicita um URL de diretório (por exemplo, `https://example.com/`), o servidor web procura um ficheiro de índice predefinido nesse diretório. A ordem de resolução padrão na diretiva `DirectoryIndex` do Apache é tipicamente:

“`

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

“`

Se nenhum destes ficheiros existir e a listagem de diretórios não estiver explicitamente desativada, o servidor pode devolver um erro 403 Forbidden ou expor uma listagem de diretórios — um risco de segurança significativo. Certifique-se sempre de que existe um ficheiro de índice válido ou de que `Options -Indexes` está definido no seu `.htaccess`.

O Que é Realmente o Diretório `www`

O diretório `www` é um link simbólico POSIX, não um diretório real com o seu próprio inode e alocação de armazenamento. Pode verificar isto em qualquer servidor baseado em Linux:

“`bash

ls -la ~/

“`

O resultado 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

“`

O `l` no início da cadeia de permissões e a seta `-> public_html` confirmam que é um symlink. Isto significa:

• `www` e `public_html` partilham exatamente os mesmos dados de inode
• Escrever um ficheiro em `~/www/contact.html` é idêntico a escrevê-lo em `~/public_html/contact.html`
• Eliminar `www` não elimina `public_html` nem nenhum dos seus conteúdos
• Recriar o symlink é trivial: `ln -s ~/public_html ~/www`

Por Que Existe o Symlink `www`

O symlink `www` é um artefacto legado com raízes práticas. Nos primeiros ambientes de alojamento baseados em Unix, a convenção era armazenar conteúdo web num diretório literalmente chamado `www` — espelhando o prefixo de subdomínio `www.` que se tornou ubíquo nos anos 90. À medida que o cPanel padronizou `public_html` como nome da raiz de documentos, o symlink `www` foi mantido para evitar quebrar:

• Scripts de implementação mais antigos codificados para escrever em `~/www/`
• Clientes FTP e gestores de ficheiros que esperavam uma pasta `www`
• Documentação e tutoriais que referenciavam `www` como destino de upload

Para todos os efeitos práticos num ambiente moderno, deve tratar `public_html` como a localização canónica e ignorar `www` completamente.

`public_html` vs `www`: Comparação Direta

Estrutura de Diretórios Dentro de `public_html`

Um diretório `public_html` bem organizado separa as responsabilidades de forma clara. Aqui está uma estrutura realista para produção de um site baseado em PHP ou instalação 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 segurança: `wp-config.php` contém credenciais de base de dados. O WordPress suporta colocar este ficheiro um diretório acima de `public_html` (`/home/username/wp-config.php`), onde é inacessível via HTTP mas ainda legível pelo PHP. Esta é uma boa prática de segurança que muitos administradores ignoram.

Como Subdomínios e Domínios Adicionais Estendem Esta Estrutura

Quando cria um subdomínio ou domínio adicional através de Painéis de Controlo VPS ou cPanel, o sistema de alojamento cria uma nova raiz de documentos — seja dentro de `public_html` ou como um diretório paralelo ao mesmo nível.

Raízes de Documentos de Subdomínios

“`

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

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

“`

Ou, em algumas configurações cPanel:

“`

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

“`

Raízes de Documentos de Domínios Adicionais

“`

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

“`

Ou como um irmão de nível superior:

“`

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

“`

O caminho exato depende da configuração do seu painel de alojamento. Verifique sempre a raiz de documentos no cPanel em Domínios > Subdomínios ou Domínios Adicionais para evitar carregar ficheiros para a localização errada.

Diferenças de Comportamento Entre Ambientes de Alojamento

Alojamento Partilhado (cPanel)

No Alojamento Web Partilhado com cPanel, a estrutura é padronizada:

• Raiz de documentos: `/home/username/public_html/`
• Symlink `www`: presente por predefinição
• Apache com suporte `.htaccess`: ativado
• Múltiplos domínios: cada um obtém o seu próprio subdiretório ou pasta paralela

VPS e Servidores Dedicados

Num Servidor Dedicado ou VPS autogerido, a raiz de documentos é inteiramente definida pelo administrador na configuração do servidor web. Convenções comuns:

Virtual Host 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>

“`

Bloco 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;

}

“`

Nestes ambientes, `public_html` é uma convenção de nomenclatura, não um requisito técnico. A raiz de documentos pode ter qualquer nome — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — desde que a configuração do servidor web aponte para ela. O symlink `www` tipicamente não existe a menos que o crie manualmente.

VPS cPanel

Um VPS com cPanel combina a flexibilidade de um VPS com a estrutura `public_html` padronizada do alojamento partilhado, tornando-o o ambiente mais comum onde tanto `www` como `public_html` coexistem exatamente como descrito neste artigo.

Permissões de Ficheiros: Um Requisito Frequentemente Ignorado

Permissões incorretas são uma das causas mais comuns de erros 403 Forbidden e falhas de implementação. O modelo de permissões padrão para ficheiros acessíveis via web:

Defina permissões recursivamente com:

“`bash

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

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

“`

Nunca defina `777` em nenhum ficheiro ou diretório num ambiente de produção. Isto concede acesso de escrita a todos os utilizadores do sistema e é um vetor direto para comprometimento do servidor.

SSL, HTTPS e a Raiz de Documentos

Quando instala um Certificado SSL no seu domínio, o certificado vincula-se ao nome de domínio, não a um diretório específico. No entanto, a configuração do virtual host HTTPS deve apontar para a mesma raiz de documentos `public_html` que a configuração HTTP. Uma incompatibilidade — onde HTTP serve a partir de um diretório e HTTPS a partir de outro — produz comportamento inconsistente que é notoriamente difícil de diagnosticar.

Se utilizar Let’s Encrypt via Certbot, o processo de verificação do desafio ACME coloca ficheiros temporários em `public_html/.well-known/acme-challenge/`. Certifique-se de que este caminho não está bloqueado por regras `.htaccess` ou blocos `location` do Nginx que negam acesso a diretórios ocultos (aqueles que começam com `.`).

Lista de Verificação de Pontos-Chave Práticos

Antes de carregar o seu site:

• Confirme o caminho exato da raiz de documentos no seu painel de alojamento — não assuma que é sempre `/home/username/public_html/`
• Verifique se `www` é um symlink e não um diretório separado, para evitar gestão duplicada de ficheiros
• Mova ficheiros de configuração sensíveis (`.env`, credenciais de base de dados) para acima de `public_html`

Durante a implementação:

• Defina permissões de diretório para `755` e permissões de ficheiro para `644`
• Certifique-se de que existe um `index.html` ou `index.php` na raiz de documentos para evitar listagem de diretórios
• Desative `Options Indexes` no `.htaccess` como medida de defesa em profundidade

Para configurações com múltiplos domínios:

• Confirme a raiz de documentos para cada subdomínio e domínio adicional individualmente
• Não assuma que todos os domínios partilham o mesmo `public_html`

Em ambientes VPS e dedicados:

• Defina a raiz de documentos explicitamente na configuração do seu virtual host ou bloco de servidor
• O symlink `www` não existe por predefinição — crie-o apenas se scripts legados o exigirem
• Reinicie o servidor web após qualquer alteração de configuração: `systemctl reload apache2` ou `systemctl reload nginx`

Para reforço de segurança:

• Nunca armazene chaves API, ficheiros `.env` ou configurações de base de dados dentro de `public_html`
• Audite `public_html` periodicamente em busca de ficheiros inesperados, particularmente em diretórios `uploads/`
• Certifique-se de que o seu virtual host SSL aponta para a mesma raiz de documentos que a configuração HTTP

Perguntas Frequentes

O que acontece se eu eliminar o diretório `www`?

Se `www` for um link simbólico (o que é em praticamente todos os ambientes cPanel), eliminá-lo não tem qualquer efeito no seu website ou nos seus ficheiros. O seu site continua a funcionar normalmente porque o conteúdo real reside em `public_html`. Pode recriar o symlink a qualquer momento com `ln -s ~/public_html ~/www`.

Posso renomear `public_html` para outra coisa?

No alojamento partilhado, não — o painel de controlo está codificado para usar `public_html` como raiz de documentos. Num VPS autogerido ou servidor dedicado, pode dar à raiz de documentos o nome que quiser, desde que atualize a configuração do servidor web (`DocumentRoot` no Apache, `root` no Nginx) para corresponder.

Por que estou a receber um erro 403 Forbidden mesmo que os meus ficheiros estejam em `public_html`?

As causas mais comuns são permissões de ficheiro incorretas (os ficheiros precisam de pelo menos `644`, os diretórios precisam de `755`), um ficheiro de índice em falta com a listagem de diretórios desativada, ou uma regra `.htaccess` a bloquear o acesso. Verifique o registo de erros do servidor web (`/var/log/apache2/error.log` ou `/var/log/nginx/error.log`) para obter o motivo específico.

Onde devo armazenar ficheiros que o PHP precisa de ler mas que não devem ser acessíveis publicamente?

Coloque-os num diretório acima de `public_html`, como `/home/username/private/` ou diretamente em `/home/username/`. O PHP pode ler ficheiros em qualquer parte do sistema de ficheiros a que o utilizador do servidor web tenha permissão de acesso, mas o servidor web não servirá ficheiros fora da raiz de documentos via HTTP.

O subdomínio `www` funciona de forma diferente do domínio sem www ao nível do servidor?

Não. Tanto `www.example.com` como `example.com` são resolvidos para a mesma raiz de documentos através da configuração DNS e das definições de virtual host. O diretório symlink `www` no sistema de ficheiros não está relacionado com o subdomínio DNS `www.` — são conceitos separados que partilham as mesmas três letras.