Ikhuerta | El blog de Iñaki Huerta View RSS

SEO OnPage: Cómo gestionar correctamente las paginaciones de tu negocio 22 Mar 2019 5:56 AM (6 years ago)

Ayer Google nos dio una noticia que desde la comunidad hemos criticado todos. Anunciaron que no usan las etiquetas rel=prev/next para nada. Y lo peor que también sabemos: que hace mucho que no las usan (si es que las llegaron a usar)

https://twitter.com/googlewmc/status/1108726443251519489

¿Por qué este anuncio nos toca las narices?

Lo primero explicar a quien no lo entienda a que se debe tanto revuelo: no es por no usar estas etiquetas si no porque esa estos etiquetados se impulsaron justo desde Google y nos las hemos comido por su culpa haciendo perder a clientes tiempo y dinero en implementarla. Todo para darnos cuenta de que como mínimo era opcional. Y todo esto sin hablar de que rel=”nex/prev” formó parte de su solución fallida para indexar el scroll infinito de las páginas.

A mí, personalmente, me preocupa también la poca seriedad para justificar todo esto y anunciarlo: a «los usuarios les gustan las soluciones one-page»… ¡Vaya forma más gratuita de confundir a la gente! No, señores clasificados e ecommerce, no podéis meter todo el catálogo en una sola página diga lo que diga esta cuenta de Twitter.

Pero este cambio ¿Nos afecta realmente?

Lo cierto es que para la mayoría de los SEOs que nos tomamos en serio la indexación y autoridad interna (los que nos centramos en el SEO On Page) esta noticia solo cambia una cosa: bajamos mucho la prioridad de implementar estas etiquetas pero no cambiamos nada de las arquitecturas porque ya fueron hechas sin tenerlas en cuenta.
Porque lo peor de este dramático anuncio, es que ya en el fondo YA LO SABÍAMOS…

Y para que se entienda todo esto y explicar por qué no supone ningún drama os voy a explicar cómo tratamos muchos (y en especial en IKAUE) desde hace tiempo las paginaciones en proyectos grandes.

¿Para qué quiere un SEO URLs de paginaciones?

La respuesta corta sería: ¡Para nada! Quítalas, bórralas o desindéxalas. No las queremos no, no ayudan.
Para una respuesta más correcta debemos por un lado explicar por qué no nos sirven y añadir también por qué sin embargo son necesarias.

¿Por qué las URLs de paginaciones no ayudan a tu SEO?

Pues sencillamente porque no son contenido único. Pensad en cualquiera de las categorías de vuestros sites que os veis obligados a paginar. Estas URLs de páginas a partir de la 1 (que es la de la propia categoría), ¿qué os aportan?

– A nivel de contenido son bastante pobres, sus artículos son referencias a fichas completas y su posible título y entradilla la mayor parte de las veces son los mismos que los de la página 1. Vamos, que como página entrarían en la categoría de thin content (que sabemos que no vamos a posicionar).

– Para empeorar la situación, encima son contenido duplicado: Páginas 1, 2, 3, 4, etc. A parte de los propios ítems del listado y de coletillas tipo “| pagina 3” no tienen más diferencias. Google los canonicalizará, en el mejor de los casos sobre la página 1 y en el peor sobre otra …

– A nivel de crawl Budget, Google va a perder el tiempo rastreando todas estas páginas, si tenemos un site grande con mucho contenido hablamos de más de 100 páginas por categoría que Google debe visitar y revisitar suponiéndole una pérdida de tiempo enorme.

– Y para terminar de fastidiarlo todo a nivel de autoridad cada uno de los links a páginas va robando autoridad, page Rank o link juice (Como quieras llamarlo)

En definitiva estas páginas no solo es que no nos interesen por negocio sino que en conjunto pueden hacer mucho daño al posicionamiento del resto de páginas de tu site.

Así que basándonos en esto la conclusión que sacaríamos es que… NO QUEREMOS QUE GOOGLE LAS VEA.

¿Por qué, sin embargo, son más que necesarias?

Por porque los buscadores siguen usando como vía principal tanto de crawling (para descubrir contenidos y revisitarlos) como como señal de traspaso de autoridad los enlaces. Esto supone que si en nuestra estructura de dominio no ofrecemos un recorrido claro de acceso a los buscadores para que saltando de enlace en enlace alcancen un contenido es muy probable que este no posicione o incluso que ni si quieras se indexe o rastree.
Cuando nuestro negocio tiene como base un catálogo (de productos, de recursos, de marcas, de lo que sea) es vital que Google alcance sus ítems para que los posicione. Y aunque esto puede no ser cierto siempre, pues hay muchos negocios que no cuidan su catálogo hasta llegar al punto de que muchas veces resulta más conveniente esconder la parte del mismo más deficiente que mostrársela a los buscadores, vamos a suponer que al menos para una gran parte del catálogo esto es cierto.

En la mayor parte de las estructuras y CMSs actuales, la indexación y acceso a toda la colección de ítems del catálogo se resuelve mediante paginaciones. Esto no significa que esta sea la única e indiscutible forma de solucionarlo, pero si que es la más común y extendida. Gracias a las paginaciones usuarios y buscadores pueden llegar a alcanzar antes o después un link hacia todos los productos disponibles en el catálogo. Incluso cuando encontramos sistemas que nos ofrecen llegar a la página 700 muchas veces esta es la única vía para alcanzar mediante enlaces el contenido que ahí encontramos.

Y este pequeño pero importante detalle es el motivo por el cual, a pesar de que las URLs de paginaciones no nos aportan nada en SEO debemos ofrecérselas al buscador.

Un repaso a las distintas soluciones a estos problemas que encontrarás por ahí…

Antes de seguir con cual es para nosotros la vía por la que solucionar estos escenarios voy a comentar algunas de las soluciones que se discuten reiterativamente en distintos blogs y redes sociales. Intentaré ser lo más breve posible al comentarlas pero es importante dedicarles un tiempo para evitar confusiones.

Usar rel=”next/prev” asumiendo que eso acumula las urls de paginación en un único ente mágico sobre la página 1

Esto es lo que llevábamos tiempo viendo que no pasaba en absoluto (a pesar de usarlo las urls seguían canonicalizándose y llevándose la autoridad) y ahora Google ha pasado a desmentir directamente. Bien, como Google ya lo ha dicho claro, no explico más. Esto no sucede, un rel=”prev/nex” no es malo. Son señales accesibles y pueden ayudar a varios sistemas. Además son URLs que los buscadores no seguirán igual que un link, pero al tener formato de URL acabarán entrando a ver que hay (sin por ello pasar autoridad).
Así que podemos hacerlo, pero no esperéis resultados con esta acción a nivel de SEO.

Usar un canonical hacia la primera página en todas las paginaciones

Con esto lo que hacemos es declarle a Google que todas las paginaciones son una copia de la primera página. Esto ya de base no es cierto, la página 2 no es igual que la 1, puede que alguien piense que le interesa que Google piense esto pero ni va a hacernos caso (porque el canonical es una señal débil que ignora a la mínima y cuando vea que el contenido total no es igual lo ignorara) ni nos convendría que lo hiciese (porque entonces a la larga ignoraría todos los items que le vamos poniendo además de que seguiría rastreando todas las paginaciones perdiendo gran parte del crawl Budget total por culpa de esto.).

En definitiva el efecto que vamos a conseguir con un canonical no lo podemos controlar. Google hará lo que le de la gana y haga lo que haga no solo lo desconoceremos sino que no solucionará los problemas que las paginaciones nos producen.

Usar un noIndex o un noindex/follow para evitar problemas de duplicados pero seguir los enlaces.

Esta parecería que es la solución mágica. Solucionamos el problema de duplicados y thin content al decirle que no indexe los contenidos pero nuestros ítems siguen indexándose.

Pero en la práctica cuando analizamos esta opción tampoco acaba de ser bueno. Por un lado si nos hiciese caso no arreglaríamos el problema de crawl Budget al pedirle que nos rastree todas las paginaciones que tenemos en el site. Por otro al ser una página noindex la que ofrece los enlaces es dudoso que traspase a estos ítems la autoridad que deseamos darles.

Pero es que para colmo, cuando analizamos el comportamiento de crawling de este tipo de páginas (noindex con o sin follow) descubrimos que a la larga empiezan a rastrearse menos que las páginas normales del site. En alguna ocasión Google nos ha hablado de este efecto y su explicación es que si total no tiene nada que ir a indexar a esas páginas es normal que se las mire menos. A la larga lo que vemos es que estas páginas apenas se rastrean, no dejan de rastrearse del todo pero si que terminan con un rastreo mínimo…

En conclusión si usamos este sistema al principio arreglamos los duplicados pero no arreglamos el problema del crawl Budget (pues al seguir enlaces sigue todas las páginas de paginación) y a la larga conseguimos que el crawl Budget vaya algo menos pero a costa de empezar a tener problemas para indexar los ítems que ofrecemos en las paginaciones (pues como no pasa por ahí no ve sus enlaces).

Nuestra recomendación es la de evitar la fórmula de noindex/follow porque este follow no se cumple como esperábamos y termina siendo mucho más efectivo usar otras fórmulas.

Sumar los 2 anteriores: Noindex/follow + canonical esperando también que haga magia

Lo que está claro es que si el canonical no era una buena idea y el noindex/follow tampoco lo era las dos a la vez no van a mejorar la situación. Es algo muy extendido y aconsejado. Incluso veréis a mucha gente que os dice: “a mi me ha ido bien”.

Según mi experiencia lo que pasa en estos casos en realidad es que el canonical es una señal muy muy débil y Google ante conflictos la ignora. En este caso le estamos diciendo: no me indexes, pero soy igual que otra página que si debes indexar. ¿Qué? Es que si la araña fuese una persona nos enviaría un mail con tres letras muy claras: “WTF!!!”.

En los casos en los que he visto cierta mejora aplicando esta técnica lo que me he encontrado ha sido exactamente lo mismo que al aplicar un noindex/folow. Mismas ventajas y mismos problemas a lo que sumamos algunos canonicals vilmente ignorados por Google.

Eliminar los enlaces (u ofuscarlos)

Controversias a parte a día de hoy hay que dejar claro que no poner un enlace u ofuscarlo (hablamos de ofuscarlo bien) en la práctica no suponen ninguna diferencia. Llega el bot de Google no ve una etiqueta de enlace que seguir y por lo tanto no sigue nada.

La diferencia real está en hasta que punto te la quieres jugar. A nosotros nos gusta ser limpios y usar la ofuscación solo como último recurso: cuando es necesario si o si eliminar un enlace pero por motivos ajenos al SEO (que hay muchos y variados y la mayoría totalmente válidos) no puede eliminarse.

Así que la fórmula que proponemos es siempre eliminar el enlace y solo cuando esta acción es rechazada hablar de otras opciones. Pero esto es más por un tema de moral, creemos que a nuestros clientes les debemos ser lo más profesionales posibles y que una técnica que algún día podría ser penalizable no puede ser el punto de partida. Dicho esto también es cierto que muchos SEOs se lanzan a la ofuscación de forma masiva y no ven ningún efecto negativo en ello (al menos a día de hoy).

También es cierto que podemos colar técnicas de usabilidad reales como solución ofuscada para las paginaciones. El ejemplo más claro sería el scroll infinito no tratado de ninguna forma. De esta forma no estás haciendo nada malo: has implementado una medida para que el usuario pueda paginar que por desgracia el pobre robot aun no es capaz de seguir. ¿Estás haciendo black hat con eso? Pues la verdad es que no y nadie puede acusarte de ello.

Olvidando el método que escojamos, con esta técnica lo que hacemos es eliminar del rastreo las paginaciones. Google no las ve (o mejor aún, ni siquiera existen) por lo que ya no hay problemas de crawl Budget ni de autoridad. Lo que si nos va a pasar si abusamos de esto es que los productos no se rastrearán (si Google no puede ver los enlaces de la página 5 no los podrá seguir) así que podemos jugar con esto siempre y cuando encontremos vías para la indexación de productos pero nunca va a ser esta la solución al problema por si sola.

Si nada funciona, ¿Qué es lo que debo hacer?

Pues sencillamente, haz SEO. Tienes las herramientas suficientes como para decidir cuando provocas unos problemas u otros y cuando obtienes el beneficio de la indexación y el traspaso de autoridad a páginas de ítem del catálogo. Juega con esas herramientas hasta conseguir un escenario que no será el ideal pero que garantice que ninguno de los problemas que puedes provocar sea grave.

Nuestro sistema, que hemos llevado a cabo en muchos grandes sites con un resultado óptimo

Lo primero es olvidarte de la solución simple y única. Ya hemos visto que no funciona, así que vamos a jugar al link sculping: vamos a diseñar cómo debe ser el acceso de las arañas de Google a todas las páginas de nuestro site y cuando me permite perdidas de crawl Budget y cuando necesito autoridad en puntos claros.

La premisa sigue siendo: A Google no le gustan las URLs de paginación pero las vamos a necesitar. Y la clave es saber cuándo dárselas y cuando no. No en qué sites dárselas y en cuales no, si no dentro de un mismo site qué sitios son los idóneos para que las arañas se pierdan por las paginaciones y en cuales no se lo vamos a permitir.
Estudia cada caso por separado, no hay fórmulas únicas.

Cada site tiene sus propios problemas de autoridad interna y de indexación, audita el tuyo y saca una idea clara de qué está suponiendo un problema y por donde pasa la araña. Screaming, análisis de logs, análisis de la arquitectura de enlaces, de puntos de gran entrada de enlaces externos… todo eso que ya miras para hacer auditorías SEO va a ayudarte a saber donde actuar.

Nuestra solución al final siempre será la misma y pasará en cada nivel de profundidad de la web por una de estas situaciones:

1. En este punto no necesitamos enlazar a item:

Hay otras zonas de la web que también van a enlazar a todos los ítems de este listado y además con una semántica más acertada o a lo mejor incluso con mayor autoridad. No necesitamos esta paginación así que proponemos eliminarla.

Esto es arriesgado, que Google no necesite ver estas paginaciones no significa que los usuarios no lo usen. Así que cualquier decisión de este tipo debería venir siempre acompañada por un análisis del uso de la paginación. Esto con Google Analytics y un poco de control sobre las expresiones regulares es fácil de probar.

Analizamos del total del tráfico que llega a la página 1 del listado, que porcentaje decide acceder a la 2, a la 3, etc. Encontraremos en muchísimos casos que el porcentaje de gente que no usa la paginación es enorme y además como muchas veces los que sí que la usan son usuarios de baja calidad (no convierten). Con estos datos podemos definir perfectamente el impacto que tendría eliminar la paginación en cifras de negocio para validar si eliminar esta paginación es una decisión arriesgada o no.

Pero, ¿y si resulta que la gente si que usa la paginación? Como decía antes una de las opciones sería no eliminarla para ellos: ofuscar esta paginación o trasnformarla en una paginación javascript con técnicas parecidas al scroll infinito o con botones “siguiente” que solo hacen llamadas por javascript y no con enlace.
Otra opción que nos gusta proponer en algunos puntos es testear cambiar la paginación por un bloque que de forma elegante venga a decirle al usuario que si quiere más contenidos debería filtrar los resultados. Una especie de menú bajo el listao que invita al usuario a usar otras categorías del site. Lo sorprendente de estos tests es que en la mayoría de los casos no solo no aumentan el rebote ni disminuyen el número de páginas vistas sino que suelen subir la conversión al invitar al usuario a navegar por lo que realmente anda buscando.

2. En este punto necesitamos paginar, pero no ofrecer toda la paginación posible.

También se dará el caso de zonas donde tenemos que paginar si o sí para que Google encuentre todos los productos posibles, pero tampoco necesitamos llegar a toda la paginación posible.

Esta también es una de las posibles soluciones rápidas cuando vemos por ejemplo que los usuarios si usan la paginación pero apenas ninguno pasa de la página X. Muy pocos usuarios están tan interesados como para ver más de 5 páginas de productos tuyos y eso Analytics nos lo va a desvelar.

También es algo que puede pasarnos en negocios con una altísima publicación. Ya no hablamos de catalogos que más o menos son estables sino de marketplaces donde los productos aparecen y despararecen o sistemas de noticias o con publicaciones de usuario que en un solo dia igual se publican 50 o 200 items nuevos. En esos casos ayudar a Google a descubrir las novedades es vital para que sea consciente de nuestro nuevo contenido así que pasamos por el aro y le dejamos paginar para que lo descubra.

En estos casos lo primero es limitar esta paginación. A partir de cierto punto debemos volver al punto 1 y hacer desaparecer la paginación ofreciendo al usuario otras soluciones (seguir paginando con javascript, elegir categorías más profundas, etc.). Esto no siempre es fácil de programar (sobretodo en CMSs ya creados) pero puede hacerse.

Luego es recomendable volver a auditar esta necesidad de paginar cada cierto tiempo ara ver si sigue siendo la misma que cuando lo decidimos: igual ahora necesitamos más paginas que hace unos meses o todo lo contrario, ya no hacen falta tantas.

Cuando tengáis este problema también os tengo que aconsejar que no lo limitéis todo a las paginaciones, es posible que lo que os haga falta es algún tipo de taxonomía que permita acceder a listados más cortos donde no haga falta paginar tanto en lugar de paginar (recordad que una página de taxonomía o subcategoría es mucho más eficiente para SEO porque si puede optar por posicionar ciertas keywords aunque sea en el long tail).

3- Dejar la paginación con un acceso libre.

Y por último tendremos esos puntos críticos donde o dejamos a las arañas pasar o no verán los productos nunca. Ahí deberíamos abrir la paginación. A vuestro criterio dejo el cómo: si con next/prev, si con noindex/nofollow, pero hay que dejar a las arañas pasar.

Yo soy más amigo de abrir la puerta del todo: si quiero que la araña pase la invito a pasar y no le pongo ninguna traba. Estoy perdiendo crawl Budget y autoridad, ¡si! No puedo olvidarme de que eso está sucediendo pero a fin de cuentas es que justo es eso lo que busco en estos casos.

¿Cuándo hago cada tipo de paginación?

Pues aquí es donde tus dotes como SEO entran en juego y todo dato que mires será poco para poder definir correctamente…

Dibuja tu árbol de navegación, pasa un rastreador para saber cuantos niveles de distancia (level en screaming frog) hay de cada punto a la home. Descargate en la medida de lo posible todo tu catálogo sabiendo a que categorías de varios niveles pertenece cada ítem. Así sabrás que necesidades reales tienes de indexarlos.
A partir de ahí diseña (en una tabla mismo) qué hacer con cada nivel de profundidad en tus categorizaciones:
– ¿Que haremos con la home del catálogo?
– ¿Y en las categorías de primer nivel?
– ¿Y en las de segundo?
– ¿Y en las de tercero?
– ¿Y en las de taxonomía?
– ¿Y en los filtros por provincia y población?
– ¿y en los autores?

Cada posible listado paginado debe tener su definición: vamos a cargarnos su paginación o no. Y de hacerlo eso que provocará en los productos.

Una solución típica que sirva como ejemplo (pero no para aplicar a lo bestia)

Os voy a poner como ejemplo cómo acaban siendo las cosas cuando juegas con las paginaciones de esta forma.
Por lo general empiezas con la propia home del catálogo viendo que ahí se pagina todo el catálogo hasta el infinito (si tenemos 50.000 items, ofrecemos 500 páginas). Eso vemos que no nos aporta porque esos ítems van también a ser indexados desde las categorías. Así que decidimos dejar de indexar la paginación de la home. ¡Fuera enlaces!

Seguimos con las categorías de primer nivel y si el site es grande nos pasará lo mismo y las eliminaremos también.

Y así seguiremos bajando hasta que realmente empecemos a tener problemas para indexar los productos y decidamos que algunas páginas si que vamos a indexar, más que nada por las novedades.

Y terminaremos en los nodos finales, las categorías de último nivel o categorías + localizaciones de último nivel donde tendremos que dejar la paginación abierta para que se pueda rastrear todo el catálogo.

Lo que conseguimos con una estrategia de este tipo será que las arañas se entretengan sobretodo con los primeros niveles de categorización (y sus productos/items estrella). Esas páginas acabarán nutridas de una altísima autoridad interna con lo que podrán pasársela a las categorías de niveles inferiores para que las trabajen. Es más, dado que las arañas ya no se entretienen con las paginaciones podremos permitirnos el lujo de poner más enlaces a categorías o incluso en un menú saltar 2 niveles de profundidad de categorías de golpe. Todo son ventajas.

Las categorías de menor nivel quedarán un poco relegadas y las páginas de ítem/producto serán el último escalón… no tiene porque ser un problema pero no suena bien, así que seguramente a partir de esa definición hagamos también una estrategia de link sculping para acercar los contenidos que más nos interesan que por culpa de estas acciones hemo alejado.

¿Veis por donde van los tiros?

Bien, pues no hagáis esto. Hacedlo vuestro, llegad si queréis a esta misma conclusión vosotros solos en cada proyecto porque al llegar ahí tomaréis alguna decisiones distintas por el camino. No siempre limitaréis las paginaciones en el mismo punto ni usareis los mismos recursos para hacerlo posible, hay mil detalles a definir por el camino pero solo si el análisis lo habéis hecho vosotros mismos percibiréis esos detalles.

¡Vaya parrafa! ¡Y cuanto trabajo! Si yo solo quería un truco…

Es que el SEO no va de trucos… Al menos no el que acaba siendo realmente rentable. Pero bueno si me pedís normas que más o menos vayan a funcionar y os habéis aburrido leyendo intendad al menos probar esto:

En un site grande no permitáis a Google acceder a paginaciones por debajo del nivel 4 de rastreo. Esos 4 niveles son vuestro core y no lo queréis ensuciar. Diseñar muy bien esos 4 niveles y solo a partir de ahí abrid el grifo de los enlaces inútiles. Solo con eso ya mejoraréis mucho vuestro rastreo y autoridad internas.

