10 cosas que deberías saber sobre las etiquetas metarobots noindex nofollow e indexación

10 cosas que deberías saber sobre las etiquetas metarobots noindex nofollow e indexación

15 Jul 2020 in

Y después deltocaba hablar un tanto sobre el recurso hermano de este: la etiqueta meta-robots. Otro básico del posicionamiento SEO del que todo el planeta sabe cosas mas que como siempre tiene tal cantidad de pecularidades que es fácil que a muchos se nos escapen ciertas. 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 mas ya no lo aplican.

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

Back to top

1) 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 puesto que su formato en general es el siguiente:
    <meta name="robots" content="Directrices para robots"/>

No tiene más misterio, la única dificultad es que cuando hacemos posicionamiento web en buscadores en un site a un nivel alto acostumbramos a acotar precisamente que valores queremos en todos y cada página del site con lo que tenemos que preocuparnos de que nuestro CMS o la programación de nuestro site nos permita manipularla a nuestro criterio.

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

Back to top

2) 1. Existen más directivas a declarar de las que sueles utilizar (pero se emplean mucho menos)

Las directrices posibles a apuntar en el atributo "content" de la etiqueta se definen casi siempre a pares positivo/negativo y son todas y cada una opcionales. Podemos declarar las que deseemos, que el resto se entenderá siempre y en todo momento como positivas.

Las indicaciones pueden estar en minusculas o mayúsculas (se comprende igual un "Nofollow" un "NOFOLLOW" y un "nofollow" y entre ellas se apartan por comas (incluyendo las que deseemos en la página). No importa demasiado si usamos espacios entre ellas o bien no, aunque la costumbre es no usarlos, Google entenderá con perfección tanto "noindex,nofollow" como "noindex, nofollow" o bien "noindex , nofollow".

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

  • index/noindex:Esta es la directiva más poderosa que podemos utilizar. Con ella le afirmamos a Google que no deseamos 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 utilizamos al publicar un nuevo contenido este no aparecerá jamás en el buscador.
  • follow/nofollow:La segunda más utilizada. Con ella le decimos que no rastree los links de esta página. No nos engañemos Google los va a rastrear mas 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 supervisar la publicación de la caché que tiene Google sobre nuestro contenido. Si no deseamos que la caché de esta página se alcanzable al público la marcaremos como noarchive. Esto puede ser útil para contenidos o noticias altamente sensibles, cosas a ocultar o contenidos demasiado dinámicos para que esta caché sea útil. En general la caché nos ayuda a ver que tiene Google sobre nuestras páginas así que no solemos desactivar su publicación.
  • translate/notranslate:Con ellas podemos indicar a Google que no deseamos darle la opción de traducir al usuario. Simplemente no le aparecerá ese link para emplear 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":La más extraña de todas. Esta nos permite indicar que queremos desindexar el artículo desde una data determinada. Útil cuando nuestro contenido deja de ser vigente o después de promociones caducadas que de seguir indizadas harían más daño que bien. Que no os asuste el formato RFC-850, es sencillamente una cadena como la que sigue: "20 Sep :00:00 GMT". Podemos discutir sobre su empleo 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, mas de todas formas pasada la fecha mejor dejar un "noindex" que un unavailable_after con data pasada.
  • snippet/nosnippet:para que no muestre descripción del resultado. A ver, que alguna utilidad debe tener no mostrarlo solo que no se la veo. Peor click through rate y solo por no querer escribir un meta... La hemos utilizado solo para casos muy especiales donde por un motivo extraño Google no utilizaba 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 emplea por el hecho de que 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 empleaban 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 carece de sentido utilizarlas a día de el día de hoy si bien prosigan en las documentaciones.

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

  • noindex,nofollow:Cuando no queremos 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 mas no traspasar autoridad a sus links. Esto solía emplearse antaño en páginas de agradecimientos y de intercambios de links (cuando menos los posicionamiento SEO timadores)... que tiempos. A día de el 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 en el caso de que no te interese indexar esta página mas si quieres que las arañas se tomen en serio sus links. Muy usada antes de la aparición del rel="next/prev" para paginaciones y aun el día de hoy para sistemas de páginas y arreglar defectos de la indexación
Back to top

3) 2. Es probable que la etiqueta meta robots (o cuando menos una parte de sus directrices) no sea precisa en la mayoría 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 comprender que esta etiqueta sobretodo marcha para limitar el empleo que pueden hacer los robots (y Google particularmente) de tus datos. Por defecto van a entender que pueden indexarlo todo, proseguir cualquier link y poner la información que deseen de tu página web, en consecuencia 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 puesto que no estará mal si las incluimos mas de ahí a decidir que un site no esta optimizado por no contar con de ellas hay un largo trecho. En SEO siempre y en toda circunstancia luchamos contra las ventanas de trabajo que nos aportan los técnicos, que siempre y en todo momento son menos de las que nos gustarían. Generar labores que no aportan nada (mierdiptimizaciones, las llamamos ) 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 en consecuencia liberándonos de todas y cada una de las etiquetas positivas de la página en realidad optimamos más nuestro posicionamiento web que incluyéndolas. Y siguiendo con esta lectura el típico "noindex,follow" tampoco tiene sentido. "follow" ya es una directriz que debería proseguir el buscador con lo que lo propio sería solo señalarle "noindex" y el ya entenderá que si que puede continuar los links. Sin embargo por claridad justo esta combinación si suele utilizarse aunque sea para dejarnos a nosotros mismos claro lo que buscamos al apuntarla. La realidad es que tampoco ganamos mucho quitándo estas directrices si bien no nos aporten nada, asi que dados estos casos todo esta bien resuelto esté como esté el site.

