Redireccions 301 i 302: guia SEO per a rankings | Ighenatt

Hi ha una regla que quasi ningú compleix correctament en les migracions web: actualitzar els enllaços interns després de configurar les redireccions. El resultat són cadenes de redirecció que consumeixen crawl budget en silenci durant mesos, de vegades anys, mentre l’equip de SEO es pregunta per què les noves pàgines triguen tant a guanyar posicions. Les redireccions 301 i 302 són un dels mecanismes més bàsics del SEO tècnic, però també on els errors més costosos ocorren exactament en el moment en què més dany poden fer: durant una migració.

Un retailer europeu ho va aprendre de la manera més cara: va perdre aproximadament £3,8 milions el primer mes després d’una migració de £7,6 milions perquè el seu equip d’IT va rebutjar implementar correctament les redireccions d’URLs. El cas està documentat com a referència del que passa quan la gestió tècnica de redireccions es tracta com un detall menor.

Aquesta guia cobreix els quatre tipus de redirecció rellevants per a SEO (301, 302, 307, 308), com flueix el PageRank a través de cadascun, els errors més comuns en cadenes i bucles, els riscos específics de les redireccions JavaScript, i les eines per auditar tot plegat abans que causi un problema.

301 vs 302: la diferència que defineix la canonicitat

La diferència entre 301 i 302 no és administrativa. Defineix com Google decideix quina URL considerar la versió canònica del contingut.

301 Moved Permanently: li diu a Google que el contingut s’ha mogut de forma definitiva a la nova URL i no tornarà. Google actualitza el seu índex per usar la URL de destinació com la URL canònica. El PageRank, els enllaços entrants i l’autoritat acumulada es transfereixen a la nova ubicació.

302 Found (temporalment mogut): li diu a Google que la URL original continua sent la URL oficial, que la desviació és temporal. Google no actualitza el seu índex per usar la URL de destinació com a canònica. Manté la URL original indexada perquè, en teoria, el contingut tornarà a ella.

L’error més freqüent en la pràctica: usar 302 quan la redirecció és permanent. Una botiga que migra les seves URLs de producte de /producte-123 a /categoria/slug-producte i usa 302 en lloc de 301 envia a Google un senyal contradictori: “aquesta pàgina té una URL nova però és l’antiga la que importa”. El resultat són senyals canòniques confoses que poden dilatar mesos la consolidació del PageRank a la nova URL.

Gary Illyes, membre de l’equip de Google Search, va aclarir públicament el juliol de 2016 el que molts SEOs debatien des de feia anys: “30x redirects don’t lose PageRank anymore.” La confirmació va eliminar la creença estesa que cada salt de redirecció costava un 15% d’autoritat. Avui el flux de PageRank a través d’una redirecció correctament configurada és complet, sense pèrdua pel fet de redirigir. L’advertència és la longitud de la cadena, no el tipus de redirecció.

La diferència operativa entre 301 i 302 sí té impacte SEO real en un punt específic: la velocitat d’actualització de l’índex. Amb un 301, Google actualitza la URL indexada en el proper recrawl. Amb un 302, Google no té raó per canviar la URL indexada perquè l’original és la “oficial”. Si el teu objectiu és que la nova URL aparegui als resultats de cerca, només el 301 aconsegueix aquest resultat.

307 i 308: quan importa el mètode HTTP

Els codis 307 i 308 són tècnicament més precisos que 302 i 301 respectivament, però la seva rellevància pràctica per a la majoria de pàgines és limitada.

John Mueller de Google ho va resumir directament: “It doesn’t matter. Use the technically correct redirect type. It can also be a 307 or 308 redirect.”

La diferència tècnica rau en la preservació del mètode HTTP:

• 301 i 302: permeten que el navegador canviï el mètode de la petició de POST a GET durant la redirecció. És el comportament històric, implementat per compatibilitat amb navegadors antics.
• 307 i 308: obliguen a preservar el mètode HTTP original. Si la petició original va ser POST, la redirecció també serà POST.

Per a pàgines web estàndard (que reben peticions GET), aquesta diferència no existeix en la pràctica. Importa en tres escenaris específics:

1. Formularis de múltiples passos: si un formulari POST redirigeix a una altra URL durant el procés, usar 308 (permanent) o 307 (temporal) assegura que les dades del formulari no es perdin en canviar a GET.
2. APIs REST: els endpoints d’API que processen PUT, POST o DELETE necessiten preservar el mètode en redirigir.
3. Fluxos de checkout en e-commerce: qualsevol procés que transmeti dades en el body de la petició HTTP.

