Prioridade de Sitemap

TL;DR — A prioridade de sitemap é um número de 0.0 a 1.0 que você pode colocar em cada URL do seu sitemap XML para indicar o quão importante ela é. Aqui está a versão curta: O Google ignora isso, e o protocolo nunca definiu isso como uma instrução absoluta de ranqueamento. Não perca tempo ajustando esses controles deslizantes no seu plugin de SEO — gaste esse tempo com links internos e uma estrutura de site limpa.

O que é prioridade de sitemap

Um sitemap XML é uma lista das suas URLs que você entrega aos mecanismos de busca para que eles possam encontrar suas páginas. O formato original de sitemap permitia anexar duas tags opcionais extras a cada URL:

• <priority> — um número de 0.0 a 1.0 (o padrão é 0.5) que deveria indicar o quão importante aquela página é em comparação com suas outras páginas.
• <changefreq> — uma palavra como daily, weekly ou monthly que deveria indicar com que frequência a página muda.

A ideia parecia razoável: marque sua página inicial como 1.0, marque uma página antiga arquivada como 0.2, diga ao Google que sua seção de notícias muda daily, e ele rastrearia e ranquearia de acordo.

O problema: não funciona

Não foi assim que aconteceu. O Google ignora ambas as tags completamente. Não “pesa menos” — ignora. A própria documentação do Google diz isso em palavras claras: “Google ignores <priority> and <changefreq> values.” O Bing faz o mesmo.

Definir uma página com prioridade 1.0 não faz o Google rastreá-la primeiro, indexá-la mais rápido ou ranqueá-la mais alto. Definir changefreq como daily não faz o Google visitar diariamente. Esses números vão para o sitemap e os mecanismos de busca os descartam.

Por que os plugins de SEO ainda mostram isso?

Esta é a parte confusa. Se você usa um plugin de SEO para WordPress, ainda pode ver opções de prioridade e frequência de alteração nas configurações do sitemap. Isso é um resquício de anos atrás, quando o formato de sitemap era novo e ninguém tinha certeza se as tags importavam. Elas persistem na tela de configurações mesmo que os mecanismos de busca que importam ignorem o que você definir. Você pode deixá-las de lado com segurança.

O que realmente diz ao Google que uma página é importante

Se a prioridade está morta, como você sinaliza que uma página importa? A resposta honesta é: da mesma forma que você sempre deveria ter feito.

• Link para ela. Páginas para as quais você linka muito — especialmente a partir da sua página inicial e menu principal — são lidas como importantes. Este é o verdadeiro sinal de “prioridade”.
• Mantenha-a perto da página inicial. Uma página a um clique da página inicial parece mais importante do que uma enterrada a seis cliques de profundidade.
• Coloque-a na navegação. Onde uma página está nos seus menus e categorias diz aos mecanismos de busca (e às pessoas) o que você considera importante.
• Mantenha seu sitemap limpo e preciso. Estar em um sitemap organizado com uma data de última modificação honesta faz mais do que qualquer número de prioridade dentro dele.

Quer a história completa — as citações exatas do Google e do Bing, por que essas tags falharam e o que usar em vez disso — mude para a aba Avançado.

TL;DR — <priority> e <changefreq> são tags opcionais do sitemaps.org destinadas a ranquear a importância relativa de uma URL e sua taxa de alteração esperada. O Google ignora ambas — a documentação atual do Search Central diz “Google ignores <priority> and <changefreq> values,” Illyes chamou a prioridade de “a bag of noise” (2017), Mueller disse que ela “doesn’t really play that much of a role” (2015). Esses campos são autodeclarados, e a explicação amplamente repetida na indústria — que nem o Google nem o Bing afirmam diretamente — é que eles foram universalmente manipulados: todo mundo definia 1.0/daily, então os campos não carregavam informação. A única tag de sitemap que os mecanismos usam é um <lastmod> preciso. Os sinais reais de importância são links internos, profundidade de clique, inclusão no sitemap, frequência de rastreamento observada e proeminência na navegação — todos observados, nenhum declarado.

