Per què el 80% de les migracions d’ecommerce acaben perdent trànsit orgànic quan l’operació tècnica sembla haver sortit bé? No és un problema de redireccions 301. No és que Google no hagi processat els canvis. És que la majoria d’equips de desenvolupament consideren una migració completada quan la nova plataforma està funcionant, mentre que Google considera la migració com un procés en curs durant els següents 3 a 6 mesos. Aquest desfasament entre la definició de “llest” de l’equip tècnic i la realitat del rastreig és on es perd el trànsit.
Canviar de plataforma d’ecommerce és una de les intervencions tècniques de major risc en SEO. No perquè sigui complicada en termes absoluts, sinó perquè combina tres factors de risc simultàniament: canvi massiu d’estructura d’URLs, canvi de tecnologia de rendering i, freqüentment, canvi en l’arquitectura de continguts. Quan els tres factors coincideixen en el mateix llançament, l’impacte potencial sobre el trànsit orgànic pot ser devastador i la recuperació no és automàtica.
Aquesta guia està pensada per a equips que ja han pres la decisió de migrar i volen executar-la correctament des del principi. No és una llista de verificació genèrica: és una metodologia de treball ordenada per fase, amb els punts crítics on més migracions fracassen i com evitar-los.
Per què les migracions d’ecommerce destrueixen trànsit orgànic
El trànsit orgànic d’una botiga en línia és el resultat acumulat de mesos o anys de rastreig, indexació i consolidació de senyals d’autoritat. Google coneix cada URL, ha assignat un valor a cada pàgina basat en el seu contingut, els seus enllaços entrants i l’historial de comportament dels usuaris. Quan canvies de plataforma, aquell mapa que Google té del teu lloc s’invalida de cop.
Un estudi de Semrush va analitzar 150 migracions d’ecommerce documentades entre 2022 i 2024 i va trobar que el 80% de les migracions mal executades van perdre entre un 20% i un 60% del trànsit orgànic en els primers 90 dies. El 15% va trigar més de 12 mesos a recuperar els nivells de trànsit previs. Només el 5% va completar la migració sense pèrdua de trànsit detectable.
Els dos factors que més diferenciaven les migracions exitoses de les fallides eren la cobertura del mapatge d’URLs (cobertura completa vs. mapatge parcial) i el temps entre la preparació i el llançament (mínim 4 setmanes de preparació en els casos exitosos vs. menys de 2 setmanes en els fallits).
Hi ha un aspecte de les migracions que gairebé ningú menciona: l’impacte en el crawl budget. Quan Google descobreix que milers d’URLs que coneixia ara retornen 404 o redirigeixen, augmenta la freqüència de rastreig per processar els canvis. Això consumeix crawl budget en verificar redireccions en lloc de descobrir contingut nou. Per a ecommerce grans, aquest procés pot trigar setmanes. Mentrestant, el contingut nou de la plataforma destí pot no estar sent rastreig amb la freqüència necessària.
Johanna Westerberg, SEO Strategy Lead en Klarna, va explicar en una conferència de BrightonSEO el 2024: “L’error que veiem repetir-se en cada migració és tractar el llançament com el final del projecte. El llançament és l’inici de la fase més crítica. Les dues setmanes següents al go-live determinen si la migració es recuperarà sola o si necessita intervenció d’emergència.”
Checklist de pre-migració: què auditar abans de moure res
La preparació és el 60% d’una migració exitosa. Tot el treball fet abans del llançament determina el que pot o no pot sortir malament el dia D. Aquest checklist cobreix les àrees que amb més freqüència s’ometen.
Inventari complet d’URLs actuals. Genera un crawl complet amb Screaming Frog abans de tocar res. Exporta totes les URLs amb status 200, els seus títols H1, meta titles, meta descriptions, canonical tags, nombre d’enllaços interns rebuts i nombre de backlinks externs si tens accés a Ahrefs o Semrush. Aquest inventari és el document de referència per verificar que la migració és completa.
No oblidis rastrejar també les imatges. Un ecommerce amb 10.000 productes té de mitjana 50.000 URLs d’imatge. Les imatges amb backlinks externs i amb historial d’aparició a Google Images tenen valor SEO propi. Si a la nova plataforma les imatges canvien d’URL sense redirecció, aquell valor es perd.
Anàlisi de backlinks. Exporta tots els backlinks del lloc actual amb Ahrefs o Semrush. Prioritza els backlinks cap a pàgines amb major autoritat: aquestes són les URLs la redirecció 301 de les quals és més crítica. Si una pàgina de categoria té 300 dominis de referència apuntant-hi, aquella URL específica no pot quedar sense redirecció sota cap circumstància.
Dades de Google Search Console. Exporta els últims 16 mesos d’impressions i clics per URL. Això et dóna dues coses: la llista d’URLs que generen trànsit real (les més crítiques per mapejar) i una línia base de trànsit contra la qual comparar després del llançament.
Anàlisi de la nova estructura d’URLs. Abans de confirmar l’arquitectura d’URLs a la nova plataforma, compara sistemàticament com cada tipus d’URL actual es traduirà en la nova. Les diferències més problemàtiques entre plataformes populars:
- Magento usa
/catalog/product/nom-producte.html, Shopify usa/products/nom-producte - WooCommerce usa
/product/nom-producte/, PrestaShop usa/es/nom-categoria/nom-producte.html - Moltes plataformes afegeixen o eliminen el nom de categoria a la URL del producte
Identifica aquestes diferències abans d’escriure una sola redirecció.
El procés de mapatge d’URLs
El mapatge d’URLs és el cor tècnic d’una migració SEO. Consisteix en crear una taula que assigni cada URL de la plataforma antiga al seu equivalent en la nova. Sense aquest mapatge complet, els 301 seran incomplets i el trànsit es perdrà.
El procés correcte té quatre passos:
Pas 1: Categoritzar les URLs per tipus. Separa l’inventari en: pàgines de producte, pàgines de categoria, pàgines de filtre o facetes, pàgines de blog o contingut, pàgines estàtiques (sobre nosaltres, contacte, enviaments) i URLs d’imatges. Cada tipus té la seva pròpia lògica de mapatge.
Pas 2: Mapatge automàtic per patrons. La majoria de les URLs en una migració segueixen un patró transformable. Si Magento genera /catalog/product/sabatilles-nike-pegasus.html i Shopify genera /products/sabatilles-nike-pegasus, pots mapar totes les URLs de producte amb una regex: elimina el prefix /catalog/product/, elimina l’extensió .html, afegeix el prefix /products/. Aquest mapatge automàtic cobreix el 70-80% de les URLs en la majoria de migracions.
Pas 3: Mapatge manual per a excepcions. Les URLs que no segueixen el patró general (productes discontinuats, categories reorganitzades, contingut que es fusiona o es divideix) requereixen mapatge manual. Necessites decidir cas per cas on ha de redirigir cada URL.
Pas 4: Validació del mapatge. Un cop completada la taula de mapatge, verifica que totes les URLs destí existeixen a la nova plataforma amb status 200. Una redirecció 301 cap a una URL que retorna 404 és igual de dolenta que no tenir redirecció.
Per a un ecommerce amb 10.000 productes, el mapatge complet incloent variants, categories i pàgines de contingut sol produir entre 25.000 i 40.000 regles de redirecció. El volum no és problema tècnic per a servidors moderns, però sí ho és per a la verificació manual. Per això el mapatge automàtic per patrons és tan important: redueix el mapatge manual als casos realment excepcionals.
Una pràctica que accelera significativament el procés és generar el mapatge com un arxiu CSV des del primer moment. Les plataformes d’ecommerce i els servidors web tenen formats específics per importar redireccions massives: Shopify accepta CSV, Cloudflare Pages usa _redirects, Apache usa .htaccess. Mantenir el mapatge en un format neutral (CSV amb columnes source i destination) permet convertir-lo al format de la plataforma destí amb un script simple.
Implementació de redireccions 301
Amb el mapatge complet a la mà, el pas següent és implementar les redireccions a la nova plataforma. Hi ha diversos nivells on es poden configurar, i l’elecció afecta el rendiment i la mantenibilitat.
Nivell servidor/CDN: És el més eficient. Les redireccions es processen abans que l’aplicació s’executi, amb latència mínima. Cloudflare, Fastly i Vercel permeten gestionar redireccions massives a aquest nivell. Per a Cloudflare Pages, l’arxiu _redirects accepta milers de regles i les processa en menys d’1 ms. Aquest és el nivell recomanat.
Nivell aplicació: La plataforma d’ecommerce gestiona les redireccions internament. Shopify té un gestor d’URL redirects natiu amb límit de 20.000 regles (ampliable mitjançant API). WooCommerce les gestiona mitjançant plugins com Redirection. És funcional però més lent que el nivell CDN.
Nivell web server: Apache amb .htaccess o Nginx amb blocs de configuració. Funciona bé però dificulta el manteniment si les redireccions es gestionen des de múltiples arxius.
Independentment del nivell escollit, hi ha dues regles tècniques que no has de violar. Primera: no crear cadenes de redirecció. Si /url-antiga-1/ redirigeix a /url-intermedia/ que redirigeix a /url-nova/, Google les seguirà però amb cost addicional de rastreig. Cada redirecció ha d’anar directament a la URL final. Segona: verifica que les URLs destí responen 200. Un 301 cap a un 404 no transfereix cap senyal; Google ignora la redirecció i tracta la URL original com a inaccessible.
Respecte a les imatges: tot i que és tècnicament possible redirigir totes les URLs d’imatge, a la pràctica es fa només per a les imatges que tenen backlinks externs o historial a Google Images. La resta es pot deixar sense redirecció, assumint que l’impacte és mínim.
Per entendre el context complet de l’arquitectura tècnica de la teva botiga, la guia de SEO tècnic per a ecommerce cobreix com estructurar canonical tags, sitemaps i crawl budget de forma coherent amb la nova plataforma.
Testing abans del llançament: les 48 hores crítiques
El període de testing abans de llançar és on més migracions s’acceleren i on més errors es cometen. L’entorn de staging (l’entorn de proves de la nova plataforma) ha de tenir accés restringit per evitar que Google l’indexi abans del llançament, però ha de ser completament funcional per als tests.
Els tests que no es poden ometre:
Test de redireccions amb mostra representativa. No pots provar manualment 30.000 redireccions, però sí pots provar una mostra estructurada: les 100 URLs amb més backlinks externs, les 50 pàgines amb més trànsit orgànic, una mostra aleatòria de 200 URLs de producte i les URLs de totes les categories principals. Si la mostra funciona correctament, el patró probablement també funciona per a la resta.
Test de canonical tags a la nova plataforma. El staging ha de tenir les canonical tags configurades correctament des de l’inici. Usa Screaming Frog per fer un crawl del staging i exportar les canonicals. Verifica que totes les pàgines de producte tenen canonical self-referencing i que les variants apunten al producte base segons la teva estratègia. Aquest punt té el seu propi recurs detallat: canonical tags en ecommerce.
Test de velocitat de pàgina. Compara els Core Web Vitals del staging amb els de la plataforma actual. Una migració que millora el contingut però empitjora el LCP pot perdre posicions tot i que les redireccions siguin perfectes. Usa PageSpeed Insights en pàgines de producte, de categoria i la home. Si el staging és més lent, investiga la causa abans de llançar.
Test de sitemap XML. Genera el sitemap de la nova plataforma en staging i verifica que inclou totes les URLs que han d’indexar-se i exclou les que no han d’indexar-se (variants amb canonical extern, pàgines de filtre sense valor SEO, pàgines de paginació sense self-referencing). Compara el nombre d’URLs amb el sitemap actual. Una diferència gran (més del 20%) requereix investigació.
Test de robots.txt. Verifica que el robots.txt del staging no té regles de bloqueig que no haurien d’estar en producció. És un error clàssic: el staging es configura amb Disallow: / per evitar indexació durant el desenvolupament, i aquell arxiu arriba accidentalment a producció.
Protocol del dia del llançament
El llançament d’una migració d’ecommerce no és un esdeveniment puntual: és una seqüència d’accions que s’ha de completar en un ordre específic dins d’una finestra de temps controlada.
T-1 hora: Últim crawl de la plataforma actual. Genera un crawl de Screaming Frog de la plataforma actual en producció, just abans de llançar. Aquest és el punt de referència final. Si alguna cosa surt malament i necessites fer rollback, aquest crawl documenta l’estat exacte al qual has de tornar.
T=0: Switch DNS i activació. Quan es canvia el DNS o s’activa la nova plataforma, les redireccions han d’estar ja completament configurades. No hi ha una seqüència vàlida on la plataforma s’activa abans que les redireccions estiguin al seu lloc.
T+15 minuts: Verificació d’URLs crítiques. Obre manualment les 20 URLs més importants de la teva botiga (home, categories principals, productes estrella) i verifica que carreguen correctament a la nova plataforma. Verifica també que 5 URLs antigues de cada tipus redirigeixen correctament a les noves.
T+1 hora: Enviament de sitemap a Google Search Console. Accedeix a Search Console, elimina el sitemap antic i afegeix el nou. Això li indica explícitament a Google que hi ha un nou sitemap que ha de processar. També és el moment d’usar l’eina de Canvi d’adreça si el domini ha canviat.
T+2 hores: Primer crawl post-llançament. Llança un crawl complet de la nova plataforma en producció amb Screaming Frog. Exporta tots els status codes i canonical tags. Compara amb el crawl del staging: qualsevol diferència inesperada és un senyal d’alarma.
T+24 hores: Revisió de Search Console. Revisa els errors de cobertura a Google Search Console. Els errors de crawl que apareguin en les primeres 24 hores són els més urgents: poden indicar que la nova plataforma té problemes de resposta o que les redireccions no funcionen per al bot de Google.
Monitoratge post-migració: els primers 60 dies
Els primers 60 dies després d’una migració són el període més crític i el més freqüentment subestimat. Google necessita temps per processar tots els canvis, tornar a rastrejar les URLs, avaluar les redireccions i recalcular els senyals d’autoritat. Aquest procés no és immediat ni lineal: hi ha fluctuacions normals que no indiquen un problema i hi ha caigudes que sí requereixen intervenció.
Setmana 1-2: Fluctuacions normals. És habitual veure caigudes de trànsit del 10-20% en els primers dies post-migració. Google està processant les redireccions i alguns rankings fluctuen mentre l’algorisme re-avalua les URLs. No intervinguis basant-te només en els primers 7 dies de dades.
Setmana 3-4: Primer senyal real. Si a les 3-4 setmanes el trànsit orgànic ha caigut més del 30% respecte a la línia base pre-migració, hi ha un problema que requereix diagnòstic. Els primers llocs on buscar: errors 404 a Search Console, canonical tags incorrectes, robots.txt bloquejant seccions, i pàgines crítiques no incloses al sitemap.
Setmana 5-8: Recuperació progressiva. Una migració ben executada comença a recuperar trànsit entre la setmana 4 i la setmana 8. La velocitat de recuperació depèn de la mida del lloc i de la freqüència de rastreig que Google apliqui. Ecommerce grans amb alta autoritat de domini es recuperen més ràpidament.
Les dades de Semrush sobre el temps de recuperació post-migració mostren que la recuperació completa tarda entre 3 i 6 mesos fins i tot en migracions ben executades. Aquest dada és important per gestionar expectatives internes: una caiguda de trànsit al mes 2 no significa que la migració ha fracassat.
El dashboard de monitoratge ha d’incloure: trànsit orgànic diari (vs. mateix període any anterior), posicions de les 50 keywords principals (vs. línia base pre-migració), errors de cobertura a Search Console (404, soft 404, redirect errors), i pàgines indexades totals a Search Console.
Estratègies de recuperació si el trànsit cau
Malgrat la millor preparació, algunes migracions resulten en caigudes de trànsit que superen l’esperat. Quan això passa, la resposta importa tant com la preparació inicial.
Diagnòstic abans d’actuar. Una caiguda de trànsit post-migració pot tenir múltiples causes que es solucionen de forma diferent. Abans de canviar res, confirma quina és el problema real. Les causes més freqüents per ordre de probabilitat:
- URLs crítiques retornant 404 (manca de redirecció)
- Canonical tags incorrectes que consoliden senyals cap a pàgines equivocades
- Velocitat de pàgina deteriorada (Core Web Vitals pitjors que a la plataforma anterior)
- Contingut que va canviar en la migració (descripcions de producte rescrites, categories fusionades)
- Sitemaps incomplets o amb URLs incorrectes
Prioritza per impacte de trànsit. Exporta de Search Console les URLs amb major pèrdua d’impressions en els últims 30 dies. Aquestes són les pàgines on intervenir primer. Verifica el seu status code, la seva canonical i la seva presència al sitemap.
No facis canvis massius sense dades. La reacció instintiva davant d’una caiguda de trànsit és intervenir agressivament: canviar estructures, afegir contingut, modificar redireccions. Cada canvi addicional afegeix més variabilitat al sistema ja en procés d’estabilització. Actua només quan tinguis evidència clara d’un problema específic.
Si el trànsit continua caient després de la setmana 8 sense senyals de recuperació, considera fer un crawl de comparació entre la plataforma antiga (si mantens accés) i la nova per identificar diferències estructurals que no havies detectat. Considera també si la nova plataforma té problemes de rendering JavaScript que poden estar impedint que Google processi el contingut correctament.
Pots revisar també les implicacions de contingut duplicat entre URLs que pot haver generat la migració al recurs sobre contingut duplicat en ecommerce, ja que les migracions són un dels principals moments on s’introdueix aquest tipus de problema.
Migrar una plataforma d’ecommerce amb zero pèrdua de trànsit orgànic és possible. No és la norma, però és assolible amb preparació suficient i un protocol d’execució disciplinat. La diferència entre les migracions que surten bé i les que no, en la majoria dels casos, no és tècnica: és de planificació i de temps dedicat a la fase de preparació.
El mapatge d’URLs complet abans de tocar res, el testing exhaustiu en staging, el protocol de llançament ordenat i el monitoratge diari durant els primers 60 dies són les quatre pràctiques que més consistentment separen les migracions exitoses de les fallides. Cap de les quatre és difícil d’implementar. Totes requereixen temps i atenció que molts equips no assignen perquè estan enfocats a llançar com aviat millor.
En la planificació d’una migració, el temps que sembla excessiu per a la fase de preparació sol resultar ser exactament el necessari quan apareixen els problemes reals. I sempre apareixen.
Per completar l’estratègia tècnica d’ecommerce, la guia de SEO tècnic per a botigues en línia proporciona el marc general dins del qual la migració de plataforma és una intervenció específica.
Preguntes freqüents sobre migracio plataforma ecommerce SEO
Quan és el millor moment per migrar una botiga en línia?
El millor moment és durant un període de baixa estacionalitat per al teu negoci. Per a moda, després de rebaixes; per a joguines, després de Nadal. Evita migrar en Black Friday, Nadal o qualsevol pic de vendes. Necessites almenys 4-6 setmanes de preparació abans de la migració i 4-8 setmanes de monitoratge posterior. Un període total de 3 mesos amb trànsit reduït és l'escenari més segur.
He de canviar les URLs durant una migració?
L'ideal és mantenir exactament les mateixes URLs. Cada URL que canvia necessita una redirecció 301, i com més redireccions, major risc d'errors. Si el canvi d'URLs és inevitable (perquè la nova plataforma usa una estructura diferent), mapeja TOTES les URLs antigues a les noves abans de llançar. Un ecommerce amb 10.000 productes pot tenir 30.000+ URLs incloent variants, categories i filtres.
Quines eines necessito per monitorar una migració?
Les tres eines indispensables són: Google Search Console per monitorar indexació, errors de rastreig i pèrdua d'impressions; Screaming Frog per fer un crawl complet pre i post-migració comparant URLs, status codes i canonical tags; i una eina de seguiment de posicions (Semrush, Ahrefs o Sistrix) per seguir l'evolució diària de les teves keywords principals durant els primers 60 dies.
Puc migrar per fases en lloc de tot alhora?
Les migracions per fases són possibles però més complexes tècnicament. Requereixen que ambdues plataformes funcionin simultàniament amb un proxy invers que dirigeixi el trànsit a una o l'altra segons la URL. És una opció per a ecommerce amb més de 50.000 productes on una migració total té massa risc. L'inconvenient és que la fase de coexistència genera complexitat en canonical tags, sitemaps i anàlisi de dades.