10 cosas que deberías saber sobre las etiquetas meta-robots, noindex, nofollow e indexación


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…


7 respuestas a “10 cosas que deberías saber sobre las etiquetas meta-robots, noindex, nofollow e indexación”

  1. ¡Grande Iñaki como siempre! Da gusto leer artículos tan completos con tantas fumadas que se encuentra una por ahí.

    Muy interesante el que Google lee la etiqueta desde cualquier parte de la página! Yo tampoco lo sabía.

    Justo estas últimas semanas he modificado unas etiquetas noindex,nofollow e index,follow a través de tag manager por dificultades con las subidas al robots.txt (el gran vacío entre dpto de desarrollo de clientes y la vida real).
    Visto que no podía modificar a corto plazo el robots.txt decidí modificar las etiquetas a través de GTM, sin embargo después de dos semanas veo que google me ha rastreado y desindexado algunas páginas con noindex,nofollow pero no indexa ninguna de las que llevan incluida la etiqueta index,follow. ¿Has visto algo parecido? Es decir, ¿crees que una desindexación es más rápida que una regla para indexar?
    Lo que he hecho es reescribir la meta actual porque son erróneas, indicando por tag manager que las que ahora están como noindex pasen a index y al revés, pero no me hace ni caso. ¿Algún consejo? ¿Crees que es cuestión de tiempo?

    De nuevo gracias por compartir tu sabiduría! 😀

    • Hola Laura! Gracias por tus comentarios.

      Mi experiencia es similar. Si añades Etiquetas meta con GTM sin existir las pilla pero si modificas las que ya existen en tests aislados va bien pero en la web real tarda muchísimo más y las lejanas no llega a aplicarlo a todas…

  2. Jajajajajja dios! Yo tampoco sabia que te leia la meta robots en cualquier parte!

    Esta chulo el arriculo 😉

    • Gracias Nacho.
      Si, me ha llevado un poco de craneo pero sabiéndolo supone que puedes usarlo en tu beneficio! 🙂

  3. Hola Iñaki! Tengo una duda. Dices en el punto 3 que no tiene mucho sentido añadir el noindex si queremos optimizar el crawl budget. Pero, ¿qué ocurre si tenemos un sitio web donde hay páginas que no queremos que aparezcan en los resultados pero sí que se sigan sus enlaces internos para potenciar la autoridad de nuestras páginas internas? ¿No crees que compensa la autoridad que puedan adquirir, para un sitio donde el número de páginas internas no es tan relevante como para que perjudique el crawl budget?
    Gracias!

    • Buenas. Gracias por comentar luis!

      Te paso mi opinion: Al final nada es absoluto. Para cada situación hay distintas formas de resolver lo mismo y nunca tienes la certeza al 100% de cual es mejor.

      No digo que una fórmula de noindex,follow no pueda ser válida en algunos contextos. solo matizo no frenamos igual al rastreo que con el robots.txt y tenemos que ser conscientes de ello. No es el fin del mundo pero la realidad es que pierdes rastreo (como en muchos otros sitios)

      Para el caso que comentas yo investigaria antes la necesidad real de ese noindex. En muchos casos (Pero no en todos) ves que se deben a fallos en una estructura de enlazado que podría haberse resuelto mejor. En esos por supuesto es mejor resolver bien la estructura que andar con parches.

      Muchas estructuras de este tipo pueden solucionarse aportando varias vías de enlazado desde varios puntos haciendo innecesario linkar desde páginas irrelevantes para el seo.

      Muchas otras veces se aplica en paginaciones de listados donde en realidad tiene más sentido un rel=next/prev donde sigues sin provocar indexación de las páginas altas, mejoras la autoridad de la página 1 y los enlaces se siguen igual. Igualmente en estos casos dejar de indexar las paginaciones en algún punto es importante pues las arañas pierde mucho tiempo muchas veces para recorrer los mismos items que ya tienen en otros listados (de categorías, taxonomía, filtros, etc)

      Luego por supuesto hay casos donde un noindex,follow tiene todo el sentido. Si lees los siguientes puntos verás que sobretodo no soy amigo del nofollow y eso te deja si o si con varias páginas noindex,follow donde no quieres indexar pero ya que la araña pasa por ahí si quieres no perder esos links.

      Si al final hay tantos casos…

  4. Buenos dias,
    Llevaba indagando varios dias sobre este tema para poder incluir las meta robots en mi WP sin necesidad de plugins y tu articulo me parece, sin duda, lo mejor de todo lo que he leido hasta el momento sobre este tema. Felicidades, porque te has lucido.

    Me queda una pequeña duda una vez implementado el codigo, para comprobar si realmente lo he hecho bien. Como no tengo acceso al .htconfig, no tengo mas remedio que utilizar el .htaccess y entornos de modRewrite. Supongo que sera el caso mas habitual.

    Una vez introducidas las 3 siguientes lineas para desindexar el blog que ponias en tu ejemplo (o bien su equivalente para las categorias o tags (p.e /category/.* o bien /tag/.*)

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

    Voy a la herramienta online dnsqueries y me devuelve esto:

    HTTP CODE = HTTP/1.1 301 Moved Permanently
    Date = Wed, 20 Dec 2017 12:37:26 GMT
    Server = Apache
    Location = http://www.midominio.com/tag/
    Vary = Accept-Encoding
    Content-Type = text/html; charset=UTF-8

    ¿Esto es correcto?
    Aparece un aviso 301 en lugar del noindex. Si embargo, al desactivar las 3 lineas anteriores, devuelve lo mismo pero con un aviso 200, o sea, todo OK.

    Gracias por tu esfuerzo al redactar el articulo, ha sido de gran ayuda.
    Un saludo.

Responder a Luis Revuelto Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *