Se você produz conteúdo, dá para resolver boa parte do SEO técnico sem sair do CMS. Você pode organizar H1 e H2, ajustar title e slug, escolher boas âncoras e ligar o artigo à página-pilar. Também pode preencher o texto alternativo, subir imagens no tamanho certo e marcar como noindex o que não deve aparecer na busca. O desenvolvimento cuida da camada de baixo: como o template monta o HTML, se o texto depende de JavaScript para existir e se o layout pula enquanto carrega. Robots.txt, redirecionamentos no servidor e dados estruturados gerados automaticamente também ficam com o time técnico.

Quando a gente fala em SEO técnico, muita gente imagina código, servidor, erro 500 e uma tela preta de terminal. Para quem vive de conteúdo, o técnico é a infraestrutura que faz o seu texto chegar inteiro ao leitor, ao Google e às IAs generativas. Ele não é um fim em si.

Neste post, eu separo seção por seção o que você edita com as próprias mãos e o que vira tarefa bem descrita para o time técnico. Tem exemplo de código, sim, mas do tipo que você consegue ler sem virar dev.

Rastreamento e indexação do conteúdo

Antes de ranquear, o conteúdo precisa ser encontrado e guardado. Rastrear é o robô visitar a URL e baixar o que ela entrega. Indexar é o Google decidir que aquela página merece entrar no banco de dados de onde saem os resultados. São duas etapas diferentes, e muita confusão de quem escreve nasce de misturar uma com a outra.

O exemplo clássico é o robots.txt. Ele é um arquivo de regras de passagem: diz quais caminhos os robôs podem ou não visitar. Ele controla rastreamento, e só. Uma URL bloqueada no robots.txt pode continuar no índice se outras páginas apontarem para ela. Às vezes ela até aparece na busca com aquele aviso de que não há informação disponível sobre a página. Bloquear não é o mesmo que excluir.

Para tirar uma página dos resultados, quem resolve é a meta tag robots com noindex. E aqui mora a pegadinha: se a mesma URL estiver bloqueada no robots.txt, o Google não consegue ler o noindex, porque nem chega a abrir a página. Eu vejo esse nó em auditoria com frequência. Reuni outros casos parecidos no post sobre erros no arquivo robots.txt.

Na prática, o robots.txt de um blog em WordPress pode ser simples assim:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

A página que deve ficar fora da busca recebe, dentro do head:

<meta name="robots" content="noindex, follow">

No CMS, você quase nunca digita isso na mão. Plugins de SEO como Yoast, Rank Math e AIOSEO trazem uma opção do tipo “permitir que mecanismos de busca mostrem este conteúdo”. Quem produz conteúdo pode, e deve, revisar essa opção nos tipos de página que não merecem aparecer:

• páginas de agradecimento depois de formulário ou compra;
• resultados da busca interna do site;
• tags com um ou dois posts e nenhum texto próprio;
• landing pages de campanhas encerradas que ainda precisam existir;
• versões de teste publicadas por engano.

O arquivo robots.txt em si, os cabeçalhos HTTP (como o X-Robots-Tag para PDFs) e o sitemap gerado pelo servidor ficam com o desenvolvimento ou com quem administra a hospedagem. O seu papel é apontar o problema com a URL exata e o print do Search Console.

Logs, crawlers e Search Console: quem anda pelo seu site

Logs de servidor parecem território hostil para quem vem do conteúdo. Na prática, eles registram as pegadas que os bots deixam quando visitam o seu site. Ver esses registros pelo menos uma vez na vida muda a cabeça de qualquer estrategista. Nos acessos do Googlebot, você descobre quais páginas são rastreadas toda hora e quais quase não recebem visitas.

Muitas vezes, aquele conteúdo recém-publicado que você considera uma joia está praticamente invisível para o robô. Enquanto isso, arquivos de paginação e filtros inúteis consomem boa parte do tempo de rastreamento. Essa visão ajuda a decidir o que fazer:

• reforçar os links internos para páginas importantes;
• remover ou bloquear áreas sem valor para a busca;
• ajustar os sitemaps;
• priorizar as seções que realmente pesam no negócio.

