Posted:

Hoje, em nossa campanha #NoHacked, falaremos sobre engenharia social. Acompanhe as discussões no Twitter e no Google+ usando a hashtag #NoHacked. (Parte 1)

Se você passa algum tempo na web, provavelmente já encontrou algum tipo de engenharia social. A engenharia social tenta extrair informações confidenciais manipulando ou enganando você de alguma forma.

Phishing

Talvez você saiba o que é o phishing, uma das formas mais comuns de engenharia social. Sites e e-mails de phishing imitam sites legítimos e induzem você a inserir neles informações confidenciais como seu nome de usuário e sua senha. Um estudo recente do Google (em inglês) descobriu que alguns sites de phishing conseguem enganar as vítimas 45% das vezes. Uma vez que um site de phishing obtém suas informações, elas serão vendidas ou usadas para manipular suas contas.

Outras formas de engenharia social

Como proprietário de um site, o phishing não é a única forma de engenharia social com a qual você precisa tomar cuidado. Outra forma de engenharia social vem do software e das ferramentas usadas no seu site. Caso você faça o download ou use algum Sistema de gerenciamento de conteúdo (CMS, na sigla em inglês), plug-ins ou add-ons, verifique se eles vêm de fontes confiáveis, como diretamente do site do desenvolvedor. Softwares de sites não confiáveis podem ter códigos maliciosos que permitem aos hackers acessar seu site.

Por exemplo, a webmaster Wanda foi contratada recentemente pelo ‘Brandon’s Pet Palace’ para ajudar a criar um site. Após esboçar alguns projetos, Wanda começou a compilar o software de que ela precisava para criar o site. No entanto, ela viu que o ‘Photo Frame Beautifier’, um de seus plug-ins favoritos, foi retirado do site oficial de plug-ins do CMS e que o desenvolvedor decidiu parar de oferecer suporte ao plug-in. Ela fez uma busca rápida e descobriu um site que oferecia um arquivo de plug-ins antigos. Ela fez o download do plug-in e o usou para terminar o site. Dois meses depois, uma notificação no Search Console informou Wanda que o site do cliente dela foi invadido. Ela rapidamente buscou corrigir o conteúdo invadido e encontrou a fonte do problema. O plug-in ‘Photo Frame Beautifier’ foi modificado por terceiros para permitir que partes maliciosas acessassem o site. Ela então removeu o plug-in, corrigiu o conteúdo invadido, protegeu o site de ataques futuros e enviou um pedido de reconsideração no Search Console. Como pode ser visto, um descuido da Wanda fez com que o site do cliente dela fosse comprometido.

Proteja-se de ataques da engenharia social

A engenharia social é efetiva porque não é claro que exista algo errado com o que você está fazendo. No entanto, há algumas coisas básicas que podem ser feitas para se proteger da engenharia social.
  • Fique atento: sempre que você inserir informações confidenciais online ou instalar software de websites, tenha uma boa dose de ceticismo. Confira os URLs para ter certeza de que você não está digitando informações confidenciais em sites maliciosos. Ao instalar um software a partir de um website, verifique se o software vem de fontes conhecidas e respeitáveis, como o site do desenvolvedor.
  • Use a autenticação de dois fatores: a autenticação de dois fatores, como a Verificação em duas etapas do Google, adiciona outra camada de segurança que ajuda a proteger sua conta mesmo que sua senha seja roubada. Use a autenticação de dois fatores em todas as contas quando possível. Falaremos mais detalhadamente sobre os benefícios da autenticação de dois fatores na próxima semana.
Recursos adicionais sobre engenharia social:

Poste suas dúvidas no Fórum de Ajuda para webmasters, onde uma comunidade de webmasters poderá ajudar a respondê-las. Participe também do nosso Hangout sobre segurança no dia 26 de Agosto.

