O Googlebot não consegue aceder a ficheiros CSS e JS em seu blog

Se você recebeu um alerta do Search Console (ou notou no relatório de Cobertura/Páginas que recursos estão sendo bloqueados) dizendo que o Googlebot não consegue acessar arquivos CSS e JavaScript do seu site, o problema quase sempre está em uma regra do robots.txt bloqueando pastas como /wp-includes/, /wp-content/, /js/, /skin/ ou similares. A boa notícia é que a correção costuma levar poucos minutos.

A parte que realmente importa é entender por que isso afeta a indexação e usar as ferramentas certas para confirmar que o problema foi resolvido, já que o antigo "Testador de robots.txt" e a ferramenta "Buscar como o Google" não existem mais no Search Console atual.

Por que o Google precisa acessar CSS e JS

Desde a mudança para o Mobile-First Indexing, o Googlebot não lê apenas o HTML puro de uma página: ele renderiza o conteúdo de forma semelhante a um navegador, usando uma versão do Chromium para montar a página como um visitante real a veria. Isso significa que o layout final, a posição dos elementos, o que fica visível "acima da dobra" e até a responsividade para dispositivos móveis dependem dos arquivos CSS e JavaScript sendo carregados normalmente.

Quando o robots.txt bloqueia esses arquivos, o Googlebot enxerga uma versão incompleta ou quebrada da página. Na prática, isso pode levar a três problemas:

• o Google pode interpretar erroneamente que o conteúdo principal não é visível para o usuário, o que pesa negativamente em critérios de qualidade de página;
• elementos carregados via JavaScript (menus, textos dinâmicos, produtos renderizados por scripts) podem simplesmente não ser indexados;
• a avaliação de compatibilidade mobile pode ser prejudicada, já que o algoritmo não consegue confirmar se o design se adapta corretamente à tela.

Ou seja, o bloqueio não impede só o "acesso a um arquivo técnico": ele distorce a forma como o Google entende a própria página.

Como diagnosticar o bloqueio hoje

Guias mais antigos sobre esse assunto costumam indicar caminhos como "Índice do Google > Recursos Bloqueados" ou "Rastreamento > Buscar como o Google". Essas seções foram descontinuadas há anos na versão atual do Search Console. Os caminhos corretos hoje são dois, e o ideal é usar os dois em conjunto.

Técnicas de como fazer um artigo antigo continue sendo visto

1. Relatório de robots.txt

Dentro do Search Console, em Configurações > Rastreamento > relatório robots.txt, o Google mostra os arquivos robots.txt que encontrou nos principais hosts do seu domínio, quando cada um foi rastreado pela última vez e se houve algum aviso ou erro de processamento. É o ponto de partida para confirmar que o Google está lendo a versão mais recente do arquivo que está publicado no seu servidor.

2. Ferramenta de Inspeção de URL

Esta é a ferramenta que substituiu o antigo "Buscar como o Google". Cole a URL afetada na barra de inspeção, use a opção Testar URL ativa e, no resultado, abra a aba de página renderizada. Ali é possível ver Mais informações > Recursos da página, uma lista dos arquivos que a página tentou carregar e o status de cada um. Se um .css ou .js aparecer como "Bloqueado por robots.txt", você encontrou a causa exata.

Se você é desenvolvedor e quer testar regras de robots.txt localmente antes de publicar, o Google também mantém uma biblioteca de código aberto para interpretar o arquivo da mesma forma que o parser usado na Busca, útil para validar alterações sem depender só da interface do Search Console.

Corrigindo o robots.txt em sites WordPress

Na grande maioria dos casos, o bloqueio em sites WordPress vem de uma destas três linhas:

Disallow: /wp-includes/
Disallow: /wp-content/
Disallow: /wp-content/plugins/

O problema é que arquivos essenciais de estilo e script do tema e dos plugins normalmente ficam dentro de /wp-content/themes/ e /wp-content/plugins/, então bloquear a pasta inteira também bloqueia o CSS e o JS que dão forma visual ao site. A correção mais segura não é simplesmente apagar essas linhas sem critério, mas sim liberar especificamente o que precisa ser rastreado, mantendo bloqueios que realmente fazem sentido (como pastas de backup ou de configuração interna):

