Triagem de problemas técnicos de SEO

Quando uma página é publicada, ela ainda percorre etapas diferentes até poder gerar visitas pela busca:

1. Rastreamento: o mecanismo de busca consegue acessar a página.
2. Indexação: ele processa a página e pode incluí-la no índice.
3. Exibição nos resultados: a página pode aparecer para uma pesquisa, em determinada posição e formato.

Uma etapa não garante a seguinte. Por isso, publicar /produtos/garrafa-verde não garante que ela já foi acessada, indexada ou exibida para uma busca relevante.

O relatório Indexação de páginas oferece uma visão agregada: ele reúne URLs por estados e motivos informados pelo Google. Use-o para localizar padrões e decidir quais recortes merecem investigação — não para concluir a causa de uma URL isolada.

No exemplo da Casa Ipê, uma categoria pode reunir várias URLs em um mesmo estado. Antes de agir, registre o recorte consultado e escolha uma URL representativa para examinar em detalhes.

A Inspeção de URL serve para investigar um endereço específico em uma propriedade do Search Console à qual você tem acesso. Para consultar dados reais, a propriedade precisa estar verificada e seu usuário precisa ter as permissões adequadas. Nesta prática, os exemplos em texto bastam.

Leia a URL junto com: estado informado, motivo exibido, data do último rastreamento quando disponível e finalidade da página. Uma página ativa de produto e uma página que não deveria aparecer na busca exigem interpretações diferentes.

Uma URL não indexada não é automaticamente um erro. Pergunte primeiro: esta página deveria aparecer na busca?

Se a finalidade for aparecer — como /produtos/garrafa-verde, produto ativo da Casa Ipê — a ausência de indexação merece investigação. Se a finalidade não for aparecer, o estado pode ser esperado. A decisão depende da finalidade real da URL, não apenas do rótulo do relatório.

Ao registrar o achado, mantenha fato e hipótese separados: “estado informado” é fato; “isso impede a descoberta do produto” é uma hipótese que precisa de contexto e evidências.

Para uma triagem inicial, anote:

• URL exata e contexto da página;
• fonte consultada, data e recorte;
• estado e motivo apresentados;
• data do último rastreamento, se houver;
• resultado separado do teste da URL publicada;
• pergunta que ainda precisa ser respondida.

Esse registro evita transformar um sinal parcial em diagnóstico ou correção apressada.

robots.txt e noindex atuam em pontos diferentes da triagem.

• robots.txt orienta o rastreamento: ele pode indicar que o rastreador não deve acessar uma URL.
• noindex orienta a indexação: ele comunica que uma página acessada não deve ser incluída no índice.

Portanto, robots.txt não é uma ordem de remoção do índice. E, para o rastreador encontrar a orientação noindex, a página precisa estar acessível a ele.

Bloquear o rastreamento pode impedir que o mecanismo leia um noindex existente. Por isso, usar os dois juntos não assegura o resultado pretendido.

Além disso, uma URL bloqueada por robots.txt ainda pode aparecer no índice, às vezes com informações limitadas, caso o mecanismo a conheça por links ou outras referências. Esse sinal pede investigação; não prova, sozinho, que a configuração está errada.

Um sitemap é uma lista de URLs que ajuda o mecanismo de busca a descobrir páginas. Estar nessa lista é uma evidência útil, mas não garante rastreamento nem indexação.

A URL canônica responde a outra pergunta: entre páginas iguais ou muito semelhantes, qual é a versão preferida para consolidar sinais? Ela não significa que todas as outras versões precisam aparecer nos resultados.

A URL canônica pode ser declarada pelo site e, quando a informação estiver disponível, também pode haver uma URL selecionada pelo Google. Elas podem coincidir ou divergir.

Leia esses dados junto com a finalidade da página. Uma versão com parâmetro de origem pode ter o mesmo conteúdo da página principal e, nesse caso, sua ausência no índice pode ser uma consolidação esperada.