Per a redireccions de contingut editorial, entrades de blog, pàgines de serveis o URLs de landing page, el parell 301/302 és correcte i suficient. La decisió d’usar 307/308 només s’ha de prendre quan el mètode HTTP del client importa per al funcionament de la destinació.

Com flueix el PageRank a través de redireccions

El PageRank no és una puntuació que “viatja” d’una URL a una altra de forma instantània. És el resultat del graf d’enllaços que Google calcula de forma periòdica. Una redirecció modifica aquest graf: li diu a Google que els enllaços que apunten a URL-A ara s’han de comptabilitzar per a URL-B.

Amb la confirmació de Gary Illyes el 2016, el model actual és: el flux de PageRank a través de redireccions 30x és complet. Un enllaç extern que apunta a una URL amb 301 transfereix el seu valor d’autoritat íntegrament a la URL de destinació. No hi ha descompte pel fet d’usar una redirecció en lloc de mantenir la URL original.

El que sí genera pèrdua de PageRank són dos patrons específics:

Cadenes llargues: cada salt addicional en una cadena de redirecció introdueix latència i, quan la cadena supera 5 salts, Google pot deixar de seguir-la en aquella sessió de rastreig. El resultat és que els enllaços que apunten al principi d’una cadena molt llarga poden no arribar a transferir el seu PageRank fins que la cadena es consolida. John Mueller recomana no superar 2 salts en cap cadena de redirecció activa.

Bucles de redirecció: quan URL-A redirigeix a URL-B i URL-B redirigeix de tornada a URL-A, o en variants més complexes amb 3 o més URLs. Els bucles fan que Googlebot abandoni la seqüència, la URL mai s’indexa, i qualsevol PageRank que arribés a aquelles URLs queda atrapat al bucle. Són errors que Search Console reporta a l’informe de Cobertura.

L’escenari de major impacte ocorre en migracions web: quan un lloc canvia centenars o milers d’URLs simultàniament i algunes redireccions apunten a altres URLs que al seu torn també estan redirigint (perquè hi va haver una migració anterior). La cadena resultant pot ser URL antiga 2020 → URL antiga 2023 → URL nova 2026, tres salts acumulats que haurien de resoldre’s en un.

Cadenes de redirecció: detecció i correcció

Una cadena de redirecció existeix quan la URL-A no apunta directament a la URL final, sinó a una URL intermèdia que al seu torn redirigeix. En llocs amb historial de migracions o reestructuracions de contingut, aquestes cadenes s’acumulen de forma silenciosa.

L’estudi d’Ahrefs sobre més d’un milió de dominis va identificar les redireccions 3XX com el problema tècnic més freqüent, present en el 95,2% dels dominis analitzats. No totes són cadenes problemàtiques, però el percentatge il·lustra quants llocs tenen redireccions sense auditar.

Per què són perjudicials:

• Crawl budget: cada salt extra és una petició HTTP addicional que Googlebot ha de fer. En llocs grans, les cadenes de redirecció poden consumir una fracció significativa del crawl budget que hauria d’usar-se per descobrir contingut nou.
• Latència de càrrega: cada salt afegeix temps de resposta del servidor. Una cadena de 3 salts pot sumar 300-500ms addicionals de temps de càrrega, amb impacte directe en Core Web Vitals i senyals d’experiència d’usuari.
• Senyals canòniques debilitades: quan hi ha múltiples URLs a la cadena, Google ha de decidir quina URL és la canònica real. Encara que generalment ho resol correctament, el procés és més lent i pot generar errors d’indexació temporals.

Com detectar cadenes amb Screaming Frog:

Screaming Frog SEO Spider és l’eina de referència per a auditories de redirecció. El procés és directe:

1. Rastrejar el lloc amb l’opció “Always Follow Redirects” activada
2. Al menú principal: Reports → Redirect Chains
3. L’informe “Redirect Chains” mostra totes les URLs amb 2 o més salts a la cadena
4. L’informe “All Redirects” llista cada redirecció individual amb el seu codi, URL d’origen i URL de destinació

La correcció de cada cadena detectada segueix el mateix principi: actualitzar la redirecció d’origen perquè apunti directament a la URL final. Si URL-A → URL-B → URL-C, canviar URL-A perquè apunti directament a URL-C. Mai és suficient eliminar el salt intermedi sense verificar que la destinació final és una URL amb 200 OK.

On es generen les cadenes sense que ningú s’hi adoni: el cas més comú és la coexistència de regles de redirecció en capes diferents. Les regles en .htaccess o la configuració del servidor web s’executen primer, però si el lloc també corre darrere d’un CDN com Cloudflare, el CDN pot tenir les seves pròpies regles de redirecció que s’executen abans d’arribar al servidor d’origen. El resultat són cadenes que no són visibles en el codi del servidor perquè una part ocorre a la capa del CDN.

