Blocos de Conteúdo Relacionado: Regras de Linkagem Interna

Um bloco de conteúdo relacionado é um conjunto curto de links selecionados manualmente, colocado ao final do corpo principal. Ele leva o leitor à página seguinte mais útil e transporta autoridade interna ao longo do mesmo link. Cada destino deve ter uma razão editorial para existir; tags compartilhadas por si só não são suficientes.

O exemplo renderizado é propositalmente modesto. Seu título explica a escolha, cada âncora prevê o destino, e cada razão informa ao leitor por que aquela página é a próxima. O bloco não compete com o artigo que conclui.

Por que este elemento é importante

Terminar uma página útil cria um ponto de decisão. O leitor pode compreender o assunto imediato mas ainda precisar aplicá-lo, comparar opções, aprender um pré-requisito ou avançar em direção a um produto. Um bloco de conteúdo relacionado reduz o esforço de encontrar esse próximo passo. Ele oferece um pequeno conjunto de rotas propositadas no momento em que o leitor está pronto para escolher, em vez de pedir que ele retorne à navegação global ou pesquise novamente.

A segunda função é arquitetural. Autoridade interna é a importância e relevância contextual que os links ajudam a distribuir entre páginas de um mesmo site. Um link cria uma aresta entre dois documentos. Sua posição, âncora e explicação informam aos sistemas de recuperação o que essa aresta representa: qual página é a autoridade ampla, qual cobre um subtópico e qual responde a uma necessidade adjacente.

A extraibilidade por máquina significa que um sistema automatizado pode recuperar esses relacionamentos a partir do HTML sem adivinhar pelo layout. Uma região de navegação semântica, um título visível, links rastreáveis comuns, âncoras descritivas e um item por destino expõem um conjunto limpo de declarações fonte–relacionamento–destino. Carrosséis apenas com JavaScript, cartões apenas com imagem e âncoras genéricas obscurecem essas declarações mesmo quando parecem polidos.

Ambas as funções devem sobreviver à revisão. Um bloco que gera cliques mas envia autoridade para páginas não relacionadas prejudica o modelo de conteúdo; um mapa de cluster correto com links irrelevantes desperdiça o ponto de decisão do leitor.

Quando usar

Use este elemento quando a página tiver de dois a cinco próximos destinos críveis e o relacionamento puder ser declarado em uma linha. Ele pertence a conteúdo educacional perene, explicadores comerciais, comparações, páginas de produto e categoria, páginas de caso de uso e estudos de caso, quando outra página genuinamente avança a mesma tarefa ou decisão.

Não o adicione simplesmente porque um template tem espaço vazio. Uma página de conversão de propósito único com uma ação necessária pode precisar apenas de sua chamada para ação final. Um aviso legal, tela de conta, incidente de suporte ou página utilitária curta pode não ter continuação editorial sensata. Um índice cujo corpo principal já consiste em cartões de navegação não precisa de uma segunda lista repetindo-os.

Equívocos comuns incluem:

• Um feed de tags responde “o que compartilha este rótulo?”, não “o que este leitor deve fazer em seguida?” Dois artigos marcados como “analytics” podem atender públicos e estágios diferentes.
• Postagens recentes recompensam a data de publicação em vez da relevância. Atualidade é útil para descoberta de notícias, mas não é um modelo de relacionamento.
• Postagens populares otimizam para tráfego agregado, não para a pergunta atual.
• Um sitemap de rodapé apoia a descoberta ampla, não um pequeno caminho escolhido editorialmente.
• Um controle anterior/próximo reflete a ordem de publicação. Ele conta apenas quando essa ordem é em si um curso ou sequência deliberada.
• Links contextuais inline explicam termos ou apoiam alegações no ponto de necessidade. Eles complementam este bloco mas não substituem seu papel de decisão ao final da página.

A seleção é manual por padrão. Para cada link proposto, o editor registra uma razão como “aplica o método”, “define o pré-requisito”, “compara as duas opções introduzidas aqui” ou “mostra evidência na prática”. Se a razão for meramente “mesma tag”, remova o item.

A seleção automática é aceitável em arquivos de notícias, coleções geradas por usuários ou inventários grandes demais e voláteis para curadoria item por item. Mesmo assim, exija um conjunto candidato controlado, exclusões para a URL atual e páginas expiradas, atualidade quando o tempo importa, relevância além de uma tag, um critério de desempate estável e uma sobreposição editorial.

Onde posicionar

Posicione o bloco após o corpo principal completo e após o bloco de fontes, mas antes da chamada para ação final. A razão é sequencial: fontes encerram a obrigação de evidência da página atual; conteúdo relacionado oferece o próximo caminho de aprendizado ou avaliação; a chamada para ação final oferece o caminho comercial ou de produto. Quando uma página não tem bloco de fontes, o conteúdo relacionado segue a seção substantiva final.

