Como uma página entra no Google: rastreamento, renderização e indexação

A página foi publicada, o endereço abre normalmente no navegador, e mesmo assim ela não está no Google. Na maioria das vezes isso não é penalidade nem falta de conteúdo bom. Entre publicar e aparecer existe um percurso de quatro etapas, descoberta, rastreamento, renderização e indexação, e a página parou em alguma delas. Descobrir em qual é o que separa uma correção de dez minutos de três meses mexendo no lugar errado.

A diferença entre saber em que etapa a página parou e não saber aparece já no primeiro dia de trabalho. Quem sabe muda uma coisa e vê o estado mudar junto. Quem não sabe reescreve o texto de uma página que o robô nunca chegou a buscar, troca o título de outra que já está indexada há semanas, e no fim decide que busca orgânica não funciona para o negócio dele, quando o que não funcionou foi o palpite.

Publiquei a página e ela não aparece no Google. O que aconteceu?

A página parou em uma das quatro etapas do caminho até o índice, e o sintoma é idêntico nas quatro, que é o silêncio. Cada etapa faz uma pergunta própria sobre a página, e uma resposta negativa em qualquer uma delas encerra o percurso ali mesmo, sem aviso e sem mensagem de erro para quem publicou.

1. Descoberta: o buscador sabe que este endereço existe?
2. Rastreamento: ele foi até o endereço e baixou o arquivo?
3. Renderização: ele conseguiu montar a página e ler o que ela mostra?
4. Indexação: ele decidiu guardar essa página no índice?

Falhar na primeira e falhar na quarta produzem exatamente a mesma tela vazia quando você procura o seu próprio texto, e é por isso que o palpite erra tanto. A correção, no entanto, é oposta nos dois casos. Uma página que nunca foi descoberta precisa de um caminho até ela, e nenhuma reescrita de texto muda isso. Uma página que foi descoberta, buscada e recusada precisa de outra coisa, porque o robô já esteve lá e não achou que valia guardar. Existe ainda uma quinta etapa, a classificação, que decide a ordem entre as páginas já indexadas, e ela só começa depois que essas quatro terminaram: como o Google decide quem aparece primeiro é uma discussão que não faz sentido enquanto a página estiver fora do índice.

Que caminho uma página percorre entre ser publicada e aparecer na busca?

O caminho tem quatro etapas em sequência, e nenhuma delas começa antes de a anterior ter terminado. A documentação do Google sobre JavaScript na Busca descreve o processo em três fases, rastreamento, renderização e indexação. Vale separar a descoberta do rastreamento, como faz o relatório de indexação de páginas do Search Console, porque o site que trava em uma não se parece em nada com o site que trava na outra.

A coluna da direita é a que encerra a discussão, porque ela é observável e as outras três são inferência. Antes de trocar qualquer palavra na página, procure a data do último rastreamento daquele endereço. Se ela não existe, nenhum trabalho feito dentro da página tem efeito, porque ninguém do outro lado chegou a abrir o arquivo. Essa única checagem, feita antes de qualquer correção, é o que evita a semana perdida reescrevendo um texto que o buscador nunca leu.

Como o Google descobre que a minha página existe?

Por link e por sitemap, e não existe uma terceira via automática. Publicar não notifica ninguém: um endereço que nenhuma outra página aponta e que nenhum arquivo lista pode permanecer desconhecido por tempo indefinido, mesmo que o site inteiro já seja rastreado todos os dias.

• Link interno: uma página do próprio site aponta para a nova. É o caminho mais forte, porque carrega contexto e posição dentro da estrutura.
• Link externo: um site de fora aponta para ela. Além de revelar o endereço, sinaliza que existe interesse real naquele conteúdo.
• Sitemap XML: o site entrega uma lista de endereços ao buscador. O sitemap XML informa que a página existe, e é sugestão, não ordem de rastreamento.
• Pedido manual no Search Console: o dono do site submete um endereço por vez para a fila. Serve para casos pontuais, não para colocar um site inteiro no ar.

O link e o sitemap não são substitutos um do outro, e essa é a confusão mais cara da lista. O sitemap entrega o endereço e nada mais. O link entrega o endereço, mais a indicação de que aquela página pertence ao site e de que alguém achou que valia apontar para ela. Uma página que só existe no sitemap, sem nenhum link apontando para ela em lugar nenhum, é descoberta com facilidade e é rastreada com má vontade, porque nada no site sugere que ela importa.

Por que uma página nova pode ficar semanas sem receber a visita do robô?

Porque descoberta e rastreamento são etapas diferentes, e o buscador pode saber que o endereço existe sem nunca ter ido buscá-lo. A fila de rastreamento é dele, não sua, e a posição nessa fila depende de dois fatores que o site influencia mas não controla: o quanto o servidor aguenta ser visitado sem piorar, e o quanto aquele conteúdo parece valer a visita. É isso que a documentação do Google sobre administração de rastreamento em sites grandes descreve, ao separar um limite de capacidade, ligado ao tempo que o servidor consegue sustentar conexões abertas, de uma demanda de rastreamento, que cada rastreador calcula por critérios próprios. O nome desse teto é orçamento de rastreamento. A mesma documentação restringe o guia dela a sites grandes, e é por isso que o assunto entra aqui como explicação do mecanismo, não como tarefa para quem tem poucas páginas.

O cenário que mais confunde é aquele em que tudo o que se costuma conferir já está certo. O sitemap responde, o acesso dos robôs está liberado, nenhuma página tem diretiva de exclusão nem erro de servidor, e ainda assim parte dos endereços aparece como descoberta e nunca rastreada, com o campo de último rastreamento vazio. Não há nada para consertar dentro dessas páginas. Elas apenas não chegaram à vez na fila.

Nesse ponto a intuição atrapalha, porque o que move a fila é diferente do que se costuma tentar:

• Links a partir de páginas que já são rastreadas com frequência, que é a forma mais direta de transferir prioridade para o endereço novo.
• Menção externa, que sinaliza demanda vinda de fora e não depende de o buscador confiar mais no site.
• Tempo, que resolve boa parte dos casos sem intervenção nenhuma, ainda que na velocidade do buscador.
• Servidor que responde rápido e sem erro, porque resposta lenta reduz o ritmo com que o robô se dispõe a voltar.

Pedir indexação manualmente para cada endereço parece a solução óbvia e trata o sintoma, não a causa: o pedido move aquela página específica na fila, e não muda a razão pela qual o site inteiro está sendo rastreado devagar. Se metade das páginas de um site fica meses no estado de descoberta sem rastreamento, o problema não se resolve endereço por endereço, e sim dando ao buscador motivos para voltar mais vezes.

Quanto tempo leva para uma página nova aparecer no Google?

De alguns dias a algumas semanas para o rastreamento, e sem garantia de indexação depois dele. A faixa é do próprio Google, na orientação sobre pedir um novo rastreamento, que também afirma que pedir o rastreamento não garante inclusão nos resultados, nem imediata nem em momento algum. Qualquer número mais fechado que isso, apresentado como regra de 24 ou 48 horas, é invenção de quem escreve o texto.

Dentro dessa faixa, o que determina onde o seu caso cai:

• Site já rastreado com frequência, com a página bem ligada internamente: costuma ser questão de dias, às vezes de horas.
• Site novo, sem nenhum link externo apontando para ele: pode levar semanas até a primeira visita, e isso não indica erro.
• Página isolada, existindo só no sitemap: fica na fila mais tempo, porque nada no site sinaliza que ela importa.
• Site com resposta lenta ou instável: o ritmo cai, e a fila anda mais devagar para todos os endereços, não só para o novo.

A pergunta útil não é quanto tempo falta, é qual etapa já foi cumprida. Uma página descoberta há três dias e ainda não rastreada está no curso normal, e não há o que fazer além de esperar. A mesma página descoberta há três meses e ainda não rastreada é sinal de falta de prioridade, não de falta de paciência, e aí existe trabalho a fazer. É a data de último rastreamento que separa os dois casos, e é por isso que ela vale mais do que qualquer estimativa de prazo.

O que o robô faz quando chega, e o que faz ele desistir?

O robô pede o arquivo ao servidor e lê a resposta antes de ler o conteúdo, porque é essa resposta que diz se vale a pena continuar. Antes mesmo do pedido, ele consulta as regras de acesso do site. Se elas liberam, ele busca o endereço, recebe um código de resposta, e é esse código que decide o destino da página.

As seis linhas descrevem o mesmo mecanismo visto de ângulos diferentes: o robô decide o que fazer com a página antes de olhar o conteúdo dela. Comece a conferência pelos endereços que mudaram no último ano, porque é neles que os códigos de status costumam estar errados, e o prejuízo se concentra em dois casos.

Por que trocar um 301 por um 302 custa tanto?

Custa porque o buscador continua tratando o endereço antigo como o verdadeiro, às vezes por meses, enquanto o endereço novo espera uma transferência que nunca foi autorizada. Uma mudança definitiva sinalizada como temporária diz ao buscador, literalmente, para não mover nada de lugar.

O caso mais comum não é decisão de ninguém: é a plataforma que aplica o código padrão dela quando alguém troca o endereço de uma página pelo painel. Use 301 e 302 pelo que cada um significa, e conferir qual dos dois o site está devolvendo de fato, porque o que o painel mostra e o que o servidor responde nem sempre coincidem.

O que uma cadeia de redirecionamentos desperdiça?

Desperdiça visitas do robô, que são o recurso escasso da etapa. Cada salto entre endereços é um pedido novo ao servidor, e uma cadeia de redirecionamentos de três ou quatro saltos até a página final gasta várias visitas para entregar um único documento.

O problema raramente é fatal e é caro em ritmo, porque o robô faz menos trabalho útil por visita. Cadeias longas nascem de migrações sucessivas, em que cada mudança de endereço foi empilhada sobre a anterior em vez de apontar direto para o destino atual. O conserto é apontar cada endereço antigo diretamente para o final, eliminando as paradas do meio.

Bloquear no robots.txt tira a minha página do Google?

Não. O robots.txt impede o robô de buscar a página, e uma página que ele nunca buscou ainda pode aparecer na busca, sem descrição, se outros sites apontarem para ela. Bloquear o acesso e pedir a remoção do índice são duas ordens diferentes, dadas em lugares diferentes, e trocar uma pela outra é o erro técnico mais comum de quem tenta esconder uma página.

São três instrumentos, com efeitos que não se substituem:

1. robots.txt: diz ao robô o que ele não deve buscar. Não fala sobre guardar ou não guardar.
2. meta robots e noindex: dizem ao buscador para não guardar a página no índice. Só funcionam se ele conseguir buscar a página e ler a instrução.
3. tag canônica: diz qual endereço representa aquele conteúdo quando existem versões parecidas. É uma indicação de preferência, não uma ordem.

A armadilha nasce da combinação dos dois primeiros. Uma página bloqueada no robots.txt e marcada com noindex nunca tem o noindex lido, porque a instrução está dentro de um arquivo que o robô foi proibido de abrir. O bloqueio anula a remoção, e o resultado é o oposto do pretendido: a página fica fora do controle e dentro do índice. Para tirar uma página do Google, o caminho é deixar o acesso liberado e marcar a exclusão dentro dela.

O Google enxerga o que aparece na tela ou o que vem no código?

O buscador começa pelo código que o servidor entrega, e só enxerga o que aparece na tela depois de executar o JavaScript, numa etapa separada chamada renderização. A documentação do Google sobre JavaScript na Busca descreve esse processo em três fases, rastreamento, renderização e indexação, e a ordem entre elas explica quase todo problema de conteúdo que existe para o visitante e não existe para o buscador.

O que acontece entre uma fase e outra é o seguinte: o robô baixa o documento inicial, percebe que parte do conteúdo depende de scripts, e coloca a página numa fila de renderização. Mais tarde, um navegador sem tela executa esses scripts e monta a versão final. É essa versão montada que vai para a indexação. Duas consequências saem daí, e nenhuma é óbvia para quem publica:

• A renderização não é instantânea. A própria documentação diz que a página pode ficar poucos segundos nessa fila, e que pode demorar mais do que isso. Nesse intervalo, o buscador conhece apenas o esqueleto da página.
• A renderização depende dos mesmos recursos que o site entrega ao visitante. Se um script ou um arquivo de dados não puder ser buscado, a montagem sai incompleta.

A verificação prática é simples e dispensa ferramenta paga. Abra o código-fonte da página, aquele que o servidor entrega antes de qualquer script rodar, e procure ali o texto principal, o título e os links internos. Se eles não estiverem no código-fonte e só aparecerem na tela, tudo o que importa naquela página depende de a renderização dar certo. Isso não é proibido e não é erro, e passa a ser um risco que precisa ser conferido, e é o assunto de SEO para JavaScript.

Por que um site em JavaScript pode ser lido pela metade?

Porque a renderização pode falhar em partes, e o buscador guarda a versão que conseguiu montar, mesmo que ela esteja incompleta. Não existe aviso de falha parcial: a página entra no índice com o que sobrou, e para quem publicou ela parece perfeita, porque no navegador dele tudo aparece.

As causas se repetem, e quase todas são de configuração, não de código:

• Conteúdo que só aparece depois de uma ação do visitante, como clicar numa aba ou rolar até o fim. O robô não clica e não rola.
• Arquivos de script ou de dados bloqueados no robots.txt, muitas vezes pastas técnicas bloqueadas anos atrás por precaução. O robô busca a página e não pode buscar o que ela precisa para existir.
• Chamadas a serviços externos que falham ou demoram, e a página é montada sem a parte que dependia daquela resposta.
• Erro de script em ambiente sem interação, que passa despercebido no navegador do visitante e interrompe a montagem no navegador do buscador.

Um exemplo prático torna o efeito visível. Uma página de produto cujo nome está no código-fonte, e cujo preço, descrição e avaliações chegam por script depois da abertura, é indexada com nome e endereço corretos e com o corpo vazio. Ela existe no índice, responde por buscas pelo nome exato do produto, e não responde por nada que dependa da descrição, porque essa parte nunca foi guardada. O diagnóstico enganoso vem em seguida: parece problema de conteúdo insuficiente, e é problema de montagem.

Como saber se o seu conteúdo depende de renderização?

Compare duas coisas, o código-fonte entregue pelo servidor e a página vista no navegador. O que existir só na segunda é exatamente o material que depende da renderização, e é ali que a leitura pela metade acontece.

A comparação leva um minuto e não exige ferramenta paga. No código-fonte, procure o texto principal, os títulos das seções, os links internos e o preço, se houver. Se qualquer um deles aparecer na tela e não no código, essa parte da página está condicionada a uma etapa que pode falhar em silêncio. Isso não obriga a refazer o site, e obriga a tratar aquele conteúdo como sujeito a conferência sempre que ele mudar.

Ser rastreada garante que a página entre no índice?

Não. Rastrear é buscar o arquivo, indexar é decidir guardá-lo, e essas duas coisas são executadas por critérios diferentes. O buscador pode ler uma página inteira, entender do que ela trata e ainda assim não guardá-la, sem que nada esteja quebrado do lado técnico.

O índice é um banco de dados com custo de armazenamento e de manutenção, e cada endereço guardado precisa justificar o espaço que ocupa. A decisão que o buscador toma nesse ponto não é sobre a página estar correta, é sobre ela acrescentar alguma coisa ao que já existe guardado. Uma página tecnicamente impecável, rápida, acessível e sem nenhum erro pode ser recusada por ser a quarta versão do mesmo conteúdo dentro do próprio site.

É por isso que a correção nessa etapa quase nunca é técnica. Quando o travamento está na indexação, mexer em velocidade, em estrutura de código ou em configuração de servidor não muda o resultado, porque nenhuma dessas coisas foi o motivo da recusa. O que muda o resultado é dar à página uma razão de existir que as outras não tenham.

Que motivos fazem o buscador ler a página e decidir não guardá-la?