Ahora, despues de probar esto y ver que funciona, volved atrás y diseñarlo bien, porque seguro que se puede hacer mejor que con un simple truco…

Google ha dejado de ser un buscador 21 Nov 2018 2:43 AM (6 years ago)

Vivimos un momento extraño en el mundo del SEO. Hace un año o poco más yo no paraba de repetir a la gente que «el SEO ha vuelvo a ser divertido», principalmente porque volvía a suponer un reto y nos obligaba a volver a probar y reaprender las cosas. Divertirnos nos divertimos. Pocos entramos en esto del SEO si no disfrutamos investigando las tripas de Google. Pero la verdad es que, a día de hoy, no lo tengo tan claro como hace solo unos meses. Cuando los cambios en rankings empiezan a no tener una explicación del todo clara y se suceden muy rápidamente acabas con la sensación de que te están cambiando las normas del juego al que llevabas jugando ya muchos años y es cuando empiezas a replantearte todo lo que sabías. Hoy, los golpes a nuestra visibilidad van sucediéndose para bien o para mal al ritmo de los «core updates» que va lanzando el maldito buscador. Han conseguido despistarnos, para que negarlo, y aunque sabemos que será por poco tiempo también tenemos claro que muchos cambios son más drásticos y profundos de a lo que Google nos tenía acostumbrados ¿Estamos en un punto de inflexión en el que vamos a dejar de entender el SEO?

Soy un exagerado, si, las bases del SEO siguen ahí. Aportar calidad técnica, autoridad u orientar bien contenidos de un site nos beneficia con un ROI a la larga del que ningún otro canal de tráfico puede presumir. Esto no ha cambiado y el SEO hoy es si cabe aún más necesario de lo que ya era para los negocios. No, este no es un post sobre la muerte del SEO, es un post sobre la muerte del buscador de Google, al menos de ese buscador donde buscábamos keywords, o más que muerte, su transformación en algo más útil para la gran masa de usuarios que lo usa, es decir, más útil para todos.

La keyword exacta y su anunciada muerte

En SEO hablar de Keywords es peligroso. Como con tantos otros términos -por ejemplo, el PageRank o reputación- todos hablamos de keywords, pero cada uno interpreta un matiz distinto al interiorizar el término en su trabajo.

«Palabra Clave» para mí siempre significó el término exacto de búsqueda que escribes en la caja de búsqueda, de esta forma «hoteles baratos» es una keyword, «hotel barato» es otra distinta y «los hoteles más baratos» es una tercera keyword. Todas ellas son semejantes pero distintas, al fin y al cabo. Esta ha sido siempre la acepción más clásica del término, pero lo cierto es que en la comunidad empieza a existir otras acepciones: hay gente que entiende «keyword» como algo más amplio y ambiguo más cercano a significados o semánticas. Así que debo aclarar que, para el resto de este post, cuando hablo de keyword me voy a referir a las búsquedas exactas (las que escribimos en la caja de búsqueda del buscador).

El fin, que la keyword (exacta), como base del buscador ha muerto, ¿qué duda cabe? Ahora posicionamos otra cosa distinta, que se parece, pero no es lo mismo. A muchos nos ha costado mucho tiempo darla por muerta porque es algo demasiado esencial en el SEO que veníamos haciendo. Pero Google, poco a poco, ha conseguido matarlas y nos ha dejado un poco huérfanos y desubicados en cuanto a nuestra forma de trabajar: Nos las quitaron del análisis con el (not provided) y luego empezaron a «interpretarlas» y mezclarlas. Queda ahora muy poco de lo que era el análisis prácticamente matemático y estadístico de keywords exactas por volumen de búsquedas y menos aún de las SERPs en las que búsquedas muy similares daban resultados muy distintos.

Pero también tenemos que ser claros, las keywords no han desaparecido de nuestro trabajo como SEOs y esto es porque -humildes mortales- no somos capaces de trabajar sin ellas. No quiero que con este post nadie pueda entender que hacer un análisis de keywords se ha vuelto inútil ni tirar por tierra la metodología de trabajo de nadie: Necesitamos evaluar volúmenes de búsqueda y de competencia para saber hacia que orientarnos y para eso necesitamos hablar de keywords porque a día de hoy no hay herramientas que nos permitan ver el mundo de otra forma.

Otro tema es cómo aplicamos ahora estos análisis de keywords a nuestros negocios. Eso sí que ha cambiado y mucho. Ya no obedecemos, ya no elegimos las 3 mejores y las vamos aplicando a lo bestia sobre nuestros sites (algunos no hicimos eso nunca en realidad, pero ya me entendéis). Ahora estos análisis son información sobre búsquedas y términos exactos que podemos llegar a usar en un texto, pero ya no escogemos una KW exacta y vamos “a muerte” a por ella. Ahora se trata de aproximarnos a semánticas con una colección de términos muy similar y nos importa un poco menos cual usamos exactamente en title y h1. Como decía, todo se ha vuelvo más humano y menos matemático, pero las bases siguen ahí y nos quedan muchos análisis de keywords por delante para saber cómo orientar nuestros sites.

Así que las keywords a día de hoy son un recurso que necesitamos los SEOs para trabajar con datos estables y entendibles, pero ya no son la base real de las búsquedas de Google. Y esto es así porque Google ya no va de «encontrar palabras en los textos» sino que quiere ser el ente sabelotodo que te soluciona tus problemas y te hace la vida más fácil cuando decides preguntarle algo. Hemos pasado de un buscador de palabras a un buscador de soluciones.

Google es una herramienta mejor de lo que era, pero nos cuesta entenderlo

Una demostración clara de que el buscador ha cambiado y ha abandonados las keywords la tenemos en que tras cada update del algoritmo los de la vieja escuela, a los que Internet nos llegó ya en nuestra adolescencia o aún más creciditos, se nos hace más difícil sacar partido de este moderno buscador que no busca como nosotros estamos acostumbrados a buscar. Y tras frustrarnos al no encontrar los textos que le pedimos, pasamos a atacar a Google y a sus ingenieros. ¡El buscador va cada vez peor! ¡Cada día es más tonto!
A muchos de nosotros nos habrás visto en eventos criticando que los resultados de las búsquedas de Google son cada vez peores. ¡Que viejos estamos! … ¡y qué equivocados!

¿Por qué nos pasa esto?

Pues creo que porque a muchos Google nos educó y aprendimos a buscar “keywords” en su caja de búsqueda. Y a día de hoy seguimos buscando «keywords», términos exactos que queremos que aparezcan en una web. Buscamos «oferta comprar bicicleta barata» esperando que un SEO haya puesto estas palabras en sus titles.

Además, como pensamos en keywords usamos el sistema de ir complicando las búsquedas que hacemos en el buscador, añadiendo detalles para encontrar esa frase exacta en un post perdido por Internet que nos dé solución a nuestros problemas. Si tengo un problema con un electrodoméstico empiezo por “problema nombreElectrodomestico” y acabo buscando “solución problema nombreElectrodomestico err305 pantalla led parpadea”… y es que parecemos más robots que el propio Google.

Buscamos «keywords» y las «keywords» están muertas para Google. No importa que a ti querido hard user de internet te funcionase muy bien buscar por Keywords complejas en el pasado, tú no eres nadie y Google tiene las miras mucho más altas. Apunta a ser mucho más útil para la gente normal y si tú no eres “gente normal” igual el problema es tuyo, no de Google.

Google, a nuestro lado, nuestro amigo, siempre a nuestro servicio

No sé en qué momento pasó esto, podría intentar definir varias fechas como punto de inflexión, pero me equivocaría. Lo que sí es evidente es que Google en algún momento ha dado un giro en el objetivo final de su buscador. Hemos visto como se ha adueñado de gran parte del ecosistema móvil y persigue adueñarse de nuestras casas y nuestra rutina y necesidades mundanas. Lo que mal llamamos “la búsqueda por voz” es mucho más profundo que solo el medio de entrada de la búsqueda y en realidad persigue facilitarnos cada aspecto de nuestra vida, ya no solo informativa (que también) sino nuestras necesidades de hacer, obtener y disfrutar de las cosas. Google Home, Google Assitant, Chromecast, Nest, etc. Son solo pequeñas piezas de un futuro Google capaz de servirnos todo lo que necesitemos. Pensad en ello: Todo puede facilitarse por una maquina bien educada y la tecnología adecuada aplicada a ella.

A Google aún le queda mucho para que esto suceda, pero en realidad afectar a nuestras costumbres es algo muy lento y mirado desde esa perspectiva está metiéndose en nuestra vida a una velocidad abrumadora. Lo tengo claro: Todos veremos cómo esto sucede y cómo nuestra vida cambia aun más de lo que ya lo ha hecho. Igual no gana Google al final y nuestro solucionador del día a día es otro (Alexa, Siri, etc.) pero que vamos a ser aún más vagos (y al mismo tiempo eficientes) de lo que ya somos está clarísimo. Todo esto es sin duda apasionante, pero dejemos el futuro y centrémonos en el momento actual y en la intención detrás de esa megaempresa que es Google…

Este cambio de meta que se ha producido en Google, por supuesto, tenía que acabar afectando a lo que es «el buscador». Y tiene sentido, si Google se orienta a «solucionarnos cosas» por qué su caja de búsqueda, su máximo exponente, va a limitarse a «encontrarnos cosas». El camino de Google debe ser dejar de ofrecernos contenido y pasar a ofrecernos soluciones. Un pequeño cambio de concepto, pero que si se aplicase de un día a otro en el buscador este cambiaría las reglas del juego radicalmente. ¿Tan radicalmente cómo están cambiando ahora? No, mucho más, lo divertido es que los SEOs estamos “flipando” pero realmente Google está siendo muy suave con los cambios.

Estoy convencido de que lo que estamos viviendo en el mundo SEO es un camino lento en este sentido. Vamos con updates desde hace más de un año, cada uno igual muy específico, pero que entre cambios de posiciones van transformando al buscador en una herramienta destinada a solucionarnos la vida y esto, claro, va en detrimento de ese buscador de documentos, posts y comentarios exactos al que nos tenían acostumbrados.

Search Intent, Intención de búsqueda o el gran cambio de Google

Y bueno, alguien tenía que ponerle nombre a esto y lo llamaron «intención de búsqueda» o “search intent”: una capa que se añade al buscador y que ya sea gracias a la estructura de Google Hummingbird, a la potencia de interpretación de Google Brain o a lo que sea que apliquen busca «entender que quieres realmente» para ofrecértelo.

Google quiere saber la necesidad que esconde la búsqueda que has escrito. Porque, como te digo, a Google le da ya igual lo que escribas, lo que él quiere es solucionarte la vida y por eso debe interpretar tus intenciones y darte lo que necesitas, sea una página, servicio, producto mapa o lo que sea. Que en la mayor parte de los casos se vean obligados a darte páginas web de terceros para resolverte tu problema es solo un detalle, no pueden ofrecértelo todo directamente ellos, claro (y si pudiesen tienen unos cuantos gobiernos haciéndoles pagar multas por monopolio y tampoco puede pasarse demasiado). Pero han decidido que deben encaminarse a saber que necesitas para luego decidir quién es el que mejor resolverá esa necesidad. Y esa necesidad -y ahí está el punto dramático- muchas veces no se soluciona con contenido textual.

Un vistazo a las Guidelines de Google nos clasifica para los Quality Raters las intenciones de búsqueda que a nivel muy macro maneja Google.

• Link Guidelines (Mirad página 68 en adelante)

Recordad que veníamos de una versión anterior muy antigua que nos presentaba una clasificación de búsquedas que se quedaba en «informativas», «navegacionales», «transaccionales» y «multimedia». Era una forma más especializada y centrada en clasificar «WEBS» y solo webs. Ahora pasamos al mundo de las intenciones de verdad: Google clasifica lo que quiere el usuario y ya verá con eso lo que le va a dar como respuesta. Son dos pasos separados: saber que necesitamos y ofrecernos la respuesta más adecuada.

Google clasifica las búsquedas en KNOW (saber), DO (hacer), Websites (páginas) y Visit in Person (localizaciones). Todas ellas son necesidades. Son lo que Google quiere/puede/podrá-algún-día resolvernos. Quiere ayudarnos a saber cosas, a hacer cosas y a encontrar las webs y lugares que buscamos y esta clasificación sin duda le ayuda más en este cometido que simplemente clasificar búsquedas textuales cómo hacia antes. Lo mejor es que esta nueva clasificación no vale para ahora, vale para siempre que Google siga persiguiendo su intención de ayudarnos y solucionarnos cosas en lugar de encontrarlas.

Ofrecer soluciones implica especializarse en cada una de ellas

Si contratas a un “manitas” que lo mismo te pone un muro que te cambia una tubería o te arregla unos enchufes ya sabes que te la estas jugando: No es un especialista y puede provocarte problemas en un futuro. En definitiva, puede no darte la solución óptima. Si alguien te preguntase y te exigiese que le recomendases a alguien que fuese a solucionarle un problema de la forma correcta seguramente no recomendarías a tu manitas (tu reputación y marca están en juego y podría liarla), deberías antes saber en qué puntos es realmente bueno y ofrecerle solo para esos trabajos.

Google ha decidido vivir de recomendarnos siempre la mejor opción ante nuestras necesidades. Para poder hacerlo debe especializarse y entender qué parámetros entran en juego al ofrecer cada tipo de solución. El mundo es muy grande y nuestras necesidades muy variadas así que -al menos de momento- no podemos esperar que desarrolle unos parámetros muy especializados para cada necesidad, pero si que especialice o pondere sus criterios de posicionamiento para cada necesidad (o intención de búsqueda).

Si buscamos contenido es lógico que la calidad de este contenido sea importante, si necesitamos comprar algo la fiabilidad del proveedor, su catálogo, precios y reputación entrarán en juego y si buscamos respuestas muy concretas la fuente más fiable y directa debería darnos la respuesta.

¿Estamos diciendo que los criterios por los que Google posiciona los contenidos no son los mismos dependiendo de qué le estoy pidiendo? Pues sí, solo que sin ser absolutistas al afirmarlo. Es decir, hay cierta especialización que cada día es mayor y por lo tanto más evidente pero ni mucho menos eso significa que los criterios base desaparezcan ni que esto sea así en absolutamente todas las búsquedas:

• Tu contenido tiene sentido, aunque quizás para solucionar algunas necesidades ya no es el rey.
• Los enlaces de calidad aportan autoridad, pero igual ya no se trata solo de que vengan de sitios relevantes sino que a veces importe más tu autoridad dentro del sector que la genérica
• La indexación y los criterios de calidad técnica siguen ahí, pero habrá páginas y dispositivos desde los cuales una experiencia técnicamente impoluta importe más que en otros

Qué criterios funcionan ahora con cada tipo de búsqueda

Bueno, ¿Quién lo sabe? Hay tantos tipos de búsqueda… Lo mejor es que cada uno en su negocio observe su sector, las intenciones de búsqueda a las que quiere dirigirse e investigue qué está primando Google. Y ahí pensemos un poco “out of the box” sobre todo pensando en que Google igual ha dado pasos especializándose en algunos sectores (y sabiendo que cuanto más dinero mueva ese sector más se habrá especializado).

Y si bien es imposible definir estos criterios, porque además de muy variados y cambiantes resulta que no tenemos datos para hacerlo y al ser especializados los datos de otros no nos sirven, lo que si podemos intentar es ver a grandes rasgos qué está pasando con distintos tipos de intenciones de búsqueda.

Para hacer esto voy a unificar los 4 search intents que nos definía Google en sus Guidelines y quedarme con sólo 3. La verdad es que si lo tomamos todo en global la diferencia entre un “busco marcas o sites” o “busco localizaciones físicas” es muy pequeña. Es gente buscando cosas que existen. Así que vamos a desarrollar a muy grandes rasgos qué está haciendo Google con las búsquedas “KNOW”, “DO” y “FIND” (siendo la última la que aglutina websites y locations).

KNOW: El contenido sigue siendo el rey

Cuando queremos saber cosas Google toma dos caminos distintos.

Por un lado, está la posibilidad de que sólo queramos conocer algo concreto (un dato, una definición, etc.), eso es lo que Google Llama “KNOW SIMPLE QUERIES” y ahí sin duda se han especializado muchísimo. Incluso han alterado la SERP para crear lo que ahora llamamos “resultado 0”, cajas de respuesta directa a lo que buscamos.

En este terreno lo que importa ahora es responder a la pregunta del usuario correctamente, tener credibilidad suficiente y ser muy concretos (se nos habla de un par de frases). Podéis leer muchas estrategias por distintos blogs para conseguir resultados 0 pero creo que lo importante es entender que lo que tienes que hacer es dar respuesta a estos “KNOW SIMPLE QUERIES” de forma concreta. Es decir, podemos usar herramientas como Answer the public para saber qué preguntas se hace la gente sobre una entidad, pero luego no se trata simplemente de meterlas en un H2 a ver si hay suerte… se trata de que nos esforcemos en responderlas de forma correcta, clara y directa en un solo párrafo. Por eso hay gente que, dependiendo de su forma de redactar, tiene mucho éxito buscando este tipo de resultados y gente que no consigue ni uno.

Bien entendidos los avances en este terreno lo que nos queda son las búsquedas en las que el usuario quiere saber algo, pero o no está tan claro qué dato quiere, o hay varias posibles respuestas o es imposible responder brevemente a su problema. En estos casos estamos en las “KNOW QUERIES” normales y estamos de suerte porque al tratarse de contenidos Google sigue con criterios de posicionamiento muy similares a los de hace años para posicionar todo esto.

Es decir, todo lo que sabes desde hace tiempo de SEO si lo que haces es orientarte a textos académicos, a blogs especializados como este, a explicar procesos y how-to’s o a dar información al público (revistas, noticias, etc.) sigue funcionando más o menos igual. Por eso tras cada update vemos que quienes más se quejan o bailan de alegría son sites de otro tipo.

Tenemos el añadido del E-A-T, que nos deja claro que un contenido textual debería ser medido por la experiencia que demuestra en el terreno, su credibilidad y su autoridad en el sector pero sabemos que medir un E-A-T de verdad sería mucho gasto de proceso y Google debe tenerlo en cuenta como guía pero no como algoritmo desarrollado.

Por último haría el matiz de que el sector noticias hace tiempo que tiene su propia especialización, pero también es cierto que no es ahí donde están los grandes cambios del año.

DO: lo importante es que puedas hacer lo que te propones

En DO Google nos detalle varias posibles acciones que puede querer hacer el usuario. Para empezar, nos diferencia las “DEVICE ACTIONS” del resto. Y si bien esto no tiene mucho sentido para los SEO, si lo tiene en un Google que busca encaminarse a solucionar cosas y no solo ofrecer webs. Las device actions son acciones que buscan interactuar con el internet de las cosas y para daros una pista Google ya especifica que suelen venir precedidas de llamadas al sistema tipo “ok Google”, “siri”, “Alexa”, etc.). Son este tipo de búsquedas que lo que van a provocar es interacción con la IA correspondiente. Cómo os decía a los SEO esto nos debería preocupar poco (al menos a los que nos dedicamos aun a posicionar webs en HTML).

Fuera de las DEVICE ACTIONS tenemos las acciones normales que Google nos cataloga en las siguientes:

• Download: El usuario quiere descargar algo
• Buy: El usuario quiere comprar un producto
• Obtain: El usuario quiere obtener el objeto de su búsqueda pero no comprándolo
• Be Entertained: El usuario busca divertirse y pasar el rato
• Interact: El usuario busca interactuar con algún sistema en concreto

Sin duda esta clasificación es relevante y debemos ofrecer cosas distintas al usuario para cada una de ellas, pero por lo que estamos viendo no deberíamos tomarla como algo genérico: es decir, no tiene por qué posicionarse exactamente con los mismos criterios todo lo que sea “BUY”.
Aquí lo que importa (según vamos viendo en los distintos updates) son dos cosas.

1. La necesidad de responder a la intención de búsqueda:

Esto lo vimos claro con los primeros al ver como si no se podía realizar la acción que el usuario demandaba al llegar a tu site lo normal era que este empezase a caer más y más posiciones (con excepciones).

Ya no tiene sentido que con un blog ataque a búsquedas de acción. “Comprar zapatillas baratas en Mallorca” nunca fue un buen titular para un post pero es que ahora además difícilmente traerá tráfico pues nuestro articulo es poco probable que resuelva la intención de búsqueda de “compra” y con ese tipo de keyword es poco probable que Google interprete la búsqueda como del tipo “KNOW” que es lo que nos interesaría para que el blog tuviese alguna oportunidad.

Por otro lado, muchos grandes sites que estaban viviendo de una gran autoridad y que se permitían atacar a muchas intenciones de búsqueda con la misma página van viendo cómo Google les especializa en las que realmente resuelven y van perdiendo tráfico de todas esas búsquedas a las que accedían solo por ser quienes eran. Muchas de estas caídas de tráfico además las vemos comentadas como “hemos perdido mucho tráfico, pero apenas nos ha afectado en conversión” lo cual deja muy claro que Google tan mal no lo ha hecho.

Que hay de todo y hay gente que ha subido sin merecerlo y que ha caído teniendo webs muy decentes pero este criterio en mayor o menor medida suele estar detrás de muchos de estos bailes.

2. La especialización de criterios de posicionamiento en el sector

