logo
GeekFormat

Comprovador de cadena de reorientació

Comprovador de cadena de redireccions

Comprova 301/302/307/308 salt a salt, identifica bucles, redireccions entre dominis i problemes de degradació HTTPS.

Quan escriviu una adreça web al navegador, darrere les escenes pot haver-hi tota una sèrie de salts que no veieu: HTTP→HTTPS, sense www→amb www, domini antic→domini nou, enllaç curt→enllaç llarg… Cada salt de reorientació consumeix temps, afecta el posicionament SEO i fins i tot pot degradar silenciosament HTTPS a HTTP. El comprovador de cadena de reorientació segueix salt a salt el camí complet de salts de l'URL des de la perspectiva del servidor, mostrant el codi d'estat de cada salt (301/302/303/307/308), la capçalera Location i l'adreça de destinació, i detecta automàticament problemes com salts en bucle, salts entre dominis, degradació HTTPS i truncament de cadena, ajudant-vos a descobrir riscos ocults de reorientació durant la migració de dominis, el desplegament HTTPS i l'optimització per a motors de cerca.

Relacionats

Casos d'ús

  • Verificació de migració de domini: després de canviar un lloc web d'un domini antic a un de nou, verifiqueu salt a salt si els URL antics es reorienten correctament amb 301 permanent a les noves adreces, evitant pèrdua de trànsit deguda a salts en cadena i codis d'estat erronis
  • Comprovació de desplegament HTTPS: confirmeu si la cadena de salts HTTP→HTTPS és un únic salt 301, comproveu si hi ha un bucle de degradació HTTP→HTTPS→HTTP, verifiqueu si la configuració HSTS funciona
  • Detecció de pàgina final d'enllaços curts: seguiu el camí complet de salts dels enllaços curts (t.cn/bit.ly, etc.), enllaços UTM de màrqueting o enllaços de compartició social, confirmeu si la pàgina final és l'adreça esperada, comproveu si els salts intermedis insereixen paràmetres de seguiment o salts maliciosos
  • Estandardització www vs no-www: comproveu si el domini www i el domini arrel es reorienten correctament amb 301 entre si cap a la versió estandarditzada, evitant problemes SEO de contingut duplicat deguts a funcionament dual
  • Resolució de problemes de bucles de reorientació: quan el navegador mostra l'error ERR_TOO_MANY_REDIRECTS, utilitzeu l'eina per localitzar amb precisió el node on es produeix el bucle, distingint si és un error de configuració Nginx/Apache, un conflicte de regles CDN o un bucle causat per un connector de WordPress
  • Depuració de CDN i proxy invers: resoleu conflictes de reorientació en arquitectures de múltiples capes com Cloudflare, Alibaba Cloud CDN, proxy invers Nginx, identifiqueu problemes de salts mutus entre regles CDN i regles del servidor d'origen
  • Auditoria de salut SEO: comproveu regularment la longitud de la cadena de reorientació de les pàgines clau del lloc, avalueu l'impacte dels salts múltiples sobre l'eficiència de transmissió de PageRank, optimitzeu les cadenes de salts massa llargues
  • Avaluació de riscos de salts entre dominis: detecteu escenaris de reorientació entre dominis com salts d'inici de sessió, callbacks OAuth i salts de pagament, confirmeu si les Cookie i les Session es transmeten correctament durant el procés entre dominis
  • Verificació de balanceig de càrrega i multi-actiu: comproveu les polítiques de reorientació en escenaris de centres de dades multi-actiu i balanceig de càrrega global GSLB, confirmeu que els usuaris de diferents regions es reorienten correctament al node disponible més proper
  • Depuració de memòria cau de reorientació: verifiqueu la configuració de les capçaleres Cache-Control i Expires de les reorientacions permanents 301 i temporals 302, resoleu accessos anormals deguts a la memòria cau del navegador amb regles de reorientació antigues