O Search Console é o termômetro: mostra se o site tem febre, onde estão alguns erros e como o Google enxerga você em impressões e cliques. Ferramentas de crawl simulam o olhar de um robô dentro do site. Elas encontram páginas órfãs, correntes de redirecionamento, títulos duplicados e canônicos conflitantes. Uma rotina semanal simples já coloca qualquer criadora ou criador de conteúdo à frente da média:

• olhar o desempenho geral e os alertas de indexação no Search Console;
• rodar um crawler nas áreas alteradas recentemente;
• validar os dados estruturados dos conteúdos mais importantes.

JavaScript e conteúdo renderizado

Imagine que você escreve com uma tinta que só aparece sob uma luz especial. A boa notícia é que o Google tem essa luz: ele executa JavaScript com uma versão atualizada do Chrome e monta a página final, o chamado HTML renderizado. Por isso, conteúdo dependente de JavaScript não fica automaticamente invisível para o buscador. Esse mito ainda circula bastante por aí, e eu adoro derrubá-lo.

O risco está nos detalhes. O Google lê primeiro o HTML que o servidor entrega e só depois processa o JavaScript, que pode rodar mais tarde. Um script pode quebrar, uma API pode demorar ou estar bloqueada no robots.txt, e o texto pode depender de um clique que o robô não dá. Se título, subtítulos e parágrafos principais só aparecem nessa segunda etapa, você depende de tudo dar certo. Eu explico a diferença entre as duas versões no post sobre HTML renderizado.

Para quem escreve, a meta não é virar dev. Basta guardar um princípio: o que é essencial para a página fazer sentido precisa estar no HTML inicial.

Olha um bloco que eu encontro em blogs com tema “moderninho”:

<section id="resumo-do-post"></section>
<script>
  fetch('/wp-json/meu-tema/v1/resumo?post=123')
    .then(resposta => resposta.json())
    .then(dados => {
      document.getElementById('resumo-do-post').innerHTML = dados.html;
    });
</script>

No código-fonte, a seção está vazia. No navegador, o resumo aparece bonitinho. O Google pode ver esse texto depois de renderizar, desde que o endpoint responda rápido, não esteja bloqueado e o script não dê erro. Só que é muita condição para o trecho que explica do que a página trata. Nesses casos, eu peço ao time que o bloco venha renderizado no servidor (SSR) ou gerado de forma estática, e deixo o JavaScript para as interações. Você encontra os ajustes que mais aparecem nas minhas auditorias em boas práticas de JavaScript para SEO.

O que precisa estar no HTML inicial, sem depender de script:

• título e subtítulos;
• bloco principal de texto;
• introdução;
• principais argumentos e links internos.

Responsivo não quer dizer renderizado

Ouço muito “mas meu site é responsivo, então está tudo certo”. Responsividade é o CSS adaptando o layout ao tamanho da tela. Renderização é o processo de executar HTML, CSS e JavaScript para montar a página final. Um site pode se ajustar lindamente ao celular e ainda carregar o texto principal por script. Ele também pode esconder parte do conteúdo justamente na versão mobile, que é a versão que o Google usa para indexar.

O teste é simples. No Search Console, abra a inspeção de URL, clique em “Testar URL publicada” e depois em “Ver página testada”, na aba HTML. Procure uma frase do meio do texto. Também vale desativar o JavaScript no navegador: no DevTools, aperte Ctrl+Shift+P e digite “Disable JavaScript”. Se tudo some, não é sentença de morte, mas é sinal de dependência que merece conversa com o dev.

Abas, acordeões e botões de “ler mais” entram na mesma conta. Se o texto já está no HTML e só fica escondido visualmente, o Google lê. Se ele só é buscado no servidor depois do clique, o robô provavelmente nunca vai encontrá-lo.

Velocidade e estabilidade visual

Imagine que você escreveu a melhor carta de amor do mundo, mas guardou essa carta numa caixa-forte que demora oito segundos para abrir. A pessoa até quer ler, mas desiste antes do primeiro parágrafo. É isso que acontece com um conteúdo incrível numa página lenta.