Otra de las cosas que parece que están sucediendo es la especialización de criterios de posicionamiento para distintos search intents. Y esto debería tener una doble lectura: por un lado “tiene pinta de que” (es decir, que no me pidáis ni un dato, es solo una intuición) se pasan a valorar aspectos relativos al objetivo perseguido. Y es que si lo que yo quiero es comprar algo el que Google pueda encontrar ese ítem en mi página (schema) y sepa si tengo un buen precio debe indicarle si va a resolver mejor cierto tipo de búsquedas que le hagamos, o por otro lado no sería descabellado pensar en que si ofrezco descargas criterios más técnicos entren en juego. Pero lo dicho, es solo una intuición.

Lo que tengo más claro es que los criterios de autoridad tienden a especializarse en el propio sector. Es decir, ahora que tu competencia te enlace es más relevante que lo hagan los 300 blogs que compraste en su día. Es decir, que muchos criterios SEO de posicionamiento pasan a ponderarse por su relevancia con la intención de búsqueda del usuario. Esto no es nuevo, llevamos tiempo diciendo que es mejor centrarse en nuestra temática, pero para mí hay algunos cambios: ya no lo decimos para no ser penalizados, sino para posicionar y además ya no hablamos de similaridad de la keyword sino del sector. Es decir, que, si yo pido en un blog no relacionado con la venta de bicicletas un post con enlace, por mucho que hable de bicicletas no es lo mismo…

¿Y el contenido? ¿qué pasa con el contenido?

El contenido está ahí, pero si lo que el usuario busca es realizar una acción el propio contenido y sobretodo la cantidad necesaria para que el usuario cumpla su cometido pueden estar en entredicho. Si un usuario puede cumplir su intención de búsqueda perfectamente sin contenido, ¿por qué Google no iba a posicionar bien ese resultado? Seguramente ya esté funcionando en parte de esta forma y el contenido en búsquedas DO no sea el rey. En búsquedas DO la acción y sus garantías deben ser los nuevos monarcas. Pero eso no significa que no necesitemos contenido porque al fin y al cabo el análisis de la página se va a seguir haciendo y si Google no encuentra en nuestro contenido qué vendemos y porqué es bueno que nos lo compren difícilmente apareceremos en los resultados de búsqueda. Lo que seguramente iremos viendo es que prima más explicar bien el producto y la acción que queremos que el usuario haga con él que escribir 5 parrafos sobre el mismo.

FIND: deja que te encuentren

Por último, en las intenciones de búsqueda de websites o localizaciones (y sumaríamos de personas, marcas, etc) en realidad no tienen tanto misterio. Si eres tú, márcalo para que te puedan encontrar. Es decir, también haz un seo clásico de marca contando con que cualquier búsqueda de la misma juega a tu favor y debes dedicarle recursos:

• Trabaja muy bien Google My Business
• Trabaja tu quienes somos y demás aspectos identificativos
• Trabaja en entender por qué nombres te buscan: qué expresiones de marca y especializaciones locales o de sector existen
• Incluye tu marca/nombre y sus especializaciones en las páginas en las que puedan buscarte por ella. Poca cosa, el típico final de title suele funcionar

Y poco más, haz un buen seo técnico y vigila la indexación y todo llegará.

En resumen

Os dejo un gráfico que he hecho para resumir todo esto que os cuento. No esta todo pero como guía no viene mal (haz click para ampliar).

 

¿Lo complicamos un poco? Todo esto no es tan simple: Una búsqueda puede tener más de una intención de búsqueda

Si el tema de especializarte en search intents te parece poco piensa además que Google hace tiempo que no hace un solo cálculo por búsqueda. Vemos señales que nos indican que parte el SERP (y sobre todo su primera página) de forma distinta para distintos search intents y momentos.

Por ejemplo, cuando buscamos algo muy concreto deberíamos estar en una “KNOW SIMPLE QUERY” y Google nos saca su resultado, pero luego rellena el SERP (por si acaso) con las reglas de una “KNOW QUERY” normal. Es decir, entiende ambas intenciones de búsqueda y las prioriza en la visualización de la SERP. Esto además lo vemos cuando analizamos muchas de estas búsquedas: Nos encontramos con que a veces tiene claro que queremos una respuesta y nos lo muestra más priorizado (respuesta en resultado 0 y además cuadro de knowledge en la derecha) y otras no lo tiene tan claro y el resultado 0 aparece por ejemplo entre el 5 y el 6.

Otras señales de esta evaluación de varias intenciones de búsqueda para una misma keyword las tenemos en las búsquedas más genéricas. Si buscas “restaurantes” encontrarás muchas intenciones mezcladas: una parte del SERP se entenderá como una búsqueda por cercanía (restaurantes más cercanos a donde estoy), otra se localizará, pero con información de negocios (quiero reservar en un restaurante en mi ciudad) e incluso podemos ver los grandes agregadores de negocios por si lo que busco es interactuar con una plataforma de reservas.

Al final el proceso es siempre el mismo

Una Keyword: Google extrae y prioriza distintas intenciones de búsqueda, las resuelve y dibuja un SERP que represente las más relevantes. Para poder hacer este dibujo lo que necesita es definir que bloques destina a resolver cada intención y eso nos dibuja distintos layouts de SERP.

Incluso temporalmente dependiendo de factores como el volumen de búsquedas que se hacen de un search intent o los movimientos que hace el propio sector podemos ver cómo este diseño cambia facilitando unos search intents u otros al usuario.

Os pongo un ejemplo claro: ahora estamos en Black Friday por lo que ante la duda es normal que Google en la primera página de la búsqueda al ver que los search intent de compra se están disparando nos deje al menos el TOP3 o TOP5 para búsquedas de ese search intent dejando resultados que respondían a otros más abajo o directamente en la paginación.

¿En qué me afecta una keyword que se resuelve con varias intenciones de búsqueda?

Para nosotros esto al mismo tiempo es importantísimo como que nos debería dar exactamente igual. Es decir, estratégicamente debemos saber que la semántica (o el conjunto de keywords, como quieras llamarlo) que potenciamos en nuestra página Google lo está resolviendo con uno o varios search intents. Básicamente porque nosotros difícilmente atacaremos a varios de ellos por lo que es importante saber en página 1 que oportunidades tenemos de salir.

Es decir, imagina que apuesto en un post por “restaurantes en Mallorca” (y todas las keywords relacionadas con ese mismo search intent). Al hacer esto estoy atacando a un search intent del tipo KNOW porque con un post difícilmente optare por gente que quiere reservar (search intent tipo DO OBTAIN) o que busca un restaurante en particular (FIND LOCATION).

Si me encuentro que para ese tipo de búsquedas Google ofrece una SERP que se dedica en un 80% a los otros dos search intents y relega a sus dos últimos resultados el de KNOW, se que lo tengo muy difícil y que solo para optar por alcanzar la posición 8 ya tengo que ser el mejor.

(que esto no es fijo, pero si me da una idea de que no voy con la mejor estrategia posible por delante)

Por otro lado, una vez se que tengo que ir a por una intención de búsqueda ya no importa cuantas tenga esa keyword en concreto, yo haré lo mismo: mi HTML será igual y los enlaces que pudiese necesitar también, independientemente de cuantos search intents aparezcan en ese SERP.

¿Y por qué no ir a por varias intenciones de búsqueda con la misma página?

Podría parecer que si Google cubre con una búsqueda 3 intenciones de búsqueda el contenido que las resuelva todas debería ser el mejor, pero esto no es así sino más bien al contrario. Es decir, cuando Google destina un espacio a un resultado que permita comprar un producto se posiciona ahí por vender ese producto y solo por eso.

Eso significa que todo lo que hagamos de añadir contenido a destajo sin fijarnos en la intención de búsqueda en realidad juega en nuestra contra porque a Google le sirve para ver que no estamos cumpliendo con el search intent que el ha detectado. Este es otro tema que vamos viendo en los sucesivos updates como muchos resultados que caen lo hacen por haber perdido la orientación a lo que realmente hacían: Listados de productos con descripciones genéricas del producto que no hablan de comprarlos ni de la tienda, páginas de servicios que se llenan de how-to’s y pierden posiciones cuando se busca un profesional que preste ese servicio o páginas de destinos posibles de una hotelera que al centrarse en describir con 5000 palabras el destino no reciben visitas relacionadas con hoteles en ese destino.

Por qué muchas webs están bajando y seguirán bajando de tráfico

La respuesta es sencilla: porque Google no percibe que den soluciones a la búsqueda del usuario. Aquellos negocios que se han centrado en ofrecer textos a Google y no soluciones a sus usuarios son los que están sufriendo con todo este cambio. Sobre todo, aquellos que resuelven intencionalidades de búsqueda del tipo “DO” pues son los más afectados en la forma de posicionarse.

También van a seguir cayendo negocios que abordaron keywords e intenciones de búsqueda que no les correspondían. Estos ya no las resuelven por lo que no deben seguir ahí posicionados salvo que empiecen a resolverlas (creando por ejemplo páginas nuevas para esos nichos que ahora se les escapan).

Por último, negocios que se apoyaron en una autoridad genérica, no especializada también están a veces sufriendo (a veces porque muchas veces esa autoridad genérica también les ha hecho estar bien posicionados en la especializada). Negocios que por ejemplo han surgido de la misma matriz y aun dedicándose a cosas totalmente distintas han levantado sus webs gracias a otras webs con gran autoridad de la compañía. O negocios que vivieron muy bien colando links y widgets genéricos y que aun sobrevivían.

¿Son estos los únicos que se están moviendo? No, pero son los que más nos encontramos y muchos otros se explican por los movimientos de estos. Luego claro, como siempre con Google hay expedientes X, cosas que no sabemos porque pasan… al menos de momento.

La gran pregunta pendiente: ¿Cómo sabe Google si respondemos a la intención de búsqueda?

Ahí creo que es donde lo tenemos peor. Google no nos lo va a decir y si lo hace será tan ambiguo que costará entenderle. Teorías hay casi tantas como SEOs.

Algunos miran hacia valores relativos a la experiencia de usuario: CTR y Rebote serían los principales. Son valores interesantes y Google los tiene, pero lo cierto es que son valores fácilmente manipulables y por eso dijo Google que no los usaba. Yo sinceramente creo que son indicadores muy claros de si cumples el search intent pero que Google no los usa. Es decir, habría una correlación clara entre lo que mide Google y estos valores, pero no una causalidad.

¿Qué significa? Pues que analizar el rebote en tus resultados es genial para ver si tu pagina responde bien a las intenciones de los usuarios pero que debemos evitar cambiar ese valor, lo que debemos hacer con el es que les guste más, no hacer trucos técnicos para que reboten menos.

Otras opciones tienen que ver con análisis semántico, detectar entidades y cosas así que le hagan saber que un contenido responde a lo que quiere el usuario. Sin duda esto funcionaría, pero con cualquier cosa avanzada siempre tenemos que pensar que Google analiza billones de páginas web lo que limita el tiempo de proceso que puede permitirse por cada página y te hace poner en duda que realmente haga un análisis de entidades con la misma calidad que se hace en sistemas PNL.

Otras opciones pasan por detectar solo señales. Es decir, si la intención de búsqueda es DO BUY tengo que ofrecer un producto con su precio y un sistema de compra, es más mi site debe ser fácilmente clasificable como ecommerce.

¿Cómo lo hace Google? Aunque hay escritas cosas yo al menos no tengo ni idea. Puede ser un poco de cada o algún dato suelto de cada cosa… o puede ser más simple que todo lo que nos imaginamos. SLo que si sabemos es que cada vez acierta más con las intenciones de búsqueda, pero aun es fácil encontrarle errores garrafales. Sea como sea el camino está marcado y como ya llevamos años diciendo lo único que tenemos que hacer en SEO es pensar en el usuario.

Cómo sacar partido a los Informes de Cobertura de Google Search Console 18 Jan 2018 3:19 AM (7 years ago)

Todo SEO que se precie debería estar actualmente deseoso de disponer de cada vez más y más proyectos migrados al nuevo Google Search Console. ¿No es tu caso? Pues debería serlo… En SEO siempre hemos ido muy faltos de datos claros sobre como nos trata el buscador y estos nuevos añadidos si bien tampoco es que nos resuelvan la vida completamente vienen a suponer una gran cantidad de insights accionables con los que sacar un claro provecho a nuestros proyectos.

El nuevo Search Console, por un motivo que creo que nadie entiende, se está habilitando muy poco a poco en las cuentas. No es nisiquiera que un usuario tenga acceso y otros no, es que proyecto a proyecto y bloque datos a bloque de datos poco a poco se nos va a ir sumando información a este informe. Actualmente si manejas un buen conjunto de proyectos lo normal es que al menos 2 o 3 ya te ofrezcan sus informes de rendimiento y cobertura. Esto se encargan de notificártelo por email pero si quieres probar a ver si se te ha escapado alguno puedes entrar en el nuevo search console con la siguiente URL: https://search.google.com/search-console/index

Dentro de esta nueva interfaz podremos ir al famoso informe de Cobertura: el que para muchos es la gran revolución de información de rastreo e indexación. En él se nos dan suficientes datos para diagnosticar y luego accionar problemas y optimizaciones de indexación en un proyecto. Básicamente se nos está hablando de cómo esta tratando Google las distintas URLS que va encontrando de nuestro dominio al rastrear. Eso, si trabajas en sites medianos o grandes es sencillamente brutal. Vamos a ver como sacarle partido…

Cómo es el informe de cobertura

No me extenderé mucho con este punto. Simplemente es un informe donde podemos ver catalogadas 4 grandes bloques:

• Error: Errores de tu servidor o al servir tus páginas.
• Válidas con advertencias: Páginas que no tendrían que tener problemas pero los tienen por bloqueos.
• Válidas: Páginas que se van de cabeza a las bases de datos de Google para ser servidas en los resultados de búsqueda.
• Excluidas: Páginas que Google estima que ya no deben estar (o no deben estar aun) en los resultados de búsqueda. En realidad este es el estado en el que está todo lo que no está en los demás estados

Esto ya supone una gran mejora de lo que teníamos antes: se nos habla de páginas excluidas, páginas que no pasan los filtros de Google y con las que podremos trabajar al detalle.

Pero hay además 4 grandes puntos o perspectivas desde las que ahora si podemos investigar nuestro estado de indexación y que marcan un antes y un despúes en nuestro día a día como SEOs.

Control de tendencias los ultimos 3 meses y comparado con impresiones

Un gran añadido es el poder ver la evolución de de estos 4 grandes datos en los últimos 3 meses (aun que lo normal es que aun no disfrutes de tanto tiempo pues ha empezado ahora a recopilar la información). Esto en la práctica supone que podemos ver cuando se producen los problemas o las mejoras de optimización pues podemos ver los cambios de tendencia de cada tipo de valor y como un tipo de páginas se transforma en otro con los cambios de la web.

Es decir, que si unimos está información a nuestro histórico de acciones que hemos realizado en los sites que gestionamos o con las subidas de nuevas versiones al servidor tendremls una nueva puerta abierta al aprendizaje y a creación de hipótesis.

El hecho de que además estas gráficas se complementen con las impresiones de resultados en el buscador nos permite descubrir aun de forma más rápida todas las relaciones de causa efecto entre indexación y visibilidad.

Os dejo solo una gráfica sobre esto donde vemos claramente como el hecho de ir aumentando la cantidad de URLs excluidas del indice (páginas y mas páginas que google pierde el tiempo en analizar para que finalmente no formen parte del índice) nos afectó negativamente en impresiones mientras duraba su rastreo. Tambien vemos como cuando este rastreo inutil terminó recuperamos impresiones.

El control de Enviadas y de Sitemaps

De primeras puede pasar un poco desapercibido pero este informe queda muy muy conectado a tu subida de sitemaps haciendo aún más útiles todas las prácticas que solemos realizar a día de hoy de trocear los sitemaps para sacar información por grupos.

En definitiva, podemos seleccionar ver todo el rastreo por libre de Google («Todas las páginas conocidas»), ver solo lo que le enviamos por sitemaps y que idealmente es lo que queremos posicionar («Todas las páginas enviadas») o escoger cada uno de nuestros sitemaps.xml por separado y ver como es el estado de indexación de cada conjunto por separado.

Si unímos esto a la información de tendencias de la que hablábamos en el punto anterior veremos para cada sitemap como ha ido evolucionando su indexación. Vamos que si nuestros sistemaps contienen cada uno tipologías de páginas distintas este filtrado acaba siendo realmente práctico.

Aquí la pena es que la gráfica de impresiones no se filtre por solo las impresiones de las URLs contenidas en el sitemap que estamos viendo pero el resto de valores (Error, Advertencias, Válidas y Excluidas) si lo hacen así que si que supone una gran ayuda para el seguimiento del proyecto.

Los motivos de cada estado

Y aquí es donde todos casi lloramos de alegría cuando empezamos a verlo en algún proyecto: no solo nos dicen el estado de las URLs sino el motivo por el que Google las mete en un estado u otro. Al principio tanta información es abrumadora pero en pocos minutos empezamos a entender lo que supone disponer de toda esta información.

Google Search console tan solo nos muestra en su listado los Motivos que nos afectan, es decir, podemos ver una lista más o menos larga dependiendo de todas las casuisticas que se sucedan en nuestro proyecto. Por suerte nos ha documentado un poco todos los motivos de los que disponen y podemos tirar de su documentación para saber todo lo que no vemos (que también es importante saber todo lo que no nos sucede): https://support.google.com/webmasters/answer/7440203?hl=es

Al final esta lista de motivos es mucho más importante de lo que parece pues práticamente nos indica si lo que vemos es un problmea o no y nos ayuda a saber que podemos hacer para solucionar aquellas cosas que no nos acaban de gustar.

Tratamiento de motivos de Error

– Error del servidor (5xx)
– Error de redirección
– Robots.txt ha bloqueado la URL enviada
– La URL enviada contiene la etiqueta «noindex»
– La URL enviada devuelve un soft 404
– La URL enviada devuelve una solicitud no autorizada (401)
– No se ha podido encontrar la URL enviada (404)
– La URL enviada tiene un problema de rastreo

Muchos de los motivos aqui citados son puramente técnicos y deben remediarse hablando con IT o con sistemas. Sin embargo hay problemas que si nos atañen directamente como redirecciones que son demasiado largas o terminan formando un loops, marcados de noindex, 404 que podríamos remediar con 301, links que le hemos ofrecido a páginas que piden password, etc. Por ultimo tenemos el «problema de rastreo» que viene a decirnos que ni Google sabe exactamente porque ha fallado esa URL… en fin. Nadie es perfecto.

Tratamiento de los motivos de advertencia

Aqui de momento solo se marca un tipo de problema: «Se ha indexado aunque un archivo robots.txt la ha bloqueado»

No hace falta explicar mucho, podemos validar que realmente se bloquea lo que esperamos bloquear. Sobre este punto tenemos que recordar que Google no solo indexa mediante el rastreo de tu site por lo que aunque le bloqueemos con robots.txt una URL el puede encontrarla con señales externas y si quiere indexarla de todas formas.

Este resultado nos puede alarmar un poco al principio: por un lado GSC al darse de alta parece que nos marca muchas URLs de este tipo pero ellas solas acaban desapareciendo de las gráficas sin que cambiemos nada (parece que le lleva tiempo saber que realmente no las ha indexado). De las que finalmente nos quedan muchas terminarán desapareciendo también solas y acabaremos prácticamente con URLs que reciben enlaces externos. Ahi si que tenemos cosas que arreglar:

– Podemos Abrirlas de nuevo (quitando el disallow) del robots.txt y aprovechalas dandoles contenido y enlaces.
– o bien redirigirlas (tambien abriendolas) hacia un punto más interesante con un 301 (o canonical si no queda más remedio).

Forzar desindexarlas porque si (porque nos molestan) a mi al menos no me parece una buena idea. Si no perdemos crawl budget (porque no se rastrean) y no nos están haciendo daño (canibalizando otras páginas) ¿para que vamos a molestarnos en ellas?

Tratamiento de las validas indexadas

-Enviada e indexada
-Indexada, no enviada en sitemap
-Indexada; recomendamos marcarla como canónica

Se nos indican las páginas que realmente va a ofrecer el buscador pero además se nos diferencian por dos criterios:

Por un lado el tema de los sitemaps vuelve a estar aquí presente, podemos comprobar que URLs google ha decidido meter en el buscador y que nosotros no le habíamos dado en sitemaps. Una validación de este grupo nos puede avisar de que cosas se nos habían pasado por alto o que páginas que realmente no queriamos ofrecer están ahí luchando por las posiciones.

El segundo criterio es la canonización, google nos indica que páginas han tenido problemas de duplicidad pero que aun asi ha escogido para indexar. La nota que nos hace google es que deberíamos marcarlas como canonicas pero nosotros deberíamos leer «escogidas por google» y ver si nos gusta su decisión o no antes de obederle. Para mi resulta más práctico plantearselas y quizas marcar a otras que google no había escogido como canonicas más que obederle porque si.

Tratamiento de las excluidas

La tipología de páginas excluidas es tan grande que creo que es mejor clasificarlas un poco antes de presentarlas…

1. Excluidas, por sacarse del indice por directrices SEO
– Página con redirección
– Excluida por una etiqueta «noindex»
– Bloqueada por la herramienta de borrado de URLs
– Bloqueada por robots.txt
– Bloqueada por una solicitud no autorizada (401)
– No se ha encontrado (404)
– Soft 404

Estos motivos indican un cambio en el estado de la URL. Anteriormente la URL si perteneció al indice pero por indicaciones de nuestra página se ha excluido del mismo. Una buena oportunidad para validar nuestras acciones o posibles problemas inesperados del proyecto.

2. Excluidas, por duplicidades y etiquetas canónicas
– Página alternativa con etiqueta canónica adecuada
– Google eligió una página canónica diferente a la del usuario
– Página duplicada sin etiqueta canónica
– Página duplicada por una página noHTML

