--- title: "SEO técnico começa na resposta do servidor" id: "653" type: "post" slug: "seo-tecnico-comeca-na-resposta-do-servidor" published_at: "2026-10-06T20:22:46+00:00" modified_at: "2026-10-06T20:22:46+00:00" url: "https://danielpazwp.com/pt/seo-tecnico-comeca-na-resposta-do-servidor/" markdown_url: "https://danielpazwp.com/pt/seo-tecnico-comeca-na-resposta-do-servidor.md" excerpt: "Códigos de status, redirecionamentos, canonicals e orçamento de rastreamento vêm antes de qualquer plugin. Comece pelo que o servidor entrega ao crawler." taxonomy_category: - "SEO" --- [SEO](https://danielpazwp.com/pt/category/seo-pt/) 6 min de leitura # SEO técnico começa na resposta do servidor Códigos de status, redirecionamentos, canonicals e orçamento de rastreamento vêm antes de qualquer plugin. Comece pelo que o servidor entrega ao crawler. Publicado **06/10/2026**6 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) O SEO técnico começa na resposta do servidor porque o crawler decide o que fazer com uma URL antes de ler uma única palavra do conteúdo. O código de status HTTP diz se a página existe, mudou de lugar ou falhou. Os redirecionamentos dizem para onde a autoridade deve ir. O canonical, as diretivas de robots e o HTML da primeira resposta dizem o que indexar. E o tempo de resposta influencia quanto do site é rastreado. Se esses sinais estão errados, nenhuma otimização on-page resolve, e os crawlers de IA, que leem só o HTML bruto e não executam JavaScript, perdoam ainda menos. ## O que o crawler vê primeiro? Quando o Googlebot ou qualquer outro robô pede uma URL, ele recebe três coisas antes de tudo: um código de status, um conjunto de cabeçalhos e um corpo. Quase todo trabalho de SEO foca no corpo. Quase todos os problemas que encontro em auditoria estão nos dois primeiros. Se o código de status diz que a página não existe mais, o crawler nunca vê o seu design, os seus sliders ou aquela introdução escrita com cuidado. Se os cabeçalhos e o HTML discordam sobre o canonical, ele pode indexar a versão errada. Então leia a resposta como um robô lê: com `curl -I`, com a aba Network ou com um crawler como o Screaming Frog. O navegador esconde tudo isso atrás da página renderizada. ## Códigos de status são as primeiras instruções do SEO técnico Cada código de status diz aos buscadores o que fazer com uma URL. Mande o código errado e o crawler segue a instrução errada. | Código | O que diz ao crawler | Erro comum no WordPress | | --- | --- | --- | | 200 | A página existe; pode considerar indexar | Devolver 200 para páginas “não encontradas” (soft 404) | | 301 / 308 | Mudou de vez; transfira os sinais para a nova URL | Usar 302 em mudanças permanentes | | 302 / 307 | Mudança temporária; não esqueça a URL antiga | Deixar redirecionamentos temporários no ar por anos | | 404 / 410 | Não existe mais; tire do índice com o tempo | Redirecionar todo 404 para a home | | 503 | Indisponível no momento; volte depois | Modo de manutenção que devolve 200 com uma página de “já voltamos” | Dois desses merecem mais atenção. O primeiro é o soft 404: uma busca interna vazia, uma página de produto apagada ou uma categoria sem posts que devolve 200 quase sem conteúdo. O Google muitas vezes classifica essas páginas como soft 404 de qualquer forma, mas aí você já desperdiçou rastreamento e criou ruído. O segundo é a manutenção. Um 503 com o cabeçalho `Retry-After` avisa os crawlers que a queda é temporária. Uma página de manutenção com 200 avisa que o seu site inteiro virou uma frase. ## Redirecionamentos: cadeias, loops e para onde vai a autoridade Um redirecionamento permanente avisa os buscadores que a URL tem um novo endereço. Feito do jeito certo, num salto só do antigo para o novo, os sinais se concentram no destino. Feito do jeito errado, nascem as cadeias. Em sites WordPress as cadeias se acumulam sem ninguém perceber. HTTP vai para HTTPS, depois sem www vai para com www, depois o slug antigo vai para o novo, depois para a versão com barra no final. São quatro saltos para uma URL. O Googlebot segue até dez, mas cada salto custa uma requisição, aumenta a latência para o usuário e aumenta a chance de algo quebrar no caminho. - Redirecione direto para a URL final, num salto. - Use 301 ou 308 em mudanças permanentes, não 302. - Atualize os links internos para apontar para o destino, assim você nem depende do redirecionamento. - Sempre que der, faça os redirecionamentos no servidor ou na borda, antes de o WordPress carregar, e não por um plugin que sobe a stack inteira primeiro. Numa migração isso vira o centro do projeto. Detalho o processo em [como migrar o WordPress sem perder posições](https://danielpazwp.com/pt/migrar-wordpress-sem-perder-posicoes/) . ## Canonical e sinais de robots precisam concordar A tag canonical é uma sugestão, não uma ordem. O Google pesa a tag junto com outros sinais: redirecionamentos, links internos, sitemaps, hreflang. Quando eles discordam, o Google escolhe o próprio canonical, e talvez não seja o que você queria. Na prática, tudo se resume a consistência. A URL do canonical deve devolver 200, não redirecionar. Deve ser a URL que você usa nos links internos e lista no sitemap, e não pode estar bloqueada no robots.txt nem marcada com noindex. Também dá para mandar o canonical como cabeçalho HTTP `Link`, o que ajuda com PDFs e outros arquivos que não são HTML. Pelo mesmo motivo, o noindex pode sair como cabeçalho `X-Robots-Tag`. > Buscadores não indexam o que você quis dizer. Indexam o que o servidor disse. ## TTFB também é problema de SEO Tempo até o primeiro byte é o intervalo entre a requisição e o primeiro byte da resposta. A orientação do web.dev considera bom um [TTFB](https://danielpazwp.com/pt/ttfb-no-wordpress/) de 0,8 segundo ou menos no percentil 75. Ele não é um Core Web Vital, mas fica embaixo de todos: um primeiro byte lento atrasa tudo o que vem depois, incluindo o LCP. Ele afeta o rastreamento também. O Google ajusta quanto rastreia de acordo com a resposta do servidor. Um host que responde rápido e de forma estável pode ser mais rastreado, e um que fica lento ou solta erros 5xx é rastreado menos. Num site pequeno isso quase não pesa. Num catálogo grande de WooCommerce ou num portal de notícias que publica todo dia, define a velocidade com que páginas novas e atualizadas são descobertas. No WordPress, as correções são as mesmas de qualquer auditoria de performance: page cache funcionando, object cache persistente para as requisições que não vão para o cache, tabela de options limpa, e menos plugins fazendo trabalho pesado em toda requisição. ## HTML renderizado no servidor para buscadores e crawlers de IA O Google consegue renderizar JavaScript, mas faz isso numa segunda etapa que pode acontecer bem depois do rastreamento inicial. Conteúdo que só aparece depois que os scripts rodam é indexado mais tarde, e às vezes não do jeito que você esperava. Os crawlers de IA são mais rígidos. Os robôs que coletam conteúdo para assistentes de IA e mecanismos de resposta, como GPTBot, ClaudeBot e PerplexityBot, em geral buscam o HTML e não executam JavaScript. Se o conteúdo principal, os títulos, os preços ou as perguntas frequentes são injetados no navegador, esses sistemas não os veem, e não dá para citar algo que nunca esteve na resposta. O WordPress sai na frente aqui, porque por padrão renderiza o HTML no servidor. O risco vem do que se coloca por cima: page builders que carregam conteúdo via AJAX, abas e acordeões preenchidos por script, ou front ends headless que entregam uma casca vazia. Um teste rápido que eu faço: buscar a URL com `curl` e procurar na saída o título principal e um parágrafo importante. Se eles não estão lá, os crawlers que não renderizam JavaScript nunca vão encontrá-los. Então acerte a resposta primeiro: status correto, um redirecionamento limpo, canonical consistente, primeiro byte rápido e conteúdo de verdade no HTML. O resto do trabalho de SEO se apoia nisso. Se quiser ver como trato essa base em projetos, a página de [SEO técnico](https://danielpazwp.com/pt/seo-tecnico/) explica o escopo. [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em SEO](https://danielpazwp.com/pt/category/seo-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [SEO out 2026Como migrar WordPress sem perder posições no Google](https://danielpazwp.com/pt/migrar-wordpress-sem-perder-posicoes/) [SEO out 2026Core Web Vitals são fator de ranking?](https://danielpazwp.com/pt/core-web-vitals-fator-de-ranking/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/)