O usuário chega com uma intenção de busca clara: resolver um problema, tirar uma dúvida, tomar uma decisão. Se o site demora, a mente dele entra no modo “isso aqui não vai me ajudar” e ele volta para o Google antes de interagir. O [tempo de carregamento e as Core Web Vitals] medem justamente essa experiência. São três métricas: LCP (quanto demora o maior elemento visível), INP (quão rápido a página responde a cliques) e CLS (quanto o layout se mexe sozinho).

Seu conteúdo não é julgado só pelo que diz, mas pela forma como aparece:

• rápido;
• estável;
• legível;
• sem ficar pulando enquanto carrega.

Veja como fica uma imagem com espaço reservado:

<img src="/uploads/capa-pao-fermentacao.webp"
     width="1200" height="675"
     alt="Pão de fermentação natural com casca dourada sobre a bancada"
     fetchpriority="high">

<img src="/uploads/passo-3-dobras.webp"
     width="800" height="600"
     alt="Mãos fazendo dobras na massa sobre a bancada enfarinhada"
     loading="lazy">

Com width e height no HTML, o navegador calcula a proporção (16:9 na capa, 4:3 na imagem do passo) e reserva o espaço antes do arquivo chegar. O CSS do tema completa o serviço com img { max-width: 100%; height: auto; }, e a imagem continua responsiva sem empurrar o parágrafo. Para vídeos incorporados e banners, o equivalente é aspect-ratio: 16 / 9 no contêiner. Repare que a capa não leva lazy load: ela é candidata a LCP e precisa chegar cedo.

No WordPress, o editor de blocos já insere width e height quando você usa uma imagem da biblioteca de mídia. O problema aparece em HTML colado de outro lugar, em page builders e em banners inseridos por plugin. No CMS, está nas suas mãos:

• comprimir e converter as imagens para WebP antes de subir;
• subir na largura que o layout realmente usa, e não a foto de 5.000 pixels da câmera;
• trocar GIFs enormes por vídeo curto ou imagem estática;
• limitar os embeds de redes sociais por post;
• fugir de pop-ups que cobrem o texto no celular.

Fontes, CSS, scripts de terceiros, cache e CDN ficam com o desenvolvimento.

Nota 100 não é a meta

Correr atrás da nota 100 em ferramentas de velocidade pode virar uma obsessão sem retorno proporcional. É como buscar o shape de fisiculturista só para passar no exame médico, quando o que você precisa é estar num nível saudável.

O mais importante é não estar na zona crítica. Se as métricas estão muito ruins, o usuário sente: página que demora demais, layout que salta, botão que não responde. Melhorar isso é obrigatório. A partir de certo patamar, porém, a diferença entre bom e perfeito aparece muito mais para a ferramenta do que para a pessoa real que está lendo seu texto.

Para quem vive de conteúdo, faz mais sentido manter uma boa experiência consistente do que sacrificar design, funcionalidades ou ritmo de publicação para espremer pontos no relatório. O objetivo é que o leitor chegue, leia sem atrito e queira continuar navegando, sem que o site vire um documento estático só para conquistar uma nota redonda.

Arquitetura e links internos

Pensa numa biblioteca enorme, cheia de livros incríveis, mas sem placas, sem números e sem estantes organizadas por tema. O visitante entra, vê o caos e sai achando que não tem nada ali para ele. O Google faz algo bem parecido quando olha para um site sem estrutura.

O problema que eu mais vejo é um erro na organização dos silos de conteúdo: não há hierarquia clara nem ligação temática entre os textos. Dezenas de artigos sobre assuntos diferentes ficam jogados num único blog, sem páginas-pilar e sem categorias pensadas. O buscador enxerga um monte de textos soltos, e não uma especialista num assunto.

