Configurar redirecionamentos diretamente no Nginx evita carregar o WordPress e executar PHP apenas para decidir o destino de uma URL. Você pode padronizar o domínio com ou sem www, forçar HTTPS e ajustar a barra final dos links permanentes antes de encaminhar a requisição à aplicação.

Este tutorial separa as quatro combinações de protocolo e host em quatro blocos server. O exemplo usa siterapidowp.com.br como domínio preferido: primeiro HTTP vira HTTPS no mesmo host; depois o www é removido; somente no HTTPS canônico a barra final é tratada. Adapte caminhos e certificados à sua instalação.

Nginx, Cloudflare ou plugin: onde redirecionar?

O Nginx recebe a requisição no servidor e pode responder sem acionar o PHP. Isso reduz o trabalho da aplicação, embora a conexão ainda chegue à hospedagem. O ganho de tempo depende do ambiente; não existe uma economia fixa para qualquer site.

Se o tráfego já passa pelo proxy da Cloudflare, regras resolvidas na borda podem evitar inclusive essa consulta à origem. Veja o tutorial de redirecionamento na borda da Cloudflare.

O plugin Redirection para WordPress continua útil para mudanças editoriais e investigação de erros 404. A escolha depende do que a regra precisa saber: host, protocolo e caminho são informações disponíveis no Nginx; dados internos do WordPress podem exigir a aplicação.

Antes de configurar, alinhe o WordPress

Confira em Configurações → Geral os endereços do WordPress e do site. Eles devem usar o protocolo e o host desejados, respeitando casos em que a instalação fica em um subdiretório.

Em Configurações → Links permanentes, identifique o padrão das páginas:

Estrutura de exemplo Política correspondente
/%postname%/ Adicionar barra final nos links permanentes
/%postname% Remover barra final dos links permanentes

O WordPress também faz correções de URL por meio de redirect_canonical e aplica a preferência de barra em user_trailingslashit. Não configure o Nginx para desfazer o padrão que a aplicação gera.

Os exemplos assumem WordPress instalado na raiz, com links permanentes amigáveis, e Nginx recebendo diretamente as conexões HTTP e HTTPS. Multisite, instalações em subpastas e estruturas com extensões precisam de adaptação.

Tenha os dois nomes configurados no DNS e um certificado válido para siterapidowp.com.br e www.siterapidowp.com.br. Na requisição HTTPS, o certificado é apresentado antes de o navegador receber o redirect.

Como organizar a configuração

O modelo usa duas partes:

  1. Um map, no contexto http, calcula a preferência de barra.
  2. Quatro blocos server separam HTTP/HTTPS e os hosts com e sem www.

São quatro blocos, mas não quatro redirects obrigatórios: o HTTPS canônico serve o site e só redireciona quando precisa ajustar a barra. Os outros três preservam caminho e parâmetros.

Por que passar pelo HTTPS do mesmo host?

A orientação de TLS da MDN recomenda que uma entrada HTTP alcance primeiro o mesmo recurso em HTTPS, antes de uma troca de domínio. Isso permite ao navegador receber a política HSTS desse host. Essa ordem também aparece nos requisitos de HSTS preload.

Com o domínio sem www como preferido, o caminho é:

http://www.siterapidowp.com.br/caminho
→ https://www.siterapidowp.com.br/caminho
→ https://siterapidowp.com.br/caminho
→ https://siterapidowp.com.br/caminho/

O último salto só existe quando a barra precisa de ajuste. Aqui, a separação das etapas é intencional; o objetivo não é resolver todas as variações em um único redirect. HSTS é uma política enviada por cabeçalho HTTPS, não uma exigência de quantidade de blocos Nginx.

Escolha somente uma das versões do mapa de barra a seguir. O segundo mapa limita essa mudança de caminho a GET e HEAD.

Os blocos map devem ficar dentro de http { ... }, fora de qualquer server ou location. É comum o nginx.conf incluir arquivos de conf.d nesse contexto; confira a estrutura usada na sua instalação. A documentação do módulo map descreve esse funcionamento.

Opção A: adicionar barra final

