Navegação e SEO, ajude o Google a encontrar suas páginas

Caravel
Originally uploaded by Lajoso

Nesta SEOgunda aprenderemos sobre o terceiro aspecto mais importante para seu sítio virtual ficar bem na fita com o Google: a navegação.

Navegar pelos sítios virtuais pode ser assustador. Serpentes marinhas gigantescas podem devorar seu browsers. O mar ferverá quando se atravessar a linha do Equador. Do ponto de vista de SEO, a função da navegação é guiar seguramente o Google pelo seu sítio, permitindo que ele não só encontre todas suas páginas, como descubra quais são as mais importantes.

Primeira coisa é entender como os mecanismos de busca descobrem as páginas que irão catalogar. Cada buscador tem um software que funciona como se fosse um browser, chamado de robô. Ao visitar uma página, ele automaticamente grava a página e clica em todos os links presentes. Para cada nova página visitada, ele clica nos links e visita todas as novas páginas. Vai assim até visitar todas as páginas de seu site.

A principal característica deste robô é que ele é burro. Ele não preenche nenhum formulário, não entende Javascript e (quase) não entende Flash. A única coisa que ele faz é ver o texto de suas páginas e clicar em links.

O que nos leva à Primeira regra SEO de navegação: toda página de seu sítio virtual tem que poder ser acessada apenas clicando em links a partir da página principal.

Se o robô do Google não puder chegar na sua página apenas clicando, ela não será indexada e nunca poderá ser o resultado de nenhuma busca (tá bom, tá bom, falaremos de sitemaps no futuro). O robô não preencherá um simples campo de busca para poder achar suas páginas antigas. Se você, por exemplo, publica notícias que expiram, mantenha um link para toda notícia expirada. Uma delas pode ter exatamente aquela palavra usada em um busca e ser responsável por lhe trazer um novo usuário.

Cada vez mais os sites criam esquemas de navegação mais espertos, cheios de animações e guéri-gueris. Apesar de divertidas, estas navegações podem destruir o ranking de seu site nos mecanismos de busca. O robô não entende Javascript nem Flash, as principais tecnologias destas animações. Se não entende, ele não conseguirá navegar nem catalogar suas páginas.

Segunda regra SEO de navegação: seu sítio virtual tem que ter uma barra de navegação para suas principais seções feita em HTML simples, usando apenas a tag <A HREF>. Se você tiver uma navegação para seções em Javascript, é preciso que ela degrade graciosamente e continue a funcionar mesmo ao desligar o Javascript do browser. Se tiver uma navegação em Flash, faça uma outra em HTML puro no pé de cada página.

Tome cuidado se você usa um Content Management System (CMS) que lhe gera automaticamente uma navegação. Ainda outro dia fiz uma consultoria SEO e me deparei com um CMS cuja navegação de seções padrão era toda em Javascript. O CMS tentava ser esperto, tinha um código para identificar se era o robô do Google que estava visitando. Se fosse, era mostrada uma navegação em HTML simples em vez da em Javascript. Só que mostrar uma página diferente para o robô e para o ser humano é uma das práticas mais abominadas pelos mecanismos de busca. É chamada de Cloaking e é muito fácil de ser descoberta. Nunca faça isto. Mesmo que os desenvolvedores do CMS estejam fazendo o cloaking de boa fé, não tem como o Google saber disto. Uma bobagem assim pode remover todo seu site das buscas do Google!!!

Estas barras com links também permitem que o mecanismo de busca identifique as principais seções de seu site. Estas seções serão links a mais que você terá direito na página de resultados de busca. Veja por exemplo o excelente trabalho que o Google faz para achar as seções do jornal New York Times:


Claro que nem sempre o Google acerta. Por isto você precisa ajudá-lo com uma boa navegação e arquitetura de informação. Ou você acha mesmo que Naruto é uma das seções mais importantes da Wikipédia? :-)


Você não pode dizer explicitamente pro Google as seções de seu site, apenas sugerí-las através dos links de navegação. Se acontecer contigo alguma tragédia como esta das seções da Wikipédia, não precisa ficar desesperado. Crie uma conta gratuita no serviço de Webmaster Tools do Google e remova as seções que você não quer que apareça.


Aguarde agora nossa próxima emocionante e informativa SEOgunda. Semana passada aprendemos sobre o mais importante elemento HTML para SEO, hoje foi terceiro aspecto mais importante. O que falta?