Não coloque um segundo bloco de conteúdo relacionado em outro lugar da página. Não o posicione ao lado de navegação duplicada anterior/próximo, uma nuvem de tags densa ou outra coleção intitulada “Você também pode gostar”. Uma região de recomendação clara é suficiente.

Anatomia

Legenda renderizada:

1. Título da seção: nomeia o relacionamento, como “Aplique o que aprendeu” ou “Compare as próximas opções”. “Relacionado” genérico é aceitável apenas quando os destinos genuinamente abrangem diferentes ações.
2. Título do item: fornece a âncora descritiva e prevê o valor primário do destino.
3. URL de destino: resolve para uma URL interna canônica e rastreável sem cadeia de redirecionamento.
4. Miniatura: opcionalmente distingue um destino quando a imagem carrega informações reais de identificação.
5. Razão de uma linha: opcionalmente explica por que esta página é o próximo passo lógico; é fortemente recomendada quando o relacionamento não é óbvio pelo título.
6. Limite do bloco: agrupa os links como navegação sem tornar o cartão inteiro um alvo de clique ambíguo.

A legenda pertence à página em vez de dentro da imagem para que permaneça selecionável, traduzível e disponível para tecnologia assistiva.

Exemplos de design

As variantes mudam a densidade de informação, não a lógica editorial.

Apenas texto: o padrão quando os títulos dos destinos tornam o relacionamento claro.

Com razões: o padrão para diferentes estágios de jornada. A razão adiciona o relacionamento em vez de reafirmar o título.

Com miniaturas: reservado para casos onde a imagem original ajuda no reconhecimento. Imagens precisam de dimensões e texto alternativo útil, ou alternativo vazio quando o título já nomeia o destino.

Entre pilares: torna explícitos os relacionamentos entre tipos de postagem, elementos e aplicações de negócio. É gerado a partir do frontmatter revisado, não de tags.

Parâmetros

Dois itens são permitidos apenas quando a página tem uma bifurcação estreita e crível. Três a cinco é a faixa normal: escolha suficiente para atender diferentes próximas necessidades, mas poucos o bastante para cada link permanecer visível e intencional. Seis é uma exceção rigorosa para um pilar que precisa expor um cluster pequeno completo. Mais de seis torna-se um diretório, enfraquece o sinal editorial de cada aresta e torna a varredura em dispositivos móveis custosa.

Um atributo de título omitido pode ser derivado do primeiro título no corpo do item. Não forneça ambos com texto diferente. Uma razão pode viver no atributo para uma frase simples ou no corpo quando precisar de ênfase inline; não deve aparecer duas vezes.

Sintaxe e exemplos de código

O nome do componente canônico é related-content. A forma aninhada ::item{} mantém os campos de cada destino juntos e evita que matrizes paralelas se desalinhem.

Diretiva Markdown portátil

:::related-content{heading="Continue com o playbook" variant="reason"}
::item{title="Escreva um guia de instruções confiável" url="/seo-playbook/post-types/how-to-guide/" reason="Transforme as regras do elemento em uma página instrucional completa."}
::item{title="Estruture um guia definitivo" url="/seo-playbook/post-types/ultimate-guide/" reason="Conecte este elemento a um pilar amplo e seus raios de apoio."}
::item{title="Construa uma página de caso de uso" url="/seo-playbook/post-types/use-case-page/" reason="Leve a intenção educacional para um público e resultado específicos."}
:::

Shortcode Hugo

{{< related-content heading="Continue com o playbook" variant="reason" >}}
  {{< item title="Escreva um guia de instruções confiável" url="/seo-playbook/post-types/how-to-guide/" reason="Transforme as regras do elemento em uma página instrucional completa." />}}
  {{< item title="Estruture um guia definitivo" url="/seo-playbook/post-types/ultimate-guide/" reason="Conecte este elemento a um pilar amplo e seus raios de apoio." />}}
  {{< item title="Construa uma página de caso de uso" url="/seo-playbook/post-types/use-case-page/" reason="Leve a intenção educacional para um público e resultado específicos." />}}
{{< /related-content >}}

Este é o contrato de destino portátil, não uma afirmação de que este repositório registra o shortcode. O exemplo ao vivo usa HTML semântico e não adiciona dependência de layout.

Bloco ou shortcode WordPress

<!-- wp:amicited/related-content {"heading":"Continue com o playbook","variant":"reason"} -->
[related_item title="Escreva um guia de instruções confiável" url="/seo-playbook/post-types/how-to-guide/" reason="Transforme as regras do elemento em uma página instrucional completa."]
[related_item title="Estruture um guia definitivo" url="/seo-playbook/post-types/ultimate-guide/" reason="Conecte este elemento a um pilar amplo e seus raios de apoio."]
[related_item title="Construa uma página de caso de uso" url="/seo-playbook/post-types/use-case-page/" reason="Leve a intenção educacional para um público e resultado específicos."]
<!-- /wp:amicited/related-content -->

