terça-feira, 25 de maio de 2010

Robots.txt - Ajudando os buscadores

Voltamos a mais um artigo sobre boas práticas de web.

O assunto de hoje não tem a ver diretamente com usuários, e sim com os buscadores: robots.txt

O que é?

O arquivo robots.txt é algo extremamente simples. De verdade. É um arquivo, com o nome "robots.txt", que deve ficar na raíz do site, e com um conteúdo similar a:

User-agent: *
Disallow: /img/
Disallow: /styles/
Disallow: /scripts/
Disallow: /busca.php

Explicação

Na primeira linha definimos o user-agent, que nada mais é que o nome do crawler. No caso especificamos *, curinga para todos os crawlers. Para saber melhor quais os nomes válidos, veja a lista completa.

Nas outras linhas temos Disallow, que é a dica de quais diretórios e arquivos não indexar. No caso acima, dizemos que todo o conteúdo dos diretórios img, scripts e styles não devem ser indexados, e que o arquivo /busca.php também não.

Outras opções

Existem várias outras opções que não fazem parte do padrão como
  • Allow - funciona como o disallow, mas ao invés de proibir, permite
  • Delay - diz qual o intervalo em segundos entre uma requisição e outra
  • Request-rate - que diz qual a taxa de requisições.
  • Visit-time - diz qual o melhor intervalo para visitação do crawler
  • Sitemap - diz onde está o sitemap xml do site.

O que usar?

É muito incomum ver nos robots.txt existentes, alguma diretiva que fuja do padrão (user-agent e disallow), com exceção da diretiva sitemap. Para os crawlers dos maiores buscadores (google, yahoo, bing, ask), o uso dessa diretiva é bastante útil, então o uso da diretiva sitemap é recomendado.

Considerações

Assim como o sitemap, a função do robots.txt é meramente informativa. O trabalho de indexação acontece de forma independente. Um badbot pode - e provavelmente irá - ignorar uma cláusula de disallow. Para evitar a indexação de informações privilegiadas, use o .htaccess.

Mas sem neuroses, a existência do robots.txt no seu site indica a preocupação em ajudar os crawlers na tarefa de indexação, e isso com certeza conta alguns pontos para uma melhor colocação do site. É mais poderoso ainda se você indicar um sitemap.

Exemplo final

User-agent: *
Disallow: /scripts/
Disallow: /styles/
Disallow: /private/
Disallow: /busca.php
Sitemap: http://www.seusite.com/sitemaps/sitemap.xml

Até a próxima.
----------- keepReading

segunda-feira, 24 de maio de 2010

Sitemaps -- Como fazer e o que fazer com eles

Fala pessoal, vamos continuar o assunto de boas práticas e de design voltado ao usuário que abordei nos dois últimos posts desse blog.

Os sitemaps são uma poderosa ferramenta de organização e SEO. Alguns buscadores aceitam que você envie o sitemap o seu site. Assim eles sabem exatamente o que indexar, ao invés de apenas ir navegando e filtrando. Outro lugar onde você pode fazer referência ao seu sitemap é no arquivo robots.txt (falaremos brevemente sobre esse arquivo num post futuro).

Isso sem contar que um sitemap em XML pode servir de base para que você crie seu sitemap HTML (seja server-side, ou com transformação XSLT).

Chega de papo. Vamos ao que interessa. Um arquivo sitemap é nada mais que um arquivo XML, com o seguinte formato:

O arquivo de sitemap

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
  <loc>http://www.example.com/</loc>
  <lastmod>2005-01-01</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
 </url>
</urlset>

Explicando cada tag.
urlset - é a raíz do arquivo. Só pode existir uma.
url - é usada para englobar as propriedade de cada página. Cada página do site precisa de um conjunto desses.
loc - é o endereço da página. Importante: esse endereço deve ser escapado. Mais detalhes abaixo.
lastmod - é a data da última modificação da página, no formato AAAA-MM-DD
changefreq - é a frequencia com que a página tem seu conteúdo atualizado (aceita os valores always, hourly, daily, weekly, monthly, yearly, never - sempre, horário, diário, semanal, mensal, anual, nunca respectivamente).
priority - define a prioridade da página em relação ao site. Os valores vão de 0.01 a 1.00

Explicações