Por fin información clara sobre como nos trata Google con las duplicidades. Si unimos todo esto a las validas a las que nos recomienda porner etiqueta con url canónica tendríamos la foto completa de todo el tratamiento de duplicidadesw internas del contenido.

Es interesante ver esta clasificación donde existen matches claros entre contenido:

– «Pagina duplicada sin etiqueta canonica» y «pagina duplicada por una página noHTML» pierden su contenido en favor de las válidas donde se nos recomienda incluir etiqueta canónica.
– Las «paginas alternativas con etiqueta canónica adecuada» lo pierden por una canonica a la que google ha hecho caso.
– Y las mejores, las paginas a las que pusimos etiqueta canónica pero que Google ha pensado que no tenian sentido y ha preferido llevar a resultados otra URL, una que tenía en otro sitio y que responde (según Google) mejor a los intereses de los usuarios. Vamos, ¡problema gordo! No le da la gana hacernos caso y nos lo dice a la cara.

En cualquier caso y aunque nada nos sorprenda y la foto sea la que esperabamos según el etiquetado que nosotros mismos hemos definido, todo esto nunca nos debe llevar a pensar que todo esta bien. Estas paginas son siempre rastreos innecesarios a evitar. Siempre va a ser mejor que Google no rastree urls inutiles asi que estos avisos nunca son del todo positivos.

3. Excluidas, a pesar de que las hemos enviado intencionadamente
– La URL enviada no se ha seleccionado como canónica
– La URL enviada se ha caido del índice

Páginas que hemos enviado intencionadamente (sitepaps, solicitudes de indexación) pero que Google no va a contemplar. De entre los motivos solo nos detalle si no la quiere por contenido duplicado, el otro motivo basicamente es «cualquier otro motivo».

4. Información sobre el proceso de indexación
– Rastreada: actualmente sin indexar
– En cola de rastreo
– Descubierta: actualmente sin indexar

3 estados con los que hay que tener mucho cuidado en su interpretación. La primera vez que los leemos creemos que tienen que ver con que google aun no ha tenido tiempo de interpretar los contenidos, pero en realidad nos hablan de bloqueos que se producen en el proceso de indexación porque las URLs no cumplen ciertos criterios.

Para mi el más importante de ellos es «Rastreada: actualmente sin indexar», este estado nos habla de URLs que se han analizado pero que google ha decidido no meter en el índice: No ha asolicado la URL a keywords comerciales porque no cumplen los criterios mínimos de calidad. Aquí encontramos un poco de todo pero sobretodo: Thin Content, Urls de listados, URLs que han perdido autoridad (ya tienen mucha distancia de rastreo o pocos o ningún link externo), formatos de archivo poco claros, etc. Vamos es el cajón para la baja calidad.

En cola de rastreo parece que no tiene demasiados problemas: Nos habla de URLs que aun no ha rastreado pero nos dice que terminará haciéndolo.

Por ultimo descubierta: actualmente sin rastrear, nos indica que Google conoce la URL pero que por el motivo que sea (normalmente técnico) no ha querido rastrearla e indexarla. Poco pdoemos saber sobre esto y gran parte se soluciona solo. Lo que si hemos notado es que ante caídas del servidor y errores 500 este tipo de URLs se disparan y cuesta bastante más pasarlas a válidas que las que ya estaban en cola de rastreo.

¿Y eso es todo? ¿No nos faltan cosas?

El tema es que si que nos faltan cosas. ¿Y el thin content? ¿Forma parte de las URLs válidas o cae dentro de las urls que se caen del indice? Parece que forme parte de las «Rastreadas pero no indexadas» pero en realidad no lo tenemos todo claro… lo iremos viendo seguro en los proximos meses a medida que todos hagamos las pruebas pertinentes.

Sea como sea todo esto es información valiosisima con la que hay que trabajar desde ya mismo.

Ver URLs exactas de cada estado y motivo o filtrar por ellas

Y la guinda para el final. Todo lo que os he contado hasta ahora podemos verlo URL a URL. No veremos todas nuestras URLS, Google Search Console ya nos deja claro que solo nos dan ejemplos (solo una muestra del total y solo hasta 1000 resultados de cada tipo) pero para descubrir patrones en cada tipología de URL estos «ejemplos» son más que suficientes. En sites pequeños podremos hacer correcciones URL a URL hasta que Google las trate como deseamos que lo haga, en sites más grandes esta información nos ayudará a descubrir patrones con los que trabajar.

Y este es solo uno de los nuevos informes…

Quizas el más llamativo, quizás el más deseado, pero solo uno. Esta claro que este nuevo Search Console solo está empezando y yo creo que incluso en este informe iremos viendo como los motivos cambian con el tiempo (por desgracia eso no significa que siempre a mejor). Nos toca aprender a lidiar con todo esto y sacarle el máximo partido posible a todo.

Nueva información significa nuevos aprendizajes y ya solo el ver como google lo está estructurando todo te da muchas ideas. Más de uno al verlo descubrirá que Google puede pasar de los canonicals y elegir por su cuenta y se le abrirá un mundo por delante. No será porque no nos lo hubiesen dicho antes pero no todo el mundo era consciente de esto.

Bueno, esperemos que no quede mucho para que esta nueva versión esté activa en todos nuestros proyectos.

Oferta de empleo: «Desarrollador web (orientación a full stack)» 2 Nov 2017 3:00 AM (7 years ago)

¿Eres desarrollador web? ¿Te interesa sacar partido a tus conocimientos llevando a cabo proyectos de distinta índole? ¡Tenemos muchas webs a las que dar salida y no menos desarrollos de herramientas y soluciones de marketing!

En IKAUE somos expertos en mejorar negocios y entornos digitales. Páginas web, ecommerce, aplicaciones móviles y todo tipo de entornos digitales. Damos servicio a grandes empresas del panorama nacional sobretodo a modo de consultoría en Analítica Digital, SEO y CRO. Somos muy buenos en nuestro trabajo y destacamos por nuestro know how y experiencia, especialmente en la parte técnica.

Actualmente queremos también empezar a crear nuestros propias soluciones y negocios. Para ello queremos empezar a contar con varios desarrolladores que nos ayuden en el día a día y además den vida a los proyectos que tenemos en mente. Empezando por nuestra propia web y las de otros proyectos internos y siguiendo con soluciones javascript para GTM, dashboards y herramientas de crawling e integraciones para SEO.

¿Qué buscamos?

A una persona con perfil de técnico/desarrollador y con ansias de aprender cada día un poco más.

• Que tenga conocimientos prácticos de maquetación HTML,
• Domine lenguajes de programación de servidor. Inicialmente trabajará con PHP pero a la larga debería meterse en el mudno de Python y R para proyectos en los que manipular grandes cantidades de información.
• También que pueda hacer sus propios scripts Javascript y/o con su framework jQuery,
• Que pueda gestionar al menos la base de un servidor Debian y/o Ubuntu server.
• Con bastantes peleas a sus espaldas con consultas SQL y Expresiones Regulares.
• Y por último, y esto es muy importante, con una pasión evidente por internet. Buscamos alguien que se divierta tanto como nosotros descubriendo nuevas vías por las que mejorar la web y analizar los distintos insights de cada negocio.

¿Qué ofrecemos?

• Un trabajo a tu medida, en el que ir avanzando y acabar dedicándote sobretodo a las áreas que te resulten más interesantes
• La posibilidad de crecer en varias tecnologías punteras con nosotros.
• La posibilidad de trabajar con los grandes clientes del panorama nacional online
• La profesionalización en el mundo de la Analítica Digital y el SEO técnico. El aprendizaje en el día a día con nosotros está más que garantizado.
• Puesto PRESENCIAL (absténganse quien no resida en la isla o pueda desplazarse), en nuestras oficinas del «Parc Bit» de Palma de Mallorca.
• 40 horas semanales, desplazadas hacia la mañana para que siempre te quede el día por disfrutar.
• Salario según valía y experiencia demostrable

¿Como ofrecer tu candidatura?

Tan solo envíanos un email a hola@ikaue.com

• Adjunta tu CV o como mínimo un link a linkedin
• Coméntanos un poco que es lo que te gusta de esta oferta, por qué crees que encajarías y que crees que te aportaríamos (preferimos que seas breve a un corta/pega de una carta de presentación al uso)
• Si tienes un horario en el mejor no contactarte háznoslo saber también para no molestarte.
• Y si quieres, añade lo que te apetezca que creas que te diferencia del resto de candidatos

12 cosas que deberías saber sobre los sitemaps.xml 16 Oct 2017 8:25 AM (7 years ago)

Hoy nos toca el tercer post especializado en sistemas de indexación SEO. Ya hemos abordado las posibilidades de los archivos Robot.txt y la gestión de las etiquetas o cabeceras del meta-robots para controlar la indexación. Ahora nos toca trabajar con otro de los archivos más famosos del SEO: los archivos sitemaps.xml. Como en anteriores ocasiones vamos desgranar todo el contenido en distintos puntos, en este caso hablaremos sobre 12 cosas que es importante que sepas sobre estos archivos. Algunas serán sabidas, otras espero que te sorprendan y por supuesto algunas serán validas para unos proyectos u otros.

Qué son y cómo crear los sitemaps.xml

Los Sitemap no son más que una vía que nos ofrecen los buscadores para que nosotros mismos les digamos que páginas deberían rastrear. Como casi todo en herramientas de indexación son solo sugerencias y Google en realidad visitará las páginas que le de la gana en el orden que él quiera. Sin embargo en muchos proyectos en los que (más por defecto de la web que de las arañas de Google) las arañas van un poco perdidas han demostrado ser de gran utilidad para guiarlas y ayudarlas a encontrar el contenido.

Los sitemaps.xml son uno de los primeros archivos que Google se preocupó por que conociésemos y eso ha conseguido que exista muchísima documentación sobre como crearlos. A día de hoy la mejor referencia oficial que tenemos la encontramos en «sitemaps.org» en muchísimos idiomas. El protocolo es muy simple pero tiene algunas peculariedades.

Este es el formato normal de un archivo sitemaps.xml bien hecho:

   
     http://blog.ikhuerta.com
     2017-09-29
     monthly
     1.0
   
   

De esta estructura lo importante es sobretodo la declaración inicial. Si no definimos el sitemap como un XML y sus atributos xmlns no será bien interpretado. Luego solo se trata de ir añadiendo nodos <url> con sus detalles (de los que solo <loc> es obligatorio). De echo la inmensa mayoría de los sitemaps que encontraras verás que solo contienen el nodo «loc» y ningún otro detalle de las URLs.

La codificación de caracteres también es muy importante, solo se admite UTF-8 así que hay que revisarla. Además el sistema nos prohíbe de forma explicita el uso de ciertos caracteres. Si queremos usarlos tenemos que «escapearlos» en HTML, es decir, debemos usar un código HTML para identificar el carácter exacto que realmente deseamos incorporar.

Por suerte estos no son muchos:

Carácter prohibido	Código HTML para incluirlo
&	&
«	"
‘	'
>	>
<	&lt;

Todo muy lógico, y no es nada que aun site con un poco de SEO onpage bien hecho le vaya a afectar. Pero tengámonos en cuenta. Por ejemplo, ¿qué pasa con esta url: «http://midominio.com?categoria=2&producto=25»? pues que en realidad en nuestro sitemap deberíamos incluirla como «http://midominio.com?categoria=2&producto=25».

Por último hay una restricción de tamaño:

• Máximo se nos permiten 50.000 URLs por archivo sitemap.xml
• Y el peso del archivo no podrá ser superior a los 50MB (así que cuidado con ajustar a 50.000 urls como hacen muchos que la podéis liar)

Bien, hasta aquí la teoría, pasamos a las cosas que a parte de la documentación básica deberíamos todos tener contempladas para hacer un buen uso de estos archivos.

1. La mayoría de sites no necesitan un sitemap.xml para nada

Esto no es solo verdad, sino que si hacemos mal el archivo sitemap.xml podemos hacer más mal a la indexación que bien. Este es otro de los puntos clásicos de los SEOs que están empezando: en clase les dicen que los sitemaps.xml son esenciales y de ahí muchos entienden que cualquier site que no los tenga no indexará bien y mejoraría su indexación con ellos.

Esto no es cierto, estos archivos son una guía para que las arañas no se pierdan y sepan donde acceder. Pero ¿que pasa si no se pierden? Les estoy aportando algo con este archivo. Puede que si, si tienes alguna estrategia de trabajo con ellos (veremos varios ejemplos más adelante) pero solo por subirlo con URLs y nada más no ganarás absolutamente nada con ello.

Así que por ejemplo para sites pequeños (normalmetne con pocos recursos de desarrollo) y donde no vemos un problema de estructura evidente nosotros desde IKAUE no solemos pedir archivos sitemaps.xml. El SEO siembre debe jugar en la línea de la rentabilidad y sin duda gastar tiempo de desarrollo en algo que no aporta absolutamente nada no tiene sentido. Y no, la solución no es subir un archivo sitemap.xml estático que creas tu con cualquier programita… ¿qué sentido tiene? ¿Vas a usar un crawler menor para ayudar a uno que es mucho más potente que el que tu usas? ¿Que esperas encontrar que google no pueda encontrar por si mismo?

Como contra además tenemos a toda esta gente que sube un sitemap sin tener mucha idea de SEO y encima provoca problemas de indexación que antes no tenía. Esto pasa más de lo que podría parecer (hay demasiados «primos de» o «amigos de» haciendo SEO para webs pequeñas). Os pongo algunos ejemplos de problemas que podemos provocar con sitemaps.xml mal realizados.

• Para empezar si no lo haces bien puedes darle muchas URLs que en SEO te importan más bien poco su indexación. Esto pasa cuando los generas automáticamente. Le dices que te indexe paginas corporativas que antes no tenía indexadas cosas así. También cuando te los generan desde desarrollo sin que pase nadie las indicaciones de qué deben contener te puedes encontrar con cosas URLs del entorno privado de usuario o páginas de gracias en el sitemap… ¿En serio queremos enseñarle eso a Google?
• Otro clásico parecido al primero es cuando nos fiamos de nuestro CMS o de algún plugin de esos que lo genera todo. Ahi WordPress, drupals y cosas así son unos expertos en conseguir indexar contenido basura. Taxonomias a las que no habías ofrecido URLs en tu página, Páginas de autor, de Archivos Mensuales (o peor aun diarios). No todo suma, todo esto resta
• Finalmente otro problema sucede con sites donde el rastreo de Google no llega a todas las páginas (con problemas de crawl budget). Nos encontramos con que le cuesta llegar a URLs muy profundas y decidimos subirlas al sitemaps «para ayudarle a encontrarlas». En estos casos podemos provocar que la araña ataque a páginas que tienen menos prioridad de posicionamiento del que tu les dabas en tu estructura. Por ejemplo, en una estructura web has relegado el posicionamiento de artículos muy viejos que no estaban bien enfocados hacia el target real de tu web a varios clicks desde la home (asumiendo que muchos no se indexarán). Subes un sitemap y te alegras porque mejora la indexación de estos artículos. Pero por otro lado no te das cuenta de que el crawl budget sigue siendo el mismo que tenías (no lo has mejorado) y que la araña visite estos contenidos tan despriorizados acaba provocando al cabo de un tiempo la desindexación de otros que tampoco estaban en primera línea de indexación pero que tenias más priorizados que estos que ahora estás empezando a recoger. Cuidado con ese tipo de cosas que cuando pasan puedes no darte cuenta de que el problema lo has provocado tu mismo con tus ansias de indexación. El crawl budget es el que es y el sitemap.xml no lo mejora.
• Por ultimo un problema (para mi menor) es que estamos poniendo a disposición de cualquiera que sea capaz de localizar este archivo todas nuestras URLs y todos los datos que pongamos sobre ellas a su alcance. La competencia en SEO se audita también y ponérselo un poco difícil no está de más. A mi me parece que salvo excepciones no es problemático que la competencia vea nuestros sitemaps, pero todo depende. Si esto te preocupa, es fácil de evitar: pongámonos a los archivos un nombre que no sea obvio y declaremoslos en Google Search Console y no en Robots.txt.

En definitiva dos cosas a destacar: a) en muchas webs no notaras ninguna por añadir un sitemap y b) si no te lo tomas en serio puedes empeorar tu indexación en lugar de mejorarla. Como norma general, si no hay una estrategia clara detrás no hagas un sitemap.

2. Declárale la guerra a los archivos de «mapa del sitio», esos no son los buenos

Si es que en realidad es muy obvio que no ayudan pero sigue sucediendo. La gente lee sitemap y hace asociaciones raras. No es lo mismo un archivo XML de Sitemaps que un Mapa del sitio montado en una o varias páginas de la web.

Un sitemap.xml:

Es un archivo muy concreto que tus usuarios no ven y que solo le ofreces a los rastreadores. Solo cumple funciones SEO, no afecta a la usabilidad del site

Un Mapa del sitio (o sitemap HTML o sitemap a secas):

Son páginas web que se usaban hace muchos años para suplir carencias de estructura en la web. Lo que hacían estas páginas era, ante sites que no permitían a las arañas alcanzar el contenido saltando de link en link ofrecer una vía secundaria de indexación. Vamos, que se solucionaban carencias básicas del site creando páginas nuevas en el mismo.

Esto hace unos años era muy común… teníamos Menús que se montaban en iframes o con flash. Las webs las hacían diseñadores, sin directrices y la UX ni tenía nombre… Más adelante aun se usaron para casos específicos: Por ejemplo era algo muy usado en Webs basadas en un buscador (clasificados, páginas de vuelos, etc.). La página tal y como estaba diseñada no ofrecía links hacia el contenido así que se colocaba un link abajo de «mapa del sitio» donde link a link el contenido acababa siendo accedido por las arañas. Eran otros tiempos y las arañas eran mucho más tontas y nosotros sabíamos menos sobre como gestionarlas.

A día de hoy los mapas del sitio no tienen sentido. Existen métodos mucho mejores para conseguir que las arañas encuentren el contenido. Lo primero es una arquitectura bien planificada y aprovechar los propios menús y bloques de enlaces del site. Si esto no es suficiente es probable que necesitemos dar vías de acceso secundarias (las aerolíneas siguen haciéndolo) pero con una estructura muy cercana a una real de un site y con contenidos, no con simples páginas llenas de enlaces…

Lo peor de este sistema es que quien lo tiene cree que ha solucionado la papeleta y no es verdad… Lo dicho: Muerte a los mapas del sitio. No los relaciones nunca con los sitemaps.xml. Estos últimos son una herramienta estupenda para hacer SEO mientras que los desfasados mapas de sitio son solo un vestigio del pasado tenebroso del SEO.

3. Podemos enviar a Google el sitemap de varias formas, no solo mediante Google Search Console

Uno de los puntos básicos pero vitales para que Google lea nuestro sitemap. El sitemap no es como el archivo robots que siempre queda alojado en la misma URL sino que practicamente podemos ponerle cualquier nombre. Así que hay que decirle a Google (o a bing) donde buscar. Esto se hace mediante Google Search Console, donde encontraremos una sección llamada sitemap donde podemos indicar esta URL. A esta acción la mal-llamamos «subir el sitemap». No subes nada, pero se le ha quedado este nombre.

Veremos más adelante que esta es la mejor vía posible pues nos da ciertas estadísticas sobre errores y su lectura, pero no es la única, en realidad podemos usar dos vías más para indicarle a Google estos archivos.

Indincándolo en el robots.txt

Es una de las vías recomendadas y puede suponer una gran ventaja cuando hacemos implementaciones genéricas, en muchos sites a la vez o por lo que sea no podemos acceder al Google Search Console de cada dominio por separado. También puede ser una buena opción para buscadores menores. Por ejemplo, si vamos a trabajar sobretodo Google pero queremos que ya de paso Bing lea nuestros sitemaps (aunque no vayamos a trabajarlos en bing) podemos añadirlo al Robots.txt y además darlos de alta en Google Search Console.

Es tan sencillo como declarar todos los archivos sitemaps que deseemos con la declaración «siteamap:» al principio de la línea.

Sitemap: http://www.midominio.com/mi-bonito-sitemap-1.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-2.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-3.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-4.xml

Los buscadores los rastrearán pero no nos darán la información de indexación y errores que si veríamos en Search Console.

Haciendo ping

Otra forma es hacer «ping» a una URL del buscador al que deseamos informar con la URL a leer. Un «Ping» no es más que una solicitud a esta URL sin más complejidades. Se carga la URL y el sistema se da por enterado. Esta solución también es valida para varios buscadores. Enviamos un ping a una URL con el siguiente formato «{dominio buscador}/ping?sitemap={URL del Sitemap}». Por ejemplo para enviar a Google el ping de mi dominio llamaríamos a la siguiente URL.

http://www.google.es/ping?sitemap=http://www.midominio.es/sitemaps.xml

Esta es la forma más descontrolada aunque puede servirnos para pegarle un toque de atención al buscador y que venga a mirar algo. Mucha gente lo usa además para intentar forzar reastreos: ante un update lanzamos pings de sitemaps que contienen las URLs con update intentando que la araña las visite. Si bien es cierto que subir sitemaps de URLs a realizar updates parece que algo si que afecta yo al menos no he tenido mucha diferencia en hacer ping o no a sus sitemaps la verdad.

4. Los sitemaps.xml solo afectan a archivos que están en su directorio o a mayor profundidad de este

Es decir «midominio.com/carpeta1/carpeta2/sitemaps.xml» no debe contener enlaces a archivos de «midominio.com/carpeta1» o «midominio.com/» solo a los de «midominio.com/carpeta1/carpeta2/…»

Asi que por ejemplo crear la típica carpeta de /sitemaps/ y por ejemplo alojar uno en «midominio.com/sitemaps/posts.xml» no es una buena idea ya que en teoría estos enlaces no se seguirían.

