Cuando un malware te fastidia el SEO

Hace unas semanas nos dimos cuenta de que, en un proyecto, había subido de golpe el tráfico. pensábamos que la caída de agosto era la tradicional caída veraniega, pero no, nos habíamos equivocado.

La vedad es que no nos habíamos dado cuenta de nada hasta que mirando la estadísticas vimos que había muchísimo tráfico desde Rusia. Esto era bastante extraño ya que el sitio web está en español. Investigando un poco detecté que al final del código fuente de todas las páginas había un script extraño…

Cuando me dispuse a bajarme el fichero por FTP vi que con el index.php saltaba el antivirus. Tras investigar, efectivamente habían colado, aún no tengo muy claro cómo, un script/virus en las páginas. Eso sí, el script (la URL a la que llamaba) había dejado de funcionar… y pocos días después el tráfico volvía a la normalidad.

Geolocaliza Google a tu gusto

Hace unos días os comentaba cómo llegar al corazón de Google de forma que pudiéramos eliminar cualquier personalización de los resultado del buscador. Básicamente se trataba de jugar con algunos parámetros que eliminaban personalizaciones, filtros, etc.

También os comenté que era posible, mediante parámetros, llegar a mostrar resultados basándolos en un idioma y un país, aunque sin más geolocalización que esta, pero ¿y si pudiéramos geolocalizar los resultados por provincia? Pues sí, es posible.

Como decía en la entrada anterior, es muy habitual que gente que navega por una misma oficina vea resultados distintos en una misma búsqueda, y muchas veces nos preguntamos que, si eso ya pasa en una misma ciudad, qué estarán viendo los usuarios de otras parte del país. Y hoy voy a explicar que es posible ver los resultados (sobretodo los que implican geolocalización) simplemente jugando con un par de parámetros más. De todas formas, esto es aplicable a algunos países con más o menos detalle, y en otros directamente no se puede. De todas formas, aunque esto en teoría es así, en la realidad Google lo utiliza principalmente para geolocalizar la publicidad.

La dirección base a llamar sería tal que:

http://www.google.com/search?pws=0&gf=0&filter=0&hl=es&gl=es&q=#busqueda#

El parámetro gl es el que indica el país desde el que se vería la consulta. La lista de países suele coincidir bastante con las extensiones de dominio.

Tras filtrar por país, el siguiente paso sería el de filtrar por provincia o región (según el país). Para ello usaremos algo tal que:

http://www.google.com/search?pws=0&gf=0&filter=0&hl=es&gl=es&gr=es-b&q=#busqueda#

La lista de provincias y regiones es una lista un poco extraña. En España podemos encontrar cosas como Cataluña (es-ct) o Barcelona (es-b), pero no Girona.

El siguiente punto es a nivel ciudad. De la misma forma que nos encontramos regiones y provincias extrañas en España, a nivel ciudad o población nos encontramos cosas aún más. Un ejemplo de dirección URL sería esta:

http://www.google.com/search?pws=0&gf=0&filter=0&hl=es&gl=es&gr=es-b&gcs=Badalona&q=#busqueda#

Existen dos listados para diferenciar las poblaciones a nivel Estados Unidos y a nivel mundial. La lista de Estados Unidos es mucho más acertada que la del resto de países.

Un caso más concreto sería el de algún punto de Estados Unidos, en el que se puede indicar el “metro code“, un número que identifica muy concretamente regiones. En este caso la dirección sería tal que así:

http://www.google.com/search?pws=0&gf=0&filter=0&hl=en&gl=us&gr=us-fl&gcs=Miami+Beach&gpc=528&q=#busqueda#

La lista de zonas está disponible tanto en la lista de poblaciones como en una lista genérica de zonas.

Kisshost, ampliando al negocio del hosting

Una de las cosas que más me gusta de trabajar con mucha gente y muy variada es que poco a poco van saliendo negocios a partir de, llamémoslo así, hobbies. Y es que desde hace muchos años el sector del alojamiento web es algo que me ha perseguido, tanto por darle servicio a colegas y demás, como el yo tener que buscarme la vida.

Hace muchos años comencé con sitios gratuitos, pasé por hosting compartido de sitios conocidos en España y luego de Estados Unidos, eso me llevó a tener servidores dedicados, hasta que finalmente acabé volviendo a tener máquinas en Barcelona.

Desde hace unos meses que Kisslab a parte de hacer SEO y demás, también comenzamos a dar a algunas personas cercanas o que nos consultaban alojamiento en forma de Linux compartido o de VPS (servidores virtuales). Poco a poco esto empezó a hacerse un poco grande y finalmente un concepto (internamente llamábamos así a esa línea de negocio) tal que Kisshost que básicamente son los servicios que ofrecemos a nivel de alojamiento web.

