Immagini prodotto sparite o rotte su PrestaShop: diagnosi e rigenerazione

In sintesi

Guida completa su immagini prodotto rotte prestashop per proprietari di e-commerce PrestaShop.

Le immagini prodotto rotte su PrestaShop derivano quasi sempre da tre cause specifiche: regole di riscrittura URL saltate nel file .htaccess, permessi errati sui file della cartella /img/p/ (CHMOD diverso da 755/644) oppure un blocco per timeout PHP durante la rigenerazione delle miniature. Per ripristinare il catalogo senza fermare le vendite occorre testare la risposta HTTP del server, verificare la presenza fisica dei file via FTP o SSH e rigenerare i formati mancanti un blocco alla volta.

Immagini prodotto rotte su PrestaShop: diagnosi rapida e guida al ripristino

Apri il tuo negozio online la mattina e trovi un punto interrogativo grigio al posto della foto principale del tuo prodotto di punta. Il discorso qual è? È come entrare in una boutique in centro, trovare le vetrine oscurate e pretendere che i passanti entrino comunque a comprare a scatola chiusa.

Nessuno compra un prodotto che non può guardare. Quando le foto spariscono dal catalogo, il tasso di conversione non rallenta: crolla a picco all'istante. Se mandi traffico a pagamento con Meta Ads o Google Shopping, stai pagando click per far atterrare le persone su pagine cieche. Butti via soldi ogni singolo minuto che passa.

Non ti dico che sistemare il problema sia banale su cataloghi da diecimila prodotti, ma ti dico che nella maggior parte dei casi l'origine del guasto è precisa e misurabile. In questa guida analizziamo i passaggi tecnici per individuare il problema ed eseguire il ripristino in totale sicurezza, senza rischiare di cancellare il database.

Perché le immagini dei prodotti non si vedono più su PrestaShop?

Le immagini non si vedono più perché il server web non riesce a recapitare il file fisico richiesto dal browser a partire dal link registrato nel database. Nella maggior parte dei casi il file esiste ancora sul disco fisso, ma un'interruzione nella catena di puntamento impedisce al sistema di mostrarlo all'utente finale.

Cosa accade sotto il cofano di PrestaShop? La piattaforma gestisce le immagini in modo disaccoppiato. Nel database MySQL c'è una tabella chiamata ps_image che associa l'ID del prodotto a un ID immagine progressivo. Sul server, invece, i file non si chiamano come il prodotto, ma seguono una struttura ad albero dentro la directory /img/p/.

Prendiamo un caso pratico. Un'immagine con ID 1234 non si troverà in una cartella generica. Si troverà nel percorso fisico /img/p/1/2/3/4/1234.jpg. Se il web server si perde tra questa cartella e il link che mostra al visitatore, la foto scompare.

Ci sono due situazioni completamente diverse che devi imparare a distinguere subito:

L'icona dell'immagine spezzata (errore 404): Il browser cerca il file a un indirizzo web specifico, ma il server risponde che lì non c'è nulla. Questo indica quasi sempre un problema di riscrittura URL o file fisicamente assenti.
Il punto interrogativo o l'immagine di default: PrestaShop sa che dovrebbe esserci un'immagine, ma non trova il formato generato corretto per quel punto della pagina (come il formato miniatura o quello della scheda prodotto).

Perché ti dico questo? Perché prima di toccare qualsiasi configurazione devi capire in quale dei due scenari ti trovi. Nei negozi che seguo vedo spesso titolari che passano ore a cancellare la cache del browser, quando invece il server restituisce un errore di autorizzazione sul file system.

Se vuoi approfondire la gestione della piattaforma prima di compiere manovre invasive, ti consiglio di consultare la nostra guida per ottimizzare la gestione di PrestaShop senza commettere errori strutturali.

Come verificare se l'errore dipende dal file .htaccess o dai link riscritti?

Per capire se la causa è il file .htaccess basta aprire gli strumenti per sviluppatori del browser (tasto F12 su Chrome o Firefox), ricaricare la scheda prodotto e guardare la scheda "Network" (Rete). Se i percorsi delle immagini mostrano un codice HTTP 404 Not Found, la riscrittura delle URL amichevoli ha smesso di funzionare.

PrestaShop utilizza le cosiddette Friendly URL. All'utente mostra un link pulito, ad esempio iltuonegizio.it/1234-large_default/nome-scarpa.jpg. Questo file, con questo nome specifico, nella realtà non esiste sul server web. È il file .htaccess su server Apache che prende quella richiesta fittizia e la traduce istantaneamente nel percorso reale dentro /img/p/.

Se il file .htaccess viene corrotto da un modulo malfunzionante o da un salvataggio errato, quella traduzione si rompe. Il server cerca davvero un file che si chiama letteralmente "nome-scarpa.jpg" e, non trovandolo, restituisce un errore 404.

Come verifichi questa ipotesi in meno di un minuto? Segui questi tre passaggi:

Fai clic con il tasto destro sull'immagine mancante e seleziona "Apri immagine in una nuova scheda".
Guarda l'indirizzo nella barra del browser.
Prendi nota dell'ID immagine (il numero che precede il trattino) e verifica via FTP o File Manager del tuo hosting se dentro la cartella /img/p/ esiste la sottocartella numerica corrispondente con i file .jpg al suo interno.

Se i file ci sono sul server ma il browser restituisce 404, il problema è al 100% la riscrittura URL. La soluzione immediata da tentare è la rigenerazione del file .htaccess direttamente dal back-office di PrestaShop:

Accedi al pannello di amministrazione.
Vai su Parametri Negozio > Traffico & SEO.
Scorri fino alla sezione Impostazione URL.
Imposta l'opzione Friendly URL su "NO" e clicca su Salva.
Reimposta l'opzione Friendly URL su "SÌ" e clicca nuovamente su Salva.

Questo semplice passaggio forza PrestaShop a riscrivere da zero l'intero blocco di direttive del server web, riallineando tutte le regole di reindirizzamento delle immagini.

Quali permessi devono avere la cartella img e i file su PrestaShop?

I permessi corretti per consentire al server di leggere e mostrare le immagini sono tassativamente 755 per tutte le cartelle e 644 per tutti i singoli file immagine. Se i permessi scendono a valori più restrittivi, il server web blocca l'accesso alle risorse restituendo un errore HTTP 403 Forbidden.

Che cosa facciamo quando un file ha permessi errati? Il sistema operativo del server (solitamente Linux) considera il server web (come Apache o Nginx) come un utente esterno. Se quell'utente non ha i privilegi di lettura su un file JPG o di esecuzione su una cartella, l'immagine non verrà mai caricata, anche se il percorso è perfetto e il file è integro.

Questo inconveniente si presenta molto spesso dopo aver trasferito un sito tramite FTP, dopo aver scompattato un backup zippato o in seguito a un cambio di hosting provider non eseguito a regola d'arte. L'archivio conserva i permessi dell'utente originario e blocca i nuovi processi.

Se hai accesso al server tramite terminale SSH, puoi correggere l'intera alberatura dei file in una manciata di secondi senza toccare manualmente migliaia di cartelle. Posizionati nella root del tuo e-commerce ed esegui questi due comandi distinti:

find img/ -type d -exec chmod 755 {} \;
find img/ -type f -exec chmod 644 {} \;

Stai mandando solo "ordine ricevuto" e "ordine spedito"?

ZIP con 10 sequenze email pronte: carrello abbandonato, post-acquisto, cliente dormiente, win-back. Copia, incolla, modifica nome — funzionano.

Le email automation banali ti costano il 40% di LTV potenziale. Questa ZIP contiene 10 sequenze copy-paste-ready: 4 carrello abbandonato, 3 post-acquisto, 3 win-back. Costruite su test reali con dati di apertura/click.

Gratuito. Arriva in 30 secondi.

Il primo comando cerca tutte le directory dentro la cartella img/ e assegna loro i permessi 755. Il secondo comando isola esclusivamente i file e imposta il permesso a 644. Non impostare mai 777 su file e cartelle: non serve ad accelerare il lavoro e crea una falla di sicurezza critica che lascia il server vulnerabile ad attacchi informatici esterni.

Oltre ai permessi numerici, verifica l'assegnazione dell'utente e del gruppo proprietario (ownership). Su distribuzioni Linux standard come Debian o Ubuntu, il proprietario deve coincidere con l'utente del server web (spesso www-data), oppure con l'utente associato al tuo profilo su pannelli come cPanel o Plesk.

Se riscontri problematiche più profonde legate alla stabilità del server o a rallentamenti complessivi della macchina, può essere utile leggere la nostra guida su come velocizzare PrestaShop e migliorare i tempi di risposta dell'infrastruttura.

Come rigenerare le miniature su PrestaShop senza mandare in blocco il server (Timeout 504)?

Per rigenerare le miniature senza provocare un errore 504 Gateway Timeout non devi mai selezionare tutti i formati insieme e non devi mai cancellare le immagini precedenti su cataloghi di medie o grandi dimensioni. La procedura corretta prevede di rigenerare un singolo formato per volta, partendo esclusivamente dai prodotti.

Qual è il meccanismo che causa il blocco del server? Ogni volta che chiedi a PrestaShop di rigenerare un'immagine, la libreria grafica di PHP (GD o Imagick) deve leggere l'immagine originale in alta risoluzione, caricarla nella RAM del server, ridimensionarla, comprimerla e salvarla sul disco. Questo calcolo richiede tempo di CPU e consumo di memoria.

Se lanci questo calcolo per 2.000 prodotti moltiplicati per 6 formati ciascuno (miniatura carrello, catalogo, scheda prodotto, zoom, ecc.), stai chiedendo al server di creare 12.000 file in un colpo solo. Il processo sfora il limite di memoria impostato nel PHP (memory_limit) o il tempo massimo di esecuzione (max_execution_time), e il server interrompe brutalmente lo script.

Procedura frazionata dal pannello di controllo (Back-office)

Se non utilizzi la riga di comando, l'unico modo per completare l'operazione in sicurezza è procedere a piccoli blocchi chirurgici:

Accedi al back-office e vai su Aspetto > Immagini.
Scorri fino alla sezione in fondo: Rigenera miniature.
Nel campo Scegli un'immagine seleziona unicamente Prodotti.
Nel campo Seleziona un formato non lasciare "Tutti", ma seleziona un formato specifico (ad esempio home_default).
Attenzione al passaggio critico: all'opzione Cancella le immagini precedenti seleziona rigorosamente NO.
Clicca sul pulsante di rigenerazione.

Perché l'opzione "Cancella le immagini precedenti = NO" ti salva la vita? Se imposti "SÌ", PrestaShop cancella tutte le immagini esistenti sul disco all'istante e poi comincia a crearle. Se il server va in timeout dopo tre minuti, ti ritrovi con le foto cancellate e il processo interrotto a metà. Risultato: il catalogo diventa completamente cieco.

Impostando "NO", lo script controlla se il formato esiste già sul disco: se c'è lo salta, se manca lo crea. Se il server va in blocco, puoi semplicemente rilanciare la pagina finché non ha processato l'intero catalogo senza cancellare ciò che era già pronto.

Rigenerazione avanzata via linea di comando (CLI)

Sui cataloghi con oltre 5.000 referenze, la rigenerazione via browser è un percorso a ostacoli destinato a fallire. In questi scenari è necessario operare direttamente via SSH utilizzando uno script PHP dedicato o l'interfaccia a riga di comando della piattaforma.

