Comprimento dos parágrafos

O que esta verificação faz

Divide o corpo do conteúdo em parágrafos (por tags <p>, por mudanças duplas de linha em Markdown), conta palavras em cada um e reporta a média e o máximo. Marca parágrafos com mais de 80 palavras como demasiado longos.

Porque é importante

As pessoas não leem páginas web — varrem-nas, como o Nielsen Norman documentou em estudos de eye-tracking desde 1997, replicados de tempos a tempos. Parágrafos longos são paredes visuais: quem está a varrer bate neles, decide que aquilo parece trabalho e sai.

O efeito é amplificado em mobile, onde um parágrafo de 80 palavras enche o ecrã inteiro e parece ainda mais intimidante. A análise de legibilidade do Yoast SEO (que uma boa fatia do mundo WordPress segue) marca qualquer parágrafo com mais de 150 palavras como falha grave — usamos 80 como limiar de aviso porque os ecrãs mobile são mais pequenos hoje do que eram em 2010.

Como corrigir

Divide parágrafos com mais de 80 palavras em 2–3 mais curtos. Os pontos naturais para partir:

• Quando muda o assunto (“Agora, no lado técnico…”).
• Quando chegas a um novo passo ou nota num argumento.
• Depois de uma frase que funciona como takeaway autónomo.
• Antes de qualquer lista, bloco de código ou citação.

Antes (um bloco de 120 palavras):

Quando estás a configurar HTTPS no nginx, há alguns aspetos a considerar. Primeiro, tens de garantir que o teu certificado é válido e fiável para os principais navegadores, o que normalmente significa usar a Let’s Encrypt ou outra CA amplamente confiável. Assim que estiver instalado, vais querer configurar os protocolos e cifras para desativar tudo o que seja fraco — o TLS 1.0 e o 1.1 estão obsoletos, e várias suites de cifras antigas têm vulnerabilidades conhecidas. Também queres configurar HSTS para prevenir ataques de downgrade, mas tem cuidado com o max-age que defines, porque assim que um navegador vê o cabeçalho HSTS, vai recusar ligar em HTTP simples durante essa duração, mesmo que o teu certificado expire.

Depois (três parágrafos):

Quando estás a configurar HTTPS no nginx, três coisas importam mais: um certificado válido, protocolos modernos e HSTS.

Tira um certificado da Let’s Encrypt ou de outra CA fiável. Depois desativa protocolos antigos — TLS 1.0 e 1.1 estão obsoletos — e remove suites de cifras conhecidas como fracas.

Por último, configura HSTS para que os navegadores recusem ataques de downgrade. Tem cuidado com o max-age: assim que um navegador vê o cabeçalho, ignora o fallback para HTTP simples até o temporizador expirar.

A mesma informação, três vezes mais provável de ser lida.

Outras alavancas de legibilidade (cada uma é a sua própria verificação):

• Frases longas — frases longas em parágrafos curtos continuam a falhar.
• Comprimento médio das frases — ritmo.
• Voz passiva — longo e passivo é a pior combinação.
• Nível Flesch-Kincaid — pontuação global de complexidade.

Perguntas frequentes

Cada parágrafo deve ser uma única frase?

Não. Parágrafos de uma frase funcionam para ênfase mas perdem ritmo à escala. Aponta para 2–4 frases por parágrafo, com o ocasional uma-linha para ênfase. O ponto é variação, não extremos.

E documentação técnica com explicações longas?

Parte-as à mesma. Longo não significa denso — consegues escrever um parágrafo técnico completo em 80 palavras apoiando-te em listas, blocos de código e tabelas quando o conteúdo se adensa. Se um parágrafo precisa genuinamente de 200 palavras para passar a mensagem, pergunta se não devia ser uma lista ou uma secção separada.

Isto afeta o SEO diretamente?

Não como fator de ranking documentado. Mas o helpful-content system procura explicitamente conteúdo “fácil de varrer” e “bem organizado” — e taxa de rejeição, tempo na página e profundidade de scroll correlacionam todos com rankings. Muros de texto prejudicam isso, portanto prejudicam rankings por via transitiva.