Posted:
Se você publicar algo online, uma de suas principais prioridades deverá ser a segurança. Ser invadido por um hacker poderá ter um efeito negativo na sua reputação online e resultar em perda de dados importantes e privados. Durante o ano passado, o Google observou um aumento de 180% no número de sites invadidos por hackers. Enquanto trabalhamos duro para combater essa onda de hackers, há etapas que você pode seguir para proteger seu conteúdo na web.
A partir de hoje, daremos continuidade à campanha #NoHacked. Durante as próximas semanas, nos focaremos na proteção do seu site contra hackers e mostraremos como algumas dessas campanhas contra hackers funcionam. Acompanhe a campanha #NoHacked no Twitter e no Google+. Além disso, finalizaremos a campanha com um Hangout sobre segurança, em que será possível fazer perguntas aos nossos especialistas.

Começaremos a campanha com algumas dicas básicas sobre como manter seu site seguro na web.

Fortaleça a segurança da sua conta

Criar uma senha que seja difícil de adivinhar ou decifrar é essencial para proteger seu site. Por exemplo, sua senha pode conter uma mistura de letras, números, símbolos ou ser uma senha longa. O tamanho da senha é importante. Quanto mais longa for sua senha, mais difícil será adivinhá-la. Há muitos recursos na web que podem testar a força da sua senha. Testar uma senha parecida com a que você tem (nunca insira sua senha real em outros sites) pode dar uma ideia do quão forte ela é.

Além disso, é importante evitar a reutilização de senhas em diferentes serviços. Os invasores costumam tentar combinações de nome de usuário e senha conhecidos, originados de listas vazadas de senhas ou serviços invadidos, para comprometer o maior número de contas possível.

Também é importante ativar a autenticação de dois fatores para contas que ofereçam esse serviço. Isso pode aumentar consideravelmente a segurança da sua conta e proteger você de uma variedade de ataques. Falaremos mais sobre os benefícios da autenticação de dois fatores em duas semanas.

Mantenha o software do seu site atualizado

Uma das formas mais comuns de um hacker comprometer seu site é por meio de software não seguro no seu site. Verifique seu site periodicamente em busca de softwares desatualizados, em especial as atualizações que corrigem falhas de segurança. Se você usar um servidor web como o Apache, o nginx ou um software comercial para servidor web, certifique-se de que o software do seu servidor web está atualizado. Se você usar um CMS (sistema de gerenciamento de conteúdo) ou quaisquer plug-ins ou add-ons em seu site, mantenha essas ferramentas atualizadas com as novas versões. Além disso, inscreva-se em listas de anúncios de segurança para o software de seu servidor web e seu CMS, se você usar um. Considere remover totalmente de seu website os add-ons ou os softwares de que você não precisa. Além de criar possíveis riscos, eles também podem desacelerar o desempenho do seu site.

Pesquise como seu provedor de hospedagem lida com as questões de segurança

A política do seu provedor de hospedagem para segurança e limpeza de sites invadidos é um fator importante a considerar quando você escolher um provedor de hospedagem. Caso você esteja usando um provedor de hospedagem, contate-o para saber se ele oferece suporte sob demanda para limpar problemas específicos do site. Também é possível verificar comentários online para saber se ele tem histórico de ajudar os usuários com sites comprometidos a limpar o conteúdo invadido.

Se você controlar seu próprio servidor ou usar serviços de servidor privado virtual (VPS, na sigla em inglês), prepare-se para lidar com as questões de segurança que poderão surgir. A administração de servidores é muito complexa, e uma das tarefas principais de um administrador de servidor é manter seu servidor web e software de gerenciamento de conteúdo corrigidos e atualizados. Caso você não tenha uma boa razão para fazer a administração de seu próprio servidor, considere que poderá ser mais proveitoso verificar se o provedor de hospedagem oferece uma opção de serviços gerenciados.

Use as ferramentas do Google para se manter informado sobre conteúdos possivelmente invadidos no seu site

É importante ter ferramentas que possam ajudar você a monitorar seu site de maneira proativa. Quanto antes você encontrar um problema, mais rápido poderá corrigi-lo.

