Como ya mencionábamos anteriormente las arañas de los buscadores son, en realidad, un navegador muy sencillo. Los navegadores solo interpretan HTML, pero el SEO va mucho más allá del HTML. Además, existen diferentes técnicas para ayudar a los buscadores a indexar el sitio web tan rápido como sea posible. Este capítulo es muy técnico pero es un conjunto de recomendaciones que vale la pena implementar, lo notarás en los resultados.

En este capítulo analizaremos los aspectos relacionados con el servidor que son importantes para SEO, abordaremos los temas siguientes:

• Velocidad de descarga de la web
• Las redirecciones
• La reescritura del URL
• El contenido duplicado
• Los txt
• Los sitemaps XML

Un navegador construye una página web usando HTML, CSS y en ocasiones JavaScript, pero para que eso ocurra, el servidor también tiene que hacer su parte. El servidor procesa las peticiones, genera el HTML, lo sirve y envía un código de respuesta del servidor (que indica si se ha procesado todo adecuadamente o si se ha presentado algún error). He aquí una lista con algunos de los códigos más importantes:

• 200 – Página encontrada
• 301 – Redirección permanente
• 302 – Redirección temporal
• 404 – Página no encontrada

Hay varios grupos de códigos de respuesta: los mensajes que se encuentran dentro del grupo 200 indican que todo ha ido bien, y los que están incluidos en la serie 300 señalan la existencia de múltiples páginas enlazadas. La serie 400 indica que el navegador no puede mostrar la página web de forma adecuada y, finalmente, la serie 500 señala los errores de servidor.

Una buena configuración del servidor tiene un impacto extremadamente positivo en el posicionamiento en buscadores, en este capítulo analizaremos algunos de los aspectos más importantes; aunque podría parecer que son dos áreas diferenciadas y sin relación entre sí, trataremos de exponerlos de forma que se entienda la repercusión. En primer lugar, analizaremos la velocidad de descarga de la web, las redirecciones y la reescritura del URL y, posteriormente, examinaremos el contenido duplicado; además, explicaremos cómo indicarle a los buscadores las páginas webqué deben o no indexar y analizaremos el alcance de los sitemap XML o los robots.txt.

En los últimos meses, la velocidad de descarga de la web se ha convertido en un factor SEO muy relevante. Hay diversas técnicas que contribuirán a mejorar la velocidad de descarga, a saber:

Hosting/housing

Este apartado es primordial, ya que dependiendo del datacenter donde se inserta el servidor y datacenter donde se aloja la web, habrá mayor conectividad y posibilidad de servir mayores peticiones en menor tiempo. Para webs con mucho tráfico o webs orientadas al e- commerce este factor se convierte en una prioridad.

A la hora de elegir dónde se va a alojar una web, conviene hacerse las siguientes preguntas:

• Sistema de tráfico contratado: por volumen de tráfico o por ancho de banda de la línea asignada al servidor.
• Capacidad del datacenter para absorber peticiones.
• Capacidad del servidor, desde la memoria RAM, tipo de CPU, a porcentaje de CPU consumida. Posibilidad de personalizar la memoria asignada a procesos del servidor.

En el caso de tener un servidor compartido o utilizar cloud computing, hay que asegurarse de que el resto de webs con las que se comparte infraestructura no afecten a la capacidad de dar respuesta a peticiones.

Este apartado se puede valorar principalmente mediante dos indicadores: tiempo medio de resolución de peticiones, velocidad de descarga (en kb/seg).

Algunas páginas son muy lentas y esto es negativo para la experiencia del usuario que incluso puede llegar a abandonar el sitio web. El mismo principio se aplica a los buscadores, que favorecen de cara al posicionamiento a aquellas páginas web que cargan más rápido, en su afán por aumentar la satisfacción del usuario. Por esta razón es importante, tanto para los usuarios como para los buscadores, que la página web cargue rápidamente.

Desde junio de 2010, con la entrada del algoritmo Google Caffeine, la velocidad de carga se ha convertido en uno de los factores de posicionamiento más importantes, ya que desde entonces, Google mide activamente la velocidad de carga de las webs. Para reducir la velocidad de carga hay que mejorar el rendimiento de la web a nivel de servidor y de compilación de los scripts.

A nivel de servidor, es importante tener en cuenta desde la configuración del sistema operativo, al tipo de máquina y especificaciones técnicas de esta, hasta poder llegar a utilizar sistemas de caché y proxy-cache, para poder aumentar el número de peticiones y reducir la compilación de las mismas.

