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.