Back to top

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

Es decir, esta directriz está dirigida 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 motores de búsqueda la visiten y saquen su información. En verdad 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. En resumen diríamos que Google nos destina un tiempo de proceso de nuestras páginas, a mayor crawl budget más capaz es de localizar todos nuestros contenidos. Bien puesto que al añadir páginas con noindex estamos produciendo trabajo inútil a estas arañas: Les hacemos rastrear páginas que no van a indexar. Así que si lo que queremos es optimar el crawl budget el robots.txt suele ser mucha mejor opción.

Back to top

5) 4. Mas noindex si afecta al rastreo: Lo disminuye.

Venga, y voy a contradecirme yo solo ahora mismo. Puesto que es que realmente el noindex si que afecta al rastreo y por ende al crawl budget, cuando examinas los logs, acostumbras a ver que las páginas con noindex pierden rastreo. Si las comparas con páginas afines del site en autoridad interna los robots acaban 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 emplear? Lo normal es que se rastreen menos, si bien indudablemente 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 diferentes) podríamos decir que el rastreo reduce con las indicaciones 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 incluso puede visitarla más de una vez al día. Al fin y al cabo si le afirmamos que siga los enlaces debe rastrearla. Mas 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 por ciento seguro, mi sensación es que se rastrea aun algo menos
  • bloqueo por robots.txt:Se anula en una gran parte el rastreo, proseguimos encontrando hits (pese a que los hemos prohibido) a las páginas por la parte del los robots mas son anecdóticos

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

Back to top

6) 5. Pensemos un poco: ¿Y a fin de que deseas poner un nofollow en tu web? ¿sirve de algo?

Y esto es algo sobre lo que muchos SEOs me van a llevar un tanto la contraria. Mas 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 cuanto 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 enlaces? 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 planeta emplea a diestro y siniestro pero... ¿has pensado si verdaderamente es lo que deseas? Mucha gente solo piensa en que no quiere indexar la página ya ya decide que tampoco se prosigue. Esto es más por acercarse al 0 rastreo de los robots.txt que porque sea lo que realmente deseas. Deberiamos pensar que van a hacer las arañas con cada página que encuetren y te encontrarás con que en muchas ocasiones 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 pasará por ahí de todas y cada una maneras, ¿seguro que no quieres que siga los enlaces y rascar un tanto de autoridad de esas páginas que no deseas en el índice pero que autoridad si que tienen? Piensalo y verás como quitas el nofollow de muchos contactar, avisos legales, secciones de marketing, etc. ¡Todo enlace cuenta!

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

    En este caso, si, si por servirnos de un ejemplo tienes todo un catalogo que no puedes indexar (por el hecho de que es basura, porque esta parseado, por el hecho de que no lo quieres y punto) y nadie te deja bloquearlo al completo por Robots.txt si que es verdad 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 enlaces que van ahí mas además en el propio catalogo que tendrá muchos enlaces a todas y cada una estas zonas un nofollow será más efectivo.

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