Lo hemos dividido todo en 2 vías: Servidores Virtuales y Linux Compartido. Lo primero es más profesional (básicamente son VPS con acceso de root, por lo que cada uno hace lo que quiere en ellos) y lo segundo es más para gente que tiene webs pequeñas o blogs y similares. Además, creo que los precios son muy buenos y la calidad del servicio ya os digo que es excepcional… además, si alguien necesita ayuda o tiene problemas ya hemos solventado más de una vez alguna situación en cuanto a rendimientos y consejos sobre la optimización de las máquinas, que Rubén Ortiz y David Toribio nos dan.

Espero que antes de irme a Estados Unidos hayamos acabado algunos proyectos nuevos y los pueda comentar. Uno de ellos creo que va a romper el mercado con los precios y servicios que ofreceremos.

Cuándo cambiar a IPv6

A lo largo de este 2010 se está hablando bastante sobre el fin de las direcciones IPv4. La verdad es que hay algo de cierto en ello… se están acabando los rangos de IP no asignados, pero eso no significa que se estén acabando las direcciones IP. Además, hay una serie de clases A reservadas para cuando llegue ese momento, de forma que IANA y compañía en último extremo tendrá una serie de IP que podrá dar en casos extremos. ¿Qué significa esto? Pues básicamente que hay muchas direcciones de las 4.294.967.296 posibles que no se están utilizando (en su día se dieron rangos enteros a empresas y países, que nunca se llegarán a usar) algo que va a forzar el cambio a las direcciones IPv6.

El cambio de IPv4 a IPv6 básicamente lo que permite es cambiar a 340 sextillones de direcciones IP, habiéndose saltado el IPv5, que planteaba como dos sistemas, el IP y el ST (para streaming principalmente), pero que sólo ha quedado para pruebas internas. Otra de las cosas interesantes es que IPv6 reduce significativamente los encabezados de datos, lo que significa que debería aumentar la velocidad de la transmisión de datos.

¿Cuándo veremos direcciones IPv6? Pues básicamente cuando los proveedores de conectividad lo decidan. Desde el punto de vista de un centro de datos se puede plantear hacer un NAS de direcciones IPv4 a IPv6 y viceversa, aunque es un poco rollo. Lo ideal sería que Telefónica dijera que a partir del día X las direcciones IP serán IPv6, creo que el resto de operadores iría detrás y los proveedores de servicios (tipo hosting) también harían los cambios.

Además, hay sitios en la red como Google que ya están preparados para esta nueva versión. recuerdo que hace un par de años lanzaron una primera fase a través de la dirección ipv6.google.com (sólo accesible por IPv6) pero que ahora ya han adaptado la mayoría de sus servicios (Google search, Alerts, Docs, Sites, Finance, Gmail, Health, iGoogle, News, Reader, Picasa Web Albums, Maps, YouTube y App Engine) a este nuevo protocolo.

En el corazón de Google

Siempre hay alguien que te dice que aparece muy bien posicionado en Google. En esos momentos abres tú, haces la consulta y no lo ves tan bien como él dice. Esto me lo he encontrado en innumerables ocasiones en los últimos años, y la verdad es que ya no se cómo explicarle a clientes y no clientes que Google les muestra lo que quieren ver, que les dice lo que quieren oir. Claro está, esto lo hace si hay un mínimo de SEO, porque si estás penalizado o algo parecido, ya da igual lo que tú, él o Google diga.

Es un poco lo mismo que me encuentro cuando alguien dice que no hay contenidos duplicados en su sitio web… haces una búsqueda genérica que lleva el parámetro site:, aparece el mensajito ese de “que se han eliminado resultados parecidos” y poco más a decir…

¿Cómo detectar problemas SEO? Una pregunta que en alguna ocasión he comentado y que cada vez es más complejo de contestar. Está claro que una forma es intentar ver el corazón de Google, el índice principal, primario, sin filtros, sin países, sin idiomas…

Para empezar, lo primero que hemos de hacer es activar el sistema que impide un cambio de “país”, es decir, que si entras en google.com te acaba mandando a google.es. Para ello hay que visitar al menos una vez la página de Google No Country Redirect. Con esto podremos entrar en el Google Principal y dejarlo sin filtrados.

Una vez tengamos esto, el siguiente paso es eliminar restricciones básicas: la personalización y el límite de dos URL por sitio web. Para ello usaremos una dirección tal que así:

http://www.google.com/search?pws=0&gf=0&filter=0&q=#CONSULTA#