Disallow: /wp-content/
Allow: /wp-content/uploads/
Allow: /wp-content/themes/
Allow: /wp-content/plugins/

Se o seu site usa um plugin de SEO (Yoast, Rank Math ou similar), normalmente existe uma seção de edição do robots.txt direto no painel do plugin. Isso facilita o processo, mas é importante lembrar de um ponto técnico que muitas vezes gera confusão: não existe uma versão "só para o Google" do robots.txt separada da versão publicada no site. O Googlebot lê exclusivamente o arquivo que está de fato hospedado em seusite.com.br/robots.txt. Se você editar algo no Search Console ou em uma ferramenta de teste sem atualizar o arquivo real no servidor, a mudança não tem efeito nenhum no rastreamento.

Técnicas de como fazer um artigo antigo continue sendo visto

Como tornar o site menor e mais rápido com Gzip WordPress

E se o site for uma loja virtual com hospedagem compartilhada?

Esse cenário é mais delicado. Muitas plataformas de e-commerce em hospedagem compartilhada não dão acesso direto ao FTP ou ao arquivo robots.txt, então qualquer ajuste depende do suporte técnico da hospedagem. Nesses casos, vale diferenciar dois tipos de bloqueio que costumam aparecer juntos em arquivos antigos de plataformas como Magento:

• bloqueios de rotas funcionais, como /checkout/, /customer/, /catalogsearch/ ou /customize/, que normalmente fazem sentido manter bloqueadas porque são páginas de sistema, sem valor de busca;
• bloqueios de recursos visuais, como regras genéricas do tipo Disallow: /*.js$ ou Disallow: /*.css$, que são justamente as que impedem a renderização correta e devem ser removidas ou reescritas com exceções.

Se o suporte da hospedagem demorar para atualizar o arquivo, testar a URL na ferramenta de Inspeção de URL ajuda a confirmar, com dados reais, quais arquivos específicos continuam bloqueados, o que facilita muito a comunicação com o time técnico responsável.

Quanto tempo leva para o Google reconhecer a correção

Depois de publicar o robots.txt corrigido no servidor, não existe um prazo fixo garantido pelo Google. Na prática, o relatório de robots.txt tende a refletir a nova versão do arquivo já no próximo rastreamento, que costuma acontecer em poucos dias. Para acelerar a reavaliação de uma URL específica, use a Inspeção de URL e solicite o reprocessamento por lá; isso não garante um novo rastreamento imediato, mas coloca a página na fila de forma mais direta do que apenas esperar o ciclo normal do Googlebot.

Perguntas frequentes

Bloquear CSS e JS realmente derruba o ranqueamento?

Não existe uma penalização direta e automática por isso, mas o efeito indireto pode ser relevante: se o Google não consegue confirmar que a página é responsiva e que o conteúdo está visível, a avaliação de qualidade e experiência da página pode ser prejudicada, especialmente em sites que dependem de JavaScript para exibir conteúdo importante.

Preciso liberar todos os arquivos JS e CSS do site?

Não necessariamente todos. O objetivo é garantir que os arquivos que afetam a renderização visual e o conteúdo visível sejam acessíveis. Scripts internos que não influenciam a exibição da página (por exemplo, ferramentas administrativas) podem continuar bloqueados sem problema.

Alterar o robots.txt pelo plugin de SEO já resolve automaticamente?

Resolve a origem do bloqueio, mas vale sempre confirmar depois com a Inspeção de URL, já que a atualização do arquivo publicado no servidor é o que realmente importa para o Googlebot, não a tela do plugin em si.

Técnicas de como fazer um artigo antigo continue sendo visto

Como tornar o site menor e mais rápido com Gzip WordPress

GuestPost uma perda de tempo? Ou estratégia para criar backlinks?

Espero que tenha curtido o conteúdo sobre:
O Googlebot não consegue aceder a ficheiros CSS e JS em seu blog
Em DICAS BLOGS temos diversos artigos sobre este tema.