Redireccions JavaScript: els riscos que la majoria ignora

Les redireccions implementades amb JavaScript (via window.location.href, window.location.replace() o <meta http-equiv="refresh">) són el pitjor escenari per a SEO, i la documentació oficial de Google és explícita al respecte.

Google Search Central afirma en la seva documentació: “Google strongly prefers server-side redirects, since they can be processed immediately after crawling the initial URL.” La recomanació per a redirects JavaScript és directa: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.”

El problema tècnic és el procés de rendering de Googlebot. Quan Google rastreja una URL amb un redirect de servidor (301, 302), obté el codi HTTP i la capçalera Location en la mateixa resposta HTTP. El procés és immediat. Quan la URL usa un redirect JavaScript, Googlebot ha de:

1. Descarregar l’HTML de la pàgina
2. Posar en cua la URL per al procés de rendering (JavaScript)
3. Executar el JavaScript en el renderitzador
4. Detectar el redirect
5. Seguir la nova URL

Aquest procés de rendering ocorre en una cua diferent del rastreig. Googlebot processa aproximadament el 95% dels redirects JavaScript correctament, però el temps entre el rastreig inicial i la resolució final del redirect pot ser de dies o setmanes. Durant aquest temps, la URL original pot quedar indexada o, si ja estava indexada, romandre a l’índex amb contingut desactualitzat.

El risc augmenta quan el rendering falla. Pot fallar per errors de JavaScript no relacionats amb la redirecció, per límits de temps en l’execució del renderitzador, o per recursos bloquejats per robots.txt que són necessaris per executar l’script de redirecció. En aquests casos, Google mai detecta la redirecció.

Els redirects <meta http-equiv="refresh"> són un cas intermedi: no requereixen JavaScript però tampoc són senyals HTTP directes. Google els segueix, però amb menys velocitat i fiabilitat que els redirects de servidor.

Situacions on els redirects JavaScript són inevitables: aplicacions d’una sola pàgina (SPA) on tota la navegació ocorre en JavaScript, sistemes de gestió de contingut headless on la capa de presentació no controla les capçaleres HTTP, o plataformes de tercers on no hi ha accés al servidor.

En aquests contextos, la pràctica recomanada és usar server-side rendering (SSR) o static site generation per a les pàgines crítiques de SEO, de forma que els redirects es gestionin a nivell de servidor per a aquelles URLs específiques.

.htaccess, server-side i CDN: quina capa implementa el redirect

L’elecció d’on implementar una redirecció determina la seva fiabilitat, velocitat i capacitat de manteniment. Hi ha tres capes principals:

Apache .htaccess: el mètode més comú en allotjaments compartits i servidors Apache. Les regles s’escriuen al fitxer .htaccess a l’arrel del lloc i es processen en cada petició HTTP. L’avantatge és la flexibilitat: permet regles complexes amb expressions regulars, redireccions condicionals per user-agent, i suport per a diferents tipus de redirect. El desavantatge és el rendiment: Apache llegeix el fitxer .htaccess en cada petició, afegint latència en llocs amb milers de regles.

Configuració de servidor (nginx.conf o Apache VirtualHost): l’opció més eficient per a llocs de producció. Les regles es carreguen en memòria a l’inici del servidor i no requereixen accés a disc en cada petició. Per a nginx, la directiva return 301 és la recomanada.

CDN (Cloudflare, Fastly, Akamai): els CDNs moderns permeten configurar regles de redirecció a la capa edge, abans que la petició arribi al servidor d’origen. Això redueix la latència al màxim perquè la redirecció es serveix des del node CDN més proper a l’usuari. El desavantatge és que crea una capa addicional de gestió: si el CDN té una regla de redirecció i el servidor d’origen també, poden crear cadenes que només són visibles monitoritzant el tràfic a la capa CDN.

La regla pràctica per triar la capa correcta: per a redireccions crítiques de SEO (migracions d’URLs, canvis de domini), implementar a la configuració del servidor (no en .htaccess) per a màxima fiabilitat. Per a redireccions de campanya o temporals, el CDN permet activar-les i desactivar-les sense desplegaments de codi.

Errors comuns en migracions web

Les migracions web concentren el major risc d’errors de redirecció perquè molts canvis d’URL ocorren simultàniament. Aquests són els cinc errors més freqüents:

1. Mapeig incomplet d’URLs: redirigir només les pàgines del sitemap actual i oblidar URLs que han generat enllaços externs històrics, pàgines indexades però no enllaçades internament, i variants d’URL amb paràmetres UTM o de sessió que apareixen als logs del servidor.