Con esto conseguimos varias cosas:

  • pws=0: eliminamos la personalización basada en el usuario, su cuenta, su cookie o sus últimas consultas.
  • gf=0: eliminamos el “site clustering”.
  • filter=0: eliminamos el límite de N resultados por sitio web.

En este momento tenemos la información casi purificada de los resultados de búsqueda. Ahora sólo queda la geolocalización. Hay que partir de la base de que la gente, por norma general, no filtra los resultados por idioma, pero sí que hace búsquedas en su Google de País. ¿Cómo asignarle ahora un país? Pues también se puede hacer de una forma sencilla:

http://www.google.com/search?pws=0&gf=0&filter=0&hl=es&gl=es&q=#CONSULTA#

Con esto conseguiremos cambiar idiomas y países:

  • hl=es: este parámetro en teoría lo podemos eliminar, porque básicamente lo que hace es cambiar la interfaz de Google, pero no afecta a los resultados de búsqueda.
  • gl=es: en este caso indicamos el país al que aplicar el índice; en este caso es “es” haría referencia a google.es, por lo que veremos los resultados según Google España; si pusieramos el “ar” veríamos los datos según Google Argentina.

Otra posibilidad a aplicar es la del famoso filtro SafeSearch. Este filtro se aplica para controlar los contenidos para adultos o “potencialmente peligrosos”. De esta forma añadiríamos el parámetro tal que:

  • safe=off: eliminamos el filtrado.
  • safe=active: activamos el filtrado.

Ahora es más sencillo encontrar porqué a veces los resultados de Google son tan distintos entre dos personas que están en una misma oficina, en una misma ciudad, en un mismo país…

Cómo cargar JavaScript

Como ya he comentado alguna otra vez, el JavaScript es uno de los elementos que bloquean la carga de los sitios web. Para evitar este bloqueo podemos usar algunos métodos creados con otro código de JavaScript que nos servirá para cualquier fichero externo que queramos cargar.

Lo bueno de estos sistemas es que permiten cargar en el sistema no sólo JavaScript sino que se podría abrir hasta CSS. Los códigos son bastante sencillos:

function loadScript(url, callback){
  var script = document.createElement("script")
  script.type = "text/javascript";
  if (script.readyState){ // Internet Explorer
    script.onreadystatechange = function(){
      if (script.readyState == "loaded" || script.readyState == "complete") {
        script.onreadystatechange = null;
        callback();
      }
    };
  } else { // Otros navegadores
    script.onload = function(){
    callback();
  };
}
script.src = url;
document.getElementsByTagName("head")[0].appendChild(script);
}

Con esta función podemos cargar un script dentro del elemento head. Y con lo siguiente hacemos la llamada desde el código en el momento que queramos:

<script type="text/javascript" src="http://www.loquesea.ext/funcion.js"></script>
<script type="text/javascript">
loadScript("http://www.loquesea.ext/fichero1.js", function(){ });
loadScript("http://www.loquesea.ext/fichero2.js", function(){ });
</script>

Peligro SEO: no tocar

Una de las cosas que hay que hacer cuando se aplican técnicas SEO a un sitio web es dejar que reposen. Por norma general, Google, en un sitio de tamaño mediano reindexa completamente todo cada 3 meses, que es el ciclo natural del motor, de forma que, cuando se hacen cambios medianos o grandes en un sitio es muy recomendable esperar estos 3 meses para comprobar la aplicación completa.

¿Y por qué hay que esperar? Porque aunque a los buscadores les gustan determinados cambios, algo que más les gusta es que se hagan cambios para bien, ya que cualquier cagada te hunde en la miseria. Un cambio bueno hace que el tráfico aumente poco a poco, pero un error en el desarrollo te puede tirar el 90% del tráfico si no lo tratas correctamente.

Hace unos años una persona que considero un grande se los SEO nos comentó a los presentes que una de las cosas que hacía siempre él era el paso a producción. Y que lo seguía haciendo él porque siempre había alguien que tocaba algo, y que “tocar algo” era una de las cosas que no se podría permitir. Básicamente lo que le pedía al proyecto era que fuera consistente, a prueba de errores graves técnicos.

¿Qué cosas tenía más en cuenta esta persona? Bueno, en aquel momento no había mucho de que hablar, pero comentaba cosas tipo los robots.txt. ¿Qué cosas miraría hoy? Hay varias cosas con la que tener bastante cuidado: Redirecciones 301, XML Sitemaps, Meta-Canonical. Teniendo estas cosas presentes es muy probable que no existan contenidos duplicados ni URL raras.