Característiques

  • Seguiment complet salt a salt: segueix cada salt de reorientació des de la perspectiva del servidor, mostrant seqüencialment l'URL original, el codi d'estat de cada salt, el text de l'estat, la capçalera de resposta Location i el camí complet de salts, sense ometre cap node intermedi
  • Suport de tots els codis d'estat: cobreix 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect, els cinc codis d'estat de reorientació estàndard, i indica les diferències semàntiques de cada codi
  • Detecció de bucles de reorientació: identifica automàticament patrons de salts tancats com A→B→A, marca la posició exacta del node on es produeix el bucle i la longitud del bucle, localitza amb precisió l'origen de l'error ERR_TOO_MANY_REDIRECTS
  • Identificació de salts entre dominis: detecta salt a salt els canvis de Host/Domain, marca els nodes de salt entre dominis, avisa del risc de pèrdua de Cookie i problemes de comprovació prèvia CORS
  • Avís de degradació HTTPS: compta el nombre de nodes HTTP (no HTTPS) a la cadena de reorientació, marca els salts de degradació HTTPS→HTTP, avisa dels riscos de seguretat i de l'impacte negatiu per a SEO
  • Protecció de truncament de cadena: estableix un límit màxim de profunditat de salts (20 salts), quan la cadena és massa llarga es trunca automàticament i es marca, evitant timeouts de petició deguts a un seguiment infinit
  • Resum estadístic de salts: proporciona una visió general de métriques clau com el nombre total de salts, l'URL final de destinació, si s'ha detectat un bucle, si hi ha salts entre dominis, el nombre de nodes HTTP i si la cadena s'ha truncat
  • Avaluació d'impacte SEO: avalua automàticament segons el nombre de salts, el tipus de codi d'estat i la cobertura HTTPS el nivell d'impacte sobre la transmissió de PageRank i els Core Web Vitals
  • URL de prova predefinides: inclou adreces de prova habituals com geekformat.com, github.com, httpbin.org/redirect i serveis d'enllaços curts, per omplir ràpidament amb un clic
  • Historial de consultes recents: guarda automàticament els últims 8 registres de consulta (emmagatzemats localment al navegador), admet la repetició de la detecció amb un clic, per facilitar la comparació dels efectes abans i després de les correccions
  • Targetes de recomanació de diagnòstic: per a problemes detectats com salts en bucle, salts entre dominis, degradació HTTP i cadenes massa llargues, proporciona recomanacions de correcció específiques i orientació de millors pràctiques
  • Doble vista de detall i resum: per defecte mostra la targeta de resum de cadena, es pot expandir per veure l'URL complet de la petició, l'estat de la resposta, l'objectiu Location i el marcatge HTTPS de cada salt

Com usar-ho

  1. Escriviu al quadre d'entrada l'URL que voleu comprovar (ha d'incloure el prefix de protocol http:// o https://), o feu clic al botó d'URL predefinides (geekformat.com/github.com/httpbin.org/redirect, etc.) per omplir ràpidament una adreça de prova
  2. Feu clic al botó «Segueix la cadena de reorientació», l'eina iniciarà la petició des del servidor, seguint la capçalera de resposta Location salt a salt per registrar la informació completa de cada salt
  3. Consulteu la targeta de resum de salts a la part superior: nombre total de salts, URL final de destinació, si s'ha detectat un bucle, si hi ha salts entre dominis, nombre de nodes HTTP i si la cadena s'ha truncat per excés de salts
  4. A l'àrea de visualització de la cadena, consulteu la informació detallada de cada salt: número, URL de petició, codi d'estat de resposta i text descriptiu, URL objectiu a la capçalera de resposta Location, marcatge de seguretat HTTPS
  5. Pareu atenció a les targetes d'avís de diagnòstic: si es detecten salts en bucle (vermell), degradació HTTPS (taronja), salts entre dominis (groc) o cadena massa llarga (groc), l'eina marcarà la posició corresponent i proporcionarà una explicació del problema
  6. Utilitzeu l'àrea d'avaluació d'impacte SEO per veure el nivell d'impacte de la cadena de reorientació actual sobre l'eficiència de transmissió de PageRank, la velocitat de càrrega de la pàgina i els Core Web Vitals, així com les recomanacions d'optimització
  7. Un cop completada la detecció, podeu fer clic a qualsevol registre de l'historial de consultes recents per repetir ràpidament la detecció, comparar els canvis de la cadena de salts abans i després de la correcció; també podeu fer una captura de pantalla dels resultats o copiar el text per a la comunicació de l'equip i el registre de tiquets

Preguntes freqients

Quants salts són massa per a una cadena de reorientació? Quin impacte té sobre SEO?

Google recomana oficialment mantenir la cadena de reorientació en un únic salt, com a màxim 3 salts. Segons la documentació de Google Search Central, Googlebot sol seguir un màxim de 5 salts de reorientació abans d'aturar el seguiment, però això no significa que 5 salts siguin segurs. Cada salt de reorientació augmenta la latència de càrrega de la pàgina (100-300ms/salt), malbarata el pressupost de rastreig i pot causar l'atenuació de la transmissió de PageRank. 1 salt gairebé no té impacte SEO; 2 salts són acceptables però es recomana optimitzar; més de 3 salts comencen a afectar el LCP i l'eficiència de rastreig; més de 5 salts tenen el risc que la pàgina no sigui indexada. Utilitzeu aquesta eina per detectar la cadena de salts de les vostres pàgines clau, assegurant-vos que els URL crítics (inici, pàgines de productes clau, pàgines internes amb molt de trànsit) tenen un salt directe.

La reorientació 301 fa mal a SEO? PageRank es pot transmetre completament?

La reorientació permanent 301 utilitzada correctament no fa mal a SEO. Gary Illyes i John Mueller de Google han confirmat diverses vegades que la reorientació 301 des d'un domini HTTP a un domini HTTPS, així com la migració permanent d'una pàgina dins del mateix domini, transmet PageRank al 100%, sense pèrdua. Però cal tenir en compte: 1) la reorientació temporal 302 no transmet PageRank (o l'eficiència de transmissió és molt baixa); 2) si la cadena de reorientació inclou noindex, bloqueig robots.txt, errors 4xx/5xx, la transmissió del pes s'interromp; 3) després d'una migració entre dominis amb 301, cal tramitar la notificació de canvi de domini a Google Search Console per accelerar la migració de l'índex; 4) la 301 és a la memòria cau del navegador a llarg termini, en la fase de proves es recomana validar primer amb 302 i després canviar a 301.