Lo mejor que podemos hacer es que es que todos nuestros sitemaps queden en la raiz de nuestro dominio (así garantizamos que no tendremos este tipo de restricciones). También existe la posibilidad de tener las cosas bien organizadas, y por ejemplo tener «/blog/sitemaps.xml» que solo tenga links a «/blog/…» pero es más fácil equivocarse con estas URLs que obligando a que los archivos se queden en la raiz del dominio (sin usar carpetas).

Lo que solemos hacer nosotros para ordenarlos es (si realmente tenemos esta necesidad) jugar con el nombre de los archivos. Por ejemplo, imagina que tienes un sitemap destinado al blog de la tienda de madrid del site. Como no acabamos de fiarnos de meterlo en la carpeta «dominio.com/madrid/blog/sitemap.xml» porque algunas URLs podrían no estar en esta estructura lo que si podemos es emular algo parecido con en el nombre poniéndole por nombre por ejemplo: «/sitemap-dominio-com–madrid–blog.xml»

5. Google no solo admite sitemaps en XML, hay más formatos

Y es que el sitemap.xml es solo uno de los formatos admitidos (y el más completo y estándar, claro) pero hay otros que nos pueden ser muy muy útiles en otros casos. Puedes verlos todos en la documentación de Google sobre formatos de sitemap.

Podemos subir archivos sitemap.txt, formados por un archivo muy simple que tan solo contenga todas las URLs del site una detrás de otra cada una en una línea distinta. Google los lee igual y nos podemos evitar complejidades técnicas si tenemos prisa o trabajamos con el típico proyecto con recursos técnicos limitados… (ejem). Como sitemap básico funcionará igual, pero este sistema por supuesto no es el más recomendado por la sencilla razón de que perdemos muchas de las funcionalidades que veremos más adelante (dado precisamente a que solo indicamos URLs y nada más con ellos).

Otra opción aun menos conocida es que podemos Subir un RSS o Feed del site. Estos son archivos que se usan para sindicar el contenido, es decir, para que ciertas herramientas puedan ver las ultimas publicaciones de una plataforma y leerlas. Son archivos XML que solo tienen contenido y no diseño. Si nunca has visto ninguno puedes ver el de cualqueir blog en wordpress añadiendo «/rss» al final de su URL. POr ejemplo, este es el RSS de mi blog. Subir este tipo de archivos suele suponer una mejora en la velocidad de indexación de nuevo contenido. Son sitemaps bastante consultados que por lo general solo contienen 10 o 20 elementos y por lo tanto Google puede leerlso muy rápidamente.

6. Tenemos sitemaps de varios tipos no solo de URLs

Estamos acostumbrados a que los Sitemaps.xml se refieran a páginas HTML concretas pero en realidad pueden contener otros tipos de información. Google tiene especificados 4 tipos de sitemap entre los que destaca el estandar (URLs):

• Estandar: https://www.sitemaps.org/index.html
• Video: https://support.google.com/webmasters/answer/80471
• Imagen: https://support.google.com/webmasters/answer/178636
• Noticias: https://support.google.com/news/publisher/answer/74288

Por supuesto, cuando lo que queremos es indexar contenido multimedia (algo que no siempre os recomendaría) los sitemaps especializados en videos e imágenes pueden ser muy útiles. Los de noticias también son utiles aunque con la desparición de Google News (que vuelve a estar visible, todos lo hemos visto) puede parecer que no tienen sentido la verdad es que no se trabajan igual y deberían aprovecharse en sitios de noticias.

POr ultimo mencionar que incluso podemos mezclar estas tipologías de sitemaps creando archivos que contengan sitemap de URLs, imagenes, videos, lo-que-quieras a la vez… Yo no lo haría porque no ayuda a entender las cosas mejor pero existe esa posibilidad.

7. Muchos campos (que cuesta tiempo desarrollar) se ignoran muchas veces por Google (según ellos por no hacerlo bien)

Y aquí viene el gran dilema al trabajar con sitemaps… ¿ponemos todos los atributos o no?

Los sitemaps nos ofrecen 3 campos a añadir a la URL:

• lastmod: fecha de ultimo cambio en la página
• changeFreq: Cada cuanto tiempo aprox cambia el contenido de esta página.
• Priority: de 0.1 a 1.0 y solo en relación a las páginas del propio sitemap, cuan importantes son unas y otras.

Sobre su interpretación tenemos históricamente mensajes muy contradictorios por parte de Google pero que a la que los lees te das cuenta de que todos tienen un hilo común. No voy a replicarlos porque son bastantes, pero os los resumo: por un lado nos dicen que se ignora la fecha de modificacion y la frecuencia porque nadie lo hacia bien, por otro que se ignora la prioridad porque no aportaba la información esperada… pero siempre, en cada comentario que nos hacen hay una coletilla: «en la mayor parte de los casos».

Al final todo esto significa que estas etiquetas bien gestionadas no se ignoran, pero que solemos gestionarlas mal y cuando eso sucede Google no les hace ni caso. Esto cuadra, casi en todos los aspectos es así: si Google no lo ve claro ignora tus etiquetados. Así que partamos de que si que podemos usarlas, pero solo para usarlas bien, no para hacer el bruto.

Os comento algunos ejemplos de mala gestión que harían que google ignorase estas etiquetas…

Sobre lastmod

• lastmod cuando usamos generadores de sitemaps.xml nos lo ponen a la fecha de creación del sitemap, lo cual no tiene sentido y más aun cuando todas las urls tienen la misma fecha
• lastmod tampoco tiene sentido cuando lo usamos para manipular al buscador. Google sabe cuando modificamos el contenido… si mentimos nos pilla
• Por ultimo En contenidos donde la Fecha aparece en el html o incluso la tenemos marcada con schema no podemos esperar que si no son fechas iguales nos haga caso

¿Que hacer con esta directriz?

Pensemos en su utilidad de cara al SEO. Realmente incorporarlo tan solo nos sirve para indicar a Google que se está perdiendo una actualización en uno de nuestros contenidos. Esperamos con ello que al ver que su fecha de modificación es más reciente que la que el tiene en caché venga a ver el contenido antes. Por ese motivo yo os recomendaría lo siguiente:

• Ni lo marquéis en páginas o sitemaps que no podéis garantizar que su fecha implique si o si la ultima revisión del contenido único de la página
• Marquémoslo solo en páginas de contenido (un last mod en un listado es muy difícil de trabajar con seguridad)
• Usémoslo solo si realmente hacemos reediciones en el contenido y nuestra reindexación es tan lenta que tenemos que ayudar a Google a darse cuenta de que lo hemos cambiado

Para todo lo demás creo que es preferible no usarlo a usarlo mal y que eso invalide toda la etiqueta al leer nuestos sitemaps.

ChangeFreq

Otra vez suele usarse muy mal esta etiqueta:

• Muchos sitemaps usan el daily para todo esperando que así su contenido se revise más a menudo
• Otros escriben incluso mal el texto, tan solo se permite especificado por la documentación
• Y otros simplemente la lían mucho haciendo un etiquetado arbitrario que nada tiene que ver con la realidad del cambio del contenido

¿Cómo deberíamos usarlo?

• Lo primero. Ni lo indiquemos si no estamos dispuestos a trabajarlo bien y de forma bien automatizada (esta etiqueta no nos ayuda en sitemaps.xml estáticos). Partamos de la idea de que si nos pilla mintiéndole a nuestro favor ignorará la etiqueta.
• Aún así, en muchos casos esta directriz ni siquiera va a tener sentido. ¿Cada cuanto cambia un contenido? Lo correcto sería indicar «never» pero, ¿queremos decirle a Google eso? ¿y si nos hiciese caso y nunca la revisitase? Pero lo cierto es que un contenido puede no cambiar nunca y todo lo que no sea un «never» es mentir al buscador.
• En listados muy dinámicos un «dialy» en contraposición a los «never» o «yearly» de las fichas haciendo más que evidente que queremos más indexación en estos listados dinámicos

En la práctica nosotros en IKAUE prácticamente nunca la indicamos porque son matices muy particulares y creemos poco en que las arañas vayan a cambiar su cola de indexación por esta directriz. Pero puesto a usarlo yo solo lo usaría en listados, para marcar diferencias entre los que añaden nuevos elementos constantemente (daily) y los que solo reciben nuevos elementos cada pocos dias (weekly), esperando así optimizar mejor nuestro crawl budget detectando mejor nuevos items en la web.

Priority

Como en las demás esta también suele usarse muy mal…

• Los generadores automáticos de sitemaps nos marcan todo el site a priority «1.0» lo cual es como no decir nada
• Muchos SEOs la intentan aprovechar para posicionar contenidos TOP que luego no se respaldan en absoluto por links, menús, autoridad ni por ninguna otra señal.
• Otros intentan hacer cambios en sus sitemaps para provocar la reindexación de contenidos. Por ejemplo, tengo todo mi sitemap todo a 0.5 y cuando quiero que se reindexe un contenido cambio la prioridad de este a 1.0 esperando que esto provoque la visita de la araña. Esto no suele funcionar (aunque si lo que hacemos es subir otro sitemap nuevo a veces si)

¿como usar la directriz de priority?

Cuando no tenemos problemas de indexación el uso más lógico que podemos hacer del sitemap es ayudarnos a reforzar la estructura de la web marcando la importancia de cada una de nuestras webs. En estos sites subir el típico archivo de sitemaps donde todo el sitemap tiene priority «1.0» ya sabemos que es estúpido. Lo que tenemos es que aprovechar este campo para reforzar la estructura/arquitectura del site. La misma definición de menús, URLs, Breadcrumbs e inlinks, debería ser consecuente con los datos indicados en priority.

Lo que buscamos es que Google vea que nuestras prioridades si tienen sentido para que nos haga caso y asi ayudarle a matizar lo más importante. Así encontrar que la home y secciones principales tienen prioridad 1.0 y vamos bajando hasta encontrar los productos estrella en prioridad 0.7 o 0.6 puede tener sentido. Haciéndolo así no se nos permite colocar estos productos en máxima prioridad (mintiendo a Google) pero si al menos diferenciar los importantes de los que no lo son (por ejemplo marcando los importantes a 0.7 y los menos importantes a 0.5).

Hay que partir de nuestra deficnición de arquitectura web y luego hacer pequeñas modificaciones sin cosas demasiado drásticas que invaliden la directriz totalmente para Google.

8. Un Sitemap nos permite suplir otras etiquetas de indexación como hreflang o canonical (aunque no es igual de potente)

Y aqui viene otra utilidad secundaria de los sitemaps. Todos sabemos que el proyecto web perfecto no existe… Todos tienen uno, dos o incluso muchos problemas. Hay cosas que sencillamente resulta un problema etiquetar en ciertas web. Abordamos ya como solucionar problemas de indexación desde cabeceras o indexación desde el robots pero veamos dos posibilidades que si que nos aportan los sitemaps para suplir a etiquetas concretas.

Marcar los hreflang desde el sitemap

Los hreflang son una suerte de implementación en sites con orientación a varias regiones geográficas o simplemente idiomas. Su definición es en realidad sencilla: Desde cada página web debo indicar en su cabecera y mediante etiquetas <link rel=»alternate» hreflang /> sus urls equivalentes en otro idioma.

Esto que parece muy simple en la práctica si tu web por detrás no tiene estas equivalencias ya hechas (algo muy común en CMSs libres donde esta orientación multidioma no se había planeado desde un principio) o si las maquetas son especialmente rígidas puede ser un infierno para los programadores.

En estos casos debemos saber que contamos con otra posibilidad: indicar estas relaciones en los archivos sitemap en lugar de (o además de) en la web. Su uso es igual de simple: en cada <url/< del sitempa indicamos además del nodo <loc> varios nodos <xhtml:link/> con las equivalencias de esa URL con otros idiomas. El problema sigue siendo el mismo: debemos identificar en cada URL todas sus posibles traducciones pero al menos disponemos de otro lugar (muchas veces más programado a medida del SEO) donde hacer este trabajo.

Puedes ver cómo desarrollar estos sitemaps aquí, o simplemente guiarte por el ejemplo que te copio a continuación:

  
    http://www.midominio.com/como-hacer-sitemaps
    
    [... otras traducciones ...]
  
  [... otras urls ...]

Evitar canibalizaciones del contenido

Y este es un método que desde luego no es equivalente a una buena etiqueta canonical (de las que hablaremos en otro post) pero si que puede ayudarnos en ciertos momentos en los que tenemos canibalizaciones de contenido (entiéndase canibalizado como contenido duplicado interno en el cual uno posiciona por encima de otro haciendo a la segunda URL totalmente inútil).

En estos casos lo que solemos hacer es decidir cual de los dos contenidos queremos que sea el que se posicione y añadir una etiqueta canónica (si no un 301 directamente) desde las URLs secundarias a la principal. Pero sabemos que esto no es siembre fácil…

Sin embargo: ¿Sabías que ante duplicados internos Google escoge casi siempre la URL que esté en el sitemap.xml? Lo indican ellos mismos en su documentación, mencionando que es un posible sustituto de etiquetas canonicas. Para ello solo tenemos qu etner un sitemap bien hecho, en el que evitemos incluir ninguna etiqueta que tenga riesgo de ser canibalizada. Es decir, en estos casos en los que varias URLs tienen el mismo contenido o apuestan por la misma Keywrod nos basta con solo incluir la URL principal en el sitemap para que esta sea la que muestre Google en sus resultados. Salvo que por links recibidos nuestra elección de URL principal no tenga ningún sentido (por ejemplo: le indicamos una URL sin links internos dejando fuera a la URL que se enlaza desde todos los menús) Google nos hará caso.

No nos engañemos, esto no es como un canonical: No traspasa autoridad y ni siquiera tenemos garantías de que nos haga caso siempre (bueno, con los canonicals tampoco) pero es una vía secundaria que tener en cuenta cuando tenemos este tipo de limitaciones.

9. Los indices para sitemaps son lo mejor que puedes usar ¡Aprovechalos Siempre!

.

Dado que los Sitemaps.xml son finitos (tienen peso y URLs máximas) tuvieron que idear una forma por las que despiezarlos en distintos archivos. Para poder hacer eso existe un tipo de archivo sitemap de índice. Son archivos en los que podemos indicar otros archivos sitemap. Las ventajas son claras: subimos un único archivo y desde este controlamos todos los que ofrecemos realmente a Google automatizando su fragmentación.

Y es que al final intentar centralizar todo el sitemap en un único archivo tiene muchos riesgos:

• Corremos el riesgo de pasarnos del tamaño máximo.
• Nos cuesta mucho encontrar en el todas las URls
• Nos cuesta auditar sus prioridades.

Lo mejor es que para cada concepto, sección, lo-que-sea de la web creemos un sitemap distinto y usemos estos índices para organizarlo todo.

Crear un índice es sencillo y está bien documentado en siteamps.org, tan solo tenemos que indicar una rama «sitemapindex» donde podemos incluir elementos «sitemap» que tienen su localización y de forma opcional su última modificación con «lastmod» (al que aplicaríamos los mismos comentarios que al lastmod de las URLs).

   
      http://www.midominio.com/sitemap1.xml
   
   
      http://www.midominio.com/sitemap2.xml
   

10. Esta es muy importante: Los sitemaps son la única forma de comprobar el porcentaje de indexación de nuestras URLS.

Uno de los mejores indicadores que nos dan los sitemaps cuando los subimos vía Google Search Console es el estado de indexación de la lista de URLS que les pasamos en ellos. Esto lo hace para cada sitemap: lo subimos y al poco tiempo ya nos dice para cada uno cuantas URLs contenía y de ellas cuantas ha indexado. Solo tendremos que dividir una cifra sobre la otra para saber el porcentaje de indexación de dicho sitemap.

Pensando un poco sobre esto no es difícil llegar a la conclusión de que no queremos subir sitemaps enormes a nuestro site: lo suyo es que subamos siempre un indice que apunte a una colección más o menos grande de sitemaps.xml parciales del site. ¿Cuantos? depende de cuanta información quieras realmente recoger.

Por cada sitemap.xml fragmentado que creemos, tendremos un nuevo grupo de URLs del que conocer el estado de su indexación. Así que a mayor cantidad de información que queramos saber sobre la indexación del site más deberíamos fragmentar los sitemaps para conocerla. Esta es una técnica medianamente conocida pero que aun sabiendola se usa poco y se aplica sin pensar demasiado en ella:

Os pongo dos ejemplos para que queden claro.

Imaginad que tenemos un blog del que vamos a subir los sitemaps.xml fragmentados en distintas piezas para conocer el estado de indexación de cada tipo de página. Una fragmentación básica nos haría crear los siguientes sitemaps:
– Home.xml
– categorías.xml
– tags.xml
– Posts.xml

Con esto podremos saber que porcentaje de cada tipo de página tenemos indexado. Seguramente si el blog tiene mucho tiempo y poco seo técnico nos encontraremos con que cada tipología de contenido tiene gran cantidad de URLs sin indexar.

Y esto esta bien saberlo pero si solo vemos este tipo de cosas no podremos accionarlo, no sabemos que hacer para mejorar estas situación y no tenemos nada que hacer con esta información. Este suele ser el problema.

Ahora pensemos en aplicar a nuestra fragmentación del sitemap una lógica SEO. Pensamos en cada tipología de página, cual puede ser su problemática de indexación. Por ejemplo, escogemos los posts, donde estamos viendo el mayor porcentaje de contenido no indexado, los analizamos y vemos que es probable que se trata de un problema de anigüedad: a mayor antigüedad del post más creemos que se habrá desindexado… Así que hacemos nuestra fragmentación del sitemap buscando obtener información justo por este criterio y en lugar de subir un único sitemap de post subimos la siguiente colección:

– posts-novedad.xml –> Indexación 90%
– post-ultimo-mes.xml –> Indexación 100%
– posts-2-meses.xml –> Indexación 98%
– post-3-6meses.xml –> Indexación 89%
– posts-7-12-meses.xml –> Indexación 50%
– post-1-2-anos.xml –> Indexación 55%
– posts-2-3-anos.xml –> Indexación 57%
Etc…

La cantidad de indexación de cada uno de estos sitemaps si que es un dato accionable. Puedo encontrarme con que a partir de los 6 meses empiezan a perder la indexación y descubrir que tengo problemas de rastreo profundos. O que los posts de hace más de 5 años siguen indexados pero los actuales no se indexan tan bien (demostrando un problema de autoridad y de calidad del contenido)…

Se pueden hacer muchas estrategias de este tipo. Incluso jugar a cambiar el patrón por el que dividimos estos sitemaps. Piensa por ejemplo en pasar screaming frog, sacar las URLs por distancia de rastreo desde la home y subir un sitemap temporal según distancia de rastreo para ver a partir de cuantos saltos empieza a sufrir la indexación. Sacamos el dato, lo accionamos y luego volvemos a usar los sitemaps de siempre…

Otra opción es simplemente hacer seguimiento, apuntar estos datos cada seemana y asi observar como mejora o empeora la indexación por zonas de la web.

11. Puedes alojar los sitemaps fuera de tu dominio

Alguno habrá arqueado la ceja al leer este título… Y es que esto es raro pero tiene grandisimas ventajas sobre todo si llevas el SEO desde fuera de la web (como freelance, agencia, consultoría, etc.). Nunca os recomendaría alojar el sitemap general de vuestro site en otro dominio distinto al del propio site pero para ciertas acciones y pruebas viene muy bien tener la posibilidad de poder ir haciendo subidas sin molestar a los desarrolladores de la web. Pensad solo en muchas de las posibilidades que hemos comentado en este post y veréis que tener un espacio donde no depender de IT para subir ciertos sitemaps bajo tu control te va a permitir realizar más acciones (o al menos de forma más rápida) de este tipo.

La idea es sencilla: a parte de los propios sitemaps de la web quiero tener la posibilidad de subirle sitemaps que no se alojen en ese dominio. ¿Dpnde se alojarán? Pues en un dominio mio, uno en el que no dependo de IT y puedo acelerar ciertas acciones mientras IT responde a las guías y funcionales que les hemos pasado.

Para esto hay varias opciones:

A. Usar los sitemaps para sites multiples

Esto está documentado en esta URL y basicamente nos permite subir el sitemap de un dominio de la forma normal, solo que indicándole dentro del sitemap URLs de otros dominios.

Para esto básicamente tenemos que hacer que el usuario que suba el sitemap.xml sea ADMIN del Google Search Console de los dos dominios. Así que en realidad nada impide que creemos un dominio tonto (sitemaps-seo.midominio.com) lo demos de alta en GSC y en el subamos nuestros propios sitemaps.xml para nuestros clientes, siempre y cuando nos hayan dado privilegios sobre sus propios GSCs.

B. Indicar el sitemap.xml en el robots.txt ya directamente apuntando a otro dominio

Este es otro recurso documentado incluso en la propia documenación documentación de los sitemaps.org. Ahi nos dicen que podemos incluir en la directriz «sitemap: » del archivo robots un sitemap sin que importe que se encuentre o no en el dominio indicado.

Es decir que si en midominio.com dispongo de un robots.txt que acaba con las siguientes lineas:

sitemap: http://midominio.com/sitemap-general.xml
sitemap: http://dominioAgenciaSeo.com/sitemap-agencia.xml

Leerá ambos. Si sumamos esto a que estos sitemaps pueden ser indices que controlan donde leer cada archivo ya tenemos un mecanismo similar al de Google Search Console.

Que todo esto tiene sus riesgos, por supuesto, pero bien hecho es una puerta nueva que no hay que desaprovechar solo porque nos de miedo usarla.

12. Puedes usar Sitemaps para alentar a las arañas a que visiten URLs que quieres que se miren (aunque no por ello que se indexen)