Antes de propor qualquer mudança, confirme três pontos:

1. Equivalência: as URLs mostram conteúdo igual ou muito semelhante?
2. Versão desejada: qual endereço deve representar a página nos resultados?
3. Indicação observada: qual URL canônica o site declara e qual o Google seleciona, quando esse dado estiver disponível?

A presença e a atualização no sitemap complementam a investigação de descoberta. Elas não provam, sozinhas, que uma URL deveria ser indexada.

Uma URL removida nem sempre é um problema técnico. HTTP 404 informa que a página não foi encontrada. Ele pode ser o estado adequado quando a remoção foi intencional e não existe uma página substituta equivalente.

Já um redirecionamento encaminha quem acessa um endereço para outro. HTTP 301 sinaliza uma mudança permanente, mas só faz sentido quando o destino atende à mesma necessidade de forma equivalente.

Na Casa Ipê, /caneca-azul foi substituída por /produtos/caneca-azul: há continuidade clara. Já /ofertas/inverno era uma campanha encerrada e não tem substituta equivalente: manter HTTP 404 pode ser a decisão coerente.

Redirecionar não é o mesmo que indicar uma URL canônica. A URL canônica ajuda a apontar a versão preferida entre conteúdos semelhantes; o redirecionamento leva o acesso de um endereço a outro.

Antes de sugerir uma mudança, observe o que acontece com a URL antiga, onde ela chega e se a pessoa encontra uma resposta equivalente à que buscava.

Para uma URL antiga, siga uma investigação curta antes de pedir alteração:

1. Confirme o endereço solicitado e se a mudança ou remoção foi intencional.
2. Observe a resposta atual e, se houver encaminhamento, o destino final.
3. Compare a finalidade e o conteúdo: o destino realmente substitui a página antiga?
4. Verifique links internos e outros acessos que ainda levem ao endereço antigo.
5. Decida o encaminhamento: HTTP 301 para substituta equivalente; HTTP 404 quando a remoção é intencional e não há equivalente.

Não é preciso implementar nada nesta triagem: o objetivo é registrar uma recomendação baseada em evidências.

O PageSpeed Insights reúne sinais sobre a experiência de carregamento e uso de uma página. Ele ajuda a formular uma hipótese e a decidir a próxima verificação; não entrega, sozinho, um diagnóstico completo nem prevê posição na busca.

Há duas fontes principais. Dados de campo reúnem observações agregadas de usuários reais quando estão disponíveis, geralmente em uma janela móvel de 28 dias. Dados de laboratório vêm de uma execução controlada do teste e podem variar conforme as condições dessa execução.

A consulta a um site próprio é opcional. Nesta prática, os relatórios são exemplos completos e ilustrativos.

Compare a origem da informação antes de interpretar qualquer número.

Antes de comparar resultados, identifique três recortes: a fonte, o dispositivo selecionado — Celular ou Computador — e o escopo.

O escopo URL se refere ao endereço analisado. O escopo Origem reúne páginas do mesmo protocolo, domínio e porta. Portanto, um dado de campo da origem não descreve exclusivamente uma única página.

A ausência de Dados de campo em uma URL ou origem não prova desempenho bom nem ruim: pode simplesmente não haver informação agregada disponível para aquele recorte.

Em uma checagem móvel, descreva apenas o que pode ser repetido: a URL, o celular ou a largura de tela, a ação e o resultado visível. Observe, por exemplo:

• conteúdo cortado ou necessidade de rolagem horizontal inesperada;
• elementos sobrepostos;
• botão, menu ou campo difícil de acionar durante uma tarefa;
• imagem que demora a aparecer;
• conteúdo que muda de posição enquanto a página carrega.

Uma checagem no seu próprio aparelho é opcional. Os exemplos ilustrativos deste tutorial permitem praticar sem acessar um site real.