Per què el meu lloc web salta automàticament a HTTP en lloc de HTTPS? Com es pot solucionar?

Els salts de degradació HTTPS→HTTP solen deure's a: 1) el proxy invers/CDN fa el origen per HTTP, el Nginx/Apache del servidor d'origen utilitza la variable $scheme per obtenir el protocol i obté http en lloc de https; 2) el codi de la capa d'aplicació té hardcoded el prefix http:// als URL; 3) el Home URL o Site URL de WordPress i altres CMS està configurat com a http; 4) restes de regles HTTP antigues a .htaccess; 5) la configuració SSL/TLS del servei de tercers (CDN/WAF) està en mode «flexible» en lloc de mode «estricte». Passes de correcció: primer utilitzeu aquesta eina per determinar en quin salt es produeix la degradació; configureu el SSL del CDN en mode «Full (strict)»; a Nginx, processeu correctament la capçalera X-Forwarded-Proto; a WordPress, afegiu $_SERVER['HTTPS']='on'; a wp-config.php; desplegueu la capçalera HSTS per evitar la degradació a nivell de navegador; comproveu totes les regles de reorientació per assegurar-vos que l'objectiu és https://.

Com es pot solucionar un bucle de reorientació a Nginx (ERR_TOO_MANY_REDIRECTS)?

Més del 90% dels bucles de reorientació de Nginx es deuen a un processament incorrecte de la capçalera X-Forwarded-Proto en escenaris de proxy invers/CDN. Mètode de correcció: 1) assegureu-vos que el CDN/balancejador de càrrega envia la capçalera X-Forwarded-Proto al backend: proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx ha d'utilitzar X-Forwarded-Proto en lloc de $scheme per decidir si salta a HTTPS. Es recomana utilitzar un bloc map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) eviteu escriure regles rewrite que coincideixin infinitament amb si mateixes al bloc server; 4) la reorientació www i sense www només es configura amb salt unidireccional en un bloc server, no configureu salts bidireccionals.

Com es pot solucionar un bucle de reorientació al .htaccess d'Apache?

Els bucles d'.htaccess d'Apache solen deure's a conflictes de regles RewriteRule. Passes de correcció: 1) assegureu-vos que RewriteEngine On només apareix una vegada; 2) la regla de salt HTTP→HTTPS es col·loca al davant de totes les regles, utilitzeu: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) les regles www/sense www es col·loquen després del salt HTTPS, i només fan un salt unidireccional (sense www→www o a l'inrevés); 4) noteu que el flag [L] significa «last», però si la regla modifica l'URL es torna a començar a coincidir des de la primera regla, cosa que pot causar un bucle, en regles complexes considereu utilitzar el flag [END] (Apache 2.3.9+); 5) comproveu si hi ha múltiples fitxers .htaccess (els .htaccess dels subdirectoris també s'apliquen); 6) canvieu temporalment R=301 per R=302 per fer proves, evitant interferències de la memòria cau del navegador.

Com es pot solucionar un bucle de reorientació causat per Cloudflare?

La causa més comuna dels bucles de Cloudflare és una configuració incorrecta del mode de xifratge SSL/TLS o conflictes de Page Rules: 1) canvieu el mode SSL/TLS de Cloudflare de «Flexible» a «Full» o «Full (strict)» — en mode Flexible, Cloudflare es connecta al servidor d'origen per HTTP, i si el servidor d'origen té configurat el salt HTTPS forçat es produeix un bucle; 2) comproveu si «Always Use HTTPS» a «Edge Certificates» de Cloudflare està activat, no configureu el salt HTTPS alhora al servidor d'origen i a Cloudflare; 3) comproveu si hi ha regles de reenviament conflictives a Page Rules; 4) si utilitzeu el connector WordPress de Cloudflare, no configureu la reorientació HTTPS alhora al connector i a Cloudflare; 5) comproveu si la regla Forwarding URL apunta a una adreça que Cloudflare torna a reorientar.

Quina diferència hi ha entre les reorientacions 301, 302, 307, 308? Quin he de triar?