E se você for ansioso demais para esperar o desenrolar da série para otimizar seu site, lembro que já fiz e estou fazendo consultorias SEO/SEM. Entre em contato no email PauloNeves(arroba)gmail.com

SEOgunda, pois segunda é dia de SEO e SEM

Charo y su lupa [abr 11]
Originally uploaded by JavierPsilocybin

Gastar uns trocados em Search Engine Optimization (SEO) e Search Engine Marketing (SEM) é um dos dinheiros mais bem gastos para o dono de um website. Todo sítio virtual é no fundo um investimento em marketing. De que vale este investimento se seus clientes não te acham?

Para que seus clientes te achem na Internet, é preciso que antes agradar a outro visitante: Mr. Google. Suas páginas têm que ser feitas para que o mecanismo de busca as entenda e tire o máximo de informações delas. Não é difícil, nem tem mágica. É só não deixar o cara que desenvolveu seu site fazer muita bobagem.

O problema é que tem muito enganador por aí. O sujeito que promete colocar seu site no primeiro lugar do Google está te enrolando. Resolvi então iniciar uma série de posts para contar os "segredos" de SEO e SEM. Como publicarei um artigo toda segunda-feira, intitularei a série: "Segunda é dia de SEO". Serão nossas SEOgundas!(Ai!)

Vou começar com a mais importante dica de SEO. É uma coisa simples, mas que pode fazer a grande diferença para acharem seu sítio pelos mecanismos de busca.

É a tag <title> do HTML. Nela você coloca o – supresa! &ndash título de sua página. O problema dela é que ninguém presta atenção neste título. Quando vê a página, ele só aparece na barrinha da janela do navegador. É fácil passar desapercebido que não foi corretamente preenchido. Veja por exemplo como aparece o título desta página:


A tag <title> é importante porque:

• As palavras que estão ali têm um peso maior para o mecanismo de busca. Se o usuário buscar por uma palavra presente no <title>, sua página tem mais chances de ser retornada.


• O texto do <title> aparecerá na página de resultados do Google. Coloque ali termos que convencerão ao usuário a clicar na sua página. Nada adianta sua página estar em primeiro lugar se o usuário clica na segunda.


• O <title> é importante para usabilidade. Ele que permite diferenciar sua página entre as várias que estão abertas no seu desktop. O <title> também especifica como a página ficará guardada nos seus Favoritos.

Isto quer dizer que você vai colocar todo seu texto no <title> e sua página aparecerá no resultado de todas as buscas, certo? Errado. Somente os 65 primeiros caracteres são considerados pelo Google. Qualquer coisa depois será ignorada.

Uma boa regra para construir seu <title> é dividí-lo em 3 partes:

Título do conteúdo da página | Seção do site | Nome do site

Na primeira, vem o título da página mesmo. Por exemplo, se for uma notícia de um evento, você coloca aí a manchete. Se for um produto em um sítio de compras, coloque o nome do produto. Se for uma página sobre um pessoa, coloque o nome dela. A melhor maneira é fazer isto automaticamente no próprio sistema que gera as páginas. Algumas páginas mais importantes valem o esforço de fazer isto manualmente. Preencha o <title> com as palavras que o usuário pode usar para buscar pelo assunto da página. Lembre-se de colocar as palavras mais importantes sempre no início, pois estas são levadas mais em conta pelo Google.

Feche o <title> com o nome da seção de seu sítio onde está a página, isto pode dar um pista do assunto para o Google. Por fim coloque o nome do seu site no final, especialmente se ele tiver palavras que as pessoas usam para buscar.

Vamos fazer isto com um exemplo. Digamos que você está vendendo uma TV Sony Bravia. Você deve colocar o nome Sony Bravia, o nome do modelo, a seção e por fim o nome da loja:

Sony Bravia KDL-52V5100 - 52" LCD - 1080p (FullHD) | TV | Casas Maria

E aí tem um dos detalhes mais importantes. Na hora de preencher as palavras chave, é preciso se colocar no ponto de vista do usuário. Talvez Eletrodomésticos seja o nome do seu departamento que vende o produto. Só que ninguém busca por "Eletrodoméstico" no Google. O sujeito está querendo é uma TV. O nome de sua seção deve ser "TV" no singular.

Tentar pensar como seu usuário é um dos aspectos mais importantes para otimização SEO. Só que isto daí já é assunto para um outro post...

E se você for ansioso demais para esperar o desenrolar da série, aviso que já fiz e estou fazendo consultorias SEO/SEM. Entre em contato no email PauloNeves(arroba)gmail.com