Recomendamos que você se inscreva no Search Console caso ainda não o tenha feito. O Search Console é a forma que o Google tem para se comunicar consigo sobre problemas no seu site, incluindo se detectamos conteúdo invadido. Além disso, é possível configurar os Alertas do Google para que o notifiquem no caso de resultados suspeitos para seu site. Por exemplo, caso você possua um site de venda de acessórios para animais de estimação chamado www.exemplo.com, será possível configurar um alerta para [site:exemplo.com software barato] que irá notificá-lo caso algum conteúdo sobre software malicioso comece a aparecer de repente no seu site. É possível configurar múltiplos alarmes para seu site para diferentes termos com spam. Se você não tiver certeza sobre quais termos com spam usar, use o Google para pesquisar por termos comuns com spam.

Esperamos que essas dicas mantenham você seguro na web. Siga nossas campanhas sociais e compartilhe dicas e truques sobre como se manter seguro na web com a hashtag #NoHacked.

Poste suas dúvidas no Fórum de Ajuda para webmasters, onde uma comunidade de webmasters poderá ajudar a respondê-las. Participe também do nosso Hangout sobre segurança no dia 26 de Agosto.

Postado por Eric Kuan, especialista em relações de webmasters, e Yuan Niu, analista de spam da web

Posted:
A Pesquisa Google fornece um serviço de preenchimento automático que tenta prever uma consulta antes que o usuário termine de digitar. Durante anos, vários desenvolvedores integraram os resultados do preenchimento automático em seus próprios serviços usando uma API não oficial e não publicada que não tinha restrições. Aqueles que descobriram a API do Preenchimento Automático (Autocomplete) puderam incorporar os serviços de preenchimento automático, independente da Pesquisa Google.

Em vários momentos, a engenharia reversa da comunidade de desenvolvedores de um serviço do Google gerou grandes resultados por meio de uma API não publicada. A API do Google Maps, por exemplo, tornou-se uma API com suporte formal alguns meses após vermos o que os engenheiros criativos podiam fazer ao combinar dados de mapas com outras origens de dados. No momento, oferecemos suporte para mais de 80 APIs que os desenvolvedores podem usar para integrar serviços e dados do Google em seus aplicativos.

No entanto, algumas vezes, usar uma API sem suporte e não publicada traz o risco de que ela se torne indisponível. Esta é uma dessas situações.

Criamos o preenchimento automático como um complemento à Pesquisa Google, e não tínhamos a intenção de que ele existisse desconectado do propósito de antecipar as consultas de pesquisa do usuário. Com o tempo, percebemos que, mesmo sendo possível criar usos para um feed de dados do preenchimento automático fora dos resultados da pesquisa que podem ser relevantes, geralmente, o conteúdo do nosso preenchimento automático é otimizado e destinado ao uso em conjunto com os resultados da pesquisa. Fora do contexto de uma pesquisa na web, eles não fornecem um benefício significativo ao usuário.

A fim de manter a integridade do preenchimento automático como parte da Pesquisa Google, iremos restringir o acesso não autorizado à API do Preenchimento Automático não publicada a partir do dia 10 de agosto de 2015. Queremos garantir que a experiência dos usuários com o preenchimento automático seja como projetado: um serviço associado à Pesquisa Google. Acreditamos que isso proporciona uma melhor experiência para o usuário nos dois serviços.

Para os editores e os desenvolvedores que ainda desejam usar o serviço de preenchimento automático em seus sites, temos uma alternativa. O Mecanismo de Pesquisa Personalizado do Google (Google Custom Search Engine) permite que os sites permaneçam com a funcionalidade do preenchimento automático em conexão com a funcionalidade da Pesquisa Google. Os parceiros que já estiverem usando o CSE do Google não serão afetados por essa mudança. Para os outros, se quiserem manter a funcionalidade de preenchimento automático após o dia 10 de agosto, acessem nossa página de inscrição do CSE.

Posted:
Muitos sites para dispositivos móveis usam intersticiais promocionais com o objetivo de incentivar os usuários a fazer o download de seus aplicativos nativos para dispositivos móveis. Para alguns aplicativos, a versão nativa proporciona ao usuário uma experiência mais produtiva e usa recursos do dispositivo cujo acesso é mais difícil em um navegador. Com isso, muitos proprietários de aplicativos acreditam que devem incentivar os usuários a instalar a versão nativa de seu produto ou serviço online. No entanto, não está claro o grau de intensidade necessário para promover esses aplicativos, e um intersticial de página inteira pode impedir o usuário de acessar o conteúdo desejado.

