Guias de robots.txt por plataforma

Next.js robots.txt: como usamos App Router e MetadataRoute.Robots

Nosso fluxo para app/robots.txt, app/robots.ts, MetadataRoute.Robots, sitemap, cache, preview e deploy.

Por Robots.txt Tools Editorial TeamÚltima verificação em 2026-10-012 min de leitura

Método editorial: este guia documenta o processo de revisão da equipe editorial do Robots.txt Tools. A linguagem procedural em primeira pessoa descreve esse método; não representa alegação de trabalho para clientes ou casos pessoais.

Next.js robots.txt: como usamos App Router e MetadataRoute.Robots

No App Router nós escolhemos entre app/robots.txt e uma rota gerada em app/robots.ts ou app/robots.js.

Preferimos estático quando basta

Um arquivo simples reduz dependências e facilita auditoria.

Usamos MetadataRoute.Robots para geração

import type { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
  return { rules: { userAgent: '*', allow: '/' }, sitemap: 'https://example.com/sitemap.xml' }
}

Conferimos cache e dynamic

Rotas geradas podem ter comportamento de cache conforme a implementação. Nós verificamos a documentação e o deploy real.

Preview precisa de acesso real

Ambientes privados usam autenticação. Também evitamos gerar Sitemap: apontando para domínio de preview.

Validamos produção

Abrimos /robots.txt, usamos o validator e o tester. Divergências levam a revisar routing, environment variables, cache e deploy.

App Router: estático quando possível

O Next.js atual suporta app/robots.txt estático e app/robots.ts / app/robots.js gerado com MetadataRoute.Robots. Rotas metadata geradas podem ser cacheadas conforme a implementação, então confirmamos versão do framework e resposta pública em vez de presumir recomputação em toda request.

Preferimos arquivo estático para política estável. Só geramos quando há ganho real, como vários grupos ou hostname controlado pelo ambiente. Evitamos chamadas remotas dentro da rota: robots.txt não deve depender de um serviço de configuração externo para responder.

Falhas que entram no smoke test

Testamos sitemap com domínio de preview, middleware/proxy interceptando /robots.txt, coexistência acidental de arquivo estático e rota gerada, cache antigo e branch de staging em produção. O teste final verifica status, content-type, body e hostname real do sitemap no domínio público.

Mantemos a origem do hostname previsível

Quando o sitemap ou a URL canônica depende de variável de ambiente, usamos um valor de produção explícito em vez de reconstruir o host a partir de uma request qualquer. Também cobrimos /robots.txt no smoke test de deploy. Assim, uma configuração ausente falha cedo e não publica silenciosamente um sitemap com domínio de preview ou uma policy diferente da planejada.

Guias relacionados