@isotopia ha detto in Piano di migrazione e-commerce:

na volta racc

Se le migliaia di pagine si riferiscono ai codici li potrebbe essere sensato fare alla stessa maniera..
Mi è capitato di avere siti "vecchi" che portavano con se gli identificativi nelle url... e li è più semplice... lo fai in base al formato della pagina precedente...

Per pagine interne come blog o altro... beh li armati di pazienza... e ricorda ci controllare eventuali link interni inseriti a manina dal cliente... lavoraccio

@isotopia per incrocio url one to one che intendi?
Se hai 1000 url vecchie e sai già come diventano in quelle nuove, ti fai 1000 righe in htaccess e sei a posto ( più o meno ) , parli del fatto che dovresti scriverti una a una le righe e vorresti automatizzare ? E come sono le url vecchie e nuove ? Cambiano gli slug ? Cambiano le directory ?

@shazarak ma stiamo scherzando? 1000 righe di htaccess?
io non lo farei MAI in htaccess... deve essere gestibile.. quindi se proprio devo lo faccio su db con chiave indicizzata...
Premetto che se conosci un metodo di rapporto tra vecchio e nuovo ti conviene usare quello.... poi vorrei capire meglio cosa avevi prima e dove vuoi portarlo... comunque ripeto NO su htaccess (premesso che tu stia lavorando in php e apache)

@mirkomassarutto potresti spiegare a me e a chi non ne ha idea il motivo per cui non dovresti mettere 1000 righe di redirect in htacces?

In ogni caso chiedevo che tipo di differenze negli c’erano perché in realtà se cambia tipo solo un folder più che 1000 righe di redirect bastano due o tre regole in regex

Edit: se può interessare parlando di 1000 redirect 1:1 io mi basavo su informazioni di questo tipo https://www.seomike.com/blog/how-many-htaccess-redirects-are-too-many/

Edit 2: qui spiega meglio l’impatto non solo su ttfb ma anche su risorse server https://strategiq.co/does-the-number-of-htaccess-rules-impact-performance-and-scalability/

Personalmente, forse mi sono espresso male. Io non metterei 1000 righe 1:1 su htacces ma avrei prima pensato alla nuova struttura url in modo tale da potermela cavare con semplici regex. E se proprio dovessi mettere 1000 righe, suppongo che le terrei per tot mesi, una volta verificato che tutto é migrato bene indicizzazione compresa, li toglierei e lascerei solo quelli eventualmente che ricevono ancora link da siti esterni.

Ciao @shazarak .. premesso che, come avevo già detto, cercerei una regola e quindi risolverei con un regex, ti spiego perché 1000 righe su htaccess non mi piace.
Innanzitutto andrei ad appesantire il file di configurazione e non avrei il vantaggio di "monitorare" i 301.

Quello che suggerisco è semplicemente una tabella nel db del tipo:

urlPrecedente	urlNuova	ultimoAccesso

in questa indicizzi la prima colonna così da aumentare la performance nella query

1. ad accesso pagina, controlli se url richiesta è presente nel db
2. se presente aggiorni la colonna dell'ultimo ingresso ed effettui il redirect

Questo ti permette sia di fare il redirect che di monitorare se hai delle richieste alla url ancora attive.. poi vabbé io gestisco in altra tabella anche ip e provenienze (semplice insert) così ho sotto mano tutte le url che magari prima mi ero perso per altri motivi.

Insomma cerco di gestire la cosa con meno hardcoding possibile... altrimenti sei sempre li a mettere mano al file di configurazione

@mirkomassarutto direi che siamo d’accordo sul usare i regex!
in ogni caso ho sbagliato a nominare htaccess perché forse non é ciò che aveva chiesto @isotopia e manda off topic l’argomento

