Posted:
Todos os dias, milhares de websites são invadidos. Os sites invadidos podem prejudicar usuários ao disponibilizar softwares maliciosos, coletar informações pessoais ou redirecioná-los a sites que não tinham a intenção de visitar. Os webmasters querem corrigir sites invadidos rapidamente, mas recuperar-se de uma invasão pode ser um processo complicado.


Estamos trabalhando para facilitar o processo de recuperação após uma invasão para os webmasters com recursos como Problemas de Segurança, Ajuda dos Webmasters para Sites Invadidos e uma seção do nosso fórum somente para sites invadidos. Recentemente conversamos com dois webmasters que tiveram seus sites invadidos para saber como eles conseguiram recuperar esses sites. Compartilharemos as histórias deles com a esperança de que elas possam dar ideias a outros webmasters vítimas de invasão. Além disso, usaremos essas histórias e outros comentários para melhorar nossa documentação sobre sites invadidos a fim de facilitar o processo para todos daqui para frente.

Estudo de caso nº 1: site de restaurante com vários scripts injetados por hackers

O site de um restaurante que usa o WordPress recebeu uma mensagem do Google na conta das Ferramentas do Google para webmasters, alertando que o site havia sido alterado por hackers. Para proteger os usuários do Google, o site foi identificado como "invadido" nos resultados da pesquisa do Google. A webmaster do site, Sam, verificou o código-fonte e identificou vários links desconhecidos no site com termos farmacêuticos como "viagra" e "cialis". Ela também notou diversas páginas em que as tags de metadescrição (no HTML) haviam adicionado conteúdo como "compre valtrex na Flórida". Também havia tags div escondidas (novamente no HTML) de várias páginas que vinculavam a diversos sites. Nenhum desses links foi adicionado pela Sam.

Sam removeu todo o conteúdo invadido que encontrou e enviou um pedido de reconsideração. O pedido foi rejeitado, mas, na mensagem que ela recebeu do Google, foi aconselhada a verificar a existência de scripts desconhecidos em arquivos .php (ou outros arquivos do servidor), assim como alterações no arquivo .htaccess. Geralmente esses arquivos têm scripts adicionados pelos hackers que alteraram o site. Normalmente esses scripts mostram o conteúdo invadido somente aos mecanismos de busca, escondendo o conteúdo de um usuário normal. Sam verificou todos os arquivos .php e os comparou com as cópias limpas que tinha no backup. Ela encontrou conteúdos novos adicionados nos arquivos footer.php, index.php e functions.php. Depois de substituí-los pelos arquivos limpos do backup, ela não encontrou mais nenhum conteúdo invadido no site. Ao enviar outro pedido de reconsideração, ela recebeu uma resposta do Google informando que o site estava livre de conteúdo invadido.

Sam sabia que precisaria continuar a proteger o site contra futuros ataques, mesmo que tivesse retirado do site o conteúdo invadido. Ela seguiu as etapas abaixo para manter o site seguro no futuro:
  • Manter o CMS (sistema de gerenciamento de conteúdo, como WordPress, Joomla, Drupal etc.) atualizado com a versão mais recente. Certificar-se de que os plug-ins também estão atualizados.
  • Verificar se a conta usada para acessar os recursos administrativos do CMS usa uma senha difícil e única.
  • Se o CMS for compatível, ativar a verificação em duas etapas para o login. Esse recurso também é chamado de "autenticação de dois fatores" ou "autenticação em duas etapas". Isso também é recomendado para a conta usada para a recuperação da senha. A maioria dos provedores de e-mail, como Google, Microsoft e Yahoo são compatíveis com esse recurso.
  • Verificar se os plug-ins e os temas instalados são de fontes confiáveis. Plug-ins ou temas piratas podem muitas vezes ter códigos que permitem a entrada de hackers mais facilmente.
Estudo de caso nº 2: site profissional com várias páginas invadidas difíceis de encontrar

Maria é proprietária de uma empresa de pequeno porte e gerencia o próprio website. Ela recebeu uma mensagem nas Ferramentas do Google para webmasters informando que o site dela havia sido invadido. A mensagem fornecia um exemplo de uma página adicionada por hackers: http://example.com/where-to-buy-cialis-over-the-counter/. Ela conversou com o provedor de hospedagem, que verificou o código-fonte na página inicial, mas não encontrou palavras-chave farmacêuticas. Quando o provedor de hospedagem visitou http://example.com/where-to-buy-cialis-over-the-counter/, o URL retornou uma página de erro. Maria também comprou um serviço de verificação de malware, mas ele não conseguiu encontrar nenhum conteúdo malicioso no site dela.

Maria foi então para as Ferramentas do Google para webmasters e usou a ferramenta "Buscar como o Google" na URL de exemplo fornecida pelo Google (http://example.com/where-to-buy-cialis-over-the-counter/), que não retornou conteúdo algum. Confusa, ela enviou um pedido de reconsideração e recebeu uma mensagem de rejeição recomendando que ela fizesse duas coisas:
  1. Verificasse a versão sem "www" do site, já que geralmente os hackers tentam esconder o conteúdo em pastas que podem ser esquecidas pelos webmasters.

    Embora possa parecer que http://example.com e http://www.example.com sejam o mesmo site, o Google os trata como sites diferentes. http://example.com é referido como o "domínio raiz", enquanto http://www.example.com é chamado de subdomínio. Maria havia verificado o endereço http://www.example.com, mas não o http://example.com, o que é importante porque as páginas adicionadas pelos hackers eram sem "www", como http://example.com/where-to-buy-cialis-over-the-counter/. Assim que verificou a URL http://example.com, ela conseguiu encontrar o conteúdo invadido na URL que havia sido fornecida, por meio da ferramenta "Buscar com o Google" nas Ferramentas do Google para webmasters.

  2. Verificasse o arquivo .htaccess para novas regras.

    Maria conversou com o provedor de hospedagem, que mostrou a ela como acessar o arquivo .htaccess. Ela percebeu imediatamente que o arquivo .htaccess tinha um conteúdo estranho que ela não havia adicionado:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
    RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
    RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
    </IfModule>


    A regra mod_rewrite que você vê acima foi inserida pelo hacker e redireciona qualquer pessoa que tenha vindo de determinados mecanismos de pesquisa e indexadores de mecanismos de pesquisa para main.php, que gera todo o conteúdo invadido. Também é possível que essas regras redirecionem usuários que acessam o site a partir de dispositivos móveis. No mesmo dia, ela viu que uma verificação recente de malware encontrou conteúdo suspeito no arquivo main.php. Além disso, ela também percebeu que havia um usuário desconhecido na área de usuários do FTP do software de desenvolvimento de website dela.
Ela removeu o arquivo main.php, o arquivo .htaccess e excluiu o usuário desconhecido da área de usuários do FTP, e o site não estava mais invadido.

Etapas para evitar uma invasão no futuro
  • Evite usar FTP ao transferir arquivos para seus servidores. O FTP não criptografa o tráfego nem senhas. Em vez disso, use SFTP, que criptografa tudo, inclusive suas senhas, como uma proteção contra curiosos examinando o tráfego da rede.
  • Verifique as permissões em arquivos confidenciais como .htaccess. Seu provedor de hospedagem poderá ajudá-lo se necessário. O arquivo .htaccess pode ser usado para melhorar e proteger seu site, mas também para invasões maliciosas caso consigam acesso a ele.
  • Fique atento e procure por usuários novos e desconhecidos no seu painel administrativo e em outros locais onde possa haver usuários que alterem seu site.
Esperamos que seu site nunca seja invadido, mas, caso seja, temos vários recursos para webmasters em nossa página "Ajuda dos webmasters para sites invadidos". Se você precisar de mais ajuda ou desejar compartilhar suas dicas, poste em nosso Fórum de ajuda para Webmasters. Caso você poste no fórum ou envie um pedido de reconsideração para seu site, inclua #NoHacked.

Publicado por Julian Prentice e Yuan Niu, da equipe de Qualidade da Pesquisa

Posted:
O JSON-LD é um formato de dados com base em JSON que pode ser usado para implementar dados estruturados a fim de descrever conteúdos no seu site para o Google e outros mecanismos de busca. Por exemplo, se você tiver uma lista de eventos, restaurantes, pessoas ou algo mais, pode incluir esses dados nas páginas de um modo estruturado usando o vocabulário schema.org, incorporado nas páginas da web como um snippet JSON-LD. Os dados estruturados ajudam o Google a entender melhor suas páginas e a destacar o conteúdo em recursos de pesquisa, tais como eventos no Mapa do Conhecimento e rich snippets.

Os Web Components são um conjunto emergente de tecnologias usadas para definir widgets personalizados e reutilizáveis de interface do usuário e seus respectivos comportamentos. Qualquer desenvolvedor web pode construir um Web Component. Você começa pela definição de um modelo para uma parte específica da interface de usuário, que depois será importada para as páginas nas quais você deseja usar o Web Component. Um Custom Element é usado para definir o comportamento do Web Component. Como você está agrupando a exibição e a lógica de uma parte da interface de usuário no Web Component, é possível compartilhar e reutilizar o grupo em outras páginas e com outros desenvolvedores, simplificando o processo de desenvolvimento.

O JSON-LD e os Web Components funcionam muito bem juntos. O Custom Element funciona como a camada de apresentação, ao passo que o JSON-LD funciona como a camada de dados consumida pelo Custom Element e pelos mecanismos de busca. Isso significa que é possível construir Custom Elements para qualquer tipo de schema.org, como schema.org/Event e schema.org/LocalBusiness.

Sua arquitetura seria assim: os dados estruturados são armazenados no banco de dados (por exemplo, os endereços das lojas da sua rede). Os dados são incorporados na sua página web na forma de um snippet JSON-LD, o que os torna disponíveis para consumo pelo Custom Element. Assim, eles podem ser exibidos a um visitante humano e também ser recuperados pelo Googlebot para a indexação do Google.

Para saber mais e dar os primeiros passos com seus Custom Elements, consulte:
Publicado por Ewa Gasperowicz, engenheira de desenvolvimento de programas; Mano Marks, assistente de desenvolvimento; e Pierre Far, analista de tendências para webmasters

Posted:
Conforme anunciamos aqui no blog de Webmasters, a partir do dia 21 de abril a compatibilidade de um site com dispositivos móveis se tornará um fator de classificação nos resultados de buscas feitas no Google a partir desses dispositivos. O seu site passa no Teste de Compatibilidade com Dispositivos Móveis? Se a resposta é não, está na hora de começar a se preparar.

Para ajudar tanto os webmasters como os donos de negócios a entender a importância de ter páginas otimizadas para mobile, além de mostrar quais são as ferramentas e documentação disponíveis para auxiliá-los nessa tarefa, lançamos hoje a campanha #MobileMadness.

Ao longo de um mês, faremos Hangouts ao vivo para explicar o que consideramos ser uma boa experiência em mobile e quais os passos que devem ser tomados para garantir que o seu site providencie essa experiência aos usuários. Haverá ainda uma sessão de Q&A para tirar dúvidas sobre essa mudança no ranking, além de várias dicas e um desafio.
A campanha #MobileMadness acontecerá no canal do Google para Seu Negócio. Confira abaixo a agenda completa:

Hangouts

Dia 23/03: Apresentação para PMEs: Otimize sua estratégia online e seu desempenho na busca
Como manter o foco nos canais corretos, introdução às Ferramentas do Google para Webmasters e SEO como estratégia de longo prazo

Série de quatro apresentações: Noções básicas de um site mobile para PMEs

15/04: Q&A: Sessão de perguntas e respostas sobre as mudanças no ranking para sites compatíveis com dispositivos móveis

Outros materiais
  • Desafio: Torne seu site compatível com dispositivos móveis em 30 dias
  • Dicas para tornar seu site compatível com dispositivos móveis (#mobilefriendly)
  • Pesquisas todas as sextas-feiras
Se tiver alguma questão específica sobre seu site, ou quiser ajudar outros webmasters a tornar seus websites compatíveis com dispositivos móveis, visite o nosso Fórum de ajuda para Webmasters.

Pronto para fazer parte dessa mudança e oferecer uma experiência de navegação incrível para seus usuários em todos os tipos de dispositivos? Participe da campanha #MobileMadness.

Publicado por Diogo Botelho e Juan Felipe Rincón, Equipe de Search Quality e Webmaster Relations

Posted:
Muitos websites dependem de formulários para a conclusão de objetivos importantes, como uma transação em um site de compras ou um registro em um site de notícias. Para muitos usuários, preencher formulários on-line significa digitar repetidamente informações comuns, como nomes, e-mails, números de telefone ou endereços, em diferentes sites na Web. Além de ser monótona, essa tarefa é propensa a erros, o que pode levar muitos usuários a desistirem do procedimento por completo. Em um mundo onde os usuários navegam pela Internet usando mais dispositivos móveis do que laptops ou computadores desktop é essencial ter formulários que sejam rápidos e fáceis de preencher.

Há três anos, anunciamos o suporte para o novo atributo “preenchimento automático” no Google Chrome para tornar o preenchimento de formulários mais rápido, fácil e inteligente. Agora o Google Chrome é completamente compatível com o atributo "preenchimento automático" para campos de formulários de acordo com o Padrão de HTML WHATWG atual. Isso permite a webmasters e desenvolvedores da Web rotular os campos de elementos de entrada com tipos de dados comuns, como "nome" ou "endereço", sem alterar a interface do usuário nem o back-end. Diversos webmasters aumentaram a taxa de preenchimento de formulários nos sites deles marcando os formulários para preenchimento automático.

Por exemplo, marcar um campo de endereço de e-mail em um formulário para permitir o preenchimento automático ficaria assim (com uma amostra completa de formulário disponível):

<input type=”email” name=”customerEmail” autocomplete=”email”/>
captureexample.jpg

É muito importante facilitar o uso dos websites em dispositivos móveis. No futuro, esperamos ver muitos formulários marcados com o atributo "preenchimento automático". Para mais informações, confira nossas especificações sobre Rotular e nomear entradas nos Fundamentos da Web. Como sempre, em caso de dúvidas, poste-as em nosso Fórum de Ajuda para webmasters.

Postado por Mathieu Perreault, engenheiro de Software do Google Chrome, e Zineb Ait Bahajji, analista de Tendências para webmasters

Posted:
A equipe de Qualidade de Pesquisa do Google trabalha continuamente para encontrar maneiras de minimizar o impacto dos webspams para os usuários. Isso inclui as doorways (páginas de entrada).

Há muito tempo nossa opinião é de que as doorways criadas somente para os mecanismos de pesquisa podem prejudicar a qualidade da experiência de pesquisa do usuário.

Por exemplo, ao fazer uma pesquisa, os usuários podem receber uma lista de resultados que levam todos ao mesmo site. Consideramos que o usuário terá uma experiência frustrante se clicar em um link, não gostar do conteúdo ali apresentado e, ao tentar o resultado seguinte na página de pesquisa, for levado ao mesmo site.

Com o tempo, notamos que os sites tentam maximizar sua presença nas pesquisas sem agregar valores claros e exclusivos. Essas campanhas de doorway aparecem como páginas de um site, uma quantidade de domínios ou uma combinação desses elementos. A fim de melhorar a qualidade dos resultados da pesquisa para nossos usuários, lançaremos em breve um ajuste de classificação para tratar desses tipos de página. Sites com campanhas amplas e bem estabelecidas de doorway poderão perceber um grande impacto causado por essa alteração.

Para ajudar os webmasters a entender melhor nossas diretrizes, adicionamos exemplos mais claros e renovamos nossa definição de doorways em nossas diretrizes de qualidade.

Estas são algumas das perguntas a fazer em relação às páginas que podem ser consideradas doorways:
  • O propósito da página é otimizar os resultados em mecanismos de busca e direcionar os visitantes à parte relevante e utilizável do site, ou a página é ela mesmo parte integrante da experiência do usuário do site?
  • As páginas se destinam a receber classificações por termos genéricos, mas o conteúdo apresentado nelas é muito específico?
  • As páginas duplicam agregações úteis de itens (locais, produtos etc.) já existentes no site a fim de receber mais tráfego de pesquisa?
  • As páginas foram criadas somente para atrair tráfego afiliado e encaminhar os usuários sem criar valores exclusivos em termos de conteúdo ou funcionalidade?
  • É possível dizer que as páginas estão "ilhadas"? É difícil ou impossível acessá-las a partir de outras partes do site? Os links que levam a tais páginas a partir de outras seções do site ou da rede de sites foram criados somente para os mecanismos de busca?
Se você tiver perguntas ou comentários sobre as doorways, visite nosso Fórum de ajuda para Webmasters.

Publicado por Brian White, equipe de Webspam do Google

Posted:
Os webmasters costumam usar arquivos de imagens vinculadas, CSS e JavaScript em páginas da web para deixá-las bonitas e funcionais. Se o rastreamento desses recursos for bloqueado, o Googlebot não poderá usá-los ao processar essas páginas para pesquisa. Agora as Ferramentas do Google para webmasters incluem um Relatório de recursos bloqueados para ajudar você a encontrar e resolver esse tipo de problemas.
Esse relatório começa com os nomes dos hosts dos quais seu site está usando recursos bloqueados, como JavaScript, CSS e imagens. Ao clicar nas linhas, você recebe uma lista de recursos bloqueados e as páginas que os incorporam. Elas guiarão você pelas etapas para diagnosticar e resolver como podemos rastrear e indexar o conteúdo da página.

Uma atualização da ferramenta Buscar e renderizar mostra como esses recursos bloqueados são importantes. Quando você solicitar a busca e a renderização de uma URL, a ferramenta exibirá capturas de tela renderizadas como o Googlebot e como um usuário normal. Isso torna mais fácil o reconhecimento dos problemas que influenciam significativamente o porquê de suas páginas serem vistas de maneira diferente pelo Googlebot.
As Ferramentas do Google para Webmasters tentam mostrar somente os hosts nos quais é possível ter influência. Por isso, de momento, não mostraremos hosts que são usados por muitos sites diferentes, tais como os de serviços de análise (analytics) mais conhecidos. Pode demorar bastante (geralmente não por razões técnicas) para atualizar todos os arquivos robots.txt. Assim, recomendamos começar com os recursos que criam as diferenças visuais mais importantes quando bloqueados. Nosso artigo na Central de Ajuda tem mais informações sobre as etapas envolvidas.

Esperamos que essa nova ferramenta facilite a identificação e o desbloqueio dos recursos usados pelo seu website. Se você tiver dúvidas, visite nossos Fórum de ajuda para Webmasters.

Postado por John Mueller, Analista de tendências para webmasters, Google Suíça

Posted:
Este artigo foi publicado originalmente no Google Online Security Blog (artigo em inglês).

Se você gerencia um website, deve estar familiarizado com as Ferramentas do Google para Webmasters e como elas permitem que você saiba se a Navegação Segura encontrou algo problemático no seu site. Por exemplo, você será avisado se o seu site está espalhando malware, o que geralmente é um sinal de que ele foi invadido. Agora, estamos também ampliando nossas proteções de Navegação Segura para automaticamente exibir avisos para todos os usuários de Google Analytics por meio das Notificações do Google Analytics.



A Navegação Segura do Google tem protegido pessoas na internet por mais de oito anos e estamos sempre procurando novas maneiras de ampliar essa proteção. Essas notificações ajudam webmasters como você a agir rapidamente para resolver quaisquer problemas. Respostas rápidas ajudam a manter seu site - e seus visitantes - seguros.

Publicado por Stephan Somogyi, Gerente de Produtos, Segurança e Privacidade
Diogo Botelho