As tags lastmod, changefreq e priority são opcionais. Note que o changefreq dá apenas uma indicação aos buscadores. Uma página marcada com always ou hourly pode ser indexada com uma frequencia menor do que isso. Uma página marcada com yearly, pode ser indexada mais de uma vez por ano. Ou seja, ela é apenas uma dica. A indexação de fato é feita pelos buscadores, e não há como garantir isso com precisão absoluta.

Para sites dinâmicos, criar o sitemap na mão pode ser bastante complicado. Então podemos criar um script que gere o sitemap. Eu criei um script rápido em PHP que faz isso.

Outra observação a ser feita é em relação ao uso da tag priority. Setar todas as páginas com prioridade 1.00 (mais importante) é uma tentação como todas as outras práticas de black hat SEO. Não faça isso!

Na dúvida deixe o valor 1.00 para a home, e outros valores mais baixos para outras páginas. Uma boa abordagem seria contar quantos níveis existem no path para cada página, e daí sim basear o valor de cada página. Por exemplo, para o endereço http://www.seusite.com.br/artigos /subcategoria/nome-do-artigo.html, vemos a seguinte estrutura:
0 - http://www.seusite.com.br/
1 - http://www.seusite.com.br/artigos/
2 - http://www.seusite.com.br/artigos/subcategoria/
3 - http://www.seusite.com.br/artigos/subcategoria/nome-do-artigo.html

Daí podemos fazer a seguinte associação de valores:
0 - 1.00
1 - 0.85
2 - 0.80
3 - 0.75

Ou mesmo inverter os dois últimos números, 0.80 e 0.75 (isso porque o conteúdo de um artigo geralment é mais importante do que o índice, mas uma seção de artigos é mais importante que um artigo sozinho).

Uma outra abordagem para calcular o valor da prioridade seria ver qual o real valor do conteúdo de cada página para o site. Vamos supor que você escreveu um artigo muito bom, ou tem uma página de produtos que atrai mais visitas que sua própria página inicial - em outros termos, você tem uma outra fonte de entrada muito boa no seu site.

É normal e aceitável que esta página tenha um valor de prioridade maior na indexação, podendo ser mesmo 1.00 (> 80% das visitas vindo por mecanismos de busca achem seu site por esta página).

Em suma: o bom senso deve imperar.

E o escaping das URLs?

Pra fechar, deixe-me falar sobre o valor da tag mais importante de cada URL, a tag loc.
O valor para esta tag que contém a URL deve ser uma URL escapada - com os carateres especiais codificados.

Por exemplo, a URL http://www.seusite.com.br/usuários/josé123 deverá ser escrita no sitemap como
http://www.seusite.com.br/usu%C3%A1rios/jos%C3%A9.

Esse resultado pode ser obtido pelo javascript, usando a função encodeURI(), ou no PHP, com a função encodeurl. Note que o PHP também faz o encoding dos caracteres especiais como ":" e "/".

No meu script há uma ligeira adaptação da função encodeURL. Eu uso a função encodeURL, e depois a str_replace para voltar os caracteres de controle ao normal.

Bom, isso é tudo. No próximo artigo, um tapa no robots.txt. Até lá.
----------- keepReading

sexta-feira, 21 de maio de 2010

Páginas de erro 404 úteis - Nos bastidores

No artigo passado sobre páginas de erro 404 úteis, vimos que existem possibilidades de sugestões e alternativas para ajudar pessoas e navegadores a encontrar o conteúdo que procuram.

Agora é hora de uma pitada técnica sobre os cabeçalhos HTTP envolvidos nesse processo, e como eles afetam sua página nos buscadores.

É de uso comum e corrente, que quando uma página não é encontrada, se faça um redirecionamento para uma página padrão, como a página de entrada. Como seguinte trecho de PHP:
<?php
header("Location http://www.seusite.com.br/");
?>

O problema dessa implementação é bem simples. Você envia junto com esse header Location, um cabeçalho HTTP 302 (Found).

Vamos supor que um indexador (googlebot, ou qqr outro) veja um link num outro site, apontando para o seu, mas com o endereço para uma página que não existe, e deveria lançar um erro 404 - porque ela não existe!

Sua manipulação com o simples header location, ou mesmo com um redirect 301 no .htaccess vai enviar o código errado, e o indexador vai entender essa página inexistente como uma existente. Pior, pode ser que ela indexe conteúdo duplicado (muitos links diferentes que apontam para uma mesma página). O que é uma má prática bad SEO.