Por ultimo y con una utilidad muy práctica si lo ligamos al punto anterior (de subir sitemaps por tu cuenta) tenemos una vieja técnica que se basa en subir sitemaps.xml para forzar su rastreo. Es sabido que al ir haciendo actualizaciones de los sitemaps las URLs que ahí se contienen acaban tarde o temprando siendo visitadas, pero esto es por lo general aún más rápido (aunque tampoco va a ser inmediato) si lo que hacemos es subir sitemaps nuevos.

Así que tenemos una herramienta (la subida de nuevos sitemaps) que nos permite crearle a Google listas de URLs pendientes de rastrear y que nos puede venir muy bien sobretodo en ocasiones en las que por no ofrecer ya links a estas páginas o por tener un rastreo lento no nos acabamos de fiar del trabajo de las arañas.

Os listo algunos de estos casos:

• En una migración dejar el sitemap antiguo o incluso, mejor aun, subir un nuevo el sitemap de URLs con 301 ayuda a que estas se lean antes y asegura que todas terminen siendo leidas
• Lo mismo para 301. Después de arreglos masivos de errores 404 que han sido sustituidos por 301 una subida de sitemap con estas URLs ayuda a que las arañas las recojan y asimilen./li>
• Ante una actualización de desindexación con meta-robots subir el sitemap también puede ayudar a agilizar su lectura
• Subir un sitemap de URLs AMP en teoría no es estándar y no «es necesario» pero en algunos casos donde la indexación de páginas AMP se atasca nos ha resultado de mucha ayuda.
• No es bueno crear errores en nuestros sitemaps pero para validar el bloqueo de URLs en grandes listados también podemos subir un sitemap con todas las URLs que deberían estar bloqueadas en el site y ver que efectivamente el validador nos da errores al tener estas bloqueadas.

Y bueno, en definitiva, nos ayuda a comprobar o intentar agilizar la indexación tras nuestras actualizaciones en la web. Siempre que queramos que las arañas pesen por sitios atípicos por los que normalmente tardarían en pasar una subida puede ponerlas en marcha, nunca será algo excesivamente rápido pero ayudará a que no se eternice.

Como decía, si unimos este punto además al anterior, por el cual podemos subirle a un cliente sitemaps.xml en nuestro propio dominio, tenemos un sistema de control de la indexación que no afecta al desarrollo de la web y que nos aportará en ciertos momentos el extra que necesitamos.

Conclusión

Los sitemaps son unos archivos muy poco mimados por gran cantidad de SEOs. Como son fáciles de definir y no arrojan grandes complicaciones más allá de conseguir el propio listado de URLs para muchos el trabajo queda ahí. Incluso como decíamos al principio es una zona que mucha gente acaba cuidando tan poco que hacen más mal que bien…

Sin embargo son una herramienta que trabajadas al detalle pueden ser un gran aliado tanto para mejorar nuestra indexación, para hacer un análisis de la indexación o para suplir distintas carencias técnicas del SEO de nuestro site.

El problema con estos archivos sigue siendo siempre el mismo: la base hay que programarla para que tenga sentido. Los desarrollos a medida no suelen haberlos tenido en cuenta y muchos CMS que los desarrollan mediante plugins al hacerlo de forma generica no acaban de ser lo que necesitamos. Solo tras una planificación y definición estratégica adecuadas empezamos a hacer autenticas virguerías con estos archivos. Hay muchos tipos de SEO y muchos estadios de evolución en una estrategia SEO, no creo que esto sea de lo primero a atacar (por complejo) pero si tengo clara una cosa: al hacer un sitemap debemos tomarnos nuestro tiempo y hacerlo bien. SI no vas a mimarlos, mejor no los uses.

10 cosas que deberías saber sobre las etiquetas meta-robots, noindex, nofollow e indexación 21 Sep 2017 1:40 AM (7 years ago)

Y después del post sobre todos esos detalles del Robots.txt que mucha gente desconoce tocaba hablar un poco sobre el recurso hermano de este: la etiqueta meta-robots. Otro básico del SEO del que todo el mundo sabe cosas pero que como siempre tiene tal cantidad de pecularidades que es fácil que a muchos se nos escapen algunas. Seguramente incluso en este post me falte algún detalle por comentar, pero aún así creo que hay temas que la mayoría de SEOs desconocen o como míminimo conocieron hace tiempo pero ya no lo aplican.

El SEO es lo que tiene, hay tantos detalles y surgen tantas cosas cada año que terminamos por borrar de nuestra cabeza las cosas que menos usamos. Por ese mismo motivo tenia ya este post medio escrito en borradores del blog, para poder acudir a estos detalles dentro de un tiempo y usarlos como referencia. Lo dicho, espero que os guste lo que viene a continuación…

Introducción: Cómo añadimos una etiqueta Robots a una página

Repasemos, la composición de la etiqueta robots es muy simple, se forma como cualquier otra meta-etiqueta de la página:

• Debe estar en el HTML de la página, específicamente dentro de la etiqueta «head» de la misma.
• Solo estar declarado una vez por página
• Se trata de una etiqueta «meta» que se compone de 2 atributos: name y content, donde name indicaa que aplica la etiqueta y content es el atributo que marca las directrices a seguir
• Asi pues su formato normalmente es el siguiente:

No tiene más misterio, la única complejidad es que cuando hacemos SEO en un site a un nivel alto solemos definir exactamente que valores queremos en cada página del site por lo que tenemos que preocuparnos de que nuestro CMS o la programación de nuestro site nos permita manipularla a nuestro criterio.

Dicho esto, vamos a ver detalles sobre que podemos hacer y cómo se interpreta esta etiqueta.

1. Existen más directivas a declarar de las que sueles usar (pero se usan mucho menos)

Las directrices posibles a indicar en el atributo «content» de la etiqueta se definen casi siempre a pares positivo/negativo y son todas opcionales. Podemos declarar las que queramos, que el resto se entenderá siempre como positivas.

Las directrices pueden estar en minusculas o mayúsculas (se entiende igual un «Nofollow» un «NOFOLLOW» y un «nofollow» y entre ellas se separan por comas (incluyendo las que queramos en la página). No importa demasiado si usamos espacios entre ellas o no, aunque la costumbre es no usarlos, Google entenderá perfectamente tanto «noindex,nofollow» como «noindex, nofollow» o «noindex , nofollow».

Dentro de estas directrices las de index y follow son las más conocidas pero no son las únicas y podemos encontrar directrices interesantes que nos saquen de algún apuro.

• index/noindex: Esta es la directiva más poderosa que podemos usar. Con ella le decimos a Google que no queremos que esta página aparezca en los resultados de búsqueda. Su acción es bastante rápida en pocos días veremos que el contenido desaparece y si la usamos al publicar un nuevo contenido este no aparecerá nunca en el buscador.
• follow/nofollow: La segunda más usada. Con ella le decimos que no rastree los links de esta página. No nos engañemos Google los va a rastrear pero no les traspasará autoridad (o no mucha al menos). Es el equivalente a marcar absolutamente todos los enlaces de la página con un rel=»nofollow».
• archive/noarchive: Nos sirve para controlar la publicación de la caché que tiene Google sobre nuestro contenido. Si no queremos que la caché de esta página se accesible al público la marcaremos como noarchive. Esto puede ser útil para contenidos o noticias muy sensibles, cosas a esconder o contenidos demasiado dinámicos para que esta caché sea útil. Por lo general la caché nos ayuda a ver que tiene Google sobre nuestras páginas asi que no solemos desactivar su publicación.
• translate/notranslate: Con ellas podemos indicar a Google que no queremos darle la opción de traducir al usuario. Simplemente no le aparecerá ese link para usar Google Translate.
• imageindex,noimageindex: Asi de fácil resulta prohibir indexar las imágenes de nuestro site. Útil cuando queremos protegerlas o todo lo contrario, que no nos cuente como contenido duplicado
• «unavailable_after: {fecha en formato RFC-850}»: La más rara de todas. Esta nos permite indicar que queremos desindexar el artículo a partir de una fecha determinada. Útil cuando nuestro contenido deja de ser vigente o después de promociones caducadas que de seguir indexadas harían más daño que bien. Que no os asuste el formato RFC-850, es simplemente una cadena como la que sigue: «20 Sep 2017 18:00:00 GMT». Podemos discutir sobre su uso y si no es mejor pasar las noticias a «noindex» directamente al pasar esa fecha: Yo os diría que la ventaja es que si lo indicáis así, Google ya está prevenido, pero de todas formas pasada la fecha mejor dejar un «noindex» que un unavailable_after con fecha pasada.
• snippet/nosnippet: para que no muestre descripción del resultado. A ver, que alguna utilidad debe tener no mostrarlo solo que yo no se la veo. Peor CTR y solo por no querer escribir un meta… La hemos usado solo para casos muy especiales donde por un motivo extraño Google no usaba la Description que queriamos.
• none: es una etiqueta en desuso que viene a decir que lo marcamos todo a no (noindex,nofollow,notranslate,noarchive,nosnippet,…). La gente no la usa porque un «noindex,nofollow» surge el mismo efecto en la práctica (si no indexas ya todo lo demás tampoco se hace) y es más claro de leer.
• por último, odp/noodp y ydir/noydir: hacían referencia a los directorios que se usaban para extraer descripciones de las páginas cuando estas eran inaccesibles (robots.txt, 302 y cosas así) pero ya no se usan y estos directorios ya ni existen. Así que no tiene sentido usarlas a día de hoy aunque sigan en las documentaciones.

Como veis hay más opciones de las que normalmente manejamos. Y es bueno conocerlas todas, aunque sin duda las que más usaremos sean index/noindex y follow/nofollow en las siguientes combinaciones:

• noindex,nofollow: Cuando no deseamos indexar ni que se sigan los enlaces de esta página. Queremos cortar por lo sano en esta página
• index,nofollow: Queremos indexar esta página pero no traspasar autoridad a sus enlaces. Esto solía usarse antaño en páginas de agradecimientos y de intercambios de links (al menos los SEO timadores)… que tiempos. A día de hoy es dificil que quieras indexar una página de la cual no te interesa ninguno de sus links.
• noindex,follow: El caso de que no te interese indexar esta página pero si quieres que las arañas se tomen en serio sus enlaces. Muy usada antes de la aparición del rel=»next/prev» para paginaciones y aun hoy para sistemas de páginas y arreglar defectos de la indexación

2. Es probable que la etiqueta meta robots (o al menos parte de sus directrices) no sea necesaria en la mayor parte de tus páginas

No paro de ver como muchos SEOs Junior te marcan como un defecto del site el que este no contenga la etiqueta meta-robots aunque esta no sirva para nada. Nada más lejos de la realidad.

Debemos entender que esta etiqueta sobretodo funciona para limitar el uso que pueden hacer los robots (y Google en particular) de tus datos. Por defecto ellos van a entender que pueden indexarlo todo, seguir cualquier link y poner la información que deseen de tu web, por lo tanto las directivas positivas como «index,follow» no aportan nada a la lectura que hacen los robots site. Tampoco es que molesten a la indexación pues no estará mal si las incluimos pero de ahí a decidir que un site no esta optimizado por no disponer de ellas hay un largo trecho. En SEO siempre luchamos contra las ventanas de trabajo que nos aportan los técnicos, que siempre son menos de las que nos gustarían. Generar tareas que no aportan nada (mierdiptimizaciones, las llamamos nosotros) no es una buena práctica.

Además, si nos ponemos en plan purista diríamos que incluirla suma peso a la página y por lo tanto liberándonos de todas las etiquetas positivas de la página en realidad optimizamos más nuestro SEO que incluyéndolas. Y siguiendo con esta lectura el típico «noindex,follow» tampoco tiene sentido. «follow» ya es una directriz que debería seguir el buscador por lo que lo suyo sería solo indicarle «noindex» y el ya entenderá que si que puede seguir los enlaces. Sin embargo por claridad justo esta combinación si suele usarse aunque sea para dejarnos a nosotros mismos claro lo que buscamos al indicarla. La realidad es que tampoco ganamos mucho quitándo estas directrices aunque no nos aporten nada, asi que ante estos casos todo esta bien resuelto esté como esté el site.

3. NoIndex se encarga de la indexación no del rastreo.

Es decir, esta directriz está encaminada a decirle al robot que cuando rastree esa página no debe sumarla al indice de resultados del buscador. Pero eso no evita que las arañas de los buscadores la visiten y saquen su información. De hecho están obligadas a hacerlo, de otra forma no podrían leer el noindex.

En la práctica esto solo nos afecta en un punto: la optimización del crawl budget. Resumiendo diríamos que Google nos destina un tiempo de proceso de nuestras páginas, a mayor crawl budget más capaz es de encontrar todos nuestros contenidos. Bien pues al añadir páginas con noindex estamos generando trabajo inutil a estas arañas: Les hacemos rastrear páginas que no van a indexar. Así que si lo que queremos es optimizar el crawl budget el robots.txt suele ser mucha mejor opción.

4. Pero noindex si afecta al rastreo: Lo disminuye.

Venga, y voy a contradecirme yo solo ahora mismo. Pues es que en realidad el noindex si que afecta al rastreo y por lo tanto al crawl budget, cuando analizas los logs, sueles ver que las páginas con noindex pierden rastreo. Si las comparas con páginas similares del site en autoridad interna los robots terminan pasando menos por ellas que por el resto.

Esto es normal si lo piensas, ¿porque van a pasar una y otra vez a leer contenido que no pueden usar? Lo normal es que se rastreen menos, aunque sin duda es mucho menos efectivo que un bloqueo por robots.txt.

Aunque no puedo daros cifras (no lo tengo tan bien atado y me encuentro con diferencias muy grandes entre proyectos distintos) podríamos decir que el rastreo disminuye con las directrices de indexación de esta forma:

• index,follow: se trastrea todo de la forma normal
• noindex,follow: se rastrea menos, pero si la página tiene autoridad aun puede visitarla más de una vez al día. A fin de cuentas si le decimos que siga los links debe rastrearla. Pero si que lo hace menos
• noindex,nofollow: se rastrea bastante menos, pero seguimos recibiendo hits en ellas
• rel=»nofollow» en todos los links que le llegan: Aunque no estoy 100% seguro, mi sensación es que se rastrea incluso algo menos
• bloqueo por robots.txt: Se anula en gran parte el rastreo, seguimos encontrando hits (a pesar de que los hemos prohibido) a las páginas por parte del los robots pero son anecdóticos

Así que tengámonos todo en cuenta: si afectas al rastreo, pero si es tu intención afectarle tienes herramientas mejores.

5. Pensemos un poco: ¿Y para que quieres poner un nofollow en tu web? ¿sirve de algo?

Y esto es algo sobre lo que muchos SEOs me van a llevar un poco la contraria. Pero a más que lo meditas no ves ningún sentido en declarar un nofollow en muchas de las páginas en las que se están declarando.

Partamos del concepto que veíamos antes: Google va a rastrear esta página hagas lo que hagas. Así que tienes varias opciones las cuales no acabo de ver…

index,nofollow:

Estas páginas huelen muy mal. ¿Quieres posicionar pero que no traspase nada de autoridad a los links? No tiene mucho sentido, salvo que estés haciendo piratadas como intercambios de links

noindex,nofollow:

Y esta es la clásica que todo el mundo usa a diestro y siniestro pero… ¿has pensado si realmente es lo que quieres? Mucha gente solo piensa en que no quiere indexar la página ya ya decide que tampoco se sigue. Esto es más por acercarse al 0 rastreo de los robots.txt que porque sea lo que realmente quieres. Deberiamos meditar que van a hacer las arañas con cada página que encuetren y te encontrarás con que muchas veces no tiene snetido el nofollow.

• ¿Quieres evitar el rastreo?

  Entonces te has equivocado de opción, lo que buscas en un bloqueo por robots, no un noindex,nofollow

• ¿Quieres no indexar ciertas páginas molestas de tus menús?

  Bien, tiene todo el sentido, pero que pasa con sus links. La araña va a pasar por ahí de todas formas, ¿seguro que no quieres que siga los links y rascar un poco de autoridad de esas páginas que no quieres en el indice pero que autoridad si que tienen? Piensalo y verás como quitas el nofollow de muchos contactar, avisos legales, secciones de marketing, etc… ¡Todo link cuenta!

• ¿Quieres frenar a la araña a estructuras completas y no puedes con el robots?

  En este caso, si, si por ejemplo tienes todo un catalogo que no puedes indexar (porque es basura, porque esta parseado, porque no lo quieres y punto) y nadie te deja bloquearlo al completo por Robots.txt si que es cierto que lo único que te queda es eliminar la autoridad a los links de ese catalogo. Ahí yo trabajaría sobretodo los rel=»nofollow» de los links que van ahí pero además dentro del propio catalogo que tendrá muchos links a todas estas zonas un nofollow será más efectivo.

6. Existe la posibilidad de declarar exactamente a que robot nos dirigimos en la etiqueta meta y actuar por separado para cada uno de ellos

Tan solo sabemos que Google se toma en serio estas directivas especificas para robots, pero eso ya es suficiente para hacer cosas.

La lista de robots por separado está aqui: https://support.google.com/webmasters/answer/1061943?hl=es-419

En ocasiones no queremos tratar igual a todos los robots, esto sucede especialmente cuando nos encontramos con temas SEO vs Publicidad de pago o cuando lidiamos con los distintos buscadores especializados de Google (que tienen cada uno su propia araña). En muchos sites creamos paginas que no queremos que Google indexe porque hablando en términos SEO son basura, pero en cambio son páginas que con ciertas campañas pueden convertir muy bien por lo que si queremos que otros robots puedan acceder a ellas.

Asi pues podemos crear más de una etiqueta. name=»robots» siempre se ocupará del caso especial, pero luego podemos añadir etiquetas más especificas para los distintos robots:

Que vendría a prohibir la indexación tan solo a los robots de rastreo dedicados a resultados orgánicos y no afectaría a los de móvil, adsense o publicidad.

O por ejemplo este otro:

Prohibiría indexar tan solo en el buscador de noticias (algo que en España ya no importa, pero en otros países si).

O por ultimo:

Prohibiria indexar en google search el resultado pero si podríamos ver las imágenes y vídeos de esa página en el buscador de Google Images y el de Google Videos.

7. Cuando mezclas noindex con otras directrices en el html (canonical, rel=»prev/next», etc) las cosas no funcionan como esperarías

Marquémosnos la norma: Si decidimos que algo no se indexa, no liemos a Google con más directrices. Se lía y para cada caso hace cosas distintas. No es buena idea y punto.

• Comentábamos que una vez indicas un noindex marcar cosas como nosnippet, noarchive, notranslate, etc. carecía de sentido: si no indexas no hay resultado y por lo tanto no hay que tocarlo. Marcar cosas en negativo no tiene problemas pero si puedes provocar que Google no haga caso a tu no index si indicas cosas como un content=»snippet,archive,transalte,follow,noindex», que son ganas de tocarle las narices. No lo hagáis y no tendréis que preguntaros porqué no os lo desindexa
• El caso del noindex + canonical es ya un clásico. Que no tiene sentido es obvio, no puedes decirle al robot que no te indexe pero que la url canónica (a no indexar) es otra. ¿Pero que buscas con eso? El caso es que consigues que se comporte de forma caótica y no puedas saber a ciencia cierta si va a aplicar el noindex o no de la página. Me gusta este post de Sergio Redondo con experimentos de canonical y noindex pero no porque este de acuerdo con sus conclusiones (yo siempre he creído que la primera indexación es muy parcial y básica y sus experimentos creo que responden más a eso responde a eso) sino porque demuestra el caos que representa juntar estas directrices. Puestos a no saber que va a hacer el buscador mejor no liarle, ¿no?
• Y luego el segundo clásico para paginaciones: ¿podemos usar «noindex,follow» a partir de la primera página y además añadir un rel=»next/prev» a todas? La lógica nos vuelve a decir que no tiene sentido: next/prev sirve para identificar que varias páginas forman parte de un mismo listado y así evitar que las entienda como duplicadas… en teoría a ojos de Google sumamos todas con todos sus links en un gran listado (en la práctica tan así no es). Pero si esto es lo que buscamos ¿qué sentido tiene que desindexemos parte de ese contenido unificado? En este caso parece que hace más caso al noindex y desindexa las páginas así marcadas pero yo no me fiaría, si le dices tonterías a Google el responde con caos.

En conclusión, no se mezclan directrices de indexación contradictorias en el HTML. Revisa lo que tienes puesto y mira que no te contradigas a ti mismo.

8. ¡Cuidado! Google lee el meta-robots en cualquier parte de la página, no solo en el <head> de la página

Y esto lo he descubierto y vivido en mis propias carnes recientemente y no ha sido hasta que Sergio Simarro me ha avisado que no he sido consciente de ello. Y es que parece ser que a Google le importa un pimiento donde pongas tu meta-robots. Si el lo ve en la página, en cualquier parte del HTML lo lee y lo sigue (y cuidado que muchas herramientas de validación no actúan igual y solo lo leen en el head).

Lo mejor que puedo daros es mi propio ejemplo, en el post que os decía antes sobre robots.txt, en su primera edición me dejé escrito en el artículo la etiqueta «<meta name=»robots» content=»noindex» />» y se me olvidó codificarla con carácteres HTML para que no se entendiese como parte del HTML. Esto provocó dos cosas:

• Que en artículo no se viese esa parte escrita (encontrando una frase inacabada en un párrafo)
• Que Google no me indexase dicho artículo y ya de paso me desindexase la home del blog ya que también aparecía esa etiqueta ahí…
• Y por el mismo motivo, me desindexó también la categoría de indexación del blog

¿Divertido verdad? Así que si vais a escribir sobre SEO en una página web tened mucho cuidado que Google lo lee. Y si os encontráis con la típica página que se pasa por el forro los estándares web cuidado con lo detectan vuestras herramientas que Google podría estar detectando otra cosa.

9. Google lee y obedece a las etiquetas que creamos en el HTML por javascript y por lo tanto podemos incluirlas vía GTM

No es un secreto que Google interperta JS. No es la forma recomendada de hacerle indicaciones pero más o menos, si todo carga en el primer print de página (sin necesitar click o acciones del usuario) termina leyéndolo. Esto ha abierto gran cantidad de posibles parches JS o de forma más controlada via Google Tag Manager (una herramienta de gestión de tags de analítica y marketing).

Así pues para cualquiera que sepa programar javascript resulta relativamente sencillo añadir a la cabecera de la página una etiqueta robots que dirija la indexación o desindexación de contenido. Funciona en los dos sentidos: Creando etiquetas robots que la página no tenía o borrando las que existían.

Por ejemplo, para desindexar contenido desde Google Tag Manager podemos crear una etiqueta personalizada con el siguiente contenido:

Y lanzarla en todas las páginas vistas que nos interese desindexar. Veréis como tarda un poco pero termina desindexando el contenido de Google.

10. También podemos enviar las directrices de meta-robots desde las cabeceras de la página

Esto ya lo adelanté en otro post pero en realidad tocaba mencionarlo en este. Además comentare algunas cosas más sobre para qué hacerlo y como conseguir la configuración…

Las directrices de robots no solo se pueden enviar en la etiqueta meta-robots sino que disponemos de una cabecera que podemos usar a nivel de servidor para enviarlas.

Todo esto está detallado en la documentación para webmasters de Google. Esta nos detalla el uso de la cabecera http «x-robots-tag». Las cabeceras son información que el servidor envía antes de hacernos llegar la web cuando la solicitamos y sirven para muchas cosas distintas: avisan de si la página es correcta, si da 404 o si es un 301, si el navegador debe usar caché, tiempo de expiración de esta, etc.

Cualquier lenguaje de programación web es capaz de gestionar las cabeceras antes de enviar la página. Un ejemplo serían estas (las de la home de mi blog):

HTTP CODE: HTTP/1.1 200 OK
Date: Thu, 21 Sep 2017 09:09:12 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.4.45-1~dotdeb+6.1
Link:; 
rel:"https://api.w.org/"
Vary:Accept-Encoding
Content-Type:text/html; charset=UTF-8
X-Pad:avoid browser bug

Aquí por programación podemos añadir las que deseemos, asi que no nos cuesta demasiado añadir una linea que declare el x-robots-tag con las mismas directivas que incluiriamos en el atributo content de la etiqueta meta-robots.

x-robots-tag: noindex,nofollow

Por ejemplo hacer este añadido en PHP sería tan sencillo como añadir esta línea antes de la primera impresión de HTML de la página:

header("X-Robots-Tag: noindex,nofollow", true);

¿Por qué mola mucho más meter las directrices de robots por headers que en el HTML?

El primer punto interesante es que Google es consciente mucho antes de que estas existen. Así básicamente podemos evitar los problemas de colisión con otras etiquetas HTML que hablabamos antes. Una cabecera se interpretará antes y por lo tanto un noindex en una cabecera tiene muchas más garantías de no indexar. Cuidado aquí porque otras directrices como los canonicals tambien pueden enviarse en cabeceras y ahi si que habría colisión.

De la misma forma en crawl budget debería ayudar más que una etiqueta meta (esto lo digo sin haber hecho el test oportuno, pero tiene lógica que se interprete más rápido y se rastree menos).

Otro punto interesante es que nuestra estrategia de posicionamiento es menos evidente: la mayoría de los SEOs no miran los headers al auditar. No es dificil mirar headers al hacerlo:
– podeis usar varios plugins de chrome
– Alguna herramienta online especializada como DNSQueries
– Y los rastreadores más populares (screamingfrog, sitebulb, deepcrawl, …) incluyen este dato

Pero lo cierto es que a muchos se les pasa por alto. En un primer analisis rápido nadie lo mira, e incluso en audits en profundidad muchos no se miran este dato o no saben mirarlo. Así que es una forma de hacer tu estrategia SEO menos patente para la competencia.

Siguiendo con las ventajas, en programación del site no implica tocar maqueta, por lo que los desarrolladores no tienen porque tocar plantillas para ir añadidendo este tag a la web. Muchas veces suponesmo que los cambios son más fáciles por estar en el HTML pero en muchos negocios no es así: llevar un cambio al HTML provoca tocar CMS, Modelo de datos, Lógica de programación y luego maqueta. Si les ahorramos aunque sea uno o dos de estos pasos mejor que mejor.

Por último, las cabeceras no solo se pueden controlar desde programación. Desde la configuración del servidor tambien podemos definirlas. Aquí los archivos htaccess de apache (o el htconfig si tocamos las tripas del servidor) también nos sirven. En seo estamos acostumbrados a tocarlos para control de redirecciones, pero resulta que también nos sirven para enviar cabeceras y por lo tanto para evitar la indexación.

Lo mejor de esta técnica es que podemos hacerlo por expresiones regulares sin tener que detallar URL a URL cuales indexamos y cuales no. En la práctica esto significa que si que tenemos un sitio facil de manipular y lejos de la programación real de la web donde indicar un noIndex a Google.

Esto nos lo explica desde el principio el blog de Yoast (el creador del famoso plugin SEO de WordPress). Pero vamos, ya has leido demasiada intro asi que vamos al grano: lo que vamos es a definir este tipo de líneas en el .htaccces de la web…

Para eso usamos la directiva de configuración «Header set» o «Header add». Estas nos permiten añadir cabeceras HTTP desde estos archivos. Sin embargo no todos los servidores permiten hacer esto por defecto.

• Si tienes un servidor compartido es probable que si que estén activas y de no estarlo tendrás que ponerte en contacto con tu proveedor para que te diga como activarlas (si es que se puede, claro).
• Si tienes el típico servidor donde tan solo está activo lo que has ido usando para tu web es posible que a la primera las cosas no funcionen. Muchas distribuciones de linux vienen ya con el módulo de envío de headers activo pero justo Ubuntu y Debian (las dos más usadas) lo traen pero no lo tienen activado.

¿Como se si lo tengo activo? Bueno, puedes comprobar los módulos tu mismo o simplemente intentar activar una directiva de creación de cabeceras. Si el servidor te da un error 500 «Internal Server Error», es que no están soportadas

Por ello yo os recomendaría siempre añadir cualquiera de estas manipulaciones de headers bajo la etiqueta «» para que si el módulo no existe al menos no hagamos fallar a toda la web.

Activar el módulo de headers en apache

Tenemos que entrar por consola y ahi teclear estas dos líneas:

a2enmod headers
apache2 -k graceful

* Hay que ser root o usar «sudo» para lanzarlo, claro.

Cómo implementarlo

Para implementarlo solo tenemos que editar los archivos de configuración del servidor (.htaccess o .htconfig dependiendo de a que nivel quieras actuar) y añadir las comprobaciones necesarias para ver si crear o no las cabeceras. El problema viene que dependiendo de lo que quieras hacer y dónde te dejen hacerlo el sistema para conseguirlo no es exactamente el mismo.

Por lo general, siempre que podamos o no estemos seguros de como funciona nuestro servidor, todas estas definiciones las englobaremos en la etiquetas «» y «» para evitar fallos por si no se nos permite crear headers.

1. Si podemos acceder al .htconfig

Este archivo es el que se encarga de las configuraciones del servidor. Es un archivo muy sensible donde además se pueden mezclar todos los hosts a los que atiende el servidor. Es difícil que nos den acceso si no es un servidor dedicado por lo que en proyectos menores no nos servirá.

Aquí la configuración es realmente sencilla porque podemos acceder a la directiva , con ella actuamos sobre la URL que se carga en el navegador y la usamos para saber si aplicamos algo o no a la configuración. Así que básicamente podemos hacer algo parecido a cuando hacemos redirecciones con ModRewrite.

Ejemplo para marcar un noindex,follow en paginaciones de la web con .htconfig:

  
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

Aquí os dejo otra para no indexar contacto o aviso legal para que dejen de aparecer esas páginas cuando alguien busca la marca… (a criterio de cada uno si es mejor hacerlo o no)

  
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

O para no indexar ni seguir los enlaces de nuestro chungui blog cuyo contenido histórico está robado de otros blogs:

  
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

Como veis, si realmente nos dejan tocar en donde toca hacer estas definiciones puede ser muy sencillo. Por desgracia ya os digo que muchos negocios pequeños no podrán acceder a este archivo y en los más grandes la gente de sistemas no verá con muy buenos ojos que andemos tocando ahí (porque es mucho más sensible que un htaccess).

2) Con .htaccess y ficheros

