Quando Magento 2.4 ha reso Elasticsearch un requisito e ha rimosso il vecchio motore MySQL, per molti merchant è cambiato poco nella pratica quotidiana e moltissimo nel modo di gestire l’infrastruttura. La ricerca interna, che prima era un componente che “funzionava e basta”, è diventata un servizio a sé, con il suo sizing, il suo hosting, il suo tuning. Nei progetti che ho seguito nell’ultimo anno questo passaggio ha prodotto due reazioni opposte: chi lo ha vissuto come una scocciatura tecnica da delegare, e chi ha capito che aveva finalmente in mano una leva vera sulla conversione. Io sto con i secondi, e provo a spiegare perché.
Cosa cambia davvero con Elasticsearch obbligatorio
Il punto che ripeto sempre ai team è questo: con Magento 2.4 la ricerca non è più una feature, è un servizio da gestire. Prima potevi ignorarla e sopravvivere. Ora hai un cluster Elasticsearch che vive accanto al database, va monitorato, dimensionato e mantenuto in versione compatibile. Non è un dettaglio: è un secondo datastore con la sua salute da presidiare.
La buona notizia è che, una volta accettato questo, la qualità della search fa un salto. Il motore gestisce meglio i typo, la rilevanza è configurabile, il faceting è più solido. Ma niente di tutto questo arriva “di default”. Arriva se qualcuno lo configura con la testa.
Sizing e hosting del cluster: dove si sbaglia di più
Il primo errore che vedo, e lo vedo spesso, è trattare Elasticsearch come un processo qualsiasi da schiacciare sulla stessa macchina di PHP e MySQL. Su un catalogo piccolo regge; su un catalogo serio, con reindicizzazioni notturne e picchi di traffico, il cluster va in sofferenza proprio quando serve di più. La mia regola è semplice: Elasticsearch va su nodi dedicati, con RAM sufficiente perché la JVM heap non superi circa metà della memoria disponibile e comunque resti sotto i ~31 GB. Sopra quella soglia si perde l’ottimizzazione dei compressed object pointer e si paga senza guadagnare.
Sull’hosting il ragionamento è di rischio, non di moda. Un cluster gestito (un managed Elasticsearch) ti toglie il peso di aggiornamenti, snapshot e failover, ma ti lega a un fornitore e a una versione. Il self-managed ti dà controllo pieno e costa di più in ore-uomo. Nei progetti mid-market di solito consiglio il gestito: non perché sia “meglio” in assoluto, ma perché il tempo del team è meglio speso sul relevance tuning che sul babysitting del cluster. Un errore che ho corretto più di una volta: single node in produzione “tanto è solo la ricerca”. No. Se quel nodo cade, la ricerca su store cade, e su alcuni template cade l’intera categoria. Almeno un minimo di ridondanza va messa in conto.
Sinonimi e stopword: il lavoro noioso che sposta i numeri
Qui viene la parte che quasi nessuno fa bene, e che secondo me vale più di mille micro-ottimizzazioni sul frontend. La configurazione di sinonimi e stopword è il modo più economico per ridurre le ricerche a zero risultati. Ho seguito un merchant fashion di fascia mid-market in cui un catalogo enorme perdeva vendite banalmente perché “sneakers” e “scarpe da ginnastica” erano due mondi separati: chi cercava un termine non vedeva metà dell’assortimento. Mezza giornata di lavoro sul dizionario dei sinonimi, e le ricerche senza risultati sono scese in modo netto.
Il metodo che uso è sempre lo stesso, e parte dai dati veri: si prende il report delle ricerche interne, si isolano i termini più cercati che restituiscono zero o pochissimi risultati, e su quelli si costruisce il vocabolario. Non si inventano sinonimi a tavolino. Le stopword vanno gestite in base alla lingua, con attenzione: rimuovere parole “inutili” è comodo, ma se togli un termine che nel tuo dominio è rilevante (pensa a una taglia, a un modello, a una sigla) fai danni. È lavoro artigianale, poco glamour, e proprio per questo viene sistematicamente rimandato.
Relevance tuning e faceting
Sul relevance tuning il mio consiglio è di non innamorarsi dei boost. Magento consente di pesare gli attributi nella search relevance, ed è tentante alzare a manetta il peso del nome prodotto o della categoria. Il risultato, quasi sempre, è una rilevanza sbilanciata che premia i prodotti sbagliati. Preferisco partire dai default, misurare, e intervenire su pochi attributi con incrementi piccoli. Il tuning della ricerca è iterativo: si cambia una cosa, si guarda l’effetto sui termini reali, si aggiusta.
Sul faceting (i filtri per attributo nelle liste) l’errore ricorrente è mostrare troppi filtri, o filtri con cardinalità enorme. Trenta colori in un menù a tendina non aiutano nessuno a decidere. I facet vanno curati come parte della UX di ricerca, non lasciati generare automaticamente da ogni attributo filtrabile. E vanno tenuti d’occhio lato performance: un attributo con troppa cardinalità in layered navigation pesa sulle query.
L’impatto sulla conversione: perché me ne occupo io e non lo delego
Chiudo con la ragione per cui insisto tanto su questo tema. Chi usa la ricerca interna converte a un tasso sensibilmente più alto della media del sito: è un utente che ha già espresso un’intenzione precisa. Trattare la search come un dettaglio infrastrutturale significa lasciare sul tavolo proprio i visitatori più vicini all’acquisto. Nei progetti dove abbiamo lavorato sul dizionario e sul relevance tuning, il segnale più chiaro è stato il calo delle ricerche a zero risultati accompagnato da un aumento del tasso di conversione da search. Non serve un progetto trimestrale: servono i dati delle ricerche interne e un po’ di disciplina nel leggerli.
La mia posizione, netta: l’obbligo di Elasticsearch in Magento 2.4 non è un costo imposto, è un’occasione. Chi lo tratta come un adempimento IT paga la complessità senza incassare il vantaggio. Chi lo tratta come parte dell’esperienza d’acquisto trasforma un requisito tecnico in punti di conversione.
Domande frequenti
Elasticsearch è davvero obbligatorio su Magento 2.4?
Sì. Con Magento 2.4 il motore di ricerca MySQL è stato rimosso ed Elasticsearch è diventato un requisito dell’installazione, sia su Magento Open Source sia su Magento Commerce. La ricerca del catalogo non funziona senza un cluster attivo e compatibile.
Posso installare Elasticsearch sullo stesso server di Magento?
Tecnicamente sì su cataloghi piccoli, ma lo sconsiglio in produzione seria. Elasticsearch è un servizio con esigenze di RAM proprie e va idealmente su nodi dedicati, così le reindicizzazioni e i picchi di traffico non entrano in competizione con PHP e MySQL.
Qual è l’intervento con il miglior ritorno sulla ricerca?
Nella mia esperienza, la configurazione di sinonimi e stopword a partire dal report delle ricerche interne. È il modo più economico per abbattere le ricerche a zero risultati e recuperare vendite già a portata di mano.
Meglio un Elasticsearch gestito o self-managed?
Dipende dalle ore che il team può dedicare all’infrastruttura. Per i merchant mid-market di solito preferisco un servizio gestito: costa qualcosa in più ma libera tempo per il relevance tuning, che è dove si genera valore.
Fabio Canovi è esperto di Magento e Adobe Commerce e tra i primi professionisti in Italia certificati Adobe Commerce. Progetta e gestisce soluzioni e-commerce enterprise, con un focus particolare su performance, ricerca e conversione per merchant mid-market.