Idiomas

SEO para WordPress

Um guia de SEO técnico para WordPress — as configurações padrão que prejudicam seu site, como funcionam de fato o sitemap nativo e o tratamento de canonicals, por que você deve usar exatamente um plugin de SEO e quais fontes de conteúdo duplicado o WordPress cria por conta própria.

Publicado pela primeira vez: 27 de jun. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2

O WordPress é capaz de fazer SEO, mas não vem pronto para SEO. Ele cria canonical próprio para posts desde o WordPress 2.9 e oferece um sitemap XML nativo desde o WordPress 5.5 — mas seus padrões também deixam permalinks ?p=123, páginas de anexos, arquivos por data/tag/autor, feeds e resultados de busca internos indexáveis, e uma única caixa em Configurações → Leitura pode bloquear silenciosamente o site inteiro. As correções que realmente importam: configurar /%postname%/ antes de publicar, usar exatamente um plugin de SEO (Yoast, Rank Math ou AIOSEO — nunca dois, porque o conflito em wp_head produz metadados duplicados), aplicar noindex em arquivos finos em vez de bloqueá-los e manter no sitemap apenas URLs canônicas e indexáveis. O WordPress 6.4+ desativa páginas de anexos por padrão em novas instalações — redirecionando diretamente para o arquivo, não para o post pai — mas sites existentes continuam com elas ativadas e precisam migrar manualmente. O Google nunca disse que o WordPress ranqueia melhor ou pior que qualquer outro CMS — quem decide isso são conteúdo e links, não a plataforma.

TL;DR — O WordPress é capaz de fazer SEO, mas não vem pronto para SEO. Ele cria canonical próprio para posts individuais desde o WordPress 2.9 e oferece um sitemap XML nativo desde o WordPress 5.5 — mas os padrões deixam permalinks ?p=123, páginas de anexos, arquivos por data/tag/autor, feeds e páginas de busca ?s= indexáveis, e a caixa em Configurações → Leitura pode bloquear silenciosamente o site inteiro. As correções que realmente movem o ponteiro: /%postname%/ antes de publicar, exatamente um plugin de SEO (o conflito em wp_head causado por dois plugins é real), noindex em arquivos finos em vez de bloqueá-los e um sitemap formado apenas por URLs canônicas e indexáveis. O WordPress 6.4+ desativa páginas de anexos por padrão em novas instalações — redirecionando para o próprio arquivo, não para o post pai; sites existentes continuam com elas ativadas e precisam migrar manualmente. O Google nunca disse que o WordPress é melhor ou pior para SEO do que qualquer outro CMS. Evidence for this claim WordPress added core XML sitemaps in 5.5 and attachment-page redirects for new sites in 6.4. Scope: Core version history; existing sites can retain prior attachment behavior. Confidence: high · Verified: WordPress 5.5 XML sitemaps WordPress 6.4 attachment pages

O WordPress é capaz de fazer SEO, mas não vem pronto para SEO

A forma honesta de ver a questão fica entre as duas afirmações de marketing que você costuma ouvir. O WordPress não é “amigável para SEO de fábrica” em um sentido completo — mas também não é ruim para SEO. Ele oferece uma base forte e controlável e, depois, deixa uma pilha de resíduos indexáveis ativada por padrão. O trabalho é saber quais padrões alterar e quais URLs geradas automaticamente suprimir.

E, para deixar claro desde o início: o Google nunca disse que o WordPress ranqueia melhor ou pior que qualquer outro CMS. Como diz a documentação do Google, “if you’re using a CMS such as WordPress, Wix, or Blogger, it’s likely that your CMS has already made a sitemap available to search engines” — (tradução: “se você usa um CMS como WordPress, Wix ou Blogger, é provável que seu CMS já tenha disponibilizado um sitemap para os mecanismos de busca”). A plataforma é tratada como qualquer outra. Os rankings vêm de conteúdo e links, não do logotipo na barra administrativa. Evidence for this claim Google says common CMS platforms often generate sitemaps and does not prescribe a CMS-specific ranking advantage. Scope: Google sitemap guidance; absence of a CMS ranking advantage is an editorial inference from platform-neutral requirements. Confidence: medium · Verified: Google: Build and submit a sitemap

