+1 per la tua richiesata, soprattutto per quanto riguarda funzioni che devono essere presenti obbligatoriamente per evitare di avere un sito irregolare dal punto di vista normativo

Buongiorno Dario, 

grazie per il tuo messaggio.

Relativamente ai punti riferiti al diritto di recesso, ti segnalo questa guida che spiega come gestire questo aspetto: https://guide.websitex5.com/it/support/solutions/articles/44002813636

Per gli altri punti ti confermo che sono già stati segnalati, ma sarò felice di riportare l'attenzione su questi aspetti. Non ho solo ben chiaro cosa intendi con il punto 7: potresti fornirmi maggiori informazioni per favore?

Grazie!

La guida è sicuramente utile per creare una soluzione manuale. La mia proposta però era leggermente diversa: non intendevo solo la possibilità di realizzare il recesso con gli strumenti già presenti, ma una funzione e-commerce più integrata.

Ad esempio, sarebbe utile avere una gestione dedicata nel pannello admin, collegata agli ordini, con richiesta di recesso/reso, stato della pratica, data, note interne e storico. In questo modo l’utente non dovrebbe gestire tutto solo tramite email o moduli generici.

Per quanto riguarda il punto 7, intendevo un modulo guidato per aiutare chi usa WebSite X5 e-commerce a creare e mantenere aggiornate le principali pagine obbligatorie o comunque importanti per un negozio online: condizioni di vendita, privacy policy, cookie policy, diritto di recesso, garanzia legale, spedizioni, pagamenti e dati aziendali.

Ad esempio, se nel sito vengono attivati determinati servizi, come Analytics, strumenti anti-spam, sistemi di pagamento, newsletter, moduli di contatto o altri servizi esterni, WebSite X5 potrebbe aiutare l’utente a generare una base coerente di privacy policy/cookie policy, partendo dai servizi effettivamente utilizzati nel progetto.

Non intendo una consulenza legale automatica, ma una procedura guidata con campi strutturati, testi base, checklist e avvisi utili. L’utente finale resterebbe comunque responsabile della verifica dei contenuti, ma avrebbe una base molto più ordinata da cui partire.

Secondo me questa funzione potrebbe essere collegata alla licenza attiva o al piano aggiornamenti attivo. Sarebbe utile per gli utenti e-commerce e, allo stesso tempo, potrebbe invogliare gli utenti a mantenere sempre aggiornato il software.

In generale credo che Incomedia potrebbe valutare una serie di servizi aggiuntivi collegati alla licenza attiva, pensati proprio per chi usa WebSite X5 in ambito professionale o e-commerce. Questo darebbe più valore al rinnovo e aiuterebbe gli utenti a restare aggiornati su aspetti tecnici, normativi e di sicurezza.

+1

008. URL Open Graph homepage

Nella homepage il tag automatico:

<meta property="og:url">

dovrebbe puntare alla root del sito, es.:

https://www.nomesito.it/

e non a:

https://www.nomesito.it/index.html

per avere un URL più pulito e canonico.

009. Link immagini verso root

Quando si associa un link a un’immagine, dovrebbe essere possibile puntare direttamente alla root del sito (/) e non necessariamente a index.html.

Utile soprattutto per loghi, banner e immagini che rimandano alla homepage.

010. Pagine prodotto: og:image:alt automatico

Nelle pagine prodotto X5 genera già og:image usando l’immagine principale/miniatura del prodotto.

Sarebbe utile generare automaticamente anche:

<meta property="og:image:alt" content="..." />

prendendo il testo dal titolo o dal testo alternativo dell’immagine principale del prodotto.

011. Pagine generiche: og:image personalizzabile

Nelle pagine generiche X5 usa come og:image la stessa immagine della homepage.

Sarebbe utile poter scegliere un’immagine Open Graph specifica per ogni pagina, così da avere anteprime social coerenti con il contenuto.

Anche in questo caso dovrebbe essere generato il relativo og:image:alt, prendendo il testo dal titolo/testo alternativo dell’immagine scelta.

012. Ottimizzazione codice effetti immagine

Quando si applicano effetti alle immagini, ad esempio bagliore esterno, bordo colorato, zoom, salto, opacità o impulso, X5 può generare script inline ripetuti per ogni singola immagine.

Sarebbe utile ottimizzare il codice esportato aggregando le chiamate in un unico script, oppure usando classi CSS/attributi data-* per gestire i parametri dei vari effetti.

Per gli effetti più semplici si potrebbe valutare anche una soluzione CSS pura, riducendo JavaScript inline, peso della pagina e interruzioni del parser HTML.

013. URL prodotto nei dati strutturati JSON-LD

Nelle pagine categoria X5 genera correttamente i link visibili alle schede prodotto, ad esempio:

product/?nome-prodotto-seo

Lo stesso URL viene usato nei link del titolo prodotto e negli eventi di apertura della scheda.

Nel JSON-LD ItemList, però, X5 usa come url del prodotto l’ancora interna alla pagina categoria, ad esempio:

voltmetri-dc.html#imProductList_...

Sarebbe più coerente usare anche nei dati strutturati lo stesso URL della scheda prodotto già generato da X5 per i link visibili, quando disponibile.

Questo renderebbe il markup più coerente e più adatto all’interpretazione dei prodotti da parte dei crawler.

+1

016. Richiesta favicon.ico 404 nelle pagine speciali

Sto testando la versione 2026.2.3 e ho notato un comportamento anomalo nelle pagine speciali, in particolare imlogin.php / area cliente.

A volte Chrome ed Edge generano una richiesta automatica a:

/favicon.ico

che restituisce 404 Not Found.

Nel progetto la favicon risulta impostata e vengono caricati correttamente file del tipo:

favicon.png?2026-2-3-...

Quindi la favicon moderna sembra presente, ma il browser effettua comunque il fallback verso /favicon.ico, che non viene trovato nella root del sito.

Il problema non blocca il funzionamento del sito, ma genera un 404 inutile in console. Sarebbe utile che WebSite X5 esportasse sempre anche un vero favicon.ico nella root del sito.

Premetto una cosa, così ci capiamo subito: quando Incomedia sbaglia, sono il primo a dirlo senza mezzi termini; quando invece una richiesta non è coerente con l’architettura del software, lo riconosco con la stessa onestà.

Lo dico perché molte delle funzioni elencate qui sopra appartengono a piattaforme come WordPress/WooCommerce, che hanno un backend dinamico, plugin, API e un sistema utenti avanzato. WebSite X5 invece è un software desktop che genera siti statici/dinamici, con una logica completamente diversa. 

Detto questo, provo a chiarire alcuni punti su cosa secondo me è fattibile e cosa invece appartiene a logiche da CMS.

006. Grafico prodotti venduti - Richiesta legittima. Migliorabile senza stravolgere l’architettura.

007. Modulo guidato per pagine legali - Questa è una richiesta intelligente e compatibile con X5. Potrebbe essere un ottimo valore aggiunto per gli utenti e-commerce.

008–009. URL Open Graph e link alla root - L'utente qui ha ragione: tecnicamente migliorabile e coerente con le best practice SEO.

010–011. Open Graph avanzati - Anche qui l'utente consiglia bene: miglioramento possibile e utile, senza cambiare l’architettura del software.

Molti dei punti che ha elencato DARIO sono ottimi spunti, ma appartengono a piattaforme come WordPress/WooCommerce che hanno un backend dinamico e un sistema di plugin. WebSite X5 ha un’architettura diversa, più semplice e più orientata alla produzione rapida di siti.

Alcune richieste sono realistiche (Open Graph, modulo legale, miglioramenti grafici), altre invece richiederebbero trasformare X5 in un CMS completo.

Per quanto riguarda la favicon, il comportamento che descrivi secondo me non è un bug di WebSite X5 ma una caratteristica dei browser moderni. Chrome, Edge e Safari effettuano sempre una richiesta automatica a /favicon.ico come fallback, anche se il sito utilizza favicon moderne in PNG o formati multipli.

X5 genera correttamente la favicon in PNG con query string (es. favicon.png?2026-2-3-...), che è perfettamente valida secondo gli standard attuali. Il 404 su /favicon.ico non influisce sul sito e non è un errore del progetto: è semplicemente il browser che tenta un file legacy che non esiste. Detto questo, potrebbe essere utile che X5 esportasse anche un file favicon.ico nella root per evitare il 404, ma si tratta di un miglioramento cosmetico, non di un malfunzionamento.

In ogni caso, idee utili: speriamo che Incomedia possa integrare almeno quelle compatibili con la struttura del software RESPONSIVE compreso ad oggi solo e ancora ahimè al 50%.

Concordo sul fatto che il 404 su /favicon.ico non sia un problema grave né bloccante.

La mia segnalazione nasce però da due osservazioni pratiche: da un lato Chrome ed Edge, soprattutto passando da pagine speciali come imlogin.php / area cliente, tentano ogni tanto il fallback verso /favicon.ico; dall’altro ho notato che su Google la favicon del sito viene mostrata nei risultati di ricerca, mentre su Bing al momento non compare. Sto quindi cercando di capire se la mancanza di un file favicon.ico fisico nella root possa essere uno dei fattori.

Nel codice delle pagine la favicon è presente come PNG, ad esempio:

<link rel="icon" href="favicon.png?2026-2-3-1-..." type="image/png" />

Quindi non sto dicendo che la favicon sia assente o che X5 non la generi. La mia osservazione è più semplice: forse sarebbe utile esportare anche un vero /favicon.ico nella root, oltre alla favicon PNG, così da evitare richieste 404 inutili e migliorare la compatibilità con browser, crawler o servizi che cercano ancora il file legacy.

Sul discorso CMS, capisco la distinzione con piattaforme come WordPress/WooCommerce, però le modifiche proposte non mi sembrano neanche lontanamente paragonabili alla trasformazione di WebSite X5 in un CMS completo. Parliamo soprattutto di ottimizzazioni SEO, Open Graph, piccole rifiniture e-commerce e correzioni su pagine già generate dal programma.

Secondo me sono richieste compatibili con la natura di X5, senza stravolgerne l’architettura.

017. Gestione allegati scaricabili per prodotti e-commerce

Sarebbe utile introdurre una gestione nativa degli allegati scaricabili associati ai singoli prodotti e-commerce.

Per molti prodotti tecnici è necessario rendere disponibili file aggiuntivi come schede tecniche PDF, manuali, certificati, disegni DWG, datasheet o altri documenti di supporto.

La soluzione ideale sarebbe una sezione dedicata nelle impostazioni del prodotto, ad esempio “Allegati”, con possibilità di selezionare uno o più file dal progetto, gestirne titolo/descrizione, pubblicarli automaticamente insieme al sito e generarne il link nella scheda prodotto.

In questo modo si eviterebbe la gestione manuale tramite caricamento separato dei file e inserimento dei collegamenti nella descrizione, rendendo il flusso più ordinato, riutilizzabile e coerente con la gestione già prevista per immagini e contenuti del prodotto.