Migració web i SEO: guia per no perdre trànsit | Ighenatt

El 40% de les migracions web generen caigudes de trànsit orgànic que superen el mes de durada. En els casos més greus, llocs amb anys de posicionament acumulat perden entre el 50% i el 80% de la seva visibilitat en qüestió de setmanes. El pitjor és que en la majoria d’aquests casos la causa no és un canvi d’algoritme de Google ni una penalització manual: és simplement la manca de planificació SEO abans de prémer el botó de publicar. Aquesta guia t’explica com evitar-ho.

Per què les migracions web són el risc SEO més subestimat

Una migració web és qualsevol canvi que altera la forma en què Google rastreja, indexa o percep les URLs del teu lloc. El problema és que els equips de desenvolupament i disseny sovint tracten una migració com un projecte tècnic pur — i ho és — però ignoren que Google ha construït un model de confiança sobre les URLs existents durant mesos o anys. Quan aquestes URLs canvien sense la senyalització correcta, aquest capital s’evapora.

Segons dades agregades d’Ahrefs sobre centenars de migracions analitzades, els llocs que no implementen un pla SEO abans de migrar perden entre el 20% i el 80% del seu trànsit orgànic. La recuperació, fins i tot en casos ben executats, porta entre 3 i 6 mesos tal com reconeix el propi Google Search Central. Per a llocs mitjans, Google indica que pot trigar “unes quantes setmanes” que la majoria de pàgines s’actualitzin a l’índex, i en llocs grans pot trigar fins i tot més.

Els tres tipus de migració més habituals, i els seus riscos específics:

Canvi de domini. És la migració de major impacte. Google transfereix l’autoritat acumulada al nou domini a través de les redireccions 301, però el procés no és immediat. Sense l’ús correcte de l’eina de canvi d’adreça a Google Search Console, el procés s’alenteix significativament.

Canvi d’estructura d’URLs. Els redissenys que alteren la jerarquia de directoris, eliminen slugs descriptius o canvien el patró d’URLs són l’origen més freqüent d’errors 404 massius. Una botiga que passa de /categoria/nom-producte/ a /p/12345/ sense mapejar redireccions destrueix tot el link equity de les seves pàgines de producte.

Migració a HTTPS. Tot i que Google recomana HTTPS, la migració mal executada genera contingut mixt (recursos HTTP en pàgines HTTPS), certificats mal configurats i cadenes de redireccions que acumulen latència. És el tipus de migració que els equips tècnics subestimen més perquè sembla simple.

La diferència crítica entre una migració “tècnica” i una “SEO”: la tècnica es considera completada quan el nou lloc funciona. La SEO es considera completada quan el nou lloc manté — o supera — el trànsit orgànic de l’anterior.

Llista de verificació pre-migració: abans de tocar res

El treball més important de tota la migració es produeix setmanes abans del dia del llançament. Sense dades de referència, no pots saber si la migració va tenir èxit ni detectar el que s’ha trencat.

1. Inventari complet d’URLs actuals. Usa Screaming Frog per rastrejar el lloc complet i exportar totes les URLs que retornen el codi 200. Filtra per tipus de contingut: pàgines, publicacions, categories, productes, imatges. Desa el fitxer; és la teva referència absoluta.

2. Identificar les URLs de major valor. Obre Google Search Console i exporta l’informe de rendiment filtrat pels darrers 3 mesos. Ordena per clics. Les 50-100 URLs amb més trànsit són la teva prioritat absoluta: han de tenir redirecció 301 correcta sense excepció.

Complementa amb Ahrefs o Semrush per identificar les URLs amb major nombre de backlinks externs. Una pàgina amb 200 backlinks perduda en la migració suposa una pèrdua de link equity que pot trigar anys a recuperar-se.

3. Captura la línia base de posicions. Exporta un snapshot de les posicions actuals a GSC: paraules clau, posició mitjana, impressions i clics. Aquest document és la teva mesura d’èxit post-migració. Sense ell, no pots demostrar si la recuperació és completa.