Eseguendo l'elaborazione da riga di comando non ci sono limiti di timeout imposti dal server web (come Nginx o Apache). Lo script può lavorare in background per tutto il tempo necessario, processando anche centinaia di migliaia di file senza mai bloccare la navigazione degli utenti attivi sul sito.

Perché le immagini si disallineano o spariscono dopo un aggiornamento di PrestaShop?

Le immagini si disallineano dopo un aggiornamento perché le nuove versioni del tema o del core di PrestaShop modificano spesso i nomi e le proporzioni dei formati grafici standard, oppure perché la struttura di archiviazione dei file nel database non combacia più con quella presente sul disco fisso.

Nel passaggio storico tra le versioni 1.6, 1.7 e le release 8.x di PrestaShop, la nomenclatura dei formati immagine ha subito variazioni. Ad esempio, un vecchio tema utilizzava formati chiamati thickbox_default o medium_default, mentre i temi moderni richiedono spesso formati con proporzioni differenti o denominazioni aggiornate.

Se il tema nuovo cerca il file scarpa-cart_default.jpg ma sul server esiste solo scarpa-small_default.jpg, la foto non viene mostrata e il layout della griglia prodotti salta, lasciando spazi vuoti o elementi disallineati.

È esattamente la situazione che abbiamo dovuto gestire nel caso studio di Valerio Turchiarulo. Dopo un aggiornamento di piattaforma, il catalogo si è ritrovato con le miniature completamente spente e le proporzioni saltate: il database puntava ancora ai vecchi identificativi grafici che il nuovo tema non era programmato per interpretare. La soluzione in quel caso non è stata procedere a tentativi, ma riallineare le tabelle SQL e rigenerare unicamente i formati richiesti dal nuovo template.

Il discorso qual è? Non ha senso perdere tre giorni a cliccare all'impazzata sul pannello di controllo sperando che la grafica si sistemi per miracolo. La tua ora da imprenditore vale 100 euro e ne deve produrre 500. Non puoi impiegarla a cercare stringhe nei log di errore. L'approccio operativo deve essere scientifico: si analizza il log degli errori, si isola la causa e si interviene alla radice.

Riepilogo errori immagini PrestaShop e soluzioni rapide

Questa tabella riassume i sintomi più comuni legati alle immagini del catalogo, il codice di risposta del server e l'azione immediata da compiere per ripristinare il corretto funzionamento.

Sintomo visibile	Codice server	Causa principale	Azione risolutiva
Icona rotta su tutti i prodotti	404 Not Found	Regole .htaccess assenti o corrotte	Disattivare e riattivare le Friendly URL nel back-office
Punto interrogativo su alcuni formati	404 Not Found	Miniatura specifica non ancora generata	Rigenerare solo quel formato (Cancella precedenti = NO)
Immagini non caricate	403 Forbidden	Permessi CHMOD troppo restrittivi	Impostare 755 per cartelle e 644 per file via SSH/FTP
Schermata bianca durante la rigenerazione	500 / 504 Timeout	Limiti memoria e tempo PHP esauriti	Eseguire la procedura un formato per volta o usare la riga di comando

Quando conviene intervenire da soli e quando serve un audit tecnico esperto?

Se l'anomalia dipende dal file .htaccess o da un semplice permesso di cartella errato, puoi risolvere la situazione in piena autonomia in circa quindici minuti. Se invece le immagini originali mancano sul server, se il database è corrotto o se ogni tentativo di rigenerazione manda il server in blocco totale, è fondamentale fermarsi prima di cancellare dati irrecuperabili.

Prendiamo il caso peggiore. Immagina di lanciare la rigenerazione miniature con la casella "Cancella precedenti" selezionata su un catalogo da quindicimila referenze. Il server va in crash dopo due minuti: ti ritrovi con settemila foto eliminate per sempre dal disco fisso e il backup dell'hosting non aggiornato.