Dicas para seu SQL não feder

Pra mim, a melhor tradução de code smells é fedentina de código.

A idéia de fedentina em código foi popularizada pelo ótimo livro Refactoring, do Martin Fowler. É uma indicação de que algo no código não está bem e merece ser analisado mais de perto. É como você andando na rua, sente um cheiro desagradável e olha a sola de seu sapato para checar se está tudo certo.

Tive que rever milhares de linhas de código SQL. Depois de um tempo, você deixa de tentar entender cada detalhe de comando e começa a funcionar por reconhecimento de padrões. Basta passar os olhos pelo código e logo vem aquele cheiro que tem algo mal feito por ali. Ao contrário do exemplo da sola de sapato, na maior parte das vezes há uma grande imundície.

Compartilho então com você, minha coleção de fedentinas em SQL:

DISTINCT

Uma vez, estava eu no departamento de TI de uma grande empresa e ouvi comentarem: "Já fiz o select, o único problema é que está vindo com alguns dados duplicados.", logo alguém respondeu: "É fácil resolver, basta usar o DISTINCT.". Argh! São raro os casos em que um DISTINCT é necessário. E normalmente o são por alguma falta de normalização no modelo de dados.

Ao usar o DISTINCT sem entender a query, você pode estar escondendo um lentíssimo produto cartesiano, ou mesmo um erro no seu código. Já vi códigos como este: SELECT DISTINCT P.Nome FROM pessoas P, equipe e WHERE e.id=123.

Parece estar tudo muito bom na sua base de testes quando você tem apenas uma única equipe e uma dúzia de pessoas. Quando entrar em produção: CABOOOM!!! Tudo vai estourar.

O mais provável é que o DISTINCT esteja acobertando a inexistência de um join na sua query. É preciso analisar a query com cuidado e checar não precisa acrescentar um join a mais entre as tabelas. Talvez seja o caso até de remodelar o projeto do banco de dados.

LIMIT 1, TOP 1, ou RowNum <=1

Esta é outra forma de esconder uma falta de join. O LIMIT é do MySql, o TOP 1 do SqlServer, e o RowNum do Oracle.

De vez em quando, sua consulta vai retornar mais de um elemento e você não entende o porquê. Qual a solução mais fácil? Ora, pegar só o primeiro e continuar correndo para entregar as coisas no prazo. Só terá é um bug sinistro pra pegar em produção. Afinal de contas, parar, pensar e olhar qual join poderia fazer a mais, ou que tabela está faltando incluir é muito difícil.

E tem o caso em que isto está 100% errado: é quando você usa um TOP 1 e não usa um ORDER BY. Como o SQL só trabalha com conjuntos, pegar o primeiro elemento sem ordenar antes, quer dizer que você está pegando um elemento aleatório. Pode até ser que seu SGBD seja sempre retornado o que você deseja, mas pequenas modificações no banco, como a criação de um novo índice, podem fazer com que um valor errado seja retornado de uma hora pra outra.

GROUP BY sem funções de agregação

Este é outro truque para evitar resultados repetidos e garantir um código desnecessariamente lento. Se nos resultados da query não tem nenhuma função COUNT, MAX, MIN ou similares, tem um erro aí. Certamente é mais um caso de join faltando que precisa ser investigado.

O caso mais inócuo é quando é usado no lugar de um DISTINCT. Tem gente que acha que o GROUP BY seria mais eficiente. Isto não é verdade. Qualquer que seja seu SGBD, ele será esperto o bastante para fazer o mesmo plano para as duas consultas. O GROUP BY apenas deixará seu código mais difícil de entender e manter, pois todas colunas do resultado precisarão ser repetidas no final.

Subselects

Neste caso, uma das colunas de retorno da query é uma outra query, isto é, um subselect. Ou pior, várias colunas são subselects parecidos, talvez retornando apenas um COUNT. Isto pode ser a coisa mais lerda do mundo.

Tem que pensar que cada subselect será executado para cada registro retornado. Se você retorna 100 registros, estará fazendo 101 consultas! A solução costuma ser mais complicada, normalmente usando condicionais e GROUP BY. Só que vale o preço. O tempo da consulta pode diminuir ordens de grandeza.

O fato de SQL ser uma linguagem declarativa às vezes disfarça processamentos custosos. Somente incluir um comando ali não parece que sua consulta está ficando duas ordens de grandeza mais lenta. Pode até ser que seu BD seja esperto o bastante para otimizar estas queries. Acredito até que isto já tenha salvo muitos sistema sem produção. Mas pra que confiar?