Bien, tiene todo el sentido, mas que pasa con sus enlaces. La araña va a pasar por ahí de todas formas, ¿seguro que no deseas que siga los links y rascar un tanto de autoridad de esas páginas que no quieres en el índice mas 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!

En este caso, si, si por poner un ejemplo tienes un catalogo que no puedes indexar (por el hecho de que es basura, porque esta parseado, por el hecho de que 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 suprimir la autoridad a los links de ese catalogo. Ahí trabajaría sobretodo los rel="nofollow" de los enlaces que van ahí mas además en el propio catalogo que tendrá muchos enlaces a todas estas zonas un nofollow será más efectivo.

Back to top

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

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

La lista de robots por separado está aqui:

En ocasiones no deseamos tratar igual a todos los robots, esto sucede especialmente cuando nos encontramos con temas posicionamiento en buscadores vs Publicidad de pago o cuando lidiamos con los diferentes motores de búsqueda especializados de Google (que tienen cada uno de ellos su araña). En muchos sites creamos paginas que no deseamos que Google indexe porque hablando en términos posicionamiento web en buscadores son basura, pero son páginas que con determinadas campañas pueden convertir realmente bien con lo que si queremos que otros robots puedan acceder a ellas.

Asi puesto que podemos crear más de una etiqueta. name="robots" siempre y en toda circunstancia se ocupará del caso especial, mas luego podemos añadir etiquetas más especificas para los distintos robots:

Que vendría a prohibir la indexación 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 servirnos de un 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.

Back to top

8) 7. Cuando mezclas noindex con otras indicaciones en el html (canonical, rel="prev/next", etc. las cosas no marchan como esperarías

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

  • Comentábamos que una vez señalas un noindex marcar cosas como nosnippet, noarchive, notranslate, etcétera carecía de sentido:si no indexas no hay resultado y por lo tanto no hay que tocarlo. Marcar cosas en negativo no tiene inconvenientes mas 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 + canonicales ya un clásico. Que no tiene sentido es obvio, no puedes decirle al robot que no te indexe mas que la url canónica (a no indexar) es otra. ¿Pero que buscas con eso? La cuestión es que consigues que se comporte de forma caótica y no puedas saber con absoluta seguridad si va a aplicar el noindex o no de la página. Me gustapero no por el hecho de que este conforme con sus conclusiones (yo siempre he creído que la primera indexación es muy parcial y básica y sus ensayos creo que responden más a eso responde a eso) sino más bien porque demuestra el caos que representa unir estas directrices. Puestos a no saber que va a hacer el buscador mejor no liarle, ¿no?
  • Y entonces el segundo clásico para paginaciones: ¿podemos usar "noindex,follow" desde la primera página y además añadir un rel="next/prev"a todas y cada una? La lógica nos vuelve a decir que no tiene sentido: next/prev sirve para identificar que múltiples 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 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. Examina lo que tienes puesto y mira que no te contradigas a ti.

Back to top

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

Y esto lo he descubierto y vivido en mis carnes recientemente y no ha sido hasta queme ha avisado que no he sido consciente de ello. Y es que parece que a Google le importa un pimiento donde pongas tu meta-robots. Si el lo ve en la página, en cualquier una parte del HTML lo lee y lo prosigue (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, 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 a fin de que no se comprendiese como una parte del HTML. Esto provocó dos cosas:

  • Que en artículo no se viese esa parte escrita (encontrando una oración inacabada en un párrafo)
  • Que Google no me indexase dicho artículo y ya de paso me desindexase la home del weblog en tanto 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 posicionamiento en buscadores 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.

Back to top

10) 9. Google lee y obedece a las etiquetas que creamos en el HTML por javascript y por ende 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 bien menos, si todo carga en el primer print de página (sin necesitar click o bien acciones del usuario) acaba leyéndolo. Esto ha abierto gran cantidad de posibles parches JS o de forma más controlada vía Google Tag Mánager (una herramienta de gestión de tags de analítica y marketing).

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

Por ejemplo, para desindexar contenido desde Google Tag Mánager 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 tanto pero acaba desindexando el contenido de Google.

Back to top

11) 10. También podemos mandar las indicaciones de meta-robots desde las cabeceras de la página

