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

En este post, vamos a desentrañar todas las facetas de la etiqueta meta-robots, desde sus funciones básicas, hasta sus detalles más sutiles, para asegurarnos de que tengas toda la información necesaria para optimizar tu estrategia de SEO. ¡Empecemos!

Índice de contenidos

Después de compartir un post detallado sobre los aspectos poco conocidos del archivo Robots.txt, ahora es momento de explorar el recurso hermano: la etiqueta meta-robots. Este elemento es otro pilar fundamental del SEO, del cual todos creemos saber algo, pero que, como siempre, posee una cantidad considerable de particularidades que fácilmente pueden pasar desapercibidas para muchos. Es muy probable que incluso en este post, haya algún detalle que no se haya abordado, pero aún así, considero que hay aspectos que la mayoría de los profesionales del SEO desconocen o, como mínimo, conocieron en el pasado pero ya no lo aplican. Así pues, este artículo será, como poco, una referencia de detalles a repasar:

¿Cómo añadimos una etiqueta Robots a una página?

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

  • Debe estar en el HTML de la página, específicamente dentro de la etiqueta «head» de la misma.
  • Solo tiene que estar declarada una vez por página.
  • Se trata de una etiqueta «meta» que se compone de 2 atributos «name» y «content»: «name» indica qué aplica la etiqueta; mientras que «content» es el atributo que marca las directrices a seguir. Así pues, su formato normalmente es el siguiente:
<meta name="robots" content="valor1, valor2, ...">

<meta name=»robots» content=»{{Directrices para robots}}»>

No tiene más misterio, la única complejidad es que cuando hacemos SEO en un site a un nivel alto solemos definir exactamente qué 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 cómo usar la etiqueta Robots para optimizar el SEO de nuestro sitio web.

¿Qué podemos hacer y cómo se interpreta esta etiqueta?

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

Los valores, es decir, las directrices o reglas posibles a indicar en el atributo «content» de la etiqueta Robots 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.

Estas directrices pueden estar en minúsculas 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), ya que Google entenderá perfectamente tanto «noindex,nofollow» como «noindex, nofollow» o «noindex , nofollow».

Dentro de estas directrices o valores las de «index» y «follow» son las más conocidas pero no son las únicas y podemos encontrar algunas interesantes a usar en momentos determinados.

  • 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 y en pocos días veremos que el contenido desaparece. Si la usamos al publicar un nuevo contenido, éste 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 sea 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 qué tiene Google sobre nuestras páginas, así 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: Así 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. Ésta 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: Esta etiqueta se utiliza para evitar que se muestre una descripción del resultado en los resultados de búsqueda. Personalmente no le veo mucho sentido: sacrificar el CTR solo porque no queremos tomarnos el tiempo para escribir una meta descripción… La hemos utilizado solo en casos muy específicos donde, por alguna razón desconocida, Google no mostraba la descripción que queríamos.
  • max-snippet:[number]: Esta permite especificar el número máximo de caracteres que se pueden mostrar en el fragmento de texto de la página en los resultados de búsqueda.
  • max-image-preview:[ajuste]: Esta permite especificar el tamaño máximo de la imagen que se puede mostrar en el fragmento de la página en los resultados de búsqueda. Los ajustes posibles son: none, standard y large.
  • max-video-preview:[número]: Esta permite especificar el número máximo de segundos que se pueden mostrar en el fragmento de vídeo de la página en los resultados de búsqueda.
  • none: es una etiqueta en desuso que viene a decir que lo marcamos todo a no (noindex,nofollow,notranslate,noarchive,nosnippet,…). No se suele usar 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.

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 difícil que quieras indexar una página de la cual no te interesa ninguno de sus links.
  • noindex,follow: En 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 aún 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.

Es común ver a muchos SEOs Junior señalar la ausencia de esta etiqueta «meta-robots» como un defecto del sitio, aunque ésta no sirva para nada. Nada más lejos de la realidad.

