Blog Central para Webmasters
Informação Oficial sobre classificação e indexação dos sites no índice do Google
Ajudar os usuários a encontrar páginas compatíveis com dispositivos móveis
terça-feira, 18 de novembro de 2014
Você já tocou em um resultado da Pesquisa Google no seu smartphone e acabou em uma página com um texto pequeno demais e links minúsculos, precisando rolar horizontalmente para ver todo o conteúdo? Isso geralmente acontece quando o site não foi otimizado para visualização em um smartphone.
Essa experiência pode ser frustrante para os usuários que realizam pesquisas para dispositivos móveis. A partir de hoje, para que as pessoas encontrem as informações que estão procurando mais facilmente, haverá um rótulo "para mobile" adicionado aos nossos resultados de pesquisa para dispositivos móveis.
Essa mudança será implementada mundialmente nas próximas semanas
.
(Atualização, 10 de Dezembro 2014: Essa mudança será lançada mundialmente durante o dia de hoje)
Uma página estará qualificada para o rótulo "para mobile" se atender aos seguintes critérios detectados pelo Googlebot:
Evitar softwares que não sejam comuns em dispositivos móveis, como Flash
Usar textos que sejam legíveis sem aumentar o zoom
Dimensionar o conteúdo no tamanho da tela para que os usuários não precisem rolar horizontalmente nem aplicar zoom
Posicionar os links afastados o suficiente para que se possa tocá-los com facilidade
Se você desejar garantir que sua página atenda aos critérios de compatibilidade com dispositivos móveis:
Faça o
Teste de compatibilidade com dispositivos móveis
nas suas páginas
Leia nossos documentos atualizados em nosso
Guia de dispositivos móveis para webmasters
sobre como criar e aprimorar seu site para dispositivos móveis
Veja o
Relatório de facilidade de uso em dispositivos móveis
nas Ferramentas do Google para webmasters, que destaca os principais problemas de facilidade de uso para mobile em todo o site, não apenas em uma página
Consulte nosso
guia para software de terceiros
, como WordPress ou Joomla, para migrar seu site hospedado em um CMS (gerenciador de conteúdo) e usar um modelo compatível com dispositivos móveis
De momento, as ferramentas e documentação mencionadas só estão disponíveis em inglês. Elas irão ser disponibilizadas em mais idiomas nas próximas semanas.
(Atualização, 10 de Dezembro 2014: As ferramentas e documentação mencionadas estão agora disponíveis em vários idiomas, incluindo português)
Esses rótulos são vistos como um primeiro passo para ajudar os usuários a terem uma experiência aprimorada na Web para dispositivos móveis. Além disso, estamos testando o uso de critérios de compatibilidade com dispositivos móveis como um sinal de classificação.
Se tiver alguma questão ou quiser ajudar outros webmasters a tornar seus websites compatíveis com dispositivos móveis, visite o nosso
Fórum de ajuda para Webmasters
. Esperamos ver muito mais sites compatíveis com dispositivos móveis no futuro. Assim, melhoraremos a Web para todos os usuários.
Publicado por
Ryoichi Imaizumi
e
Doantam Phan
, Pesquisa Google Mobile
Traduzido por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
Promover sites modernos para dispositivos modernos nos resultados de pesquisa do Google
quarta-feira, 29 de outubro de 2014
Nível do webmaster: todos
Um aborrecimento comum dos usuários da Web é quando os sites exigem tecnologias de navegador que não são compatíveis com o dispositivo utilizado. Quando os usuários acessam essas páginas, eles só veem um espaço em branco ou uma grande parte do conteúdo da página não é exibido.
A partir de hoje, avisaremos os usuários que realizam pesquisas quando nossos algoritmos detectarem páginas que talvez não funcionem nos dispositivos deles. Por exemplo, o Adobe Flash não é compatível com dispositivos iOS ou com a versão 4.1 e superiores do Android, então uma página com a maior parte do conteúdo em Flash poderá ser visualizada desta forma:
Como desenvolver sites compatíveis com vários dispositivos modernos
A boa notícia é que fazer sites que funcionam em todos os dispositivos modernos não é difícil: os sites podem usar HTML5, pois ele é compatível universalmente, e às vezes de forma exclusiva, com todos os dispositivos. Para ajudar os webmasters a criar sites que funcionam em todos os tipos de dispositivos independentemente do tipo de conteúdo que desejam exibir,
anunciamos
há pouco dois recursos:
Fundamentos da Web
: uma fonte selecionada de práticas recomendadas modernas.
Kit de primeiros passos para a Web
: uma estrutura pronta para uso complementar às práticas recomendadas dos Fundamentos da Web.
Ao seguir as práticas recomendadas descritas nos Fundamentos da Web, é possível criar um
design Web responsivo
, o que é uma
recomendação antiga do Google
para a criação de sites compatíveis com a pesquisa. Não bloqueie o rastreamento de nenhum Googlebot dos recursos da página (CSS, JavaScript e imagens) usando robots.txt ou outros métodos. O acesso completo a esses arquivos externos ajuda nossos algoritmos a detectar a configuração de Web design responsivo do seu site e tratá-lo de forma adequada. Use o recurso
Buscar e renderizar como o Google
nas Ferramentas do Google para webmasters para testar como nossos algoritmos de indexação vêem seu site.
Como sempre, poste uma pergunta no nosso
Fórum de ajuda para Webmasters
se você precisar de mais ajuda.
Escrito por Keita Oda, Engenheiro de software, e Pierre Far, Analista de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
Atualização das nossas diretrizes técnicas para webmasters
segunda-feira, 27 de outubro de 2014
Nível do webmaster: todos
Recentemente, anunciamos que nosso sistema de indexação estava
renderizando páginas da Web
de maneira semelhante a um navegador moderno padrão, com CSS e JavaScript ativados. Hoje, estamos atualizando uma das nossas
diretrizes técnicas para Webmasters
relacionadas a esse anúncio.
Para a renderização e a indexação ideais, nossas novas diretrizes especificam que você precisa permitir o acesso do Googlebot aos arquivos de imagem, JavaScript e CSS usados pela sua página. Desse modo, a renderização e a indexação ideais ficarão disponíveis para seu site.
Desabilitar o rastreamento de arquivos JavaScript ou CSS no arquivo robots.txt do seu site afeta diretamente a qualidade de renderização e indexação dos nossos algoritmos sobre seu conteúdo, o que pode resultar em classificações inferiores
.
Orientações atualizadas para a indexação ideal
Historicamente, os sistemas de indexação do Google eram semelhantes aos antigos navegadores somente de texto, como o Lynx, e era isso o que nossas diretrizes para webmasters diziam. Agora, com a indexação com base na renderização da página, nossos sistemas de indexação não podem continuar sendo classificados como navegadores somente de texto. Em vez disso, chamá-lo de navegador da Web moderno torna-se uma abordagem mais precisa. Com essa nova perspectiva, lembre-se do seguinte:
Assim como os navegadores modernos, nosso mecanismo de renderização pode não ser compatível com todas as tecnologias usadas por uma página. Verifique se seu design da Web adota os princípios de
melhoria progressiva
. Isso ajuda nossos sistemas (e uma variedade mais ampla de navegadores) a ver o conteúdo útil e as funcionalidades básicas de determinados recursos de design da Web que ainda não são compatíveis.
As páginas renderizadas rapidamente não só ajudam os usuários a acessar seu conteúdo com maior facilidade, como também tornam a indexação das páginas mais eficiente. Aconselhamos que você siga as práticas recomendadas para a
otimização do desempenho da página
. Falando especificamente:
Elimine downloads desnecessários
Otimize a veiculação dos seus arquivos CSS e JavaScript
ao concatenar (mesclar) os arquivos separados, reduzir os arquivos concatenados e configurar seu servidor da Web para veicular arquivos compactados (geralmente com a compactação em gzip)
Verifique se o servidor pode lidar com o carregamento adicional da veiculação de arquivos JavaScript e CSS para o Googlebot.
Testar e solucionar problemas
Em conjunto com o lançamento da nossa indexação com base em renderização, também atualizamos o recurso
Buscar e renderizar como o Google
nas Ferramentas do Google para webmasters. Desse modo, os webmasters poderão ver como nossos sistemas renderizam a página. Com isso, será possível identificar uma série de problemas de indexação, como restrições de arquivos robots.txt impróprios, redirecionamentos que o Googlebot não consegue seguir, entre outros.
Como sempre, se você tiver comentários ou perguntas, acesse nosso
Fórum de ajuda para Webmasters
.
Escrito por Pierre Far, analista de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
Uma atualização da API das Ferramentas do Google para Webmasters
quarta-feira, 10 de setembro de 2014
Nível do webmaster: avançado
Durante o verão, a equipe das Ferramentas do Google para webmasters preparou uma atualização para a
API das Ferramentas do Google para Webmasters
. A nova API é consistente com outras APIs do Google, facilita a autenticação de serviços da Web ou de aplicativos e fornece acesso a alguns dos recursos principais das Ferramentas do Google para webmasters.
Se você já tiver usado outras APIs do Google, dar os primeiros passos com a nova Webmaster Tools API será fácil. Temos exemplos para
Python
,
Java
e
OACurl
(para os fãs de linhas de comando).
Essa API permite que você:
Liste, adicione ou remova sites da sua conta (no momento é possível ter até 500 sites na conta)
Liste, adicione ou remova Sitemaps dos seus sites
Tenha contagens de erros, avisos e indexados de Sitemaps individuais
Tenha uma série temporal de todos os tipos de erros de rastreamento para seu site
Liste amostras de tipos específicos de erros de rastreamento
Marque erros de rastreamento individuais como "corrigido". Isso não altera a forma de processamento dos erros, mas ajuda a simplificar a interface para você
Adoraríamos ver o que você está criando com nossas APIs. Fique à vontade para vincular seus projetos nos comentários abaixo. Além disso, caso você tenha dúvidas sobre o uso da API, sinta-se à vontade para postar sua pergunta no nosso
Fórum de ajuda para Webmasters
.
Postado por John Mueller, fã de longas linhas de comando, Google Zurich
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
Academia para Webmasters, agora disponível em 22 idiomas
segunda-feira, 8 de setembro de 2014
Hoje, a nova
Academia de webmasters
será disponibilizada em 22 idiomas,
incluíndo em português
. Os Webmasters novos ou iniciantes falantes de diversos idiomas agora poderão aprender os princípios básicos sobre como
criar um site incrível
,
proporcionar uma experiência agradável aos usuários
e
ter uma boa classificação nos resultados da pesquisa
. Se você já conhece esses tópicos, responda ao
questionário no final de cada módulo
para o comprovar! :)
Leia a Academia de webmasters no idioma que preferir e use os comentários ou o
Fórum de ajuda para Webmasters
para nos passar sua opinião. Recebemos comentários ótimos e úteis após o
lançamento da versão em inglês em Março
. Por isso, esperamos que este guia objetivo e fácil de ler possa ser proveitoso (e divertido) para todos.
Juntos, publicaremos conteúdo pesquisável e sites incríveis para todo o mundo.
Escrito por Mary Chen, Equipe de Webmaster Relations
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
Caixa de pesquisa aprimorada nos resultados da pesquisa
sexta-feira, 5 de setembro de 2014
Nível de webmaster: todos
Hoje você verá uma nova e aprimorada caixa de pesquisa de sitelinks. Quando exibida, ela tornará mais fácil aos usuários encontrar conteúdo específico no seu site, diretamente através das suas próprias páginas de pesquisa de site.
O que é esta caixa de pesquisa e quando ela aparece para meu site?
Quando os usuários pesquisam uma empresa pelo nome, por exemplo, [
Megadodo Publications
] ou [
Dunder Mifflin
], eles podem estar de fato procurando por algo específico nesse website. No passado, quando nossos algoritmos reconheciam isso, eles exibiam um conjunto maior de
sitelinks
e uma caixa de pesquisa adicional abaixo desse resultado da pesquisa. Isso levava os usuários a fazer
pesquisas do tipo "site:"
diretamente no site dos resultados. Por exemplo, [
site:example.com guias para caroneiros
].
Essa caixa de pesquisa agora está mais destacada (acima dos sitelinks), suporta o recurso Preenchimento Automático e, se você usar a marcação adequada, direcionará o usuário diretamente para as páginas de pesquisa do seu próprio website.
Como faço para marcar meu site?
Você precisa ter um mecanismo de pesquisa específico para sites funcionando no seu website. Se já tiver um, informe-nos marcando sua página inicial como uma entidade
schema.org/WebSite
com a propriedade
potentialAction
da marcação
schema.org/SearchAction
. É possível usar JSON LD, microdados ou RDFa para fazer isso. Confira todos os detalhes da implementação em nosso
site para desenvolvedores
.
Se você implementar a marcação no seu site, os usuários poderão pular diretamente da caixa de pesquisa de sitelinks para a de resultados de pesquisa do seu site. Se não encontrarmos marcação alguma, mostraremos a eles uma página de resultados de pesquisa para a consulta do tipo "site:" correspondente, como temos feito até o momento.
Como sempre, se você tiver dúvidas, fique à vontade para perguntar em nosso
Fórum de ajuda para Webmasters
.
Escrito por Mariya Moeva, analista de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Otimização da largura de banda no Apache e no Nginx
quinta-feira, 4 de setembro de 2014
Nível do webmaster: avançado
Todos desejam usar menos largura de banda: Os hosts querem contas mais baixas, os usuários de dispositivos móveis desejam ficar abaixo dos seus limites, e ninguém quer esperar por bytes desnecessários. A Web está cheia de oportunidades para economizar largura de banda: páginas veiculadas sem gzip, folhas de estilos, JavaScript veiculado não reduzido, e imagens não otimizadas, para citar algumas.
Então por que a Web já não está otimizada para largura de banda? Se essas economias são boas para todos, por que ainda não foram corrigidas? A maioria é bastante inconveniente. Os designers da Web são encorajados a "economizar para a Web" quando exportam suas ilustrações, mas nem sempre se lembram disso. Os programadores de JavaScript preferem não trabalhar com código reduzido porque isso torna a depuração mais difícil. É possível configurar um fluxo personalizado garantindo que cada uma dessas otimizações seja aplicada ao seu site todas as vezes como parte do processo de desenvolvimento ou de implantação. Contudo, isso é bastante trabalhoso.
Uma solução fácil para os usuários da Web é utilizar um proxy de otimização como o do
Google Chrome
. Quando os usuários aceitam esse serviço, o tráfego HTTP acontece por meio do proxy do Google, que otimiza o carregamento da página e reduz o uso da largura de banda em 50%. Ao mesmo tempo que isso é ótimo para esses usuários, é limitado para as pessoas usando o Google Chrome que ativam o recurso, e não consegue otimizar o tráfego HTTPS.
Com a
Otimização da largura de banda
, a equipe do PageSpeed está trazendo essa tecnologia para os webmasters. Assim, todos se beneficiarão: usuários de outros navegadores, sites seguros, usuários de computadores e proprietários de sites que desejam diminuir sua conta de tráfego de saída. Basta instalar o
módulo PageSpeed
no seu servidor Apache ou Nginx [1] e
ativar
a Otimização da largura de banda nas suas configurações, e o PageSpeed fará o restante.
Captura de tela da configuração
Se mais tarde você ficar interessado em otimizações mais avançadas do PageSpeed, desde
extensões de cache
e
inserção in-line
a
imagens de lazyload
e
delegação de JavaScript mais intensos
, basta ativá-las nas configurações do seu PageSpeed.
Saiba mais sobre a
instalação do PageSpeed
ou a
ativação da Otimização da largura de banda
.
Postado por Jeff Kaufman, Torne a Web rápida
Traduzido e publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Relations
[1] Se estiver usando um servidor de Web diferente, considere executar o PageSpeed em um proxy Apache ou Nginx. Tudo está em código aberto, com esforços de portabilidade em andamento para IIS, ATS e outros.
#NoHacked: uma campanha global para difundir a conscientização sobre atividades de hacker
terça-feira, 26 de agosto de 2014
No mês passado, apresentamos uma campanha social de uma semana chamada #NoHacked. Os objetivos da campanha #NoHacked eram conscientizar o público sobre os ataques de hackers e oferecer dicas sobre como manter os sites protegidos contra invasão.
Lançamos a campanha em 11 idiomas e em vários canais, incluindo
Google+
,
Twitter
e
Weibo
. Cerca de 1 milhão de pessoas visualizaram nossas dicas e centenas de usuários usaram a hashtag #NoHacked para difundir a conscientização e compartilhar suas próprias dicas. Confira abaixo as postagens compartilhadas durante a campanha:
g+
,
Twitter
g+
,
Twitter
g+
,
Twitter
g+
,
Twitter
Algumas das diversas dicas compartilhadas por usuários de todo o mundo:
Pablo Sílvio Esquivel , do Brasil, recomenda que os usuários não usem software pirata (
fonte
)
Rens Blom, da Holanda, sugere usar senhas diferentes para suas contas, alterá-las regularmente e usar uma camada extra de segurança, como a autenticação em duas etapas (
fonte
)
Дмитрий Комягин, da Rússia, sugere monitorar regularmente as origens do tráfego, consultas de pesquisa e páginas de destino, além de ficar atento a aumentos súbitos de tráfego (
fonte
)
工務店コンサルタント, do Japão, aconselha todos a escolher uma boa empresa de hospedagem especialista em problemas de atividades de hacker. Ele também sugere definir o encaminhamento de e-mails nas Ferramentas do Google para webmasters (
fonte
)
Kamil Guzdek defende a alteração do prefixo da tabela padrão em wp-config para um personalizado ao instalar um novo WordPress para reduzir o risco do banco de dados ser invadido (
fonte
)
As atividades de hacker ainda são um problema surpreendentemente comum em todo o mundo. Por isso, incentivamos todos os webmasters a seguir essas dicas úteis. Fique à vontade para continuar usando a hashtag #NoHacked para compartilhar suas dicas ou experiências de conscientização e prevenção contra atividades de hacker. Agradecemos seu apoio à campanha #NoHacked.
Caso seu site seja invadido por hackers, ajudaremos você para que a recuperação seja rápida e completa:
Realize estas etapas para a recuperação
Poste uma pergunta ou procure respostas no nosso Fórum de Ajuda
Postado pela equipe #NoHacked
HTTPS como um sinal de classificação
quinta-feira, 7 de agosto de 2014
Segurança é uma das prioridades para o Google. Investimos muito para garantir que nossos serviços tenham a segurança líder do setor, como
uma criptografia HTTPS forte por padrão
. Isso significa que quem usa a Pesquisa Google, o Gmail ou o Google Drive, por exemplo, tem automaticamente uma conexão segura com o Google.
Além de nossos próprios produtos, estamos trabalhando para tornar a Internet mais segura de maneira mais abrangente. Uma grande parte disso é garantir que os websites acessados por meio do Google sejam seguros. Por exemplo, criamos recursos para ajudar os webmasters a
evitar e corrigir violações de segurança em seus sites
.
Queremos ir além. Durante a
Google I/O
há alguns meses, falámos da importância de ter “
HTTPS everywhere
” na Web.
Vimos cada vez mais webmasters adotando o
HTTPS
(também conhecido como HTTP com
TLS
ou Transport Layer Security - em português Segurança da Camada de Transporte) em seus websites, o que é motivador.
Por essas razões, ao longo dos últimos meses, realizamos testes levando em consideração se os sites usam ou não conexões seguras e criptografadas como um sinal em nossos algoritmos de classificação de pesquisa. Observamos resultados positivos e, por esta razão, começaremos a usar HTTPS como sinal de classificação. Por enquanto, é um sinal sem muito impacto, que afeta menos de 1% das consultas globais e recebe um peso menor do que outros sinais, como conteúdo de alta qualidade. Fazemos isso para que os webmasters tenham tempo para mudar para HTTPS. No entanto, ao longo do tempo, podemos decidir fortalecer esse sinal, pois desejamos encorajar todos os proprietários de website a mudar de HTTP para HTTPS a fim de manter todos protegidos na Web.
Para facilitar a adoção do TLS e evitar erros comuns, publicámos na nossa Central de Ajuda o artigo "
Proteja seu site
", onde explicamos como funciona o HTTPs e quais as práticas recomendadas para sua implementação. Deixamos aqui também algumas dicas básicas para os primeiros passos:
Decida o tipo de certificado de que você precisa: único, de vários domínios ou curinga
Use certificados de chave de 2048 bits
Use URLs relativos para recursos que residem no mesmo domínio seguro
Use URLs relativos de protocolo em todos os outros domínios
Confira nosso
artigo sobre mudança de site
para mais diretrizes sobre como alterar o endereço do seu website
Não bloqueie o rastreamento do seu site HTTPS por meio do arquivo robots.txt
Permita a indexação das suas páginas por mecanismos de pesquisa sempre que possível. Evite a metatag "noindex".
Caso seu website já esteja veiculando em HTTPS, teste o nível e a configuração de segurança com a
ferramenta Qualys Lab.
Se você estiver preocupado com a TLS e o desempenho do seu site, consulte o artigo
Is TLS fast yet
? (somente em inglês). Se você tiver alguma pergunta ou preocupação, fique à vontade para perguntar no nosso
Fórum de ajuda para Webmasters
.
Esperamos ver mais websites usando HTTPS no futuro. Juntos, tornaremos a Web um lugar mais seguro.
Postado por
Zineb Ait Bahajji
e
Gary Illyes
, analistas de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Testar os arquivos robots.txt ficou mais fácil
quarta-feira, 16 de julho de 2014
Rastrear, ou não rastrear, eis a pergunta.
Às vezes, criar e manter os arquivos robots.txt corretos pode ser difícil. Embora muitos sites não tenham problemas com isso (dica: eles geralmente nem precisam de um arquivo robots.txt!), encontrar as diretivas em um grande arquivo robots.txt que estão ou estavam bloqueando URLs individuais, pode ser um pouco complicado. Para facilitar esse processo, anunciamos uma atualização na
ferramenta de teste de arquivos robots.txt
nas Ferramentas do Google para webmasters.
A ferramenta de teste atualizada está na seção Rastreamento das
Ferramentas do Google para webmasters
:
Aqui você encontrará o arquivo robots.txt e poderá testar os novos URLs para verificar se eles estarão desautorizados para rastrear. A fim de guiá-lo através das diretivas complexas, a ferramenta destacará a diretiva específica que levou à decisão final. É possível realizar alterações no arquivo e testá-las também. Para tal, basta fazer o upload da nova versão do arquivo com as alterações para o servidor para que elas entrem em vigor. Nosso site para desenvolvedores tem
mais informações sobre as diretivas do robots.txt e como os arquivos são processados
.
Além disso, será possível revisar as versões mais antigas do seu arquivo robots.txt e saber quando problemas de acesso nos impedem de fazer o rastreamento. Por exemplo, se o Googlebot verificar um erro de servidor 500 para o arquivo robots.txt, normalmento faremos uma pausa do rastreamento do site.
Já que é possível haver alguns erros ou alertas exibidos para seus sites existentes, recomendamos voltar a verificar seus arquivos robots.txt. Também é possível combinar esta nova funcionalidade com outras partes das Ferramentas do Google para webmasters. Por exemplo, é possível usar a
ferramenta Buscar como Google
, recentemente atualizada, para processar páginas importantes no seu website. Se for informado que qualquer URL foi bloqueado, use a ferramenta de teste de robots.txt para encontrar a diretiva que o está a bloquear e melhore o seu arquivo robots.txt. Um problema comum já visto ocorre a partir de arquivos robots.txt antigos que bloqueiam CSS, JavaScript ou conteúdo para celular. Corrigir esse problema é fácil após identificá-lo.
Esperamos que essa ferramenta atualizada facilite o teste e a manutenção do arquivo robots.txt. Em caso de dúvidas ou se precisar de ajuda para criar um bom conjunto de diretivas, passe no
fórum de ajuda para webmasters
.
Escrito por Asaph Arnon, Equipe de Webmaster Tools
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Solução de problemas com anotações hreflang nas Ferramentas do Google para webmasters
segunda-feira, 14 de julho de 2014
Se você segmenta usuários em mais de um país, provavelmente você já ouviu falar da anotação
rel-alternate-hreflang
. Em resumo, essa anotação permite ao Google e outros mecanismos de pesquisa veicular as páginas no idioma ou na versão regional correta, aumentando a satisfação dos usuários.
Verificar se as anotações implantadas podem ser utilizadas pelos mecanismos de pesquisa pode ser um tanto difícil, principalmente em sites com muitas páginas, e proprietários de sites em todo o mundo já nos relataram essa realidade. Hoje estamos lançando um recurso que deverá facilitar a depuração das anotações rel-alternate-hreflang.
A seção "Idioma de destino" na ferramenta
Segmentação internacional
permite que você identifique dois dos problemas mais comuns relacionados com anotações hreflang:
Tags de retorno ausentes
: as anotações precisam ser confirmadas a partir das páginas para as quais direcionam. Se a página A direcionar à página B, a página B precisará direcionar de volta à página A. Caso contrário, as anotações poderão não ser interpretadas corretamente.
Para cada erro desse tipo, relatamos onde e quando cada um desses erros foi detectado, assim como onde o tag de retorno deveria estar.
Valores incorretos de hreflang
: o valor do atributo hreflang precisa ser um código de idioma no formato
ISO 639-1
, como "pt", ou uma combinação de códigos de idioma e de país, como "pt-BR", em que o código do país esteja no formato
ISO 3166-1 Alpha 2
.
Caso nossos sistemas de indexação detectem códigos de idioma ou de país que não estejam nesses formatos, providenciaremos URLs de exemplo para ajudar você a corrigi-los.
Além disso, movemos as configurações de
segmentação geográfica
para esta seção das Ferramentas do Google para webmasters, de modo que você possa encontrar todas as informações relevantes sobre a segmentação internacional e multilíngue em um só lugar.
Esperamos que esse novo recurso seja útil e ajude você a identificar os problemas de implementação da marcação rel-hreflang no seu site. Se você tiver comentários ou dúvidas sobre este recurso, deixe uma postagem em nosso
Fórum de ajuda para Webmasters
.
Escrito por Gary Yves, Analista de Tendências para Webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Indexação de apps no Android, agora para todo mundo!
sexta-feira, 27 de junho de 2014
Nível do webmaster: todos
Além de seu site, você tem um aplicativo Android? Você agora pode conectar os dois para que os usuários que fazem pesquisas em seus smartphones e tablets possam encontrar e acessar o conteúdo de seu aplicativo com facilidade.
Links profundos de seus aplicativos nos resultados de pesquisa ajudam seus usuários a encontrar seu conteúdo mais facilmente e voltar a usar seu aplicativo depois de já o terem instalado. Como proprietário de site, você pode exibir a seus usuários o conteúdo certo, na hora certa. Conectando páginas de seu site às partes relevantes de seu aplicativo, você controla quando seus usuários são direcionados a seu aplicativo e quando vão para seu site.
Centenas de aplicativos já
implementaram a indexação de aplicativos
, como o Letras.mus.br ou o Viva Cupom. Esta semana no Google I/O, anunciamos um conjunto de novos recursos que tornarão ainda mais fácil configurar links profundos de seu aplicativo, conectar seu site a seu aplicativo e acompanhar o desempenho e erros potenciais.
É muito fácil começar
Simplificámos bastante o processo para indexar os links profundos de seus aplicativos. Se seu aplicativo é compatível com esquemas de links HTTP, você precisa:
1.
Adicionar o suporte a links profundos em seu aplicativo
2.
Conectar seu site a seu aplicativo
3. Não existe passo 3 :-)
À medida que indexamos seus URLs, descobriremos e indexaremos as conexões de aplicativos/site e podemos começar a exibir links profundos de aplicativos nos resultados de pesquisas.
Podemos descobrir e indexar os links profundos de seus aplicativos por conta própria, mas recomendamos que você publique os links profundos. Isso também vale se seu aplicativo é compatível com somente um esquema de links profundos. Existem duas maneiras para publicá-los:
Inserir um elemento rel=alternate <link> para especificar os URLs dos aplicativos. Poderá inseri-los na seção <head> de cada página Web ou no mapa de seu site Descubra
como implementar esses métodos
em nosso site do desenvolvedor.
Usar a
API indexadora de aplicativos
.
Mais uma coisa: adicionámos uma
nova funcionalidade nas Ferramentas do Google para webmasters
para ajudá-lo a depurar problemas que possam surgir durante a indexação das páginas dos aplicativos. Ele mostrará que tipo de erros detectámos para os pares página do aplicativo-página da Web, juntamente com URLs de aplicativos de exemplo, para que você possa realizar a depuração:
Também forneceremos instruções detalhadas sobre como depurar cada problema, incluindo um código QR para links profundos de aplicativos, para que você possa abri-los facilmente em seu celular ou tablet. Também enviaremos notificações de erros da Ferramenta do webmaster, para você ficar atualizado.
Teste a indexação de aplicativos e, como sempre, se precisar de mais ajuda, coloque suas perguntas no
Fórum de ajuda para Webmasters
.
Escrito por
Mariya Moeva
, analista de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Como criar uma página inicial apropriada para seus usuários internacionais
quarta-feira, 25 de junho de 2014
Nível do webmaster: avançado
Se você tiver negócios em mais de um país ou estiver segmentando diferentes idiomas, recomendamos que você tenha sites ou seções separadas com conteúdo próprio em cada URL destinado a países ou idiomas específicos. Por exemplo, uma página para os Estados Unidos e visitantes que falam inglês e uma página diferente para a França e usuários que falam francês. Apesar de termos disponíveis informações sobre o tratamento
de sites multirregionais e multilíngues
, a página inicial pode ser um pouco especial. Este post ajudará você a criar a página inicial adequada em seu website para veicular o conteúdo apropriado aos usuários dependendo do seu idioma e da sua localização.
Existem três maneiras de configurar a página inicial / página de destino quando seus usuários a acessarem:
Mostrar o mesmo conteúdo para todos.
Permitir que o usuário escolha.
Veicular o conteúdo dependendo da localização e do idioma do usuário.
Veja a seguir cada uma delas em detalhes.
Mostrar o mesmo conteúdo para os usuários ao redor do mundo
Neste cenário, você escolhe veicular o conteúdo específico para um determinado país e idioma na página inicial / no URL genérico (
http://www.example.
com
). Esse conteúdo estará disponível a todos que acessarem o URL diretamente no navegador ou para aqueles que pesquisarem esse URL especificamente. Como já foi dito, todas as versões de países e idiomas devem ser acessíveis por meio de um URL exclusivo.
Observação
:
é possível mostrar um banner na sua página para sugerir uma versão mais apropriada aos usuários de outras localizações ou com configurações diferentes de idioma.
Permitir que os usuários escolham qual versão local e idioma desejam
Nesta configuração, você escolhe veicular uma página do seletor de países na página inicial / no URL genérico e permite que os usuários escolham qual conteúdo desejam visualizar dependendo do seu país e idioma. Todos os usuários que digitarem esse URL acessarão a mesma página.
Se você implementar esse cenário no seu site internacional, use a
anotação x-default rel-alternate-hreflang para a página do seletor de países,
que foi criada especificamente para esse tipo de página. O valor x-default nos ajuda a reconhecer as páginas que não são específicas a um idioma ou uma região.
Redirecionar automaticamente os usuários ou veicular dinamicamente o conteúdo HTML apropriado, dependendo da localização dos usuários e das configurações de idioma
Um terceiro cenário seria veicular automaticamente o conteúdo HTML apropriado para seus usuários dependendo da localização e das configurações de idiomas deles. Você fará isso usando redirecionamentos 302 no servidor ou veiculando dinamicamente o conteúdo HTML apropriado.
Lembre-se de utilizar a anotação x-default rel-alternate-hreflang na página inicial / página genérica mesmo que esta seja uma página de redirecionamento que não pode ser acessada diretamente pelos usuários.
Observação
:
considere redirecionar os usuários para os quais você não tem uma versão específica. Por exemplo, os usuários que falam francês em um website que tem versões em português, inglês e espanhol. Mostre a eles o conteúdo que você considera mais apropriado.
Independente da configuração que você escolher utilizar, verifique se todas as páginas, inclusive as do seletor de países e idiomas:
Possuem
anotações rel-alternate-hreflang
.
Podem ser acessadas pelo rastreamento e pela indexação do Googlebot: não bloqueie o rastreamento e a indexação das suas páginas localizadas.
Permitem sempre que os usuários mudem a versão da localização ou o idioma: faça isso usando um menu suspenso, por exemplo.
Lembrete
:
como foi mencionado no início, é preciso que você tenha URLs separados para cada versão de país e idioma.
Sobre as anotações rel-alternate-hreflang
Anote todas as páginas, independentemente do método que você escolher. Isso ajudará os mecanismos de busca a mostrar os resultados certos aos seus usuários.
Todas as páginas do seletor de países e as páginas iniciais redirecionadas ou veiculadas de maneira dinâmica devem usar a
x-default hreflang
, que foi criada especificamente para redirecionar automaticamente as páginas iniciais e os seletores de países.
Por fim, seguem alguns lembretes úteis sobre as anotações rel-alternate-hreflang:
Suas anotações
precisam
ser confirmadas a partir de outras páginas. Se a página A levar à página B, será necessário que a página B leve de volta à página A. Caso contrário, suas anotações serão interpretadas incorretamente.
Suas anotações devem ser auto-referenciais. A página A deve usar a anotação rel-alternate-hreflang vinculando ela mesma.
É possível especificar as anotações rel-alternate-hreflang no cabeçalho de HTTP, na seção principal do HTML ou em um arquivo de Sitemap. Recomendamos que você escolha somente uma maneira para implementar as anotações a fim de evitar sinais inconsistentes e erros.
O valor do atributo hreflang precisa estar no formato
ISO 639-1
para o idioma e no formato
ISO 3166-1 Alpha 2
para a região. Especificar apenas a região não é compatível. Se você desejar configurar seu site para somente um país, use o recurso de segmentação geográfica nas
Ferramentas do Google para webmasters
.
Ao seguir essas recomendações, você nos ajudará a entender melhor seu conteúdo localizado e a veicular resultados mais relevantes aos seus usuários nos nossos resultados de pesquisa. Se você tiver dúvidas ou comentários, informe-nos no
Fórum de ajuda para Webmasters
.
Escrito por
Zineb Ait Bahajji
, Analista de tendências para webmasters
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Links não naturais em websites e pedidos de reconsideração
quarta-feira, 11 de junho de 2014
Nível do webmaster: todos
No passado e inclusive bastante recentemente, temos tomado 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. No mercado de língua portuguesa, temos visto muitos exemplos de links pagos passando
PageRank
em artigos de blogs.
Queremos aproveitar para relembrar que esquemas de links artificiais e técnicas de manipulação de PageRank e do posicionamento nos resultados de pesquisa não obedecem às nossas diretrizes de qualidade para webmasters. Por este motivo, continuaremos a tomar ações apropriadas para manter a qualidade e relevância do nosso índice - isto pode resultar num impacto negativo no posicionamento nos resultados de pesquisa dos sites que detectarmos estarem participando em
esquemas de links artificiais
.
Este post no blog tem como objetivo clarificar e relembrar que tipos de links são considerados pelo Google como prejudiciais para a reputação do seu site e seu classificação geral, e também o que deve fazer se verificar que foi aplicada uma ação manual ao seu site.
Que tipo de links podem ser considerados pelo Google como prejudiciais?
Links artificiais para seu site
A 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 PageRank com o objetivo de distorcer os resultados de pesquisa orgânica continuam sendo considerados uma infração às nossas
diretrizes de qualidade
. Publicámos recentemente 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 perceber melhor as nossas diretrizes referentes a links.
Para ilustrar um tipo específico de link pago, criámos o exemplo fictício que pode ver de seguida. No exemplo, repare que realçámos os
links com âncoras de texto super otimizadas
e assuma que estão configurados para passar PageRank.
Exemplo fictício de links pagos num artigo de um blog
No passado já comunicámos os nossos pensamentos sobre estratégias de comercialização de artigos através da venda de artigos. De facto, 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
onde o Matt Cutts fala sobre o que consideramos links pagos e não-naturais.
Recentemente o Matt publicou também no seu blog pessoal o artigo “
The decay and fall of guest blogging for SEO
", onde comentou a mudança que se tem dado nos últimos anos na natureza dos artigos "convidados" em blogs de terceiros. No artigo, ele comenta como estes 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 PageRank. Consequentemente, em vez de contribuírem com diferentes pontos de vista sobre os temas dos blogs onde são publicados, estes 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 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 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 estes posts possam ter sido criados sem más intenções por parte do dono do site, estes links específicos são uma violação das nossas diretrizes, pois foram criados com o único propósito de passar PageRank e manipular o posicionamento desses websites de terceiros nos resultados de pesquisa. O mesmo se passa com os widgets que contêm no código links otimizados que passam PageRank.
Criámos um widget fictional para ilustrar um modelo comum que encontrámos em blogs legítimos. Poderá reparar nos links embutidos no widget, que passam PageRank e logo não estão de acordo com as nossas diretrizes para webmasters. Neste 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 tem dúvidas sobre a qualidade dos links presentes no seu website, ou apontando ao 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 acredita que alguns dos links são suspeitos, é prática recomendada removê-los, colocar uma marcação "no-follow" nos mesmos, ou pedir a quem faz a gestão do seu site que o faça por si.
Se acreditar que um site específico utiliza técnicas que violam as nossas diretrizes para webmasters, ou se algum webmaster o contactar oferecendo uma troca de links, pode
efetuar uma denúncia de spam
, ajudando-nos assim a aumentar a qualidade dos resultados de pesquisa.
O que devo fazer se o meu site tiver uma ação manual?
Apesar do 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é removendo-os totalmente dos nossos resultados de pesquisa.
Se o seu site tiver sofrido uma ação manual, poderá ter acesso a esta informação na sua conta das
Ferramentas do Google para Webmasters
, na seção "Tráfego de pesquisa → Ações Manuais. Depois de ter tomado todas os passos para corrigir o problema mencionado, pode submeter um pedido de reconsideração. É importante que 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, isto significa contactar os webmasters dos websites onde estes links tenham sido colocados, e pedir-lhes para remover os links problemáticos. Em último recurso, se não conseguir que alguns destes links sejam removidos, pode usar a
ferramenta para rejeitar links
. Pode aceder a informação adicional sobre como usar esta ferramenta neste artigo de 2012, ou ainda na nossa lista de Perguntas Frequentes.
Se tiver links artificiais no seu site apontando para outro site, ou se tiver anúncios de texto com âncoras otimizadas que estejam passando PageRank, assegure-se que estes links são removidos, ou que contêm uma marcação "no-follow".
Em jeito de conclusão, deixamos um conselho simples para garantir que não está infringindo as diretrizes do Google:
não compre, venda, troque ou peça links
. Se seguir este conselho, a grande maioria dos links que o Google considera problemáticos não chegarão a ser criados
Se tiver mais questões ou dúvidas, pode colocá-las no nosso
Fórum de ajuda para Webmasters
.
Publicado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Campanha #NoHacked no Google+ contra invasão de websites
segunda-feira, 9 de junho de 2014
Nível do webmaster: todos
Esta semana estamos lançando no
Google+
uma campanha de conscientização contra a
invasão de websites
, com o objetivo de alertar para esse problema e partilhar conselhos sobre como manter o seu website protegido.
Apesar de desejarmos que isto não aconteça a ninguém, é surpreendentemente comum os sites serem invadidos - incluindo o seu! No Google achamos que está na hora de dizer BASTA e a melhor parte é que você pode ajudar-nos!
Participe nesta campanha e durante esta semana partilhe connosco no Google+ os métodos e técnicas que usa para proteger o seu site! Inclua o hashtag
#NoHacked
- no final selecionaremos e referenciaremos os melhores conselhos!
Traduzido e postado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Mover o seu site facilmente
sexta-feira, 6 de junho de 2014
Nível do webmaster: avançado
Poucos assuntos confundem e assustam mais os webmasters que as mudanças de sites. Para ajudar a evitar surpresas, criámos um guia detalhado sobre como lidar com as mudanças de sites de uma forma compatível com o Googlebot. O que exatamente é uma mudança de site e como fazê-la corretamente?
Exemplo da ferramenta para mudança de adereço (acessível no menu "definições -> Mudança de endereço")
Noções básicas das mudanças de sites
No geral, a mudança de site é um dos dois tipos de migração de conteúdo:
Mudanças de sites sem alterações do URL
. Somente a infraestrutura subjacente que veicula o site é alterada sem qualquer mudança visível na estrutura do URL. Por exemplo, é possível mover w
ww.example.com para um provedor de hospedagem diferente mantendo as mesmas estruturas de URLs e do site em www.example.com.
Mudanças de sites com alterações do URL
. Aqui, os URLs no site podem ser alterados de diversas formas:
O protocolo:
http://www.example.com
para
https://www.example.com
O nome de domínio: example.com para example.net
Os caminhos do URL: http://example.com/page.php?id=1 para
http://example.com/widget
Existem casos em que os webmasters implementaram mudanças de sites incorretamente ou omitiram etapas que teriam aumentado muito as chances da mudança de site ser bem-sucedida. Para ajudar os webmasters a projetarem e implementarem mudanças de sites corretamente, atualizmos as
diretrizes para a mudança de site
na nossa Central de Ajuda. Paralelamente, continuamos aprimorando nossos sistemas de rastreamento e indexação para detectar e lidar com mudanças de sites caso você siga nossas diretrizes.
Mudança para o design responsivo da Web
Uma questão relacionada cada vez mais comum é sobre como um site passa do uso de URLs diferentes para dispositivos móveis ou da veiculação dinâmica para o uso do design responsivo da Web. Para ajudar você a implementar essa alteração de configuração, consulte essa
nova página em nosso site de recomendações para smartphones
.
Como sempre, caso tenha dúvidas, não hesite em colocar suas perguntas em nosso
Fórum de ajuda para Webmasters
.
Escrito por Pierre Far e Zineb Ait Bahajji, Analistas de tendências para webmasters
Traduzido e postado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Indexação de aplicativos móveis como se fossem websites
quarta-feira, 4 de junho de 2014
Nível do webmaster: avançado
Lançámos recentemente uma nova funcionalidade do Google Search, chamada
Indexação de aplicativo móvel
, com o objetivo de que os links diretos para seus aplicativos de dispositivos móveis possam aparecer nos resultados da Pesquisa do Google no Android em qualquer lugar.
Com esta funcionalidade, o Googlebot agora consegue indexar conteúdo presente no seu aplicativo Android da mesma forma que rastreia e indexa as suas páginas Web. Os webmasters podem indicar o conteúdo do aplicativo móvel que o Google deve indexar tal como fazem para páginas Web - através do
Sitemaps
e através das
Ferramentas do Google para webmasters
. Se os conteúdo da página Web e aplicativo móvel forem indexados com sucesso, o iremos então tentar mostrar links diretos para o seu aplicativo nos resultados de pesquisa, sempre que consideremos que estes são relevantes para a busca do usuário, e caso o usuário tenha o aplicativo móvel instalado no seu dispositivo. Clicando em um destes links, o seu aplicativo será aberto e o usuário irá ser redirecionado diretamente para o conteúdo procurado. Na imagem seguinte pode ver um exemplo de uma busca por anúncios de alojamento em Mountain View:
Depois de em Abril termos oficialmente
lançado esta nova funcionalidade em inglês
(com mais de 20 aplicações suportadas), hoje temos o prazer de anunciar que adicionámos os primeiros editores que têm conteúdo em outros idiomas: Fairfax Domain, MercadoLibre, Letras.Mus.br, Vagalume, Idealo, L'Equipe, Player.fm, Upcoming, Au Feminin, Marmiton e chip.de. Também oferecemos suporte a mais aplicativos nos EUA: Walmart, Tapatalk e Fancy.
Adicionalmente, traduzimos as nossas
diretrizes para desenvolvedores
para outros oito idiomas:
chinês (tradicional)
,
francês
,
alemão
,
italiano
,
japonês
,
português brasileiro
,
russo
e
espanhol
.
Se você estiver interessado em participar da indexação de aplicativos e seu conteúdo e sua implementação estiverem prontos, informe-nos
preenchendo este formulário
.
Práticas recomendadas para adicionar links diretos para aplicativos móveis no seu Sitemaps ou website:
Links diretos para aplicativos móveis só devem ser adicionados para
URLs Web canônicos
.
Lembre-se de especificar um link direto para aplicativo móvel para a sua página inicial.
Nem todos os URLs Web incluídos num
Sitemaps
precisam de ter um link direto para aplicativo móvel correspondente. Não inclua links diretos para aplicacativos móveis que não sejam suportados pelo seu aplicativo.
Se tem um website de Notícias e usa um
Sitemaps do Google Notícias
, inclua os links diretos para aplicativos móveis no Sitemaps do Google Notícias e no Sitemaps geral do seu website.
Não inclua anotações para links diretos para aplicativos móveis que executem código nativo ARM. Isto permite que a indexação de apps funcione para todas as plataformas.
Quando o Google indexa conteúdo do seu aplicativo móvel, o seu aplicativo irá precisar de fazer as
solicitações HTTP
que faz em condições normais. Estas solicitações irão ser identificadas pelos seus servidores como originando do Googlebot. Por esta razão, o seu ficheiro
robots.txt
precisa estar configurado corretamente para permitir estas solicitações.
Finalmente, garanta que a funcionalidade "voltar atrás" do seu aplicativo redireciona os usuários de volta à página com os resultados da pesquisa.
Como sempre, é possível fazer perguntas no
Fórum de ajuda para Webmasters
.
Por fim, se você acessar o Google I/O em Junho, confira a seção "
Futuro dos aplicativos e da pesquisa
", na qual compartilharemos mais atualizações sobre a indexação de aplicativos.
Escrito por Michael Xu e
Erik Hendriks, Engenheiros de software, e por
Lawrence Chang
, GEstor de Produto
Traduzido e postado por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Renderizar páginas com a ferramenta "Buscar como o Google"
terça-feira, 27 de maio de 2014
Nível do webmaster: todos
A
ferramenta "Buscar como o Google"
nas
Ferramentas do Google para webmasters
fornece os resultados das tentativas do Googlebot buscar as páginas dos webmasters. O HTML e os cabeçalhos do servidor exibidos são úteis para diagnosticar problemas técnicos e efeitos colaterais de uma possível invasão do seu site, mas às vezes dificultam a verificação cuidadosa da resposta:
Preciso de ajuda! O que significam todos estes códigos? Esta é a mesma página que vejo no meu navegador? Onde iremos almoçar??
- Não podemos ajudar com a última pergunta, mas quanto ao restante, expandimos recentemente a ferramenta para que também mostre como o Googlebot poderia renderizar a página.
Visualizar a página renderizada
Para renderizar a página, o Googlebot tentará encontrar e buscar todos os arquivos externos envolvidos. Esses arquivos muitas vezes incluem imagens, CSS e JavaScript, assim como outros arquivos que podem estar indiretamente incorporados por meio de CSS ou de JavaScript. Eles são usados para renderizar uma imagem de visualização que mostra como o Googlebot vê a página.
É possível encontrar a
ferramenta "Buscar como o Google"
na seção "Rastreamento" das
Ferramentas do Google para webmasters
. Após enviar um URL com "Buscar e renderizar", aguarde o processamento. Isso pode levar alguns instantes em algumas páginas. Quando estiver pronto, basta clicar na linha de resposta para ver os resultados. Veja o seguinte exemplo:
Renderização da página do Google Analytics
Manusear recursos bloqueados pelo robots.txt
O Googlebot segue as
diretivas do robots.txt
em todos os arquivos que busca. Caso você desautorize o rastreamento de alguns desses arquivos (ou se eles estiverem incorporados a partir de um servidor de terceiros que esteja desautorizando o rastreamento deles pelo Googlebot), não poderemos exibi-los a você na visualização renderizada. Da mesma forma, se o servidor não responder ou retornar erros, também não poderemos usar os arquivos. Pode encontrar informações sobre problemas semelhantes na seção
Erros de rastreamento
das Ferramentas do Google para webmasters. Caso algum desses problemas ocorra, eles serão exibidos abaixo da imagem de visualização.
Recomendamos que você confira se o Googlebot pode acessar todos os recursos incorporados que contribuem significativamente para o conteúdo visível ou para o layout do seu site. Isso facilitará o uso do "Buscar como o Google" e possibilitará que o Googlebot encontre e indexe o conteúdo. Alguns tipos de conteúdo, como botões de mídia social, fontes e scripts de análise de websites, tendem a não contribuir significativamente para o conteúdo visível ou o layout e, assim, podem permanecer sem autorização para rastreamento. Para mais informações, veja nossa postagem anterior no blog sobre
como o Google está trabalhando para compreender melhor a Web
.
Esperamos que esta atualização facilite o diagnóstico desses tipos de problema e a descoberta de conteúdo bloqueado para rastreamento por engano. Caso você tenha dúvidas ou comentários, informe-nos aqui ou visite
Fórum de ajuda para Webmasters
.
Escrito by Shimi Salant, Equipe das Ferramentas do Google para webmasters
Traduzido por
Diogo Botelho
, Equipe de Search Quality e Webmaster Outreach
Marcadores
Academia para Webmasters
Accelerated Mobile Pages
ações manuais
AMP
Anúncios
API
aplicativos
avançado
botnet
bots
Buscar como o Google
Chrome
Chromium
cms
comunicação
comunidade webmaster
conteúdo duplicado
Contribuidores Principais
css
dados estruturados
desenvolvedores
design responsivo
diretrizes para webmasters
Discover
dispositivos móveis
engenharia social
erros de rastreamento
estrutura do website
experts em produtos
ferramentas e dispositivos
ferramentas para webmasters
Google Assistente
Google Home
Google notícias
Google+
Googlebot
guia SEO
hreflang
HTTPS
imagens
Imagens do Google
indexação de aplicativos móveis
iniciante
intersticiais
invasão de sites
javascript
Lighthouse
links
localização
malware
mudança de site
navegação segura
NoHacked3.0
pagespeed insights
phishing
preenchimento automático
prevenção
rastreio e indexação
reCaptcha
recomendações
reconsiderações
resultados de busca
resultados de pesquisa
rich cards
rich snippets
robots.txt
safe browsing
Search Console
segurança
SEO
sitemaps
TC Summit
url canônico
UX
velocidade
verificação
verificação em duas etapas
webspam
Arquivo do blog
2020
novembro
setembro
agosto
julho
junho
maio
abril
março
fevereiro
janeiro
2019
novembro
outubro
setembro
junho
maio
abril
março
fevereiro
janeiro
2018
dezembro
novembro
outubro
julho
junho
maio
abril
março
fevereiro
2017
dezembro
novembro
julho
junho
abril
março
2016
novembro
outubro
setembro
agosto
julho
junho
maio
abril
março
janeiro
2015
dezembro
novembro
outubro
setembro
agosto
julho
junho
maio
abril
março
janeiro
2014
novembro
Ajudar os usuários a encontrar páginas compatíveis...
outubro
Promover sites modernos para dispositivos modernos...
Atualização das nossas diretrizes técnicas para we...
setembro
Uma atualização da API das Ferramentas do Google p...
Academia para Webmasters, agora disponível em 22 i...
Caixa de pesquisa aprimorada nos resultados da pes...
Otimização da largura de banda no Apache e no Nginx
agosto
#NoHacked: uma campanha global para difundir a con...
HTTPS como um sinal de classificação
julho
Testar os arquivos robots.txt ficou mais fácil
Solução de problemas com anotações hreflang nas Fe...
junho
Indexação de apps no Android, agora para todo mundo!
Como criar uma página inicial apropriada para seus...
Links não naturais em websites e pedidos de recons...
Campanha #NoHacked no Google+ contra invasão de we...
Mover o seu site facilmente
Indexação de aplicativos móveis como se fossem web...
maio
Renderizar páginas com a ferramenta "Buscar como o...
abril
março
Feed
Recursos disponíveis para Webmasters:
Ferramentas do Google para Webmasters
Fórum de Ajuda para Webmasters
Central de Ajuda
Outros Artigos Publicados
Guia de Otimização para Webmasters Iniciantes
Perguntas Frequentes de Webmasters
.png)
.png)
.png)
.png)
