SEO Playbook · Element

O Que Fazer e o Que Não Fazer: Regras de Orientação Pareadas

Construa blocos de "o que fazer e o que não fazer" que pareiam ações equivalentes, explicam cada proibição e oferecem aos leitores e mecanismos de resposta uma orientação clara e prática que possa ser reutilizada.

17 min read

Um bloco de o que fazer e o que não fazer pareia uma ação recomendada com um erro de mesmo escopo e explica por que o erro falha. Seu valor vem do contraste: a versão errada expõe um modo de falha tentador, enquanto a versão certa oferece ao leitor uma substituição imediata.

Escrevendo alegações de comparação

  1. Faça: Nomeie o plano exato e a data verificada. Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação com segurança.
    Não faça: Não publique um preço sem data. Os leitores não conseguem identificar qual plano ou período o valor descreve.
  2. Faça: Compare ambos os produtos no mesmo critério. Uma medida compartilhada torna a diferença significativa.
    Não faça: Não compare a velocidade de um produto com o suporte de outro. Critérios diferentes criam a aparência de comparação sem uma escolha válida.
  3. Faça: Escreva "Desconhecido" quando não houver evidência disponível. Uma lacuna explícita distingue pesquisa faltante de funcionalidade ausente.
    Não faça: Não deixe um campo não verificado em branco. Um campo em branco pode ser interpretado como zero, indisponível ou não aplicável.

Este exemplo renderizado é o modelo de produção. Cada linha aborda um assunto no mesmo nível de detalhe. O “Não faça” nomeia um erro realista e sua consequência; o “Faça” fornece uma correção utilizável. Rótulos, e não cores ou ícones, carregam a distinção.

Por que este elemento é importante

Regras são mais fáceis de entender quando os leitores podem ver o limite que devem respeitar. Uma instrução positiva isolada pode parecer abstrata: “Use evidências específicas” não revela o que é considerado vago demais. Uma instrução negativa isolada cria atrito: “Não faça alegações sem fundamento” diz o que evitar, mas deixa o próximo passo incerto. Colocar as duas juntas transforma um limite em uma escolha que o leitor pode executar.

A versão errada é instrutiva porque frequentemente se assemelha ao que uma pessoa ocupada escreveria naturalmente. Mostrar esse erro próximo ajuda o leitor a reconhecê-lo em seu próprio trabalho. A razão é igualmente importante. “Não use linguagem vaga” exige obediência; “Não escreva ‘rápido’ sem nomear a tarefa medida, porque os leitores não podem verificar ou comparar” ensina um princípio que se transfere para novos exemplos.

Paridade significa que ambos os lados cobrem assuntos, contagens, detalhes e peso editorial equivalentes. Isso impede que uma coluna polida de “Faça” se situe ao lado de um monte de avisos não relacionados. Os leitores podem escanear um par, entender o contraste e continuar sem precisar lembrar de um item de outra parte da página.

Extraibilidade por máquina é a capacidade do software de isolar conteúdo preservando seu significado e relacionamentos. Cabeçalhos visíveis, estrutura de lista e pares alinhados em linhas permitem que sistemas de busca e mecanismos de resposta recuperem afirmações como “Para preços, nomeie o plano e a data; evite valores sem data porque seu escopo é inverificável.” Se os dois lados contiverem marcadores não relacionados ou a razão for implícita apenas por um ícone, a extração pode preservar o comando enquanto perde a qualificação que o torna seguro.

Siga as regras de escrita de elementos antes de selecionar este bloco. O propósito tem precedência sobre a aparência. Conteúdo que alerta principalmente sobre dano imediato continua sendo um aviso; uma sequência continua sendo uma lista de etapas; um conjunto finito de verificações de conclusão continua sendo uma lista de verificação. Duas colunas coloridas não transformam esses propósitos em “o que fazer e o que não fazer”.

Quando usar

Use este elemento quando os leitores precisarem distinguir uma prática recomendada de um erro plausível e consequente. O contraste deve reduzir a ambiguidade de forma mais eficaz do que uma única instrução. Assuntos adequados incluem padrões editoriais, convenções de implementação, controles de qualidade, comportamento de design, manipulação de dados e escolhas de processo.

Todas estas condições devem ser verdadeiras:

  1. Cada erro tem uma ação de substituição responsável.
  2. A razão para evitar o erro pode ser declarada em uma frase curta.
  3. Os itens são orientações independentes, não etapas que devem ser concluídas em ordem.
  4. Ambos os lados podem usar o mesmo escopo e nível de especificidade.