Os padrões que prejudicam — e por quê

A caixa “Desencorajar mecanismos de busca de indexar este site” (Configurações → Leitura) grava um noindex no site inteiro e um robots.txt virtual restritivo. É a primeira coisa que verifico em qualquer auditoria de WordPress, porque é a única configuração capaz de zerar silenciosamente a indexação de um site inteiro — geralmente fica ativada desde o ambiente de staging.

O permalink padrão ?p=123 não oferece sinal de tema e não é uma URL limpa. Mude para /%postname%/ — e faça isso antes de publicar. Em um site já estabelecido, mudar a estrutura de permalinks altera as URLs; o WordPress cria automaticamente um redirecionamento 301 das URLs numéricas antigas para tipos de post padrão, mas tipos de post personalizados e páginas nem sempre redirecionam corretamente, então teste. Eu evitaria colocar a categoria no permalink (/%category%/%postname%/): no dia em que você reorganizar a taxonomia, provocará uma mudança em massa de URLs e jogará fora o histórico de ranking sem benefício proporcional.

Páginas de anexos são a particularidade específica do WordPress que as pessoas esquecem. Historicamente, cada upload de mídia criava uma URL independente contendo apenas o arquivo e alguns metadados automáticos — páginas finas que podem canibalizar as páginas reais. O WordPress 6.4 mudou o padrão para que novas instalações desativem totalmente as páginas de anexos — uma solicitação a uma delas agora redireciona diretamente para o próprio arquivo, não para o post pai. Sites existentes (atualizados) continuam com as páginas de anexos ativadas; não há uma opção na tela de Configurações para isso, apenas wp option set wp_attachment_pages_enabled 0 via WP-CLI ou a edição direta da opção em wp-admin/options.php. Na prática, a maioria dos donos de sites nunca toca nessa opção e resolve pelo plugin: aplica noindex à página de anexo ou, melhor, redireciona para o post pai pelo plugin de SEO. Não presuma que um site antigo herdou o padrão do WordPress 6.4; não herdou.

Arquivos, feeds e páginas de busca. Por padrão, o WordPress gera arquivos de categoria, tag, data e autor indexáveis, páginas de arquivo paginadas (?page=2), URLs de feed (/feed/), páginas de anexos e páginas internas de resultados de busca (/page=search, isto é, ?s=). Essa é a lista canônica de fontes de conteúdo duplicado do WordPress, e quase nada disso foi uma decisão sua.

Conteúdo duplicado que o WordPress cria por conta própria

Vale dizer claramente, porque isso surpreende muita gente: o WordPress fabrica conteúdo estruturalmente duplicado por padrão. As fontes recorrentes são:

OrigemExemploCorreção típica
Arquivos de categoria/category/news/Manter ou aplicar noindex se for fino
Arquivos de tag/tag/wordpress/Geralmente noindex (fino e sobreposto)
Arquivos de autor/author/admin/Noindex em sites de um só autor
Arquivos de data/2023/04/Noindex (quase sempre fino)
Paginação/page/2/Canonical autorreferente (não a página 1)
URLs de feed/feed/Aplicar noindex aos feeds
Páginas de anexos/photo-of-cat/Redirecionar para o post pai pelo plugin de SEO (no WordPress 6.4+, novas instalações redirecionam para o próprio arquivo)
Resultados de busca/?s=keywordNoindex

A correção quase nunca é entrar em pânico por causa de uma penalidade — o Google consolida duplicatas em uma canonical em vez de penalizar a duplicação estrutural. A correção é aplicar noindex ao conteúdo fino e manter o sitemap limpo. E há uma distinção essencial: noindex ≠ não rastrear. Uma página com noindex precisa continuar rastreável para que o Google consiga ler a diretiva. Se você a bloquear no robots.txt, o Google não conseguirá ver a diretiva — por isso você aplica noindex aos arquivos finos em vez de bloqueá-los.