Debemos entender que esta etiqueta sobre todo 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 indexar todo, seguir cualquier link y poner la información que deseen de tu web. Por lo tanto, las directrices positivas como «index,follow» no aportan nada a la lectura que hacen los robots del site. Aunque no perjudica tenerlas, la falta de estas reglas no debería considerarse como falta de optimización del sitio.

En SEO siempre luchamos contra las ventanas de trabajo que nos aportan los técnicos, que siempre son menos de las que nos gustaría. Generar tareas que no aportan nada no es una buena práctica.

Además, desde un punto de vista purista, podríamos argumentar que incluir la etiqueta «meta-robots» aumenta el peso de la página, por lo que en realidad se optimiza más nuestro SEO al no incluirla. 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 sería suficiente indicar solo «noindex», ya que entenderá que sí puede seguir los enlaces. Sin embargo, a menudo se utiliza la combinación completa por motivos de claridad, aunque sea para dejarnos a nosotros mismos claro lo que buscamos al indicarla.

En realidad, no ganamos mucho al eliminar estas reglas, aunque no nos aporten nada. Por lo tanto, en estos casos, la presencia o ausencia de estas directrices no debería ser motivo de preocupación, ya que el sitio está bien resuelto independientemente de su configuración.

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 índice 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.

Bien, permíteme contradecirme a mí mismo en este momento. Resulta que en realidad el noindex sí 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. ¿Por qué los robots deberían dedicar tiempo a recorrer repetidamente contenido que no pueden indexar? 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 rastrea todo de 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 sí 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ámoslo todo en cuenta: sí afectas al rastreo; no obstante, si es tu intención afectarle, tienes herramientas mejores.

5. Pensemos un poco: ¿Por qué quieres poner un nofollow en tu web? ¿Sirve de algo?

Sobre este tema, es probable que muchos SEOs discrepen conmigo. Sin embargo, cuanto más lo analizas, menos sentido encuentras en utilizar la etiqueta «nofollow» en muchas de las páginas donde se está implementando.

Partamos del concepto que veíamos antes: Google rastreará esta página pase lo que pase. Entonces, ¿cuáles son tus opciones? Francamente, no las veo muy claras…

index,nofollow:

Esta combinación levanta sospechas. ¿Quieres posicionar una página pero evitar que la autoridad se transfiera a los enlaces? No tiene mucho sentido, a menos que estés involucrado en prácticas poco éticas como intercambios de enlaces.

noindex,nofollow:

Esta es la combinación clásica que muchos emplean sin cuestionar. Pero, ¿has reflexionado sobre si realmente es lo que deseas? Muchas personas simplemente deciden no indexar una página y automáticamente aplican el «nofollow». Esto se hace más para limitar el rastreo a cero, similar a lo que se lograría con el archivo robots.txt, que por una verdadera necesidad. Deberíamos considerar cuidadosamente cómo las arañas de los motores de búsqueda interactuarán con cada página que encuentren, y descubrirás que muchas veces el uso de «nofollow» carece de sentido.

¿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?

Tiene sentido, pero ¿qué sucede con sus enlaces? Las arañas de búsqueda pasarán por allí de todas formas. ¿Estás seguro de que no quieres que sigan los enlaces y aprovechar un poco de autoridad de esas páginas que no deseas en el índice pero que sí tienen autoridad? Reflexiona sobre ello y verás cómo eliminas el atributo «nofollow» de muchos enlaces, como los de contacto, avisos legales, secciones de marketing, ¡porque cada enlace cuenta!

¿Quieres frenar a la araña de indexar estructuras completas y no puedes con robots.txt?

En ese caso, si tienes, por ejemplo, un catálogo completo que no deseas indexar (ya sea porque es basura, está obsoleto, o simplemente no quieres que aparezca en los resultados de búsqueda), y no puedes bloquearlo por completo mediante el archivo robots.txt, entonces la única opción que te queda es eliminar la autoridad de los enlaces de ese catálogo. En este caso, te recomendaría trabajar especialmente con el atributo «rel=nofollow» en los enlaces que dirigen a esa área del sitio. Además, dentro del propio catálogo, donde habrá muchos enlaces que apuntan a estas áreas, utilizar el atributo «nofollow» será más efectivo.