Otro detalle importante es el del alojamiento web y la conectividad. Ahora que veo todo el sistema de alojamiento desde la perspectiva que te puede dar un Centro de Datos como Digital Parks o los servicios de alojamiento web que estamos dando a clientes, una de las bases principales es que las máquinas siempre estén encendidas y disponibles.

Uno de los grandes problemas que se suele tener en los grandes proyectos es precisamente esto… mucha gente toca el código y a veces se eliminan parámetros o variables que provocan desastres por no dedicarle más tiempo a la calidad y consistencia que a primar la velocidad del lanzamiento. Sin duda que un proyecto sea consistente es una de las grandes bazas para que el SEO siempre funcione.

Combinar y reducir JavaScript

En muchas ocasiones me encuentro que tengo varios JavaScript en una página y, al final, se hace bastante pesado tener que gestionar múltiples ficheros. Además, otra cosa que me gusta es la de reducir al máximo el tamaño del fichero, y el hecho de poder combinarlos también permite reducirlos…

Es por esto que existe para PHP una pequeña biblioteca de funciones llamada JSmin-php que ayuda a gestionar esta situación tanto la de combinar como de minimizar.

Básicamente lo que hace esta biblioteca es leer todos los ficheros JS de una carpeta, combinarlos, comprimirlos y generar un fichero único cacheado.

require_once("jsmin.php");
$files = glob("/carpeta/js/*.js");
$js = "";
foreach($files as $file) {
  $js .= JSMin::minify(file_get_contents($file));
}
file_put_contents("/carpeta/combinado.js", $js);

En el caso en que no queramos leer todos los ficheros de una carpeta y sólo incluior unos pocos, podemos cambiar la línea por algo al que así:

$files = array("/carpeta/js/1.js", "/carpeta/js/2.js", "/carpeta/js/3.js");

De esta forma generaremos un único fichero. Personalmente creo que esto habría que ejecutarlo una vez de forma externa, y usar el fichero generado a mano… a menos que montemos un sistema que verifique las cachés o que permita cambiar este fichero sin que ocurra nada… que luego ya se sabe, cambios de versiones, etc.

HTML5 Prefetch

Hace un tiempo, cuando comencé a hablar del HTML 5, hice una breve referencia a los distinto “rel-algo” que podemos encontrar en la nueva codificación. Entre estos hay uno que puede ser muy interesante si sabes cómo navegan los usuarios de tu sitio web y, aun no sabiéndolo, crees que puedes acelerar la velocidad de carga de la misma.

El link prefetching básicamente lo que permite es descargar las URL indicadas antes de que se vayan a visitar… y el HTML 5 incluye un sistema para avisarlo, ya de forma estándar (hasta ahora sólo Firefox le daba soporte).

El sistema es tan sencillo como poner en el <head> algo como:

<link rel="prefetch" href="http://sitio.web/url-siguiente/">

o algo como:

<link rel="prefetch" href="http://sitio.web/imagen-siguiente.png">

Otra posibilidad es la de acelerar la carga pero en URL concretas que se vayan cargando dentro del sitio… de forma que cualquier enlace interno quedaría de la siguiente forma:

<a rel="prefetch" href="http://sitio.web/url-siguiente/">

Un ejemplo de uso interesante es el que hace Yahoo! con su página principal. Cuando se carga, a priori no hace nada, pero una vez escribes la primera letra en el cajetín de búsqueda, comienza un proceso para precargar imágenes y CSS de la página de resultados de búsqueda, ya que se plantea que va a ser la siguiente en visitarse.

Header Robots (no Meta Robots)

Siempre que se habla de limitar el acceso de los robots de búsqueda a un contenido hablamos de los robots.txt y del meta-robots.

Con estos sistemas básicamente podemos controlar cosas muy generales como todo un sitio o unas carpetas, y de forma más detallada, cada una de las páginas o determinados tipos de fichero.

El tema está en que en algunas ocasiones hay ficheros como los PDF, los vídeos o imágenes que, de forma particular, podemos decidir no indexarlos… pero ¿cómo le puedo poner un noindex a un PDF? Para ello usaremos los encabezados para robots.

Es por esto que existe la directiva HTTP X-Robots-Tag que, gracias a un simple encabezado, permite enviar información como la del meta-robots pero vía servidor web.

Un ejemplo sencillo de encabezado podría ser este:

X-Robots-Tag: noindex

Básicamente le diremos al robot que haya solicitado el dichero que no se indexe… aunque también se pueden hacer cosas como:

X-Robots-Tag: noarchive, nosnippet

En este caso le decimos que no muestre un enlace a la caché y que no muestre el resumen (snippet) en los resultados de búsqueda.

Sin duda es una forma más de avisar a los robots lo que pueden o no hacer cuando llegan a nuestro sitio web.