La diferència clau rau en dues dimensions: «si és permanent» i «si conserva el mètode de petició». Guia ràpida de selecció: per a peticions GET habituals de pàgines web (accés de l'usuari a la pàgina) — utilitzeu 301 per a migracions permanents (migració de domini, canvi a HTTPS, canvi permanent d'URL), utilitzeu 302 per a salts temporals (proves A/B, manteniment temporal, salt d'inici de sessió); per a peticions POST/PUT/DELETE (crides API, enviament de formularis) — utilitzeu 308 per a migracions permanents, utilitzeu 307 per a salts temporals, per assegurar que el mètode de petició i el cos de petició no es perdin; 303 s'utilitza exclusivament per al salt a la pàgina de resultats després de l'enviament d'un formulari POST (força GET, per evitar el reenviament). Memòria simple: 301=permanent GET segur, 302=temporal GET segur, 307=temporal per a tots els mètodes, 308=permanent per a tots els mètodes, 303=després de POST salt a la pàgina de resultats.

El navegador guarda permanentment a la memòria cau la reorientació 301? Com es pot netejar la memòria cau 301?

La reorientació permanent 301 es guarda a la memòria cau del navegador per defecte, però la durada de la memòria cau depèn de la configuració de les capçaleres Cache-Control i Expires de la resposta. Si no s'especifica explícitament la capçalera de memòria cau, el comportament per defecte varia segons el navegador: Chrome sol guardar la memòria cau de les reorientacions 301 durant setmanes o mesos (fins i tot després de reiniciar el navegador pot mantenir la memòria cau); Firefox per defecte guarda 301 a la memòria cau però després de reiniciar pot tornar a validar; Safari té una política de memòria cau relativament conservadora. Mètodes per netejar la memòria cau 301: 1) Chrome: Configuració→Privadesa i seguretat→Neteja les dades de navegació→interval de temps «tot el temps»→marqueu «imatges i fitxers a la memòria cau»→Neteja les dades; 2) amb les eines de desenvolupador (F12) obertes, marqueu «Disable cache» al panell Network; 3) afegiu un paràmetre de consulta sense significat a l'URL (?nocache=1) per saltar-vos la memòria cau; 4) els desenvolupadors de Chrome poden fer Flush sockets a chrome://net-internals/#sockets, o Clear host cache a chrome://net-internals/#dns; 5) en la fase de proves utilitzeu la reorientació temporal 302 en lloc de 301, un cop confirmat sense errors canvieu-la a 301.

Quina diferència hi ha entre Meta Refresh i la reorientació HTTP? Quin és millor?

Meta Refresh és una reorientació implementada amb l'etiqueta <meta> al document HTML (com <meta http-equiv="refresh" content="0;url=https://example.com/new">), que s'executa després que el navegador analitzi l'HTML, mentre que la reorientació HTTP utilitza el codi d'estat 3xx per indicar directament el salt a nivell de protocol HTTP pel servidor. Comparació: 1) velocitat: la reorientació HTTP comença a saltar en rebre la capçalera de resposta, Meta Refresh ha d'esperar a la descàrrega i l'anàlisi de l'HTML abans de saltar, és més lenta; 2) SEO: Google sol poder reconèixer Meta Refresh i transmetre el pes (si delay=0), però es recomana oficialment utilitzar la reorientació HTTP 301/302, perquè Meta Refresh és un salt del costat del client, el senyal no és tan clar com el del salt del servidor; 3) retard: Meta Refresh pot establir un temps de retard (com content="5;url=..." significa saltar després de 5 segons), però la reorientació HTTP no té aquesta funció; 4) accessibilitat: el W3C no recomana utilitzar Meta Refresh, perquè les tecnologies assistives com els lectors de pantalla no el processen bé, i pot confondre l'usuari; 5) botó de retrocés: Meta Refresh pot trencar el comportament del botó de retrocés en alguns navegadors. Conclusió: prioritzeu sempre la reorientació HTTP 301/302/307/308, eviteu Meta Refresh, tret que no pugueu controlar la configuració del servidor (com allotjar-vos en una plataforma de pàgines estàtiques on no es poden configurar regles del servidor).

La reorientació afecta el LCP dels Core Web Vitals?

Sí, i molt significativament. La reorientació es produeix abans que el navegador obtingui el document HTML, la qual cosa significa que cada salt de reorientació retarda el moment d'inici de la descàrrega del document HTML. El càlcul de LCP (Largest Contentful Paint, pintat de contingut més gran) té com a punt de partida el moment d'inici de la navegació, i el navegador ha d'obtenir l'HTML final abans de començar a analitzar el DOM, carregar el CSS i renderitzar l'element LCP. Suposant que cada salt de reorientació afegeix 150ms de latència de xarxa (DNS+TCP+TLS+petició-resposta), 3 salts de reorientació afegiran almenys 450ms al LCP, la qual cosa és suficient per empènyer el LCP de «bo» (≤2,5s) a «necessita millora» (2,5-4s). La documentació de Core Web Vitals de Google inclou explícitament «evitar múltiples reorientacions» com una de les recomanacions clau per optimitzar el LCP. Millors pràctiques: assegureu-vos que les pàgines clau no tenen reorientacions (enllaços directes a l'URL final), i que les reorientacions necessàries com HTTP→HTTPS i estandardització www es mantenen en un únic salt.

