Os guias oficiais de escrita da Microsoft e do Google são poderosos. Eles ensinam a escrever frases curtas, colocar o ponto principal primeiro, padronizar os termos, redigir de um jeito que traduza bem e deixar o texto fácil de ler para qualquer pessoa.
Mas remédio forte não deixa ninguém saudável só porque a pessoa tomou o vidro inteiro. Se você aplica um guia oficial de forma mecânica, como se fosse uma lei que precisa ser cumprida ao pé da letra, o seu artigo de repente vai trabalhar na central de ajuda de uma empresa. O texto que ontem reclamava "mas por que isso funciona assim?" amanhece dizendo só "Execute as etapas a seguir". A personalidade foi passada por um comitê de aprovação.
A conclusão é simples.
Dos guias oficiais, você pega a sabedoria sobre estrutura, clareza, acessibilidade e escrita multilíngue, que existe para o leitor não se perder. O que você não pega é a padronização de estilo que não combina com o propósito do seu veículo.
E isso não é uma fase de rebeldia contra os guias. O próprio guia de estilo do Google para desenvolvedores diz para usar primeiro as regras específicas do projeto e que você pode se afastar do guia se isso ajudar o leitor.[4] No fim das contas, tanto a Microsoft quanto o Google colocam no centro que o leitor entenda com facilidade.[1][2][5]
A conclusão em 5 segundos: guia é guard-rail, não constituição
Para usar um guia oficial sem acidentes, ajuda dividir em três camadas.
| Camada | Papel | Exemplos |
|---|---|---|
| Requisitos obrigatórios | O que precisa ser cumprido: leis, normas, especificações formais | Requisitos formais de acessibilidade, nomes exatos de produtos, citações e fontes |
| Recomendações fortes | Princípios que melhoram muito a leitura | Conclusão primeiro, títulos que criam fluxo, parágrafos curtos, termos padronizados |
| O tempero do veículo | O que se desenha de acordo com o site, o autor e os leitores | Humor, metáforas, comentários sarcásticos, ritmo, finais de frase, piadas internas |
O problema acontece no momento em que você transforma as três camadas em "regras absolutas".
Por exemplo, o guia do Google para desenvolvedores aconselha evitar expressões idiomáticas e humor que dependam da cultura em documentos técnicos para o público global.[5] Para um documento que explica como configurar uma API e será traduzido para 12 idiomas, isso faz todo o sentido.
Mas não é motivo para transformar resenha de restaurante, diário de viagem, relato de jogo, crônica ou texto de observação em "Proibido rir: 24 horas de documentação técnica".
Se você importa regras sem olhar onde elas se aplicam, pode montar a máquina errada com peças perfeitamente boas.
Por que seguir o guia oficial à risca costuma deixar o texto sem sabor
A orientação da Microsoft sobre textos fáceis de escanear recomenda colocar a informação importante primeiro, usar títulos, frases e parágrafos curtos, e dar aos textos longos um jeito de navegar.[1] A orientação de acessibilidade também valoriza textos curtos, com sentido e focados.[2]
Até aqui, tudo muito sólido.
Só que, quando você automatiza e começa a pontuar com regras como "quanto mais curto, mais pontos", "apague metáforas", "apague palavras de emoção", "apague a linguagem coloquial", tudo quebra.
Você acaba com frases curtas demais.
E aí.
O texto.
Vira isso.
Você queria deixar mais legível, e o que recebe é um robô mandando telegramas.
Do outro lado, se você padroniza todos os parágrafos em "conclusão, motivo, exemplo", nos primeiros artigos é gostoso, mas no artigo de número 1000 o leitor já adivinha o futuro. A consistência no desenho da informação é necessária, mas a encenação não precisa ser idêntica.
Deixar o texto legível não é tirar a personalidade dele.
É reduzir o esforço desnecessário que o leitor faz só para entender o sentido.
O que a Microsoft e o Google realmente dizem
Se você resume os guias oficiais, o que eles têm em comum é surpreendentemente simples.
A Microsoft defende com força o que podemos chamar de "não deixar o leitor se perder": colocar o importante primeiro, escrever curto e claro, adicionar navegação aos textos longos, manter a estrutura consistente.[1] Em acessibilidade, também valoriza frases curtas e com sentido, e boa estrutura.[2] Para conteúdo global, diz que frases curtas e simples e terminologia consistente facilitam a tradução.[3]
O guia do Google para desenvolvedores também recomenda escrita clara, concisa e sem ambiguidade, explicações diretas e terminologia consistente.[5] Mas no topo desse mesmo guia está escrito que se deve usar primeiro o estilo específico do projeto e que é permitido se afastar do guia se o conteúdo melhorar.[4]
Do lado da busca, o Google se importa menos com o texto parecer "estilo Google" e mais com informação original, análise própria, explicação suficiente, experiência de primeira mão e conteúdo que permite ao leitor alcançar o que veio buscar.[6] A orientação de 2026 para a busca com IA generativa também valoriza um ponto de vista próprio e "conteúdo que não seja o lugar-comum que qualquer um poderia produzir", em vez de uma reciclagem do que já existe.[7]
Ou seja, juntando todos os documentos oficiais, o resultado é este:
Deixe legível. Seja preciso. Ajude o leitor. E não vire uma fotocopiadora.
É uma exigência bem humana.
Não transforme números inventados em "padrão do Google"
O mais perigoso na automação de textos é promover a oráculo números que os guias oficiais nem mencionam.
"Cada frase deve ter menos de 20 caracteres, segundo o Google." "Artigos com mais de 2000 caracteres ajudam no SEO." "Sempre tem que ter tantos subtítulos." "A proporção de jargão deve ficar abaixo de tanto por cento."
Números assim podem ser usados como limites de alerta internos. Mas se a fonte oficial não diz, não se pode chamar de "obrigatório do Google" nem "obrigatório da Microsoft".
Na verdade, a orientação do Google Search sobre conteúdo feito para pessoas sugere justamente que você se pergunte se está ajustando o texto a uma contagem de palavras porque acha que o Google prefere, e afirma claramente que não existe uma contagem de palavras preferida.[6]
Por isso, nas verificações automáticas, o veredito se divide em três tipos:
- Requisitos oficiais obrigatórios: viram obrigatórios, com a fonte anexada.
- Recomendações oficiais: viram avisos ou candidatos a melhoria.
- Nossas regras práticas: ficam marcadas como regras internas, sem pegar emprestado o selo oficial.
Não vista a "regra que a gente inventou" com o uniforme do Google. Só isso já deixa tudo bem mais saudável.
Um projeto em três camadas para unir legibilidade e graça
O texto de um artigo fica mais fácil de lidar quando dividido em três camadas.
1. O esqueleto do sentido
Fatos, conclusões, números, datas, condições, citações, fontes, incerteza.
Aqui não se brinca. Se num guia de jogo o dano é 3, não se escreve 30 porque fica mais engraçado. O mundo quebra antes da risada.
2. O caminho da compreensão
Títulos, resumos, ordem, parágrafos, tabelas, exemplos concretos, explicações de termos, links internos.
Aqui se despeja a sabedoria da Microsoft e do Google em grande quantidade. A ideia é que o leitor nunca fique pensando "onde estou?" ou "afinal, qual é o ponto?".
3. A voz do artigo
Metáforas, piadas, comentários sarcásticos, observações, ritmo, jeitos de dizer, exemplos esquisitos.
Se você corta tudo isso, a informação pode estar certa, mas deixa de existir um motivo para ler justamente neste site.
O importante é que a camada 3 não quebre a camada 1.
Piada ruim esconde o sentido. Piada boa ajuda a lembrar do sentido.
Por exemplo, dizer "A gestão tripla é importante" é fraco.
Mas se você diz "Só a memória é filosofia, só o GitHub é constituição, só a agenda é um funcionário. Só quando as três se conectam existe uma fábrica", a pessoa lembra também a diferença entre os papéis.
A piada está carregando a bagagem da explicação. Aí ela está trabalhando.
Em 12 idiomas, não se traduz a piada: traduz-se o trabalho da piada
O que mais quebra na escrita multilíngue é o humor, não os fatos.
A frase japonesa "o artigo foi trabalhar na central de ajuda" talvez sobreviva a uma tradução mecânica para o inglês. Mas trocadilhos, memes de internet, piadas de final de frase e referências culturais têm índice alto de acidente.
O guia do Google para documentação técnica global evita expressões e humor dependentes de cultura justamente para reduzir esses acidentes de tradução.[5]
No entanto, para um artigo geral, a solução não é simplesmente "tirar o humor de todos os idiomas".
Separe o sentido da função da piada.
Se a piada da versão japonesa serve para aliviar a tensão de uma explicação dura, em inglês use uma tirada leve que soe natural em inglês. Em coreano, crie uma pausa natural em coreano. O mesmo vale para chinês, espanhol, português, indonésio, tailandês, vietnamita, francês e alemão.
O que fica fixo: fatos, números, lógica, fontes, incerteza.
O que pode ser regenerado: ordem das palavras, metáforas, ganchos, analogias, piadas, ritmo da explicação.
Doze idiomas têm menos a ver com "converter o japonês onze vezes" e mais com "escrever o mesmo artigo doze vezes, direito".
Em vez de fábrica de tradução, é uma reunião de doze editores. Uma reunião que, por incrível que pareça, serve para alguma coisa. Raro.
As regras ficam em três lugares: memória, fonte oficial e instruções de execução
Numa fábrica automática de artigos, não dá para relaxar só porque você definiu uma boa regra uma vez.
Uma pessoa pode dizer "aquilo que eu falei" e ser entendida. Um processo automático, na próxima execução, faz cara de quem esqueceu tudo.
Por isso se divide em três.
| Onde | Papel | O que colocar |
|---|---|---|
| Memória | A intenção editorial de longo prazo | Por que existe essa política e o que não pode ser quebrado |
| Fonte oficial (GitHub etc.) | As regras oficiais detalhadas | Critérios de decisão, exemplos, escopo, histórico de alterações |
| Agenda e instruções de execução | A ação de cada vez | Ler a fonte oficial mais recente antes de executar; não priorizar regras fixas antigas |
O ponto importante é não copiar e colar a mesma regra longa nos três lugares e acabar com três fontes oficiais.
Com três fontes, na semana seguinte as três estão dizendo coisas diferentes. Isso não é clone, é guerra civil.
A fonte oficial das regras detalhadas fica concentrada em um só lugar. A memória guarda a intenção, e a agenda tem um contrato de execução que diz "leia a fonte oficial mais recente".
Assim, a filosofia de escrita, a especificação formal e cada execução ficam conectadas.
A verificação automática também precisa olhar se "a personalidade foi apagada"
As verificações de texto tradicionais olham erros de digitação, tamanho das frases, títulos, links e fontes.
Se só isso for verificado, depois de cem rodadas de melhoria de qualidade todos os artigos podem acabar com a mesma cara.
Por isso, inclua também estes itens:
- Dá para pegar a conclusão logo de cara?
- O fluxo se entende só pelos títulos H2?
- O sentido passa mesmo sem conhecer os termos técnicos?
- As fontes, os números e a incerteza foram preservados?
- As observações, comparações, análises e experiências originais continuam lá?
- Foram cortadas sem necessidade piadas eficazes ou o calor humano que existia no original?
- O texto corrigido não degenerou naquele resumo de IA que existe em qualquer lugar?
- A mesma piada foi traduzida literalmente em 12 idiomas e causou um acidente?
- Algum limite que não está nos guias oficiais está sendo disfarçado de "obrigatório oficial"?
A política de spam do Google Search mira páginas produzidas em massa com IA generativa, tradução ou paráfrase que acrescentam pouco ou nenhum valor ao usuário.[8]
Ou seja, "a gramática está correta" é só o mínimo.
É preciso verificar se, depois da correção, o motivo para ler também não foi apagado.
Exemplos de falhas: o que os robôs de aprimoramento de texto costumam fazer
Falha 1: encurtar tudo
Divide todas as frases longas e quebra junto as ligações de sentido. A solução é olhar não a "brevidade", mas se as relações ficam claras numa só leitura.
Falha 2: usar a mesma sintaxe em tudo
Trava todos os parágrafos na mesma ordem e no mesmo ritmo. A solução é organizar a ordem da informação sem colocar o ritmo de uniforme.
Falha 3: tratar o humor como ruído
Apaga todas as metáforas e os comentários sarcásticos. A solução é manter as piadas que ajudam a entender e cortar só as divagações que atrapalham.
Falha 4: achar que escrever como o Google é SEO
Confunde o estilo da documentação para desenvolvedores com qualidade de busca. A solução é tratar guia de estilo, qualidade de busca, acessibilidade e localização como camadas separadas.
Falha 5: inventar números
Chama de "padrão do Google" um valor que não está em nenhuma fonte. A solução é dizer que é uma heurística interna, quando for.
Lista final: deixe o texto legível, mas não tire o toque humano de circulação
- O assunto e a conclusão ficam claros em 5 segundos.
- Dá para captar o panorama em 30 segundos.
- O fluxo se entende só pelos H2.
- Dá para entender com palavras comuns.
- Nomes oficiais, números e fontes estão corretos.
- Mesmo em textos longos, o leitor não se perde.
- Há valor original.
- As piadas ajudam a explicação.
- As piadas não estragam os fatos.
- A função das piadas está localizada nos 12 idiomas.
- Obrigatório oficial, recomendação oficial e regras internas não estão misturados.
- Mesmo depois das correções automáticas, continua existindo um motivo para ler neste site.
Os guias oficiais são poderosos. Justamente por isso, não engula tudo.
Da Microsoft, pegue o projeto que não deixa ninguém se perder. Do guia de documentação do Google, pegue a clareza e o desenho para o público global. Do Google Search, pegue o conteúdo feito para pessoas, o valor original e a confiança.
E a voz do site, essa você guarda para você.
Melhorar a qualidade de um texto não é colocar uniforme nele. É arrumar só os pontos em que o leitor se perde e deixar em paz aqueles em que a graça está fazendo o seu trabalho.
Guard-rail é necessário. Mas se a estrada inteira virar guard-rail, ninguém consegue mais passar.