Esto ya lo adelanté en otro blog post pero en realidad tocaba mentarlo en este. Además comentare ciertas cosas más sobre para qué hacerlo y como lograr la configuración...

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

Todo esto está detallado en la. Esta nos detalla el empleo 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 pedimos y sirven para muchas cosas distintas: informan de si la página es adecuada, si da cuatrocientos cuatro o si es un 301, si el navegador debe utilizar caché, tiempo de expiración de esta, etc.

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

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 exactamente las mismas directivas que incluiriamos en el atributo content de la etiqueta meta-robots.

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

¿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 que estas existen. Así básicamente podemos evitar los inconvenientes de colisión con otras etiquetas en código HTML que hablabamos antes. Una cabecera se interpretará antes y por 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 mandarse en cabeceras y ahí si que habría colisión.

De exactamente la misma forma en crawl budget debería asistir 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 emplear
- Alguna herramienta on-line especializada como
- 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 inclusive en audits en profundidad muchos no se miran este dato o bien no saben mirarlo. Así que es una forma de hacer tu estrategia posicionamiento web en buscadores menos patente para la competencia.

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

Por último, las cabeceras no solamente 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 habituados a tocarlos para control de redirecciones, pero resulta que también nos sirven para enviar cabeceras y por ende para eludir la indexación.

Lo mejor de esta técnica es que podemos hacerlo por expresiones regulares sin especificar URL a URL cuales indexamos y cuales no. En la práctica esto significa que si 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 creador del conocido plugin posicionamiento web de WordPress). Mas vamos, ya has leído demasiada intro asi que vamos al grano: lo que vamos es a definir esta clase de líneas en el .htaccces de la web...

Para eso utilizamos la directiva de configuración "Header set" o bien "Header add". Estas nos dejan añadir cabeceras HTTP desde estos ficheros. Sin embargo no todos y cada uno de 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 a fin de que te diga como activarlas (si se puede, claro).
  • Si tienes el típico servidor donde tan solo está activo lo que has ido utilizando para tu página web posiblemente 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 mas no lo tienen activado.

¿Como se si lo tengo activo? Bueno, puedes revisar los módulos tu mismo o bien sencillamente 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 &#x1F61B;

Por ello os recomendaría siempre y en todo momento añadir cualquiera de estas manipulaciones de headers bajo la etiqueta " " a fin de que si el módulo no existe cuando 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 2 líneas:

* Hay que ser root o bien usar "sudo" para lanzarlo, claro.

Cómo implementarlo

Para implementarlo solo tenemos que editar los ficheros de configuración del servidor (.htaccess o bien .htconfig en dependencia de a que nivel desees actuar) y añadir las comprobaciones necesarias para poder ver si crear o bien no las cabeceras. El inconveniente viene que dependiendo de cuanto quieras hacer y dónde te dejen hacerlo el sistema para conseguirlo no es 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 fichero es el que se encarga de las configuraciones del servidor. Es un fichero 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 fácil por el hecho de que 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 página web con .htconfig:

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

O para no indexar ni continuar los links de nuestro chungui weblog cuyo contenido histórico está robado de otros blogs:

Como veis, si verdaderamente nos dejan tocar en donde toca hacer estas definiciones puede ser muy sencillo. Desgraciadamente 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í (por el hecho de que es mucho más sensible que un htaccess).

2) Con .htaccess y ficheros

En .htaccess (donde en posicionamiento web en buscadores estamos más habituados a entrar) también podemos hacer cosas, pero por degracia las directivas de y aqui no están disponibles. Así que no podemos acceder a URLs como tales, sino a los ficheros y carpetas de la web. En vez de aquí disponemos de para jugar con los nombres de ficheros y con para enviar cabeceras en directorios completos. No obstante recordemos que charlamos de archivos reales en el servidor no de URLs de la página. Esto quiere decir que por ejemplo en un WP tanto la url "/mi-bonito-post" como "/category/mis-posts" o bien "/page/15" realmente terminan todas ejecutando el fichero "/index.php" con 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 bien .pdf (aunque corregido que el suyo tiene un errorcillo y con el IfModule añadido a fin de que no pete), como veis aquí si podemos emplearlo pues se refiere a ficheros concretos.

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

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

