Uma palavra a menos derrubou 13 páginas que já estavam no ar.

Em 7 de novembro, 13 páginas de desenvolvedor front-end do Currículo para Vaga saíram do ar de uma vez e passaram a responder 404 em produção. Uma delas, a página de headline do LinkedIn para desenvolvedor front-end, já estava no índice do Google em 6 de novembro.

A queda veio de dentro do meu próprio pipeline de verificação. Eu já vinha testando travas automáticas de publicação em as 650 páginas contra a regra do método, e desta vez um portão desenhado para segurar qualidade excluiu em silêncio um conjunto inteiro que o buscador já conhecia.

Uma palavra abaixo do mínimo derrubou a nota de 100 para 98

As páginas de cargo do Currículo para Vaga são geradas a partir de dossiês, e cada uma só vai ao ar se passar pelos portões de qualidade do build. Um deles exige que a nota calculada do exemplo bem feito bata a nota declarada no dossiê. Quando os números divergem, o portão exclui o dossiê da saída.

Em 7 de novembro, uma mudança na contagem de palavras passou a dar 349 palavras ao exemplo de desenvolvedor front-end, uma abaixo do mínimo de uma das regras. Com isso, a nota do exemplo caiu de 100 para 98. Como o dossiê declarava 100, o portão excluiu o dossiê inteiro, os sitemaps de cargo ficaram com 119 cargos e a produção passou a responder 404 nas 13 páginas de desenvolvedor front-end.

O caso deixa um alerta prático para quem mantém páginas programáticas com validação no build. Um portão que exclui itens reprovados sem avisar protege páginas inéditas, mas derruba URLs que o Google já indexou se uma regra mudar depois da publicação.

A volta das 13 páginas esperou o código alcançar a produção

A correção entrou em 8 de novembro: o dossiê passou a declarar 98, porque as palavras contam exatamente como as exportações imprimem. Com esse ajuste, a conferência de conteúdo voltou a passar com 1.557 páginas aprovadas.

Mesmo com a conferência aprovada, a volta ao ar dependia da publicação seguinte do código. Isso acontece porque a publicação automática de conteúdo fica parada quando há código à frente da produção. Assim que o código foi publicado no mesmo dia 8 de novembro, as 13 páginas voltaram a responder 200.

Como ler 39 impressões na primeira semana sem inventar demanda

No fechamento da primeira semana do Search Console, de 1 a 7 de novembro, o site somou 39 impressões, 1 clique e posição média de 27,2. O Google mostra só 10 consultas, com 1 impressão cada, e deixa o restante anônimo.

Ler o topo dessa tabela sem filtro leva ao erro. As páginas com mais impressões aparecem em posição de 1 a 9, o que interpretei como sinal de buscas pela marca ou com site:, inclusive as da própria medição. Isso ainda não comprova demanda pelos temas. Nas consultas que já têm página própria no site, apareceram quatro termos:

• “curriculo cirurgião dentista” em 16º lugar.
• “curriculo de jornalista” em 18º lugar.
• “curriculo analista de sistemas” em 29º lugar.
• “curriculo recepcionista” em 97º lugar.

Uma impressão por consulta em uma semana é dado fino demais para sustentar decisão de conteúdo. Nenhuma consulta pediu página nova, e a releitura ficou marcada para quando houver 4 semanas de dados.

O Google foi a 104 páginas, os robôs de IA correram e o Bing parou no zero

Na leitura de 8 de novembro, o site: do Google passou de 62 para 104 páginas listadas. Já o Bing seguia com zero páginas indexadas, parado há 5 dias mesmo com a chave do IndexNow aceita e os sitemaps lidos. O passo seguinte é abrir um pedido ao suporte do Bing Webmaster.

Os robôs de IA caminharam bem mais rápido nesse começo. O OAI-SearchBot, que alimenta a busca do ChatGPT, leu 504 páginas do site em 24 horas, depois de registrar 1 e 8 acessos nos dias anteriores. O Applebot leu 294 páginas em 7 de novembro.

Olhar para a saúde das URLs publicadas vale mais na primeira semana do que tentar adivinhar pauta em cima de uma impressão isolada. Essa separação entre infraestrutura de indexação e leitura de demanda segue o que aplico em o método de busca na prática.