Para que as tags foram projetadas

Ambas as tags vêm do protocolo sitemaps.org, a especificação 0.9 que define o formato de sitemap XML que o Google e o Bing leem.

<priority> aceita um valor de 0.0 a 1.0, com padrão de 0.5. Seu trabalho declarado é descrever “a prioridade desta URL em relação a outras URLs do seu site.” A palavra-chave é relativa — nunca foi feita para ser uma pontuação de importância absoluta em toda a web, apenas uma classificação das suas próprias páginas entre si. E até mesmo a especificação que a inventou se esquivou: ela diz claramente que “a prioridade que você atribui a uma página provavelmente não influenciará a posição das suas URLs nos resultados de pesquisa de um mecanismo de busca.” Os próprios criadores da tag disseram que ela não era uma alavanca de ranqueamento.

<changefreq> aceita um de always, hourly, daily, weekly, monthly, yearly ou never. A especificação é explícita ao dizer que esse “valor fornece informações gerais aos mecanismos de busca e pode não se correlacionar exatamente com a frequência com que eles rastreiam a página” — é “considerado uma dica e não um comando.” Os mecanismos de busca sempre foram livres para rastrear novamente uma página never para verificar surpresas e ignorar uma alegação daily se o conteúdo permanecesse inalterado.

Então, desde o início, essas eram dicas autorrelatadas que a própria especificação descartava. O que aconteceu em seguida é que os dois maiores mecanismos pararam de lê-las completamente.

Posição do Google: “ignora” — e é consistente há uma década

A documentação atual e permanente do Google é direta. Na página Criar e enviar um sitemap, na seção sobre tags opcionais, diz: “O Google ignora os valores de <priority> e <changefreq>.” Não “dá menos peso a”, não “desprioriza”. Ignora. Isso é documentação, não um tweet isolado.

E não é novidade. As declarações públicas vêm de anos:

• 2015 — John Mueller. Em um hangout do Webmaster Central, perguntado se prioridade e frequência importam: “Prioridade e frequência de mudança não desempenham mais um papel tão grande com Sitemaps… é muito melhor apenas especificar o timestamp diretamente.”
• 2017 — Gary Illyes. Perguntado no Twitter sobre os campos priority e changefreq, ele respondeu: “nós os ignoramos. É essencialmente um saco de ruído.”

Dois Googlers nomeados, com dois anos de diferença, dizendo a mesma coisa que a documentação diz hoje. Isso é política estabelecida, repetida e de longa data — não é boato nem mudança recente.

Uma nota de rodapé que vale destacar: alguns comentários de 2017 alegavam que o Google ignorava também a data <lastmod>. Isso agora está desatualizado. A documentação atual do Google diz explicitamente que o Google usa <lastmod> — “se for consistente e verificavelmente… preciso.” Não confunda os dois: <priority>/<changefreq> são ignorados; um <lastmod> honesto não é.

O Bing trata isso de forma diferente? Não.

Esta é a brecha que as pessoas buscam: “claro, o Google ignora, mas talvez o Bing ainda se importe.” Não se importa. O próprio post de fevereiro de 2023 no blog de webmaster do Bing sobre lastmod diz que, como esses campos “não refletem com precisão a probabilidade de uma página ser atualizada ou a importância relativa de uma URL,” “o Bing desconsidera amplamente esses campos.” No mesmo post, o Bing diz que está “reformulando nossa pilha de escalonamento de rastreamento para utilizar melhor as informações fornecidas pela tag lastmod” — exatamente a jogada do Google. Ambos os mecanismos abandonaram as tags autorrelatadas e apostaram naquela que podem verificar.

O Bing reforçou isso no seu post de julho de 2025 sobre sitemaps na busca com IA: XML “continua sendo o formato preferido… pois suporta metadados estruturados como lastmod, que ajudam o Bing a avaliar a atualidade e a relevância do conteúdo de forma mais eficaz.” Novamente — lastmod, não priority.

Por que essas tags provavelmente foram ignoradas (uma explicação, não uma oficial)

