Sitemap XML moderno: prioridade, lastmod e o que ignorar

Em fevereiro de 2026 auditamos 41 sitemaps de clientes enterprise e encontramos o mesmo padrao: priority em 0.8 para tudo, changefreq mentindo 'daily' em paginas estaticas, e lastmod batendo a data do deploy mesmo quando o conteudo nao mudou. O Googlebot ja avisou ha anos que priority e changefreq sao ignorados, mas lastmod virou sinal de scheduling de crawl. Quando voce mente em lastmod, perde credibilidade no proximo ciclo. Esse post mostra o que realmente importa, com dados de log e Search Console de quatro tenants entre 12k e 4.2M URLs indexaveis.

Comece pelo essencial: sitemap precisa listar apenas URLs canonicas, 200 OK, indexaveis e que voce quer no indice. Parece obvio, mas 73% das auditorias que rodamos em 2026 ainda tinham URLs 301, paginas com noindex ou parametros UTM listados. O crawler interpreta isso como ruido e reduz prioridade do dominio. Use lighthouse + screaming frog para cruzar o sitemap com o status code real. Se voce ainda nao tem esse processo, leia Como auditar SEO on-page sem cair em achismos antes de continuar otimizando o XML.

Sobre o lastmod: ele precisa refletir mudanca significativa de conteudo, nao mudanca de timestamp do CMS. Edicao do alt de uma imagem nao muda lastmod. Reescrever 40% do corpo, atualizar tabelas, trocar a H1, sim. Em estudo do Gary Illyes confirmado em janeiro de 2026, o Google usa lastmod como dica e ajusta a frequencia se voce mantiver consistencia por 4-6 semanas. Mentir uma vez tira voce da fila por meses. Para entender como decidir o que vale reescrever, veja Reescrever ou refazer: a decisao por dados de SERP e Content decay: identificando posts que estao perdendo trafego.

Segmente seus sitemaps por tipo e por velocidade de mudanca. Um sitemap de PDPs muda diariamente em e-commerce; PLPs mudam quando o merchandising roda; blog muda quando voce publica. Misturar tudo num sitemap.xml monolitico de 50MB e o erro classico. A recomendacao do protocolo continua: 50.000 URLs ou 50MB descompactados por arquivo. Para sites grandes use sitemap index, separe por idioma, por tipo de pagina, e cruze com hreflang sem dor: implementacao para sites multilingues. Em e-commerce especificamente, divida PLP de PDP, e ataque cada um com a estrategia certa via On-page para e-commerce: PLP vs PDP sem canibalizar.

O que ignorar com confianca: priority, changefreq, image:image em sites com imagens lazy bem marcadas, e video:video se voce ja tem Schema VideoObject. O Google deprecou tags de news em sitemap geral em 2023; news quer sitemap proprio. Nao coloque URLs paginadas (?page=2) se voce ja tem rel=prev/next ou view-all canonical. Nao liste tag pages se elas nao tem trafego organico medido nos ultimos 90 dias - elas comem crawl budget. Se voce ainda nao mediu isso, Crawl budget: quando se preocupar e como medir tem o passo a passo com BigQuery.

Automatize a geracao a partir do banco, nao do crawler. Crawler-based sitemaps sao lentos, capturam erros de roteamento e geram lastmod errado. Em PostgreSQL, uma view materializada com updated_at do conteudo (nao da row) resolve. Pingue o Google via Search Console API em vez do antigo ping endpoint, que foi descontinuado em junho de 2023. Confirme com log file analysis se o Googlebot esta lendo o sitemap diariamente - se nao esta, voce tem problema de crawl mais profundo, descrito em Log file analysis: o que o Googlebot esta realmente fazendo.

Takeaway pratico: hoje a noite, baixe seu sitemap.xml, conte URLs com status != 200 e URLs com lastmod identico ao de outras 100 paginas. Se passar de 5% em qualquer um dos dois, voce esta queimando crawl. Corte tudo que nao for canonical 200 indexavel, segmente por tipo, e deixe o lastmod contar a verdade. Em quatro semanas voce ve mudanca em 'Paginas rastreadas por dia' no GSC. Eh chato, e funciona.