Redirecionamentos curinga: como funcionam e como configurá-los

Um redirecionamento curinga é uma única regra que corresponde a muitas URLs por padrão e as envia para outro lugar. Em vez de listar 4.000 endereços antigos um por um, você escreve algo como “tudo em /blog/ vai para o mesmo caminho no novo domínio” e deixa o servidor fazer o resto. Este guia aborda os dois significados que as pessoas confundem (curingas de DNS e redirecionamentos HTTP), padrões funcionais para Apache e NGINX, os erros de SEO que custam posições e quando uma camada de redirecionamento gerenciada é a melhor escolha.

O que um redirecionamento curinga realmente é#

A palavra “curinga” abrange três coisas diferentes, e os resultados de pesquisa as misturam livremente.

Redirecionamentos curinga (por padrão). Uma regra com um espaço reservado. O espaço reservado pode significar “quaisquer caracteres após este ponto” (uma correspondência de prefixo), “quaisquer caracteres antes deste ponto” (uma correspondência de sufixo) ou um segmento capturado que é reutilizado no destino. Exemplos típicos: /old-blog/* para /blog/*, ou *.olddomain.com para newdomain.com.

Registros DNS curinga. Um registro com um asterisco no rótulo mais à esquerda, como *.example.com, responde a consultas de subdomínios que não têm registro próprio. AWS documenta como os asteriscos funcionam nos nomes de registro^[1], e o ponto principal para este tema é que o DNS apenas decide qual servidor responde. O redirecionamento em si é uma operação HTTP que acontece após a resolução de DNS, no servidor que recebe a solicitação.

Proibição de curingas no nível do registrador. O terceiro uso diz respeito aos registradores de domínios de nível superior: os operadores estão proibidos de sintetizar respostas para domínios inexistentes. Isso é uma regra para registradores, não algo que você configura no seu próprio site.

Portanto, uma configuração completa de curinga para subdomínios geralmente precisa de duas camadas: um registro DNS curinga para que cada subdomínio chegue ao seu servidor e uma regra no lado do servidor que decide para onde cada solicitação deve ir.

Os padrões que você realmente vai usar#

A maioria das necessidades do mundo real se enquadra em seis padrões.

A diferença entre as duas primeiras linhas é a que mais importa. Preservar o caminho mantém a relevância um a um, o que é o ideal quando o novo site espelha o antigo. Remover o caminho só é correto quando não existem páginas equivalentes.

Redirecionamentos curinga no Apache (.htaccess)#

Uma pergunta comum é como redirecionar tudo após um determinado caminho por meio de .htaccess. No Apache, essa é a função de mod_rewrite. A documentação do Apache mod_rewrite^[2] descreve RewriteRule e as flags que a acompanham, incluindo R para redirecionamento.

Um redirecionamento de prefixo que mantém o restante do caminho:

<code class="language-apache">RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
</code>

Os parênteses capturam tudo após old-section/, e $1 o insere no destino. L interrompe o processamento de regras posteriores, o que evita correspondências duplas acidentais.

Um redirecionamento de domínio inteiro que mantém os caminhos e as strings de consulta:

<code class="language-apache">RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</code>

Algumas coisas costumam confundir as pessoas:

• A ordem importa. As regras são executadas de cima para baixo. Coloque as regras específicas acima das gerais, ou a regra coringa capturará tudo.
• Escape os pontos. Um . não escapado em uma regex corresponde a qualquer caractere.
• Teste primeiro com um 302. Os navegadores armazenam em cache 301s de forma agressiva. Use R=302 durante os testes e, depois, mude para 301 quando a regra estiver funcionando.
• Preste atenção ao servidor. .htaccess funciona apenas no Apache. Se o seu host executa NGINX, o arquivo é ignorado.

Redirecionamentos curinga no NGINX#

O NGINX lida com nomes de host por meio de server_name. O guia do servidor web NGINX^[3] explica que um nome de servidor pode ser um nome exato, um curinga com um asterisco no início ou no fim, ou uma expressão regular, e que os nomes exatos têm prioridade sobre os curingas quando vários correspondem.

Redirecione cada subdomínio de um domínio antigo para o novo:

<code class="language-nginx">server {
    listen 80;
    server_name .old-domain.com;
    return 301 https://new-domain.com$request_uri;
}
</code>

O ponto inicial corresponde tanto a old-domain.com quanto a qualquer subdomínio. $request_uri carrega o caminho e a string de consulta originais, então os links profundos são preservados.

Para um prefixo de caminho dentro de um site:

<code class="language-nginx">location ~ ^/old-section/(.*)$ {
    return 301 /new-section/$1;
}
</code>

Prefira return em vez de rewrite para redirecionamentos simples. É mais claro e mais barato de avaliar.

Escolhendo o código de status#

O código que você retorna diz aos navegadores e aos mecanismos de busca como tratar a mudança.

• 301 (Movido Permanentemente) e 308 (Redirecionamento Permanente) indicam que o recurso tem um novo endereço permanente. A referência do MDN para 301^[4] descreve navegadores seguindo o cabeçalho Location automaticamente.
• 302 e 307 são temporários. Use-os para testes A/B, promoções de curto prazo ou páginas de manutenção.

A orientação do Google é que redirecionamentos permanentes ajudam a consolidar URLs duplicadas e sinalizam que a nova URL deve ser indexada^[5], enquanto redirecionamentos temporários mantêm a prioridade de indexação da página de origem. Se a mudança for de longo prazo, use um código permanente. Uma regra curinga deixada em 302 após uma migração é um erro silencioso e comum.

O que o tráfego da RedirHub mostra sobre códigos permanentes e temporários#

Em uma amostra de seis horas das solicitações de redirecionamento que a edge da RedirHub atendeu em 22 de outubro de 2026, 42,2% vieram de bots. Das solicitações feitas por pessoas, 82,3% receberam um 301 ou 308, 1,3% um 302 ou 307, e menos de 0,03% um erro (4xx ou 5xx).

Os códigos permanentes dominam, então uma regra curinga ainda em código temporário após uma migração se destaca como a exceção a ser auditada. As participações contam apenas pessoas (bots excluídos), vêm do registro de acesso de redirecionamento em vez de uma pesquisa e deixam de fora as maiores contas para que nenhum cliente isolado as distorça. No RedirHub, redirecionamentos de domínio com 301, 302, 307 e 308 estão incluídos no Core, Pro e Enterprise, enquanto redirecionamentos curinga de subdomínio estão incluídos apenas no Pro e Enterprise.

Erros de SEO que regras curinga tornam fáceis#

Como uma regra afeta milhares de URLs, uma regra errada danifica milhares de páginas de uma só vez.

Enviar tudo para a página inicial#

A opção genérica preguiçosa, /* para /, parece organizada e perde relevância. Um visitante que clicou em um link para um guia específico cai em uma página inicial genérica e sai. Os mecanismos de busca também podem tratar redirecionamentos em massa para uma página irrelevante como um soft 404. Redirecione para a equivalente mais próxima e use uma categoria pai mais ampla apenas quando não existir equivalente.

Criar cadeias#

Digamos que http://old.com/page redirecione para https://old.com/page, que redireciona para https://www.old.com/page, que redireciona para https://new.com/page. Isso são três saltos. A documentação do Google observa que o Googlebot pode seguir um número limitado de saltos e que redirecionamentos diretos são preferíveis^[5], porque cadeias acrescentam latência e podem tornar a indexação mais lenta. Escreva a regra para que a primeira resposta já aponte para a URL final, com protocolo, host e caminho corrigidos de uma vez.

Esquecer a string de consulta e os fragmentos#

Parâmetros de campanha, como tags UTM, muitas vezes acompanham links antigos. Verifique se sua regra preserva a string de consulta quando você quiser isso. No Apache, um redirecionamento para uma URL absoluta carrega a string de consulta original, a menos que você diga o contrário, como explica a documentação do Apache. No NGINX, $request_uri a inclui, enquanto $uri não.

Confundir www e não-www#

Escolha um host canônico e redirecione o outro para ele. A orientação do Google sobre a consolidação de URLs duplicadas^[6] lista redirecionamentos como um forte sinal da sua versão preferida, e qualquer uma das opções está bem, desde que você mantenha a consistência. Se precisar de um passo a passo, nossa nota sobre redirecionar de não-www para www cobre isso.

Removendo regras cedo demais#

O Google diz que redirecionamentos podem ser tratados como um sinal de canonização, e não como uma ordem absoluta, e que ainda pode escolher um canônico diferente com base em outros fatores, como explica a sua documentação sobre canonização^[7]. Na prática, mantenha redirecionamentos permanentes ativos por pelo menos um ano após uma mudança, e por mais tempo para URLs que ainda recebem links externos.

Um processo seguro para uma migração com curingas#

1. Faça o inventário das URLs antigas. Extraia-as do seu sitemap, dos logs do servidor, das análises e de um rastreamento. A documentação do Google sobre mudança de site^[8] enfatiza mapear cada URL antiga para seu novo destino.
2. Agrupe-as por padrão. A maioria dos sites se resume a algumas poucas regras com curingas, além de uma lista menor de exceções pontuais.
3. Escreva as exceções primeiro. Os mapeamentos individuais devem ficar acima das regras com curinga para que prevaleçam.
4. Teste com URLs reais. Execute uma amostra de várias centenas de URLs antigas, incluindo as mais incomuns, e verifique o código de status, o destino final e o número de redirecionamentos. Um verificador de redirecionamento mostra cada etapa e o código de status para uma única URL.
5. Lance com códigos permanentes. Mude de 302 para 301 assim que os testes passarem.
6. Monitore. Observe erros de rastreamento, 404s e tráfego por seção durante semanas. Corrija lacunas com novas regras, não editando as antigas às pressas.

O Google também observa que sites grandes podem mudar em etapas para testar o impacto, enquanto sites menores geralmente se saem melhor ao mover tudo de uma vez. Para o planejamento da parte do domínio, o nosso guia de mudança de domínio para SEO cobre o que verificar antes e depois da troca.

Onde os arquivos do servidor deixam de ser práticos#

Editar .htaccess ou uma configuração do NGINX é aceitável para um único site que você controla. Isso fica doloroso quando:

• Você possui dezenas de domínios, alguns estacionados, outros legados, outros comprados para uma campanha.
• O marketing precisa बदलar um destino, mas as alterações exigem um desenvolvedor e uma implantação.
• Seu site roda em uma plataforma sem acesso à configuração do servidor.
• As regras de redirecionamento vivem em quatro lugares (CMS, CDN, servidor, registrador) e ninguém sabe qual delas prevalece.

A ordem também importa. Como explica a MDN^[9], o redirecionamento é acionado pelo servidor ao enviar uma resposta 3xx com um cabeçalho Location, portanto acontece antes de qualquer conteúdo da página ser enviado. Truques do lado do cliente, como JavaScript ou meta refresh, são um último recurso quando você não consegue الوصول à camada do servidor. Uma camada dedicada de redirecionamento mantém você no nível correto sem exigir acesso ao servidor.

A velocidade é o outro custo de sair da camada do servidor, e ele é pequeno: o tempo médio até o primeiro byte do RedirHub foi de 18 ms, contra 11 ms do mais rápido entre 26 provedores, medido a partir de Washington, D.C., Frankfurt e Tóquio (Benchmark de velocidade de redirecionamento do RedirHub, 18–25 de outubro de 2026^[10]).

Nossa perspectiva#

A maior parte dos problemas de redirecionamento que vemos não é sobre sintaxe. É sobre propriedade. Uma regra é escrita uma vez por quem estava no projeto, fica em um arquivo de configuração e, anos depois, ninguém se lembra por que /promo/* aponta para onde aponta. Então um domínio expira, um folheto impresso ou um código QR continua levando as pessoas para uma página morta, e a correção exige um ticket.

Construímos a RedirHub com base na ideia de que links e redirecionamentos devem ficar no seu próprio domínio e sob o seu controlo, com o SSL tratado por si, em vez de depender de um encurtador partilhado ou de um conjunto de ficheiros no servidor. O nosso conselho para regras curinga é o mesmo, qualquer que seja a ferramenta que use: escreva o padrão mais restrito que resolva o problema, aponte-o diretamente para o URL final, mantenha uma lista de exceções e reveja as regras periodicamente. Trate os redirecionamentos como ativos de longo prazo, porque os links no mundo real vão sobreviver ao design atual do seu site.

Gerir redirecionamentos curinga e de domínio sem ficheiros de configuração#

A RedirHub permite-lhe gerir redirecionamentos de domínio e links com marca nos seus próprios domínios, com SSL e análises, e alterar destinos sem tocar em materiais impressos. Se estiver a migrar um site, o nosso serviço de migração de websites e o serviço de redirecionamento 301 para migrações SEO foram criados para essa tarefa. Os planos estão publicados na página de preços: o Core custa 49 $ por mês e o Pro custa 119 $ por mês. O Enterprise é definido por contrato. Os redirecionamentos curinga de subdomínio (redirecionamentos de subdomínio genéricos) estão incluídos apenas no Pro e no Enterprise, enquanto os redirecionamentos de domínio, o encaminhamento de caminhos e o encaminhamento de parâmetros de consulta estão incluídos no Core, no Pro e no Enterprise.

Referência rápida: DNS curinga versus redirecionamento curinga#

Mais um detalhe de DNS para configurações com vários domínios: um CNAME não pode ficar no apex da zona (o example.com sem o prefixo), enquanto alguns provedores oferecem registros no estilo alias que podem. A AWS descreve isso em sua comparação entre registros alias e não alias^[11]. Se você apontar domínios sem prefixo para um serviço de redirecionamento, verifique qual tipo de registro seu provedor de DNS suporta no apex.

Exemplo prático: uma mudança de marca com três subdomínios#

Imagine uma empresa mudando de acme-tools.com para acme.com. Ela tem um blog, um site de suporte em help.acme-tools.com e alguns subdomínios regionais, como uk.acme-tools.com.

Um plano limpo fica assim:

1. Adicione um registo DNS curinga no domínio antigo para que qualquer subdomínio, incluindo os que ninguém se lembra, chegue à camada de redirecionamento.
2. Crie primeiro regras explícitas: help.acme-tools.com/* para support.acme.com/*, e uk.acme-tools.com/* para acme.com/uk/*.
3. Adicione uma regra geral: *.acme-tools.com/* para acme.com/*, como fallback.
4. Adicione a regra da raiz: acme-tools.com/* para acme.com/*.
5. Retorne 301 para todas elas, com HTTPS no destino para que haja apenas um salto.
6. Teste 200 URLs antigas do sitemap e da análise, depois verifique-as novamente após uma semana.

As regras explícitas protegem as secções com estruturas diferentes, e o fallback apanha os casos isolados. Sem a ordem, o fallback aplanaria o site de suporte dentro dos caminhos do domínio principal, onde nada corresponde.