Na web para dispositivos móveis do Google+, decidimos analisar mais detalhadamente nosso próprio uso de intersticiais. Estudos internos identificaram uma experiência do usuário menos proveitosa, e Jennifer Gove fez um discurso importante no Google I/O do ano passado, destacando essa frustração dos usuários.

Apesar da intuição de que deveríamos remover o intersticial, preferimos deixar que os dados orientassem nossas decisões e, dessa forma, começamos a descobrir de que maneira o intersticial afetava nossos usuários. Nossa análise descobriu que:
  • Em nossa página intersticial, 9% das visitas resultaram em cliques no botão "Instalar o aplicativo". No entanto, é importante ressaltar que um percentual desses usuários já havia instalado o aplicativo ou talvez não tenha prosseguido com o download na loja de aplicativos.
  • 69% das visitas abandonaram nossa página. Esses usuários não acessaram a loja de aplicativos nem visitaram nosso site para dispositivos móveis.
Embora 9% seja um excelente CTR para qualquer campanha, estávamos mais concentrados no número de usuários que tinham abandonado nosso produto devido a atritos na experiência. Com esses dados, em julho de 2014 decidimos realizar uma experiência e descobrir de que forma a remoção do intersticial afetaria a utilização efetiva do produto. Adicionamos um Smart App Banner para promover o aplicativo nativo de maneira menos intrusiva, de acordo com a recomendação fornecida na seção Evitar erros comuns do nosso Guia de SEO para dispositivos móveis. Os resultados foram surpreendentes:
  • O número de usuários ativos por um dia no nosso site para dispositivo móvel aumentou em 17%.
  • Em sua maioria, as instalações de aplicativos nativos do Google+ para iOS não foram afetadas (-2%). Não informaremos os números de instalações em dispositivos Android porque a maioria já vem com o Google+ instalado.
Com base nesses resultados, decidimos remover permanentemente o intersticial. Acreditamos que o aumento no número de usuários em nosso produto representa uma mudança positiva e estamos compartilhando essas informações com a esperança de que você reconsidere o uso de intersticiais promocionais. Vamos remover esses atritos na experiência do usuário e tornar a web para dispositivos móveis mais útil e utilizável.

(Depois deste estudo, lançamos uma melhor experiência na web móvel que atualmente não conta com um banner intersticial. No entanto, ele ainda pode ser encontrado no iOS 6 e em versões anteriores)

Posted:
Com a chegada de muitos novos domínios genéricos de primeiro nível (gTLDs, na sigla em inglês), queremos oferecer algumas informações sobre como eles são tratados na pesquisa do Google. Já escutamos e vimos dúvidas e ideias erradas sobre como tratamos novos Domínios de Primeiro Nível (TLDs, na sigla em inglês), como .guru, .how ou qualquer um dos gTLD .MARCA. Por exemplo:

P: Como os novos gTLDs afetarão a pesquisa? O Google alterará o algoritmo de pesquisa para priorizar esses TLDs? Qual a importância deles na pesquisa?
R: Em geral, nossos sistemas tratam novos gTLDs da mesma forma que outros gTLDs (como .com e .org). As palavras-chave em um TLD não oferecem vantagens ou desvantagens na pesquisa.

P: E quanto aos TLDs de Nomes de domínio internacional (IDN, na sigla em inglês) como .みんな? O Googlebot pode rastreá-los e indexá-los para que eles possam ser usados na pesquisa?
R: Sim. Esses TLDs podem ser usados da mesma forma que outros TLDs (é fácil verificar com uma consulta como [site:みんな]). O Google trata a versão Punycode do nome do host como um equivalente à versão não codificada, assim não é preciso redirecioná-lo ou canonizá-lo separadamente. Para o restante do URL, lembre-se de usar nele uma string de consulta e o UTF-8 para o caminho quando forem usados caracteres não ASCII.

