No mundo digital de hoje, não basta produzir conteúdo e esperar que o Google faça o resto, é preciso entender como o site é rastreado, o que deve ser indexado e quais páginas realmente merecem disputar as primeiras posições.
É aqui que entra o funil de SEO técnico. Ele ajuda enxergar o site em níveis (do “tudo que existe” até “o que realmente deve ranquear”), auxiliando na organização da auditoria técnica e priorizando problemas de rastreamento, indexação e classificação.
A seguir, vamos montar esse funil passo a passo e depois conectar cada estágio aos problemas técnicos mais comuns, com foco no prático.
5 passos para construir seu funil de SEO técnico
1. Todas as páginas
Todo site tem um universo total de páginas: posts, categorias, produtos, filtros, páginas internas do sistema, testes antigos, URLs com parâmetros, versões antigas, etc.
O primeiro passo é mapear esse universo. Use um crawler (como Screaming Frog) para descobrir o máximo de URLs possível e combine com outras fontes, como o sitemaps XML, o relatório de páginas no GSC e logs, se tiver acesso.
2. Páginas rastreadas
Do total de páginas, uma parte precisa ser rastreada pelo Googlebot, e outra não deve receber rastreamento com tanta liberdade. Entram nessa lista de “não rastrear”:
- páginas de checkout;
- áreas de “Minha Conta”;
- páginas internas sensíveis;
- URLs geradas por filtros infinitos ou parâmetros irrelevantes.
Essas páginas podem ser controladas por diretivas de bloqueio no arquivo robots.txt e na remoção de linkagens internas. O objetivo é que o Google gaste tempo com o que importa.
3. Páginas indexadas
Dentro das páginas rastreadas, nem todas precisam aparecer na SERP. Entre as páginas que quase nunca deveriam ser indexados, estão as páginas de agradecimento, resultados de busca interna e algumas páginas de testes ou campanhas temporárias.
Nesses casos, você controla a indexação com meta robots noindex e nos ajustes de arquitetura para não promover URLs que não fazem sentido na busca.
Nesta etapa, afunilamos mais: daquilo que é rastreado, o que realmente deve estar no índice?
4. Páginas canônicas classificadas
Entre o que pode ser indexado, você ainda precisa separar em páginas canônicas (originais e únicas) e páginas não canônicas (duplicadas, variações de parâmetros, versões de teste).
As versões duplicadas devem apontar para a versão oficial pelo rel="canonical", para que o Google entenda qual URL consolidar, onde concentrar sinais de ranking e qual página mostrar ao usuário.
Nesse nível do funil, você estará lidando duplicidades de conteúdo e parâmetros desnecessários.
5. Otimização por níveis
No final do funil, você chega às páginas que:
- devem ser rastreadas;
- devem ser indexadas;
- são canônicas;
- têm potencial ou já disputam posição.
Essas são as páginas que merecem mais ateção. Você pode otimizá-las em dois níveis:
Por página individual:
- melhorar título, description, headings;
- reforçar conteúdo;
- revisar links internos;
- otimizar imagens, dados estruturados, UX.
Por template (modelo de página):
- corrigir estrutura de todas as páginas de produto de uma vez;
- melhorar o layout de todos os posts de blog;
- ajustar componentes repetidos (breadcrumbs, blocos de recomendados, etc.).
Esse é o ponto em que o funil vira um plano de ação.
6 problemas técnicos de SEO no funil
Agora que o funil está claro, vamos ver como ele ajuda a diagnosticar problemas típicos de rastreamento e queda de classificação.
1. Páginas que não deveriam ser rastreadas, mas estão sendo
O Google está gastando crawl budget em URLs inúteis ou perigosas.
Onde olhar: Google Search Console → Configurações → Estatísticas de rastreamento.
Observar aqui:
- picos estranhos em solicitações de rastreamento;
- muitas requisições em URLs com parâmetros;
- um volume alto de “descoberta” em um site que quase não atualiza conteúdo (indício de geração descontrolada de URLs).
Identifique o tipo de URL (filtros, parâmetros, páginas internas, etc.). Se for problema de geração de URL, trate na origem (CMS, facetas, query strings), mas se forem áreas que não deveriam ser expostas, bloqueie o rastreamento via robots.txt e/ou remova links internos que apontam para elas.
2. Páginas que são rastreadas, mas não são indexadas
O Google visita, mas não coloca a URL no índice.
Onde olhar: GSC → Indexação de páginas → “Rastreada, mas não indexada no momento”.
Exporte as URLs para uma planilha e agrupe por tipo de padrão:
- tipo de template;
- parâmetros;
- idioma;
- diretório.
Algumas dessas páginas não deveriam mesmo ser indexadas. Mas, entre elas, você vai encontrar páginas importantes que ficaram sem força. Depois, solicite indexação novamente.
Para URLs que deveriam ser indexadas, melhore os links internos apontando para elas e garanta que estejam no sitemap XML, se fizer parte do seu escopo, revise o conteúdo (qualidade, duplicidade, intenção).
3. Páginas que não estão indexadas, mas deveriam estar
Muito parecido com o caso anterior, porém com um agravante: às vezes a culpa é do noindex.
Onde olhar: GSC → Indexação de páginas → “Rastreada, mas não indexada no momento” e “Excluída pela tag ‘noindex’”.
Identifique se a tag noindex foi usada por descuido (deploy antigo, template copiado, testes). Ao identificar este problema em páginas importantes, remova o noindex, reforce links internos e reenvie para indexação.
4. Páginas que estão indexadas, embora não devessem estar
O índice do Google está cheio de URLs que você não quer ver aparecendo (parâmetros, buscas internas, páginas de teste etc.).
Onde olhar: GSC → Indexação de páginas → Páginas indexadas → exporte a lista para analisar com mais calma.
Liste os tipos de página que não deveriam estar no índice (resultados de busca interna, URLs com parâmetros inúteis, duplicatas claras) e aplique meta robots noindex (preferencialmente). Somente em último caso, use regras de remoção temporária no GSC.
Importante: não use robots.txt para tentar “tirar do índice”. Bloquear rastreamento impede que o Google veja o conteúdo, mas não garante remoção da indexação de algo que ele já conhece.
5. Páginas não canônicas sendo classificadas
Aqui, o problema não é exatamente “não indexar”, mas “indexar e ranquear a URL errada”, como as versões com parâmetros, UTM, filtros ou estruturas alternativas estão aparecendo nas buscas.
Onde olhar:
- GSC → Desempenho → aplique filtro de Página usando “URLs com ?” ou expressões regulares para parâmetros
- GSC → Indexação de páginas → “Cópia sem página canônica selecionada pelo usuário” e “Página alternativa com tag canônica adequada”.
Nem toda URL com parâmetro é ruim. Em alguns contextos (como filtros úteis), pode fazer sentido, mas quando versões “auxiliares” roubam o lugar da principal, você tem um problema.
Para as páginas que não deveriam classificar:
- Verifique se o
rel="canonical"está apontando para a URL correta. - Veja se há links internos apontando para a versão errada.
- Confira se o sitemap XML só lista a versão canônica.
- Analise se há links externos apontando para a versão não canônica – em alguns casos, será preciso ajustar isso com quem linka.
6. Páginas canônicas que não estão classificando
Este é o contraponto do caso anterior: as URLs “certas” não aparecem e as erradas ganham visibilidade. Várias URLs disputando a mesma palavra-chave, e a página que você gostaria que ranqueasse está “sumida”.
Onde olhar: GSC → Desempenho → selecione uma palavra-chave importante → veja quantas URLs estão ranqueando para ela → observe se a “URL ideal” está fraca, enquanto outras variantes ocupam espaço.
Dica: ignore URLs com # aqui, pois muitas vezes são só âncoras internas mostradas como atalho.
Garanta que a página canônica tenha canonical autorreferenciado, esteja presente no sitemap XML, receba a maior parte dos links internos e tenha conteúdo mais completo e bem otimizado.
Nas duplicadas ajuste canonical apontando para a página principal, reduza links internos para essas variantes e evite promovê-las em navegação e menus. Verifique também se não há problemas de JavaScript impedindo que o Google veja o conteúdo da página canônica.
O impacto do JavaScript no funil de SEO
Em muitos sites modernos, o JavaScript é responsável por montar boa parte do conteúdo. Sites em JavaScript são poderosos e trazem um desafio no SEO: o Google precisa fazer um trabalho extra para enxergar tudo.
Conteúdo em JavaScript é como um cartão-presente: quando alguém te dá um, você ainda precisa sair de casa, ir até a loja e escolher o que quer. O presente existe, mas ele chega com atraso.
Com o Googlebot é parecido: quando você entrega tudo via JS, está dando um “vale-conteúdo”. Ele precisa ir buscar o script, processar, montar a página e só então entender o que está ali. Isso consome tempo e recursos e pode atrasar (ou limitar) a indexação completa.
Uma boa prática é reservar, de tempos em tempos, uma análise focada nas páginas mais importantes do funil (pilares, categorias principais, páginas de conversão), para entender se o Google consegue ver o conteúdo principal ou se está enxergando somente cabeçalho e rodapé.
Ferramentas simples (extensões de navegador, DevTools, testes no GSC) te ajudam nessa força-tarefa:
- ver o que some quando o JS é desativado;
- conferir como fica o HTML renderizado;
- detectar blocos que nunca são carregados na versão que o Google processa.
Se você perceber que o conteúdo crítico depende de JS pesado e não aparece bem na versão renderizada, é hora de conversar com o time de desenvolvimento. Ajustes de renderização (SSR, hydration, pré-render, etc.) costumam trazer impacto direto em tráfego para essas páginas.
Para SEO técnico, o ideal é que o conteúdo crítico não dependa totalmente de JS, e quando depender, garantir que o Google consiga renderizar e ler, ou seja, usar JavaScript só onde ele realmente faz diferença, mantendo o carregamento rápido e previsível.