En .htaccess (donde en SEO estamos más acostumbrados a entrar) también podemos hacer cosas, pero por degracia las directivas de y aqui no están disponibles. Asi que no podemos acceder a URLs como tales, sino a los ficheros y carpetas de la web. En lugar de aquí disponemos de para jugar con los nombres de archivos y con para enviar cabeceras en directorios completos. Sin embargo recordemos que hablamos de archivos reales en el servidor no de URLs de la página. Esto significa que por ejemplo en un WordPress tanto la url «/mi-bonito-post» como «/category/mis-posts» o «/page/15» en realidad acaban todas ejecutando el archivo «/index.php» por lo que no podríamos diferenciar cabeceras de estas páginas con este sistema.

Os pongo el ejemplo que en el artículo de yoast aparecía para no crear cache ni descripción de nuestros archivos .doc o .pdf (aunque corregido que el suyo tiene un errorcillo y con el IfModule añadido para que no pete), como veis aqui si podemos usarlo porque se refiere a archivos concretos.

  
    Header set X-Robots-Tag "index, noarchive, nosnippet"
  

También podríamos hacer lo mismo con todo el contenido del directorio «wp-admin»:

  
    Header set X-Robots-Tag "noindex,nofollow"
  

Como si que es un directorio real en el servidor (podemos incluso verlo en el FTP de nuestro proyecto) si podemos trabajar con el en .htaccess.

2) Con .htaccess y entornos de modRewrite

Hasta ahora tenemos dos vías sencillas para trabajar con esto: Una en un sitio que es difícil que nos den acceso y otra con un sistema que no es capaz de diferenciar URLs virtuales/amigables/sobreescritas que acaban todas en el mismo archivo. ¿Nos falta algo verdad? Si, La capacidad de hacer esto mismo con URLs de este tipo pero en el .htaccess. Un sitio donde la directiva dedicada a leer esto no está disponible…

Por suerte, en la inmensa mayoría de los casos en los que tenemos este problema, este sucede porque estamos usando ModRewrite en la página. Un módulo de Apache con el que indicamos estas URLs amigables (y que en SEO usamos muchas veces para hacer las redirecciones 301). Bien, pues resulta que ModRewrite a la hora de definir como se leen las URLs es capaz además de crear entornos (environments), luego estos entornos pueden recibir headers distintos cada uno.

¿Como hacemos esto? Pues es un poco más complejo que antes, pero sigue siendo sencillo…

• Identificamos en nuesrto .htaccess donde empiezan las acciones de modRewrite
• Debemos escribir siempre: Después del condicional de y de su configuración basica, pero antes de ninguna declaración que afecte a ninguna URL
• Tres líneas distintas:
  • La primerar recoge la variable %{THE_REQUEST} que es lo que realmente el navegador ha pedido al servidor. Es la petición completa por lo que incluye el método y el protocolo. Así si accedemos a «/pagina» la variable THE_REQUEST tendrá el valor «GET /pagina HTTP/1.1». Sobre este valor tenemos que hacer la expresión regular para detecar las URLs a las que afectar.
  • La segunda línea declarará el nombre del entorno para todas las URLs y archivos que coincidan con la línea anterior.
  • La tercera línea será la declaración de cabeceras

  Por ejemplo, para hacer un noindex, nofollow sobre el blog las tres líneas serían:

  RewriteCond %{THE_REQUEST} "^(GET|POST) /blog/.* HTTP"
  RewriteRule .* - [ENV=NOINDEXBLOG:true]
  Header set X-Robots-Tag "noindex,follow" env=NOINDEXBLOG
  

Veamos esto para el caso de wordpress que tiene un .htaccess sencillito…

.htaccess original de wordpress:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Y supongamos que queremos hacer que las paginaciones no se indexen, así que debemos detectar las URLs que acaban en «page/{número}» y asignarle un «noindex,follow». Así que encontramos en el código la expresión , vemos su configuración básica que enciende el motor y establece la URL base a «/» y bajo esta añadimos la declaración del entorno «NOINDEXNOFOLLOW». Luego, declaramos los headers para este entorno.

.htaccess con noindex en paginaciones para wordpress:

# BEGIN WordPress

RewriteEngine On
RewriteBase /

# GESTION DIRECTIVAS x-robots-tags
RewriteCond %{THE_REQUEST} "^(GET|POST) .*page/[0-9]+ HTTP"
RewriteRule .* - [ENV=NOINDEXFOLLOW:true]
Header set X-Robots-Tag "noindex,follow" env=NOINDEXFOLLOW

# Gestion Redirecciones
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

A partir de ahí, se trata solo de saber hacer las Expresiones regulares correctas. Por ejemplo si nos ponemos a hilar fino y solo queremos desindexar las paginaciones a partir de la 5ª página y solo si estas son de la home o de categorias principales de wordpress el código sería el mismo, pero la expresion regular se complicaría:

# GESTION DIRECTIVAS x-robots-tags
RewriteCond %{THE_REQUEST} "^(GET|POST) /(category/[a-z-]+/)?page/([5-9]|[1-9][0-9]+) HTTP"
RewriteRule .* - [ENV=NOINDEXFOLLOWPAGES:true]
Header set X-Robots-Tag "noindex,follow" env=NOINDEXFOLLOWPAGES

¿No es genial definir todo esto de esta forma? La web tiene que acompañar claro, si no somos capaces de crear las expresiones regulares necesarias para detectar las páginas no podremos trabajar, pero muchas veces si que podemos hacerlo y una vez conocido el sistema no es tan difícil de implementar. Somos muy poco intrusivos con la programación de los sites y ante errores al estar toda la definición en un único archivo es muy fácil de controlar.

Conclusión

La cantidad de detalles a controlar sobre indexación es abrumadora. En un par de días hemos tocado solo los dos recursos más básicos que existen y ya da para replantear las estrategias de muchos sites.

Como todo, priorizar y seleccionar es importante. No tenemos que aplicarlo todo a todos los sites e incluso de tener que hacerse no tiene porque ser desde el primer momento. Empecemos por controlar que no hemos cometido errores, sigamos seleccionando bien que queremos hacer con las arañas y luego ya poco a poco la vamos liando.

Al final estas cosas se notan. Sobretodo en sites donde Google no llega a todas las páginas que le ofrecemos el control sobre que indexar y que seguir supone elegir nosotros que Keywords realmente nos importan y eso se traduce en mejora de visitas.

De momento os voy a dejar tranquilos con estos temas… quien sabe, igual en un tiempo me lance a por los sitemaps, canonicals (aqui hay mucha chicha), atributos rel… tambien tocaría editar los viejos artículos que tengo sobre HTML… cuanto trabajo por delante…

10+1 cosas que deberías saber sobre los archivos robots.txt e indexación SEO 15 Sep 2017 3:59 AM (7 years ago)

Hace tiempo que no comentamos muchas cosas de SEO por aquí. Así que para que no se diga hoy he sacado de borradores una serie de apuntes sobre uno de los básicos del SEO del que la mayoría de gente desconoce detalles muy importantes: El archivo robots.txt, uno de los básicos de la indexación SEO. Robots.txt es un archivo destinado a indicar a los buscadores que URLs tiene derecho a visitar y de cuales debería abstenerse. El funcionamiento es simple: antes de visitar una URL del site un robot debería mirar en este archivo para determinar si tiene que ir ahi a recoger información o si por el contrario el dueño del site prefiere que no entre. En definitiva son solo indicaciones que cualquier robot puede saltarse si quiere, pero a las que el robot de google hace bastante caso (que tampoco al 100%).

El archivo robots.txt es uno de esos temas técnicos del que todo SEO debe saber lo suficiente como para manipularlo con éxito. Por ello el mismo Google en su soporte nos indica como podemos crear el nuestro: Información sobre los archivos Robots.txt.

Se nos da información muy directa y fácil de asimilar. La redacción de estos archivos es muy sencilla aunque cualquier fallo, por mínimo que sea, podría provocar que las arañas no entrasen en las páginas que nosotros deseamos. En el mejor de los casos eso provocará que sigan visitando URLs en las que no querríamos que perdiesen el tiempo en el peor será todo lo contrario: no indexarán contenidos que en realidad si que queremos que aparezcan en el buscador. Es el tipíco aspecto importante que de fácil que es la gente no se toma lo suficientemente en serio, y ahí esta el problema: la documentación de Google está bien aunque no cubre todas las pecularidades sobre como se va a interpretar dicho archivo y si nos quedamos solo ahí podemos cometer errores que lamentaremos en el futuro.

Así pues, os dejo 10 conceptos sobre estos archivos que hay que tener en cuenta y asimilar. Desde lo más básico hasta consejos que solo en webs complejas o con mucho detalle de optimización del crawl budget podremos aplicar.

Previo: El formato general del robots.txt

Un Robots.txt es sencillo…

1. Empezamos declarando en una línea el user-agent (nombre del sistema que está navegando o rastreando el site) al que queremos afectar y tras esta indicaremos los accesos permitidos y prohibidos.
– Muchas veces declararemos un accceso a todos (user-agent:*) y en ocsaiones nos referiremos a algun robot o crawler en particular (user-agent:googlebot).

user-agent: *
---- Reglas para todos los robots ----

user-agent: googlebot
---- Reglas que solo aplican a Google Bot----

user-agent: majestic
---- Reglas que solo aplican majestic----

2. Después usamos directivas «Allow: {expresion}» y «Disallow: {expresion}» para indicar si damos acceso o lo eliminamos. Por defecto podríamos decir que un robot tiene acceso a todas las URLs del site («Allow:*») pero aunque esto ya es así desde el principio mucha gente decide dejarlo declarado de forma explicita y continuar prohibiendo a partir de ahí. Por eso aun siendo innecesario no debe parecernos raro ver un robots que empieza por «Allow: *».

3. Por ultimo, podemos indicar nuestro sitemap.xml si lo deseamos (sitemap: sitemap.xml). Esto para Google carece de importancia si gestionamos adecuadamente Google Search Console, aunque puede ayudar a otros robots a leerlo así que mal no va a hacernos declararlo.

sitemap: /miarchivositemap.xml

Una cosa curisosa de este archivo sitemap es que puede estar alojado incluso en otros dominios distintos al nuestro (esto puede ser útil si por ejemplo necesitamos hacer subidas con cambios del archivo cada cierto tiempo y en la web que trabajamos no nos lo permiten ir actualizando de forma tan ágil).

Así un ejemplo que cubra todo lo que acabamos de mencionar sería el siguiente:

user-agent: *
allow: *