O Google e o Bing documentam que ignoram priority e changefreq. Nenhuma empresa publicou por que — então trate o que segue como a explicação consolidada do setor, não como uma justificativa declarada do Google ou do Bing.

A leitura comum entre profissionais é um problema de confiança: um sinal só é útil se for difícil de falsificar e se correlacionar com algo real, e priority/changefreq não são nenhuma das duas coisas:

• Eles são autodeclarados. Você os declara; ninguém os verifica. Um mecanismo de busca não tem como confirmar se sua página 1.0 é realmente mais importante que sua página 0.4 — você apenas digitou os números.
• A explicação amplamente citada é que eles foram manipulados. A teoria — repetida em todo o setor de SEO, não uma linha da documentação do Google ou do Bing — é que webmasters previsivelmente definem quase todas as URLs como 1.0 e daily para parecerem importantes. Quando tudo afirma prioridade 1.0, nada afirma — a variância do campo entraria em colapso e ele deixaria de carregar informação.

Esse é um mecanismo plausível e se encaixa no padrão que os mecanismos de busca descrevem para outros campos autodeclarados, mas é inferência, não causalidade confirmada.

O que está documentado é o contraste com <lastmod>. O Google o usa, mas condicionalmente — “se for consistente e verificavelmente… preciso”, o que ele verifica “comparando com a última modificação da página”. Essa verificação embutida é uma distinção real e com fonte entre os dois tipos de tag: independentemente de a manipulação ser o motivo específico pelo qual priority morreu, a verificabilidade de lastmod é por que o Google pode confiar nele de uma forma que priority nunca conquistou.

O que realmente sinaliza a importância de uma página

Priority não é substituído por outra tag que você define — é substituído por sinais que os mecanismos de busca observam em vez de sinais que você declara. Esta é a seção que mais importa:

Alguns desses merecem mais atenção:

A frequência de rastreamento é observada, não declarada. Você não pode dizer ao Google para rastrear uma página diariamente via changefreq. O próprio modelo de demanda de rastreamento do Google decide isso com base em popularidade (“URLs que são mais populares na Internet tendem a ser rastreadas com mais frequência para mantê-las mais atualizadas em nossos sistemas”) e obsolescência (“nossos sistemas querem rastrear documentos com frequência suficiente para captar quaisquer mudanças”), conforme sua documentação sobre orçamento de rastreamento. A popularidade é em grande parte uma função de links; a obsolescência é uma função da sua taxa real de mudanças refletida em um lastmod honesto. Nenhuma das duas é algo que você define em uma tag.

lastmod é a tag para acertar. Mas acerte — não carimbe a data de hoje em tudo, o que é apenas outra forma de manipular um sinal e faz com que suas datas sejam desacreditadas. Atualize-a apenas em mudanças significativas de conteúdo.

Você ainda deve incluir priority e changefreq?

Na prática: não tem problema deixá-los de fora completamente. Incluí-los não é prejudicial, mas também não é útil, e quando seu gerador os define com o mesmo valor padrão, eles não sinalizam absolutamente nada. A maioria das ferramentas de sitemap e plugins de SEO ainda os emite por padrão (e ainda expõem controles deslizantes de prioridade em sua interface), que é o principal motivo pelo qual esse mito não morre. Removê-los não prejudicará seu SEO; um sitemap enxuto com <loc> mais um <lastmod> preciso é a prática recomendada atual. Seu tempo é muito melhor gasto em links internos e arquitetura do site.

Onde isso se encaixa

Este é um tópico de estágio de descoberta. Se você está construindo ou depurando sitemaps de forma mais ampla, veja o hub de sitemaps, o mergulho profundo em sitemap XML e o índice de sitemap para sites grandes. Para o lado do “o que realmente funciona em vez disso”, links internos, profundidade de rastreamento e frequência de rastreamento são as próximas páginas a ler.

Mitos, rapidamente