Os motivos se concentram em três, e todos os três aparecem depois que a leitura já aconteceu: repetição, ausência de conteúdo próprio, e sinal contraditório dentro da própria página.

1. Repetição dentro do site. Vários endereços entregam o mesmo conteúdo, seja porque um parâmetro na URL cria uma variação, seja porque existe uma versão para impressão, seja porque o mesmo texto foi publicado em duas seções. O buscador escolhe um endereço para representar o conjunto e descarta os demais.
2. Conteúdo sem nada próprio. Páginas montadas por template, em que só mudam o nome da cidade ou o nome do serviço, com o mesmo corpo em todas. Elas existem para completar uma estrutura, e o buscador lê exatamente isso.
3. Sinal contraditório na página. Uma tag canônica apontando para outro endereço, uma diretiva de exclusão esquecida de uma migração antiga, ou títulos repetidos em série. A página pede para não ser guardada, e é atendida.
4. Volume sem demanda. Centenas de endereços criados de uma vez para combinações que ninguém procura. O buscador guarda uma parte, avalia o retorno e desacelera no restante.

Os quatro casos produzem a mesma linha no relatório, e só o primeiro tem conserto puramente técnico. Os outros três exigem uma decisão editorial que se adia com facilidade porque é mais trabalhosa: escolher quais páginas merecem existir. Cortar cem endereços vazios costuma fazer mais pelo desempenho de um site do que otimizar os mesmos cem, e essa é a recomendação que menos aparece em proposta comercial, porque ela reduz o tamanho do trabalho em vez de aumentar.

Por que o Google mostra uma versão antiga da minha página?

Porque o que aparece na busca é a última versão que foi rastreada e guardada, não a que está no ar agora. Entre publicar uma alteração e ela aparecer no resultado existe uma nova rodada de rastreamento, e o intervalo entre uma rodada e outra é decidido pelo buscador, com base na frequência com que aquela página costuma mudar de verdade.

Três coisas encurtam esse intervalo, e nenhuma delas age de imediato:

1. Histórico de mudança real. Página que muda com regularidade passa a ser visitada com mais frequência. Trocar uma vírgula toda semana não produz esse efeito, porque a comparação é de conteúdo, não de data.
2. Data de modificação coerente no sitemap. O campo de última modificação informa quando o conteúdo mudou, e a documentação do Google sobre sitemaps diz que o valor é usado quando ele é consistente e verificável, por comparação com a última modificação real da página. A leitura prática disso é que um sitemap que carimba a data de hoje em todas as páginas deixa de ser verificável, e o campo perde a função de sinal.
3. Link interno a partir de páginas visitadas com frequência. A mesma mecânica que acelera a descoberta acelera a revisita.

O efeito prático aparece no caso de quem corrige um erro e continua vendo o erro na busca por dias. A correção está no ar, e o índice ainda não sabe. Antes de refazer a alteração, ou de concluir que ela não funcionou, olhe a data do último rastreamento daquela página: se ela é anterior à mudança, não há nada de errado com a correção, e sim com a expectativa de que o buscador acompanhasse em tempo real.

Quais páginas do site não deveriam ser indexadas?

As que não têm o que responder a quem chega pela busca, e elas são mais numerosas do que parece: página de agradecimento, resultado de busca interna, versões filtradas do mesmo conjunto, ambiente de teste e áreas de acesso restrito. Deixar todas no índice não é neutro, porque cada endereço guardado consome parte da atenção que o buscador dedica ao site.

A última linha existe para evitar o excesso oposto, que é sair excluindo tudo o que não traz visita: página que não atrapalha pode ficar. O corte vale para as quatro primeiras, e a coluna da direita é a parte que costuma sair errada. Bloquear o acesso a um ambiente de teste no arquivo de regras não o esconde, porque o bloqueio impede a leitura e não a listagem, e o endereço acaba aparecendo sem descrição. Ambiente de teste se protege com senha, que é a única forma que impede as duas coisas ao mesmo tempo.

Descoberta ou rastreada: por que a diferença entre esses dois estados muda tudo?