6. Podemos usar la etiqueta meta para indicar a los robots de búsqueda cómo queremos que traten nuestra página.

Google tiene diferentes robots específicos para diferentes tipos de contenido, y podemos usar etiquetas específicas para cada uno de ellos. La lista completa y actualizada de los robots de Google la tienes a continuación:

🔗 https://support.google.com/webmasters/answer/1061943?hl=es-419

No obstante, a veces no queremos que todos los robots se comporten de la misma manera, especialmente cuando nos encontramos con temas de SEO vs. Publicidad de pago, o bien, cuando queremos optimizar nuestro contenido para los distintos buscadores especializados de Google.

Dicho de otro modo, en algunos sitios creamos páginas que no queremos que Google indexe porque no aportan valor desde el punto de vista SEO, pero en cambio son páginas que pueden funcionar bien con ciertas campañas y queremos que otros robots puedan acceder a ellas. Para lograr esto, podemos usar más de una etiqueta.

La etiqueta name=“robots” se aplica al caso general, es decir, a todos los robots que no tengan una etiqueta específica. Luego podemos añadir etiquetas específicas para los distintos robots de Google, usando el formato de:

name=“googlebot-[tipo de contenido]”.

Por ejemplo, si usamos estas etiquetas:

<meta name=“robots” content=“index,follow”>

<meta name=“googlebot-ads” content=“noindex”>

Estamos diciendo que todos los robots, excepto Googlebot-Ads, pueden indexar y seguir los enlaces de la página, pero Googlebot-Ads no puede indexarla. Esto puede ser útil si queremos evitar que nuestra página aparezca en los anuncios de Google.

Otro ejemplo sería este:

<meta name=“robots” content=“index,follow”>

<meta name=“googlebot-image” content=“noindex”>

Aquí estamos diciendo que todos los robots pueden indexar y seguir los enlaces de la página, pero Googlebot-Image no puede indexar las imágenes de la página. Esto puede ser útil si queremos proteger nuestras imágenes o evitar que se consideren como contenido duplicado.

Por otro lado, si lo que queremos es que la evitar que la página apareciera en el buscador de noticias, puesto que la etiqueta name=“googlebot-news” ya no se usa, es decir, Google News (de vuelta en España) usa el mismo robot que Google Search (“googlebot”), habría que usar la herramienta de editor de Google News o la etiqueta “noindex” para ello

¿Qué más ha cambiado respecto a hace unos años?

  • La etiqueta name=“googlebot-video” ya no se usa, ya que Google usa (de nuevo) el mismo robot (“googlebot”) para rastrear e indexar los vídeos. Así que si quisieras controlar cómo se muestran tus vídeos en los resultados de búsqueda, podrías usar el archivo robots.txt, la etiqueta noindex o el atributo data-nosnippet.
  • A diferencia de la anterior, la etiqueta name=“googlebot-image” sí se usa, pero solo para controlar la indexación de las imágenes en Google Imágenes, no para controlar cómo se muestran en los resultados de búsqueda. Si quisieras evitar que tus imágenes aparecieran en los resultados de búsqueda, también deberías usar el archivo robots.txt, la etiqueta noindex o el atributo data-nosnippet.

7. Cuando mezclas noindex con otras directrices en el HTML (canonical, rel=”prev/next”, etc.) puede no funcionar como esperas.

Establezcamos una regla básica: si optamos por no indexar algo, evitemos liar a Google con múltiples directivas adicionales. Esto puede generar confusión y llevar a resultados inconsistentes en diferentes casos. Es una mala idea.

  • 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 qué 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 esté 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), sino porque demuestra el caos que representa juntar estas directrices. Puestos a no saber qué va a hacer el buscador mejor no confundirle, ¿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 no es exactamente así). 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 de nuevo sería mejor no fiarse y provocar ese caos.

En conclusión, es recomendable no mezclar directrices de indexación contradictorias en el HTML. Revisa lo que tienes en el tuyo y observa si estas directrices se contradicen.

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