Com es pot comprovar on salta finalment un enllaç curt?

Els enllaços curts (t.cn, bit.ly, dwz.cn, url.cn, etc.) normalment arriben a l'URL final a través de 1-3 salts de reorientació, i al mig poden incloure paràmetres de seguiment UTM, salts de detecció de dispositiu, salts geogràfics, etc. Amb aquesta eina podeu: 1) introduir l'URL de l'enllaç curt (incloent http:// o https://); 2) fer clic a segueix per veure el camí complet de cada salt; 3) consultar l'URL final de destinació, el nombre de salts i el tipus de codi d'estat; 4) comprovar si els salts intermedis tenen degradació HTTP o salts entre dominis anormals. Nota: alguns enllaços curts retornen destinacions finals diferents en funció del User-Agent o la regió IP, aquesta eina utilitza la IP del servidor per fer la petició, i el resultat pot diferir lleugerament del que veieu accedint directament des del navegador (especialment per a serveis d'enllaços curts estrangers). Per als enllaços curts url.cn de WeChat/QQ, pot caldre estar dins de l'entorn de WeChat per saltar correctament a la pàgina objectiu.

El salt forçat a HTTPS ha d'utilitzar 301 o 302? Cal afegir HSTS?

El salt forçat a HTTPS ha d'utilitzar la reorientació permanent 301, perquè el canvi d'HTTP a HTTPS és un canvi permanent, no un salt temporal. Un cop configurat el 301, també s'ha de desplegar la capçalera HSTS. La solució completa de HTTPS forçat es divideix en tres fases: 1) Primera fase (període de proves): primer configureu la reorientació 301 HTTP→HTTPS, sense habilitar HSTS, observeu durant 1-2 setmanes per confirmar que tots els recursos i subdominis funcionen correctament; 2) Segona fase (període estable): afegiu la capçalera Strict-Transport-Security, amb un max-age inicial curt (com max-age=300, és a dir, 5 minuts), aneu allargant-lo progressivament fins a max-age=31536000 (1 any); 3) Tercera fase (Preload): un cop confirmat que tots els subdominis suporten HTTPS, afegiu includeSubDomains i la directiva preload, i després tramiteu-la a la HSTS Preload List (hstspreload.org), perquè el navegador porti integrada la política HSTS del vostre domini, eliminant la finestra HTTP del primer accés. Noteu que un cop HSTS és a la memòria cau del navegador, abans que max-age caduqui no es pot revocar des del servidor, per tant feu proves exhaustives abans del desplegament.

Quina diferència hi ha entre el salt window.location de JavaScript i la reorientació HTTP?

Els salts de JavaScript (com window.location.href='https://example.com') i les reorientacions HTTP 3xx tenen diferències essencials: 1) nivell d'execució: la reorientació HTTP es fa a nivell de protocol pel servidor retornant un codi d'estat, el navegador salta immediatament en rebre la capçalera de resposta; el salt JS necessita la descàrrega de l'HTML, l'anàlisi i l'execució del JS abans de saltar, és més lent; 2) SEO: els rastrejadors dels motors de cerca poden reconèixer i seguir correctament les reorientacions HTTP 301/302 per transmetre el pes, però l'efecte SEO dels salts JS depèn de si el rastrejador executa JS i quan, el senyal és feble i inestable; 3) procés intermedi: abans del salt JS la pàgina ja ha començat a carregar-se (pot aparèixer una pantalla blanca o parpelleig de contingut parcial), amb la reorientació HTTP l'usuari arriba directament a la pàgina objectiu, l'experiència és més fluida; 4) fiabilitat: JS pot ser bloquejat pel navegador, complements o Content Security Policy, la reorientació HTTP és processada pel nucli del navegador, la fiabilitat és la més alta. Conclusió: quan calgueu saltar permanentment o temporalment un URL, utilitzeu sempre la reorientació HTTP 301/302 del servidor, els salts JS només s'utilitzen per a la navegació de pàgines en la lògica d'interacció (com salts després de la validació d'un formulari, salts en fer clic a un botó, etc.).

La cadena de reorientació pot fer que els resultats de les proves A/B no siguin precisos?

Sí, la cadena de reorientació afecta les proves A/B en diversos aspectes: 1) si la prova A/B s'implementa amb reorientacions (50% dels usuaris 302 a la versió A, 50% a la versió B), la latència de la reorientació fa que la velocitat de càrrega de les dues versions sigui diferent, la velocitat en si pot afectar la taxa de conversió (la versió més ràpida té naturalment una taxa de conversió més alta), causant un biaix en la prova; 2) la reorientació pot perdre paràmetres UTM o marcadors d'origen, fent que les dades d'atribució no siguin precises; 3) si la reorientació 302 dura molt de temps, Google pot jutjar per si mateix que és 301 i transmetre el pes, afectant el SEO de les pàgines de prova; 4) si algun salt de la cadena de reorientació múltiple estableix Cookie, pot afectar la lògica d'agrupació d'usuaris. Es recomana utilitzar per a les proves A/B la divisió de trànsit del servidor renderitzant o la divisió de trànsit JS del client (com Google Optimize, Optimizely), evitant la divisió amb reorientacions. Si cal utilitzar reorientacions (com ara provar camins d'URL completament diferents), utilitzeu 302 (no 301) i assegureu-vos que sigui un únic salt directe, i elimineu la reorientació a temps un cop acabada la prova.