P: O TDL .MARCA terá mais ou menos relevância do que um .com?
R: Não, esses TLDs serão tratados da mesma forma que outros gTLDs. Eles exigirão a mesma segmentação geográfica e configuração e não terão mais relevância ou influência do que os outros na forma como rastreamos, indexamos ou classificamos URLs.

P: Como os novos TLDs de região ou de cidade (como .london ou .bayern) são tratados?
R: Mesmo que eles pareçam específicos de alguma região, serão tratados como gTLDs. Isso é consistente com nosso gerenciamento de TLDs como .eu e .asia. Pode haver exceções, em algum momento, conforme verificamos como eles são usados na prática. Acesse nossa Central de Ajuda para mais informações sobre sites multilíngues e multirregionais e defina a segmentação geográfica no Search Console onde for relevante.

P: E quanto aos verdadeiros ccTLDs (Domínios de Primeiro Nível de códigos de países): o Google priorizará ccTLDs (como .uk, .ae etc.) como um domínio local para as pessoas que pesquisarem nesses países?
R: Por padrão, a maioria dos ccTLDs (com exceções) faz com que o Google os use para segmentar geograficamente o website. O ccTLD nos informa que provavelmente o website é mais relevante no país adequado. Mais uma vez, veja nossa Central de Ajuda para mais informações sobre sites multilíngues e multirregionais.

P: O Google oferecerá suporte ao meu trabalho de SEO para mudar meu domínio de .com para um novo TLD? Como faço a mudança do meu website sem perder a classificação de pesquisa ou o histórico?
R: Temos uma extensa documentação sobre mudança de site em nossa Central de Ajuda. Tratamos essas mudanças da mesma forma que qualquer outra mudança de site. Dito isso, as mudanças de domínio podem levar algum tempo para serem processadas para pesquisa (e fora da pesquisa, os usuários esperam que os endereços de e-mail deles permaneçam válidos por um longo período), por isso geralmente é melhor escolher um domínio que atenda às suas necessidades a longo prazo.

Esperamos que isso ofereça mais informações sobre como os novos Domínios de Primeiro Nível são gerenciados. Caso você tenha mais dúvidas, acesse o nosso Fórum de Ajuda para Webmasters.

Posted:
No ano passado publicamos um artigo extenso sobre links não naturais, as possíveis consequências da participação em esquemas de links pagos e os recursos que o Google disponibiliza para ajudar a recuperar seu site de uma ação manual.

Com o intuito de reforçar essa mensagem, hoje compartilhamos novamente informações que permitem clarificar e identificar links não naturais, compreender as consequências que eles podem causar para a reputação do seu site e sua classificação nos resultados de busca orgânica, e também o que você deve fazer se verificar que foi aplicada uma ação manual ao seu site.

Por que isso é importante e quais ações o Google está tomando?

missão do Google é organizar as informações do mundo e torná-las mundialmente acessíveis e úteis para os todos os usuários que usam os nossos serviços. Isso significa que, para cada pesquisa que cada usuário faz no Google, queremos mostrar os resultados que temos no nosso índice que possam ter mais valor e que sejam mais úteis para esse usuário. Para definir isso, existem hoje mais de 200 fatores que levamos em consideração, inclusive a reputação online de indivíduos, empresas, serviços, ou qualquer outro tipo de entidade que tenha uma presença online. Por que isso é importante? Porque melhor do que decidir "sozinhos" se um site/conteúdo tem qualidade, é "perguntar" ao coletivo das pessoas que usam a internet se consideram que certo site/conteúdo tem qualidade.

Esquemas de links artificiais e técnicas de manipulação de PageRank e do posicionamento nos resultados de pesquisa comprometem diretamente nossa habilidade de medir a reputação de websites e, consequentemente, não obedecem às nossas diretrizes de qualidade para webmasters.

Para manter a qualidade e relevância do nosso índice, continuamos tomando ações manuais em websites individuais e até redes inteiras de websites que violaram as nossas diretrizes de qualidade para webmasters de forma agressiva e deliberada. Isso pode resultar em um impacto negativo no posicionamento nos resultados de pesquisa dos sites que detectarmos estarem participando de esquemas de links artificiais.

