Perguntas frequentes sobre AJAX

Quando preciso usar _escaped_fragment_ e quando usar #! nos URLs em AJAX?

O site precisa usar a sintaxe #! em todos os URLs que adotaram o esquema de rastreamento AJAX. O Googlebot não seguirá hyperlinks no formato _escaped_fragment_.

Onde eu vejo esse esquema em ação?

Veja uma amostra de aplicativo AJAX em http://gwt.google.com/samples/Showcase/Showcase.html. Ao clicar nos links à esquerda, é possível ver que o URL contém um fragmento hash #!, e o aplicativo navegará para o estado correspondente ao fragmento. Caso você mude o #! (por exemplo, http://gwt.google.com/samples/Showcase/Showcase.html#!CwRadioButton) para ?_escaped_fragment_= (por exemplo, http://gwt.google.com/samples/Showcase/Showcase.html?_escaped_fragment_=CwRadioButton), o site retornará um resumo em HTML.

O que acontece se #! não for implementado no site AJAX?

Suas páginas provavelmente não aparecerão nas páginas de resultados da pesquisa do Google. No entanto, estamos trabalhando continuamente para fazer o Googlebot se comportar mais como um navegador. Conforme os recursos exigidos pelo seu site são implementados, o Googlebot pode começar a indexar suas páginas de modo adequado, sem ajuda. No entanto, esse esquema de rastreamento de AJAX oferece uma solução para sites que já usam AJAX e querem garantir que seus conteúdos já sejam indexados adequadamente. Esperamos que seja uma boa solução para quem já tem instantâneos HTML de suas páginas ou para quem prefere usar um navegador sem cabeçalho para adquirir esses instantâneos HTML.

Com que frequência devo atualizar meu conteúdo?

A resposta para essa pergunta depende inteiramente da frequência de mudança do conteúdo de seus apps. Se forem alterados com frequência, você deve criar sempre um instantâneo HTML novo em resposta à solicitação do rastreador. Por outro lado, considere um arquivo de biblioteca em que o inventário não seja mudado regularmente. Para evitar que o servidor tenha que produzir os mesmos instantâneos HTML várias vezes, é possível criar todos os instantâneos HTML relevantes de uma vez, possivelmente off-line, e depois salvá-los para fins de futura referência. Também é possível responder ao Googlebot com um Código de status HTTP 304 (não modificado).

E se meu aplicativo não usar fragmentos hash?

Talvez ele devesse utilizar. Você acelera muito seu aplicativo usando fragmentos hash, porque eles são manipulados pelo navegador no lado do cliente e não fazem a página inteira ser atualizada. Além disso, eles permitem fazer um histórico de trabalho no seu aplicativo (o infame "botão de voltar do navegador"). Várias estruturas AJAX oferecem suporte para fragmentos hash. Por exemplo, acesse os sites (em inglês) Histórico superfácil, histórico de plug-in de jQuery, histórico de mecanismo do Google Web Toolkit ou o suporte para histórico de gerenciamento do ASP.NET AJAX.