Casos de erro próximo são comuns:

  • Prós e contras: vantagens e limitações avaliam uma opção. “O que fazer e o que não fazer” instrui o comportamento do leitor. “Inclui projetos ilimitados” é um pró, não um “faça”.
  • Aviso: uma consequência severa ou irreversível precisa de destaque direto e uma resposta, não de uma coluna companheira de peso igual.
  • Lista de verificação: uma lista de verificação acompanha se o trabalho necessário está completo. Seu estado não verificado não é um “Não faça”.
  • Tabela de comparação: uma tabela avalia várias opções contra critérios compartilhados. Ela não prescreve comportamentos corretos e incorretos.
  • Antes e depois: dois exemplos podem mostrar uma edição sem expressar uma regra comportamental reutilizável. Use “o que fazer e o que não fazer” apenas quando o contraste ensinar uma prática geral.
  • Estilo interno arbitrário: se nenhuma consequência para o leitor, sistema, conformidade ou manutenção puder ser explicada, documente a convenção como uma regra em vez de fingir que a alternativa é um erro.

Não use o bloco para fabricar oposição. “Faça escrever claramente; não faça escrever obscuramente” reitera a mesma abstração e não ensina nada. O lado errado deve ser tentador o suficiente para ser reconhecido e específico o suficiente para ser diagnosticado.

Onde posicionar

Posicione o bloco depois que a página tiver definido a tarefa, o público e quaisquer termos necessários para entender a orientação. Ele pertence imediatamente após a explicação ou demonstração que resume, ou perto do final de uma seção como uma revisão prática antes de o leitor agir.

Regras exatas de posicionamento:

  • Introduza um tópico no cabeçalho mais próximo. Cada par deve fazer sentido sob aquele tópico sem tomar emprestado escopo de um parágrafo distante.
  • Coloque o bloco após o princípio orientador e antes de uma lista de verificação de implementação ou próxima ação. Os leitores devem entender o porquê antes de verificar a conclusão.
  • Em seções repetidas, use a mesma posição e os mesmos limites de pares. Mover o bloco de forma imprevisível dificulta a leitura entre assuntos.
  • Mantenha as listas pareadas juntas na ordem de origem e no layout visual. A prosa explicativa pode seguir o bloco completo, não dividir seus lados.

Ele não pode ficar diretamente ao lado de outro elemento de decisão de duas colunas, porque grades adjacentes obscurecem quais rótulos e linhas pertencem uns aos outros. Não coloque um depoimento, banner promocional, formulário ou chamada para ação entre os lados “Faça” e “Não faça”. Não o torne o primeiro conteúdo significativo em uma página quando as regras dependem de termos ou contexto que o leitor ainda não recebeu.

Anatomia

Legenda renderizada

  1. Cabeçalho do tópico: nomeia a tarefa delimitada ou decisão compartilhada por cada par.
  2. Rótulo Faça: texto visível identificando o comportamento recomendado; um ícone ou tratamento verde é suplementar.
  3. Rótulo Não faça: texto visível identificando o comportamento a evitar; a pontuação usa a forma editorial localizada.
  4. Declaração de ação: uma instrução imperativa ou declarativa que nomeia comportamento observável.
  5. Razão: uma frase conectando a instrução a uma consequência, modo de falha ou princípio orientador.
  6. Relação do par: ordem de origem e layout preservam qual “Faça” responde a qual “Não faça”.
  7. Nota de fonte opcional: identifica a política, teste, regulamentação ou evidência que rege os requisitos factuais.

O autor fornece o tópico, os pares e as razões. O renderizador fornece apresentação igual, empilhamento responsivo, rótulos acessíveis e ícones decorativos quando apropriado.

Exemplos de design

As variantes a seguir são o conjunto completo suportado. Elas alteram densidade e disposição, nunca a paridade ou o contrato de raciocínio.

Linhas pareadas padrão

Use de três a sete linhas horizontalmente alinhadas em telas largas. Cada linha contém um “Faça” e um “Não faça” sobre o mesmo assunto.

Pares móveis empilhados

Em larguras estreitas, mantenha cada par junto: “Faça”, depois “Não faça”, depois o próximo par. Empilhar todos os itens positivos antes de todos os itens negativos ocultaria a correspondência.

Variante liderada por exemplo

Use quando a linguagem exata, marcação ou comportamento de interface for mais útil do que um comando abstrato. Cada lado mostra um exemplo curto seguido por sua razão. O código permanece como texto selecionável.

Variante de revisão compacta

Use apenas quando as razões orientadoras já tiverem sido explicadas imediatamente acima. A razão ainda aparece em cada item, mas em uma frase curta em vez de um parágrafo separado.

