Existem diversos motivos. O primeiro deles é o fato do ser humano perceber facilmente que há um predador à sua espreita. Somos a espécie animal mais adaptada à sobrevivência, e faz parte de nossa natureza enxergar uma ameaça. O Google já mostrou que veio para dominar a WWW, e isso não agrada a quem vive da WWW.

Segundo, que o Google busca mais e mais manter o visitante em suas páginas, ao invés de enviá-lo ao local onde obteve a informação.

Em um documento recente que vazou na WWW, o “Guia de Qualidade Google” que os seus revisores humanos utilizam para classificar os sites, o sistema de buscas cita explicitamente “sites de hotéis” como sendo alvo de punições. Se o site ganhar dinheiro com hotéis de qualquer maneira, será punido, independente se for útil ou não para o usuário. Não sou eu que faço essa afirmação, está escrito exatamente dessa forma no documento interno do Google:

Note: Major cosmopolitan cities are preferred targets for spammers, especially hotel affiliates. Such results should be flagged as Spam, even if they are related to the query and helpful to users. For example, a hotel affiliate page with a list of Chicago hotels may be assigned a rating Relevant, but also receive a Spam flag.

Traduzindo o trecho grifado: Resultados desse tipo devem ser marcados como spam, mesmo que sejam relacionados à busca e úteis aos usuários. (Não surpreende em nada que o Google tenha acabado de lançar seu sistema de busca de hotéis, não acham?)

Vamos analisar um resultado de buscas por hotéis(clique para aumentar). Para este exemplo, busquei por hotéis em Brasilia.

Minha resolução de tela atual é de 1680×1050. Em meu monitor, vejo mais de 50% da tela de anúncios. A parte beige acima dos resultados são anúncios pagos Adwords, e a coluna ao lado direito, em verde, idem. O sombreamento verde e vinho foram feitos por mim, o beige é original do Google.

Sobra, para o webmaster que criou o conteúdo que responde à pergunta do navegante, apenas metade do espaço. Frisando que a resposta não é fornecida pelo Google, e sim pelo webmaster que criou o conteúdo.

Nos outros 50% o Google preferiu listar 5 hotéis, escolhidos a seu critério. Brasilia tem centenas de hotéis, o Google listou 5. Se você rolar a tela para baixo, verá finalmente os sites que deram o conteúdo da resposta ao Google. Sem eles, o Google seria apenas anúncios… Esses sites estão “invisíveis” na minha resolução de tela, conforme o leitor pode ver capturada acima.

Este é apenas um exemplo dos motivos pelos quais o Google se tornou competidor dos webmasters, ao invés de um parceiro como antigamente. Muitos webmasters já haviam enxergado esse perigo, e ele finalmente se concretizou: hoje qualquer página que ganhe dinheiro na WWW está em competição direta com o Google. Uma competição injusta e completamente desproporcional, pois eles tem o poder de desaparecer com este blog, por exemplo, sem prestar qualquer esclarecimento sobre sua decisão.

A especialista em SEO, Miranda Miller, publicou um interessante artigo sobre a cartilha seguida pelo departamento de controle de qualidade do Google.

Basicamente, o funcionário segue uma cartilha para julgar a qualidade do site. Os quesitos são bem “elaborados”, não se trata apenas de julgar o visual e as primeiras impressões, mas a experiência de navegação como um todo.

Ao fim dos anos 1990 a força dos sistemas de buscas veio da automatização do processo de descoberta e seleção de conteúdo. Ao fim da primeira década de 2000, ao que tudo indica, estamos vendo um retorno à humanização da busca.

São, afinal de contas, pessoas como eu e você que vão decidir diversos quesitos de posicionamento de sites nos resultados.

Infelizmente, o documento original contendo as diretrizes para avaliação manual foi removido pelo Google, e sua reprodução é proibida. Porém, Miranda Miller fez um ótimo trabalho ao salvar trechos e comentá-los. O artigo está em Inglês, mas se você estiver envolvido com a WWW vale um estudo.

