Vamos usar como exemplo um site que possuía um bom perfil de backlinks, conteúdo interessante, relacionamento bem aproveitado com os usuários (gerando compartilhamento das páginas do site nas redes sociais), além de vários outros pontos bem positivos.

Mas em um ponto falhava bastante: arquitetura. De maneira geral, o relacionamento entre os grupos de páginas era basicamente o seguinte:

Onde as setas azuis indicam o caminho dos links internos entre as páginas do site

Em uma primeira análise, você saberia identificar qual o problema dessa estrutura? Não? Então vamos seguir o caminho dos links:

• A home faz links para as categorias principais.
• As subcategorias fazem links para as páginas mais profundas.
• Todos os grupos fazem links para a home através da header do site.

Mas onde estão os links entre as páginas de categorias e subcategorias?

Se cortarmos dessa estrutura os links de header que apontam para a home do site, e considerarmos somente os links que se “aprofundam” na estrutura, temos a seguinte representação:

Ou seja, o site possuía dois grupos de páginas isolados. O primeiro, assinalado em verde na figura acima, era composto pela home e as categorias principais. O segundo, assinalado em amarelo, era composto de subcategorias e páginas profundos. Vale lembrar que as páginas profundas possuíam um tráfego muito baixo.

Antes de prosseguir, devemos lembrar que ao longo desse projeto foram efetuadas várias melhorias em conteúdo, usabilidade, semântica, etc, etc, etc, mas uma das melhorias de maior impacto foi justamente a correção da arquitetura do site.

Com o passar do tempo, a estrutura foi adaptada para o seguinte formato (mais uma vez, considerando apenas os links que “descem” na estrutura do site):

De maneira que deixaram de existir dois grupos de páginas isolados. Com o passar de um determinado tempo de projeto, foi obtido o seguinte comportamento de tráfego orgânico nas páginas profundas:

Vale lembrar que:

1. as porcentagens foram calculadas com relação ao primeiro ponto do gráfico
2. foram isolados os dados de tráfego orgânico das páginas que não receberam nenhum trabalho de link building antes e durante o período considerado.
3. foi tomado o cuidado de isolar um período em que não foram feitas alterações “pesadas” nas páginas profundas

Bom, mas o propósito ao exibir esses dados é lembrar que, embora a arquitetura e os elementos relacionados aos trabalhos onpage de um site sejam considerados os mais básicos, trabalhá-los de maneira correta pode melhorar – e muito – o tráfego orgânico no site como um todo.

Para tanto, existem muitas maneiras de organizar o nosso trabalho. Duas dicas:

1. Monte um “checklist de SEO” de maneira que, sempre que for necessário analisar um novo projeto você já possua um mãos um “guia” de itens que precisam de análise. E lembre-se: mantenha esse checklist sempre atualizado.
2. Mantenha-se sempre atualizado quanto as guidelines do Google e outras Search Engines.

Para manter os conhecimentos sempre atuais, algumas referências:

• Blog oficial do Google para Webmasters (bem como os vídeos do canal no Youtube)
• SEOmoz
• SEObook

Algumas fontes tupiniquins:

• MestreSEO
• Blog da Enlink
• BrasilSEO
• SEO de Saia
• LinkBuilding.com.br

Além do mais, atualmente o Brasil tem sido palco para vários eventos de SEO bastante interessantes, como o #olhoSEO, #uaiSEO e, em breve, o #searchmastersbr . Aliás, também siga esse pessoal no Twitter. =)

Gostou do artigo? Ficou alguma dúvida para trás? Gostaria de fazer alguma sugestão? Fique à vontade e faça seu comentário.

AllowOverride = All

Para tanto, você terá que editar o arquivo httpd.conf. Dessa vez será necessário trocar o conteúdo do atributo “AllowOverride”, de “None” para “All”. Se você se esqueceu de como editar esse arquivo, basta usar os dois comandos abaixo para abrir a tela de edição do arquivo:

cd /etc/apache2
sudo nano httpd.conf

No editor de texto, procure pela linha que contém “AllowOverride” e faça as alterações necessárias, assim:

Mas calma, o processo ainda não acabou. Você terá que fazer a mesma alteração no arquivo nomedeusuario.conf, contido na pasta /etc/apache2/users. No meu caso, usei os comandos:

cd /etc/apache2/users
sudo nano fabianelima.conf

No seu caso você deverá trocar o “fabianelima” pelo nome de seu usuário do MAC. Vale lembrar que esse arquivo é pequeno, e depois da configuração terá uma configuração semelhante ao da figura abaixo:

Depois disso, reinicie o Apache e ele estará pronto para aceitar os redirecionamentos feitos via arquivo .htaccess.

WordPress no Mac OS

Vale lembrar que esse é o primeiro passo sobre como rodar WordPress no Mac OS, abaixo, seguem os demais artigos da série:

1 – Ativando o Apache

2 – Ativando o PHP

3 – Instalando e configurando o MySql no Mac OS

4 – Configurando Virtual Hosts

Quando falamos que o Mac OS já vem preparado para rodar sites localmente, não é brincadeira. Somente para teste, digite no seu browser (mas é claro, antes disso ative o apache e lembre-se de habilitar o PHP):

http://localhost/~nomedeusuario/

Onde “nomedeusuario” deve ser trocado pelo seu nome de usuário do mac. Por exemplo, no meu caso, ficou:

http://localhost/~fabianelima/

Depois disso, você verá o site:

Sabe onde esse site está? No seu próprio MAC. Acessando a pasta “Sites” do seu usuário, você verá os arquivos do site mostrado acima:

Entretanto, para montar seu próprio site – da maneira como as coisas estão configuradas até o momento – você terá que configurar somente um site dentro da pasta Sites.

Em casa, tentei instalar o blog dentro de uma subpasta na pasta “Sites”, mas ao rodar o site localmente, as funções do WordPress não estavam funcionando – pois referenciavam arquivos que não estavam no local apontado.

Para resolver esse problema, foi necessário configurar virtual hosts. Mas como fazer isso?

1 – Arquivo Hosts

O arquivo hosts (localizado na pasta /etc) possui uma lista de hosts já configurados na sua máquina. Primeiramente, será necessário incluir um host para cada um dos sites trabalhados.

Para editar o arquivo, use os comandos:

cd /etc
sudo nano hosts

Uma vez dentro do arquivo, vá para o final do mesmo e acrescente os hosts necessários, da seguinte maneira:

Lembre-se que o nome utilizado acima corresponde a maneira como você vai acessar localmente o seu site. Por exemplo, escolhi acessar o meu blog através de “fabianemlima.local” e alterei o arquivo, da seguinte maneira:

2 – Arquivo httpd.conf

Depois disso, é necessário fazer com o que o Apache aceite virtual hosts. Para tanto, será necessário alterar o arquivo httpd.conf (localizado na pasta /private/etc/apache2). Dentro desse arquivo, encontre a linha que contém:

#Include /private/etc/apache2/extra/httpd-vhosts.conf

E descomente-a, da seguinte maneira:

Include /private/etc/apache2/extra/httpd-vhosts.conf

Para editar o arquivo, basta utilizar os seguinte comandos:

cd /private/etc/apache2/extra
sudo nano httpd.conf

3 – Arquivo httpd-vhosts.conf

Agora é hora de inserir o(s) novo(s) host(s) no arquivo httpd-vhosts.conf, afim de “contar” para o Apache quais virtual hosts serão utilizados. Para isso, utilize os seguintes comandos:

cd /private/etc/apache2/extra
sudo nano httpd-vhosts.conf

Nesse arquivo você vai encontrar a seguinte estrutura:

Nesse arquivo já estão configurados dois exemplos de Virtual Host. Vale lembrar que nem todos os atributos precisam ser configurados, no nosso caso, precisamos apenas do DocumentRoot, que contém o endereço do nosso site; e ServerName, que contém o atributo que vamos utilizar para chamar o site, o qual configuramos no arquivo hosts.

No meu caso, o arquivo ficou configurado da seguinte maneira:

Agora é necessário reiniciar o Apache. Para tanto, basta acessar o menu “Web Sharing”, desabilitar o compartilhamento e depois habilitar novamente (ver em mais detalhes no artigo: Ativando o Apache no Mac OS).

Depois disso a pasta está pronta para receber os arquivos do site e você poderá testar os resultados através do endereço que você configurou. Para verificar se funcionou tudo corretamente, você pode arrastar o conteúdo da pasta “Sites” para dentro da subpasta do seu site (dentro da pasta “Sites”). No meu caso, ficou assim:

Agora, ao tentar acessar

http://fabianemlima.local

do meu Browser, a página que aparece para mim é:

Como o teste deu certo, agora é hora de instalar e configurar o worpress na nova pasta. Não irei abordar como fazer a instalação nesse artigo, mas se ficar alguma dúvida, pode entrar em contato. =) … Ah, e não se esqueça de usar o banco de dados que você configurou anteriormente.

WordPress no Mac OS

Vale lembrar que esse é o quarto passo sobre como rodar WordPress no Mac OS, abaixo, seguem os demais artigos da série:

1 – Ativando o Apache

2 – Ativando o PHP

3 – Instalando e configurando o MySql no Mac OS

5 – Arquivo .htaccess no Mac OS

Para instalar, faça o download do MySQL no site. O arquivo em questão possui três pacotes – um deles corresponde a instalação do atalho para o MySQL nas preferências do sistema.

Vale lembrar que a instalação é simples, acontece da mesma maneira que qualquer aplicativo no MAC – a configuração é que pode precisar de um pouco mais de esforço, aliás, você pode instalar o phpMyAdmin para facilitar o gerenciamento do banco de dados.

1 – Alterando o Socket

Bom, infelizmente a configuração não pára por aí. Os usuários de MAC OS 10.4 (ou superior) precisam fazer algumas alterações, segundo o próprio site da Apple:

If you have downloaded and installed MySQL yourself but are using the pre-installed version of PHP, note that your custom version of MySQL might be configured to use the old MySQL socket location, /tmp/mysql.sock. The version of PHP in this software update uses the newer location /var/mysql/mysql.sock by default.

Ou seja, você provavelmente terá que alterar o arquivo php.ini para apontar para a localização correta do socket do MySQL.

Para tanto, verifique que existe o arquivo php.ini (dentro do diretório /etc). Caso não exista, basta fazer uma cópia do arquivo php.ini.default no mesmo diretório, renomar para php.ini, o que é possível através dos comandos:

cd /etc
sudo cp php.ini.default php.ini
sudo chmod 666 php.ini

Depois disso, basta alterar o endereço do Socket do MySQL. Para tanto, localize a linha do arquivo que contem “mysql.default_socket = /var/mysql/mysql.sock“. Para tanto, vamos utilizar o terminal novamente. Uma vez dentro do diretório /etc, abra o arquivo php.ini, através do seguinte comando:

sudo nano php.ini

Depois de digitar o comando acima, localize a linha que contém “mysql.default_socket = ” e edite com os valores passados anteriormente, da seguinte maneira:

Depois de alterar o arquivo, saia do editor de texto e salve as alterações efetuadas. Pronto, agora conexão com o MySQL é que não vai faltar.

2 – Facilite a sua vida: Aliases para o MySQL

Depois de instalado, para utilizar os comandos SQL sem o phpMyAdmin você terá que acessar o próprio MySQL através de seu endereço na máquina, o qual, é: /usr/local/mysql/bin/mysql. O mesmo processo acontecerá para o mysqladmin, cujo endereço é: /usr/local/mysql/bin/mysqladmin.

Para facilitar o processo, é interessante criar dois aliases, um para o mysql e outro para o mysqladmin. Da seguinte maneira:

alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin

Depois disso, para utilizar comandos SQL, basta digitar “mysql” no terminal e utilizar o mysql à vontade.

3 – Alterando as Senhas

Por padrão, o MySQL vem com o usuário root configurado com uma senha em branco. Se você quer alterá-la (o que é recomendado), o processo é feito através dos seguintes comandos no terminal:

mysqladmin -u root password "newpwd"
mysqladmin -u root -h host_name password "newpwd"

Onde “newpwd” corresponde a nova senha para o seu usuário root. Para mais informações e outros métodos, é interessante consultar o artigo sobre Default Preferences no próprio site do MySQL.

4 – Novas tabelas!