user-agent: googlebot
disallow: /no-rastrear-esto/
allow: /no-rastrear-esto/pero-esto-si/
disallow: /*/no-rastrear-esto/

sitemap: /sitemap.xml  

Visto esta base, que es lo más conocido del robots, vayamos a por los conceptos que no todo el mundo tiene tan dominados…

1. Donde colocas tu archivo es más importante de lo que creees.

Existe mucha confusión con este punto, en parte porque la documentación en el pasado (de hecho cuando escribi este post yo mismo lo detallé mal) El archivo robots.txt siempre se busca en la ruta «/robots.txt» de tu dominio. El robots.txt afecta al host donde está alojado pero solo a este host exacto. Esto supone que un subdominio no hará caso al robots.txt de su host superior y que http y https usan archivos distintos. ¿Por qué etonces vemos sitios donde una configuración bloquea a otra? Lo veremos más adelante pero es sobretodo por temas de hosts redirigidos totalmente con un 301. Es decir, cuando vemos que el robots.txt de www.midominio.com afecta también a midominio.com normalmente es porque existe una redirección de «midominio.com/robots.txt» a «www.dominio.com/robots.txt» y por lo tanto se lee el mimso archivo para ambos hosts. Lo mismo pasa con http y https, si uno esta redirigido al otro se aplica el mismo archivo a ambos.

Pero en definiva vendría a ser esto:

Así pues:

• midominio.com/robots.txt >> NO afecta a www.midominio.com y a blog.midominio.com
• dev.midominio/robots.txt >> Afecta a dev.midominio.com pero no a blog.dev.midominio.com
• www.midominio/robots.txt >> Afecta a www.midominio.com pero no a blog.www.midominio.com y solo afectará a midominio.com si hay un redirect de midominio.com/robots.txt a www.midominio.com/robots.txt

Además también hay que eliminar la creencia de que el robots.txt actúa como muchos piensan sobre carpetas concretas del site. Esto no es cierto: Google solo lo lee si está en la raiz del documento:

«midominio.com/blog/robots.txt» no sirve para nada. Google no va a intentar leerlo ni tiene porque hacerle caso. Algunos CMS se empeñan en añadirlo pero esto no forma parte de la definición oficial del archivo robots.txt.

2. El tipo y tamaño de archivo puede afectar a que no se lea tu archivo robots.txt

Lo ideal es que un robots.txt esté codificado en UTF-8 para no tener problemas de lectura. Pero lo cierto es que los archivos de texto pueden tener varias codificaciones y si por ejemplo creas el archivo desde tu bloc de notas de windows es probable que su formato sea otro. Es recomendable usar editores de texto plano más profesionales (como por ejemplo, por daros una opción sencilla y pontente notepad++ ) donde entre otras cosas se os deje escoger la codificación del archivo.

Aun así Google nos dice que puede leer otras codificaciones, lo que pasa en estos casos no es tanto que el pueda o no, sino que al generarlo se escriba en una codificación y el servidor lo devuelva en otra. Eso puede provocar los típicos caracteres extraños que terminan en que el archivo no funcione o no se lea de forma adecuada.

Aun dentro de los archivos UTF-8 hay una cosa en estos archivos que se llama BOM (Marca de orden de bytes del archivo, que ocupa la primera linea) . Lo ideal es que los ficheros simples no tengan BOM pero Google es capaz de leer el robots.txt con un BOM inicial (y solo uno y solo al principio) así que si vuestro archivo tiene BOM no pasa nada.

Otra limitación la tenemos en el tamaño. Google nos limita a 500MB, (1/2 GB) si lo pasamos no leerá el archivo. Así que tenemos que economizar estos archivos y ya no solo por no acercanos a los 500MB sino porque son archivos muy consultados por los robots y a mayor tamaño más desgaste de proceso y red en el servidor.

3. Un disallow solo prohíbe leer el contenido no indexar (y de primeras no está focalizado a desindexar)

Un aviso: No es lo mismo un <meta name=»robots» content=»noindex» /> que un disallow en el robots. Significan cosas totalmente distintas.

• Disallow prohibe a las arañas leer el HTML de la página. Pero puede leer la URL y aparecer esta en búsquedas con información a partir de otras páginas y links de internet. Además con un disallow no eliminamos lo que ya sabía Google de esas páginas y no es extraño que tras añadir una URL como disallow veamos como el resultado se mantiene un tiempo en el buscador. Definitivamente no es una forma rápida de desindexar, va más encaminado a temas de rastreo y a acciones a medio o largo plazo.
• Por el contrario con un NoIndex en el meta-robots si deja a la araña rastrear el HTML pero prohíbe que su resultado salga en Google. Es el efecto contrario: las arañas siguen perdiendo el tiempo con esa página pero los resultados desaparecen antes del buscador

Todo esto por supuesto con matices… A la larga un Disallow provocará la desindexación si no hay links externos hacia esa página y por el contrario un meta-robots a noindex terminará provocando menor rastreo de esa url que total Google no puede trabajar.

4. Si el contenido no se lee, como es lógico, las directivas del HTML se ignoran

No tiene sentido un disallow+noindex o un disallow+canonical o disallow+rel-next/prev o un disallow+loquesea-en-el-html. Google no va a contemplar este HTML porque le hemos prohibido acceder a el así que ahórrate su etiquetado.

Lo mismo pasa aunque en menor medida con las redirecciones. Si yo creo una redirección 301 de una URL vieja a una nueva y al mismo tiempo bloqueo la vieja por robots.txt Google no debería enterarse de que he creado un 301 (porque no debería acceder a la URL con 301) así que el traspaso de autoridad no se realizará de forma eficiente. En la práctica a veces si se da cuenta de la redirección pero por lo general se pierde mucha autoridad al hacer estas cosas.

Otro caso es el de meta-robots=noindex unido a otras directivas. En teoría nada impide que no puedas poner por ejemplo un noindex y un canonical a la vez, se puede pero es un poco especial y en realidad su interpretación es muy ambigua. Y ante estos casos ambiguos sabemos que Google decide ignorar todas las señales del HTML (por no fiarse de ellas) por lo que aunque en teoría si se puedan hacer estas cosas yo no os recomendaría ninguna salvo la de «noindex,follow» e incluso esa, con cuidado (pues un noindex se rastrea poco, así que ponerle un follow termina siendo un poco contradictorio).

5. La redacción de las URLs es simple, pero muy concreta y sus reglas de lectura no son tan intuitivas como podría parecer.

La vamos a repasar porque llegados al detalle tiene miga y la gente comete muchos fallos.

Cada línea debe empezar con una orden (allow/disallow) y cada orden hay que escribirla con mucho cuidado.

• Si las urls no comienzan con un slash («/») google lo añadirá. Es decir: «disallow: blog» google lo entenderá como «disallow: /blog» y «disallow: -producto» como «disallow: /-producto».
• La regla que aplica Google no es un «contiene», nuestra declaración debe empear por el principio de la URL. Normas tipo «disallow: .doc» no funcionan porque falta el principio de la URL. De echo entenderá que la url a prohibir es urls que empiecen por «/.doc».

  Esto tiene varias implicaciones:

  • La solución cuando lo que queremos es definir partes del final o fragmentos de las URLs es redactarlas como sigue: «/*-producto» o «/*.doc» indicando que empieza por cualquier cosa y luego si contiene ese rastro que queremos detectar.
  • Si pensamos en declarar carpetas de la web todo se vuelve más fáficl pues Google entenderá que se hace referencia a esa dirección y a todos los achivos internos que contengan esas carpetas. Es decir, al indicar «/mi-carpeta» como disallow, también prohíbo el acceso a «/mi-carpeta/mi-archivo».
• Las directrices allow/disallow no son sensibles a mayúsculas y minúsculas, pero las URLs que se definen en ellas si lo son. Es decir yo puedo escribir «disallow:» o «Disallow:» o «DISALLOW:» y es lo mismo pero «/mi-pagina» y «/MI-PAGINA» no son la misma URL.
• Se nos permite usar los comodines * y $ para completar las URLs:
  • «*» equivale a cualquier conjunto de caracteres. (el equivalente en expresiones regulares a «.*»)
    • «disallow: /blog*» bloqueará la carpeta /blog/ pero tambien cualquier archivo o carpeta cuya url empiece por «/blog», por ejemplo «/blogueria.html»
    • «disallow: /*.doc» si que funciona pues contemplamos cualquier cáracter al principio y esperamos que acabe por .doc
  • «$» Nos permite forzar que ese sea el final de la URL, sin permitir nada tras ella:
    • «disallow: /categoria/$» solo bloqueará el acceso a la página de categoría «/categoria/» pero no a archivos internos como «/categorias/post»
    • «disallow: /blog$» solo bloqueará el archivo «/blog» pero no la carpeta «/blog/»
  • Se nos permite sobreescribir reglas por ejemplo permitir el rastreo de una parte de una regla ya prohibida o prohibirlo luego de nuevo para una regla que lo permitía.

    disallow: /blog/
    allow: /blog/$
    allow: /blog/categoria-1

  Si rastreará tanto la home como la categoria-1 del blog, pero no el resto porque todo el resto de URLs siguen prohibidas

  • Por último, las reglas no se aplican por orden de lectura sino por lo especificas que son.
    La norma es que Las Reglas más largas pesan más que las más cortas.
    Así:

    disallow: /blog-corporativo/
    allow: /*.html
    

    No conseguirá que se rastreen los archivos «.html» dentro de /blog-corporativo dado que es más larga la expresión de blog-corporativo y por lo tanto pesa más.

    Pero esta otra composición si lo hará:

    disallow: /blog-corporativo/
    allow: /blog-corporativo/*.html
    

    Porque ahora «/blog-corporativo/*.html» es más largo que «/blog-corporativo/» … así de simple, pero también así de ilógico.

6. Las alternativas para evitar rastreo/indexación a robots.txt o meta-robots no son igual de pontentes.

Y esto es así… No hay nada más potente y duradero que una sentencia de robots.txt…

• En Google Search Console puedes usar la herramienta de borrar contenido y estas URLs se borrarán. Pero Google aproximadamente a los 90 días olvidará que le habías pedido borrar la URL y si por lo que sea vuelve a encontrarla la volverá a indexar. Por lo que sirve para eliminar errores puntuales pero no para eliminar URLs que van a seguir ahí.
• En Google Search Console puedes usar la herramienta de parámetros de URL para indicar si un contenido aporta cambios en la url o no pero esto no es mandatario, Es solo una ayuda como puede ser el sitemaps y si Google cree que los parámetros indicados son interesantes (cambian el contenido del HTML) la usará igual. Básicamente solo es útil para indicar que no indexe URLs de campañas y ayudar un poco con los listados. Lo que seguro que no evitará esta función es que los robots entren en dicha URL

7. Todas las directivas no contempladas en la deficnición del robots se ignoran.

Por ejemplo el famoso «Crawl-delay» se ignora. En teoría debería indicar tiempo entre peticiones de robots pero no le hace caso así que podemos olvidarnos de esta sentencia al menos para Google (otros rastreadores si que le hacen caso).

Todas las directivas inventadas por terceros tambien se pasan por alto.

Y por último las lineas que empiezan por «#» también se ignoran al entenderse como comentarios. Sin embargo si que cuentan en el tamaño de archivo máximo así que es mejor no pasarse con su uso. Una recomendacion para comentarios: Cuando trabajamos con varios proyectos o muchos sites es mejor incluir notas de la version subida como comentario.:

#robots.txt for www.midominio.com DD-MM-YYYY

user-agent: ...

8. ¿Que pasa cuando Google no puede acceder o encuentra cosas raras al acceder a tu archivo robots?

Ya hemos dicho que el archivo robots.txt siempre se busca en la ruta «/robots.txt» de tu dominio. Y que si no lo encuentra, podrá ir a buscarlo a un nivel superior de dominio (si existe). Por ejemplo si no lo encuentra en www.dominio.com/robots.txt irá a buscarlo a dominio.com/robots.txt

Pero veamos ahora que pasa cuando lo solicita. Un servidor lo que hará cuando reciba la petición del archivo robots.txt es devolver un código de respuesta diciéndole a las arañas si lo está encontrando o no.

• Código «200». Significa que el archivo SI existe. Entonces lo leerá y aplicará sus normas. Si está vacío o googlebot no tiene directrices «disallow» entenderá que tiene acceso a todo y entrará hasta la cocina de la web
• Códigos «4xx» (404, 401, 403, etc.). Significa que el archivo no existe o no está abierto al público. En ese caso google lo entenderá como un archivo vacío y dará acceso a todo como si no contuviese disallows.
• Código «301». Significa «contenido movido permanentemente» y viene acompañado de una URL donde está el nuevo contenido. Google interpreta a todos los efectos que el contenido de esta URL a la que redirige robots.txt es el propio robots.txt, incluso si existe un cambio de carpeta, la URL está en otro dominio o si la URL no tiene el nombre «robots.txt».

  Conocer este detalle puede ser útil para gestionar robots.txt programados en algunos sistemas. Podemos tratar la URL de /robots.txt solo como una redirección a donde realmente gestionamos nuestro archivo robots.txt.

  Sin embargo también puede suponer un problema en migraciones mal realizadas de un dominio a otro o de http a https. En estos casos podemos encontrarnos con que al migrar un site devolvemos un 301 hacia el nuevo site con el robots.txt con lo que estaríamos aplicando el robots.txt nuevo al viejo dominio dejando de bloquear las urls viejas y pudiendo provocar una cascada de detección de errores y pérdida de tiempos de rastreo. Por general la recomendación debería ser que todos los sites tengan su propio /robots.txt y que nunca se redirija pero esto en la mayor parte de los casos no se hace así.

• Otros códigos (sobretodo 503). Si hay un error en servir el archivo, Google entiende que el dominio está caído y para no molestar para el rastreo del site y solo consultará el archivo 503 hasta que su error cambie. Parar el rastreo no supone desindexar, salvo que mantengamos así el servidor tanto tiempo que empiecen a perder fuerza los enlaces y contenidos de la página, por lo general mejor no hacerlo más de unas horas.

  El cómo actúa Google si este error persiste en el tiempo no lo sabemos exactamente pero por el motivo que sea suele llevar a perdidas de autoridad y a que se intente reindexar la web. Por este motivo, cuando hay errores técnicos en una web, y se están solucionando en ese mismo día, es preferible obligar al archivo robots.txt a que devuelva error 503 y así parar la indexación completa del site hasta que se arregle el problema. Esto es mucho mejor que bloquear el rastreo ya que lo segundo tiene implicaciones más severas y un simple 503 es totalmetne temporal.

• Sin respuesta. Otra posibilidad es que el servidor no devuelva nada o tarde demasiado tiempo en hacerlo (por problemas de configuración o porque la maquina está demasiado saturada). En esos casos Google tira de la caché que tiene de este archivo durante un tiempo. Es decir, interpreta el último archivo robots.txt al que pudo acceder y trabaja como si fuese este el que está subido.

9. El bloqueo de archivos JS y CSS puede ocasionar problemas e incluso está mal visto por el buscador

Google recomeinda no Bloquear archivos CSS y JS. Antigüamente eran archivos que se solían bloquear porque no le servian a las arañas para nada. Pero ahora los robots de google son capaces de interprertar el HTML y así situar los contenidos en su contexto (saben si un texto es grande o pequeño, el color de fondo o que sitio ocupan en el diseño y lo visibles que son los contenidos para los usuarios. Así que Google nos pide que le dejemos acceder a esto y así valorar la web al completo.

Si no les damos acceso a estos archivos es cuando empieza a enviarnos notificaciones y en la práctica la autoridad/calidad que percibe de nuestra web disminuye.

Esto no significa que no podamos nunca bloquearle un archivo JS (todos sabemos para qué ) pero si que hay que evitar este bloqueo a nivel general.

10. Google entra en contenidos 400 pero no si se le bloquea

Los contenidos 400 (páginas 404 – no encontradas, o 401 que suelen estar bajo login, etc…) si que son accedidos por las arañas. Google lo intenta y se encuentra al visitar las páginas con que estas no responden y por lo tanto no indexan.

Al final con esta situación lo que provocamos es perder tiempo de rastreo en URLs que nunca se van a indexar así que suele ser preferible bloquearles el acceso directamente. Pensemos en cualquier URL, incluso las de destino de los formularios de Google y una vez las tengamos presentes:

• 1. Evitemos que el HTML muestre links hacia ellas
• 2. Independientemente de si este acceso existe o no, marquemolas con con disallow en el robots

Bonus. Es posible enviar un noindex desde tu servidor creando una especie de robots.txt pero para noindex y nofollow

No cuento este punto entre los 10 conceptos pues en realidad habla más de directivas de indexación que de robots.txt y es más una posibildiad que no es fácil de implementar para todos ( y en su versión más sencilla no está recomendado y no sabemos realmente si funciona).

Hablamos de encontrar alguna forma no para prohibir el rastreo sino para prohibir la indexación: el equivalente a la metaetiqueta de robots marcada a «noindex» que comentabamos antes. Sobre este tema podréis leer de todo, lo más común es que os encontréis artículos que os hablen de la directiva «noindex:» dentro del archivo robots.txt

Esta directriz viene a decirnos que nosotros podemos crear sentencias noindex en el archivo robots con la misma nomenclatura.

Por ejemplo:

Allow: /categoria-1/
Noindex: /categoria-1/*-pag-*$

Vendria a decirle al robot que puede navegar por la categoría-1 y rastrearla pero que los contenidos de las páginaciones de esta categoría no deben aparecer en el índice de búsqueda.

Seria genial que nos dejasen hacer esto ya que como comentaba antes bloquear una URL no implica desindexarla y asi tendríamos un control total sobre todo esto. Sin embargo, y a pesar de que podréis ver como muchos SEOs lo mencionan e incluso Deepcrawl lo mide, Google ya nos ha dicho que no recomienda usarla y mientras lo sigan diciendo yo creo que carece de sentido hacerlo. Así que no disfrutamos de esta posibilidad…

En su lugar tenemos otra forma más complicada pero efectiva a nivel de servidor que podemos usar. Google tiene documentado el uso de directivas robots (index/noindex,follow/nofollow) con el uso de «x-robots-tag» en las cabeceras. Según esta definición tan solo tenemos que enviar una cabecera del tipo «x-robots-tag» con el mismo valor que pondríamos a la meta-etiqueta robots para para pasarlo desde servidor y no desde HTML.

A parte del propio sistema, esto nos abre la puerta a crear un archivo que gestione estas cabeceras en nuestro servidor. Podemos hacer esto con el lenguaje de programación de nuestro CMS (PHP, Java, .Net, etc.) o directametne en la configuración del servidor. En ella gracias a los archivos .htaccess y .htconfig podemos declarar el envio de cabeceras en un único archivo que definia qué puede y qué no puede indexar el robot.

Ejemplo para marcar un noindex,follow en paginaciones de tu web a través del archivo .htconfig:

  
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

Marcar no indexar incluir caché o descripción de los archivos PDF en el .htaccess…

Header set X-Robots-Tag "index, noarchive, nosnippet"

O no indexar paginaciones a través del módulo de modRewrite con el que gestionamos nuestras URLs amigables y redirecciones:

RewriteCond %{THE_REQUEST} "^(GET|POST) .*page/[0-9]+ HTTP"
RewriteRule .* - [ENV=NOINDEXFOLLOW:true]
Header set X-Robots-Tag "noindex,follow" env=NOINDEXFOLLOW

Pero no quiero estenderme demasaido con este sistema, si quieres leer más sobre como ponerlo en práctica te invito a que visites otro post de este mismo blog donde detallo otras 10 cosas que deberías saber sobre meta-robots. En la última de ellas se explica al detalle este sistema.

Conclusión

No se si os habrá pasado como a mi a medida que he ido descubriendo con los años todo lo que os he expuesto en este post, pero la verdad es que como todo en el SEO, te das cuenta de que nunca sabes lo suficiente de todo. Me pareció interesante recopilar todo esto porque sigo viendo con el tiempo que los problemas que existen en muchos sites debido a no entender bien los archivos robots.txt siguen ahí año tras año y nadie habla de ellos demasiado.

Asi que espero haber ayudado a algunos y a otros haberles descubierto algún detalle que desconociesen.

Como siempre os espero en los comentarios o por twitter.

20 Tips de Medición con Google analytics, mi charla en el SEonthebeach 5º aniversario 28 Jun 2017 12:04 AM (7 years ago)

Este fin de semana se celebró el ansiado SEonthebeach, el evento de marketing online más gamberro y distendido que existe (diría que en el mundo entero). Sin duda este año Sico y su gente se superaron, nos lo pasamos como nunca y aprendimos de un buen puñado de cracks de distintas disciplinas. Es genial cuando ves que un evento logra arreglar cada año los pequeños fallos del anterior y añadir un par de extras que terminen de redondearlo.

En esta ocasión di una pequeña charla sobre 20 tips de medición con Google analytics:
«Todo lo que no mides… (y deberias)». En ella se presentan técnicas que hemos ido desarrollando en IKAUE con el tiempo, todas contrastadas y efectivas para un caso u otro: La idea que cada uno se quede 2 o 3 que aplicar a sus negocios. Y creo que fue justo eso lo que sucedió pues tras darla no paró de pararme gente y cada uno habían elegido justo 1 o 2 tips que me prometian iban a probar de forma inmediata. A todos vosotros, ya sabeis, cualquier duda al implementarlos decidme y haré lo que pueda

Sin más os dejo aqui la charla colgada en slideshare, espero que os gustase a los que la visteis y os gusten los slides a los que no:

Y como no, dejo también un resumen de tweets que dejó la gente durante y después de la misma…

SEO Escalable, estrategias SEO de crecimiento 5 Jun 2017 10:27 PM (7 years ago)

Este fin de semana se celebró la séptima edición del Congreso Web Zaragoza (que se dice pronto!). El año pasado me lo perdí por enfermedad (no podía ni hablar) y la verdad es que tenía muchas ganas de desquitarme y poder dar la charla que por una vez y sin que sirva de precedente llevaba más que trabajada desde hace meses.

Puedo decir que nos lo pasamos todos realmente bien, charlas interesantes (dentro de que al ser evento genérico tocaba muchos muchos palos distintos) y un trato excelente por parte de la organización. Aunque sin duda si algo queda para el recuerdo será la entrada de Sico de Andrés como Rafaela Carrà…

En esta ocasión di dos charlas. Una más técnica el viernes por la mañana en el clinic seo sobre analisis de logs con Big Query y Data Studio y otra en el auditorio sobre «SEO Escalable», una charla de creación de estrategias de crecimiento y evolución de un site. La charla creo que tuvo muy buena acogida o al menos fue el feedback que me llegó. Y siendo sincero, para que negarlo, realmente reconforta cuando crees firmemente en un mensaje, te esfuerzas en comunicarlo y luego ves como le llega a la gente. Y así fue, tal cual.

Este post es solo para haceros llegar dicha charla. Son solo los slides usados, el vídeo lo tiene la gente del Congreso Web y ya veremos si lo hacen o no público

Para los más marujas os dejo también una colección de tweets con comentarios y fotos que la gente fue dejando durante y después de la charla. He seleccionado sobretodo aquellos que aportaban algún mensaje opinión o comentario y se que se me olvidan muchos pero cuando he visto que llevaba ya más de 10 capturas he tenido que parar…

¡Muchas gracias a todos!

Crear un dashboard de análisis de Logs SEO con Google Big Query y Google Data Studio 27 Mar 2017 1:33 AM (8 years ago)

La semana pasada fuimos otra vez al Clinic SEO del eShow de Barcelona. En este caso nos llevamos una metodología que sabíamos que iba a gustar a muchos SEOs. Explicamos los pasos necesarios que hay que dar para poder disponer de Dashboards accionables sobre la información de los logs de nuestro servidor: Es decir, cómo fabricar un Analytics del rastreo que hace Google de nuestras webs y asi poder optimizar mejor la indexación de nuestros proyectos.

El proceso aunque no se libra de la carga técnica de empezar a lidiar con nuevas herramietnas (sobretodo si nunca antes habías necesitado usar bigquery) lo tenemos ya lo suficientemente depurado como para poder presentarlo como pasos a seguir sin demasiadas complicaciones en la mayor parte de los casos.

Espero que con esta charla hayamos abierto una nueva puerta a mucha gente que no podía acceder hasta ahora al mundo del análisis de logs que tantas sorpresas (buenas y malas) te da en el mundo del seo.

No hay ni que decir que cualquier comentario, duda o crítica serán muy bien recibidos.