Como Remover “wordpress” da URL do Seu Site (Guia Técnico Completo)

Quando o WordPress é instalado num subdiretório chamado /wordpress, cada URL pública carrega esse segmento de caminho — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — o que prejudica a credibilidade da marca e dilui o valor de SEO. A solução é uma migração controlada de ficheiros combinada com atualizações de URL na base de dados: move todos os ficheiros principais do WordPress do subdiretório para a raiz do documento do servidor (public_html), atualiza as definições de Endereço do WordPress e Endereço do Site, regenera as regras de reescrita e emite redirecionamentos 301 para quaisquer URLs legados indexados. Não é necessária reinstalação.

Este guia abrange todas as camadas técnicas desse processo — operações do sistema de ficheiros, substituição de strings na base de dados, lógica de reescrita .htaccess, estratégia de redirecionamento e validação pós-migração — incluindo casos extremos que causam falhas silenciosas na maioria dos tutoriais.

Por Que o WordPress Acaba num Subdiretório

Compreender a causa raiz evita que o mesmo problema se repita. Os cenários mais comuns são:

• Predefinições do instalador: Muitos instaladores de um clique (Softaculous, Installatron) utilizam por predefinição um caminho de subdiretório se o utilizador não definir explicitamente o caminho de instalação para /.
• Promoção de staging para produção: Um programador instala o WordPress em /wordpress para testes e o site fica ativo sem uma correção do caminho.
• Planeamento de multi-site que nunca se concretizou: Alguém antecipou a execução de vários CMSes num domínio e limitou o WordPress à sua própria pasta.
• Peculiaridades do instalador automático do cPanel: Em ambientes VPS com cPanel, o instalador por vezes acrescenta o nome da aplicação como subdiretório, a menos que seja substituído.

Independentemente da origem, o procedimento de migração é idêntico.

Lista de Verificação Pré-Migração

Antes de tocar num único ficheiro, complete todos os itens desta lista. Ignorar qualquer um deles é a principal causa de tempo de inatividade durante esta operação.

• Cópia de segurança completa do site: Arquive tanto o sistema de ficheiros como a base de dados MySQL. Plugins como UpdraftPlus ou Duplicator funcionam bem; o mesmo se aplica a um snapshot ao nível do servidor se o seu fornecedor de VPS Hosting o suportar.
• Credenciais da base de dados disponíveis: Vai precisar delas se for necessária uma edição manual do wp-config.php.
• Modo de manutenção ativo: Utilize um plugin ou adicione define('WP_MAINTENANCE_MODE', true); temporariamente para evitar escritas durante a janela de migração.
• Registo de erros PHP ativado: Defina WP_DEBUG_LOG para true em wp-config.php para que quaisquer erros pós-migração sejam escritos em /wp-content/debug.log em vez de aparecerem no ecrã.
• TTL do DNS anotado: Se também estiver envolvida uma alteração de DNS, reduza o TTL para 300 segundos pelo menos uma hora antes de começar.

Passo 1: Mover os Ficheiros do WordPress para a Raiz do Documento

O objetivo é copiar tudo dentro de /public_html/wordpress/ diretamente para /public_html/ — não a pasta em si, mas o seu conteúdo.

Usando um Cliente FTP (FileZilla)

1. Ligue-se ao seu servidor via SFTP (porta 22) em vez de FTP simples para evitar a interceção de credenciais.
2. Navegue até public_html/wordpress/.
3. Selecione todos os ficheiros e pastas incluindo ficheiros ocultos. No FileZilla, ative Ver > Mostrar Ficheiros Ocultos para expor .htaccess e quaisquer ficheiros .env.
4. Arraste a seleção um nível de diretório acima para public_html/.
5. Quando solicitado sobre a substituição de index.php (se existir um marcador de posição na raiz), confirme a substituição.

Usando a Linha de Comandos (Recomendado para VPS)