A nivel de código fuente, hay que intentar que el mismo esté bien estructurado, reducir las peticiones internas a la misma máquina y hay que utilizar técnicas de caché y reducir el peso de los archivos a descargar (tanto de código fuente como tamaño y número de las imágenes), con el objetivo de reducir el tiempo de carga.

Una web se puede programar de diferentes formas, si nuestro objetivo es aumentar la capacidad de respuesta, podemos utilizar varias técnicas, incluso varias de ellas a la vez. Algunas de estas técnicas son las siguientes:

• Utilización de sistemas de caché de script.
• Utilización de caché de base de datos.
• Utilización de caché a nivel de servidor.
• Implementación de sistemas de CDN.
• Reducción del número de peticiones a bases de datos durante la carga de la web.
• Uso de CSS sprites para reducir el número de imágenes cargadas.

Todas estas técnicas aceleran el tiempo de descarga de la web y el volumen de uso de CPU, con lo que no sólo se reducirá el tiempo de descarga, sino que podremos aumentar las peticiones por segundo al liberar uso de la CPU para absorber más peticiones.

Si hablamos de SEO y servidores, uno de los aspectos más importantes, por su repercusión y porque suele acarrear infinitos problemas, son las redirecciones. Antes o después, todo sitio web tendrá que enfrentar la necesidad de trasladar contenido de una página a otra, por ejemplo, un producto que se retira de la tienda, o en la creación una nueva estructura para el sitio web.

La importancia reside en que la URL del producto que se retira tiene un historial, y puede haber atraído enlaces desde otros sitios web, de manera que si se elimina la página y se muestra un código de respuesta 404 (página no encontrada), se perderá para siempre el valor de los enlaces, con lo que implica. Además, las páginas web que tienen cierta antigüedad, independientemente de que tengan enlaces entrantes o no, tienen un valor, es decir, por el hecho de haber estado online han acumulado peso y esto contribuye a mejorar su posicionamiento. En resumen, es importante redirigir las páginas que tienen enlaces entrantes o cierta antigüedad en vez de eliminarlas.

Existen varias formas de configurar una redirección: mediante las meta etiquetas, JavaScript, código de script del servidor (php, asp, jsp, …), usando JavaScript e incluso a nivel de reglas de servidor (.htaccess para php isapi para .asp). El problema de estas técnicas es que los buscadores no siempre las comprenden adecuadamente y optan por no seguir los enlaces. Esto significa que la redirección, sea como sea debe ser 301 si tiene fines SEO.

Los códigos de respuesta

En el protocolo http existen diferentes códigos de respuesta para indicar una redirección (en el World Wide Web Consortium^l8se puede encontrar una lista con todos los códigos y su significado). No obstante, los dos códigos más populares son: la redirección 301 y 302, que tienen una diferencia fundamental:

301:        Trasladado permanentemente

302:        Trasladado temporal

Muchos sitios web utilizan automáticamente la redirección 302, pero los buscadores no interpretan este código como una redirección real. Es decir, esta redirección indica exactamente que se sustituye una URL por otra, pero solo de manera temporal por lo que los buscadores solo recordarán la antigua URL.

Por el contrario, la redirección 301 le indica a los buscadores que el antiguo enlace ha sido eliminado definitivamente por lo que tendrán que borrarlo de su memoria y reemplazarlo con el nuevo enlace. Así, dentro de todas las opciones de redirección disponibles, la redirección 301 es la única que comprenden los buscadores. En este punto, la redirección con JavaScript y el uso de las etiquetas meta para refrescar la redirección no son aplicables.

Las redirecciones 302 suelen ser la redirección por defecto en un servidor, ya que históricamente se han utilizado con fines de seguridad y privacidad. La imagen a continuación muestra cómo todos los enlaces de la antigua URL se refieren a la nueva URL.

Una página de error del tipo ‘esta página no se pudo encontrar’ debe mostrar un código de de respuesta 404, si mostrara un código 200 sería indexada y crearía una mala experiencia en los usuarios y un factor negativo de cara al posicionamiento.

Uno de los usos de las redirecciones 301 es solucionar los problemas de páginas 404 de un sitio web, muy habitual en migraciones y en sitios que no tienen un mantenimiento SEO. Este seguimiento es especialmente importante en e-commerce con rotación de productos.

Hay técnicas para evitar las páginas de error 404, pero hay que tener planificado cómo se va a dar respuesta a estos errores, ya sea mediante un seguimiento activo de resolución como a un análisis de cuáles son y por qué se están produciendo.

