10 cosas que deberías saber sobre las etiquetas meta-robots, noindex, nofollow y también indexación
Do not speak Spanish?.
Y después deltocaba charlar un poco sobre el recurso hermano de este: la etiqueta meta-robots. Otro básico del posicionamiento SEO del que todo el mundo sabe cosas mas que como siempre tiene tal cantidad de pecularidades que es fácil que a muchos se nos escapen algunas. Seguramente incluso en este artículo me falte algún detalle por comentar, mas aún así creo que hay temas que la mayoría de SEOs ignoran o bien como míminimo conocieron hace ya tiempo mas ya no lo aplican.
El posicionamiento web 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 empleamos. Por ese motivo tenia ya este blog post medio escrito en borradores del weblog, para poder acudir a estos detalles dentro de un tiempo y emplearlos 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 exactamente la misma.
- Solo estar declarado una vez por página
- Se trata de una etiqueta "meta" que se compone de dos 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:
<meta name="robots" content="Directrices para robots"/>
No tiene más misterio, la única dificultad es que cuando hacemos SEO en un site a un nivel alto acostumbramos a delimitar exactamente que valores queremos en todos y cada página del site con lo que debemos preocuparnos de que nuestro Content Management System o bien la programación de nuestro site nos deje manipularla a nuestro criterio.
Dicho esto, veremos detalles sobre que podemos hacer y cómo se interpreta esta etiqueta.
1. Existen más directivas a declarar de las que acostumbras a utilizar (pero se emplean mucho menos)
Las directrices posibles a señalar 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 toda circunstancia como positivas.
Las directrices pueden estar en minusculas o bien 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 empleamos espacios entre ellas o no, aunque la costumbre es no emplearlos, Google entenderá con perfección tanto "noindex,nofollow" como "noindex, nofollow" o "noindex , nofollow".
Dentro de estas indicaciones las de index y follow son las más conocidas pero no son las únicas y podemos hallar 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 deseamos que esta página aparezca en los resultados de búsqueda. Su acción es bastante rápida en pocos días vamos a ver 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 utilizada. Con ella le afirmamos que no rastree los enlaces de esta página. No nos engañemos Google los va a rastrear mas no les traspasará autoridad (o bien no mucha al menos). Es el equivalente a marcar absolutamente todos los links 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 queremos que la caché de esta página se accesible al público la vamos a marcar como noarchive. Esto puede ser útil para contenidos o noticias altamente sensibles, cosas a esconder o contenidos demasiado dinámicos para que esta caché sea útil. Generalmente la caché nos ayuda a ver que tiene Google sobre nuestras páginas asi que no acostumbramos a desactivar su publicación.
translate/notranslate:Con ellas podemos apuntar 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":La más extraña de todas y cada una. Esta nos deja señalar que deseamos desindexar el artículo a partir de una fecha determinada. Útil cuando nuestro contenido deja de ser actual o bien 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 uso y si no es mejor pasar las noticias a "noindex" de forma directa al pasar esa fecha: Yo os diría que el beneficio es que si lo indicáis así, Google ya está prevenido, mas de todas y cada una 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 redactar un meta... La hemos usado 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 usa 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 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 utilizarlas a día de el día de hoy si bien sigan en las documentaciones.
Como veis hay más opciones de las que generalmente manejamos. Y es bueno conocerlas todas y cada una, si bien 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 prosigan los enlaces de esta página. Deseamos recortar por lo sano en esta página
index,nofollow:Queremos indexar esta página mas no traspasar autoridad a sus links. Esto solía utilizarse antaño en páginas de agradecimientos y de intercambios de enlaces (al menos los posicionamiento web en buscadores timadores)... que tiempos. A día de el día de hoy es difícil que quieras indexar una página de la cual no te interesa ninguno de sus enlaces.
noindex,follow:El en el caso de que no te interese indexar esta página pero 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 hoy para sistemas de páginas y reparar defectos de la indexación
2. Es probable que la etiqueta meta robots (o por lo menos parte de sus directrices) no sea precisa 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 si bien 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 van a entender que pueden indexarlo todo, proseguir cualquier link y poner la información que deseen de tu página web, por consiguiente las directivas positivas como "index,follow" no aportan nada a la lectura que hacen los robots site. Tampoco es que incordien a la indexación puesto que no estará mal si las incluimos mas de ahí a decidir que un site no esta optimado por no contar con de ellas hay un largo trecho. En posicionamiento web en buscadores siempre y en todo momento combatimos contra las ventanas de trabajo que nos aportan los técnicos, que siempre y en toda circunstancia son menos de las que nos gustarían. Generar tareas que no aportan nada (mierdiptimizaciones, las llamamos nosotros) no es 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 las etiquetas positivas de la página en realidad optimamos más nuestro posicionamiento SEO que incluyéndolas. Y siguiendo con esta lectura el típico "noindex,follow" tampoco tiene sentido. "follow" ya es una indicación que debería continuar el buscador con lo que lo suyo sería solo apuntarle "noindex" y el ya entenderá que si que puede continuar los enlaces. Sin embargo por claridad justo esta combinación si suele emplearse si bien sea para dejarnos a nosotros mismos claro lo que procuramos al apuntarla. La realidad es que tampoco ganamos mucho quitándo estas indicaciones aunque no nos aporten nada, así 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 indicación está dirigida 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 otro modo no podrían leer el noindex.
En la práctica esto solo nos afecta en un punto: la. Para resumir diríamos que Google nos destina un tiempo de proceso de nuestras páginas, a mayor crawl budget más capaz es de hallar todos nuestros contenidos. Bien puesto que al añadir páginas con noindex estamos produciendo 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 acostumbra a ser mucha mejor opción.
4. Mas noindex si afecta al rastreo: Lo reduce.
Venga, y voy a contradecirme solo ahora. Puesto que es que en realidad el noindex si que afecta al rastreo y por consiguiente al crawl budget, cuando analizas los logs, acostumbras a ver que las páginas con noindex pierden rastreo. Si las equiparas con páginas similares del site en autoridad interna los robots acaban pasando menos por ellas que por el resto.
Esto es normal si lo piensas, ¿porque pasarán una y otra vez a leer contenido que no pueden usar? Lo normal es que se rastreen menos, si bien 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 reduce con las indicaciones de indexación de esta forma:
index,follow:se trastrea todo de la manera normal
noindex,follow:se rastrea menos, mas si la página tiene autoridad aun puede visitarla más de una vez al día. Al fin y al cabo si le decimos que siga los links debe rastrearla. Pero si que lo hace menos
noindex,nofollow:se rastrea bastante menos, pero proseguimos recibiendo hits en ellas
rel="nofollow" en todos los enlaces que le llegan:Aunque no estoy 100 por cien seguro, mi sensación es que se rastrea aun algo menos
bloqueo por robots.txt:Se anula en una gran parte el rastreo, seguimos encontrando hits (a pesar de que los hemos prohibido) a las páginas por parte del los robots mas 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 a fin de 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 tanto 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 múltiples opciones las que no acabo de ver...
index,nofollow:
Estas páginas huelen muy mal. ¿Quieres posicionar mas 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 utiliza a diestro y siniestro pero... ¿has pensado si verdaderamente es lo que quieres? Mucha gente solo piensa en que no desea 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 pues sea lo que verdaderamente deseas. Deberiamos meditar que harán las arañas con cada página que encuetren y te encontrarás con que muchas veces no tiene snetido el nofollow.
- ¿Quieres eludir 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, mas que pasa con sus links. La araña va a pasar por ahí de todas y cada una maneras, ¿seguro que no quieres que prosiga 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!
- ¿Quieres frenar a la araña a estructuras completas y no puedes con el robots?
En este caso, si, si por poner 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 absolutamente 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 enlaces de ese catalogo. Ahí trabajaría sobretodo los rel="nofollow" de los links que van ahí pero además en el propio catalogo que tendrá muchos enlaces a todas 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, pero que pasa con sus enlaces. La araña pasará por ahí de todas formas, ¿seguro que no deseas que prosiga los enlaces y rascar un poco de autoridad de esas páginas que no deseas 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 enlace cuenta!
En este caso, si, si por poner un ejemplo tienes un catalogo que no puedes indexar (pues es basura, pues esta parseado, porque no lo quieres y punto) y absolutamente nadie te deja bloquearlo al completo por Robots.txt si que es verdad que lo único que te queda es suprimir la autoridad a los links de ese catalogo. Ahí yo trabajaría sobretodo los rel="nofollow" de los enlaces que van ahí pero además en el propio catalogo que tendrá muchos enlaces a todas y cada una estas zonas un nofollow será más efectivo.
6. Existe la posibilidad de declarar precisamente 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, mas eso ya es suficiente para hacer cosas.
La lista de robots separadamente está aqui:
En ocasiones no deseamos tratar igual a todos y cada uno de los robots, esto sucede especialmente cuando nos encontramos con temas posicionamiento en buscadores vs Propaganda de pago o cuando lidiamos con los diferentes buscadores especializados de Google (que tienen cada uno de ellos su propia araña). En muchos sites creamos paginas que no queremos que Google indexe pues hablando en términos SEO son basura, pero son páginas que con determinadas campañas pueden transformar muy bien por lo que si deseamos que otros robots puedan acceder a ellas.
Asi pues podemos crear más de una etiqueta. name="robots" siempre se ocupará del caso especial, mas entonces podemos añadir etiquetas más detallas para los diferentes 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 bien publicidad.
O por poner 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 mas 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étera 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 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 señalas 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 carece de 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 logras que se comporte de forma caótica y no puedas saber con certeza si va a aplicar el noindex o no de la página. Me gustapero no por el hecho de que este de acuerdo con sus conclusiones ( siempre y en todo momento 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 más bien porque prueba el caos que representa unir estas directrices. Puestos a no saber que hará 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 varias páginas son parte de un mismo listado y así evitar que las entienda como duplicadas... en teoría a ojos de Google sumamos todas con sus enlaces en un gran listado (en la práctica tan así no es). Pero si esto es lo que procuramos ¿qué sentido debe desindexemos una 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 afirmas 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.
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 carnes recientemente y no ha sido hasta queme ha sobre aviso 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 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 para que no se entendiese como parte del HTML. Esto provocó 2 cosas:
- Que en artículo no se viera 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 blog ya que también aparecía esa etiqueta ahí...
- Y por exactamente el mismo motivo, me desindexó también la categoría de indexación del blog
¿Divertido verdad? Así que si escribiréis sobre posicionamiento web 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 advierten 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 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 menos, si todo carga en el primer print de página (sin precisar clic o acciones del usuario) acaba leyéndolo. Esto ha abierto gran cantidad de posibles parches JS o bien de forma más controlada via Google Tag Mánager (una herramienta de gestión de tags de analítica y marketing).
Así puesto que para cualquiera que sepa programar javascript resulta parcialmente fácil 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 Mánager podemos crear una etiqueta adaptada con el próximo 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 mandar las directrices de meta-robots desde las cabeceras de la página
Esto ya lo adelanté en otro artículo mas en realidad tocaba mencionarlo en este. Además comentare algunas 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 disponemos de una cabecera que podemos usar a nivel de servidor para mandarlas.
Todo esto está detallado en la. Esta nos especifica el empleo de la cabecera http "x-robots-tag". Las cabeceras son información que el servidor envía antes de hacernos llegar la página 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 trescientos uno, si el navegador debe usar caché, tiempo de expiración de esta, etc.
Cualquier lenguaje de programación web es capaz de administrar las cabeceras antes de mandar la página. Un ejemplo serían estas (las de la home de mi weblog):
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.
Por ejemplo hacer este añadido en PHP sería tan sencillo como añadir esta línea ya antes de la primera impresión de HTML de la página:
¿Por qué mola mucho más meter las indicaciones 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 eludir los inconvenientes de colisión con otras etiquetas HTML que hablabamos ya antes. Una cabecera se interpretará antes y por consiguiente un noindex en una cabecera tiene muchas más garantías de no indexar. Cuidado aquí pues otras indicaciones como los canonicals tambien pueden mandarse en cabeceras y ahí si que habría colisión.
De exactamente 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 difícil mirar headers al hacerlo:
- podeis usar
- Alguna herramienta en línea especializada como
- Y los rastreadores más populares (screamingfrog, sitebulb, deepcrawl, ...) incluyen este dato
Pero la verdad 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 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, por lo que los desarrolladores no tienen por el hecho de que tocar plantillas para ir añadidendo este tag a la página web. Muchas veces 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 Content Management System, Modelo de datos, Lógica de programación y luego maqueta. Si les ahorramos aunque sea uno o bien dos de estos pasos mejor que mejor.
Por último, las cabeceras no solo se pueden controlar desde programación. anunciar en google ads ón del servidor tambien podemos definirlas. Aquí los ficheros htaccess de apache (o bien 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 precisar URL a URL cuales indexamos y cuales no. En la práctica esto quiere decir que si que tenemos un lugar 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 creador del conocido complemento posicionamiento en buscadores de Wordpress). Mas vamos, ya has leído demasiada intro así que vamos al grano: lo que vamos es a acotar este género de líneas en el .htaccces de la web...
Para eso empleamos la directiva de configuración "Header set" o bien "Header add". Estas nos dejan añadir cabeceras HTTP desde estos archivos. No obstante no todos los servidores dejan hacer esto por defecto.
- Si tienes un servidor compartido probablemente si que estén activas y de no estarlo tendrás que contactar con tu proveedor para que te diga como activarlas (si se puede, claro).
- Si tienes el típico servidor donde solo está activo lo que has ido usando para tu web es posible que a la primera las cosas no funcionen. especialistas en woocommerce de linux vienen ya con el módulo de envío de headers activo mas justo Ubuntu y Debian (las dos más utilizadas) lo traen pero no lo tienen activado.
¿Como se si lo tengo activo? Bueno, puedes comprobar los módulos tu mismo o bien simplemente intentar activar una directiva de creación de cabeceras. Si el servidor te da un fallo quinientos "Internal Server Error", es que no están soportadas 😛
Por ello yo 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 por lo menos no hagamos fallar a toda la página 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 emplear "sudo" para lanzarlo, claro.
Cómo implementarlo
Para implementarlo solo debemos editar los ficheros de configuración del servidor (.htaccess o bien .htconfig en dependencia de a que nivel quieras actuar) y añadir las comprobaciones necesarias para ver si crear o no las cabeceras. El problema viene que en dependencia de lo que quieras hacer y dónde te dejen hacerlo el sistema para lograrlo no es el mismo.
Por lo general, toda vez que podamos o bien no estemos seguros de como marcha nuestro servidor, todas estas definiciones las englobaremos en la etiquetas "
" y "" para eludir fallos por si acaso no se nos permite crear headers.
1. Si podemos acceder al .htconfig
Este fichero es el que se hace cargo de las configuraciones del servidor. Es un archivo altamente sensible donde además se pueden entremezclar todos y cada uno de 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 utilizamos para saber si aplicamos algo o bien no a la configuración. Así que básicamente podemos hacer algo similar a cuando hacemos redirecciones con ModRewrite.
diseño pagina web rapido ,follow en paginaciones de la web con .htconfig:
Aquí os dejo otra para no indexar contacto o bien 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)
O para no indexar ni proseguir los links de nuestro chungui blog cuyo contenido histórico está robado de otros blogs:
Como veis, si realmente nos dejan tocar en donde toca hacer estas definiciones puede ser sencillísimo. 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 libres. Asi que no podemos acceder a URLs como tales, sino a los archivos y carpetas de la web. En lugar de
aquí disponemos de
para jugar con los nombres de archivos y con
para mandar cabeceras en directorios completos. Sin embargo recordemos que hablamos de ficheros reales en el servidor no de URLs de la página. Esto significa que por servirnos de un ejemplo en un Wordpress tanto la url "/mi-bonito-post" como "/category/mis-posts" o bien "/page/15" en realidad terminan todas ejecutando el fichero "/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 ficheros .doc o .pdf (aunque corregido que el suyo tiene un errorcillo y con el IfModule añadido para que no pete), como veis aquí si podemos usarlo porque 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 ambientes de modRewrite
Hasta ahora tenemos dos vías fáciles 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 distinguir URLs virtuales/amigables/sobreescritas que acaban todas en exactamente el mismo archivo. ¿Nos falta algo verdad? Si, La capacidad de hacer esto mismo con URLs de esta clase mas en el .htaccess. Un sitio donde la directiva dedicada a leer esto no está disponible...
Por suerte, en la enorme mayoría de los casos en los que tenemos este problema, este sucede porque estamos utilizando ModRewrite en la página. Un módulo de Apache con el que indicamos estas URLs amigables (y que en posicionamiento SEO empleamos en muchas ocasiones para hacer las redirecciones 301). Bien, puesto que resulta que ModRewrite en el momento de acotar como se leen las URLs es capaz además de crear entornos (environments), luego estos ambientes pueden percibir headers distintos cada uno.
¿Como hacemos esto? Pues es un tanto más complejo que antes, pero sigue siendo fácil...
- Identificamos en nuesrto .htaccess donde comienzan las acciones de modRewrite
- Debemos escribir 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 verdaderamente 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 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 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 cien 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 debemos hacer la expresión regular para detecar las URLs a las que afectar.
- La segunda línea declarará el nombre del entorno para todas y cada una de las URLs y ficheros 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 weblog las 3 líneas serían:
Veamos esto para el caso de wordpress que tiene un .htaccess sencillito...
.htaccess original de wordpress:
Y imaginemos 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 hallamos 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 ambiente "NOINDEXNOFOLLOW". Luego, declaramos los headers para este ambiente.
.htaccess con noindex en paginaciones para wordpress:
A partir de ahí, se trata solo de saber hacer las Expresiones regulares correctas. Por poner un ejemplo si nos ponemos a tejer fino y solo deseamos 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 exactamente el mismo, mas la expresión regular se complicaría:
¿No es excelente delimitar todo esto de esta forma? La web debe acompañar claro, si no somos capaces de crear las expresiones regulares necesarias para advertir las páginas no vamos a poder trabajar, pero muy frecuentemente si que podemos hacerlo y una vez conocido el sistema no es tan difícil de incorporar. Somos poquísimo intrusivos con la programación de los sites y ante errores al estar toda la definición en un único fichero es muy fácil de supervisar.
Conclusión
La cantidad de detalles a supervisar sobre indexación es abrumadora. En un par de días hemos tocado solo los 2 recursos más básicos que existen y ya da para reconsiderar las estrategias de muchos sites.
Como todo, priorizar y escoger es esencial. No tenemos que aplicarlo todo a todos los sites e inclusive de tener que hacerse no tiene pues ser desde el primer momento. Empecemos por supervisar que no hemos cometido fallos, sigamos seleccionando bien que queremos hacer con las arañas y después ya poco a poco la vamos liando.
Al final estas cosas se notan. 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 escoger nosotros que Palabras clave verdaderamente nos importan y eso se traduce en mejora de visitas.
De instante os dejaré apacibles con estos temas... quien sabe, igual en un tiempo me lance a por los sitemaps, canonicals (aquí hay mucha chicha), atributos rel... también tocaría editar los viejos artículos que tengo sobre HTML... cuanto trabajo por delante...
¿Te gustó este artículo? Puedes seguir sus comentarios a través de, o realizardesde tu weblog.