Com es pot comprovar en lot la cadena de reorientació de tot el lloc web?

La comprovació en lot de les cadenes de reorientació del lloc web ha de combinar eines de rastreig: 1) utilitzeu eines de rastreig com Screaming Frog SEO Spider per rastrejar tot el lloc web, consulteu tots els URL reorientats i la longitud de la cadena a l'informe Redirect Chains; 2) utilitzeu les funcions d'auditoria de lloc d'eines SEO com Ahrefs, Semrush o Sitebulb, que detecten automàticament les cadenes de reorientació i els bucles; 3) per a la llista de pàgines clau, podeu escriure un script que cridi l'API del backend d'aquesta eina per detectar en lot; 4) a l'informe «Indexació de pàgines» de Google Search Console, consulteu els consells «error de reorientació» i «cadena de reorientació massa llarga»; 5) utilitzeu l'auditoria Lighthouse de Chrome DevTools, la secció Performance marcarà els problemes de reorientació. Es recomana comprovar amb prioritat: la pàgina d'inici, les pàgines de navegació principals, les pàgines de destinació amb molt de trànsit, les pàgines migrades o redissenyades recentment, tots els URL HTTP després del canvi a HTTPS, i tots els URL del domini antic.

术语表

Reorientació (Redirect)
Mecanisme pel qual el servidor retorna un codi d'estat 3xx i una capçalera de resposta Location, indicant al client que accedeixi automàticament a un altre URL. La reorientació sol ser transparent per a l'usuari, el navegador la segueix automàticament.
301 Moved Permanently
Codi d'estat de reorientació permanent. Indica que el recurs s'ha mogut permanentment a una nova ubicació, els motors de cerca transferiran el PageRank de l'URL antic al nou URL, i el navegador guardará a la memòria cau aquesta reorientació. En escenaris de petició GET, recomanat per a migracions de domini, canvi a HTTPS i altres canvis permanents.
302 Found
Codi d'estat de reorientació temporal (originalment Move Temporarily). Indica que el recurs es troba temporalment en una altra ubicació, els motors de cerca no transferiran el pes, el navegador no fa memòria cau a llarg termini. Nota: les peticions POST que reben 302 són convertides a GET per la majoria de navegadors, la qual cosa pot perdre el cos de petició.
303 See Other
Codi d'estat «veure una altra ubicació». Normalment utilitzat per al salt a la pàgina de resultats després de l'enviament d'un formulari POST, exigeix explícitament que el client sol·liciti el nou URL amb GET, per evitar el reenviament del formulari. La resposta 303 no hauria de ser a la memòria cau.
307 Temporary Redirect
Codi d'estat de reorientació temporal (introduït a HTTP/1.1). La mateixa semàntica que 302, però exigeix estrictament conservar el mètode de petició i el cos de petició — una petició POST que rep 307 ha de continuar sol·licitant el nou URL amb POST, sense perdre les dades del formulari. Apropiat per a salts temporals en escenaris d'API i formularis.
308 Permanent Redirect
Codi d'estat de reorientació permanent (definit per RFC 7538). La mateixa semàntica que 301, però exigeix estrictament conservar el mètode de petició i el cos de petició — una petició POST que rep 308 continua reorientant-se amb POST. És la versió «mètode segur» de 301, totalment compatible amb els navegadors moderns.
Capçalera Location
Camp de la capçalera de resposta HTTP, utilitzat per especificar l'URL objectiu en les respostes de reorientació 3xx. Pot ser un URL absolut (recomanat) o relatiu, i el client en rebre'l inicia automàticament una nova petició a aquest URL. Els caràcters no ASCII de la capçalera Location han de ser codificats com a URL.
Cadena de reorientació (Redirect Chain)
La seqüència de reorientacions contínues entre l'URL inicial i l'URL final. Per exemple, A→B→C→D forma una cadena de reorientació de 3 salts. Una cadena de reorientació massa llarga alenteix la velocitat de càrrega i perd pes SEO, es recomana mantenir-la en un únic salt, com a màxim 3 salts.
Bucle de reorientació (Redirect Loop)
Un URL de la cadena de reorientació es repeteix, formant un bucle infinit de salts (com A→B→A). Quan el navegador arriba al nombre màxim de salts (normalment 20), mostra l'error ERR_TOO_MANY_REDIRECTS. Les causes habituals inclouen salts mutus HTTP↔HTTPS, salts mutus www↔sense www i pèrdua de protocol en proxy invers.
Migració de domini (Domain Migration)
El procés pel qual un lloc web canvia permanentment d'un domini a un altre, com canvi de marca de domini, adquisició o fusió. Durant la migració, cal reorientar amb 301 tots els URL del domini antic a les pàgines corresponents del domini nou, i tramitar la notificació de canvi de domini a Google Search Console.
Estandardització d'URL (URL Canonicalization)
El procés d'unificar les múltiples variants d'URL del mateix contingut (www/sense www, amb/sense barra final, HTTP/HTTPS, diferències de majúscules i minúscules) a un únic URL canònic, normalment implementat amb reorientació 301. L'estandardització evita problemes de contingut duplicat i concentra el pes SEO.
Salt forçat a HTTPS
La configuració que reorienta amb 301 totes les peticions HTTP (port 80) a HTTPS (port 443), un pas necessari després del desplegament d'un certificat SSL/TLS. Normalment s'utilitza juntament amb la capçalera HSTS per eliminar la finestra HTTP en text clar del primer accés.
HSTS
HTTP Strict Transport Security (Seguretat de Transport Estricta), a través de la capçalera de resposta Strict-Transport-Security indica al navegador que durant el període especificat només es pot accedir a aquest domini per HTTPS, el navegador puja automàticament HTTP a HTTPS sense necessitat de reorientació del servidor. Defensa efectivament contra atacs d'eliminació SSL.
Enllaç curt (Short URL)
Servei que converteix un URL llarg en un URL curt (com bit.ly, t.cn), que en accedir-hi salta a l'URL original mitjançant reorientació 301/302. Darrere els enllaços curts sovint s'hi amaguen cadenes de salts múltiples, que poden incloure paràmetres de seguiment o saltar a diferents destinacions en certes condicions.
PageRank
Algorisme de classificació de pàgines inventat pels fundadors de Google Larry Page i Sergey Brin, que avalua l'autoritat de les pàgines a través de les relacions d'enllaços. La reorientació permanent 301 transmet el PageRank de l'URL antic al nou URL, mentre que la reorientació temporal 302 normalment no transmet o en transmet molt poc.
Core Web Vitals
Indicadors centrals d'experiència de pàgina definits per Google, inclouen LCP (Largest Contentful Paint, mesura el rendiment de càrrega, estàndard bo ≤2,5s), FID/INP (responsivitat d'interacció, estàndard bo ≤100ms/200ms) i CLS (estabilitat visual, estàndard bo ≤0,1). La cadena de reorientació retarda la descàrrega HTML i deteriora directament l'indicador LCP.
Reorientació entre dominis (Cross-origin Redirect)
L'URL objectiu de la reorientació té un domini diferent de l'URL original (incloent dominis completament diferents o subdominis diferents). La reorientació entre dominis està subjecta a la política del mateix origen, i pot causar problemes com no enviament de Cookie, bloqueig de Cookie de tercers i fallada de la comprovació prèvia CORS.
Truncament de cadena (Chain Truncation)
Quan el nombre de salts de la cadena de reorientació supera el límit màxim de profunditat establert per l'eina o el navegador (aquesta eina 20 salts, Chrome 20 salts), el rastrejador deixa de seguir les reorientacions posteriors i marca la cadena com a truncada. El truncament de cadena normalment indica un bucle infinit o una configuració de reorientació anormalment complexa.