2) Con .htaccess y entornos de modRewrite

Hasta ahora tenemos 2 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 fichero. ¿Nos falta algo verdad? Si, La capacidad de hacer esto mismo con URLs de esta clase pero en el .htaccess. Un lugar donde la directiva dedicada a leer esto no está libre...

Por suerte, en la enorme mayoría de los casos en los que tenemos este inconveniente, este sucede pues estamos usando ModRewrite en la página. Un módulo de Apache con el que indicamos estas URLs afables (y que en posicionamiento SEO empleamos muy frecuentemente para hacer las redirecciones trescientos uno). Bien, puesto que resulta que ModRewrite a la hora de definir como se leen las URLs es capaz además de crear ambientes (environments), luego estos ambientes pueden percibir headers diferentes cada uno de ellos.

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

  • Identificamos en nuesrto .htaccess donde comienzan las acciones de modRewrite
  • Debemos redactar siempre: Después del condicional de y de su configuración basica, pero ya antes de ninguna declaración que afecte a ninguna URL
  • Tres líneas distintas:
    • La primerar recoge la variable por ciento 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 ambiente para todas las URLs y ficheros que coincidan con la línea precedente.
    • La tercera línea será la declaración de cabeceras

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

    RewriteCond  por ciento THE_REQUEST "^(GET|POST) /blog/.* HTTP" RewriteRule .* - [ENV=NOINDEXBLOG:true] Header set X-Robots-Tag "noindex,follow" env=NOINDEXBLOG
  • La primerar recoge la variable por ciento 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 ambiente para todas y cada una de las URLs y archivos que coincidan con la línea precedente.
  • La tercera línea será la declaración de cabeceras

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

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

.htaccess original de wordpress:

Y pongamos que deseamos hacer que las paginaciones no se indexen, así que debemos advertir las URLs que terminan 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:

A partir de ahí, se trata solo de saber hacer las Expresiones regulares adecuadas. Por poner un ejemplo si nos ponemos a tejer fino y solo queremos desindexar las paginaciones a partir de la 5ª página y solo si estas son de la home o bien de categorias primordiales de wordpress el código sería exactamente el mismo, mas la expresión regular se complicaría:

¿No es excelente acotar todo esto de este modo? La página web debe acompañar claro, si no somos capaces de crear las expresiones regulares necesarias para detectar las páginas no vamos a poder trabajar, mas en muchas ocasiones 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 fallos al estar toda la definición en un único fichero es muy fácil de controlar.

Back to top

12) Conclusión

La cantidad de detalles a supervisar 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 reconsiderar las estrategias de muchos sites.

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

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

De momento os voy a dejar sosegados 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...

¿Te gustó este blog post? Puedes proseguir sus comentarios mediante, o realizardesde tu blog.

Back to top
Share icon

ESTOS EXCLUSIVOS INFORMES GRATUITO REVELAN

7 SECRETOS DE EXPERTOS SEO QUE TE LLEVÁN AL 1#
7 SECRETOS DE EXPERTOS SEO QUE TE LLEVÁN AL 1# EN GOOGLE PARA GANAR 10.000s DE TRÁFICO DE CALIDAD GRATUITO - EN SÓLO 2 MESES
 

Los 7 pasos más poderosos para disparar tu ranking orgánico para ALCANZAR Y MANTENER un impresionante tráfico orgánico es TUYO.

Consigue gratis lo que el 1% de los expertos en SEO venden por miles de euros... y el otro 99% ni siquiera sabe que existe.


OBTEN MI INFORME GRATUITO
5 errores que debes evitar en tu sitio web de Drupal
Ebook - 5 errores que debes evitar en tu sitio web de Drupal (¡podrían costarte miles de euros!)
 

Este Ebook cubre 5 terribles errores que probablemente estés cometiendo ahora mismo con tu sitio web de Drupal.

¡Nº3 TE SORPRENDERÁ! Esta lectura de 10 minutos te ahorrará miles de euros.



OBTEN MI INFORME GRATUITO