O sitemap XML: núcleo versus plugin

O WordPress 5.5 (agosto de 2020) adicionou um sitemap XML nativo em /wp-sitemap.xml. Ele existe, mas é básico. Ele inclui todos os tipos de post públicos, todas as taxonomias públicas e arquivos de autor — ou seja, lista justamente as páginas finas que você quer fora do índice. Não oferece suporte a sitemap de imagens e tem controle limitado. Por isso, na prática, a maioria dos sites usa o sitemap do Yoast ou do Rank Math, que permite incluir ou excluir tipos de post e taxonomias específicos e manter o arquivo restrito a URLs canônicas e indexáveis. O Yoast desativa o sitemap do núcleo e o substitui; isso é esperado.

Há duas coisas que o sitemap não fará por você: o Google ignora completamente <priority> e <changefreq> (segundo a própria documentação do Google), e o WordPress não envia o sitemap ao Google por você — você o envia no Search Console e no Bing Webmaster Tools, e pode listá-lo com uma diretiva Sitemap: no robots.txt para descoberta passiva. O limite de 50 000 URLs / 50 MB da especificação continua valendo; acima disso, divida em um índice de sitemaps.

Tratamento de canonical: núcleo, plugin e a armadilha do conflito

O núcleo gera rel=canonical por meio de rel_canonical() desde o WordPress 2.9 (2009) — posts e páginas individuais geram canonical para si mesmos. O WordPress 4.6 não adicionou a tag; ele reorganizou a função para usar wp_get_canonical_url(), que aceita filtros e é o que as pessoas normalmente querem dizer quando afirmam “canonical desde o 4.6”. É uma boa base, mas o núcleo não trata tipos de post personalizados de forma consistente entre temas, não adiciona canonicals a páginas 404 e não resolve sozinho duplicatas de variações de URL (?utm_source=, www versus não-www, barras finais). Plugins de SEO substituem a saída do núcleo por um tratamento mais completo: canonicals para tipos de post personalizados, canonicals autorreferentes de paginação (não apontando páginas 2+ para a página 1 — um erro que desindexa suas páginas mais profundas), canonical entre domínios para distribuição e substituições por página.

Aqui está a armadilha que conecta toda a questão dos plugins: a tag canonical definida pelo seu plugin de SEO é o sinal autoritativo — mas, se o seu tema também inserir uma title tag ou seus próprios metadados de SEO, haverá conflito. Alguns frameworks de tema (Genesis, Thesis) emitem suas próprias tags de SEO. Ao ativar um plugin de SEO, desative o SEO no nível do tema e inspecione o <head> renderizado para confirmar que existe exatamente uma canonical, um title e uma meta description.

Um plugin de SEO. Nunca dois.

Este tema merece um título próprio porque é a ferida de SEO mais comum que o próprio WordPress causa. Nunca execute dois plugins de SEO simultaneamente. Yoast, Rank Math e AIOSEO usam wp_head() para escrever title, meta description, canonical, tags Open Graph/Twitter, meta robots e JSON-LD. Se você executar dois, ambos serão acionados — meta descriptions duplicadas, tags canonical duplicadas (e contraditórias), Open Graph conflitante e sitemaps conflitantes. O Search Console sinalizará os metadados duplicados. Escolha um e desinstale completamente o outro (desativá-lo deixa entradas no banco de dados).

Quanto a qual escolher — todos cobrem as tarefas centrais; a escolha depende do caso de uso e do orçamento:

  • Yoast SEO — a maior base de instalações, pontuação familiar em formato de semáforo, ótimo para iniciantes e equipes de conteúdo que querem um fluxo guiado. (O schema do WooCommerce é um complemento pago.)
  • Rank Math — o nível gratuito mais generoso: palavras-chave de foco ilimitadas, gerenciador de redirecionamentos, monitoramento de 404, integração com GSC + GA4 e um construtor de schema forte (16+ tipos gratuitos). É minha escolha para desenvolvedores e usuários avançados.
  • All in One SEO (AIOSEO) — integração forte com WooCommerce, assistente de links internos e bom SEO local. É adequado para agências e lojas grandes.