Se tiver acesso SSH — o que deve ter em qualquer ambiente VPS Hosting ou Servidor Dedicado corretamente configurado — a abordagem por linha de comandos é mais rápida e evita problemas de timeout de FTP em instalações grandes:

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

Não elimine ainda o diretório /wordpress. Deixe-o intacto até que a migração seja totalmente validada. Pode removê-lo na etapa final de limpeza.

Caso Extremo Crítico: Symlinks e Caminhos Absolutos em Plugins

Alguns plugins (particularmente plugins de cópia de segurança e segurança) armazenam caminhos de ficheiros absolutos na base de dados — por exemplo, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Estes irão falhar silenciosamente após a mudança. A pesquisa e substituição na base de dados no Passo 5 trata disto, mas deve incluir a tabela wp_options e quaisquer tabelas de plugins personalizados no âmbito da substituição.

Passo 2: Atualizar o Endereço do WordPress e o Endereço do Site

O WordPress armazena dois valores de URL críticos na tabela wp_options: siteurl (o Endereço do WordPress, apontando para onde os ficheiros principais do WordPress residem) e home (o Endereço do Site, o URL que os visitantes usam para aceder ao site). Ambos devem ser atualizados.

Método A: Painel de Controlo do WordPress

1. Inicie sessão em yourdomain.com/wordpress/wp-admin — isto ainda funciona porque os ficheiros ainda estão em ambos os locais neste momento.
2. Vá a Definições > Geral.
3. Atualize ambos os campos:

• Endereço do WordPress (URL): https://yourdomain.com
• Endereço do Site (URL): https://yourdomain.com

1. Clique em Guardar Alterações.

Método B: Edição Direta da Base de Dados (Quando o Painel de Controlo Está Inacessível)

Se o painel de controlo já estiver inacessível, use WP-CLI ou phpMyAdmin:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Ou no phpMyAdmin, execute:

UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';

Substitua wp_ pelo seu prefixo de tabela real se foi alterado durante a instalação.

Método C: Substituição Temporária no wp-config.php

Se tanto o painel de controlo como a base de dados estiverem temporariamente inacessíveis, adicione estas duas linhas ao wp-config.php como uma substituição de arranque:

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

Isto substitui o que estiver armazenado na base de dados. Remova estas linhas após confirmar que o painel de controlo está acessível e que os valores da base de dados foram atualizados permanentemente.

Passo 3: Verificar e Atualizar o Ficheiro .htaccess

O ficheiro .htaccess na raiz do documento controla a reescrita de URL do Apache para o WordPress. Após mover os ficheiros, este ficheiro já deve estar em public_html/ — mas a sua diretiva RewriteBase deve refletir a nova instalação ao nível da raiz.

Abra public_html/.htaccess e certifique-se de que contém exatamente o seguinte bloco de reescrita do WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

A alteração principal em relação a uma instalação em subdiretório é RewriteBase / em vez de RewriteBase /wordpress/. Se esta linha estiver errada, todos os permalinks formatados retornam erros 404 enquanto a página inicial carrega corretamente — uma assinatura de diagnóstico clássica de um RewriteBase mal configurado.

Utilizadores de Nginx: O WordPress não usa .htaccess. Atualize a diretiva try_files do seu bloco de servidor:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Passo 4: Limpar a Estrutura de Permalinks

O WordPress armazena em cache as regras de reescrita na base de dados. Após alterar o URL do site, essas regras em cache referenciam a estrutura de caminho antiga e devem ser regeneradas.

1. Vá a Definições > Permalinks no painel de controlo do WordPress.
2. Sem modificar a estrutura de permalink selecionada, clique em Guardar Alterações.

Isto força o WordPress a reconstruir e armazenar em cache as regras de reescrita em relação ao novo caminho ao nível da raiz. Em alternativa, use WP-CLI:

wp rewrite flush --hard

O sinalizador --hard regenera o ficheiro .htaccess além de limpar o cache da base de dados — útil se não tiver a certeza se o .htaccess está correto.