Nem todo problema móvel é estático. Ao abrir uma página, uma imagem pode surgir depois e empurrar o título, o preço ou um botão para outra posição. Esse deslocamento durante o carregamento é diferente de um elemento que já está cortado na tela.

Também evite concluir a causa pela aparência: uma imagem que demora pode levantar a hipótese de arquivo pesado, mas isso deve ser confirmado pelo tamanho do arquivo ou por um diagnóstico apropriado.

Exemplo ilustrativo — 12/05/2026, 14h30

Na Casa Ipê, a pessoa abriu https://casa-ipe.example/produtos/garrafa-verde em um celular com largura de 360 px. Ela tentou usar o botão de compra logo após a página começar a aparecer. Quando a imagem do produto terminou de carregar, o botão mudou de posição e ficou abaixo da área inicialmente visível.

Escreva um registro curto que inclua: contexto, ação, resultado observado e uma hipótese técnica formulada como possibilidade — não como certeza.

Priorizar não é atribuir uma pontuação aparentemente exata. Compare quatro aspectos: importância da página, alcance do problema, impacto provável na tarefa da pessoa usuária e força da evidência.

Uma página ativa de produto em que a compra não pode ser concluída pode exigir atenção antes de uma diferença visual cosmética, mesmo que a melhoria cosmética seja mais fácil. Use as prioridades Alta, Média e Baixa para ordenar a atenção, não para substituir a investigação.

Também classifique a natureza do achado:

• Problema confirmado: o efeito foi observado de forma reproduzível.
• Hipótese que exige investigação: há um indício, mas a causa ainda não foi confirmada.
• Estado esperado: não requer correção, como /ofertas/inverno retornando HTTP 404 após uma campanha encerrada sem substituta equivalente.

Ao registrar, não transforme a hipótese sobre a causa em certeza.

Alguns ajustes podem estar disponíveis sem código, como comprimir ou redimensionar uma imagem e usar uma opção nativa de layout. Isso depende dos recursos e das permissões da ferramenta.

Já regras de rastreamento, URL canônica, redirecionamentos, servidor e código podem exigir Apoio técnico. A existência de um botão ou campo no CMS não torna segura uma alteração que afeta URLs, indexação ou muitas páginas.

A ficha de encaminhamento padroniza a decisão:

URL | Evidência | Hipótese e impacto provável | Próxima ação | Responsável | Prioridade | Critério de validação

A evidência deve informar fonte, data e recorte. O critério de validação deve repetir a condição que revelou o achado: realizar novamente a tarefa móvel, confirmar o destino final de uma URL ou verificar um estado após novo rastreamento.

Associe cada cenário ao encaminhamento determinado pelas condições informadas.

Use esta sequência curta para fechar uma triagem: localize a etapa → reúna evidências → confirme a intenção → priorize → encaminhe → valide.

A decisão não é “corrigir tudo”. Uma URL pode estar fora do índice de modo esperado; um sinal pode indicar um problema relevante; ou os dados podem ainda não bastar para concluir. Mantenha sempre separadas a evidência observada, a hipótese e a próxima ação.

Leia os três registros abaixo. Todos são um Exemplo ilustrativo da Casa Ipê, registrado em 12/05/2026. Cada caso traz evidência suficiente para uma classificação inicial.

Confira seu raciocínio:

• A é estado esperado: a versão com parâmetro repete o conteúdo e está consolidada na URL canônica principal. Não há motivo para exigir que ambas sejam indexadas.
• B é problema prioritário: a página é ativa e deveria poder aparecer na busca, mas há evidência de bloqueio de rastreamento. A alteração deve ser avaliada pelo Apoio técnico, não feita por suposição.
• C é informação insuficiente: a rolagem horizontal foi observada, mas ainda precisa ser reproduzida e registrada em outra condição antes de atribuir uma causa ou prioridade final.

Na ficha, a evidência descreve o fato; a hipótese indica o impacto possível; a próxima ação define a verificação. Validar o ajuste no site e observar posteriormente o estado no Google são etapas diferentes.