Como Sergio Simarro me comentó una vez y pude verificar, a Google le da realmente igual dónde se encuentra tu meta-robots en la página. Si 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 comentaba antes sobre robots.txt, en su primera edición dejé escrito en el artículo la etiqueta «<meta name=”robots” content=”noindex” />» y olvidé codificarla con carácteres HTML para que no se entendiese como parte del HTML. Esto provocó dos cosas:

  • Que el 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, desindexase la home del blog ya que también aparecía esa etiqueta ahí. Y por el mismo motivo, desindexó también la categoría de indexación del blog.

¿Interesante, ¿verdad? Por lo tanto, si vais a escribir sobre SEO en vuestra web, tened mucho cuidado, porque Google puede leerlo. Y si os encontráis con una página que ignora los estándares web, tened precaución, ya que vuestras herramientas podrían estar detectando algo diferente a lo que Google está percibiendo.

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

No es un secreto que Google interpreta 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 clic 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:

<script type="text/javascript">

var m = document.createElement(‘meta’);

m.name = ‘robots’;

m.content = ‘noindex’;

document.getElementsByTagName(‘head’)[0].appendChild(m);

</script>

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.

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í, con programación podemos añadir las que deseemos, así que no nos cuesta demasiado añadir una línea 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é es mejor introducir las directrices de robots por headers que en el HTML?

1. Google es consciente antes.

El primer punto interesante es que Google se percata mucho antes de que estas directrices existen. Así que básicamente podemos evitar los problemas de colisión con otras etiquetas HTML que hablábamos 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 también pueden enviarse en cabeceras y ahí sí que habría colisión.

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

2. Nuestra estrategia no es tan obvia.

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 difícil mirar headers al hacerlo:

  • Podéis usar varios plugins de Chrome.
  • Alguna herramienta online especializada como DNS Queries.
  • Y los rastreadores más populares (Screaming Frog, Sitebulb, Deepcrawl…) incluyen este dato.

Pero lo cierto es que a muchos se les pasa por alto. En un primer análisis 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.

3. No hay que tocar la maqueta del site.

Siguiendo con las ventajas, la programación del site no implica tocar maqueta, por lo que los desarrolladores no tienen porqué tocar plantillas para ir añadiendo este tag a la web. Muchas veces suponemos 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.

4. Se pueden definir desde el servidor.

Por último, las cabeceras no solo se pueden controlar desde programación. Desde la configuración del servidor también 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 cuáles indexamos y cuáles no. En la práctica, esto significa que tenemos un sitio fácil 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). En fin, ya has leído demasiada intro, así que vamos a lo interesante: definir este tipo de líneas en el .htaccces.

¿Cómo definir este tipo de directrices en el .htaccces de la web?

Para eso usamos la directiva de configuración «Header set» o «Header add». Éstas 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 sí que estén activas y de no estarlo, tendrás que ponerte en contacto con tu proveedor para que te diga cómo activarlas (si es que es posible).
  • 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.

¿Cómo sé si lo tengo activo? Bueno, puedes comprobar los módulos tú 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.

¿Cómo activar el módulo de headers en Apache?

Tenemos que entrar por consola y ahí 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 qué 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 cómo funciona nuestro servidor, todas estas definiciones las englobaremos en las etiquetas «<ifmodule mod_headers.c=»»>» y «</ifmodule>» 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 «locationmatch», 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:

<ifmodule mod_headers.c="">

<locationmatch «=»» page-[0-9]+$»=»»>

Header set X-Robots-Tag «noindex,follow»

</locationmatch>

# Otras definiciones para crear cabeceras

</ifmodule>

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).

<ifmodule mod_headers.c="">

<locationmatch «^=»» (contactar|aviso-legal)$»=»»>

Header set X-Robots-Tag «noindex,follow»

</locationmatch>

# Otras definiciones para crear cabeceras

</ifmodule>

Como podéis ver, si realmente nos permiten acceder a donde necesitamos para hacer estas definiciones, puede resultar bastante sencillo. Lamentablemente, muchos negocios pequeños no tendrán acceso a este archivo, y en empresas más grandes, es posible que el personal de sistemas no vea con buenos ojos que hagamos cambios allí (ya que es mucho más delicado que modificar un archivo htaccess).