HTML semántico

Cuando desarrollamos sitios web normalmente no pensamos en usar etiquetas o herramientas que se salen del HTML que todo el mundo conoce. Pero lo que muchos no saben es que el HTML permite algunas cosas semánticas que habitualmente no se utilizan. También lo permite el XHTML, que fue el precursor de esto hace ya algún tiempo, aunque en este caso existen algunas reglas.

Antes de comenzar con lo que se podría hacer en un futuro en el HTML5, voy a poner un ejemplo en XHTML y a explicar brevemente su funcionamiento, ya que es algo distinto si comparamos la versión XHTML de la del HTML:

<ul role="navigation sitemap">
  <li href="/downloads/">Downloads</li>
  <li href="/docs/">Documentation</li>
  <li href="/news/">News</li>
</ul>

Como se puede ver, tampoco es que que haya mucho cambio… simplemente se incluye un atributo nuevo llamado role que permite una serie de parámetros. Y aquí llega lo interesante: la lista de parámetros es el secreto de la semántica, ya que es bastante extensa y permite hacer bastantes cosas.

Voy a destacar aquellos que me parecen más interesantes de cara a aplicaciones y a buscadores ya que, de cara al usuario esto no se verá nunca y no tiene aplicación. En resumen: esto está creado para las máquinas.

Los que habitualmente se usan como link rel=”algo”:

  • bookmark: Indica que ese enlace contiene información extendida del contenido actual.
  • cite: Indica que el contenido de destino es el origen de la cita actual.
  • contents: indica dónde encontrar la tabla de contenidos.
  • stylesheet: Indica la hoja de estilos que se ha de utilizar.

Los que podrían usarse dentro de contenedores (div y similares):

  • banner: Indica que ese bloque de contenido tiene el nombre del sitio y la título principal.
  • complementary: Indica que ese contenido no es el principal, pero lo complementa.
  • contentinfo: Ofrece meta-información del contenido de la página.
  • definition: Da la definición de una palabra o concepto.
  • main: Es el contenido principal de la página.
  • navigation: Indica que eso es la navegación principal de la página.
  • note: Ese contenido es una anotación, acotación o nota del contenido principal.
  • search: Indica que esa zona marca permite realizar búsquedas.

Para acabar, encontramos los elementos más especiales… en este caso habría que ver dónde ubicarlos (pueden ser contenedores o simples span):

  • alert: Mensajes importante y normalmente limitados en tiempo.
  • article: Sección de la página que forma parte del contenido principal pero que tiene significado independiente.
  • heading: La cabecera de la una sección de la página.
  • img: Una colección de imágenes que unidas formas una imagen única.
  • log: Sección que indica una serie de información antigua en relación con el contenido principal.
  • menubar: Menú, habitualmente horizontal, que suele estar siempre visible.
  • region: Una sección grande de la página o del sitio que el autor cree lo suficientemente importante para ser incluida en un sumario.
  • separator: Separador de secciones o de grupos de “menuitems”.
  • status: Contiene información interesante, pero no tan importante como un “alert”.

La cuestión principal es que esto está pensado para el XHTML… pero, ¿se puede usar en HTML5? La respuesta es sí. Aunque hay que decir que normalmente las etiquetas ya llevan implícitos algunos roles… por ejemplo, un <h1> ya lleva implícito un “heading”. O sea, que si se cumples las normas (no sobreeescribir lo que ya se da por implícito y no poner roles a cosas que no se permiten), debería funcionar. Un ejemplo:

<figure role="img" aria-labelledby="fish-caption">
  <pre>
 o           .'`/
     '      /  (
   O    .-'` ` `'-._      .')
      _/ (o)        '.  .' /
      )       )))     >< <
      `\  |_\      _.'  '. \
        '-._  _ .-'       '.)
            `\__\
  </pre>
  <figcaption id="fish-caption">
    Joan G. Stark, "fish".
    October 1997. ASCII on electrons. 28×8.
  </figcaption>
</figure>

Para tener esto en cuenta, es importante ver las anotaciones ARIA según lo que nos espera en HTML5, donde vienen detalladas las excepciones de las que os hablaba antes…

Sin duda, bastante interesante esto que aportan los roles, y su actuación sobre los buscadores, ya que ayudan a mejorar las búsquedas de aquellos contenidos que se encuentran en los roles más concretos y a los que se les da más importancia…

SEO y Arquitectura de la Información

Una de las cosas más interesantes del SEO es que hay que pensar como piensan las máquinas. Dedicar tiempo simplemente a posicionar cuatro conceptos no sirve de nada si tu sitio no aumenta el tráfico de llegada y, una vez dentro, lo conviertes. Esto se resumen en que el SEO ya no sirve por sí mismo si no va acompañado de otras cosas alrededor.