WordPress deve usar um bloco dinâmico registrado com controles de item aninhados. A forma de shortcode é para sistemas que não podem armazenar blocos aninhados e deve ser registrada antes da publicação.

Exemplos

Bom: cada link responde a uma necessidade diferente de próximo passo

:::related-content{heading="Coloque o método em prática" variant="reason"}
::item{title="Execute a checklist de QA pré-publicação" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Verifique links, evidências, acessibilidade e estrutura da página antes do lançamento."}
::item{title="Construa um guia de instruções" url="/seo-playbook/post-types/how-to-guide/" reason="Aplique o elemento dentro de um formato instrucional completo."}
::item{title="Adapte o playbook para SaaS" url="/seo-playbook/business-types/saas/" reason="Traduza as regras compartilhadas para uma jornada de conteúdo orientada a produto."}
:::

Isso funciona porque os destinos são distintos mas conectados: verificação, implementação e adaptação de negócio. As âncoras declaram o que cada página entrega, e as razões explicam o relacionamento com a página atual.

Ruim: o widget de tag se passa por seleção editorial

:::related-content{heading="Você também pode gostar"}
::item{title="Leia mais" url="/blog/new-office/"}
::item{title="Clique aqui" url="/features/ai-visibility/"}
::item{title="Postagem mais recente" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="Mais SEO" url="/blog/old-seo-notes/"}
::item{title="Outro artigo" url="/academy/how-to-export-prompt-data/"}
::item{title="Recomendado" url="/case-studies/hz-containers/"}
:::

O exemplo falha mesmo que toda URL resolva. Sete escolhas excedem a faixa. As âncoras não preveem o destino. Os destinos misturam notícias da empresa, produto, arquivo, academia e intenção de estudo de caso sem razões declaradas. “Mais recente” é uma regra de data, “SEO” é amplo demais, e nada prova que os links servem à próxima tarefa deste leitor.

O contrato do cluster

Um cluster de tópicos é um grupo planejado de páginas em torno de um assunto. Seu pilar é a página ampla que organiza o assunto; seus raios são páginas mais específicas que respondem a partes dele. O bloco de conteúdo relacionado transforma esse plano em links HTML reais:

• Cada raio linka para cima até seu pilar. Isso informa aos leitores onde a resposta específica pertence e impede que o raio se torne um ponto final isolado.
• O pilar linka para baixo até cada raio atual. Quando o cluster tem mais de seis raios, use seções organizadas no corpo do pilar em vez de forçar o conjunto completo em um bloco de conteúdo relacionado.
• Links laterais conectam um raio a outro apenas quando um leitor pode declarar a relação de próximo passo. Compartilhar um pai não é suficiente.
• Toda aresta é bidirecional quando ambas as direções ajudam um leitor. A âncora e razão reversas podem diferir porque a jornada difere.
• Remover, mesclar ou redirecionar uma página dispara uma revisão de cada aresta armazenada que aponta para ela.

Dentro deste playbook, uma página de tipo de postagem linka para os elementos que requer e para os tipos de negócio que a adaptam. Uma página de elemento linka de volta para os tipos de postagem que a usam. Esses relacionamentos são gerados a partir de frontmatter revisado sob as regras entre pilares: o array postTypes desta página é a origem para seus links de tipo de postagem, enquanto os metadados do tipo de postagem correspondente fornecem a aresta de retorno. A geração lida com a renderização; os editores ainda decidem se o relacionamento pertence aos metadados.

As regras de escrita de elementos mais amplas governam como esses metadados permanecem portáteis. Nunca repare um relacionamento editorial ausente adicionando uma tag e torcendo para um widget escolher corretamente.

Regras de texto âncora

Texto âncora é a redação visível e clicável de um link. Escreva-o de modo que um leitor possa prever o destino sem ler a URL. “Construa um guia de instruções” é útil; “leia mais”, “clique aqui”, “saiba mais” e uma URL nua não são.

Varie as âncoras naturalmente enquanto preserva o assunto do destino. “Crie um guia de instruções” e “estruture um guia instrucional” funcionam; sinônimos de palavras-chave não relacionados, não. Nunca prometa um template, calculadora, preço, estudo ou checklist que o destino não possui.

Dentro do bloco, as âncoras de título devem ser únicas. Se dois destinos usassem o mesmo título, adicione o público, método ou resultado distintivo. Mantenha a razão opcional fora da âncora para que o alvo do clique permaneça conciso e as listas de links da tecnologia assistiva permaneçam úteis.

Marcação Schema e acessibilidade

Nenhum tipo especial de JSON-LD é necessário. JSON-LD é um formato baseado em script para dados estruturados, e Schema.org é o vocabulário compartilhado comumente codificado com ele. Os links normalmente permanecem parte do Article, TechArticle, Product ou WebPage que os envolve. Não invente um tipo de schema RelatedContent.

Um ItemList pode descrever o bloco apenas quando for genuinamente uma lista editorial ordenada ou nomeada e a política de schema do site a exigir. Se usado, itemListElement deve corresponder à ordem visível dos itens, URLs e nomes. Não adicione destinos ocultos ou classificações sintéticas. Um breadcrumb é um relacionamento diferente e não deve absorver esses links.

A acessibilidade começa com um marco <nav>, ou seja, uma região que a tecnologia assistiva pode identificar como navegação. Dê a ela um título visível conectado através de aria-labelledby; ARIA é o conjunto de atributos usado para expor nomes e estados de interface quando o HTML nativo por si só precisa de ajuda. Use uma <ul> porque a ordem normalmente não carrega classificação. Preserve o foco de teclado visível, torne o título o link primário e evite aninhar um cartão interativo dentro de outro link.

O texto alternativo da miniatura não deve duplicar o título linkado. Use texto alternativo vazio para uma miniatura decorativa. Quando a imagem contribui com informação distinta, descreva apenas essa informação. O bloco deve permanecer completo com imagens ou JavaScript desabilitados, e não deve mover o foco do teclado quando as recomendações forem atualizadas.

Regras de escrita

Use de três a cinco itens por padrão, dois para uma bifurcação estreita, e no máximo seis para uma necessidade documentada de cluster pequeno. Escreva um título de duas a oito palavras, âncoras de título de três a doze palavras, e razões opcionais de oito a vinte e duas palavras. Razões usam uma frase, voz ativa e um relacionamento concreto: aplicar, comparar, verificar, definir, diagnosticar ou ver evidência.

Cada item precisa de uma razão editorial distinta no modelo de conteúdo mesmo quando a razão não é renderizada. Revise títulos após mudanças nos cabeçalhos dos destinos. Use URLs internas canônicas com barras inicial e final. Remova parâmetros de rastreamento, fragmentos que não identificam seções estáveis, redirecionamentos e links de volta para a página atual.

Nunca coloque anúncios, biografias de autor, botões de seguir em redes sociais, formulários de newsletter, nuvens de tags, promoções não relacionadas ou citações de fontes dentro deste elemento. Não misture leitura externa com próximos passos internos; evidência externa pertence ao bloco de fontes. Não use selos como “melhor”, “popular” ou “recomendado” a menos que a página defina e justifique a base de seleção.

O tom deve ser útil e específico, não urgente. Evite “imperdível”, “não perca”, escassez artificial e alegações de que o destino é abrangente a menos que seu escopo justifique essa palavra. O bloco recomenda um caminho; ele não fabrica importância.

Tipos de postagem que o utilizam

O array postTypes do frontmatter é a fonte da verdade para os seguintes relacionamentos entre pilares.

Nem todo candidato precisa ser renderizado em toda página. O tipo de postagem define o relacionamento elegível; o editor da página seleciona os destinos que fazem sentido para o assunto e jornada reais.

Checklist de QA

• O bloco aparece uma vez, após fontes e antes da chamada para ação final.
• A página contém de dois a cinco links, ou uma razão documentada para usar seis.
• Cada item tem uma razão editorial registrada além de uma tag, categoria ou data de publicação compartilhada.
• Cada âncora prevê o que o destino realmente entrega e evita “leia mais”, “clique aqui” e linguagem genérica similar.
• O conjunto apoia o contrato do cluster: raio para cima, pilar para baixo, e lateral apenas quando genuinamente relacionado.
• A URL atual está excluída, os destinos são canônicos, e nenhum link depende de redirecionamento ou parâmetro de rastreamento.
• O frontmatter de conteúdo relacionado concorda com os links entre pilares renderizados.
• O bloco permanece legível, navegável e completo sem miniaturas ou JavaScript.
• A região de navegação tem um título visível e um nome acessível; o foco de teclado está visível.
• Miniaturas existem, agregam valor de identificação, reservam dimensões e usam texto alternativo correto.
• Razões adicionam um relacionamento de próximo passo em vez de repetir títulos.
• Fontes, anúncios, formulários, links sociais e promoções não relacionadas permanecem fora do bloco.
• Qualquer dado estruturado ItemList corresponde exatamente aos itens e ordem visíveis.
• A renderização móvel expõe cada título e razão sem um carrossel horizontal oculto.

Um revisor deve rejeitar links meramente plausíveis. Cada um deve ser o próximo passo certo, expressar uma aresta arquitetural real e permanecer claro em HTML.

FAQ

O template da academia renderiza as entradas de FAQ a partir do frontmatter.