4. Verifica el sitemap i el robots.txt actuals. Descarrega i revisa ambdós fitxers. Assegura’t que el sitemap inclou totes les URLs importants i que robots.txt no bloqueja seccions que haurien d’estar indexades. Documenta la configuració actual: necessitaràs replicar-la correctament al nou lloc.

5. Inventari de backlinks externs. Exporta la llista de backlinks des d’Ahrefs o Search Console. Identifica els 20-30 dominis que més enlaçen al teu lloc. Després de la migració, considera contactar els més rellevants per demanar-los que actualitzin els seus enllaços a les noves URLs — tot i que amb les redireccions correctes no és imprescindible, elimina un salt de redirecció per a aquestes pàgines.

L’article sobre auditoria SEO tècnica cobreix la revisió de l’estat actual com a primer pas abans de qualsevol migració.

El mapa de redireccions: com planificar-lo correctament

El mapa de redireccions és un document que relaciona cada URL antiga amb el seu equivalent nou. No és opcional. És el nucli de tota la migració SEO.

Plantilla de mapeig recomanada:

Columna per columna: la URL antiga és la que apareix al rastreig de Screaming Frog i als informes de GSC. La URL nova és el seu equivalent al nou lloc. El codi de redirecció (301 per a permanent, 410 per a pàgines que desapareixen definitivament). L’estat d’implementació i verificació.

La regla de l’1:1. Cada URL antiga ha d’apuntar a exactament una URL nova. Mai facis una redirecció de múltiples URLs antigues a la pàgina d’inici — Google tracta això com un soft 404 i no transmet el link equity. Si una pàgina antiga no té un equivalent directe, busca la pàgina del nou lloc que més s’aproximi temàticament.

Casos especials que requereixen atenció:

Paginació. Les URLs de paginació (/blog/page/2/) generalment no necessiten redirecció si l’estructura nova manté la mateixa lògica. Si canvia, mapeja-les a la primera pàgina de cada secció.

Paràmetres d’URL. Molts llocs tenen URLs amb paràmetres de seguiment o filtres: ?utm_source=, ?color=vermell. Defineix a GSC quins paràmetres Google pot ignorar per evitar contingut duplicat. No necessiten redirecció individual.

Facetes del comerç electrònic. Les URLs de filtres en botigues en línia (/sabatilles/?talla=42&color=negre) representen un cas complex. Si el nou lloc usa la mateixa estructura de facetes, no necessiten mapeig. Si canvia l’arquitectura de filtres, consulta un especialista SEO abans de procedir.

Pàgines que desapareixen. Si una pàgina no té un equivalent raonable al nou lloc, usa un codi 410 (Gone) en lloc de redirigir a una pàgina genèrica. El 410 indica a Google que la pàgina s’ha eliminat intencionalment i que deixi de rastrejar-la, la qual cosa és més net que una redirecció irrellevant.

Implementació tècnica de les redireccions 301

Un cop tens el mapa de redireccions complet i verificat, la implementació varia segons la tecnologia del servidor.

Apache (.htaccess). L’opció més habitual en hostings compartits. Les regles de redirecció s’escriuen directament al fitxer .htaccess:

Redirect 301 /pagina-antiga/ https://eltudomini.es/pagina-nova/

Per a redireccions massives amb patrons, usa mod_rewrite:

RewriteRule ^categoria-antiga/(.*)$ /categoria-nova/$1 [R=301,L]

Nginx (nginx.conf). En servidors VPS o dedicats amb Nginx, les redireccions van al bloc server:

return 301 https://eltudomini.es/pagina-nova/;

CMS (WordPress, Shopify, etc.). Connectors com Redirection (WordPress) o la gestió nativa de redireccions a Shopify permeten implementar el mapa sense accés al servidor. Són més lents que les redireccions a nivell de servidor però vàlids per a la majoria de llocs.

Errors d’implementació més freqüents:

Cadenes de redireccions. Si la URL A redirigeix a B, i B redirigeix a C, Googlebot ha de fer dues peticions extra. Google tolera cadenes de fins a 5 salts, però cada salt addicional afegeix latència i pot perdre una mica d’autoritat. Abans del llançament, usa Screaming Frog en mode “Follow redirects” per detectar cadenes i curtcircuitar-les.

Bucles de redirecció. A redirigeix a B, B redirigeix a A. Screaming Frog els detecta com a errors vermells. Solen ocórrer en implementacions de .htaccess amb regles que es contradiuen.

Redireccions que apunten a 404. La redirecció existeix, però la URL de destí retorna 404. És més perjudicial que no tenir redirecció perquè Google arriba a la nova URL i troba un error. Verifica totes les URLs de destí abans del llançament.

Els llocs amb múltiples versions d’idioma tenen una capa addicional: la implementació de hreflang tracta aquest cas amb detall.

El dia del llançament: protocol de validació

El llançament no és el moment d’improvisar. Tingues preparada aquesta llista de verificació de 10 punts i executa-la en ordre:

1. Verificar que robots.txt no bloqueja la indexació. L’error més catastròfic i freqüent: el nou lloc es va llançar amb Disallow: / a robots.txt — una mesura habitual en entorns de proves que algú va oblidar revertir. Comprova-ho a eltudomini.es/robots.txt abans de qualsevol altra acció.

2. Confirmar que les etiquetes noindex s’han eliminat. Similar al punt anterior: revisa amb Screaming Frog que cap pàgina important té <meta name="robots" content="noindex">.

3. Verificar una mostra de 20 redireccions crítiques. Comprova manualment les 20 URLs amb més trànsit de la línia base. Usa una eina de comprovació de capçaleres HTTP per confirmar que retornen 301 i que el destí és correcte.

4. Confirmar que no hi ha bucles de redirecció. Llança un rastreig ràpid amb Screaming Frog sobre les URLs principals.

5. Verificar el certificat SSL. Si és una migració a HTTPS, comprova que el certificat és vàlid per al domini principal i als subdominis que usis.

6. Detectar contingut mixt. Amb la consola del navegador (F12 → Console) obre les pàgines principals i verifica que no hi ha recursos carregant per HTTP en pàgines HTTPS.

7. Enviar el sitemap actualitzat a GSC. Ves a Search Console → Sitemaps → envia la nova URL del sitemap. Si el domini ha canviat, fes-ho des de la propietat del nou domini.

8. Usar l’eina de canvi d’adreça (sols si canvies de domini). A GSC → Configuració → Canvi d’adreça. Sols vàlid per a canvis de domini complets, no per a canvis d’estructura d’URLs dins del mateix domini.

9. Sol·licitar la indexació de les pàgines principals. Usa l’eina d’inspecció d’URLs a GSC per sol·licitar la indexació de la teva pàgina d’inici, les pàgines de serveis principals i les publicacions més importants.

10. Monitoritzar errors en temps real durant les primeres 4 hores. Tingues obert l’informe de cobertura de GSC i els registres del servidor. Els primers problemes solen aparèixer en les hores posteriors al llançament.

Monitorització post-migració: els 90 dies crítics

La feina no acaba el dia del llançament. La major part dels problemes d’una migració es detecten en les setmanes posteriors, no en el moment del llançament.

Setmana 1-2: errors 404 i redireccions trencades. Googlebot comença a rastrejar el nou lloc immediatament. Els errors 404 apareixen a l’informe “Pàgines no trobades” de GSC. Revisa-ho diàriament durant la primera setmana. Qualsevol URL amb trànsit històric que aparegui com a 404 necessita una redirecció urgent.

Configura una alerta a Google Search Console per rebre notificacions de nous errors de rastreig. També activa alertes de caiguda brusca de sessions a Google Analytics 4 (Informes → Alertes personalitzades).