Taula comparativa completa dels codis d'estat de reorientació HTTP

301Moved PermanentlySí (permanent)Pot canviar (POST→GET)Migració de domini, canvi a HTTPS, estandardització www/sense www, canvi permanent d'URL
302FoundNo (temporal)Pot canviar (POST→GET)Pàgina de manteniment temporal, salt d'inici de sessió, proves A/B, pàgines de campanya a curt termini
303See OtherNo (temporal)Sí (força GET)Salt a la pàgina de resultats després de l'enviament d'un formulari POST, per evitar el reenviament
307Temporary RedirectNo (temporal)No (conserva estrictament el mètode original)Reorientació temporal d'API, salts temporals que necessiten conservar les dades POST
308Permanent RedirectSí (permanent)No (conserva estrictament el mètode original)Migració permanent d'API RESTful, reorientacions permanents que necessiten conservar el mètode PUT/DELETE

Taula comparativa de l'impacte de la cadena de reorientació sobre SEO

0 salts (arribada directa)Sense impacte, estat òptimSense latència addicionalMaintenir l'estat actual, els enllaços interns apunten directament a l'URL final
1 saltPageRank es transmet normalment, l'impacte SEO és negligibleAugment d'uns 100-300ms de latència (un viatge)Acceptable, nombre de salts habitual per a HTTP→HTTPS i estandardització de domini
2 saltsLa transmissió de pes pot tenir una lleugera atenuació, el rastrejador pot seguir-la normalmentAugment d'uns 200-600ms de latènciaEs recomana optimitzar a un únic salt, comproveu si els enllaços interns apunten a URL de salt intermedis
3 saltsL'eficiència de transmissió de pes baixa, alguns rastrejadors poden abandonar el seguimentAugment d'uns 300-900ms de latència, el LCP es pot veure afectatS'ha d'optimitzar, consolidar les regles de reorientació per arribar directament a l'URL final
4-5 saltsAtenuació evident de PageRank, la indexació es pot veure afectada, malbaratament del pressupost de rastreigAugment de 500ms-1,5s de latència, el LCP probablement supera el llindarCorrecció urgent, comproveu si CDN/servidor d'origen/aplicació apilen reorientacions en múltiples capes
6 salts o mésRisc greu, els motors de cerca poden aturar el seguiment i causar la desindexació de la pàginaLatència superior a 1 segon, experiència d'usuari molt dolentaInvestigar immediatament els bucles o errors de configuració, reconstruir les regles de reorientació
Bucle (ERR_TOO_MANY_REDIRECTS)La pàgina és completament inaccessible, els motors de cerca l'eliminen de l'índexLa pàgina no es pot carregar, el navegador mostra errorCorrecció de màxima prioritat, utilitzeu aquesta eina per localitzar el node del bucle