Para cada site em WordPress que vamos rodar localmente na máquina, será necessário montar uma nova base de dados para o mesmo no MySQL. Para montar uma tabela, basta utilizar os seguintes comandos:

mysql -u root -p
create database newdatabase1;
create database newdatabase2;
...
create database newdatabaseX;

Onde newdatabase1, …,  newdatabasex, devem ser substituídos pelos nomes dos bancos de dados em questão. Por comodidade, geralmente utilizo o nome do domínio blog/site em questão. Por exemplo, para este blog, usei como nome do banco de dados: fabianemlima.

Depois dos passos 3.1, 3.2, 3.3 e 3.4, o seu MySQL já está pronto para usar, inclusive as bases de dados que você vai precisar para seus sites.

5 – Dica Extra: Tela de Erro

Após a instalação do MySQL não é necessário reiniciar o seu mac entretanto, quando isso acontecer, pode ser que apareça o seguinte alerta:

“/Library/StartupItems/MySQLCOM”
has not been started because it does not have the proper security settings.

Para corrigir esse problema, basta utilizar os seguintes comandos no terminal:

sudo chown -R root:wheel /Library/StartupItems/MySQLCOM

E pronto, depois disso a tela de erro não será exibida novamente.

WordPress no Mac OS

Vale lembrar que esse é o terceiro passo sobre como rodar WordPress no Mac OS, abaixo, seguem os demais artigos da série:

1 – Ativando o Apache

2 – Ativando o PHP

4 – Configurando Virtual Hosts

5 – Arquivo .htaccess no Mac OS

A partir de agora será necessário alterar alguns arquivos de sistema, ou seja, você precisará utilizar o terminal – o qual está disponível em Applications > Utilities

Alterando o arquivo http.conf

Para ativar o PHP é necessário alterar o arquivo httpd.conf , localizado na pasta /etc/apache2/. Para tanto, basta utilizar os comandos:

cd /etc/apache2
sudo nano httpd.conf

Da seguinte maneira:

Depois de usar esses comandos, você vai precisar inserir a senha do usuário root da máquina. Vale lembrar que, com esses comandos, você primeiro entrou na pasta onde o arquivo httpd.conf, com o segundo comando, você está abrindo o arquivo em questão com o editor de texto do terminal (o nano).

Uma vez com o arquivo aberto no editor, agora vamos habilitar o php5. Para isso, basta procurar a linha que contém o “php5″, bastando, para isso digite a combinação de teclas “control” e “w”. Você deverá encontrar a linha que contém o seguinte trecho:

#LoadModule php5_module libexec/httpd/libphp5.so

Para habilitar o php 5, basta “descomentar” essa linha, ou seja, basta retirar o caracter “#”, resultando em:

LoadModule php5_module libexec/httpd/libphp5.so

Depois de descomentar essa linha de código, saia do editor e salve o arquivo. Para tanto, basta pressionar a combinação de teclas “control” e “x”, e depois “y”, assim:

E pronto, depois de salvar o arquivo o php 5 está corretamente ativado.

WordPress no Mac OS

Vale lembrar que esse é a segunda etapa sobre como rodar WordPress no Mac OS, abaixo, seguem os demais artigos da série:

1 – Ativando o Apache

3 – Instalando e configurando o MySql no Mac OS

4 – Configurando Virtual Hosts

5 – Arquivo .htaccess no Mac OS

1 – Entrar em System Preferences

2 – Entrar na opção Sharing

3 – Ativar o Web Sharing

E voilá, depois desses três passos o Apache está ativo, pronto para usar. =)

WordPress no Mac OS

Vale lembrar que esse é o primeiro passo sobre como rodar WordPress no Mac OS, abaixo, seguem os demais artigos da série:

2 – Ativando o PHP

3 – Instalando e configurando o MySql no Mac OS

4 – Configurando Virtual Hosts

5 – Arquivo .htaccess no Mac OS

1. instalar o WAMP,
2. criar um diretório para cada site dentro da pasta “www”,
3. instalar o wordpress nas pastas

E, voilá, você tem o que precisa para testar vários sites localmente, antes de colocá-los no ar. Pode ser que ocorra um problema ou outro quando se deseja testar recursos mais específicos, mas basta procurar um tutorial ou outro na Internet, acertar alguma configuração no WAMP, e o problema está resolvido.

Para o mac, existe uma solução bastante similar – o MAMP. Entretanto, suas opções de configuração mais avançadas estão disponíveis somente para a versão PRO, a qual não é gratuita. Esse fato complica um pouco a vida de quem não compra o MAMP. Por exemplo, há alguns dias atrás precisava testar alguns redirecionamentos via .htaccess localmente, antes de subir as alterações no ar – gastei um bom tempo reconfigurando alguns itens, e mesmo assim não consegui o resultado que esperava.

Porém…

Foi aí que descobri que o MAC OS tem apache e php nativos (obrigada, Estevão!), ou seja, ao invés de instalar o MAMP, que vem com apache, php e mysql, só é necessário instalar o mysql na sua máquina.

Porém… [2]

Não foi assim tão simples quanto eu imaginava. Mas o que realmente importa é que o resultado foi mais que satisfatório. Abaixo, segue um guia, passo a passo, de como configurar sites em WordPress no seu MAC OS, usando php e apache nativos. E, é claro, com direito ao uso do arquivo .htaccess.

Abaixo, segue o índice dos tópicos abordados nesse artigo, para facilitar a sua navegação:

1. Ativando o Apache
2. Ativando o PHP
3. Instalando e Configurando o MySQL
4. Configurando Virtual Hosts
5. Arquivo .htaccess no mac

Bom, agora é só usar e abusar do wordpress para testar seus blogs/sites localmente. Qualquer dúvida/sugestão/crítica a respeito desse artigo, entre em contato através dos comentários. =)

1. Como o GA faz o tracking de uma campanha?
2. Quando utilizar o URL Builder
3. Como usar o URL Builder

Como o GA faz o Tracking de uma Campanha?

O Google entende uma campanha de marketing online como uma combinação dos 5 elementos:

• Source: Fonte do link
• Medium: Esse item tem como finalidade especificar o tipo do Source (ads, publicidade, orgânico, etc).
• Term: Termo ou keyword que o usuário utiliza na Search Engine
• Content: Descreve a versão do anúncio no qual o usuário clicou. Esse item é utilizado quando se está fazendo testes A/B.
• Campaign: Diferencia as campanhas de marketing, ou seja, é a intenção da campanha em si.

Ou seja, ao utilizar o URL Builder você estará nada mais que utilizando os parâmetros acima para classificar suas campanhas de marketing.

Quando Usar o URL Builder?

O Google Analytics já “taggeia” automaticamente links vindos de sites de referência e AdWords (quando você habilita a opção “auto-tagging”), ou seja, nesses dois casos não é necessário utilizar o URL builder, mas em alguns casos pode ser interessante abrir excessões.

E-mail Marketing

Embora o GA já faça o tracking da origem dos links de e-mail marketing, existem casos onde o tracking dessa visita por e-mail marketing é perdido: o caso dos usuários que utilizam aplicativos desktop para gerência de e-mails. Essas visitas serão contadas como sendo diretas e não por referral.

Outra vantagem de utilizar o URL Builder em campanhas de e-mail marketing é segmentar o tráfego gerado por essas campanhas e ter uma exata noção de sua repercussão ao longo do tempo. Por exemplo, vamos supor que você faça quatro campanhas promocionais ao longo de mês, ou seja, uma campanha por semana.

Entretanto, os usuários não vão acessar os links da primeira campanha promocional apenas na primeira semana do mês, os links da segunda campanha na segunda semana, e assim por diante… A maioria dos acessos até pode ocorrer dessa maneira, mas uma boa parte não seguirá esse padrão. Fazendo o tagging correto das campanhas é possível analisar melhor o comportamento desses usuários.

Twitter

O mesmo problema com URLs que perdem o tracking do referral acontece no Twitter, pois grande parte dos usuários utilizam aplicativos para gerenciar suas contas de Twitter. Ao fazer tags de maneira correta nos links enviados no Twitter, você poderá uma noção melhor de qual o seu tráfego real advindo dessas campanhas.

Como Utilizar o URL Builder?

Como Preencher os Campos do URL Builder?

Primeiramente é necessário acessar o formulário do URL Builder, o qual tem o seguinte formato:

Onde “Website URL” é o campo onde você deve inserir a URL que você vai divulgar na campanha. Ao clicar no botão “generate URL”, o campo “URL final” vai receber todos os atributos setados nos demais campos. Vale lembrar que é possível gerar as URLs “taggeadas” sem o URL Builder, bastanto apenas acrescenter os parâmetros e seus respectivos conteúdos corretamente na URL original.

Por exemplo, supondo que quero verificar os impactos da divulgação deste artigo no Twitter, vou preencher os campos da seguinte maneira:

• URL original: http://www.fabianemlima.com/google/url-builder-dicas-uso
• Source: twitter
• Medium: fabianemlima
• Name: divulgacao-2010-10-29

Note que preenchi somente os valores setados como obrigatórios. A URL final, nesse caso, será:

http://www.fabianemlima.com/google/url-builder-dicas-uso?utm_source=twitter&utm_medium=fabianemlima&utm_campaign=divulgacao-2010-10-29

Aliás, vale lembrar:

1 – Que é interessante sempre utilizar nomes diferentes para as campanhas e adotar um padrão para esses nomes. Dessa maneira você consegue identificar corretamente as campanhas em seu respectivo relatório no Google Analytics (caminho: Traffic Sources -> Campaigns).

2 – Podem ser utilizados em uma mesma campanha vários tipos de Sources (e mediuns). Nesse caso, o nome da campanha não muda, mas os demais valores sim.

3 –  Não interfira no tracking que outras pessoas fazem. Se você encontrou um artigo interessante em algum site na Internet e resolveu enviar no Twitter,  não precisa utilizar o URL Builder. =P

Dica Extra: Cuidado com o Conteúdo Duplicado

Um problema acarretado pelo uso das URLs “taggeadas” é que esse conteúdo é duplicado. Para cada URL original é gerada uma URL com tags, o que pode ser prejudicial para o site.

Para evitar esse problema é necessário utilizar a canonical tag nas páginas divulgadas, configuradas de maneira que apontem sempre para suas respectivas versões originais de URL.

Conclusão

O uso desse recurso é essencial para analisar corretamente os dados de campanhas de Twitter e E-mail marketing, uma vez que conseguimos um número mais preciso referente aos usuários que acessam o site através dessas campanhas. E você, utiliza o URL Builder com freqüência? Encontrou outra aplicação para esse recurso? Tem alguma dúvida sobre como configurar? Deixe seu comentário e conte sua opinião.

Ganhei do dia das criancas o direito de testar o #googleInstant. estou brincando com ele agora! #diadascrianças (via @lucasaugustomcc)

Teaching myself into NOT pressing enter while searching on google. #googleinstant (via @Vernalkick)

so, i don’t feel any differences from #GoogleInstant than the ordinary search methods (via @bayubagja)

We think #GoogleInstant is like a new parent who gives a child the answer before the child knows the question. #search #webdev #psychology (via @bestwebstrategy)

#GoogleInstant, so far, has really not changed search results & behavior too much. @randfish #IMS10 (via @pullnotpush)

@RoshSillars The longtail has definitely changed in the last in the last 6 months with the #mayday update and #googleinstant (via @Rmercader)

Oké, #GoogleInstant is een mooi staaltje techniek, maar toch zie ik er geen meerwaarde in… (via @jeffmaes) -> Alguém entendeu essa? =P

E olha que essas são algumas das opiniões coletadas na última semana.

Como é possíve perceber, há quem odeie, quem ama, quem não entende e quem simplesmente não usa o Google Instant. Mas e aí, qual é a onda dessa alteração?

Mas, afinal, o que é o Google Instant?

O Google Instant é uma das mais recentes alterações na interface de buscas do Google, onde os resultados vão aparecendo conforme o usuário vai digitando sua querie de pesquisa. Como no exemplo abaixo:

Essa nova alteração do Google apresentou 3 principais pontos de mudança:

1. Resultados mais rápidos: são salvos cerca de 2 segundos por pesquisa realizada.
2. Resultados mais espertos: com base nos dados de pesquisas já realizadas ao longo do tempo, o Google realiza uma “predição” do que você está digitando, exibindo os resultados para os termos que você já digitou.
3. Resultados instantâneos: como os resultados vão sendo construídos enquanto o usuário digita sua querie, ao terminar o resultado encontrado já é o resultado final – ou seja, o usuário não precisa acionar a pesquisa para que depois o resultado seja exibido.