Um cuidado com os sinais verdes do Yoast: uma pontuação maior no Yoast não significa rankings melhores. Ela é uma heurística para formatação on-page básica — presença de palavras-chave, comprimento do título e aproximações de legibilidade. Um post com sinal vermelho costuma superar um post totalmente verde. Qualidade do conteúdo, correspondência com a intenção, autoridade e links importam muito mais.

Schema: o que o WordPress gera e o que não gera

O núcleo do WordPress gera essencialmente nada de útil para rich results — HTML limpo que o Google consegue analisar, mas nenhum JSON-LD. Como observa o Google, “if you use a CMS, such as Wix, WordPress, or Shopify, you might not be able to edit your HTML directly… you may be able to install a plugin that allows you to specify structured data” — (tradução: “se você usa um CMS como Wix, WordPress ou Shopify, talvez não consiga editar o HTML diretamente… pode instalar um plugin que permita especificar dados estruturados”). Esse é o caminho:

  • Yoast adiciona automaticamente Organization/Person, WebSite (com SearchAction), WebPage, BreadcrumbList e schema Article em JSON-LD.
  • Rank Math adiciona isso e mais de 16 tipos de schema no nível gratuito (FAQ, HowTo, Product, Review, Event…) e um construtor para tipos personalizados.
  • O WooCommerce, sozinho, gera metadados básicos de produto em Open Graph, mas não gera JSON-LD de Product — você precisa do Yoast WooCommerce SEO (pago) ou do Rank Math Pro para obter schema Product completo com preço, disponibilidade e agregado de avaliações.

WooCommerce, brevemente

O WooCommerce acrescenta uma superfície de SEO maior ao WordPress padrão. Os problemas recorrentes são: as bases de URL /product/ e /product-category/ (removíveis, com redirecionamentos em sites existentes), variações de produto criando quase duplicatas e — o principal — navegação facetada gerando milhares de URLs finas de combinações de filtros. Trate os facets como faria em qualquer lugar: de preferência com filtragem baseada em JS sem mudar a URL; caso contrário, use rel=canonical para a categoria base e/ou noindex, follow nas páginas de filtro (mantendo o rastreamento permitido para que a diretiva seja vista). A paginação de loja e categoria deve usar canonicals autorreferentes, e o Google descontinuou rel=prev/next em 2019 — é inofensivo se estiver presente, mas não dependa dele. A navegação facetada recebe um tratamento mais aprofundado no pilar de Ecommerce SEO.

robots.txt e Core Web Vitals — duas notas rápidas

O WordPress fornece um robots.txt virtual (não é um arquivo no disco) que, por padrão, bloqueia /wp-admin/ e permite admin-ajax.php. Coloque um arquivo físico na raiz e ele substituirá completamente o virtual; plugins de SEO permitem editar a versão virtual pelo painel. O erro clássico é bloquear /wp-content/, o que impede CSS/JS/imagens e quebra a renderização — não faça isso.

Quanto ao desempenho: a reclamação de que “o WordPress é lento” é um problema de configuração, não do núcleo. Problemas de LCP vêm principalmente de TTFB (hospedagem compartilhada barata, sem cache de opcode) e imagens hero sem otimização; problemas de INP vêm do excesso de JavaScript dos construtores de páginas (Elementor, Divi); CLS vem de imagens sem dimensões e fontes web sem font-display: swap. Temas leves (GeneratePress, Kadence, Astra), junto de um plugin de cache, uma CDN e formatos modernos de imagem, fazem um site WordPress bem construído passar confortavelmente pelos Core Web Vitals. O detalhe está no cluster de Web Performance.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.