Passo 5: Substituição de URL em Toda a Base de Dados

Mover ficheiros e atualizar siteurl/home não é suficiente. O WordPress armazena strings de URL serializadas em toda a base de dados — no conteúdo de publicações, postmeta, definições de widgets, opções de temas e tabelas de configuração de plugins. Quaisquer referências de caminho /wordpress restantes produzirão imagens quebradas, tags canónicas incorretas e funcionalidades de plugins com mau funcionamento.

Usando o Plugin Better Search Replace

1. Instale e ative o plugin Better Search Replace.
2. Vá a Ferramentas > Better Search Replace.
3. Configure a substituição:

• Pesquisar por: https://yourdomain.com/wordpress
• Substituir por: https://yourdomain.com

1. Selecione todas as tabelas da base de dados.
2. Desmarque Executar como simulação? apenas após confirmar que a simulação mostra o número esperado de substituições.
3. Clique em Executar Pesquisa/Substituição.

Execute também uma segunda passagem para o caminho absoluto do servidor:

• Pesquisar por: /public_html/wordpress
• Substituir por: /public_html

Usando WP-CLI (Preferido para Produção)

O comando search-replace do WP-CLI trata corretamente os dados serializados, o que a função SQL REPLACE() simples não faz:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Execute uma segunda passagem para caminhos absolutos do sistema de ficheiros:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

O sinalizador --precise usa a substituição com reconhecimento de serialização do PHP em vez de regex, o que evita a corrupção de arrays serializados armazenados na base de dados.

Passo 6: Implementar Redirecionamentos 301 para Continuidade de SEO

Se o site esteve publicamente acessível em URLs /wordpress — e especialmente se esses URLs foram indexados pelo Google ou referenciados a partir de fontes externas — os redirecionamentos permanentes são obrigatórios, não opcionais. Sem eles, cada URL indexado torna-se um 404, e todo o valor de link acumulado é perdido.

Adicione a seguinte regra de redirecionamento ao public_html/.htaccess, acima do bloco de reescrita do WordPress:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Esta regra captura qualquer pedido que comece com wordpress/ e redireciona-o para o caminho equivalente ao nível da raiz. Por exemplo:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Nota importante sobre posicionamento: Este bloco de redirecionamento deve aparecer antes do comentário # BEGIN WordPress. As próprias regras de reescrita do WordPress irão intercetar o pedido primeiro se o redirecionamento for colocado depois delas.

Para Nginx, adicione isto ao bloco de servidor:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Passo 7: Validação Pós-Migração

Os testes sistemáticos evitam que falhas silenciosas passem despercebidas em produção.

Verificações Funcionais

Validação por Linha de Comandos

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Submeta o sitemap atualizado no Google Search Console imediatamente após a validação. Use a ferramenta de Inspeção de URL para solicitar a reindexação da página inicial. Monitorize o relatório de Cobertura nas 48–72 horas seguintes para qualquer aumento de erros 404, o que indicaria substituições de URL em falta.

Passo 8: Limpeza e Proteção Final

Assim que o site estiver a funcionar de forma estável no URL raiz durante 24–48 horas:

1. Elimine o subdiretório /wordpress do servidor. Deixá-lo no lugar cria um risco de conteúdo duplicado e expõe um ponto de entrada secundário para a instalação do WordPress.

rm -rf /var/www/html/public_html/wordpress

1. Remova a constante WP_MAINTENANCE_MODE do wp-config.php se a adicionou.
2. Remova as definições temporárias WP_HOME/WP_SITEURL do wp-config.php se usou o Método C no Passo 2.
3. Verifique a cobertura SSL: Se o seu Certificado SSL foi emitido para yourdomain.com/wordpress como âmbito baseado em caminho (incomum mas possível em algumas configurações), confirme que o certificado cobre corretamente o domínio apex.
4. Atualize quaisquer configurações externas de DNS ou CDN que possam ter armazenado em cache a estrutura de caminho antiga.
5. Limpe todas as camadas de cache: Limpe o cache de página do lado do servidor, o cache de objetos (Redis/Memcached) e o cache de CDN. As entradas de cache obsoletas para URLs /wordpress irão servir conteúdo incorreto mesmo após a conclusão da migração.