Para utilizá-lo é necessário habilitá-lo através da opção “Google Instant is on” na página de pesquisa do Google.com, logo ao lado da caixa de pesquisa. Vale lembrar que a opão de utilizar o Google Instant ainda não está disponível para o Google Brasil. Mas, se você tiver oportunidade… Compensa experimentar.

UaiSEO – Quais Serão os Impactos do Google Instant?

Muito se discutiu a respeito do Google Instant em fóruns, blogs, Twitter e eventos. Inclusive, o Google Instant foi o primeiro assunto abordado na mesma redonda do UaiSEO 2.0.

Abaixo seguem algumas informações passadas na mesa redonda pelos palestrantes do Evento, de maneira a organizar uma idéia geral sobre o Instant:

“O Google instant não implicou em diferenças no Search, até o momento nenhuma alteração no comportamento dos usuários” (@fabioricotta)

“No começo as pessoas não utilizavam mais que uma palavra nas pesquisas e elas navegavam até o final dos resultados para encontrar os resultados. Hoje em dia as pessoas utilizam mais termos na pesquisa e praticamente ninguém chega até a terceira página de pesquisa. A maioria das pessoas está sofrendo por antecipação. Uma mudança comportamental demora anos ou meses para acontecer, pelo lado do SEO, nós teremos que apresentar resultados na primeira página. O primeiro, segundo e terceiro link na busca orgânica passarão a ser essenciais. Os primeiros termos sugeridos pelo Google terão grande importância, pois o usuário seleciona um desses resultados para realizar a busca. Será necessário esperar o Google Instant vir para o Brasil para verificar possíveis alterações no comportamento de busca dos usuários.” (@flavioraimundo)

“Pensar que otimização é mais que otimizar para uma palavra chave, contexto passou a ter mais relevância. O Google Instant ainda não surtiu efeito no comportamento dos usuários – os usuários continuam utilizando a busca mais rápida.” (@cassy82)

“Verificar as sugestões dadas pelo Google Suggest e Google Instant e otimizar para elas.” (@msanches)

“O Google Instant vai servir de mais uma ferramenta de busca de palavras-chave.” (@msanches)

• melhorar a visibilidade da marca na web e no mercado,
• supervisionar o que consumidores (e possíveis consumidores) falam a respeito de sua marca,
• melhorar o branding e o relacionamento com os clientes,
• fidelizar usuários
• entre outras finalidades

Mas vale ressaltar que as redes sociais, assim como os agregadores de conteúdo, também podem ser utilizadas para melhorar o ganho de links para sites e blogs, ou seja, constituem uma maneira bem interessante de trabalhar o link building de seu site e, consequentemente, o SEO do mesmo.

Entretanto, além da enorme quantidade de agregadores de conteúdo e redes sociais já existentes, a cada dia são lançados novos agregadores e redes – o que torna inviável o uso de todos esses recursos.

Nesse cenário a saída é escolher quais recursos serão utilizados.

Mas como escolher quais mídias sociais e agregadores de conteúdo utilizar para melhorar o link building do meu site? Abaixo, seguem algumas dicas.

Nicho de mercado

O ideal é utilizar agregadores e redes sociais cujos usuários correspondem ao público-alvo de seu site. Afinal, melhor que apenas enviar tráfego para o seu site, é levar tráfego de pessoas que podem:

• ter o interesse de comprar os seus produtos,
• se identificar com a sua marca,
• se interessar pelos assuntos tratados em seu site.

Além do mais, links de sites com assuntos relacionados têm maior valor que links não relacionados.

Para identificar o público do site é necessário verificar os tipos de conteúdos postados e sua aceitação pela comunidade. Se a comunidade possui uma seção com os “top conteúdos”, essa é uma ótima maneira de facilitar a análise.

Por exemplo, supondo que tenho um blog sobre sapatos e preciso verificar se o linkninja.com.br tem um público compatível com o meu público-alvo. Para tanto, vou acesar o linkninja e verificar o conteúdo que é postado lá.

