Você troca a estrutura de permalinks e, dias depois, o Search Console começa a encher de 404 com URLs antigas no formato ?p=123. O WordPress até redireciona parte disso sozinho, mas quando você tenta criar uma regra para redirecionar ID para permalink, a regex gananciosa captura coisas que não devia: paginação, feeds, anexos e até parâmetros de rastreamento. O resultado é um efeito colateral pior que o problema original.
O WordPress já resolve isso sozinho?
Na maioria dos casos, sim. Desde que os permalinks amigáveis estejam ativos, o WordPress detecta acessos a ?p=123 e faz um redirecionamento 301 para a URL canônica do post. Isso é comportamento nativo do núcleo, não de plugin.
Portanto, o primeiro passo é testar. Abra uma aba anônima e acesse https://seusite.com/?p=123, trocando 123 por um ID real de post publicado. Observe três coisas:
- Se a URL final é o permalink amigável.
- Se o código de status é 301 (use a aba Network do navegador ou uma ferramenta de header).
- Se o canônico da página aponta para o permalink correto.
Se as três respostas forem positivas, você não precisa de regex nenhuma. O problema pode estar em outro lugar: cache de página servindo HTML antigo, CDN com regra própria ou um plugin de SEO que desativou o redirecionamento canônico. Nesse caso, mexa na causa, não na consequência.
Quando o canônico não cobre e é preciso redirecionar ID para permalink
O redirecionamento nativo falha em cenários específicos. Os mais comuns:
- O post foi excluído e o ID não existe mais.
- A URL antiga tem parâmetros extras, como
?p=123&utm_source=news. - O site migrou de domínio e os links antigos apontam para outro host.
- Um plugin de cache ou firewall intercepta a requisição antes do WordPress processar.
- Você quer redirecionar de
?p=123para uma URL que não é o permalink do próprio post, como uma categoria ou página institucional.
Nesses casos, é preciso criar uma regra explícita. E aqui começa o terreno minado.
Onde colocar a regra: servidor, tema ou plugin
A escolha do lugar muda o desempenho e o risco. Compare:
| Onde | Quando usar | Risco |
|---|---|---|
| Servidor (Nginx/Apache) | Regras fixas, muitos acessos, quer performance | Erro de sintaxe derruba o site inteiro |
| Função no tema (functions.php) | Poucas regras, precisa de lógica condicional | Perde-se ao trocar de tema |
| Plugin de redirecionamento | Não tem acesso a servidor, quer interface visual | Peso extra e conflito com outros plugins |
Se você tem SSH e acesso ao arquivo de configuração do servidor, a regra no Nginx ou Apache é a mais eficiente. Se só tem o painel da hospedagem, o caminho costuma ser um plugin. E se administra vários sites, padronize: manter regras em lugares diferentes vira dívida técnica.
Para quem trabalha com SEO técnico no dia a dia, vale revisar o checklist de SEO técnico para auditar sites WordPress antes de sair criando redirecionamentos soltos.
O erro da regex gananciosa
A receita que circula por aí costuma ser algo como RewriteRule ^\?p=(.*)$ /$1 [R=301,L]. O problema está no (.*): ele captura qualquer coisa depois de ?p=, inclusive 123&feed=rss2, 123&page=2 e 123&attachment_id=456.
Na prática, isso quebra feeds, paginação de comentários e URLs de anexo. O leitor clica em “comentários da página 2” e cai num 404. O leitor de RSS recebe um redirecionamento para uma URL que não serve o feed.
O correto é ancorar a regra apenas no ID numérico e exigir que a URL termine ali. Em Apache, algo como:
RewriteCond %{QUERY_STRING} ^p=(\d+)$
RewriteRule ^$ /?p=%1 [R=301,L]Em Nginx, a lógica é parecida, usando if ($arg_p ~ ^\d+$) e verificando se não há outros argumentos. O ponto central não é a sintaxe exata, é o critério: a regra só deve disparar quando p for o único parâmetro e seu valor for puramente numérico.
Se você precisa de mais controle, uma função no tema consegue verificar o ID, checar se o post existe e montar o destino correto. Isso evita redirecionar para um permalink que também não existe.
Como validar em lote sem derrubar o acesso
Depois de escrever a regra, não a coloque em produção direto. Valide assim:
- Liste de 10 a 20 URLs antigas com
?p=, incluindo casos com&feed,&pagee&attachment_id. - Teste cada uma em ambiente de staging ou com a regra comentada.
- Ative a regra e repita os testes, observando o código de status e o destino final.
- Confirme que acessos sem parâmetro
pcontinuam funcionando normalmente. - Só então replique para os outros sites, um por vez.
Se você administra muitos sites, esse passo vira gargalo. Uma forma de reduzir o risco é aplicar a regra primeiro em um site de teste, medir por alguns dias e só depois padronizar. Vale também checar se o redirecionamento não está criando corrente (301 para 301), o que o Google trata como sinal fraco.
Para não perder de vista o que já foi ajustado em cada site, o SEO incidental no WordPress: o que corrigir sem planejar ajuda a separar o que é urgente do que pode esperar.
Quando NÃO usar essa solução
Nem todo ?p=123 deve ser redirecionado. Evite criar regra quando:
- O ID pertence a um rascunho ou post privado: redirecionar expõe a existência dele.
- O ID é de anexo e você quer mantê-lo acessível para o Google Imagens.
- O parâmetro
pé usado por outro plugin com significado diferente. - A URL antiga tem equivalente exato em outro sistema (fórum, loja), e o redirecionamento quebraria a lógica dele.
Nesses casos, o melhor pode ser deixar o WordPress responder com 404 e tratar o problema na origem, removendo os links antigos.
Erros comuns que aparecem depois
Mesmo com a regra ancorada, alguns problemas surgem:
- Redirecionar tudo para a home, o que o Google interpreta como soft 404.
- Esquecer de testar com cache ativo: o CDN pode servir a resposta antiga por horas.
- Criar regra no servidor e também no plugin, gerando loop.
- Não remover a regra antiga depois de migrar para permalink novo, acumulando camadas.
Por isso, documente o que foi feito. Em seis meses, ninguém lembra por que aquela linha existe.
Prevenção para quem cuida de vários sites
Se o seu trabalho é manter sites de clientes, trate redirecionamento como parte do handover. Ao entregar um site, registre quais URLs antigas existem e como serão tratadas. Isso evita que o cliente crie links quebrados em campanhas futuras.
Vale também monitorar 404 periodicamente. O Search Console mostra as URLs que o Google tentou acessar e não encontrou. Se aparecerem muitas com ?p=, sua regra pode estar incompleta. Para um panorama mais amplo, o artigo sobre WordPress não indexa no Google: o que verificar cobre outros motivos de páginas sumirem do índice.
Quando o volume de sites cresce, manter regras de redirecionamento em cada um vira trabalho manual. O 100% WP centraliza a gestão de vários sites WordPress em um painel só, o que ajuda a verificar de uma vez quais estão com configuração de permalink inconsistente e quais precisam de ajuste.
Quando chamar alguém
Se você não tem acesso ao servidor, não consegue testar em staging ou o site já está com tráfego caindo, pode ser hora de envolver um desenvolvedor. Regex mal escrita em arquivo de configuração derruba o site inteiro, e recuperar o acesso exige editar o arquivo por SSH ou pelo painel da hospedagem. O custo de um erro é alto demais para tentativa e erro em produção.
Fonte: Google Search Central