Salve, por exemplo, como /etc/nginx/conf.d/wordpress-canonical-map.conf, se essa pasta for incluída dentro de http:

map $request_uri $wp_normalized_uri {
    default $request_uri;

    # A raiz permanece como está, inclusive com query string.
    ~^/(?:\?|$) $request_uri;

    # Rotas especiais não recebem normalização de barra.
    ~^/(?:wp-admin|wp-json|wp-content|wp-includes|api|checkout|cart|my-account|wc-api)(?:/|\?|$) $request_uri;

    # Heurística: não modificar caminhos com ponto.
    ~^[^?]*\. $request_uri;

    # Acrescentar a barra antes da query string.
    ~^(?<wp_path_add>/[^?]*[^/?])(?<wp_query_add>\?.*)?$ $wp_path_add/$wp_query_add;
}

map $request_method $wp_canonical_uri {
    default $request_uri;
    GET $wp_normalized_uri;
    HEAD $wp_normalized_uri;
}

Exemplo de transformação:

/post-exemplo?origem=email
→ /post-exemplo/?origem=email

O teste de ponto é uma heurística, não uma descoberta do tipo de arquivo: também ignora páginas como /versao-1.2. A lista de exceções deve incluir os endpoints específicos dos seus plugins e integrações. O caminho /.well-known/ fica fora da alteração por conter ponto.

Opção B: remover barra final

Para usar links permanentes sem barra, substitua o primeiro mapa pela versão abaixo. Mantenha o mapa de métodos exatamente como na opção A:

map $request_uri $wp_normalized_uri {
    default $request_uri;

    ~^/(?:\?|$) $request_uri;
    ~^/(?:wp-admin|wp-json|wp-content|wp-includes|api|checkout|cart|my-account|wc-api)(?:/|\?|$) $request_uri;
    ~^[^?]*\. $request_uri;

    # Remover uma barra final, preservando a query string.
    ~^(?<wp_path_remove>/[^?]*[^/])/(?<wp_query_remove>\?.*)?$ $wp_path_remove$wp_query_remove;
}

Exemplo:

/post-exemplo/?origem=email
→ /post-exemplo?origem=email

A raiz / permanece intacta. Não misture esse mapa com o de adicionar barra.

Os quatro blocos server

Integre os blocos à configuração do site sem duplicar virtual hosts já existentes. Eles assumem que o Nginx recebe diretamente HTTP e HTTPS. Ajuste os caminhos dos certificados e da raiz; preserve no bloco final os location de PHP, cache e segurança da instalação.

1. HTTP sem www: HTTPS no mesmo host

server {
    listen 80;
    server_name siterapidowp.com.br;

    return 308 https://siterapidowp.com.br$request_uri;
}

Esse bloco não altera host nem barra. $request_uri já inclui caminho e parâmetros.

2. HTTP com www: HTTPS no mesmo host

server {
    listen 80;
    server_name www.siterapidowp.com.br;

    return 308 https://www.siterapidowp.com.br$request_uri;
}

Uma entrada HTTP com www não vai diretamente para o domínio sem www: primeiro recebe a versão HTTPS do próprio host.

3. HTTPS com www: domínio HTTPS preferido

server {
    listen 443 ssl;
    server_name www.siterapidowp.com.br;

    ssl_certificate /etc/letsencrypt/live/siterapidowp.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/siterapidowp.com.br/privkey.pem;

    add_header Strict-Transport-Security "max-age=300" always;

    return 308 https://siterapidowp.com.br$request_uri;
}

A resposta HTTPS intermediária também envia HSTS. O caminho permanece intacto, inclusive se estiver sem a barra final.

4. HTTPS sem www: servir o site e tratar a barra

server {
    listen 443 ssl;
    server_name siterapidowp.com.br;

    root /var/www/siterapidowp.com.br/public;

    ssl_certificate /etc/letsencrypt/live/siterapidowp.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/siterapidowp.com.br/privkey.pem;

    add_header Strict-Transport-Security "max-age=300" always;

    set $wp_target_uri $wp_canonical_uri;

    # Não alterar a barra de arquivos ou diretórios existentes.
    if (-e $request_filename) {
        set $wp_target_uri $request_uri;
    }

    if ($request_uri != $wp_target_uri) {
        return 301 https://siterapidowp.com.br$wp_target_uri;
    }

    # Mantenha aqui os locations existentes do WordPress e do PHP.
}

