Em 12 de fevereiro de 2009, o Google começou a suportar a tag link rel=”canonical”, que foi adotada posteriormente por Bing e Yahoo!, para especificar uma versão preferencial de uma URL. Essa situação se estendeu até 17 de junho de 2011, quando o Google anunciou o suporte para rel=canonical na forma de um cabeçalho HTTP, dando aos webmasters outro caminho para fornecer uma URL preferencial para content-types non-text/html, como os arquivos de PDF, que, de outra forma, eram incapazes de ter uma URL específica usando a tag link. Em retrospecto, essa notícia foi relativamente importante para os SEOs, ajudando a minimizar possíveis problemas de conteúdo duplicado, especialmente no rastro de penalidades contra os proprietários do site nos últimos anos.

Esse método não tradicional é subutilizado nos dias de hoje, e eu acredito que, agora mais do que nunca, os SEOs devem começar a potencializar e a levar em consideração o poder desse método para content-types non-text/html.

Há várias razões que explicam o porquê de o link header HTTP não ter tido muito sucesso na indústria de SEO:

• Os SEOs estão fortemente focados na consolidação da URL tradicional para content-types non-text/html.
• Cabeçalhos HTTP Canônicos são mais difíceis de implementar de forma dinâmica do que a tag link HTML.
• A implementação pode exigir acesso adicional, no qual privilégios podem ser limitados.
• A implementação pode exigir módulos adicionais do servidor para ser ativado ou instalado.
• A implementação pode criar erros do servidor facilmente, caso não seja tratada corretamente.

Para a maior parte, esses content-types non-text/html, especificamente arquivos PDF, adicionam conteúdo e valor aos sites. Eles podem ser rastreados, indexados, conter links que, quando compartilhados na web, atuam como link building natural, e passar PageRank. O link HTTP headers devem ser adicionados a esses content-types non-text/html quando forem aplicáveis.

Recentemente, eu estava fuçando a documentação do Apache e navegando em artigos diferentes para obter informações sobre uma implementação mais avançada. Fiquei surpreso ao perceber que não havia muitos métodos avançados ou tutoriais sobre como adicionar dinamicamente no HTTP header, e por isso estou trazendo isso para a comunidade.

Cabeçalhos HTTP usando PHP (types Text/HTML):

O cabeçalho HTTP rel=”canonical” pode ser adicionado facilmente a um content-types non-text/html que suporte PHP usando a função header(). Utilizar a sintaxe apropriada mostrada na documentação do Google juntamente com o PHP vai nos permitir fazer isso.

Adicionar essa função header() antes que qualquer HTML seja emitido acrescentará um link rel=”canonical” header HTTP para os cabeçalhos antes de serem enviados.

Isso minimiza a tag link rel=”canonical”. A única diferença é o envio da URI canônica preferencial usando um cabeçalho HTTP versus uma tag <link>. Tradicionalmente, a tag <link> tem sido de longe a escolha mais popular de implementação. Essa função, no entanto, será utilizada na seção avançada deste artigo.

Cabeçalhos HTTP usando .htaccess (types non-Text/HTML):

O cabeçalho HTTP pode ser modificado de uma forma relativamente fácil usando .htaccess para todos os content-types non-text/html, como arquivos PDF. Essa solução funciona muito bem para sites que tenham uma quantidade relativamente pequena de arquivos que você precisa adicionar o cabeçalho. Neste exemplo, vou mostrar um content-type application/pdf.

Esse trecho de código, quando implementado, adicionará um cabeçalho HTTP ao arquivo PDF apontando para uma página HTML com a URL de /page.html.

O argumento filename deve incluir um nome de arquivo, ou uma string wild-card, onde ? corresponde a qualquer caractere único, e * corresponde a qualquer sequência de caracteres.

As expressões regulares também podem ser utilizados, com a adição do caracter ~.

Implementação dinâmica avançada do cabeçalho HTTP (types non-Text/HTML):

A implementação dinâmica do cabeçalho HTTP para content-type application/pdf  que estou prestes a mostrar é mais avançada e requer conhecimento de .htaccess e PHP, embora eu vá dar os exemplos.

O primeiro passo é criar um arquivo php para controlar a saída do PDF. Isso pode facilmente ser feito reescrevendo uma URL.

Esse RewriteRule, quando adicionado a um arquivo .htaccess, simplesmente nos permite controlar o arquivo PDF a partir de um arquivo php chamado “pdf.php”. Sempre que um usuário ou um mecanismo de busca tenta acessar uma URL que contém a extensão de arquivo “. Pdf”, o arquivo pdf.php será referenciado para obter instruções sobre como exibir o arquivo. Isso nos dá a capacidade de executar a lógica condicional para adicionar um cabeçalho HTTP canônico.

Este trecho de código, quando adicionado a pdf.php, irá verificar se a URL do arquivo PDF existe. Se existir, podemos executar a lógica para adicionar no cabeçalho HTTP canônico, caso contrário, vamos querer retornar o arquivo como um 404.

Como você pode ver, a lógica condicional foi comentada e atualmente não funciona, embora este seja o lugar onde eu te deixo em boas mãos para criar a sua própria lógica com base em suas necessidades.

Por exemplo, você pode ter um arquivo csv ou txt que gostaria de ler. Esses arquivos podem conter uma lista de arquivos pdf e URLs correspondentes aos quais você gostaria de adicionar o cabeçalho HTTP. Você também pode ter tabela(s) ou coluna (s) de informações úteis em um banco de dados que você precisa referenciar para encontrar a URL correspondente para apontar para a URL preferencial. Existem inúmeras possibilidades.

É importante observar também os outros dois cabeçalhos adicionais acrescentados para content-type e content-length. São condições necessárias para uma saída adequada. Se não definir o content-type application/pdf, o arquivo será tratado como um arquivo de text/html.

Verifique seus cabeçalhos

Como você sabe se os cabeçalhos HTTP foram enviados? Verifique-os usando uma ferramenta. O WebDeveloper Toolbar para Firefox é uma ferramenta ótima não só para implementar cabeçalhos HTTP. Outra ferramenta que pode ser utilizada é Live Headers HTTP. Você também pode usar uma ferramenta de terceiros baseada na Web para ambientes de desenvolvimento que geralmente não são hospedados localmente.

Atenção

Eu recomendo que você teste quaisquer cabeçalhos HTTP dinâmicos usando .htaccess em um ambiente de desenvolvimento ou site local antes de colocar as mudanças no ar. Há possíveis erros que podem ocorrer, e isso também nos dá a chance de fazer um QA da implementação.

O que eu usei

• PHP
• Apache
• mod_rewrite enabled
• mod_headers enabled

Nota: Estes exemplos de script são muito minimalistas com o propósito de mostrar o código fundamental necessário para executar o método. Há muitas maneiras diferentes de adicionar a tag canonical na forma de um cabeçalho HTTP. Isso simplesmente mostra exemplos para usuários que executam servidores e frameworks mais usados. Windows rodando o IIS não usa .htaccess, a menos que as extensões de terceiros estejam habilitadas. Eles também são diferentes no que diz respeito à à diferenciação de maiúsculas e minúsculas utilizando file_exists() com PHP.

***

Este artigo é uma republicação feita com permissão. SEOMoz não tem qualquer afiliação com este site. O original está em: http://www.seomoz.org/blog/how-to-advanced-relcanonical-http-headers