Cuando en Kisslab comenzamos la consultoría de un proyecto el primer paso siempre es el de las buenas prácticas en buscadores, la base para que un proyecto no tenga problemas en un futuro y, que conste, que para mi eso no es SEO, es simplemente hacer un proyecto de Internet bien.

El siguiente paso que planteamos es el de Arquitectura de la Información, aunque con una breve diferencia de la clásica, y es que está enfocado al SEO. me gusta mucho el artículo de la Wikipedia sobre el tema ya que creo que refleja bastante bien lo que es la arquitectura en general, aunque le falte el puntillo SEO que os comentaba… y eso es lo que me gustaría tocar ligeramente.

Una de las definiciones que tiene es:

El arte y la ciencia de organizar y rotular sitios web, intranets, comunidades en línea y software para promover la usabilidad y la ubicabilidad (la característica de ser encontrado a través de las búsquedas en Internet).

Es decir, la Arquitectura de la Información es una de las bases del SEO, ya que promueve la “ubicabilidad” y la “usabilidad” (que esta última acaba llevando a que el usuario pase más tiempo en el sitio y acabe convirtiéndose mejor).

Entre las tareas del arquitecto de la información encontramos:

  • El objeto, propósito y fines del sistema de información o sitio.
  • La definición del público objetivo y los estudios de la audiencia.
  • La realización de análisis competitivos.
  • El diseño de la interacción.
  • El diseño de la navegación, esquemas de organización y facetación de los contenidos
  • El etiquetado o rotulado de los contenidos para acceder a la información.
  • La planificación, gestión y desarrollo de contenidos.
  • La facilidad de búsqueda y el diseño de la interfaz de búsqueda.
  • La usabilidad.
  • La accesibilidad.
  • El feedback del resultado y los procesos de reingeniería del sitio.

Muchos de estos procesos suenan bastante a tareas que hay que hacer también para SEO, como la definición del público objetivo (y por tanto su manera de buscar), la navegación y organización (o sea, la indexabilidad que luego tendrán los robots), el etiquetado de los contenidos (o qué código HTML utilizar en todo momento), el desarrollo de los contenidos (para aumentar la calidad de las posibles consultas de búsqueda)…

Una de las cosas más interesantes de cara a organizar la información es lo que la propia estructura de la URL nos da. No podemos tener contenidos de cualquier tipo mezclados en la carpeta raíz de nuestro sitio, de la misma forma que no podemos tener un árbol de categorías con contenidos finales muy alejados del tronco… mi opinión personal y la experiencia en proyectos me dice que es mejor agrupar los contenidos según tipos de búsqueda y clustering (aplicado a los contenidos, no a la informática en general).

De esta forma hemos de tener presente cosas como que la página principal es un elemento a tratar por separado, otro podría ser la categorización por geolocalización, otro pueden ser los contenidos, otro las tipologías… esto generaría un tipo de URL distinta en cada caso, y de esa forma los motores deberían ser capaces de organizar y entender la información mucho mejor.

Aun así, la arquitectura de la información va a depender de cada sitio web, y aunque se puede generalizar y se sabe que hay cosas que, por lo general, funcionan en cualquier sitio web, es mejor hacer un análisis de la escalabilidad del sitio, también pensando en un futuro aumento de contenidos, cambio de tecnología, etc…

Data URI mejor que CSS Sprites

Una de las cosas que más a bombo y platillo se nos ha intentado meter en la cabeza en los últimos tiempos es que era mejor usar los CSS Sprites que no un montón de imágenes. Y es cierto, es mejor lo primero que lo segundo… ¿pero es lo óptimo? No.

En alguna ocasión he hablado ligeramente sobre las peticiones HTTP y lo que afectan en cuanto a la velocidad de carga de un sitio; una de esas cosas que comenté en su momento fue la de usar los Data URI. Y es que el uso de los CSS Sprites está muy bien si hablamos de navegadores como Internet Explorer 6 o 7, pero desde que tenemos los Internet Explorer 8, Firefox 3 u Opera 9 podemos ir a por un nivel más.

Hoy en día es mucho más óptimo reducir el número de peticiones que no el hecho del tamaño de los elementos en sí. la velocidad de conexión media ha aumentado de tal forma que no es un problema que los ficheros ocupen mucho, sino que haya muchos ficheros distintos, y esto es lo que consiguen los Data URI. Este método básicamente permite insertar imágenes directamente en el código de ficheros CSS y HTML codificando los elementos en Base64.