Porque um estado diz que o buscador nunca abriu a página, e o outro diz que ele abriu e recusou. São diagnósticos opostos, com correções opostas, e o relatório de indexação de páginas do Search Console separa os dois exatamente por isso.

A leitura que essa tabela permite e que quase ninguém faz é a seguinte: se os seus endereços parados estão no primeiro estado, nenhuma alteração dentro das páginas vai mudar o quadro, e o trabalho é de estrutura e de atenção externa. Se estão no segundo, o trabalho é de conteúdo, e insistir em pedidos de indexação apenas repete uma decisão que já foi tomada com a página aberta. Antes de escolher o que fazer, abra a cobertura de índice e ver em qual dos dois estados a maior parte dos endereços parados está, porque é essa proporção que define o tipo de trabalho, não o total de páginas fora do índice.

Em qual das etapas o meu site travou?

Quatro perguntas na ordem resolvem, e a primeira resposta negativa marca a etapa que travou. Cada uma tem um sinal observável, o que significa que nenhuma delas depende de opinião ou de ferramenta paga.

1. O endereço aparece em algum relatório de indexação? Se não aparece em lugar nenhum, ele não foi descoberto, e o problema está antes de tudo: nenhum link aponta para ele e nenhum sitemap o lista.
2. Existe data de último rastreamento registrada? Se o endereço é conhecido e essa data está vazia, ele foi descoberto e nunca buscado. O travamento é de fila e de prioridade.
3. O conteúdo principal aparece no código-fonte entregue pelo servidor? Se ele só existe na tela, depois dos scripts, a montagem é o ponto frágil, e o que foi guardado pode ser bem menos do que a página mostra.
4. A página consta como rastreada e mesmo assim fora do índice? Então ela foi lida e recusada, e a causa está no conteúdo ou nos sinais que ela emite.

Essas quatro perguntas separam o problema em duas famílias que não se misturam. As perguntas 1 e 2 tratam de acesso, e nelas o texto da página é irrelevante. As perguntas 3 e 4 tratam do que foi lido, e nelas nenhuma mudança de estrutura resolve. Fazer as quatro na ordem leva alguns minutos por endereço e evita o erro mais caro do trabalho técnico, que é aplicar a correção certa na etapa errada.

Quando o padrão se repete em dezenas de endereços, e não em um só, a leitura deixa de ser página a página e vira análise de rastreamento, que é olhar o comportamento do robô no site inteiro em vez de conferir casos isolados. Se o objetivo for levantar tudo o que está errado de uma vez, e não apenas descobrir a etapa travada, o caminho é uma auditoria de SEO, que cobre também o que está fora do escopo técnico.

A página está indexada e mesmo assim não aparece. E agora?

Então o trabalho técnico terminou e o problema mudou de natureza. Uma página indexada já passou pelas quatro etapas, e o que a impede de aparecer não é mais acesso nem leitura, é a disputa por posição com outras páginas que também estão guardadas e também respondem àquela busca.

A confirmação de que a página está mesmo no índice leva alguns segundos: procure pelo endereço exato dela no buscador, ou pelo título entre aspas. Se ela responde a essa busca e não responde a nenhuma outra, o índice a tem, e o que falta é relevância para os termos que as pessoas realmente digitam. Existe ainda um caso intermediário que engana bastante, que é a página indexada e posicionada para um termo que ninguém procura. Ela está tecnicamente perfeita, aparece em primeiro lugar, e não recebe visita nenhuma, porque a busca que ela ganha não existe em volume.

Esse é o limite do trabalho técnico, e dizê-lo com clareza evita frustração depois: essa camada decide se a página é encontrada, lida e guardada, e ela não gera demanda. Ela resolve uma condição de entrada. Um site com problema de indexação resolvido e conteúdo que não responde a nada continua invisível, com a diferença de que agora o motivo é outro, e a correção também.

A velocidade do servidor atrapalha o rastreamento?

