Rank Math: sitemap não atualiza? 6 causas e o fix

O sintoma: o Google trava no mesmo número de páginas descobertas

Você publica, o post aparece no site, responde 200, está com index, follow — e o Search Console continua dizendo que descobriu o mesmo número de páginas de três semanas atrás. Abre o post-sitemap.xml no navegador e o post novo não está lá. Nenhum erro de PHP, nenhum aviso vermelho no painel.

Esse é o modo de falha mais caro do Rank Math, porque ele é silencioso. O plugin não avisa que está servindo uma cópia velha do XML. Do lado do Google, o efeito é o mesmo de nunca ter publicado — e como o Rank Math não expõe nenhum indicador de “sitemap regenerado em”, você só descobre olhando o XML na mão ou vendo o número travar no Search Console semanas depois.

No nosso caso — este site, julho de 2026 — eram 8 posts já no ar e invisíveis para o sitemap. Não era um post: era um mês de trabalho fora do índice. Abaixo estão as 6 causas em ordem de frequência, o teste que separa uma da outra, e o caminho que a maioria dos tutoriais não cobre: como corrigir sem ter acesso ao wp-admin.

Prove que é cache antes de mexer em configuração

Quase todo tutorial começa mandando você revirar as opções do plugin. Errado: 3 em cada 4 casos são cache, e mexer em configuração antes de saber disso só adiciona variável. São três testes de dois minutos.

Teste 1 — o XML muda com um parâmetro inútil? Abra a URL do sitemap com uma query string aleatória:

https://seusite.com.br/post-sitemap.xml?cachebuster=123

Se com o parâmetro o post novo aparece e sem ele não, o cache é de página (servidor, plugin de cache ou CDN), não do Rank Math. Cache de página normalmente varia por URL completa, então a query string entrega uma versão gerada ao vivo.

Teste 2 — o cabeçalho de resposta confessa. Peça só os headers e olhe o cabeçalho de cache da sua stack:

curl -sI https://seusite.com.br/post-sitemap.xml | grep -i -e cache -e age

Em servidor LiteSpeed, x-litespeed-cache: hit num arquivo .xml é o diagnóstico fechado: o servidor está entregando uma cópia guardada. Em Cloudflare, olhe cf-cache-status. Um age alto também denuncia.

Teste 3 — o lastmod do índice bate com a realidade? Abra o sitemap_index.xml e compare o <lastmod> de cada sub-sitemap com a data do seu último post. Se o índice diz que o post-sitemap foi modificado antes da sua última publicação, o índice também está velho — e aí o problema está em camada anterior aos posts.

Com esses três resultados na mão você já sabe se vai para a Causa 1, para a Causa 2, ou se é realmente configuração.

Causa 1 — o transient cache do próprio Rank Math

O Rank Math guarda o sitemap gerado em transients do banco para não reconstruir o XML a cada requisição. É uma decisão correta de performance que vira armadilha quando a invalidação não dispara — e ela não dispara de forma confiável quando o post é criado ou editado fora do wp-admin: via REST API, via WP-CLI, por importador, por plugin de publicação automática.

É exatamente o que acontece aqui: o nosso motor de conteúdo publica pela REST API. O post nasce, entra no banco, responde 200 — e o transient do sitemap continua com a versão anterior, sem ele.

O desligamento do cache é um filtro oficial documentado pelo próprio Rank Math — não é gambiarra. E não é caso isolado: a thread do suporte no WordPress.org tem o mesmo relato repetido por anos.

// Desliga o cache de transients do sitemap do Rank Math.
// Custo: o XML e reconstruido a cada requisicao (alguns ms a mais).
// Beneficio: post publicado por REST/CLI entra no sitemap na hora.
add_filter( 'rank_math/sitemap/enable_caching', '__return_false' );

Sobre o custo: em sites até alguns milhares de URLs, reconstruir é irrelevante — o sitemap é pedido por robô, não por visitante, e o cache de página do servidor ainda absorve o volume. Em site com dezenas de milhares de URLs, avalie; nesse porte o caminho melhor é consertar a invalidação, não desligar o cache.

Onde colar o filtro importa mais do que parece, e é o assunto da seção sobre não ter wp-admin, mais abaixo.

Causa 2 — o cache de página do servidor está guardando o .xml

