Robots.txt: errors que bloquegen Googlebot - Ighenatt Blog

El robots.txt més perillós no és el que té errors obvis. És el que sembla correcte, que ningú ha revisat en mesos, i que està bloquejant silenciosament pàgines clau que Googlebot mai arriba a veure. Segons dades internes d’auditories de Screaming Frog, aproximadament el 30% dels llocs que analitzen tenen alguna directiva problemàtica al seu robots.txt que afecta pàgines que haurien d’estar indexades.

El fitxer robots.txt és allà des dels primers dies del SEO. Algú el va generar, en algun moment, i després ningú el va tornar a tocar. Aquí és exactament el problema.

A diferència de la configuració d’un sitemap o una etiqueta canonical, el robots.txt opera en una capa prèvia a qualsevol altra senyal SEO: si bloquegeu una URL aquí, Googlebot no arriba a llegir ni el títol, ni les etiquetes meta, ni el schema markup. Tot el treball d’optimització on-page queda irrellevant abans de començar.

Què és el robots.txt i com l’interpreta Googlebot realment

El robots.txt és un fitxer de text pla que viu a l’arrel del vostre domini (https://elvostredomini.com/robots.txt). La seva funció és comunicar als robots de cerca quines parts del lloc poden i no poden rastrejar. L’especificació és senzilla en teoria. A la pràctica, hi ha prou matisos d’interpretació per tal que els errors siguin freqüents i costosos.

El primer que cal entendre: el robots.txt no és un mecanisme de seguretat. Google el segueix per convenció, no per obligació. Un robot maliciós ignorarà el fitxer sense conseqüències tècniques. El robots.txt només funciona per a bots que respecten l’especificació, principalment els motors de cerca.

El segon punt: Google emmagatzema en memòria cau el robots.txt. No el llegeix en cada visita. El descarrega periòdicament (cada pocs dies en llocs actius) i usa aquella versió en memòria cau per a totes les seves decisions de rastreig fins a la propera actualització. Un canvi urgent al robots.txt pot trigar 24-48 hores a reflectir-se en el comportament real de Googlebot.

L’estructura bàsica d’una directiva és simple:

User-agent: [nom del bot]
Disallow: [ruta bloquejada]
Allow: [ruta permesa]

Google accepta * com a comodí universal per a User-agent (tots els robots) i com a comodí en rutes. També accepta $ per indicar el final d’una URL. El que Google no accepta són alguns patrons avançats d’expressions regulars que altres bots sí interpreten — un punt de confusió freqüent quan es copien configuracions d’altres fonts.

John Mueller, Analista Sènior de Cerca a Google, ha reiterat en múltiples sessions de preguntes i respostes que el robots.txt no garanteix privacitat i que bloquejar una URL aquí no l’elimina de l’índex. Si la URL ja estava indexada quan s’afegeix la directiva Disallow, Google pot mantenir-la als resultats durant mesos perquè no pot visitar-la per verificar si s’ha de desindexar.

Error #1 — Disallow: / (bloquejar tot el lloc per accident)

Aquest és l’error més greu i, sorprenentment, passa amb prou freqüència com perquè Google el mencioni específicament a la seva documentació. El resultat: Googlebot no pot rastrejar cap pàgina del lloc.

# INCORRECTE — bloqueja tot el lloc a tots els bots
User-agent: *
Disallow: /

La causa més comuna no és malícia ni ignorància: és copiar el robots.txt de l’entorn de preproducció al de producció. Els entorns de desenvolupament i preproducció solen bloquejar tot el rastreig per evitar que apareguin als resultats de cerca. Quan es fa el desplegament a producció i algú copia el fitxer de configuració complet, el bloqueig viatja amb ell.

La versió correcta per a un lloc que vol permetre el rastreig general:

# CORRECTE — permet el rastreig de tot el lloc
User-agent: *
Disallow:

# Si hi ha seccions específiques a bloquejar:
User-agent: *
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /cistella/

Una línia Disallow: buida és la manera estàndard de dir-li a Googlebot que pot rastrejar qualsevol ruta. No cal escriure Allow: / (tot i que també funciona).

El senyal d’alerta més clar d’aquest error: Google Search Console comença a mostrar una caiguda dràstica en les pàgines rastrejades, i l’informe de Cobertura mostra desenes o centenars de pàgines amb l’estat “Exclosa: bloquejada per robots.txt”. Si veieu aquesta combinació, reviseu el robots.txt immediatament.

Error #2 — Bloquejar recursos CSS i JavaScript crítics per al renderitzat

Aquest error no bloqueja pàgines completes. Bloqueja els recursos que Googlebot necessita per renderitzar correctament aquelles pàgines. L’efecte és més subtil però igualment perjudicial.

Quan Googlebot visita una URL, no es limita a llegir l’HTML. Descarrega els fitxers CSS i JavaScript referenciats per renderitzar la pàgina tal com la veuria un usuari real. Si el robots.txt bloqueja aquells recursos, Googlebot veu una versió degradada del contingut — i aquella versió degradada és la que avalua per al posicionament.

Els patrons de bloqueig que causen aquest problema amb més freqüència:

# INCORRECTE — bloqueja recursos necessaris per al renderitzat
User-agent: *
Disallow: /wp-content/uploads/
Disallow: /wp-content/plugins/
Disallow: /assets/
Disallow: /static/
Disallow: /css/
Disallow: /js/

La intenció darrere d’aquests bloquejos sol ser raonable: evitar que Google indexi fitxers individuals que no aporten valor com a pàgines. El problema és que “no indexar” i “no rastrejar” són coses diferents. Google no indexarà un fitxer /assets/main.css com si fos una pàgina de resultats, però sí que necessita descarregar-lo per renderitzar qualsevol pàgina que l’usi.

# CORRECTE — permet el rastreig de recursos, bloqueja només el necessari
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /cistella/
Disallow: /checkout/
Disallow: /el-meu-compte/

# Els recursos CSS, JS i imatges NO es bloquegen

Google Search Central documenta explícitament aquesta recomanació: permetre l’accés a tots els fitxers que el navegador necessita per renderitzar la pàgina és fonamental perquè Googlebot pugui avaluar correctament el contingut.

Per verificar si Googlebot pot accedir als recursos d’una pàgina, useu l’eina d’Inspecció d’URLs a Google Search Console. L’informe mostra si hi va haver recursos bloquejats durant el darrer rastreig i quins van ser. Si apareix la secció “Recursos de pàgina bloquejats”, teniu aquest problema.

Error #3 — Sintaxi incorrecta: sensibilitat a majúscules i espais que costen indexació

El robots.txt és més estricte del que sembla en la seva sintaxi. Dos errors específics de format causen problemes difícils de detectar sense eines:

Sensibilitat a majúscules en rutes: Les rutes de les directives Disallow i Allow són sensibles a majúscules segons l’especificació de Google. Això vol dir que:

# INCORRECTE si la vostra URL real és /admin/ (minúscules)
User-agent: *
Disallow: /Admin/

# CORRECTE — la capitalització ha de coincidir exactament amb la URL real
User-agent: *
Disallow: /admin/

Si el vostre lloc té URLs amb majúscules (quelcom que caldria evitar, però existeix en molts CMS), heu de bloquejar les versions exactes. Un bloqueig de /Admin/ no afecta /admin/ ni /ADMIN/.

Espais a la directiva User-agent: L’especificació requereix que no hi hagi espai entre User-agent: i el valor. Un fitxer generat incorrectament pot tenir:

# INCORRECTE — espai després dels dos punts (en alguns analitzadors causa problemes)
User-agent : *
Disallow: /admin/

# CORRECTE
User-agent: *
Disallow: /admin/

Directives sense User-agent: Qualsevol directiva que no estigui associada a un bloc User-agent és ignorada. Si algú afegeix una directiva Disallow fora d’un bloc, no té cap efecte però tampoc genera un error visible:

# INCORRECTE — la directiva Disallow sense User-agent previ és ignorada
Disallow: /area-privada/

User-agent: *
Disallow: /admin/

L’ordre importa per a l’agrupament: Google agrupa les directives per bloc User-agent. Si teniu dos blocs separats per al mateix User-agent, Google els processa de manera independent. El resultat pot no ser el que espereu:

# POTENCIALMENT PROBLEMÀTIC — dos blocs separats per al mateix user-agent
User-agent: *
Disallow: /admin/

User-agent: *
Disallow: /login/
# Google pot aplicar només un dels dos blocs

La forma correcta és agrupar totes les directives del mateix User-agent en un únic bloc:

# CORRECTE — un sol bloc per User-agent
User-agent: *
Disallow: /admin/
Disallow: /login/
Disallow: /cistella/

Error #4 — Comodí mal aplicat que bloqueja pàgines que voleu indexar

Els comodins (* i $) són potents però requereixen precisió. Un patró mal escrit pot bloquejar desenes o centenars de URLs que volíeu mantenir accessibles per a Googlebot.

El comodí * en una ruta coincideix amb qualsevol seqüència de caràcters en aquella posició. El problema sorgeix quan el patró és massa genèric:

# INCORRECTE — bloqueja TOTES les URLs que continguin "?", incloses pàgines de producte vàlides
User-agent: *
Disallow: /*?

# Això bloqueja:
# /producte/camisa-blava?color=blau
# /blog/article?utm_source=newsletter
# /serveis?tab=preus   ← pàgina important que volíeu indexar

Si l’objectiu és bloquejar pàgines de filtres dinàmics però permetre les URLs base de producte, la directiva ha de ser més específica:

# MILLOR — bloqueja només paràmetres de filtre específics
User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter_color=
Disallow: /*?paged=

El comodí $ indica el final de la URL. Útil per bloquejar fitxers amb extensions específiques sense bloquejar rutes que comencin igual:

# CORRECTE — bloqueja fitxers .pdf però no la secció /documents/
User-agent: *
Disallow: /*.pdf$

Sense el $, Disallow: /*.pdf podria bloquejar també una URL hipotètica com /documents/guies-pdf/. Amb el $, només es bloquegen URLs que acaben exactament en .pdf.

Un error especialment costós en comerç electrònic: bloquejar pàgines de paginació amb un patró massa ampli:

# INCORRECTE — bloqueja pàgines de categoria amb paginació (/categoria/page/2/)
User-agent: *
Disallow: /*/page/

# Si el vostre lloc té URLs com /serveis/page/2/, /blog/page/3/,
# aquestes també queden bloquejades tot i que les volíeu indexar

Abans d’afegir qualsevol directiva amb comodí, useu la Inspecció d’URLs a Google Search Console per provar el patró contra URLs reals del vostre lloc. L’eina mostra exactament quines URLs queden bloquejades i quines segueixen accessibles.

Error #5 — Conflicte entre robots.txt i meta robots: qui guanya?

Aquest és l’error conceptual més comú: assumir que el robots.txt i l’etiqueta meta robots funcionen de la mateixa manera o que es complementen de manera intuïtiva. La realitat és més complexa i pot produir resultats inesperats.

Regla fonamental: si una URL està bloquejada al robots.txt, Google no pot rastrear-la. Si no pot rastrear-la, no pot llegir les etiquetes meta que conté. Això inclou l’etiqueta <meta name="robots" content="noindex">.

L’escenari més problemàtic:

# Al robots.txt:
User-agent: *
Disallow: /landing-pages/

# A /landing-pages/oferta-especial/:
<meta name="robots" content="noindex, follow">

L’objectiu aparent és desindexar la landing page. El resultat real: Google no pot accedir a la pàgina per llegir el noindex, de manera que pot mantenir-la a l’índex indefinidament si tenia enllaços entrants que l’havien indexada prèviament.

La regla de precedència és la contrària del que molts esperen:

• Per impedir el rastreig: useu robots.txt Disallow. El noindex a la pàgina és irrellevant si Google no pot rastrejar la URL.
• Per impedir la indexació d’una pàgina rastrejable: useu <meta name="robots" content="noindex"> (o la capçalera HTTP X-Robots-Tag: noindex). El robots.txt ha de permetre l’accés perquè Google pugui llegir aquesta directiva.
• Per eliminar de l’índex una pàgina que ja estava indexada: traieu el bloqueig del robots.txt, afegiu noindex a la pàgina, i espereu que Google la rastregui i processi la directiva.

Gary Illyes de Google va resumir aquest conflicte amb claredat en una conferència de Google Search Central: “Una pàgina bloquejada per robots.txt no és el mateix que una pàgina amb noindex. Si voleu assegurar-vos que alguna cosa no aparegui als resultats, no confongueu ambdós mecanismes.”

La combinació correcta depèn de l’objectiu:

Com auditar el vostre robots.txt amb Google Search Console

Google Search Console ofereix dues eines complementàries per verificar el robots.txt:

1. Informe de robots.txt (Configuració → Robots.txt): mostra el robots.txt en memòria cau que Googlebot utilitza actualment, quan es va rastrejar per última vegada i si hi va haver errors de fetch.

2. Inspecció d’URLs: permet provar una URL concreta i verificar si està bloquejada per robots.txt, quina regla s’aplica i l’estat d’indexació.

Per a una auditoria més completa del robots.txt, Screaming Frog SEO Spider té una funció específica que rastreja el lloc simulant el comportament de Googlebot i mostra quines pàgines queden fora del rastreig per les directives actuals. L’informe “Blocked by Robots.txt” a la pestanya de Resposta mostra totes les URLs afectades.

Passos per a una auditoria bàsica:

1. Obriu https://elvostredomini.com/robots.txt directament al navegador i reviseu les directives una per una.
2. A Google Search Console, useu la Inspecció d’URLs per verificar que les 10-20 pàgines més importants del vostre lloc no estan bloquejades per robots.txt.
3. Reviseu l’informe de Cobertura a Search Console i filtreu per “Exclosa: bloquejada per robots.txt” per veure si hi ha URLs que no haurien d’estar bloquejades.
4. Si useu Screaming Frog, rastregeu el lloc i reviseu l’informe “Blocked by Robots.txt”.

Un robots.txt ben configurat és un dels fonaments de la gestió del crawl budget i de la indexació correcta del lloc. Si les pàgines crítiques no arriben a Googlebot, cap altra optimització SEO té oportunitat de funcionar.

Per aprofundir en la relació entre el robots.txt, els sitemaps i l’estratègia d’indexació, la guia pràctica de Google Search Console desenvolupa com coordinar ambdós mecanismes per maximitzar la visibilitat a Google.