Errors habituals de configuració de reorientació i solucions

Error de bucle ERR_TOO_MANY_REDIRECTS, salts repetits HTTP↔HTTPSEl CDN/balancejador de càrrega fa el origen per HTTP, el servidor d'origen no processa correctament la capçalera X-Forwarded-Proto, sempre reorienta a HTTPSAfegiu a la configuració Nginx: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } o utilitzeu la variable $scheme combinada amb proxy_set_header X-Forwarded-Proto
www i sense www es reorienten mútuament formant un bucleLa capa CDN té configurat el salt www→sense www, el Nginx del servidor d'origen té configurat el salt sense www→www, conflicte de reglesEscolliu una versió estandarditzada (es recomana sense www o amb www, manteniu la coherència), només configureu la reorientació en una capa (CDN o servidor d'origen), elimineu les regles corresponents a l'altra capa
La cadena de reorientació passa per 4-5 salts per arribar a la pàgina finalSalt HTTP→HTTPS → salt sense www→www → salt amb barra final → salt camí antic→camí nou, apilament de múltiples capes de reglesConsolidar les regles de reorientació, fer un salt directe des de l'URL inicial a l'URL final. A Nginx, utilitzeu la directiva return per fer un salt únic a l'adreça final completa
La cadena de reorientació d'un lloc HTTPS conté nodes HTTP (degradació)La configuració del servidor té hardcoded el prefix http:// per a l'objectiu de la reorientació, o l'aplicació genera l'URL de reorientació sense reconèixer que el frontal és HTTPSConfigureu l'aplicació per confiar en el proxy invers, llegiu correctament X-Forwarded-Proto; a Nginx, utilitzeu URL absoluts https:// o la variable $scheme (suposant que el proxy ha configurat correctament el scheme); desplegueu HSTS
Després de modificar una reorientació 301, el navegador encara salta a l'adreça antigaEl navegador té a la memòria cau a llarg termini la regla de reorientació permanent 301, la tecla F5 no funcionaEn la fase de proves utilitzeu primer la reorientació temporal 302, un cop confirmat sense errors canvieu-la a 301; netegeu la memòria cau del navegador (Chrome: Configuració→Privadesa→Neteja les dades de navegació→Imatges i fitxers a la memòria cau); utilitzeu l'opció Disable cache de DevTools
Les dades del formulari es perden després de la reorientació d'una petició POSTS'ha utilitzat la reorientació 301 o 302, el navegador converteix automàticament POST a GET, el cos de petició es descartaPer a peticions no GET com POST/PUT/DELETE, utilitzeu reorientació 307 (temporal) o 308 (permanent), que conserven estrictament el mètode de petició i el cos de petició
L'URL mostra caràcters de doble codificació com %2520 després de la reorientacióEls paràmetres de l'URL ja s'han codificat una vegada, el servidor els codifica una segona vegada en reorientarComproveu la lògica de reorientació, assegureu-vos que l'URL només es codifica una vegada; a Nginx, utilitzeu $request_uri (URI original, no descodificada) en lloc de $uri (descodificada)
La petició AJAX/fetch reporta un error CORS després d'una reorientació entre dominisEl servidor objectiu de la reorientació entre dominis no té configurades les capçaleres CORS (Access-Control-Allow-Origin, etc.)Assegureu-vos que cada salt de la cadena de reorientació té les capçaleres CORS configurades correctament; o eviteu utilitzar reorientacions entre dominis a les peticions AJAX, en lloc d'això, l'frontend obté l'URL objectiu i fa la petició directament

Troubleshooting