Que tipo de links podem ser considerados pelo Google como prejudiciais?


Links artificiais para seu site

Nossa postura em relação a links apontando para o seu site não mudou: a participação em esquemas de links e a compra de links que passam o PageRank com o objetivo de distorcer os resultados de pesquisa orgânica continuam sendo considerados uma infração às nossas diretrizes de qualidade. Publicamos há algum tempo um vídeo sobre os critérios que usamos quando avaliamos se um link é pago ou artificial, com o intuito de ajudar os webmasters a entender melhor as nossas diretrizes referentes a links.

Para ilustrar um tipo específico de link pago, criamos o exemplo fictício exibido abaixo. No exemplo, repare que realçamos os links com âncoras de texto super otimizadas e assuma que eles estão configurados para passar o PageRank.
Exemplo fictício de links pagos em um artigo de um blog
No passado já comunicamos nosso posicionamento sobre estratégias de comercialização de artigos através da venda de artigos. De fato, a aquisição de links provenientes de diretórios de artigos também é considerada não natural. Para mais detalhes, voltamos a recomendar este vídeo em que o Matt Cutts fala sobre o que consideramos links pagos e não naturais.

Além do vídeo, o Matt publicou também em seu blog pessoal o artigo “The decay and fall of guest blogging for SEO" (artigo em inglês), em que comenta a mudança que tem acontecido nos últimos anos na natureza dos artigos "convidados" em blogs de terceiros. No texto, ele comenta como esses artigos "convidados" têm deixado de ser uma atividade respeitável, para passarem a fazer regularmente parte de práticas inteiramente focadas na aquisição de links que passam o PageRank. Consequentemente, em vez de contribuírem com diferentes pontos de vista sobre os temas dos blogs onde são publicados, esses artigos dão cada vez menos importância à qualidade e autenticidade do conteúdo e cada vez mais importância aos links que são criados e colocados nesses artigos.

Links artificiais em seu site

Além da compra de links, gostaríamos de relembrar que a venda de links que passam o PageRank também é uma infração clara das nossas diretrizes de qualidade.

Temos notado que vários blogs em português estão hospedando links altamente otimizados, que estão passando o PageRank, para websites de terceiros, seja através de artigos promocionais/convidados, ou do uso de widgets embutidos que contêm esses links.

Apesar de compreendermos que esses posts possam ter sido criados sem más intenções por parte do dono do site, esses links específicos são uma violação das nossas diretrizes, pois foram criados com o único propósito de passar o PageRank e manipular o posicionamento desses websites de terceiros nos resultados de pesquisa. O mesmo acontece com os widgets que contêm no código links otimizados que passam o PageRank.

Criamos um widget fictício para ilustrar um modelo comum que encontramos em blogs legítimos. Repare nos links embutidos no widget que passam o PageRank e, portanto, não estão de acordo com as nossas diretrizes para webmasters. Nesse caso, é bastante clara a intenção do link otimizado, mas existem outras ocasiões em que a intenção do link presente no widget não é tão transparente, sendo até possível que o webmaster que coloca o widget no seu próprio website não se dê conta da natureza dos links alojados no código desse widget.

Exemplo fictício de um link otimizado contido num widget
Se você tem dúvidas sobre a qualidade dos links presentes em seu website, ou apontando para o mesmo, recomendamos que volte a ler as diretrizes para webmasters e faça uma auditoria dos links de e para o seu site, a fim de confirmar se estão de acordo com as diretrizes de qualidade do Google. Se você acredita que alguns dos links são suspeitos, é prática recomendada removê-los, colocar uma marcação "nofollow" nos mesmos, ou pedir a quem faz a gestão do seu site que tome essa ação por você.

Se você acreditar que um site específico utiliza técnicas que violam as nossas diretrizes para webmasters, ou se algum webmaster entrar em contato oferecendo uma troca de links, pode fazer uma denúncia de spam, ajudando-nos assim a aumentar a qualidade dos resultados de pesquisa.

O que devo fazer se o meu site sofrer uma ação manual?