Se o Teste 1 acusou cache de página, o filtro do Rank Math não resolve nada: o XML novo é gerado corretamente e o servidor continua entregando a cópia antiga por cima dele.

A correção tem duas partes, e fazer só uma é a razão mais comum de “apliquei e não mudou”:

1. Excluir os .xml do cache de página. No LiteSpeed Cache, Cache → Exclusões (a documentação do LiteSpeed detalha a sintaxe de cada campo); em Cloudflare, uma Cache Rule com bypass para *.xml. O padrão de exclusão que cobre o Rank Math é sitemap e .xml.
2. Purgar o que já está guardado. Excluir do cache não apaga o que já foi guardado antes da regra. Sem o purge, você continua vendo a cópia velha e conclui que a exclusão não funcionou.

Se o purge pelo painel não estiver disponível — porque o wp-admin está atrás de um proxy, porque é site de cliente, porque você só tem FTP — dá para expor um purge sob demanda por URL. Aqui existe um endpoint com token para isso; o mesmo padrão serve para qualquer plugin de cache que tenha função de purge programático.

Causa 3 — o post type ou a taxonomia está desligada no sitemap

Se o Teste 1 mostrou que nenhuma versão do XML tem a URL — nem com cachebuster — não é cache. É configuração, e o suspeito é a chave por tipo de conteúdo em Rank Math SEO → Sitemap Settings.

Dois detalhes que enganam:

• Categoria nova não entra sozinha. Criar uma categoria não a coloca no category-sitemap.xml se a taxonomia estiver desligada — ou se o cache da Causa 1 estiver ativo. Quando desligamos o transient aqui, uma categoria criada dias antes entrou no category-sitemap.xml junto com os 8 posts.
• O noindex individual manda mais que a configuração global. Um post com noindex no painel do Rank Math é excluído do sitemap de propósito — esse é o comportamento correto, não um bug. Confira o post específico antes de culpar o plugin.

Causa 4 — permalinks precisam de flush

O menos glamouroso e o que resolve um punhado de casos: Configurações → Links permanentes → Salvar alterações, sem alterar nada. Isso regrava as regras de rewrite, e as URLs de sitemap do Rank Math dependem delas.

Faça depois dos testes, não antes: se você fizer o flush primeiro, perde a chance de saber qual era a causa real — e o problema volta na próxima publicação sem você entender por quê.

Causa 5 — o redirecionador do Rank Math engole a URL do sitemap

Esse é sutil e custou dias aqui. O módulo Redirections do Rank Math tem a opção de mandar todo 404 para a home. Quando a URL do sitemap não existe ainda — porque é um sitemap customizado, porque as rewrite rules não foram regravadas, porque o post type mudou — a requisição vira 404, o redirecionador captura, e o Google recebe um 301 para a home em vez de um 404.

A diferença é grave: um 404 diz “não existe, tente depois”; um 301 para a home diz “esse conteúdo agora é a home”. No Search Console isso aparece como Página com redirecionamento, não como erro de sitemap — e você procura o problema no lugar errado.

Foi o que aconteceu com o nosso /sitemap-news.xml: o redirecionador 301-ava a URL para a home antes de o gerador ser chamado. Como detectar:

curl -sI -A "Mozilla/5.0" https://seusite.com.br/sitemap-news.xml | head -3
# 301 + Location: https://seusite.com.br  ->  o redirecionador esta no caminho
# 404                                     ->  a URL realmente nao existe
# 200 + Content-Type: application/xml     ->  ok

Correção: desligar o “redirect 404 to homepage” — ele é ruim para SEO de qualquer forma — ou registrar o gerador do sitemap num hook que roda antes do redirecionador. Detalhamos esse caso no artigo sobre news sitemap que o Rank Math não gera.

Causa 6 — o limite de itens por sitemap

O Rank Math divide o sitemap em páginas (post-sitemap1.xml, post-sitemap2.xml…) a partir de um limite de itens. Se o limite estiver alto e a paginação mal formada, os posts mais recentes podem cair numa página que o índice não referencia.

Teste rápido: mude o número de itens por sitemap em Sitemap Settings → Links Per Sitemap. Se os posts novos aparecerem depois disso, o problema era a paginação — e o próprio ato de salvar já força a regeneração, o que também é pista de cache. É um workaround, não um diagnóstico: se resolveu, volte aos testes 1 e 2 para achar a causa de verdade.