Teniendo en cuenta los navegadores que dan soporte a los Data URI, tenemos una buena forma de actuar:

  • Firefox 2+
  • Opera 7.2+ (no más de 4.100 caracteres)
  • Chrome
  • Safari
  • Internet Explorer 8+ (menor de 32 KB)

¿Y cómo es un Data URI? Pues algo tans encillo como esto:

data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge
8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1h
LnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g
77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7

Este elemento, convertido en un CSS podría ser algo tal que así:

.icono {
  background: url(data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS
  /7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AA
  ARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguW
  w6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7) no-repeat;
}

Para aquellos que quieran automatizarlo, existen una opción en PHP que lo hace… algo tal que así:

<?php
echo base64_encode(file_get_contents("icono.gif"));
?>

Y ya tenemos más optimizadas las peticiones HTTP de nuestro sitio… menos peticiones, mayor velocidad (sobre todo teniendo en cuenta que los CSS se cachean si se organizan bien y se reducen también las peticiones para verificar imágenes actualizadas).

Contenidos duplicados por idiomas

Según va pasando el tiempo cada vez me encuentro con clientes (y no clientes) que quieren hacer versiones internacionales de sus sitios. En algunos casos lo hacen bien, ya que usan los TLD de cada país, con la interfaz y los contenidos traducidos a lo que ese país utiliza, pero no siempre es así.

Aunque algunos digan y repitan que el contenido duplicado no existe, la propia Google da algunos consejos para evitar que eso ocurra (un artículo muy interesante, la verdad) y, aunque para mi falta chicha en ese artículo, sobre todo hablando de los contenidos dplicados off-site (ahí se habla principalmente de los importantes, que son los contenidos duplicados on-site), es cierto que los idiomas, a priori, no se contemplan.

Es por eso que Google ha aprovechado una de las novedades de HTML 5 para ¿inventarse? un nuevo meta-dato que ayudará a comprobar si los contenidos parecidos entre idiomas están bien trabajados y, en el caso que toque, no se consideren duplicados.

¿Y por qué está haciendo esto? Básicamente porque mucha gente está abusando de su traductor automático para conseguir tráfico en varios idiomas, y ya han dejado claro que aquellos que usen contenidos traducidos automáticamente serán penalizados (NOTA: esta penalización aun no se aplica, pero parece ser que lo haría antes de finales de 2010).

¿Qué sugiere Google? Aprovechar el metadato que antes comentaba que es tal que así:

<link rel="alternate" hreflang="fr" href="http://fr.javiercasares.com/">

Como muchos ya sabréis, los “link” son unos elementos que se incluyen en la cabecera de la página y que, gracias al atributo “rel” permite distintas actuaciones. En este caso el rel-alternate indica que existe otra versión alternativa de la página (y que según los parámetros que le siguen se puede deducir si es una versión para imprimir, una versión en PDF o una versión en otro idioma).

El elemento “href” hace referencia a la dirección URL que sería “duplicada” (o mejor dicho, alternativa) a la actual, y, el elemento interesante, el hreflang que indica, en este caso, el idioma de la página alternativa.

Tal y como avisa Google, esto está pensado para sitios que podrían tener la estructura base de la página en idiomas distintos, pero los contenidos en el mismo idioma.

Que conste que no recomiendo en absoluto usar lo que Google, mezclando rel-canonical con rel-alternate, sino que habría que ver cada caso y decidir, para evitar generar aun más contenidos duplicados. Pero bueno, es un punto de inicio para gestionar mejor los distintos idiomas de un sitio web.

evercookie, la cookie que nunca desaparece

Una de las cosas que en algunos proyectos pueden ser interesantes es saber quién visita la página sí o sí. Normalmente usamos las cookies del navegador, con las opciones de que sean de sesión, de darles una fecha final más o menos cercana o lejana y, por supuesto, la opción de eliminarlas simplemente pulsando un par de botones en las opciones de nuestro navegador.

Pero seguro que en alguna ocasión has necesitado poner una cookie que no desaparezca ni aunque se vacíen todas las opciones de configuración. Si esto es lo que quieres, tu respuesta tiene nombre: evercookie.

El objetivo del proyecto evercookie es conseguir crear una cookie que sea prácticamente indestructible, y para ello utiliza algunas cosas como:

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached
  • PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in and reading out Web History
  • Storing cookies in HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

evercookie está escrito en JavaScript, aunque usa elementos de SWF (para guardar en Flash) o PHP u otras herramientas que tenga disponible el sistema con tal de guardar esa información para que se vuelva indestructible. En principio, el único navegador que es capaz de no cargar este sistema es Safari en modo privado…