Prima di toccare qualsiasi impostazione o lanciare procedure distruttive sul server, metti in atto questa sequenza minima di sicurezza:

Esegui un backup completo del database MySQL tramite phpMyAdmin o linea di comando.
Crea un archivio compresso (tar.gz o zip) dell'intera cartella /img/ e scaricalo sul tuo computer.
Non installare moduli di pulizia o ottimizzazione immagini sconosciuti mentre il catalogo è in stato di emergenza.

Meglio fatto che perfetto non significa lavorare alla cieca sul negozio in produzione mentre i clienti provano a completare gli acquisti. Se il disservizio persiste da giorni e le vendite sono ferme, il costo del danno supera ampiamente il costo di qualunque intervento tecnico qualificato.

Ripristina le immagini del tuo negozio senza rischiare il catalogo

Se hai già tentato il riallineamento del file .htaccess, controllato i permessi e la rigenerazione continua ad andare in blocco mandando il server in errore, l'errore è più profondo e coinvolge la configurazione dell'ambiente di hosting o il database della piattaforma.

In queste situazioni, continuare a fare tentativi disordinati rischia solo di sovrascrivere file originali o corrompere l'indice dei prodotti. Per chi desidera andare sul sicuro e chiudere il problema una volta per tutte, metto a disposizione il servizio di Audit Tecnico Approfondito PrestaShop a 497 €.

Analizziamo la configurazione del tuo server, verifichiamo la coerenza strutturale del database e identifichiamo con precisione millimetrica la causa del blocco entro 24-48 ore, indicandoti la procedura esatta per ripristinare il catalogo senza mettere a rischio lo storico degli ordini e le vendite del tuo e-commerce.

Per richiedere una verifica immediata del tuo store, puoi collegarti direttamente a francescoingrosso.com e segnalare la tua urgenza.

Domande frequenti

Perché dopo aver rigenerato le miniature continuo a non vedere le immagini?

Nella maggior parte dei casi si tratta di una questione di cache attiva. Svuota sia la cache interna di PrestaShop (da Parametri Avanzati > Prestazioni) sia la cache del tuo browser o di eventuali CDN esterne come Cloudflare, che continuano a distribuire la vecchia versione della pagina con il link non aggiornato.

Cosa significa l'errore 404 sulle immagini prodotto su PrestaShop?

Significa che il percorso web richiesto dal browser per caricare la foto non corrisponde a un file reale sul server. Questo avviene quasi sempre per una regola di riscrittura non funzionante all'interno del file .htaccess oppure perché il file originale non è mai stato caricato nella cartella /img/p/.

Posso impostare i permessi della cartella /img a 777 per risolvere l'errore 403?

No, non devi mai impostare i permessi 777 in produzione. I permessi corretti e sicuri per far funzionare PrestaShop sono 755 per le cartelle e 644 per i file. Assegnare 777 permette a qualsiasi utente di eseguire file all'interno dello spazio web, esponendo il negozio al rischio concreto di intrusioni e malware.

Come faccio a sapere quante immagini prodotto mancano fisicamente dal server?

Puoi confrontare il numero totale di record presenti nella tabella ps_image del database con il numero effettivo di file contenuti all'interno della cartella /img/p/. Se il database contiene più record rispetto ai file trovati sul disco, alcuni file sorgente sono stati rimossi o non sono stati trasferiti durante la migrazione.

Hai un e-commerce PrestaShop che non performa?

Richiedi un'analisi gratuita del tuo sito. Identifico i problemi tecnici e ti propongo un piano d'azione concreto.

Richiedi Analisi Gratuita

Ti sono state utili queste guide? Aggiungici come fonte preferita su Google:

Francesco Ingrosso

15 anni su PrestaShop, 300+ store seguiti. Ingegnere del software: lavoro ogni giorno su e-commerce reali, tra migrazioni, performance e recupero vendite.

Scopri chi sono → LinkedIn