• “Prioridade 1.0 faz o Google rastrear/ranquear minha página primeiro.” Não — ignorada; a demanda de rastreamento (popularidade + desatualização) decide, não sua declaração.
• “changefreq=daily faz o Google rastrear diariamente.” Não — ignorado; até a especificação chamou isso de dica que os mecanismos podem desconsiderar.
• “A prioridade afeta o ranqueamento.” Nunca afetou — a própria especificação do sitemaps.org dizia que é “improvável que influencie” o ranqueamento.
• “Talvez o Bing ainda use esses campos.” Não — o Bing “desconsidera amplamente esses campos.”
• “Já que o Google também ignora lastmod, nada disso importa.” Desatualizado — os documentos atuais do Google dizem que ele usa um lastmod preciso.
• “Remover prioridade/changefreq vai prejudicar meu SEO.” Não — um sitemap enxuto é prática padrão.

Resumo de IA

Uma visão condensada da versão Avançada:

• Prioridade de sitemap = a tag opcional <priority> (0.0–1.0, padrão 0.5) do protocolo sitemaps.org, destinada a ranquear a importância de uma URL em relação a outras páginas do mesmo site. <changefreq> é sua companheira (uma dica de frequência de alteração).
• O Google ignora ambas — literalmente. Seus documentos dizem “O Google ignora os valores de <priority> e <changefreq>.” Illyes (2017): “um saco de ruído.” Mueller (2015): “não desempenha um papel tão grande.” Isso é uma política consistente e de uma década.
• O Bing também as ignora. O blog do Bing de 2023: ele “desconsidera amplamente esses campos” e está investindo em lastmod em vez disso. Fecha a brecha do “talvez o Bing se importe”.
• Nunca foi um fator de ranqueamento, nem mesmo por design — a especificação do sitemaps.org dizia que a prioridade é “improvável que influencie a posição de suas URLs” nos resultados.
• Por que provavelmente morreram: autorrelatados e, de acordo com a explicação comum da indústria — não declarada diretamente pelo Google ou Bing — universalmente manipulados (todo mundo definia 1.0/daily), então os campos não carregavam informação. lastmod sobreviveu porque é verificável.
• O que realmente sinaliza importância: número de links internos, profundidade de clique, inclusão em um sitemap limpo, um <lastmod> preciso e destaque na navegação — tudo observado, não declarado. A frequência de rastreamento é um resultado de popularidade + desatualização, não algo que você define.
• Orientação prática: tudo bem omitir ambas as tags; inofensivo, mas inútil mantê-las; removê-las não prejudicará o SEO. Plugins de SEO ainda expõem controles deslizantes de prioridade, que é o motivo pelo qual o mito persiste.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca e do protocolo que define as tags.

Google

• Criar e enviar um sitemap — o documento vigente que afirma “O Google ignora os valores de <priority> e <changefreq>” e explica quando <lastmod> é usado.
• Otimize seu orçamento de rastreamento — demanda de rastreamento como popularidade + desatualização, ou seja, o que realmente impulsiona a frequência de rastreamento em vez de changefreq.

Bing / Microsoft

• The Importance of Setting the “lastmod” Tag in Your Sitemap (fev. 2023) — diz que o Bing “largely disregards these fields” (priority/changefreq) e está reformulando o agendamento de rastreamento em torno de lastmod.
• Keeping Content Discoverable with Sitemaps in AI-Powered Search (jul. 2025) — XML é preferido porque suporta lastmod para frescor; não há menção a priority como sinal.

Protocolo (origem das tags)

• Protocolo sitemaps.org — as definições originais de <priority> e <changefreq>, incluindo a admissão da própria especificação de que priority “not likely to influence the position of your URLs in a search engine’s result pages.”

Citações da fonte

Declarações oficiais do Google e do Bing. Cada link salta para a passagem citada na página de origem.

Google — a documentação atual

• “Google ignores <priority> and <changefreq> values.” (tradução) «O Google ignora os valores de <priority> e <changefreq>.» — Documentação do Google Search Central, Build and Submit a Sitemap. Ir para a citação
• “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” (tradução) «O Google usa o valor de <lastmod> se ele for consistente e verificavelmente preciso (por exemplo, comparando com a última modificação da página).» — mesmo documento, sobre a única tag que o Google lê. Ler o documento

Gary Illyes, Google (2017)

• “we ignore those. It’s essentially a bag of noise.” (tradução) «Nós ignoramos esses campos. É essencialmente um saco de ruído.» — Gary Illyes, respondendo no Twitter a uma pergunta sobre os campos priority e changefreq do sitemap, 28 de março de 2017. Ler a cobertura

John Mueller, Google (2015)

• “Priority and change frequency doesn’t really play that much of a role with Sitemaps anymore. This is something where we’ve tried various things but essentially, if you have a sitemap file and you are using it to tell us about the pages that were changed or updated, it is much better to just specify the time stamp directly so that we can look into our internal systems and say we haven’t crawled since this date therefore we should crawl again. And just crawling daily doesn’t make much sense if your content doesn’t change.” (tradução) «Priority e change frequency não têm mais tanta importância com Sitemaps. É algo em que tentamos várias coisas, mas essencialmente, se você tem um arquivo de sitemap e o usa para nos informar sobre as páginas que foram alteradas ou atualizadas, é muito melhor especificar diretamente o timestamp para que possamos consultar nossos sistemas internos e dizer: não rastreamos desde esta data, portanto devemos rastrear novamente. E rastrear diariamente não faz muito sentido se o seu conteúdo não muda.» — John Mueller, Google Webmaster Central hangout, 8 de maio de 2015. Ler a cobertura

Microsoft Bing (2023)

• “Bing largely disregards these fields.” (tradução) «O Bing desconsidera amplamente esses campos.» — Blog do Bing Webmaster, sobre <changefreq> e <priority>, fevereiro de 2023. Ir para a citação

Erros que as pessoas realmente cometem com essas tags

Coisas concretas que vejo equipes e plugins fazerem com priority e changefreq — cada uma custa tempo ou, em um caso, danifica silenciosamente um sinal que importa.

Ajustar manualmente os valores de prioridade página por página. Sentar e decidir que esta página de categoria é 0.7 e aquela é 0.5 parece otimização. Não é — o Google e o Bing ignoram o campo, então cada minuto gasto nisso produz zero efeito de rastreamento ou ranqueamento. Gaste esse tempo em links internos ou arquitetura do site; essas ações realmente movem a agulha na importância percebida.

Definir o changefreq de cada URL como daily ou hourly para parecer importante. Esse é o tipo de manipulação amplamente culpada por fazer os mecanismos de busca perderem a confiança no campo — embora nem o Google nem o Bing afirmem esse motivo diretamente. O que está documentado é mais simples: quando cada URL declara daily, o campo não carrega informação distintiva, e a própria especificação do sitemaps.org o chama de “uma dica e não um comando” que os mecanismos podem ignorar de qualquer forma. Deixe de fora.

Construir lógica personalizada de pontuação de prioridade no seu gerador de sitemap (ponderando por profundidade da página, contagem de palavras ou receita) é um esforço real de engenharia gasto em um campo que nenhum mecanismo lê. Se você tem esse tipo de dado de rastreamento/página disponível, aponte-o para recomendações de links internos ou posicionamento na navegação — esses são os fatores que realmente se correlacionam com a importância percebida.

Carimbar a data de hoje em <lastmod> para cada URL para parecer atualizado. Ao contrário de priority e changefreq, isso pode sair pela culatra: o Google diz que usa <lastmod> apenas “se for consistente e verificavelmente… preciso”, verificado comparando com a data real de modificação da página. Falsifique em todo o site e você arrisca o único sinal de sitemap que realmente é lido. Atualize-o apenas quando o conteúdo mudar significativamente.

Tratar “corrigir valores de prioridade” como um item em uma auditoria de SEO. Parece trabalho produtivo, mas não entrega nada mensurável. Substitua esse item por verificar a limpeza do sitemap e a precisão do <lastmod> — a auditoria ainda parece completa, mas agora está verificando algo que importa.