Apesar de o Google ter algoritmos que avaliam e constantemente melhoram a qualidade dos resultados de pesquisa, tomamos também ações manuais em sites que usam técnicas de spam, rebaixando-os ou até mesmo removendo-os totalmente dos nossos resultados de pesquisa.

Se o seu site tiver sofrido uma ação manual, você poderá ter acesso a essa informação na sua conta do Google Search Console, na seção "Tráfego de pesquisa → Ações Manuais". Depois de seguir todos os passos para corrigir o problema mencionado, você pode submeter um pedido de reconsideração. É importante que você garanta que o seu problema está completamente resolvido antes de nos enviar o pedido de reconsideração

Nos casos de links artificiais para o seu site, isso significa entrar em contato com os webmasters dos websites onde esses links tenham sido colocados, e pedir que removam os links problemáticos. Em último caso, se não conseguir que alguns desses links sejam removidos, pode usar a ferramenta para rejeitar links.

Se houver links artificiais no seu site apontando para outro site, ou se houver anúncios de texto com âncoras otimizadas que estejam passando o PageRank, certifique-se de que esses links sejam removidos, ou que contêm uma marcação "nofollow".

Para concluir, deixamos um conselho simples para garantir que você não está infringindo as diretrizes do Google: não compre, venda, troque ou peça links que violam nossas diretrizes para webmasters sobre Esquemas de links. Se seguir esse conselho, a grande maioria dos links que o Google considera problemáticos não chegarão a ser criados.

Se tiver mais dúvidas, pode colocá-las no nosso Fórum de ajuda para Webmasters.

Publicado por Diogo Botelho, Equipe de Search Quality e Webmaster Outreach

Posted:

O envio de sitemaps pode ser uma parte importante da otimização de websites. Os sitemaps permitem que os mecanismos de pesquisa descubram todas as páginas em um site e façam o download delas rapidamente quando há alterações. Aqui explicamos quais campos são importantes nos sitemaps, quando usar sitemaps em XML e feeds RSS/Atom, e como otimizá-los para o Google.

Sitemaps e feeds

Os sitemaps podem estar nos formatos sitemap XML, RSS ou Atom. A diferença mais importante entre esses formatos é que os sitemaps em XML descrevem todo o conjunto de URLs em um site, enquanto os feeds RSS/Atom descrevem as alterações recentes. Isso tem implicações importantes:
  • Os sitemaps em XML geralmente são grandes. Os feeds RSS/Atom são pequenos, contendo somente as atualizações mais recentes do seu site.
  • O download dos sitemaps em XML é feito com menos frequência que o dos feeds RSS/Atom.
Para um rastreamento ideal, recomendamos usar os sitemaps em XML e os feeds RSS/Atom. Os sitemaps em XML darão informações ao Google sobre todas as páginas no seu site. Os feeds RSS/Atom fornecerão todas as atualizações no seu site, ajudando o Google a manter seu conteúdo em dia no índice. O envio de sitemaps ou feeds não garante a indexação dessas URLs.

Exemplo de um sitemap XML:

<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>http://example.com/mypage</loc>
   <lastmod>2011-06-27T19:34:00+01:00</lastmod>
   <!-- optional additional tags -->
 </url>
 <url>
   ...
 </url>
</urlset>

Exemplo de um feed RSS:

<?xml version="1.0" encoding="utf-8"?>
<rss>
 <channel>
   <!-- other tags -->
   <item>
     <!-- other tags -->
     <link>http://example.com/mypage</link>
     <pubDate>Mon, 27 Jun 2011 19:34:00 +0100</pubDate>
   </item>
   <item>
     ...
   </item>
 </channel>
</rss>

Exemplo de um feed Atom:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
 <!-- other tags -->
 <entry>
   <link href="http://example.com/mypage" />
   <updated>2011-06-27T19:34:00+01:00</updated>
   <!-- other tags -->
 </entry>
 <entry>
   ...
 </entry>
</feed>


