Indexação WordPress no Google: o guia completo para garantir que cada página é encontrada
O WordPress alimenta mais de 40% da web, mas milhares de sites WordPress têm páginas que o Google nunca descobre. Este guia leva-te a percorrer cada definição, configuração de plugin e ajuste ao nível do servidor que precisas para garantir uma indexação completa e rápida do teu conteúdo WordPress.
Neste guia
O WordPress alimenta mais de 40% da web, mas a sua flexibilidade cria dezenas de pontos onde a indexação pode falhar. Uma caixa mal clicada em Settings > Reading pode esconder o teu site inteiro. Uma má configuração de um plugin SEO pode silenciosamente adicionar diretivas noindex. Um tema mal codificado pode injetar tags canonical duplicadas que confundem o Googlebot.
Este guia é um passo-a-passo específico do WordPress para cada ponto de configuração que afeta a indexação — definições do core, sitemaps Yoast/RankMath, estruturas de permalink, regras do .htaccess e endpoints da REST API. Quer geres um blog ou uma loja WooCommerce, os passos aqui aplicam-se.
Como o Google faz crawl a sites WordPress
O Google descobre páginas WordPress através de três canais principais:
- O teu sitemap XML — o mecanismo principal de descoberta
- Links internos dentro do teu site que o Googlebot segue
- Backlinks externos a apontar para as tuas páginas a partir de outros sites
O WordPress gera um sitemap integrado em /wp-sitemap.xml desde a versão 5.5, mas a maioria dos proprietários de sites usa um sitemap gerado por plugin porque oferece mais controlo sobre quais tipos de post, taxonomias e arquivos são incluídos.
Quando o Googlebot chega ao teu site WordPress, verifica primeiro o robots.txt na raiz do domínio. O WordPress gera um robots.txt virtual através de uma função PHP em vez de servir um ficheiro estático, o que significa que plugins e funções do tema podem modificá-lo programaticamente. O robots.txt predefinido do WordPress permite todos os crawlers e aponta para o sitemap, mas plugins de segurança acrescentam frequentemente regras restritivas que bloqueiam o acesso a /wp-admin/, /wp-includes/ e por vezes até a /wp-content/uploads/ — o diretório onde vivem todos os teus ficheiros de media.
Depois de ler o robots.txt, o Googlebot começa a fazer crawl das páginas. O WordPress serve HTML que é geralmente bem estruturado, mas o pipeline de renderização importa. Se o teu tema depende fortemente de JavaScript para o layout (comum com page builders como o Elementor, Divi ou WPBakery), o Google tem de fazer uma segunda passagem de renderização. Esta indexação em duas passagens — primeiro o HTML em bruto, depois a versão renderizada por JavaScript — pode atrasar a indexação completa em dias ou mesmo semanas. Páginas construídas com o editor de blocos Gutenberg nativo renderizam do lado do servidor e evitam totalmente este atraso.
O WordPress também expõe conteúdo através da sua REST API em /wp-json/wp/v2/. Embora o Googlebot normalmente não faça crawl a endpoints da REST API para fins de indexação, sites mal configurados por vezes têm URLs da REST API a aparecer em sitemaps ou links internos, criando confusão na fila de crawl do Google.
Definições do core WordPress que afetam a indexação
A definição mais importante de indexação no WordPress vive em Settings > Reading. A caixa com o rótulo "Discourage search engines from indexing this site" adiciona uma tag <meta name="robots" content="noindex, nofollow"> a cada página e modifica o robots.txt para incluir Disallow: /. Esta definição destina-se a ambientes de desenvolvimento e staging, mas fica ativada em produção mais vezes do que esperarias. Toda a auditoria de indexação WordPress deve começar aqui.
A estrutura de permalink, configurada em Settings > Permalinks, determina o formato de URL para cada post e página. A estrutura predefinida usa query strings simples como /?p=123, que são rastreáveis mas não dão sinais de keyword ao Google. A estrutura recomendada para a maioria dos sites é "Post name" (/%postname%/), que cria URLs limpos e legíveis. Se mudares a estrutura de permalink num site existente, o WordPress não cria redirecionamentos automáticos para os URLs antigos. Cada URL previamente indexado vai devolver um 404 a não ser que adiciones regras de redirecionamento ao .htaccess ou uses um plugin como o Redirection.
As definições de endereço do site em Settings > General também importam. Se o teu WordPress address e o site address não coincidirem, ou se um usar www e o outro não, o Google vê duas versões diferentes de cada URL. O WordPress trata da redireção entre www e não-www através de RewriteRules do .htaccess, mas más configurações aqui causam loops de redireção que impedem o crawl por completo.
O WordPress também envia pingbacks XML-RPC quando publicas novo conteúdo. Embora o sistema XML-RPC em /xmlrpc.php esteja largamente depreciado a favor da REST API, o ecrã Settings > Writing tem uma lista "ping services" que controla que serviços recebem notificações. Adicionar o endpoint de ping do Google para sitemaps já não é eficaz porque o Google depreciou o ping de sitemap em 2023, mas muitos guias desatualizados ainda o recomendam.
Configuração de plugin SEO: Yoast SEO e RankMath
O Yoast SEO e o RankMath são os dois plugins de SEO mais populares no WordPress, e ambos têm controlo extensivo sobre a tua indexação. Geram sitemaps XML, gerem diretivas meta robots, definem URLs canonical e controlam como o teu conteúdo aparece nos resultados de pesquisa.
O Yoast SEO gera o seu sitemap em /sitemap_index.xml, que é um sitemap index a conter links para sitemaps individuais de posts, páginas, categorias, tags, arquivos de autor e custom post types. Controlas que tipos de conteúdo aparecem através de Yoast > Settings > Content Types e Yoast > Settings > Categories & Tags. Cada tipo de conteúdo tem um toggle "Show in search results" — desligá-lo adiciona uma diretiva noindex a todo esse tipo de conteúdo e remove-o do sitemap. Esta é a causa número um de noindexing acidental no WordPress.
O RankMath usa uma abordagem semelhante mas com uma interface mais granular. As suas definições de sitemap estão em RankMath > Sitemap Settings, onde cada post type e taxonomia tem o seu próprio separador. O RankMath também tem um separador "Advanced" por página no editor de posts onde podes definir páginas individuais como noindex, nofollow ou noarchive. Um erro comum é definir uma página como noindex durante o desenvolvimento e esquecer de mudar antes de publicar.
Ambos os plugins definem URLs canonical automaticamente. Conflitos de URL canonical surgem quando:
- Ambos os plugins estão ativos simultaneamente — nunca corras dois plugins SEO ao mesmo tempo
- Um plugin de cache serve uma versão antiga da página com uma tag canonical desatualizada
O sitemap gerado por estes plugins substitui o sitemap do core do WordPress. Se tanto o sitemap do core (/wp-sitemap.xml) como o sitemap do plugin (/sitemap_index.xml) estiverem ativos, o Google pode descobrir ambos e desperdiçar crawl budget a processar entradas duplicadas. O Yoast e o RankMath desativam ambos o sitemap do core automaticamente, mas desativar o plugin SEO sem remover a sua configuração pode reativar o sitemap do core enquanto deixa URLs de sitemap órfãs no Google Search Console.
O ficheiro .htaccess e controlos de indexação ao nível do servidor
O ficheiro .htaccess na raiz do teu WordPress é um dos ficheiros mais poderosos e mais incompreendidos que afeta a indexação. O WordPress escreve as suas próprias regras de rewrite neste ficheiro para o tratamento de permalinks, mas plugins, fornecedores de alojamento e edições manuais podem adicionar regras que bloqueiam crawlers ou criam cadeias de redirecionamento.
O bloco .htaccess predefinido do WordPress verifica se o ficheiro ou diretório pedido existe, e se não existir, encaminha o pedido para index.php para o WordPress tratar. Plugins de segurança como o Wordfence, Sucuri e iThemes Security adicionam as suas próprias regras acima do bloco WordPress. Essas regras às vezes incluem bloqueio por IP, rate limiting ou filtragem por user-agent que podem inadvertidamente bloquear o Googlebot. Se o teu plugin de segurança tiver uma funcionalidade "block suspicious user agents", verifica que a user agent string do Googlebot está explicitamente whitelisted.
Os fornecedores de alojamento também modificam o .htaccess. Hosts WordPress geridos como o WP Engine, Kinsta e Flywheel adicionam cabeçalhos de cache, regras de compressão GZIP e às vezes regras de redirecionamento para o seu CDN. Estes geralmente estão bem, mas se o teu host força HTTPS via .htaccess e as tuas definições WordPress ainda referenciam URLs HTTP, ficas com uma cadeia de redirecionamento:
- 1HTTP para HTTPS (via
.htaccess) - 2Normalização www/não-www (via WordPress)
Cada redirecionamento na cadeia custa crawl budget e adiciona latência.
Para auditar o teu .htaccess, faz download via SFTP ou pelo gestor de ficheiros do alojamento e revê cada bloco de regras. Procura por:
- Regras
Deny from allque possam bloquear diretórios inteiros - Padrões
RewriteRuleque redirecionam user agents de crawlers - Diretivas
Header set X-Robots-Tagque adicionam noindex ao nível do servidor
O header HTTP X-Robots-Tag é particularmente sorrateiro porque não aparece no código-fonte da página — só o consegues ver nos cabeçalhos de resposta HTTP usando curl ou as dev tools do browser.
Conflitos de plugins e problemas de tema que bloqueiam a indexação
A arquitetura de plugins do WordPress significa que qualquer plugin instalado pode modificar cabeçalhos HTTP, injetar meta tags, alterar o robots.txt ou mudar o teu sitemap. Os conflitos mais comuns que partem a indexação envolvem:
Plugins de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) a servir HTML obsoleto que contém meta robots tags ou URLs canonical desatualizados. Quando mudas uma página de noindex para index, a versão em cache pode continuar a servir a tag noindex até que a cache seja limpa. Limpa sempre a cache de página inteira após qualquer alteração relacionada com SEO.
Plugins de membership e paywall (MemberPress, Restrict Content Pro, WooCommerce Memberships) que envolvem conteúdo em verificações de autenticação. Se o plugin esconde o conteúdo atrás de um login sem fornecer um fallback para utilizadores anónimos, o Googlebot vê ou um formulário de login ou conteúdo vazio. Alguns plugins de membership têm uma opção "Show excerpt to search engines" — ativa-a para que o Google possa indexar um snippet significativo.
Plugins de page builder armazenam conteúdo em formatos personalizados de base de dados que a função the_content() predefinida do WordPress não devolve. O Elementor armazena os seus dados de layout como post meta e renderiza via JavaScript. Se os ficheiros CSS e JS do Elementor estiverem bloqueados no robots.txt, o Google não consegue renderizar a página e indexa um layout em branco. O mesmo aplica-se ao Divi, Beaver Builder e WPBakery. Verifica a ferramenta URL Inspection do Google Search Console e clica em "View Crawled Page" para ver exatamente o que o Googlebot renderiza.
Temas também podem interferir. Alguns temas incluem as suas próprias funcionalidades SEO — campos de meta description, tags Open Graph ou mesmo geradores de sitemap — que entram em conflito com o teu plugin SEO. Meta tags geradas pelo tema podem criar tags de title e description duplicadas no teu HTML head. Inspeciona o código-fonte da página e procura por <meta name="description"> ou <meta name="robots"> duplicadas. Se o teu tema adiciona as suas próprias, desativa essa funcionalidade nas definições do tema ou muda de tema.
WordPress REST API e otimização de crawl budget
A REST API do WordPress expõe o teu conteúdo em /wp-json/wp/v2/posts, /wp-json/wp/v2/pages e endpoints semelhantes. Embora não sejam destinados ao consumo por motores de busca, às vezes aparecem no índice do Google se ligados a partir do teu sitemap, do JavaScript do teu tema ou de fontes externas. Respostas da REST API devolvem JSON, não HTML, por isso URLs da API indexados aparecem como dados em bruto nos resultados de pesquisa.
Para evitar que URLs da REST API sejam indexados, adiciona um header X-Robots-Tag: noindex às respostas da REST API. Podes fazer isto com um pequeno snippet de código no functions.php do tema ou num plugin personalizado. Alguns plugins SEO tratam disto automaticamente, mas verifica visitando um URL da REST API e inspecionando os cabeçalhos de resposta.
O crawl budget é uma preocupação real para sites WordPress grandes. Se tens milhares de posts, mais arquivos de tag, arquivos de categoria, arquivos de data, arquivos de autor e versões paginadas de tudo isto, o Google tem de fazer crawl de dezenas de milhares de URLs. Muitas destas páginas de arquivo têm thin content. Define o seguinte como noindex nas definições do teu plugin SEO:
- Arquivos de tag — contêm muitas vezes apenas 1-2 posts
- Arquivos de data — meses em que publicaste uma vez
- Arquivos de autor — desnecessários em blogs de um único autor
Isto concentra o crawl budget no teu conteúdo real.
O WordPress gera URLs de feed em /feed/, /comments/feed/ e feeds por categoria e por tag. São mecanismos de descoberta válidos e devem permanecer rastreáveis, mas não devem ser indexados. A maioria dos plugins SEO adiciona noindex às respostas de feed por padrão. Verifica visitando /feed/ e procurando uma diretiva noindex no header XML.
Finalmente, considera o tempo de resposta do teu site. WordPress em alojamento partilhado com muitos plugins ativos tem frequentemente um Time to First Byte (TTFB) de 2-4 segundos. O Googlebot interpreta respostas lentas como sinal de que o servidor está sobrecarregado e reduz a sua taxa de crawl. Usa cache ao nível do servidor (cache de objetos Redis ou Memcached, cache de página através do teu fornecedor de alojamento) para baixar o TTFB para menos de 500ms. Só isto pode aumentar dramaticamente quantas páginas o Google faz crawl por dia.
Guia passo a passo
Confirma que a caixa "Discourage search engines" está desligada
Inicia sessão no admin do WordPress e navega para Settings > Reading. Desliza para baixo até à secção "Search engine visibility".
A caixa com o rótulo "Discourage search engines from indexing this site" tem de estar desmarcada para sites em produção. Se estiver marcada, desmarca e clica em Save Changes.
Esta única caixa controla uma diretiva noindex ao nível do site inteiro que impede completamente o Google de indexar qualquer página. Depois de desmarcar, vê o código-fonte da página e confirma que <meta name="robots" content="noindex, nofollow"> já não aparece na secção <head>.
Configura as definições de sitemap e indexação do teu plugin SEO
Yoast SEO: Vai a Settings > Content Types e ativa "Show in search results" para Posts e Páginas. Em Categories & Tags, indexa categorias mas considera definir as tags como noindex.
RankMath: Vai a Sitemap Settings e ativa cada post type. Em Titles & Meta, verifica que nenhum tipo de conteúdo tem o Robots Meta definido como noindex.
Visita /sitemap_index.xml num browser e confirma que carrega XML válido a ligar ao teu conteúdo.
Define uma estrutura de permalink ótima e implementa redirecionamentos
Navega para Settings > Permalinks e seleciona "Post name" como estrutura de permalink. Isto cria URLs como oteudominio.com/titulo-do-teu-post/ que são limpos, ricos em keywords e fáceis para o Google analisar.
Se estás a mudar de uma estrutura diferente num site existente:
- 1Instala o plugin Redirection antes de fazer a mudança
- 2Muda a estrutura de permalink e guarda
- 3O plugin Redirection vai registar automaticamente erros 404 dos URLs antigos
- 4Configura regras de redirecionamento dos padrões antigos para os novos
Por exemplo, se a estrutura antiga era /%year%/%monthnum%/%postname%/, cria um redirecionamento regex de ^/\d{4}/\d{2}/(.+)$ para /$1 para preservar o link equity.
Audita o robots.txt e o .htaccess à procura de bloqueios a crawlers
Visita oteudominio.com/robots.txt e verifica que não há regra Disallow: / e que o URL do teu sitemap está listado com uma diretiva Sitemap:.
Faz download do .htaccess via SFTP e procura por regras de bloqueio de user-agent, restrições de IP que afetem a gama 66.249.x.x do Google e cabeçalhos X-Robots-Tag de plugins de segurança. Se encontrares regras suspeitas, desativa os plugins de segurança um a um para identificar a origem.
Submete o teu sitemap ao Google Search Console
Inicia sessão no Google Search Console e seleciona a tua propriedade WordPress. Navega para Sitemaps na barra lateral esquerda e introduz o URL do teu sitemap:
/sitemap_index.xmlse usares Yoast ou RankMath/wp-sitemap.xmlse usares o sitemap do core do WordPress
Clica em Submit. O Google começa a processar o sitemap, o que costuma demorar 24-48 horas para a primeira leitura.
Depois da submissão, monitoriza o relatório Sitemaps à procura de erros comuns:
- URLs a devolver 404 (posts apagados ainda no sitemap)
- URLs bloqueados por robots.txt
- URLs com cadeias de redirecionamento
O relatório Pages mostra-te quantos URLs submetidos foram indexados, excluídos ou tiveram erros.
Testa a renderização da página com URL Inspection
No Google Search Console, usa URL Inspection nas tuas páginas mais importantes. Clica em "Test Live URL" e verifica que a resposta HTTP é 200, que o estado de indexação mostra que o URL pode ser indexado e que o screenshot renderizado em "View Crawled Page" corresponde ao teu browser.
Se a página renderizada mostrar conteúdo em falta ou secções vazias, tens um problema de renderização JavaScript por recursos bloqueados ou conflitos com o page builder.
Usa a IndexBolt para acelerar a indexação das páginas restantes
Depois de completar todas as correções técnicas acima, algumas páginas podem ainda demorar semanas a ser indexadas através do ciclo de crawl natural do Google, especialmente em sites WordPress mais recentes ou de menor autoridade.
Usa a IndexBolt para submeter estes URLs diretamente para indexação:
- 1Exporta os URLs do teu sitemap (encontra-os no
sitemap_index.xmlclicando em cada sub-sitemap) - 2Cola-os no formulário de submissão da IndexBolt
- 3Deixa a nossa API empurrá-los pelo pipeline de indexação do Google
Para conteúdo sensível ao tempo como novas páginas de produto, anúncios de eventos ou breaking news, usa a indexação instantânea da IndexBolt para furar a fila e ter as páginas indexadas em horas em vez de dias.
Problemas comuns e como resolvê-los
A caixa "Discourage search engines" continua marcada
Causa: Esta caixa em Settings > Reading foi ligada durante o desenvolvimento ou migração do site e nunca foi desligada. Alguns fornecedores de alojamento ativam-na por padrão em ambientes de staging, e persiste quando empurras staging para produção. Instaladores automáticos de WordPress de painéis de controlo de alojamento também a deixam por vezes marcada.
Solução: 1. Vai a **Settings > Reading**, desmarca **"Discourage search engines from indexing this site"** e clica em **Save Changes** 2. Visita o código-fonte da homepage e confirma que a meta tag **noindex** desapareceu 3. Verifica o `robots.txt` (`oteudominio.com/robots.txt`) para confirmar que já não contém `Disallow: /` 4. **Limpa a cache de qualquer plugin de cache** depois de fazer esta alteração para que o HTML atualizado seja servido imediatamente
O plugin SEO está a definir um post type ou taxonomia inteiro como noindex
Causa: No Yoast SEO, o toggle "Show in search results" em Settings > Content Types foi desligado para um post type. No RankMath, o Robots Meta para um tipo de conteúdo foi definido como noindex em Titles & Meta. Isto adiciona uma diretiva noindex a cada página desse tipo e remove-as do sitemap, mesmo que posts individuais tenham conteúdo valioso.
Solução: Abre as definições do teu plugin SEO e revê cada post type e taxonomia. - **Yoast:** Vai a **Settings > Content Types** e ativa **"Show in search results"** para cada tipo que queres indexado - **RankMath:** Vai a **Titles & Meta > Post Types** e define o Robots Meta como **"index"** Depois de mudar, regenera o teu sitemap visitando-o num browser e confirmando que os URLs afetados agora aparecem. **Volta a submeter o sitemap** no Google Search Console.
A mudança de estrutura de permalink causou erros 404 em massa
Causa: Mudar a estrutura de permalink em Settings > Permalinks atualiza todos os links internos mas não cria redirecionamentos para os padrões de URL antigos. Quaisquer links externos, bookmarks ou URLs previamente indexados que apontem para a estrutura antiga devolvem agora erros 404. O Google acabará por desindexar essas páginas.
Solução: 1. Instala o plugin **Redirection** (ou usa o teu `.htaccess` diretamente) para criar **redirecionamentos 301** baseados em padrões da estrutura antiga para a nova 2. Se a estrutura antiga era `/%category%/%postname%/`, cria um mapeamento de redirecionamento dos URLs antigos para a nova estrutura `/%postname%/` 3. Monitoriza **erros 404** no relatório Pages do Google Search Console 4. Adiciona redirecionamentos individuais para qualquer URL que a regra baseada em padrão não tenha apanhado Com o tempo, o Google atualizará o seu índice para refletir a nova estrutura de URL.
Vários plugins a gerar sitemaps conflituosos
Causa: Correr dois plugins SEO em simultâneo (por exemplo, Yoast e RankMath), ou ter um plugin SEO juntamente com um plugin dedicado de sitemap como o Google XML Sitemaps, cria vários ficheiros de sitemap. Se o robots.txt ou o Google Search Console referenciar ambos os sitemaps, o Google processa entradas duplicadas e pode detetá-las como suspeitas. Alguns plugins all-in-one de segurança como o All In One WP Security também geram os seus próprios sitemaps.
Solução: **Usa apenas um plugin para a geração do sitemap.** Se usas Yoast ou RankMath, desativa ou remove quaisquer plugins de sitemap autónomos. 1. Verifica o `robots.txt` à procura de várias linhas `Sitemap:` e remove duplicados 2. No Google Search Console, vai a **Sitemaps** e remove quaisquer submissões desatualizadas ou duplicadas 3. Verifica que o sitemap do core do WordPress em `/wp-sitemap.xml` está desativado pelo teu plugin SEO (Yoast e RankMath fazem isto automaticamente quando estão ativos)
Plugin de cache a servir páginas noindex obsoletas
Causa: Mudaste uma página de noindex para index (ou corrigiste qualquer problema de meta tag), mas o teu plugin de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) está ainda a servir o HTML antigo em cache que contém a diretiva noindex. As caches de página podem persistir durante horas ou dias dependendo da configuração.
Solução: **Limpa a tua cache de página completa** depois de qualquer alteração relacionada com SEO: - **WP Rocket:** Settings > WP Rocket > **"Clear Cache"** - **W3 Total Cache:** Performance > Dashboard > **"Empty All Caches"** - **LiteSpeed Cache:** LiteSpeed Cache > Toolbox > **"Purge All"** Se usas um CDN como o **Cloudflare**, limpa também a cache do CDN a partir do dashboard do Cloudflare. Depois de limpar, confirma visitando a página numa **janela de browser anónima** e vendo o código-fonte para confirmar que as meta tags corretas estão presentes.
Tema pesado e page builder a abrandar a taxa de crawl
Causa: Temas WordPress complexos com grandes bundles de CSS/JS e page builders como Elementor ou Divi aumentam significativamente o tempo de carregamento da página. Quando o Time to First Byte excede 2 segundos, o Googlebot reduz a sua taxa de crawl para evitar sobrecarregar o servidor. Em alojamento partilhado, isto pode baixar o teu volume de crawl diário de centenas de páginas para apenas algumas dezenas.
Solução: Ativa **cache do lado do servidor** para melhorar os tempos de resposta: 1. Instala um plugin de cache e configura-o para **full-page caching** 2. Usa um **object cache** (**Redis** ou **Memcached**) se o teu host suportar 3. **Minifica e combina** ficheiros CSS/JS através do teu plugin de cache 4. Considera mudar para um host WordPress gerido (**WP Engine**, **Kinsta**, **Cloudways**) que inclua cache ao nível do servidor e CDN Verifica a tua taxa de crawl no Google Search Console em **Settings > Crawl Stats**, que mostra pedidos de crawl diários, tamanho de download e tempos de resposta.
Dicas de profissional
Sites WordPress podem ter centenas ou milhares de páginas à espera que o Google as descubra. A IndexBolt deixa-te submeter os teus URLs WordPress diretamente para indexação, sem esperar pelo próximo crawl do Googlebot. Quer tenhas acabado de corrigir um problema de noindex ou publicado um lote de novos posts, mete-os no índice do Google em horas em vez de semanas.
100 créditos gratuitos. Sem cartão de crédito. Resultados em menos de 24 horas.
Perguntas frequentes
Quanto tempo demora o Google a indexar uma nova página WordPress?+
Em **sites WordPress estabelecidos** com boas taxas de crawl, novas páginas aparecem tipicamente no Google em **2-7 dias** após a publicação. Em **sites mais recentes** ou sites com baixa autoridade de domínio, pode levar **2-6 semanas**. Se a tua página não estiver indexada após 4 semanas, provavelmente há um problema técnico a bloquear o crawl ou a indexação. Usar a **IndexBolt** pode reduzir este prazo para **horas** em páginas urgentes.
Devo usar o sitemap do core do WordPress ou o do meu plugin SEO?+
Usa o **sitemap do teu plugin SEO** se tens o Yoast SEO ou o RankMath instalados. Estes plugins geram sitemaps mais completos com melhor controlo sobre que tipos de conteúdo são incluídos, e **desativam automaticamente o sitemap do core** para evitar duplicados. O sitemap do core do WordPress em `/wp-sitemap.xml` é adequado para sites simples sem um plugin SEO, mas falta-lhe os controlos granulares que o Yoast e o RankMath fornecem.
Posso ter páginas a mais no meu sitemap WordPress?+
Um único ficheiro de sitemap pode conter até **50.000 URLs** segundo a especificação do protocolo de sitemap. Tanto o Yoast como o RankMath dividem sitemaps grandes em sub-sitemaps de **1.000 URLs** cada (configurável). A preocupação real não é o tamanho do sitemap mas a **qualidade dos URLs** nele. Se o teu sitemap contém milhares de páginas de arquivo finas, páginas de tag com um post ou URLs paginados, o **crawl budget** do Google é desperdiçado em páginas de baixo valor. Mantém o teu sitemap enxuto **definindo como noindex tipos de conteúdo finos**.
Mudar o meu tema WordPress afeta os meus rankings no Google?+
Mudar de tema pode **afetar absolutamente a indexação e os rankings**. Um tema novo pode: - Alterar a tua **estrutura de página** e **hierarquia de headings** - Modificar **padrões de links internos** - Adicionar ou remover **dados estruturados** - Introduzir comportamento diferente de **renderização JavaScript** Se o novo tema for mais lento ou usar JavaScript pesado, o Google pode fazer crawl e indexar as tuas páginas com menos eficácia. **Testa sempre uma mudança de tema num site de staging primeiro** e monitoriza o relatório Pages do Google Search Console de perto depois de mudar.
Porque é que as minhas páginas de tag do WordPress aparecem como 'Discovered but not indexed'?+
O Google frequentemente classifica páginas de arquivo de tag como **baixo valor** porque contêm os mesmos excerpts de post que aparecem noutras páginas de arquivo (páginas de categoria, páginas de autor, a homepage do blog). Quando o Google determina que uma página não acrescenta valor único, descobre o URL mas **escolhe não o indexar**. A boa prática é **definir os arquivos de tag como noindex** nas definições do teu plugin SEO, a não ser que as tuas tags tenham conteúdo único substancial. Isto ajuda na verdade a indexar as tuas páginas importantes mais rapidamente **ao concentrar o crawl budget**.
O meu site WordPress usa um page builder. Isso afeta a indexação?+
Page builders como o **Elementor**, **Divi** e **WPBakery** armazenam conteúdo no seu próprio formato e renderizam via JavaScript no frontend. O Google consegue renderizar JavaScript mas fá-lo num **segunda passagem atrasada**, o que significa que páginas construídas com page builders podem demorar mais a ser totalmente indexadas. Mais criticamente, se o teu `robots.txt` bloqueia os ficheiros CSS ou JS do page builder (alguns plugins de segurança fazem isto), o Google **não consegue renderizar a página de todo** e pode indexar um layout em branco. Testa com a ferramenta **URL Inspection** do Google Search Console para verificar que o Google vê a página totalmente renderizada.