HTML semântico e SEO: o que main, article e nav mudam

O HTML semântico não é um fator de ranking direto — mas influencia como o Google e os parsers baseados em IA constroem a representação de uma página, e isso pode afetar indiretamente rich results, resumos gerados por IA e a experiência de quem usa leitor de tela. A resposta curta para "html semântico ajuda no SEO" é: sim, mas não do jeito que a maioria explica.

Este texto olha para o que main, article, nav, section, listas e tabelas realmente mudam no processamento de uma página — e separa isso dos mitos que ainda circulam sobre a marcação HTML5. Não é sobre a hierarquia de h1 a h6: isso é um assunto próprio, com regras diferentes, e não será repetido aqui.

Como o Google e os parsers de IA leem a estrutura de uma página

Antes de qualquer análise de conteúdo, o rastreador do Google renderiza a página e constrói uma árvore de DOM; um navegador deriva dela também uma árvore de acessibilidade. Elementos semânticos — main, header, footer, nav, aside, article, section — mapeiam diretamente para landmarks nessa árvore de acessibilidade. São os mesmos landmarks que um leitor de tela usa para pular direto ao conteúdo principal ou à navegação, sem precisar ouvir a página inteira.

É razoável supor que o Google use sinais estruturais semelhantes para decidir o que é conteúdo principal e o que é boilerplate — o material repetido em todas as páginas do site, como menus, rodapés e barras laterais fixas. Esse processo já existia antes do HTML5, baseado em heurísticas de posição e repetição, mas marcação semântica correta reduz a ambiguidade que essas heurísticas precisam resolver.

Ferramentas de IA generativa que resumem páginas para responder perguntas diretamente fazem algo parecido em menor escala: extraem texto com mais confiança quando ele está dentro de um landmark reconhecível do que quando está solto em divs genéricas, porque a estrutura reduz o trabalho de inferir o que é conteúdo e o que é ruído. Isso não é o mesmo que dizer que HTML semântico é um fator de ranking — é mais preciso dizer que ele reduz o trabalho de inferência de quem está lendo a página automaticamente, e quando esse trabalho é mais fácil, a chance de o mecanismo de extração de conteúdo principal acertar sobe.

main e article: onde termina o boilerplate e começa o conteúdo

O elemento main deve aparecer exatamente uma vez por página, envolvendo o conteúdo que é único àquela página específica — o oposto do que fica em header, footer, nav e aside, que tendem a se repetir em todo o site e por isso são tratados como candidatos naturais a boilerplate.

article é conteúdo autocontido: precisa fazer sentido se distribuído isoladamente, fora do resto da página — um post de blog, uma notícia, um comentário, um card de produto. A pergunta prática para decidir entre article e section é simples: isso faria sentido em um feed, sozinho, sem o resto da página ao redor? Se sim, é article. Se é apenas uma divisão de layout dentro de um todo maior, é section.

Um erro comum em sites com abas ou conteúdo trocado via JavaScript é ter mais de um main na mesma página — um para cada estado visível — o que é inválido em HTML5 e confunde qualquer parser sobre qual é, de fato, o conteúdo real da página naquele momento.

• Um único main por página, sempre envolvendo o conteúdo exclusivo dela.
• article passa o teste: faz sentido sozinho, fora de contexto, como em um feed?
• Em uma listagem de produtos, cada card pode ser um article; a listagem em si, não.
• Cada comentário em um post de blog é um candidato natural a article.

nav: por que colocar links dentro dele não muda como são tratados

nav marca blocos de navegação para a árvore de acessibilidade, permitindo que um leitor de tela pule direto para o menu ou o ignore. Mas o Google já identificava blocos de navegação antes do HTML5 existir, por heurísticas como densidade de links, posição no layout e padrões de texto-âncora típicos de menu. Envolver esses links em nav não adiciona um sinal novo a um sistema que já infere isso pelo contexto — o benefício mais direto é para tecnologia assistiva, não para classificação de conteúdo.

Um mito recorrente é achar que colocar os links do rodapé dentro de nav faz esses links distribuírem mais valor interno de página. Isso é falso: o fluxo de valor por links internos segue o grafo de links do site, não a etiqueta HTML que envolve a âncora. A tag afeta como aquele bloco é classificado como navegacional, não o peso de cada link individual dentro dele.

Também não funciona na direção contrária: embrulhar uma grande lista de links não relacionados dentro de um nav, esperando que pareça navegação legítima, não muda a avaliação desse bloco — se os links não refletem a navegação real do site, o padrão continua se parecendo com uma lista de links manipulada, independentemente da tag usada.

section: a etiqueta mais mal utilizada do HTML5

section só funciona como landmark de acessibilidade quando é acompanhada por um heading que a descreve. Sem esse heading, na prática, deveria ser um div. Muitos frameworks e geradores de site geram section automaticamente para qualquer bloco de layout, sem heading algum — isso não agrega nada e às vezes piora a experiência, porque cria landmarks vazios ou genéricos demais na árvore de acessibilidade, dificultando a navegação por comandos de voz de quem usa leitor de tela.

Uma regra prática para decidir: se você não colocaria um h2 (ou heading de nível equivalente) logo ali, provavelmente aquele bloco não deveria ser section — deveria ser div.