As “outras tags” se referem às tags opcionais e obrigatórias pelos respectivos padrões. Recomendamos que você especifique as tags obrigatórias para Atom/RSS, pois elas o ajudarão a aparecer em outras propriedades que podem usar esses feeds, além da Pesquisa Google.

Práticas recomendadas

Campos importantes

Os sitemaps em XML e os feeds RSS/Atom, em sua essência, são listas de URLs com metadados anexados. As duas informações mais importantes para o Google são o próprio URL e o horário da última modificação:

URLs

As URLs nos sitemaps em XML e feeds RSS/Atom devem seguir as seguintes diretrizes:
  • Incluir somente URLs que podem ser buscados pelo Googlebot. Um erro comum é incluir URLs não permitidos pelo robots.txt, que não podem ser buscados pelo Googlebot, ou incluir URLs de páginas que não existem.
  • Incluir somente URLs canônicos. Um erro comum é incluir os URLs de páginas duplicadas. Isso aumenta o carregamento no seu servidor sem melhorar a indexação.

Horário da última modificação

Especifique o horário da última modificação para cada URL em um sitemap XML e feed RSS/Atom. O horário da última modificação deve ser a última vez que o conteúdo da página foi alterado de maneira significativa. Se uma alteração tiver sido feita para ficar visível nos resultados da pesquisa, o horário da última modificação deverá ser a hora que essa alteração foi realizada.

  • O sitemap XML usa  <lastmod>
  • O RSS usa <pubDate>
  • O Atom usa <updated>

Defina ou atualize o horário da última modificação corretamente:

  • Especifique o horário no formato correto: formato data e hora do W3C para sitemaps XML, RFC3339 para Atom e RFC822 para RSS.
  • Atualize o horário da modificação somente quando o conteúdo for alterado significativamente.
  • Não defina o horário da última modificação para o horário atual todas as vezes que o sitemap ou o feed for veiculado.

Sitemaps XML

Os sitemaps XML devem ter URLs de todas as páginas no seu site. Em geral, eles são grandes e são atualizados com pouca frequência. Siga estas diretrizes:
  • Para um único sitemap XML: atualize-o pelo menos uma vez por dia (caso seu site seja alterado regularmente) e dê um ping no Google depois de atualizá-lo.
  • Para um conjunto de sitemaps XML: maximize o número de URLs em cada sitemap XML. O limite é 50.000 URLs ou um tamanho máximo de 10 MB não compactados, o que for atingido primeiro. Dê um ping no Google para cada sitemap XML atualizado (ou uma vez para o índice de sitemaps, caso seja usado) todas as vezes que ele for atualizado. Um erro comum é colocar somente alguns URLs em cada arquivo de Sitemap XML, o que geralmente dificulta para que o Google faça o download de todos esses sitemaps XML em um tempo razoável.

RSS/Atom

Os feeds RSS/Atom devem transmitir as atualizações recentes do seu site. Em geral, eles são pequenos e são atualizados com frequência. Para esses feeds, recomendamos:
  • Quando uma nova página é adicionada ou uma página existente é alterada significativamente, adicione o URL e o horário da modificação ao feed.
  • Para que o Google não perca atualizações, o feed RSS/Atom deve ter todas as atualizações desde a última vez que o Google fez o download dele. A melhor maneira de conseguir isso é usando o PubSubHubbub. O hub propagará o conteúdo do seu feed para todas as partes interessadas (leitores RSS, mecanismos de pesquisa etc.) da maneira mais rápida e eficiente possível.

Gerar os sitemaps XML e feeds Atom/RSS é uma ótima maneira de otimizar o rastreamento de um site para o Google e outros mecanismos de pesquisa. As principais informações nesses arquivos são o URL canônico e o horário da última modificação das páginas no website. Configurá-los corretamente e notificar o Google e outros mecanismos de pesquisa com pings dos sitemaps e PubSubHubbub permitirá que seu website seja rastreado da melhor forma e representado apropriadamente nos resultados da pesquisa.

Se você tiver alguma pergunta, junte-se a outros webmasters na seção sobre sitemaps do Fórum de Ajuda para webmasters.

Postado por Alkis Evlogimenos, equipe de Feeds do Google
Diogo Botelho