En algunos casos, esta cookie puede ser instalada desde un único navegador, pero utilizada desde algún otro, ya que hay algunos sistemas compartidos, sobre todo a la hora de guardar información general en la máquina.

Para descargarlo puedes visitar la página GitHub de evercookie o descargar la versión 0.3. Su uso es tan sencillo como:

<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="swfobject-2.2.min.js"></script>
<script type="text/javascript" src="evercookie.js"></script>
<script>
  var ec = new evercookie();
  // set a cookie "id" to "12345"
  // usage: ec.set(key, value)
  ec.set("id", "12345");
  // retrieve a cookie called "id" (simply)
  ec.get("id", function(value) { alert("Cookie value is " + value) });
  // or use a more advanced callback function for getting our cookie
  // the cookie value is the first param
  // an object containing the different storage methods
  // and returned cookie values is the second parameter
  function getCookie(best_candidate, all_candidates) {
    alert("The retrieved cookie is: " + best_candidate + "\n" +
    "You can see what each storage mechanism returned " +
    "by looping through the all_candidates object.");
    for (var item in all_candidates)
      document.write("Storage mechanism " + item + " returned: " + all_candidates[item] + "
");
  }
  ec.get("id", getCookie);
</script>

En fin… no sé si algún día llegaré a utilizarlo en alguno de mis proyectos, pero la verdad es que parece muy interesante para determinadas cosas… ya que la información y funcionalidad es impresionante.

Tu propio acortador de URL gracias a Google Short Links

Seguramente muchos habréis escuchado hablar de los acortadores de URL tipo tinyURL o bit.ly y últimamente el lanzamiento de goo.gl.

Pues si quieres disponer de tu propio acortador y usar la tecnología de Google, puedes plantearte usar el sistema de Google Short Links, una aplicación del Google Apps Marketplace para los usuarios de Google Apps.

En principio este acortador es válido para las cuentas gratuitas como las cuentas de pago de Google Apps, así que se puede usar sin problema. También hay que ecir que esta aplicación está creada por la propia Google, lo que da cierta seguridad de que seguirá funcionando. Probablemente haya sido alguna aplicación creada en ese famoso 20% de tiempo que se les deja libres a algunos empleados de la compañía.

Una vez indiquemos nuestro usuario, aceptaremos los términos y condiciones. En mi caso seleccionaré el sistema url.casares.org.

Tras esto deberemos configurar la entrada DNS en el dominio:

url.casares.org CNAME ghs.google.com

Ahora que ya está todo configurado, vamos a revisar el panel de gestión del producto; en él podremos añadir más dominios y configuraciones:

Ahora que ya hemos configurado todo, sólo nos queda ir al panel desde el que gestionar los enlaces. Para ello tan sólo hay que entrar en url.casares.org donde veremos algo tal que así:

Para añadir un acceso rápido es tan sencillo como indicar la palabra clave que queremos crear y la dirección URL a la que ha de apuntar. Podemos hacer que esta dirección sea pública o privada.

NOTA: En el caso de no indicar ningún nombre a la URL, se genera uno de forma aleatorio.

Además, podemos arrastrar alguno de estos botones (o ambos) a nuestra barra de enlaces del navegador para así tener más a mano la posibilidad de acortar un enlace. Existe la opción del botón para que los enlaces sean público o no, según convenga. Al pulsar en este enlace, básicamente nos manda a la página de creación de enlaces con el recuadro de la URL completo, y la posibilidad de crearlo.

Además, existen 2 paneles más… uno es para ver todos los enlaces cortos que se han creado por todos los usuarios del dominio y, el otro, es para a administración de los tuyos (así poder corregirlos o mejorarlos cuando toque). Os dejo con el más completo de los dos (que simplemente difiere en que aparece una columna con el nombre del usuario).

Entre las cosas curiosas (y que yo no sé si tienen mucha utilidad) podemos “editar” un enlace y ver algunos datos sobre él. Lo primero es poder darle “permisos” a otros usuarios para gestionar dicho enlace, lo segundo es un listado (a modo de log) de todos los cambios que se han hecho.

En resumen… está bien, es una buena forma de organizar los enlaces privados, y aunque los puede usar cualquiera, no son de administración pública (sólo para los usuarios del dominio).

NOTA para SEO: esta aplicación hace redirecciones 302, que son conocidas por su mal funcionamiento en SEO (y supongo que se han desarrollado así para evitar barbaridades)…

GET /tumanitas HTTP/1.1
Host: url.casares.org

HTTP/1.1 302 Found
Location: http://www.tumanitas.com/
Expires: Fri, 01 Jan 1990 00:00:00 GMT