@shazarak In effetti nel mio caso htaccess non c'entra, la mia domanda si riferisce al lavoro da fare prima della migrazione vera e propria, ossia il piano: un semplice file excel in cui si danno le indicazioni al programmatore sui redirect che si andranno ad applicare per far sì che le pagine del vecchio sito puntino tutte alle corrispondenti pagine del nuovo sito. Tali pagine sono appunto un migliaio e le URL di origine (es: www.dominio.it/vecchia_URL-2.php sono completamente diverse dalle nuove URL (es: www.dominio.it/nuovaURLSEO. Dalle URL non si riesce a ricondurre il contenuto della pagine (es: codice prodotto), pertanto l'unica è: prendersi manualmente ciascuna URL del vecchio, aprire la pagina nel browser, guardarla, cercare la corrispondente pagina nel nuovo (es: la stessa scheda prodotto) e segnarla nella riga corrispondente nel file. Moltiplicato per 1.000, diventa un lavoro lunghissimo (per quanto sia molto semplice). Ecco mi chiedevo se qualcuno ha qualche idea migliore per evitare tale lungaggine.

@isotopia perdonami.... ma dal sistema vecchio con url vecchia_url in qualche maniera prendi il prodotto con codice XXX
a questo punto ti dovrebbe bastare fare un incrocio con i due db... il codice è l'elemento che ti permette di fare il confronto.

p.s. ricorda che poi avrai altri url in giro... che magari non cogli al volo...

io normalmente guardo:

1. Sitemap
2. Search Console
3. Google SERP
   ... e non dimentarti bing e soci

per quello poi suggerisco un sistema che monitori da dove arrivano i link "non validi"....

@isotopia non capisco come non si possa riconoscere un prodotto dalla sua url, in ogni caso puoi usare tool come screaming frog , fare una scansione completa di entrambi i siti , scaricarti le liste in excel e confrontare direttamente, trovare pattern, regex eccc. senza dover aprire una per una 1000 pagine. oppure come dice @mirkomassarutto lavori su database

@shazarak D'accordo, ma purtroppo non sempre si riconosce il prodotto dall'URL e purtroppo non sempre si ha la possibilità di lavorare avendo accesso al database... almeno dalla mia esperienza.

Allora, anche a me è capitato di partire con un ecommerce con oltre 5000 pagine tutte in HTML...
Li fai un bel grabbing ed in base al contenuto vai a comprendere il riferimento prodotto...

Domanda ma le pagine nuove... sei partito da zero a farle o dai contenuti precedenti...

@mirkomassarutto Grazie, cosa intendi per "grabbing" ? Le nuove pagine hanno esattamente lo stesso contenuto delle vecchie, almeno per quanto riguarda le schede prodotto.

@isotopia scusa ma sono curioso, può essere che tu intenda situazioni tipo questa?

sito.com/2445743.html
sito.com/f4323hasg.html
ecc

che diventano
sito.com/nome-prodotto-1/
sito.com/nome-prodotto-2/
ecc

è per motivi del genere che ti serve aprire la pagina vecchia per vedere di che prodotto si parla?
perche io , sbagliando, ragiono dando per scontato che le vecchie url abbiano i nome dei prodotti , e @mirkomassarutto mi fa giustamente notare che non è detto !

@shazarak Esatto, mi riferisco a casi come questi (che capitano). Se non apro la pagina non capisco dall'URL di che prodotto si tratta.

@isotopia azz che rogna queste vecchie url hanno le info a database ? Puoi tipo esportare dal db la lista prodotti con qualche info tipo nome de prodotto ? Così magari faciliti l’associazione coi prodotti nuovi

@shazarak Purtroppo è anche uno di quei casi in cui non ho accesso al database...

@isotopia e che Ciapet

@isotopia beh se non hai accesso al db.... all'interno della pagina vecchia è presente il codice prodotto? .. sempre il grabbing può aiutare....

@mirkomassarutto concordo, cerca almeno di recuperare il nome del prodotto dal meta title o dalla description o dall' h1 ecc