2. Redireccions a la pàgina d’inici com a fallback: quan no hi ha una URL equivalent clara al nou lloc, redirigir a la pàgina d’inici sembla una solució raonable. No ho és. Google tracta les redireccions genèriques a la pàgina d’inici com a senyals que el contingut ja no existeix, i les interpreta com un 404 suau (soft 404). El PageRank de la URL original no es transfereix.

3. Oblidar actualitzar els enllaços interns: configurar les redireccions i no actualitzar els enllaços interns que apunten a les URLs antigues. El resultat és un lloc on cada enllaç intern crea un salt de redirecció innecessari, multiplicant el consum de crawl budget.

4. No verificar el temps de resposta post-migració: algunes redireccions funcionen correctament però introdueixen latència de servidor que augmenta el TTFB (Time to First Byte). Una auditoria de velocitat post-migració amb Google Search Console i eines com WebPageTest ha de ser part del procés estàndard.

5. Eliminar les redireccions massa aviat: Google recomana mantenir les redireccions permanents actives durant almenys un any després de la migració per garantir que tots els crawlers externs i cercadors hagin actualitzat els seus índexs. Eliminar-les abans pot fer que els enllaços externs que encara apunten a les URLs antigues generin 404s en lloc de redirigir correctament.

Eines per auditar redireccions SEO

Screaming Frog SEO Spider és l’eina estàndard per a auditories de redirecció. La versió gratuïta rastreja fins a 500 URLs; la versió de pagament cobreix llocs de qualsevol mida. Els informes rellevants són: “All Redirects” (llista completa), “Redirect Chains” (2+ salts), i “Redirect & Canonical Chains” (combinació de redirects i senyals canòniques).

Ahrefs Site Audit complementa Screaming Frog amb anàlisi de redireccions al perfil de backlinks: detecta cadenes que inclouen URLs externes amb redireccions, el que és crític per avaluar si els enllaços que apunten al teu lloc estan arribant correctament a les URLs finals.

curl en terminal: per verificar redireccions individuals ràpidament, curl -I [URL] retorna les capçaleres HTTP amb el codi de resposta i la capçalera Location. És la forma més directa de confirmar que una redirecció respon amb el codi correcte.

Google Search Console: l’informe de Cobertura sota “Excloses” mostra les URLs que Google no està indexant. Les categories “Redirigida” i “Error de redirecció” identifiquen pàgines amb problemes de redirecció actius. L’informe de “Pàgines indexades” mostra si les noves URLs post-migració s’estan indexant o si Google continua usant les antigues.

Com Googlebot gestiona les redireccions

Googlebot té regles específiques de comportament davant les redireccions que afecten directament el rastreig i la indexació:

Límit de salts per sessió: Googlebot segueix fins a 5 salts de redirecció en una sola sessió de rastreig. Si una cadena supera aquest límit, abandona en aquell punt i la URL final no es rastreja ni s’indexa en aquella sessió. La pàgina pot aparèixer a Search Console com “No rastrejada - descoberta però no rastrejada encara”.

Actualització d’URLs a l’índex: quan Googlebot troba una redirecció 301, programa actualitzar la URL a l’índex en el proper recrawl. El procés no és immediat: per a llocs grans amb moltes redireccions, pot trigar setmanes fins que totes les URLs de l’índex reflecteixin les noves ubicacions.

Tractament de soft 404s: si Googlebot detecta que una redirecció porta a una pàgina amb codi 200 OK però el contingut de la qual és significativament diferent al de la URL original (per exemple, la pàgina d’inici d’un lloc), pot classificar-la com a soft 404. Les redireccions genèriques a pàgines d’inici o pàgines de categoria molt àmplies són el cas més freqüent.

robots.txt i redirects: si la URL de destinació d’una redirecció està bloquejada a robots.txt, Googlebot no podrà rastrejar-la després de seguir el redirect. El resultat és una URL d’origen amb 301 però la destinació de la qual és inaccessible per al crawler. És un error comú en migracions on les noves URLs s’afegeixen a robots.txt durant el desenvolupament però no s’eliminen abans del llançament.

Les redireccions són infraestructura SEO crítica que la majoria dels llocs gestiona de forma reactiva en lloc de proactiva. El patró habitual és configurar-les durant una migració i no auditar-les fins que apareix un problema de posicionament. Per a projectes on l’arquitectura d’URLs forma part de l’estratègia SEO, com els que treballen amb enllaçat intern avançat o contingut programàtic a escala, una auditoria de redireccions trimestral amb Screaming Frog és part del manteniment tècnic bàsic.

Si vols revisar l’estat de les redireccions del teu lloc abans d’una migració o després de detectar pèrdues de tràfic inexplicades, ho fem com a part d’una auditoria SEO tècnica.