Quando criar a sua página de erro para páginas não encontradas, SEMPRE se assegure que vai enviar o cabeçalho HTTP 404.

Em PHP o código é bem simples.
<?php
header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
?>
//código da página de erro amigável

Assim, você garante a correta indexação e a consistencia entre o seu sitemap XML, e as páginas válidas no seu site.

No próximo post: sitemaps.
----------- keepReading

Criando páginas 404 úteis

As famosas páginas de error 404 - Documento não encontrado são um saco. Ninguém gosta de clicar num link e ver uma página de erro, em branco asséptico, com a única opção de voltar ou ver se digitou errado (quando vc digita o endereço ainda vai, o problema é quando vc clica e cai numa página de erro.)

Bom, ninguém gosta dessas páginas. Nem os motores de busca. Mas o que fazer? Bom, é dever de quem faz web com qualidade, cuidar para providenciar alternativas amigáveis.
  • Sugestões
  • Mapa do site
  • Busca no site
Vamos por partes. E partir do pressuposto que você tem um mapa do site (sitemap). Ou melhor, dois. Um sitemap XML e um HTML. Num futuro proximo escreverei sobre Sitemaps. Por enquanto basta saber que é basicamente uma coleção de links que de fato existem e são válidos no seu site.

Agora mais uma suposição de uma página de conteúdo seu. http://www.seusite.com.br/viagens/recife.html

Esta sua página foi linkada ou enviada por algum amigo seu, por engano como http://www.seusite.com.br/viagens/reci

Isso mesmo, truncada. Quando alguém clicar, invariávelmente vai cair numa página de erro 404, porque essa página não existe. Aqui é onde os truques começam.

A forma mais simples de processar isso seria procurar entre os links que vc tem como válidos no seu sitemap (a versão XML é melhor para isso, por facilidade de implementação), um link que tenha o endereço informado como parte e sugerir esse(s), links.

Por exemplo,
Páginas mais próximas:
http://www.seusite.com.br/viagens/recife.html
http://www.seusite.com.br/viagens/recitais_em_gramado.html

Bem melhor, não? Ter alternativas válidas ao invés de uma mensagem de erro apenas.

Mas podemos melhorar ainda mais dando uma alternativa à raiz do diretório imediatamente anterior. No caso, o link para http://www.seusite.com.br/viagens/

Fora essas sigestões de links, nos restam como alternativas:
Oferecer o link para o sitemap em versão html, e oferecer uma busca no site.

http://www.seusite.com.br/mapa_do_site/



Como resultado final, se alguém clicar num link para http://www.seusite.com.br/viagens/reci vai ser levado às seguintes sugestões:

http://www.seusite.com.br/viagens/recife.html
http://www.seusite.com.br/viagens/recitais_em_gramado.html
http://www.seusite.com.br/viagens/
http://www.seusite.com.br/mapa_do_site/


Ótimo. Agora ao invés de ter uma página de erro que enche o saco, temos uma página de erro que ajuda as pessoas e os buscadores através de alternativas e sugestões.

Até o próximo artigo onde vou explicar uma parte mais técnica para a implementação.
----------- keepReading

sexta-feira, 14 de maio de 2010

Validações em PHP

Andei trabalhando bastante com web esses últimos tempos, e uma coisa que sempre consome muito tempo e neurônios é segurança em geral.

Até que eu encontrei uns artigos do Chris Shifflet. Todos artigos do cara são muito bons. Vale a pena dar uma lida com carinho.

Eu já havia lido algumas coisas publicadas por ele, mas apenas para Sessões PHP. Desta vez encontrei uma frase que mudou meu conceito de segurança em geral num artigo sobre XSS e CSRF.

"Instead of trying to predict what malicious data you want to reject, define your criteria for valid data, and force all input to abide by your guidelines."/cite>

Ou em português... "Ao invés de tentar adivinhar quais dados maliciosos você quer rejeitar, defina seu critério para dados válidos, e force todas entradas a obedecer suas regras.".

Isso não só me foi útil para definir critérios de validação de dados, mas também como design de software como um todo.

Aliado a boas práticas de outras áreas, isso se torna algo realmente valioso, pois economiza muitas e muitas linhas de código e neurônios.

----------- keepReading