Não crie variantes apenas com ícones, carrossel, abas ou colapsáveis independentes. Elas separam o par, ocultam um lado ou fazem a comparação depender de interação.

Parâmetros

O contrato modela pares em vez de duas listas não relacionadas. “Fonte” descreve de onde o renderizador obtém cada valor.

Parâmetros de interface de o que fazer e o que não fazer
NomeTipoObrigatórioMín./máx.PadrãoFonte
headingString simplesSim2–10 palavras; 100 caracteresNenhumPrimeiro cabeçalho no corpo
pairRegistro repetidoSim3–7 paresNenhumItem de corpo aninhado
doTexto simples com código inline limitadoSim por par1 ação; 110 caracteres recomendadosNenhumAtributo do par ou primeiro campo Faça no corpo
dontTexto simples com código inline limitadoSim por par1 ação; 110 caracteres recomendadosNenhumAtributo do par ou primeiro campo Não Faça no corpo
do-reasonString simplesSim por par1 frase; 180 caracteresNenhumCorpo sob o cabeçalho Faça
dont-reasonString simplesSim por par1 frase; 180 caracteresNenhumCorpo sob o cabeçalho Não Faça
variantEnumNãostandard, example-led ou compactstandardAtributo
source-noteTexto simples com links opcionaisCondicional1–3 fontesNenhumCorpo após todos os pares

O primeiro cabeçalho do corpo mapeia para heading. Cada pair aninhado possui ambas as ações e ambas as razões. O modelo de fonte não deve armazenar todos os itens positivos separadamente de todos os itens negativos, porque isso torna a correspondência de linhas dependente da posição no array e fácil de quebrar durante a edição.

Sintaxe e exemplos de código

Todos os três formatos preservam o mesmo tópico, ordem dos pares, ações e razões. Eles não inferem uma razão a partir da ação nem criam um item positivo automaticamente.

Diretiva Markdown portátil

:::dos-and-donts
## Escrevendo alegações de comparação

::item{do="Nomeie o plano exato e a data verificada" dont="Não publique um preço sem data"}
### Faça
Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.

### Não faça
Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.
::

::item{do="Compare ambos os produtos no mesmo critério" dont="Não compare capacidades não relacionadas"}
### Faça
Uma medida compartilhada torna a diferença significativa.

### Não faça
Critérios diferentes criam a aparência de comparação sem uma escolha válida.
::
:::

Este elemento substitui o mapeamento de item padrão: o cabeçalho pai fornece heading; os atributos do item fornecem as ações; os primeiros subtítulos Faça e Não faça mapeiam seu texto seguinte para as duas razões.

Shortcode Hugo

Nenhum shortcode Hugo de produção implementa atualmente o contrato de registro pareado. Até que um exista, renderize HTML semântico como o exemplo ao vivo em vez de usar dois auxiliares de lista não relacionados. O adaptador pretendido é:

{{< dos-and-donts >}}
## Escrevendo alegações de comparação

{{< do-dont-pair do="Nomeie o plano exato e a data verificada" dont="Não publique um preço sem data" >}}
### Faça
Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.
### Não faça
Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}

O renderizador futuro deve produzir uma região rotulada com uma lista de registros pareados. Ele não deve criar dois arrays e combiná-los por índice após a renderização.

Bloco ou shortcode WordPress

[dos_and_donts heading="Escrevendo alegações de comparação" variant="standard"]
[pair]
[do action="Nomeie o plano exato e a data verificada"]Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.[/do]
[dont action="Não publique um preço sem data"]Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.[/dont]
[/pair]
[pair]
[do action="Compare ambos os produtos no mesmo critério"]Uma medida compartilhada torna a diferença significativa.[/do]
[dont action="Não compare capacidades não relacionadas"]Critérios diferentes criam a aparência de comparação sem uma escolha válida.[/dont]
[/pair]
[/dos_and_donts]

Um bloco WordPress personalizado deve editar cada par como um registro e impedir a publicação quando uma ação ou razão estiver faltando.

Exemplos

Bom: equivalente, acionável e fundamentado

FaçaNão faça
Informe qual plano de preços você verificou. O escopo do plano impede que um preço válido seja aplicado à oferta errada.Não escreva “a partir de R$ 29” sem o nome do plano. O número pode permanecer tecnicamente verdadeiro enquanto engana o comprador pretendido.
Use a mesma janela de medição para cada opção. Períodos correspondentes tornam mudanças e classificações comparáveis.Não compare um total anual com um instantâneo mensal. Janelas diferentes podem criar um vencedor artificial.
Marque evidência indisponível como “Desconhecido.” O rótulo preserva a diferença entre incerteza e ausência.Não trate um fato omitido como “Não.” Documentação faltante não prova que uma capacidade está indisponível.

