HTTP/1.1 y SEO

Hace unos días, revisando unos temas de medio SEO, medio de infraestructura, medio de curiosidad (todo veía por unos problemas que teníamos en una web que no sabíamos que pasaba) me puse a leer un poco en diagonal el Hypertext Transfer Protocol – HTTP/1.1; sí, lo sé, geek power.

Total, que dándole una ojeada encontré algunas cosas que no creo que muchos sepan… y más que nada teniendo en cuenta lo importante que debería ser saber todo lo que acontece alrededor de algo como el protocolo HTTP.

Para comenzar a meternos en el tema tenemos los Protocol Parameters. No es que sea de mucha utilidad para alguien corriente, pero es interesante saber cómo «hablan» los servidores web con los navegadores, cómo se manda la información de idiomas, fechas y similares. De la misma forma tenemos cómo se mandan HTTP Message y cómo son los Request, aunque como digo, esto son meras formalidades ya que poco uso le vamos a dar. De la misma forma tenemos las Response, Entity, Connections (de las que se recomienda usar las Persistent Connections) y finalmente los Method Definitions (habitualmente usamos las GET y POST, pero hay otras tantas).

Cuando la cosa se empezó a poner divertida fue con los Status Code Definitions. Muchos los conocéis como «códigos web» del que, en SEO, de los que más se escucha es el 301 y el 404. Total, que me puse a leer algo más sobre esto ya que en las últimas semanas estaba viendo como algunos sitios de clientes hacían verdaderas barbaridades, y quería asegurarme de si eran ellos o era yo; ambos estábamos equivocados porque los SEO no se han mirado nada de esto.

Los códigos se dividen en:

• 1xx – Informational
• 2xx – Successful
• 3xx – Redirection
• 4xx – Client Error
• 5xx – Server Error

Seguramente muchos sabíais esto… o al menos se intuye… los 100 no se suelen ver (son internos entre servidor y navegador), el 200 es el habitual ya que normalmente cuando se llama a un fichero se devuelve eso. Los 300 son las redirecciones; los 400 son los problemas con la web en sí y los 500 los errores del servidor web.

Aquí es cuando me puse a leer e investigar un poco más (sobretodo me intrigaban los 300 y 400 que son los que más afectan a SEO). En los últimos tiempos he estado haciendo cambios en los clientes en cuanto a recomendaciones de 300, 400 y 500 se refiere, y ahora veréis el porqué. NOTA: hay muchos más códigos de los que voy a poner, pero he elegido estos por la trascendencia personal y profesional que me implican, que al final, este blog es «lo que yo quiero».

• 200 OK – Este es el código habitual cuando se devuelve una página. Es el «normal», así que poco a decir tengo.
• 204 No Content – Este código lo vi usar hace unos días en Google. No recuerdo exactamente cuándo, pero creo que es la forma en la que hacen las redirecciones a otras páginas desde sus resultados de búsqueda. El servidor devuelve una cabecera pero no devuelve «contenido».
• 301 Moved Permanently – Poco hay que decir de este caso. Es la forma en la que si tienes una página que «ya no exite» y tienes otra que la sustituye, con esto consigues que tanto usuario como buscador vayan a la nueva. En el caso del buscador «elimina» la URL vieja e indexa esta «nueva» URL.
• 302 Found – ¡Coño! ¿Found? ¿no era Redirect Temporaly? Pues sí, aquí está el secreto de porqué los buscadores «indexan» los 302 y es que, aunque se hace una redirección, la respuesta es «Found», o sea, que se ha encontrado y, por tanto, como la página se ha encontrado, se «toma prestado» el contenido de la página a la que se redirecciona y se «pone» también en la URL antigua. De ahí que genere contenidos duplicados un 302.
• 304 Not Modified – Este también es un clásico, sobretodo cuando hablamos de contenidos cacheados.
• 307 Temporary Redirect – ¡Anda! Si no es 302, ¡es 307! Sí, si lo que queremos es «distribuir» de forma aleatoria visitas, hay que utilizar un 307. Con este código (que personalmente no he probado con buscadores) se supone que la página original no se debería indexar, ni ella ni la de destino, ya que «cada vez» puede cambiar. Supongo que la de destino, si el buscador es listo, la indexará como una URL nueva, sin tener que ver de dónde viene.
• 403 Forbidden – El servidor entiende lo que se le está pidiendo, pero no quiere contestar nada. Es como un 404, pero «educado».
• 404 Not Found – Si no encuentro nada que hacer y no sé si lo volveré a encontrar, te contesto esto, pero que sepas que no tengo ni idea ni de porqué te estoy contestando esto. Es decir, que devolver un 404 y no devolver nada es casi lo mismo… el 404 es para administradores y programadores «vagos» que no controlan su sitio web.
• 410 Gone – La frase en inglés lo deja muy claro: «The requested resource is no longer available at the server and no forwarding address is known». Esto significa que lo que había aquí ya no está y no se sabe dónde está; traducido al idioma de los buscadores: «si tenías esto indexado, bórralo porque no existe y si existiera no sé donde está». Si hay que borrar algo de un buscador, es la respuesta perfecta.
• 503 Service Unavailable – Cuando hay una sobrecarga en la web hay que devolver este código. También significa que el servidor está en mantenimiento; esto significa que, si en algún momento hay que poner un mensaje de «Página en Mantenimiento» ha de ir acompañada de este código. Por cierto, este código siempre ha de ir acompañado de un «Retry-After» porque sino se comporta como un «500 Internal Server Error».

Otro de los capítulos que consideré interesantes (sólo por el título, y luego por lo que contenía) fue el de Caching in HTTP. Sabía que me serviría para aprender cómo devolver contenidos cacheados y así bajar el tiempo de respuesta y la carga del servidor web.