Das 7 primeiras notícias postadas na home do site, encontrei:

Onde grifei de cores diferentes os tipos de conteúdo que encontrei:

Amarelo – Notícias em outras línguas. Esse tipo de conteúdo é relativamente comum em redes sociais, e na maioria das vezes são resultado de submissões automáticas feitas por softwares de divulgação de conteúdo.

Vermelho – Conteúdo spam.

Verde – Conteúdo em português e não spam.

Ou seja, a julgar pelo conteúdo postado na página inicial, o site pode não ser uma boa opção de agregador de conteúdo para o meu blog de sapatos: duas das três notícias postadas na categoria moda, são spam.

Mas não vamos parar por aí.

Essa primeira verificação foi feita pouco antes das 7:00 da manhã. Ao analisar a home do site no mesmo dia, aproximadamente às 22:00 hs, o quadro encontrado foi bastante diferente:

Ou seja, observando o segundo quadro verificamos que não é necessário descartar esse agregador como fonte de links. Vale ressaltar que a filtragem de spam é um problema encontrado por diversas redes sociais e agregadores, problema que na grande maioria dos casos não é resolvido de maneira absoluta.

Popularidade

Outro ponto a ser considerado é a popularidade do site – quanto maior seu público, melhor: mais pessoas vão ter acesso a sua marca.

Para verificar o tamanho do público do site que você pretende utilizar, uma boa alteranativa é utilizar a  ferramenta Google Trends for Websites.  Da seguinte maneira:

No campo “sites”, insira os sites que pretende comparar separados por vírgulas. Uma dica: mesmo que sua intenção seja apenas verificar a popularidade de um determinado site, utilize um site que você conheça (de preferência do mesmo nicho de mercado) e que possua alguma relevância no mercado que você procura.

No menu “opções” é possível segmentar as comparações por região de atuação e período de tempo. Sempre escolha como região o país foco de seu site.

Já em “informações” é possível obter alguns dados interessantes sobre a comparação realizada: em que regiões aquele site é mais procurado, que sites as pessoas também costumam visitar além do verificado e os sites que as pessoas também buscam quando procura pelo site analisado.

Voltando ao exemplo anterior, vamos supor que desejamos analisar a popularidade do linkninja.com.br, que é um agregador brasileiro de conteúdo relativamente novo. Para verificar sua popularidade, vou compará-lo com o dihitt.com.br e o linkk.com.br – também são agregadores brasileiros de conteúdo.

Quanto ao dihitt, sei que tem um grande público e que pode trazer um bom tráfego para o meu site, já o linkk não traz um volume tão grande de visitas.

Na figura abaixo, seguem as comparações:

Como é possível perceber, ao longo do tempo a tendência do linkninja é ultrapassar a popularidade do linkk (pelo menos até janeiro de 2010 – a partir de então não temos dados suficientes do linkninja).

Follow ou Nofollow?

Geralmente quando se fala de link building, fala-se em ganhar links sem o atributo rel=”nofollow”. Mas imagine o seguinte cenário:

Uma rede social ou agregador tem uma popularidade considerável e um público interessante para o seu site, mas utiliza o atributo rel=”nofollow” em seus links externos. Você ainda vai usar essa rede ou agregador para divulgar seu conteúdo?

Antes de decidir por não utilizar uma determinada rede social por causa do uso de “nofollow” o ideal é fazer testes na mesma: divulgue notícias, estabeleça alguns contatos, verifique como é o comportamento dos usuários da rede no seu site, qual a dificuldade de conseguir destaques em suas notícias… Use a rede: Muitas vezes um link que não passa juice é uma fonte melhor de tráfego do que um link follow.

Conclusão

Escolher as redes sociais e agregadores que serão utilizados na divulgação de conteúdo do site dependem de identificação do público-alvo,  análise de popularidade e testes – sendo que os últimos é que realmente vão determinar se a rede social ou agregador realmente vai trazer bons resultados, tanto para o SEO do site quanto para a reputação da marca.

E você, costuma realizar essas análises antes de escolher um agregador ou uma rede social? Costuma utilizar esses recursos para divulgar seu conteúdo? Tem alguma dúvida sobre esse assunto? Deixe um comentário.