Os pares compartilham um assunto em cada linha: escopo do plano, janela de tempo e status da evidência. Ambas as ações são específicas o suficiente para serem revisadas em um rascunho, e cada razão explica o que pode dar errado. Um leitor pode aplicar o princípio mesmo quando o preço, produto ou período exato muda.

Ruim: duas pilhas de comandos

FaçaNão faça
Seja precisoNunca use jargão
Adicione exemplosNão escreva parágrafos longos
Mantenha simplesEvite muitos links
Verifique fatos

Isso falha porque as colunas são não relacionadas e desiguais. “Seja preciso” não tem condição de conclusão observável, enquanto “Nunca use jargão” proíbe linguagem sem distinguir termos necessários de termos não explicados. Nenhum dos itens negativos declara uma consequência, e a célula em branco expõe que o autor criou duas listas em vez de quatro pares.

Repare o bloco escolhendo um tópico e depois escrevendo linhas equivalentes. Para terminologia, o par poderia ser: “Defina um termo técnico necessário no primeiro uso, porque a definição permite que os novatos acompanhem o argumento” e “Não substitua um termo preciso por uma frase vaga do dia a dia, porque a substituição pode alterar o significado.” A correção ensina julgamento em vez de impor um slogan.

Marcação Schema e acessibilidade

O Schema.org não fornece um tipo geral DoAndDont. Mantenha o bloco visível dentro do Article, TechArticle, HowTo ou outros dados estruturados de nível de página quando essa página genuinamente se qualificar. Não converta os itens positivos em registros HowToStep a menos que eles formem um procedimento ordenado, e não publique os pares como FAQPage meramente porque contêm explicações curtas.

Use cabeçalhos e listas nativos. Uma seção externa recebe seu nome acessível do cabeçalho do tópico. Cada par deve ser um item de lista ou registro agrupado contendo um rótulo “Faça” visível e um rótulo “Não faça” visível. Preserve cada par na ordem de origem para que um usuário de leitor de tela encontre a recomendação e seu erro correspondente juntos.

Cor e ícones são suplementares. Verde não pode ser o único sinal para “Faça”, e um X não pode ser o único sinal para “Não faça”. Ícones decorativos recebem texto alternativo vazio ou são ocultados da tecnologia assistiva. Não torne um bloco estático focalizável. Se o transbordamento horizontal for inevitável para uma tabela de exemplo, contenha e rotule a região de rolagem; o componente de produção deve empilhar pares em vez disso.

A contração “Não faça” é aceitável como texto editorial visível. Campos de código usam dont seguro para ASCII onde apóstrofos complicariam nomes de atributos. Renderizadores localizam os rótulos sem alterar as ações ou razões armazenadas.

Regras de escrita

Escreva a razão antes de finalizar o comando. Isso força o autor a identificar a consequência para o leitor, sistema, segurança, conformidade ou manutenção. Se uma razão defensável não puder ser escrita, a proibição pode ser preferência em vez de orientação.

Use de três a sete pares. Cada ação deve expressar um comportamento observável em 110 caracteres ou menos quando prático. Dê a cada lado uma frase de razão de no máximo 180 caracteres. Os limites mantêm os dois lados escaneáveis; qualificações mais longas pertencem à prosa ao redor.

Mantenha a paridade em cinco dimensões:

  • Assunto: ambas as ações abordam a mesma decisão ou artefato.
  • Altitude: uma regra precisa de marcação não pode ser pareada com uma máxima ampla como “escreva bem.”
  • Gramática: use imperativos paralelos ou declarações declarativas paralelas.
  • Evidência: aplique o mesmo limiar factual e de fontes a ambos os lados.
  • Peso visual: nenhum lado recebe mais espaço, ênfase, detalhe ou visibilidade padrão.

Use linguagem direta e neutra. Prefira “Não publique um preço não verificado” a linguagem de vergonha como “Apenas escritores descuidados esquecem de verificar preços.” Evite sarcasmo, medo e termos absolutos, a menos que a regra seja genuinamente absoluta e seu escopo seja declarado.

Nunca coloque dentro do elemento:

  • Dicas não relacionadas adicionadas para preencher um lado ou forçar simetria numérica.
  • Uma proibição sem consequência, princípio ou ação de substituição.
  • Procedimentos ordenados, caixas de seleção, classificações, vereditos ou vantagens e limitações de produtos.
  • Avisos críticos de segurança, isenções legais, instruções de emergência ou avisos de ação irreversível.
  • Depoimentos, citações longas, mídia, formulários, chamadas para ação, botões promocionais ou códigos de cupom.
  • Acordeões aninhados, abas, carrosséis, tabelas de comparação ou outro bloco de “o que fazer e o que não fazer.”
  • Afirmações sobre pessoas ou grupos enquadradas como falha moral em vez de comportamento observável.

Quando um requisito vier de uma política, regulamentação, teste ou padrão externo, adicione uma nota de fonte próxima. Atribua a regra com precisão suficiente para que um editor possa re verificá-la; não faça o bloco carregar um aparato de citação longo.

Tipos de postagem que o utilizam

O array postTypes do frontmatter orienta esta matriz de uso. A inclusão torna o elemento disponível sob a condição declarada; não torna o bloco obrigatório em toda página desse tipo.

Tipo de postagemUsoPosição preferidaRegra especial
Guias de instruçõesRecomendado para escolhas de execução de alto risco ou frequentemente confusasApós o método relevante, antes da verificaçãoNunca substitua etapas ordenadas por pares.
Guias completosOpcional para uma prática delimitada com erros próximos recorrentesAo final da seção de ensino relevanteMantenha cada bloco em um tópico dentro do guia mais amplo.
Artigos de documentaçãoRecomendado para configuração, sintaxe ou convenções de fluxo de trabalhoApós o comportamento canônico ser explicadoCorresponda à versão do produto documentada e à interface.
Artigos de lista de verificaçãoOpcional como ensino antes das verificaçõesAntes da lista de verificação, nunca dentro delaPares explicam julgamento; verificações confirmam conclusão.
Postagens de erros a evitarRecomendado quando cada erro tem uma correção concretaApós diagnosticar o erro e a consequênciaNão comprima evidência no item negativo.
Páginas de políticasOpcional para interpretação prática de uma regra formalApós a regra autoritativa e escopoO bloco não pode criar requisitos ausentes da política.
Páginas de normas e regulamentaçõesOpcional para práticas conformes versus não conformesApós explicar a aplicabilidade e o requisito exatoCite a disposição controladora e evite conclusões legais além dela.
Postagens de frameworkOpcional para aplicação correta e incorreta de um frameworkApós introduzir a parte relevante do frameworkPareie o uso incorreto com o mesmo princípio do framework, não com conselho genérico.

Lista de verificação de QA

  • O bloco tem um tópico delimitado que fica claro a partir de seu cabeçalho mais próximo.
  • O princípio orientador aparece antes do bloco, para que os pares reforcem em vez de inventar a regra.
  • Há de três a sete pares completos e exatamente o mesmo número de ações “Faça” e “Não faça”.
  • Cada par aborda o mesmo assunto, público, escopo e nível de especificidade.
  • Cada “Não faça” nomeia um erro realista e explica sua consequência ou modo de falha.
  • Cada “Faça” fornece uma substituição acionável e explica por que funciona.
  • Nenhum item meramente nega seu parceiro, repete um slogan ou usa redação circular.
  • As ações contêm um comportamento e permanecem próximas ao alvo de 110 caracteres.
  • As razões contêm uma frase e permanecem dentro de 180 caracteres.
  • Ambos os lados usam gramática, padrões de evidência, detalhe e peso visual paralelos.
  • Requisitos factuais identificam sua política, regulamentação, teste ou fonte quando necessário.
  • O bloco não contém etapas, estados de verificação, compensações de produto, avisos severos, promoção, formulários ou elementos complexos aninhados.
  • O texto visível diz “Faça” e “Não faça”; cor, posição e ícones não são os únicos sinais.
  • A saída responsiva mantém cada par junto em vez de empilhar todos os itens positivos antes de todos os itens negativos.
  • O cabeçalho do tópico e a estrutura do par permanecem compreensíveis em texto simples e quando estilos ou scripts não estão disponíveis.
  • Os dados estruturados descrevem apenas a página envolvente e não inventam um tipo de schema de “o que fazer e o que não fazer”.
  • Comentários de captura de tela permanecem instruções de captura não renderizadas até que ativos reais existam.

FAQ

O template da academia renderiza as cinco perguntas armazenadas no frontmatter [[faq]] desta página. Elas cobrem completude dos pares, paridade numérica, razões, dados estruturados e contagem de itens.

← All SEO Playbook guides

Pronto para colocar em prática?

Verificação gratuita · Teste de 7 dias · sem cartão de crédito