Outer joins

Esta fedentina aqui acontece mais em código procedural. O sujeito faz um loop nos resultados de um select. Para cada elemento retornado, processa alguma coisa e faz um outro select para checar se existe algo em outra tabela. Se existir faz um processamento a mais. Se você tiver 10 elementos, serão 11 selects. 11 idas à base para pegar dados.

Um Outer join resolveria isto com uma única consulta! Caso não existisse relação entre as tabelas, os elementos da tabela secundária viriam como NULL. Somente isto pode fazer a diferença entre um banco de dados stressado e um tranquilo.

Por outro lado, Outer joins são mais caros que os inner joins tradicionais. Já vi gente fazendo um left join "só pra garantir". Confira sempre se é mesmo necessário fazê-lo em vez de um inner join normal.

texto LIKE '%:nome%'

Se a string com o que o LIKE compara começa com %, significa que o texto pode casar em qualquer ponto. O SBGD ê terá não só que varrer não só toda sua tabela, como todo o texto do atributo analisado. É um algoritmo de complexidade quadrática! Sim, isto é lento praca.

Este é mais um caso em que na base de testes, que tem pouco dados, tudo ficará uma beleza. Alguns meses (ou anos) depois que o sistema entrar em produção, tudo emperrará.

A solução para este problema é usar um índice textual. Mas aí é assunto para outro post.

Ver estas e outras em códigos de produção me leva a divagar sobre dois grandes sucessos da informática, o MySql e os frameworks de mapeamento Objeto-Relacional.

Até outro dia o MySql não tinha subselects. Isto era chato, pois tornava necessário codificar coisas que uma única consulta mais sofisticada resolve. Só que por outro lado, ficava claro pra todo mundo que você estava fazendo loop dentro de loop. Nenhum problema ficava "escondido" no código. A falta de features mais avançadas, deixava claro tudo que estava sendo feito.

Os frameworks Objeto-Relacional por outro lado fazem tudo pra você. Eles não esquecem dos joins, nem inventam gambiarras pra retornar o que desejam. Alguns até criam todos os índices pra você, um outro problema que nem mencionei. No mundo da produção de código industrial, isto é um aumento de produtividade tremendo. Vai ser chato quando quiser fazer um relatório mais complicado, mas aí basta ter alguém que entenda como o mapeamento é feito e faça a consulta "na unha", com SQL de verdade.

As limitações destas tecnologias, acabam sendo uma grande vantagem. Elas resolvem a maior parte dos problemas. Sem elas, fica muito fácil dar um tiro pé. Putz! O tiro ainda foi no pé que tava todo sujo!

Código de ética do engenheiro de software

1. Público: Engenheiros de Software devem agir de forma consistente com o interesse público.
   
2. Cliente e empregador: Engenheiros de Software devem agir de modo que atenda aos melhores interesses de seus clientes e empregadores, sempre consistente com o interesse público
   
3. Produto: Engenheiros de Software devem garantir que seus produtos atendem ao mais alto padrão de qualidade profissional.
   
4. Julgamento: Engenheiros de Software devem manter integridade e independência em seus julgamentos profissionais.
   
5. Gerência: Engenheiros de Software que sejam gerentes e líderes devem subscrever e promover uma abordagem ética à gerência de desenvolvimento e manutenção de software.
   
6. Profissão: Engenheiros de Software devem avançar a integridade e reputação da profissão, sempre de forma consistente com o interesse público.
   
7. Colegas: Engenheiros de Software devem ser justos com seus colegas e sempre apoiá-los.
   
8. Sobre si próprio:Engenheiros de Software devem, durante toda sua vida, estar sempre aprendendo as práticas de sua profissão, e promoverem uma abordagem ética à profissão.
   

Sempre é bom de ler e saber que existe.

Em português o texto, que já era mal escrito em inglês, ficou ainda pior. Leia o documento original: Código de Ética do Engenheiro de Software, onde cada item é detalhado.

Por que "Não tem mosquito"?

He, he, achei uma explicação sucinta neste artigo, e não dá pra deixar de transcrever:

Essa expressão “não tem mosquito” é tão antiga quanto Oswaldo Cruz, o doutor Mata Mosquito, um sanitarista de primeira linha que se bateu para acabar com os mosquitos que infestavam o Rio de Janeiro, no início do século passado, quando a então capital do Brasil a anunciada aos quatro cantos do mundo como um lugar para se evitar por causa das doenças tropicais.