Isso não é uma questão de penalidade de SEO — não existe uma penalidade documentada por usar section sem heading. É uma questão de utilidade real: uma marcação semântica aplicada sem critério não ajuda mais do que a ausência dela, e em alguns casos confunde ferramentas de acessibilidade e de extração de conteúdo que esperam que section signifique algo específico.

Listas e tabelas: a estrutura que ferramentas de IA generativa realmente aproveitam

É aqui que a estrutura tem o retorno mais claro e demonstrável para extração automática. Listas ordenadas e não ordenadas (ol e ul) e tabelas com thead, tbody e th usados corretamente são o formato mais fácil de extrair mecanicamente, porque delimitam itens discretos e, no caso de tabelas, pares claros de cabeçalho e valor.

Ferramentas que geram respostas resumidas — de featured snippets a resumos produzidos por IA generativa — historicamente preferem extrair de listas e tabelas porque a extração é determinística: cada item de lista é uma unidade, cada linha de tabela com th é um par claro de atributo e valor. Um parágrafo de texto corrido descrevendo os mesmos dados exige inferência de linguagem natural para separar os itens, o que é mais sujeito a erro de extração.

Na prática, isso significa que quando o conteúdo é genuinamente uma lista de passos, itens ou uma comparação, formatá-lo como lista ou tabela real — e não como texto corrido com "1)", "2)", "3)" dentro de um único parágrafo, nem como imagem de uma tabela — aumenta a chance de ser extraído corretamente, seja por um snippet, seja por qualquer parser de terceiros.

Um mito que vale descartar: nem toda tabela HTML ganha destaque nos resultados de busca. A estrutura torna a extração possível, não garantida — os fatores de relevância e a qualidade do conteúdo continuam decidindo se aquele trecho específico é o escolhido.

• Cada item de lista deve ser uma unidade de sentido completa, não um fragmento de frase.
• Tabelas devem usar th nos cabeçalhos de linha e coluna, nunca um td em negrito imitando um cabeçalho.
• Evite tabelas HTML criadas só para organizar texto visualmente — isso confunde parsers de dados tabulares que esperam relação real entre cabeçalho e valor.

O que HTML semântico não faz: os mitos que ainda circulam

Não é um fator de ranking direto e documentado: trocar todas as divs de um site por elementos semânticos não move, isoladamente, a posição de uma página no algoritmo de ranking do Google.

Não substitui dados estruturados. Schema.org, em JSON-LD, é o vocabulário formal que o Google interpreta para recursos como rich results; HTML semântico é sobre a estrutura do documento, não sobre a marcação de entidades e tipos de conteúdo. Um site pode ter HTML5 semântico impecável e nenhum rich result — e o inverso, dados estruturados corretos sobre uma marcação HTML genérica, também é comum.

Não corrige conteúdo fraco: a estrutura ajuda o parser a localizar o conteúdo principal mais rápido, mas se esse conteúdo é raso ou repetitivo, isso não muda a avaliação de qualidade sobre ele.

Não é sinal de acessibilidade completa por si só: usar as tags corretas é necessário, mas não suficiente. Ainda faltam texto alternativo em imagens, contraste de cores adequado e foco de teclado navegável, entre outros itens, para uma página ser de fato acessível.

Como verificar sua própria estrutura sem depender de suposições

Abra a aba de acessibilidade das ferramentas de desenvolvedor do navegador (em Chrome ou Edge, a árvore de acessibilidade dentro do painel Accessibility) e veja quais landmarks a página expõe de fato. Se main, navigation e conteúdo principal não aparecem claramente separados ali, a marcação não está cumprindo a função que deveria.

Teste a navegação por leitor de tela — VoiceOver no Mac, NVDA no Windows — usando o comando de saltar entre landmarks ou regiões. Se o leitor de tela não anuncia "navegação" ou "conteúdo principal" em nenhum momento, é sinal de ausência ou mau uso de nav e main.

Valide o HTML no validador do W3C para pegar erros estruturais óbvios, como mais de um main na mesma página ou um section mal formado. E observe como o modo de leitura do navegador (reader view) interpreta a página: se ele corta conteúdo importante ou inclui lixo de navegação junto do texto principal, é sinal de que os limites entre main, article e o resto não estão claros o suficiente para ferramentas automáticas.

• Árvore de acessibilidade nas ferramentas de desenvolvedor do navegador.
• Leitor de tela com navegação por landmarks (atalho específico de cada leitor).
• Validador de HTML do W3C.
• Modo de leitura (reader view) do navegador como teste indireto de extração de conteúdo.

Erros de implementação mais comuns

A maioria dos problemas não vem de ignorar HTML semântico, e sim de aplicá-lo de forma automática, sem checar se cada tag ainda representa o que deveria representar depois que o layout muda.

• Mais de um main na mesma página — por exemplo, versões mobile e desktop escondidas por CSS, ambas com seu próprio main.
• nav usado para blocos de link que não são navegação do site, como uma lista de "artigos relacionados" inserida no meio do texto.
• article aninhado sem necessidade, criando vários "artigos" dentro de um artigo só porque o CMS gera esse padrão por padrão em todo template.
• section sem heading correspondente, funcionando na prática como uma div com nome mais bonito e nenhum ganho real.
• aside usado para conteúdo que na verdade faz parte do argumento principal do texto, removendo-o indevidamente do que é tratado como conteúdo central.
• Reordenar visualmente blocos com CSS (flexbox ou grid) sem perceber que a ordem no DOM continua sendo a que o parser e o leitor de tela seguem.