Desde que foi lançado, tenho observado o número de “Plus” recebidos pelo painel do Webmaster Tools.

Lembro-me de ter ficado impressionado com a quantidade de webmasters que votavam no sistema a cada dia. De 30k saltou para 42k, para 68k e assim por diante: uma avalanche de votos. Eis que há alguns dias o número não passa de 120 mil. Estaremos nos aproximando do número total de usuários do WT? Ou é apenas uma pequena pausa?

Há alguns dias venho recebendo erros 500 Internal Server Error do principal servidor Apache hospedado em instância EC2 do Amazon Web Services.

Não se tratava de um “bug da manhã” do MySQL porque haviam conexões suficientes ao servidor de banco de dados para manter o handle DBH válido.

O erro aparentava ser aleatório, não era relacionado a uma página específica, ou uma query mais longa. Às vezes ocorria logo que o servidor era reiniciado, às vezes tardava em ocorrer. Um tipo problema realmente difícil de diagnosticar porque é um “alvo móvel”, nem sempre acontece, e quando acontece não há uma causa clara.

Algumas das mensagens encontradas no log de erros do Apache incluiam:

DBI Connection failed
ou
Can't connect to MySQL server on [...]
ou
DBI Connection failed: Lost connection to MySQL server at 'reading authorization packet', system error: 0 at [...]


Após algumas horas de testes, cheguei a relatórios de “bugs” do MySQL, a maioria dos quais eram apenas pedidos de suporte técnico onde o MySQL levava a culpa, e o pedido era “mascarado” de um bug no sistema.

O problema era a latência de rede do EC2 da Amazon. Já havia ouvido falar no assunto, porém não tinha tido problemas no passado. Aparentemente os mega-servidores XEN podem ter seus altos e baixos também, e a “conversa de rede” entre milhões de instâncias virtuais pode ficar um pouco lenta.

Aumentando o timeout de rede do servidor MySQL para conexão e leitura solutionou o problema.

Editando a seção [mysqld] do /etc/my.cnf, inserí:

connect_timeout=30
net_read_timeout=45


E pronto.

Nota: O problema em exagerar o timeout, como exagerei acima elevando o tempo máximo para conexão a 30 segundos, é que em caso de falha pode-se criar uma imensa fila(“backlog”) de conexões aguardando decorrer o timeout para serem canceladas. No caso de uma rede local de velocidade aceitável, jamais precisei modificar o valor padrão de 5 segundos. Porém, em uma rede virtualizada como aquela do Amazon EC2 a latência de rede pode se tornar um problema. Deve haver um equilibrio entre um timeout seguro para não haver erros e que, porém, não cause enormes filas para conexão. Posteriormente reduzí o timeout a 8 segundos e ficou tudo ok. Três segundos à mais eram a margem de erro que precisava para a latência da rede Amazon.

As dicas de SEO em inglês podem todas serem aplicadas à lingua Portuguesa. Só que, devemos nos atentar para algumas peculiaridades que nossa lingua traz à arte de otimizar sites para sistemas de busca.

Um detalhe a ser observado é a acentuação. Para tanto, vamos usar um exemplo prático. Veja a diferença entre as buscas abaixo.

Compare com esta:

Observe que:

• Há 300 mil páginas a mais na versão acentuada.
• Os resultados são completamente diferentes.
• Não acentuei a palavra Kaka e o Google reconheceu que era o Jogador

O que isso significa? O leitor poderá observar mais fatos interessantes sobre a diferença nos resultados de acordo com a acentuação, porém, tenho em mente algumas conclusões.

1. É possível deixar de acentuar algumas palavras menos conhecidas para competir com menos sites.
2. O Google possui um Tesauro com sinônimos de palavras mais conhecidas, como Kaka.
3. A busca é binária, ou seja, maca e maçã são inteiramente diferentes.

E você, enxergou mais alguma dica para compartilhar sobre acentuação nos resultados de busca?