Antes de começarmos a oferecer SEO técnico como serviço, fizemos o que a maioria das agências pula: aplicamos o processo em nós mesmos.
Rodamos uma auditoria técnica completa no prixelo.com. Não em um ambiente de staging, não em um site de demonstração — o site real, o mesmo que clientes em potencial veem antes de nos mandar um e-mail. Esperávamos encontrar alguns probleminhas. Encontramos sete coisas que estavam trabalhando ativamente contra nós.
Este post é essa auditoria, sem edição. Nada de cliente fictício, nada de estudo de caso inventado. Apenas o que encontramos no nosso próprio site e o que cada bug ensina sobre como os mecanismos de busca realmente veem uma página, em contraste com como um navegador a renderiza para você.
O sitemap estava sem a maior parte do site
Abrimos o sitemap.xml esperando encontrar uma formalidade. Em vez disso, encontramos um arquivo listando uma fração das nossas páginas reais. Seções inteiras do site — páginas que já tínhamos publicado, linkado internamente e esperávamos que rankeassem — simplesmente não estavam lá.
Um sitemap não é um extra opcional. É o mapa que você entrega ao Google para que ele não precise adivinhar a estrutura do seu site apenas rastreando links. Uma página que está no ar, linkada internamente e ausente do sitemap ainda pode acabar sendo indexada, mas de forma mais lenta e menos confiável — e isso sinaliza aos crawlers que os metadados do seu site não são confiáveis. Se o sitemap está errado uma vez, o crawler tem menos motivo para tratá-lo como autoritativo em qualquer outro lugar.
Nosso JSON-LD de Organization estava quebrado em todo o site
Verificamos dados estruturados com um validador por hábito. Os nossos falharam. Em todas as páginas.
A causa era um bug de escaping no template — um caractere no nosso schema de Organization estava sendo codificado incorretamente no momento da renderização, o que tornava o bloco de JSON-LD sintaticamente inválido em todas as páginas em que aparecia. O Google não faz parsing parcial de um JSON quebrado. Ou ele faz o parsing completo, ou descarta o bloco inteiro. Então, durante todo o tempo em que isso esteve no ar, tínhamos zero dados estruturados chegando ao Google, em todo o site, enquanto acreditávamos ter a marcação completa. Esse é o tipo de bug que não gera nenhum erro visível no navegador — a página parece normal — e nenhum aviso, a menos que você vá procurar especificamente em um validador de schema ou no relatório de resultados avançados do Search Console.
Soft-404s retornando HTTP 200
Algumas URLs quebradas ou removidas do site não estavam retornando status 404. Elas serviam um conteúdo alternativo — uma página genérica — enquanto o servidor dizia ao navegador e a todo crawler "200 OK, esta página existe".
Isso é um soft-404, e é pior do que um 404 de verdade. Um 404 real diz claramente aos mecanismos de busca: essa URL não existe mais, tire-a do índice. Um soft-404 diz: essa URL está tudo bem, continue rastreando e indexando, mesmo que não haja nada aqui. Se não for corrigido, isso desperdiça orçamento de rastreamento (crawl budget) em páginas que não existem e pode diluir a forma como suas páginas reais são avaliadas, porque o crawler está gastando tempo e confiança em becos sem saída que afirmam estar ativos.
Tags canonical apontando para o domínio errado
Várias páginas tinham tags canonical referenciando a versão non-www do nosso próprio domínio, que por sua vez redireciona para outro lugar — um resquício de uma configuração anterior. Uma tag canonical é uma instrução direta aos mecanismos de busca: "indexe esta URL como a versão autoritativa, não a que você está vendo agora." Quando ela aponta para o lugar errado, você está explicitamente dizendo ao Google para atribuir crédito a uma URL diferente pelo seu próprio conteúdo. No melhor caso, é ignorada. No pior caso, você está ativamente desviando seus próprios sinais de ranqueamento da página que precisa deles.
Meta descriptions cortadas no meio da palavra
É algo menor, mas do tipo que corrói a confiança quando somado a outros: várias meta descriptions estavam sendo cortadas no meio de uma palavra diretamente no HTML bruto, não apenas truncadas na exibição dos resultados de busca. Isso é um bug de template ou de limite de caracteres, não um artefato de exibição, e aparece como frases inacabadas dentro das suas tags <meta> — visíveis para qualquer um que veja o código-fonte, e um sinal pequeno, mas real, de descuido em uma página que está tentando parecer confiável.
Um robots.txt desatualizado, vindo de um diretório anterior ao site atual
Essa foi a descoberta mais estranha. O robots.txt sendo servido não era o que estava no nosso código atual. Ele vinha de um diretório legado esquecido no servidor — um resquício de uma versão anterior do site que deveria ter sido totalmente desativada. A aplicação em produção não tinha ideia de que esse arquivo existia, nem de que era ele que os crawlers estavam de fato lendo.
O robots.txt é um dos primeiros arquivos que um crawler solicita. Se a versão servida estiver desatualizada, ela pode estar bloqueando caminhos que deveriam ser rastreáveis, permitindo caminhos que não deveriam ser, ou simplesmente apontando para um sitemap que não existe mais. E como ele vive fora do seu fluxo normal de deploy, fica invisível para quem está checando o código atual — você precisa verificar o que está sendo servido de fato na URL, não o que acha que publicou.
Páginas que diziam "não encontrado" aos crawlers por causa da detecção de slug só no client-side
O último é um problema de renderização em JavaScript, e é uma armadilha comum para qualquer coisa construída com roteamento no client-side. Certas páginas decidiam qual conteúdo exibir com base em um slug que só era resolvido no navegador, depois que o JavaScript rodava. Crawlers que não executam totalmente o JavaScript no client-side — ou que dão timeout antes que ele seja resolvido — recebem a resposta inicial do servidor, não encontram nenhum slug correspondente, e acabam vendo um estado de "não encontrado". A página funciona perfeitamente para uma pessoa. Para um crawler que nunca chega longe o suficiente para ver o conteúdo real, ela é invisível ou está quebrada.
O que isso realmente ensina
Nenhum desses bugs é exótico. São os modos de falha padrão de qualquer site que já cresceu além da sua primeira versão: infraestrutura legada que ninguém desativou, uma mudança de template que quebrou silenciosamente a codificação, um padrão de roteamento otimizado para usuários, mas nunca verificado quanto ao comportamento dos crawlers. Todos eles eram invisíveis em um navegador normal, e continuavam invisíveis a menos que alguém fosse procurar especificamente como um crawler vê a página — não como uma pessoa vê.
Esse é o verdadeiro trabalho. SEO técnico não é sugestão de palavras-chave ou calendário de conteúdo — é encontrar a diferença entre a aparência do seu site para você e a aparência dele para os sistemas que decidem se vão indexá-lo e ranqueá-lo. Corrigimos todos os sete problemas no nosso próprio site como parte da construção do nosso serviço de SEO, porque não íamos vender uma auditoria que não tínhamos primeiro rodado em nós mesmos.
Se você quiser saber se o seu próprio site tem versões desses mesmos problemas, é exatamente isso que nossa equipe de SEO verifica primeiro — antes de qualquer conversa sobre conteúdo ou rankings.