Atrapalha, e por um caminho diferente daquele que afeta o visitante. O robô ajusta o ritmo das visitas ao tempo que o servidor leva para responder, então servidor lento significa menos páginas buscadas por dia, e um site inteiro pode demorar semanas a mais para ser percorrido por causa disso.

São dois assuntos com o mesmo nome popular, e confundi-los faz o trabalho ir para o lugar errado:

• Tempo de resposta do servidor: quanto o servidor demora para entregar o arquivo depois do pedido. Afeta o rastreamento, porque define quantos pedidos o robô se dispõe a fazer.
• Experiência de carregamento para quem visita: quanto a página demora para ficar utilizável na tela, medida pelos Core Web Vitals. Afeta a etapa seguinte, a de classificação, e não muda o ritmo do robô.

A distinção tem consequência prática imediata. Um site que trava no rastreamento por lentidão de servidor não melhora com otimização de imagem nem com ajuste de fonte, porque o gargalo está antes, na entrega do arquivo. E um site com boa resposta de servidor e carregamento ruim na tela do visitante é rastreado normalmente, mesmo tendo um problema real a resolver. Medir e melhorar essa segunda parte é trabalho de criação de sites e de manutenção, e aqui ela interessa apenas como sinal de que a leitura do lado do buscador pode estar comprometida.

Quem resolve um travamento desses: quem cuida do site ou quem cuida do SEO?

Os dois, e a divisão é mais simples do que costuma parecer: quem cuida do site tem acesso ao servidor e ao código, e quem cuida do SEO sabe qual mudança pedir e como confirmar que ela funcionou. O problema aparece quando um dos dois papéis é exercido sozinho, porque cada arranjo falha de um jeito previsível.

A quarta linha é a que funciona, e ela não é a mais cara por acaso: as três primeiras terminam com alguém esperando por outra pessoa. Se o seu caso for de site pequeno, com poucas páginas e nenhuma delas travada nas duas primeiras etapas, o arranjo da segunda linha já basta, e contratar mais que isso é gastar com um problema que você não tem. Quando existe um travamento medido, e ele se repete em muitos endereços, o que resolve é uma auditoria técnica de SEO feita por quem depois acompanha a execução, que é o formato do serviço de SEO Técnico. A escolha entre agência, consultor ou equipe interna é uma decisão anterior e vale para todas as frentes, não só para esta, e está discutida em contratar agência, consultor ou fazer dentro de casa.

O que fazer depois de descobrir em qual etapa a página travou?

A correção é diferente em cada etapa, e cada uma exige um tipo de trabalho que não substitui o das outras. Saber o ponto de parada vale mais do que qualquer lista genérica de otimização justamente por isso: ele elimina três quartos das tarefas possíveis antes de você gastar um dia com qualquer uma delas.

1. Travou na descoberta, o trabalho é de caminho. Um link a partir de uma página que já é rastreada, e o endereço listado no sitemap. Nada do que estiver escrito dentro da página muda esse quadro.
2. Travou no rastreamento, o trabalho é de prioridade e de resposta. Servidor rápido, redirecionamentos curtos, acesso liberado, e links internos vindos das páginas que o robô visita com mais frequência.
3. Travou na renderização, o trabalho é de entrega. O conteúdo essencial precisa estar no código-fonte, e os arquivos de que a montagem depende precisam estar acessíveis. O que ficar atrás de um clique ou de uma rolagem continua invisível.
4. Travou na indexação, o trabalho é editorial. Repetição interna eliminada, canônica e diretiva de exclusão corrigidas, e um motivo de existir que as outras páginas do site não tenham.

Uma frente por vez, com o sinal observável conferido antes e depois, é o que transforma trabalho técnico em resultado verificável, em vez de uma lista de tarefas que ninguém sabe se funcionou. E depois que a página entra no índice, o cuidado muda de natureza: monitorar a saúde técnica em intervalos regulares é o que evita descobrir um travamento três meses depois de ele começar, quando tudo o que foi publicado nesse intervalo já nasceu invisível. Se quiser ver como essas etapas se encadeiam dentro de um trabalho completo, do diagnóstico à publicação, a metodologia mostra o percurso inteiro aplicado.