Um vexame, ou um enxame, não se sabe bem. O fato é que só quando a mosquitada foi colocada a nocaute é que a imagem da cidade começou a melhorar. Por isso, o malandro carioca quando queria dizer que tudo estava sob controle dizia “‘Dotô’, não tem mosquito!”

Acho que não é preciso explicitar a relação com os bugs nossos de dia a dia.

Dev in Rio 2009, eu fui!

Fui na primeira edição do Dev in Rio. O evento foi de primeira. Depois de descobrir que foi praticamente organizado só por dois caras, fiquei realmente impressionado.

As palestras foram de alto nível. No Dev in Rio pessoal sabia do que estava falando. Somente havia ido a um outro evento desta natureza, um da Locaweb, e achei um saco. Eram apresentações tecnicamente rasteiras, quase sempre fazendo propaganda de alguma coisa. Em troca de um lanchinho me amarraram frente a uma TV que só passava comerciais. Fiquei com a má impressão que no Brasil bom conteúdo só existe (às vezes) em eventos acadêmicos.

Vale a pena comentar as palestras. Depois da abertura, o primeiro a se apresentar foi o Ryan Ozimek. Ele ficou todo o tempo falando do Joomla, um CMS de código aberto. Foi quase nada técnico, falando mais da história e da evolução da comunidade. Não tenho a menor intenção de usar o software e cheguei a duvidar se o evento seria proveitoso. Achei a mais fraca palestra do dia.

A seguir o tema foi a Máquina Virtual Java (JVM) e como está sendo usada por outras linguagens. Uma dupla de apresentadores, Guilherme Silveira e Nico Steppat, deixou a palestra bem mais dinâmica e divertida, especialmente no início quando eles fizeram um diálogo bem platônico. Eles argumentaram que apesar de Java ter uma sintaxe verborrágica e ultrapassada, a JVM é tudo de bom. Rápida, segura, com um monte de bibliotecas, multi-plataforma, multithread etc. e tal. Terminaram dando um exemplo de um código Java chamar um código em ruby. Aí que achei que faltou completar. O exemplo que acho mais legal é exatamente o contrário. A linguagem dinâmica chamar Java e toda sua rica biblioteca. Encaixa bem no espírito da clássica Dicotomia de Ousterhout, em que uma linguagem mais flexível cuida da lógica principal de uma aplicação, funcionando como "cola" de uma camada inferior mais eficiente e rígida.

Depois do almoço, Fabio Akita fez a melhor apresentação do dia. Talvez por eu não conhecer muito de Ruby, foi onde mais aprendi. O vídeo com ele mostrando meta-programação em Ruby é excelente e provavelmente está lá no sítio dele. É o que uma informação técnica deve ser, repleta de informação. E o Google tá aí pra quem quiser se aprofundar nos assuntos mencionados.

Veio a palestra que eu mais aguardava, a do Jacob Kaplan-Moss, um dos criadores do Django. Gostei. Deu para conhecer mais a cultura e história deste framework web em que muito programarei ainda. Ele tem um jeito bem nerd e simpático dos rincões norte-americanos. Perdeu em ritmo e em conteúdo pro Akita, mas só esta palestra já valia a ida.

Fui dali para o dojo em Python. Apesar de já ter lido a respeito, nunca havia participado de um. Apresentaram o esquema do dojo e decidiram o problema. O importante é todo mundo aprender alguma coisa. O que foi aprendi foi que você não deve fazer sua primeira participação em um dojo sendo o primeiro a sentar no teclado:-) O primeiro teste é sempre idiota. Espere as coisas pegarem o ritmo para só então levantar a mão. Acabou meu tempo assim que comecei a esquentar. Depois achei o treco meio lento. Quando uma dupla fez seu terceiro teste que passou sem precisar de qualquer alteração no código, me deu uma angústia danada e saí correndo para a palestra.

Pena eu ter perdido mais da metade da apresentação do Jeff Patton. Ele é responsável por uma das minhas colunas preferidas da revista IEEE Software. Não pareceu ter grandes novidades, mas sempre é bom ter novos argumentos para design focado no usuário e desenvolvimento interativo.

Depois do bate-papo, todos foram convidados ao Lapa 40º para o #HoraExtra, isto é, o chopp. Mais uma bola dentro do evento, ter um chopp oficialmente divulgado. Mas amarelei:-( Estava cansado e ter ido sozinho me desanimou. Sinto falta de um convívio social para falar nerdices. Mas não tem problema, pelo visto não faltarão oportunidades nos próximos Dev in Rio.