Para cachear y mantener una comunicación sobre esto se utiliza la cabecera «Cache-Control» y también los Entity-Tags (también conocidos como ETags). Otra cosa curiosa es que una caché ha de ser de mínimo 60 segundos, aunque este tiempo se considera un mínimo muy mínimo.

Para acabar otro de los grandes mundos que se tratan en el protocolo HTTP es el de los encabezados. Muchos conocemos el «Header Location» para las redirecciones, pero hay otros tantos que hay que tener en cuenta y que deberíamos saber cómo funcionan.

Hay uno, el «Accept» que es importante pero a la vez complejo y que creo que no aportaría mucho, por lo que no voy a entrar en él ahora. El siguiente es el «Accept-Charset», que este sí es importante. Básicamente es el que informa de la codificación de caracteres que va se puede leer.

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

El siguiente a tener en cuenta es el «Accept-Encoding». Este es importante porque le dice al navegador/buscador cómo puede contestar o qué puede solicitar de la web. En este caso lo más habitual es decirle que podemos enviar y recibir contenidos comprimidos, por poner uno de tantos.

Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

El siguiente es el «Accept-Language» que como él mismo indica es el que gestiona los idiomas del sitio.

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Uno de los importantes, como comentaba hace un rato, es el de «Cache-Control». Esta cabecera tiene muchísimas opciones, por lo que hay que darle una ojeada a cada una de ellas.

• public: puede cachearse en cualquier momento y lugar (habitualmente la caché del navegador).
• private: puede ser cacheado pero en una caché que sólo pueda leer el usuario que está accediendo en ese momento (no en una caché compartida).
• no-cache: no debe ser cacheado el documento.
• no-store: cuando una página se carga, se suele hacer una copia en el disco (ya esté cacheada o no)… con esto impides que se haga dicha copia.
• s-maxage: en cachés públicas, esta cabecera devuelve la edad máxima de la caché; además, si hay un proxy por algún lado, le obligará a no cachear.
• max-age: la edad de la página no puede ser mayor que la especificada en segundos.
• max-stale: se puede recibir información pero no después de los segundos que se indican.
• min-fresh: la página ha de refrescarse en no menos que el momento actual sumado los segundos.
• must-revalidate: aunque en algún lado se indique que hay que cachear, con esto forzamos a que las comunicaciones se hagan sin cacheos.

Otro de los elementos que hemos de ver es el «Content-Encoding», antes hemos visto lo que la comunicación acepta, y otra cosa es lo que la comunicación envía. El clásico ejemplo sería:

Content-Encoding: gzip

De la misma forma que antes veíamos lo que aceptaba en cuanto a idiomas, ahora le indicamos lo que vamos a enviarle como idioma con el «Content-Language». En el caso del SEO (y no SEO) es importante indicarle el idioma general en el que está hecha una web. Por eso es importante que un dominio no tenga parámetros de idioma o carpetas, porque esto se vuelve más complejo de gestionar (es más sencillo los subdominios o ccTLD).

Otro de los interesantes es el «Content-Type» que manda el tipo de documento y su codificación. Muchas veces esto se manda por un encabezado del HTML, pero debería ser el mismo que en el servidor. De esta forma, si lo mandamos por el servidor no hará falta que la web lo tenga que incluir en todos sitios.

Content-Type: text/html; charset=ISO-8859-4

Para cachear y demás hay que tener en cuenta el «Expires». Este encabezado lo que controla es la fecha máxima de caducidad que puede tener la página en cuestión, por lo que si se cachea, a partir de ese momento dejará de estarlo. En muchos casos, para indicar que una página no ha de cachearse, lo que se hace es enviar una fecha anterior al día y hora actuales. Así, cuando se recibe, ya se recibe como «caducada» (en lo que a caché se refiere).

Expires: Thu, 01 Dec 1994 16:00:00 GMT

De una forma similar al anterior, existe el «If-Modified-Since». Gracias a este se puede controlar cuándo una página ha variado o no. Con esto conseguimos que si está cacheado, el navegador le manda la fecha de la última actualización que tiene. Si el servidor ha cambiado la página, se la devuelve renovada. Si la página no ha cambiado, devuelve un 304 avisando que la página no ha variado y utiliza la que hay en caché reservando los recursos.

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Parecidos a estos anteriores tenemos el «If-Unmodified-Since» y el «Last-Modified» que indican también fechas con las que se puede trabajar y decidir si una página ha de llamarse del servidor o de la caché local.

El elemento que más se suele usar en SEO es el de «Location». Un detalle de este elemento es que la dirección URL que ha de incluirse siempre ha de ser una URL absoluta y no una URL relativa (aunque muchos navegadores la aceptan).

Location: http://javiercasares.com/

Para acabar (que ya falta menos) es interesante el «Referer». Básicamente cuando se navega de una página a otro, el navegador envía esta cabecera para informar de cuál era la página anterior (básicamente es la que permite luego ver datos en las estadísticas). También tenemos, para los códigos 503 el «Retry-After», al que pasados unos segundos, se le indica al buscador que ha de volver a visitar la web. Otro de los que habitualmente se usa para estadísticas y para detectar robots de búsqueda es el encabezado «User-Agent», que es el que indica que navegador utilizamos, qué version, o qué robot de búsqueda está visitando nuestro sitio web.

Y, ya sé que es un texto largo y pesado, pero ya se ha acabado. Como veis hay mucha planta y muchas cosas a tener en cuenta cuando se hace un sitio web, cuando se quiere comunicar el servidor con un navegador o con un buscador y sobretodo, cuando queremos hacer las cosas lo mejor posible.