Setmana 3-4: problemes d’indexació a l’informe de Cobertura. A partir de la tercera setmana, l’informe de cobertura de GSC comença a reflectir l’estat real del nou lloc. Problemes freqüents en aquesta fase: pàgines marcades com “Descoberta, actualment no indexada” (Google les ha trobat però encara no les ha processades), pàgines amb canonical incorrecte, i duplicats detectats.

Compara el nombre total de pàgines indexades amb la línia base anterior a la migració. Una caiguda del 15-20% pot ser temporal (Google encara re-processant); una caiguda del 50%+ requereix investigació immediata.

Mes 2: recuperació de posicions. Compara l’informe de rendiment de GSC amb la línia base de posicions que vas capturar abans de migrar. Identifica paraules clau que han perdut més de 5 posicions. Per a cadascuna, verifica que la URL corresponent estigui correctament indexada i que la redirecció del contingut equivalent antic funcioni.

Un lloc ben migrat hauria de recuperar el 80-90% de les seves posicions originals al final del segon mes. Si la recuperació és menor, revisa si hi ha problemes de canonical entre les URLs antigues (encara rebent trànsit de backlinks) i les noves.

Mes 3: anàlisi de backlinks recuperats vs perduts. Amb Ahrefs o Semrush, compara el perfil de backlinks actual amb l’anterior a la migració. Els backlinks que apunten a les URLs antigues continuaran passant autoritat sempre que les redireccions 301 estiguin actives — Google recomana mantenir les redireccions almenys un any. Els backlinks “perduts” (els que apuntaven a pàgines que ara retornen 404) són els que necessites recuperar contactant els dominis que enlaçen.

L’article sobre què és el SEO tècnic explica els fonaments que fan possible una migració sense pèrdues de visibilitat.

El cas de la migració fallida: què aprendre

El patró més comú que veiem en migracions amb pèrdues severes de trànsit segueix sempre la mateixa estructura. Un negoci amb 3-5 anys de presència web decideix renovar completament la seva imatge i tecnologia. El projecte es gestiona com un projecte de disseny i desenvolupament: nou CMS, nova arquitectura visual, nou sistema d’URLs més “net”. El SEO no entra a la conversa fins que el nou web està llest per publicar-se.

El dia del llançament, el nou web és impecable visualment. Però en les 3 setmanes següents, el trànsit orgànic cau un 60%. La investigació revela tres errors simultanis: les URLs de bloc van passar de /blog/titol-de-la-publicacio/ a /noticies/2024/titol-de-la-publicacio/ sense cap redirecció, les pàgines de serveis van canviar d’estructura completament i tampoc no tenen redireccions, i el robots.txt del nou servidor va bloquejar la indexació durant 5 dies perquè ningú no ho va verificar després del llançament.

La recuperació va durar 8 mesos. Amb un pla SEO previ, hauria trigat 6-8 setmanes.

Els tres errors que es repeteixen sempre:

Primer, tractar el SEO com una capa que s’aplica després, no com una restricció de disseny. Les decisions d’arquitectura d’URLs s’han de consultar amb el SEO abans que el desenvolupament estigui avançat, no el dia abans del llançament.

Segon, no tenir dades de referència. Sense el rastreig previ, sense la línia base de posicions, sense l’inventari de backlinks, no pots mesurar l’impacte ni prioritzar la recuperació.

Tercer, no assignar responsabilitat de monitorització post-llançament. La migració “acaba” el dia de publicació per a l’equip de desenvolupament, però per al SEO comença aquell dia. Algú ha de revisar GSC diàriament durant les primeres 4 setmanes.

Amb la preparació correcta, una migració web és una oportunitat: netejar l’arquitectura d’URLs, eliminar contingut duplicat, millorar l’estructura d’enllaçament intern. Els llocs que migren amb planificació SEO no sols preserven el seu trànsit — sovint el superen en 6-12 mesos.

Si estàs planificant una migració web i vols assegurar-te que no perds el posicionament que has construït, el nostre servei de migració SEO inclou auditoria pre-migració, mapeig complet de redireccions, validació tècnica en proves i monitorització intensiva durant els 90 dies posteriors al llançament.