CSS e semântica: dando (bons) nomes aos bois

No tempo da Internet a Vapor, ao se escrever cada elemento HTML era preciso especificar como ele seria formatado. A tag mais usada era a <font>. Quer colocar um título grande e vermelho? Fácil:

<font size=+2 color=red>Meu Título</font>

O design de seu sítio virtual se espalhava por de todas as páginas. Trocou de idéia? Quer agora que seu título seja verde? Beleza, agora terá que editar todas as páginas de seu sítio e fazer color=green. Não só vai dar um trabalhão, como você vai esquecer-se de mudar em alguns lugares. Seu design ficará inconsistente: umas páginas de um jeito, outras de outro.

O Cascading Style Sheets (Folhas de Estilo em Cascata) foi criado exatamente para resolver este problema. O CSS permite que o estilo de formatação de um elemento seja definido em uma página separada. Todas as páginas de um sítio passam a ter seus estilos definidos em um único lugar.

Se você quiser mudar o design, um único arquivo precisará ser modificado. As páginas ficam menores e carregam mais rápido, pois não é preciso enchê-las de informações para formatação. O estilo é carregado uma única vez e fica cacheado pelo browser.

Muita gente acha que o CSS existe para que se tenha novas opções de formatação. Não é esta a sua principal vantagem.

Com o CSS é possível dizer: todos meus elementos <H1> são formatados deste jeito, todos meus campos <INPUT> são daquele. E o grande poder do CSS vem com dois novos atributos para os elementos HTML, o class e o id. Uma classe ou id representa um conjunto de formatações. Todo elemento que tiver aquela classe ou id terá estas formatações.

As diferenças entre os dois é que todo elemento pode ter várias classes e apenas um id, e que não podem existir dois elementos com o mesmo id numa página.

Para se ter boas definições de estilo, uma das coisas mais importantes é dar bons nomes à suas classes. Pode até parecer bobagem, mas na prática, o nome que você der definirá que estilos sua classe representará.

Um exemplo de um estilo com nome ruim seria

textoGrandeVermelho {color: red; font-size: 3em;}

Fazendo isto, apesar de estar usando CSS, você estará programando como quando não existia. Caso resolva mudar o design de suas páginas para ter uma fonte verde, ou ficará com uma definição assim:

textoGrandeVermelho {color: green; font-size: 3em;}

ou terá que, como nos velhos tempos, editar todas as páginas de seu site. Não é raro preferirem a dissonância cognitiva.

Bons nomes são semânticos, isto é, devem definir alguma coisa. Você deve definir um nome que represente um objeto de seu design, ou uma qualidade dele. Eis um bom nome:

titulo {color: red; font-size: 3em;}

Assim você pode mudar os estilos de todos seus títulos sem precisar editar outras páginas, nem correr o risco de deixar seu sítio inconsistente. Ao ler o arquivo CSS, fica muito mais fácil identificar o que você precisa mudar se quiser que seu título apareça de maneira diferente. Se você quiser aproveitar suas páginas para outro cliente, bastará editar o arquivo CSS para ter um novo design.

Exemplos de bons nomes seriam: .titulo, .cabecalho, .rodape, .erro, .obrigatorio, .aviso, .filtro, .relatorio. Como cada elemento HTML pode ter mais uma classe, você pode combiná-las para ter definições como:

<H1 class="titulo erro">Título de página de erro</H1> 

<div class="aviso erro">Aviso de preenchimento de form> 

<input class="filtro obrigatorio" value="Filtro de preenchimento obrigatório" />

Nomes ruins seriam: .centralizado, .padding-esquerda, .width-td-full. E por que estes nomes são ruins? É porque se você quiser modificar seu site no futuro, será caro e trabalhoso. Se suas páginas tiverem títulos assim:

<H1 class="textoGrandeVermelho centralizado">Meu Titulo</H1>

E você não quiser mais que sejam centralizados, continuará tendo que editar todas as páginas. E será difícil achar no CSS quais são os estilos aplicados apenas a seus títulos. Eles provavelmente se aplicarão também a elementos que nada têm a ver.

Pensar um pouco para ter bons nomes para seus estilos CSS não é frescura. É apenas se preocupar com o futuro, com o tempo que você gastará com a manutenção de seu sítio. Não fazê-lo, é se prender ao passado. É programar como se ainda estivéssemos em 1995.