Googlebot também usa HEAD, OPTIONS, PUT, PATCH e DELETE, e o motivo é JavaScript

A maioria de quem administra servidores assume que o Googlebot vive de GET e, ocasionalmente, POST. Não é bem assim. Segundo publicação de Gary Illyes, do Google, no LinkedIn, resumida pelo Search Engine Roundtable, os crawlers da empresa também disparam requisições HEAD, OPTIONS, PUT, PATCH e DELETE. O volume é pequeno, mas o comportamento existe e tem implicações práticas para quem configura infraestrutura e analisa logs no Brasil.

O que Illyes disse

Segundo a fonte, Illyes contou que recebeu nas últimas semanas várias perguntas sobre se os crawlers do Google enviavam algo além de GET e POST. A resposta curta: sim. Esses cinco métodos adicionais representam, segundo ele, menos de 1,5% do total de requisições que os crawlers do Google enviam. Não é um fluxo relevante em volume, mas é real.

O motivo? JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) →. Na formulação dele, citada pela fonte, é "basicamente algum absurdo de JavaScript iniciando essas requisições" enquanto o mecanismo de renderização faz o trabalho dele. Ou seja: não é o crawler tomando decisões de escrita por conta própria. É a renderização de páginas que executam código no cliente (Web Rendering Service), e esse código dispara chamadas a APIs, chamadas essas que podem usar qualquer verbo HTTP que a aplicação implemente.

Por que isso importa na prática

O ponto sensível está nos verbos de escrita: PUT, PATCH e DELETE. Se uma página renderizada pelo Google contém JavaScript que faz um fetch para um endpoint de API, e esse endpoint não estiver devidamente protegido, o Google pode, ao renderizar, acabar disparando uma operação de escrita ou remoção. Não por malícia, mas porque o código da própria aplicação mandou.

A lição não é nova, mas o alerta é oportuno: operações que alteram estado nunca deveriam ser acionáveis sem autenticação e sem intenção explícita do usuário. Um endpoint DELETE acessível a partir de código client-side, sem verificação de sessão, é um problema de segurança independentemente do Googlebot. O crawler apenas expõe uma falha que já estava lá.

HEAD e OPTIONS são mais inofensivos e esperados: HEAD recupera cabeçalhos sem baixar o corpo (útil para checar Content-Type, tamanho ou cache), e OPTIONS faz parte do fluxo de preflight de CORS, comum quando JavaScript chama recursos de outra origem.

O que ajustar em servidor e logs

Algumas recomendações práticas, com o porquê de cada uma:

• Não bloqueie métodos no cegamente. Alguns firewalls de aplicação (WAF) e configurações defensivas bloqueiam tudo que não seja GET/POST. Isso pode interferir na renderização de páginas legítimas pelo Google. Verifique se seus endpoints necessários respondem a OPTIONS (preflight CORS) corretamente.
• Proteja verbos de escrita. Garanta que PUT, PATCH e DELETE exijam autenticação e tokens anti-CSRF. Isso vale para qualquer tráfego, não só o do Google.
• Filtre os logs por método. Ao auditar o acesso do Googlebot, não estranhe ver verbos além de GET. Confirme a origem validando o IP via DNS reverso, como o Google recomenda, antes de tirar conclusões. Um DELETE vindo de um user-agent que se diz Googlebot mas de IP falso é outra história.
• Meça o antes e o depois. Se você endurecer regras de método no servidor, acompanhe no Search Console eventuais quedas de renderização ou de indexação de páginas que dependem de JavaScript. Sem medição, o ajuste vira aposta.

O contexto maior

Esse detalhe reforça algo que quem trabalha com SEO↳SEO4 conteúdosPor que a transição do SEO clássico para a Otimização de Motores Generativos (GEO) exige que se repense a modelagem semânticaMarketing Tech · mai 2026O impacto da pesquisa e do SEO no comércio eletrônico: insights da State of Search Brasil 5Marketing Tech · fev 2025SEO por Elas 2025: Impulsionando e promovendo mulheres no Marketing DigitalMarketing Tech · fev 2025Ver tudo em Marketing Tech → técnico já vive: o Google não é mais um leitor passivo de HTML. Ele executa a aplicação. Quanto mais lógica você joga para o client-side, mais o comportamento de rastreamento passa a depender do que o seu JavaScript faz, incluindo chamadas de rede que você talvez nem lembre que existem.

O número de 1,5% deixa claro que não é para entrar em pânico nem reescrever a arquitetura. Mas é um bom lembrete para revisar dois pontos: se a segurança dos endpoints de escrita está correta e se a configuração de servidor não está silenciosamente atrapalhando a renderização. Ambos são baratos de verificar e caros de ignorar.

Fonte: Search Engine Roundtable