A estrutura que funciona tem páginas-pilar cobrindo os temas principais e, ao redor delas, artigos específicos que se conectam de ida e volta. Breadcrumbs reforçam essa hierarquia para o leitor e para o robô. Um detalhe que eu faço questão de dizer: organizar em clusters ajuda a mostrar a relação entre os textos, mas não garante autoridade. Um cluster cheio de textos rasos continua raso. A estrutura amplifica o que o conteúdo já entrega.

Se você suspeita que suas categorias viraram gaveta de bagunça, uma auditoria de SEO técnico mostra páginas órfãs, profundidade de clique e links que apontam para redirecionamentos. Com isso em mãos, dá para priorizar o que arrumar primeiro.

Exemplo de ligação entre página-pilar e artigo específico

Vamos a um blog de culinária. A página-pilar é “Pão caseiro: técnicas, ingredientes e erros comuns”, na URL /pao-caseiro/. Um dos artigos específicos é “Como alimentar o levain sem deixar a massa azedar”, em /pao-caseiro/alimentar-levain/.

Na página-pilar, dentro do parágrafo sobre fermentação:

A fermentação natural depende de um fermento ativo. Se o seu perde força depois de dois dias na geladeira, veja como alimentar o levain sem deixar a massa azedar e ajuste a proporção de farinha e água.

A âncora é “como alimentar o levain sem deixar a massa azedar” e o destino é /pao-caseiro/alimentar-levain/. No artigo, o caminho de volta aparece onde faz sentido:

Esse cuidado com o fermento é só uma parte das técnicas de pão caseiro que reuni na página principal do tema, junto com hidratação e tempo de forno.

Aqui a âncora é “técnicas de pão caseiro” e o destino é /pao-caseiro/. As duas âncoras descrevem o destino, ficam no meio de uma frase que o leitor já estava lendo e dão ao Google uma pista clara da relação entre as páginas.

Âncoras e quantidade de links

Link equity funciona como um sistema de votos de confiança: cada página vota nas outras quando cria um link interno. Se você distribui esses votos de forma aleatória, em excesso e sem relação temática, dilui a força das páginas que deveriam se destacar.

Não existe número mágico de links por página, mas existe uma lógica saudável. Alguns links bem colocados no corpo do texto valem mais do que um bloco de vinte links no rodapé que ninguém clica. As páginas mais importantes precisam receber mais links das relacionadas, e os artigos menores ganham quando apontam de volta para elas.

O que faz a linkagem parecer spam é a repetição exagerada, a falta de relação entre os assuntos e as âncoras genéricas o tempo inteiro. “Clique aqui” e “saiba mais” não dizem nada sobre o destino, nem para o leitor nem para o robô.

URLs, títulos e dados estruturados

Essas três camadas ficam na fronteira entre conteúdo e técnica: você define boa parte delas no CMS, e o template decide como elas chegam ao HTML. Comece pela URL. Um slug curto, descritivo, em minúsculas e com hífens (/pao-caseiro/alimentar-levain/) diz mais do que /2026/08/03/post-123/. Um estudo de caso publicado na Revista FTEC, feito com uma loja virtual de vestuário feminino, destacou a otimização de URLs claras e das informações de produto em todos os itens do site.

Depois que o post está no ar e recebendo visitas, mexer no slug exige redirecionamento 301. Sem ele, quem chega pelo endereço antigo encontra um 404.

Se eu pudesse ensinar uma única coisa técnica para redatoras e copywriters, seria esta: use títulos e subtítulos como estrutura semântica, e não como escolha estética. O H1 é o tema da página, os H2 dividem o assunto em seções e os H3 aprofundam pontos dentro de cada seção.

Um exemplo de hierarquia para um post de receita:

H1  Como fazer pão de fermentação natural em casa
  H2  O que você precisa antes de começar
    H3  Ingredientes
    H3  Utensílios
  H2  Passo a passo da massa
    H3  Autólise
    H3  Dobras e descanso
  H2  Erros que deixam o pão solado