No entanto, se não for viável estruturar o app para usar fragmentos hash, é possível usar um token especial neles (ou seja, todo o trecho a partir do sinal # de um URL). Os fragmentos hash que representam estados de página únicos precisam começar com um ponto de exclamação. Por exemplo, se o app AJAX tiver um URL como este:

www.example.com/ajax.html#mystate

Ele deverá ficar assim:

www.example.com/ajax.html#!mystate

Quando seu site adotar o esquema, ele será considerado "AJAX rastreável". Isso significa que o rastreador verá o conteúdo do app se o site fornecer resumos HTML.

Essa abordagem levará a uma proliferação de URLs feios com _escaped_fragment_?

A sintaxe _escaped_fragment_ para URLs é um URL temporário que nunca será visto pelo usuário final. Em todos os contextos que serão exibidos ao usuário, o URL belo (com #! em vez de _escaped_fragment_) deverá ser usado: na interação normal do app, nos sitemaps, em hiperlinks, em redirecionamentos e em outra situação que o URL fique visível. Pelo mesmo motivo, os resultados de pesquisa são URLs belos em vezes de URLs feios.

Este esquema abre as portas para as técnicas de cloaking?

As técnicas de cloaking consistem em exibir para os usuários conteúdo diferente do exibido nos mecanismos de pesquisa. Geralmente, isso é feito com a intenção de melhorar a classificação nos resultados de pesquisa. As técnicas de cloaking sempre foram (e sempre serão) questões importantes para os mecanismos de pesquisa. É importante observar que fazer os aplicativos em AJAX rastreáveis não é, de maneira alguma, um convite para facilitar as técnicas de cloaking. Por esse motivo, o instantâneo HTML precisa ter o mesmo conteúdo que o usuário final veria em um navegador. Se esse não for o caso, podem ter ocorrido técnicas de cloaking. Veja a resposta para saber mais detalhes.

Posso usar esse esquema para tornar meu Flash ou meus outros arquivos rich media mais rastreáveis?

O Google indexa muitos tipos de arquivo rich media, e estamos sempre trabalhando para aprimorar nosso rastreamento e nossa indexação. No entanto, talvez o Googlebot não veja todo o conteúdo de um Flash ou de outro aplicativo rich media (da mesma forma que ele não pode rastrear todo o conteúdo dinâmico no seu site). Dessa forma, pode ser útil usar esse esquema para fornecer conteúdo adicional ao Googlebot. Por esse motivo, o instantâneo HTML deve ter o mesmo conteúdo que o usuário final veria em um navegador. O Google reserva-se o direito de excluir do índice os sites suspeitos de utilizar técnicas de cloaking.

E se meu site tiver alguns URLs com fragmentos hash que não devem ser rastreados?

Quando seu site adotar o esquema de rastreamento AJAX, o rastreador do Google rastreará todos os URLs com fragmento hash que encontrar. Se você tiver URLs com fragmento hash que não devem ser rastreados, sugerimos adicionar uma diretiva de expressão regular para o arquivo robots.txt. Por exemplo, é possível usar uma convenção nos fragmentos hash que não devem ser rastreados e depois excluir todos os URLs que correspondem a ela no arquivo robots.txt. Suponha que todos os estados não indexáveis sejam do formato #DONOTCRAWLmyfragment. Você poderia evitar que o Googlebot rastreasse essas páginas adicionando o seguinte ao robots.txt:

Disallow: /*_escaped_fragment_=DONOTCRAWL

E os usos atuais de #! em fragmentos hash?

#! é um token usado raramente nos fragmentos hash atuais. No entanto, ele não é proibido pela especificação de URL. O que acontece se o aplicativo usar #!, mas não quiser adotar o novo esquema de rastreamento AJAX? Uma abordagem possível é adicionar uma diretiva em seu robots.txt para indicar isso ao rastreador.

Disallow: /*_escaped_fragment_

Isso significa que, se o aplicativo tiver somente o URL www.example.com/index.html#!mystate, esse URL não será rastreado. Caso seu aplicativo também tenha o URL básico www.example.com/ajax.html, esse URL será rastreado.

E quanto à acessibilidade?

Um efeito colateral da prática atual de fornecer conteúdo estático para os mecanismos de pesquisa é que os proprietários de sites tornaram os aplicativos mais acessíveis aos usuários com deficiência. O novo contrato leva a acessibilidade para um novo nível: sem intervenção manual, os proprietários de sites podem usar um navegador headless para criar resumos HTML que tenham conteúdo relevante e sejam utilizáveis por leitores de tela. Isso significa que agora é mais fácil manter o conteúdo estático atualizado, já que menos trabalho manual é exigido. Em outras palavras, os proprietários de sites agora têm um incentivo ainda maior para tornar os aplicativos acessíveis às pessoas com deficiência.

Como devo usar rel="canonical"?

Use <link rel="canonical" href="http://example.com/ajax.html#!foo=123" /> (e não <link rel="canonical" href="http://example.com/ajax.html?_escaped_fragment_=foo=123" />).

Qual URL devo incluir no meu sitemap?

O sitemap precisa incluir a versão preferencial para exibição nos resultados da pesquisa, então precisa ser http://example.com/ajax.html#!foo=123.

Como os URLs #! afetarão os feeds de produtos?

É comum querer que os sites tenham os mesmos URLs para o Google Shopping e a Pesquisa Google na Web. Geralmente, a versão #! do URL precisa ser tratada como a versão "canônica" a ser usada em todos os contextos. O URL _escaped_fragment_ é considerado um URL temporário que não deve ser visível aos usuários finais.

Uso o HtmlUnit como navegador headless e ele não funciona. Por que não?

Se "não estiver funcionando" significar que o HtmlUnit não retorna o instantâneo que você esperava ver, é provável que você não tenha esperado tempo suficiente para que ele executasse as solicitações JavaScript e/ou XHR. Para resolver isso, tente uma ou todas as recomendações a seguir:

  • Use NicelyResynchronizingAJAXController. Isso fará o HtmlUnit esperar pelas chamadas XHR pendentes.
  • Aumente o tempo de espera para waitForBackgroundJavaScript e/ou waitForBackgroundJavaScriptStartingBefore.

Isso provavelmente resolverá o problema. Caso não resolva, veja as Perguntas frequentes sobre HtmlUnit aqui: http://htmlunit.sourceforge.net/faq.html. O HtmlUnit também tem um fórum do usuário.