Se puede hacer el seguimiento de las páginas 404 desde la herramienta de analítica web si previamente se ha implementado el seguimiento, así como desde las herramientas de Google para Webmasters (más adelante en este mismo capítulo nos referimos a esta herramienta).

Cómo hacer la redirección 301

Una redirección 301 se puede colocar en el fichero .htaccess o en cualquier otro lenguaje de programación (ya que el .htaccess solo está disponible si se utiliza un servidor webApache. La principal ventaja del fichero .htaccess es que permite redireccionar un gran número de URL estableciendo reglas. A continuación mostramos varios ejemplos de una redirección 301 en diferentes lenguajes de programación:

.htaccess

Redirect 301 /antigua.html

http://www.onetomarket.es/nueva.html

PHP

<?php

header(«HTTP/1.1 301 Moved Permanently«);

header(«Location: http://www.onetomarket.es/nueva.html«);

?>

ASP

<%

Response.Status=»301 Moved Permanently»

Response.AddHeader «Location»,

«http://www.onetomarket.es/nueva.html»

%>

ASP.NET

<scriptrunat=»server»>

prívate void Page_Load(object sender,

System.EventArgs e)

{

Response.Status = «301 Moved Permanently»;

Response.AddHeader(«Location»,»http://www.onetomarket.es/nueva.ht }

</script>

Versión canónica. ¿Insertar o no las www?

Muy pocos saben que www es un subdominio, por eso, desde el punto de vista técnico, http://casadellibro.com es diferente de http://www.casadellibro.com, así, los buscadores comprenden que ambas URL son distintas. No obstante, en muchas ocasiones tomamos la vía más fácil y tecleamos simplemente: ‘casadellibro.com’; entonces el navegador lo reemplaza con:http://casadellibro.com, una dirección que continúa siendo diferente de http://www.casadellibro.com. A pesar de estas diferencias, casi siempre las versiones con o sin www muestran el mismo sitio web por lo que existe el peligro del contenido duplicado.

Normalmente se opta por crear con www la versión principal, sería la versión canónica, y se redirige desde la versión sin www a la versión con www con un fichero .htaccess (siempre que se utilice un servidor Apache). Se puede utilizar el siguiente código:

RewriteEngineOn

RewriteCond %{HTTP_HOST} ^Acasadellibro\.com [NC] RewriteRule a(.*) http://www.casadellibro.com/$1 [l,R=30i]

Echemos un vistazo a dos URL diferentes:

www.web.es/index.php?mainID=26&sectionID=43&itemID=327

www.web.es/categoria-principal/subcategoria-palabra-dave/

Es obvio que la segunda versión da una impresión mucho mejor, indica el tema de la página web, y se puede memorizar y reproducir, mientras que la primera URL es menos atractiva porque utiliza todos los ID técnicos para encontrar el elemento adecuado dentro de la base de datos. Si mostramos ambas URL en los resultados de búsqueda, el segundo enlace seguramente atraerá más clics simplemente porque es más informativo y atractivo. Además, la segunda URL también se indexa con mayor facilidad por parte de los buscadores y representa una oportunidad más para reforzar la estructura del sitio web.

Lo ideal sería que la URL indicase el tema de la página web, por ejemplo,          /libros-historia/las-venas-abiertas-de-america-latina, representa un fichero existente pero no tiene que ser necesariamente así, es decir, el fichero puede existir solo en la URL pero no físicamente en el servidor. Existen diferentes métodos para crear una URL-ID apta para buscadores, en este capítulo analizaremos dos formas de hacerlo.

Alergenos Alimentarios

Método 1: mod_rewrite en Apache

mod_rewrite es un módulo del servidor Apache al que se puede acceder ubicando un fichero .htaccess en la raíz del sitio web. En este fichero se indicará que el RewriteEngine debe estar activado:

RewriteEngine on

Si la estructura de la URL se muestra de la siguiente manera:

1) www.site.es/index.php?mainID=26&sectionID=43&itemID=327

La URL no tiene términos de búsqueda, de manera que si la optimizamos y eliminamos las variables, nos queda:

2) www.site.es/26/43/327/

El mod-rewrite debe reescribir la URL 2 de forma tal que trabaje intermitentemente con la URL 1, para lograrlo se usa RewriteRule. Antes de explicar esto con más detalle, he aquí el código de la regla:

RewriteRule *(0-9+)/(0-9+)/(0-9+)

index.php?mainID=$1&sectionID=$2&itemID=$3 [L]

El signo ^A indica el nombre del dominio, por ejemplo www.site.es. A continuación se incluye (o-9+)listado tres veces y separados por una barra. (0-9+) describe una serie de números donde el signo + indica que la serie debe continuar hasta que se encuentre un carácter que no sea un número. Al usar este método las series de números que se encuentran entre las barras se reemplazan con una variable. Las primeras series se convierten en $1, la segunda en $2y la tercera en $3. Después, las series de números se sitúan en la URL, que inicia con index.php.

Todo el fichero .htaccess se mostrará de la siguiente manera:

RewriteEngine On

RewriteRule *(0-9+)/(0-9+)/(0-9+)

index.php?mainID=$1&sectionID=$2&itemID=$3 [L]

A continuación, se deben reemplazar todas las antiguas URL del sitio web para pasar a usar las nuevas URL según el formato número 2. No obstante, como la antigua URL tiene historial, se debería colocar una redirección a la nueva tal y como explicábamos al principio de este capítulo.

Evaluación de este método

El método que hemos mostrado funciona bien y puede programarse con rapidez, el único problema que presenta es que el uso de ReWriteRules puede ser complejo. De hecho, a veces ReWrite Rules es tan complicado que para poder realizar todo el trabajo se necesita un conocimiento básico de las expresiones regulares (entiéndase estas como una vía para describir los patrones utilizados por el ordenador para comprender el texto).

Método 2: Reemplazar la URL con PHP

Existe otra forma para reescribir las URL basada en el uso de PHP (o cualquier otro lenguaje de programación de servidor) y no en el mod_rewrite. Una vez más, se deberá crear un fichero .htaccess pero el contenido será diferente:

RewriteEngine on

RewriteRule !\.(gif|jpg|png|css|js)$

/home/httpd/vhosts/site.es/httpdocs/site.php

El archivo /inicio/httpd/vhosts/site.es es una ruta de raíz hacia el fichero. Como la ruta es diferente para cada servidor, se deberá descubrir cuál es la propia ruta de raíz.

Esto significa que cada fichero que no tenga las extensiones .gif, .jpg, .png, .css o .js se reescribirá en el fichero site.php. Ahora se puede leer la URL desde el fichero site.php y ver qué contenidos se mostrará. También es posible no reescribir todos los archivos, para lograrlo basta con excluir los archivos que no se quieran reescribir. En el ejemplo a continuación se muestran los archivos/stats que no se reescribirán:

RewriteEngine on

RewriteRule ^Astats/.*$ – [L]

RewriteRule Astats/$ – [L]

RewriteRule Astats$ – [L]

RewriteRule !\.(gif|jpg|png|css|js)$

/var/www/dominio.com/index.php

Todas las URL que no comiencen con /stats se reescribirán a index.php. Ahora se puede usar index.php para determinar qué páginas se deben mostrar basándose en la URL semántica.

Usaremos la siguiente URL como ejemplo: /libros-historia/lasvenas- abiertas-de-america-latina. Necesitamos usar libros-historia y las- venas-abiertas-de-america-latina para determinar qué URL se mostrará. Esto se puede hacer usando el siguiente código PHP:

<?php

$parts = explode($_SERVER[‘REQUEST_URI’]) ;

// $parts[0] = «»;

// $parts[1] = «libros-historia»;

// $parts[2] = «las-venas-abiertas-de-america-latina «;

?>

Ahora se pueden usar las variables para determinar el contenido que se mostrará.

Evaluación de este método

Este método no requiere ningún tipo de conocimiento sobre las expresiones regulares ya que la mayor parte del trabajo de reescritura se realiza a nivel de PHP. No obstante, es necesario excluir los archivos que no quieran redireccionarse.

El uso de estas técnicas requiere hacer un cambio a nivel de página, de forma que tenemos que ser capaces no sólo de leer nuevas URL, sino que tenemos que ser capaces de generarlas.

Más bibliografía sobre mod_rewrite

Aún queda mucho que decir sobre mod_rewrite pero sería imposible abarcarlo todo en este libro. Quienes deseen profundizar en este tema tienen a su disposición otras fuentes bibliográficas, una de las mejores es la explicación de Apache que puede encontrarse en: http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html. A los lectores que estén interesados en profundizar aún más en este tema les recomendamos: La Guía Definitiva para Apache mod_rewrite, escrita por Rich Bowen ¹⁹.