Os erros que eu mais encontro são estes: dois H1 na página (a logo do tema marcada como H1 mais o título do post), H3 usado só porque a fonte é menor, salto de H2 direto para H4 e headings que viram frase de efeito (“Bora lá!”). O title tag é outra peça: ele aparece na página de resultados e fica no campo do plugin de SEO. Já o H1 aparece na página. Os dois podem ter redações diferentes, mas precisam falar do mesmo assunto.

Quando essa hierarquia é respeitada, o conteúdo conta uma história coerente para pessoas e máquinas. Ela pesa em vários pontos:

• chance de aparecer em destaques de resposta;
• navegação mais fácil para quem lê na diagonal;
• acessibilidade para leitores de tela;
• rastreamento com menos esforço para o buscador.

Dados estruturados são como etiquetas nos potes da cozinha: “aqui é sal”, “aqui é açúcar”, “aqui é páprica”. Sem elas, a máquina precisa cheirar cada pote para adivinhar. Com marcações como Article ou BlogPosting, Person, Organization e BreadcrumbList, você informa diretamente o tipo de conteúdo, quem escreveu e onde ele se encaixa no site. A marcação de FAQ continua válida, mas o Google passou a exibir esse resultado enriquecido só para sites governamentais e de saúde.

No CMS, o plugin gera a maior parte do schema. A sua parte é preencher a bio do autor, a data de atualização e a imagem destacada. Quando o template gera um autor errado ou deixa de marcar a organização, a correção é tarefa do desenvolvimento.

Esses sinais também entram no E-E-A-T, que fica bem concreto quando você olha para os elementos técnicos:

• certificado de segurança (HTTPS);
• breadcrumbs;
• dados estruturados de autor e organização;
• páginas de contato e “sobre”;
• políticas de privacidade e termos de uso.

Com AI Overviews e outras respostas generativas, ser bem estruturado ajuda as máquinas a ler e atribuir o seu conteúdo com menos esforço. Não é garantia de citação. Mas, sem uma base técnica mínima, até o texto mais brilhante pode ficar de lado quando o sistema precisa escolher rapidamente em quais páginas confiar.

Mudou a URL? Migrações sem perder tráfego

Migrar um site é como mudar de casa. Se você não avisa os Correios e não deixa nenhuma placa, as cartas continuam indo para o endereço antigo e voltam com destinatário desconhecido. No digital, essas cartas são o seu tráfego orgânico. Uma mudança mal planejada é uma das formas mais comuns de derrubar uma estratégia de conteúdo que estava funcionando.

Os erros mais doloridos são técnicos:

• redirecionamentos mal feitos ou inexistentes;
• mudanças bruscas na estrutura de URL;
• remoção de páginas com histórico de links e tráfego;
• sitemaps desatualizados;
• perda de dados estruturados.

Para evitar o trauma, o preparo segue esta ordem:

• mapear as URLs antigas e as novas;
• garantir redirecionamentos permanentes;
• testar tudo em ambiente seguro antes de ir ao ar;
• monitorar de perto o comportamento do buscador nas semanas seguintes.

Quem produz conteúdo precisa estar nessa conversa, porque é quem sabe quais páginas são insubstituíveis para o negócio.

Conteúdo em outros idiomas

Levar o conteúdo para outros países vai além de traduzir. O hreflang funciona como um conjunto de placas que indica ao Google qual versão mostrar para quem: português do Brasil, inglês, espanhol da Espanha. Os desafios são de precisão e consistência:

• usar os códigos certos de idioma e país;
• garantir que as versões se referenciem mutuamente;
• não misturar tudo numa estrutura de URLs confusa.

Há também o lado humano. Um texto replicado sem adaptação cultural soa raso, mesmo tecnicamente impecável. Uma estrutura clara, como subdiretórios por idioma, junto com adaptação real de exemplos e chamadas, faz mais do que volume de tradução.

O que editar no CMS e o que solicitar ao desenvolvimento

SEO técnico e conteúdo funcionam melhor quando as duas pontas conversam desde o planejamento. A pessoa que escreve sabe quais páginas importam e o que o leitor procura. O time técnico sabe como o template, o servidor e os scripts se comportam. Quando cada um trabalha na sua bolha, o post sai lindo num site que esconde metade dele.

