Tengo mucho que comentar sobre el search congress de bilbao y no se por donde empezar. Así que empezaré por lo más importante, cosas que he aprendido y que no conviene olvidar.

Lo primero es que le seguimos el juego a Google y

Según Javier Casares las urls de un proyecto no deben cambiar nunca. Hay que pensar con cuidado la estructura y asegurarte que puede crecer en el futuro. No conviene cambiar de urls con redirects 301. Aunque siempre es recomendable pensar bien un nuevo proyecto su opinión es discutible, según mi experiencia Google tiene una memoria limitada (en tema de história de una web) no creo que guarde todas las versiones y unicamente debe guardar «eventos o marcas» de los triggers que hayas hecho saltar. Puedes perder valor de los enlaces entrantes por haberlos convertido en un redirect 301 en vez de ser directos pero no creo que afecte mucho más.

Ya lo sabía pero se sigue insistiendo y creo que con razón, la velocidad de la web va a tener más peso en el valor de las webs para google. Aunque el coste de aplicar todas las sugerencias del Page Speed de google puede ser casi imposible si hay cosas que se pueden arreglar en poco tiempo.

  1. Cachear en local el código de analytics. De esta forma hay una resolución menos del dns y no estorbamos la carga de la web.
  2. Cachear en local el código de adsense por la misma razón, lo único a tener en cuenta es que en este punto no hay consenso sobre si incumple las políticas de adsense.

Otra vez según Javier las carpetas de idiomas no funcionan para posicionar. Es mejor que cada idioma tenga su dominio.

Todo el tráfico de suramerica pasa por Miami… Interesante si te diriges al mercado suramericano poner los servidores en esa ciudad.

Las instalaciones por defecto de los servidores suelen ser fatales para el seo, hay que cuidar especialmente las redirecciones que tienen configuradas.

El cloud computing no geolocaliza por ip, javier propone hacer cloud en el país al cual diriges tus servicios.

La forma de optimizar el HTML no es que pase los checks del W3 consortium sino que hemos de conseguir que cargue lo más rápido posible. Hay tres vías para ello.

  1. Que el servidor tarde poco en generar los contenidos a enviar. Cachear, optimización de la programación y más maquina.
  2. Enviar menos información.
    • Enviar el contenido comprimido. http/1.1
    • reducir el número de ficheros a descargar: un solo css, un solo js, usar csssprites para las imagenes que siempre se usan.
    • Comprimir los css y los js: jsmin o yuicompressor
    • Poner los contenidos estáticos (imagenes, videos, js, css etc) en un servidor sin cookies (dominio distinto).  Tendremos una resolución adicional de dns pero a cambio ahorraremos el envío de cookies inecesarias.
    • Paralelizar las descargas, flush()
    • Anticipar las descargas de las páginas siguientes. En una formulario en cadena cuando estás rellenando los campos podríamos ir descargando los elementos necesarios para el siguiente. Esto para SEO no aporta nada, pero es experiencia de usuario.
    • Limitar los elementos DOM que tenemos en cada página a menos de 1000 para facilitar a los navegadores la rederización.
    • Obviamente optimizar imagenes.

Un par de trucos guarros para que Google penalice a la competencia… ups
Cuando tengamos una página de en mantenimiento para actualizaciones y similares tiene que responder un error 503  para que Google no indexe esa página, no habría de usarse más de 12 horas.
En contenidos para móviles el adsense todavía no está explotado a fondo, hay un nicho de negocio.