O fix quando você não tem wp-admin

Aqui está o cenário que os tutoriais ignoram e que é comum em qualquer operação séria: você precisa aplicar o filtro e não tem o painel. O wp-admin está atrás de um proxy de acesso (no nosso caso, Cloudflare Access), é site de cliente com credencial que ninguém acha, ou o painel simplesmente não abre.

Dá para aplicar por arquivo. A ordem de preferência:

1. mu-plugin — wp-content/mu-plugins/sitemap-cache-off.php. É o lugar certo: must-use plugin carrega sempre, sobrevive a troca de tema e não depende de ativação.
2. functions.php do child theme — segunda opção. Funciona, mas morre se o tema mudar.
3. Plugin de snippet — só se você já tiver um e conseguir acessá-lo.

A armadilha prática: a API de arquivos do cPanel não cria diretório. Se não existe mu-plugins, e você está operando por API e não por FTP, a opção 1 fica fora de alcance. Foi o que nos aconteceu — daí o filtro ter ido para o functions.php do child theme, em bloco marcado no fim do arquivo:

/* ==== WPRAIZ: sitemap cache off (2026-07-26) ====
 * Motivo: posts publicados via REST nao entravam no sitemap.
 * Remover este bloco reverte 100% da mudanca.
 */
add_filter( 'rank_math/sitemap/enable_caching', '__return_false' );
/* ==== fim do bloco ==== */

Três regras que valem para qualquer edição de arquivo em produção sem painel: backup do arquivo original antes (com data no nome), bloco delimitado por comentário para o rollback ser apagar um trecho e não reconstruir o arquivo, e conferir o site inteiro depois — um erro de sintaxe em functions.php derruba tudo, não só o sitemap.

Como confirmar que funcionou — medição, não fé

“Apliquei o filtro” não é resultado. Resultado é o post novo dentro do XML. A sequência de verificação:

1. Purgue o cache de página — senão você valida a cópia velha e conclui errado.
2. Conte as URLs do XML, não olhe de olho:

   curl -sL -A "Mozilla/5.0" https://seusite.com.br/post-sitemap.xml | grep -c "<loc>"

3. Procure a URL específica do post que estava faltando:

   curl -sL -A "Mozilla/5.0" https://seusite.com.br/post-sitemap.xml | grep "slug-do-post"

4. Confira o lastmod do índice — tem que ter avançado para a data de hoje.
5. Só então vá ao Search Console e reenvie o sitemap. O painel leva de horas a dias; o curl responde na hora. Validar pelo painel primeiro é trocar um teste de 5 segundos por um de 2 dias.

No nosso caso o número fechou a conta: os 8 posts invisíveis entraram, a categoria nova entrou no category-sitemap.xml, e não houve erro de PHP nem queda no site. Hoje o índice serve post-sitemap1.xml e post-sitemap2.xml com o total do acervo, e o lastmod acompanha a última publicação.

Um último aviso que vale mais que o fix: sitemap consertado não é distribuição consertada. Estar no XML é condição para ser rastreado, não garantia de ser encontrado. Se o seu problema é tráfego e não indexação, o sitemap é o primeiro item da lista, não o único — vale olhar também Core Web Vitals com LiteSpeed e o llms.txt se você quer ser lido também por assistente de IA.

E se você chegou aqui decidindo entre plugins de SEO: a diferença de comportamento de cache de sitemap é um dos pontos práticos que separam os dois líderes — tratamos disso em por que o Rank Math domina a era da IA e na seleção de plugins indispensáveis. Para automatizar a checagem em vez de rodar curl na mão toda semana, veja IA para SEO técnico no WordPress.

Se a sua decisão ainda é entre os dois plugins, o comparativo Yoast SEO vs Rank Math entra no detalhe de cada módulo — e o cache de sitemap é exatamente um dos pontos em que o Rank Math ganha em recurso e perde em previsibilidade. E se você chegou aqui porque mexer em functions.php por API te deixou desconfortável, com razão: leia as 7 dicas de segurança no WordPress antes de repetir o procedimento, e mantenha o núcleo em dia — as 12 correções de segurança do WordPress 7.0.3 mostram o tamanho da superfície que um site desatualizado deixa aberta.