2. Con .htaccess y ficheros.

En .htaccess (donde en SEO estamos más acostumbrados a entrar) también podemos trabajar, pero por desgracia las directivas de <location> y <locationmatch> aquí no están disponibles. Así que no podemos acceder a URLs como tales, sino a los ficheros y carpetas de la web.

En lugar de <locationmatch> aquí disponemos de <filesmatch> para jugar con los nombres de archivos y con <directory> 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 caché ni descripción de nuestros archivos .doc o .pdf (aunque con unas pequeñas correcciones), como veis aquí sí podemos usarlo porque se refiere a archivos concretos.

<ifmodule mod_headers.c="">

<filesmatch «\.(doc|pdf)$»=»»>

Header set X-Robots-Tag «index, noarchive, nosnippet»

</filesmatch>

</ifmodule>

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

<ifmodule mod_headers.c="">

<directory ~=»» «.*=»» wp-admin=»» .*»=»»>

Header set X-Robots-Tag «noindex,nofollow»

</directory>

</ifmodule>

Como sí que es un directorio real en el servidor (podemos incluso verlo en el FTP de nuestro proyecto), sí podemos trabajar con él en .htaccess.

3. 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? Sí, 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, éste 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 cómo se leen las URLs es capaz, además, de crear entornos (environments). Luego estos entornos pueden recibir headers distintos cada uno. ¿Cómo hacemos esto? Pues es un poco más complejo que antes, pero sigue siendo sencillo:

  • Identificamos en nuestro .htaccess donde empiezan las acciones de modRewrite.
  • Debemos escribir siempre después del condicional de y de su configuración básica, pero antes de ninguna declaración que afecte a ninguna URL.
  • Tres líneas distintas:
    • La primera 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 detectar 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

<ifmodule mod_rewrite.c=»»>

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</ifmodule>

# 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 «<ifmodule mod_rewrite=»»>», vemos su configuración básica que enciende el motor y establece la URL base a «/» y bajo ésta 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 categorías principales de WordPress. el código sería el mismo pero la expresión 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. No obstante, muchas veces sí 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 que deben controlarse en cuanto a la indexación puede resultar abrumadora. En este artículo, nos hemos centrado únicamente en los dos recursos más básicos, lo cual debería ser suficiente para replantear las estrategias de muchos sitios web.

Como en todo, es importante priorizar y seleccionar. No es necesario aplicar todas las técnicas a todos los sitios web, e incluso si se decide hacerlo, no es necesario implementarlas todas de inmediato. Es fundamental comenzar por asegurarse de no cometer errores, luego seleccionar cuidadosamente qué queremos lograr con las arañas de los motores de búsqueda, y finalmente ir avanzando de manera gradual.

Estos ajustes se notarán con el tiempo, especialmente en sitios donde Google no alcanza a indexar todas las páginas que ofrecemos. Tener el control sobre qué páginas se indexan y cuáles se siguen rastreando significa que podemos elegir las palabras clave que realmente nos importan, lo que se traduce en un aumento en las visitas al sitio.

Por ahora, dejaré estos temas aquí. Quién sabe, tal vez en el futuro me adentre en temas como sitemaps, canonicals (que son bastante complejos), atributos rel… E iré revisando y actualizando estos artículos ante cualquier cambio. ¡Hay mucho trabajo por delante!

Iñaki Huerta
CEO de IKAUE

Director de IKAUE. Analista Digital y SEO hace más de 15 años. Internet Lover, Creador de Hilillos y DataHacker.

También te puede interesar

¡Suscríbete!

RECIBE NUESTRA NEWSLETTER

Registrar nueva cuenta

IKAUE MARKETING ONLINE, S.L. es la Responsable del Tratamiento de tus datos, con la finalidad de gestionar tu registro y remitirte nuestra Newsletter con las últimas novedades y/o promociones. Tienes derecho de acceso, rectificación, supresión, limitación, oposición al tratamiento y portabilidad. Puedes ejercitar tus derechos [email protected]. Más información en la Política de privacidad.