Supor que os controles deslizantes de prioridade do seu plugin de SEO valem a pena configurar por template. Quaisquer que sejam os valores padrão do plugin ou que você possa substituir, o resultado para rastreamento e ranqueamento é idêntico: ignorado. Deixe os controles deslizantes de lado e gaste o tempo de configuração confirmando que o plugin não está emitindo XML malformado ou URLs duplicadas.

Quais mecanismos realmente usam essas tags

Uma tabela de referência rápida construída a partir das declarações oficiais nas abas Documentos Oficiais e Citações — nada aqui é inferido, apenas o que cada fonte diz sobre seu próprio mecanismo.

Esta tabela cobre apenas Google e Bing porque são os dois mecanismos com declarações registradas no briefing — não vou adivinhar o comportamento do Yandex ou de qualquer outro mecanismo sem uma citação com fonte.

Decisão rápida sobre tags de sitemap

Devo incluir priority e changefreq no meu sitemap?

Uma pequena lista de verificação pré-publicação para decidir o que fazer com essas tags — e, mais importante, acertar o <lastmod>, já que é o que importa.

• Verifique o que seu gerador de sitemap ou plugin de SEO realmente emite. Abra um arquivo de sitemap de exemplo e procure por <priority>/<changefreq> em algumas URLs — a maioria dos plugins ainda os adiciona por padrão.
• Se você tem ajustado manualmente os valores de prioridade, pare. Isso não tem efeito no rastreamento ou no ranqueamento; redirecione esse tempo para links internos.
• Decida: deixe as tags ou remova-as para um arquivo mais enxuto. Ambas as opções são válidas — incluí-las não é prejudicial, apenas não é útil também. Como abordado na aba Avançado, um sitemap enxuto com <loc> e um <lastmod> preciso é a recomendação mais atual.
• Se você removê-las, valide o resultado. Execute o arquivo no Validador de Sitemap para confirmar que o XML ainda está bem formado e que nada mais quebrou.
• Audite uma amostra das datas de <lastmod> em relação às datas reais de alteração de conteúdo no seu CMS. Uma tag precisa gera confiança com a verificação do Google; um carimbo genérico de “hoje” em páginas inalteradas a corrói.
• Se você regenerar o sitemap com uma ferramenta, prefira uma que só emita <lastmod> quando tiver evidências reais para isso em vez de uma que invente uma data para cada URL — o Gerador de Sitemap XML faz isso emitindo lastmod apenas quando a página fornece evidências para isso.

A auditoria de sinais reais: um framework de 4 etapas para importância de página

Como a prioridade está morta, esta é a maneira repetível de realmente descobrir — e melhorar — quais páginas são lidas como importantes pelos mecanismos de busca. Execute-a por seção ou template, não por URL individual.

Etapa 1 — Censo de links. Conte os links internos apontando para cada URL, ponderados por links de páginas de alto valor (homepage, navegação principal, páginas topo de categoria). Este é o substituto real para um número de prioridade declarado — é observado, não autodeclarado.

Etapa 2 — Verificação de profundidade de clique. Meça a quantos cliques cada URL está da homepage. Páginas com vários cliques de profundidade são lidas como menos importantes estruturalmente, independentemente de qualquer tag que você defina nelas.

Etapa 3 — Auditoria de sitemap e <lastmod>. Confirme se a URL está em um sitemap limpo, somente com canônicas, e que seu <lastmod> está presente e é honesto. Estar em um sitemap organizado com uma data precisa é um sinal real; estar ausente, ou em um sitemap cheio de URLs noindexed ou redirecionadas, não é.

Etapa 4 — Revisão de proeminência na navegação. Verifique onde a página está nos seus menus, breadcrumbs e hierarquia de categorias. A posição aqui é uma declaração estrutural de importância que tanto usuários quanto mecanismos de busca leem da mesma forma.

Pontue as páginas combinando todas as quatro — uma página que é bem linkada, rasa, corretamente incluída no sitemap e proeminente na navegação é genuinamente importante. Uma página que você marcaria como 1.0 no modelo antigo, mas que falha em todas as quatro verificações, não é importante, não importa qual número você digitou em uma tag que ninguém lê.

Kit de ferramentas: encontrando e removendo tags de prioridade/changefreq

Como a recomendação é “tudo bem deixá-las de fora”, aqui está como verificar se seu sitemap as tem e removê-las se você decidir.

Regex para corresponder a um elemento <priority> ou <changefreq> (para remoção ou verificação):

<(priority|changefreq)>[^<]*<\/\1>

• (priority|changefreq) — grupo de captura 1, corresponde a qualquer um dos nomes de tag.
• [^<]* — o conteúdo de texto da tag (um número ou uma palavra como daily).
• <\/\1> — a tag de fechamento correspondente, via uma referência reversa ao grupo 1, então <priority> só fecha com </priority>.

Python — remova ambas as tags de um arquivo de sitemap:

import re

with open("sitemap.xml", "r", encoding="utf-8") as f:
    xml = f.read()

# Remove <priority>...</priority> and <changefreq>...</changefreq> elements,
# including any surrounding whitespace/newline.
cleaned = re.sub(r"\s*<(priority|changefreq)>[^<]*</\1>", "", xml)

with open("sitemap-clean.xml", "w", encoding="utf-8") as f:
    f.write(cleaned)

macOS / Linux — contagem rápida de quantas URLs carregam as tags:

grep -oE '<(priority|changefreq)>' sitemap.xml | sort | uniq -c

Windows PowerShell — mesma verificação:

Select-String -Path sitemap.xml -Pattern '<priority>|<changefreq>' -AllMatches |
  ForEach-Object { $_.Matches } | Group-Object Value | Select Name, Count

Console do Chrome DevTools — busque e verifique um sitemap ao vivo (cole no painel Console em qualquer página, editando a URL):

fetch('/sitemap.xml')
  .then(r => r.text())
  .then(xml => {
    const priority = (xml.match(/<priority>/g) || []).length;
    const changefreq = (xml.match(/<changefreq>/g) || []).length;
    console.log({ priority, changefreq });
  });

XPath — para uma extração personalizada do Screaming Frog para sinalizar se uma URL de sitemap rastreada carrega essas tags:

//*[local-name()='url']/*[local-name()='priority']

(swap priority for changefreq for the other tag; local-name() is used because sitemap XML is namespaced, so a plain //priority won’t match).

Depois de remover as tags (ou decidir mantê-las), execute o resultado pelo Validador de Sitemap para confirmar que o XML ainda está bem formado.

Teste-se: Prioridade de Sitemap

Cinco perguntas rápidas sobre as tags priority e changefreq e o que realmente sinaliza importância. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus artigos relacionados

• Guia do Iniciante para SEO Técnico — onde sitemaps e descoberta se encaixam no panorama geral.
• Robots.txt e SEO: Tudo o que Você Precisa Saber — o outro lado do controle de rastreamento que as pessoas confundem com tags de sitemap.
• A História de Bloquear 2 Páginas com Alto Ranqueamento com Robots.txt — um experimento de primeira parte sobre como os controles de rastreamento realmente se comportam, em vez do que as pessoas assumem.

Da indústria

• Google — Criar e Enviar um Sitemap — o documento principal; “O Google ignora os valores de <priority> e <changefreq>.”
• Bing — A Importância de Definir a Tag “lastmod” no Seu Sitemap — o Bing “desconsidera amplamente esses campos.”
• Protocolo sitemaps.org — a especificação que define <priority>/<changefreq> e admite que a prioridade “provavelmente não influencia” o ranqueamento.
• Search Engine Roundtable — Google: Campo de Prioridade de Sitemap É ‘Um Saco de Ruído’ — a cobertura de Barry Schwartz sobre a troca de mensagens de Illyes em 2017.
• Search Engine Roundtable — Google Minimiza o Uso de Prioridade e Frequência de Alteração no Arquivo de Sitemap XML — o hangout de Mueller em 2015.
• Ahrefs — Como Criar um Sitemap XML (e Enviá-lo ao Google) — o guia de Joshua Hardwick; recomenda deixar lastmod, changefreq e priority de fora para manter os sitemaps enxutos.

Registro de alterações