Comparação: Métodos de Migração em Resumo

Para qualquer ambiente com acesso SSH — incluindo Servidores Dedicados e instâncias VPS não geridas — a abordagem WP-CLI é a opção mais fiável e menos propensa a erros.

Matriz de Decisão Técnica

Use esta matriz para determinar quais os passos obrigatórios versus situacionais para o seu cenário específico:

Conclusões Principais

• A operação principal é: copiar ficheiros para a raiz do documento, atualizar siteurl e home na base de dados, corrigir .htaccess RewriteBase, executar pesquisa e substituição com reconhecimento de serialização, adicionar redirecionamentos 301.
• Nunca use um SQL REPLACE() simples em tabelas do WordPress sem tratamento de serialização — irá corromper valores de opções e quebrar plugins silenciosamente.
• A diretiva .htaccess RewriteBase / é o elemento mais frequentemente mal configurado nesta migração; um valor errado produz erros 404 em todos os URLs baseados em permalinks enquanto a página inicial continua a carregar.
• Os redirecionamentos 301 não são cosméticos — transferem o valor de link e evitam a fragmentação do índice. São obrigatórios para qualquer site com visibilidade de pesquisa existente.
• Elimine o diretório /wordpress original apenas após uma janela de observação estável de 24 horas.
• Se estiver a executar o WordPress num VPS com cPanel, use a opção Mostrar Ficheiros Ocultos do Gestor de Ficheiros para garantir que .htaccess está incluído na operação de cópia.

Perguntas Frequentes

A remoção de /wordpress do URL irá afetar as minhas classificações de SEO?

A curto prazo, espere pequenas flutuações de classificação enquanto o Googlebot re-rastreia os novos URLs. Se os redirecionamentos 301 forem corretamente implementados, o valor de link transfere-se totalmente e as classificações tipicamente estabilizam dentro de duas a quatro semanas. Ignorar os redirecionamentos 301 causa perda permanente de classificação para todas as páginas anteriormente indexadas.

E se o meu painel de controlo do WordPress estiver inacessível após mover os ficheiros?

A causa mais comum é uma incompatibilidade entre o valor siteurl na base de dados e a localização real dos ficheiros. Use WP-CLI (wp option update siteurl) ou adicione define('WP_SITEURL', 'https://yourdomain.com'); ao wp-config.php como uma substituição temporária para restaurar o acesso.

Preciso de atualizar wp-config.php após mover o WordPress para a raiz?

Na maioria dos casos, não. O ficheiro wp-config.php usa caminhos relativos para a ligação à base de dados e não codifica o caminho de instalação. A exceção é se ABSPATH foi definido manualmente como um caminho absoluto apontando para o antigo diretório /wordpress — nesse caso, atualize ou remova essa linha.

Por que as imagens ainda estão quebradas após executar o Better Search Replace?

Isto geralmente significa que o plugin foi executado num subconjunto de tabelas e perdeu tabelas de plugins personalizados ou a tabela wp_postmeta. Execute novamente a substituição com todas as tabelas selecionadas, e verifique também os caminhos absolutos do sistema de ficheiros (por exemplo, /public_html/wordpress/wp-content/uploads/) além das strings baseadas em URL.

Como trato disto numa instalação WordPress Multisite?

O Multisite requer constantes adicionais no wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) e os URLs do site da rede devem ser atualizados tanto nas tabelas wp_site como wp_blogs. O procedimento padrão de site único é insuficiente — trate isto como uma migração completa da rede e teste primeiro num clone de staging.