Somente esse bloco usa o resultado dos mapas. Com a opção de adicionar barra, a navegação abaixo recebe 301:

https://siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx
→ https://siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx/

O endereço já terminado em / segue para o conteúdo sem redirect destas regras. No WordPress, escolha o mapa de acordo com os links permanentes reais; os endereços acima ilustram o padrão do Site Rápido WP.

O teste de existência depende de uma root correta. O if mostrado usa apenas set e return, sem alterar a escolha de location. Consulte as diretivas if e return do Nginx antes de ampliar a lógica.

HSTS: comece com prazo curto e confira os cabeçalhos

O valor max-age=300 é um exemplo inicial de cinco minutos para validar a implantação. Aumente o prazo conforme a política do site depois de confirmar o funcionamento. O cabeçalho deve aparecer nas respostas HTTPS do host intermediário e do host final, inclusive nos redirects; ele não é enviado nos blocos HTTP.

Se um location define seus próprios add_header, confira a herança na versão e configuração do Nginx e garanta que HSTS continue presente. Preserve também os demais cabeçalhos de segurança existentes. Veja a documentação de add_header.

includeSubDomains amplia a política para subdomínios e exige que eles suportem HTTPS. preload é uma decisão adicional com requisitos e consequências próprios, não habilitada neste exemplo. Os quatro blocos, sozinhos, não tornam o domínio elegível para preload.

E se o domínio preferido usar www?

Os dois blocos HTTP continuam redirecionando para HTTPS no próprio host. Inverta apenas os papéis dos blocos HTTPS:

  • O bloco HTTPS de siterapidowp.com.br envia HSTS e retorna 308 https://www.siterapidowp.com.br$request_uri.
  • O bloco HTTPS de www.siterapidowp.com.br serve o site e trata a barra. No return 301 dele, use https://www.siterapidowp.com.br$wp_target_uri.

Mantenha certificados válidos nos dois hosts e HSTS nos dois blocos HTTPS. Escolha o mapa de adicionar ou remover barra conforme o WordPress; a barra continua sendo corrigida apenas no host HTTPS final.

Por que usar 308 e 301 neste exemplo?

O código 308 é permanente e preserva o método HTTP nas trocas de protocolo ou host. A política de barra só atua em GET e HEAD e usa 301.

Durante testes, use os equivalentes temporários 307 e 302, respectivamente, se precisar evitar o armazenamento de redirects permanentes pelos clientes. Mesmo preservando método, teste formulários, autenticação e integrações no host correto; o ideal é eles já utilizarem a URL final.

Como manter o encaminhamento para o WordPress

As regras de redirecionamento não substituem o encaminhamento dos links permanentes para o PHP. No location / existente, uma estrutura comum é:

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

Ela procura arquivos e diretórios e encaminha os demais caminhos ao front controller. Preserve o bloco FastCGI/PHP já configurado e as regras de segurança. Confira a documentação do WordPress com Nginx para o contexto de instalação.

Os mapas usam $request_uri para preservar o caminho original e sua query string. Isso evita confundir a navegação original com o caminho interno /index.php usado durante o processamento. Não acrescente $is_args$args ao destino mostrado: os parâmetros já fazem parte da variável calculada.

Diretórios reais merecem atenção: o próprio Nginx pode acrescentar barra para servi-los. O teste -e mantém esses caminhos fora da normalização de barra do exemplo, evitando a disputa entre remover uma barra e adicioná-la de novo. Aliases e mapeamentos de arquivos personalizados precisam de avaliação própria.

Exemplos de teste para as quatro entradas

Com a combinação sem www e com barra, use um caminho publicado. A tabela mostra apenas o próximo passo de cada resposta:

Entrada Próximo resultado esperado
http://siterapidowp.com.br/caminho 308 para https://siterapidowp.com.br/caminho
http://www.siterapidowp.com.br/caminho 308 para https://www.siterapidowp.com.br/caminho
https://www.siterapidowp.com.br/caminho 308 para https://siterapidowp.com.br/caminho, com HSTS na resposta
https://siterapidowp.com.br/caminho 301 para https://siterapidowp.com.br/caminho/, com HSTS
https://siterapidowp.com.br/caminho/ Conteúdo sem redirect destas regras, com HSTS

Para remover barra, inverta somente a correção do caminho no bloco HTTPS final. Uma entrada HTTP nunca deve ter a barra alterada pelos dois blocos da porta 80.

Confira as quatro combinações do exemplo solicitado:

curl -I 'http://siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx'
curl -I 'https://siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx'
curl -I 'http://www.siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx'
curl -I 'https://www.siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx'

Para acompanhar o caminho inteiro e conferir a preservação de parâmetros:

curl -sSIL --max-redirs 10 \
  -o /dev/null \
  -w 'redirects=%{num_redirects} final=%{url_effective}\n' \
  'http://www.siterapidowp.com.br/nginx/como-instalar-8g-firewall-nginx?origem=teste'

Nesse modelo, sem uma política HSTS previamente aplicada pelo cliente, a entrada HTTP com www e sem barra pode produzir três redirects: protocolo, host e barra. Já o HTTPS sem www e com barra não precisa de nenhum. No navegador, HSTS já conhecido pode atualizar o protocolo internamente antes da requisição; isso não é a mesma coisa que receber um redirect do servidor.

Confira também arquivos, diretórios reais, wp-admin, wp-json, APIs, formulários POST e rotas dos plugins. A normalização de barra continua restrita a GET/HEAD e às rotas abrangidas pelo mapa. Um 404 no final ainda pode significar que o conteúdo não existe, mesmo com redirects corretos.

Este modelo de quatro blocos foi validado em Nginx local isolado, com 68 casos e suas cadeias, incluindo as duas preferências de host e as duas políticas de barra. Os testes conferiram HSTS nos dois hosts HTTPS e sua ausência no HTTP. A aplicação foi simulada; o comportamento do WordPress e das integrações reais deve ser conferido na instalação.

Como aplicar e evitar loops

Salve uma cópia da configuração anterior, confira os caminhos e valide a sintaxe antes de recarregar:

sudo nginx -t

Se o teste passar, recarregue pelo método usado no seu servidor. Por exemplo, em instalações gerenciadas por systemd:

sudo systemctl reload nginx

Veja a diferença entre restart e reload do Nginx se precisar identificar o comando adequado ao ambiente. O teste de sintaxe não comprova o comportamento do WordPress: valide depois as URLs, os formulários e os endpoints reais.

Se ocorrer um loop ou um segundo salto inesperado, confira:

  • O padrão de barra dos links permanentes e o host configurado no WordPress.
  • Regras do plugin Redirection, da hospedagem e de outros blocos server.
  • Diretórios reais, arquivos e endpoints que precisam de exceção.
  • Cache de redirects no navegador, na origem ou na CDN.
  • Se o destino já usa o caminho e a URL canônica corretos.

Para atualizar URLs gravadas no conteúdo, o redirect sozinho não basta: consulte os guias de migração para HTTPS e troca de domínio com WP-CLI.

E quando há Cloudflare ou outro proxy na frente?

Os quatro blocos pressupõem que as conexões chegam às portas HTTP e HTTPS correspondentes. Se outro proxy termina TLS e acessa a origem por HTTP, ela pode responder repetidamente com redirect para HTTPS, criando um loop.

Com Cloudflare, prefira uma conexão adequada até a origem, como Full (strict) com certificado válido, e alinhe as regras das duas camadas. Em outras arquiteturas, reconheça cabeçalhos encaminhados somente por proxies confiáveis; não copie um teste de X-Forwarded-Proto sem essa configuração de confiança.

Se a Cloudflare responder antes do Nginx, a ordem observada será a definida na borda. Para manter este modelo, configure nela a mesma sequência de HTTPS no próprio host antes da troca de domínio. Evite que uma camada adicione www ou barra enquanto outra os remove.