A divisão abaixo é a que eu uso em consultoria. Ela evita que você abra chamado para algo que resolve em dois minutos no editor, e também evita que você tente consertar no plugin um problema de template. Para melhorar a convivência com o time técnico, deixei dicas no post sobre como trabalhar com desenvolvedores.

Problema	Ação	Responsável
Post com dois H1 ou headings fora de ordem	Revisar os blocos de título no editor	Conteúdo (CMS)
Âncoras genéricas como “clique aqui”	Reescrever a âncora descrevendo o destino	Conteúdo (CMS)
Artigo novo sem links da página-pilar	Inserir links no corpo do texto da pilar e do artigo	Conteúdo (CMS)
Página de agradecimento aparecendo na busca	Marcar noindex no plugin de SEO	Conteúdo (CMS)
Imagem de 4 MB na capa	Comprimir, converter para WebP e substituir	Conteúdo (CMS)
Slug alterado em post já publicado	Criar redirecionamento 301 no plugin ou no servidor	Conteúdo e desenvolvimento
Texto principal ausente no código-fonte	Renderizar no servidor ou gerar a página estática	Desenvolvimento
Layout pulando ao carregar banner ou anúncio	Reservar espaço no template com CSS e aspect-ratio	Desenvolvimento
Logo do tema marcada como H1 em todas as páginas	Ajustar o template do cabeçalho	Desenvolvimento
Schema de autor ausente ou errado	Corrigir o template ou a configuração do plugin	Desenvolvimento
Robots.txt bloqueando CSS ou JavaScript	Revisar as regras no servidor	Desenvolvimento

Como pedir uma correção sem ruído

Chamado vago vira chamado esquecido. “O SEO está ruim” não cabe numa sprint. “A seção de resumo dos posts não aparece no código-fonte” cabe. Para facilitar a vida de quem vai corrigir, eu sigo esta ordem:

1. Informe a URL exata e se o problema se repete em todas as páginas do mesmo template.
2. Descreva o que você esperava ver.
3. Mostre o que acontece, com print da ferramenta ou trecho do código-fonte.
4. Explique o impacto: tráfego, conversão ou páginas fora do índice.
5. Combine como a correção vai ser validada.

Esse formato também ajuda a priorizar. Quando o dev vê que um ajuste no template corrige trezentas páginas de uma vez, a conversa sobre prazo fica bem mais fácil.

Automação no CMS: assistente ou sabotadora?

Automação técnica é como ter alguém arrumando a casa enquanto você cria. Bem usada, ela tira peso operacional: gera sitemaps, comprime imagens, checa links quebrados e minifica arquivos. Isso libera energia para a parte mais humana do trabalho, que é pensar, estruturar e escrever.

O problema começa quando a automação atravessa a fronteira da infraestrutura e ocupa o lugar da autoria:

• títulos genéricos gerados automaticamente;
• meta descriptions sem intenção;
• links internos feitos por plugins que ligam qualquer coisa a qualquer coisa;
• conteúdo criado em massa por IA sem revisão humana.

Tudo isso empobrece o projeto e aumenta a chance de o site ser percebido como mais um na multidão. Deixe o sistema cuidar das tarefas repetitivas de bastidor e mantenha o olhar humano nas camadas estratégicas:

• intenção de busca;
• argumentação;
• narrativa;
• posicionamento.

Dúvidas de quem produz conteúdo

Estas são as perguntas que mais chegam para mim em aula, mentoria e direct, quase sempre de redatoras e redatores que começaram a abrir o Search Console e se assustaram com o que viram. As respostas vão direto ao ponto.

Quando um alerta aparecer no Search Console, vale olhar primeiro para o que está nas suas mãos: profundidade do texto, hierarquia de headings e links vindos da página-pilar. Se o problema persistir depois desses ajustes, aí sim ele vira chamado para o desenvolvimento, com URL, print e impacto descritos. Assim cada dúvida deixa de ser susto e passa a ter dono claro, e o seu conteúdo chega inteiro ao leitor e ao buscador.